Information processing system, client device, and information processing program

Abstract

To allow easy switching of servers at the occurrence of failure.SOLUTION: First management means manages a result of information processing executed by first processing means in response to multiple times of requests from first request means in association with an identifier. Recording means records the history of requests from the first request means in association with an identifier. According to determination of the occurrence of failure made by determination means, according to the recorded history, and accompanied by a notification of the identifier with which the history is associated, second request means requests a second server to execute information processing that has been requested from the first request means before the occurrence of failure. Second management means manages a result of information processing executed by second processing means in response to multiple times of requests from second request means and third request means in association with the notified identifier. Update means updates the execution result managed by the first management means in association with the identifier notified by notification means according to the execution result notified by the notification means.SELECTED DRAWING: Figure 10

Description

[Technical field]

[0001] An embodiment of the present invention relates to an information processing system, a client device, and an information processing program. [Background technology]

[0002] There is a known system in which a smartphone carried by a customer shopping at a store or a tablet terminal installed in the store is used as a user interface device for the customer, and information processing for registering purchased items and settling the price for the items is performed by a cloud server. In other words, it is known to realize a system for managing product sales by a client-server system consisting of a client device using a smartphone or a tablet terminal and a server such as a cloud server. However, in such a system, if some kind of failure occurs, such as a communication failure between the client device and the server, the process cannot be continued and the customer is unable to complete his shopping.

[0003] Therefore, it is possible to prepare a first and a second server and have the second server take over processing when a failure occurs in the first server. However, in this case, cooperation between the first and second servers is required, which increases the processing load. In view of these circumstances, it has been desirable to be able to easily switch servers when a failure occurs. [Prior art documents] [Patent documents]

[0004] [Patent Document 1] Patent No. 4983445 Summary of the Invention [Problem to be solved by the invention]

[0005] An object of the present invention is to provide an information processing system, a client device, and an information processing program that enable easy switching of a server when a failure occurs. [Means for solving the problem]

[0006] An information processing system according to an embodiment includes a first server, a second server, and a client device. The first server includes a first processing means, a first management means, and an update means. The second server includes a second processing means, a second management means, and a notification means. The client device includes a first request means, a recording means, a determination means, a second request means, and a third request means. The first request means requests the first server to perform information processing in response to an operation. The first processing means executes information processing in response to the request by the first request means. The first management means manages execution results of information processing by the first processing means in response to multiple requests by the first request means in association with the same identifier. The recording means records a history of requests by the first request means in association with the identifier. The determination means determines that a failure has occurred in the first server. The second request means, in response to the determination of the occurrence of a failure by the determination means, requests the second server to perform information processing that has been requested by the first request means before the occurrence of the failure, in accordance with the history recorded by the recording means, along with a notification of the identifier with which the history is associated. The third request means requests the second server to perform information processing in accordance with an operation after the request by the second request means is completed. The second processing means executes information processing in accordance with the request by the second request means and the third request means. The second management means manages an execution result of the information processing by the second processing means in response to the multiple requests by the second request means and the third request means, in association with the identifier notified by the second request means. The notification means notifies the first server of the execution result managed by the second management means together with the associated identifier, after the request by the third request means regarding the identifier notified by the second request means is completed. The update means updates the execution result managed by the first management means in association with the identifier notified by the notification means, with the execution result notified by the notification means. [Brief description of the drawings]

[0007] [Figure 1] 1 is a block diagram showing a schematic configuration of a product sales processing system according to an embodiment. [Diagram 2] 2 is a block diagram showing a main circuit configuration of the store server shown in FIG. 1; [Diagram 3] FIG. 3 is a schematic diagram showing a data structure of the transaction data shown in FIG. 2 . [Figure 4] 2 is a block diagram showing a main circuit configuration of the user terminal shown in FIG. 1; [Diagram 5] FIG. 5 is a schematic diagram showing a data structure of the history data shown in FIG. 4 . [Figure 6] 2 is a block diagram showing the main circuit configuration of the cart terminal shown in FIG. 1. [Figure 7] 2 is a block diagram showing a main circuit configuration of the cloud server shown in FIG. 1. [Figure 8] FIG. 8 is a schematic diagram showing the data structure of the transaction data shown in FIG. 7. [Figure 9] 5 is a flowchart of information processing based on a smartphone POS app by the processor shown in FIG. 4. [Figure 10] 5 is a flowchart of information processing based on a smartphone POS app by the processor shown in FIG. 4. [Figure 11] 8 is a flowchart of a web POS process based on a web POS app by the processor shown in FIG. 7. [Figure 12] 3 is a flowchart of an agent POS process based on an agent POS application by the processor shown in FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0008] Hereinafter, an embodiment of a product sales processing system configured by applying an information processing system will be described with reference to the drawings. FIG. 1 is a block diagram showing a schematic configuration of a product sales processing system according to this embodiment. The product sales processing system includes a plurality of store systems 100, a user terminal 200, a cart terminal 300, and a cloud server 400. The plurality of store systems 100, the user terminals 200, the cart terminals 300, and the cloud server 400 are capable of communicating with each other via a communication network 500.

[0009] FIG. 1 shows two store systems 100. These store systems 100 are installed in two different stores, Store A and Store B, which use the product sales processing system. There may be three or more stores that use the product sales processing system, with a store system 100 installed in each store. In the following, when it is necessary to distinguish between the store systems 100 installed in each store, the store system 100 installed in Store A will be referred to as store system 100-1, and the store system 100 installed in Store B will be referred to as store system 100-2. The business operator who operates store A may be the same as or different from the business operator who operates store B. When the transaction system is used in other stores, the business operator who operates the other stores may be the same as or different from the business operator who operates store A or store B.

[0010] The user terminal 200 and the cart terminal 300 are information processing devices that function as a user interface for customers who use the product sales processing system to shop at a store. Although FIG. 1 shows one user terminal 200 and one cart terminal 300 in each of store A and store B, a plurality of terminals may be present in each store. In addition, it is not necessary to use either the user terminal 200 or the cart terminal 300 in all stores or in some stores. The user terminal 200 and the cart terminal 300 have a function of wireless communication with the store system 100 and a function of wireless communication with the communication network 500. The user terminal 200 may be a communication terminal with a data communication function such as a smartphone or a tablet computer. The user terminal 200 may be owned by the customer or may be loaned to the customer at the store. The cart terminal 300 may be a communication terminal with a data communication function such as a tablet computer, and is attached to a shopping cart provided in store A or store B. The user terminal 200 and the cart terminal 300 are mainly operated by customers. However, the user terminal 200 and the cart terminal 300 may be operated by a store clerk or the like on behalf of a customer. The cart terminal 300 includes a barcode scanner 301. The barcode scanner 301 is a reading device configured to optically read a barcode representing a product code as an identifier for identifying a product, using an infrared laser or the like. The barcode scanner 301 may include a reading device configured to recognize and read a barcode from an image captured by an imaging device, instead of or in addition to the above reading device.

[0011] The cloud server 400 executes information processing for product sales processing, such as registering purchased products and settling the price, in response to requests from the user terminal 200 and the cart terminal 300. For example, the cloud server 400 has a function for executing various information processing for product sales processing, and publishes multiple APIs (application programming interfaces) for receiving requests to execute such information processing. In an API, a base URL (uniform resource locator) for identifying the API and a definition of arguments, etc. to be added to the base URL are defined. When the cloud server 400 receives access through an access URL formed by adding arguments, etc. to the base URL, it executes the information processing identified by the access URL.

[0012] The communication network 500 may be, for example, the Internet, a virtual private network (VPN), a local area network (LAN), a public communication network, a mobile communication network, or the like, either alone or in appropriate combination. Typically, a mobile communication network and the Internet are used as the communication network 500. In other words, the communication network 500 is typically a wide area network.

[0013] The general configuration of each store system 100 is the same. That is, the store system 100 is configured so that the store server 1, the payment machine 2, the gateway 3, and the access point 4 can communicate with each other via an in-store communication network 5. However, the store server 1, the payment machine 2, the gateway 3, the access point 4, and the in-store communication network 5 only need to have the same functions for realizing the operations described below, and do not need to be completely identical. In addition, some store systems 100 may be equipped with devices not shown in FIG. 1.

[0014] The store server 1 executes information processing for product sales processing such as registering purchased products and settling the price in response to requests from the user terminal 200 and the cart terminal 300. The store server 1 has a function for executing information processing equivalent to that executed by the cloud server 400 for product sales processing. The store server 1 also publishes APIs for receiving requests to execute such information processing. The basic URLs of APIs published by the cloud server 400 and the store server 1 for equivalent information processing are associated with each other in advance. For example, in this embodiment, for an API for registering a specified product as a purchased product, "xyz.cloud.co.jp / api / registration" is defined as the basic URL for the cloud server 400, and "192.168.1.zzz / api / registration" is defined as the basic URL for the store server 1. In other words, the basic URLs defined for APIs for the same information processing differ only in the domain part. When the store server 1 receives an access via the access URL, it executes information processing to be provided by the API specified by the access URL. In other words, the store server 1 has a function for executing product sales processing similar to that of the cloud server 400. However, the store server 1 executes these functions to temporarily act as a proxy for the functions of the cloud server 400, as described below. In other words, the cloud server 400 corresponds to a first server that mainly executes product sales processing, and the store server 1 corresponds to a second server that acts as a proxy for the product sales processing. The user terminal 200 and the cart terminal 300 correspond to client devices for using the product sales processing by the cloud server 400 or the store server 1. The store server 1 is a local server provided in a store, which is a facility where the user terminal 200 and the cart terminal 300 as client devices are operated.

[0015] The accounting machine 2 is a user interface device for customers to make payments at a store. The payment methods that the accounting machine 2 can use for the above-mentioned payments may be all or any part of well-known payment methods, such as cash payment, credit card payment, electronic money payment, point payment, code payment, etc. Code payment is also called mobile payment or smartphone payment. The accounting machine 2 may be operated by either a store clerk or a customer. The accounting machine 2 may be configured, for example, based on a self-service accounting machine used in an existing semi-self-service POS (point-of-sale) system. The accounting machine 2 may have a function of performing information processing for registering products as purchased products. In this case, the accounting machine 2 may be configured, for example, based on a face-to-face POS terminal used in an existing POS system or a self-service POS terminal used in an existing self-service POS system.

[0016] The gateway 3 interconnects the in-store communication network 5 and the communication network 500, enabling communication via both the in-store communication network 5 and the communication network 500. The gateway 3 can be, for example, an existing communication device that interfaces between a LAN and the Internet.

[0017] The access point 4 performs communication processing to enable the user terminal 200 to access the in-store communication network 5 via wireless communication. For example, a well-known communication device that performs wireless communication according to the IEEE802.11 standard can be used as the access point 4. The access point 4 is installed in the store so that the user terminal 200 can perform wireless communication from anywhere in the sales floor of the store. Depending on the size of the store, multiple access points 4 may be installed in one store system 100.

[0018] The in-store communication network 5 may be the Internet, VPN, LAN, public communication network, mobile communication network, or the like, either alone or in appropriate combination. Typically, however, the in-store communication network 5 is a LAN. In other words, the in-store communication network 5 is typically a narrow area network.

[0019] In a store where the store system 100 is installed, a two-dimensional code TCI for check-in is posted near the entrance. The two-dimensional code TCI represents check-in data for checking in. The check-in data differs for each store. The check-in data indicates, for example, information such as (1) the operation version of the store system 100 for each store, (2) a store code for identifying the store, (3) the name of the business operating the store, (4) the name of the store in which the store system 100 is installed, (5) a business code for identifying the business operating the store, and (6) a connection destination and information required for the user terminal 200 to communicate with the store system 100. An example of a connection destination for the user terminal 200 to communicate with the store system 100 is an access point 4. Examples of information required for the connection include an SSID (service set identifier) ​​for identifying the access point 4 and a password for accessing the access point 4. Examples of information required for the connection include the domain name of the store server 1. The check-in data may not include some of the various pieces of information exemplified above. Also, the check-in data may represent information other than the various pieces of information exemplified above.

[0020] FIG. 2 is a block diagram showing the main circuit configuration of the store server 1. As shown in FIG. The store server 1 includes a processor 11, a main memory 12, an auxiliary storage unit 13, a communication interface 14, and a transmission path 15. The processor 11, the main memory 12, the auxiliary storage unit 13, and the communication interface 14 are capable of communicating with each other via the transmission path 15. The processor 11, the main memory 12, and the auxiliary storage unit 13 are connected by the transmission path 15 to configure a computer for controlling the store server 1.

[0021] The processor 11 corresponds to the central part of the computer. The processor 11 executes information processing for realizing various functions of the store server 1 according to information processing programs such as an operating system and application programs. The processor 11 is, for example, a CPU (central processing unit).

[0022] The main memory 12 corresponds to the main storage portion of the computer. The main memory 12 includes a nonvolatile memory area and a volatile memory area. The main memory 12 stores the information processing program in the nonvolatile memory area. The main memory 12 may store data required for the processor 11 to execute information processing in a nonvolatile or volatile memory area. The main memory 12 uses the volatile memory area as a work area where data is appropriately rewritten by the processor 11. The nonvolatile memory area is, for example, a ROM (read only memory). The volatile memory area is, for example, a RAM (random access memory).

[0023] The auxiliary storage unit 13 corresponds to the auxiliary storage portion of the computer. As the auxiliary storage unit 13, for example, a storage unit using a well-known storage device such as an EEPROM (electric erasable programmable read-only memory), a HDD (hard disk drive), or an SSD (solid state drive) can be used. The auxiliary storage unit 13 stores data used by the processor 11 in performing various processes, or data created by the processes in the processor 11. The auxiliary storage unit 13 may also store the above-mentioned information processing program.

[0024] The communication interface 14 performs data communication in accordance with a predetermined communication protocol with each unit connected to the in-store communication network 5. As the communication interface 14, for example, a well-known communication device for a LAN can be applied. The transmission path 15 includes an address bus, a data bus, and control signal lines, and transmits data and control signals between the connected components.

[0025] The auxiliary memory unit 13 stores an agent POS application APA, which is one of the information processing programs. The agent POS application APA is an application program, and describes information processing for realizing the functions of the store server 1. A part of the memory area of ​​the auxiliary memory unit 13 is used to store transaction data DAA. The transaction data DAA is a collection of various data for managing one transaction related to the sale of a product at a store.

[0026] FIG. 3 is a schematic diagram showing the data structure of the transaction data DAA. The transaction data DAA includes product data for each product registered as a purchased product in association with a transaction code as an identifier of the transaction. Therefore, the number of product data items included in the transaction data DAA varies depending on the number of products registered as purchased products. The product data includes a product code, a product name, a price, and a quantity. The product code is an identifier defined to identify the product for each SKU (stock keeping unit), and for example, a JAN (Japanese article number) code is used. The product name is a name defined to make it easy for humans to distinguish the product. The price is the amount of the sale of the product. The quantity is the amount of the product purchased.

[0027] FIG. 4 is a block diagram showing the main circuit configuration of the user terminal 200. The user terminal 200 includes a processor 201, a main memory 202, an auxiliary storage unit 203, a touch panel 204, a camera 205, a sound unit 206, a group of sensors 207, a wireless communication unit 208, a mobile communication unit 209, and a transmission path 210. The processor 201, the main memory 202, the auxiliary storage unit 203, the touch panel 204, the camera 205, the sound unit 206, the group of sensors 207, the wireless communication unit 208, and the mobile communication unit 209 are capable of communicating with each other via a transmission path 210. The processor 201, the main memory 202, and the auxiliary storage unit 203 are connected via the transmission path 210 to configure a computer for controlling the user terminal 200. The functions of the processor 201, the main memory 202, the auxiliary storage unit 203, and the transmission path 210 are generally the same as those of the processor 11, the main memory 12, the auxiliary storage unit 13, and the transmission path 15, and therefore will not be described here.

[0028] The touch panel 204 functions as an input device and a display device for the user terminal 200 . The camera 205 includes an optical system and an image sensor, and generates image data representing an image within a field of view formed by the optical system using the image sensor. The sound unit 206 outputs various sounds such as voices and melodies. The sensor group 207 includes various sensors such as an angular velocity sensor and a GPS (global positioning system) sensor.

[0029] The wireless communication unit 208 transmits and receives data via wireless communication according to a wireless communication protocol with the access point 4. As the wireless communication unit 208, for example, a well-known communication device conforming to the IEEE802.11 standard can be used. The mobile communication unit 209 is an interface for data communication via the communication network 500. As the mobile communication unit 209, for example, a well-known communication device for performing data communication via a mobile communication network can be used.

[0030] The auxiliary memory unit 203 stores a smartphone POS app APB, which is one of the information processing programs. The smartphone POS app APB is an application program that describes information processing, described below, for making the user terminal 200 function as a user interface for customers of the store system 100. A part of the memory area of ​​the auxiliary memory unit 203 is used to store history data DAB. The history data DAB is data for managing the history of requests made to the cloud server 400 regarding one transaction.

[0031] FIG. 5 is a schematic diagram showing the data structure of the history data DAB. The history data DAB includes, in association with a transaction code, an access URL used to request information processing related to the transaction identified by the transaction code from the cloud server 400. Therefore, the number of access URLs included in the history data DAB changes depending on the number of requests.

[0032] FIG. 6 is a block diagram showing the main circuit configuration of the cart terminal 300. In addition to the barcode scanner 301, the cart terminal 300 also includes a processor 302, a main memory 303, an auxiliary storage unit 304, a touch panel 305, a sound unit 306, a wireless communication unit 307, and a transmission path 308. The processor 302 is capable of communicating with the barcode scanner 301, the main memory 303, the auxiliary storage unit 304, the touch panel 305, the sound unit 306, and the wireless communication unit 307 via the transmission path 308. The processor 302, the main memory 303, and the auxiliary storage unit 304 are connected via the transmission path 308 to configure a computer for controlling the cart terminal 300. The functions of the processor 302, main memory 303, auxiliary memory unit 304, touch panel 305, sound unit 306, wireless communication unit 307 and transmission path 308 are generally the same as those of the processor 11, main memory 12, auxiliary memory unit 13, touch panel 204, sound unit 206, wireless communication unit 208 and transmission path 15, so their explanation will be omitted.

[0033] The auxiliary storage unit 304 stores a cart terminal application APC, which is one of the information processing programs. The cart terminal application APC is an application program, and describes information processing for making the cart terminal 300 function as a user interface for customers of the store system 100. A part of the storage area of ​​the auxiliary storage unit 304 is used to store history data DAC. The history data DAC is data for managing the history of requests made to the cloud server 400 regarding one transaction. The history data DAC may have a configuration similar to that of the history data DAB, for example.

[0034] FIG. 7 is a block diagram showing the main circuit configuration of cloud server 400. As shown in FIG. The cloud server 400 includes a processor 401, a main memory 402, an auxiliary storage unit 403, a communication interface 404, and a transmission path 405. The processor 401, the main memory 402, the auxiliary storage unit 403, and the communication interface 404 are capable of communicating with each other via the transmission path 405. The processor 401, the main memory 402, and the auxiliary storage unit 403 are connected by the transmission path 405 to configure a computer for controlling the cloud server 400. The functions of the processor 401, the main memory 402, the auxiliary storage unit 403, the communication interface 404, and the transmission path 405 are generally equivalent to those of the processor 11, the main memory 12, the auxiliary storage unit 13, the communication interface 14, and the transmission path 15, and therefore will not be described here.

[0035] The auxiliary memory unit 403 stores a web POS application APD, which is one of the information processing programs. The web POS application APD is an application program in which information processing, described below, for providing the services described below is described. A part of the memory area of ​​the auxiliary memory unit 403 is used to store transaction data DAD. The transaction data DAD is a collection of various data for managing one transaction. The auxiliary memory unit 403 may store multiple pieces of transaction data DAD, each related to multiple transactions processed in parallel.

[0036] FIG. 8 is a schematic diagram showing the data structure of the transaction data DAD. The transaction data DAD includes a user code, a store code, and product data associated with a transaction code. The transaction code is an identifier of the transaction with which the transaction data DAD is associated. The user code is an identifier of the customer of the transaction with which the transaction data DAD is associated. The store code is an identifier of the store where the transaction with which the transaction data DAD is associated is performed. The product data is data for managing products registered as purchased products. If there are no products registered as purchased products, the transaction data DAD does not include any product data. If multiple products are registered as purchased products, the transaction data DAD includes multiple product data related to each of the purchased products. The product data includes a product code, product name, price, quantity, etc.

[0037] The store server 1, the user terminal 200, the cart terminal 300 or the cloud server 400 may be transferred in a state in which the agency POS application APA, the smartphone POS application APB, the cart terminal application APC or the web POS application APD is stored in the auxiliary storage unit 13, 203, 304, 403, or the hardware in a state in which the agency POS application APA, the smartphone POS application APB, the cart terminal application APC or the web POS application APD is not stored in the auxiliary storage unit 13, 203, 304, 403 and the agency POS application APA, the smartphone POS application APB, the cart terminal application APC or the web POS application APD may be transferred separately. The agency POS application APA, the smartphone POS application APB, the cart terminal application APC or the web POS application APD may be transferred by recording it on a removable recording medium such as a magnetic disk, a magneto-optical disk, an optical disk, a semiconductor memory or the like, or by communication via a network.

[0038] Next, the operation of the product sales processing system configured as described above will be described. Note that the contents of the various processes described below are merely examples, and it is possible to change the order of some of the processes, omit some of the processes, or add other processes as appropriate. For example, in the following description, in order to easily explain the characteristic operations of this embodiment, the description of some of the processes is omitted. For example, when some kind of error occurs, a process may be performed to deal with the error, but the description of some of such processes is omitted.

[0039] The service provided to customers by the operation of the product sales processing system described below is called a smartphone POS service or a cart POS service, but will be referred to as a smartphone POS service below. The following description will focus on the operation for realizing shopping using the user terminal 200.

[0040] To use the smartphone POS service, a customer installs the smartphone POS app APB on a smartphone or the like that he or she owns, and makes it available as a user terminal 200. Alternatively, the customer borrows the user terminal 200 configured by installing the smartphone POS app APB on a tablet computer or the like from a store. Then, before entering the store, the customer starts information processing based on the smartphone POS app APB.

[0041] 9 and 10 are flowcharts of information processing by the processor 201 based on the smartphone POS application APB. First, as ACT11 shown in FIG. 9, the processor 201 executes a usage start process for starting use of the smartphone POS service. Details of the usage start process are not a feature of this embodiment, so a description thereof will be omitted. The usage start process may be the same process as that executed when a smartphone application for using a cloud service is started, for example. For example, as one process of the usage start process, the processor 201 executes a process for receiving user authentication by the cloud server 400. For example, as one process of the usage start process, the processor 201 starts the camera 205 and displays a scan screen on the touch panel 204 that prompts the customer to take a picture of the two-dimensional code TCI with the camera 205.

[0042] When the processor 401 in the cloud server 400 is accessed by the user terminal 200 in response to the execution of the above-mentioned start-of-use process, the processor 401 starts information processing according to the web POS application APD (hereinafter referred to as web POS processing) in order to provide the smartphone POS service to the user terminal 200. If the processor 401 is already executing web POS processing for another user terminal 200, the processor 401 starts a new web POS processing in parallel with the other web POS processing. In other words, the processor 401 may execute multiple web POS processing in parallel, each for a plurality of user terminals 200. In the following, when the term "user terminal 200" is used simply, it refers to the user terminal 200 that is the target of the web POS processing being explained.

[0043] FIG. 11 is a flowchart of the web POS process performed by the processor 401 based on the web POS application APD. As ACT41, the processor 401 executes a provision start process for starting provision of the smartphone POS service to the accessing user terminal 200. Details of the provision start process are not a feature of this embodiment, so a description will be omitted. The type of processing to be performed as the provision start process may be determined arbitrarily by, for example, the creator of the web POS application APD. The provision start process may be the same as the processing executed when a smartphone application for using a cloud service is started. For example, the processor 401 executes, as one process of the provision start process, a process for authenticating a customer who uses the smartphone POS service in cooperation with the above-mentioned use start process in the user terminal 200.

[0044] A customer carries the user terminal 200 and enters any store in which the store system 100 is installed. At this time, the customer photographs the two-dimensional code TCI with the camera 205 of the user terminal 200, thereby causing the user terminal 200 to read the check-in data represented by the two-dimensional code TCI.

[0045] When the processor 201 finishes the usage start process in ACT11 in FIG. 9, the processor 201 proceeds to ACT12. In ACT12, the processor 201 waits for the check-in data to be read. If the check-in data is read by photographing the two-dimensional code TCI with the camera 205, the processor 201 judges the result as YES and proceeds to ACT13.

[0046] As ACT13, the processor 201 requests the cloud server 400 to start a transaction. The processor 201 executes various requests to the cloud server 400, including this request, described below, by accessing the cloud server 400 using an access URL generated by adding arguments defined for each API to the basic URL of the API published for accepting those requests. However, some requests, such as a request to start a transaction, may be made without using the API.

[0047] For example, if the basic URL of an API related to processing for starting a transaction is defined as "xyz.cloud.co.jp / api / start", the processor 201 generates an access URL by adding a store code or the like represented in the check-in data as an argument, and uses this access URL to access the cloud server 400 from the mobile communication unit 209 via the communication network 500.

[0048] When the processor 401 in the cloud server 400 finishes the provision start process in ACT41 in FIG. 11, the processor 401 proceeds to ACT42. In ACT42, the processor 401 waits for a start request from the user terminal 200. Then, when the processor 401 receives access from the user terminal 200 via the communication network 500 using the access URL for the start request as described above, the processor 401 judges YES and proceeds to ACT43.

[0049] As ACT43, the processor 401 determines a transaction code for identifying a transaction to be started in response to the above-mentioned start request. For example, the processor 401 determines a code different from the transaction code for identifying another transaction as a new transaction code according to a predetermined rule.

[0050] In ACT44, the processor 401 generates transaction data DAD associated with the transaction to be started, and stores it in the auxiliary storage unit 403. If transaction data DAD generated by another Web POS process being executed in parallel has already been stored in the auxiliary storage unit 403, the processor 401 leaves the transaction data DAD as is and stores the newly generated transaction data DAD in the auxiliary storage unit 403. The processor 401 includes in the transaction data DAD generated here the transaction code determined in ACT43, the user code acquired in the provision start process in ACT41, and the store code included as an argument in the access URL for the start request. At this stage, the processor 401 does not include product data in the transaction data DAD. In ACT45, the processor 401 responds to the start request. For example, the processor 401 transmits predetermined response data to the user terminal 200 via the communication network 500. The processor 401 includes the transaction code determined in ACT43 in the response data.

[0051] After the processor 201 in the user terminal 200 requests the start of a transaction in ACT13 in FIG. 9, the process proceeds to ACT14. In ACT14, the processor 201 waits for a response to the request. Then, when the response data transmitted from the cloud server 400 as described above is received by the mobile communication unit 209, the processor 201 determines that the result is YES, and proceeds to ACT15. The processor 201 generates history data DAB in ACT 15. The processor 201 generates the history data DAB as data that includes the transaction code included in the response data but does not include the access URL, for example, and stores the history data DAB in the auxiliary storage unit 203.

[0052] If a customer wishes to register a product as a purchased product, the customer inputs the product code of the product into the user terminal 200. For example, the customer has the camera 205 read a barcode displayed on the product, which indicates the product code. Alternatively, the customer touches a button displayed on the touch panel 204 and associated with the product code. Alternatively, the customer operates the touch panel 204 to manually input the product code. If the customer wishes to change the quantity of a product registered as a purchased product, the customer performs a predetermined operation, for example, on the touch panel 204. If the customer wishes to remove a product registered as a purchased product from the purchased products, the customer performs a predetermined operation, for example, on the touch panel 204. If the customer wishes to finish registering the purchased product and pay for the purchased product, the customer performs a predetermined operation on the touch panel 204 to instruct payment. The customer performs other predetermined operations.

[0053] In ACT16, the processor 201 waits for the above-mentioned operations by the customer. The operation that the processor 201 waits for here may be determined as appropriate by, for example, the creator of the web POS application APD. If any of the operations that are targets of acceptance are performed, the processor 201 judges YES and proceeds to ACT17.

[0054] As ACT17, the processor 201 requests the cloud server 400 to perform processing according to the operation. For example, when the processor 201 requests the registration of a purchased item, the processor 201 accesses the cloud server 400 using an access URL generated by adding, for example, a product code as an argument to a basic URL of an API published for a registration request. For example, when the processor 201 requests the change in the quantity of a purchased item, the processor 201 accesses the cloud server 400 using an access URL generated by adding, for example, a product code and a changed quantity as arguments to a basic URL of an API published for a quantity change request. For example, when the processor 201 requests the exclusion of a purchased item, the processor 201 accesses the cloud server 400 using an access URL generated by adding, for example, a product code as an argument to a basic URL of an API published for an exclusion request. For example, when the processor 201 requests payment, the processor 201 accesses the cloud server 400 using an access URL generated by adding, for example, payment data representing the payment method to be applied as an argument to a basic URL of an API published for a payment request. Thus, by the processor 201 executing information processing based on the smartphone POS application APB, the computer with the processor 201 as its central part functions as a request means for output 1. In ACT18, the processor 201 updates the history data DAB stored in the auxiliary storage unit 203 so that it includes the access URL used in the request in ACT17.

[0055] After responding in ACT45 in FIG. 11, the processor 401 in the cloud server 400 proceeds to ACT46. In ACT 46, the processor 401 checks whether or not a process has been requested. If the processor 401 cannot check the event, it determines NO and proceeds to ACT 47. In ACT 47, the processor 401 checks whether the transaction data has been notified. If the processor 401 cannot check the event, it determines NO and returns to ACT 46. Thus, the processor 401, as ACT46 and ACT47, waits for processing to be requested or for transaction data to be notified.

[0056] If access is made using the access URL as described above, the processor 401 judges YES in ACT46 and proceeds to ACT48. As ACT48, the processor 401 executes processing according to the request. For example, when the processor 401 receives an access from an access URL for a registration request, the processor 401 adds product data including the product code included as an argument in the access URL to the transaction data DAD stored in the auxiliary storage unit 403. For example, when the processor 401 receives an access from an access URL for a quantity change request, the processor 401 finds product data including the product code included as an argument in the access URL from the transaction data DAD stored in the auxiliary storage unit 403, and changes the quantity included in the product data to the quantity included as an argument in the access URL. For example, when the processor 401 receives an access from an access URL for an exclusion request, the processor 401 finds product data including the product code included as an argument in the access URL from the transaction data DAD stored in the auxiliary storage unit 403, and deletes the product data from the transaction data DAD. For example, when processor 401 receives an access via an access URL for a payment request, it calculates the price of the purchased item based on transaction data DAD stored in auxiliary storage unit 403, and executes a predetermined process for settling the price using the payment method indicated by the payment data included as an argument in the access URL. However, these processes are merely examples, and other processes may be executed for the same request. By updating transaction data DAD through the above processes, processor 401 uses this transaction data DAD to manage the results of execution of multiple processes in association with one transaction identifier. Thus, by processor 401 executing information processing based on web POS application APD, the computer with processor 401 as its central part functions as a first processing means and a second management means.

[0057] In ACT49, the processor 401 responds to the currently received request. For example, the processor 401 transmits response data including screen data showing the contents of the changed transaction data to the user terminal 200 via the communication network 500. For example, when a predetermined transaction completion state is reached by the processing in ACT48, the processor 401 includes predetermined notification data for notifying the completion of the transaction in the response data. Note that the state that is the transaction completion state may be arbitrarily determined by, for example, the creator of the web POS application APD. As an example, it is assumed that the state in which the payment is completed is determined as the transaction completion state.

[0058] In ACT50, the processor 401 checks whether the transaction has been completed by the process executed in ACT48. If the transaction has not been completed, the processor 401 judges NO and returns to the standby state of ACT46 and ACT47. However, if the transaction has been completed, for example, when the payment has been normally completed in ACT48, the processor 401 judges YES in ACT50 and ends this web POS process.

[0059] After updating the history data DAB in ACT18 in FIG. 9, the processor 201 in the user terminal 200 proceeds to ACT19. In ACT 19, the processor 201 checks whether or not a response has been made to the processing requested in ACT 17. If the processor 401 cannot check the relevant event, it judges NO and proceeds to ACT 20. In ACT 20, the processor 201 checks whether or not a failure has occurred. If the processor 201 cannot check the event, it determines NO and returns to ACT 19. Thus, the processor 201 waits for a response or for a failure to occur in ACT19 and ACT20. Then, when the response data transmitted from the cloud server 400 as described above is received by the mobile communication unit 209, the processor 201 determines YES in ACT19 and proceeds to ACT21.

[0060] As ACT21, the processor 201 executes processing in response to the response from the cloud server 400. For example, when the processor 201 receives response data including data of a screen showing the contents of the changed transaction data as described above, the processor 201 causes the touch panel 204 to display the corresponding screen.

[0061] In ACT22, the processor 201 checks whether the transaction has been completed. If the response data does not include notification data for notifying completion of the transaction, the processor 201 judges NO and returns to the standby state of ACT16. That is, the processor 201 continues to wait for a new operation. The processor 201 then repeatedly executes ACT17 to ACT21 in response to the new operation. That is, every time the processor 201 requests a new process, it adds the access URL used for the request to the history data DAB. The processor 201 updates the history data DAB so that the access order of each access URL appears based on the description order of each access URL in the history data DAB. In this way, the processor 201 executes information processing based on the smartphone POS application APB, and the computer with the processor 201 as the central part functions as a recording means.

[0062] Now, if the processor 201 is unable to continue communication with the cloud server 400 due to a failure in the communication network 500 or a failure in the cloud server 400, the processor 201 judges YES in ACT20 and proceeds to ACT23 in Fig. 10. Thus, the processor 201 executes information processing based on the smartphone POS application APB, and the computer with the processor 201 as the central part functions as a judgment means.

[0063] As ACT23, the processor 201 requests the store server 1 to start processing the transaction interrupted by the above-mentioned failure. For example, the processor 201 establishes communication with the access point 4 based on information required for connecting to the access point 4 indicated in the check-in data, and then accesses the store server 1 via the access point 4 and the in-store communication network 5 using an access URL that includes a transaction code as an argument in a basic URL indicated in the check-in data as a processing for starting the proxy. As a result, for example, a user terminal 200 present in store A accesses the store server 1 included in the store system 100-1. Also, for example, a user terminal 200 present in store B accesses the store server 1 included in the store system 100-2.

[0064] When the processor 11 in the store server 1 receives the above-mentioned access from the user terminal 200 via the access URL for requesting the proxy start process, the processor 11 starts information processing according to the proxy POS application APA (hereinafter referred to as proxy POS processing) in order to provide the smartphone POS service to the user terminal 200 on behalf of the user terminal 200. If the processor 11 is already executing proxy POS processing for another user terminal 200, the processor 11 starts a new proxy POS processing in parallel with the other proxy POS processing. In other words, the processor 11 may execute multiple proxy POS processing in parallel, each for a plurality of user terminals 200. In the following description, when the term "user terminal 200" is used simply, it refers to the user terminal 200 that is the target of the proxy POS processing being explained.

[0065] FIG. 12 is a flowchart of the proxy POS process by the processor 11 based on the proxy POS application APA. As ACT61, the processor 11 executes an agency start process for starting the agency provision of the smartphone POS service to the accessing user terminal 200. For example, the processor 11 generates transaction data DAA that includes a transaction code included as an argument in the access URL and does not include product data, and stores the transaction data DAA in the auxiliary storage unit 13. If transaction data DAA generated by another agency POS process being executed in parallel has already been stored in the auxiliary storage unit 13, the processor 11 leaves the transaction data DAA as it is and stores the newly generated transaction data DAA in the auxiliary storage unit 13. The processor 11 responds to the start request as the ACT 62. For example, the processor 11 transmits predetermined response data to the user terminal 200 via the communication network 500.

[0066] After the processor 201 in the user terminal 200 requests the start of proxy action in ACT23 in FIG. 10, the process proceeds to ACT24. In ACT24, the processor 201 waits for a response to the request. If the response data transmitted from the store server 1 as described above is received by the mobile communication unit 209, the processor 201 determines that the result is YES, and proceeds to ACT25.

[0067] As ACT25, the processor 201 requests the store server 1 to perform processing based on the history data DAB. For example, the processor 201 selects the access URL used in the oldest access included in the history data DAB, and accesses the store server 1 using the access URL obtained by replacing the domain part of this access URL with the domain indicated in the check-in data. That is, if the access URL selected from the history data DAB is "xyz.cloud.co.jp / api / registration / 4946843523221" and the domain indicated in the check-in data is "192.168.1.zzz", the processor 201 accesses the store server 1 using the access URL "192.168.1.zzz / api / registration / 4946843523221".

[0068] After responding in ACT62 in FIG. 12, the processor 11 in the store server 1 proceeds to ACT63. In ACT 63, the processor 11 waits for a processing request. Then, if an access is made using the access URL as described above, the processor 11 judges YES in ACT 63 and proceeds to ACT 64.

[0069] The processor 11 executes processing in response to the request as ACT64. For example, the processor 11 executes information processing in the same manner as the processor 401 of the cloud server 400 executes as ACT48 in FIG. 11. However, the processor 11 updates the transaction data DAA stored in the auxiliary storage unit 13. The processor 11 responds to the currently received request as ACT 65. The processor 11 responds to the user terminal 200 in the same manner as the processor 401 of the cloud server 400 executes as ACT 49 in FIG. In ACT66, the processor 11 checks whether the transaction has been completed by the process executed in ACT64. If the transaction has not been completed, the processor 11 determines NO and returns to the standby state in ACT63.

[0070] After the processor 201 in the user terminal 200 updates the history data DAB in ACT25 in FIG. 10, the process proceeds to ACT26. In ACT26, the processor 201 waits for a response to the process requested in ACT25. Then, when the response data transmitted from the store server 1 as described above is received by the mobile communication unit 209, the processor 201 judges the result as YES and proceeds to ACT27.

[0071] In ACT27, the processor 201 checks whether the reproduction of the request based on the history data DAB is complete. For example, when the processor 201 executes ACT25 immediately before, if the access URL used in the most recent access included in the history data DAB is not selected, the processor 201 judges that the reproduction is not complete and judges NO, and repeats ACT25 and the following steps in the same manner as described above. However, at this time, in ACT25, the processor 201 selects the access URLs included in the history data DAB that have not yet been selected, in order of oldest. Thus, the processor 201 requests the store server 1 to perform the process that has already been requested to the cloud server 400 by the access URL included in the history data DAB in the same manner. Thus, the processor 201 executes information processing based on the smartphone POS application APB, and the computer with the processor 201 as the central part functions as a second request means.

[0072] When the processor 11 in the store server 1 is sequentially requested to perform the processes that have already been requested from the cloud server 400 as described above, the processor 11 is in a standby state of ACT63 in Fig. 12. Therefore, the processor 11 repeats ACT64 and ACT65 every time a process request is made.

[0073] In this manner, a further processing request based on the history data DAB is made from the user terminal 200 to the store server 1, and the processor 11 in the store server 1 executes processing in response to this request, whereby transaction data DAA including product data is generated in the auxiliary memory unit 13 of the store server 1 in the same manner as the transaction data DAD that was stored in the auxiliary memory unit 403 of the cloud server 400 at the time of the failure.

[0074] Meanwhile, while the processor 201 in the user terminal 200 is requesting the store server 1 to perform the process that has already been requested from the cloud server 400 as described above, even if a response is received from the store server 1, the processor 201 does not execute the corresponding process. Therefore, the generation of the above-mentioned transaction data DAA is executed in the background.

[0075] For example, if the processor 201 is in a state where it has selected the access URL used in the most recent access included in the history data DAB, it determines YES in ACT27 as reproduction is complete, and proceeds to ACT28. In ACT28, the processor 201 waits for an operation, similar to ACT16 in Fig. 9. The customer can continue to perform various operations as described above without being aware of the above-mentioned failure. If any of the operations that are subject to acceptance are performed, the processor 201 judges YES in ACT28 and proceeds to ACT29.

[0076] In ACT29, the processor 201 requests the store server 1 to perform processing in accordance with the operation. The processing by the processor 201 here is similar to that in ACT17 in Fig. 9, but generates an access URL including the basic URL indicated in the check-in data. In this way, the processor 201 executes information processing based on the smartphone POS application APB, and the computer with the processor 201 as the central part functions as a third request means.

[0077] When the processor 11 in the store server 1 receives access for a new request made in response to the operation in this manner, it determines YES in ACT63 in Fig. 12 and executes ACT64 and ACT65 as described above. As a result, the processor 11 further updates the transaction data DAA in response to the request that was not accepted by the cloud server 400. In this way, the processor 11 executes information processing based on the agent POS application APA, and the computer with the processor 11 as its central part functions as a second processing means and a second management means.

[0078] If the transaction is completed, for example, if the settlement is normally completed in ACT64, the processor 11 determines YES in ACT66 and proceeds to ACT67. As ACT67, the processor 11 notifies the cloud server 400 of the transaction data DAA. For example, the processor 11 transmits notification data including the transaction data DAA to the cloud server 400 via the in-store communication network 5, the gateway 3, and the communication network 500. If the above-mentioned failure has not yet been resolved and the notification of the transaction data cannot be completed, the processor 11 repeats the transmission of the notification data after a predetermined time. Alternatively, the cloud server 400 may publish an API that provides data indicating the operation status of the cloud server 400, and the processor 11 may use this API to check the operation status of the cloud server 400 and transmit the notification data after confirming that the failure has been resolved. Then, when the processor 11 completes the notification, it ends the proxy POS processing. Thus, the processor 11 executes information processing based on the proxy POS application APA, and the computer with the processor 11 as the central part functions as a notification means.

[0079] In the cloud server 400, when the processor 201 in the user terminal 200 determines that a failure has occurred in ACT20 in FIG. 9 due to the communication network 500, the processor 401 continues the proxy POS process as it is, but remains in the standby state of ACT46 and ACT47 in FIG. 11 since the processing request from the user terminal 200 is no longer made. In addition, when the processor 401 stops the proxy POS process being executed in response to the occurrence of some kind of failure in itself, it enters the standby state of ACT46 and ACT47 after recovery from the failure. Thus, in the cloud server 400, when the communication interface 404 receives the notification data transmitted from the store server 1 as described above, the processor 401 is in the standby state of ACT46 and ACT47. In response to the reception of the notification data including the transaction code related to the transaction that is the target of the proxy POS process, the processor 401 determines YES in ACT47 and proceeds to ACT51.

[0080] As ACT51, the processor 401 updates the transaction data DAD based on the notification data. For example, the processor 401 selects the transaction data DAD that includes the transaction code included in the notification data from the transaction data DAD stored in the auxiliary storage unit 403. The processor 401 then rewrites all of the product data included in the transaction data DAD to the product data in the notification data. The processor 401 then ends the proxy POS process. In other words, the processor 401 updates the transaction data DAD to data that represents the content of the transaction that has been completed on behalf of the store server 1. In this way, the processor 401 executes information processing based on the web POS application APD, and the computer with the processor 401 as its central part functions as an update means.

[0081] If there is no need to store the transaction data DAD related to the completed transaction in the cloud server 400, the processor 401 may, in ACT51, delete the transaction data DAD including the transaction code included in the notification data from the auxiliary storage unit 403. Alternatively, if journal data based on the transaction data DAD related to the completed transaction is to be stored in the cloud server 400, the processor 401 may, when determining YES in ACT50 or after completing ACT51, generate journal data based on the transaction data DAD and store it in the auxiliary storage unit 403, and delete the corresponding transaction data DAD.

[0082] After the processor 201 in the user terminal 200 requests processing in ACT 29 in FIG. 10, the process proceeds to ACT 30. In ACT 30, the processor 201 waits for a response to the process requested in ACT 29. Then, when the response data transmitted from the store server 1 in ACT 65 in FIG. 12 is received by the mobile communication unit 209, the processor 11 judges the result as YES and proceeds to ACT 31.

[0083] As ACT31, the processor 201 executes processing in response to the response from the store server 1. For example, if the processor 201 receives response data including data of a screen showing the contents of the changed transaction data, the processor 201 causes the touch panel 204 to display the corresponding screen. In ACT32, the processor 201 checks whether the transaction has been completed. If the response data does not include notification data for notifying the completion of the transaction, the processor 201 judges the result as NO and returns to the standby state of ACT28. After that, the processor 201 repeatedly executes ACT29 to ACT31 every time a customer performs an operation.

[0084] The processor 201 judges YES in ACT22 in FIG. 9 if the response data received from the cloud server 400 includes notification data for notifying the completion of the transaction, and judges YES in ACT32 in FIG. 10 if the response data received from the store server 1 includes notification data for notifying the completion of the transaction, and in either case returns to the standby state of ACT12 in FIG. 9.

[0085] As described above, the product sales processing system stores a history of requests to the cloud server 400 in the user terminal 200, and when a failure occurs that makes it impossible to cause the cloud server 400 to execute a process, the system causes the store server 1 to execute a process that has already been executed in the cloud server 400 based on the history, in response to a request from the user terminal 200. This allows the list of purchased products managed by the store server 1 using the transaction data DAA to be matched with the list of purchased products managed by the cloud server 400 using the transaction data DAD at the time of the abnormality. By having the store server 1 execute subsequent processes, the store server 1 can continue to process the transaction on its behalf. There is no need for cooperation between the cloud server 400 and the store server 1 to match the transaction data DAA and the transaction data DAD, and this makes it easy to switch servers when a failure occurs.

[0086] Furthermore, in the product sales system, when a transaction is interrupted in the cloud server 400 because it is being performed by the store server 1, the store server 1 completes the transaction and notifies the cloud server 400 of the result of the transaction. Based on the notification, the cloud server 400 can then complete the interrupted transaction.

[0087] This embodiment can be modified in various ways as follows. The information processing executed by the cloud server 400 and the store server 1 is not limited to information processing for product sales processing, and may be any information processing.

[0088] Cloud server 400 may be replaced with any other server device, such as a server device installed in a headquarters that manages multiple stores.

[0089] The store server 1 may be replaced with another server device provided in any facility other than a store.

[0090] When shopping is performed using the cart terminal 300 instead of the user terminal 200, the user terminal 200 can be read as the cart terminal 300. In other words, the processor 302 of the cart terminal 300 may execute information processing that is generally similar to the information processing performed by the processor 201 of the user terminal 200. However, in the case of the cart terminal 300, for example, reading of the check-in data may be omitted by storing in advance at least a part of the various data indicated in the check-in data in the main memory 303 or the auxiliary storage unit 304. The cart terminal 300 also accesses the cloud server 400 via the access point 4, the in-store communication network 5, the gateway 3, and the communication network 500.

[0091] When the user terminal 200 is loaned to a customer at a store, at least a portion of the various data indicated in the check-in data may be stored in advance in the main memory 202 or the auxiliary memory unit 203, thereby eliminating the need to read the check-in data.

[0092] The processing of the cloud server 400 or the processing of the store server 1 may be distributed among a plurality of server devices.

[0093] Requests and responses between the store server 1 and the user terminal 200 and cart terminal 300 may be mediated by another server device.

[0094] Each function realized by the processor 11, 201, 302, 401 through information processing can be realized in part or in whole by hardware that executes information processing not based on a program, such as a logic circuit, etc. Also, each of the above functions can be realized by combining the above hardware, such as the logic circuit, with software control.

[0095] Although some embodiments of the present invention have been described, these embodiments are presented as examples and are not intended to limit the scope of the invention. These novel embodiments can be implemented in various other forms, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their modifications are included in the scope and spirit of the invention, and are included in the scope of the invention and its equivalents described in the claims. [Explanation of symbols]

[0096] 100 (100-1, 100-2)... store system, 200... user terminal, 300... cart terminal, 400... cloud server, 500... communication network, 1... store server, 2... cashier, 3... gateway, 4... access point, 5... in-store communication network, 11, 201, 302, 401... processor, 12, 202, 303, 402... main memory, 13, 203, 304, 403... auxiliary memory unit, 14... communication interface, 15, 210, 308, 405... transmission path, 204, 305... touch panel, 205... camera, 206, 306... sound unit, 207... sensor group, 208, 307... wireless communication unit, 209... mobile communication unit, 301... barcode scanner, 404... communication interface.

Claims

1. An information processing system including a first server, a second server, and a client device, a first request means provided in the client device for requesting the first server to perform information processing in accordance with an operation; a first processing means provided in the first server and configured to execute information processing in response to a request made by the first request means; a first management means provided in the first server, for managing execution results of information processing by the first processing means in response to a plurality of requests from the first request means in association with an identical identifier; a recording means provided in the client device for recording a history of requests made by the first request means in association with the identifier; a determination means provided in the client device for determining that a failure has occurred in the first server; a second request means provided in the client device, for requesting, in response to the occurrence of a failure being determined by the determination means, in accordance with the history recorded by the recording means, the second server to perform information processing that was requested by the first request means before the occurrence of the failure, along with a notification of an identifier with which the history is associated; a third request means provided in the client device for requesting the second server to perform information processing in accordance with an operation performed after the request by the second request means is completed; a second processing means provided in the second server and configured to execute information processing in response to requests made by the second request means and the third request means; a second management means provided in the second server and managing execution results of information processing by the second processing means in response to a plurality of requests by the second request means and the third request means in association with an identifier notified by the second request means; a notification means provided in the second server, for notifying the first server of the execution result managed by the second management means together with the associated identifier after the request by the third request means regarding the identifier notified by the second request means is completed; an update means provided in the first server for updating the execution result managed by the first management means in association with the identifier notified by the notification means, with the execution result notified by the notification means; An information processing system comprising:

2. the first processing means and the second processing means execute information processing for registering a product designated by the client device as a purchased product and for settling the price of the registered purchased product; The information processing system according to claim 1 .

3. the first server is a cloud server; the second server is a local server provided in a facility where the client device is operated; 3. The information processing system according to claim 1 or 2.

4. A wide area network is used for communication between the client device and the first server; A short-range network is used for communication between the client device and the second server. An information processing system according to any one of claims 1 to 3.

5. a first request means for requesting a first server to perform information processing in accordance with an operation; a recording means for recording a history of requests made by the first request means in association with an identifier; A determination means for determining that a failure has occurred in the first server; a second request means for requesting a second server to perform information processing that was requested by the first request means before the occurrence of the failure, in response to the determination by the determination means and in response to the history recorded by the recording means, along with a notification of an identifier associated with the history; a third request means for requesting a second server to perform information processing in accordance with an operation performed after the request by the second request means is completed; A client device comprising:

6. A computer acting as a client device, a first request means for requesting a first server to perform information processing in accordance with an operation; a recording means for recording a history of requests made by the first request means in association with an identifier; A determination means for determining that a failure has occurred in the first server; a second request means for requesting a second server to perform information processing that was requested by the first request means before the occurrence of the failure, in response to the determination by the determination means and in response to the history recorded by the recording means, along with a notification of an identifier associated with the history; a third request means for requesting a second server to perform information processing in accordance with an operation performed after the request by the second request means is completed; An information processing program that enables the system to function as such.

Images