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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 5/27/26 has been entered.
Response to Arguments
Applicant's arguments and amendments, filed 5/27/26, have been fully considered but they are not persuasive.
Applicant argued:
However, Applicant respectfully points out that sections 5.32.7.3 ("Interworking without N26 Interface") and 5.32.8 ("ATSSS Rules") on pages 322-323 of 3GPP TS 23.501 are exclusively directed to Access Traffic Steering, Switching and Splitting (ATSSS) rules and EPS interworking. There is absolutely no mention of "timestamp information", nor any teaching of "timestamp information... carried in a header of a data packet" or "a transmission time" on these cited pages.
The above limitations of claim 1 require that:
1) The UPF obtains the timestamp information according to a data packet of the first data sent by an application server or an application layer;
2) The UPF sends the timestamp information to the access network device;
3) The timestamp information indicates a time at which the first data is expected to arrive at a receiver, i.e., a future arrival time of the first data to the access network device; and
4) The timestamp information is used by the access network device to determine a processing policy for the first data.
The Examiner respectfully disagrees and initially submits that pages 322-323 of 3GPP TS 23.501 contains sections 5.33.3.1 to 5.33.3.3 not sections 5.32.7.3 ("Interworking without N26 Interface") and 5.32.8 ("ATSSS Rules") as Applicant suggests. Pages 322-323 teach:
1) The UPF obtains the timestamp information according to a data packet of the first data sent by an application server or an application layer (“The PSA UPF encapsulates in the GTP-U header with QFI, QoS Monitoring Packet (QMP) indicator (which indicates the packet is used for UL/DL packet delay measurement) and the local time T1 when the PSA UPF sends out the DL monitoring packets.”);
2) The UPF sends the timestamp information to the access network device (“When receiving an UL packet from UE for that QFI or when the NG-RAN sends a dummy UL packet as monitoring response (in case there is no UL service packet for UL packet delay monitoring), the NG-RAN encapsulates QMP indicator, the RAN part of UL/DL packet delay result, the time Tl received in the GTP-U header, the local time T2 at the reception of the DL monitoring packet and the local time T3 when NG-RAN sends out this monitoring response packet to the UPF via N3 interface, in the GTP-U header of the monitoring response packet.”);
3) The timestamp information indicates a time at which the first data is expected to arrive at a receiver, i.e., a future arrival time of the first data to the access network device (“The PSA UPF records the local time T4 when receiving the monitoring response packets and calculates the round trip (if not time synchronized) or UL/DL packet delay (if time synchronized) between NG-RAN and anchor PSA UPF based on the time information contained in the GTP-U header of the received monitoring response packet.”); and
4) The timestamp information is used by the access network device to determine a processing policy for the first data (“SMF may activate the end to end UL/DL packet delay measurement between UE and PSA UPF for a QoS Flow during the PDU Session Establishment or Modification procedure.”).
As shown, these cited pages do indeed teach "timestamp information", "timestamp information... carried in a header of a data packet" and "a transmission time" as well as a time at which the first data is expected to arrive (“The PSA UPF records the local time T4 when receiving the monitoring response packets and calculates the round trip (if not time synchronized) or UL/DL packet delay (if time synchronized)”). Thus, 3GPP TS 23.501 teaches the currently presented claim limitations.
Applicant further argued:
The cited 3GPP neither discloses any of the above limitations of claim 1, nor teaches the general concept of UPF sending information of further arrival time of data to the access network device, so that the processing policy for the data is determined based on the further arrival time.
Furthermore, throughout the cited 3GPP documents, all the timestamps described are time of behaviors already happened (see e.g., table 5.8.2.11,7-1 on page 179, the timestamp, in terms of absolute time, when the collection of the information provided within Usage-Information is started, or the timestamp, in terms of absolute time, when the information provided within Usage- Information is generated in; or see e.g., section 5.27.1.2 on page 266, ingress timestamping (TSi) made upon reception of a downlink gPTP message, or egress timestamping (TSe) created after a UE receives the gPTP messages and forwards them to the DS-TT), instead of a further time of a behavior to be performed. Therefore, 3GPP even fails to provide any hint of the time at which the first data is expected to arrive at a receiver as defined in claim 1.
The Examiner notes that in addition to teaching the timestamp information as above, page 323 of 3GPP further states:
The SMF can request to activate QoS monitoring for the GTP-U path(s) between all UPF(s) and the (R)AN based on locally configured policies. Alternatively, when a QoS monitoring policy is received in a PCC rule and the QoS monitoring is not yet active for the DSCP corresponding to the 5QI in the PCC rule, the SMF activates QoS Monitoring for all UPFs currently in use for this PDU Session and the (R)AN. The SMF sends the QoS monitoring policy to each involved UPF and the (R)AN via N4 interface and via N2 interface respectively.
A GTP-U sender performs an estimation of RTT to a GTP-U receiver on a GTP-U path by sending Echo messages and measuring time that elapses between the transmission of Request message and the reception of Response message. A GTP-U sender computes an accumulated packet delay by adding RTT/2, the processing time and, if available, an accumulated packet delay from an upstream GTP-U sender (i.e. an immediately preceding GTP-U sender in user plane path) thus the measured accumulated delay represents an estimated elapsed time since a user plane packet entered 3GPP domain.
It is expected that a GTP-U sender determines RTT periodically in order to detect changes in transport delays. QoS monitoring is performed by a GTP-U end-point (UP function) that receives and stores QoS monitoring policy including a packet delay budget parameter for a QoS flow. QoS monitoring is performed by comparing a received accumulated packet delay with the stored QoS parameter, i.e. packet delay budget, possibly also taking into the account the measured delay of GTP-U path to next GTP-U end-point processing time. If the GTP-U end-point (the PSA UPF, in the case of accumulated packet delay reporting) determines that the packet delay exceeds the requested packet delay budget, then the node triggers QoS monitoring alert signalling to the relevant SMF or to the OA&M function. (Emphasis added).
Herein 3GPP clearly teaches the concept of UPF sending information of further arrival time of data to the access network device so that the processing policy for the data is determined based on the further arrival time (“The SMF can request to activate QoS monitoring for the GTP-U path(s) between all UPF(s) and the (R)AN based on locally configured policies. Alternatively, when a QoS monitoring policy is received in a PCC rule and the QoS monitoring is not yet active for the DSCP corresponding to the 5QI in the PCC rule, the SMF activates QoS Monitoring for all UPFs currently in use for this PDU Session and the (R)AN.”).
And in addition to page 322 as explained above, 3GPP herein also discloses a time at which the first data is expected to arrive by estimating a Round-Trip-Time (RTT) by using timestamp information (“A GTP-U sender performs an estimation of RTT to a GTP-U receiver on a GTP-U path by sending Echo messages and measuring time that elapses between the transmission of Request message and the reception of Response message.”). And goes on to teach wherein the timestamp information is used to determine a processing policy for processing the first data by the access network device (“It is expected that a GTP-U sender determines RTT periodically in order to detect changes in transport delays. QoS monitoring is performed by a GTP-U end-point (UP function) that receives and stores QoS monitoring policy including a packet delay budget parameter for a QoS flow.”) Therefore, 3GPP TS 23.501 teaches the claimed limitations.
The Examiner respectfully reminds applicant of the broadest reasonable interpretation standard (See MPEP 2111), "During examination, the claims must be interpreted as broadly as their terms reasonably allow." In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 USPQ2d 1827, 1834 (Fed. Cir. 2004) (The USPTO uses a different standard for construing claims than that used by district courts; during examination the USPTO must give claims their broadest reasonable interpretation.) In Phillips v. AWH Corp., 415 F.3d 1303, 75 USPQ2d 1321 (Fed. Cir. 2005), the court further elaborated on the “broadest reasonable interpretation" standard and recognized that “The Patent and Trademark Office (“PTO") determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction." Thus, when interpreting claims, the courts have held that Examiners should (1) interpret claim terms as broadly as their terms reasonably allows and (2) interpret claim phrases as broadly as their construction reasonably allows. In conclusion, upon taking the broadest reasonable interpretation of the claims, the cited reference teaches all of the claimed limitations and the rejections are maintained as below.
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, 3-4, 8, 12-13 and 17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; System architecture for the 5G System (5GS); Stage 2 (Release 16)” of 3GPP TS 23.501 V16.7.0 dated December, 2020, hereinafter referred to as “3GPP.”
As per claim 1, 3GPP teaches an access network device, comprising a memory and a processor, wherein the memory is configured to store a program, and the processor is configured to invoke the program in the memory to cause the access network device to perform:
receiving, from a user plane function (UPF) network element, timestamp information of first data, wherein the timestamp information is obtained by the UPF network element according to a data packet of the first data sent by an application server or an application layer, the timestamp information is used to indicate a time at which the first data is expected to arrive at a receiver, wherein the receiver is the access network device,
wherein the timestamp information is carried on a user plane or comprised in a user plane message,
wherein the timestamp information is used to determine a processing policy for processing the first data by the access network device [pages 322-323].
As per claim 3, 3GPP teaches the access network device according to claim 1, wherein the processor is configured to invoke the program in the memory to cause the access network device to further perform: receiving quality of service (QOS) information of the first data and/or associated information of the first data, wherein the associated information is used to indicate information of second data associated with the first data; wherein the QoS information and/or the associated information and the timestamp information are used together to determine a processing policy for processing the first data by the access network device [pages 0132-0134].
As per claim 4, 3GPP teaches the access network device according to claim 1, wherein the processing policy for the first data comprises one or more of the following operations: buffering of the first data; a transmission time of the first data; or resource allocation and/or scheduling of the first data [page 94].
As per claim 8, 3GPP teaches the access network device according to claim 1, wherein the time at which the first data is expected to arrive at the receiver comprises one or more of the following: a time at which the first data is expected to arrive at an access stratum (AS) layer of the receiver; a time at which the first data is expected to arrive at a non-access stratum (NAS) layer of the receiver; and a time at which the first data is expected to arrive at an application layer of the receiver [page 309].
As per claim 12, 3GPP teaches the access network device according to claim 1, wherein the timestamp information is carried in one or more of the following messages: a medium access control control element (MAC CE), uplink control information (UCI), physical layer indication information, scrambling code information, port information, a transmission resource, and a resource request [page 262].
As per claim 13, 3GPP teaches the access network device according to claim 12, wherein the transmission resource or the resource request comprises one or more of the following messages: a buffer status report (BSR), a scheduling request (SR), an uplink shared channel (UL-SCH), a downlink shared channel (DL-SCH), an uplink (UL) scheduling grant, and downlink (DL) assignment [page 55].
Claim 17 has similar limitations as to the rejected claims above therefore it is being rejected under the same rationale.
There are prior art made of record not relied upon but is considered pertinent to applicant's disclosure. See attached.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RANODHI N SERRAO whose telephone number is (571)272-7967. The examiner can normally be reached Monday to Friday 8:00 am to 4: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, John Follansbee can be reached on (571) 272-3964. 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.
Ranodhi N. Serrao
/RANODHI SERRAO/Primary Examiner, Art Unit 2444
Prosecution Insights