Patent Grant
12184640
The technology described in this patent document relates to communicating information from a mobile device over a communication channel. In particular it relates to communicating sensitive information related to mobile identity documents, such as mobile driving licenses (mDLs), over a trusted communication channel.
A mDL provides the functionality of a driving license on a mobile device (e.g., smartphone, tablet, etc.). It also allows the latest information to be available to police office in the event of a traffic stop. However, information related to a driving license can be sensitive personal information that should only be communicated with an mDL reader or with the infrastructure of the issuing authority via a trusted communication channel.
A mobile driving license (mDL) includes an application (mDL App) that executes on a mobile communication device (e.g., smartphone, tablet, etc.). In the event of a traffic stop, information related to the license may be communicated with the mDL reader of the issuing authority of the driving license. This information can be sensitive information for the driver and the information needs to be communicated between the mDL reader and the mobile device using a trusted channel.
At 215, the public key is used by the mDL App to encrypt the communication and encrypted DE data is sent over the established communication channel. The mDL App sends DE data encrypted either with the received public key or with a derived key. At 220, an mDL reader Request is sent encrypted using the derived key. The public key may be used to determine a new derived key. At 225, the encrypted Response is returned from the mDL reader.
The encrypted DE data may not be sent right away. In some embodiments, after the engagement data is transferred, the next communication may occur based on the proximity of the mobile communication device and the verifier device. For example, the engagement data may be transferred according to 205, and then the communication pauses. The subsequent processes continue according to a near proximity protocol (e.g., Blue tooth, a near field protocol, etc.) when the mobile device is in near proximity to the verifier device.
At 310, the mDL App engages with the mDL reader (the verifier device) using the QR code, an NFC handover, or the “click to app” link within the web page (e.g. deep linking to an App calling default App for identity), or other means to receive the information to connect to an identified reader. As part of the device engagement, the mDL App receives a public key from the mDL reader which is used in the process of encrypting the device engagement data (e.g., to share the mDL ephemeral public key) prior to sending other DE data from the mDL App to the mDL reader.
At 315, the mDL App may check if the information acquired so far has been issued by a device with a certificate from a trusted authority. At 320, the mDL checks for the particular case where the vDE comes with the request and acts accordingly (e.g., where a certificate is included in the request). At 325, if the request is not included, the mDL App sends its DE data encrypted. At 330, the mDL receives an encrypted Request. At 335, the mDL App optionally authenticates the mDL reader terminal. At 340, the mDL App sends a Response. If the request is included at 320, then at 330 the mDL App sends the encrypted Response. In subsequent steps, the exchanges of information continue.
The public key acquired from the verifier side as part of the vDE can be a somewhat ephemeral key and the key may be changed at the discretion of the mDL reader to prevent tracking. The public key may be provided as part of a certificate from the trusted authority (TA). The mDL App may check the certificate over a list of TAs and connect accordingly. Alternatively, the vDE data may be signed by an authority trusted by the mDL App and the mDL App proceeds accordingly. The vDE may include the option to connect using a private WiFi network, or using the Internet. The vDE may provide a uniform resource identifier (URI) to which to connect, and a certificate pinning information to match with the certificate from the transport layer security (TLS) session. All exchanged information may be encrypted point-to-point between the mDL App and the mDL reader, and all intermediate components or the front end web server of the infrastructure only see encrypted data.
The vDE provides some options not available for a mDL App side DE. For example, the vDE may include a signature, and the vDE data may have information for connection over the Internet (e.g., the mDL reader web front end URI and the certificate pinning for the TLS). Connecting using the Internet may cause the communication between the mDL App and the mDL reader to be faster because only the communication channel may only have to secured once for the communication session. It may also contain the request itself so that the mDL App can send the response immediately. The vDE data can be encoded using concise binary object representation (CBOR) and further presented using QR code, NFC data exchange format (NDEF) tag, or URI. The vDE data does not necessarily have to be presented by the mDL reader itself but the vDE data can be presented in a web page, a badge, etc. Other readable media may be used. The mDL App can scan the QR to start the device engagement. The NFC handover using NDEF Tag can be used to trigger the mDL App to start the device engagement. A URI containing the CBOR vDE may be used to open the appropriate App on the mobile device for the mDL App.
The mDL App side DE provides a definite structure to send the ephemeral key of the mDL App. It also provides for additional communication methods that the mDL App may prefer. The mDL DE data is sent encrypted either using the public key or a key derived from the public key and an ephemeral private key of the mDL reader whose pubic key is included with the DE data.
The additional communication methods may include an offline request. Typically, the mDL reader request is delivered after the DE data has been received by the mDL reader. The mDL reader request can be encrypted using a key derived from the mDL reader ephemeral public key and mDL reader ephemeral private key. When the mDL reader ephemeral public key matches the mDL reader ephemeral private key, sending the mDL reader public key is unnecessary. The mDL reader request could be part of the vDE data. In that case the request CBOR can be added to the vDE data and shared without encryption. This approach presents the advantage that the mDL App can respond immediately. This might be of particular interest for over the internet verification where the response relies on TLS, which can provide the necessary elements to confirm the mDL reader is authorized to receive the response.
The additional communication methods may include an offline response. The mDL response is typically delivered encrypted using the derived key from mDL reader public key and mDL private key. For the offline request, the mDL request may be concatenated to the vDE data. The offline response is returned along with the mDL App public key for the mDL reader to be able to compute the derived key used as a decryption key to decrypt the response.
There are additional advantages in using an intermediate media readable by the mDL App. Typically, a police officer asks for a driving license from the driver and then takes it back to the police car where proper check of the license can be performed. For an mDL, it is not realistic to consider that the police officer would take the mobile device away from the driver and back to the officer's car. Also, it is likely that the police officer's car is not be equipped with the mDL reader. Portable mDL readers present many issues: easier theft, higher risk of impersonation of a police officer, increased risk of damage (e.g., from dropping), etc.
The information scanned or read from the badge or other intermediate media can be used to identify that the officer is genuinely a police officer and the channel opened between the mDL App and the mDL reader can be bound to the police officer through the information carried by the intermediate media. Using this approach, the driver does not have to turn their phone over to the police officer, and it can be used to ensure that the police officer is genuine and not someone posing as a police office. This eliminates the risk of giving the phone to someone who is actually not a police officer.
In Case 2, the badge can be referred to as an Issuing Authority badge. In addition to the mDL Reader communication profiles of the Convenience badge with the type of App to active and display, the Issuing Authority badge contains an mDL reader certificate from the Issuing Authority. The mDL App validates the mDL reader certificate over recorded Trusted Authorities and accordingly connects to the mDL Reader associated with the badge. The mDL App may then share encrypted DE data with the mDL reader over the encrypted communication channel. The DE can be digitally signed to provide a means for the mDL App to confirm authenticity of the DE. The digital signature may be added by an Issuing Authority that is trusted for establishing a connection.
In Case 3, the badge includes instant response capability. In addition to the information in the Issuing Authority badge, the Case 3 badge includes the mDL reader Request that may include the certificate. The mDL App validates the certificate using recorded Trusted Authority certificates and prepares an encrypted Response to the Request. The Response may be presented as a bar code.
Returning to
When the intermediate media is an Issuing Authority badge (Case 2 badge), the police officer badge is configured with the mDL reader certificate and the badge contains the communication establishment information. The police officer asks for the citizen's driving license, and if the citizen has an mDL, the officer present their badge for scanning. The badge is read (e.g., the badge includes a contactless tag) by the mDL App receives the information necessary.
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 engagement is discarded at 420. As in the case for verifier side engagement, the connection to the mDL reader may not occur right away. After the engagement data is transferred, the connection to the mDL reader and the next communication may occur based on the proximity of the mobile communication device and the mDL reader.
At 425, the mDL App generates ephemeral keys and prepares the device engagement data (DE). The certificate of the badge may include a public key, instead of receiving an ephemeral key from the mDL reader as in the vDE case. The key derived from the public key is a secret key (SKDE), and DE is encrypted using the SKDE. At 430, the encrypted DE is sent to the mDL reader with the mDL App ephemeral key. The mDL reader receives the encrypted DE along with the mDL App ephemeral key and uses the information to compute the derived key and SKDE and then deciphers the received DE. At 435, the mDL reader sends the Request, and at 445 the mDL App sends the Response. In some embodiments, the mDL App encrypts the Response using a cryptographic method that uses the ephemeral key (e.g., the information may be ciphered using the ephemeral key, or the information may be encrypted using a key derived from the ephemeral key). Optionally, the mDL App may verify identification of the reader terminal at 440, for example by at least one of a digital signature or a certificate. More detail of the process of mDL device engagement started from the mDL App side when the officer's badge is a Case 2 badge can be found in Appendix A.
When the intermediate media is a Case 3 badge, the information contained in the badge includes the request (e.g., a CBOR-encoded request) normally sent from the mDL reader for the convenience badge and issuance authority badge. The police officer askes for the citizen's driving license, and if the license is mDL, office asks to scan or otherwise have the mobile phone read the information of the badge. The mDL App checks whether such a certificate is valid and issued by a Trusted Authority. The mDL App generates ephemeral keys and prepares the encrypted response data without waiting for a Request from the mDL reader. The response data may be encrypted using SKDE and encodes the data along with a public key to present the response as a bar code (or other optical code). The MDL reader scans the bar code, computes the SKDE, and deciphers the Response. An example of an extension to the process of mDL device engagement started from the mDL App side when the officer's badge is a Case 3 badge can be found in Table 1.
For the case where the device engagement is of mDL device engagement started from the mDL App side, the mDL App Response to an mDL reader Request can be communicated using the Internet.
A challenge to using the Internet for mDL communications is that while both the mDL App and the mDL reader know their respective Internet connectivity status, the devices need to exchange status to enable peer-to-peer communication over the Internet. To resolve this issue, the Request from the mDL reader can include a Universal Resource Locator (URL) that the mDL App can respond to (e.g., using HTTPs POST).
The mDL reader may include the URL when the mDL reader has a good connection to the Internet. The mDL App may have the option (e.g., based on its Internet connection status or Internet availability) to send the Response using the Internet channel or to use the communication channel used for the mDL Request. The mDL App may elect to send the Response via the Internet when the mDL App also has a good connection to the Internet. One or both of the mDL reader and the mDL app may determine the connectivity status of the network by attempting a communication via the Internet with a server identified in the URL. The Response may be transmitted via an Internet connection to the mDL reader through a trusted web server identified using the URL. The mDL reader receives a ciphered Response from the mDL App, and the mDL reader may rely on the URL to retrieve the corresponding session.
In some examples, the HTTPs authentication is bound to the terminal identification using the same certificate used to identity the Request and the front end server of the infrastructure. The terminal identification along with the HTTPs authentication using the trusted authority, and the mDL Request being ciphered for sending to the mDL App and referencing the DE data ensures a sufficient level of trust for the HTTPs POST Response data from the mDL App.
While neither the device engagement data nor the response data is modified, and therefore the security level is unchanged and no security issues are foreseen in using an Internet channel, additional security can be provided by the HTTPs protocol. For example, when the mDL App establishes the HTTPs connection prior to returning the encrypted response, the mDL App may verify that the certificate from the mDL reader HTTPs interface is issued by a Trusted Authority. Trusted Authorities for such response method may be managed at the mDL App level rather than by the mobile phone operating system (OS). Furthermore, when the mDL Reader request includes Reader Identification, both the Reader Identification certificate and HTTPs authentication certificate could match.
Returning to
The Holder device is connected on a network in communication with the network the Verifier device is connected to. The Holder device prepares the Response and conditionally elects to send the Response to the URL from the Verifier Device. The Holder device establishes an HTTPs connection to communicate the Response.
During this process the Holder device may check for a certificate or certificates from the HTTPs server to be trusted (e.g., issued by a trusted authority to the Holder device or mDL App). Additionally, if the Request included identification of the Verifier device in a form of a certificate, the same certificate could be used by the HTTPs web server and optionally verified as matching by the mDL App (e.g., the certificate it could be a certificate from the same trusted authority). Once the communication to the specified URL has been established, the Response data can be provided by the mDL App of the Holder device 605. In some embodiment the Holder device uses POST method to send the response over HTTPs. In another example, the Holder device 605 may us a PUT communication to send the Response data, and the Verifier device 610 may take advantage of the PUT communication to issue a GET communication to get more information from the Holder device 605.
It may be desired for an mDL to support both a domestic driving permit (DDP) and an international driving license (IDL). A challenge for supporting both types is that the DDP may include additional information, and the DDP may use the local alphabet (which may not be a Latin alphabet) and language. These may not be supported by an IDL. Further, the citizen may have a driving license from more than one country. It is desirable for an mDL to accommodate the DDP by being able to support the additional DDP data elements while minimizing the data needed for the support. Also, it is desired to support the local alphabet of the DDP and the preferred language of the citizen (which may be different from the DDP language). Additionally, an mDL reader won't know about a citizen's possession of a valid DDP for the country ahead of sending a Request.
To help support language differences in an mDL, the device engagement data may include an optional field for the citizen's (i.e., the mDL holder) preferred language. An example of device engagement data including an optional field is shown in
Further, the approach of
An improvement to the approach of
For the DE engagement communication, having the option for the DE communication to support more than one preferred language provides great benefits for Asian countries and to some extent Arabic countries where the spoken language may be different, but the written language may be common. Alternatively, the field that specifies the language could be changed for written language. The fall back may be to an international language (e.g., English). Appendix B is a chart showing the DE data that supports a preferred language. In another alternative, the field may include a structure to list more than one preferred language of the holder.
The Request from the mDL reader can request data elements of the IDL and optionally request data elements of the DDP of the holder. The elements can be requested individually, or multiple data elements for multiple documents may be requested. The multiple documents may come from different issuing authorities. The Request CBOR could be provided in two parts of the same Request: one part for the IDL data elements and one for the DDP data elements. The Request data fields are shown in Appendix C. The DDP fields allow for data objects (DOs) for the local country to be requested.
The Response from the mDL App may optionally include DDP data elements. 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 of Appendix C is for passive authentication. However, once the document identifier is provided a different structure could be presented as in Appendix E. Appendix F shows the resulting data fields.
The systems, devices, and methods described provide improvements for a mDL system. These improvements include a flexible system where device engagement can begin from either the mobile device side or the verifier side. A secure communication channel can be either the channel used for device engagement or can be a network such as the Internet. The mDL system also provides for support of preferred languages for the holder of the mDL.
Example 1 includes subject matter (such as a method including steps, or a computer readable medium including instructions that when performed by processing circuitry cause a device to perform steps) comprising transferring information including a response uniform resource locator (URL) between a primary device and a secondary device using a primary communication channel between the primary device and the secondary device; determining, using the secondary device, status of connectivity of a network separate from the primary communication channel; transmitting, by the secondary device, a response to a request from the primary device via the network using the response URL when the status indicates the network is available, and transmitting the response via the primary communication channel when the status indicates the network is unavailable.
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 communications device, and the method further including transferring engagement data between the primary device and the secondary device, and verifier engagement data is transmitted from the verifier device prior to mobile engagement data being transmitted by the mobile communications device.
In Example 3, the subject matter of Example 2 optionally includes the URL being included in the engagement data transmitted by the verifier device.
In Example 4, the subject matter of Example 2 optionally includes the URL being included in the request from the verifier device.
In Example 5, the subject matter of one or any combination of Examples 2-5 optionally includes the verifier engagement data including a digital signature indicating that the verifier engagement data is from a trusted source.
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 communications device, and the method further including transferring engagement data between the primary device and the secondary device, and mobile engagement data is transmitted from the mobile communications device prior to verifier engagement data being transmitted by the verifier device.
In Example 7 the subject matter of Example 6 optionally includes encrypting the request using an ephemeral key provided to the verifier device with the mobile engagement data.
In Example 8, the subject matter of one or both of Examples 6 and 7 optionally includes obtaining, with the mobile communications device, information carried on intermediate media; and including information related to the mobile driving license application in the mobile engagement data.
In Example 9, the subject matter of one or any combination of Examples 1-8 optionally includes analyzing the status of network connectivity by attempting a communication via the Internet with a server identified in the URL, and wherein transmitting the response includes transmitting the response via an Internet connection to the primary device through a trusted web server identified using the URL.
In Example 10, the subject matter of one or any combination of Examples 1-9 optionally includes transferring information via the primary channel using one of a proximity-based communication protocol or a WiFi aware communication protocol.
In Example 11, the subject matter of one or any combination of Examples 1-10 optionally includes transmitting a request from the primary device that includes a certificate that identifies the primary device to the secondary device as a trusted source.
In Example 12, the subject matter of one or any combination of Examples 1-11 optionally includes transmitting a request from the primary device that includes pinning information, and the secondary device identifies the primary device as a trusted source by matching the pinning information to a certificate previously received by the mobile communication device.
Example 13 can include subject matter (such as a method including steps, or a computer readable medium including instructions that when performed by processing circuitry cause a device to perform steps) or can optionally be combined with one or any combination of Examples 1-12 to include such subject matter, comprising reading, using the mobile communication device, information carried on media intermediate the mobile device and the verifier device, wherein the information includes a public key; encrypting device engagement data using the public key; transmitting the encrypted device engagement data from the mobile communication device to the verifier device, wherein the encrypted device engagement data includes the public key; receiving, by the mobile communication device, a request from the verifier device that includes an ephemeral key encrypted using the transmitted public key; and sending, by the mobile communication device, a response encrypted using a cryptographic method that uses the ephemeral key.
In Example 14 the subject matter of Example 13 can optionally include the information read from the intermediate media including a certificate, and the method optionally further includes determining, by the mobile communication device, whether the certificate belongs to a trusted authority; and communicating, by the mobile communication device, the device engagement data to the verifier device in response to the mobile communication device determining that the certificate belongs to a trusted authority.
In Example 15, the subject matter of one or both of Examples 13 and 14 optionally includes the information carried by the intermediate media including a digital signature indicating that the information is from a trusted source.
In Example 16, the subject matter of one or any combination of Examples 13-15 optionally includes reading the information from the intermediate media offline from a communication network.
In Example 17, the subject matter of one or any combination of Examples 13-16 optionally includes the intermediate media being a badge associated with authority personnel, and the badge carries the information.
In Example 18, the subject matter of Example 17 optionally includes the badge carries information that includes a certificate, and the method optionally further includes determining, using the mobile communication device, if the certificate is a valid certificate with a valid signature; generating an optical code at the mobile communication device when determining the certificate is a valid certificate with a valid signature; and presenting the optical code via a user interface of the mobile communication device.
In Example 19, the subject matter of Example 18 optionally includes enabling a reader carried by the authority personnel to compute a decryption key using the optical code; generating a response at the mobile communication device that include mobile driving license information for a carrier of the mobile communication device; transmitting the response to the reader carried by the authority personnel; decrypting the response at the reader with the decryption key.
Example 20 can include subject matter (such as a method including steps, or a computer readable medium including instructions that when performed by processing circuitry cause a device to perform steps) or can optionally be combined with one or any combination of Examples 1-19 to include such subject matter, comprising receiving, at a mobile communication device, a request for information from a mobile driving license; in response to receiving the request, preparing, at the mobile communication device, a response that includes multiple data elements related to multiple documents; and transmitting the response from the mobile communication device.
In Example 21, the subject matter of Example 20 optionally includes storing an electronic record in memory of the mobile communication device that includes information related to the multiple mobile driving licenses.
In Example 22, the subject matter of one or both of Examples 20 and 21 optionally includes storing an electronic record in memory of the mobile communication device that includes a language preference of a user, wherein the language preference comprises an indicator of a primary language for a user identified by the mobile driving license.
In Example 23, the subject matter of Example 22 optionally includes storing a country code identifier as part of the electronic record for the mobile driving license; and including the country code identifier in the response, wherein the country code identifier is different from the language preference.
In Example 24, the subject matter of one or any combination of Examples 20 optionally includes the mobile communication device transmitting the response using a wireless proximity-based communication protocol.
In Example 25, the subject matter of one or any combination of Examples 20-24 optionally includes storing an additional language preference as part of the electronic record for the mobile driving license; and including the additional language preference in the response.
In Example, 26, the subject matter of one or any combination of Examples 20-25 optionally includes transmitting a response that includes multiple data elements related to a driving license and at least one of an automobile registration and automobile insurance information.
In Example, 27, the subject matter of one or any combination of Examples 20-26 optionally includes transmitting a response that includes multiple data elements related to multiple driving licenses of the holder from different license issuers.
In Example, 28, the subject matter of one or any combination of Examples 20-26 optionally includes transmitting a response that includes multiple data elements related to multiple driving licenses of the holder from different license issuers.
These non-limiting examples can be combined in any permutation or combination. The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments in which the invention can be practiced. These embodiments are also referred to herein as “examples.” All publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In this document, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, composition, formulation, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments can be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is provided to allow the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. In the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, the subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment, and it is contemplated that such embodiments can be combined with each other in various combinations or permutations. The scope should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
Appendix A
Case2:
Case 3 Extension:
Appendix B
aThis field is mandatory if there are fields that are already authorized by the mDL.
bshall be present only if Boolean flag (tag 01) is FALSE or absent from [A6].
coptional additional language is more than one makes sense
Appendix C
Appendix D
Appendix E
Appendix F
This application This application is a U.S. National Stage filing under 35 U.S.C. § 371 of PCT Patent Application No. PCT/EP2019/082767, filed on Nov. 27, 2019, which claims priority to U.S. Patent Provisional Application Ser. Nos. 62/771,845, filed Nov. 27, 2018, 62/771,849, filed Nov. 27, 2018, 62/771,886, filed Nov. 27, 2018, and 62/779,864 filed Dec. 14, 2018.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2019/082767 | 11/27/2019 | WO |
| Publishing Document | Publishing Date | Country | Kind |
|---|---|---|---|
| WO2020/109400 | 6/4/2020 | WO | A |
| Number | Name | Date | Kind |
|---|---|---|---|
| 10356087 | Vetter | Jul 2019 | B1 |
| 10366378 | Han | Jul 2019 | B1 |
| 20030005078 | Turicchi et al. | Jan 2003 | A1 |
| 20140171065 | Graessley | Jun 2014 | A1 |
| 20140273820 | Narayan | Sep 2014 | A1 |
| 20150100490 | Agapitov | Apr 2015 | A1 |
| 20160127898 | Gupta | May 2016 | A1 |
| 20180315127 | Chappell | Nov 2018 | A1 |
| 20190065724 | Dudley | Feb 2019 | A1 |
| 20190149527 | John | May 2019 | A1 |
| Number | Date | Country |
|---|---|---|
| 1351789 | May 2002 | CN |
| 101047495 | Oct 2007 | CN |
| 10210031 | Jun 2011 | CN |
| 2284816 | Feb 2011 | EP |
| WO-2016099809 | Jun 2016 | WO |
| WO-2020109400 | Jun 2020 | WO |
| Entry |
|---|
| “Computer network”, Wikipedia, Retrieved from the Internet: URL:<https://en.wikipedia.org/w/index.php?title=Computer_network&oldid=869526861>, (Nov. 19, 2018), 25 pgs. |
| “International Application Serial No. PCT/EP2019/082767, International Search Report mailed Apr. 6, 2020”, 7 pgs. |
| “International Application Serial No. PCT/EP2019/082767, Invitation to Pay Additional Fees mailed Feb. 13, 2020”, 11 pgs. |
| “International Application Serial No. PCT/EP2019/082767, Written Opinion mailed Apr. 6, 2020”, 8 pgs. |
| “Canadian Application Serial No. 3,121,032, Examiners Rule 86(2) Report mailed Jan. 5, 2024”, 3 pgs. |
| “European Application Serial No. 19817167.0, Communication Pursuant to Article 94(3) EPC mailed Jul. 12, 2024”, 6 pages. |
| “Chinese Application Serial No. 201980090708.1, Office Action mailed Sep. 30, 2024”, with English translation, 25 pages. |
| Number | Date | Country | |
|---|---|---|---|
| 20220337582 A1 | Oct 2022 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62771845 | Nov 2018 | US | |
| 62771849 | Nov 2018 | US | |
| 62771886 | Nov 2018 | US | |
| 62779864 | Dec 2018 | US |
