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 12/17/2025 has been received and considered. In the response, Applicant elected Group I, claim 1 – 4, 6- 12 and 21 – 29, therefore claim 13 was withdrawn from consideration. Further claims 5, 11, 14 – 20 were previously canceled and claim 30 was added. Therefore, claims 1 – 4, 6 – 12 and 21 – 30 will be reviewed in this office action.
Claim Objections
Applicant is advised that should claim 22 be found allowable, claim 30 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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, 6, 7, 12, 21, 22, 26, 27 and 30 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrov (US Pub. No. 2019/0164518 A1) in view of Apte (US Pub. No. 2014/0281017 A1).
As per claim 1, Dimitrov discloses a method implemented in a client device and comprising: receiving a first plurality of packets from a server, the first plurality of packets carrying video frames of video content (a server device provides services to one or more client devices such as client device. The services provided by server device includes the running of an application which renders frames that are transmitted over a network or communication connection to client device, and video (and optionally audio) based on information from the frames is displayed on display device of the client device, see [0037]); applying a first latency value to the first plurality of packets before decoding and displaying (the client maintains a dynamic jitter buffer that determines how long frames spend in the buffer before display, the system maintains a dynamic jitter buffer, characterized by the jitter absorption parameter (JAP) which defines how long frames spend in the jitter buffer on average, [0047], further the JAP corresponds to the recited "first latency value”, it is the amount of time packets dwell in the receiver buffer before decoding and display. The frames in the jitter buffer are already decoded and ready for scan-out and that arrival times include the time consumed for decoding the respective image frames, confirming that the JAP/latency value applies before display, see Fig. 2A: 208 and [0081]); sending a request message to the server, the request message comprising first information indicating a requested latency value determined based on a frame pace variation (the client measures variations in frame arrival timing, i.e., frame pace variation, and transmits that information to the server. "The client device performs monitoring of incoming image frame arrivals. The JAP, which controls the jitter buffer, may be configured based on the monitoring, see [0047], during game or other application execution, frame arrival feedback generated by frame arrival monitoring is transmitted from client device to server device, see [0050]); receiving a response message from the server, the response message comprising second information indicating a latency value (in response to the client's feedback, the server adjusts the rate at which it provides image frames: "A feedback adaptive frame rate controller at the server device may operate to receive feedback from client device, and based on factors including the received feedback, to adjust frame timer in order to control the render frame rate of video game, see [0046], the server’s adjusted frame rate which corresponds to the new latency value is then implemented in the subsequent transmission to the client); and applying the latency value to a second plurality of packets before decoding and displaying, the second plurality of packets being received subsequent to the first plurality of packets (the client adapts the jitter buffer in accordance with the new JAP value, applying the new latency to subsequently arriving frames, "the at least one processor is also configured to transmit information regarding the measured differences to the remote server, adapt a size of a jitter buffer in the memory in accordance with at least the measured differences, insert said data frames in the adapted jitter buffer, and display images on the display device based on said data frames inserted in the adapted jitter buffer”, [0017], "if the client determines that the JAP is to be increased, the render server is notified and the render server starts rendering faster. The frames then start arriving at the client device 104 at a faster rate than they are displayed, slowly filling the jitter buffer to a desirable amount”, see [0049]).
However, Dimitrov does not expressly disclose a server to client response message containing a “second latency value”. Apte teaches a cloud gaming QoS architecture in which the client transmits one-way-delay and packet-loss statistics to the server, and the server then "transmits a command over network to client to enable dynamic jitter buffering" along with associated QoS settings (see Fig.5 and [0047]). The server to client command includes specific buffer size parameter, such as “a maximum jitter buffer size and a minimum jitter buffering parameter for mitigating buffer under-runs”, (see [0042]). The server confirmed buffer size parameters are considered as “second information indicating a second latency value” sent in a response message from the server to the client.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to combine the dynamic Jitter Absorption Parameter based feedback architecture of Dimitrov with the explicit sever to client command/response messaging of Apte in order to manage the dynamic jitter buffering at a streaming client based on bidirectional client-server signaling for cloud gaming.
As per claim 6, Dimitrov discloses the requested latency value is based on any of a number of delayed frames and a number of dropped frames (eliminate or reduce latency, stutter and frame tearing, while simultaneously eliminating dropped frames or at least limiting dropped frames to a predefined threshold, see [0036], [0047]).
As per claim 7, Dimitrov does not expressly discloses the second latency value is applied to the second plurality of packets based on the second latency value being equal to the requested latency value or comprising a value between the requested latency value and the first latency value.
Apte teaches a jitter buffer system for jitter buffering, wherein server-determined buffer size parameters bounded by both a minimum and a maximum (the various QoS settings indicate whether dynamic jitter buffering is enabled or disabled, along with the jitter threshold, the jitter wait time, the no-jitter wait time, and a maximum jitter buffer size and a minimum jitter buffering parameter (see Fig. 3:318 and [0042]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to implement the server response to be either equal to the requested latency value or an intermediate value of Apte to the dynamic latency system of Dimitrov as it would allow the latency system to have an efficient minimum or maximum buffer-size constraint.
As per claim 21, Dimitrov discloses the first latency value, the requested latency value and the second latency value are respectively a first buffer latency value, a requested buffer latency value and a second buffer latency value (see [0047]).
As per claims 12, 22, 26, 27 and 30, the instant claim is a client device in which corresponds to the method of claims 1, 6, 7 and 21. Therefore, it is rejected for the reasons set forth above.
Claims 8 – 10, 28 and 29 are rejected under 35 U.S.C. 103 as being unpatentable over Dimitrov (US Pub. No. 2019/0164518 A1) in view of Apte (US Pub. No. 2014/0281017 A1) as applied to claims 1 and 12 above, and further in view of Kafle et al. (US Pub. No. 2015/0172757 A1).
As per claims 8 – 10, Dimitrov in view of Apte teaches the dynamic latency adjustment method but does not expressly discloses before the first plurality of packets are received, a handshake request message is sent and received by the client device to the server, and wherein the handshake request message comprises third information indicating a client capability to support dynamic latency operation; a handshake response message is received by the client device from the server in response to the handshake request message, and wherein the client device performs dynamic latency operation by sending the request message on a condition that the handshake response message comprises fourth information indicating a server capability to support dynamic latency operation.
Kafle et al. teaches a source-device-centric RTSP-based capability negotiation method in which the source device receives capability information from each sink device before streaming commences. RTSP request/response message exchanges between source and sink devices to communicate capability information before streaming begins (see Fig. 6A – 9B and [0059] – [0077]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date to incorporate pre-streaming capability handshake of Kafle et al. into the dynamic latency system of Dimitrov in view of Apte purpose of enabling each endpoint to determine whether the other supports the dynamic latency feature before attempting to use it. Further, without such a handshake, a client that sends frame arrival feedback to a server that does not support dynamic latency operation would receive no meaningful response, resulting in degraded operation.
Examiner’s Note
Claims 2 – 4 and 23 – 25 are 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.
The closest applicable prior art, Dimitrov (US 2019/0164518), is interpreted as teach a dynamic jitter and latency-tolerant rendering, wherein a server executing an application and generating image frames associated with the application at a frame rate, and a client which displays the image frames on a display that has a predetermined refresh rate and which monitors arrival times of the image frames in relation to the predetermined refresh rate. The server is further configured to dynamically change the frame rate based on the monitoring so that the frame rate more closely corresponds to the predetermined refresh rate of the client's display.
The closest applicable prior art, Apte (US Pub. No. 2014/0281017), is interpreted as teach a jitter buffering system, wherein a QoS statistic is a one-way delay, i.e., when a packet is ready to transmit, the server writes the transmit timestamp in the packet header. When the packet is received by the client, the receipt timestamp is noted.
The closest applicable prior art, Kuhn (US Pub. No. 2015/0067186), is interpreted as teaching a dynamic and automatic control of latency buffering for audio/video streaming, wherein the dynamic control of latency or jitter buffer size at the sink device for audio and/or video streaming over an error-prone channel. The sink buffer size may be dynamically controlled by the source device based on a type of application for a media stream being transmitted from the source device to the sink device for presentation.
However, Dimitrov, Apte and Kuhn does not expressly teach or disclose the first latency value and the second latency value are applied to the first plurality of packets and the second plurality of packets, respectively, by extracting the first plurality of packets and the second plurality of packets from a receiver buffer based on (i) the first latency value and the second latency value, respectively, and (ii) time stamp information included in the first plurality of packets and the second plurality of packets, wherein the time stamp information indicates respective times associated with a storage of the first plurality of packets and the second plurality of packets in a sender buffer of the server.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Tran (US Pub. No. 2002/0194609) teaches a video client with dynamically allocable video buffer for efficiently streaming video.
Perlman et al. (US Patent No. 8,964,830) teaches a system for multi-stream video compression using multiple encoding formats.
Perlman et al. (US Patent No. 9,314,691) teaches a system for compressing video frames or portions based on feedback information from a client device.
Perry et al. (US Pub. No. 2021/0346799) teaches qualified video delivery methods, wherein a video server is configured to provide streaming video to players of computer games over a computing network. The video server can provide video of different games to different players simultaneously. This is accomplished by rendering several video streams in parallel using a single GPU. The output of the GPU is provided to graphics processing pipelines that are each associated with a specific client/player and are dynamically allocated
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