DETAILED ACTION
This action is in reply to the amendment filed on 06/26/2025.
Claims 1, 8, 9 and 16 have been amended.
Claims 1-16 have been examined.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Arguments
With regard to the 112 rejection, the Applicant has amended claims 8 and 16 with regard to the “ISO 8583 standard . . .”. Therefore, the 112 rejection is withdrawn.
With regard to the Applicant’s remarks on the 101 Rejection, Applicant asserted in pg. 10 , under step 2A – Prong One: “[applicant] respectfully submits that the specification ‘provides sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement . . . See, e.g., the Revised Guidance, at p. 11” However, the Examiner does not see the improvement in technology as claimed by the applicant. The Applicant’s claims do not involve any improvements to another technology, technical field, or improvements to the functioning of the computer itself. The Applicants’ invention is a business solution to a problem rooted in an abstract idea. The limitations are directed to concepts, via the use of generic computer components to performing payment between two parties. Hence, they are directed to commercial interactions and/or fundamental economic activity which fall within the Certain Methods of Organizing Human Activity grouping.
The Applicant further asserted in pg. 14 that “[as] a result of the claims, (1) interactions previously required between involved entities are reduced, (2) direct involvement by involved entities to initiate payment transactions is no longer required as the payments are automatically handheld by a payment processor . . .and (3) accuracy of provenance blockchains and efficiency is increased . . . .” However, the above arguments are not persuasive. The limitations in claim 1, in light of the arguments, are not indicative of integration into a practical application. They are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). In the instant case, the applicant leverages the blockchain technology and links the judicial exception to the existing technology .
Under Step 2B Analysis, the claimed elements are not indicative of an inventive concept (aka “significantly more”, the limitations are Generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Therefore, per above reasoning, the 101 rejection is maintained.
With regards to the 103 rejections, the Applicant has amended the limitations. The Applicant asserted in page 20 that “Ortiz does not disclose or suggest [the amended limitation of claim 1] . . .”. However, the reference MST still discloses the amended limitation.
Please refer to the rejections below for further details.
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-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea.
Claims 1 and 9 recite, in part, a method for triggering payment transactions through predetermined events identified using a blockchain, comprising: receiving, by a blockchain node in a blockchain network, from an external computing device including at least one of a buyer system and a seller system, via a specific application programming interface (API) utilized by the blockchain node, trigger data associated with at least one product, the trigger data including at least a first account identifier associated with a buyer of the buyer system, a second account identifier associated with a seller of the seller system, and one or more trigger event values that are a hash value of a blockchain data value; recording, by the blockchain node, via a self-executable smart contract, the trigger data received from the external computing device in a blockchain; monitoring, by the blockchain node, via the self-executable smart contract, new blockchain data values added to the blockchain, wherein each new blockchain data value includes at least a specific hash value; determining, by the blockchain node, via the self-executable smart contract, that a specific new blockchain data value of the new blockchain data values added to the blockchain triggers a specific trigger event associated with a specific trigger event value of the one or more trigger event values based on a correspondence between at least the specific hash value included in a new blockchain data value added to the blockchain and the specific trigger event value; in response to determining that a specific trigger event has been triggered, self-executing, by the self-executing smart contract, to electronically transmit a notification message, from the blockchain node to a payment provider computing system, wherein the notification message includes at least the first account identifier associated with the buyer and the second account identifier associated with the seller; identifying, by the payment provider computing system, a first payment identifier based on the received first account identifier associated with the buyer and a second payment identifier based on the received second account identifier associated with the seller; without requiring direct involvement by the buyer and the seller, automatically initiating, by the payment provider computing system, a payment transaction for payment from a transaction account associated with the first payment identifier to a transaction account associated with the second payment identifier for a predetermined transaction amount by creating a specially formatted transaction message and submitting the specially formatted transaction message to a payment network via payment rails associated therewith, and in response to scanning of a machine-readable code affixed to the at least one product, submitting, by the blockchain node, via self-execution of the self-executing smart contract, a new event associated with the scanning of the machine-readable code, for addition to the blockchain as a new blockchain data value.. The limitations are directed to concepts, via the use of generic computer components to performing payment between two parties. Hence, they are directed to commercial interactions and fundamental economic activity which fall within the Certain Methods of Organizing Human Activity grouping. Accordingly, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application. In particular, the claim only recites additional elements such as a blockchain network, computing devices, blockchain nodes, a buyer system, a seller system, a self-executable smart contract, payment providers, and other generic computer components to perform receiving, sending, and transmitting. The blockchain is recited at a very high level of generality such that this technology is leveraged to perform the abstract idea. The generic computer components are recited at a high-level of generality (receiving, determining, and transmitting) such that it is generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to an abstract idea
Next the claim as a whole is analyzed to determine whether any element, or combination of elements, is sufficient to ensure the claim amounts to significantly more than an abstract idea. Claims 1 and 9 do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements of at least a computing device to perform receiving and identifying data are merely additional elements performing the abstract idea on a generic device i.e., abstract idea and apply it. There is no improvement to computer technology or computer functionality MPEP 2106.05(a) nor a particular machine MPEP 2106.05(b) nor a particular transformation MPEP 2106.05(c); see Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) see MPEP 2106.05(d). Given the above reasons, applicant leverages a generic processing device with existing technology to perform a payment integration with provenance supply chain events is not a novel idea. Therefore, the claims are not patent eligible.
The dependent claims have been given the full two part analysis (Step 2A – 2-prong tests and step 2B) including analyzing the additional limitations both individually and in combination. The Dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. 101 because for the same reasoning as above and the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea. The additional limitations of the dependent claim(s) when considered individually and as ordered combination do not amount to significantly more than the abstract idea.
Claim 4, 12 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of receiving account identifier(s). This judicial exception is not integrated into a practical application because the limitations are A generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as a computing device) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claim 6, 14 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) an abstract idea of triggering data for one of the triggering event. This judicial exception is not integrated into a practical application because the limitations are A generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as a computing device) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claim 7, 15 are rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) method of initiating a submission of transaction message format. This judicial exception is not integrated into a practical application because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as a blockchain) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Claims 2, 3, 5, 8, 10, 11, 13, 16 rejected under 35 U.S.C. 101 because the claimed invention is directed to judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. The claim(s) recite(s) additional elements such as predetermined amount, order number, message format standard. This judicial exception is not integrated into a practical application because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h). The claim(s) does/do not include additional elements (such as a blockchain, a computing device) that are sufficient to amount to significantly more than the judicial exception because the limitations are generally linking the use of the judicial exception to a particular technological environment or field of use – see MPEP 2106.05(h).
Therefore, Claims 1-16 are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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, 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, 3, 4, 7, 9, 10, 11, 12, 15 are rejected under 35 U.S.C. 103 as being unpatentable over Ortiz et al. (US 2018/0293573 A1) in view of Kapczynski et al. (US 9, 443, 268 B1) in further view of Microsoft Technology Licensing, LLC (WO 2020/106507 A1); hereinafter, MSFT.
Claims 1 and 9, Ortiz discloses: A method for triggering payment transactions through predetermined events identified using a blockchain, comprising: receiving, by a blockchain node in a blockchain network, from an external computing device including at least one of a buyer system and a seller system, via a specific application programming interface (API) utilized by the blockchain node (Ortiz, par. [0165] & [0199]) the computing device receives buyer and seller system, trigger data associated with at least one product, the trigger data including at least a first account identifier associated with a buyer, a second account identifier associated with a seller of the seller system, (Ortiz, see at least par. [0198] “. . . Generally speaking, the exact format of such protocols is of secondary importance: more importantly, relevant data such as payment and/or deposit account numbers (or other identifiers), authorized and/or requested transaction values, and identifiers related to account holders, authorized account users, account administrators, and payors and payees can be embedded within transaction data records in any suitable and agreed format.”) payor could correspond to buyer and payee could correspond to seller, and one or more trigger event values (Ortiz, see at least Par. [0223] “The user can select a GUI item 1486 associated with the desired FI, and provided a corresponding wallet application 112 is installed on the device 110, 110′, that corresponding wallet application 112 is launched, the user can further select an individual account associated with that FI (e.g., choose between credit, deposit, and loyalty accounts), and tap the device 110′, 100 to an NFC-enabled POS device 132, 134 POS to pay. A token or other suitable credentials data set stored in association with the selected wallet application 112 may be transmitted to the POS terminal directly, or it may be sent back (pulled) to the originally-preferred wallet application 112 through SDK/API 116 “Paywithurbank” communication standards, and the first FI wallet 112 can route a suitably-configured transaction payment data set to the POS terminal. A similar process can be applied in-app payments originated from a merchant or other application 114, 115, as well.” & Par. [0336] & Table 2 & par. [0446]) triggering value could be a currency denomination as mentioned in par. [0032] of the spec. Furthermore, triggering value could be any form of data such as hashing that identifies the merchant or parties involved to initiate transaction workflow,
in response to determining that a specific trigger event has been triggered, self-executing, by the self-executing smart contract, to, electronically transmit a notification message, from the blockchain node to a payment provider computing wherein the notification message includes at least the first account identifier associated with the buyer and the second account identifier associated with the seller (Fig. 26A-26C & Par. [0341]) first account identifier corresponds to “RBC”, second account identifier corresponds to “moog audio”,
identifying, by the payment provider computing system, a first payment identifier based on the received first account identifier associated with the buyer and a second payment identifier based on the received second account identifier associated with the seller (Par. [0281]) Interpretation: Trusted platform corresponds to payment provider;
without requiring direct involvement by the buyer and the seller, automatically initiating, by the payment provide computing system, a payment transaction for payment from a transaction account associated with the first payment identifier to a transaction account associated with the second payment identifier for a predetermined transaction amount (Par. [0341]) payment is confirmed.
by creating a specially formatted transaction message and submitting the specially formatted transaction message to a payment network via payment rails associated therewith (Ortiz, claim 6): Token in generated format compatible for routing corresponds to “specifically formatted transaction”.
and in response to scanning of a machine-readable code affixed to the at least one product (Ortiz, see at least par. [0022] “. . . Similarly, payment credentials and transaction information can be exchanged between the mobile wallet and merchant POS terminal using visual patterns, such as barcodes and QR codes, which are displayed on the mobile device for scanning by the merchant POS terminal . . .”).
Ortiz does not teach the following; however, Kapczynski teaches:
and without requiring the buyer or seller to initiate new payment transactions or manage recurring payments, automatically initiating, by the second computing system, a payment transaction for payment from a transaction account associated with the first payment identifier to a transaction account associated with the second payment identifier for a predetermined transaction amount (Kapczynski, Col. 8 ln 49-63) the cited portion discloses the automatic initiation of payment for a recurring amount (predetermined amount).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the features of automatic initiation of recurring payment as taught by Kapcyznski with the invention of performing a transaction between 2 devices disclosed by Ortiz to better create hashed block prior to better automatize bill payment on the blockchain platform (abstract). Therefore, the combination is obvious.
Ortiz in view of Kapczynksi does not disclose the following; MSFT teaches:
hash value of a blockchain data value (MSFT, see at least par. [0038] “. . . As discussed above, in some scenarios new blocks are created by miners who compete to generate hash values meeting certain criteria . . .”)
recording, by the blockchain node, via a self-executable smart contract, the trigger data received from the external computing device in a blockchain (Microsoft Technology Licensing, LLC (WO 2020/106507 A1), par. [0023] “ . . . In an example scenario, a smart contract may be configured to transfer ownership of a particular asset (e.g., vehicle) from one party to another upon confirmation of payment. Once the smart contract receives an indication that the payment has been made, the smart contract may automatically record a transaction specifying the change in ownership of the asset. . . .”); monitoring, by the blockchain node, via the self-executable smart contract, new blockchain data values added (Microsoft, par. [0026]-[0027]) to wherein each blockchain data value includes at least a specific hash value (Microsoft, par. [0040] “. . . As discussed above, in proof-of-work scenarios, each new block to the blockchain will include a unique hash value that was generated to meet certain criteria . . .”)
determining by the blockchain node, via the self- executable smart contract, that a match between a specific new blockchain data value added to the blockchain of the one or more blockchain data values and a specific trigger event associated with a specific trigger event value of the one or more trigger event values based on correspondence between at least the specific hash value included in a new blockchain data value and the specific trigger event value (Microsoft, see at least par. [0018] “. . . Inclusion of prior block hashes serves to validate the sequence of blocks in the chain, as each block should be succeeded by a block including a corresponding hash value, and also provides a defense against modifications to the chain, as even minor changes to a block will affect its hash value. In other words, header 204B may include a hash of block 202 A, while header 204C may include a hash of block 202B.. . .”) Interpretation: this is called validation;
submitting, by the blockchain node, via self-execution of the self-executing smart contract, a new event associated with the scanning of the machine-readable code, for addition to the blockchain as a new blockchain data value (MSFT, see at least par. [0027] “When access criteria for a digital asset are, the update may be recorded in the blockchain as a new data entry that is automatically generated by the smart contract and eventually added to a new block . . .”).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the features of using smart contracts and hash functions in blockchain as taught by MSFT with the invention of performing a transaction between 2 devices disclosed by Ortiz in view of Kapczynski to better create hashed block prior to providing access to a service provider for authentication purpose (Abstract). Therefore, the combination is obvious.
2. Claims 2 and 10 were disclosed by Ortiz in view of MSFT: Claim 2, for instance, is disclosed: The method of claim 1, wherein the trigger data includes the predetermined transaction amount (Ortiz, Par. [0341]) the predetermined amount could be any amount prior to the transferred.
3. Claims 3 and 11 were disclosed by Ortiz in view of Kapcyznski in further view of MSFT: Claim 3, for instance, is disclosed. Ortiz in view of Kapcyznski teaches: The method of claim 1. However, Ortiz further teaches: wherein each of the one or more trigger event values included in the trigger data is accompanied by an amount value, and the predetermined transaction amount is the amount value accompanying the specific trigger event value (Ortiz, Par. [0341]) Trigger event could be a purchase and money wiring.
Claims 4 and 12 were disclosed: Claim 4, for instance, is taught by Ortiz in view of Kapcyznski in further view of MSFT. Ortiz, further teaches: receiving, by the payment provider, the first account identifier and the first payment identifier or the second account identifier and the second payment identifier from the external computing device (Ortiz, Par. [03444]) the cited portion discloses receiving identifier.
Claims 7 and 15 were grouped together, Claim 7, for instance, was disclosed by Ortiz in view of Kapcyznski in further view of MSFT: wherein the transaction message formatted pursuant to one or more standards to a financial institution using payment rails, wherein the transaction message includes a plurality of data element storing the first payment identifier, the second payment identifier, and the transaction amount (Ortiz, Par. [0364]) The cited portion discloses the transaction message including plurality of data.
Claims 5, 6 13 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Ortiz et al. (US 2018/0293573 A1) in view of Kapczynski et al. (US 9, 443, 268 B1) in view of Microsoft Technology Licensing, LLC (WO 2020/106507 A1); hereinafter, MSFT, in further view of Fenton et al. (US 2019/0057381 A1).
Claims 5 and 13 were disclosed: Ortiz in view of Kapcyznski in further view of MSFT teaches: the method of claim 1. However, Fenton teaches wherein the notification message further includes an order number (Fenton, Table 1 “transaction number”) Transaction number corresponds to order number and is part of the account identifier.
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the features of including a transaction or order number as taught by Fenton with the invention of using the hash value and transaction performance between two devices as taught by Ortiz in view of Kapcyznski in further view of MSFT to better improve transaction via machine learning and record enhancement (Fenton, abstract). Therefore, the combination is obvious.
Claims 6 and 14 were disclosed: Ortiz in view of Kapcyznski in further view of MSFT teaches: the method of claim 5. However, Fenton teaches wherein the order number is one of: a single order number included in the trigger data for each of the one or more trigger event values, or an order number associated with the specific trigger event value included in the trigger data (Fenton, Table 1) Interpretation: Table 1 includes triggering event such as term date for a transaction
It would have been obvious to one of ordinary skill in the effective filing date to combine the features of including a transaction or order number as taught by Fenton with the invention of using the hash value and transaction performance between two devices as taught by Ortiz in view of Kapcyznski in further view of MSFT to better improve transaction via machine learning and record enhancement (Fenton, abstract). Therefore, the combination is obvious.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Ortiz et al. (US 2018/0293573 A1) in view of Kapczynski et al. (US 9, 443, 268 B1) in view of Microsoft Technology Licensing, LLC (WO 2020/106507 A1); hereinafter, MSFT in further view of Sonkar et al. (US 2018/0285549 A1).
Claims 8 and 16 were disclosed: Ortiz in view of Kapcyznski in further view of MSFT teaches: The method of claim 1. However, Sonkar teaches wherein wherein the specially formatted transaction message is an international standard (i) for electronic financial transaction card- originated messages, (ii) for electronic data in the financial industry (Sonkar, Par. [0031] “. . . An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account . . .”).
It would have been obvious to one of ordinary skill in the effective filing date to combine the features of including ISO 8583 or ISO 2022 as taught by Sonkar with the invention of using the hash value and transaction performance between two devices as taught by Ortiz in view of Kapcyznski in further view of MSFT to better comply with system standard in processing transaction (Par. [0031]). Therefore, the combination is obvious.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TOAN DUC BUI whose telephone number is (571)272-0833. The examiner can normally be reached M-F 8-5:00 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, Mike W. Anderson can be reached on (571) 270-0508. 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.
/TOAN DUC BUI/ Examiner, Art Unit 3693 /Mike Anderson/Supervisory Patent Examiner, Art Unit 3693
Prosecution Insights