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 .
Specification
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed.
Claim Rejections - 35 USC § 102
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 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.
Claim(s) 1-8, 11-18, 20 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Harrell et al. (US 20030067872, hereinafter Harrell.)
Regarding claim 1, “A method for media data transmission, performed by an electronic device, comprising: obtaining a plurality of first media frames, transmitting respective traffic packet sets of the plurality of first media frames to a data receiving end” Harrell (Fig. 2 and ¶0037) a packet network 200 includes a server 202 that is connected to an access network 206 by a link 204, and a client 212 that is attached to a client media buffer 210 that is in turn attached to the access network 206 by a last-mile link 208; (¶0003) media data is transmitted through packet network; (¶0047) packet includes frames
As to “and receiving at least one response packet corresponding to the plurality of first media frames returned by the data receiving end” Harrell teaches (¶0038) The client media buffer 210 plays an important role in providing an error-free media stream to the client. A buffering portion and a signaling device operatively coupled to the buffering portion that can send signals to the server 202 together comprise the client media buffer 210; (¶0039) the client media buffer detects congestion and begins signaling the server to avoid a playback error
As to “performing a first determining operation on whether the data receiving end is capable of receiving media frame data of at least one first media frame based on the at least one response packet” Harrell teaches (¶0016, ¶0044) The client is able to request a plurality of service adjustments from the media server in response to the plurality of congestion levels to avoid errors in the playback of the media stream. Adjustments may include packet retransmissions, stream prioritization, stream acceleration, changes in media compression rate, changes in the enhancement layer or layers in the case of multi-layered streams, dropping B frames in the case of video streaming, changes in media resolution, and maintaining audio while dropping video in exceptional cases; (¶0038) determining whether the buffer duration is long enough to allow packet retransmission before the lost packet obstructs the client's media streaming experience
As to “performing a second determining operation on whether the data receiving end is capable of playing the at least one first media frame for each of the at least one first media frame according to a preset playing order of the plurality of first media frames in a case that a first determining result of the first determining operation is positive” Harrell teaches (¶0038) Preferably, the buffer can detect multiple levels of network congestion and can initiate multiple levels of error handling for graceful degradation through statistically less frequent congestion error situations; (¶0016) The client is able to request a plurality of service adjustments from the media server in response to the plurality of congestion levels to avoid errors in the playback of the media stream. Adjustments may include packet retransmissions, stream prioritization, stream acceleration, changes in media compression rate, changes in the enhancement layer or layers in the case of multi-layered streams, dropping B frames in the case of video streaming, changes in media resolution, and maintaining audio while dropping video in exceptional cases
As to “predicting a storage state of a storage unit of the data receiving end based on a second determining result of the second determining operation; and transmitting a second media frame to the data receiving end by invoking a corresponding preset data transfer strategy according to the storage state, the second media frame being different from the plurality of first media frames, or the second media frame comprising the at least one first media frame.” Harrell teaches (¶0039) If network congestion causes the loss or delay of some packets, then the buffer level will begin to drop. When it drops below a critical level (where buffer levels are measured as playback time remaining), the client media buffer detects congestion and begins signaling the server to avoid a playback error. If the buffer level continues to drop, it will cross another critical level at which the client signals the server to take more aggressive action to avoid letting missing packets traverse the entire buffer length; (¶0038, ¶0047) switch to a lower bit rate video stream.
Regarding claim 2, “The method according to claim 1, wherein the performing, in a case that a first determining result of the first determining operation is positive, a second determining operation on whether the data receiving end is capable of playing the at least one first media frame for each of the at least one first media frame according to a preset playing order of the plurality of first media frames comprises: detecting, iteratively for each of the at least one first media frame, whether the data receiving end is capable of playing the first media frame when it is determined based on the playing order that at least one other media frame that is before the first media frame exists among the plurality of first media frames and based on a first determining result respectively corresponding to the at least one other media frame.” Harrell teaches (¶0041) the buffer receives packets from the network at an In/Write 322 side, and transmits the sequenced data to the client at an Out/Read 324 side; (¶0043) occasional packets may be lost or corrupted. The client media buffer recognizes these errors via packet sequencing and a checksum operation. The buffer periodically requests retransmission of lost or corrupted packets by the server as needed. The server sends retransmitted packets with top priority to replace these packets before they cause a client error during playback. Harrell also teaches (¶0047) subsequent frames in a GOP depend on a key frame for accurate reconstruction of the sequence. When requesting a stream switch, the client will also indicate the boundary of the last complete GOP in the buffer. Depending upon the proportion of the unfinished GOP in the buffer, the server will decide either to replace it with a new lower-bit-rate GOP or to finish that GOP at the higher bit rate before switching to the lower-bit-rate stream
Regarding claim 3, “The method according to claim 2, wherein the detecting whether the data receiving end is capable of playing the first media frame when it is determined based on the playing order that at least one other media frame that is before the first media frame exists among the plurality of first media frames and based on a first determining result respectively corresponding to the at least one other media frame comprises: determining that the client is capable of playing the first media frame, if it is determined that the data receiving end receives each of the at least one other media frame based on the first determining results respectively corresponding to the at least one other media frame, or determining that the client is incapable of playing the first media frame, if it is determined that a media frame not received by the data receiving end exists in the at least one other media frame based on the first determining results respectively corresponding to the at least one other media frame.” Harrell teaches (¶0041) the buffer receives packets from the network at an In/Write 322 side, and transmits the sequenced data to the client at an Out/Read 324 side; (¶0043) occasional packets may be lost or corrupted. The client media buffer recognizes these errors via packet sequencing and a checksum operation. The buffer periodically requests retransmission of lost or corrupted packets by the server as needed. The server sends retransmitted packets with top priority to replace these packets before they cause a client error during playback. Harrell also teaches (¶0047) subsequent frames in a GOP depend on a key frame for accurate reconstruction of the sequence. When requesting a stream switch, the client will also indicate the boundary of the last complete GOP in the buffer. Depending upon the proportion of the unfinished GOP in the buffer, the server will decide either to replace it with a new lower-bit-rate GOP or to finish that GOP at the higher bit rate before switching to the lower-bit-rate stream
Regarding claim 4, “The method according to claim 1, wherein the predicting a storage state of a storage unit of the data receiving end based on a second determining result of the second determining operation comprises: obtaining cached usage data based on the second determining result and with reference to a media frame currently played by the data receiving end; and determining the storage state based on the usage data.” Harrell teaches (¶0044, ¶0046-¶0048, and Fig. 3) based on buffer level (i.e., storage/cache state); (¶0047) the stream switch preferably occurs at a GOP (group of pictures) boundary since subsequent frames in a GOP depend on a key frame for accurate reconstruction of the sequence. In this case, when requesting a stream switch, the client will also indicate the boundary of the last complete GOP in the buffer. Depending upon the proportion of the unfinished GOP in the buffer, the server will decide either to replace it with a new lower-bit-rate GOP or to finish that GOP at the higher bit rate before switching to the lower-bit-rate stream. For instance, if only a few frames of a GOP remain unsent, the server can determine that it saves more bits to send those few frames at a high bit rate per frame rather than to replace almost an entire GOP of frames at a lower bit rate per frame (such a tradeoff depends on the specific bit rates at which the two streams are encoded).
Regarding claim 5, “The method according to claim 4, wherein the cached usage data comprises: a cache quantity and cache duration of media frames in cache; and the obtaining cached usage data based on the second determining result and with reference to a media frame currently played by the data receiving end comprises: determining a target frame whose playing time meets a set reference condition from the at least one playable frame based on a respective playing time of the at least one playable frame, if it is determined that at least one playable frame exists in the at least one first media frame based on the second determining result; obtaining the cache duration based on the media frame currently played by the data receiving end and the playing time of the target frame; and using a quantity of the at least one playable frame as the cache quantity.” Harrell teaches (Fig. 3 and ¶0041) the client media buffer 210 of the preferred embodiment when operating in a normal mode, with media streaming at best quality. The buffer receives packets from the network at an In/Write 322 side, and transmits the sequenced data to the client at an Out/Read 324 side. The buffer transmits the data to the client at the desired playback rate, so after an initial build-up phase the buffer empties its contents at a constant rate. The server 202 preferably delivers media data to the buffer at this same playback rate so that an equilibrium buffer level is maintained; (¶0042, ¶0044, ¶0047, and Fig. 3) different marks 310, 312, 314, 316, 318 based on the playable time left on the buffer, used to receive more content or stop receiving more content from the server (avoid buffer overflow.)
Regarding claim 6, “The method according to claim 5, wherein the determining the storage state based on the usage data comprises: determining that the storage state is insufficient, in a case that the cache duration is less than a preset first duration threshold and the cache quantity is less than a preset first quantity threshold, or determining that the storage state is sufficient, in a case that the cache duration is greater than a preset second duration threshold and the cache quantity is greater than a preset second quantity threshold.” Harrell teaches (¶0039, ¶0042, and Fig. 3) When it drops below a critical level (where buffer levels are measured as playback time remaining), the client media buffer detects congestion and begins signaling the server to avoid a playback error. If the buffer level continues to drop, it will cross another critical level at which the client signals the server to take more aggressive action to avoid letting missing packets traverse the entire buffer length.
Regarding claim 7, “The method according to claim 1, wherein the transmitting a second media frame to the data receiving end by invoking the data transfer strategy comprises: determining an initial transmission parameter based on network transmission performance between a data transmitting end and the data receiving end; adjusting the initial transmission parameter based on the data transfer strategy, to obtain a target transmission parameter; and transmitting the second media frame to the data receiving end based on the target transmission parameter.” Harrell teaches (¶0042 and ¶0045) speeding up or slowing down the serving based on buffer level; Harrell also teaches (¶0047-¶0048, ¶0053, ¶0055, ¶0057, Fig. 5) switching between lower-bit-rate to a higher-bit-rate and vice-versa based on network congestion/demand.
Regarding claim 8, “The method according to claim 7, wherein the adjusting the initial transmission parameter based on the data transfer strategy, to obtain a target transmission parameter comprises: adjusting the initial transmission parameter according to a data transfer strategy of increasing a transmitted data volume, to obtain the target transmission parameter, in a case that the storage state indicates insufficient cache, or adjusting the initial transmission parameter according to a data transfer strategy of reducing a transmitted data volume, to obtain the target transmission parameter, in a case that the storage state indicates sufficient cache.” Harrell teaches (¶0042 and ¶0044-¶0045) speeding up or slowing down the serving based on buffer level; Harrell also teaches (¶0047-¶0048, ¶0053, ¶0055, ¶0057, Fig. 5) switching between lower-bit-rate to a higher-bit-rate and vice-versa based on network congestion/demand.
Regarding claim 11, its rejection is similar to claim 1.
Regarding claim 12, its rejection is similar to claim 2.
Regarding claim 13, its rejection is similar to claim 3.
Regarding claim 14, its rejection is similar to claim 4.
Regarding claim 15, its rejection is similar to claim 5.
Regarding claim 16, its rejection is similar to claim 6.
Regarding claim 17, its rejection is similar to claim 7.
Regarding claim 18, its rejection is similar to claim 8.
Regarding claim 20, its rejection is similar to claim 1.
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.
Claim(s) 9-10, 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Harrell in view of Anderson et al. (US 5905713, hereinafter Anderson.)
Regarding claim 9, “The method according to claim 1, wherein the playing order of the plurality of first media frames is determined in the following mode:” Harrell teaches (¶0007-¶0009, and Fig. 1) Application-level data, such as streaming media data, is broken into pieces and each piece is given a transfer header by TCP. An IP header is then affixed to each piece, followed in some cases by a data link header providing information relevant to the actual data link over which the data will be transferred. At the receiving end, these headers are removed in inverse order until the original data is recovered; (¶0041) the buffer receives packets from the network at an In/Write 322 side, and transmits the sequenced data to the client at an Out/Read 324 side; (¶0043) occasional packets may be lost or corrupted. The client media buffer recognizes these errors via packet sequencing and a checksum operation. The buffer periodically requests retransmission of lost or corrupted packets by the server as needed.
Harrell alone does not teach “a locally recorded packet identifier set of each of the first media frames is obtained, the packet identifier set comprising a packet identifier of each traffic packet in the traffic packet set of the first media frame, and each packet identifier being obtained by numbering according to a transmission order of each traffic packet; and the playing order of the plurality of first media frames is determined based on each packet identifier comprised in each packet identifier set.” However, Anderson teaches (2:53-60) each packet header may contain up to three 8-bit bytes which maintain the proper sequencing of packets and identifies the contents of the packet. The packet stream analyzer uses the header information to verify the contents and sequencing of packets. Accordingly, when the system of Harrell is modified by Anderson each packet would have an identifier. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the packet network system as taught Harrell with the packet identifier as taught by Anderson for the benefit of verifying the contents and sequencing of packets.
Regarding claim 10, “The method according to claim 1, wherein the performing, based on the at least one response packet, a first determining operation on whether the data receiving end is capable of receiving media frame data of at least one first media frame comprises” Harrell teaches (¶0007-¶0009, and Fig. 1) Application-level data, such as streaming media data, is broken into pieces and each piece is given a transfer header by TCP. An IP header is then affixed to each piece, followed in some cases by a data link header providing information relevant to the actual data link over which the data will be transferred. At the receiving end, these headers are removed in inverse order until the original data is recovered; (¶0041) the buffer receives packets from the network at an In/Write 322 side, and transmits the sequenced data to the client at an Out/Read 324 side; (¶0043) occasional packets may be lost or corrupted. The client media buffer recognizes these errors via packet sequencing and a checksum operation. The buffer periodically requests retransmission of lost or corrupted packets by the server as needed.
Harrell alone does not teach “obtaining a locally recorded packet identifier set of each of the first media frames, the packet identifier set comprising a packet identifier of each traffic packet in the traffic packet set of the first media frame, and each packet identifier being obtained by numbering according to a transmission order of each traffic packet; and determining that the data receiving end receives media frame data of at least one first media frame, based on each packet identifier comprised in each packet identifier set and a packet identifier carried by the at least one response packet.” However, Anderson teaches (2:53-60) each packet header may contain up to three 8-bit bytes which maintain the proper sequencing of packets and identifies the contents of the packet. The packet stream analyzer uses the header information to verify the contents and sequencing of packets. Accordingly, when the system of Harrell is modified by Anderson each packet would have an identifier. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the packet network system as taught Harrell with the packet identifier as taught by Anderson for the benefit of verifying the contents and sequencing of packets.
Regarding claim 19, its rejection is similar to claim 9.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Sudak et al. (US 20200107069) – (¶0098) the stream analysis engine 112, the local EMLC feedback 122 (e.g., EMLC feedback 122 via communicative coupling 110B), the local dropped packet feedback (e.g., acknowledgement feedback 121 via communicative coupling 110A), and the direct side channel and hardware-to-hardware coupling (e.g., via communicative coupling 110C), the source electronic device 58A may improve matching and/or tracking of the encoded video stream bitrate to EMLC conditions, may be able to intelligently schedule data packets 86 of the encoded video stream to increase the chances that the sink electronic device 58B receives a suitable amount of data to decode each image frame 84 of the encoded video stream. Further, bandwidth may be more efficiently utilized for transmission of data based upon data packets 86 and/or image frames predicted to experience transmission error.
Dalbec et al. (US 20180270516) – (¶0075) The media guidance application may, in response to determining that the user device receiving the media asset from the first source does not have buffering capabilities, store the media asset received from the first source in the buffer.
Eberle et al. (US 20200145725) – (¶0062) The source device 108 may determine the packet type, flags, and parameters of the request packet. The source device 108 also receives response packets, such as acknowledgement packets, negative acknowledgement packets, etc., from the retransmission buffer 110.
Park et al. (US 20200092074) – (¶0082) The communicator 210 may receive, from the receiving electronic device 100, various information such as a response signal (e.g., ACK signal) for data reception, a response signal (e.g., Drop signal) for missing data, a response signal (e.g., BSS signal) for the data buffer amount, or the like. At this time, the ACK signal may be a signal for notifying that the receiving electronic device 100 has received data from the transmitting electronic device 200 without missing data. The drop signal may be a signal including information on missing data in a communication process. The BSS signal may be a signal to notify that the amount of buffer of the data stored in the buffer in the receiving electronic device 100 is less than a predetermined amount.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FRANK J JOHNSON whose telephone number is (571)272-9629. The examiner can normally be reached 9:00AM-5:00PM 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, Brian T. Pendleton can be reached on 571-272-7527. 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.
/Frank Johnson/Primary Examiner, Art Unit 2425
Prosecution Insights