DETAILED ACTION
Acknowledgements
This action is in response to Applicant’s filing on Feb. 26, 2026, and is made Final. This action is being examined by James H. Miller, who is in the eastern time zone (EST), and who can be reached by email at James.Miller1@uspto.gov or by telephone at (469) 295-9082.
Interviews
Examiner interviews are available by telephone or, preferably, by video conferencing using the USPTO’s web-based collaboration platform. Applicants are strongly encouraged to schedule via the USPTO Automated Interview Request (AIR) portal at http://www.uspto.gov/interviewpractice. Interviews conducted solely for the purpose of “sounding out” the examiner, including by local counsel acting only as a conduit for another practitioner, are not permitted under MPEP § 713.03. The Office is strictly enforcing established interview practice, and applicants should ensure that every interview request is directed toward advancing prosecution on the merits in compliance with MPEP §§ 713 and 713.03.
For after-final Interview requests, supervisory approval is required before an interview may be granted. Each AIR should specifically explain how the After-Final Interview request will advance prosecution—for example, by identifying targeted arguments responsive to the rejection of record, alleged defects in the examiner’s analysis, proposed claim amendments, or another concrete basis for discussion. See MPEP § 713. If the AIR form’s character limits prevent inclusion of all pertinent details, Applicants may send a contemporaneous email to the examiner at James.Miller1@uspto.gov.
The examiner is generally available Monday through Friday, 10:00 a.m. to 4:00 p.m. EST.
For any GRANTED Interview Request, Applicant can expect an email within 24 hours confirming an interview slot from the dates/times proposed and providing collaboration tool access instructions. For any DENIED Interview Request, the record will include a communication explaining the reason for the denial.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Status
The status of claims is as follows:
Claims 1–20 are pending and examined with Claims 1, 11, and 20 in independent form.
Claims 1, 2, 3, 4, 7, 8, 9, 11, 12, 13, 14, 17, 18, 19, and 20 are presently amended.
No Claims are presently cancelled or added.
Response to Amendment
Applicant's Amendment has been reviewed against Applicant’s Specification filed Jun. 13, 2024, [“Applicant’s Specification”] and accepted for examination.
Response to Arguments
35 U.S.C. § 101 Argument
Applicant notes the Office characterizes the claims recite an abstract idea exception of certain methods of organizing human activity and alternatively, to mental processes but elects not to substantially dispute Step 2A, Prong One at this time, merely stating respectful disagreement and “reserve[ing] the right to address these allegations at a later time.” Applicant’s Reply at 16.
Examiner’s Response: In the absence of specific rebuttal, Applicant's arguments fail to comply with 37 CFR 1.111(b) because they amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims support Applicant’s assertion.
Applicant agues the claims integrate any abstract idea into a practical application by reciting a specific “security-enhancing protocol” and “machine-implemented verification pipeline” that embeds mDL-based authentication and documentation verification into the transaction architecture, eliminating manual ID checks and untrusted document uploads and reducing impersonation and counterfeit-document fraud. Applicant points to claim elements such as mDL/IA authentication, identifying mDL credential data based on supplemental documentation, verifying supplemental documentation by comparison and enforcing restriction satisfaction requirements to automatically authenticate users for restricted-item transactions, citing supporting the specification, ¶¶ 2–5, 13. Applicant’s Reply at 16–8.
Examiner respectfully disagrees.
The additional elements identified by Applicant, when viewed both individually and as an ordered combination, amount to implementing an abstract authorization scheme (deciding whether to approve or deny a transaction based on identity and documentation checks) using generic computer technology such as servers, user devices, communications hardware, and software “circuitry” implemented by processors and memory as taught by the specification. The improvement asserted by Applicant lies in the business concept, not in any specific improvements of the functioning of the underlying computer hardware architecture. Independent claims recite high-level functional results. Although the specification discloses protocol-like operations, (e.g., generating a digital token in response to an mDL authentication request, transmitting the token to an IA system, and receiving an mDL validity response with verified credential and device identification data (¶¶ 55, 56), these details are only recited in dependent claims and even there at a functional high-level without specifying a particular token structure, cryptographic operation, or unconventional message sequence. The claims as currently written, merely apply the abstract authorization exception using generic computer and network operations, rather than reciting a specific improvement to the functioning of a computer or other technology as contemplated by MPEP 2106.05(a). Spec. ¶ 115.
Applicant argues that under Step 2B, the ordered combination of features is not well understood routine or conventional (as already discussed for the § 103 rejection) and therefore, amounts to significantly more that any recited exemption.
Examiner respectfully disagrees.
The individual operations—credential-based user authentication (including issuer-based validation), comparison of credential data to documentation, application of rule-based restrictions, and allow/deny handling—are each conventional in electronic transaction and identity verification systems when implemented using standard computing components. Taken together, they merely apply the abstract idea using generic technology and therefore do not apply an inventive concept.
35 U.S.C. § 103 Argument
Applicant arguments have been fully considered and found persuasive. Applicant’s Reply at 14. Specifically, the discussion about amendments regarding the supplemental required documentation. See “Examiner Statement of Prior Art—No Prior Art Rejections” point heading below. The rejection of Claim 1–20 under § 103 as previously set forth in the Non-Final Office Action mailed Nov. 26, 2025 [“Non-Final Office Action”] is WITHDRAWN.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that use the words “means” and are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. Such claim limitation(s) is/are:
means for receiving a transaction attempt associated with a user device of a user, wherein the transaction attempt comprises supplemental required documentation (Claim 20)
means for determining whether the transaction attempt includes a restricted item, wherein the restricted item is associated with a restriction satisfaction requirement; (Claim 20)
means for determining whether the transaction attempt indicates that an mDL associated with the user is comprised in the user device (Claim 20)
means for authenticating the mDL with an issuing authority (IA) system (Claim 20)
means for identifying credential data from the mDL based on data from the supplemental required documentation; (Claim 20)
means for verifying the supplemental required documentation based on a comparison between the credential data from the mDL and the data from the supplemental required documentation; (Claim 20)
means for determining whether the restriction satisfaction requirement is satisfied based on the credential data; (Claim 20)
means for authenticating the user based on the credential data and the restriction satisfaction requirement, wherein the user is successfully authenticated in response to successfully verifying the supplemental required documentation and determining that the restriction satisfaction requirement is satisfied; (Claim 20)
means for handling, based on authenticating the user, the transaction attempt, wherein (a) the transaction attempt is allowed … and (b) the transaction attempt is denied … . (Claim 20)
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Disclosure of Corresponding Structure
Having found that the aforementioned claim terms are subject to interpretation under § 112(f), next, it is determined whether Applicant’s Specification discloses sufficient structure for performing the claimed function. Examiner finds sufficient disclosure is disclosed by Applicant’s Specification.
Construing a means-plus-function claim term is a two-step process. First, the function must be identified. Second, the corresponding structure, if any, disclosed in Applicant’s Specification that corresponds to the claimed function must be determined. When multiple functions are claimed, Applicant must disclose adequate corresponding structure to perform all claimed functions. If the Applicant fails to disclose any corresponding structure or adequate corresponding structure, the claim is indefinite.
When evaluating § 112(f) limitations in software related claims for definiteness under § 112(b), a specialized function must be supported in the specification by the computer and the algorithm that the computer uses to perform the claimed specialized function. However, a non-specialized function requires no more support in the specification than a general-purpose computer or a known computer component that is recognized by those of ordinary skill in the art as typically including structure and non-specialized programming to perform the claimed function. Generally, it is only in rare circumstances that an algorithm need not be disclosed. MPEP § 2181(II)(B). Rare circumstances are when functionality is coextensive with a microprocessor such as the functions of receiving, storing, or processing of data. Id. (Katz1 exception).
The following claim limitations are interpreted under § 112(f) along with their corresponding structure from Applicant’s Specification. For each claim limitation interpreted under § 112(f), an evaluation for definiteness under § 112(b) is also performed.
Claimed Functions
means for receiving a transaction attempt;
means for determining whether the transaction attempt includes a restricted item;
means for determining whether the transaction attempt indicates that an mDL … is comprised in the user device;
means for authenticating the mDL with an issuing authority (IA) system;
means for identifying credential data from the mDL based on data from the supplemental required documentation;
means for verifying the supplemental required documentation based on a comparison … ;
means for determining whether the restriction satisfaction requirement is satisfied based on the credential data;
means for authenticating the user based on the credential data and the restriction satisfaction requirement … ;
means for handling, based on authenticating the user, the transaction attempt (allowed/denied);
Corresponding Structure
Function (1) = processor 202, memory 204, and communications hardware 206 of apparatus 200 executing the flowchart operation “receiving a transaction attempt” (e.g., operation 402) as described at ¶¶ 25, 30, 94, 95, 96.
Function (2) = smart mobile wallet management circuitry 212 (using processor 202, memory 204, and communications hardware 206) performing the restricted item determination logic: receiving a digital representation of transaction items, comparing it to a restricted items list, and classifying an item as a restricted item. ¶¶ 60, 61, 98, 99 (expressly describe these operations).
Function (3) = smart mobile wallet management circuitry 212 (again leveraging processor, memory, communications hardware) configured to check whether the transaction attempt indicates an mDL in the user device or smart wallet, as described at ¶ 61 (“determine whether the transaction attempt indicates that an mDL associated with the user is comprised in a user device (e.g., user device 108A) and/or a smart mobile wallet associated with the user”).
Function (4) = mDL management circuitry 208 and user authentication circuitry 210, together with processor 202, memory 204, and communications hardware 206, implementing the IA authentication and token based protocol described in ¶¶ 52–56 (IA authentication request, digital token generation, sending token to IA system, receiving mDL validity response).
Function (5) = smart mobile wallet management circuitry 212 and/or mDL management circuitry 208 executing the flow described around ¶¶ 71, 101–5, where the system uses “desired credential data” selected based on restricted items and restriction requirements, and retrieves those credential fields from the mDL or from the mDL validity response.
Function (6) = smart mobile wallet management circuitry 212 performing data comparisons between fields from the supplemental required documentation and the credential data obtained from the mDL, as described conceptually (¶¶ 3, 4 (verification of firearm license, prescriptions)), and in the discussion of verifying documentation is associated with the user and transaction (¶¶ 71, 103–4).
Function (7) = smart mobile wallet management circuitry 212 implementing the logic of applying “restriction satisfaction requirements” (age minimums, permit validity, etc.) to the verified credential data, as discussed at ¶¶ 2, 3 and in the “restriction satisfaction requirement” steps of ¶¶ 101–5.
Function (8) = user authentication circuitry 210, working with mDL management circuitry 208 and/or biometric data management circuitry 214, making the final authentication decision, as described at ¶¶ 57–9 and in the flowchart (operations where user authentication circuitry authenticates user based on mDL validity response and/or biometric score).
Function (9) = smart mobile wallet management circuitry 212 implementing the allow/deny and transaction handling steps, as described at ¶¶ 30, 111, 112 (allow or deny transaction; optionally remove restricted items; send notifications).
Evaluation of Definitiveness under § 112(b)
Function (1) = non-specialized (basic network I/O), which the Specification teaches is standard communications hardware and processor logic (¶¶ 44, 96).
Function (2) = specialized function with the algorithm is spelled out (receive item data, compare to restricted list, classify), so corresponding structure is adequately disclosed.
Function (3) = specialized function with the high-level algorithm, inspect transaction related data / smart wallet state to see if an mDL is present, taught in ¶ 61.
Function (4) = specialized function with the algorithm reasonably spelled out: generate IA authentication request, obtain IA public key, generate digital token with cryptographic information, transmit token, receive validity response. ¶¶ 52–6.
Function (5) = specialized function with the algorithm reasonably spelled out in ¶¶ 71, 101–5: determine desired credential data from restricted item/restriction requirement, then retrieve those credentials from the mDL or IA response.
Function (6) = specialized function with the algorithm reasonably spelled out in ¶¶ 71, 103–4 in prose (compare corresponding fields and decide match/non match).
Function (7) = specialized function with the algorithm reasonably spelled out in ¶¶ 101–5 (“if credential value meets requirement, condition is satisfied”)
Function (8) = specialized function with the algorithm reasonably spelled out in ¶¶ 57–9 (if credential checks and restriction satisfaction succeed (and optionally biometric threshold is met), authenticate user; otherwise, fail.)
Function (9) = non-specialized function for transaction control (processing) (¶¶ 30, 111, 112).
Thus, for each “means for” element in claim 20, the specification provides corresponding structure: specific circuitries (elements 208, 210, 212, 214), processor/memory/communications hardware 206, and flowchart operations with described logic (¶¶ 40–6, 52–6, 60, 61, 71, 98, 99, 101–5, 111–12) ¶¶ 81, 82 tie the functions to concrete components and algorithms.
None of the recited functions appear to be pure “black box” functions without any described way to perform them. Even the more specialized functions (IA system mDL authentication, credential-based documentation verification, restriction satisfaction determination) have at least high-level algorithmic support. On this record, Claim 20 is definite under § 112(b).
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–20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., an abstract idea) without significantly more.
Analysis
Step 1: Claims 1–20 are directed to a statutory category. Claims 1–10 recite a “method” and are therefore, directed to the statutory category of a “process.” Claims 11–19 recite an “apparatus” and are therefore, directed to the statutory category of a “machine.” Claim 20 recites a “system” and is therefore, directed to the statutory category of a "machine.”
Representative Claim
Claim 11 is representative [“Rep. Claim 11”] of the subject matter under examination and recites, in part, emphasis added by Examiner to identify limitations with normal font indicating the abstract idea exception, bold limitations indicating additional elements. Each limitation is identified by a letter for later use as a shorthand notation in referencing/describing each limitation. Portions of the claim use italics to identify intended use limitations2 and underline to identify amendments this round:
[A] 11. An apparatus for providing automatic [mobile driver’s license]3-based transaction management:
[B] communications hardware configured to:
[B1] receive a transaction attempt associated with a user device of a user, wherein the transaction attempt comprises supplemental required documentation;
[C] smart mobile wallet management circuitry configured to:
[C1] determine whether the transaction attempt includes a restricted item, wherein the restricted item is associated with a restriction satisfaction requirement,
[C2] in an instance in which the transaction attempt includes a restricted item, determine whether the transaction attempt indicates that an [mobile driver’s license] associated with the user is comprised in the user device,
[C3] in response to determining that the transaction attempt indicates an [mobile driver’s license] associated with the user is comprised in the user device, authenticate the [mobile driver’s license] with an issuing authority (IA) system,
[C4] in response to determining that the [mobile driver’s license] is authentic, identify credential data from the [mobile driver’s license] based on data from the supplemental required documentation, verify the supplemental required documentation based on a comparison between the credential data from the [mobile driver’s license] and the data from the supplemental required documentation, and determine whether the restriction satisfaction requirement is satisfied based on the credential data; and
[D] user authentication circuitry configured to: authenticate the user based on the credential data and the restriction satisfaction requirement, wherein the user is successfully authenticated in response to successfully verifying the supplemental required documentation and determining that the restriction satisfaction requirement is satisfied,
[E] wherein the smart mobile wallet management circuitry is further configured to handle, based on authenticating the user, the transaction attempt, wherein (a) the transaction attempt is allowed in an instance in which the user is successfully authenticated and (b) the transaction attempt is denied in an instance in which the user fails to be successfully authenticated.
Claims are directed to an abstract idea exception.
Step 2A, Prong One: Rep. Claim 11 recites “handle, based on authenticating the user, the transaction attempt, wherein (a) the transaction attempt is allowed in an instance in which the user is successfully authenticated and (b) the transaction attempt is denied in an instance in which the user fails to be successfully authenticated” in Limitation E, which recites a fundamental economic principle/practice under the organizing human activity exception because “allow[ing]” or “den[ying]” a “transaction attempt” based on “authenticating the user,” “describe concepts relating to the economy and commerce,” such as “mitigating risks” of a fraudulent transaction. MPEP § 2106.04(a)(2)(II)(A). Limitations B1, C1, and C2 are the required steps and data inputs required to “handle, based on authenticating the user, the transaction attempt” and therefore, recites the same exception. Id.
Alternatively4, Limitations B1, C1, C2, and E as drafted, recite the abstract idea exception of mental processes that under the broadest reasonable interpretation, cover performance in the human mind or with pen and paper, but for the recitation of the generic computer components indicated in bold. MPEP § 2106.04(a)(2)(III).
Claims recite a mental process when they contain limitations that can practically be performed in the human mind, including for example, observations, evaluations, judgments, and opinions. Examples of claims that recite mental processes include:
• a claim to "collecting information, analyzing it, and displaying certain results of the collection and analysis," where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind, Electric Power Group v. Alstom, S.A., 830 F.3d 1350, 1353-54, 119 USPQ2d 1739, 1741-42 (Fed. Cir. 2016);
. . .
• a claim to collecting and comparing known information (claim 1), which are steps that can be practically performed in the human mind, Classen Immunotherapies, Inc. v. Biogen IDEC, 659 F.3d 1057, 1067, 100 USPQ2d 1492, 1500 (Fed. Cir. 2011).
MPEP § 2106.04(a)(2)(III)(A). For example, but for the generic computer components claim language, here, Limitations B1, C1, C2, and E, recite collecting information (Limitations B1) and analyzing it (Limitations C1, C2, and E), where the data analysis steps are recited at a high level of generality such that they could practically be performed in the human mind. For example, Limitations C1 and C2 are mental processes that are practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to “determine whether the transaction attempt includes a restricted item, wherein the restricted item is associated with a restriction satisfaction requirement” (Limitation C1) and “determine whether the transaction attempt indicates that a[ ] [ ] driver’s license associated with the user is [presented], in an instance in which the transaction attempt is associated with one or more restricted items,” (Limitation C2). Likewise, Limitation E is a mental process that is practically performed in the human mind or with pen and paper because it requires mere “observation, evaluation, judgment, and/or opinion” to “handle, based on authenticating the user, the transaction attempt, wherein (a) the transaction attempt is allowed in an instance in which the user is successfully authenticated and (b) the transaction attempt is denied in an instance in which the user fails to be successfully authenticated.” Limitations C1, C2, and E cover any solution with no restriction on how the result is accomplished and no description of the mechanism for accomplishing the result, which is so broad as to encompass mental processes. Receiving a transaction attempt, determining whether it involves a restricted item with an associated restriction requirement, and allowing or denying the transaction based on whether the user is authenticated merely reflects the abstract idea of collecting information, evaluating it under a rule, and deciding an outcome. These are activities that can be practically performed mentally or with pen and paper by a human clerk authorizing restricted transactions.
If a claim limitation under BRI, covers performance of the limitation in the mind but for the recitation of generic computer components, then it falls within the “Mental Processes” grouping of abstract idea exception. MPEP § 2106.04(a)(2)(III). Accordingly, the pending claims recite the combination of these abstract idea exceptions.
Step 2A, Prong Two: Rep. Claim 11 does not contain additional elements that integrate the abstract idea exception into a practical application because the additional elements are mere instructions to apply the abstract idea exception. MPEP § 2106.05(f). The additional elements are limited to the computer components and indicated in bold, supra. The additional elements are: An apparatus [computer]; mobile characterization of “driver’s license” [computer]; communications hardware; a user device; smart mobile wallet management circuitry; and Limitations C3, C4, and D.
Regarding the apparatus [computer]; mobile characterization of “driver’s license” [computer]; communications hardware; a user device; smart mobile wallet management circuitry; and Limitations C3, C4, and D, Applicant’s Specification does not otherwise describe them or describes them using exemplary language as a general-purpose computer, as a part of a general-purpose computer, or as any known and exemplary (generic) computer component known in the prior art. Thus, Applicant takes the position that such hardware/software is so well known to those of ordinary skill in the art that no explanation is needed under 35 U.S.C. § 112(a). Lindemann Maschinenfabrik GMBH v. Am. Hoist & Derrick Co., 730 F.2d 1452, 1463 (Fed. Cir. 1984) (citing In re Meyers, 410 F.2d 420, 424 (CCPA 1969) (“[T]he specification need not disclose what is well known in the art”). E.g., Spec. ¶ 92 (“loading the software instructions onto a computing device or apparatus produces a special-purpose machine comprising the means for implementing various functions described herein.”); ¶ 9 (“compare the captured biometric data to known biometric data … (e.g., known user portrait image data associated with the user's mDL … compare the captured biometric data to the known biometric data in order to verify and/or authenticate the user”); ¶ 13 (“compare the captured biometric data with known biometric data (e.g., known image data related to the user's facial features, known voiceprint data) associated with the user and/or the user's mDL. Using traditional verification methods, a clerk would have to manually verify the user by comparing the portrait of the user on a government-issued photo ID with the user's face. If a counterfeit photo ID is presented to the clerk, the clerk may have a difficult time making a correct judgement on whether the photo ID is valid in a short period of time. As such, the mDL-based verification mitigates potential human error.”); ¶ 39 (“the one or more enterprise computing devices 106A-106N and/or the one or more user devices 108A-108N may be embodied by any computing devices known in the art.”); ¶ 57 (“facilitate the identification and/or authentication of a user based on captured biometric data and/or known biometric data associated with the user.”); ¶ 69 (“matching the user signature data captured in real time, or near-real time, to the known user signature data associated with the user's mDL.”); ¶ 76 (“compare captured biometric data associated with a user to known biometric data associated with the user … the known biometric data may be associated with an mDL associated with the user (e.g., user portrait image data, user signature data, and/or the like associated with the user's mDL).”); ¶ 77 (“comparing the captured biometric data to the known biometric data, whether the biometric data satisfies a biometric data matching threshold.”); ¶ 78 (“matching user signature data that is captured in real time, or near-real time, during a transaction attempt (e.g., via a handwriting capture device) to known user signature data associated with an mDL … matching score based on matching the user signature data captured in real time, or near-real time, to the known user signature data associated with the user's mDL.”); ¶ 115 (“many modifications … will come to mind …not to be limited to the specific embodiments disclosed”); ¶ 13 (“example embodiments are capable of performing user verification securely and accurately while avoiding human mistakes”); ¶ 22 (“The term "computing device" refers to any one or all of [long list of “computing devices”]); ¶ 23 (“The term "server" or "server device" refers to any computing device capable of functioning as a server”); ¶ 24 (“The smart mobile wallet may store digital identification documents associated with a respective user (e.g., an mDL) … and/or any other relevant digital assets associated with the user.”); ¶ 25 (“Example embodiments described herein may be implemented using any of a variety of computing devices or servers”); ¶ 41 (any known “processor”); ¶ 44 (“The communications hardware 206 may be any means such as a device or circuitry embodied in either hardware or a combination of hardware and software that is configured to receive and/or transmit data”); ¶ 71 (“any relevant permit required to purchase a restricted item”); ¶ 83 (“As illustrated in FIG. 3, an apparatus 300 is shown that represents an example enterprise computing device ( e.g., any of enterprise computing devices 106A-106N) or an example user device (e.g., any of user devices 108A-108N)”); ¶ 92 (“Any suitable non-transitory computer-readable storage medium may be utilized”). The generic processor, here, appears to perform calculations (functions) that are programmed by software. Spec. ¶ 41. This is a computer doing what it is designed to do—performing directions it is given to follow.
Limitations B1, C1, C2, and E describe the additional limitations, Limitations A, B, C, C3, C4 and D, performing the steps of the claimed invention, which represents the abstract idea exception itself. Performing the steps of the abstract idea exception itself simply adds a general-purpose computer after the fact to an abstract idea exception, MPEP § 2106.05(f)(2), or generically recites an effect of the judicial exception. MPEP § 2106.05(f)(3).
Thus, all the additional elements, including Limitations C3, C4, and D are implemented using generic computer components and standard network communications as taught by Applicant’s own specification and are recited at a high functional level (e.g., send authentication information, receive a validity response, compare data, and apply a rule). Therefore, the claim as a whole, looking at the additional elements individually and in combination, are no more than mere instructions to apply the exception using generic computer components and is not a practical application. MPEP § 2106.05(f). The additional elements do not integrate the abstract idea exception into a practical application because they do not impose any meaningful limits on the abstract idea exception. Accordingly, Rep. Claim 11 is directed to an abstract idea.
Rep. Claim 11 is not substantially different than Independent Claims 1 and 20 and includes all the limitations of Rep. Claim 11. Independent Claims 1 and 20 contain no additional elements. Therefore, Independent Claims 1 and 20 are also directed to the same abstract idea.
The claims do not provide an inventive concept.
Step 2B: Rep. Claim 11 fails Step 2B because the claim as whole, looking at the additional elements individually and in combination, are not sufficient to amount to significantly more than the recited judicial exception. As discussed with respect to Step 2A, Prong Two, the additional elements in the claim amount to no more than mere instructions to apply the exception using a generic computer and/or generic computer components. MPEP § 2106.05(f). The same analysis applies here in Step 2B. Mere instructions to apply an exception using a generic computer and/or generic computer components cannot provide an inventive concept. MPEP § 2106.05(I).
The additional elements, taken individually and in combination, do not result in the claim, as a whole, amounting to significantly more than the identified judicial exception.
The pending claims in their combination of additional elements is not inventive. First, the claims are directed to an abstract idea. Second, each additional element represents a currently available generic computer technology, used in the way in which it is commonly used (individually generic). Last, Applicant’s Specification discloses that the combination of additional elements is not inventive. Spec., ¶ 115 (steps/functions may be performed in any order); ¶¶ 9, 13, 22, 23, 24, 25, 39, 41, 44, 57, 69, 71, 76, 77, 78, 83, 92, 115, Figs. 1, 2, 3 (known and generic (exemplary) computer equipment as explained and cited supra.)
Thus, Examiner finds the additional elements of Rep. Claim 11 are elements that have been recognized as well-understood, routine, and conventional (“WURC”) activity in the particular field of this invention based on Applicant’s own disclosure5. Spec. ¶¶ 9, 13, 22, 23, 24, 25, 39, 41, 44, 57, 69, 71, 76, 77, 78, 83, 92, 115, Figs. 1, 2, 3; MPEP § 2106.05(d). Specifically, Applicant’s Specification discloses the recited additional elements (i.e., apparatus [computer]; mobile characterization of “driver’s license” [computer]; communications hardware; a user device; smart mobile wallet management circuitry; and Limitations C3, C4, and D.) are limited to generic computer components. These elements do no more than “apply” the recited abstract idea(s) on a known computer (e.g., apparatus) and computer-related components (e.g., circuitry). The Examiner also finds the functions of receiving, storing, transmitting, displaying, processing and Limitations C3, C4, and D, are all normal functions of a generic computer based on Applicant’s own disclosure.
There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Thus, taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception (the abstract idea). Looking at the additional elements in combination adds nothing that is not already present when looking at the elements individually. Their collective functions merely provide conventional computer implementation of the abstract idea at a high level of generality. Thus, Rep. Claim 11 does not provide an inventive concept.
Rep. Claim 11 is not substantially different than Independent Claims 1 and 20 and includes all the limitations of Rep. Claim 11. Independent Claims 1 and 20 contain no additional elements. Therefore, Independent Claims 1 and 20 are also directed to the same abstract idea.
Dependent Claims Not Significantly More
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claim(s) when analyzed both individually and in combination are also held to be patent ineligible under 35 U.S.C. § 101. Dependent claims are dependent on Independent Claims and include all the limitations of the Independent Claims. Therefore, all dependent claims recite the same Abstract Idea. Dependent claims do not contain additional elements that integrate the abstract idea exception into a practical application or recite an inventive concept because the additional elements: (1) are mere instructions to apply the abstract idea exception; and/or (2) further limit the abstract idea exception of the Independent Claims. The abstract idea itself cannot provide the inventive concept or practical application. MPEP §§ 2106.05(I), 2106.04(d)(III).
Dependent Claims 2 and 12 all recite “wherein” clauses that further limits the abstract idea of the Independent Claims but contains the additional elements of: a digital token. For the same reasoning as explained for the “computer hardware” in Step 2A, Prong Two, and Step 2B, supra, this additional element does not provide a practical application or inventive concept because it is amounts to mere instructions to apply the exception with a computer. MPEP § 2106.05(f). “Generating a digital token” can occur in any manner. The authenticating limitation based on a validity response recites a mental process. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). The “receiving,” “transmitting,” “receiving,” limitations merely invoke computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2).
Dependent Claims 3, 4, 5, 9, 13, 14, 15, and 19 all recite “wherein” clauses or limitations that further limit the abstract idea of the Independent Claims and contain no additional “elements. The “authenticating” and “determining” limitations (Claims 3, 13), as drafted recite a mental process. The “capturing,” “comparing,” “determining,” and authenticating limitations (Claims 5, 15) recites a mental process. Captured biometric data can be a picture and a human is capable of recognizing others. The “determining” and “classifying” limitations (Claim 9) also recite a mental process, as drafted. The “determining” limitation (Claim 19) is also a mental process, as drafted. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). The “receiving” limitation (Claims 9, 19) merely invoke computers or other machinery in its ordinary capacity to receive, store, or transmit data. MPEP § 2106.05(f)(2).
Dependent Claims 6, 7, 10, 16, and 17 recite additional limitations that form part of the same abstract idea exception as recited in Independent Claims and contain no additional elements. The “determining,” “authenticating,” and “handling” limitations (Claims 7, 8, 17, 18) recite mental processes. The “generating” limitation (Claim 10) recites a mental process. An inventive concept or practical application cannot be furnished by an abstract idea exception itself. MPEP §§ 2106.05(I), 2106.04(d)(III). The “displaying” limitation (Claims 6, 16) and “causing storage” limitation (Claim 10) merely invoke computers or other machinery in its ordinary capacity to receive, store, display, or transmit data. MPEP § 2106.05(f)(2).
Conclusion
Claims 1–20 are therefore drawn to ineligible subject matter as they are directed to an abstract idea without significantly more. The analysis above applies to all statutory categories of invention. As such, the presentment of Rep. Claim 11 otherwise styled as another statutory category is subject to the same analysis.
Examiner Statement of Prior Art—No Prior Art Rejections
Based on the prior art search results, the prior art of record fails to anticipate or render obvious the claimed subject matter of the instant application. While some individual features of Claims 1–206 may be shown in the prior art of record—no known reference, alone or in combination, would provide the invention of Claims 1–20. Independent claims recite, using Claim 1 as the example:
1. A method for providing automatic mobile drive license (mDL) - based transaction management, the method comprising: receiving, by communications hardware, a transaction attempt associated with a user device of a user, wherein the transaction attempt comprises supplemental required documentation; determining, by smart mobile wallet management circuitry, whether the transaction attempt includes a restricted item, wherein the restricted item is associated with a restriction satisfaction requirement; in an instance in which the transaction attempt includes a restricted item, determining, by the smart mobile wallet management circuitry, whether the transaction attempt indicates that an mDL associated with the user is comprised in the user device; in response to determining that the transaction attempt indicates an mDL associated with the user is comprised in the user device, authenticating, by the smart mobile wallet management circuitry, the mDL with an issuing authority (IA) system; in response to determining that the mDL is authentic, identifying, by the smart mobile wallet management circuitry, credential data from the mDL based on data from the supplemental required documentation; verifying, by the smart mobile wallet management circuitry, the supplemental required documentation based on a comparison between the credential data from the mDL and the data from the supplemental required documentation; determining, by the smart mobile wallet management circuitry, whether the restriction satisfaction requirement is satisfied based on the credential data; authenticating, by user authentication circuitry, the user based on the credential data and the restriction satisfaction requirement, wherein the user is successfully authenticated in response to successfully verifying the supplemental required documentation and determining that the restriction satisfaction requirement is satisfied; and handling, by the smart mobile wallet management circuitry and based on authenticating the user, the transaction attempt, wherein (a) the transaction attempt is allowed in an instance in which the user is successfully authenticated and (b) the transaction attempt is denied in an instance in which the user fails to be successfully authenticated.
The bolded elements recite a specific mDL-centric smart-wallet architecture: (1) an mDL authenticated by an issuing authority (IA) system and stored in a mobile wallet; (2) smart mobile wallet management circuitry that ingests “supplemental required documentation” (e.g., firearm permits, prescriptions, hazardous-material permits, loan documents) (Spec. ¶ 71) as part of the restricted-item transaction; (3) identification of particular mDL credential data “based on data from that supplemental documentation”; (4) verification of the supplemental documentation by “comparing its data to the mDL credential data”; and (5) automated allow/deny transaction handling conditioned on both successful supplemental documentation verification and satisfaction of a restriction satisfaction requirement.
The prior art most closely resembling the applicant’s claimed invention are:
Maheshwari et al. (U.S. Pat. Pub. No. 2022/0005047) is pertinent because it discloses a mobile device age verification method where a digital wallet receives a payment credential request including age verification data, verifies the user via biometrics and invokes a digital identity application t determine whether an age requirement is met for a POS transaction. Maheshwari, ¶¶ 7, 8, 10, 19. Maheshwari does not disclose an mDL authenticated with an issuing authority system, does not ingest or verify “supplemental required documentation” as part of the transaction, and does not identify mDL credential data based on such documentation or compare that data to verify the documentation itself within the wallet.
FOR: Int. Pat. Pub. No. WO 2012/078987 A2 is pertinent because it discloses central prescription servers, prescription identifiers or claim checks, and workflows in which pharmacies verify prescription validity and prescriber credentials before dispensing. The pharmacist verifies the patient’s identity (using a physical ID) but they do not disclose a smart mobile wallet that holds an authenticated mDL, ingests the prescription itself as supplemental documentation, selects mDL credential fields based on that prescription, and verifies the prescription by directly comparing its data to mDL credential data for automated transaction allow/deny logic.
NPL: ISO/IEC DIS 18013-5 (Draft) (2020) is pertinent because it discloses the mDL ecosystem, including mDL data models, offine and online data-sharing, protocols, issuer signatures, trust lists, and several use cases such as age-restricted purchases, car rental, building access, and banking KYC. NPL teaches that verifiers can request subsets of mDL attributes (e.g., DOB, and over N, privileges) and authenticate those attributes via issuer cryptography but they do not contemplate ingesting separate transaction specific legal documents (firearm permits, prescriptions, loan documentation) into a wallet, selecting mDL credential fields based on those documents, or verifying those documents by comparing their data to mDL credential data inside the wallet as a condition for transaction handling.
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 JAMES H MILLER whose telephone number is (469)295-9082. The examiner can normally be reached M-F: 10- 4 PM (EST).
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, Bennett M Sigmond can be reached at (303) 297-4411. 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.
/JAMES H MILLER/Primary Examiner, Art Unit 3694
1 EON Corp. IP Holdings LLC v. AT & T Mobility LLC, 785 F.3d 616, 621 (Fed. Cir. 2015) (citing In re Katz Interactive Call Processing Patent Litigation, 639 F.3d 1303 (Fed. Cir. 2011) (explaining “The Katz Exception”)
2 Statements of intended use fail to limit the scope of the claim under BRI. MPEP § 2103(I)(C).
3 The “mDL” abbreviation is replaced through Rep. Claim 11 with “mobile driver’s license.”
4 “It should be noted that these groupings are not mutually exclusive, i.e., some claims recite limitations that fall within more than one grouping or sub-grouping. … Accordingly, examiners should identify at least one abstract idea grouping, but preferably identify all groupings to the extent possible, if a claim limitation(s) is determined to fall within multiple groupings and proceed with the analysis in Step 2A Prong Two.” MPEP § 2106.04(a).
5 See Changes in Examination Procedure Pertaining to Subject Matter Eligibility, Recent Subject Matter Eligibility Decision (Berkheimer v. HP, Inc.), 3-4, https://www.uspto.gov/sites/default/files/documents/memo-berkheimer-20180419.PDF (April, 18, 2018) (That additional elements are well-understood, routine, or conventional may be supported by various forms of evidence, including "[a] citation to an express statement in the specification or to a statement made by an applicant during prosecution that demonstrates the well-understood, routine, conventional nature of the additional element(s).").
6 For claim 20, None of the cited art alone or in combination discloses the corresponding structures or equivalents performing those specific mDL-plus-supplemental-documentation functions.