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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-15 in the reply filed on 6/9/2026 is acknowledged.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 1-4, 10-12, 21-23 is/are rejected under 35 U.S.C. 103 as being unpatentable over Evani (US-20230100200-A1) in view of RFC 6749 (October 2012), in further view of RFC 9449 (September 2023), in further view of Major (WO-2025126478-A1).
Regarding claim 1, Evani teaches A system comprising: a server device executing an authentication service, the server device communicatively coupled to a client computing device executing a first instance of an application frontend, the authentication service comprising: (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 114, "FIG. 6 illustrates a sequence diagram 600 for exchanging a bearer token for a Proof-of-Possession (PoP) token, in accordance with some example embodiments." Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system." Fig. 4 shows a client 410 requesting a token from IDCS authentication service, The first instance is interpreted as the session the user has a token and is trying to perform the token exchange in. The authentication server device is interpreted as the token exchange system in figure 2.).
an identity provider that:
receives, from the first instance, … [a request from user account] (Fig. 4 shows a token request for an access token from the client.).
and transmits, to the first instance, an authentication artifact… the authentication artifact indicating … the user account is authenticated; (FIG. 4 illustrates a sequence diagram 400 for obtaining an access token. In the example shown in FIG. 4, a client of the IDCS system is requesting an access token for the IDCS system. Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system." Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token) that is used to access a first identity management system (e.g., Identity Cloud Service (IDCS)) can be exchanged for a second type of token (e.g., proof of possession (PoP) token) that is used to access a second identity management system (e.g., Infrastructure Identity and Access Management (IAM)), and vice versa" The bearer token/access token are interpreted as equivalent since they both are a first type of token. The access/bearer token/IDCS token is interpreted as an authentication artifact of a first instance.).
and an ownership validator that:
receives the authentication artifact from the first instance, (Paragraph 114, "FIG. 6 illustrates a sequence diagram 600 for exchanging a bearer token for a Proof-of-Possession (PoP) token, in accordance with some example embodiments." Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." The authentication artifact, the IDCS/bearer/access token is received from the same session as the IDCS/bearer/access token receiver.)
responsive to determining [a] proof code is valid … resulting in a signed authentication artifact, (Paragraph 55, "FIG. 1 illustrates a general overview of a method 100 for exchanging tokens, in accordance with some example embodiments. The method 100 shown in FIG. 1 can be performed by a token exchange system of an Integrated Identity Management System (IDMS). The token exchange can be performed to exchange a bearer token for a proof of possession (PoP) token, or to exchange a PoP token for a bearer token. In an example embodiment, a token for a first identity system can be exchanged to obtain a different type of token for a second identity system." Paragraph 131-135, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application. At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key. At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid. At step 740, the token exchange system can generate a second token for the second identity system based on the first token for the first identity system. At step 750, the token exchange system can sign the second token with the private key of the entity to generate a second signed token." The proof code is interpreted as the public key and signature associated with a private key on the request that comes with the first token, this token being interpreted as the authentication artifact.).
and transmits [a] signed authentication artifact to the first instance. (Paragraph 20 "An example embodiment can include a method including determining, by a token exchange system of an integrated identity management system of a cloud service, that an entity is authorized to access a first identity system, wherein the entity is an application, generating, by the token exchange system, a first request for the entity to access a second identity system, wherein the first request includes a bearer token and a first public key associated with the entity, verifying, by the token exchange system, that the bearer token is a valid bearer token, verifying, by the token exchange system, whether a role of the entity is a role that is authorized to access the second identity system, generating, by the token exchange system, a second token based on the bearer token and the first public key received in the first request, and sending, by the token exchange system, the second token to the entity, wherein the second token is associated with the second identity system, and the second token includes the first public key of the entity." The entity is the first instance, the signed authentication artifact is interpreted as the second token.)
However, Evani does not explicitly teach a system that receives … a proof code and a credential of a user account; authenticates the credential of the user account; and transmits, to the first instance, … artifact comprising the proof code, … artifact indicating the credential of the user account is authenticated; responsive to determining the proof code is valid, digitally signs the authentication artifact, resulting in a signed authentication artifact. and transmits the signed authentication artifact to the first instance.
RFC 6479 teaches a system that receives … a credential of a user account (RFC 6749, Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
authenticates the credential of the user account; (RFC 6749, Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
… artifact indicating the credential of the user account is authenticated (RFC 6749, Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." The access token being given to the user device after authentication of the credential is successful is interpreted as an indication that the credential of the user account is authenticated.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani’s token exchange system with RFC 6749 by enhancing the access token issuance (Evani, Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token)”) to be an Oauth token, with the system performing a credential check on a token request and returning a Oauth token in response to authenticating the authorization code of the user. The motivation is to enhance Evani’s first token to use the Oauth 2.0 framework and adhere to the standard, so that access tokens are only given to trustworthy entities.
However, Evani in view of RFC 6749 does not explicitly teach a system that receives … a proof code … of a user account, and transmits, to the first instance, … artifact comprising the proof code, and responsive to determining the proof code is valid, digitally signs the authentication artifact, resulting in a signed authentication artifact. and transmits the signed authentication artifact to the first instance.
RFC 9449 teaches a system that receives … a proof code … of a user account; (RFC 9449, Figure 1 shows a Token request comprising a dPop Proof. Page 6, "Roughly speaking, a DPoP proof is a signature over: some data of the HTTP request to which it is attached, a timestamp, a unique identifier, an optional server-provided nonce, and a hash of the associated access token when an access token is present within the request." Page 7, "In the token request, the client sends an authorization grant (e.g., an authorization code, refresh token, etc.) to the authorization server in order to obtain an access token (and potentially a refresh token). The client attaches a DPoP proof to the request in an HTTP header." RFC 9449, Page 9, "A DPoP proof is a JWT [RFC7519] that is signed (using JSON Web Signature (JWS) [RFC7515]) with a private key chosen by the client (see below). The JOSE Header of a DPoP JWT MUST contain at least the following parameters: … jwk: Represents the public key chosen by the client in JSON Web Key (JWK) [RFC7517] format as defined in Section 4.1.3 of [RFC7515]. It MUST NOT contain a private key." The dpop public key associated with a private key is interpreted as a proof code of a user account. The credential is interpreted as the authorization code.).
and transmits, to the first instance, … artifact comprising the proof code, (RFC 9449, Figure 1, Page 7, "The authorization server binds (sender-constrains) the access token to the public key claimed by the client in the DPoP proof; that is, the access token cannot be used without proving possession of the respective private key. If a refresh token is issued to a public client, it is also bound to the public key of the DPoP proof." RFC 9449 page 14, "Resource servers MUST be able to reliably identify whether an access token is DPoP-bound and ascertain sufficient information to verify the binding to the public key of the DPoP proof (see Section 7.1). Such a binding is accomplished by associating the public key with the token in a way that can be accessed by the protected resource, such as embedding the JWK hash in the issued access token directly, using the syntax described in Section 6.1, or through token introspection as described in Section 6.2. Other methods of associating a public key with an access token are possible per an agreement by the authorization server and the protected resource; however, they are beyond the scope of this specification." RFC 9449, Page 15-16, "For a DPoP-bound access token, the hash of the public key to which the token is bound is conveyed to the protected resource as metainformation in a token introspection response. The hash is conveyed using the same cnf content with jkt member structure as the JWK Thumbprint confirmation method, described in Section 6.1, as a top-level member of the introspection response JSON." The artifact comprising the proof code is interpreted as the public key being stored inside the access token via hash.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749’s token exchange system with RFC 9449 by enhancing Evani in view of RFC 6749’s initially provided access/bearer token system to include a public key included in the request for a token, then having the token returned with a binding to the public key associated with the client’s session, as taught by RFC 9449. The motivation is to prevent spoofing and imitation attacks with the access/bearer token provided by Evani in view of RFC 6749’s system by building the proof of a secret key’s possession into the access token, preventing anybody but the secret key’s owner from being able to use the access token properly.
However, Evani in view of RFC 6749, in further view of RFC 9449 does not teach that the system responsive to determining the proof code is valid, digitally signs the authentication artifact, resulting in a signed authentication artifact, and transmits the signed authentication artifact to the first instance.
Major teaches a system that responsive to determining the proof code is valid, digitally signs the authentication artifact, resulting in a signed authentication artifact (Paragraph 25, "The device can determine 504 the integrity of the challenge token by first verifying a CDS signature on the challenge token. The device can then decrypt 506 the challenge token using a self-generated key, as well as a persistent key for the device … The device, having successfully decrypted the challenge token, can then verify 508 the inner signature of the challenge token using the CDS public key. Once decrypted and verified, the device can determine 510 the manager information included in the token." Paragraph 23, "The device can then generate 610 a bearer token including the decrypted token and digitally signed by the device, effectively converting the challenge token to a bearer token." Paragraph 25, "The device can then combine 512 the signed but decrypted challenge token with the nonce from inside the token to create a bearer token, which can then be signed 514 with the self-generated device key. The self-generated key is used instead of the persistent device key as the manager should only be able to access information for the device while that manager is associated with that device, and not at any other time." Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication." The authentication artifact is interpreted as the challenge token. The proof code is interpreted as the signature, where if the signature shows that the sender of the challenge token indeed owns the private key and public key for which the token is for, the combined challenge token with nonce being used for the bearer token, then signing it, is interpreted as a signed authentication artifact.),
and transmits the signed authentication artifact to the first instance. (Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449’s token exchange system with Major by enhancing Evani in view of RFC 6749, in further view of RFC 9449’s access/bearer token to POP (proof of possession) token conversion to include a step where the new token includes a signed previous token, the signature of the previous token a result of confirming the signature in the token is valid with the public key associated with the device who transmitted this token, as taught by Major. The motivation is to include a record of the POP token’s generation built into the token to prevent possible replay attacks with the previous token, as well as encoding the token’s origin for accounting purposes.
Regarding claim 2, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the system of claim 1. Evani teaches the system further comprising an artifact validator that:
receives, from the first instance, an access request comprising the signed authentication artifact; (Paragraph 180, "At step 1160, the token exchange system can send the application the token signed by IAM. The token can be used by the application to make future API calls to IAM. The token can also be known as a key. By assigning a key to an application and the key can be used to ensure that the application is what it is claiming to be," The token the first token is exchanged for is interpreted as the signed authentication artifact, the future API calls are interpreted as access requests. The token validity checking system is interpreted as the artifact validator.).
determines the signed authentication artifact is valid; (Paragraph 186, "If the application makes future API calls, the token exchange system can receive a request for an API call to the IAM. The request includes the public token signed by IAM. The request is signed using the private key of the application." Paragraph 187, " The application can attach the token received from IAM in any requests and the application can sign also sign the request with the private key of the application. The application can prove is possesses a private key and a valid token from the IAM. Therefore, resources that application is trying to access can verify the identity of the application. The application can make future references to IAM API's by signing the request with the private key of the application and attaching the token signed by the IAM." The determining the signed authentication artifact is interpreted as the verification of the token included in the access request.).
and forwards the access request to the application backend, the forwarded access request indicating the signed authentication artifact is valid and causing the application backend to provide the first instance access to a resource of the application backend. (Paragraph 187, "Therefore, resources that application is trying to access can verify the identity of the application." The verification of the application identity through the valid token from the IAM prior to resource access is interpreted as forwarding the request to the backend to provide the requesting application the resources it needed verification to request.).
Regarding claim 3, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the system of claim 2. Evani teaches wherein the application backend is configured to deny access to the resource without validation of the signed authentication artifact by the artifact validator. (Paragraph 187, "The application can attach the token received from IAM in any requests and the application can sign also sign the request with the private key of the application. The application can prove is possesses a private key and a valid token from the IAM. Therefore, resources that application is trying to access can verify the identity of the application. The application can make future references to IAM API's by signing the request with the private key of the application and attaching the token signed by the IAM." The system requiring identity verification of the application using a token from the IAM (the signed authentication artifact) for accessing specific resources means that access if validation fails, the application would not be given access to the resource.).
Regarding claim 4, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the system of claim 1. Evani teaches wherein the ownership validator further: binds the signed authentication artifact to the first instance. (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 62, "The tokens can be session based. That is, while a user is authenticated in a session, the tokens can continue to be used. The tokens can also be browser based. If a user is logging into a browser using a sign on session, the length that the tokens can continue to be used can be based on the browser session." The IDCS and IAM tokens (they are proof of possession tokens interpreted as signed authentication artifacts) being session based is interpreted as binding the signed authentication artifact to the first instance.).
Regarding claim 10, Evani teaches a method performed by an authentication service that is executing on a server device, the server device communicatively coupled to a client computing device executing an application frontend, the method comprising: (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 114, "FIG. 6 illustrates a sequence diagram 600 for exchanging a bearer token for a Proof-of-Possession (PoP) token, in accordance with some example embodiments." Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system." Fig. 4 shows a client 410 requesting a token from IDCS authentication service, The first instance is interpreted as the session the user has a token and is trying to perform the token exchange in. The authentication server device is interpreted as the token exchange system in figure 2.).
receiving, from a first instance of the application frontend, … [a request from the user account] (Fig. 4 shows a token request for an access token from the client.).
responsive to …[request], generating an authentication artifact …; (FIG. 4 illustrates a sequence diagram 400 for obtaining an access token. In the example shown in FIG. 4, a client of the IDCS system is requesting an access token for the IDCS system. Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system." Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token) that is used to access a first identity management system (e.g., Identity Cloud Service (IDCS)) can be exchanged for a second type of token (e.g., proof of possession (PoP) token) that is used to access a second identity management system (e.g., Infrastructure Identity and Access Management (IAM)), and vice versa" The bearer token/access token are interpreted as equivalent since they both are a first type of token. The access/bearer token/IDCS token is interpreted as an authentication artifact of a first instance.).
determining [a] proof code is valid, resulting in a validated authentication artifact; (Paragraph 55, "FIG. 1 illustrates a general overview of a method 100 for exchanging tokens, in accordance with some example embodiments. The method 100 shown in FIG. 1 can be performed by a token exchange system of an Integrated Identity Management System (IDMS). The token exchange can be performed to exchange a bearer token for a proof of possession (PoP) token, or to exchange a PoP token for a bearer token. In an example embodiment, a token for a first identity system can be exchanged to obtain a different type of token for a second identity system." Paragraph 131-135, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application. At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key. At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid. At step 740, the token exchange system can generate a second token for the second identity system based on the first token for the first identity system. At step 750, the token exchange system can sign the second token with the private key of the entity to generate a second signed token." The proof code is interpreted as the public key and signature associated with a private key on the request that comes with the first token, this token being interpreted as the authentication artifact.).
and transmitting [a] validated authentication artifact to the first instance. (Paragraph 20 "An example embodiment can include a method including determining, by a token exchange system of an integrated identity management system of a cloud service, that an entity is authorized to access a first identity system, wherein the entity is an application, generating, by the token exchange system, a first request for the entity to access a second identity system, wherein the first request includes a bearer token and a first public key associated with the entity, verifying, by the token exchange system, that the bearer token is a valid bearer token, verifying, by the token exchange system, whether a role of the entity is a role that is authorized to access the second identity system, generating, by the token exchange system, a second token based on the bearer token and the first public key received in the first request, and sending, by the token exchange system, the second token to the entity, wherein the second token is associated with the second identity system, and the second token includes the first public key of the entity." The entity is the first instance, the signed authentication artifact is interpreted as the second token.)
However, Evani does not teach receiving … a proof code and a credential of a user account; responsive to authenticating the credential of the user account, generating … artifact comprising the proof code; determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
RFC 6479 teaches receiving … a credential of a user account; (RFC 6749, Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
responsive to authenticating the credential of the user account, generating … artifact comprising … (Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani’s token exchange system with RFC 6749 by enhancing the access token issuance (Evani, Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token)”) to be an Oauth token, with the system performing a credential check on a token request and returning a Oauth token in response to authenticating the authorization code of the user. The motivation is to enhance Evani’s first token to use the Oauth 2.0 framework and adhere to the standard, so that access tokens are only given to trustworthy entities.
However, Evani in view of RFC 6749 does not teach receiving … a proof code … of a user account; generating … artifact comprising the proof code, determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
RFC 9449 teaches receiving … a proof code … of a user account; (Figure 1 shows a Token request comprising a dPop Proof. Page 6, "Roughly speaking, a DPoP proof is a signature over: some data of the HTTP request to which it is attached, a timestamp, a unique identifier, an optional server-provided nonce, and a hash of the associated access token when an access token is present within the request." Page 7, "In the token request, the client sends an authorization grant (e.g., an authorization code, refresh token, etc.) to the authorization server in order to obtain an access token (and potentially a refresh token). The client attaches a DPoP proof to the request in an HTTP header." Page 9, "A DPoP proof is a JWT [RFC7519] that is signed (using JSON Web Signature (JWS) [RFC7515]) with a private key chosen by the client (see below). The JOSE Header of a DPoP JWT MUST contain at least the following parameters: … jwk: Represents the public key chosen by the client in JSON Web Key (JWK) [RFC7517] format as defined in Section 4.1.3 of [RFC7515]. It MUST NOT contain a private key." The dpop public key associated with a private key is interpreted as a proof code of a user account. The credential is interpreted as the authorization code.).
generating … artifact comprising the proof code; (Figure 1, Page 7, "The authorization server binds (sender-constrains) the access token to the public key claimed by the client in the DPoP proof; that is, the access token cannot be used without proving possession of the respective private key. If a refresh token is issued to a public client, it is also bound to the public key of the DPoP proof." RFC 9449 page 14, "Resource servers MUST be able to reliably identify whether an access token is DPoP-bound and ascertain sufficient information to verify the binding to the public key of the DPoP proof (see Section 7.1). Such a binding is accomplished by associating the public key with the token in a way that can be accessed by the protected resource, such as embedding the JWK hash in the issued access token directly, using the syntax described in Section 6.1, or through token introspection as described in Section 6.2. Other methods of associating a public key with an access token are possible per an agreement by the authorization server and the protected resource; however, they are beyond the scope of this specification." RFC 9449, Page 15-16, "For a DPoP-bound access token, the hash of the public key to which the token is bound is conveyed to the protected resource as metainformation in a token introspection response. The hash is conveyed using the same cnf content with jkt member structure as the JWK Thumbprint confirmation method, described in Section 6.1, as a top-level member of the introspection response JSON." The artifact comprising the proof code is interpreted as the public key being stored inside the access token via hash.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749’s token exchange system with RFC 9449 by enhancing Evani in view of RFC 6749’s initially provided access/bearer token system to include a public key included in the request for a token, then having the token returned with a binding to the public key associated with the client’s session, as taught by RFC 9449. The motivation is to prevent spoofing and imitation attacks with the access/bearer token provided by Evani in view of RFC 6749’s system by building the proof of a secret key’s possession into the access token, preventing anybody but the secret key’s owner from being able to use the access token properly.
However, Evani in view of RFC 6749, in further view of RFC 9449 does not teach determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
determining the proof code is valid, resulting in a validated authentication artifact; (Paragraph 25, "The device can determine 504 the integrity of the challenge token by first verifying a CDS signature on the challenge token. The device can then decrypt 506 the challenge token using a self-generated key, as well as a persistent key for the device … The device, having successfully decrypted the challenge token, can then verify 508 the inner signature of the challenge token using the CDS public key. Once decrypted and verified, the device can determine 510 the manager information included in the token." Paragraph 23, "The device can then generate 610 a bearer token including the decrypted token and digitally signed by the device, effectively converting the challenge token to a bearer token." Paragraph 25, "The device can then combine 512 the signed but decrypted challenge token with the nonce from inside the token to create a bearer token, which can then be signed 514 with the self-generated device key. The self-generated key is used instead of the persistent device key as the manager should only be able to access information for the device while that manager is associated with that device, and not at any other time." Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication." The authentication artifact is interpreted as the challenge token. The proof code is interpreted as the signature, where if the signature shows that the sender of the challenge token indeed owns the private key and public key for which the token is for, the combined challenge token with nonce being used for the bearer token, then signing it, is interpreted as a signed authentication artifact.).
and transmitting the validated authentication artifact to the first instance. (Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication.")
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449’s token exchange system with Major by enhancing Evani in view of RFC 6749, in further view of RFC 9449’s access/bearer token to POP (proof of possession) token conversion to include a step where the new token includes a signed previous token, the signature of the previous token a result of confirming the signature in the token is valid with the public key associated with the device who transmitted this token, as taught by Major. The motivation is to include a record of the POP token’s generation built into the token to prevent possible replay attacks with the previous token, as well as encoding the token’s origin for accounting purposes.
Regarding claim 11, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the method of claim 10. Evani teaches wherein said determining the proof code is valid comprises: providing the proof code to an ownership validator, causing the ownership validator to determine the proof code is valid and generate the validated authentication artifact. (Paragraph 25, "The device can determine 504 the integrity of the challenge token by first verifying a CDS signature on the challenge token. The device can then decrypt 506 the challenge token using a self-generated key, as well as a persistent key for the device … The device, having successfully decrypted the challenge token, can then verify 508 the inner signature of the challenge token using the CDS public key. Once decrypted and verified, the device can determine 510 the manager information included in the token." Paragraph 23, "The device can then generate 610 a bearer token including the decrypted token and digitally signed by the device, effectively converting the challenge token to a bearer token." Paragraph 25, "The device can then combine 512 the signed but decrypted challenge token with the nonce from inside the token to create a bearer token, which can then be signed 514 with the self-generated device key. The self-generated key is used instead of the persistent device key as the manager should only be able to access information for the device while that manager is associated with that device, and not at any other time." The authentication artifact is interpreted as the challenge token. The proof code is interpreted as the signature, where if the signature shows that the sender of the challenge token indeed owns the private key and public key for which the token is for, the combined challenge token with nonce being used for the bearer token, then signing it, is interpreted as a signed authentication artifact.).
Regarding claim 12, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the method of claim 10. Evani teaches further comprising: receiving, from the first instance, an access request comprising the validated authentication artifact; (Paragraph 180, "At step 1160, the token exchange system can send the application the token signed by IAM. The token can be used by the application to make future API calls to IAM. The token can also be known as a key. By assigning a key to an application and the key can be used to ensure that the application is what it is claiming to be," The token the first token is exchanged for is interpreted as the signed authentication artifact, the future API calls are interpreted as access requests. The token validity checking system is interpreted as the artifact validator.)
determining the validated authentication artifact is valid; (Paragraph 186, "If the application makes future API calls, the token exchange system can receive a request for an API call to the IAM. The request includes the public token signed by IAM. The request is signed using the private key of the application." Paragraph 187, " The application can attach the token received from IAM in any requests and the application can sign also sign the request with the private key of the application. The application can prove is possesses a private key and a valid token from the IAM. Therefore, resources that application is trying to access can verify the identity of the application. The application can make future references to IAM API's by signing the request with the private key of the application and attaching the token signed by the IAM." The determining the signed authentication artifact is interpreted as the verification of the token included in the access request.).
and transmitting a forwarded access request to the application backend, the forwarded access request indicating the validated authentication artifact is valid and causing the application backend to provide the first instance access to a resource of the application backend. (Paragraph 187, "Therefore, resources that application is trying to access can verify the identity of the application." The verification of the application identity through the valid token from the IAM prior to resource access is interpreted as forwarding the request to the backend to provide the requesting application the resources it needed verification to request.).
Regarding claim 21, Evani teaches A computer-readable storage medium having programming instructions encoded thereon structured to cause a processor of a server device to perform a method comprising: (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 114, "FIG. 6 illustrates a sequence diagram 600 for exchanging a bearer token for a Proof-of-Possession (PoP) token, in accordance with some example embodiments." Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system." Fig. 4 shows a client 410 requesting a token from IDCS authentication service, The first instance is interpreted as the session the user has a token and is trying to perform the token exchange in. The authentication server device is interpreted as the token exchange system in figure 2.).
receiving, from a first instance of an application frontend executing on a client computing device communicatively coupled to the server device, … [a request from the user account] (Fig. 4 shows a token request for an access token from the client.).
responsive to …[request], generating an authentication artifact …; (FIG. 4 illustrates a sequence diagram 400 for obtaining an access token. In the example shown in FIG. 4, a client of the IDCS system is requesting an access token for the IDCS system. Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system." Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token) that is used to access a first identity management system (e.g., Identity Cloud Service (IDCS)) can be exchanged for a second type of token (e.g., proof of possession (PoP) token) that is used to access a second identity management system (e.g., Infrastructure Identity and Access Management (IAM)), and vice versa" The bearer token/access token are interpreted as equivalent since they both are a first type of token. The access/bearer token/IDCS token is interpreted as an authentication artifact of a first instance.).
determining [a] proof code is valid, resulting in a validated authentication artifact; (Paragraph 55, "FIG. 1 illustrates a general overview of a method 100 for exchanging tokens, in accordance with some example embodiments. The method 100 shown in FIG. 1 can be performed by a token exchange system of an Integrated Identity Management System (IDMS). The token exchange can be performed to exchange a bearer token for a proof of possession (PoP) token, or to exchange a PoP token for a bearer token. In an example embodiment, a token for a first identity system can be exchanged to obtain a different type of token for a second identity system." Paragraph 131-135, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application. At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key. At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid. At step 740, the token exchange system can generate a second token for the second identity system based on the first token for the first identity system. At step 750, the token exchange system can sign the second token with the private key of the entity to generate a second signed token." The proof code is interpreted as the public key and signature associated with a private key on the request that comes with the first token, this token being interpreted as the authentication artifact.).
and transmitting [a] validated authentication artifact to the first instance. (Paragraph 20 "An example embodiment can include a method including determining, by a token exchange system of an integrated identity management system of a cloud service, that an entity is authorized to access a first identity system, wherein the entity is an application, generating, by the token exchange system, a first request for the entity to access a second identity system, wherein the first request includes a bearer token and a first public key associated with the entity, verifying, by the token exchange system, that the bearer token is a valid bearer token, verifying, by the token exchange system, whether a role of the entity is a role that is authorized to access the second identity system, generating, by the token exchange system, a second token based on the bearer token and the first public key received in the first request, and sending, by the token exchange system, the second token to the entity, wherein the second token is associated with the second identity system, and the second token includes the first public key of the entity." The entity is the first instance, the signed authentication artifact is interpreted as the second token.)
However, Evani does not teach receiving … a proof code and a credential of a user account; responsive to authenticating the credential of the user account, generating … artifact comprising the proof code; determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
RFC 6479 teaches receiving … a credential of a user account; (RFC 6749, Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
responsive to authenticating the credential of the user account, generating … artifact comprising … (Page 5, "The authorization server authenticates the client and validates the authorization grant, and if valid, issues an access token." RFC 6749, Page 5, "The authorization code provides a few important security benefits, such as the ability to authenticate the client, as well as the transmission of the access token directly to the client without passing it through the resource owner's user-agent and potentially exposing it to others, including the resource owner." Fig. 1 shows the authorization grant being sent to the authorization server, where it then sends an access token.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani’s token exchange system with RFC 6749 by enhancing the access token issuance (Evani, Paragraph 10, "For example, a first type of token (e.g., bearer token, OAuth access token)”) to be an Oauth token, with the system performing a credential check on a token request and returning a Oauth token in response to authenticating the authorization code of the user. The motivation is to enhance Evani’s first token to use the Oauth 2.0 framework and adhere to the standard, so that access tokens are only given to trustworthy entities.
However, Evani in view of RFC 6749 does not teach receiving … a proof code … of a user account; generating … artifact comprising the proof code, determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
RFC 9449 teaches receiving … a proof code … of a user account; (Figure 1 shows a Token request comprising a dPop Proof. Page 6, "Roughly speaking, a DPoP proof is a signature over: some data of the HTTP request to which it is attached, a timestamp, a unique identifier, an optional server-provided nonce, and a hash of the associated access token when an access token is present within the request." Page 7, "In the token request, the client sends an authorization grant (e.g., an authorization code, refresh token, etc.) to the authorization server in order to obtain an access token (and potentially a refresh token). The client attaches a DPoP proof to the request in an HTTP header." Page 9, "A DPoP proof is a JWT [RFC7519] that is signed (using JSON Web Signature (JWS) [RFC7515]) with a private key chosen by the client (see below). The JOSE Header of a DPoP JWT MUST contain at least the following parameters: … jwk: Represents the public key chosen by the client in JSON Web Key (JWK) [RFC7517] format as defined in Section 4.1.3 of [RFC7515]. It MUST NOT contain a private key." The dpop public key associated with a private key is interpreted as a proof code of a user account. The credential is interpreted as the authorization code.).
generating … artifact comprising the proof code; (Figure 1, Page 7, "The authorization server binds (sender-constrains) the access token to the public key claimed by the client in the DPoP proof; that is, the access token cannot be used without proving possession of the respective private key. If a refresh token is issued to a public client, it is also bound to the public key of the DPoP proof." RFC 9449 page 14, "Resource servers MUST be able to reliably identify whether an access token is DPoP-bound and ascertain sufficient information to verify the binding to the public key of the DPoP proof (see Section 7.1). Such a binding is accomplished by associating the public key with the token in a way that can be accessed by the protected resource, such as embedding the JWK hash in the issued access token directly, using the syntax described in Section 6.1, or through token introspection as described in Section 6.2. Other methods of associating a public key with an access token are possible per an agreement by the authorization server and the protected resource; however, they are beyond the scope of this specification." RFC 9449, Page 15-16, "For a DPoP-bound access token, the hash of the public key to which the token is bound is conveyed to the protected resource as metainformation in a token introspection response. The hash is conveyed using the same cnf content with jkt member structure as the JWK Thumbprint confirmation method, described in Section 6.1, as a top-level member of the introspection response JSON." The artifact comprising the proof code is interpreted as the public key being stored inside the access token via hash.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749’s token exchange system with RFC 9449 by enhancing Evani in view of RFC 6749’s initially provided access/bearer token system to include a public key included in the request for a token, then having the token returned with a binding to the public key associated with the client’s session, as taught by RFC 9449. The motivation is to prevent spoofing and imitation attacks with the access/bearer token provided by Evani in view of RFC 6749’s system by building the proof of a secret key’s possession into the access token, preventing anybody but the secret key’s owner from being able to use the access token properly.
However, Evani in view of RFC 6749, in further view of RFC 9449 does not teach determining the proof code is valid, resulting in a validated authentication artifact; and transmitting the validated authentication artifact to the first instance.
determining the proof code is valid, resulting in a validated authentication artifact; (Paragraph 25, "The device can determine 504 the integrity of the challenge token by first verifying a CDS signature on the challenge token. The device can then decrypt 506 the challenge token using a self-generated key, as well as a persistent key for the device … The device, having successfully decrypted the challenge token, can then verify 508 the inner signature of the challenge token using the CDS public key. Once decrypted and verified, the device can determine 510 the manager information included in the token." Paragraph 23, "The device can then generate 610 a bearer token including the decrypted token and digitally signed by the device, effectively converting the challenge token to a bearer token." Paragraph 25, "The device can then combine 512 the signed but decrypted challenge token with the nonce from inside the token to create a bearer token, which can then be signed 514 with the self-generated device key. The self-generated key is used instead of the persistent device key as the manager should only be able to access information for the device while that manager is associated with that device, and not at any other time." Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication." The authentication artifact is interpreted as the challenge token. The proof code is interpreted as the signature, where if the signature shows that the sender of the challenge token indeed owns the private key and public key for which the token is for, the combined challenge token with nonce being used for the bearer token, then signing it, is interpreted as a signed authentication artifact.).
and transmitting the validated authentication artifact to the first instance. (Paragraph 25, "The device can then send 516 the bearer token to the determined manager with a request for configuration information, or other such communication.")
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449’s token exchange system with Major by enhancing Evani in view of RFC 6749, in further view of RFC 9449’s access/bearer token to POP (proof of possession) token conversion to include a step where the new token includes a signed previous token, the signature of the previous token a result of confirming the signature in the token is valid with the public key associated with the device who transmitted this token, as taught by Major. The motivation is to include a record of the POP token’s generation built into the token to prevent possible replay attacks with the previous token, as well as encoding the token’s origin for accounting purposes.
Regarding claim 22, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the computer-readable storage medium of claim 21. Evani teaches wherein said determining the proof code is valid comprises: providing the proof code to an ownership validator, causing the ownership validator to determine the proof code is valid and generate the validated authentication artifact. (Paragraph 25, "The device can determine 504 the integrity of the challenge token by first verifying a CDS signature on the challenge token. The device can then decrypt 506 the challenge token using a self-generated key, as well as a persistent key for the device … The device, having successfully decrypted the challenge token, can then verify 508 the inner signature of the challenge token using the CDS public key. Once decrypted and verified, the device can determine 510 the manager information included in the token." Paragraph 23, "The device can then generate 610 a bearer token including the decrypted token and digitally signed by the device, effectively converting the challenge token to a bearer token." Paragraph 25, "The device can then combine 512 the signed but decrypted challenge token with the nonce from inside the token to create a bearer token, which can then be signed 514 with the self-generated device key. The self-generated key is used instead of the persistent device key as the manager should only be able to access information for the device while that manager is associated with that device, and not at any other time." The authentication artifact is interpreted as the challenge token. The proof code is interpreted as the signature, where if the signature shows that the sender of the challenge token indeed owns the private key and public key for which the token is for, the combined challenge token with nonce being used for the bearer token, then signing it, is interpreted as a signed authentication artifact.).
Regarding claim 23, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the computer-readable storage medium of claim 21. Evani teaches the method further comprising:
receiving, from the first instance, an access request comprising the validated authentication artifact; (Paragraph 180, "At step 1160, the token exchange system can send the application the token signed by IAM. The token can be used by the application to make future API calls to IAM. The token can also be known as a key. By assigning a key to an application and the key can be used to ensure that the application is what it is claiming to be," The token the first token is exchanged for is interpreted as the signed authentication artifact, the future API calls are interpreted as access requests. The token validity checking system is interpreted as the artifact validator.)
determining the validated authentication artifact is valid; (Paragraph 186, "If the application makes future API calls, the token exchange system can receive a request for an API call to the IAM. The request includes the public token signed by IAM. The request is signed using the private key of the application." Paragraph 187, " The application can attach the token received from IAM in any requests and the application can sign also sign the request with the private key of the application. The application can prove is possesses a private key and a valid token from the IAM. Therefore, resources that application is trying to access can verify the identity of the application. The application can make future references to IAM API's by signing the request with the private key of the application and attaching the token signed by the IAM." The determining the signed authentication artifact is interpreted as the verification of the token included in the access request.).
and transmitting a forwarded access request to the application backend, the forwarded access request indicating the validated authentication artifact is valid and causing the application backend to provide the first instance access to a resource of the application backend. (Paragraph 187, "Therefore, resources that application is trying to access can verify the identity of the application." The verification of the application identity through the valid token from the IAM prior to resource access is interpreted as forwarding the request to the backend to provide the requesting application the resources it needed verification to request.).
Claim(s) 14 and 25 is/are rejected under 35 U.S.C. 103 as being unpatentable over Evani (US-20230100200-A1) in view of RFC 6749 (October 2012), in further view of RFC 9449 (September 2023), in further view of Major (WO-2025126478-A1), in further view of RFC 7591 (July 2015).
Regarding claim 14, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the method of claim 10. Evani teaches wherein said determining the proof code is valid comprises: determining the proof code is a proof of possession of a … key [used by] the first instance ... (Paragraph 131, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application." Paragraph 132, "At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key." Paragraph 133, "At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid." Paragraph 141, "IAM Application programming interfaces (API's) may only accept a connection from a resource or a service. If the entity is not a resource or a service, then the entity cannot communicate with the IAM API. IAM API's depend on getting a signed request where the request is signed by a private key and only the requestor has the private key." The public key (proof code) is determined to be a proper proof of possession of the secret key in the key pair, not requiring the first instance to provide the secret key itself.).
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not teach … a registration key issued to the … instance by an application registration service.
RFC 7591 teaches … a registration key issued to the … instance by an application registration service. (RFC 7591, Page 7, "The authorization server registers the client and returns: * the client's registered metadata, * a client identifier that is unique at the server, and * a set of client credentials such as a client secret, if applicable for this client." A client secret is interpreted as a registration key to a first instance.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with RFC 7591by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s application private key system to use a private key given by a server in response to giving the server registration data, as taught by RFC 7591. The motivation is to give the system a way to generate keys of a more standardized format for clients to use, thus organizing the way in which keys are generated, as well as providing a system to register clients with the authorization server so that the client can make communication sessions with the server in the future.
Regarding claim 25, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Majo teaches the computer-readable storage medium of claim 21. Evani teaches wherein said determining the proof code is valid comprises:
determining the proof code is a proof of possession of a … key [used by] the first instance ... (Paragraph 131, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application." Paragraph 132, "At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key." Paragraph 133, "At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid." Paragraph 141, "IAM Application programming interfaces (API's) may only accept a connection from a resource or a service. If the entity is not a resource or a service, then the entity cannot communicate with the IAM API. IAM API's depend on getting a signed request where the request is signed by a private key and only the requestor has the private key." The public key (proof code) is determined to be a proper proof of possession of the secret key in the key pair, not requiring the first instance to provide the secret key itself.)
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not teach … a registration key issued to the … instance by an application registration service.
RFC 7591 teaches … a registration key issued to the … instance by an application registration service. (RFC 7591, Page 7, "The authorization server registers the client and returns: * the client's registered metadata, * a client identifier that is unique at the server, and * a set of client credentials such as a client secret, if applicable for this client." A client secret is interpreted as a registration key to a first instance.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with RFC 7591by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s application private key system to use a private key given by a server in response to giving the server registration data, as taught by RFC 7591. The motivation is to give the system a way to generate keys of a more standardized format for clients to use, thus organizing the way in which keys are generated, as well as providing a system to register clients with the authorization server so that the client can make communication sessions with the server in the future.
Claim(s) 5, 13, 24 is/are rejected under 35 U.S.C. 103 as being unpatentable over Evani (US-20230100200-A1) in view of RFC 6749 (October 2012), in further view of RFC 9449 (September 2023), in further view of Major (WO-2025126478-A1), in further view of Balijepalli (US-20190197251-A1).
Regarding claim 5, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the system of claim 4. However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not teach further comprising an artifact validator that receives, from a second instance of the application frontend, an access request comprising the signed authentication artifact; determines the signed authentication artifact is invalid based on the signed authentication artifact being bound to the first instance; and denies the second instance access to the application backend.
Balijepalli teaches a system further comprising an artifact validator that: receives, from a second instance of the application frontend, an access request comprising the signed authentication artifact; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The previous token(s) is/are interpreted as the signed authentication artifact. The client device using previous tokens issued by the security server without the updated subset for requests are interpreted is interpreted as a second instance.)
determines the signed authentication artifact is invalid based on the signed authentication artifact being bound to the first instance; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The tokens being rejected for being previously issued tokens is interpreted as having them bound to a previous/first instance, and being rejected based on the fact it's bound to a first instance.).
and denies the second instance access to the application backend. (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset. Accordingly, application server 120 may reject tokens having the indicated session ID." The application server rejecting these requests is interpreted as denying the second instance access to the application backend.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with Balijepalli by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token handling system to include a token rejection system, where old tokens are not allowed to be reused, them being rejected, as taught by Balijepalli. The motivation is to prevent tokens from previous instances and sessions from being reused from unauthorized users and causing security breaches.
Regarding claim 13, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the method of claim 10, further comprising: binding the validated authentication artifact to the first instance; (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 62, "The tokens can be session based. That is, while a user is authenticated in a session, the tokens can continue to be used. The tokens can also be browser based. If a user is logging into a browser using a sign on session, the length that the tokens can continue to be used can be based on the browser session." The IDCS and IAM tokens (they are proof of possession tokens interpreted as signed authentication artifacts) being session based is interpreted as binding the signed authentication artifact to the first instance.).
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not explicitly teach receiving, from a second instance of the application frontend, an access request comprising the validated authentication artifact and determining the validated authentication artifact is invalid based on the validated authentication artifact being bound to the first instance;
Balijepalli teaches receiving, from a second instance of the application frontend, an access request comprising the validated authentication artifact; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The previous token(s) is/are interpreted as the signed authentication artifact. The client device using previous tokens issued by the security server without the updated subset for requests are interpreted is interpreted as a second instance.)
determining the validated authentication artifact is invalid based on the validated authentication artifact being bound to the first instance; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The tokens being rejected for being previously issued tokens is interpreted as having them bound to a previous/first instance, and being rejected based on the fact it's bound to a first instance.).
and denying the second instance access to the application backend. (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset. Accordingly, application server 120 may reject tokens having the indicated session ID." The application server rejecting these requests is interpreted as denying the second instance access to the application backend.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with Balijepalli by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token handling system to include a token rejection system, where old tokens are not allowed to be reused, them being rejected, as taught by Balijepalli. The motivation is to prevent tokens from previous instances and sessions from being reused from unauthorized users and causing security breaches.
Regarding claim 24, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the computer-readable storage medium of claim 21. Evani teaches the method further comprising:
binding the validated authentication artifact to the first instance; (Paragraph 116, "In the example shown in FIG. 6, an IDCS service, such as SaaS and PaaS, which has an IDCS token (e.g., bearer token) would like to access a service of an IAM system. The user is authenticated and they have logged into an IDCS system and have obtained an IDCS token. In a same session, the user can obtain a token for the IAM system. A user can refer to a product, an application or service of an application that would like to access features of the IAM system. A service of the IAM system can include IAM data services and storage services. PaaS and SaaS services of the IDCS can make sure of any data services of the IAM using the IAM generated token." Paragraph 62, "The tokens can be session based. That is, while a user is authenticated in a session, the tokens can continue to be used. The tokens can also be browser based. If a user is logging into a browser using a sign on session, the length that the tokens can continue to be used can be based on the browser session." The IDCS and IAM tokens (they are proof of possession tokens interpreted as signed authentication artifacts) being session based is interpreted as binding the signed authentication artifact to the first instance.).
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not explicitly teach receiving, from a second instance of the application frontend, an access request comprising the validated authentication artifact; determining the validated authentication artifact is invalid based on the validated authentication artifact being bound to the first instance; and denying the second instance access to the application backend.
Balijepalli teaches receiving, from a second instance of the application frontend, an access request comprising the validated authentication artifact; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The previous token(s) is/are interpreted as the signed authentication artifact. The client device using previous tokens issued by the security server without the updated subset for requests are interpreted is interpreted as a second instance.)
determining the validated authentication artifact is invalid based on the validated authentication artifact being bound to the first instance; (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset." The tokens being rejected for being previously issued tokens is interpreted as having them bound to a previous/first instance, and being rejected based on the fact it's bound to a first instance.).
denying the second instance access to the application backend. (Paragraph 36, "For example, when security server 110 updates the subset of permissions included in token 150 in response to permission request 160, security server 110 may request that application server 120 reject requests from client device 130 that include previous tokens issued by security server 110 that do not have the updated subset. Accordingly, application server 120 may reject tokens having the indicated session ID." The application server rejecting these requests is interpreted as denying the second instance access to the application backend.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with Balijepalli by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token handling system to include a token rejection system, where old tokens are not allowed to be reused, them being rejected, as taught by Balijepalli. The motivation is to prevent tokens from previous instances and sessions from being reused from unauthorized users and causing security breaches.
Claim(s) 6-8, 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Evani (US-20230100200-A1) in view of RFC 6749 (October 2012), in further view of RFC 9449 (September 2023), in further view of Major (WO-2025126478-A1) , in further view of RFC 7591 (July 2015), in further view of Kohji (WO-2025126478-A1).
Regarding claim 6, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major teaches the system of claim 1. However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not teach the system further comprising an application registration service that: receives, from the first instance, a registration code indicating the user account is an authorized user account of the application backend; and responsive to validating the registration code, transmits a registration key to the first instance.
RFC 7591 teaches a system further comprising an application registration service that: receives, from the first instance, a registration [data] … (RFC 7591, Page 7,"The client or developer calls the client registration endpoint with the client's desired registration metadata, optionally including the initial access token from (A) if one is required by the authorization server.")
and responsive … registration [data] …, transmits a registration key to the first instance. (RFC 7591, Page 7, "The authorization server registers the client and returns: * the client's registered metadata, * a client identifier that is unique at the server, and * a set of client credentials such as a client secret, if applicable for this client." A client secret is interpreted as a registration key to a first instance.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s token exchange system with RFC 7591 by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major’s application private key system to use a private key given by a server in response to giving the server registration data, as taught by RFC 7591. The motivation is to give the system a way to generate keys of a more standardized format for clients to use, thus organizing the way in which keys are generated.
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591 does not teach … a registration code indicating the user account is an authorized user account of the application backend and responsive to validating the registration code, transmit[ting] [secure session information] …
Kohji teaches … a registration code indicating the user account is an authorized user account of the application backend (Page 3, paragraph 1, "The user terminal 3 obtains token data from the authentication server 1. The user terminal 3 transmits the token data to the providing server 2 and receives a registration code from the providing server 2. The user terminal 3 transmits the registration code to the providing server 2 and requests the establishment of a tunnel between the processing unit 25 of the application provided by the providing server 2 and the user terminal 3. Once the tunnel is established, the user terminal 3 uses the established tunnel to enjoy the application service provided by the processing unit 25." Fig. 3 and Fig. 4 show an authentication server initially receiving a login, a token is generated, then given to the user terminal, who gives the token to a provided server that stores the token and gives a registration code in response. The code is then given to the provided server, which checks to see if the code is valid, then permits a tunnel establishment to access an application, thus meaning the registration cod4e indicates the user account is authorized for the application backend.).
responsive to validating the registration code, transmit[ting] [secure session information] … (Page 3, paragraph 3, "In the present disclosure, an SSH tunnel is established between the user terminal 3 and a processing unit 25 that provides an application service used by the user terminal 3. At this time, the authentication system 8 establishes the tunnel while ensuring sufficient security even if the amount of authentication information data that can be transmitted is limited during authentication before the SSH tunnel is established, etc., in the software that realizes SSH." Fig. 3 and Fig. 4 show that after the registration code is validated, an SSH tunnel is established, requiring secure session information to be exchanged between the user and provided server.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591’s token exchange system with Kohji by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591’s client key generation and receiving system to include a user sign in feature, where the user signs in, receives a token they can use/authenticate to obtain a registration code, this registration code giving the client the ability to configure a communication session for later application communication after transmitting it, as taught by Kohji. The motivation is to prevent unauthorized users from being able to request key generation and transmission, making sure to use this sign in step to filter out possibly malicious requests that would waste server resources.
Regarding claim 7, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji teaches the system of claim 6. Evani teaches wherein to determine the proof code is valid, the ownership validator:
determines the proof code is a proof of possession of the … key, without requiring the first instance to provide the … key to the ownership validator. (Paragraph 131, "At step 710, the token exchange system can determine that an entity is authorized to access a first identity system. The entity can be an application." Paragraph 132, "At step 720, the token exchange system an receive a first request by the entity to access a second identity system. The first request can include a bearer token and a public key." Paragraph 133, "At step 730, the token exchange system can verify that the token is valid. The token can be determined to be valid if the signature on the request is valid." Paragraph 141, "IAM Application programming interfaces (API's) may only accept a connection from a resource or a service. If the entity is not a resource or a service, then the entity cannot communicate with the IAM API. IAM API's depend on getting a signed request where the request is signed by a private key and only the requestor has the private key." The public key (proof code) is determined to be a proper proof of possession of the secret key in the key pair, not requiring the first instance to provide the secret key itself.).
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major does not teach a … registration key … RFC 7591 teaches … registration key … (RFC 7591, Page 7, "The authorization server registers the client and returns: * the client's registered metadata, * a client identifier that is unique at the server, and * a set of client credentials such as a client secret, if applicable for this client." A client secret is interpreted as a registration key to a first instance.).
The motivation to combine Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major and RFC 7591 is the same as in claim 6.
Regarding claim 8, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji teaches the system of claim 6. Kohji teaches wherein the application registration service further: receives, from the first instance, a registration request; (Page 3, paragraph 1, "The user terminal 3 obtains token data from the authentication server 1. The user terminal 3 transmits the token data to the providing server 2 and receives a registration code from the providing server 2. The user terminal 3 transmits the registration code to the providing server 2 and requests the establishment of a tunnel between the processing unit 25 of the application provided by the providing server 2 and the user terminal 3. Once the tunnel is established, the user terminal 3 uses the established tunnel to enjoy the application service provided by the processing unit 25." Fig. 3 and Fig. 4 show an authentication server initially receiving a login, a token is generated, then given to the user terminal, who gives the token to a provided server that stores the token and gives a registration code in response. The code is then given to the provided server, which checks to see if the code is valid, then permits a tunnel establishment to access an application, thus meaning the registration cod4e indicates the user account is authorized for the application backend. Fig. 3 shows a user login, interpreted as a registration request received from the first instance.).
causes the identity provider to generate a registration token indicating the user account is authenticated for registration; (The identity provider is interpreted as the authentication server shown in figure 3. The registration token is interpreted as the token given to the user terminal, who then gives it to the provided server.).
and causes an administrator server to provide the client computing device access to the registration code. (The administrator server is interpreted as the computing component of the provided server transmitting the registration code to the user device.).
The motivation to combine Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591 with Kohji is the same as in claim 6.
Regarding claim 15, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591 teaches the method of claim 14. RFC 7591 teaches wherein the authentication service further comprises the application registration service and the method further comprises:
receiving, from the first instance, a registration [data] … (RFC 7591, Page 7,"The client or developer calls the client registration endpoint with the client's desired registration metadata, optionally including the initial access token from (A) if one is required by the authorization server.")
and responsive to … registration [data], transmitting a registration key to the first instance. (RFC 7591, Page 7, "The authorization server registers the client and returns: * the client's registered metadata, * a client identifier that is unique at the server, and * a set of client credentials such as a client secret, if applicable for this client." A client secret is interpreted as a registration key to a first instance.).
The motivation to combine Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major with RFC 7591 is the same as in claim 14.
However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591 does not teach … a registration code indicating the user account is an authorized user account of the application backend and a registration token indicating the user account is authenticated for registration by an identity provider; and responsive to validating the registration code, transmitting [secure session information] …
Kohji teaches … a registration code indicating the user account is an authorized user account of the application backend and a registration token indicating the user account is authenticated for registration by an identity provider (Page 3, paragraph 1, "The user terminal 3 obtains token data from the authentication server 1. The user terminal 3 transmits the token data to the providing server 2 and receives a registration code from the providing server 2. The user terminal 3 transmits the registration code to the providing server 2 and requests the establishment of a tunnel between the processing unit 25 of the application provided by the providing server 2 and the user terminal 3. Once the tunnel is established, the user terminal 3 uses the established tunnel to enjoy the application service provided by the processing unit 25." Fig. 3 and Fig. 4 show an authentication server initially receiving a login, a token is generated, then given to the user terminal, who gives the token to a provided server that stores the token and gives a registration code in response. The code is then given to the provided server, which checks to see if the code is valid, then permits a tunnel establishment to access an application, thus meaning the registration cod4e indicates the user account is authorized for the application backend.).
and responsive to validating the registration code, transmitting [secure session information] … (Page 3, paragraph 3, "In the present disclosure, an SSH tunnel is established between the user terminal 3 and a processing unit 25 that provides an application service used by the user terminal 3. At this time, the authentication system 8 establishes the tunnel while ensuring sufficient security even if the amount of authentication information data that can be transmitted is limited during authentication before the SSH tunnel is established, etc., in the software that realizes SSH." Fig. 3 and Fig. 4 show that after the registration code is validated, an SSH tunnel is established, requiring secure session information to be exchanged between the user and provided server.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591’s token exchange system with Kohji by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591’s client key generation and receiving system to include a user sign in feature, where the user signs in, receives a token they can use/authenticate to obtain a registration code, this registration code giving the client the ability to configure a communication session for later application communication after transmitting it, as taught by Kohji. The motivation is to prevent unauthorized users from being able to request key generation and transmission, making sure to use this sign in step to filter out possibly malicious requests that would waste server resources.
Claim(s) 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Evani (US-20230100200-A1) in view of RFC 6749 (October 2012), in further view of RFC 9449 (September 2023), in further view of Major (WO-2025126478-A1) , in further view of RFC 7591 (July 2015), in further view of Kohji (WO-2025126478-A1), in further view of Barnes (US-20110246212-A1).
Regarding claim 9, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji teaches the system of claim 8. However, Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji does not teach a system that wherein to cause the administrator server to provide the client computing device access to the registration code, the application registration service further: causes a prompt to be displayed in a user interface of an administrator computing device communicatively coupled to the administrator server, the prompt comprising a request to authorize the client computing device, the application frontend, or the user account.
Barnes teaches wherein to cause the administrator server to provide the client computing device access to the registration code, the application registration service further: causes a prompt to be displayed in a user interface of an administrator computing device communicatively coupled to the administrator server, the prompt comprising a request to authorize the client computing device, the application frontend, or the user account. (Paragraph 35, "Thus, the interface for the respective user role comprises different types of information due to the variation in the functions, permissions, internal controls and firewalls for the respective user role, which will be discussed with the modules associated with the user roles below. Each role has a unique "Today Page" to interface with the system." Paragraph 66, " FIG. 6B illustrates a fine art dealer registration request review process, according to one embodiment. An administrator 106 (or internal user) receives a new dealer application on the internal Today Page 608. An administrator 106 or internal user reviews the dealer user's request for registration on the internal dealer application list system site 609. The administrator 106 (or internal user) checks to see if the information is complete and valid 610. If the information is valid and complete, the administrator 106 checks the "Is Active" checkbox and generates a temporary UserID and password 611, and the dealer applicant is sent an e-mail notification that contains login credentials. The dealer applicant is invited by e-mail to log in and fill out the due diligence form 612. If the information is not valid and/or complete, the administrator 106 contacts the dealer applicant by computer via e-mail to adjust the application 614." The prompt to be displayed is interpreted as the new dealer application received on the internal today page, which is the interface used for interfacing with the system. The system is the today page of the administrator is connected to is interpreted as an administrator computing device connected to an administrator server. The prompt is interpreted as authorization for the user account/application frontend/client device to register with the system, the authorization code/email containing login credentials being seen as the registration code.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji’s token exchange system with Barnes by enhancing Evani in view of RFC 6749, in further view of RFC 9449, in further view of Major, in further view of RFC 7591, in further view of Kohji’s administrator system’s registration code transmission to include a human administrator at the server that can receive and authorize user requests to receive registration information from the administrator server, as taught by Barnes. The motivation is in the case certain functionalities of the administration server isn’t working, it is still possible for users to access applications through receiving registration codes with a human fallback option, maintaining high availability.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
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, Rupal Dharia can be reached at 571-272-3880. 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.
/M.H.R./Examiner, Art Unit 2492
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491
Prosecution Insights