DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendments
This final office action is in response to amendment filed on 03/26/2026. Claims 14 have been amended. No Claims have been cancelled. Claims 1-23 remain pending in the application.
Response to Amendment
The amendment filed on 03/26/2026 has been entered. See response to
amendments.
Response to Arguments/Amendment
Examiner’s remarks concerning applicant’s claim objection.
The Applicant argument regarding (remark page 7):
“Applicants see the mention of a capital letter to begin a claim, as quoted by
the Examiner, but no prohibition on capital letters within a claim. Certainly, capital letters must be permissible within the claim for many other purposes, including chemical formulas and acronyms but also for proper nouns, e.g. Viterbi decoder, Reed Solomon encoder, Ohmic transfer, etc. The use of "Claim 1" is a use attributing a proper noun status to Claim 1, in the same way.”
Applicant’s arguments have been fully considered and are persuasive. Thus, claim objection as set forth in the previous office action has been waived.
Examiner’s remarks concerning applicant’s arguments on 35 U.S.C. 102 rejections.
The Applicant’s argument regarding (remark pages 7-8).
Applicant’s arguments have been fully considered and are persuasive. However, upon further consideration, arguments are moot in view of new grounds of rejection necessitated by applicant amendments.
Examiner’s remarks concerning applicant’s arguments on 35 U.S.C. 103 rejections.
The Applicant’s argument regarding (remark pages 8-10):
“Wang describes a middle tier that "creates an object of the user and includes
security credentials in the object." (item 204, Figure 2). In Wang, the middle tier provides the authentication to the end client and is trusted by the server. Figure 3 explains that there is a secure session between the middle tier and the database system, but the security credentials are not part of that secure session.”.
The Examiner respectfully disagree and arguments is not persuasive because Wang discloses (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.” Furthermore Wang Col.4 lines 3-9: “In response to receiving a client request, applications 112 and 114 send requests to database system 120 through database connections. One example technology that may be used to establish a connection with database system 120 and submit database requests is Java Database Connectivity (JDBC). Other (e.g., non-Java-based) connection technologies may be used to establish a database connection.” Wang disclose receiving a user authentication from an end client, the authentication request being a request to access a database that alone or in combination perform the functionally equivalent task.
With regards to applicant’s remarks concerning, “Fischer does not even seem to serve database requests. As shown in Figure 7, the Application Service services a request based on an authenticates in the token from the user/tenant 710. After obtaining the token, this would seem to be a direct interaction between the user/tenant and the service that answers the request.”.
The Examiner respectfully disagree and arguments are not persuasive because Fischer discloses obtaining an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including an encrypted personal identifier that is unique to a user, 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 (Ml M) or other similar attacks ... The token's
Page 13 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.", Col 9 lines 38- 44: "The AAS accesses an external identity provider (EIP)(authentication utility), which performs the user or tenant authentication using appropriate database lookups and/or validation methods, 704. The EIP return the authorization results to the AAS, and upon
authorization by the EIP, the AAS performs client authorization for the users/tenants,"). Fischer disclose “obtaining an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including an encrypted personal identifier that is unique to a user, and an authentication utility digital signature”.
With regards to applicant’s remarks concerning, “Fryer certainly has this direct interaction between the client application 110 and the resource API/service 130 as shown in Figure 1.”.
The Examiner respectfully disagree and arguments are not persuasive because Fryer discloses (see Fryer par.0024: "the resource server 206 may store various applications, routines, software modules, and data to control access to resources stored on or accessed through the resource server 206. Thus, the memory 262 may store one or more APIs or services 272 for exposing resource access to client devices 202 via the network 208. The APls or services 272 may be configured to verify user account authorization based upon an encrypted access
token provided by the client device 202 prior to providing access to the resources. In some embodiments, the resource server 206 may decrypt encrypted access tokens using one or more decryption filters 276 stored in the memory 262. Such decryption filters 276 may access a private key of the resource server 206 to decrypt the payload content of an encrypted access token to verify user account authorization to access resources stored on or controlled by the resource server 206. Each decryption filter 276 may correspond to one or more of the APIs or services 272. The memory 262 may also store one or more resources 274 accessible via the APls or services 272, which resources may include data and/or application logic. For example, such resources 274 may include streaming media content, user account details, account creation application logic, or other types of data or functions. In some embodiments, the resource server 206 may access one or more resources stored in additional networked memories, databases. or data stores (not shown) via the network 208 or via additional communication connections (not shown).", par.0038: "Upon receiving the resource request message, the resource server 206 may verify user account access permissions using the encrypted access token, then parse the resource request to perform a corresponding action (e.g., providing content, processing data, or generating and sending a response). In some embodiments, verifying access may include decrypting the payload of the encrypted access token at the resource server 206. In further embodiments, the resource server 206 may communicate with the IDP 204 via the network 208 to authorize the resource request by sending the encrypted access token to the IDP 204 for validation. In some embodiments, the resource server 206 may further verify a user account indicated by a user identifier in the encrypted access token is authorized to access the resource requested, which may be determined based upon both the user identifier and an indication of the resource or action requested by the resource request message (either as part of a PoP token or otherwise explicitly or implicitly indicated by the resource request message). Upon determining the resource request is valid (i.e., the client application 224 is authorized to access the requested resource (Database)), the resource server 206 performs the resource request. In some embodiments, performing the resource request includes sending a resource response to the client application 224.", Furthermore par.0029 “granting access to the resource may include sending a resource request response message 328 to the client application 224. Such resource request response message 328 may include data, files, or other content requested by the client application 224.”.
With regards to applicant’s remarks concerning, “Claim 1 recites "receiving a database request from the end client," and "sending the database request to the database with the identity assertion token." Wang does not send this to the database. Fischer and Fryer do not have this intermediate receiving and sending as claimed but show a direct interaction between the user and the database.”.
The Examiner respectfully disagree and arguments are not persuasive because Wang does recites "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).”, See Wang Col.4 lines 3-9: “In response to receiving a client request, applications 112 and 114 send requests to database system 120 through database connections. One example technology that may be used to establish a connection with database system 120 and submit database requests is Java Database Connectivity (JDBC). Other (e.g., non-Java-based) connection technologies may be used to establish a database connection.”. Wang disclose receiving a user authentication from an end client, the authentication request being a request to access a database that alone or in combination perform the functionally equivalent task. and "sending the database request to the database with the identity assertion token." (see Wang column 10 line [42-44]: "the identifier (identity assertion token) and version number (received in block 210) is inserted into the request to create a modified request").Examiner construe the identifier as the identity assertion token which is consistent with applicant publication par.[0016]: “identity assertion token may contain user name, telephone number, email address, or other personal identifiers may be used.”, (Lines [49-50]: "At block 216, the modified request is sent to database system 120).", furthermore Wang Col.7 lines 34-40: “The authentication data may be a user identifier and/or group identifier. Session manager 118 stores the authentication data and is responsible for sending the authentication data to database system 120. The database system 120 may use the user/group identifier for auditing purposes and/or for security purposes to enforce security policies in light of the specific user. For example, a security policy on a table may include a user-specific”).
With regards to applicant’s remarks concerning, “In Wang, the database seems to trust the middle tier and establish a secure session and there is no need for personal identifiers and user databases, approved authentication utilities. In Fischer and Fryer, there is no sending and receiving as claimed because the interaction is direct.”.
The Examiner respectfully disagree and arguments are not persuasive because Wang teaching is not use for the limitation involving in response to the personal identifier corresponding to a record stored in a user database at the database
and in response to the authentication utility, instead Fryer is use for teaching this limitation. With respect with Fischer teaching is use to teach obtaining an identity assertion…. and sending a reply to the end client. Fryer teaching is for receiving a reply from the database…,
With regards to applicant’s remarks concerning, “Without directly saying so, the Examiner would seem to be suggesting that operations from two different systems may be selected and combined to create the current system. However, this ignores the question of obviousness. It would not be obvious to add a middle tier to Fisher and Fryer to provide the send and receive operations. Nothing in these references suggest that. Instead, the point in Fischer and Fryer is to enable the direct interaction. It would not be obvious to add a user database and approved authentication utilities to Wang. Instead, the point in Wang is that the middle tier does this work and the server can trust the secure session with the trusted middle tier.”.
The Examiner respectfully disagree and arguments are not persuasive because for the same reason explained above where the teaching of Wang teaching is being use to for limitations “receiving a user authentication.., authenticating the user…, receiving a database request…, and sending the database request…”, Fischer teaching is being use to “obtaining an identity assertion…, and sending the reply.” while Fryer teaching is being use to receiving a reply... The current claim limitations are broad and Examiner is using the broadest reasonable interpretation. One of the ordinary skill in the art would be obvious to combine Wang, Fischer, and Fryer teaching to authenticate an user through an application and sending the request to the database to confirm the user authentication.
The applicant argument regarding (remark page 10):
“The remaining claims are dependent on one of Claim 1, 10, 14, or 21 and are believed to be allowable therefore as well as for the additional limitations set forth in each such claim, respectively”.
Applicant's arguments do not comply with 37 CFR 1.111(c) because they do not clearly point out the patentable novelty which he or she thinks the claims present in view of the state of the art disclosed by the references cited or the objections made. Further, they do not show how the amendments avoid such references or objections.
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.
Claims 1- 3, and 6 - 7 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 Fryer et al. (US-20220217124-A 1 hereafter Fryer).
Regarding claim 1 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 However teaches obtaining an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including an encrypted personal identifier that is unique to a user, 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.”, Col 9 lines 38-44: “The AAS accesses an external identity provider (EIP)(authentication utility), which performs the user or tenant authentication using appropriate database lookups and/or validation methods, 704. The EIP return the authorization results to the AAS, and upon authorization by the EIP, the AAS performs client authorization for the users/tenants,”); 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 however Fryer teaches
receiving a reply from the database in response to the database request in response to the personal identifier corresponding to a record stored in a user
database at the database and in response to the authentication utility digital signature being of an approved authentication utility (see Fryer par.0024: “the resource server 206 may store various applications, routines, software modules, and data to control access to resources stored on or accessed through the resource server 206. Thus, the memory 262 may store one or more APIs or services 272 for exposing resource access to client devices 202 via the network 208. The APIs or services 272 may be configured to verify user account authorization based upon an encrypted access token provided by the client device 202 prior to providing access to the resources. In some embodiments, the resource server 206 may decrypt encrypted access tokens using one or more decryption filters 276 stored in the memory 262. Such decryption filters 276 may access a private key of the resource server 206 to decrypt the payload content of an encrypted access token to verify user account authorization to access resources stored on or controlled by the resource server 206. Each decryption filter 276 may correspond to one or more of the APIs or services 272. The memory 262 may also store one or more resources 274 accessible via the APIs or services 272, which resources may include data and/or application logic. For example, such resources 274 may include streaming media content, user account details, account creation application logic, or other types of data or functions. In some embodiments, the resource server 206 may access one or more resources stored in additional networked memories, databases, or data stores (not shown) via the network 208 or via additional communication connections (not shown).”, par.0038: “Upon receiving the resource request message, the resource server 206 may verify user account access permissions using the encrypted access token, then parse the resource request to perform a corresponding action (e.g., providing content, processing data, or generating and sending a response). In some embodiments, verifying access may include decrypting the payload of the encrypted access token at the resource server 206. In further embodiments, the resource server 206 may communicate with the IDP 204 via the network 208 to authorize the resource request by sending the encrypted access token to the IDP 204 for validation. In some embodiments, the resource server 206 may further verify a user account indicated by a user identifier in the encrypted access token is authorized to access the resource requested, which may be determined based upon both the user identifier and an indication of the resource or action requested by the resource request message (either as part of a PoP token or otherwise explicitly or implicitly indicated by the resource request message). Upon determining the resource request is valid (i.e., the client application 224 is authorized to access the requested resource), the resource server 206 performs the resource request. In some embodiments, performing the resource request includes sending a resource response 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 teaching describe above with Fryer teaching “secure resource access technique 100 for provisioning and using encrypted access tokens to access secure online resources. The secure resource access technique 100 may be implemented to provide access to remote resources through application programming interfaces (APIs) or services in a secure manner, while maintaining the security and confidentiality of user account information needed to access some such resources. As illustrated, a client application 110 obtains an encrypted access token from an identity provider (IDP) 120, which encrypted access token protects the payload by remaining encrypted even when stored or used by the client application 110. Thus, any user confidential data included in the encrypted access token (e.g., user phone number or e-mail address) remains secure against attacks, even if the device running the client application 110 is compromised.”, (see Fryer par.0014).
Regarding claim 2 Wang in view of Fischer and Fryer 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.”).
Regarding claim 3 Wang in view of Fischer and Fryer 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 Fryer 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).
Regarding claim 6 Wang in view of Fischer and Fryer 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 Fryer 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).
Regarding claim 7 Wang in view of Fischer and Fryer 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)).”).
Claims 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 Fryer et al. (US-20220217124-A 1 hereafter Fryer), in further view of Rykowski et al. (US-20160366119-A1 hereafter Rykowski).
Regarding claim 4 Wang in view of Fischer and Fryer teach the method of claim 3.
Wang in view of Fischer and Fryer do not explicitly teach 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 Fryer 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).
Regarding claim 5 Wang in view of Fischer, Fryer 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, Fryer, and Rykowski 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 8 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 Fryer et al. (US-20220217124-A 1 hereafter Fryer), in further Dunjic et al. (US-11811748-B2 hereafter Dunjic).
Regarding claim 8 Wang in view of Fischer and Fryer disclose the method of claim 1, Wang in view of Fischer and Fryer do not explicitly teach however Dunjic teaches 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 Fryer 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 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 Fryer et al. (US-20220217124-A 1 hereafter Fryer), in further view of Cook et al. (US-11770376-B2 hereafter Cook).
Regarding claim 9 Wang in view of Fischer and Fryer 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 Fryer appear to silence however Cook teaches and 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 Fryer 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).
Claims 10, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (CN-110413676-B hereafter Li),in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in Further view of O’Meara et al. (US-20140179274-A1 hereafter O’Meara).
Regarding claim 10 Li 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 Li par.10: “receiving access request data from an application, wherein the access request data is sent by a JDBC client in response to an access request of the application to the database, the access request data is obtained by encrypting and/or compressing a structured query statement and an access parameter carried in the access request by the JDBC client, acquiring access response data corresponding to the access request data from the database in response to the access request data, and sending the access response data to the JDBC client, so that the application realizes access to the database based on the access response data from the JDBC client.”, par.80 “The JDBC client may be embedded inside an Application program as an Application Programming Interface (SDK) for accessing the JDBC server by the Application program. The JDBC client encapsulates the SDK with the functions of access, compression, encryption, decryption and the like of the JDBC server, provides a simple access interface of the JDBC server for an application program,”); and
wherein the end client interface sends the reply to the end client. (See Li par.70: “access response data is sent to the JDBC client, so that the application realizes access to the database based on the access response data from the JDBC client.”, par.79-80: “the access request data from the application program is sent by the JDBC client in response to the access request of the application program to the database, and the access request data is obtained by encrypting and/or compressing the structured query statement and the access parameter carried in the access request by the JDBC client. The JDBC client may be embedded inside an Application program as an Application Programming Interface (SDK) for accessing the JDBC server by the Application program. The JDBC client encapsulates the SDK with the functions of access, compression, encryption, decryption and the like of the JDBC server, provides a simple access interface of the JDBC server for an application program”).
Li appear to be silence however Fischer teaches
a processor to perform authentication utility operations including to authenticate the user, to encrypt a personal identifier associated with the user and unique to the user, and to provide an identity assertion token after authenticating the user, the identity assertion token having a header, a payload including the encrypted personal identifier (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.”, Col.10 lines 4-9: “a computer system used to execute one or more software components of the present system described herein. The computer system 1005 includes a monitor 1050, keyboard 1015, and mass storage devices 1020. Computer system 1000 further includes subsystems such as central processor 1010,”); 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 Li teaching “a first sending module and a second receiving module, wherein the first receiving module is configured to receive access request data from an application program, the access request data is sent by a JDBC client in response to an access request of the application program to the database, the access request data is obtained by encrypting and/or compressing a structured query statement and an access parameter carried in the access request by the JDBC client, the obtaining module is configured to obtain access response data corresponding to the access request data from the database in response to the access request data, and the first sending module is configured to send the access response data to the JDBC client so that the application program realizes access to the database based on the access response data from the JDBC client.”, (see Lil par.19), 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).
Li in view of Fischer appear to be silence however O’Meara teaches
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 the personal identifier corresponding to a record stored in a user database at the database and in response to the authentication utility digital signature being of an approved authentication utility (see O'Meara pa.0045-0048: “the software 32 receives a request for a particular application 40 on the phone 20 to utilize the interface (external interface) (including input 24 resources 1-2 and output 25 resources 3-4) (database) of the head unit 21. The request includes a user identifier corresponding to the user of the motor vehicle and/or head unit 21, an application identifier corresponding to the particular application 40, and vehicle status information. The user identifier could be an identifier provided by the user when the control software 30A was first activated in the mobile phone 100, user's phone number. The software 32 authenticates the user. This can include determining whether the user identified by the user identifier matches a database 11(user database) of subscribers for the service of extending the interface of the phone 20 using the head unit 21…. if the user is authenticated, then in block 204B the software 32 authenticates the application 40 by comparing the application identifier to a list 12 of applications (also referred to as a whitelist) (approved authentication utility). This list 12 can be compared by version number such that one particular version of an application 40 can be identified on the list while a different version is excluded….if the application 40 is authenticated, then in block 206 the software 32 compares the application identifier and the current vehicle status information to a mapping 15 of application operation modes. As shown, the mapping 15 can have an entry 17 for each application 40 of the list 12. Each entry 17 includes a mapping that is particularized for the corresponding application 40.”).
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 Li in view of Fischer teaching described above with O’Meara teaching “a request for an application of a mobile device to utilize a resource of a vehicle head unit, the request including a first profile of the vehicle head unit and a second profile of the mobile device. Responsive to sending the request, the processing device receives an instruction from the remote network device, the instruction to be executed by embedded software of the vehicle head unit so as to enable the application to utilize a resource of the vehicle head unit.”, (see O’Meara par.0007).
Regarding claim 12 Li in view of Fischer, and O’Meara 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 Li in view of Fischer, and O’Meara teaching of claim 10 along with Fischer teaching “FIG. 8 shows a system block
diagram of a computer system used to execute one or more software components of the present system described herein.. network interface 1035,.. the computer may be connected to a network and may interface to other computers using this network. The network may be an intranet, Internet, or the Internet, among others.”, (see Fischer Col.10 lines:4-5,12, and 43-46).
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (CN-110413676-B hereafter Li),in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in Further view of O’Meara et al. (US-20140179274-A1 hereafter O’Meara), in view of in further view of Rykowski et al. (US-20160366119-A1 hereafter Rykowski).
Regarding claim 11 Li in view of Fischer, and O’Meara disclose the access application of claim 10.
Li in view of Fischer, and O’Meara appear to be silence on however Rykowski teaches further comprising a users database to store the identity assertion token in association with the user. (See Rykowski par.0048: “At step 718, the client application 224 can receive a session token from the service provider 209. The session token can correspond to an OAuth token. For example, the session token can be provided within a cookie, which the client application 224 can store in its container or data store for later retrieval.”.).
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 Li in view of Fischer, and O’Meara teaching of claim 10 along with Rykowski teaching “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.”, (see Rykowski par.0017).
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Li et al. (CN-110413676-B hereafter Li), in view of Fischer et al. (US-10742638-B1 hereafter Fischer), in Further view of O’Meara et al. (US-20140179274-A1 hereafter O’Meara), in further view Wang et al. (US- US 9,613,224 B2 hereafter Wang).
Regarding claim 13 Li in view of Fischer, and O’Meara disclose the access application of claim 10. Li in view of Fischer, and O’Meara appear to be silence however, Wang teaches further comprising a session engine to establish a secure session with the database. (See Wang column 9 line [0106]: connections between database system 120 and middle tier 110 are secured with a cryptographic communication protocol (such as Secure Sockets Layer (SSL)). Applicant defines in the specification "secure session" as secure connection, and "session engine" to stablish a secure session.”).
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 Li in view of Fischer, and O’Meara teaching of claim 10 along with Wang teaching “session manager 118 has access to credential data, Such as a username and password, that session manager 118 uses to establish trust with database system 120. The credential data may be managed in secure store that is configured to give access to the correct mid-tier component(s).”, (see Wang Col.13 lines:50-55).
Claim 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over Fryer et al. (US-20220217124-A1 hereafter Fryer), in view of Sugarev et al. (US-11563580-B2 hereafter Sugarev).
Regarding claim 14 Fryer 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 Fryer par.0023: “The resource server 206 also includes a communication interface 270 configured to send and receive communications between the resource server 206 and external computing devices via a data network connection with the network 208.”, par.0028: “the IDP 204 validates the authorization code and generates an encrypted access token. In some embodiments, the encrypted access token includes user confidential data, such as personally identifiable information used as a user identifier (e.g., user phone number or e-mail address).The encrypted access token may be generated as a JavaScript Object Notation (JSON) Web Encryption (JWE) token or other type of encrypted token,”, par. 0029: “the resource request message 324 is sent from the client application 224 to the resource server 206 to request access to secure resources ( e.g., to access a resource 274 via anAPI or service 272 of the resource server 206).”, par.0034: “A JWE token comprises five portions: a JWE header, a JWE encrypted key, a JWE initialization vector, a JWE ciphertext (i.e., an encrypted payload corresponding to a plaintext payload containing the user identifier), and a JWE authentication tag.”) , wherein the database request is generated by an end client coupled through a network to the access application (see Fryer Fig.3 and par.0019: “ the user agent 222 may be a separate software module or may be part of the client application 224., par.0026: “Such initiate authorization request 302 may be sent in response to a user action to log in to a system or to access secured resources (e.g., resources 274 of the resource server 206)”
PNG
media_image2.png
608
624
media_image2.png
Greyscale
);
determining that the authentication utility digital signature is of an approved authentication utility (see Fryer par.0029: “When the resource server 206 receives the resource request message 324 via an API or service 272, it validates
the encrypted access token to verify user authorization to access the requested resource 274, such validation may include decrypting the payload of the encrypted access token via a decryption filter 276. Alternatively, the resource server 206 may communicate with the IPD 204 to provide the encrypted access token to the IDP 204 for decryption and verification by a decryption filter 246 of the IDP 204”);
decrypting the personal identifier (see Fryer par.0023: “The resource server 206 comprises computing components configured to provide access to secured external resources to the client device 202, based upon verification of user account authorization….Similar to the controller 210, the controller 260 receives, processes, produces, transmits, and stores data. The controller 260 includes a memory 262, a processor 264, a RAM 266, and an I/O circuit 268, each configured and operating analogously to the corresponding components of the controller 210 described above.”, par.0024: “the resource server 206 may decrypt encrypted access tokens using one or more decryption filters 276 stored in the memory 262. Such decryption filters 276 may access a private key of the resource server 206 to decrypt the payload content of an encrypted access token to verify user account authorization to access resources stored on or controlled by the resource server 206. Each decryption filter 276 may correspond to one or more of the APis or services 272. The memory 262 may also store one or more resources 274 accessible via the APis or services 272, which resources may include data and/or application logic.”);
performing the database request on the database based on the comparing and the determining (see Fryer par.0029: “the resource server 206 grants access to the requested resource 274 to the client application 224. In some embodiments, granting access to the resource may include sending a resource request response message 328 to the client application 224. Such resource request response message 328 may include data, files, or other content requested by the client application
224.”);
generating a reply in response to performing the database request (see Fryer par.0029: “the resource server 206 grants access to the requested resource 274 to the client application 224. In some embodiments, granting access to the resource may include sending a resource request response message 328 to the client application 224. Such resource request response message 328 may include data, files, or other content requested by the client application
224.”); and
sending the reply to the access application for forwarding to the end client
through the network. (See Fryer par.0023: “The resource server 206 also includes a communication interface 270 configured to send and receive communications between the resource server 206 and external computing devices via a data network connection with the network 208.”, par.0029: “granting access to the resource may include sending a resource request response message 328 to the client application 224.”).
Fryer do not explicitly teach comparing a stored personal identifier that is unique to a user and stored in a user database to the decrypted personal identifier of the identity assertion token;
determining that the request is genuine from the user in response to the
comparing;
In this instance the examiner notes the teachings of prior art reference Sugarev.
With regards to applicant’s claim limitation element of, “comparing a stored personal identifier that is unique to a user and stored in a user database to the decrypted personal identifier of the identity assertion token (see Sugarev Col.1 lines 53 - Col.2 lines 1-7: “the determined identifier is a client key generated by the client and provided by the client to the authentication server for generating the security token… the determined identifier is a version value provided at a versioning field part of the received security token, and wherein the application server compares the determined version value with the stored values to determine whether the token is valid… determining the identifier associated with the client comprises retrieving the identifier from a security storage (user database) component based on information about a location of the identifier included in the security token, wherein the identifier comprises a client key incorporated in the security token during generation at the authentication server... the identifier is a client key generated in advance by the client and stored at a security storage component, wherein the client key is retrieved by the application server from the security storage component to validate the security token, wherein the security storage component is either external to the authentication server or within the authentication server.”);
With regards to applicant’s claim limitation element of, “determining that the request is genuine from the user in response to the comparing (see Sugarev Col.1 lines 56 - Col.2 lines 1-7: “the determined identifier is a version value provided at a versioning field part of the received security token, and wherein the application server compares the determined version value with the stored values to determine whether the token is valid… determining the identifier associated with the client comprises retrieving the identifier from a security storage component based on information about a location of the identifier included in the security token, wherein the identifier comprises a client key incorporated in the security token during generation at the authentication server... the identifier is a client key generated in advance by the client and stored at a security storage component, wherein the client key is retrieved by the application server from the security storage component to validate the security token, wherein the security storage component is either external to the authentication server or within the authentication server.”);
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 Fryer teaching “
The secure resource access technique 100 may be implemented to provide access to remote resources through application programming interfaces (APis) or services in a
secure manner, while maintaining the security and confidentiality of user account information needed to access some such resources. As illustrated, a client application 110 obtains an encrypted access token from an identity provider (IDP) 120, which encrypted access token protects the payload by remaining encrypted even when stored or used by the client application 110.”, (see Fryer par.0014), with Sugarev teaching because Sugarev teaching of “the payload can include the user identifier, the company tenant identifier, and the client application identifier of the client application for which the token is generated. In cases where tokens are generated based on multiple identifiers, if any one of the identifiers is changed or not maintained for reference, those tokens that are associated with any changed identifier would be invalidated and rights associated with the tokens would be revoked. In these cases, revocation of tokens can be performed more flexibly, as a security breach at any level in the sequence of identifiers can be addressed by changes at the particular level. Additionally, control over access to resources can be executed faster and more efficiently when performing token revocation.”. (see Sugarev Col.5 lines 23-36:).
Regarding claim 15 Fryer in view of Sugarev disclose the method of claim 14, Fryer 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 Fryer par.0014: “The secure resource access technique 100 may be implemented to provide access to remote resources through application programming interfaces (APIs) or services in a secure manner, while maintaining the security and confidentiality of user account information needed to access some such resources. As illustrated, a client application 110 obtains an encrypted access token from an identity provider (IDP) 120, which encrypted access token protects the payload by remaining encrypted even when stored or used by the client application 110. Thus, any user confidential data included in the encrypted access token (e.g., user phone number or e-mail address) remains secure against attacks, even if the device running the client application 110 is compromised.”).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Fryer in view of Sugarev as applied to claim 14 above and further view of Kon et al. (US- US-20030078894-A1 hereafter Kon).
Regarding claim 16 Fryer in view Sugarev disclose the method of claim 14, Fryer in view Sugarev do not explicitly teach however Kon teaches 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 Kon par.0047: “the user uses the user terminal 1 to prepare a resource request command requesting a resource kept by the resource providing server 4. By an authentication in the user authenticating section 211 of the window server 2, a secure path is established with the window server 2. Thereafter, a prepared resource request command is sent to the window server 2.”, par.0050 “the user authenticating section 211 of the window server 2 authenticates the user to establish a secure path with the user terminal 1., and thereafter accepts a resource request command from the user terminal 1. When forming a PKI-based secure path, reference is made to the user information database 22 to check for a contradiction against a resource request command content. The ID & password is checked for a contradiction between the information provided by the user and the resource request command content.”, par.0052: “the request generating section 212 verifies whether the resource provider included in the resource request command is reliable or not, by making reference to the resource provider information database 23. When the resource provider is not reliable or is less reliable, a notification to this effect is sent back to the user terminal 1.”, par.0054: “after the authentication has been performed, the request generating section 212 sends to the resource providing server 4 the resource request command for the resource providing server 4 prepared in the step S5. In step S7, the request authenticating section 411 of the resource providing server 4, after being authenticated with the window server 2 in step S6, verifies the resource request command sent from the window server 2.”, par.0055: “The resource request command is verified by any one of the methods of verifying a reliability of the window server 2 having authenticated the user or of verifying a reliability of the user. The algorithm for selecting any of the methods is previously determined for the request verifying section 411. When verifying a reliability of the window server 2, reliability information about the window server 2 is extracted from the resource provider information database 43 to determine, according a content thereof, whether to allow the access to the resource. If the reliability of the user is verified, reference is made to the user information included in the resource request command from the window server 2 to specify a user. The personal information of the user is retrieved through and extracted from the user information database 42 to determine, according to a content thereof, whether to allow access to the resource or not. When the determination is to allow access to the resource, a check request is prepared to verify a restriction from accessing the resource.”).
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 Fryer in view of Sugarev teaching of claim 14 with Kon teaching “A user information database records information for authenticating the user. A resource provider database records information for verifying a reliability of a resource provider. A resource provider information database records information for verifying the window server. user information database records information of a user authenticated by the window server to allow the access to a resource. A permission data database records information for restricting the access to a resource.”, (see Kon abstract). The motivation to combine would have been to “The resource request command is verified by any one of the methods of verifying a reliability of the window server 2 having authenticated the user or of verifying a reliability of the user”. (see Kon par.0055).
Claims 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Fryer in view of Sugarev, and Kon as applied to claim 16 above and in further view of Wang et al. (US 9,613,224 B2 hereafter Wang).
Regarding claim 17 Fryer in view of Sugarev, and Kon discloses the method of claim 16, Fryer in view of Sugarev, and Kon appear to be silence however Wang teaches further comprising obtaining a security policy of the user by applying the database identification to the record and wherein performing the database request comprises performing the database request in accordance with the security policy. (See Wang column 9 line [0022]: “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).”).
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 Fryer in view of Sugarev, and Kon teaching of claim 16, with Wang because Wang teaching of “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:34-36). The motivation to combine would have been to allow user to have their assigned privilege for example to read but not to update.
Regarding claim 18 Fryer in view of Sugarev, Kon, and Wang disclose the method of claim 17, Wang further discloses wherein the security policy defines permissions (see Wang column 9 line [0039]: “database system 120 implements a data access control policy that provides row-level and/or column-level access control to data stored in database system 120.”.), and roles that are associated in the record with the user. (See Wang column 9 line [0039]: “Each access control list specifies what privileges (e.g., read or write) can be performed by which principals, where each principal is a user or role in the database system.”.).
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 Fryer in view of Sugarev Kon, and Wang teaching of claim 17, with Wang teaching “database system 120 implements a data access control policy that provides row-level and/or column-level access control to data stored in database system 120. The data access control policy may be specified using one or more access control lists. Each access control list specifies what privileges (e.g., read or write) can be performed by which principals, where each principal is a user or role in the database system.”, (see Wang Col.6 lines:10-18). The motivation to combine would have been to allow user to have only specific privilege like to read but not to update.
Claim 19 is rejected under 35 U.S.C. 103 as being unpatentable over Fryer in view of Sugarev as applied to claim 14 above and in further view of Siguero et al. (US-20230388119-A1 hereafter Siguero).
Regarding claim 19 Fryer in view Sugarev disclose the method of claim 14, Fryer in view Sugarev do not explicitly teach however Siguero teaches 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).”).
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 Fryer in view of Sugarev teaching of claim 14 with Siguero teaching because Siguero teaching of “the method comprises a communication session between a client device and a server. During this phase, the user initiates requests for service through a browser on the client device, where each request includes the JWT based cookie and token, and the server authenticates the request using the cookie and token and then returns a response to the request if the cookie and token are valid.”, (see Siguero par.0047). The reason to combine would have been if the JWT signature is determined to be valid, the server processes the request, generates a response to the request and returns this response to the browser. 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.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Fryer in view of Sugarev as applied to claim 14 above and in further view of Dunjic et al. (US-11811748-B2 hereafter Dunjic).
Regarding claim 20 Fryer in view Sugarev disclose the method of claim 14, Fryer in view Sugarev appear to be silence however Dunjic teaches wherein the personal identifier comprises a number associated with the user independent of an end client associated with the user. (See Dunjic Col.9 lines57-64: “the client application constructs a request to access a protected resource. For example, the client application may generate a request/call to an API associated with a resource server. The client application may first create a cryptographic nonce. In some embodiments, the cryptographic nonce may include a combination of the client identifier, the user identifier, and a salt value (e.g., an arbitrary number to be used only once).”.) Examiner interpret that salt value as the number associated with the user independent of an end client..
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 Fryer in view Sugarev teaching of claim 14, with Dunjic because Dunjic teaching of “a request to obtain an access token for accessing a protected resource, the request including: a client identifier uniquely identifying the client application; an authorization code for authorizing the client application's access of the protected resource; and a public key associated with the end user;”, (see Dunjic Col.3 lines:8-13). The motivation would have been to 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.
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Fryer et al. (US-20220217124-A1 hereafter Fryer), in view of Sun et al. (US-20200195647-A1 hereafter Sun).
Regarding claim 21 Fryer discloses a database comprising:
secure data (see Fryer par.0023: “The resource server 206 comprises computing components configured to provide access to secured external resources… the resource server 206 comprises one or more servers configured to communicate via the network 208, as well as to receive, store, process, generate, access, and output data.”);
an external interface to receive 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 Fryer par.0023: “The resource server 206 also includes a communication interface 270 configured to send and receive communications between the resource server 206 and external computing devices via a data network connection with the network 208.”, par.0028: “the IDP 204 validates the authorization code and generates an encrypted access token. In some embodiments, the encrypted access token includes user confidential data, such as personally identifiable information used as a user identifier (e.g., user phone number or e-mail address).The encrypted access token may be generated as a JavaScript Object Notation (JSON) Web Encryption (JWE) token or other type of encrypted token,”, par. 0029: “the resource request message 324 is sent from the client application 224 to the resource server 206 to request access to secure resources ( e.g., to access a resource 274 via anAPI or service 272 of the resource server 206).”, par.0034: “A JWE token comprises five portions: a JWE header, a JWE encrypted key, a JWE initialization vector, a JWE ciphertext (i.e., an encrypted payload corresponding to a plaintext payload containing the user identifier), and a JWE authentication tag.”); and
a processor to perform data engine operations including to decrypt the personal identifier of the identity assertion token, to compare the personal identifier of the identity assertion token to stored personal identifiers, to determine that the request is genuine from the user in response to the comparing, to determine that the authentication utility digital signature is of an approved application utility, to perform the database request on the secure data based on the comparing and the determining (see Fryer par.0023: “The resource server 206 comprises computing components configured to provide access to secured external resources to the client device 202, based upon verification of user account authorization….Similar to the controller 210, the controller 260 receives, processes, produces, transmits, and stores data. The controller 260 includes a memory 262, a processor 264, a RAM 266, and an I/O circuit 268, each configured and operating analogously to the corresponding components of the controller 210 described above.”, par.0024: “the resource server 206 may decrypt encrypted access tokens using one or more decryption filters 276 stored in the memory 262. Such decryption filters 276 may access a private key of the resource server 206 to decrypt the payload content of an encrypted access token to verify user account authorization to access resources stored on or controlled by the resource server 206. Each decryption filter 276 may correspond to one or more of the APis or services 272. The memory 262 may also store one or more resources 274 accessible via the APis or services 272, which resources may include data and/or application logic.”, par.0029: “When the resource server 206 receives the resource request message 324 via an API or service 272, it validates
the encrypted access token to verify user authorization to access the requested resource 274, such validation may include decrypting the payload of the encrypted access token via a decryption filter 276. Alternatively, the resource server 206 may communicate with the IPD 204 to provide the encrypted access token to the IDP 204 for decryption and verification by a decryption filter 246 of the IDP 204”), and to generate a reply in response to performing the database request (see Fryer par.0029: “the resource server 206 grants access to the requested resource 274 to the client application 224. In some embodiments, granting access to the resource may include sending a resource request response message 328 to the client application 224. Such resource request response message 328 may include data, files, or other content requested by the client application
224.”), wherein the external interface is further to send the reply to the access application (See Fryer par.0023: “The resource server 206 also includes a communication interface 270 configured to send and receive communications between the resource server 206 and external computing devices via a data network connection with the network 208.”, par.0029: “granting access to the resource may include sending a resource request response message 328 to the client application 224.”);
Fryer appears to be silence however Sun teaches
a users database containing stored personal identifiers associated with users that are unique to a respective user and approved application utilities (see Sun par.0037-0038: the data controller 160 may securely store personal data of various users as a data object. The data object may be stored in the personal data database 168 on the data controller 160. For example, each user may be represented and/or organized in JavaScript Object Notation (JSON), among other object types, as a JSON object. An example of a portion of the personal data represented as a data object (e.g., stored in the JSON format) is as follows:.. The data object may include one or more user attributes, which represent the personal data stored in the data controller 160 for each user. In the above example, the one or more user attributes for the user Xun Sun includes a first name, a last name, an email, a job, a social security number (SSN), and a bank account.”, par.0043: “the data controller 160 may include one or authentication and/or authorization features for authorizing one or more applications (software or applications) via the application server 110 in communication with the client 120 after a request from the application to access data stored on the data controller 160. For example, the applications may be authenticated using an application key (stored in the application configuration database 166) received by the application server 110 from the authentication service 165 of the data controller 160, during application onboarding. Upon successful authentication of the application using the application key, the application receives a web token (e.g., a JSON Web Toke (JWT)) from the authentication service 165.”).
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 Fryer teaching “
The secure resource access technique 100 may be implemented to provide access to remote resources through application programming interfaces (APis) or services in a
secure manner, while maintaining the security and confidentiality of user account information needed to access some such resources. As illustrated, a client application 110 obtains an encrypted access token from an identity provider (IDP) 120, which encrypted access token protects the payload by remaining encrypted even when stored or used by the client application 110.”, (see Fryer par.0014), with Sun teaching “If the authentication service 165 determines that the application keys match, the authentication service 165 may accept the login request. For example, at 260, the authentication service 165 may generate a web token (JWT token) for the current user login, authenticating the current session, and allowing the user to access the personal data stored on the data controller 160. The web token provides an additional layer of security to protect the personal data of the data objects stored on the data controller 160.”, (see Sun par.0060).
Claims 22 - 23 are rejected under 35 U.S.C. 103 as being unpatentable over Fryer et al. (US-20220217124-A1 hereafter Fryer), in view of Sun et al. (US-20200195647-A1 hereafter Sun), in further view of Wang et al. (US-9613224-B2 hereafter Wang).
Regarding claim 22 Fryer in view of Sun disclose the database of claim 21,
Fryer in view of Sun don not explicitly teach however Wang teaches wherein the database request includes a database identification of the user, wherein the data engine applies the database identification to a record of the users database (see Wang column 7 line [37-40]: “The database system 120 may use the user/group identifier for auditing purposes and/or for security purposes to enforce security policies in light of the specific user.”.), and wherein comparing a stored personal identifier comprises comparing a stored personal identifier associated with the record. (See Wang column 16 line [20-21]: “security protocol is public-key cryptography where both session manager 118 and database system 120 have a private (or secret) key and a public key. Session manager 118 using the private key to “sign content to generate a digital signature. The signed content may be content of a session management call, which may have been initiated by a mid-tier application or by session manager 118. Alternatively, the signed content may be content of an application data request, such as a SQL query. Database system 120 verifies the digital signature by processing the digital signature using the public key and comparing the result with the signed content. If the result matches the original content, then the message is presumed authenticated.”).
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 Fryer in view of Sun teaching of database of claim 21 with Wang teaching “session manager 118 creates a session and initiates a LWS on database system 120 using only a user/group identifier of the user. After that point, session manager 118 stores a LWS ID for the session. Later, after the role(s) of the user are determined (e.g., in response to a Subsequent request from the corresponding client), session manager 118 transmits the role data and a LWS ID to database system 120, which updates its LWS to include the role data. Session manager 118 may use the mid-tier applications connection (from connection pool 116) to initiate the above create session/ assign user roles operations”, (see Wang Col.8 lines:29-40).
Regarding claim 23 Fryer in view of Sun disclose the database of Claim 21,
Fryer in view of Sun do not explicitly teach however Wang teaches wherein the users database further contains a security policy of the user and wherein the data engine performs the database request in accordance with the security policy. (See Wang column 7 line [34-42]: “The authentication data may be a user identifier and/or group identifier. Session manager 118 stores the authentication data and is responsible for sending the authentication data to database system 120. The database system 120 may use the user/group identifier for auditing purposes and/or for security purposes to enforce security policies in light of the specific user. For example, a security policy on a table may include a user-specific or group specific policy.”).
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 Fryer in view of Sun teaching of database of claim 21 with Wang teaching “When a principal Submits a query to a database server, a database server enforcing a data access control policy deter
mines whether a table identified by the query is associated with one or more data realms. If the database server deter mines that the query identifies such a table, then, during query execution, the database server will evaluate the data realms associated with the table for each row requested in the query. If an associated data realm includes an access control list that either grants or denies the requested privilege to the requesting principal and the associated access predicate is true for the current row under evaluation, then access to the row is granted or denied to the principal,”, (see Wang Col.6 lines:55-67).
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Conclusion
The prior art made of record and not relied upon is considered pertinent to
applicant's disclosure:
Forrest et al. (US-20190245860-A1) a data management system for sharing data associated with a first user, the data management system comprising: a data storage resource configured to store user data associated with the first user; a transmitter arranged to transmit, from the data management system to an authorization system, a request to access an authorized entity database stored at the authorization system, wherein the authorized entity database comprises a plurality of authorized entity labels each indicative of an identifier of an authorized entity; a receiver arranged to receive at least a portion of the authorized entity database, wherein the data storage resource is arranged to store the at a portion of the authorized entity database; wherein the receiver is arranged to receive an access message, from a remote system, associated with a request for access to the data stored at the data management system, the access message comprising a remote system label indicative of an identifier of the remote system; a comparison module arranged to compare the remote system label with the plurality of authorized entity labels stored at the data management system, in response to receiving the access message; and an identification module arranged to identify a match between the remote system label and at least one of the plurality of authorized entity labels stored at the data management system and, in response, cause the transmitter to transmit a grant message indicative that the request for access is granted.
Hamel et al. (US-20190306143-A1) a secret data is generated. the credential request is cryptographically signed using the secret data. the credential is stored, secret data is stored. The credential identifier is stored. The privacy data is stored. For example, privacy data is stored as metadata. The credential, the secret data, the credential identifier, and the privacy data are encrypted, in response to a request for credential information a request for credential information associated with user information is received. A user associated with the user information is located in a database system. A set of credentials associated with the user is determined. Credential information associated with the credentials is determined. The credential information is provided.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DUILIO MUNGUIA whose telephone number is (571)270-5277. The examiner can normally be reached M-F 9:30AM - 5:00PM.
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, Eleni A. Shiferaw can be reached at (571) 272-3867. 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.
/DUILIO MUNGUIA/Examiner, Art Unit 2497 /ELENI A SHIFERAW/ Supervisory Patent Examiner, Art Unit 2497
Prosecution Insights