Patent Description:
Identification documents may be used to verify aspects of a person's personal identity. If issued in the form of a small, mostly standard-sized card, it is usually called an identity card (ID or ID card). Countries which do not have formal identity documents may require identity verification using informal documents.

In the absence of a formal identity document, driving licenses may be accepted in many countries for identity verification. Some countries do not accept driving licenses for identification, often because in those countries they do not expire as documents and can be old or easily forged. Most countries accept passports as a form of identification.

Identification documents may also be used to verify an individual's membership in a group. For example, student identification cards are used as proof that the individual is a student, faculty, or staff at a school. Military identification cards are used as proof that the individual is a member of the armed services.

<CIT> describes a method that includes forwarding, by a mobile device, a request for identification information associated with a user of the mobile device. The method may also include receiving, from an identification provider, the identification information, and displaying, by the mobile device, at least some of the identification information.

<CIT> describes secure personal identification, information processing, and precise point of contact location and timing.

<CIT> describes digitally signing and delivering content in a geographically controlled manner via a network.

<CIT> describes authorizing mobile payment transactions.

<CIT> describes secure digital identification.

This specification describes technologies relating to digital identification.

Identification documents service an important role. They are used to verify that an individual is who they purport to be. Identification documents are also used to verify that an individual is a member of class of individuals entitled to certain privileges. For example, a driver's license demonstrates that a user is entitled to drive. A student identification card demonstrates that an individual is affiliated with a particular school. A military identification card demonstrates that an individual is a member of the armed services.

Physical cards have short comings. They can be lost, stolen, or forged. An individual may need to carry multiple identification cards, which may be unwieldy. Identification documents can be stored or accessed using a client device. In some implementations, identification document access can be integrated into a digital wallet or similar application. digital identification has the advantage of being able to be provided electronically, rather than physically, which in turn reduces the likelihood that the identification will be lost or stolen. digital identification also allows for real-term validation that the ID is still active (for example, that the ID has not been revoked) unlike a physical ID which can only show if the ID is expired.

<FIG> is an example of a digital wallet application executing on a client device. The client device can be, for example, a mobile device (such as a smart phone, a tablet, a notebook, personal digital assistant, a dedicated wallet device, a wearable computing device, or any other portable device capable of sending and receiving messages over a network). The client device can also be devices integrated into the Internet of Things, such as a smart home or devices within the home. The client device 102a includes a digital wallet application <NUM>. Within the digital wallet is information about different available digital identification documents. In this example, the digital wallet has a driver's license <NUM>, a military id <NUM>, a student id <NUM>, and a passport <NUM>. Other types of identification and permits can also be stored in the digital wallet, including but not limited to firearm permits, hunting licenses, medical licenses, bar admission cards, and a Naturalization and Immigration Services (NIS) Cards. In some implementations, the digital wallet only displays information about digital identification documents to which the application has access.

Information in the digital wallet may also establish relationships between individuals, such as legal guardianship and spousal relationships.

In some implementations, the digital wallet application <NUM> includes a selectable item <NUM> (for example, a button or a link) that enables the user to add a new form of identification to the system. In some implementations, the driver's license may be requested, for example, by selecting the appropriate identification and selecting the Request ID button <NUM>. In some implementations, the driver's license may be requested, for example, by voice activation and / or double tapping the driver's license item <NUM>.

The user can select a form of digital identification to present on the client device 102a. In this example, the user selects the driver's license <NUM>. The user interface of the client device 102b can update the display the user's driver's license <NUM>.

<FIG> illustrates providing a digital identification <NUM> to a computing device <NUM>. A computing device <NUM> may request identification from the client device <NUM>. In some implementations, the computing device <NUM> can be executing an application that is capable of sending a request to the client device <NUM>. For example, the application executing on the computing device <NUM> and the app executing on the client device <NUM> may be in communication through a separate system such as a server (not shown).

The client device <NUM> receives the request for the driver's license and displays a message <NUM> on the screen. The request may include the identity of the individual, company, or system requesting the identification. In this example, Burger Shop has requested to see a driver's license. In some implementations, the computing device <NUM> can request a particular form of identification, such as a driver's license or a passport. In some implementations, the computing device <NUM> may request any form of identification sufficient to demonstrate some fact about the user, such as age or citizenship.

In some implementations, the client device <NUM> may proactively offer the driver's license. The driver's license may be offered to particular entity (for example, the Burger Shop, a law enforcement officer, etc.) or may be generally presented to whomever requests it. In some implementations, the driver's license may be offered to a particular type of entity (for example, any bar or restaurant, any law enforcement officer, an immigration agent, etc.).

The user of the client device <NUM> may accept <NUM> or deny <NUM> the request. If the user accepts the request, the user's driver's license <NUM> is displayed on the computing device <NUM> of the requesting party. The computing device <NUM> may display the user's digital identification, but in some instances it may only display a decision or determination that is relevant to the person requesting the identification. For example, an age verification requested by a retail store may only need to know that digital identification holder is old enough to purchase alcohol. Therefore the computing device may display a YES or NO depending on whether the identification holder is old enough to purchase alcohol or not. Other examples include authorization to enter a venue or event (for example, if the client device <NUM> contains a ticket to the venue or event), authorization to board a transport (for example, a plane, ship, bus, or train), and authorization to vote (for example, the client device <NUM> is used to access a voter registration).

In some implementations, business rules may determine whether or not a request is legitimate. For example, the GPS location of the requester and the GPS location of the client device may be compared, the system may compare items purchased by the user to determine if any purchased item requires proof of age, etc..

Communication between the client device <NUM> and the computing device <NUM> may be performed using point to point communication technologies (for example, near field communication (NFC), Blue Tooth, etc.) or may be performed using communication with an application service, described further below).

In some implementations, the driver's license may be offered only for a limited amount of time. For example, the recipient of the driver's license may only have a predetermined period of time (for example, <NUM> seconds, <NUM> seconds, <NUM> minute) to view the driver's license. In some implementations, the recipient of the driver's license may only have a limited period of time to accept an offer to view a driver's license (for example, <NUM> seconds, <NUM> seconds, <NUM> minute), but once viewed, may view it for a longer period of time (for example, <NUM> minutes, <NUM> minutes, an hour, indefinitely).

The application executing on the computing device <NUM> and or the digital wallet / client device detect when a picture, snap shot, or screen shot of the digital driver's license (or other digital license or identification stored in the digital wallet) is made. The system generates an alert that potential identify theft and unlicensed capturing of sensitive information has occurred.

<FIG> illustrates an example of integrating a digital wallet with a digital ID provider <NUM>. The digital wallet <NUM> executes on the client device <NUM>. The user of the client device <NUM> indicates that he wishes to store and retrieve digital identification using a digital wallet <NUM>. The user can be presented with a screen that explains the legal issues surrounding the use of the digital identification service, including but not limited to an end user license agreement. The user is given the option of opting in <NUM> to the use of the digital identification service.

In some implementations, the digital wallet may integrate with a digital ID provider <NUM>. The digital ID provider <NUM> may require that certain communication with the digital ID provider <NUM> be secured using a secret (for example, a client key and client secret). For example, the digital identification service may require, for example, that the communication or part of the communication be encrypted or digitally signed. The communication can be encrypted, for example, using a public key - private key or using a symmetric key. A digital signature can be applied using the public key / private key infrastructure.

The digital identification service may provide a software development kit (SDK) to enable external applications to integrate with the digital identification service. In this example, the digital wallet <NUM> includes an application <NUM> that provides functionality to the digital wallet <NUM> and also includes a digital ID provider SDK <NUM> that enables the digital wallet to access the digital ID providers <NUM>. To enhance security, in some implementations, the secret (for example, client key and client secret) is not stored on the client device <NUM>, but is instead stored on a wallet server <NUM>. Therefore, communications requiring the use of a secret occur from the wallet server <NUM> to the digital ID provider <NUM>. The wallet server can serve as a proxy server to transport information to and from the digital ID provider SDK <NUM> and the digital ID provider <NUM>.

When the user opts into using the digital wallet to store identification documents, the application <NUM> requests that the digital ID provider SDK <NUM> authorize the user and the client device <NUM> to use the digital ID provider <NUM>.

The digital ID provider SDK <NUM> can prompt the digital ID provider <NUM> to create and authorize an account. The digital ID provider <NUM> can generate an authentication code and provides the authentication code to the digital ID provider SDK <NUM>, which, in tum, can provide the authentication code to the application <NUM>. The application can provide the authentication code to the wallet server <NUM> using a secure connection.

The wallet server <NUM> can send the authentication code and the secret to the digital ID provider <NUM>.

The digital ID provider <NUM> compares the provided authentication code to a stored authentication code. If the provided authentication code matches the stored authentication code, the digital ID provider <NUM> registers the user.

The digital ID provider <NUM> provides an access token with a refresh token to the wallet server <NUM>. The wallet server <NUM> provides the access token with the refresh token to the application <NUM>. The application provides the access token with the refresh token to the digital ID provider SDK <NUM>. The digital ID provider SDK <NUM> provides the access token with the refresh token to the digital ID provider <NUM>.

In response to receiving the token, digital ID provider <NUM> associates the client device <NUM> and / or the digital wallet <NUM> with the user.

<FIG> illustrates an example of adding an identification document to a digital wallet. While this example refers to a driver's license, the process described herein may be used to store other forms of identification, including but not limited to Military ID, Student ID, and Passports.

The user can use the mobile app <NUM> to obtain a digital image of his driver's license. For example, the user may use a camera associated with the client device <NUM> to take a picture of the driver's license. Alternatively, or additionally, the user may scan their driver's license using a conventional scanner and transfer the scanned driver's license to the client device <NUM>. In some implementations, the user is asked to scan a bar code, QR code, or other data bearing code that is shown on driver's license.

The image of the driver's license or bar code is provided to the digital ID provider SDK <NUM>. The digital ID provider SDK encrypts the image of the driver's license or scanned code using a public key associated with the digital ID provider <NUM>. In some implementations, the public key is stored on the client device <NUM> and is accessible by the digital ID provider SDK <NUM>. In some implementations, the digital ID provider SDK <NUM> may obtain the public key from the digital ID provider <NUM>, for example, through a network request.

The digital ID provider SDK sends the encrypted payload to the application <NUM>. The Application <NUM> sends the encrypted payload to a digital ID module <NUM> on the wallet server <NUM>. As the wallet server <NUM> does not possess the private key of the digital ID provider <NUM> the wallet server <NUM> cannot decrypt the encrypted payload.

The wallet server <NUM> can obtain additional information about the user. For example, the wallet server may use a user verification module <NUM> to determine whether the user is a verified user. In some implementations, determining whether a user is verified includes obtaining a user profile <NUM> of the user. The user profile <NUM> may include information that can be used to determine whether the user has accounts with a financial institution. For example, the user may have bank account, insurance, or an investment account with the financial institution. Some accounts may include sufficient information to verify the user (for example, a bank account or life insurance account). Other accounts may not include sufficient information to verify the user (for example, a property and casualty insurance account).

The wallet server also may provide additional information about the user to the digital ID provider Server. This additional information is owned by the wallet server <NUM> and can be used by the digital ID provider <NUM> for further verification of the request. The additional information may include identification information about the use stored in the wallet server <NUM> (such as a customer number). The additional information can also be user specific data such as first name, last name, social security number, etc..

If the user can be verified, the wallet server <NUM> collects information about the user.

If the user cannot be verified, information about the user may be obtained through a third party identification verification system <NUM>.

The information about the user (if available) and the encrypted payload is provided to an external gateway <NUM> that manages communications with the digital ID provider <NUM>. The External Gateway may send the encrypted payload and the user data (secured by the secret, as described above) to the digital ID provider <NUM>.

The digital ID provider <NUM> can decrypt the image of the driver's license or scanned code using the digital ID provider's private key.

If the user has been verified the digital ID provider <NUM> may store the decrypted driver's license for later retrieval. In some implementations, the image of the driver's license or scanned code may be stored in encrypted form. In some implementations, the digital ID provider <NUM> may use information derived from the scanned code to obtain additional driver's licenses details from a third party (such as the issuer of the driver's license).

If the user has not been verified, the digital ID provider <NUM> can use the image of the driver's license or scanned code and any provided user data to verify the driver's license with an Identification Verification Check <NUM>. For example, with the appropriate governmental agency (such as the Department of Motor Vehicles, Department of State, a Military Branch, or similar institution). In some implementations, the digital ID provider may contract with a third party (such as EXPERIAN) to verify the ID. In some implementations, the digital ID provider <NUM> may verify the user even if the user has been verified by the wallet server.

Other information about the user may also be stored. For example, the license plate number of a registered vehicle may be stored in association with the digital driver's license. Similarly, a rental car agency may associate a digital driver's license with a rented automobile for the duration of the rental. In some implementations, a digital driver's license may be associated with a financial payment instrument (such as a credit card). The digital driver's license may be associated with a rental automobile based on the use of the credit card to rent the automobile. The digital driver's license may be associated with other appropriate transactions or object based on similar activity.

<FIG> illustrate an example of providing a digital identification document to a third party. While this example refers to a digital driver's license and a law enforcement officer, a similar process can be used to provide other forms of digital identification to other parties. For example, the process may be used to present a passport to an immigration or customs officer.

In this example, a car <NUM> is pulled over by a law enforcement officer <NUM>. The law enforcement officer obtains an identifier for the car <NUM> in his computer <NUM> (in this example, a license plate number but other identifier such as an identifier on a decal may also be used). For example the license plate number may be manually entered, may be scanned using a camera or scanning device. The license plate number could be obtained using NFC, RFID, or another communication mechanism to obtain the information from the license plate or from the car <NUM>. The computer sends the license plate number to a registration system <NUM>. The registration system may be, for example, a law enforcement database, an insurance database, a governmental database, or a digital identification database.

Other methods may be used to determine that the driver possesses a digital driver's license. For example, a sticker or decal may be placed on the car to notify the law enforcement officer that the driver is likely to have a digital driver's license. In some implementations, the other method may also include an identifier (for example, number, bar code, QR code, etc.) that notifies that enables the law enforcement officer to look up the digital driver's licenses associated with the identifier. In some implementations, computers or media included in the dash board of the car may be able to identify that the driver has a digital driver's license. In some implementations, the system may use biometrics such as a fingerprint, retina scan, voice recognition, or other biometric to identify the driver. The identity of the driver can be cross referenced to determine that the driver has a digital driver's license.

The registration system <NUM> identifies that the driver of the car <NUM> may possess a digital driver's license.

In some implementations, the law enforcement officer may be informed by the individual that he has a digital driver's license.

The law enforcement officer may use his computer <NUM> to request the digital driver's license of the potential drivers from a digital ID system <NUM>. The digital ID system <NUM> may include one or more disparate systems coordinating together. For example, the digital ID system <NUM> may include a digital ID provider (for example, the digital ID provider <NUM> of <FIG>) and a Wallet Server (for example, the Wallet Server <NUM> of <FIG>). In some implementations, secure communication between the client device <NUM> and a digital ID provider may be sent through a Wallet Server. Communications between the client device and the wallet server may be secured by the wallet server. Communications between the Wallet Server and the digital ID provider may be secured using a secret provided to the Wallet Server by the digital ID provider, as described above.

The law enforcement officer may also send the GPS location. In some implementations, the GPS device may be integrated into the computer <NUM>, the GPS may be integrated into the law enforcement officer's vehicle <NUM>, alternatively or additionally the GPS location may be integrated into the GPS device may be into a hand held device, scanner, or other device that is indicative of the location of the law enforcement officer. Communication with the digital ID system <NUM> may include a verification of the identity of the law enforcement officer. In some implementations, other information may be included, such as a code or comment describing the reason the identification is requested (for example, "traffic stop").

The digital ID system <NUM> may compare the location of the law enforcement officer (as determined by the GPS location) to the location of the registered devices of the potential drivers of the car <NUM>. For example, the car may be insured to John Smith and Jane Smith. John Smith and Jane Smith may have each registered a smart phone (or other client device) with the digital ID system <NUM>. In some scenarios, the GPS location of one or more devices may be available. For example, the driver of the car <NUM>, may have enabled the GPS location using his digital wallet when he was pulled over. In other scenarios, the GPS location of the one or more devices may not be available. The digital ID system <NUM> may send a message or notification to the one or more devices asking them to enable their GPS location. In some implementations a wallet server (not shown) may act as an intermediary between the digital ID system <NUM> and the client device <NUM>.

In some implementations, GPS location information for the requester (in this example, the law enforcement officer) and the holder of the digital driver's license may be maintained for only as long as necessary to provide the digital driver's license. The GPS information may be deleted once the digital driver's license is provided to the requester. In some implementations, GPS location information may be deleted after a predetermined period of time (for example, <NUM> minutes). Removal of GPS information can facility improved privacy for the sender and the recipient of the driver's license. Other measures to protect the privacy of the participants may be adopted, for example, records may by cryptographically stored, requesting and granting access to a digital ID may require close proximity, etc..

In some implementations, the request for the digital ID may be sent through another communication channel. For example, the user may receive an SMS text, push notification, email, etc.. The user may grant or deny permission to share the requested ID using the same mechanism. For example, the user may response to the SMS text, push notification, or email. In some implementations, the user may also receive a telephone call describing the request for ID. The user may be able to respond during the telephone call. For example, using an interactive voice response (IVR) system.

The user may accept or deny this request. For example, if John Smith is driving the car and Jane Smith is at work, then Jane may decide to deny the request. Similarly, if John Smith is driving the car and Jane Smith is a passenger, Jane may deny the request to facilitate providing accurate information about the driver to the law enforcement officer.

In some implementations, the law enforcement officer or other authorized individual may be able to request identity of the identity of the driver or individuals in a vehicle without notifying the individual of the request. For example, a signal can be send to a device in the car (such as a receiver, a mobile phone, an NFC device, etc.) which may provide the law enforcement officer with information sufficient to obtain digital driver's licenses or other ID's associated with the device.

The digital ID provider determines that the GPS location of the individual driving the car is close to the GPS location of the law enforcement officer requesting the digital driver's license. In some implementations, the GPS location of the law enforcement officer and the GPS location of the driver may be considered close if the reported distance between the two locations is within the margin of error of the GPS device. In some implementations, the location of the GPS location of the law enforcement officer and the GPS location of the driver may be considered close if the locations are within a predetermined distance (e.g., <NUM> feet, <NUM> feet, <NUM> feet, <NUM> feet) as reported by each GPS.

In this example, the digital ID system <NUM> identifies the driver as the probable individual from whom the driver's license is requested. The digital ID system <NUM> ask the driver to allow his driver's license to be shared with the law enforcement officer. As described above, the request may include the identity of the law enforcement officer along with verification that the law enforcement officer is authorized to request the driver's license.

If multiple devices are determined to be close to the law enforcement officer, the digital ID system <NUM> may send a request to each device. For example, John Smith may be driving the car <NUM> and Jane Smith may be a passenger. In this scenario, Jane Smith may elect not to share her driver's license with the law enforcement officer.

Referring to <FIG>, the driver of the car <NUM>, provides permission for the law enforcement officer to receive his digital driver's license.

The digital ID system <NUM> can encrypt each driver's license, which was shared with the law enforcement officer, using a public key associated with the law enforcement officer. The law enforcement officer's computer decrypts the driver license(s) using the private key associate with the law enforcement officer. The law enforcement officer's computer <NUM> then display's the driver's licenses that have been shared with the officer.

<FIG> illustrates another example of providing a digital identification document to a third party. While this example refers to a digital driver's license and a law enforcement officer, a similar process can be used to provide other forms of digital identification to other parties. For example, the process may be used to present a passport to an immigration or customs officer.

In this example, a car <NUM> is pulled over by a law enforcement officer <NUM>. The law enforcement officer <NUM> obtains an identifier to request the digital driver's license of the driver of the car <NUM>. The identifier may be an identifier associated with the car <NUM> (for example, a driver's license, an identifier provided on a decal, an NFC signal provided by a transponder, etc.) alternatively the identifier may be associated with the law enforcement officer (for example, the license plate of the law enforcement officer's vehicle, the law enforcement officer's badge number, etc.). The identifier can be added to the computer of the law enforcement office.

In this example, the computer <NUM> sends the identifier to the digital ID system <NUM> requesting the digital driver's license). The driver of the car <NUM> sends his digital driver's license to the digital id system <NUM> using the same identifier. The digital ID system <NUM> matches the request with the grant of permissions (for example, using the identifier) and provides the digital driver's license to the computer <NUM> of the law enforcement officer.

In some implementations, when the digital driver's license is provided to the law enforcement officer, records of the transaction are removed from the digital ID system. In this example, the exchange of identifiers occurs between the driver and the law enforcement office. The exchange increases the likelihood that the sender of the driver's license and the recipient of the driver's license are in proximity without relying on GPS tracking technology.

Other methods may be used to determine that the driver possesses a digital driver's license. For example, a sticker or decal may be placed on the car to notify the law enforcement officer that the driver is likely to have a digital driver's license. In some implementations, the other method may also include an identifier (for example, number, bar code, QR code, etc.) that notifies that enables the law enforcement officer to look up the digital driver's licenses associated with the identifier.

<FIG> illustrates an example of presenting a digital driver's license. In response to a request to view a digital driver's license (not shown for simplicity), a verification system <NUM> obtains a GPS location of the requesting law enforcement officer (step <NUM>). The GPS location can be obtained from the police department <NUM> by querying a server it controls that manages locations of law enforcement officers. Alternatively, the GPS location can be obtained directly from the law enforcement officer who requested to view the digital driver's license using either their browser location function or an on-vehicle GPS device.

The request may be transmitted through a firewall <NUM> of the police department. The request may be distributed by the police department to a particular police vehicle or officer who wishes to view the digital driver's license material. The police department <NUM> (or law enforcement officer) sends a GPS location through the firewall <NUM> to the to a geolocation matching service <NUM> (step <NUM>).

Generally, both the police department system <NUM> and the verification system <NUM> may maintain network security features such as firewalls (for example, firewall <NUM> and firewall <NUM>). Communication to and from these systems may pass through these network security features.

Using the information provided by the police department <NUM>, the verification system <NUM> sends a silent push request to the client device <NUM> of the individual for whom the driver's license is requested (step <NUM>). If the individual has opted in to providing a digital driver's license, the client device <NUM> can send the GPS location (provided by a GPS device <NUM>) to the geo-location matching service <NUM> (step <NUM>). The information may be provided through the firewall <NUM> of the verification system <NUM>.

The geo-location matching service <NUM> matches the GPS location provided by the client device <NUM> with the GPS location provided by the police department <NUM>. When a match is identified, the police department <NUM> is notified of the match (step <NUM>).

The police department <NUM> may request the driver's license from the verification system <NUM> (step <NUM>). The verification system may include or work with a push notification server <NUM>. The verification server <NUM> causes a push notification to be send to the mobile app <NUM> on the client device <NUM> (step <NUM>). The individual may be presented with the option to provide their digital driver's license to the police department. If the individual agrees to present their digital driver's license, a message may be sent to the display response <NUM> on the verification system <NUM> (step <NUM>). The indication of acceptance is transmitted to the police department <NUM> (step <NUM>) thereby enabling the police department <NUM> to obtain and display the driver's license.

<FIG> is a sequence diagram illustrating an example of presenting a digital driver's license to a law enforcement officer. In this example, the driver proactively shares his digital driver's license before it is requested by the law enforcement officer.

The driver device <NUM> informs the geo-matching service <NUM> that the individual is authorizing the sharing of his digital driver's license with authorized parties (such as a law enforcement officer) (step <NUM>). The driver device <NUM> provides the location of the driver device <NUM> (for example, a GPS location).

The geo-matching service <NUM> adds the location and permission to a list of pre-authorizations (step <NUM>). While described as a list for simplicity, other data structures may be used, for example, a dictionary, a hash table, a lookup table, etc..

The geo-matching service <NUM> informs the driver device <NUM> that the request is pending and provides a timer, indicating for how long the pending request is valid (step <NUM>). In some implementations, the preauthorization to view a digital driver's license may be limited in time, for example, for <NUM> minute, for <NUM> minutes, for <NUM> minutes, etc..

Before the timer expires (that is, while the pre-authorization to view the digital driver's license is valid), a police application <NUM> requests the driver's license from the geo-matching service <NUM> (step <NUM>). The request may include information that can be used to identify the individual (for example, a license plate number). The request may also include the location of the law enforcement officer making the request.

The geo-matching service compares the information in the request from the law enforcement officer with entries in the list of pre-authorizations (step <NUM>). The geo-location service can use the location provided by the driver device <NUM>, the location provided by the police application <NUM>, and/or the identifying information (e.g. a license plate number) provided by the police application <NUM> to identify the individual for whom the law enforcement officer is requesting the license.

In this example, the geo-location service <NUM> identifies that the individual has pre-authorized sharing of the digital driver's license. The geo-location service <NUM> sends information about the license to the police application <NUM> (step <NUM>).

Using the information about the license, the police application <NUM> requests the digital driver's license from a license information source <NUM> (step <NUM>). The license information source can be, for example, a registry of motor vehicles or other governmental or private institution.

The license information source <NUM> provides the digital driver's license to the police application <NUM> (step <NUM>).

The police application <NUM> informs the geo-matching service <NUM> that the law enforcement officer is viewing the digital driver's license (step <NUM>).

The geo-matching service <NUM> informs the driver device <NUM> that the law enforcement officer is viewing the digital driver's license (step <NUM>).

<FIG> is a sequence diagram illustrating an example of presenting a digital driver's license to a law enforcement officer. In this example, the individual reacts to a request for his driver's license by a law enforcement officer.

A police application <NUM> requests the driver's license from the geo-matching service <NUM> (step <NUM>). The request may include information that can be used to identify the individual (for example, a license plate number). The request may also include the location of the law enforcement officer making the request.

The geo-matching service <NUM> compares the information in the request from the law enforcement officer with the list of pre-authorizations (step <NUM>). In this example, the geo-matching service <NUM> does not find a pre-authorization. The geo-matching service <NUM>, determines whether an individual associated with the license plate number (or other identifying information provided by the police application <NUM>) has opted-in to the digital driver's license (step <NUM>).

In this example, the geo-matching service <NUM> identifies a driver device <NUM> associated with the information provided by the police application <NUM>. The geo-matching service <NUM> sends a silent location request to a push gateway <NUM> (step <NUM>).

The push gateway <NUM> pushes the silent location request to a driver device <NUM> (step <NUM>).

The driver device <NUM> sends its location to the geo-matching service <NUM> (step <NUM>.

The geo-matching service <NUM> compares the information in the request from the law enforcement officer and the information from the driver device <NUM> (step <NUM>). Once the geo-matching service <NUM> matches the request from the police application <NUM> with the information provided by the driver device <NUM>, the geo-matching service <NUM> sends a request for permission to share the digital driver's license to the push gateway <NUM> (step <NUM>).

The push gateway <NUM> pushes the request to the driver device <NUM> (step <NUM>). The request for permission may be displayed on the user interface of the driver device. The user of the driver device may elect to share the digital driver's license. In some implementations, the user may be required to authenticate with the device and/or the geo-marching service prior to sharing the driver's license.

Once the user elects to share the digital driver's license, the driver device <NUM> informs the geo-matching service <NUM> that the request has been authorized by the user (step <NUM>).

The geo-matching service identifies the law enforcement officer request for the driver's license (step <NUM>). Pending law enforcement officer requests may be stored in a data structure such as a list, collection, hash table, lookup table, dictionary, or other similar mechanism.

The geo-matching service <NUM> provides information about the license to the police application <NUM> (step <NUM>. ) The information may be information sufficient of obtain the digital driver's license (for example, a driver's license number, a token, or other mechanism).

<FIG> is a flowchart of an example process for providing a digital driver's license to a requester.

The process <NUM> compares <NUM> the location of a requester of a digital identification and an owner of the digital identification. The location of the owner may be obtained without notifying the owner.

The process <NUM> may receive authorization to share the information from the owner. The authorization may be made before or after the requester requests the driver's license. An authorization that is made before the requester requests the driver's license may only be valid for a predetermined period of time.

The process <NUM> provides <NUM> the license information to the requester.

Embodiments of the subject matter described in this specification can be implemented as one or more computer programs (i.e., one or more modules of computer program instructions, encoded on computer storage mediums for execution by, or to control the operation of, data processing apparatus). The computer storage medium can be non-transitory.

The term "data processing apparatus" encompasses all kinds of apparatus, devices, and machines for processing data, including by way of example, a programmable processor, a computer, a system on a chip, or multiple ones, or combinations, of the foregoing The apparatus can include special purpose logic circuitry (e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit)). The apparatus can also include, in addition to hardware, code that creates an execution environment for the computer program in question (e.g., code that constitutes processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or a combination of one or more of them).

The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry (e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit)).

Generally, a computer will also include, or be operatively coupled to receive, data from or transfer data to, or both, one or more mass storage devices for storing data (e.g., magnetic, magneto-optical disks, or optical disks), however, a computer need not have such devices. Moreover, a computer can be embedded in another device (e.g., a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a Global Positioning system (GPS) receiver, or a portable storage device (e.g., a universal serial bus (USB) flash drive)), to name just a few. Devices suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks.

To provide for interaction with a user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback) and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user (for example, by sending web pages to a web browser on a user's user device in response to requests received from the web browser).

Embodiments of the subject matter described in this specification can be implemented in a computing system that includes a back-end component (e.g., as a data server),a middleware component (e.g., an application server), or a front-end component (e.g., a user computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such back-end, middleware, or front-end components.

The computing system can include users and servers. A user and server are generally remote from each other and typically interact through a communication network. The relationship of user and server arises by virtue of computer programs running on the respective computers and having a user-server relationship to each other. In some embodiments, a server transmits data (e.g., an HTML page) to a user device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the user device). Data generated at the user device (e.g., a result of the user interaction) can be received from the user device at the server.

Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can, in some cases, be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Claim 1:
A computer-implemented method, comprising:
receiving, from a first device (<NUM>), a request for digital identification information (<NUM>), the request comprising an identifier and location information indicative of a location of a requester;
determining if digital identification information has been assigned to an owner of the identifier;
responsive to determining that digital identification information has been assigned to the owner, receiving, from a second device, location information indicative of a location of the owner of the digital identification information;
providing (<NUM>) the digital identification information to an application on the first device based at least in part on determining that the requester and the owner are within a predetermined distance and in response to receiving authorization to share the digital identification information from the owner;
detecting that the first device has captured an image of the digital identification information; and
sending, to the second device, an alert indicating that potential identify theft and unlicensed capturing of sensitive information has occurred.