fig1 schematically illustrates a system for generating or creating information outputs , e . g . voice outputs , or interactive dialogs which can be made available to service users . according to the invention , service providers da 1 , da 2 and da 3 can access an inventive arrangement sa ( storage arrangement ) which is operated and administered by a network operator or an operator of an information output or interactive dialog system . the service providers da 1 , da 2 and da 3 access the arrangement sa by means of configuration systems tf 1 , tf 2 and tf 3 ( tf : tooling function ) assigned to them for information outputs or interactive dialogs . within the configuration system tf 1 , ta 2 and tf 3 , components for new or changed information outputs or interactive dialogs can be created . these components are then transferred to the storage arrangement sa using e . g . the http protocol and stored on a storage area a / d 1 , a / d 2 or a / d 3 for recorded messages a or interactive dialogs d assigned to the relevant service provider da 1 , da 2 or da 3 . the access of the service providers da 1 , da 2 and da 3 is protected by the fact that authorizations exist only for the particular storage area a / d 1 , a / d 2 or a / d 3 assigned to him , and that a firewall fw is provided between the arrangement sa and the configuration systems tf 1 , tf 2 and tf 3 of the service providers da 1 , da 2 or da 3 . the operator of the storage arrangement sa himself has at his disposal a configuration system amtf ( administration master tooling function ) from which he can store [ lacuna ] for system messages or interactive dialogs associated with the network operator from components for messages a or interactive dialogs d on a storage area a / da ( a / da : messages a or interactive dialogs d of the network operator or administrator a ). the storage arrangement sa itself is subdivided into two different functional parts , namely a supply device mcf ( master content function ) containing the storage areas which the service providers da 1 , da 2 and da 3 and the system operator access via the configuration system amtf . the access of a service provider or the storing of one or more new or changed components for messages or interactive dialogs triggers or initiates two events : on the one hand the changed or new components are transferred to provision devices scf 1 and scf 2 ( scf : slave content function ) where they are available for information output devices , such as vf 1 , vf 2 and vf 3 ( vf : voice function ). on the other hand , the storing of new or changed components causes charging of this change to be set in train , which is implemented by means of a message sent to the charging server vs . in the same way as for the service providers , components stored by the system operator or network operator by means of the configuration system atmf are automatically transmitted to the provision devices scf 1 and scf 2 , charging generally being unnecessary , as the configuration system amtf and arrangement sa belong to the same operator . the information output devices vf 1 to vf 3 use components stored in the provision devices scf 1 and scf 2 for handling the services , from which components the output required as part of the service or the required interactive dialog is composed . although the storage arrangement sa forms a functional unit , in a preferred solution it is implemented by means of separate hardware elements . this preferred version is illustrated in fig2 . fig2 shows the component configuration system tf of a service provider , as well as the component configuration system amtf of the system operator from which new or changed components can be transmitted e . g . via an ip network to the supply device mcf by means of the http protocol . service provider access is again protected by firewall fw . modified or new components are transmitted to the provision devices scf 1 and scf 2 by means of the unix commands rcp ( remote copy ) or rsh ( remote shell ). in this version the supply devices mcf associated with the arrangement sa , as well as the provision devices scf 1 and scf 2 are implemented on various hardware platforms or servers . the provision devices scf 1 and scf 2 can be accessed by information output devices vf for handling a recorded message or interactive service . a recorded message or interactive service is controlled by a switch vst , with recorded message or interactive services being possible both via circuit - switched networks using pcm ( pulse code modulation ) and via packet - switched networks by means of the rtp protocol ( rtp : real time protocol ) which was designed for real - time traffic handled via ip networks . information fed out by the information output devices vf is finally transmitted using the switch vst to a service user dn who is using a service offered by the service provider . examples of services that can be implemented by a service provider using the systems described in fig1 or fig2 are : a service provider is a telecommunications provider wishing to draw the attention of callers on hold to his latest offers . the offer message is updated monthly . another service provider uses televoting to allow people to participate in his prize draw . in the recorded message for rejecting non - accepted participants , the caller &# 39 ; s attention shall be drawn to new developments in the prize draw in order to make him / her call again . this message must be updated daily . both services can be implemented by leasing resources from the network operator or the operator of the inventive arrangement sa and interactive system vf . the network operator himself also wants to be able to change his system messages . this generally happens somewhat rarely , e . g . in the case of a version change in switches vst in his area of responsibility . each of the service providers receives the url ( universal resource locator ) for a web gui ( gui : graphical user interface ) in which he can define the content of the corresponding recorded messages and interactive dialogs by text ( in which case text - to - speech software is used ) or wav files ( e . g . recorded on his pc or in a sound studio ). he additionally specifies the time of updating . then the relevant changes are checked for correctness on a so - called master resource content server ( corresponding to the supply device mcf ) and recorded ( using voice xml ), and the required wav files are loaded onto the server . for this purpose each service provider is pre - assigned a directory ( a / d 1 , a / d 2 and a / d 3 in fig1 ) on the master resource content server mcf in which are located the recorded messages that can be changed by him . this directory is protected by username / password identification . the corresponding recorded messages are diverted to the service provider &# 39 ; s directory ( a / d 1 , a / d 2 or a / d 3 in fig1 ). for this purpose , the new description in the service provider &# 39 ; s directory is referenced in a voice xml file which is called up by default for the corresponding message . the voice xml file in the provider &# 39 ; s directory is replaced by the new definition at the time of the change . the changes made on the master resource content server mcf are replicated onto the slave resource content servers or provision devices ( scf 1 or scf 2 in the figures ) by means of the unix commands rcp ( remote copy ; copying of data to another server ) and rsh ( remote shell ; issuing system commands to another server ). the number of these servers can be adapted to suit the performance required . simultaneously a charging ticket is created at the time of the change which records data such as the service provider &# 39 ; s id , the time of the change , etc . this enables the change as well as the different change intervals to be charged by the network operator . via an administration gui ( gui : graphical user interface ) the network operator is able to administer his own system messages . here a complete record of new system messages can be displayed . it is possible for this change also not to be implemented until a particular time ( e . g . low - traffic periods ). the changes for the service providers are used by this tool , i . e . the administrations gui or the configuration system amtf of the operator , for the new definitions of the system messages . the network operator can set up new ids for the service providers on the master resource content server mcs . the messages are then assigned to these ids , the tooling creating the appropriate directories and referencing this directory for the corresponding messages . ( this reference is canceled again when the user is deleted .) also the setting - up of these slave resource content servers themselves can be carried out with the gui . the change is notified to the resource voice server ( voice function vf 1 , vf 2 and vf 3 in fig1 , vf in fig2 ), it being e . g . possible to influence the caching time of the message via the configuration of the apache webserver by means of . htaccess file ( this is part of the http protocol and is transmitted over it to the resource voice server ). via the administrations gui , the network operator has the opportunity of also changing the caching time which he can set differently for the various service users . he can likewise define lower and upper bounds as well as a preset value within these bounds specifically for a service provider , so that the latter has the option of changing the preset possibly in a manner affecting charging within the specified interval . in the case of the first example described above for a provider using the system according to the invention , a change interval of 24 hours can be selected . only when the definition is one day old is a new definition retrieved from the information output device or the resource voice server vf by the slave resource content server scf 1 or scf 2 . in this way unnecessary network loading can be avoided and the number of slave resource content servers scf 1 and scf 2 can be reduced . in the case of the second provider , the update rate can be set to 1 hour or ‘ immediately ’, i . e . the recorded message is not cached in the resource voice server vf . more resources must be scheduled here . however , the usage of these resources can be billed , as all the changes are logged and tickets created . for the system messages , the resource voice server vf provides information about changes directly , as these changes do not occur very frequently and the introduction of new features by the network operator is planned long in advance .