Title of Invention: Data management system, primary server, and secondary server for data registration and retrieval in distributed environment Abstract: A data management system that allows client terminals on a network to register records with search keywords to distributed data management servers and to retrieve them by entering a specific search keyword. The entire coverage area of the network is divided into a plurality of primary areas, and each primary area is further subdivided into a plurality of secondary areas. Primary and secondary servers are deployed over the network, one for each individual primary area and secondary area, respectively. The primary servers employ a primary hash function that processes a given search keyword to derive a primary server identifier indicating one of the primary servers that governs a particular primary area where the secondary server having a record relevant to the given search keyword is located. Further, the primary servers have a secondary hash function that processes a given search keyword to derive a specific secondary server identifier indicating one of the secondary servers that is located in the same primary area as their own and has a record relevant to the given search keyword. The secondary servers are also equipped with the same secondary hash function as the primary servers'. Those two hash functions are used in both data registration and data retrieval processes. Detailed Description: Part PAC: DESCRIPTION OF THE PREFERRED EMBODIMENTS Part PAR: An embodiment of the present invention will be described below with reference to the accompanying drawings. Part PAR_2: Referring first to FIG. 1, the following will describe the concept of a data management system in which the present invention is implemented. This system allows terminals (not shown) on a network 1 to register records with search keywords and to retrieve the records by entering a specific search keyword. The system comprises the following elements: Part PA1: a plurality of primary areas 2a to 2n which constitute the entire coverage area of the network 1; PA1 a plurality of secondary areas 3a to 3m which constitute each of the primary areas 2a to 2n; PA1 a plurality of primary servers 4a to 4n, one for each of the primary areas 2a to 2n, which are uniquely identified in the network 1 by primary server identifiers assigned thereto; PA1 a plurality of secondary servers 5a to 5m, one for each of the secondary areas 3a to 3n, which are uniquely identified in each primary area by secondary server identifiers assigned thereto; PA1 a primary transformation unit 6, disposed in each of the primary servers 4a to 4n, for processing a given search keyword to derive a specific primary server identifier indicating one of the primary servers 4a to 4n that governs a particular primary area where the secondary server having a record corresponding to the given search keyword is located; PA1 secondary transformation units 7 and 8, disposed in each of the primary servers 4a to 4n, for processing a given search keyword to derive a specific secondary server identifier indicating one of the secondary servers 5a to 5m that is located in the same primary area and has a record corresponding to the given search keyword; and PA1 a secondary transformation unit 8, disposed in each of the secondary servers 5a to 5m, for processing a given search keyword to derive a specific secondary server identifier indicating one of the secondary servers 5a to 5m that is located in the same primary area and has a record corresponding to the given search keyword. PA1 FIG. 7--Format of activation request messages between servers. PA1 FIG. 8--Format of activation response messages between servers. PA1 FIG. 9--Format of reactivation request messages between servers. PA1 FIG. 10--Format of reactivation response messages between servers. PA1 FIG. 11--Format of primary server information messages, primary server restoration messages, and primary server substitution messages between servers. PA1 FIG. 12--Format of secondary server information messages, secondary server restoration messages, and secondary server substitution messages between servers. PA1 FIG. 13--General message format for the data retrieval, data registration, and search report message classes. PA1 FIG. 14--Format of data registration request messages used between terminals and secondary servers. PA1 FIG. 15--Format of data retrieval request messages used between terminals and secondary servers. PA1 FIG. 16--Format of search report message used between terminals and secondary servers. PA1 FIG. 17--Server information storage in the system supervisory server, where symbols "ID1" and "ID2" represent identifiers of primary servers and secondary servers, respectively. PA1 FIG. 18--Server information storage in primary servers. PA1 FIG. 19--Server information storage in secondary servers. PA1 FIG. 20--Regular data storage, local replicated data storage, remote replicated data storage, local backup data storage, and remote backup data storage. (All those five storage areas are used to store search keywords and data objects to be retrieved with specific keywords, along with related server identifiers. This structure is common to primary servers and secondary servers.) PA1 FIG. 21--Process executed by the terminal when a data registration request has arisen. PA1 FIG. 22--Process executed by the terminal when a data retrieval request has arisen. PA1 FIG. 23--Process executed by the communication controller in each terminal. PA1 FIG. 24--Process executed by the communication controller. PA1 FIG. 25--Process executed by an activation verification unit when starting up a server. PA1 FIG. 26--Process executed by an activation verification unit when reactivating a server. PA1 FIG. 27--Process executed by the server management unit. PA1 FIG. 28(A)--Process executed by the command parser. PA1 FIG. 28(B)--Process executed by the activation request unit. PA1 FIG. 28(C)--Process executed by the reactivation request unit. PA1 FIG. 29--Process executed by the communication controller. PA1 FIG. 30--Process executed by the activation verification unit when server activation is requested. PA1 FIG. 31--Process executed by the activation verification unit when server reactivation is requested. PA1 FIG. 32--Process executed by the server management unit. PA1 FIG. 33--Process executed by the data registration unit. PA1 FIG. 34--The first half of a process executed by the data retrieval unit. PA1 FIG. 35--The second half of the process executed by the data retrieval unit. PA1 FIG. 36--Process executed by the search report transfer unit. PA1 FIG. 37(A)--Process executed by the command parser. PA1 FIG. 37(B)--Process executed by the activation request unit. PA1 FIG. 37(C)--Process executed by the reactivation request unit. PA1 FIG. 38--Process executed by the communication controller. PA1 FIG. 39--Process executed by the server management unit. PA1 FIG. 40--The first part of a process executed by the data registration unit. PA1 FIG. 41--The second of the process executed by the data registration unit. PA1 FIG. 42--The first part of a process executed by the data retrieval unit. PA1 FIG. 43--The second part of the process executed by the data retrieval unit. PA1 FIG. 44--The third part of the process executed by the data retrieval unit. PA1 FIG. 45--Process executed by the search report unit. PA1 (A) Primary Server Activation Process, PA1 (B) Secondary Server Activation Process, PA1 (C) Data Registration Process, PA1 (D) Data Retrieval Process, and PA1 (E) Data Restoration Process. Part PAR_3: While FIG. 1 only illustrates a plurality of secondary areas 3a to 3m constituting the primary area 2a, the other primary areas 2b to 2n also have their own subordinate secondary areas, in each of which a secondary server is disposed. Likewise, the primary servers 4b to 4nactually have their own primary and secondary transformation unit, although FIG. 1 only shows a single set of primary and secondary transformation units 6 and 7 disposed in the server 4a. Further, other secondary servers 5b to 5m have their own secondary transformation units, although FIG. 1 only shows the secondary transformation unit 8 disposed in the secondary server 5a. Part PAR_4: As such, the secondary transformation units are disposed in every primary server and secondary server. Note that their content is specific to each primary area; i.e., the primary server governing a specific primary area and its subordinate secondary servers share the same content (or algorithms, actually) in their respective secondary transformation units, as will be illustrated in later part of the description. Part PAR_5: Now, in the above-described structural arrangement, it is supposed that a terminal located in the secondary area 3a, for instance, is attempting to newly enter some registration data that consists of a search keyword and a data object to be shared in the network. This new registration data will be saved not only in the secondary server 5a, but also in another secondary server deployed in the primary area 2a, and further in a secondary server deployed in a different primary area. More specifically, the secondary server 5a, having received a data registration request from a terminal, first stores the received registration data into its local storage. At the same time, the secondary server 5a identifies another secondary server in the primary area 2a by using its own secondary transformation unit 8, and requests the identified secondary server to store the same registration data in its data storage. The appointed secondary server stores the registration data as requested. The secondary server 5a further sends a request for the data registration to the primary server 4a governing the primary area 2a where the secondary server 5a is located. Upon receipt of this request, the primary server 4a determines another primary server by using its own primary transformation unit 6 and requests the determined primary server to store the same registration data. Having received this request, the primary server identifies a secondary server in its own coverage area by using its secondary transformation unit and requests it to store the registration data. The secondary server stores the registration data as requested by the primary server. Part PAR_6: In this way, the data registration process is conducted in the following three stages: (1) registration in a secondary server that has accepted a data registration request from a terminal, (2) registration in another secondary server located in the same primary area, and (3) registration in still another secondary server located in a different primary area. The system conducts data registration in such a 3-stage process where registration data traces the logical hierarchy of data management servers, thus enabling the same data objects to be registered in a distributed manner over the network. Part PAR_7: In the present invention, data retrieval is carried out by tracing just the same hierarchical path. Suppose, for instance, that a terminal located in the secondary area 3a has sent a data retrieval request to the secondary server 5a, along with a specific search keyword. Upon receiving this request, the secondary server 5a tries to search its own data storage by using the given search keyword information. If no match is found, then the secondary server 5a identifies another secondary server in the same primary area 2a by activating its own secondary transformation unit 8 and requests the identified server to make a search. That secondary server attempts to retrieve a record relevant to the given search keyword, as requested by the secondary server 5a. If it is still unable to find such a record, the secondary server, now acting as an agent for the secondary server 5a, sends the data retrieval request to the primary server 4a in the same primary area 2a. The primary server 4a forwards the request to another primary server that is identified by using its own primary transformation unit. That primary server further forwards the request to a secondary server that is found within its own coverage area by using a secondary transformation unit of its own. The secondary server searches its local data storage as requested by the primary server. Part PAR_8: The above-described data retrieval process can be summarized in the following three stages: (1) search in a secondary server that has accepted a data retrieval request from a terminal, (2) search in another secondary server located in the same primary area, and (3) search in still another secondary server located in a different primary area. This hierarchical network search will reach the desired record by executing at most three stages. Part PAR_9: Now, the present embodiment of the invention will be described in further detail below, by presenting a specific implementation in an ATM-ARP server. This ATM-ARP server provides ATM address resolution services in an ATM-LAN system which interconnects the existing LANs and public ATM network. Here, each IP address should be interpreted into physical ATM address when delivering messages over the ATM network. Part PAR_10: FIG. 2(A) shows a network divided into a plurality of areas at a first step. FIG. 2(B) shows the same network further subdivided into a plurality of smaller areas at a second step. More specifically, the network's coverage area is segmented into three "primary areas" at the first step, and three servers 10, 20, and 30 are deployed in the three divided areas, respectively. Those servers 10, 20, and 30 are referred to as "primary servers." At the second step, each individual primary area is further segmented into three "secondary areas." Data management servers 110, 120, 130, 210, 220, 230, 310, 320, and 330 are each deployed in those smaller areas as FIG. 2(B) shows, which servers are referred to as "secondary servers." To govern the primary servers 10, 20, and 30, there is provided a system supervisory server 0. Although FIG. 2(B) only depicts a limited number of terminals 40, 41, 50, 60, and 70, many terminals are distributed in each secondary area. Part PAR_11: FIG. 3 is a block diagram showing the internal structure of the system supervisory server 0, primary server 10, secondary server 110, and terminal 40, where the secondary server 110 and terminal 40 reside in the same secondary area, as part of the primary area governed by the primary server 10. When the terminal 40 has encountered an event that needs data registration, its data registration request unit 400 issues a data registration request message. The data to be registered here actually consists of a data object, the body of a record, and search keyword information that allows the record to be retrieved from target data storage. In the present context of the ATM-ARP server application, the registration data is a set of IP and ATM addresses, where the IP address serves as a search keyword. When a request for data retrieval has arisen in some process in the terminal 40, a data retrieval request unit 401 issues a data retrieval request message. FIG. 3 depicts internal commands 402 and external commands 403 which respectively represent an internal process and an external process that may raise such requests. Part PAR_12: The system supervisory server 0 has an activation verification unit 00 to respond to some messages that fall under "server activation message class", which include activation request and reactivation request messages. It also has a server management unit 01 that accepts messages under "server management message class" and extracts necessary server information from them. This class of messages actually include secondary server information messages and secondary server substitution messages. The extracted server information is saved into a server information storage 02. Part PAR_13: The primary server 10 comprises several functional units and local data storage as described below. An activation request unit 100 issues activation request messages, while a reactivation request unit 101 issues reactivation request messages. An activation verification unit 102 processes messages under "server activation message class" (i.e., activation request or reactivation request messages) when they are received. A server management unit 103 receives messages under "server management message class" (i.e., activation response messages, reactivation response messages, primary server information messages, primary server restoration messages, secondary server restoration messages, and primary server substitution messages), and extracts necessary server information from them. A data registration unit 104 receives messages under "data registration message class" (i.e., extra data registration request messages, data registration request messages, replicated data registration request messages, extra data restoration messages, and remote backup data restoration messages) and performs data registration tasks according to them. A data retrieval unit 105 receives messages that fall under "data retrieval message class" (i.e., data retrieval request messages, replicated data retrieval request messages, and data restoration request messages) and performs data retrieval tasks according to them. A search report transfer unit 106 receives messages under "search report message class" (i.e., "data found" and "data not found" messages) and performs data transfer tasks according to them. A command script 107 is a program script that instructs activation or reactivation of servers. A command parser 108 parses this script 107 and activates the activation request unit 100 or reactivation request unit 101. A primary hash function unit 109 and secondary hash function unit 111 are used to obtain a primary and secondary server identifiers, respectively, from a given search keyword. Local backup data storage 112 stores such records that have been delivered in extra data registration request messages. Here, the term "local backup data" denotes that the data stored in this storage 112 is replicas of the original registration data that is stored in secondary servers located in the same primary area. Remote backup data storage 113 saves, as a measure of precaution, such records that have been delivered in replicated data registration request messages. Here, the term "remote backup data" denotes that the data stored in this storage 113 is replicas of the original registration data that is stored in secondary servers located in remote primary areas. A server information storage 114 stores server information (i.e., parameters for network connection) extracted by the server management unit 103. Part PAR_14: Similarly to the primary server 10, the secondary server 110 comprises the following functional units and information storage. An activation request unit 1100 issues activation request messages, while a reactivation request unit 1101 issues reactivation request messages. The server management unit 1102 receives messages that fall under "server management message class" (i.e., activation response messages, reactivation response messages, secondary server information messages, secondary server restoration messages, primary server substitution messages, and secondary server substitution messages), and extracts necessary server information from the received messages. A data registration unit 1103 receives messages under "data registration message class" (i.e., data registration request messages, local replicated data registration request messages, remote replicated data registration request messages, extra data restoration messages, regular data restoration messages, local replicated data restoration messages, and remote replicated data restoration messages), and enters given registration data to appropriate data storage in accordance with the message types. A data retrieval unit 1104, in turn, receives messages under "data retrieval message class" (i.e., data retrieval request messages, local replicated data retrieval request messages, remote replicated data retrieval request messages, data restoration request messages, and extra data restoration request messages). It retrieves requested records from data storage relevant to the message types. When a message under "search report message class" (i.e., "data found" or "data not found" messages) is received, a search report unit 1105 reports the search results to the requesting terminal, based on a network connection obtained from the search keyword information. It also sends a search report when the secondary server 110 has received a data retrieval request message directly from a terminal and has successfully completed the requested data retrieval by itself. A command script 1106 is a program script that instructs activation or reactivation of servers. A command parser 1107 parses the script and triggers the activation request unit 1100 or reactivation request unit 1101. A secondary hash function unit 1108 is used to calculate a secondary server identifier from a given search keyword. Part PAR_15: Regular data storage 1109 is the first place to store the data contained in the data registration request messages when they are directly received from terminals. Local replicated data storage 1110 registers information, when local replicated data registration request message are received. Here, the term "local replicated data" denotes that the data stored in this storage 1110 is replicas of the original registration data that is stored in other secondary servers located in the same (or local) primary area. In contrast to this, remote replicated data storage 1111 is used to save information extracted from remote replicated data registration request messages when they are received. The term "remote replicated data" denotes that the data stored in this storage 1111 is replicas of the original registration data that is stored in other secondary servers located in some remote primary areas. The server information storage 1112 stores server information extracted by the server management unit 1102. Part PAR_16: The terminal 40 and servers 0, 10, and 110 transmit and receive messages through their respective communication controllers 404, 03, 115, and 1113. They are triggered by internal functional blocks when transmitting messages, while being activated by a communication medium 90 when receiving messages. FIG. 3 schematically shows this communication medium 90 as a network environment including various interface devices, circuit switching equipment, and transmission media for local area and wide area networks. Part PAR_17: FIG. 5 shows a table of ATM addresses assigned to the servers. The primary servers 10, 20, and 30 and the secondary servers 110, 120, 130, 210, 220, 230, 310, 320, and 330 function as ATM-ARP servers which maintain the records of IP-ATM address pairs to allow an ATM address to be retrieved by entering a specific IP address as a search keyword. Part PAR_18: The present embodiment deploys a plurality of ATM-ARP servers on an ATM network and they frequently communicate with each other through ATM connections between servers. It is thus preferable to pre-establish some Permanent Virtual Connections (PVCs) to interconnect the servers in the network. FIG. 4 illustrates a typical configuration of such a network where PVCs have been established. Part PAR_19: FIGS. 6(A) and 6(B) show what information is stored in the primary server 30 and secondary server 330, concerning the above-described PVCs established in the network. Part PAR_20: FIGS. 7 to 16 show the formats of various messages exchanged between servers, or between terminals and servers, as listed below: Part PAR_21: FIGS. 17 to 20 illustrate the contents of each data storage prepared in the servers for some specific purposes as listed below: Part PAR_22: FIGS. 21 to 23 are flowcharts which show various processes executed in the terminals. Part PAR_23: FIGS. 24 to 27 are flowcharts which show various processes executed in the system supervisory server 0. Part PAR_24: FIGS. 28(A) to 36 are flowcharts which show various processes executed in each primary server. Part PAR_25: FIGS. 37(A) to 45 are flowcharts which show various processes executed in each secondary server. Part PAR_26: Referring now to the above flowcharts, the operation of the data management system will be described below. The explanation will be provided in five separate sections, which include: Part PAL: Although above-listed flowcharts of FIGS. 21 to 45 describe the operation of each individual functional unit employed in the terminals or servers, the explanation for the processes (A) to (E) will proceed by referring simultaneously to a plurality of flowcharts. Part PAR_27: As a background knowledge, the following few paragraphs present a brief description of hash functions used in the present embodiment, assuming the area division illustrated in FIG. 2. Generally, hash function is a transformation that takes a variable-size input (a search keyword in the present case) and returns a fixed-size string, which is called the hash value. In the present invention, the data management servers use two kinds of hash functions called "primary hash function" and "secondary hash function." It is noted here that all primary servers commonly use the same primary hash function, while each primary server and its subordinate secondary servers (i.e., secondary servers in that server's primary area) share a common same secondary hash function of their own. In other words, the primary and secondary servers in different primary areas use different secondary hash functions. Part PAR_28: The primary hash function, commonly used by the primary servers, produces the primary hash value by processing a given search keyword in the following way, based on the number of primary areas (="3") and the number of secondary areas (="3"). First, the given search keyword, now being treated as a binary value, is divided by "3." A constant value of "1" is then added to the remainder of that division, thus obtaining the primary hash value. The secondary hash function commonly used in the primary area of the primary server 10 divides a given search keyword by 2 (i.e., applying a 1-bit right-shift operation to the binary dividend) and further divides the quotient by 3. Lastly, a constant value of 1 is added to the remainder of the second division, thereby yielding the secondary hash value. The secondary hash function commonly used in the primary server 20's primary area divides a given search keyword by "4" (i.e., applying a 2-bit right-shift operation to the binary dividend) and further divides the quotient by 3. Then, a constant value of 1 is added to the remainder of the second division, thereby yielding the secondary hash value. Likewise, the secondary hash function commonly used in the primary server 30's primary area first divides a given search keyword by "8" (i.e., applying a 3-bit right-shift operation to the binary dividend), further divides the quotient by "3," and adds a constant value of "1" to the remainder of the second division, thereby yielding the secondary hash value. Part PAL_2: (A) Primary Server Activation Process Part PAR_29: This process allows primary servers to start operations as active ATM-ARP servers in the network. For an illustrative purpose, it is assumed here that the system supervisory server 0 has already activated the primary servers 10 and 20 by sequentially processing the activation requests sent from them, and has confirmed their activation. The system supervisory server 0 employs a counter that represents how many primary servers have been activated. This "primary server activation counter," or "primary counter" for short, now indicates a value of "2" since the primary servers 10 and 20 are serving. Part PAR_30: (A-1) The system administrator enters an activation command to the primary server 30. This command triggers the activation request unit in the primary server 30 to execute the sequence shown in FIG. 28(B), thus activating the communication controller to transmit an activation request message to the system supervisory server 0. Part PAR_31: (A-2) The communication controller 03 in the system supervisory server 0 receives and identifies this activation request message (FIG. 24). Since the received message belongs to the server activation message class, the process is handed over to the activation verification unit 00, which executes a process shown in FIG. 25. The activation verification unit 00 increments the primary server activation counter by one (FIG. 17). It then assigns the resultant counter value of "3" to the primary server 30 as its primary server identifier. The system supervisory server 0 activates its communication controller to supply the primary server 30 with an activation response message to inform of the identifier assigned thereto and primary server information messages which contain information about the primary servers 10 and 20 that have been activated already. The contents of the latter message are referred to as the "primary server information," which describes the network address and identifier of each working primary server. In addition, the system supervisory server 0 activates its communication controller 03 again to transmit a primary server information message to the primary server 10 and the primary server 20, which message conveys the primary server information (i.e., network address and primary server identifier) concerning the primary server 30 that has just been activated. Part PAR_32: (A-3) In the primary servers 10 and 20, their respective server management units extract necessary information from the received primary server information message, and stores it into their server information storage (FIG. 32). In the primary server 30, on the other hand, its server management unit receives the activation response message and primary server information messages from the system supervisory server 0, and stores necessary information extracted from these messages into its server information storage (FIG. 32). Part PAR_33: The primary server activation process described above develops a table of primary server information in each primary server, as well as in the system supervisory server 0. FIGS. 46(A) and 46(B) illustrate the contents of such server information storage in the system supervisory server 0, and that in the primary server 30, after all primary servers 10, 20, and 30 has become active. Part PAL_3: (B) Secondary Server Activation Process Part PAR_34: This process allows secondary servers to start operations as active ATM-ARP servers in the network. For illustration, it is assumed here that the primary server 10 has already activated the secondary servers 110, 120, and 130 by sequentially processing the activation requests sent from them, and. has confirmed their activation. Likewise, it is assumed that the primary server 20 has activated the secondary servers 210, 220, and 230, and that the primary server 30 has activated the secondary servers 310 and 320 in the same manner. Further, it is noted that each primary server has a counter that represents how many secondary servers have been activated (FIG. 18). This counter is referred to as a "secondary server activation counter," or "secondary counter" for short. Part PAR_35: (B-1) The system administrator enters an activation command to the secondary server 330. In response to this command, the secondary server 330 makes its activation request unit execute the sequence of FIG. 37 (B) , thus activating the communication controller to transmit an activation request message to the primary server 30. Part PAR_36: (B-2) The communication controller in the primary server 30 receives and identifies this activation request message (FIG. 29). Since it is a message that belongs to the server activation message class, the process is handed over to the activation verification unit (FIG. 30). The activation verification unit in the primary server 30 increments a relevant secondary server activation counter by one. It then assigns the resultant counter value of "3" to the secondary server 330 as its secondary server identifier. The primary server 30 activates its communication controller to supply the secondary server 330 with an activation response message which includes the identifier assigned thereto, as well as a plurality of secondary server information messages which convey the information about the secondary servers 310 and 320 that have been already activated. The contents of the latter message are referred to as the "secondary server information," which describes the network address and identifier of each working secondary server. Further, the primary server 30 activates its communication controller to send another secondary server information message to the other secondary servers 310 and 320 in the same primary area, as well as to the system supervisory server 0. This message notifies them of the network address and secondary server identifier of the secondary server 330 which has newly joined the present data management system. Part PAR_37: (B-3) The server management unit in the system supervisory server 0 and those in the secondary servers 310 and 320 receive the secondary server information message concerning the secondary server 330, and stores necessary information extracted from the message into their own server information storage (FIGS. 27 and 39). The server management unit in the secondary server 330 also extracts necessary information from the received activation response message and secondary server information messages, and stores the extracted information into its own server information storage (FIG. 39). Part PAR_38: The above-described secondary server activation process allows relevant secondary server information to be distributed and stored in all primary servers, secondary servers, and system supervisory server. FIGS. 47(A), 47(B), and 47(C) illustrate the contents of the server information storage in the system supervisory server 0, primary server 30, and secondary server 330, respectively, while assuming that the activation of all secondary servers has been completed. Part PAL_4: (C) Data Registration Process Part PAR_39: This process allows terminals to register data to the data management servers. For illustration, it is assumed here that all secondary servers in the system have just been started up and no registered records are available in their data storage. It is also supposed that the terminal 40, located in the secondary area of the secondary server 110, is now attempting to register a piece of network address information, "IP ADDRESS=5" and "ATM ADDRESS=55." Part PAR_40: (C-1) Based on its internal or external command script, the terminal 40 executes a process shown in FIG. 21 to send a data registration request message (see FIG. 14) to the secondary server 110 through its communication controller. Here, the data registration request message contains registration data of "IP ADDRESS=5" and "ATM ADDRESS=55." Part PAR_41: (C-2) Upon arrival of this data registration request message at its communication controller, the secondary server 110 performs a process of FIG. 40 by activating its data registration unit that is responsible for the data registration message class. With the received message recognized as a data registration request message, the data registration unit selects a process flow of F403, where the secondary server 110 applies its secondary hash function to the search key record, or the IP address "5" extracted from the message. More specifically, it shifts the binary number "101" (IP address "5") by one bit to the right direction, divides the result by "3," and adds "1" to the remainder. This calculation yields a secondary hash value of "3," which is used as a secondary server identifier. The data registration unit then increments the regular data counter by one, and stores the registration data, together with the secondary server identifier "3" obtained through the above hash calculation, to a specific data field of the regular data storage as pointed by the regular data counter. Here, the registration data actually contains an IP address to serve as a search keyword and an ATM address to be searched for. Part PAR_42: The secondary server 110 then compares the above second hash value "3" with its own second server identifier "1" to determine whether the hash value indicates itself or not. Because they do not match, the data registration unit assembles a local replicated data registration request message on the basis of the data registration request message in process. This message, having a value of "1" in its requester's second server identifier field, is transmitted by the communication controller toward the secondary server 130 whose secondary server identifier is known to be "3." The data registration unit further creates another data registration request message having a value of "1" in its requester's second server identifier field (see FIG. 13) and transmits it to the primary server 10 by activating the communication controller. Part PAR_43: (C-3) The secondary server 130 receives the local replicated data registration request message through its communication controller, and starts a process shown in FIG. 40 by activating its data registration unit. Since the received message is identified as a local replicated data registration request message, it takes a process flow of F404, whose main part is shown in FIG. 41. According to this F404, the data registration unit increments the local replicated data counter by one and stores the registration data, together with the requester's secondary server identifier "1," to the local replicated data storage as pointed by the counter. Part PAR_44: (C-4) The primary server 10 receives the data registration request message through its communication controller, and executes a process shown in FIG. 33 by activating its data registration unit to handles the data registration message class. On identifying the received message as a data registration request message, the data registration unit selects a process flow of F333, where the aforementioned primary hash function is applied to the given IP address "5" extracted from the message as a search keyword. More specifically, it divides the IP address value of "5" by "3," and adds "1" to the remainder, thus yielding a primary hash value of "3." This hash value is then compared with the primary server 10's identifier "1." Because they do not agree with each other, the data registration unit produces a replicated data registration request message on the basis of the data registration request message in process. This message, containing a value of "1" in its requester's primary server identifier field, is transmitted by the communication controller to the primary server 30 whose primary server identifier is known as "3." Part PAR_45: (C-5) The primary server 30 receives the replicated data registration request message through its communication controller, and executes a process shown in FIG. 33 by activating its own data registration unit that is responsible for the data registration message class. Since the received message is a replicated data registration request message, the data registration unit takes a process flow of F334, where the primary server 30's secondary hash function is applied to the IP address "5" extracted from the message as a search key record. More specifically, it right-shifts the binary number "101" (IP address "5") by three bits, divides the result by "3," and adds "1" to the remainder. This calculation yields a secondary hash value of "1," which is used as a secondary server identifier. The data registration unit then increments the remote backup data counter by one and stores the registration data and the obtained secondary server identifier "1" to the remote backup data storage as pointed by the remote backup data counter. Further, the primary server 30 assembles a remote replicated data registration request message based on the received replicated data registration request message, and activates its local communication controller to send the message to the secondary server 310 whose secondary server identifier is known to be "1." Part PAR_46: (C-6) The secondary server 310 receives this request message through its communication controller, and starts a process shown in FIG. 40 by activating its local data registration unit that is responsible for the data registration message class. Since the received message is identified as a remote replicated data registration request message, the data registration unit selects a process flow of F405, whose main part is shown in FIG. 41. In F405, the data registration unit increments the remote replicated data counter by one, and stores the registration data and its own secondary server identifier "1" to the remote replicated data storage as pointed by the remote replicated data counter. Part PAR_47: Now, the next two paragraphs present another example of data registration process. It is assumed here that the terminal 60 is uploading a piece of network address information, "IP ADDRESS=4" and "ATM ADDRESS=54" to the secondary server 130 for data registration. Upon receipt of a data registration request message, the secondary server 130 obtains a secondary hash value of "3" from the IP address value "4" contained in the message. It then saves the registration data into its regular data storage, along with the above secondary hash value "3." Since this hash value agrees with its own identifier, the secondary server 130 further stores the same data into its local replicated data storage (F403 in FIG. 40). Part PAR_48: After that, the secondary server 130 activates its communication controller to send an extra data registration request to the primary server 10. This extra step allows another replica of the registration data to be entered into the local backup data storage in the primary server 10 (F331 in FIG. 33). The subsequent hash calculation in the primary server 10 leads to a primary hash value of "2," which causes the transmission of another replicated data registration request message to the primary server 20. This replicated data registration request message delivers the original registration data (i.e., "IP ADDRESS=4" and "ATM ADDRESS=54") to the remote backup data storage in the primary server 20, as well as causing a remote replicated data registration request message to the secondary server 220 (F334 in FIG. 33). More specifically, the data registration unit in the primary server 20 shifts the binary number "100" (IP address "4") by two bits to the right direction, divides the result by "3," and adds "1" to the remainder. This calculation yields a secondary hash value of "2" indicative of a specific secondary server 220 in the same primary area. Accordingly, the primary server 20 sends a remote replicated data registration request message, so that the secondary server 220 will save the registration data into its remote replicated data storage. Part PAR_49: The following paragraphs presents still another example of the data registration process. Suppose that the terminal 50 is attempting to register a piece of address information, "IP ADDRESS=12" and "ATM ADDRESS=62," to the secondary server 120. The secondary server 120 saves the registration data into its regular data storage. The IP address value "12" derives a secondary hash value of "1" in this case, thus causing the registration data to be transferred to the secondary server 110 for registration in its local replicated data storage. The IP address value "12" also leads to a primary hash value of "1" in this context, which causes the registration data to be transferred to the primary server 10 within the same primary area for registration in its remote backup data storage. This data registration triggers another message transmission to the secondary server 110 so that the same registration data will be stored in its remote replicated data storage. Part PAR_50: The above explanation has exemplified three data registration requests and their processes. FIGS. 48(A) to 48(E) and 49(A) to 49(C) totally show the resultant data contents in the primary and secondary servers' local data storage. Here, the secondary servers 210, 230, 320, and 330 are not included, because no data registration has happened to their local data storage in the above-described three processes. Part PAR_51: More specifically, FIG. 48(A) shows the contents of the local backup data storage and remote backup data storage in the primary server 10. FIG. 48(B) shows the contents of the local backup data storage and remote backup data storage in the primary server 20. FIG. 48(C) shows the contents of the local backup data storage and remote backup data storage in the primary server 30. FIG. 48(D) shows the contents of the regular data storage, local replicated data storage, and remote replicated data storage in the secondary server 110. FIG. 48(E) shows the contents of the regular data storage, local replicated data storage, and remote replicated data storage in the secondary server 120. Part PAR_52: FIG. 49(A) shows the contents of the regular data storage, local replicated data storage, and remote replicated data storage in the secondary server 130. FIG. 49(B) shows the contents of the regular data storage, local replicated data storage, and remote replicated data storage in the secondary server 220. FIG. 49(C) shows the contents of the regular data storage, local replicated data storage, and remote replicated data storage in the secondary server 310. Part PAL_5: (D) Data Retrieval Process Part PAR_53: This process allows terminals to make access to the registration data in the ATM-ARP servers. Since the actual process flow may vary, depending on the locations of original sources of address information, the following explanation is divided into four parts, Cases (1) to (4). All those cases assumes that the data contents shown in FIGS. 48(A) to 48(E) and 49(A) to 49(C) have been developed in those servers through the data registration processes described in section (C). Part PAR_54: CASE (1) Part PAR_55: CASE (1) describes such a situation that the information that a terminal is looking for is what was originally registered by another terminal located in the same secondary area. Suppose, for example, that a terminal 41 is now trying to communicate with another terminal 40 having an IP address "5" without knowing its ATM address. Part PAR_56: (D-1-1) Due to the lack of knowledge about the destination ATM address, the terminal 41 executes a data retrieval process of FIG. 22. That is, the data retrieval request unit creates a data retrieval request message with a search keyword value of "5" and activates the communication controller to send the message to the secondary server 110. Part PAR_57: (D-1-2) The secondary server 110 receives this request message through its communication controller, and executes a process of FIG. 42 by activating its data retrieval unit that is responsible for the data retrieval message class. Since the received message is identified as a data retrieval request message, the data retrieval unit takes a process flow of F423, whose main part is shown in FIG. 43. In F423, the data retrieval unit extracts a search keyword "5" from the request message, saves this search keyword and the connection identifier for the terminal 41 for later use, and then searches the regular data storage for a record relevant to the extracted search keyword "5." In CASE (1), this search successfully ends up with a record containing "IP ADDRESS=5" (search keyword) and "ATM ADDRESS=55" (retrieved data). Then, according to the flowchart of FIG. 45, the search report unit produces a "data found" message with the format of FIG. 16 to inform the requesting terminal 41 of the successful search result. It obtains the connection to the terminal 41 from the search keyword "5" and transmits the "data found" message to the requesting terminal 41 by activating the communication controller. Part PAR_58: CASE (2) Part PAR_59: CASE (2) describes such a situation that the information that a terminal is looking for is what was originally registered by another terminal located in another secondary area as part of the same primary area. Suppose, for example, that a terminal 50 is trying to communicate with another terminal 40 having an IP address "5" without knowing its ATM address. Part PAR_60: (D-2-1) Due to the lack of knowledge about the destination ATM address, the terminal 50 executes a data retrieval process according to the flowchart of FIG. 22. That is, the data retrieval request unit in the terminal 50 creates a data retrieval request message with a search keyword of "5" and activates the communication controller to send the message to the secondary server 120. Part PAR_61: (D-2-2) The secondary server 120 receives this data retrieval request message through its communication controller, and initiates a process of FIG. 42 by activating its data retrieval unit that deals with the data retrieval message class. Since the received message is identified as a data retrieval request message, the data retrieval unit takes a process flow of F423, whose main part is shown in FIG. 43. In F423, the data retrieval unit first extracts a search keyword "5" from the request message, saves this search keyword and the connection identifier for the terminal 50 for later use, and then searches its own regular data storage for a record relevant to the extracted search keyword "5." In this CASE (2), however, this search ends up with no matches. The data retrieval unit then applies its secondary hash function to the search keyword "5," thus obtaining a secondary hash value of "3." Since this secondary hash value "3" does not match with its own secondary server identifier "2," the secondary server 120 produces a local replicated data retrieval request message (FIG. 13) on the basis of the data retrieval request message in process. This new message, having a value of "2" in its secondary server identifier field, is transmitted by the communication controller to another secondary server 130 whose secondary server identifier is known to be "3." Part PAR_62: (D-2-3) The secondary server 130 receives this message through its communication controller, and executes a process shown in FIG. 42 by activating its data retrieval unit that is responsible for the data retrieval message class. Since the received message is identified as a local replicated data retrieval request message, the data retrieval unit in the secondary server 130 takes a process flow of F424, whose main part is shown in FIG. 43. In F424, the data retrieval unit extracts a search keyword "5" from the request message, and searches its local replicated data storage to find a record relevant to the extracted search keyword "5." Since this search successfully ends up with a record containing "IP ADDRESS=5" (search keyword) and "ATM ADDRESS=55" (retrieved data), the data retrieval unit produces a "data found" message that contains the detailed search results. This "data found" message is transmitted by the communication controller to the secondary server 120, which is identified as the requesting server by the secondary server identifier "2" found in the received message. Part PAR_63: (D-2-4) The secondary server 120 receives this message through its communication controller, and executes a process shown in FIG. 45 by activating its search report unit that is responsible for the search report message class. The search report unit converts the received message to the format used for returning search results from servers to terminals (FIG. 16). It obtains a network connection to reach the requesting terminal 50 by using the search keyword "5" and then activates the communication controller to transmit the converted "data found" message to the requesting terminal 50. Part PAR_64: CASE (3) Part PAR_65: CASE (3) describes such a situation that the information that a terminal is looking for is what was originally registered by another terminal located in a different primary area. Suppose, for example, that a terminal 70 is trying to communicate with another terminal 40 having an IP
{'bibliographic_information': "{'Patent Number': '062125214', 'Series Code': '9', 'Application Number': '0495514', 'Application Type': '1', 'Art unit': '211', 'Application Filing Date': '19980327', 'Title of Invention': 'Data management system, primary server, and secondary server for data registration and retrieval in distributed environment', 'Issue Date': '20010403', 'Number of Claims': '20', 'Exemplary Claim Number(s)': '1', 'Assistant Examiner': 'Pardo; Thuy', 'Primary Examiner': 'Amsbury; Wayne', 'Number of Drawing Sheets': '50', 'Number of figures': '67'}", 'source_file': './grant/2001/pftaps20010403_wk14.txt', 'source_data': 'USPTO-Grant'}