DETAILED ACTION
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 .
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on September 9, 2025 has been entered.
Status of Claims
Claims 1 - 37 were cancelled, while claims 38 - 46 were added.
Claims 38 - 47 are pending and have been examined.
This action is made NON-FINAL.
Response to Arguments
Applicant's arguments filed September 9, 2025 have been fully considered but they are not persuasive.
Regarding the applicant's arguments against the 101 rejection of pending claims on pages 2-5: Applicant’s arguments directed to 101 analysis were considered. However, these arguments are not persuasive and the examiner respectfully disagrees for the following reasons:
For Step 2A-Prong 1 starting in p. 3: The Applicant argues that the pending claims are not directed to any of the abstract ideas identified because “the newly added claims go beyond this characterization by requiring tangible components” to read the identifiers in encrypted form which are “specific technical implementations”, allegedly while comparing the DDR holding federal decision. However, the Examiner finds these arguments unpersuasive and respectfully disagrees. Generally, because this is not how an Examiner concludes that the claimed invention and its pending claims are part of an abstract idea. Firstly, the pending claims were analyzed and “evaluated after determining what [the] applicant has invented by reviewing the entire application disclosure and construing the claims in accordance with their broadest reasonable interpretation (BRI)” for Step 2A-Prong 1 and 2 (See MPEP § 2106, subsection II, for more information about the importance of understanding what the applicant has invented, and MPEP § 2111 for more information about the BRI). Further, each claim “recites” a judicial exception when the judicial exception is “set forth” or “described” in the claim (see MPEP 2106.04, subsection II) which recited steps of “(iii) determining said RVT [representative value of trust] for said TR” or transaction record by evaluating data matches/correlations between transactions (TR) and other factors for data compliance, to then “(v) sharing said RVT with at least one authorized entity in possession of or monitoring said item…” for the purpose of utilizing the “RVT for verification or decision-making purposes”. Thus, these recited steps encompassed commercial interactions related to business relations between trusted parties that are verified through their transactions and mitigation of risks in order to avoid financial transactions linked to falsified/counterfeit products. Moreover, the determining and evaluating limitations required evaluation and judgement to evaluate data to enable the RVT determined to be used for verification or decision-making determinations. Finally, these last steps do not negate and further still reads in the mental nature of the limitation(s), when obtaining such information, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of determining the representative value of trust (RVT) per transaction for verification or decision-making purposes (see MPEP 2106.04(a)(2)(III)(B & C)).
For Step 2A-Prong 2 and Step 2B starting in p. 3: The Applicant alleges that the claims integrate, the judicial exception identified, into a practical application and further alleges that the “combination of FUI and SUI on physical media read via inductive coupling provides a two-factor style authentication mechanism that significantly improves the trustworthiness of digital tracking systems” and improves “computer security functionality” by “providing a technical solution to a recognized problem in supply-chain verification”. However, the Examiner finds these arguments unpersuasive and respectfully disagrees. Because the abstract ideas identified in the claims are not being integrated into a practical application or does not amount to significantly more than the judicial exception (e.g. abstract idea(s)) itself when considering the additional elements individually and in combination. Rather, the claim limitations invoked the use of a computer as a tool to perform an abstract idea (see MPEP 2106.04(d)(I) and MPEP 2106.05(f)). Thus, not providing an inventive concept at Step 2B. Therefore, these claims, contrary to Applicant assertions for using “cryptographic encoding sequences that ensure identifiers are revealed only upon successful completion of an authentication challenge” and the element features later required at least in claim 41 and 45 and as argued in p. 4 from remarks, does not reflect an improvement to the way the computer is working to specifically and distinctively recite how such alleged “tracking” and “authentication” is achieved for preserving “data integrity”, flagging “counterfeit products” and “automatically recalculate trust values”. Rather, as the Applicant asserts, related “cryptographic encoding sequences” used/employed (e.g. applied, at least in claim 47) by the computer and the blockchain technology broadly claimed in addition to the high level of generality that the claim limitations provide for the “authentication or a cryptographic challenge”. Specifically, the limitations in claims 44 – 45 and 47 are “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the blockchain technology for the “distributed ledger system” used to store or retrieve related TR data is broadly recited and simply attempts to limit the use of the abstract idea to computer environments and/or the blockchain claimed (see MPEP 2106.05(h) for examples (ix) and (x)). Also, Applicant’s disclosure does not provide more detail about how the alleged “cryptographic encoding sequences” are used/ “employed” (see at least ¶0037 – 38 and Figs. 1 – 2 from Applicant’s disclosure). Thus, the claim steps further describe the end result without providing details on how this alleged “improvement” to the computer functioning and/or to the existing technology of “computer-based tracking and authentication systems” is achieved. Thus, for all the reasons stated above, the Examiner respectfully disagrees, and maintains 35 USC § 101 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 102 for the pending claims on pages 5 – 6: Applicant’s arguments with respect to claim(s) 38 - 47have been considered but are not persuasive. Firstly, because the prior art of Feeney still teaches the use of the SUI permanently paired to the FUI on a physical microchip as claimed in claim 41, which is directed to the “first code” or “RFID tag concealed within a product” that can hide in a chip or “smartcard” (e.g. SUI) that identifies “the transaction register 205 a” along with the “product identifier” (e.g. directed to the FUI; see ¶0074; Feeney) (see ¶0076 – 77; Feeney).
Secondly, regarding Feeney not teaching “blockchain authentication elements stored on physical media or a consent cloud system for secure verification of transactional updates”, the Examiner disagrees. Because Feeney teaches that “users may utilize the system 200” (including the “the transaction register 205 a” that is a “block chain or a consensus ledger”; see ¶0061; Feeney) to record further appraisals of goods” wherein the “user may append a code to a possession of the user, and given an appraisal by a qualified person, who may be registered with the system 200, the user may be able to add the possession to the system as an authenticated product” (see ¶0093; Feeney), when following the “authentication element” example in ¶0084 from Applicant’s disclosure, under the broadest reasonable interpretation (BRI) of the claim language. Similarly, upon “scanning, by a computing device, using a code scanner, an address from a code affixed to a product (601)” the system can verify that “the address is associated with a crypto-currency transaction recorded at a transaction register (602)” that includes “additional datum” from the “code” such as “the location of a merchant that is authorized to sell the product” (see ¶0120), which is directed to the blockchain authentication element with sufficient data to verify said item against a distributed blockchain ledger, in accordance to the “data elements” associated to the FUI and SUI within the distributed ledger example (e.g. interpreted as blockchain authentication elements) given in ¶0040 – 41 from Applicant’s disclosure.
The subsequent arguments made by the Applicant fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the Feeney reference. Please, refer to the Claim Rejections - 35 USC § 103 section for further details. Therefore, for all these reasons stated above, the Examiner respectfully disagrees, and maintains 35 USC § 102 rejection for these pending claims.
Regarding to Applicant's arguments of rejection under 35 USC § 103 for the pending claims on pages 6 – 7: Applicant’s arguments regarding these amended limitation steps in the pending claims are not persuasive because the combination of Feeney with Greco is relatable for rejecting claim 47. Specifically, the rationale to modify or combine the prior art does not have to be expressly stated in the prior art; the rationale may be expressly or impliedly contained in the prior art or it may be reasoned from knowledge generally available to one of ordinary skill in the art, established scientific principles, or legal precedent established by prior case law. (see MPEP 2144(I)). Therefore, the Examiner respectfully disagrees, and maintains 35 USC § 103 rejection for these pending claims.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 41 and 47 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. claim 47 recite is directed in part to limitations involving “wherein said inductive coupling device employs a cryptographic encoding sequence prior to or during reading of said SUI, such that said FUI or said SUI is obtained or revealed only upon successful completion of an authentication or a cryptographic challenge between a tag and a transaction input device”. However, for this device employing this encoding technique to reveal or obtain identifier data, the "algorithm or steps/procedure taken to perform the function must be described with sufficient detail so that one of ordinary skill in the art would understand how the inventor intended the function to be performed” (See MPEP 2161.01). However, the Applicant’s specifications in ¶0037 – 38 and Figs. 1 – 2, lacks sufficient detailed information or discussion about the specific steps or procedures taken to perform the “cryptographic encoding sequence” step that is employed and how such encoding occurs to reveal or obtain the identifier data (e.g. FUI or SUI), as claimed in which their respective algorithm was not disclosed. Therefore, a person ordinary skill in the art would not be able to recognize the boundaries and restrictions (e.g. by defining the meets and bounds of the invention) of the function for employing the “cryptographic encoding sequence” technique being claimed and distinctively recognize the claimed invention to avoid infringement. Moreover, the disclosure broadly recites and fails to detail the at least how the “inductive coupling device” is employing such cryptographic encoding claimed. Therefore, the disclosed claim limitations are considered to be lacking possession of the subject matter claimed and indicated above which is not sufficiently supported by the specifications as originally filed.
Thus, for examination purposes the Examiner has interpreted the functionality of this limitation step in a general sense applying the Broadest Reasonable Interpretation (BRI) as simply receiving a challenge message wherein a tag digitally signs the challenge with a private key to transmit these two data elements and verify if it matches an original challenge message that upon a successful authentication third party server provides access to the content associated with the item product a which is reasonable when viewed in light of Applicant’s disclosure as previously cited. For the same reasons stated above, claim 41 is rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ) based on their dependency to claims 47.
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 38 - 47 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention. Because the following claims recite subjective terms that are disclosed as follows:
The term “an expected threshold” in claim 38 for the limitation of “evaluating a data correlation to determine compliance within an expected threshold from either a prior TR or a following TR from said RS”, this underlined term is a relative term which renders the claim indefinite. The term “expected threshold” is not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree for determining compliance within such a threshold, and one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Also, this term is subjective because someone of ordinary skilled in the art wouldn’t know how the compliance is within a threshold simply based on being “expected” and the specifications fail or do not further describe some kind of standard to measure this scope term at least when in view of the example of data elements complying within “expected patterns” given in ¶0079 from Applicant’s disclosure (See MPEP 2173.05(b)). Thus, for examination purposes the Examiner has interpreted the functionality of this limitation step in a general sense applying the Broadest Reasonable Interpretation (BRI) as simply evaluating data correlations to determine compliance within a threshold that is set by the user/entity or “reporting source (RS)” criteria which is reasonable when viewed in light of Applicant’s disclosure.
The term “less than an entire blockchain” and “data sufficient to verify” in claim 45 for the limitation of “wherein said blockchain authentication element comprises less than an entire blockchain and includes data sufficient to verify said item against a distributed blockchain ledger is also stored on said re-writable memory”, these underlined terms are relative term which renders the claim indefinite. These terms are not defined by the claim, the specification does not provide a standard for ascertaining the requisite degree to establish what a “blockchain authentication element” can be considered “less than an entire blockchain” and include data that is “sufficient” for verification wherein one of ordinary skill in the art would not be reasonably apprised of the scope of the invention. Also, these terms are subjective because someone of ordinary skilled in the art wouldn’t know how to measure when the data element is enough to be considered “sufficient” data for verification with the distributed blockchain ledger” and the specifications fail or do not further describe some kind of standard to measure this scope terms at least when in view of the “data elements” associated to the FUI and SUI within the distributed ledger example (e.g. interpreted as blockchain authentication elements) given in ¶0040 – 41 from Applicant’s disclosure (See MPEP 2173.05(b)). Thus, for examination purposes the Examiner has interpreted the descriptive matter and possible functionality of this limitation step in a general sense applying the Broadest Reasonable Interpretation (BRI) as simply having “data elements” that are recorded in the distributed ledger which is reasonable when viewed in light of Applicant’s disclosure.
Therefore, the scope of what is claimed is not clear for these reasons stated above and these claims are considered to be indefinite. For the same reasons stated above, claims 39 – 44 and 46 – 47 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ) based on their dependency to claims 38 and 45.
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 38 - 47 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The analysis of this claimed invention is recited in claim 38: as follows:
At Step 1: Claim 38 falls under statutory category of a process.
At Step 2A Prong 1: Claim 38 recites an abstract idea, which is defined by the following underlined elements (e.g. functional steps) while omitting any hardware components (e.g. represented as “…”):
(i) obtaining a TR having a plurality of data including at least a record identifier, a date, a time, an item identity of an item, a device location, a device identifier, a device type, and a device description;
(ii) recording said record identifier,
(iii) determining said RVT for said TR by:
evaluating a data match between said TR and another TR referencing said item identity;
evaluating a data correlation to determine compliance within an expected threshold from either a prior TR or a following TR from said RS;
evaluating said plurality of data of said TR synchronized with data of a plurality of other items traveling together with said item identity; and
evaluating said plurality of data of said TR to determine if said plurality of data is not expected in reference to prior TR or a following TR from said RS;
(iv) recording said RVT; and
(v) sharing said RVT with at least one authorized entity in possession of or monitoring said item, thereby enabling [[said]] said authorized entity to utilize said RVT for verification or decision-making purposes.
These limitations, describe a method for collecting transactional events regarding to physical products to evaluate value of trust for each transaction for product verification and authenticity purposes. As disclosed in the specification in ¶0035, this invention “resolves the inconsistencies in data records (transactions) for physical goods (objects), and the resulting potential transaction/date falsification issues present in the prior art by incorporating a second unique identifier linked to a first unique identifier associated/linked with an object thereby effectively enabling a traditional two-factor style authentication for transactions involving the creation, movement, and consumption of manufactured objects (products and materials)”. However, the abstract idea(s) of a certain method of organizing human activity (See MPEP 2106.04(a)(2), subsection II) are/is recited in claim 38 in the form of “commercial or legal interactions”. Specifically, the abstract idea is recited in the steps of “(iii) determining said RVT [representative value of trust] for said TR” or transaction record (e.g. steps c - g) and “(v) sharing said RVT with at least one authorized entity in possession of or monitoring said item…” for the purpose of utilizing the “RVT for verification or decision-making purposes”. Because determining a value representing trust of at least one monetary transaction encompasses commercial interactions related to business relations between trusted parties that are verified through their transactions. Similarly, these steps also fall under the abstract idea sub-group of “fundamental economic principles or practices” since determining such RVT per transaction and sharing it with authorized entities for verification purposes and other decision-making determinations at least encompasses mitigation of risks in order to avoid financial transactions linked to falsified/counterfeit products.
On the other hand, the step of “(iii) determining said RVT [representative value of trust] for said TR” or transaction record and the subsequent steps d – g and i (or step (v)), fall under the abstract idea of mental processes that can be practically be performed in the human mind or in pen and paper (See MPEP 2106.04(a)(2), subsection III). Because determining the RVT by “evaluating a data match” between a TR and a referenced TR with item identity, “evaluating a data correlation” for compliance, “evaluating” plurality of data or the “TR synchronized with data” of other items with item identity to determine the data that is not expected and enabling the RVT determined to be used for verification or decision-making determinations encompass evaluation and judgement. Also, these steps can either be done with the help of physical aid such as pen and paper or can be performed by humans without or with the assistance (e.g. tool) a computer. Thus, the steps does not negate and further still reads in the mental nature of the limitation(s), when obtaining such information, as well as the concept is merely claimed to be performed on a generic computer and is merely using a computer as a tool to perform the concept of determining the representative value of trust (RVT) per transaction for verification or decision-making purposes (see MPEP 2106.04(a)(2)(III)(B & C)).
Step 2A Prong 2: For independent claim 38, This judicial exception is not integrated into a practical application. Because the claim has no additional feature element(s) for recording transaction record with different identifiers associated to an object to share the TR with an entity possessing the object to verify transactions or for other decision-making purposes, which merely invokes the use of a computer as a tool to perform the abstract idea (refer to MPEP 2106.05(f)). These element features including the computer and are recited at a high level of generality and are performed generally to apply the abstract idea without placing any limits on how these steps are performed distinctively from generic computer components and without having each function to generally “apply it” to a computer. See MPEP 2106.05(f).
As for the steps of “obtaining a TR having a plurality of data…” and the “recording” steps for “record identifier(s)” and RVTs and the step of “sharing” the RVT with authorized entities in possession of the item, are really nothing more than links to computer for implementing the use of ordinary capacity for economic or other tasks (e.g., to receive, store, or transmit data) or simply adding a general-purpose computer or computer components (refer to MPEP 2106.05 f (2)).
Step 2B: For independent claim 38, The claim(s) do not include additional elements that are sufficient to amount to significantly more than the judicial exception. Because the steps for recording transaction record with different identifiers associated to an object to share the TR with an entity possessing the object to verify transactions or for other decision-making purposes, are not sufficient to amount significantly more than the judicial exception or abstract idea (see MPEP 2106.05). Because, as indicated in Step 2A Prong 2, these additional element(s) claimed are merely, instructions to “apply” the abstract ideas, which cannot provide an inventive concept. Also, the recitation of the claim limitations amounts to no more than mere instructions to apply the exception using a generic computer component. Thus, even when considered in combination, these additional elements represent mere instructions to implement an abstract idea or other exception on a computer, which do not provide an inventive concept at Step 2B.
For dependent claims 39 - 47, these claims cover or fall under the same abstract idea of a method of organizing human activity and mental processes. They describe additional limitations steps of:
Claims 39 – 47: further describes the abstract idea of the method for creating a representative value of trust (RVT) for a transaction record (TR) and how different evaluation indices (EIs) and transaction events (e.g. HTEs and ATEs) are retrieved, compared to determine/calculate the value of trust (RVT) for each TR that is updated/verified, and wherein the unique electronic tracking identifier (UETI) further comprising a second unique identifier (SUI) is physically attached to said item and how the RVT calculation evaluates the HTE with the FUI matching the SUI within the UETI while adjusting the Eis based on transaction parameters to further adjust RVT calculations which can also involve other conditions for increasing it. Also, the limitations further describe how the FUI and SUIs are read and the additional user observable data included in the HTEs. Thus, being directed to the abstract idea groups of “fundamental economic principles or practices”, “engaging in commercial or legal interactions” and “mental processes” as it is for the purpose of mitigating the risk of falsified products by determining a transaction trust factor that can be mentally performed requiring evaluation and judgement for the linked products while ensuring legit business relations with trust factor values.
Step 2A Prong 2 and Step 2B: For dependent claims 41 and 44 - 47, these claims recite the additional elements: an inductive coupling device (claims 41 and 45); a distributed ledger, a blockchain or a hash-graph distributed ledger (claims 44 – 45); a re-writable memory and a processor (claim 45); a consent cloud in the form of a system (claim 46) and a cryptographic encoding sequence and a transaction input device (claim 47) which are also recited to be merely used as a tool to perform the abstract idea to handle, read and store/retrieve the product identifiers (e.g. FUIs and SUIs) with an authentication/cryptographic challenge, EIs and/or data related to the transactions and verify changes/updates related to this same data for positive verification and data integrity . Thus, it amounts no more than mere instructions to apply the exception using a generic computer component (MPEP 2106.05(f)). Therefore, these claim limitations amount to no more than mere instructions to apply the exception using generic computer components and or computing technologies (e.g. that are merely deployed to be used as a tool; see MPEP 2106.05 (f)).
Also, the feature elements in claims 44 – 45 and 47 related to the steps of “…recording said record identifier and determining said RVT for said TR involve data stored on or retrieved from a distributed ledger system…”, “…write to the memory a blockchain authentication element…” and employing “a cryptographic encoding sequence prior to or during reading of said SUI…”, respectively, are “merely indicating a field of use or technological environment in which to apply a judicial exception do not amount to significantly more than the exception itself, and cannot integrate a judicial exception into a practical application” (MPEP 2106.05(h)). In this case, the blockchain technology for the “distributed ledger system” used to store or retrieve related TR data is broadly recited and simply attempts to limit the use of the abstract idea to computer environments and/or the blockchain (see MPEP 2106.05(h) for examples (ix) and (x)). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. These claims are still directed to an abstract idea without being integrated into a practical application.
Finally, the additional elements previously mentioned above, are nothing more than descriptive language about the elements that define the abstract idea, and these claims remain rejected under 101 as well.
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.
Claims 38 - 46 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Feeney (U.S. Pub No. 20160098723 A1).
Regarding claim 38:
Feeney teaches:
(i) obtaining a TR having a plurality of data including at least a record identifier, a date, a time, an item identity of an item, a device location, a device identifier, a device type, and a device description; (ii) recording said record identifier, (In ¶0046; Fig. 2 (201 and 205); Fig. 3 (301 – 303); Fig. 4 (402); Fig. 5 (501); Fig. 6 (602 – 603): teaches that “the first computing device 201 is configured to obtain an address, and to file a crypto-currency transaction 204 to the address in at least one transaction register 205 a” wherein the transaction is a “collection of textual data stating that the owner of a certain transferable item represented in the transaction register is transferring that item to the owner of an address, along with a digital signature created using the private key associated with the owner's public key” and a “first crypto-currency transaction 204” record includes “a data structure linking the first address and the identifier of the allocated transaction register 205 a” (see ¶0078) which satisfies the descriptive matter that the TR data includes, as claimed and a record identifier as the identifier for the transaction. Also, “new transactions concerning the first product 201 record the identity of the current user” which “may also be stored on the first code 207 or a subsequent code” wherein “the first code 207, a subsequent code, or a transaction may record the current state of the product” as well as the transaction “may be linked to an agreement to lease or purchase the access right” (see ¶0093 and ¶0095). Refer to ¶0107 – 108 wherein “the first computing device 201 stores the product identifier in a transaction register 205 a” wherein the “product identifier may include an address” or “produces a first string containing a product identifier and at least one additional datum (501)” wherein the “additional datum 501” includes “a timestamp” with a “date” that the “product was delivered to a merchant” and/or it can include “a universal product code (“UPC”) corresponding to the product” as well as its brand, description, and its “lot number” (see ¶0120).)
(iii) determining said RVT for said TR by: evaluating a data match between said TR and another TR referencing said item identity; (In ¶0113; Fig. 3 (305 – 306): teaches that the “determination of authenticity may include querying the first computing device 201 using the first string; the first computing device 201 may determine that the product identifier is a valid product identifier, stored in memory accessible to the first computing device 201” wherein the “query may include merchant information, which the first computing device 201 may compare to merchant information pertaining to the correct sale of the first product” directed to evaluating matches between the TR and another TR referencing the item ID. Similarly, “computing device 203 determines that the product is authentic based on the verification and the at least one current transaction datum (604)” wherein “computing device 203 may compare each current transaction datum to at least one additional datum” such as based on “location information” and “if the locations match, the smartphone may indicate to the user that the product is authentic; if they do not match, the smartphone may indicate that the product is not authentic” (see ¶0128).)
evaluating a data correlation to determine compliance within an expected threshold from either a prior TR or a following TR from said RS; (In ¶0087; Fig. 3 (305 – 306): teaches that the “second computing device 203 may determine that the first product is authentic only if the trustworthiness score is above a certain threshold”. But also, the “second computing device 203 may set threshold amounts regarding other scores, such as customer satisfaction; for instance, the financial value of a transaction for which the second computing device 203 will authenticate the first product may be related to a customer satisfaction score” which is based on the example of data elements complying within “expected patterns” given in ¶0079 from Applicant’s disclosure.)
evaluating said plurality of data of said TR synchronized with data of a plurality of other items traveling together with said item identity; and (In ¶0091: teaches that “bulk shipments may be tracked, in bulk, using a single code which contains a series of transactions transferring the output of each previous transaction to an address associated with the next carrier, warehouse, or shipment in the transport and supply operation; each item in the bulk shipment may have a transaction from the address of that item to an address corresponding to the bulk shipment as a whole, so that an item can be traced readily to its bulk shipment, aiding in the discovery of theft or accidental diversion from shipments”, which is in accordance to the example given in ¶0063 and ¶0070 from Applicant’s disclosure.)
evaluating said plurality of data of said TR to determine if said plurality of data is not expected in reference to prior TR or a following TR from said RS; (In ¶0097 – 98; Fig. 3 (305 – 306): teaches that “the second computing device 203 determines that the data is problematic by determining that the second address is not associated with a transaction in the transaction register 205 a; for instance, the second code may be a counterfeit code designed to imitate the appearance of the codes used in the system 200”. Similarly, “the second computing device 203 determines that the data is problematic by checking it against an inventory tracking system; for instance, the inventory tracking system may describe the second product as being located in a different location, or with a different merchant, than the location at which it was scanned” and the “inventory tracking system may report that the second product is supposed to be associated with one or more additional products; the lack of the associated products may indicate that a set of components of which the second product was one component, which combined form a single product for sale, have been separated improperly, for instance by a “chop shop” that sells parts of stolen goods”.)
(iv) recording said RVT; and (In ¶0086; Fig. 3 (303 – 306): teaches that upon scanning with a “code scanner”, the “first code” affixed to a product, the user can verify that “the product being offered to the customer for sale is authentic, or to verify the manner in which the retail acquired the product” wherein response the “first address” is received by “a second computing device 203” which further verifies the “first crypto-currency transaction at the transaction register , using the first address (305)” (see ¶0080 – 81) and subsequently the “second computing device 203” during the product’s authenticity verification, can obtain “a trustworthiness score for the entity that filed the first crypto-currency transaction” (directed to the RTV being recorded in the filed transaction) which is calculated “using information gathered from the transactions performed by the entity operating the first computing device 201”.)
(v) sharing said RVT with at least one authorized entity in possession of or monitoring said item, thereby enabling [[said]] said authorized entity to utilize said RVT for verification or decision-making purposes. (In ¶0086; Fig. 4 (402 – 403); Fig. 5 (503): teaches that the “trustworthiness score may be based in part by reviews of transactions involving the entity operating the first computing device 201 by recipients of crypto-currency transactions from the entity” wherein such “reviews may be visible to users” to “allow user to consider the reviews in context of the reviewers' trustworthiness” which is directed to sharing the TR with an entity that either possess or monitors the object which uses the RVT to make purchasing or ownership transfer decisions based on trust verification. Refer to ¶0088 for more details of the “the second computing device 203, or the user thereof” being allowed to see “repeated transactions” to “authenticate both the product and the stage in the sales cycle from manufacturing to sales that the product occupies”. Refer to ¶0028 wherein “encryption and decryption keys in symmetric cryptographic systems may be kept secret, and shared only with persons or entities that the user of the cryptographic system wishes to be able to decrypt the cyphertext”.)
Regarding claim 39:
Feeney, as shown in the rejection above, discloses the limitations of claim 38.
Feeney further teaches:
wherein determining said RVT further comprises performing a plurality of steps of: (i) retrieving a set of evaluation indices (EI) each comprising an expected pattern, a range, a criterion, or a value for at least one corresponding transaction parameter selected from device identifiers, transaction types, time stamps, location data, and object identifiers; (In ¶0087; Fig. 3 (305 – 306); Fig. 5 (501): teaches that the user can see the determination of a “first product” being “authentic only if the trustworthiness score is above a certain threshold”, via the “second computing device 203” which are directed to the set of Eis that at least include a criterion or a value for at least one of a transaction and the device ID, in accordance to ¶0053 from applicant specs. But also, “second computing device 203 may set threshold amounts regarding other scores, such as customer satisfaction” (e.g. ranges and criterion or values), “qualitative indicia of the reputation of the operator of the first computing device 201, such as customer or transaction-partner reviews” (e.g. expected patterns) to authenticate or not based on the “perusal of the provided qualitative indicia” which are generally directed to the corresponding transaction parameters selected. As for the descriptive matter that the at least one corresponding transaction parameter(s) consist of, the prior art teaches that “the second computing device 203 also verifies that the private key used to perform the transaction belongs to the entity that uses the first computer 201” (e.g. device identifier) by querying “the private register 205 b” via “a web site or mobile application” and can “confirm that the entity controlling the first computer 201 is the possessor of a public key or linked address, such as the first address” as well as the “crypto-currency transaction may identify a particular computing device as linked to the first entity” and “a network location as linked to the first entity” (see ¶0082). Also, the object identifiers, transaction types date/time stamps and location data are directed to the “first string containing a product identifier and at least one additional datum (501)” produced and stored by the “the first computing device 201”, wherein the additional datum includes “a timestamp” which may “describe the anticipated time the product will be in stock at the merchant” and the identification of a merchant including their business name, “retail branch or stock warehouse” and its jurisdiction/location(see ¶0107 – 108), such that this data is retrievable by “the second computing device 203” per product and their related transactions (see ¶0083).)
(ii) retrieving a plurality of historical transactional events (HTE) associated with said item identity, said plurality of HTEs including prior instances of TRs for said item identity; (In ¶0083; Fig. 3 (305): teaches that the “the second computing device 203 checks a series of transactions including the first transaction 205 a; as an example, where the first transaction 204 is the latest of a series of transactions tracking a product through its supply chain”. Thus, such transactions already include all the descriptive subject matter claimed which is the same for the previous limitation since the transactions are linked with the product and its “first code”. Refer to ¶0090 wherein a party can verify whether a product is counterfeit or not and can request to updated transactions to show the “product has changed hands” for a “second crypto-currency transaction 208” a being recorded.)
(iii) comparing said plurality of data from at least one other TR, where said item identity is stored via a unique electronic tracking identifier (UETI), said UETI including a first unique identifier (FUI) and any combination of said plurality of data, said set of EI, or said plurality of HTEs to calculate said RVT for said TR; and (In ¶0112; Fig. 3 (305): teaches that “determining authenticity includes determining that the encrypted first string may be decrypted correctly using the public key; for instance, the determination may include verifying that the first string, after decryption, has a required form, such as a product identifier concatenated with at least one additional datum” directed to UETI and FUI and any combined data, in accordance to the FUI definition in ¶0037 from Applicant’s disclosure. But also, the “determination of authenticity may include comparing, by the first computing device 201, data in the decrypted first string to additional data”. As an example “the second computing device 203 compares a mathematical representation in the first string purporting to represent additional information in the first code 207 to a mathematical representation generated from the additional information in the first code 207”. In another example, “the second computing device 203 compares additional information in the first code 207 to information concerning the circumstances of the sale of the first product; for instance, the second computing device 203 may compare the location of the first sale to a location recorded in the first code 207, or the second computing device 203 may compare the merchant described in the first code 207 to the merchant offering the first product for sale” which are directed to the Eis and HTEs used later to calculate/update the RVTs.)
(iv) storing said RVT. (In ¶0086; Fig. 3 (303 – 306): teaches that the “second computing device 203” during the product’s authenticity verification, can obtain “a trustworthiness score for the entity that filed the first crypto-currency transaction” (directed to the RTV being stored in the filed transaction) which is calculated “using information gathered from the transactions performed by the entity operating the first computing device 201” directed to the HTEs and Eis used as a basis for its calculation (see ¶0080 – 81 and ¶0087).)
Regarding claim 40:
Feeney, as shown in the rejection above, discloses the limitations of claim 39.
Feeney further teaches:
wherein said UETI further comprises a second unique identifier (SUI) singularly and permanently associated with said FUI, wherein said SUI is physically attached to said item (In ¶106 – 107; Fig. 5: teaches that the product being scanned to analyze their corresponding transaction (e.g. TR) and its “trustworthiness score” (e.g. RVT value), includes a “first code 207” that is affixed to the physical product or “first product” which is directed to the SUI that is associated to the FUI since this “first code” was exported from the initial encryption of the “first string with a private key of a public key cryptographic system (502)” (e.g. directed to the FUI) and the “first code” in the form of “RFID tags affixed” in the product can be scanned to locate the product identification and retrieve their private key (see ¶0040 and ¶0080 – 81). Further, this “private key” derives from the “product identifier” (e.g. directed to the UETI) that is held in the “first string” when authenticating the product (see ¶0109 – 113 for more details and examples).)
and said RVT calculation further evaluates said HTE with said FUI matching said SUI within said UETI, (In ¶0086 – 87: teaches “trustworthiness score” (e.g. directed to RVT) may be “calculated using information gathered from the transactions performed by the entity operating the first computing device 201” (e.g. directed to the HTEs) and “trustworthiness score may be based in part by reviews of transactions involving the entity operating the first computing device 201 by recipients of crypto-currency transactions from the entity” wherein the “user of the second computing device 203” can “consider the reviews in context of the reviewers' trustworthiness”. Further, such transactions can be further evaluated to verify if their respective FUI or “private keys” match their corresponding SUI or “first codes” affixed to the product in question, by considering attempts of “double spending” in the score (see ¶0053 and ¶0097 for “double spending” examples) and other “behavior suggesting fraud” as well as collecting “qualitative indicia of the reputation of the operator” (¶0087) which is directed to evaluating matches between the FUI and SUIs for a product. Refer to ¶0099, ¶0115, ¶0117 and ¶0128 – 129 for examples of such mismatches of the transactions or scanned codes linked to the product identifier’s data that could deem the product counterfeit, indicates that is inauthentic or is a possible theft.)
and further comprising adjusting one or more of said set of EIs in response to parameters of transactions of said item identity that were previously unspecified in said set of EIs, by incorporating any such previously unspecified transaction parameters into said set of EIs and correspondingly adjusting said RVT, thereby refining a trust calculation as new transaction context data becomes available. (In ¶0086 – 87: teaches that “the trustworthiness score may be lowered for each attempt at double spending by the entity” which is directed to adjusting/refining the RVT by considering EIs of factors such as “double spending”. “Double spending” refers to “crypto-currency transactions 204 registered” by two entities simultaneously in “two alternate branches” that creates a “fork” and these transactions are then “recreated in a new block in the valid branch” which are considered “fraudulent crypto-currency transactions 204” (see ¶0053). Also, other EIs that are adjusted when incorporating transaction parameters that were previously unspecified (e.g. missing/incomplete or not included yet) were interpreted as considering “reviews in context of the reviewers' trustworthiness” wherein the reviews include the “reviews according to the reviewers' trustworthiness scores” that are “represented as positive numbers” and “a numerical rating from each reviewer may be multiplied by the reviewer's trustworthiness score” (see ¶0086). Other factors considered as unsp