04DETAILED ACTION
This Final Office Action is in response to amendment filed on 04/30/2025. Claims
1, 3, 5, 9, 10, 14 and 21 have been amended. Claims 1-23 remain pending in the application.
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 .
Response to Amendment
The amended filed on 04/30/2025 has been entered. See above on lines 1-3 of
this office action.
Response to Arguments
Remarks regarding rejections under 35 U.S.C § 101 filed 04/30/2025 Applicant’s amendment to Claims 1, 10, 14 and 21 and arguments are carefully considered and are persuasive and overcome the rejection under 35 U.S.C § 101 in respect to the abstract idea.
Rejection is maintained in regard with claims 21-23 Applicant did not address the software per se rejection to the claims 21-23 directed to a “software per se”.
Rejection is maintained in regard with claims 10-13 Applicant did not address the software per se rejection to the claims 10-13 directed to a “software per se”.
Remarks regarding rejections under 35 U.S.C § 103 filed 04/30/2025 Applicant’s amendment to Claims 1,3, 5, 9, 10, 14 and 21 and arguments are carefully considered and are persuasive. However, upon further consideration, arguments are moot in view of new grounds of rejection.
With respect to applicant’s argument to the remaining dependent claims 2, 4, 6-8, 11-13, 15-20, and 22-23 on pages 8 of the remark, the applicant is relying on the newly added amendments of the independent claims 1, 10, 14, and 21. Please see examiner’s response above and the detail of the rejection below.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 10-13 are rejected under 35 U.S.C. 101 because the claimed invention is
directed to non-statutory subject matter. The claims do not fall within at least one of the
four categories of patent eligible subject matter because the claims are directed to a
"Software per se" are directed to an access application that is merely a software per se
that does the user authentication. Applicant claims an access application in each claim 10-13 but the claims do not positively recite any hardware element[s] or algorithm. Although applicant claims, “an interface”, “Authentication utility” and “session engine”, the terms “interface”, “authentication utility”, and “session engine” are generally understood to include software. Therefore claims 10-13 are directed to software which is not a patent eligible subject matter, and hence rejected as "software per se".
Claims 21-23 are rejected under 35 U.S.C. 101 because the claimed invention is
directed to non-statutory subject matter. The claims do not fall within at least one of the
four categories of patent eligible subject matter because the claims are directed to a "Software per se"
Applicant claims a database in each of the claim 21-23 but the claims do not
positively recite any hardware elements[s]. although applicant claims an "interface" and "a data engine", yet the terms "interface" and "data engine" are generally understood to include software. Therefore claims 21-23 are directed to software which is not a patent eligible subject matter, hence rejected as "software per se".
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 14 – 16, and 19 are rejected under 35 U.S.C. 102 (a)(1)as being anticipated by Poole Siguero et al. (US-20230388119-A1 hereafter Siguero).
For claim 14 (Currently Amended) Siguero discloses a method comprising:
receiving a database request from an access application, the database request including an identity assertion token that has a header, a payload including an encrypted personal identifier, and an authentication utility digital signature, the personal identifier identifying a user (see Siguero par.0060: “the client transmits a request for service to the server, and the server processes the request
and sends a communication to the client which is responsive to the request. This process is repeated for each request/ response between the client and server. The communications depicted in this figure make use of the HTTP-only cookie and encrypted JWT payload.”, par.0061: “the client transmits a request for service to the server, and the server processes the request and sends a communication to the client which is responsive to the request. This process is repeated for each request/ response between the client and server. The communications depicted in this figure make use of the HTTP-only cookie and encrypted JWT payload.”, par:0049 “The JWT 300 includes a
header 310, a payload 320 and a signature 330. Header 310 includes information identifying the type of token ("JWT") and the algorithm used to generate the signature, which in this example is "HS256". Payload 320 includes information about the user for authentication and/or authorization ( e.g., users, roles, groups, etc.). Signature 330 is generated using the algorithm identified in the header, applied to the encoding of the header and the encoding of the payload.”). The authentication signature 330 is a signature that can be adequate for the authentication utility digital signature which is consistent with applicant instant application par.0062: In some embodiments the authentication utility is integrated into the access application. The approval of the authentication utility signature wrap in http-only cookie can be verify. Siguero par.0062: “if the authentication gateway is able to obtain the JWT header, JWT pay load and JWT signature from the browser's request, these components are then used to reconstruct the original JWT step 530). Using the reconstructed JWT, the authentication gateway determines whether the JWT signature is valid (step 535)”;
decrypting the personal identifier (see Siguero par.0061: “when the
request for service is received by the authentication gateway of the server, the gateway extract the encrypted header and signature from the cookie and decrypts them to obtain the original JWT header and JWT signature (step 510). The authentication gateway also extracts the encrypted JWT payload from the request header and decrypts it to obtain the original JWT payload (step 515).”.);
comparing a stored personal identifier associated with the user to the decrypted personal identifier of the identity assertion token (see Siguero par.0065: “When the request is received by the server, the server extracts the encrypted JWT signature and JWT header from the secure HTTP-only cookie and decrypts them. The algorithm in the JWT header is identified, and is used to generate a signature corresponding to the JWT header plus JWT payload. This generated signature is compared to the JWT signature that was contained in the secure HTTP-only cookie to verify that the components of the JWT have not been tampered with. If the generated signature matches the extracted JWT signature, the signature is verified, and the request is authenticated, so access to the server is allowed in accordance with the user information that is contained in the JWT payload.”.);
determining that the authentication utility digital signature is of an approved authentication utility (see Siguero par.0062: “if the authentication gateway is able to obtain the JWT header, JWT pay load and JWT signature from the browser's request, these components are then used to reconstruct the original JWT step 530). Using the reconstructed JWT, the authentication gateway determines whether the JWT signature is valid (step 535). since the JWT signature was originally generated based on the JWT header and JWT payload, validation of the JWT comprises substantially the same process. In other words, a signature is generated based on the recovered JWT header and JWT payload, and this newly generated signature is compared to the JWT signature. If the newly generated signature matches the original JWT signature, the JWT is valid.”.);
performing the database request on the database based on the comparing and the determining (see Siguero par.0063: “if the JWT signature is determined to be valid (step 540), the server processes the request, generates a response to the request and returns this response to the browser (step 550). Processing the request may include, for example, examine the JWT payload to determine authorization information
that is contained in the payload such as users, roles and groups and the like, and then enforce applicable rules to enable access to the server in accordance with the authorization information in the JWT payload.”.);
generating a reply in response to performing the database request (see Siguero par.0065: “The server then generates a response to the request and returns the response with the secure HTTP-only cookie (not shown in the figure).”); and
sending the reply to the access application. (See Siguero par.0064: “When the browser receives the response, it processes the corresponding information (step 555), and the communication cycle corresponding to the browser's request is complete.”.).
For claim 15 (Original) Siguero discloses the method of claim 14, Siguero further discloses wherein receiving a database request comprises receiving the database request from an access application through a secure session with the access application. (See Siguero par.009: “The request from the browser may be received via a secure communication channel (e.g., uses HTTPS protocol).”)
For claim 16 (Original) Siguero discloses the method of claim 14, Siguero further discloses wherein receiving the database request comprises receiving a database identification of the user, the method further comprising applying the database identification to a record of the database and wherein comparing a stored personal identifier comprises comparing a stored personal identifier associated with the record. (See Siguero par.0049: “the browser to transmit and authentication request to the authentication gateway of the server. The authentication request includes credentials for the user. When the authentication gateway receives the authentication request from the browser, it extracts the user credentials and authenticates the credentials”, par.0058: “the request containing the user information is transmitted from the client to the server. When the server receives the request, it extracts the user information from the request. The server already has the information identifying the algorithm to be used to generate the JWT components, and knows that the algorithm will be used to generate a JWT-type token. The algorithm and token type are combined ( e.g., after being encoded with base64URLencoding) and encrypted to form the JWT header. The user information received from the client is also encoded (using base64URLencoding) encrypted to form the JWT payload. The JWT header and JWT payload are then signed using the algorithm to form the JWT signature. The server then has all three components of the JWT (JWT header, JWT payload and JWT signature).”, par.0061-62: “when the request for service is received by the authentication gateway of the server, the gateway extract the encrypted header and signature from the cookie and decrypts them to obtain the original JWT header and JWT signature (step 510). The authentication gateway also extracts the encrypted JWT payload from the request header and decrypts it to obtain the original JWT payload (step 515)… a signature is generated based on the recovered JWT header and JWT payload, and this newly generated signature is compared to the JWT signature. If the newly generated signature matches the original JWT signature, the JWT is valid.”.).
For claim 19 (Original) Siguero discloses the method of claim 14, Siguero further discloses wherein the reply comprises at least one of an acknowledgment, read data, and a computed result. (See Siguero par.0065: “The algorithm in the JWT header is identified, and is used to generate a signature corresponding to the JWT header plus JWT payload. This generated signature is compared to the JWT signature that was contained in the secure HTTP-only cookie to verify that the components of
the JWT have not been tampered with. If the generated signature matches the extracted JWT signature, the signature is verified, and the request is authenticated, so access to the server is allowed in accordance with the user information that is contained in the JWT payload. The server then generates a response to the request and returns the response with the secure HTTP-only cookie (not shown in the figure).”.).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
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 1 - 3, and 6 - 8 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US- US 9,613,224 B2 hereafter Wang), in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in further view of Dunjic et al. (US-11811748-B2 hereafter Dunjic).
For claim 1 (Currently Amended) Wang discloses a method comprising
receiving a user authentication request from an end client, the user authentication request being a request to access a database (see Wang column 9 line [54-55]: “The user provides a username and password”) which is consistent with applicant publication in par. [0061 ]: includes receiving a user authentication request from an end client. (See Wang column 3 line [50-52]: “Each of clients 102 and 104 submit requests, initiated by end-users, to middle tier 110. Each of clients 102 and 104 may be a web browser”). Examiner interpret that request received by the client application 112 and 114 is a user authentication base on (Wang column 4 line [ 41-42]: one service that middle tier may provide to applications112 and 114 is an authentication service). The authentication request is a request to verify the user credentials. In Fig 1 the user (e.g., client 2 or client 4) is being authenticated through a middle tier 110 client application 112 or 114. The authentication process is done by the user providing email and password.);
authenticating the user (see Wang column 11 line [44]: “The user client 2 is authenticated by the middle tier application 112) the client credentials are sent to an external authentication server for authentication.”);
receiving a database request from the end client (see Wang column 10 line [26-27]: “at block 212, a data request from application 112 is received). The data request from the end client is received by the middle tier. Application 112 represent the end user”, column 10 line [29-31]: “data request from application 112 is executed in the context (i.e., Subjec.doASin Java) of the object that represents the end user).“.);
sending the database request to the database with the identity assertion token (see Wang column 10 line [42-44]: “the identifier and version number (received
in block 210) is inserted into the request to create a modified request”). (Line [49-50]: “At block 216, the modified request is sent to database system 120).”).
Wang appear to be silence on obtaining an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including an encrypted and an authentication utility digital signature;
receiving a reply from the database in response to the database request in response to after decryption corresponding and the authentication utility digital signature being of an approved authentication utility; and
sending the reply to the end client.
However, Fischer discloses obtaining an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including an encrypted and an authentication utility digital signature (see Fischer Col.6 lines24-50: “the client 302 initially connects to the authentication/authorization service (AAS) 306 as shown in step 31 and provides user credentials as part of the authentication request…. The EIP 308 then verifies credentials and obtains the user group membership (33). The EIP 308 could be configured for each tenant separately, or for multiple tenants. After verification (33), the AAS 306 returns the result, which is the user group membership if verification is successful (34). The AAS 306 next performs client authorization for each tenant, as shown in steps 35 to 37. In this process, the AAS first verifies client authorization during an authentication stage (35) and then verifies client authorization during an authorization phase (36), and then returns the result (37). The authorization results are encapsulated into a token, as shown in step 38…. After the token is returned to the client 302, the client requests a service from application service 304, as shown in steps 41 to 43. In this process, the service request from the client includes the valid token (41).”, Col 7 lines10-43: “the token's data is signed and encrypted, so that it is meaningless to a third party who may get access to the token. This prevents exposure of any information about the principal's roles and the different tenants, and renders the system safe from man-in-the-middle (MIM) or other similar attacks… The token's serialization, signature and encryption are implemented using the JWT protocol, which provides a compact URLsafe means of representing claims which are transferred between two parties in a distributed system. The claims in a MT are encoded as a JSON object that is used as the payload of a JSON web signature structure… the JWT 402 is composed of a header 404, a payload 406, and a signature 408.”); and
sending the reply to the end client (see Fischer Col.6 lines:45-46 “The resulting token is returned to the client 302 as shown in step 39.”).
It would be obvious to combine Wang teaching “a database system to enforce application data security policies based on the identity of an application user. The database system natively enforces application-defined policies within the database
system based on the application user's identity.”, (see Wang Col.3 lines:31-36), with Fischer teaching “the token's data is signed and encrypted, so that it is meaningless to a third party who may get access to the token. This prevents exposure of any information about the principal's roles and the different tenants, and renders the system safe from man-in-the-middle (MIM) or other similar attacks. The token's signature prevents unauthorized modification of its data. The token's serialization, signature and encryption are implemented using the JWT protocol, which provides a compact URLsafe means of representing claims which are transferred between two parties in a distributed system.”, (see Fischer Col.7 lines:18-28).
Wang in view of Fischer appear to be silence on receiving a reply from the database in response to the database request in response to after decryption corresponding and the authentication utility digital signature being of an approved authentication utility.
However, Dunjic teaches receiving a reply from the database in response to the database request in response to after decryption corresponding and the authentication utility digital signature being of an approved authentication utility (see Dunjic Col. 9 lines 6467-Col.10 lines1-43: “A cryptographic signature is then created by the client application. The signature may be generated based on a message that includes a combination of a first representation of the requested access token and the cryptographic nonce. The message data ( or a hash of the message data) may be encrypted with the user-specific private key in the secure enclave of the device. The signature itself may be generated in the secure enclave. The request to access the protected resource includes the access/bearer token, the cryptographic nonce, and the digital signature. The client application sends the request to the protected resource, in operation 526. The protected resource, in tum, requests the authorization server to verify the bearer token submitted by the client application, in operation 528. That is, the authorization server receives, from a web server associated with the protected resource, a request to validate the bearer token. In operation 530, the authorization server validates the bearer token. The digital signature may be verified by using the public key previously stored at the authorization server to decrypt the signature and comparing to the original data (i.e., the access token and cryptographic nonce). The cryptographic nonce may also be verified by the authorization server. In particular, the authorization server may compare the cryptographic nonce against a store of nonce values to ensure that the same value has not previously been used. The use of cryptographic nonce values can help to prevent token replay attacks, in which a client attempts to authenticate a relying party with a security token that the client has already
used. By recording, in memory of the authorization server, a cryptographic nonce associated with an access token for the duration of the expiry period of said token, the authorization server may be able to detect token replay. In response to validating the bearer token, the authorization server sends the web server associated with the protected resource a notification indicating that the bearer token is valid, in operation 532. For example, a message notifying the web server that the bearer token is valid may be generated and signed using a private key that is specific to the authorization server. The web server receives the notification message (and/or the digital signature generated based on the message) from the authorization server and verifies it. If the message can be verified, the web server responds to the request (e.g., API call) of the client application to the protected resource, in operation 534.”).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer teaching with Dunjic teaching “the processing unit may be further configured to: receive, via the communication inter face from a web server associated with the protected resource, a fourth signal including a request to validate a bearer token submitted by the client application to the web server, the bearer token including a digital signature; vali
date the bearer token, the validating including verifying the digital signature using the public key; and in response to validating the bearer token, send to the web server via the communication interface a fifth signal including a notification that the bearer token is valid.”, (see Dunjic Col.2 lines:41-51).
For claim 2 (Original) Wang in view of Fischer and Dunjic disclose the method of claim 1, Wang further disclose wherein authenticating the user comprises authenticating the user at an access application that is connected through a network to the end client (See Wang column 3 line [57-58]: “Middle tier 110 comprises one or more application server and applications 112 and 114 process client request... line [59-60]: middle tier 110 may include one or more services that applications utilize. Example services include user authentication... “). The end client is being authenticated in the middle tier application that act as an access application. that is connected through a network to the end client. (Wang column 3 line [50-54]: “Each of clients 102 and 104 submit requests, initiated by end-users, to middle tier 110. Each of clients 102 and 104 may be a web browser and the requests may be HTTP requests that are transmitted over a network using a communications protocol”). Which is consistent with applicant publication par. [0050]: The end client is connected to the access application through an intranet, a VPN (virtual private network), or the Internet.”).
For claim 3 (Currently Amended) Wang in view of Fischer and Dunjic disclose the method of claim 1, Fischer further discloses wherein authenticating the user comprises sending user credentials to an external authentication utility (See Fischer Col.6 lines24-28: “the client 302 initially connects to the authentication/authorization service (AAS) 306 as shown in step 31 and provides user credentials as part of the authentication request. The AAS 306 performs tenant-based authentication using an external identity provider (RIP) 308,”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 1 along with Fischer teaching “an external identity provider 108 provides certain credential information, such as stored in an identity (ID) database 118 for use by the tenant management 112 and stateless AA process 114. Elements of the AA server may be implemented in either a dedicated server 108 or as a process hosted by any other server in the network, such as server 102.”, (see Fischer Col.5 lines:15-21).
For claim 6 (Original) Wang in view of Fischer and Dunjic disclose the method of claim 1, Fischer further discloses further comprising sending the identity assertion token to the end client (see Fischer Col.6 lines42-47: “The authorization results are encapsulated into a token, as shown in step 38. That authorization information will be used by the application service 304 when enforcing Role Based Access Control (MAC). The resulting token is returned to the client 302 as shown in step 39. After the token is returned to the client 302.”.), and wherein receiving a database request comprises receiving the identity assertion token. (See Fischer Col.6 lines47-58: “After the token is returned to the client 302, the client requests a service from application service 304, as shown in steps 41 to 43. In this process, the service request from the client includes the valid token (41). The application service then processes the request based on the authorization included in the token (42), and returns the result to the user (43). The application service can be individually configured for each tenant or the same application service could serve several tenants. The application service 304 uses the provided token to make a decision whether to serve or deny the client request through the application and enforcement of RBAC rules and policies.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 1 along with Fischer teaching “The use of a token management process to encode the token with authentication results and transmit the token between the AAS, client and application service provides a built-in mechanism that eliminates the need for the application service to access the AAS during the request servicing phase. This greatly reduces the communications overhead in the process by eliminating the I/0 calls to the AAS typically needed during the application service portion of the overall client request session.”, (see Fischer Col.9 lines:56-64).
For claim 7 (Original) Wang in view of Fischer and Dunjic disclose the method of claim 1, Wang further discloses wherein sending the database request comprises sending the database request through a secure session with the database, (see Wang column 7 line [9-11]: Session manager 118 is responsible for managing sessions between applications in middle tier 110 and database system 120. through a secure session with the database. (Wang column 15 line [35-37]: connections between database system 120 and middle tier 110 are secured with a cryptographic communication protocol (such as Secure Sockets Layer (SSL)).”).
For claim 8 (Original) Wang in view of Fischer and Dunjic disclose the method of claim 1, Dunjic further disclose wherein the reply comprises data from a search report in the database request. (See Dunjic Col.6 lines 31-43: “In response to validating the bearer token, the authorization server sends the web server associated with the protected resource a notification indicating that the bearer token is valid, in operation 532. For example, a message notifying the web server that the bearer token is valid may be generated and signed using a private key that is specific to the authorization server. The web server receives the notification message (and/or the digital signature generated based on the message) from the authorization server and verifies it. If the message can be verified, the web server responds to the request (e.g., API call) of the client application to the protected resource, in operation 534.”.). Examiner interpret that the validation of the bearer token along with the signed private key indicating that is a valid token and then sent an notification to the web server that can be construed as result of a report and based on the valid result is sent to the client application.
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 1 along with Dunjic teaching “process 600 for regulating access to a protected resource. The process 600 may be performed by an authorization server, or at least a combination of a security token service and a server having a token endpoint and communicably coupled to both a requesting client application and an interface (e.g., web server, API, etc.) to a protected resource. The authorization server functions as an intermediary between the client application and the protected resource, facilitating authenticated requests by the client application to access the protected resource.”, (see Dunjic Col.10 lines:45-54).
Claim 4 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US- US 9,613,224 B2 hereafter Wang), in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in view of Dunjic et al. (US-11811748-B2 hereafter Dunjic), in further view of Rykowski et al. (US-20160366119-A1 hereafter Rykowski).
For claim 4 (Original) Wang in view of Fischer and Dunjic teach the method of claim 3.
Wang in view of Fischer and Dunjic appear to be silence on wherein obtaining the identity assertion token comprises obtaining the identity assertion token from the external authentication utility.
However, Rykowski teaches wherein obtaining the identity assertion token comprises obtaining the identity assertion token from the external authentication utility. (See Rykowski par.0027: “At step 321, the identity provider 206 authenticates the authentication application 221 either using user-provided security credentials or a registration credential, such as a long-lived token or password. At step 324, the identity provider 206 generates the requested identity assertion assuming that the client application 224 is to be permitted access to the service provider 209 using the federated identity. At step 327, the identity provider 206 sends the identity assertion to the authentication application 221. At step 330, the authentication application 221 provides the identity assertion to the client application 224.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 3 along with Rykowski teaching “one or more of the
service providers 209 can authenticate users separately from the identity provider 206, thereby giving users the option to log in either with the identity provider 206 or with the
service provider 209 directly.”, (see Rykowski par.0018).
For claim 5 (Currently Amended) Wang in view of Fischer, Dunjic, and Rykowski disclose the method of claim 4.
Rykowski further discloses wherein the personal identifier is retrieved from a database of the external authentication utility and inserted into the identity assertion token by the external authentication utility. (See Rykowski par.0026-0027: “the authentication application 221 receives the security credentials from the user. Upon receipt of the security credentials, the authentication application 221 requests the identity assertion from the identity provider 206 at step 318. At step 321, the identity provider 206 authenticates the authentication application 221 either using user-provided security credentials or a registration credential, such as a long-lived token or password. At step 324, the identity provider 206 generates the requested identity assertion assuming that the client application 224 is to be permitted access to the service provider 209 using the federated identity. At step 327, the identity provider 206 sends the identity assertion to the authentication application 221.”, par.0017: “the identity provider 206 can be in communication with an identity data store 215 that stores information associated with user identities. This information can include, for example, usernames, security credentials, biometric identity information, authorized client applications, unauthorized client applications, authorized client devices 203”.). Examiner interpret that the external identity provider along with identity data store sends the identity assertion (token) along with other inserted information to the client application.
PNG
media_image1.png
903
737
media_image1.png
Greyscale
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 4 along with Rykowski teaching “An identity assertion in security assertion markup language (SAML), for example, contains a packet of security information that service providers 209 use to make access control decisions. SAML supports three types of statements: authentication statements, attribute statements, and authorization decision statements. Authentication statements assert to the service provider 209 that the client device 203 authenticated with the identity provider 206 at a particular time using a particular method of authentication.”, (see Rykowski par.0022).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Wang et al. (US- US 9,613,224 B2 hereafter Wang), in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in view of Dunjic et al. (US-11811748-B2 hereafter Dunjic), in further view of Cook et al. (US-11770376-B2 hereafter Cook).
For claim 9 (Currently Amended) Wang in view of Fischer and Dunjic disclose the method of claim 1, Fischer further disclose wherein sending the database request comprises sending a database identification to the database, the database identification being unique to the user with a link at the database to a security policy (see Fischer par.6 lines: “That authorization information will be used by the application service 304 when enforcing Role Based Access Control (MAC). The resulting token is returned to the client 302 as shown in step 39. After the token is returned to the client 302, the client requests a service from application service 304, as shown in steps 41 to 43. In this process, the service request from the client includes the valid token (41). The application service then processes the request based on the authorization included in the token (42), and returns the result to the user (43). The application service can be individually configured for each tenant or the same application service could serve several tenants. The application service 304 uses the provided token to make a decision whether to serve or deny the client request through the application and enforcement of RBAC rules and policies.”.).
Wang in view of Fischer and Dunjic appear to silence on and wherein receiving a reply from the database comprises receiving a reply subject to permissions of the security policy associated with the database identification.
However, Cook teaches wherein receiving a reply from the database comprises receiving a reply subject to permissions of the security policy associated with the database identification. (See Cook Col.28 lines 6-18: “At 1316, the client 314 requests the protected resource from the resource server 312. The request may include an access token. At 1318, the resource server 312 introspects the access token using the authorization server 318. At 1320, the resource server 312 is given a resource owner relationship and list of granted resources by the authorization server 318. This may include or be represented by a resource owner token. The resource server 312 evaluates the grant against the rights of the resource owner 310.
At 1322, the resource server 312 releases the authorized protected resources to the client 314.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Wang in view of Fischer and Dunjic teaching of claim 1 along with Cook teaching “federated privacy exchange system configured to provide an authorization service for allowing the service provider client device to access the protected resource according to permissions data, the federated privacy exchange system comprising: a privacy-respecting authorization server configured to store a resource definition for the protected resource; and an agent device configured to: provide an agent interface for managing credentials and controlling permissions and policies at the authorization server.”, (see Cook Col.2 lines:19-28).
Claim 10, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Dunjic et al. (US-11811748-B2 hereafter Dunjic),in view of Fischer et al. (US-10742638-B1 hereafter Fischer).
For claim 10 (Currently Amended) Dunjic discloses an access application comprising
an end client interface to receive a user authentication request from an end client, the user authentication request being a request to access a database and to receive a database request from the end client (see Dunjic fig 5 and col.3 line33-65 : “When an end-user launches a client application on a device, the client application initiates authentication of the end-user in operation 510. In the context of an OpenID
Connect implementation, the client application ( or relying party) generates an OpenID authentication request (which may be an OAuth 2.0 authorization request to access the end-user's identity) via a browser (e.g., browser 320 of FIG. 3), in operation 512…Once the end-user is authenticated, the client application is provided with an authorization code in operation 514.”, Col.9 lines23-26: “the client application submits a request to the authorization server, in operation 518, to obtain an access token for use in accessing a
protected resource.”, Col 10 lines38-43: “The web server receives the notification message (and/or the digital signature generated based on the message) from the authorization server and verifies it. If the message can be verified, the web server responds to the request (e.g., API call) of the client application to the protected resource, in operation 534.”). Examiner interpret that the access application interface as the browser and/or the application programming interface; and
an external interface to send the database request to the database with the identity assertion token and to receive a reply from the database in response to the database request in response to after decryption corresponding and the authentication utility digital signature being of an approved authentication utility (see Dunjic Col.10 lines 45-50: “process 600 for regulating access to a protected resource. The process 600 may be performed by an authorization server, or at least a combination of a security token service and a server having a token endpoint and communicably coupled to both a requesting client application and an interface (e.g., web server, API, etc.) to a protected resource.” lines 8-37: “The client application sends the request to the protected resource, in operation 526. The protected resource, in tum, requests the authorization server to verify the bearer token submitted by the client application, in operation 528. That is, the authorization server receives from a web server associated with the protected resource, a request to validate the bearer token. In operation 530, the authorization server validates the bearer token. The digital signature may be verified by using the public key previously stored at the authorization server to decrypt the signature and comparing to the original data (i.e., the access token and cryptographic nonce). The cryptographic nonce may also be verified by the authorization server. In particular, the authorization server may compare the cryptographic nonce against a store of nonce values to ensure that the same value has not previously been used. The use of cryptographic nonce values can help to prevent token replay attacks, in which a client attempts to authenticate a relying party with a security token that the client has already used. By recording, in memory of the authorization server, a cryptographic nonce associated with an access token for the duration of the expiry period of said token, the authorization server may be able to detect token replay. In response to validating the bearer token, the authorization server sends the web server associated with the protected resource a notification indicating that the bearer token is valid, in operation 532. For example, a message notifying the web server that the bearer token is valid may be generated and signed using a private key that is specific to the authorization server.”.). Examiner interpret that the external interface use by the client application is the API, to send the request to the data use to database, also Examiner construed that the authorization server as the database that perform the decrypting the token (the identity assertion token) that will be compare with previously stored public key (record) and the cryptographic nonce (authentication utility);
wherein the end client interface sends the reply to the end client. (See Dunjic Col.8 lines 51-53: “the end-user may be prompted to provide their credentials and consent for signing into the client application.”, Col.5 lines:22-25: “an end-user is asked to authenticate and grant a client application access to the user's identity. In OAuth 2.0 implementations, a token endpoint of the identity provider service 138”). Examiner construed that the web browser is the end client interface sends the reply to the end user. Col.10 lines 38-43: “The web server receives the notification message (and/or the digital signature generated based on the message) from the authorization server and verifies it. If the message can be verified, the web server responds to the request (e.g., API call) of the client application to the protected resource, in operation 534.”The web server receives the notification message (and/or the digital signature generated based on the message) from the authorization server and verifies it. If the message can be verified, the web server responds to the request (e.g., API call) of the client application to the protected resource, in operation 534.”).
Dunjic appear to be silence on an authentication utility to authenticate the user, to encrypt a personal identifier associated with a user, and to provide an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including the encrypted ; and an authentication utility digital signature.
However, Fischer teaches an authentication utility to authenticate the user, to encrypt a personal identifier associated with a user, and to provide an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including the encrypted (see Fischer Col.6 lines33-43: “The EIP 308 could be configured for each tenant separately, or for multiple tenants. After verification (33), the AAS 306 returns the result, which is the user group membership if verification is successful (34). The AAS 306 next performs client authorization for each tenant, as shown in steps 35 to 37. In this process, the AAS first verifies client authorization during an authentication stage (35) and then verifies client authorization during an authorization phase (36), and then returns the result (37).
The authorization results are encapsulated into a token, as shown in step 38.”, Col.7 lines10-20: “the token used in system 100 and process 300 is a JSON web token (JWT),… the token's data is signed and encrypted, so that it is meaningless to a third party who may get access to the token.”, lines41-43: “ the JWT 402 is composed of a header 404, a payload 406, and a signature 408.”); and an authentication utility digital signature (see Fischer Col.8 lines 28-35: “The header 404 and payload 406 are digitally signed using the algorithm/key specified in the header. The JWT signature
408 is used to validate the authenticity of the token so that it can be trusted by the consumer. It also ensures the token has not changed in transition. The signature is a digital signature from both the header and the payload. The header and payload are JSON objects that are Base64 encoded for transport.”.).
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Dunjic teaching “the processing unit being configured to: receive, via the communication interface from a client application executing on a first device, a first signal including a request to obtain an access token for accessing a protected resource, the request including: a client identifier uniquely identifying the client application.”, (see Dunjic Col.2 lines:17-22), with Fischer teaching “The database server may instantiate a program that interacts with the database. Each instance of a database server may, among other features, independently query the database and store information in the database, or it may be an application server that provides user interfaces to database servers, such
as through web-based interface applications or through virtual database server or a virtual directory server applications.”, (see Fischer Col.4 lines:3-11).
For claim 12 (Original) Dunjic in view of Fischer disclose the access application of claim 10. Fischer Further disclose wherein the end client interface is further to send the identity assertion token to the end client (see Fischer Col4. lines 30-34: “system 100, and may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP) as in hypertext transport protocols (HTTP), well known in the relevant arts. In a distributed network environment, network 110”Col.6 lines42-47: “The authorization results are encapsulated into a token, as shown in step 38. That authorization information will be used by the application service 304 when enforcing Role Based Access Control (MAC). The resulting token is returned to the client 302 as shown in step 39. After the token is returned to the client 302.”.), and to receive the database request with the identity assertion token. (See Fischer Col.6 lines47-58: “After the token is returned to the client 302, the client requests a service from application service 304, as shown in steps 41 to 43. In this process, the service request from the client includes the valid token (41). The application service then processes the request based on the authorization included in the token (42), and returns the result to the user (43). The application service can be individually configured for each tenant or the same application service could serve several tenants. The application service 304 uses the provided token to make a decision whether to serve or deny the client request through the application and enforcement of RBAC rules and policies.”.) Examiner interpret that end client interface is a well know relevant arts and the access application is able to send the resulting token and receive a database request from the client with the included token .
It would have been obvious to someone of ordinary skill in the art before the
effective filing date of the claimed invention to have combined Dunjic in view of Fischer teaching of claim 10 along with Fischer teaching “FIG. 8 shows a system block
diagram of a computer system u