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 amendments filed on May 26, 2026
• Claims 1, 5, 11, 14, 18, 21 have been amended and are hereby entered.
• Claim 22 has been added.
• Claims 3 and 17 have been canceled.
• Claims 1-2, 4-16, and 18-22 are currently pending and have been examined.
• This action is made FINAL.
Information Disclosure Statement
The information disclosure Statement(s) filed on 04/29/2026 have been considered. Initialed copies of the Form 1449 are enclosed herewith.
Response to Arguments
Applicant’s arguments filed May 26, 2026 have been fully considered but they are not persuasive.
The Examiner is withdrawing the 35 USC § 101 due to Applicant’s amendments.
Applicant’s arguments with respect to 35 USC § 103 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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-22 are rejected under 35 U.S.C. 103 as being unpatentable over US 20210312339 A1 (“Stogo”) in view of US 20230370660 A1 (“El Ghazzal”).
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 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 corresponding to the network connection, wherein the condition is 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 characteristics of the network connection 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 condition is based on the one or more changes in characteristics of the network, and 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 characteristics of the network connection 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 one or more of a network connection status, a data throughput speed of the network connection, a type of the network connection, or a signal 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. Furthermore, while Stogo discloses changes in characteristics of the network, Stogo does not expressly disclose the changes of characteristics in the network satisfying a threshold signal strength of the network connection and a threshold data throughput speed of the network connection.
However, El Ghazzal discloses the steps being performed by the client device (client device performing steps including executing an application on the client device, sending and receiving data, and detecting error with network connection, etc. See at least [0018]-[0020] and [0044]-[0045].);
the characteristics of network connections are associated with the client device, the characteristics comprise one or more of a network connection status, a data throughput speed of the network connection, a type of the network connection, or a signal strength of the network connection (Example information describing the connection between the client device of the user and the network includes a connection strength, a connection speed, a connection type, or any other suitable information. See at least [0044].);
detect a condition corresponding to a network connection at the client device; the changes of characteristics in the network satisfying a threshold signal strength of the network connection and a threshold data throughput speed of the network connection (Information describing the connection between the client device of the user and the network includes a connection strength, a connection speed, a connection type, or any other suitable information. For example, detecting the error in the video content in response to a connection strength of the connection between the client device of the user and the network being less than a threshold strength or in response to a connection speed of the connection between the client device of the user and the network being less than a threshold speed. See at least [0044].).
From the teaching of El Ghazzal, 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 El Ghazzal, and to modify the characteristics of El Ghazzal to be associated with the client device and to comprise one or more of a network connection status, a data throughput speed of the network connection, a type of the network connection, or a signal strength of the network connection, as taught by El Ghazzal, and to modify the detecting a condition corresponding to a network connection of Stogo to be at the client device, as taught by El Ghazzal, and to modify the changes of characteristics in the network of Stogo to satisfy a threshold signal strength of the network connection and a threshold data throughput speed of the network connection, as taught by El Ghazzal, in order to improve user experience for users interacting online (see El Ghazzal at least at [0001]-[0003]. 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.
Regarding claim 2, the combination of Stogo and El Ghazzal 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 El Ghazzal 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 El Ghazzal 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 that 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 El Ghazzal 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 El Ghazzal 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 El Ghazzal 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 El Ghazzal discloses the limitations of claim 1, as discussed above, and Stogo further discloses wherein to monitor the characteristics of the network connection, 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.).
Regarding claim 22, the combination of Stogo and El Ghazzal discloses the limitations of claim 1, as discussed above, and while Stogo discloses transmitting and receiving signaling for the data transaction (see Stogo at least at [0033]-[0035], describing a user initiates payment request using application on the user device.), Stogo does not expressly disclose to detect the change in the condition, the one or more processors are further configured to compare the one or more changes in the characteristics of the network connection to respective thresholds for the characteristics, wherein the respective thresholds comprise threshold values for transmitting and receiving signaling.
However, El Ghazzal discloses to detect the change in the condition, the one or more processors are further configured to compare the one or more changes in the characteristics of the network connection to respective thresholds for the characteristics, wherein the respective thresholds comprise threshold values for transmitting and receiving signaling (Information describing the connection between the client device of the user and the network includes a connection strength, a connection speed, a connection type, or any other suitable information. For example, detecting the error in the video content in response to a connection strength of the connection between the client device of the user and the network being less than a threshold strength or in response to a connection speed of the connection between the client device of the user and the network being less than a threshold speed. See at least [0044].).
From the teaching of El Ghazzal, it would have been obvious to one having ordinary skill in the art before the effective filing date to modify Stogo to detect the change in the condition, the one or more processors are further configured to compare the one or more changes in the characteristics of the network connection to respective thresholds for the characteristics, wherein the respective thresholds comprise threshold values for transmitting and receiving signaling, as taught by El Ghazzal, in order to improve user experience for users interacting online (see El Ghazzal at least at [0001]-[0003]. 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.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Stogo in view of El Ghazzal, and in further view of US 20180101906 A1 (“McDonald”).
Regarding claim 6, the combination of Stogo and El Ghazzal 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 El Ghazzal, and in further view of US 20160335608 A1 (“Balasubramani”).
Regarding claim 7, the combination of Stogo and El Ghazzal 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, El Ghazzal, 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.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to RAVEN E YONO whose telephone number is (313)446-6606. The examiner can normally be reached Monday - Friday 8-5PM EST.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bennett M Sigmond can be reached at (303) 297-4411. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/RAVEN E YONO/Primary Examiner, Art Unit 3694
Prosecution Insights