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 .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are in claim 14:
A collector, a request receiver, a preference data provider, a rule provider, a preference data generator, and an assignor.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, they are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. (See pages 10, 47-49, 56, and 77 of the Specification)
If applicant does not intend to have these limitations interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitations to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitations) recites sufficient structure to perform the claimed function so as to avoid them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
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-15 are rejected under 35 U.S.C 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Claims 1-10 recite a computer-implemented method (process), Claim 11 recites an apparatus (machine), Claim 12 recites a computer element (manufacture), Claim 13 recites a method (process), claim 14 recites a system (machine) and claim 15 recites a computer element (manufacture) and therefore fall into a statutory category.
Step 2A – Prong 1 (Is a Judicial Exception Recited?):
The claims as a whole recites a computer-implemented method, an apparatus, a method, a computer element, a system and a computer element for performing a manner of organizing information for products for assessing the preferential treatment of a product, which under its broadest reasonable interpretation, covers concepts for Certain Methods of Organizing Human Activity.
The abstract idea portion of the claims is as follows:
(Claim 1)
A [computer-implemented] method for generating preference data associated with a product, wherein the product is produced by a production from at least one inbound material, the method including:
(a) receiving a request to generate the preference data, said request including product data associated with the product,
(b) retrieving - based on the received product data - preference data associated with the inbound material(s) from inbound material data associated with said inbound material(s), wherein the inbound material data associated with each inbound material is accessed - based on a decentral identifier associated with the respective inbound material data, and optionally based on data related to the respective inbound material data – [by a data consuming service under control of a data providing service being associated with a data owner], said data owner being associated with the respective inbound material data;
(c) retrieving at least one rule of origin for attributing a country of origin to the product produced from the at least one material;
(d) generating preference data associated with the product based on the retrieved rule(s) of origin, the retrieved preference data, and the received product data;
and (e) providing, [via a communication interface], the generated preference data.
(Claim 11)
[An apparatus for] generating preference data associated with a product produced from at least one material, [the apparatus comprising: one or more computing nodes; and one or more computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the one or more computing nodes, cause the apparatus to] perform the method as claimed in claim 1.
(Claim 12)
[A computer element with instructions, which when executed on one or more computing node(s) are configured to] carry out the steps of the method as claimed in claim 1.
(Claim 13)
A method for producing at least one product associated with preference data, wherein the product is produced by a production from at least one inbound material, the method including:
(a) providing the inbound material(s) to a production and producing the at least one product from at least part of the provided inbound material(s) using the production,
(b) receiving a request to generate the preference data, said request including product data associated with the product,
(c) retrieving - based on the received product data - preference data associated with at least part of the inbound material(s) from inbound material data associated with said part of the inbound materials, wherein the inbound material data associated with each inbound material of said part of inbound materials is accessed - based on a decentral identifier associated with the inbound material data, and optionally based on data related to the inbound material data – [by a data consuming service under control of a data providing service being associated with a data owner], said data owner being associated with the respective inbound material data,
(d) retrieving at least one rule of origin for attributing a country of origin to the produced product, and
(e) generating preference data based on the received product data, the retrieved preference data and the received rule(s) of origin, and associating said generated preference data with the produced product.
(Claim 14) [A system configured to] produce a product associated with preference data from one or more inbound material(s) and to provide the produced product associated with the preference data, [the system including:]
[(a) a production line configured to] produce the product from the inbound material(s) and to provide the produced product, wherein the product is connected to or comprises a physical identifier,
(b) [a collector configured to] collect product data associated with the product,
(c) [a request receiver configured to] receive a request to generate the preference data, said request including product data associated with the product,
(d) [a preference data provider configured to] retrieve - based on the received product data - preference data associated with at least part of the inbound material(s) from inbound material data associated with said part of the inbound materials, wherein the inbound material data associated with each inbound material of said part of inbound materials is accessed - based on a decentral identifier associated with the inbound material data, and optionally based on data related to the inbound material data – [by a data consuming service under control of a data providing service being associated with a data owner], said data owner being associated with the respective inbound material data,
(e) [a rule provider configured to] retrieve at least one rule of origin for attributing a country of origin to a product produced from at least one inbound material;
(f) [a preference data generator configured to] generate preference data associated with the produced product based on the received product data, the retrieved preference data and the retrieved rule(s) rule of origin, and
(g) [an assignor configured to] assign the physical identifier to the generated preference data.
(Claim 15) [A computer element with instructions, which when executed on one or more computing node(s) are configured to be carried out by the apparatus as claimed in claim 11].
Here the claims recite concepts covering commercial or legal interactions (business relations, legal obligations) but for the recitation of generic computing components. In the present application the claims recite concepts for a manner of organizing information for product for assessing the preferential treatment of a product. (See pages 1 and 6).
If a claim limitation, under its broadest reasonable interpretation, covers concepts capable of being performed in commercial or legal interactions it falls under the Certain Method of Organizing Human Activity, grouping of abstract ideas. See MPEP 2106.04.
Accordingly, the claims recite an abstract idea.
Step 2A-Prong 2 (Is the Exception Integrated into a Practical Application?):
The Examiner views the following as the additional elements:
Computer-implemented. (See page 14 the Specification.)
A data consuming service. (See page 11 of the Specification.)
A data providing service. (See page 11 of the Specification.)
A communication interface. (See page 15 of the Specification.)
An apparatus. (See page 16 of the Specification.)
One or more computing nodes. (See page 14 of the Specification.)
One or more computer-readable media. (See page 14 of the Specification.)
Computer-executable instructions. (See page 14 of the Specification.)
A system. (See pages 75 of the Specification
A production line. (See pages 4-5 and 75 of the Specification.)
A collector. (See page 10 of the Specification.)
A request receiver. (See page 56 of the Specification.)
A preference data provider. (See page 56 of the Specification.)
A rule provider. (See page 56 of the Specification.)
A preference data generator. (See page 56 of the Specification.)
An assignor. (See pages 47-49 and 77 of the Specification.)
A computer element. (See page 14 of the Specification.)
Instructions. (See page 14 of the Specification.)
These additional elements are recited at a high-level of generality such that they act to merely “apply” the abstract idea using generic computing components and do not integrate the abstract idea into a practical application. (See MPEP 2106.05 (f))
The combination of these additional elements and/or results oriented steps are no more than mere instructions to apply the exception using generic computing components. (See Id.) Accordingly, even in combination these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea.
Step 2B (Does the claim recite additional elements that amount to Significantly More than the Judicial Exception?):
As noted above, the claims as a whole merely describes a method and system that generally “apply” the concepts discussed in prong 1 above. (See MPEP 2106.05 f (II)) In particular applicant has recited the computing components at a high-level of generality such that it amounts to no more than mere instructions to apply the exception using generic computer components. As the court stated in TLI Communications v. LLC v. AV Automotive LLC, 823 F.3d 607, 613 (Fed. Cir. 2016) merely invoking generic computing components or machinery that perform their functions in their ordinary capacity to facilitate the abstract idea are mere instructions to implement the abstract idea within a computing environment and does not add significantly more to the abstract idea. Accordingly, these additional computer components do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. Therefore, even when viewed as a whole, nothing in the claim adds significantly more (i.e. an inventive concept) to the abstract idea and as a result the claim is not patent eligible.
Dependent claims 2-10 further define the abstract idea as identified and do not integrate the abstract idea into a practical application or add significantly more. Therefore claims 2-10 are considered to be patent ineligible.
In conclusion the claims do not provide an inventive concept, because the claims do not recite additional elements or a combination of elements that amount to significantly more than the judicial exception of the claims. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and the collective functions merely provide conventional computer implementation. Therefore, whether taken individually or as an order combination, the claims are nonetheless rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-13 and 15 are rejected under 35 U.S.C. 102 (a)(1) as being anticipated by Robotham et al. (US 20210326872).
Referring to claim 1,
Robotham which is directed to using intelligent assertion tokens for authenticating and controlling network communications using a distributed ledger in a supply chain, discloses
A computer-implemented method for generating preference data associated with a product, wherein the product is produced by a production from at least one inbound material, the method including:(a) receiving a request to generate the preference data, said request including product data associated with the product, (Robotham paragraph 38 disclosing to address the shortcomings of known systems described above, the present disclosure sets forth systems and methods that facilitate the admissibility requirements and/or qualification of goods under preferential or non-preferential rules of origin, by representing the requirements to qualify as a set of dependencies on assertions made by producers, exporters or suppliers as to certain attributes of their goods (e.g., country of origin), tokenizing these assertions on a distributed ledger such as a blockchain network, and using the flow of these tokens along with the documents they reference to validate claims to reduced duties or tariffs on those goods, or validating that a tariff should not apply to those goods. Robotham paragraphs 41 teaching the recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. Robotham paragraph 43 teaching in some embodiments, a distributed ledger-implemented (e.g., blockchain-implemented) system manages and exchanges Certificates of Origin and similar declarations related to cross-border commerce. The system can be configured to manage assertions related to the qualification of a good for preferential or non-preferential duties or tariff treatment, tokenize these assertions, and use the flow of these tokens to automate administrative Country of Origin (COO) processes for cross-border supply chains.
Robotham paragraph 53 disclosing a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraphs 64-66 disclosing A COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”).While a BOM can specify in detail all components used in the manufacturing process for the good (a “production BOM”), only the minimum set of components used for qualifying under the COO contract may be specified in a BOM (a “partial BOM”). Many free trade agreements allow a claim for preferential or non-preferential duties or tariff treatment based on meeting a minimum set of requirements, and therefore a partial BOM can be sufficient to meet these requirements. For example, a preferential regime could require that 70% of the value of the good has been produced from parts originating within the countries covered under the free trade agreement, and therefore the components specified in a partial BOM can be limited to those needed to meet the relevant threshold. A partial BOM has many practical advantages in reducing the number of components that can be specified in the BOM or BOM contract to be included in a token, thus reducing the number and complexity of processing steps that are related to the number of components in a BOM. Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e), in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d). Optionally, requests to certify certificates of origin can be received from compute devices of third parties and processed by suppliers and/or manufacturers (i.e., via their associated compute devices), and requests to verify certificates of origin can be received from compute devices of customs agencies and processed by the customers and/or importers of record (i.e., via their associated compute devices), as shown in FIG. 26.)
(b) retrieving - based on the received product data - preference data associated with the inbound material(s) from inbound material data associated with said inbound material(s), wherein the inbound material data associated with each inbound material is accessed - based on a decentral identifier associated with the respective inbound material data, and optionally based on data related to the respective inbound material data - by a data consuming service under control of a data providing service being associated with a data owner, said data owner being associated with the respective inbound material data;
(Robotham paragraphs 40-42 disclosing a CO token is uniquely identified by a unique identifier, and can therefore be classified, for example, using blockchain nomenclature as a non-fungible token (NFT). The recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. At each such step of the supply chain, the CO token associated with that step may be inspected by a processor, according to inspection rules stored in a memory operably coupled to the processor, prior to transmission of that CO token or upon receipt of the CO token. The processor may authorize the CO token to be transmitted or received, or may block the CO token from being transmitted or received, depending on the outcome of the application of the inspection rules. In some embodiments, inspection of the CO token is performed according to a set of rules defined, for example, by one or more smart contracts, examples of which can include the BOM smart contract, the COO smart contract, and/or the non-COO smart contract, and/or by operations external to the distributed ledger which record the results on the distributed ledger through transactions mediated by one or more of these smart contracts, as discussed herein. For COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement.)
(c) retrieving at least one rule of origin for attributing a country of origin to the product produced from the at least one material; (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e))
(d) generating preference data associated with the product based on the retrieved rule(s) of origin, the retrieved preference data, and the received product data; and (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e).)
(e) providing, via a communication interface, the generated preference data. ((Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e) , in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d).)
Referring to claim 2,
Robotham further discloses wherein the preference data associated with the product includes at least the preferential origin status or the non-preferential origin status of the product for at least one country or at least one region. (Robotham paragraph 39 disclosing in some embodiments, assertions about a country of origin are tokenized, and the tokenized assertions can be used as digital equivalents of Certificates of Origin (COs) and/or similar declarations commonly used in cross-border trade. A CO can therefore function as a declaration and attestation of the Country of Origin (COO) of a good. The transfer of a CO token from a supplier to a customer makes that token available for use by that customer. The customer can use a CO token to automatically resolve one or more dependencies on that COO assertion for products the customer is producing. The set of dependencies on COO assertions can be used, for example, to determine whether a given good qualifies under preferential or non-preferential rules of one or multiple trade agreements and/or other government agency laws that may be enforced by customs border agencies (collectively referred to herein as “trade programs”). Robotham paragraph 73 disclosing As shown in FIG. 1, the memory 102 includes one or more CO token templates 102B, one or more CO tokens 104, one or more BOM smart contracts 106, and, optionally, one or more assertion tokens 108 and/or one or more token inspection rules 120. Each COO smart contract 102A can include one of more CO token templates 102B. Each CO token 104 can include one or more of: a good identifier (“Good ID”) 104A, treaties 104B, rules 104C, tariffs 104D, and dates 104E (e.g., date ranges, such as a date range of applicability of a preferential trade agreement). Each BOM smart contract 106 can include data for good components 106A (e.g., a listing of parts associated with an assembled multi-component good Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e), in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d).)
Referring to claim 3,
Robotham further discloses wherein the product data includes a product identifier, price data, product composition data and/or a customs tariff classification associated with the product. (Robotham paragraph 42 disclosing For COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement. Robotham paragraph 68 disclosing for a part component, an illustrative example of a matching criteria is to use the unique identifier (“unique ID”) of a stock keeping unit (“SKU”) for a part maintained in the producer's inventory. In this example, a CO token for a part from a supplier can be mapped into this SKU. The matching CO token becomes eligible for use in resolving the part dependency. A single CO token can be used to resolve part dependencies in multiple components within a single BOM or across multiple BOMs. A part component can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes, in order to facilitate the matching process.)
Referring to claim 4,
Robotham further discloses wherein the decentral identifier is associated with the data owner and/or with the inbound material the inbound material data is associated with. (Robotham paragraph 68 disclosing for a part component, an illustrative example of a matching criteria is to use the unique identifier (“unique ID”) of a stock keeping unit (“SKU”) for a part maintained in the producer's inventory. In this example, a CO token for a part from a supplier can be mapped into this SKU. The matching CO token becomes eligible for use in resolving the part dependency. A single CO token can be used to resolve part dependencies in multiple components within a single BOM or across multiple BOMs. A part component can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes, in order to facilitate the matching process. Robotham paragraph 88 disclosing the mappings within a given entity between an identifier in an assertion token and the matching criteria of a BOM component can be unique for that entity, since the entity controls the mapping from asset token identifier to identifier used in its matching criteria. However, the identifiers in the assertion token are commonly interpreted across entities to transfer an asset token from one entity to the next and effectively use it to resolve a dependency in the entity receiving the assertion token. This implies that a common taxonomy of identifiers for an assertion token of a given type should be maintained across the entities that either generate a token with that assertion identifier or intend to use that token to resolve a dependency.)
Referring to claim 5,
Robotham further discloses wherein the preference data is retrieved using the decentral identifier and/or inbound material identifier(s) associated with the inbound material(s). (Robotham paragraph 68 disclosing for a part component, an illustrative example of a matching criteria is to use the unique identifier (“unique ID”) of a stock keeping unit (“SKU”) for a part maintained in the producer's inventory. In this example, a CO token for a part from a supplier can be mapped into this SKU. The matching CO token becomes eligible for use in resolving the part dependency. A single CO token can be used to resolve part dependencies in multiple components within a single BOM or across multiple BOMs. A part component can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes, in order to facilitate the matching process. Robotham paragraphs 88-89 disclosing the mappings within a given entity between an identifier in an assertion token and the matching criteria of a BOM component can be unique for that entity, since the entity controls the mapping from asset token identifier to identifier used in its matching criteria. However, the identifiers in the assertion token are commonly interpreted across entities to transfer an asset token from one entity to the next and effectively use it to resolve a dependency in the entity receiving the assertion token. This implies that a common taxonomy of identifiers for an assertion token of a given type should be maintained across the entities that either generate a token with that assertion identifier or intend to use that token to resolve a dependency. At a minimum, the commonality of assertion identifiers and assertion types are made between the party issuing the assertion token (producer) and the party receiving the assertion token (consumer) of any given assertion token, with either the producer or consumer or both providing the common mappings. In a broader set of implementations, where tokens of a given type are exchanged across multiple participants in the blockchain ecosystem, a shared taxonomy of assertion types and assertion identifiers enables the benefits of transferring an assertion token from one entity to the next without intermediate interpretations and mappings.)
Referring to claim 6,
Robotham further discloses wherein the preference data associated with the respective inbound material includes data on the preferential origin status or the non-preferential origin status of said material for at least one country, and a material price. (Robotham paragraph 42 disclosing for COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement. In some embodiments, the assertion smart contract is configured to automatically perform one or more calculations and generate one or more COO assertions based on the one or more calculations.
Robotham paragraph 53 disclosing a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraphs 64-66 disclosing A COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”).While a BOM can specify in detail all components used in the manufacturing process for the good (a “production BOM”), only the minimum set of components used for qualifying under the COO contract may be specified in a BOM (a “partial BOM”). Many free trade agreements allow a claim for preferential or non-preferential duties or tariff treatment based on meeting a minimum set of requirements, and therefore a partial BOM can be sufficient to meet these requirements. For example, a preferential regime could require that 70% of the value of the good has been produced from parts originating within the countries covered under the free trade agreement, and therefore the components specified in a partial BOM can be limited to those needed to meet the relevant threshold. A partial BOM has many practical advantages in reducing the number of components that can be specified in the BOM or BOM contract to be included in a token, thus reducing the number and complexity of processing steps that are related to the number of components in a BOM. Robotham paragraph 145 disclosing Continuing with FIG. 7, when Tier 1 Supplier 5 (5 b) manufactures part P, the Tier 1 Supplier 5 (5 b) (e.g., via a production ERP system) maintains a production BOM (5 j) for part P, a detailed list of all parts required to manufacture part P. This production BOM (5 j) is closely related to the BOM (5 g) referenced in the COO contract (5 h) used for minting CO tokens, but is not necessarily exactly the same, since the BOM for the COO (5 g) can be a partial BOM while the production BOM (5 j) can have a more detailed list of components. In this example, the production BOM also has a Component 1 (5 k) corresponding to Component 1 (5 f) used in the COO process but also has additional components.)
Referring to claim 7,
Robotham further discloses wherein the data related to the inbound material data includes one or more digital representation(s) pointing to the inbound material data or parts thereof. (Robotham paragraph 42 teaching for COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement. In some embodiments, the assertion smart contract is configured to automatically perform one or more calculations and generate one or more COO assertions based on the one or more calculations. Robotham paragraph 53 disclosing a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraph 64 disclosing a COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”).Robotham paragraph 68 disclosing for a part component, an illustrative example of a matching criteria is to use the unique identifier (“unique ID”) of a stock keeping unit (“SKU”) for a part maintained in the producer's inventory. In this example, a CO token for a part from a supplier can be mapped into this SKU. The matching CO token becomes eligible for use in resolving the part dependency. A single CO token can be used to resolve part dependencies in multiple components within a single BOM or across multiple BOMs. A part component can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes, in order to facilitate the matching process. Robotham paragraph 145 disclosing continuing with FIG. 7, when Tier 1 Supplier 5 (5 b) manufactures part P, the Tier 1 Supplier 5 (5 b) (e.g., via a production ERP system) maintains a production BOM (5 j) for part P, a detailed list of all parts required to manufacture part P. This production BOM (5 j) is closely related to the BOM (5 g) referenced in the COO contract (5 h) used for minting CO tokens, but is not necessarily exactly the same, since the BOM for the COO (5 g) can be a partial BOM while the production BOM (5 j) can have a more detailed list of components. In this example, the production BOM also has a Component 1 (5 k) corresponding to Component 1 (5 f) used in the COO process but also has additional components.
Referring to claim 8,
Robotham further discloses wherein the at least one rule of origin is retrieved based on the received product data. (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e).)
Referring to claim 9,
Robotham further discloses wherein the at least one rule of origin includes at least one rule related to wholly obtained products and/or at least one rule related to the substantial transformation of a material used to produce the product and/or the substantial transformation of an ingredient used to produce the material. (Robotham paragraph 42 disclosing for COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement. In some embodiments, the assertion smart contract is configured to automatically perform one or more calculations and generate one or more COO assertions based on the one or more calculations. Robotham paragraph 53 disclosing a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraphs 64-66 disclosing a COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”). While a BOM can specify in detail all components used in the manufacturing process for the good (a “production BOM”), only the minimum set of components used for qualifying under the COO contract may be specified in a BOM (a “partial BOM”). Many free trade agreements allow a claim for preferential or non-preferential duties or tariff treatment based on meeting a minimum set of requirements, and therefore a partial BOM can be sufficient to meet these requirements. For example, a preferential regime could require that 70% of the value of the good has been produced from parts originating within the countries covered under the free trade agreement, and therefore the components specified in a partial BOM can be limited to those needed to meet the relevant threshold. A partial BOM has many practical advantages in reducing the number of components that can be specified in the BOM or BOM contract to be included in a token, thus reducing the number and complexity of processing steps that are related to the number of components in a BOM. Robotham paragraph 145 disclosing continuing with FIG. 7, when Tier 1 Supplier 5 (5 b) manufactures part P, the Tier 1 Supplier 5 (5 b) (e.g., via a production ERP system) maintains a production BOM (5 j) for part P, a detailed list of all parts required to manufacture part P. This production BOM (5 j) is closely related to the BOM (5 g) referenced in the COO contract (5 h) used for minting CO tokens, but is not necessarily exactly the same, since the BOM for the COO (5 g) can be a partial BOM while the production BOM (5 j) can have a more detailed list of components. In this example, the production BOM also has a Component 1 (5 k) corresponding to Component 1 (5 f) used in the COO process but also has additional components.)
Referring to claim 10,
Robotham further discloses wherein generating preference data includes - determining the origin based on the received rule(s) of origin and the received preference data, and - determining the preference status based on the determined origin. (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e).)
Referring to claim 11,
Robotham discloses An apparatus for generating preference data associated with a product produced from at least one material, the apparatus comprising: one or more computing nodes; and one or more computer-readable media having thereon computer-executable instructions that are structured such that, when executed by the one or more computing nodes, cause the apparatus to perform the method as claimed in claim 1. (Robotham paragraph 38 disclosing to address the shortcomings of known systems described above, the present disclosure sets forth systems and methods that facilitate the admissibility requirements and/or qualification of goods under preferential or non-preferential rules of origin, by representing the requirements to qualify as a set of dependencies on assertions made by producers, exporters or suppliers as to certain attributes of their goods (e.g., country of origin), tokenizing these assertions on a distributed ledger such as a blockchain network, and using the flow of these tokens along with the documents they reference to validate claims to reduced duties or tariffs on those goods, or validating that a tariff should not apply to those goods. Robotham paragraph 41 disclosing the recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. Robotham paragraph 43 disclosing in some embodiments, a distributed ledger-implemented (e.g., blockchain-implemented) system manages and exchanges Certificates of Origin and similar declarations related to cross-border commerce. The system can be configured to manage assertions related to the qualification of a good for preferential or non-preferential duties or tariff treatment, tokenize these assertions, and use the flow of these tokens to automate administrative Country of Origin (COO) processes for cross-border supply chains.
For COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement. Robotham paragraph 73 disclosing any of the one or more producers 101, one or more suppliers 103, and one or more end consumers 110 can be an importer. The producers 101, suppliers 103, and end consumers 110 each have associated compute devices that can communicate with one another via the telecommunications network “N,” which may be a wireless network, a wired network, or a combination of both. Each compute device of the producer(s) 101 includes a memory 102, a processor 106 operably coupled to the memory 102, and a transceiver 108 (e.g., an antenna) operably coupled to the processor 106. The memory 102 stores data and instructions (e.g., code) executable by the processor 106 to perform defined steps (i.e., software). Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e), in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d). Optionally, requests to certify certificates of origin can be received from compute devices of third parties and processed by suppliers and/or manufacturers (i.e., via their associated compute devices), and requests to verify certificates of origin can be received from compute devices of customs agencies and processed by the customers and/or importers of record (i.e., via their associated compute devices), as shown in FIG. 26.)
Referring to claim 12,
Robothma discloses A computer element with instructions, which when executed on one or more computing node(s) are configured to carry out the steps of the method as claimed in claim 1. (Robotham paragraph 73 disclosing any of the one or more producers 101, one or more suppliers 103, and one or more end consumers 110 can be an importer. The producers 101, suppliers 103, and end consumers 110 each have associated compute devices that can communicate with one another via the telecommunications network “N,” which may be a wireless network, a wired network, or a combination of both. Each compute device of the producer(s) 101 includes a memory 102, a processor 106 operably coupled to the memory 102, and a transceiver 108 (e.g., an antenna) operably coupled to the processor 106. The memory 102 stores data and instructions (e.g., code) executable by the processor 106 to perform defined steps (i.e., software).)
Referring to claim 13,
Robotham discloses A method for producing at least one product associated with preference data, wherein the product is produced by a production from at least one inbound material, the method including:(a) providing the inbound material(s) to a production and producing the at least one product from at least part of the provided inbound material(s) using the production, (Robotham paragraph 38 disclosing to address the shortcomings of known systems described above, the present disclosure sets forth systems and methods that facilitate the admissibility requirements and/or qualification of goods under preferential or non-preferential rules of origin, by representing the requirements to qualify as a set of dependencies on assertions made by producers, exporters or suppliers as to certain attributes of their goods (e.g., country of origin), tokenizing these assertions on a distributed ledger such as a blockchain network, and using the flow of these tokens along with the documents they reference to validate claims to reduced duties or tariffs on those goods, or validating that a tariff should not apply to those goods. Robotham paragraphs 41 teaching the recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. Robotham paragraph 43 teaching in some embodiments, a distributed ledger-implemented (e.g., blockchain-implemented) system manages and exchanges Certificates of Origin and similar declarations related to cross-border commerce. The system can be configured to manage assertions related to the qualification of a good for preferential or non-preferential duties or tariff treatment, tokenize these assertions, and use the flow of these tokens to automate administrative Country of Origin (COO) processes for cross-border supply chains. Robotham paragraph 53 disclosing a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraphs 64-66 disclosing A COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”).While a BOM can specify in detail all components used in the manufacturing process for the good (a “production BOM”), only the minimum set of components used for qualifying under the COO contract may be specified in a BOM (a “partial BOM”). Many free trade agreements allow a claim for preferential or non-preferential duties or tariff treatment based on meeting a minimum set of requirements, and therefore a partial BOM can be sufficient to meet these requirements. For example, a preferential regime could require that 70% of the value of the good has been produced from parts originating within the countries covered under the free trade agreement, and therefore the components specified in a partial BOM can be limited to those needed to meet the relevant threshold. A partial BOM has many practical advantages in reducing the number of components that can be specified in the BOM or BOM contract to be included in a token, thus reducing the number and complexity of processing steps that are related to the number of components in a BOM. Robotham paragraphs 91-92 disclosing when considering the slots defined within an assertion contract, BOM contract or BOM, there is in practice considerable flexibility in defining the rules for resolving the dependencies implied by each slot and the rules for determining that a sufficient number of slots have been resolved to allow assertion tokens to be issued by the assertion contract. In a simplified use case, every component dependency within a given BOM is considered independent, and every component in the BOM is resolved before the producer can generate (mint) its own assertion token based on a COO contract referencing that BOM (or referencing a BOM contract that in turn references that BOM). In this use case, every component is specifying a mandatory dependency, and all dependencies must be resolved to qualify the BOM for use in minting a CO token. Robotham paragraph 94 disclosing one important consideration is that the slots and the rules for resolving their dependencies only need to cover the minimum requirements to support the assertion being made. As described in an example above, to support a COO assertion that 70% of the value of a product comes from parts with origins from a given set of countries, slots only need to be defined for those parts that constitute at least 70% of the value of the product. There may be hundreds of smaller parts that don't contribute to the 70% threshold and therefore do not need to be specified as slots in the COO contract, BOM contract or BOM. In this example, a total cost or total value can be specified in either the BOM contract or COO contract, to validate that the threshold has been met.)
(b) receiving a request to generate the preference data, said request including product data associated with the product, (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e), in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d). Optionally, requests to certify certificates of origin can be received from compute devices of third parties and processed by suppliers and/or manufacturers (i.e., via their associated compute devices), and requests to verify certificates of origin can be received from compute devices of customs agencies and processed by the customers and/or importers of record (i.e., via their associated compute devices), as shown in FIG. 26.)
(c) retrieving - based on the received product data - preference data associated with at least part of the inbound material(s) from inbound material data associated with said part of the inbound materials, wherein the inbound material data associated with each inbound material of said part of inbound materials is accessed - based on a decentral identifier associated with the inbound material data, and optionally based on data related to the inbound material data - by a data consuming service under control of a data providing service being associated with a data owner, said data owner being associated with the respective inbound material data, (Robotham paragraphs 40-42 disclosing a CO token is uniquely identified by a unique identifier, and can therefore be classified, for example, using blockchain nomenclature as a non-fungible token (NFT). The recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. At each such step of the supply chain, the CO token associated with that step may be inspected by a processor, according to inspection rules stored in a memory operably coupled to the processor, prior to transmission of that CO token or upon receipt of the CO token. The processor may authorize the CO token to be transmitted or received, or may block the CO token from being transmitted or received, depending on the outcome of the application of the inspection rules. In some embodiments, inspection of the CO token is performed according to a set of rules defined, for example, by one or more smart contracts, examples of which can include the BOM smart contract, the COO smart contract, and/or the non-COO smart contract, and/or by operations external to the distributed ledger which record the results on the distributed ledger through transactions mediated by one or more of these smart contracts, as discussed herein. For COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement)
(d) retrieving at least one rule of origin for attributing a country of origin to the produced product, and (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e))
(e) generating preference data based on the received product data, the retrieved preference data and the received rule(s) of origin, and associating said generated preference data with the produced product. (Robotham paragraph 169 disclosing FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e).
Referring to claim 15,
Robotham discloses A computer element with instructions, which when executed on one or more computing node(s) are configured to be carried out by the apparatus as claimed in claim 11. (Robotham paragraph 73 disclosing any of the one or more producers 101, one or more suppliers 103, and one or more end consumers 110 can be an importer. The producers 101, suppliers 103, and end consumers 110 each have associated compute devices that can communicate with one another via the telecommunications network “N,” which may be a wireless network, a wired network, or a combination of both. Each compute device of the producer(s) 101 includes a memory 102, a processor 106 operably coupled to the memory 102, and a transceiver 108 (e.g., an antenna) operably coupled to the processor 106. The memory 102 stores data and instructions (e.g., code) executable by the processor 106 to perform defined steps (i.e., software).)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Robotham et al. (US 20210326872) in view of Liu et al. (US 20200364817).
Referring to claim 14,
Robotham teaches A system configured to produce a product associated with preference data from one or more inbound material(s) and to provide the produced product associated with the preference data, the system including: (Robotham paragraph 38 teaching to address the shortcomings of known systems described above, the present disclosure sets forth systems and methods that facilitate the admissibility requirements and/or qualification of goods under preferential or non-preferential rules of origin, by representing the requirements to qualify as a set of dependencies on assertions made by producers, exporters or suppliers as to certain attributes of their goods (e.g., country of origin), tokenizing these assertions on a distributed ledger such as a blockchain network, and using the flow of these tokens along with the documents they reference to validate claims to reduced duties or tariffs on those goods, or validating that a tariff should not apply to those goods. Robotham paragraphs 41 teaching the recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. Robotham paragraph 43 teaching in some embodiments, a distributed ledger-implemented (e.g., blockchain-implemented) system manages and exchanges Certificates of Origin and similar declarations related to cross-border commerce. The system can be configured to manage assertions related to the qualification of a good for preferential or non-preferential duties or tariff treatment, tokenize these assertions, and use the flow of these tokens to automate administrative Country of Origin (COO) processes for cross-border supply chains. Robotham paragraph 53 teaching a Bill of Materials (BOM) can specify one or more parts, obtained from one or more suppliers, that can be correlated to a set of dependencies on supplier assertions that must be met to satisfy the requirements encoded in the COO contract. In some embodiments, a COO assertion smart contract references one or more Bills of Materials (BOMs) for producing the good. Each BOM can also specify other dependencies on assertions required either at the level of an individual part, or at the level of the total BOM, for meeting the requirements for preferential or non-preferential duties or tariff treatment. These other dependencies can include assertions about the labor content, overhead, import/export procedures, or statements of meeting the requirements of a regulatory process. Robotham paragraphs 64-66 teaching A COO contract can reference one or more BOM contracts for the good being produced, and BOM contract can reference one or more BOMs. Each BOM can define a set of components that, at a minimum, meet the requirements for preferential or non-preferential duties or tariff treatment specified in the COO contract. Each component can be a part taken from the producer's inventory and used in the production process (“part component”), a cost allocated to the production process such as labor or overhead or shipping (“cost component”) or a requirement that must be met in order to qualify for the preferential or non-preferential duties or tariff treatment (“requirement component”).While a BOM can specify in detail all components used in the manufacturing process for the good (a “production BOM”), only the minimum set of components used for qualifying under the COO contract may be specified in a BOM (a “partial BOM”). Many free trade agreements allow a claim for preferential or non-preferential duties or tariff treatment based on meeting a minimum set of requirements, and therefore a partial BOM can be sufficient to meet these requirements. For example, a preferential regime could require that 70% of the value of the good has been produced from parts originating within the countries covered under the free trade agreement, and therefore the components specified in a partial BOM can be limited to those needed to meet the relevant threshold. A partial BOM has many practical advantages in reducing the number of components that can be specified in the BOM or BOM contract to be included in a token, thus reducing the number and complexity of processing steps that are related to the number of components in a BOM. Robotham paragraphs 91-92 teaching when considering the slots defined within an assertion contract, BOM contract or BOM, there is in practice considerable flexibility in defining the rules for resolving the dependencies implied by each slot and the rules for determining that a sufficient number of slots have been resolved to allow assertion tokens to be issued by the assertion contract. In a simplified use case, every component dependency within a given BOM is considered independent, and every component in the BOM is resolved before the producer can generate (mint) its own assertion token based on a COO contract referencing that BOM (or referencing a BOM contract that in turn references that BOM). In this use case, every component is specifying a mandatory dependency, and all dependencies must be resolved to qualify the BOM for use in minting a CO token. Robotham paragraph 94 teaching one important consideration is that the slots and the rules for resolving their dependencies only need to cover the minimum requirements to support the assertion being made. As described in an example above, to support a COO assertion that 70% of the value of a product comes from parts with origins from a given set of countries, slots only need to be defined for those parts that constitute at least 70% of the value of the product. There may be hundreds of smaller parts that don't contribute to the 70% threshold and therefore do not need to be specified as slots in the COO contract, BOM contract or BOM. In this example, a total cost or total value can be specified in either the BOM contract or COO contract, to validate that the threshold has been met.)
(c) a request receiver configured to receive a request to generate the preference data, said request including product data associated with the product, (Robotham paragraph 169 teaching FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e), in response to requests for certificates of origin subsequently received at the one or more compute devices of the producer from compute devices of customers and/or importers of record, as shown at step (d). Optionally, requests to certify certificates of origin can be received from compute devices of third parties and processed by suppliers and/or manufacturers (i.e., via their associated compute devices), and requests to verify certificates of origin can be received from compute devices of customs agencies and processed by the customers and/or importers of record (i.e., via their associated compute devices), as shown in FIG. 26.
(d) a preference data provider configured to retrieve - based on the received product data - preference data associated with at least part of the inbound material(s) from inbound material data associated with said part of the inbound materials, wherein the inbound material data associated with each inbound material of said part of inbound materials is accessed - based on a decentral identifier associated with the inbound material data, and optionally based on data related to the inbound material data – [by a data consuming service under control of a data providing service being associated with a data owner], said data owner being associated with the respective inbound material data,
Robotham paragraphs 40-42 teaching a CO token is uniquely identified by a unique identifier, and can therefore be classified, for example, using blockchain nomenclature as a non-fungible token (NFT). The recipient of an assertion token (also referred to herein as a “customer” or “solicitor”), when receiving the assertion token from an issuer thereof, can use the CO token to resolve dependencies on the assertion for qualifying goods that it produces under a given trade program. These dependencies can be referenced directly in a COO contract for a good being produced, or indirectly through another smart contract referenced in that COO contract. Once that customer has received sufficient tokens to resolve its dependencies for a given product that it is producing, that customer, who is now acting as the producer of its own good, can in turn use its own COO contract with the resolved dependencies to issue (mint) its own CO tokens for its product, for use by its downstream customers. This process can be repeated at each step of a supply chain. At each such step of the supply chain, the CO token associated with that step may be inspected by a processor, according to inspection rules stored in a memory operably coupled to the processor, prior to transmission of that CO token or upon receipt of the CO token. The processor may authorize the CO token to be transmitted or received, or may block the CO token from being transmitted or received, depending on the outcome of the application of the inspection rules. In some embodiments, inspection of the CO token is performed according to a set of rules defined, for example, by one or more smart contracts, examples of which can include the BOM smart contract, the COO smart contract, and/or the non-COO smart contract, and/or by operations external to the distributed ledger which record the results on the distributed ledger through transactions mediated by one or more of these smart contracts, as discussed herein. For COO assertions, the assertion smart contract describes the good, the trade program being referenced, and additional properties such as the manner of asserting that the good qualifies under the free trade agreement, the time period of validity of the assertion, the country of origin being claimed for the good or some other type of claim being asserted about the origin of the good being produced, and any other attributes required to meet the qualification. A COO assertion can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes. Depending on the type of the COO assertion, a percentage or other value may be supplied to indicate the relative value of the good that can be attributed to the specified country of origin. In some embodiments, the assertion smart contract can manage a workflow associated with the assertion token or codify rules for determining the eligibility under a given preferential or non-preferential trade agreement
(e) a rule provider configured to retrieve at least one rule of origin for attributing a country of origin to a product produced from at least one inbound material; (Robotham paragraph 169 teaching FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e))
(f) a preference data generator configured to generate preference data associated with the produced product based on the received product data, the retrieved preference data and the retrieved rule(s) rule of origin, and (Robotham paragraph 169 teaching FIG. 26 is a diagram showing token transactions within a networked system including a supplier, a manufacturer, a producer, and customers, according to some embodiments. At step (a), requests for certificates of origin are sent, from one or more compute devices of a producer, to each of a compute device of a supplier and a compute device of a manufacturer. In response to the requests, CO tokens are issued by the compute device of a supplier and the compute device of a manufacturer, at step (b). The CO tokens are written to the distributed ledger. At step (c), a rule of origin check is automatically performed, in response to receiving the CO token(s) and without human intervention, for example in which the one or more compute devices of the producer compares assertions of the CO tokens on the distributed ledger to a set of rules stored in memory of, or accessible by, the one or more compute devices. Assuming that the rule of origin check is successful (i.e., the assertions of the CO tokens satisfy the set of rules), the one or more compute devices of the producer can issue CO tokens at step (e).
(g) an assignor configured to assign the physical identifier to the generated preference data.
(Robotham paragraph 68 teaching for a part component, an illustrative example of a matching criteria is to use the unique identifier (“unique ID”) of a stock keeping unit (“SKU”) for a part maintained in the producer's inventory. In this example, a CO token for a part from a supplier can be mapped into this SKU. The matching CO token becomes eligible for use in resolving the part dependency. A single CO token can be used to resolve part dependencies in multiple components within a single BOM or across multiple BOMs. A part component can also include a commonly used identifier such as a Harmonized Tariff Schedule (HTS) code, used in classifying goods for customs and tariff purposes, in order to facilitate the matching process.)
Robotham does not teach or suggest (a) a production line configured to produce the product from the inbound material(s) and to provide the produced product, wherein the product is connected to or comprises a physical identifier, (b) a collector configured to collect product data associated with the product,
However Liu, which is directed to recording supply chain information on a distributed ledger, teaches
(a) a production line configured to produce the product from the inbound material(s) and to provide the produced product, wherein the product is connected to or comprises a physical identifier, (Liu paragraphs 103-104 teaching the association process may also be integrated with production line, making the process automatic. A typical scenario is that the production line has one or more fixed readers 14 to read tags 12 on the production line and upload data to blockchain 24 one by one. In particular, the association between an item and the unique ID can be automatically established during the production process of the items. In the production line, the manufacturer may equip the automatic assembly line with customization equipment and background link system. The customization equipment and background link system are adapted to automatically obtain from the inventory database 26 the relevant information such as the product batch code, production date, expiration date and so on into the smart label, and then read the product smart label for the information upload blockchain process. The association process can be completed in time in the manufacturing process of the commodity and is suitable for large enterprises with mature commodity production lines.)
(b) a collector configured to collect product data associated with the product, (Liu paragraphs 103-104 teaching the association process may also be integrated with production line, making the process automatic. A typical scenario is that the production line has one or more fixed readers 14 to read tags 12 on the production line and upload data to blockchain 24 one by one. In particular, the association between an item and the unique ID can be automatically established during the production process of the items. In the production line, the manufacturer may equip the automatic assembly line with customization equipment and background link system. The customization equipment and background link system are adapted to automatically obtain from the inventory database 26 the relevant information such as the product batch code, production date, expiration date and so on into the smart label, and then read the product smart label for the information upload blockchain process. The association process can be completed in time in the manufacturing process of the commodity and is suitable for large enterprises with mature commodity production lines. Liu paragraph 107 teaching in one embodiment, the reader 14 is adapted to carrying out a tag reading method comprising the steps of reading an identification number along with other information from the tag, such as an RFID/NFC tag, or barcode label. The reader 14 then sends the identification number and other information received to one or more servers 22. The server 22 then invokes the application programming interface (API) to the database 26 to obtain a search result from the database. Depending on the implementation, the API carry out the process of reading the inventory information and/or recording the identification information to the database. The server 22 then secure the information on the blockchain 24. Liu paragraph 118 teaching in another embodiment, the reader 14 is a mobile device with an Android or Apple iOS mobile application which can be installed on an android phone or Apple iPhone with NFC or camera capabilities . The mobile application adapted to carry out the functions of: Authentication, Scanning products, and Sending data for blockchain transaction. The Authentication function is adapted to identify each object of the system 10. Scanning product function is adapted to allow Employee using the mobile application to gather unique ID associated with the object. The unique ID will be processed on the mobile device and wait to be uploaded to the blockchain. The Send blockchain transaction function can be performed when the mobile devices have access to the Internet and send information such as the product location, product details and employee information or the authenticated code thereof to the blockchain through the Internet. From there the tracking information will be stored in the blockchain and can be displayed when needed. Liu paragraphs 279-280 teaching in the manufacturing field, a configuration of UPhoto will monitor and record the manufacturing process and environment (temperature, pressure, etc). During production, smart contracts are programmed to set parameters so that operational data and results are immediately online. This ensures that all processes are well documented and ensures that all information is completely transparent from the very beginning of the supply chain. An emergency protocol is activated if an incident occurs in any of the links in the supply chain. During packaging, smart labels containing a globally unique fingerprint for each unit, are placed on each product through assembly line equipment. The smart label contains all the information about the product including its environment, shelf life, production time, etc. The IoT equipment is provided for enterprises which are installed at the time of shipment and allows real-time monitoring of the products' entire journey. This data is encrypted and stored in the blockchain thus ensuring the safety of the products and reducing human error and interference. Furthermore, all this data that is collected during the supply chain process is accessible via the UTMS which makes it convenient for manufacturers to access big data reports.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the analysis of preferential treatment for a product as part of the supply chain as taught in Robotham to incorporate (a) a production line configured to produce the product from the inbound material(s) and to provide the produced product, wherein the product is connected to or comprises a physical identifier, (b) a collector configured to collect product data associated with the product, as taught in Liu with the motivation of utilizing conventional equipment as part of the supply chain for facilitating the recordation of product data associated with a produced product. (Liu paragraphs 103-104 and 279-280)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nelson et al. (US 20230306442) – directed to providing product object story data structures.
Vargas et al. (US 20220171951) – directed to tracking products.
Chung et al. (US 20120116930) – directed to process-based origin management.
Dahod et al. (US 20200286026) – directed to blockchain assisted asset pedigree traceback.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MICHAEL J MONAGHAN whose telephone number is (571)270-5523. The examiner can normally be reached on Monday- Friday 8:30 am - 5:30 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Sarah Monfeldt can be reached on (571) 270-1833. 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.
/Michael J. Monaghan/Examiner, Art Unit 3629
Prosecution Insights