DETAILED ACTION
Notice to Applicant
The following is a FINAL Office action upon examination of application number 18/777,037 filed on 07/18/2024. Claims 1-20 are pending in this application, and have been examined on the merits discussed below.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
In the response filed December 19, 2025, Applicant amended claims 1 3, 5, 9,11, and 17-18, and did not cancel any claim. No new claim was presented for examination.
Applicant's amendments to claim 5 are hereby acknowledged. The amendments are sufficient to overcome the previously issued claim objection; accordingly, this objection has been removed.
Applicant's amendments to the claims are hereby acknowledged. The amendments are not sufficient to overcome the previously issued claim rejection under 35 U.S.C. 101; accordingly, this rejection has been maintained.
Response to Arguments
Applicant's arguments filed December 19, 2025, have been fully considered.
7 Applicant submits “Applicant notes that amended claim 1 incorporates a limitation (e.g., "generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL") that was previously recited in claim 3. As mentioned above, claim 3 was not rejected under 35 U.S.C. § 101. Accordingly, amended claim 1 includes subject matter already indicated (e.g., via a lack of a10 of 14 § 101 rejection) as eligible subject matter. Thus, Applicant that amended claim 1 recites eligible subject matter, and thus requests withdrawal of the 35 U.S.C. § 101 rejections. [Applicant’s Remarks, 12/19/2025, pages 10-11]
The Examiner respectfully disagrees. In response to Applicant’s argument that amended claim 1 is patent eligible because it incorporates a limitation previously recited in claims 3, which was not rejected under 35 U.S.C. § 101, it is noted that the lack of a prior § 101 rejection of claim 3 does not automatically confer eligibility to claim 1. Each claim must be examined on its own merit. Amended claim 1 now recites only the step of generating a digital token with cryptographic information, without including the additional steps present in claim 3, such as transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; and receiving, by the communications hardware and from the IA system, a mDL validity response, wherein the mDL validity response indicates credential data associated with the mDL. Although claim 3 included both generation and communication with an issuing authority (providing a concrete technical effect), claim 1 as amended does not recite the additional steps, which were significant to the prior determination. Therefore, the prior § analysis of claim 3 does not automatically extend to claim 1. Claim 1 is interpreted as reciting concepts related to the abstract idea of delegating and verifying authority, with the generation of the “digital token” being implemented on generic circuitry. Absent additional steps that demonstrate a technical improvement (e.g., interaction with an IA system, or a specific technical effect beyond abstract token generation, claim 1, does not recite an inventive concept sufficient to transform the abstract idea into patent eligible subject matter. Accordingly, this argument is found unpersuasive.
8. Applicant submits “that the claims, at least as amended herein, are integrated into a practical application because the claims recite a particular technical solution for a trusted intermediary to securely verify a purported delegate based on a verification of an authenticity of an authentication token (e.g., an mDL). In particular, the particular technical solution leverages a trusted intermediary that enables entities (e.g., individuals) to verify purported delegates based on an authenticity of an authentication token presented by said purported delegates in a real- world scenario. For example, amended claim 1 recites "receiving ... an authority verification request from a second user device associated with a second user, wherein the authority verification request comprises at least an indication of a mobile driver's license (mDL) associated with a third user and an indication of a delegated action," "generating, ... based on an indication of the mDL, a digital token comprising cryptographic information associated with the mDL," "determining, ... based on the digital token, an authority verification result identifying whether the third user is authorized to perform the delegated action," and "causing ... transmission of an indication of the authority verification result to the second user device." Accordingly, by generating a cryptographically protected digital token based on an indication of a mDL associated with and received from a user verifying a purported delegate, and by determining an authority verification result based on that digital token, the claims recite a particular practical application of any alleged abstract idea, and thus are eligible at Step 2A, Prong Two.” [Applicant’s Remarks, 12/19/2025, page 11]
In response to Applicant’s argument that “the claims, at least as amended herein, are integrated into a practical application because the claims recite a particular technical solution for a trusted intermediary to securely verify a purported delegate based on a verification of an authenticity of an authentication token (e.g., an mDL). In particular, the particular technical solution leverages a trusted intermediary that enables entities (e.g., individuals) to verify purported delegates based on an authenticity of an authentication token presented by said purported delegates in a real-world scenario,” it is noted that the additional elements in amended claim 1 are: communications hardware, a first user device, a user delegation circuitry, a second user device, a mobile driver's license (mDL), mDL management circuitry, a digital token comprising cryptographic information, and a user authentication circuitry, which merely serve to tie the abstract idea to a particular technological environment (computer-based operating environment) via generic computing hardware, software/instructions, which is not sufficient to amount to a practical application, as noted in MPEP 2106.05. Applicant has provided no facts/evidence, cited any portion of the Specification, nor provided a persuasive line of reasoning showing how the additional elements are integrated with the abstract idea to integrate the abstract idea into a practical application.
It is also noted that the claims are devoid of any discernible change, transformation, or improvement to a computer (software or hardware) or any existing technology. Applicant has not shown that any specific technological improvement is achieved within the scope of the claims. It bears emphasis that no hardware, device, or technological elements are modified or improved upon in any discernible manner. Instead, the result produced by the claims is simply information relating to an indication of the authority verification result, which is not a technical result or improvement thereof.
Furthermore, the additional elements fail to integrate the abstract idea into a practical application because they fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Moreover, in response to Applicant’s argument that the claims are integrated into a practical application by reciting a trusted intermediary that verifies a purported delegate using a cryptographically protected digital token, the Examiner notes that when the claim is considered as a whole, the recited steps are directed to verifying delegated authority based on authentication information, which constates an abstract idea. The generation and use of the digital token, as presently claimed, do not recite a specific technical improvement to computer functionality, but instead reflect the use of cryptographical information in a conventional manner to carry out the abstract verification process. Examiner suggests amending the claim to clarify the technical nature of the token generation and verification process or to recite additional technical features that demonstrate a concrete improvement computer or technology. For the reasons above, this argument is found unpersuasive.
9. Applicant submits “The Office Action admits that Lu does not discuss verifying an mDL associated with a purported delegate but alleges that Aabye corrects this deficiency. See Office Action, page 13. Applicant respectfully disagrees.” [Applicant’s Remarks, 12/19/2025, page 12]
Applicant disagrees with the Office action’s reliance on Aabye, asserting that Lu does not discuss verifying an mDL associated with a purported delegate. However, it is noted that claim 1 does not recite a limitation requiting verification of a mobile driver’s license. Instead, amended claim 1 recites “determining, by a user authentication circuitry and based on the digital token, an authority verification result,” without specifying that the mobile driver’s license itself must be verified or authenticated. As explained in the Office action, Aabye teaches receiving a digital license and using cryptographically derived information to make an authorization or access determination. Such disclosure reasonably corresponds to the claimed step of determining an authority verification result. In response to applicant's argument that the references fail to show certain features of the invention, it is noted that the features upon which applicant relies (i.e., verifying an mDL associated with a purported delegate) are not recited in the rejected claim(s). Although the claims are interpreted in light of the specification, limitations from the specification are not read into the claims. See In re Van Geuns, 988 F.2d 1181, 26 USPQ2d 1057 (Fed. Cir. 1993). Accordingly, Applicant’s argument is not commensurate with the scope of the claim.
10. Applicant submits “the Office Action fails to provide a valid rationale for combining Lu with Aabye. The need to provide a rationale for combination is not some technicality, but exists explicitly to prevent impermissible reliance on an applicant's own disclosure during the examination process. As the Federal Circuit has held, "using the invention as a roadmap to find its prior art components ... would discount the value of combining various existing features or principles in a new way to achieve a new result - often the very definition of invention." Princeton Biochemicals, Inc. v. Coulter, Inc., 411 F.3d 1332, 1337 (Fed. Cir. 2005). In this case, as mentioned on page 16 of the Office Action, "Lu is directed to a delegation framework" and "Aabye relates to an authentication system" that generally discusses issuance and authentication of mDLs. However, Lu does not contemplate verifying the authenticity of an authentication token presented by a purported delegate. Additionally, Aabye does not contemplate verifying an mDL of a user in a real-world scenario to ultimately authorize (or not authorize) a purported delegate. The Office Action alleges that a motivation for modifying Lu with Aabye is to gain the benefits of "reduced fraud." See Office Action, page 16. However, Lu does not contemplate any evident need to reduce fraud. Further, although Aabye contemplates fraud reduction, this benefit is in the context of ID fraud, not other types of fraud; in other words, Aabye is focused on the problem of using a fraudulent driver's license, and suggests use of an mDL as a vehicle to mitigate that type of ID fraud. Nothing in either reference illustrates a need to reduce fraud that would occur in the setting described in Lu, and therefore the Office Action's reliance on "reduced fraud" does not actually appear to be a motivation found in the prior art. Thus, besides the benefits set forth in the application itself, it is unclear why one having ordinary skill in the art at the time of the invention would seek to modify the user delegation system discussed in Lu from a wholly unrelated area of inquiry described in Aabye.” [Applicant’s Remarks, 12/19/2025, page ]
In response to Applicant’s argument that there is no motivation to combine the cited references, the Examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, it is noted that the examiner has provided reasoning articulating why it would have been obvious to combine the references as proposed. The Examiner notes that a prior art reference must either be in the field of applicant’s endeavor or, if not, then be reasonably pertinent to the particular problem with which the applicant was concerned, in order to be relied upon as a basis for rejection of the claimed invention. See In re Oetiker, 977 F.2d 1443, 24 USPQ2d 1443 (Fed. Cir. 1992). The Examiner points out that the rejection of claim 1 provides an articulated line of reasoning based on the teachings of the prior art, the knowledge of one skilled in the art, and the motivation to modify the prior art to arrive at the conclusion of obviousness of claimed invention, which is a permissible means to support the legal conclusion of the obviousness of the claimed subject matter. See KSR Int'l Co. v. Teleflex Inc., 550 U.S. at 418, 82 USPQ2d at 1396 (quoting In re Kahn, 441 F.3d 977, 988, 78 USPQ2d 1329, 1336 (Fed. Cir. 2006)).
As discussed in the Office action, both references are directed to analogous solution in the field of user verification and authorization. Lu teaches a delegation framework, and Aabye teaches authenticating a digital credential, such as a mobile driver license, to support authorization decisions. One of ordinary skill in the art would have recognized that applying Aabye’s credential based verification techniques to Lu’s delegation framework would provide predictable results, including assurance that delegated actions are performed by authorized users. The rationale for combining the references need not to arise from a problem identified in Lu alone; rather, it is sufficient that the combination reflects a predictable application of known techniques within the relevant field.
As the claims have been given their "broadest reasonable interpretation consistent with the specification", the Examiner asserts that the scope and contents of the prior art have been determined, thereby satisfying the first factual inquiry set forth by Graham v. John Deere Co. The Examiner applied the teachings of Lu and Aabye, and determined the deficiencies, thereby ascertaining the differences between the prior art and the claims at issue. The Examiner has fulfilled the role of factfinder while resolving the Graham inquiries, as per MPEP 2141, and determined that the level of ordinary skill in the art is reflected by the prior art itself, thereby resolving the level of ordinary skill in the pertinent art. The Examiner asserts that the Graham factual inquiries have been properly resolved, resulting in a proper prima facie case of obviousness. Accordingly, this argument is found unpersuasive.
11. Applicant submits “it appears that the Office Action relies on impermissible hindsight reasoning in setting forth its conclusion of obviousness. As MPEP 2142 states, it is well-settled that "impermissible hindsight must be avoided and the legal conclusion must be reached on the basis of the facts gleaned from the prior art." But even if one assumed some rational basis for the proffered combination of references, the Office Action fails to explain how the proposed combination would operate to reduce fraud in the context of Lu, because Lu does not rely on use of an ID, so use of an mDL would not seem to improve upon any of the authentication mechanisms disclosed in Lu; thus, there is not any reasonable expectation of success in further reducing fraud from the proposed Lu-Aabye combination.” [Applicant’s Remarks, 12/19/2025, page ]
In response to applicant's argument that the examiner's conclusion of obviousness is based upon improper hindsight reasoning, it must be recognized that any judgment on obviousness is in a sense necessarily a reconstruction based upon hindsight reasoning. But so long as it takes into account only knowledge which was within the level of ordinary skill at the time the claimed invention was made, and does not include knowledge gleaned only from the applicant's disclosure, such a reconstruction is proper. See In re McLaughlin, 443 F.2d 1392, 170 USPQ 209 (CCPA 1971).
In response to Applicant’s assertion that there would be no reasonable expectation of success in combining Lu with Aabye because Lu does not rely on the use of an ID, it is noted that the clam broadly recites determining an authority verification result based on a digital token, not the verification of a mobile driver’s license itself, and the digital token is taught by a separate reference. As discussed in the Office action, Aabye teaches using ID related information for authorization decisions, and Lu teaches determining whether a user is authorized to perform a delegated action. One of ordinary skill in the art would have reasonably expected that incorporating token-based authorization techniques into Lu’s delegation framework would operate as claimed, with predictable results. Accordingly, Applicant has not demonstrated that the applied combination lack a reasonable expectation of success.
12. Applicant’s remaining arguments either logically depend from the above-rejected arguments, in which case they too are unpersuasive for the reasons set forth above, or they are
directed to features which have been newly added via amendment. Therefore, this is now the Examiner's first opportunity to consider these limitations and as such any arguments regarding these limitations would be inappropriate since they have not yet been examined. A full rejection of these limitations will be presented later in this Office Action.
Claim Rejections - 35 USC § 101
13. 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.
14. Claims 1-2, 7-10, and 15-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-patentable subject matter. The claims are directed to an abstract idea without significantly more.
15. Claims 1-2, 7-10, and 15-17 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more. The eligibility analysis in support of these findings is provided below, in accordance with MPEP 2106.
With respect to Step 1 of the eligibility inquiry (as explained in MPEP 2106), it is first noted that the method (claims 1-2, 7-8), apparatus (claims 9-10, 15-16), and computer-program product (claim 17) are directed to at least one potentially eligible category of subject matter (i.e., process, machine, and article of manufacture, respectively). Thus, Step 1 of the Subject Matter Eligibility test for claims 1-2, 7-10, and 15-17 is satisfied.
With respect to Step 2A Prong One, it is next noted that the claims recite an abstract idea that falls into the “Certain Methods of Organizing Human Activity” abstract idea set forth in MPEP 2106 because the claims recite steps for managing user tasks, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), and also falls into the “Mental Processes” abstract idea grouping by reciting concepts performed in the human mind such as via observation, evaluation, and judgment. With respect to independent claim 1, the limitations reciting the abstract idea are indicated in bold below: receiving, by communications hardware, an authority delegation request from a first user device associated with a first user, wherein the authority delegation request comprises a delegation parameter set; determining, by a user delegation circuitry and based on the delegation parameter set, a delegated action; storing, by the user delegation circuitry, the delegated action in a user authority delegation profile associated with the first user; receiving, by the communications hardware, an authority verification request from a second user device associated with a second user, wherein the authority verification request comprises at least an indication of a mobile driver's license (mDL) associated with a third user and an indication of the delegated action; generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL; determining, by a user authentication circuitry and based on the digital token, an authority verification result identifying whether the third user is authorized to perform the delegated action; and causing, by the communications hardware and based on the authority verification result, transmission of an indication of the authority verification result to the second user device. These steps describe managing personal behavior or relationships or interactions (e.g., social activities, following rules or instructions) and are organizing human activity because the limitations are directly tied to managing delegation and authorization, and include mental processes (evaluating and determining permissions). Independent claims 9 and 17 recite similar limitations as those recited in claim 1 and therefore are found to recite the same abstract idea(s) as claim 1.
Therefore, because the limitations above set forth activities falling within the “Certain methods of organizing human activity” abstract idea grouping described in the 2019 PEG, the additional elements recited in the claims are further evaluated, individually and in combination, under Step 2A Prong Two and Step 2B below.
With respect to Step 2A Prong Two, the judicial exception is not integrated into a practical application. With respect to the independent claims, the additional elements are: communications hardware, a first user device, a user delegation circuitry, a second user device, a mobile driver's license, mDL management circuitry, a digital token comprising cryptographic information, and a user authentication circuitry (claim 1), communications hardware configured, a first user device, user delegation circuitry, a second user device, a mobile driver's license, the apparatus, mDL management circuitry, a digital token comprising cryptographic information, and user authentication circuitry (claim 9), a non-transitory computer-readable storage medium storing instructions, an apparatus, a first user device, a second user device, a mobile driver's license, and a digital token comprising cryptographic information (claim 17). These additional elements have been evaluated, but fail to integrate the abstract idea into a practical application because they amount to using generic computing elements or computer-executable instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment. See MPEP 2106.05(f) and 2106.05(h). Even if the “causing transmission” step is not deemed part of the abstract idea, this step is at most directed to insignificant extra-solution activity, which is not sufficient to amount to a practical application. See MPEP 2106.05(g). In addition, these limitations fail to provide an improvement to the functioning of a computer or to any other technology or technical field, fail to apply the exception with a particular machine, fail to apply the judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, fail to effect a transformation of a particular article to a different state or thing, and fail to apply/use the abstract idea in a meaningful way beyond generally linking the use of the judicial exception to a particular technological environment.
Accordingly, because the Step 2A Prong One and Prong Two analysis resulted in the conclusion that the claims are directed to an abstract idea, additional analysis under Step 2B of the eligibility inquiry must be conducted in order to determine whether any claim element or combination of elements amount to significantly more than the judicial exception.
With respect to Step 2B of the eligibility inquiry, it has been determined that the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. With respect to the independent claims, the additional elements are: communications hardware, a first user device, a user delegation circuitry, a second user device, a mobile driver's license, mDL management circuitry, a digital token comprising cryptographic information, and a user authentication circuitry (claim 1), communications hardware configured, a first user device, user delegation circuitry, a second user device, a mobile driver's license, the apparatus, mDL management circuitry, a digital token comprising cryptographic information, and user authentication circuitry (claim 9), a non-transitory computer-readable storage medium storing instructions, an apparatus, a first user device, a second user device, a mobile driver's license, and a digital token comprising cryptographic information (claim 17). These elements have been considered individually and in combination, but fail to add significantly more to the claims because they amount to using generic computing elements or instructions (software) to perform the abstract idea, similar to adding the words “apply it” (or an equivalent), which merely serves to link the use of the judicial exception to a particular technological environment and does not amount to significantly more than the abstract idea itself. Notably, Applicant’s Specification suggests that virtually any type of computing device under the sun can be used to implement the claimed invention (Specification at paragraph [0022]). Accordingly, the generic computer involvement in performing the claim steps merely serves to generally link the use of the judicial exception to a particular technological environment, which does not add significantly more to the claim. See, e.g., Alice Corp., 134 S. Ct. 2347, 110 USPQ2d 1976.).
Even if the “causing transmission” step is not deemed part of the abstract idea, this step is at most directed to insignificant extra-solution activity, which has been recognized as well-understood, routine, and conventional, and thus insufficient to add significantly more to the abstract idea. See MPEP 2106.05(d) 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); 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 addition, when taken as an ordered combination, the ordered combination adds nothing that is not already present as when the elements are taken individually. There is no indication that the combination of elements integrate the abstract idea into a practical application. Their collective functions merely provide generic computer implementation. Therefore, when viewed as a whole, these additional claim elements do not provide meaningful limitations to transform the abstract idea into a practical application of the abstract idea or that, as an ordered combination, amount to significantly more than the abstract idea itself.
Dependent claims 2, 7-8, 10, and 15-16 a recite the same abstract idea as recited in the independent claims, and when evaluated under Step 2A Prong One are found to merely recite details that serve to narrow the same abstract idea recited in the independent claims accompanied by the same generic computing elements or software as those addressed above in the discussion of the independent claims, which is not sufficient to amount to a practical application or add significantly more, or other additional elements that fail to amount to a practical application or add significantly more, as noted above. In particular, dependent claims 2 and 7-8 recite “further comprising: receiving an authentication request from the first user, wherein the authentication request comprises authentication data associated with at least the first user; determining, based on the authentication request, a successful authentication result; and establishing, an authenticated session with the first user, wherein the authority delegation request is received during the authenticated session,” “further comprising: in an instance in which the authority verification request does not comprise the indication of the DL: determining the authority verification result based on a standard method of verification,” “further comprising: in response to a successful authority verification result, transmitting a completed action notification to the first user,” however these limitations cover organizing human activity since they flow directly from the delegation management involving human interaction, which encompasses activity for managing personal behavior or relationships or interactions (e.g., following rules or instructions), which is part of the same abstract idea as addressed in the independent claims that falls within the “Certain Methods of Organizing Human Activity” abstract idea grouping, and also falls within the “Mental Processes” abstract idea grouping. Accordingly, these steps are part of the same abstract idea(s) set forth in the independent claims. Dependent claims 10, 15 and 16 have been fully considered as well however, similar to claims 2 and 7-8, the elements set forth in these claims describe steps/details falling within the same “Certain Methods of Organizing Human Activity” and “Mental Processes” abstract idea groupings as described by independent claims 1/9/17. The additional elements recited in the dependent claims include: the communications hardware, the first user device, the user authentication circuitry, the user authentication circuitry (claim 2), the mDL, the user authentication circuitry (claim 7), the communications hardware, the first user device (claim 8), communications hardware, the first user device, the user authentication circuitry (claim 10), the user authentication circuitry and the mDL (claim 15), the communications hardware and the first user device (claim 16). However, these elements are recited at a high level of generality and fail to yield any discernible improvement to the computer or to any technology, nor set forth any additional function or result that provided meaningful limitation beyond linking the abstract idea to a particular technological environment (i.e., automated/computing environment), and thus fail to integrate the abstract idea into a practical application. When evaluated under Step 2A Prong Two and Step 2B, these additional elements do not amount to a practical application or significantly more since they merely require generic computing devices (or computer-implemented instructions/code) which as noted in the discussion of the independent claims above is not enough to render the claims as eligible.
The ordered combination of elements in the dependent claims (including the limitations inherited from the parent claim(s)) add nothing that is not already present as when the elements are 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 generic computer implementation. Accordingly, the subject matter encompassed by the dependent claims fails to amount to a practical application or significantly more than the abstract idea itself.
For more information, see MPEP 2106.
Claim Rejections - 35 USC § 103
16. In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
17. 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 of this title, 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.
18. 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.
19. This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
20. Claims 1-4, 7-12, and 15-18 are rejected under 35 U.S.C. 103 as being unpatentable over Lu et al., Pub. No.: US 2014/0020051 A1, [hereinafter Lu], in view of Aabye et al., Pub. No.: US 2023/0308295 A1, [hereinafter Aabye], in further view of Lovelock et al., Pub. No.: US 2016/0380774 A1 [hereinafter Lovelock].
As per claim 1, Lu teaches a method for verifying a delegate, the method (paragraphs 0001, 0011, 0073) comprising:
receiving, by communications hardware, an authority delegation request from a first user device associated with a first user, wherein the authority delegation request comprises a delegation parameter set (paragraph 0002, discussing that delegation is the process of an identified entity, called delegator, giving a mandate or a delegation assertion to another identified entity, called delegatee. The delegatee receives the privilege to act on behalf of the delegator at a service provider, who provides services to a requester; paragraph 0036, discussing that the method may comprise associating a delegation invocation step with a user authentication step wherein the delegatee may request to login at the service provider, which delegates the user authentication to the identity provider; the identity provider may authenticate the delegatee; paragraph 0020);
determining, by a user delegation circuitry and based on the delegation parameter set, a delegated action (paragraph 0034, discussing a method for providing user-to-user delegation service in federated identity environment, characterized in that it comprises a delegation or assignment step wherein a delegator specifies said delegation at an identity provider for delegating a privilege or task to a delegatee to be performed at a service provider; paragraph 0073);
storing, by the user delegation circuitry, the delegated action in a user authority delegation profile associated with the first user (paragraph 0036, discussing that the method may comprise associating a delegation invocation step with a user authentication step wherein the delegatee may request to login at the service provider, which delegates the user authentication to the identity provider; the identity provider may authenticate the delegatee, and if the authentication step is successful and if the identity provider finds delegations for the delegatee, the delegatee is able to choose which delegation to perform; paragraph 0073, discussing that in the delegation invocation, the method comprises the following steps: the delegatee logs in to the SP (service provider), which is redirected to the IdP. The IdP then verifies the delegatee's identity. The IdP (Identity provider) finds delegation(s) for the delegatee at the SP and asks him if he wants to login as himself or as a delegatee and for which delegator. The delegatee then selects login as a delegatee and specifies the delegator. The IdP generates an authentication assertion for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegatee. If all is well, the SP presents services to let the delegatee to perform the delegated tasks; claim 6: “wherein a delegation policy is in a metadata stored in the service provider”; paragraphs 0075, 0085);
receiving, by the communications hardware, an authority verification request from a second user device associated with a second user, wherein the authority verification request comprises at least an indication associated with a third user and an indication of the delegated action (paragraph 0073, discussing that in the delegation invocation, the method comprises the following steps: the delegatee logs in to the SP (service provider), which is redirected to the IdP. The IdP then verifies the delegatee's identity. The IdP finds delegation(s) for the delegatee at the SP and asks him if he wants to login as himself or as a delegatee and for which delegator. The delegatee then selects login as a delegatee and specifies the delegator. The IdP generates an authentication assertion for the delegatee with a delegation attribute statement specifying delegator, privileges, and other constraints. The IdP then sends the authentication assertion to the SP. The SP verifies the authentication assertion and the delegation statement and consults with its access control engine for both the delegator and delegate; paragraph 0074, discussing that the IdP generates an authentication assertion in response to the authentication request from the SP. The subject in the assertion is the delegatee. The assertion in addition includes an attribute statement about the delegation);
determining, by a user authentication circuitry and based on the indication, an authority verification result identifying whether the third user is authorized to perform the delegated action (paragraph 0036, discussing that the method may comprise associating a delegation invocation step with a user authentication step wherein the delegatee may request to login at the service provider, which delegates the user authentication to the identity provider; the identity provider may authenticate the delegatee, and if the authentication step is successful and if the identity provider finds delegations for the delegatee, the delegatee is able to choose which delegation to perform; paragraphs 0075-0082, discussing that the SP must process the delegation information, verifies the delegation statement, and consult with its access control engine to decide if it should provide the requested services. Specifically, the SP verifies the following steps: the delegation is in the valid period, the service request is specified in the statement, the requester is the delegatee specified in the statement, the signature of the assertion is valid and the certificate is not revoked, the delegator is authorized to perform the delegated privileged task, the delegator is authorized to delegate the privileged task, the delegatee has the privilege to perform the delegated task; paragraph 0133, discussing that the delegation statement in the authentication assertion provided by the IdP is not an authorization of delegation. Instead the IdP vouches that the delegator indeed has delegated some tasks to the delegatee. It is the service provider's responsibility to consult its access control engine to decide if the delegatee should be authorized to receive the requested services, and to record the transaction; paragraph 0086); and
causing, by the communications hardware and based on the authority verification result, transmission of an indication of the authority verification result to the second user device (paragraph 0047, discussing that the delegation allows a user A to delegate some of his privileges at a service provider (SP) to a user B. The delegation service includes delegation assignment, delegation invocation, and delegation revocation. The identity provider (IdP) acts as the delegation authority that manages delegations. The delegator assigns delegations at the IdP. The delegatee is to perform the delegated tasks at the specified service provider (SP). The SP obtains delegation assertions from the IdP; paragraph 0111, discussing that once the delegatee is then informed of the delegation assignment either by the delegator or by the identity provider, the delegatee examines the delegation, for example, from the received information or the IdP provides a service for the delegatee to do so. The request to the SP by the delegatee to perform the delegated tasks is a form of delegation acceptance. The IdP may also provide a service for the delegatee to explicitly accept the delegation; paragraph 0036).
Lu does not explicitly teach wherein the authority verification request comprises at least an indication of a mobile driver's license (mDL) associated with a third user; generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL; and determining, by a user authentication circuitry and based on the digital token, an authority verification result. Aabye in the analogous art of authentication systems teaches:
wherein the authority verification request comprises at least an indication of a mobile driver's license (mDL) associated with a third user and an indication of the delegated action (paragraph 0007, discussing a method performed by a relying party computer associated with a relying party. The method comprises receiving, from a certification authority, a certification authority public key and receiving, from a user device, a digital license issued by an issuing authority. The digital license includes a digital certificate signed by the certification authority using a certification authority private key. The certification authority private key is paired with the certification authority public key. The method also includes verifying the certificate using a certification authority public key. The certificate includes an issuing authority public key. The method further includes verifying information contained in the digital license using the issuing authority public key; paragraph 0043, discussing that the user may present the digital license to a relying party as part of an interaction with the relying party. For example, the user may wish to gain access to a location (e.g., a concert venue, a foreign country, a secure building) managed by the relying party, that requires a certain set of credentials (e.g., a ticket, a vaccination record, a passport, an identity card). In other embodiments, the user may present the digital license as a proof of authorization (e.g., a digital driver’s license). The relying party may receive a public key of the certification authority (CA public key) from the certification authority. Upon receiving the digital license associated with the digital certificate, the relying party may decrypt the digital certificate using the CA public key to obtain the information contained therein. For example, the issuing authority public key (IA public key) may be embedded in the digital certificate. The relying party may retrieve the IA public key, decrypt the digital license using the IA public key, and obtain the information in the digital license. The relying party may trust the veracity and accuracy of the information retrieved from the digital license because the relying party trusts the certification authority. The digital certificate issued by the certification authority may in turn vouches for the identity of the issuing authority. Therefore, the relying part may trust the veracity and accuracy of the information retrieved from the digital license; paragraph 0066, discussing that FIG. 2 illustrates another diagram for issuing and verifying a digital license according to various embodiments. The issuing authority may be vetted (e.g., authenticated, verified) by a certification authority. According to an exemplary embodiment, the digital license may be a mobile driver’s license (mDL). As such, FIG. 2 may illustrate a method of generating and/or verifying a user’s mDL data provided to a relying party by the user and/or the mDL); and
determining, by a user authentication circuitry, an authority verification result (paragraph 0043, discussing that the user may present the digital license to a relying party as part of an interaction with the relying party. For example, the user may wish to gain access to a location (e.g., a concert venue, a foreign country, a secure building) managed by the relying party, that requires a certain set of credentials (e.g., a ticket, a vaccination record, a passport, an identity card). In other embodiments, the user may present the digital license as a proof of authorization (e.g., a digital driver’s license). The relying party may receive a public key of the certification authority (CA public key) from the certification authority. Upon receiving the digital license associated with the digital certificate, the relying party may decrypt the digital certificate using the CA public key to obtain the information contained therein. For example, the issuing authority public key (IA public key) may be embedded in the digital certificate. The relying party may retrieve the IA public key, decrypt the digital license using the IA public key, and obtain the information in the digital license. The relying party may trust the veracity and accuracy of the information retrieved from the digital license because the relying party trusts the certification authority. The digital certificate issued by the certification authority may in turn vouches for the identity of the issuing authority. Therefore, the relying part may trust the veracity and accuracy of the information retrieved from the digital license; paragraph 0066, discussing that FIG. 2 illustrates another diagram for issuing and verifying a digital license according to various embodiments. The issuing authority may be vetted (e.g., authenticated, verified) by a certification authority. According to an exemplary embodiment, the digital license may be a mobile driver’s license (mDL). As such, FIG. 2 may illustrate a method of generating and/or verifying a user’s mDL data provided to a relying party by the user and/or the mDL; paragraph 0069, discussing that the relying party may be a merchant that needs to check the age of a user prior to providing goods or services to the user. When the user presents the user device to a terminal of the relying party, the mobile driver’s license sends the digital certificate to the relying party computer. The digital certificate may be of any suitable format such as X.509 format which includes, among other things: a certificate version number, a serial number, an issuer name, a validity period, subject public key information, and a signature; paragraph 0070, discussing that the relying party computer may detect (e.g., through an identifier on the card) that the mobile driver’s license is associated with the certification authority, and retrieve the CA public key. The relying party computer may use the CA public key to verify that the IA public key was signed by the CA private key. The relying party computer then extracts the IA public key from the digital certificate, and may verify that the digital license was signed using the private key of the IA. If the verification is successful, the relying party computer may now trust that the issuing authority is legitimate as it has been authenticated by the trusted certification authority. In some cases, the relying party computer may also contact the certification authority to determine if the details of the digital certificate are still valid; paragraph 0075).
Lu is directed to a delegation framework. Aabye relates to an authentication system. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Lu with Aabye because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying Lu to include Aabye’s features for including wherein the authority verification request comprises at least an indication of a mobile driver's license (mDL) associated with a third user; and determining, by a user authentication circuitry, an authority verification result, in the manner claimed, would serve the motivation of benefiting from reduced fraud (Aabye at paragraph 0076); and further obvious because 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 Lu-Aabye combination does not explicitly teach generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL; and determining, by a user authentication circuitry and based on the digital token, an authority verification result. However, Lovelock in the analogous art of virtualized credential systems teaches this concept. Lovelock teaches:
generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL (paragraph 0008, discussing that providing virtualized credentials of a holder includes authorizing a subset of credential data to be sent to a device of a relying party that is different from the holder, where the subset of credential data depends on a role of the relying party and/or contextual data of the relying party and includes displaying the subset of credential data on a screen of the device of the relying party. The credential data may correspond to a license of the holder. The license may be a driver's license. The credential data may include insurance information of the holder...The credential data may be provided by a device of the holder. The device of the holder may communicate directly with the device of the relying party. The credential data may be stored in a cloud and the subset of credential data may be sent from the cloud to the device of the relying party. The relying party may receive a release from the holder (possibly in the form of an access token) that allows the relying party to view the subset of credential data and/or access credential data from the cloud or some other source. An issuing authority that issues the virtualized credentials may filter information about the holder that is released to the relying party. The information may be filtered according to filtering rules stored by the issuing authority or the holder; paragraph 0014); and
determining, by a user authentication circuitry and based on the digital token, an authority verification result (paragraph 0008, discussing that providing virtualized credentials of a holder includes authorizing a subset of credential data to be sent to a device of a relying party that is different from the holder, where the subset of credential data depends on a role of the relying party and/or contextual data of the relying party and includes displaying the subset of credential data on a screen of the device of the relying party. The credential data may correspond to a license of the holder. The license may be a driver's license. The credential data may include insurance information of the holder...The credential data may be provided by a device of the holder. The device of the holder may communicate directly with the device of the relying party. The credential data may be stored in a cloud and the subset of credential data may be sent from the cloud to the device of the relying party. The relying party may receive a release from the holder (possibly in the form of an access token) that allows the relying party to view the subset of credential data and/or access credential data from the cloud or some other source. An issuing authority that issues the virtualized credentials may filter information about the holder that is released to the relying party. The information may be filtered according to filtering rules stored by the issuing authority or the holder; paragraph 0039, discussing that a mobile device includes a cryptograph key that is securely provisioned in the mobile device. The mobile device may be used by a license holder in connection with the system described herein. The cryptographic key may be a symmetric key or part of an asymmetric private/public key pair. The mobile device also includes license data that contains information for license(s)/credentials provided with the mobile device. The license data may include one or more visual images of the license holder that are displayed on the mobile device as well as information and/or graphical images for indicating information associated with the license(s)/credentials, such as date of birth, specific authorizations, etc.; paragraph 0041, discussing that the cryptographic key may be used (e.g., by the mobile device) to generate a cryptogram that validates the license dat. In an embodiment herein, a relying party may use the cryptogram to ensure that the license holder is presenting valid data.).
The Lu-Aabye combination describes features related to delegation verification and authentication. Lovelock relates to the field of providing virtualized credentials. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Lu-Aabye combination with Lovelock because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye combination to include Lovelock’s features for including generating, by mDL management circuitry and based on the indication of the mDL, a digital token comprising cryptographic information associated with the mDL, in the manner claimed, would serve the motivation of providing a license/credential that reduces the dissemination of unnecessary information (Lovelock at paragraph 0005); and further obvious because 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.
As per claim 2, the Lu-Aabye-Lovelock combination teaches the method of claim 1. Lu further teaches further comprising: receiving, by the communications hardware, an authentication request from the first user device, wherein the authentication request comprises authentication data associated with at least the first user or the first user device (paragraph 0011, discussing that access controls are security mechanisms that control how subjects, such as users, applications, and systems access and interact with objects, such as resources, other applications and systems. Access control includes identification, authentication, authorization, and accountability. All organizations and their systems or services must have access control policies and implementations to protect their resources and systems from unauthorized access; paragraph 0022, discussing that an SAML assertion in response to the authentication request from IdP includes the same subject NameID and subject confirmation as in the first authentication statement and a condition that has a Delegate element with the NameID as the portal; paragraph 0036, discussing that the method may comprise associating a delegation invocation step with a user authentication step wherein the delegatee may request to login at the service provider, which delegates the user authentication to the identity provider; the identity provider may authenticate the delegate; paragraph 0062, discussing that ,a delegator always delegates all his privileges to a delegatee at a service provider, that is, the delegator allows the delegatee to login to the service provider as the delegator. For example, the delegator can give his login credentials, such as username/password or smart card/PIN, to the delegatee at the SP);
determining, by the user authentication circuitry and based on the authentication request, a successful authentication result (paragraph 0036, discussing that the method may comprise associating a delegation invocation step with a user authentication step wherein the delegatee may request to login at the service provider, which delegates the user authentication to the identity provider; the identity provider may authenticate the delegatee, and if the authentication step is successful and if the identity provider finds delegations for the delegatee, the delegatee is able to choose which delegation to perform); and
establishing, by the user authentication circuitry, an authenticated session with the first user, wherein the authority delegation request is received during the authenticated session (paragraph 0005-0009, discussing that a delegation is the act of temporarily or permanently transferring privileges from one entity to another; a delegator is the entity that transfers, i.e. delegates all or a subset of its privileges to a Delegatee; a delegatee is the entity that receives all or a subset of the delegator's privileges in order to use them on the delegator's behalf; a delegation assertion is an assertion of the correctness and authority for a delegation, issued by a Delegation Authority to a delegate; a delegation authority or mandate authority is an entity that controls delegation and issues delegation assertions; paragraphs 0015-0017, discussing that the granting delegation allows the delegated privileges to be available to both the delegator and the delegatee after a successful delegation operation. The transfer delegation transfers the delegated privileges to the delegatee after a successful delegation. Those privileges are no longer available to the delegator. The RBAC system must manage the delegation based on the access control policies. In doing so, it must answer the following two questions: Is a delegator authorized to delegate a role, privilege, or permission that is available to him? Can a role, privilege, or permission be delegated to a delegate?; paragraph 0047, discussing that the delegation allows a user A to delegate some of his privileges at a service provider (SP) to a user B. The delegation service includes delegation assignment, delegation invocation, and delegation revocation. The identity provider (IdP) acts as the delegation authority that manages delegations. The delegator assigns delegations at the IdP. The delegatee is to perform the delegated tasks at the specified service provider (SP). The SP obtains delegation assertions from the IdP; paragraph 0086, discussing that for the delegation assignment, a delegator wants to delegate some tasks to a delegatee, to be done at a SP. The IdP does not know what privileges that the delegator can delegate. The IdP's role is to manage the delegation and to tell the SP that the delegator indeed has delegated certain privileges to the delegatee. The SP must exercise the access control, that is, to ensure that the delegator has and can delegate these privileges and the delegatee is authorized to perform the tasks; paragraph 0075).
As per claim 3, the Lu-Aabye-Lovelock combination teaches the method of claim 1. Although not explicitly taught by the Lu-Aabye combination, Lovelock in the analogous art of virtualized credential systems teaches further comprising: transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL (paragraph 0010, discussing that the credential data may be stored in a cloud and the subset of credential data may be sent from the cloud to the device of the relying party. The relying party may receive a release from the holder (possibly in the form of an access token) that allows the relying party to view the subset of credential data and/or access credential data from the cloud or some other source. An issuing authority that issues the virtualized credentials may filter information about the holder that is released to the relying party. The information may be filtered according to filtering rules stored by the issuing authority or the holder; paragraph 0036, discussing that a flow diagram 400 illustrates steps performed in connection with the communications/cloud infrastructure providing information to a relying party. Processing begins at a first step where a request is received. In some embodiments, the relying party requests the information from a license holder so the request received is from the relying party. In other embodiments, the request may be provided by the license holder to send the information to the relying party so that the request received is from the license holder. In either case, the request may include one or more tokens); and
receiving, by the communications hardware and from the IA system, a mDL validity response, wherein the mDL validity response indicates credential data associated with the mDL (paragraph 0014, discussing that the system may use the cloud to translate identity of a user with an associated license. An id may include a virtual identity from a licensing board that also indicates where to retrieve an actual license, and any required access method information. Input of the user optionally includes a release from the providing party (possibly in the form of an access token) to allow the relying party to read the license/insurance data and/or access the license/insurance data from the cloud or possibly some other source. The id and associated data may include an encrypted dynamic element to prevent a replay attack; paragraph 0037, discussing that in instances where an identity is indirectly tied to the license holder, an external database may map a token to the identity of the license holder. The external database/data used for mapping may be separate from any other database/data containing personal information about the license holder…The token(s) are matched by the infrastructure to information for the license holder and/or the relying party. In some cases, the token(s) may indicate where to retrieve the requested license information and possibly required access information (i.e., credentials for remote systems that are accessed). Following…it is determined if the request is authorized…It may be necessary for the license holder to provide authorization in the form of a password, fingerprint, etc. In some cases, the license holder may need to provide a release (possibly in the form of an access token) to authorize the relying party to read the license information and/or access license information from the cloud, including possibly information about insurance. Note that authorization may include having the relying party present their device to the license holder who then provides a password, a fingerprint, etc. to the device of the relying party).
The Lu-Aabye combination describes features related to delegation verification and authentication. Lovelock relates to the field of providing virtualized credentials. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Lu-Aabye combination with Lovelock because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye combination to include Lovelock’s features for including transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL, and receiving, by the communications hardware and from the IA system, a mDL validity response, wherein the mDL validity response indicates credential data associated with the mDL, in the manner claimed, would serve the motivation of providing a license/credential that reduces the dissemination of unnecessary information (Lovelock at paragraph 0005); and further obvious because 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.
As per claim 4, the Lu-Aabye-Lovelock combination teaches the method of claim 3. Although not explicitly taught by the Lu-Aabye combination, Lovelock in the analogous art of virtualized credential systems teaches wherein the indication of the mDL comprises one or more of cryptographical information associated with the mDL, cryptographical information associated with a user device to which the mDL corresponds, desired credential data associated with the mDL, location data, user profile data, user account data, social media data, or smart wallet identification data (paragraph 0008, discussing that providing virtualized credentials of a holder includes authorizing a subset of credential data to be sent to a device of a relying party that is different from the holder, where the subset of credential data depends on a role of the relying party and/or contextual data of the relying party and includes displaying the subset of credential data on a screen of the device of the relying party. The credential data may correspond to a license of the holder. The license may be a driver's license. The credential data may include insurance information of the holder...The credential data may be provided by a device of the holder. The device of the holder may communicate directly with the device of the relying party. The credential data may be stored in a cloud and the subset of credential data may be sent from the cloud to the device of the relying party. The relying party may receive a release from the holder (possibly in the form of an access token) that allows the relying party to view the subset of credential data and/or access credential data from the cloud or some other source. An issuing authority that issues the virtualized credentials may filter information about the holder that is released to the relying party. The information may be filtered according to filtering rules stored by the issuing authority or the holder; paragraph 0039, discussing that a mobile device includes a cryptograph key that is securely provisioned in the mobile device. The mobile device may be used by a license holder in connection with the system described herein. The cryptographic key may be a symmetric key or part of an asymmetric private/public key pair. The mobile device also includes license data that contains information for license(s)/credentials provided with the mobile device. The license data may include one or more visual images of the license holder that are displayed on the mobile device as well as information and/or graphical images for indicating information associated with the license(s)/credentials, such as date of birth, specific authorizations, etc.; paragraph 0041, discussing that the cryptographic key may be used (e.g., by the mobile device) to generate a cryptogram that validates the license dat. In an embodiment herein, a relying party may use the cryptogram to ensure that the license holder is presenting valid data.).
The Lu-Aabye combination describes features related to delegation verification and authentication. Lovelock relates to the field of providing virtualized credentials. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Lu-Aabye combination with Lovelock because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye combination to include Lovelock’s feature for including wherein the indication of the mDL comprises one or more of cryptographical information associated with the mDL, cryptographical information associated with a user device to which the mDL corresponds, desired credential data associated with the mDL, location data, user profile data, user account data, social media data, or smart wallet identification data, in the manner claimed, would serve the motivation of providing a license/credential that reduces the dissemination of unnecessary information (Lovelock at paragraph 0005); and further obvious because 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.
As per claim 7, the Lu-Aabye-Lovelock combination teaches the method of claim 1. Lu further teaches further comprising: in an instance in which the authority verification request does not comprise the indication of the mDL: determining, by the user authentication circuitry, the authority verification result based on a standard method of verification (paragraph 0114, discussing that SAML protocol is a request and response protocol. The requester sends a request, and the responder processes the request and sends a response. SAML 2.0 standard is used to format the delegation request and response; paragraph 0136, discussing that the delegator can digitally sign the delegation (mandate) providing non-repudiation. The Identity Provider manages delegations for all service providers who have registered with the IdP and expressed permission and policies of delegation in their metadata. Standard protocols are used between IdP and SPs, such as SSL/TLS, SAML, and SACML. Service providers have to authorize any delegations. The IdP can get authorization from service providers before creating mandates. Non-repudiation is provided by digital signature. The delegator can specify constraints, such as valid period).
As per claim 8, the Lu-Aabye-Lovelock combination teaches the method of claim 1. Lu further teaches further comprising: in response to a successful authority verification result, transmitting, by the communications hardware, a completed action notification to the first user device (paragraph 0108, discussing that when a user's privileges are reduced or removed, the service provider should find out if there are outstanding delegations relevant to this user. If so, the SP needs to examine each of the delegations to see if they are still valid. If the user was a delegator and he no longer has privilege to delegate the task, or if the user was a delegatee and he no longer has the privilege to perform the delegated task, then the SP sends a revocation request to IdP to revoke the delegation. The IdP then informs the delegator and the delegate; paragraph 0111, discussing that once the delegatee is then informed of the delegation assignment either by the delegator or by the identity provider, the delegatee examines the delegation, for example, from the received information or the IdP provides a service for the delegatee to do so. The request to the SP by the delegatee to perform the delegated tasks is a form of delegation acceptance. The IdP may also provide a service for the delegatee to explicitly accept the delegation; paragraph 0114, discussing that the requester sends a request, and the responder processes the request and sends a response. SAML 2.0 standard is used to format the delegation request and response).
Claims 9 and 17 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 1, as discussed above. Further, as per claim 9 the Lu-Aabye-Lovelock combination teaches an apparatus for verifying a delegate, the apparatus comprising: communications hardware; user delegation circuitry, user authentication circuitry, and communications circuitry (Lu, paragraphs 0013-0014, 0024 and Aabye, paragraphs 0031, 0094, 0095). As per claim 17, the Lu-Aabye-Lovelock teaches a computer program product for verifying a delegate, the computer program product comprising a non-transitory computer-readable storage medium storing instructions (Aabye, paragraphs 0033, 0095, 0097).
Claim 10 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 2, as discussed above.
Claims 11 and 18 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 3, as discussed above.
Claim 12 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 4, as discussed above.
Claim 15 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 7, as discussed above.
Claim 16 recites substantially similar limitations that stand rejected via the art citations and rationale applied to claim 8, as discussed above.
21. Claims 5, 13, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Aabye, in view of Lovelock, in further view of Boyd, Pub. No.: US 2023/0367858 A1 [hereinafter Boyd].
As per claim 5, the Lu-Aabye-Lovelock combination teaches the method of claim 3. Lu further teaches further comprises: determining, by the user authentication circuitry, a metadata parameter set based on the authority verification request (paragraph 0039, discussing that a delegation policy may be in a metadata stored in the service provider, applicable to discretionary and role-based access control models, wherein during the assignment step, identity provider may check the delegation policy; paragraph 0059, discussing allowing service providers to exercise different types of access control and manage the complexities of using delegation accordingly. A service provider specifies if it allows delegation, and if it does, what delegation option does it supports, all inside a metadata; paragraph 0070, discussing that the service provider can express its delegation policy or a subset of the policy inside the metadata; paragraph 0071, discussing that the delegation Assignment comprises the following steps wherein the delegator first authenticates to the IdP. Then the delegator selects the SP that he wants to delegate some tasks. The IdP reads the delegation policy in the metadata of the SP and presents delegatable resources and actions, if any, to the delegator. The delegator specifies the delegatee, the tasks i.e. the resources and the actions, and other constraints, such as a validation period. The IdP creates a delegation. The IdP may also ask the delegator to digitally sign the delegation for non-repudiation. Then the delegator signs the delegation if required. The delegator or the IdP informs the delegatee about the delegation).
The Lu-Aabye-Lovelock combination does not explicitly teach determining, by the user authentication circuitry and using an authentication scoring model, an authentication score, wherein the authentication score is based on the mDL validity response and the metadata parameter set; comparing, by the user authentication circuitry, the authentication score to an authentication threshold; and determining, by the user authentication circuitry and based on the comparing, the authority verification result. However, Boyd in the analogous art of authentication systems teaches these concepts. Boyd teaches:
determining, by the user authentication circuitry and using an authentication scoring model, an authentication score, wherein the authentication score is based on the mDL validity response and the metadata parameter set (paragraph 0043, discussing that when a user desires to use a photograph other than that in the MIC (mobile identification credential) user information, the user may in an embodiment supply a different photograph referred to as candidate photograph. In this embodiment, the official photograph in the MIC user information is biometrically compared with the user-supplied photograph in the candidate photograph. If the candidate photograph matches the MIC user information to a set match threshold the candidate photograph may be designated as additional base truth information);
comparing, by the user authentication circuitry, the authentication score to an authentication threshold (paragraph 0043, discussing that when a user desires to use a photograph other than that in the MIC (mobile identification credential) user information, the user may in an embodiment supply a different photograph referred to as candidate photograph. In this embodiment, the official photograph in the MIC user information is biometrically compared with the user-supplied photograph in the candidate photograph. If the candidate photograph matches the MIC user information to a set match threshold the candidate photograph may be designated as additional base truth information; paragraph 0046, discussing that when the processing associated with performing comparisons of candidate information may be implemented in different ways. In one embodiment, an APS (authorizing party system) may perform a threshold image comparison between the candidate photograph and the verified MIC user information photograph of the user (the official photograph associated with the MIC). In another embodiment, the user's UMD performs the threshold image comparison between the candidate photograph and the MIC user information photograph of the user. In yet another embodiment, the online host serving as the RPS (relying party system) performs the threshold image comparison between the candidate photograph and the MIC user information photograph of the user); and
determining, by the user authentication circuitry and based on the comparing, the authority verification result (paragraph 0047, discussing that upon favorable comparison results, the online host serving as the RPS treats the candidate photograph as a base truth photograph of the user. In other words, when the candidate photograph and the official photograph associated with the MIC match closely enough, to within a match threshold, the candidate photograph is determined to be a base truth photograph even if it is not identical to the official photograph, and becomes part of additional base truth information for the user to be used for future comparisons or verifications. Other information can qualify as base truth information, such as a user's date of birth or full name, or other MIC user information or other candidate information uploaded by the user. When the comparison results are not favorable (e.g., when the comparison does not meet a match threshold), embodiments may delete the hosted information that does not represent the user; paragraph 0089, discussing that if the comparison matches to within a threshold (e.g., based on image matching, facial recognition, or other techniques for identifying matches of the same user in photographs), the online host serving as the RPS verifies the matching photograph or photographs as genuinely representing the user).
The Lu-Aabye-Lovelock combination describes features related to delegation verification and authentication. Boyd relates to systems for verifying user information. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Lu-Aabye-Lovelock combination with Boyd because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye-Lovelock combination to include Boyd’s features for including determining, by the user authentication circuitry and using an authentication scoring model, an authentication score, wherein the authentication score is based on the mDL validity response and the metadata parameter set; comparing, by the user authentication circuitry, the authentication score to an authentication threshold; and determining, by the user authentication circuitry and based on the comparing, the authority verification result, in the manner claimed, would serve the motivation of avoiding potential misrepresentations or other inaccuracies regarding information submitted (Boyd at paragraph 0006); and further obvious because 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.
Claims 13 and 19 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 5, as discussed above.
22. Claims 6, 14, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Aabye, in view of Lovelock, in view of Boyd, in further view of Maleknejad, Pub. No.: US 2020/0336904 A1, [hereinafter Maleknejad].
As per claim 6, the Lu-Aabye-Lovelock-Boyd combination teaches the method of claim 5. Although not explicitly taught by the Lu-Aabye-Lovelock-Boyd combination, Maleknejad in the analogous art of authentication systems and methods teaches further comprising: in response to an unsuccessful authority verification result: transmitting, by the communications hardware, a supplemental verification request to the second user device (paragraph 0039, discussing that FIG. 3 is an example diagram showing how an application may use the systems and methods here for authentication of a user and approve some follow-on, extra, or additional task that is somehow outside the bounds of what the application normally accomplishes, or somehow requires additional authentication for sensitive procedures. For example, a user first utilizes the above systems and methods to access a third party application. While using the third party application, the user is presented with the option of some extra activity, for example, to take a picture with the mobile phone, purchase an item, share files, and/or make a phone call, or other task. Such a scenario may arise while utilizing the third party application but the third party application needs to utilize some other hardware, or requires some additional sensitive approval before proceeding. In such examples, a second round of authentication may be called, in order to ensure that the task or extra/additional request is authorized. In such examples, the term task is used to describe these extra, additional or other requests);
receiving, by the communications hardware, a completed supplemental verification request from the second user device (paragraph 0038, discussing that part of the workflow describes an optional initial authentication registration which may not occur after the initial registration has occurred. Such a registration may only happen if a user has not yet registered the mobile client on the authentication server that handles the authentication workflow for this specific third party application. In such initial authentication examples, the mobile client may then request the user to submit an email address or phone number. Those are the current methods to validate user's identity. Other sources of user identification may be used, such as but not limited to, ID cards or social security number in future. The user may then provide a mobile client with requested email address or phone number. The mobile client may then register the device at the mobile authentication server. The authentication server sends a confirmation email or text message to the user, via the mobile client. The user confirms the device registration to the authentication server via a response through the mobile client. The mobile authentication server notifies the mobile client that the device is registered. The mobile client saves the device registration…; paragraph 0039, discussing that FIG. 3 is an example diagram showing how an application may use the systems and methods here for authentication of a user and approve some follow-on, extra, or additional task that is somehow outside the bounds of what the application normally accomplishes, or somehow requires additional authentication for sensitive procedures. For example, a user first utilizes the above systems and methods to access a third party application. While using the third party application, the user is presented with the option of some extra activity, for example, to take a picture with the mobile phone, purchase an item, share files, and/or make a phone call, or other task. Such a scenario may arise while utilizing the third party application but the third party application needs to utilize some other hardware, or requires some additional sensitive approval before proceeding. In such examples, a second round of authentication may be called, in order to ensure that the task or extra/additional request is authorized. In such examples, the term task is used to describe these extra, additional or other request); and
determining, by the user authentication circuitry and based on the completed supplemental verification request, an updated authority verification result (paragraph 0039, discussing that FIG. 3 is an example diagram showing how an application may use the systems and methods here for authentication of a user and approve some follow-on, extra, or additional task that is somehow outside the bounds of what the application normally accomplishes, or somehow requires additional authentication for sensitive procedures. For example, a user first utilizes the above systems and methods to access a third party application. While using the third party application, the user is presented with the option of some extra activity, for example, to take a picture with the mobile phone, purchase an item, share files, and/or make a phone call, or other task. Such a scenario may arise while utilizing the third party application but the third party application needs to utilize some other hardware, or requires some additional sensitive approval before proceeding. In such examples, a second round of authentication may be called, in order to ensure that the task or extra/additional request is authorized. In such examples, the term task is used to describe these extra, additional or other request)
The Lu-Aabye-Lovelock-Boyd combination describes features related to delegation verification and authentication. Maleknejad relates to authentication systems and methods. Therefore, they are deemed to be analogous as they both are directed towards solutions for delegate verification and authentication systems. It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the Lu-Aabye-Lovelock-Boyd combination with Maleknejad because the references are analogous art because they are both directed to solutions for delegate verification and authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye-Lovelock-Boyd combination to include Maleknejad’s features for including in response to an unsuccessful authority verification result: transmitting, by the communications hardware, a supplemental verification request to the second user device; receiving, by the communications hardware, a completed supplemental verification request from the second user device; and determining, by the user authentication circuitry and based on the completed supplemental verification request, an updated authority verification result, in the manner claimed, would serve the motivation of standardizing delegating (Maleknejad at paragraph 0006); and further obvious because 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.
Claims 14 and 20 recite substantially similar limitations that stand rejected via the art citations and rationale applied to claim 6, as discussed above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Brickell et al., Pub. No.: US 2003/0145223 A1 – describes controlled access to credential information of delegators in delegation relationships.
Kruse et al., Patent No.: US 10,243,945 B1 – describes managing identity federation.
Sánchez García, Sergio, et al. "Solving identity delegation problem in the e-government environment." International Journal of Information Security 10.6 (2011): 351-372 – proposes a system of dynamic delegation of identity between two generic entities that can solve the problem of delegated access to the telematic services provided by public authorities.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. 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 extension fee 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 DARLENE GARCIA-GUERRA whose telephone number is (571) 270-3339. The examiner can normally be reached M-F 7:30a.m.-5:00p.m. 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, Brian M. Epstein can be reached on (571) 270-5389. 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.
/Darlene Garcia-Guerra/
Primary Examiner, Art Unit 3625