JP4753165B2 - Relay server and relay communication system - Google Patents

Description

  The present invention relates to a relay server and a relay communication system that realize resource sharing via a network.

Conventionally, a communication system called a virtual private network (VPN) is known (for example, Patent Document 1). This VPN is used, for example, for applications in which terminals connected to LANs of a plurality of branch offices (bases) provided for each region communicate via the Internet. Using the VPN, each client terminal can share various resources (folders and files) on a device connected to another remote LAN.
JP 2002-217938 A

  The file sharing via the network as described above has an aspect that damage is easily spread to other devices when the shared file is infected with a computer virus, for example. Therefore, from the viewpoint of security, there has been a demand for a configuration that can easily detect when an unintended change is made to a resource such as a file.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to centrally manage attribute information that can detect falsification of a shared resource together with information on the shared resource in a relay server that realizes virtual resource sharing. And providing a configuration capable of easily detecting tampering or the like.

Means and effects for solving the invention

  According to a first aspect of the present invention, a relay server having the following configuration is provided. That is, the relay server includes a relay group information registration unit, a shared resource information registration unit, and a control unit. The relay group information registration unit stores information on relay groups including other relay servers that can be connected to each other. The shared resource information registration unit stores shared resource information when a resource is shared among a plurality of client terminals in the relay group. This shared resource information includes information related to the resource, attribute information of the resource, and account information of a resource sharing terminal that is a client terminal that shares the resource. The control unit includes an instruction relay unit, an attribute information management unit, and a verification information relay unit. The instruction relay unit relays an operation instruction for a resource registered in the shared resource information to at least one of a client terminal under its control or another relay server. The attribute information management unit registers attribute information related to the resource in the shared resource information by adding information related to the resource to the shared resource information. The verification information relay unit acquires verification information necessary for verification of a target resource from a client terminal capable of operating the resource entity or a relay server under its control in accordance with a relay instruction, and transmits the relay instruction. Relay the verification information to the source.

  With this configuration, it is possible for a plurality of client terminals to share resources with the necessary counterparts via the relay server, and to easily unify management of resource information and attribute information. In addition, since the client terminal can acquire the attribute information of the target resource from the relay server and can acquire the collation information by relay of the relay server, it can verify whether the resource has been tampered with. .

  According to a second aspect of the present invention, a relay server having the following configuration is provided. That is, the relay server includes a relay group information registration unit, a shared resource information registration unit, and a control unit. The relay group information registration unit stores information on relay groups including other relay servers that can be connected to each other. The shared resource information registration unit stores shared resource information when a resource is shared among a plurality of client terminals in the relay group. This shared resource information includes information related to the resource, attribute information of the resource, and account information of a resource sharing terminal that is a client terminal that shares the resource. The control unit includes an instruction relay unit, an attribute information management unit, and a verification unit. The instruction relay unit relays an operation instruction for a resource registered in the shared resource information to at least one of a client terminal under its control or another relay server. The attribute information management unit registers attribute information related to the resource in the shared resource information by adding information related to the resource to the shared resource information. The verification unit, in response to a verification instruction from the resource sharing terminal, acquires verification information necessary for verification of the target resource from a client terminal that can operate the resource entity or a relay server under its control, The target resource is verified based on the attribute information and the collation information.

  With this configuration, it is possible for a plurality of client terminals to share resources with the necessary counterparts via the relay server, and to easily unify management of resource information and attribute information. Further, the client terminal can cause the relay server to verify whether the resource has been tampered with based on the resource attribute information and the collation information.

  In the relay server, it is preferable that the verification unit automatically performs verification on the target resource when an instruction to operate the resource is given.

  With this configuration, each time a resource is operated, the target resource can be automatically verified. Therefore, the resource can be verified without performing verification instructions from the client terminal one by one, so that the burden on the user can be reduced and high security can be realized.

  In the relay server, the control unit preferably stops relaying the operation instruction for the resource when the verification by the verification unit fails.

  With this configuration, it is possible to prevent the client terminal from manipulating resources that may have been tampered with and to achieve high security.

  In the relay server, the attribute information is preferably at least one of an electronic signature, a hash value, and time stamp information.

  With this configuration, resource tampering can be detected easily and powerfully, so that highly reliable verification can be performed.

  In the relay server, the attribute information management unit registers the attribute information created by the client terminal in the shared resource information when the client terminal gives an instruction to share the resource that can operate the entity. Is preferred.

  With this configuration, since the client terminal itself that can operate the resource entity creates attribute information based on the entity, the resource registration process can be simplified.

  Alternatively, the attribute information management unit obtains attribute creation information about the resource from the client terminal when the client terminal gives an instruction to share the resource that can operate the entity, and creates the attribute creation The attribute information can be created from information and registered in the shared resource information.

  In this case, both the creation of the attribute information and the verification based thereon are performed on the relay server side, so that the load on the client terminal can be reduced.

  In the relay server, the control unit preferably notifies the resource sharing terminal when a predetermined period has elapsed since the creation of the attribute information.

  With this configuration, when the reliability of the attribute information decreases with the passage of time, the resource sharing terminal can be automatically notified to call attention. Therefore, higher security can be realized.

  In the relay server, it is preferable that the control unit deletes information related to a resource corresponding to the attribute information from the shared resource information when a predetermined period has elapsed since the attribute information was created.

  With this configuration, when the reliability of the attribute information decreases with time, it is possible to delete the information about the target resource from the shared resource information and stop sharing. Therefore, higher security can be realized.

  According to the 3rd viewpoint of this invention, the relay communication system of the following structures is provided. That is, this relay communication system includes a plurality of relay servers and a plurality of client terminals. The relay server includes a relay group information registration unit, a shared resource information registration unit, and a control unit. The relay group information registration unit stores information on relay groups including other relay servers that can be connected to each other. The shared resource information registration unit stores shared resource information when a resource is shared among a plurality of the client terminals in the relay group. The shared resource information includes information regarding the resource, attribute information of the resource, and account information of the resource sharing terminal that is the client terminal that shares the resource. The control unit includes an instruction relay unit, an attribute information management unit, and a verification information relay unit. The instruction relay unit relays an operation instruction for a resource registered in the shared resource information to at least one of a client terminal under its control or another relay server. The attribute information management unit registers attribute information related to the resource in the shared resource information by adding information related to the resource to the shared resource information. The verification information relay unit acquires verification information necessary for verification of a target resource from a client terminal capable of operating the resource entity or a relay server under its control in accordance with a relay instruction, and transmits the relay instruction. Relay the verification information to the source.

  With this configuration, it is possible for a plurality of client terminals to share resources with the necessary counterparts via the relay server, and to easily unify management of resource information and attribute information. In addition, since the client terminal can acquire the attribute information of the target resource from the relay server and can acquire the collation information by relay of the relay server, it can verify whether the resource has been tampered with. .

  According to the 4th viewpoint of this invention, the relay communication system of the following structures is provided. That is, this relay communication system includes a plurality of relay servers and a plurality of client terminals. The relay server includes a relay group information registration unit, a shared resource information registration unit, and a control unit. The relay group information registration unit stores information on relay groups including other relay servers that can be connected to each other. The shared resource information registration unit stores shared resource information when a resource is shared among a plurality of the client terminals in the relay group. The shared resource information includes information regarding the resource, attribute information of the resource, and account information of the resource sharing terminal that is the client terminal that shares the resource. The control unit includes an instruction relay unit, an attribute information management unit, and a verification unit. The instruction relay unit relays an operation instruction for a resource registered in the shared resource information to at least one of a client terminal under its control or another relay server. The attribute information management unit registers attribute information related to the resource in the shared resource information by adding information related to the resource to the shared resource information. The verification unit, in response to a verification instruction from the resource sharing terminal, acquires verification information necessary for verification of the target resource from a client terminal that can operate the resource entity or a relay server under its control, The target resource is verified based on the attribute information and the collation information.

  With this configuration, it is possible for a plurality of client terminals to share resources with the necessary counterparts via the relay server, and to easily unify management of resource information and attribute information. Further, the client terminal can cause the relay server to verify whether the resource has been tampered with based on the resource attribute information and the collation information.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is an explanatory diagram showing the overall configuration of a relay communication system according to an embodiment of the present invention.

  As shown in FIG. 1, the relay communication system according to the present embodiment includes a plurality of LANs connected to a WAN. This relay communication system includes a relay server 1, an external server 2, a client terminal 5, a file server 6, and the like.

  A WAN (Wide Area Network) is a network that connects different LANs to each other. In the present embodiment, the Internet is used as the WAN.

  A LAN (Local Area Network) is a relatively small network constructed in a limited place. There are a plurality of LANs, and they are constructed at locations physically separated from each other. In this embodiment, it is assumed that the LAN 91 is constructed in the Tokyo branch and the LANs 92, 93, and 94 are constructed in the Osaka branch, the Nagoya branch, and the Fukuoka branch, respectively. These four LANs 91, 92, 93, 94 are connected to the Internet, which is a global network.

  Next, the external server 2 will be described with reference to FIG. FIG. 2 is a functional block diagram of the external server 2. The external server 2 is a device used for communication between the relay servers 1 arranged in each LAN, and is installed on the Internet.

  The external server 2 shown in FIG. 2 has a function as a SIP (Session Initiation Protocol) server. Specifically, the external server 2 has a function as a SIP proxy server that relays SIP methods and responses, and a function as a SIP registrar server that registers an account of the relay server 1.

  As shown in FIG. 2, the external server 2 includes a WAN interface 201, a control unit 202, and a relay server account information database 203 as main components.

  The WAN interface 201 is an interface that communicates with each device such as the relay server 1 connected to the Internet using a global IP address.

  The relay server account information database 203 is a database that manages the account of the relay server 1 that has requested registration in association with the global IP address.

  The control unit 202 is a processing unit that controls various communications performed via the WAN interface 201, and controls communication processing according to a protocol such as TCP / IP, UDP, or SIP. For example, the control unit 202 receives an account of the relay server 1 from each relay server 1 and registers it in the relay server account information database 203. Also, processing such as relaying communication data such as various SIP methods or responses transmitted from the relay server 1 to other relay servers 1 is performed.

  Next, the client terminal 5 will be described with reference to FIG. FIG. 3 is a functional block diagram of the client terminal 5.

  The client terminal 5 is a terminal that can be directly operated by the user, and corresponds to, for example, a personal computer (PC) used for daily work by the user. Accordingly, there are usually a large number of client terminals 5 in the LAN. In this embodiment, as shown in FIG. 1, client terminals 11 and 12 are connected to a LAN 91, and client terminals 21 and 22 are connected to a LAN 92. In addition, client terminals 31 and 32 are connected to the LAN 93, and client terminals 41 and 42 are connected to the LAN 94. Each client terminal 5 is assigned a private IP address that is uniquely managed in the same LAN.

  As shown in FIG. 3, the client terminal 5 includes a LAN interface 601, a control unit 602, a resource storage unit 603, and a shared resource information database 604 as main components.

  The LAN interface 601 is an interface that communicates with each device such as the relay server 1 and the file server 6 connected to the same LAN using the private IP address.

  The resource storage unit 603 stores resource entities such as files or folders that can be operated by the client terminal 5.

  The shared resource information database 604 stores shared resource information describing information of shared resources held by each client terminal 5.

  The control unit 602 is a processing unit that controls various communications performed via the LAN interface 601. The control unit 602 controls communication processing according to a protocol such as TCP / IP, UDP, or SIP.

  For example, the control unit 602 performs processing for controlling the movement, change, or deletion of resources stored in the resource storage unit 603. When the control unit 602 receives the shared resource information change notification from the relay server 1, the control unit 602 performs a process of updating the shared resource information stored in the shared resource information database 604.

  Next, the relay server 1 according to the first embodiment will be described with reference to FIG. FIG. 4 is a functional block diagram of each relay server 1.

  As shown in FIG. 1, one relay server 1 is arranged in each LAN. Specifically, the relay server R1 is arranged in the LAN 91, the relay server R2 is arranged in the LAN 92, the relay server R3 is arranged in the LAN 93, and the relay server R4 is arranged in the LAN 94.

  The relay server 1 is connected to a LAN and can communicate with each client terminal 5 connected to the same LAN. The relay server 1 is also connected to the Internet, and can communicate with the relay server 1 connected to another LAN (via the external server 2). For this communication, each relay server 1 is assigned both a private IP address and a global IP address.

  As shown in FIG. 4, the relay server 1 includes a LAN interface 501, a WAN interface 502, a control unit 503, an account information database 504, a relay group information database 505, and a shared resource information database 506. It is provided as a component.

  The LAN interface 501 is an interface that uses a private IP address to communicate with the client terminal 5 connected to the same LAN as its own device. For example, in the LAN 91, the relay server R 1 can communicate with each of the client terminals 11 and 12 using the LAN interface 501.

  The WAN interface 502 is an interface that communicates with each device such as the external server 2 connected to the Internet using a global IP address.

  Each relay server 1 has a function as a SIP registrar server, and communication between each relay server 1 and each client terminal 5 is performed using SIP. For example, in the LAN 92, the relay server R2 functions as a SIP registrar server, receives the accounts of the client terminals 21 and 22 connected to the LAN 92, and registers them in the account information database 504.

  Therefore, as shown in FIG. 5, the relay server 1 functions as a server that receives an account from the client terminal 5 and registers (REGISTER) in relation to the client terminal 5. In relation to the external server 2, the relay server 1 functions as a client that transmits an account to the external server 2 and registers (REGISTER).

  The account information database 504 in FIG. 4 is a database that manages the account of the client terminal 5 that has requested registration in association with the private IP address.

  A relay group information database (relay group information registration unit) 505 is a database that manages relay group information related to the client terminal 5 registered in the account information database 504.

  A shared resource information database (shared resource information registration unit) 506 is a database that manages shared resource information related to the client terminal 5 registered in the account information database 504.

  The control unit 503 is a processing unit that controls various communications performed via the LAN interface 501 and the WAN interface 502, and controls various communication processes according to protocols such as TCP / IP, UDP, and SIP.

  The control unit 503 executes, for example, processing for transmitting an account of the own apparatus to the external server 2 to request registration, and processing for creating relay group information and storing it in the relay group information database 505. Further, the control unit 503 executes processing for creating shared resource information and storing it in the shared resource information database 506.

  The control unit 503 includes an instruction relay unit 511, an electronic signature information management unit (attribute information management unit) 512, and a hash value information relay unit (collation information relay unit) 513.

  When the instruction relay unit 511 receives an operation instruction such as opening a shared resource from the client terminal 5 or the like, the instruction relay unit 511 relays the operation instruction to a necessary partner (another relay server 1 or the like).

  When a shared resource is added to the shared resource information stored in the shared resource information database 506, the electronic signature information management unit 512 can additionally register the information of the electronic signature data of the shared resource in the shared resource information. It is configured as follows.

  The hash value information relay unit 513 is a hash value necessary for verifying the target shared resource from the relay server 1 or the like under the client terminal 5 that can operate the entity of the shared resource in response to a relay instruction from the client terminal 5 (Collation information) is acquired and relayed to the client terminal 5 that is the transmission source of the relay instruction.

  Next, the file server 6 will be described. As shown in FIG. 1, this file server 6 is connected to a LAN and is configured to be able to communicate with each client terminal 5 connected to the same LAN.

  The file server 6 is configured to store resources such as files or folders, and functions as a resource storage unit that replaces the resource storage unit 603 (FIG. 3) provided in each client terminal 5. That is, in this embodiment, the resources that can be operated by each client terminal 5 are considered to be stored in the local disk of the client terminal 5 or stored in the file server 6 as a network drive. . This file server 6 is not essential for each LAN, and in the example of FIG.

  Next, relay group information and shared resource information, which are information handled in this relay communication system, will be described.

  First, relay group information will be described with reference to FIG. FIG. 6 is a diagram showing an example of the contents of relay group information.

  FIG. 6 shows an example of the contents stored in the relay group information database 505 in the relay server R3. In this example, the relay group information database 505 stores two pieces of relay group information 100a and 100b.

  Each of the relay group information 100a and 100b includes one group identification information 101, information (relay account information) 102 of the relay server 1 that configures the relay group by permitting mutual connection, and resource sharable terminal information 110. And.

  The group identification information 101 is information for identifying the relay group information 100, and is configured to be uniquely identified with a different identification ID every time the relay group information 100 is created. Thereby, the operator or the like can specify the relay group based on the group identification information 101, and can easily change the group configuration.

  The relay account information 102 includes account information of each relay server 1 that configures a relay group by permitting connection to each other. For example, in the relay group information 100a shown on the upper side of FIG. 6, accounts of three relay servers R1, R2, and R3 constituting the relay group are described. In the relay group information 100b shown on the lower side of FIG. 6, an account of one relay server R3 constituting the relay group is described.

  In the relay account information 102, specific names given to the accounts of the respective relay servers 1 are registered together to facilitate user identification. For example, in the relay account information 102a of the relay server R1 (relay-server1), a name (branch office A) is assigned to the account (relay-server1 @ net) of the relay server R1.

  As described above, the relay group information 100a and 100b are created so as to be uniquely identifiable for each relay group. Further, the relay group information 100a, 100b includes an account (relay account information 102) of each relay server that forms a group (relay group) by allowing connection to each other. Therefore, by referring to the relay group information 100a and 100b, it is possible to know which LAN and which LAN form a group.

  Next, the resource sharable terminal information 110 that can be included in the relay group information 100 will be described.

  As shown in FIG. 6, the resource sharable terminal information 110 is registered corresponding to each relay group information 100. For example, the resource sharable terminal information 110a is registered corresponding to the relay group information 100a, and the resource sharable terminal information 110b is registered corresponding to the relay group information 100b.

  Each of the resource sharable terminal information 110a and 110b includes individual terminal information 111 describing the client terminal 5 that is permitted to share resources in the relay group related to the corresponding relay group information 100a and 100b. The individual terminal information 111 is information describing an account of each client terminal 5 that can share resources.

  For example, the relay group information 100a corresponding to the resource sharable terminal information 110a on the upper side of FIG. 6 defines a relay group including three relay servers R1, R2, and R3. As shown in FIG. 1, there are two client terminals 11 and 12 in the LAN 91 to which the relay server R1 is connected. In the example of the resource sharable terminal information 110 a on the upper side of FIG. 6, both of these two units are selected as terminals that can share resources in the relay group, and the account information is registered as the individual terminal information 111. Similarly, in the LAN 92 to which the relay server R2 is connected, both the client terminals 21 and 22 are selected as resource sharable terminals. Although the client terminals 31 and 32 exist in the LAN 93 to which the relay server R3 is connected, in the example of the resource sharable terminal information 110a, only the client terminal 31 is selected as the resource sharable terminal, and the account information is the individual terminal information 111. It is registered as.

  The relay group information 100b corresponding to the resource sharable terminal information 110b on the lower side of FIG. 6 defines a relay group including only the relay server R3. In the example of the resource sharable terminal information 110b, in the LAN 93 to which the relay server R3 is connected, both of the two client terminals 31 and 32 are selected as resource sharable terminals, and the account information is used as the individual terminal information 111. It is registered.

  In the individual terminal information 111, in addition to the account of each resource sharable terminal, the specific name given to the account is registered, and the user can be easily identified. For example, in the case of the client terminal 11, a name (client 11) given to the account (for example, client11@relay-server1.net) is described. Further, the individual terminal information 111 describes affiliation identification data 112 indicating the affiliation of the resource sharable terminal such as the sales department and the development department.

  In the resource sharable terminal information 110, each individual terminal information 111 is described in association with the relay account information 102 of the relay server connected to the same LAN as the resource sharable terminal. For example, the individual terminal information 111 related to the client terminal 11 is described in a form associated with the relay account information 102a of the relay server R1.

  Further, as illustrated in the example of FIG. 6, the relay group information database 505 can store a plurality of relay group information 100 and resource sharable terminal information 110. The client terminal 31 is a resource sharable terminal in both resource sharable terminal information 110a and 110b in the two relay groups, and the individual terminal information 111 is described. Thus, one client terminal 5 can be selected as a resource sharing terminal in a plurality of relay groups, and the resource sharable terminal information 110 to that effect can be stored in the relay group information database 505.

  Each relay group information 100 is exchanged between the relay servers 1 constituting the relay group. For example, the upper relay group information 100a in FIG. 6 is exchanged by three relay servers R1, R2, and R3, and stored in the relay group information database 505 of the respective relay servers R1, R2, and R3. Also, the lower relay group information 100b in FIG. 6 is held only by the relay server R3 and stored in the relay group information database 505 of the relay server R3.

  Next, the content of the shared resource information will be described with reference to FIG. FIG. 7 illustrates the shared resource information 120 stored in the shared resource information database 604 of the client terminal 11. The same information is also stored in the shared resource information database 506 of the relay server R1 connected to the same LAN as the client terminal 11.

  The shared resource information 120 includes account identification information 121 indicating that it is shared resource information related to the client terminal 11 and individual shared resource information 122 related to the client terminal 11.

  The account identification information 121 is information for identifying the shared resource information 120 created for each client terminal 5.

  The individual shared resource information 122 includes shared resource identification information 123, family account information 124, family resource information 125, and the like.

  The shared resource identification information 123 is information for identifying the individual shared resource information 122, and is configured to be uniquely identified by being assigned a different ID each time the individual shared resource information 122 is created. Here, the shared resource identification information 123 is composed of an ID associated with the client terminal 5 that has requested creation of the shared resource information 120 and a name for facilitating the identification. The ID can be, for example, 20071001150032client11 @ relay-server1, and the name that facilitates identification can be, for example, workspace1.

  Thereby, since the user etc. can specify the individual shared resource information 122 based on the shared resource identification information 123, the content can be easily edited.

  The family resource information 125 is a collection of resource information 126 indicating the substance of resources such as files or folders (directories) held by the client terminal 5.

  Each resource information 126 includes information on the name of the shared resource, information on the account of the client terminal 5 (owner client terminal) capable of operating the resource entity, and address information indicating the location of the resource entity. And status information about the resource.

  The name of the resource to be shared is a name given to the resource when the resource is shared by a plurality of client terminals 5, and is described as name = “folderA”, for example. In the account information of the owner client terminal, an account for identifying the owner client terminal is described as, for example, owner = “client11@relay-server1.net”. The address indicating the actual location of the resource indicates the location where the shared resource is actually stored in the resource storage unit 603 (or the file server 6). For example, value = “c: / folderA” using a full path. And so on. The status information is information indicating the state of the resource, and is described as, for example, status = “ok”.

  In addition, the resource information 126 can include electronic signature information necessary for verifying that the resource has not been tampered with, if necessary. For example, in the family resource information 125a of FIG. In the resource information 126 related to the shared resource of xls, the file name of the electronic signature is described as “signature =“ es.p7s ””, and the electronic signature information 129 is configured thereby. In the family resource information 125b, the name is file00A. In the resource information 126 related to the shared resource of xls, the file name of the electronic signature is described as “signature =“ es2.p7s ”, and the electronic signature information 129 is configured. These electronic signature files are created by the relay server 1 and stored in appropriate storage means of the relay server 1.

  The family account information 124 is a collection of information of accounts (for example, client11@relay-server1.net) of the client terminals 5 that share the resource entity indicated by the family resource information 125.

  In the example of the family resource information 125a in FIG. A client terminal (user client terminal) capable of indirectly manipulating the resource entity via the owner client terminal 11 is a client terminal described in the family account information 124 of FIG. 7 other than the owner client terminal 11. Is. That is, in this example, the client terminal 21 is a user client terminal.

  As shown in FIG. 7, a plurality of family resource information 125 can be described, and the owner client terminals described in each family resource information 125 may be different from each other. Therefore, the relationship between the owner client terminal and the user client terminal is not fixed, and any client terminal described in the family account information 124 can be an owner account terminal. In the following description, the client terminal described in the family account information 124 may be referred to as a shared member terminal.

  Each of the client terminals 11 and 21 which are shared member terminals in the example of FIG. 7 is the same as one of the three relay servers R1, R2 and R3 constituting the relay group described by the relay group information 100a of FIG. Connected to LAN. Each shared member terminal is a client terminal in which individual terminal information 111 is described as a resource sharable terminal in the resource sharable terminal information 110a in the relay group.

  Each of the shared member terminals stores the shared resource information 120 having the individual shared resource information 122 having the above-described contents in the shared resource information database 604.

  Next, the generation and registration steps of the relay group will be described with reference to sequence numbers 11 to 19 in FIG. The processing of sequence numbers 11 to 19 shown in FIG. 8 is generally performed as a network initial setting by a user and an operator.

  First, in the relay server R1, a method (createGroup method) for newly forming a relay group with the relay server R2 is executed by the operator. In this createGroup method, an account (relay-server2 @ net) of the relay server R2 that forms the relay group is specified.

  Then, the relay group information 100a is newly created in the relay server R1. At this time, an identification ID (0001 @ relay-server1) is assigned to the relay group information and described in the group identification information 101.

  Next, a message transmission command (MESSAGE method) is executed in the relay server R1, and a group-info message for the partner relay server R2 is transmitted to the external server 2 (sequence number 11). This message includes the identification ID of the relay group information created by the createGroup method.

  In this MESSAGE method, an account (sip: relay-server2 @ net) of the relay server R2 that is the message transmission destination is specified. The external server 2 acquires the global IP address of the relay server R2 by referring to the relay server account information database 203, and relays the group-info message from the relay server R1 to the relay server R2. The relay server R2 that has received the message returns an OK response to the relay server R1 via the external server 2.

  As described above, communication between each relay server 1 of the present embodiment is performed via the external server 2, and the same applies to the following. Therefore, in the following description, a specific description of communication processing via the external server 2 is omitted.

  Next, the relay server R1 transmits a server information transmission request message (request-server-info message) to the relay server R2 (sequence number 12). The relay server R2 that has received this message returns information (server-info) about itself together with the OK response to the relay server R1.

  On the contrary, the relay server R2 transmits a request-server-info message to the relay server R1 (sequence number 13), and the relay server R1 returns information (server-info) about itself to the relay server R2.

  As described above, by exchanging information about each other's servers, the information of both relay servers R1, R2 is described in the relay account information 102 included in the relay group information 100, and the relay group information database of each relay server R1, R2 505 is stored.

  Next, in the relay server R2, a method (addGroup method) for newly adding the relay server R3 to the previously created relay group (relay group composed of the relay servers R1 and R2) is executed by the operator. In this addGroup method, the account (relay-server3 @ net) of the relay server R3 to be joined and the identification ID (0001 @ relay-server1) of the relay group to be joined are designated.

  Then, the relay server R2 transmits a group-info message to the relay server R3 that is a partner to join (sequence number 14). This message includes the identification ID of the relay group specified by the addGroup method. Receiving this, the relay server R3 returns an OK response to the relay server R2. Next, server information is exchanged between the relay server R2 and the relay server R3 in exactly the same manner as described for the sequence numbers 12 and 13 (sequence numbers 15 and 16).

  Next, the relay server R2 transmits an update-group-info message notifying that the relay server R3 has joined the relay group to the relay server R1 (sequence number 17). Receiving this, the relay server R1 returns an OK response to the relay server R2. Thereafter, server information is exchanged between the relay server R3 and the relay server R1 (sequence numbers 18, 19).

  As described above, the relay group information 100 (specifically, the information indicated by reference numeral 100a in FIG. 6) that the three relay servers R1, R2, and R3 form a relay group is included in each relay server R1. , R2 and R3 are stored in the relay group information database 505.

  Although not shown in FIG. 8, the createGroup method is further executed in the relay server R3 without designating another relay server that forms the relay group. As a result, the relay group information 100b formed only from the relay server R3 is created, given an identification ID (0002 @ relay-server2), and stored in the relay group information database 505 of R3.

  Next, with reference to sequence numbers 21 to 29 in FIG. 9, the registration stage of the resource sharable terminals for the relay group will be described.

  In the relay server R1, a method for registering the client terminal 11 as a resource sharable terminal (addTerminal method) is executed by the operator in a relay group including three relay servers R1, R2, and R3. In this addTerminal method, an account of the client terminal 11 and an identification ID (0001 @ relay-server1) indicating the relay group of the registration destination are specified.

  When this addTerminal method is executed, the relay server R1 searches its own relay group information database 505. Then, the individual terminal information 111 of the client terminal 11 is added to the resource sharable terminal information 110 corresponding to the relay group information of the specified identification ID.

  Immediately thereafter, the relay server R1 specifies the relay group information 100 from the storage contents of the relay group information database 505 by the identification ID, and checks which relay server 1 is configured with the relay group. Then, it can be seen from the relay group information 100a in FIG. 6 that the target relay group is composed of itself (the relay server R1) and the two relay servers R2 and R3.

  Therefore, the relay server R1 first transmits an add-group-info message for requesting addition of a resource sharable terminal to the relay group to the relay server R2 (sequence number 21). This message includes the account of the target client terminal 11, the identification ID of the registration destination relay group, and the like. The relay server R2 that has received this adds the individual terminal information 111 of the client terminal 11 to the resource sharable terminal information 110 stored in the relay group information database 505, and then returns an OK response.

  Next, the relay server R1 transmits a group-info message to the client terminal 11 (sequence number 22). This message includes resource sharable terminal information 110 to which the individual terminal information 111 of the client terminal 11 is added. Receiving this, the client terminal 11 stores the content of the received resource sharable terminal information 110 in an appropriate storage unit.

  Subsequently, the relay server R1 also transmits an add-group-info message requesting addition of a resource sharable terminal to the relay group to the relay server R3 (sequence number 23). The relay server R3 that has received this adds the individual terminal information 111 of the client terminal 11 to the resource sharable terminal information 110 stored in the relay group information database 505, and then returns an OK response.

  As described above, the individual terminal information of the client terminal 11 as the resource sharable terminal is added to the resource sharable terminal information 110 in the relay group information 100 stored in the relay group information database 505 of the three relay servers R1, R2, and R3. 111 is registered.

  Next, in the relay server R2, a method (addTerminal method) for specifying the above-described relay group identification ID and registering the client terminal 21 as a resource sharable terminal is executed by the operator.

  Then, the relay server R2 searches its own relay group information database 505, and adds the individual terminal information 111 of the client terminal 21 to the resource sharable terminal information 110 corresponding to the relay group information specified by the identification ID.

  Next, the relay server R2 transmits an add-group-info message for requesting addition of a resource sharable terminal to the relay group to the relay server R1 (sequence number 24). This message includes the account of the target client terminal 21, the identification ID of the registration-destination relay group, and the like.

  Receiving this, the relay server R1 adds the individual terminal information 111 of the client terminal 21 to the resource sharable terminal information 110 stored in the relay group information database 505. Further, the relay server R1 is connected to the same LAN as itself, and transmits an add-group-info message to the client terminal 11 already stored as a resource sharable terminal (sequence number 24.1). The client terminal 11 that has received this message stores the individual terminal information 111 of the client terminal 21 in an appropriate storage means. Thereafter, the client terminal 11 returns an OK response to the relay server R1, and the relay server R1 that has received the response returns an OK response to the relay server R2.

  Further, the relay server R2 transmits a group-info message to the client terminal 21 (sequence number 25). This message includes resource sharable terminal information 110 to which the individual terminal information 111 of the client terminals 11 and 21 is added. Receiving this, the client terminal 21 stores the content of the received resource sharable terminal information 110 in an appropriate storage means.

  Subsequently, the relay server R2 also transmits an add-group-info message requesting addition of a resource sharable terminal to the relay group to the relay server R3 (sequence number 26). The relay server R3 that has received this adds the individual terminal information 111 of the client terminal 21 to the resource sharable terminal information 110 stored in the relay group information database 505, and then returns an OK response.

  As described above, the resource sharable terminal information 110 in the relay group information 100 stored in the relay group information database 505 of the three relay servers R1, R2, and R3 has the client terminals 11 and 21 as resource sharable terminals. The individual terminal information 111 is registered.

  Next, in the relay server R3, a method (addTerminal method) for specifying the above-described relay group identification ID and registering the client terminal 31 as a resource sharable terminal is executed by the operator.

  Then, the relay server R3 searches its own relay group information database 505, and adds the individual terminal information 111 of the client terminal 31 to the resource sharable terminal information 110 related to the relay group specified by the identification ID.

  Further, the relay server R3 transmits an add-group-info message for requesting addition of a resource sharable terminal to the relay group to the relay server R1 (sequence number 27). This message includes the account of the target client terminal 31, the identification ID of the registration destination relay group, and the like.

  Receiving this, the relay server R1 adds the individual terminal information 111 of the client terminal 31 to the resource sharable terminal information 110 stored in the relay group information database 505. Further, the relay server R1 is connected to the same LAN as itself, and transmits an add-group-info message to the client terminal 11 already stored as a resource sharable terminal (sequence number 27.1). The client terminal 11 that has received this message stores the individual terminal information 111 of the client terminal 31 in an appropriate storage means. Thereafter, the client terminal 11 returns an OK response to the relay server R1, and the relay server R1 that has received this returns an OK response to the relay server R3.

  Next, the relay server R3 transmits a group-info message to the client terminal 31 (sequence number 28). This message includes resource sharable terminal information 110 to which the individual terminal information 111 of the client terminal 31 is added. Receiving this, the client terminal 31 stores the content of the received resource sharable terminal information 110 in an appropriate storage means.

  Subsequently, the relay server R3 also transmits an add-group-info message requesting addition of a resource sharable terminal to the relay group to the relay server R2 (sequence number 29). Receiving this, the relay server R2 adds the individual terminal information 111 of the client terminal 31 to the resource sharable terminal information 110 stored in the relay group information database 505. Further, the relay server R2 is connected to the same LAN as itself, and transmits an add-group-info message to the client terminal 21 already stored as a resource sharable terminal (sequence number 29.1). The client terminal 21 that has received this message stores the individual terminal information 111 of the client terminal 31 in an appropriate storage means. Thereafter, the client terminal 21 returns an OK response to the relay server R2, and the relay server R2 that has received the response returns an OK response to the relay server R3.

  Thus, the client terminals 11, 21, and 31 as resource sharable terminals are added to the resource sharable terminal information 110 in the relay group information 100 stored in the relay group information database 505 of the three relay servers R1, R2, and R3. The individual terminal information 111 is registered.

  Although not shown in FIG. 9, an operation of adding the client terminals 12 and 22 to the relay group information (identification ID is 0001 @ relay-server1) is further performed. As a result, the individual terminal information 111 of the client terminals 11, 12, 21, 22, and 31 is registered as resource sharable terminals in the resource sharable terminal information 110 in the relay group information 100 (reference 110a in FIG. 6). reference). Further, in the relay server R3, an operation of adding the client terminals 31 and 32 to other relay group information (identification ID is 0002 @ relay-server2) is continuously performed.

  In addition, although the process which registers a client terminal as a resource sharable terminal was demonstrated in FIG. 9, the relay server 1 can also perform the process (deleteTerminal method) which removes the registration as a resource sharable terminal of the client terminal 5. FIG. In this case, the individual terminal information 111 of the designated client terminal 5 is deleted from the resource sharable terminal information 110.

  Next, the operation when the resources of the client terminal 5 are actually shared will be described with reference to FIG. Here, the client terminal 11 creates a shared resource, attaches an electronic signature to the file “estimate.xls” held by the client terminal 11, and in the relay group whose identification ID is 0001 @ relay-server 1 An example of sharing with the client terminal 21 will be described.

  The user operates the client terminal 11 to designate a relay group whose identification ID is 0001 @ relay-server1, and then instructs the client terminal 11 to display the resource sharable terminals in the relay group. The client terminal 11 acquires information on the resource sharable terminals through communication with the relay server R1, and displays a list of resource sharable terminals in the designated relay group on the screen.

  Here, since the relay group with the identification ID 0001 @ relay-server1 is designated, the four client terminals 12, 21, 22, and 31 share resources based on the resource sharable terminal information 110a shown on the upper side of FIG. Displayed as a possible terminal. The user designates the client terminal 21 as a terminal (the user client terminal) that actually shares resources.

  Further, the user operates the client terminal 11 and designates a file stored in the resource storage unit 603 of the client terminal 11 as a resource to be shared. This time, it is assumed that a file “Quote.xls” is specified. Further, the client terminal 11 inquires of the user about the name for sharing the file. In this description, it is assumed that the user designates “file00ZX.xls” as the name at the time of sharing.

  Note that, in the sequence diagrams after FIG. 10, the folder in which the actual “estimate.xls” file is stored is indicated by reference numeral 11f. In the sequence diagram, the file “estimate.xls” that is the object of this time is represented as file001 for convenience.

  When the above operation is completed, the client terminal 11 first executes a ReadFile command to read and acquire the contents of the target file stored in the folder 11f (sequence number 31). Subsequently, the client terminal 11 executes an electronic signature command (ES command). By this electronic signature command, a hash value is calculated for the content of the object file, and the electronic signature data can be obtained by encrypting the hash value. In the present embodiment, a standard group of cryptographic techniques using a public key (Public Key Cryptography Standard, PKCS) is used as the encryption method.

  Thereafter, the client terminal 11 transmits a shared resource creation request (createSharedResource command) to the relay server R1 (sequence number 31 in FIG. 10). This message includes designation of a sharing partner, designation of a file to be shared (including designation of a name at the time of sharing), and electronic signature data created by performing the above processing on the file. .

  Receiving this, the relay server R1 first executes the Save command, and saves the data of the electronic signature received from the client terminal 11 in a suitable storage unit with the file name “es.p7s”. Next, the relay server R1 creates the shared resource information 120 and stores it in its own shared resource information database 506.

  The shared resource information 120 stored at this time includes the account of the client terminals 11 and 21 described in the family account information 124 (FIG. 7) and the resource of the current target file (entity name “estimate.xls”). Information 126 is described in the family resource information 125. Further, in the resource information 126 relating to the resource whose entity name is “estimate.xls”, as the electronic signature information (attribute information) 129, the file name of the above-mentioned electronic signature is “signature =“ es.p7s ”. Described.

  Then, the relay server R1 refers to the contents of the relay group information database 505 based on the identification ID of the relay group, transmits an updateResource message to the other relay server R2 constituting the relay group, and the created shared resource Information 120 is notified (sequence number 32.1). The updateResource message is also transmitted to the relay server R3. In this case, the number of member terminals is only 11 and 21, and the relay server R3 does not play an important role in the communication processing. A description of the communication process related to the server R3 is omitted.

  The relay server R2 that has received the message stores the shared resource information 120 in its shared resource information database 506. Further, the relay server R2 transmits an updateResource command to the designated client terminal 21 and notifies the shared resource information 120 (sequence number 32.1.1).

  The user client terminal 21 that has received the updateResource command changes the shared resource information 120 stored in its own shared resource information database 604. Thereafter, the user client terminal 21 returns an OK response to the transmission source relay server R2, and the relay server R2 that has received the OK response returns an OK response to the relay server R1.

  As described above, the shared resource identification information 123 and the family account information 124 are described in the shared resource information 120 stored in the shared resource information database 506 of the relay servers R1, R2, and R3. Furthermore, resource information (reference numeral 126 in FIG. 7) indicating the substance of the shared resource is added to the shared resource information 120 as family resource information 125. The resource information 126 includes the electronic signature information 129. The same content is also described in the shared resource information 120 stored in the shared resource information database 604 of the client terminals 11 and 21.

  Next, a process when the user client terminal 21 opens the shared resource added by the above process will be described. In this description, it is assumed that the user performs an appropriate operation on the client terminal 21 to instruct to open the specified shared resource.

  Then, the OpenFile command is executed in the client terminal 21, and an electronic signature data acquisition request (GetES command) is immediately transmitted from the client terminal 21 to the relay server R2 (sequence number 33). The relay server R2 that has received the electronic signature data acquisition request transmits a getES message to the relay server R1 that has the owner client terminal 11 under control (sequence number 33.1). The relay server R1 that has received this message transmits the electronic signature data stored in itself to the relay server R2, and the relay server R2 relays the electronic signature data to the client terminal 21. Subsequently, the client terminal 21 executes a Decode command, and extracts a hash value by decoding the received electronic signature data.

  Next, the client terminal 21 transmits a hash value acquisition request (GetHashCode command) as collation information to the relay server R2 (sequence number 34). This GetHashCode command includes the designation of the owner client terminal (that is, the client terminal 11) and the designation of the shared resource for which the hash value is to be calculated.

  The relay server R2 that has received this command checks the relay group information 100 stored in its own relay group information database 505. Then, it is understood that the instructed client terminal 11 is under the relay server R1. Therefore, the relay server R2 transmits a getHashCode message to the relay server R1 (sequence number 34.1). The relay server R1 that has received the message transmits a GetHashCode command to the client terminal 11 under its control (sequence number 34.1.1). Upon receiving this command, the client terminal 11 executes the ReadFile command to read the file entity (sequence number 34.1.1.1), calculates the hash value, and transmits it to the relay server R1. The hash value data is transmitted from the relay server R1 to the client terminal 11 via the relay server R2.

  Next, the client terminal 21 executes a Validation command to check whether or not the hash value extracted from the electronic signature data matches the hash value calculated by the owner client terminal 11. As a result, it is assumed that the hash values match this time and it is confirmed that the shared resource has not been tampered with.

  When the verification of the shared resource is thus successful, the client terminal 21 transmits a file open request (OpenFile command) to the relay server R2 (sequence number 35). This OpenFile command includes designation of the owner client terminal (that is, client terminal 11) and designation of the shared resource to be opened. Receiving this command, the relay server R2 transmits a connection request (INVITE method) to the relay server R1 (sequence number 35.1). The relay server R1 that has received the connection request transmits a file open request (OpenFile) to the client terminal 11 (sequence number 35.1.1). The client terminal 11 that has received the file open request confirms that the target resource can be operated and returns an OK response to the relay server R1, and the relay server R1 returns an OK response to the relay server R2.

  The relay server R2 that has received the OK response transmits a MediaSession command to the relay server R1, thereby establishing a communication path between the relay servers R2 and R1 (sequence number 35.2). The relay server R1 that has received the MediaSession command transmits the MediaSession command to the client terminal 11, thereby establishing a communication path between the relay server R1 and the client terminal 11 (sequence number 35.2.1). Thereafter, the client terminal 11 executes a ReadFile command (sequence number 35.2.1.1.1), reads the target resource, and transmits it to the relay server R1. The target resource is transferred from the relay server R1 to the relay server R2, and further transferred to the client terminal 21. As described above, the actual data of the shared resource is transmitted to the client terminal 21, and the client terminal 21 performs processing for opening the data.

  The above sequence numbers 35 to 35.2.1.1.1 are processes when the hash values match and the verification is successful, but the verification may fail. Hereinafter, with reference to FIG. 11, processing when verification fails will be described.

  In the verification command of the client terminal 21, if the hash value extracted from the electronic signature does not match the hash value calculated from the file entity, an error notification process (NotifyError command) is performed in the client terminal 21, as shown in FIG. Is executed. As a result, an error message indicating that verification of the shared resource has failed is displayed on the display of the client terminal 21.

  Further, the client terminal 21 transmits a file error notification (ErrorFile command) to the relay server R2 (sequence number 36). This ErrorFile command includes the designation of the owner client terminal (that is, the client terminal 11) and the designation of the shared resource that is the target of the error. Receiving this, relay server R2 transmits an errorFile message to relay server R1 (sequence number 36.1).

  The relay server R1 that has received the errorFile message transmits an ErrorFile command to the client terminal 11 (sequence number 36.1.1), and the client terminal 11 that has received the errorFile command executes the NotifyError command. As a result, an error message indicating that verification of the shared resource has failed is also displayed on the display of the client terminal 11. Thereafter, the client terminal 11 returns an OK response to the transmission source relay server R1, and the relay server R1 that has received the OK response returns an OK response to the relay server R2.

  Next, the client terminal 21 automatically executes a command (DeleteResource command) for deleting the shared resource that has failed verification. When this command is executed, the client terminal 21 deletes the resource information 126 related to the target shared resource from the shared resource information 120 stored in the shared resource information database 604.

  Thereafter, the client terminal 21 transmits a shared resource information update request (UpdateResource command) to the relay server R2, and notifies the updated shared resource information 120 (sequence number 37). Receiving this update request, the relay server R2 stores the notified shared resource information 120 in the shared resource information database 604 and transmits an updateResource message to the relay server R1 (sequence number 37.1). The relay server R1 that has received this message stores the updated shared resource information 120 in the shared resource information database 604 in the same manner as the relay server R2. Further, the relay server R1 transmits an UpdateResource command to the client terminal 11 and similarly updates the shared resource information 120 (sequence number 37.1.1).

  Next, with reference to FIG. 12, the details of processing when the client terminal 5 adds its own file as a shared resource will be described. FIG. 12 is a flowchart illustrating an operation when the shared resource of the client terminal 5 is added in the relay communication system according to the first embodiment. The flowchart of FIG. 12 substantially corresponds to the processing (sequence numbers 31 to 32) of the client terminal 11 in FIG.

  As shown in FIG. 12, the client terminal 5 stands by until an instruction to add a shared resource is given (S101). When an instruction to add a shared resource is given, the client terminal 5 inquires about a shared resource (file) to be added (S102). . In response to this inquiry, the user appropriately selects a file to be shared.

  Next, the client terminal 5 inquires whether or not to add the electronic signature information to the shared resource information (S103). The user can select whether to give an electronic signature to this inquiry.

  When the user selects to give the electronic signature information, the client terminal 5 reads the designated file entity, calculates the hash value, and creates the electronic signature data (S104). Thereafter, the client terminal 5 adds the resource information 126 of the target file to the shared resource information 120 stored in the shared resource information database 604 (S105). Further, the client terminal 5 transmits an update command for the shared resource information 120 to the relay server 1 with the electronic signature data (S106).

  On the other hand, if the user selects not to add the digital signature information in the determination of S103, the resource information 126 of the target file is added to the shared resource information 120 (S107), and the update command for the shared resource information 120 is relayed. It transmits to the server 1 (S108).

  Next, with reference to FIG. 13, the details of the processing when the client terminal 5 opens the shared resource will be described. FIG. 13 is a flowchart illustrating the operation of the client terminal 5 when the shared resource is opened in the relay communication system according to the first embodiment. The flowchart in FIG. 13 substantially corresponds to the processing (sequence numbers 33 to 36.1.1) of the client terminal 21 in FIGS. 10 and 11.

  As shown in FIG. 13, the client terminal 5 waits until an instruction to open a shared resource is received (S201). When an instruction to open a shared resource is given, electronic signature information is added to the target shared resource. Is checked based on the shared resource information 120 (S202).

  If the electronic signature information is given, the client terminal 5 checks whether the owner of the designated shared resource is other than itself (S203). If the owner of the shared resource is other than itself (that is, if the owner is a user client terminal), a hash data acquisition command is transmitted to the relay server 1 (S204), and the hash value data calculated by the owner client terminal is transmitted. Received and acquired via the relay server 1 (S205). On the other hand, when the owner of the shared resource is itself (that is, when the owner is the owner client terminal), the shared resource itself reads the file entity, calculates the hash value data, and acquires it (S206).

  Next, the client terminal 5 acquires the electronic signature data from the relay server 1 (S207), and extracts the hash value by decoding (decoding) this (S208). Then, it is checked whether or not the hash value obtained in S205 or S206 matches the hash value obtained in S208 (S209). As a result, if the hash values do not match, the user is notified that tampering has been detected (verification has failed) (S210).

  If the hash values match in the determination in S209, and if the digital signature information is not given in the determination in S202, the client terminal 5 determines whether the owner of the designated shared resource is other than itself. It is checked whether or not (S211). If the owner of the shared resource is other than itself (that is, if it is a user client terminal), a file entity data transfer command is transmitted to the relay server 1 (S212), and the file entity data is transmitted via the relay server 1. Receive and obtain (S213). On the other hand, when the owner of the shared resource is itself (that is, when the owner is the owner client terminal), the owner of the shared resource reads the file entity. Thereafter, a process for opening the obtained file entity data is performed (S214).

  With the above configuration, resources can be shared between the plurality of client terminals 11 and 21 as necessary. In addition, when a resource is shared, an electronic signature is calculated, and this is compared with the hash value calculated from the file entity, so that unintentional alteration of the shared resource can be detected, and highly secure file sharing can be achieved. Can be realized.

  As described above, the relay server 1 of this embodiment includes the relay group information database 505, the shared resource information database 506, and the control unit 503. The relay group information database 505 stores relay group information (relay group information 100) including other relay servers that can be connected to each other. The shared resource information database 506 stores shared resource information 120 when resources are shared among a plurality of client terminals 5 in the relay group. This shared resource information 120 includes family resource information 125 that is information of the resource, electronic signature information 129 of the resource, and account information of the resource sharing terminal that is a client terminal that shares the resource (family account information 124). And including. The control unit 503 includes an instruction relay unit 511, an electronic signature information management unit 512, and a hash value information relay unit 513. Then, for example, as indicated by sequence numbers 35 and 35.1 in FIG. 10, the instruction relay unit 511 of the relay server R2 sends an operation instruction for the resource registered in the shared resource information 120 to the client under its control. Relay to terminal 5 or another relay server 1. Further, as indicated by the sequence number 32, the electronic signature information management unit 512 of the relay server R1 adds the information related to the resource to the shared resource information 120, whereby the electronic signature information 129 related to the resource is added to the shared resource information 120. Register with. Further, as shown in sequence numbers 34 and 34.1, the hash value information relay unit 513 of the relay server R2 can operate the resource entity 11 in accordance with the relay instruction (GetHashCode command) of the client terminal 21. Is acquired from the relay server R1 under the control, and the hash value information is relayed to the client terminal 21 that is the transmission source of the relay instruction.

  As a result, the plurality of client terminals 5 can share resources with the necessary counterparts via the relay server 1, and the centralization of management of resource information and attribute information can be easily realized. In addition, since the client terminal 5 can acquire the digital signature data of the target resource from the relay server 1 and can acquire the hash value information necessary for verification by relaying the relay server, whether the resource has been tampered with. Etc. can be verified.

  In the present embodiment, the shared resource information 120 includes electronic signature information 129, and the shared resource can be verified by the electronic signature.

  Thereby, it is possible to easily and powerfully detect falsification of a shared resource using an electronic signature, and to perform highly reliable verification.

  In the present embodiment, as indicated by the sequence number 32 in FIG. 10, the electronic signature information management unit 512 of the control unit 503 of the relay server R1 is created by the owner client terminal 11 that has given an instruction to share resources using an ES command. The digital signature data is registered in the shared resource information 120.

  As a result, the client terminal itself capable of operating the resource entity creates the electronic signature data based on the entity, thereby simplifying the shared resource registration process.

  Next, a second embodiment of the present invention will be described. In addition, in this 2nd Embodiment, the same code | symbol is attached | subjected to drawing in the same or similar member as the said 1st Embodiment, and description is abbreviate | omitted. FIG. 14 is a functional block diagram of the relay server 1 according to the second embodiment.

  As shown in FIG. 14, the control unit 503 of the relay server 1 according to the second embodiment omits the hash value information relay unit 513 provided in the first embodiment, and includes a verification unit 514 instead. Yes. In response to a shared resource verification instruction from the client terminal 5, the verification unit 514 obtains a hash value necessary for verification of the target shared resource from the owner client terminal 5 of the shared resource or the relay server 1 having the shared resource. The shared resource is acquired and verified based on the electronic signature data of the electronic signature information 129 and the hash value.

  Next, the operation when the resources of the client terminal 5 are actually shared in the second embodiment will be described with reference to FIG. Here, a virtual place (shared resource information) for sharing resources between the two client terminals 11 and 21 is created in advance, and the file “doc001. An example in which an electronic signature is attached to xls "and shared with the client terminal 11 will be described.

  The user operates the client terminal 21 and designates a file stored in the resource storage unit 603 of the client terminal 21 as a resource to be shared. It is assumed that a file “doc001.xls” is specified this time. Further, the client terminal 11 inquires of the user about the name for sharing the file. In this description, it is assumed that the user designates “file00A.xls” as the name at the time of sharing.

  Note that in the sequence diagrams after FIG. 15, the folder in which the entity of the file “doc001.xls” is stored is indicated by reference numeral 21f. In the sequence diagram, the file “doc001.xls” that is the object of this time is represented as “file002” for convenience.

  When the above operation is completed, the client terminal 21 first executes a ReadFile command, and reads and acquires the content of the target file stored in the folder 21f (sequence number 41 in FIG. 15). Next, the client terminal 21 transmits a resource addition request (addResource command) to the relay server R1 (sequence number 42). This command includes specification of shared resource information, specification of a file to be shared (including specification of a name at the time of sharing), specification of giving an electronic signature, and hash value data calculated from the entity of the file And are included.

  Receiving this, the relay server R2 executes an electronic signature command (ES command) and encrypts the hash value received from the client terminal 21 to create electronic signature data. Next, the relay server R2 executes a Save command and saves the created electronic signature data in an appropriate storage unit with the file name “es2.p7s”. Further, the relay server R2 executes an updateResource command to update the shared resource information 120 stored in its own shared resource information database 506.

  Through the above processing, the shared resource information 120 stored in the shared resource information database 506 is the resource information 126 of the current target file (entity name “doc001.xls”) described in the family resource information 125. Further, in the resource information 126 relating to the resource whose entity name is “doc001.xls”, the file name of the above-mentioned electronic signature is described as “signature =“ es2.p7s ”as the electronic signature information (attribute information) 129. Is done.

  Then, the relay server R2 transmits an updateResource message to the other relay server R2 (R3) configuring the relay group, and notifies the updated shared resource information 120 (sequence number 43). Further, the relay server R2 transmits an updateResource command to the client terminal 21 under its control, and notifies the updated shared resource information 120 (sequence number 44).

  The relay server R1 that has received the updateResource message stores the shared resource information 120 in its shared resource information database 506. In addition, the relay server R1 transmits an updateResource command to the client terminal 11 under its control, and notifies the shared resource information 120 (sequence number 43.1).

  The user client terminal 11 that has received the updateResource command from the relay server R1 changes the shared resource information 120 stored in its own shared resource information database 604. Thereafter, the user client terminal 11 returns an OK response to the transmission source relay server R1, and the relay server R1 that has received the OK response returns an OK response to the relay server R2. Further, the client terminal 21 that has received the updateResource command from the relay server R2 changes the shared resource information 120 stored in its own shared resource information database 604. Thereafter, the client terminal 21 returns an OK response to the transmission source relay server R2.

  Next, a process when the user client terminal 11 opens the shared resource added by the above process will be described. In this description, it is assumed that the user performs an appropriate operation on the client terminal 11 to instruct to specify and open the shared resource added earlier.

  Then, the client terminal 11 transmits a file open request (OpenFile command) to the relay server R1 (sequence number 45). This OpenFile command includes the designation of the owner client terminal (that is, the client terminal 21) and the designation of the shared resource to be opened. Receiving this command, the relay server R1 transmits a connection request (INVITE method) to the relay server R2 (sequence number 45.1). The relay server R2 that has received the connection request transmits a GetHashCode command to the owner client terminal 21 under its control (sequence number 45.1.1). Upon receiving this command, the client terminal 21 executes a ReadFile command to read the file entity (sequence number 45.1.1.1.1), calculates a hash value, and transmits the hash value to the relay server R2.

  Next, the relay server R2 checks the electronic signature information 129 of the shared resource information 120, reads out the electronic signature data stored in itself, decodes (decodes) this, and calculates a hash value. Then, the relay server R2 executes the Validation command and checks whether or not the hash value obtained by decrypting the electronic signature data matches the hash value calculated by the owner client terminal 11. As a result, it is assumed that the hash values match this time and it is confirmed that the shared resource has not been tampered with.

  Then, the relay server R2 transmits a file open request (OpenFile) to the client terminal 21 (sequence number 45.2.1). The client terminal 21 that has received the file open request confirms that the target resource can be operated, returns an OK response to the relay server R2, and the relay server R2 returns an OK response to the relay server R1.

  The relay server R1 that has received the OK response transmits a MediaSession command to the relay server R2, thereby establishing a communication path between the relay servers R1 and R2 (sequence number 45.2). The relay server R2 that has received the MediaSession command transmits the MediaSession command to the client terminal 21, thereby establishing a communication path between the relay server R2 and the client terminal 21 (sequence number 45.2.1). Thereafter, the client terminal 11 executes a ReadFile command (sequence number 45.2.1.1.1), reads the target resource, and transmits it to the relay server R2. The target resource is transferred from the relay server R2 to the relay server R1, and further transferred to the client terminal 11. As described above, the actual data of the shared resource is transmitted to the client terminal 11, and the client terminal 21 performs processing for opening the data.

  The above sequence numbers 45 to 45.2.1.1 are processes when the hash values match and the verification is successful, but the verification may fail. Hereinafter, with reference to FIG. 16, processing when verification fails will be described.

  The processing of sequence numbers 46 to 46.1.1.1 in FIG. 16 is exactly the same as the processing of sequence numbers 45 to 45.1.1.1 in FIG. If the hash value extracted from the electronic signature does not match the hash value calculated from the file entity in the Validation command executed by the relay server R2, the relay server R2 notifies the client terminal 21 of a file error (ErrorFile command). ) Is transmitted (sequence number 46.1.2). Receiving this, the client terminal 21 executes a NotifyError command. As a result, an error message indicating that verification of the shared resource has failed is displayed on the display of the client terminal 21. Thereafter, the client terminal 21 returns an OK response to the transmission source relay server R2.

  Next, the relay server R2 returns an ErrorFile response to the relay server R1. This response includes information on the owner client terminal 21 of the shared resource that has failed verification and information on the shared resource. The relay server R1 that has received the response transmits an ErrorFile response to the client terminal 11 that has attempted to open the target shared resource. Upon receiving this, the client terminal 11 executes a NotifyError command, and displays an error message indicating that verification of the shared resource has failed on the display of the client terminal 11. In the present embodiment, the process of automatically deleting the shared resource that has failed verification from the shared resource information 120 is not performed.

  Next, with reference to FIG. 17, the details of the processing of the relay server 1 when the client terminal 5 under its control adds a file as a shared resource will be described. Note that the flowchart in FIG. 17 substantially corresponds to the processing (sequence numbers 42 to 44) of the relay server R2 in FIG.

  As shown in FIG. 17, the relay server 1 waits until a shared resource update command is received from the client terminal 5 under its control (S301). It is checked whether the instruction is given (S302).

  If it is instructed to add the information of the electronic signature, the hash value data is received from the owner client terminal 5 (transmission source of the update command) under its control (S303). Then, the hash value is encrypted and electronic signature data is created and stored (S304), and information related to the electronic signature is added to the shared resource information 120 (S305). On the other hand, if there is no instruction to add electronic signature information in the determination of S302, the processing of S303 to S305 is skipped. Then, the update command of the shared resource information 120 is distributed to the client terminal 5 or other relay server 1 under its control (S306).

  Next, with reference to FIG. 18, the details of the processing of the relay server 1 when receiving an instruction to open or verify the shared resource (file) from the client terminal 5 under its control will be described. Note that the flowchart in FIG. 18 corresponds to the processing (sequence numbers 45 to 46.1.2) of the relay server R2 in FIGS. 15 and 16.

  As shown in FIG. 18, the relay server 1 waits until a command for opening a shared resource or a verification command is received from the client terminal 5 (S401). If the command is received, an electronic signature is attached to the target shared resource. It is checked whether the information is given based on the shared resource information 120 (S402). If the electronic signature information is not given, if the command is to open a file, the command is transferred to the owner client terminal 5 (via another relay server 1 if necessary) (S403). In the case of a file verification command, verification is impossible without an electronic signature, so a predetermined error message is notified and the process ends.

  When the electronic signature information is given, the relay server 1 transmits a hash value acquisition command to the owner client terminal 5 (S404), and receives the hash value data (S405). Next, the electronic signature data is read (S406), and the hash value is extracted by decrypting the data (S407). Then, it is checked whether or not the hash value obtained in S405 matches the hash value obtained in S407 (S408). As a result, if the hash values do not match, the client terminal 5 or the like concerned is notified that falsification has been detected (verification has failed) (S409).

  If the hash values match in the determination in S408, the relay server 1 checks whether the received command is a command for opening a file (S410). If it is a command for opening a file, the command is transferred to the owner client terminal 5 (via another relay server 1 if necessary) (S411). If it is not a command for opening a file (if it is a file verification command), the client terminal 5 as a transmission source is notified of the verification result (that is, the verification was successful) (S412).

  As described above, the relay server 1 according to this embodiment includes the verification unit 514 instead of the hash value information relay unit 513. Then, in response to the verification command from the resource sharing terminal 5, the verification unit 514 obtains a hash value necessary for verification of the target resource from the owner client terminal 5 of the target resource or the relay server 1 under its control. It is configured to obtain and verify a target resource based on the electronic signature and the hash value.

  Thereby, the client terminal 5 can make the relay server 1 verify whether the resource has been tampered with based on the electronic signature and the hash value of the resource.

  For example, as shown in sequence numbers 45 to 45.2.1.1.1 in FIG. 15, the verification unit 514 of the relay server R1 instructs the resource sharing terminal 5 to open a resource via the relay server R1. It is configured to automatically verify the target resource when it is performed.

  Thereby, whenever the client terminal 5 opens a resource, a target resource can be automatically verified. Therefore, since the resource can be properly verified without the client terminal 5 issuing a verification instruction one by one, the burden on the user can be reduced and high security can be realized.

  For example, as shown in sequence numbers 46 to 46.1.2 in FIG. 16, the control unit 503 of the relay server R2 is instructed to open a resource from the resource sharing terminal 5 via the relay server R1, and verified. When resource verification by the unit 514 fails, relaying the operation instruction to the client terminal 21 under its control is stopped.

  As a result, it is possible to prevent the client terminal from operating a resource that may have been tampered with and to achieve high security.

  For example, as shown in the sequence number 42 of FIG. 15, the electronic signature information management unit 512 of the relay server R2 receives a hash value as attribute creation information about the resource from the owner client terminal 21 that has instructed to add the resource. It is configured to obtain the electronic signature from the hash value and register it in the shared resource information 120.

  As a result, both the creation of the electronic signature and the verification based thereon are performed on the relay server 1 side, so that the load on the client terminal 5 can be reduced.

  Note that, in the two embodiments described above, the control unit 503 of the relay server 1 transmits the information to the client terminal 5 that shares the resource when a predetermined period has elapsed since the creation of the electronic signature information. It can also be configured to automatically notify the effect.

  In this case, when the reliability of the electronic signature decreases with the passage of time, the resource sharing terminal can be automatically notified to call attention. Therefore, higher security can be realized.

  Further, the control unit 503 of the relay server 1 automatically deletes the resource information 126 corresponding to the electronic signature from the shared resource information 120 when a predetermined period has elapsed since the electronic signature information was created. It can also be configured as follows.

  In this case, when the reliability of the electronic signature decreases with time, the information regarding the target resource can be deleted from the shared resource information 120 to stop sharing. Therefore, higher security can be realized.

  The preferred embodiments of the present invention have been described above, but the above configuration can be modified as follows, for example.

  In the above embodiment, communication is performed between the relay servers 1 via the external server 2 that is a SIP server. Instead, the configuration is changed so that communication is performed directly between the relay servers 1 without using the external server 2. can do.

  As the electronic signature information 129, instead of describing the file name of the electronic signature, for example, the electronic signature data itself can be encoded and described in the shared resource information 120.

  In the shared resource information 120, for example, information of a hash value or a time stamp (encrypted by adding time information to the hash value) can be described instead of the electronic signature information. These also make it possible to easily and powerfully detect falsification of shared resources.

  The operation instruction for the shared resource is not limited to an operation for opening a file, and may be configured to verify the shared resource before, for example, a file copy operation.

The network block diagram of the relay communication system which concerns on one Embodiment of this invention. The functional block diagram of an external server. The functional block diagram of a client terminal. The functional block diagram of the relay server which concerns on 1st Embodiment. The figure which shows the relationship between a client terminal, a relay server, and an external server. The figure which shows the content of relay group information. The figure which shows the content of shared resource information. The sequence diagram which shows the communication processing which creates a relay group. The sequence diagram which shows the communication processing which registers a client terminal as a resource sharable terminal in a relay group. FIG. 5 is a sequence diagram illustrating communication processing when an owner client terminal adds a shared resource and a user client terminal verifies and opens the shared resource in the first embodiment. The sequence diagram which shows a communication process when a user client terminal fails in verification of a shared resource. 5 is a flowchart illustrating processing when an owner client terminal adds a shared resource in the first embodiment. 5 is a flowchart illustrating processing when a client terminal verifies and opens a shared resource in the first embodiment. The functional block diagram of the relay server which concerns on 2nd Embodiment. FIG. 10 is a sequence diagram illustrating communication processing when an owner client terminal adds a shared resource and a user client terminal opens the shared resource in the second embodiment. The sequence diagram which shows the communication process when verification of a shared resource fails. The flowchart which shows the process of the relay server when an owner client terminal adds a shared resource in 2nd Embodiment. The flowchart which shows the process of a relay server when a client terminal opens a shared resource in 2nd Embodiment.

Explanation of symbols

1 (R1 to R4) Relay server 2 External server 5 (11, 12, 21, 22, 31, 32, 41, 42) Client terminal 120 Shared resource information 124 Family account information 126 Resource information 127 Message information 503 Control unit 505 Relay Group information database (relay group information registration department)
506 Shared resource information database (shared resource information registration unit)
511 Instruction relay unit 512 Electronic signature information management unit (attribute information management unit)
513 Hash value information relay unit (collation information relay unit)
514 Verification Department

Claims (11)

A relay group information registration unit that stores information on relay groups including other relay servers that can be connected to each other;
When sharing a resource among a plurality of client terminals in the relay group, information on the resource, attribute information of the resource, account information of the resource sharing terminal that is the client terminal that shares the resource, A shared resource information registration unit for storing shared resource information including:
A control unit;
With
The controller is
An instruction relay unit that relays the operation instruction of the resource registered in the shared resource information to at least one of its own client terminal or other relay server;
An attribute information management unit that registers attribute information about the resource in the shared resource information by adding information about the resource to the shared resource information;
In response to a relay instruction, collation information necessary for verifying the target resource is obtained from a client terminal that can operate the resource entity or a relay server under its control, and relays the collation information to a transmission source of the relay instruction. A collation information relay unit to
A relay server comprising: A relay group information registration unit that stores information on relay groups including other relay servers that can be connected to each other;
When sharing a resource among a plurality of client terminals in the relay group, information on the resource, attribute information of the resource, account information of the resource sharing terminal that is the client terminal that shares the resource, A shared resource information registration unit for storing shared resource information including:
A control unit;
With
The controller is
An instruction relay unit that relays the operation instruction of the resource registered in the shared resource information to at least one of its own client terminal or other relay server;
An attribute information management unit that registers attribute information about the resource in the shared resource information by adding information about the resource to the shared resource information;
In response to a verification instruction from the resource sharing terminal, the verification information necessary for verification of the target resource is acquired from a client terminal that can operate the resource entity or a relay server under its control, and the attribute information and the verification A verification unit that verifies the target resource based on the information;
A relay server comprising: The relay server according to claim 2,
The verification server automatically verifies a target resource when an instruction to operate the resource is given. The relay server according to claim 3,
When the verification by the verification unit fails, the control unit stops relaying the operation instruction for the resource. The relay server according to any one of claims 1 to 4, wherein
The relay server, wherein the attribute information is at least one of an electronic signature, a hash value, and time stamp information. A relay server according to any one of claims 1 to 5,
The attribute information management unit registers the attribute information created by the client terminal in the shared resource information when the client terminal gives an instruction to share a resource with which the entity can operate. . A relay server according to any one of claims 1 to 5,
The attribute information management unit obtains attribute creation information about the resource from the client terminal when the client terminal gives an instruction to share a resource that can operate the entity, and from the attribute creation information, A relay server that creates the attribute information and registers the attribute information in the shared resource information. The relay server according to any one of claims 1 to 7,
The control unit notifies the resource sharing terminal of the fact when a predetermined period has elapsed since the creation of the attribute information. The relay server according to any one of claims 1 to 8,
The control unit, wherein a predetermined period of time has passed since the creation of the attribute information, deletes information related to a resource corresponding to the attribute information from the shared resource information. Multiple relay servers,
Multiple client devices,
With
The relay server is
A relay group information registration unit that stores information on relay groups including other relay servers that can be connected to each other;
When sharing a resource among a plurality of client terminals in the relay group, information on the resource, attribute information of the resource, and information on an account of a resource sharing terminal that is the client terminal that shares the resource, , A shared resource information registration unit for storing shared resource information including
A control unit;
With
The controller is
An instruction relay unit that relays the operation instruction of the resource registered in the shared resource information to at least one of its own client terminal or other relay server;
An attribute information management unit that registers attribute information about the resource in the shared resource information by adding information about the resource to the shared resource information;
In response to a relay instruction, collation information necessary for verifying the target resource is obtained from a client terminal that can operate the resource entity or a relay server under its control, and relays the collation information to a transmission source of the relay instruction. A collation information relay unit to
A relay communication system comprising: Multiple relay servers,
Multiple client devices,
With
The relay server is
A relay group information registration unit that stores information on relay groups including other relay servers that can be connected to each other;
When sharing a resource among a plurality of client terminals in the relay group, information on the resource, attribute information of the resource, and information on an account of a resource sharing terminal that is the client terminal that shares the resource, , A shared resource information registration unit for storing shared resource information including
A control unit;
With
The controller is
An instruction relay unit that relays the operation instruction of the resource registered in the shared resource information to at least one of its own client terminal or other relay server;
An attribute information management unit that registers attribute information about the resource in the shared resource information by adding information about the resource to the shared resource information;
In response to a verification instruction from the resource sharing terminal, the verification information necessary for verification of the target resource is acquired from a client terminal that can operate the resource entity or a relay server under its control, and the attribute information and the verification A verification unit that verifies the target resource based on the information;
A relay communication system comprising:

Images