JP5150128B2 - Trace system, trace method, and computer program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To restrict registration of a communication route and the target of disclosure of information regarding an object to a player on the circulation route actually obtaining the object, even under environment where the circulation route of the object cannot be previously specified. <P>SOLUTION: The player PF-F produces certification code A by method capable of being produced only by the player PF-A by a terminal 2a and writes it onto a tag 1 attached to the product. The player PF-B receiving the product produces certification code B by a method capable of being produced only by the player PF-B by a terminal 2b based on the certification code A read from the tag 1 and transmits the produced certification code B and registration request of the circulation route information to a route server 3. The route server 3 inspects whether or not the certification code B is correct certification code, and only when it is inspected that it is the correct certification code, the route server 3 adds record of the received circulation route information to a route table. The terminal 2b rewrites the certification code A in the tag 1 to the certification code B, and the product is shipped. <P>COPYRIGHT: (C)2009,JPO&amp;INPIT

Description

The present invention relates to a trace system , a trace method, and a computer program.

  2. Description of the Related Art Conventionally, in a distribution system or the like using an ID storage device such as an RF-ID (Radio Frequency Identification) or a barcode, an access control method for “information of goods” includes “object ID” and “accessor's ID”. A method of setting access authority such as “reference permission” and “write prohibition” corresponding to a combination of “ID or attribute” has been adopted. In this method, it is a precondition that an ID and an attribute of an accessor who can access “thing information” are specified in advance.

  For example, Patent Document 1 describes a technique for determining the authenticity of a card using an ID added to the card and a server that stores information in association with the ID. In this technique, an ID (for example, a barcode) is printed on a card (for example, a postcard), and information is stored in the center server in association with the ID. In the distribution channel of the card, for example, an intermediate trader and a retail store connect to the center server from their respective terminals and register information in association with the ID, or purchase a card from the retail store. In addition, the password is stored in the center in association with the ID. Eventually, the person who received the card will access the center server from the retailer, such as when exchanging the card and goods at the retailer, and inquires whether the distribution channel is correct or the PIN is correct. If the result is positive, processing is possible.

Further, in Patent Document 2, an information registration apparatus detects a management IC tag held by an information registrant when registering information in a system that enables information registration by adding an IC tag to a product. Thus, there is described a technique for confirming the legitimacy of the registrant and registering information.
Further, in Patent Document 3, in a system that manages history information in production, processing, and distribution of goods and provides the user with data contents that the user wants to refer to the server, the server receives the user. It is determined whether or not the identifier is a registered user. If the identifier is registered, the content of the data that the user desires to provide (for example, whether or not the product can be provided for each identifier) is determined by the user identifier. A technique is described in which it is further determined whether the information is in a specified range that can be provided, and when the information can be provided, the information is searched and the information constructed as the provided information is transmitted to the user.

Japanese Patent Application Laid-Open No. 2004-228561 describes a technology that easily realizes safe information provision in the process of information provision using an RFID tag. In this technology, in a system composed of “RFID tag”-“RFID reader”-“ID resolution server”-“database (DB) server”, a random key or the like is added to the RFID tag in the RFID tag, It is encrypted with the public key of the ID resolution server and transmitted to the RFID reader. In the RFID reader, a time stamp is given to the user ID of the RFID reader and it is encrypted (encrypted user ID) with a common key with the DB server or the public key of the DB server, and the encrypted RFID received from the RFID tag Is sent to the ID resolution server. Then, among the information received by the ID resolution server, the encrypted RFID is decrypted to identify the DB server storing the information corresponding to the RFID, and the decrypted RFID and the encrypted data are encrypted with respect to the identified DB server. A user ID is transmitted. In the DB server, the received encrypted user ID is decrypted, and the authorization to refer to information stored in association with the RFID is performed based on the user ID. If there is no problem in the authentication result, the RFID is supported. Information to be transmitted to the RFID tag reader via the ID resolution server. Thereby, it is possible to conceal the information regarding the RFID and the database server that stores the information from the RFID reader (the user who uses the RFID).
JP 2006-192681 A JP 2005-250532 A JP 2004-171398 A JP 2006-53800 A

  In the conventional trace system, it can be assumed that an upstream player such as a manufacturer does not know what route the goods will be distributed from when the goods are shipped. On the other hand, there is a demand for restricting the distribution range of the distribution route and the disclosure range of information such as receipt / shipment data and transaction data to players on the distribution route who have actual goods. However, in the conventional technology, since an upstream player such as a manufacturer needs to know the ID and attribute of an accessor to whom reference authority is given at the time of shipment, it can be applied to an environment where a distribution channel cannot be specified in advance. There is a problem that you can not.

The present invention has been made in view of such circumstances, and even in an environment where it is not possible to specify the distribution route of goods in advance, the registration of distribution routes and the disclosure range of information related to goods are actually handled. It is an object of the present invention to provide a tracing system , a tracing method, and a computer program that can be limited to players on the distribution channel.

In order to solve the above-mentioned problems , the present invention provides information on a recording medium attached to a trace target, a player's terminal, and information on a route through which the trace target is distributed or moved, connected to the terminal via a network. A trace system having a path server to be managed, wherein a player terminal on the path reads a trace target identifier for identifying a trace target from the information recording medium, and a trace target identifier read by the read means Information on route registration request means for sending a route registration request to which the information is set to the route server, a trace target identifier read by the reading means, and a pre-registered player who is next permitted to register the route information Pre-registration request means for transmitting a pre-registration request in which is set to the route server; The route server stores route information including information in which the trace target identifier is associated with the player on the route, and a pre-registration table indicating information in which the trace target identifier is associated with the pre-registered player. And a route registration request received from the terminal of the player and the route information corresponding to the trace target identifier in the received route registration request is unregistered, or the transmission source player in the route registration request is When the player is newly registered in the pre-registration table corresponding to the trace target identifier in the route registration request, the transmission source player is on the route corresponding to the trace target identifier. A route registration means for registering the information to the route information in the storage means and a pre-registration request from the terminal of the player, When the credential player is the player most recently registered in the route information in the storage unit corresponding to the tracing target identifier in the pre-registration request, the tracing target identifier in the pre-registration request A tracing system comprising: pre-registration means for registering information associated with a pre-registration player in a pre-registration table in the storage means.

  Further, the present invention is the above-described trace system, wherein the terminal or the access server on the network can provide a type of trace target related information that can be provided to a player on the route and a player who is not on the route. Access authority storage means for storing access authority information indicating the type of trace object related information is provided, a trace object identifier for identifying a trace object that is an acquisition target of related information, and information of a player who has requested the trace object related information And whether or not the requesting player is registered as a player on the route in the route information in the storage means of the route server corresponding to the trace target identifier, and in the access authority storage means The type of information that can be provided to the information requesting player is identified from the access authority information, and Of traced related information stored in correspondence with the traced identifier to the layer of the terminal, providing traced related information of the specified type to a terminal of the requesting player, characterized in that.

The present invention also includes an information recording medium attached to a trace target, a player's terminal, and a route server that is connected to the terminal via a network and manages information on a route on which the trace target is distributed or moved. A tracing method executed by the tracing system, wherein the route server includes route information including information associating a trace target identifier for specifying a trace target with a player on the route, a trace target identifier, A storage unit for storing a pre-registration table indicating information associated with the registered player, wherein the reading unit of the player's terminal on the path reads a trace target identifier from the information recording medium; The route registration requesting means of the player's terminal above reads out the route read in the reading step. A route registration request step for transmitting to the route server a route registration request in which information on the source object identifier is set, and the route registration means of the route server receives the route registration request from the terminal of the player and receives the received route registration. The route information corresponding to the trace target identifier in the request is not registered, or the transmission source player in the route registration request is newly registered in the pre-registration table corresponding to the trace target identifier in the route registration request. A route registration step of registering in the route information in the storage means information indicating that the transmission source player is on the route corresponding to the trace target identifier; The player's terminal pre-registration requesting means permits registration of the trace target identifier read in the reading step and then the route information. A pre-registration request step for transmitting to the route server a pre-registration request in which information with a pre-registration player as a player is set; When the player who has transmitted the pre-registration request is the player most recently registered in the route information in the storage unit corresponding to the trace target identifier in the pre-registration request, A pre-registration step of registering information associating a trace target identifier with a pre-registered player in a pre-registration table in the storage means.
The present invention also includes an information recording medium attached to a trace target, a player's terminal, and a route server that is connected to the terminal via a network and manages information on a route on which the trace target is distributed or moved. A computer used as the path server in the trace system includes: path information including information associating a trace target identifier for specifying a trace target with a player on the path; a trace target identifier; and a pre-registered player. Storage means for storing a pre-registration table indicating associated information , receiving a route registration request from the terminal of the player, whether the route information corresponding to the trace target identifier in the received route registration request is unregistered, or the source of the player in the path registration request, corresponds to the traced identifier of the path in the registration request Most recently in the case of a player who has registered in the pre-registration table in correspondence with the traced identifier, registers information indicating that the source of the player is on the route to the route information in the storage means Te A route registration unit that receives a pre-registration request from the terminal of the player, and the player who has transmitted the pre-registration request most recently corresponds to the trace target identifier in the pre-registration request. When the player is registered in the route information, it functions as a pre-registration unit that registers information in which the trace target identifier in the pre-registration request is associated with the pre-registration player in the pre-registration table in the storage unit. It is a computer program characterized by making it carry out.

According to the present invention, even when the distribution target / traffic route of a person to be traced or a person's distribution / movement route is not known in advance, only the player on the distribution / movement route registers the distribution route information or discloses information about the trace target. The access control that can be performed can be realized. Also, since access control is performed based on whether or not the route was actually traced, it is possible to prevent a third party who does not physically hold the trace target from acquiring information on the trace target illegally. Can do. As a result, it is possible to safely distribute information that is desired to be kept secret to non-distributed parties only to the parties concerned .

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[1. Overview]
In the present embodiment, on the trace system, a route server that records the distribution / movement route of a trace target such as a thing or a person is installed, and information on the distribution / movement route recorded in the route server is used. Controls access to information related to the trace target. As a result, even in an environment where the distribution / movement route is unknown, the distribution range of the distribution / movement route and the disclosure range of the information related to the trace target can be limited to players on the actual distribution route. Here, the trace target is “product” that is a product to be distributed, and the disclosure range of “product information” as information related to the trace target is limited by whether or not the player is on the actual distribution channel Will be described.

Access control in the trace system according to the present embodiment is realized by the following two procedures.
(Procedure 1) A player who has a thing registers distribution route information in a route server on the trace system. At this time, access control is performed so that only the person (player) who has the item can register the distribution route information.
(Procedure 2) Each player collects information related to an object (referred to as “information of an object”) from the players on the distribution route recorded in the route server. At this time, by performing access control based on the distribution route information, information limited to only the players on the distribution route is distributed.

  The above (Procedure 1) and (Procedure 2) will be described below.

[2. (Procedure 1) Access control during distribution route information registration]
A player who has a thing registers his player ID in the route server from the terminal of the player. As each player registers in the distribution process of goods, a list of player IDs for identifying the player who has picked up the goods is stored in the route server, and this is information representing the distribution route of goods. In the present embodiment, access control is performed so that only a player who actually has a thing can register with the route server, thereby ensuring the reliability of the distribution route information on the route server.

There are the following two patterns in the access control method to the route server when registering the distribution route information, depending on the preconditions.
(Pattern 1) When all players use the same route server.
(Pattern 2) When there is a player who does not use the same route server.

  An embodiment in the case of (Pattern 1) and (Pattern 2) will be described below.

[2.1 (Pattern 1) When all players use the same route server]
Here, access control at the time of distribution route information registration in the case where all players use the same route server will be described. In this embodiment, when an object moves between players, the movement source player pre-registers the movement destination player in the route server. The route server only allows registration requests from pre-registered players, thereby preventing unauthorized distribution route information from being registered by a third party who has not been pre-registered.

  However, access control is not performed in an initial state where no distribution route information is registered or pre-registered. In this case, even if a third party illegally registers the distribution route information, the player (for example, the manufacturer) who first registers the distribution route in the route server can detect and respond to the unauthorized registration at the time of registration. Therefore, it is possible to prevent the delivery of fake information due to unauthorized distribution route information.

  FIG. 1 is a diagram showing a configuration of a trace system according to the present embodiment and a player pre-registration procedure. This figure shows an example in which goods are distributed in the order of player PF-A, player PF-B, and player PF-C. Player PF-A is “Manufacturer A” and player PF-B is “Wholesale B”. The player PF-C is “Retail C”. A tag 1 is attached to or built in a product to be distributed, and the route server 3 is connected to the terminal 2 of each player via a network such as the Internet or a dedicated line. The terminal 2 of the player PF-A (manufacturer A) is the terminal 2a, the terminal 2 of the player PF-B (wholesale B) is the terminal 2b, and the terminal 2 of the player PF-C (retail C) is the terminal 2c.

  For example, an RFID (Radio Frequency Identification) tag can be used as the tag 1 as an information recording medium attached to the trace target. The RFID tag mainly uses a radio frequency for communication, and includes a memory for recording data, a data processing circuit, and an antenna for carrying data at the radio frequency. The power source of the RFID tag depends on a battery incorporated in the RFID tag or a necessary power is extracted from an electromagnetic wave used as a data carrier wave from the outside. The tag 1 stores a tag ID unique to each tag in the memory. This tag ID is used as a trace target identifier for specifying the trace target.

  The terminal 2 is a computer terminal such as a personal computer, a PDA (Personal Digital Assistants: information portable terminal), or a cellular phone, and includes a reader / writer for reading and writing information in the tag 1.

  The route server 3 includes a storage device that stores a route table and a pre-registration table. The route server 3 authenticates the player and performs access control to permit registration of the authenticated player in the route table and the pre-registration table. The route table is composed of a record of distribution route information indicating a tag ID, a player ID, terminal identification of the terminal 2 that performed the registration, reference authority (refer to step 2 described later for details), registration date and time, and the like. For the terminal identification of the terminal 2, the address of the terminal 2 can be used. The pre-registration table indicates information of players that each player is allowed to register next in the route table, and identifies a tag ID, a pre-registered player ID that is a player ID for specifying a pre-registered player, and a player that performs pre-registration. It is comprised by the record containing information, such as registrant player ID which is player ID to perform, and registration date.

  Here, the tag ID “01” is stored in the tag 1 attached to or incorporated in the product, that is, the product. Further, the IP address of the terminal 2a is “192.168.0.1”, the IP address of the terminal 2b is “192.168.0.2”, and the IP address of the terminal 2c is “192.168.0.3”. To do. Further, the player ID of manufacturer A is “PF-A”, the player ID of wholesale B is “PF-B”, and the player of retail C is “PF-C”.

  In the above configuration, manufacturer A pre-registers wholesale B in route server 3 using terminal 2a when shipping the product (tag ID “01”) to wholesale B, and wholesale B corresponds to the product (tag ID “01”). Enable distribution channel information to be registered. The wholesaler B pre-registers the retail C to the route server 3 by the terminal 2b when shipping the product (tag ID “01”) to the retail C, and the retail C distributes the product (tag ID “01”). Enable to register route information.

  First, the manufacturer A has a tag ID “01” read from the tag 1 attached to the product by the terminal 2a, the player ID “PF-A” of the manufacturer A, and the possession of the manufacturer A for the distribution route information registration request. The distribution route information including the address “192.168.0.1” of the terminal 2 a to be accessed, the reference authority, and the registration date and time “2006/7/13 9:00” in the route table is transmitted to the route server 3. . The date and time of registration in the route table may be given by the route server 3. Since the record with the tag ID “01” is not registered in the route table, the route server 3 determines that the record player is the first player in the distribution route, and does not perform access control based on the pre-registration table, and receives the received distribution route information. Record the records generated from the above in the route table.

  Furthermore, the manufacturer A pre-registers the wholesale B in the route server 3 through the terminal 2a. Since this pre-registration procedure is the same as the case where wholesale B, which will be described later, pre-registers retail C, detailed description of the procedure is omitted here. By this registration, the route server 3 receives the tag ID “01”, the registrant player ID “PF-A”, the pre-registered player ID “PF-B” received from the terminal 2a, and the registration date and time “2006/7/13 10: A record including information “00” is additionally registered in the pre-registration table.

  Thereafter, the wholesaler B who has received the product shipped from the manufacturer A registers the distribution route information in the route server 3 by the terminal 2b. The distribution route information registration procedure is the same as that in the case where retail C, which will be described later, registers the distribution route information. Therefore, detailed description of the procedure is omitted here. By this registration, the route server 3 includes the tag ID “01”, the wholesaler B player ID “PF-B”, and the address “192.168.0.2” of the terminal 2b included in the distribution route information received from the terminal 2b. ”, A reference authority, and a record including information on registration date and time“ 2006/7/13 10:30 ”in the route table is additionally registered in the route table.

Next, a processing flow when wholesale B pre-registers retail C will be described with reference to FIG.
In the figure, wholesaler B who has registered distribution route information in the route table transmits a pre-registration request for retail C to route server 3 by means of terminal 2b (step S111). In the pre-registration request, the tag ID “01” read from the tag 1 given to the product, the registrant player ID “PF-B” in which the player ID of the wholesale B which is the pre-registration request source is set, and pre-registration The pre-registered player ID “PF-C” in which the player ID of the target retail C is set, and information on the registration date and time “2006/7/13 12:00” in the pre-registration table are included. The date and time of registration in the pre-registration table may be given by the route server 3.

  The route server 3 confirms whether or not the received registrant player ID “PF-B” is registered as the player ID in the latest record in the route table specified by the received tag ID “01” (step) S112). This is to confirm the authority because only the player who has the product (distributed item) at the present time has the authority for pre-registration.

  If it is determined in step S112 that the received registrant player ID is registered as the player ID in the latest record in the route table specified by the received ID, the route server 3 receives the received pre-registration request, that is, , A record including a tag ID “01”, a registrant player ID “PF-B”, a pre-registration player ID “PF-C”, and a registration date “2006/7/13 12:00” is additionally registered in the pre-registration table. (Step S113).

  Note that the pre-registration table can be changed / deleted only by a registrant who currently has an item. That is, only when it is determined that the player ID of the registrant received from the terminal 2 is registered as the player ID in the latest record in the route table specified by the tag ID received as the record change / deletion target. The record corresponding to the tag ID in the pre-registration table registered by the player can be changed / deleted.

FIG. 2 is a diagram illustrating an operation procedure when the retailer C registers distribution route information.
When the retailer C receives the goods shipped from the wholesaler B, the terminal 2c transmits a distribution route information registration request (route registration request) to the route server 3 (step S121). The distribution route information registration request includes the tag ID “01” read from the tag 1 attached to the product, the player ID “PF-C” of the retail C, and the address “192.168 .. 0.3 ”, reference authority, and registration date and time“ 2006/7/13 15:30 ”in the route table are set. The date and time of registration in the route table may be given by the route server 3.

  The route server 3 confirms whether or not the received player ID “PF-C” is registered as a pre-registered player ID in the latest record in the pre-registration table specified by the received tag ID “01” ( Step S122). The route server 3 rejects the received registration request if it is a distribution route information registration request from a player other than the last pre-registered player.

  If it is determined in step S122 that the received player ID is registered as the pre-registered player ID in the latest record in the pre-registration table specified by the received tag ID, the tag ID indicated by the received distribution route information A record including “01”, player ID “PF-C”, address “192.168.0.3”, reference authority, and registration date and time information “2006/7/13 15:30” in the route table is recorded. It is additionally registered in the route table (step S123). After registering the record in the route table, the route server 3 reads the number of records specified in the route table using the tag ID “01” received in step S121 as a key (step S124). Thereby, in order to prevent fraud, it is determined whether or not the player who requested the registration of the distribution channel information received in step S121 is the first registrant.

  Note that the route table can be changed / deleted only by a registrant who currently has an item. That is, only when the registrant's player ID received from the terminal 2 is registered as the player ID in the latest record in the route table identified by the tag ID received as the change / delete target of the route table. It is possible to change the contents of the latest record.

[2.2 (Pattern 2) When there is a player who does not use the same route server]
Here, access control at the time of registration of distribution route information when there is a player who does not use the same route server will be described. If there is a player who uses a different route server or a player that is not systemized in the middle of the distribution route, there is a possibility that the shipping destination player cannot be pre-registered in the route server. In this case, registration access control is performed using an authentication code written in the tag 1 in each player.

  In other words, a player who has an object first generates an authentication code that can be generated only by him / her on the basis of information read from a tag attached to the object. When the player passes the distribution route information and the authentication code to the route server, the route server confirms that the authentication code is generated based on the information read from the tag, and then registers the distribution route information therein.

  FIG. 3 is a diagram showing a configuration of the trace system according to the present embodiment and a procedure for registering distribution route information. This figure shows an example in which an item is distributed in the order of player PF-A, player PF-B, and player PF-C, but between player PF-A and player PF-B, player PF-B, player During PF-C, it may be connected to a route server of a trace system different from the route server 3 or pass through a player that is not systematized.

An outline of the authentication code generation / verification process when the player PF-B ships the product received from the player PF-A to the player PF-C will be described with reference to FIG.
First, the player PF-A generates an authentication code A by a method that can be generated only by the player PF-A using the terminal 2a owned by the player PF-A, and writes it in the tag 1 (step S211). The player PF-A ships the product (distributed item) with the tag 1 attached to the player PF-B (step S212).

  The player PF-B receiving the product reads the authentication code A in the tag 1 by the terminal 2b owned by the player PF-B (step S213). Based on the authentication code A read in step S213, the terminal 2b of the player PF-B generates the authentication code B by a method that can be generated only by the player PF-B (step S214). The terminal 2b of the player PF-B transmits a distribution route information registration request (route registration request) to the route server 3 together with the generated authentication code B (step S215).

The path server 3 verifies whether or not the authentication code B received from the terminal 2b of the player PF-B is a correct authentication code (step S216). Only when it is verified that the authentication code is correct in step S216, the route server 3 registers the player PF-B as a distribution route by adding the received distribution route information record to the route table (step S216). S217).
Further, the terminal 2b of the player PF-B rewrites the authentication code A in the tag 1 with the authentication code B generated in step S214 (step S218). The player PF-B ships the product to which the tag 1 recording the authentication code B is attached to the player PF-C (step S219).

  Hereinafter, two methods for generating and verifying an authentication code used in this embodiment will be described. One is an example using a public key certificate, and the other is an example using a hash.

[2.2.1 Method using public key certificate]
Each player keeps the secret key in the public key cryptosystem secret so that it is not known to a third party, and an authentication code is generated by the terminal 2 using the secret key. Further, it is assumed that the public key certificate of each player is registered in advance in the route server 3.

  4 and 5, the player PF-C registers the distribution route information on the terminal 2c owned by the player PF-C with respect to the product distributed through the player PF-A → player PF-B → player PF-C. A processing procedure when the server 3 performs verification will be described.

FIG. 4 is a diagram showing an authentication code generation processing procedure in the terminal 2 of each player.
The most upstream player PF-A reads the tag ID from the tag 1 by the terminal 2a. The terminal 2a generates a random number for generating an authentication code, and uses this as an initial random number. The terminal 2a generates an authentication code A by encrypting the code obtained by combining the read tag ID and the generated initial random number with the secret key of the player PF-A (step S221), and writes it to the tag 1. This initial random number is registered together with the tag ID in the tag 1 in the route server 3 by a safe method. The path server 3 additionally registers the tag ID requested to be registered by the terminal 2a and the initial random number in the initial random number registration table held by itself.

  The player PF-B receiving the product from the player PF-A reads the authentication code A from the tag 1 by the terminal 2b, and encrypts the read authentication code A with the secret key of the player PF-B to generate the authentication code B. (Step S222). The terminal 2b transmits the tag ID read from the tag 1 and the generated authentication code B when registering the distribution route information in the route server 3. The terminal 2b rewrites the authentication code A in the tag 1 with the generated authentication code B.

  Similarly, the player PF-C receiving the product from the player PF-B reads the authentication code B from the tag 1 by the terminal 2c, encrypts the read authentication code B with the secret key of the player PF-C, and authenticates the code. C is generated (step S223). The terminal 2 c transmits the tag ID read from the tag 1 and the generated authentication code C when registering the distribution route information in the route server 3. Also, the terminal 2c rewrites the authentication code B in the tag 1 with the generated authentication code C.

FIG. 5 is a diagram showing an authentication code verification process procedure in the route server 3.
Here, a case where the authentication code C is verified will be described. The path server 3 holds a public key certificate table that holds each player and a public key certificate.
When the route server 3 receives the reception ID that is the tag ID read by the terminal 2c from the tag 1 and the authentication code C from the terminal 2c, first, the public key of the player PF-C that is the distribution route information registration request source is received. The received authentication code C is decrypted using the certificate (step S231). As a result of the decryption, an authentication code B ′ is obtained. Next, the route server 3 refers to the route registered in the route table corresponding to the received ID, identifies the player on the route, and traces the authentication codes obtained as a result of the decryption in the reverse order of the route. The public key certificate of each player is sequentially used to perform decryption using the public key.

  In the figure, since the distribution of the product from the player PF-A to the player PF-B corresponding to the reception ID “01” is registered in the route table, the route server 3 stores the authentication code B 'Is decrypted with the public key certificate of the player PF-B to obtain an authentication code A' (step S232), and the obtained authentication code A 'is decrypted with the public key certificate of the player PF-A to obtain an ID. 'And an initial random number' are obtained (step S233). The route server 3 compares the received ID received from the terminal 2c of the player PF-C with the ID ′ obtained by decryption and registers the initial ID registered in the initial random number registration table in association with the received ID. The random number is compared with the initial random number 'obtained by decryption, and the authentication code C is regarded as the correct authentication code only when they match (step S234).

FIG. 6 shows the configuration of the trace system when this method is used, and the operation procedure when a product manufactured by manufacturer A is distributed to wholesale B.
This figure shows an example in which goods are distributed in the order of “Manufacturer A” as the player PF-A, “Wholesale B” as the player PF-B, and “Retail C” as the player PF-C. The trace system shown in the figure is different from the trace system shown in FIGS. 1 and 2 in that the route server 3 does not hold the pre-registration table in the storage device included in the route server 3, and the route table, the public key The certificate table and the initial random number registration table are stored, the authentication code received from the terminal 2 is verified, and the verified player is allowed to register the distribution route information in the route table. The route table has the same configuration as the route table shown in FIGS. The public key certificate table holds a public key certificate associated with the player ID. The initial random number registration table indicates information in which a tag ID is associated with an initial random number.

  First, the manufacturer A reads the tag ID from the tag 1 attached to the product by the reader / writer (R / W) included in the terminal 2a (step S241). When the terminal 2a generates an initial random number (step S242), it transmits the tag ID read in step S241 and the initial random number generated in step S242 to the route server 3 (step S243). The route server 3 associates the tag ID received from the terminal 2a with the initial random number and additionally registers it in the initial random number registration table (step S244).

  Subsequently, the terminal 2a sets information such as the tag ID “01” read from the tag 1, the player ID “PF-A” of the manufacturer A, the address of the terminal 2a, the reference authority, and the registration date and time in the route table. The distribution route information thus transmitted is transmitted to the route server 3 as a route registration request (step S245). Since the received record with the tag ID “01” is not registered in the route table, the route server 3 determines that it is the first player of the distribution route, and additionally registers the received distribution route information in the route table ( Step S246). The terminal 2a generates an authentication code A by encrypting the code connecting the tag ID read in step S241 and the initial random number generated in step S242 with the secret key of the manufacturer A (step S247), and writes it to the tag 1 (Step S248).

  Thereafter, the product is distributed from manufacturer A to wholesale B. After the product is received, the wholesaler B reads the tag ID from the tag 1 attached to the product by the reader / writer provided in the terminal 2b (step S249) and also reads the authentication code A (step S250). When the terminal 2b encrypts the read authentication code A with the secret key of the wholesale B and generates the authentication code B (step S251), the route server 3 and the generated authentication code B together with the generated authentication code B as a route registration request. (Step S252). In this distribution route information, information such as the tag ID “01” read from the tag 1, the player ID “PF-B” of the manufacturer B, the address of the terminal 2b, the reference authority, and the date and time of registration in the route table are set. Is done.

  The path server 3 verifies the received authentication code B by the procedure shown in FIG. 5 (step S253). Specifically, the path server 3 reads out the public key certificate corresponding to the player ID “PF-B” indicated in the distribution path information from the public key certificate table, and uses the read public key certificate for the authentication code. B is decrypted to obtain an authentication code A ′. Subsequently, the route server 3 refers to the record registered in the route table corresponding to the received ID, that is, the tag ID “01” indicated in the distribution route information, and routes the player ID “PF-A”. Read as. The path server 3 reads out the public key certificate corresponding to the player ID “PF-A” from the public key certificate table, decrypts the authentication code A ′ using the read public key certificate, and obtains ID ′ and initial random number ′. Get. The route server 3 compares the received ID received from the terminal 2b with the ID ′ obtained by decryption, and the initial random number registered in association with the received ID “01” in the initial random number registration table. The decrypted initial random number 'is compared, and if they match, it is determined that the verification is successful, and if they do not match, it is determined that the verification fails.

  The route server 3 registers the distribution route information received from the terminal 2b in the route table only when it is verified in step S253 that the authentication code B received from the terminal 2b is correct (step S254). The terminal 2b overwrites the authentication code A in the tag 1 with the authentication code B generated in step S251 by means of its own reader / writer (R / W) (step S255).

  According to the above procedure, a player who has not actually read the authentication code A by the reader / writer, for example, the retailer C, cannot generate a correct authentication code and therefore cannot illegally register distribution channel information.

[2.2.2 Method using hash]
Next, an example in which a hash is used for generating and verifying an authentication code will be described.
7 and 8, the distribution route information is registered on the terminal 2c owned by the player PF-C with respect to the product distributed from the player PF-A → the player PF-B → the player PF-C. A processing procedure when the server 3 performs verification will be described.

FIG. 7 is a diagram showing an authentication code generation processing procedure in the terminal 2 of each player.
The most upstream player PF-A reads the tag ID from the tag 1 by the terminal 2a. The terminal 2a generates an initial random number, generates an authentication code A by taking a hash of a code that combines the read tag ID and the generated initial random number (step S261), and writes it to the tag 1. Taking a hash means obtaining a hash value using a hash function or the like. This initial random number is registered in the route server 3 in a secure manner. The path server 3 additionally registers the tag ID requested to be registered by the terminal 2a and the initial random number in the initial random number registration table held by itself.

  The player PF-B that received the product from the player PF-A reads the authentication code A from the tag 1 by the terminal 2b, and generates the authentication code B by taking the hash of the read authentication code A (step S262). The terminal 2b transmits the tag ID read from the tag 1 and the generated authentication code B when registering the distribution route information in the route server 3. The terminal 2b rewrites the authentication code A in the tag 1 with the generated authentication code B.

  Similarly, the player PF-C receiving the product from the player PF-B reads the authentication code B from the tag 1 by the terminal 2c, and generates the authentication code C by taking the hash of the read authentication code B (step). S263). The terminal 2 c transmits the tag ID read from the tag 1 and the generated authentication code C when registering the distribution route information in the route server 3. Also, the terminal 2c rewrites the authentication code B in the tag 1 with the generated authentication code C.

FIG. 8 is a diagram showing a verification code verification process procedure in the route server 3.
Here, a case where the authentication code C is verified will be described. When receiving the reception ID and the authentication code C, which are tag IDs read by the terminal 2c from the tag 1, from the terminal 2c, the path server 3 reads the initial random number associated with the reception ID from the initial random number registration table. The route server 3 takes a hash for the code connecting the received ID and the read initial random number. As a result, an authentication code A ′ is obtained. Next, the route server 3 takes the hash as many times as the number of players registered in the route table corresponding to the received ID (step S271). In FIG. 8, two players with the player IDs “PF-A” and “PF-B” are registered in the route table corresponding to the reception ID “01”. Take the hash once. An authentication code B ′ is obtained as a result of the first hash (step S272), and an authentication code C ′ is obtained as a result of the second hash (step S273). The route server 3 compares the authentication code C received from the terminal 2c of the player PF-C with the authentication code C ′ obtained in the route server 3, and the authentication code C is the correct authentication code only when they match. Consider it.

  This method can be realized by the same system configuration as the method using the public key certificate shown in FIG. However, only the route table and the initial random number registration table are stored in the storage device included in the route server 3. Then, the route server 3 and each terminal 2 calculate a hash value using the same hash function.

  The manufacturer A reads the tag ID from the tag 1 attached to the product by the tag reader / writer of the terminal 2a. When the terminal 2a generates an initial random number, the terminal 2a transmits the read tag ID and the generated initial random number to the path server 3, and the path server 3 associates the tag ID received from the terminal 2a with the initial random number and initializes the initial random number. Add to the random number registration table. Subsequently, the terminal 2a transmits the distribution route information to the route server 3, and the route server 3 additionally registers the received distribution route information in the route table. The terminal 2 a generates an authentication code A by taking a hash of a code obtained by connecting the read tag ID and the generated initial random number, and writes it to the tag 1.

  Thereafter, the product is distributed from manufacturer A to wholesale B. After the product is received, the wholesale B reads the tag ID and the authentication code A from the tag 1 attached to the product by the reader / writer included in the terminal 2b. When the terminal 2b generates the authentication code B by taking the hash of the read authentication code A, the terminal 2b transmits the distribution route information to the route server 3 together with the generated authentication code B.

The route server 3 verifies the received authentication code B according to the procedure shown in FIG. Specifically, when the route server 3 receives the distribution route information and the authentication code B from the terminal 2b, the initial value associated with the received ID, that is, the tag ID indicated in the distribution route information, from the initial random number registration table. Read a random number. The path server 3 obtains an authentication code A ′ by taking a hash of the code connecting the received ID and the read initial random number. Next, the route server 3 takes the hash as many times as the number of players registered in the route table corresponding to the received ID. Since only the player ID “PF-A” is registered in the route table, the authentication code A ′ is hashed once to obtain the authentication code B ′. The path server 3 compares the authentication code B received from the terminal 2b of the player PF-B with the authentication code B ′ calculated in the path server 3, and if they match, the verification succeeds, and if they do not match, the verification fails. Judge.
The route server 3 registers the distribution route information received from the terminal 2b in the route table only when it is verified that the authentication code B is correct. The terminal 2b overwrites the authentication code A in the tag 1 with the generated authentication code B by the reader / writer provided in the terminal 2b.

  According to the above procedure, a player who has not actually read the authentication code A by the reader / writer, for example, the retailer C, cannot generate a correct authentication code and therefore cannot illegally register distribution channel information.

[3. (Procedure 2) Access control when distributing information to players]
Next, access control when collecting information from players on the distribution route recorded in the route server will be described.
When an information reference request is generated from a certain player, information is distributed only to the players on the distribution route by performing access control based on the distribution route information stored in the route server. As a control method, there are the following two patterns.

(Pattern 1) The disclosure range of the distribution route information itself is limited depending on whether the player is on the distribution route registered in the route server. Since each player collects “thing information” based on the distribution route information acquired from the route server, it is possible to filter player IDs that cannot be accessed at this time (“thing information” cannot be collected).
(Pattern 2) On the side of each player who provides “object information”, the disclosure range of the information is limited by whether or not the player is registered in the route server. As a result, it is possible to block access from players other than the distribution channel on the provider side of “product information”, or to disclose only specific “product information” only to players on the distribution channel. .

As a control method for realizing the above two patterns, there are the following three configurations, and their respective characteristics are shown.
(1) Complete server type: <Information collection> Collected by servers on network, <Access control> Servers on network controlled (2) Access control distributed type: <Information collection> collected by servers on network, <Access control > Control by each player's terminal (3) Completely distributed: <Information collection> Collect by each player's terminal, <Access control> Control by each player's terminal

  Embodiments of (1) a complete server type, (2) an access control distributed type, and (3) a fully distributed type will be described below.

[3.1 Complete server type]
The complete server type is a case where a server on the network performs both collection of “things information” and access control. This server is called an “access server”.
When the access server receives a request for collecting information about “thing information” from the access source, the access server accesses the route server and holds a list of players holding “thing information” (that is, players of distribution route information). To get. If no “object information” is provided to a player who is not on the distribution channel, a player who cannot be referred to as an access source at this time, that is, an access source (information requesting source) player not included in the list. Can be eliminated. Next, the access server collects “thing information” from the player's terminal based on the acquired list, and filters information that cannot be referred to by the access source according to the registration status in the route server. Finally, the access server returns the filtered “thing information” to the access source.

  FIG. 9 is a diagram showing a configuration of a complete server type trace system and an access control procedure at the time of information distribution. In the figure, the complete server type trace system has a configuration in which an access server 4 connected to a network is added to the trace system shown in FIG. 1 or FIG. Goods are distributed in the order of “Manufacturer A”, “Wholesale B”, and “Retail C”. In the storage device of the route server 3, the route table registered by (Pattern 1) or (Pattern 2) in “2. Access control at the time of registration of the distribution route information (procedure 1)” is stored as distribution route information. ing.

  The distribution route information includes a tag ID “01”, a player ID “PF-A”, an address “192.168.0.1”, a reference authority “only open to accessors on the distribution route”, a registration date “ 2006/7/13 9:00 ”record, tag ID“ 01 ”, player ID“ PF-B ”, address“ 192.168.0.2 ”, reference authority“ open to all accessors ”, registration Record consisting of date and time “2007/7/13 10:00”, tag ID “01”, player ID “PF-C”, address “192.168.0.3”, reference authority “only access person on distribution channel” And the record of registration date “2007/7/13 14:00” is registered.

  The access server 4 includes a storage device that stores access authority information. The access server 4 receives a request for collecting information about “things” from the terminal 2, acquires a list of players holding “thing information” from the route server 3, and performs access control. Further, the access server 4 collects “thing information” from the terminal 2 of the player indicated in the acquired player list, filters the information with reference to the access authority information, and filters the information to the access source terminal 2. Will be returned.

The access authority information indicates information that associates an attribute name, an accessor role, an access ID that is a player ID of an information requesting player, ownership history, target information, and access control information.
In the figure, the access authority information includes an attribute name “attribute value”, an accessor role “retail”, an access ID “*” (indicating an arbitrary player ID), an ownership history “present”, and target information “<product information. ><Priceinformation> ”, access control information“ reference permission ”record, attribute name“ attribute value ”, accessor role“ retail ”, access ID“ * ”(arbitrary player ID), ownership history“ none ”, A record including target information “<product information>” and access control information “reference permission” is held.
Note that the reference authority for the “thing information” registered in the access authority information is set in advance by the information owner (provider) based on their own policy.

Next, the operation of the trace system will be described.
In the figure, a player who wants to acquire “information on an object” uses a terminal 2 held by the player to specify an object for which information is to be acquired, that is, in a tag 1 that is assigned to the object at least during distribution. The stored tag ID and own player ID are transmitted to the access server 4 (step S311). Here, it is assumed that retailer C and retailer X are access source players who want to acquire information on goods. The terminal 2c of the retail C has an access source (information request source) player ID “PF-C” and ID “1”, and the terminal 2x of the retail X has an access source player ID “PF-X” and ID “1”. To the access server 4.

  The access server 4 accesses the route server 3, searches the distribution route information using the tag ID for specifying the information acquisition target item and the access source player ID as keys, and holds “item information”. A list of players (that is, players on the distribution channel) is acquired (step S312). The player list obtained here includes only players that can be referred to with the authority of the access source. The authority to refer to the distribution route information held by the route server 3 is set based on its own policy when each player registers the route ([2. (Procedure 1) Distribution route information registration time (See Access Control].)

  For example, when the distribution route information is searched using the ID “1” received from the terminal 2c and the access source player ID “PF-C” as keys, a record including the tag ID “01” and the player ID “PF-C” is obtained. Since it is registered, it can be seen that retail C (player PF-C) is a player on the distribution channel. Therefore, among records corresponding to the ID “1”, that is, records set with the tag ID “01”, the reference authority is “open to only the access person on the distribution channel” or “to all the access persons. The player IDs “PF-A”, “PF-B”, “PF-C” and the addresses corresponding to these player IDs in the record for which “public” is set are read out as a player list.

  On the other hand, when the distribution route information is searched using the ID “1” received from the terminal 2 x and the access source player ID “PF-X” as keys, the corresponding record is not registered, so the retail X (player PF-X ) Is not a player on the distribution channel. Therefore, among the records in which the tag ID “01” is set, the player ID “PF-B” and the address in the record in which “open to all accessors” is set as the reference authority are read as a player list. It is.

  The access server 4 transmits an “object information” acquisition request to the terminal 2 of the player included in the player list acquired in step S312 (step S313). This acquisition request includes an ID that identifies the item for which information is to be acquired. If the access source player is included in the player list, the acquisition request may not be transmitted to the terminal 2 of the access source player. Each terminal 2 that has received the information acquisition request returns “thing information” held by itself to the access server 4 corresponding to the ID. “Product information” may include, for example, product information, price information, receipt / shipment data, transaction data, and the like. In response to the information collection request from retail C, the terminal 2b corresponding to the information collection request from retail X is sent to the terminals 2a and 2b of the player specified by the player IDs “PF-A” and “PF-B”. A request for acquisition of “object information” is sent to.

  The filtering device included in the access server 4 includes information that cannot be referred to by the access source player, that is, the retailer C and the retailer X, among the “object information” returned from the terminal 2 corresponding to the specified tag ID “01”. Filtering is performed (step S314).

  In step S312, retail C is determined to be an accessor on the distribution channel, and the accessor role is “retail”. Therefore, from the access authority information, the target information “<product information> <price information>”, corresponding to the accessor role “retail”, access ID “*” (arbitrary player ID), and ownership history “present”, and The access control information “reference permission” is read. Therefore, the access server 4 determines that only the product information and price information among the information acquired from the terminals 2a and 2b is information that can be provided to the retailer C.

On the other hand, in step S312, it is determined that retail X is not an accessor on the distribution channel, and the accessor role is “retail”. Therefore, from the access authority information, the target information “<product information>” and the access control information corresponding to the accessor role “retail”, access ID “*” (arbitrary player ID), and ownership history “none”. Read “reference permission”. Accordingly, the access server 4 determines that only the product information among the information acquired from the terminal 2b is information that can be provided to the retail X.
The access server 4 stores accessor role information corresponding to the player ID in advance, or the terminal 2 transmits the accessor role information together with the information collection request in step S311. .

  The access server 4 returns the permitted information to the terminals 2c and 2x as a result of the filtering in step S314 (step S315). That is, the merchandise information and price information included in the information acquired from the terminals 2a and 2b are returned to the terminal 2c of the retail C, and the merchandise information included in the information acquired from the terminal 2b is returned to the terminal 2x of the retail X. Will be returned.

[3.2 Access control distributed type]
The access control distributed type is a case where the server collects “thing information” and the terminal of each player performs access control. A server that collects “things information” is called an “access server”.
When the access server receives a request for collecting information about “thing information” from the access source, the access server accesses the route server and holds a list of players holding “thing information” (that is, players of distribution route information). To get. If no “object information” is provided to a player who is not on the distribution channel, a player who cannot be referred to as an access source at this time, that is, an access source (information request source) player not included in the player list. Can be eliminated. Next, the access server collects “item information” from the player's terminal based on the acquired player list. Upon receiving the information acquisition request, each player terminal filters information that cannot be referred to by the access source according to the registration status in the route server, and returns only the information that can be referred to the access server. The access server returns the filtered “thing information” returned from the terminal to the access source terminal.

  FIG. 10 is a diagram showing a configuration of an access control distributed trace system and an access control procedure at the time of information distribution. The access control distributed trace system configuration is the same as that of the complete server type, except that each terminal 2 holds access authority information and filters information, not the access server 4.

  From the information collection request in step S321 to the acquisition of the player list having “thing information” in step S322, the information collection request in step S311 of the complete server type in FIG. 9 to the “item information” in step S312 in FIG. This is the same operation procedure as the acquisition of the player list. Here again, the player who wants to acquire information on the goods is assumed to be retail C and retail X, corresponding to retail C, player IDs “PF-A”, “PF-B”, “PF-C”, and corresponding to these player IDs. The address is read out as a player list, and the player ID “PF-B” and its address are read out as a player list corresponding to the retail X.

The access server 4 transmits an “object information” acquisition request to the terminal 2 of the player included in the player list acquired in step S322 (step S323). This acquisition request includes an ID for identifying the object for which information is to be acquired, and information on the player ID of the access source player, the accessor role, and the ownership history. Accordingly, in response to the information collection request from the retail C, acquisition of “information of goods” to the terminals 2a and 2b excluding the terminal 2c of the retail C and to the terminal 2b in response to the information collection request from the retail X A request is sent.
The access server 4 stores information on the accessor role corresponding to the player ID in advance, and the accessor role read out corresponding to the player ID received from the access source terminal 2 is referred to as “thing information”. The access server 4 receives the information on the accessor role of the access source from the access source terminal 2 at the time of the information collection request in step S311. Information "may be transmitted to the terminal 2 that is the request destination.

Each terminal 2 that has received the “object information” acquisition request in step S323 filters information that cannot be referred to by the access source player among the “object information” held by the terminal 2 (step S324).
For example, the terminal 2a refers to the access authority information held by itself and corresponds to the access source player ID “PF-C”, the accessor role “retail”, and the possession history “present” received from the access server 4. The target information “<product information><priceinformation>” and the access control information “reference permission” are read out. Accordingly, the terminal 2a determines that the access source player (retail C) identified by the player ID “PF-C” is the product information among the “item information” held by itself, which is identified by the ID “1”. It is determined that only the price information can be provided.

  Further, for example, the terminal 2b refers to the access authority information held by itself and corresponds to the received access source player ID “PF-C”, the accessor role “retail”, and the possession history “present”. While reading information “<product information> <price information>” and access control information “reference permission”, it corresponds to access source player ID “PF-X”, accessor role “retail”, possession history “none”. The target information “<product information>” and the access control information “reference permission” are read out. Therefore, the terminal 2b has only the merchandise information out of the “thing information” held by itself, which is specified by the ID “1”, for the player (retail C) specified by the player ID “PF-C”. It is information that can be provided, and it is determined that only product information can be provided to the player (retail X) identified by the player ID “PF-X”.

  Each terminal 2 returns the information filtered in step S324 to the access server 4 together with the player ID (step S325). The access server 4 returns the information received from the terminal 2 to the access source terminal 2 (step S326). Thereby, the access server 4 returns the product information and price information acquired from the terminals 2a and 2b to the terminal 2c of the retail C, and the product information acquired from the terminal 2b is returned to the terminal 2x of the retail X. .

[3.3 Completely distributed type]
The fully distributed type is a case where both the collection of “thing information” and the access control are performed at the player's terminal.
A player who wants to refer to “information of goods” first accesses the route server from his / her terminal to obtain a list of players holding “information of goods” (that is, players of distribution route information). Next, the terminal of the access source (information requesting source) player collects “thing information” based on the acquired player list. The collection of “object information” may be performed by directly accessing a player terminal shown in the player list or via a route server. The player terminal that provides the “thing information” performs filtering on information that cannot be referred to by the access source according to the registration status in the route server, and only the referable information is directly or via the access server. Return it to the player's terminal.

FIG. 11 is a diagram showing the configuration and processing flow of a fully distributed trace system.
In the figure, the difference between the configuration of the fully distributed trace system and the configuration of the access control distributed trace system shown in FIG. 10 is that there is no access server 4. That is, the terminal 2a of the manufacturer A, the terminal 2b of the wholesale B, the terminal 2c of the retail C, the terminal 2x of the retail X, and the route server 3 are connected via the network, and the route server 3 stores the distribution route information information. Each terminal 2 holds access authority information.

  In the figure, the information requesting player who wants to acquire “information of an object” uses the terminal 2 held by the player to specify an ID for identifying an object for which information is to be acquired, that is, a tag assigned to the object at least during distribution. 1 tag ID and own player ID are transmitted to the route server 3. Here, the information requesting player is assumed to be retail C and retail X. The terminal 2c of the retail C gives the access source player IDs “PF-C” and ID “1”, and the terminal 2x of the retail X gives the access source player IDs “PF-X” and ID “1” to the route server 3. Send.

  The route server 3 searches the distribution route information by using the ID for specifying the information acquisition target and the access source player ID as a key in the same procedure as the complete server type and the access control distributed type, and holds “thing information”. A list of players (that is, players on the distribution channel) and their addresses is acquired (step S331). The route server 3 returns the read player list to the corresponding terminal 2. Thereby, the terminal 2c of the retail C receives the player list of the player IDs “PF-A”, “PF-B”, and “PF-C”, and the terminal 2x of the retail X receives the player ID “PF-B”. Only as a player list.

  The access source terminal 2 that has received the player list requests “information on the object” from the terminal 2 of the player other than itself, which is indicated by the player list received in step S331 (step S332). That is, the terminal 2c of the retail C sends “information of goods” to the terminal 2a of the manufacturer A specified by the player ID “PF-A” and the terminal 2b of the manufacturer B specified by the player ID “PF-B”. Send a reference request for. This reference request includes an ID “1” for specifying the information acquisition object and an access source (information request source) player ID “PF-C”. Further, the retail X terminal 2x transmits a reference request for “information on the product” to the terminal 2b of the manufacturer B specified by the player ID “PF-B”. This reference request includes an ID “1” for specifying the information acquisition object and an access source (information request source) player ID “PF-X”.

  In step S332, the terminal 2 that has received the reference request for “thing information” requests distribution route information from the route server 3 (step S333). The distribution route information request includes the ID information received in step S332. The route server 3 refers to the distribution route information, identifies the record specified using the ID received from the terminal 2 as a key, and returns the distribution route information including the player ID information read from the identified record. For example, when the ID “1” is received from the terminals 2a and 2b, the player ID “PF-A”, the address “192.168.0.1” specified by the tag ID “01”, the reference authority “distribution route” A record including information “open only to the above accessor”, a record including player ID “PF-B”, address “192.168.0.2”, and reference authority “opening to all accessors” , Distribution route information including a player ID “PF-C”, an address “192.168.0.3”, and a reference authority “open only to the access person on the distribution route” is returned.

In step S333, the terminal 2 that acquired the distribution route information from the route server 3 performs filtering on information that cannot be referred to by the access source player among the “item information” held by the terminal 2 (step S334).
For example, since the access source player ID “PF-C” is included as the player ID in the distribution route information acquired in step S333, the retail C (player PF-C) is an accessor on the distribution route. To be judged. The accessor role of the player (retail C) with the access source player ID “PF-C” is “retail”. Therefore, from the access authority information, the target information “<product information><priceinformation>”, corresponding to the accessor role “retail”, access ID “*” (arbitrary player ID), and ownership history “present”, and The access control information “reference permission” is read. Therefore, the terminals 2a and 2b are identified by the ID “1” and only the product information and the price information among the “item information” held by the terminal 2a and 2b are the players (retails) of the access source player ID “PF-C”. It is determined that the information can be provided to C).

  On the other hand, since the access source player ID “PF-X” is not included as the player ID in the distribution route information acquired in step S333, the retail X (player PF-X) is not an access person on the distribution route. To be judged. Further, the accessor role of the player (retail X) of the access source player “PF-X” is “retail”. Therefore, from the access authority information, the target information “<product information>” and the access control information corresponding to the accessor role “retail”, access ID “*” (arbitrary player ID), and ownership history “none”. Read “reference permission”. Therefore, the terminal 2b can provide only the product information among the “item information” held by the terminal 2b, which is specified by the ID “1”, to the player (retail X) having the access source player ID “PF-C”. Judgment information.

  The route server 3 may store information on the accessor role in advance corresponding to the player ID, and transmit the accessor role to the terminal 2 together with the distribution route information. The terminals 2c and 2x The information on the accessor role transmitted together with the information reference request in step S332 may be transmitted.

  The terminal 2 that has received the information reference request returns information permitted to be provided as a result of filtering in step S334 to the access source (information request source) terminal 2 (step S335). Accordingly, the product information and price information are returned from the terminals 2a and 2b to the terminal 2c of the retail C, and the product information is returned from the terminal 2b to the terminal 2x of the retail X.

[4. Others]
The points of the above embodiment are summarized as follows.
(1) A player on the distribution route performs pre-registration in a daisy chain, so that even a player who does not know the distribution route in advance can limit the information to only the players on the distribution route and disclose the information.
(2) Since the authentication code is written in the tag, the present invention can also be applied in an environment where there are players with different management schemes or players who are not systemized in the middle of the distribution channel.
(3) Since the authentication code changes each time the player moves between players, it is possible to prevent a player who has once obtained an item from illegally registering distribution channel information after releasing the item.

In the trace system described above, distribution (distribution) is described as an example. However, it is applicable if the trace target managed by the ID is an application that moves between a plurality of players. In the above embodiment, the player ID is assigned to the company unit on the distribution route. However, the player ID assignment unit is arbitrary, and may be an individual or group unit according to the unit in which the trace target is distributed / moved. .
In addition, an information storage device such as an ID and an authentication code assigned to a trace target can be other than a tag.

In the conventional technique, in “registration of distribution route information”, each player (trader) on the distribution route registers its own information in the server in association with the ID, and whether the distribution route is correct based on the registered information. The server confirms (Patent Document 1) or restricts the persons who register the history information (Patent Document 2). Further, the range of information that can be provided is specified according to the information requester, and the specified information is provided (Patent Documents 3 and 4).
However, in the method for limiting information registrants according to the present embodiment, when an object moves between players, the movement source player pre-registers the movement destination player in the route server. The route server only allows registration requests from pre-registered players, thereby preventing unauthorized distribution route information from being registered by a third party who has not been pre-registered.

  Further, in another method for restricting information registrants, when a player at each stage on the distribution channel of goods obtains a thing, it is stored in a tag attached to the obtained thing by using a secret key respectively possessed. The encrypted information is further encrypted, authenticated by the server, the encrypted information is registered in the tag, and the distribution channel information is registered in the server. Accordingly, it is possible to prevent registration of information by a player other than the player who actually has a thing (tag) based on information until immediately before registration on the server side.

  As described above, in the present embodiment, when registering data to a tag attached to a product to be distributed, a registrant who first attaches the tag to a product encrypts an initial random number with his / her private key (encryption Registration information) is registered in the tag and the center, and the next registrant in the distribution channel encrypts the encrypted information registered in the tag with his / her private key and asks the center for authentication. Is decrypted, the encrypted information registered corresponding to the tag is confirmed and authenticated, and if the authentication result is positive, data registration is permitted.

  Therefore, even when the distribution route is not known in advance, it is possible to realize access control so that information on objects can be disclosed only to players on the distribution route. Further, since access control based on actual possession of goods is performed, it is possible to prevent a third party who does not physically obtain the goods from illegally acquiring information on the goods. As a result, it is possible to safely distribute information that is desired to be kept secret to non-distribution parties such as receipt / shipment data, transaction data, and purchase data.

Further, in the present embodiment, even if a player outside the system is routed in the middle of the distribution route, the distribution route information is registered within the range of the players connected to the same route server, or on the distribution route. It is possible to publish limited information on items only to players. This enables safe information distribution even in an environment where a plurality of management schemes are mixed or in an environment where there is a difference in systemization level among players.
Further, in the method of using a unified authentication code for a plurality of players, there is a possibility that a player who has once picked up an item may register the distribution route information after releasing the item. In this embodiment, on the distribution route, Since the authentication code changes every time the player changes, unauthorized registration after releasing an item can be prevented.

  Note that the terminal 2, the route server 3, and the access server 4 described above have a computer system therein. The operation processes of the terminal 2, the route server 3, and the access server described above are stored in a computer-readable recording medium in the form of a program, and the computer system reads and executes this program. The above processing is performed. The computer system here includes a CPU, various memories, an OS, and hardware such as peripheral devices.

Further, the “computer system” includes a homepage providing environment (or display environment) if a WWW system is used.
The “computer-readable recording medium” refers to a storage device such as a flexible medium, a magneto-optical disk, a portable medium such as a ROM and a CD-ROM, and a hard disk incorporated in a computer system. Furthermore, the “computer-readable recording medium” dynamically holds a program for a short time like a communication line when transmitting a program via a network such as the Internet or a communication line such as a telephone line. In this case, a volatile memory in a computer system serving as a server or a client in that case is also used to hold a program for a certain period of time. The program may be a program for realizing a part of the functions described above, and may be a program capable of realizing the functions described above in combination with a program already recorded in a computer system.

It is a figure which shows the structure of a trace system in case all the players are using the same path | route server, and a player pre-registration procedure. It is a figure which shows the distribution route information registration procedure in the trace system shown in FIG. It is a figure which shows the structure of a trace system when the player who is not using the same route server exists, and the registration procedure of distribution route information. It is a figure which shows the production | generation process sequence of the authentication code in the terminal of each player at the time of using a public key cryptosystem. It is a figure which shows the verification process procedure of the authentication code in a path | route server at the time of using a public key cryptosystem. It is a figure which shows the structure of a trace system at the time of using a public key encryption system, and an operation | movement procedure. It is a figure which shows the production | generation process sequence of the authentication code in the terminal of each player at the time of using a hash. It is a figure which shows the verification processing procedure of the authentication code in a path | route server when a hash is used. It is a figure which shows the structure of a complete server type trace system, and the access control procedure at the time of information delivery. It is a figure which shows the structure of an access control distributed type trace system, and the access control procedure at the time of information delivery. It is a figure which shows the structure of a fully distributed trace system, and the access control procedure at the time of information delivery.

Explanation of symbols

1 ... tags 2a, 2b, 2c, 2x ... terminal 3 ... route server 4 ... access server

Claims (4)

A trace system comprising: an information recording medium attached to a trace target; a player's terminal; and a route server connected to the terminal via a network and managing information on a route on which the trace target is distributed or moved. ,
The player's terminal on the route
Reading means for reading a trace target identifier for specifying a trace target from the information recording medium;
Route registration request means for sending a route registration request in which information of the trace target identifier read by the reading means is set to the route server;
A pre-registration request unit configured to transmit to the route server a pre-registration request in which information on a trace target identifier read by the reading unit and a pre-registration player who is a player who permits registration of route information is set next;
The route server is
Storage means for storing route information including information associating a tracing target identifier with a player on the route, and a pre-registration table indicating information associating the tracing target identifier with a pre-registered player;
The route registration request is received from the terminal of the player, and the route information corresponding to the trace target identifier in the received route registration request is unregistered, or the transmission source player in the route registration request Information corresponding to the trace target identifier, the information indicating that the transmission source player is on the route is displayed when the player is newly registered in the pre-registration table corresponding to the trace target identifier. Route registration means for registering the route information in the storage means;
The pre-registration request is received from the terminal of the player, and the player who has transmitted the pre-registration request is newly registered in the route information in the storage unit corresponding to the trace target identifier in the pre-registration request. And a pre-registration means for registering, in the pre-registration table in the storage means, information in which the tracing target identifier in the pre-registration request is associated with the pre-registration player.
Trace system characterized by that. The access server on the terminal or the network is
Access authority storage means for storing access authority information indicating a type of trace target related information that can be provided to a player on the path and a type of trace target related information that can be provided to a player not on the path;
A trace target identifier that identifies a trace target that is a target for acquiring related information and information of a player who requests the trace target related information are received, and the request source player responds to the trace target identifier with the route. The type of information that can be provided to the player requesting the information is specified based on whether or not it is registered as a player on the route in the route information in the storage means of the server and the access authority information in the access authority storage means. Providing the specified type of trace target related information among the trace target related information held in correspondence with the trace target identifier to the terminal of the player on the route to the terminal of the requesting player;
The trace system according to claim 1 .   Executed by a trace system having an information recording medium attached to a trace target, a player's terminal, and a route server connected to the terminal via a network and managing information on a route through which the trace target is distributed or moved A tracing method,
  The route server includes route information including information associating a tracing target identifier for specifying a tracing target with a player on the route, and pre-registration indicating information associating the tracing target identifier with a pre-registered player A storage means for storing the table;
  A reading step in which the reading means of the terminal of the player on the route reads the trace target identifier from the information recording medium;
  A route registration request step in which the route registration request means of the terminal of the player on the route transmits a route registration request in which the information of the trace target identifier read in the reading step is set to the route server;
  The route registration means of the route server receives a route registration request from the terminal of the player, and the route information corresponding to the trace target identifier in the received route registration request is unregistered or transmitted in the route registration request When the original player is the player most recently registered in the pre-registration table corresponding to the trace target identifier in the route registration request, the transmission source player corresponds to the trace target identifier. A route registration step of registering information on the route in the route information in the storage means;
  The pre-registration request means of the terminal of the player of the player on the route issues a pre-registration request in which information about the tracing target identifier read in the reading step and a pre-registered player who is the next player who is permitted to register the route information is set. A pre-registration request step to send to the route server;
  Pre-registration means of the route server receives a pre-registration request from the terminal of the player, and the player who has transmitted the pre-registration request most recently corresponds to the tracing target identifier in the pre-registration request. Pre-registration for registering, in the pre-registration table in the storage means, information in which the tracing target identifier in the pre-registration request is associated with the pre-registered player when the player is registered in the route information in the storage means Steps,
  A tracing method comprising: The route in a trace system comprising an information recording medium attached to a trace target, a player's terminal, and a route server connected to the terminal via a network and managing information on a route through which the trace target is distributed or moved Computer used as a server
Memory storing path information including information associating a trace target identifier for specifying a trace target with a player on the path, and a pre-registration table indicating information associating the trace target identifier with a pre-registered player Means ,
The route registration request is received from the terminal of the player, and the route information corresponding to the trace target identifier in the received route registration request is unregistered, or the transmission source player in the route registration request If in response to traced identifier of the inner is most newly player registered in the pre-registration table in correspondence with the traced identifier, the information indicating that the source of the player is on the path Route registration means for registering the route information in the storage means;
The pre-registration request is received from the terminal of the player, and the player who has transmitted the pre-registration request is newly registered in the route information in the storage unit corresponding to the trace target identifier in the pre-registration request. Pre-registration means for registering, in the pre-registration table in the storage means, information in which the tracing target identifier in the pre-registration request and the pre-registration player are associated with each other,
A computer program that functions as a computer program.

Images