Detailed Action
Claims 1-20 are pending and are examined.
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 .
Status of Claims
Claims 1, 5-6, 11-13, and 16 are currently amended.
Response to Remarks
Claim Objections
Applicant’s amendments to the claims have overcome the previous objections. Accordingly, the previous objections are withdrawn.
35 U.S.C. § 112
Applicant’s amendments to the claims have overcome the previous rejections. Accordingly, the previous rejections are withdrawn.
35 U.S.C. § 101
Applicants arguments have been fully considered, and the rejection is maintained. The claims recite computer-implemented operations such as watermarking documents, generating cryptographic hashes, recording those documents and hashes on a blockchain, and generating blockchain certificates. These steps are all performable by generic, conventional computing components and are used merely as tools to carry out an information-management scheme for trade documentation, without any asserted or demonstrated improvement to the functioning of the computer, the network, or the blockchain technology itself. The steps reasonably fall within the abstract idea category of “certain methods of organizing human activity”, including commercial and legal interactions, and recordkeeping for audit and verification. Applicants reliance on Example 40 is unavailing as that example ties the claims to a specific technical solution that reduces network traffic and improves network performance, whereas applicants claims only improve business-side auditability and traceability of documents, not the underlying computer performance. Similarly, the applicant analogy to DDR holdings is inapposite; although the present claims use computer and blockchain functionality, they do so in a straightforward ‘apply-it’ manner to implement an abstract commercial scheme, rather than altering the operation of the computer or network itself as in DDR. Finally, the claims are not comparable to Example 1, which is directed to detecting an isolating malicious code to protect computer resources. Here, any ‘protection’ pertains to documents and business records, not to the security or functioning of the computer system or network. Accordingly, this contention is unpersuasive.
35 U.S.C. § 103
Remark 1: Applicant argues “This particular sequence [described in the independent claims] creates a document-level immutable audit trail that ensures verifiable authenticity and prevents substitution or tampering of individual trade documents. Dowling's event monitoring, Brundage's watermarking of IDs, and Adam's commodity trading system operate at different levels and for different purposes. None of the references, alone or in combination, addresses this technical problem or provides this solution.”. (Applicant Arguments, 2025-09-09). The applicant contends “the present invention ensures that each trade document is uniquely marked, cryptographically hashed, and immutably recorded on a blockchain. This guarantees document- level immutability and auditability, addressing a longstanding problem in international trade transactions where documents can be altered, substituted, or disputed. Such document-level verifiability enhances trust, reduces fraud, and streamlines compliance, providing a tangible technical benefit not found in the cited art.”. (id.)
Response to Remark 1: Examiner respectfully disagrees, as the cited references (e.g. Dowling, Brundage, Adam, Youb, and Gaur) still teach the limitations of the currently amended independent claims, as shown at least in paragraphs 14, 18, 20, & 38 of Dowling, paragraphs 205 & 394 of Youb, and as further outlined in paragraphs 11 & 58 of this action. Indeed, Dowling teaches a blockchain trade-documentation system with buyer and seller devices sending transaction documents to a backend server, where each documents is uniquely hashed to create a record in the blockchain ledger. Youb further describes a Proof-of-Stake based blockchain system (e.g. Polygon) with an underlying EVM capability. Accordingly, this contention is unpersuasive.
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 directed to an abstract idea without significantly more.
Claims 1-11:
Step 1
Claims 1-11 are directed to a computer-implemented system (i.e., machine, and manufacture). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 1 recites (i.e., sets forth or describes) an abstract idea of certification for trade transactions. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A system for blockchain-enabled documentation of trade transactions, the system comprising:
one or more buyer devices associated with respective buyers;
one or more seller devices, associated with respective sellers;
a computer system associated connected with the one or more buyer devices and the one or more seller devices, the computer system including:
a processor; and
a memory unit configured to store machine readable instructions that, when executed by the processor, cause the computer system to:
receive, transaction documents from the one or more buyer devices and the one or more seller devices;
compile a set of transaction documents for each agricultural trade transaction, wherein a transaction from the buyer device is in relation to an event type selected from acceptance of goods or payment by the buyer;
watermark each of the compiled documents with a Unique Acceptance Code (UAC);
generate a unique hash for each document watermarked with the UAC, wherein the hash is either an Inspection Report Code (IRC) or a Commercial Invoice Code (CIC) corresponding to the acceptance of goods or payment by the buyer respectively, which serves as a novel identifier for the said document;
record the generated IRC or CIC onto the blockchain platform, along with the event type and document timestamp, to ensure the immutability and transparency of the transaction data;
generate a blockchain certificate for each event recorded on the blockchain platform; and
utilize the blockchain platform to provide a verifiable and permanent record-keeping system, wherein the immutability of records is achieved through the blockchain's inherent properties, thereby enhancing the security and authenticity of the contracts of the agricultural trade.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 14 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 2-11 have also been analyzed. However, the subject matter of these claims also fails to recite patent eligible subject matter for the following reasons:
Claim 2 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of event-based documentation. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the set of transaction documents comprising at least one of:
an inspection report received from the seller device, confirming the condition of goods supplied by a seller; and
a signed delivery order or commercial invoice from the one or more buyer devices, each related to the event type selected from the acceptance of goods or payment by the buyer, respectively.
Claim 3 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of including time and type information in an identifier. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the UAC includes:
a Deal Transaction Number uniquely identifying the trade transaction;
a Document Sequence and Type indicating the sequential order and category of the document within the transaction; and
a GMT Timestamp marking the exact date and time of document issuance.
Claim 4 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of equating one hash with an identifier. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the unique hash is designated as:
the Inspection Report Code (IRC) for documents corresponding to the acceptance of goods; or
the Commercial Invoice Code (CIC) for documents corresponding to the acceptance of payment by the buyer; each hash serving as a novel identifier for the said document.
Claim 5 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of a certificate certifying the state of a transaction. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein each certificate:
signifies the blockchain's confirmation of the acceptance of goods or payment as per the respective IRC or CIC; and
confirms the completion and immutability of the respective transactions within the agricultural trade process.
Claim 6 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of a polygon-compatible blockchain. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the blockchain is a Polygon blockchain.
Claim 7 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of digitally signing transactions. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the one or more buyer devices further comprise a user interface configured to allow buyers to manually verify and sign the delivery order or commercial invoice digitally within the device before providing it to the system.
Claim 8 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of visual inspection. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the one or more seller devices include an imaging component configured to capture visual confirmation of the goods for inclusion in the inspection report, and which integrates with the system to facilitate automatic watermarking with the UAC.
Claim 9 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of hash encryption. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising a cryptographic module managed by the processor that encrypts the unique hash for each document to enhance security before recording on the blockchain platform.
Claim 10 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of contract compliance checking. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the processor is further configured to verify the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws.
Claim 11 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of checking compliance prior to hash issuance. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the memory unit contains additional machine-readable instructions that, when executed by the processor, enable the system to automatically match buyers with sellers based on the availability of goods and requirements, thereby facilitating the formation of digital contracts within the agricultural trade process.
Claims 12-20:
Step 1
Claim 12 is directed to a computer-implemented method (i.e., process). Therefore, these claims fall within the four statutory categories of invention, and thus must be further analyzed at Step 2A to determine if the claims are directed to a judicial exception (See MPEP 2106.03, subsection II).
Step 2A Prong One
In Prong One examiners evaluate whether the claim recites a judicial exception, i.e., whether a law of nature, natural phenomenon, or abstract idea is set forth or described in the claim. Claim 12 recites (i.e., sets forth or describes) an abstract idea of certification for trade transactions. Specifically, but for the additional elements, the claim under its broadest reasonable interpretation recites limitations grouped within the “certain methods of organizing human activity” grouping of abstract ideas. The certain method of organizing human activity grouping is used to describe fundamental economic principles or practices, commercial or legal interactions, and managing personal behavior or relationships or interactions between people. Fundamental economic principles or practices are relating to the economy and commerce, or recite hedging, insurance, and mitigating risks. Commercial or legal interactions recite agreements in the form of contracts, legal obligations, advertising, marketing or sales activities or behaviors, and business relations. Managing personal behavior or relationships or interactions between people recite social activities, teaching, and following rules or instructions. See MPEP § 2106.04(a)(2), subsection II. The claim limitations reciting the abstract ideas are grouped within the “certain methods of organizing human activity” grouping of abstract ideas because the limitations recite fundamental economic principles or practices, as they recite mitigating risk, commercial or legal interactions, as they recite sales activities or behaviors, and concepts that can practically be performed in the human mind, with or without the use of a physical aid. More specifically, the following underlined claim elements recite abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a).
A computer-implemented method for blockchain-enabled documentation of trade transactions, the method comprising steps of:
receiving, transaction documents from one or more buyers and one or more sellers;
compiling a set of transaction documents for each agricultural trade transaction, wherein a transaction from the buyer device is in relation to an event type selected from acceptance of goods or payment by the buyer;
watermarking each of the compiled documents with a Unique Acceptance Code (UAC);
generating a unique hash for each document watermarked with the UAC, wherein the hash is either an Inspection Report Code (IRC) or a Commercial Invoice Code (CIC) corresponding to the acceptance of goods or payment by the buyer respectively, which serves as a novel identifier for the said document;
recording the generated IRC or CIC onto the blockchain, along with the event type and document timestamp, to ensure the immutability and transparency of the transaction data;
generating a blockchain certificate for each event recorded on the blockchain platform;
utilizing the blockchain platform to provide a verifiable and permanent record-keeping system, wherein the immutability of records is achieved through the blockchain's inherent properties, thereby enhancing the security and authenticity of the agricultural trade documents.
Step 2A Prong Two
In Prong Two, examiners evaluate whether the claim as a whole integrates the exception into a practical application of that exception. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception. Here, claim 1 as a whole, looking at the identified additional elements individually and in combination, does not integrate the judicial exception into a practical application. First, the non-underlined additional elements merely serve as a tool to perform the abstract idea (MPEP § 2106.05(f)). Additionally, regarding the specification and claims, there is no improvement in the functioning of a computer or an improvement to other technology or technical field present (MPEP §§ 2106.04(d)(1) and 2106.05(a)), there is no applying or using the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition present (MPEP § 2106.04(d)(2)), there is no implementing the judicial exception with or using the judicial exception in conjunction with a particular machine or manufacture that is integral to the claim present (MPEP § 2106.05(b)), there is no effecting a transformation or reduction of a particular article to a different state or thing present (MPEP § 2106.05(c)), and there is no applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment present, such that the claim as a whole is more than a drafting effort designed to monopolize the exception (MPEP § 2106.05(e)). Thus, the claim as a whole is directed to a judicial exception and thus requires further analysis at Step 2B to determine if the claim as a whole, amounts to significantly more than the exception itself (See MPEP 2106.04, subsection II).
Step 2B
Step 2B determines whether the claim as a whole amount to significantly more than the exception itself. Evaluating additional elements to determine whether they amount to an inventive concept requires considering them both individually and in combination to ensure that they amount to significantly more than the judicial exception itself. Here, the additional elements, taken individually and in combination, do not result in claim 1, as a whole, amounting to significantly more than the judicial exception. As discussed previously with respect to Step 2A, the additional elements merely serve as a tool to perform an abstract idea. Thus, there is no inventive concept in the claim and thus the claim is not eligible, warranting a rejection for lack of subject matter eligibility and concluding the eligibility analysis.
Dependent Claims:
Claims 13-20 have also been analyzed. However, the subject matter of these claims also fail to recite patent eligible subject matter for the following reasons:
Claim 13 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of documentation of inspection/acceptance. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the set of documents comprising at least:
an inspection report confirming the condition of goods supplied by a seller; and
a signed delivery order or commercial invoice, each related to the acceptance of goods or payment by a buyer, respectively.
Claim 14 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of including time and type information in an identifier. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the UAC includes:
a Deal Transaction Number uniquely identifying the trade transaction;
a Document Sequence and Type indicating the sequential order and category of the document within the transaction; and
a GMT Timestamp marking the exact date and time of document issuance.
Claim 15 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of equating one hash with an identifier. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein the unique hash is designated as:
an Inspection Report Code (IRC) for documents corresponding to the acceptance of goods; or
a Commercial Invoice Code (CIC) for documents corresponding to the acceptance of payment by the buyer; each hash serving as a novel identifier for the said document.
Claim 16 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of certifying a transactions state. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
wherein each certificate:
signifies the blockchain's confirmation of the acceptance of goods or payment as per the respective IRC or CIC; and
confirms the completion and immutability of the respective transactions within the agricultural trade process.
Claim 17 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of device-based buyer confirmation. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising step of allowing buyers to manually verify and sign the delivery order or commercial invoice digitally within the device before providing it to the system.
Claim 18 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of visual confirmation for inspection. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
comprising step of capturing visual confirmation of the goods for inclusion in the inspection report, and which integrates with the system to facilitate automatic watermarking with the UAC.
Claim 19 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of encrypting a hash. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
further comprising step of encrypting the unique hash for each document to enhance security before recording on the blockchain platform.
Claim 20 recites the following underlined claim elements as abstract ideas while the non-underlined claim elements recite additional elements according to MPEP 2106.04(a). The claim recites the abstract idea of verifying contract compliance. In other words, it recites limitations grouped within the “certain methods of organizing human activity” . The non-underlined additional elements fail to recite a practical application or significantly more than the abstract idea because it merely serves as a tool to perform the abstract idea (MPEP § 2106.05(f)).
comprising step of verifying the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws.
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.
Claims 1-5, 7-9, and 11-19 are rejected under 35 U.S.C. 103 as being unpatentable over Dowling et al. (US20180268479A1) (hereinafter “Dowling”) in view of Brundage et al. (US20070016790A1) (hereinafter “Brundage”) in further view of Adam at al. (US20020069156A1) (hereinafter “Adam”)
As per Claim 1, Dowling teaches:
A system for blockchain-enabled documentation of trade transactions, the system comprising: one or more buyer devices associated with respective buyers; (“FIG. 1 is a block diagram illustrating a system 100 structured to perform a commercial trade finance transaction using a BLC, according to an example embodiment. The system 100 includes trade finance blockchain computing system 102, a trade finance blockchain 104, a buyer 106, an issuing bank 108, an advising bank 110, a seller 112, a good 113, a freight forwarder 114, and a shipping company 116, each being in operative communication via a network 118. By way of example, the system 100 will be described in connection with an international trade finance transaction involving the seller 112 exporting the good 113 from a first country and the buyer 106 importing the good 113 into a second country.”) (Para. 0016); (“The buyer 106 is a party applying for the issuance of the BLC 120, and may also be referred to as the “applicant.” The buyer 106 is the party importing the good 113. In this example, the buyer 106 has a bank account with the issuing bank 108.”) (Para. 0024); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032);
one or more seller devices, associated with respective sellers; (“FIG. 1 is a block diagram illustrating a system 100 structured to perform a commercial trade finance transaction using a BLC, according to an example embodiment. The system 100 includes trade finance blockchain computing system 102, a trade finance blockchain 104, a buyer 106, an issuing bank 108, an advising bank 110, a seller 112, a good 113, a freight forwarder 114, and a shipping company 116, each being in operative communication via a network 118. By way of example, the system 100 will be described in connection with an international trade finance transaction involving the seller 112 exporting the good 113 from a first country and the buyer 106 importing the good 113 into a second country.”) (Para. 0016); (“The seller 112 is the party in whose favor the LC is issued, and who will receive payment if all the conditions and terms of the BLC 120 are met. The seller 112 may also be referred to as the “beneficiary.” The seller 112 is the party exporting the good 113. In this example, the seller 112 has a bank account with the advising bank 110.”) (Para. 0027); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032);
a computer system associated with the one or more buyer devices and the one or more seller devices, the computer system including: a processor; and a memory unit configured to store machine readable instructions that, when executed by the processor, cause the computer system to: (“The trade finance blockchain computing system 102 is structured to facilitate and manage trade finance products and services, such as BLCs. Detailed components of the trade finance blockchain computing system 102 are described in further detail in connection with FIG. 2. In some embodiments, the trade finance blockchain computing system 102 is managed by a financial institution, such as a bank. For example, in some embodiments, the trade finance blockchain computing system 102 is managed by one of the issuing bank 108 and the advising bank 110. In other embodiments, the trade finance blockchain computing system 102 is managed by a governmental entity or a third-party.”) (Para. 0017); (“FIG. 2 is a block diagram of the trade finance blockchain computing system 102 of FIG. 1, according to an example embodiment. The trade finance blockchain computing system 102 includes a network interface 202, an accounts database 204, a KYC whitelist 206, an authorization circuit 208, a trade financing circuit 210, a blockchain circuit 212, an event circuit 214, a risk analysis circuit 226, a variable trade financing circuit 218, a securitization circuit 220, and a marketplace circuit 222.”) (Para. 0030); (“The “circuit” may also include one or more processors communicatively coupled to one or more memory or memory devices. In this regard, the one or more processors may execute instructions stored in the memory or may execute instructions otherwise accessible to the one or more processors. In some embodiments, the one or more processors may be embodied in various ways. The one or more processors may be constructed in a manner sufficient to perform at least the operations described herein. In some embodiments, the one or more processors may be shared by multiple circuits (e.g., circuit A and circuit B may comprise or otherwise share the same processor which, in some example embodiments, may execute instructions stored, or otherwise accessed, via different areas of memory).”) (Para. 0057);
receive, transaction documents from the one or more buyer devices and the one or more seller devices; (“Conventional trade finance systems, such as those facilitating LCs, operate based on a flow of documents between parties and banks, which may be referred to as a “documentary flow.” The documentary flow includes a series of steps involving the transfer, analysis, and approval of certain documents. Each step must be completed in order to satisfy the requirements of the LC, and to ultimately release payment for the trade transaction.”) (Para. 0009); (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“In general, risks decrease over time as portions of a BLC 120 are completed. For example, documentary risks decrease as the trade finance blockchain computing system 102 receives, verifies, and authenticates documents associated with the BLC 120. Similarly, supply chain risks decrease as the good 113 progresses through the supply chain. To this end, the risk analysis circuit 226 is tasked with analyzing the various risks associated with the BLC 120 over time. For example, in one embodiment, the risk analysis circuit 216 is structured to assign a first risk level associated with the trade transaction prior completion of one of the documentary or supply chain flow events, and a second risk level associated with the trade transaction after completion of one of the documentary and/or supply chain flow events. In effect, the difference between the first and second risk levels represents the risk that the corresponding documentary or supply chain flow events will not occur. The risk analysis circuit 216 may define risk levels associated with any of the documentary and supply chain flow events identified in the BLC 120. As will be appreciated, the risk levels may be utilized to trigger interest rate adjustments, partial payments, or pricing of securities associated with the BLC 120.”) (Para. 0043);
compile the received transaction documents into a set for each . . ., wherein a transaction from the buyer device is in relation to an event type selected from acceptance of goods or payment by the buyer; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“According to various embodiments, the BLC 120 may define certain documentary flow events and/or supply chain flow events as triggering payments, risk calculations, and interest rate adjustments, among other things. For example, a documentary flow payment trigger event and a supply chain flow payment trigger event may define the final events in the contract. In one embodiment, the BLC 120 is structured to transfer payment for the contract in response to detecting occurrence of both of the documentary flow payment trigger event and the supply chain flow payment trigger event. In some embodiments, the BLC 120 is structured to transfer payment for the contract, in whole or in part, in response to detecting occurrence of one of the documentary flow payment trigger event and the supply chain flow payment trigger event.”) (Para. 0038); (“Various embodiments also relate to trade financing via a variable trade financing profile. An example variable trade financing profile may include several incremental partial payment amounts triggered by monitored documentary and/or supply chain flow events. The ability to monitor documentary and supply chain flow throughout the lifecycle of the trade financing transaction enables enhanced analysis of documentary risk and supply chain risk at improved levels of granularity. In addition, linking the documentary flow events with the supply chain flow events enables overall dynamic trade financing risk to be analyzed at levels of granularity and accuracy not previously available. By better analyzing risk, banks may provide superior trade financing products, resulting in lower cost and better performance for the customer. For example, in one embodiment, a variable trade financing profile defines levels of incremental funding provided as the trade transaction progresses. In another embodiment, a variable trade financing profile defines an interest rate that is reduced as the trade transaction progresses.”) (Para. 0014);
. . . each of the compiled documents with a Unique Acceptance Code (UAC); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037);
generate a unique hash for each of the compiled document . . . with the UAC, wherein the hash is either an Inspection Report Code (IRC) or a Commercial Invoice Code (CIC) corresponding to the acceptance of goods or payment by the buyer respectively, which serves as a novel identifier for the respective document; (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018)
record the generated IRC or CIC onto the blockchain platform, along with the event type and document timestamp, to ensure the immutability and transparency of the transaction data; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040); (“A plurality of documentary flow events related to the BLC are tracked. In response to detecting occurrence of each of the plurality of documentary flow events, the respective documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. A plurality of supply chain flow events are tracked. Each of the plurality of supply chain flow events are related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the respective supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. Payment for the contract for the trade transaction is transferred to the seller in response to detecting occurrence of both of the documentary flow event corresponding to the documentary flow payment trigger event and the supply chain flow event corresponding to the supply chain flow payment trigger event.”) (Para. 0004);
generate a blockchain certificate for each event recorded on the blockchain platform; and (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The BLC defines a documentary flow payment trigger event and a supply chain flow payment trigger event. A blockchain circuit is structured to store the BLC on a blockchain. The BLC is accessible by each of the seller and the buyer to view a status of the trade transaction. An event circuit structured to track a plurality of documentary flow events related to the BLC. In response to detecting occurrence of each of the plurality of documentary flow events, the tracked documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. The event circuit is also structured to track a plurality of supply chain flow events. Each of the plurality of supply chain flow events being related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the tracked supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. The trade financing circuit is further structured to, in response to detecting occurrence of both of a first documentary flow event of the plurality of documentary flow events corresponding to the documentary flow payment trigger event and a first supply chain flow event of the plurality of supply chain flow events corresponding to the supply chain flow payment trigger event, transfer payment for the contract for the trade transaction to the seller.”) (Para. 0005)
utilize the blockchain platform to provide a verifiable and permanent record-keeping system, wherein the immutability of records is achieved through the blockchain's inherent properties, thereby enhancing the security and authenticity of the contracts in an . . ..; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018);
Dowling does not disclose:
• “watermark” (claim 1).
However, as per Claim 1, Brundage in the analogous art of multi-factor authentication, teaches: “watermark”. (See “An identification document may include a digital watermark. Digital watermarking is a process for modifying physical or electronic media to embed a machine-readable code into the media. The media may be modified such that the embedded code is imperceptible or nearly imperceptible to the user, yet may be detected through an automated detection process. In some of our preferred embodiments, an identification document includes two or more digital watermarks. Digital watermarking systems typically have two primary components: an encoder that embeds the digital watermark in a host media signal, and a decoder that detects and reads the embedded digital watermark from a signal suspected of containing a digital watermark (a suspect signal). The encoder embeds a digital watermark by altering the host media signal. The alterations usually take the form of altered signal values, such as slightly changed pixel values, luminance, colors, changed DCT coefficients, altered signal values or selective placement or signal tweaks, etc. However, a watermark can also be manifested in other ways, such as changes in the surface microtopology of a medium, localized chemical changes (e.g. in photographic emulsions), localized variations in optical density, localized changes in luminescence, etc. The surface texture of an object may be altered to create a watermark pattern. This may be accomplished by manufacturing an object in a manner that creates a textured surface or by applying material to the surface (e.g., an invisible film or ink) in a subsequent process. The watermark reading component analyzes content to detect whether a watermark pattern is present. In applications where the watermark encodes information, the reading component extracts this information from the detected watermark. The reading component analyzes a suspect signal to detect whether a digital watermark is present. The reading component can be hosted on a wide variety of units ranging from tethered or wireless reader devices, conventional personal computers, network servers, cell phones including cameras, to fully mobile readers with built-in displays. Image data corresponding to a watermarked surface of an identification document is read and decoded by this reader to obtain a watermark's information or “payload”.” (para. 0014-0015); “Sometimes the printed indicia is printed with visible or invisible (e.g., UV or IR) inks. Of course, the ID document 100 may include a wide variety of other features like optical or magnetic memory, microprinting, holograms, Kinograms®, electronic circuitry (e.g., a so-called smart card), ghost or faintly reproduced images, etc., etc.” (para. 0174); “It will be appreciated that the information encoded with the photograph need not necessarily correlate with other information on an identification document. For example, the scanning system may need only to confirm the existence of the identification code so that the user may be provided with a “go” or “no go” indication of whether the photograph has been tampered with. It will also be appreciated that the local computer, using an encrypted digital communications line, could send a packet of information to a central verification facility, which thereafter returns an encrypted “go” or “no go” indication.” (para. 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Dowling with the technique of Brundage to include digital watermarking in the tracking/authentication process. Therefore, the incentives of providing increased data security and downstream validation/tracking for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Dowling in view of Brundage does not disclose:
• “agricultural trade transaction” (claim 1).
However, as per Claim 1, Adam in the analogous art of secure digitally-based supply chain tracking systems, teaches: “agricultural trade transaction”. (See “Generally, the invention might be best understood as a system and method for implementing a true level- 2 trading methodology in the context of perishable agricultural commodities, complete with streaming quotes, and real-time display of seller “asks” and buyer “bids”. In order to enhance the immediacy of this agricultural trading exchange, information is delivered to both buyers and sellers through the medium of the World Wide Web (the Internet) which defines a platform allowing information delivery direct to a buyer's or seller's computer system, without requiring the intermediary of a broker and certainly without requiring the intermediary of a centralized institutional exchange, complete with “trading pit” and institutionalized traders. In the context of the present invention, the agricultural trading exchange exists in electronic form, as an application software routine running on a centralized server system, that itself functions as the intermediary between large numbers of buyers and sellers that could be separated from one another by continental distances. Both buyers and sellers register as traders with the agricultural trading exchange according to the invention, and are able to trade from their personal computers, whether desktop, laptop or palmtop, using suitable application specific software programs based on Internet standards (HTML, XML and TCP/IP). It should be noted that the present invention is particularly suited for Wireless Application Protocol-Enabled Software in the particular case where a user might wish to maintain communication with the commodity exchange using mobile or wireless service. To digress momentarily, WAP is an application communication protocol used to access services and information for hand held devices such as mobile phones. In order to fit within such small wireless devices, WAP makes use of a micro browser, a truncated set of software that makes minimal demands on hardware, memory and CPU time and is able to display information within a restricted mark-up language termed Wireless Mark-Up Language (WML). It should therefore be understood that the following detailed description of systems and methods in accordance with the invention, is not necessarily limited to desktop, laptop or palmtop-type computer systems, but is particularly suited for the type of device that a grower might easily be able to carry with them while working amongst the crops. Buyers and sellers, in the agricultural exchange according to the invention, are not constrained in their normal everyday movements and are not restricted in the other activities which they may wish to undertake.” (para. 0026); “Simultaneously, the seller receives a purchase notification from the exchange including all of the necessary data and information that the seller needs to ship the particular quantity of produce to that particular buyer. The seller invoices the buyer, and delivers the produce to the loading dock, whence it is shipped to the buyer's receiving facility. Once received, the exchange obtains delivery notification, either from the purchaser or from the shipper, and transfers actual funds from the buyer's account to the seller's account, making sure to credit any interim interest earned on the buyer's funds to the buyer.” (para. 0094); “Additional pages that are available through the activity window 64 include an alert page through which a user is able to structure a list of commodities that they are interested in trading. In the case of a wholesale buyer, the structured list might be a list of those commodities which they are interested in purchasing at a particular price or which might be available in a particular quantity. For example, if a wholesale buyer is interested in making a purchase of a large lot size of broccoli 14's at a price of $5.25, for example, and the asking price is $5.40, the buyer might structure his alert page to give him a notification whenever an “ask” order is posted which has a price in the general neighborhood of $5.25. Alerts may be set up to bracket a price, for example, i.e., between $5.15 and $5.35, or set a trigger threshold, i.e., less than $5.35, or even provide an alert on the basis of a price trend metric such as 2 or 3 trades in a row with increasing or decreasing prices. Further, as will be explained in greater detail below, a user may request an alert when a particular buyer or seller enters the market with a particular commodity. Since many buyers and sellers have long-standing relationships, a wholesale buyer for Kroger Foods, for example, may wish to receive an alert when broccoli crowns are offered by Adam Brothers Farming, Inc., for example.” (para. 0048).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Adam to provide verifiable agricultural trade records. Therefore, the incentives of providing increased auditability and post-sale accountability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 2, Dowling teaches:
The system as claimed in claim 1, wherein the set of transaction documents comprising at least one of: an inspection report received from the seller device, confirming the condition of goods supplied by a seller; and a signed delivery order or commercial invoice from the one or more buyer devices, each related to the event type selected from the acceptance of goods or payment by the buyer, respectively.; (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“According to various embodiments, the BLC 120 may define certain documentary flow events and/or supply chain flow events as triggering payments, risk calculations, and interest rate adjustments, among other things. For example, a documentary flow payment trigger event and a supply chain flow payment trigger event may define the final events in the contract. In one embodiment, the BLC 120 is structured to transfer payment for the contract in response to detecting occurrence of both of the documentary flow payment trigger event and the supply chain flow payment trigger event. In some embodiments, the BLC 120 is structured to transfer payment for the contract, in whole or in part, in response to detecting occurrence of one of the documentary flow payment trigger event and the supply chain flow payment trigger event.”) (Para. 0038); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 3, Dowling teaches:
The system as claimed in claim 1, wherein the UAC includes: a Deal Transaction Number uniquely identifying the trade transaction; a Document Sequence and Type indicating the sequential order and category of the document within the transaction; and a GMT Timestamp marking the exact date and time of document issuance.; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 4, Dowling teaches:
The system as claimed in claim 1, wherein the unique hash is designated as: the Inspection Report Code (IRC) for documents corresponding to the acceptance of goods; or the Commercial Invoice Code (CIC) for documents corresponding to the acceptance of payment by the buyer; each hash serving as a novel identifier for the said document.; (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020)
As per Claim 5, Dowling teaches:
The system as claimed in claim 1, wherein each certificate: signifies the blockchain's confirmation of the acceptance of goods or payment as per the respective IRC or CIC; and confirms the completion and immutability of the respective transactions within the . . .. (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The BLC defines a documentary flow payment trigger event and a supply chain flow payment trigger event. The BLC is stored on a blockchain. The BLC is accessible by each of the seller and the buyer to view a status of the trade transaction. A plurality of documentary flow events related to the BLC are tracked. In response to detecting occurrence of each of the plurality of documentary flow events, the respective documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. A plurality of supply chain flow events are tracked. Each of the plurality of supply chain flow events are related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the respective supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. Payment for the contract for the trade transaction is transferred to the seller in response to detecting occurrence of both of the documentary flow event corresponding to the documentary flow payment trigger event and the supply chain flow event corresponding to the supply chain flow payment trigger event.”) (Para. 0004); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020).
Dowling in view of Brundage does not disclose:
• “agricultural trade transaction” (claim 5).
However, as per Claim 5, Adam in the analogous art of secure digitally-based supply chain tracking systems, teaches: “agricultural trade transaction”. (See “Generally, the invention might be best understood as a system and method for implementing a true level- 2 trading methodology in the context of perishable agricultural commodities, complete with streaming quotes, and real-time display of seller “asks” and buyer “bids”. In order to enhance the immediacy of this agricultural trading exchange, information is delivered to both buyers and sellers through the medium of the World Wide Web (the Internet) which defines a platform allowing information delivery direct to a buyer's or seller's computer system, without requiring the intermediary of a broker and certainly without requiring the intermediary of a centralized institutional exchange, complete with “trading pit” and institutionalized traders. In the context of the present invention, the agricultural trading exchange exists in electronic form, as an application software routine running on a centralized server system, that itself functions as the intermediary between large numbers of buyers and sellers that could be separated from one another by continental distances. Both buyers and sellers register as traders with the agricultural trading exchange according to the invention, and are able to trade from their personal computers, whether desktop, laptop or palmtop, using suitable application specific software programs based on Internet standards (HTML, XML and TCP/IP). It should be noted that the present invention is particularly suited for Wireless Application Protocol-Enabled Software in the particular case where a user might wish to maintain communication with the commodity exchange using mobile or wireless service. To digress momentarily, WAP is an application communication protocol used to access services and information for hand held devices such as mobile phones. In order to fit within such small wireless devices, WAP makes use of a micro browser, a truncated set of software that makes minimal demands on hardware, memory and CPU time and is able to display information within a restricted mark-up language termed Wireless Mark-Up Language (WML). It should therefore be understood that the following detailed description of systems and methods in accordance with the invention, is not necessarily limited to desktop, laptop or palmtop-type computer systems, but is particularly suited for the type of device that a grower might easily be able to carry with them while working amongst the crops. Buyers and sellers, in the agricultural exchange according to the invention, are not constrained in their normal everyday movements and are not restricted in the other activities which they may wish to undertake.” (para. 0026); “Simultaneously, the seller receives a purchase notification from the exchange including all of the necessary data and information that the seller needs to ship the particular quantity of produce to that particular buyer. The seller invoices the buyer, and delivers the produce to the loading dock, whence it is shipped to the buyer's receiving facility. Once received, the exchange obtains delivery notification, either from the purchaser or from the shipper, and transfers actual funds from the buyer's account to the seller's account, making sure to credit any interim interest earned on the buyer's funds to the buyer.” (para. 0094); “Additional pages that are available through the activity window 64 include an alert page through which a user is able to structure a list of commodities that they are interested in trading. In the case of a wholesale buyer, the structured list might be a list of those commodities which they are interested in purchasing at a particular price or which might be available in a particular quantity. For example, if a wholesale buyer is interested in making a purchase of a large lot size of broccoli 14's at a price of $5.25, for example, and the asking price is $5.40, the buyer might structure his alert page to give him a notification whenever an “ask” order is posted which has a price in the general neighborhood of $5.25. Alerts may be set up to bracket a price, for example, i.e., between $5.15 and $5.35, or set a trigger threshold, i.e., less than $5.35, or even provide an alert on the basis of a price trend metric such as 2 or 3 trades in a row with increasing or decreasing prices. Further, as will be explained in greater detail below, a user may request an alert when a particular buyer or seller enters the market with a particular commodity. Since many buyers and sellers have long-standing relationships, a wholesale buyer for Kroger Foods, for example, may wish to receive an alert when broccoli crowns are offered by Adam Brothers Farming, Inc., for example.” (para. 0048).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Adam to provide verifiable agricultural trade records. Therefore, the incentives of providing increased auditability and post-sale accountability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 7, Dowling teaches:
The system as claimed in claim 1, wherein the one or more buyer devices further comprise a user interface configured to allow buyers to manually verify and sign the delivery order or commercial invoice digitally within the device before providing it to the system. (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032); (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 8, Dowling teaches:
The system as claimed in claim 1, wherein the one or more seller devices include an imaging component configured to capture visual confirmation of the goods for inclusion in the inspection report, and which integrates with the system to facilitate automatic . . . with the UAC. (“The good 113 is the product that is the subject of the BLC 120, and is being sold by the seller 112 to the buyer 106. In some embodiments, the good 113 includes a transmitter 126 for transmitting a physical status of the good 113 within a supply chain flow to the trade finance blockchain computing system 102. For example, the transmitter 126 may transmit a geolocation of the good 113 to the trade finance blockchain computing system 102. In some embodiments, the transmitter 126 is an RFID tag. In some embodiments, the good 113 includes a one- or two-dimensional barcode in addition to or instead of the transmitter 126. In such embodiments, the barcode is scanned using a scanner at various points during the supply chain process, and the physical status information is transmitted to the trade finance blockchain computing system 102. The transmitter 126 or barcode may be integrated or attached to the packaging of the good 113, or may be integral to the good 113.”) (Para. 0029); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040).
Dowling does not disclose:
• “watermark” (claim 8).
However, as per Claim 8, Brundage in the analogous art of multi-factor authentication, teaches: “watermark”. (See “An identification document may include a digital watermark. Digital watermarking is a process for modifying physical or electronic media to embed a machine-readable code into the media. The media may be modified such that the embedded code is imperceptible or nearly imperceptible to the user, yet may be detected through an automated detection process. In some of our preferred embodiments, an identification document includes two or more digital watermarks. Digital watermarking systems typically have two primary components: an encoder that embeds the digital watermark in a host media signal, and a decoder that detects and reads the embedded digital watermark from a signal suspected of containing a digital watermark (a suspect signal). The encoder embeds a digital watermark by altering the host media signal. The alterations usually take the form of altered signal values, such as slightly changed pixel values, luminance, colors, changed DCT coefficients, altered signal values or selective placement or signal tweaks, etc. However, a watermark can also be manifested in other ways, such as changes in the surface microtopology of a medium, localized chemical changes (e.g. in photographic emulsions), localized variations in optical density, localized changes in luminescence, etc. The surface texture of an object may be altered to create a watermark pattern. This may be accomplished by manufacturing an object in a manner that creates a textured surface or by applying material to the surface (e.g., an invisible film or ink) in a subsequent process. The watermark reading component analyzes content to detect whether a watermark pattern is present. In applications where the watermark encodes information, the reading component extracts this information from the detected watermark. The reading component analyzes a suspect signal to detect whether a digital watermark is present. The reading component can be hosted on a wide variety of units ranging from tethered or wireless reader devices, conventional personal computers, network servers, cell phones including cameras, to fully mobile readers with built-in displays. Image data corresponding to a watermarked surface of an identification document is read and decoded by this reader to obtain a watermark's information or “payload”.” (para. 0014-0015); “Sometimes the printed indicia is printed with visible or invisible (e.g., UV or IR) inks. Of course, the ID document 100 may include a wide variety of other features like optical or magnetic memory, microprinting, holograms, Kinograms®, electronic circuitry (e.g., a so-called smart card), ghost or faintly reproduced images, etc., etc.” (para. 0174); “It will be appreciated that the information encoded with the photograph need not necessarily correlate with other information on an identification document. For example, the scanning system may need only to confirm the existence of the identification code so that the user may be provided with a “go” or “no go” indication of whether the photograph has been tampered with. It will also be appreciated that the local computer, using an encrypted digital communications line, could send a packet of information to a central verification facility, which thereafter returns an encrypted “go” or “no go” indication.” (para. 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Dowling with the technique of Brundage to include digital watermarking in the tracking/authentication process. Therefore, the incentives of providing increased data security and downstream validation/tracking for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 9, Dowling teaches:
The system as claimed in claim 1, further comprising a cryptographic module managed by the processor that encrypts the unique hash for each document to enhance security before recording on the blockchain platform. (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037); (“As used herein, the term “circuit” may include hardware structured to execute the functions described herein. In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.”) (Para. 0056);
As per Claim 11, Dowling teaches:
The system as claimed in claim 1, wherein the memory unit contains additional machine-readable instructions that, when executed by the processor, enable the system to automatically match buyers with sellers based on the availability of goods and requirements, thereby facilitating the formation of digital contracts within the . . .. (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“In some embodiments, the trade financing circuit 210 interfaces with a third-party system to create BLCs 120. For example, in some embodiments, the buyer 106 interfaces with the third-party system to create a smart contract associated with the BLC. For example, in some embodiments, the third-party creates a bracket-based obligation (“BBO”) based on a request received from the buyer 106. The third-party system may send a request for approval of the BBO to the issuing bank 108, and may generate the BLC 120 upon receiving approval. In such embodiments, the trade financing circuit 210 may monitor and manage performance of the BLC 120.”) (Para. 0036); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037).
Dowling in view of Brundage does not disclose:
• “agricultural trade” (claim 11).
However, as per Claim 11, Adam in the analogous art of secure digitally-based supply chain tracking systems, teaches: “agricultural trade”. (See “Generally, the invention might be best understood as a system and method for implementing a true level- 2 trading methodology in the context of perishable agricultural commodities, complete with streaming quotes, and real-time display of seller “asks” and buyer “bids”. In order to enhance the immediacy of this agricultural trading exchange, information is delivered to both buyers and sellers through the medium of the World Wide Web (the Internet) which defines a platform allowing information delivery direct to a buyer's or seller's computer system, without requiring the intermediary of a broker and certainly without requiring the intermediary of a centralized institutional exchange, complete with “trading pit” and institutionalized traders. In the context of the present invention, the agricultural trading exchange exists in electronic form, as an application software routine running on a centralized server system, that itself functions as the intermediary between large numbers of buyers and sellers that could be separated from one another by continental distances. Both buyers and sellers register as traders with the agricultural trading exchange according to the invention, and are able to trade from their personal computers, whether desktop, laptop or palmtop, using suitable application specific software programs based on Internet standards (HTML, XML and TCP/IP). It should be noted that the present invention is particularly suited for Wireless Application Protocol-Enabled Software in the particular case where a user might wish to maintain communication with the commodity exchange using mobile or wireless service. To digress momentarily, WAP is an application communication protocol used to access services and information for hand held devices such as mobile phones. In order to fit within such small wireless devices, WAP makes use of a micro browser, a truncated set of software that makes minimal demands on hardware, memory and CPU time and is able to display information within a restricted mark-up language termed Wireless Mark-Up Language (WML). It should therefore be understood that the following detailed description of systems and methods in accordance with the invention, is not necessarily limited to desktop, laptop or palmtop-type computer systems, but is particularly suited for the type of device that a grower might easily be able to carry with them while working amongst the crops. Buyers and sellers, in the agricultural exchange according to the invention, are not constrained in their normal everyday movements and are not restricted in the other activities which they may wish to undertake.” (para. 0026); “Simultaneously, the seller receives a purchase notification from the exchange including all of the necessary data and information that the seller needs to ship the particular quantity of produce to that particular buyer. The seller invoices the buyer, and delivers the produce to the loading dock, whence it is shipped to the buyer's receiving facility. Once received, the exchange obtains delivery notification, either from the purchaser or from the shipper, and transfers actual funds from the buyer's account to the seller's account, making sure to credit any interim interest earned on the buyer's funds to the buyer.” (para. 0094); “Additional pages that are available through the activity window 64 include an alert page through which a user is able to structure a list of commodities that they are interested in trading. In the case of a wholesale buyer, the structured list might be a list of those commodities which they are interested in purchasing at a particular price or which might be available in a particular quantity. For example, if a wholesale buyer is interested in making a purchase of a large lot size of broccoli 14's at a price of $5.25, for example, and the asking price is $5.40, the buyer might structure his alert page to give him a notification whenever an “ask” order is posted which has a price in the general neighborhood of $5.25. Alerts may be set up to bracket a price, for example, i.e., between $5.15 and $5.35, or set a trigger threshold, i.e., less than $5.35, or even provide an alert on the basis of a price trend metric such as 2 or 3 trades in a row with increasing or decreasing prices. Further, as will be explained in greater detail below, a user may request an alert when a particular buyer or seller enters the market with a particular commodity. Since many buyers and sellers have long-standing relationships, a wholesale buyer for Kroger Foods, for example, may wish to receive an alert when broccoli crowns are offered by Adam Brothers Farming, Inc., for example.” (para. 0048).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Adam to provide verifiable agricultural trade records. Therefore, the incentives of providing increased auditability and post-sale accountability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 12, Dowling teaches:
A computer-implemented method for blockchain-enabled documentation of trade transactions, the method comprising steps of: receiving, transaction documents (“Conventional trade finance systems, such as those facilitating LCs, operate based on a flow of documents between parties and banks, which may be referred to as a “documentary flow.” The documentary flow includes a series of steps involving the transfer, analysis, and approval of certain documents. Each step must be completed in order to satisfy the requirements of the LC, and to ultimately release payment for the trade transaction.”) (Para. 0009); (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“In general, risks decrease over time as portions of a BLC 120 are completed. For example, documentary risks decrease as the trade finance blockchain computing system 102 receives, verifies, and authenticates documents associated with the BLC 120. Similarly, supply chain risks decrease as the good 113 progresses through the supply chain. To this end, the risk analysis circuit 226 is tasked with analyzing the various risks associated with the BLC 120 over time. For example, in one embodiment, the risk analysis circuit 216 is structured to assign a first risk level associated with the trade transaction prior completion of one of the documentary or supply chain flow events, and a second risk level associated with the trade transaction after completion of one of the documentary and/or supply chain flow events. In effect, the difference between the first and second risk levels represents the risk that the corresponding documentary or supply chain flow events will not occur. The risk analysis circuit 216 may define risk levels associated with any of the documentary and supply chain flow events identified in the BLC 120. As will be appreciated, the risk levels may be utilized to trigger interest rate adjustments, partial payments, or pricing of securities associated with the BLC 120.”) (Para. 0043);
from one or more buyers (“FIG. 1 is a block diagram illustrating a system 100 structured to perform a commercial trade finance transaction using a BLC, according to an example embodiment. The system 100 includes trade finance blockchain computing system 102, a trade finance blockchain 104, a buyer 106, an issuing bank 108, an advising bank 110, a seller 112, a good 113, a freight forwarder 114, and a shipping company 116, each being in operative communication via a network 118. By way of example, the system 100 will be described in connection with an international trade finance transaction involving the seller 112 exporting the good 113 from a first country and the buyer 106 importing the good 113 into a second country.”) (Para. 0016); (“The buyer 106 is a party applying for the issuance of the BLC 120, and may also be referred to as the “applicant.” The buyer 106 is the party importing the good 113. In this example, the buyer 106 has a bank account with the issuing bank 108.”) (Para. 0024); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032);
and one or more sellers; (“FIG. 1 is a block diagram illustrating a system 100 structured to perform a commercial trade finance transaction using a BLC, according to an example embodiment. The system 100 includes trade finance blockchain computing system 102, a trade finance blockchain 104, a buyer 106, an issuing bank 108, an advising bank 110, a seller 112, a good 113, a freight forwarder 114, and a shipping company 116, each being in operative communication via a network 118. By way of example, the system 100 will be described in connection with an international trade finance transaction involving the seller 112 exporting the good 113 from a first country and the buyer 106 importing the good 113 into a second country.”) (Para. 0016); (“The seller 112 is the party in whose favor the LC is issued, and who will receive payment if all the conditions and terms of the BLC 120 are met. The seller 112 may also be referred to as the “beneficiary.” The seller 112 is the party exporting the good 113. In this example, the seller 112 has a bank account with the advising bank 110.”) (Para. 0027); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032);
compiling the received documents into a set for each . . ., wherein a transaction from the buyer device is in relation to an event type selected from acceptance of goods or payment by the buyer; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“According to various embodiments, the BLC 120 may define certain documentary flow events and/or supply chain flow events as triggering payments, risk calculations, and interest rate adjustments, among other things. For example, a documentary flow payment trigger event and a supply chain flow payment trigger event may define the final events in the contract. In one embodiment, the BLC 120 is structured to transfer payment for the contract in response to detecting occurrence of both of the documentary flow payment trigger event and the supply chain flow payment trigger event. In some embodiments, the BLC 120 is structured to transfer payment for the contract, in whole or in part, in response to detecting occurrence of one of the documentary flow payment trigger event and the supply chain flow payment trigger event.”) (Para. 0038); (“Various embodiments also relate to trade financing via a variable trade financing profile. An example variable trade financing profile may include several incremental partial payment amounts triggered by monitored documentary and/or supply chain flow events. The ability to monitor documentary and supply chain flow throughout the lifecycle of the trade financing transaction enables enhanced analysis of documentary risk and supply chain risk at improved levels of granularity. In addition, linking the documentary flow events with the supply chain flow events enables overall dynamic trade financing risk to be analyzed at levels of granularity and accuracy not previously available. By better analyzing risk, banks may provide superior trade financing products, resulting in lower cost and better performance for the customer. For example, in one embodiment, a variable trade financing profile defines levels of incremental funding provided as the trade transaction progresses. In another embodiment, a variable trade financing profile defines an interest rate that is reduced as the trade transaction progresses.”) (Para. 0014);
. . . each of the compiled documents with a Unique Acceptance Code (UAC); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notificat ion of events specified in the BLCs 120.”) (Para. 0037);
generating a unique hash for each of the complied documents . . . with the UAC, wherein the hash is either an Inspection Report Code (IRC) or a Commercial Invoice Code (CIC) corresponding to the acceptance of goods or payment by the buyer respectively, which serves as a novel identifier for the respective document; (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018)
recording the generated IRC or CIC onto the blockchain, along with the event type and document timestamp, to ensure the immutability and transparency of the transaction data; (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040); (“A plurality of documentary flow events related to the BLC are tracked. In response to detecting occurrence of each of the plurality of documentary flow events, the respective documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. A plurality of supply chain flow events are tracked. Each of the plurality of supply chain flow events are related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the respective supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. Payment for the contract for the trade transaction is transferred to the seller in response to detecting occurrence of both of the documentary flow event corresponding to the documentary flow payment trigger event and the supply chain flow event corresponding to the supply chain flow payment trigger event.”) (Para. 0004);
generating a blockchain certificate for each event recorded on the blockchain platform; (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The BLC defines a documentary flow payment trigger event and a supply chain flow payment trigger event. A blockchain circuit is structured to store the BLC on a blockchain. The BLC is accessible by each of the seller and the buyer to view a status of the trade transaction. An event circuit structured to track a plurality of documentary flow events related to the BLC. In response to detecting occurrence of each of the plurality of documentary flow events, the tracked documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. The event circuit is also structured to track a plurality of supply chain flow events. Each of the plurality of supply chain flow events being related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the tracked supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. The trade financing circuit is further structured to, in response to detecting occurrence of both of a first documentary flow event of the plurality of documentary flow events corresponding to the documentary flow payment trigger event and a first supply chain flow event of the plurality of supply chain flow events corresponding to the supply chain flow payment trigger event, transfer payment for the contract for the trade transaction to the seller.”) (Para. 0005)
utilizing the blockchain platform to provide a verifiable and permanent record-keeping system, wherein the immutability of records is achieved through the blockchain's inherent properties, thereby enhancing the security and authenticity used in an . . .. (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018);
Dowling does not disclose:
• “watermark” (claim 12).
However, as per Claim 12, Brundage in the analogous art of multi-factor authentication, teaches: “watermark”. (See “An identification document may include a digital watermark. Digital watermarking is a process for modifying physical or electronic media to embed a machine-readable code into the media. The media may be modified such that the embedded code is imperceptible or nearly imperceptible to the user, yet may be detected through an automated detection process. In some of our preferred embodiments, an identification document includes two or more digital watermarks. Digital watermarking systems typically have two primary components: an encoder that embeds the digital watermark in a host media signal, and a decoder that detects and reads the embedded digital watermark from a signal suspected of containing a digital watermark (a suspect signal). The encoder embeds a digital watermark by altering the host media signal. The alterations usually take the form of altered signal values, such as slightly changed pixel values, luminance, colors, changed DCT coefficients, altered signal values or selective placement or signal tweaks, etc. However, a watermark can also be manifested in other ways, such as changes in the surface microtopology of a medium, localized chemical changes (e.g. in photographic emulsions), localized variations in optical density, localized changes in luminescence, etc. The surface texture of an object may be altered to create a watermark pattern. This may be accomplished by manufacturing an object in a manner that creates a textured surface or by applying material to the surface (e.g., an invisible film or ink) in a subsequent process. The watermark reading component analyzes content to detect whether a watermark pattern is present. In applications where the watermark encodes information, the reading component extracts this information from the detected watermark. The reading component analyzes a suspect signal to detect whether a digital watermark is present. The reading component can be hosted on a wide variety of units ranging from tethered or wireless reader devices, conventional personal computers, network servers, cell phones including cameras, to fully mobile readers with built-in displays. Image data corresponding to a watermarked surface of an identification document is read and decoded by this reader to obtain a watermark's information or “payload”.” (para. 0014-0015); “Sometimes the printed indicia is printed with visible or invisible (e.g., UV or IR) inks. Of course, the ID document 100 may include a wide variety of other features like optical or magnetic memory, microprinting, holograms, Kinograms®, electronic circuitry (e.g., a so-called smart card), ghost or faintly reproduced images, etc., etc.” (para. 0174); “It will be appreciated that the information encoded with the photograph need not necessarily correlate with other information on an identification document. For example, the scanning system may need only to confirm the existence of the identification code so that the user may be provided with a “go” or “no go” indication of whether the photograph has been tampered with. It will also be appreciated that the local computer, using an encrypted digital communications line, could send a packet of information to a central verification facility, which thereafter returns an encrypted “go” or “no go” indication.” (para. 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Dowling with the technique of Brundage to include digital watermarking in the tracking/authentication process. Therefore, the incentives of providing increased data security and downstream validation/tracking for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Dowling in view of Brundage does not disclose:
• “agricultural trade transaction” (claim 12).
However, as per Claim 12, Adam in the analogous art of secure digitally-based supply chain tracking systems, teaches: “agricultural trade transaction”. (See “Generally, the invention might be best understood as a system and method for implementing a true level- 2 trading methodology in the context of perishable agricultural commodities, complete with streaming quotes, and real-time display of seller “asks” and buyer “bids”. In order to enhance the immediacy of this agricultural trading exchange, information is delivered to both buyers and sellers through the medium of the World Wide Web (the Internet) which defines a platform allowing information delivery direct to a buyer's or seller's computer system, without requiring the intermediary of a broker and certainly without requiring the intermediary of a centralized institutional exchange, complete with “trading pit” and institutionalized traders. In the context of the present invention, the agricultural trading exchange exists in electronic form, as an application software routine running on a centralized server system, that itself functions as the intermediary between large numbers of buyers and sellers that could be separated from one another by continental distances. Both buyers and sellers register as traders with the agricultural trading exchange according to the invention, and are able to trade from their personal computers, whether desktop, laptop or palmtop, using suitable application specific software programs based on Internet standards (HTML, XML and TCP/IP). It should be noted that the present invention is particularly suited for Wireless Application Protocol-Enabled Software in the particular case where a user might wish to maintain communication with the commodity exchange using mobile or wireless service. To digress momentarily, WAP is an application communication protocol used to access services and information for hand held devices such as mobile phones. In order to fit within such small wireless devices, WAP makes use of a micro browser, a truncated set of software that makes minimal demands on hardware, memory and CPU time and is able to display information within a restricted mark-up language termed Wireless Mark-Up Language (WML). It should therefore be understood that the following detailed description of systems and methods in accordance with the invention, is not necessarily limited to desktop, laptop or palmtop-type computer systems, but is particularly suited for the type of device that a grower might easily be able to carry with them while working amongst the crops. Buyers and sellers, in the agricultural exchange according to the invention, are not constrained in their normal everyday movements and are not restricted in the other activities which they may wish to undertake.” (para. 0026); “Simultaneously, the seller receives a purchase notification from the exchange including all of the necessary data and information that the seller needs to ship the particular quantity of produce to that particular buyer. The seller invoices the buyer, and delivers the produce to the loading dock, whence it is shipped to the buyer's receiving facility. Once received, the exchange obtains delivery notification, either from the purchaser or from the shipper, and transfers actual funds from the buyer's account to the seller's account, making sure to credit any interim interest earned on the buyer's funds to the buyer.” (para. 0094); “Additional pages that are available through the activity window 64 include an alert page through which a user is able to structure a list of commodities that they are interested in trading. In the case of a wholesale buyer, the structured list might be a list of those commodities which they are interested in purchasing at a particular price or which might be available in a particular quantity. For example, if a wholesale buyer is interested in making a purchase of a large lot size of broccoli 14's at a price of $5.25, for example, and the asking price is $5.40, the buyer might structure his alert page to give him a notification whenever an “ask” order is posted which has a price in the general neighborhood of $5.25. Alerts may be set up to bracket a price, for example, i.e., between $5.15 and $5.35, or set a trigger threshold, i.e., less than $5.35, or even provide an alert on the basis of a price trend metric such as 2 or 3 trades in a row with increasing or decreasing prices. Further, as will be explained in greater detail below, a user may request an alert when a particular buyer or seller enters the market with a particular commodity. Since many buyers and sellers have long-standing relationships, a wholesale buyer for Kroger Foods, for example, may wish to receive an alert when broccoli crowns are offered by Adam Brothers Farming, Inc., for example.” (para. 0048).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Adam to provide verifiable agricultural trade records. Therefore, the incentives of providing increased auditability and post-sale accountability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 13, Dowling teaches:
The method as claimed in claim 12, wherein the compiled set of transaction documents comprising at least: an inspection report confirming the condition of goods supplied by a seller; and a signed delivery order or commercial invoice, each related to the acceptance of goods or payment by a buyer, respectively. (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“According to various embodiments, the BLC 120 may define certain documentary flow events and/or supply chain flow events as triggering payments, risk calculations, and interest rate adjustments, among other things. For example, a documentary flow payment trigger event and a supply chain flow payment trigger event may define the final events in the contract. In one embodiment, the BLC 120 is structured to transfer payment for the contract in response to detecting occurrence of both of the documentary flow payment trigger event and the supply chain flow payment trigger event. In some embodiments, the BLC 120 is structured to transfer payment for the contract, in whole or in part, in response to detecting occurrence of one of the documentary flow payment trigger event and the supply chain flow payment trigger event.”) (Para. 0038); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 14, Dowling teaches:
The method as claimed in claim 12, wherein the UAC includes: a Deal Transaction Number uniquely identifying the trade transaction; a Document Sequence and Type indicating the sequential order and category of the document within the transaction; and a GMT Timestamp marking the exact date and time of document issuance. (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020); (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 15, Dowling teaches:
The method as claimed in claim 12, wherein the unique hash is designated as: an Inspection Report Code (IRC) for documents corresponding to the acceptance of goods; or a Commercial Invoice Code (CIC) for documents corresponding to the acceptance of payment by the buyer; each hash serving as a novel identifier for the said document. (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020)
As per Claim 16, Dowling teaches:
The method as claimed in claim 12, wherein each certificate: signifies the blockchain's confirmation of the acceptance of goods or payment as per the respective IRC or CIC; and confirms the completion and immutability of the respective transactions within the . . . (“Structuring the BLC 120 as a smart contract stored on a blockchain provides enhanced customer visibility into the transaction status. With current LC systems, customers are often frustrated regarding the lack of transaction status information that is available once documents have been submitted. In contrast, BLCs 120 offer real-time visibility of transaction status information for all participants at every stage of the transaction. Other advantages of structuring the BLC 120 as a blockchain-based smart contract include providing an immutable audit trail, enabling participants rights management, and facilitating transfer and assignment of BLCs 120.”) (Para. 0023); (“The BLC defines a documentary flow payment trigger event and a supply chain flow payment trigger event. The BLC is stored on a blockchain. The BLC is accessible by each of the seller and the buyer to view a status of the trade transaction. A plurality of documentary flow events related to the BLC are tracked. In response to detecting occurrence of each of the plurality of documentary flow events, the respective documentary flow events are recorded on the blockchain. Each of the plurality of documentary flow events are linked to the BLC. A plurality of supply chain flow events are tracked. Each of the plurality of supply chain flow events are related to a physical status of a good involved in the trade transaction. In response to detecting occurrence of each of the plurality of supply chain flow events, the respective supply chain flow events are recorded on the blockchain. Each of the plurality of supply chain flow events are linked to the BLC. Payment for the contract for the trade transaction is transferred to the seller in response to detecting occurrence of both of the documentary flow event corresponding to the documentary flow payment trigger event and the supply chain flow event corresponding to the supply chain flow payment trigger event.”) (Para. 0004); (“As illustrated in FIG. 1, the trade finance blockchain 104 includes a BLC 120. The BLC 120 includes the terms and conditions of a BLC defined by the trade finance blockchain computing system 102 in response to a request by the buyer 106. The BLC 120 also includes several events, including a first event 122 to an Nth event 124, associated with the BLC 120. For example, as will be appreciated, the first event 122 may include a documentary flow event and the Nth event 124 may include a supply chain flow event. The first to Nth events 122, 124 are added to the trade finance blockchain 104 as they occur. The BLC 120 and its associated first to Nth events 122, 124 may be linked based on a transaction identifier, an identifier of the buyer 106, or other types of unique identifiers. Accordingly, the trade finance blockchain 104 maintains a complete and immutable record of each BLC 120 and its associated first to Nth events 122, 124.”) (Para. 0020).
Dowling in view of Brundage does not disclose:
• “agricultural trade transaction” (claim 16).
However, as per Claim 16, Adam in the analogous art of secure digitally-based supply chain tracking systems, teaches: “agricultural trade transaction”. (See “Generally, the invention might be best understood as a system and method for implementing a true level- 2 trading methodology in the context of perishable agricultural commodities, complete with streaming quotes, and real-time display of seller “asks” and buyer “bids”. In order to enhance the immediacy of this agricultural trading exchange, information is delivered to both buyers and sellers through the medium of the World Wide Web (the Internet) which defines a platform allowing information delivery direct to a buyer's or seller's computer system, without requiring the intermediary of a broker and certainly without requiring the intermediary of a centralized institutional exchange, complete with “trading pit” and institutionalized traders. In the context of the present invention, the agricultural trading exchange exists in electronic form, as an application software routine running on a centralized server system, that itself functions as the intermediary between large numbers of buyers and sellers that could be separated from one another by continental distances. Both buyers and sellers register as traders with the agricultural trading exchange according to the invention, and are able to trade from their personal computers, whether desktop, laptop or palmtop, using suitable application specific software programs based on Internet standards (HTML, XML and TCP/IP). It should be noted that the present invention is particularly suited for Wireless Application Protocol-Enabled Software in the particular case where a user might wish to maintain communication with the commodity exchange using mobile or wireless service. To digress momentarily, WAP is an application communication protocol used to access services and information for hand held devices such as mobile phones. In order to fit within such small wireless devices, WAP makes use of a micro browser, a truncated set of software that makes minimal demands on hardware, memory and CPU time and is able to display information within a restricted mark-up language termed Wireless Mark-Up Language (WML). It should therefore be understood that the following detailed description of systems and methods in accordance with the invention, is not necessarily limited to desktop, laptop or palmtop-type computer systems, but is particularly suited for the type of device that a grower might easily be able to carry with them while working amongst the crops. Buyers and sellers, in the agricultural exchange according to the invention, are not constrained in their normal everyday movements and are not restricted in the other activities which they may wish to undertake.” (para. 0026); “Simultaneously, the seller receives a purchase notification from the exchange including all of the necessary data and information that the seller needs to ship the particular quantity of produce to that particular buyer. The seller invoices the buyer, and delivers the produce to the loading dock, whence it is shipped to the buyer's receiving facility. Once received, the exchange obtains delivery notification, either from the purchaser or from the shipper, and transfers actual funds from the buyer's account to the seller's account, making sure to credit any interim interest earned on the buyer's funds to the buyer.” (para. 0094); “Additional pages that are available through the activity window 64 include an alert page through which a user is able to structure a list of commodities that they are interested in trading. In the case of a wholesale buyer, the structured list might be a list of those commodities which they are interested in purchasing at a particular price or which might be available in a particular quantity. For example, if a wholesale buyer is interested in making a purchase of a large lot size of broccoli 14's at a price of $5.25, for example, and the asking price is $5.40, the buyer might structure his alert page to give him a notification whenever an “ask” order is posted which has a price in the general neighborhood of $5.25. Alerts may be set up to bracket a price, for example, i.e., between $5.15 and $5.35, or set a trigger threshold, i.e., less than $5.35, or even provide an alert on the basis of a price trend metric such as 2 or 3 trades in a row with increasing or decreasing prices. Further, as will be explained in greater detail below, a user may request an alert when a particular buyer or seller enters the market with a particular commodity. Since many buyers and sellers have long-standing relationships, a wholesale buyer for Kroger Foods, for example, may wish to receive an alert when broccoli crowns are offered by Adam Brothers Farming, Inc., for example.” (para. 0048).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Adam to provide verifiable agricultural trade records. Therefore, the incentives of providing increased auditability and post-sale accountability for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 17, Dowling teaches:
The method as claimed in claim 12, further comprising step of allowing buyers to manually verify and sign the delivery order or commercial invoice digitally within the device before providing it to the system. (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032); (“The trade financing circuit 210 is structured to create and manage trade finance mechanisms, such as BLCs 120. In some embodiments, the buyer 106 interfaces directly with the trade finance blockchain computing system 102 to request to create the BLC 120. The trade finance blockchain computing system 102 processes the request and sends the request to the issuing bank 108. However, in other embodiments, the buyer 106 may interface with the issuing bank 108 and the issuing bank may instruct the trade finance blockchain computing system 102 to create the BLC 120. The request to create the BLC 120 may include various documents and other details regarding the terms of the trade transaction contract, such as payment terms, shipment terms, and additional information.”) (Para. 0035); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
As per Claim 18, Dowling teaches:
The method as claimed in claim 12, comprising step of capturing visual confirmation of the goods for inclusion in the inspection report, and which integrates with the system to facilitate automatic . . . with the UAC. (“The good 113 is the product that is the subject of the BLC 120, and is being sold by the seller 112 to the buyer 106. In some embodiments, the good 113 includes a transmitter 126 for transmitting a physical status of the good 113 within a supply chain flow to the trade finance blockchain computing system 102. For example, the transmitter 126 may transmit a geolocation of the good 113 to the trade finance blockchain computing system 102. In some embodiments, the transmitter 126 is an RFID tag. In some embodiments, the good 113 includes a one- or two-dimensional barcode in addition to or instead of the transmitter 126. In such embodiments, the barcode is scanned using a scanner at various points during the supply chain process, and the physical status information is transmitted to the trade finance blockchain computing system 102. The transmitter 126 or barcode may be integrated or attached to the packaging of the good 113, or may be integral to the good 113.”) (Para. 0029); (“The event circuit 214 is structured to monitor messages, documents, and other data received by the trade finance blockchain computing system 102 to track, identify, and record documentary and supply chain events. The messages and documents may include metadata or other data that indicates the BLC 120 or parties with which the messages and documents are associated. The event circuit 214 processes the messages and documents to determine occurrence of and compliance with events specified in the associated BLC 120.”) (Para. 0040);
Dowling does not disclose:
• “watermarking” (claim 18).
However, as per Claim 18, Brundage in the analogous art of multi-factor authentication, teaches: “watermarking”. (See “An identification document may include a digital watermark. Digital watermarking is a process for modifying physical or electronic media to embed a machine-readable code into the media. The media may be modified such that the embedded code is imperceptible or nearly imperceptible to the user, yet may be detected through an automated detection process. In some of our preferred embodiments, an identification document includes two or more digital watermarks. Digital watermarking systems typically have two primary components: an encoder that embeds the digital watermark in a host media signal, and a decoder that detects and reads the embedded digital watermark from a signal suspected of containing a digital watermark (a suspect signal). The encoder embeds a digital watermark by altering the host media signal. The alterations usually take the form of altered signal values, such as slightly changed pixel values, luminance, colors, changed DCT coefficients, altered signal values or selective placement or signal tweaks, etc. However, a watermark can also be manifested in other ways, such as changes in the surface microtopology of a medium, localized chemical changes (e.g. in photographic emulsions), localized variations in optical density, localized changes in luminescence, etc. The surface texture of an object may be altered to create a watermark pattern. This may be accomplished by manufacturing an object in a manner that creates a textured surface or by applying material to the surface (e.g., an invisible film or ink) in a subsequent process. The watermark reading component analyzes content to detect whether a watermark pattern is present. In applications where the watermark encodes information, the reading component extracts this information from the detected watermark. The reading component analyzes a suspect signal to detect whether a digital watermark is present. The reading component can be hosted on a wide variety of units ranging from tethered or wireless reader devices, conventional personal computers, network servers, cell phones including cameras, to fully mobile readers with built-in displays. Image data corresponding to a watermarked surface of an identification document is read and decoded by this reader to obtain a watermark's information or “payload”.” (para. 0014-0015); “Sometimes the printed indicia is printed with visible or invisible (e.g., UV or IR) inks. Of course, the ID document 100 may include a wide variety of other features like optical or magnetic memory, microprinting, holograms, Kinograms®, electronic circuitry (e.g., a so-called smart card), ghost or faintly reproduced images, etc., etc.” (para. 0174); “It will be appreciated that the information encoded with the photograph need not necessarily correlate with other information on an identification document. For example, the scanning system may need only to confirm the existence of the identification code so that the user may be provided with a “go” or “no go” indication of whether the photograph has been tampered with. It will also be appreciated that the local computer, using an encrypted digital communications line, could send a packet of information to a central verification facility, which thereafter returns an encrypted “go” or “no go” indication.” (para. 0020).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the method of Dowling with the technique of Brundage to include digital watermarking in the tracking/authentication process. Therefore, the incentives of providing increased data security and downstream validation/tracking for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 19, Dowling teaches:
The method as claimed in claim 12, further comprising step of encrypting the unique hash for each document to enhance security before recording on the blockchain platform. (“The trade financing circuit 210, in cooperation with the event circuit 214, is also structured to analyze metadata and other data associated with tracked documentary flow events (e.g., executed documents) and supply chain event messages to track compliance with various requirements or milestones of the BLCs 120. Because the BLCs 120 are structured as smart contracts, the trade financing circuit 210 facilitates performance of clauses of the BLCs 120 by providing notification of events specified in the BLCs 120.”) (Para. 0037); (“In some embodiments, each respective “circuit” may include machine-readable media for configuring the hardware to execute the functions described herein. The circuit may be embodied as one or more circuitry components including, but not limited to, processing circuitry, network interfaces, peripheral devices, input devices, output devices, sensors, etc. In some embodiments, a circuit may take the form of one or more analog circuits, electronic circuits (e.g., integrated circuits (IC), discrete circuits, system on a chip (SOCs) circuits, etc.), telecommunication circuits, hybrid circuits, and any other type of “circuit.” In this regard, the “circuit” may include any type of component for accomplishing or facilitating achievement of the operations described herein.”) (Para. 0056); (“The trade finance blockchain 104 is a distributed ledger including all of the information (e.g., trade financing transactions, records, and other related information, among other things) that has been stored in the trade finance blockchain 104 since its genesis. The trade finance blockchain 104 may be similar to other blockchains, such as those used for math-based currencies, or may be built on top of a math-based currency blockchain. The trade finance blockchain 104 hashes transactions (e.g., trade finance transactions, events, etc.) into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power (e.g., operated by verification nodes). The proof-of-work requirement ensures that entries in the blockchain are not compromised. In some embodiments, verification nodes are paid for their mining activities via minimal transaction fees. Other embodiments use a consensus mechanism other than proof-of-work, such as proof-of-stake, Byzantine fault tolerance, federated consensus, etc.”) (Para. 0018);
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Dowling et al. in view of Brundage et al. and Adam at al. in further view of Youb (US20220261882A1) (hereinafter “Youb”).
As per Claim 6, Dowling teaches:
The system as claimed in claim 1, wherein the blockchain is . . .. (“In some embodiments, the trade finance blockchain 104 is a private and permissioned blockchain platform in which verification nodes are preselected by a central authority (e.g., the trade finance blockchain computing system 102 or another entity). In other embodiments, the trade finance blockchain 104 is a public and permissionless ledger. In one embodiment, the trade finance blockchain 104 is purpose-built to maintain compatibility with existing applications.”) (Para. 0019).
Dowling in view of Brundage and Adam does not disclose:
• “proof-of-stake, EVM-compatible decentralized blockchain platform” (claim 6).
However, as per Claim 6, Youb in the analogous art of secure blockchain transactions, teaches: “a Polygon blockchain”. (See “Polygon—Formerly known as the Matic Network, Polygon is a proof-of-stake blockchain which is supported by major NFT marketplaces such as OpenSea.” (para. 0205); “Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, our high-level language, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and two data fields: [2, ‘CHARLIE’ ].” (Para. 0394).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Youb to provide a variety of POS, EVM-compatible blockchain networks for transaction processing. Therefore, the incentives of providing increased user access for the user provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Dowling et al. in view of Brundage et al. and Adam at al. in further view of Gaur (US20210350343A1) (hereinafter “Gaur”)
As per Claim 10, Dowling teaches:
The system as claimed in claim 1, wherein the processor is further configured to . . .. (“The authorization circuit 208 is structured to verify and authenticate identities of users of the system 100. The authorization circuit 208 may utilize any number of authentication mechanisms, such as a username and password, cryptographic key exchange, etc. to verify and authenticate the identity of an entity that has an account with the trade finance blockchain computing system 102. Users of the system 100 may include any of the buyers 106 and sellers 112, banks and financial institutions such as the issuing bank 108 and the advising bank 110, logistics partners such as the freight forwarder 114 and the shipping company 116, and any other user of the system 100.”) (Para. 0034); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032); (“The KYC whitelist 206 is a list of entities that have been determined by the trade finance blockchain computing system 102 to comply with KYC requirements. The entities included in the KYC whitelist 206 may, but need not, be registered account holders of the trade finance blockchain computing system 100. If an entity intending to use the system 100 as a buyer or a seller is not included in the KYC whitelist 206, the entity may be required to provide certain information to comply with KYC requirements.”) (Para. 0033);
Dowling in view of Brundage and Adam does not disclose:
• “verify the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws” (claim 10).
However, as per Claim 10, Gaur in the analogous art of secure blockchain transactions, teaches: “verify the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws”. (See “The OFI may provide the RFI with temporary custody of a digital value such as a digital obligation (e.g., legal instrument with promise to pay, etc.), a digital asset (e.g., stablecoin, cryptocurrency, etc.), or the like. The OFI may also have the option to choose which digital value to be used during the on-chain settlement. Based on the choice of digital value by the OFI, the host system may implement different messaging workflows. For example, a digital obligation may have different compliance requirements than a digital asset. Here, the host system may ensure that the workflow is satisfied prior to storing final settlement on the blockchain. In either case, temporary custody of the digital obligation or the digital asset is returned from the RFI back to the OFI at the end of the settlement process. For example, when the off-chain transaction lands in the RFI's account, the digital obligation/digital asset may be returned to the OFI through the blockchain and the final settlement may be recorded on the blockchain.” (para. 0046); “If successful, the message is forwarded to the RFI 140 for additional compliance and verification. Here, the RFI 140 interacts with the compliance and federation service 144 to perform regulatory verification on the transfer within the message. The compliance and federation service 144 may use regulations from the database 142 of the country of origin and the country of destination. The compliance and federation service 144 may perform AML, screening and KYC screening to verify identities involved in the transaction. Here, the compliance and federation service 144 may use account ID, names, addresses, etc. within the message to verify the parties involved in the transaction. If the compliance verification is successful, the RFI 140 may transmit a response to the send service 121 indicating successful compliance, and the resulting notification may be stored on the blockchain. According to various embodiments, the host system 120 captures message data (e.g., conversational data) that represents a state of compliance of the off-chain transfer of value” (para. 0075); “The conversational state 150 may be included within standardized messages that are transmitted between the OFI 130 and the RFI 140. Here, the host system may capture the entire message content and store it on the blockchain 126. As another example, the host system may extract message elements such as compliance-specific data, account identifiers, jurisdictional data (origin, destination, etc.), types of compliance checks performed (e.g., KYC, AML, sanctions, etc.), message format verification elements, and the like, and store the data elements on the blockchain 126. For example, the host system may hash the message content in a transaction that is added to a block on the blockchain.” (para. 0077); “Settlement of the off-chain transaction may be completed on-chain through recording and exchange of the digital obligation/digital asset and the message content. Thus, the message exchange can act as legal settlement of the off-chain transaction. Furthermore, the host system may validate the messages between the OFI and the RFI to ensure that the content and format satisfies International Organization Standardization (ISO) protocols such as ISO 20022.” (Para. 0045).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Gaur to provide a verified form and party competence checking in a blockchain system based on geographic limitations. Therefore, the incentives of providing full-spectrum auditing, from data integrity to contractual and legal validation, provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
As per Claim 20, Dowling teaches:
The method as claimed in claim 12, comprising step of . . .. (“The authorization circuit 208 is structured to verify and authenticate identities of users of the system 100. The authorization circuit 208 may utilize any number of authentication mechanisms, such as a username and password, cryptographic key exchange, etc. to verify and authenticate the identity of an entity that has an account with the trade finance blockchain computing system 102. Users of the system 100 may include any of the buyers 106 and sellers 112, banks and financial institutions such as the issuing bank 108 and the advising bank 110, logistics partners such as the freight forwarder 114 and the shipping company 116, and any other user of the system 100.”) (Para. 0034); (“The accounts database 204 is a storage repository including account information of the various users (e.g., entities, such as corporations, organizations, individuals, etc.) of the system 100, such as the buyer 106 and the seller 112. In some embodiments, users must go through an on-boarding process, including KYC verification, to create an account with the trade finance blockchain computing system 102 in order to use the system 100. In some embodiments, the trade finance blockchain computing system 102 receives account information from a financial institution with which a user has an account. For example, the trade finance blockchain computing system 102 may receive account information from the advising bank 110 regarding the seller 112.”) (Para. 0032); (“The KYC whitelist 206 is a list of entities that have been determined by the trade finance blockchain computing system 102 to comply with KYC requirements. The entities included in the KYC whitelist 206 may, but need not, be registered account holders of the trade finance blockchain computing system 100. If an entity intending to use the system 100 as a buyer or a seller is not included in the KYC whitelist 206, the entity may be required to provide certain information to comply with KYC requirements.”) (Para. 0033).
Dowling in view of Brundage and Adam does not disclose:
“verifying the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws” (claim 20).
However, as per Claim 20, Gaur in the analogous art of secure blockchain transactions, teaches: “verifying the legal form and competence of the parties to the contract based on the respective local jurisdictions before generating the IRC or CIC, ensuring that each digital smart contract is compliant with applicable international trade laws”. (See “The OFI may provide the RFI with temporary custody of a digital value such as a digital obligation (e.g., legal instrument with promise to pay, etc.), a digital asset (e.g., stablecoin, cryptocurrency, etc.), or the like. The OFI may also have the option to choose which digital value to be used during the on-chain settlement. Based on the choice of digital value by the OFI, the host system may implement different messaging workflows. For example, a digital obligation may have different compliance requirements than a digital asset. Here, the host system may ensure that the workflow is satisfied prior to storing final settlement on the blockchain. In either case, temporary custody of the digital obligation or the digital asset is returned from the RFI back to the OFI at the end of the settlement process. For example, when the off-chain transaction lands in the RFI's account, the digital obligation/digital asset may be returned to the OFI through the blockchain and the final settlement may be recorded on the blockchain.” (para. 0046); “If successful, the message is forwarded to the RFI 140 for additional compliance and verification. Here, the RFI 140 interacts with the compliance and federation service 144 to perform regulatory verification on the transfer within the message. The compliance and federation service 144 may use regulations from the database 142 of the country of origin and the country of destination. The compliance and federation service 144 may perform AML, screening and KYC screening to verify identities involved in the transaction. Here, the compliance and federation service 144 may use account ID, names, addresses, etc. within the message to verify the parties involved in the transaction. If the compliance verification is successful, the RFI 140 may transmit a response to the send service 121 indicating successful compliance, and the resulting notification may be stored on the blockchain. According to various embodiments, the host system 120 captures message data (e.g., conversational data) that represents a state of compliance of the off-chain transfer of value” (para. 0075); “The conversational state 150 may be included within standardized messages that are transmitted between the OFI 130 and the RFI 140. Here, the host system may capture the entire message content and store it on the blockchain 126. As another example, the host system may extract message elements such as compliance-specific data, account identifiers, jurisdictional data (origin, destination, etc.), types of compliance checks performed (e.g., KYC, AML, sanctions, etc.), message format verification elements, and the like, and store the data elements on the blockchain 126. For example, the host system may hash the message content in a transaction that is added to a block on the blockchain.” (para. 0077); “Settlement of the off-chain transaction may be completed on-chain through recording and exchange of the digital obligation/digital asset and the message content. Thus, the message exchange can act as legal settlement of the off-chain transaction. Furthermore, the host system may validate the messages between the OFI and the RFI to ensure that the content and format satisfies International Organization Standardization (ISO) protocols such as ISO 20022.” (Para. 0045).
It would have been obvious to one of ordinary skill in the art before the effective filing date to combine the methods of Dowling and Brundage with the technique of Gaur to provide a verified form and party competence checking in a blockchain system based on geographic limitations. Therefore, the incentives of providing full-spectrum auditing, from data integrity to contractual and legal validation, provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner.
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.
The following prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
US2020/0045051 (Bathen), discussing how “One example embodiment may include a method that provides one or more of storing a public key and a corresponding address associated with a user profile in a blockchain, creating a set of credentials for the user profile based on the public keys, forwarding the credentials to the one or more addresses, receiving a request for access to a site from a user device associated with the user profile, and retrieving the credential based on the one or more addresses from the blockchain. The process may be randomized to improve security, and the policy by which factors are requested can be defined by the systems administrators. Another example embodiment may include an apparatus including a processor configured to perform one or more of store a public key and one or more corresponding addresses associated with a user profile in a blockchain, create a credential for the user profile based on the public key, forward the credential to the one or more addresses, a receiver configured to receive a request for access to a site from a user device associated with the user profile, and the processor is further configured to retrieve the credential based on the one or more addresses from the blockchain. Yet another example embodiment may include a non-transitory computer readable storage medium configured to store instructions that when executed cause a processor to perform one or more of storing a public key and a corresponding address associated with a user profile in a blockchain, creating a set of credentials for the user profile based on the public keys, forwarding the credentials to the one or more addresses, receiving a request for access to a site from a user device associated with the user profile, and retrieving the credential based on the one or more addresses from the blockchain. The process may be randomized to improve security, and the policy by which factors are requested can be defined by the systems administrators.” (Para. 0006-0008)
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Justin A. Jimenez whose telephone number is (571) 270-3080. The examiner can normally be reached on 8:30 AM - 5:00 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, John W. Hayes can be reached on 571-272-6708. 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.
/Justin Jimenez/
Patent Examiner, Art Unit 3697
/JOHN W HAYES/Supervisory Patent Examiner, Art Unit 3697