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 .
Applicant’s Submission of a Response
Applicant’s submission of a response on 6/12/2026 has been received and considered. In the response, no amendments were made. Therefore, claims 1 – 7, 10 – 12, 15, 17 – 19, 22 – 26 and 31 are pending.
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1 – 4, 6 – 7, 10 – 12, 15, 17 – 19, 22 – 26 and 31 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Tamasi et al. (US Pub. No. 2014/0189091 A1).
As per claim 1, Tamasi et al. discloses a method implemented in a client device (see [0026] and [0030]), the method comprising:
receiving, from a cloud server, video frames of a game running on the cloud server (a cloud gaming architecture, Fig. 1 and Fig. 2, in which a cloud data center server renders graphical images of a video game and streams them as encoded video frames to a client device over the internet, see [0003], [0025] and [0026]);
receiving input information from at least one input device of the client device, resulting from user interactions associated with the video frames (user input received in the client device 109 through a graphical user interface, or other hardware input devices such as a mouse, keyboard, or controller is transmitted directly to the server 103, and the next series of images in a sequence or a new series of images responsive to user input may be processed, rendered, encoded, and streamed back to the client device 109, see [0026]);
transmitting the input information to the cloud server (at step 403, the user input is transmitted to a connected game server, user input (e.g., controller input) received in the client device 209 is then forwarded back to the server 201 and recorded, before programmed instructions corresponding to the user input are referenced and a new or next sequence of images are processed and rendered, see [0031] and [0038]);
receiving consumption rate information associated with the running game, wherein the consumption rate information is representative of a rate at which the cloud server processes the input information (once the video data received from the cloud server is decoded and displayed at the client device 209, the length of time since the user input was sent is measured—i.e., a latency value representative of the rate at which the cloud server processes the input information is determined at the client device based on receiving and decoding the received video frames, see [0038]; further the data transmissions between the server 201 and the client device 209 during an active game session are performed according to the Real-time Transport Protocol (RTP), under which latency and packet loss are constantly measured for the transmissions between the server 201 and the client device 209, see [0032]); and
adjusting an input transmission rate at which the input information is transmitted to the cloud server based on the received consumption rate information, wherein the adjustment is performed to stabilize a perceived latency at the client device (a closed-loop rate-control framework in which the constantly-measured latency of the active game session governs the dynamic adjustment of the transmission rates at which data of the active game session is transmitted under RTP in order to reduce and stabilize the perceived latency; when the measured latency is high (above a pre-determined threshold) the rates are dynamically increased/adjusted, and when the measured latency is low (below a second pre-determined threshold) the rates are correspondingly capped, see [0032], [0036])
As per claim 2, Tamasi et al. discloses receiving the consumption rate information comprises determining a consumption rate value at the client device based on receiving and decoding the video frames received from the cloud server (when the user input is received in the game server, a sequence of images may be rendered that is responsive to the input received. The sequence of images may be then encoded as a video and streamed over the network connection, where it is received by the client device at step 405. The encoded data is subsequently decoded at step 407, and finally displayed in the display device at step 409. Once the received data is decoded and displayed, the length of time since the user input was received may be measured and communicated to the game server as the determined latency, see [0038]).
As per claim 3, Tamasi et al. discloses the consumption rate information is received from the cloud server and wherein the consumption rate information indicates a consumption rate value at the cloud server, the consumption rate value indicating the rate at which the cloud server processes the received input information (see [0032]).
As per claim 4, Tamasi et al. discloses the consumption rate information is received from the cloud server and wherein a consumption rate value is determined at the client device based on the received consumption rate information, the consumption rate value being representative of the rate at which the cloud server processes the received input information (see Fig. 4:405-409, [0037] – [0038]).
As per claim 6, Tamasi et al. discloses the consumption rate information indicates at
a game frame rate at which the running game is rendered by a game rendering thread and a server frame rate at which the video frames of the running game are any of encoded and
captured on the cloud server (see [0035]).
As per claim 7, Tamasi et al. discloses the consumption rate information comprises a
timestamp indicating occurrence at the cloud server of any of an input event and a frame rendering event (data transmissions during active game sessions are performed according to the Real-time Transport Protocol (RTP), see [0032]).
As per claim 10, Tamasi et al. discloses the consumption rate information is received
on a regular basis (monitoring may be performed continuously as periodic intervals, to accompany events (e.g., successful or unsuccessful transmissions), and/or responsive to frequent trigger events. When the monitored latency is determined to be within normal boundaries, that is, not exceeding one or more pre-determined thresholds, steps 301-307 are repeated for the duration of the gaming session, see [0035]).
As per claim 11, Tamasi et al. discloses receiving updated consumption rate
information if at least one of the input consumption rate, the game frame rate, the server frame rate, or the filling ratio changes (Once adjusted (either increased or decreased), the next sequence of frames are rendered with the adjusted frame rate, and steps 301 through 307 are repeated, see [0036]).
As per claim 12, Tamasi et al. discloses the consumption rate information is
encapsulated in metadata of a video stream comprising the video frames of the running game (see Fig. 3 and [0032] – [0034]).
As per claim 15, Tamasi et al. discloses a predicted consumption rate value is
determined at the client device based on a history of previous consumption rate information received from the cloud server (a default profile/heuristic that includes values for the render, stream, and/or display frame rates may be created and stored per game, see [0032]).
As per claim 17, Tamasi et al. discloses a method implemented in a cloud server (server 201; see [0031]), the method comprising:
transmitting, to a client device, video frames of a game running on the cloud server (a cloud data center server renders graphical images of a video game and streams them as encoded video frames to the client device over the internet, see [0003], [0025], [0026]);
receiving, from the client device, input information resulting from user interactions associated with the video frames of the running game (user input received in the client device 209 is forwarded back to the server 201 and recorded, see [0031], [0038]); and
transmitting, to the client device, consumption rate information representative of a processing rate at which the cloud server processes the received input information (the consumption rate information is encapsulated in the metadata of the video stream comprising the video frames of the running game, which video stream is transmitted to and received by the client device, see Fig. 3 and [0032]–[0034]; additionally, the server modifies and streams the video frames at a rate determined from the measured processing latency, such that the video frames received by the client device are representative of the processing rate at which the cloud server processes the received input information, see [0032]);
wherein the input information is received at a receiving rate varying according to the processing rate to stabilize a perceived latency at the client device (under the RTP-based closed-loop framework, the transmission rates of the active game session are varied according to the measured processing latency in order to stabilize the perceived latency at the client device, see [0032]).
As per claim 18, Tamasi et al. discloses the consumption rate information indicates at least one of the processing rate at which the received input information is processed by the cloud server, a game frame rate at which the running game is rendered by the cloud server, a server frame rate at which the video frames of the running game are any of encoded and captured by the cloud server, or a filling ratio of an input queue (see [0035]).
As per claim 19, Tamasi et al. discloses the consumption rate information comprises a timestamp indicating occurrence at the cloud server of any of an input event and a frame rendering event (RTP-based data transmissions, see [0032]).
As per claim 22, Tamasi et al. discloses the consumption rate information is transmitted on a regular basis (monitoring performed continuously at periodic intervals for the duration of the gaming session, see [0035]).
As per claim 23, Tamasi et al. discloses the consumption rate information is re-transmitted on a condition that at least one of the processing rate, the game frame rate, the server frame rate, or the filling ratio changes (Once adjusted (either increased or decreased), the next sequence of frames are rendered with the adjusted frame rate, and steps 301 through 307 are repeated, see [0036]).
As per claim 24, Tamasi et al. discloses the consumption rate information is encapsulated in metadata of a video stream comprising the video frames of the running game (see Fig. 3 and [0032] – [0034]).
As per claim 25, Tamasi et al. discloses determining a predicted consumption rate value based on a history of previous consumption rate information, the predicted consumption rate value indicating a predicted processing rate for processing further received input information by the cloud server (a default profile/heuristic that includes values for the render, stream, and/or display frame rates may be created and stored per game, see [0032]).
As per claim 26, Tamasi et al. discloses the transmitted consumption rate information indicates the determined predicted consumption rate value (see [0032]).
As per claim 31, Tamasi et al. discloses a client device (client device 209; see [0026], [0031]) comprising:
a processor configured to:
receive, from a cloud server, video frames of a game running on the cloud server (see [0003], [0025], [0026]);
receive input information from at least one input device of the client device, resulting from user interactions associated with the video frames (see [0026]);
transmit the input information to the cloud server (see [0031], [0038]);
receive consumption rate information associated with the running game, wherein the consumption rate information is representative of a rate at which the cloud server processes the input information (see [0032], [0038]); and a
adjust an input transmission rate at which the input information is transmitted to the cloud server based on the received consumption rate information, wherein the adjustment is performed to stabilize a perceived latency at the client device (a closed-loop rate-control framework in which the constantly-measured latency of the active game session governs the dynamic adjustment of the transmission rates at which data of the active game session is transmitted under RTP in order to reduce and stabilize the perceived latency; when the measured latency is high (above a pre-determined threshold) the rates are dynamically increased/adjusted, and when the measured latency is low (below a second pre-determined threshold) the rates are correspondingly capped, see [0032], [0036]).
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 5 is rejected under 35 U.S.C. 103 as being unpatentable over Tamasi et al. (US Pub. No. 2014/0189091) in view of Yong et al. (US Pub. No. 2016/0261656 A1).
As per claim 5, Tamasi et al. discloses adjusting the input transmission rate at which the received input information is transmitted to the cloud server (see [0032]), but does not expressly disclose that the adjusting comprises synchronizing the input transmission rate to a consumption rate value by setting at least one of (i) a sending rate of the received input information or (ii) a polling rate of the received input information.
Yong et al. teaches a cloud input channel management, wherein the input polling rate is a client-side latency variable in cloud gaming systems (while client devices will attempt to achieve the lowest latency through a variety of methods, inevitably, each client device will experience a different amount of latency due to differences in factors such as the decode speed of transmitted data, render rates, input polling, or even the client's network connection, see [0003]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to have modified the rate monitoring framework of Tamasi et al. with an input polling rate in view of Yong et al. in order to synchronize and monitor each client device’s latency.
Response to Arguments
Applicant's arguments filed on June 12, 2026 have been fully considered but they are not persuasive.
Applicant argues on p. 2 – 4 that Tamasi et al. fails to disclose the “receiving consumption rate information associated with the running game… representative of a rate at which the cloud server processes the input information” limitation of claims 1 and 31 (and the corresponding “transmitting … consumption rate information” limitation of claim 17) because the cited data communication in Tamasi et al. takes place internally within the server between stream component and server control module. The Examiner respectfully disagrees.
As an initial matter, independent claims 1 and 31 do not recite that the consumption rate information is received from the cloud server. Claims 1 and 31 recite only “receiving consumption rate information associated with the running game,” without limitation as to the source of that information.
Consistent with the broadest reasonable interpretation, and as confirmed by dependent claim 2, “receiving consumption rate information comprises determining a consumption rate value at the client device based on receiving and decoding the video frames received from the cloud server.” Tamasi et al. discloses precisely this at [0038]: once the encoded video data received from the server is decoded (step 407) and displayed (step 409) at the client device 209, the length of time since the user input was sent is measured. That measured latency is a consumption rate value determined at the client device, based on decoding the received video frames, that is representative of the rate at which the cloud server processes the input information. The client device therefore obtains (i.e., “receives”) the recited consumption rate information. Applicant’s argument is directed solely to the server-internal RTP measurement pathway of [0032] and does not address, and cannot overcome, the client-side determination expressly disclosed at [0038].
With respect to independent claim 17, which does recite transmitting the consumption rate information to the client device, Tamasi et al. discloses that the consumption rate information is encapsulated in the metadata of the video stream that is streamed to, and received by, the client device. Tamasi et al. further discloses that the video frames are modified and streamed to the client device at a rate determined from the measured processing latency, such that the frames received by the client device are representative of the processing rate at which the server processes the received input. Accordingly, Tamasi et al. discloses transmitting, to the client device, consumption rate information representative of the processing rate, and Applicant’s “internal to the server” argument does not account for the disclosed stream-metadata transmission of the consumption rate information to the client device.
Further, Applicant argues that the parameter adjusted in Tamasi et al. is the server-side “rendering frame rate,” whereas the claims recite adjusting the client device’s “input transmission rate”. The Examiner respectfully disagrees.
Tamasi et al. does not merely adjust an isolated rendering frame rate, a closed-loop, RTP-based rate-control framework in which the latency of the active game session is constantly measured for the data transmissions between the server and the client device, and the transmission rates of that active game session are dynamically adjusted based on the measured latency in order to reduce and stabilize the perceived latency. The claim recites adjusting “an input transmission rate at which the input information is transmitted to the cloud server based on the received consumption rate information … to stabilize a perceived latency at the client device.” Tamasi et al.’s dynamic adjustment of the active-session transmission rates, performed responsive to the constantly-measured latency and for the express purpose of stabilizing perceived latency, reads on the claimed adjustment under the broadest reasonable interpretation. The claim language does not require that the input transmission rate be the only rate adjusted, nor does it exclude the concurrent adjustment of other transmission rates within the same closed-loop framework. Therefore, the rejection above is maintained.
Conclusion
THIS ACTION IS MADE FINAL. 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 ANKIT B DOSHI whose telephone number is (571)270-7863. The examiner can normally be reached Mon - Fri. ~8:30 - ~5:30.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Dmitry Suhol can be reached at 571-272-4430. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ANKIT B DOSHI/Examiner, Art Unit 3715
Prosecution Insights