DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
Claims 1, 8, 9, 16 and 17 have been amended.
Claim 6 and 14 have been cancelled
Claims 1-5, 7-13, 15-21 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-5, 7-13 and 15-21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zimring et al (US 2021/0113927) in view of Tayloe et al (US 11,870,585) in view of “Quake 3 Network Protocol” by Jacek Fedoryński, (hereinafter “Fedorynski”) in view of USB – Device Class Definition for Human Interfaces (HID), 2001 (hereinafter USB)
As per claim 1, Zimring discloses a gaming system 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 : (Zimring discloses a video game input device used as a game controller that a user utilized to play an interactive video game by means of transmitting inputs to a game server and the game server transmitting game data such as game media streams to the game client and input device) (Zimring 0070)
a first input state message comprising a first input state of the video game input device corresponding to the user interactions ; and (Zimring discloses the transmission of input messages or signals that comprise input states of the input device) (Zimring 0070)
updating gameplay of the video game based on input state information received in the first input state message and the second input state message. (Zimring discloses the updating of the video game based upon multiple input messages sent from the game controller (i.e. first and second input messages) (Zimring 0141, 0145 – 0147)
Zimring fails to disclose:
receiving, from a video game input device used as a video game controller, a control message that includes a retransmit factor defining a predetermined number of retransmissions for input state messages; performing at least one procedure based at least in part on the control message;
wherein the predetermined number of retransmissions of the first input state are received without providing an acknowledgement associated with the first input state;
receiving, 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 the first input state of the video game input device and a second input state of the video game input device corresponding to the additional user interactions; and
wherein the predetermined number of retransmissions of the second input state are received without providing an acknowledgement associated with the second input state; and
receiving, in response to determining that the video game input device is in an idle state, one or more retransmissions of a most recently transmitted group of input states until the predetermined number of retransmissions has been received for each input state in the group;
However, in a similar field of endeavor, wherein data signals are transmitted between two devices, Tayloe discloses a communication system that transmits data messages between devices, wherein a transmitting entity will transmit a data message and retransmit the message a predetermined number of times without receiving an acknowledgment and also will retransmit a second message that comprises data that was used in a previous message without an acknowledgment (Tayloe 7:44 – 8:10, 8:17 – 25, 41 – 58).
It would be obvious to one of ordinary skill in the art, at the time of filing, to modify Zimring in view of Tayloe to use known technique to improve similar devices in the same way by utilizing a transmission technique of retransmitting messages repeatedly a predetermined number of times without an acknowledgment and wherein the retransmitted of a second message includes data from the first message. This would be beneficial as there is a measure of latency when game controllers communicate with game servers and as using this mechanism for transmission may cover high latency scenarios wherein stop and wait HARQ does not work (Tayloe 8:23 – 25)
However, in a similar field of endeavor, wherein data signals are transmitted between two devices, Fedorynski discloses the use of input commands sent by an input device to a server wherein the commands comprise previous commands in addition to the current input state commands and they are repeatedly sent without waiting for an acknowledgement and they are retransmitted for a configurable (i.e dynamically amount) of times. Fedorynski teaches “Client commands and server commands are text commands that are used for things like player chats and sending scores. They are reliable messages so they must be confirmed and retransmitted if necessary. Every client and server command has a sequence number and every packet sent by the server or the client contains the sequence number of the last command received from the other side. How does the client and the server decide when to retransmit a command? They just retransmit all commands until they are acknowledged. This means that if the network latency is high enough, commands will be repeated even if there is no packet loss, if the interval between packets is shorter than the time a packet needs to reach the other side and the confirmation to return. User commands containing player movement are not reliable in the sense that they absolutely need to be received by the server (after some time they’re useless anyway), so the client won’t retransmit them indefinitely. But we would still prefer if all of them reached the server, even in the face of packet loss. So while there is no direct confirmation mechanism, user commands are also retransmitted by default. But instead of retransmitting them until confirmed, the client just repeats them a fixed (configurable) number of times. By default each user command is sent twice. That way if one packet is lost, the server still gets the player’s movement in the next packet” (Fedorynski page 6)
It would be obvious to one of ordinary skill in the art, at the time of filing, to modify Zimring in view of Fedorynski to use a known technique to improve similar devices in the same way by utilizing a data communication method of transmitting a first message that comprises a history of previous inputs and to retransmit a configurable number of times for redundancy. This would be beneficial as it would compensate for latency when packets are lost.
In a similar field of endeavor, USB specification teaches the retransmission of duplicate reports in response to a devices state remaining unchanged (i.e. unchanged state equivalent to an idle state) “If the interrupt in endpoint is servicing multiple reports, then the Set Idle request may be used to affect only the rate at which duplicate reports are generated for the specified Report ID. For example, a device with two input reports could specify an idle rate of 20 milliseconds for report ID 1 and 500 milliseconds for report ID 2. The recommended default idle rate (rate when the device is initialized) is 500 milliseconds for keyboards (delay before first repeat rate) and infinity for joysticks and mice. “(USB page 53 – 54)
It would be obvious to one of ordinary skill in the art, at the time of filing, to modify Zimring and Fedorynski in view of USB to receive duplicate transmissions in response to an idle state of the device. This would be beneficial as the system would still be able to transmit the needed duplicate input states in the event that the end destination did not receive the most recent input state, but at the same time still conserve power when the input device is set to an idle state due to not being used or actively transmitting.
As per claim 2, wherein the user interactions on the video game input device in connection with the video game comprise at least one of single-finger touch gesture user interactions or multi-finger touch gesture user interactions. (Zimring discloses a touch interface receiving at least a single touch gesture) (Zimring 0056)
As per claim 3, an initialization 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 disconnect procedure with the video game input device . (Zimring discloses the transmitting a gaming setup command and authorization procedures. “The application is further being configured to implement a second mode (e.g., gameplay mode) in which the game controller transmits gameplay commands to the gaming server and a predefined subset of the gaming setup commands to the interface device. In some implementations, the interface device is proximate to the game controller. In some implementations, the game controller and the interface device are connected on the same local network, and the game controller transmits the gaming setup commands to the interface device over the same local network. In some implementations, the game controller stores multiple user credentials and multiple network credentials.) (Zimring 0016, 0116)
As per claim 4, further comprising, in response to the control message, generating an acknowledgement message associated with the control message and transmitting the acknowledgement message to the video game input device . (Combination of Zimring in view of Tayloe, wherein Tayloe discloses the generation of an acknowledgement message and transmitting it between devices in response to an initial transmission message) (Tayloe 9:40- 52)
As per claim 5, wherein the first input state message, the second input state message, and the control message further comprise a device ID associated with the video game input device (Zimring discloses the messages that are transmitted comprise a device ID associated with the input device) (Zimring 0098)
As per claim 6, wherein the predetermined number of retransmissions is defined by a retransmit factor included in at least one of the control messages. (Combination of Zimring in view of Tayloe, wherein Tayloe discloses that retransmission times depend on the distances between transmitting and receiving entities) (Tayloe 7:58 -60)
As per claim 7, wherein the second input state message further comprises a time delta that indicates a number of milliseconds that separate the first input state of the video game input device from a timestamp associated with the second input state message. (Combination of Zimring in view of Tayloe, wherein Tayloe discloses that retransmission of messages that have a calculated time difference or delta in milliseconds such as 0, 8, 16, 24 and 32 msec) (Tayloe 7:58 -8:8)
As per claim 8, further comprising, in response to receiving no input state message transmissions 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. (Zimring discloses the determination if the system is in standby or idle based upon not receiving any inputs from the game controller, thus the game controller is idle as well) (Zimring 0072)
Independent claim(s) 9 and 17 is/are made obvious by the combination of Zimring Tayloe, Fedorynski and USB based on the same analysis set forth for claim(s) 1, which are similar in claim scope.
Dependent claim(s) 10 -13, 15- 16 is/are made obvious by the combination of Zimring Tayloe, Fedorynski and USB based on the same analysis set forth for claim(s) 2 – 5, 7, 8 which are similar in claim scope.
Dependent claim(s) 18 - 20 is/are made obvious by the combination of Zimring Tayloe, Fedorynski and USB based on the same analysis set forth for claim(s) 3, 4 and 7, respectively, which are similar in claim scope.
Claim(s) 21 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zimring et al (US 2021/0113927) in view of Tayloe et al (US 11,870,585) in view of “Quake 3 Network Protocol” by Jacek Fedoryński, (hereinafter “Fedorynski”) in view of USB – Device Class Definition for Human Interfaces (HID), 2001 (hereinafter USB) in view of Hua et al (US 8,873,543)
As per claim 21, Zimring fails to disclose:
further comprising: dynamically adjusting the retransmit factor based at least in part on one or more network conditions; and receiving, from the video game input device, the predetermined number of retransmissions of a last input state.
However, Hua teaches “The QoS manager at each VoIP device executes the burst retransmission by causing the media transport protocol module to retransmit the voice packet one or more times. Depending on the network bandwidth, the QoS manager may decide to retransmit only the voice packets of high energy levels (i.e., voice packets that contain audible sounds). Depending on the packet loss rate, the QoS manager may adjust the number of times a voice packet is retransmitted.” (Hua 6:7 – 14). Thus as can be seen the QoS manager resides on the endpoint device and observes the packet loss of the network and adjusts the retransmission count.
It would be obvious to one of ordinary skill in the art, at the time of filing, to modify Zimring in view of Hua to provide a communication mechanism that determined the number of retransmissions based upon a control message depending on the current network conditions. This would be beneficial as it would dynamically retransmit messages as needed based upon how the network is performing and this saving bandwidth and processing power.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-5,7-13 and 15-21 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Please see above rejection addressing the newly amended claim limitations in view of newly found references to Fedorynsk and USB.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ROSS A WILLIAMS whose telephone number is (571)272-5911. The examiner can normally be reached Mon-Fri 8am - 4pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kang Hu can be reached at (571)270-1344. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RAW/ Examiner, Art Unit 3715
9/30/2026
/KANG HU/ Supervisory Patent Examiner, Art Unit 3715
