Information processing system, system program, application program, and information processing method

Abstract

To improve a communication method when executing a game by performing communication between information processors.SOLUTION: An application program causes a computer to execute a process of outputting, via an API for a system program, first identification information indicating which of a first communication method and a second communication method is to be used by the application program, and a process of requesting execution of a predetermined communication process via the API by using a command common to the first communication method and the second communication method. The system program causes the computer to execute a process of obtaining and storing the first identification information in response to the output of the first identification information via the API, and execute the predetermined communication process by executing, in response to a request via the API, a process that differs depending on whether the first communication method or the second communication method is used, based on the first identification information.SELECTED DRAWING: Figure 22

Description

[Technical Field]

[0001] The present disclosure relates to control of communication processing using either a first communication method or a second communication method. [Background technology]

[0002] BACKGROUND ART Conventionally, there is a technique for executing a game by communicating between information processing devices (see, for example, Patent Document 1). [Prior art documents] [Patent documents]

[0003] [Patent Document 1] Patent No. 6646991 specification Summary of the Invention [Problem to be solved by the invention]

[0004] There is room for improvement in the selection and control of the communication method when a game is executed through communication between information processing devices. [Means for solving the problem]

[0005] For example, the following configuration example can be given.

[0006] A first configuration example is an information processing system capable of executing an application program and a system program. The application program causes a computer to input first identification information, indicating whether the application program will use a first communication method or a second communication method, via an API (Application Programming Interface) for the system program, and to request execution of a predetermined communication process via the API using a command common to the first and second communication methods. The system program also causes the computer to acquire and store the first identification information in response to the input of the first identification information via the API, and, in response to the request via the API, to execute a process that differs depending on whether the first or second communication method is used, based on the stored first identification information, thereby executing the predetermined communication process.

[0007] As a second configuration example, in the first configuration example, the first communication method may be local communication, and the second communication method may be internet communication.

[0008] As a third configuration example, in the first or second configuration example, the specified communication process includes a first process in which the host device receives operation data from the guest device, and a second process in which the host device transmits a game image generated by using the operation data to the guest device, and the instruction code in the application program for executing the first process and the second process via the API may be a common instruction code whether the first communication method is used or the second communication method is used.

[0009] As a fourth configuration example, in the third configuration example, the specified communication process further includes a third process in which the host device recruits a guest device, and the instruction code for executing the third process via the API in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0010] As a fifth configuration example, in the fourth configuration example, the third process may include a process of determining a communication method specified by the application program based on the saved first identification information, and a process of recruiting guest devices using broadcast communication if the first communication method is specified, and a process of recruiting guest devices using a matching room method or by specifying a specific partner registered in the host device if the second communication method is specified.

[0011] As a sixth configuration example, in the fifth configuration example, the application program may further cause the computer to specify, via an API, a memory address at which information about the guest device is to be saved. The system program may also cause the computer to store information about the guest device at a memory address obtained via the API. The application program may also cause the computer to execute game processing using the information about the guest device stored at the memory address.

[0012] As a seventh configuration example, in the sixth configuration example, the information related to the guest device is presence information of the guest device, and the game processing may be performed for each guest device based on the presence information.

[0013] As an eighth configuration example, in the fifth configuration example, in a specified communication process, when the communication method indicated by the first identification information is the first communication method, MAC address information may be stored and used as communication partner information, and when it is the second communication method, IP address information may be stored and used as communication partner information.

[0014] As a ninth configuration example, in any of the third to eighth configuration examples, the host device may selectively execute a first mode in which a single game image is generated and transmitted to all guest devices, and a second mode in which a game image for each guest device is generated and transmitted to that guest device. The application program may further cause the computer to execute a process of outputting, via the API, second identification information indicating whether the application program is being executed in the first mode or the second mode, and to execute a process of generating a single game image when the application program is being executed in the first mode, and generating and saving a game image for each guest device when the application program is being executed in the second mode. The system program may further cause the computer to execute a process of saving the second identification information output via the API, and a process of, in a predetermined communication process, reading out and sending one game image to all guest devices if the first mode is specified in the second identification information, and reading out and sending a game image for each guest device to each guest device if the second mode is specified.

[0015] As a tenth configuration example, in any of the first to third configuration examples, the specified communication process further includes a fourth process of searching for a communication partner, and the instruction code for executing the fourth process in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0016] As an eleventh configuration example, in the tenth configuration example, the first communication method may be local communication and the second communication method may be Internet communication. Also, the fourth process may include a process of determining a communication method designated by the application program based on the stored first identification information, and a process of searching for a communication partner using broadcast communication if local communication is designated, and searching for a communication partner using a matching room method or by designating a registered predetermined partner if Internet communication is designated.

[0017] As a twelfth configuration example, in the tenth or eleventh configuration example, the application program may further cause the computer to execute a process of specifying a memory address for saving information about the communication partner via the API. The system program may cause the computer to execute a process of storing information about the communication partner at the memory address specified via the API. Then, the application program may cause the computer to execute a game process using the information about the communication partner stored at the memory address.

[0018] As a thirteenth configuration example, in the twelfth configuration example, in a specified communication process, when the communication method indicated by the first identification information is local communication, MAC address information may be stored and used as communication partner information, and when it is Internet communication, IP address information may be stored and used as communication partner information.

[0019] As a fourteenth configuration example, in any of the first to thirteenth configuration examples, the predetermined communication process may include a fifth process of acquiring operation data of the communication partner. Furthermore, the code for executing the fifth process via the API in the application program may be a command code that is common to both the first communication method and the second communication method.

[0020] As a fifteenth configuration example, in the fourteenth configuration example, the application program may further cause the computer to execute a process of specifying a memory address for saving operation data via the API of the system program. The system program may further cause the computer to execute a process of saving the operation data at the specified memory address. Then, the application program may further cause the computer to retrieve the operation data from the specified memory address and execute game processing.

[0021] As a sixteenth configuration example, in the fifteenth configuration example, the application program may further cause the computer to execute a process of specifying a memory address for saving operation data for each controller ID of one or more controllers used in the information processing system. Also, the system program may further cause the computer to execute a process of saving the operation data in the memory address specified for each controller ID. The game processing may be executed by obtaining the operation data from the memory address for each controller ID.

[0022] A seventeenth configuration example is a system program that causes a computer to execute the following processes: in response to a first request from an application program via an API, obtain and store first identification information from the application program, the first identification information indicating whether the application program will use a first communication method or a second communication method; and in response to a second request from the application program via the API, execute a predetermined communication process by performing different processing depending on whether the first communication method or the second communication method is used, based on the stored first identification information.

[0023] An 18th configuration example is the 17th configuration example, wherein the specified communication processing includes a first processing in which the host device receives operation data from the guest device, and a second processing in which the host device transmits a game image generated by using the operation data to the guest device, and the instruction code for executing the first processing and the second processing via the API in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0024] A 19th configuration example is the 18th configuration example, wherein the system program further causes the computer to execute the following processes: in response to a first request from an application program via an API, acquire and store second identification information indicating whether the application program will be executed in a first mode in which a single game image is generated and sent to all guest devices, or in a second mode in which a game image is generated for each guest device and sent to that guest device; and in a predetermined communication process, if the first mode is specified in the second identification information, read out the single game image generated and stored by the application program and send it to all guest devices, and if the second mode is specified, read out the game image generated and stored by the application program for each guest device and send it to each guest device.

[0025] A twentieth configuration example is such that, in the seventeenth configuration example, the specified communication processing further includes a third processing of searching for a communication partner, and the instruction code for executing the third processing via an API in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0026] A 21st configuration example is such that, in the 17th configuration example, the specified communication processing includes a fourth processing for obtaining operation data of the communication partner, and the code for executing the fourth processing via an API in the application program may be an instruction code that is common between when the first communication method is used and when the second communication method is used.

[0027] The 22nd configuration example is an application program that causes a computer to execute the following processes: inputting first identification information indicating whether the first communication method or the second communication method is to be used via an API for a system program; and requesting the execution of a predetermined communication process via the API for the system program using instructions common to the first communication method and the second communication method.

[0028] A 23rd configuration example is the 22nd configuration example, wherein the specified communication processing includes a first processing in which the host device receives operation data from the guest device, and a second processing in which the host device transmits a game image generated by the host device using the operation data to the guest device, and the instruction code for the application program to request execution of the first processing and the second processing via the API may be a common instruction code whether the first communication method is used or the second communication method is used.

[0029] A 24th configuration example is the 23rd configuration example, wherein the application program further causes the computer to execute, via the API, a process of outputting second identification information indicating whether the application is executed in a first mode in which a single game image is generated and sent to all guest devices, or in a second mode in which a game image is generated for each guest device and sent to that guest device, and a process of generating a single game image when executed in the first mode, and generating and saving a game image for each guest device when executed in the second mode.

[0030] A 25th configuration example is such that, in the 22nd configuration example, the specified communication processing further includes a third processing of searching for a communication partner, and the instruction code for executing the third processing via an API in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0031] A 26th configuration example is such that, in the 22nd configuration example, the specified communication processing includes a fourth processing for obtaining operation data of the communication partner, and the instruction code for executing the fourth processing via an API in the application program may be a common instruction code whether the first communication method is used or the second communication method is used.

[0032] Each of the configuration examples described above may be applied to an information processing method. [Brief explanation of the drawings]

[0033] [Figure 1]A diagram showing the overall picture of the game system 1 when using local communication. [Figure 2] A diagram showing the overall picture of the game system 1 when using internet communication. [Figure 3] A diagram explaining the transmission control of individual image games using the local game sharing function [Figure 4] A diagram explaining the transmission control of shared screen games using the local game sharing function [Figure 5] A diagram explaining the transmission control of individual image type games using the Internet type game sharing function [Figure 6] A diagram explaining the transmission control of a common image type game using the Internet type game sharing function [Figure 7] A diagram explaining the transmission control of a common image type game using the Internet type game sharing function [Figure 8] FIG. 10 is a block diagram showing an example of the configuration of a game device 3. [Figure 9] FIG. 10 is a diagram showing an example of data stored in a flash memory 32. [Figure 10] FIG. 10 is a diagram showing an example of data stored in the DRAM 33 of the host machine. [Figure 11] FIG. 10 is a diagram showing an example of the data configuration of shared game information 337. [Figure 12] FIG. 10 is a diagram showing an example of the data configuration of input function information 393 used; [Figure 13] FIG. 10 is a diagram showing an example of the data configuration of chat member information 323. [Figure 14] FIG. 10 is a diagram showing an example of the data configuration of guest member information 324. [Figure 15] FIG. 10 is a diagram showing an example of the data configuration of app-oriented guest member information 325. [Figure 16] FIG. 10 is a diagram showing an example of the data configuration of MAC address information 327. [Figure 17] FIG. 10 is a diagram showing an example of the data configuration of the self-side operation data 328 (operation data 332 of the controller ID n); [Figure 18] FIG. 10 is a diagram showing an example of data stored in the DRAM 33 of the guest machine. [Figure 19]FIG. 10 is a diagram showing an example of data stored in the server 4. [Figure 20] FIG. 10 is a diagram showing an example of a game screen. [Figure 21] An example of a chat app processing sequence [Figure 22] An example of a game processing sequence by a game AP that is a shared image type game [Figure 23] An example of a game processing sequence by a game AP that is a shared image type game [Figure 24] An example of a game processing sequence by a game AP that is an individual image type game [Figure 25] An example of a game processing sequence by a game AP that is an individual image type game [Figure 26] An example of a sequence for queuing touch panel data [Figure 27] An example of a sequence for queuing pad data [Figure 28] An example of a mouse data queuing sequence [Figure 29] An example of a sequence for queuing motion sensor data [Figure 30] An example of a setting process sequence [Figure 31] An example of a member recruitment process sequence [Figure 32] An example of a member recruitment process sequence [Figure 33] An example of a sequence for starting streaming [Figure 34] An example of a local streaming processing sequence [Figure 35] An example of an internet streaming processing sequence [Figure 36] An example of a sequence for acquiring operation data [Figure 37] An example of a sequence for receiving and storing local operations [Figure 38] An example of a sequence for receiving and storing internet operations [Figure 39]An example of the guest startup sequence [Figure 40] An example of a sequence for starting local sharing [Figure 41] An example of a local game sharing process sequence [Figure 42] An example of a sequence of preparing to send operation data [Figure 43] An example of a sequence of preparing to send operation data [Figure 44] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 45] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 46] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 47] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 48] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 49] FIG. 10 is a diagram illustrating a preparation process for transmitting operation data. [Figure 50] A diagram explaining the process of sending data in the operation queue [Figure 51] An example of the sequence of the Internet sharing start process [Figure 52] An example of a sequence for receiving images for guests [Figure 53] An example of a sequence for touch panel data transmission processing [Figure 54] An example of a sequence for pad data transmission processing [Figure 55] An example of a sequence for sending mouse data [Figure 56] An example of a sequence of a motion sensor data transmission process [Figure 57] An example of a sequence of processes executed on Server 4 DETAILED DESCRIPTION OF THE INVENTION

[0034] An embodiment will be described below.

[0035] This embodiment relates to processing related to a game sharing function. The game sharing function allows multiple users to share a predetermined game owned by a user for multiplayer play. The game sharing function in this embodiment generally executes the following processing. First, a host-side game device (hereinafter referred to as the host machine) and one or more guest-side game devices (hereinafter referred to as the guest machines) are connected via a network. Then, game processing is executed on the host machine side using a predetermined game application. This game is, for example, a multiplayer game in which a user of the host machine (hereinafter also referred to as the host user) and a user of the guest machine (hereinafter also referred to as the guest user) participate. In this game processing, the host machine receives operation data (hereinafter referred to as the guest operation data) from the guest machine. Then, the host machine performs game processing using its own operation data (hereinafter referred to as the local operation data) and the guest operation data to generate game images. Then, the host machine transmits these game images to the guest machine. The guest machine displays the received game images on its own display. In other words, the host machine streams game images to the guest machine. The multiplayer game is executed by repeating the transmission and reception of operation data and game images. When multiplayer is performed in this manner, the game application program itself need only be stored on the host device. Through this process, a game owned by a host user can be shared and played with guest users.

[0036] In the following, the host machine and the guest machine may be collectively referred to simply as "game device."

[0037] [Network status] In this embodiment, there are two main methods for network communication between the host machine and the guest machine. The first is a communication method called "local communication," and the second is a communication method called "internet communication." The game device according to this embodiment can use either of these two communication methods.

[0038] 1 is a schematic diagram showing an overall image of a game system 1 of this embodiment when using local communication. In the case of local communication, game devices 3 are connected to each other using wireless communication such as IEEE802.11 or Bluetooth, and various data is transmitted and received.

[0039] Next, FIG. 2 shows a schematic diagram of the overall picture of the game system of this embodiment when using Internet communication. In this case, each game device 3 and a server 4 can be connected to each other via the Internet. Here, communication between the host device and the guest device via the Internet can be performed via the server 4 (client-server system) or via a peer-to-peer system. As will be described in detail later, this embodiment controls the use of these two types of communication depending on the situation. In the following description, communication performed via the server 4 will be referred to as "server-mediated communication," and communication performed via the peer-to-peer system will also be referred to as "P2P communication."

[0040] The game sharing function in this embodiment can be used via either local communication or internet communication. However, in this embodiment, when using the game sharing function via internet communication, it is assumed that a "chat application" (described later) is running. Hereinafter, the game sharing function using local communication may be referred to as the "local-type game sharing function," and the game sharing function using internet communication may be referred to as the "internet-type game sharing function."

[0041] The game device 3 of this embodiment is capable of executing system software (hereinafter also referred to as OS), which is equivalent to so-called firmware or an operating system, and application programs. The application (hereinafter also referred to as AP) is, for example, the game application described above.

[0042] In this embodiment, when using the game sharing function, the system software is primarily responsible for controlling the transmission and reception of operation data, the transmission and reception of game images, and the process of recruiting participants for the multiplayer game. The game AP executed on the host machine uses an API (Application Programming Interface) corresponding to each process handled by the system software to request the system software to execute each process individually. The content of the communication control process differs depending on whether local communication or Internet communication is used when using the game sharing function. In this embodiment, however, the system software handles the control depending on the communication method. Therefore, from the game AP's perspective, the API allows the various processes to be performed using common commands regardless of whether local communication or Internet communication is used. Specific examples of APIs will be described later.

[0043] The term "API" may include, for example, the execution of a process that includes a predetermined response to a predetermined request in accordance with a predetermined rule, but it does not exclude other meanings. The term "API" does not necessarily have to be used in a system or design.

[0044] [Game screen types] Here, the game AP assumed in this embodiment is of the following two types. Hereinafter, the first type will be referred to as a "common image type game" and the second type will be referred to as an "individual image type game." Note that this embodiment assumes that the individual image type game and the common image type game are separate game APs (games with different game titles).

[0045] A common-image type game is, for example, a fixed-screen action game in which the screen does not scroll. In a common-image type game, a process is executed to generate a common game image on the host machine and the guest machine. Therefore, when a common-image type game is played using the game sharing function, the game image resulting from the game process in a certain frame will be the same on both the host machine and the guest machine.

[0046] On the other hand, an individual image type game is a game in which game images for the host machine and game images for the guest machine are generated separately. For example, this is a racing game in which 3D game images are displayed. When an individual image type game is played using the game sharing function, the game images resulting from game processing in a certain frame may differ between the host machine and the guest machine.

[0047] In this embodiment, when using the game sharing function via the Internet, the transmission of game images is controlled by selectively using communication via a server or P2P communication based on whether the game is an individual image type game or a shared image type game and the number of guests. Specifically, P2P communication is used in principle, but communication via a server is used under certain conditions.

[0048] Hereinafter, an overview of transmission control relating to a combination of an "individual image type game" and a "common image type game" will be described with reference to FIGS.

[0049] FIG. 3 is a schematic diagram showing an overview of transmission control of game images and operation data when using the local game sharing function for an individual image type game. In this case, game images are transmitted from the host machine to the guest machine using local communication. In an individual image type game, game images for the host machine (hereinafter referred to as host images) and game images for each guest machine (hereinafter referred to as guest images) are generated separately by the game processing of the host machine, and different game images are displayed on the host machine display and the guest machine display. The host machine also stores the user ID and MAC address of each guest machine as guest member information (described below). The guest machine also stores the user ID and MAC address of the host machine as host information. The host machine identifies the IP address of each guest machine by referencing the guest member information and transmits each guest image to the corresponding guest machine using local communication. Note that, hereinafter, host images and guest images may be collectively referred to as "individual images."

[0050] Next, Figure 4 is a schematic diagram showing an overview of game image transmission control when using the local game sharing function for a common image type game. In a common image type game, one game image (hereinafter sometimes referred to as a common image) is generated by game processing on the host machine, and this game image is displayed on the displays of the host machine and the guest machine. Then, as in the case of the individual image type game, the common image is transmitted from the host machine to the guest machine using local communication.

[0051] Furthermore, the guest machines transmit their own operation data to the host machine identified based on the host information. Transmission of operation data from the guest machines to the host machine is performed using local communication, both in the case of an individual image type game (FIG. 3) and in the case of a common image type game (FIG. 4). Note that, as will be described in detail later, in this embodiment, control is performed such that operation data accumulated in a frame rate cycle is transmitted to the host machine all at once in the same cycle as the frame rate. This allows for more efficient transmission of operation data.

[0052] Next, an overview of transmission control when using the Internet-based game sharing function will be described. FIG. 5 is a schematic diagram showing an overview of transmission control of game images and operation data when using the Internet-based game sharing function for an individual image type game. In this case, game images are transmitted from the host machine to the guest machines using P2P communication over the Internet. Specifically, host images and guest images are generated separately by game processing on the host machine. The host machine also stores the user ID and IP address of each guest machine as guest member information. The guest machine also stores the user ID and IP address of the host machine as host information. The host machine identifies the IP address of each guest machine by referencing the guest member information and transmits each guest image to the corresponding guest machine using P2P communication.

[0053] Next, Figures 6 and 7 are schematic diagrams showing an overview of game image transmission control when an Internet-based game sharing function is used for a common-image type game. In this case, either server-mediated communication or P2P communication is used depending on the number of guest machines. In this embodiment, P2P communication is used when the number of guests is three or less, and server-mediated communication is used when the number is four or more. Figure 4 is a schematic diagram showing an example of a case where there is one guest machine as an example of a case where there are three or less guest machines. Referring to Figure 4, a common image is generated by game processing on the host machine. Then, when the number of guest machines is three or less, the common image is transmitted from the host machine to the guest machine using P2P communication, as in the case of the individual image type game described above.

[0054] Next, FIG. 5 is a schematic diagram showing a case where the number of guest machines is four or more. When the number of guest machines is four or more, the host machine transmits a common image to the server 4. A virtual room called a "game sharing room" is created in the server 4. For each game sharing room, participating member information is stored, including data about the host machine (host data) and data about each guest machine (nth guest data, where n is an integer). Specifically, each user ID and IP address is stored. The common image transmitted from the host machine is sent to the game sharing room in which the host machine is participating. The server 4 then references the participating member information and transmits the common image received from the host machine to each guest machine. In other words, when a common image-type game is being shared and the number of guest machines is four or more, the common image is transmitted from the host machine via communication via the server.

[0055] The reason for using different communication control methods when sharing a shared image game using an Internet-based game sharing function, as described above, is to balance the processing load on the host machine with the communication delay associated with sending and receiving game images. First, when transmitting image data from a host machine to a guest machine using server-mediated communication and P2P communication, P2P communication generally tends to have lower communication delays and is not affected by factors such as the server's geographic location. Therefore, game images are generally transmitted using P2P communication. Considering a shared image game with multiple guest machines, the process of transmitting the same game images using P2P communication must be repeated for each guest machine. Therefore, the greater the number of guest machines, the greater the processing load on the host machine for transmitting game images. On the other hand, when transmitting game images via a server, the process of transmitting game images from the host machine to the server 4 only needs to be performed once. In other words, server-mediated communication is advantageous in terms of reducing the processing load on the host machine. Therefore, in this embodiment, taking into consideration both communication delays and the processing load of the host machine, control is performed so that if the number of guest machines is relatively large, the shared image is transmitted via communication via a server, and if the number of guest machines is small, the shared image is transmitted via P2P communication. Note that, depending on the network settings of the host machine and guest machines, direct P2P communication may not be possible. In such cases, communication via a server is performed. In this embodiment, as an example, communication via a server is performed if the number of guests is four or more, but the specific number may be determined appropriately depending on the processing capabilities of the game devices and the game content. For example, control may be performed so that P2P communication is used if the number of guests is one, and communication via a server is used if the number is two or more.

[0056] Furthermore, in the Internet-based game sharing function, operation data is transmitted from a guest machine to a host machine using P2P communication regardless of whether the image is an individual image or a common image, and regardless of the number of guests. Unlike the local-based game sharing function, this transmission is controlled to be immediate, without waiting for a game frame cycle. This is because the operation data from the guest machine is required to advance game processing on the host machine. In other words, there is a possibility that the game processing on the host machine will have to wait for the arrival of operation data from the guest machine. In consideration of this possibility, P2P communication is used to transmit and receive operation data, which can minimize communication delays on the host machine. Furthermore, because the data volume of operation data is small, it is expected that the impact on the processing load of the host machine will be small. In other embodiments, operation data may be transmitted and received using either P2P communication or communication via a server, or a hybrid of these.

[0057] The processing according to this embodiment will be described in detail below.

[0058] [Hardware Configuration of Game Device 3] First, a description will be given of the hardware configuration of the game device 3. Fig. 8 is a block diagram showing the hardware configuration of the game device 3. The game device 3 is an example of an information processing device. The information processing device may be, for example, a personal computer, a tablet terminal, a smartphone, etc.

[0059] The game device 3 includes a processor 31. The processor 31 is an information processing unit that executes various types of information processing executed in the game device 3. The processor may be a general-purpose processor or a dedicated processor. The processor 31 may be configured, for example, from multiple processors or cores, typically multiple central processing units (CPUs) or cores, or may be configured from a system-on-a-chip (SoC) that includes multiple functions such as a CPU function and a graphics processing unit (GPU) function. In this embodiment, the "processor" may include at least a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. The processor 31 executes various types of information processing by executing a program (e.g., a program that runs a game application) stored in a storage unit (e.g., an internal storage medium such as the flash memory 32 or the DRAM 33, an external storage medium inserted in a predetermined slot, etc.).

[0060] The game device 3 includes a flash memory 32 and a dynamic random access memory (DRAM) 33 as examples of internal storage media. The flash memory 32 is a memory used mainly for storing various types of data saved in the game device 3. The DRAM 33 is a memory used mainly for temporarily storing various types of data used in information processing. The processor 31 executes various types of information processing by appropriately reading and writing data from and to storage media such as the flash memory 32 and the DRAM 33. In this embodiment, the "memory" may include at least the flash memory and the DRAM, and may also include other storage media.

[0061] The game device 3 also includes a frame buffer 34 for storing one frame of game image. The frame buffer 34 may be built into the GPU, or a part of the DRAM 33 may be used as the frame buffer, or a dedicated memory device may be used.

[0062] The game device 3 also includes a display 35, which is an example of a display unit. The display 35 may be a built-in display or a monitor externally connected to the game device 3.

[0063] The game device 3 also includes an operation unit 36. The operation unit 36 ​​includes a plurality of input functions. Each input function corresponds to a different type of operation device. Specifically, in this embodiment, a touch panel, a joystick, operation buttons, a mouse, and a motion sensor are described as examples of input functions included in the operation unit 36. In other embodiments, other input functions may be included.

[0064] A touch panel is a type of pointing device. The touch panel may be, for example, a type that allows multi-touch input (e.g., a capacitance type), a type that allows single-touch input (e.g., a resistive type), or any other type. The touch panel also generates data that indicates the position where a touch input has been made, and repeatedly outputs the data to processor 31 at appropriate timing.

[0065] The joystick can be used as a direction input unit that can input a direction, for example. The game device 3 may also include multiple joysticks. The operation buttons are used to give instructions according to various programs (for example, system software programs and application programs) executed on the game device 3. The operation buttons are, for example, so-called ABXY buttons and LR buttons on a game controller. Information regarding operations performed on the joystick and operation buttons is repeatedly output to the processor 31 at appropriate timing.

[0066] The mouse is a type of pointing device, such as an optical mouse. Of course, other types of mouse may also be used. Data for calculating the movement of the mouse placed on the placement surface is repeatedly output to processor 31 at appropriate timing.

[0067] The motion sensor is, for example, an acceleration sensor or an angular velocity sensor. The acceleration sensor detects the magnitude of acceleration along predetermined three axial directions. The acceleration sensor may detect acceleration along one or two axial directions. The angular velocity sensor detects angular velocity around predetermined three axes. The angular velocity sensor may detect angular velocity around one or two axes. The detection results of the motion sensor are repeatedly output to the processor 31 at appropriate timing.

[0068] As described above, the operation unit 36 ​​includes five types of input devices (input functions), but in this embodiment, the joystick and operation buttons are treated as a single input function. For convenience in the following description, the input function collectively referring to the joystick and operation buttons is referred to as a "pad." Therefore, in this embodiment, an example will be described in which four types of input functions are used: a touch panel, a pad, a mouse, and a motion sensor. In addition, in the following description, the operation data of the joystick and operation buttons may be collectively referred to as "pad data."

[0069] In other embodiments, the joystick and the operation buttons may be treated as separate input functions.

[0070] The communication module 37 communicates with other game devices 3 and the server 4 via the above-mentioned local communication or internet communication. The communication module 37 also supports the A-MPDU function (in the so-called MAC sublayer). A-MPDU (Aggregation-MAC Protocol Data Unit) is a type of frame aggregation technology that aggregates and transmits multiple packets in a single frame. In this embodiment, this function can be used when the above-mentioned local game sharing function is used.

[0071] The hardware configuration of the server 4 may be the same as that of a general server or PC, and a description thereof will be omitted, but as an example, the configuration is assumed to be the same as that shown in Fig. 8. The server 4 may be configured by a plurality of server devices.

[0072] Next, various types of data used in the processing according to this embodiment will be described. First, the data stored in flash memory 32 will be described using Figure 9. Flash memory 32 stores system software 301 and a game program 309. System software 301 has the game sharing function described above, and the game sharing function is made up of a host program 303, a guest program 305, and an Internet communication application 306.

[0073] The host program 303 is a program for operating the game device 3 as the host machine. The host program 303 includes a local communication streaming program 304 and an internet communication streaming program 308. The local communication streaming program 304 is a program for realizing control to transmit game images to a guest machine using the local communication. The internet communication streaming program 308 is a program for realizing control to transmit game images to a guest machine using the internet communication.

[0074] The guest program 305 is a program for operating the game device 3 as the guest device. In this embodiment, the guest program 305 includes programs corresponding to guest-side startup processing, local sharing start processing, local game sharing processing, internet sharing start processing, and internet game sharing processing, which will be described later.

[0075] The internet communication application 306 is an application that uses the internet communication. In this embodiment, the internet communication application 306 is a chat application (hereinafter referred to as chat AP). The chat AP includes a chat application program 307. The chat application program 307 is a program for implementing various chat functions. In this embodiment, it is assumed that a chat application is running in order to use the internet-based game sharing function. In other words, it is assumed that a player selects a partner to play with from among chat members and plays multiplayer games using the internet-based game sharing function.

[0076] In addition, although not shown in the figure, the system software also includes a local communication module for controlling the local communication (such as exchanging various packets) and an internet communication module for controlling the internet communication.

[0077] The game program 309 is a program equivalent to the game AP. In this embodiment, the input functions, frame rate, and game image resolution used in the game are predetermined for each game AP. In this embodiment, the game AP is assumed to be a fixed frame rate game, but may be a variable frame rate game. This information is defined within the game program. For example, the information may be directly specified as part of the code.

[0078] In the game device 3 according to the present embodiment, the processes resulting from the execution of the system program, chat application program, and game program can coexist. For example, even if a game AP is running in the foreground, a chat AP can also be running in the background.

[0079] Next, data stored in the DRAM 33 of the host machine will be described with reference to Figure 10. Various data required for executing the game sharing function is generated, updated, and stored in the DRAM 33 as appropriate. In Figure 10, the DRAM 33 of the host machine may contain the following data:

[0080] The communication type identification data 321 is data for identifying whether local communication or internet communication is used in the game sharing function.

[0081] The game type identification data 322 is data for identifying whether the game relating to the game sharing function is an individual image type game or a common image type game.

[0082] The shared game information 337 is information about the game to be played this time in game sharing (hereinafter, sometimes referred to as the shared game). FIG. 11 shows an example of the data configuration of the shared game information 337. The shared game information 337 includes a game ID 391, a game name 392, used input function information 393, frame rate information 394, and resolution information 395. The game ID 391 is an ID for uniquely identifying the shared game, and the game name 392 is the game title name of the shared game. This information is stored in the game program and is stored in DRAM when the game program is launched. Note that with regard to this information, the game program may store different data for each game scene, and different data depending on the game scene may be stored in DRAM as the shared game information 337.

[0083] The used input function information 393 is information that specifies an input function to be used in the current shared game from among multiple input functions provided in the game device. As described above, in this embodiment, an example will be described in which there are four types of input functions: a touch panel, a pad, a mouse, and a motion sensor. Therefore, information that specifies the input function to be used from these four is set as the used input function information 393. FIG. 12 shows an example of the data configuration of the used input function information 393. The used input function information 393 is, for example, 4-bit data. In FIG. 12, each bit is assigned, from left to right, as information on the touch panel, pad, mouse, and motion sensor. For each bit, 1 is set if the input function is to be used, and 0 is set if the input function is not to be used.

[0084] Returning to FIG. 11, the frame rate information 394 indicates the frame rate of the shared game. Information indicating, for example, 60 fps or 30 fps is set as the frame rate information 394. Note that the processing time for one frame based on the frame rate information 394 may be referred to as a "game frame" below. For example, in the case of a game for which 60 fps is specified as the frame rate information 394, a game frame is 1 / 60 seconds (16.7 ms).

[0085] The resolution information 395 is information that specifies the resolution of the game image in the shared game, and is set to, for example, information indicating 720p or 1080p.

[0086] Returning to FIG. 10, chat member information 323 is information about members participating in a chat in the chat AP. FIG. 13 shows an example of the data configuration of chat member information 323. Chat member information 323 is data consisting of a collection of records each having a user ID 351, an IP address 352, and various other information 353. User ID 351 is an ID for uniquely identifying a user participating in the chat. IP address 352 is the IP address of the game device used by the user participating in the chat. Various other information 353 may include, for example, a user name, an icon image, account information, etc.

[0087] Returning to FIG. 10, the guest member information 324 is information on the guest machines participating in the shared game related to the game sharing function as described above. FIG. 14 shows an example of the data configuration of guest member information 324. The guest member information 324 is data consisting of a collection of records each having a guest ID 361, a user ID 362, controller information 363, and various other information 364. The guest ID 361 is information mainly used in the game AP and is an ID for uniquely identifying each guest machine (and the guest user using it) participating in the game. The user ID 362 is the same as the user ID 351 described above. In other words, the guest member information 324 can be said to be information indicating the correspondence between the guest ID 361 and the user ID 351 in the chat member information 323. The controller information 363 is information indicating the controller ID and controller type of the controller used (connected) in the current game sharing on the guest machine corresponding to the guest ID 361. The various other information 364 includes other information about each guest machine (e.g., player name, etc.). In this example, when game sharing is performed using Internet communication, a guest ID 361 is assigned to each guest machine participating in the game sharing.

[0088] Returning to FIG. 10 , the application-oriented guest member information 325 is information used in game processing by the game AP. The application-oriented guest member information 325 is information that indicates the guest IDs 361 of guest machines that will actually participate in the game, among the guest member information 324. In other words, it can also be said to be information that indicates the presence of guest machines at the time of game sharing. FIG. 15 shows an example of the data configuration of the application-oriented guest member information 325. Here, as an example, a case will be described in which the maximum number of guest machines that can participate in game sharing is seven. The application-oriented guest member information 325 is assumed to be fixed-length data with seven storage slots for guest IDs. Each slot is assumed to be set with the guest ID 361 of the guest machine that will participate in the game, or a null value (a value indicating non-participation). In the example of FIG. 15 , the guest IDs are filled up to three slots, indicating that the number of guest machines participating in the game is three.

[0089] In addition to the data configuration described above, the guest member information 325 for the application may also be, for example, table-format data consisting of a combination of all guest IDs 361 in the guest member information 324 and a flag indicating the existence / non-existence of each guest ID.

[0090] 10, the storage address information 326 of the guest member information for the application is information indicating the top memory address (hereinafter referred to as the guest information storage address) of the memory area of ​​the DRAM 33 where the guest member information for the application 325 is stored. The guest information storage address is used as an argument when using an API in the process described later.

[0091] The MAC address information 327 is data used when using the game sharing function in local communication. Fig. 16 shows an example of the data configuration of the MAC address information 327. The MAC address information 327 is data consisting of a set of records, each of which is a pair of a user ID 381 and a MAC address 382.

[0092] Returning to FIG. 10 , the local operation data 328 is operation data indicating the details of operations performed on a controller or the like of the host machine. FIG. 17 shows an example of the data structure of the local operation data 328. Note that operation data 332 for each controller ID, which will be described later, has a similar data structure. In FIG. 17 , the local operation data 328 includes a touch panel data area 371, a pad data area 372, a mouse data area 373, and a motion sensor data area 374. In this embodiment, an example is described in which the game device is equipped with four types of input functions as described above. Data output from each input function is accumulated in the local operation data 328 at a predetermined cycle. In this embodiment, data is accumulated every 4 ms for the touch panel, and every 5 ms for the pad, mouse, and motion sensor.

[0093] Touch panel data, which is output data from the touch panel, can be stored in the touch panel data area 371 at a cycle of 4 ms. The touch panel data is, for example, a two-dimensional array of data in which the touch panel is viewed as an XY plane, and is data indicating the coordinates of touches. Note that when multiple touches are made, the coordinate data for each touch is output and stored.

[0094] Pad data is accumulated at 5 ms intervals in pad data area 372. Pad data is output data from the operation buttons and joystick, and includes, for example, information indicating the on / off status of each button and information indicating the input direction and tilt degree (angle) of each joystick.

[0095] Mouse data, which is output data from the mouse, is accumulated every 5 ms in the mouse data area 373. The mouse data is data that indicates, for example, the movement distance per predetermined unit time (5 ms in this example) in the x-axis and y-axis directions of a two-dimensional coordinate system corresponding to the surface on which the mouse is placed.

[0096] Motion sensor data, which is output data from the motion sensor, is accumulated in a cycle of 5 ms in the motion sensor data area 374. The motion sensor data is, for example, data indicating acceleration in the x, y, and z-axis directions and angular velocity around the x, y, and z-axes per predetermined unit time (5 ms in this example).

[0097] Returning to FIG. 10 , the guest operation data area 330 is an area for storing operation data received from a guest machine, and includes multiple nth guest operation data 331 (where n is the guest machine number) that are operation data corresponding to each guest machine (hereinafter also referred to as guest operation data). In this embodiment, a controller ID is assigned (for example, sequentially starting from 1) to identify the controller used in each game machine. Controller IDs are also assigned for each game machine. Therefore, for example, if two controllers are connected to a second guest machine, it is possible to identify each controller connected to each guest machine by a combination of a guest ID and a controller ID (hereinafter collectively referred to as controller identification information), such as "controller ID1 of the second guest ID" and "controller ID2 of the second guest ID." Each nth guest operation data 331 stores operation data 332 for each controller ID, the same as the number of controllers connected to that guest machine. The data structure of the operation data 332 for each controller ID is similar to that of the host operation data 328, and therefore will not be described again.

[0098] Next, the guest operation data storage address information 333 is information indicating the leading memory address (hereinafter referred to as guest operation storage address) of the storage location of each piece of operation data 332 for each controller ID included in the n-th guest operation data 331.

[0099] Next, the player's game image data 334 is game image data to be displayed on the display 35 of the host machine. The area in which the player's game image data 334 is stored is a so-called frame buffer, and may be the frame buffer 34. In this embodiment, when a "common image type game" is executed, the common image may be stored in the area (frame buffer) of the player's game image data 334. When an "individual image type game" is executed, the common image may be stored in a memory area separate from the frame buffer.

[0100] The guest game image area 335 is an area where the guest images generated by the game AP are stored in the case of an individual image type game. The guest game image area 335 includes a plurality of nth guest machine image data 336 (n is an integer and is an element corresponding to each guest ID), which are guest images for each guest ID. The guest game image area 335 is not necessary in a common image type game.

[0101] Next, an example of data stored in the DRAM 33 when the game device 3 operates as a guest machine will be described. Fig. 18 shows an example of data stored in the DRAM 33 of the guest machine. The DRAM 33 of the guest machine includes shared game data 411, guest game image data 414, an operation data queuing area 415, a transmission buffer 420, a transmission queue 421, etc.

[0102] The shared game data 411 includes host information 412 and shared game information 413. The host information 412 includes information about the host machine in the game being shared this time. Specifically, it includes the network address (MAC address or IP address) of the host machine, the user ID of the host machine, etc. The shared game information 413 is the shared game information 337 transmitted from the host machine and stored as described above in FIG. 11. The data structure is the same as that of the shared game information 337, and therefore a description thereof will be omitted.

[0103] The guest game image data 414 is a game image (common game image or individual game image) transmitted from the host machine that has been received and stored.

[0104] The operation data queuing area (hereinafter, sometimes referred to as the operation queue area) 415 is an area for storing operation details for each input function as operation data. The data configuration is the same as that of the local operation data 328 in the host machine. As described above, in this embodiment, each piece of operation data is stored in the corresponding area within the operation queue area 415 at a cycle of 4 ms for the touch panel, and at a cycle of 5 ms for the pad, mouse, and motion sensor. In addition, as will be described in detail later, in this embodiment, when playing a game using local communication, the data stored in the operation queue area 415 can be collected at a predetermined timing and transmitted to the host machine.

[0105] The transmission buffer 420 is a working buffer used when generating transmission packets to be sent to the host device. Note that one transmission packet can also be considered as one transmission unit.

[0106] The transmission queue 421 is an area for temporarily storing one or more transmission packets 422 to be transmitted to the host machine. An upper limit is set for the number of transmission packets that can be stored in the transmission queue 421. Note that, as will be described in detail later, in this embodiment, processing is performed to output all transmission packets stored in the transmission queue 421 at once. Then, these transmission packets are grouped together by the A-MPDU function and transmitted from the guest machine to the host machine.

[0107] Next, data that may be stored in the server 4 will be described. FIG. 19 shows an example of data stored in the server 4. FIG. 19 is also a diagram that excerpts only the server portion of FIG. 7 above. The server 4 stores shared room data 401 corresponding to each of a plurality of game shared rooms. Each shared room data 401 may include participating member information 402. The participating member information 402 may include host data 403 related to the host machine and multiple n-th guest data 406 related to the guest machine. Each piece of data includes a user ID 404 and an IP address 405.

[0108] A specific example of processing according to this embodiment will be described below, but before that, an example of the flow of user operations up to the start of using the game sharing function will be described.

[0109] In this embodiment, for example, when the host user starts up the game device 3, a home menu (not shown) is displayed. The host user selects and starts up a game AP compatible with the game sharing function from the home menu. As a result, a game menu screen such as that shown in FIG. 20 is displayed. In FIG. 20, the name of the game title and the start menu items "Single Play," "Game Sharing (Local)," "Game Sharing (Internet)," and "Options" are displayed. When using the game sharing function using the local communication, the host user selects "Game Sharing (Local)" and performs a confirm operation. When using the game sharing function using the Internet communication, the host user selects "Game Sharing (Internet)" and performs a confirm operation.

[0110] When using the game sharing function using local communication, the above operation causes the processing described below to be performed.

[0111] On the other hand, as mentioned above, if you want to use the game sharing function over the Internet, you must first launch the chat app. Therefore, in this case, before launching the game AP, you must select and launch the chat app from the home menu and enter a chat room.

[0112] 21 shows an example of a processing sequence related to the chat application. In this processing, first, a process for specifying a chat partner is executed (S1). For example, based on a user's operation, a process for sending a chat request to a predetermined friend or joining a chat room is executed.

[0113] Next, a process is performed to generate and store the chat member information 323 (S2). After that, although not shown in the drawings, processes such as sending and receiving various messages related to the chat may be performed as appropriate based on the user's operation.

[0114] When the chat application is started and chat member information 323 is created as described above, selecting and confirming "Game Sharing (Internet)" from the menu causes the processing described below to be executed.

[0115] If "Game Sharing (Internet)" is selected and confirmed when the chat application is not started, a message prompting the user to start the chat application may be displayed. Then, the process related to "Game Sharing (Internet)" may not be executed until the chat application is started and the chat member information 323 is generated.

[0116] [Processing on the game AP side] Next, an example of the processing of a game AP executed by the host machine will be described. First, the processing when the game AP is a common image type game will be described, and then the processing when the game AP is an individual image type game will be described.

[0117] [Common image type game] 22 and 23 are flowcharts showing an example of processing of a game AP of a common image type game executed on a host machine. Note that only the processing related to the game sharing function as described above will be explained here, and detailed explanations of other game functions will be omitted.

[0118] In FIG. 22, when the game process starts, first, the game title screen as described above is displayed (S11).

[0119] Next, based on the user's operation data 328, it is determined whether an instruction to activate the local game sharing function has been issued (S12). In the example of FIG. 14, it is determined whether an operation to confirm "game sharing (local)" has been issued. If the result of this determination is that an instruction to activate the local game sharing function has been issued (YES in S12), then a process to call "settings processing" using the API is executed (S13). When the API is called, the following arguments are specified, and a command to call the settings processing is issued. First, a value specifying the communication type is set as the argument. Furthermore, a value specifying the type of game (individual image or common image) is set as the argument. For example, the value (variable) specifying the communication type is set as "type," and either "Local" or "Internet" is set as the setting value. Furthermore, the value specifying the type of game is set as "Mode 1" for common images and "Mode 2" for individual images. Furthermore, a setting value to be set in the shared game information is also set as the argument. That is, values ​​indicating the specific content of the game ID 391, game name 392, input function information 393, frame rate information 394, and resolution information 395 are set as arguments. Here, as an example, it is assumed that the game to be shared has a game ID of 0123, uses only the pad as an input function, has a game frame rate of 60 fps, and has a resolution of 1080p. In such a case, for example, the following instruction code may be written. Note that the specified game frame may be a variable frame rate, or a frame rate different from the frame rate of the host machine may be specified. In that case, information about the frame rate of the host machine may be included. type=Local Initialize(type,mode1, 0100,60,1080) With this description, a "setting process" is called, specifying "local communication" as the communication type and "common image" as the game type. This causes various data in the shared game information 337 to be set.

[0120] In addition, when different data is used for each game scene for the used input function information 393, when the corresponding scene is reached, data on the used input function corresponding to the scene may be passed to the system via the API. The same applies to the mode and frame rate indicating the common image or individual image.

[0121] Here, the Initialize method is a process for initializing game processing, and this initialization process includes the above-mentioned "type saving process." Therefore, in response to the above command, the system software performs the initialization process, and executes the "type saving process" using the above-mentioned arguments during this process. Note that, while a specific example of the "setting process" will be described later, as a result of this process, the above-mentioned communication type identification data 321, game type identification data 322, and shared game information are set.

[0122] On the other hand, if the result of the determination in S12 above is that an instruction to activate the local game sharing function has not been issued (NO in S12), then it is determined based on the own operation data 328 whether or not an instruction to activate the Internet-type game sharing function has been issued (S14). In the example of FIG. 14 above, it is determined whether or not a "game sharing (Internet)" confirmation operation has been issued. If the result of this determination is that an instruction to activate the Internet-type game sharing function has not been issued (NO in S14), the process returns to S11 above and is repeated. If an instruction to activate the Internet-type game sharing function has been issued (YES in S14), a "setting process" is called in which "Internet communication" is specified as the communication type and "common image" is specified as the game type (S15). For example, the following command code may be written: type=Internet Initialize(type,mode1, 0100,60,1080)

[0123] After the "setting process" is called, a process is executed to determine the maximum and minimum number of members to be recruited (S16). This may be specified by the user, or may be set as a fixed number depending on the title of the game.

[0124] Next, the above-mentioned guest information storage address is determined (S17).

[0125] Next, the guest information storage address, the maximum number of members to be recruited, and the minimum number of members to be recruited are specified as arguments, and the "member recruitment process" is called using the API (S18). For example, if the variable indicating the maximum number of members to be recruited is "max," the variable indicating the minimum number of members to be recruited is "min," and the variable indicating the member information storage address is "MemberInfoAddr," the following command code can be written: Matchmake(MemberInfoAddr,max,min) As a result of this call, the "member recruitment process" described below is executed on the system software side, and as a result, the guest member information 324 and guest member information 325 for applications are generated.

[0126] Next, a "streaming start process" is called using the API (S19). This process instructs the system software to start the streaming process (a process for transmitting game images to the guest machine), which will be described later, and can be written, for example, using the following command code without using any arguments: StartStreaming() This starts the execution of the streaming process, which will be described later.

[0127] Next, the guest operation storage address is determined and notified to the system program (S20). In this example, since a controller ID is assigned to each game device as described above, the guest operation storage address is determined for each piece of controller identification information. Note that the guest operation storage address may be specified each time the "operation data receiving and storing process" described below is called.

[0128] Next, a call of an "operation data acquisition process" using the API is executed (S21). This process causes the system software to execute an "operation data acquisition process" described later. This process executes a process to acquire the operation data stored in the guest operation data area 330. Note that this process is executed once for each game frame, but as described later, the process of storing operation data in the guest operation data area 330 (the process of receiving operation data from the guest machine and storing the operation data in the guest operation data area 330) is executed each time data is received. This process is called by specifying one or more pairs of the controller identification information and the guest operation storage address as arguments. For example, it can be written using the following instruction code: GetGuestInput(Padaddr1, Guest1,Pad1, Padaddr2, Guest2,Pad1, Padaddr3, Guest2,Pad2,...) Here, the argument Padaddrn (n is an integer) indicates the operation data storage address, and the arguments Guestn and Padn indicate the controller identification information (guest ID: controller ID). The guest ID is identification information for each guest machine, and the controller ID is identification information for the controller connected to each guest machine.

[0129] Next, game processing is executed (S22) based on the operation data 332 for each controller ID of each guest machine stored in the guest operation data area 330 and the host operation data 328. At this time, only the operation data related to the input function specified in the used input function information 393 is used for the host operation data 328. The data used in the game processing may be deleted.

[0130] Next, a command (this command is included in the game program) is executed to instruct the GPU to generate a game image (common image) based on the results of the game processing (S23). In response to this command, the GPU draws the common image in frame buffer 34 (a buffer that stores game images to be displayed on the display of the host machine). (Note that direct drawing may also be executed by a command from the game program. The same applies to individual images, described below.) Since this is a common-image type game, the common image will be generated as the game image. In S23, a command to generate the common image is issued, and after it is executed (when the common image is completed), a display command is executed. The display command is a command indicating that generation of the game image has been completed and that it may be displayed on the display; the actual display is performed at the timing of the V-sync of the host machine after the display command is issued. The command to generate the common image and the display command are commands from the game program.

[0131] Thereafter, the process returns to S21, and the above process is repeated until the game ends.

[0132] This concludes the description of the processing example of the game AP of the common image type game.

[0133] [Individual image type game] Next, a processing example of the game AP of the individual image type game will be described. Figures 24 and 25 are flowcharts showing a processing example of the game AP of the individual image type game executed on the host machine. Here, in Figure 24, except for some processing, the same processing as that of the common image type game is executed. Therefore, a description of the similar parts will be omitted, and only the parts where processing different from that of the common image type game is performed will be described.

[0134] In FIG. 24, when an instruction to activate the local game sharing function is given (YES in S12), a process is executed to call the "setting process" using the same arguments as above (S13). In this process, the value specified as the argument is different from that in the case of the common image game. Specifically, a value indicating "individual image" is specified as the game type. For example, the following command code may be written: type=Local Initialize(type,mode2,0100,60,1080)

[0135] Furthermore, when an instruction to activate the Internet-based game sharing function is given (YES in S14), a process is executed to call the "setting process" using the same arguments as above (S15), and in this case too, a value indicating "individual image" is specified as the argument for the game type. For example, this can be written using the following command code: type=Internet Initialize(type,mode2, 0100,60,1080)

[0136] In addition, when the guest member information 324 is created as a result of calling the "member recruitment process" in S18, the guest game image area 335 (i.e., the storage location for each guest image) is secured according to the number of guests (guest IDs).

[0137] 25, following the game processing in S22, a process for generating a game image based on the results of the game processing is executed. However, because this is an individual image type game, a different process is executed from that executed in the case of a common image type game. That is, in S25, an instruction (this instruction is included in the game program) instructing the GPU to generate an individual image is executed. Specifically, in S25, an instruction instructing the GPU to generate an image for the host is executed, and the image for the host is drawn in the game image data 334 for the player's machine (frame buffer) (S25). Furthermore, an instruction instructing the GPU to generate an image for each guest is executed, and each guest image is drawn in the guest game image area 335 (S26). Needless to say, if multiple controllers are connected to one guest machine, a game image reflecting game processing based on operation data related to these multiple controllers is generated as the guest image for that guest machine. In step S25, each time generation of a game image for each guest is completed, a display instruction for that game image is executed. Furthermore, the game image data for the player's machine stored in the frame buffer by the processing in S25 is sent to each guest machine by a streaming process described below, and is displayed on the display of the host machine at the image switching timing by the system program.

[0138] By the streaming process described later, each image data is read from the guest game image area 335 and transmitted to each guest machine. After that, the process returns to S21 and repeats.

[0139] This completes the description of the processing example of the game AP of the individual image type game.

[0140] [System software processing] Next, various processes that can be executed by the system software (system software 301) in response to a call from the game AP using the API will be described.

[0141] First, the operation data queuing process will be described. In this embodiment, an example is described in which the game device has four types of input functions as described above. Then, for each input function, the system software acquires its output data at predetermined intervals and stores it in the host device's own operation data 328 or in the operation queue area 415 for the guest device.

[0142] 26 to 29 show an example of operation data queuing processing for each input function. This processing is executed by system software on both the host machine and the guest machine. First, FIG. 26 is a flowchart showing the touch panel data queuing processing. In this processing, a process (S171) of queuing output data from the touch panel in the touch panel data area 371 (touch panel data area 416 in the operation queue area 415 when executed on the guest machine) is repeatedly executed every 4 ms.

[0143] 27 is a flowchart showing the pad data queuing process. In this process, a process (S181) of queuing output data (pad data) from the joystick and operation buttons in the pad data area 372 (pad data area 417 when executed on a guest machine) is repeatedly executed every 5 ms.

[0144] 28 is a flowchart showing the mouse data queuing process. In this process, the process (S191) of queuing output data from the mouse in the mouse data area 373 (or the mouse data area 418 when executed on a guest machine) is repeatedly executed every 5 ms.

[0145] 29 is a flowchart showing the queuing process of motion sensor data. In this process, the process (S201) of queuing the output data from the motion sensor in the motion sensor data area 374 (motion sensor data area 419 when executed on a guest machine) is repeatedly executed every 5 ms.

[0146] [Settings processing] Next, a description will be given of the "setting process" that can be executed in response to the process of S13 or S15 above. Fig. 30 is a flowchart showing the details of the setting process. In Fig. 30, first, based on the above arguments related to the call of the setting process, it is determined whether the communication type is local communication (whether the value of type is "Local") (S31). If the result of this determination is local communication (YES in S31), a value indicating "local communication" is set in the communication type identification data 321 (S32). On the other hand, if the communication type is Internet communication (NO in S31), a value indicating "Internet communication" is set in the communication type identification data 321 (S33).

[0147] Next, based on the above argument related to the call of the setting process, it is determined whether the game type is a common image type game (mode 1 or not) (S34). If the result of this determination is that the game is a common image type game (mode 1) (YES in S34), a value indicating "common image type" is set in the game type identification data 322 (S35). On the other hand, if the game type is an individual image type (NO in S34), a value indicating "individual image type" is set in the game type identification data 322 (S36).

[0148] Next, the shared game information 337 is set based on the values ​​related to the shared game information indicated by the above-mentioned arguments (S37). In S37, a game ID and a game name are added to the shared game information 337. When the user starts a game from the menu, the system software has already acquired the game name and game ID of the game, and therefore uses this information to add them to the shared game information 337. This completes the setting process.

[0149] Next, the "member recruitment process" executed in response to the process of S18 above will be described. FIGS. 31 and 32 are flowcharts showing the details of the member recruitment process. In FIG. 31, first, the communication type identification data 321 is referenced to determine whether the communication type is "local communication" (S41). If the result of this determination is local communication (YES in S41), first, member recruitment data is advertised (broadcast) using local communication (S42). This member recruitment data is generated so as to include host information including information on the user ID and MAC address of the host machine, and the shared game information 337.

[0150] Next, if a person who wishes to connect responds to the advertisement, information about the person who wishes to connect (which may include information about the controller ID to be used, etc.) and a predetermined UI including a dialogue about whether or not to allow the person to participate are displayed on the display of the host machine (S43). Note that if two controllers are connected and used on one guest machine, the number of participants is counted as two.

[0151] Next, processing related to whether to permit or reject participation is executed based on the host operation data 328. If participation is permitted, a participation permission notice is sent to the guest device, and if participation is rejected, a participation rejection notice is sent to the guest device (S44).

[0152] Next, after the participants are confirmed and the member recruitment process is requested, it is determined whether preparations for starting the game are complete based on the arguments indicating the maximum and minimum numbers, etc. (S45). If preparations are not complete yet (NO in S45), the process returns to S42 above and continues recruiting participants.

[0153] On the other hand, if the participants have been confirmed and preparations are complete (YES in S45), guest number information indicating the number of guest machines and a game start command instructing the start of the game are sent from the host machine to each guest machine (S46).

[0154] Next, the guest member information 324 and MAC address information 327 as described above are generated and stored in the DRAM 33 (S47).

[0155] Next, guest member information 325 for the application is generated based on the guest member information 324. Then, the guest member information 325 for the application is stored in the memory area indicated by the guest information storage address specified by the argument when the member recruitment process is requested (S48).

[0156] After that, the member recruitment process ends.

[0157] On the other hand, if the result of the determination in S41 above is that the communication type is "Internet communication" (NO in S41), the number of guests is determined based on the arguments indicating the maximum and minimum numbers when the member recruitment process was requested. Then, the chat member information 323 is referenced, and members (guest machines) who will participate in the game are selected by the user from among the chat partners through UI operations (S49).

[0158] Next, the selected guest machine is designated and a request to create a matching room is made to the server 4. Although not shown in the drawings, in response to this request, the server 4 appropriately executes a process to create a matching room.

[0159] Next, the status of the matching room is polled and a process of waiting for the participation of a guest machine is executed (S51). A process of displaying information about the guest machine that has joined on a predetermined UI is also executed. This information may also include information indicating the controller ID used by the guest machine.

[0160] Next, a process is executed to accept a participation confirmation operation (e.g., an OK button operation) from the guest machine via the UI by the host user (S52). When the confirmation operation is performed, a notification indicating permission to participate is sent to the guest machine that confirmed it. Then, a determination is made as to whether or not confirmation has been performed for all participating guests (S53). If confirmation has not yet been completed for all guests (NO in S53), the process returns to S51 and repeats. On the other hand, if confirmation has been completed (YES in S53), the host machine transmits the guest number information, the shared game information 337 including the used input function information 393, and a game start command to each guest machine (S54).

[0161] With regard to the timing of transmission of the shared game information 337, in this example, the shared game information 337 is sent after the participants of the game have been determined, but in other embodiments, the shared game information 337 may be sent to the server 4, for example, when a request to create a room is made. In this case, the shared game information 337 may be held by the server 4 as part of the room information, and may be transmitted from the server 4 to the guest machine.

[0162] Next, it is determined whether the game type is a common image type game (S55). If the result of this determination is that the game type is not a common image type game (NO in S55), this corresponds to a case where an individual image type game is to be shared via Internet communication. In this case, it is determined that game images will be transmitted via P2P communication, and guest member information 324 is stored in the DRAM 33 of the host machine (S58). This can result in the situation shown in FIG. 5 above.

[0163] On the other hand, if the game type is a common image game (YES in S55), it is then determined whether the number of guests is four or more (S56). If the result of this determination is that the number of guests is four or more (YES in S56), it is decided to transmit game images via server-mediated communication, and processing is executed in the server 4 to store participating member information 402 in association with the corresponding game sharing room (S57). This can result in the situation shown in FIG. 7 above. Thereafter, processing proceeds to S58 above, and the guest member information 324 is also stored in the DRAM 33 of the host machine. This is because, even in this situation, the app-oriented guest member information 325 can be used in exchanging operation data.

[0164] On the other hand, if the number of guests is three or less (NO in S56), the process proceeds to S58, where it is determined that game images will be transmitted via P2P communication, and guest member information 324 is stored in the DRAM 33 of the host machine. This results in the state shown in FIG. 6 above.

[0165] Next, the process proceeds to S48 described above, where the application-oriented guest member information 325 is generated, and the member recruitment process then ends.

[0166] Next, the "streaming start process" executed in response to the process of S19 above will be described. Fig. 33 is a flowchart showing the details of the streaming start process. In Fig. 33, first, the communication type identification data 321 is referenced to determine whether the communication type is local communication or not (S71). As a result, if it is local communication, the local streaming process described below is started (S72). On the other hand, if it is Internet communication (NO in S71), the Internet streaming process described below is started (S73). This ends the streaming start process.

[0167] Next, the local streaming process will be described in detail. The local streaming process is realized by executing the system software 301 (more specifically, the host program 303 and the local communication streaming program 304). FIG. 34 is a flowchart showing the details of the local streaming process. In FIG. 34, first, the game type identification data 322 is referenced to determine whether the game type is a common-image type game (S81). If it is a common-image type game (YES in S81), first, a common image is obtained. The common image is data stored in the frame buffer 34 based on the game program. When the local communication streaming program determines that a common-image type game is being executed based on the game type identification data 322 specified by the game program, it reads game image data from the frame buffer 34 as game image data to be transmitted to the guest device and transmits the game image data to the guest device. The acquired common image is then transmitted to the guest machine identified based on the app-oriented guest member information 325 and the MAC address information 327 (S82). The transmission of the common image in S82 is triggered by the game program issuing the display command described above. Thereafter, the process returns to S81 and is repeated.

[0168] On the other hand, in the case of an individual image type game (NO in S81), a guest image is read from the guest game image area 335 for each guest ID. That is, when the local communication streaming program determines that an individual image type game is being executed based on the game type identification data 322 specified by the game program, it reads game image data for each guest from the guest game image area 335 as game image data to be transmitted to the guest device and transmits it to each guest device. Then, the corresponding guest image is transmitted to the guest device identified based on the app-oriented guest member information 325 and the MAC address information 327 (S83). The transmission of the guest image in S83 is triggered by the game program issuing the display command described above for the guest image. Thereafter, the process returns to S81 and is repeated.

[0169] Next, the details of the Internet streaming process will be described. The Internet streaming process is realized by executing the system software 301 (more specifically, the host program 303, which is the Internet communication streaming program). FIG. 35 is a flowchart showing the details of the Internet streaming process. In FIG. 35, first, the game type identification data 322 is referenced to determine whether the game type is a common-image type game (S91). If it is a common-image type game (YES in S91), a common image is acquired (S92). When the Internet communication streaming program determines that a common-image type game is being executed based on the game type identification data 322 specified by the game program, it acquires game image data from the frame buffer 34 as game image data to be transmitted to the guest device. Next, it is determined whether the number of guests is less than four (S93). Note that this determination may be made based on the result of the determination (determination in S56) in the member recruitment process (FIG. 21), or, if the number of guests changes during the game, it may be made during the game based on the current number of guests. If the number of guests is less than four (YES in S93), the IP addresses corresponding to each guest machine are identified based on the guest member information 324 and chat member information 323, and the acquired common image is transmitted (S94). At this time, the common image is transmitted to each guest machine using P2P communication, as described above. The transmission of the common image in S94 is triggered by the game program issuing the display command described above. Thereafter, the process returns to S91, and the process is repeated.

[0170] On the other hand, if the number of guests is four or more (NO in S93), the acquired common image is sent to the server 4 (S96). In other words, in this case, the common image is sent to each guest via the server. Thereafter, the process returns to S91 and is repeated.

[0171] On the other hand, if the result of the determination in S91 above is that the game type is an individual image type game (NO in S91), each guest image is read from the guest game image area 335. That is, when the Internet communication streaming program determines that an individual image type game is being executed based on the game type identification data 322 specified by the game program, it reads game image data for each guest from the guest game image area 335 as game image data to be transmitted to the guest device. Then, based on the app-oriented guest member information 325, guest member information 324, and chat member information 323, an IP address corresponding to each guest machine is identified, and the acquired guest image is transmitted. In this case, too, the guest image is transmitted to each guest machine using P2P communication (S95). The transmission of the guest image in S95 is triggered by the game program issuing the display command described above for the guest image. Thereafter, the process returns to S91 above, and the process is repeated.

[0172] Next, the "operation data acquisition process" executed in response to the process of S21 above will be described. FIG. 36 is a flowchart showing the details of the operation data acquisition process. In FIG. 36, first, the communication type identification data 321 is referenced to determine whether the communication type is local communication (S101). If the result is local communication (YES in S101), then it is determined whether the local operation reception and storage process described below has already started (S102). If the execution has not yet started (NO in S102), the execution of the local operation reception and storage process described below is started. On the other hand, if the execution has already started (YES in S102), this process is skipped. Next, the operation data of each guest machine is acquired from the guest operation data area 330 (S104). On the other hand, if the result of the determination in S101 above is that the communication type is Internet communication (NO in S101), then it is determined whether the Internet operation reception and storage process described below has already started (S105). If the result of this determination is that the operation has not started (NO in S105), the Internet operation receiving and storing process described below is started (S106). On the other hand, if the operation has already started (YES in S102), the process of S106 is skipped. Then, the process proceeds to the process of S104, and the operation data of each guest machine stored in the guest operation data area 330 is acquired. Then, the operation data acquisition process ends.

[0173] FIG. 37 is a flowchart showing the details of the local operation reception and storage process that starts in the process of S103 described above. This process is triggered by the reception of operation data from a guest machine. In FIG. 37, first, it is determined whether or not operation data for each controller identified by the controller identification information has been transmitted from the guest machine (S211). This transmission is performed using local communication. If the result of this determination is that no data has been transmitted (NO in S211), this determination is repeated. In other words, the process waits for transmission of operation data from the guest machine.

[0174] The transmission of operation data from the guest machine will be described later. In this embodiment, in the case of local communication, the guest ID, controller ID, and multiple pieces of operation data accumulated over a predetermined period are transmitted to the host machine as a single unit for each game frame. In the host machine, the received data is temporarily stored in an operation reception buffer (not shown) as a process performed by the system software. At this time, the data is stored separately for each guest ID and controller ID. Then, in the "operation data acquisition process," the operation data corresponding to the guest ID and controller ID specified by the arguments is acquired from the operation reception buffer, thereby performing the process of receiving the operation data from the guest machine.

[0175] On the other hand, if it has been transmitted (YES in S211), operation data for each controller identified by the controller identification information is received. Then, the received operation data is decompressed into the guest operation data area 330, and the compressed data is classified and stored in each area corresponding to each input function (see FIG. 17 above) (S212).

[0176] Next, FIG. 38 is a flowchart showing details of the Internet operation reception and storage process started in the process of S106 described above. This process is triggered by receiving operation data from a guest machine. In FIG. 38, first, it is determined whether operation data for each controller identified by the controller identification information has been transmitted from the guest machine (S221). As described above, this transmission is performed via P2P communication. If the result of this determination is that no data has been transmitted (NO in S221), this determination is repeated. In other words, the system waits for transmission of operation data from the guest machine.

[0177] On the other hand, if the operation data has been transmitted (YES in S221), the operation data for each controller identified by the controller identification information is received. Then, the received operation data is decompressed and stored in the guest operation data area 330, classified into areas corresponding to the input functions (S222). In other words, the operation data of the guest machine is received immediately.

[0178] In other embodiments, the reception is not limited to being immediate, and the process of S222 may be executed in a cycle shorter than the game frame.

[0179] The operation data may be received, for example, as follows: First, each guest machine transmits a guest ID, a controller ID, and data indicating the operation content as a single unit to the host machine. In the host machine, the received data is temporarily stored in an operation reception buffer (not shown) as a process on the system software side. At this time, the data is stored separately for each guest ID and controller ID. Then, in the "operation data acquisition process," the operation data corresponding to the guest ID and controller ID specified by the arguments is acquired from the operation reception buffer, thereby performing the process of receiving the operation data from the guest machine.

[0180] This concludes the explanation of the various processes executed by the system software in response to requests using the API.

[0181] Next, various processes performed on the guest machine side will be described. Note that, in the guest machine as well, the queuing process of operation data as shown in Figures 26 to 29 is executed in the background by the system software of the guest machine.

[0182] FIG. 39 is a flowchart showing details of a guest-side startup process for starting processing related to the game sharing function on a guest machine. This process is started, for example, by selecting an item called "Game Sharing" from the home menu. Alternatively, this process may be started, for example, by pressing a dedicated button for the game sharing function. For ease of explanation, it is assumed here that the guest machine has already started a chat app and is in a predetermined chat room before starting this process. Operation data indicating operations performed on the guest machine is stored in the DRAM 33 of the guest machine.

[0183] 39, first, a selection screen (not shown) including the options of local communication or internet communication is displayed (S111). Next, it is determined whether local communication is selected (S112). If local communication is selected (YES in S112), local sharing start processing is executed (S113). On the other hand, if internet communication is selected (NO in S112), internet sharing start processing is executed (S114).

[0184] Fig. 40 is a flowchart showing the details of the local sharing start process. In Fig. 28, first, a search process for a host machine that is currently advertising is performed by a network scan using local communication (S121).

[0185] Next, the shared game information 337 and various information such as the MAC address of the host machine are obtained from the host machine found by the search and stored as shared game data 411. The information about the host machine is then displayed using a predetermined UI. Furthermore, the MAC address of the guest machine is transmitted as application data to the host machine selected by the guest user in the UI, and a connection request is made (S122). At this time, information such as the controller ID used by the guest machine may be transmitted together with the application data.

[0186] Next, a participation permission notice is received from the host machine, and then a game start instruction is received (S123).

[0187] Next, if a game start instruction is received, the local game sharing process is started (S124), and the local sharing start process ends.

[0188] Fig. 41 is a flowchart showing the details of the local game sharing process. In Fig. 41, first, a process for preparing to transmit operation data is executed (S131).

[0189] Figures 42 and 43 are flowcharts showing details of the above-mentioned operation data transmission preparation process. Figures 44 to 49 are diagrams for providing additional explanation of this process. In this process, data accumulated in the operation queue area 415 is extracted, compressed, and stored in a transmission packet to create one or more transmission packets 422, which are then stored in the transmission queue 421. In addition, if multiple controllers are connected to the guest machine, the following process is performed for each controller ID.

[0190] 42, first, operation data to be fetched from the operation data queuing area (hereinafter referred to as the fetch target) is identified based on the used input function information 393 included in the shared game information 413 (S231). For example, assume that the used input functions are a touch panel, a pad, and a motion sensor, and four pieces of touch panel data, three pieces of pad data, and three pieces of motion sensor data are stored in the operation queue area 415. In this case, a data group of "touch panel data 1, touch panel data 2, touch panel data 3, touch panel data 4, pad data 1, pad data 2, pad data 3, motion sensor data 1, motion sensor data 2, motion sensor data 3" is identified as the data to be fetched (it is assumed that the data with the smaller number is the data that was stored earlier).

[0191] Next, for the input function to be used, each data is fetched in the following fetch order: touch panel data → pad data → mouse data → motion sensor data, and converted into TLV format (S232). Each data is extracted from the fetch target so that the data size after conversion into TLV format does not exceed the free space in one transmission buffer 420 (S233). For example, if a touch panel, pad, and motion sensor are used as the input functions to be used, the data is fetched in the order described above, that is, touch panel data 1 to n → pad data 1 to n → motion sensor data 1 to n. Also, for example, if only a pad and motion sensor are used, the data is fetched in the order pad data 1 to n → motion sensor data 1 to n. Note that in S233, data may be extracted so that the compressed data size does not exceed the free space in transmission buffer 420.

[0192] Here, a supplementary explanation will be given regarding the fetch order. In this example, operation data is classified from the viewpoint of storing as much data as possible in the transmission data and from the viewpoint of data compression efficiency. Specifically, in this embodiment, operation data is classified into two types, "simple data" and "complex data," based on whether the data structure is simple or complex. Simple data is, for example, integer data, and complex data is, for example, floating-point data. Integer data, for example, when viewed in binary, is considered to have a large range of consecutive 0s and is considered to have a relatively simple data structure. In this example, control is performed to store simple data preferentially in the transmission buffer (transmission packet). This is because compressing integer data, which is likely to have consecutive 0s, collectively is considered to have high compression efficiency, and therefore, by compressing and storing simple data collectively, it is highly likely that more operation data can be stored in one transmission packet 422. In this example, an example will be described in which motion sensor data is floating-point data and the rest is integer data. Therefore, the fetch order of motion sensor data is controlled so that it comes after operation data of other input functions.

[0193] Furthermore, operation data for input functions classified as the same simple data is processed in descending order of data size, starting with the input function with the largest data size. In this example, the simple data is processed in descending order of data size, starting with touch panel data, followed by pad data, and then mouse data. For example, touch panel data is 500 bytes per data, pad data is 100 bytes per data, and mouse data is 80 bytes per data, etc. Then, by extracting data in descending order of data size, compressing it as described below, and storing it in a transmission packet, the possibility of storing it in a single transmission packet 422 increases, and packet space can be used more effectively. The same applies to complex data; if the operation data for multiple input functions is complex data, the input functions with the largest data size are processed first.

[0194] FIG. 44 is a schematic diagram showing an example of the above-mentioned fetching operation. Here, the explanation will be made assuming that the size of the transmission buffer 420 is 1500 bytes (already converted to TLV format), each piece of touch panel data is 500 bytes (already converted to TLV format), and each piece of pad data is 100 bytes (already converted to TLV format). Note that in FIG. 44, each piece of touch panel data is represented as "Tn" and each piece of pad data is represented as "Pn." Also, mouse data and motion data are not shown. FIG. 44 shows the first fetching operation in the processing loop for preparing to transmit operation data. In this case, since the transmission buffer has 1500 bytes of free space, three pieces of touch panel data (totaling 1500 bytes, already converted to TLV format) are first extracted.

[0195] Returning to Fig. 42, next, the extracted data are compressed together to generate compressed data, which is stored in the transmission buffer 420 (S233). In the example of Fig. 44, the three extracted data are compressed together to generate one piece of compressed data (here, referred to as first compressed data). Here, it is assumed that the size after compression is 1000 bytes. Then, as shown in Fig. 45, the first compressed data is stored in the transmission buffer 420. Therefore, at this point, the free space in the transmission buffer 420 is 500 bytes.

[0196] Returning to FIG. 42, next, it is determined whether all of the fetch targets have been processed (S234). If all have been processed (YES in S234), the transmission preparation process for the operation data ends. On the other hand, if all of the fetch targets have not yet been processed (NO in S234), it is determined whether the data size of the next fetch target to be extracted exceeds the free space in the transmission buffer 420 (S235). In the example of FIG. 45, the size of the touch panel data 4 is compared with the free space in the transmission buffer 420. If the result of this determination is that the size does not exceed the free space (NO in S235), the process returns to S232 and the above process is repeated. For example, as shown in FIG. 45, in the second fetch operation, the touch panel data 4 is extracted, compressed, and stored in the transmission buffer 420 as second compressed data, as shown in FIG. 46. Here, it is assumed that the size of the second compressed data is 400 bytes.

[0197] 46, the size of pad data 1, which is the data to be fetched next, is 100 bytes, which does not exceed the free space in the transmission buffer 420. Therefore, the above process is repeated, and pad data 1 is fetched as the third fetch operation. This data is then compressed and stored in the transmission buffer 420 as third compressed data, as shown in FIG. 47. Here, the size of the third compressed data is assumed to be 50 bytes, and the free space in the transmission buffer 420 at this point is assumed to be 50 bytes. In other words, the state in FIG. 47 is one in which the size of the data to be fetched next (pad data 2) exceeds the free space in the transmission buffer 420.

[0198] 42, if the result of the determination in S235 above is that the size of the data to be fetched next to be extracted exceeds the available space in the transmission buffer 420 (YES in S235), a transmission packet 422 is generated based on the data in the transmission buffer 420. Then, the generated transmission packet 422 is stored in the transmission queue 421 (S236). For example, based on the transmission buffer 420 in FIG. 47 above, a first transmission packet 422 as shown in FIG. 48 is generated. Specifically, the first transmission packet 422 is generated by adding a header to the content of the transmission buffer 420 as the payload. Then, this transmission packet 422 is stored in the transmission queue 421.

[0199] 45, for example, if the free space in transmission buffer 420 is 400 bytes, a first transmission packet containing only the first compressed data will be generated. Then, touch panel data 4 will be stored in a second transmission packet that will be generated separately later.

[0200] Returning to FIG. 43, next, the transmission buffer 420 is cleared (S237). Next, it is determined whether or not the number of transmission packets stored in the transmission queue 421 has reached the upper limit (S238). If the upper limit has not been reached (NO in S238), the process returns to S232 above and is repeated. As a result, transmission packets are subsequently generated, such as the second transmission packet, the third transmission packet, and so on. Furthermore, in generating each transmission packet, the operation data is extracted in the fetch order as described above. Then, as shown in FIG. 49, the generated transmission packets are sequentially stored in the transmission queue 421.

[0201] On the other hand, if the upper limit has been reached (YES in S238), the transmission preparation process for the operation data ends.

[0202] Returning to FIG. 41, next, a process is executed in which each transmission packet stored in the transmission queue 421 is transmitted by local communication to the MAC address of the host machine (S132). During this transmission, transmission control is performed using the A-MPDU function. As a result, as shown in FIG. 50, multiple transmission packets are grouped together and transmitted as one transmission process. In FIG. 50, if the first transmission packet is considered to be the first transmission unit, the second transmission packet is considered to be the second transmission unit, and the third transmission packet is considered to be the third transmission unit, then the group of the wireless header plus the first to third transmission packets as shown in FIG. 50 can be said to be a fourth transmission unit. Transmission control is performed using the A-MPDU function for this fourth transmission unit.

[0203] 41, next, the operation queue area 415 is cleared (S133). Therefore, if there is any operation data remaining in the operation queue area 415 that did not fit into the send queue 421 at this point, it will be discarded.

[0204] In another embodiment, the data may be deleted from the operation queue area 415 at the time when the data is retrieved from the operation queue area 415 and stored in the transmission buffer 420 (at the time of S233 above).

[0205] Next, the game image (common image or individual image) transmitted to the guest is received using local communication (S134). The received game image is then displayed on the display 35 of the guest machine (S135). After that, the process returns to S131 and repeats until the game ends. Note that the processes of S134 and S135 are executed at a frame rate based on the game frame information included in the shared game information 337 received in S122.

[0206] Next, the details of the internet sharing start process will be described. Fig. 51 is a flowchart showing the details of the internet sharing start process. In Fig. 51, first, a process is executed to search for a host machine (a matching room where a host is waiting) that is recruiting participants for game sharing (S141).

[0207] Next, information about the host machine (matching room) found as a result of the search is displayed on the display of the guest machine using a predetermined UI. Furthermore, the IP address of the guest machine is sent to the host machine selected by the guest user in the UI, and a connection request (a request to enter the matching room) is made (S142). At this time, information such as the controller ID used by the guest machine may be sent.

[0208] Next, a participation permission notification is received from the host machine. Once the participation permission notification is received, entry into the matching room is performed. Furthermore, the game type identification data 322, the guest number information, the shared game information 337, and a game start instruction transmitted from the host machine are received (S143). The game type identification data 322 and the guest number information are stored appropriately in the DRAM 33 of the guest machine.

[0209] Once the game start command is received, a guest image reception process, which will be described later, is then initiated (S144). At S144, it is determined whether to use P2P communication or communication via the server for receiving game images, based on the guest count information transmitted from the host machine. Next, based on the input function information 393 included in the shared game information 337, a transmission process of operation data corresponding to the input functions to be used in this game sharing is initiated (S145). The internet sharing start process then ends. The guest image reception process and the operation data transmission process will be described below.

[0210] FIG. 52 is a flowchart showing details of the guest image reception process (processing started in S144). This process is repeatedly executed for each game frame. First, based on the game type identification data 322 and guest number information received from the host machine, a game image (common image or guest image) transmitted to a guest is received using Internet communication, communication via a server, or P2P communication (S251). Specifically, if the game type is a common image type game and the number of guests is four or more, the common image transmitted to the guest is received by communication via a server. In other cases, the common image is received using P2P communication.

[0211] Next, the received game image is displayed on the display 35 of the guest machine (S252). After that, the process returns to S251 and the process is repeated until the game ends.

[0212] 53 to 56 are flowcharts showing details of the operation data transmission process (processing started by S145) corresponding to each input function in the guest machine. First, FIG. 53 is a flowchart showing details of the touch panel data transmission process. In FIG. 53, first, it is determined whether or not queuing of touch panel data to the operation queue area 415 has occurred (S261). In other words, the queuing of touch panel data to the queue area triggers the execution of the process described below.

[0213] If the result of the above determination is that queuing of touch panel data has not occurred (NO in S261), the determination of S261 is repeated. If queuing of touch panel data has occurred (YES in S261), the touch panel data stored in touch panel data area 416 (in this case, only one piece of touch panel data is stored) is then formatted in TLV format, and multiple pieces of operation data (which may include pad data and mouse data) that have been extracted as storable in the transmission buffer are compressed together to generate a transmission packet that includes the touch panel data (S262).

[0214] Next, the generated transmission packet is transmitted to the IP address of the host machine via P2P using Internet communication (S263).

[0215] Next, the touch panel data area 416 is cleared (S264). This completes the touch panel data transmission process. In the case of game sharing via Internet communication, this process allows touch panel data to be transmitted to the host machine immediately upon queuing, without waiting for the passage of a game frame.

[0216] 54 is a flowchart showing the details of the pad data transmission process. This process is similar to the touch panel data transmission process described above, except that pad data is used instead of touch panel data. That is, the following process is executed: it is determined whether pad data queuing has occurred (S271); if queuing has occurred (YES in S271), a transmission packet including the pad data is generated (S272), the packet is transmitted to the host device via P2P (S273), and the pad data area 417 is cleared (S274).

[0217] 55 is a flowchart showing details of the mouse data transmission process. This process is similar to the touch panel data transmission process described above, but with mouse data as the target. That is, the following process is executed: it is determined whether mouse data queuing has occurred (S281); if queuing has occurred (YES in S281), a transmission packet including the mouse data is generated (S282), and the packet is transmitted to the host device via P2P (S283); and the mouse data area 418 is cleared (S284).

[0218] 56 is a flowchart showing the details of the motion sensor data transmission process. This process is similar to the touch panel data transmission process described above, but targets the motion sensor data. That is, the following process is executed: it is determined whether queuing of motion sensor data has occurred (S291); if queuing has occurred (YES in S291), a transmission packet including the motion sensor data is generated (S292), the packet is transmitted to the host device via P2P (S293), and the motion sensor data area 419 is cleared (S294).

[0219] This concludes the explanation of the various processes in the guest machine.

[0220] Next, the processing of the server 4 when game images are transmitted and received via server-mediated communication will be described. FIG. 32 is a flowchart showing details of the processing of the server 4 in the mode described in FIG. 5 above. This processing can be executed by the server processor. It is also assumed that a game sharing room and various related data such as those shown in FIG. 13 above have been created prior to this processing. In FIG. 32, first, a common image is received from the host machine (S161). Next, the participating member information 402 of the game sharing room in which the host machine is participating is referenced to identify the IP addresses of the guest machines to which the image is to be sent (S162). Next, the common image is sent to each guest machine (S163). Thereafter, the process returns to S161 above and the process is repeated. This concludes the description of the server processing.

[0221] As described above, in this embodiment, the system software is configured to handle functions common to most games, such as member recruitment processing, operation data acquisition processing, and game image transmission processing, and these functions are accessible from the game AP via the API described above. By simply initially specifying parameters appropriate for the game being executed, the game AP can execute member recruitment processing, operation data acquisition processing, and game image transmission processing using the same instruction codes, regardless of the communication method or game type (individual image / common image). This makes it easier to execute appropriate processing and reduces the development burden on application developers.

[0222] In addition, by using P2P communication for common images, communication delays can be reduced. On the other hand, in individual image games with a certain number of guest machines or more, communication via a server can be used, which has the advantage of avoiding the processing load of directly transmitting images from the host machine to a certain number of guest machines or more.

[0223] In addition, in this embodiment, when sharing a game, only the input functions to be used in the game are specified, and control is exercised so that operation data relating to unused input functions is not transmitted. This reduces the number of transmission packets. Furthermore, in this embodiment, when generating transmission packets, operation data for the four input functions is extracted from the accumulated operation data queue in the order described above, compressed, and stored in the packet. This improves the efficiency of storing operation data in one transmission packet, reduces the number of packets to be transmitted, and improves communication efficiency.

[0224] Furthermore, in this embodiment, when a game is shared via local communication, the operation data transmitted from the guest machine to the host machine is controlled to transmit all accumulated operation data for each game frame, as described above. In this embodiment, accumulating and transmitting operation data allows multiple pieces of operation data to be compressed together before transmission, thereby reducing communication volume. Furthermore, while the A-MPDU function is utilized, A-MPDU allows packets to be transmitted more efficiently by minimizing the intervals between packets and transmitting packets in batches. Therefore, in an environment where A-MPDU is available, controlling the transmission of multiple packets in batches for each game frame, as in this embodiment, allows for more effective use of the A-MPDU function than transmitting packets in small batches. Furthermore, since the communication bandwidth is limited in local communication (compared to Internet communication), transmitting packets in batches as described above allows for more efficient use of the limited communication bandwidth.

[0225] On the other hand, when using internet communication, it is believed that delays in receiving operation data from guest machines on the host machine have a greater impact on game processing. Therefore, when sharing a game over the internet, the operation data from the guest machine is sent immediately without waiting for a game frame. This allows for appropriate game processing that reflects the operation details of the guest machine.

[0226] [Variations] In the above embodiment, an example was given in which a matching room was used to recruit members for game sharing using Internet communication. The member recruitment process is not limited to this matching room method, and other methods may be used. For example, the host user may recruit members by designating (inviting) specific people from among chat members. Alternatively, for example, members may be recruited by designating specific users from a user list (e.g., a friend list) registered on the host machine. In this case, for example, invitation data indicating an invitation to multiplayer play via game sharing may be transmitted to the guest machine. The guest machine may receive the invitation data and display a UI inquiring whether or not to accept the invitation. Then, the guest user may perform an operation to accept the invitation, thereby participating in multiplayer play.

[0227] In addition, in this embodiment, the individual image type game and the common image type game are separate game APs, but in other embodiments, a single game AP may have a common image type game mode and an individual image type game mode. In this case, when processing related to each game mode is started, the "type saving processing" may be called using arguments corresponding to each game mode.

[0228] Furthermore, a game system is an example of an information processing system, and the information processing system may be a system in which a game is not executed.

[0229] In the above embodiment, the game sharing function is used as an example, and an example is given in which the communication type and game type are specified when the "type saving process" is executed. In other embodiments, only one of these may be used. For example, consider an AP that is not a game AP, and supports the above-mentioned "local communication" and "internet communication" as communication modes, but only uses a fixed screen as the AP screen. An API for such an AP may be used that specifies only the communication type as an argument. Furthermore, for example, an API for a game device that does not support "local communication" and can only use "internet communication" may be used that specifies only the communication type as an argument.

[0230] In the above embodiment, when using the game sharing function, an example was given in which the game AP uses the member recruitment process, operation data reception process, and game image transmission process via the API described above. In other embodiments, depending on the content of the application, only one of these processes may be used using the API described above. For example, when executing a specific application that does not use the game sharing function, only the member recruitment process described above may be used. Also, for example, depending on the application, only the operation data acquisition process may be used using the API described above.

[0231] As another example, the above-mentioned simple data and complex data may be classified based on whether the values ​​that the data can take are within a predetermined numerical range. For example, data that uses a numerical value within a range that uses only 11 bits out of 32 bits may be treated as the above-mentioned simple data, since the compression efficiency from the 12th bit onwards is considered high. Furthermore, data that uses a numerical range that uses all 32 bits may be treated as complex data.

[0232] In the above embodiment, when fetching, if the size of the next data to be fetched is larger than the free space in the transmission buffer, the contents of the transmission buffer are temporarily confirmed at that time and a transmission packet is generated. In other embodiments, if the size of the next data to be fetched is larger than the free space in the transmission buffer, and if there is any data smaller than the free space among the data to be fetched, that data may be extracted, compressed, and stored. For example, in the situation shown in FIG. 45, if the free space in the transmission buffer 420 is 400 bytes, the next touch data 4 is larger than the free space in the transmission buffer, but the next pad data 1 is smaller than the free space. In this case, pad data 1 to pad data 3 may be extracted and compressed / stored. In other words, appropriate operation data may be extracted from the remaining fetch targets within the free space in the transmission buffer, and compressed / stored. In this case, touch data 4 is stored in the next transmission packet to be created.

[0233] Furthermore, in other embodiments, the compression process for storing operation data in a transmission packet may be performed as follows. For example, in the above example, the data types are divided into two types: simple data and complex data. In the above example, there is only one type of complex data (motion sensor data). In this regard, the complex data may relate to two or more input functions. In this case, for complex data relating to two or more input functions, the simple data may be compressed together in the same manner, or each input function may be compressed separately.

[0234] Furthermore, with regard to storing operation data in transmission packets, the above example shows an example in which simple data is first compressed and stored, and then similar processing is performed on complex data. In the above processing example, operation data of different data types may be stored in the same transmission packet, depending on the free space in the transmission buffer. In this regard, in other embodiments, control may be exercised so that operation data of different data types is stored in different transmission packets. In other words, operation data for input functions of different data types among multiple input functions may be stored separately in transmission packets. Furthermore, in still other embodiments, control may be exercised so that operation data of the same data type is stored in separate transmission packets for each input function.

[0235] Furthermore, the data types of the operation data may be classified into three or more types. In this case, the same data types may be compressed together.

[0236] Furthermore, the order in which the operation data (input functions) are fetched is merely an example, and the operation data for each input function may be fetched in an order different from the above.

[0237] Furthermore, with regard to transmission of operation data from a guest machine when sharing a game over the Internet, the above embodiment illustrates an example in which the operation data is transmitted immediately. In this regard, other embodiments may perform the following control. Operation data for input functions to be used may be retrieved from the operation queue area 415 at a cycle shorter than the game frame and transmitted all at once. For example, if the game frame is 16.7 ms, control may be performed such that operation data for input functions to be used is retrieved from the operation queue area 415 at a cycle shorter than this, 5 ms, and transmitted all at once to the host machine. After transmission, the operation queue area 415 may be cleared. Note that, in this specification, "a cycle shorter than the game frame" refers to transmission at a cycle shorter than the frame rate when the frame rates of the host machine and guest machine are the same. However, when the frame rates of the host machine and guest machine are different, this term also includes transmission at a cycle shorter than the frame rate of the guest machine, and also includes transmission at a cycle shorter than the frame rate of the host machine (in this case, the cycle may be the same as the frame rate of the guest machine). By transmitting at a cycle shorter than the frame rate of the guest machine, for example, transmission is faster than in the case of local wireless communication, allowing the host machine to process the game based on more recent operation data.By transmitting at a cycle shorter than the frame rate of the host machine, transmission frequency is higher than the host's game processing cycle, allowing the host to process the game based on more recent operation data.

[0238] Furthermore, in the above example, at a certain point in time (the same game frame cycle), all operation data relating to the input function being used in the operation queue area 415 was sent, including data when no operation was occurring (effectively empty data). In this regard, in other embodiments, it is possible to select and send only operation data indicating that an operation has occurred (data with content), without sending essentially empty data.

[0239] In another embodiment, when a change occurs in the operation content (operation state), the changed data may be sent. For example, when operation data of a touch panel changes from an untouched (non-input) state to a touched state, touch panel data may be sent.

[0240] In another embodiment, with regard to the transmission of operation data from a guest machine when sharing a game via Internet communication, control may be performed to switch between a control (first transmission control) in which operation data is transmitted immediately as soon as it is generated as described above, and a control (second transmission control) in which operation data is retrieved from the operation queue area 415 and transmitted at a cycle shorter than the game frame as described above, based on predetermined conditions.

[0241] In another embodiment, each game device may be configured to execute an application program. In this case, operation data may be transmitted and received between the game devices. In this case, the transmission and reception of operation data may be controlled differently depending on whether the communication is local or over the Internet.

[0242] Furthermore, with regard to the timing of transmitting the used input function information 393, the embodiment described above shows an example in which recruitment data including the used input function information 393 is advertised when recruiting members. In another embodiment, after the participating members are determined, the host machine may transmit the used input function information 393 to the guest machine. Furthermore, the used input function information 393 may be transmitted to each guest machine individually, without being limited to being transmitted by advertisement.

[0243] Furthermore, if the game AP is a game AP capable of executing multiple games, the input functions to be used may be different for each game. In this case, the input functions to be used may be predetermined for each game. Then, when starting each game, the host machine may transmit the input function information to the guest machine.

[0244] Furthermore, even when the same terminology is used to describe data in the above explanation, the data does not necessarily have to be completely identical. At least, if certain information is substantially conveyed between one piece of data and another piece of data, they may be considered to be the same data.

[0245] Furthermore, the program that causes a computer to execute each process may be a single program, or a group of programs including multiple programs. "A certain program" does not necessarily mean a single program, but may include a group of programs. Furthermore, a program does not necessarily have to be stored in one device. "A certain program" may refer to the entire set of programs stored in multiple devices included in an information processing system, for example.

[0246] At least a part of the series of processes described above may be executed by a server-side device in an information processing system including a terminal-side device and a server-side device capable of communicating with the terminal-side device via a network. Note that the server may be configured by a plurality of information processing devices, and the processes may be shared and executed by the plurality of information processing devices.

[0247] Although the present embodiment and its modifications have been described above, these descriptions are merely illustrative in every respect and are not intended to limit the scope of the present embodiment and its modifications. It goes without saying that various improvements and modifications can be made to the present embodiment and its modifications. [Explanation of symbols]

[0248] 1. Information Processing Systems 3. Gaming devices 4 Server

Claims

1. An information processing system capable of executing application programs and system programs, The application program is installed on a computer. a process of inputting first identification information indicating whether the application program uses a first communication method or a second communication method via an API (Application Programming Interface) for the system program; executes a process of requesting execution of a predetermined communication process via an API for the system program using a command common to the first communication method and the second communication method; The system program includes: executes a process of acquiring and storing the first identification information in response to input of the first identification information via the API; An information processing system that, in response to the request via the API, executes the specified communication processing by executing different processing depending on whether the first communication method or the second communication method is used based on the stored first identification information.

2. the first communication method is local communication; The information processing system according to claim 1 , wherein the second communication method is Internet communication.

3. the predetermined communication process includes a first process in which the host device receives operation data from the guest device, and a second process in which the host device transmits a game image generated by using the operation data to the guest device; an instruction code in the application program for executing the first process and the second process via the API is a common instruction code for a case where the first communication method is used and a case where the second communication method is used; The information processing system according to claim 1 .

4. the predetermined communication process further includes a third process in which the host device recruits the guest device; an instruction code in the application program for executing the third process via the API is a common instruction code for a case where the first communication method is used and a case where the second communication method is used; The information processing system according to claim 3 .

5. The third process includes: a process of determining a communication method designated by the application program based on the stored first identification information; 5. The information processing system according to claim 4, further comprising a process of recruiting the guest device using broadcast communication when the first communication method is specified, and recruiting the guest device using a matching room method or by specifying a predetermined partner registered in the host device when the second communication method is specified.

6. The application program further causes a computer to execute a process of specifying, via the API, a memory address at which information about the guest device is to be saved; the system program executes a process of storing information related to the guest device in the memory address acquired via the API; The application program further causes a computer to execute a game process using the information related to the guest device stored at the memory address. The information processing system according to claim 5 .

7. the information related to the guest device is presence information of the guest device; The information processing system according to claim 6 , wherein the game processing executes game processing for each of the guest devices based on the presence information.

8. 6. An information processing system as described in claim 5, wherein, in the specified communication processing, when the communication method indicated by the first identification information is a first communication method, MAC address information is stored and used as communication partner information, and when it is a second communication method, IP address information is stored and used as communication partner information.

9. the host device selectively executes a first mode in which one game image is generated and transmitted to all guest devices, and a second mode in which a game image is generated for each guest device and transmitted to that guest device; The application program further causes the computer to executes, via the API, a process of outputting second identification information indicating whether the program is to be executed in the first mode or the second mode; executing a process of generating the single game image when executed in the first mode, and generating and saving a game image for each guest device when executed in the second mode; The system program further includes: A process of storing the second identification information output via the API; An information processing system as described in any one of claims 3 to 8, wherein, in the specified communication processing, if the first mode is specified in the second identification information, the one game image is read out and transmitted to all guest devices, and if the second mode is specified, the game image for each guest device is read out and transmitted to each guest device.

10. the predetermined communication process further includes a fourth process of searching for a communication partner, 2. The information processing system according to claim 1, wherein an instruction code for executing the fourth process in the application program is a common instruction code for using the first communication method and for using the second communication method.

11. the first communication method is local communication; the second communication method is internet communication, The fourth process is a process of determining a communication method designated by the application program based on the stored first identification information; The information processing system of claim 10, further comprising a process for searching for the communication partner using broadcast communication when the local communication is specified, and for searching for the communication partner by using a matching room method or by specifying a registered predetermined partner when the Internet communication is specified.

12. The application program further causes the computer to execute a process of specifying a memory address for storing information about the communication partner via the API; the system program causes the computer to execute a process of storing information about the communication partner at the memory address specified via the API; the application program causes the computer to execute game processing using the information about the communication partner stored in the memory address; 12. The information processing system according to claim 10 or 11.

13. 13. The information processing system according to claim 12, wherein, in the specified communication processing, when the communication method indicated by the first identification information is the first communication method, MAC address information is stored and used as communication partner information, and when the communication method is the second communication method, IP address information is stored and used as communication partner information.

14. the predetermined communication process includes a fifth process of acquiring operation data of a communication partner, an instruction code for executing the fifth process via the API in the application program is a common instruction code for a case where the first communication method is used and a case where the second communication method is used; The information processing system according to claim 1 .

15. The application program further causes the computer to execute a process of specifying a memory address for storing the operation data via the API; The system program further causes the computer to execute a process of saving the operation data at the specified memory address; 15. The information processing system according to claim 14, wherein the application program further causes the computer to acquire the operation data from the specified memory address and execute game processing.

16. the application program further causes the computer to execute a process of specifying a memory address for saving the operation data for each controller ID of one or more controllers used in the information processing system; the system program further causes the computer to execute a process of saving the operation data in the memory address designated for each of the controller IDs; The information processing system according to claim 15 , wherein the game processing is executed by acquiring the operation data from a memory address for each of the controller IDs.

17. On the computer, a process of acquiring and storing first identification information from an application program in response to a first request from the application program via an API, the first identification information indicating whether the application program uses a first communication method or a second communication method; and a process of executing a predetermined communication process by executing different processes depending on whether the first communication method or the second communication method is used based on the stored first identification information in response to a second request from the application program via the API.

18. the predetermined communication process includes a first process in which the host device receives operation data from the guest device, and a second process in which the host device transmits a game image generated by using the operation data to the guest device; 18. The system program according to claim 17, wherein an instruction code for executing the first process and the second process via the API in the application program is a common instruction code when the first communication method is used and when the second communication method is used.

19. The system program further causes the computer to a process of acquiring and storing second identification information indicating whether the application program is executed in a first mode in which one game image is generated and transmitted to all guest devices, or in a second mode in which a game image is generated for each guest device and transmitted to that guest device, in response to the first request from the application program via the API; 19. The system program of claim 18, wherein, in the specified communication processing, if the first mode is specified in the second identification information, the system reads out the one game image generated and saved by the application program and transmits it to all guest devices, and if the second mode is specified, the system reads out the game image for each guest device generated and saved by the application program and transmits it to each guest device.

20. the predetermined communication process further includes a third process of searching for a communication partner, 18. The system program according to claim 17, wherein an instruction code for executing the third process via the API in the application program is a common instruction code for using the first communication method and for using the second communication method.

21. the predetermined communication process includes a fourth process of acquiring operation data of a communication partner, 18. The system program according to claim 17, wherein an instruction code for executing the fourth process via the API in the application program is a common instruction code for using the first communication method and for using the second communication method.

22. On the computer, a process of inputting first identification information indicating whether the first communication method or the second communication method is to be used via an API for a system program; an application program that executes a process of requesting execution of a predetermined communication process via an API for the system program using a command common to the first communication method and the second communication method.

23. the predetermined communication process includes a first process in which the host device receives operation data from the guest device, and a second process in which the host device transmits a game image generated by using the operation data to the guest device; 23. The application program according to claim 22, wherein an instruction code for the application program to request execution of the first process and the second process via the API is a common instruction code for when the first communication method is used and when the second communication method is used.

24. The application program further causes the computer to a process of outputting, via the API, second identification information indicating whether the application is executed in a first mode in which one game image is generated and transmitted to all guest devices, or in a second mode in which a game image is generated for each guest device and transmitted to that guest device; 24. The application program of claim 23, which generates the single game image when executed in the first mode, and generates and saves a game image for each guest device when executed in the second mode.

25. the predetermined communication process further includes a third process of searching for a communication partner, 23. The application program according to claim 22, wherein an instruction code for executing the third process via the API in the application program is a common instruction code for using the first communication method and for using the second communication method.

26. the predetermined communication process includes a fourth process of acquiring operation data of a communication partner, 23. The application program according to claim 22, wherein an instruction code for executing the fourth process via the API in the application program is a common instruction code for using the first communication method and for using the second communication method.

27. An information processing method for causing a computer of an information processing system capable of executing an application program and a system program to execute the program, comprising: The application program is installed on the computer. a process of inputting first identification information indicating whether the application program uses a first communication method or a second communication method via an API for the system program; executes a process for requesting execution of a predetermined communication process via the API using a command common to the first communication method and the second communication method; The system program causes the computer to executes a process of acquiring and storing first identification information in response to input of the first identification information via the API; An information processing method in which, in response to the request via the API, different processing is performed depending on whether the first communication method or the second communication method is used, based on the stored first identification information, thereby executing the specified communication processing.

Images