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 2/12/2026 has been received and considered. In the response, Applicant amended claims 1 and 9. Therefore, claims 1 - 24 are pending.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1 – 15 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
With regards to claim 1 and 9, Applicant has amended the claims to include rendering, “under control of the at least one synchronization signal” and encoding, “under control of the at least one synchronization signal. The original specification does not have limitations anywhere to be found. Additionally, Applicant has provided no paragraph to where they believe support can be found.
All dependent claims inherit the deficiencies of the claim(s) from which they depend and are similarly rejected for the same reason.
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.
Claims 1 – 7, 9 – 14 and 16 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over McAuley et al. (US Pub. No. 2021/0195262 A1) in view of Cerny et al. (US Pub. No. 2021/0093960 A1).
As per claim 1, McAuley et al. discloses a method performed at a server (See Fig. 1:150), comprising: the target frame rate based on a first proposed maximum frame rate received from a client device (see [0048] – [0050]) and further based on one or more current parameters of the server (see [0028], [0029] and [0040]).
McAuley et al. does not expressly disclose generating at least one synchronization signal based on a target frame rate; rendering, under control of the at least one synchronization signal, video frames of a stream of video frames; encoding, under control of the at least one synchronization signal, the rendered video frames of the stream of video frames to generate a stream of encoded video frames; and transmitting the stream of encoded video frames to the client device via at least one network. McAuley et al. teaches that the adjusted target FPS, resolution, and bit rate are used to configure the encoder and the output video stream (see [0035], [0037], [0040], [0046]).
Cerny et al. teaches a server-client cloud gaming pipeline in which a synchronization signal, wherein a VSYNC signal whose frequency corresponds to the target frame rate. The target frame rate is generated and used to govern the timing of rendering, encoding, and transmission operations at the server, as well as to align corresponding operations at the client (see [0005], [0031], [0051] – [0053]). Further, Cerny teaches that proper alignment of frequencies of server and client VSYNC signals and a timing offset between those signals, is configured for the purpose of reducing one-way latency and latency variability between the server and the client. The frequency of the VSYNC signal is dictated and generated based on the target frame rate of the streaming pipeline; the VSYNC signal in turn dictates when rendered frames are produced, when encoded frames are emitted from the encoder buffer (e.g., a first-in-first-out buffer), and when frames are delivered to the client (see Fig. 5 – 6 and [0076] – [0077]). Accordingly, in Cerny the rendering and encoding operations are performed under control of the VSYNC synchronization signal that is itself based on the target frame rate.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to have modified the server of McAuley et al. with a target frame rate from a client-proposed maximum frame rate and current server parameters and configures the encoder accordingly, to additionally generate a VSYNC-type synchronization signal based on that target frame rate and to perform rendering and encoding of the video frames under control of that synchronization signal, as taught by Cerny et al., in order to reduce one-way latency between the cloud gaming server and the client, to reduce latency variability and to thereby improve the smoothness of the video as displayed at the client.
As per claim 2, McAuley et discloses modifying the target frame rate based on a second proposed maximum frame rate received from the client device after receiving the first proposed maximum frame rate; and rendering additional video frames of the stream of video frames based on the modified target frame rate (adjusted based on feedback received from a decoder of a client device so that the server (e.g., computer system) generates frames at a rate that can be handled by the client device, and a target streaming bit rate is adjusted according to network parameter estimates (e.g., available bandwidth) generated based on network and client condition feedback received from the client device, see [0040], [0041], [0046]).
As per claim 3, McAuley et al. discloses modifying the target frame rate based on one or more updated current parameters of the server; and rendering the stream of video frames based on the modified target frame rate (see [0033], [0037], [0040]).
As per claim 4, McAuley et al. discloses the one or more current parameters of the server include at least one of: a network latency between the server and the client device; a network bandwidth between the server and the client device (streaming bandwidth from network and client, see [0032], [0033], [0035]).
As per claim 5, McAuley et al. discloses the target frame rate is based on the first proposed maximum frame rate and the one or more current parameters according to an algorithm (monitoring the frame rate in view of an upper frame rate threshold and a lower frame rate threshold and the frame resolution in view of an upper resolution threshold and a lower resolution threshold, wherein the dynamically adjusting at least one of the frame rate or the frame resolution is based at least in part on the monitoring (see [0033] and [0037] – [0041])
As per claim 6, McAuley et al. discloses the stream of video frames is generated for an instance of a video game application executing at the server on behalf of the client device (game streaming, see [0028] and [0032])
As per claim 7, McAuley et al. discloses transmitting a representation of a status of a vertical synchronization (vsync) feature of the instance of the video game application to the client device via the at least one network (see [0028] and [0031]).
As per claims 9 - 14, the instant claims are a sever in which corresponds to the method of claims 1 – 7. Therefore, it is rejected for the reasons set forth above.
As per claim 16, McAuley et al. in view of Cerny discloses a method performed at a client device (similar to the method of claim 1). Specifically, McAuley discloses that the server's adjustment of streaming parameters, including target frame rate, is made based on information received from the client device, including a proposed maximum frame rate and information regarding current parameters of the client device such as decoder performance and network conditions observed at the client (see [0040], [0041], [0046], [0048] – [0050]). Further, McAuley discloses the client device receiving, from the server, a stream of encoded video frames that have been rendered and encoded at the server in accordance with the target frame rate that is itself based on the client-supplied proposed maximum frame rate (see [0035], [0037], [0040], [0046]); decoding the received stream of encoded video frames to generate decoded video frames (decoder of the client device, see [0048]); and presenting the decoded video frames for display at a display associated with the client device (game streaming for client display, see [0028] and [0032]). Cerny further teaches client-side feedback to the server regarding maximum bandwidth experienced by the client by means of a client-side feedback mechanism used by the server to monitor and tune the encoder (see [0076] – [0077]). Further, claims 17 – 20, the instant claims are a method in which corresponds to the method of claims 1 - 6. Therefore, it is rejected for the reasons set forth above.
Examiner’s Note
Claims 8 and 21 – 24 are allowed, over the prior art on record.
Claim 15 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims and overcome the 35 USC 112 (a) rejection above
Response to Arguments
Applicant's arguments filed 2/12/2026 have been fully considered but they are not persuasive. Applicant argues the amendment of “based on” to “under control of the at least one synchronization signal” does not distinguish over the combination of McAuley and Cerny. The Examiner respectfully disagrees.
Applicant amended claim 1 (and corresponding claim 9) to recite that rendering and encoding are performed "under control of the at least one synchronization signal" instead of "based on" that signal. Under the broadest reasonable interpretation consistent with the specification, the phrase "under control of" requires that the synchronization signal govern or determine the timing of the rendering and encoding operations. The specification does not define "under control of" clearly and Applicant has not pointed to any portion of the specification that imparts a special meaning to that phrase. Cerny expressly teaches operations that are timed and synchronized in accordance with VSYNC signals whose frequency is set in accordance with the target frame rate, which is considered as "under control of" the synchronization signal. The amendment therefore does not distinguish the claims over the combination of McAuley and Cerny.
Applicant argues that McAuley does not disclose generating a synchronization signal based on a target frame rate or rendering and encoding under control of such a signal. The rejection does not rely on McAuley for those features. As expressly set forth above, McAuley is relied on to teach the determination of a target frame rate based on a first proposed maximum frame rate received from a client device and further based on one or more current parameters of the server and to teach that the target frame rate is used to configure encoder behavior and the output video stream. Cerny is relied on to teach generation and use of a VSYNC-type synchronization signal, derived from the target frame rate, that governs the timing of rendering, encoding, and delivery operations. Applicant's argument that McAuley alone does not disclose these features does not address the combination on which the rejection is actually based, and is therefore unpersuasive.
Applicant argues that the VSYNC signals discussed in Cerny are “display-timing or scan-out reference signals used for aligning server and client clocks and overlapping operations, not synchronization signals generated from a target frame rate to govern rendering and encoding cadence”. Examiner respectfully disagrees.
First, a VSYNC signal is a synchronization signal. The term "VSYNC" is an abbreviation of "vertical synchronization" and the function of a VSYNC signal is to synchronize the timing of frame-related operations. Applicant's own claim 7 expressly refers to a “vertical synchronization (vsync) feature,” which treats VSYNC as a species of synchronization signal consistent with the synchronization recited in claim 1.
Second, the frequency of a VSYNC signal in a video pipeline is as a matter of fundamental display and streaming engineering, equal to or derived from the frame rate of the corresponding video stream. A VSYNC signal that occurs at 60 Hz corresponds to a 60 frames-per-second video pipeline. If the target frame rate is adjusted, the VSYNC frequency is correspondingly adjusted. Cerny expressly addresses alignment of the frequencies of server and client VSYNC signals, wherein the alignment that necessarily requires that those frequencies are set in accordance with the target frame rate of the streaming pipeline. The VSYNC signal of Cerny is therefore "based on a target frame rate" within the broadest reasonable interpretation of that phrase.
Third, Cerny teaches that the VSYNC signal is used to control when rendered frames are produced and emitted from the encoder buffer to the network, which is considered as the "under control of" relationship recited in amended claim 1.
Applicant argues that the proposed combination relies on "impermissible hindsight reconstruction using Applicant's disclosure as a blueprint." The combination, however, is supported by the cited references themselves, not from Applicant's specification. Specifically, Cerny expressly identifies the technical problem solved by VSYNC alignment between server and client. Specifically, reduction of one-way latency and latency variability and the resulting improvement in frame timing reliability. McAuley is directed to the same field of endeavor (server-to-client video streaming for cloud gaming) and expressly addresses the related problem of selecting a target frame rate suited to the client and the network conditions. A person of ordinary skill in the art, considering McAuley's target-frame-rate framework and Cerny's VSYNC-alignment technique, would have had ample motivation to combine them in the manner set forth in the rejection, in order to obtain the benefits expressly identified in Cerny.
Further, Applicant's argument that McAuley and Cerny "operate at different stages of the streaming pipeline" and "address different technical problems" is not persuasive. Both references are in the same field (server-to-client cloud video streaming) and both addresses overlapping concerns of frame rate, encoder behavior, and the relationship between server-side timing and client-side display. The combination is therefore proper.
Applicant argues that claim 16 is directed to a client-side method with features distinct from claim 1 and that the prior Office Action's rejection of claim 16 “by mere reference to the rejection of claim 1” is procedurally improper and substantively deficient. Examiner respectfully disagrees with the substantive challenge, and the present Office Action sets forth an analysis of claim 16 in the rejection section above. To the extent Applicant's argument is that the prior treatment of claim 16 was insufficiently detailed, Examiner has expanded the analysis of claim 16 in this Office Action.
With respect to the substantive content of claim 16, McAuley discloses that the server's determination of the target frame rate is made based on a proposed maximum frame rate received from the client device and based on current parameters of the client device, including decoder queue fullness, decoder performance, and network conditions observed at the client. For the server to receive such a proposed maximum frame rate and such client-side parameter information, the client device necessarily transmits that information to the server. McAuley's server-side disclosure of receipt of a client-proposed maximum frame rate inherently imply the corresponding client-side act of transmission. The features of claim 16 directed to the client transmitting a proposed maximum frame rate to the server, receiving in return an encoded video stream rendered at a target frame rate based on that proposed maximum frame rate, decoding, and presenting are therefore taught by the same disclosure of McAuley that supports the server-side method of claim 1, considered from the perspective of the client device.
Cerny further teaches the corresponding client-side acts of receiving and decoding encoded video frames produced under control of a VSYNC-based synchronization arrangement coordinated between server and client. The combination of McAuley and Cerny therefore teaches each limitation of claim 16, and the rejection of claim 16 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