JP2019096112A - Request to execute processing with improved resistance to failures, and method, program, and system for responding to results of the same - Google Patents

Abstract

To issue a request to execute processing with an improved resistance to failures and make a response to results of the processing.SOLUTION: The present invention includes the steps in which: a first system sends a request to execute processing to a second system; the first system waits for a response to the request which shows the reception of the execution; and the first system sends a request for results of the processing from the second system.SELECTED DRAWING: Figure 4A

Description

  The present invention relates to a client server system. More particularly, the present invention relates to a client-server system that implements processing requests for execution and the resultant responses with improved fault tolerance.

  There is a client server type reservation system for a restaurant (for example, a restaurant) or the like.

  FIG. 6 is a diagram showing an overall process flow 600 of a reservation system according to the prior art. Reference numerals 610 and 620 denote clients and servers, respectively, which are connected via a network (not shown). The client 610 transmits, to the server 620, an execution request for processing related to reservation (for example, reservation (registration) for a certain restaurant or the like, reservation change and reservation cancellation). The server 620 actually executes the process relating to the reservation, and sends a response indicating the result of the process to the received request for the process execution.

  According to the reservation system as described above, when a failure caused by the network occurs and transmission of a request for execution of a process related to reservation or transmission of its response fails, the following problem occurs.

  The process related to the reservation actually executed in the server 620 is a process that takes a relatively long time to complete and fluctuates in time. Therefore, the client 610 basically keeps waiting for a response after transmitting the process execution request. However, if a response does not come back, the client 610 will continue to wait for a response semipermanently or for a predetermined timeout period (for example, 20 seconds), and therefore, processing of the client 610 may be delayed from request to response. Will lead to Such stagnation can secondarily cause failures at the client 610.

  Also, if no response is returned to the process execution request that has been sent, on the side of the client 610, whether execution of the process related to the reservation has succeeded or failed (for example, has the reservation registration succeeded or has failed)? Can not judge. Therefore, the client 610 can not take the next action (such as notification to the user who made the reservation).

  Furthermore, when transmission of an execution request for a process relating to a reservation or a response thereof fails, there is a problem that a recognition deviation is generated between the restaurant and the user and the user regarding the process relating to the reservation. For example, if the processing related to the reservation is successful (for example, the reservation registration has been successful) in the server 620 although no response is returned, the user who made the reservation can not know that. In a restaurant, etc., there is a situation where there is no visitor despite reservation being made. In addition, although the response is not returned, if the cancellation of the reservation in the server 620 is successful, the user who wants to cancel visits the restaurant etc. thinking that the response can not be canceled because the response is not returned. On the restaurant side, cancellation is possible.

  The present invention has been made in view of the above, and it is an object of the present invention to carry out a request for execution of processing with improved fault tolerance and a result response.

  According to a first aspect of the present invention, a first system transmits a process execution request to a second system, and the first system indicates a process execution acceptance for the process execution request. The method comprises the steps of: waiting for a response; and transmitting a request for processing result to the second system.

  In the method, the first system sets itself to repeatedly transmit the processing result request to the second system when the first system receives a response to the processing execution request indicating acceptance of the processing execution. It may further be included.

  The method may further include the step of the first system storing the identification information. At this time, it is preferable that the process execution request and the process result request include the stored identification information.

  In the second aspect of the present invention, the system returns a response indicating acceptance of the process execution without waiting for the completion of the process execution when the system receives the process execution request, and the system performs the process Attempting to obtain the result of the process in order to return the result of the process when the request for the result of the process is received.

  It is preferable that the process execution request and the process result request include identification information. At this time, the method may further include the step of the system storing the result of the process of receiving the execution request in association with the identification information included in the execution request. Also, attempting to obtain the result of the process may include attempting to obtain the result of the process that received the result request based on the identification information included in the result request.

  A third aspect of the present invention is a program that causes one or more computers to execute the above method as a whole.

  A fourth aspect of the present invention is a system for performing the above method.

  According to the embodiment of the present invention, it is possible to implement a process execution request and a response as a result with improved tolerance to a failure in a system as well as a failure caused by a network.

Configuration of exemplary reservation system 100 Flowchart of Exemplary Process 200 Performed by Client 110 Flowchart of Exemplary Process 250 Performed by Client 110 Flowchart of Exemplary Process 300 Performed by Server 120 Flowchart of Exemplary Process 330 Performed by Server 120 Flowchart of Exemplary Process 360 Performed by Server 120 A diagram depicting the overall exemplary process flow 400 of the reservation system 100 A diagram depicting a general illustrative process flow 420 of reservation system 100 A diagram depicting a general illustrative process flow 440 of the reservation system 100 A diagram depicting a general illustrative process flow 460 of the reservation system 100 Configuration of Example Computer 500 A diagram representing the overall process flow 600 of a prior art reservation system

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 1. One Embodiment of the Present Invention Hereinafter, one embodiment of the present invention will be described with reference to the drawings.

1-1 Reservation System According to an Embodiment FIG. 1 shows a configuration of an exemplary reservation system 100 according to an embodiment of the present invention.

  Reference numeral 110 denotes a system (sub system used by a user who makes a reservation for a restaurant etc .; hereinafter, since it functions as a client from the viewpoint of the flow of processing relating to reservation, it is called "client"). The client 110 is composed of one or more computers, describes information of a restaurant and the like, receives an instruction of reservation for a restaurant and the like from the user, and transmits the instruction of the reservation to the client 110 It also has a function as a web server that provides a web page for Please also refer to the section "2 computer" for "computer".

  115 is a computer that is at the user's hand, acquires a web page from the client 110 and displays it, receives an input of a reservation instruction from the user, and transmits the reservation instruction to the client 110 (hereinafter referred to as “user terminal "Is indicated. Although only one user terminal 115 is depicted in FIG. 1, there are actually a plurality of user terminals used by a plurality of users.

  Reference numeral 120 denotes a system (sub system for managing reservations of restaurants and the like; hereinafter, since it functions as a server from the viewpoint of the flow of processing relating to reservations, it is referred to as a "server"). The server 120 is composed of one or more computers, and also has a function as a web server for receiving a request for reservation processing of a restaurant or the like.

  Reference numeral 130 denotes a network composed of one or more networks (subnetworks). Network 130 may include one or both of a Local Area Network (LAN) and a Wide Area Network (WAN) such as the Internet. At least the client 110 and the server 120, and the client 110 and the user terminal 115 can communicate via the network 130.

1-2 Overview of Client 110 Hereinafter, an exemplary series of processes executed by the client 110 will be described with reference to FIGS. 2A and 2B. As described above, since the client 110 is configured of one or more computers, the series of processing is executed by the one or more computers as a whole. Although each step included in the series of processes is executed by any one of one or more computers constituting the client 110, the computer executed may be different for each step. A process to be executed by a computer described below (hereinafter, referred to as “exemplary process”) may cause a program to be executed by a computer, more specifically, by a processor of the computer. Also, such a program can be stored in a known computer readable storage medium, more specifically, for example, a non-transitory computer readable storage medium. Furthermore, some of the steps included in the example process can be omitted, the order of execution can be changed, and further steps can be added to the example process.

  FIG. 2A is a flowchart of an exemplary process 200 invoked when the client 110 receives a reservation indication from the user terminal 115. Examples of reservation instructions are reservation for a certain restaurant etc (registration of reservation), change of reservation and cancellation of reservation.

  Reference numeral 202 denotes a step of storing information (hereinafter referred to as “transaction ID”) for identifying a process execution request based on a reservation instruction received from the user terminal 115 for the subsequent steps. Although this storage may be temporary, it is preferable that at least the program related to the reservation system 100 in the client 110 is abnormally terminated and stored in such a manner that it can be acquired even after being restarted. . The transaction ID can be generated by the client 110 by any method.

  The step 204 indicates the step of transmitting the execution request of the process to the server 120 using the stored transaction ID. Specifically, the server 120 can have, as a web API, a URL for receiving a processing execution request for each type of processing, and accordingly, the server 120 can be a reservation registration API, a reservation change API, and a reservation. It can have an API for cancellation, etc. In addition, the execution request for a certain process includes information necessary for the process including the transaction ID in the URL corresponding to the process (information specifying the reservation content such as a restaurant to be reserved, information specifying the already-reserved, etc. ) Can be an HTTP request with the destination added as a parameter.

  206 shows the step of determining whether a response to the process execution request has been received. Specifically, the response to the process execution request can be an HTTP response to an HTTP request. If a response to the process execution request has been received, the process proceeds to step 214 described later, and if not, the process proceeds to step 208.

  Reference numeral 208 denotes a step of determining whether or not a first time has elapsed since the last execution request for processing. The first time is optional, for example, 2 seconds. If the first time has elapsed since the last request for processing execution, the process proceeds to step 210 described later, and otherwise returns to step 206.

  Step 210 shows the step of determining whether the first condition is met. The first condition is arbitrary, but in the present embodiment, the condition is that the transmission retry of the execution request of the process using the same transaction ID has already been made three times. If the first condition is satisfied, the process proceeds to step 212 described later, and if not, the process returns to step 204. As a result of step 210, a predetermined number of transmission retries of the process execution request can be realized.

  Reference numeral 212 denotes a step of performing a predetermined process. Having reached step 212 means that the response has not been returned although the transmission retry of the process execution request is repeated a predetermined number of times. Thus, the predetermined process may be the corresponding error process, but is not limited to the error process. As the error processing, specifically, it is considered to store an error log, issue an alert to a mobile phone held by a person in charge of maintenance of the reservation system 100, or notify the user terminal 115 that an error has occurred. Although it is not limited to these.

  Reference numeral 214 denotes the step of determining whether the response to the process execution request indicates that the process execution is accepted. The response may indicate failure to accept execution of the process. If the response to the process execution request indicates that the process execution is accepted, the process proceeds to step 216 described later, and if not, the process proceeds to step 220.

  Steps 206, 208, and 214 are an example of steps constituting a step of waiting for a response to a process execution request, which indicates the acceptance of the process execution as a whole.

  216 shows the step of notifying the user terminal 115 that the execution of the process is to be started. As a result of this step, it is possible to display on the user terminal 115 that the process is being executed.

  218 shows the steps of configuring the client 110 to send processing result requests to the server 120 at predetermined time intervals. Although predetermined time is arbitrary, it is 3 seconds, for example. As a result of this step, a process 250 to be described later is called at predetermined time intervals.

  Step 218 is an example of setting the client 110 to repeatedly transmit the processing result request to the server 120. The time between transmissions may vary.

  220 shows the step of performing a predetermined process. Having reached step 220 means that the process execution acceptance has failed. Thus, the predetermined processing in step 220 may be the corresponding error processing, but is not limited to error processing. Further, the predetermined process in step 220 may be the same process as the predetermined process in step 212, but may be a different process.

  FIG. 2B is a flowchart of an exemplary process 250 invoked at predetermined time intervals as a result of step 218. The process 250 may be called at another timing such as when the client 110 restarts after the program related to the reservation system 100 ends abnormally.

  252 shows the step of transmitting the processing result request to the server 120 using the transaction ID stored in step 202. Specifically, the server 120 can have a URL for receiving a request as a result of processing as a web API, and thus the server 120 can have an API for confirming a reservation result. Also, the processing result request can be an HTTP request with the corresponding URL added with necessary information including the transaction ID as a parameter as a destination.

  254 shows the step of determining whether a response to the processing result request has been received. Specifically, the response to the processing result request can be an HTTP response to an HTTP request. As a result of processing, if a response to the request has been received, the process proceeds to step 262 described later, and if not, the process proceeds to step 256.

  256 shows the step of determining whether a second time has elapsed since the last transmission of the processing result request. The second time is optional, for example, 2 seconds. As a result of processing, if the second time has elapsed since the last request was sent, the process proceeds to step 258 described later, and otherwise returns to step 254.

  Step 258 shows the step of determining whether the second condition is met. The second condition is arbitrary, but in the present embodiment, one minute has already passed since the corresponding transaction ID was generated. If the second condition is satisfied, the process proceeds to step 260 described later, and if not, the process 250 ends.

  Note that, as a result of step 258 and steps 266 and 270 described later, transmission retry of the request at a predetermined time interval can be realized as a result of the processing until the predetermined time elapses.

  260 shows the step of performing a predetermined process. The fact that step 260 has been reached means that the response has not been returned despite repeated processing of transmission of the request as a result of processing. Thus, the predetermined processing in step 260 may be the corresponding error processing, but is not limited to error processing. Further, the predetermined process in step 260 may be the same process as the predetermined process in step 212, but may be a different process.

  262 shows the step of determining whether the response to the processing result request indicates the processing result. The response may not indicate the result of the process, but may indicate that the process is being performed. Processing Result If the response to the request indicates the processing result, the process proceeds to step 264 described later, otherwise proceeds to step 266.

  H.264 shows steps for performing processing according to the processing result. Although the example of the process according to a process result is notifying a user terminal 115 of a process result, it is not necessarily limited to this.

  266 shows the step of determining whether the third condition is met. Although the third condition is optional, it is the same as the second condition in the present embodiment. If the third condition is satisfied, the process proceeds to step 268 described later, and if not, the process 250 ends.

  268 indicates steps for performing predetermined processing. The fact that step 268 has been reached indicates that there is a possibility that the response indicating the processing result has not been returned, that is, the execution of the processing has failed, although the transmission retry of the request of the processing is repeated for a certain period of time. means. Thus, the predetermined processing at step 268 may be the corresponding error processing, but is not limited to error processing. Further, the predetermined process in step 268 may be the same process as the predetermined process in step 212, but may be a different process.

  A step 270 shows the step of canceling the transmission setting of the request as a result of the processing at the predetermined interval made in the step 218. As a result of this step, process 250 will no longer be called at predetermined intervals.

1-3 Overview of Server 120 Hereinafter, an exemplary series of processes executed by the server 120 will be described with reference to FIGS. 3A to 3C. As described above, since the server 120 is configured by one or more computers, the series of processing is executed by the one or more computers as a whole. It should be noted that although each step included in the series of processes is executed by any one of one or more computers configuring the server 120, the computer executed by each step may be different. .

  FIG. 3A is a flowchart of an exemplary process 300 performed by server 120.

  Reference numeral 302 denotes a step of determining whether a process execution request has been received. If a process execution request has been received, the process is repeated at step 304 described later, otherwise step 302 is repeated.

  Reference numeral 304 denotes a step of attempting temporary storage of the transaction ID included in the received processing execution request. Specifically, the transaction ID can be stored in a storage (cache) for temporarily storing volatile information. Further, in this step, other information such as the reception date and time of the process execution request may be stored.

  306 illustrates the step of determining if the attempt in step 304 is successful. If any error occurs, it will be determined that the trial is not successful. If the attempt is successful, the process proceeds to step 308 described later, otherwise proceeds to step 310.

  Reference numerals 308 and 310 respectively denote a step of generating a response indicating acceptance of processing execution and a step of generating a response indicating failure of acceptance of processing execution as a response to the received request for processing execution.

  312 shows the step of actually starting the execution of the process. Note that, in the present embodiment, an instance that receives an execution request for processing in the server 120 and an instance that actually executes the processing are different, and step 312 is the processing from the former instance to the latter instance. Sending an execution request (not shown). Here, an example of one instance is one physical computer, one virtual machine running on a physical computer or virtual machine, and one virtual machine running on a physical computer or virtual machine It is a process. The former instance and the latter instance may be identical.

  314 shows the step of returning a response to the received request for processing execution. Note that step 314 may be performed asynchronously with step 312. That is, step 314 can be performed without waiting for the completion of the process whose execution has been started.

  FIG. 3B is a flowchart of an exemplary process 330 invoked as a result of performing step 312.

  332 shows the step of setting the server 120 so that the transaction ID temporarily stored in step 304 is automatically deleted after a predetermined time has elapsed. Although this predetermined time is arbitrary, it is 120 seconds, for example.

  334 shows the step of actually executing the process.

  336 shows the step of storing the result of processing in association with the corresponding transaction ID. It should be noted that if an error occurs in step 334 and the process is not completed, ie, the result of the process is not obtained, step 336 is not executed and therefore the result of the process is not stored.

  338 shows the step of deleting the transaction ID temporarily stored in step 304. This step is independent of the automatic deletion of the transaction ID set in step 332. That is, in this embodiment, the transaction ID temporarily stored is deleted when a predetermined time has elapsed or the processing is completed.

  FIG. 3C is a flowchart of an exemplary process 360 performed by server 120.

  362 shows the step of determining whether the processing result request has been received. If a process result request has been received, the process is repeated at step 364 described later, and otherwise step 362 is repeated.

  364 indicates a step of attempting to acquire the stored processing result based on the transaction ID included in the received processing result request.

  366 shows the step of determining if the attempt in step 364 is successful. If the process receiving the execution request has not been executed, this attempt will fail. In the present embodiment, since the temporary storage of the transaction ID is deleted when the execution of the process is completed, the step 366 determines whether the transaction ID is temporarily stored (see FIG. Not shown). If the attempt is successful, the process proceeds to step 368 described later, otherwise proceeds to step 370.

  Reference numerals 368 and 370 respectively indicate steps of generating a response indicating the result of the process and generating a response indicating that the process is being executed as a response to the request of the result of the received process.

  372 shows the step of storing the result of processing in association with the transaction ID. As a result of this step, based on the transaction ID, the server 120 determines, based on the transaction ID, whether or not the acquisition of the result of the process is stored, and if it is stored, the result of the process is transmitted to the client 110 and thus the user It will be possible to recognize that the terminal 115 will be notified, and if it is not stored, the user terminal 115 will not be notified yet.

  374 shows the step of returning a response to the received request for processing result.

1-4 Overall Process Flow of Reservation System 100 The following is a description of the overall example process flow of reservation system 100 under various circumstances, with reference to FIGS. 4A-D. In these figures, the user terminal 115 and the network 130 are omitted.

  FIG. 4A is a diagram illustrating the overall exemplary process flow 400 of the reservation system 100 when a series of processes are performed without the occurrence of a particular failure.

  401 indicates that the user terminal 115 has transmitted a reservation instruction to the client 110.

  Reference numeral 402 indicates that the client 110 has sent the server 120 an execution request for processing relating to reservation.

  403 indicates that, in order to actually start the execution of the process in the server 120, the instance for receiving the process execution request has sent the process execution request to the instance for actually performing the process execution.

  404 indicates that the server 120 has returned a response indicating acceptance of execution of the process.

  405 indicates that the client 110 has notified the user terminal of the start of processing execution.

  Reference numeral 406 denotes that the process for which the execution request has been received in the server 120 is completed.

  Numeral 407 indicates that the client 110 has sent a request as a result of processing to the server 120. In this figure, since the occurrence of 407 is after the occurrence of 406, in process 360, the server 120 can obtain the processing result.

  Reference numeral 408 indicates that the server 120 has sent back a response indicating the processing result.

  Reference numeral 409 denotes that the client 110 has notified the user terminal 115 of the processing result as processing according to the processing result.

  As described above, according to the reservation system 100, it is possible to perform the process related to the reservation based on the instruction according to the instruction of the reservation from the user terminal 115 and to notify the user terminal 115 of the processing result. Further, according to the reservation system 100, the client 110 can wait for a response indicating that the process execution is accepted in response to the process execution request, so that the waiting time-out time can be made small. Even if a response is not received, the retention of the processing from the request for execution of the processing related to the reservation to the response becomes short.

  FIG. 4B is a diagram illustrating the overall exemplary process flow 420 of the reservation system 100 when a failure due to the network 130 occurs.

  421 shows the same thing as 401.

  422 indicates that the client 110 has sent a process execution request but did not reach the server 120.

  Reference numeral 423 denotes that the process execution request has been transmitted from the client 110 to the server 120 again.

  424-427 show the same thing as 403-406, respectively.

  428 indicates that the client 110 has sent a request as a result of processing but did not reach the server 120.

  429 indicates that the request has been sent again from the client 110 to the server 120 as a result of the process.

  430 and 431 indicate the same as 408 and 409, respectively.

  As described above, according to the reservation system 100, even if communication via the network 130 is unstable, the possibility that the series of processes related to the reservation may be interrupted is reduced. In particular, according to the reservation system 100, since the request for processing can be transmitted a plurality of times, when the processing for receiving the execution request in the server 120 is completed, the fact can not be acquired by the client 110, and thus the user It is less likely that the user of the terminal 115 can not be notified of the success or failure of the reservation. This means that, for example, the probability of occurrence of an accident that there is no visitor even though reservations are made in a restaurant or the like is reduced.

  FIG. 4C is a diagram representing the overall exemplary process flow 440 of the reservation system 100 when a failure occurs at the client 110.

  441-446 have shown the same thing as 401-406.

  447 indicates that the abnormal termination of the program related to the reservation system 100 has occurred at the client 110.

  448 indicates that, after the program is restarted, a request for processing result is transmitted from the client 110 to the server 120 using the stored identification information.

  449 and 450 indicate the same as 408 and 409, respectively.

  As described above, according to the reservation system 100, even if a temporary failure occurs in the client 110, the request result of the process of transmitting the execution request before the failure occurrence is transmitted using the identification information stored before the failure occurrence. As a result, it is less likely that the user of the user terminal 115 can not be notified of the success or failure of the reservation.

  FIG. 4D is a diagram illustrating a general example process flow 460 of the reservation system 100 when it takes time to execute the process of receiving the execution request in the server 120.

  461 to 467 indicate the same as 401 to 407, respectively. However, in this figure, since the occurrence of 467 precedes the occurrence of 466, the server 120 can not acquire the processing result when the request as a result of the processing indicated by 467 is received.

  468 indicates that the server 120 returned a response indicating that the process is being executed because the server 120 could not obtain the process result.

  469 indicates that the request has been sent again from the client 110 to the server 120 as a result of the process. In this figure, since the occurrence of 469 is later than the occurrence of 466, the server 120 can obtain the processing result when the request as a result of the processing indicated by 469 is received.

  Reference numeral 470 denotes that the server 120 has sent back a response indicating the processing result in response to the processing result request sent again.

  471 shows the same thing as 409.

  As described above, according to the reservation system 100, even if it takes time to execute the process for which the server 120 receives the execution request, the response to the execution request is made without waiting for the completion of the execution. The processing time from request for execution of processing related to reservation to response at 110 becomes shorter.

2 Computer FIG. 5 shows an example of a hardware configuration of a computer. As shown, the computer 500 mainly includes a processor 510, a main storage 520, an auxiliary storage 530, a user interface 540, and a communication interface 550, which include an address bus, They are mutually connected via a bus line 560 including a data bus, a control bus and the like. An interface circuit (not shown) may be appropriately interposed between the bus line 560 and each hardware resource.

  The processor 510 controls the entire computer. The processor 510 may be configured by a plurality of processors each performing control of part or all of a computer.

  The main storage device 520 provides a work area to the processor 510, and is a volatile memory such as SRAM or DRAM.

  The auxiliary storage device 530 is a non-volatile memory, such as a hard disk drive or a flash memory, which stores software programs (including computer executable instructions) and various data. The program is loaded from the auxiliary storage unit 530 to the main storage unit 520 via the bus line 560 at any time to cause the processor 510 to execute various processing, methods or steps.

  It should be noted that the main storage device 520 and the auxiliary storage device 530 may be collectively referred to as "memory" without distinguishing between the two.

  The user interface 540 is a user interface as a hardware resource that presents information to the user and / or receives input of information from the user, for example, a keyboard, a mouse, a track pad, and a track. It is a pointer, a display, a touch panel display, a microphone, a speaker, an acceleration sensor, and the like.

  The communication interface 550 is connected to the network 130, and sends and receives data via the network 130. The communication interface 550 and the network 130 can be connected by wire or wirelessly. The communication interface 550 may also acquire information related to a network, for example, information related to an access point of Wifi, information related to a base station of a communication carrier, and the like.

3 Conclusion Although the embodiments of the present invention have been described, it should be noted that other similar forms may be adopted, and forms may be modified or added as appropriate.

Claims (7)

The first system transmitting to the second system an execution request for processing;
Waiting for a response to a request for execution of the process, the first system indicating acceptance of execution of the process;
Sending the request resulting from the process to the second system. The method according to claim 1, wherein
Setting the self system to repeatedly transmit the result request of the process to the second system when the first system receives a response to the process execution request indicating acceptance of the process execution; A method further comprising The method according to claim 1 or 2, wherein
The method further includes the step of the first system storing identification information, wherein the processing execution request and the processing result request include the stored identification information. A step of returning a response indicating acceptance of the execution of the process without waiting for the completion of the execution of the process when the system receives the process execution request;
Attempting to obtain the result of the process in order to return the result of the process if the system receives a request for the result of the process. 5. The method according to claim 4, wherein the processing execution request and the processing result request include identification information;
The system further includes the step of storing the result of the process having received the execution request in association with the identification information included in the execution request, and the step of attempting to acquire the result of the process is:
Attempting to obtain a result of the process that received the result request based on the identification information included in the result request.   A program that causes one or more computers to execute the method according to any one of claims 1 to 5 as a whole.   A system for performing the method according to any one of claims 1 to 5.

Images