Acknowledgements
This communication is in response to applicant’s response filed on 09/01/2026.
Claims 1, 10, 13, and 20 have been amended.
Claims 1-20 are pending and have been examined.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
Regarding applicant’s arguments:
Applicant’s argument, see pg. 11, filed 09/01/2026, with respect to the rejection(s) of claims 1-20 under Double Patenting rejection that the rejection be held in abeyance has been fully considered. The Double Patenting rejection is maintained.
Applicant’s arguments, see pgs. 12-18, filed 09/01/2026, with respect to the rejection(s) of claims 1-20 under Claim Rejections - 35 USC § 101 that the claim integrates the abstract idea into a practical application in a manner that imposes a meaningful limit on the judicial exception have been fully considered and are persuasive. The Claim Rejections - 35 USC § 101 has been withdrawn.
Applicant’s arguments, see pgs. 18-20, filed 09/01/2026, with respect to the rejection(s) of claims 1, 10, and 20 under Claim Rejections - 35 USC § 103 that the combination of Cook in view of Martin in further view of Khan does not teach all the limitations, specifically, “collect, from a merchant processor, transaction profile information associated with the transaction, wherein the transaction profile information includes at least one selected from the group of a transaction amount, a transaction type, and a merchant identity; analyze the transaction profile information; determine, based on the analysis of the transaction profile information, a security assessment of the transaction based on a risk of fraud, wherein the security assessment indicates a measure of security associated with the transaction” have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is in view of Novack (US 20150089585).
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 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 § 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-15 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over Cook (US 20230267449) in view of Novack (US 20150089585) in further view of Martin (US 20230186298) in further 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 an account processing system a user account query including the encrypted user datum (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); 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 collect, from a merchant processor, transaction profile information associated with the transaction, wherein the transaction profile information includes at least one selected from the group of a transaction amount, a transaction type, and a merchant identity; analyze the transaction profile information; determine, based on the analysis of the transaction profile information, a security assessment of the transaction based on a risk of fraud, wherein the security assessment indicates a measure of security associated with the transaction.
Novack from same or similar field of endeavor teaches collect, from a merchant processor, transaction profile information associated with the transaction, wherein the transaction profile information includes at least one selected from the group of a transaction amount, a transaction type, and a merchant identity (Paragraphs 0084-0085 teach a server computer receives an authentication request from a requestor; the authentication request can be received from a resource such as a website, an application, a computer, or the like; the authentication request received can include transaction information that identifies a transaction occurring at or in association with the requestor; the transaction information can include, for example, a transaction definition, a transaction type, location information, information describing or defining the transaction and/or parameters thereof (e.g., amounts involved parties or entities, locations of involved entities, types of connections and/or networks used in the transactions, transaction histories, combinations thereof, or the like)); analyze the transaction profile information (Paragraph 0087 and 0090-0091 teach the server computer determines a risk associated with the transaction identified by the authentication request; the authentication service can analyze the authentication request and the transaction identified by the authentication request, and analyze the authentication data to determine the risk associated with the transaction; the authentication data can include risk data that can identify transactions and/or types of transactions; the risk data also can identify risks associated with various transactions and/or types of transactions; the server computer determines an authentication score based upon the risk determined; the server computer can analyze the authentication data and the transaction type and/or risk determined to determine the authentication score to be enforced for the transaction; the authentication score can be based, at least in part, upon the risk data, the factor data, the score data, and an identification of the transaction or transaction type); and determine, based on the analysis of the transaction profile information, a security assessment of the transaction based on a risk of fraud, wherein the security assessment indicates a measure of security associated with the transaction (Paragraphs 0092 and 0094 teach the server computer can determine two or more groups of authentication factors based upon the determined score; the groups of authentication factors can include at least two groups of authentication factors that, if successfully answered or satisfied by a user, will provide nonrepudiation of the authentication; at least two groups of factors are generated, in some embodiments, to allow a user or other entity to select how the required authentication score will be satisfied while still imposing or enforcing the required level of security; the two or more groups of authentication factors can be include a variety of authentication factors, if desired, to ensure that the requestor has the opportunity to respond; for example, if one factor group requires a fingerprint, the other factor group may require a different authentication factor to ensure that a user or other entity does not have to provide a fingerprint to authenticate).
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 Novack to collect, from a merchant processor, transaction profile information associated with the transaction, wherein the transaction profile information includes at least one selected from the group of a transaction amount, a transaction type, and a merchant identity; analyze the transaction profile information; determine, based on the analysis of the transaction profile information, a security assessment of the transaction based on a risk of fraud, wherein the security assessment indicates a measure of security associated with the transaction.
There is motivation to combine Novack into Cook because embodiments of the concepts and technologies described herein can provide authentication techniques that satisfy security requirements while providing flexibility to users or other entities to allow the users or other entities to select a combination of authentication factors that satisfy a determined authentication score to be enforced against a transaction (Novack Paragraph 0031).
However, the combination of Cook and Novack does not explicitly teach 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; and 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.
Martin from same or similar field of endeavor teaches 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 0029 and 0067 teach an application server is configured to implement certain encryption and other operations to enable various embodiments described herein; such operations include generation of an encrypted shopper identifier credential (SIC), sending queries to issuing banks to determine whether the encrypted SIC is linked to an account at the issuing bank, and causing a checkout UI displayed on a user computing device to be modified with a selection field for each account determined to be inked to the encrypted SIC; a payment method linking application receives the unencrypted SIC; payment method linking application then generates the encrypted SIC; payment method linking application then sends a query that includes the encrypted SIC to one or more issuing bank servers; each query requests an indication from the receiving issuing bank whether the encrypted SIC is associated with an account for the receiving issuing bank); and 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 (Paragraphs 0068-0070 teach the shopper registration service receives the query and searches registered customer table for the encrypted SIC; when the encrypted SIC is not found in registered customer table, shopper registration service determines that there is no account associated with the online shopper at the issuing bank and an alternative checkout process must be used to complete the online transaction; alternatively, when the encrypted SIC is found in registered customer table, shopper registration service determines that there is an account associated with the online shopper at the issuing bank, and therefore the account is a linked payment method available to the online shopper; shopper registration service notifies payment method linking application that the encrypted SIC is linked to an account at that issuing bank, and therefore an account at that issuing bank is available to the online shopper as a payment method for the online transaction; the payment method linking application receives a response from each issuing bank at which an account is linked to the encrypted SIC).
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 Novack to incorporate the teachings of Martin to 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; and 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.
There is motivation to combine Martin into the combination of Cook and Novack because by entering the unencrypted shopper identifier credential into the checkout UI, suitable secure payment methods associated are made available to the online shopper without redirecting the online shopper to the website of an issuing bank or requiring the online shopper to enter credit card information into the merchant website (Martin Paragraph 0006).
However, the combination of Cook, Novack, and Martin does not explicitly teach 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; and generate a message comprising a plurality of details about the transaction.
Khan from same or similar field of endeavors teaches 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); 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 the combination of Cook, Novack, and Martin to incorporate the teachings of Khan to 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 the combination of Cook, Novack, and Martin 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 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, and Khan 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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, Novack, Martin, 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: 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/or activate the card; for example, the card issuer computing system may verify the information received based on the location of the customer device, a phone number of the customer device, type of customer device, and information received during the application process or information stored in the customer database; 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).
Regarding Claim 14, the combination of Cook, Novack, Martin, and Khan teaches all the limitations of claim 10 above; and Cook further teaches wherein the method further comprises transmitting, to the user device, a notification indicating that the transaction has been authorized (Paragraph 0104 teaches if the additional authentication information is sufficient, the card issuer computing system has authenticated the customer and proceeds to process).
Regarding Claim 15, the combination of Cook, Novack, Martin, and Khan teaches all the limitations of claim 10 above; and Cook further teaches further comprising 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 (Paragraph 0104 teaches if the additional authentication information, is not sufficient the card issuer computing system may cause the customer device (e.g., via sending a signal to the customer device) to re-prompt the user and re-enter process).
Regarding Claim 19, the combination of Cook, Novack, Martin, and Khan teaches all the limitations of claim 10 above; and Cook further teaches further comprising notifying the user device of potential security risks associated with the transaction before proceeding with authentication (Paragraph 0098 teaches where the card issuer computing system has determined a likelihood of a fraudulent attempt to access an account associated with the transaction card, the card issuer computing system may automatically generate and send an email or other electronic notification to an employee of the card issuer and/or to the user of the transaction account in order to notify them of the potential fraudulent activity).
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Cook (US 20230267449) in view of Novack (US 20150089585) in further view of Martin (US 20230186298) in further view of Khan (US 20210035086) in further view of Farivar (US 20210241280).
Regarding Claim 16, the combination of Cook, Novack, Martin, and Khan teaches all the limitations of claim 10 above; however, the combination does not explicitly teach further comprising 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.
Farivar from same or similar field of endeavor teaches further comprising 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 (Paragraph 0018 teaches a suspicious transaction can be identified based on a comparison to previous transactions of an owner of the card on the basis of location where the transaction occurred, time of day, amount, etc.; in some cases, the level of suspicion can be ranked. For example, a “high” level of suspicion or risk can be associated with a transaction more than three standard deviations from an average transaction amount for that card; a “medium” suspicion or risk can be associated with a transaction between one and three standard deviations from the average transaction amount; and a “low” suspicion or risk can be associated with a transaction less than one standard deviation from the average transaction amount. Similar rankings can be assigned based on time of day, location of the establishment, etc).
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, Novack, Martin, and Khan to incorporate the teachings of Farivar to determine 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.
There is motivation to combine Farivar into the combination of Cook, Novack, Martin, and Khan because it prevents fraudulent transactions.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Cook (US 20230267449) in view of Novack (US 20150089585) in further view of Martin (US 20230186298) in further view of Khan (US 20210035086) in further view of Mossoba (US 20210398114).
Regarding Claim 17, the combination of Cook, Novack, Martin, and Khan teaches all the limitations of claim 10 above; however, the combination does not explicitly teach wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information.
Mossoba from same or similar field of endeavor teaches wherein each account processing system is associated with a different account provider and has been provisioned with the user datum encryption information (Paragraph 0046 teaches the payment information assembly processor may be further configured to apply security measures to the payment account information data file; such security measures may be aimed at inhibiting or preventing unauthorized access to the payment information or account holder information stored in the data file and/or to prevent tampering with this information; the payment information assembly processor may be configured to encrypt some or all of the information stored in the data file using one or more keys available only to the financial institutions that have agreed to the data file format).
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, Novack, Martin, and Khan to incorporate the teachings of Mossoba for each account processing system to be associated with a different account provider and has been provisioned with the user datum encryption information.
There is motivation to combine Mossoba into the combination of Cook, Novack, Martin, and Khan because among other things, this would prevent access to the data file information by the account holder in embodiments where the data file is provided to the account holder. In some embodiments, the security measures could merely include measures for determining whether changes have been made to the data file. This could include, for example, including a check-sum or similar method that would allow the receiving financial institution an indicator that some or all of the data has been altered after creation of the data file by the transferring institution (Mossoba Paragraph 0046).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Siddens et al. (US 20180300729) teaches methods and systems for performing a secure authentication process by leveraging the historical transaction data associated with an issuer. The historical transaction data stored at a fraud detection system may include the types of frequency of past authentication processes performed by the issuer, allowing for a determination of the likelihood of an authentication challenge process being applied to a current transaction. A merchant may define merchant rules that define what authentication process, if any, should then be applied to the current transaction based on the likelihood of an authentication challenge process being applied to the current transaction.
Ansari et al. (US 20180276660) teaches systems and methods of providing secure remote transaction (SRT) transactions. In some embodiments, upon selection of a checkout element, a user may be identified with respect to a transaction to be completed. A number of accounts may then be identified in relation to that user. Upon selection of a particular account, the user may be authenticated using a facilitator application installed on a mobile computing device that supports authentication for the selected account. In some embodiments, the system may involve the use of a transaction-specific token generated upon receiving an authentication indicator from the facilitator application.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to COURTNEY JONES whose telephone number is (469)295-9137. The examiner can normally be reached on 7:30 am - 4:30 pm CST (M-Th).
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, Neha Patel can be reached at (571) 270-1492. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/COURTNEY P JONES/Primary Examiner, Art Unit 3699
