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 .
Information Disclosure Statement
The information disclosure statement (IDS) submitted on November 28, 2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Drawings
The drawings submitted on November 28, 2023 are acceptable.
Response to Amendment
The amendment filed on February 03, 2026 has been entered. Applicant has amended claims 1-2. Claims 11-20 have been withdrawn. Claims 1-20 are now pending, claims 1-10 have been examined and currently stand rejected.
Claim Interpretation
Non-Functional Language:
Regarding claim 5: The portion which recites “wherein a verification result value of the verification field is based on a comparison of a maintenance history of the used vehicle stored in at least one external terminal associated with the blockchain network and the maintenance history of the used vehicle stored in the electronic wallet linked to the first terminal.” is non-functional descriptive material describing the verification result.
Regarding claim 6: The portion which recites “wherein the verification result value is configured to be received from the at least one external terminal.” is non-functional descriptive material describing the verification result.
It has been held that non-functional descriptive material will not distinguish the invention from the prior art in terms of patentability.
Examiner has provided prior art, where available, for these intended use and/or non-functional phrases/limitations, however, these phrases/limitations will not distinguish the invention from the prior art in terms of patentability. Accordingly, the prior art is only provided in the interest of compact prosecution.
Intended use/result Language:
Regarding claim 1: The portion which recites “to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with the blockchain network,” is intended use language. This phrase do not affect how the positively recited steps are performed.
The applicant is reminded that these portions, i.e., intended use/result, do not further limit the scope of the claim as the limitations, or portions thereof, do not claim the functions as being positively recited actions or functions, and/or they do not add any meaning or purpose to the associated manipulative step(s). See MPEP 2103 C and 2111.04. Simply because the limitation recites something as being "for ... [performing a specific functionality]", etc. does not mean that the functions are required to be performed, or are actually performed.
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-10 are rejected under 35 U.S.C. 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea) and does not provide an integration of the recited abstract idea into a practical application nor include an inventive concept that is “significantly more” than the recited abstract idea to which the claim is directed. MPEP §2106.
In determining subject matter eligibility in an Alice rejection under 35 U.S.C. §101, it is first determined as Step 1 whether the claims are directed to one of the four statutory categories of an invention (i.e., a process, a machine, a manufacture, or a composition of matter). MPEP §2106.03.
Here, the claims are directed to the statutory category of a machine (Claims 1-10). Therefore, we proceed to Step 2A, Prong 1. MPEP §2106.
Under a Step 2A, Prong 1 analysis, it must be determined whether the claims recite an abstract idea that falls within one or more enumerated categories of patent ineligible subject matter that amounts to a judicial exception to patentability. MPEP §2106.04. Independent Claim 1 is selected as being representative of the independent claims in the instant application. Claim 1 recites:
A first terminal for issuing a non-fungible token (NFT) recording a maintenance history of a used vehicle, the first terminal comprising:
a communication interface a user interface;
one or more processors; and
a non-transitory storage medium storing instructions that, when executed by the one or more processors, cause the first terminal to:
receive, via the user interface, a maintenance history of a used vehicle, and
generate, based on the parsed data, an issuance request of a non- fungible token (NFT), recording the maintenance history of the used vehicle, wherein the issuance request being generated by the first terminal comprising information to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with the blockchain network,
cause an issuance of an NFT associated with the maintenance history of the used vehicle by transmitting, to the blockchain network via the communication interface, the issuance request,
receive an issued NFT associated with the maintenance history of the used vehicle,
and
store the issued NFT in an electronic wallet linked to the first terminal,
wherein the maintenance history of the used vehicle comprises at least one maintenance record of the used vehicle and further comprises at least one of: an accident history of the used vehicle, mileage information of the used vehicle, or an owner change history of the used vehicle.
Here, the claims recite an abstract idea, or combination of abstract ideas of receiving and cleaning data and storing and transmitting the data of a maintenance history of a used vehicle with the intent to issue tokens. This concept/abstract idea, which is identified in the bolded sections seen above, falls within the Certain Methods of Organizing Human Activity grouping because it describes a commercial or legal interactions (e.g., data exchange for transactions).
Accordingly, it is determined that the claims recite an abstract idea since they fall within one or more of the three enumerated categories of patent ineligible subject matter. MPEP §2106.04.
Since it is determined that the claim(s) contain a judicial exception, it must then be determined, under Step 2A, Prong 2, whether the judicial exception is integrated into a practical application of the exception. MPEP §2106.04. In order to make this determination, the additional element(s) are analyzed to determine if the claim as a whole integrates the recited judicial exception into a practical application of that exception. Here claim 1 recite the additional elements of a first terminal, a communication interface, one or more processors, a storage medium a blockchain network and NFTs. The additional elements a first terminal, a communication interface, one or more processors and a storage medium are all recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception, or a portion thereof, using a generic computer component. See MPEP 2106.05(f). Furthermore, the additional elements: the blockchain network and NFTs amount to generally linking the use of the judicial exception to a particular technological environment or field of use. Additionally, Examiner finds no indication in the Specification, that the operations recited in the independent claims require any specialized computer hardware or other inventive computer components, i.e., a particular machine, invoke any allegedly inventive programming, or that the claimed invention is implemented using other than generic computer components to perform generic computer functions. Furthermore, there is no indication in the claim(s) that the use of a first terminal, a communication interface, one or more processors and a storage medium, the blockchain network and NFTs in combination with the abstract idea leads to an improvement of the processor, memory, another technology, or to a technical field. Accordingly, the 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. Looking at the elements as a combination does not add anything more than the elements analyzed individually. Examiner further notes that even though the claims may not preempt all forms of the abstraction, this alone, does not make them any less abstract.
When analyzed under step 2B, the claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional element of using a generic computing component (e.g., a first terminal, a communication interface, one or more processors and a storage medium, the blockchain network and NFTs) to implement the abstract idea amounts to no more than mere instructions to apply the exception using a generic computer component. Mere instructions to apply an exception using a generic computer component cannot provide an inventive concept or significantly more than the judicial exception. Considered as an ordered combination, the additional elements recited in the claim(s) add nothing that is not already present when the steps are considered separately.
Therefore, claim 1 is rejected under 35 U.S.C. §101 and are not patent eligible. Dependent claims 2-10 when analyzed are held to be patent ineligible under 35 U.S.C. §101 because the additional recited limitation(s) fail to establish that the claim(s) is/are not directed to an abstract idea.
Dependent claim 2 further refine the abstract idea by indicating that issued NFT is associated with an issuance history of the issued NFT stored in
the blockchain network. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 3-4 further refine the abstract idea by indicating that the maintenance history of the vehicle is stored. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 5-6 further refine the abstract idea by indicating that verification result value of the verification field is based on a comparison and the maintenance history of the used vehicle stored. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claim 7 further refine the abstract idea by describing a transaction of the token =. This claim fails to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
Dependent claims 8-10 further refine the abstract idea by indicating that the transaction and the issuance are based on ERC 721 contract protocol. These claims fail to include any new additional elements that integrate the abstract idea into a practical application or provide significantly more than the abstract idea.
In summary, the dependent claims considered both individually and as an ordered combination do not provide meaningful limitations to transform the abstract idea into a patent eligible application of the abstract idea such that the claims amount to significantly more than the abstract ideas itself. The claims do not recite an improvement to another technology or technical field, an improvement to the functioning of the computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. Therefore, the dependent claims are also not patent eligible.
Accordingly, it is determined that all claims are directed to non-statutory subject matter under 35 U.S.C. 101 and are ineligible.
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.
Claims 1-5 and 7-10 are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed et al. (US 2024/0185180 A1), hereinafter “Mohammed” in view of Blevins (US 2022/0027992 A1) hereinafter “Blevins”, in view of “Richter” (US 11,863,676 B1).
Regarding claim 1: Mohammed disclose: A first terminal comprising:
a communication interface; (See at least Mohammed, Fig 1; Communication Module)
a user interface; (See at least Mohammed, Fig 1; [0045] Display Device Display device 124 may
be combined with processor(s), and/or user input device 120)
one or more processors; and (See at least Mohammed, Fig 1; Processor)
a storage medium (See at least Mohammed, Fig 1; Processor) storing instructions that, when executed by the one or more processors, cause the first terminal to:
receive, via the user interface, a maintenance history of a used vehicle, and (See at least Mohammed, Fig. 3; [0064-0065]; where a maintenance history of a used vehicle (i.e., the identifying information of the vehicle and identifying information of the owner(s)) is received via the user interface (i.e., via a user input device and a graphical user interface (GUI).)
recording the maintenance history of the used vehicle; (See at least Mohammed, [0038] Vehicle management system 102 may include a blockchain 108, which may be used by vehicle management system 102 as a distributed ledger to store ownership data of vehicle 130; The smart contracts may be stored in NFTs on the blockchain, where the NFTs may be associated with at least one of the vehicle.)
wherein the maintenance history of the used vehicle comprises at least one maintenance record of the used vehicle and further comprises at least one of: an accident history of the used vehicle, mileage information of the used vehicle, or an owner change history of the used vehicle. (See at least Mohammed, [0048]; [0055]; [0123] where maintenance history of the used vehicle comprises at least an owner change history of the used vehicle (i.e., vehicle owner(s) field 222, which may store identifying information of one or more owners of the vehicle.).
Mohammed disclose update NFT on blockchain in response to a request (See Mohammed, [0068]; [0070] The NFT-VID and the NFT-DIDs may be written to blockchain 108 and updated as new blocks are added to blockchain 108; 312, method 300 includes updating the NFTVID of the vehicle and the NFT-DID of the respective owner on the blockchain.)
However, Mohammed does not explicitly disclose parse data of the maintenance history of the used vehicle, generate, based on the parsed data, an issuance request of a non- fungible token (NFT), wherein the issuance request being generated by the first terminal comprising information to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with the blockchain network, cause an issuance of an NFT associated with the maintenance history of the used vehicle by transmitting, to the blockchain network via the communication interface, the issuance request, receive an issued NFT associated with the maintenance history of the used vehicle, and store the issued NFT in an electronic wallet linked to the first terminal.
Blevins, on the other hand, teaches disclose wherein the issuance request being generated by the first terminal comprising information to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with the blockchain network, cause an issuance of an NFT associated with the maintenance history of the used vehicle by transmitting, to the blockchain network via the communication interface, the issuance request, receive an issued NFT associated with the maintenance history of the used vehicle, and store the issued NFT in an electronic wallet linked to the first terminal. (See at least Blevins, Fig. 3; [0036]; [0052]; [0058]; [0061]; [0066]; [0079]; [0083-0085]; wherein the issuance request (i.e., request) being generated by the first terminal comprising information (e.g., application server) to cause an NFT-based contract device (i.e., smart contract on a blockchain) to perform an issuance operation of an NFT-based contract associated with the blockchain network, cause an issuance of an NFT associated with the maintenance history of the used vehicle (i.e., generation of the tree token) by transmitting, to the blockchain network via the communication interface, the issuance request (i.e., Transaction, Tx 1 in block 11) corresponding to generation of a tree token 171, or record of a tree for generation of a tree token 171, may be stored within the blockchain) receive an issued NFT associated with the maintenance history of the used vehicle (i.e., new entry (e.g., tree token)) and store the issued NFT in an electronic wallet linked to the first terminal (e.g., by the application server 120, for input to the smart contract 145 by which a NFT, like a tree token, may be generated. In either instance, a record of the generation of the NFT may be stored within the data store, and may include information like a token identifier and an account to which the token was transferred ( e.g., to a tree owner, such as initially, or other account of a user such as when an account user trades for the token ( e.g., adoption, purchase, or otherwise).
It would have been obvious to one of ordinary still in the art to include in the system of Mohammed the ability to transmit issuance request to a blockchain taught by Blevins since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
The combination of Mohammed and Blevins does not explicitly disclose; however, Richter teaches parse data of the maintenance history of the used vehicle and generate, based on the parsed data, an issuance request of a non- fungible token (NFT) (See at least Richter, Col. 2 lines 20-23; Col. 16 lines 28-37; where parse (i.e., parse) data of the maintenance history of the used vehicle (i.e., user-specific data) and generate, based on the parsed data, an issuance request of a non- fungible token (NFT) (i.e., generating NFTs from user-specific products and data).)
Therefore, 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 above combination and include Richter teachings in order to ensure data integrity and authenticity.
Regarding claim 2: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 1. The combination further disclose:
wherein the issued NFT is associated with an issuance history of the issued NFT stored in the blockchain network, and (See at least Mohammed, [0048] The modifiable data fields of NFT-VID 200 may include a vehicle owner(s) field 222, which may store identifying information of one or more owners of the vehicle. The identifying information may include one or more owner IDs 224 ( e.g., an owner ID 224 for each vehicle owner). For example, a first owner ID 224 of a previous owner or seller of the vehicle may be included, and a second owner ID 224 of a current owner or buyer of the vehicle may
be included.)
wherein the issuance history of the issued NFT comprises:
a token identifier (ID) of the issued NFT; (See at least Mohammed, [0038] In various embodiments, blockchain 108 may store one or more non-fungible tokens (NFTs) associated with and identifying vehicle 130, referred to herein as NFT-VIDs.)
Mohammed does not explicitly disclose; however, Blevins teaches;
wherein the issuance history of the issued NFT comprises: a hash value associated with the maintenance history of the used vehicle; (See at least Blevins, [0036])
a verification field for the maintenance history of the used vehicle; and (See at least Blevins, [0027]; [0036]; Embodiments may interrogate these records to verify authenticity, e.g., by recreating the calculation of the cryptographic hash values along each link in a chain of cryptographic hash pointers and comparing the recalculated values to the values in the chain to confirm (by virtue of matches) that the records are authentic (e.g., to verify current ownership of a tree token by a given user account, information about the tree to which the tree token corresponds, or other information pertaining to the tree token or tree).)
a value indicating a quantity of tokens corresponding to a transaction price of the issued NFT, (See at least Blevins, [0054]; The tokenization service may allow a tree owner to set one or more attributes of the tree token, such as a price of a tree token.)
wherein the hash value indicates an address of a storage where the maintenance history of the used vehicle is to be stored. (See at least Blevins, [0117-0119] A further embodiment comprising: verifying the record of the tree has not been tampered with subsequent to their recording in the data store by verifying that the record of the tree is consistent with a set of cryptographic hash values based on the record of the tree, at least some of the cryptographic hash values also being based on other records. further embodiment comprising: verifying records of transfer of the unique token from generation to a last recorded transfer to a digital wallet have not been tampered with subsequent to recording in the data store by verifying that each record is consistent with a set of cryptographic hash values based on the record, at least some of the cryptographic hash values also being based on other records. A further embodiment wherein: a record of the second transaction indicative of the generation of the unique token comprises a reference to a location of the record of the tree within the data store to which the unique token corresponds.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mohammed and include Blevins teachings in order to afford a tamper-evident storage scheme. Blevins [0029].
Regarding claim 3: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 2. The combination further disclose: wherein the instructions, when executed by the one or more processors, cause the first terminal to store, based on the hash value, the maintenance history of the used vehicle in the storage. (See at least Blevins, [0066] In some cases, a new entry ( e.g., a new transaction record, which may correspond to the establishment of a tree record, generation of a tree token, transfer of a tree token to a user account, or other function described herein) created by the smart contract may include this cryptographic hash value and pointers to those other nodes.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mohammed and include Blevins teachings in order to afford a tamper-evident storage scheme. Blevins [0029].
Regarding claim 4: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 2. The combination further disclose: wherein the instructions, when executed by the one or more processors, cause the first terminal to store the maintenance history of the used vehicle in the electronic wallet linked to the first terminal. (See at least Blevins, [0025]; [0037]; In such examples, a user's digital wallet may store an indication of a tree token and a corresponding stake in the token; Tree tokens may be held in a digital wallet of a user, which may be viewed on a user's device or otherwise
accessed ( e.g., via a website).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mohammed and include Blevins’ teachings in order to provide user accessibility, security and verifiability.
Regarding claim 5: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 4. The combination further disclose: wherein a verification result value of the verification field is based on a comparison of a maintenance history of the used vehicle stored in at least one external terminal associated with the blockchain network and the maintenance history of the used vehicle stored in the electronic wallet linked to the first terminal. (See at least Blevins, [0070]; Information stored outside of the data store (and within) may be verified as having been untampered with based on matching of cryptographic hashes. For example, a cryptographic hash of properties of a tree may be associated with a tree token. The properties of the tree may be stored within a record within or external to the data store. A tree (e.g., uniquely represented by the properties) may be verified as corresponding to the tree token recalculating a cryptographic hash value based on the asserted properties and verification of a match with the cryptographic hash associated with the tree token ( e.g., which may have been computed in association with the generation of the tree token).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mohammed and include Blevins teachings in order to afford a tamper-evident storage scheme. Blevins [0029].
Regarding claim 7: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 2. The combination further disclose: wherein the instructions, when executed by the one or more processors, cause the first terminal to perform a token transaction operation associated with the NFT-based contract, (See at least Blevins, [0061] transaction) wherein the token transaction operation associated with the NFT-based contract is configured to cause:
withdrawal of tokens, corresponding to the quantity of tokens, from an electronic wallet linked to a second terminal associated with a purchaser of the used vehicle; (See at least Blevins, [0061]; Users may buy or sell tree tokens using fiat currency, or digital currency such as cryptocurrency. After the purchase is completed successfully, the online marketplace may call a smart contact to execute the transfer the tree token to the digital wallet of the user based on a verification of information associated with the request transaction (e.g., donation meets criteria, validation of token ownership by the tree owner, etc.).
transfer of the withdrawn tokens to the electronic wallet linked to the first terminal; (See at least Blevins, [0061]; Users may buy or sell tree tokens using fiat currency, or digital currency such as cryptocurrency. After the purchase is completed successfully, the online marketplace may call a smart contact to execute the transfer the tree token to the digital wallet of the user based on a verification of information associated with the request transaction (e.g., donation meets criteria, validation of token ownership by the tree owner, etc.).
withdrawal of the issued NFT stored in the electronic wallet linked to the first terminal; and (See at least Blevins, [0056]; For example, a buyer may select one or more tree tokens from the online marketplace to purchase and request the tree tokens be delivered to their digital wallet.)
transfer of the withdrawn NFT to the electronic wallet linked to the second terminal. (See at least Blevins, [0056]; For example, a buyer may select one or more tree tokens from the online marketplace to purchase and request the tree tokens be delivered to their digital wallet.)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Mohammed and include Blevins’ teachings in order to provide user accessibility, security and verifiability.
Regarding claim 8: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 7. The combination further disclose: wherein the token transaction operation is at least partially based on an Ethereum Request for Comments (ERC) 721 contract protocol, and wherein authorization for the withdrawal of the tokens is configured to be granted based at least partially on the ERC 721 contract protocol and an approval operation of an ERC 20 contract protocol. (See at least Blevins, [0020]; [0037]; In some cases, those transactions may use (e.g., all or some of) the ERC 721 standard; In some embodiments, a tree token may be an ERC-721-standard compliant token, said standard being hereby incorporated by reference; In some embodiments, computation of carbon credit and transaction data associated with the trading of carbon credits may be stored in the blockchain-based data repository. In some cases, fungible carbon-credit tokens ( e.g., ERC-20 standard-compliant tokens)
It would have been obvious to one of ordinary still in the art to include in the system of Mohammed the description of the protocols used as taught by Blevins since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 9: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 8. The combination further disclose: wherein the approval operation is associated with an address of the ERC 721 contract protocol entered in a spender corresponding to a subject to withdraw at least one token. (See at least Blevins, [0020]; [0037]; In some cases, those transactions may use (e.g., all or some of) the ERC 721 standard; In some embodiments, a tree token may be an ERC-721-standard compliant token, said standard being hereby incorporated by reference; In some embodiments, computation of carbon credit and transaction data associated with the trading of carbon credits may be stored in the blockchain-based data repository. In some cases, fungible carbon-credit tokens ( e.g., ERC-20 standard-compliant tokens.)
It would have been obvious to one of ordinary still in the art to include in the system of Mohammed the description of the protocols used as taught by Blevins since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Regarding claim 10: The combination of Mohammed, Blevins and Richter disclose the terminal of claim 14. The combination further disclose: wherein the NFT is an NFT to be issued according to an Ethereum Request for Comments (ERC) 721 contract protocol associated with the NFT-based contract, and the issuance operation is associated with a Mint function according to the ERC 721 contract protocol. (See at least Blevins, [0083]; generate a tree token, which may establish an instance of a new, unique token (e.g., like an ERC-721 token)
It would have been obvious to one of ordinary still in the art to include in the system of Mohammed the description of the protocols used as taught by Blevins since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable.
Claim(s) 6 is/are rejected under 35 U.S.C. 103 as being unpatentable over Mohammed, Blevins and Richter as applied to claim 5 above, and further in view of Alvarez et al. (US 7735125 B1), “Alvarez"
Regarding claim 6: The combination of Mohammed, Blevins and Richter disclose the first terminal of claim 5. However, the combination do not explicitly disclose wherein the verification result value is configured to be received from the at least one external terminal.
Alvarez, on the other hand, teaches that it was known in the art before the effective filling date of the claimed invention to receive verification result from an external terminal (e.g., wherein the verification result value is configured to be received from the at least one external terminal.) (See at least Alvarez, Col. 7 lines 66-67; Col. 8 lines 1-6; In step 350, the kiosk 100 verifies the identity of the user. In one example, the verification of the identity of the user of the kiosk 100 is based on the comparison of the customer input data with the customer record which was received from the external verification system 220. In a further embodiment, the verification of the identity of the user is based upon the verification result which was received from the external verification system 220. FIG. 3 ends in step 360).
Therefore, 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 above combination that already discloses verification of information from stored outside of the data store and include Alvarez teachings that receives the information/data from an external device in order to improve data security.
Response to Arguments
Claim Interpretation
Examiner appreciates Applicant’s efforts in amending the claims to solve the claims interpretation. However, the claim still recite portions that will not distinguish the invention from the prior art in terms of patentability (i.e., non-functional and intended-use language).
Rejections Under 35 U.S.C § 101
Based on Applicant amendments, the rejection of claim 1 under 35 U.S.C § 101 for being directed to signal per se is withdrawn.
Applicant's arguments filed February 3, 2026 regarding rejections under 35 U.S.C § 101 because the claimed invention recites and is directed to a judicial exception to patentability (i.e., an abstract idea)have been fully considered but they are not persuasive. Applicant asserts that the claims are not directed to an abstract idea (Remarks, p. 1). Examiner respectfully disagrees. The claims are directed to the abstract idea of receiving and cleaning data and storing and transmitting the data of a maintenance history of a used vehicle with the intent to issue tokens.
Applicant asserts that the claims implement any such abstract idea into a practical application in a manner that imposes a meaningful limit on the abstract idea and are thereby directed to patent-eligible subject matter in compliance with 35 U.S.C. § 101 (Remarks, pp. 10-11). Examiner respectfully disagrees. In order to determine whether the abstract idea is integrated into a practical application the additional element(s) are analyzed. The additional elements (i.e., a first terminal, a communication interface, one or more processors and a storage medium) are all recited at a high-level of generality such that they amount to no more than mere instructions to apply the exception, or a portion thereof, using a generic computer component. Furthermore, the additional elements: the blockchain network and NFTs amount to generally linking the use of the judicial exception to a particular technological environment or field of use.
Rejections Under 35 U.S.C § 103
Applicant's arguments filed February 3, 2026 regarding rejections under 35 U.S.C § 103 have been fully considered but they are not persuasive. Applicant asserts that none of the cited references, either alone or in combination, teach or suggest at least "parse data of the maintenance history of the used vehicle, generate, based on the parsed data, an issuance request of a non-fungible token (NF'T), recording the maintenance history of the used vehicle, wherein the issuance request being generated by the first terminal comprising information to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with a blockchain network, ... wherein the maintenance history of the used vehicle comprises at least one maintenance record of the used vehicle and further comprises at least one of: an accident history of the used vehicle, mileage information of the used vehicle, or an owner change history of the used vehicle," as recited in present claim 1. (Remarks, pp. 11-13). Regarding the newly introduced language i.e., “parse data of the maintenance history of the used vehicle, generate, based on the parsed data, an issuance request of a non-fungible token (NF'T)”, examiner agrees. However, upon further consideration, a new ground(s) of rejection is made in view of Mohammed, Blevins and Richter Examiner notes this feature is disclosed by “Richter”. Examiner respectfully disagrees that the cited references fail to disclose “recording the maintenance history of the used vehicle... wherein the maintenance history of the used vehicle comprises at least one maintenance record of the used vehicle and further comprises at least one of: an accident history of the used vehicle, mileage information of the used vehicle, or an owner change history of the used vehicle”. (See at least, Mohammed, [0038]; [0048]; [0055]; [0123]). Examiner disagrees that the cited references fail to disclose; wherein the issuance request being generated by the first terminal comprising information to cause an NFT-based contract device to perform an issuance operation of an NFT-based contract associated with a blockchain network. (See at least Blevins, Fig. 3; [0036]; [0052]; [0058]; [0061]; [0066]; [0079]; [0083-0085]; wherein the issuance request (i.e., request) being generated by the first terminal comprising information (e.g., application server) to cause an NFT-based contract device (i.e., smart contract on a blockchain) to perform an issuance operation of an NFT-based contract associated with the blockchain network).
Applicant asserts that “even if combined, the cited references, the modified Mohammed system would have been limited to the ownership updates, and the Blevins teaching is directed to NFT mechanisms for trees.” Examiner respectfully disagrees. Blevins describes the use of tokens (e.g., NFTs) to manage data and ownership of a physical asset (i.e., trees). Therefore, managing tree ownership data with NFTs is analogous to managing vehicle ownership data with NFTs .
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARLYANNIE M GARCIA whose telephone number is (571)272-6950. The examiner can normally be reached Monday - Friday 7:30am - 4: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, Patrick McAtee can be reached at (571) 272-7575. 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.
/K.G.M/Examiner, Art Unit 3698
/EDUARDO CASTILHO/Primary Examiner, Art Unit 3698
Prosecution Insights