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 .
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.
Claims 1, 10-13, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Tan et al. (US 2021/0006477) in view of Graff et al. (EP 4184885 A1).
In regard to claim 1, Tan disclosed a method comprising:
determining, by a first computing device, whether a source port of a Real-Time Transport Protocol (RTP) packet of a multimedia application session is a same source port as a source port of a Real-Time Transport Control Protocol (RTCP) packet of the multimedia application session; Tan [0094], When obtaining a data packet, if determining that a source IP address and a destination IP address of the data packet are consistent with the preset source IP address and destination IP address, and determining that a source port number of the data packet is equal to the preset source port number plus 1 and a destination port number of the data packet is equal to the preset destination port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet. Because the data packet of the target call service is bidirectional, when obtaining a data packet, if determining that a source IP address of the data packet is consistent with the preset destination IP address and a destination IP address of the data packet is consistent with the preset source IP address, and determining that a source port number of the data packet is equal to the preset destination port number plus 1 and a destination port number of the data packet is equal to the preset source port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet.
determining, by the first computing device, whether a destination port of the RTP packet is a same destination port as a destination port of the RTCP packet; Tan [0094], When obtaining a data packet, if determining that a source IP address and a destination IP address of the data packet are consistent with the preset source IP address and destination IP address, and determining that a source port number of the data packet is equal to the preset source port number plus 1 and a destination port number of the data packet is equal to the preset destination port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet. Because the data packet of the target call service is bidirectional, when obtaining a data packet, if determining that a source IP address of the data packet is consistent with the preset destination IP address and a destination IP address of the data packet is consistent with the preset source IP address, and determining that a source port number of the data packet is equal to the preset destination port number plus 1 and a destination port number of the data packet is equal to the preset source port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet. and
determining, by the first computing device and based on the determination of whether the source port of the RTP packet is the same source port as the source port of the RTCP packet and the determination of whether the destination port of the RTP packet is the same destination port as the destination port of the RTCP packet Tan [0094], When obtaining a data packet, if determining that a source IP address and a destination IP address of the data packet are consistent with the preset source IP address and destination IP address, and determining that a source port number of the data packet is equal to the preset source port number plus 1 and a destination port number of the data packet is equal to the preset destination port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet. Because the data packet of the target call service is bidirectional, when obtaining a data packet, if determining that a source IP address of the data packet is consistent with the preset destination IP address and a destination IP address of the data packet is consistent with the preset source IP address, and determining that a source port number of the data packet is equal to the preset destination port number plus 1 and a destination port number of the data packet is equal to the preset source port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet.
Tan failed to disclose determining…whether to negotiate and set up, with a second computing device, the use of RTP header extensions for delay determination or the use of RTCP packets for delay determination.
However, Graff disclosed determining…whether to negotiate and set up, with a second computing device, the use of RTP header extensions for delay determination or the use of RTCP packets for delay determination. Graff, [0010], Fig. 2 is a schematic illustration of a prior art message flow 200 between a sender device 201 and a receiving device 202, the sender device transmitting a media stream 203 over a communication link to the receiving device 202. Transport-wide Congestion Control (TWCC) is an extension of the Real-time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) for use in congestion control algorithms for RTP-based media flow. The packets of the media stream 203 comprises a RTP header extension containing a transport-wide packet sequence number, i.e. a packet identifier. TWCC proposes that the receiving device transmits an RTCP feedback message 204 feeding back the arrival times and sequence numbers of the packets of the media stream 203 received over the connection. The sender device keeps a map of in-flight packets, and upon receiving the feedback message 204 looks up the transmission timestamp of the corresponding packet. From these two timestamps the sender can compute metrics such as inter-packet delay variation and estimated queueing delay.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to calculate delay using an RTP header extension and a RTCP feedback message as in Graff with the port determination of RTP and RTCP messages in Tau in order to identify a delay based on the use of a RTCP message or a RTP header extension in Tau, therefore allowing for estimation of queueing delay in Tau to ensure that the packets are part of the current period as in Tau [0106]-[0108], [0110].
In regard to claim 10, Graff disclosed: determining, by at least one of the first computing device or the second computing device, a delay based on the use of the RTP header extensions or the use of the RTCP packets. Graff, [0010], Fig. 2 is a schematic illustration of a prior art message flow 200 between a sender device 201 and a receiving device 202, the sender device transmitting a media stream 203 over a communication link to the receiving device 202. Transport-wide Congestion Control (TWCC) is an extension of the Real-time Transport Protocol (RTP) and Real-Time Transport Control Protocol (RTCP) for use in congestion control algorithms for RTP-based media flow. The packets of the media stream 203 comprises a RTP header extension containing a transport-wide packet sequence number, i.e. a packet identifier. TWCC proposes that the receiving device transmits an RTCP feedback message 204 feeding back the arrival times and sequence numbers of the packets of the media stream 203 received over the connection. The sender device keeps a map of in-flight packets, and upon receiving the feedback message 204 looks up the transmission timestamp of the corresponding packet. From these two timestamps the sender can compute metrics such as inter-packet delay variation and estimated queueing delay.
In regard to claim 12, Tan disclosed …
determining, by the first computing device and for each respective flow of the plurality of flows, whether a corresponding source port of an RTP packet of the respective flow is a same corresponding source port as a corresponding source port of an RTCP packet of the multimedia application session; and
determining, by the first computing device and for each respective flow of the plurality of flows, whether a corresponding destination port of the RTP packet of the respective flow is a same corresponding destination port as a corresponding destination port of the RTCP packet of the multimedia application session.
Tan [0094], When obtaining a data packet, if determining that a source IP address and a destination IP address of the data packet are consistent with the preset source IP address and destination IP address, and determining that a source port number of the data packet is equal to the preset source port number plus 1 and a destination port number of the data packet is equal to the preset destination port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet. Because the data packet of the target call service is bidirectional, when obtaining a data packet, if determining that a source IP address of the data packet is consistent with the preset destination IP address and a destination IP address of the data packet is consistent with the preset source IP address, and determining that a source port number of the data packet is equal to the preset destination port number plus 1 and a destination port number of the data packet is equal to the preset source port number plus 1, the client may determine that the data packet is a data packet of the target call service and the data packet is an RTCP data packet.
Tan failed to disclose wherein the multimedia application session comprises a plurality of flows each associated with corresponding type of data.
However, Graff disclosed wherein the multimedia application session comprises a plurality of flows each associated with corresponding type of data. Graff, [0010], Fig. 2 is a schematic illustration of a prior art message flow 200 between a sender device 201 and a receiving device 202, the sender device transmitting a media stream 203 over a communication link to the receiving device 202. Graff showed just one exemplary flow, but it would be obvious to use multiple flows given the teachings of Graff.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to calculate delay using an RTP header extension and a RTCP feedback message as in Graff with the port determination of RTP and RTCP messages in Tau in order to identify a delay based on the use of a RTCP message or a RTP header extension in Tau, therefore allowing for estimation of queueing delay in Tau to ensure that the packets are part of the current period as in Tau [0106]-[0108], [0110].
Claim 13 is rejected for substantially the same reasons as claim 1.
Claim 20 is rejected for substantially the same reasons as claim 1.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Tan in view of Graff as applied to claim 10 above, and further in view of Shribman et al. (US 12,587,579).
In regard to claim 11, Tan in view of Graff failed to disclose wherein the delay comprises a round trip time (RTT), a one-way uplink delay, or a one-way downlink delay. Graff did disclose calculating delay of a packet flow.
However, Shribman disclosed wherein the delay comprises a round trip time (RTT), a one-way uplink delay, or a one-way downlink delay. Shribman column 43, lines 57-65. The Round-trip Delay Time (RTD) or Round-Trip Time (RTT) is the length of time it takes for a signal to be sent and to be received and processed at the destination node, plus the length of time it takes for an acknowledgment of that signal to be received. This time delay therefore includes the propagation times between the two points of a signal. The signal is generally a data packet, and the RTT is also known as the ping time, and an internet user can determine the RTT by using the ping command.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to calculate any network delay in Graff, including a round trip time, since round trip time is a commonly calculated delay in networks and Graff calculated delays in network packet transfer.
Allowable Subject Matter
Claims 2-9 and 14-19 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.
The following is a statement of reasons for the indication of allowable subject matter:
Regarding claims 2 and 14, the Graff reference failed to disclose based on the determination that the source port of the RTP packet is the same source port as a source port of the RTCP packet and the determination that the destination port of the RTP packet is the same destination port as the destination port of the RTCP packet, determining to negotiate and set up the use of RTCP packets for delay determination.
Regarding claims 9 and 19, the Graff reference fails to disclose based on the determination that at least one of the source port of the RTP packet is not the same source port as a source port of the RTCP packet or the destination port of the RTP packet is not the same destination port as the destination port of the RTCP packet, determining to negotiate and set up the use of RTP header extensions for delay determination.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Jeffrey R. Swearingen whose telephone number is (571)272-3921. The examiner can normally be reached M-F 8:00 am - 5:00 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, Oscar Louie can be reached at 571-270-1684. 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.
Jeffrey R. Swearingen
Primary Examiner
Art Unit 2445
/Jeffrey R Swearingen/ Primary Examiner, Art Unit 2445
Prosecution Insights