Systems and methods for capturing and using video game input states

Description

1 / 53 SYSTEMS AND METHODS FOR CAPTURING AND USING VIDEO GAME INPUT STATES CROSS-REFERENCE PARAGRAPH

[0001] This application claims the benefit of U.S. Patent Application No. 18 / 193,626, filed March 30, 2023, which is incorporated herein by reference in its entirety. BACKGROUND

[0002] Video games remain a popular and widespread form of entertainment. Video game platforms constantly strive to create video games that are faster, more exciting, and more engaging. Typically, a video game is played on a video game console or computer that displays game graphics via a display device, such as a TV or monitor, while the player interacts with the displayed game via a video game input device, such as a video game controller or a touchscreen display device. These input devices usually include or display a collection of buttons, joysticks, trackpads, paddles, and so on. When a video game player interacts with an input device while playing a video game, the input device can transmit signals to the game system that cause the video game to generate different visual outputs based on how the player interacted with the input device.

[0003] When video games are played on a local console (that is, a video game console connected to a controller or on the same subnet as a wireless controller), the player may experience a high level of responsiveness that can help the video game feel more realistic. However, problems can arise when video games are played on a larger network. For example, a video game player might play a video game over the internet in such a way that the player interacts with an input device and the input device... Petition 870250088208, dated 09 / 29 / 2025, page 14 / 81 2 / 53 transmit input signals over the Internet to a remote gaming platform. The gaming platform can then cause the player's local video game display to update based on the received input signals.

[0004] This transmission cycle, however, can present increased latency, which can negatively impact the performance of the video game. For example, the round-trip time of incoming signals over the Internet can be long enough that the video game player experiences a delay between the moment a button is pressed on the controller and the moment a corresponding video game update is displayed on the player's display device. Although this delay may be very small, such transmission inefficiencies can cause gameplay to become slow to the point where the video game freezes, crashes, or becomes difficult to play.

[0005] Furthermore, input signals can be dropped or interrupted at any time during transmission over the Internet. To illustrate, if one input signal from a series of input signals (for example, a series of button presses on a video game controller) is dropped, the video game platform may incorrectly update the video game display due to the lost input signal. This can result in confusion for the player, as well as computational waste due to replaying the game, restarting levels, restarting the video game, and so on. SUMMARY

[0006] As will be described in greater detail below, the present disclosure describes implementations that blindly transmit and retransmit complete input states of a video game controller over the Internet, so that the corresponding video game can maintain an input state. Petition 870250088208, dated 09 / 29 / 2025, page 15 / 81 3 / 53 consistent. For example, implementations may include receiving, from a video game input device and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first input state message comprising a first input state from the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state, receive,From the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state, and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[0007] In some examples, user interactions on the video game input device in connection with the video game may include at least one single-finger touch gesture user interaction or multi-finger touch gesture user interaction. Additionally, implementations may further include receiving control message transmissions from the video game input device and utilizing those messages. Petition 870250088208, dated 09 / 29 / 2025, page 16 / 81 4 / 53 control for at least one of a startup procedure with the video game input device, an authorization procedure with the video game input device, a device configuration procedure with the video game input device, or a disconnection procedure with the video game input device.

[0008] In some examples, implementations may also include, in response to receiving a transmission of a control message, generating a confirmation message associated with the control message and transmitting the confirmation message to the video game input device. For example, the first input status message, the second input status message, and additional control messages may include a device ID associated with the video game input device.

[0009] In some examples, the predetermined number of retransmissions may be defined by a retransmission factor included in at least one of the control messages. Additionally, the second input state message may further include a time delta indicating a number of milliseconds separating the first input state of the video game input device from a timestamp associated with the second input state message. Furthermore, implementations may additionally include, in response to receiving no input state message transmission from the video game input device for more than a threshold amount of time, determining that the video game input device is in an idle state.

[0010] Some examples described here include a system with at least one physical processor and physical memory, including computer-executable instructions that, when Petition 870250088208, dated 09 / 29 / 2025, p. 17 / 81 5 / 53 executed by at least one physical processor, cause that at least one physical processor to perform several acts. In at least one example, computer executable instructions, when executed by at least one physical processor, cause that at least one physical processor to perform acts, including receiving, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first input state message comprising a first input state of the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state, receive,From the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state, and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[0011] In some examples, the method described above is encoded as computer-readable instructions in a computer-readable medium. In one example, the instructions Petition 870250088208, dated 09 / 29 / 2025, page 18 / 816 / 53 computer-readable, when executed by at least one processor of a computing device, cause the computing device to receive, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first input state message comprising a first input state of the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state, receive,From the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state, and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[0012] In one or more examples, features of any of the modalities described herein are used in combination with one another in accordance with the general principles described herein. These and other modalities, features, and advantages will be more fully understood after reading the following detailed description. Petition 870250088208, dated 09 / 29 / 2025, page 19 / 81 7 / 53 together with the attached drawings and claims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The attached drawings illustrate a number of exemplary embodiments and are part of the descriptive report. Together with the description that follows, these drawings demonstrate and explain several principles of the present disclosure.

[0014] FIG. 1 is a block diagram of an exemplary environment for implementing an input state system according to one or more implementations.

[0015] FIG. 2 is a flow diagram of an exemplary computer-implemented method for capturing and using input state information in connection with a video game according to one or more implementations.

[0016] FIGS. 3A-3C illustrate earlier protocols for transmitting event data from a sender to a receiver. [ 0017 ] Figures 3D-3F illustrate an input-state protocol that uses blind preemptive retransmission to transmit input-state information with lower latency and higher accuracy according to one or more implementations.

[0018] FIG. 4 illustrates a block diagram of the input state system according to one or more implementations.

[0019] Throughout the drawings, identical descriptions and reference characters indicate similar, but not necessarily identical, elements. Although the exemplary embodiments described herein are susceptible to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail in this document. However, the exemplary embodiments described herein are not intended to be Petition 870250088208, dated 09 / 29 / 2025, p. 20 / 81 8 / 53 limited to the particular forms disclosed. Instead, this disclosure covers all modifications, equivalents and alternatives within the scope of the appended claims. DETAILED DESCRIPTION OF EXEMPLARY MODALITIES

[0020] As mentioned above, video games played over the Internet can exhibit latency and input signal dropout issues. These inefficiencies and inaccuracies can, in turn, lead to incorrect gameplay, player frustration, and corresponding computational waste. For example, a player might pause, restart, or reset a video game that is lagging due to network latency. Resource waste can result from any of these actions, as network resources are used to transmit incorrect data, incorrect game graphics are rendered, systems are restarted, and so on.

[0021] In light of these problems, the present disclosure describes a system that captures and utilizes video game input states with greater efficiency and improved accuracy. For example, the system described here can cause a video game controller to transmit atomic input state information over the Internet to a video game platform instead of transmitting individual events. By transmitting complete input states whenever a state change is detected (e.g., a new button is pressed), the system described here can maintain a consistent view of the video game controller's state at any given time. The system described here can maintain this consistent view even when signals and / or packets are dropped, coalesced, or split during transmission over the Internet.

[0022] In more detail, the system described here can Petition 870250088208, dated 09 / 29 / 2025, page 21 / 81 9 / 53 involve an input state protocol that utilizes blind preemptive retransmission. In one or more implementations, the described system can have the video game controller transmit a current input state of the video game controller (e.g., reflecting which video game controller elements there was interaction with), potentially in addition to other input states that occurred previously. The system described here can additionally have the video game controller retransmit input states a predetermined number of times without waiting for an acknowledgment message from the video game platform. By blindly retransmitting each input state (e.g., without receiving an acknowledgment message), the systems described here increase the speed at which input states are transmitted and received.Furthermore, the system described here increases game accuracy by creating a high level of redundancy in the transmission of input state, so that the game can remain consistent even when a transmission is dropped.

[0023] Features of any of the implementations described herein may be used in combination with one another, in accordance with the general principles described herein. These and other implementations, features and advantages will be more fully understood after reading the following detailed description together with the attached drawings and claims.

[0024] What follows will provide, with reference to FIGS. 1-4, detailed descriptions of an input state system that causes a video game controller to transmit video game input states according to an input state protocol to accurately and efficiently capture current and previous input states of the video game controller. For example, an exemplary network environment is Petition 870250088208, dated 09 / 29 / 2025, page 22 / 81 Figure 1 illustrates the input state system operating in connection with a display device and a video game input device (e.g., a video game controller). Figure 2 illustrates the steps performed by the input state system when receiving transmissions and retransmissions of input states without providing any acknowledgment message to a video game input device being used as a video game controller. Figures 3A-3F describe operations and advantages of the input state protocol, including blind preemptive retransmission in existing transmission protocols. Finally, Figure 4 provides further details regarding the characteristics and functionalities of the input state system.

[0025] As mentioned, FIG. 1 illustrates an exemplary network environment 100 that implements aspects of this disclosure. For example, the network environment 100 may include server(s) 112, a display device 118, a video game input device 120, and a network 122. As shown further on, the server(s) 112 may include memory 106, additional items 108, and a physical processor 110.

[0026] In one or more implementations, as shown in FIG. 1, the display device 118 may be a television and the video game input device 120 may be any type of video game controller. For example, the video game input device 120 may be a display screen device, such as a smartphone. In some examples, the display screen device used as a video game controller may include a touch-screen display showing video game control elements (e.g., buttons, joysticks, trackpads) that can be used to control the video game 103 displayed on the display device 118. In further implementations, Petition 870250088208, dated 09 / 29 / 2025, page 23 / 81 11 / 53 The video game input device 120 may be another type of input device. For example, the video game input device 120 may be a TV remote control, a smart wearable device (e.g., a smartwatch), a virtual reality device, or a gamepad connected to the display device 118. In at least one implementation, the video game input device 120 may include a keyboard and / or mouse connected directly to a computing device, such as a desktop computer, laptop, or tablet.

[0027] As shown in FIG. 1, an input state system 102 can be implemented as part of a digital content system 104 within memory 106 in server(s) 112. In one or more implementations, the digital content system 104 may include a subscription streaming service to provide subscribers with digital media content. Furthermore, the input state system 102 (alone or in combination with the digital content system 104 and / or the video game 103) can access the video game 103, run the video game 103, transmit the output of the video game 103 to one or both of the display device 118 and the video game input device 120 (e.g., to make the display device 118 render game graphics, to make the video game input device 120 display video game control elements such as buttons, joysticks, etc.).), receive input state messages and other transmissions from a video game controller (for example, as the video game input device 120), etc. In one or more implementations, the video game controller 103 can analyze input states, change game states, and update game graphics based on input states, while the input state system 102 works in conjunction with the video game controller 103 to receive transmissions a. Petition 870250088208, dated 09 / 29 / 2025, page 24 / 81 12 / 53 from the 120 video game input device and transmit information to the 120 video game input device.

[0028] As shown in FIG. 1, the video game input device 120 may include the ability to communicate information to and from the input state system 102 via the network 122. In at least one implementation, the input state system 102 – in conjunction with the video game 103 – may access and utilize data received from the video game input device 120.

[0029] As mentioned above, the display device 118 and / or the video game input device 120 can be communicatively coupled with the server(s) 112 via the network 122. In one or more implementations, the network 122 can represent any type or form of communication network, such as the Internet, and can include one or more physical connections, such as a LAN, and / or wireless connections, such as a WAN. In some implementations, the network 122 can represent a telecommunications carrier network. In at least one implementation, the network 122 can represent combinations of networks such that the display device 118 can communicate with the digital content system 104 via a wireless network, while the video game input device 120 can communicate with the input state system 102 via a cellular network.

[0030] Although FIG. 1 illustrates components of the exemplary network environment 100 in one arrangement, other arrangements are possible. For example, in one implementation, the input state system 102 can operate as a native application that can be installed on the display device 118 and / or the video game input device 120. In another implementation, the input state system 102 can operate Petition 870250088208, dated 09 / 29 / 2025, page 25 / 81 13 / 53 across multiple servers.

[0031] Furthermore, in some implementations, the exemplary network environment 100 may include multiple video game input devices 120 – such as when a multiplayer game is being played on the display device 118. Similarly, the exemplary network environment 100 may also include multiple display devices 118, such as when multiple players are playing a video game on separate displays. For example, in this implementation, the input system 102 and / or the digital content system 104 may support the same video game being played by multiple players (e.g., on multiple video game input devices and multiple display devices) in multiple locations and on different user accounts within the digital content system 104.

[0032] In one or more implementations, and as will be explained in more detail below, the methods and steps performed by the input state system 102 refer to multiple terms. For example, a “digital video game” or “video game” may refer to a digital program that causes game graphics to be rendered on a display device, such as the display device 118, as user inputs received through a video game input device manipulate or interact with the rendered game graphics. A video game may include points, places, junctions, levels, characters, and other displayed objects. [ 00 33 ] As used herein, a “video game input device” may include any device capable of receiving user input and transmitting signals associated with that input to a game platform. For example, a video game input device may include a video game controller specific to the game platform. Petition 870250088208, dated 09 / 29 / 2025, page 26 / 81 14 / 53 and can include any combination of physical buttons, joysticks, paddles, trackpads, etc. Additionally, a video game input device can include a client device, such as a smartphone, that has been converted into a video game controller. For example, a smartphone that has been converted into a video game controller might display graphical representations of buttons, joysticks, paddles, trackpads, etc. on a touchscreen display. Furthermore, a video game input device can include a mouse, keyboard, trackpad, etc., which is already connected directly to a computing device, such as a desktop computer, a laptop, a tablet, etc. In some implementations, the input state system 102 can detect and utilize input state information from multiple video game input devices (e.g., when a video game is played with a computer keyboard and mouse).

[0034] As used herein, “video game control elements” can refer to physical or graphically displayed buttons, joysticks, trackpads, rollerballs, paddles, and so forth. For example, a video game control element might be an interactive graphic that mimics a button. In some implementations, a graphically displayed video game control element might appear to be pressed or otherwise manipulated when selected. In some implementations, video game control elements might refer to other types of interactive graphics displayed. For example, a video game control element might be specific and customized to a particular video game. To illustrate, a video game control element might include a representation of an enemy character that, in response to a selection detected on the display screen device, is destroyed within the Petition 870250088208, dated 09 / 29 / 2025, page 27 / 81 15 / 53 video game. In another example, video game control elements might include two displayed objects (e.g., a stone and a piece of wood) that can be dragged together on the display screen touchscreen of the display device to be combined into a new video game control element (e.g., a tool).

[0035] As used herein, an “input state” can refer to data reflecting any video game controller element on a video game input device that is not in its default state at a given time. For example, an input state of a video game input device with video game controller elements might reflect which video game controller elements are interacting with or being selected at a given time. In one or more implementations, the input state system might capture an input state of a video game controller in response to the detection of an “event” or “input event.” For example, an event might include a player interaction with one or more video game controller elements on the video game controller.

[0036] As used herein, a “transmission” can refer to the communication of information over a network. Additionally, a “retransmission” can refer to a further communication of previously sent information that is sent to the same endpoint as the previous transmission. In one or more implementations, the input state system can transmit various types of messages. For example, the input state system can transmit input state messages that may include input state information. The input state system can also transmit control messages that may include control information related to the video game input device, the current session, etc. Furthermore, the Petition 870250088208, dated 09 / 29 / 2025, page 28 / 81 16 / 53 input state system 102 can transmit an acknowledgment message that can confirm receipt of a previous transmission. In one or more implementations, the input state system can format and transmit messages according to an input state protocol that includes preemptive blind retransmission discussed in more detail below with respect to FIG. 4.

[0037] As mentioned above, FIG. 2 is a flow diagram of an exemplary computer-implemented method 200 for capturing atomic input states from the videogame input device 120 in connection with the videogame 103. The steps shown in FIG. 2 can be performed by any suitable computer executable code and / or computing system, including the system(s) illustrated in FIG. 4. In one example, each of the steps shown in FIG. 2 may represent an algorithm whose structure includes and / or is represented by several sub-steps, examples of which will be provided in more detail below.

[0038] As illustrated in FIG. 2, in step 202 the input state system 102 can receive, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device, 1) a transmission of a first input state message comprising a first input state of the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state.

[0039] For example, the input state system 102 Petition 870250088208, dated 09 / 29 / 2025, page 29 / 81 17 / 53 can cause video game input device 120 to generate and transmit the first input state message in response to the detection of user inputs via a touchscreen display on video game input device 120. Input state system 102 can cause video game input device 120 to generate the first input state message, including the first input state indicating one or more video game control elements with which the player interacted. Input state system 102 additionally causes video game input device 120 to blindly retransmit the first input state a predetermined number of times (e.g., five times) without waiting for confirmation messages associated with the first input state.In one or more implementations, the input state system 102 can cause the video game input device 120 to retransmit the first input state by grouping the first input state with additional input states in future input state messages.

[0040] As illustrated in FIG. 2, in step 204, the input state system 1 02 can receive, from the video game input device and in response to additional user interactions on the video game input device connected to the video game, 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state. [ 004 1 ] For example, as mentioned above, the input state system 102 can make the input device Petition 870250088208, dated 09 / 29 / 2025, page 30 / 81 18 / 53 of video game 120 generate the second input state message, including the second most recently captured input state (e.g., a second video game controller element or group of video game controller elements with which the player interacted), as well as the first input state that was previously transmitted. Thus, the second input state message may include a first transmission of the second input state and a retransmission (e.g., a second transmission) of the first input state. Just as with the first input state, the input state system 102 may cause the video game input device 120 to retransmit the second input state a predetermined number of times, grouping the second input state into future input state messages along with the first input state.

[0042] Furthermore, as illustrated in FIG. 2, in step 206, the input state system 102 can update the video game gameplay based on the input state information received in the first input state message and the second input state message. For example, the input state system 102 can utilize the transmissions and retransmissions of the various input states received from the video game input device 120 to generate a consistent view of the input state of the video game input device 120 at any given time. This remains true even when messages are dropped during transmission over the Internet, due to the redundancy included in the retransmissions. [ 004 3 ] As discussed above, the input state system 102 can receive input state information from an input device that is being used as a video game controller. As mentioned above, the Petition 870250088208, dated 09 / 29 / 2025, page 31 / 81 19 / 53 input state system 102 can utilize the blind preemptive relay protocol with any type of video game controller (e.g., a TV remote control, a wired gamepad, a keyboard and mouse connected to a PC browser). In at least one implementation, the video game input device 120 (e.g., a player's smartphone) can be converted into a video game controller, where one or more video game controller elements are displayed on a touchscreen display of the video game input device 120.

[0044] In one or more implementations, as mentioned above, the input state system 102 can cause the video game input device 120 to detect input states and transmit input state messages to the server(s) 112. To illustrate, the video game input device 120 can detect an input event including a selection of a left direction video game control element and a simultaneous selection of a running video game control element (e.g., the player is making his character run to the left). The video game input device 120 can then detect an input event including a selection of a jumping video game control element (e.g., the player is making his character jump). Finally, the video game input device 120 can detect an input event including a release of all video game control elements.In terms of individual events, this sequence of selections can be represented as: Event 1: Press the left steering wheel video game control element + the racing video game control element; Event 2: Press the video game control element. Petition 870250088208, dated 09 / 29 / 2025, page 32 / 81 20 / 53 jump; Event 3: Release the jump video game control element; Event 4: Unlock the left-hand steering video game control element + the racing video game control element.

[0045] In one or more implementations, the 120 video game input device can detect the following states in response to these detected selections: State 1: left-hand drive video game control element + racing video game control element; State 2: left-hand steering video game control element + racing video game control element + jumping video game control element; State 3: left-hand drive video game control element + racing video game control element; State 4: nothing.

[0046] In at least one implementation, the input state system 102 can effectively maintain a consistent view of the input state of the video game input device 120, receiving each state change atomically. This can be especially important if one or more detected states are transferred over the Internet, because network queues along the way can coalesce or split some input states that shouldn't be split.

[0047] Furthermore, by receiving each state change atomically, the input state system 1 02 can effectively handle input state message discards. For example, if an input state message associated with State 3 is discarded, the input state system 1 02 can infer the events associated with State 3 based on the events of State 4 (i.e., all elements of Petition 870250088208, dated 09 / 29 / 2025, page 33 / 81 21 / 53 video game controllers released). Thus, for example, the 102 input state system can avoid the loss of video game controller element releases by using atomic full state transmission.

[0048] In one or more implementations, the 102 input state system can handle several challenges associated with atomic full-state transmission. For example, relative coordinates can be used for mouse input devices (with pointer locking enabled) or for accelerometers. For example, the movement of a mouse can be captured as: 1. X: +1, Y: -1 2. X: +1, Y: -2 3. X: +1, Y: -3

[0049] Thus, to determine the total mouse movement during a single game loop, all X and Y coordinates would need to be summed. If one of the event messages is lost during transmission, the final result will be incorrect. [ 00 50 ] Thus, the 102 input state system can solve this problem by using absolute values ​​for relative events. For example, the input device can start at X=0 and Y=0. The 102 input state system can then apply the relative change at each state change using an encapsulated unsigned number to encode the new value. For example, when applying the relative change, mouse movements can be transmitted as: 1. X: 1, Y: 4294967295 2. X: 2, Y: 4294967293 3. X: 3, Y: 4294967290 [ 00 51 ] As discussed above, a primary goal of the 102 input state system is to reduce latency in Petition 870250088208, dated 09 / 29 / 2025, page 34 / 81 22 / 53 Input state transmission to improve video game-related performance 103. FIGS. 3A-3C illustrate issues related to previously used transmission algorithms. For example, as shown in FIG. 3A, the Transmission Control Protocol (TCP) may include a cumulative acknowledgment reliability protocol 302, where a sender must wait for acknowledgment messages from the receiver.

[0052] To illustrate, a sender can transmit messages from events 1 to 4 to a receiver. As shown in FIG. 3A, event 3 can be dropped at some point during transmission and not be received by the receiver. In this way, the receiver can transmit acknowledgments back to the sender that are associated with events 1, 2, and 4. In response to the determination that event 3 was not acknowledged by the receiver, the sender can retransmit event 3. The receiver can then transmit an acknowledgment of event 3 back to the sender. In this way, event 3 can take the time of two round trips to be retransmitted, which can delay all subsequent events. This protocol also offers no way to drop event 3, which may be preferable when there is excessive delay. [ 00 53 ] Some systems seek to improve the cumulative acknowledgment reliability protocol latency problem by preemptively retransmitting messages until an acknowledgment message is received from the receiver. For example, as shown in FIG. 3B, some systems use 304 preemptive cycle retransmission, where events can be grouped. To illustrate, the sender might transmit event 1, a group including events 1 and 2, a group including events 1-3, and a group including events 14. The receiver might acknowledge events 1, 2, 3, and 4 evenly. Petition 870250088208, dated 09 / 29 / 2025, p. 35 / 81 23 / 53 that the group including events 1-3 is discarded during transmission. In response to receiving acknowledgments of events 1 and 2, the sender may transmit a group including events 3, 4, and 5 because acknowledgments of events 3 and 4 have not yet been received from the receiver. The sender may then receive an acknowledgment of event 5 from the receiver. In the example shown in FIG. 3B, the loss of the event group 1-3 has a minimal impact on latency because the next event group repeats any previously unacknowledged events (e.g., the message that includes the event group 1-4).

[0054] Although preemptive cycle retransmission can improve transmission latency, the input state system 102 seeks to add a layer of security, especially when used in connection with specific data channels, such as a web real-time communication (WebRTC) data channel. As illustrated in FIG. 3C, some earlier systems addressed this situation with a partial recovery flow control transmission protocol 306 (PR-SCTP). In one or more implementations, PR-SCTP 306 can create separate multiplexed reliable substreams with the ability to set a timeout or maximum number of attempts in retransmissions, as well as unordered delivery. As shown in FIG. 3C and similarly to preemptive cycle retransmission 304, PR-SCTP 306 can transmit groups of events and retransmit unacknowledged events.PR-SCTP 30 6 also adds application event acknowledgments, in addition to sender-level acknowledgments within the PR-SCTP layer. [ 00 55 ] Even with the efficiencies introduced by PRSCTP 306, relying on receiver acknowledgments can introduce unwanted latency. Therefore, the input state system 102 improves the reliability protocol. Petition 870250088208, dated 09 / 29 / 2025, page 36 / 81 24 / 53 cumulative confirmation 302, the preventive cycle retransmission 304, and the PR-SCTP 306, removing this dependence on receiver acknowledgments. For example, as shown in FIG. 3D, the input state system 102 can trigger an input state protocol with blind preventive retransmission 308 that blindly retransmits events a predetermined number of times, regardless of any receiver acknowledgments. For example, as shown in FIG. 3D, the input state system 102 can transmit and retransmit each detected event a predetermined number of times (e.g., five times) without any receiver acknowledgment.

[0056] In one or more implementations, the predetermined number is selected to cover most event losses over the Internet. In the event that all packets containing a specific event are dropped, the 102 input state system can remain in a consistent input state because complete atomic states are transmitted with each packet. To illustrate, if all packets associated with event 2 are dropped (e.g., the second through sixth packets), the 102 input state system will still receive packets associated with events 3 and 4 due to complete atomic state retransmission.

[0057] As discussed above, the input state system 102 causes the video game input device 120 to transmit and retransmit input state information in response to an event (e.g., a detected selection of one or more video game control elements on the video game input device 120). However, this can create a problem when the video game 103 is slow and only a few buttons are pressed, without any further events for a few seconds. Thus, as shown in FIG. 3E, the last detected event (e.g., event 3) Petition 870250088208, dated 09 / 29 / 2025, page 37 / 81 25 / 53 cannot be retransmitted proactively until the next event (e.g., event 4) is detected. Therefore, when the packet associated with the last detected event is discarded, the receiver receives the last detected event (e.g., event 3) with a delay.

[0058] To solve this problem, the input state system 102 can determine that the sender (e.g., the video game input device 120) is in an idle state. As shown in FIG. 3F, the input state system 102 can cause the video game input device 120 to retransmit the last group of events when no new event is detected for a threshold amount of time until the predetermined number of retransmissions for each event in the event group is reached.

[0059] As mentioned above and as shown in FIG. 4, the input state system 102 performs several functions in connection with the transmission and retransmission of input states from the video game input device 120 to maintain a consistent input state in connection with the video game 103. FIG. 4 is a block diagram 400 of the input state system 102 operating within the memory 106 of the server(s) 112 while performing these functions. Thus, FIG. 4 provides additional details regarding these functions. For example, as shown in FIG. 4, the input state system 102 may include a communication manager 402 and an input state protocol manager 404 along with the video game 103. As shown in FIG. 4, the additional items 108 may store and maintain digital video game data 406. [ 00 60 ] In certain implementations, the input state system 102 may represent one or more software applications, modules, or programs that, when executed by a computing device, can cause the Petition 870250088208, dated 09 / 29 / 2025, page 38 / 81 26 / 53 computing device perform one or more tasks. For example, and as will be described in more detail below, one or more of the communication manager 402, the input state protocol manager 404, or the video game 103 may represent software stored and configured to run on one or more computing devices, such as the server(s) 112. One or more of the communication manager 402, the input state protocol manager 404, and the video game 103 of the input state system 102 shown in FIG. 4 may also represent all or parts of one or more special-purpose computers to perform one or more tasks.

[0061] As mentioned above and as shown in FIG. 4, the input state system 102 may include the communication manager 402. In one or more implementations, the communication manager 402 may transmit and receive data on the server(s) 112. In at least one implementation, the communication manager 402 may additionally cause the video game input device 120 to send and receive data. [ 00 62 ] As mentioned above and as shown in FIG. 4, the input state system 102 may include the input state protocol manager 404. In one or more implementations, the input state protocol manager 404 enforces the input state protocol with blind preemptive retransmission 08 between the video game input device 120 and the server(s) 112. For example, the input state protocol manager 404 may enforce the input state protocol with blind preemptive retransmission 308 according to a protocol definition. In at least one implementation, the protocol definition may include two types of messages: control messages and input state messages. For example, the manager Petition 870250088208, dated 09 / 29 / 2025, page 39 / 81 The 27 / 53 input state protocol 404 can use control messages for initialization procedures, authorization procedures, setting configuration procedures, and disconnection procedures. In one or more implementations, the 404 input state protocol manager can cause the video game input device 120 and / or the server(s) 112 to retransmit control messages until a corresponding confirmation message is received. Furthermore, the 404 input state protocol manager can blindly retransmit input state messages to carry one or more input states of the video game input device 120 without any type of confirmation message.

[0063] The protocol definition for the input-state protocol with blind preemptive retransmission 308 is now discussed in more detail. In one or more implementations, the input-state protocol is a binary protocol that operates in a binary format with ordered bits representing various data. In this way, the input-state protocol is extremely space-efficient, so that the control and input-state messages are very small. This efficiency allows the input-state system 102 to create input-state redundancy in input-state messages with minimal cost in terms of message size and transmission speed. To facilitate the discussion, the input-state protocol is described below to show the various types of information that are indicated by groups of bits within the structured control messages and input-state messages.It is understood that, although the input state protocol is already described in detail, the input state protocol can be implemented in its binary form. Petition 870250088208, dated 09 / 29 / 2025, pp. 40 / 81 28 / 53

[0064] In more detail, the 404 inbound status protocol manager can include certain data in control message headers. For example, the 404 inbound status protocol manager can include the following information in the header of a control message: s (1 bit): The 404 input state protocol manager can use this bit to differentiate between control messages and input state messages. In at least one implementation, the 404 input state protocol manager can set s to zero in control messages.

[0065] Version (7 bits): the 404 input state protocol manager can indicate the version of the blind preemptive retransmission protocol being used with these bits.

[0066] Device ID (24 bits): The 404 input state protocol manager can indicate the ID of the 120 video game input device to which messages are being sent and received with these bits. In at least one implementation, the 404 input state protocol manager can multiplex multiple devices on the same underlying transport channel based on their device IDs. For example, the Device ID can be unique across all controller devices connected to a given video game instance. Once negotiated, the 404 input state protocol manager can use the same Device ID for the entire lifetime of the 102 input state system during a given game session. The IP address of the 120 video game input device or the underlying transport can change without affecting the input states (e.g., sequence numbers, device configuration, authorization) of the device. Petition 870250088208, dated 09 / 29 / 2025, pp. 41 / 81 29 / 53 video game input 120.

[0067] Flags (4 bits): The 404 ingress state protocol manager can use flags for connection management. Flags may include: Ack (1 bit): The 404 input status protocol manager can use this indicator in acknowledgment messages.

[0068] Ini (2 bits): The 404 input status protocol manager can use this indicator to initialize the connection of a new control device.

[0069] Fin (4 bits): Input state protocol manager 404 can use this indicator to indicate the intention to disconnect video game input device 120.

[0070] Rco (8 bits): The 404 input state protocol manager can use this indicator to reassociate a session with a different underlying data or transport channel. For example, in case of reconnection of the underlying transport protocol, the 404 input state protocol manager can send a control message with the Rco indicator set to recover communication for the Device ID. Unless a valid control message with the Rco indicator set is sent by the 120 video game input device and a valid control message with the Ack indicator is received by the 120 video game input device, the 404 input state protocol manager can prevent the 120 video game input device from sending any additional input state messages and control messages.

[0071] Session ID (32 bits): Input state protocol manager 404 can cause video game input device 120 to generate the Session ID. Petition 870250088208, dated 09 / 29 / 2025, p. 42 / 81 30 / 53 as part of the initialization and can use the “Session ID” to add security and facilitate message routing. During the handshake, the 404 inbound state protocol manager can validate that the “Session ID” has not yet been used and can generate a random “Device ID” that has not yet been used. After the handshake, the 404 inbound state protocol manager can link the “Device ID” and the “Session ID” so that no control message can be accepted for a “Device ID” with a different “Session ID”. In this way, the “Session ID” can protect a message for a given “Device ID” from attackers who might try to exploit the fact that the lifetime of a device connection is not tied to the lifetime of the underlying secure protocol.

[0072] “Control Sequence Number” (32 bits): The 404 input state protocol manager adds a sequence number to each message. For example, the 404 input state protocol manager might increment the “Control Sequence Number” by one for each message. [ 007 3 ] “Acknowledgement Number” ( 32 bit s ) : when the “Ack” indicator is set, the input status protocol manager 4 04 can use the “Acknowledgement Number” to represent the pair control sequence number that this message confirms. [ 007 4 ] “Timestamp” (32 bits): The 404 input state protocol manager indicates the “Timestamp” as the number of milliseconds since the negotiated epoch at initialization (e.g., handshake). The 404 input state protocol manager can update the timestamp in control messages on each retransmission. [ 007 5 ] In addition to the control message headers, the 4 04 input state protocol manager also Petition 870250088208, dated 09 / 29 / 2025, page 43 / 81 31 / 53 can include certain data in incoming status message headers. For example, the 404 incoming status protocol manager can include the following information in the header of an incoming status message: s (1 bit) : the 404 input status protocol manager can set s to one in input status messages.

[0076] Version (7 bits): The 404 input state protocol manager can indicate the version of the blind preemptive retransmission protocol being used with these bits.

[0077] Device ID (24 bits): Input state protocol manager 404 can indicate the video game input device ID 120 to which messages are being sent and received with these bits.

[0078] States Group Sequence Number (32 bits): The 404 input state protocol manager can use the States Group Sequence Number to indicate a sequence number for the first input state group. This sequence number can be separated from the Control Sequence Number, and the 404 input state protocol manager can increment the States Group Sequence Number by one for each new input state group.

[0079] Timestamp (32 bits): The 404 input state protocol manager indicates the Timestamp as the number of milliseconds since the negotiated epoch at initialization (e.g., handshake).

[0080] In one or more implementations, before receiving input state messages from the video game input device 120, the input state protocol manager 404 may initialize the video game input device 120. For example, the manager of Petition 870250088208, dated 09 / 29 / 2025, page 44 / 81 32 / 53 Input State Protocol 404 can initialize Video Game Input Device 120 by causing Video Game Input Device 120 to send a control message to Server(s) 112 which includes: The Ini indicator is set to one in the control message header.

[0081] The Session ID is defined as a random value in the control message header.

[0082] The Control Sequence Number is set to another random, encapsulated value. In at least one implementation, the 404 input state protocol manager may set the States Group Sequence Number to the same random value.

[0083] The 404 ingress state protocol manager may also include configuration instructions for declaring ingress resources and authorizing the connection, as discussed in more detail below). [ 008 4 ] In response to receiving this control message on server(s) 112, the input state protocol manager 404 may generate and transmit a control message back to the video game input device 120, including: The Ini and Ack indicators are set to one. [ 008 5 ] The Device ID is defined as a randomly generated and unique ID for a current game session.

[0086] The Control Sequence Number set with a randomly generated server sequence number.

[0087] The Acknowledgement Number defined as the Control Sequence Number received from the 12 0 videogame input device. [ 0088 ] In one or more implementations, the 404 input state protocol manager can relay the initialization control message to the device of Petition 870250088208, dated 09 / 29 / 2025, page 45 / 81 33 / 53 video game input 120 until an acknowledgment message is received from the video game input device 120. In at least one implementation, the 404 input state protocol manager may additionally send an additional acknowledgment message to the video game input device 120 in response to receiving the acknowledgment message from the video game input device 120 (i.e., a bidirectional handshake).

[0089] In some implementations, the 404 inbound state protocol manager may include an inbound authorization secret token as part of an authorization flow. For example, the 404 inbound state protocol manager may not allocate resources if the inbound authorization secret token is not accepted. The 404 inbound state protocol manager may further implement more protection on the 112 server(s) by accepting to allocate a limited number of “Device IDs” per connection flow. By having only one secret token evaluated at a time, the 404 inbound state protocol manager can prevent certain types of attacks. The 404 inbound state protocol manager may send initialization control messages at any time during the lifetime of the connection. [ 00 90 ] When the video game input device 120 or the server(s) 112 wish to terminate the connection, the input state protocol manager 404 can send a control message with the “Fin” indicator set. In one or more implementations, a preemptive blind retransmission protocol disconnection may not terminate an established inbound communication. For example, a websocket may reconnect to the same endpoint and resume communication with the last “Device ID” / “Sequence”. Petition 870250088208, dated 09 / 29 / 2025, pp. 46 / 81 34 / 53 The “ID” is known. To associate a “Device ID” with this newly established connection, the 404 inbound state protocol manager can send a control message with the “RCO” indicator set to a matching “Device ID” / “Session ID” pair. In at least one implementation, the 404 inbound state protocol manager may not accept any inbound state information on a new device connection before a valid control message with the “Ini” or “Rco” indicator is received.

[0091] In some implementations, the 404 input state protocol manager may use the “Session ID” during the handshake when a websocket reflector is being used. For example, the 404 input state protocol manager may use the “Session ID” to route traffic back to the client for “Ini” + “Ack” control messages or “Rco” + “Ack” control messages. In these implementations, the websocket reflector may associate the “Device ID” with the “Session ID” based on the “Ack” control message from the 404 input state protocol manager. In one or more implementations, the 404 input state protocol manager may set the “Session ID” to zero for any control message to the 120 video game input device that has the “Rco” or “Ini” indicator set to prevent this information from leaking to an attacker. [ 00 92 ] With regard to acknowledgment control messages, the 404 ingress state protocol manager can proactively cause control messages to be retransmitted until a control message with the “Ack” indicator set to one with the message sequence number indicated by the “Acknowledgment Number” field is received. In at least one implementation, the 404 ingress state protocol manager can delay the retransmission of Petition 870250088208, dated 09 / 29 / 2025, page 47 / 81 35 / 53 control messages in ten milliseconds with an exponential fallback of up to one second.

[0093] If a control message with the Ack indicator set to one does not contain any other data, the 404 inbound status protocol handler cannot increment the “Sequence Number”. Instead, the 404 inbound status protocol handler can set the “Sequence Number” to zero and not send any corresponding “Ack” control message back.

[0094] In one or more implementations, the 404 input state protocol manager may create an acknowledgment for each received control message that has the “Ini”, “Rco”, or “Fin” indicator set and / or has a non-zero body. This may be true even if the sequence has already been received. Instead, the 404 input state protocol manager may buffer control messages for reordering and then interpret the control messages in order, without gaps. If a new control message is too far in the future for reordering purposes, the 404 input state protocol manager may close and then re-establish the connection. [ 00 95 ] With respect to timestamps, the 404 ingress state protocol manager can initialize the “Timestamp” field to zero in the first control message (e.g., the handshake). All subsequent messages can include this initial value as a reference (e.g., an epoch) with the difference added in milliseconds. For example, the “Timestamp” field can represent the time a message was sent. Thus, when the 404 ingress state protocol manager causes a message to be retransmitted (i.e., in accordance with blind preemptive retransmission), the 404 ingress state protocol manager can do Petition 870250088208, dated 09 / 29 / 2025, pp. 48 / 81 36 / 53 with which the Timestamp field is updated, even when the messages have the same Sequence ID.

[0096] In one or more implementations, a control message may include a control header (as discussed above) and a message body. In at least one implementation, the 404 input state protocol manager may format the message body of a control message as a control frame. The 404 input state protocol manager may generate several types of control frames, where each type of control frame has a custom format. The 404 input state protocol manager may use the different types of control frames to authorize an incoming connection, describe the capabilities of the 120 video game input device, etc. In at least one implementation, the 404 input state protocol manager may generate control frames with types including: Device_Info, Declare_Key, Declare_Rel, Declare_Abs, Declare_Rumble, Var, Retransmit_Factor, Ping, Auth, and Error.Each type of control panel is now described in more detail.

[0097] Device_Info (binary value 0): This type of control frame can define device information. For example, a Device_Info control frame might include: Props (e.g., some properties specific to the 120 video game input device). This can be used to define axis meanings by accelerometer data. For a gamepad with analog joysticks and an accelerometer, two separate devices can be declared: Device Name Length (e.g., a length of the device name string), Vendor, Product (e.g., standard vendor / product IDs that identify the device). Petition 870250088208, dated 09 / 29 / 2025, page 49 / 81 37 / 53 video game input 120), “Device Name” (e.g., video game input device name 120 as reported to video game 103). If the video game controller is a virtual controller, the “Device Name” may contain the player's username. In at least one implementation, the 404 input state protocol manager may require a “Device_Info” control frame when a control message has the “Ini” indicator set without the “Ack” indicator being set.

[0098] “Declare_Key” (binary value 1): This type of control frame can declare a key (or set of keys) supported by the 120 video game input device—or other type of input device. For example, a “Declare_Key” control frame might include: “R” which defines a track mode, and a “Key Code” field. When the “R” bit is set, the 40 4 input state protocol manager can use the “Key Code” field to declare the start of a track. Another “Declare_Key” control frame can be expected to declare the end of the track. This allows for the compact declaration of all the keys on a keyboard, for example. In at least one implementation, the “Declare_Key” control frame is used for each video game control element on the video game input device's touch screen display (or button / key supported by a dedicated game controller). [ 0 0 9 9 ] “Declare_Rel” (binary value 2): This type of control frame can declare a relative axis supported by the 120 video game input device (or other input device). For example, a “Declare_Rel” control frame can include a “Rel Code” representing an input key code associated with this axis (e.g., “Rel_X”, “Rel_Y”, etc.). In at least one implementation, the state protocol manager of Petition 870250088208, dated 09 / 29 / 2025, pp. 50 / 81 38 / 53 entry 404 uses a “Declare_Rel” control frame for each relative (infinite) axis, such as a mouse, a mouse wheel, or an accelerometer.

[00100] “Declare_Abs (binary value 3) : This type of control frame can declare and configure an absolute axis supported by the 120 video game input device (or other input device). For example, a “Declare_Abs” control frame can include: “Abs Code” which can include a corresponding input code associated with this axis (“Abs_X”, “Abs_Y”, etc.), “Default” which can specify the remaining value (e.g., zero), and “Maximum” which can specify a maximum value for the axis. For example, to define an axis that can go from -100 to 100, the 404 input state protocol manager can set “Default” to 100 and “Maximum” to 200. [ 0 0 1 0 1 ] “Declare_Rumble (binary value 4): This type of control frame can declare force feedback capabilities of the 12 0 video game input device (or other input device). For example, a “Declare_Rumble” control frame can include “RMB Cod” representing the vibration motor code. The 404 input state protocol manager can set the “RMB Cod” value to: “RMB_Low(0)” (e.g., low frequency motor) and “RMB_High(1)” (e.g., high frequency motor).

[00102] “Var (binary value 5) : This type of control frame can define a variable. For example, a “Var” control frame can include a “Name” (e.g., a variable name) and a “Value” (e.g., the variable value).

[00103] “Retransmit_Factor (binary value 10): This type of control frame can define the number of retransmissions that the video game input device 12 0 (or other Petition 870250088208, dated 09 / 29 / 2025, pp. 51 / 81 39 / 53 input device) can perform for each input state message (e.g., input state group). For example, the Retransmit_Factor can include a Count representing the number of blind retransmissions that should be performed for each input state message (e.g., input state group). In one or more implementations, the 404 input state protocol manager can dynamically adjust the Count associated with a Retransmit_Factor control frame based on network conditions.

[00104] Ping (binary value 11): This type of control frame can provide a mechanism for synchronizing the system clocks of the video game input device 120 (or other input device) and the server(s) 112. For example, a Ping control frame might include a P bit and a Received Timestamp. When P is set to 0 in a Ping control frame, the input state protocol manager 404 can send it back with P set to 1 and the Received Timestamp set to the timestamps in the control message header. The input state protocol manager 404 can send Ping control frames at regular intervals from the server(s) 112 to measure round trips and detect timeouts.

[00105] Auth (binary value 12): This type of control frame can provide a secret authorization token. For example, an Auth control frame can include a Secret Token and its corresponding Secret Token Length. The 404 input state protocol manager can use an Auth control frame as an authorization token to connect to a remote input device, such as the 12 0 video game input device.

[00106] Error (binary value 13): This frame type Petition 870250088208, dated 09 / 29 / 2025, pp. 52 / 81 Control panel 40 / 53 can provide context about an error that may occur when the configuration is rejected. For example, an Error control panel might include error codes such as: Unknown (0), Max_Input_Reached (1), Invalid_Config (2), Auth_Failed (3), Unsupported_Extension (4), and Unrecoverable_Loss (5).

[00107] In one or more implementations, an input state message may include an input state header (as discussed above) and a message body. In at least one implementation, the 404 input state protocol manager may format the message body of an input state as an input state frame. For example, the 404 input state protocol manager may use input state frames to communicate input state group messages. An input state frame may declare a series of input states grouped into atomic input states (e.g., a consistent view of all buttons / axes / vars that are active at a given time). The 120 video game input device may emit an input state group whenever a state change is detected relative to the 300 touchscreen display.In one or more implementations, an input state message can include more than one group of input states to implement the 408 blind preemptive retransmission protocol without needing to duplicate packets. The 404 input state protocol manager can utilize several types of input state frames, including: Group (binary value 0): This type of input state frame can group input states. For example, a Group input state frame can include a C bit. When C is set to zero (Group_States), the 404 input state protocol manager can... Petition 870250088208, dated 09 / 29 / 2025, pp. 53 / 81 41 / 53 Grouping input states as a consistent state of the 120 video game input device. When more than one of these groups is present in a single message, the 404 input state protocol manager can decrement the “Sequence ID” of the input state message. When “C” is set to a (“Group_Sub”), the 404 input state protocol manager can group input states to construct a more complex description (e.g., as with multi-finger touch inputs). A “Group” input state frame can additionally include a “Length” (e.g., a number of bytes for this group) that the 404 input state protocol manager can use to quickly jump to the next group of input states without parsing, in case the “Sequence ID” has already been received.If “C” is set to 0 (“Group_States”) and “Length” is zero, the 404 input state protocol manager can determine that the 120 video game input device is in an idle state (e.g., all video game control elements are in their default state). The 404 input state protocol manager can ignore “Length” if “C” is set to one (“Group_Sub”). An input state frame “Group” can also include “Time Delta”, which can be a number of milliseconds separating that group from the input state message timestamp. Because groups can be sorted within an input state message in antichronological order, the 404 input state protocol manager can subtract the “Time Delta” from the input state message timestamp.

[00108] “Key” (binary value 1): This type of input state frame can define a video game control element (e.g., a key that is pressed). By Petition 870250088208, dated 09 / 29 / 2025, pp. 54 / 81 42 / 53 For example, a Key input status frame might include a Code that represents a pressed input key code (e.g., Key_A, Key_Leftshift, etc.).

[00109] Rel (binary value 2): This type of input state frame can define a change of a relative axis. For example, a Rel input state frame might include a Code (e.g., the input key code associated with this axis) and a Value (e.g., the resolved absolute value of the relative movement since the last input state expressed as a 24-bit value).

[00110] Abs (binary value 3): This type of input status frame can define an absolute axis change. For example, an Abs input status frame might include a Code (e.g., the corresponding input key code associated with this axis) and a Value (e.g., the new absolute position for this axis). [ 00111 ] Rumble (binary value 4) : This type of input state frame can define the noise associated with the 120 video game input device (or other input device). For example, a Rumble input state frame might include an RMB Cod (e.g., RMB_Low (0) or RMB_High (1)) and a Frequency (e.g., the motor frequency). The 404 input state protocol manager can send a Rumble input state frame to the 120 video game input device for each motor declared by the 120 video game input device during initialization (e.g., handshake).

[00112] To better illustrate how the 404 input state protocol manager utilizes the blind preemptive retransmission protocol, an example of a connection lifecycle between the video game input device 120 and the server(s) 112 is now provided. The example Petition 870250088208, dated 09 / 29 / 2025, pp. 55 / 81 43 / 53 described below includes a textual representation of the input state protocol. It is understood, however, that the input state protocol can be implemented in its binary format. In the example below, the video game input device 120 may include video game control elements, including a D-pad (e.g., with up, down, right, and left buttons), a joystick, and two additional buttons (e.g., an A button and a B button). First, the input state protocol manager 404 may initialize the connection to the video game input device 120: > video game input device 12 0 Control INI, Session 987, Device 0, Seq 456, Timestamp 0 DEVICE_INFO Vendor: xx Product: xx Length: 12 Device Name: Bob's iPhone DECLARE_KEY Code: BTN_DPAD_UP DECLARE_KEY Code: BTN_DPAD_DOWN DECLARE_KEY Code: BTN_DPAD_LEFT DECLARE_KEY Code: BTN_DPAD_RIGHT DECLARE_KEY Code: BTN_A DECLARE_KEY Code: BTN_B DECLARE_ABS Code: ABS_X Petition 870250088208, dated 09 / 29 / 2025, pp. 56 / 81 44 / 53 Default: 512 Maximum: 1024 AUTH Secret Token: xxx

[00113] The 404 inbound state protocol manager can cause server(s) 112 to respond with an Ack message that includes a “Session ID” and a “Device ID” that will be included in future messages during this connection lifecycle: < video game 103 Control INI+ACK, Session 987, Device 123, Seq 890, Ack 456, Timestamp 0 # here seq is the receiver's seq init

[00114] At this point, since server(s) 112 sent a control message to video game input device 120, input state protocol manager 404 can cause video game input device 120 to send an “Ack” message back to server(s) 112: > video game input device 120 Control ACK, Session 987, Device 123, Seq 457 , Ack 8 90, Timestamp 50 [ 0011 5 ] With the video game input device 120 connected, the input state protocol manager 404 can cause the video game input device 120 to transmit input state messages. In this example, the player may have used the video game control elements displayed on the touchscreen display 300 of the video game input device 120 to go right, then jump, and then release all buttons: > video game input device 120 # go right States Device 123, Seq 457, Timestamp: 123 # Seq is states sequence GROUP Petition 870250088208, dated 09 / 29 / 2025, pp. 57 / 81 45 / 53 Code: GROUP_STATES Length:<computed length of this groups> Time Delta: 0 # the first group's delta is set to 0 KEY Code: BTN_DPAD_RIGHT > video game input device 120 # jump States Device 123, Seq 458, Timestamp: 133 GROUP Code: GROUP_STATES Length: <computed length of this groups> Time Delta: 0 KEY Code: BTN_DPAD_RIGHT KEY Code: BTN_A GROUP # the previous event states are repeated starting here Code: GROUP_STATES Length: <computed length of this groups> Time Delta : 10 # this is 1 33-12 3 KEY Code: BTN_DPAD_RIGHT > video game input device 12 0 # release all buttons States Device 123, Seq 459, Timestamp: 153 GROUP Code: GROUP_STATES Length: 0 Time Delta: 0 # a GROUP with zero Length means all buttons released GROUP Code: GROUP_STATES Length: <computed length of this groups> Time Delta : 20 Petição 870250088208, de 29 / 09 / 2025, pág. 58 / 81 46 / 53 KEY Code: BTN_DPAD_RIGHT KEY Code : BTN_A GROUP Code: GROUP_STATES Length:<computed length of this groups> Time Delta: 10 KEY Code: BTN_DPAD_RIGHT

[00116] After this, the 120 video game input device can disconnect: > video game input device 12 0 Control FIN Session 988, Device 123, Seq 459 # Seq is control sequence < video game 103 Control FIN+ACK Session 988, Device 123, Seq 892, Ack 458

[00117] As shown in FIG. 4, and as mentioned above, the input state system 102 may include the video game 103. In one or more implementations, the video game 103 may poll received input states from the video game input device 120. The video game 103 may further update the gameplay based on these polls. For example, the video game 103 may detect inconsistencies (e.g., dropped messages) in the atomic input states received from the video game input device 120. The video game 103 may further resolve these inconsistencies from the input state information redundancies built into the preemptive blind retransmission protocol.

[00118] As shown in FIGS. 1 and 4, server(s) 112 may include one or more processors. Petition 870250088208, dated 09 / 29 / 2025, pp. 59 / 81 47 / 53 physical processors, such as the physical processor 110. The physical processor 110 can generally represent any type or form of processing unit implemented in hardware capable of interpreting and / or executing computer-readable instructions. In an implementation, the physical processor 110 can access and / or modify one or more components of the input state system 102. Examples of physical processors include, without limitation, microprocessors, microcontrollers, central processing units (CPUs), field-programmable gate arrays (FPGAs) implementing softcore processors, application-specific integrated circuits (ASICs), parts of one or more thereof, variations or combinations of one or more thereof, and / or any other suitable physical processor.

[00119] In addition, the server(s) 112 may include memory 106. In one or more implementations, memory 106 generally represents any type or form of volatile or non-volatile storage device or medium capable of storing computer-readable data and / or instructions. In one example, memory 106 may store, load, and / or maintain one or more input state system components 102. Examples of memory 106 may include, without limitation, random access memory (RAM), read-only memory (ROM), flash memory, hard disk drives (HDDs), solid-state drives (SSDs), optical disk drives, caches, variations or combinations thereof, and / or any other suitable storage memory.

[00120] In addition, as shown in FIG. 4, server(s) 112 may include additional items 108. On server(s) 112, additional items 108 may include digital video game data 406. In one or more implementations, digital video game data 406 may include definitions for the input state protocol with Petition 870250088208, dated 09 / 29 / 2025, pp. 60 / 81 48 / 53 blind preemptive retransmission, as discussed above. Digital videogame data 406 may also include information associated with videogame 103.

[00121] In summary, the 102 input state system can increase the speed and accuracy with which video games can be played on a network such as the Internet. For example, as described above, the 102 input state system can utilize a blind preemptive retransmission protocol that overcomes the shortcomings of previous protocols, causing a video game controller (e.g., like the 120 video game input device) to transmit an input state in response to a detected input event. The 102 input state system can additionally cause the video game controller to retransmit the same input state a predetermined number of times without waiting for any acknowledgment message from the receiver. The 102 input state system further reduces latency by grouping retransmissions of older input states with transmissions of new input states.Thus, the 102 input state system creates a high level of redundancy in input state transmission without duplicating packets, which can make the game slower. Examples of Modalities

[00122] Example 1: A computer-implemented method for blindly transmitting and retransmitting complete input states from a video game controller over the Internet, so that the corresponding video game can maintain a consistent input state. For example, the method might include receiving, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first message of Petition 870250088208, dated 09 / 29 / 2025, pp. 61 / 81 49 / 53 input state comprising a first input state of the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state, received from the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state,and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[00123] Example 2: The computer-implemented method of Example 1, wherein user interactions on the video game input device in connection with the video game include at least one single-finger touch gesture user interaction or multi-finger touch gesture user interaction.

[00124] Example 3: The computer-implemented method of either Examples 1 and 2, including additionally receiving control message transmissions from the video game input device and using the control messages for at least one of a startup procedure with the video game input device, an authorization procedure with the input device. Petition 870250088208, dated 09 / 29 / 2025, pp. 62 / 81 50 / 53 videogame, a device setup procedure with the videogame input device, or a disconnection procedure with the videogame input device.

[00125] Example 4: The computer-implemented method of any of Examples 1-3, including additionally, in response to receiving a transmission of a control message, generates an acknowledgment message associated with the control message and transmits the acknowledgment message to the video game input device.

[00126] Example 5: The computer-implemented method of any of Examples 1-4, wherein the first input status message, the second input status message, and the additional control messages include a device ID associated with the video game input device.

[00127] Example 6: The computer-implemented method of any of Examples 1-5, wherein the predetermined number of retransmissions is defined by a retransmission factor included in at least one of the control messages.

[00128] Example 7: The computer-implemented method of any of Examples 1-6, wherein the second input state message additionally includes a time delta indicating a number of milliseconds separating the first input state of the video game input device from a timestamp associated with the second input state message.

[00129] Example 8: The computer-implemented method of any of Examples 1 through 7, including additionally, in response to receiving no transmission of input status messages from the video game input device for more than a threshold amount of time, determines that the video game input device Petition 870250088208, dated 09 / 29 / 2025, pp. 63 / 81 51 / 53 is in an idle state.

[00130] In some examples, a system may include at least one processor and physical memory including computer executable instructions that, when executed by at least one processor, cause at least one processor to perform various acts. For example, the computer executable instructions may cause at least one processor to perform acts including receiving, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first input state message comprising a first input state from the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state,To receive, from the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state, and to update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[00131] In addition, in some examples, a legible medium Petition 870250088208, dated 09 / 29 / 2025, pp. 64 / 81 52 / 53 Non-transient computer instructions may include one or more computer executable instructions that, when executed by at least one processor of a computing device, cause the computing device to perform various acts. For example, one or more computer executable instructions may cause the computing device to receive, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: 1) a transmission of a first input state message comprising a first input state of the video game input device, and 2) a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state, receive,From the video game input device and in response to additional user interactions on the video game input device in connection with the video game: 1) a second input state message comprising a second input state of the video game input device and the first input state of the video game input device, and 2) the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state, and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

[00132] Unless otherwise indicated, the terms connected to and coupled to (and their derivatives), as Petition 870250088208, dated 09 / 29 / 2025, pp. 65 / 81 53 / 53 used in the descriptive report and claims should be interpreted as allowing for both direct and indirect connection (i.e., through other elements or components). Furthermore, the terms "a" or "an," as used in the descriptive report and claims, should be interpreted as meaning "at least one of." Finally, for ease of use, the terms "including" and "having" (and their derivatives), as used in the descriptive report and claims, are interchangeable and have the same meaning as the word "comprising." Petition 870250088208, dated 09 / 29 / 2025, pp. 66 / 81

Claims

1 / 8 CLAIMS 1. A computer-implemented method, characterized in that it comprises: receiving, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: a transmission of a first input state message comprising a first input state of the video game input device; and a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state;To receive, from the video game input device and in response to additional user interactions on the video game input device in connection with the video game: a second input state message comprising a second input state of the video game input device and the first input state of the video game input device; and the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state; and to update the video game gameplay based on the input state information received in the first input state message and the second input state message.

2. A computer-implemented method according to claim 1, characterized in that the user interactions on the video game input device in connection with the video game comprise at least one of the user interactions of one-finger touch gestures or multi-finger touch gestures.

3. A computer-implemented method according to claim 1, characterized in that it further comprises: receiving control message transmissions from the video game input device; and using the control messages for at least one of a startup procedure with the video game input device, an authorization procedure with the video game input device, a device configuration procedure with the video game input device, or a disconnection procedure with the video game input device.

4. A computer-implemented method according to claim 3, characterized in that it further comprises, in response to receiving a transmission of a control message, generating a confirmation message associated with the control message and transmitting the confirmation message to the video game input device.

5. A computer-implemented method according to claim 3, characterized in that the first input status message, the second input status message, and the additional control messages comprise a device ID associated with the video game input device.

6. Computer-implemented method according to claim 3, characterized in that the predetermined number of retransmissions is defined by a retransmission factor included in at least one of the control messages.

7. A computer-implemented method according to claim 1, characterized in that the second input state message additionally comprises a time delta indicating a number of milliseconds separating the first input state of the video game input device from a timestamp associated with the second input state message.

8. A computer-implemented method according to claim 1, characterized in that it further comprises, in response to receiving no transmission of input status messages from the video game input device for more than a threshold amount of time, determining that the video game input device is in an idle state.

9. A system, characterized in that it comprises: at least one physical processor; and physical memory comprising computer executable instructions which, when executed by the at least one physical processor, cause the at least one physical processor to perform acts comprising: receiving, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: a transmission of a first input state message comprising a first input state of the video game input device; and a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state; Petition 870250088208, dated 09 / 29 / 2025, p.69 / 81 4 / 8 receive, from the video game input device and in response to additional user interactions on the video game input device in connection with the video game: a second input state message comprising a second input state of the video game input device and the first input state of the video game input device; and the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state; and update the video game gameplay based on the input state information received in the first input state message and the second input state message.

10. System according to claim 9, characterized in that user interactions on the video game input device in connection with the video game comprise at least one of the user interactions of single-finger touch gestures or multi-finger touch gesture user interactions.

11. System according to claim 9, characterized in that it further comprises computer executable instructions which, when executed by at least one physical processor, cause the at least one physical processor to perform acts comprising: receiving control message transmissions from the video game input device; and using the control messages for at least one of a startup procedure with the video game input device, an authorization procedure with the video game input device, a device configuration procedure with the video game input device, or a disconnection procedure with the video game input device.

12. System according to claim 11, characterized in that it further comprises computer executable instructions which, when executed by at least one physical processor, cause that physical processor to perform an action comprising, in response to receiving a transmission of a control message, generating an acknowledgment message associated with the control message and transmitting the acknowledgment message to the video game input device.

13. System according to claim 11, characterized in that the first input status message, the second input status message, and the additional control messages comprise a device ID associated with the video game input device.

14. System according to claim 11, characterized in that the predetermined number of retransmissions is defined by a retransmission factor included in at least one of the control messages.

15. System according to claim 9, characterized in that the second input state message additionally comprises a time delta indicating a number of milliseconds separating the first input state of the video game input device from a timestamp associated with the second input state message.

16. System according to claim 9, characterized in that it further comprises computer executable instructions which, when executed by at least one physical processor, cause at least one physical processor to perform an act comprising, in response to receiving no input status message transmission from the video game input device for more than a threshold amount of time, determining that the video game input device is in an idle state.

17. Non-transient computer-readable medium, characterized in that it comprises one or more computer-executable instructions which, when executed by at least one processor of a computing device, cause the computing device to: receive, from a video game input device used as a video game controller and in response to user interactions on the video game input device in connection with a video game displayed on a display device: a transmission of a first input state message comprising a first input state of the video game input device; and a predetermined number of retransmissions of the first input state, wherein the retransmissions of the first input state are received without providing an acknowledgment associated with the first input state;to receive, from the video game input device and in response to additional user interactions on the video game input device in connection with the video game: a second input state message comprising a second input state of the video game input device and the first input state of the video game input device; and the predetermined number of retransmissions of the second input state, wherein the retransmissions of the second input state are received without providing an acknowledgment associated with the second input state; and to update the video game gameplay based on the input state information received in the first input state message and the second input state message.

18. Non-transient computer-readable medium according to claim 17, characterized in that it further comprises one or more computer-executable instructions which, when executed by at least one processor of the computing device, cause the computing device to: receive control message transmissions from the video game input device; and use the control messages for at least one of a startup procedure with the video game input device, an authorization procedure with the video game input device, a device configuration procedure with the video game input device, or a disconnection procedure with the video game input device.

19. Non-transient computer-readable medium according to claim 18, characterized in that it further comprises one or more computer-executable instructions which, when executed by at least one processor of the computing device, cause the computing device, in response to receiving a transmission of a control message, to generate an acknowledgment message associated with the control message and to transmit the acknowledgment message to the video game input device.

20. Non-transient computer-readable medium according to claim 19, characterized in that the second input state message additionally comprises a time delta indicating a number of milliseconds separating the first input state of the video game input device from a timestamp associated with the second input state message.

Images