text: telephone switching systems are designed primarily to handle switching functions . while they do store data detailing the configurations of the telephone lines connected to the switches and can provide that information on request , such information handling tasks are conducted at a very low level of priority . consequently , responses to requests for information are generally slow . the element management system (“ ems ”) 100 according to a preferred embodiment of the present invention , shown functionally in fig1 contains and maintains a proxy database subsystem or proxy database 20 which reflects substantially up - to - date subscriber data as to the services being provided to customers , viz . subscriber requirements and corresponding subscriber line configurations of the central offices and / or other network elements managed by the ems . the managed data is fetched from the managed network elements 31 , 31 ′, 31 ″ etc . via network connections and stored in the proxy database 20 . the ems 100 also has the capability to populate the proxy database in bulk or single unit mode . the signal flow involved in initialization of the proxy database is shown in fig2 . subscriber data respecting the network element 31 is stored in an associated subscriber data storage means 31 a . similarly , subscriber data respecting each of the other network elements 31 ′, 31 ″ etc . is stored in corresponding associated subscriber data storage means ( not shown ). the subscriber data storage means associated with a particular network element may be physically situated at the location of said network element or at a remote site . reference herein to a network element implicitly includes reference to the associated subscriber data storage means . the proxy database 20 of the ems mirrors , i . e . contains and maintains on an essentially current basis , a functional copy of the subscriber data ( i . e ., data as to subscriber requirements and subscriber line configurations ) of the managed network elements 31 , 31 ′, 31 ″ etc . thus clients such as telephone company personnel and systems can obtain up - to - date subscriber data by querying the ems rather than querying the central offices or other network elements and waiting a relatively long time for response . the signal flow involved in the query process is shown in fig4 . the clients will also send requests to the ems for configuration changes , i . e . to change certain data in the network elements . a subsystem of the ems then translates the requests into corresponding network element commands and communicates the commands to the appropriate network elements . upon receiving responses from the network elements indicating the requested changes have been made , the response messages are sent to the clients , and the proxy database is updated accordingly . the signal flow involved in this configuration changing process is shown in fig6 . a synchronization subsystem 22 in the ems 100 keeps the subscriber data in the proxy database 20 synchronized with the network element subscriber data . this subsystem informs the managed network elements 31 , 31 ′, 31 ″ etc . as to which data needs to be monitored for the ems . the network elements input changes in such data into log files , and the synchronization subsystem obtains the log files from the network elements at scheduled time intervals , or in real time . for improved data transfer efficiency , information as to which records have been changed in the time interval since the last accessing of the log files can be parsed out therefrom . the ems sends commands to retrieve the changed data from the network elements and store the changed data in the proxy database . the signal flow involved in the synchronization process is shown in fig8 . the proxy database in the ems keeps a functional copy of the network element subscriber data . the clients of the ems communicate with the ems instead of accessing the network elements directly . in a telephone system , an element management system is a type of operations support system (“ oss ”) and part of a telecommunication management network (“ tmn ”), namely that portion which performs configuration management and security management functions . the present invention relates to the configuration management part of the element management system . as shown in fig1 the ems 100 has the following subsystems , i . e . software modules : the proxy database subsystem 20 contains a functional copy of the data in network elements 31 , 31 ′, 31 ″ etc . which are managed by the ems , and reflects essentially up - to - date subscriber data of the network elements . the network elements may , for example , be telephone central offices . the proxy database subsystem has the following features and functions : a . the proxy database is initialized at the startup of the ems . b . the proxy database can be populated with fresh data in either single unit or bulk mode ; and is preferably initially populated in a bulk mode and thereafter populated in a single unit mode . c . any changes in the network elements 31 made by sources outside the ems are detected in such a way that the proxy database is updated by the synchronization subsystem 22 ; which automatically detects changes made to subscriber data by sources independent of the ems , and stores the changed data in the proxy database . d . to query the data of the network elements 31 , the clients of the ems only need to query the proxy database , thus optimizing the current status of the data available to the clients for a given allocation of network element resources . e . when the clients 32 of the ems send configuration requests to the ems to change the network element data , the network resources subsystem 23 validates the requests and translates the requests into corresponding network element commands . these translated commands are then sent to the network elements . if the commands are successfully executed , the proxy database is updated accordingly . by thus keeping the ems “ in the loop ” as to such changes , the current status of the information in the proxy database as to such requested changes is maintained . the proxy database needs to be initialized at the startup of the ems 100 , using data obtained from the network elements 31 , 31 ′, 31 ″ etc . the clients 32 can also repopulate the proxy database in single unit or bulk mode . the initialization and re - population can be scheduled by the oa & amp ; m subsystem 26 or manually started by the system administrators . to maintain the data contained therein as current as is feasible consistent with the relatively low priority availability of network element resources for data exchange , the proxy database subsystem 20 needs to be kept synchronized with the data of the network elements 31 , 31 ′, 31 ″ etc . this subsystem therefore has a mechanism to ( i ) detect changes made by sources independent of the ems , and ( ii ) automatically update the proxy database based on the changes detected . the synchronization process can be scheduled or manually started from the oa & amp ; m subsystem 26 . the network resources subsystem 23 takes care of data change requests from the clients 32 of the ems . the requests are validated and translated into network element commands . the validated network element commands are sent to the network elements 31 , 31 ′, 31 ″ etc . via the network interface subsystem 24 . after getting successful responses from the network elements 31 , the subsystem 23 ( i ) updates the proxy database accordingly . ( ii ) sends corresponding response messages back to the clients 32 , ( iii ) compares the old values with the new values in the proxy database , and ( iv ) sends the differences to the log / archive subsystem 27 . the parser 30 performs two distinct functions . first , it parses log files from the network elements 31 . second , it extracts changed subscriber data from the response sent back from the network elements . log files are files that reside in each network element or the associated subscriber data storage means and / or an associated control system and contain information about data that has been changed in or for the network element . since the log files obtained from a network element vary in format depending on the network element type , they need to be parsed to identify the data records that contain the changed data . the parser 30 , for instance , examines these log files to determine what data to retrieve from the corresponding network element for updating of the proxy database 20 . since the changed data records retrieved from the network element are presented in different formats depending on the network element type , relevant data needs to be extracted , by the parser , from said records before being stored in the proxy database . the network interface subsystem 24 supports interfaces with different network elements based on specific protocols such as tcp / ip , x . 25 , for example . the operation , administration and maintenance (“ oa & amp ; m ”) subsystem 26 provides services to both ems clients and internal ems subsystems for management of the ems application system resources . features and functions of the oa & amp ; m subsystem include : a . providing oa & amp ; m resource management services to ems clients . for example , such services allow telephone company system administrators to establish and change ( i ) the frequency of backup of ems files , ( ii ) the frequency of interrogation of network elements by the synchronization subsystem , and ( iii ) security levels , user identification codes and passwords for access to and / or control of various aspects of the ems and the network elements with which it is associated . b . management of a configuration database incorporated in the ems and containing information such as login identification codes and network addresses . c . access protection of the oa & amp ; m resources stored in the log / archive subsystem 27 . the log / archive subsystem 27 provides services to both ems clients and internal ems subsystems for the management of the ems logs ( i . e ., the recent change history logs ) and archives , and functions as the gateway into the ems log database and archive within said subsystem . the application programming interfaces ( apis ) 25 provide a communication infrastructure between the ems 100 and its clients 32 across distributed and heterogeneous computing environments . two categories of interfaces are included , namely ( i ) common object request broker architecture (“ corba ”) apis and ( ii ) customizable apis . features and functions of the application programming interfaces include : a . determining where specific network resource objects ( such as concentrators , satellite links , etc .) are . c . directing requests from the ems clients to the appropriate ems subsystems and redirecting the responses from said subsystems back to the ems clients . the user interfaces (“ ui ”) server 28 acts to couple the ems to an external web to enable clients and remote users to utilize the web or wide area network 33 to provide services that the ems cannot provide directly . functions of the user interfaces server include : c . converting responses received via the web to a form usable by the ems . d . managing data communication sessions ( open , closed , etc .) between the ems and web based browsers . the operations support systems (“ oss ”) gateway subsystem 29 acts as a gateway between the ems and other operations support systems such as legacy oss 34 that need access to the ems services but are not supported by the corba interfaces . the features and functions of the operations support systems gateway subsystem include : a . converting oss - specific configuration requests into one or more ems corba interface requests . c . managing data communication sessions ( open , close , etc .) between the oss and ems corba interfaces . the proxy database 20 has four principal modes of operation , namely : ( 1 ) initialization ; ( 2 ) client query ; ( 3 ) network element data change request ; and ( 4 ) synchronization . when a new circuit ( telephone line ) is added to a telephone network switch or when the ems starts up initially , the data in the proxy database must be initialized . fig2 illustrates the operation of the software modules of the ems when initialization is performed . first , the oa & amp ; m module 26 requests an initialization to occur . this request is coupled to the initialization subsystem 21 via line 1 . the initialization subsystem issues a command on line 2 to the network interface subsystem 24 , which issues a corresponding command to the network element ( s ) 31 on line 3 . the network element ( s ) provides either the data , if it is available , or an error message , if a communication or other error occurs ; and sends the data or error message on line 4 to the network interface subsystem 24 , which issues a corresponding response signal back to the initialization subsystem 21 on line 5 . the response signal is passed to the parser 30 on line 6 , for further data filtering , and then forwarded to the proxy database on line 7 a . then the initialization subsystem 21 sends the response messages to the oa & amp ; m module 26 via line 7 b . this section describes , in more detail , the interaction between the different subsystems involved in the initialization process . fig3 a and 3b illustrate the step - wise process flow of the initialization process . in step 1 , the oa & amp ; m module sends a request to the initialization subsystem for initialization of a particular resource , for example , a telephone number . in step 2 , the initialization subsystem receives this request . in step 3 , the initialization subsystem issues a verify command to the network interface subsystem . the verify command is a switch command , which returns the data associated with a particular resource , specified as part of the command . in step 4 , the network interface subsystem issues a corresponding command , which wraps the verify command , to the network element . for example , if the network interface subsystem uses x . 25 protocol to communicate with the network element , then it opens a session with the network element host . the network interface subsystem then sends the verify command , which is the data to be sent , through the session and then closes the session . in step 5 , the network element receives the verify command and provides either the resource data or an error message to the network interface subsystem as the response . in step 6 , the network interface subsystem passes the resource data or the error message back to the initialization subsystem after converting the data or error message back from the transmission format to the original format . in step 7 , the availability of the data is checked . if the data is available the program proceeds to step 8 . if the data is not available then the program proceeds to step 12 . in step 8 , the initialization subsystem passes the resource data to the parser for further data filtering , based on the verify translation table entries . the parser uses the resource data and the entries in the verify translation table to get the value for the features and functions associated with the resource . in step 9 , the parser determines whether it needs to send additional verify commands to the initialization subsystem . most of the time , due to the low priority given to such data exchanges by network elements , all the data associated with a resource cannot be retrieved in response to a single verify command . in step 10 , the program either proceeds to step 11 or loops back to step 3 based on whether more verify commands need to be sent . in step 11 , the initialization subsystem has all the data pertaining to the resource and it then forwards this data to the proxy database by issuing database commands . in step 12 , the initialization subsystem sends the response message , i . e . whether the initialization was successful or not , to the oa & amp ; m module . at times , a client , such as a user , an administrator , a service representative , or another system , will need to determine the status or configuration of , for example , a particular telephone line . since such information resides in the proxy database , it can be obtained directly from that database without the necessity to access a network element such as the central office to which the particular telephone line is connected . the manner in which software modules of the ems process a client query is shown in fig4 . initially , the client 32 sends a query request to the appropriate application programming interface of the apis 25 on line 1 , seeking subscriber data information associated with a particular network element of the elements 31 , 31 ′, 31 ″ etc . ( fig1 ); such information being also contained in the proxy database . the application programming interface forwards the query request to the network resources subsystem 23 via line 2 . the network resources subsystem parses the request and translates it into a corresponding database query command , which is communicated to the proxy database via line 3 . the proxy database then searches for the requested information . since the proxy database is concerned solely with data management , it responds much more quickly than would the network element itself . the query result , which may be the requested information or an error message if the requested information is not available or an error is encountered during the database search , is sent back to the network resources subsystem 23 via line 4 . the network resources subsystem then passes the query result to the originating application programming interface of the apis 25 via line 5 ; and that application programming interface converts the result to an appropriate interface format and transfers it to the client 32 via line 6 . this section describes , in more detail , the interaction between the different subsystems involved in the client query process . fig5 a and 5b illustrate the step - by - step process flow of the client query process . in step 1 , the ems client sends a query request to the appropriate application programming interface , seeking subscriber data information associated with a particular network element . the application programming interface can be thought of as a server module that communicates with the ems client . for example , the api could be a corba server , a web server , or any customized server that can service the ems client . this server receives the requests from the client and sends responses from the ems back to the client . in step 2 , the application programming interface forwards the query request to the network resources subsystem after removing the transmission information , such as the protocol headers and trailers , from the query . at this stage , the query is in the appropriate interface format as needed by the ems . in step 3 , the network resources subsystem parses the request and translates it into a corresponding database query command . in step 4 , the network resources subsystem executes the database query command on the proxy database . in step 5 , a check is made on the availability of the requested information . if the requested information is available , the program goes to step 6 . if the requested information is not available , then the program proceeds to step 7 . the query result may be the requested information or an error message . if either the requested information is not available or an error is encountered during the database search , an error message is received as a result of the execution of the query command . in step 6 , the proxy database sends back the requested information to the network resources subsystem . in step 7 , the proxy database sends back an error message to the network resources subsystem . the program reaches step 8 either through step 6 or step 7 . in step 8 , the network resources subsystem parses the query result , translates it to the appropriate interface format and sends it to the originating application programming interface . in step 9 , the originating application programming interface transfers the translated query result to the ems client and then the program exits . since the proxy database is concerned solely with data management , it responds more quickly to a client query than the actual network element . without such a proxy database , substantially more time would be required to process the client query , due to the additional steps described below : a . the query would have to be sent to the network element across the network ; b . the network element would have to process the query and respond to it in addition to the other work it does ; and c . the response would have to be received from the network element across the network . from time to time , the status or configuration of one or more telephone lines ( or other components ) associated with a network element needs to be modified , usually to reflect changes in subscriber data . in such an instance , the change is relayed to the corresponding network element , where the change actually occurs ; and upon verification that the change has occurred , the proxy database is updated to reflect the change . fig6 illustrates the operation of the cognizant software modules of the ems when a data change is requested . first , a client 32 sends a data change request for a particular network element of the elements 31 to the appropriate application programming interface of the apis 25 via line 1 . the application programming interface forwards the change request to the network resources subsystem 23 via line 2 . the network resources subsystem validates the request , based on the information in the proxy database . if successfully validated , the request is translated into a command or commands understandable by the particular network element . the network resources subsystem then issues the translated command to the network interface subsystem 24 via line 3 . the network interface subsystem is the module that actually communicates with the network element by taking the data change command from the network resources subsystem , converting it to an appropriate transmission format , such as tcp / ip or x . 25 , and forwarding it to the particular network element of the elements 31 on line 4 . if the change is successfully executed , the particular network element will send back a response to the network interface subsystem 24 via line 5 , where the response is converted back from the transmission format and sent back to the network resources subsystem 23 via line 6 . if there was an error , the network element will , instead of sending a positive response indicating the requested change was made or will be made , send an error message as a ( negative ) response . if the response is positive , the network resources subsystem 23 updates the proxy database accordingly via line 7 a , to reflect the change made to the network element . regardless of the nature of the response ( positive or error ), the network resources subsystem always communicates the response back to the client 32 on line 8 via the originating application programming interface , to which the response is communicated on line 7 b . this section describes , in more detail , the interaction between the different subsystems involved in the network element data change request process . fig7 a and 7b illustrate the step - by - step process flow of the data change request process . in step 1 , the ems client sends a data change request for a particular network element to the appropriate application programming interface . in step 2 , the application programming interface forwards the change request to the network resources subsystem . in step 3 , the network resources subsystem validates the request based on the information in the proxy database . examples of the different types of validation are checks across different tables in the database ( cross - datafile checks ), checks across different records in the same table ( cross - record checks ), and checks across different fields in the same record ( cross - field checks ). for example , if telephone number 555 - 1212 has the feature called call forward busy turned on then its call forward busy telephone number must be set to a valid telephone number for the call to be successfully forwarded when telephone number 555 - 1212 is busy . this is an example of a cross - field check . in step 4 , a check is made as to whether the validation was successful . if the validation was successful , the program proceeds to step 5 . if the validation was not successful then the program proceeds to step 13 . in step 5 , the request is translated into command ( s ) understandable by the network element . each network element has a specific set of commands that can be used to manipulate the data of that network element . in step 6 , the network resources subsystem issues the translated command to the network interface subsystem . in step 7 , the network interface subsystem , which is the module that actually communicates with the network element , takes the data change command from the network resources subsystem and converts it into an appropriate format ( e . g ., tcp / ip , x . 25 ) [ see step 4 of the initialization process — fig3 a — for more detail in this respect ]. in step 8 , the network interface subsystem forwards the data change command to the network element . in step 9 , the network element sends back a response to the network interface subsystem . in step 10 , the network interface subsystem converts the response back from the transmission format and sends it to the network resources subsystem . in step 11 , a check is made as to whether the change was successfully executed or not . if the change was successfully executed , then the program proceeds to step 12 . if the change was not successfully executed , the program proceeds to step 13 . in step 12 , the network resources subsystem updates the proxy database accordingly , to reflect the change made to the network element . in step 13 , the network resources subsystem sends a response , indicating whether the data change request was successful or not , back to the ems client through the originating api ; and then the program exits . the data in the proxy database 20 must be periodically updated to accurately reflect the status or configuration of the network elements 31 , 31 ′, 31 ″, etc . fig8 illustrates the operation of the cognizant software modules of the ems 100 when the contents of the proxy database are synchronized with the subscriber data of a network element . the synchronization process starts when the oa & amp ; m module 26 sends an update request to the synchronization subsystem 22 via line 1 . upon receiving the request , the synchronization subsystem sends a request to the network interface subsystem 24 on line 2 ; and the network interface subsystem sends a corresponding request to the corresponding one or more of the network elements 31 , 31 ′, 31 ″ etc . for downloading a log file to the network interface subsystem on line 4 , which routes the log file being downloaded to the synchronization subsystem 22 via line 5 . once the log file is received , the synchronization subsystem sends it to the parser 30 via line 6 for identifying they are identified by a signal from the parser to the synchronization subsystem on line 11 ; and the synchronization subsystem requests the changed data from the network elements 31 on line 7 to the network interface subsystem 24 , which communicates the request to the network elements 31 via line 8 . the network elements 31 reply by sending the changed data back to the network interface subsystem 24 on line 9 , which routes the changed data to the synchronization subsystem 22 on line 10 . thereafter the synchronization subsystem transfers the changed data to the parser 30 via line 11 for further data filtering , and then stores the filtered data in the proxy database via line 12 . then the synchronization subsystem 22 sends a reply signal to the oa & amp ; m module 26 , either confirming that the subscriber data has been updated in the proxy database , or delivering an error message . this section describes , in more detail , the interaction between the different subsystems involved in the synchronization process . fig9 a and 9b illustrate the step - by - step process flow of the synchronization process . in step 1 , the synchronization process starts when the oa & amp ; m module sends an update request to the synchronization subsystem . in step 2 , the synchronization subsystem sends a request to the network interface subsystem to download the log file from the network element . the log file contains the changes made to the data in the network element . in step 3 , the network interface subsystem converts the request to an appropriate transmission format , such as tcp / ip or x . 25 , and sends it to the network element [ see step 4 of the initialization process — fig3 a — for more detail in this respect ]. in step 4 , the network interface subsystem routes the downloaded log file to the synchronization subsystem . in step 5 , the synchronization subsystem sends the log file to the parser for identifying data changes in the network element . the parser looks only for the data changes made since the last time the log file was downloaded . in step 6 , a check is made to find whether there are any data changes made by systems outside of the ems . the parser does not consider the changes made through the requests by the ems because those changes would have already been incorporated in the proxy database during the data change request process [ refer , to step 12 of the network element data change request process — fig7 b ]. if there are any changes , the program proceeds to step 9 . if there are no data changes , then the program proceeds to step 7 . in step 7 , the parser sends a response to the synchronization subsystem notifying it that there were no data changes . in step 8 , the synchronization subsystem sends an appropriate reply to the oa & amp ; m module and the program exits . in step 9 , the parser sends a list of resources that have changed to the synchronization subsystem . in step 10 , a check is made to find whether there are any resources left to be synchronized . if there are any resources left to be synchronized , then the program proceeds to step 11 . if not , then the program proceeds to step 15 . in step 11 , the synchronization subsystem sends a request to the initialization subsystem to initialize that particular resource . the initialization process takes place as previously described ; except that the request for initialization comes from the synchronization subsystem instead of the oa & amp ; m module . in step 12 , a check is made to find whether the initialization was successful . if the initialization was successful the program proceeds to step 14 . if not , then it proceeds to step 13 . in step 13 , the synchronization subsystem adds the current resource to the list of resources whose initialization failed . then the program loops back to step 10 . in step 14 , the synchronization subsystem adds the current resource to the list of resources whose initialization succeeded . then the program loops back to step 10 . in step 15 , the synchronization subsystem sends a report of both the list of resources whose initialization succeeded and the list of resources whose initialization failed to the oa & amp ; m module . by means of synchronization , the proxy database is updated with the changes made to the network element data by systems independent of the ems . due to the proxy database being synchronized , there is no need to contact the network elements to obtain such network element data ; thus enabling faster response to client queries as described in the previous client query section . the proxy database system of the present invention provides substantially faster response times for client queries , as was discussed in the section on client query . since the data in the proxy database is synchronized frequently , it matches the data in the corresponding network elements on a reasonably current basis and eliminates the need to directly access the network elements to retrieve data ; thus lessening the burden on the network elements and avoiding the degradation in network performance which would otherwise result . since the data in the proxy database is centralized , it is possible to utilize the ems to do administration of the telephone network itself in addition to administration of individual network elements .