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 .
This communication is a Final Office Action in response to Applicant’s response filed on December 12, 2025.
Claims 21-40 have been examined in this application. Claims 1-20 are cancelled.
No new information disclosure statement (IDS) has been filed.
Response to Arguments
Applicant’s arguments, filed on December 12, 2025, pages 11-12, regarding claim rejection under 35 U.S.C. 112(a) have been fully considered and are persuasive. The rejection is now withdrawn.
Applicant’s arguments, filed on December 12, 2025, pages 11-12, regarding claim rejections under 35 U.S.C. 101 have been fully considered but are not persuasive.
Applicant argues that the claims are not directed to an abstract idea and that said abstract idea does not fall under any of the abstract idea groupings. Applicant also argues that the receiving over a first network account data, storing the data in a storage unit, receiving using the first network a request to share account provisioning data, transmitting using the first network a user datum request, receiving the datum via first network, sending to user device the datum over a second network, confirm sharing of the data, receiving a confirmation of sharing the provisioning data, retrieve from the storage unit provisioning data, and sending via first network to the transaction processor at least one of the one or more account provisioning data are all additional elements that provide a “technical implementation to provision account information to a transaction data processing system in a meaningful way beyond mere instructions to apply the exception using generic computer components.” Id., 17-18. Applicant finally argues that the claims amount to significantly more, based on the argued additional elements, than the abstract idea if the claims amount to an abstract idea.
The Examiner respectfully disagrees. The claims amount to merely an abstract idea of sending or transmitting account provisioning data in response to manipulation of data without significantly more. The abstract idea does fall under certain methods of organizing human activity because they capture business relations, and sales activities. The relationship between user and entity provisioning the data is a clear relationship between entities linked to settlement of a transaction. Likewise, the provisioning of said data to settle a transaction clearly highlight a sales activity. Without the provisioned data, a transaction wouldn’t be settled. The additional elements, which Applicant considers as the entire claim as a whole, are not correct. Additional elements in the claims are the elements that are deemed technical, or include a device and its components. Sending and receiving data is not technical. The use of a first and second communication method is not technical or recited as amounting to a unique technical solution to a technical problem. They are merely a way to communication data without any additional meaningful elements. Even if said communications are considered, they are recited at a high level of generality failing to amount to a practical application. The argued claimed steps of sending, receiving, storing, authenticating, and transmitting data over networks amount to mere standard operations for networked payment systems. There is no technical solution to a technical problem being captured by the claimed scope as a whole. The provisioning of data is a clear business process and the claims use, at best, off-the-shelf computers/devices and network technology to implement the abstract idea.
In conclusion, the claims remain directed to the abstract idea of provisioning account information for a transaction, which falls within the “certain methods of organizing human activity” grouping of abstract ideas as outlined in MPEP § 2106.04(a). The abstract idea is not integrated into a practical application; receiving, storing, authenticating, and transmitting account data—are generic computer functions performed in a conventional manner. The claims do not recite a specific improvement to computer functionality or another technology. The claims do not include additional elements that amount to “significantly more” than the abstract idea itself. The technical features recited are generic and do not provide a specific technical solution or improvement. The arguments regarding secure push provisioning and EMV card use are not reflected in the claim language as a novel technical implementation. Each of the additional elements / limitations are no more than mere instructions to apply the exception using generic computer components or a generic device. Accordingly, even in combination, 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 Applicant’s arguments that the claims amount to significantly more are not persuasive. the claims fail to 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 amount to merely instructions to apply the exception using generic computer components. The claim limitations do not improve another technology or technical field, improve the functioning of a computer itself, apply the abstract idea with, or by use of, a particular machine (not a generic computer, not adding the words "apply it" or words equivalent to "apply the abstract idea", not mere instructions to implement an abstract idea on a computer, adding insignificant extra solution activity to the judicial exception, generally linking the user of the judicial exception to a particular technological environment or field of use), effects a transformation or reduction of a particular article to a different state or thing, or adds meaningful limitations that amount to more than generally linking the use of the abstract idea to a particular technological environment. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
The rejection is maintained.
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 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter.
Claims 21-40 fall within at least one of the four categories of patent eligible subject matter (process, machine, manufacture, or composition of matter).
Claims 21-40 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea of provisioning payment data to be used in a transaction without significantly more.
The abstract idea is categorized under certain methods of organizing human activity and mental processes. More specifically, the abstract idea falls under commercial interactions including sales activities or behaviors, business relations, concepts performed in a human mind such as judgement, evaluation, opinion, observation and performing theses concepts using pen and paper.
Claim 30, in pertinent part, recites:
A method for provisioning account information to a transaction processing system, the method comprising:
receiving… one or more account provisioning data associated with one or more account processing systems;
storing… the one or more account provisioning data in a data storage unit;
receiving… a request to share at least one of the one or more account provisioning data with the transaction processor;
transmitting… a user datum request;
receiving… a user datum;
determining… whether the user datum is associated with the one or more account provisioning data;
transmitting… a request to confirm sharing of at least one of the one or more account provisioning data;
receiving… a confirmation response for sharing at least one of the one or more account provisioning data;
retrieving… the at least one of the one or more account provisioning data; and
transmitting… the at least one of the one or more account provisioning data.
The judicial exception is not integrated into a practical application. The claims recite the following additional elements: an administrator processor, a transaction processor, non-transitory, and a computer readable medium comprising instructions, a first network, a second network. The additional elements are recited at a high level of generality, wherein the claims merely amount to an abstract idea that is implemented using generic computers, performing generic computer functions such as receiving data, sending data, storing data, analyzing the data, and determining an outcome. Each of the additional elements / limitations are no more than mere instructions to apply the exception using generic computer components or a generic device. Accordingly, even in combination, 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 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 amount to merely instructions to apply the exception using generic computer components. The claim limitations do not improve another technology or technical field, improve the functioning of a computer itself, apply the abstract idea with, or by use of, a particular machine (not a generic computer, not adding the words "apply it" or words equivalent to "apply the abstract idea", not mere instructions to implement an abstract idea on a computer, adding insignificant extra solution activity to the judicial exception, generally linking the user of the judicial exception to a particular technological environment or field of use), effects a transformation or reduction of a particular article to a different state or thing, or adds meaningful limitations that amount to more than generally linking the use of the abstract idea to a particular technological environment. Mere instructions to apply an exception using generic computer components cannot provide an inventive concept.
The dependent claims do not include additional elements that integrate the abstract idea into a practical application or that provide significantly more than the abstract idea. The dependent claims fail to recite additional elements that would amount to a practical application or amount to significantly more than the judicial exception as discussed above. The dependent claims further describe the abstract idea.
The claims are not patent eligible.
Prior Art
The prior art made of record, cited, and considered teaches the majority of the Applicant’s claimed scope. Receiving and storing user payment information or registering user payment information is well settled in the art. Furthermore, receiving a request for payment from an entity such as a merchant at a user device and providing the merchant with payment information as a result of the request is too well settled in the art; dating back decades. More importantly, prior art teaches that before sending the payment information to the merchant, a user can be presented with a plurality of payment options to select from before returning the selection/selected payment option to the merchant. The payment option selection can be based on rules set, dynamic rules, automated, or based on an overriding selection by the user.
On the other hand, a clear indication is not found in the art, wherein a device (1) first receives a request, from a requesting device, to share at least one of the one or more account provisioning data, and (2) requesting user datum information from the requestor device, (3) receiving the user datum by the device, (4) determines whether the user datum is associated with one or more account data, and (5) sending to a user device, different than the requestor device, a request to select the one or more account provisioning data, and finally sending the account data to the requestor device. Therefore, a clear and obvious combination of references to teach the at least claimed scope as a whole is not deemed obvious at this point in prosecution.
References that teach the majority of Applicant’s claimed scope include but are not limited to:
U.S. Patent Application Publication 2019/0034924 to Prabhu et al. teaches user may interact with a merchant to buy an item, which may be a good or service offered by a merchant via merchant application 1406. In FIG. 14A, at an action 1420, user device 1302 sends a request to pay with the user's account with the payment service provider to merchant application 1406. In an example, the user uses user device 1302 to select user selectable object 1308 displayed on page 1300 to send the request to pay with the user's account. In some examples, the user may interact with payment application 1402 while merchant application 1406 is active on user device 1302 because services of payment application 1402 may be accessible via merchant application 1406. The user's request to pay with her payment service provider account may be a request to use a funding instrument (e.g., VENMO® account) that is provided by the payment service provider to pay for the transaction. The funding instrument is a payment source for the transaction. For example, the payment service provider is VENMO®, and the funding instrument is the user's VENMO® wallet, which may include one or more payment methods (e.g., credit card, debit card, checking account, etc.). In this example, the payment service provider is a source of the funding instrument.
At an action 1422, merchant application 1406 receives the request to pay with the user's payment service provider account and switches the active application on user device 1302 to payment application 1402. An active application refers to the application that is currently displaying data on user device 1302. Merchant application 1406 may switch the active application on user device 1302 to payment application 1402 by redirecting the user device to the payment application. In an example, merchant application 1406 activates payment application 1402, which may be installed on user device 1302, to display data on user device 1302. In another example, merchant application 1406 triggers a browser executing on user device 1302 to point to a URL that references content provided by payment application 1402.
Payment application 1402 may perform actions to authenticate the user. At an action 1424, payment application 1402 sends a page including a login request to user device 1302 for authentication to the payment service provider. At an action 1426, user device 1302 sends the user's login information to payment application 1402. In the example illustrated in FIG. 14A, the user's login information includes the user's account number, which is specified as “Acct1,” and the customer's name, which is specified as “John Smith.” This is not intended to be limiting and the user login information may include additional or different information from that shown in FIG. 14A. In an example, the login information also includes the user's user credentials, which may be the user's username and password.
At an action 1428, payment application 1402 receives the user login information from user device 1302 and sends the user login information to payment server 1412. Once the user has authenticated herself to payment application 1402, payment application 1402 may identify the user and therefore may send an account number or identifier that can uniquely identify that user back to payment server 1412. In an example, payment application 1402 sends the user's account number or some derived identifier of the account number and a session ID to payment server 1412 to identify the user for future interactions. Payment server 1412 may be coupled to an account database 1432 that stores user account information. Account database 1432 may be maintained by the payment service provider and be used to authenticate users desiring to access services of the payment service provider. Account database 1432 includes a user account table 1434 having a Common ID, Customer Name, Funding Instrument Type, Payment Token, and Acct No columns. User account table 1434 includes an entry 1436, which specifies that a user having the customer name “John Smith” is associated with a credit card funding instrument type and a payment token “abcd.” In an example, the funding instrument is a credit card “V-1234” (e.g., a VISA® credit card having the last four digits “1234”), and a credit card company provided the user with this credit card for authorizing payment for goods or services on credit. Entry 1436 was pre-existing from a previous interaction where the same customer shared her credit card information as the funding instrument.
If payment server 1412 finds the provided login information in account database 1432, process flow may proceed from action 1438 to an action 1440 in FIG. 14B, in which payment server 1412 successfully authenticates the user and authorizes the user login. If payment server 1412 authenticates the user, the payment service provider knows the identity of the user and also that the user is attempting to complete a payment transaction with a merchant. After payment server 1412 authorizes the user login, process flow may proceed from action 1440 to an action 1442, in which payment server 1412 sends a request for a common identifier (ID) to token service provider 1410. The request for the common ID also includes the account number provided in the user login information (and belonging to the user “John Smith”). Payment server 1412 may request a common ID from token service provider 1410 if the user desires to pay a merchant using an account she has with the payment service provider (see action 1420 in FIG. 14A).
At an action 1444, token service provider 1410 receives the common ID request including the account number “Acct1” from payment server 1412, and generates a common ID “CID1” that corresponds to the user's “Acct1.” A common ID may vary from context to context. For example, in the context in FIGS. 14A-14C, the user's identity on her account with the payment service provider is bound to the partner requesting the common ID. For example, payment server 1412 may request a common ID for an authenticated user, and would be provided with common ID “CID1.” At a later point in time, if another partner offers the user the ability to pay with the payment service provider and this partner requests a common ID for the same user, token service provider 1406 may generate a common ID “CID2,” which is different from the common ID issued to the first partner. Merchant application 1402 may be unaware of the common ID. As will be explained further below, the user's account with the payment service provider (VENMO® account) will be bound to a common ID. In an example, this binding happens once between the user's identity on the payment service provider and the user's identity on token service provider 1406 (e.g., common ID “CID1”). In this example, for a single binding, a single common ID (e.g., “CID1”) may be common across any merchant that the payment service provider is made available on.
Payment server 1412 may recognize “Acct1,” which was included in the user login information in actions 1426 and 1428, as being the user's requested funding instrument in relation to the user's account with the payment service provider. Accordingly, payment server 1412 may include “Acct1” in the request for a common ID to token service provider 1410 so that token service provider 1410 provides both “Acct1” and the generated common ID back to payment server 1412. In this way, payment server 1412 may easily pair these two parameters together and know to associate the common ID “CID1” with “Acct1.”
At an action 1446, token service provider 1410 sends the common ID “CID1” and account number “Acct1,” which are both associated with John Smith's account, to payment server 1412. At an action 1450, payment server 1412 sends a request for a payment token to token requestor 1408. The payment token request also includes the common ID “CID1” and account number “Acct1” associated with John Smith's account. Action 1450 is associated with a dashed line to indicate a “notification” type event that is triggered by the common ID creation. At an action 1452, token requestor 1408 receives the payment token request including the common ID “CID1” and the account number “Acct1,” and generates a payment token “xyz.” A payment token may be an internal construct issued by token requestor 1404 to commerce partners of token requestor 1404 and/or the payment service provider. As will be explained further below in relation to FIGS. 16A-16D, the payment token “xyz” is a non-transactable token that may be used as a handle to John Smith's account corresponding to the funding instrument “Acct1.”
Token requestor 1408 maps the payment token “xyz” to the common ID “CID1” included in the payment token request by inserting them into the same entry. In response to receiving a payment token request from payment server 1412, token requestor 1408 may know that the payment token is being generated for a funding instrument type provided by the payment service provider. Additionally, token requestor 1408 may know that “Acct1” belongs to John Smith because token requestor 1408 is in a trusted relationship with the payment service provider. Although token requestor 1404 and the payment service provider are in a trusted relationship, it may be possible that token requestor 1404 knows nothing more about the user's identity other than the common ID associated with the user's payment service provider account, where “Acct1” is a unique account number. The common ID “CID1” may identify “Acct1” as the funding instrument to be charged for the user's payment transaction if the user desires to pay a merchant with her payment service provider account (e.g., VENMO® account or wallet).
U.S. Patent 10963883 to Haverlah teaches a system for performing transactions from vehicles, the system comprising: a vehicle recognition based transaction (VRT) system; a vehicle recognition scanner installed at a merchant location, the vehicle recognition scanner configured to: scan a vehicle of a user when the vehicle is proximate to the vehicle recognition scanner; and responsive to scanning the vehicle, obtain vehicle identifier (VID) that uniquely identifies the vehicle; and a merchant computing system communicably coupled with the vehicle recognition scanner and in communication with the VRT system, the merchant computing system configured to: obtain the VID from the vehicle recognition scanner; send, to the VRT system, a request for behavioral information and disbursement information from a user profile associated with the VID; and responsive to receiving the behavioral information, automatically causing a display device at the merchant location to present a suggested transaction for the user at the merchant location, the suggested transaction determined based on the behavioral information, and wherein the VRT system is configured to: responsive to receiving the request from the merchant computing system: identify the user profile from among a plurality of different user profiles using the VID, and obtain, from the user profile, 1) behavioral information that is associated with the user and relevant to a particular merchant associated with the merchant computing system 2) a suggested payment method for the user based on the behavioral information; send the suggested payment method to a computing device associated with the user for presentation to the user; receive, from the computing device, a user selection of a particular payment method; and responsive to receiving the user selection of the particular payment method, send, to the merchant computing system, the behavioral information and the disbursement information, wherein the disbursement information is based on the particular payment method selected by the user, and wherein the merchant computing system is further configured to automatically execute a payment, in response to receiving the disbursement information and based on the disbursement in formation, without need for the user to provide payment to an employee of the merchant.
U.S. Patent Application Publication 2020/0082402 to Patel et al. teaches use of a token selection to settle a transaction. Figure 8 and related text recite further detail on the operation of a user selection of a payment and issue of payment account method and settlement of a transaction using the account method with a merchant. Paragraphs 0126-0139.
Canadian Patent Application 2961515 to Tomasofsky et al. teaches ser authentication and/or payment authorization of a payment-by-card merchant, transaction data associated with a payment card transaction, the payment card transaction including a suspect consumer presenting a payment card from a a privileged cardholder; (ii) computing a risk score for the payment card with the payment card transaction; (iii) transmitting an indication of acceptable risk to the merchant if the user authentication and/or payment authorization of a payment-by-card purchase, a merchant name, a type of merchant, purchase information, cardholder account associated with a transaction and transmitted between parties to the perform a transaction which undergoes a user authentication process. provide a user authentication mechanism for authenticating cardholder 602 and, times the user has authenticated into the subject digital wallet. For example, RBD module 750 would not recommend additional user authentication based only 750 would recommend additional user authentication based only on the recommendation for additional user authentication in risk result 752. In recommendation for additional user authentication is provided in risk result and may provide data associated with digital wallet 600 (e.g., a selection of payment cards present available to suspect consumer 702 through digital wallet 600). via the merchant's web site) displays data associated with digital wallet 600 consumer 702 (e.g., confirming login to wallet, and/or payment card selection to wallet provider 1002 who, at step 1035, transmits transaction information (e.g., payment merchant).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed on for PTO-892.
THIS ACTION IS MADE FINAL. 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 EL MEHDI OUSSIR whose telephone number is (571)270-0191. The examiner can normally be reached M-F 9AM - 5PM.
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 on 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 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.
Sincerely,
/EL MEHDI OUSSIR/Primary Examiner, Art Unit 3699