DETAILED ACTION
This is in response to US App. 18/660,139. Claims 1-19 have been examined.
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.
Claim Objections
Claims 1-3 and 12 -14 are objected to because of the following informalities: the phrase “SM” should be spelled out when first used. Appropriate correction is required.
Claim Rejections - 35 USC § 102
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)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-5, 7-9, 11-16, and 18-19 are rejected under 35 U.S.C. 102(a)(2) as being unpatentable by Nassar et al. (WO 2024/142023; hereafter Nassar).
Regarding Claim 1,
An apparatus for establishing a traffic path and transmitting the established traffic path in a mobile communication system, the apparatus comprising: a memory for storing at least one program; a transmitting and receiving unit for transmitting and receiving at least one signal; and a processor for executing the at least one program stored in the memory,
wherein the processor receives an SM policy association establishment request message or an SM policy association modification request message on the basis of protocol data unit (PDU) session establishment [Nassar: 0223: the UE may initiate establishment of a MA PDU session by, sending to an AMF, a request to establish a PDU session, and the AMF selecting a SMF for the requested PDU session … the SMF selection may be based, at least in part, by obtaining information regarding the SMF from a UDM; the PDU session establishment request sent by the UE to the AMF may comprise an identifier of an existing PDU session (“PDU Session ID”) for which multiple accesses is being requested],
obtains policy-related information from a unified data repository (UDR) on the basis of an SM policy association establishment request or an SM policy association modification request, and performs a policy decision on the basis of whether a previously stored policy and charging control (PCC) rule related to the PDU session establishment exists in the policy-related information, and the policy decision comprises traffic routing for each service data flow (SDF) [Nassar: 0227; when the AMF has identified a SMF for the requested PDU session (e.g., by exchanging signalling with the UDM), the AMF sends a MA PDU session creation request to the identified SMF, which may establish the MA PDU session; as part of establishing this MA PDU session, the SMF may retrieve, from a PCF, routing rules (such as ATSSS rules) for distributing traffic of a service data flow across both the 3GPP access and the non-3GPP access; 0235; the SMF may determine routing rules for distributing (e.g., switching, steering, and/or splitting) traffic of a service data flow across the access paths (i.e., legs) over the first and second accesses in response to receiving the access identifiers and recognizing that the access paths over the first and second accesses are to be used for routing traffic of a service data to and/or from the UE to a UPF of the core network for a same PDU session at a same time], and
Note:
PCF is policy control function. UDM is unified data management.
transmits an SM policy association establishment response message or an SM policy association modification response message, which comprises policy decision information, to a session management function (SMF) [Nassar: 0247; Figure 5 illustrates operations that may be performed by an apparatus for a first network function; depending on the example network configuration (as illustrated further below with reference to Figures 7 to 13), the first network function may be a session management function; 0255; the apparatus may generate the first and/or second set of rules based on policy and charging control rules obtained from a policy control function].
Note:
Policy and Charging Control is PCC.
Regarding Claim 2,
wherein in a case where the PCC rule exists in the policy-related information, the processor performs the policy decision on the basis of the PCC rule and transmits the SM policy association establishment response message or the SM policy association modification response message, which comprises the policy decision information, to the SMF [Nassar: 0416; the AMF 1104 may signal the SM signaling to the PGW-C and SMF 1106 by invoking a PDUSession_createSMcontextReq service operation; 0417; during 13006, the PGW-C and SMF 1106 notifies a PCF (not show) that a MA PDU session is to be established and obtains new ATSSS rules and MAR rules for this MA PDU session; he ATSSS rules and MAR rules may be obtained from a PCF (not shown); this PCF (not shown) may comprise the functions of the PCF described above with reference to Figure 6A; 0227; as part of establishing this MA PDU session, the SMF may retrieve, from a PCF, routing rules (such as ATSSS rules) for distributing traffic of a service data flow across both the 3GPP access and the non-3GPP access; 0247; Figure 5 illustrates operations that may be performed by an apparatus for a first network function; depending on the example network configuration (as illustrated further below with reference to Figures 7 to 13), the first network function may be a session management function; 0255; the apparatus may generate the first and/or second set of rules based on policy and charging control rules obtained from a policy control function].
Regarding Claim 3,
wherein, in a case where the PCC rule does not exist in the policy-related information, the processor generates the PCC rule, performs the policy decision on the basis of the generated PCC rule, and transmits the SM policy association establishment response message or the SM policy association modification response message, which comprises the policy decision information, to the SMF [Nassar: 0428; in all of the above examples, in order to support the possibility of distributing (e.g., switching, splitting and steering) traffic of a service data flow of a across the multiple access paths (access paths) of the MA PDU session that go through different access networks or same access networks having the same or different RATs and terminate in different mobile networks or in the same mobile network (e.g., PLMN or SNPN), new rules, policies and capabilities may be introduced for the ATSSS feature described in 3GPP standards for helping in delivering the new ATSSS rules to the UE and MAR rules to the UPF; 0429; new rules, policies, and capabilities for the ATSSS feature comprise updates to the definitions of PCC rules (PCF to SMF), updates to N4 rules (MAR rules) (SMF to UPF) and updates to ATSSS rules (SMF to UE)].
Regarding Claim 4,
wherein, in a case of the generating of the PCC rule, the processor transmits a traffic route computation request message to a routing control function (RCF), the RCF obtains topology information and load information, and performs traffic route computation for each service data flow (SDF) on the basis of the obtained topology information and load information [Nassar: topology == access paths; load information == load balancing; 0276; Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type; 0282; as another example, for the Load balancing mode, split percentage values may be defined per Leg_ID, where the percentage values over all legs sum to 100%; 0430; in the present example, it may be set to 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 or 100; it may be included when the "steerModeValue" attribute is set to "LOAD_BALANCING" ], and
generates a routing identification (RID) for each SDF, and wherein the processor receives a return of the RID, which is determined for each SDF, through a traffic route computation response message [Nassar: 0273; for example, the UE, SMF, and/or AMF may determine a Leg_ID of each path (leg) of the MA PDU Session using non-access stratum (NAS) signaling as part of an initial registration of the UE with the AMF, or during part of a session establishment procedure; 0430; legLoad Array of (legId, Indicates for each Leg_ID the traffic Uinteger) expressed in percent; in the present example, it may be set to 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 or 100; it may be included when the "steerModeValue" attribute is set to "LOAD_BALANCING"; 0436; MAR ID: this information element may uniquely identify MAR ID the MAR among all the MARs configured for that PFCP session; 0437; a Forwarding Action Rule (FAR) ID that controls the packets forwarding to a access path of the MA PDU Session; - a Weight to indicate the proportion of traffic to be forwarded by the given FAR when the Steering Mode is set to "Load Sharing"].
Regarding Claim 5,
wherein the RID returned for each SDF is comprised in the PCC rule and is transmitted to the SMF [Nassar: 0273; for example, the UE, SMF, and/or AMF may determine a Leg_ID of each path (leg) of the MA PDU Session using non-access stratum (NAS) signaling as part of an initial registration of the UE with the AMF, or during part of a session establishment procedure; 0276; Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type; 0430; legLoad Array of (legId, Indicates for each Leg_ID the traffic Uinteger) expressed in percent; in the present example, it may be set to 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 or 100; it may be included when the "steerModeValue" attribute is set to "LOAD_BALANCING"; 0436; MAR ID: this information element may uniquely identify MAR ID the MAR among all the MARs configured for that PFCP session; 0437; a Forwarding Action Rule (FAR) ID that controls the packets forwarding to a access path of the MA PDU Session; - a Weight to indicate the proportion of traffic to be forwarded by the given FAR when the Steering Mode is set to "Load Sharing"].
Regarding Claim 7,
wherein the RCF transmits a topology request message to the SMF and obtains a topology response message comprising the topology information from the SMF [Nassar: topology == paths; 0271; the above aspects introduce new control plane signaling (“signalling”) between entities such as UE, AMF, SMF, PCF, and the UPF; 0272; this signalling may comprise, for an MA PDU Session, comprising multiple (i.e., more than one) paths (legs) over each of 3GPP access and/or non-3GPP access; each path (leg) (otherwise referred to herein as an access path, an access route) has a respective identifier identifying the respective path (leg) (labelled in the below as a Leg_ID); 0276; for example, Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type; 0317; Figure 8 illustrates control plane signalling (generally referred to as signalling) that may be sent between the UE 701, the first 3GPP access network 702, the second 3GPP access network 703, AMF1704, AMF2705, SMF 706, and UPF 707 of the first network configuration to establish a MA PDU session in accordance with the second technique].
Note:
Path information (topology) is inherent in signaling between AMF, SMF, PCF, and UPF. For example, the provision of rules from PCF to SMF about steering traffic across two or more access paths is the result of having previously received path information.
Regarding Claim 8,
wherein the RCF transmits a load request message to a network data analytics function (NWDAF) or a user plane function (UPF) and obtains a load response message comprising the load information from the NWDAF or the UPF [Nassar: 0217; a 5GC may comprise at least one of any of the following network functions: … Network Data Analytics Function (NWDAF), Policy Control Function (PCF); Unified Data Management (UDM); Authentication Server Function (AUSF); an Access and Mobility Management Function (AMF); a Session Management Function (SMF) and User Plane Function (UPF); 0265; Figure 6B illustrates operations that may be performed by an apparatus for a user plane function; 0269; in any of the examples of Figures 5 to 6B, the first set of rules may be configured to allow the user plane function to apply at least one of the following policies for transmission for identified downlink traffic: whether a path over an access is allowed for the identified downlink traffic; or whether a path over an access is to act as an active path for the identified downlink traffic and, if so, a proportion of the identified downlink traffic the path over the access is to carry; or when a conditional redundant steering mode is to apply, an indication of which paths over accesses are to carry the identified downlink traffic and which paths over accesses are to carry a duplicate of at least part of the identified downlink traffic0280; for example, in Active- standby steering mode, an entity determining how data for a session is to be routed (e.g., a UE for uplink data and a UPF for downlink data) may use respective priorities associated with each access path when the active access path is not available in order to select at least one of the standby legs to be used for sending data for the session; the same priorities may be used when the entity is in in Priority-based mode when at least one access path is congested; 0281; as another example, for the Load balancing mode, split percentage values may be defined per Leg_ID, where the percentage values over all legs sum to 100%; 0271; the above aspects introduce new control plane signaling (“signalling”) between entities such as UE, AMF, SMF, PCF, and the UPF; 0272; this signalling may comprise, for an MA PDU Session, comprising multiple (i.e., more than one) paths (legs) over each of 3GPP access and/or non-3GPP access; each path (leg) (otherwise referred to herein as an access path, an access route) has a respective identifier identifying the respective path (leg) (labelled in the below as a Leg_ID); 0317; Figure 8 illustrates control plane signalling (generally referred to as signalling) that may be sent between the UE 701, the first 3GPP access network 702, the second 3GPP access network 703, AMF1704, AMF2705, SMF 706, and UPF 707 of the first network configuration to establish a MA PDU session in accordance with the second technique; 0422; the ATSSS rules and MAR rules may be obtained from a PCF (not shown); this PCF (not shown) may comprise the functions of the PCF described above with reference to Figure 6A; the PGW-C and SMF 1106 further updates the UPF 1107 with new MAR rules; the UPF 1107 may use the new MAR rules to distribute (e.g., switch, steer and/or split) the downlink traffic of a service data flow across the first access path and the second access path].
Note:
Load request and response is inherent in signaling between AMF, SMF, PCF, and UPF. For example, MAR rules provided to UPF from PCF is the result of having provided earlier load information of different paths.
Regarding Claim 9,
wherein the PCC rule comprises traffic path information, the traffic path information indicates the traffic path through an RID returned for each SDF [Nassar: 0430; legLoad Array of (legId, Indicates for each Leg_ID the traffic Uinteger) expressed in percent; in the present example, it may be set to 0, 10, 20, 30, 40, 50, 60, 70, 80, 90 or 100; it may be included when the "steerModeValue" attribute is set to "LOAD_BALANCING"; 0436; MAR ID: this information element may uniquely identify MAR ID the MAR among all the MARs configured for that PFCP session; 0437; a Forwarding Action Rule (FAR) ID that controls the packets forwarding to a access path of the MA PDU Session; - a Weight to indicate the proportion of traffic to be forwarded by the given FAR when the Steering Mode is set to "Load Sharing"], and
routing of the PDU session is performed through a segment ID (SID) of segment routing IPv6 (SRv6) in a case where the PDU session is established on the basis of the PDU session establishment [Nassar: segment ID == Leg ID; 0291; in this second technique, the network function may consider all those access paths (legs) as potentially available access paths (legs) when requesting the PCF to generate the ATSSS rules and MAR rules; 0273; for example, the UE, SMF, and/or AMF may determine a Leg_ID of each path (leg) of the MA PDU Session using non-access stratum (NAS) signaling as part of an initial registration of the UE with the AMF, or during part of a session establishment procedure; 0276; Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type; 0281; as another example, for the Load balancing mode, split percentage values may be defined per Leg_ID, where the percentage values over all legs sum to 100%; 0229; the MPTCP functionality enables the UE to transmit control protocol (TCP) packets between the UE and the UPF via a 3GPP access network, and allows the transmission of internet protocol (IP) packets between the UE and the UPF via any access network].
Regarding Claim 11,
wherein the device for establishing the traffic path and transmitting the established traffic path is a policy control function (PCF) [Nassar: 0227; as part of establishing this MA PDU session, the SMF may retrieve, from a PCF, routing rules (such as ATSSS rules) for distributing traffic of a service data flow across both the 3GPP access and the non-3GPP access; 0276; Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type].
Regarding Claims 12-16 and 18-19, which recites a method having the same claim limitations as those in claims 1-5 and 7-8 above, the same rationale of rejection as presented in claims 1-5 and 7-8 is applicable.
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.
Claim(s) 6 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Nassar in view of Wu et al. (WO 2024/152183; hereafter Wu).
Regarding Claim 6,
Nassar teaches:
wherein, … the PCC rule comprising the RID returned for each SDF is generated [Nassar: 0273; for example, the UE, SMF, and/or AMF may determine a Leg_ID of each path (leg) of the MA PDU Session using non-access stratum (NAS) signaling as part of an initial registration of the UE with the AMF, or during part of a session establishment procedure; 0276; Policy Control (PCC) rules sent by the PCF to an SMF may be defined in order to accommodate steering traffic (e.g., data) of a service data flow associated with a same PDU session across two or more access paths over accesses of the same access type (e.g., two or more 3GPP access paths or two or more non-3GPP access paths), N4 rules (e.g., updated Multi-Access Rules (MAR)) sent from the SMF to a UPF may be updated in order to accommodate the multiple paths over accesses of the same access type, and ATSSS rules sent from SMF to a UE may be updated in order to accommodate the multiple accesses paths over accesses of the same access type],
However, Nassar does not teach that the processor transmits a PCC rule storage request message to the UDR to store the generated PCC rule in the UDR.
Wu teaches:
… when the PCC rule … for each SDF is generated … the processor transmits a PCC rule storage request message to the UDR to store the generated PCC rule in the UDR [Wu: p. 24; in one implementation, the NEF may combine the operator's policy and subscription information to confirm whether the requested service feature is authorizable for an XRM service or a multi-mode data service for a single UE or a UE group and store the corresponding parameters in the UDR; if multiple UEs are involved, the NEF transmits the relevant service parameters to the PCF, and performs the corresponding authorization in each PCF, as well as the decision or update of policies and rules; the PCF stores the corresponding information in the UDR based on the authorization result of the request … if AF subscribes to the execution notification of the relevant policies of the XRM service, PCF sends the relevant The execution result is given to AF; at the same time, if there are changes to the relevant subscription parameters, PCF updates the changes to UDR, triggering the serving PCF of other UEs related to the XRM service group to execute policy changes and coordination].
It would have been obvious for POSITA before the effective filing date of the invention to combine the teachings of Nassar and Wu in order to help the transmission and control of the network and services, as well as, service assurance and user experience [Wu: p. 2].
Regarding Claim 17, which recites the same claim limitations as those in claim 6 above, the same rationale of rejection as presented in claim 6 is applicable.
Allowable Subject Matter
Claim 10 is 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Keyur et al. (US 2022/0345972) teaches that when sending out this VPNv4/v6 update for the UE route, BGP module 324 may assign a service SID for the UE route [Keyur: 0156].
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A WAQAS whose telephone number is (571)270-5642. The examiner can normally be reached 8:30 - 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, Marcus Smith can be reached at (571) 270-1096. 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.
SAAD A. WAQAS
Primary Examiner
Art Unit 2468
/Saad A. Waqas/Primary Examiner, Art Unit 2468
Prosecution Insights