CTFR 18/792,361 CTFR 92003 DETAILED ACTION Notice of Pre-AIA or AIA Status 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. This communication is in response to the amendment filed on 04/23/2026. Claims 1-16 are pending and rejected. Claims 1-2, 4-13, 15-16 have been amended. Response to Arguments Applicant’s arguments, with respect to the Claim interpretation under 35 U.S.C 112(f) has been fully considered and are persuasive. The Interpretation has been withdrawn. Applicant’s arguments with respect to claims 1 and 15-16 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Further, applicant’s argued that Jarnikov does not teach the minimizing of arrival time to the second device. The examiner respectful disagree. Jarnikon teach at [0045] requesting chunks at a low quality decreases transmission time leaving more reserve time available to transmit following chunks. Avoid requesting more data than that could be timely transmitted under current network conditions to prevent delays in displaying the video . Prevent delays corresponds to the claimed “minimizing of arrival time”. Although Jarnikon does not teach the whole limitation “ assigning, for each of a plurality of chunks,…, to minimize an arrival time required for all packets belonging to the chunk to reach the second device ”, Jarnikov still teaches the partial limitation noted above. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 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. 07-20-aia AIA 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. 07-21-aia AIA Claim s 1-3 and 6-16 are rejected under 35 U.S.C. 103 as being unpatentable over Jarnikov (US 20110270913 A1) in view of Beck (US 20130227102 A1) . Regarding claim 1 , Jarnikov teaches a communication device that transmits packets received from a first device to a second device using one of a plurality of communication lines, the device comprising a central processing unit (CPU), a memory storing a program, and a buffer that stores the packets, wherein the CPU executes the program to perform: receiving the packets from the first device ([0041], fig. 1, a receiver module 1 communicates with an external server for requesting and receiving content data 101) ; identifying a chunk to which each of the packets belongs, the chunk being a unit of data treated as a single piece of data at a higher layer ( [0004] Each copy typically consists of two-to five-seconds segments called chunks (single piece of content data) that are physically separated (e.g. a file is created for each chunk in a copy) or logically separated (e.g. all chunks of a copy are stored in a single file with an addressing structure that allows to access any chunk individually) ; acquiring a communication performance of each of the plurality of the communication lines ([0041] The receiver module is furthermore configured to estimate the available bandwidth, typically based on the size of the downloaded content data and the duration of its transmission) ; reading the packets from the buffer and transmitting the read packets to the second device using one of a plurality of the communication lines based on the assignment ([0041] Data read from the buffer 3 and provided to the decoder 4; [0004] predict transmission time for the next chunk from different quality levels and choose the quality level that minimizes the risk of late chunk delivery while keeping the quality level as high as possible) . Jarnikov does not explicitly teach assigning, for each of a plurality of chunks, each of a plurality of the packets to respective one of the plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device. Beck teaches assigning, for each of a plurality of chunks, each of a plurality of the packets to respective one of the plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device ([0044] The exemplary Chunk Request Scheduler 130 then schedules audio chunk requests over the slower TCP connection(s) during step 630 and schedules video chunk requests over the faster TCP connection(s)) . It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jarnikov disclosure, chunks are transmitted to destination based on performance of the connections, as taught by Beck. One would be motivated to do so to balance the tradeoff between fast reaction time and efficient downloads. Regarding claim 2 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU identifies the chunks based on the reception interval of the packets received by the receiver ([0004] Each copy typically consists of two-to five-seconds segments called chunks that are physically separated (e.g. a file is created for each chunk in a copy) or logically separated) . Regarding claim 3 , Jarnikov and Beck teach the communication device according to claim 2, wherein Jarnikov further teaches the chunks are frames generated by compression of video ([0005] On the contrary, the bit budget may vary per frame in order to enhance the rate-distortion performance of the encoded video). Regarding claim 6 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU assigns, for each of the chunks, each of the plurality of the packets to one of the plurality of the communication lines based on at least one of the available bandwidth of each communication line and the delay time of each communication line ([0014] estimating an available bandwidth of the packet switched network), wherein the available bandwidth is based on a transmission duration of the digital content; [0068] data packets may be delayed due to multiple traffic flows contending for the same path). Regarding claim 7 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU assigns, for each of the chunks, each of the plurality of the packets to respective one of the plurality of the communication lines based on at least one of the amount of un-transmitted data in the chunk being transmitted, and the amount of in-flight data, the in-flight data being data that is being transmitted or scheduled to be transmitted on each communication line and has not reached the second device, in addition to the communication performance ([0043] Although it is possible that a next chunk is not available, for simplicity in this example the external server always has the next chunk available, so the buffer fullness on the client side is the only limiting factor. If the buffer is full, the receiver is put on hold until the buffer 3 has sufficient space to accommodate the next chunk; [0045] The client buffer 3 is kept as full as possible to be able to accommodate a possible oversized chunk or a drop in the network throughput. Requesting chunks (depicted by 203) at a low quality decreases transmission time leaving more reserve time available to transmit following chunks) . Regarding claim 8 , Jarnikov and Beck teach the communication device according to claim 6, wherein Jarnikov further teaches the CPU assigns, for each of the chunks, each of the plurality of the packets to respective one of the plurality of the communication lines based on at least one of the amount of un-transmitted data in the chunk being transmitted, and the amount of in-flight data, the in-flight data being data that is being transmitted or scheduled to be transmitted on each communication line and has not reached the second device, in addition to the communication performance ([0043] Although it is possible that a next chunk is not available, for simplicity in this example the external server always has the next chunk available, so the buffer fullness on the client side is the only limiting factor. If the buffer is full, the receiver is put on hold until the buffer 3 has sufficient space to accommodate the next chunk; [0045] The client buffer 3 is kept as full as possible to be able to accommodate a possible oversized chunk or a drop in the network throughput. Requesting chunks (depicted by 203) at a low quality decreases transmission time leaving more reserve time available to transmit following chunks) . Regarding claim 9 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU, when transmitting a subsequent packet using the communication line to which no preceding packet is assigned, reads the subsequent packet from the from a position offset from a beginning of the buffer, the preceding packet is a packet of a preceding chunk, which is a chunk that should complete reaching the second device first, and the subsequent packet is a packet of a subsequent chunk, which is a chunk that should complete reaching the second device after the preceding chunk ([0065] In this example the duration of a chunk is 2 seconds, video sequences are split in chunks and trace files are created for recording sizes of all chunks. The trace files contain size measurements for chunks from different quality levels). Regarding claim 10 , Jarnikov and Beck teach the communication device according to claim 1, Jarnikov further teaches CPU controls the storage of the packets in the buffer and the discarding of the packets from the buffer by the chunks ([0015] signaling from the controller to the receiver a quality level of a next chunk of data) . Regarding claim 11 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU identifies a communication flow to which the packet belongs based on the source and/or destination of the packet, the CPU assigns each of the plurality of packets to respective one of the plurality of communication lines for each communication flow and for each chunk, to make the arrival time of the plurality of packets by the chunk to the second device the earliest ([0009] In practice the channel throughput may not be constant bit rate and may vary over time, due to competing traffic, changing to a different routing path, or switching between different content sources; [0042] Typically, every chunk belongs to a particular quality level. Hereby the controller changes the quality level of the receiver in such way that a chunk can be successfully received within a given time period) . Regarding claim 12 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU transmits chunk identification information that identifies the chunk to which the packet belongs ([0004] Each copy typically consists of two-to five-seconds segments called chunks that are physically separated or logically separated. A protocol allows a client to request a data chunk from one of several quality levels at run-time to react to varying network conditions) . Regarding claim 13 , Jarnikov and Beck teach the communication device according to claim 1, wherein Jarnikov further teaches the CPU transmits chunk size information indicating the size of the chunk to which the packet belongs ([0063] The statistics are gathered off-line by measuring sizes of chunks of a particular duration from the various video inputs and dividing the measured values by the bandwidth that the calculated strategy will be used for). Regarding claim 14 , Jarnikov and Beck teach the communication device according to claim 1, Jarnikov further teaches wherein the communication device is mounted to a mobile object ([0003] respond to an operation of attaching the electronic device onto a vehicle magnetic suction bracket by a user) . Regarding claim 15 , Jarnikov teaches a communication method performed by a CPU of a communication device comprising a buffer that stores the packets and transmitting packets received from a first device to a second device using one of a plurality of communication lines, the method comprising: receiving the packets from the first device ([0041], fig. 1, a receiver module 1 communicates with an external server for requesting and receiving content data 101) ; identifying the chunk to which each of the packets belongs, the chunk being a unit of data treated as a single piece of data at a higher layer ( [0004] Each copy typically consists of two-to five-seconds segments called chunks that are physically separated (e.g. a file is created for each chunk in a copy) or logically separated (e.g. all chunks of a copy are stored in a single file with an addressing structure that allows to access any chunk individually); acquiring the communication performance of each of a plurality of the communication lines ([0041] The receiver module is furthermore configured to estimate the available bandwidth, typically based on the size of the downloaded content data and the duration of its transmission) ; reading the packets from the buffer and transmitting the read packets to the second device using one of a plurality of the communication lines based on the assignment ([0041] Data read from the buffer 3 and provided to the decoder 4; [0004] predict transmission time for the next chunk from different quality levels and choose the quality level that minimizes the risk of late chunk delivery while keeping the quality level as high as possible) . Jarnikov does not explicitly teach assigning, for each of a plurality of chunks, each of a plurality of the packets to respective one of a plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device. Beck teaches assigning, for each of a plurality of chunks, each of a plurality of the packets to respective one of a plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device ([0044] The exemplary Chunk Request Scheduler 130 then schedules audio chunk requests over the slower TCP connection(s) during step 630 and schedules video chunk requests over the faster TCP connection(s)) . It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jarnikov disclosure, chunks are transmitted to destination based on performance of the connections, as taught by Beck. One would be motivated to do so to balance the tradeoff between fast reaction time and efficient downloads. Regarding claim 16 , Jarnikov teaches a computer-readable non-transitory storage medium storing a communication program executable by a CPU of a communication device comprising a buffer that stores the packets and transmitting packets received from a first device to a second device using one of a plurality of communication lines, the communication program causing the communication device to: receive the packets from the first device ([0041], fig. 1, a receiver module 1 communicates with an external server for requesting and receiving content data 101) ; identify the chunk to which each of the packets belongs, the chunk being a unit of data treated as a single piece of data at a higher layer ( [0004] Each copy typically consists of two-to five-seconds segments called chunks that are physically separated (e.g. a file is created for each chunk in a copy) or logically separated (e.g. all chunks of a copy are stored in a single file with an addressing structure that allows to access any chunk individually); store the packets in a buffer ([0041] The received data is stored in a buffer) ; acquire the communication performance of each of a plurality of the communication lines ([0041] The receiver module is furthermore configured to estimate the available bandwidth, typically based on the size of the downloaded content data and the duration of its transmission) ; read the packets from the buffer and transmitting the read packets to the second device using one of a plurality of the communication lines based on the assignment ([0041] Data read from the buffer 3 and provided to the decoder 4; [0004] predict transmission time for the next chunk from different quality levels and choose the quality level that minimizes the risk of late chunk delivery while keeping the quality level as high as possible) . Jarnikov does not explicitly teach assign, for each of a plurality of chunks, each of a plurality of the packets to respective one of a plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device. Beck teaches assign, for each of a plurality of chunks, each of a plurality of the packets to respective one of a plurality of the communication lines based on the communication performance, to minimize an arrival time required for all packets belonging to the chunk to reach the second device ([0044] The exemplary Chunk Request Scheduler 130 then schedules audio chunk requests over the slower TCP connection(s) during step 630 and schedules video chunk requests over the faster TCP connection(s)) . It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jarnikov disclosure, chunks are transmitted to destination based on performance of the connections, as taught by Beck. One would be motivated to do so to balance the tradeoff between fast reaction time and efficient downloads . 07-21-aia AIA Claim s 4-5 are rejected under 35 U.S.C. 103 as being unpatentable over Jarnikov (US 20110270913 A1) in view of Beck (US 20130227102 A1) and further in view of Sung (US 20190160834) . Regarding claim 4 , Jarnikov and Beck teach the communication device according to claim 1, Jarnikov does not explicitly teach wherein Sung further teaches the CPU identifies the chunks based on the identifier contained in the IP header of the packet. Sung teaches wherein Sung further teaches the CPU identifies the chunks based on the identifier contained in the IP header of the packet ([0127] a unique session identification is a session identifier stored in the header of an IP packet) . It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jarnikov disclosure, packet includes IP address header, as taught by Sung. One would be motivated to do so to transmit data packets, so that the overall performance of the aggregate end-to-end connection is satisfactory, and is not affected negatively by transmitting data packets through established end-to-end connections that have poor performance. Regarding claim 5 , Jarnikov and Beck teach the communication device according to claim 1, Janikov does not explicitly teach wherein Sung further teaches the packet identification unit identifies the chunk based on the identification information contained in the TCP/UDP payload of the packet. Sung teaches wherein Sung further teaches the packet identification unit identifies the chunk based on the identification information contained in the TCP/UDP payload of the packet ([0127] the session identifier is stored in the payload of an IP packet). It would have been obvious to a person of ordinary skill in the art before the effective filling date of the claimed invention made to include in the Jarnikov disclosure, identification information contained in the payload of the packet, as taught by Sung. One would be motivated to do so to transmit data packets, so that the overall performance of the aggregate end-to-end connection is satisfactory, and is not affected negatively by transmitting data packets through established end-to-end connections that have poor performance. Conclusion 07-40 AIA 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 ANH NGUYEN whose telephone number is (571)270-0657. The examiner can normally be reached M-F. 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 5712703037. 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. /ANH NGUYEN/Primary Examiner, Art Unit 2458 Application/Control Number: 18/792,361 Page 2 Art Unit: 2458 Application/Control Number: 18/792,361 Page 3 Art Unit: 2458 Application/Control Number: 18/792,361 Page 4 Art Unit: 2458 Application/Control Number: 18/792,361 Page 5 Art Unit: 2458 Application/Control Number: 18/792,361 Page 6 Art Unit: 2458 Application/Control Number: 18/792,361 Page 7 Art Unit: 2458 Application/Control Number: 18/792,361 Page 8 Art Unit: 2458 Application/Control Number: 18/792,361 Page 9 Art Unit: 2458 Application/Control Number: 18/792,361 Page 10 Art Unit: 2458 Application/Control Number: 18/792,361 Page 11 Art Unit: 2458 Application/Control Number: 18/792,361 Page 12 Art Unit: 2458 Application/Control Number: 18/792,361 Page 13 Art Unit: 2458
Prosecution Insights