JP2004157826A - Peer-to-peer document sharing network system - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a convenient peer-to-peer file sharing system capable of performing information retrieval not only for a file name but also the content of a file. <P>SOLUTION: This file sharing system accumulates and manages a shared document as a combination of actual file data and metadata. Each node computer comprises a type plug-in for collating the content of the metadata with a retrieval condition to determine whether the document is a document corresponding to the retrieval condition or not, a network engine for communicating with another node computer by a peer-to-peer network protocol, a dialog interface function for inputting the retrieval condition and displaying the retrieval result, and a search engine for performing document search and management for the whole network by use of it. <P>COPYRIGHT: (C)2004,JPO

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a document sharing system in a peer-to-peer network.
[0002]
[Prior art]
Until now, it has been common to construct a client-server type network in a LAN constructed in a business office or the like. In the case of a client-server system, computers connected to a network are assigned roles between a client and a server. In such a system, a computer connected to a network includes a client that has a graphical user interface (GUI) and issues various requests and job requests according to a user's operation input, and a server that quickly responds to request requests from the client. And divided into In many cases, a personal computer connected to a network serves as a client, and an expensive and high-performance dedicated server equipped with a large-capacity storage device and a high-performance CPU serves as a server. On the other hand, recently, due to the improvement in CPU performance of a personal computer connected to a network and an increase in disk capacity, a peer-to-peer type network (hereinafter, P2P type) in which a computer connected to the network is not divided into a client and a server has attracted attention. I have.
[0003]
In the P2P type, all computers are clients and also function as servers. Since a dedicated server machine is not required and the cost is low, it is suitable for sharing files and printers on a small LAN. On the other hand, a load is imposed on the computer sharing the file, which is not suitable for constructing a large-scale network. However, there is a technology such as Napstar (Non-Patent Document 1) and Gnutella (Non-Patent Document 2) for directly exchanging files between users on the Internet.
[0004]
Napstar and Gnutella define a protocol for exchanging files on the Internet, and a P2P network engine mounted on a computer exchanges information according to this protocol, so that a user can find a partner holding a desired file. , Which can be referenced or duplicated.
[0005]
[Non-patent document 1]
Masao Kawachi, Keiichi Koyanagi, "New Century of P2P Internet"
Telecommunications Association; ISBN: 488490197; May 2002
[Non-patent document 2]
Kyohei Yamamura, "Let's Go with Gnutella!-Monster Software" Gnutella "That Will Revolutionize the Internet World"Bestsellers; ISBN: 4584165262; January 2001
[0006]
[Problems to be solved by the invention]
In Napstar and Gnutella, requests and searches for desired information are all performed on file names. That is, only the file having the file name including the search character string is searched. Therefore, for example, there is a restriction that information search in a full-text search form cannot be performed.
[0007]
The present invention has been made in view of such problems, and provides an easy-to-use peer-to-peer file sharing system capable of performing information search not only on file names but also on file contents. As an issue.
[0008]
[Means for Solving the Problems]
A first invention for solving the problem is as follows.
A document sharing network system in which a plurality of node computers cooperate in an equal relationship, the first mode of which is:
Each node computer connected to this system stores the shared document as a data set, which is a combination of real file data and metadata describing the real file data for each defined item, in each storage device of each node computer. And further, each node computer,
Using a type plug-in that refers to metadata contained in each stored data set, a network engine that exchanges information with another node computer by a peer-to-peer network protocol, and using the network engine and the type plug-in A designated search comprising: a search engine for performing search, reference, transfer, and registration of the data set; and a graphical user interface for providing instructions to the search engine by a user and displaying search results by the search engine. This is a peer-to-peer type document sharing network system capable of extracting a data set by comparing conditions with metadata of each data set and presenting the data set as a search result.
[0009]
By managing the shared storage document in the form of a data set and referring to the metadata at the time of the search, the peer-to-peer type document sharing system can perform a search process of the shared document using a search term other than the file name.
[0010]
A second aspect of the first invention for solving the problem is as follows.
In the peer-to-peer type document sharing network system according to the first aspect, the metadata can define new metadata types (metadata types) one after another by adding an extension to basic metadata. A shared document stored in the system can be classified and managed according to the type of metadata, and the type plug-in is provided according to the metadata type of the shared document. It is a shared network system.
[0011]
A data set, which is a unit for managing information in the system according to the first invention, includes real file data (real data) and metadata. Actual data is the content of the shared document itself. On the other hand, metadata is a collection of names (item names, tags, and the like) of some items defined for actual data and their values (item values). Therefore, the “document type” for classifying shared documents into equivalence classes is determined depending on whether the item names included in the metadata match. This is called a “metadata type”. The user can define a new document type as needed, and can refer to metadata by a type plug-in corresponding to the defined document type (metadata type). By adopting such a management system, it becomes possible to manage the shared document flexibly and easily even if the environment changes and the properties of the document to be stored change.
[0012]
A third aspect of the first invention for solving the problem is as follows.
In the peer-to-peer type document sharing network system according to the second aspect, when searching for a stored and managed shared document, by specifying one metadata type as a search type, the search engine can perform A peer-to-peer type document sharing network system characterized in that a metadata type matching a search type and a data set corresponding to a metadata type based on the search type can be limited as search targets.
[0013]
By specifying a search type, documents of a search type and a type derived from the search type can be searched. Such a search method is reasonable from the viewpoint of document management. Documents of derived types also contain all of the underlying type's metadata.
[0014]
A fourth aspect of the first invention for solving the problems is as follows.
In the peer-to-peer type document sharing network system according to the second aspect, one type plug-in refers to only the metadata of the unique part corresponding to the type of the corresponding metadata type, and the meta of the other basic part. By calling the type plug-in of the metadata type on which the data is based repeatedly as necessary, the range of the data described in the metadata type corresponding to the type plug-in of the metadata of the data set to be processed is obtained. Is a peer-to-peer type document sharing network system characterized by referring to FIG.
[0015]
In the system of the first invention, it is necessary to provide a type plug-in from a basic type to various development types thereof, but the configuration and realization of the type plug-in in this way is performed when a new type is defined. , Making it easier to create new type plugins for that type. This is because the new type plug-in knows what the type plug-in is based on, and only needs to perform processing on the newly added metadata.
[0016]
In the peer-to-peer document sharing network system according to the second aspect, it is desirable that the user interface provided when registering the shared document is provided according to the metadata type of the newly registered document. This is because the user can register necessary information as metadata of the document without omission.
[0017]
In the peer-to-peer type document sharing network system according to the third aspect, it is desirable that a user interface for specifying a search condition when starting a search be provided according to the specified search type. This is because the user can specify as many search conditions as necessary for all items defined as metadata of the document.
[0018]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a conceptual diagram of a P2P document sharing system 1 (hereinafter, system 1) according to an embodiment of the present invention. In FIG. 1, reference numeral 10 denotes each computer connected to the network. Each computer constituting the system 1 is called a node computer or simply a node. Each node is interconnected with other nodes whose existence it knows. The left part of FIG. 1 shows the inside of one node computer 10. One node is provided with a search engine 11, several plug-ins 12, a network engine 13, and a file database 20 for storing and managing shared documents. The file database 20 holds the shared document in a data set 21 format. One data set 21 includes a real file 211 and metadata 210 that describes, for each item, what is described in the real file, the nature of the real file as a document, and the like.
[0019]
First, a data set as a unit for managing information in the present system will be described. One data set includes real file data and metadata. This is shown in FIG. "Metadata" is a term for "actual data", and "data about actual data" has its original meaning. Often used as data indicating what the actual data means. In the system 1, the actual data is the content of the shared document itself. On the other hand, the metadata is a collection of names (item names, tags) and their values (item values) of some items defined for the actual data. Therefore, by appropriately setting the items to be included in the metadata, the gist of the contents of the shared document and some attributes of the shared document can be known by referring to the metadata without reading the actual data. If the list of metadata item names of a plurality of shared documents match, it can be said that they are the same type (same type) of shared documents. In other words, the metadata defines the “document type” that classifies the shared document into the equivalent class. This is called a “metadata type”.
[0020]
Further, in the system 1, based on one metadata type, a new metadata type can be defined by adding some new item names thereto.
In this way, a series of the metadata type can be created. FIG. 4 shows an example of such a metadata type sequence. In FIG. 4, based on the metadata described as metadata type A, new items B1, B2,... Are added to the metadata type B to form a metadata type B, and a new item C1 is added to the metadata. The example which defined type C is shown. In this sequence of metadata type A → metadata type B → metadata type C, metadata type A (B) is a basic type of metadata type B (C) and can be said to be a parent type. Alternatively, it can be said that the metadata type B (C) is further developed by inheriting the metadata type A (B) and adding new items B1, B2,... (C1). Also, it can be said that type A is a higher type of types B and C, and type C is a lower type of types A and B. The items B1, B2,... (C1) newly added when defining the metadata type B (C) will be referred to as “specific metadata type B (C)” for convenience. The unique metadata type B is included in the metadata type B and lower metadata types, but is not included in the metadata type higher than the metadata type B.
[0021]
Returning to the description of FIG. The search engine 11 is provided for each node 10. The search engine 11 started in the node 10 exchanges information with the search engine 11 operating in another node using a mutually defined P2P protocol to implement a P2P search process. The actual search process is performed by the type plug-in 12 that is called one after another as needed. The search engine 11 uses a network engine 13 to exchange information with the P2P protocol. Further, the search engine 11 uses a graphical user interface (GUI) prepared according to the type of metadata (more precisely, a unique metadata type) for inputting search conditions or registering a shared document. A user's search request is received by the GUI function, the search result is displayed and output, and an instruction to import a file is received.
[0022]
The type plug-in 12 refers to the metadata of the shared document to be processed and executes the requested process on the document. In particular, processing is performed on whether or not the document is hit with respect to the search condition. The type plug-in 12 is prepared corresponding to the metadata type, that is, corresponding to the document type. Details will be described later.
[0023]
The network engine 13 is a program that enables communication between nodes by a peer-to-peer network protocol (application layer protocol). The network engine 13 may use a computer program described in Non-Patent Document 2. FIG. 2 illustrates a flow from when a certain computer searches for information and obtains desired information according to the network protocol.
[0024]
FIG. 2 shows a case where the node A issues a search request. Node A transmits a search request message to node B according to a predetermined search route. Upon receiving this message, the node B checks whether or not the corresponding data exists in itself ((1)). If not, it sends a search request message to the next node C. This time, the node C checks whether the corresponding data exists ([2]). If it is confirmed that the corresponding data is held, the node C returns a response to the node B to that effect. The node B returns a response indicating that the data corresponding to the node C is present to the node A ([3]). Node A sends a message to node C requesting data. The node C sends the corresponding data to the node A ([4]). In this way, the search message and the response to it are exchanged like a message game, and the search and procurement of information are performed in a completely equal network without server / client distinction. In an actual protocol, there is a concept of "lifetime" in order to prevent divergence of search requests. The search request is generated with a value of the lifetime which is a certain integer (for example, “= 5 nodes”). Lifetime is consumed each time a node is passed, and when it reaches 0, the search request is not transferred to the next node.
[0025]
Next, referring to FIGS. 6 and 7, how the file sharing function of the system 1 actually operates will be described with an example. The diagram on the left side of FIG. 6 shows a document type sequence assumed in the description example. The diagram on the right side of FIG. 6 shows a peer-to-peer message route assumed in the description example. The description example shows the operation of the system 1 until the user (murata) searches for a shared document including “「 × △ ”in the title of the document from his or her own computer and obtains it.
[0026]
First, the user (murata) selects a proposal-type document search from the GUI menu on the computer of murata ((1) -1 in FIG. 7) and sets search items. Here, “○ × △” is designated as the title. Therefore, a proposal-type data set including “○ × △” in the title is retrieved ((1) -2 in FIG. 7). The search query is transmitted to the two nodes, suzuki and tanaka, according to the determined message route ((2) and (3) in FIG. 7).
[0027]
The node suzuki checks whether or not a corresponding data set exists in the database 20 held by itself, and transfers the search query to a lower node existing in a lower message route. ((2) -1 in FIG. 7).
[0028]
Similarly, the node tanaka checks whether there is a corresponding data set in the database 20 held by itself ((3) -1 in FIG. 7), and transfers the search query to the lower node minami ((3) -1). (4) in FIG. 7). Similarly, the node minami checks whether or not the corresponding data set exists in the database 20 held by itself ((4) -1 in FIG. 7). If the corresponding data set exists, the node “minami” The corresponding data set is returned and the metadata of the corresponding data set is returned to the node tanaka ([4] -2 in FIG. 7). The node tanaka relays the response to murata ((3) -2 in FIG. 7).
[0029]
The node murata collects responses returned to the search query, forms a search result screen, and displays it to the user ([5] in FIG. 7). On the search result screen, the title, owner (existing node), and type of the data set are displayed in a list. The user selects a data set to download from this list. Then, a download request is transmitted directly to each node where the data set selected for download exists ([6] in FIG. 7).
[0030]
The node receiving the download request transfers the specified data set directly to the node murata ([6] -2 in FIG. 7). Thus, in the peer-to-peer network, the search and transfer of the shared file are performed.
[0031]
Next, the configuration of the system 1 that realizes the operation described with reference to FIGS. 6 and 7 will be described. Before the following description, FIG. 8 defines three types of metadata types used as specific examples of the following description. FIG. 8A shows the contents of report-type metadata (M01). The report-type metadata M01 includes items of “document title”, “creator”, and “creation date”. FIG. 8B shows the contents of the conference report type metadata (M012). The meeting report type is obtained by adding a set (M02) of items of "meeting name", "attendant", and "date and time" to the report type metadata M01. FIG. 8C shows the contents of the business trip report type metadata (M013). The business trip report type is obtained by adding a set (M03) of items of “business trip destination”, “accompaniment”, and “business trip date and time” to the report type metadata M01. FIG. 8D is a system diagram showing the parent-child relationship of three document types: a report type, a meeting report type, and a business trip report type. Note that the actual metadata includes not only the item name but also its value and the type name of the unique metadata type (such as “report type”).
[0032]
In the following description, “(one) shared document” and “(one) data set”, “document type” and “metadata type” are used as synonymous terms. Although “(one) shared document” and “document type” are terms used from a user's point of view, “(one) dataset” and “metadata type” are terms used from a computer system point of view, This is because they refer to the same entity.
[0033]
FIGS. 12 and 13 are schematic flowcharts for explaining the entire operation of the search engine 11. FIGS. 12 and 13 show one flowchart divided into two for the sake of space. Hereinafter, the operation of the search engine 11 will be schematically described with reference to this schematic flow.
[0034]
The search engine 11 is started whenever the node computer starts up. First, an initial setting process is performed (S01). The initial setting process depends on the OS of the node computer and the implementation method of the system. However, the network engine 13 is started to enable communication with the other node at any time by the peer-to-peer protocol, and is used for executing the search process. A process such as setting a temporary storage area and various status flags to an initial state is performed. Since the search processing can be accepted at any time after the initial setting is completed, an icon for calling the search condition input screen interface is displayed on the computer screen (S05). Thus, when the user wants to perform a search, the user can display the search condition input screen at any time by clicking the icon.
[0035]
Thereafter, the search engine 11 enters a state of waiting for an event (S09). The main events here are search icon selection, search request generation, file transfer request generation, search result reception, file transfer request response reception, search request reception, search result relay reception, and file transfer request reception. is there. In addition to the functions of the search engine 11, there are also events that are generated by interactive operations such as calling an operation screen for registration / change processing of a shared document and instructions for registration / change processing. In the description, the description will focus on operations related to search processing, which is the main function of the search engine 11.
[0036]
When the search engine 11 detects the search icon selection event, the search engine 11 first displays a GUI screen for selecting a type to be searched (search type) (S17), and allows the user to select a search type. Next, a search condition input screen corresponding to the search type selected by the user image is displayed (S19), and the user inputs search conditions on the screen.
[0037]
FIG. 9 shows an example of a GUI screen when a search condition is input. FIG. 9A is a GUI screen for selecting a search type. 9B to 9D are search condition designation screens displayed when a report type, a meeting report type, and a business trip report type are selected as the search types.
[0038]
The search request event occurs when the user presses the search button after inputting search conditions in FIGS. 9B to 9D. At this time, the search engine 11 causes the next node on the route to issue a search request through the network engine 13 (S10). The search request includes information such as the ID number of the search request, the ID of the search requesting node, and the initial value of the lifetime, in addition to the search conditions input by the user. The search engine 11 sets a flag indicating that the request with this ID number is being searched (waiting for a response to the search request issued by itself) (S12).
[0039]
The file transfer request event occurs when the user selects a specific file from the search result list screen and presses the file transfer request button. The search engine 11 causes the node having the data set to issue a file transfer request via the network engine 13 (S20).
[0040]
When the response to the file transfer request issued by itself is returned, the file data is fetched (S40). This ends a series of processing.
[0041]
Next, the processing of the search engine 11 of the relay node will be described with reference to FIG.
[0042]
First, when a search request is received (relayed) from the preceding node, the search engine 11 relays the search request to the next node on the route through the network engine 13 (S50). However, when the lifetime of the search request is zero, the network engine 13 no longer relays. In the case of relaying, the value of the lifetime is reduced by one and relaying is performed. Then, a search process of the own node is executed (S52). The search processing result is returned to the preceding (upper) node as soon as the search processing is completed (S62).
[0043]
When the search result is received from a lower node on the route, the search result is relayed to the upper node on the route as it is (S62).
[0044]
When a file transfer request addressed to the own node is received, a copy of the file is directly returned to the requesting node (S70).
[0045]
The flowchart of FIG. 14 describes the flow of the search processing of the own node in step S52 in more detail. Hereinafter, the search processing of the own node will be described with reference to FIG.
[0046]
First, one unexamined data set existing in the node is selected (S80). Next, it is checked whether the document type of the data set to be checked matches the specified search type or is a lower-order type. If not, the process jumps to step S88. If it does, the specified search-type plug-in 12 is called, the search condition data is passed to the plug-in 12, and the search by the plug-in 12 is executed (S84). As will be described later, the plug-in 12 calls another plug-in (a plug-in of “parent type”) when necessary, for example, and has a portion where the search condition data is hit in the metadata. The search result is returned to the search engine 11. The search engine 11 temporarily records the result (S86). Then, it is checked whether or not an unexamined data set exists in the own node (S88). If it exists, the process returns to step S80. If not, it means that all searches have been completed for the own node.
[0047]
In the flowchart of FIG. 14, the timing at which the type plug-in 12 is called from the search engine 11 has been described. The type plug-in 12 has a function of returning a result of whether or not a specific one data set hits a given search condition in a search process of the own node (S52). FIG. 5 is a flowchart illustrating the search processing by the type plug-in 12 in step S84 in more detail. Hereinafter, the processing of the type plug-in 12 called from the search engine 11 will be described with reference to FIG.
[0048]
First, it is checked whether or not a value (unique metadata) of an item to be processed by the called type plug-in 12 includes a portion corresponding to a search condition (S101). If the data is found (hit), the searched data set is to be added to the search result list, and the result of the hit is set as a return value, and the process returns to the calling source (S105). If there is no hit, it is checked whether or not the called plug-in has a higher type (S107). If there is no higher-type plug-in, the fact that there was no hit in this data set is returned as a return value. Set and return to the calling source (S113). In the above two cases, the result is determined by this type plug-in. If there is an upper type plug-in in step S107, the search condition data is delivered and the upper type plug-in is called (S109). Similar judgment processing is performed in the upper plug-in. The return value of the higher-level plug-in is set as the return value of the plug-in that called it, and the process returns to the calling source (S111).
[0049]
The above is the search processing operation by the type plug-in 12. In the present system, starting from the unique metadata for the search type, higher-level type plug-ins are called one after another until the metadata content hits the search condition. Each type plug-in checks only its own range (corresponding unique metadata) and if no hit is found, further processing is delegated to the type plug-in of the parent type. By adopting such a system configuration, it becomes easy to realize a type plug-in corresponding to the definition of a new document type, and a flexible document sharing system can be realized.
[0050]
Next, the configuration of the mold plug-in 12 that realizes the operation of the flowchart of FIG. 5 will be described with reference to FIGS. The type plug-in 12 needs to be provided corresponding to the unique metadata type in the metadata. This is because it is necessary to process a metadata part newly defined as an evolved type of the basic type (parent type, upper type). FIG. 11 is a diagram illustrating a logical configuration in a case where a type plug-in corresponding to the unique meeting report type M02 is realized as a class object. The class object P02 holds type definition information P020. In the type definition information P020, a type name (meeting report type), item definition information defining unique metadata, and a type plug-in ID or type name of a parent plug-in are recorded. Further, the class object P02 includes methods of a search result transmitting unit P021, a unique metadata searching unit P022, and a search delegating unit P023 to a parent plug-in.
[0051]
The unique metadata search unit P022 executes the main part of the operation described in the flowchart of FIG. The search result transmitting means P021 is in charge of a process of returning a result processed by the type plug-in to the calling source (child type plug-in or search engine 11). The search delegation means P023 to the parent plug-in executes control to shift the search processing to a higher-level type plug-in in step S109.
[0052]
FIG. 10 is a diagram illustrating a logical configuration when a type plug-in corresponding to the unique report type M01 is realized as a class object. The class object P01 holds type definition information P010. In the type definition information P010, a type name (report type), item definition information defining unique metadata, and a type plug-in ID or type name of a parent plug-in are recorded. Further, the class object P01 includes the respective methods of the search result transmitting means P011 and the unique metadata searching means P012. Since there is no parent type plug-in, search delegation means P013 to the parent plug-in is not provided.
[0053]
If a method for registering and changing metadata is added as a method to the class objects P01 and P02, not only document search but also registration and change of metadata of a shared document can be performed by P01 and P02. It becomes.
[0054]
The embodiment of the present system has been described above in detail. The characteristics of document retrieval by this system are summarized as follows. When a search is performed using a certain search type, for example, a report type, documents that are the development type such as a meeting report type and a business trip report type are also searched. However, in this case, the meeting report type and travel report type documents are treated as report type documents, so only the report type plug-in works, and does the meeting report type plug-in / travel report type document plug-in work? Absent. That is, the meta information of the evolved unique part does not participate in the search. Thus, document types can be defined hierarchically from basic types to their evolved types, but the phylogenetic tree of such types does not need to be fixed from the beginning, but can be You can define a new type and store a new type dataset. Even in such a case, the search can be performed without any trouble in the case of searching for the existing type. When upgrading the file sharing system so that a search can be performed using the new type, it is only necessary to create a type plug-in that handles only the meta information of the developed part and distribute this to each user.
[0055]
For example, at first, only the report type is defined, some shared documents are stored as the report type, and then the meeting report type is defined. When searching by type, all shared documents are searched. Such features of the present system provide operational flexibility to a P2P file sharing system used by many users on an equal basis. Defining meta information suitable for the document to be stored depends on the purpose of creating the document, but the purpose of creating the document depends on the activity theme of the members who use the file sharing system at that time, This is because the theme of the members' activities is not constant and changes over time.
[0056]
【The invention's effect】
As described above in detail, according to the present system, it is possible to realize a P2P type file sharing system that can be searched not only by file name but also by meta information, Even if it becomes necessary to add a new document type, there is a remarkable effect that it can be easily and flexibly handled.
[Brief description of the drawings]
FIG. 1 is a diagram illustrating an outline of a node computer included in a peer-to-peer network system 1 according to an embodiment of the present invention.
FIG. 2 is a diagram illustrating a peer-to-peer network protocol.
FIG. 3 is a diagram illustrating the structure of a data set.
FIG. 4 is a diagram illustrating a configuration example of metadata.
FIG. 5 is a flowchart illustrating the operation of the mold plug-in 12;
FIG. 6 is a diagram illustrating a search processing operation of the system 1.
FIG. 7 is a diagram illustrating a search processing operation of the system 1.
FIG. 8 is an explanatory diagram of three types of metadata types used in the description.
FIG. 9 is an example of a GUI screen for performing a search process.
FIG. 10 is a configuration diagram illustrating a report type plug-in.
FIG. 11 is a configuration diagram illustrating a conference report type plug-in.
FIG. 12 is a diagram illustrating a peer-to-peer network protocol.
FIG. 13 is a diagram illustrating the structure of a data set.
FIG. 14 is a diagram illustrating a configuration example of metadata.
[Explanation of symbols]
1 Document sharing network system
10 node computer
11 Search Engine
12 type plug-in
13 Peer-to-peer network engine
P01 Report type plug-in
P010 Report type plug-in type definition information
P011 Report type plug-in search result transmission means
P012 Report-specific plug-in specific metadata search means
P02 meeting report type plug-in
P020 Meeting report type plug-in type definition information
P021 Meeting report type search result transmission means
P022 Unique metadata search means of conference report type plug-in
P023 Search delegation means of the conference report type plug-in to the parent plug-in

Claims (6)

A document sharing network system in which a plurality of node computers cooperate in an equal relationship,
Each node computer connected to this system stores the shared document as a data set which is a combination of actual file data and metadata describing the actual file data for each defined item. To be held in
In addition, each node computer
A type plug-in that refers to the metadata contained in each stored data set,
A network engine that exchanges information with other node computers by a peer-to-peer network protocol;
A search engine for performing search, reference, transfer, and registration of a data set using the network engine and the type plug-in;
A graphical user interface by which a user gives instructions to the search engine and displays search results by the search engine;
A peer-to-peer type document sharing network system capable of extracting specified data sets by comparing designated search conditions with metadata of each data set and presenting the data sets as search results. 2. The peer-to-peer type document sharing network system according to claim 1, wherein the metadata can define new metadata types (metadata types) one after another by adding an extension to a basic metadata type. Wherein the shared document stored in the system can be classified and managed according to the type of metadata, and the type plug-in is provided according to the metadata type of the shared document. Type document sharing network system. 3. In the peer-to-peer type document sharing network system according to claim 2, when searching for a shared document stored and managed, one metadata type is designated as a search type, so that the search type of the shared document matches the search type. A peer-to-peer document sharing network system, characterized in that a data set corresponding to a metadata type whose basic type is a metadata type and a search type can be limited as a search target. 3. The peer-to-peer type document sharing network system according to claim 2, wherein one type plug-in refers only to the metadata of a specific part corresponding to the type of the corresponding metadata type, and to the meta of the other basic part. By calling the type plug-in of the metadata type on which the data is based repeatedly as necessary, the range of the data described in the metadata type corresponding to the type plug-in of the metadata of the data set to be processed is obtained. A peer-to-peer type document sharing network system characterized by referring to FIG. 3. The peer-to-peer type document sharing network system according to claim 2, wherein a user interface provided when registering the shared document is provided according to a metadata type of the newly registered document. Document sharing network system. 4. The peer-to-peer type document sharing network system according to claim 3, wherein a user interface for specifying a search condition when starting a search is provided according to a specified search type. .

Images