DETAILED ACTION
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 .
Status of Claims
Claims 1-20 are pending.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 1/13/2026 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-7 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim recites a computing apparatus comprising: a computer-readable storage medium… and one or more processors coupled to the computer-readable storage medium. However, the BRI of “computer-readable storage medium” includes a transitory signal per se, and the BRI of “one or more processors” includes software processors, i.e. software per se, neither of which falls within one of the four categories of patent eligible subject matter. None of claims 2-7 fix this and are therefore rejected for the same reasons. In order to fix this, the applicant must claim an element of hardware as part of the apparatus, e.g. non-transitory computer-readable storage medium, memory, hardware processor, etc.
Claims 16-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because the claim recites a computer-readable storage medium; however, the BRI of “computer-readable storage medium” includes a transitory signal per se, which does not fall within one of the four categories of patent eligible subject matter. Therefore, claim 16 is not an apparatus, nor is it a process, manufacture, or composition of matter. None of claims 2-7 fix this and are therefore rejected for the same reasons. In order to fix this, the applicant must claim an element of hardware as part of the apparatus, e.g. non-transitory computer-readable storage medium.
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(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, 8, 16 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Perlmutter et al (PGPUB 2019/0124059).
Regarding Claims 1, 8, and 16:
Perlmutter teaches a computing apparatus, a method, and a computer-readable storage medium comprising processor-executable instructions, wherein the processor-executable instructions, in part, operate a first network function (NF) within a first network such to cause one or more processors to perform a method, the computing apparatus comprising ([0091] exemplary system 600 configured to implement the gateway 130 of the present invention):
a computer-readable storage medium ([0091] computer readable medium storing software);
processor-executable instructions stored on the computer-readable storage medium ([0091] computer readable medium storing software); and
one or more processors coupled to the computer-readable storage medium and configured to execute the processor-executable instructions to operate a first network function (NF) within a first network ([0091] system (processing system) 600 includes a processor 602; [0056] the cloud gateway 130 may be one or more devices including one or more processors in one or more locations, implemented physically or virtually, as is known in the current state of the art; the cloud gateway 130 implements gateway functionality), wherein the first NF function comprises an access token engine ([0072] gateway 130 generates a second token), such that the processor-executable instructions, when executed by the one or more processors, direct the computing apparatus, to at least:
receive a service request from a visitor consumer NF ([0064] refer now to FIG. 2, a simplified flowchart of a method for identification; in particular, a method for identifying a user, and identifying each of multiple users, behind a shared VPN tunnel; in step 200, the current embodiment begins with receiving a first request from a user 102, the user being on a first side of the VPN 108; [0053] on the internal network 100 a router 110 is deployed; one or more clients are deployed on the internal network 100 and connected via the router 110 and VPN 108 to the cloud gateway 130; exemplary client 104 has a user 102 running an application 106), wherein the visitor consumer NF is in a second network that is different from the first network ([0064] the second side of the VPN is normally a side of the VPN other than the first side of the VPN; the first side is typically the internal network 100, and the second side is typically the Internet 120);
determine that the service request lacks an access token for receiving services from the first network ([0066] in step 202, the first request is processed and evaluated by the gateway 130, to determine if the first request includes a second token authenticating the user to the resource);
determine an access token for the visitor consumer NF based on the service request ([0071] In step 204, the first request does not include a second token authenticating the user to the resource; the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated (see below steps 206 to 216) and from step 204 the method continues at step 230, else the method continues at step 206; [0072] in step 230, the user 102 has been authenticated, but the user has not yet been authenticated to the resource in the first request (that is, not authenticated to the domain of the reference to the resource 128); a second token (domain ID cookie) authenticating the user to the resource is generated);
generate an updated service request comprising the service request and the access token ([0073] in step 232, a second request is generated; the second request is based on the first request, includes the reference to the resource 128, and includes the second token); and
transmit the updated service request to a producer NF within the first network, wherein the producer NF furnishes the service request for the visitor consumer NF based on the access token ([0074] in step 234, the second request is issued; issuing a request typically is re-directing the request, for example re-directing the user's web browser; for example, in the case of the current resource being a website (the resource 128), issuing the second request can be implemented by redirecting the user's browser from the gateway 130 to the originally requested resource (the website 128); [0075] in this case, the re-direction is to the same resource, but with a different request, specifically with the request now including the second token; in other words, the second request is issued and then is handled like the first request, repeating the steps of the current figure).
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.
Claim(s) 2, 7, 9, 17, 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Wang et al (PGPUB 2026/0039650).
Regarding Claim 2:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
generate an access token request based on the service request, wherein the access token request comprises one or more attributes associated with the visitor consumer NF and the service request; and
transmit the access token request to a second NF within the first network, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of directing a computing apparatus to generate an access token request based on a service request, wherein the access token request comprises one or more attributes associated with a visitor consumer NF and the service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120); and
transmit the access token request to a second NF within a first network, wherein the second NF generates an access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 7:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
determine one or more access token attributes based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach generating an access token request comprising the one or more access token attributes; and
retrieving the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of generating an access token request comprising the one or more access token attributes ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120); and
retrieving the access token from a second NF within a first network using the access token request, wherein the second NF generates an access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 9:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the service request comprises:
generating, by the access token engine, an access token request based on the service request;
transmitting, by the access token engine, the access token request to a second NF within the first network, wherein the second NF generates the access token responsive to receiving the access token request; and
receiving, by the access token engine, the access token from the second NF.
However, Wang teaches the concept wherein determining, by an access token engine, an access token for a service request comprises:
generating, by the access token engine, an access token request based on the service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120);
transmitting, by the access token engine, the access token request to a second NF within a first network, wherein the second NF generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130); and
receiving, by the access token engine, the access token from the second NF ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 17:
Perlmutter teaches the computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
generate, by the access token engine, an access token request based on the service request, wherein the access token request comprises one or more of:
nfinstanceID;
nftype;
targetnftype;
scope of service; or
requestorPLMN; and
retrieve, by the access token engine, the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of generating, by an access token engine, an access token request based on a service request ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120), wherein the access token request comprises one or more of:
nfinstanceID;
nftype;
targetnftype ([0092] the SCPc 130 transmits to the NRF 150 a request for the access token; in some example embodiments, if the SCPc 130 uses “targetNfType” in the request for the access token, the audience in the access token claims may be set accordingly and with multiple matching NF producer instances, “token ValidationDelegationAllowed” and/or “token ValidationDelegationSCPDomainList” may be configured differently);
scope of service; or
requestorPLMN; and
retrieve, by the access token engine, the access token from a second NF within the first network using the access token request, wherein the second NF generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Regarding Claim 20:
Perlmutter teaches the computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
retrieve, by the access token engine, the access token from a second NF within the first network using an access token request, wherein the second NF:
comprises a network function repository function (NRF) within the first network; and
generates the access token responsive to receiving the access token request.
However, Wang teaches the concept of retrieving, by an access token engine, an access token from a second NF within a first network using an access token request, wherein the second NF ([0066]-[0067] the NFc 110 may transmit to the SCPc 130 a request for a service from the NFp 120; for example, the request may comprise scope information associate with the NFp 120; the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120):
comprises a network function repository function (NRF) within the first network ([0066]-[0067] NRF); and
generates the access token responsive to receiving the access token request ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Claim(s) 3, 5-6, 11, 13-15, 18-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of S Bykampadi et al (PGPUB 2021/0297942), hereinafter Bykampadi.
Regarding Claim 3:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions to determine the access token for the visitor consumer NF based on the service request, when executed by the one or more processors, further direct the computing apparatus to:
determine a unique identifier for the visitor consumer NF based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach performing a look-up on a visitor access token table based on the unique identifier; and
determining the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF.
However, Bykampadi teaches the concept of performing a look-up on a visitor access token table based on a unique identifier ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
determining an access token for the visitor consumer NF within a visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 5:
Perlmutter teaches the computing apparatus of claim 1. In addition, Perlmutter teaches wherein the processor-executable instructions, when executed by the one or more processors, further direct the computing apparatus to:
determine a unique identifier for the visitor consumer NF based on the service request ([0071] the first request is then processed and evaluated by the gateway 130, to determine if the first request includes a userid; processing may include decrypting the first request and parsing the resulting data to determine a userid; in a case where the first request is a URL, the URL, can be checked to see if the URL includes a userid; if the first request includes the userid, then the user has previously been authenticated).
Perlmutter does not explicitly teach determining an expiry time associated with the access token; and
updating a visitor access token table with the access token, the expiry time, and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF and the expiry time within the visitor access token table.
However, Bykampadi teaches the concept of determining an expiry time associated with the access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
updating a visitor access token table with the access token, the expiry time, and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF and the expiry time within the visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 6:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network.
However, Bykampadi teaches the concept wherein a first NF comprises a Security Edge Protection Proxy (SEPP) within a first network ([0096] SCP to SCP connection may be based on TLS or, in alternative embodiments, could also be Network Domain Security/Internet Protocol or NDS/IP (IPSec) or also implicit if going through a SEPP (for inter-roaming scenarios); SCPc and SCPp trust each other based on a mutually authenticated secure connection between them either directly or indirectly via SEPP).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the SEPP teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating a specialized security device which implements proven security transport techniques such as Transport Layer Security (TLS) and application layer security (ALS).
Regarding Claim 11:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
performing, by the access token engine, a look-up on a visitor access token table based on the service request; and
identifying, by the access token engine, the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF.
However, Bykampadi teaches the concept of performing, by an access token engine, a look-up on a visitor access token table based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
identifying, by the access token engine, an access token for a visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 13:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the method further comprises:
determining, by the access token engine, a unique identifier for the visitor consumer NF based on the service request; and
updating, by the access token engine, a visitor access token table with the access token and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF.
However, Bykampadi teaches the concept of determining, by an access token engine, a unique identifier for a visitor consumer NF based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
updating, by the access token engine, a visitor access token table with an access token and the unique identifier, wherein the access token is associated with the unique identifier of the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 14:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the access token comprises an open authorization token.
However, Bykampadi teaches the concept wherein an access token comprises an open authorization token ([0058] methodology is provided to implement OAuth-based service access authorization).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the OAuth teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating authentication methods which are well-known standards in the art, such as OAuth, which has a proven record of safe and secure authentication functionality.
Regarding Claim 15:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein the first NF comprises a Security Edge Protection Proxy (SEPP) within the first network.
However, Bykampadi teaches the concept wherein a first NF comprises a Security Edge Protection Proxy (SEPP) within a first network ([0096] SCP to SCP connection may be based on TLS or, in alternative embodiments, could also be Network Domain Security/Internet Protocol or NDS/IP (IPSec) or also implicit if going through a SEPP (for inter-roaming scenarios); SCPc and SCPp trust each other based on a mutually authenticated secure connection between them either directly or indirectly via SEPP).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the SEPP teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve the security environment by incorporating a specialized security device which implements proven security transport techniques such as Transport Layer Security (TLS) and application layer security (ALS).
Regarding Claim 18:
Perlmutter teaches the computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine, by the access token engine, the access token for the visitor consumer NF cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
perform, by the access token engine, a look-up on a visitor access token table based on the service request;
identify, by the access token engine, the access token for the visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within the first network for the visitor consumer NF; and
determine, by the access token engine, that the access token is valid based on a respective expiry time of the access token.
However, Bykampadi teaches the concept of performing, by an access token engine, a look-up on a visitor access token table based on a service request ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed);
identifying, by the access token engine, an access token for a visitor consumer NF within the visitor access token table, wherein the access token was previously generated by a second NF function within a first network for the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed); and
determining, by the access token engine, that the access token is valid based on a respective expiry time of the access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Regarding Claim 19:
Perlmutter teaches the computer-readable storage medium of claim 16.
Perlmutter does not explicitly teach wherein the processor-executable instructions cause the one or more processors to further execute processor-executable instructions stored in the computer-readable storage medium to:
determine, by the access token engine, an expiry time for the access token;
associate, by the access token engine, the access token with a unique identifier for the visitor consumer NF; and
store, by the access token engine, the access token, the expiry time, and the unique identifier in a visitor access token table.
However, Bykampadi teaches the concept of determining, by an access token engine, an expiry time for an access token ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration));
associate, by the access token engine, the access token with a unique identifier for the visitor consumer NF ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)); and
store, by the access token engine, the access token, the expiry time, and the unique identifier in a visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed; [0092] the claims in the token include the NF Instance Id of NRF (issuer), NF Instance Id of the NF Service consumer (subject), NF type of the NF Service producer (audience), expected service name(s) (scope) and expiration time (expiration)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Lee et al (PGPUB 2023/0020855).
Regarding Claim 4:
Perlmutter teaches the computing apparatus of claim 1.
Perlmutter does not explicitly teach wherein the processor-executable instructions to determine that the service request lacks the access token for receiving services from the first network, when executed by the one or more processors, further direct the computing apparatus to:
identify a current access token for the visitor consumer NF within a visitor access token table; and
determine that an expiry time associated with the current access token is exceeded.
However, Lee teaches the concept of identifying a current access token for a visitor consumer NF within a visitor access token table ([0021] an access device may be configured to maintain access data including the network access tokens within a container stored in local memory (e.g., in a mapping between an accessory device identifier and a network access token, in a list of network access tokens with which access is to be granted, in an object for each accessory device and related data, or the like)); and
determining that an expiry time associated with a current access token is exceeded ([0029] the access device may be configured to detect when the time limit of a network access token has been reached (referred to as “expiration time”); upon determining that the time limit has been reached, the access device can revoke network access for the accessory device corresponding to the expired network access token).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token expiration teachings of Lee with the authentication of a service request teachings of Perlmutter; it is well-known in the art to time-limit authentication and encryption credentials, such as keys and tokens, in order to improve the security environment by limiting the amount of time an eavesdropper has to attempt reuse of security materials.
Claim(s) 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Lee and Wang.
Regarding Claim 10:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein:
determining, by the access token engine, that the service request lacks the access token for receiving services from the first network comprises:
identifying, by the access token engine, a current access token for the visitor consumer NF within a visitor access token table; and
determining, by the access token engine, that the current access token is invalid based on an expiry time associated with the current access token.
However, Lee teaches the concept of identifying, by an access token engine, a current access token for a visitor consumer NF within a visitor access token table ([0021] an access device may be configured to maintain access data including the network access tokens within a container stored in local memory (e.g., in a mapping between an accessory device identifier and a network access token, in a list of network access tokens with which access is to be granted, in an object for each accessory device and related data, or the like)); and
determining, by the access token engine, that the current access token is invalid based on an expiry time associated with the current access token ([0029] the access device may be configured to detect when the time limit of a network access token has been reached (referred to as “expiration time”); upon determining that the time limit has been reached, the access device can revoke network access for the accessory device corresponding to the expired network access token).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token expiration teachings of Lee with the authentication of a service request teachings of Perlmutter; it is well-known in the art to time-limit authentication and encryption credentials, such as keys and tokens, in order to improve the security environment by limiting the amount of time an eavesdropper has to attempt reuse of security materials.
Neither Perlmutter nor Lee explicitly teaches determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
retrieving, by the access token engine, the access token for the visitor consumer NF from a second NF within the first network.
However, Wang teaches the concept wherein determining, by an access token engine, an access token for a visitor consumer NF based on a service request comprises:
retrieving, by the access token engine, the access token for the visitor consumer NF from a second NF within the first network ([0067] the SCPc 130 transmits (210) to the NRF 150 a request for a token to access the NFp 120; the NRF 150 generates the token based on the request and the registration information from the NFp 120; then, the NRF 150 transmits (215) the token to the SCPc 130).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the network repository function (NRF) teachings of Wang with the authentication of a service request teachings of Perlmutter in view of Lee, with the benefit of using an established, central token repository to distribute tokens to supplicant parties, thereby improving efficiency by eliminating redundant systems and improving security by allowing administrators to focus on a single point of failure for hardening against exploits and attacks.
Claim(s) 12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Perlmutter, and further in view of Bykampadi and Baskaran et al (PGPUB 2026/0039641).
Regarding Claim 12:
Perlmutter teaches the method of claim 8.
Perlmutter does not explicitly teach wherein determining, by the access token engine, the access token for the visitor consumer NF based on the service request comprises:
identifying, by the access token engine, a current access token for the visitor consumer NF within a visitor access token table;
generating, by the access token engine, a first updated service request comprising the current access token and the service request;
retrieving, by the access token engine, the access token from a second NF within the first network based on the service request.
However, Bykampadi teaches the concept of identifying, by an access token engine, a current access token for a visitor consumer NF within a visitor access token table ([0059]-[0060] the SCP obtains an access token on behalf of the NFc and stores these (cached) access tokens for later usage for the entire validity period of the granted access tokens; if there already exists an access token for this pair of NFc-NFp which has not expired, then the SCPc may reuse that access token (i.e., cached token), and no access token request to the NRF is needed);
generating, by the access token engine, a first updated service request comprising the current access token and the service request (abstract, first service communication proxy element determines at least one target service producer based on the service request; the first service communication proxy element sends an access token request to an authorization entity, wherein the access token request is generated based on the determining step; the first service communication proxy element receives an access token response from the authorization entity, wherein the access token response comprises an access token; the first service communication proxy element may then send a service request with the access token to a second service communication proxy element, wherein the second service communication proxy element is associated with the target service producer);
retrieving, by the access token engine, the access token from a second NF within the first network based on the service request ([0059] the SCP connected to the NFc (referred to herein as SCPc) obtains all the required information related to the target NF producer (NFp) from the NRF; once it selects the target NFp, it issues another request to the NRF to obtain an access token specific to the NFc and the selected target NFp).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the token caching teachings of Bykampadi with the authentication of a service request teachings of Perlmutter, in order to improve system efficiency and security by reusing valid tokens for a limited amount of time, thereby providing a balance between the number of required token issuance requests and the duration of a token, limiting an attacker’s ability to intercept and replay a stolen token.
Neither Perlmutter nor Bykampadi explicitly teaches receiving, by the access token engine, an error response from the producer NF responsive to transmitting the first updated service request to the producer NF.
However, Baskaran teaches the concept of receiving, by an access token engine, an error response from a producer NF responsive to transmitting a first updated service request to the producer NF ([0059] the NF service producer checks that the token has not expired by verifying the expiration time in the token against the current data and/or time; if a client credentials assertion (CCA) is present in the service request, then the NF service producer may verify that the CCA as defined and that the subject claim (e.g., the NF instance ID of the NF service consumer) in the token matches the subject claim in the CCA; if the verification is successful, then the NF service producer executes the requested service and responds back to the NF service consumer; otherwise, the NF service producer replies with an error response (e.g., an Oauth 2.0 error response)).
It would have been obvious to one or ordinary skill in the art before the effective filing date of the claimed invention to combine the error notification teachings of Baskaran with the authentication of a service request teachings of Perlmutter in view of Bykampadi; it is well-known in the art to provide error notifications in the event of failure, in order to improve system efficiency and security by informing a client/user/admin that there is an issue with a validation process that must be fixed before making use of a service.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to FORREST L CAREY whose telephone number is (571)270-7814. The examiner can normally be reached 9:00AM-5:30PM M-F.
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, William Korzuch can be reached at (571)-272-7589. 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.
/FORREST L CAREY/Examiner, Art Unit 2491
/WILLIAM R KORZUCH/Supervisory Patent Examiner, Art Unit 2491