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 .
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
Election/Restrictions
Applicant's election with traverse of Group II (Claim 14-21) in the reply filed on 06/30/2026 is acknowledged. The traversal is on the grounds that the examination of all of the claims is not believed to create an undue burden on the USPTO and that the subject matter among the groups is not independent and distinct as required by statute. This is not found persuasive because the Examiner has established the two criteria for a proper restriction; at least, different keywords in performing the searches would be required for the groups identified by the Examiner. Applicant has not explained how using different, non-overlapping keyword searches does not form a proper basis when the claims have been shown to be directed to separate, non-obvious subject matters where disparate, non-overlapping searches would be required. The Examiner has fulfilled the guidelines for a proper restriction by providing a prima facie position showing the separate status in the art and the different field of search as defined in MPEP 808.02.
The requirement is still deemed proper and is therefore made FINAL.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the "right to exclude" granted by a patent and to prevent possible harassment by multiple assignees. See In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970);and, In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent is shown to be commonly owned with this application. See 37 CFR 1.130(b).
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 14-21 are rejected under the judicially created doctrine of obviousness-type double patenting as being unpatentable over claims 1-8 of US patent No.: 12,141,749 (Application No. 17/952,550) [ hereinafter ‘749 application]. Although the conflicting claims are not identical, they are not patentably distinct from each other (see table below):
“A later patent claim is not patentably distinct from an earlier patent claim if the later claim is obvious over, or anticipated by, the earlier claim. In re Longi, 759 F.2d at 896, 225 USPQ at 651 (affirming a holding of obviousness-type double patenting because the claims at issue were obvious over claims in four prior art patents); In re Berg, 140 F.3d at 1437, 46 USPQ2d at 1233 (Fed. Cir. 1998) (affirming a holding of obviousness-type double patenting where a patent application claim to a genus is anticipated by a patent claim to a species within that genus). “ELI LILLY AND COMPANY v BARR LABORATORIES, INC., United States Court of Appeals for the Federal Circuit, ON PETITION FOR REHEARING EN BANC (DECIDED: May 30, 2001).
18/907,807
17/952,550 (12,141,749)
14. A method, comprising:
maintaining, by a server, a shared blockchain between entities associated with products, wherein the shared blockchain comprises cryptographic cooperatively shared product data structures, each cryptographic cooperatively shared product data structure associated with a particular product of the products, and wherein each cryptographic cooperatively shared product data structure comprises cryptographically linked records that are collectively maintained by the entities;
maintaining, by the server, multiple search keys for returning and updating product information for the products in records on the shared blockchain;
providing, by the server, a front-end interface to the entities for submitting custom searches for the products and for updating the shared blockchain with entity-provided information when the entities handle the products, wherein the front-end interface is configured to enable complete product tracking from origination points of the products through each entity that handled the products to current inventory locations; and
providing, by the server, an application programming interface (API) to entity services to access the front-end interface for submitting the custom searches, performing updates, and receiving search results performed on the shared blockchain, wherein the API is configured to use the common hashing algorithm to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information.
1. A method, comprising:
maintaining, by a server, a shared blockchain between entities associated with products, wherein the shared blockchain comprises cryptographic cooperatively shared product data structures, each cryptographically shared produce data structure associated with a particular product of the products;
maintaining, by the server, multiple search keys for returning and updating product information for the products in records on the shared blockchain;
providing, by the server, a front-end interface to the entities for submitting custom searches for the products and for updating the shared blockchain with entity-provided information when the entities handle the products, wherein the front-end interface is configured to provide a product tracer service for the products through the shared blockchain; and
providing, by the server, an application programming interface (API) to entity services to access the front-end interface for submitting the custom searches, performing updates, and receiving results performed on the shared blockchain, wherein the API is configured to maintain the multiple search keys on the cryptographic cooperatively shared product data structures within the blockchain for searching and updating the product information and the entity-provided information from the entities.
15. The method of claim 14 further comprising, providing, by the server, a common hashing algorithm for use in the API by the entity services to generate the multiple search keys.
2. The method of claim 1 further comprising, providing, by the server, a common hashing algorithm for uses in the API by the entity services to generate the multiple search keys.
16. The method of claim 14 further comprising, providing, by the server, a product tracer and product tracker service for the products through the shared blockchain using the API to obtain corresponding records for the products associated with complete histories of the products.
3. The method of claim 1 further comprising, providing, by the sever, a product tracer and product tracker service for the products through the shared blockchain using the API to obtain corresponding records for the products associated with complete histories of the products.
17. The method of claim 14, wherein providing the front-end interface further includes processing at least one custom search that spans the records associated with multiple different ones of the products on the shared blockchain.
4. The method of claim 1, wherein providing the front-end interface further includes processing at least one custom search that spans the records associated with multiple different ones of the products on the shared blockchain.
18. The method of claim 14, wherein providing the API further includes providing the search results returned from a particular custom search by a particular entity to an inventory service, a promotion service, or a customer service associated with the particular entity.
5. The method of claim 1, wherein providing the API further includes providing the results returned from a particular custom search by a particular entity to an inventory service, a promotion service, or a customer service associated with the particular entity.
19. The method of claim 14, wherein providing the API further includes providing search results returned from a particular custom search by a particular entity through the front-end interface.
6. The method of claim 1, wherein providing the API further includes providing results returned from a particular customer search by a particular entity through the front-end interface.
20. A system, comprising:
a blockchain that comprises cryptographic cooperatively shared product data structures, each cryptographic cooperatively shared product data structure associated with a particular product of products;
a server that comprises a processor, and a non-transitory computer-readable storage medium comprising executable instructions;
the executable instructions when executed by the processor cause the processor to perform operations comprising:
providing a front-end interface to search and update each cryptographic cooperatively shared product data structure on the blockchain with product information for the products and entity-provided information from entities, wherein the front-end interface is configured to enable complete product tracking from origination points of the products through each entity that handled the products to current inventory locations using a common hashing algorithm for generating multiple search keys;
maintaining multiple search keys on the cryptographic cooperatively shared product data structures within the blockchain for searching and updating the product information of the products and the entity-provided information from the entities; and
providing an application programming interface (API) to entity services of the entities to access the front-end interface for submitting custom searches, performing updates, and receiving search results performed on the blockchain, wherein the API is configured to use the common hashing algorithm to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information,
7. A system, comprising:
a blockchain that comprises cryptographic cooperatively shared product data structures, each cryptographic cooperatively shard product data structure associated with a particular product of a plurality of products;
a server that comprises a processor, and a non-transitory computer-readable storage medium comprising executable instructions;
the instructions when executed by the processor cause the processor to perform operations comprising:
providing a front-end interface to search and update the cryptographically shared data structures on the blockchain with product information for the products and entity-provided information from entities, wherein the front-end interface is configured to provide a product tracer service for the products through the shared blockchain using a common hashing algorithm for generating multiple search keys;
maintaining multiple search keys on the cryptographic cooperatively shared product data structures within the blockchain for searching and updating the product information of the products and the entity-provided information from the entities; and
providing an application programming interface (API) to entity services of the entities to access the front-end interface for submitting custom searches, performing updates, and receiving results performed on the blockchain, wherein the API is configured to use the common hashing algorithm to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information.
21. The system of claim 20, wherein the operations further include providing the common hashing algorithm for use in the API by the entity services to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information.
8. The system of claim 7, wherein the operations further include providing a common hashing algorithm for use in the API by the entity services to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information.
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 14-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 1: Statutory Category
The claims fall within a statutory category. Claims 20-21 are considered “machines” based claims and claims 14-21 are considered “processes”. Both machines and processes are members of the statutory categories. Thus, the analysis moves towards step 2A, prong one of the subject matter eligibility test.
Step 2A, Prong One: Judicial Exception
The claims recite abstract ideas in the mathematical concepts grouping. For example, Claim 1 recite:
maintaining, …, a shared blockchain between entities associated with products, wherein the shared blockchain comprises cryptographic cooperatively shared product data structures, each cryptographic cooperatively shared product data structure associated with a particular product of the products, and wherein each cryptographic cooperatively shared product data structure comprises cryptographically linked records that are collectively maintained by the entities;
maintaining, …, multiple search keys for returning and updating product information for the products in records on the shared blockchain;
providing, …, a front-end interface to the entities for submitting custom searches for the products and for updating the shared blockchain with entity-provided information when the entities handle the products, wherein the front-end interface is configured to enable complete product tracking from origination points of the products through each entity that handled the products to current inventory locations; and
providing, …, an application programming interface (API) to entity services to access the front-end interface for submitting the custom searches, performing updates, and receiving search results performed on the shared blockchain, wherein the API is configured to use the common hashing algorithm to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information.
Such processes are akin to a mental process or methods of organizing human activity, which have been recognized as abstract ideas. Thus, the analysis moves towards step 2A, prong two.
Step 2A, Prong Two: Integration into a Practical Application
Claims do not integrate the abstract idea into a practical application. The additional elements, such as a server, a shared blockchain between entities, a front-end interface and an application programming interface (API) are generic computer components and functions and do not impose any meaningful limits of on the abstract idea. Accordingly, the claim does not integrate the recited abstract concepts into a practical application. Thus, the analysis moves towards step 2B.
Step 2B: Inventive concept
Finally, the claims do not recite an inventive concept that transforms the abstract idea into a patent-eligible application. The use of well-understood, routine, and conventional (WURC) implementations of computer, executing the action. In Berkheimer, 224 F.Supp.3d at 647-48 (quoting Content Extraction, 776 F.3d at 1348), claims that “describe "steps that employ only `well-understood, routine, and conventional' computer functions" and are claimed "at a relatively high level of generality.”” were held ineligible.
Dependent claims 15 and 21 describe a common hashing algorithm for use in the API to generate the multiple search keys. This claim further recite the abstract idea of certain methods of mathematical concepts.
Dependent claims 16-19 describe providing search result witch still belong to the abstract idea identified in claim 14 and 20.
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 14-21 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.
Specifically, while the claims 14 and 20 recite “cryptographic cooperatively shared product data structures”, the specification lacks a detailed description of any data structures details as to how this is defined. The specification uses similar language as the claims without further details. As a result, the disclosure does not appear to show possession of the full breadth of the claimed product data structures.
Further, the claims 14 and 20 recite “the common hashing algorithm”, the specification lacks a detailed description of any algorithm details as to how this is accomplished. The specification uses similar language as the claims without further details. As a result, the disclosure does not appear to show possession of the full breadth of the claimed hashing algorithm.
Courts have in the past (see MPEP2161.01) found that generic claim language in the original disclosure does not satisfy the written description requirement if it fails to support the scope of the genus claimed. Ariad, 598 F.3d at 1349-50, 94 USPQ2d at 1171 ("[A]n adequate written description of a claimed genus requires more than a generic statement of an invention’s boundaries.").
Dependent claims 15-19 and 21 are also rejected for inheriting the deficiencies of the independent claims from which they depend on.
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 14-21 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 pre-AIA the applicant regards as the invention.
Regarding claims 14 and 20, Key limitation, "cryptographic cooperatively shared product data structures" is presented purely as functional label with no objective boundaries, leaving readers unable to determine where infringement begins or ends. Every operative verb (identifying, applying and deciding) is recited only by its desired outcome. Because a person having ordinary skill in the art could not ascertain the claim scope with reasonable certainty, the claims are indefinite under 35 U.S.C § 112(b).
Claim 14 is further rejected because “the common hashing algorithm” does not have a previous recitation of “common hashing algorithm”. As a result, lacks proper antecedent basis.
Claim 15 is rejected because it’s unclear if “a common hashing algorithm” is related to the common hashing algorithm claimed in parent claim 14.
Dependent claims 15-19 and 21 are also rejected for inheriting the deficiencies of the independent claims from which they depend on.
Allowable Subject Matter
Claims 14-21 would be allowable if the double patent, 112(a), 112(b) and 101 rejections, set forth in this Office action, are overcome. The following is a statement of reasons for the allowance:
Each independent claims 14 and 20, when compared with the ‘parent application’ 749, are found to be similar in scope than the respective independent claims 1 and 7 of the parent application’ 749. The inventive concept of the instant application is the same as the ‘parent application’ 749. Specifically, the cited prior art on record does not specifically disclose, teach or suggest as a whole the limitation “providing, by the server, a front-end interface to the entities for submitting custom searches for the products and for updating the shared blockchain with entity-provided information when the entities handle the products, wherein the front-end interface is configured to enable complete product tracking from origination points of the products through each entity that handled the products to current inventory locations; and providing, by the server, an application programming interface (API) to entity services to access the front-end interface for submitting the custom searches, performing updates, and receiving search results performed on the shared blockchain, wherein the API is configured to use the common hashing algorithm to generate the multiple search keys using portions of the product information for the products or portions of the entity-provided information” including all the other limitation recited in the independent claims.
The limitations of the independent claims were searched, but did not result in any applicable prior art. After further consideration, each of the independent claims as a whole are allowable.
Dependent claims 15-19 and 21 are also allowable for incorporating the allowable feature recited in the independent claims.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Baar et al. US 10423947 B1 - generating and displaying a user interface prompting a user to input: an identifier of a primary payment source account for applying resources to transactions originating at one or more merchants, the primary payment source account being accounted for in a first data structure of a shared ledger and having its identifier linked with one or more supplemental payment source accounts; identifiers of one or more supplemental payment source accounts for applying resources to transactions originating at one or more merchants, the supplemental payment source accounts being accounted for in second and subsequent data structures of the shared ledger
Smith et al. US 2017/0317997 - including receiving the information and a public key generated for the information; applying a hash function to the information to create a hash; combining the hash of the information with the public key generated for the information to generate a public attest key
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MENG LI whose telephone number is (571)272-8729. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached on (571) 270-5143. 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.
/MENG LI/
Primary Examiner, Art Unit 2437
Prosecution Insights