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 .
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.
DETAILED ACTION
This communication is in response to Application No. 19/079,686 filed on 14 March 2025 2024. The election response presented on 31 July 2026. Applicant provisionally elects with traverse to prosecute Group I, inclusive of claims 1-5, 9-13, 15, 17 and 19. Claims 1-5, 9-13, 15, 17 and 19 are currently pending and subject to examination.
Election/Restrictions
Applicant provisionally elects with traverse to prosecute Group I, inclusive of claims 1-5, 9-13, 15, 17 and 19. in the reply filed on 31 July 2026 is acknowledged. Claims 6-8, 14, 16, 18 and 20 are withdrawn from further consideration pursuant to 37 CFR 1.142(b) as being drawn to a nonelected invention, there being no allowable generic or linking claim. Election was made with traverse in the reply filed on 31 July 2026.
Response to Arguments
Applicant argues at page 2 of the remarks, as filed on 31 July 2026, that
Notwithstanding the above provisional election, Applicant reserves the right to request rejoinder, according to MPEP § 821.04, of claims 6-8, 14, 16, 18 and 20, once the elected claims have been allowed. Nevertheless, Applicant respectfully traverses this election and reserves the right to file one or more divisional and/or continuation applications claiming some or all of the unelected subject matter. Applicant respectfully traverses the Restriction Requirement for at least the following reasons. The Patent Office is requested to reconsider the Restriction Requirement. Applicant respectfully submits that all the claims are sufficiently related to each other such that an undue burden would not be placed upon the Patent Office by maintaining all groups in a single application. See, e.g., MPEP § 803. Moreover, the Office's demand for election is burdensome, not only of the Patent Office and the Applicant, but also the public. Applicant may be forced to expend considerable monies for filing and prosecuting at least one additional patent application. The Office will then be burdened by multiple unnecessary applications and redundant repetition of work. Correspondingly, the public will then be generally burdened by having to consider multiple applications and patents where, in reality, the need for them does not exist.
In view of the foregoing, it is respectfully submitted that the requirement for election be withdrawn.
The examiner respectfully disagrees and finds these arguments unpersuasive.
I. Claims 1-5, 9-13, 15, 17 and 19 are drawn to a decoding method, performed by a first terminal, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: receiving a plurality of real-time transport protocol (RTP) data packets of a target multimedia file sent by a server; sending, in a case that it is determined that the RTP data packets do not comprise a first RTP data packet of the target multimedia file sent by the server; receiving the first RTP data packet, and inserting the first RTP data packet into a cache to decode the target multimedia file and the first terminal and the second terminal jointly receive the RTP data packets of the target multimedia file sent by the server, and classified in H04L65/65.cpc.
II. Claims 6-8, 14, 16, 18 and 20 are drawn to a data transmission method, performed by a server, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: obtaining an initial value of a shared code corresponding to a target multimedia file; determining a shared code corresponding to each of a plurality of real-time transport protocol (RTP) data packets of the target multimedia file based on the initial value of the shared code and sending the plurality of RTP data packets of the target multimedia file to a first terminal and a second terminal, and classified in H04L67/1091.cpc.
3. Inventions I and II are related as subcombinations disclosed as usable together in a single combination. The subcombinations are distinct if they do not overlap in scope and are not obvious variants, and if it is shown that at least one subcombination is separately usable. In the instant case, subcombination I has separate utility such as
a decoding method, performed by a first terminal, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: receiving a plurality of real-time transport protocol (RTP) data packets of a target multimedia file sent by a server; sending, in a case that it is determined that the RTP data packets do not comprise a first RTP data packet of the target multimedia file sent by the server; receiving the first RTP data packet, and inserting the first RTP data packet into a cache to decode the target multimedia file and the first terminal and the second terminal jointly receive the RTP data packets of the target multimedia file sent by the server. subcombination II has separate utility such as a data transmission method, performed by a server, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: obtaining an initial value of a shared code corresponding to a target multimedia file; determining a shared code corresponding to each of a plurality of real-time transport protocol (RTP) data packets of the target multimedia file based on the initial value of the shared code and sending the plurality of RTP data packets of the target multimedia file to a first terminal and a second terminal. See MPEP § 806.05(d).
Inventions l and ll require significantly different search queries with respect to one another. Invention l is directed towards a decoding method, performed by a first terminal, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: receiving a plurality of real-time transport protocol (RTP) data packets of a target multimedia file sent by a server; sending, in a case that it is determined that the RTP data packets do not comprise a first RTP data packet of the target multimedia file sent by the server; receiving the first RTP data packet, and inserting the first RTP data packet into a cache to decode the target multimedia file and the first terminal and the second terminal jointly receive the RTP data packets of the target multimedia file sent by the server, Invention II is directed towards a data transmission method, performed by a server, an electronic device, a non-transitory readable storage medium, a chip and a computer program product comprising: obtaining an initial value of a shared code corresponding to a target multimedia file; determining a shared code corresponding to each of a plurality of real-time transport protocol (RTP) data packets of the target multimedia file based on the initial value of the shared code and sending the plurality of RTP data packets of the target multimedia file to a first terminal and a second terminal.
Therefore, The examiner is maintaining restriction requirement. As Applicant’s elects with traverse to prosecute Group I, inclusive of claims 1-5, 9-13, 15, 17 and 19 so for the examination purpose examiner will consider claims 1-5, 9-13, 15, 17 and 19 for examination.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 9-11, 15, 17 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over SHANG et al. (CN 101119249 A); in view of Daily et al. (US 2018/0014082 A1).
Regarding claim 1, SHANG teaches a decoding method, performed by a first terminal ([paragraph 0096, 0135] describes a client terminal (e.g. a first terminal) performing a FEC decoding method), the method comprising:
receiving a plurality of real-time transport protocol (RTP) data packets of a target multicast data sent by a server ([paragraph 0048, 0066-0068, 0072] describes The client terminal (e.g. the first terminal) requests to download data from the server, and the server pushes the data down via a bearer network in a multicast manner. During the data push process, if another client (e.g. second terminal) request to download the same data, within the limits of the available resources, the client can join the multicast group to receive multicast data and simultaneously request other clients to download any missed, lost, or corrupted data, preparing to receive data, the service end starts the multicast, a client downloading data from a service side through a multicast address issued by the service side, data basic information prepared at the service side mainly consists of the following parts: the data transmission protocol specifies what format the data packets transmitted over the network take, real Time Transport Protocol (RTP)),
wherein a protocol header of each of the RTP data packets carries a common block corresponding to the RTP data packet, the common block is used for indicating an arrangement sequence number of the RTP data packet in the target multicast data ([paragraph 0063-0066, 0097-0098, 0111] describes RTP protocol header of each RTP data packets includes a common block (e.g. shared code) corresponding to the RTP data packet and The server prepares a file "a.dat" with a file size of 256M. The file block
size is set to 256K, with a total of 1000 blocks. The network data packet size
is 1K, so each block contains 256 packets. Each common block (e.g. shared code) has a block number, starting from 0 and ranging from 0 to 999. Each data packet has a packet number within a block, starting from 0 and ranging from 0 to 255. The sequence number of a data packet sent over the network consists of two parts: the block number and the packet number within the block. The sequence number of each data packet can be used to locate its specific position in the file);
and the common block corresponding to the RTP data packet is determined by the server based on an initial value of an obtained common block corresponding to the target multicast data ([paragraph 0063-0066, 0097-0098, 0111] describes the common block (e.g. shared code) corresponding to the RTP data packet is determined by the server based on value starting from 0 to 999 and Each data packet (e.g. first data packet) has a packet number within a block, starting from 0 and ranging from 0 to 255. The sequence number of a data packet sent over the network consists of two parts: the block number and the packet number within the block. The sequence number of each data packet can be used to locate its specific position in the file);
sending, in a case that it is determined that the RTP data packets do not comprise a first RTP data packet of the target multicast data sent by the server, a common block of the first RTP data packet to a second terminal (paragraph 0089, 0111, 0114-0116] describes When a client detects data loss, it first sends a query packet to other clients
based on the current client information list. The query packet may include basic information about the client, the sequence number of the lost data packet, and whether FEC is supported, sending the common block (e.g. shared code) of first RTP data packets to another client (e.g. second terminal)); and
receiving the first RTP data packet, and inserting the first RTP data packet into a cache to decode the target multicast data, wherein the first RTP data packet is sent by the second terminal based on the common block of the first RTP data packet (paragraph 0097, 0115-0116, 0136] describes receiving the first RTP data packet and attaching the first data packet into a local buffer (e.g. cache) to decode multicast data and the client (e.g. first terminal) will request another client (e.g. second terminal) to transmit data packets in blocks 0-50, as well as data packets 254 and 255 in block 51),
wherein the first terminal and the second terminal jointly receive the RTP data packets of the target multicast data sent by the server ([paragraph 0027, 0085] describes both the client (e.g. first terminal) and another client (e.g. second terminal .receive RTP data packets of the multicast data sent by the server. a service side
issuing a multicast address and a list of customer information to a client, upon receipt of this information by the client, join a multicast group, preparing to receive data, the service end starts the multicast, a client downloading data from a service side through a multicast address issued by the service side, the data basic information prepared at the
service side mainly includes the following: the data transmission protocol specifies what format the data packets are transmitted over the network the Real Time Transport Protocol (RTP) may be used).
SHANG fails to teach wherein a common block is a shared code; and wherein multicast data is a multimedia file.
However, Daily teaches wherein a common block is a shared code ([paragraph 0151-0153, 0320-0321] describes common block is a common shared code);
and wherein multicast data is a multimedia file ([paragraph 0093, 0151-0153, 0260-0261] describes multicast data is a multimedia file).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of SHANG to include wherein a common block is a shared code; and wherein multicast data is a multimedia file as taught by Daily. One ordinary skill in the art would be motivated to utilize the teachings of SHANG in the Daily system in order to perform the actions of decrypting, interpreting FEC, and depacketizing via common shared code and data ([paragraph 0052] in Daily).
Regarding claim 2, the combination of SHANG and Daily teaches the method, wherein the sending, in a case that it is determined that the RTP data packets do not comprise a first RTP data packet of the target multimedia file sent by the server, a shared code of the first RTP data packet to a second terminal comprises: determining, based on the plurality of received RTP data packets of the target multimedia file sent by the server, whether the first RTP data packet has not been received; and sending the shared code of the first RTP data packet to the second terminal in a case that the first RTP data packet has not been received (SHANG: [paragraph 0087-0089, 0115-0116] describes When a client detects data loss, it first sends a query packet to other clients based on the current client information list. The query packet may include basic information about the client, the sequence number of the lost data packet, and whether FEC is supported and During the download process, if a client misses, loses, or corrupts data while downloading multicast data, it can request the missing, lost, or corrupted data from other clients if those clients possess it. If data loss occurs while downloading data from other clients, the data segment containing that data packet is retransmitted wherein a common block is a shared code (Daily: [paragraph 0151-0153, 0320-0321] describes common block is a common shared code); and wherein multicast data is a multimedia file (Daily: [paragraph 0093, 0151-0153, 0260-0261] describes multicast data is a multimedia file).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of SHANG to include wherein a common block is a shared code; and wherein multicast data is a multimedia file as taught by Daily. One ordinary skill in the art would be motivated to utilize the teachings of SHANG in the Daily system in order to perform the actions of decrypting, interpreting FEC, and depacketizing via common shared code and data ([paragraph 0052] in Daily).
Regarding claim 3, the combination of SHANG and Daily teaches the method, wherein the determining whether the first RTP data packet has not been received comprises: determining, based on the shared codes of the plurality of received RTP data packets, that an unreceived first RTP data packet exists in a case that the shared codes of the plurality of RTP packets are not consecutive (SHANG:[paragraph 0087-0089, 0111, 0114-0116] describes the determining whether the first RTP data packet has not been received includes determining, based on the common blocks of the of received RTP data packets, that an unreceived first RTP data packet exists in a case that the common blocks of the of RTP packets are not in order) Daily: [paragraph 0151-0153, 0320-0321] describes common block is a common shared code); and wherein multicast data is a multimedia file (Daily: [paragraph 0093, 0151-0153, 0260-0261] describes multicast data is a multimedia file).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of SHANG to include wherein a common block is a shared code; and wherein multicast data is a multimedia file as taught by Daily. One ordinary skill in the art would be motivated to utilize the teachings of SHANG in the Daily system in order to perform the actions of decrypting, interpreting FEC, and depacketizing via common shared code and data ([paragraph 0052] in Daily).
Regarding claims 9-11, these claims contain limitations found within that of claims 1-3 and the same rationale to rejections are used.
Regarding claim 15, this claim contains limitations found within that of claim 1 and the same rationale to rejection is used.
Regarding claim 17, this claim contains limitations found within that of claim 1 and the same rationale to rejection is used.
Regarding claim 19, this claim contains limitations found within that of claim 1 and the same rationale to rejection is used.
.
Claims 4-5 and 12-13 are rejected under 35 U.S.C. 103 as being unpatentable over SHANG et al. (CN 101119249 A); in view of Daily et al. (US 2018/0014082 A1) and further in view of FENG et al. (CN 109510868 A).
Regarding claim 4, SHANG and Daily fails to teach the method, further comprising: establishing a connection with the second terminal in a case that a packet loss rate of the first terminal satisfies a first condition, wherein the first condition comprises that the packet loss rate is greater than or equal to a first preset threshold.
However, FENG teaches the method, further comprising: establishing a connection with the second terminal in a case that a packet loss rate of the first terminal satisfies a first condition, wherein the first condition comprises that the packet loss rate is greater than or equal to a first preset threshold ([paragraph 0065-0069] describes establishing a P2P network exchanging signaling information with a node that has established a connection, the signaling information including information such as network conditions between two nodes, packet loss rate, network speed and uplink capability, such that two nodes with a successful connection obtain each other's network conditions; replacing connected objects when network conditions are poor; In order to guarantee the stability of the established P2P network to acquire resource data, a subscription request may be sent to connected nodes having a packet loss rate less than a first set value, an uplink capability exceeding a second set value, and/or a wideband capability of each node exceeding a third set value and packet loss rate is greater than first set threshold).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of SHANG/Daily to include establishing a connection with the second terminal in a case that a packet loss rate of the first terminal satisfies a first condition, wherein the first condition comprises that the packet loss rate is greater than or equal to a first preset threshold as taught by FENG. One ordinary skill in the art would be motivated to utilize the teachings of SHANG/Daily in the FENG system in order to establish a connection with the node that responds to the request to update the P2P network ([paragraph 0010] in FENG).
Regarding claim 5, the combination of SHANG, Daily and FENG teaches the method, wherein the establishing a connection with the second terminal in a case that a packet loss rate of the first terminal satisfies a first condition (FENG: paragraph 0065-0069] describes establishing a P2P network exchanging signaling information with a node that has established a connection, the signaling information including information such as network conditions between two nodes, packet loss rate, network speed and uplink capability, such that two nodes with a successful connection obtain each other's network conditions; replacing connected objects when network conditions are poor; In order to guarantee the stability of the established P2P network to acquire resource data, a subscription request may be sent to connected nodes having a packet loss rate less than a first set value, an uplink capability exceeding a second set value, and/or a wideband capability of each node exceeding a third set value and packet loss rate is greater than first set threshold) comprises:
receiving information about at least one terminal sent by the server, wherein a packet loss rate of each of the at least one terminal is less than or equal to a second preset threshold; selecting the second terminal from the at least one terminal in a case that the packet loss rate of the first terminal satisfies the first condition; and establishing the connection with the second terminal(FENG: [paragraph 0065-0069] describes after receiving the node list, this node (node 1) can send connection requests to all or some of the nodes in the node list based on the address information on the node list. The node that receives the request determines whether it still allows other nodes to actively connect to it. If the number of other nodes actively connecting to this node is less than a first set threshold, it returns a response to node 1, and the connection is successful. If
it is equal to the first set threshold, it does not return a response and after establishing a connection with the node responding to the request, selecting at least one node from the nodes with which the connection has been established to obtain resource data).
Therefore, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the teachings of SHANG/Daily to include receiving information about at least one terminal sent by the server, wherein a packet loss rate of each of the at least one terminal is less than or equal to a second preset threshold, selecting the second terminal from the at least one terminal in a case that the packet loss rate of the first terminal satisfies the first condition; and establishing the connection with the second terminal as taught by FENG. One ordinary skill in the art would be motivated to utilize the teachings of SHANG/Daily in the FENG system in order to establish a connection with the node that responds to the request to update the P2P network ([paragraph 0010] in FENG).
Regarding claims 12-13, these claims contain limitations found within that of claims 4-5 and the same rationale to rejections are used.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
- Maharajh et al., US 2013/0166580 A1, the present invention provides method and system for determining if an existing pass log may be reused.
- Shivadas et al., US 2014/0359678 A1, Network services encode multimedia content, such as video, into multiple adaptive bitrate streams of encoded video and a separate trick play stream of encoded video to support trick play feature.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MEHULKUMAR J SHAH whose telephone number is (571)272-1072. The examiner can normally be reached Mon-Fri, 6:05 am-3:55 pm.
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.
/M.J.S/Examiner, Art Unit 2459 /TONIA L DOLLINGER/Supervisory Patent Examiner, Art Unit 2459
Prosecution Insights