DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20, 25-44, 49-68 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. According to the specification, the invention relates to a method of providing a virtual environment responsive to player inputs. Exemplary claims 1, 11, 25, 35, 49 and 59 includes the following underlined claim elements:
1. A method of a video game utilizing a lockstep engine, the method comprising: receiving user input information from at least one of a plurality of users of a match of the video game that utilizes the lockstep engine, each of the user input information from the at least one of the plurality of users being associated with a current frame of a plurality of frames of the lockstep engine based on the respective user input information being received within a current time interval of the current frame; and sending the current frame of the user input information irrespective of whether the user input information is received from each of the plurality of users within the current time interval.
11. A method of a video game utilizing a lockstep engine, the method comprising: transmitting, to a server, a request to join a match after the match has started, wherein the match is in the video game that utilizes the lockstep game engine; receiving, in response to the request to join, game state information of the match for a plurality of time intervals of the match of the video game, the game state information comprising information for each of a plurality of time intervals of the lockstep game engine; and rendering a plurality of video frames of the match in the video game based on the game state information for each of the plurality of time intervals.
25. An apparatus for a video game utilizing a lockstep engine, the apparatus comprising: processing circuitry configured to: receive user input information from at least one of a plurality of users of a match of the video game that utilizes the lockstep engine, each of the user input information from the at least one of the plurality of users being associated with a current frame of a plurality of frames of the lockstep engine based on the respective user input information being received within a current time interval of the current frame; and send the current frame of the user input information irrespective of whether the user input information is received from each of the plurality of users within the current time interval.
35. An apparatus for a video game utilizing a lockstep engine, the apparatus comprising: processing circuitry configured to: transmit, to a server, a request to join a match after the match has started, wherein the match is in the video game that utilizes the lockstep game engine; receive, in response to the request to join, game state information of the match for a plurality of time intervals of the match of the video game, the game state information comprising information for each of a plurality of time intervals of the lockstep game engine; and render a plurality of video frames of the match in the video game based on the game state information for each of the plurality of time intervals.
49. A non-transitory computer-readable storage medium storing computer-readable instructions thereon, which, when executed by processing circuitry, cause the processing circuitry to perform a method of a video game utilizing a lockstep engine, the method comprising: receiving user input information from at least one of a plurality of users of a match of the video game that utilizes the lockstep engine, each of the user input information from the at least one of the plurality of users being associated with a current frame of a plurality of frames of the lockstep engine based on the respective user input information being received within a current time interval of the current frame; and sending the current frame of the user input information irrespective of whether the user input information is received from each of the plurality of users within the current time interval.
59. A non-transitory computer-readable storage medium storing computer-readable instructions thereon, which, when executed by processing circuitry, cause the processing circuitry to perform a method of a video game utilizing a lockstep engine, the method comprising: transmitting, to a server, a request to join a match after the match has started, wherein the match is in the video game that utilizes the lockstep game engine; receiving, in response to the request to join, game state information of the match for a plurality of time intervals of the match of the video game, the game state information comprising information for each of a plurality of time intervals of the lockstep game engine; and rendering a plurality of video frames of the match in the video game based on the game state information for each of the plurality of time intervals.
The underlined claim elements above are directed in user interaction in a game environment and applying game logic to user interactions which is the court enumerated abstract idea of certain methods of organizing human activities, following rules or instructions. The various dependent claims only further detail the abstract ideas or constitute insignificant extra solution activity and consequently are also considered abstract ideas.
This judicial exception is not integrated into a practical application because the claims do not recite additional elements that would integrate the abstract idea into a practical application. The recited “processing circuitry”, “server”, “computer-readable storage medium” amount to implementing the abstract idea on a general purpose computer, and/or do no more than generally link the use of a judicial exception to a particular technological environment or field of use. Applicant’s specification states “As described herein, a device, such as the computing device 100, may refer to any user device, apparatus, or system configured to perform one or more techniques described herein. For example, a user device may be a client device, a computer (e.g., a personal computer (PC)), a desktop computer, a laptop computer, a tablet computer, a computer workstation, or a mainframe computer, a phone, a smart phone, a video game platform or console, a handheld device (e.g., a portable video game device or a personal digital assistant (PDA)), a wearable computing device (e.g., a smart watch), an augmented reality device, a virtual reality device, a display or display device, a television, a television set-top box, a network device, a digital media player, a video streaming device, a content streaming device, an in-car computer, or any other device configured to perform one or more techniques described herein. Processes herein may be described as performed by a particular component (e.g., a CPU), but, in further aspects, can be performed using other processing components configured to perform the described processes.
The computing device 100 may be any user device with a processor and memory. While many user devices on which to play video games are different, the user devices may share some common characteristics. For instance, the user devices may have some method of capturing user input such as a computer mouse, keyboard, remote control, touchscreen, game controller, or the like. In addition, the different user devices may also have some method of displaying a two-dimensional image using a display such as a TV screen or computer monitor (e.g., LED, LCD, or OLED) or touchscreen. In some devices, the user devices may have some method of displaying a three-dimensional image using a display such as a head-set display or augmented reality device. The user devices may have some form of processing CPU, although the capability often widely varies in terms of capability and performance. Further, in some aspects, the user devices may have a connection to the internet, such as an Ethernet connection, WiFi connection or mobile phone cell data connection”, [0047] & [0048]). This supports a conclusion that the method operates in a general computing environment and that the claim provides mere instructions to apply the judicial exception on a computer. There is no improvement made to computer technology since the claims are directed to providing a virtual environment to the player and responding to player input. This is not related to a long standing problem in computer technology. Additionally, there is no practical application as there is no particular machine that is used to implement the claim language and only generic computer components are used to perform the invention. Also, there is no transformation of the machine used in the application into a different state or thing. Lastly, the claims do not attempt to apply the abstract idea in a meaningful way beyond simply using a generic computer. The various dependent claims only further detail the abstract idea or are insignificant extra solution activity and also fail to rise significantly more than the abstract ideas.
The claims do not recite additional elements, individually or in combination, that amount to significantly more than the abstract idea. As discussed above with respect to the lack of a practical application, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component. The same analysis applies here, i.e., mere instructions to apply an exception using generic computer component(s) cannot provide an inventive concept. The additional element(s) or combination of elements in the claim(s) other than the abstract idea(s) computer network system: (i) mere instructions to implement the idea on a computer, and/or (ii) recitation of generic computer structures that serves to perform generic computer functions that are well-understood, routine, and conventional activities previously known to the pertinent industry. Viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself
Therefore, the claims are directed to an abstract idea that lacks significantly more and thus is not patent eligible.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-3, 25-27 and 49-51 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Cook (pub. no. 20220305380).
Regarding claim 1, Cook discloses a method of a video game utilizing a lockstep engine (“The embodiments disclosed herein implement event synchronization in an online game. A central computing device, such as a game server, time synchronizes with each of a plurality of other computing devices, such as personal computers, game consoles, and/or mobile devices, executing an online game. The central computing device determines an event to be depicted on each of the computing devices at a future time and sends, to the computing devices, event information that identifies the event and an event depiction timestamp that identifies a future time at which the event is to be depicted by the computing devices.
The computing devices receive the event information, and, at the designated future time, concurrently depict the event to each of the players. The computing devices then receive user input from the players in response to the depiction of the event. Each computing device generates a timestamp, which identifies the time of the user input, and action information, which identifies the user input, and sends the timestamp and the action information to the central computing device.
The central computing device collects the information sent by the computing devices, and determines, based on the timestamps and the user inputs, an appropriate next game event to be depicted. The central computing device sends to the computing devices the next game event to be depicted by the computing devices and an event timestamp that identifies the future time at which the next game event is to be depicted to the players. In this manner, the central computing device and the computing devices can ensure perfectly synchronized events such that the central computing device can make precise determinations as to which players acted at which times, irrespective of significant network delays among the different computing devices and the central computing device”, [0021] - [0023]),
the method comprising: receiving user input information from at least one of a plurality of users of a match of the video game that utilizes the lockstep engine, each of the user input information from the at least one of the plurality of users being associated with a current frame of a plurality of frames of the lockstep engine based on the respective user input information being received within a current time interval of the current frame (“Based on the network delay values associated with the computing device 14-1 and the computing device 14-N, the game controller 34 determines a timing window. The timing window defines a period of time during which only a single synchronized event is to be processed by the computing devices 14. In some implementations, the timing window may be based on a greatest network delay value associated with the computing devices 14-1, 14-N. In some embodiments, the timing window may be the greatest network delay value plus some predetermined buffer value as a safety margin”, [0039];
“At a time T1 during the timing window 42-1, the central computing device 12 communicates event information regarding a synchronized event to the computing devices 14-1 and 14-N, which are time-synchronized with the central computing device 12. The event information contains an event depiction timestamp that identifies a time T2. At the time T2, the computing devices 14-1 and 14-N depict the event on the display devices 26-1, 26-N. The computing device 14-1 sends a message identifying a user input and a timestamp of the user input to the central computing device 12, which is received by the central computing device 12 at a time T3. The computing device 14-N sends a message identifying a user input and a timestamp of the user input to the central computing device 12, which is received by the central computing device 12 at a time T4”, [0050]);
and sending the current frame of the user input information irrespective of whether the user input information is received from each of the plurality of users within the current time interval (“The central computing device 12 processes the messages, based in part on the timestamps contained in the messages, and generates next event information that identifies a next synchronized event, and an event depiction timestamp that identifies a time T6 of the timing window 42-2. At a time T5, the central computing device 12 communicates the next event information regarding the next synchronized event to the computing devices 14-1, 14-N. At the time T6, the computing devices 14-1 and 14-N depict the event on the display devices 26-1, 26-N”, [0050]; see also [0056] – [0058]).
Regarding claim 2, Cook discloses the user input information from the at least one of the plurality of users only includes the user input information from a subset of the plurality of users (in the case not all the players respond during a particular input window).
Regarding claim 3 Cook discloses the user input information from the at least one of the plurality of users includes user input information from one of the plurality of users that is associated with the current frame and received after the current time interval of the current frame, and the user input information from the one of the plurality of users is associated with a subsequent frame of the plurality of frames of the lockstep engine that corresponds to a subsequent time interval in which the user input information from the one of the plurality of users is received (in the case a network delay prevents delivery of an input until after the associated input window).
Claims 25-27 are directed to devices that implement the methods of claims 1-3 respectively and are rejected for the same reasons as claims 1-3 respectively.
Claims 49-51 are directed to articles of manufacture that contain code that implement the methods of claims 1-3 respectively and are rejected for the same reasons as claims 1-3 respectively.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 4-9, 28-33 and 52-57 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cook (pub. no. 20220305380) in view of Todorovic (pub. no. 20220212101).
Regarding claims 4-9, it is noted that Cook does not disclose snapshotting game state, saving user inputs subsequent to a snapshot and introducing a new user by updating a snapshot using the inputs. Todorovic however, teaches snapshotting game state, saving user inputs subsequent to a snapshot and introducing a new user by updating a snapshot using the inputs (“An additional aspect, as represented by block 406, is that the gameplay of the game world 202 is dependent on player input. As such, nothing occurs in a region 210 of the game world when there are no players in that region to influence it. In some implementations, this results in the gameplay for the region 210 reverting to a default state when all players leave the region. Alternatively, the state for region 210 is stored to a cloud drive or other network-accessible storage when the last player leaves the region 210, and then that state is reloaded when a player comes to the area. This allows a world that maintains state, but without the coordinating game servers. Alternatively, the gameplay can be configured so that the state when players arrive in a region 210 can be simulated immediately relative to the perception of the players joining that region 210. This does not limit non-player characters (NPCs) and other game agents from being present in the game world 202 and performing various activities, but any such activities are limited to those that do not materially change the gameplay unless players are in the corresponding region. In particular, the publish and subscribe functions facilitate the implementation of the ad-hoc peer-to-peer networks between player simulation instances 208 for a given region 210 without requiring coordinating servers to distribute messages.
Yet another aspect, as represented by block 408, is enforcing deterministic game world simulation with simulation rollback. Some implementations of the cloud gaming system 100 are intended to permit game developers to design video games in a manner similar to designing a single-player experience while allowing multiplayer interactions. One feature that facilitates this design approach is to mandate deterministic game world simulation with rollback, in addition to having player input information being the primary network-transmitted data between game platform instances 206. Generally, as used herein, a game world simulation is “deterministic” when, given the same state and player inputs, two different game platform instances 206 executing the same game simulation, even if started at different times, will produce the same state within some specified threshold duration (typically in the hundreds of milliseconds range). To facilitate this deterministic operation, particularly while supporting simulation rollback, a number of factors are considered and solutions implemented, as described below.
As represented by block 410, one such factor is the starting state for the simulation. As the starting state for a simulation generally controls many subsequent state aspects, the starting state for a simulation is determined so that the starting point for each simulation instance will be the same even though the simulation instances typically will be started at different times. The determination of this starting state includes, for example, level geometry, NPC characteristics and state, object positioning, resources, and the like. That is, most or all aspects of the game world 202 are readily calculable”, [0042] - [0044];
“Another such factor is player input management, as represented by block 414. As noted above, an aspect of at least one embodiment is that the only things that cause changes to the game simulation is player input; that is, without player input, the game simulation proceeds deterministically without need for network activity on the messaging bus 108. Accordingly, only with players in a given region 210 is the simulation for that region 210 created and advanced.
Because player input is what drives the simulations, the game platform instances 206 are configured so that each simulation processes all player input in the same way. This is accomplished, for example, by ensuring each simulation processes player input using the same time values, in the same order that the player input was performed. Thus, when a player performs an input, the game platform instance 206 connected to the client device 106 of the player to registers the player input, time stamps it, and sends that information across the messaging bus 108 to all of the other simulations in the same region 210 (and any designated “adjacent” regions 210). In some embodiments, even the simulation local to the player uses the networked version of the player input for processing the player input; this is because if there's anything different about how the player input is processed (for instance, a more accurate time value locally versus on the network) then the simulations are likely to drift. The local visualization of player input can use more accurate local data for the local player's benefit, but this is because the visualization is driven by the simulation and typically provides no feedback to the simulation.
When a simulation receives player input (whether from the local or a remote player; in at least one implementation the simulation does not distinguish between local and remote players), the simulation rolls back the simulation to the moment when the player input occurred if the timestamp was before the last time state was calculated. The simulation then applies all player input since the time of the rolled back state in order of their timestamps. If the received player input has a time stamp that occurs after the last time state was calculated, the player input is added to a list or other queue of player inputs to be processed in the order of their timestamps the next time state is calculated. In the event that two timestamps represent the same time, a deterministic tie breaker is applied, such as through the alphabetical ordering of player names or using a deterministic random number generator as described above. If a player input is time stamped into the future, the player input is added to a corresponding future input queue and executed later. In this way, relatively minor time variations between instances can be managed. Further, in some situations a player could send multiple inputs at the same time, and so in some embodiments the timestamping process ensures that the timestamp of each input is incremented by some small value to preserve ordering and further ensures that a client device 106 avoids sending more than one player input with the same timestamp. Further, to reduce the apparent latency of player input, in some implementations the timestamp of player input is set to have occurred when the local client device 106 registered the player input as opposed to when the game platform instance 206 received notification of the player input. This treats local player input more like a networked player (which, technically, the local player is) and can provide a better experience for the player.
As represented by block 416, a facilitating aspect for peer-to-peer multiplayer operation is the implementation of rollback and resimulation (also known as “replay”) by each game simulation instance. Typically, the simulation is constantly rolling back and simulating forward as potentially large amounts of player input are sent across the messaging bus 108. In this sense, rollback can be approximated as an “undo” operation, while processing player input can be seen as operations on state. As such, any of a variety of techniques can be employed; one approach is to provide each operation with a corresponding undo operation. With this, the simulation can rollback to precisely the point where a new player input occurred, and no earlier, then process forward with a minimum number of operations. It will be appreciated that some counterpart undo operations may contain a significant amount of the simulation's state. As another approach, since the simulation has access to the starting state, the simulation can roll back to the beginning and then resimulate from there using all previous player input to re-simulate forward. Another technique utilizes the taking of periodic snapshots of the complete state of the simulation, and keeping all player input between these snapshots. To avoid memory fragmentation, a ring buffer can be employed for the snapshots, such that the oldest snapshots are eventually discarded and overwritten. When a new player input is received, a rollback is implemented in the simulation to the most recent snapshot created before the player input, and then the simulation processes all data forward. Because the simulation is not a text editor, older snapshots can be discarded; in fact, the system can elect to keep only one snapshot that is X milliseconds in the past, where X is some value beyond which the simulations would be declared out of sync and unrepairable. In this manner, only two copies of the state, the snapshot and the “current” estimate, need be maintained, and a rollback in this context thus means that the snapshot state is rolled back to the current state and simulated forward. Periodically, the snapshot state is advanced forward to X milliseconds in the past, and remote player input is discarded before that point”, [0046] – [0049];
“Yet another factor in deterministic simulation with effective rollback, is the management of player state as represented by block 420. This includes maintaining persistent player state, as well as determining the initial player state. For maintaining a persistent player state, in some embodiments the conventional single player save state routines employed by a cloud gaming system can be used to maintain player state across separate launches of the game. This can include, for example, storing the current player state to a cloud drive or other cloud-attached storage. As for initial player state, when a player enters a region 210 where there are already players interacting with the environment (and may have been for an arbitrarily long period of time), determining the initial player state can be problematic. In one approach, the initial player state is determined by obtaining all player input since the beginning, applying those inputs to the simulation and run it forward. However, the history of everything that's occurred can dwarf the simulation state when the game has been active for a long period of time, or when there is a relatively high number of players active in the game. Accordingly, in other implementations, when a player enters a region 210, the player simulation instance can obtain the current state from one of the existing player's simulation instance, while also receiving updates from all players in the same region 210. The current state from the existing player typically is sufficiently far in the past that it contains the effects of all the player input up to that point, but soon enough that the player's simulation will be able to obtain all of the player input updates from other simulations. An example of this approach includes: (1) subscribe to player inputs for the region 210 via the messaging bus 108; (2) request for one of the other simulation instances to send its state. (3) another simulation sends its state to the requesting simulation—this state can include the recent simulation data stored for rollback (i.e., highly confident that it has all of the player inputs up until that point) and all of the player inputs from other players received since that data was collected; (4) the new player simulation instance receives this data, uses the simulation data as its source of truth, merges the player input from the other instance with what it's received, culling duplicates; and proceed with the gameplay as normal”, [0054]).
Exemplary rationales that may support a conclusion of obviousness include use of a known technique to improve similar devices (methods, or products) in the same way. Here both Cook and Todorovic are directed to multiplayer games. To modify the Cook invention to use the Todorovic updating method would be to use a known technique to improve a similar system in the same way. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to incorporate the updating system as taught by Todorovic into the Cook invention. To do so would enable quickly bringing a new user up to date thereby increasing the perceived value of the game.
Claims 28-33 are directed to devices that implement the methods of claims 4-9 respectively and are rejected for the same reasons as claims 4-9 respectively.
Claims 52-57 are directed to articles of manufacture that contain code that implement the methods of claims 4-9 respectively and are rejected for the same reasons as claims 4-9 respectively.
Claim(s) 10, 34 and 58 is/are rejected under 35 U.S.C. 103 as being unpatentable over Cook (pub. no. 20220305380) in view of Kong et al. (pub. no. 20200155946).
Regarding claim 10, it is noted that Cook does not explicitly disclose a video game that is a real time strategy game. Kong however, teaches a multiplayer game that is a real time strategy game (“RTS is an abbreviation of Real-Time Strategy Game and is one type of strategy game. An RTS is played in real time rather than a common turn-based strategy game. In addition, a player often plays a general in an RTS to command armed forces”, [0026];
“When the first client is disconnected and then connected again, the first client obtains a current progress time from the second client, and then calculates a reference time mark (that is, a target reference time mark) according to the progress time. The time mark is before the current progress time. A difference between the current time mark and the closet target reference time mark is determined, and attribute information of the current time mark is determined according to the difference and attribute information of the target reference time mark. The first client performs rapid computation starting from this reference mark. A computing speed is 50 to 100 times a normal game speed (depending on the performance of the client), and catches up with the current progress time of the second client. This process is included in disconnection and reconnection logic. When a disconnection and reconnection process is completed, the first client and the second client are at the same time mark, start to display the game picture, and enter a normal game process”, [0097]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Cook and Kong are directed to multiplayer games. To modify the Cook invention to implement an RTS according to Kong would be to combine prior art methods according to known methods to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to implement an RTS in the Cook invention. To do so would cater to player preferences by providing a game in a popular genre.
Claim 34 is directed to a device that implements the method of claim 10 and is rejected for the same reasons as claim 10.
Claim 58 is directed to an articles of manufacture that contain code that implement the method of claim 10 and is rejected for the same reasons as claim 10.
Claim(s) 11-18, 35-42 and 59-66 is/are rejected under 35 U.S.C. 103 as being unpatentable over Todorovic (pub. no. 20220212101) in view of Cook (pub. no. 20220305380).
Regarding claim 11, Todorovic discloses a method of a video game, the method comprising: transmitting, to a server, a request to join a match after the match has started; receiving, in response to the request to join, game state information of the match for a plurality of time intervals of the match of the video game, the game state information comprising information for each of a plurality of time intervals of the lockstep game engine; and rendering a plurality of video frames of the match in the video game based on the game state information for each of the plurality of time intervals (“Accordingly, in other implementations, when a player enters a region 210, the player simulation instance can obtain the current state from one of the existing player's simulation instance, while also receiving updates from all players in the same region 210. The current state from the existing player typically is sufficiently far in the past that it contains the effects of all the player input up to that point, but soon enough that the player's simulation will be able to obtain all of the player input updates from other simulations. An example of this approach includes: (1) subscribe to player inputs for the region 210 via the messaging bus 108; (2) request for one of the other simulation instances to send its state. (3) another simulation sends its state to the requesting simulation—this state can include the recent simulation data stored for rollback (i.e., highly confident that it has all of the player inputs up until that point) and all of the player inputs from other players received since that data was collected; (4) the new player simulation instance receives this data, uses the simulation data as its source of truth, merges the player input from the other instance with what it's received, culling duplicates; and proceed with the gameplay as normal”, [0054]).
Regarding claim 11, it is noted that Todorovic does not explicitly disclose a lockstep engine. Cook however, teaches a lockstep engine (“The embodiments disclosed herein implement event synchronization in an online game. A central computing device, such as a game server, time synchronizes with each of a plurality of other computing devices, such as personal computers, game consoles, and/or mobile devices, executing an online game. The central computing device determines an event to be depicted on each of the computing devices at a future time and sends, to the computing devices, event information that identifies the event and an event depiction timestamp that identifies a future time at which the event is to be depicted by the computing devices.
The computing devices receive the event information, and, at the designated future time, concurrently depict the event to each of the players. The computing devices then receive user input from the players in response to the depiction of the event. Each computing device generates a timestamp, which identifies the time of the user input, and action information, which identifies the user input, and sends the timestamp and the action information to the central computing device.
The central computing device collects the information sent by the computing devices, and determines, based on the timestamps and the user inputs, an appropriate next game event to be depicted. The central computing device sends to the computing devices the next game event to be depicted by the computing devices and an event timestamp that identifies the future time at which the next game event is to be depicted to the players. In this manner, the central computing device and the computing devices can ensure perfectly synchronized events such that the central computing device can make precise determinations as to which players acted at which times, irrespective of significant network delays among the different computing devices and the central computing device”, [0021] - [0023]).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Todorovic and Cook are directed to multiplayer games. To modify the Todorovic invention to use the Cook lockstep engine would be to combine prior art methods according to known methods to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to incorporate lockstep engine as taught by Cook into the Todorovic invention. To do so would enable accurate synchronization of player inputs thereby increasing the perceived fairness of the system.
Regarding claim 12, Todorovic discloses the match of the video game is a live match that is in progress ([0054]).
Regarding claim 13, Todorovic discloses the plurality of time intervals includes each time interval of the match of the video game that elapsed before the request to join is received by the server ([0054]).
Regarding claim 14, Todorovic discloses the game state information indicates user inputs for each of at least a subset of the plurality of time intervals of the match, and the rendering of the plurality of video frames comprises: processing the user inputs from the match via the lockstep game engine, and rendering the plurality of video frames corresponding to the subset of the plurality of time intervals of the match in the video game based on the processed user inputs ([0054]).
Regarding claim 15, Todorovic discloses the game state information comprises compressed user input information that includes user inputs performed during the match ([0054]).
Regarding claim 16, Todorovic discloses the game state information indicates a game state including status information of a plurality of game elements for each of at least a first subset of the plurality of time intervals of the match, and the rendering of the plurality of video frames comprises rendering the plurality of video frames corresponding to the first subset of the plurality of time intervals of the match in the video game based on the game state of each of the first subset of the plurality of time intervals of the match ([0054]).
Regarding claim 17, Todorovic discloses the game state information comprises status information of a plurality of game elements that is processed by a view model to render a current video frame of the plurality of video frames ([0054]).
Regarding claim 18, Todorovic discloses the game state information of the match is stored in a server ([0054]).
Claims 35-42 are directed to devices that implement the methods of claims 11-18 respectively and are rejected for the same reasons as claims 11-18 respectively.
Claims 59-66 are directed to articles of manufacture that contain code that implement the methods of claims 11-18 respectively and are rejected for the same reasons as claims 11-18 respectively.
Claim(s) 19, 43 and 67 is/are rejected under 35 U.S.C. 103 as being unpatentable over Todorovic (pub. no. 20220212101) in view of Cook (pub. no. 20220305380) as applied respectively to claims 11, 35 and 59 above and further in view of Trombetta et al. (pub. no. 20190262723).
Regarding claim 19 it is noted that Todorovic and Cook do not disclose joining a spectator to the game. Trombetta however, teaches disclose joining a spectator to the game (“ At step 315, a game server identifies that a second client computing device B is currently assigned a spectator role within the video game.
At step 320, the game server delivers the video game data to the second client computing device B. Because the second client computing device B is currently assigned a spectator role within the video game, the game server delivers the video game data stream to the second client computing device B using one or more inferior network transfer properties. That is, the game server delivers the video game data stream to the second client computing device B at a low bitrate, a low priority, a low quality-of-service (QoS), a high latency, or a combination thereof. Unlike players, spectators provide little or no influence on an outcome of the game match, and therefore the video game data received by the spectator can be more choppy, less smooth, or less detailed if necessary to improve the experience for players and to therefore provide optimal gameplay.
At step 330, the game server detects a trigger event during the game match of the game”, [0040] – [0042];
“The trigger event of step 330 may alternately/additionally be based on inputs from spectators. For example, if enough spectators vote that a particular player is cheating, playing unfairly, or doing a bad job, the spectators can vote to have that player replaced, where a number of such votes from spectators surpassing a predetermined threshold number or percentage (of the total number of spectators) can be detected by the game server as a trigger event.
At step 335, the game server switches the player/spectator roles of the first client computing device A and the second client computing device B in response to detecting the trigger event in step 330. That is, the role of the first client computing device A is switched from a player role to a spectator role, and the role of the second client computing device B is switched from a spectator role to a player role”, [0044] & [0045];
“At step 355, the game server delivers the video game data to the second client computing device B. Because the second client computing device B is currently assigned a player role within the video game, the game server delivers the video game data stream to the second client computing device B using one or more superior network transfer properties. That is, the game server delivers the video game data stream to the second client computing device B at a high bitrate, a high priority, a high Quality of Service (QoS), a low latency, or a combination thereof. The superior network transfer properties used by the game server to deliver the video game data to the second client computing device B in step 355 are superior to the inferior network transfer properties used by the game server to deliver the video game data to the first client computing device A of step 320”, [0049]).
Exemplary rationales that may support a conclusion of obviousness include use of a known technique to improve similar devices (methods, or products) in the same way. Here both Todorovic and Trombetta are directed to multiplayer games. To modify the Todorovic invention to use the Trombetta spectator onboard would be to use of a known technique to improve similar devices (methods, or products) in the same way. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to the spectator onboarding as taught by Trombetta into the Todorovic invention. To do so would increase the perceived entertainment value of the system.
Claim 43 is directed to a device that implements the method of claim 19 and is rejected for the same reasons as claim 19.
Claim 67 is directed to an articles of manufacture that contain code that implement the method of claim 19 and is rejected for the same reasons as claim 19.
Claim(s) 20, 44 and 68 is/are rejected under 35 U.S.C. 103 as being unpatentable over Todorovic (pub. no. 20220212101) in view of Cook (pub. no. 20220305380) as applied respectively to claims 11, 35 and 59 above and further in view of Lloyd et al. (pat. no. 6,884,172).
Regarding claim 20, it is noted that Todorovic and Cook do not disclose rejoining a disconnected user to the game. Lloyd however, teaches rejoining a disconnected user to the game (“Embodiment of the invention, described below, permit a user on a connected device to interact with a persistent game world. The user may be playing a game any type of connected device, either wired or wireless, such as wireless phones, personal digital assistants (PDAs), personal computers, etc. The game world allows for multi-user capability, including users on a wide variety of platforms, so that users can play each other, even if they are on different types of devices. The user also experiences a persistent game world, so that if the user is disconnected, either voluntarily or involuntarily, the user can return to a game world that is consistent with what they would expect, such as the exact same game world or a game world that has advanced in a reasonable fashion”, col. 2, lines 51-64).
Exemplary rationales that may support a conclusion of obviousness include combining prior art elements according to known methods to yield predictable results. Here both Todorovic and Lloyd are directed to multiplayer games. To modify the Todorovic invention to use the Lloyd user reconnect would be to combine prior art methods according to known methods to yield a predictable result. Therefore, it would have been obvious to a person having ordinary skill in the art as of the effective filing date of the claimed invention to incorporate user reconnect as taught by Lloyd into the Todorovic invention. To do so would increase the uptime of the game thereby increasing the perceived reliability.
Claim 44 is directed to a device that implements the method of claim 20 and is rejected for the same reasons as claim 20.
Claim 68 is directed to an articles of manufacture that contain code that implement the method of claim 20 and is rejected for the same reasons as claim 20.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LAWRENCE STEFAN GALKA whose telephone number is (571)270-1386. The examiner can normally be reached M-F 6-9 & 12-5.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dmitry Suhol can be reached at 571-272-4430. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/LAWRENCE S GALKA/Primary Examiner, Art Unit 3715
Prosecution Insights