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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on January 13, 2026 has been entered.
Status of Claims
• This action is in reply to the RCE filed on January 13, 2026.
• Claims 1, 10-11, 17-18, and 21 have been amended and are hereby entered.
• Claim 3 has been canceled.
• Claims 1-2 and 4-21 are currently pending and have been examined.
• This action is made Non-FINAL.
Response to Arguments
Applicant’s arguments filed January 13, 2026 have been fully considered but they are not persuasive.
New 35 USC § 101 rejections for claim 21 have been entered due to applicant’s amendments.
The Examiner is maintaining the 35 USC § 101 rejection. In particular, the Examiner notes that the amended claim limitations are broader than the limitations that were deemed patent eligible in claim 21. For example, the step of claim 1 that detects, “based on the characteristic of the network connection associated with the client device, a condition” has been broadened to remove that the condition “corresponds to a network connection at the client device.” Now, the condition is merely “associated with a failure to execute the data transaction at the first time.” The Specification at [0051] describes a condition that causes a failure to execute the data transaction to be, for example, based on “a stored balance associated with the payment service.” In other words, the claim is missing the step of the network connection being lost/failing in the first place, and therefore the claims are no longer detecting a network failure; and if there is no network failure detected, then there is no network failure to address and the claims are therefore not improving technology.
In order to overcome the 101 rejection, the Examiner recommends amending claim 1 to recite “detect, based on the characteristics of the network connection associated with the client device, a condition corresponding to a network connection at the client device, wherein the condition is associated with a failure to execute the data transaction at the first time.”
In this way, the claims would then be patent-eligible because it will clearly define the detected condition as a condition of the network connection status of the device (as opposed to a condition of an account not having enough balance to complete a transaction).
Regarding claim 21, the claim has been broadened and rejected under 35 USC 101 for similar reasons as claim 1 as described above.
The claims are not patent eligible.
Applicant’s arguments with respect to 35 USC § 103 have been fully considered and are not persuasive.
Regarding Applicant’s arguments on pages 13-14, that Stogo does noes not teach the claimed processes performed by the client device and rather Stogo teaches the claimed processes performed by various components of the server, the argument has been considered and is not persuasive. In response to the argument, the Examiner notes, as discussed in detail in the 103 rejection below, that Kumar teaches performing various operations at the client device (see Kumar at least at [0047] and FIG. 4, step 402-404). The cited art of record therefore teaches this limitation.
For the reasons above, Applicant’s arguments are not persuasive.
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, 10-11, 17-18, and 21 are rejected under 35 U.S.C. 101 because the claimed invention recites an abstract idea without significantly more. Independent claims 1, 11, and 18 are directed to an apparatus (claim 1), a method (claim 11), and a system (claim 18). Therefore, on its face, each independent claim 1, 11, and 18 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 1, 11, and 18 recite, in part, an apparatus, a method, and a system of organizing human activity. Using the limitations in claim 1 to illustrate, the claim recites receive, via associated with a payment service and at a first time, a request to execute a data transaction; collect network information that includes characteristics at the time first; detect, based on the characteristics, a condition associated with a failure to execute the data transaction at the first time; refrain from executing, at the first time, the data transaction based on the condition; monitor the network information at a second time after the first time to detect one or more changes in the characteristics; detect, based on the one or more changes in the characteristics and at the second time, a change in the condition, wherein the change in condition is associated with executing the data transaction, automatically execute, at the second time, the data transaction based on the change in the condition; and discontinue monitoring responsive to automatically executing the data transaction. The Specification at [0004] recites the following regarding the data transaction:
“For example, the data transaction can include a payment for a service provided to the user of the device, where the service is terminated if the data transaction is not executed during the time period. Additionally, or alternatively, the data transaction can include a scheduled payment and/or a payment in real-time for one or more items. In some variations, the items are to be consumed or used by the user of the device during the time period (e.g., food for a meal during the time period, an item used to complete a task during the time period, etc.). In some other variations, the data transaction can include a retroactive and/or proactive payment for one or more items consumed during the time period and/or outside of the time period. For example, the data transaction can include a payment from a business to another business, such as a payment to an office stationery supplier from a business.”
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 detecting a condition for processing a transaction and executing the transaction based on the condition, 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 client device comprising one or more processors and one or more memories 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 client device comprising: at least one memory; and processors coupled with the at least one memory and configured to cause the client device to perform claim functions; a system comprising: one or more processors; and computer-readable storage media storing instructions that are executable by the one or more processors to perform claim functions; an application of the client device; a network connection; characteristics of a network connection associated with the client device, wherein the characteristics comprise at least one of a network connection status, a speed of the network connection, a type of the network connection, or a strength of the network connection are recited at a high-level of generality (i.e., as a generic processor performing a generic computer function receiving a request, detecting a condition, and executing the transaction based on a condition) such that they amount to no more than mere instructions to apply the exception using a generic computer components (see MPEP 2106.05(f)).
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 mere instructions to apply the exception using generic computer components. Mere instructions to apply an exception 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 2, 4-10, 12-17, and 19-21 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 1-2, 4-20, and 21 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 1-2, 4-5, 9-14, and 16-21 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210312339 A1 (“Stogo”) in view of US 20210097521 A1 (“Kumar”).
Regarding claim 1, Stogo discloses a device comprising: at least one memory; and processors coupled with the at least one memory and configured to cause the device to (see at least [0021]-[0022].):
receive, via an application of the client device associated with a payment service and at a first time, a request to execute a data transaction (Server receives request from client device, the request including payment information, see at least [0038] and FIG. 2, Step 202. User initiates payment request using application on the user device, see at least [0033]-[0035].);
collect network information that includes characteristics of a network connection at the first time (The payment authorization module may identify an outage at the payment service provider. The payment authorization module may identify the outage if the payment authorization module does not receive a response message from the payment service provider after a threshold amount of time, the connection between the payment authorization module and the payment service provider is unavailable, or the payment authorization module receives an indication of a connection failure from the payment service provider, such as an error message indicating that the payment service provider is experiencing an outage. See at least [0041].);
detect, based on the characteristics of the network connection, a condition associated with a failure to execute the data transaction at the first time (The server detects an outage at a payment service provider, see at least [0041] and FIG. 2, step 208. An outage may be for example when communication connection between modules is unavailable, see at least [0041], and communication is via networks, see at least [0028]-[0030].);
refrain from executing, via the application and at the first time, the data transaction based on the condition (After detecting the outage, Stogo teaches performing multiple different steps that are not executing the transaction, see Stogo at least at [0042]-[0044] and FIG. 2, steps 210-218.);
monitor the network information at a second time after the first time to detect one or more changes in the characteristics of the network connection (After there is an outage, periodically (e.g., every 30 minutes) retransmitting payment information to the payment service provider, see at least [0045]. See also FIG. 3, steps 302-306 and [0049].);
detect, based on the one or more changes in the characteristics of the network connection and at the second time, a change in the condition, wherein the change in the condition is associated with executing the data transaction (The offline retry engine in the server device determines whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0046] and FIG. 3, step 302.);
automatically execute, via the application and at the second time, the data transaction based on the change in the condition (After determining the connection to the payment service provider has been restored, retransmitting the payment information to authorize the payment. See at least [0049] and see also FIG. 3, step 306.); and
discontinue monitoring the network information responsive to automatically executing the data transaction (After there is an outage, periodically (e.g., every 30 minutes) retransmitting payment information to the payment service provider. The offline retry engine periodically retransmits the payment information for the queue of transactions in the offline database to the payment service provider. See at least [0045]. The offline retry engine retransmits the payment information for the transaction to the payment service provider, which authorizes the payment and transmits a payment authorization including a valid approval code to the offline retry engine. The offline retry engine then removes the transaction from the offline database. See at least [0050]-[0051]. The Examiner notes that Stogo teaches monitoring transactions stored in the offline transaction database by periodically retrying them for example every 30 minutes. Therefore, the Examiner interprets removing the transaction from the offline database, after a successful execution of the transaction, as discontinuing monitoring.).
While Stogo discloses claimed steps performed by a device, Stogo does not expressly disclose these claimed steps are performed specifically by the client device. Furthermore, while Stogo discloses characteristics of the network connection, Stogo does not expressly disclose the characteristics of network connections are associated with the client device, the characteristics comprise at least one of a network connection status, a speed of the network connection, a type of the network connection, or a strength of the network connection. Furthermore, while Stogo discloses detecting a condition corresponding to a network connection, does not expressly disclose detect a condition corresponding to a network connection at the client device.
However, Kumar discloses the claimed steps being performed by the client device (The payer device monitors connectivity of the payer device to the wide area network. In a step, the payee device monitors connectivity of the payee device to the wide area network. The steps determine if the payer device and the payee device are connected to or disconnected from the wide area network, thus determining if they are in the online or offline mode. See at least [0047] and FIG. 4, step 402-404. See also FIG. 5. Stogo teaches executing the application on a client device and performing monitoring and performing steps relating the monitoring at the client deivce.);
the characteristics of network connections are associated with the client device, the characteristics comprise at least one of a network connection status, a speed of the network connection, a type of the network connection, or a strength of the network connection (The payer device monitors connectivity of the payer device to the wide area network. In a step, the payee device monitors connectivity of the payee device to the wide area network. The steps determine if the payer device and the payee device are connected to or disconnected from the wide area network, thus determining if they are in the online or offline mode. See at least [0047] and FIG. 4, step 402-404. The payer device in the offline mode and establish the local area network connection. The local area network connection is a separate communication channel from the wide area network. See at least [0050]. The Examiner interprets being connected to LAN but not WAN as a network connection failing to satisfy a type of network connection. Furthermore, the Examiner interprets a device not being connected to WAN as failing to satisfy a threshold of strength of a network connection because the network strength would be 0 and the threshold would be that the strength must be greater than zero.).
From the teaching of Kumar, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the operations of Stogo to be performed at the client device, as taught by Kumar, and to modify the characteristics of Stogo to be associated with the client device and to comprise at least one of a network connection status, a speed of the network connection, a type of the network connection, or a strength of the network connection, as taught by Kumar, in order to improve electronic device and computerized networks for devices not connected to a network (see Kumar at least at [0003]-[0006]), and in order to improve efficiency and performance of performing transactions (see Kumar at least at [0080]).
Regarding claim 2, the combination of Stogo and Kumar disclose the limitations of claim 1, as discussed above, and Stogo further discloses output, for display via a user interface of the client device, a control that is selectable to cause execution of the data transaction based on the change in the condition (Server device determines whether a threshold time period has expired or whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0051] and FIG. 4, step 402. In response, the server requests an alternative form of payment from the client device. See at least [0054] and FIG. 4, step 414. Client device displaying information, for example via an application running on the device, see at least [0032]-[0034]. The offline retry engine may receive a selection of a user control. See at least [0048]. See also [0052] and [0056].); and
receive a selection via the control that indicates for the client device to automatically execute the data transaction based on the change in the condition (The user may then provide an alternative method of payment via the client device which is sent to the offline retry engine. See at least [0054] and FIG. 4, step 416.).
Regarding claim 4, the combination of Stogo and Kumar disclose the limitations of claim 1, as discussed above, and Stogo further discloses output, for display via a user interface of the client device, a message that indicates a status of execution of the data transaction at the second time wherein the status comprises at least one of a successful execution of the data transaction or a failed execution of the data transaction (Determining a time period has expired or that the server has received an indication that the outage has ended, see at least [0051] and FIG. 4, step 402. Then after the determination, sending a message to the user device requesting an alternative form of payment, see at least [0054] and FIG. 4, step 414. The Examiner interprets the message requesting an alternative form of payment as a message that indicated a status of execution being a failed execution.).
Regarding claim 5, the combination of Stogo and Kumar disclose the limitations of claim 1, as discussed above, and Stogo further discloses at least one of: detect a change from a first network connection status associated with the network connection to a second network connection status associated with the network connection (The server detects an outage at a payment service provider, see at least [0041] and FIG. 2, step 208. An outage may be for example when communication connection between modules is unavailable, see at least [0041], and communication is via networks, see at least [0028]-[0030]. The offline retry engine in the server device determines whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0046] and FIG. 3, step 302.);
detect a change from one or more first characteristics of the network connection to one or more second characteristics of the network connection (The server detects an outage at a payment service provider, see at least [0041] and FIG. 2, step 208. An outage may be for example when communication connection between modules is unavailable, see at least [0041], and communication is via networks, see at least [0028]-[0030]. The offline retry engine in the server device determines whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0046] and FIG. 3, step 302.);
detect a change from a first server status to a second server status (The server detects an outage at a payment service provider, see at least [0041] and FIG. 2, step 208. An outage may be for example when communication connection between modules is unavailable, see at least [0041], and communication is via networks, see at least [0028]-[0030]. The offline retry engine in the server device determines whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0046] and FIG. 3, step 302.);
detect a change in a value of a stored balance associated with the payment service, wherein the value of the stored balance satisfies a threshold value corresponds to a transaction value associated with the data transaction;
detect a change in a threshold transaction value associated with the data transaction;
detect expiry of a timer corresponding to a threshold numerical quantity of data transactions associated with the payment service;
detect expiry of a timer corresponding to a threshold transaction value associated with the data transaction;
detect a change to a geographic location corresponding to a greater threshold numerical quantity of data transactions associated with the payment service;
detect a change to a geographic location corresponding to a greater threshold transaction value associated with the data transaction; or
detect a change to at least one of a numerical quantity of data transactions associated with a geographic location or a threshold transaction value for one or more data transactions associated with the geographic location.
Regarding claim 9, the combination of Stogo and Kumar discloses the limitations of claim 1, as discussed above, and Stogo further discloses to receive the request to execute the data transaction, the one or more processors are configured to receive, via an interactable element of a user interface displayed at the client device, user input indicating the request to execute the data transaction (Server device determines whether a threshold time period has expired or whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0051] and FIG. 4, step 402. In response, the server requests an alternative form of payment from the client device. See at least [0054] and FIG. 4, step 414. Client device displaying information, for example via an application running on the device, see at least [0032]-[0034]. The offline retry engine may receive a selection of a user control. See at least [0048]. See also [0052] and [0056].).
Regarding claim 10, the combination of Stogo and Kuma discloses the limitations of claim 1, as discussed above, and Stogo further discloses wherein the one or more processors are further configured to detect an additional condition corresponding to the failure to execute the data transaction at the first time, wherein the additional condition comprises at least one of a server status (The payment authorization module may identify an outage at the payment service provider. The payment authorization module may identify the outage if the payment authorization module does not receive a response message from the payment service provider after a threshold amount of time, the connection between the payment authorization module and the payment service provider is unavailable, or the payment authorization module receives an indication of a connection failure from the payment service provider, such as an error message indicating that the payment service provider is experiencing an outage. See at least [0041].),
a value of a stored balance associated with the payment service, a threshold numerical quantity of data transactions associated with the payment service for a duration of a timer, a threshold numerical quantity of data transactions associated with a geographic location, or a threshold transaction value associated with the geographic location.
Claim 11 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Regarding claim 12, the combination of Stogo and Kumar disclose the limitations of claim 11, as discussed above, and Stogo further discloses outputting, for display via a user interface of the client device, a control that is selectable to cause automatic execution of the data transaction based on the change in the condition (Server device determines whether a threshold time period has expired or whether the offline retry engine has received an indication that the connection to the payment service provider has been restored. See at least [0051] and FIG. 4, step 402. In response, the server requests an alternative form of payment from the client device. See at least [0054] and FIG. 4, step 414. Client device displaying information, for example via an application running on the device, see at least [0032]-[0034]. The offline retry engine may receive a selection of a user control. See at least [0048]. See also [0052] and [0056].).
Claim 13 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Claim 14 has similar limitations found in claim 5 above, and therefore is rejected by the same art and rationale.
Claim 16 has similar limitations found in claim 9 above, and therefore is rejected by the same art and rationale.
Claim 17 has similar limitations found in claim 10 above, and therefore is rejected by the same art and rationale.
Claim 18 has similar limitations found in claim 1 above, and therefore is rejected by the same art and rationale.
Claim 19 has similar limitations found in claim 2 above, and therefore is rejected by the same art and rationale.
Claim 20 has similar limitations found in claim 4 above, and therefore is rejected by the same art and rationale.
Regarding claim 21, the combination of Stogo and Kumar discloses the limitations of claim 1, as discussed above, and Stogo further discloses wherein to monitor the network information, the one or more processors are further configured to: determine a time period associated with automatically executing the data transaction; and detect, within the time period, the one or more changes in the characteristics of the network connection, (The offline retry engine in the server device determines whether a threshold time period has expired (e.g., 30 minutes after the last attempt to communicate with the payment service provider). See at least [0046] and see also FIG. 3, step 302.).
While Stogo discloses detect a change in condition, Stogo does not expressly disclose the change in condition is based on the one or more changes in characteristics of the network connection satisfying at least one of network connection status, a threshold strength of the network connection, the type of network connection, or a threshold speed of the network connection.
However, Kumar discloses the change in condition is based on the one or more changes in characteristics of the network connection satisfying at least one of network connection status, a threshold strength of the network connection, the type of network connection, or a threshold speed of the network connection (The payer device monitors connectivity of the payer device to the wide area network. In a step, the payee device monitors connectivity of the payee device to the wide area network. The steps determine if the payer device and the payee device are connected to or disconnected from the wide area network, thus determining if they are in the online or offline mode. See at least [0047] and FIG. 4, step 402-404. The payer device in the offline mode and establish the local area network connection. The local area network connection is a separate communication channel from the wide area network. See at least [0050]. However, if the payer device subsequently reconnects to the wide area network, the payer device deactivates the payer offline wallet in response to determining that the payer device is connected to the wide area network and has returned to the online mode. See at least [0049]. The Examiner interprets reconnection to the WAN as a change in characteristic satisfying a type of network connection. Furthermore, the Examiner interprets reconnection to WAN, which would have satisfy a threshold of strength of a network connection by being greater than 0, as satisfying a threshold of strength.).
From the teaching of Kumar, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the characteristic of Stogo to be based on the one or more changes in characteristics of the network connection satisfying at least one of network connection status, a threshold strength of the network connection, the type of network connection, or a threshold speed of the network connection, as taught by Kumar, in order to improve electronic device and computerized networks for devices not connected to a network (see Kumar at least at [0003]-[0006]), and in order to improve efficiency and performance of performing transactions (see Kumar at least at [0080]).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Stogo in view of Kumar, and in further view of US 20180101906 A1 (“McDonald”).
Regarding claim 6, the combination of Stogo and Kumar discloses the limitations of claim 1, as discussed above, and Stogo further discloses receive, via an interactable element of a user interface displayed at the client device, user input indicating data (Client device displaying information, for example via an application running on the device, see at least [0032]-[0034]. The offline retry engine may receive a selection of a user control. See at least [0048]. See also [0052] and [0056].).
While Stogo discloses input indicating data, Stogo does not expressly disclose indicating at least one of a threshold numerical quantity of data transactions associated with respective geographic locations of a plurality of geographic locations or a threshold transaction value associated with the respective geographic locations of the plurality of geographic locations.
However, McDonald discloses indicating at least one of a threshold numerical quantity of data transactions associated with respective geographic locations of a plurality of geographic locations or a threshold transaction value associated with the respective geographic locations of the plurality of geographic locations (Some exemplary parameters include, but are not limited to: earmarked spending limits on different types of purchases, daily or weekly spending limits, conditional spending limits (if $X is sent to recipient A, then a limit of $Y is set for sending to recipient B). For example, personal constraints can limit spending to a percentage of available balance, or to a threshold amount within a predetermined period (e.g., $10,000 per month). The personal constraints can limit spending according to a previously entered budget allocation. The personal constraints can limit spending from a wallet depending on location of a transaction. The user can set a parameter for the maximum amount to spend within a defined geographic region or in a pre-determined business establishment. (e.g., The constraint can limit spending to a pre-determined amount at a casino). See at least [0038].).
From the teaching of McDonald, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the data of Stogo to indicate a threshold transaction value associated with the respective geographic locations of the plurality of geographic locations, as taught by McDonald, in order to improve enforcing controls on spending (see McDonald at least at [0038]). Since the claimed invention is merely a combination of old elements, and in the combination, each element merely would have performed the same function it performed separately, one having ordinary skill in the art at the time of the invention would have recognized that the results of the combination were predictable.
Claims 7-8 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210312339 A1 (“Stogo”) in view of Kumar, and in further view of US 20160335608 A1 (“Balasubramani”).
Regarding claim 7, the combination of Stogo and Kumar disclose the limitations of claim 1, as discussed above, and Stogo further discloses receive, via an interactable element of a user interface displayed at the client device, user input (Client device displaying information, for example via an application running on the device, see at least [0032]-[0034]. The offline retry engine may receive a selection of a user control. See at least [0048]. See also [0052] and [0056].).
While Stogo discloses input, Stogo does not expressly disclose input indicating an expiry time associated with automatically executing the data transaction.
However, Balasubramani discloses input indicating an expiry time associated with automatically executing the data transaction (One example user interface for inputting one or more virtual payment device parameters according to one or more aspects described herein. The interface includes fields for inputting one or more virtual payment device parameters. For instance, interface include field in which an amount of the virtual payment device may be input. An expiration date of the virtual payment device may be input in field. The date may be directly inserted into field by the user or, upon selection of field, a calendar interface may be displayed and the user may select a desired expiration date from the calendar. See at least [00059].).
From the teaching of Balasubramani, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify the input of Stogo to indicate an expiry time associated with automatically executing the data transaction, as taught by Balasubramani, in order to improve efficiency and security of payment transactions (see Balasubramani at least at [0001]), and in order to improve privacy and security of customers payment information (see Balasubramani at least at [0070]).
Regarding claim 8, the combination of Stogo, Kumar, and Balasubramani disclose the limitations of claim 7, as discussed above, and Stogo further discloses to automatically execute the data transaction, the one or more processors are configured to detect the expiry time (determining a threshold time has expired before retransmitting request, see at least [0051]-[0056].).
Claim 15 has similar limitations found in claim 7 above, and therefore is rejected by the same art and rationale.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20210383382 A1 (“Harris”) discloses receiving a payment request for a financial transaction and determining whether the financial transaction violates at least one of a hard or soft rule associated with a customer account. The method also includes, in response to determining that the transaction does not violate a hard rule but violates a soft rule, determining whether the financial transaction is low risk and, in response to determining that the financial transaction is low risk, authorizing the payment for the transaction. The method further includes updating the violated soft rule such that future financial transactions similar to the authorized financial transaction do not violate the soft rule.
US 20220122076 A1 (“Braun”) discloses providing transaction retry notifications to merchants based on monitored account usage. An insufficient funds message of a first transaction is received that indicates the first transaction includes a payment to be provided to a merchant from an account and that the account has insufficient funds for the first transaction. An account identifier of the account is stored and a transaction message of a second transaction associated with the account is detected based on the stored account identifier. The transaction message indicates that the account has sufficient funds for the second transaction. Based on detecting the transaction message, a transaction retry notification is sent to the merchant, whereby the merchant is notified that the account with which the first transaction is associated includes a quantity of funds. The disclosure enables merchants to optimize the timing or retrying failed transactions and thereby reduce costs associated with transaction retries.
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