DETAILED ACTION
This action is made in response to the communication filed on February 04, 2025. This action is made non-final. Claims 1 and 12 are independent claims. Claims 2, 7, 13, 16 and 21-27 were canceled. Claims 1, 3-6, 8-12, 14, 15 and 17-20 are pending.
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 .
Priority
This application is the national stage entry of PCT/CN2023/110176, filed on July 31, 2023, which claims priority to International Patent Application No. PCT/CN2022/110528, filed with the Chinese Patent Office on August 05, 2022.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on February 04, 2025 and April 10, 2026 are in compliance with the provisions of 37 CFR 1.97 and have been considered by the examiner.
Claim Objections
5. Claims 5, 17 and 20 are objected to because of the following informalities:
Claim 5 recites “an PLMN handover procedure with access and mobility management function, AMF change.” The recitation contains a grammatical error (“an PLMN”), and it appears from the parallel recitation in claim 14 (“an intra public land mobile network, PLMN handover procedure with access and mobility management function, AMF change”) that the phrase “intra public land mobile network,” was inadvertently omitted. Appropriate correction is required. For purposes of examination, the recitation is interpreted consistent with claim 14 as reciting “an intra public land mobile network, PLMN handover procedure with access and mobility management function, AMF change”.
Claim 17 recites “wherein the second session management comprises at least one of: an anchor SMF, a home SMF, or an SMF hosting session management context resource.” The word “node” appears to have been inadvertently omitted after “second session management.” Appropriate correction is required. For purposes of examination, the recitation is interpreted as “the second session management node,” consistent with claim 12 and with parallel recitation in claim 8.
Claim 20 recites “an anchor SM F requires authorization”. This recitation should read “an anchor SMF requires authorization” with no space between M and F in SMF.
Claim Rejections - 35 USC § 112
6. 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.
7. Claims 18 and 19 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 18 recites the third network node.” There is insufficient antecedent basis for this limitation in the claim. Claim 12, from which claim 18 depends, recites a session management node, a second management node, and a first network node; it does not recite a third network node. It is unclear which entity of claim 12 the recited “third network node” refers to, or whether claim 18 is intended to introduce an additional node not recited in claim 12.
Claim 19 recites “wherein the first information is sent to the third network node in at least one of: session management context create data, session management context, or user equipment context.” Claim 19 is indefinite for two reasons. First, “the third network node” lacks antecedent basis in claim 12 for the reasons set forth above with respect to claim 18. Second, claim 12 recites a method performed by the session management node comprising receiving the first information and getting a token; claim 19 recites the first information being sent to a third network node. However, it is unclear which entity performs the recited sending step, and unclear how the recited sending step further limits the method performed by the session management node of claim 12. It cannot be determined whether claim 19 intends (i) the session management node of claim 12 to forward the first information to a further node, or (ii) a recitation of the manner in which the first information was received in claim 12 (i.e., that the session management node is itself the recipient information sent in the recited data structures).
For purposes of examination, claim 19 is interpreted per alternative (ii), consistent with the corresponding recitation of claim 10 as depending from claim 1 and with the manner of receiving described in the specification (Spec: [0031]; [00128]), i.e., that the first information received in claim 12 is comprised in at least one of session management context create data, session management context, or user equipment context.
Claim Interpretation
8. Claim 1 recites “first information indicating whether a second session management node requires authorization.” Under the broadest reasonable interpretation consistent with the specification, this limitation encompasses any information element from which a recipient can determine whether an identified session management function requires authorization for access to its service. The specification identifies the oauth2Required information as an example of such information (instant specification at [0007], [0008], [0146] and [0147]), and states that oauth2Required is defined in 3GPP TS 29.510 (instant specification at [0005] and [0104]). The claim does not require that the information be generated by any particular node, and it does not require that the information be conveyed proactively rather than in response to a query.
Claim Rejections - 35 USC § 103
9. 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.
10. 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.
11. 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.
12. Claims 1, 3, 5, 6 and 8-11 are rejected under 35 U.S.C. § 103 as being unpatentable over Ericsson, (“Service Access Authorization between SMFs,” 3GPP TSG-CT WG4 Change Request C4-220445, (CR 0377 rev 1, Rel-16)), hereafter Ericsson CR, in view of 3GPP TS 29.510 V17.2.0, (“3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G System; Network Function Repository Services;” Stag3 (Release 17)), hereafter TS 29.510.
Regarding claim 1, the Ericsson CR teaches a method performed by a first network node. The Ericsson CR describes actions performed by the AMF during PDU session establishment and during handover, service request, and registration procedures involving I-SMF or V-SMF insertion, change, or removal (Reason for Change, page 1, clauses 5.2.2.2.4 – 5.2.2.2.7, pages 6-8). The Ericsson CR states that the AMF discovers and selects the H-SMF or SMF on behalf of the V-SMF or I-SMF during the PDU session establishment (Reason for Change, page 1).
The Ericsson CR teaches obtainingconcerning the identity of a second session management node. The Ericsson CR states that the AMF discovers and selects the H-SMF or SMF for the V-SMF or I-SMF via NRF discovery during PDU session establishment (Reason for Change, page 1). The Ericsson CR states that the discovery result makes the discovering consumer aware of the NF instance ID of the producer, and that the new I-SMF or V-SMF needs the NF instance ID of the peer SMF, which serves as the service producer (Reason for Change, page 1).
and sending the first information to a third network node; The Ericsson CR adds identifier of the peer SMF to the SmContextCreateData data type, and the AMF sends SmContextCreateData to the new V-SMF or I-SMF in the Create SM Context service operation (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). The stated purpose of the forwarding is to enable the recipient SMF to obtain an access token for the peer SMF (Reason for Change, page 1).
The Ericsson CR teaches token-based authorization administered by the NRF. The CR states that OAuth is introduced to enforce access control between NF service consumers and NF service producers, and that the consumer acquires an access token from the NR, which serves as the authorization server (Reason for Change, page 1). The Ericsson CR does not expressly state the OAuth version.
The Ericsson CR does not teach that the first information is information indicating whether the second session management requires authorization. The information forwarded in the CR consists of identifiers of the peer SMF. The Ericsson CR also does not expressly teach wherein the authorization comprises OAuth2-based authorization, because the CR does not state which OAuth version is used.
TS 29.510 cures this deficiency. TS 29.510 defines the oauth2Required attribute in the NFService information that a network function registers with the NRF as part of its NF profile. The definition states: “It indicates whether the NF Service Instance requires Oauth2-based authorization” (Table 6.1.6.2.3-1, page 76). The NFservice type of the Nnrf_NFDiscovery API carries the same attribute: “It indicates whether the NF Instance requires Oauth2-based authorization” (Table 6.2.6.2.4-1, page 157), confirming that the indication is part of the discovery response returned to the consumer. An SMF is a network function whose profile is registered and discovered in this manner, as SMF is among the NF types known to the NRF (TS 29.510, Table 6.1.6.3.3-1, page 120). TS 29.510 therefore teaches obtaining, available to the AMF in the NRF discovery response. The discovery service of TS 29.510 returns the profile information of the discovered producer to the requesting NF service consumer (clause 6.2.6.2.2, Table 6.2.6.2.2-1, page 150). Per the Ericsson CR, the AMF obtains the peer SMF identity from that same discovery response (Ericsson CR, Reason for Change, page 1). The specification acknowledges the same mechanism: “during NRF discovery procedure, the service consumer will get the information from the NRF whether Oauth2-based authorization is required by the service producer” (instant specification at paragraphs [0005] and [0104]).
TS 29.510 also establishes that the authorization at issue is OAuth2 based. The oauth2Required definition recites Oauth2-based authorization (Table 6.1.6.2.3-1, page 76). TS 29.510 further defines the token service of the NRF: the Access Token Request operation “is used by an NF Service Consumer to request an OAuth2 access token from the authorization server (NRF)” (clause 5.4.2.2.1, page 40-41). In the combination, the access token that the new V-SMF or I-SMF acquires from the NRF as authorization server is therefore an OAuth2 access token, and the authorization is OAuth2-based authorization, as recited in the wherein clause.
TS 29.510 is analogous art because it is from the same field of endeavor as the claimed invention, namely service registration, discovery and OAuth2-based authorization among network functions in the 5G core service-based architecture. The Ericsson CR expressly operates within the framework of TS29.510, in that the NRF of the CR is the authorization server and discovery source that TS 29.510 defines.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of the Ericsson CR such that the information the AMF forwards to the new V-SMF or ISMF in SmContextCreateData includes the oauth2Required indication of the peer SMF, as taught by TS 29.510 (Table 6.1.6.2.3-1, page 76; Table 6.2.6.2.4-1, page 157). In the combination, the AMF receives the oauth2Required attribute in the NRF discovery response together with the identity of the peer SMF, and the AMF includes that indication with the peer SMF information sent to the new V-SMF or I-SMF.
One of ordinary skill would have been motivated to make this modification so that the new V-SMF or I-SMF can determine, before sending a service request to the peer SMF, whether it must first obtain an access token. That determination is the stated function of the oauth2Required attribute (Table 6.1.6.2.3-1, page 76). The determination matters in a setting where “PDU Session establishment or relocation with V-SMF/I-SMF will failure, if Oauth is enabled” (Ericsson CR, Consequences if not approved, page 2). Ericsson’s own publication Fu et al., WO2020/141356A1 (Publication Date: July 2020) demonstrates that this motivation was recognized in the art. Fu teaches provisioning a network function in a procedure chain with authorization material concerning a node that the function will later access ([0033]), which “reduces the total latency of the Third Generation Partnership Project (3GPP) procedure… and reduces network traffic ([0023]). This document is cited as evidence of motivation and is not applied against the claims.
The modification adds a known information element, the oauth2Required attribute, to a known message, the SmContextCreateData. Each performs its established function in the combination. The result is predictable: the recipient SMF knows whether the peer SMF requires authorization before sending a request. One of ordinary skill would have had a reasonable expectation of success because the AMF receives the oauth2Required attribute in the same discovery response from which it obtains the peer SMF identity, and because the Ericsson CR itself adds new attributes to SmContextCreateData and characterizes the additions as backward compatible (Summary of Change, page 1; Other comments, page 2).
Claim 3:
Regarding claim 3, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 3 recites wherein the first information is obtained from at least one of: a network repository function, NRF, or a mobility management node. Claim 3 recites the sources in the alternative; a teaching of any one source meets the limitation. The combination set forth for claim 1 teaches the NRF alternative. The Ericsson CR states that the AMF discovers and selects the H-SMF OR SMF via NRF discovery (Reason for Change, page 1). In the combination, the oauth2Required indication is obtained from the NRF as part of the discovery response (TS 29.510, Table 6.2.6.24-1, page 157; clause 6.2.6.2.2, Table 6.2.6.2.2-1, page 150). In the combination, the first information is therefore obtained by the AMF from the NRF. The rationale for the combination is set forth in the rejection of claim 1.
Claim 5:
Regarding claim 5, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 5 recites wherein the first information is sent to the third network node during at least one of: a protocol data unit, PDU session establishment procedure with intermediate session management function, SMF, a PDU session establishment procedure in home routed roaming scenario, an PLMN handover procedure with access and mobility management function, AMF change, an intra PLMN handover procedure with visited SMF change, an inter PLMN mobility registration procedure, or an inter PLMN handover procedure. Claim 5 recites the procedures in the alternative; a teaching of any one procedure meets the limitation. The recitation “an PLMN handover procedure” is interpreted as set forth in the claim objection above. The combination set forth for claim 1 teaches the first two alternatives. The Create Sm Context service operation carrying SmContextCreate Data is used to create the SM context in the V-SMF for home routed roaming scenarios and in the I-SMF for a PDU session with an I-SMF, and it is used in the UE requested PDU session establishment procedure (Ericsson CR, clause 5.2.2.2.1, page 3). The Ericsson CR states that the AMF discovers and selects the H-SMF or SMF for the V-SMF or I-SMF during PDU session establishment (Reason for Change, page 1). In the combination, the first information is therefore sent to the new V-SMF or I-SMF during a PDU session establishment procedure with an intermediate SMF and during a PDU session establishment procedure in a home routed roaming scenario. The rationale for the combination is set forth in the rejection of claim 1.
Claim 6:
Regarding claim 6, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 6 recites wherein the first network node comprises at least one of: a source . Claim 6 recites the nodes in the alternative; a teaching of any one node meets the limitation. The combination set forth for claim 1 teach the source AMF alternative. Under the broadest reasonable interpretation consistent with the specification, a source AMF encompasses the AMF from which the first information is sent. The specification describes the AMF performing the NRF discovery and including the HsmfOauth2Required information element in the Nsmf_PDUSession_CreateSMContext request at PDU session establishment (instant specification at [0147]), and describes the S-AMF forwarding the corresponding information during the mobility procedures (instant specification at [0155] and [0169]). In the Ericsson CR, the AMF is the node that obtains the peer SMF information via NRF discovery and sends it to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). In the combination, the first network node therefore comprises a source AMF. The rationale for the combination is set forth in the rejection of claim 1.
Claim 8:
Regarding claim 8, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 8 recites wherein the second session management node comprises at least one of: an anchor SMF, a home SMF, or an SMF hosting session management context resource. Claim 8 recites the nodes in the alternative; a teaching of any one node meets the limitation. The combination set forth for claim 1 teaches the home SMF alternative and the SMF hosting session management context resource alternative. The Ericsson CR identifies the H-SMF as a peer SMF that the AMF discovers and selects for the V-SMF or I-SMF (Reason for change, page 1). Per clause 5.2.2.2.1, the NF service consumer provides the URI of the Nsmf_PDUSession service of the H-SMF for the PDU session establishment procedure in the home routed roaming scenario (Ericsson Cr, page 4). The specification states that the H-SMF is a home session management function (instant specification at [0006] and [0086]). The Ericsson CR also describes a scenario in which the new I-SMF retrieves the SM context from the old I-SMF or SMF (Reason for Change, page 1). In the mobility procedures, the Ericsson CR adds that the Create SM Context request optionally includes “the NF instance identifier of the SMF hosting the SM Context resource” (clauses 5.2.2.2.4 through 5.2.2.2.7, pages 6-8). In the combination, the second session management node comprises a home SMF or an SMF hosting session management context resource. The rationale for the combination is set forth in the rejection of claim 1.
Claim 9:
Regarding claim 9, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 9 recites wherein the third network node comprises at least one of: a target AMF, er a target visited SMF, or a target intermediate SMF. Claim 9 recites the nodes in the alternative; a teaching of any one node meets the limitation. The combination set forth for claim 1 teaches the target visited SMF and target intermediate SMF alternatives. In the Ericsson CR, the AMF sends the SmContextCreateData to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). Per clauses 5.2.2.2.4 through 5.2.2.2.7 7, the NF service consumer, e.g., the AMF, requests the new I-SMF or new V-SMF to create an SM context for I-SMF insertion or change during Xn based and N2 based handover, during a service request with I-SMF insertion or change or with V-SMF change, and during the registration procedure with I-SMF insertion or change (Ericsson CR, pages 6-8). The Ericsson CR refers to this recipient as the new V-SMF or I-SMF (Reason for Change, page 1). The specification uses “target” for the corresponding node, describing the Nsmf_PDUSession_CreateSMContext request as sent to the target V-SMF (instant specification at [0156] and [0203]). In the combination, the third network node therefore comprises a target visited or a target intermediate SMF. The rationale for the combination is set forth in the rejection of claim 1.
Claim 10:
Regarding claim 10, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 10 recites wherein the first information is sent to the third network node in at least one of: session management context create data, session management context, or user equipment context. Claim 10 recites the data structures in the alternative; a teaching of any one structure meets the limitation. The combination set forth for claim 1 teaches the session management context create data alternative. The Ericsson CR adds identifiers of the peer SMF to the SmContextCreateData data type (Summary of Change, page 1). In the Ericsson CR, the AMF sends SmContextCreateData to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). In the combination set forth for claim 1, the oauth2Required indication is included with the identifiers in SmContextCreateData. The specification states that the session management context create data may be the same as SmContextCreateData as described in the clause 6.1.6.2.2 of 3GPP TS 29.502 v17.5.0 (instant specification at [0111]). In the combination, the first information is therefore sent to the third network node in session management context create data. The rationale for the combination is set forth in the rejection of claim 1.
Claim 11:
Regarding claim 11, Ericsson CR in view of TS 29.510 teaches the limitations of claim 1 as set forth above.
Claim 11 recites wherein the first information comprises at least one of: information indicating whether a home SMF requires authorization, information indicating whether an anchor SMF requires authorization, or information indicating whether an SMF hosting session management context resource requires authorization. Claim 11 recites the content variants in the alternative; a teaching of any one variant meets the limitation. The combination set forth for claim 1 teaches the home SMF variant. The Ericsson CR identifies the H-SMF as a peer SMF that the AMF discovers and selects for the V-SMF (Reason for Change, page 1). Per clause 5.2.2.2.1, the NF service consumer provides the URI of the Nsmf_PFUSession service of the H-SMF for the PDU session establishment procedure in the home routed roaming scenario (Ericsson CR, page 4). The specification states that the H-SMF is a home session management function (instant specification at [0006] and [0086]). In the combination, the forwarded indication is the oauth2Required attribute of that H-SMF, which indicates whether the H-SMF requires OAuth2-based authorization (TS 29.510, Table 6.1.6.2.3-1, page 76; Table 6.2.6.2.4-1, page 157). In the combination, the first information therefore comprises information indicating whether a home SMF requires authorization. The rationale for the combination is set forth in the rejection of claim 1.
13. Claims 12, 14, 15 and 17-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Ericsson, (“Service Access Authorization between SMFs,” 3GPP TSG-CT WG4 Change Request C4-220445, (CR 0377 rev 1, Rel-16)), hereafter Ericsson CR, in view of 3GPP TS 29.510 V17.2.0, (“3rd Generation Partnership Project; Technical Specification Group Core Network and Terminal; 5G System; Network Function Repository Services;” Stag3 (Release 17)), hereafter TS 29.510, and further in view of Qi et al. (US 2021/0250344 A1), hereafter Qi.
The interpretation of “first information indicating whether a second session management node requires authorization” set forth in the Claim Interpretation section applies equally to the identical term in claim 12.
Regarding claim 12, the Ericsson CR teaches a method performed by a session management node. The Create SM Context service operation of the Ericsson CR is used to create the SM context in the V-SMF for home routed roaming scenarios or in the I-SMF for a PDU session with an I-SMF (Ericsson CR, clause 5.2.2.2.1, page 3). The Ericsson CR states that the new I-SMF or V-SMF needs to get an access token to access the service on the H-SMF, the SMF, or the old I-SMF (Reason for Change, page 1).
The Ericsson CR teaches receiving first information concerning the identity of a second session management node from a first network node. The Ericsson CR adds identifiers of the peer SMF to the SmContextCreate Data datatype, and the AMF sends SmContextCreate Data to the new V-SMF or I-SMF in the Create SM Context service operation (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). The new V-SMF or I-SMF is the session management node that receives this information, and the AMF is the first network node.
getting a token for accessing the second session management node; The Ericsson CR states that the new I-SMF or V-SMF needs to get an access token to successfully access the service on the peer SMF, and that the consumer acquires the access token from the NRF, which serves as the authorization server (Reason for Change, page 1). The Ericsson CR does not expressly state the OAuth version.
The Ericsson CR does not teach that the received information is information indicating whether the second session management node requires authorization. The information received in the Ericsson CR consists of identifiers of the peer SMF. The Ericsson CR also does not expressly teach wherein the authorization comprises OAuth20based authorization, because the CR does not state which OAuth version is used. The Ericsson CR further does not expressly teach getting the token when the first information indicates the second session management node requires authorization.
TS 29.510 cures the first two deficiencies. TS 29.510 defines the oauth2Required attribute, which “indicates whether the NF service Instance requires Oauth2-based authorization” (Table 6.1.6.2.3-1, page 76; see also Table 6.2.6.2.4-1, page 157). The attribute is carried in the NRF discovery response (Table 6.2.6.2.4-1, page 157; clause 6.2.6.2.2, Table 6.2.6.2.2-1, page 150). Per the Ericsson CR, the AMF obtains the peer SM identity from that same discovery response (Ericsson CR, Reason for Change, page 1). The specification acknowledges the same mechanism: “during NRF discovery procedure, the service consumer will get the information from the NRF whether Oauth2-based authorization is required by the service producer” (instant specification at paragraphs [0005] and [0104]).
TS 29.510 is analogous art because it is from the same field of endeavor as the claimed invention, namely service registration, discovery and OAuth2-based authorization among network functions in the 5G core service-based architecture.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of the Ericsson CR to include the oauth2Required indication of the peer SMF with the peer SMF information the AMF sends to the new V-SMF or I-SMF, as taught by TS 29.510 (Table 6.1.6.2.3-1, page 76; Table 6.2.6.2.4-1, page 157). One of ordinary skill would have been motivated to make this modification so that the new V-SMF or I-SMF can determine, before sending a service request to the peer SMF, whether it must first obtain an access token. That determination is the stated function of the oauth2Required attribute (Table 6.1.6.2.3-1, page 76). The determination matters in a setting where “PDU Session establishment or relocation with V-SMF/I-SMF will failure, if Oauth is enabled” (Ericsson CR, Consequences if not approved, page 2). In this combination, the information the new V-SMF or I-SMF receives from the AMF is first information indicating whether the second session management node requires authorization. The authorization is OAuth2-based authorization because the Access Token Request operation of TS 29.510 “is used by an NF Service Consumer to request an OAuth2 access token from the authorization server (NRF)” (clause 5.4.2.2.1, page 40-41).
The modification adds a known information element, the oauth2Required attribute, to a known message, the SmContextCreateData. Each performs its established function in the combination. The result is predictable: the recipient SMF knows whether the peer SMF requires authorization before sending a request. One of ordinary skill would have had a reasonable expectation of success because the AMF receives the oauth2Required attribute in the same discovery response from which it obtains the peer SMF identity, and because the Ericsson CR itself adds new attributes to SmContextCreateData and characterizes the additions as backward compatible (Summary of Change, page 1; Other comments, page 2).
Neither the Ericsson CR nor TS 29.510 expressly describes the session management node getting the token in response to the information received from the first network node.
Qi cures this deficiency. Qi describes a PDU session establishment procedure in a 5G system in which “an access and mobility management function is a client, a visited session management function is a first sever, a home session management function is a second server, and a network repository function is an authorization server” (Qi, [0207]). Qi teaches that the client may send an instance identifier or a resource identifier of the second server to the first server, “and then the first server applies for, based on the instance identifier or the resource identifier of the second server, the access token for accessing the second server” ([0130]; see also [0013]). In Qi’s example, the visited session management function receives the instance identifier of the home session management function from the access and mobility management function in step S1003A ([0211] and [0216]). The visited session management function then sends an access token request message to the network repository function, and the request carries the instance identifier of the home session management function “obtained from S1003A” ([0215] and [0216]). The network repository function generates the access token and sends an access token response message to the visited session management function ([0217]). The visited session management function then sends the session establishment request message carrying the access token to the home session management function ([0221]). Qi therefore teaches a session management node that receives information concerning a second session management node from a first network node, and based on the received information, gets a token for accessing the second session management node.
Qi is analogous art because it is from the same field of endeavor as the claimed invention, namely service authorization among network functions in the 5G core service-based architecture using access tokens issued by the NRF. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of the Ericsson CR and TS 29.510 such that the new V-SMF or I-SMF, upon receiving the information sent by the AMF, gets the access token for the peer SMF, as taught by Qi ([0130], [0207], [0215] and [0216]). In the combination, the received indication determines whether the token acquisition step applies, which is the stated function of the oauth2Required attribute (TS 29.510, Table 6.1.6.2.3-1, page 76).
One of ordinary skill would have been motivated to make this modification because doing so “can resolve a problem that…the first server fails to obtain service authorization to access the second server, so as to reduce a security risk of a service-based network” (Qi, [0008]). The modification applies a known sequence to a known method. The result is predictable: the recipient SMF holds the token it needs before sending the service request to the peer SMF. One of the ordinary skills would have had a reasonable expectation of success because Qi describes the same four nodes performing the same PDU session procedure as the Ericsson CR (Qi, [0207] - [0222]), and the modification asks the recipient node of the Ericsson CR to perform the sequence that Qi’s visited session management function already performs.
Claim 14:
Regarding claim 14, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 14 recites wherein the first information is received from the first network node during at least one of: a protocol data unit, PDU session establishment procedure with intermediate session management function, SMF, a PDU session establishment procedure in home routed roaming scenario, an intra public land mobile network, PLMN handover procedure with access and mobility management function, AMF change, an intra PLMN handover procedure with visited SMF change, an inter PLMN mobility registration procedure, or an inter PLMN handover procedure.
Claim 14 recites the procedures in the alternative; a teaching of any one procedure meets the limitation. The combination set forth for claim 12 teaches the first two alternatives. The Create SM Context service operation carrying SmContextCreate Data is used to create the SM context in the V-SMF for home routed roaming scenarios and in the I-SMF for a PDU session with an I-SMF, and it is used in the UE requested PDU session establishment procedure (Ericsson CR, clause 5.2.2.2.1, page 3). The Ericsson CR states that the AMF discovers and selects the H-SMF or SMF for the V-SMF or I-SMF during PDU session establishment (Reason for Change, page 1). In the combination, the new V-SMF or I-SMF therefore receives the first information from the AMF during a PDU session establishment procedure with an intermediate SMF and during a PDU session establishment procedure in a home routed roaming scenario. The rationale for the combination is set forth in the rejection of claim 12.
Claim 15:
Regarding claim 15, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 15 recites wherein the first network node comprises at least one of: a source . Claim 15 recites the nodes in the alternative; a teaching of any one node meets the limitation. The combination set forth for claim 12 teach the source AMF alternative. Under the broadest reasonable interpretation consistent with the specification, a source AMF encompasses the AMF from which the first information is sent. The specification describes the AMF performing the NRF discovery and including the HsmfOauth2Required information element in the Nsmf_PDUSession_CreateSMContext request at PDU session establishment (instant specification at [0147]), and describes the S-AMF forwarding the corresponding information during the mobility procedures (instant specification at [0155] and [0169]). In the Ericsson CR, the AMF is the node that obtains the peer SMF information via NRF discovery and sends it to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). In the combination, the first network node therefore comprises a source AMF. The rationale for the combination is set forth in the rejection of claim 12.
Claim 17:
Regarding claim 17, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 17 recites wherein the second session management comprises at least one of: an anchor SMF, a home SMF, or an SMF hosting session management context resource. The recitation “the second session management” is interpreted as “the second session management node,” as set forth in the claim objection above. Claim 17 recites the nodes in the alternative; a teaching of any one node meets the limitation. The combination set forth for claim 12 teaches the home SMF alternative and the SMF hosting session management context resource alternative. The Ericsson CR identifies the H-SMF as a peer SMF that the AMF discovers and selects for the V-SMF or I-SMF (Reason for change, page 1). Per clause 5.2.2.2.1, the NF service consumer provides the URI of the Nsmf_PDUSession service of the H-SMF for the PDU session establishment procedure in the home routed roaming scenario (Ericsson CR, page 4). The specification states that the H-SMF is a home session management function (instant specification at [0006] and [0086]). The Ericsson CR also describes a scenario in which the new I-SMF retrieves the SM context from the old I-SMF or SMF (Reason for Change, page 1). In the mobility procedures, the Ericsson CR adds that the Create SM Context request optionally includes “the NF instance identifier of the SMF hosting the SM Context resource” (clauses 5.2.2.2.4 through 5.2.2.2.7, pages 6-8). In the combination, the second session management node comprises a home SMF or an SMF hosting session management context resource. The rationale for the combination is set forth in the rejection of claim 12.
Claim 18:
Regarding claim 18, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 18 recites wherein the third network node comprises at least one of: a target AMF, or a target SMF. Claim 18 stands rejected under 35 U.S.C. 112(b) above, and the prior art is applied to the claim as best understood. For purposes of applying prior art, “the third network node” is interpreted as the node to which the first information is directed. This interpretation is consistent with claim 9, which recites the corresponding limitation as depending from claim 1, and with the specification, which describes the Nsmf_PDUSession_CreateSMContext request as sent to the target V-SMF (instant specification at [0156] and [0203]).
Claim 18 recites the nodes in the alternative; a teaching of any one node meets the limitation. Under this interpretation, the combination set forth for claim 12 teaches the target SMF alternative. In the Ericsson CR, the AMF sends the SmContextCreateData to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). Per clauses 5.2.2.2.4 through 5.2.2.2.7, the NF service consumer, e.g., the AMF, requests the new I-SMF or new V-SMF to create an SM context for I-SMF insertion or change during Xn based and N2 based handover, during a service request with I-SMF insertion or change or with V-SMF change, and during the registration procedure with I-SMF insertion or change (Ericsson CR, pages 6-8). The CR refers to this recipient as the new V-SMF or I-SMF (Reason for Change, page 1), and the specification uses “target” for the corresponding node (instant specification at [0156] and [0203]). In the combination, the third network node therefore comprises a target SMF. The rationale for the combination is set forth in the rejection of claim 12.
Claim 19:
Regarding claim 19, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 19 recites wherein the first information is sent to the third network node in at least one of: session management context create data, session management context, or user equipment context. Claim 19 stands rejected under 35 U.S.C. 112(b) above, and the prior art is applied to the claim as best understood. For purposes of applying prior art, claim 19 is interpreted per the interpretation set forth in the rejection under 35 U.S.C. 112(b), namely that the first information received in claim 12 is comprised in at least one of the recited data structures. Claim 19 recites the data structures in the alternative; a teaching of any one structure meets the limitation.
Under this interpretation, the combination set forth for claim 12 teaches the session management context create data alternative. The Ericsson CR adds identifiers of the peer SMF to the SmContextCreateData data type (Summary of Change, page 1). In the Ericsson CR, the AMF sends SmContextCreateData to the new V-SMF or I-SMF (Reason for Change, page 1; Summary of Change, page 1; clause 5.2.2.2.1, page 3). In the combination set forth for claim 12, the oauth2Required indication is included with the identifiers in SmContextCreateData, and the new V-SMF or I-SMF receives it in that data structure. The specification states that the session management context create data may be the same as SmContextCreateData as described in the clause 6.1.6.2.2 of 3GPP TS 29.502 v17.5.0 (instant specification at [0111]). In the combination, the first information is therefore received to the third network node in session management context create data. The rationale for the combination is set forth in the rejection of claim 12.
Claim 20:
Regarding claim 20, Ericsson CR in view of TS 29.510 and Qi teaches the limitations of claim 12 as set forth above.
Claim 20 recites wherein the first information comprises at least one of: information indicating whether a home SMF requires authorization, information indicating whether an anchor SM F requires authorization, or information indicating whether an SMF hosting session management context resource requires authorization. Claim 11 recites the content variants in the alternative; a teaching of any one variant meets the limitation. The combination set forth for claim 12 teaches the home SMF variant. The Ericsson CR identifies the H-SMF as a peer SMF that the AMF discovers and selects for the V-SMF (Reason for Change, page 1). Per clause 5.2.2.2.1, the NF service consumer provides the URI of the Nsmf_PFUSession service of the H-SMF for the PDU session establishment procedure in the home routed roaming scenario (Ericsson CR, page 4). The specification states that the H-SMF is a home session management function (instant specification at [0006] and [0086]). In the combination, the received indication is the oauth2Required attribute of that H-SMF, which indicates whether the H-SMF requires OAuth2-based authorization (TS 29.510, Table 6.1.6.2.3-1, page 76; Table 6.2.6.2.4-1, page 157). In the combination, the first information therefore comprises information indicating whether a home SMF requires authorization. The rationale for the combination is set forth in the rejection of claim 12.
14. Claim 4 is rejected under 35 U.S.C. § 103 as being unpatentable over the Ericsson CR in view of TS 29.510 as applied to claims 1 and 3, and further in view of Applicant Admitted Prior Art, hereafter AAPA.
Regarding claim 4, Ericsson CR in view of TS 29.510 teaches the limitations of claims 1 and 3 as set forth above.
Claim 4 recites wherein in inter public land mobile network PLMN, mobility registration procedure or inter PLMN handover procedure, the first information is obtained from the NRF. The combination set forth for claims 1 and 3 obtains the first information from the NRF, as set forth in the rejection of claim 3. The specification acknowledges that, in the existing solution, the oauth2Required information of a network node can be only obtained from NRF (instant specification at [0007]). Per clause 5.2.2.2.1, the Create SM Context service operation is used in mobility procedures, including handover of a PDU session when the target AMF is not in the PLMN of the N31WF, and the registration procedure for a UE with a PDU session with V-SMF insertion, change and removal (Ericsson CR, page 3). The Ericsson CR describes a home routed roaming scenario involving an H-SMF and a V-SMF (Reason for Change, page 1; clause 5.2.2.2.1, pages 3-4).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to apply the combination set forth for claims 1 and 3 in an inter PLMN mobility registration procedure and in an inter PLMN handover procedure. One of ordinary skills would have been motivated to do so because the authorization at issue arises in the inter PLMN setting; the specification acknowledges that the H-SMF in the HPLMN may require OAuth2-based authorization for requests from the V-SMF in the N16 interface (instant specification at [0089]). The Ericsson CR addresses the mobility registration and handover procedures with V-SMF insertion or change (clause 5.2.2.2.1, page 3), and such procedures include those in which the UE moves between PLMNs, as illustrated by the Ericsson CR’s handover case in which the target AMF is not in the PLMN of the N3IWF (clause 5.2.2.2.1, p. 3). In such a procedure, the first information is obtained from the NRF for the reasons acknowledged above (instant specification at [0007]). Applying the combination in the inter PLMN procedures recited in claim 4 yields the predictable result that the new V-SMF or I-SMF obtains the indication even when the UE moves between PLMNs. One of ordinary skill would have a reasonable expectation of success because the Create SM Context service operation and SmContextCreateData are used in the same manner across procedures of clause 5.2.2.2.1, including the case in which the target AMF is not in the PLMN of the N3IWF (Ericsson CR, p. 3).
Conclusion
15. The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Rodrigo et al. (WO 2022/089781 A1) describes a network node receiving a message comprising information indicative of whether a security feature, such as an access token, is required, and acquiring the security feature from a network repository function when it is required.
16. Any inquiry concerning this communication or earlier communications from the examiner should be directed to BIN QING ZHENG whose telephone number is (703)756-1535. The examiner can normally be reached on M-F at 10:00 am - 06:00 pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Philip J. Chea can be reached on 571-272-3951. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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.
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.
/BIN QING ZHENG/
Examiner, Art Unit 2499
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights