DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
• This action is in reply to the preliminary amendments filed on February 3, 2025.
• Claims 10 has been amended and are hereby entered.
• Claims 21-34 have been added.
• Claims 1-9 and 13-20 have been canceled.
• Claims 10-12 and 21-34 are currently pending and have been examined.
• This action is made Non-FINAL.
• The Examiner would like to note that this application is now being handled by Examiner Raven Yono.
Information Disclosure Statement
The information disclosure Statement(s) filed on 02/03/2025, 06/23/2025, and 09/24/2025 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
Examiner Note
The Examiner notes that claim 23-24, 29-30, and 32-33 of the instant application recite similar limitations found in the allowed claims of the parent application, App. No. 17/276,995. However, the claims of the instant application are not eligible under 35 USC § 101. The Examiner notes that the claims of the parent application and the claims of the instant application are different in scope. For example, the claims of parent application recite the active step of a generating step, the generating step including (a) concatenating the looked up payment token with at least one item of numeric transaction data to form a first numeric string; (b) signing the first numeric string to form a second numeric string; (c) selecting three leading digits of the second numeric string to be the dynamic token verification code; and (d) forming the dynamic expiry data by transforming four digits of the second numeric string, said four digits immediately following said three leading digits of the second numeric string. Whereas, dependent claims 23-24 and 32-33 of the instant application recite a generation step that has already occurred, and therefore occurs outside of the claim scope. Similarly, claims 29-30 of the instant application recite a verification step that has already occurred, and therefore occurs outside of the claim scope.
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 10-12 and 21-34 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 10 and 31 are directed to a method (claim 10) and an apparatus (claim 31). Therefore, on its face, each independent claim 10 and 31 are directed to a statutory category of invention under Step 1 of the Patent Subject Matter Eligibility analysis (see MPEP 2106.03).
Under Step 2A, Prong One of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), claims 10 and 31 recite, in part, a system, a method, and an apparatus of organizing human activity. Claim 10 recites a method comprising: operating to initiate a transaction with an entity; determining the entity supports a dynamic-data payment method; interacting to confirm support of the dynamic-data payment method; sending a request for payment credentials for the transaction; receiving the requested payment credentials, the received payment credentials including a payment token, dynamic expiry data and a dynamic token verification code; and transmitting the received payment credentials to the entity for use with the dynamic-data payment method; wherein the payment token, the dynamic expiry data and the dynamic token verification code collectively uniquely correspond to the transaction.
Claim 31 recites similar limitations as claim 10 above, and further recites receiving a user input to initiate a transaction.
The limitations, as drafted, is a process that, under its broadest reasonable interpretation, covers fundamental economic principles or practices and commercial and legal interactions (certain methods of organizing human activity), but for the recitation of generic computer components. The claims as a whole recite a method of organizing human activity. The claimed inventions allows for requesting payment credentials including a payment token, dynamic expiry data, and a dynamic token verification code to use for a payment method for a transaction, which is a fundamental economic principle or practice of mitigating risk and a commercial and legal interaction including sales activities or behaviors. The mere nominal recitation of a customer device and e-commerce server computer do not take the claim out of the methods of organizing human activity grouping. Thus, the claims recite an abstract idea.
Under Step 2A, Prong Two of the Patent Subject Matter Eligibility analysis (see MPEP 2106.04), the judicial exception is not integrated into a practical application. In particular, the additional elements of a customer device; online transaction; an e-commerce server computer; a browser interface; a payment application of the customer device are recited at a high-level of generality (i.e., as a generic computer performing generic computer functions of requesting payment credentials, receiving payment credentials to be used in a transaction) such that it amounts to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (e.g., a computer network).-see MPEP 2106.05(h).
Accordingly, the combination of the additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea.
Under Step 2B of the Patent Subject Matter Eligibility analysis (see MPEP 2106.05), the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements in the claims amount to no more than generally linking the use of the judicial exception to a particular technological environment or field of use (see MPEP 2106.05(h)). Generally linking the use of the judicial exception to a particular technological environment or field of use using generic computer components cannot provide an inventive concept.
The claims are not patent eligible.
The dependent claims have been given the full two part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. Dependent claims 11 and 32-34 simply further describes the technological environment. Dependent claims 12 and 21-30 simply help to define the abstract idea. The additional limitations of the dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea.
Viewing the claim limitations as an ordered combination does not add anything further than looking at the claim limitations individually. When viewed either individually, or as an ordered combination, the additional limitations do not amount to a claim as a whole that is significantly more than the abstract idea. Accordingly, claims 10-12 and 21-34 are ineligible.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 10-12, 21-22, 25-28, 31, and 34 are rejected under 35 U.S.C. 103 as being unpatentable over US 20180181956 A1 (“Zarakas”) in view of US 20150032627 A1 (“Dill”).
Regarding claim 10, Zarakas discloses a method comprising (see at least FIG. 5):
operating a customer device to initiate an online transaction with an e-commerce server computer over a browser interface (a customer completing an online shopping transaction may log in to a browser extension associated with an electronic checkout page. A browser extension may include a plug-in that may extend the functionality of the web browser of the merchant online shopping website, which may be utilized to facilitate a secure checkout. See at least [0090] and FIG. 5, step 504.);
determining that the e-commerce server computer supports a dynamic-data payment method (The customer's dynamic transaction card may receive via a short range wireless network, which may be a Bluetooth or Bluetooth Low Energy (BLE) network, a connection attempt from a user application associated with the user device utilized for online shopping to pair the dynamic transaction card with the user device. The user application may identify checkout fields on the online shopping site. For example, a web crawler may be utilized to search for checkout fields, which may be obtained from online shopping web pages, and may be accessed by the web crawler and APIs. The web crawler process may automatically browse a web page, and may identify and index fields on the merchant sites. In an embodiment, a web crawler may be embodied in a script that may parse HTML code of the sites to look for certain checkout field attributes associated with merchant sites. If checkout fields are identified, the user application may display a window via a user interface on the user device, which may request the customer to wake up the associated dynamic transaction card to complete payment information. See at least [0091]-[0092] and FIG. 5, steps 506, 508, and 512.);
interacting with a payment application of the customer device to confirm that the payment application supports the dynamic-data payment method (If checkout fields are identified, the user application may display a window via a user interface on the user device, which may request the customer to wake up the associated dynamic transaction card to complete payment information. Upon activation of the dynamic transaction card to wake up the card, a wireless connection, which may include a Bluetooth, BLE, or NFC connection may be established between the dynamic transaction card and the user device. See at least [0092] and FIG. 5, steps 506, 508, and 512.);
sending a request for payment credentials for the transaction; receiving the requested payment credentials (Upon authentication of a customer based on the evaluation of the connection between the dynamic transaction card and the user device, log in credentials of the user for logging in to the browser extension associated with the checkout page, and user information stored in the digital security delivery storage, the dynamic transaction card application may trigger the user device application to call an account provider system, via and API coupled to a communication interface that communicates with the dynamic transaction card and user device via a network. In response, the account provider system may send a push notification to the browser extension. The account provider system may transmit the customer account information to the customer application, via a short range wireless communication network, which may be a Bluetooth or BLE network, which may prompt the browser extension to populate the fields on the electronic checkout page using the user account information retrieved and transmitted by the account provider system through the customer application. See at least [0097] and FIG. 5, step 514, 518, 520, and 522.),
the received payment credentials including a payment token, dynamic expiry data (An application processor on the dynamic transaction card may also be utilized to generate a unique key, which may include a token, which may be utilized to securely store customer account information, which in turn may be utilized to authenticate the customer. As such, sensitive customer account information does not need to be entered to facilitate the funds transfer and may be obtained through the wireless connection. The unique key may be associated with the browser extension and may include a single-use transaction key. See at least [0096]. Customer account information may be encrypted to facilitate a secure transfer of the information. The transmitted information may include a key or token of encrypted information representing a financial account, the amount of the transaction and/or other information necessary to facilitate the transfer of funds. The backend account provider system may verify the customer account information, as it may use the customer account information to look up the account of the customer and determine whether the transaction should be authorized. The account provider system may check the account information against certain parameters to determine, for example, whether the transfer complies with certain parameters, and/or whether the associated token has expired. See at least [0099].); and
transmitting the received payment credentials to the e-commerce server computer for use with the dynamic-data payment method (The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. See at least [0097].);
wherein the payment token, the dynamic expiry data collectively uniquely correspond to the transaction (The transmitted information may include a key or token of encrypted information representing a financial account, the amount of the transaction and/or other information necessary to facilitate the transfer of funds. The backend account provider system may verify the customer account information, as it may use the customer account information to look up the account of the customer and determine whether the transaction should be authorized. The account provider system may check the account information against certain parameters to determine, for example, whether the transfer complies with certain parameters, and/or whether the associated token has expired. See at least [0099]. An application processor on the dynamic transaction card may be utilized to generate a unique key, which may include a token which may be utilized to securely store customer account information, which in turn may be utilized to authenticate the customer. As such, sensitive customer account information does not need to be entered to facilitate the funds transfer and may be obtained through the wireless connection. The unique key may be associated with the browser extension and may include a single-use transaction key. See at least [0104].).
While Zarakas describes a dynamic token verification code (see Zarakas at [0068]), Zarakas does not expressly disclose that the received payment credentials includes a dynamic token verification code. Furthermore, while Zarakas discloses the payment token and dynamic expiry data collectively uniquely correspond to the transaction, Zarakas does not expressly disclose the dynamic token verification code also collectively uniquely correspond to the transaction.
However, Dill discloses the received payment credentials includes a dynamic token verification code (Receiving a dynamic payment token including a token number, token expiration date, see at least [0145]. Dynamic token includes a dynamic card verification field, see at least [0201]-[0202].);
the dynamic token verification code also collectively uniquely correspond to the transaction (Dynamic tokens can be generated and delivered on a per-transaction or on an as needed basis to the end user to initiate a payment transaction through a registered and authenticated device and/or channel. For example, a one-time use dynamic token can be used at electronic-commerce (e-commerce) websites and if the dynamic token is intercepted by a third party, the dynamic token may be useless because it has been used and is thus worthless for future transactions. See at least [0058]. Receiving a dynamic payment token including a token number, token expiration date, see at least [0145]. Dynamic token includes a dynamic card verification field, see at least [0201]-[0202]. See also [0210]-[0211], describing the dynamic card verification field may be generated based on transaction specific data.).
From the teaching of Dill, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the received payment credentials of Zarakas to include a dynamic token verification code, as taught by Dill, and to modify the data that uniquely corresponds to the transaction of Zarakas to include the dynamic token verification code, as taught by Dill, in order to improve transaction security and increase service transparency and reduce merchant/issuer costs and reducing need for merchant to be PCI-DSS compliant (see Dill at least at [0029]), and in order to improve protection against misuse of payment accounts (see Dill at least at [0047]), and to improve approval levels for consumers and issuers (see Dill at least at [0048]), and to help card issuers and merchants improve card security and enable new payment experiences (see Dill at least at [0291]).
Regarding claim 11, the combination of Zarakas and Dill disclose the limitations of claim 10, as discussed above, and Zarakas further discloses submitting the received payment credentials to a merchant associated with the transaction (The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. See at least [0097].).
Regarding claim 12, the combination of Zarakas and Dill disclose the limitations of claim 10, as discussed above, and Zarakas further discloses the sending, receiving and submitting steps are performed by a mobile device (User device may be a smartphone, see at least [0025].).
Regarding claim 21, the combination of Zarakas and Dill disclose the limitations of claim 10, as discussed above, and Zarakas further discloses the payment token is a payment token associated with an account from which payment for the online transaction is to be made (An application processor on the dynamic transaction card may also be utilized to generate a unique key, which may include a token, which may be utilized to securely store customer account information, which in turn may be utilized to authenticate the customer. See at least [0096]. See also [0104].).
Regarding claim 22, the combination of Zarakas and Dill disclose the limitations of claim 21, as discussed above, and Zarakas further discloses the account is one of a deposit account and a credit account (A dynamic transaction card may be any type of transaction card that includes a microcontroller-enabled card used in any type of transaction, including, for example, debit cards, credit cards, pre-paid cards… see at least [0019]. Account provider may include banks/depository institutions, see at least [0034].).
Regarding claim 25, the combination of Zarakas and Dill disclose the limitations of claim 10, as discussed above, and Zarakas further discloses transmitting the received payment credentials to the e-commerce server computer for use with the dynamic-data payment method includes: passing the payment credentials from the customer device to a browser pointed to the e- commerce server (Upon authentication of a customer based on the evaluation of the connection between the dynamic transaction card and the user device, log in credentials of the user for logging in to the browser extension associated with the checkout page, and user information stored in the digital security delivery storage, the dynamic transaction card application may trigger the user device application to call an account provider system, via and API coupled to a communication interface that communicates with the dynamic transaction card and user device via a network. In response, the account provider system may send a push notification to the browser extension. The account provider system may transmit the customer account information to the customer application, via a short range wireless communication network, which may be a Bluetooth or BLE network, which may prompt the browser extension to populate the fields on the electronic checkout page using the user account information retrieved and transmitted by the account provider system through the customer application. See at least [0097] and FIG. 5, step 514, 518, 520, and 522. The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. See at least [0097].).
Regarding claim 26, the combination of Zarakas and Dill disclose the limitations of claim 10, as discussed above, and Zarakas further disclose completing the online transaction using the payment credentials (The account provider system may transmit the customer account information to the customer application, via a short range wireless communication network, which may be a Bluetooth or BLE network, which may prompt the browser extension to populate the fields on the electronic checkout page using the user account information retrieved and transmitted by the account provider system through the customer application. See at least [0097] and FIG. 5, step 514, 518, 520, and 522. The customer account information may be passed and queued on the backend merchant system to complete the checkout transaction. See at least [0097].).
Regarding claim 27, the combination of Zarakas and Dill disclose the limitations of claim 26, as discussed above. Zarakas does not expressly disclose completing the online transaction further comprises: transmitting, by the e-commerce server, an authorization request message containing the payment credentials.
However, Dill discloses completing the online transaction further comprises: transmitting, by the e-commerce server, an authorization request message containing the payment credentials (The merchant computer may generate an authorization request message including the token and send the authorization request message to the acquirer computer for the transaction initiated by the consumer. See at least [0232]. See also FIG. 8, step 816.).
From the teaching of Dill, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the completing of the online transaction to complete by transmitting by the e-commerce server an authorization request message containing the payment credential, as taught by Dill, in order to improve transaction security and increase service transparency and reduce merchant/issuer costs and reducing need for merchant to be PCI-DSS compliant (see Dill at least at [0029]), and in order to improve protection against misuse of payment accounts (see Dill at least at [0047]), and to improve approval levels for consumers and issuers (see Dill at least at [0048]), and to help card issuers and merchants improve card security and enable new payment experiences (see Dill at least at [0291]).
Regarding claim 28, the combination of Zarakas and Dill disclose the limitations of claim 27, as discussed above. Zarakas does not expressly disclose completing the online transaction further comprises: receiving, by the e-commerce server, an authorization response message authorizing the online transaction, the authorization response message received after the dynamic expiry data and the dynamic token verification code are verified.
However, Dill discloses completing the online transaction further comprises: receiving, by the e-commerce server, an authorization response message authorizing the online transaction, the authorization response message received after the dynamic expiry data and the dynamic token verification code are verified ( the token exchange and routing module 316 may validate if the token/PAN mapping is valid and/or if the transaction is allowed for the token based on the requested timestamp, transaction timestamp, token expiration date, token presentment mode, token requestor identifier, and any other relevant information. See at least [0237] and see also FIG. 8, step 822. Receiving an authorization response message. See at least [0244] and FIG. 8, step 830.).
Claim 31 has similar limitations found in claim 10 above, and therefore is rejected by the same art and rationale. And, Zarakas discloses a device comprising: a processor; and a memory in communication with the processor, the memory storing program instructions, the processor operative with the program instructions to perform functions as follows (See at least [0025]-[0029].):
receiving a user input to initiate an online transaction with an e-commerce server computer over a browser interface (a customer completing an online shopping transaction may log in to a browser extension associated with an electronic checkout page. A browser extension may include a plug-in that may extend the functionality of the web browser of the merchant online shopping website, which may be utilized to facilitate a secure checkout. See at least [0090] and FIG. 5, step 504.).
Claim 34 has similar limitations found in claim 25 above, and therefore is rejected by the same art and rationale.
No Prior Art Rejections
Based on the prior art search results, the prior art of record fails to anticipate or render obvious the claimed subject matter of claims 23-24, 29-30, 32-33. While some individual features of claims 23-24, 29-30, 32-33 may be shown in the prior art of record: no known reference, alone or in combination, would provide the invention of claims 23-24, 29-30, 32-33.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20160232525 A1 (“Cateland”) discloses a request may be received for a transaction. In response to the request, a nonce value may be generated. A cryptographic key may be used to cryptographically process a payment token with the nonce value to produce a security code. The payment token, the nonce value and the security code may be transmitted together as payment credentials. In some cases, the nonce value may be in the format for a payment account expiration date.
US 20170373852 A1 (“Cassin”) discloses systems and methods for validating transactions using a cryptogram. One embodiment of the invention is directed to a method of processing a remote transaction initiated by a communication device provisioned with a token.
US 20170255932 A1 (“Aabye”) discloses receiving a token from a plug-in application to conduct a transaction associated with a user of a communicating device. The process may include sending an authentication request to a remote access control sever to authenticate the user, and receiving, from the remote access control server, an authentication tracking value that the remote access control server used in generation of an authentication cryptogram.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights