DETAILED ACTION
Notice to Applicant
The following is a NON-FINAL Office action upon examination of application number 18/777,037 filed on 07/18/2024, in response to Applicant’s Request for Continued Examination (RCE) filed on July 21, 2026. Claims 1-2, 4-10, 12-17, and 19-22 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 July 21, 2026, Applicant amended claims 1, 4-5, 9, 12-13, 17, and 19, and canceled claims 3, 11, and 18. New claims 21 and 22 were presented for examination.
Applicant's amendments to the claims are hereby acknowledged. The amendments are sufficient to overcome the previously issued claim rejection under 35 U.S.C. 101; accordingly, this rejection has been withdrawn.
Response to Arguments
Applicant's arguments filed July 21, 2026, have been fully considered.
Applicant submits “that the claims are nevertheless not "directed to" any allegedly recited judicial exception (Step 2A, Prong Two), and in any event that the claims amount to "significantly more" than any allegedly recited judicial exception (Step 2B). For compactness, the following remarks center on Step 2A, Prong Two, without acceding to the arguments presented in the Office Action related to Step 2A, Prong One or Step 2B. As an initial matter, amended claim 1 expressly recites a communications hardware to transmit a digital token to an IA system and receive a mDL validity response. For example, amended claim 1 recites "transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL and whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned." This limitation constitutes a concrete technical requirement, not a mental process or an organizational concept.” Applicant further submits “that the claims, at least as amended herein, are integrated into a practical application because they recite a specific, technology-based solution for securely verifying a purported delegate using (i) a cryptographically protected mobile driver's license (mDL), (ii) an authority-verification token derived from that mDL, and (iii) an IA system for a mDL validity response. The claims therefore do not merely "apply" an abstract concept on generic computers. Instead, they require receiving credential data associated with the mDL and indicating whether a user device associated with the mDL corresponds to the user device to which the mDL was originally provisioned; these steps produce a technical security improvement. For example, the IA system ensures that the purported delegate corresponds to the user device to which the mDL was originally provisioned. This provides a particular technical solution such that the third-party verifier (e.g., the second user) may be confident that the information (e.g., user verification data, such as the indication of the mDL) that is utilized to determine the ultimate authority verification result is associated with the purported delegate that the third-party verifier is currently interacting with. The amended claim therefore recites a technological improvement to the security of delegated-authority verification, not merely the automation of a mental process or business practice. Accordingly, the claims recite a particular practical application of any alleged abstract idea, and thus are eligible at Step 2A, Prong Two.” [Applicant’s Remarks, 07/21/2026, pages 10-11]
In response to the claim amendments filed July 21, 2026, the 35 U.S.C. §101 rejection applied to claims 1-2, 7-10, and 15-17 in the previous Office Action has been withdrawn. It is noted that the §101 rejection has been withdrawn based on the determination that, although the claims recite limitations that fall under the “Certain Methods of Organizing Human Activities” abstract idea grouping, the claims recite additional elements that, when evaluated under Step 2A Prong Two of the eligibility inquiry, integrate the judicial exception into a practical application.
Applicant submits “The applied references, singly or in any proper combination, do not disclose and would not have rendered obvious "transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL and whether the user device associated with the mDL corresponds to the user device to which the mDL was originally provisioned," as recited in amended independent claim 1.” [Applicant’s Remarks, 07/21/2026, page 12]
In response to the Applicant’s argument that “The applied references, singly or in any proper combination, do not disclose and would not have rendered obvious "transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL and whether the user device associated with the mDL corresponds to the user device to which the mDL was originally provisioned," as recited in amended independent claim 1,” it is noted that this argument is a mere allegation of patentability by the Applicant with no supporting rationale or explanation. Merely stating that the claims do not teach a feature does not offer any insight as to why the specific sections of the prior art relied upon by the Examiner fail to disclose the claimed features. Applicant's arguments amount to a general allegation that the claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. Moreover, the Examiner notes the limitations being argued by Applicant as being newly amended to the claims in the response filed 07/21/2026, which have been addressed in the updated rejection below. Applicant’s argument has been considered, but it pertains to amendments to independent claims 1, 9, and 17 that are believed to be addressed via the updated ground of rejection under §103 set forth in the instant Office action, which incorporates a new reference and new citations to address the amended limitations in claim 1 and supports a conclusion of obviousness of the amended claims.
8. 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 Objections
9. Claim 21 is objected to because of the following informalities: typographical error.
Newly presented claim 21 recites “The method of claim 1, generating the digital token comprises: creating a header comprising metadata of the digital token; creating a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token...” Claim 21 should recite “The method of claim 1, wherein generating the digital token comprises: creating a header comprising metadata of the digital token; creating a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token...” Appropriate correction is required.
Claim Rejections - 35 USC § 103
10. 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.
11. 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.
12. 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.
13. 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.
14. Claims 1-2, 4, 7-10, 12, 15-17, and 22 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 view of Lovelock et al., Pub. No.: US 2016/0380774 A1 [hereinafter Lovelock], in further view of Vitug Weber et al., Pub. No.: US 2024/0340285 A1, [hereinafter Vitug].
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; transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL and whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned; and determining, by a user authentication circuitry and based on the mDL validity response, 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; transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL; receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL and whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned; and determining, by a user authentication circuitry and based on the mDL validity resposne, 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);
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);
receiving, by the communications hardware and from the IA system, a mDL validity response indicating 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); 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, transmitting, by the communications hardware, the digital token to an issuing authority (IA) system associated with an IA that provisioned the mDL, receiving, by the communications hardware and from the IA system, a mDL validity response indicating credential data associated with the mDL, and determining, by a user authentication circuitry and based on the digital token, an authority verification result, 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.
The Lu-Aabye-Lovelock combination does not explicitly teach receiving a mDL validity response indicating whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned; and determining, based on the mDL validity response, an authority verification result. However, Vitug in the analogous art of acces verification systems teaches these concepts. Vitug teaches:
receiving a mDL validity response indicating whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned (paragraph 0013, discussing that a mobile device may be provisioned with a mobile ID by a mobile ID verifier system (e.g., a system associated with an entity that enrolls and verifies the identity of a user requesting the mobile ID), and the mobile ID may be stored by the mobile device and accessed via a mobile application. In some implementations, the mobile ID that is stored by and registered to the mobile device can then be leveraged to build a mobile ID association tree that can be used to control access that different users have to one or more shared services. For example, the mobile device may communicate with a mobile ID tree orchestration system to configure a mobile ID association tree that defines one or more user groups, where each user that is represented in the mobile ID association tree may be a holder of a mobile ID that is registered to a mobile device associated with the user. The one or more user groups can then be used to establish integrations with different shared or sharable services. For example, each group in the mobile ID association tree may be associated with one or more shared services that are accessible to each member of a corresponding group. In this way, the mobile ID association tree may provide a mechanism to connect users to shared services in a verified and configurable and centralized manner (e.g., a user may be added to a user group authorized to access a set of shared services, which may grant the user access to all of the shared services associated with the user group). Furthermore, the mobile IDs that are registered to the mobile devices are subject to robust identity verification, and can therefore provide a secure electronic identity document that can be used to verify the identity of a person requesting access to a shared service; paragraph 0016, discussing that a mobile ID is a secure, accurate, and interoperable digital or electronic representation of the information associated with an identity document and/or information relevant to state privileges, national context, international or global identification, and/or other identification contexts, which is generally provisioned onto a smart mobile device, such as a smartphone, a tablet, or a smart watch, for use by the proper holder of the mobile ID. For example, in some implementations described, a holder of a mobile ID may correspond to a user of the mobile device, and may refer to the legitimate owner of an identity associated with a digital-only mobile ID or a mobile ID that is a counterpart to a physical identity document; paragraph 0027, discussing that in order to use the mobile ID registered to the mobile device in a transaction or interaction to request access to a shared service, the mobile device may be presented to a mobile ID verifier system that then obtains information associated with the mobile ID registered to the mobile device. For example, the mobile device may be presented in an offline/transmit use case, where the mobile ID is securely stored on the mobile device and the mobile ID verifier system includes a kiosk device or is otherwise equipped to read the mobile ID from the mobile device. In this case, the mobile ID verifier system and/or kiosk device does not necessarily need to be connected or in an online state. For example, the mobile ID verifier system may request that the user of the mobile device transmit identity attributes over communication channels supported by the mobile device and the mobile ID verifier system, and the requested identity attributes associated with the mobile ID may be transmitted from the mobile device to the mobile ID verifier system over a secure encrypted channel along with a cryptographic signature from the mobile ID issuer system to prove that the data has not been altered. The reader can then check that the mobile ID was transmitted by the mobile device to which the mobile ID was originally provisioned. Additionally, or alternatively, the information associated with the mobile ID may be communicated to the mobile ID verifier system in an online/token use case, where the mobile device sends a token to a connected kiosk device and/or mobile ID verifier system, where the token authorizes the kiosk device and/or mobile ID verifier system to request and receive specific and signed identity data from an online source…; paragraph 0029, discussing an example workflow in which the mobile ID association tree can be used to add an approved caretaker that is authorized to pick a child up from school or daycare. However, it will be appreciated that the workflow depicted in FIG. 1D may be extended to add, remove, or otherwise configure authorized users, authorized user groups, varying access levels, or the like for any suitable shared service that is integrated with the mobile ID association tree. As shown in FIG. 1D, and by reference number 135-1, the user of the mobile device may access an application associated with the mobile ID association tree via the mobile device, which may display an interface to view and configure (e.g., add or remove) approved caretakers that are authorized to pick a child up from school or daycare; paragraph 0032); and
determining, based on the mDL validity response, an authority verification result (paragraph 0017, discussing that the entity that needs to confirm the identity or biographical information associated with the mobile ID stored on the mobile device (e.g., an entity associated with the mobile ID verifier system) may receive information associated with the mobile ID that has been authorized for sharing through an electronic reader or over a network and confirm the authenticity of the mobile ID and the shared information associated with the mobile ID. In some implementations, the mobile ID stored on the mobile device may be associated with the user of the mobile device, or the user of the mobile device may be a parent, guardian, agent, or other person that represents or acts on behalf of the person associated with the mobile ID stored on the mobile device. For example, the mobile ID may embed all relevant data associated with the electronic identity document into individual data fields, which allows the data to be compartmentalized such that the user of the mobile device can share only one or more fields that the user wishes to share or that the mobile ID verifier system requires to be provided. The individual data elements are digitally signed by the mobile ID issuer system (e.g., using a private key associated with the mobile ID issuer system), and the mobile ID verifier system has capabilities to verify the cryptographic signature(s) of the shared data fields such that the mobile ID verifier system can have confidence in the authenticity of the shared data field(s); paragraph 0018, discussing that the mobile ID issuer system may implement a process to verify that the user of the mobile device is the owner of the identity associated with the mobile ID being requested and the owner of the mobile device to be provisioned with the mobile ID. For example, in some implementations, the mobile ID issuer system may verify whether the user of the mobile device owns the identity associated with the mobile ID being requested and the mobile device to be provisioned with the mobile ID based on payment records, a personal identification number (PIN) or other shared secret, facial recognition matched against a trusted data source, or in-person registration of the mobile device; paragraph 0022, discussing that a user that is an organizer of one or more groups or sub-groups may send a request to the mobile ID tree association system to invite another user to join a group or sub-group in the mobile ID association tree associated with the user. In this way, associations between different users may be defined and verified through the mobile ID registered to each user, which may define a two-way verified association between each pair of users. Accordingly, in some implementations, the mobile ID association tree may be configured for the mobile ID associated with the user of the mobile device by providing the user with the option to organize different users into groups or by the mobile ID tree orchestration system deriving the groups based on the two-way verified association facilitated through the mobile ID tree orchestration system; paragraph 0028, discussing that the mobile ID association tree can leverage mobile IDs to configure access to various shared services; paragraph 0032, discussing that a person attempting to prove that they are authorized for the service may present their mobile device to the kiosk device to request access. In this case, the kiosk device reads information associated with the mobile ID of the person attempting to prove that they are authorized for the service from the mobile device, and sends a request that includes the requester's mobile ID to the mobile ID tree orchestration system 150-2. For example, the request may include the name or other identity information associated with the person requesting access to the service. In some implementations, the mobile ID tree orchestration system may send a request to the mobile ID verifier system to verify the authenticity of the mobile ID. As shown by reference number 150-4, the mobile ID tree orchestration system may then send a mobile ID approval message to the kiosk device, thereby granting the user the requested access, based on the mobile ID verifier system indicating that the mobile ID is authentic and the applicable mobile ID association tree indicating that the user presenting the mobile ID is included among the users or groups of users that are authorized for the service. Alternatively, the mobile ID tree orchestration system may send a mobile ID rejection message to the kiosk device, thereby denying the user the requested access, based on the mobile ID verifier system indicating that the mobile ID is inauthentic and/or the applicable mobile ID association tree indicating that the user presenting the mobile ID is not included among the users or groups of users that are authorized for the service).
The Lu-Aabye-Lovelock combination describes features related to delegation verification and authentication. Vitug relates to systems for access verification. 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 Vitug 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 Vitug’s features for receiving a mDL validity response indicating whether a user device associated with the mDL corresponds to the first user device to which the mDL was originally provisioned and determining, based on the mDL validity response, an authority verification result, in the manner claimed, would serve the motivation of facilitating obtaining data associated with a mobile ID from a mobile device and facilitating interaction with and/or authorization from a person who is presenting the mobile ID stored on the mobile device (Vitug at paragraph 0041); 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-Vitug 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 4, the Lu-Aabye-Lovelock-Vitug 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-Vitug 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-Vitug 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-Vitug 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-Vitug combination 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.
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.
As per claim 22, the Lu-Aabye-Lovelock-Vitug combination teaches the method of claim 1. Although not explicitly taught by thhe Lu-Aabye-Lovelock combination, Vitug in the analogous art of access verification systems teaches further comprising verifying, by the user authentication circuitry and based on the mDL validity response, the mDL is associated with the third user (paragraph 0017, discussing that the entity that needs to confirm the identity or biographical information associated with the mobile ID stored on the mobile device (e.g., an entity associated with the mobile ID verifier system) may receive information associated with the mobile ID that has been authorized for sharing through an electronic reader or over a network and confirm the authenticity of the mobile ID and the shared information associated with the mobile ID. In some implementations, the mobile ID stored on the mobile device may be associated with the user of the mobile device, or the user of the mobile device may be a parent, guardian, agent, or other person that represents or acts on behalf of the person associated with the mobile ID stored on the mobile device. For example, the mobile ID may embed all relevant data associated with the electronic identity document into individual data fields, which allows the data to be compartmentalized such that the user of the mobile device can share only one or more fields that the user wishes to share or that the mobile ID verifier system requires to be provided. The individual data elements are digitally signed by the mobile ID issuer system (e.g., using a private key associated with the mobile ID issuer system), and the mobile ID verifier system has capabilities to verify the cryptographic signature(s) of the shared data fields such that the mobile ID verifier system can have confidence in the authenticity of the shared data field(s); paragraph 0018, discussing that the mobile ID issuer system may implement a process to verify that the user of the mobile device is the owner of the identity associated with the mobile ID being requested and the owner of the mobile device to be provisioned with the mobile ID. For example, in some implementations, the mobile ID issuer system may verify whether the user of the mobile device owns the identity associated with the mobile ID being requested and the mobile device to be provisioned with the mobile ID based on payment records, a personal identification number (PIN) or other shared secret, facial recognition matched against a trusted data source, or in-person registration of the mobile device; paragraph 0022, discussing that a user that is an organizer of one or more groups or sub-groups may send a request to the mobile ID tree association system to invite another user to join a group or sub-group in the mobile ID association tree associated with the user. In this way, associations between different users may be defined and verified through the mobile ID registered to each user, which may define a two-way verified association between each pair of users. Accordingly, in some implementations, the mobile ID association tree may be configured for the mobile ID associated with the user of the mobile device by providing the user with the option to organize different users into groups or by the mobile ID tree orchestration system deriving the groups based on the two-way verified association facilitated through the mobile ID tree orchestration system; paragraph 0028, discussing that the mobile ID association tree can leverage mobile IDs to configure access to various shared services; paragraph 0032, discussing that a person attempting to prove that they are authorized for the service may present their mobile device to the kiosk device to request access. In this case, the kiosk device reads information associated with the mobile ID of the person attempting to prove that they are authorized for the service from the mobile device, and sends a request that includes the requester's mobile ID to the mobile ID tree orchestration system 150-2. For example, the request may include the name or other identity information associated with the person requesting access to the service. In some implementations, the mobile ID tree orchestration system may send a request to the mobile ID verifier system to verify the authenticity of the mobile ID. As shown by reference number 150-4, the mobile ID tree orchestration system may then send a mobile ID approval message to the kiosk device, thereby granting the user the requested access, based on the mobile ID verifier system indicating that the mobile ID is authentic and the applicable mobile ID association tree indicating that the user presenting the mobile ID is included among the users or groups of users that are authorized for the service. Alternatively, the mobile ID tree orchestration system may send a mobile ID rejection message to the kiosk device, thereby denying the user the requested access, based on the mobile ID verifier system indicating that the mobile ID is inauthentic and/or the applicable mobile ID association tree indicating that the user presenting the mobile ID is not included among the users or groups of users that are authorized for the service).
The Lu-Aabye-Lovelock combination describes features related to delegation verification and authentication. Vitug relates to systems for access verification. 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 Vitug 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 Vitug’s feature for verifying, by the user authentication circuitry and based on the mDL validity response, the mDL is associated with the third user, in the manner claimed, would serve the motivation of facilitating obtaining data associated with a mobile ID from a mobile device and facilitating interaction with and/or authorization from a person who is presenting the mobile ID stored on the mobile device (Vitug at paragraph 0041); 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.
15. 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 view of Vitug, in further view of Boyd, Pub. No.: US 2023/0367858 A1 [hereinafter Boyd].
As per claim 5, the Lu-Aabye-Lovelock-Vitug 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-Vitug 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-Vitug 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-Vitug 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.
16. 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 view of Vitug, in further view of Maleknejad, Pub. No.: US 2020/0336904 A1, [hereinafter Maleknejad].
As per claim 6, the Lu-Aabye-Lovelock-Vitug 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-Vitug-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-Vitug-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-Vitug-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.
17. Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Lu in view of Aabye, in view of Lovelock, in view of Vitug, in view of Engan et al., Patent. No.: US 10,505,916 B2 [hereinafter Engan], in further view of Schalldach et al., Pub. No.: US 2024/0236067 A9, [hereinafter Schalldach].
As per claim 21, the Lu-Aabye-Lovelock-Vitug combination teaches the method of claim 1. Although not explicitly taught by the Lu-Aabye-Lovelock-Vitug combination, Engan in the analogous art of authorization systems teaches generating the digital token comprises: creating a header comprising metadata of the digital token (col. 6, lines 51-53, discussing that the authentication token includes a header, a payload, and a signature; col. 6, lines 54-60, discussing that the header includes header data that is typically, but not necessarily, made up of two parts: a type of the token, and a digital signing algorithm used with the token. The header data is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header; col. 7, lines 1-3, discussing that the header indicates that the token type is a JSON Web Token, and that the PS256 algorithm was used with the token);
creating a payload comprising data including at least one of information about the mDL or an indication of an expiration time for the digital token (col. 6, lines 51-53, discussing that the authentication token includes a header, a payload, and a signature; col. 7, lines 4-18, discussing that the payload (sometimes referred to as a “body”), includes statements about an entity and may contain additional data. In the example provided, the payload includes at least a client public key and a unique user identifier (UUID) associated with the client device. Typically, the payload will also contain other information, such as information that identifies an issuer of the token, a subject of the token, an expiration time of the token, etc. The client public key, and other data, is encoded to produce the payload. Although such encoding is shown in FIG. 3 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described);
encoding and combining the header and the payload (col. 8, lines 27-31, discussing that
the header data is encoded using Base64, Base64url, or some other mutually recognized scheme to produce the header; col. 8, lines 32-39, discussing that the payload includes payload data that consists of statements about an entity and/or other data, such as information that identifies an issuer of the token, a subject of the token, etc. The payload data is encoded to produce the payload. Although such encoding is shown in FIG. 4 as being according to Base64, any known method of encoding may be used as long as it suits the purposes of the techniques described); and
signing the combined header and the payload using a secret key and signing algorithm, where the signing creates the digital token (col. 7, lines 43-51, discussing that the signature is created by signing the encoded header and the encoded payload with an identity provider private key...The signature is created using the digital signature algorithm identified in the header data; col. 9, lines 39-48, discussing that an authentication token and a POP token are included in the header credentials. Similar to the authentication token shown in FIG. 3, the authentication token includes header data, a client public key, and a signature from a trusted identity provider…).
The Lu-Aabye-Lovelock-Vitug combination describes features related to delegation verification and authentication. Engan relates to systems for authentication. 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-Vitug combination with Engan because the references are analogous art because they are both directed to solutions for authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye-Lovelock-Vitug combination to include Engan’s features for including creating a header comprising metadata of the digital token, creating a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token, encoding and combining the header and the payload, and signing the combined header and the payload using a secret key and signing algorithm, where the signing creates the digital token, in the manner claimed, would serve the motivation of providing an improvement over authentication tokens and usage techniques presently in use (Engan at col. 2, lines 13-15); 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-Lovelock-Vitug-Engan combination does not explicitly teach a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token. However, Schalldach in the analogous art of authentication systems teaches this concept. Schalldach teaches:
a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token (paragraph 0005, discussing that ISO 18013-5 defines and enables a personal identification, especially an ISO-compliant driving license which is used within a mobile driving license (mDL) application. A Citizen (called Holder) owns a digital ID document in his mobile wallet, issued by an issuing entity (called Issuer) trusted by the Relying Party (called verifier). This digital document contains civil ID attributes like family name, first name, place of birth, date of birth, address etc. It may also contain entitlement attributes like right to drive a certain class of car, trucks, or boats. Documents also has a validity date attribute. Such a mobile ID document is defined by ISO 18013-5 and possesses appropriate technical attributes to prove it is genuine (not cloned or tampered) by using some signature & active authentication keys; paragraph 0040: “mDL: a special type of digital document instance, digital equivalent of a physical driver license”; paragraph 0067, discussing that the holder having access to his holder app is visiting a web page of a service or goods provider. Here, since initial reference is made to an mDL and a use case where specific elements have to be provided and authenticated, it is assumed that the provider is a car rental service; paragraph 0085, discussing that the holder having access to his holder app is visiting a web page of a service or goods provider. Here, since initial reference is made to an mDL and a use case where specific elements have to be provided and authenticated, it is assumed that the provider is a car rental service).
The Lu-Aabye-Lovelock-Vitug-Engan combination describes features related to delegation verification and authentication. Schalldach relates to secure online authentication method using mobile id document. Therefore, they are deemed to be analogous as they both are directed towards solutions for 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-Vitug-Engan combination with Schalldach because the references are analogous art because they are both directed to solutions for authentication systems, which falls within applicant’s field of endeavor (system for verifying a delegate), and because modifying the Lu-Aabye-Lovelock-Vitug-Engan combination to include Schalldach’s feature for including a payload comprising mDL data including at least one of information about the mDL or an indication of an expiration time for the digital token, in the manner claimed, would serve the motivation providing enhanced confidence and trust (Schalldach at paragraph 0101), 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.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Law et al., Pub. No.: US 2024/0362622 A1 – describes user device gated authentication and tokenization computing systems and methods.
Jain, Patent No.: US 12,664,244 B1 – describes that if a device has been seen previously, a DT (Device Token) for the device may be retrieved. In one embodiment, the determination that the device has been seen previously may be made because a new user is enrolling using a previously seen device. In one implementation, the DT may be retrieved as part of the device search on the device graph database. For example, if the device search indicates that the device has been seen previously, the device search may provide the DT of the matching device graph in the device graph database.
Lim et al., Pub. No.: US 2023/0224712 A1 – describes systems and methods of verifying the identity of an individual/client before providing a form of access to the client and, more specifically, to verifications that make use of mobile identification credentials for sign-on authentication.
Brăcăcescu, Raluca Veronica, et al. "A proposal of digital identity management using blockchain." Revue Roumaine Des Sciences Techniques—Série Électrotechnique Et Énergétique 69.1 (2024): 85-90 – describes a system for digital identity.
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
