Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
The following is a non-final Office Action in response to application number 18971698 filed on December 06, 2024. Claims 1-10 are currently pending, and have been examined.
Claim Objections
Claim 4 is objected to because of the following informalities: “storing the authentication ID in memory from later retrieval” should read “storing the authentication ID in memory for later retrieval”.
Claim 5 is objected to because of the following informalities: “transmitting, …, the consent message requesting creation a consent session …” should read “transmitting, …, the consent message requesting creation of a consent session …”.
Claim Rejections - 35 USC § 101
35 U.S.C. § 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-10 are rejected under 35 U.S.C. § 101 because the claimed invention is directed to an abstract idea without significantly more.
In the instant case, claims 1-10 are directed to a “method. Therefore, these claims are directed to one of the four statutory categories of invention.
Claim 1 recites “authentication and consent in accessing cardholder financial data”, which is a form of commercial or legal interactions (i.e., organizing human activity), and an abstract idea. Specifically, the claim recites: “receiving, at the third party provider computing device, an access approval message from the cardholder computing device; receiving, at the authentication provider computing device, a request message from the third party provider computing device to create an authentication session; transmitting, by the authentication provider computing device, an authentication identifier (ID) to the cardholder computing device; authenticating the cardholder computing device at the authentication provider computing device; receiving, at the consent provider computing device, a request from the authentication provider computing device to create a consent session; transmitting, by the consent provider computing device, a list of data services to which the third party provider computing device is requesting access; receiving, at the consent provider computing device, a consent message from the cardholder computing device, the consent message including cardholder consent information indicating consent to one or more of the data services; receiving, at the consent provider computing device, transaction card details from the cardholder computing device, the transaction card details corresponding to a transaction card of a cardholder and being associated with a financial account of the cardholder; transmitting, by the consent provider computing device, a request to generate a digital access token by the open service API based on the transaction card details and the cardholder consent information; and transmitting, by the consent provider computing device, the digital access token to the cardholder computing device”, where the italicized claim language represents the abstract idea “authentication and consent in accessing cardholder financial data”. (MPEP §2106.04 II.A.1.).
This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP §2106.04 II.A.2.), the additional elements of the claim (the bolded claim language), such as “the third party provider computing device”, “the cardholder computing device”, “the authentication provider computing device”, “the consent provider computing device”, “to generate a digital access token by the open service API”, and “transmitting, by the consent provider computing device, the digital access token to the cardholder computing device”, represents the use of a computer as a tool to perform an abstract idea. Therefore, the additional elements do not integrate the abstract idea into a practical application as they do no more than represent a computer performing functions that correspond to implementing the acts of “authentication and consent in accessing cardholder financial data”.
The limitations of “receiving , …, an access approval message …”, “receiving, …, a request message …”, “receiving, …, a request … to create …”, “receiving, …, a consent message …”, “receiving, …, transaction card details …”, and “transmitting an authentication identifier (ID) …”, “transmitting, …, a list of data services …”, “transmitting, …, a request to generate …”, as additional elements, are recited at a high level of generality (i.e., as a general means of gathering an access approval, a request, a consent, transaction card details, and data outputting, such as transmitting an authentication identifier (ID), a list of data services, a request to generate), and amounts to mere data gathering and data output, which are forms of insignificant extra-solution activity.
Accordingly, these additional elements, even in combination, do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
When analyzed under step 2B (MPEP 2106.05 I.A.), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describes the concept of “authentication and consent in accessing cardholder financial data” using computer technology (e.g., “a cardholder computing device” and “a third party provider computing device”). Therefore, as this additional elements do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or technical field. (MPEP 2106.05 I A (f) & (h)). Therefore, claim 1 is non-statutory.
Dependent claims 2-10 further describe the abstract idea of “authentication and consent in accessing cardholder financial data”, which is insufficient to overcome the rejection of claim 1.
Dependent claims 2, 4-5, and 7-10 do not recite any new additional elements that integrate the abstract idea into a practical application, and that do no more than represent a computer performing functions that correspond to implementing the acts of “authentication and consent in accessing cardholder financial data”, when analyzed under Step 2A, Prong Two.
Dependent claim 3 recites new additional elements of “a JSON web token (JWT)” and “a customer redirect URL”, which do no more than employ a computer as a tool to implement the abstract idea. And, as they do no more than employ a computer as a tool to implement the abstract idea, they do not improve computer functionality nor improve another technology or a technical field.
Dependent claim 6 recites a new additional element of “a lightbox popup window on a display of the cardholder computing device”, which does no more than employ a computer as a tool to implement the abstract idea. And, as it does no more than employ a computer as a tool to implement the abstract idea, it does not improve computer functionality nor improve another technology or a technical field.
Hence, claims 1-10 are not patent eligible.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. § 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. § 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 10 is rejected under 35 U.S.C. § 112(b) or 35 U.S.C. § 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Antecedent Basis
Claim 10 recites “The computing system in accordance with claim 1, …” There is insufficient antecedent basis for “the computing system” in claim 10. For purposes of examination, claim 10 is being interpreted as “the computer-implemented method in accordance with claim 1”. (MPEP § 2173.05 (e))
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. § 102 and § 103 (or as subject to pre-AIA 35 U.S.C. § 102 and § 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. § 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U. S. 1. 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. § 103 are summarized as follows:
Determining the scope and contents of the prior art.
Ascertaining the differences between the prior art and the claims at issue.
Resolving the level of ordinary skill in the pertinent art.
Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Courage et al (U. S. Patent Application Publication No. 20150121462 A1), herein referred to as Courage, in view of Girish et al (U. S. Patent Application Publication No. 20190020478 A1), herein referred to as Girish, and in further view of Powell et al (U. S. Patent Application Publication No. 20150127547 A1), herein referred to as Powell.
Regarding claim 1, Courage discloses a computer-implemented method performed by a network system including a cardholder computing device (FIG. 1, item 102, para 35, “… system 100 may include one or more computing devices 102 (such as desktop computers, notebook computers, netbook computers, tablet computers, smart-phones, etc.). A computing device 102 may include one or more processors ( e.g., CPU 104), one or more memories 106, an operating system (e.g., O/S 108), and a cache 118 … Computing device 102 or O/S 108 may include or support a software or user interface (e.g., a browser or a system-specific client) through which computing device 102 can access applications and resources residing on the web. Computing device 102 may execute a runtime 120 and various applications (e.g., a web application 110, a packaged application 130, a packaged application/ identity component application 140, etc.) …”), a third party provider computing device (FIG. 1, item 150, 160, para 36, “… Server 150 and server 160 may each include one or more CPUs and memories (e.g., CPU 152/Memory 154, and CPU 162/Memory 164, respectively). The one or more servers ( e.g., User Accounts server 150) may be configured to function as identity providers … under a standard authentication and authorization protocol (e.g. OAuth 2.0) or other custom protocols …”; para 37,”… and authorize requests to access protected user data or accounts on the servers (e.g., server 160) …”), an authentication provider computing device (FIG. 1, items 152, 180, 182, para 36, “… Server 150 and server 160 may each include one or more CPUs and memories (e.g., CPU 152/Memory 154 …”; para 37, “Server 150 may … include an identity provider API 180 coupled to an Identity UI 182. Identity provider API 180 may be configured to receive requests for authentication and authorization (e.g., from client devices such as computing device 102) to access protected user data on the servers. Identity provider API 180 may verify a security token as an alternative to explicitly authenticating a user (e.g., of computing device 102) and authorize requests to access protected user data or accounts on the servers (e.g., server 160) …”), a consent provider computing device (FIG. 1, items 120, 170, para 40, “Identity API 170, which may be part of runtime 120 of computing device 120, may be configured to display the web-based consent UI on computing device 120. Identity API 170 may display the web-based consent UI in conjunction with an identity component application 140, which is also installed on computing device 120 …”), and an open service API (FIG. 1, item 160, para 36, “… API/ services provider server 160) … server 160 may each include one or more CPUs and memories (e.g., … CPU 162/Memory 164, …)”; para 38, “… API/services provider server 160. User Accounts server 150 or API/services provider server 160 may provide access to the user data and accounts to packaged app 130 only if the user has authorized or consented to such access …”), said method comprising: …
receiving, at the consent provider computing device (FIG. 1, item 102, para 35), a request from the authentication provider computing device (FIG. 1, items 152, 180, 182, para 36-37) to create a consent session (FIG. 1, items 120, 150, 170, 180, para 39, “… a client-side Identity API (e.g., Identity API 170) may be configured to interact with Identity provider API 180 on server 150 and serve web-based user consent dialogs (e.g., web-based consent UI 300, FIG. 3) on computing device 102 on which the packaged app (e.g., packaged application 130) operates outside of a web browser …”; para 40, “Identity API 170, which may be part of runtime 120 of computing device 120, may be configured to display the web-based consent UI on computing device 120. Identity API 170 may display the web-based consent UI in conjunction with an identity component application 140, which is also installed on computing device 120 … the consent UI may be displayed in a web view container in identity component application 140, which may itself be a packaged application … the consent UI may be visually attached to a display of packaged app 130 itself …”);
transmitting, by the consent provider computing device (FIG. 1, items 120, 170, para 40), a list of data services to which the third party provider computing device (FIG. 1, item 150, 160, para 36-37) is requesting access (para 29, “… the Identity API may be configured to let the packaged app request an access token (e.g., OAuth access token), which may allow the packaged app to make web service calls on behalf of the user to the user's web account. A range of resources made available and operations permitted in the user's web account by the access token may be controlled during the access token request process via a variable parameter called 'scope'. Several scopes may be included in the access token request made by the packaged app …”;
receiving, at the consent provider computing device (FIG. 1, items 120, 170, para 40), a consent message from the cardholder computing device (FIG. 1, item 102, para 35), the consent message including cardholder consent information indicating consent to one or more of the data services (para 30, “A user consent dialog (or dialogs) may be employed to receive or process user input for user authentication and for user approval or grant of access scopes requested by a packaged app …”; para 41, “… a structure of an example runtime 120, which includes Identity API 170 that is configured to display web-based user consent dialogs for granting a packaged app access to user data or service accounts on network servers …”); …
transmitting, by the consent provider computing device (FIG. 1, items 120, 170, para 40), a request to generate a digital access token by the open service API (FIG. 1, item 160, para 36, 38) based on the transaction card details and the cardholder consent information (para 44, “… Identity API 170 may be configured so that token requests by a packaged application (e.g., packaged application 130) for access to user data or service accounts may be satisfied in …”; para 46, “… By an Issue Token call to an identity provider (e.g., identity provider API 180). This call may either return an access token (e.g., an OAuth token or other token) to the packaged application if the user has previously given consent, or may request that the user be prompted for consent …”; para 47, “From a web-based UI flow (e.g., under an OAuth 2.0 protocol). The computing device runtime (e.g., runtime 120) may be configured to make a series of calls to exchange its user login access token or other token-based user credential (obtained from credential component 212) for session cookies, and to then invoke a web-based consent UI inside a web view container that is populated with the session cookies. It will be understood that exchange of user login access token for session cookies or credentials may take place under a protocol other than the OAuth 2.0 protocol …”)
transmitting, by the consent provider computing device (FIG. 1, items 120, 170, para 40), the digital access token to the cardholder computing device (FIG. 1, items 102, 140, para 53, “… Identity component application 140 may then create a window containing a <webview>control (47), pointed at the MergeSession URL, with a continuation URL pointed to the OAuth authorization URL for Awesome Chrome App ( e.g., (request type=token;redirect url=https://<awesome-chrome-app-id>. chromiumapp.org/oauth callback)). Identity component application 140 may present a web-based scope approval UI (e.g., UI 300) in <webview> on computing device 102. The presented web-based scope approval UI, may have multiple approval steps. The user may then proceed through the web-based approval flow displayed in <webview> to grant or authorize access. Identity component application 140 may intercept the redirect to chromiumapp.org and parse the redirect URL ( 48) to extract an access token (if present), before a final result (i.e., an access token or error) is returned to packaged application 410 (49) …”; FIG. 4-6, para 63, “… The instructions when executed by one or more microprocessors may cause the computer system to obtain access tokens for an application (e.g., a packaged application) as described with reference to FIGS. 4-6”).
Courage does not specifically disclose, however, Girish discloses receiving, at the authentication provider computing device (FIG. 1, item 112A; para 26, “An "access control server computer" may be configured to authenticate a user. An access control server computer can receive authentication request messages. An access control server computer may be configured to transmit challenge request messages and receive challenge response messages from a user computing device (or application operating thereon) or a service provider computer … the access control server computer may be further configured to verify the enrollment of an account in a secure authentication program, perform a risk analysis to determine whether the transaction should be authenticated, and return an authentication response message to a resource provider computer …”), a request message from the third party provider computing device to create an authentication session (FIG. 1, item 110; para 27, “A "directory server computer" may include a server that can perform message routing … the directory server computer may be capable of receiving messages (e.g., authentication request messages, authentication response messages, etc.), determining the appropriate destination computer for the received messages, and routing the received messages to the appropriate destination computer (e.g., an access control server computer)…”; para 36, “A "challenge request message" may include a message sent as part of an authentication process for a user and/or user computing device … the challenge request message may contain a request for the user to submit a pre-established authentication data in order to authenticate an account or payment device. The challenge request message may be generated and sent (e.g., by an access control server computer) prior to authenticating the account or payment device …”);
transmitting, by the authentication provider computing device (FIG. 1, item 112A; para 26), an authentication identifier (ID) (para 53, “A "verification value" may be a value or a token that indicates successful authentication. A "verification value" may be in the form of a digital signature. The digital signature may be a cryptogram that is generated after a computer such as an access control server signs transaction data with a key (e.g., a private or a symmetric key) … a verification value is a cardholder authentication verification value, or CAVV, that may be provided by an issuer associated with a payment device upon authentication of the payment device. The verification value may be used in processing a payment authorization for a financial transaction as proof that an issuer or other authorizing entity authenticated a user …”) to the cardholder computing device (FIG. 1, item 102; para 60, “The user computing device 102 may be in any suitable form … the user computing device 102 may be hand-held and compact so that they can fit into a user's pocket … a user computing device 102 may include any device capable of accessing the Internet … a user computing device 102 may include cellular or wireless phones (e.g., smartphones), tablet phones, tablet computers, laptop computers, desktop computers, personal digital assistants (PDAs), pagers, portable computers, smart cards, and the like …”);
authenticating the cardholder computing device at the authentication provider computing device (FIG. 1, items 108, 112A; para 71, “The access control server computer 112A may comprise a server computer that may be configured to conduct authentication processes. The access control server computer 112A may be associated with an issuer, which can be an authorization entity (e.g., bank, financial institution) that issues and maintains financial accounts for a user. The access control server computer 112A may use user-specific data, user computing device data, transaction data, PAN, payment device data, geolocation data, account data, or other comparable data, in order to perform an authentication for the transaction … at the time of a transaction, the access control server computer 112A may perform the authentication, and may provide an authentication response message to the resource provider computer 108 via the directory server computer 110. The authentication response message may provide an indication to the resource provider computer 108 that the account or user computing device has been authenticated or not authenticated …”); …
Girish discloses token provisioning utilizing a secure authentication system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provision a token in reducing the number of steps required to complete millions of transactions taking place by computing resources in a computer network, which can be significant.
Courage and Girish do not specifically disclose, however, Powell discloses receiving, at the third party provider computing device (FIG. 1, item 104; para 68, “The issuer 104 may represent an issuer processor of a business entity (e.g., a bank) that may have issued an account (e.g., credit account, debit account, etc.) for payment transactions …, the business entity (bank) associated with the issuer 104 may also function as an acquirer 108. The issuer 104 may issue an account represented by a primary account number (PAN) to an account holder 102, upon request of the account holder 102 … The issuer 104 may be responsible for authorization and ongoing risk management in the tokenization eco-system environment 100. The issuer 104 may need to accommodate any data fields provided in messages passed to and from the issuer, as defined in embodiments of the present invention in order to properly process payment transaction requests …”), an access approval message from the cardholder computing device (para 61, “An "authorization response message" may be an electronic message reply to an authorization request message generated by an issuing financial institution (i.e. issuer) or a payment processing network. The authorization response message may include an authorization code, which may be a code that an account issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g. POS terminal) that indicates approval of the transaction …”; para 116, “… The issuer 104 may send a payment authorization response message to the payment network 210 approving or declining the payment transaction … The payment network 210 may send the payment modified authorization response message to the merchant 106 via the acquirer 108. Based on the authorization response message, the merchant 106 may finalize the transaction with the account holder 102 …”); …
receiving, at the consent provider computing device (para 64, “… An "agent" may be an entity appointed by the issuer to perform specific functions on behalf of the issuer. Exemplary functions may include card processing, cardholder verification using the 3-D Secure protocol, and token service … an Access Control Server (ACS) may be an agent of the issuer that provides a 3D-Secure service for identification and verification (ID&V)…”; para 92, “… the issuer verification of the account holder may be performed via 3-D Secure Access Control Server (ACS), mobile banking verification of the account holder with an authentication code, federated login systems, API functionality capable of generating, delivering, and validating data from the token requestor and shared secrets, one-time password (OTP), activation code, or other shared secret between the issuer 104 and the account holder 102. If the issuer 104 determines that there is a need to verify the account holder 102 requesting the token through an explicit verification (e.g. using an OTP or activation code), the shared secret may be delivered to the account holder 102 through an out-of-band channel …”), transaction card details from the cardholder computing device, the transaction card details corresponding to a transaction card of a cardholder and being associated with a financial account of the cardholder (para 60, “… An authorization request message may also comprise additional data elements corresponding to "identification information" including, for example, a service code, a CVV or CVC (card verification value or code), a dCVV or dCVC (dynamic card verification value or code), token cryptogram, an expiration date, etc. An authorization request message may also comprise "transaction information," such as any information associated with a current transaction (e.g. the transaction amount, merchant identifier, merchant location, etc.) as well as any other information that may be utilized in determining whether to identify and/or authorize a payment transaction …”); …
Powell discloses a network token system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide a network token system for card-not-present and hybrid transaction environments to minimize unauthorized use of account holder data, and to prevent cross-channel fraud.
Regarding claim 2, Courage, Girish, and Powell disclose the limitations of claim 1. Courage and Girish do not specifically disclose, however, Powell discloses the computer-implemented method in accordance with claim 1, further comprising transmitting, by the third party provider computing device (FIG. 1, item 104; para 68), a request to the cardholder computing device for the cardholder (FIG. 1, item 102; para 68, “… The issuer 104 may issue an account represented by a primary account number (PAN) to an account holder 102, upon request of the account holder 102. The account holder 102 may use the account to conduct payment transactions …; para 69, “The account holder 102 may wish to conduct a payment transaction with a merchant 106 using the account (represented by the PAN) issued by the issuer 104 …”) to link one or more transaction card accounts with a third party provider service (para 51, “… a token requestor ID can identify a pairing of a token requestor (e.g., a mobile device, a mobile wallet provider, etc.) with a token domain (e.g., e-commerce, contactless, etc.). A token requestor ID may include any format or type of information … the token requestor ID may include an alphanumerical value such as a ten digit or an eleven digit letter and/or number (e.g., 4678012345)… a token requestor ID may include a code for a token service provider (e.g., first 3 digits) such as the network token system and the remaining digits may be assigned by the token service provider for each requesting entity (e.g., mobile wallet provider) and the token domain (e.g., contactless, e-commerce, etc.)…”).
Powell discloses a network token system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references in providing, along with a token, a token assurance level and data used to generate the token assurance level, and the time the token is issued, steps have been taken to ensure that the token is replacing a primary account number (PAN) that was legitimately being used by a token requestor.
Regarding claim 4, Courage, Girish, and Powell disclose the limitations of claim 1. Courage and Powell do not specifically disclose, however, Girish discloses the computer-implemented method in accordance with claim 1, said operation of transmitting the authentication ID to the cardholder computing device comprises:
generating the authentication ID (FIG. 2, item 218; para 84, “… the authentication module 218 may comprise code that, when executed, causes the processor 204 to conduct a challenge process with the user computing device 102 … the authentication module 218 may be configured to cause the processor 204 to generate a challenge request message requesting a user provide a pre-established secure data element (e.g., password, token, biometric data) in order to authenticate the transaction and/or the payment device. The processor 204 may be configured to transmit the challenge request message to a user computing device and receive a challenge response message from the user computing device corresponding to the request. In such embodiments, the authentication module 218 may be configured to cause the processor 204 to evaluate a secure data element (e.g., a password, a PIN, authentication data, etc.) received in a challenge response message and determine whether the received secure data element matches a stored secure data element …”); and
storing the authentication ID in memory from later retrieval (FIG. 2, item 234; para 84, “… By way of example, the authentication module 218 may cause the processor 204 to access authentication data (e.g., the secure data element) stored in the authentication information data store 234, a data store configured to store such information and accessible to the processor 204…”).
Girish discloses token provisioning utilizing a secure authentication system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include provisioning utilizing a secure authentication system, as in Girish; and to include a network token system, as in Powell, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references in utilizing the infrastructure of a secure authentication system to provision a token for use in a transaction by a resource provider computer receiving the transaction data and request, via an authentication request message, authenticating the user through the secure authentication system.
Regarding claim 6, Courage, Girish, and Powell disclose the limitations of claim 1. Courage further discloses the computer-implemented method in accordance with claim 1, said operation of transmitting a list of data services to which the third party provider computing device (FIG. 1, item 150, 160, para 36-37) is requesting access comprises presenting the list of the data services to the cardholder via a lightbox popup window (para 32, “… a packaged app/identity component application may be configured to receive and display URL content or web page (i.e. user consent dialog) served by the identity provider/identity APL The packaged app, which is coded to operate outside of a web browser, may include a coding construct that allows display of web content ( e.g. the URL content or web page served by the identity provider/identity API) in a container in the packaged application UI or window …”) on a display of the cardholder computing device (FIG. 1, item 102, para 35).
Regarding claim 7, Courage, Girish, and Powell disclose the limitations of claim 1. Courage further discloses the computer-implemented method in accordance with claim 1, said operation of receiving the consent message from the cardholder computing device (FIG. 1, item 102, para 35) comprises receiving an input from the cardholder computing device including cardholder selection of one or more of the requested data services (para 29, “… the Identity API may be configured to let the packaged app request an access token (e.g., OAuth access token), which may allow the packaged app to make web service calls on behalf of the user to the user's web account. A range of resources made available and operations permitted in the user's web account by the access token may be controlled during the access token request process via a variable parameter called 'scope'. Several scopes may be included in the access token request made by the packaged app …”; para 30, “A user consent dialog (or dialogs) may be employed to receive or process user input for user authentication and for user approval or grant of access scopes requested by a packaged app …”).
Regarding claim 8, Courage, Girish, and Powell disclose the limitations of claim 1. Courage further discloses the computer-implemented method in accordance with claim 1, further comprising receiving, at the consent provider computing device (FIG. 1, items 120, 170, para 40), the digital access token (para 29, “… the Identity API may be configured to let the packaged app request an access token (e.g., OAuth access token), which may allow the packaged app to make web service calls on behalf of the user to the user's web account. A range of resources made available and operations permitted in the user's web account by the access token may be controlled during the access token request process via a variable parameter called 'scope'. Several scopes may be included in the access token request made by the packaged app …”; para 38, “A packaged app (e.g., packaged app 130) installed on computing device 102 may need access tokens to access protected user data … in User Accounts server 150 or API/services provider server 160. User Accounts server 150 or API/services provider server 160 may provide access to the user data and accounts to packaged app 130 only if the user has authorized or consented to such access …”) from the open service API (FIG. 1, item 160, paras 36, 38).
Regarding claim 9, Courage, Girish, and Powell disclose the limitations of claim 1. Courage and Girish do not specifically disclose, however, Powell discloses the computer-implemented method in accordance with claim 1, further comprising generating the digital access token by a token service system (FIG. 1, item112; para 67, “… A token requestor 114 and a token service provider 116 may form a token service system 112 which is also a part of the tokenization ecosystem environment 100 …”); para 69, “… a token representing the PAN may be generated by the token service system 112 and passed to the merchant server 106 (e.g. a merchant server or computer) …”), the digital access token associated with the financial account and the cardholder consent information (para 38, “… generating and issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g. token vault). The token service system may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service system may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN. In various embodiments, the token service system may include a token requestor and a token service provider interacting with the token requestor …”; para 39, “… the token vault may maintain one-to-one mapping between a token and a primary account number (PAN) represented by the token. The token service provider may have the ability to set aside licensed BINs as token BINs to issue tokens for the PANs that may be submitted to the token service provider …”).
Powell discloses a network token system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references in providing, along with a token, a token assurance level and data used to generate the token assurance level, and the time the token is issued, steps have been taken to ensure that the token is replacing a primary account number (PAN) that was legitimately being used by a token requestor.
Regarding claim 10, Courage, Girish, and Powell disclose the limitations of claim 1. Courage and Girish do not specifically disclose, however, Powell discloses the computing system in accordance with claim 1, further comprising receiving, at open service API (para 166, “… FIG. 9 illustrates the use of Application Program Interfaces (APIs) by the token service provider to facilitate token issuance and processing (e.g. to provide a token ser-vice) …”; para 167, “… the interaction between the token service provider 904 and other entities in a tokenization ecosystem environment 900 through the use of one or more APIs and/or messaging interface(s) to facilitate token requests, token issuance, ID& V performance, de-tokenization, token routing, and token lifecycle management …”), a token revocation message from the cardholder computing device (para 186, “… The ongoing changes to token-to-PAN mapping due to lifecycle events, such as PAN updates, lost or stolen devices, and deactivation of the Token due to customer relationship termination with the token requestor, may be accommodated by the token service provider when implemented according to embodiments of the present invention …”; para 190, “ … The token service provider may indicate to the payment network when the tokens that have been deemed as lost/stolen have been marked as suspended …”).
Powell discloses a network token system. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references in providing, along with a token, a token assurance level and data used to generate the token assurance level, and the time the token is issued, steps have been taken to ensure that the token is replacing a primary account number (PAN) that was legitimately being used by a token requestor.
Claims 3 and 5 are rejected under 35 U.S.C. 103 as being unpatentable over Courage et al (U. S. Patent Application Publication No. 20150121462 A1), herein referred to as Courage, in view of Girish et al (U. S. Patent Application Publication No. 20190020478 A1), herein referred to as Girish, in view of Powell et al (U. S. Patent Application Publication No. 20150127547 A1), herein referred to as Powell, and in further view of Latimer et al (U. S. Patent Application Publication No. 20200322151 A1), herein referred to as Latimer.
Regarding claim 3, Courage, Girish, and Powell disclose the limitations of claim 1. Courage, Girish, and Powell do not specifically disclose, however, Latimer discloses the computer-implemented method in accordance with claim 1, further comprising, upon receipt of the access approval message from the cardholder computing device, generating, at the third party provider computing device (Figure 1, items 108, 112; para 100, “… The remote server 108 can provide an application feature/service 112 to the application program 106 on the client device 104. Such an application feature/service 112 may be called a remote application feature because it is stored remotely from the client device 104 …”), the request message to request creation of the authentication session, the request message comprising a JSON web token (JWT) including one or more of the following: a set of predefined claims, a Client ID, a creation time, a validity period, a customer redirect URL, and application specific data (Figure 1, items 106, 108, 112, 122; para 114, “… The signed security token 122 has a finite lifetime (e.g. 20 minutes, a typical average time for a user session following user log-in) within which the application program 106 can access the requested application feature 112 using the signed security token 122. The signed security token 122 may be a JavaScript Object Notation Web Token (JSON web token or JWT) in some examples. The signed security token is used by the application program 106 to make authenticated ( e.g. web) requests for application features 112, such as UI content and/or API calls, from the remote server 108 …”).
Latimer discloses an apparatus and methods for secure access to remote content. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an apparatus and methods for secure access to remote content, as in Latimer; to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide an improved system and method for allowing a user to access remotely stored software features and services in a secure way, which the user finds less burdensome than manually and repeatedly entering user authorization credentials.
Regarding claim 5, Courage, Girish, and Powell disclose the limitations of claim 1.
Courage further discloses the computer-implemented method in accordance with claim 1, further comprising: transmitting, by the authentication provider computing device (FIG. 1, items 152, 180, 182, para 36-37), a consent request message to the consent provider computing device (FIG. 1, items 120, 170, para 40), the consent message requesting creation a consent session (para 30, “… A user consent dialog (or dialogs) may be employed to receive or process user input for user authentication and for user approval or grant of access scopes requested by a packaged app …”; para 31, “… the identity API may be configured to serve the user consent dialog as URL content or a web page ("web page") embedded in a system-generated window on the computing device even as the packaged app runs outside a web browser on the user's computing device. The embedded web page may be a process that is exclusively controlled by the identity provider/identity API …”) …
receiving, at the authentication provider computing device (FIG. 1, items 152, 180, 182, para 36-37), a user consent session token (FIG. 2, items 120, 170, para 41, “… a structure of an example runtime 120, which includes Identity API 170 that is configured to display web-based user consent dialogs for granting a packaged app access to user data or service accounts on network servers …”; FIG. 5, item 500, para 55, “Method 500 may include receiving an application's request for access to a user's cloud- or network-based account (510). The application may be a packaged natively-operating application installed on the user's computing device. Receiving the application's request may involve providing an identity application programming interface (API) to receive and process the application's request …”); and
connecting the cardholder computing device (FIG. 1, item 102, para 35) to the consent provider computing device using a redirect with the user consent session token (para 31, “… the identity API may be configured to serve the user consent dialog as URL content or a web page ("web page") embedded in a system-generated window on the computing device even as the packaged app runs outside a web browser on the user's computing device. The embedded web page may be a process that is exclusively controlled by the identity provider/identity API …”; para 39, “… a client-side Identity API (e.g., Identity API 170) may be configured to interact with Identity provider API 180 on server 150 and serve web-based user consent dialogs (e.g., web-based consent UI 300, FIG. 3) on computing device 102 on which the packaged app (e.g., packaged application 130) operates outside of a web browser …”).
Courage, Girish, and Powell do not specifically disclose, however, Latimer discloses … with a JSON web token (JWT) (FIG. 4, item 420; para 139, “…in FIG. 4 as "Step 7. Get JWT session token (signed by API key)" 420, wherein the request for access is a request for an authorization token, here a JSON Web Token (JWT), to use to access the application feature from the remote application 408 …”); …
Latimer discloses an apparatus and methods for secure access to remote content. It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to include an apparatus and methods for secure access to remote content, as in Latimer; to include a network token system, as in Powell; and to include token provisioning utilizing a secure authentication system, as in Girish, to improve and/or enhance the technology of identity application programming interface, as in Courage, because it would amount to combining elements that in the combination would perform the same function as they functioned separately. One of ordinary skill in the art before the effective filing date of the invention would have been motivated to combine the references to provide an improved system and method for allowing a user to access remotely stored software features and services in a secure way, which the user finds less burdensome than manually and repeatedly entering user authorization credentials.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Srinivasan et al (U. S. Patent No. 8935757 B2) – OAuth Framework
Srinivasan discloses a framework, which conforms to the OAuth standard, involves a generic OAuth authorization server that can be used by multiple resource servers in order to ensure that access to resources stored on those resource servers is limited to access to which the resource owner consents. Each resource server registers, with the OAuth authorization server, metadata for that resource server, indicating scopes that are recognized by the resource server. The OAuth authorization server refers to this metadata when requesting consent from a resource owner on behalf of a client application, so that the consent will be of an appropriate scope. The OAuth authorization server refers to this metadata when constructing an access token to provide to the client application for use in accessing the resources on the resource server. The OAuth authorization server uses this metadata to map issued access tokens to the scopes to which those access tokens grant access.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to STEVEN CHISM whose telephone number is (571) 272-5915. The examiner can normally be reached during 9:00 AM – 3:00 PM Monday – Thursday, EST.
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, Ryan D. Donlon can be reached (571) 270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/STEVEN CHISM/
Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692