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
This is first office action on the merits in response to election filed on 10/17/2024.
Claims 1-20 are currently pending and have been examined.
Priority
Applicant’s claim for the benefit of a US Provisional Application No. 63/544,973 filed on 10/20/2013 is acknowledged.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 21-40 of copending Application No. 18/225,913 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications involve receiving and verifying an authentication credential after determining whether encrypted user datum matches one or more user profiles.
Claims 1-20 are provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claim 1-20 of copending Application No. 18/919,031 (reference application). Although the claims at issue are not identical, they are not patentably distinct from each other because both applications involve receiving, encrypting, and transmitting user datum to a plurality of account processing systems and receiving a confirmation from user identifying which account provider the user wants to use in the transaction.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Under Step 1 of the Section 101 analysis, claim 1 is directed to a system, claim 10 is directed to a method, and claim 20 is directed to a non-transitory computer readable medium (an apparatus, a process, and an article of manufacture).
Under Step 2A Prong One, Claims 1, 10, and 20 recite: receive, from a user device associated with an account holder associated with a bank, a transaction request; receive, from the user device, a user datum associated with the account holder; encrypt the user datum using user datum encryption information; transmit to each of a plurality of account processing systems a user account query including the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information; receive, by the software application from at least one of the plurality of account processing systems, a response comprising a notification that the account holder has a transaction account processed by that account processing system; transmit, by the software application to the user device, a confirmation request identifying the account providers associated with the at least one of the plurality of account processing systems; receive, by the software application from the user device, a confirmation response including identification of a selected account provider; collect, from a merchant processor, transaction profile information associated with the transaction; analyze the transaction profile information; determine, based on the analysis of the transaction profile information, a security assessment of the transaction, wherein the security assessment indicates a measure of security associated with the transaction; transmit to the user device upon determining that the transaction is insecure, an authentication request; receive, from the user device, a user authentication credential; generate a message comprising a plurality of details about the transaction; transmit the message to the selected account provider; and receive, from the selected account provider, a response comprising either an authorization of the transaction or a rejection of the transaction.
Claims 1, 10, and 20 as drafted include language (see underlined language above) that recite an abstract idea of a user selecting an account to perform a transaction that is performed after authenticating user identity, which falls under certain methods of organizing human activity (i.e., commercial interactions).
Under Step 2A Prong Two, the additional claim element(s), considered individually, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. The additional claim elements(s) “a system comprising: a software application” and “a non-transitory computer readable medium containing computer executable instructions,” generally “apply” the concept of a user selecting an account to perform a transaction that is performed after authenticating user identity. The claimed computer components are recited at a high level of generality and are merely invoked as tools to perform the abstract idea. Simply implementing the abstract idea on a generic computer is not a practical application of the abstract idea. Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea.
Under Step 2A Prong Two, the additional claim element(s), considered in combination, do not apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception and in a manner that integrates the exception into a practical application of the exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a system comprising: a software application and a non-transitory computer readable medium containing computer executable instructions amounts to no more than applying the abstract idea of a user selecting an account to perform a transaction that is performed after authenticating user identity. Mere instructions to apply an exception using a generic component cannot provide an inventive concept. The limitations “receive, from a user device associated with an account holder associated with a bank, a transaction request; receive, from the user device, a user datum associated with the account holder; encrypt the user datum using user datum encryption information; transmit to each of a plurality of account processing systems a user account query including the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information; receive, by the software application from at least one of the plurality of account processing systems, a response comprising a notification that the account holder has a transaction account processed by that account processing system” adds extra-solution activity to the judicial exception, and is not enough to incorporate the abstract idea into a practical application. The claim is not patent eligible.
Under Step 2B, the additional claim element(s), considered individually and in combination, do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself for similar reasons outlined under Step 2A Prong Two.
A similar analysis can be applied to dependent claim 2 which claim “wherein the user datum is one of the set consisting of a phone number, a name, and an email address” which merely elaborates on the extra-solution activity without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 3 which claims “wherein the at least one authentication credential includes multi-factor information associated with the user account” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 4 which claims “wherein the at least one authentication credential includes encrypted information received by the user device from a contactless card associated with the transaction account associated with the selected account provider” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 5 which claims “wherein the confirmation request includes an instruction to display a list of the account providers associated with the at least one of the plurality of account processing systems” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 6 and 11 which claims “wherein the message includes at least one selected from the group of an IP address, shipping address, and one or more credit card data” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claims 7 and 18 which claims “wherein the software application is further configured to receive a request from the account provider to request a second authentication credential from the user device” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 8 which claims “wherein the software application is further configured to receive a request from the account provider to decline the transaction” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 9 which claims “wherein the software application is further configured to generate a unique session identifier for the transaction and includes it in the message” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 12 which claims “wherein the message includes at least one selected from the group of a time datum, user device datum, and geolocation datum” which merely elaborates on the extra-solution activity without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 13 which claims “wherein the transaction profile information includes at least one of the following: transaction amount, transaction type, merchant identity, and geographic location” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 14 which claims “wherein the method further comprises transmitting, to the user device, a notification indicating that the transaction has been authorized” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 15 which claims “notifying the user device of the rejection of the transaction and providing a reason for the rejection when the response from the selected account provider indicates a rejection of the transaction” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 16 which claims “determining that the transaction is insecure if a geolocation datum associated with the transaction deviates from one or more historical geolocation datum associated with the account holder” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 17 which claims “wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information” which merely elaborate on the extra-solution activity without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
A similar analysis can be applied to dependent claim 19 which claims “notifying the user device of potential security risks associated with the transaction before proceeding with authentication” which merely elaborate on the abstract idea without reciting any new additional elements. When the limitations are considered individually and as a whole in combination with the independent claims from which they depend from, the claims do not recite additional elements that amount to significantly more than the judicial exception.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cook (US 20230267449) in view of Khan (US 20210035086).
Regarding Claims 1, 10, and 20, Cook teaches receive, from a user device associated with an account holder associated with a bank, a transaction request (Paragraph 0092 teaches a customer device receives the information from the transaction card; the customer device receives a URL from the transaction card that has the information that is indicative of an identity of a user associated with the transaction card stored within a query string; the customer device may be configured to automatically launch a browser (or to otherwise automatically navigate a browser) of the customer device to the URL; the customer device navigates to the URL received from the transaction card, the customer device may act as a conduit in transmitting the data stored within the query string (e.g., the information that is indicative of an identity of a user associated with the transaction card) directly to the card issuer computing system); receive, from the user device, a user datum associated with the account holder (Paragraphs 0087-0088 and 0091-0092 teach the transaction card is embedded with information that includes payment account information and information that is indicative of an identity of a user associated with the transaction card; the information embedded on the transaction card includes only the information that is indicative of an identity of a user associated with the transaction card; the transaction card is also embedded with an encryption algorithm that is configured to encrypt the cryptographic key or cryptographic token stored on transaction card; the contactless card transmits the information to the customer device via a NFC transmission; the customer device causes at least a portion of the tag (e.g., information that is indicative of an identity of a user associated with the transaction card) to be sent to the customer device; the customer device receives the encrypted information that is indicative of an identity of a user associated with the transaction card); encrypt the user datum using user datum encryption information (Paragraph 0088 teaches in one example of an encryption algorithm, the transaction card may be configured to receive a request from a device (e.g., a customer device having a near-field communications NFC reader) that includes a request for the cryptographic key or token and a seed (e.g., a bit sequence, random number, or word); the request may then cause the transaction card to perform an encryption of the cryptographic key using the seed, the cryptographic key or token (e.g., stored within the transaction card), and/or other information as inputs into the encryption algorithm and cause the transaction card to transmit the output of the encryption algorithm to the device (e.g., the customer device)); transmit to each of a plurality of account processing systems a user account query including the encrypted user datum, wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information (Paragraphs 0093 and 0097 teach the customer device transmits the information that is indicative of an identity of a user associated with the transaction card to the card issuer computing system; the customer device acts as a conduit and automatically forwards the information that is indicative of an identity of a user associated with the transaction card; for example, the customer device may include instructions stored thereon that are configured to cause the customer device to automatically forward the information that is indicative of an identity of a user associated with the transaction card in response to requesting and receiving the information from the transaction card (e.g., via processes 902-906); the card issuer computing system receives the information that is indicative of an identity of a user associated with the transaction card via a network connection to the customer device; the card issuer computing system may decrypt the received information that is indicative of an identity of a user associated with the transaction card; for example, the card issuer computing system may receive, as the information, an encrypted cryptographic key, seed information that was used to generate the cryptographic key, and/or a count number; the card issuer computing system may then use the encrypted cryptographic key, the seed information that was used to generate the encrypted cryptographic key, and/or the count number as inputs into a decryption algorithm in order to generate an output that is used by the card issuer computing system to cross-reference the output within a database on the card issuer computing system that includes multiple cryptographic keys, each corresponding to a different customer); analyze the transaction profile information (Paragraphs 0099-0100 teach the card issuer computing system identifies an identity of the customer associated with the transaction card based on the received information (e.g., and/or the output of the decryption algorithm); the card issuer computing system authenticates the customer); determine, based on the analysis of the transaction profile information, a security assessment of the transaction, wherein the security assessment indicates a measure of security associated with the transaction (Paragraph 0100 teaches if the customer cannot be authenticated based on the received information, the card issuer computing system may automatically generate an electronic notification and push or transmit the electronic notification to the customer device to prompt the user for additional authentication information at process; for example, if the customer profile associated with the customer of the transaction card requires, as a preference or rule of the customer, that additional authentication information is needed then the system may proceed to process); transmit to the user device upon determining that the transaction is insecure, an authentication request (Paragraph 0101 teaches the customer device prompts the user for additional authentication information; that is, the card issuer computing system has determined that additional authentication information is needed in order to allow the mobile device (e.g., the device that requested access) to have access to any or all of the account information associated with the transaction card; the additional authentication information may be unique to the customer; that is, the type of additional authentication information needed may have been prescribed by the user (e.g., the owner of the account and transaction card) to be a particular piece of additional authentication information; the type of additional authentication information may have a default preference where the user is prompted to provide a particular piece of additional authentication information); receive, from the user device, a user authentication credential (Paragraph 0102 teaches the customer device receives the authentication information; the user interfaces with the customer device and enters their additional authentication information; the customer device encrypts the additional authentication information in response to receiving the additional authentication information); transmit the message to the selected account provider (Paragraph 0103 teaches the customer device transmits the additional authentication information to the card issuer computing system, which may then use the additional authentication information to authenticate the user); and receive, from the selected account provider, a response comprising either an authorization of the transaction or a rejection of the transaction (Paragraphs 0104 and 0107 teach the additional authentication information may then be decrypted and used to authenticate the customer; the card issuer computing system provides an additional layer of security to ensure that only the users (e.g., via the customer device) that are authorized to access particular information of the account; if the additional authentication information is sufficient, the card issuer computing system has authenticated the customer and proceeds to allow the customer access to at least a portion of the online account associated within the transaction card; the card issuer computing system may allow the customer to transfer money into or out of the online account via the customer device; if the additional authentication information, is not sufficient the card issuer computing system may cause the customer device to re-prompt the user and re-enter process).
However, Cook does not explicitly teach receive, by the software application from at least one of the plurality of account processing systems, a response comprising a notification that the account holder has a transaction account processed by that account processing system; transmit, by the software application to the user device, a confirmation request identifying the account providers associated with the at least one of the plurality of account processing systems; receive, by the software application from the user device, a confirmation response including identification of a selected account provider; collect, from a merchant processor, transaction profile information associated with the transaction; and generate a message comprising a plurality of details about the transaction.
Khan from same or similar field of endeavors teaches receive, by the software application from at least one of the plurality of account processing systems, a response comprising a notification that the account holder has a transaction account processed by that account processing system (Paragraph 0160 teaches the MBE server uses the information received in message to get information associated with the user, such as a list of the user's payment accounts, which the MBE server provides to the mobile device); transmit, by the software application to the user device, a confirmation request identifying the account providers associated with the at least one of the plurality of account processing systems (Paragraph 0160 teaches the MBE server provides to the mobile device; the list of accounts (or a default account, if configured) and optionally other information, is then displayed to the user by the mobile device); receive, by the software application from the user device, a confirmation response including identification of a selected account provider (Paragraph 0161 teaches the user may choose to select an account, whether or not a default account is selected, in which case the user's selection is conveyed to the MBE server); collect, from a merchant processor, transaction profile information associated with the transaction (Paragraphs 0174 and 0183 teach the user indicates a desire to conclude the transaction, e.g., by clicking on a “Buy Now” button on the generated webpage, and in response, the mobile device sends to the MBE server a request to perform the transaction; the MBE server may optionally apply rules that govern the allowed behavior of the user's payment instruments, e.g., so as to verify that the requested transaction is allowed, for example; because the MBE server can maintain sensitive information related to electronic payments, for example, the MBE server is uniquely positioned to store and apply user-defined rules that control which users can and cannot engage in such transactions, which payment instruments they can or cannot use, and other restraints upon transactions including spending caps, and so on; the MBE server may then query a database to get entity-defined or user-defined preferences and rules that may determine whether the desired transaction will be allowed or not allowed, whether a notification or alert will be sent or not sent, or other specific behaviors and capabilities for specific transactions and/or accounts as defined by the user); and generate a message comprising a plurality of details about the transaction (Paragraph 0176 teaches the request can include information that may be used to identify a particular credit card, debit card, or other payment instrument, herein referred to as “a card pointer;” the card pointer may be a number that operates as an index, key, or pointer into a database or array, etc. Alternatively, the card pointer may be a descriptive string, such as “AmEx” or “Visa1” or “Dad's Credit Card”, or even a random string of characters; the use of a pointer with no inherent payment information to query the database provides an additional layer of protection against “man in the middle” attacks between a POS terminal/ecommerce website and the MBE server: an unauthorized viewer might see that the user wants to use a MasterCard credit card, but does not see any information from which the actual account information could be reconstructed; the database responds to this request by providing the transaction information; if the transaction is a payment, for example, the transaction information may include payment information. Non-payment transactions are also contemplated).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified Cook to incorporate the teachings of Khan to receive, by the software application from at least one of the plurality of account processing systems, a response comprising a notification that the account holder has a transaction account processed by that account processing system; transmit, by the software application to the user device, a confirmation request identifying the account providers associated with the at least one of the plurality of account processing systems; receive, by the software application from the user device, a confirmation response including identification of a selected account provider; collect, from a merchant processor, transaction profile information associated with the transaction; and generate a message comprising a plurality of details about the transaction.
There is motivation to combine Khan into Cook because of the system provides convenience by making possible a wide range of transactions that can be performed using mobile device without the overhead of a secure connection to and from mobile device (Khan Paragraph 0072 teaches).
Regarding Claim 1, Cook teaches a system for authenticating a user for a transaction, the system comprising: a software application configured to perform operations (Paragraphs 0025-0027 teach a customer device is owned by or otherwise associated with a customer/user; the customer device is structured to enable the user to access the network and also structured as a contactless reader structured to enable the reception of information wirelessly from the contactless card; the customer device may include program logic (e.g., instructions) stored by the memory and executable by the processor to implement at least some of the functions described herein; the processor may be configured to download and execute a software application of the customer device; for example, a developer may make or create the software application to be downloaded (e.g., via the developer's website, via an app store, or in another manner); responsive to a customer selection of an appropriate link, the software application can be transmitted to the customer device and cause itself to be installed on the customer device; installation of the software application creates a customer application that is executable by the processor; examples of downloadable applications include a mobile banking application, a mobile wallet application, and so on).
Regarding Claim 10, Cook teaches a method for authenticating a user for a transaction (Paragraph 0086 teaches referring now to FIG. 9 , a flow diagram 900 of a method of a communicating with a transaction card having key stored thereon to identify a customer is shown, according to an example embodiment).
Regarding Claim 20, Cook teaches a non-transitory computer readable medium containing computer executable instructions that, when executed by a computer hardware arrangement, cause the computer hardware arrangement to perform procedures (Paragraph 0006 teaches a non-transitory computer-readable medium storing instructions that, when executed by one or more processors cause operations including generate a customer-specific uniform resource locator (URL) for a contactless card for an customer, the customer-specific URL including a publicly accessible URL with an appended data field specific to the customer, issue the contactless card with the customer-specific URL embedded thereon to the customer, store, in a database, information regarding the customer and information regarding the contactless card, the information regarding the contactless card comprising the appended data field specific to the customer, based on a short range contactless communication between a mobile device of the customer and the contactless card, receive the appended data field specific to the customer, in response to receiving the appended data field specific to the customer, access, from the database, the information regarding the customer based on cross-referencing the appended data field specific to the customer to information stored in the database, based on matching the appended data field with information stored in the database, provide a graphical user interface (GUI) to the mobile device, the GUI including a prompt for authentication information, receive authentication information from the mobile device, verify the authentication information based on cross-referencing the received authentication information with the information regarding the customer retrieved from the database using the appended data field specific to the customer, and in response to verifying the authentication information from the customer device, activate the contactless card for a subsequent use).
Regarding Claim 2, the combination of Cook and Khan teaches all the limitations of claim 1 above; and Cook further teaches wherein the user datum is one of the set consisting of a phone number, a name, and an email address (Paragraphs 0048 and 0055 teach for example, the database may store information for customers with issued cards, including for example, personal customer information (e.g., names, addresses, phone numbers, and so on) and financial information (e.g., associated financial institutions, account numbers, available credit, credit history, and so on); the information contained in the customer database may be used by the card issuer computing system to perform a variety of checks surrounding a given contactless card, including for example, confirming identifying customer information, determining a customer's transaction history, determining a customer's available credit, and so on; the contactless communication between the contactless card and customer device causes the customer device to transmit data pre-loaded onto the card and information from the customer device to the card issuer computing system).
Regarding Claim 3, the combination of Cook and Khan teaches all the limitations of claim 1 above; and Cook further teaches wherein the at least one authentication credential includes multi-factor information associated with the user account (Paragraph 0101 teaches the additional authentication information includes biometric information (e.g., a thumb print on a thumb reader of the mobile device or facial recognition via a camera on the mobile device), a personal identification number (PIN), the last four of the social security number of the user associated with the account, security questions, code words or sentences, or a combination thereof).
Regarding Claim 4, the combination of Cook and Khan teaches all the limitations of claim 1 above; and Cook further teaches wherein the at least one authentication credential includes encrypted information received by the user device from a contactless card associated with the transaction account associated with the selected account provider (Paragraph 0102 teaches the customer device receives the authentication information; the user interfaces with the customer device and enters their additional authentication information; the customer device encrypts the additional authentication information in response to receiving the additional authentication information; for example, code on a mobile application or embedded within the website may take the additional authentication information and run it through an encryption algorithm that scrambles or obfuscates the additional authentication information automatically in response to receiving the additional authentication information or in response to receiving an input from the user (e.g., the selection of an “Enter” or other confirmation icon displayed along with the prompt for additional authentication information) that is intended to cause the customer device to transmit the additional authentication information).
Regarding Claim 5, the combination of Cook and Khan teaches all the limitations of claim 1 above; however, the combination does not explicitly teach wherein the confirmation request includes an instruction to display a list of the account providers associated with the at least one of the plurality of account processing systems.
Khan further teaches wherein the confirmation request includes an instruction to display a list of the account providers associated with the at least one of the plurality of account processing systems (Paragraph 0160 teaches the MBE server uses the information received in message to get information associated with the user, such as a list of the user's payment accounts, which the MBE server provides to the mobile device; the list of accounts (or a default account, if configured) and optionally other information, is then displayed to the user by the mobile device).
It would have been prima facie obvious to one of ordinary skill in the art before the effective filing data of the claimed invention to have modified the combination of Cook and Khan to incorporate the further teachings of Khan for the confirmation request to include an instruction to display a list of the account providers associated with the at least one of the plurality of account processing systems.
There is motivation to further combine Khan into the combination of Cook and Khan because dramatically boosts convenience, control, and clarity by allowing quick, secure transfers between your own accounts (checking, savings) or to others, enabling instant financial oversight (balances, spending), streamlining payments (bill pay, P2P), and offering real-time security alerts, making money management effortless and always accessible.
Regarding Claims 6 and 11, the combination of Cook and Khan teaches all the limitations of claims 1 and 10 above; and Cook further teaches wherein the message includes at least one selected from the group of an IP address, shipping address, and one or more credit card data (Paragraph 0105 teaches for example, the card issuer computing system may refuse to allow the customer device to have access to the account (e.g., not authenticate the customer) based on information received that identifies the customer device (e.g., internet protocol IP address, MAC identifier, or other electronic identifier)).
Regarding Claims 7 and 18, the combination of Cook and Khan teaches all the limitations of claims 1 and 10 above; and Cook further teaches wherein the software application is further configured to receive a request from the account provider to request a second authentication credential from the user device (Paragraph 0101 teaches the additional authentication information includes biometric information (e.g., a thumb print on a thumb reader of the mobile device or facial recognition via a camera on the mobile device), a personal identification number (PIN), the last four of the social security number of the user associated with the account, security questions, code words or sentences, or a combination thereof; for example, FIG. 11 depicts one example of a graphical user interface on a customer device that prompts the user for additional authentication information (e.g., a PIN number); in another example, FIG. 12 depicts one example of a graphical user interface on a customer device that prompts the user for additional authentication information (e.g., biometric data). Further discussion of each of these examples and figures are provided below).
Regarding Claim 8, the combination of Cook and Khan teaches all the limitations of claim 1 above; and Cook further teaches wherein the software application is further configured to receive a request from the account provider to decline the transaction (Paragraphs 0098 and 0105 teach for example, if new information is received that includes an encrypted cryptographic key and a seed (e.g., that should have been randomly generated) that are identical to a previously received encrypted cryptographic key and previously received seed, then the card issuer computing system may make the determination that there is likely a fraudulent actor or computing system that has intercepted the previously received cryptographic key and seed and is now trying to use them in a fraudulent manner; thus, in such example, the card issuer computing system may automatically disable the account associated with the transaction card, reject or deny access to the account, and/or flag the internet protocol (IP) address from which the new information (e.g., the suspected fraudulent information) was received from; in response to receiving and indication that the customer device is fraudulent, the card issuer computing system may, in response, deactivate the transaction card and add any electronic identification information of the customer device (e.g., IP address or identifying protocol information) to a list within the database that can be used to cross-reference future requests and automatically reject the request based on a determination that the request is coming from a fraudulent customer device).
Regarding Claim 9, the combination of Cook and Khan teaches all the limitations of claim 1 above; and Cook further teaches wherein the software application is further configured to generate a unique session identifier for the transaction and includes it in the message (Paragraphs 0095 and 0098 teach the transaction card may use the cryptographic key and seed information (e.g., and/or other information such as a count number) as inputs into an encryption algorithm (e.g., a cryptographic algorithm) and outputs a bit sequence that may represent the encrypted cryptographic key; the customer device may forward the received encrypted cryptographic key and seed information (and/or other information such as the count number of how many times the cryptographic key has been requested) to the card issuer computing system; the decryption algorithm may be used to detect fraud; for example, the card issuer computing system may cross reference the received information within a database that includes information previously received; the card issuer computing system may include a security process that automatically recognizes that the cryptographic key, the seed information that was used to generate the cryptographic key, and/or the count number was previously received and determine that the information was intercepted or hacked by a fraudulent actor).
Regarding Claim 12, the combination of Cook and Khan teaches all the limitations of claim 10 above; and Cook further teaches wherein the message includes at least one selected from the group of a time datum, user device datum, and geolocation datum (Paragraphs 0031, 0069, and 0105 teach it should be understood that the customer device may include other structures with associated functionality as well; for example, the customer device may include a global positioning system (GPS) structured to at least one of determine or receive data indicative of the location of the customer device; this “location data” may provide an indication of a location of the customer device; location data may be used as part of an authentication process for activation of the contactless card and/or password-less login; for example, the location of the device may be used in authenticating the customer: if the customer is in a predefined location or on a non-open network, then they may pass the first layer of authentication; the card issuer computing system may refuse to allow the customer device to have access to the account (e.g., not authenticate the customer) based on information received that identifies the customer device (e.g., internet protocol IP address, MAC identifier, or other electronic identifier)).
Regarding Claim 13, the combination of Cook and Khan teaches all the limitations of claim 10 above; and Cook further teaches wherein the transaction profile information includes at least one of the following: transaction amount, transaction type, merchant identity, and geographic location (Paragraph 0069 teaches for example, the customer device may have instructions (or receive instructions embedded on the contactless card) to send information (e.g., identifying information) from the contactless card (e.g., received as a result of the tap) and information about the customer device (e.g., identifying information such as phone number, MIS, or location) to the card issuer computing system; the card issuer computing system may then cross-reference or otherwise verify the information in order to automatically authenticate the customer and