DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. 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
2. 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.
3. 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.
4. 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.
5. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
6. Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Bae et al. (WO 2024096657A1, hereinafter “Bae”).
Regarding claims 1, 9 and 16, Bae teaches a method comprising: receiving, by an entity (figs. 9 and 12, Page 32, Page 33, page 35) in a wireless network, a packet with a flag set to a first value, wherein the first value indicates that the packet is associated with non-low latency, low loss and scalable throughput (non-L4S) traffic ( Page 4, Page 5: it is possible to provide services that take congestion control situations into account even when intermediate network equipment does not support L4S services. Fig. 4, Page 15: The ECN congestion bit can be encoded with the value below. 00 (Non-ECT) ECN transmission is not supported . 01 ECT(1) L4S support available . 10 ECT(0) Classical ECN support . 11 CE (Congestion Experience) Congestion Experience. Page 16: When handover occurs between source NG-RAN (source NG-RAN: S-NG-RAN) where service is supported and target NG-RAN (target NG-RAN: T-NG-RAN) where L4S service is not supported It may be a congestion notification operation. Page 17: It can be seen that the L4S service is not supported, and therefore "Request ECN marking" or "Congestion info" can be transmitted to the UPF entity 104 through the N4 modification procedure. Page 18: the intermediate router can reset the ECN value to No ECT support and forward it. Page 21: The UPF entity 104 operates as follows depending on the ECN field value in the TOS field included in the IP header, the congestion control L4S/ECN marking control code received from the SMF entity 105, and whether or not there is congestion); determining, by the entity and based on a packet detection rule, that the packet should be associated with L4S traffic; and transmitting, by the entity and based on determining that the packet should be associated with L4S traffic, the packet with the flag set to a second value, wherein the second value indicates that the packet is associated with L4S traffic (Page 17: The UPF entity 104, which has received “Request ECN marking” or “Congestion info” through the N4 modification procedure, requests ECN marking on the uplink packet and sends the uplink packet for which ECN marking was requested to AS (200). ), it is possible to inform the AS (200) that congestion occurs. Page 20: a network entity that changes according to the movement of the terminal 101 (e.g., change from source RAN (source RAN: S-RAN 102-1) to target RAN (target RAN: T-RAN) 102-2) If the device does not support L4S/ECN marking, this is notified through signaling on the control plane, and the SMF entity 105 notifies the UPF entity 104 of this to perform L4S/ECN marking instead, which is included in the PCC policy information…the SMF entity ( 105) receives this and can perform a policy update to perform L4S/ECN marking based on congestion situation information in the UPF entity 104 through an N4 session change request…However, through a separate policy update, networks that do not support L4S/ECN marking L4S/ECN marking to a network entity (e.g., UPF entity 104) that supports L4S/ECN marking based on reporting information received from the SMF entity 105... the SMF entity 105 may transmit the N4 rules related to L4S/ECN related to QER (QoS enforcement rule) on a QoS Flow basis to the UPF entity 104. Page 21: The UPF entity 104 operates as follows depending on the ECN field value in the TOS field included in the IP header, the congestion control L4S/ECN marking control code received from the SMF entity 105, and whether or not there is congestion, Page 22: In step 611, settings for the L4S service, such as whether or not to mark L4S/ECN between network entities and the UE application and application server, can be completed through the above steps. Page 31: the UPF entity 104 performs the L4S/ECN operation of the UPF entity 104 received in step 607 of FIG. 6 based on the received congestion information. Based on the marking policy, the CE bit can be marked on the ECN bit in the TOS field of the internal IP header of upstream application layer traffic).
Bae does not explicitly teach restoring, by the entity, based on determining that the packet should be associated with L4S traffic, the flag to a second value that was previously associated with the packet; transmitting, by the entity, the packet with the flag restored to the second value.
However, Bae teaches the value of the ECN field in the TOS field of the IP header of the TCP SYN packet sent by the terminal may be marked as ECT(0) if the terminal supports Classic ECN, and as ECT(1) if it supports L4S. If there is a router that does not support ECN or L4S among the routers through which TCP packets pass between the terminal and the AS, the intermediate router can reset the ECN value to No ECT support and forward it. Along the path, the AS that receives the TCP SYN packet can find out whether ECN/L4S is supported on the path with the terminal. The application service provider may know in advance whether ECN/L4S is supported in the 5G network managed by the mobile communication service provider, and may also know whether ECN/L4S is supported in the intermediate backhaul network through an agreement, or as an example above (Pages 17-18 ). A network entity that changes according to the movement of the terminal 101 (e.g., change from source RAN (source RAN: S-RAN 102-1 that supports L4S/ECN marking) to target RAN (target RAN: T-RAN 102-2 that device does not support L4S/ECN marking), this is notified through signaling on the control plane, and the SMF entity 105 notifies the UPF entity 104 of this to perform L4S/ECN marking instead, which is included in the PCC policy information. When a congestion situation occurs in each network entity, L4S/ECN marking is performed depending on whether the network entity supports L4S/ECN marking or at the request of the service provider. However, through a separate policy update, networks that do not support L4S/ECN marking L4S/ECN marking to a network entity (e.g., UPF entity 104) that supports L4S/ECN marking based on reporting information received from the SMF entity 105 on the control plane based on reporting information from the entity (RAN) (Page 20).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, that the UPF restores, based on determining that the packet should be associated with L4S traffic, the flag to a second value that was previously associated with the packet, wherein restoring the flag to the second value restores L4S compliance (i.e., when a terminal that supports L4S/ECN marking moves from a source RAN (that supports L4S/ECN marking) to a target RAN (that does not support L4/ECN marking), and the UPF receives a packet from the target RAN that does not support L4S/ECN marking (i.e., UPF receives a no ECT packet), the UPF marks the packet with L4S/ECN marking (ECT (1))), and transmits the packet with the flag restored to the second value in the system of Bae to further enhance industrial applicability.
Regarding claims 2, 10 and 17, Bae teaches the method of claim 1, wherein the packet is subject to packet header bleaching (Pages 17-18, If there is a router that does not support ECN or L4S among the routers through which TCP packets pass between the terminal and the AS, the intermediate router can reset the ECN value to No ECT support and forward it) and wherein determining, based on the packet detection rule, that the packet should be associated with L4S traffic is based on data associated with the packet, wherein the data includes one or more of a source Internet Protocol (IP) address, a source port, a destination IP address, a destination port, or a protocol associated with the packet (Bae: fig. 1, Pages 17-18, Page 19: L4S/ECN-related PCC rules may include the following information: Service data flow information (SDF) is information that can identify the service flow to which L4S/ECN will be applied. It can be expressed as a Service Data Flow Template. It can be expressed as an IP source/destination address or range, a source/receive port number or range, or a fully qualified domain name (FQDN) value or FQDN range, for example, a range of FQDNs expressed in regular expressions.).
Regarding claims 3, 11 and 17, Bae teaches the method of claim 1, wherein determining, based on the packet detection rule, that the packet should be associated with L4S traffic is based on ongoing traffic flows that are associated with L4S traffic ( fig. 1, Page 19: The PCF entity 106 may transmit the SM policy control update notification request message to the SMF entity 105 including L4S/ECN-related policy and charging control (PCC) rules. L4S/ECN-related PCC rules may include the following information: Service data flow information (SDF) is information that can identify the service flow to which L4S/ECN will be applied. It can be expressed as a Service Data Flow Template. It can be expressed as an IP source/destination address or range, a source/receive port number or range, or a fully qualified domain name (FQDN) value or FQDN range, for example, a range of FQDNs expressed in regular expressions. Pages 20-22, Page 31: in step 811, the RAN does not support L4S/ECN marking according to the congestion information delivery method experienced by the RAN in the QoS profile of the RAN, but congestion information is provided through a congestion information report message on the control plane. When supporting delivery, the RAN determines to generate a congestion information reporting message including congestion information and then delivers it to the SMF entity 105 through the AMF entity 103 through steps 813 and 814, and to the SMF entity 105 in step 815. ) delivers the corresponding congestion information to the UPF entity 104 through the N4 session modification process, and the UPF entity 104 performs the L4S/ECN operation of the UPF entity 104 received in step 607 of FIG. 6 based on the received congestion information. Based on the marking policy, the CE bit can be marked on the ECN bit in the TOS field of the internal IP header of upstream application layer traffic).
Regarding claims 4, 12 and 18, Bae teaches the method of claim 1, further comprising: receiving, from a policy control function (PCF) via a session management function (SMP), policy and charging control (PCC) rules provisioned for a session, wherein the PCC rules include an L4S control data configuration that indicates the packet detection rule (fig. 1, Page 19: the PCF entity 106 may determine the L4S/ECN congestion control policy based on the request received from the AF entity 107. If the PCF entity 106 decides to provide the L4S/ECN service according to the operator policy, the PCF entity 106 may perform the SM policy control update notification procedure. The PCF entity 106 may transmit the SM policy control update notification request message to the SMF entity 105 including L4S/ECN-related policy and charging control (PCC) rules. L4S/ECN-related PCC rules may include the following information: Service data flow information (SDF) is information that can identify the service flow to which L4S/ECN will be applied. It can be expressed as a Service Data Flow Template. It can be expressed as an IP source/destination address or range, a source/receive port number or range, or a fully qualified domain name (FQDN) value or FQDN range, for example, a range of FQDNs expressed in regular expressions.. L4S/ECN marking-related information may include L4S/ECN marking policy and L4S/ECN congestion experience bit marking policy. The L4S/ECN marking policy may have a policy including whether L4S/ECN marking is supported, the L4S/ECN marking version, and L4S/ECN marking support using information from the control plane. Page 21, page 22. Figs. 7b, 7c, page 25, page 26).
Regarding claims 5, 13 and 19, Bae teaches the method of claim 1, wherein the packet is received from a network node associated with the packet header bleaching, and a header of the packet is incorrectly marked as being associated with non-L4S traffic based on the packet header bleaching (Pages 17-18, If there is a router that does not support ECN or L4S among the routers through which TCP packets pass between the terminal and the AS, the intermediate router can reset the ECN value to No ECT support and forward it).
Regarding claims 6 and 14, Bae teaches the method of claim 1, wherein the flag of the packet is enabled to be set to a third value based on a network congestion, based on the flag being set to the second value instead of the first value (Bae: fig. 4, page 20, Page 21: The UPF entity 104 operates as follows depending on the ECN field value in the TOS field included in the IP header, the congestion control L4S/ECN marking control code received from the SMF entity 105, and whether or not there is congestion. Congestion Control L4S/ECN Marking If the control code value is "Reset ECN", the ECN value is set to 00 (No ECT) and delivered. If "Reset ECN" and congestion control information (e.g. Congestion info) transmitted from the control plane is transmitted to the UPF entity 104 through a separate L4S/ECN control rule, the UPF entity 104 uses the information to perform L4S /ECN marking can be performed. Congestion Control L4S/ECN Marking If the control code value is "bypass", the ECN value is not checked and is transmitted as is. The congestion control profile of bypass can operate the same even if there is no congestion control profile. Congestion Control L4S/ECN Marking If the control code value is L4S marking, the ECN value of the arrived IP header is ECT(1) capable, and if the congestion is greater than the specified congestion level or the predefined congestion level threshold, two ECNs are activated. bit resets the CE bit (i.e., marks the CE bit), otherwise retains the ECT(1) value. Congestion Control L4S/ECN Marking If the control code value is classic ECN marking and the ECN value of the arrived IP header is ECT(0) capable and is greater than the specified congestion level or predefined congestion level threshold, two ECN bits are used. Reset the CE bit (i.e., mark the CE bit), otherwise maintain the ECT(0) value).
Regarding claims 7, 15 and 20, Bae teaches the method of claim 1, wherein the packet is an Internet Protocol (IP) packet, the packet is associated with downlink traffic, and the first value and the second value are explicit congestion notification (ECN)-capable transport (ECT) values (fig. 4, Page 15, Page 20, Page 21, Page 27: whether or not congestion has been experienced can be expressed as 1 bit information to indicate whether or not congestion has been experienced, or as 2 bits representing whether ECT is supported, ECT(0), ECT(1), and CE (11), such as the ECN bit in the IP header…In step 759, the AS marks the CE bit in the ECN bit in the TOS field of the internal IP header of the downlink application layer traffic based on the marking information of the CE bit in the ECN bit in the TOS field of the internal IP header of the received uplink application layer traffic).
Regarding claim 8, Bae teaches the method of claim 1, wherein the entity is a user plane function (UPF) (figs. 6-7d, 9, 12, Page 31, Page 32).
Response to Arguments
7. Applicant’s arguments with respect to claims 1, 9 and 16 have been considered but are moot in view of new ground(s) of rejection.
Bae renders obvious the amended claims 1, 9 and 16, as set forth above.
Conclusion
8. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477