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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 4/25/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 10 recites the limitation “a TCP protocol and a UDP protocol.” The acronyms need to be spelled out.
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, 2, 6, 10 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over Einarsson et al. (US 2010/0121974), hereinafter Einarsson in view of O’Callaghan et al. (US 2015/0180924), hereinafter O’Callaghan.
As for claim 1, Einarsson teaches a method for controlling real time video streaming (paragraph [0028] describes techniques of managing real time protocol (RTP) packets by adapting bitrate of a stream’s RTP packets), the method comprising:
providing a dataset structure for transmission of video data (Fig. 3; paragraph [0028] describes a server receives/takes a streaming data (i.e. RTP packet) that is encoded by an encoder), wherein a dataset generated according to the dataset structure in a first configuration comprises encoded video data with a first encoding bitrate and padding data (paragraph [0028] describes the server takes a streaming data encoded at a particular bitrate by an encoder and stuffs the TRP packets with dummy data);
generating first datasets according to the dataset structure in the first configuration (paragraph [0028] describes the server stuffs the RPT packets with dummy data as stuffed RTP packets), and transmitting the first datasets as a data stream via a communication channel (paragraph [0028] describes the stuffed RTP packets are transmitted over the network to a receiver);
during the transmission of the first datasets, receiving a first metric indicating a network condition of the communication channel (Fig. 3; paragraphs [0026] and [0028] describe the stuffed RTP packets are transmitted over the network to a mobile equipment. After receiving a RTCP feedback message, the server monitors the round-trip delay, estimated throughput, loss fraction, and other parameters to determine whether the network is unable to sustain this data rate. Such an indication could be a rapidly increasing round trip delay (RTD). These monitored network conditions are interpreted as indications of a network condition);
adjusting the dataset structure to a second configuration (paragraph [0028] describes after receiving the RTCP feedback message, the server monitors the network metrics (i.e. a rapid increase of RTD) to determine whether the network is unable to sustain the current data rate. Such an indication could be a rapidly increasing RTD. The probing is then aborted and the streaming server then enters the recovery state by reverting back to the previous lower bitrate), wherein a dataset generated according to the adjusted dataset structure comprises encoded video data with a second encoding bitrate and padding data (Fig. 2; paragraph [0028] describes the stuffed packets include the streaming data is encoded with a specific bitrate and dummy data), wherein the second encoding bitrate is lower than the first encoding bitrate (paragraph [0028] describes the server enters the recovery state by reverting back to the previous lower bitrate); and
generating second datasets according to the dataset structure in the second configuration and transmitting the second datasets as a data stream via the communication channel (paragraph [0028] and claim 12 describe the higher bitrate is not compatible with the available bandwidth, the server revert back to transmitting a packet with the lower bitrate for streaming the multimedia data).
Einarsson fails to teach
wherein a network condition is a level of network congestion;
determining from a received first metric that a level of network congestion has increased above a threshold.
O’Callaghan discloses
wherein a network condition is a level of network congestion (paragraph [0045] describes congestion information includes information that indicates a congestion level of a network);
determining from a received first metric that a level of network congestion has increased above a threshold (paragraphs [0044]-[0045] describe congestion information (i.e. resource load, a latency associated with the network, a packet loss or packet loss rate et.,) are used to determine the level of traffic congestion).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of O’Callaghan for detecting network traffic characteristics. The teachings of O’Callaghan, when implemented in the Einarsson system, will allow one of ordinary skill in the art to determine level of congestion in a network. One of ordinary skill in the art would be motivated to utilize the teachings of O’Callaghan in the Einarsson system in order to deliver segment of data stream at an adjusted bitrate based on the ability of the network.
As for claim 2, Einarsson teaches in response to determining that a network condition event has changed (paragraphs [0026] and [0028] describe the server receives the RTP feedback and monitors the network metrics with indication of the network conditions, the server performs action):
adjusting the dataset structure to a third configuration, wherein a dataset generated according to the dataset structure in the third configuration comprises encoded video data with the second encoding bitrate and no padding data (Einarsson: paragraph [0008] and claim 12 discloses a probing is conducted by modifying the media streams that include the padding data. The padded dummy data in the media stream utilizes the standard reporting mechanism for determining the transport network’s capability. In response to a determination that the packet with higher bitrate is compatible with the available bandwidth associated with the packet communication link, transmitting a second packet with that higher bitrate, the second packet includes contents of multimedia data and without including any dummy data);
generating third datasets according to the dataset structure in the third configuration, and transmitting the third datasets as a data stream via the communication channel (Einarsson: paragraph [0008] describes the streaming server stops sending dummy data and instead starts sending actual content);
during the transmission of third datasets, receiving a second metric indicating network condition of a communication channel and determining from the received second metric indicating a network condition event (Einarsson: paragraphs [0029]-[0030] describe the server starts probing state where it tries to increase the transmission rate (i.e. higher bitrate). The server then enters an upswitch evaluation state to determine whether the network is capable of handling the higher bandwidth. During this state, round-trip delay, estimated throughput, loss fraction and other network performance and quality related parameters are evaluated to ensure that an acceptable quality is maintained for a certain period of time. If the evaluation period has passed and the transport appears sustainable, the server then reverts back to the normal state, the probing, increasing and evaluation steps are repeatedly performed. If, on the other hand, the RTP feedback indicates that the probing should be aborted, the streaming server then enters the recovery state where the probing, increasing, and evaluation steps are repeatedly performed); and
adjusting the dataset structure to the second configuration (Fig. 5; paragraph [0030] describes the streaming server reverts back to the normal state which is interpreted as second configuration after the initial state).
Einarsson fails to teach
a network condition has changed includes a level of network congestion has increased above a threshold;
a network congestion level is a network condition and the level of network congestion has decreased below the threshold is a network condition event.
O’Callaghan discloses
a network condition has changed includes a level of network congestion has increased above a threshold (paragraphs [0044] and [0047] describe a congestion information indicates that the network congestion level has risen above a threshold, a prediction is made that predicts that a client device will begin requesting lower bitrate segments and lower bitrate segments from a content server is obtained);
a network congestion level is a network condition (paragraphs [0044]-[0045] describe a process of detecting a network congestion level by monitoring a network to determine congestion information which indicates a congestion level), and the level of network congestion has decreased below the threshold is a network condition event (paragraphs [0044]-[0047] describe a network monitoring device transmits congestion information indicating that the network congestion level has satisfied a threshold (e.g., has risen above a threshold, has dropped below a threshold, is equal to a threshold, etc.. when the network becomes less congested (e.g., when the congestion level is less than a threshold, higher bitrate segments of content are proactively obtained from a content server),
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of O’Callaghan for detecting network traffic characteristics. The teachings of O’Callaghan, when implemented in the Einarsson system, will allow one of ordinary skill in the art to determine level of congestion in a network. One of ordinary skill in the art would be motivated to utilize the teachings of O’Callaghan in the Einarsson system in order to deliver segment of data stream at an adjusted bitrate based on the ability of the network.
As for claim 6, the combined system of Einarsson and O’Callaghan teaches wherein the dataset structure defines that the encoded video data is positioned before the padding data in a dataset generated according to the dataset structure (Einarsson: Fig. 2; paragraph [0027] describes a RTP packet that is stuffed with dummy data. The picture shows the data payload is positioned before the dummy data).
As for claim 10, the combined system of Einarsson and O’Callaghan teach wherein the datasets are transmitted over the communication channel using at least one of a TCP protocol and a UDP protocol (O’Callaghan: paragraph [0045] describes TCP protocol uses by devices connected to the network).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of O’Callaghan for applying TCP. The teachings of O’Callaghan, when implemented in the Einarsson system, will allow one of ordinary skill in the art to determine level of congestion in a network. One of ordinary skill in the art would be motivated to utilize the teachings of O’Callaghan in the Einarsson system in order to ensure that lost packets are resent in to determine the level of network congestion.
As for claim 12, the combined system of Einarsson and O’Callaghan teaches wherein the metric indicating a level of network congestion of the communication channel defines one of: packet loss rate (O’Callaghan: paragraphs [0044]-[0045] describe congestion information indicates that the network congestion level and congestion information includes a packet loss rate), jitter, transmission buffer occupancy, a number or frequency of explicit congestion notifications, or latency (O’Callaghan: paragraph [0045] describes a latency).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of O’Callaghan for detecting network traffic characteristics. The teachings of O’Callaghan, when implemented in the Einarsson system, will allow one of ordinary skill in the art to determine level of congestion in a network. One of ordinary skill in the art would be motivated to utilize the teachings of O’Callaghan in the Einarsson system in order to deliver segment of data stream at an adjusted bitrate based on the ability of the network.
As for claim 13, the combined system of Einarsson and O’Callaghan teaches a non-transitory computer-readable storage medium having stored thereon instructions for implementing the method according to claim 1 when executed on a camera having processing capabilities (Einarsson: Fig.1; Video Source 50; paragraph [0033] describes a streaming server includes a video source connected to an encoder; O’Callaghan: paragraphs [0023] and [0027] describe a processor executing software instructions included in a computer-readable medium, such as a memory). Claim 13 recites the method of claim 1, therefore, the supporting rational of the rejection of claim 1 applies equally as well to claim 13.
As for claim 14, Einarsson teaches a device for controlling real time video streaming (Fig. 8; paragraph [0033] describes a streaming server including a bandwidth adaptor for evaluating and deciding on the appropriate bitrates for streaming data. The streaming server includes a video source (e.g. a camera) connected to an encoder which is communicably coupled to a RTP transmitter which transmits RTP messages carrying streaming data encoded at a particular bitrate over a packet based communication network), the device configured for:
providing a dataset structure for transmission of video data (Fig. 3; paragraph [0028] describes a server receives/takes a streaming data (i.e. RTP packet) that is encoded by an encoder), wherein a dataset generated according to the dataset structure in a first configuration comprises encoded video data with a first encoding bitrate and padding data (paragraph [0028] describes the server takes a streaming data encoded at a particular bitrate by an encoder and stuffs the TRP packets with dummy data);
generating first datasets according to the dataset structure in the first configuration (paragraph [0028] describes the server stuffs the RPT packets with dummy data as stuffed RTP packets), and transmitting the first datasets as a data stream via a communication channel (paragraph [0028] describes the stuffed RTP packets are transmitted over the network to a receiver);
during the transmission of the first datasets, receiving a first metric indicating a network condition of the communication channel (Fig. 3; paragraphs [0026] and [0028] describe the stuffed RTP packets are transmitted over the network to a mobile equipment. After receiving a RTCP feedback message, the server monitors the round-trip delay, estimated throughput, loss fraction, and other parameters to determine whether the network is unable to sustain this data rate. Such an indication could be a rapidly increasing round trip delay (RTD). These monitored network conditions are interpreted as indications of a network condition);
adjusting the dataset structure to a second configuration (paragraph [0028] describes after receiving the RTCP feedback message, the server monitors the network metrics (i.e. a rapid increase of RTD) to determine whether the network is unable to sustain the current data rate. Such an indication could be a rapidly increasing RTD. The probing is then aborted and the streaming server then enters the recovery state by reverting back to the previous lower bitrate), wherein a dataset generated according to the adjusted dataset structure comprises encoded video data with a second encoding bitrate and padding data (Fig. 2; paragraph [0028] describes the stuffed packets include the streaming data is encoded with a specific bitrate and dummy data), wherein the second encoding bitrate is lower than the first encoding bitrate (paragraph [0028] describes the server enters the recovery state by reverting back to the previous lower bitrate); and
generating second datasets according to the dataset structure in the second configuration and transmitting the second datasets as a data stream via the communication channel (paragraph [0028] and claim 12 describe the higher bitrate is not compatible with the available bandwidth, the server revert back to transmitting a packet with the lower bitrate for streaming the multimedia data).
Einarsson fails to teach
wherein a network condition is a level of network congestion;
determining from a received first metric that a level of network congestion has increased above a threshold.
O’Callaghan discloses
wherein a network condition is a level of network congestion (paragraph [0045] describes congestion information includes information that indicates a congestion level of a network);
determining from a received first metric that a level of network congestion has increased above a threshold (paragraphs [0044]-[0045] describe congestion information (i.e. resource load, a latency associated with the network, a packet loss or packet loss rate et.,) are used to determine the level of traffic congestion).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of O’Callaghan for detecting network traffic characteristics. The teachings of O’Callaghan, when implemented in the Einarsson system, will allow one of ordinary skill in the art to determine level of congestion in a network. One of ordinary skill in the art would be motivated to utilize the teachings of O’Callaghan in the Einarsson system in order to deliver segment of data stream at an adjusted bitrate based on the ability of the network.
As for claim 15, the combined system of Einarsson and O’Callaghan teaches the device is implemented in a camera capturing the video data (Einarsson: Fig. 3; paragraph [0033] describes the streaming server includes a video source (e.g. a camera) connected to an encoder .
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Einarsson (US 2010/0121974) in view of O’Callaghan (US 2015/0180924) further in view of Alvarez-Cortes et al. (US 2025/0159034), hereinafter Alvarez-Cortes.
As for claim 7, the combined system of Einarsson and O’Callaghan fails to teach determining a size of the padding data using at least one of:
transmission technology of the communication channel;
a size of the encoded video data;
a measurement indicating a variance of available bandwidth of the communication channel;
a measured roundtrip time, RTT, of a signal transmitted on the communication channel; or
a user input indicating an importance of the video data.
Alvarez-Cortes discloses
teach determining a size of the padding data using at least one of:
transmission technology of the communication channel;
a size of the encoded video data;
a measurement indicating a variance of available bandwidth of the communication channel (paragraph [0067] describes bandwidth data is communicated to a padding adder module which takes into consideration the bandwidth estimation determined by a receiver bandwidth estimator when computing an amount of padding to inject into a media stream);
a measured roundtrip time, RTT, of a signal transmitted on the communication channel; or
a user input indicating an importance of the video data.
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Alvarez-Cortes for computing an amount of padding data. The teachings of Alvarez-Cortes, when implemented in the Einarsson and O’Callaghan system, will allow one of ordinary skill in the art to adjust bitrate for a data stream. One of ordinary skill in the art would be motivated to utilize the teachings of Alvarez-Cortes in the Einarsson and O’Callaghan system in order to enable rate-control to operate effectively and ramp-up fast enough in either end-to-end single quality stream situations, or subscribers' quality selection in multi-quality streams situations (Alvarez-Cortes: paragraph [0040]).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Einarsson (US 2010/0121974) in view of O’Callaghan (US 2015/0180924) further in view of Jamadagni et al. (US 2018/0007519), hereinafter Jamadagni.
As for claim 11, the combined system of Einarsson and O’Callaghan teaches the encoded video data is transmitted using a specific protocol (Einarsson: paragraph [0027] describes real time transport protocol is used to transmit encoded a data packet).
The combined system of Einarsson and O’Callaghan fails to teach wherein a specific protocol is a TCP protocol and padding data is transmitted using the UDP protocol.
Jamadagni discloses
teach wherein a specific protocol is a TCP protocol and padding data is transmitted using the UDP protocol (paragraphs [0051] describes dummy packet is sent for a user datagram protocol (UDP) based connection and single packet for a transmission control protocol (TCP)).
One of ordinary skill in the art before the effective filing date of the claimed invention would have recognized the ability to utilize the teachings of Jamadagni for using different types of communication protocols. The teachings of Jamadagni, when implemented in the Einarsson and O’Callaghan system, will allow one of ordinary skill in the art to improve communication of a game server. One of ordinary skill in the art would be motivated to utilize the teachings of Jamadagni in the Einarsson and O’Callaghan system in order to achieve both reliable stream guarantee and low latencies traffic.
Allowable Subject Matter
The following is a statement of reasons for the indication of allowable subject matter: prior art fails to teach all the limitations recite in each of the above indicated claims.
Claims 3-5, 8-9 and 11 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.
Regarding claim 3, the claim recites the limitations “The method of claim 1, further comprising:
in response to determining that the level of network congestion has increased above the threshold, instructing a video encoder to start encoding of video data with the second encoding bitrate;
adjusting the dataset structure to a fourth configuration, wherein a dataset generated according to the dataset structure in the fourth configuration comprises encoded video data with the first encoding bitrate and no padding data; and
in response to receiving an indication that the video encoder encodes video data with the second encoding bitrate, adjusting the dataset structure to the second configuration.”
Regarding claim 4, the claim recites the limitations “The method of claim 1, further comprising:
during the transmission of the second datasets, receiving a third metric indicating a level of network congestion of the communication channel and determining from the received third metric that the level of network congestion has decreased below the threshold;
adjusting the dataset structure to the first configuration; and generating fourth datasets according to the dataset structure in the first configuration and transmitting the fourth datasets as a data stream via the communication channel.”
Einarsson (US 2010/0121974) discloses the server evaluates and decides on the appropriate bitrates for streaming data. The server performs the steps of probing, increasing, and evaluation repeatedly (see paragraph [0030]). Einarsson teaches process that is repeatedly perform but fails to explicitly teach what were claimed in claims 3 and 4.
Regarding claim 5, the claim recites the limitations “The method of claim 1, wherein the dataset structure defines that the encoded video data is prioritized over the padding data during the transmission of dataset generated according to the dataset structure.”
Prior art fails to teach the limitations recited in claim 5.
Regarding claim 8, the claim recites the limitations “The method of claim 7, further comprising:
determining the measurement indicating a variance of available bandwidth of the communication channel using historical data identifying a frequency of changes of configurations of the dataset structure.”
Regarding claim 9, the claim recites the limitations “The method of claim 7, wherein a comparably larger RTT results in a comparably larger padding data size.”
Claims 8 and 9 are objected to as being dependent upon a rejected base claim 7, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims
As allowable subject matter has been indicated, applicant's reply must either comply with all formal requirements or specifically traverse each requirement not complied with. See 37 CFR 1.111(b) and MPEP § 707.07(a).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Spilo et al. (US 8,218,657) teach system and method for automatic adjustment of streaming video bit rate
Virdi et al. (US 7,571,246) teach media transrating over a bandwidth-limited network
Takeda et al. (US 8,171,123) teach network bandwidth detection and distribution.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to L. T N. whose telephone number is (571)272-1013. The examiner can normally be reached M & Th 5:30 am - 2:30 pm EST.
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, TONIA DOLLINGER can be reached at 571-272-4170. 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.
/SCHQUITA D GOODWIN/Primary Examiner, Art Unit 2459
/L. T. N/
Examiner, Art Unit 2459
Prosecution Insights