JPH10247943A - Link information management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To reduce the load in selection without requiring the specialized knowledge of a user and to reduce the loads on the operation of a server side by providing a uniquely determined link information table in which a link information name is a key. SOLUTION: An application interface part 27 gathers and transmits the kinds of requests to an application message reception part 23. By the application message reception part 23, link information is inquired to a link information server 11 from a network interface part 24. By the link information server 11, the received kind of the request is checked and a link information retrieval part 14 refers to the link information table 12 and obtains a retrieved result. Then, it is transmitted from the network interface part 15 to a client 21. By the client 21, based on received information, an object down-loading part 25 down-loads a link destination file and displays the link destination file.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a management system for an object which is a part of data scattered in a network environment, and controls a reference route between objects through link information and new reference by inheriting the reference route itself. The present invention relates to a system for creating and managing routes.

[0002]

2. Description of the Related Art A conventional example is disclosed in Japanese Patent Application Laid-Open No. 08-87463.
There is one shown in Japanese Patent Publication No. FIG. 21 is a system block diagram showing this conventional example, which is composed of a distributed resource server device (device A), a distributed resource client device (device B), a resource server related information server device (device C), and a communication network. You.

The device A uses a resource editing unit for editing resources (objects), a resource storage unit for storing / managing resources, a resource server unit having a protocol function for communicating with the device B, and a communication network. It is composed of a network interface unit that exchanges information with the device B. The device A includes a resource editing unit for editing resources (objects), a resource storage unit for storing / managing resources, a resource server unit having a protocol function for communicating with the device B, and a device B using a communication network. It is composed of a network interface that exchanges information.

The device B includes an input unit for controlling input from a keyboard and a mouse, an output unit for controlling output to a display and the like, a resource client unit having a protocol function for communicating with the devices A and C, link information and resources. A temporary storage unit composed of a link information temporary storage unit / resource information temporary storage unit for temporarily storing information, a network interface unit for exchanging information with the devices A and C via a communication network, and controlling these units. It is composed of a control unit.

The device C stores a resource table which is a list table of distributed resources (FIG. 22) and a link relation table which stores a link relation table which is information of a link relation between resources (FIG. 23). , An editing unit for editing the two tables, a network interface unit for exchanging information with the device B via a communication network, a resource relation information server unit having a function of communicating with the device B, and a control unit for controlling these. Is done.

The devices A, B, and C each have a machine address for uniquely identifying each of them in each network interface unit. In a system using this apparatus, consider an operation in which a user follows an object to obtain a desired data output. In the conventional link information table structure, the resource table storage unit of FIG.
Due to the structure of the link relation table of No. 3, only link information between two objects can be held, and it is impossible to uniquely manage continuous link information of a plurality of objects. This will be described with an example. As shown in FIG. 24, it is assumed that there are two types of sightseeing guides, “Yokohama Eat and Walk” and “Yokohama Sightseeing Guide”. Each guide is constituted by a plurality of objects linked continuously. The objects that make up "Eating Yokohama" are "Eating Walking Opening Screen" (word processing document) → "Map of Yokohama" (still image file) → "Chinatown store name list" (spreadsheet file). The objects that make up "Yokohama Sightseeing Guide" are "Tourist Guide Opening Screen" (word processing document)
“Map of Yokohama” (still image file) → “Yokohama sightseeing spot list” (spreadsheet file). Here, the "map of Yokohama" (still image file) is used in common by the two sightseeing guides.

FIG. 25 shows the link information of the two sightseeing guides in a conventional link relation table. In this case, two objects to be linked to the “map of Yokohama” (still image file) are “Chinatown store name list” (spreadsheet file) and “Yokohama sightseeing spot list” (spreadsheet file). In other words, regardless of which sightseeing information the user uses, if they try to go beyond the “Yokohama Map” (still image file), the “Chinatown store name list” (spreadsheet file) and the “Yokohama tourist spot list” (table Calculation file)
You have to choose one. When the user selects the link destination, even if the user has followed the link from “Tourist Information Opening Screen” (word processing document) to “Map of Yokohama” (still image file), the object to follow next is “Chinatown store name list” (Spreadsheet file), and the user may not know which link is correct. As described above, since a group of one continuous object that is meaningful with the structure of the conventional link relation table cannot be held as information, when a plurality of objects are linked from one object, which object is selected. It is necessary for the user to determine whether or not.

[0008]

The conventional distributed resource link system is constructed as described above. In the link relation table, apart from two objects, three or more continuous or a plurality of branched objects are set apart from two objects. There is a problem that link information cannot be uniquely managed. In addition, in the conventional separated resource link system, there is no mechanism for multiple resource relation information servers to work together on the network, and a bottleneck occurs in the resource relation information server due to response, maintenance, etc. when the data volume increases There was also a problem that there was a possibility of doing this. Also, objects must be managed centrally on the server, and local objects (objects that cannot be referenced by others) can be linked from the client side to objects (public objects) on the server. There is also a problem that it is difficult to add flexible link information for each user.

SUMMARY OF THE INVENTION The present invention has been made to solve the above-mentioned problems, and manages a group of meaningful link information so as to eliminate the burden of a user selecting an object. The purpose is to obtain a link information management system that enables the addition of unique link information.

[0010]

A link information management system according to the present invention is a system for managing link information between objects as a common file in order to mutually use objects distributed on a network. A link information table that manages the location of objects on the network, uniquely defines the connection between a series of objects corresponding to the link information name using the link information name as a key, and a link information name from the client Based on a request for correspondence, a link information server equipped with a link information management unit that searches, registers, and deletes connection information between a series of objects, and, when a program is specified by a user, supports the program from the link information table Required to obtain a series of connection information corresponding to the key of the link information name With the object downloading section for downloading objects, and a client which is adapted to output a corresponding destination defines a particular link source of the link information name by analyzing the user's request.

Further, the link information server has a link information name / link information server name correspondence table in which the link information name and the link information server are associated with each other. If the link information server does not have this information when there is a request to download the link information, the request is transferred to another link information server in the link information name-link information server name correspondence table.

Still further, the client has a local link information table for storing link information between the link source and the link destination specific to the client, and analyzes a user's request to store the information in the link information server or its own local link information table. Added a simple link manager to get a specific link source corresponding to link information name.

Further, the client has added a link information table temporary storage unit for downloading and storing necessary portions of the link information table and the link information name / link information server name correspondence table.

[0014]

BEST MODE FOR CARRYING OUT THE INVENTION

Embodiment 1 FIG. A system that centrally manages connections between a series of objects using link information names as keys to achieve effective use and facilitate maintenance will be described. FIG. 1 is a configuration block diagram of a link information management system according to the present embodiment, and shows a case where one link information server and two clients are connected via a communication network as an example. In the figure, 1 is a communication network, 11 is a link information server, 12 is a link information table, 13 is a link information management unit that manages the link information table 12, and 14 is link information for searching the link information table in response to a request from a client. A search unit 15 is a network interface unit that communicates with other link information servers and clients and the communication network 1. Reference numerals 21 and 31 denote clients for obtaining information on a screen or the like and searching for the next. Internally, an application 22 for analyzing a request from an application interface unit 23 and obtaining necessary information or requesting other information from an application interface unit 23. A message receiving unit, a network interface unit for communicating with another client or link information server 24, an object download unit 25 for receiving an object from another client or link information from the link information server 11, an object of 26 There is a file, 27 application interface sections.

FIG. 2 is a diagram showing an example of link information indicating a connection between a series of objects corresponding to specific link information names, and is stored in the link information table 12. In the figure, 121 is a link information name, 122 is a link source file location, 123 is a link source anchor object name, 124 is a link destination file location,
Reference numeral 125 denotes a link destination anchor object name, and a specific name is registered in each column. It is assumed that 126 is “Yokohama Eat and Walk” registered as an example of the link information name 121, and 127 is also “Yokohama Eat and Walk”, which are also files “Yokohama Eat and Walk” and “Yokohama Escape and Travel”, respectively. When the link destination anchor object name is *, the link destination object indicates the link destination file itself, and when all three fields (columns) 123, 124, and 125 are * as in 129, the end of the link information. Shall be expressed. The link information table 12
May have other additional information. FIG. 3 is a diagram showing a part of objects related to “Yokohama sightseeing guide” 127 as well as the link information name “Yokohama Eat and Walk” 126 in FIG.
Is a "map of Yokohama" object (in this case, image data) as a part of the file shown in FIG. Reference numerals 132, 134, and 137 denote objects (anchor objects) indicating areas where the objects shown in FIG. 3 are present. FIG. 4 is a diagram for explaining the flow of information based on an input made by the user at the client 21, FIG. 5 is an operation explanatory diagram for explaining the operation of the application message receiving unit 23, and FIG. It is an operation explanatory view for explaining a search operation.

The operation of the system having the above configuration will be described. First, a certain user creates a file “Yokohama Eat and Walk” 126 of the application shown in FIG. 3 and registers the link information “Yokohama Eat and Walk” 126 shown in FIG. 2 in the link information table 12 of the link information server 11. Suppose you have Separately, the file "Yokohama sightseeing guide" 127 of the application shown in FIG.
Is created and registered in the link information table 12. Although the relationship is difficult to understand in the link information table 12 in FIG. 2, this link information indicates the relationship between the white arrow and the black arrow in FIG. 3, and the "map of Yokohama" 133, which is a part of the same file, is uniquely different depending on the file. You can see that it is connected to the next object. The user tries to open and view the application “Yokohama Sightseeing Guide” from an input device (not shown) such as a keyboard and a mouse of the client 21. Opening this file will explain the case where the file “Yokohama Sightseeing Guide” is downloaded to the client 21 each time a search is made from the client or server in which the object is stored. You may. Then, a "sightseeing guide opening screen" 136 in FIG. 3 appears as the first screen. When the user selects a specific area “Next” 137 (such as clicking with a mouse), this input is not a request for registration or deletion.
The application interface unit 27 of the application retrieves the request together with the link source file location and the link source anchor object name, collects the request type 211, and transmits the request to the application message receiving unit 23.

The application message receiving section 23
Then, in response to this, the operation of FIG. 5 is performed. That is, since the request type is not registered in step 221, the request type 211 is set as the request type (search) 222 from the network interface unit 24 to the link information server 1.
Ask 1 for link information. Link information server 11
Then, referring to the type (search) 222 of the request received via the network interface unit 15, the link information search unit 14 refers to the link information table 12, and the search result 23
3 as the link destination file location 124 (
And the link destination anchor object name (in this case, it is not the link destination file itself)). Then, the packet is transmitted from the network interface unit 15 to the client 21.

In the client 21, based on the information on the location of the file of "map of Yokohama" received by the network interface unit 24 from the link information server 11, FIG.
The object download unit 25 downloads the link destination file, starts an application corresponding to the file, and displays the link destination file (in this case, “Map of Yokohama”) by activating the anchor object 213. . Thereafter, when the user selects the button “next” 135 which is a specific area of the display screen, the same operation as the above-described operation of each unit is continued. The application interface unit 27 is a block described by a macro or the like of each application.

In the above-described operation, the operation in which the user opens the file and follows the anchor object, that is, the search operation has been described. In addition to this, for example, the user who first creates the file changes a part of the file in the middle for maintenance, temporarily deletes the corresponding link information in the link information table 12 for changing the version, or registers again or newly registers. The operation at the time of performing will be described. When “link information” is specified in a format set separately from the application interface unit 22 of the client 21 and a “delete” request is made, the application message receiving unit 23 indicates that the content of the request type 211 is “delete”. So the network interface part 2
4 transmits a request type (deletion) to the link information server 11. The link information server 11 receiving this deletes the “link information” corresponding to the link information management unit 13 from the link information table 12 from the request content. Of course, deletion is link information, and the object itself is not deleted. The operation of re-registration or new registration is the same as the above-described deletion operation.

Embodiment 2 The link information server mainly manages files frequently used by clients connected to the network. However, a system that can be handled by the link information server even when a file inquiry from a certain client exceeds the management range will be described. By doing so, it is possible to achieve both efficiency of management and diversity of requirements. FIG. 7 is a configuration diagram of the link information management system according to the present embodiment. In the figure, 4
1 is a link information server in Yokohama, 42 is a link information table, 43 is a link information management unit, 44 is a link information search unit, and 45 is a network interface unit. As a new element different from the first embodiment, 46 is a link information name / server name correspondence comparison unit, 47 is a link information name / server name correspondence table, and 127 is a “Yokohama sightseeing guide” file. Reference numeral 51 denotes a link information server of Kamakura City, 52 denotes a link information server of Kanagawa Prefecture, 53 denotes a “Kamakura sightseeing guide” file, and 54 denotes a “Kanagawa sightseeing guide” file. The client is the same as in the first embodiment. FIG. 8 is a diagram showing an example of a link information name / server name correspondence table, where 471 is a column for link information names, and 475 is a column for showing the name of the server having the file. FIG. 9 is a diagram for explaining the operation of the link information name / server name correspondence comparison unit 46.

The outline of the operation of the system having the above configuration at the time of searching for link information is as follows. When a search request for the link information name “Kamakura sightseeing guide” 474 is sent from the client 21 connected to the Yokohama city server 41 to the Yokohama city server 41, the Yokohama city server 41 reads “link information name” in the server. It can be seen from the “server name correspondence table” 47 that the link information server in which the link information name “Kamakura sightseeing guide” 474 is managed is the “Kamakura city server” 478. The Yokohama-shi server 41 transfers the search request sent from the client 21 to the Kamakura-shi server 51, receives the search result (location of the linked object) from the Kamakura-shi server 51, and sends it to the requesting client 21. Send.

The transfer operation of the link information server (Yokohama City) 41 will be described in detail with reference to FIG. The “link information name / server name correspondence comparison unit” 46 receives the search request (441) sent from the client 21 via the network interface unit 45. Next, using the link information name “Kamakura sightseeing guide” in the search request 441 transmitted as a key, the link information server name storing the link information is searched from the link information name / server name correspondence table 47 ( Step 461). Obtained link information server 5
In step 462, a message from the client is transferred to the client 1 (step 462). The link information search unit 55 on the transfer destination server performs a search in the same manner as in the first embodiment, and sends the result to the link information name-server name correspondence comparison unit 46 of the link information server (Yokohama) 41 as the transmission source server. return. The link information name / server name correspondence comparison unit 46 transfers the returned search result to the client 21 via the network interface unit 45. Subsequent operations of the client are the same as in the first embodiment.

If the link information table is uniquely determined and managed using the link information name as a key as described above, the link between a series of objects can be registered by combining these link information names with a new information name. . The case of using the combination will be described below. FIG. 10 is a view for explaining linking of link information. FIG. 11 is a part 54 of a file which is a linking part of the file “Kanagawa sightseeing guide” 54.
FIG. As shown in FIG. 10A, the files “Kanagawa sightseeing guide” 54 and “Yokohama sightseeing guide” 1 are originally.
27 and "Kamakura Tourist Information" 53 were separate files. This is processed into an anchor object of a part 541 of the file, and “Kanagawa sightseeing guide” 540 is added to the link information table as a new link information name in FIG.
By registering as a series of information as shown in FIG.
The connection can be made as shown in FIG.

Embodiment 3 FIG. There is information that is not public information that can be used by a large number of people but that should be kept secret except for the doctor in charge, such as personal medical information. In such a case, there is a system that can be combined with public information and exert its effects. The system according to the present embodiment is characterized by a client. FIG. 12 is a configuration diagram of the link information management system according to the present embodiment. In the figure, 60 is a medical link information server, 61 is a doctor client, 62 is an application, 63 is an application message receiving unit, 64 is a network interface unit, 65 is an object download unit, 66 is an object,
This is the same as the element of the same name in the other embodiments. Embodiment 1
67 is a simple link manager unit, and 68 is a local link information table. FIG.
Is a *** file 602 which is a part of the medical link information file 601 of the medical link information server 60,
FIG. 9 is a diagram illustrating the relationship between a cecal case file 603, a cecal coping method file 604, and a **** file 605, and a case where a part of the public medical link information file 601 is used from a doctor client. . In the figure, reference numeral 69 denotes a patient's chart file.
FIG. 14 shows the medical link information 6 in the link information table 601.
FIG. 15 is a diagram showing a connection between a series of objects connecting ten link source files and a link destination file, and FIG. 15 is a diagram showing an example of local link information 68 of the doctor client 61. FIG. 16 also shows the doctor client 6
FIG. 3 is a diagram for explaining the operation of a simple link manager unit 67 in FIG.

First, a medical chart 69 of a patient who has been treated exists as an object on the client 61 of each doctor. When the doctor searches the public medical link information 610 of the medical link information server 60 and finds an object “cecal case file” 603 which is a reference to the medical record of the cecal patient he is examining, the medical chart 6 of the cecal patient
9 (object) is linked to the searched object “cecal case file” 603. FIG. 15 shows a state after the link is registered in its own local link information table 68. With this registration, the cecal patient's chart file 69 is connected to the cecal case file 603 as shown by the thick line in FIG. This is registered and managed in the local medical link information 681. In this way, it is possible to link a local object 69 such as a chart file to public information managed by the medical link information server 60. Further, since the linked local object 69 cannot be traced from another client, it is also effective in terms of security of protecting the secret of an individual.

The operation outline when the cecal case file 603 and the cecal coping method file 604 therefrom are traced from the cecal patient's chart 69 is as follows. When searching for a linked object from the cecal patient's chart 69, first, the local medical link information 681 is searched to obtain the location of the linked object (cecum case) 603. Thereafter, when searching for link information ahead of the cecal case file 603, first, local link information is searched (it does not exist), and then the medical link information server 60 is searched.
A search request can be made to obtain the location 604 of the linked object “cecal treatment file” of the cecal case file 603.

The operation of the simple link manager 67 in the client 61 will be described. The operation shown in FIG. 16 is performed in response to a user's operation, that is, a request for registration / deletion / search for local link information from the application interface unit. As in the operation of FIG.
The processing request sent to the message receiving unit 63 is passed to the simple link manager 67 in this case. If the processing request is other than search (registration / deletion) in step 671, registration / deletion is performed on the local link information table 68 in step 672. If the processing request is a search, first, at step 673, the local link information table 68
Is found, and if the corresponding link information exists, the "link information name", "link destination file location", and "link destination anchor / object name" are passed to the object download section 65 in step 675. Also, if there is no corresponding link information in the local link information search,
In step 674, the processing request (search) is sent to the medical link information server 60 via the network interface unit 64.
Passed to. Subsequent operations of the object download unit 65 and the like are the same as those described in the first embodiment.

Embodiment 4 In each of the embodiments described above, the case where the link source of the link information is designated from the client and the link destination is mainly obtained from the link information server each time has been described, but the traffic on the network is reduced and the load on the link information server is reduced. Explain the system to reduce. The system of this embodiment is also characterized by the client. FIG. 17 is a configuration diagram of the link information management system according to the present embodiment. In the figure, 80 is a link information server,
Reference numeral 71 denotes a client, 72 denotes an application, 73 denotes an application message receiving unit, 74 denotes a network interface unit, 75 denotes an object download unit, and 76 denotes an object, which are the same as those of the other embodiments. As a new element different from the first embodiment, 82 is a link information temporary holding unit, 83 is a link information name / server name correspondence table temporary holding unit, 84 is a simple link search unit, and 85 is a link information batch download unit. FIG. 18 is a diagram showing an example of link information and download to a terminal according to the present embodiment, and FIG. 19 is a diagram for explaining the operation of the link information batch download unit 85 in the client. FIG. 20 is a diagram showing an example of a link information table relating to car sales used in the present embodiment.

The client 71 is a link information server 80
, A link information group to be used is specified, and the link information group and a necessary portion in the “link information name-server name correspondence table” are received from the link information server 80. After receiving the information, the client 7 searches for the link information.
Since it can be performed by only one side, communication with the server is not required for the search. If the link information is searched in the client 71, the client managing the required object can be found. The object download is executed by requesting the identified managing client to download the object.

Specific examples are shown below. Take car sales as an example. Salesman has his own laptop 1
The information file of the individual “customer 1” 911 and “customer 2” 912 as the customer information and the “photograph of the vehicle type A” 91
3. It is assumed that the user has a "picture of car type B" (image file) 914, and the link information of these objects is managed by the link information server 80 of the business office. Further, “photograph of vehicle type A” and “photograph of vehicle type B” are a plurality of “catalogs” each describing detailed specifications of the vehicle (model A catalog 1901 → model A catalog 2, model B catalog 1 → model B catalog 2). ) Are linked as a link destination. It is assumed that the “catalog” object itself exists in the catalog information server 90 of the business office. FIG.
As shown in the figure, the link information table has a link information name connected to “customer 1” as “customer 1 link” 88 and a link information name connected to “customer 2” as “customer 2 link” 89. When a high-speed communication network is usually used in a business office, a search for a link as described in the first embodiment is performed. However, when the terminal 171 is taken for business to a customer, the communication with the server 80 of the business office uses a low-speed public line, so that the link information is searched and downloaded one by one on a normal route. In such a case, it takes time until the linked object is displayed.

Therefore, when visiting the home of the customer 1 and conducting business activities, if a link destination object (“catalog”) other than the information in the terminal 171 becomes necessary, first,
Link information server 80 Link information name Customer 1 link 8
8 and, if necessary, the “link information name-server name correspondence table” are collectively downloaded to the terminal 171 (in the above case, since the link information is not distributed, “link information name-server name” Although it is not necessary to download the "correspondence table", it is stored in the terminal 171.
Thereafter, as long as "customer 1" is searched for, all of the link information can be searched for in terminal 171. This eliminates the need to exchange information with the link information server using a low-speed public line. The actual link destination object is downloaded directly from the client or server obtained as a result of the search performed in the terminal 171.

The operation of the terminal 1 as the client 71 which is not included in the other embodiments will be described. FIG.
In step 851, the link information batch download unit 85 receives the link information name input from the user in step 851, and transmits a processing request (link information batch download request) and the link information name to the link information server 80 in step 852. The link information server 80 transmits the link information related to the link information name (in this case, the customer 1 link 88) and the related link information name-server name correspondence table to the link information batch download unit 85 of the client 71 that has made the request. The link information batch download unit 85 receiving the information from the server 80 stores the information in the “link information temporary storage unit” 82 and the link information name-server name correspondence table temporary storage unit 83. After that, the application
In response to a user inquiry from the interface unit, the simple link search unit 84 searches the link information temporary storage unit 82 and the link information name-server name correspondence table temporary storage unit 83 in principle. That is, the search request sent from the application interface unit to the application message receiving unit as shown in FIG. 4 is passed to the simple link search unit 84 in this embodiment. Upon receiving the search request, the simple link search unit 84 searches the link information temporary storage unit 82 and the link information name / server name correspondence table temporary storage unit 83, and stores the “link information name”, “link destination file” in the object download unit 75. Pass the "location" and "link destination anchor / object name".
This is exactly the same operation as the simple link manager unit of the previous embodiment, and the other operations are exactly the same as the elements of the same name in the previous embodiment. However, the simple link search unit does not have the link information registration / deletion function of the simple link manager unit. According to this embodiment, the link information can be used even in an environment requiring asynchronous processing such as a mobile terminal.

[0033]

As described above, according to the present invention, a link information table which is uniquely determined by using a link information name as a key is provided. This has the effect of reducing the burden of operation on the side.

Further, since a link information name-to-link information server name table for storing link information corresponding to the link information server to be managed is provided, the scale of the link information server can be reduced, the use scale can be increased, and maintenance is easy. Has the effect of becoming

Further, since the client is provided with a local link information table which cannot be seen from other clients, there is an effect that secrecy can be maintained for files composed of local objects. There is also an effect that a flexible file configuration can be made.

Further, the provision of the link information temporary storage unit in the client has the effect of reducing the amount of communication and the communication time. In addition, there is an effect that it can be used by a client that needs asynchronous processing.

[Brief description of the drawings]

FIG. 1 is a configuration block diagram of a link information management system according to a first embodiment of the present invention.

FIG. 2 is a diagram showing a data example of a link information table according to the first embodiment.

FIG. 3 is a diagram illustrating an example of an object corresponding to a link information name according to the first embodiment;

FIG. 4 is a diagram showing a flow of information corresponding to a user's input operation in the first embodiment.

FIG. 5 is a diagram illustrating an operation of an application message receiving unit according to the first embodiment.

FIG. 6 is a diagram for explaining an operation of a link search unit according to the first embodiment.

FIG. 7 is a configuration block diagram of a link information management system according to a second embodiment of the present invention.

FIG. 8 is a diagram illustrating a data example of a link information name / server name correspondence table according to the second embodiment;

FIG. 9 is a diagram for explaining an operation of a link information name / server name correspondence comparison unit according to the second embodiment.

FIG. 10 is a diagram for describing combined use of link information according to the second embodiment.

FIG. 11 is a diagram for describing combined use of link information according to the second embodiment.

FIG. 12 is a configuration block diagram of a link information management system according to a third embodiment of the present invention.

FIG. 13 is a diagram for describing a partial use of a public file according to the third embodiment.

FIG. 14 is a diagram illustrating a data example of a link information table according to the third embodiment.

FIG. 15 is a diagram showing a local link information table according to the third embodiment.

FIG. 16 is a diagram illustrating an operation of a simple link manager unit according to the third embodiment.

FIG. 17 is a configuration block diagram of a link information management system according to a fourth embodiment of the present invention.

18 is a diagram illustrating an example of link information and an example of downloading to a terminal according to Embodiment 4. FIG.

FIG. 19 is a diagram illustrating an operation of a link information batch download unit according to the fourth embodiment.

FIG. 20 is a diagram illustrating a data example of a link information table according to the fourth embodiment.

FIG. 21 is a diagram of a conventional distributed resource link management system.

FIG. 22 is a configuration diagram of a resource storage unit of a conventional distributed resource link management system.

FIG. 23 is a diagram of a link relation table of the conventional distributed resource link management system.

FIG. 24 is an explanatory diagram of an object link for explaining a conventional distributed resource link management system.

FIG. 25 is a diagram of a link relation table of the conventional distributed resource link management system.

[Explanation of symbols]

1 communication network, 11 link information server, 12 link information table, 13 link information management section, 14 link information search section, 15 network interface section, 2
1 client, 22 application, 23 application message receiving unit, 24 network interface unit, 25 object download unit, 26 object file, 27 application interface unit, 31, 32 client, 41 link information server, 42 link information table, 43 link information management unit, 44 link information search unit, 45 network interface unit, 46 link information name / server name correspondence comparison unit, 47 link information name / server name correspondence table, 51 link information server, 5
2 link information server, 53 Kamakura tourist information file,
54 Kanagawa sightseeing guide file, 60 link information server, 61 doctor client, 62 application, 63 application message receiving unit, 64
Network interface part, 65 Object download part, 66 Object file, 6
7 Simple link manager section, 68 Local link information table, 69 Medical chart file, 601 Medical link information file, 71 Client (terminal 1), 72
Application, 73 Application, 74
Network interface unit, 75 Object download unit, 76 Object file, 80
Link information server, 82 link information temporary storage unit, 8
3. Link information name / server name correspondence table temporary holding unit,
84 Simple link search (manager) section, 85 link information batch download section, 90 catalog information server.

Claims (4)

[Claims] 1. A system for managing link information between objects as a common file in order to mutually use objects distributed on a network, comprising: managing the location of the objects on the network; A link information table that uniquely defines a connection between a series of objects corresponding to the link information name with a link as a key, and a link information table between the series of objects based on a request for the link information name correspondence from a client. A link information server having a link information management unit for searching, registering and deleting connection information; and a series of keys corresponding to the link information name corresponding to the program from the link information table when a program is specified by a user. Object that obtains connection information and downloads necessary objects Comprising a transfected download unit, the link information management system comprising a client which is adapted to analyze the request of the user and outputs a corresponding destination defines a particular link source of the link information name. The link information server has a link information name-to-link information server name correspondence table in which the link information name and the link information server are associated with each other. When there is no connection information download request in the own link information server when there is a connection information download request, the request is transferred to another link information server in the link information name-link information server name correspondence table. The link information management system according to claim 1, wherein 3. The client has a local link information table for storing link information between a link source and a link destination unique to the client, analyzes a user request, and stores the link information in a link information server or the local link information table. 2. The link information management system according to claim 1, further comprising a simple link manager for obtaining a specific link source corresponding to the name. 4. The client according to claim 1, further comprising a link information table and a link information table temporary storage unit for downloading and storing a required portion of the link information name / link information server name correspondence table. Link information management system.