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 March 31, 2026 has been entered.
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, 6-12, 14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al, (US 2007/0156611 A1) hereinafter “Gupta” in view of Thomas et al (US 2022/0391890 A1) “Thomas” in view of Liu et al. (US 2021/0049594 A1) hereinafter “Liu”, in view of Gupta ‘613, (US 7783613 B2).
Regarding claim 1: Gupta disclose:
A system (See at least Gupta, Fig. 3 Computer System) comprising:
one or more processors; (See at least Gupta, Fig. 3 CPU) and
one or more non-transitory, computer-readable mediums (See at least Gupta, Fig. 3 memory) including instructions which, when executed by the one or more processors, cause the system to
receive, from a user system, over a communication network, rule data for defining an expiration for transaction authorizations, the rule data including an expiration value and one or more attribute field-value pairs; (See at least Gupta, Fig. 1A; Fig. 1B; Fig 1D; [0021]; [0030-0034]; [0048]; [0054]; [0095] where rule data (i.e., usage instruction rule sets) for defining an expiration for transaction authorizations is received, the rule data including an expiration value (i.e., expiration date/ durationTimeLimit ) and one or more attribute field-value pairs (i.e., one or more parameter values).)
receive, from an issuing processor of the set of issuing processors , over the communication network, a transaction authorization request for a transaction, the transaction authorization request including transaction data; (See at least Gupta, [0018-0019]; [0022-0025]; where a request for a transaction (i.e., a potential transaction) is received from an issuer (i.e., payment provider); the transaction authorization request including transaction data (i.e., information).)
establish a transaction record, including the transaction data (See at least Gupta, [0044] In such situations, information about the subscription or other multiuse purchase may be stored by the Account System in various ways so that the Transaction System 210 will later be able to determine that a payment transaction is authorized.);
compare, the transaction data to the rule data to determine whether a match occurs for the transaction data and the rule data; (See at least Gupta, [0026-0027]; [0042]; [0065] where the transaction data (i.e., information about the potential transaction) and the rule data (i.e., instruction rules) are compared to determine whether a match occurs for the transaction data and the rule data (i.e., when a compatibility is determined).)
transmit, the transaction data, wherein the system is configured to update an available balance based on the transaction data; (See at least Gupta, [0095]; [0024] This rule specifies that if the sender registers a dispute within 15 days of the transaction, an automatic refund will be issued; various information about the potential transaction can then be supplied to the transaction authorization system for automatic determination of whether the transaction is authorized .).)
monitor for expiration of the transaction authorization according to the transaction by comparing that a current time is greater than or equal to the transaction authorization expiration field (See at least Gupta, [0095]; [0126-0127]; [0171-0172]; [0135-0136]; [0153-0154]. E.g., This rule specifies that if the sender registers a dispute within 15 days of the transaction, an automatic refund will be issued; # recipient must allow dispute refunds for 10 days or more; SenderwinsTimeLimit>='l0 days';.)
and
transmit, an indication of expiration of the transaction authorization, the indication including the transaction identifier, wherein, the system is configured to reverse the update to the available balance, according to the transaction expiration. (See at least Gupta, [0095]; [0175]; [0181] The recipient specifies a dispute resolution policy that allows the sender to receive a 100% refund for up to ten days after the transaction date; The transaction authorizer also generates a Transaction ID that will be returned to the caller..)
Gupta does not explicitly disclose; however Thomas teaches the transaction record including a transaction authorization expiration field to specify an expiration of the transaction authorization; for a match occurrence, set the transaction authorization expiration field of the transaction record according to the expiration value; and monitor for expiration of the transaction authorization according to the transaction authorization expiration field of the transaction record;. (See at least Thomas, [0107-0108]; [0127]; For example, the resource manager 210 may place a hold on resources recorded in the resource pool 242 when the proposed transfer indicates that resources are to be transferred from the resource pool 242 to the resource pool 244, and a hold authorization from the party that owns the resource pool; As used herein a hold (or "lock") timeout refers to a specified amount of time that an intermediary will agree to have its resource held at a resource tracking system. If the transfer from the sending party to the receiving party does not complete before a lock timeout expires, the hold on the resources may be released, and the transfer may fail.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta and include Thomas’s teachings in order to reduce manual intervention and ensure consistent, automated enforcement in the time related rules.
The combination of Gupta and Thomas disclose a system where rules sets are received, receiving a potential transaction, determining combability between transaction information and rule sets and updating balances based on rules. (Gupta, [0030-0034]; [0025]; [0095]). However, Gupta does not explicitly disclose transmitting to a ledger the transaction data of the transaction and a ledger configured to update balances (e.g., reverse balances).
Liu, on the other hand teaches transmitting to a ledger the transaction data a ledger configured to update balances (e.g., reverse balances). (See at least Lui, [0033]; [0054]; [0088]; [0101]).
It would have been obvious to one of ordinary skill in the art at the time of the invention have transmitted the transaction data and to configure ledger to update balances (e.g., reverse balances) by including the ledger for communication with the system executing the system of Gupta, as in the improvement discussed in Liu in the system executing the system of Gupta. As in Liu, it is within the capabilities of one of ordinary skill in the art to attach and configure ledger functionality to Gupta’s transaction processing system, to securely update and reverse balances as needed in Gupta.
The combination of Gupta, Thomas and Liu does not explicitly disclose; however Gupta 613’ teaches; operate an authorization engine as middleware between a set of issuing processors having heterogeneous authorization message formats and a ledger system via a uniform interface that uses a standardized format, (See at least Gupta ‘613, claim 1; Col. 5 lines 43-67; receiving a request for transaction processing from the client device, wherein the request comprises one or more transaction parameters as submitted via a transaction form; (D) at a middleware service configured to communicate with the client device, receiving an indication of a security protocol supported by the client device; (E) transforming the request into a format supported by a backend transaction server, thereby generating a transformed request, wherein the transaction model of the transaction type specifies how to transform the one or more transaction parameters into the format supported by the backend transaction server)
translate, via an issuing processor integration interface, the transaction data from a heterogeneous authorization message format into the standardized format; (See at least Gupta ‘613, claim 1 receiving a request for transaction processing from the client device, wherein the request comprises one or more transaction parameters as submitted via a transaction form; (D) at a middleware service configured to communicate with the client device, receiving an indication of a security protocol supported by the client device; (E) transforming the request into a format supported by a backend transaction server, thereby generating a transformed request, wherein the transaction model of the transaction type specifies how to transform the one or more transaction parameters into the format supported by the backend transaction server)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the above combination and include Gupta 613’s teachings in order to use uniform format and configuration in the computing system.
Regarding claim 11: Gupta disclose: A method for configuring transaction authorization expiration, comprising:
receiving, at an authorization engine, rule data for defining an expiration for transaction authorizations, the rule data including one or more attribute fields, a set of one or more values for each of the one or more attribute fields, and an expiration value; (See at least Gupta, Fig. 1A; Fig. 1B; Fig 1D; [0021]; [0030-0034]; [0048]; [0054]; [0095] where rule data (i.e., usage instruction rule sets) for defining an expiration for transaction authorizations is received, the rule data including an expiration value (i.e., expiration date/ durationTimeLimit ) and one or more attribute field-value pairs (i.e., one or more parameter values).)
receiving, at the authorization engine, from an issuing processor, over a communication network, a transaction authorization request for a transaction, the transaction authorization
request including transaction data; (See at least Gupta, [0018-0019]; [0022-0025]; where a request for a transaction (i.e., a potential transaction) is received from an issuer (i.e., payment provider); the transaction authorization request including transaction data (i.e., information).)
establishing an electronic transaction record, including the transaction data and a transaction authorization expiration field to specify an expiration of the transaction authorization; (See at least Gupta, [0044] In such situations, information about the subscription or other multiuse purchase may be stored by the Account System in various ways so that the Transaction System 210 will later be able to determine that a payment transaction is authorized.);
comparing, by the authorization engine, the transaction data to the rule data to determine whether a match occurs for the transaction data and the rule data; (See at least Gupta, [0026-0027]; [0042]; [0065] where the transaction data (i.e., information about the potential transaction) and the rule data (i.e., instruction rules) are compared to determine whether a match occurs for the transaction data and the rule data (i.e., when a compatibility is determined).)
transmitting, by the authorization engine, the transaction data, wherein the system is configured to update an available balance based on the transaction data; ; (See at least Gupta, [0095]; [0024] This rule specifies that if the sender registers a dispute within 15 days of the transaction, an automatic refund will be issued; various information about the potential transaction can then be supplied to the transaction authorization system for automatic determination of whether the transaction is authorized).
monitoring for expiration of the transaction authorization according to the transaction authorization expiration field of the transaction record by comparing that a current time is greater than or equal to the transaction authorization expiration field; (See at least Gupta, [0095]; [0126-0127]; [0171-0172]; [0135-0136]; [0153-0154]. E.g., This rule specifies that if the sender registers a dispute within 15 days of the transaction, an automatic refund will be issued; # recipient must allow dispute refunds for 10 days or more; SenderwinsTimeLimit>='l0 days';.)
upon transaction remaining pending at a current time corresponding to the transaction authorization expiration, effecting, by the authorization engine, expiration of the transaction authorization; (See at least Gupta, [0153-0157] where if the transaction remains pending at a current time corresponding to the transaction authorization expiration (i.e., TransactionDate<='2004-Oct-1 ') effecting, by the authorization engine, expiration of the transaction authorization (e.g., when token expires after Oct. 1, 2004.)
transmitting, by the authorization engine, in indication of expiration of the transaction authorization, wherein system is configured to reverse the update to the available balance, according to the transaction authorization expiration. (See at least Gupta, [0095]; [0175] The recipient specifies a dispute resolution policy that allows the sender to receive a 100% refund for up to ten days after the transaction date.)
Gupta does not explicitly disclose; however Thomas teaches according to a match, setting a transaction authorization expiration to the expiration value. See at least Thomas, [0107-0108]; [0127]; For example, the resource manager 210 may place a hold on resources recorded in the resource pool 242 when the proposed transfer indicates that resources are to be transferred from the resource pool 242 to the resource pool 244, and a hold authorization from the party that owns the resource pool; As used herein a hold (or "lock") timeout refers to a specified amount of time that an intermediary will agree to have its resource held at a resource tracking system. If the transfer from the sending party to the receiving party does not complete before a lock timeout expires, the hold on the resources may be released, and the transfer may fail.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta and include Thomas’s teachings in order to reduce manual intervention and ensure consistent, automated enforcement in the time related rules.
The combination of Gupta and Thomas disclose a system where rules sets are received, receiving a potential transaction, determining combability between transaction information and rule sets and updating balances based on rules. (Gupta, [0030-0034]; [0025]; [0095]). However, Gupta does not explicitly disclose transmitting to a ledger the transaction data of the transaction and a ledger configured to update balances (e.g., reverse balances).
Liu, on the other hand teaches transmitting to a ledger the transaction data a ledger configured to update balances (e.g., reverse balances). (See at least Lui, [0033]; [0054]; [0088]; [0101])
It would have been obvious to one of ordinary skill in the art at the time of the invention have transmitted the transaction data and to configure ledger to update balances (e.g., reverse balances) by including the ledger for communication in the system of Gupta, as in the improvement discussed in Liu. As in Liu, it is within the capabilities of one of ordinary skill in the art to attach and configure ledger functionality to Gupta’s transaction processing system, to securely update and reverse balances as needed in Gupta.
The combination of Gupta, Thomas and Liu does not explicitly disclose; however Gupta 613’s teaches; translating, via an issuing processor integration interface, the transaction data from a heterogeneous authorization message format into the standardized format; (See at least Gupta ‘613, claim 1; Col. 5 lines 43-67; receiving a request for transaction processing from the client device, wherein the request comprises one or more transaction parameters as submitted via a transaction form; (D) at a middleware service configured to communicate with the client device, receiving an indication of a security protocol supported by the client device; (E) transforming the request into a format supported by a backend transaction server, thereby generating a transformed request, wherein the transaction model of the transaction type specifies how to transform the one or more transaction parameters into the format supported by the backend transaction server)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the above combination and include Gupta 613’s teachings in order to use uniform format and configuration in the computing system.
Regarding claims 2 and 12: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the method of claims 1 and 11. The combination further disclose comprising instructions which, when executed by the one or more processors, cause the system to:
receive, the updated available balance; and (See at least Gupta, [0182-0186] $50.00 from the sender's bank account; account balances are updated in the course of executing the above transaction.)
receive, the available balance with the update reversed. (See at least Gupta, [0095]; [0174]; [0182-0186]; an automatic refund will be issued.)
However, Gupta does not specifically disclose receive updated balances from a ledger system.
Liu, on the other hand teaches, receive updated balances from a ledger system (i.e., blockchain). (See at least Liu, [0054]).
It would have been obvious to one of ordinary skill in the art at the time of the invention have transmitted the transaction data and to configure ledger to update balances (e.g., reverse balances) by including the ledger for communication in the system of Gupta, as in the improvement discussed in Liu. As in Liu, it is within the capabilities of one of ordinary skill in the art to attach and configure ledger functionality to Gupta’s transaction processing system, to securely update and reverse balances as needed in Gupta.
Regarding claims 4 and 14: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose wherein the rule data further includes one or more of set logic and Boolean logic for combining attribute field-value pairs, wherein the comparing the transaction data to the rule data to determine whether a match occurs is according to the one or more of the set logic and Boolean logic. (See at least Gupta, Fig. 1B; Fig. 1E; [0189]; [0189]; [0196] Boolean expressions and logical operators.)
Regarding claims 6 and 16: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose wherein the comparing, by the authorization engine, the transaction data to the rule data comprises comparing each value of the set of one or more values of the one or more attribute fields to corresponding attribute data of the transaction data to determine whether a match occurs. (See at least Gupta, [0022]; [0026]; [0042]; [0147] whether one or more corresponding rules in the other instruction rule set(s) match or are otherwise compatible with the rule; TransactionAmount<='USD 50'; The sender is limiting the amount of each transaction
to $50. This does not limit the total usage of the token).
Regarding claims 7 and 17: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose wherein the expiration value is one of: a point in time, a time period, or a duration. (See at least Gupta, [0095] it’s a time period and/or duration e.g., duration SenderWinsTimeLimit :- '15 days').
Regarding claims 8 and 18: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose comprising instructions which, when executed by the one or more processors, cause the system to provide a user interface to a client computing device, for presenting to a user, the user interface to receive and transmit to the authorization engine the rule data. (See at least Gupta, Fig. 1 item 224; [0034]; [0039] In addition, usage instruction rule sets and their rules can be created in various ways in various embodiments, such as interactively via a graphical user interface ("GUI") provided by the transaction authorization system; including defining usage
instruction rule sets for use with the account. In some embodiments, the routine may be implemented as part of an interactive user interface with which a user can interact.)
Regarding claim 9: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose wherein the attribute field-value pairs each comprise an attribute field and a set of one or more values that correspond to the attribute field. (See at least Gupta, Fig. 1D; [0170]; [0179] e.g., attribute field:=value; number SenderwinsFractionLimit:=100%; SenderWinsTimeLimit:=10 days. And in Fig. 1B attribute field would be “Dispute Time Window” and the value “30days”.)
Regarding claims 10 and 20: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose wherein monitoring for expiration of the transaction comprises considering a status of the transaction. (See at least Gupta, [0095]; where monitoring for expiration of the transaction comprises considering the transaction expiration relative to a current time (i.e., duration SenderWinsTimeLimit :- '15 days; This rule specifies considering a status of the transaction (i.e., refund or no automatic refund).)
Regarding claim 19: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the method of claim 11. The combination further disclose wherein a given attribute field of the one or more attribute fields is one of: merchant name.(See at least Gupta, Fig. 1B; Fig. 1E. AllowedPayers; DisallowedPayers; e.g., the attribute field is: Payer and the value is Company XYZ).
Claim(s) 3 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Thomas, Liu and Gupta ‘613 as applied to claims 1 and 11 above, and further in view of Manapat et al. (US 10,867,303 B1), “Manapat”.
Regarding claims 3 and 13: The combination of Gupta, Thomas, Liu and Gupta ‘613 disclose the system of claim 1 and the method of claim 11. The combination further disclose:
receive at the authorization engine, over a communication network, a default expiration value; and (See at least Gupta, [0052]; instruction rule set has a specified expiration date).
However, the combination does not explicitly disclose according to a match not occurring, set a transaction authorization expiration to the default expiration value.
Manapat, on the other hand teaches than it was known in the art if a match fails to occur, set a default rule (e.g., transaction authorization expiration to the default expiration value). (See at least Manapat, Col. 9 lines 5-15 However, where a rule exists and matches the conditions associated with the transaction in question then the system will apply the action specified by the user rule by overriding the default system behavior to either accept or reject the transaction).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine teaching of Gupta in view of Liu to Manapat in order to improve system reliability by ensuring that the system behaves in a secure way when no specific rule applies.
Claim(s) 5 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta, Thomas, Liu and Gupta ’613 as applied to claims 1 and 11 above, and further in view of Roe et al. (US 2012/0221397 A1), “Roe”.
Regarding claims 5 and 15: The combination of Gupta, Thomas, Liu and Gupta 613 disclose the system of claim 1 and the method of claim 11. The combination further disclose component retrieves stored information about the usage instruction rule sets that correspond to the reference tokens and determines whether those usage instruction rule sets are satisfied for the potential transaction under the current conditions. Gupta further disclose a data retrieved including available balance. Gupta, [0065]; [0113]. However, the combination does not explicitly disclose compare, by the authorization engine, the transaction data to an available balance to determine an authorization status; and transmit, by the authorization engine, to the issuing processor, the authorization status.
Roe, on the other hand teaches a known technique of compare, by the authorization engine, the transaction data to an available balance to determine an authorization status; and transmit, by the authorization engine, to the issuing processor, the authorization status. (See at least Roe, Abs.; [0009]; [0034]; claim 3; where the transaction data (i.e., bank account data) is compared to an available balance (i.e., available balance) to determine authorization status; and the authorization status (i.e., authorization for the transaction) is transmitted to an issuing processor (i.e., to the account server).)
One of ordinary skill in the art would have recognized that applying the known technique of Roe would have yielded predictable results and resulted in an improved system. It would have been recognized that applying the technique of comparing available balance and transmitting authorization, as taught by Roe to the teachings of the combination of Gupta and Liu would have yielded predictable results because the level of ordinary skill in the art demonstrated by the references applied shows the ability to incorporate such features into similar systems. Further, applying the functionality of comparing available balance and transmitting authorization to the above combination, would have been recognized by those of ordinary skill in the art as resulting in an improved system that ensures transaction validity based on funds available.
Response to Arguments
Rejections Under 35 U.S.C. § 101
Applicant's arguments with respect to the 101 rejection, filed on 03/31/2026 have been fully considered and they are found persuasive. Specifically, Applicant argues claims recite a middleware authorization engine that handles electronic authorization communications between different types of computing systems ( e.g. the set of issuing processors and the ledger system) and interfaces with a third system (a user system) to enable configurable authorization expiration in an electronic payments ecosystem, which conserves resources within and improves that ecosystem. This simply is not an abstract idea”. Amendment, p. 10. Applicant further asserts “The Applicant respectfully submits that, for at least these foregoing reasons, claims 1 and 11 recite elements (specific data structures) and a specific data structure architecture that conserve memory and processing resources, which are technical improvements to secure electronic payment network technology and/or to the functioning of a computer system(s) implementing the same, which integrates any abstract idea into a practical application of the abstract idea under Step 2A, Prong 2. Accordingly, the Applicant respectfully submits that claims 1 and 11, and all claims dependent thereon, are patent eligible and should be found allowable”. Amendment, p. 16. Examiner agrees. The claims rejections under 35 USC 101 are withdrawn based on the claims amendments and the Applicants arguments.
Rejections Under 35 U.S.C. § 103
Applicant argues that the prior art does not teach, suggest or disclose "an authorization engine as middleware between a set of issuing processors ... and a ledger system .... ". and "translating, via an issuing processor integration interface, the transaction data from a heterogeneous authorization message format into the standardized format. Amendment, p. 18. Examiner agrees. However, upon further consideration of the newly introduced language, a new ground(s) of rejection is made in view of Gupta, Thomas, Liu and Gupta 613’.
Applicant argues that the Office Action erroneously asserts that Gupta discloses "rule data for defining an expiration for transaction authorizations. Specifically, Applicant asserts that the expiration of a rule teaches nothing about whether a transaction authorization remains valid or expires. Examiner respectfully disagrees. Gupta discloses where rule data (i.e., usage instruction rule sets) for defining an expiration for transaction authorizations is received, the rule data including an expiration value (i.e., expiration date/durationTimelimit). Furthermore, Thomas teaches whether a transaction authorization remains valid or expires (See at least Thomas, [0107-0108]; [0127]; For example, the resource manager 210 may place a hold on resources recorded in the resource pool 242 when the proposed transfer indicates that resources are to be transferred from the resource pool 242 to the resource pool 244, and a hold authorization from the party that owns the resource pool; As used herein a hold (or "lock") timeout refers to a specified amount of time that an intermediary will agree to have its resource held at a resource tracking system. If the transfer from the sending party to the receiving party does not complete before a lock timeout expires, the hold on the resources may be released, and the transfer may fail.)
Applicant asserts that Thomas does not teach suggest, or otherwise disclose "a transaction record including a transaction authorization expiration field ... ," and "set[ting] the transaction authorization expiration field ... according to the expiration value,". Specifically, Applicant asserts that the holds/locks of Thomas do not describe a transaction record that includes a transaction authorization expiration field that can be set (or configured) according to rule data. Amendment p. 19-20. Examiner respectfully disagrees. Thomas disclose a transaction record that includes a transaction authorization expiration field (e.g., the hold on the resources may be released, and the transfer may fail ) that can be set (or configured) according to rule data (e.g., timeout).) (See at least Thomas, [0107-0108]; [0127]
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARLYANNIE M GARCIA whose telephone number is (571)272-6950. The examiner can normally be reached Monday - Friday 7:30am - 4:30-pm.
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, Patrick McAtee can be reached at (571) 272-7575. 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.
/K.G.M/Examiner, Art Unit 3698
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698