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 .
DETAILED ACTION
This action is responsive to the application filed on 01/31/2024 has a total of 20 claims pending in the application; there are 3 independent claims and 17 dependent claims, all of which are ready for examination by the examiner.
Title
The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. The examiner suggests the title “A UPF for traffic steering rules in mobile edge computing network”.
Specification
The disclosure is objected to because of the following informalities: The AS-specific extended community drawings presented in the specification, paraphrase [0042] and [0044], should be under the “Drawings sheet”. They are not a presentation of tables but rather graphs. Thus, these drawings belong under the Drawing section. Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 7-10 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 7 recites “wherein the routing tag includes one or more of a routing domain identifier, a virtual routing and forwarding (VRF) identifier, a community attribute, an extended community attribute, or an AS-specific extended community attribute” having the routing tag contains an identifier or an attribute...”. However, dependent claim 8 recites “the routing tag includes the routing domain identifier…”. While dependent claim 9 recites “the routing tag includes the community attribute…” and dependent claim 10 recites “the routing tag includes a routing domain identifier and the community attribute…” the limitations claimed in dependent claims 8-10 are optional limitations in base claim 7, which make the claims indefinite for failing to particularly point out and distinctly claim the subject matter. Examiner suggests amending claim 7 to have the routing tag include all the attributes and identifiers. Appropriate corrections is required.
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.
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-20 are rejected under 35 U.S.C. 103 as being unpatentable over LI et al. Publication No. (US 2022/0109633 A1) in view of BOGINENI et al. Publication No. (US 2019/0335002 A1).
Regarding claim 1, LI teaches in a telecommunications network having a user plane function (UPF) configured to steer network traffic in accordance with traffic steering rules (configuring a user plane function (UPF) 240 to perform selective traffic steering rules in a wireless communication system [0155] FIG.2B), a method comprising:
installing, at the UPF, a packet detection rule (PDR) including instructions used for steering network traffic, the PDR including a route rule with a routing tag (configuring at a UPF with information further includes generating rules according to the information for the UPF, the rules including a packet detection rule (PDR) and a forwarding action rule (FAR) for at least one UPF, the information used for traffic selection to support selective traffic steering [0010] FIG.3) ;
receiving, at the UPF, a data packet and identifying one or more packet attributes of the data packet (the UPF configured to receive rules, from the SMF, the rules including at least one packet detection rule (PDR) and at least one forwarding action rule (FAR); the at least one PDR indicating that the at least one PDU is from DPF of the service function chain. The at least one UPF is further configured to receive the at least one PDU from the first DPF of the service function chain [0015] FIG.3);
comparing the one or more packet attributes against the route rule of the PDR (the UPF detects a PDU (i.e. the data packet sent from the UE) is destined to or targeting the DNS server, e.g. by comparing the destination address in the PDU header of the data packet with an address of the DNS server and identifying that they are identical. The detection may be based on the PDR and/or the PFD associated to the PDR [0228-229] FIG.9);
determining, based on comparing the one or more packet attributes against the route rule, that the one or more packet attributes match the route rule of the PDR (the UPF may check the content (i.e. payload) of the PDU. If the content indicate a DNS query, i.e. a DNS message sent to the DNS server for querying the IP address corresponding to a domain name, and if the domain name matches or is identical to the domain name of the AS in local configuration (e.g. in a locally-store PDR related to the application), the UPF may notify the SMF 204 about the detection by sending a notification (indicating the detection of traffic related to the application) to the SMF 204 [0229-230] FIG.9); and
routing, based on determining that the one or more packet attributes match the route rule, the data packet in accordance with the instructions of the PDR (For a packet that matches or satisfies the PDR, the UPF 240 performs selective traffic steering based on the PDR indicating that the packet is received from the RAN (e.g. the source of the PDR containing information), the PDR uses the FAR to route traffic toward the final destination and/or route traffic toward the service function chain, the PDR includes information about traffic selection to the UPF [0162-165] FIG.9), wherein routing the data packet includes steering the data packet to a local data network of an edge network (local data network (DN 242) may represent an Edge Computing network or resource, such as a Mobile Edge Computing (MEC) network [0037-39] FIG.1).
LI does not explicitly teach the UPF processing data in a telecommunications network.
BOGINENI teaches the UPF processing data in a telecommunications network (BOGINENI: a user plane function (UPF) processing a set of rules for managing a communications session in a wireless telecommunications system [0011-15] FIG.1A).
Therefore, it would have been obvious to one of ordinary skilled in the art before the effective filling date of the claimed invention to have modified LI by the teaching of BOGINENI to have the UPF processing rules in a telecommunication network making the UPF apply sets of packet processing rules tailored to specific types of packets, which can result in lower network latency, more efficient packet routing and increased network reliability and quality of service (BOGINENI: [0010] FIG.1A).
Regarding claim 2, LI teaches the method of claim 1, wherein the PDR is received from a session management function (SMF) (the UPF 240 to perform selective traffic steering based on the PDR or the FAR provided by the SMF 204, or configured by the SMF 204 into the UPF 240 [0155-156] FIG.8).
Regarding claim 3, LI teaches the method of claim 2, wherein the PDR is received from the SMF in conjunction with establishing a packet data unit (PDU) session (steering traffic of PDUs are performed by a session management function (SMF) [0010] FIG.9).
Regarding claim 4, LI teaches the method of claim 1, wherein the PDR includes a packet filter rule (The AF request may have an application identifier or traffic filtering information (e.g. 5 Tuple, indicating or including a source IP address, a source port number, a destination IP address, a destination port number and a protocol or type of protocol in use) mapped to a PDR or packet detection rule(s) [0059] FIG.3)
Regarding claim 5, LI teaches the method of claim 4, further comprising determining that the one or more packet attributes match the packet filter rule of the PDR, and wherein routing the data is further based on determining that the one or more packet attributes match the packet filter rule of the PDR (an identifier (DNAIs) are related to the information considered by the SMF for UPF selection, e.g. for diverting (locally) some traffic matching traffic filters provided by the PCF, the PCF acknowledges (step 309 in FIG.3) the AF request, if the AF request is targeting an individual PDU Session, to the AF or to the NEF [0083] FIG.3).
Regarding claim 6, LI teaches the method of claim 1, wherein the route rule is received from the local data network on the edge network via a routing protocol (receiving, from an application function (AF), a message including a target AS internet protocol (IP) address corresponding to a target data network access identifier (DNAI) [0254] FIG.3).
Regarding claim 7, LI teaches the method of claim 1, wherein the routing tag includes one or more of a routing domain identifier, a virtual routing and forwarding (VRF) identifier, a community attribute, an extended community attribute, or an AS-specific extended community attribute (the SMF 204 may configure UPF(s) accordingly by sending 234 configuration parameters or rules to the UPF(s), such as attributes in N4 forwarding action rules and packet detection rules or simply sending the forwarding action rules and/or the packet detection rules to the UPF(s). The configuration parameters or rules may be generated by the SMF 204 based on polices received from the PCF 206 or the configuration information/parameters from OAM 210 [0054] FIG.9).
Regarding claim 8, LI teaches the method of claim 7, wherein the routing tag includes the routing domain identifier, and wherein the method further comprises routing the data packet in accordance with a forwarding action rule (FAR) attached to the PDR based on determining that the one or more packet attributes match the routing domain identifier of the PDR (the attributes used by the network functions for packet (PDU) selection strategy (for indicating how to select traffic to route to a service function chain), include a second forwarding action rule ID, which identifies a forwarding action that is to be taken by the UPF(s) in order to route traffic toward the service function chain (when selective traffic steering applies, e.g. as indicated by the PDU selection), the attribute of the forwarding action rule ID is used to identify or refer to a forwarding action that is to be taken by the UPF in order to route traffic toward the final destination (e.g., this can apply to a domain identifier or a community attribute or both) [0161-165] TABLE-00002).
Regarding claim 9, LI teaches the method of claim 7, wherein the routing tag includes the community attribute, and wherein the method further comprises routing the data packet in accordance with a forwarding action rule (FAR) attached to the PDR based on determining that the one or more packet attributes match with the community attribute of the PDR (the attributes used by the network functions for packet (PDU) selection strategy (for indicating how to select traffic to route to a service function chain), include a second forwarding action rule ID, which identifies a forwarding action that is to be taken by the UPF(s) in order to route traffic toward the service function chain (when selective traffic steering applies, e.g. as indicated by the packet (PDU) selection strategy), the attribute of the forwarding action rule ID is used to identify or refer to a forwarding action that is to be taken by the UPF in order to route traffic toward the final destination (e.g., this can apply to a domain identifier or a community attribute or both) [0161-165] TABLE-00002).
Regarding claim 10, LI teaches the method of claim 7, wherein the routing tag includes the routing domain identifier, and wherein the method further comprises routing the data packet in accordance with a forward actioning rule (FAR) attached to the PDR based on determining that the one or more packet attributes match with the routing domain identifier and the community attribute of the PDR (the attributes used by the network functions for packet (PDU) selection strategy (indicating how to select traffic to be routed), include a second forwarding action rule ID, which identifies a forwarding action that is to be taken by the UPF(s) in order to route traffic toward the service function chain (when selective traffic steering applies, e.g. as indicated by the PDU selection), the attribute of the forwarding action rule ID is used to identify or refer to a forwarding action that is to be taken by the UPF in order to route traffic toward the final destination (e.g., this can apply to a domain identifier or a community attribute or both) [0161-165] TABLE-00002).
Regarding claim 11, LI teaches the method of claim 1, wherein the UPF and the local data network are located on the edge network of a cloud computing system (DN 242 may represent an Edge Computing network or resource, such as a Mobile Edge Computing (MEC) network [0039] FIG.1).
Regarding claim 12, LI teaches the method of claim 1, wherein the telecommunications network is a fifth generation (5G) mobile network (a service-based system architecture of a 5G Core Network [0038] FIG.2A).
Regarding claim 13, LI teaches the method of claim 1, wherein the one or more packet attributes include one or more of an origin IP address, a destination IP address, an origin IP prefix, or a destination IP prefix (The AF request may have an application identifier or traffic filtering information (e.g. 5 Tuple, indicating or including a source IP address, a source port number, a destination IP address, a destination port number and a protocol or type of protocol in use) [0059] FIG.5).
Regarding claims 14-17, the independent claim and each dependent claim are related to the same limitation set for hereinabove in claims 1-13, where the difference used is having a plurality of packet detection rules (PDRs) (LI: the UPF with packet handling instructions including PDRs and FARs for steering traffic to the local access to the data network (DN) [0086] [0132-136] FIG.6) and the wordings of the claims were interchanged within the claim itself or some of the claims were presented as a combination of two or more previously presented limitations. This change does not affect the limitation of the above treated claims. Adding these phrases to the claims and interchanging the wording did not introduce new limitations to these claims. Therefore, these claims were rejected for similar reasons as stated above.
Regarding claims 18-20 the independent claim and each dependent claim are related to the same limitation set for hereinabove in claims 1-13, where the difference used is the limitations were presented from a “system” side with a processor and a memory with instructions (LI: [0257-259] FIG.1) and the wordings of the claims were interchanged within the claim itself or some of the claims were presented as a combination of two or more previously presented limitations. This change does not affect the limitation of the above treated claims. Adding these phrases to the claims and interchanging the wording did not introduce new limitations to these claims. Therefore these claims were rejected for similar reasons as stated above.
Conclusion
When responding to this office action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections See 37 CFR 1.111 (c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDELNABI O MUSA whose telephone number is (571)270-1901, and email address is abdelnabi.musa@uspto.gov ‘preferred’. The examiner can normally be reached on M-F 9:00 am - 5:00 pm. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kevin Bates, can be reached on 571-2723980. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov Should you have questions on access to the Private PAIR system? Contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ABDELNABI O MUSA/Primary Examiner, Art Unit 2472