JP4257139B2 - Information processing method and processing program - Google Patents

Description

[0001]
[Technical field to which the invention belongs]
The present invention relates to a session management technique in a web system.
[0002]
[Prior art]
The HTTP protocol is a connectionless communication technique that does not maintain a state and that does not require securing or opening a communication path. For this reason, a series of requests and responses related to product purchases, such as an order entry screen, an order specification and an order confirmation screen in response to this, and a registration confirmation screen in response to confirmation input, are sent from the same client. It is known to use “Http Session” (session key) in order to determine whether the client is a client and to grasp the state of the client.
[0003]
In this method, the server side holds client-specific information (session key), and returns a response with a client-specific session key attached to a request from the client. By adding the session key to a client request, the server can determine from which client the request is made.
[0004]
For example, in Patent Document 1, however, various problems may occur because it is stateless and connectionless. For example, Patent Document 1 proposes a technique for managing session time and determining whether a screen transition is within a predetermined time in order to prevent impersonation of another person even when the terminal is separated from a terminal for a long period of time. Has been.
[0005]
[Patent Document 1]
JP 2002-229941 A
[0006]
[Problems to be solved by the invention]
In addition to the above-mentioned impersonation of others, the following problem may occur in the method using the session key.
For example, multiple browsers with the same session key can be created by the user opening a new window. In this case, there is a problem in that it cannot be determined from which browser screen the request is made and an appropriate response cannot be made.
[0007]
There is also a problem of double registration in the registration process. For example, double-clicking the confirmation button on the input content confirmation screen causes confirmation to be registered twice. In addition, after turning on the confirmation button, there is a possibility that the screen can be restored with the return button and the confirmation button can be turned on again. For example, in the case of confirmation of product purchase, the server may determine that the product has been purchased twice.
Conventionally, the following methods have been put into practical use as countermeasures for the above problems.
[0008]
(1) When the input button is turned on from the client, the server holds confirmation information. When the next button (for example, the registration button) is sent from the client, the registration process is executed. Delete the confirmation information. Thereby, the problem of double registration can be solved.
[0009]
(2) In order to change the screen, issue a token (Token) and return it to the client. The server executes processing in response to only the request with the latest token. This is almost the same as changing the session key for each screen transition.
[0010]
However, in the method (1), when a plurality of browsers are open in the same session, the data displayed on the client machine may be different from the data to be processed. For example, order a product on one screen, call a screen to confirm the input contents, then order another product on the other screen (the screen itself is the same as the above one screen) and confirm the input content Consider the state of calling the screen. Here, when the user turns on the registration button on the screen for confirming the contents of one (ordered earlier), the server may determine that the registration button from the other screen is on. That is, while the user is trying to purchase the product A, the product B that was going to be purchased on the other screen is registered.
In addition, even if the “Return” button is specified on the screen (change screen) for changing user information or the like, this is invalidated. For example, the same problem may occur in the display of the search result list.
[0011]
In the method (2), the “return” button of the browser cannot be used. When the “Return” button is pressed, subsequent operations are invalidated. Also, if multiple browsers are open in the same session and you turn off one of the screens, you will have to start again from login. In other words, if the screen with the current token disappears, there is a problem that the operation cannot be continued. In addition, if you double-click the registration button, an error will be displayed.
[0012]
The present invention responds to a user's request without any contradiction even when double-clicking or opening multiple screens when the information on the screen referred to by the user matches the information to be processed. It aims at providing the system which can do.
[0013]
[Means for Solving the Problems]
An object of the present invention is an information processing method for executing predetermined processing in response to a request from a client machine and returning the processing result as a response to the client machine. A step of generating a session object that holds a session ID relating to a series of requests and responses, and data for uniquely identifying the response data in the session object in order to respond to the request from the client machine Generating the ID, transmitting the response data and the data ID to the client machine, temporarily storing the data ID in a storage unit, and in the client machine, from the response data Different request A data ID associated with the response data is transmitted to the server, and the server collates the received data ID with the data ID temporarily stored in the storage means, and can appropriately collate In this case, in the session object, a step of generating response data in response to the request, a step of generating a new data ID for uniquely specifying the processed response data, and data once used for verification This is achieved by an information processing method comprising the step of not using the ID for collation in response to a request after the collation.
[0014]
According to the present invention, the data ID related to the response data created in response to the preceding request is stored in the storage unit of the server and transmitted to the client. The transmitted data ID is returned to the server together with other requests based on the response data from the client. The data ID returned to the server is collated with the data ID stored in the storage means. If the same data ID returned from the client to the server exists in the storage means, the processing is continued assuming that the data ID has been properly verified. The data ID once used for verification is not used for subsequent verification. Thereby, double registration can be prevented.
[0015]
The data ID is related to response data for a certain request. Therefore, when the client returns to the screen corresponding to the response data after the browser return button is pressed, the data ID associated with the response data is added to the request from the returned screen. Therefore, the server can process appropriately.
[0016]
That is, in the present invention, apart from the session ID for conventional session management, data ID is assigned and managed for each data held by the object. For this reason, the data ID can be assigned by paying attention only to the data change of the object without depending on the screen transition state or the HTTP request from the client machine. Accordingly, even when the screen is returned again after the double registration is prevented or the browser return button is pressed, appropriate processing in the server can be realized.
[0017]
The data ID is preferably generated randomly and uniquely so that it is difficult to guess.
[0018]
In a preferred embodiment, the step of preventing the data ID from being used for collation includes a step of erasing the temporarily stored data ID. In this embodiment, there may be provided a step of transmitting an error message to the client machine in response to the request when the verification cannot be properly performed.
[0019]
In another preferred embodiment, the step of not using for the collation moves the temporarily stored data ID and stores it in another area of the storage means as a confirmed data ID by the collation. Having steps. More preferably, the received data ID and the data ID temporarily stored in the storage means are collated, and when the collation cannot be properly performed, the received data ID and the confirmed data If there is a step of secondarily collating with the ID, and if the second collation can be properly performed, the request is ignored. On the other hand, if the second collation is not properly performed, , Sending an error message to the client in response to the request.
[0020]
Another object of the present invention is an information processing program for operating a computer to execute a predetermined process in response to a request from a client machine and to return the processing result as a response to the client machine. Generating a session object that holds a session ID related to a series of requests and responses from the client machine, and for responding to the request from the client machine, the response data and the response data are uniquely specified in the session object. Generating a data ID to be specified, transmitting the response data and the data ID to the client machine, temporarily storing the data ID in a storage unit, and transmitting the data ID in the client machine Is , Receiving different data IDs related to the response data and the data ID related to the response data, matching the received data ID with the data ID temporarily stored in the storage means, and appropriately matching If it is possible, in the session object, a step of generating response data in response to the request, a step of generating a new data ID for uniquely specifying the processed response data, and once used for verification This is achieved by a program that causes the computer to execute the step of not using the data ID for collation in response to a request after the collation.
[0021]
In a preferred embodiment, in the step of not using the data for verification, the computer is caused to execute the step of erasing the temporarily stored data ID. Here, when the verification is not properly performed, a step of transmitting an error message to the client machine in response to the request may be executed by the computer.
[0022]
In another preferred embodiment, in the step of not using for collation, the temporarily stored data ID is moved and stored in another area of the storage means as a confirmed data ID by collation Is executed by the computer. Further, the received data ID and the data ID temporarily stored in the storage means are collated, and when the collation cannot be properly performed, the received data ID and the confirmed data ID are If the computer executes the next verification step and the secondary verification is properly performed, the request is ignored, while the secondary verification is not properly performed. Preferably, the computer executes the step of sending an error message to the client in response to the request.
[0023]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. FIG. 1 is a block diagram showing an outline of a system including a server according to the first embodiment of the present invention. In FIG. 1, client machines 14-1, 14-2,... And a server 16 are connected to the Internet 12. The server 16 can provide predetermined contents (for example, images) in response to various requests from the client machine 14. Needless to say, the present invention is not limited to a form in which the client machine 14 can be connected to the server 16 via the Internet 12, and it goes without saying that the present invention can be applied to a machine connected via an arbitrary network such as a LAN or WAN. In addition, the server 16 is provided with a data storage unit 18 for temporarily storing a data ID used when data is exchanged from the client machine 14.
[0024]
FIG. 2 is a diagram showing an outline of processing by the server 16 using the technique according to the present embodiment. Here, a state in which a command is transmitted from the client machine 14 to the server 16 by data exchange between the client machine 14 and the server 16 and the screen is changed in the client machine 14 is shown.
[0025]
In FIG. 2, registration contents indicating that the order contents are registered from the order input screen 201 for specifying the goods and ordering the specified goods through the order content confirmation screen 202 for confirming the order contents in the product purchase site. Transition to the confirmation screen 203 is made. When the servlet object 20 starts a session with the client machine 14, the server 16 generates a session object 22 (for example, session ID (SID) = YYZZX), and when the session object 22 changes data, A data ID is assigned, and a unique data ID is transmitted to the client machine 14 together with the data. The data ID is randomly and uniquely assigned so that estimation is impossible or difficult.
[0026]
When the user refers to the order input screen on the display device of the client machine 14 and selects a certain product, this is transmitted to the server 16 (see arrow 211). As a result of processing by the server 16, necessary data is obtained. An input content confirmation screen 202 is displayed on the display device of the client machine 14 given to the client machine 14 (see arrow 212). Next, when a button or the like indicating content confirmation is designated by the operation of the input device by the user, this is transmitted to the server 16 (see arrow 213). By repeating the data exchange (see arrows 213 and 214), the server 16 registers the product purchased by the user.
[0027]
FIG. 3 is a flowchart showing an example of processing executed by the client machine 14 and the server 16 according to the present embodiment. Here, the processing executed for the screen transition shown in FIG. 2 is shown. Upon access from the client machine 14 (step 301), in the server 16, the object 20 generates a session object 22 for a session with the client machine 14 (step 302). The session object 22 issues a session ID so that the client machine 14 can be identified. This is held until the session with the client machine 14 ends.
[0028]
It is considered that an order input screen is displayed on the display device of the client machine 14 by data exchange between the client machine 14 and the server 16. On the order input screen, for example, a plurality of product names are listed, and the product is specified by clicking a button associated with one of the listed product names.
[0029]
Here, when a user designates a certain product and turns on a button associated with the product, data indicating that the order input button is turned on and predetermined other data (data ID) are input to the server. It is transmitted to 16 objects 20 (step 303). Actually, the data ID and the parameter corresponding to the designated product number are added to the method call (request) called “list selection” of the object from the client machine, and given to the server 16. This data ID will be described in detail after step 311.
[0030]
The object 20 of the server 16 transmits the request to the session object 22 after necessary processing (also described in detail with reference to step 311 and subsequent steps) (step 304). The session object 22 generates order data for generating the input content confirmation screen and a data ID that is unique to the request in step 304 and returns it to the object 20 (step 311). Accordingly, the order data is transmitted to the client machine 14 together with the data ID (confirmation ID) as confirmation data for requesting confirmation from the user (step 312). This data ID is stored in the data storage unit 18 in association with the order data (step 313).
[0031]
When the confirmation button is turned on by the user operating the input device with reference to the input content confirmation screen on the display device of the client machine 14, a request “confirmation request” is transmitted in step 312. The data ID is added and transmitted to the server 16 (step 314). The server 18 collates the received data ID with the data ID stored in the data storage unit 18 in association with the order data (step 315). If they match, the data ID in the data storage unit 18 is deleted (step 316), and a registration request is transmitted to the session object 22 (step 317).
[0032]
The session object 22 returns registration data for generating a registration confirmation screen and a data ID that is unique to the request in Step 317 to the object 20 (Step 318). Therefore, the registration data is transmitted to the client machine 14 together with the data ID as confirmation data for requesting confirmation from the user (step 319). That is, the response data and a new data ID that uniquely identifies the response data are given to the client machine 14. Although not shown in FIG. 3, the data ID of this registration data is also stored in the data storage unit 18 and is used for collation when accessed from the next client machine 14.
[0033]
Here, it is assumed that the confirmation button is turned on twice in a state where a screen based on the order data (input content confirmation screen) is displayed on the client machine. For example, a case where a single-click operation of a mouse is sufficient for a double-click operation corresponds to this. As shown in FIG. 4, at this time, when the first confirmation button is turned on, the registration request and the data ID given together with the previous order data are transmitted to the object 20. This is the same as step 314 in FIG. Accordingly, the object 20 refers to the data storage unit 18 and collates the data ID (step 315), and erases the data after the collation (step 316). Since the collation of the data ID has been completed successfully (that is, the data ID exists), the registration request is transmitted to the session object (see step 317 in FIG. 3).
[0034]
On the other hand, when a registration request and a data ID are given to the object 20 by turning on the second confirmation button (step 401), the corresponding data ID in the data storage unit 18 has already been deleted. The verification fails (step 402). Therefore, the request based on the second confirmation button being turned on is ignored thereafter (see step 403). Alternatively, in response to the request in step 401, the object 20 transmits an image including an error message (error message image).
[0035]
As described above, according to the present embodiment, in response to a request (request) of the client machine 14, the data (confirmation data) and the data ID responding to the request are returned to the client machine 14, The data ID associated with the confirmation data is assigned to the next request related to the responding data and transmitted. The server 16 can specify a request from the user by holding this data ID.
[0036]
Further, by deleting the data ID after the collation, even if the same request and data ID are transmitted to the server 16 by double clicking, the request can be ignored. This makes it possible to prevent double registration by double-clicking, multiple screen display, and the like.
[0037]
Also, according to the present embodiment, it is possible to hold a plurality of data (screens) in the same session and execute appropriate processing for each. FIG. 5 is a diagram illustrating an example of such a screen transition. In FIG. 5, the user transitions the screen in the order of the order input screen 501, the input content confirmation screen 502, and the registration content confirmation screen 503 by inputting a request (see reference numerals 521 to 524) at the product purchase site. . This corresponds to the screens 201 to 203 in FIG. On the other hand, for example, by opening a new window, another order input screen 511 is displayed, a request is input from the order input screen (see reference numeral 531), and the request and response are repeated (see reference numerals 532 to 534). The screen transition is made to another input content confirmation screen 512 and a registration content confirmation screen 513. In the present embodiment, it is possible to appropriately transition the screens of each of them and to register user inputs appropriately.
[0038]
6 and 7 are flowcharts showing an example of processing when a plurality of data (screens) are held.
First, the session object 22 is generated in the server 16 by the access from the client machine 14 (step 600a) (step 600b). When the order ID screen request from the client machine 16 and the data ID given in the response from the previous server are transmitted to the object 20 of the server 16, as described in steps 315 and 316 of FIG. The data ID is collated and deleted (not shown), and then the order entry screen request is transmitted to the session object 22 (step 602).
[0039]
The session object 22 provides the object 20 with data (screen data for generating an order entry screen) in response to the request and a data ID (for example, data ID = aaa) that is unique to the request. return. Thereby, the screen data and the data ID (= aaaa) are transmitted to the client machine (step 603). The data ID (= aaaa) is stored in the data storage unit 18 (step 604).
[0040]
On the other hand, when the second order entry screen request is transmitted to the object 20 together with the data ID, for example, by opening a new window in the same session (step 611), the verification of the data ID and the deletion of the data ID are performed. After this (not shown), this is communicated to the session object 22. Here, it is considered that the data ID is appropriately verified. Therefore, the second order entry screen request is also transmitted to the session object 22 (step 612).
[0041]
The session object 22 sends data (screen data for generating an order entry screen) in response to the request and a data ID (for example, data ID = bbbb) unique to the request to the object 20. return. Thereby, the screen data and the data ID (= bbbb) are transmitted to the client machine (step 613). The data ID (= bbbb) is stored in the data storage unit 18 (step 614). Therefore, the second order entry screen can be displayed on the display device of the client machine 14 separately from the order entry screen in response to the previous request.
[0042]
When the user refers to the (first) order entry screen and turns on the button associated with the desired product, the data indicating that the button is turned on and the data ID (= aaa) given in step 603 are It is sent to the server 16 (step 605). The object 20 collates and deletes the data ID (because data collation is appropriately performed in this case), and an order input request is given to the session object 22 (step 608). In response to this, the session object 22 transmits the order data for generating the input content confirmation screen and the corresponding data ID (for example, data ID = cccc) to the client machine 14 via the object 20. (Step 609). Again, the data ID (= cccc) is stored in the data storage unit 18 (step 610). Also in this case, the response data and a new data ID that uniquely identifies the response data are given to the client machine 14. In this way, when the data ID is added to the request and transmitted to the server, one of the screen transitions (reference numerals 501 to 503 in FIG. 5) can be appropriately executed.
[0043]
On the other hand, when the user refers to the second order input screen and turns on the button associated with the desired product, the request and the data ID (= bbbb) given in the previous step 613 are also stored in the server 16. (Step 615). Thereafter, verification and deletion of the data ID (= bbbb), transmission of the second order data in response to the second order input in the session object, and transmission of the corresponding data ID (= dddd), etc. are executed (step) 616-620). These are the same as steps 516 to 520 in FIG. 5 described above except that the data ID is different. In this way, the other screen transition (reference numerals 511 to 513 in FIG. 5) can also be appropriately executed.
[0044]
As described above, according to the present embodiment, the request from the client machine is issued by issuing and storing the data ID, collating the data ID from the client machine with the stored data ID, and deleting the data ID after the collation. In response to this, the necessary processing (for example, data registration and screen transition) is executed. Therefore, even when there are two requests (for example, a data registration request) from the same screen, appropriate processing can be executed only in accordance with the previous request. In addition, even when the same screen is simultaneously held in the same session and any request is made on each screen, it is possible to execute an appropriate process in response to each request.
[0045]
Next, the second embodiment of the present invention will be described. Also in the system according to the second embodiment, as shown in FIG. 1, the client machine 14 and the server 16 are connected to the Internet, and the server 16 performs predetermined requests for various requests from the client machine 14. Content can be provided.
[0046]
In the first embodiment, after collation is completed, the data ID in the data storage unit 18 is deleted, thereby preventing execution of processing in response to a duplicate request. However, if the data ID is deleted, it cannot be determined whether the request is due to a double click or is completely different. Therefore, only a uniform response, such as transmitting an error message image, was possible. On the other hand, in the second embodiment, the request given to the server 16 by double-clicking is ignored, and an error message image can be transmitted to the client 14 for other inappropriate requests. It is configured.
[0047]
FIG. 8 is a flowchart illustrating an example of processing executed by the client machine 14 and the server 16 according to the second embodiment. 8, steps 801 to 804 and steps 811 to 815 correspond to steps 301 to 304 and steps 311 to 315 in FIG. 3, respectively. After the confirmation data and confirmation ID are given to the client 14 (see step 812), when the confirmation button is turned on by the operation on the client machine 14 by the user, the data received in step 812 together with the confirmation request. An ID (eg, data ID = “aaaa”) is transmitted from the client 14 to the server 16 (step 814).
[0048]
As in the first embodiment, the object 20 of the server 16 collates the received data ID with the data ID associated with the order data stored in step 813 (step 815). If they match, a registration request is transmitted to the session object 817 (step 817). That is, in this case, it is determined that the request in step 814 is appropriate, and the processing further proceeds.
[0049]
In the second embodiment, after the collation, the data ID used for the collation (data ID = “aaaa”) is moved and associated with the order data and stored in the data storage unit 18 as a confirmed ID ( Step 816 and reference 820). The confirmed ID is not used for the initial verification (eg, step 815 in FIG. 8) with the data ID transmitted from the client, and is executed when the initial verification fails as will be described later. Used for secondary verification.
[0050]
In response to the transmission of the registration request (step 817), the session object 22 returns to the object 20 registration data for generating a registration confirmation screen and a data ID that is unique to the request in step 317. (Step 818). Accordingly, the registration data is transmitted to the client machine 14 together with the data ID as confirmation data for requesting confirmation from the user side (step 819). Although not shown in FIG. 8, as in the first embodiment, the data ID of this registration data is also stored in the data storage unit 18 and used for verification at the next access from the client machine 14. .
[0051]
In FIG. 8, a case is considered where the confirmation button is turned on (see step 814) by the user's operation on the client machine 14 is a double click. In this case, as shown in FIG. 9A, the same confirmation request and data ID (data ID = “aaaa”) are transmitted again to the server (step 901). The object 900 initially collates the received data ID with the data ID associated with the order data stored in the data storage unit 18 (step 902). However, since the data ID used for collation is moved and stored as the confirmed ID in step 816 in FIG. 8, there is no data ID identical to the accepted data ID in step 902. In this case, the object 20 secondarily collates the received data ID with the confirmed ID (step 903).
[0052]
In the example of FIG. 9A, “aaa” is stored as the confirmed ID, so it is determined that the same data ID exists. If the confirmed ID is the same as the accepted data ID, the object 20 ignores the request from the client 14 (see reference numeral 904).
On the other hand, as shown in FIG. 9B, in the initial collation and the secondary collation (collation with the confirmed ID), the same data ID as the received data ID is stored in the data storage unit 18. If the object 20 cannot be found (see steps 911 to 913), the object 20 transmits an image including an error message (error message image) to the client 14.
[0053]
Thus, according to the second embodiment, it is possible to determine whether the request is a double-click request or another inappropriate request by the initial verification and the secondary verification, Appropriate processing (for example, ignoring or sending an error message) according to the request mode can be executed.
The present invention is not limited to the above embodiments, and various modifications can be made within the scope of the invention described in the claims, and these are also included in the scope of the present invention. Needless to say.
[0054]
【The invention's effect】
According to the present invention, the information on the screen that the user is referring to matches the information to be processed, and responds to the user's request without conflict even when double-clicking or opening multiple screens. can do.
[Brief description of the drawings]
FIG. 1 is a block diagram showing an outline of a system including a server according to a first embodiment of the present invention.
FIG. 2 is a diagram showing an outline of processing by a server using the technique according to the present embodiment.
FIG. 3 is a flowchart illustrating an example of processing executed by a client machine and a server according to the present embodiment.
FIG. 4 is a flowchart illustrating an example of processing executed by the client machine and the server according to the present embodiment.
FIG. 5 is a diagram showing an example of screen transition according to the present embodiment.
FIG. 6 is a flowchart illustrating an example of processing when a plurality of data (screens) is held in the present embodiment.
FIG. 7 is a flowchart illustrating an example of processing when a plurality of data (screens) is held.
FIG. 8 is a flowchart illustrating an example of processing executed by a client machine and a server according to the second embodiment.
FIG. 9 is a flowchart illustrating an example of processing executed by a client machine and a server.
[Explanation of symbols]
14 Client machine
16 servers
20 objects
22 Session object

Claims (2)

An information processing method for executing a predetermined process in response to a request from a client machine and returning a processing result as a response to the client machine,
Generating a session object that holds a session ID for a series of requests and responses from a client machine at the server;
Generating response data and a data ID uniquely identifying the response data in the session object in order to respond to a request from the client machine;
Transmitting the response data and the data ID to the client machine, and temporarily storing the data ID in a storage unit;
At the client machine, sending another request based on the response data with a data ID associated with the response data,
In the server, the data ID received from the client computer is collated with the data ID temporarily stored in the storage unit, and when the collation can be appropriately performed, the session object responds to the other request. Generating second response data;
Generating a new data ID that uniquely identifies the second response data;
A step of preventing the data ID once used for verification from being used for verification in response to a request after the verification,
The step of not using the collation is as follows:
Moving the temporarily stored data ID and storing it in a different area of the storage means as a verified data ID by verification;
Further, in order to determine whether the request is a double-click request or another inappropriate request, the received data ID is checked against the data ID temporarily stored in the storage means, and the check is made appropriately. If the received data ID and the confirmed data ID stored in another area of the storage means are secondarily verified,
If that could appropriately secondary verification, it is determined that the request by the double-click, ignores the other requests, while, if it can not adequately secondary verification, the other And determining that the request is inappropriate and transmitting an error message to the client in response to the other request. An information processing program that operates a server to execute a predetermined process in response to a request from a client machine, and return a processing result as a response to the client machine,
Generating a session object that holds a session ID for a series of requests and responses from a client machine;
Generating response data and a data ID uniquely identifying the response data in the session object in order to respond to a request from the client machine;
Transmitting the response data and the data ID to the client machine, and temporarily storing the data ID in a storage unit;
Receiving another request based on the response data and a data ID associated with the response data transmitted at the client machine;
A second response in response to the other request in the session object when the data ID received from the client machine is collated with the data ID temporarily stored in the storage means and can be appropriately collated. Generating data; and
Generating a new data ID that uniquely identifies the second response data;
Causing the computer to execute the step of preventing the data ID once used for verification from being used for verification in response to a request after the verification,
The step of not using the collation is as follows:
Moving the temporarily stored data ID and storing it in a different area of the storage means as a verified data ID by verification;
Further, in order to determine whether the request is a double-click request or another inappropriate request, the received data ID is checked against the data ID temporarily stored in the storage means, and the check is made appropriately. If the received data ID and the confirmed data ID stored in another area of the storage means are secondarily verified,
If that could appropriately secondary verification, it is determined that the request by the double-click, ignores the other requests, while, if it can not adequately secondary verification, the other And causing the computer to execute the step of determining that the request is inappropriate and transmitting an error message to the client in response to the other request.

Images