Device interaction connection system with verification

Abstract

A method includes: transmitting information including a response uniform resource locator (URL) between the primary device and the secondary device using a primary communication channel between the primary device and the secondary device; determining, using the secondary device, a connection status of a network separate from the primary communication channel; when the status indicates that the network is available, sending, by the secondary device, a response to a request from the primary device via the network using the response URL; and sending a response via the primary communication channel when the status indicates that the network is unavailable.

Description

[0001] Priority Claim

[0002] This application claims priority to U.S. Provisional Application Nos. 62 / 771,845, filed on November 27, 2018, 62 / 771,849, filed on November 27, 2018, 62 / 771,886, filed on November 27, 2018, and 62 / 779,864, filed on December 14, 2018. Technical Field

[0003] The technology described in this patent document relates to transmitting information from a mobile device over a communication channel. In particular, the technology described in this patent document relates to transmitting sensitive information related to a mobile identity document, such as a mobile driver's license (mDL), over a trusted communication channel. Background Art

[0004] mDL provides the functionality of a driver's license on mobile devices (e.g., smartphones, tablets, etc.). mDL also allows the police department to obtain up-to-date information in the event of a traffic stop. However, information related to a driver's license may be sensitive personal information that should only be transmitted to the issuing authority's infrastructure or an mDL reader via a trusted communication channel. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a block diagram of a mobile driver's license (mDL) system.

[0006] Figure 2 is a flowchart of an example of a method of mDL device engagement starting from the authentication side.

[0007] Figure 3 is a flowchart of an example of a method of mDL device interaction starting from the authentication side.

[0008] Figure 4 is a flowchart of an example of a method of mDL device interaction starting from the mDL holder side.

[0009] Figure 5 Are images of different types of scannable or readable badges.

[0010] Figure 6 is a block diagram of a portion of another example of an mDL system.

[0011] Figure 7 is an example of including a Uniform Resource Locator (URL) in an mDL reader request.

[0012] Figure 8 is another example of including a URL in an mDL reader request.

[0013] Figures 9 and 10 is another example of including a URL in an mDL reader request. DETAILED DESCRIPTION

[0014] A mobile driver's license (mDL) consists of an application (mDL App) that runs on a mobile communication device (e.g., a smartphone, tablet, etc.). During a traffic stop, information related to the driver's license can be transmitted to an mDL reader at the issuing authority. This information may be sensitive to the driver and requires a trusted channel to be used to transmit it between the mDL reader and the mobile device.

[0015] Figure 1 is a block diagram of a portion of an example of an mDL system. The system includes a driver's mDL holder 105 device (e.g., a smartphone), an issuing authority's mDL reader 110, and an issuing authority's infrastructure 115 (e.g., one or more servers). In order to establish a trusted communication channel, device interaction (DE) data is transmitted between the mDL holder 105 and the mDL reader 110. DE data can be sent from an mDL App (mDL DE) or from an mDL reader or verifier device (vDE). For example, the DE data can include one or more encryption keys for forming a trusted channel. Device interaction can start from the primary verifier side or the secondary mDL App side.

[0016] Figure 2 Flowchart that is an overview of mDL device interaction (verifier-side device interaction or vDE) starting from the verifier side. There may be situations where starting the interaction from the verifier side is preferred, or starting from the verifier side may be the only option. At 205, some DE data is used by the mDL App to obtain the necessary information to establish a secure connection to the mDL reader. The DE data may include information read from a readable or scannable badge of a police officer (or other agency personnel), a quick response (QR) code on a web page, or a click on an App link on a web page, or other media between the mDL App and the mDL reader. The information may include communication options that can be used to communicate with the mDL reader. The information may include security information, such as a public key that can be used to encrypt the communication channel. The public key can be at least slightly temporary. At 210, communication is established between the mDL holder and the mDL reader.

[0017] At 215, the mDL App uses the public key to encrypt the communication and sends the encrypted DE data over the established communication channel. The mDL App sends the DE data encrypted using the received public key or the derived key. At 220, the mDL reader request is sent encrypted using the derived key. The public key can be used to determine the new derived key. At 225, an encrypted response is returned from the mDL reader.

[0018] The encrypted DE data may not be sent immediately. In some embodiments, after the exchange data is transmitted, the next communication may occur based on the proximity of the mobile communication device to the verifier device. For example, the exchange data may be transmitted according to step 205, and then the communication may be suspended. When the mobile device is within close range of the verifier device, the subsequent process continues according to a short-range protocol (e.g., Bluetooth, Near Field Protocol, etc.).

[0019] Figure 3 Flowchart of another example of a method of mDL device interaction starting from the verifier side (vDE). Before sending the DE data, at 305, the communication between the mDL App and the mDL reader may include some preliminary steps for reducing traceability. These preliminary steps may include: sending information that is as dynamic as possible. The mDL reader may send dynamic information. The dynamic information may include a Quick Response (QR) code that is dynamically created, and the mDL App scans the QR code and returns the QR code to the mDL reader as dynamic information. In another example, a badge may include a Near Field Communication (NFC) tag or other contactless tag, and the badge may be synchronized with the mDL reader, and the dynamic information may have been updated before the control situation begins.

[0020] At 310, the mDL App interacts with the mDL reader (authenticator device) using a QR code, NFC handoff, or a "click-to-app" link within a web page (e.g., a deep link to an app that calls the default identity app), or other means for receiving information for connecting to the identified reader. As part of the device interaction, the mDL App receives a public key from the mDL reader before sending other DE data from the mDL App to the mDL reader. The public key is used in the process of encrypting the device interaction data (e.g., to share the mDL temporary public key).

[0021] At 315, the mDL App can check whether the information obtained so far was issued by a device with a certificate from a trusted authority. At 320, mDL checks for specific cases where vDE starts from the request and acts accordingly (for example, if the certificate is included in the request). At 325, if the request is not included, the mDL App sends its encrypted DE data. At 330, mDL receives the encrypted request. At 335, the mDL App optionally authenticates the mDL reader terminal. At 340, the mDL App sends a response. If the request was included at 320, the mDL App sends an encrypted response at 330. In subsequent steps, the exchange of information continues.

[0022] The public key obtained from the verifier side as part of vDE can be somewhat temporary and can be changed at the discretion of the mDL reader to prevent tracking. The public key can be provided as part of a certificate from a trusted authority (TA). The mDLApp can check the certificate against the TA's list and connect accordingly. Alternatively, the vDE data can be signed by an authority that the mDLApp trusts and the mDLApp proceeds accordingly. vDE can include the option to connect using a private WiFi network or using the Internet. vDE can provide a uniform resource identifier (URI) to connect to, as well as certificate pinning information that matches the certificate from the transport layer security (TLS) session. All information exchanged can be end-to-end encrypted between the mDLApp and the mDL reader, and all intermediate components of the infrastructure or front-end web servers only see encrypted data.

[0023] vDE provides some options that are not available to DE on the mDL app side. For example, vDE can include signatures, and vDE data can have information for connecting over the Internet (e.g., certificate pinning for TLS and the mDL reader web front-end URI). Using the Internet to connect can make communication between the mDL app and the mDL reader faster because the communication channel may only need to be protected once for the communication session. It can also contain the request itself so that the mDL app can send a response immediately. vDE data can be encoded using Concise Binary Object Representation (CBOR) and further presented using a QR code, NFC Data Exchange Format (NDEF) tag, or URI. vDE data does not necessarily have to be presented by the mDL reader itself, but can be presented in a web page, badge, etc. Other readable media can be used. The mDL app can scan the QR to initiate device interaction. NFC handover using the NDEF tag can be used to trigger the mDL app to initiate device interaction. The URI containing the CBORvDE can be used to open the appropriate app for the mDL app on the mobile device.

[0024] The DE on the mDL App side provides a clear structure to send the temporary key of the mDL App. The DE on the mDL App side also provides additional communication methods that the mDL App can prefer. The mDL DE data is encrypted and sent using a public key or a key derived from the public key and the temporary private key of the mDL reader. The public key of the mDL reader is included in the DE data.

[0025] Additional communication methods may include offline requests. Typically, an mDL reader request is delivered after the DE data is received by the mDL reader. The mDL reader request may be encrypted using a key derived from the mDL reader temporary public key and the mDL reader temporary private key. When the mDL reader temporary public key matches the mDL reader temporary private key, the mDL reader public key does not need to be sent. The mDL reader request may be part of the vDE data. In this case, the request CBOR may be added to the vDE data and shared without encryption. This method presents the following advantages: the mDL App can respond immediately. This may be of particular interest for Internet authentication where the response relies on TLS, which can provide the necessary elements to confirm that the mDL reader is authorized to receive the response.

[0026] Additional communication methods may include offline responses. mDL responses are typically delivered encrypted using a key derived from the mDL reader public key and the mDL private key. For offline requests, the mDL request can be linked to vDE data. The offline response is returned along with the mDL App public key so that the mDL reader can calculate the derived key used as the decryption key to decrypt the response.

[0027] Figure 4 Flowchart of an example of a method for mDL device interaction starting from the mDL App side. As with the verifier side DE, the communication between the mDL App and the mDL reader may include some preliminary steps for reducing traceability. These preliminary steps 402 may include sending dynamic information that changes as the channel is established. The dynamic information can be sent by the mDL App. The dynamic information to be sent to the mDL reader can be read by an mDL App intermediate medium (e.g., a badge) owned by the police, which is not included in the verifier device or mobile device. The intermediate medium may include or carry a dynamically created quick response (QR) code, and the mDL App scans the QR code and sends the QR code as dynamic information to the mDL reader. In another example, the intermediate medium may include a near field communication (NFC) tag or other contactless tag, and the mDL App reads the NFC tag and sends the information of the NFC tag as dynamic information to the mDL reader. In another example, the intermediate medium may be synchronized with the mDL reader and the dynamic information may have been updated before the control situation begins.

[0028] There are additional advantages to using an intermediate medium that can be read by the mDL app. Typically, the police ask the driver to show their driver's license and then take the driver's license back to the police car, where the license can be properly checked. With mDL, it is unrealistic to consider that the police will take the mobile device from the driver and take it back to the police car. In addition, the police car is likely not equipped with an mDL reader. Portable mDL readers have many problems: they are easier to be stolen, there is a higher risk of impersonating the police, and the risk of damage (such as dropping) is increased.

[0029] The information scanned or read from the badge or other intermediary media can be used to identify the officer as a genuine police officer, and the channel opened between the mDL app and the mDL reader can be tied to the officer through the information carried by the intermediary media. Using this method, drivers don't have to hand their phone over to the police, and it can be used to ensure that the officer is genuine and not someone impersonating one. This eliminates the risk of handing the phone over to someone who isn't actually a police officer.

[0030] Figure 5is a diagram of various configurations of scannable or readable badges that can have different levels of information included in the badge. In Case 1, the badge can be referred to as a convenience badge. The badge contains information about the type of mDL app to be activated and displayed (e.g., one or more mDL reader communication profiles for the mDL app type). Once the appropriate mDL App is activated and optionally visible on the mobile screen, the scanned data (e.g., QR code) or read data (NFC tag data) can be sent as dynamic information.

[0031] In case 2, the badge can be called an authority badge. In addition to the mDL reader communication profile of the convenience badge with the App type to be activated and displayed, the authority badge also contains the mDL reader certificate from the authority. The mDL App verifies the mDL reader certificate through the recorded trusted authority and connects to the mDL reader associated with the badge accordingly. The mDL App can then share the encrypted DE data with the mDL reader over an encrypted communication channel. The DE can be digitally signed to provide the mDL App with a means to confirm the authenticity of the DE. The digital signature can be added by the authority that is trusted for establishing the connection.

[0032] In case 3, the badge includes an immediate response capability. In addition to the information in the issuing authority badge, the case 3 badge also includes an mDL reader request, which may include a certificate. The mDL app uses the recorded trusted authority certificate to verify the certificate and prepare an encrypted response to the request. The response can be presented as a barcode.

[0033] Back to Figure 4 , at 405, the mDL App reads information from the badge. If the intermediate medium is a convenience badge (Case 1 badge), the driver's mobile phone is used to read the badge. When the badge is a contactless tag, NDEF information is used to identify the type of App (e.g., mDL App) and the associated App is made active and visible on the mobile phone. When the badge includes a QR code instead of a contactless tag, the encoded NDEF information of the QR code is used to identify the type of App (e.g., mDL App) and the associated App is made active and visible on the mobile phone. Interaction with the user (e.g., to obtain user consent) may be performed.

[0034] When the intermediary medium is an issuing authority badge (Case 2 badge), the police badge is configured with an mDL reader certificate and contains communication establishment information. The police ask for the citizen's driver's license, and if the citizen has an mDL, the police present their badge for scanning. The mDL app receives the necessary information to read the badge (for example, if the badge includes a contactless tag).

[0035] At 410, the mDL App checks whether the certificate read from the badge is issued by a trusted authority. If the certificate is verified, at 415, the mDL App uses the communication profile information received from the badge to establish communication with the mDL reader. If the certificate is not verified, the device interaction is abandoned at 420. As in the case of authenticator-side interaction, the connection with the mDL reader may not occur immediately. After the interaction data is transmitted, the connection to the mDL reader and the next communication can occur based on the proximity of the mobile communication device to the mDL reader.

[0036] At 425, the mDL App generates a temporary key and prepares the device interaction data (DE). Instead of receiving a temporary key from the mDL reader as in the case of vDE, the badge's certificate may include a public key. The key derived from the public key is the secret key (SK DE ) and use SK DE DE is encrypted. At 430, the encrypted DE is sent to the mDL reader along with the mDL App temporary key. The mDL reader receives the encrypted DE along with the mDL App temporary key and uses this information to calculate the derived key and SK DE , and then decrypts the received DE. At 435, the mDL reader sends a request, and at 445, the mDL App sends a response. In some embodiments, the mDL App encrypts the response using an encryption method that utilizes a temporary key (for example, the information may be encrypted using a temporary key, or the information may be encrypted using a key derived from the temporary key). Optionally, the mDL App may verify the identity of the reader terminal at 440, for example, by at least one of a digital signature or a certificate. When the police badge is a Case 2 badge, more details of the process of mDL device interaction starting from the mDL App side can be found in Appendix A.

[0037] When the intermediate medium is a case 3 badge, the information contained in the badge includes a request (e.g., a CBOR-encoded request) that is typically sent from an mDL reader for both convenience badges and issuing authority badges. The police ask for the citizen's driver's license and, if the license is an mDL, the police ask the mobile phone to scan or otherwise read the badge's information. The mDL App checks that such a certificate is valid and issued by a trusted authority. The mDL App generates a temporary key and prepares the encrypted response data without waiting for a request from the mDL reader. SK DEThe response data is encrypted and the response data is encoded along with the public key to present the response as a barcode (or other optical code). The MDL reader scans the barcode and calculates SK DE , and decrypts the response. When the police badge is a case 3 badge, an example of an extension of the process of mDL device interaction starting from the mDL App side can be found in Table 1.

[0038] In the case where the device interaction is an mDL device interaction initiated from the mDL App side, the mDL App response to the mDL reader request may be transmitted using the Internet. Figure 6 6 is a block diagram of a portion of another example of an mDL system. A citizen's identity holder device 605 (e.g., a mobile device with mDL) and an issuing authority's verifier device 610 (e.g., an mDL reader) are shown. The mDL App sends device interaction data and the verifier device 610 returns a request. The response from the mDL App is sent over the Internet 615 (e.g., using HTTPs POST). Some benefits of using the Internet to transmit responses include: taking advantage of high-speed connections (e.g., upcoming 5G) when they are available, thereby being able to send responses without always opening a new secure communication channel; and using the Internet as a universal method for transmitting responses to any kind of mDL reader.

[0039] The challenge of using the Internet for mDL communication is that, although both the mDL app and the mDL reader are aware of their respective Internet connection status, the devices need to exchange status to enable peer-to-peer communication over the Internet. To address this problem, the request from the mDL reader can include a uniform resource locator (URL) to which the mDL app can respond (e.g., using HTTPs POST).

[0040] When the mDL reader has a good connection to the Internet, the mDL reader can include a URL. The mDL App can have the option of sending a response using an Internet channel or using a communication channel for mDL requests (for example, based on its Internet connection status or Internet availability). When the mDL App also has a good connection to the Internet, the mDL App can choose to send a response via the Internet. One or both of the mDL reader and the mDL app can determine the connection status of the network by attempting to communicate with the server identified in the URL via the Internet. The response can be transmitted to the mDL reader via the Internet connection using a trusted web server identified by the URL. The mDL reader receives an encrypted response from the mDL App, and the mDL reader can rely on the URL to retrieve the corresponding session.

[0041] Figure 7This is an example of including a URL in an mDL reader request. The URL to which the mDL app responds is provided by the mDL reader in the request portion of the optional terminal identification data sent by the mDL reader. Besides the fact that the request comes from the mDL reader, encrypted using a temporary key from the mDL app and contains a reference to the interaction data provided at a short distance, the mDL app can also utilize a trusted entity or entities to not only perform terminal identification but also authenticate the HTTPs connection.

[0042] In some examples, the HTTPs authentication is tied to the endpoint identity using the same certificate used to identify the request and the infrastructure front-end server. The endpoint identity, along with the HTTPs authentication using a trusted authority and the encrypted mDL request sent to the mDL app and referencing the DE data, ensures a sufficient level of trust in the HTTPs POST response data from the mDL app.

[0043] Figure 8 Another example of including a URL in an mDL reader request is the inclusion of the URL as part of the request as an optional field. Trust in the communication over the channel is based on the request being encrypted using information from the device interaction data. Trust in the communication comes from the secure DE / request exchange between the mDL reader and the mDL app, and assumes that the trusted authority presented to the app for sending HTTPs POST data is a trusted web server. This provides a similar level of security as when responding to a new communication channel, as the communication is based on interaction over a short distance and temporary keys from the mDL app and the mDL reader.

[0044] Figure 9 This is another example of including a URL in an MDL reader request. The request CBOR is modified to include a URL for the response. When the mDL reader is connected to the Internet and the mDL reader supports receiving responses via the Internet, the mDL reader can format the request to include a URL. When the mDL app receives a request with a URL and the mDL app supports sending responses via the Internet, the mDL app can use HTTPs POST to send the response.

[0045] Although neither the device interaction data nor the response data is modified, and therefore the security level is unchanged, and no security issues are foreseen when using an Internet channel, additional security can be provided by the HTTPs protocol. For example, when the mDL App establishes an HTTPs connection before returning an encrypted response, the mDL App can verify that the certificate from the mDL reader HTTPs interface is issued by a trusted authority. The trusted authority for such a response method can be managed at the mDL App level rather than by the mobile phone operating system (OS). In addition, when the mDL reader request includes a reader identification, both the reader identification certificate and the HTTPs authentication certificate can match.

[0046] Back to Figure 6 , the citizen presents their identity app to the verifier device 610 (e.g., an mDL reader) by sending device interaction data. The verifier device 610 is connected to a network (e.g., a cellular network) and the Internet 615. The verifier device 610 receives the device interaction data. The verifier device continues to communicate on one of the suggested communication channels provided as part of the interaction data and shares the request for information to the citizen's holder device 605. The request also includes a URL, in which case the holder device 605 (e.g., a mobile communication device) can publish a response to the request. The holder device can receive a request including a response to be sent to the URL.

[0047] The holder device is connected to a network that communicates with the network to which the verifier device is connected. The holder device prepares a response and conditionally selects to send the response to a URL from the verifier device. The holder device establishes an HTTPs connection to transmit the response.

[0048] During this process, the holder device can check one or more certificates from the HTTPs server to be trusted (for example, issued to the holder device or mDL App by a trusted authority). In addition, if the request includes an identification of the verifier device in the form of a certificate, the same certificate can be used by the HTTPs web server, and optionally verified by the mDL App as a match (for example, the certificate can be a certificate from the same trusted authority). Once communication to the specified URL is established, response data can be provided by the mDL App of the holder device 605. In some embodiments, the holder device uses the POST method to send a response over HTTPs. In another example, the holder device 605 can use PUT communication to send the response data, and the verifier device 610 can use PUT communication to issue a GET communication to obtain more information from the holder device 605.

[0049] mDL may be expected to support both domestic driver's licenses (DDPs) and international driver's licenses (IDLs). The challenge in supporting both types is that DDPs may include additional information and may use a local alphabet (which may not be the Latin alphabet) and language. These may not be supported by IDLs. In addition, a citizen may have a driver's license from more than one country. It is desirable for mDL to accommodate DDPs by being able to support additional DDP data elements while minimizing the data required for support. In addition, it is desirable to support the local alphabet of the DDP and the citizen's preferred language (which may be different from the DDP language). In addition, the mDL reader will not know that the citizen has a valid DDP for that country before sending the request.

[0050] To help support language differences in mDL, the device interaction data may include an optional field for the preferred language of the citizen (i.e., mDL holder). Figure 10 An example of device interaction data including optional fields is shown in FIG. However, because the preferred spoken language may not be specific to a single country, and because a single country may have multiple spoken languages, Figure 10 The method will not work for specifying a country code for DDP. Furthermore, Asian countries have different spoken languages, but some share the same written language. Therefore, device interaction should allow for a list of preferred languages. The preferred language can be different from the country code. This is better than simply defaulting to English when a single preferred language is not matched.

[0051] also, Figure 10 This approach doesn't adequately address some issues or doesn't address them efficiently. For example, optional terminal identification can provide the mDL app with sufficient information about domestic terminals, but this terminal identification occurs alongside the request from the mDL reader without knowing the citizen's DDP. This prevents minimizing the transfer of the required data to a single step. It's possible to request local data in a subsequent request, but this is inefficient.

[0052] right Figure 10An improvement to the method is to provide DE, request and response communications that adapt to DDP information. For example, the DE provides support for more than one preferred language of the holder of the mDL holder, which provides more options for communicating with the holder. The request from the mDL reader may include IDL data elements and may optionally include DDP data elements. This allows the mDL reader to request supplemental information from the DDP, request repeated information from the DDP, or a combination thereof. The mDL reader may also request one or both of car registration information and car insurance information from the mDL App. There is no need to define a standard for labels for DDP data elements. The response from the mDL App may also include IDL data elements and may optionally include DDP data elements.

[0053] For DE interactive communications, having the option of more than one preferred language supported by the DE communication provides a great benefit for Asian countries and to some extent Arab countries where the spoken language may be different but the written language may be common. Alternatively, the field specifying the language can be changed to the written language. The fall back can be an international language (e.g., English). Appendix B is a chart showing the DE data that supports preferred languages. In another alternative, the field can include a structure that lists more than one preferred language of the holder.

[0054] A request from an mDL reader may request data elements of the IDL and, optionally, data elements of the holder's DDP. Elements may be requested individually, or multiple data elements may be requested for multiple documents. The multiple documents may be from different issuing authorities. A request CBOR may be provided in two parts of the same request: one for the IDL data elements and the other for the DDP data elements. The request data field is shown in Appendix C. The DDP field allows requesting data objects (DO) for the local country.

[0055] The response from the mDL App may optionally include a DDP data element. The response may contain multiple data elements from multiple documents from multiple issuing authorities. The response data fields are shown in Appendix D. The example in Appendix C is for passive authentication. However, once the document identifier is provided, a different structure may be presented, as in Appendix E. Appendix F shows the resulting data fields.

[0056] The described systems, devices, and methods provide improvements to the mDL system. These improvements include a flexible system where device interactions can be initiated from either the mobile device side or the verifier side. The secure communication channel can be a channel used for device interaction or can be a network such as the Internet. The mDL system also provides support for preferred languages for the holder of the mDL.

[0057] Additional Examples and Disclosures

[0058] Example 1 includes the following subject matter (e.g., a method including steps, or a computer-readable medium including instructions that, when executed by a processing circuit, cause a device to perform the steps), the subject matter including: using a primary communication channel between the primary device and the secondary device to transmit information including a response uniform resource locator (URL) between the primary device and the secondary device; using the secondary device to determine a connection status of a network separate from the primary communication channel; when the status indicates that the network is available, sending, by the secondary device, a response to a request from the primary device via the network using the response URL, and sending the response via the primary communication channel when the status indicates that the network is unavailable.

[0059] In Example 2, the subject matter of Example 1 optionally includes: the primary device is a verifier device and the secondary device is a mobile communication device, and the method further includes transmitting interaction data between the primary device and the secondary device, and sending the verifier interaction data from the verifier device before the mobile interaction data is sent by the mobile communication device.

[0060] In Example 3, the subject matter according to Example 2 may optionally include including the URL in the interaction data sent by the verifier device.

[0061] In Example 4, the subject matter according to Example 2 may optionally include including the URL in the request from the verifier device.

[0062] In Example 5, the subject matter according to one or any combination of Examples 2 to 5 may optionally include the verifier interaction data comprising a digital signature indicating that the verifier interaction data is from a trusted source.

[0063] In Example 6, the subject matter of Example 1 optionally includes: the primary device is a verifier device, and the secondary device is a mobile communication device, and the method further includes transmitting interaction data between the primary device and the secondary device, and sending mobile interaction data from the mobile communication device before the verifier interaction data is sent by the verifier device.

[0064] In Example 7, the subject matter of Example 6 may optionally include encrypting the request using a temporary key provided to the verifier device along with the mobile interaction data.

[0065] In Example 8, the subject matter of one or both of Examples 6 and 7 may optionally include: obtaining, using a mobile communication device, information carried on an intermediate medium; and including information related to the mobile driver's license application in the mobile reference data.

[0066] In Example 9, the subject matter of one or any combination of Examples 1 to 8 optionally includes analyzing the network connection status by attempting to communicate with a server identified in the URL via the Internet, and wherein sending the response includes sending the response to the primary device via the Internet connection using a trusted web server identified by the URL.

[0067] In Example 10, the subject matter of one or any combination of Examples 1 to 9 may optionally include transmitting the information via the primary channel using one of a proximity-based communication protocol or a WiFi-aware communication protocol.

[0068] In Example 11, the subject matter according to one or any combination of Examples 1 to 10 may optionally include sending a request from the primary device including a certificate identifying the primary device as a trusted source to the secondary device.

[0069] In Example 12, the subject matter of one or any combination of Examples 1 to 11 optionally includes sending a request including lock information from the primary device, and the secondary device identifying the primary device as a trusted source by matching the lock information with a certificate previously received by the mobile communication device.

[0070] Example 13 may include the following subject matter (e.g., a method including steps or a computer-readable medium including instructions that, when executed by a processing circuit, cause a device to perform the steps) or may optionally be combined with one or any combination of Examples 1 to 12 to include such subject matter, the subject matter including: using a mobile communication device to read information carried on a medium between the mobile device and the verifier device, wherein the information includes a public key; encrypting device interaction data using the public key; sending the encrypted device interaction data from the mobile communication device to the verifier device, wherein the encrypted device interaction data includes the public key; receiving, by the mobile communication device, a request from the verifier device, the request including a temporary key encrypted using the sent public key; and sending, by the mobile communication device, a response encrypted using an encryption method that uses the temporary key.

[0071] In Example 14, the subject matter according to Example 13 may optionally include: the information read from the intermediate medium includes a certificate, and the method optionally further includes: determining, by the mobile communication device, whether the certificate belongs to a trusted authority; and transmitting, by the mobile communication device, the device interaction data to the verifier device in response to the mobile communication device determining that the certificate belongs to a trusted authority.

[0072] In Example 15, the subject matter of one or both of Examples 13 and 14 may optionally include the information carried by the intermediate medium including a digital signature indicating that the information is from a trusted source.

[0073] In Example 16, the subject matter according to one or any combination of Examples 13 to 15 may optionally include reading the information from the intermediate medium offline from the communication network.

[0074] In Example 17, the subject matter according to one or any combination of Examples 13 to 16 may optionally include the intermediate medium being a badge associated with an institution personnel, and the badge carrying the information.

[0075] In Example 18, the subject matter of Example 17 optionally includes: the badge carries information including a certificate, and the method optionally further includes: using a mobile communication device to determine whether the certificate is a valid certificate with a valid signature; when it is determined that the certificate is a valid certificate with a valid signature, generating an optical code at the mobile communication device; and presenting the optical code via a user interface of the mobile communication device.

[0076] In Example 19, the subject matter of Example 18 optionally includes: enabling a reader carried by agency personnel to use the optical code to calculate a decryption key; generating a response at the mobile communication device, the response including mobile driver's license information of a carrier of the mobile communication device; sending the response to the reader carried by the agency personnel; and decrypting the response at the reader using the decryption key.

[0077] Example 20 may include the following subject matter (e.g., a method comprising steps, or a computer-readable medium comprising instructions that, when executed by a processing circuit, cause a device to perform the steps) or may optionally be combined with one or any combination of Examples 1 to 19 to include such subject matter, the subject matter comprising: receiving a request for information from a mobile driver's license at a mobile communication device; in response to receiving the request, preparing a response at the mobile communication device that includes multiple data elements related to multiple documents; and sending the response from the mobile communication device.

[0078] In Example 21, the subject matter according to Example 20 may optionally include storing an electronic record including information related to the plurality of mobile driver licenses in a memory of the mobile communication device.

[0079] In Example 22, the subject matter of one or both of Examples 20 and 21 may optionally include storing an electronic record including a language preference of the user in a memory of the mobile communication device, wherein the language preference includes an indicator of a primary language of the user identified by the mobile driver's license.

[0080] In Example 23, the subject matter of Example 22 can optionally include: storing a country code identifier as part of the electronic record of the mobile driver's license; and including the country code identifier in the response, wherein the country code identifier is different from the language preference.

[0081] In Example 24, the subject matter according to one or any combination of Example 20 may optionally include the mobile communication device sending the response using a proximity-based wireless communication protocol.

[0082] In Example 25, the subject matter according to one or any combination of Examples 20-24 can optionally include: storing the additional language preference as part of the electronic record of the mobile driver's license; and including the additional language preference in the response.

[0083] In Example 26, the subject matter according to one or any combination of Examples 20 to 25 may optionally include sending a response including at least one of car registration information and car insurance information and a plurality of data elements related to a driver's license.

[0084] In Example 27, the subject matter according to one or any combination of Examples 20 to 26 may optionally include sending a response including a plurality of data elements related to a plurality of driver's licenses of the holder from different license issuers.

[0085] In Example 28, the subject matter according to one or any combination of Examples 20 to 26 may optionally include sending a response including a plurality of data elements related to a plurality of driver's licenses of the holder from different license issuers.

[0086] These non-limiting examples may be combined in any arrangement or combination. The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. As an illustration, the drawings show specific embodiments in which the invention may be practiced. These embodiments are also referred to herein as "examples". All publications, patents, and patent documents mentioned in this document are incorporated herein by reference in their entirety, as if individually incorporated by reference. If there is an inconsistent usage between this document and those documents incorporated by reference, the usage in the incorporated reference(s) should be considered to supplement the usage of this document; for contradictory inconsistencies, the usage in this document shall prevail.

[0087] Herein, as is common in patent literature, the terms "a" or "an" are used to include one or more than one, regardless of any other instance or usage of "at least one" or "one or more." In this document, unless otherwise indicated, the term "or" is used to represent a non-exclusive or, such that "A or B" includes "A but not B," "B but not A," and "A and B." Herein, the terms "including" and "in which" are used as the plain English equivalents of the respective terms "comprising" and "wherein." Furthermore, in the appended claims, the terms "including" and "comprising" are open-ended, that is, systems, apparatus, articles, combinations, formulations, or processes that include elements in addition to those listed after such terms in a claim are still considered to fall within the scope of the claim. Furthermore, in the appended claims, the terms "first," "second," and "third," etc., are used merely as labels and are not intended to impose numerical requirements on their objects.

[0088] The above description is intended to be illustrative and not restrictive. For example, the examples described above (or one or more aspects of the examples) can be used in combination with each other. Other embodiments may be used by those skilled in the art after consulting the above description. The abstract is provided to allow the reader to quickly determine the essence of the technical disclosure. The abstract is submitted with the following understanding: the abstract will not be used to interpret or limit the scope or meaning of the claims. In the above specific embodiments, various features can be grouped together to simplify the present disclosure. This should not be interpreted as meaning that: for any claim, the disclosed features that are not claimed for protection are all necessary. Instead, the subject matter may exist in the case of less than all the features of a particular disclosed embodiment. Therefore, the appended claims are hereby incorporated into the specific embodiments, wherein each claim is independently a separate embodiment, and it is expected that such embodiments can be combined with each other in various combinations or arrangements. The scope should be determined with reference to the appended claims together with the full range of equivalents enjoyed by these claims.

[0089] Appendix A

[0090] Case 2:

[0091]

[0092]

[0093] Continue with the default process M

[0094]

[0095] Terminate the default process M

[0096] Case 3 expansion:

[0097]

[0098]

[0099] Render the response directly as a QR code M

[0100]

[0101] Appendix B

[0102]

[0103]

[0104]

[0105] Appendix C

[0106]

[0107]

[0108]

[0109]

[0110]

[0111]

[0112] Appendix D

[0113]

[0114]

[0115]

[0116]

[0117] Appendix E

[0118]

[0119] Appendix F

[0120]

[0121]

[0122]

[0123]

[0124]

Claims

1. A method for device interaction, the method comprising: transmitting information including a response uniform resource locator (URL) between the primary device and the secondary device using a primary communication channel between the primary device and the secondary device; determining, using the secondary device, a connection status of the network by initiating a connection to a network separate from the primary communication channel; sending, by the secondary device, a response to the request from the primary device via the network using the response URL when the status indicates that the network is available, and sending the response via the primary communication channel when the status indicates that the network is unavailable; Using the auxiliary device to obtain information carried on the intermediate medium; causing the secondary device to automatically open a mobile driver's license application stored on the secondary device; as well as Information related to the mobile driver's license application is included in the mobile interaction data.

2. The method according to claim 1, in, The primary device is a verifier device and the secondary device is a mobile communication device; and The transmitting of information includes transmitting interaction data between the primary device and the secondary device, and transmitting verifier interaction data from the verifier device before the mobile interaction data is transmitted by the mobile communication device.

3. The method according to claim 2, wherein: The response URL is included in the verifier interaction data sent by the verifier device.

4. The method according to claim 2, wherein: The response URL is included in the request from the verifier device.

5. The method according to claim 2, wherein: The verifier interaction data includes a digital signature indicating that the verifier interaction data is from a trusted source.

6. The method according to claim 1, in, The primary device is a verifier device and the secondary device is a mobile communication device; and Wherein, transmitting information includes transmitting interaction data between the primary device and the secondary device, and the mobile interaction data is sent from the mobile communication device before the verifier device sends the verifier interaction data.

7. The method according to any one of claims 1 to 6, wherein The request is encrypted using a temporary key provided to the primary device along with the mobile interaction data.

8. The method according to claim 1, wherein A network connection status is analyzed by attempting to communicate with a server identified in the response URL via the Internet, and wherein sending the response comprises sending the response to the primary device via an Internet connection using a trusted web server identified by the response URL.

9. The method according to any one of claims 1 to 6 or claim 8, wherein Transmitting information using the primary communication channel includes transmitting information via the primary communication channel using one of a proximity-based communication protocol or a WiFi-aware communication protocol.

10. The method according to any one of claims 1 to 6 or claim 8, wherein The request from the primary device includes a certificate identifying the primary device as a trusted source to the secondary device.

11. The method according to any one of claims 1 to 6 or claim 8, wherein The request from the primary device includes lock information, and the secondary device identifies the primary device as a trusted source by matching the lock information with a certificate previously received by the secondary device.

12. A method for establishing a communication channel between an application on a mobile communication device and an application on a verifier device, the method comprising: reading, using the mobile communication device, information carried on an intermediate medium separate from the mobile communication device and the verifier device, wherein the information includes a public key; encrypting device interaction data using the public key; sending encrypted device interaction data from the mobile communication device to the verifier device, wherein the encrypted device interaction data includes the public key; receiving, by the mobile communication device, a request from the verifier device, the request including a temporary key encrypted using the transmitted public key; and sending, by the mobile communication device, a response encrypted using an encryption method using the temporary key, The intermediate medium is a badge associated with an institution staff member, and the badge carries the information.

13. The method according to claim 12, wherein: The information read from the intermediate medium includes a certificate, and the method further comprises: determining, by the mobile communication device, whether the certificate belongs to a trusted authority; and The device interaction data is transmitted, by the mobile communication device, to the verifier device in response to the mobile communication device determining that the certificate belongs to a trusted authority.

14. The method according to claim 12, wherein: The information carried by the intermediate medium includes a digital signature indicating that the information comes from a trusted source.

15. The method according to claim 12, wherein: Reading the information from the intermediate medium includes reading the information offline from a communication network.

16. The method according to claim 12, wherein: The badge carries information including a credential, and the method further comprises: determining, using the mobile communication device, whether the certificate is a valid certificate having a valid signature; generating an optical code at the mobile communication device when the certificate is determined to be a valid certificate with a valid signature; and The optical code is presented via a user interface of the mobile communication device.

17. The method according to claim 16, comprising: enabling a reader carried by personnel of the agency to use the optical code to calculate a decryption key; generating a response at the mobile communication device, the response including mobile driver's license information of a carrier of the mobile communication device; sending the response to the reader carried by the facility personnel; as well as The response is decrypted at the reader using the decryption key.

18. A computer-readable medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform steps comprising: transmitting information including a response uniform resource locator (URL) between the primary device and the secondary device using a primary communication channel between the primary device and the secondary device; determining a connection status of the network by initiating a connection to a network separate from the primary communication channel; sending a response to the request from the primary device via the network using the response URL when the status indicates that the network is available, and sending the response via the primary communication channel when the status indicates that the network is unavailable; Using the auxiliary device to obtain information carried on the intermediate medium; causing the secondary device to automatically open a mobile driver's license application stored on the secondary device; as well as Information related to the mobile driver's license application is included in the mobile interaction data.

19. A computer-readable medium comprising instructions that, when executed by a processing circuit, cause the processing circuit to perform steps for establishing a communication channel between an application of a mobile communication device and an application of a verifier device, the steps comprising: reading information carried on an intermediate medium separate from the mobile communication device and the verifier device, wherein the information includes a public key; encrypting device interaction data using the public key; sending encrypted device interaction data from the mobile communication device to the verifier device, wherein the encrypted device interaction data includes the public key; receiving a request from the verifier device, the request including a temporary key encrypted using the sent public key; and sending a response encrypted using an encryption method using the temporary key, The intermediate medium is a badge associated with an institution staff member, and the badge carries the information.

Images