JP2004287899A - Information processing method and processing program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system by which the information of a screen referred by a user is matched with the information to be processed and the request of the user is responded without discrepancy even at the time of performing double clicking or opening a plurality of images. <P>SOLUTION: A session object 22 holding a session ID relating to a series of requests and responses from a client machine is generated, and response data and a data ID uniquely specifying them are generated in the session object 22 in order to respond to a specified request and are stored in a data storage part 18. At the time of receiving a different request from the response data and the data ID imparted to it from the client machine, the received data ID and a temporarily stored data ID are collated, and when they are appropriately collated, the session object 22 generates the response data responding to the request. Also, a new data ID specifying uniquely the response data after being processed is generated. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a session management method in a web system.
[0002]
[Prior art]
The HTTP protocol is a stateless communication method that does not hold a state and does not require securing or opening a communication path. For this reason, a series of requests and responses related to product purchase, such as an order input screen, an order specification screen and an order confirmation screen in response to the order, and a registration confirmation screen in response to the confirmation input, are transmitted from the same client. It is known to use “HTTP Session” (session key) in order to determine that the client is the client and to grasp the state of the client.
[0003]
In this method, the server side holds client-specific information (session key), and gives a client-specific session key to a request from the client and returns a response. By adding the session key also to the client request, the server can determine which client has made the request.
[0004]
For example, Patent Literature 1, however, has various problems because it is stateless and connectionless. For example, Patent Literature 1 proposes a technology that manages session time and determines whether a screen transition is within a predetermined time, in order to prevent impersonation of another person even when the terminal is separated from the terminal for a long time. Have been.
[0005]
[Patent Document 1] JP-A-2002-229941
[0006]
[Problems to be solved by the invention]
In addition to the above-described impersonation of another person, the method using a session key may cause the following problems.
For example, when a user opens a new window, multiple browsers with the same session key may be created. In this case, there is a problem that it is impossible to determine which browser screen is the request from, and an appropriate response cannot be made.
[0007]
There is also a problem of double registration in the registration process. For example, when the confirmation button is double-clicked on the input content confirmation screen, the confirmation is registered twice. Further, after turning on the confirmation button, there is a possibility that the screen can be returned to the original state with the return button and the confirmation button can be turned on again. For example, when confirming the purchase of a product, the server may determine that the product was purchased twice.
Conventionally, the following methods have been put into practical use as measures against the above problems.
[0008]
(1) Upon receiving the ON of the input button from the client, the server retains the confirmation information, and upon receiving the ON of the button (for example, the registration button) transmitted from the client next, executes the registration processing, Delete the above confirmation information. Thereby, the problem of double registration can be solved.
[0009]
(2) Issue a token (Token) and return it to the client for the screen transition. The server executes processing in response to only the request to which the latest token has been assigned. 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, data displayed on the client machine may be different from data to be processed. For example, order a product on one screen, call a screen to confirm the input contents, and then order another product on the other screen (the screen itself is the same as the above one screen) and confirm the input contents. Consider the state where the screen is called. Here, when the user turns on the registration button on the screen for confirming the contents of one (ordered first), the server may determine that the registration button is on from the other screen. That is, while the user intends to purchase the product A, the product B that the user has purchased on the other screen is registered.
In addition, even if a “return” button is specified on a screen (change screen) for changing user information or the like, the button is invalidated. For example, a similar problem may occur in displaying a search result list.
[0011]
In the method (2), the "back" button of the browser cannot be used. Pressing the "return" button invalidates subsequent operations. Also, if multiple browsers are open in the same session and you erase one screen, you will have to restart from login. That is, if the screen containing the current token disappears, the operation cannot be continued. Furthermore, if you double-click the registration button, an error will be displayed.
[0012]
The present invention is to respond to a user's request without any inconsistency even when the information on the screen referred to by the user and the information to be processed match, and the user is double-clicking or opening multiple screens. The purpose is to provide a system that can perform
[0013]
[Means for Solving the Problems]
An object of the present invention is 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; and in the session object, response data and data uniquely identifying the response data in order to respond to a request from the client machine. Generating an ID, transmitting the response data and the data ID to the client machine, and temporarily storing the data ID in a storage unit. Different request Sending a data ID associated with the response data to the server, and comparing the received data ID with the data ID temporarily stored in the storage means in the server so that the data can be appropriately compared. Generating a response data in response to the request in the session object; generating a new data ID for uniquely identifying the processed response data; Preventing the ID from being used for matching in response to the request after the matching.
[0014]
According to the present invention, the data ID associated with the response data created in response to the preceding request is stored in the storage means of the server and transmitted to the client. The transmitted data ID is returned from the client to the server together with another request based on the response data. The data ID returned to the server is collated with the data ID stored in the storage unit. If the same data ID as the data ID returned from the client to the server exists in the storage means, it is determined that the data has been properly collated, and the process is continued. The data ID once used for collation is not used for subsequent collation. Thus, double registration can be prevented.
[0015]
Further, the data ID is related to response data to a certain request. Therefore, if the screen is returned to the screen corresponding to the response data again after the return button of the browser is pressed on the client, the data ID associated with the response data is added to the request from the returned screen. Therefore, the server can perform appropriate processing.
[0016]
That is, in the present invention, a data ID is assigned and managed for each data held by the object, separately from the conventional session ID for session management. For this reason, the data ID can be assigned not depending on the screen transition state or the HTTP request from the client machine and focusing only on the change of the data of the object. Thus, even when the screen is returned again after the double registration is prevented or the return button of the browser is pressed, appropriate processing in the server can be realized.
[0017]
It is desirable that the data ID is randomly and uniquely generated so that it is difficult to guess.
[0018]
In a preferred embodiment, the step of not using the data ID for collation includes the step of erasing the temporarily stored data ID. In this embodiment, the method may further include a step of transmitting an error message to the client machine in response to the request when the matching is not properly performed.
[0019]
In another preferred embodiment, the step of not using the data for the collation comprises moving the temporarily stored data ID and storing the data ID as a data ID confirmed by collation in another area of the storage unit. With steps. More preferably, the received data ID is compared with the data ID temporarily stored in the storage means. If the data ID is not properly matched, the received data ID and the confirmed data are compared. A step of secondary matching with the ID, and if the secondary matching is properly performed, the request is ignored, and if the secondary matching 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 executing a predetermined process in response to a request from a client machine, and operating a computer to 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; and responding to the request from the client machine, in the session object, uniquely identifying the response data and the response data. Generating a data ID to specify the data, 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 to the client machine. Is Receiving a different request from the response data and a data ID associated with the response data, collating the received data ID with the data ID temporarily stored in the storage unit, and appropriately collating the data ID. If successful, 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 identifying the processed response data, and once used for collation Making the computer execute the step of not using the data ID for the matching in response to the request after the matching.
[0021]
In a preferred embodiment, the step of erasing the temporarily stored data ID is performed by the computer in the step of not using the data ID for collation. Here, the step of transmitting an error message to the client machine in response to the request when the collation cannot be properly performed may be performed by the computer.
[0022]
In another preferred embodiment, in the step of not using the data ID for collation, the step of moving the temporarily stored data ID and storing the data ID as a data ID confirmed by collation in another area of the storage unit Is executed by the computer. Furthermore, the received data ID is compared with the data ID temporarily stored in the storage means. If the data ID cannot be properly compared, the received data ID and the confirmed data ID are compared. Next, the step of collating is performed by the computer, and if the secondary collation is properly performed, the request is ignored, while if the secondary collation is not properly performed, Transmitting the error message to the client in response to the request.
[0023]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. FIG. 1 is a block diagram schematically showing 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 content (for example, an image) in response to various requests from the client machine 14. Of course, the present invention is not limited to the form in which the client machine 14 can be connected to the server 16 via the Internet 12, but it is needless to say that the present invention can be applied to a machine connected via an arbitrary network such as a LAN or WAN. Further, the server 16 is provided with a data storage unit 18 for temporarily storing a data ID used when data is transmitted / received from the client machine 14.
[0024]
FIG. 2 is a diagram illustrating an outline of processing by the server 16 using the method according to the present embodiment. Here, a state is shown in which a command is transmitted from the client machine 14 to the server 16 by exchanging data between the client machine 14 and the server 16, and a screen transition is made on the client machine 14.
[0025]
In FIG. 2, on the product purchase site, a registered content indicating that the order content has been registered, from an order input screen 201 for specifying the product and ordering the specified product, through an order content confirmation screen 202 for confirming the order content. The screen transitions to the confirmation screen 203. The server 16 generates a session object 22 (for example, session ID (SID) = YYZZX) when the servlet object 20 starts a session with the client machine 14, and when the session object 22 changes data, The data ID is numbered, and the unique data ID is transmitted to the client machine 14 together with the data. The data ID is randomly and uniquely assigned so that it is impossible or difficult to guess.
[0026]
The user refers to the order input screen on the display device of the client machine 14 and selects a certain product, which is transmitted to the server 16 (see arrow 211). As a result of the processing by the server 16, necessary data is obtained. The input content confirmation screen 202 is displayed on the display device of the client machine 14 (see arrow 212). Next, when a button or the like indicating confirmation of the content is designated by the user operating the input device, this is transmitted to the server 16 (see the arrow 213). By repeating the data transfer (see arrows 213 and 214), the server 16 registers the product purchased by the user.
[0027]
FIG. 3 is a flowchart illustrating an example of processing executed by the client machine 14 and the server 16 according to the present embodiment. Here, the processing executed in 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 maintained until the session with the client machine 14 ends.
[0028]
It is assumed that an order input screen is displayed on the display device of the client machine 14 due to the 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 attached to any of the listed product names.
[0029]
Here, when the user specifies a certain product and turns on a button associated with the product, data indicating that the order input button has been turned on and predetermined other data (data ID) are input to the server as input data. The information is transmitted to the 16 objects 20 (step 303). Actually, the data ID and the parameter corresponding to the designated product number are added to the call (request) of the method “select a list” of the object from the client machine, and the result is given to the server 16. This data ID will be described in detail in step 311 and thereafter.
[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 an input content confirmation screen and a data ID unique to the request in step 304, and returns these to the object 20 (step 311). Therefore, 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]
Referring to the input content confirmation screen on the display device of the client machine 14, when the user operates the input device to turn on the confirmation button, the request is transmitted to the request "confirmation request" 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 the registration request is transmitted to the session object 22 (step 317).
[0032]
The session object 22 returns the registration data for generating the registration confirmation screen and the data ID 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 asking the user for confirmation (step 319). That is, the response data and a new data ID for uniquely specifying the response data are given to the client machine 14. Although not shown in FIG. 3, the data ID of the registration data is also stored in the data storage unit 18 and is used for collation at the time of the next access from the client machine 14.
[0033]
Here, it is assumed that the confirmation button is turned on twice while a screen (input content confirmation screen) based on the order data is displayed on the client machine. For example, this corresponds to a case where a single click operation of the mouse is sufficient for a double click operation. 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 similar to step 314 in FIG. Therefore, the object 20 refers to the data storage unit 18 to collate the data ID (Step 315), and deletes the data after collation (Step 316). Since the data ID verification has been successfully completed (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 the registration request and the 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 collation 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) from the client machine 14, data (confirmation data) and a data ID responding to the request are returned to the client machine 14, and the The data ID associated with the confirmation data is attached to the next request related to the responded data and transmitted. The server 16 can specify the request from the user by holding the data ID.
[0036]
In addition, 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, display of multiple screens, and the like.
[0037]
Further, according to the present embodiment, it is possible to hold a plurality of data (screens) in the same session and execute an appropriate process for each of them. FIG. 5 is a diagram showing an example of such a screen transition. In FIG. 5, a user inputs a request (refer to reference numerals 521 to 524) on the product purchase site, and the screen is changed in the order of an order input screen 501, an input content confirmation screen 502, and a registered content confirmation screen 503. . This corresponds to each of 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 is changed to another input content confirmation screen 512 and a registered content confirmation screen 513. In the present embodiment, it is possible to appropriately make screen transitions and to appropriately register user inputs.
[0038]
FIG. 6 and FIG. 7 are flowcharts illustrating an example of a process when a plurality of data (screens) are stored.
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 data ID assigned in the order input screen request from the client machine 16 and the response from the previous server is transmitted to the object 20 of the server 16, as described in steps 315 and 316 of FIG. Then, the data ID is collated and erased (not shown), and then an order input screen request is transmitted to the session object 22 (step 602).
[0039]
The session object 22 stores, in the object 20, data responding to the request (screen data for generating an order input screen) and a data ID (for example, data ID = aaaa) 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, in the same session, when the second order input screen request is transmitted to the object 20 together with the data ID by, for example, opening a new window (step 611), the data ID is collated or the data ID is deleted. After this (not shown), this is communicated to the session object 22. Here, it is assumed that the data ID has been properly collated. Therefore, the second order entry screen request is also transmitted to the session object 22 (step 612).
[0041]
The session object 22 stores, in the object 20, data responding to the request (screen data for generating an order input screen) and a data ID (for example, data ID = bbbb) unique to the request. return. Thus, 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 input screen can be displayed on the display device of the client machine 14 separately from the order input screen responding to the previous request.
[0042]
When the user refers to the (first) order input screen and turns on the button associated with the desired product, the data indicating that the button is turned on and the data ID (= aaaa) previously given in step 603 are It is sent to the server 16 (step 605). The object 20 performs collation and deletion of the data ID (in this case, data collation is properly performed), 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). Here, 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 for uniquely specifying the response data are given to the client machine 14. In this way, by transmitting the request with the data ID added to the server, it is possible to appropriately execute one screen transition (reference numerals 501 to 503 in FIG. 5).
[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 stored in the server 16. (Step 615). Thereafter, collation 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) are performed (step). 616-620). These are the same as steps 516 to 520 of FIG. 5 described above except that the data ID is different. In this manner, the other screen transition (reference numerals 511 to 513 in FIG. 5) can be appropriately executed.
[0044]
As described above, according to the present embodiment, a request from a client machine is issued by issuing and storing a 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 the request, a necessary process (for example, data registration or 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, the same screen is simultaneously held in the same session, and even if any request is made on each screen, it is possible to execute appropriate processing in response to each request.
[0045]
Next, a second embodiment of the present invention will be described. Also in the system according to the second embodiment, as shown in FIG. 1, a client machine 14 and a server 16 are connected to the Internet, and the server 16 responds to various requests from the client machine 14 in accordance with predetermined requests. Content can be provided.
[0046]
In the first embodiment, after the end of the collation, the data ID in the data storage unit 18 is deleted, thereby preventing the execution of the process in response to the duplicated request. However, if the data ID is deleted, it cannot be determined whether the request is made by double-clicking or completely different. Therefore, only a uniform response such as transmitting an error message image was possible. On the other hand, in the second embodiment, a 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 the confirmation ID are given to the client 14 (see step 812), when the confirmation button is turned on by the user's operation on the client machine 14, the data received in step 812 is transmitted together with the confirmation request. The ID (for example, data ID = "aaa") is transmitted from the client 14 to the server 16 (step 814).
[0048]
The object 20 of the server 16 collates the received data ID with the data ID stored in step 813 and associated with the order data, as in the first embodiment (step 815). If they match, the registration request is transmitted to the session object 817 (step 817). That is, in this case, the request in step 814 is determined to be appropriate, and the process further proceeds.
[0049]
In the second embodiment, after the collation, the data ID (data ID = “aaaa”) used for the collation is moved and stored in the data storage unit 18 as a confirmed ID in association with the order data ( Step 816 and reference numeral 820). The confirmed ID is not used for initial collation with the data ID transmitted from the client (for example, step 815 in FIG. 8), and is executed when the initial collation fails, as described later. Used for secondary verification.
[0050]
In response to the transmission of the registration request (step 817), the session object 22 returns the registration data for generating the registration confirmation screen and the data ID unique to the request in step 317 to the object 20. (Step 818). Therefore, the registration data is transmitted to the client machine 14 together with the data ID as confirmation data for asking the user for confirmation (step 819). Although not shown in FIG. 8, similarly to the first embodiment, the data ID of the registration data is also stored in the data storage unit 18 and used for collation at the time of the next access from the client machine 14. .
[0051]
In FIG. 8, it is assumed that the user turns on the confirmation button by operating the client machine 14 (see step 814) by double clicking. In this case, as shown in FIG. 9A, the same confirmation request and data ID (data ID = “aaaa”) are transmitted to the server again (step 901). The object 900 initially collates the received data ID with the data ID stored in the data storage unit 18 and associated with the order data (step 902). However, in step 816 of FIG. 8, since the data ID used for collation has been moved and stored as the confirmed ID, there is no data ID identical to the received 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, since “aaaa” is stored as the confirmed ID, it is determined that the same data ID exists. When the confirmed ID includes the same data ID as the received 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. When the object 20 is not found (see steps 911 to 913), the object 20 transmits an image including an error message (error message image) to the client 14.
[0053]
As described above, 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 collation and the secondary collation, It is possible to execute appropriate processing (for example, ignoring or sending an error message) according to the mode of the request.
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, which 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 referred to by the user matches the information to be processed, and responds to the user's request without inconsistency even when double-clicking or opening multiple screens. can do.
[Brief description of the drawings]
FIG. 1 is a block diagram schematically showing a system including a server according to a first embodiment of the present invention.
FIG. 2 is a diagram schematically illustrating a process performed by a server using a method according to the embodiment;
FIG. 3 is a flowchart illustrating an example of processing executed by a client machine and a server according to the embodiment;
FIG. 4 is a flowchart illustrating an example of processing executed by the client machine and the server according to the embodiment;
FIG. 5 is a diagram illustrating an example of screen transition according to the embodiment;
FIG. 6 is a flowchart illustrating an example of a process in a case where a plurality of data (screens) is stored in the present embodiment.
FIG. 7 is a flowchart illustrating an example of a process when a plurality of data (screens) are stored.
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 (10)

An information processing method of executing a predetermined process in response to a request from a client machine, and returning a process result as a response to the client machine,
At the server, generating a session object holding a session ID for a series of requests and responses from the client machine;
Generating response data and a data ID uniquely identifying the response data in the session object 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;
A step of, in the client machine, transmitting a different request from the response data with a data ID associated with the response data;
A step of comparing the received data ID with the data ID temporarily stored in the storage means in the server, and generating response data in response to the request in the session object when the data ID can be appropriately compared; When,
Generating a new data ID that uniquely identifies the processed response data;
Preventing the data ID once used for matching from being used for matching in response to a request after the matching. The step of not using for the matching,
2. The information processing method according to claim 1, further comprising erasing the temporarily stored data ID. 3. The information processing method according to claim 2, further comprising transmitting an error message to the client machine in response to the request when the collation fails. The step of not using for the matching,
2. The information processing method according to claim 1, further comprising the step of moving the temporarily stored data ID and storing the data ID as a data ID confirmed by collation in another area of the storage unit. Furthermore, the received data ID is compared with the data ID temporarily stored in the storage means. If the data ID cannot be properly compared, the received data ID and the confirmed data ID are compared. Next matching step, and
If the secondary match is successful, the request is ignored, while if the secondary match is not successful, an error message is sent to the client in response to the request. The information processing method according to claim 4, further comprising the step of: An information processing program for executing a predetermined process in response to a request from a client machine, and operating a server to return a process result as a response to the client machine,
Generating a session object holding a session ID for a series of requests and responses from the client machine;
Generating response data and a data ID uniquely identifying the response data in the session object 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 a different request from the response data sent at the client machine and a data ID associated with the response data;
Collating the received data ID with the data ID temporarily stored in the storage unit, and, if the collation is properly performed, generating response data in response to the request in the session object;
Generating a new data ID that uniquely identifies the processed response data;
Causing the computer to execute the step of not using the data ID once used for the matching in the matching in response to the request after the matching. In the step of not using for the collation,
The program according to claim 6, wherein the program causes the computer to execute the step of deleting the temporarily stored data ID. The computer-readable storage medium according to claim 7, wherein the computer is caused to execute a step of transmitting an error message to the client machine in response to the request when the collation is not properly performed. In the step of not using for the collation,
7. The computer according to claim 6, further comprising: causing the computer to execute the step of moving the temporarily stored data ID and storing the temporarily stored data ID as a confirmed data ID in another area of the storage unit. program. Furthermore, the received data ID is compared with the data ID temporarily stored in the storage means. If the data ID cannot be properly compared, the received data ID and the confirmed data ID are compared. Causing the computer to perform the following collating step; and
If the secondary match is successful, the request is ignored, while if the secondary match is not successful, an error message is sent to the client in response to the request. The program according to claim 9, wherein the program causes the computer to execute the step of:

Images