DETAILED ACTION
Status of Claims:
Claims 1 – 21 are pending.
Claims 1, 8, and 15 are amended. This rejection is FINAL.
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 .
Response to Arguments
Applicant s arguments in the amendments, filed 06/18/2026, have been fully considered and are persuasive. The prior rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection has been made based on the amendments.
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1 – 21 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Brailovskiy (US 11343551).
As per claim 1, a method for full sender-side rate control, comprising:
receiving a data stream at a forwarding unit (The server 224 (forwarding unit, Col.31, Line 60 – Col. 32, Line 19) receives streams from connected devices, See Col. 35, Line 65 – Col. 36, Line 10);
determining a bandwidth estimation for communicating the data stream between the forwarding unit and a sender of the data stream (Using the bandwidth value calculation process 514, the server 224 can calculate an estimated bandwidth between itself and the A/V device 210 (sender) streaming audio and/or video data, See Col. 36, Lines 35 - 48);
determining respective bandwidth estimations for communicating the data stream between the forwarding unit and at least two receivers using the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59);
aggregating the bandwidth estimations determined for communicating the data stream between the forwarding unit and the at least two receivers (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17); and
limiting the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream based on the aggregated bandwidth estimations (The server 224 transmits the message to the transmitting device to adapt the stream quality. For example, using the communication module 502, the server 224 can transmit the REMB message including both bandwidth value 430 and the confidence value 432 to the A/V device 210 for use in determining resolutions of the streams in the streaming session, See Col. 37, Lines 8 - 18).
As per claim 2, the method of claim 1, wherein the bandwidth estimation for communicating the data stream between the forwarding unit and the sender of the data stream is determined using Real-Time Transport Protocol (RTP) data received from the sender of the data stream (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 3, the method of claim 1, wherein the respective bandwidth estimations for communicating the data stream between the forwarding unit and the at least two receivers are determined using Real-Time Transport Protocol (RTP) data received from the at least two receivers (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 4, the method of claim 3, wherein the respective bandwidth estimations for communicating the data stream between the forwarding unit and at least two receivers are determined by further using information regarding the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59).
As per claim 5, the method of claim 1, wherein the bandwidth estimations determined for communicating the data stream between the forwarding unit and the at least two receivers are aggregated using an aggregating algorithm, which selects a minimum of the aggregated bandwidth estimations (The A/V device 102 can use the bandwidth estimate and confidence value to select a quality of the streams to be generated by the A/V device 102 for transmission to the backend computing system 108. The backend computing system 108 can receive the streams generated by the A/V device 102 and select one of the received streams for transmission to the one or more client devices 114 for display. For example, if the backend computing system 108 determines that a connection with the client device 114 is poor (e.g., slow), then the backend computing system 108 will relay the low-resolution stream, See Col. 5, Lines 21 - 41).
As per claim 6, the method of claim 5, wherein the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream is limited by the minimum of the aggregated bandwidth estimations (In some embodiments, the backend computing system 108 may receive or otherwise obtain bandwidth data 110 and confidence data 112, to be used in accordance with the present disclosure. The bandwidth data 110 can include any combination of data that can be used to determine an estimated amount of available bandwidth between two devices, such as, for example, between the backend computing system 108 and the A/V device 102, See Col. 4, Line 52 – Col. 5, Line 14).
As per claim 7, the method of claim 1, wherein the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream is limited by communicating a limitation message to the sender (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17).
As per claim 8, an apparatus for full sender-side rate control, comprising:
a publisher peer connection module configured to:
receive a data stream (The server 224 (forwarding unit, Col.31, Line 60 – Col. 32, Line 19) receives streams from connected devices, See Col. 35, Line 65 – Col. 36, Line 10); and
determine a bandwidth estimation for communicating the data stream between the publisher peer connection module and a sender of the data stream (Using the bandwidth value calculation process 514, the server 224 can calculate an estimated bandwidth between itself and the A/V device 210 (sender) streaming audio and/or video data, See Col. 36, Lines 35 - 48);
at least two subscriber peer connection modules, each of the at least two subscriber peer connection modules configure to:
determine a respective bandwidth estimation for communicating the data stream between the forwarding unit and at least one of two receivers using the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59); and
an aggregator module configured to:
aggregate the bandwidth estimations determined for communicating the data stream between the at least two subscriber peer connection modules and the at least two receivers (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17); and
communicate information regarding the aggregated bandwidth estimations to the sender to limit the bandwidth estimation determined for communicating the data stream between the publisher peer connection module and the sender of the data stream (The server 224 transmits the message to the transmitting device to adapt the stream quality. For example, using the communication module 502, the server 224 can transmit the REMB message including both bandwidth value 430 and the confidence value 432 to the A/V device 210 for use in determining resolutions of the streams in the streaming session, See Col. 37, Lines 8 - 18).
As per claim 9, the apparatus of claim 8, wherein the bandwidth estimation for communicating the data stream between the publisher peer connection module and the sender of the data stream is determined using Real-Time Transport Protocol (RTP) data received by the publisher peer connection module from the sender of the data stream (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 10, the apparatus of claim 8, wherein the respective bandwidth estimations for communicating the data stream between the forwarding unit and the at least two receivers are determined using Real-Time Transport Protocol (RTP) data received by respective ones of the at least two subscriber peer connection modules from the at least two receivers (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 11, the apparatus of claim 10, wherein the respective bandwidth estimations for communicating the data stream between the at least two subscriber peer connection modules and at least two receivers are determined by respective ones of the at least two subscriber peer connection modules by further using information regarding the bandwidth estimation determined for communicating the data stream between the publisher peer connection module and the sender (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59).
As per claim 12, the apparatus of claim 8, wherein the bandwidth estimations determined by the at least two subscriber peer connection modules for communicating the data stream between the forwarding unit and the at least two receivers are aggregated using an aggregating algorithm, which selects a minimum of the aggregated bandwidth estimations (The A/V device 102 can use the bandwidth estimate and confidence value to select a quality of the streams to be generated by the A/V device 102 for transmission to the backend computing system 108. The backend computing system 108 can receive the streams generated by the A/V device 102 and select one of the received streams for transmission to the one or more client devices 114 for display. For example, if the backend computing system 108 determines that a connection with the client device 114 is poor (e.g., slow), then the backend computing system 108 will relay the low-resolution stream, See Col. 5, Lines 21 - 41).
As per claim 13, the apparatus of claim 12, wherein the bandwidth estimation determined for communicating the data stream between the publisher peer connection module and the sender of the data stream is limited by the minimum of the aggregated bandwidth estimations (In some embodiments, the backend computing system 108 may receive or otherwise obtain bandwidth data 110 and confidence data 112, to be used in accordance with the present disclosure. The bandwidth data 110 can include any combination of data that can be used to determine an estimated amount of available bandwidth between two devices, such as, for example, between the backend computing system 108 and the A/V device 102, See Col. 4, Line 52 – Col. 5, Line 14).
As per claim 14, the apparatus of claim 8, wherein the bandwidth estimation determined for communicating the data stream between the publisher peer connection module and the sender of the data stream is limited by communicating a limitation message to the sender (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17).
As per claim 15, an apparatus for full sender-side rate control, comprising:
a processor; and
a memory coupled to the processor, the memory having stored therein at least one of programs or instructions executable by the processor to configure the apparatus to:
receive a data stream at the apparatus (The server 224 (forwarding unit, Col.31, Line 60 – Col. 32, Line 19) receives streams from connected devices, See Col. 35, Line 65 – Col. 36, Line 10);
determine a bandwidth estimation for communicating the data stream between the apparatus and a sender of the data stream (Using the bandwidth value calculation process 514, the server 224 can calculate an estimated bandwidth between itself and the A/V device 210 (sender) streaming audio and/or video data, See Col. 36, Lines 35 - 48);
determine respective bandwidth estimations for communicating the data stream between the apparatus and at least two receivers using the bandwidth estimation determined for communicating the data stream between the forwarding unit and the sender of the data stream (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59);
aggregate the bandwidth estimations determined for communicating the data stream between the apparatus and the at least two receivers (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17); and
limit the bandwidth estimation determined for communicating the data stream between the apparatus and the sender of the data stream based on the aggregated bandwidth estimations (The server 224 transmits the message to the transmitting device to adapt the stream quality. For example, using the communication module 502, the server 224 can transmit the REMB message including both bandwidth value 430 and the confidence value 432 to the A/V device 210 for use in determining resolutions of the streams in the streaming session, See Col. 37, Lines 8 - 18).
As per claim 16, the apparatus of claim 15, wherein the bandwidth estimation for communicating the data stream between the apparatus and the sender of the data stream is determined using Real-Time Transport Protocol (RTP) data received from the sender of the data stream (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 17, the apparatus of claim 15, wherein the respective bandwidth estimations for communicating the data stream between the apparatus and the at least two receivers are determined using Real-Time Transport Protocol (RTP) data received from the at least two receivers (In some embodiments, the connection monitoring process 512 can process RTP data in the form of an RTP dump. For example, the RTP dump can include buffered statistics for the active streaming sessions, such as, for example, packet delay, jitter, number of retries (to send packets), packet losses, etc., that can be used to estimate an available bandwidth, See Col. 28, Lines 35 - 45).
As per claim 18, the apparatus of claim 17, wherein the respective bandwidth estimations for communicating the data stream between the apparatus and at least two receivers are determined by further using information regarding the bandwidth estimation determined for communicating the data stream between the apparatus and the sender (For example, using the communication module 504, the server 224 can relay/retransmit the streams from the A/V device 210 to one or more client devices 214, 216, See Col. 36, Lines 35 - 48 … In some embodiments, based on the protocol being used and the bandwidth data 110 gathered by the connection monitoring process 512, the processor 502 can use a bandwidth value calculation process 514 to calculate the bandwidth value 430, such as an estimated available bandwidth for a particular connection between the server 224 and another device. For example, the processor 502 can use the bandwidth value calculation process 514 to determine the bandwidth value 430 for an available bandwidth or bitrate while the server 224 receives a real-time stream from the A/V device 210, See Col. 28, Lines 46 - 59).
As per claim 19, the apparatus of claim 15, wherein the bandwidth estimations determined for communicating the data stream between the apparatus and the at least two receivers are aggregated using an aggregating algorithm, which selects a minimum of the aggregated bandwidth estimations (The A/V device 102 can use the bandwidth estimate and confidence value to select a quality of the streams to be generated by the A/V device 102 for transmission to the backend computing system 108. The backend computing system 108 can receive the streams generated by the A/V device 102 and select one of the received streams for transmission to the one or more client devices 114 for display. For example, if the backend computing system 108 determines that a connection with the client device 114 is poor (e.g., slow), then the backend computing system 108 will relay the low-resolution stream, See Col. 5, Lines 21 - 41).
As per claim 20, the apparatus of claim 19, wherein the bandwidth estimation determined for communicating the data stream between the apparatus and the sender of the data stream is limited by the minimum of the aggregated bandwidth estimations (In some embodiments, the backend computing system 108 may receive or otherwise obtain bandwidth data 110 and confidence data 112, to be used in accordance with the present disclosure. The bandwidth data 110 can include any combination of data that can be used to determine an estimated amount of available bandwidth between two devices, such as, for example, between the backend computing system 108 and the A/V device 102, See Col. 4, Line 52 – Col. 5, Line 14).
As per claim 21, the apparatus of claim 15, wherein the bandwidth estimation determined for communicating the data stream between the apparatus and the sender of the data stream is limited by communicating a limitation message to the sender (The A/V device 210 can receive an REMB message 1202, from the server 224, containing field 1208 including the bandwidth value 430 and the confidence value 432 through the real-time communication protocol, for example, as part of the WebRTC stack. The bandwidth value 430 can represent a bandwidth estimation of a total available bandwidth or bitrate that exists between the A/V device 210 and the device receiving the streams, See Col. 34, Line 57 – Col. 35, Line 17).
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 NAZIA NAOREEN whose telephone number is (571) 270-7282. The examiner can normally be reached M-F: 9:00 - 6:00.
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, Umar Cheema can be reached at 571-270-3037. 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.
/NAZIA NAOREEN/Primary Examiner, Art Unit 2458
Prosecution Insights