JP2023160609A - Analysis service providing method, analysis service providing device, analysis service providing system, and program - Google Patents

Abstract

To provide an analysis service providing method, an analysis service providing device, an analysis service providing system, and a program, capable of reducing mistakes in placing samples in containers in analysis services in which samples are encapsulated in containers and delivered.SOLUTION: Disclosed is an analysis service providing method, in which a sample is encapsulated in a container and delivered, and which includes the steps of: associating a secret key and a public key with the container; receiving the analysis request from a requester; electronically signing information on the sample to be encapsulated in the container in response to the analysis request with the secret key associated with the container and transmitting the information to the requester; and requesting a custodian of the container to deliver the container, to which the public key associated with the container or its storage location has been added, to the requester.SELECTED DRAWING: Figure 2

Description

The present invention relates to an analytical service providing method, an analytical service providing device, an analytical service providing system, and a program.

Conventionally, contract-type analysis services have been provided in which a client sends a sample to an analyst, and the analyst returns the analysis results to the client. For example, Patent Document 1 discloses a method of receiving a test analysis sample from a user who desires test analysis and providing the user with test analysis data that is the result of the test analysis of the user sample.

Japanese Patent Application Publication No. 2005-43257

Even with the analysis service described in Patent Document 1, there are no security measures in place to prevent the leakage of analysis information, such as user authentication for the client, encryption of analysis results, and non-disclosure agreements between the client and the analysis contractor. It is being taught. However, although it is necessary to deliver the correct sample to the analyst, the analysis service described in Patent Document 1 does not take any measures to prevent sample mix-ups.

In outsourced analysis services, samples are sealed in special transport containers prepared for the sample and sent to analysts. After the sample is sealed in the transport container, the sample is identified by the identification information added to the transport container. Therefore, if the requester mistakenly stores another sample in the transport container and sends it, the analysis will continue as is, and there is a problem in that the requester will not be able to obtain the intended analysis results.

The present invention has been made in view of the above-mentioned problems, and an object of the present invention is to provide a method for providing an analytical service that can reduce mistakes in placing a sample in a container in an analytical service that encloses a sample in a container and delivers it. The purpose of the present invention is to provide an analytical service providing device, an analytical service providing system, and a program.

An analysis service providing method according to one aspect of the present disclosure is an analysis service providing method in which a sample is sealed in a container and delivered, the method comprising: associating a private key and a public key with the container;
a step of receiving an analysis request from a requester; a step of electronically signing information regarding a sample to be sealed in the container in response to the analysis request with the private key associated with the container and transmitting the same to the requester; requesting a custodian of the container to deliver the container to which the public key related to the public key or its storage location is added to the requester.

An analysis service providing device according to one aspect of the present disclosure is an analysis service providing device that encloses a sample in a container and delivers the sample, and includes a container registration unit that associates a private key and a public key with the container, and an analysis request from a client. a signature generation unit that digitally signs information regarding a sample to be sealed in the container in response to the analysis request using the private key associated with the container and sends it to the requester; and a delivery requesting unit that requests a custodian of the container to deliver the container to which the related public key or its storage location is added to the requester.

An analysis service providing system according to an aspect of the present disclosure includes an analysis service providing device of the present disclosure and a client terminal including a signature verification unit that verifies an electronic signature, the signature verification unit reading from the container. The received electronic signature is verified using the public key and the information associated with the container.

A program according to one aspect of the present disclosure is a program for an analysis service that encloses a sample in a container and delivers it, and includes steps of associating a private key and a public key with the container by a computer, and receiving an analysis request from a client. a step of receiving information regarding a sample to be sealed in the container in response to the analysis request, electronically signing the information with the private key associated with the container and transmitting the information to the requester; or requesting a custodian of the container to deliver the container to which the storage location has been added to the requester.

According to the present invention, in an analysis service in which a sample is sealed in a container and delivered, it is possible to reduce mistakes in placing a sample in a container.

It is a figure showing an example of the appearance of a container. FIG. 1 is a schematic diagram for explaining the outline of the present invention. 1 is a schematic diagram showing an example of the configuration of an analysis service providing system according to a first embodiment of the present invention. FIG. 2 is a block diagram showing an example of an electrical configuration of a server. FIG. 2 is a block diagram showing an example of an electrical configuration of a terminal device. FIG. 2 is a sequence diagram showing an example of the processing flow of the analysis service providing system according to the first embodiment of the present invention. FIG. 1 is a functional block diagram of the main parts of the analysis service providing system of the present invention. It is a screen transition diagram showing an example of a UI screen displayed on a client terminal. It is a screen transition diagram showing an example of a UI screen displayed on an analyst terminal. It is a schematic diagram which shows an example of the process of a container registration process. It is a flowchart which shows an example of the flow of "container registration processing" by a server. It is a chart showing an example of the data structure stored in container DB. FIG. 3 is a schematic diagram showing an example of processing of an analysis request/acceptance process. 12 is a flowchart illustrating an example of the flow of "requester main processing" performed by the requester terminal. 12 is a flowchart illustrating an example of the flow of "new registration processing" performed by the client terminal. It is a flowchart which shows an example of the flow of "OTP input processing" by a client terminal. 2 is a flowchart illustrating an example of the flow of "analysis request reception processing" performed by the server. 12 is a flowchart illustrating an example of the flow of "analyst main processing" by the analyst terminal. 12 is a flowchart illustrating an example of the flow of "analysis request processing" by an analyst terminal. It is a schematic diagram which shows an example of the process of an enclosure instruction creation process. 12 is a flowchart illustrating an example of the flow of "enclosure instruction input processing" by the analyst terminal. 2 is a flowchart illustrating an example of the flow of "signature generation processing" performed by the server. It is a schematic diagram which shows an example of the process of a sample sending process. 12 is a flowchart illustrating an example of the flow of "requested matter processing" by the client terminal. It is a flowchart which shows an example of the flow of "container identifier reading processing" by a client terminal. 12 is a flowchart illustrating an example of the flow of "inclusion instruction display processing" performed by the client terminal. It is a flowchart which shows an example of the flow of "sample information input processing" by a client terminal. It is a schematic diagram which shows an example of the process of an analysis report process. 12 is a flowchart illustrating an example of the flow of "analysis report processing" by an analyst terminal. 12 is a flowchart illustrating an example of the flow of "analysis completion processing" performed by the server. FIG. 7 is a sequence diagram showing an example of the processing flow of the analysis service providing system according to the second embodiment of the present invention. FIG. 3 is a schematic diagram showing an example of an additional configuration of an analysis service providing system according to a third embodiment of the present invention. (A) is a schematic diagram showing a functional arrangement corresponding to a "one-to-one" analysis request, and (B) is a schematic diagram showing a functional arrangement corresponding to a "many-to-many" analysis request.

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

[First embodiment]
<Summary of the invention>
First, the container will be explained with reference to FIG.
When the container 30 in which the sample is sealed and transported is registered, a private key and a public key are generated for the container 30, and an identification mark representing the public key is generated. Here, examples of the identification mark include a two-dimensional code such as a QR code (registered trademark) and a one-dimensional code such as a bar code. As shown in FIG. 1, the identification mark representing the public key is physically attached to the container 30 in a non-removable manner by directly marking the container, printing directly on the container, embedding it in the container, or the like. These identification marks can be read optically or electromagnetically. In addition, below, the case where a two-dimensional code is used as an identification mark and the two-dimensional code is engraved on the container 30 is demonstrated.

Next, an overview of the present invention will be explained with reference to FIG.
As shown in FIG. 2, the requester 10 makes an analysis request, and the analyst 14 accepts the analysis request. Here, it is assumed that the client 10 requests the analysis of two samples A and B, and the analyst 14 accepts the request for analysis of the samples A and B. The analyst 14 prepares a container 30A and a container 30B, and assigns the container 30A to the sample A and the container 30B to the sample B. Container 30A and container 30B are delivered to client 10.

The analyst 14 creates an enclosure instruction containing information regarding the sample A to be enclosed in the container 30A, and encrypts it using a common key held by the client 10 and the analyst 14. In addition to the name of the sample, the enclosing instructions may include dimensions of the sample piece to be enclosed, precautions during processing and enclosing, return address, and the like. The inclusion instructions are not limited to documents, but may also be photographs or videos. The analyst 14 generates an electronic signature for the encrypted enclosing instruction using the private key of the container 30A. Note that if a server 18, which will be described later, is involved, strictly speaking, the server 18 generates the electronic signature. Similarly, the analyst 14 creates and encrypts an enclosing instruction for sample B, and generates an electronic signature for the encrypted enclosing instruction using the private key of the container 30B. The encrypted text of the enclosing instruction and its electronic signature are transmitted to the client 10 separately from the container 30.

The requester 10 has the container 30A, the container 30B, the encrypted text of the instruction to enclose sample A, the encrypted signature (i.e., electronic signature) of the enclosing instruction of sample A, the encrypted text of the instruction to enclose sample B, and the encrypted text of the instruction to enclose sample B. The ciphertext signature (i.e. electronic signature) of the enclosing instruction has been received. The client 10 reads the public key of the container 30A, and verifies the authenticity of the encrypted text of the enclosing instruction using the public key of the container 30A. The only thing whose authenticity can be verified using the public key of the container 30A is the encrypted text of the instruction to enclose the sample A, which is digitally signed using the private key of the container 30A. The requester 10 decrypts the ciphertext of the enclosing instruction for the sample A whose authenticity has been verified using the common key, and encloses the sample A in the container 30A according to the enclosing instruction.

Similarly, the client 10 reads the public key of the container 30B and verifies the authenticity of the encrypted text of the enclosing instruction using the public key of the container 30B. The requester 10 is the one whose authenticity can be verified, that is, decrypts the encrypted text of the enclosing instruction for the sample B using the common key, and encloses the sample B in the container 30B according to the enclosing instruction.

As shown in this example, the analysis service providing method of the present disclosure generates a private key and a public key for each container 30, uses them as an electronic tally, and verifies the authenticity of the enclosure instruction digitally signed with the private key. , it can be verified only by a public key that is physically imprinted on the container 30 in a non-removable form. Thereby, the enclosing instruction linked to the container 30 by the analyst 14 can be safely and reliably transmitted to the client 10. Therefore, with this configuration, the analysis service providing method of the present disclosure can obtain the following effects 1) to 3).

1) Enclosing in which only an enclosure instruction that can be verified with the public key engraved on the container 30 can be presented to the client 10, and the client 10 misunderstands the instructions of the analyst 14 and the sample is enclosed in an unintended container 30. Mistakes can be reduced.

2) Even if the wrong container 30 is delivered to the client 10, there is no verifiable charging instruction, and it is possible to reduce the possibility of a filling error in which the sample is sealed in the wrong container 30.

3) Since the packaging instructions are encrypted, it is difficult for a third party to eavesdrop on the package, and even if a malicious third party changes the container or falsifies the return address, it will be detected through verification. I can do it.

<Configuration of analysis service provision system>
Next, the configuration of the analysis service providing system will be explained with reference to FIGS. 3 to 5.
As shown in FIG. 3, the analysis service providing system 1 includes a client terminal 12 used by a client 10, an analyst terminal 16 used by an analyst 14, a server 18 which is an example of an analysis service providing device, and a stockyard. 20 is provided with a terminal device (not shown). The server 18 is located on a cloud, for example.

In the following, the configuration surrounded by dotted lines in FIG. 3 will be mainly described. The main components of the analysis service providing system 1 are a client terminal 12 used by a client 10 and a server 18. The functions of the analyst terminal 16 can also be performed by the server 18.

The analysis service providing system 1 may optionally further include various external devices 24 arranged in a server (not shown) of the analysis center 22. In this example, the external equipment 24 is exemplified by an analyzer 24A, a storage 24B, and a transport vehicle 24C. In response to instructions from the analyst 14, the server 18 causes these external devices 24 to perform various processes (eg, analysis, storage, transportation) on the container 30 in which the sample is sealed.

The client terminal 12, the analyst terminal 16, the terminal device in the stockyard 20, and the server in the analysis center 22 are each communicably connected to the server 18 via a wired or wireless communication line such as the Internet. Furthermore, the analysis device 24A, the storage 24B, and the transport vehicle 24C are communicably connected to the server of the analysis center 22 via a wired/wireless communication line such as a LAN. Furthermore, the container 30 can be delivered between the client 10, the analyst 14, the stockyard 20, and the analysis center 22, as indicated by the vehicle icon.

The terminal device in the stockyard 20 requests the server 18 to register the container 30, and obtains information on the public key of the container 30 from the server 18. A worker at the stockyard 20 stamps a two-dimensional code representing the public key on the container 30 based on the information on the public key of the container 30. Further, the terminal device in the stockyard 20 receives an instruction to ship the container 30 from the analyst 14 and prompts the worker to ship the container 30.

In response to a request from a terminal device in the stockyard 20, the server 18 registers the container 30, generates a private key and a public key for the container 30, and generates a container ID for identifying the container 30 and a private key for the container 30. , the public key, and the specifications (width, height, depth, etc.) of the container 30 are associated with each other and stored in a container database 48C, which will be described later, to manage this information. The server 18 discloses the public key of the container 30 in response to an inquiry from the client 10 or the analyst 14. The server 18 manages various other information in a database (hereinafter abbreviated as "DB"). The server 18 applies an electronic signature to the encrypted text of the enclosing instruction.

The client terminal 12 provides the client 10 with an input/output interface for various information. The client terminal 12 generates a temporary common key and encrypts or decrypts various information using the temporary common key. The client terminal 12 verifies the authenticity of the encrypted text of the enclosing instruction using the public key of the container 30 read by a camera 62, which will be described later.

The analyst terminal 16 provides the analyst 14 with an input/output interface for various information. The analyst terminal 16 generates a temporary common key and encrypts or decrypts various information using the temporary common key.

The external device 24 is a device for supporting remote analysis by the analyst 14. When analysis is performed at analysis center 22, server 18 causes external equipment 24 to process containers 30 in response to instructions from analyst 14.

If the analysis is performed at the analysis center 22, the location of the storage 24B will be written as the return destination in the enclosing instruction. The rate of remote analysis work is determined by the inventory of containers 30 and the availability of storage 24B. For this reason, the analyst 14 checks not only the inventory of the containers 30 but also the availability of the storage 24B when creating the enclosing instruction.

An ID (hereinafter referred to as a "storage location ID") is assigned to each storage location in the storage warehouse 24B. The server 18 stores the storage location ID of the container 30 in association with the ID of the container 30. The storage 24B is not just a warehouse, but also operates as a device for receiving and storing containers 30 containing samples. The server 18 instructs the storage 24B to store the container 30 containing the sample in the storage location specified by the storage location ID.

In the case of remote analysis, the server 18 takes out the container 30 containing the sample from the storage 24B in response to an instruction from the analyst 14, transports the sample to the analysis device 24A by the carrier 24C, and removes the sample from the container 30. The sample is taken out and set in the analyzer 24A. Further, the server 18 causes the analyzer 24A to analyze the sample set in accordance with instructions from the analyst 14.

(Electrical configuration of server)
As shown in FIG. 4, the server 18 includes a CPU (Central Processing Unit) 40, a memory 42, a storage section 44, a communication section 46, and various DBs 48. The CPU 40 , memory 42 , storage section 44 , communication section 46 , and various DBs 48 are connected via a bus 49 so that they can communicate with each other.

CPU 40 is a central processing unit. The memory 42 is comprised of RAM (Random Access Memory) and temporarily stores programs and data as a work area. The storage unit 44 includes a ROM (Read Only Memory), an HDD (Hard Disk Drive), an SSD (Solid State Drive), etc., and stores various programs including an operating system and various data.

The CPU 40 reads a program from the storage unit 44 and executes the program using the memory 42 as a work area. Further, the CPU 40 controls each of the above sections and performs various arithmetic processing according to a program stored in the storage section 44.

The communication unit 46 is an interface for communicating with other devices. Various DB48s include
It includes an account DB 48A that manages account information of the client 10, an analysis request DB 48B that manages analysis request information, and a container DB 48C that manages container information.

(Electrical configuration of terminal device)
As shown in FIG. 5, a client terminal 12 and an analyst terminal 16 are provided as terminal devices. Since both have the same configuration, the configuration of the client terminal 12 will be explained here. The client terminal 12 includes a CPU 50, a memory 52, a storage section 54, an operation input section 56, a display section 58, a communication section 60, and a camera 62. The CPU 50 , the memory 52 , the storage section 54 , the operation input section 56 , the display section 58 , the communication section 60 , and the camera 62 are connected to each other via a bus 64 so that they can communicate with each other.

The CPU 50, memory 52, storage section 54, and communication section 60 are the same as the CPU 40, memory 42, storage section 44, and communication section 46 of the server 18. An operation input unit 56 is a device for inputting various information, such as a keyboard and a mouse. The display unit 58 is, for example, a device such as a display or a printer for outputting various information. A touch panel display may be provided as the operation input section 56 and the display section 58. The camera 62 is a device for capturing an image, and is provided here for reading a two-dimensional code. The CPU 50 controls each of the above sections and performs various arithmetic operations according to a program stored in the storage section 54. The storage unit 54 also stores application programs such as a web browser.

In addition, in FIG. 5, the symbols of each part of the analyst terminal 16 are also written in parentheses. As described, the analyst terminal 16 includes a CPU 51, a memory 53, a storage section 55, an operation input section 57, a display section 59, a communication section 61, and a camera 63.

<Overall process flow of the analysis service provision system>
Next, the overall flow of processing of the analysis service providing system will be explained.
The processing of the analysis service providing system can be roughly divided into the following six steps.
(1) Container registration step in which the server 18 registers the container 30 (2) Analysis request step in which the requester 10 requests an analysis (3) Analysis request acceptance step in which the analyst 14 accepts the analysis request (4) Analyst 14 (5) Sample delivery step (6) The analyst 14 delivers the analysis report to the client 10. Analysis report process

First, the flow of processing of the analysis service providing system will be schematically explained with reference to the sequence diagram of FIG. Note that here, the main body of the processing is conceptually represented, and the client terminal 12 is referred to as the "requester 10," the analyst terminal 16 is referred to as the "analyst 14," and the terminal device in the stockyard 20 is referred to as the "stockyard 20." .

In the container registration step (1), the stockyard 20 requests container registration from the server 18 (S2). The server 18 registers the container 30 in response to a request from the stockyard 20, generates a private key and a public key for the container 30 (hereinafter referred to as a "container private key" and a "container public key"). Information on each key is stored in the container DB 48C (S4). The server 18 provides the container public key to the stockyard 20 (S6). The stockyard 20 generates a two-dimensional code representing the container public key and stamps it on the container 30 (S8).

In the analysis request step (2), the requester 10 requests the server 18 to start the request (S10). The server 18 starts accepting analysis requests, and in response to the request from the client 10, transmits temporary common key parameters for generating a temporary common key to the client 10 (S12). The client 10 generates a temporary common key, creates an analysis request, and encrypts it with the temporary common key (S14). The client 10 transmits the ciphertext of the analysis request to the server 18 (S16). Note that the requester 10 may encrypt sample information regarding the sample using a temporary common key and include it in the analysis request.

(3) In the analysis request acceptance step, the analyst 14 requests an analysis request query from the server 18 (S18). The server 18 transmits the temporary common key parameter to the analyst 14 in response to the request from the analyst 14 (S20). The analyst 14 generates a temporary common key (S22). The analyst 14 obtains the ciphertext of the analysis request from the server 18 (S24). The analyst 14 decrypts the ciphertext of the analysis request using the temporary common key and views it (S26).

In the inclusion instruction creation step (4), the analyst 14 creates an inclusion instruction and encrypts it with a temporary common key (S26). The analyst 14 orders the container 30 from the server 18 (S28). The server 18 instructs the stockyard 20 to ship the container 30 selected by the analyst 14 (S30). The analyst 14 transmits the encrypted text of the enclosing instruction to the server 18 (S32). The server 18 calculates a hash value of the shared information (ciphertext of the enclosing instruction and the container public key) and generates an electronic signature using the container private key (S34). The server 18 transmits the encrypted text and electronic signature of the enclosing instruction to the client 10 (S36).

In the sample sending step (5), the container 30 is sent from the stockyard 20 to the client 10 (S38). The requester 10 reads the container public key from the container 30, combines it with the encrypted text of the received enclosing instruction to form shared information, calculates a hash value, and verifies the hash value and the electronic signature using the container public key. (S40). The client 10 decrypts the encrypted text of the enclosing instruction using the temporary common key, and encloses the sample in the container 30 according to the enclosing instruction (S42). The client 10 sends the container 30 containing the sample to the analyst 14 (S44). Note that the requester 10 may encrypt sample information regarding the sample using a temporary common key and transmit it to the analyst 14.

In the analysis report step (6), the analyst 14 analyzes the sample, creates an analysis report, and encrypts it with a temporary common key (S46). The analyst 14 delivers the ciphertext of the analysis report to the client 10 (S48). The client 10 decrypts the ciphertext of the analysis report using the temporary common key and views it (S50). Finally, the analyst 14 returns the container 30 to the stockyard 20 (S52).

FIG. 7 is a diagram showing the analysis service providing system 1 that executes the sequence shown in FIG. 6 using functional blocks. As shown in FIG. 7, the analysis service providing system 1 includes a client terminal 12, an analyst terminal 14, and a server 18 that can communicate with each other via a communication line N. The server 18 includes a container registration section 300 that associates a private key and a public key with a container 30, a request reception section 302 that receives an analysis request from a requester 10, and a container 30 that stores information regarding a sample to be sealed in the container 30 in response to an analysis request. a signature generation unit 304 that sends an electronic signature with a private key associated with the container 30 to the client 10; and a signature generation unit 304 that sends an electronic signature with a private key associated with the container 30 to the client 10; and a delivery requesting unit 306 that makes a request to the custodian of the container 30. The server 18 also functions as a web server.

The client terminal 12 includes an interface providing section 310, an encryption/decryption section 312, and a signature verification section 314. The analyst terminal 16 includes an interface providing section 320 and an encryption/decryption section 322. Interface providing units 310 and 320 provide user interfaces. The encryption/decryption units 312 and 322 encrypt or decrypt information. The signature verification unit 314 verifies the electronic signature based on the public key and the information to be signed. Each of the interface providing units 310 and 320 functions as a web browser.

<UI screen transition>
As shown in FIG. 8, the UI screen displayed on the display unit 58 of the client terminal 12 includes a client main screen 100, a new request screen 110, an OTP input screen 120, a requested project screen 130, and a container identifier reading screen. 140, an enclosure instruction display screen 150, and a sample information input screen 160. These screens transition to the next screen when a specific selection is made, as indicated by arrows. Details of each screen will be described later.

As shown in FIG. 9, the user interface (hereinafter abbreviated as "UI") screen displayed on the display unit 59 of the analyst terminal 16 includes an analyst main screen 170, an analysis request screen 180, and an enclosure instruction input screen. It includes a screen 190 and an analysis report input screen 200. These screens transition to the next screen when a specific selection is made, as indicated by arrows. Details of each screen will be described later.

<Each processing step of the analysis service provision system>
Below, while also referring to the UI screens shown in FIGS. 8 and 9, (1) container registration process, (2) analysis request process, (3) analysis request acceptance process, (4) enclosure instruction creation process, (5) Each of the sample sending process and (6) analysis reporting process will be explained in detail.

The analysis service provided by the server 18 uses a website that can be viewed using the HTTPS protocol, and the server 18 functions as a web server. Each of the client terminal 12 and the analyst terminal 16 displays various UI screens via a web browser and accepts operations on the various UI screens. That is, the CPU 50 of the client terminal 12 and the CPU 40 of the server 18 cooperate to provide the client 10 with a user interface. Similarly, the CPU 51 of the analyst terminal 16 and the CPU 40 of the server 18 cooperate to provide the analyst 14 with a user interface.

(Container registration process)
Next, the container registration process will be specifically explained.
As shown in FIG. 10, when the stockyard 20 requests the server 18 to register the container 30, the server 18 generates the private key and public key of the container 30, and the URL containing the hash value of the container public key is stored. Yard 20 is notified. The stockyard 20 converts the URL including the hash value of the container public key into a two-dimensional code, and stamps the two-dimensional code on the container 30 by laser processing.

-Server processing-
Here, the "container registration process" executed by the CPU 40 of the server 18 will be described in detail with reference to the flowchart shown in FIG. The "container registration process" is started when registration of the container 30 is requested. First, in step S100, the CPU 40 of the server 18 generates a pair of a container private key and a container public key. The container private key and the container public key can be generated by, for example, the Edwards-curve Digital Signature Algorithm (EdDSA).

Next, in step S102, the CPU 40 stores the container private key and the container public key in the container DB 48C. Each of the container private key and the container public key is converted into a string using the BASE64 method, and a hash value is calculated from the container public key string using a hash function such as SHA-256 (Secure Hash Algorithm 256-bit). do. The hash value of this container public key is used as the container ID.

As shown in Table 1 of FIG. 12, the container DB 48C stores the character string of the container public key, the character string of the container private key, and Stores each value of the container specifications. Alternatively, as shown in Table 2, using an arbitrary short name as a key, enter the character string of the container public key, the character string of the container private key, the hash value (footprint) of the container public key, and the values of the container specifications. It can also be used as a value.

For example, in Table 1, the hash value of the container public key (“12c70824abb1a7e441e04257…”), which is the key, includes the character string of the container public key (“Pubkey”: ”MCowBQYDK2VwAyEA2+h9+JCt…”), the container secret The key string (“Privkey”: “MC4CAQAwBQYDK2VwBCIEIK1k…”) and the container specifications (“Width”:100, “Height”:100, “Depth”:100) are each associated as a value. .

Next, in step S104, the CPU 40 notifies the stockyard 20 of, for example, a URL including the hash value (or its shortened URL) as a URL where the container public key can be viewed, and starts the "container registration process" routine. finish.

Note that the server 18 functions as a web server, and the client 10 and the analyst 14 can also view the container public key by reading the two-dimensional code stamped on the container 30. As shown, the public key related to the container 30 is disclosed to a third party, so it can be indicated that the public key belongs to the analyst 14 or the organization to which he or she belongs.

(Analysis request process)
Next, the analysis request process will be specifically explained.
As shown in FIG. 13, a token generator 11 that generates a time-based one-time password (hereinafter abbreviated as "OTP") is distributed in advance to the client terminal 12. ing. A unique ID unique to the token generator 11 and a salt character string are embedded in the token generator 11. The time of the internal timer of the token generator 11 is synchronized with the time of the server 18. The token generator 11 generates an OTP from the time, unique ID, and salt. Note that the password may be abbreviated as "PW" in some cases.

Further, the client 10 who is a user has an account for using the analysis service, and a user ID has been issued to the client 10 in advance. The server 18 manages account information such as user IDs in an account DB 48A. The unique ID of the token generator 11 distributed to the client 10 by the account DB 48A is also linked to the user ID.

- Processing of client terminal -
Here, the processing on the client terminal 12 side will be explained in more detail with reference to FIGS. 14 to 16. These processes are executed by the CPU 50 of the client terminal 12.

When the client 10 accesses the analysis service website (ie, server 18) and logs in using his or her user ID, the "client main process" shown in FIG. 14 is started. First, in step S200, the CPU 50 obtains a list of requested projects of the client 10 from the server 18.

Next, in step S202, the CPU 50 displays the client main screen 100 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. In the case of a new request, the requester 10 selects the new button 102 on the requester main screen 100. When the new button 102 is selected, the UI screen transitions to a new request screen 110. On the other hand, in the case of a requested case, the requester 10 selects the requested case from the selection column 104. When the target requested matter is selected, the UI screen transitions to a requested matter screen 130.

Returning to the explanation of FIG. 14. Next, in step S204, the CPU 50 determines whether or not it is a new case based on the input from the client 10. In the case of a new case, the process advances to "new request processing" in step S208. If it is not a new case, the process advances to step S206, and in step S206, the CPU 50 determines whether or not it is a requested case based on the input from the client 10. In the case of a requested matter, the process advances to "requested matter processing" in step S210. If it is not a requested matter, the process returns to step S200 and waits until the next loop.

Next, with reference to FIG. 15, the "new request processing" in step S208 of FIG. 14 will be explained. First, in step S212, the CPU 50 displays the new request screen 110 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. The requester 10 inputs the request contents (for example, text, photos, videos, etc. of the request contents) into the request contents input field 112 of the new request screen 110. When making a request with the input contents, the requester 10 selects the send button 114. When the send button 114 is selected, the UI screen transitions to an OTP input screen 120. On the other hand, in order to cancel the input contents, the requester 10 selects the cancel button 116. When the input contents are canceled, the UI screen returns to the client main screen 110.

Returning to the explanation of FIG. 15. Next, in step S214, the CPU 50 determines whether or not to send based on the input from the requester 10. In the case of transmission, the process advances to "OTP input processing" in step S218. If it is not a transmission, the process advances to step S216, and in step S216, the CPU 50 determines whether or not it is a cancellation based on the input from the requester 10. In the case of cancellation, the process advances to "requester main processing" in step S220. If it is not cancelled, the process returns to step S212 and waits until the next loop.

Next, with reference to FIG. 16, the "OTP input process" in step S218 in FIG. 15 will be described. First, in step S222, the CPU 50 displays the OTP input screen 120 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. The client 10 inputs the OTP generated by the token generator 11 into the PW input field 122 of the OTP input screen 120. If the entered content is OK, the requester 10 selects the send button 124. On the other hand, to cancel the input contents, the requester 10 selects the cancel button 126. In either case, the UI screen returns to the client main screen 110.

Returning to the explanation of FIG. 16. Next, in step S224, the CPU 50 determines whether or not to send based on the input from the requester 10. In the case of transmission, the process advances to step S230. If it is not a transmission, the process advances to step S226, and in step S226, the CPU 50 determines whether or not it is a cancellation based on the input from the requester 10. In the case of cancellation, the process advances to "requester main processing" in step S228. If it is not cancelled, the process returns to step S222 and waits until the next loop.

Next, in step S230, the CPU 50 transmits the user ID and OTP to the server 18. Note that although the user ID of the requester 10 has been sent to the server 18 at the time of login, the user ID may be sent to the server 18 again together with the OTP in step S230. When the server 18 receives the OTP from the client terminal 12, it transmits the common key parameter to the client terminal 12.

Next, in step S232, the CPU 50 determines whether there is a response from the server 18. If there is a response, the process advances to step S234; if there is no response, the process returns to step S222.

Next, in step S234, the CPU 50 receives the common key parameter from the server 18. In the following step S236, a temporary common key is generated. For example, the server 18 transmits an initialization vector (IV) held as a constant in advance to the client terminal 12 as a common key parameter. The CPU 50 of the client terminal 12 uses the Web browser to generate an AES common key of the common key encryption system (AES: Advanced Encryption Standard) from the OTP and the initialization vector. That is, in the first embodiment, an "AES common key" is used as the temporary common key.

Next, in step S238, the CPU 50 encrypts the analysis request using the temporary common key. In the following step S240, the CPU 50 transmits the ciphertext of the analysis request to the server 18. When the server 18 receives the ciphertext of the analysis request from the client terminal 12, it issues an analysis request ID and transmits it to the client terminal 12. Next, in step S242, the CPU 50 receives the analysis request ID from the server 18, stores the temporary common key in the storage unit 54, and returns to step S228.

-Server processing-
Here, the "analysis request reception process" executed by the CPU 40 of the server 18 will be described with reference to FIG. 17. The “analysis request reception process” is started when a new case from the client 10 is received. First, in step S110, the CPU 40 receives an OTP from the client 10. Next, in step S112, the CPU 40 transmits the common key parameter to the client 10. Next, in step S114, the CPU 40 enumerates OTPs that can be generated before and after the time, and detects the time difference of the token generator 11.

Next, in step S116, the ciphertext of the analysis request is received from the requester 10. Next, in step S118, the CPU 40 issues an analysis request ID and transmits it to the requester 10. Next, in step S120, the CPU 40 generates a work status record and sets the work status to "not started." Next, in step S122, the CPU 40 stores the unique ID, time difference, ciphertext of the analysis request, and work status record in the analysis request DB 48B in association with the analysis request ID, and performs the "analysis request reception process" routine. end.

(Analysis request acceptance process)
Next, the analysis request acceptance process will be specifically explained.
As shown in FIG. 13, the analyst 14 can access the website (ie, server 18) and query the analysis request DB 48B. The analyst 14 uses the unique ID and time difference stored in the analysis request DB 48B together with the ciphertext of the analysis request to generate a temporary common key each time. The analyst 14 decrypts and views the ciphertext of the analysis request using the temporary common key.

- Processing of analyst terminal -
Here, the processing on the analyst terminal 16 side will be explained in more detail with reference to FIGS. 18 and 19. These processes are executed by the CPU 51 of the analyst terminal 16.

When the analyst 14 queries the analysis request DB 48B, "analyst main processing" shown in FIG. 18 is started. First, in step S400, the CPU 51 obtains a list of all analysis requests from the server 18. Next, in step S402, the CPU 51 displays the analyst main screen 170 as an interface.

Here, the screen transition diagram in FIG. 9 will be referred to. The analyst 14 selects the analysis request to be accepted from among the analysis requests displayed in the all request list selection field 172. When the analyst 14 selects an analysis request to accept, the UI screen transitions to an analysis request screen 180.

Returning to the explanation of FIG. 18. Next, in step S404, the CPU 51 determines whether an analysis request has been selected. When an analysis request is selected, the process advances to step S406, ``analysis request processing.'' On the other hand, if no analysis request has been selected, the process returns to step S400 and waits until the next loop.

Next, with reference to FIG. 19, the "analysis process" in step S406 in FIG. 18 will be described. First, in step S408, the CPU 51 obtains the ciphertext of the selected analysis request from the server 18 based on the analysis request ID. Next, in step S410, the CPU 51 decrypts the ciphertext of the analysis request using the temporary common key corresponding to the analysis request ID.

Next, in step S412, the CPU 51 displays the analysis request screen 180 as an interface.

Here, the screen transition diagram in FIG. 9 will be referred to. In the request content display field 182 of the analysis request screen 180, the decoded analysis request (ie, request content) is displayed, and in the sample information display field 186, sample information corresponding to the analysis request is displayed. The analyst 14 selects the inclusion instruction input button 184 when inputting an inclusion instruction. When the inclusion instruction input button 184 is selected, the UI screen transitions to an inclusion instruction input screen 190.

The analyst 14 selects the analysis report input button 188 when inputting an analysis report. When the analysis report input button 188 is selected, the UI screen transitions to an analysis report input screen 200. The analyst 14 selects the inclusion instruction input button 184 when inputting an enclosure instruction. If completed, the analyst 14 selects the finish button 189 and the UI screen returns to the analyst main screen 170.

Returning to the explanation of FIG. 19. Next, in step S414, the CPU 51 determines based on the input from the analyst 14 whether or not an enclosing instruction has been input. In the case of inputting an enclosing instruction, the process proceeds to step S420, ``enclosing instruction input processing.'' If the input is not an enclosure instruction, the process advances to step S416, and in step S416, the CPU 51 determines whether the input is an analysis report based on the input from the analyst 14. In the case of inputting an analysis report, the process advances to step S422, ``analysis report input processing''. If it is not an analysis report input, the process advances to step S418, and in step S418, the CPU 51 determines whether or not the input is complete based on the input from the analyst 14. If completed, return to "Analyst Main Processing". If not completed, the process returns to step S408 and waits until the next loop.

(Enclosure instruction creation process)
Next, the inclusion instruction creation process will be explained.
As shown in FIG. 20, when the analyst 14 decides to start accepting the analysis request, the analyst 14 selects a container 30 with appropriate specifications from the container DB 48C to receive the sample based on the contents of the analysis request, and sends the selected container to the server 18. Order container 30. A plurality of containers 30 may be selected. Further, the analyst 14 creates an enclosure instruction, encrypts it with a temporary common key, and transmits the encrypted text of the enclosure instruction to the server 18 .

Furthermore, if the analysis request does not contain enough information necessary to select the container 30, the analyst 14 creates an inquiry text, encrypts it with a temporary common key, and sends it to the requester 10. , you may be prompted to update the analysis request.

The server 18 orders the container 30 selected by the analyst 14 from the stockyard 20. The stockyard 20 receives the order and delivers the container 30 to the client 10. The server 18 obtains the container private key and container public key of the selected container 30. The server 18 generates an electronic signature of the shared information including the encrypted text of the enclosing instruction using the container private key, and transmits the encrypted text of the enclosing instruction and the electronic signature to the client 10 .

- Processing of analyst terminal -
Here, the processing on the analyst terminal 16 side will be explained in more detail with reference to FIG. 21. These processes are executed by the CPU 51 of the analyst terminal 16.

As described above, when the inclusion instruction input 184 is selected on the analysis request screen 180 shown in FIG. 9, the "inclusion instruction input process" shown in FIG. 21 is started. First, in step S426, the CPU 51 initializes the container ID with an initial value (null). Next, in step S428, the CPU 51 obtains a list of available containers 30 from the server 18.

Next, in step S430, the CPU 51 displays the inclusion instruction input screen 190 as an interface.

Here, the screen transition diagram in FIG. 9 will be referred to. When the analyst 14 selects inclusion instruction input 184 on the analysis request screen 180, the UI screen transitions to an inclusion instruction input screen 190. A list of selectable containers 30 is displayed in the container list selection column 192 of the enclosure instruction input screen 190. The analyst 14 selects a container 30 and inputs an enclosing instruction into the enclosing instruction input field 194 in order to enclose a sample in the container 30. When the analyst 14 selects the send button 196, the enclosing instruction is sent to the server 18, and the UI screen returns to the analyst main screen 170. Furthermore, when the analyst 14 selects the cancel button 198, the input is canceled and the UI screen returns to the analyst main screen 170.

Returning to the explanation of FIG. 21. Next, in step S432, the CPU 51 determines whether the container 30 has been selected based on the input from the analyst 14. If a container is selected, the process advances to step S438, sets the container ID of the container 30 selected in step S438 as the container ID, and returns to step S430. On the other hand, if no container is selected, the process advances to step S434.

Next, in step S434, the CPU 51 determines whether or not to transmit based on the input from the analyst 14. In the case of transmission, the process advances to step S442. If it is not a transmission, the process advances to step S436, and in step S436, the CPU 51 determines whether to cancel based on the input from the analyst 14. In case of cancellation, return to "Analysis request processing". If it is not cancelled, the process returns to step S426 and waits until the next loop.

When the transmission of the enclosing instruction is instructed in step S434, next in step S442, the CPU 51 determines whether the container ID is an initial value. If the container ID is the initial value, no container 30 has been selected, and the process returns to step S430. If the container ID is not the initial value, the process advances to step S444. Next, in step S444, the CPU 51 encrypts the enclosing instruction using the temporary common key corresponding to the analysis request ID. In the subsequent step 446, the encrypted text of the enclosing instruction and the container ID are transmitted to the server 18, and the process returns to step S440.

-Server processing-
Here, the "signature generation process" executed by the CPU 40 of the server 18 will be described with reference to FIG. 22. The "signature generation process" is started when the analyst 14 selects an analysis request to be accepted. First, in step S124, the CPU 40 identifies the ID of the accepted analysis request. Next, in step S126, the CPU 40 updates the work status record of the accepted analysis request to "Start". Subsequently, in step S128, the CPU 40 records information on the analyst 14 and the work start time.

Next, in step S130, the CPU 40 instructs the stockyard 20 to deliver the container 30 selected by the analyst 14 to the client 10. Next, in step S132, the CPU 40 generates a container private key and a container public key for the container 30 selected by the analyst 14. Next, in step S134, the CPU 40 obtains the encrypted text of the inclusion instruction created by the analyst 14.

Next, in step S136, the CPU 40 generates an electronic signature for the shared information including the encrypted text of the enclosing instruction and the container public key. That is, a hash value of the shared information is calculated, and an electronic signature is generated using the container private key. In the following step S138, the CPU 40 transmits the encrypted text of the enclosing instruction and the electronic signature to the client 10, and ends the "signature generation process" routine.

(Sample sending process)
Next, the sample sending process will be explained.
As shown in FIG. 23, the client 10 uses the camera 62 to read the two-dimensional code stamped on the container 30 delivered from the stockyard 20, and obtains the container public key. Specifically, the URL containing the hash value of the container public key is read from the two-dimensional code, and the container public key can be viewed from the URL.

The client 10 verifies the electronic signature using the container public key, and verifies the authenticity of the encrypted text of the enclosing instruction. If this verification is not successful, the container, packaging instructions, and combination thereof are not what the analyst intended, and it is necessary to contact the service provider. If the verification is successful, the client 10 encloses the sample in a container 30 according to the enclosing instructions and sends it to the analyst 14. It is also possible to encrypt sample information regarding the enclosed sample using a temporary common key and send it to the analyst 14.

- Processing of client terminal -
Here, the processing on the client terminal 12 side will be explained in more detail with reference to FIGS. 24 to 27. These processes are executed by the CPU 50 of the client terminal 12.

When the client 10 selects a requested matter on the client main screen 100 in FIG. 8, "requested matter processing" shown in FIG. 24 is started. First, in step S250, the CPU 50 specifies the analysis request ID of the selected requested case and acquires the ciphertext and electronic signature of the analysis request from the server 18.

Next, in step S252, the CPU 50 decrypts the ciphertext of the analysis request created by the requester 10 himself using the temporary common key corresponding to the analysis request ID.

Next, in step S254, the CPU 50 displays the requested matter screen 130 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. When the client 10 selects a requested matter on the client main screen 100, the UI screen transitions to a requested matter screen 130. The request content display field 132 of the requested matter screen 130 displays an analysis request (that is, the request content), and the analysis report display field 138 displays an analysis report.

The requester 10 selects the inclusion instruction display button 134 to display the inclusion instruction. When the enclosure instruction display button 134 is selected, the UI screen changes to a container identifier reading screen 140. The client 10 selects the sample information input button 136 when inputting sample information. When the sample information input button 136 is selected, the UI screen changes to the sample information input button 136. If completed, the client 10 selects the completion button 139 and the UI screen returns to the client main screen 100.

Returning to the explanation of FIG. 24. Next, in step S256, the CPU 50 determines whether or not an enclosing instruction is displayed based on the input from the requester 10. If the enclosure instruction is displayed, the process advances to step S262, ``container identifier reading process.'' If it is not an enclosure instruction display, the process advances to step S258, and in step S258, the CPU 50 determines whether sample information is to be input based on the input from the requester 10. In the case of inputting sample information, the process advances to "sample information input processing" in step S264. If the input is not sample information, the process advances to step S260, and in step S260, the CPU 50 determines whether or not the input is complete based on the input from the requester 10. If completed, return to "requester main processing". If not completed, the process returns to step S250 and waits until the next loop.

Next, with reference to FIG. 25, the "container identifier reading process" in step S262 of FIG. 24 will be described. First, in step S270, the CPU 50 acquires a camera image. Next, in step S272, the CPU 50 acquires a character string from the two-dimensional code in the camera image. Next, in step S274, the CPU 50 determines whether the two-dimensional code represents the container public key. If the container public key is represented, the process advances to step S276; if the container public key is not represented, the process returns to step S270.

Next, in step S276, the CPU 50 determines whether or not to read based on the input from the requester 10. In the case of reading, the process advances to step S280, ``inclusion instruction display processing''. If it is not a reading, the process advances to step S278, and in step S278, the CPU 50 determines whether or not to cancel based on the input from the requester 10. In the case of cancellation, the process returns to "requested matter processing" in step S282, and in the case of non-cancellation, the process returns to step S270 and waits until the next loop.

Here, the screen transition diagram in FIG. 8 will be referred to. The client 10 photographs the two-dimensional code of the container 30 and causes the image of the camera 62 to be displayed in the camera image display column 142 of the container identifier reading screen 140. When the client 10 selects the read button 144, the two-dimensional code is read and the container public key is obtained, and the UI screen changes to an enclosure instruction display screen 150.

Next, with reference to FIG. 26, the "inclusion instruction display process" in step S280 of FIG. 25 will be described. First, in step S290, the CPU 50 verifies the electronic signature using the container public key and the ciphertext. Next, in step S292, the CPU 50 determines whether the verification has failed. If the verification is successful, the process advances to step S294. On the other hand, if the verification fails, the process returns to the requested matter processing in step S300.

Next, in step S294, the CPU 50 decrypts the ciphertext of the enclosing instruction using the temporary common key corresponding to the analysis request ID. Next, in step S296, the CPU 50 displays the inclusion instruction display screen 150 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. The enclosing instruction display column 152 of the enclosing instruction display screen 150 displays the plain text of the enclosing instruction that has been verified using the container public key and decrypted using the temporary common key. When the requester 10 selects the completion button, the requester main screen 100 returns.

Returning to the explanation of FIG. 26. Next, in step S298, the CPU 50 determines whether or not the process is completed. If completed, the process returns to "requested matter processing" in step S300; if not completed, the process returns to step S290 and waits until the next loop.

Next, with reference to FIG. 27, the "sample information input process" in step S264 in FIG. 24 will be described. First, in step S302, the CPU 50 displays the sample information input screen 160 as an interface.

Here, the screen transition diagram in FIG. 8 will be referred to. The client 10 inputs sample information into the input field 161 of the sample information input screen 160 as necessary. When the client 10 selects the send button 162, the sample information is encrypted and transmitted to the server 18, and the UI screen returns to the client main screen 100. Furthermore, when the client 10 selects the cancel button 164, the input is canceled and the UI screen returns to the client main screen 100.

Returning to the explanation of FIG. 27. Next, in step S304, the CPU 50 determines whether or not to send based on the input from the requester 10. In the case of transmission, the process advances to step S310. If not, the process advances to step S306, and in step S306, the CPU 50 determines whether or not to cancel based on the input from the requester 10. In the case of cancellation, the process advances to "requested matter processing" in step S308.

If sending the sample information is instructed in step S304, then in step S310 the CPU 50 encrypts the sample information with the temporary common key corresponding to the analysis request ID.In the subsequent step 312, the CPU 50 encrypts the sample information The encrypted text of the information is sent to the server 18, and the process returns to step S302 to wait until the next loop.

(Analysis report process)
Next, the analysis reporting process will be explained.
As shown in FIG. 28, the analyst 14 takes out a sample from the container 30 delivered by the client 10 and analyzes it. Further, when sample information is provided by the requester 10, it is decrypted using a temporary common key and viewed in the same way as when requesting analysis. In addition, the analyst 14, like the client 10, reads the two-dimensional code engraved on the container 30, and based on the container public key, confirms that the container 30 is the one ordered by the analyst along with the filling instructions. Good too.

Then, the analyst 14 creates an analysis report, encrypts it with the temporary common key, and sends it to the client 10. Here, the analysis report is an example of "other information" different from the information included in the enclosure instruction. At this time, similarly to the enclosing instruction, an electronic signature may be generated for the encrypted text of the analysis report using the container private key, and the electronic signature may be sent together with the encrypted text of the analysis report. The electronic signature allows the requester 10 to be provided with an analysis report linked to the container 30.

If the sample does not need to be returned, the container 30 is returned to the stockyard 20 and the sample is discarded when it is no longer needed before or after analysis. If it is necessary to return the sample, the container 30 containing the sample is returned to the client 10.

The client 10 decrypts the analysis report sent from the analyst 14 using the temporary common key and views it. Furthermore, if there is an electronic signature, it is verified using the same process as the enclosing instruction to confirm the authenticity of the combination of the container 30 and the analysis report. When the sample is returned, the sample is taken out from the container 30 and returned to the stockyard 20.

- Processing of analyst terminal -
Here, the processing on the analyst terminal 16 side will be explained in more detail with reference to FIG. 29. These processes are executed by the CPU 51 of the analyst terminal 16.

When the analysis report input button 188 is selected on the analysis request screen 180 of FIG. 9, the "analysis report input process" of FIG. 29 is started. First, in step S450, the CPU 51 displays the analysis report input screen 200 as an interface.

Here, the screen transition diagram in FIG. 9 will be referred to. When the analyst 14 selects the analysis report input button 188 on the analysis request screen 180, the UI screen transitions to an analysis report input screen 200. The analyst 14 inputs an analysis report into the analysis report input field 202 of the analysis report input screen 200. When the analyst 14 selects the send button 204, the analysis report is encrypted and sent to the server 18, and the UI screen returns to the analyst main screen 170. Furthermore, when the analyst 14 selects the cancel button 206, the input is canceled and the UI screen returns to the analyst main screen 170.

Returning to the explanation of FIG. 29. Next, in step S452, the CPU 51 determines whether or not to transmit based on the input from the analyst 14. In the case of transmission, the process advances to step S458. If it is not a transmission, the process advances to step S454. In the following step S454, the CPU 51 determines whether or not to cancel based on the input from the analyst 14. In the case of cancellation, the process advances to "analysis request processing" in step S456. If it is not cancelled, the process returns to step S450 and waits until the next loop.

On the other hand, if it is determined in step S452 that an analysis report is to be sent, then in step S458, the CPU 51 encrypts the analysis report with a temporary common key corresponding to the analysis request ID. In the following step 460, the CPU 51 transmits the ciphertext of the analysis report to the server 18, returns to step S450, and waits until the next loop.

-Server processing-
Here, the "analysis completion process" executed by the CPU 40 of the server 18 will be described with reference to FIG. The "analysis completion process" is started when the ciphertext of the analysis report is received from the analyst 14. First, in step S140, the CPU 40 optionally generates an electronic signature for the ciphertext of the analysis report using the container private key. Next, in step S142, the CPU 40 transmits the ciphertext of the analysis report to the client 10. If an electronic signature is generated, the ciphertext of the analysis report and the electronic signature are sent to the client 10. Next, in step S144, the CPU 40 updates the work status record to "completed" and ends the "analysis completion process" routine.

- Processing of client terminal -
As described with reference to FIG. 24, the "requested case processing" shown in FIG. 24 also corresponds to the case where an analysis report is delivered from the analyst 14. When the requester 10 views an analysis report, when he selects a requested matter on the client main screen 100 in FIG. 8, the "requested matter processing" shown in FIG. The plain text of the analysis report is displayed in the analysis report display column 138.

As explained above, in the first embodiment, only the packaging instructions that can be verified using the public key engraved on the container 30 can be presented to the client 10. Enclosing errors such as being enclosed in an unintended container 30 can be reduced.

Moreover, even if the wrong container 30 is delivered to the client 10, there is no verifiable charging instruction, and it is possible to reduce the possibility of a filling error in which the sample is sealed in the wrong container 30. In addition, since the packaging instructions are encrypted, it is difficult for a third party to eavesdrop on them, and even if a malicious third party attempts to change the container or falsify the return address, it will be detected through verification. I can do it.

Further, in the first embodiment, information exchanged between the client 10 and the analyst 14 is encrypted using a common key, and the client 10 and the analyst 14 have the common key necessary for decryption. Only those who know the contents can know the contents. Furthermore, the public key stamped on the container 30 can be read optically or electromagnetically, allowing for quick verification. Furthermore, since the public key is disclosed to a third party, it can be indicated that the public key belongs to the analyst 14 or the organization to which he or she belongs.

[Second embodiment]
The second embodiment introduces a temporary common key A that encrypts an analysis request and a temporary common key B that encrypts communications between the requester and the analyst after the enclosing instruction is issued.

Similar to the first embodiment, the temporary common key A may be an AES common key generated using a common key cryptosystem from the OTP generated by the token generator 11 and the initialization vector.

On the other hand, the temporary common key B is a common key generated using the Diffie-Hellman (DH) key exchange method or the elliptic curve Diffie-Hellman (ECDH) key exchange method. In the DH key exchange method and the ECDH key exchange method, of the pair of temporary private key and temporary public key temporarily generated between the client 10 and the analyst 14, only the temporary public key is sent to the other party. . The client 10 and the analyst 14 each generate a temporary common key from the other party's temporary public key and their own temporary private key/temporary public key pair.

FIG. 31 is a sequence diagram schematically showing the processing flow of the analysis service providing system. This sequence diagram differs from the sequence diagram shown in FIG. 6 in that steps S2 to S8 are omitted and steps S54 to S68 surrounded by dotted lines are inserted. Common steps will be given the same or similar reference numerals and their explanation will be omitted. Step S26 in FIG. 6 is divided into step S26A in which the analysis request is decrypted using the temporary common key A, and step S26B in which the enclosing instruction is created and encrypted using the temporary common key B in FIG. Steps S28A to S52A in FIG. 31 are similar to steps S28 to S52 in FIG. 6, except that temporary common key B is used.

Therefore, only the steps S54 to S68 for generating the temporary common key B will be explained. The server 18 transmits the temporary common key parameter to the analyst 14 (S54). The server 18 also transmits the temporary common key parameter to the client 10 (S56). The analyst 14 generates a pair of a temporary private key and a temporary public key using the temporary common key parameter (S58). The client 10 also generates a pair of a temporary private key and a temporary public key using the temporary common key parameter (S60).

The client 10 transmits the temporary public key to the analyst 14 (S62). The analyst 14 generates a temporary common key B from the analyst's own temporary private key and temporary public key and the temporary public key of the client 10 (S64). The analyst 14 also transmits the temporary public key to the client 10 (S66). The client 10 generates a temporary common key B from the client 10's own temporary private key and temporary public key and the analyst 14's temporary public key (S68). Temporary common key B is used for subsequent encryption.

In the first embodiment, the client 10, the analyst 14, and the server 18 hold the same temporary common key, but the server 18 (and its administrator) does not originally need to know the content of the analysis. Furthermore, if the temporary common key is leaked from the server 18, there is a risk that all the analysis contents will be intercepted. In the second embodiment, a temporary common key B is used when encrypting the communication between the requester and the analyst after the enclosing instruction. Since the temporary common key B is generated only between the client 10 and the analyst 14 without being known by a third party, the content of communication can be kept secret from third parties including the server 18.

[Third embodiment]
The analysis service providing system according to the third embodiment uses external equipment 24 (transportation vehicle, storage, analysis device, etc.) that is remote from the analyst 14. Here, in addition to the client 10 and the analyst 14, a third party such as a person in charge of transporting and storing containers may also access the operation and status display of the external device 24.

As shown in FIG. 32, in the third embodiment, the external device 24 is provided with an authentication system that manages the operation of the external device 24 and access to the status display. Furthermore, the external device 24 is provided with a mechanism that allows the camera 26 to read the two-dimensional code stamped on the container 30 and identify the container public key.

When the client 10, the analyst 14, or a third party (hereinafter referred to as "the client 10, etc.") attempts to access the operation or status display of the external device 24, login authentication to the server 18, etc. is required. After being authenticated by another authentication system, authentication by the external device 24 is further required.

For example, when the requester 10 etc. generates an appropriate random number and sends it to the server 18, the server 18 encrypts the random number with the container private key, generates an electronic signature, and sends the electronic signature to the requester 10 etc. Issue. Then, the client 10 or the like inputs the electronic signature together with the random number into the authentication system of the external device 24. The external device 24 can authenticate the client 10 or the like depending on whether the received random number and electronic signature can be verified with the container public key obtained from the container 30.

When using external devices 24, it may be necessary to limit access to each device for security reasons. As in the third embodiment, by providing an authentication system that manages the operation of the external device 24 and access to the status display, and a mechanism for acquiring the container public key, appropriate information (for example, a random number) and its Access authentication can be performed based on whether information can be verified with the container public key and an electronic signature generated using the container private key.

Note that the method by which the external device 24 obtains the public key is not limited to this form. For example, the container public key can be directly registered in the authentication system of the external device 24 in advance.

Furthermore, the public key used for authentication is not limited to the container public key. There are cases where it is desired to link the authentication system of the external device 24 not only to the container 30 but also to an individual as multi-factor authentication. In this case, an individual such as the client 10 may individually have a private key and a public key, and may register the individual's public key in the authentication system of the external device 24.

For example, if an individual's public key is converted into a two-dimensional code and printed on a name plate, the private key is stored in the smartphone, and the time on the external device 24 and the smartphone is determined by an NTP (Network Time Protocol) server on the Internet. Consider the case of synchronization. At this time, an electronic signature for the time can be generated using a private key stored in the smartphone and displayed as a two-dimensional code on the smartphone screen. Then, the external device 24 can acquire the public key by reading the public key from the name plate, reading the electronic signature from the screen of the smartphone, and reading the two-dimensional code with the camera 26. Thereby, the external device 24 can perform authentication based on whether the time can be verified.

As another form of multi-factor authentication, it is also possible to use the temporary public key and temporary private key generated by DH key exchange in the second embodiment. By adding a mechanism to print a two-dimensional code on paper after generating a temporary public key, and a mechanism to display a time electronic signature using a temporary private key as a two-dimensional code on a smartphone or PC screen, the external device 24 can Authentication can be performed by obtaining the time, digital signature, and temporary public key, and determining whether the time can be verified.

Although the third embodiment has been described as assuming that the external device 24 performs the authentication, the server 18 may perform the authentication via the external device 24.

[Modified example]
The configurations of the analytical service providing method, analytical service providing device, analytical service providing system, and program described in each of the above embodiments are merely examples, and may be modified without departing from the spirit of the present invention. Needless to say.

FIG. 33(A) is a schematic diagram showing a functional arrangement corresponding to a "one-to-one" analysis request, and in the above embodiment, FIG. 33(B) is a schematic diagram showing a functional arrangement corresponding to a "many-to-many" analysis request. FIG. In the above embodiment, the present invention was explained using a "many-to-many" analysis request in FIG. 33(B), but the present invention is also applicable to a "one-to-one" analysis request shown in FIG. 33(A). be. In this case, as is clear from a comparison of the two, the analyst 14 will perform the functions previously performed by the server 18 and the stockyard 20.

1 Analysis service providing system 10 Client 11 Token generator 12 Client terminal 14 Analyst 16 Analyst terminal 18 Server 20 Stockyard 22 Analysis center 24 External equipment 24A Analysis device 24B Storage 24C Transport vehicle 26 Cameras 30, 30A, 30B Container 48 Database (DB)
62, 63 Camera 100 Client main screen 110 Client main screen 110 New request screen 120 OTP input screen 130 Requested project screen 140 Container identifier reading screen 150 Enclosing instruction display screen 160 Sample information input screen 170 Analyst main screen 180 Analysis request Screen 190 Enclosing instruction input screen 200 Analysis report input screen 300 Container registration section 302 Request reception section 304 Signature generation section 306 Delivery request section 310 Interface provision section 312 Encryption/decryption section 314 Signature verification section 320 Interface provision section 322 Encryption/Decryption section Department

Claims (22)

An analysis service providing method in which a sample is sealed in a container and delivered,
associating a private key and a public key with the container;
a step of accepting an analysis request from a requester;
a step of electronically signing information regarding a sample to be sealed in the container in response to the analysis request using the private key associated with the container, and transmitting the information to the requester;
requesting a custodian of the container to deliver the container to which the public key associated with the container or its storage location is added to the requester;
How we provide analytical services, including: The analytical service providing method according to claim 1, wherein the public key associated with the container is irremovably attached to the container. 2. The analytical service providing method according to claim 1, wherein the public key associated with the container is added as an optically or electromagnetically readable identification mark. The analysis service providing method according to claim 3, wherein the identification mark is a one-dimensional code or a two-dimensional code. The analytical service providing method according to claim 1, wherein the container is delivered separately from the information. 2. The analysis service providing method according to claim 1, wherein the information is encrypted with a common key that can be held by the client. 7. The analysis service providing method according to claim 6, wherein the common key is generated from a one-time password using a token. 7. The analysis service providing method according to claim 6, wherein the common key is generated using a Diffie-Hellman (DH) key exchange method or an elliptic curve Diffie-Hellman (ECDH) key exchange method. further comprising the step of transmitting or receiving other information different from the information,
Generating a private key and a public key for communication, generating an electronic signature of the other information using the private key for communication, and verifying the electronic signature of the other information using the public key for communication. The analysis service providing method according to claim 1. If a common key is generated with the client using a key exchange method,
10. The analysis service providing method according to claim 9, wherein a temporary secret key and a temporary public key used to generate the common key are used as the communication private key and public key. The analysis service providing method according to claim 1, wherein the transmission and reception are performed via communication means. further comprising the step of causing an external device to process the container in which the sample is sealed,
2. The analysis service providing method according to claim 1, wherein the external device performs access authentication for the client, an analyst who analyzes the sample, or a third party. 13. The analytical service providing method according to claim 12, wherein the private key and public key associated with the container are used for the access authentication. 13. The analysis service providing method according to claim 12, wherein a temporary private key and a temporary public key used for generating a common key using a key exchange method are used for the access authentication. 13. The analysis service providing method according to claim 12, wherein the access authentication uses an authentication private key and a public key generated for the access authentication. The analysis service providing method according to claim 1, wherein the public key associated with the container is viewable. further comprising the step of obtaining and providing the public key from a storage location of the public key;
The analysis service providing method according to claim 1. An analysis service providing device that seals a sample in a container and delivers it,
a container registration unit that associates a private key and a public key with the container;
A request reception department that accepts analysis requests from requesters;
a signature generation unit that digitally signs information regarding a sample to be sealed in the container in response to the analysis request using the private key associated with the container and transmits the electronic signature to the requester;
a delivery requesting unit that requests a custodian of the container to deliver the container to which the public key related to the container or its storage location is added to the requester;
An analysis service providing device comprising: The analysis service providing device according to claim 18;
a client terminal equipped with a signature verification unit that verifies an electronic signature;
Equipped with
The signature verification unit verifies the received electronic signature using the public key related to the container read from the container and the information.
Analysis service provision system. The client terminal further includes an interface providing unit that provides a user interface,
displaying the information verified by the signature verification unit on the user interface;
The analysis service providing system according to claim 19. The client terminal further includes an encryption/decryption unit that encrypts or decrypts information,
If the information verified by the signature verification unit is encrypted, displaying the information decrypted by the encryption/decryption unit on the user interface;
The analysis service providing system according to claim 20. A program for analysis services that seals samples in containers and delivers them,
By computer,
associating a private key and a public key with the container;
a step of accepting an analysis request from a requester;
electronically signing information regarding the sample to be sealed in the container in response to the analysis request using the private key associated with the container, and transmitting the information to the requester;
requesting a custodian of the container to deliver the container to which the public key associated with the container or its storage location is added to the requester;
A program to run.