Systems, methods, and programs

Abstract

When a notification is sent to another device based on user actions on one device, and that other device is unable to receive the notification, the user operating the device will be notified more quickly that the other device is unable to receive the notification. [Solution] The system comprises a first terminal, a second terminal, a first server, and a second server. The system is configured such that the first server performs a first process, which includes having the second server, which is always connected to the second terminal, send a first notification to the second terminal, in response to user operations on the first terminal. The second server is capable of receiving a first response from the second terminal indicating that the second terminal has received the first notification, and sends a second response to the first server indicating that the first notification was successful or a third response indicating that the first notification failed, depending on whether the first response was received.

Description

Technical Field

[0001] The present disclosure relates to a system, a method, and a program.

Background Art

[0002] Patent Document 1 (Japanese Patent Application Laid-Open No. 2018-113578) discloses a technique for changing the settings of a game terminal from a terminal such as a smartphone via a server.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] When notifying another terminal based on a user operation on a certain terminal, when the other terminal is in a state where it cannot receive the notification, it is desired to notify the user operating the certain terminal earlier that the other terminal cannot receive the notification.

Means for Solving the Problems

[0005] (Configuration 1) A system including a first terminal, a second terminal, a first server, and a second server. The first server executes a first process including causing the second server, which can always be connected to the second terminal, to send a first notification to the second terminal in response to a user operation on the first terminal. The second server can receive a first response from the second terminal indicating that the second terminal has received the first notification, and sends a second response indicating that the first notification has succeeded or a third response indicating that the first notification has failed to the first server according to whether the first response has been received.

[0006] (Configuration 2) In configuration 1, the third response includes information indicating the cause of the failure of the first notification.

[0007] (Composition 3) In Configuration 1 or Configuration 2, when the second server sends a third response to the first server, if the second terminal is constantly connected to the second server, the second server sends the third response after a predetermined period of time has elapsed; if the second terminal is not constantly connected to the second server, the second server sends the third response before the predetermined period of time has elapsed.

[0008] (Composition 4) In any of the configurations 1 to 3, if the first server receives a second response from the second server, it will not allow the first terminal to send a notification to its user. If the first server receives a third response from the second server, it will allow the first terminal to send the notification.

[0009] (Composition 5) In any of configurations 1 to 4, the second terminal is configured to allow insertion of a virtual game card, and the first process includes inserting or removing a virtual game card from the second terminal.

[0010] (Composition 6) In any of Configurations 1 to 5, the first server performs a second process, including having the second server send a second notification to the second terminal, in response to user operations on the first terminal. If a request is made to the second server during the first process, the first server maintains a session with the second server. If a request is made to the second server during the second process, the first server terminates the session with the second server.

[0011] (Composition 7) In configuration 6, the second server, upon receiving a request for the second processing, does not send a notification to the first server indicating whether the second notification was successful or not, regardless of whether the second notification was successful or not.

[0012] (Composition 8) In configuration 6 or 7, the second server does not add the first notification to the queue, but does add the second notification to the queue.

[0013] (Composition 9) A method used in a system for enabling communication between a first terminal and a second terminal via a first server and a second server, the method comprising: causing the first server to perform a first process in response to a user operation on the first terminal, which includes causing the second server, which is always connected to the second terminal, to send a first notification to the second terminal; causing the second server to receive a first response from the second terminal indicating that the second terminal has received the first notification; and causing the second server to send a second response indicating that the first notification was successful or a third response indicating that the first notification failed to the first server, depending on whether or not the first response was received.

[0014] (Composition 10) In configuration 9, the third response includes information indicating the cause of the failure of the first notification.

[0015] (Composition 11) In configuration 9 or configuration 10, the method includes the steps of: when the second server sends a third response to the first server, causing the second server to send a third response after a predetermined period of time has elapsed if the second terminal is always connected to the second server; and causing the second server to send a third response before the predetermined period of time has elapsed if the second terminal is not always connected to the second server.

[0016] (Composition 12) In any of the configurations 9 to 11, the method includes the steps of: when the first server receives a second response from the second server, preventing the first terminal from performing notification to the user of the first terminal; and when the first server receives a third response from the second server, causing the first terminal to perform notification.

[0017] (Composition 13) In any of configurations 9 to 12, the second terminal is configured to allow insertion of a virtual game card, and the first process includes inserting or removing a virtual game card from the second terminal.

[0018] (Composition 14) In any of Configurations 9 to 13, the method includes causing the first server to execute a second process including causing the second server to give a second notification to the second terminal in response to a user operation on the first terminal, holding a session with the second server after requesting the first process from the second server, and ending the session with the second server based on having requested the second process from the second server.

[0019] (Configuration 15) In Configuration 14, the method includes causing the second server not to give a notification indicating that the second notification has succeeded to the first server even when the second notification has succeeded, based on having received a request for the second process.

[0020] (Configuration 16) In Configuration 14 or 15, the method further includes causing the second server to add the second notification to a queue while not adding the first notification to the queue.

[0021] (Configuration 17) A program used in a second server that is always connectable to a second terminal and has one or more processors in a system for communicating between a first terminal and a second terminal via the first server and the second server, the program causing the one or more processors to cause the second terminal to give a first notification based on a first process executed by the first server in response to a user operation on the first terminal, receive a first response from the second terminal indicating that the second terminal has received the first notification, and send a second response indicating that the first notification has succeeded or a third response indicating that the first notification has failed to the first server according to whether the first response has been received.

[0022] (Configuration 18) In Configuration 17, the third response includes information indicating a cause indicating that the first notification has failed.

[0023] (Configuration 19) In configuration 17 or configuration 18, the program causes one or more processors to perform the following steps: when the second server sends a third response to the first server and the second terminal is always connected to the second server, the program causes the second server to send a third response after a predetermined period of time has elapsed; and when the second server sends a third response to the first server and the second terminal is not always connected to the second server, the program causes the second server to send a third response before a predetermined period of time has elapsed.

[0024] (Composition 20) In any of configurations 17 to 19, the second terminal is configured to allow insertion of a virtual game card, and the first process includes inserting or removing a virtual game card from the second terminal.

[0025] (Composition 21) In any of the configurations 17 to 20, the program causes one or more processors to perform the following steps: to send a second notification to the second terminal based on a second process executed by the first server in response to a user operation on the first terminal; to maintain a session with the first server after receiving a request for the first process from the first server; and to terminate the session with the first server after receiving a request for the second process from the first server.

[0026] (Composition 22) In configuration 21, the program causes one or more processors to perform a step in which, based on having received a request for the second processing, they do not notify the first server that the second notification was successful, even if the second notification was successful.

[0027] (Composition 23) In configuration 22, the program causes one or more processors to perform the step of adding the second notification to the queue, while not adding the first notification to the queue. [Brief explanation of the drawing]

[0028] [Figure 1]This is a schematic diagram showing an example of a system according to this embodiment. [Figure 2] This is a schematic diagram showing an example of the hardware configuration of a always-on server according to this embodiment. [Figure 3] This is a schematic diagram showing an example of the hardware configuration of a game terminal according to this embodiment. [Figure 4] This is a schematic diagram showing an example of the hardware configuration of a service provision server according to this embodiment. [Figure 5] This is a flowchart illustrating an example of how the service provider server processes API requests in Embodiment 1. [Figure 6] This is a sequence diagram illustrating an example of a successful notification from a always-on server to a game terminal. [Figure 7] This is a sequence diagram illustrating an example of a failure in notification from a always-on server to a game terminal. [Figure 8] This is a flowchart illustrating an example of how the service provider server processes API requests in Embodiment 2. [Figure 9] This sequence diagram illustrates an example of a successful configuration change process in second-mode communication. [Figure 10] This sequence diagram illustrates an example of what happens when a configuration change process fails during second-mode communication. [Modes for carrying out the invention]

[0029] This embodiment will be described in detail with reference to the drawings. Note that identical or corresponding parts in the drawings are denoted by the same reference numerals, and their descriptions will not be repeated.

[0030] <Embodiment 1> [A. Overview] An example configuration of system 100 according to this embodiment will be described. Figure 1 is a schematic diagram showing an example of system 100 according to this embodiment. System 100 is a system that provides services to game terminals 30A, 30B and other information terminals not shown, for example, using a always-on server Pe and a service provision server SP.

[0031] System 100 includes, for example, game terminals 30A and 30B, a service provider server SP, and a always-on server Pe. Each component in System 100 is connected to one another via a network NW. The network NW is, for example, the internet.

[0032] Each of the game terminals 30A and 30B could be, for example, a game-specific information processing device for providing games to users. Hereafter, game terminals 30A and 30B will be collectively referred to as "game terminal 30" without distinction.

[0033] In this embodiment, the always-on server Pe provides a persistent connection service. The always-on connection service is a service that enables communication between the always-on server Pe and the game terminal 30 at any time, for example, by maintaining the connection between the always-on server Pe and the game terminal 30. The always-on connection service provides a connection method in which the game terminal 30 always maintains a connection with the always-on server Pe as long as the game terminal 30 is able to connect to the network NW. Hereinafter, the state in which the connection between the always-on server Pe and the game terminal 30 is maintained will be referred to as the "always-on state". For example, when predetermined conditions are met, the always-on server Pe may send a notification to the game terminal 30 in the always-on state according to those conditions. The game terminal 30 may be configured to be in the always-on state basically when connected to the network NW, or it may be configured to be in the always-on state based on predetermined conditions such as user operation.

[0034] In this embodiment, the service provider server SP is a server that performs processing specialized for a specific service. This specific service may be various services, such as a service that allows multiple game terminals 30 to exchange information, a service that allows other information processing terminals (not shown) to manage the state of the game terminals 30, or a service that modifies programs within multiple game terminals 30 in response to commands from a development terminal. The services provided by the service provider server SP are not limited to these services and may include other services. The always-on connection service provided by the always-on connection server Pe and the specific service provided by the service provider server SP are independent services.

[0035] Embodiment 1 describes an example in which the service provided to the service provider server SP is a virtual game card service. The virtual game card service is a service that virtually realizes a usage mode in which, for example, one game card is selectively inserted and used among multiple game terminals 30. The virtual game card service may also be a service that provides virtual game card insertion and removal processing to the game terminals 30.

[0036] [B. Hardware Configuration Example] In the following section, using Figures 2 to 4, we will describe an example of the hardware configuration of the always-on server Pe, the game terminal 30, and the service provider server SP that constitute the system 100 according to this embodiment.

[0037] Figure 2 is a schematic diagram showing an example of the hardware configuration of an always-on server Pe according to this embodiment. Referring to Figure 2, the always-on server Pe includes a communication unit 23, one or more processors 24, memory 25, and storage 26. These components are connected to each other via a bus 27 so that data can be communicated with each other. The always-on server Pe may be a dedicated server for providing always-on services, or it may be implemented using a general-purpose server, or it may be configured by combining multiple information processing terminals.

[0038] The communication unit 23 communicates with other information processing terminals included in the system 100 via a network NW. The communication unit 23 may have at least one of the hardware necessary for wired communication and the hardware necessary for wireless communication. In addition, all or part of the processing of the communication unit 23 may be implemented by the processor 24.

[0039] Processor 24 is a processing entity for executing processing provided by the always-on server Pe. In this disclosure, the term "processor" means, for example, a processing circuit such as a CPU (Central Processing Unit), MPU (Micro Processing Unit), or GPU (Graphics Processing Unit). The term "processor" also includes processing circuits that execute processing according to instruction codes written in a program, processing circuits that integrate multiple functions such as a SoC (System on Chip), and hardwired circuits.

[0040] Memory 25 is a volatile storage device accessible by the processor 24, and may include, for example, DRAM (Dynamic Random Access Memory) or SRAM (Static Random Access Memory). Storage 26 is a non-volatile storage device accessible by the processor 24, and may include, for example, a hard disk or flash memory. Storage 26 may also be a storage medium that can be attached to and removed from the always-on server Pe, such as an optical disc and cartridge.

[0041] Storage 26 may store a management program 261, always-on connection information 262, and a communication interface program 263. The processor 24, for example, reads the management program 261 and the communication interface program 263, loads them into memory 25, and executes them. In this specification, the term “memory” includes at least both volatile memory and non-volatile storage.

[0042] The management program 261 is, for example, a program for managing the always-on game terminal 30. The management program 261 may also include a process for causing the always-on server Pe to send notifications to the always-on game terminal 30.

[0043] The always-on connection information 262 is information that can identify a game terminal 30 that is always connected. For example, the always-on connection information 262 may be a table for managing the identification information of a game terminal 30 that is always connected. The game terminal 30 may be always connected or not always connected depending on the timing. For example, the game terminal 30 may be not always connected when the power is off, when it is not connected to the network NW, or when it receives a command from the user not to connect to the always-on connection server Pe. The always-on connection server Pe, for example, obtains the identification information of a game terminal 30 that is always connected at predetermined intervals and updates the always-on connection information 262.

[0044] The communication interface program 263 is a program that implements an API (Application Programming Interface) for providing the functions of the always-on server Pe to external parties. For example, the API is made public to users, developers, etc., as information to allow other information processing terminals to use the functions of the always-on server Pe. In this embodiment, the always-on server Pe receives requests from other information processing terminals to use the functions of the always-on server Pe via the API. For example, based on the fact that the always-on server Pe has received a request from the service provider server SP via the API, it may notify the always-on game terminal 30 according to the content of the request from the service provider server SP. After receiving the API request described in Embodiment 1, the always-on server Pe may maintain a session with the information processing terminal that made the API request.

[0045] Figure 3 is a schematic diagram showing an example of the hardware configuration of a game terminal 30 according to this embodiment. The game terminal 30 includes a display 31, a communication unit 33, one or more processors 34, memory 35, and storage 36, all of which are connected to each other via a bus 37 in a manner that enables data communication.

[0046] The always-on connection program 361 is a program for using the always-on connection service. The game terminal 30 may, for example, run the always-on connection program 361 to be controlled to an always-on connection state, or to perform processing in response to notifications received from the always-on connection server Pe while in an always-on connection state.

[0047] The virtual game card program 362 is a program for using the virtual game card service. The processing performed by the virtual game card program 362 may include, for example, at least one of the following: setting the state of the game terminal 30 itself to a state in which a virtual game card is inserted, and setting it to a state in which a virtual game card is removed. The setting process may be performed based on user operation on the game terminal 30 itself, or in response to a request from another information processing terminal, including a service provision server SP.

[0048] The game terminal 30, for example, executes a virtual game card program 362 to determine whether it has the right to execute a virtual game card. If a virtual game card is inserted, the game terminal 30 may determine that it has the right to execute the virtual game card and execute the virtual game card in response to user input. If a virtual game card is not inserted, the game terminal 30 may determine that it does not have the right to execute the virtual game card and may prohibit the execution of the virtual game card, or delete the program and data for executing the virtual game card from the storage 36.

[0049] Figure 4 is a schematic diagram showing an example of the hardware configuration of a service provision server SP according to this embodiment. Referring to Figure 4, the service provision server SP includes a communication unit 43, one or more processors 44, memory 45, and storage 46, all connected to each other via a bus 47 for data communication. The service provision server SP may be a dedicated server for providing a specific service, or it may be implemented using a general-purpose server, or it may be configured by combining multiple information processing devices.

[0050] The service provision program 461 is a program for executing a specific service provided by the service provision server SP. The specific service may include, for example, a service that includes sending notifications to at least one game terminal 30. In Embodiment 1, the specific service is a virtual game card service, so the service provision server SP manages the insertion status of the virtual game card in the game terminal 30. The service provision server SP may execute the service provision program 461 to cause a game terminal 30 to perform the above-described configuration process.

[0051] In Embodiment 1, the service provider server SP provides a service that remotely inserts and removes virtual game cards from other game terminals 30 in response to user operations on a certain information processing terminal. In this case, the service provider server SP in Embodiment 1 utilizes the functions of the always-on server Pe via an API request to notify the target game terminal 30 to perform a setting process. That is, the always-on server Pe provides the service provider server SP with a function to send a notification to the target game terminal 30 that includes a command to perform a setting process. In Embodiment 1, the setting process is a process that changes the insertion status of a virtual game card in a certain game terminal 30, but is not limited to this. The setting process may differ depending on the content of the specific service provided by the service provider server SP. For example, if the specific service is a monitoring service that supervises the game terminal 30, the setting process may include setting a play time limit for the game terminal 30, setting a password to change that time limit, etc.

[0052] [Example of processing a C.API request] Figure 5 is a flowchart illustrating an example of API request processing by the service provider server SP in Embodiment 1. The service provider server SP determines whether the conditions for making a request via API to the always-on server Pe have been met (step S101). The conditions for making a request via API may be, for example, receiving a service request from another information processing terminal to cause the game terminal 30 to perform configuration processing. If the conditions are not met (NO in step S101), the service provider server SP terminates processing.

[0053] If the condition is met (YES in step S101), the service provider server SP makes a request to the always-on server Pe via API (step S102) and terminates the process. In step S102, the service provider server SP sends the destination information of the game terminal 30 to be notified and the content of the notification to the always-on server Pe.

[0054] Next, we will explain a specific example using a sequence diagram. Figures 6-8 below illustrate an example where a service provider server SP receives a request for virtual game card services from a game terminal 30B. The request from game terminal 30B for virtual game card services is to remove a specific virtual game card inserted in game terminal 30A. In this case, game terminal 30A is notified of a command to perform a setting process that sets the specific virtual game card to a removed state. As mentioned above, the setting process may be a process other than the process of setting the specific virtual game card to a removed state, and the specific service provided by the service provider server SP may be any other service.

[0055] Figure 6 is a sequence diagram illustrating an example of a successful notification from the always-on server Pe to the game terminal 30A. The game terminal 30B makes a service request to the service provider server SP, for example, a service requesting the removal of a specific virtual game card inserted in the game terminal 30A (step S201). Upon receiving the service request, the service provider server SP makes a request via API to utilize the functions of the always-on server Pe (step S202). In step S202, the service provider server SP sends destination information indicating the game terminal 30A and notification content, for example, a request to execute a setting process to remove the virtual game card, to the always-on server Pe. In Embodiment 1, the always-on server Pe maintains a session with the service provider server SP even after step S202.

[0056] Based on the request received via the API, the always-on server Pe checks whether the game terminal 30A indicated in the received destination information is in an always-on state, for example by referring to the always-on connection information 262. In the example in Figure 6, the always-on server Pe confirms that the game terminal 30A is in an always-on state. After confirming the always-on connection status of the game terminal 30A, the always-on server Pe issues a notification including an instruction to execute the configuration process (step S203).

[0057] The game terminal 30A, which is always connected, makes a notification response based on having received a notification from the always-connected server Pe (step S204). The notification response is a response indicating whether the notification from the always-connected server Pe to the game terminal 30A was successful or not. In the example in Figure 6, the game terminal 30A receives the notification successfully. Therefore, the game terminal 30A makes a notification response that includes information indicating that the notification was received successfully. The notification response in step S204 only needs to include information that allows the game terminal 30A to identify that the notification was received successfully, and one example of this is an ACK signal. The always-connected server Pe makes a response to the service provider server SP indicating that the notification was successful (step S205). At this time, in this embodiment, the service provider server SP does not make any notification to the game terminal 30B based on having received the response in step S205. However, the service provider server SP may make a response to the game terminal 30B indicating that the notification was successful based on having received the response in step S205. The response in step S205 may also be an ACK signal, similar to step S204.

[0058] The following describes an example of processing for a specific service provided by the service provider server SP in steps S206 to S208. These processes may be independent of the requests in S201 and S202, and may not be performed depending on the type of service, or different processes may be performed. The game terminal 30A makes configuration changes according to the content of the notification received in step S203 (step S206). That is, if the specific service is a virtual game card service, as part of using the virtual game card service, the game terminal 30A executes the virtual game card program 362 to set the state of the game terminal 30A itself to a state in which the specific virtual game card has been removed. For example, the game terminal 30A executes the virtual game card program 362 and notifies the service provider server SP of the result indicating whether the configuration process to remove the specific virtual game card was successful or not. The service provider server SP receives the notification from the game terminal 30A indicating whether the configuration process was successful or not, and sends a response to the game terminal 30B indicating whether the configuration process was successful or not in the game terminal 30A (step S207). The game terminal 30B reports the result indicating whether the configuration process was successful or not (step S208). In other service examples, the game terminal 30A may request the service provider server SP to notify the game terminal 30B via the always-on server Pe whether the process corresponding to S206 was successful or not. That is, after performing a predetermined process, the game terminal 30A sends information indicating the result of the process to the service provider server SP, and the service provider server SP may notify the game terminal 30B via the always-on server Pe in a manner corresponding to steps S202 to S205 described above. The process from step S206 onwards may be switched depending on whether the terminal corresponding to the game terminal 30B is a terminal that can connect to the always-on server Pe.

[0059] Figure 7 is a sequence diagram illustrating an example of a failure in notification from the always-on server Pe to the game terminal 30A. Figure 7 shows two examples of failures in notification to the game terminal 30A.

[0060] Steps S211 to S216 describe the first example of a case where notification to the game terminal 30A fails when the game terminal 30A is not in a constantly connected state. Steps S221 to S227 describe the second example of a case where notification to the game terminal 30A fails when the game terminal 30A is in a constantly connected state.

[0061] The processes in steps S211 and S212 correspond to the processes in steps S201 and S202, respectively, so we will not repeat the explanation. In Embodiment 1, the session between the service provider server SP and the always-on server Pe is maintained even after step S212. In step S213, unlike step S203, the always-on server Pe checks, for example, the always-on connection information 262 to confirm that the game terminal 30A is not in an always-on state (step S213).

[0062] When the always-on server Pe determines that the game terminal 30A is not in a always-on state, it sends a response to the service provider server SP indicating that notification to the game terminal 30A failed (step S214). Since the session between the always-on server Pe and the service provider server SP is maintained even after step S212, the always-on server Pe can execute the process in step S214 in a short period of time after receiving the processing in step S212. This short period of time may be, for example, a period of 200ms or less. An example of the response in step S214 may be a NACK signal.

[0063] Furthermore, the service provider server SP sends a command to the game terminal 30B to notify it that the notification failed (step S215). The game terminal 30B then notifies it that the configuration change on the game terminal 30A failed (step S216).

[0064] The failure response transmitted in steps S214 and S215 may include information indicating the cause of the failure. In the example of steps S214 and S215, for example, the failure response may include information indicating that the game terminal 30A was not in a constantly connected state. In step S216, the information indicating the cause of the failure may be notified to the user by the game terminal 30B.

[0065] Next, we will explain a second example of what happens when notification to the game terminal 30A fails while the game terminal 30A is always connected. The processes in steps S221 and S222 correspond to the processes in steps S201 and S202, respectively, so we will not repeat the explanation.

[0066] In step S223, the always-on server Pe fails to send a notification to the game terminal 30A. The reasons for the failure to send a notification to the game terminal 30A in step S223 may include, for example, that although the game terminal 30A is in an always-on state, some kind of failure occurs in the game terminal 30A or the network NW, or that although the always-on connection information 262 stores that the game terminal 30A is in an always-on state, at the start of processing in step S223, the game terminal 30A is disconnected from the network NW, for example, and thus the game terminal 30A is no longer in an always-on state. If the sending of a notification from the always-on server Pe to the game terminal 30A fails due to these failures, the always-on server Pe uses a timeout process to determine that the notification has failed to be sent.

[0067] If the always-on server Pe does not receive a notification response from the game terminal 30A corresponding to S204 within the period D1 elapsed between receiving a request via API from the service provider server SP in step S222, it sends a response indicating failure (step S224). Period D1 may be, for example, 10 seconds. The processes in steps S224 to S226 correspond to the processes in steps S214 to S216, respectively, so the explanation will not be repeated. This allows system 100 to notify game terminal 30B that notification to game terminal 30A has failed. For example, if there is an error in the notification content received from the always-on server Pe, game terminal 30A may send information to the always-on server Pe indicating that it failed to receive the notification. If the always-on server Pe receives information from game terminal 30A indicating that it failed to receive the notification before period D1 elapses, it may send a response indicating failure to the service provider server SP.

[0068] <Embodiment 2> Embodiment 1 describes an example where a request to change the settings of the game terminal 30A is made via an API. The API for using the functions of the always-on server Pe may be configured to accept multiple types of requests. Hereafter, the request made via the API described in Embodiment 1 will be referred to as the "first request," and the communication described in Figures 6 and 7, which is executed by the first request, will be referred to as "first mode communication." Furthermore, hereafter, the communication that occurs when a second request different from the first request described in Embodiment 2 is made will be referred to as "second mode communication."

[0069] Unlike the first mode of communication, the second mode of communication does not maintain a session between the always-on server Pe and the service provider server SP after the second request; for example, it may be communication that terminates the session. In Embodiment 2, the service provider server SP can select between the first mode of communication and the second mode of communication by changing the type of request via the API. Note that in Embodiment 2, descriptions of configurations that overlap with Embodiment 1 will not be repeated.

[0070] The second mode of communication may, for example, be used to notify a number of game terminals 30 that is greater than the number of game terminals 30 notified by the first mode of communication. The second mode of communication may be used, for example, to provide a developer service that performs batch processing on dozens or more game terminals 30 connected to the always-on server Pe. The batch processing may be, for example, a process to fix bugs in a program. In this case, the service provided by the service provider server SP may be, for example, a developer service that supports maintenance for multiple game terminals 30. When the always-on server Pe notifies the game terminals 30 by using the second mode of communication, it notifies each game terminal 30 using a queue.

[0071] The following describes an example in which a developer makes a service request to a service provider server SP in order to execute batch processing on a game terminal 30 that is always connected. Figure 8 is a flowchart illustrating an example of how the service provider server SP processes an API request in Embodiment 2. In Embodiment 2, the service provider server SP executes the flowchart in Figure 8 instead of the flowchart shown in Figure 5.

[0072] In Embodiment 2, when the conditions for making a request via API to the always-on server Pe are met (YES in step S301), the service provider server SP determines whether the API request from the game terminal 30 that was made in step S301 corresponds to first mode communication or second mode communication (step S302).

[0073] The communication mode to which an API request corresponds may be predetermined depending on the content of the successful API request. If the API request corresponds to the first mode of communication, the service provider server SP makes a first request via the API to the always-on server Pe (step S303) and terminates processing. When a first request is made, the communication described in Figures 6 and 7 also takes place in the system 100 in Embodiment 2.

[0074] If the API request corresponds to second-mode communication, the service provider server SP makes a second request via the API to the always-on server Pe (step S304) and terminates processing. At this time, the service provider server SP may send a re-notification flag to the always-on server Pe in addition to the destination information of the game terminal 30 to be notified and the content of the notification. The storage 26 in Embodiment 2 may further include a re-notification table for holding notifications for which the re-notification flag is TRUE. The re-notification table is a table that stores notifications that should be re-notified if notification to the game terminal 30 fails in second-mode communication. When a second request is made, the system 100 in Embodiment 2 performs the communication described in Figures 9 and 10.

[0075] [D. Processing flow via second mode communication] The following describes an example of communication in the second mode. Figure 9 is a sequence diagram illustrating an example where a notification to change settings is successful in second mode communication. Figures 9 and 10 show only the communication between game terminal 30A, one of several game terminals 30 that require batch processing, and an information processing terminal. The information processing terminal may be a terminal used by a developer for program development, or it may be an information processing terminal such as a smartphone, tablet, or PC.

[0076] The information processing terminal makes a service request to the service provider server SP to change the settings of multiple game terminals 30, including game terminal 30A (step S401). The service provider server SP determines, by executing the flowchart in Figure 8, that the API request that was fulfilled in step S401 corresponds to second-mode communication. The service provider server SP sends a second request based on the service request (step S402). In step S402, the service provider server SP sends a data package to the always-on server Pe that includes destination information for all game terminals 30 subject to notification, the content of the notification indicating the execution command for batch processing, and a re-notification flag, as explained in step S304. If the re-notification flag is TRUE, the always-on server Pe, upon receiving the data package, may save the notification to the re-notification table.

[0077] The always-on server Pe responds to the service provider server SP upon receiving the second request (step S403). In the second mode of communication, the session between the service provider server SP and the always-on server Pe ends based on the completion of the response in step S403. Note that the response in step S403 is not required, and the service provider server SP may terminate the session with the always-on server Pe based on the completion of the second request. The always-on server Pe adds the information in the data package received from the service provider server SP to a queue (step S404). The queue may have, for example, a FIFO (First In First Out) data structure. Multiple notifications corresponding to each of the multiple game terminals 30 that are destinations are sequentially added to the queue.

[0078] The always-on server Pe retrieves a notification addressed to game terminal 30A from the queue and sends the notification to game terminal 30A (step S405). The processing in step S406 corresponds to the processing in step S204. Also, the processing in steps S407 to S409 corresponds to the processing in steps S206 to S208 respectively, so the explanation will not be repeated.

[0079] Next, Figure 10 is a sequence diagram illustrating an example of a case where a notification to perform a setting change fails in second-mode communication. The processes in steps S411 to S415 correspond to the processes in steps S401 to S405, respectively, so the explanation will not be repeated. In the example in Figure 10, the game terminal 30A does not respond to the notification shown in step S405. That is, the game terminal 30A fails to send and receive the notification in step S405 due to the various reasons mentioned above.

[0080] For example, the game terminal 30A sends information indicating that it failed to receive the notification (step S416). The always-on server Pe determines, through the processing in step S416, that the game terminal 30A failed to receive the notification. In addition, if the always-on server Pe does not receive the notification response shown in step S406 within a predetermined period after notifying the game terminal 30A in step S415, it may also determine that the game terminal 30A failed to receive the notification. If the re-notification flag for the notification retrieved from the queue in step S415 is TRUE, the always-on server Pe sends the notification again, for example, when the game terminal 30A successfully reconnects to the always-on server Pe (step S417). That is, in step S417, the always-on server Pe waits for the game terminal 30A to successfully reconnect to the always-on server Pe before sending the notification shown in S415.

[0081] After the service provider server SP makes the second request (step S412), it determines that the configuration change has failed if certain conditions are met (step S418). These conditions include, for example, not receiving a notification response from the game terminal 30A within a predetermined period. Alternatively, the conditions may also include receiving a response from the game terminal 30A indicating that the configuration change has failed. The processes in steps S419 and S420 correspond to the examples of configuration change failures in steps S207 and S208, respectively, and therefore will not be repeated in this explanation.

[0082] [E. Other variations] There may be an upper limit on the number of game terminals 30 that can be notified simultaneously by the first request. In this case, when a first request is made destined for more than the upper limit number of game terminals 30, the always-on server Pe may automatically process it using the second mode of communication.

[0083] Whether a service request corresponds to a particular communication mode is not predetermined based on the type of service request. Instead, the service provider server SP may decide whether to make a first request or a second request based on the content of the service request each time it receives one. For example, the service provider server SP may determine the type of API request to be made based on the number of game terminals 30 that need notification in response to the service request. Specifically, the service provider server SP may decide to make a first request if the number of destinations is less than a predetermined number, and decide to make a second request if the number of destinations is equal to or greater than the predetermined number. Furthermore, the first and second requests may be used interchangeably by the service provider server SP within the same service, depending on the content of the service request. Moreover, the system 100 may include multiple service provider servers SP, each providing different services, and it may be predetermined whether to make a first request or a second request for each of these multiple service provider servers.

[0084] The embodiments disclosed herein should be considered in all respects to be illustrative and not restrictive. The scope of the present invention is indicated by the claims rather than by the foregoing description, and all modifications within the meaning and scope equivalent to the claims are intended. [Explanation of symbols]

[0085] 23,33,43 Communication section, 24,34,44 Processor, 25,35,45 Memory, 26,36,46 Storage, 27,37,47 Bus, 30,30A,30B Game terminal, 31 Display, 100 System, 261 Management program, 262 Always-on connection information, 263 Communication interface program, 361 Always-on connection program, 362 Virtual game card program, 461 Service provision program, D1 Period, NW Network, Pe Always-on connection server, SP Service provision server.

Claims

1. It is a system, The first terminal and The second terminal and The first server and A second server is provided, The first server performs a first process, which includes having the second server, which is always connected to the second terminal, send a first notification to the second terminal, in response to user operations on the first terminal, and the second server, The second terminal can receive a first response indicating that the second terminal has received the first notification. A system that, depending on whether or not the first response has been received, sends to the first server a second response indicating that the first notification was successful or a third response indicating that the first notification failed.

2. The system according to claim 1, wherein the third response includes information indicating the cause of the first notification failure.

3. When the second server sends the third response to the first server, If the second terminal is in constant connection with the second server, after a predetermined period of time has elapsed, the third response is sent. The system according to claim 1 or 2, wherein if the second terminal is not in constant connection with the second server, the third response is transmitted before the predetermined period elapses.

4. The first server is, When the second response is received from the second server, the first terminal is not instructed to perform notification to the user of the first terminal. The system according to claim 1 or claim 2, wherein when the second server receives the third response, the first terminal is instructed to perform the notification.

5. The second terminal is configured to allow the insertion of a virtual game card, The system according to claim 1 or claim 2, wherein the first process includes inserting or removing a virtual game card from the second terminal.

6. The first server is, The second process, which includes having the second server send a second notification to the second terminal, is executed in response to user operations on the first terminal. When a request is made to the second server in the first process, a session with the second server is maintained. The system according to claim 1 or 2, wherein when a request is made to the second server in the second processing, the session with the second server is terminated.

7. The system according to claim 6, wherein the second server, based on having received a request for the second processing, does not notify the first server of the result of whether or not the second notification was successful, regardless of whether or not the second notification was successful.

8. The system according to claim 6, wherein the second server does not add the first notification to the queue, but adds the second notification to the queue.

9. A method used in a system that enables communication between a first terminal and a second terminal via a first server and a second server, The aforementioned method, The first server is instructed to perform a first process, which includes causing the second server, which is always connected to the second terminal, to send a first notification to the second terminal, in response to a user operation on the first terminal. The steps include causing the second server to receive a first response from the second terminal indicating that the second terminal has received the first notification, A method comprising the step of causing the second server to send to the first server a second response indicating that the first notification was successful or a third response indicating that the first notification failed, depending on whether or not the first response has been received.

10. The method according to claim 9, wherein the third response includes information indicating the cause of the first notification failure.

11. The method described above includes the case where the second server sends the third response to the first server, The second server is instructed to send the third response after a predetermined period of time has elapsed, if the second terminal is in constant connection with the second server. The method according to claim 9 or 10, further comprising the step of causing the second server to send the third response before the predetermined period elapses if the second terminal is not in constant connection with the second server.

12. The above method involves the first server, When the second response is received from the second server, the first terminal is prevented from performing notification to the user of the first terminal, The method according to claim 9 or claim 10, further comprising the step of causing the first terminal to execute the notification when the second server receives the third response.

13. The second terminal is configured to allow the insertion of a virtual game card, The method according to claim 9 or 10, wherein the first process includes inserting or removing a virtual game card from the second terminal.

14. The above method involves the first server, The steps include causing the second server to perform a second process, which includes causing the second terminal to receive a second notification, in response to a user operation on the first terminal, The steps include: after requesting the first processing from the second server, maintaining a session with the second server; The method according to claim 9 or 10, further comprising the step of terminating a session with the second server based on the fact that the second processing has been requested from the second server.

15. The above method involves the second server, The method according to claim 14, further comprising the step of notifying the first server that the second notification was successful, even if the second notification was successful based on the receipt of the request for the second processing.

16. The above method involves the second server, The method according to claim 14, further comprising the step of not adding the first notification to the queue, but adding the second notification to the queue.

17. A system that enables communication between a first terminal and a second terminal via a first server and a second server, wherein the second server is constantly connected to the second terminal and has one or more processors, and is used on the second server. The program is configured on one or more processors: A step of sending a first notification to the second terminal based on a first process performed by the first server in response to a user operation on the first terminal, The steps include causing the second terminal to receive a first response from the second terminal indicating that it has received the first notification, A program that performs the steps of: sending a second response indicating that the first notification was successful or a third response indicating that the first notification failed to the first server, depending on whether or not the first response has been received.

18. The program according to claim 17, wherein the third response includes information indicating the cause of the first notification failure.

19. The program is configured on one or more processors: When the second server transmits the third response to the first server, and the second terminal is in constant connection with the second server, the steps include causing the second terminal to transmit the third response after a predetermined period of time has elapsed, The program according to claim 17 or 18, which, when the second server transmits the third response to the first server, causes the second terminal not to be in constant connection with the second server, to transmit the third response before the predetermined period elapses.

20. The second terminal is configured to allow the insertion of a virtual game card, The program according to claim 17 or claim 18, wherein the first process includes inserting or removing a virtual game card from the second terminal.

21. The program is configured on one or more processors: A step of sending a second notification to the second terminal based on a second process performed by the first server in response to a user operation on the first terminal, The steps include: receiving a request for the first processing from the first server, and maintaining a session with the first server; The program according to claim 17 or claim 18, which performs the steps of receiving a request for the second processing from the first server and then terminating the session with the first server.

22. The program is configured on one or more processors: The program according to claim 21, which, based on the receipt of a request for the second processing, performs a step of notifying the first server that the second notification was successful, even if the second notification was successful.

23. The program is configured on one or more processors: The program according to claim 21, which performs the step of adding the second notification to the queue, while not adding the first notification to the queue.

Images