DETAILED ACTION
This is an office action on the merits in response to the communication filed on 10/9/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, 9, and 17 are amended. Claims 1-20 are pending and are considered in this office action.
Response to Arguments/Comments
112 Rejection
Examiner still finds “out-of-band communication channel” being not supported by the specification. According to one of ordinary skilled in the art, i.e., Wikipedia definition, “out-of-band communication channel” describes as the exchange of call control information in a separate band from the data or voice stream, or on an entirely separate, dedicated channel. Out-of-band communication channel is a broad specific term which encompasses a broad range of different communication channels and has nothing to do with applicant’s description on “keeping the transaction in “pending” status until approved” (pg.10 of the Arguments/Remarks). As such, 112 rejection on the “out-of-band communication channel” is maintained.
101 Rejection
The specific network-control architecture is not unique in the context payment authorization and has long existed in the field, there is nothing special using the pre-authorization control nor behavioral-biometric telemetry to perform the any of the steps. These steps do not add significantly more than just linking the abstract idea to a technological environment because they do not amount to any technological improvement with respect to conducting secured electronic financial transactions. See the new 101 rejection below.
103 Rejection
Applicant’s argument is moot in light of a new art and new grounds of rejection due to amended claims.
In response to applicant's argument that the combination lacks the claims the claimed ordered architecture, the fact that the inventor has recognized another advantage which would flow naturally from following the suggestion of the prior art cannot be the basis for patentability when the differences would otherwise be obvious. See Ex parte Obiaya, 227 USPQ 58, 60 (Bd. Pat. App. & Inter. 1985).
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.
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 1, 9, and 17 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. Claims 1, 9, and 17 each recites “receiving, via an out-of-band communication channel comprising a text message or an application notification, a confirmation of the transaction from the account holder.” However, the specification does not directly provide support on “out-of-band communication channel.”
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention is 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, claim 1 is method claim; claim 9 is a system claim; and claim 17 is non-transitory storage medium claim. Thus, independent claims 1, 9, and 17 are directed to statutory subject matter.
However, independent claims 1, 9, and 17 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.
The abstract idea of the independent claims is (claims 1, 9, and 17 being similar in scope):
Claim 1:
identifying, by a computing system, a first payment source account held by an account holder and a second account held by the account holder; receiving, by the computing system, transaction data associated with a transaction initiated by the account holder with a merchant using the first payment source account, the transaction having a transaction amount; performing, by the computing system and prior to completion of the transaction, a pre-authorization charge of the second account in a pre-authorized amount equal to the transaction amount via a second network; receiving a virtual signature from the account holder and collecting, during the act of signing, metadata including at least pressure applied by the account holder, a speed of writing, and a sequence of characters; encrypting the virtual signature and the collected metadata using a symmetric or asymmetric encryption algorithm including at least one of AES or RSA, and storing the encrypted virtual signature and the metadata in a database; receiving, via an out-of-band communication channel comprising a text message or an application notification, a confirmation of the transaction from the account holder, and maintaining the transaction in a pending state until the confirmation is received; responsive to the confirmation, requesting, via a first network, a first transfer of the transaction amount from the first payment source account within a predetermined time; when the first transfer is not completed within the predetermined time, requesting, via the second network, a second transfer of the pre-authorized amount from the second account; and when the transaction amount is successfully transferred from the first payment source account within the predetermined time, releasing the pre-authorization charge of the second account; and completing payment to the merchant using funds from the first transfer or, when requested, from the second transfer; wherein the first network comprises an automated clearing house (ACH) network and the second network comprises a card network.
Step 2A Prong 1: Does the claim recite an abstract idea, law of nature, or natural phenomenon MPEP 2106.04, see also October 2019 Patent Eligibility Guidance Update (issued October 17, 2019) (“2019 PEG Update”).
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, are: identifying a first payment source account held by an account holder and a second account held by the account holder; receiving transaction data associated with a transaction initiated by the account holder with a merchant using the first payment source account; performing a pre-authorization charge of the second account in a pre-authorized amount equal to the transaction amount via a second network; receiving a virtual signature from the account holder and receiving, via an out-of-band communication channel comprising a text message or an application notification, a confirmation of the transaction from the account holder, and maintaining the transaction in a pending state until the confirmation is received; responsive to the confirmation, requesting a first transfer of the transaction amount from the first payment source account within a predetermined time; when the first transfer is not completed within the predetermined time, requesting a second transfer of the pre-authorized amount from the second account; and when the transaction amount is successfully transferred from the first payment source account within the predetermined time, releasing the pre-authorization charge of the second account; and completing payment to the merchant using funds from the first transfer or, when requested, from the second transfer; wherein the first network comprises an automated clearing house (ACH) network and the second network comprises a card network. 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, see also 2019 PEG Update.
The recited computing elements (claim 1: a computer system; a first network; a second network; claim 3: a ACH network; claim 9: “one or more processors”; and “one or more memories having stored thereon instructions; claim 17: “a non-transitory physical computer storage”) are 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: “collecting, during the act of signing, metadata including at least pressure applied by the account holder, a speed of writing, and a sequence of characters; encrypting the virtual signature and the collected metadata using a symmetric or asymmetric encryption algorithm including at least one of AES or RSA, and storing the encrypted virtual signature and the metadata in a database” in claim 1, 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, encrypting step is 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, i.e. a point of sale terminal. 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 2-8 are further directed to additional abstract ideas because the steps performed are simply narrowing the scope of the abstract idea of claim 1 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 2 further describes the steps of encrypting and storing the transaction data; claim 3 on charging a tip through ACH network; claim 4 on confirming and accepting terms of service; claim 5 on performing a reputation management comprising an on-line review; claim 6 populating an invoice with the decrypted signature; claim 7 on populating a credit card receipt with the decrypted signature; claim 8 on collecting/encrypting/storing meta data, which all of the limitation are narrowing the steps performed in claim 1.
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 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. The other dependent claims (claims 10-16 and 18-20), which are similar in scope to the dependent claims 2-8, are rejected for the same reason as above. 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 1-20 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 1, 2, 8-10, 16-18 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1), and further in view of Holden et al. (US20200082153A1).
With respect to claim 1, 9, and 17
Young teaches the limitations of:
receiving, by the computing system, transaction data associated with a transaction initiated by the account holder with a merchant using the first payment source account, the transaction having a transaction amount (col.3 ln32-ln37, The merchant server computing device 108 may communicate with merchant financial institution 112 or the individual financial institution 114 by way of the communications network 116 to send and receive information regarding transactions made at the point of sale device 106; see also col.2 ln56-ln58, FIG. 1, an individual 102 having a mobile computing device 104 may desire to make a purchase from a merchant 101; see also col.6 ln14-ln21, the individual 102 may use a web browser in the mobile computing device 104 to navigate to a bill payment website offered by the individual financial institution 114. Using the web browser and the bill payment website, the individual 102 may enter or upload information about the transaction to the individual financial institution 114, authorize the transaction, and/or receive confirmations regarding the transaction.);
receiving, via an out-of-band communication channel comprising a text message or an application notification, a confirmation of the transaction from the account holder (col.4 ln1-ln11, At 204, the payment to the merchant is authorized using the application on the mobile computing device. The application may include a “send” or “purchase” option that may be selected by the individual 102 to indicate that the transaction is authorized for payment to the merchant 101. The authorization may include a telephone number of the mobile computing device 104, an e-mail address associated with the individual 102, an Internet Protocol address, or other identifier such that an electronic message, telephone call, SMS message, etc. may be communicated to the mobile device 104 at a later time.), and maintaining the transaction in a pending state until the confirmation is received (col.4 ln42-ln47, At 214, it is determined if the confirmation is received. Using the mobile computing device 104, the user 102 may communicate a confirmation 120 to the individual financial institution 114 that the transaction is to be completed with the merchant 101. Only after receiving the confirmation 120, would the individual financial institution 114 send transaction approval information to the merchant server computing device 108 and transfer funds to the merchant financial institution 112.); responsive to the confirmation, requesting, via a first network, a first transfer of the transaction amount from the first payment source account (col.5 ln6-ln12, If the confirmation is not received, then the process ends at 216. However if a confirmation is received, then at 218, the individual financial institution transfers the funds to the merchant account at the merchant financial institution. The transfer funds may be accomplished using an ACH transfer, wire transfer, mailing the physical check, etc.)
Young doesn’t explicitly disclose, but Nosek teaches:
identifying, by a computing system, a first payment source account held by an account holder and a second account held by the account holder (col.2 ln56-ln60, In addition, if the user has verified multiple financial accounts (or other accounts from which ACH funds may be drawn) and/or multiple credit sources, the user may be prompted to select from the multiple accounts and/or credit sources.);
performing, by the computing system and prior to completion of the transaction, a pre-authorization charge of the second account in a pre-authorized amount equal to the transaction amount via a second network (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);
when the first transfer is not completed within the predetermined time, requesting, via the second network, a second transfer of the pre-authorized amount from the second account (col.8 ln12-ln30, 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. If the ACH process succeeds, after the funds are received and applied, the illustrated procedure ends. Otherwise, if the ACH process failed, the procedure continues at state 222. 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.); and when the transaction amount is successfully transferred from the first payment source account within the predetermined time, releasing the pre-authorization charge of the second account (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.);
completing payment to the merchant using funds from the first transfer or, when requested, from the second transfer; wherein the first network comprises an automated clearing house (ACH) network and the second network comprises a card network (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.)
requesting, via a first network, a first transfer of the transaction amount from the first payment source account within a predetermined time (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.);
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 Young 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 Young, for example managing payment transaction between a merchant and a customer, to include a method of putting a pre-authorization charge on a second account as taught by Nosek for the predicated result of an improved and secured fund settlement process.
Young in view of Nosek do not explicitly disclose, but Holden teaches:
receiving a virtual signature from the account holder and collecting, during the act of signing, metadata including at least pressure applied by the account holder, a speed of writing, and a sequence of characters ([0100], handwriting data can be represented as a sequence of pen events. Typically, a pen event records the position of the pen tip (e.g., while on the surface of or within a limited range of a digitizer) at a particular time. In addition to x/y-coordinate values, some handwriting input devices also may detect other information such as pen angle, writing speed, writing pressure, etc; see also [0206], raw handwriting data can be represented as a sequence of pen events (see FIG. 24). Typically, a pen event records the position of the pen tip (e.g., while on the surface of or within a limited range of a digitizer) at a particular time. Depending on device capabilities, pen data associated with pen events may include additional measurements such as pen pressure and angles. FIG. 24 is an illustration of an example data structure 108 that can be used to represent a pen event and a data sequence order 110 of such pen events that can be provided to a handwriting data processing section (see, e.g., handwriting data processing section 2100A in FIG. 20).);
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 Young/ Nosek with the teaching of Holden as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek, for example managing payment transaction between a merchant and a customer in Young, to include the method of collecting data of handwritten signature as taught by Holden for the predicated result of an improved systems of conducting a payment transaction.
Young in view of Nosek in view of Holden do not explicitly disclose, but Elischer teaches:
encrypting the virtual signature and the collected metadata using a symmetric or asymmetric encryption algorithm including at least one of AES or RSA ([0030], the digital signatures 210, 212, and other digital signatures disclosed herein, are ones of a variety of digital signatures known in the art. In an examples, the data structure 200 as built to the point of the inclusion of each digital signature 210, 212 is hashed to create a message digest, which is then encrypted using the private key of the sender (in this example, the issuer for the issuer digital signature 210 and the virtual check service 212 for the service digital signature 212….. in various examples, the keys are from seven hundred sixty-eight (768) bits, one thousand twenty-four (1024) bits, two thousand forty-eight (2048) bits, and other values. Digital signature algorithms may be selected from proprietary examples or industry standards, such as RSA-MD5, RSA-SHA-1, RSA-SHA-256, RSA-SHA-384, and Digital Signature Architecture (DSA).); see also [0040], The private key may be utilized to encrypt or digitally sign data tags 202, as disclosed herein; see [0078] on data tags).), and storing the encrypted virtual signature and the metadata in a database ([0050], The payer may use the user interface 122 to write out the virtual check 102. In various examples, writing out the virtual check 102 may include entering the name of the payee, the date, the amount of the check, and the payer's written authorizing signature, as well as an optional memo field text. The entry of the data may be directly onto a visual representation of the virtual check 102, as disclosed herein, or into electronic data fields not graphically associated with a visual representation of the virtual check 102. This data may be stored with other data as part of a payer data tag, as disclosed herein; see also fig. 5 element 116 for storage)
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 Young/ Nosek/Holden with the teaching of Elischer as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden, for example managing payment transaction between a merchant and a customer in Young, to include a method of encrypting virtual signature and the collected metadata as taught by Elischer for the predicated result of an improved systems of conducting a payment transaction.
With respect to claim 2, 10, and 18
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1, 9, and 17 respectively. Elischer further teaches: further comprising encrypting and storing the transaction data in a database ([0040], The private key may be utilized to encrypt or digitally sign data tags 202, as disclosed herein and [0031] describes the payer data tag pertains; see also [0105], In Example 21, a system may include an issuer platform, including an electronic storage configured to store data tags related to a virtual check blank, including an issuer data tag, the issuer data tag including: issuer check data and an issuer digital signature and check image data configured to generate an image related to the virtual check blank and at least some of the data tags.)
With respect to claim 8 and 16
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1 and 9 respectively. Elischer further teaches: further comprising collecting meta data associated with the signature writing process, encrypting and storing the meta data in the database ([0046], The issuing platform 104, and the issuing service 400 generally, may generate the check blank 102A by including metadata for a graphic check template, print text, magnetic ink character recognition (MICR) text, logos, background images, and/or security watermarks. Such metadata may correspond to location information specifying where the metadata is to be positioned on a graphic representation of the virtual check 102. A user may select a particular check blank 102A template among multiple check blank 102A templates, such as users may conventionally select between and among multiple bank checks and designs; see also [0105], In Example 21, a system may include an issuer platform, including an electronic storage configured to store data tags related to a virtual check blank, including an issuer data tag, the issuer data tag including: issuer check data and an issuer digital signature and check image data configured to generate an image related to the virtual check blank and at least some of the data tags.)
Claims 3, 11, and 19 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1) in view of Holden et al. (US20200082153A1), and further in view of Barron et al. (US8195570B1).
With respect to claim 3, 11, and 19
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1, 9, and 17 respectively. The combination does not explicitly disclose, but Barron teaches: further comprising service fee through an ACH network as a separate transaction upon receiving the (see col.4 ln34- ln38, the merchant can then electronically submit the return fee via ACH processing, since the checkwriter's signature had been obtained to authorize that. The merchant could also empower the third party processor to perform these functions on behalf of the merchant - the third party processor processes the transaction as a separate transaction.)
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 Young/ Nosek/Holden/ Elischer with the teaching of Barron as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a method of charging a service fee through ACH as a separate transaction taught by Barron for the predicated result of an improved systems of conducting a payment transaction.
Claims 4, 12, and 20 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1) in view of Holden et al. (US20200082153A1), and further in view of Campbell et al. (US20120095894A1).
With respect to claim 4, 12, and 20
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1, 9, and 17 respectively. The combination does not explicitly disclose, but Campbell teaches: further comprising confirming and accepting terms of service upon receiving the virtual signature form the user ([0039], For example, in one embodiment the user may first be required to selected a checkbox (or other user interface element) agreeing to receive information associated with credit advice and sign electronically, and after providing the electronic communication and signature consent the user can then agree to the terms and conditions that are electronically displayed.)
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 Young/ Nosek/Holden/ Elischer with the teaching of Campbell as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a method of accepting terms of service after receiving the virtual signature form the user taught by Campbell for the predicated result of an improved systems of conducting a payment transaction.
Claims 5 and 13 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1) in view of Holden et al. (US20200082153A1), and further in view of Triola et al. (US20190319948A1).
With respect to claim 5 and 13
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1 and 9 respectively. The combination does not explicitly disclose, but Triola teaches: further comprising performing a reputation management comprising an on-line review harvesting by providing a user with a review page upon receiving the virtual signature from the user for leaving reviews for merchants' services ([0028], in another embodiment, the remote notary may receive one or more documents, electronically tag documents for signature or initials or other requirement, schedule appointment or meet on-demand over a network with one or more parties; enable a secure online environment or portal for review, editing, approving, and/or signing the document, provide identification verification and/or proofing, enable audio and/or visual recording, support one or more document formats, execute a document, provide for tamper sealing the document, and/or register the document with a third party registration system or ledger.)
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 Young/ Nosek/Holden/ Elischer with the teaching of Triola as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a method of collecting online feedback form the user taught by Triola for the predicated result of an improved systems of conducting a payment transaction.
Claims 6 and 14 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1) in view of Holden et al. (US20200082153A1) in view of Kirsch (US20130246280A1), and further in view of Hoffman (US20020140714A1).
With respect to claim 6 and 14
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1 and 9 respectively. The combination does not explicitly disclose, but Kirsch teaches:
…….and processing an invoice prepared by the merchant for payment ([0066], The “transactions” referred to in the above discussion should be interpreted broadly. In some cases, a transaction may involve a commercial purchase. In other cases, a transaction may simply involve retrieving securely stored information from the identity repository and decrypting the information for use by a merchant; [0068], As used herein, the terms “invoice” or “digital invoice” may be interpreted broadly to include any representation of a transaction. For example, a digital invoice may be sent from a merchant to a user device describing a purchase, a purchase amount, a product type, a product quantity, and/or the like;
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 Young/ Nosek/Holden/ Elischer with the teaching of Kirsch as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a system of processing a digital invoice for a transaction between the access device and a merchant device taught by Kirsch for the predicated result of reducing the likelihood that malicious actors can intercept form data during a transaction.
The combination does not explicitly disclose, but Hoffman teaches: further comprising decrypting the virtual signature upon the account holder’s authentication([0067-0068], Reading the user's card obtains the address (e.g. URL) previously stored thereon, in addition to obtaining other data required for the transaction. In order to verify or authenticate the transaction (i.e. whether the cardholder is the owner/authorized user), the user enters his/her PIN, block 246. Correct entry of the PIN, provides authorization to proceed with the transaction. The transaction payment terminal logs onto the address obtained during reading of the card, block 248. The encoded and encrypted signature is retrieved by the transaction payment terminal from the storage location specified by the address obtained from the card, block 250. Thereafter, the encoded and encrypted signature is decrypted and decoded to obtain the original signature (i.e. an electronic representation of the original signature), block 252. The original signature is then printed onto a paper receipt, block 254, when the transaction is complete. In addition, the signature is appended to a digital receipt generated from the transaction that is then stored in a storage device, block 256.)
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 Young/ Nosek/Holden/ Elischer with the teaching of Hoffman as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a method of populating decrypted signature onto a receipt as taught by Hoffman for the predicated result of providing easier access to the various functionality of the signature capture terminal.
Claims 7 and 15 are rejected under 35 U.S.C 103 as obvious over Young et al. (US11715080B1) in view of Nosek (US7191151B1) in view of Elischer (US20140067661A1) in view of Holden et al. (US20200082153A1), and further in view of Hoffman (US20020140714A1).
With respect to claim 7 and 15
The combination of Young, Nosek, Elischer, and Holden teaches the limitation of claim 1 and 9 respectively. The combination does not explicitly disclose, but Barron teaches: further comprising decrypting the virtual signature upon the account holder’s authentication and populating a credit card receipt with the decrypted signature ([0067-0068], Reading the user's card obtains the address (e.g. URL) previously stored thereon, in addition to obtaining other data required for the transaction. In order to verify or authenticate the transaction (i.e. whether the cardholder is the owner/authorized user), the user enters his/her PIN, block 246. Correct entry of the PIN, provides authorization to proceed with the transaction. The transaction payment terminal logs onto the address obtained during reading of the card, block 248. The encoded and encrypted signature is retrieved by the transaction payment terminal from the storage location specified by the address obtained from the card, block 250. Thereafter, the encoded and encrypted signature is decrypted and decoded to obtain the original signature (i.e. an electronic representation of the original signature), block 252. The original signature is then printed onto a paper receipt, block 254, when the transaction is complete. In addition, the signature is appended to a digital receipt generated from the transaction that is then stored in a storage device, block 256; see [0057], The system 170 includes a transaction payment/retail terminal 172 on which a transaction is made. The transaction may be any type of transaction that requires a signature from the consumer such as a retail purchase, bill payment, electronic fund transfer, or the like. Such transactions are typically those involving credit cards, debit cards, other types of cards, and the like.)
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 Young/ Nosek/Holden/ Elischer with the teaching of Hoffman as they relate to a system/method of managing payment transaction between two parties. One of ordinary skill in the art before effective filing date of the claimed invention would have modified the combined systems of Young/ Nosek/Holden/ Elischer, for example managing payment transaction between a merchant and a customer in Young, to include a method of populating decrypted signature onto a receipt as taught by Hoffman for the predicated result of providing easier access to the various functionality of the signature capture terminal.
Conclusion
THIS ACTION IS MADE FINAL, necessitated by amendment. 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 3699
1/7/2026
/NEHA PATEL/Supervisory Patent Examiner, Art Unit 3699