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 reply filed on 11/17/2025.
Claims 1-20 are currently pending and have been examined.
Response to Arguments
Applicant’s arguments, filed 11/17/2025, with respect to the restriction requirement have been fully considered and are persuasive. The restriction requirement of claims 1-20 has been withdrawn.
Claim Objections
Claim 8 is objected to because of the following informalities: The claim recites “form a memory” instead of “from a memory” in line 3. Appropriate correction is required.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more.
In the instant case, claims 1, 17 and 20 are directed to a method, system, and method. For the purposes of this analysis, representative claim 1 is addressed.
Claim 1 recites “presenting prospective transaction failure” which is a grouped under “Certain methods of organizing human activity — fundamental economic practices” in prong one of step 2A (MPEP 2106.04(a)). Abstract ideas are in bold below. Claim 1 recites:
A method in an electronic device, the method comprising:
detecting, with one or more processors of the electronic device, a prospective financial transaction using a digital wallet application operable on the one or more processors of the electronic device;
identifying, with the one or more processors from data retrieved with a communication device of the electronic device, one or more probable digital wallet application payment failure modes due to one or more merchant or payment processor system malfunctions; and
in response to identifying at least one probable digital wallet application payment failure mode due to the one or more merchant or payment processor system malfunctions, presenting, by the one or more processors on a user interface of the electronic device, a potential payment failure mode notification identifying the one or more probable digital wallet application payment failure modes.
The additional elements of claim 1 such as “with one or more processors of the electronic device,… digital… operable on the one or more processors of the electronic device”, “with a communication device of the electronic device,”, “ by the one or more processors on a user interface of the electronic device”, represent the use of a computer as a tool to perform an abstract idea and/or does no more than generally link the abstract idea to a particular field of use.
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 into a practical application, the additional elements amount to no more than [mere instructions to apply the abstract idea of using generic computer components. The claim elements when considered separately and in an ordered combination, do not add significantly more than implementing the abstract idea of fundamental economic practice.
Hence, claims 1, 17 and 20 are not patent eligible.
Dependent claims 2-16, and 18-19 recited additional details which only further narrow the abstract idea and do not add any additional features, alone or in combination, that would provide a practical application or provide significantly more.
The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not affect an improvement to another technology or technical field, the claims do not amount to an improvement to the functioning of a computer system itself, and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 10-14, and 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hubli (US 2019/0057384 A1).
Regarding Claims 1, 17 and 20
A method in an electronic device, the method comprising: detecting, with one or more processors of the electronic device, a prospective financial transaction using a digital wallet application operable on the one or more processors of the electronic device; (See at least Hubli [0027] and [0029]:[0027] The payment server 16 receives an authorization request from the merchant system 14 through the network 26 to purchase products or book services. In one non-limiting embodiment, the authorization request may propose to book one or more travel-related services such as airline tickets, hotel reservations, or a car rental using at least two forms of payment. [0029] The payment server 16 also includes a delivery server 28. As explained in greater detail below, the delivery server 28 may be used to reverse or refund a successful transaction in some circumstances. In particular, two or more forms of payments may be used to pay for booking a specific service. The payment server 16 detects at least one successful transaction and a failure of at least one of the forms of payment, and the delivery server 28 seeks to reverse any successful transactions.
identifying, with the one or more processors from data retrieved with a communication device of the electronic device, one or more probable digital wallet application payment failure modes due to one or more merchant or payment processor system malfunctions; and (See at least Hubli [0030] The form of payment may fail for any number of reasons. For example, in one embodiment the transaction may fail because the payment server 16 was unable to connect to the corresponding payment provider system 18 due to poor connectivity of the network 26. Thus, the payment server 16 may detect failure of the transaction if a notification has not been received within a predetermined amount of time. In yet another embodiment, the transaction may fail because the form of payment has been denied. For example, a transaction may be denied if there are insufficient funds in a bank account if a debit card is used. Thus, the payment server 16 may detect failure of the transaction based on receiving a failure notification from a corresponding payment server 16. In another example, the transaction may be denied if the form of payment has expired. For example, a user may inadvertently use an expired credit card to pay for a booking. Accordingly, the delivery server 28 may detect failure of the transaction based on receiving a notification that the credit card has expired.
in response to identifying at least one probable digital wallet application payment failure mode due to the one or more merchant or payment processor system malfunctions, presenting, by the one or more processors on a user interface of the electronic device, a potential payment failure mode notification identifying the one or more probable digital wallet application payment failure modes. (See at least Hubli [0051] The rollback requests placed into the timeout exception queue require manual action. This means that the rollback requests in the timeout exception queue may not be handled by a user such as a travel agent. Instead, technical personnel may address the rollback requests. Specifically, as soon as a rollback request is introduced to the timeout exception queue, a notification may be displayed upon a monitoring interface, such as a graphical user interface (GUI) used by the technical personnel (not illustrated in the figures). Once the number of rollback requests exceeds a predetermined limit in the timeout exception queue, then a trigger or alarm may be raised to notify the technical personnel. In one example, the alarm may be raised as soon as there are five rollback requests in the timeout exception queue).
Regarding Claim 2
The method of claim 1, wherein the potential payment failure mode notification comprises at least one alternate payment mode suggestion. (See at least Hubli [0043] The payment server 16 may also generate a request to the payment provider system 18N to authorize the second credit card. The payment server 16 may then receive a second notification that the second credit card has been approved.
Regarding Claim 3
wherein the at least one alternate payment mode suggestion suggests a payment mode that omits using the digital wallet application. (See at least Hubli [0044] Accordingly, in response to receiving a notification that a transaction has failed, the payment server 16 may search the database 20 for business rules corresponding to the specific payment provider for the approved transactions. The payment server 16 then determines if a transaction corresponding to a particular form of payment may either be reversed or refunded based on the business rules stored in the rules database 20.
Regarding Claim 4
wherein the potential payment failure mode notification identifies the one or more merchant or payment processor system malfunctions. (See at least Hubli [0030] The form of payment may fail for any number of reasons. For example, in one embodiment the transaction may fail because the payment server 16 was unable to connect to the corresponding payment provider system 18 due to poor connectivity of the network 26. Thus, the payment server 16 may detect failure of the transaction if a notification has not been received within a predetermined amount of time. In yet another embodiment, the transaction may fail because the form of payment has been denied. For example, a transaction may be denied if there are insufficient funds in a bank account if a debit card is used. Thus, the payment server 16 may detect failure of the transaction based on receiving a failure notification from a corresponding payment server 16. In another example, the transaction may be denied if the form of payment has expired. For example, a user may inadvertently use an expired credit card to pay for a booking. Accordingly, the delivery server 28 may detect failure of the transaction based on receiving a notification that the credit card has expired.
Regarding Claim 10
wherein the data retrieved with the communication device comprises one or more alert messages from one or more payment method purveyors or payment mode processors indicating that one or more merchant or payment processor systems will be unavailable. (See at least Hubli [0030] The form of payment may fail for any number of reasons. For example, in one embodiment the transaction may fail because the payment server 16 was unable to connect to the corresponding payment provider system 18 due to poor connectivity of the network 26. Thus, the payment server 16 may detect failure of the transaction if a notification has not been received within a predetermined amount of time. In yet another embodiment, the transaction may fail because the form of payment has been denied. For example, a transaction may be denied if there are insufficient funds in a bank account if a debit card is used. Thus, the payment server 16 may detect failure of the transaction based on receiving a failure notification from a corresponding payment server 16. In another example, the transaction may be denied if the form of payment has expired. For example, a user may inadvertently use an expired credit card to pay for a booking. Accordingly, the delivery server 28 may detect failure of the transaction based on receiving a notification that the credit card has expired.
Regarding Claim 11
wherein the data retrieved with the communication device comprises a plurality of past financial transaction failures occurring at one or more merchant or payment processor systems within a predefined time. (See at least Hubli[0047] In one embodiment, the delivery server 28 may determine one or more processing queues. Specifically, if a transaction indicating a form of payment has failed, and if two or more forms of payment have already been approved, then the delivery server 28 may determine one or more processing queues. A processing queue may include one or more rollback requests that each correspond to an approved form of payment.
Regarding Claim 12
wherein the data retrieved with the communication device comprises one or more of a maximum financial transaction limit or a block applied to a merchant or payment processor system. (See at least Hubli [0030] The form of payment may fail for any number of reasons. For example, in one embodiment the transaction may fail because the payment server 16 was unable to connect to the corresponding payment provider system 18 due to poor connectivity of the network 26. Thus, the payment server 16 may detect failure of the transaction if a notification has not been received within a predetermined amount of time. In yet another embodiment, the transaction may fail because the form of payment has been denied. For example, a transaction may be denied if there are insufficient funds in a bank account if a debit card is used. Thus, the payment server 16 may detect failure of the transaction based on receiving a failure notification from a corresponding payment server 16. In another example, the transaction may be denied if the form of payment has expired. For example, a user may inadvertently use an expired credit card to pay for a booking. Accordingly, the delivery server 28 may detect failure of the transaction based on receiving a notification that the credit card has expired.
Regarding Claim 13
wherein the data retrieved with the communication device comprises one or more of a merchant or payment processor network failure or equipment failure. (See at least Hubli [0030] The form of payment may fail for any number of reasons. For example, in one embodiment the transaction may fail because the payment server 16 was unable to connect to the corresponding payment provider system 18 due to poor connectivity of the network 26. Thus, the payment server 16 may detect failure of the transaction if a notification has not been received within a predetermined amount of time. In yet another embodiment, the transaction may fail because the form of payment has been denied. For example, a transaction may be denied if there are insufficient funds in a bank account if a debit card is used. Thus, the payment server 16 may detect failure of the transaction based on receiving a failure notification from a corresponding payment server 16. In another example, the transaction may be denied if the form of payment has expired. For example, a user may inadvertently use an expired credit card to pay for a booking. Accordingly, the delivery server 28 may detect failure of the transaction based on receiving a notification that the credit card has expired.
Regarding Claim 14
wherein the presenting the potential payment failure mode notification occurs at a predetermined time during the day. (See at least Hubli [0011] In another embodiment, a refund notification is not received in reply to the first rollback request over a predetermined amount of time, and the program code further causes the system to periodically send a predetermined number of secondary requests for reversal or refund of the first transaction to the first payment provider at predetermined intervals of time.
Regarding Claim 18
wherein the potential payment failure mode notification instructs one or more alternative payment modes for use while the probable failure of the digital wallet application to complete the upcoming financial transactions is occurring. (See at least Hubli [0008] In one embodiment, the system includes program code that, when executed by the one or more processors, further causes the system to receive information indicating a third form of payment and a third transaction to the third form of payment used to purchase the product or service. The system is further caused to send, to a third payment provider system, a third request to authorize the third transaction to the third form of payment. The system also receives a second notification that the third request has been approved by the third payment provider system.
Regarding Claim 19
wherein the potential payment failure mode notification comprises an audible alert. (See at least Hubli [0036] The HMI 60 may be operatively coupled to the processor 52 of computer system 50 in a known manner to allow a user to interact directly with the computer system 50. The HMI 60 may include video or alphanumeric displays, a touch screen, a speaker, and any other suitable audio and visual indicators capable of providing data to the user. The HMI 60 may also include input devices and controls such as an alphanumeric keyboard, a pointing device, keypads, pushbuttons, control knobs, microphones, etc., capable of accepting commands or input from the user and transmitting the entered input to the processor 52.
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 5, 6, 8, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hubli (US 2019/0057384 A1) in view of Phipps (US 2017/0193491 A1).
Regarding Claim 5
Hunli does not specifically teach: wherein the detecting the prospective financial transaction using the digital wallet application comprises querying, by the one or more processors, a calendaring application to detect a scheduled appointment stored in the calendaring application that identifies a merchant.
However Phipps teaches: [0030] In some embodiments, payment provider server 170 may maintain user history in the account information, such as user's browsing history, purchase history, communication history, and the like. In some embodiments, payment provider server 170 may have access to user's contact list, to-do list, calendar, and the like. Payment provider server 170 also may maintain merchant information, such as merchant's location history, transaction history, type of business, products/services offered, and the like. Payment provider server 170 may utilize the account information of users and/or merchants to automatically determine location/event based merchant groups. In an embodiment, payment provider server 170 may include a location/event based merchant group database storing various location/event based merchant groups. In some embodiments, a merchant may be included in various merchant groups at different time and/or location, especially for traveling merchants.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the mobile transaction device enabling dynamic electronic checks as taught by Phipps in order to allow merchants associated with events or locations may be quickly located for transactions. (Phipps (abstract))
Regarding Claim 6
Hunli does not specifically teach: wherein the detecting the prospective financial transaction using the digital wallet application comprises receiving, with the communication device by the one or more processors, an electronic communication identifying both a scheduled appointment and a merchant.
However Phipps teaches: [0030] In some embodiments, payment provider server 170 may maintain user history in the account information, such as user's browsing history, purchase history, communication history, and the like. In some embodiments, payment provider server 170 may have access to user's contact list, to-do list, calendar, and the like. Payment provider server 170 also may maintain merchant information, such as merchant's location history, transaction history, type of business, products/services offered, and the like. Payment provider server 170 may utilize the account information of users and/or merchants to automatically determine location/event based merchant groups. In an embodiment, payment provider server 170 may include a location/event based merchant group database storing various location/event based merchant groups. In some embodiments, a merchant may be included in various merchant groups at different time and/or location, especially for traveling merchants.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the mobile transaction device enabling dynamic electronic checks as taught by Phipps in order to allow merchants associated with events or locations may be quickly located for transactions. (Phipps (abstract))
Regarding Claim 8
Hunli does not specifically teach: wherein the detecting the prospective financial transaction using the digital wallet application comprises querying, by the one or more processors form a memory of the electronic device, an electronically stored to-do list to identify one or more to-do items stored in the memory that reference a merchant.
However Phipps teaches: [0030] In some embodiments, payment provider server 170 may maintain user history in the account information, such as user's browsing history, purchase history, communication history, and the like. In some embodiments, payment provider server 170 may have access to user's contact list, to-do list, calendar, and the like. Payment provider server 170 also may maintain merchant information, such as merchant's location history, transaction history, type of business, products/services offered, and the like. Payment provider server 170 may utilize the account information of users and/or merchants to automatically determine location/event based merchant groups. In an embodiment, payment provider server 170 may include a location/event based merchant group database storing various location/event based merchant groups. In some embodiments, a merchant may be included in various merchant groups at different time and/or location, especially for traveling merchants.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the mobile transaction device enabling dynamic electronic checks as taught by Phipps in order to allow merchants associated with events or locations may be quickly located for transactions. (Phipps (abstract))
Regarding Claim 16
Hunli does not specifically teach: detecting, by a location detector, the electronic device exiting a dwelling of an authorized user of the electronic device; wherein the predetermined time during the day occurs when the electronic device exits the dwelling of the authorized user of the electronic device.
However Phipps teaches: [0030] In some embodiments, payment provider server 170 may maintain user history in the account information, such as user's browsing history, purchase history, communication history, and the like. In some embodiments, payment provider server 170 may have access to user's contact list, to-do list, calendar, and the like. Payment provider server 170 also may maintain merchant information, such as merchant's location history, transaction history, type of business, products/services offered, and the like. Payment provider server 170 may utilize the account information of users and/or merchants to automatically determine location/event based merchant groups. In an embodiment, payment provider server 170 may include a location/event based merchant group database storing various location/event based merchant groups. In some embodiments, a merchant may be included in various merchant groups at different time and/or location, especially for traveling merchants.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the mobile transaction device enabling dynamic electronic checks as taught by Phipps in order to allow merchants associated with events or locations may be quickly located for transactions. (Phipps (abstract))
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Hubli (US 2019/0057384 A1) in view of Sardari et al (US 2023/0316280 A1).
Regarding Claim 7
wherein the detecting the prospective financial transaction using the digital wallet application comprises: querying, from a memory of the electronic device by the one or more processors, past financial transactions made by an authorized user of the electronic device that are stored in the memory; (See at least Hubli [0037] A database 64 may reside on the mass storage memory device 56, and may be used to collect and organize data used by the various systems and modules described herein. The database 64 may include data and supporting data structures that store and organize the data. In particular, the database 64 may be arranged with any database organization or structure including, but not limited to, a relational database, a hierarchical database, a network database, or combinations thereof. A database management system in the form of a computer software application executing as instructions on the processor 52 may be used to access the information or data stored in records of the database 64 in response to a query, where a query may be dynamically determined and executed by the operating system 66, other applications 68, or one or more modules.)
However, Hubli does not specifically teach: “determining, by the one or more processors, a repeating pattern of one or more repeating financial transactions; and predicting, by the one or more processors, another instance of the repeating pattern as the prospective financial transaction.”
However Sardari teaches:
determining, by the one or more processors, a repeating pattern of one or more repeating financial transactions; and (See at least Sardari [0129] Information from stored and/or accessible data may be extracted from one or more databases, such as the datastore(s) 116, and may be utilized to predict trends and behavior patterns.)
predicting, by the one or more processors, another instance of the repeating pattern as the prospective financial transaction. (See at least Sardari [0129] The predictive analytic techniques may be utilized to determine associations and/or relationships between explanatory variables and predicted variables from past occurrences and utilizing these variables to predict the unknown outcome. The predictive analytic techniques may include defining the outcome and data sets used to predict the outcome.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the machine learning model for fraud reduction as taught by Sardari in order to inspect the data with the goal of identifying useful information and arriving at one or more determinations that assist in predicting the outcome of interest. (Sardari [0130])
Claim 15 is rejected under 35 U.S.C. 103 as being unpatentable over Hubli (US 2019/0057384 A1) in view of Wintle et al (US 2022/0245641 A1).
Regarding Claim 15
Hunli does not specifically teach: wherein the predetermined time corresponds with actuation, by the one or more processors, of an alarm using an alarm application operating on the one or more processors.
However, Wintle teaches: [0042] In one embodiment, the alert message may contain cardholder selectable links to response options about the next recurring transaction. For example, the alert message may contain response options such as “verify”, “deny” or “fraudulent”. The options may be displayed in the form of a prompt, selection box, or a link (e.g., a uniform resource locator (URL)) for the cardholder to enter/select an appropriate verification, denial and/or fraud response. In one embodiment, once entered by cardholder 106, a response message of the cardholder 106 may be received by the issuer 110. In one embodiment, the issuer 110 may forward the response message to the intelligent recurring transaction component 120 or the payment processor 102. In one embodiment, non-receipt of a response must within a predetermined period of time may be treated as a verification of the next recurring payment. In embodiments, the alert message and the response message may be sent through the cardholder's preferred communication channel, e.g., a text/SMS message, email, an automated phone call, or transmitted to/from an electronic wallet application of the issuer 110 running on a device of the cardholder, described further below.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the generating rollback requests to reverse partially approved payments of Hubli in view of the intelligent recurring transaction processing and fraud detection as taught by Wintle in order to for a call is to be initiated via the API to the issuer with transaction attributes regarding the next recurring payment transaction prior to the predicted date of the next recurring payment transaction so that the issuer can forward the information in an electronic alert message directly to the cardholder. (Wintle [0041])
Prior Art of Record Not Currently Relied Upon
Torres (Us 2018/0092020 A1) Teaches: Mobile network node routing.
Carrington (US 2018/0165759 A1) Teaches: Method for identifying card on file payment account transactions.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GREGORY MARK JAMES whose telephone number is (571)272-5155. The examiner can normally be reached M-F 8:30am - 5:00pm EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ryan Donlon can be reached at 571-270-3602. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/GREGORY M JAMES/Examiner, Art Unit 3692
/RYAN D DONLON/Supervisory Patent Examiner, Art Unit 3692
March 26, 2026
Prosecution Insights