DETAILED ACTION
The following claims are pending in this office action: 1-6, 8-10, 13-16 and 18
Claim 1 is independent
The following claims are new: -
The following claims are cancelled: 7, 11-12, and 17
Claims 1-6, 8-10, 13-16 and 18 are rejected. This rejection is FINAL.
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 .
Previous Objections and/or Rejections Withdrawn
The objections to claims 2-3 are withdrawn based on the amendments.
The 35 U.S.C. § 112(b) rejections to claims 1-8 are withdrawn based on the amendments.
RESPONSE TO ARGUMENTS
Applicant’s arguments in the amendment filed 07/29/2025 have been fully considered but are moot in view of new grounds of rejection necessitated by amendment.
Applicant notes: “the proposed combination of Landrok and Singh ... fails to disclose all elements of amended independent claim 1.” The amended limitations are disclosed by Wilson et al. (US Pub. 2023/0132934) as explained below and rejected accordingly.
Dependent claims 2-6, 8-10, 13-16 and 18 depend on independent claims 1. The amended elements in the claims are disclosed as explained below, and so any additional features to the dependent claims are rejected accordingly.
Additionally, Applicant’s arguments are not persuasive.
First, Applicant argues that Landrok does not disclose enrolling a client application to register a service, and so does not establish a prima facie case of obviousness.
…claim 1 is directed to enrolling a client application to access a service provided by the host backend .... Landrok does not disclose “enrolling, by a computer program executed by a client backend for a client application and with a host backend program, a client application identifier for the client application to access a service provided by the host backend.” (Arguments, pg. 10)
... Instead of enrolling a client application to use as a service, Landrok discloses registering a user to access a system. Thus, because Landrok registers a user, there is no disclosure of “enrolling ... a client application identifier for the client application to access a service provided by the host backend.” (Arguments, pg. 11)
If an applicant disagrees with any factual findings by the Office, an effective traverse of a rejection based wholly or partially on such findings must include a reasoned statement explaining why the applicant believes the Office has erred substantively as to the factual findings. A mere statement or argument that the Office has not established a prima facie case of obviousness will not be considered substantively adequate to rebut the rejection or an effective traverse of the rejection under 37 CFR 1.111(b). See MPEP §2141. The Patent and Trademark Office determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction "in light of the specification as it would be interpreted by one of ordinary skill in the art." In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364[, 70 USPQ2d 1827, 1830] (Fed. Cir. 2004). Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitations that are not part of the claim.” See MPEP 2111.
Landrok teaches that “a unique, secure authentication token is generated which links together a user’s personal computing device(s) ... The security token is typically a software-based token which is unique to each computing device registered to use the secure payment system, and is used to prove the identity of the device during a transaction.” Landrok, para. 0083. “User A and his Device D have been pre-registered in the secure payment system, as described above ... User A uses his Device D to make the transaction, thereby avoiding the need to enter the details written on his debit or credit card at any point during the transaction.” Landrok, para. 0116. Thus, Landrok teaches registering/enrolling a user software-based token to make/access a transaction/service/system.
Here, Applicant argues that instead of registering a software application, Landrok teaches registering a user. However, in the field of computer/software security, to a person of ordinary skill in the art, it appears this is an obvious distinction. By registering/enrolling the user/user device, the software associated with the user device is accordingly registered/enrolled so that direct associated credentials do not have to be repeated applied. Directly registering an application associated with the device is more clearly taught by Wilson et al. (US Pub. 2023/0132934) as explained below. As Landrok in view of Wilson teaches enrolling/registering and application to provide a service, Applicant’s argument is moot in view of the rejection below necessitated by amendment.
Additionally, Applicant argues Examiner uses hindsight to modify the system of Landrok, which is impermissible.
…Because Landrok enrolls a user to access a system, there is no reason for Landrok to store details about a service to be accessed, a time period for the access, or a client application identifier as recited in amendment claim 1. The only possible reason for this modification is the application of hindsight, which is improper. (Arguments, pg. 12)
“[A]ny judgment on obviousness is in a sense necessarily a reconstruction based on hindsight reasoning, but so long as it takes into account only knowledge which was within the level of ordinary skill in the art at the time the claimed invention was made and does not include knowledge gleaned only from applicant’s disclosure, such a reconstruction is proper.” In reMcLaughlin, 443 F.2d 1392, 1395, 170 USPQ 209, 212 (CCPA 1971). Applicants may also argue that the combination of two or more references is “hindsight” because “express” motivation to combine the references is lacking. However, there is no requirement that an “express, written motivation to combine must appear in prior art references before a finding of obviousness.” See Ruiz v. A.B. Chance Co., 357 F.3d 1270, 1276, 69 USPQ2d 1686, 1690 (Fed. Cir. 2004). See also Uber Techs., Inc. v. X One, Inc., 957 F.3d 1334, 1339-40, 2020 USPQ2d 10476 (Fed. Cir. 2020).
As explained below, Singh discloses several additional fields, such as a validity timestamp and a server ID that corresponds to the backend service which are used as part of access the service. “The server ID may indicate the Internet protocol (IP) address of a server providing the backend service ... the transmitted access token may have a validity timestamp associated with the validity of the access token.” Singh, para. 0027. “API gateway validates the access token and authorizes the client application to access the backend service via ... The access token ... In an example, the validity period of the access token may be decided based on the security requirement of the backend service.” Thus, Singh expressly discloses written motivation to have a validity timestamp field and a service identifier field: to meet the security requirement of the backend service thereby increasing security.
Here, Applicant argues that as Examiner uses hindsight reasoning, the rejection is improper. However, as Applicant also notes in pg. 12 of the Arguments, any judgement on obviousness is necessarily a reconstruction based on hindsight reasoning. Examiner does not use impermissible hindsight reasoning as the express motivations to combine are found in the cited prior art. Including a client application identifier is more clearly taught by Wilson as explained below. As the prior art includes express motivations to combine, Applicant’s argument that Examiner uses impermissible hindsight reasoning, is not persuasive.
Finally, Applicant argues that Landrok fails to disclose a security token.
…Instead of disclosing a security token ... Lanrok discloses either ... authentication token that comprises a static or dynamic password token, or a SMS message that includes a passcode. This is not the claimed security token ... Landrok discloses sending a passcode by SMS ... a passcode sent by SMS is not the claimed security token.
(Arguments, pg. 13)
If an applicant disagrees with any factual findings by the Office, an effective traverse of a rejection based wholly or partially on such findings must include a reasoned statement explaining why the applicant believes the Office has erred substantively as to the factual findings. A mere statement or argument that the Office has not established a prima facie case of obviousness will not be considered substantively adequate to rebut the rejection or an effective traverse of the rejection under 37 CFR 1.111(b). See MPEP §2141. The Patent and Trademark Office determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction "in light of the specification as it would be interpreted by one of ordinary skill in the art." In re Am. Acad. of Sci. Tech. Ctr., 367 F.3d 1359, 1364[, 70 USPQ2d 1827, 1830] (Fed. Cir. 2004). Though understanding the claim language may be aided by explanations contained in the written description, it is important not to import into a claim limitations that are not part of the claim.” See MPEP 2111.
Landrok teaches that the first authentication identifier is generated based on a passcode which is exchanged at registration, the passcode (or token) needs to be kept secret”. Landrok, para. 0042. Furthermore, “a unique, secure authentication token is generated which links together a user’s personal computing device(s) ... The security token is typically a software-based token which is unique to each computing device registered to use the secure payment system, and is used to prove the identity of the device during a transaction.” Landrok, para. 0083. “When the authentication server receives a message (or data) from the smartphone indicating the user wishes to process a transaction, the authentication server generates ... an SMS message (or similar) and sends this to the smartphone via an SMS gateway (second channel) ... The SMS message comprises a short authentication code (or passcode).” Landrok, para. 0123. Thus, Landrok teaches a passcode that is a security token.
Here, Applicant argues that the passcode provided via SMS is not a security token. Landrok expressly discloses that passcode and token may be used interchangeably. As explained above, although the token does not contain the client backend identifier, an identifier for the service, and a time period, these elements are disclosed by Singh and obvious to include for the reasons as disclosed above and below. In other words, elements are necessary for meeting the security requirements of a backend server to verify the validity of the client request. The SMS message/token of Landrok is used to determine, by the authentication server, when it is sent back to the authentication server that it is valid in order to process the transaction. Similarly, the security token of the Instant Application is used to determine whether it is valid to process access to the service. It is unclear why a passcode would not be a “security token” given its broad meaning to a person of ordinary skill in the art. As the prior art establishes clearly that a passcode is a security token, Applicant’s argument that it is not a security token is not persuasive.
Claim Objections
Claim 15 is objected to because of the following informalities:
Claim 15 recites the limitation “the signed encryption security token” (claim 15, ln. 5-6). Examiner suggests “the signed encrypted security token” to conform with other instances of the same limitation. See for example, claim 15, ln. 2.
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.
Claims 1, 6 and 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Landrok et al. (US Pub. 2017/0364911) (hereinafter “Landrok”) in view of Singh et al. (US Pub. 2023/0018767) (hereinafter “Singh”) in view of Wilson et al. (US Pub. 2023/0132934) (hereinafter “Wilson”) and evidenced by “IEEE Standard Glossary of Computer Hardware Terminology”; Glossary [online]; IEEE Standards Board; 1994 [retrieved on 2025-05-06]; Retrieved from the Internet <URL: https://ieeexplore.ieee.org/stamp/ stamp.jsp?arnumber=477873> (hereinafter “Glossary”).
As per claim 1, Landrok teaches a method for enrolling a client to protect unauthenticated computer applications, comprising: ([Landrok, para. 0095] “embodiments provide a way to identify a user and his computer device properly ... to prevent [protect] attacks where parts or all of the transaction data forwarded by the user are altered by a third party [unauthorized computer applications] ... the user forwards the details of a transaction to the secure backend payment system”; [para. 0107] “Fig. 3 is a flow chart of example steps [a method] for a user to register [enrolling a client] to use the secure payment system”)
enrolling, by a computer program ([Landrok, para. 0090] “The computing device comprises payment authorisation software, preferably in the form of a software application (‘app’) 18”; [para. 0108] “Once installed, User A uses the app to register himself to use the system”) executed by a client backend ([para. 0108] “The computing device comprises a processor 12a coupled to program memory 12b storing computer program code to implement the backend payment method”; Glossary 3.132 and 3.133 on pg. 8 explains that the backend processor of a computer handles procedures that are non-user interface related such as database access, simulation, or vector processing; here, executing the application to communicate with the backend is not user interface related, and so the processor 12a is a client backend) for a client application ([para. 0118] “activating the software or ‘app’ ... to start a payment session using the secure backend payment system”) and with a host backend computer program, ([para. 0087; Fig. 2a] “program memory 26b storing computer program code to implement the backend payment method”; [para. 0108] “Once installed, User A uses the app to register himself to use the system (S302) ... providing information that the secure backend can use to map User A; enrolling a client application identifier for the client application to access a service provided by a host backend is more clearly taught by Wilson below) the client application to access a service provided by the host backend; ([para. 0088] “The processor 12a ... to implement functions, including ... interface, storage and import and export [access a service] from the device”; [para. 0118] “User A progresses the transaction by activating the software or ‘app’ [the client application] on Device D to start a payment session [access a service] using the secure backend payment system [by the host backend]”)
creating, by the host backend computer program, a database entry in a database that stores a client backend identifier for the client backend; ([Landrok, para. 0113] “User A is also required to register his Device D for use with the system... User A may use the same ‘app’ to register his Device D, where the app may communicate details about the Device D to the system to identify the device ... The device registration module of the backend secure payment system [by the host backend computer program – see para. 0093: “The secure backend payment system 26 comprises ... computer program code”] generates [creating] a unique ID for Device D [a client backend identifier for the client backend as the client backend executes on the device] ... and stores this with any other details about Device D [database entry] in the data store [a database]”; creating a database entry in a database, an identifier for the service, and a time period for the access is more clearly taught by Singh below)
receiving, by the client application executed on a user mobile device, user information; ([Landrok, para. 0112] “The unique user ID is transmitted to the ‘app’ running on Device D and stored on Device D for use by the app”)
calling, by the client application, the host backend computer program with an application identifier for the client application; ([Landrok, para. 0125] “The software application applies [calling by the client application] a MAC algorithm (message authentication code) to the transaction details using the key, and outputs a MAC [an application identifier for the client application as it is an authentication/identifier code created by the application] ... to the authentication server [the host backend computer program – see Fig. 2a as the server is part of the backend system]”)
generating, by the host backend computer program, a security token; and ([Landrok, para. 0123] “the authentication server [the host backend computer program] generates ... passcode”; [para. 0083] “The security token is ... a dynamic password”)
sending, by the host backend computer program, the security token to the client backend, ([Landrok, para. 0123] “the authentication server [the host backend] generates ... an SMS message (or similar) and sends this to the smartphone [to the client backend as the backend/processor of the client handles database access/import of data as explained above] ... The SMS message comprises a ... passcode”) wherein the client backend is configured to send the security token to the client application. ([para. 0124] “This code is extracted from the SMS message [send the security token] by the app [to the client application] running on the Device D”; as the app extracts the code/security token, the security token is necessarily sent by the client backend as the client backend/mobile device processor facilitates database access/import of the data)
Landrok does not clearly teach enrolling a client application identifier for the client application to access a service provided by a host backend; creating a database entry in a database that stores an identifier for the service, the client application identifier, and a time period for the access; calling, by the client application, the host backend computer program with the client application identifier; and generating a security token comprising the client backend identifier, the identifier for the service, and the time period for the access.
However, Singh teaches creating a database entry in a database, ([Singh, para. 0048] “information may include ... a validity timestamp, a server ID ... corresponding to the access token [database entry] stored at the token database [database] ... to validate the new access token before allowing access to the backend service”) an identifier for the service, ([para. 0027] “The server ID may indicate the Internet protocol (IP) address of a server providing the backend service”) and a time period for the access; and ([para. 0013] “On receiving the API call from the client application with the access token, the API gateway validates the access token and authorizes the client application to access the backend service ... the access token generated ... for processing the API call may be short-lived and may have a limited validity period [a time period for the access]”)
generating a security token comprising the client backend identifier, the identifier for the service, and the time period for the access. ([Singh, para. 0025] “generate an access [security] token, encrypt sensitive data within the access token body”; [para. 0027] “The information present in the access token ... include an identifier [client backend identifier as the token information is information associated with the client device], a signature, a server ID [identifier for the service], and the validity timestamp [time period for the access]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok with the teachings of Singh to include creating a database entry in a database, an identifier for the service, and a time period for the access; and generating a security token comprising the client backend identifier, the identifier for the service, and the time period for the access; and generating a security token comprising the client backend identifier, the identifier for the service, and the time period for the access. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing the access to meet the security requirement of the backend service, and furthermore, such a validity timestamp would be helpful preventing a denial-of-service situation by a malicious device. (Singh, para. 0013; para. 0037; and para. 0043)
Landrok in view of Singh does not clearly teach enrolling a client application identifier for the client application to access a service provided by a host backend; creating a database entry in a database that stores the client application identifier; and calling, by the client application, the host backend computer program with the client application identifier.
However, Wilson teaches enrolling a client application identifier for the client application ([Wilson, para. 0135] “upon validation of the ... registration request [enrolling], the IMAS 135 generates application instance-specific credentials 119 which are specific to the application instance 117 [for the client application] ... The application instance specific credentials include a client identifier [client application identifier]”) to access a service provided by a host backend; ([para. 0147] “upon validation of the application instance-specific credentials ... generates an ... authz code”; [para. 0149] “validates the authz code ... generates an access token”; [para. 0151] “the application instance 117 then uses the access token received ... to perform the desired business function ... by accessing one or more ... services of the TPAP [services provided by a host backend]”; [para. 0061] “The IMAS 135 is a backend identity management and authentication/authorization system/service ... used ... to access a protected resource of a third party access provider ... TPAP”)
creating a database entry in a database that stores the client application identifier; and ([Wilson, para. 0136] “The IMAS 135 stores [creating a database entry] the application instance-specific credentials 119 [the client application identifier] and the associations in a data storage unit [a database] accessible to the IMAS 135”)
calling, by the client application, the host backend computer program with the client application identifier. ([Wilson, para. 0139] “the registered application instance 117 [the client application instance] can now use the application instance-specific credentials 119 [with the client application identifier] ... for access resources [calling the host backend computer program]”; [para. 0140] “the application instance 117 generates an authorization code request ... the application instance 117 retrieves, from a data storage unit accessible to the user device 101, the stored application instance-specific credentials 119 and includes the application instance-specific credentials 119 in the authz code request; [para. 0149] “the application instance 117 [by the client application] transmits [calling] an access token request including the authz code [with the client application identifier] to the IMAS 135 [the host backend computer program]”; [para. 0060] “The various entities [including the IMAS – see Fig. 1] ... implemented in software”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Singh with the teachings of Wilson to include enrolling a client application identifier for the client application to access a service provided by a host backend; creating a database entry in a database that stores the client application identifier; and calling, by the client application, the host backend computer program with the client application identifier. One of ordinary skill in the art would have been motivated to make this modification because by generating client credentials that are specific to each application instance, this provides a significant improvement over prior art techniques that use the same client credentials for different instances of the same application by providing a more secure and robust implementation. (Wilson, para. 0055)
As per claim 6, Landrok in view of Singh and Wilson teaches claim 1.
Landrok does not clearly teach wherein the security token comprises a JSON Web Token (JWT).
However, Singh teaches wherein the security token comprises a JSON Web Token (JWT). ([Landrok, para. 0025] “the access token may be a JSON web token (JWT)”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include wherein the security token comprises a JSON Web Token (JWT). One of ordinary skill in the art would have been motivated to make this modification because by using such existing authentication protocols, the client application is allowed to access the backend services, such as a web/java service securely. (Singh, para. 0012; para. 0024)
As per claim 9, Landrok in view of Singh and Wilson teaches claim 1.
Landrok also teaches receiving, at the host backend computer program, the security token ([Landrok, para. 0124] “The short authentication code [passcode/security token – see para. 0123 that describes the short authentication code as a “passcode” and para. 0042 that describes the passcode as a security token] ... sent ... to the authentication server [host backend computer program]”) and a request for access to the service; and ([para. 0116] “User A selects [requests] an item or service to purchase [access to the service]”)
granting, by the host backend computer program, access to the service. ([Landrok, para. 0127] “the POS terminal [by the host backend computer program – see para. 0086: “POS terminals ... receive the information they require ... to process and complete a transaction ... acquired from the backend system”] ... is used to complete the transaction [granting access to the service]”)
Landrok does not clearly teach determining, by the host backend computer program, that the security token is not encrypted; and identifying, by the host backend computer program, the database entry corresponding to the security token in the database; and determining, by the host backend computer program, that a current time is within the time period in the database entry.
However, Singh teaches determining, by the host backend computer program, that the security token is not encrypted; ([Singh, para. 0048] “the API gateway 102 [the host backend computer program as: “An application processing interface (API) gateway is used for supporting multiple backend services” – see para. 0012 and “software ... to perform the functions of the API gateway 102 as described within” – see para. 0026] may decrypt the access token [determining that the security token is not encrypted as a decrypted token is not encrypted] and extract information from the access token”)
identifying, by the host backend computer program, the database entry corresponding to the security token in the database; and ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token [the security token] with the information corresponding to the new access token stored at the token database 116 [the database entry corresponding to the security token in the database] of the API gateway 102 to validate the new access token before allowing access to the backend service”)
determining, by the host backend computer program, that a current time is within the time period in the database entry. ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token [a timestamp of when the current access token was generated, and so current time – see para. 0034] with the information corresponding to the new access token stored at the token database 116 [the database entry corresponding to the security token in the database] of the API gateway 102 to validate the new access token before allowing access to the backend service ... The information may include ... a validity timestamp [the period in the database]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include determining, by the host backend computer program, that the security token is not encrypted; identifying, by the host backend computer program, the database entry corresponding to the security token in the database; and determining, by the host backend computer program, that a current time is within the time period in the database entry. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing the access to meet the security requirement of the backend service, and furthermore, such a validity timestamp/period would be helpful preventing a denial-of-service situation by a malicious device. (Singh, para. 0013; para. 0037; and para. 0043)
As per claim 10, Landrok in view of Singh and Wilson teaches claim 9.
Landrok in view of Wilson does not clearly teach validating, by the host backend computer program, that the client backend identifier for the client backend is valid.
However, Singh teaches validating, by the host backend computer program, that the client backend identifier for the client backend is valid. ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token with the information corresponding to the new access token stored at the token database 116 [the database entry corresponding to the security token in the database] of the API gateway 102 to validate the new access token before allowing access to the backend service ... The information may include ... an identifier [client backend identifier as the token information is information associated with the client device]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include validating, by the host backend computer program, that the client backend identifier for the client backend is valid. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing the access to meet the security requirement of the backend service. (Singh, para. 0013; para. 0037; and para. 0043)
Claims 2-3 and 14-16 are rejected under 35 U.S.C. 103 as being unpatentable over Landrok in view of Singh and Wilson as applied to claim 1 above, and further in view of Cannata, Jr. et al. (US Pub. 2023/0163967) (hereinafter “Cannata”)
As per claim 2 Landrok in view of Singh and Wilson teaches claim 1.
Landrok also teaches associating, the host backend computer program, the security token with the database entry for the client backend; and ([Landrok, para.0094] “the user and device registration module 30 is used to create the strong binding or secure authorisation token [the security token] between a user and user device [for the client backend] ... Once this relationship [association] between user and user device is defined in the registration module 30 ... and stored in a data store 34 [with the database entry] ... the relationship can be used to authorise subsequent transaction”; the security token being a signed security token is more clearly taught by Singh below)
storing, by the host backend computer program, the association in the database; and ([Landrok, para.0094] “the strong binding or secure authorisation token [association] ... defined in the registration module 30 [by the registration module] ... stored in a data store 34 [storing in the database] ... the relationship can be used to authorise subsequent transaction”)
wherein the client backend is configured to send the security token to the client application. ([Landrok, para. 0124] “This code is extracted from the SMS message [send the security token] by the app [to the client application] running on the Device D”; as the app extracts the code/security token, the security token is necessarily sent by the client backend as the client backend/mobile device processor facilitates database access/import of the data; wherein the host backend computer sends the signed security token to the client backend, and wherein the security token is a signed security token is more clearly taught by Singh below)
Landrok in view of Wilson does not clearly teach retrieving, by the host backend computer program, a signing key from a key management service; signing, by the host backend computer program, the security token with the signing key; and wherein the host backend computer sends the signed security token to the client backend.
However, Singh teaches signing, by the host backend computer program, the security token with the signing key; and ([Singh, para. 0025] “The token issuer 112 [by the backend computer program as the backend generates the token as described above] may generate an access token ... and sign the access token using a signature ... a private key”)
wherein the host backend computer sends the signed security token to the client backend. ([Singh, para. 0025] “The token issuer 112 [the host backend computer] may transmit a signed encrypted access token [sends the signed security token] to a client application [to a client backend] ... requesting access to a backend service”; [para. 0021] “a first network interface... to control access to the backend services ... by the client applications ... applications ... external to the API gateway ... a backend service”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include signing, by the host backend computer program, the security token with the signing key; and wherein the host backend computer sends the signed security token to the client backend. One of ordinary skill in the art would have been motivated to make this modification because by using a signature of the host backend computer, authentication of client devices requesting access may be performed to provide the benefit of supporting multiple backend services that require authentication before accessing the backend services. (Singh, para. 0012; and para. 0016)
Landrok in view of Singh and Wilson do not clearly teach retrieving, by the host backend computer program, a signing key from a key management service.
However, Cannata teaches retrieving, by the host backend computer program, a signing key from a key management service. ([Cannata, para. 0040] “The authorization service node [the host backend computer program as the authorisation is performed by the authentication server of the Secure Backend Payment System as explained above and para. 0094 of Landrok] requests a private key [a signing key] ... from the key management service node 108b [a key management service] ... to be used in signing ... the unencrypted access token”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Singh and Wilson with the teachings of Cannata to include retrieving, by the host backend computer program, a signing key from a key management service. One of ordinary skill in the art would have been motivated to make this modification because by using a key management service, the benefit of separation, independence, and personalized security of each customer’s authentication is ensured as the key management service distributes, and rotates public and private key pairs. (Cannata, para. 0034; and para. 0050)
As per claim 3, Landrok in view of Singh and Wilson and further in view of Cannata teaches claim 2.
Landrok also teaches wherein the security token has a length of less than a predetermined length. ([Landrok, para. 0124] “The short [less than] authentication code [passcode/security token – see para. 0123 that describes the short authentication code as a “passcode” and para. 0042 that describes the passcode as a security token] may be 4 to 6 [predetermined] digits in length”)
Landrok in view of Wilson does not clearly teach wherein the security token is a signed security token.
However, Singh teaches wherein the security token is a signed security token. ([Singh, para. 0025] “The token issuer 112 [by the backend computer program as the backend generates the token as described above] may generate an access token ... and sign the access token using a signature ... a private key”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Landrok, Singh, Wilson and Cannata for the same reasons as disclosed above.
As per claim 14, Landrok in view of Singh and Wilson teaches claim 1.
Landrok also teaches receiving, at the host backend computer program, the security token and a request for access to the service; and ([Landrok, para. 0124] “The short authentication code [passcode/security token – see para. 0123 that describes the short authentication code as a “passcode” and para. 0042 that describes the passcode as a security token] ... sent ... to the authentication server [host backend computer program]”) and a request for access to the service; and ([para. 0116] “User A selects [requests] an item or service to purchase [access to the service]”)
granting, by the host backend computer program, access to the service. ([Landrok, para. 0127] “the POS terminal [by the host backend computer program – see para. 0086: “POS terminals ... receive the information they require ... to process and complete a transaction ... acquired from the backend system”] ... is used to complete the transaction [granting access to the service]”)
Landrok in view of Wilson does not clearly teach determining, by the host backend computer program, that the security token is encrypted; retrieving, by the host backend computer program, an encryption key from a key management service; decrypting, by the host backend computer program, the security token using the encryption key; and determining, by the host backend computer program, that the time period is valid.
However, Singh teaches determining, by the host backend computer program, that the time period is valid. ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token [the time period] with the information corresponding to the new access token stored at the token database 116 of the API gateway 102 to validate the new access token [determining that the time period is valid] before allowing access to the backend service ... The information may include ... a validity timestamp”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include determining, by the host backend computer program, that the time period is valid. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing the access to meet the security requirement of the backend service, and furthermore, such a validity timestamp would be helpful preventing a denial-of-service situation by a malicious device. (Singh, para. 0013; para. 0037; and para. 0043)
Landrok in view of Singh and Wilson does not clearly teach determining, by the host backend computer program, that the security token is encrypted; retrieving, by the host backend computer program, an encryption key from a key management service; and decrypting, by the host backend computer program, the security token using the encryption key.
However, Cannata teaches determining, by the host backend computer program, ([Cannata, para. 0043] “described techniques ... implemented in a ... back-end component”) that the security token is encrypted; ([para. 0043] “receives [determining] ... encrypted access token [that the security access token is encrypted]”)
retrieving, by the host backend computer program, an encryption key from a key management service; and ([Cannata, para. 0040] “receives public keys [an encryption key] from the key management service node 108b [key management service] in order to validate and decrypt access tokens”)
decrypting, by the host backend computer program, the security token using the encryption key. ([Cannata, para. 0040] “public keys ... to ... decrypt access tokens”; [para. 0043] “decrypts (step 210) the access token”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson and Singh with the teachings of Cannata to include determining, by the host backend computer program, that the security token is encrypted; retrieving, by the host backend computer program, an encryption key from a key management service; and decrypting, by the host backend computer program, the security token using the encryption key. One of ordinary skill in the art would have been motivated to make this modification because by using a key management service, the benefit of separation, independence, and personalized security of each customer’s authentication is ensured as the key management service creates, distributes, and rotates public and private key pairs. (Cannata, para. 0034; and para. 0050)
As per claim 15, Landrok in view of Singh, Wilson and further in view of Cannata teaches claim 14.
Landrok in view of Wilson does not clearly teach wherein the security token is received with a signed encrypted security token, and further comprising: retrieving, by the host backend computer program, a signing key from the key management service; and verifying, by the host backend computer program, a signature on the signed encryption security token.
However, Singh teaches wherein the security token is received with a signed encrypted security token, and further comprising: ([Singh, para. 0025] “The token issuer 112 may transmit a signed encrypted access token”; [para. 0047] “the API gateway 102 may receive a request to access a backend service from a client application using the new access token”)
verifying, by the host backend computer program, a signature on the signed encryption security token. ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token with the information corresponding to the new access token stored at the token database 116 of the API gateway 102 to validate the new access token ... The information may include ... a signature”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson with the teachings of Singh to include determining, by the host backend computer program, that the time period is valid. One of ordinary skill in the art would have been motivated to make this modification because by using a signature of the host backend computer, authentication of client devices requesting access may be performed to provide the benefit of supporting multiple backend services that require authentication before accessing the backend services and encrypting sensitive data provides secure access to the backend services. (Singh, para. 0012; para. 0016; para. 0021; para. 0025)
Landrok in view of Singh and Wilson does not clearly teach retrieving, by the host backend computer program, a signing key from the key management service.
However, Cannata teaches retrieving, by the host backend computer program, ([Cannata, para. 0043] “described techniques ... implemented in a ... back-end component”) a signing key from the key management service. ([para. 0040] “The authorization service node 108a requests a private key ... the key management service node 108b provides a public-private key pair to the authorization service node 108a”; [para. 0041] “the authorization service node 108a uses the private key from the key pair to ... sign the unencrypted access token)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to combine the teachings of Landrok, Singh, Wilson and Cannata for the same reasons as disclosed above.
As per claim 16, Landrok in view of Singh, Wilson and further in view of Cannata teaches claim 14.
Landrok in view of Wilson and Cannata does not clearly teach validating, by the host backend computer program, that the client backend identifier for the client backend is valid.
However, Singh teaches validating, by the host backend computer program, that the client backend identifier for the client backend is valid. ([Singh, para. 0048] “the API gateway 102 [host backend computer program] may compare the information extracted from the new access token with the information corresponding to the new access token stored at the token database 116 [the database entry corresponding to the security token in the database] of the API gateway 102 to validate the new access token before allowing access to the backend service ... The information may include ... an identifier [client backend identifier as the token information is information associated with the client device]”)
It would have been obvious before the effective filing date of the claimed invention for one of ordinary skill in the art to have modified the elements disclosed by Landrok in view of Wilson and Cannata with the teachings of Singh to include validating, by the host backend computer program, that the client backend identifier for the client backend is valid. One of ordinary skill in the art would have been motivated to make this modification because such a technique would provide the benefit of allowing the access to meet the security requirement of the backend service. (Singh, para. 0013; para. 0037; and para. 0043)
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Landrok in view of Singh and Wilson as applied to claim 1 above, and further in view of Tiwari et al. (US Pub. 2016/0308851) (hereinafter “Tiwari”) and Cannata.
As per claim 4, Landrok in view of Singh teaches claim 1.
Landrok also teaches wherein the client backend is configured to send the security token to the client application. ([Landrok, para. 0124] “This code is extracted from the SMS message [send the security token] by the app [to the client application] running on the Device D”; as the app extracts the code/security token, the security token is necessarily sent by the client backend as the client backend/mobile device processor facilitates database access/import of the data; wherein the host backend computer sends the signed encrypted security token to the client backend and wherein the security token is a signed encrypted security token is taught more clearly by Singh below; wherein the host backend computer sends the signed security token [that is not also an encrypted token] to the client backend, and wherein the security token is a signed security token [that is not also an encrypted token] is more clearly taught by Tiwari below)
Landrok in view of Wilson does not clearly teach retrieving, by the host backend computer program, an encryption key and a signing key from a key management service; encrypting, by the host backend computer program, the security token; signing, by the host backend computer program, the encrypted security token with the signing key; signing, by the host backend computer program, the security token with the signing key; and wherein the host backend computer sends the signed security token and the signed encrypted security token to the client backend.
However, Singh teaches encrypting, by the host backend computer program, the security token; [Singh, para. 0025] “The token issuer 112 [by the backend computer program as the backend generates the token as described above] may generate an access token, encrypt sensitive data within the access token body”)
signing, by the host backend computer program, the encrypted security token