DETAILED ACTION
This is an office action on the merits in response to the communication filed on 7/31/2025.
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 .
Claims’ Status
Claims 1-37 are cancelled. Claims 38-44 are newly added claim. Claims 38-44 are pending and are considered in this office action.
Response to Arguments/Comments
101 Rejection
In view of a new set of amended claims, please see the new rejection below.
103 Rejection
Applicant’s argument is moot in light of new arts and new grounds of rejection due to a newly submitted set of claims.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 38-44 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claim 38 recites “concurrently with requesting the first transfer, performing a pre-authorization charge on a second account of the account holder in an amount at least equal to the transaction amount, without capturing the funds from the second account at this stage.” This limitation describes both the first and second transfer would happen concurrently, however the specification does not provide support for such description. Claim 38 also recites “…..automatically requesting via a second network a second funds transfer of the pre-authorized amount from the second account to the merchant,…”, “automatically requesting” can be a unique step by itself, however the specification does not provide support for such description.
Claim 39 recites “…..the timestamp is a Coordinated Universal Time value retrieved from a secure system clock of the device”, however there is no support from the specification for this particular limitation.
Claim 40 recites “encrypting at least one of the geographic location or the timestamp before writing the encrypted value into one or more EXIF header fields of the virtual-check image”, however there is no support from the specification for this particular limitation.
Claim 41 recites “…..the pre-authorization is placed through a card-network authorization request that reserves, but does not capture, at least the transaction amount”, however there is no support from the specification for this particular limitation.
Claim 42 recites “…..transmitting a reversal message to the card network to release the pre-authorization hold upon determining that the first funds transfer was successfully completed within the predetermined time period”, however there is no support from the specification that teaches “transmitting a reversal message to the card network.”
Claim 43 recites “the predetermined time period during which the status of the first funds transfer is monitored is defined by an automated clearing house (ACH) settlement rule stored in a configuration file of the payment-processing system”, however there is no support from the specification that teaches “ACH rule stored in a configuration file of the payment-processing system.
Claim 44 recites “….querying a routing- number participation database that identifies financial institutions enabled for the Real- Time Payments (RTP) network and routing the first funds transfer through the RTP network only when the routing number of the first account is present in the participation database”, however there is no support from the specification for this particular limitation.
Corrections are required.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 38 recites the limitation “….embedding at least a portion of said metadata into the image file of the virtual check.” Claim 38 also recites “monitoring the status of the first funds transfer for a predetermined time period to determine whether the first transfer is successfully completed or fails to complete within said time period.” There are insufficient antecedent basis for “the image file” and “the status” in the limitation.
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 38-44 are rejected under 35 U.S.C. 101 because the claimed invention is not directed to patent eligible subject matter. The claimed matter is directed to a judicial exception (i.e. an abstract idea not integrated into a practical application) without significantly more.
Step 1 (The Statutory Categories): Is the claim to a process, machine, manufacture or composition of matter? MPEP 2106.03
Per Step 1, claims 38 is directed to a method claim. Thus, independent claim 38 is directed to statutory subject matter.
However, independent claims 38-44 are rejected under 35 U.S.C. 101 because the claims recite an abstract idea, a judicial exception, without reciting additional elements that integrate the judicial exception into a practical application.
Independent claim recites:
Claim 38:
receiving, from a user, a request to perform a transaction with a merchant; generating a virtual check for the transaction, the virtual check including at least a checking account number, a bank routing number, and a date; displaying the virtual check on a display of an electronic device associated with the user or the merchant; receiving user input corresponding to one or more check fields of the virtual check; automatically generating, in real time, transaction metadata including at least a geographic location and a timestamp of the virtual check's creation, and embedding at least a portion of said metadata into the image file of the virtual check by writing the metadata into one or more exchangeable image file format (EXIF) fields of the virtual check image ;populating the virtual check with the received user input in the respective check fields; initiating a deposit of the virtual check by transmitting the virtual check image for payment processing; in response to said deposit initiation, requesting via a first network a first funds transfer of a transaction amount from a first account of the account holder, wherein the first network is an automated clearing house (ACH) network or a mobile remote deposit capture (mRDC) network ;concurrently with requesting the first transfer, performing a pre-authorization charge on a second account of the account holder in an amount at least equal to the transaction amount, without capturing the funds from the second account at this stage; monitoring the status of the first funds transfer for a predetermined time period to determine whether the first transfer is successfully completed or fails to complete within said time period; upon determining that the first transfer has not completed successfully within said predetermined time or has been rejected, automatically requesting via a second network a second funds transfer of the pre-authorized amount from the second account to the merchant, thereby capturing the pre-authorized funds to settle the transaction; upon determining that the first transfer was successfully completed within said predetermined time, releasing or voiding the pre-authorization hold on the second account such that the second account is not charged; and wherein prior to requesting the first funds transfer, the method further includes determining whether the first account is eligible for processing via a real-time payment network, and if so, routing the first funds transfer through a real-time payments (RTP) network for substantially immediate settlement based on the bank routing number of the first account, thereby obviating the need for the second funds transfer if the real- time payment is confirmed.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon MPEP 2106.04).
The limitations, as drafted, constitute a process that, under its broadest reasonable interpretation, covers managing, 1) Commercial interactions in the form of business relation; 2) Fundamental economic principle, under the Certain methods of organizing human activity, but for the recitation of generic computer components. The abstract idea, recited above, includes: receiving a request to perform a transaction with a merchant; generating a virtual check for the transaction; displaying the virtual check on a display of an electronic device associated with the user or the merchant; receiving user input corresponding to one or more check fields of the virtual check; populating the virtual check with the received user input in the respective check fields; initiating a deposit of the virtual check by transmitting the virtual check image for payment processing; in response to said deposit initiation, requesting via a first network a first funds transfer of a transaction amount from a first account of the account holder; concurrently with requesting the first transfer, performing a pre-authorization charge on a second account of the account holder in an amount at least equal to the transaction amount, without capturing the funds from the second account at this stage; monitoring the status of the first funds transfer for a predetermined time period to determine whether the first transfer is successfully completed or fails to complete within said time period; upon determining that the first transfer has not completed successfully within said predetermined time or has been rejected, automatically requesting via a second network a second funds transfer of the pre-authorized amount from the second account to the merchant; upon determining that the first transfer was successfully completed within said predetermined time, releasing or voiding the pre-authorization hold on the second account such that the second account is not charged; and determining whether the first account is eligible for processing via a real-time payment network, and if so, routing the first funds transfer through a real-time payments (RTP) network for substantially immediate settlement based on the bank routing number of the first account,. If a claim limitation, under its broadest reasonable interpretation, covers performance of limitations commercial interactions, but for the recitation of generic computer components, it falls within the Certain Methods of Organizing Human Activity – 1) Commercial interactions; 2) Fundamental economic principle, grouping of abstract ideas. Accordingly, the claim recites an abstract idea.
Step 2A Prong 2: Does the claim recite additional elements that integrate the judicial exception into a practical application? MPEP 2106.04.
The recited computing elements (claim 38: “RTP network”) is recited at a high-level of generality, i.e. as generic computing element performing generic computer functions such that it amounts to no more than mere instructions to apply the exception using generic computer components (see MPEP 2106.05(f)). Simply adding a general purpose computer or computer components after the fact to an abstract idea does not integrate a judicial exception into a practical application or provide significantly more, since it amounts to no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer, as set forth in MPEP 2106.05(f).
The additional positive elements are: “automatically generating, in real time, transaction metadata including at least a geographic location and a timestamp of the virtual check's creation, and embedding at least a portion of said metadata into the image file of the virtual check by writing the metadata into one or more exchangeable image file format (EXIF) fields of the virtual check image” in claim 38; which amounts to linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Furthermore, the dependent claims such as encrypting/decrypting steps are recited at very high level without any specificity and does not turn abstract idea into practical application.
Accordingly, these additional claim elements, alone and in combination do not integrate the abstract idea into a practical application, because (1) they do not effect improvements to the functioning of a computer, or to any other technology or technical field (see MPEP 2106.05(a)); (2) they do not apply or use the abstract idea to effect a particular treatment or prophylaxis for a disease or a medical condition (see the Vanda memo); (3) they do not apply the abstract idea with, or by use of, a particular machine (see MPEP 2106.05(b)); (4) they do not effect a transformation or reduction of a particular article to a different state or thing (see MPEP 2106.05(c)); (5) they do not apply or use the abstract idea in some other meaningful way beyond generally linking the use of the identified abstract idea to a particular technological environment, such that the claim as a whole is more than a drafting effort designated to monopolize the exception (see MPEP 2106.05(e) and the Vanda memo). Therefore, per Step 2A, Prong Two, the claim is directed to an abstract idea not integrated into a practical application.
Step 2B (The Inventive Concept): Does the claim recite additional elements that amount to significantly more than the judicial exception? MPEP 2106.05.
Step 2B of the eligibility analysis concludes that the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception. Examiner carries over the analysis from Step 2A related to the generic computing elements being no more than a recitation of the words "apply it" (or an equivalent) to implement an abstract idea or other exception on a computer (MPEP 2106.05(f)). The additional claim elements that are just “applying it” or “generally linking the use of the judicial exception to a particular technological environment or field of use” are mere instructions to implement an abstract idea on a computer, are carried over for further analysis in Step 2B.
When the independent claims are considered as a whole, as a combination, the claim elements noted above do not amount to any more than they amount to individually. The operations appear to merely apply the abstract concept to a technical environment in a very general sense. The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified as an abstract idea. Therefore, it is concluded that the elements of the independent claims are directed to one or more abstract ideas and do not amount to significantly more. (MPEP 2106.05)
Further, Step 2B of the analysis takes into consideration all dependent claims as well, both individually and as a whole, as a combination:
Claims 39, 40 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 38 since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. For example, claim 39 describes ; claim 40 describes encrypting geographic location or the timestamp data; claim 42 describes transmitting a reversal message to the card network to release the pre-authorization hold; claim 43 describes having a ACH rule stored in a configuration file; claim 44 on querying a routing-number participation database, which all of the limitation are narrowing the steps performed in claim 38.
Claim 41 is directed to nonfunctional descriptive material. While these descriptive elements may provide further helpful context for the claimed invention, these elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not significantly more than the abstract concept at the core of the claimed invention. Claim 41 describes the second account is a credit-card account; etc. The claims do not, for example, purport to improve the functioning of the computer itself. Nor do they effect an improvement in any other technology or technical field. Therefore, based on case law precedent, the claims are claiming subject matter similar to concepts already identified by the courts as dealing with abstract ideas. See Alice Corp. Pty. Ltd., 573 U.S. 208 (citing Bilski v. Kappos, 561, U.S. 593, 611 (2010)).
Moreover, the claims in the instant application do not constitute significantly more also because the claims or claim elements only serve to implement the abstract idea using computer components to perform computing functions (Enfish, see MPEP 2106.05(a)). Specifically, the computing system encompasses general purpose hardware and software modules.
The most significant elements of the claims, that is the elements that really outline the inventive elements of the claims, are set forth in the elements identified in the independent claims as an abstract idea. The fact that the associated computing devices or payment networks are facilitating the abstract concept is not enough to confer statutory subject matter eligibility. In sum, the additional elements do not serve to confer subject matter eligibility to the invention since their individual and combined significance is still not heavier than the abstract concepts at the core of the claimed invention. Therefore, it is concluded that the dependent claims of the instant application do not amount to significantly more either. (see MPEP 2106.05)
In sum, claims 38-44 are rejected under 35 USC 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
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 of this title, 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 set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied 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 38 are rejected under 35 U.S.C 103 as obvious over in view of Thiele et al. (US9619789B1) in view of Nosek (US7191151B1) in view of Jarvis et al. (US20220277086A1), and further in view of Singh et al. (US20200327543A1).
With respect to claim 38
Thiele teaches:
generating a virtual check for the transaction, the virtual check including at least a checking account number, a bank routing number, and a date (see fig.3 & col.4 ln14 – col.5 ln 43);
displaying the virtual check on a display of an electronic device associated with the user or the merchant (col.4 ln14 –ln19, FIG. 3 illustrates one side of a virtual check 300, which can be created on the mobile device 102 in an example. The virtual check 300 is displayed as an image on the mobile device 102, either while the virtual check 300 is being created or after the data is entered by the user or application for proofing and sending to the check receiver.);
receiving user input corresponding to one or more check fields of the virtual check (see col.7 ln44 – ln47, at 606, the payor must complete certain data fields and verify the automatically populated data. Some fields that require the payor to enter data include the payment amount, payee name, and the payor's signature.);
automatically generating, in real time, transaction metadata including at least a geographic location and a timestamp of the virtual check's creation; and… (see col.1 ln41-ln44, In an example, creating the virtual check image includes generating tag data that includes at least one of check creation time, check creation date, and physical location of check creation; see also claim 1, receiving, from a mobile device comprising a position sensor and associated with a payor, information for a virtual check created in real-time in the mobile device associated with the payor, the information including an amount of the virtual check and a location indicating where the virtual check was created or sent from);
populating the virtual check with the received user input in the respective check fields (see col.1 ln48-ln51, In an example, creating the virtual check image includes automatically populating tag data with data stored in the payor device. In an example, creating the virtual check image includes automatically populating check data fields with data stored in the payor device.);
initiating a deposit of the virtual check by transmitting the virtual check image for payment processing (col.2 ln12-ln13, In an example, the method uploads the virtual check image to a bank for deposit.);
in response to said deposit initiation, requesting via a first network a first funds transfer of a transaction amount from a first account of the account holder, wherein the first network is an automated clearing house (ACH) network or a mobile remote deposit capture (mRDC) network (col.9 ln28-ln34, At 638, the virtual check is reconciled with the payor's bank. This can be done through Automated Clearing House (ACH), Clearing House Interbank Payment System (CHIPS), or Society for Worldwide Interbank Financial Telecommunication (SWIFT). The funds represented by the check are withdrawn from the payor's account and deposited in the last receiver's account.);
Thiele doesn’t explicitly disclose, but Nosek teaches:
receiving, from a user, a request to perform a transaction with a merchant (col.2 ln36-ln38, In this embodiment of the invention, the system receives a request from a receiver to conduct a transaction involving a first value.)
concurrently with requesting the first transfer, performing a pre-authorization charge on a second account of the account holder in an amount at least equal to the transaction amount, without capturing the funds from the second account at this stage (col.2 ln38-ln52, The transaction may involve the payment or transfer of funds to another entity (e.g., a merchant) or the receiver's own account with the system. The system authorizes the first value against a credit source (e.g., a credit card, credit line) associated with the receiver, which may be a credit line established for the receiver by the system. The system then places a hold against the credit source for the first value, in order to hold that amount for the system to charge, if necessary. The system then takes on the role of an ACH originator and initiates an ACH debit, in the amount of the first value, to retrieve it from an account the receiver has with a financial institution (e.g., bank, credit union, mutual fund, brokerage, savings and loan). If the ACH debit is rejected or returned, all or a portion of the first value may be charged against the credit source; col.4 ln12-ln14, In one alternative method of the invention, the funds may be charged against the credit source at the time the ACH entry is initiated);
monitoring the status of the first funds transfer for a predetermined time period to determine whether the first transfer is successfully completed or fails to complete within said time period (col.4 ln23-ln34, In a typical ACH debit process, the funds requested by the ODFI from the RDFI may be received within a few business days after the debit is initiated. Or, the ODFI may be notified that insufficient funds are available to complete the transaction. Even if the funds are received within a few days, however, they may be retracted by the RDFI if it determines that the receiver's account has insufficient funds. Thus, until a sufficient period of time passes for the RDFI to check for available funds (e.g., several business days), the ODFI risks making the funds available to or for the originator (e.g., to pay a bill, make a purchase, transfer them to another entity) and not recouping them from the RDFI.);
upon determining that the first transfer has not completed successfully within said predetermined time or has been rejected, automatically requesting via a second network a second funds transfer of the pre-authorized amount from the second account to the merchant, thereby capturing the pre-authorized funds to settle the transaction (In state 222, the user's credit source is charged the amount that failed to clear through the ACH process. Thus, if the entire transaction failed, the full amount of the payment/transfer may be charged. Otherwise, if a portion of the funds is received, the remaining funds are charged. The procedure then ends.)
upon determining that the first transfer was successfully completed within said predetermined time, releasing or voiding the pre-authorization hold on the second account such that the second account is not charged (col.8 ln12-ln21, In state 220 the system determines whether the ACH transaction is rejected or returned. Return of an ACH debit (e.g., because of insufficient funds in the receiver's account) may take a variable amount of time, but if not received within a threshold period (e.g., several days), the system may assume that the transaction succeeded. If the transaction is a success, the system may use the received funds to replace those released to/for the user. Further, the system may cancel the hold that was placed on the user's credit source or, alternatively, may just allow it to expire.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Thiele with the teaching of Nosek as they relate to a system/method of managing payment transaction data. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the system of Thiele, for example initiating a check deposit process in Thiele, to include a method of putting a hold on a credit account as taught by Nosek for the predicated result of an improved and secured fund settlement process.
Thiele in view of Nosek do not explicitly disclose, but Jarvis teaches:
…….embedding at least a portion of said metadata into the image file of the virtual check by writing the metadata into one or more exchangeable image file format (EXIF) fields of the virtual check image ([0056], In some examples, the first image file 511 can include the set of pixels. For example, the set of pixels of the first image file 511 can indicate a check with payee “John Doe,” an amount of “1,000.00”, a date of “9/30/2020”, a check number of “1936”, and other information, such as routing number and bank account; see also [0016], A document can be a file including text content, image or graphic content, audio content, video content, or any other digital contents. A document can be a file converted from a non-digital document, e.g., a paper document, or a file generated by a computer. A document can be in any of the file format, e.g., a word processing format including doc format, PDF format; an image format including joint photographic experts group (JPEG) related format, exchangeable image file format (Exif), tagged image file format (TIFF), graphics interchange format (GIF), portable network graphics (PNG) format, WebP format, or other image format; see also fig.3A-3C and [0038], For example, the first image file 301 can optionally include file header, marker, and metadata, which are not shown.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Thiele/ Nosek with the teaching of Jarvis as they relate to a system/method of managing payment transaction data. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Thiele/ Nosek, for example initiating a check deposit process in Thiele, to include a method of embedding check metadata using EXIF format in a virtual check as taught by Jarvis for the predicated result of an improved and secured fund settlement process.
Thiele in view of Nosek in view of Jarvis do not explicitly disclose, but Singh teaches:
wherein prior to requesting the first funds transfer, the method further includes determining whether the first account is eligible for processing via a real-time payment network ([0010], a payments computer serves as a trusted repository of transaction data to facilitate payment transactions via a real-time payment network. The bank (acquirer) for a payment requestor (party desiring to receive a payment), provides transaction data to the payments computer. The payments computer generates a unique transaction identifier, provides it to the acquirer, and stores the transaction data in association with the transaction data. The acquirer provides the transaction identifier to the payment requestor. Using a standard message format, the payment requestor submits the transaction identifier in a request for payment to the payer's bank. The payer's bank authenticates the payer and messages the payments computer with the transaction identifier to retrieve the transaction data. Based on the transaction data, the payer's bank presents transaction details to the payer for confirmation, and then initiates a transaction in a real-time payment network to credit the account of the payment requestor.);
if so, routing the first funds transfer through a real-time payments (RTP) network for substantially immediate settlement based on the bank routing number of the first account, thereby obviating the need for the second funds transfer if the real- time payment is confirmed ([0055-0056], the payment requestor 114 (FIG. 1) may be an e-commerce merchant, and the process of FIGS. 6A and 6B may entail a payment to consummate an online purchase transaction. ……The ensuing discussion assumes that the merchant/payment requestor and the acquirer have been enrolled and brought “on board” to the payment system 100. The onboarding process may include obtaining the following information: merchant name, acquirer ID, merchant ID, the bank account number and bank routing number for either or both of the merchant's bank account and the acquirer bank account, along with any other information required for processing in the real-time payment network 104; see also [0071], The payer's bank 106 now proceeds with the requested payment. At block 636, the payer's bank 106 debits the transaction amount from the payer's account. At block 638, the payer's bank sends an instruction to the real-time payment network 104 to transfer the transaction amount to the account of the payment requestor 114 or the acquirer 108, as the case may be, for the benefit of the payment requestor 114. With this process, the payment requestor may immediately receive the funds paid for the online purchase transaction referred to at blocks 602-606 (FIG. 6A).)
This portion of the limitation “thereby obviating the need for the second funds transfer if the real- time payment is confirmed” is merely recited as intended use. This portion is given little to no patentable weight because the limitation, or portion thereof, does not claim the function(s) as being positively recited actions or functions, and/or it does not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being “for … [performing a specific functionality]”, etc. does not mean that the functions are required to be performed, or are actually performed.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Thiele/ Nosek/Jarvis with the teaching of Singh as they relate to a system/method of managing payment transaction data. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Thiele/ Nosek/Jarvis, for example initiating a check deposit process in Thiele, to include a method of using real-time payment network for fund transfer as taught by Singh for the predicated result of an improved and secured fund settlement process.
With respect to claim 39
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 38. Thiele further teaches: wherein the geographic location is obtained from a global positioning system (GPS) receiver of the electronic device and the timestamp is a Coordinated Universal Time value retrieved from a secure system clock of the device (see col.1 ln41-ln44,In an example, creating the virtual check image includes generating tag data that includes at least one of check creation time, check creation date, and physical location of check creation; col.6 ln36-ln38, Field 511 stores the location where the check was created. In an example, the mobile device includes a GPS or other position sensors and stores position data in field 511; see also claim 1, receiving, from a mobile device comprising a position sensor and associated with a payor, information for a virtual check created in real-time in the mobile device associated with the payor, the information including an amount of the virtual check and a location indicating where the virtual check was created or sent from)
With respect to claim 40
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 38. Thiele further teaches: further comprising encrypting at least one of the geographic location or the timestamp before writing the encrypted value into one or more EXIF header fields of the virtual-check image (col.6 ln36-ln38, Field 511 stores the location where the check was created. In an example, the mobile device includes a GPS or other position sensors and stores position data in field 511; col.8 ln57-ln60, At 631, the payor's bank's public encryption key is applied to at least one of the check image and check related data. In an example, the encryption can be done by symmetric key.)
With respect to claim 41
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 38. Nosek further teaches: wherein the second account is a credit-card account of the account holder and the pre-authorization is placed through a card-network authorization request that reserves, but does not capture, at least the transaction amount (col.2 ln40-ln43, The system authorizes the first value against a credit source (e.g., a credit card, credit line) associated with the receiver, which may be a credit line established for the receiver by the system; see col.5 ln41-45, After the user's account with institution 130 and credit source are verified, facilitator 112 may attempt to authorize and hold the requested amount of value against the user's credit source. This may be done through financial institution 110 or some other third party.)
With respect to claim 42
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 41. Nosek further teaches: further comprising transmitting a reversal message to the card network to release the pre-authorization hold upon determining that the first funds transfer was successfully completed within the predetermined time period (fig1A and col.5 ln41-ln49, After the user's account with institution 130 and credit source are verified, facilitator 112 may attempt to authorize and hold the requested amount of value against the user's credit source. This may be done through financial institution 110 or some other third party……. If this action succeeds, however, then the funds may be released as requested and the ACH process may be initiated to retrieve the funds from the user's account at institution 130.)
With respect to claim 44
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 38. Singh further teaches: wherein determining whether the first account is eligible for processing via a real-time payment network comprises querying a routing- number participation database that identifies financial institutions enabled for the Real- Time Payments (RTP) network and routing the first funds transfer through the RTP network only when the routing number of the first account is present in the participation database (see [0056 and 0068])
Claim 43 is rejected under 35 U.S.C 103 as obvious over in view of Thiele et al. (US9619789B1) in view of Nosek (US7191151B1) in view of Jarvis et al. (US20220277086A1) in view of Singh et al. (US20200327543A1), and further in view of Lawson et al. (US7930248B1).
With respect to claim 43
The combination of Thiele, Nosek, Jarvis, and Singh teaches the limitation of claim 38. The combination does not explicitly disclose, but Lawson teaches: wherein the predetermined time period during which the status of the first funds transfer is monitored is defined by an automated clearing house (ACH) settlement rule stored in a configuration file of the payment-processing system (col.34 ln12-col.35 ln20).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Thiele/ Nosek/Jarvis/Singh with the teaching of Lawson as they relate to a system/method of managing payment transaction data. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Thiele/ Nosek/Jarvis/Singh, for example initiating a check deposit process in Thiele, to include a method of storing ACH rule in a configuration file as taught by Lawson for the predicated result of an improved and secured fund settlement process.
Conclusion
THIS ACTION IS MADE FINAL, necessitated by amendments. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YIN Y CHOI whose telephone number is (571)272-1094 or yin.choi@uspto.gov. The examiner can normally be reached on M-F 7:30 - 5:30pm 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, Neha Patel can be reached on 571-270-1492. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YIN Y CHOI/Examiner, Art Unit 369911/3/2025
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699