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
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 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.
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 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.
Claims 1 – 20 are rejected under 35 U.S.C. 103 as being unpatentable over 3GPP (3GPP TS 133 501 V17.7.0 (3GPP)) in view of Rodrigo (US 2023/0283470 A1) and Singh (US 2022/0294775 A1).
Per claim 1, 3GPP suggests a network repository function CNRF) network function device, comprising: one or more processors configured to (reads on "The Network Repository Function CNRF) receives NF Discovery Request from an NF instance, provides the information of the discovered NF instances to the NF instance, and maintains NF profiles," see 3GPP §5.9.2.2):
receive an access token request (reads on "The SCP sends an access token request (Nnrf_AccessToken_Get Request) to the NRF," see 3GPP §13.4.1.3.2 Step 3- The Examiner asserts the NRF is the named recipient ("to the NRF") of the SCP's "access token request," so the NRF necessarily performs the recited "receive an access token request") from a service communication proxy (SCP) network function device (reads on "The SCP sends an access token request (Nnrf AccessToken Get Request) to the NRF," see 3GPP §13.4.1.3.2 Step 3), wherein the access token request is associated with a first network function device (reads on "an access token request sent by SCP on behalf of a certain NF Service Consumer," see 3GPP §13.3.1.2 NOTE 3);
validate the access token request (reads on "The NRF authenticates the NF Service Consumer using one of the methods described in clause 13.3.1.2," see 3GPP §13.4.1.3.2 Step 4-The Examiner asserts Step 4 recites the NRF authenticating the NF Service Consumer and then conditioning token issuance on that authentication plus authorization, which under BRI is the NRF "validat[ing] the access token request-" Step 4 makes authentication-and-authorization the express precondition to issuing the token, which is precisely request validation- The Examiner further asserts under BRI, "validate the access token request" encompasses the NRF's determination that the request (and its asserted consumer identity) is authentic and authorized-"The NRF authenticates the NF Service Consumer ... If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy" (see 3GPP §13.4.1.3.2 Step 4) reads on this limitation because authenticating the consumer that the request carries, and confirming authorization, is the act of validating the request) based on a client credentials assertion (CCA) token (reads on "Client credentials assertion (CCA) based authentication as specified in clause 13.3.8," see 3GPP §13.3.1.2) associated with the first network function device (reads on the CCA shall include the NF instance ID of the NF Service Consumer (subject), which binds the CCA verbatim to the consumer NF (the first network function device) see 3GPP §13.3.8.2); and
transmit, to the SCP network function device (reads on "The NRF sends the access token to the SCP in an access token response (Nnrf_AccessToken_Get Response)," see 3GPP §13.4.1.3.2 Step 5) and based on validating the access token request (reads on "If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token," see 3GPP §13.4.1.3.2 Step 4), an access token associated with the first network function device (reads on "The NRF uses the NF Service Consumer instance ID as the subject of the access token," see 3GPP §13.4.1.3.2 Step 4),wherein the access token is for accessing a second network function device (reads on "The SCP sends the service request to the NF Service Producer. The service request includes an access token," see 3GPP §13.4.1.3.2 Step 6. The Examiner asserts the access token accompanies the service request to the "NF Service Producer," which is the recited "second network function device" the token is "for accessing"). The prior art is silent on explicitly stating one or more processors and wherein the access token request is associated with a first network function device.
Singh (US 2022/0294775 A1) is relied upon to teach one or more processors (see Singh para 0081- The Examiner asserts Singh shows that a 5G NF is conventionally realized as "at least one processor 600 and a memory 602").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the NRF-and-SCP access-token procedure of 3GPP §13.4.1.3.2 by integrating the SCP delegated-authorization client-proxy teaching of Singh (see Singh para [0012]: "A method for delegated authorization at a service communications proxy (SCP) includes intercepting, from a first consumer network function CNF) that does not support access-token-based authorization, a service based interface CSBI) service request- The method further includes operating as an access token authorization client proxy to obtain a first access token on behalf of the first consumer NF") to realize the instant limitations directed to an NRF that, on the basis of a CCA token, issues to the SCP an access token associated with the first network function device for accessing a second network function device- One or more of the underpinning rationale(s), as discussed in KSR see MPEP 2141 {A, C, D, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have implemented the recited NRF as a conventional processor-and-memory 5G node that receives the SCP's delegated access token request and issues the consumer-NF-scoped access token, by applying the SCP as access token authorization-client-proxy design of Singh in which the SCP obtains an access token on behalf of a consumer NF to the existing NRF token issuance side of the 3GPP procedure. The combined system thereby completing the delegated-authorization round trip (SCP requests, NRF validates and issues) without altering the NRF's fundamental authorization-and-issuance mode of operation. As Singh itself states: "Referring to FIG. 6, SCP 101A includes at least one processor 600 and a memory 602. SCP 101A further includes an access token authorization client proxy 604 for performing the operations described above with regard to FIG. 4 for the delegated discovery case of obtaining an Auth 2.0 access token on behalf of a consumer NF that does not support Auth 2.0 authorization" (see Singh para [0081], marker line 1367; "processor 600 and a memory 602" at line 1371)), which addresses the well-recognized technical problem of enabling a consumer NF that does not itself support access-token-based (OAuth 2-0) authorization to nonetheless obtain and use access tokens through a delegating proxy. One of ordinary skill in the art in 5G core-network security would have recognized that 3GPP's base procedure presupposes, but does not itself fully specify, the SCP-side delegated client-proxy behavior that drives the access token request to the NRF, and that Singh's proven SCP-as-client-proxy model - embodied in the numbered processor/memory architecture of FIG. 6 - was a known, predictable solution to exactly that gap, requiring no change to the NRF's existing CCA-validation and token-issuance operations under §13.3.1.2 and 13.4.1.1. The combination is further supported by MPEP 2141 Rationale A (combining prior-art elements according to known methods to yield predictable results), Rationale C (use of a known technique to improve similar devices in the same way), and Rationale D (applying a known technique - delegated proxy authorization - to a known device, the NRF, ready for improvement to yield predictable results), with Rationale G (teaching, suggestion, or motivation) supplied by Singh's express incorporation by reference of 3GPP (Singh para [0012] and [0096]); neither reference disparages or directs one of ordinary skill in the art away from the combination, and the rejection relies only on the[AltContent: ] client-proxy role (consumer-side delegation to obtain a token from the NRF), which presupposes an Auth-capable token-issuing NRF exactly as claimed (see Singh para [0081]). Singh therefore does not disparage or teach away from an Auth-capable NRF that issues the access token. The motivation to combine is applied to all claims beneath this heading.
Rodrigo (US 2023/0283470 A1) is relied upon to teach a network repository function (NRF) network function device, comprising: one or more processors see Rodrigo para [0080]); and the access token request is associated with a first network function device (reads on the SCP obtaining "an access token on behalf of the first NF node 20", see Rodrigo para [0011]).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify the indirect-communication access-token-request procedure of 3GPP §13.4.1.3.2 (in which an SCP sends an access token request to the NRF on behalf of a consumer NF) by integrating the client-credentials-assertion-via-SCP delegation teaching of Rodrigo (see Rodrigo para [0007]: "The use of client credentials assertions is discussed in 3GPP ... particularly in section 13.3.1.2") to realize the instant limitations directed to an NRF that validates an SCP-borne access token request on the basis of a CCA token associated with the first network function device. One or more of the underpinning rationale(s), as discussed in KSR MPEP 2141 {A, C, G}, support this conclusion. Accordingly, it would have been obvious to one of ordinary skill in the art to have the NRF of 3GPP receive and evaluate an SCP-originated access token request carrying client-credentials-assertion information identifying the consumer NF on whose behalf the SCP acts, exactly as recited in the instant claims, by applying the indirect-communication delegation pattern of Rodrigo - in which the consumer NF's signed CCA travels through the SCP to the receiving endpoint - to the existing NRF access-token-issuance procedure of 3GPP, the combined system thereby authorizing and issuing an access token in response to the SCP request without altering the NRF's underlying authorization-and-issuance mode of operation. As Rodrigo itself states: "Thus in systems using indirect communication, a subsequent request for a service, after a first request that provided discovery parameters to a SCP node to allow selection, is not able to be proceeded by the SCP node, The SCP node cannot find a valid stored access token and does not have enough information to be able to request a new access token", see Rodrigo para [0017] which addresses the well-recognized technical problem of token-acquisition failure in indirect (SCP-mediated) 5G service communication, where the SCP lacks a valid stored access token and sufficient information to obtain a new one. One of ordinary skill in the art in 5G core-network security would have recognized that 3GPP's base procedure does not itself spell out the consumer-identifying delegation signal that lets the NRF issue a token for the correct consumer NF behind the SCP, and that Rodrigo's proven CCA-through-SCP mechanism was a known, predictable solution to exactly that gap, requiring no change to the NRF's existing token-generation and signing operations under §13.4.1.1. The combination is further supported by MPEP 2141 Rationale A (combining prior-art elements according to known methods to yield predictable results) and Rationale C (use of a known technique to improve similar devices in the same way), with Rationale G (some teaching, suggestion, or motivation in the art) further supplied by Rodrigo's own express cross-citation to 3GPP §13.3.1.2 for the CCA mechanism, The motivation to combine these references is grounded in their shared 5G indirect-communication architecture and in Rodrigo's explicit invocation of the same 3GPP CCA framework, and neither reference disparages or directs one of ordinary skill in the art away from the combination, The motivation to combine is applied to all claims beneath this heading.[AltContent: ]
Per claim 2, the prior art of record further suggests wherein the CCA token is based on (reads on the CCA's mandatory audience content of "The CCA shall include: The NF type of the expected audience (audience), i.e. the type 'NRF' and/or the NF type of the NF Service Producer," see 3GPP §13.3.8.2, as scoped to the SCP-relay procedure by "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'," see 3GPP §13.4.1.3.2 Step 1- The Examiner asserts under the patentee's controlling lexicography (para [0030]: "based on the SCP"= the CCA "includ[ing] an SCP identifier"; para [0113]: "based on"= "based, at least in part, on"), the limitation "the CCA token is based on the SCP" requires no SCP-signing or SCP-key-binding - only that the CCA content be partly determined by the SCP. 3GPP §13.3.8.2 mandates the CCA's audience field, and §13.4.1.3.2 Step 1 conditions that field's mandated dual content specifically on the SCP-relay delegated-discovery procedure, so the CCA content is "based, at least in part, on" the SCP within that procedure. The applicant's own definitional choice forecloses a narrower construction, so the standard's procedure-scoped audience content reads on "the CCA token is based on the SCP") the SCP network function device (reads on "an access token request sent by SCP on behalf of a certain NF Service Consumer," see 3GPP §13.3.1.2 NOTE 3. The Examiner asserts 3GPP recites the SCP as the network function relaying the request/CCA, mapping onto "the SCP network function device" on which the CCA is based, and under BRI, "the SCP network function device" is the standardized SCP node. "An access token request sent by SCP on behalf of a certain NF Service Consumer" (see 3GPP §13.3.1.2 NOTE 3) reads on this because the SCP is the named network function in the relay).
Per claim 3, the prior art of record further suggests the CCA token includes (reads on "The CCA shall include: the NF instance ID of the NF Service Consumer (subject); A timestamp (iat) and an expiration time (exp), and The NF type of the expected audience (audience)," see 3GPP §13.3.8.2) an SCP identifier (reads on "The CCA shall include: ... The NF type of the expected audience (audience), i.e. the type 'NRF' and/or the NF type of the NF Service Producer," see 3GPP §13.3.8.2, as scoped to the SCP-relay procedure by "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'," see 3GPP §13.4.1.3.2 Step 1) associated with the SCP network function device (reads on "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'," see 3GPP §13.4.1.3.2 Step 1. The Examiner asserts under Applicant’s controlling lexicography, the SCP identifier is one "associated with the SCP 202" (para [0030]), and 3GPP §13.4.1.3.2 Step 1 conditions the in-CCA audience content on the SCP being in the delegation chain, so the in-CCA value is "associated with the SCP network function device" Step 1's "shall contain" requirement is triggered by, and thus tied to, the SCP-relay procedure, satisfying Applicant’s defined association).
Per claim 4, the prior art of record further suggests determine that the access token request is from the SCP network function device (reads on the indirect communication the NRF's hop-by-hop counterparty is the SCP per the "Implicit ... between SCP and NRF" authentication leg, and Step 3 names the SCP as the request sender, so the NRF ascertains (determines) the request is from the SCP-mediated hop. This is the correct SCP-NRF leg - so the determination rests on an authenticated SCP counterparty. The Examiner further asserts under BRI, "determine that the access token request is from the SCP" encompasses the NRF ascertaining that the request arrived over the authenticated SCP➔NRF hop. "Implicit, i.e. by relying on authentication between NF Service Consumer and SCP, and between SCP and NRF, provided by the hop-by-hop security protection" (see 3GPP §13.3.1.2), combined with Step 3's SCP-as-sender, reads on this because the NRF's authenticated hop counterparty is the SCP); and validate the access token request based on determining that the access token request is from the SCP network function device (reads on "If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token," see 3GPP §13.4.1.3.2 Step 4. The Examiner asserts Step 4 conditions validation/issuance on the §13.3.1.2 authentication outcome, which in the indirect path is the determination that the request is from the SCP-mediated channel, mapping onto validating "based on determining that the access token request is from the SCP").
Claim 5 is analyzed with respect to claim 4. The prior art of record further suggests determine that the CCA token includes an SCP identifier associated with the SCP network function device (reads on "It checks that the audience claim in the CCA matches its own type," see 3GPP §13.3.8.3, where the audience content is the SCP-relay-procedure value mandated by "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'," see 3GPP §13.4.1.3.2 Step 1. The Examiner further asserts the in-CCA audience value mandated for the SCP-relay procedure is "an SCP identifier", and the NRF's §13.3.8.3 audience-claim check is the act by which the NRF "determines" the CCA "includes" that value. §13.4.1.3.2 Step 1 mandates the audience content specifically for the delegated-discovery (SCP-relay) procedure, tying it to the SCP); and validate the access token request based on determining that the CCA token includes the SCP identifier associated with the SCP network function device (reads on "If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token," see 3GPP §13.4.1.3.2 Step 4. The Examiner further asserts Step 4's AND-conjunctive gate ("authentication is successful and ... authorized") conditions issuance on both the SCP-origin determination and the CCA-audience verification, mapping onto the claim's two-conjunct "based on determining ... and based on determining").
Per claim 6, the prior art of record further suggests determine that the access token request includes an indication that service authorization for the first network function device is delegated to the SCP network function device (reads on "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'" (Step 1) read with "The NRF authenticates the NF Service Consumer using one of the methods described in clause 13.3.1.2" (Step 4), within the "Authorization for indirect communication with delegated discovery procedure," see 3GPP §13.4.1.3.2 Steps 1, 3 and 4. The Examiner asserts the "indication ... delegated to the SCP" is defined broadly to include "a particular value in a field in the service request", and within §13.4.1.3.2's "delegated discovery procedure" Step 1 mandates the in-CCA audience field as exactly such a procedure-specific in-field value. Step 3 carries the SCP-originated request, and Step 4 recites "The NRF authenticates the NF Service Consumer," i.e., the NRF's act of evaluating the incoming request and its mandated fields, so the NRF determines the request includes that delegation indication);
determine, based on determining that the access token request includes the indication that service authorization for the first network function device is delegated to the SCP network function device, that the access token request is from the SCP network function device (reads on "Implicit, i.e. by relying on authentication between NF Service Consumer and SCP, and between SCP and NRF, provided by the hop-by-hop security protection at the transport layer, NDS/IP, or physical security," see 3GPP §13.3.1.2. The Examiner asserts gated by the delegation-indication determination (6/A), the NRF determines the request is from the SCP via the authenticated SCP-NRF hop with the SCP as the Step 3 sender. The rejection relies on the SCP-NRF leg, so the determination rests on an authenticated SCP counterparty. Step 3 establishes the SCP as the sender within the delegated procedure recognized at 6/A; and under BRI, this is the NRF's SCP-origin determination performed because the delegation indication was determined, ascertained over the authenticated SCP-NRF hop. "Implicit, i.e. by relying on authentication between NF Service Consumer and SCP, and between SCP and NRF, provided by the hop-by-hop security protection" (see 3GPP §13.3.1.2) plus Step 3's SCP-as-sender reads on this);
determine, based on determining that the access token request includes the indication that service authorization for the first network function device is delegated to the SCP network function device, that the CCA token includes an SCP identifier associated with the SCP network function device (reads on "It checks that the audience claim in the CCA matches its own type," see 3GPP §13.3.8.3, where the audience content is the SCP-relay-procedure value mandated by "If the CCA is included, the NF type of the expected audience in CCA shall contain 'NRF' and 'NF Service Producer'," see 3GPP §13.4.1.3.2 Step 1. The Examiner asserts gated by the[AltContent: ] delegation-indication determination (6/A), the NRF's §13.3.8.3 audience-claim check evaluates the in-CCA value that §13.4.1.3.2 Step 1 mandates for the SCP-relay procedure, which is "an SCP identifier," so the NRF determines the CCA includes it); and validate the access token request based on determining that the access token request is from the SCP network function device and based on determining that the CCA token includes the SCP identifier associated with the SCP network function device (reads on "If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token," see 3GPP §13.4.1.3.2 Step 4. The Examiner asserts Step 4's AND-conjunctive gate conditions issuance on both determinations (SCP-origin and CA-audience), maps onto the claim's two-conjunct validation. Step 4 expressly requires both conditions before issuance. The Examiner further asserts Rodrigo para [0012]: "the first SCP node 10 sends an access token request to the NRF 60, The access token request includes some of parameters from the discovery parameters received in the request (see arrow 604) and may also include other information from the first SCP node 10 such as the scope (one or multiple services)" - confirms SCP supplied parameters accompany the request as the delegation/identifying signal evaluated by the NRF).
Per claim 7, the prior art of record further suggests generate the access token (reads on "the NRF shall then generate an access token with appropriate claims included," see 3GPP §13.4.1.1) based on validating the access token request (reads on "If NF Service Consumer authentication is successful and the NF Service Consumer is authorized based on the NRF policy, the NRF issues an access token," see 3GPP §13.4.1.3.2 Step 4).
Claims 8 – 14 the non-transitory computer-readable medium (see Rodrigo para [0031], [0048], [0063], and [0145]) are analyzed with respect to claims 1- 7 respectively.
Claims 15 – 20 are analyzed with respect to claims 1- 7 respectively.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Brian Shaw whose telephone number is (571)270-5191. The examiner can normally be reached on Mon-Thurs from 6:00 AM-3:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeff Nickerson can be reached on (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 703-872-9306.
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.
/BRIAN F SHAW/
Primary Examiner, Art Unit 2432
Prosecution Insights