DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Status of Claims
2. Applicant filed the amendment on 03/23/2026. Claims 1-20 are pending. Claims 1, 5, 10-12, 16-17, and 20 are amended.
Claim Interpretation
Intended Use
3. Intended use language is generally not given patentable weight. See MPEP 2114(II) ("A claim containing a 'recitation with respect to the manner in which a claimed apparatus is intended to be employed does not differentiate the claimed apparatus from a prior art apparatus’ if the prior art apparatus teaches all the structural limitations of the claim. Ex parte Masham, 2 USPQ2d 1647 (Bd. Pat. App. & Inter. 1987).”); see also MPEP 2103(C). Examples of claim limitations that are often found to precede intended use include “adapted to,” “capable of,” “sufficient to,” “whereby,” and “for.”
4. Claim 1 recites “updating, using the processor, the smart contract to indicate that the respective transaction party condition has been fulfilled” and “updating, using the processor the smart contract to indicate that the part of the transaction has been executed”.
Claim 12 recites “update the smart contract to indicate that the respective transaction party condition has been fulfilled” and “update the smart contract to indicate that the part of the payment transaction has been executed”.
Claim Rejections - 35 USC § 112
5. 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.
6. Claim 1-20 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.
7. Claims 1 and 12 recite “an accessibility matrix, the accessibility matrix including: a plurality of different roles for the plurality transaction parties, and an assignment of each transaction party to at least one of the roles, wherein each role in the accessibility matrix is configured to allow the transaction party who is assigned to the role a right to access one or more functions of the smart contract based on the transaction party's access requirements for the payment transaction; for each transaction party condition of the transaction party conditions”.
The specification does not support a single contract that performs all of the functions of above recited amendments. The wallets and roles contract are separate from the transaction contract in the specification (see figure 6, elements 626 and 630, and specification (PGPub, para 86) “The entitlement contract 632 contains the rights of roles. This acts as an accessibility matrix for different roles.”).
8. Claims 2-11 and 13-20 are rejected under the same rationale as claims 1 and 12, because claims 2-11 and 13-20 inherit deficiencies of claims 1 and 12 respectively due to their dependency.
Claim Rejections - 35 USC §101
9. 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.
10. Claims 1-20 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.
11. In the instant case, claims 1 and 12 are directed to a “method and a system for a payment transaction processing”.
12. Claim 1 recites “processing a payment transaction”. Specifically, the claim recites “receiving … a transaction initiation request for a payment transaction involving a plurality of transaction parties; generating … for the payment transaction and storing …; configuring … to include: a plurality of conditions which are fulfilled prior to execution of the payment transaction, wherein the plurality of conditions comprises transaction party conditions which are fulfilled by respective transaction parties from the plurality of transaction parties; and an accessibility matrix, the accessibility matrix including: a plurality of different roles for the plurality transaction parties, and an assignment of each transaction party to at least one of the roles, wherein each role in the accessibility matrix is configured to allow the transaction party who is assigned to the role a right to access one or more functions … based on the transaction party's access requirements for the payment transaction; for each transaction party condition of the transaction party conditions: searching … in the accessibility matrix, for one or more transaction parties corresponding to the transaction party condition; in response to determining … from the search, that a respective transaction party's condition corresponds to the transaction party condition based on the assigned role of the respective transaction party in the payment transaction: sending … a message to the respective transaction party to fulfill the respective transaction party's condition; receiving … a response indicating that the respective transaction party condition has been fulfilled; verifying … based on the accessibility matrix, that the response was sent by the respective transaction party; and in response to verifying… that the response was sent by the respective transaction party: updating … to indicate that the respective transaction party condition has been fulfilled; in response to determining … that each condition of the plurality of conditions has been fulfilled; sending … a transaction execution message to a transaction execution party of the plurality of transaction parties to execute part of the payment transaction; receiving … a transaction execution response from the transaction execution party indicating that a part of the payment transaction has been executed; and updating … to indicate that the part of the transaction has been executed”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
13. This judicial exception is not integrated into a practical application because, when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 1 such as “a processor”, “generating, using the processor, a smart contract instance for the payment transaction”, and “storing, using the processor, the smart contract instance in a smart contract on a blockchain” do no more than represent the use of a computer as a tool to perform an abstract idea and the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “receiving, using a processor, a transaction initiation request for a payment transaction involving a plurality of transaction parties”, “storing, using the processor, the smart contract instance in a smart contract on a blockchain”, “sending, using the processor, a message to the respective transaction party to fulfill the respective transaction party's condition”, “receiving, using the processor, a response indicating that the respective transaction party condition has been fulfilled”, “sending, using the processor, a transaction execution message to a transaction execution party of the plurality of transaction parties to execute part of the payment transaction”, and “receiving, using the processor, a transaction execution response from the transaction execution party indicating that a part of the payment transaction has been executed”, is simply transmitting data; “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
14. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of processing a payment transaction using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
15. Hence, claim 1 is not patent eligible.
16. Claim 12 also recites “processing a payment transaction”. Subject matter grouped under “Certain methods of organizing human activity” (e.g., commercial or legal interactions) and an abstract idea in prong one of step 2A (MPEP 2106.04(a)).
17. As in the case of claim 1, the judicial exception is not integrated into a practical application because when analyzed under prong two of step 2A (MPEP 2106.04 II), the additional elements of claim 12 such as “a processor”, “a data storage device”, “generate a smart contract instance for the payment transaction”, and “store the smart contract instance in a smart contract on a blockchain” do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use. Therefore, as they do no more than represent the use of a computer as a tool to perform an abstract idea and/or generally linking the use of a judicial exception to a particular technological environment or field of use, they do not improve computer functionality nor improve another technology or technical field. With respect to “receive a transaction initiation request for a payment transaction involving a plurality of transaction parties”, “store the smart contract instance in a smart contract on a blockchain”, “send a message to the respective transaction party to fulfill the respective transaction party's condition”, “receive a response indicating that the respective transaction party condition has been fulfilled”, “send a transaction execution message to a transaction execution party of the plurality of transaction parties to execute part of the payment transaction”, and “receive a transaction execution response from the transaction execution party indicating that a part of the payment transaction has been executed”, is simply transmitting data; “[use] of a computer or other machinery in its ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) (e.g., a fundamental economic practice) does not integrate a judicial exception into a practical application or provide significantly more”, (MPEP 2106.05(f)(2)).
18. When analyzed under step 2B (MPEP 2106.04 II), the claim does not include additional elements that are sufficient to amount to significantly more than the judicial exception itself. Viewed as a whole, the combination of elements recited in the claim merely describe the concept of processing a payment transaction using computer technology (e.g., the processor). Therefore, the use of these additional elements does no more than employ a computer as a tool to automate and/or implement the abstract idea, which cannot provide significantly more than the abstract idea itself (MPEP 2106.05(I)(A)(f) & (h)).
19. Hence, claim 12 is not patent eligible.
20. The following dependent claims recent additional elements not addressed above:
claims 6 and 17 recite “one of a plurality of smart contract templates”; and
claim 11 recites “a non-transitory computer readable medium”.
When considered individually, and as a whole, each of these additional elements amount to merely "apply it", as they are merely applying the abstract idea to the technical environment of the one of a plurality of smart contract templates and the non-transitory computer readable medium.
Dependent claims 2-11 and 13-20 merely expand upon the abstract ideas of the independent claims 1 and 12, and are therefore rejected under the same rationale as claims 1 and 12.
Conclusion of 35 USC §101
21. The claims as a whole do not amount to significantly more than the abstract idea itself. This is because the claims do not effect an improvement to another technology or technical field; the claims do not amount to an improvement to the functioning of a computer system itself; and the claims do not move beyond a general link of the use of an abstract idea to a particular technological environment.
22. Accordingly, there are no meaningful limitations in the claims that transform the judicial exception into a patent eligible application such that the claims amount to significantly more than the judicial exception itself.
Claim Rejections - 35 USC § 103
23. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
24. 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.
25. 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.
26. Claims 1-6 and 11-17 are rejected under 35 U.S.C. 103 as being unpatentable over US11423398B1 to Mullins et al. in view of US11120437B2 to Wright et al.
27. As per claim 1:
Mullins et al. discloses the following limitations:
A transaction processing method comprising (Col.2, lines 13-15; discloses transaction processing method using blockchain (smart contracts) for payment)
receiving, using a processor, a transaction initiation request for a payment transaction involving a plurality of transaction parties (Col.31, lines 61-67; discloses the processor receives a transaction initiation request for a payment transaction between merchant, customer and a plurality of transaction parties)
generating, using the processor, a smart contract instance for the payment transaction (Col.32, lines 18-22; discloses that a smart contract instance (executable code) is generated for the specific payment transaction)
storing, using the processor, the smart contract instance in a smart contract on a blockchain (Col.32, lines 23-24; col.10, lines 34-36; discloses that the generated smart contract is stored on the blockchain)
configuring, using the processor, the smart contract to include (Col.16, lines 1-6; discloses that the blockchain-enforced contract is configured with one or more conditions (including nested contract conditions))
a plurality of conditions which are fulfilled prior to execution of the payment transaction, wherein the plurality of conditions comprises transaction party conditions which are fulfilled by respective transaction parties from the plurality of transaction parties (Col.12, lines 45-50, 52-56; discloses multiple party-specific conditions (customer confirmation, merchant confirmation, shipping-agent confirmation, third-party authorization) must be fulfilled by their respective parties before the payment executes)
a plurality of different roles for the plurality transaction parties (Col.12, lines 52-56; discloses distinct roles – merchant, customer, shipping agent, third-party arbiter)
an assignment of each transaction party to at least one of the roles (Col.17, lines 14-17; discloses that each transaction party is assigned to a specific role (merchant / customer / third party / shipping agent)
for each transaction party condition of the transaction party conditions (Col.17, lines 60-63; discloses that the system iterates per condition to check fulfillment by the respective party)
in response to determining, using the processor, from the search, that a respective transaction party's condition corresponds to the transaction party condition based on the assigned role of the respective transaction party in the payment transaction (Col.17, lines 20-26; discloses that the party-condition is matched to the assigned role (e.g., delivery confirmation from shipping agent role))
sending, using the processor, a message to the respective transaction party to fulfill the respective transaction party's condition (Col.14, lines 28-33; col.33, lines 14-15; discloses that a message is sent to the appropriate party prompting them to fulfill their condition)
receiving, using the processor, a response indicating that the respective transaction party condition has been fulfilled (Col.36, lines 29-34; discloses that a response confirming the party-condition is received from the responsible party)
in response to verifying, using the processor, that the response was sent by the respective transaction party (Col.18, lines 39-44; discloses that subsequent action is taken only in response to successful determination/verification)
updating, using the processor, the smart contract to indicate that the respective transaction party condition has been fulfilled (Col.32, lines 30-38; discloses that the smart contract is updated on blockchain to indicate that the condition has been fulfilled by the responsible party)
in response to determining, using the processor, that each condition of the plurality of conditions has been fulfilled (Col.33, lines 21-27; discloses that execution proceeds only after each condition of the contract has been satisfied)
sending, using the processor, a transaction execution message to a transaction execution party of the plurality of transaction parties to execute part of the payment transaction (Col.18, lines 51-55; col.32, lines 39-41; discloses that an execution message/transaction is sent to a transaction-execution party (blockchain node/payment service) to execute part of the payment)
receiving, using the processor, a transaction execution response from the transaction execution party indicating that a part of the payment transaction has been executed (Col.32, lines 35-38; discloses that a confirmation/response of execution is received from the blockchain network (transaction execution party))
updating, using the processor the smart contract to indicate that the part of the transaction has been executed (Col.33, lines 9-13; discloses that the smart contract / ledger is updated to indicate execution of the payment)
Mullins et al. does not disclose, however, Wright et al., as shown, teaches the following limitations:
an accessibility matrix, the accessibility matrix including (Col.1, lines 17-20; col.11, lines 3-4; discloses that script defines who may access which outputs/functions (i.e., functionally an accessibility matrix))
wherein each role in the accessibility matrix is configured to allow the transaction party who is assigned to the role a right to access one or more functions of the smart contract based on the transaction party's access requirements for the payment transaction (Col.1, lines 18-20; col.4, lines 46-49; discloses that each role granted specific access rights to functions of the smart contract based on authorization)
searching, using the processor, in the accessibility matrix, for one or more transaction parties corresponding to the transaction party condition (Col.13, lines 37-41; discloses identifying the specific party (assigned signatory) per condition (by name and key))
verifying, using the processor, based on the accessibility matrix, that the response was sent by the respective transaction party (Col.21, lines 46-49; col.26, lines 14-17; discloses that response cryptographically verified against the public key tied to the party, i.e., role based verification by Elliptic Curve Digital Signature Algorithm key check)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for controlling the visibility and/or performance of a contract, wherein the contract may be a smart contract of Wright et al. (‘437, col.2, lines 48-52) with teaching of Mullins et al. for creating an intelligent smart contract on the blockchain at a point of sale system, without requiring the POS system to be equipped with software or hardware for distributed-application programming or blockchain data storage (‘398, col.2, lines 13-17) for having small programs known as scripts embedded into its inputs and output, which specify how and by whom the outputs of the transaction can be accessed, accessing to some or all of the contents of the contract may be required authorisation in order to view some or all of the contract, building contract where a sign-off from a surveyor is required, created, and circulated to sign, and validating the first signed message with the first node second public key and authenticating the first node based on the result of validating the first signed message (‘437, col.1, lines 17-20; col.4, lines 46-49; col.11, lines 3-4; col.13, lines 37-41; col.21, lines 46-49; col.26, lines 14-17)
Claim 12 is rejected using the same rationale that was used for the rejection of claim 1.
28. As per claim 2:
Mullins et al. discloses the following limitations:
The method according to claim 1, wherein the plurality of conditions further comprises an external condition which is fulfilled prior to execution of the payment transaction (Col.12, lines 45-49; col.23, lines 3-10; discloses external conditions (oracle data, shipping agent confirmation, third party authorization) required to be fulfilled prior to execution of the payment)
Claim 13 is rejected using the same rationale that was used for the rejection of claim 2.
29. As per claim 3:
Mullins et al. discloses the following limitations:
The method according to claim 2, wherein the blockchain stores a mapping of a function onto the external condition (Col.23, lines 3-5; col.32, lines 18-22; discloses that the smart contract code (function) for evaluating the external condition is stored on the blockchain, effectively mapping the function onto the external condition)
Claim 14 is rejected using the same rationale that was used for the rejection of claim 3.
30. As per claim 4:
Mullins et al. discloses the following limitations:
The method according to claim 3, wherein the function depends on an external data source (Col.23, lines 3-8; discloses the on-chain function relies on an external data source (an oracle, third party API) to obtain condition information)
Claim 15 is rejected using the same rationale that was used for the rejection of claim 4.
31. As per claim 5:
Mullins et al. discloses the following limitations:
The method according to claim 1, wherein the smart contract is further configured to indicate a sequence in which the plurality of conditions are fulfilled (Col.16, lines 1-6, 9-12; discloses that the smart contract indicates a sequence of stages (e.g., purchase > return > dispute), with each stage’s conditions required for that stage’s execution) and wherein the method further comprises determining, using the processor, that the conditions are fulfilled according to the sequence (Col.33, lines 21-27; discloses determining that conditions of each stage have been fulfilled in sequence before progressing to the next stage / execution)
Claim 16 is rejected using the same rationale that was used for the rejection of claim 5.
32. As per claim 6:
Mullins et al. discloses the following limitations:
The method according to claim 1, wherein generating the smart contract instance comprises generating the smart contract instance according to one of a plurality of smart contract templates (Col.33, lines 34-41; discloses selecting from a set of potential conditions/options to generate the contract (i.e., template) like configurable basis)
Claim 17 is rejected using the same rationale that was used for the rejection of claim 6.
33. As per claim 11:
Mullins et al. discloses the following limitations:
A non-transitory computer readable medium storing processor executable instructions which when executed on the processor cause the processor to carry out the method according to claim 1 (Col.31, lines 49-53; discloses computer-readable non-transitory storage media storing instructions cause the processor to perform the method of claim 1)
34. Claims 7-10 and 18-20 are rejected under 35 U.S.C. 103 as being unpatentable over
US11423398B1 to Mullins et al. in view of US11120437B2 to Wright et al. and ISO 20022 Programme. Quality data, quality payments. Awareness Webinar – Payments Deep Dive. (“ISO 20022 Webinar”).
35. As per claim 7:
Neither Mullins et al., nor Wright et al. disclose, however, ISO 20022 Webinar, as shown, discloses the following limitations:
The method according to claim 1, wherein the transaction initiation request comprises a message formatted according to the ISO 20022 standard (ISO 20022 Webinar “What is ISO 20022? Maintenance process –built on strict business justifications and review process - leading to new ‘versions’ of the messages” page 4; “In 2018, the global financial community agreed to migrate from the MT (FIN) payment message standard to ISO 20022” page 5)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for controlling the visibility and/or performance of a contract, wherein the contract may be a smart contract of Wright et al. (‘437, col.2, lines 48-52) and ISO 20022 Webinar explaining benefits of standard like improved data quality, enhanced operational efficiency through higher straight-through processing (STP) rates, and better compliance and risk management with teaching of Mullins et al. for creating an intelligent smart contract on the blockchain at a point of sale system, without requiring the POS system to be equipped with software or hardware for distributed-application programming or blockchain data storage (‘398, col.2, lines 13-17) for maintaining process of building and reviewing business justifications by establishing payment message standards (ISO 20022 Webinar, page 5).
Claim 18 is rejected using the same rationale that was used for the rejection of claim 7.
36. As per claim 8:
Neither Mullins et al., nor Wright et al. disclose, however, ISO 20022 Webinar, as shown, discloses the following limitations:
The method according to claim 7, wherein the transaction initiation request comprises a pacs.008 message (ISO 20022 Webinar, page 12, “pacs.008 FI To FI Customer Credit Transfer serial message flow”)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for controlling the visibility and/or performance of a contract, wherein the contract may be a smart contract of Wright et al. (‘437, col.2, lines 48-52) and ISO 20022 Webinar explaining benefits of standard like improved data quality, enhanced operational efficiency through higher straight-through processing (STP) rates, and better compliance and risk management with teaching of Mullins et al. for creating an intelligent smart contract on the blockchain at a point of sale system, without requiring the POS system to be equipped with software or hardware for distributed-application programming or blockchain data storage (‘398, col.2, lines 13-17) for describing usage of ISO 20022 pacs.008 message formats (ISO 20022 Webinar, page 12).
37. As per claim 9:
Neither Mullins et al., nor Wright et al. disclose, however, ISO 20022 Webinar, as shown, discloses the following limitations:
The method according to claim 1, wherein the messages sent and received from the respective transaction parties are formatted according to the ISO 20022 standard (ISO 20022 Webinar “What is ISO 20022? Maintenance process – built on strict business justifications and review process - leading to new ‘versions’ of the messages” page 4; “In 2018, the global financial community agreed to migrate from the MT (FIN) payment message standard to ISO 20022” page 5)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for controlling the visibility and/or performance of a contract, wherein the contract may be a smart contract of Wright et al. (‘437, col.2, lines 48-52) and ISO 20022 Webinar explaining benefits of standard like improved data quality, enhanced operational efficiency through higher straight-through processing (STP) rates, and better compliance and risk management with teaching of Mullins et al. for creating an intelligent smart contract on the blockchain at a point of sale system, without requiring the POS system to be equipped with software or hardware for distributed-application programming or blockchain data storage (‘398, col.2, lines 13-17) for maintaining process of building and reviewing business justifications by establishing payment message standards (ISO 20022 Webinar, page 5).
Claim 19 is rejected using the same rationale that was used for the rejection of claim 9.
38. As per claim 10:
Neither Mullins et al., nor Wright et al. disclose, however, ISO 20022 Webinar, as shown, discloses the following limitations:
The method according to claim 9, wherein the messages sent and received from the respective transaction parties are at least one of pacs.002 and pacs.008 messages (ISO 20022 Webinar “Payment, Clearing and Settlement (pacs) messages”. “pacs.008 - Financial Institution to Financial Institution Customer Credit Transfer”. “pacs.002 – FI To FI Payment Status Report”, page 23; “The pacs.008 has two core sets of nested element: Group Header which contain a set of characteristics that relate to all individual transactions, Credit Transfer Transaction Information which contains elements providing information specific to the individual credit transfer transaction”, page 25; “When the customer credit transfer migrates to the pacs 008, there is an option to provide payment status messages utilizing the pacs 002 message. The pacs 002 is a point to point status message and does not carry full comprehensive status information like the gpi tacker service. The pacs 002 or the camt.054 can be used to confirm transaction execution to originating banks”, page 27)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate a method and system for controlling the visibility and/or performance of a contract, wherein the contract may be a smart contract of Wright et al. (‘437, col.2, lines 48-52) and ISO 20022 Webinar explaining benefits of standard like improved data quality, enhanced operational efficiency through higher straight-through processing (STP) rates, and better compliance and risk management with teaching of Mullins et al. for creating an intelligent smart contract on the blockchain at a point of sale system, without requiring the POS system to be equipped with software or hardware for distributed-application programming or blockchain data storage (‘398, col.2, lines 13-17) for describing usage of ISO 20022 pacs.002 and pacs.008 message formats (ISO 20022 Webinar, pages 25, 27).
Claim 20 is rejected using the same rationale that was used for the rejection of claim 10.
Response to Arguments
39. After careful consideration of applicant arguments, the examiner finds them to be not persuasive. Claims 1-20 are rejected.
Rejections under 35 U.S.C. § 112 (b)
40. Rejections of claims1-20 due to amendments of claims 1, 12, and 16-17 are withdrawn.
Rejection under 35 USC § 101
41. Applicant’s arguments toward 35 U.S.C. § 101 rejection is not persuasive. Amended independent claims 1 and 12 do not have additional elements that could lead to an improvement in the functioning of a computer, or an improvement to other technology or technical field.
42. Applicant is of the opinion that “[t]he claims recite a specific technical implementation involving: (i) configuring a smart contract on a blockchain to include an accessibility matrix having defined roles and assignments for the transaction parties; (ii) searching in the accessibility matrix to identify the transaction party corresponding to each condition based on the party's assigned role; (iii) verifying, based on the accessibility matrix, that a received response was sent by the correct transaction party; and (iv) updating the smart contract only upon successful verification… they define a specific mechanism for enforcing role-based access control and verification within a smart contract on a blockchain.”
Examiner respectfully disagrees.
Claims as a whole directed to processing a payment transaction which is grouped under “Certain methods of organizing human activity (e.g., commercial or legal interactions)”.
43. Applicant is of the opinion that “[e]ven assuming, arguendo, that the claims recite an abstract idea, the claims as a whole integrate any such idea into a practical application. Specifically, the claimed accessibility matrix is not a generic computer element applied to an abstract idea - rather, it is an integral component embedded within the smart contract itself on the blockchain. The claimed approach improves the functioning of the blockchain-based payment transaction processing system in at least the following respects. First, the accessibility matrix, as configured within the smart contract, enforces a technical access control mechanism that restricts each transaction party's interaction with the smart contract functions to only those functions authorized by the party's assigned role… Second, the claimed steps of searching the accessibility matrix for the correct transaction party for each condition, and verifying that a received response was sent by the correct party based on the accessibility matrix, impose a specific ordered combination of operations that constrains how the smart contract processes conditions and updates its state. These are not mere data- gathering or output steps - they represent a specific technical architecture in which the smart contract's state transitions are gated by programmatic role-based verification. This specific technical architecture is analogous to the type of self-referential data structure that was found to be patent eligible in Enfish, LLC V. Microsoft Corp., 822 F.3d 1327 (Fed. Cir. 2016), in that the accessibility matrix provides a specific data structure within the smart contract that improves the smart contract's own functioning, rather than merely using the smart contract as a tool to automate an otherwise manual process.”
Examiner respectfully disagrees.
Mentioned above the elements of the claims performed by using the computer components. The use of a processor/computer as a tool to implement the abstract idea does not integrate the abstract idea into a practical application because it requires no more than a computer performing functions that correspond to acts required to carry out the abstract idea. The additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. An ordered combination of the limitations – searching the accessibility matrix for the correct transaction party for each condition, and verifying that a received response was sent by the correct party based on the accessibility matrix – merely implement an abstract idea (commercia/legal interaction) using the additional elements such as a digital asset, a blockchain oracle, a blockchain, a processor, a computer network interface, a memory, at least one peer on a network of the blockchain, blockchain oracle code, and a heartbeat transaction. The claims do not, for example, purport to improve the functioning of a computer. Nor do they effect an improvement in any other technology or technical field. Accordingly, the additional elements do not impose any meaningful limits on practicing the abstract idea, and the claims 1 and 12 are directed to the abstract idea.
44. Applicant is of the opinion that “the claims as amended recite significantly more than any alleged abstract idea. The specific ordered combination of configuring the accessibility matrix within the smart contract, searching the matrix to identify the correct party for each condition, verifying responses against the matrix, and conditionally updating the smart contract only upon successful verification, provides an inventive concept that amounts to significantly more.”
Examiner respectfully disagrees.
Applicant’s argument is not persuasive for the reasons already discussed above – the additional elements do not involve improvements to the functioning of a computer, or to any other technology or technical field. As per the identification of the “additional elements” under Step 2A Prong Two and Step 2B, the rejection properly identifies the elements which are recited in the claim beyond the abstract idea, including “an accessibility matrix, the accessibility matrix including: a plurality of different roles for the plurality transaction parties, and an assignment of each transaction party to at least one of the roles, wherein each role in the accessibility matrix is configured to allow the transaction party who is assigned to the role a right to access one or more functions of the smart contract based on the transaction party's access requirements for the payment transaction; for each transaction party condition of the transaction party conditions”. Under Step 2A Prong Two, the “additional elements” have been identified and the limitations are not indicative of integration into a practical application. Under Step 2B, the additional elements have been evaluated and do not amount to “significantly more”. Note that Revised Step 2A overlaps with Step 2B, and thus, many of the considerations need not be reevaluated in Step 2B because the answer will be the same. The identification of the additional elements in the claim from Step 2A Prong Two is carried over as well as the conclusion from Step 2A Prong Two on the considerations discussed in MPEP 2106.05(a)-(c), (e), (f), and (h).
The claims are not patent eligible.
Rejections under 35 U.S.C. § 103
45. Applicant is of the opinion that the prior art references Rainey et al. and Mullins et al. do not teach independent claims 1 and 12 limitations.
Applicant arguments are no longer applicable because they are moot in light of the new ground of rejection.
Conclusion
46. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US11100502B1 – Rainey et al. – Discloses systems and methods for providing modular and configurable smart contracts for blockchain applications, wherein the smart contracts may be utilized to retain all transaction attribute values in a world state database of the blockchain-implemented ledger.
US11295359B1 – Mullins et al. – Discloses a method for receiving one or more selected options for one or more of multiple contract conditions generated based on transaction information associated with a request to create a blockchain-related invoice and generating instructions for a blockchain-enforced contract based on the transaction information and the one or more selected options.
US20160292672A1 – Fay et al. – Discloses a computer system for providing communications with a distributed blockchain computing system that includes multiple computing nodes, wherein new data transaction requests are added to the order book.
US20200372505A1 – Turgman et al. – Discloses a method and system for generating a smart contract deployed to a distributed ledger platform, wherein a first party and a second party negotiate the terms of an engagement, jointly choose a mediator from those available on a social networking platform, and choose a smart contract template, and a user interface is thereafter presented to the parties for inclusion of negotiable elements
US20170221066A1 – Ledford et al. – Discloses a method, system, apparatus, and computer program for conducting a real-time payment settlement transaction, wherein the method includes determining a prefunded requirement for one or more financial institutions and a prefunded balance is stored, based on a prefunded payment received in a separate funding account, for each of the one or more financial institutions.
47. Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
48. Any inquiry concerning this communication or earlier communications from the examiner should be directed to AMANULLA ABDULLAEV whose telephone number is (571)272-4367. The examiner can normally be reached Monday-Friday 9:30AM -4:30PM ET.
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, Ryan D Donlon can be reached at 571-270-3602. 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.
/AMANULLA ABDULLAEV/ Examiner, Art Unit 3692
/DAVID P SHARVIN/Primary Examiner, Art Unit 3692
Prosecution Insights