JPH09167155A - Distributed processing system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To process external characters more than the number of allocated characters for external character by selecting and registering an unregistered code in code data register parts provided at server and client computers to be operated by different code systems. SOLUTION: A server computer 1 to be operated by the 1st code system is provided with a code data register part 10 for registering code data corresponding to the 1st code system, and a client computer 2 to be operated by the 2nd code system is provided with a code data register part 20 for registering code data corresponding to the 2nd code system. Besides, a register part 30 stores the states of registering the code data in the code data register parts 10 and 20. While referring to the register part 30, a register means 40 selects any unregistered code and registers the code data in any one of code data register parts 10 and 20 at least corresponding to the selected code. Thus, external characters more than the number of characters allocated for external characters can be processed by Japanese KANJI(Chinese character) code systems different in code systems.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention, in a distributed processing system composed of a server computer and a client computer, is a conversion specification for centrally managing Japanese external character processing of different code systems in the system and converting codes and external characters. It is a distributed processing system that can uniquely perform.

[0002]

[Prior art]

Conventional example 1. Japanese Patent Application Laid-Open No. 4-225467 discloses a "font processing device" that uses a management table with the latest contents by creating the management table when the power is turned on.

Conventional example 2. The “resource management method and information processing system” disclosed in JP-A-5-6323 is
The second resource required by the document data which is the first resource,
For example, external character font data used in document data,
It describes a technique in which when the insertion data, the fixed form, etc. are present in the client but not in the server, they are read according to the information indicating the location of the second resource and the processing of the first resource is performed without error. However, in this conventional example, no reference is made to the second resource registration method.

Conventional example 3. Similarly, as a conventional technique in which a management table is used to manage the location of other data that is referred to when processing certain data, there is Japanese Patent Laid-Open No. 5-121.
There is a "font server and printer" disclosed in Japanese Patent No. 50. FIG. 43 is a block diagram showing an outline of the circuit configuration of the font server of this conventional example. In the figure,
Reference numeral 821 denotes a master font server, which is the main control unit 83.
1, network control circuit 833, font conversion circuit 8
35, buffer circuit 834, disk controller 83
6. These are connected via a bus 832. Further, the network control circuit 833 communicates with another information processing device, for example, a workstation via the communication cable 811. The magnetic disk 837 connected to the disk controller 836 stores a program for controlling the master font server 821 and data such as character fonts. In addition, a management table 83 describing the location of the character font data
8 is also stored.

FIG. 44 is a diagram showing the structure of the management table. It describes the name of the font file name and which font server these font files are stored in. In the figure, the blank address indicates that the font file is stored in the font server (master font server in this case) that stores the management table. If the font file is stored in another font server, the font server name and address are recorded. The font file “01” and the font file “02” are, for example, specifically a 9-point Mincho type character font file, a 12-point Mincho type character font file, and the like.

Further, FIG. 45 is a configuration diagram of font information transmitted / received to / from the master font server. In the figure, 851 is font information, the requested font file name, the character code to be processed,
It consists of a device identification number indicating the request source. It also contains the error flag used as a response and the address of the font server that stores the font file.

In this conventional example, a management table for storing the location of the character font data, a notification means for searching the management table and notifying the location of the character font, and a character font requested to be transferred are transferred to a designated destination. The transfer means and the like will be described. Further, when requesting character font data, it is possible to request either the entire font file or the required character font data such as one character. Further, according to this conventional example, by arranging a management table in a printer which is a user of character fonts, the location of character fonts can be managed by the printer without requesting a search from the font server. is there. Further, it also mentions that this management table is always updated. In this conventional example, the locations of the character font files are dispersed, and when the character font files are shared in the system, it is possible to avoid the concentration of access to only one font server (master font server) and to use usable characters. It is possible to increase the type and amount of fonts. However, it does not mention the function to register external characters in individual font files.

[0008] In these conventional examples, the fonts held by the server are shared by the information processing devices connected to the network, so that the storage capacity for the fonts can be saved as a whole system, and the fonts can be saved in the own device. The advantage is that you can use fonts that do not exist on the network if they are on the network.

Next, consider a case where an information processing device for data processing registers an external character. Each information processing device
Register the external character when the character you want to use is not prepared in the system. To register an external character, it is first necessary to add a code to the character (data) to be registered. Each information processing device performs a registration operation by assigning a code (not used) that has not been assigned yet to a character (data) that the information processing device wants to register. After creating a document using the newly registered characters, when requesting another information processing device to print the document, information regarding the added characters is also transmitted to the information processing device together with the document in advance, or It is necessary to issue an inquiry request from the information processing device to the information processing device that created the document.

In addition, when a plurality of information processing devices perform arbitrary external character registration, unused codes are respectively allocated within the device itself, so that in the entire system, different characters are allocated to the same code. May occur. As a method to eliminate such inconvenience,
There is a method of dividing file management for each subsystem.

Conventional example 4. The "external character management method in a distributed environment" disclosed in Japanese Patent Application Laid-Open No. 6-131284 discloses a method of maintaining external character consistency between a client and a server.
It is a system that defines external characters only on the client.
In this conventional example, an external character file for each client system is prepared in the server system, and when transmitting / receiving data including the external character between the server system and the client,
Use the external character information of the remote client system managed by the server system. This allows multiple clients to register external characters as needed,
Moreover, it does not affect other clients. In addition, unused checks when assigning codes may be performed for each client.

FIG. 46 is a block diagram showing the configuration of the client system and the server system of this conventional example.
In the figure, 901a is a client system, 901
b is a server system. Reference numeral 902a denotes a local system external character file, 910a a client external character management mechanism, 920a an external character data conversion mechanism, and 930a a communication program. Also, the client system 901a
Has a server information file 903a which records the location information of the server system to which it is connected. In the server system 901b, 930b is a communication program, 920b is an external character data restoration mechanism, 910b is a server external character management mechanism, and 902b is an external character file of a partner system for managing external character data of each connected client system.

Next, the operation will be described. When the external character is updated in the client system 901a and the content of the local system external character file 902a is updated,
The client external character management mechanism 910a refers to the server information file 903a and issues an external character update request to all connected server systems. Server system 9
When the external character update request is received by 01b, the server external character management mechanism 910b detects that the external character file 902b
The file of the requested client system is updated, and the response data is sent to the client system that issued the external character update request. As described above, in this conventional example, if the external system external character files are prepared by the number of client systems connected to the server system and the file is updated in response to a request from the client system, the external system external character file is transmitted between the client system and the server system. Thus, it is possible to obtain the effect that the external character consistency of each client system can be maintained without causing a code mismatch.

FIG. 47 is a diagram showing an example of allocating codes of a partner system external character file in this conventional example.
For example, if one external character file can use a code area of 1 to 300, in this conventional example, the external character file is separately provided for each client, so that each client system can register 300 external characters from 1 to 300. On the other hand, since the clients A, B, and C register different external characters for the code “1”,
There is a problem that the uniqueness of the code cannot be maintained in the system. Code uniqueness means that a code is unique within the system and means only one piece of data.

As a result, the external character defined and used in each client system can transmit / receive data including the external character to / from the server system, and the data including the external character can be processed in the server system. As described above, this conventional example is suitable when each client restricts and manages an arbitrary external character so that it is valid only within its own client system, but within a network including multiple clients and servers. It is not suitable when you want to use common external characters. Further, since it is not intended to share the external character information with other clients, no consideration is given to a method of avoiding double registration with other clients when each client registers an external character.

Further, the above-mentioned conventional example aims at registering and using external characters only in the Japanese Kanji code system of the client computer. FIG.
[Fig. 6] is a diagram showing areas respectively assigned to external characters and characters (internal characters) other than the external characters of the Japanese Kanji code of the client computer. As shown in FIG. 48, the number of characters of external characters that can be registered, that is, the number of available free codes is limited.

[0017]

In the prior art,
As described above, since the external character file is divided for each client, the character registered by one client cannot be used by another client.

Further, in order to share the code in the system, it is sufficient to limit the registration of the external character to only one master server, but this method allows the client to arbitrarily register and update the external character. I couldn't do it, and it wasn't a system with good usability.

Further, in the conventional font server, even if the font (external character) is changed on the font server, there is no function of notifying the client of the change. For this reason, the client may continue to use the old font and the correct display / print result may not be obtained.

Further, in the conventional font server, it is assumed that all clients have the same code system. Therefore, for example, the extended Unix code (EU
C: Extended Unix Code) and Shi
The font server could not be used when there were a mixture of computers adopting ft-JIS code, JIS code, and the like.

Even when a request for using a huge number of external characters occurs due to the contents of data processing, the external characters can be registered in excess of the number of characters allocated for external characters in the Japanese Kanji code system of the client computer. , Could not be used for data processing.

The present invention has been made to solve the above problems, and aims to realize the following points. (1) In the distributed processing system, each client can register and update the code, and at the same time, set the code uniquely in the system. (2) Data (for example, font) created by a client can be used by other clients. (3) Even if the data (for example, font) in the server computer is changed, the client can use the latest data (for example, font) for the processing (display / print). (4) Data (for example, font) can be commonly used even between clients and servers having different code systems. (5) To obtain a distributed processing system capable of processing external characters in a number greater than or equal to the number of characters allocated for external characters in the Japanese Kanji code system of the client computer.

[0023]

A distributed processing system according to the present invention is characterized by having the following elements. (A) A server computer having a first code data registration unit for registering first code data corresponding to a code in the first code system and operating in the first code system, (b) a second code Second corresponding to the code by the system
First and second client computers having a second code data registration unit for registering the code data of (1), and (c) the first of the first and second code data registration units. And (d) referring to the registration unit that stores the registration state of the second code data, select an unregistered code, and select the code data corresponding to the selected code from the first and second codes. Registration means for registering in at least one of the code data registration units.

The registration means refers to the registration section, selects a code in which the second code data is not registered in the second code data registration section, and selects the second code data corresponding to the selected code. It is characterized in that a client registration means for registering in the second code data registration section of one client computer and updating the registration section is provided.

The registration means further includes a second client computer of the first client computer by the client registration means.
A second means for distributing the second code data registered in the second code data registration section of the second client computer to the second code data registration section of the second client computer. To do.

The registration means further refers to the registration section, selects a code in which the first code data is not registered in the first code data registration section, and selects the first code data corresponding to the selected code. Is registered in the first code data registration section of the server computer, and a server registration means for updating the registration section is provided.

The second code data registration unit registers the second code data using the code of the first code system corresponding to the code of the second code system as a key, and the registration unit stores the second code data. The registration state in the code data registration unit is stored using the code of the first code system, and the client registration means uses the code of the first code system to store the second status.
It is characterized by registering code data of.

The registration section stores a code of the first code system in which the first code data and the second code data are not registered in the first code data registration section and the second code data registration section. An unregistered table to be stored, a code of the first code system in which the first code data is already registered in the first code data registration section, and a second code data is stored in the second code data registration section. First registered
And a registered table for storing codes of the above code system.

The unregistered table stores the unregistered code by using the code of the first code system, and stores the code of the first code system by allocating it to each client computer. .

The registration unit is provided with reconstructing means for reallocating the codes of the first code system allocated to each client computer in the unregistered table.

The distributed processing system further includes the first
And deletion means for simultaneously deleting the second code data from the second code data registration section of the second client computer.

The registered table stores, for each client computer, the registration state of the second code data registration section of each client computer, and the client computer further refers to the registered table to obtain a desired code. When the code data corresponding to is registered in the second code data registration section of the user, the second code data registered in the second code data registration section of the user is used to correspond to the desired code. If the code data is not registered in the second code data registration section of the user,
It is characterized in that the server computer is provided with a utilization means for distributing and using code data corresponding to a desired code.

The distributed processing system includes a database in which at least one piece of data is represented by the respective codes of the first and second code systems, and the registration means includes the database of the first and second code systems. The first and second code data corresponding to each code are registered in the first and second code data registration units.

The utilization means refers to the respective codes of the first and second code systems of the database,
It is characterized in that the first and second code data corresponding to the respective codes of the first and second code systems are inputted from the first and second code data registration sections and used.

[0035]

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiment 1 FIG. FIG. 1 is a diagram showing the configuration of the distributed processing system of this embodiment. In the figure, reference numeral 1 is a server computer (hereinafter sometimes referred to as a server), and 2 is a client computer (hereinafter sometimes referred to as a client). Further, 115 is a client-server system including a server computer 1 and a plurality of client computers 2. FIG. 2 is a diagram showing a configuration example of a resident information system in a local government having a plurality of servers 1 by embodying the distributed processing system shown in FIG.

FIG. 3 is a block diagram showing the configuration of this embodiment. In the figure, 10 is a code data registration unit of the server 1 and 20 is a code data registration unit of the client 2. In this distributed environment, it is assumed that the server 1 and the client 2 use different character code systems. For example, in the server 1, a BUC (Business Uni), which is an extension of the extended Unix code,
x Code) and in client 2
SJIS (Shift JIS) code shall be used. In this case, the code data registration unit 10 registers the code data corresponding to the BUC code, and the code data registration unit 20 registers the code data corresponding to the SJIS code. Reference numeral 30 is a registration unit including an unregistered table 32, a registered table 34, and a reconstructing unit 36. Further, 40 is a registration means including a client registration means 42, a distribution means 44, and a server registration means 46.
Further, 50 is a deleting means, 60 is a using means, and 70 is a database. The database 70 is a database that records data of a business processing system operated by this distributed processing system.

Next, the mapping of different code systems will be described. In a distributed environment, each terminal (client) has a different character code system for Japanese processing, so as an example, a server that uses the BUC code system and an SJI
The conversion specifications of different code systems between clients that use the S code system will be described. FIG. 4 is a diagram showing respective Japanese character code systems of the server and the client. In the figure, reference numeral 110 denotes an (internal character) area (also referred to as a server internal character area) that is a character other than an external character (hereinafter also referred to as a server external character area) 150 among the characters of the server. 21
Reference numeral 1 is an internal character area of the client (client internal character area), and 251 is an external character area of the client (client external character area). The server internal character area 110 and the server external character area 150 correspond to the code data registration unit 10.
The client internal character area 211 and the client external character area 251 correspond to the code data registration unit 20.
As shown in FIG. 4, in BUC and SJIS, BUC has a larger number of characters. Therefore, the mapping as shown in FIG. 5 is performed. Reference numeral 111 denotes a client internal character, which corresponds to the client internal character area 211. Reference numeral 112 is a client-internal character. When the client-compatible internal character 111 and the client-incompatible internal character 112 are combined, the server internal character area 110 shown in FIG. 4 is obtained. Further, reference numeral 151 denotes a client external character, which corresponds to the client external character area 251. Reference numeral 152 is a non-client external character of the server. The client external character 151 and the non-client external character 152 are combined to form the server external character area 150 shown in FIG. When a character (external character) is added or displayed on the client, the area corresponding to the external character 151 corresponding to the client (or the external character area 251 corresponding to the client) uses SJIS, and the area corresponding to the external character 152 not corresponding to the client uses BUC. Further, the character newly added to the area corresponding to the client-supported external character 151 can be used by another client.

Next, a synchronization procedure between clients will be described. First, the case of adding an external character will be described with reference to FIG. FIG. 6 is a diagram for explaining synchronization between clients when adding an external character. FIG. 6 shows a case where three clients are connected. The characters added to the client's external character 151 area on the server
Perform the following process to synchronize with other clients. First, in FIG. 6A, a character is added by the registration unit 40 in the client 2a. FIG.
In, the character "outer" surrounded by a frame represents an external character. Client 2 by client registration means
The character added from a is added to the client external character area 151 on the server and at the same time added to the client external character area 251a on the client 2a. At this point in time, the client external character 151 and the client external character area 251a of the client 2a are the same, but the other clients 2b and 2c are not synchronized. Next, in FIG. 6 (2), a case where the client 2b refers to a character (asynchronous state) will be described. At the time of the above (1), when the character registered in the client 2a is referred to by the client 2b, the utilization means 60 shown in FIG. 3 uses the character registered in the client 2a in the client external character area 251b of the client 2b. Since it does not exist, it is referred from the area of the client-specific external character 151 on the server. Further, when synchronizing with the other client 2c, the area of the client-corresponding external character 151 on the server is set at a preset timing by the distribution unit 44, for example, immediately or at regular intervals, as shown in FIG.
As shown in, the data is transferred to the client external character area 251c (the state of the client 2c). Client 2c that has been transferred to the client's external character 151 area of the server
However, when referring to the character registered in the client 2a, the character registered in the client 2a can be read from the client external character area 251c of the client 2c as shown in FIG. 6 (4) without going to the server. refer.

Next, a synchronization procedure for deleting registered external characters will be described with reference to FIG. FIG. 7 is a diagram for explaining synchronization between clients when deleting an external character. The following processing is performed to synchronize the characters registered in the above procedure when they are deleted. First, FIG. 7 (1)
At, the character is deleted in the client 2a by the deleting means 50. The characters deleted by the client 2a are deleted from the client external character area 151 on the server and also deleted from the client external character area 251a on the client 2a.
At this point in time, the client external character 151 and the client external character area 251a of the client 2a are the same, but the other clients 2b and 2c are not synchronized. Therefore, the client in the state of the client 2c, which is synchronized at the time of registration, has a disadvantage that the font corresponding to the deleted character code is held in its own terminal and can be displayed. next,
Character reference (asynchronous) is explained. Figure 7 above
At the time of (1), when the usage unit 60 refers to the character deleted by the client 2a from the client 2b, the character deleted by the client 2a does not exist in the client external character area 251b of the client 2b. Reference is made from the area of the client-specific external character 151 on the server. However, since the character has already been deleted from the client-compatible external character 151 on the server at this point, the character cannot be displayed and the correct operation is performed. Regarding the client 2c which is synchronized at the time of registration, the area of the client corresponding external character 151 on the server is immediately transferred to the client external character area 251c by the deleting means (state of the client 2c). This process must be done immediately. That is, since the font corresponding to the deleted character code is held in the terminal itself, there is an inconvenience that it can be displayed. In the client in the state of the client 2b, the characters are displayed from the server because the characters are not synchronized at the time of registration, so the external character corresponding to the client on the server is 15
When the character is deleted from the area 1, the display becomes impossible. In the procedure described above, the client in the state of the client 2c synchronized at the time of registration holds the font corresponding to the deleted character code in its own terminal (see the state of (4)). In addition, since it is possible to display, it is necessary to immediately synchronize the area of the client external character 151 of the server.

Next, a method of storing character strings in the database 70 shown in FIG. 3 will be described. In this distributed processing system, both the BUC character string data and the SJIS character string data are stored in the business processing database that is operated. When processing in cooperation with the server, BUC
Both the character string and the SJIS character string are used, but in the client's own processing where the client operates independently,
Since the BUC character string cannot be used, only the SJIS character string is used. As a result, it is possible to perform processing by the client alone and reduce the load on the server in the distributed environment, and at the same time, the server and the client can perform work individually, which improves the utilization efficiency of the user. A method of storing a character string in the database is shown in FIG. The database contains
As shown in FIG. 8, both the BUC character string data and the SJIS character string data are stored. As an advantage of storing both,
There are the following points. First, when the server and the client are connected, the BUC character string can be used to display the official Kanji even if there is no official Kanji in the SJIS of the client. In addition, it is also possible to perform client-only processing. Even when the server and the client are not connected, by storing the data record in the client, the SJIS character string is used and displayed as a simple character string. This makes it possible to continue client-only processing that does not require the display of official kanji. It is also possible to handle data in other applications. Regardless of the connection form of the server and client, even when using an application that can handle only SJIS or BUC, the data of the required character string can be referenced from the database, so the character code corresponding to the application can be used. You can choose. This prevents garbled characters by using either character string that is not compatible with the application.

Next, the timing of synchronization will be described.
In this distributed processing system, the registration states of the code data registration units 10 and 20 are managed using the unregistered table 32 and the registered table 34 shown in FIG. In order to synchronize the external characters registered in multiple clients, send a new candidate list (unregistered table) and fixed part list (registered table) to the server, and merge all of them to create a local font list. create. The new candidate list, fixed part list, and local font list will be described later in detail. Basically, as shown in FIG. 6 (2), the font itself can be obtained by going to the server to obtain the font without using synchronization, but in terms of performance, Will be inferior. Therefore, as the timing of synchronization,
The following three methods are prepared.

The first method is immediate synchronization. As described in the synchronization between the clients at the time of deletion, in the case of the deletion process, if a specific character is deleted by the client 2a and the state in which the other character can be referred to by another client 2c continues, it is used incorrectly. It is possible. In order to prevent this, when deleting a specific character, the server collects the new candidate list and fixed part list of each client immediately after the deletion, reconstructs it, and sends it to each client. However, if you perform instant synchronization entirely, the synchronization process runs every time you register a character (external character), which increases the load in the distributed environment. Therefore, you should use it carefully considering the system load. desirable.

The second method is synchronization at startup. This is a method of synchronizing once every morning when the client and server start up. If this method is adopted, the server collects the new candidate list and fixed part list of each client up to the previous day, rebuilds them, and sends them to each client. This is the case, for example, when issuing a resident card. Normally, when a resident requests the issuance of a resident's card at a window, processing is performed by only one client at that window,
It is unlikely that other clients will perform client-only processing (processing that does not use the server font, for example, processing that uses a client application that cannot communicate with the server) from another client during the same day. Therefore, even if you enter a foreign character when issuing the resident card, it is not necessary to synchronize immediately.
It can be said that it is enough to make it available to other clients after the next day.

The third method is schedule synchronization. This is a setting such that synchronization is always maintained at preset constant intervals. By setting the interval from several minutes to several hours, it becomes possible to synchronize even within the same day.
For example, a certain inhabitant performs transfer processing at the counter, registers certain specific characters (gaiji), and then issues a resident card. If the insured ledger of the National Health Insurance is to be processed by another client alone during the same day, the processing can be performed by synchronizing the schedule.

The management file will be described below. The management of character registration of the client is a management file, that is,
Use the fixed part list, local font list, and new candidate list. The management file is created for each client. First, the client registerable area will be described. FIG. 9 shows details of the client character registerable area. FIG. 9 shows the client external character area 251 in FIG. Client external character area 251
9 is actually divided into an area (fixed portion) 2511 registered in common in the system and a client registrable area 2512 as shown in FIG. External characters that are known to be used in advance are registered in the fixed unit 2511 when the system is introduced. Therefore, the external character newly registered by the user is registered in the client registerable area 2512. FIG. 10 is a diagram showing allocation of Japanese character codes obtained by combining FIGS. 5 and 9. As shown in FIG. 10, the fixed unit 2511 corresponds to the fixed unit 1511 of the server, and the client registrable area 2512 corresponds to the client registrable area 1512 of the server.

Next, an example of a procedure of processing for utilizing characters at the client will be described with reference to a flow chart. 11 and 1
2, FIG. 13 is a flow chart showing a procedure of using characters. First, FIG. 11 will be described. In this distributed processing system, the content of the process is determined depending on which of the areas shown in FIG. 10 the character to be used is registered. First, in S10, it is determined whether the character to be used is the client corresponding internal character 111 (corresponding to the client internal character area 211). If yes,
In S12, the client corresponding internal character 111 (21
Use 1). In S10, when it is not the client corresponding internal character 111, it becomes NO, and in S14,
Client External Character 151 (Client External Character Area 2
It corresponds to 51). If YES, in S16, the client-corresponding external character 151 already registered is used. Gaiji 15 for client
If not 1, it becomes NO in S14 and S18.
At, it is determined whether the internal character 112 is not compatible with the client. YE in case of client-internal character 112
S, and in S20, client-incompatible internal character 1
12 is used. If it is not the client-incompatible internal character 112, the determination is NO, and in S30, the process of using the client-incompatible external character 152 is performed.

The process of using the client-internal character 112 in S20 of FIG. 11 will be further described with reference to FIG. In S22, it is determined whether the client-internal character that is the character to be processed can be registered in the client-specific external character 151. YES if registration is possible
Then, in S24, the corresponding client non-corresponding internal character is registered in the client external character 151 by the client registration means. What is actually registered is the client registrable area 15 in the client-compatible external character 151.
Twelve. If the client-supported external character 151 cannot be registered, the determination result in S22 is NO and S
In 26, the applicable client-internal character is used as it is.

Next, the process of using the client-incompatible external character 152 in S30 of FIG. 11 will be described with reference to FIG. First, in S32, it is determined whether or not the external character 151 corresponding to the client can be registered. In the case of YES, in S34, it is determined whether or not the character to be processed is already registered in the client-incompatible external character 152. If YES, in S36, the registered client non-corresponding external character 152 is registered in the client corresponding external character 151 by the client registration means. S
If NO in 34, in S38, a new character (new character) is registered in the client-specific external character 151. When it is not possible to register in the client compatible external character 151 in S32, the determination result is NO, and it is determined in S40 whether the client compatible external character 152 has already been registered. If YES, in S42, the client-incompatible external character that has already been registered is used. In the case of NO, the server registration means registers the new character in the client non-client external character 152 in S44.

By determining the character usage method in accordance with the above processing procedure, it becomes possible to use all the areas shown in FIG. 10 in this distributed processing system.

Next, the new candidate list will be described. The new candidate list is a file that manages an area in which new characters can be registered on the client. FIG. 14 shows the structure of the new candidate list 320. The meaning of the registration flag is as follows. L: Locally registered S: Server registered U: Unused Registerable code indicates a code that can be registered by the corresponding client. In this embodiment, the list is created by the server side code (BUC code) corresponding to the code that can be registered by the client. When there are a plurality of registrable clients, the registrable area is distributed to the number of clients and a new candidate list is created.
As a result, each client is assigned its own registrable area, and code duplication does not occur in the system.

Next, the local font list will be described. The local font list is a file that confirms the character registration status of the client at the time of reference. FIG. 15 shows the structure of the local font list 330. The meaning of the registration flag is the same as the meaning of the registration flag of the new candidate list 320. The registration status code is registered as a BUC code in the same manner as the registerable code of the new candidate list, and represents the character registration status of the corresponding client. This list integrates all the local font lists of other character registerable clients, and the integrated local font list is redistributed to each client.

Next, the fixed part list will be described. The fixed part list is an area that is registered in the system in advance before the system is activated, and is in the registered state, like the local registered state of the new candidate list described above. FIG. 16 shows the structure of the fixed part list 310. The meanings of the registration flag and the registrable code are the same as those of the new candidate list 320 described above. Since the system is registered in advance, the fixed flag is characterized in that the registration flags are all "L".

Next, the storage location of each management file will be described. The new candidate list 320 is a list for referencing when registering a character and determining whether or not it can be registered. Therefore, although it is necessary to allocate a registerable area to each client, allocation is performed once. Once done, it can be managed by either the client or the server. In the case of storing in each client, when the character is registered in each client, the new candidate list of the own terminal is referred to, and if it can be registered, it is registered. In addition, when storing in the server, when registering characters in each client, it is determined whether or not registration is possible in the own terminal by referring to the new candidate list for oneself stored in the server. . Since the local font list 330 is used when determining whether or not the characters are registered in the terminal when displaying the characters on each client,
It must be stored in each client. The fixed part list 310 is the same as the locally registered state of the new candidate list, and may be included in the new candidate list. Further, when the fixed part list is not included in the new candidate list and separately managed as the fixed part list, it is handled in the same manner as the new candidate list, and therefore may be managed by either the server or the client. FIG. 17 shows an arrangement example of the management file.
FIG. 17 shows the fixed part list 310 and the new candidate list 32.
6 is a diagram showing a case where 0 and a local font list 330 are arranged in the client 2. FIG.

The registration process by the registration means will be specifically described below. First, a client (hereinafter referred to as a registered client) 2a to be registered when the client 2a performs character registration in the client external character area 251 will be described. FIG. 18 is a diagram showing a state of the registration client at the time of character registration. In FIG. 18, (a) is an initial state, (b) is a state in which external characters are added, and (c) is a state after transfer of the local font list. In the initial state shown in FIG. 18A, the registerable area is set to 2512a. At this time, the registration flags of the new candidate list 320a and the local font list 330a are all U (unused). When adding, the registration means refers to the new candidate list 320a, and the code is U (unused) (here, "F001", "F00").
2 "). After the registration is completed, 40 in FIG.
1, 403, L (local registration) is set for the corresponding code in the new candidate list 320a and the local font list 330a. After the registration is completed, the fixed part list (not shown) of each client is merged with the new candidate list 320 to create a new local font list, and the created local font list is distributed (transferred) to all clients. Since the client 2a is a registered client, the new candidate list 32 after transfer is displayed.
0a and the local font list 330a are shown in FIG.
As shown in FIG. 18C, the state is the same as that in FIG. 18B before the transfer.

FIG. 19 is a diagram showing a state of a client (hereinafter, unregistered client) 2b which has not performed character registration. The initial state of FIG. 19A is the same as that of the registration client 2a. Even after the character addition by the client 2a, as shown by 411 and 413 in FIG. 19B, in the non-registered client 2b, the new candidate list 32
The state of 0b and the local font list 330b does not change. After the registration is completed, the local font list created by merging the fixed part list of each client and the new candidate list is distributed to all clients. After this distribution,
The state of all clients is synchronized. As shown by 415 and 417 in FIG. 19C, the new candidate list 320
Both b and the local font list 330b are L (local registration). The codes of the new candidate list and the local font list are F001 to F999 as an example. Note that F001 to F500 are client external characters 151, and F501 to F999 are client external characters 152.

Next, a case will be described in which a character is registered in the client-incompatible external character 152. Character registration to the client-incompatible external character 152 is performed by the server registration means. FIG. 20 shows the client 2a when the client 2a registers in the non-client external character 152.
It is a figure which shows the state of. In the initial state shown in FIG. 20A, all non-client external characters 152 can be registered, and the registration flag of the new candidate list 320a is U (unused). When the addition is performed, the new candidate list 320a is referred to, and the code (here, “F501” and “F502”) that is U (unused) is registered. After the registration is completed, the corresponding code “F501” in the new candidate list 320a and the local font list 330a,
Set S (server registration) for "F502". The state is shown by 421 and 423 of FIG.20 (b). After the registration is completed, the fixed part list of each client and the new candidate list are merged to create a local font list, and the created local font list is distributed to all clients again. The state of each list of the client 2a after distribution is shown in FIG. Since the client 2a is the registered client, the status of each list is 4
25 and 427, it is the same as FIG.

FIG. 21 is a diagram showing a state of the client 2b which has not performed character registration. The initial state of FIG. 21A is the same as that of the registration client 2a. Even after the characters are added by the client 2a, 4 in FIG.
As indicated by reference numerals 31 and 433, in the non-registered client 2b, neither the new candidate list 320b nor the local font list 330b is changed in state. After the registration is completed, the local font list created by merging the fixed part list of each client and the new candidate list is distributed to all clients. After this distribution, the status of all clients will be synchronized. As shown by 435 and 437 in FIG. 21C, the registration flag is S for both the new candidate list 320b and the local font list 330b of the client 2b.
(Server registration).

Next, the flow of registration processing will be described.
FIG. 22 is a flowchart of the registration process. In FIG. 22, a case where a normal character exists in the client internal character area 211 (when the SJIS simple character is a normal character) will be described.
The regular characters here are the correct characters that the user wants to use. First, in 1 of FIG. 22, SJIS simple characters are input from the client. Then in 2,
Convert from SJIS to BUC by a predetermined conversion method,
Generate BUC characters. In this embodiment, SJIS and BUC are used as an example of the code system. However, even if another code system is used, a conversion method corresponding to the code system may be used, and the processing procedure is The same as in this embodiment. Next, it is determined whether or not the generated BUC character, that is, the input SJIS simple character is an authentic character. When the input SJIS simple character is a proper character, the process of 4 is performed. In the process of 4, SJIS character, B
Confirm the UC character. Next, at 5, the character is displayed and the processing using the character is continued. In No. 3, if the character is not a positive character, the processing 1000 when there is no positive character in the client-supported internal character 111 is performed. Details of this processing will be described later.

The above processing will be described using the name input screen. FIG. 23 is a diagram showing a name input screen 500 used for the registration processing of this embodiment. In the figure, 501 is an area for inputting a family name in the kana name input area, and 502 is an area for inputting a first name. 503,5
Reference numeral 04 is an area for displaying the family name and given name of the simple name. Reference numeral 508 is a kanji name display area.

FIG. 24 is a diagram showing the name input screen 500 after performing the process 1 of FIG. Input of SJIS simple characters is performed by a predetermined Japanese input method. As a result, as shown in FIG. 24, predetermined characters are displayed on the kana names 501 and 502 and the simple names 503 and 504. FIG.
5 shows the name input screen 500 in which the generated BUC characters are displayed. BUC displayed in Kanji name area 508
If the character is correct, the process using the character is continued in 5 of FIG. 22 described above.

Next, a case where a regular character exists in the client-internal character 112 of the server will be described. The letter is S
Client non-compliant internal character 11 instead of JIS simple character
FIG. 26 shows a detailed flow chart of the processing (processing 1000 when there is no positive character in the client-corresponding internal character 111) in the case of existing in No. 2 or not created and newly created.
In 6 of FIG. 26, S input in 1 of FIG.
Since the JIS simple characters are not regular characters, enter the BUC code directly. At this time, if there is a true character in the client-incompatible internal character 112 or the client-incompatible external character 152,
Enter the BUC code in regular characters. In the case of a completely new character, the BUC code of the most similar character is input. Next, in 7, the font of the input BUC code is acquired. Next, at 8, the BUC input
Judge whether the characters of the code are orthographic characters. If it is a regular character, the process of 9 is performed. 14 if it is not
Is performed. In the process of 9, since the input BUC code is a proper character, the registration flag of the code is referred to from the local font list. In FIG. 10, when the registration flag is “U”, there is a regular character in the client non-corresponding internal character 112 or the client non-corresponding external character 152, but it is not registered in the client external character 151, that is, in the client external character area 251. Indicates the status. At this time, the process of 11 is performed. If the registration flag is not "U", 12 processing is performed. In No. 11, since the registration flag is “U”, the character is registered in the client-specific external character 151, that is, the client external character area 251. After that, 14 processes are performed. When the registration flag is not “U” and the registration flag is “L” in 12, the character is already registered in the client external character 151, that is, the client external character area 251, and the area is referred to. Show good things. If the registration flag is not "L", the process of 13 is performed. When the registration flag is "S" in 13, the character is already registered in the client non-corresponding external character 152 of the server. This is a client-compatible external character 15
1, the case where the client external character area 251 is tried to be registered, but there is no empty code, and mapping is impossible in the processing 18 described later. At this time, the client-incompatible external character 152 of the server may be referred to. Further, in this embodiment, the processing procedure is configured such that if the registration flag is not "S", it is not possible. This is because the registration flag has no value other than "U", "L", and "S". The process of 14 is the first step of performing the registration process in the client corresponding external character 151 (client external character area 251). Here, the new candidate list is referenced to search for a new registerable code (BUC). Next, at 15, the BUC that can be newly registered
Confirm the code. Subsequently, in 16, the determined new BUC code is converted into a code of the client external character area 251 corresponding to the client external character 151 by a predetermined conversion method. Next, in 17, if necessary, the external character is edited using an external character editor or the like. This process is not necessary if you enter a code for a regular character in the process of 6 above, but if you enter a code for a character that is similar to a regular character, use the pattern of similar input characters. hand,
The external character will be edited. Next, at 18, it is judged whether registration (mapping) is possible in the client external character area 251. If the registration is possible, the process of 19 is performed, and if the registration is not possible, the process of 20 is performed. If the registration is possible, the registration flag corresponding to the new BUC code in the new candidate list and the local font list is set to "L" at 19, and this processing is ended. Figure 2 after the end
Processing 4 of 2 is performed. If it is not possible to register in the process of 18, it is registered in the client non-corresponding external character 152 in 20, so that the new candidate list,
The registration flag corresponding to the new BUC code in the local font list is set to "S", and this processing ends. After the end, the process 4 of FIG. 22 is performed.

The above processing will be described with reference to the drawings.
FIG. 27 is a diagram showing the name input screen 500 when the character is not a proper character. In the figure, it is assumed that the character "hama" shown at 517 is not a proper character, and that it is in the process of inputting a proper character. FIG. 28 shows 6 of FIG.
It is a figure which shows the name input screen 500 at the time of directly inputting a BUC code in the process of FIG. In the figure, 509 is an area for inputting a code or a similar code. When a code is input, the characters corresponding to the input code and its adjacent code are displayed. If there is an orthographic character in the displayed characters, that character is registered as a client external character. A window for confirming whether to replace the SJIS code with the BUC code is displayed on the screen.
FIG. 29 is a diagram showing the name input screen 500 in which the confirmation window 518 is displayed. When the button 520 is pressed while the screen shown in FIG. 29 is displayed, the simplified name displayed in the kanji name area 508 is replaced with the designated character font. FIG. 30 shows a name input screen after the simple name replacement.

Next, the display processing by the utilization means will be described. FIG. 31 is a diagram showing a registered state which is a prerequisite for this display processing. This state is the state already registered in the registration process described above, as shown in FIG.
Same as (c).

Next, details of the display will be described. FIG.
2, FIG. 33 is a flowchart of detailed display processing. First,
In 1 of FIG. 32, the SJIS character string and the BUC character string are acquired from a database or the like. Next, in 2, a character is cut out from the character string and a process for each character is performed. After that, the process up to 15 in FIG. 33 is repeated for the number of characters. In step 3, it is checked whether one of the BUC characters is an external character. In 4, when it is an external character,
6 is performed. If it is not a foreign character, the process of 5 is performed. In No. 5, since it is not an external character, BUC characters and SJ
Since the IS characters differ only in the code system and are not variants (characters in different fonts), the character is displayed in SJIS, which is the client code system. If it is an external character, in 6 the local font list is referenced and the registration flag for that character code is acquired. Next, in 7, when the acquired registration flag is “U”, registration is performed in any part of the client corresponding internal character 111 (client internal character area 211) and the client corresponding external character 151 (client external character area 251). Since it is a character that has not been written, processing of 8 is performed. In No. 8, since the registration flag is “U”, the font is acquired from the client-internal character 112 of the server. 32A, B, C
Are connected to A, B, and C of FIG. 33, respectively. Next, in 9 of FIG. 33, the registration flag is “S”.
If it is, the server does not support client external characters 15
Since 2 indicates that the character is registered, 10
Is performed. If it is not "S", the process of 11 is performed. In No. 10, since the registration flag is "S", the font is acquired from the client-incompatible external character 152 of the server. When the registration flag is “L” in 11, it indicates that the character is registered in the client-specific external character 151 (client external character area 251), and therefore the process of 12 is performed. The registration flag is "U",
Since the value is either "S" or "L", it is not "L". In No. 12, since the registration flag is “L”, the font is acquired from the client-supported external character 151 (client external character area 251). Next, at 13, the SJIS character is once output. Then, in 14, the acquired BUC characters are overlapped and output. In 15, the above process is repeated for the number of characters corresponding to the process of 2.

Next, the deleting process by the deleting means will be described. The deletion process is also performed from the state of FIG. 31 described above, and thus the description thereof is omitted here.
Details of the deletion will be described using a flowchart. FIG.
4, FIG. 35 is a flow chart of detailed deletion processing. First,
In 1 of FIG. 34, the BUC code of the character (external character) to be deleted is input. Next, in 2, the local font list is referenced to acquire the registration flag. In 3,
When the acquired registration flag is “U”, the character to be deleted is not registered in the client-specific external character 151 (client external character area 251), and the process ends without doing anything. Note that D and E in FIG. 34 are connected to D and E in FIG. In 4 of FIG. 35, when the registration flag is “S”, the character to be deleted is registered in the non-client external character 152 of the server, and therefore the process of 5 is performed. In No. 5, since the registration flag is "S", the registration flag of the corresponding character code in the local font list and new candidate list is set to "U". Thereafter, in 6, the font of the corresponding character in the client-incompatible external character 152 of the server is cleared. If the registration flag is “L” in 7, the character to be deleted is registered in the client-specific external character 151 (client external character area 251), so the process of 8 is performed. In No. 8, since the registration flag is "L", the registration flag of the corresponding character code in the local font list and new candidate list is set to "U". In the process of 9, the font of the corresponding character in the client-compatible external character 151 of the server is cleared. Then, in 10, the BUC code is converted into an SJIS code by a predetermined conversion method. Next, in 11, the font of the corresponding character in the client external character area 251 is deleted.

Next, the operation of the management file will be described. First, the initial state will be described. In this embodiment,
Assuming that one server and three character registerable clients are installed, character areas are allocated between the server and clients (plural) as follows. FIG. 36 is a diagram showing a state in which the client registrable area 2511 is divided by the number of clients. In the figure, 2512a is a client 2a, 2512b is a client 2b, 25
Reference numeral 12c indicates a code area assigned to each client 2c. The area used in the system (fixed part) cannot be registered on the client side.

FIG. 37 is a diagram showing a management file for each client in the same state as in FIG. FIG. 38 is a diagram showing a management file of each client immediately after registration by the client 2a, and shows a state when characters are registered as indicated by 600 in the client 2a. In this case, in the new candidate list 320a and the local font list 330a of the client 2a, as shown by 601 and 603, “L” is registered for the corresponding code. At this stage, the local font lists of the client 2b and the client 2c are not updated as indicated by 605 and 607, so when referring to the character registered in the client 2a, the character pattern is acquired from the server.

FIG. 39 is a diagram showing the management file of each client immediately after registration with the client 2b, showing the state when characters are registered as shown by 610 in the client 2b from the state after the above registration. There is. In this case, in the new candidate list 320b and the local font list 330b of the client 2b, as indicated by 613 and 615, “L” is registered for the corresponding code. At this stage, the local font list of the client 2c has not been updated as indicated by 617. Further, since the client 2a and the client 2b are not synchronized, the character pattern is acquired from the server when referring to the character registered in the client 2a or the character registered in the client 2b.

FIG. 40 is a diagram showing the state of the management file of each client after the transfer of the font file and the local font list. FIG. 40 shows the client 2a,
After the character is registered in the client 2b, the font file and the local font list are updated in other clients as well. The font file and local font list of each client are
Each is merged by the server and then updated (6
21, 623, 625, 627). In this state, the clients are synchronized with each other, so that the characters (60
0,610) is 600 even in other clients.
As shown in b, 600c, 610a, and 610c, it is not necessary to acquire the font from the server, and it is possible to display at high speed.

Next, a case will be described in which all the codes assigned to the client 2a are used and registration cannot be performed in the client 2a. Client 2
If characters (external characters) are continuously registered in a, the client 2b, and the client 2c, the registration status progresses asynchronously, so that some clients will exhaust the new candidate list. Here, FIG. 41 shows a case where the client 2a cannot be registered. In the state of FIG. 41, the area of the new candidate list for the client 2a is insufficient, so when the local font list is created by the server, the new candidate list is reconstructed by the reconstructing means, and after the reconstruction. Expand the new candidate list and local font list to each client. Figure 4 shows the state after deployment
It is shown in FIG. As shown in FIG. 42, the reconstructing means uses the code "F5A1" originally assigned to the client 2c.
Of "FEFE", "FA01" to "FEFE" are newly assigned to the client 2a. As a result, the allocation of the client 2c is "F5A1" to "FA00".
Becomes By performing the reconstruction in this way, the external character can be registered from three clients.

[Brief description of the drawings]

FIG. 1 is a diagram showing a configuration example of a distributed processing system of the present invention.

FIG. 2 is a diagram showing an example of a distributed environment to which the distributed processing system of the present invention is applied.

FIG. 3 is a block diagram showing a configuration of a distributed processing system of the present invention.

FIG. 4 is a diagram showing allocation of Japanese character codes of a client and a server of the present invention.

FIG. 5 is a diagram showing allocation of Japanese character codes of a client and a server of the present invention.

FIG. 6 is a diagram showing a synchronization procedure between clients when an external character is added according to the present invention.

FIG. 7 is a diagram showing a synchronization procedure between clients at the time of deleting an external character according to the present invention.

FIG. 8 is a diagram showing an example of character storage in the database of the present invention.

FIG. 9 is a detailed view of a client character storable area of the present invention.

FIG. 10 is a diagram showing allocation of Japanese character codes of the present invention.

FIG. 11 is a flowchart showing an example of a character utilization procedure of the present invention.

FIG. 12 is a flowchart showing an example of a character utilizing procedure of the present invention.

FIG. 13 is a flowchart showing an example of a character utilization procedure of the present invention.

FIG. 14 is a diagram showing a structure of a new candidate list of the present invention.

FIG. 15 is a diagram showing the structure of a local font list of the present invention.

FIG. 16 is a diagram showing a structure of a fixed part list according to the present invention.

FIG. 17 is a diagram showing an arrangement example of a management file of the present invention.

FIG. 18 is a diagram showing a state of a registration client at the time of character registration of the present invention.

FIG. 19 is a diagram showing a state of an unregistered client at the time of character registration of the present invention.

FIG. 20 is a diagram showing a state when the registration client of the present invention is registered in a non-client external character area.

FIG. 21 is a diagram showing a state of an unregistered client of the present invention.

FIG. 22 is a flow chart of registration processing of the present invention.

FIG. 23 is a diagram showing a name input screen (before input) of the present invention.

FIG. 24 is a diagram showing a name input screen (during input) of the present invention.

FIG. 25 is a diagram showing a name input screen (after input) of the present invention.

FIG. 26 is a flowchart of the process when there is no regular character in the client-supported internal character of the present invention.

FIG. 27 is a diagram showing a name input screen of the present invention.

FIG. 28 is a diagram showing a name input screen of the present invention.

FIG. 29 is a diagram showing a name input screen of the present invention.

FIG. 30 is a diagram showing a name input screen of the present invention.

FIG. 31 is a diagram showing a state in which external characters have been registered according to the present invention.

FIG. 32 is a flow chart of a display process of the present invention.

FIG. 33 is a flowchart of the display process of the present invention.

FIG. 34 is a flowchart of deletion processing of the present invention.

FIG. 35 is a flowchart of deletion processing of the present invention.

FIG. 36 is a diagram showing a management file of the server of the present invention.

FIG. 37 is a diagram showing a management file of each client of the present invention.

FIG. 38 is a diagram showing a management file immediately after registration in the client 2a of the present invention.

FIG. 39 is a diagram showing a management file immediately after registration in the client 2b of the present invention.

FIG. 40 is a diagram showing a management file after transfer of a local font list according to the present invention.

FIG. 41 is a diagram showing a registration disabled state of the present invention.

FIG. 42 is a diagram showing a state after rebuilding the new candidate list of the present invention.

FIG. 43 is a block diagram showing an outline of a circuit configuration of a conventional font server.

FIG. 44 is a diagram showing a configuration of a management table used for conventional location management.

FIG. 45 is a configuration diagram of font information transmitted / received to / from a conventional master font server.

FIG. 46 is a block diagram showing configurations of a conventional client system and server system.

[Fig. 47] Fig. 47 is a diagram illustrating an example of assigning codes of a conventional partner system external character file.

[Fig. 48] Fig. 48 is a diagram illustrating an example of assigning a conventional Japanese Kanji code.

[Explanation of symbols]

1 server, 2, 2a, 2b, 2c client, 1
10 server internal character area, 111 client compatible internal character, 112 client non-compatible internal character, 115 client server system, 150 server external character area, 151
External character corresponding to client, 1511 fixed part, 1512
Client registerable area, 152 Client non-support external character, 211 Client internal character area, 251, 25
1a, 251b, 251c Client external character area, 2
511 fixed part, 2512, 2512a, 2512b,
2512c Client registerable area, 310 fixed part list, 320 new candidate list, 330 local font list.

Claims (12)

[Claims] 1. A distributed processing system comprising: (a) a first code system having a first code data registration unit for registering first code data corresponding to a code by the first code system. A server computer operating according to (b) a second code corresponding to a code according to the second code system.
First and second client computers having a second code data registration unit for registering the code data of (1), and (c) the first of the first and second code data registration units. A registration unit that stores the registration state of the second code data, and (d) the registration unit is referred to, an unregistered code is selected, and the code data corresponding to the selected code is set to the first and second codes. Registration means for registering in at least one of the code data registration units. 2. The registration means refers to the registration unit,
A code for which the second code data is not registered in the second code data registration section is selected, and the second code data corresponding to the selected code is selected by the second code of the first client computer.
2. The distributed processing system according to claim 1, further comprising a client registration unit that registers the code data in the code data registration unit and updates the registration unit. 3. The registration means further distributes the second code data registered in the second code data registration section of the first client computer by the client registration means to the second client computer, Second
3. The distributed processing system according to claim 2, further comprising a distribution means for registering in the second code data registration unit of the client computer. 4. The registration means further refers to the registration section, selects a code in which the first code data is not registered in the first code data registration section, and selects a first code corresponding to the selected code. 3. The distributed processing system according to claim 2, further comprising server registration means for registering the code data in the first code data registration unit of the server computer and updating the registration unit. 5. The second code data registration section is the second code data registration section.
The second code data is registered by using the code of the first code system corresponding to the code of the first code system as a key, and the registration unit sets the registration state in the second code data registration unit to the code of the first code system. 3. The distributed processing system according to claim 2, wherein the client registration means registers the second code data by using the code of the first code system. 6. The registration unit is of a first code system in which the first code data and the second code data have not been registered in the first code data registration unit and the second code data registration unit. A non-registered table storing a code, a code of a first code system in which the first code data has been registered in the first code data registration unit, and a second code
5. The distributed processing system according to claim 4, further comprising: a registered table for storing the code of the first code system in which the second code data has been registered in the code data registration unit. 7. The unregistered table stores unregistered codes by using the codes of the first code system, and stores the codes of the first code system by allocating to each client computer. The distributed processing system according to claim 6. 8. The distributed processing system according to claim 7, wherein the registration unit includes a reconstructing unit that reallocates a code of the first code system allocated to each client computer of the unregistered table. . 9. The distributed processing system further comprises deletion means for simultaneously deleting the second code data from the second code data registration units of the first and second client computers. The distributed processing system according to claim 2. 10. The registered table stores, for each client computer, a registration state of a second code data registration section of each client computer, and the client computer further refers to the registered table to obtain a desired state. If the code data corresponding to the code is already registered in the second code data registration section of the user, the second code data registered in the second code data registration section of the user is used to obtain the desired code. When the corresponding code data is not registered in the second code data registration unit of its own, the server computer is provided with a means for distributing and using the code data corresponding to the desired code. The distributed processing system according to claim 6. 11. The distributed processing system comprises a database in which at least one data is represented by respective codes of a first code system and a second code system, and the registration means comprises the first code and the second code. The first and second code data corresponding to the respective codes of the system are used as the first and second code data.
11. The distributed processing system according to claim 10, wherein the distributed processing system is registered in the code data registration unit of. 12. The utilization means refers to the respective codes of the first and second code systems of the database, and first and second corresponding to the respective codes of the first and second code systems. 12. The distributed processing system according to claim 11, wherein the second code data is input from the first and second code data registration units and used.