Prosecution Insights
Last updated: April 19, 2026
Application No. 18/675,817

BLOCKCHAIN-BASED USER IDENTIFICATION METHOD AND ELECTRONIC DEVICE FOR PERFORMING THE SAME

Final Rejection §101§103§112
Filed
May 28, 2024
Examiner
WEISBERGER, RICHARD C
Art Unit
3693
Tech Center
3600 — Transportation & Electronic Commerce
Assignee
42dot Inc.
OA Round
2 (Final)
48%
Grant Probability
Moderate
3-4
OA Rounds
4y 8m
To Grant
44%
With Interview

Examiner Intelligence

Grants 48% of resolved cases
48%
Career Allow Rate
173 granted / 359 resolved
-3.8% vs TC avg
Minimal -4% lift
Without
With
+-4.1%
Interview Lift
resolved cases with interview
Typical timeline
4y 8m
Avg Prosecution
32 currently pending
Career history
391
Total Applications
across all art units

Statute-Specific Performance

§101
35.2%
-4.8% vs TC avg
§103
19.7%
-20.3% vs TC avg
§102
5.4%
-34.6% vs TC avg
§112
28.0%
-12.0% vs TC avg
Black line = Tech Center average estimate • Based on career data from 359 resolved cases

Office Action

§101 §103 §112
DETAILED ACTION Claim Interpretation The applicant being his own lexicographer limits the claims according to the following bolded limitations. While no express definitions are provided and the examiner relies upon the following portions of the specification to render meanings to the terms. “The CID may include vehicle information, driver information, vehicle owner information, and/or CID type information.” “The CID 111 may be segmented into blockchain-based decentralized identifiers (DIDs) (e.g., DIDs 121 and 122) respectively corresponding to vehicle usage scenarios of the driver 102.” “A verifiable credential (VC) may be used to authenticate an identity or prove a specific credential. The VC may be issued by the issuer 200. The VC may correspond to a credential of a driver (e.g., the driver 102), and the credential may be, for example, an owned credential which is a credential owned by the driver and a delegated credential which is a credential delegated to the driver and may include, for example, a vehicle operation credential and/or a vehicle feature on demand (FOD) service usage credential. The VC may include a credential ID, an issuer ID (e.g., an ID of the issuer 200), a holder ID (e.g., an ID of the driver 102), claims (e.g., credential data), and a signature of an issuer (e.g., the issuer 200). The claims (e.g., credential data) may include information about credentials of a driver (e.g., the driver 102), for example, an owned credential, a sharing credential, driver's license information, membership information, a vehicle operation contract, and the like. The VC may be mapped to a DID corresponding to a vehicle usage scenario of a driver (e.g., the driver 102), as indicated in 131 and 132, for example.” “A verifiable presentation (VP) (e.g., VPs 141 and 142) may be used to verify a specific credential or information by submitting a portion or entirety of a VC to a verifier 500. The VPs 141 and 142 may be used to verify (e.g., authenticate and/or authorize) a vehicle-related service the driver 102 desires to receive. The VPs 141 and 142 may selectively include only information required to use the vehicle-related service. For example, the VP 141 may be a combination of one DID (e.g., the DID 121) and at least one VC. The VPs 141 and 142 may include a VC and a signature of a holder (e.g., the driver 102). The VPs 141 and 142 may correspond to vehicle usage scenarios of the driver 102. For example, the VP 141 may correspond to a first vehicle usage scenario of the driver 102. For example, the VP 142 may correspond to a second vehicle usage scenario of the driver 102.” “A service provider 400 (e.g., a provider of a vehicle-related service) may perform driver identification and/or vehicle-related service verification (e.g., authentication and/or authorization) using the VPs 141 and 142. The service provider 400 (e.g., a provider of a vehicle-related service) may include a vehicle manufacturer, a vehicle FOD service provider, a vehicle rental company, a fleet management company, and the like.” 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 19-28 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. In claim 19 “requesting an external device to issue a decentralized identifier (DID) corresponding to a current vehicle usage scenario of the driver, wherein the DID corresponds to a CID representing a combination of the vehicle and the driver, and the CID is generated based on a relationship type between the vehicle and the driver” is not described in the specification. Fig. 3. shows examples of CID types of "main", "delegated driver", "rented car", and "delegated car" which appears to describe the driver-vehicle or vehicle-driver relationship. What is unclear is how a CID potentially only comprised of a single type of information (i.e. at least one of vehicle information, driver information, vehicle owner information, or CID type information) may be segmented into DIDs corresponding to vehicle usage scenarios of the driver. In claim 19, “providing the service to the driver by activating a function of the vehicle corresponding to the service when verification of the VP is successful” is not described in the specification. Moreover, it is not described in response to transmitting the VP to the service provider. Claim Rejections - 35 USC § 101 Claims 19-28 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) a blockchain-based user/approved vehicle identification method: This judicial exception is not integrated into a practical application for the reasons as follows. The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception for the reasons that follow. Eligibility Analysis, Step 1 The claims are each directed to a system and method, each categories of invention. As such, the analysis proceeds to Step 2. The 2019 Patent Subject Matter Eligibility Guidance (“2019 PEG”) sets forth a revised Step 2A analysis which includes a two-prong inquiry. Eligibility Analysis, Step 2A Prong One Prong one consists of determining if the claims recite a judicial exception, which includes abstract ideas, laws of nature, and natural phenomenon. Groupings of abstract ideas may include mathematical concepts, mental processes, and certain methods of organizing human activity. Here, representative independent claim 19 recites limitations relating to a blockchain-based user identification method: requesting an external device to issue a decentralized identifier (DID) corresponding to a current vehicle usage scenario of the driver, wherein the DID corresponds to a CID representing a combination of the vehicle and the driver, and the CID is generated based on a relationship type between the vehicle and the driver; receiving the DID from the external device, wherein the DID is stored via a blockchain; receiving, from the external device, verifiable credentials (VCs) respectively corresponding to permissions required for the current vehicle usage scenario corresponding to the DID, wherein the VCs are stored via the blockchain; generating a verifiable presentation (VP) based on a combination of at least some of the VCs; transmitting the VP to a device of a service provider; and providing the service to the driver by activating a function of the vehicle corresponding to the service when verification of the VP is successful. The bolded steps above describe a commercial interaction and managing interactions between people, and therefore a certain method of organizing human activity. Further, the limitations, as drafted, describe a process that, under its broadest reasonable interpretation, covers performance of the limitation by a human analog but for the recitation of generic computer components. That is, other than the recitation of the blockchain, external device and vehicle nothing in the claims precludes the steps from practically being performed by a human analog. Here, the mere nominal recitation of the blockchain and devices/car does not take the claim limitation out of the “certain methods of organizing human activity” grouping. As such, the claims recite an abstract idea under prong one. The analysis proceeds to Step 2A Prong Two. Eligibility Analysis, Step 2A Prong Two Determining whether the claim recites additional elements that integrate the judicial exception into a practical application via the following additional elements: stored in a blockchain. The blockchain is recited at a high level of generality, i.e., as a generic blockchain programmed for sending, receiving, and processing data. This generic blockchain limitation is no more than mere instructions to apply the exception using a generic computer component. an external device a service provider device The additional elements in the claims amount to no more than mere instructions to apply the exception using generic computer components. They do not integrate the judicial exception into a practical application because they do not impose any meaningful limits on practicing the abstract idea. As such, the claims are directed to the abstract idea. The applicant’s arguments regarding “physical control of the vehicle” is not persuasive as it is not commensurate with the scope of the claims. "...providing the service to the driver by activating a function of the vehicle corresponding to the service when verification of the VP is successful." The analysis proceeds to Step 2B. Eligibility Analysis, Step 2B Step 2B consists of determining whether the claim provides an inventive concept by considering whether the additional elements go beyond what is well-understood, routine, and conventional activity. The courts have recognized the following computer functions as well‐understood, routine, and conventional functions when they are claimed in a merely generic manner (e.g., at a high level of generality) or as insignificant extra-solution activity (see MPEP 2106; see also USPTO: July 2015 Update: Subject Matter Eligibility): i. Receiving or transmitting data over a network, e.g., using the Internet to gather data, Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362 (utilizing an intermediary computer to forward information); TLI Communications LLC v. AV Auto. LLC, 823 F.3d 607, 610, 118 USPQ2d 1744, 1745 (Fed. Cir. 2016) (using a telephone for image transmission); OIP Techs., Inc., v. Amazon.com, Inc., 788 F.3d 1359, 1363, 115 USPQ2d 1090, 1093 (Fed. Cir. 2015) (sending messages over a network); buySAFE, Inc. v. Google, Inc., 765 F.3d 1350, 1355, 112 USPQ2d 1093, 1096 (Fed. Cir. 2014) (computer receives and sends information over a network); but see DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258, 113 USPQ2d 1097, 1106 (Fed. Cir. 2014) (“Unlike the claims in Ultramercial, the claims at issue here specify how interactions with the Internet are manipulated to yield a desired result‐‐a result that overrides the routine and conventional sequence of events ordinarily triggered by the click of a hyperlink.” (emphasis added)); ii. Performing repetitive calculations, Flook, 437 U.S. at 594, 198 USPQ2d at 199 (recomputing or readjusting alarm limit values); Bancorp Services v. Sun Life, 687 F.3d 1266, 1278, 103 USPQ2d 1425, 1433 (Fed. Cir. 2012) (“The computer required by some of Bancorp’s claims is employed only for its most basic function, the performance of repetitive calculations, and as such does not impose meaningful limits on the scope of those claims.”); iii. Electronic recordkeeping, Alice Corp., 134 S. Ct. at 2359, 110 USPQ2d at 1984 (creating and maintaining “shadow accounts”); Ultramercial, 772 F.3d at 716, 112 USPQ2d at 1755 (updating an activity log); iv. Storing and retrieving information in memory, Versata Dev. Group, Inc. v. SAP Am., Inc., 793 F.3d 1306, 1334, 115 USPQ2d 1681, 1701 (Fed. Cir. 2015); OIP Techs., 788 F.3d at 1363, 115 USPQ2d at 1092-93; In the case of the instant claims, the generic application of the devices and blockchain does not make the invention patent-eligible. Note that the disclosure recites a generic blockchain which are suitable to perform the claimed method. Moreover, the specification does not contribute any technically-specific computer algorithm or code, but rather merely states that the claimed steps may be performed by the generic modules with the expectation that one of ordinary skill in the art would be capable of implementation without further instruction. The use of computing devices in this manner is merely what blockchains do, ie. performing repetitive calculations, receiving, processing, and storing data, and automating mental tasks, and does not change the analysis. Whilst the implementation of such a solution may include the use of generic technical features, these merely serve their well-understood functions as would be recognized by one of ordinary skill in the art in the technical field under consideration. As such, the claims' invocation of the computer merely amounts to the limiting of the use of the abstract idea to a particular technological environment. Here, the involvement of the generic computer products does not amount to significantly more than the abstract idea because the mere recitation of a generic blockchain computer cannot transform a patent-eligible abstract idea into a patent-eligible invention. The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception because the additional elements when considered both individually and as an ordered combination do not amount to significantly more than the abstract idea. The computer components are recited at a high level of generality and are recited as performing generic computer functions routinely used in computer applications. Generic blockchain computer components recited as performing generic computer functions that are well-understood, routine and conventional activities amount to no more than implementing the abstract idea with a computerized system. The use of generic blockchain computer components in this manner does not impose any meaningful limit on the computer implementation of the abstract idea. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation. As discussed with respect to Step 2A Prong Two, the additional elements in the claims amount to no more than mere instructions to apply the exception using generic computer components. The additional elements are recited at a high level of generality, as discussed above. The same analysis applies here in Step 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. Independent claim 24 recites substantially similar limitations as independent claim 1 and is rejected accordingly. Dependent claims 20-23 and 25-28 do not remedy the deficiencies of the independent claims and are rejected accordingly. In this case, all claims have been reviewed and are found to be substantially similar and linked to the same abstract idea (see Content Extraction and Transmission LLC v. Wells Fargo (Fed. Cir. 2014)). Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claim(s) 1 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Miu 20170187707 in view of Dutta 20220343414 As per claims 19, 24 Miu discloses an electronic device for 1. requesting an external device to issue a decentralized identifier (DID) corresponding to a current vehicle usage scenario of the driver, wherein the DID corresponds to a CID representing a combination of the vehicle and the driver, and the CID is generated based on a relationship type between the vehicle and the driver; (see at least Fig. 1B, Fig. 2): (at least Fig. 2 and paragraphs 48-51 discloses user accounts associated with users displayed as user accounts 210a, 210b, 210c/CID in the onboard vehicle system associating the user with the vehicle) 2. receiving the DID from the external device, wherein the DID is stored via a blockchain; 3. receiving, from the external device, verifiable credentials (VCs) respectively corresponding to permissions required for the current vehicle usage scenario corresponding to the DID, wherein the VCs are stored via the blockchain; (at least paragraph 17-18 discloses a digital identification document/profile data including vehicle registration and user account information); 4. generating a verifiable presentation (VP) based on a combination of at least some of the VCs; (see paragraph 16) 5. transmitting the VP to a device of a service provider (see paragraph 16) and 6. providing the service to the driver by activating a function of the vehicle corresponding to the service when verification of the VP is successful. (see paragraph 16) Miu however, fails to explicitly disclose the above bolded limitations of storing the profile data in a blockchain and wherein the CID is segmented into blockchain-based decentralized data. Dutta discloses a blockchain configuration that stores profile data in a blockchain (at least paragraph 41 discloses a blockchain storing vehicle information collected before, during and/or after a vehicle’s operation data in order to manage permission for each particular user vehicle profile). Dutta additionally discloses segmenting data into blockchain-based decentralized data ( . Therefore, it would have been obvious to a person having ordinary skill in the art at the time the application was filed to modify the onboard vehicle digital identification transmission of Miu to include the use of the blockchain technology as described in Dutta since such would provide a system which can secure interactions among a group of entities which share a common goal which do not or cannot fully trust one another (see paragraph 34) such as in an environment where multiple users are sharing a single vehicle as described in Miu. As to claims 20 and 25 (New) The electronic device of claim 19, wherein the VP comprises the combination of the at least some of the VCs and the DID. See paragraph 16 As to claims 21 and 26 (New) The electronic device of claim 19, wherein the relationship type between the vehicle and the driver comprises a relationship in which driving of the vehicle is delegated to the driver from an owner of the vehicle. (see at least Fig. 1B, Fig. 2): (at least Fig. 2 and paragraphs 48-51 discloses user accounts associated with users displayed as user accounts 210a, 210b, 210c/CID in the onboard vehicle system associating the user with the vehicle) As to claims 22 and 27. (New) The electronic device of claim 19, wherein the verification of the VP is performed based on information stored via the blockchain. Dutta discloses a blockchain configuration that stores profile data in a blockchain (at least paragraph 41 discloses a blockchain storing vehicle information collected before, during and/or after a vehicle’s operation data in order to manage permission for each particular user vehicle profile). Dutta additionally discloses segmenting data into blockchain-based decentralized data (see at least paragraph 34, 40, and 41, 48-50). Therefore, it would have been obvious to a person having ordinary skill in the art at the time the application was filed to modify the onboard vehicle digital identification transmission of Miu to include the use of the blockchain technology as described in Dutta since such would provide a system which can secure interactions among a group of entities which share a common goal which do not or cannot fully trust one another (see paragraph 34) such as in an environment where multiple users are sharing a single vehicle as described in Miu. As to claim 23 and 28. (New) The electronic device of claim 19, wherein the CID is generated based on mapping user information of each of one or more users capable of driving the vehicle information of the vehicle (see at least Fig. 1B, Fig. 2): (at least Fig. 2 and paragraphs 48-51 discloses user accounts associated with users displayed as user accounts 210a, 210b, 210c/CID in the onboard vehicle system associating the user with the vehicle) , Mui fails to teach and wherein the vehicle information and the user information are stored via the blockchain Dutta discloses a blockchain configuration that stores profile data in a blockchain (at least paragraph 41 discloses a blockchain storing vehicle information collected before, during and/or after a vehicle’s operation data in order to manage permission for each particular user vehicle profile). Dutta additionally discloses segmenting data into blockchain-based decentralized data (see at least paragraph 34, 40, and 41). Therefore, it would have been obvious to a person having ordinary skill in the art at the time the application was filed to modify the onboard vehicle digital identification transmission of Miu to include the use of the blockchain technology as described in Dutta since such would provide a system which can secure interactions among a group of entities which share a common goal which do not or cannot fully trust one another (see paragraph 34) such as in an environment where multiple users are sharing a single vehicle as described in Miu. 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 RICHARD C WEISBERGER whose telephone number is (571)272-6753. The examiner can normally be reached Monday - Thursday 10AM-8PM PCT. 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, Michael Anderson can be reached at 571-270-0508. 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. RICHARD C. WEISBERGER Examiner Art Unit 3693 /RICHARD C WEISBERGER/Primary Examiner, Art Unit 3693
Read full office action

Prosecution Timeline

May 28, 2024
Application Filed
Nov 29, 2025
Non-Final Rejection — §101, §103, §112
Feb 24, 2026
Response Filed
Apr 01, 2026
Final Rejection — §101, §103, §112 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12586048
SYSTEMS AND METHODS FOR REAL-TIME ACCOUNT ACCESS
2y 5m to grant Granted Mar 24, 2026
Patent 12548080
BLOCKCHAIN SUBROGATION PAYMENTS
2y 5m to grant Granted Feb 10, 2026
Patent 12530719
SYSTEM AND METHOD FOR OPTIMIZING ORDER PLACEMENT IN AN ORDER QUEUE IN AN ELECTRONIC TRADING ENVIRONMENT
2y 5m to grant Granted Jan 20, 2026
Patent 12524806
INTEREST RATE SWAP COMPRESSION MATCH ENGINE
2y 5m to grant Granted Jan 13, 2026
Patent 12511651
TOKENIZATION REQUEST HANDLING AT A THROTTLED RATE IN A PAYMENT NETWORK
2y 5m to grant Granted Dec 30, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
48%
Grant Probability
44%
With Interview (-4.1%)
4y 8m
Median Time to Grant
Moderate
PTA Risk
Based on 359 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month