Cryptographic services for browser applications

Abstract
This disclosure relates to the provision of cryptographic services to web browsers, and more specifically, to systems and methods for providing cryptographic results to a browser from a cryptographic device over a persistent peer-to-peer connection. A method for obtaining cryptographic services for a browser executing a webpage comprising the steps of establishing a persistent peer-to-peer connection over a wireless Internet Protocol communication network between the browser and a cryptographic device, in response to receiving user input to the webpage, transmitting, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, for cryptographic processing of the data by the cryptographic device using a cryptographic key stored on the cryptographic device to produce a cryptographic result, and receiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device, and providing the cryptographic result to the webpage.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is the U.S. National Stage application of PCT Application No. PCT/AU2020/051020 filed Sep. 25, 2020, designating the United States, which claims priority to Australian Provisional Patent Application No. 2019903591 filed Sep. 25, 2019, the contents of which are each incorporated herein by reference in their entirety.


TECHNICAL FIELD

Aspects of this disclosure relate generally to the provision of cryptographic services to web browsers and more specifically to systems and methods for providing cryptographic services to a browser by a cryptographic device.


BACKGROUND

Many webpages now facilitate or require the use of cryptographic functions to provide authentication, encryption and other security features to users.


For example, two step (or two factor) authentication is a method of authenticating a user by utilising a secret that the user knows, such as a password, and a cryptographic secret that the user can generate through use of a cryptographic device and can provide to the webpage. This form of authentication is becoming more prevalent in line with the increased demand for enhanced security.


Additionally, many web enabled applications now provide functionality that enables a user to apply encryption and decryption to data for privacy purposes, or to interface with cryptographic applications such as blockchain ledgers.


Unfortunately, users often find the use of cryptographic services provided by web pages to be cumbersome and inefficient to use. Furthermore, an increased risk of unintentional or malicious security breaches means that there is a focus on ensuring that such cryptographic services be highly resistant to hacking or tampering by malicious parties.


Accordingly, there is a need for a private, secure and convenient means of providing authentication and cryptography services to web enabled applications, such as browsers.


Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each of the appended claims.


SUMMARY

There is provided a method for obtaining cryptographic services for a browser executing a webpage. The method comprises establishing a persistent peer-to-peer connection over a wireless Internet Protocol communication network between the browser and a cryptographic device, in response to receiving user input to the webpage, transmitting, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, for cryptographic processing of the data by the cryptographic device using a cryptographic key stored on the cryptographic device to produce a cryptographic result, and receiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device, and providing the cryptographic result to the webpage.


The method may further comprise the steps of receiving, by the cryptographic device, from the browser, data via the persistent peer-to-peer connection between the browser and the cryptographic device, performing, by the cryptographic device, the cryptographic function on the data using the cryptographic key stored on the cryptographic device, to produce the cryptographic result, and transmitting, by the cryptographic device, the cryptographic result to the browser, over the persistent peer-to-peer connection.


The persistent peer-to-peer connection may remain established over multiple iterations of the steps of transmitting, by the browser, the data over the persistent peer-to-peer connection to the cryptographic device, and receiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device.


The cryptographic device may send confidential data stored on the cryptographic device, from the cryptographic device to the browser. Furthermore, the cryptographic device may sign, encrypt, verify or decrypt the data with the cryptographic key to produce the cryptographic result.


The browser may embed the cryptographic result in the webpage. Additionally, the browser may provide the cryptographic result to a server hosting the webpage, which may result in the browser receiving an updated webpage from the server hosting the webpage.


A persistent peer-to-peer connection may be established via the browser signalling information. The cryptographic device may receive the signalling information, and in response, transmit response information, to the browser, necessary to establish a peer-to-peer connection. The signalling information may be signalled ‘out of band’, for example via a Quick Response (QR) code displayed within the browser.


The signalling information may include an authentication challenge, which may be signed by the cryptographic device by applying an authentication key to the challenge information to produce a challenge response.


The cryptographic device may transmit a signalling response back to the browser, which include cryptographic device identification information and the challenge response. The response may also include a public key which is complementary to the private key stored on the cryptographic device.


The software describing the browser's establishment and management of the peer-to-peer connection may be injected into the webpage by the browser. The software may be described by JavaScript libraries which are invoked by a call to the libraries embedded in the webpage code.


According to another aspect of the disclosure, there is provided a method of obtaining cryptographic services for a browser executing a webpage on a user device, the method comprising establishing a persistent peer-to-peer connection between the browser and a cryptographic device, in response to receiving user input to the webpage, transmitting, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, applying, by the cryptographic device, a cryptographic function to the data using a cryptographic key stored on the cryptographic device, to produce a cryptographic result; and transmitting, by the cryptographic device, the cryptographic result to the browser, over the persistent peer-to-peer connection.


According to another aspect of the disclosure, there is provided a method of providing cryptographic services to a browser executing a webpage, the method comprising receiving data from the browser, via a persistent peer-to-peer connection between the browser and a cryptographic device, performing, by the cryptographic device, a cryptographic function on the data using a cryptographic key stored on the cryptographic device, to produce a cryptographic result, and transmitting, by the cryptographic device, the cryptographic result to the browser, over the persistent peer-to-peer connection.


According to another aspect of the disclosure, there is provided a browser executing a webpage on a user device, the browser configured to, establish a persistent peer-to-peer connection between the browser and a cryptographic device, in response to receiving a user input to the webpage, transmit data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device for cryptographic processing of the data using a cryptographic key stored on the cryptographic device, to produce a cryptographic result, and receive the cryptographic result over the persistent peer-to-peer connection from the cryptographic device.


According to another aspect of the disclosure, there is provided a cryptographic device configured to establish a persistent peer-to-peer connection between a browser executing a webpage, and an cryptographic application executing on the cryptographic device, receive data from the browser, via the persistent peer-to-peer connection, perform a cryptographic function on the received data, using a cryptographic key stored on the cryptographic device, to produce an cryptographic result, transmit the cryptographic result to the browser, via the persistent peer-to-peer connection.





BRIEF DESCRIPTION OF DRAWINGS

Examples will now be described with reference to the following drawings, in which:



FIG. 1 illustrates a network diagram;



FIG. 2 is block diagram of the cryptographic device of FIG. 1;



FIG. 3 is a flowchart illustrating a method, as performed by a browser, of establishing a peer-to-peer connection between a browser and a cryptographic device;



FIG. 4 is a flowchart illustrating a method, as performed by a cryptographic device, of establishing a peer-to-peer connection between a browser and a cryptographic device;



FIG. 5 is a flowchart illustrating a method, as performed by a browser, for obtaining cryptographic services;



FIG. 6 is a flowchart illustrating a method, as performed by a cryptographic device, for providing cryptographic services;



FIG. 7 is a message flow diagram illustrating request and response messages being transmitted between a browser and a cryptographic device; and



FIGS. 8a-f illustrates a browser displaying webpages.





DESCRIPTION OF EMBODIMENTS
Network Overview


FIG. 1 illustrates a network diagram 100 in accordance with an aspect of this disclosure. A user 102 is in operation of a device, exemplified by a personal computer 104, displaying a webpage within a web browser 105 executing on the personal computer 104. It is to be understood that in other examples, the browser may be executing on a mobile phone, or other suitable web enabled device.


The user 102 is also in operation of a cryptographic device 106, exemplified by a mobile phone. The mobile phone includes software and hardware configured to perform cryptographic functions using one or more cryptographic keys 114 stored on the cryptographic device 106.


It is to be understood that the description of the cryptographic device as a mobile phone is not intended to be limiting. A cryptographic device in accordance with this disclosure could be a device which is specifically dedicated to providing cryptographic processing services and providing cryptographic results over a peer-to-peer connection, a full function device such as a personal computer, a headless device without a screen and interface, or any device which is capable of performing the functionality as attributed to the cryptographic device herein.


Instead of having to establish a connection with the browser each time a cryptographic service is required, the web browser 105 executing on the personal computer 104 is persistently in communication with the mobile phone via a persistent peer-to-peer connection 108. The web browser 105 is also in communication with a web server 112 via an internet connection 110, such that the web browser is able to download and display webpages from web server 112 via internet connection 110.


In cases where authentication of the user is required, one or more public keys 118 associated with the user 102 may be stored in memory storage 116 which is accessible by the web server 112. The memory storage 116 may be located within web server 112 or remote from web server 112, as depicted in FIG. 1.


Another party 120 is also illustrated. The other party may be another user or application. The other party 120 is in operation of a cryptographic device 122, which in the example shown in FIG. 1 is a mobile phone. The other party may be a communication partner of the user 102, with which the communication partner has exchange public keys via the Public Key Infrastructure, or the like. If the other party is a communication partner of the user 102, one or more public keys 124 associated with the user 102 may be stored on the other party's device 122. A role of the other party 120 will be described in subsequent sections.


Cryptographic Device


FIG. 2 is a block diagram of the cryptographic device 106 of FIG. 1. The cryptographic device 106 comprises a processor configured to control operation of the device through the execution of a cryptographic application stored, at least in part, on memory storage 212. Memory storage 212 also stores identification information associated with the one or more user identities of the user 102. The identification information may include user names, email addresses, user identification numbers, and the like.


Additionally, memory storage 212 stores one or more cryptographic keys 114 to be used by the cryptographic application in the provision of cryptographic services to the browser 105 and in the authentication of the user's identify, if this is required.


The memory storage 212 may comprise a plurality of individual or interconnected memory storage components. Furthermore, the memory storage 212 may comprise components internal to the cryptographic device, and/or may comprise separate components which are in communication with the cryptographic device, or may comprise a combination thereof.


The device 106 further comprises a network interface 208. According to the embodiment illustrated in FIG. 2, the network interface 208 is a wireless internet interface, which is configured to receive and transmit information wirelessly to and from the internet.


The device 106 further comprises one or more input/output interfaces 214. The I/O interface may comprise: a camera, configured to capture images and provide said images to the processor; a user input in the form of a touch screen, number pad or keyboard; and an output in the form of a display screen or a status light. Other input/output interfaces may be provided which enable the user to provide and receive information to the device.


The processor of the cryptographic device executes a cryptographic application, which controls the provision of cryptographic processing services and manages the establishment and operation of the peer-to-peer connection.


The cryptographic device 106 may include a cryptographic hardware accelerator 210 which is configured to perform cryptographic processing, such as encryption, decryption and signing in hardware. The inclusion of a cryptographic hardware accelerator may be desirable to improve the performance or the security of the cryptographic device.


The cryptographic processing services may be provided by the cryptographic application executing on the processor, or by the hardware accelerator, or by a combination thereof. The cryptographic device may be configured to provide asymmetric cryptography, such as RSA or others, and may also be configured to provide symmetric cryptography.


Cryptographic Keys

The cryptographic keys stored within memory storage 212 may include one or more keys which are used to provide cryptographic services to the browser. The type of keys stored on the device will depend upon the type of cryptographic services provided by the device. The cryptographic device may perform asymmetrical or symmetrical cryptography, or a combination of the two.


Asymmetric cryptography uses public and private keys to encrypt and decrypt data. The public key may be shared with other parties; however, the private key remains secure and unknown to other parties. In contrast, symmetric cryptography uses only a single key to apply and remove a cryptographic function on data.


Where the device 106 provides asymmetric cryptographic processing, the cryptographic device may generate a public/private key pair. Alternatively, the cryptographic keys may be pre-configured during manufacture or setup of the cryptographic device. The public key may be stored in memory storage 212 and communicated to communication parties as required. In contrast, private keys will not be communicated external to the device, and will be stored in memory storage 212. The cryptographic device may also store public keys received from communication partners.


As noted above, memory storage 212 may comprise a plurality of different memory components. For enhanced security, private keys may be stored in a memory component which is resistant to malicious access by an external party.


Since the cryptographic device performs cryptographic processing for the browser, advantageously, the private key remains stored on the device, and there is no need to communicate the private key outside the device 106. Accordingly, there is no need to entrust the user's private key with another party, such as a web server. As the private key is not stored by another party, there is no concern that the private key will be disclosed unintentionally by the other party, or discovered through a security breach of the other party.


The cryptographic keys stored in memory storage 212 may also include one or more keys used to authenticate the identity of the user. A key used to authenticate the identity of the user may be a private key which is associated with a corresponding public key, in the case that asymmetric cryptography is used during authentication. Although enhanced security would result from an authentication key differing from the one or more cryptographic keys used to provide cryptographic services to the browser, it is envisaged that, for some implementations, a cryptographic device may use the same cryptographic key for the provision of cryptographic services to the browser and for the authentication of the user's identity.


Communication Parties

As illustrated in FIG. 1, a communication partner 120 of a user may exist. A communication partner is another user to which the user 102 has provided a public key 124 corresponding to the user's private key (one of 114). The communication partner may also have provided the user 102 with a public key associated with a private key of the communication partner. Through use of the user's public key 124, the communication partner 120 can provide cryptographically processed information, such as digital signatures and encrypted information, to the user 102. Furthermore, though the user's use of the communication partner's public key, the communication partner can verify the authenticity of data signed by the communication partner's public key, or decrypt data encrypted by the communication partner's public key.


Multiple User Identities

In some situations, it may be desirable for the cryptographic device to be configured to maintain a plurality of identities for the user (or set of users) of the device. Situations in which this may be advantageous include where the user operates both a personal and business identity, or where the user has an administrator role in addition to their user role. Alternatively, or additionally, the user may elect to maintain a plurality of identities and private keys for security or privacy purposes.


To accommodate a plurality of identities, the cryptographic device may be configured to store a plurality of cryptographic keys within the memory store 212, so that each user identity may be associated with a unique cryptographic key for enhanced security. The user of the device may select one of the plurality of user identities when establishing a persistent peer-to-peer connection with a browser. Additionally, it is to be understood that a cryptographic device may establish a plurality of separate persistent peer-to-peer connections between one or more browsers, whereby each of the separate connections may be associated with a different user identity.


Configuration Process

An exemplary mechanism for configuring the cryptographic device and the browser to perform methods in accordance with this disclosure, will now be described. However, it will be appreciated that there are numerous mechanisms and variations via which the cryptographic device and the browser may be configured to perform methods in accordance with this disclosure.


The user 102 downloads a cryptographic application 107 from an application server to cryptographic device 106 and installs the cryptographic application. The application server may be the same entity as web server 112. The user 102 triggers the execution of the cryptographic application and creates a user account, for an identity of the user, by providing identifying information such as a user name and authentication information such as a password, phrase or other secret information known to the user. This identifying information and authentication information is provided by the cryptographic application to the server 112 for storage. It is noted, however, that persistent storage of the identifying and authentication information on server 112 is not essential and the keys maybe the only data stored in cryptographic device 106.


If two-factor authentication is desired, the cryptographic application may also generate a private/public key pair to be associated with the user identity for authentication purposes, storing the private key in the memory storage 212, and providing the public key to the server 112, or a storage location 116 accessible by the server 112. Accordingly, it will be possible for the server who has access to the public key, to verify the identity of the user by applying the public key to a digital signature that the user has signed with their private key.


The user 102 uses the browser to download a webpage 105 of a website from the web server 112. The user may log into the website 105 using the same user identification information used to create an account for the cryptographic application. Accordingly, the user may be logged into both the website and the cryptographic application on the cryptographic device; however this is not essential.


The user may now take steps to establish a persistent peer-to-peer connection between the browser and the cryptographic device, so that the cryptographic device may provide cryptographic services to the browser.


Persistent Peer-to-Peer Connections

A persistent peer-to peer connection provides a communication channel between two internet connected applications, e.g. a browser 105 and a cryptographic application 107 executing on a cryptographic device.


Communication across the persistent peer-to-peer connection may be achieved via various communication protocols. One peer-to-peer communication protocol which may be applied in accordance with aspects of this disclosure is the Web Real-Time Communication (WebRTC) application programming interface (API). WebRTC provides web browsers and other internet connected applications with real-time communications via simple APIs, including the RTCPeerConnection API, which provides a mechanism for establishing a peer-to-peer connection, and the RTCDataChannel API, which provides a mechanism to transmit arbitrary data over the peer-to-peer connection.


Accordingly, a peer-to-peer connection, allows peer devices to communicate bit streams, files, audio or video communications and other data forms, by providing a direct communication channel between peers, over the Internet Protocol. This eliminates the need for a dedicated server to relay communications from a transmitting peer to a receiving peer.


Signalling

To establish a peer-to-peer connection between one internet connected application and another internet connected application, to the participants perform a signalling process, whereby identifying and locating information is exchanged between the peer applications. Signalling allows the applications to exchange metadata to coordinate communication.


Exemplary information communicated during the signalling process includes network data, which reveals where the applications are located on the internet (IP address and port) so that each application can locate the other. Other information that may be communicated during the signalling process includes session control information which determines when to initialise, close and modify the peer-to-peer connection; and configuration data, which indicates the functional range of the applications, and what type of data can be communicated across the connection. Additionally, signalling may include an authentication and authorisation mechanism to verify the identity of the user.


Signalling Methods

One method of implementing a peer-to-peer connection is to provide signalling information via a server; however, there are situations in which it may be undesirable to use a server to facilitate the signalling process due to limited server bandwidth, speed or privacy concerns. Accordingly, it may be desirable to provide a signalling mechanism that does not necessitate the use of a server, to establish a peer-to-peer connection.


Signalling information may be sent from a first peer to a second peer ‘out of band’, meaning that the signalling information is transmitted via a communication means that is not the channel over which the peer-to-peer connection will be established. One method for transmitting the signalling information ‘out of band’ is to provide the signalling information as a QR code which can be displayed on a display of the initiating peer device. A responding peer can then receive the signalling information by capturing the QR code using a camera input.


An initiating peer may transmit signalling information to a responding peer through other ‘out of band’ mechanisms including, but not limited to, SMS, email, Near Field Communications, Bluetooth, hardwired connection, manual input or via USB.


Embodiment—Establishing a Persistent Peer-to-Peer-Connection

A method of establishing a persistent peer-to-peer connection between a browser and a cryptographic device, using a QR code to transmit the signalling information, will be described with reference to FIG. 3, which illustrates a method 300 as performed by a browser 105, and FIG. 4, which illustrates a complementary method 400 as performed by a cryptographic application 107 executing on a cryptographic device, in the form of a mobile phone 106. The exemplary methods illustrated in FIGS. 3 and 4 use the WebRTC protocol to establish the persistent peer-to-peer connection.


In step 302, the user authenticates themselves to the webpage executing within the browser, by entering a username and password to log into the webpage. Alternatively, some other means of user authentication may be utilised. In some situations, step 302 may not be required, as the cryptographic device may provide user identification during the establishment of the persistent peer-to-peer connection.


At step 302, it may also be appropriate for the user or the browser to configure parameters pertaining to the type of cryptographic services that are desired.


In step 304, in response to receiving an input trigger from the user, such a mouse click on a webpage button or URL, the browser displays a QR code which encodes signalling information to initiate the establishment of a persistent peer-to-peer connection between the browser 105 and the cryptographic device 106. The signalling information includes the public-facing IP address of the browser, as well as the port and transport protocol to be used for the persistent peer-to-peer connection. The signalling information may also include additional information, such as information which identifies the webpage.


Signalling Via QR Code

The mobile phone scans 404 the QR code using the phone's camera. The image of the QR code is then provided to a cryptographic application executing on the phone. In step 406, the cryptographic application decodes the QR code to extract the signalling information.


Authentication Challenge

In some applications, it may be desirable to authenticate, during establishment of the persistent peer-to-peer connection, that the cryptographic device is appropriately associated with user identity used to log into the browser. In other applications, this authentication process may not be needed or desired; for example, if the webpage allows connections as a guest, or where the user's identity has been otherwise authenticated.


In the embodiment illustrated in FIGS. 3 and 4, the browser requires the authentication of the cryptographic device in relation to the user's logged in identity. Accordingly, the signalling information provided in the QR code, in step 304, also includes authentication challenge data, which will be used to authenticate that the cryptographic device is associated with the user identity used to log in to the browser. The authentication challenge data may be a pseudo-randomly generated bit-string.


In step 408, the cryptographic application determines the authentication challenge data from the QR code, and in step 410, the cryptographic device calculates a signature of the challenge data using an authentication key stored on the cryptographic device, to produce signed authentication challenge data. The authentication key may be the private key of a public/private key pair which identifies the user identity by which the user logged into the cryptographic device and the browser in steps 302 and 402, respectively.


In step 412, the cryptographic application prepares a signalling response message, which includes cryptographic device identification information, such as an IP address and a port of the cryptographic device. The cryptographic device identification information may also include a list of cryptographic services supported by the device. The signalling response message also includes the signed authentication challenge data.


The cryptographic application then transmits 412 the signalling response message, via the internet, to the browser at the IP address and port specified in the QR code.


In step 306, the browser receives the signalling response message from the cryptographic device. Accordingly, now both the browser and the cryptographic device know the connection details (IP address and port) of the other peer, and therefore a persistent peer-to-peer connection can be established. However, in the exemplary embodiment illustrated in FIGS. 3 and 4, the browser requires authentication of the user's identify before establishment of the persistent peer-to-peer connection.


In step 308, the browser extracts the signed authentication challenge data from the signalling response message received from the cryptographic device, and provides the signed authentication challenge data to the web server 112. Retrieving the public key 118 associated with the user identity with which the user logged into the web page, the web server 112 verifies that the authentication challenge data has been signed with the user's private key, by considering the challenge data with the digital signature and the user's public key.


If there is a discrepancy which indicates that the private key used to sign the authentication challenge data is not complementary to the public key associated with the user's logged in identity, then the browser may elect to abort 314 the establishment of the persistent peer-to-peer connection.


Otherwise, the browser considers that the user's identity has been authenticated, and the browser 105 proceeds with negotiating session parameters 312, 414 with the cryptographic device 106 over the persistent peer-to-peer connection 108.


In accordance with the WebRTC API, the Session Description Protocol (SPD) may be used to describe the parameters of the persistent peer-to-peer connection, including the types of media to be exchanged between the browser and the cryptographic device, transport protocols, bandwidth information and other metadata, as desired to be negotiated.


Once the session parameters have been settled, the persistent peer-to-peer connection is established 316, 416 and the provision of cryptographic services to the browser, may begin.


Browser Method


FIG. 5 illustrates a method 500 for obtaining cryptographic services for a browser executing a webpage. In step 504, the browser takes steps to establish the persistent peer-to-peer connection with the cryptographic device. The establishment of the persistent peer-to-peer connection may occur in response to the browser receiving user input such as the click of a webpage button, or a URL.


An exemplary method for establishing a persistent peer-to-peer connection has been described in relation to FIGS. 3 and 4; however, alternative methods for establishing a persistent peer-to-peer connection may be utilised. Once the peer-to-peer connection has been established, the browser awaits a user input 506 to indicate that cryptographic processing is requested.


The user input 506 can take a variety of forms. By way of non-limiting examples, the user input 506 may be in the form of a mouse-click on a webpage button or hyperlink, selecting text and right clicking to select a menu option, the use of the browser navigation icons or menu.


In step 508, the browser forms a request message in the form of a data packet which includes including data to be cryptographically processed by the cryptographic device and other information, as required, to specify the parameters of the cryptographic processing. It is envisaged that in some cases, it will not be necessary to specify the parameters of the cryptographic processing, in particular, in situations where the cryptographic device is configured to only provide one processing function, or where the processing function to be performed by the device has already been specified during the establishment of the persistent peer-to-peer connection.


In step 510, the browser waits for and receives a response message from the cryptographic device over the peer-to-peer connection. The response message contains the result of the cryptographic processing of the data by the cryptographic device. In response to receiving this cryptographic result, the browser provides the cryptographic result to the webpage 512. Depending upon the configuration of the webpage, the browser provides the cryptographic result to the webpage via various means, including, but not limited to, updating the webpage to display the cryptographic result, embedding or entering the cryptographic result into the code of the webpage, entering the result into a web form input of the web page, providing the result as an AJAX HTTP request, or a HTML parameter value. Additionally, or alternatively, the browser may provide the cryptographic result to the server 112 hosting the webpage, which may result in the server 112 providing a revised or new webpage to be displayed in the browser 105. Alternatively, the cryptographic result may remain local to the webpage, and not be transmitted to the webserver or other applications.


Following, step 512, the method of the browser returns to step 506 in which the browser waits to receive further input from the user. Notably and advantageously, the peer-to-peer connection is persistent, which means it remains established and open for multiple iterations of steps 506 to 512. Therefore, further requests can be processed with minimal latency, and with less user input.


Device Method


FIG. 6 illustrates a method 600 performed by the cryptographic device 106, according to one aspect of the present disclosure.


In step 602, the cryptographic device 106 establishes a persistent peer-to-peer connection 108 with the web browser 105. An exemplary method for establishing a persistent peer-to-peer connection has been described in relation to FIGS. 3 and 4; however, alternative methods for establishing connection 108 may be utilised.


In step 604, the cryptographic device 106 waits to receive a request message from the browser 105 over the persistent peer-to-peer connection 108. The request message may be in the form of a data packet containing an indication of the cryptographic function requested to be performed. The data packet may also contain data to which the cryptographic function is to be applied, or an indication of such data, and additional information as required by a particular embodiment. The format and contents of the request message may be configured during the establishment of the peer-to-peer connection, or may be preconfigured into the browser and the cryptographic device.


In step 606, cryptographic device 106 analyses the request message transmitted by the browser over the peer-to-peer connection to determine the cryptographic function to be applied, and the data to which that function should be applied. Depending upon the configuration of the cryptographic device, the device may also seek confirmation from the user to proceed with performing the cryptographic function as requested. The device may seek confirmation by displaying the details of the cryptographic function request on a display of the device, and then wait to receive input from the user to thereby confirm that the cryptographic processing should proceed.


The device 106 then selects an appropriate cryptographic key 114 from the memory storage 212. In embodiments where a plurality of cryptographic keys are stored in memory storage 212, the selection of the appropriate key may depend upon the user identity under which the persistent peer-to-peer connection was established, the type of cryptographic processing requested by the browser, the type of data to be cryptographically processed, or other factors.


The device 106 then performs cryptographic processing 606 on the determined data, using the selected cryptographic key, to produce a cryptographic result. In step 608, the cryptographic result is then packaged by the device into a response message which is transmitted back to the browser via the persistent peer-to-peer connection.


The method of the device then returns to step 604, whereby the device waits for further request messages from the browser to be received over the persistent peer-to-peer connection. Notably and advantageously, the peer-to-peer connection which was established in step 602 is persistent, which means that it remains established through multiple iterations of steps 604, 606 and 608.


Transport Layer Encryption

To ensure transmissions between the browser and the cryptographic device are secure, a transport layer encryption protocol may be applied to messages transmitted over the persistent peer-to-peer connection. An exemplary transport layer encryption protocol is Datagram Transport Layer Security (DTLS), which is designed to protect data privacy and prevent eavesdropping and tampering. It will be appreciated, however, that many other transport layer encryption protocols that are compatible with the Internet Protocol may be used.


Transport layer encryption may be applied to request messages transmitted by the browser to the cryptographic device. Furthermore, transport layer encryption may be applied to response messages transmitted by the cryptographic device to the browser. Accordingly, the cryptographic result embedded in the response message, may be further encrypted due to the application of transport layer encryption.


Persistent Peer-to-Peer Connection


FIG. 7 is a message flow diagram 700 which illustrates request and response messages being transmitted between the browser 105 and the cryptographic device 106, over an established peer-to-peer connection 108, in accordance with an aspect of this disclosure. At the establishment of the persistent peer-to-peer connection 108, there may be a series of messages 705 transmitted between the browser and the cryptographic device which negotiate the parameters of the communication session.


Messages 706 and 708 are a request and response pair, in which the browser has requested cryptographic processing from the device, and has received a cryptographic response from the cryptographic device Similarly, messages 710 and 712 are another request and response pair, in which the browser has requested further cryptographic processing from the device, and has received a further cryptographic response from the cryptographic device.


Advantageously, multiple request and response pairs may be transmitted over the persistent peer-to-peer connection while established, as illustrated by request and response messages 714 and 716. Advantageously, the browser need not establish a connection each time cryptographic processing is required.


Eventually, the browser may determine that the services of the cryptographic device are no longer required, for example, if the user logs out of the webpage, or takes action to sever the persistent peer-to-peer connection. The browser may then take steps to close the persistent peer-to-peer connection, thus freeing up resources associated with the connection. If the peer-to-peer connection is a WebRTC connection, the connection maybe closed by invoking the RTCPeerConnection.close( ) method, which terminates agents associated with the WebRTC connection. A close message 718 may be transmitted, which triggers the cryptographic device to close the connection, and to cease listening for further request messages via the connection.


It is understood that a peer-to-peer connection may close unexpectedly, due to a fault at the browser or at the cryptographic device, or a network fault. To ameliorate the effect of a closure of the connection, and to enable fast reestablishment of a connection, the browser may store the connection details (e.g. IP address and port) of the cryptographic device so that the connection may be reactivated through the renegotiation of session parameters.


Embodiment—Browser Connecting

An embodiment of the methods as described in FIGS. 5 and 6, will now be illustrated with reference to FIGS. 8a-f.



FIGS. 8a-f illustrates a browser 802 displaying webpages 803a-f. Webpages 803a-f are illustrative of one or more webpages of a website in which users can post messages to a message board. Various forms of message boards exist, including those within social media platforms. Message boards enable users to post content, which is attributed to the user and viewable or accessible by other parties.


The browser task bar 804 is located at the top of the browser and provides navigational control to the user of the browser. Located in the middle of the webpage 803a is a web form element 806a in the form of a text box. The user may enter data into this text box in the usual manner


To the right of the webpage 803a, is an interface 808a which indicates whether the browser is connected to a cryptographic device via a persistent peer-to-peer connection. As indicated by the unlocked padlock icon 809, the browser illustrated in FIG. 8 is not currently connected to a cryptographic device via a persistent peer-to-peer connection. A Connect button 810, is provided under the padlock icon 809. A user may click the Connect button 810 to trigger the browser to initiate the establishment of a persistent peer-to-peer connection to a cryptographic device.



FIG. 8b illustrates the browser 802 displaying a modified version 803b of webpage 803a, as a result of the user clicking the Connect button 810 on webpage 803a. In the example illustrated in FIG. 8b, the browser 802 displays a Scan to Connect box 812 in the middle of webpage 803b. This box contains a QR code 814 which encodes signalling information sufficient to initiate the establishment of a persistent peer-to-peer connection between the browser 802 and a cryptographic device.


The further steps taken by the browser and the cryptographic device to establish the persistent peer-to-peer connection have been described with regards to FIGS. 3 and 4.


Embodiment—Signing


FIG. 8c illustrates the webpage 803c, executing in browser 802, upon establishment of the persistent peer-to-peer connection between the browser 802 and the cryptographic device. The locked padlock icon 809c provides a visual representation to the user that the peer-to-peer connection is currently established.


It can be seen that the user has entered the text “Hello world” 807 into web form element 806c. To post the message directly to the message board, so that other users may see the message, the user may click on the Post button 819c. However, the user may want to provide assurance that the message 807 to be posted to the message board originated from that user, and that the message has not been altered before being posted to the message board. Accordingly, the user may elect to sign the message by calculating a signature over the message contents. To achieve this, the user clicks on the Sign button 818, as indicated by the shading pattern of button 818. In response, the browser packages the user's message 807 into a request for cryptographic processing by signing, and transmits the request to the cryptographic device over the peer-to-peer connection. The cryptographic device applies a digital signature to the user's message 807, for example, by applying a one-way hash of the user's message using a public/private key pair stored in memory storage 212, in accordance with the steps 604 to 608 of FIG. 6, and transmits the digital signature to the browser in a response message.


The browser receives the digital signature and, in accordance with the example illustrated in FIG. 8d, provides the signature to the web page. The webpage displays the digital signature 817 below the user's message 807 in the web form element 806d. Alternatively, a browser in accordance with this disclosure, may not display the digital signature within the browser, but may embed the digital signature information within data associated with the webpage. The browser may visually depict that the user's message 807 has been signed through the use of different colouring, shading, location upon the webpage, indicative icons or the like.


It is noted that, the browser may initiate the message signing process upon posting the message, as a matter of course, or as dependent upon the configuration of the webpage or the user. Furthermore, a browser in accordance with this disclosure, may initiate the posting of the user's message 807 upon signing the message, as a matter of course, or as dependent upon the configuration of the webpage or the user.



FIG. 8e illustrates the browser 802 with the user's message 821 and its associated signature 822 posted to the message board.


Embodiment—Encrypting

In addition to the option of signing the message, as provided by the Sign button 818, the user has the option of encrypting the message 807 for decryption by communication partner 120. Such message encryption, as performed by Author C, is illustrated in relation to message 826.


To encrypt the message 807, the user clicks on the Encrypt button 820. In response, the browser packages the user's message 807 into a request for cryptographic processing by encryption, and transmits the request to the cryptographic device over the persistent peer-to-peer connection. The cryptographic device encrypts the user's message 807 using the communication partner's public key stored on the cryptographic device, for example in accordance with the steps 604 to 608 of FIG. 6, and transmits the encrypted message to the browser, as a cryptographic result, in a response message.


The browser receives the encrypted message and provides the cryptographic result to the webpage. As exemplified by message 826, the webpage may display the encrypted message in association with the user's identity.


Embodiment—Verifying


FIGS. 8c-e also illustrate message verification functionality, according a further aspect of the present disclosure. As indicated by status box 808c-e in FIGS. 8c-e, a peer-to-peer connection remains established between the browser and a cryptographic device. A Verify button 827 is collocated with a message 824 posted by exemplary author, Author B. Message 824 is also collocated with digital signature 825, which provides prime facia indication that message 824 has been signed by Author B.


A user of browser 802 may use the cryptographic device to verify that the digital signature 825 associated with message 824 has been produced by Author B. In the exemplary scenario as illustrated in FIG. 8a-e, the user of browser 802 and the cryptographic device is a communication partner of Author B, and has exchanged public keys with Author B via the Public Key Infrastructure. Accordingly, the cryptographic device 106 stores two keys associated with Author B: a public key to be used when transmitting information to Author B; and a private key to be used when receiving information from Author B. The public key which is complementary to the stored private key has been provided to Author B, and is used by Author B to calculate a signature 825 of message 824.


Accordingly, when the user clicks on the Verify button 827 collocated with message 824 and digital signature 825, the browser forms a request message containing message 824, digital signature 825, information identifying Author B (such as a username), and an indication that the request pertains to a verification function. The browser transmits this request message to the cryptographic device via the established peer-to-peer connection.


Upon receipt of the request message, the cryptographic device determines the private key associated with Author B, and uses the private key to determine whether the digital signature 825 transmitted in the request message, has been produced over message 824 and Author B's private key. The cryptographic device then forms a response message, to be transmitted to the browser over the peer-to-peer connection, including a cryptographic result which either verifies the validity of digital signature 825, or refutes the validity of digital signature 825, in accordance with the cryptographic device's determination.


The browser provides the cryptographic result to the webpage. Depending upon the functionality coded in the webpage, the webpage may indicate a verified signature through a change in colour, shading, collocated icons or otherwise. Similarly, a webpage may indicate a refuted signature by changing the appearance of the message 824 and digital signature 825, or by removal of the same.


Embodiment—Decrypting


FIGS. 8c-e also illustrate message decryption functionality, according a further aspect of the present disclosure. As indicated by status box 808c-e in FIGS. 8c-e, a persistent peer-to-peer connection remains established between the browser and a cryptographic device. A Decrypt button 828 is collocated with a message 826 posted by exemplary author, Author C.


Message 826 has been encrypted using asymmetric encryption prior to posting by Author C, using a public cryptographic key associated with the user. In order for the user of the browser 802 to view the unencrypted contents of message 826, it will be necessary to decrypt message 826 using the user's private cryptographic key.


In the exemplary scenario as illustrated in FIG. 8c-e, the user of browser 802 and the cryptographic device is a communication partner of Author C, and has exchanged public keys with Author C via the Public Key Infrastructure. Accordingly, the cryptographic device currently stores a public key associated with Author C, and a private key for communication with Author C. The public key which is complementary to the private key for communication with Author C has been provided to Author C, and is used by Author C to produce encrypted message 826.


Accordingly, when the user clicks on the Decrypt button 828 collocated with encrypted message 826, the browser forms a request message containing encrypted message 826, information identifying Author C (such as a username), and an indication that the request pertains to a decryption function. The browser transmits this request message to the cryptographic device via the established peer-to-peer connection.


Upon receipt of the request message, the cryptographic device retrieves from the memory source 812 a public cryptographic key associated with Author C and suitable to decrypt encrypted message 826. The cryptographic device then decrypts encrypted message 826 by applying the public cryptographic key, and returns the decrypted message, as a cryptographic result, to the browser, in a response message, via the persistent peer-to-peer connection 108.


The browser provides the cryptographic result to the webpage. Depending upon the functionality coded in the webpage, the webpage may display the decrypted message from Author C in place of the encrypted message 826. The cryptographic result may remain local to the webpage, and not transmitted to the webserver or other applications.


Signing, Verifying and Decrypting Files and Other Data

In relation to FIG. 8a-e, there has been described methods of signing text based data (i.e. messages posted to a message board), verifying signatures associated with text based data, encrypting and decrypting text based message; however, the above described techniques may also have application in signing, verifying, encrypting and decrypting data other than text messages posted to a message board.


In particular, the methods and devices described herein may be applied to applications such as the signing of documents of certificate, transcripts, medical prescriptions, photographs and any data to which encryption and/or signatures may be applied using a cryptographic key.


Embodiment—Uploading Files

A cryptographic device in accordance with another aspect of the present disclosure, may be configured to transmit confidential information from the cryptographic device to the browser securely. For example, FIG. 8f illustrates browser 802 displaying a further version of webpage 803f, which enables the uploading of encrypted or signed files. The locked padlock icon 809f indicates that a peer-to-peer connection has been established between the browser and a cryptographic device associated with Author A. The “Upload signed file” button 830 provides the user of the browser with the functionality to provide a file signature for a file, whereby the file signature may be verified by the user's communication partner 120. This functionality includes applying a cryptographic key to the file, and uploading the file and its associated signature from the cryptographic device to the browser via the persistent peer-to-peer connection.


To enable this functionality, the following steps may be taken. The user 802, as Author A, selects a file to be uploaded and clicks on the “Upload signed file” button 830. The browser transmits a request message, which includes a file reference and a request for the creation of a file signature, to the cryptographic device 106 via the peer-to-peer connection 108. The cryptographic device 108 locates and retrieves the file from memory source 212, and applies the public key of communication partner 120 to the file contents to calculate a file signature. The cryptographic device transmits the file and its associated signature, as a cryptographic result, to the browser, in a response message, via the peer-to-peer connection.


The browser then provides the cryptographic result to the webpage. Depending upon the configuration of the webpage, the browser may then upload the file and its associated signature to a web server, and may provide an indication of the uploaded file upon the webpage. For example, text 834 indicates the previous upload of a file entitled ‘Academic transcript (Author A).pdf”. A file signature has been created by the cryptographic device for this file 834, as indicated by the tick icon 838.


The provision of file signatures with uploaded files enables a communication partner of the uploading user to be able to verify that the file originated from the uploading user, and has not been altered since uploading. The communication partner 120 applies the communication partner's private key to the file to determine whether the associated signature verifies the file.


Furthermore, file encryption functionality can be provided in much the same way as the generation of file signatures as described above. The user 102, as Author A, selects a file to be uploaded and clicks on the “Upload encrypted file” button 832. The browser transmits a request message, which includes a file reference and a request for an encryption of the file, to the cryptographic device 106 via the peer-to-peer connection 108. The cryptographic device 108 locates and retrieves the file from memory source 212, and applies the communication partner's public cryptographic key to the file contents to encrypt the file. The cryptographic device transmits the encrypted file to the browser, as a cryptographic result, in a response message, via the persistent peer-to-peer connection.


The browser provides the cryptographic result to the webpage. Depending upon the configuration of the webpage, the browser may then upload the encrypted file to a web server, and may provide an indication of the uploaded encrypted file upon the webpage. For example, text 836 indicates the previous upload of an encrypted file entitled ‘Curriculum Vitae (Author A).pdf”. This file has been encrypted by the cryptographic device, as indicated by the padlock icon 840.


The communication partner 120 may apply the communication partner's private key to the file to decrypt the file.


It will be appreciated by persons skilled in the art that numerous variations and/or modifications may be made to the above-described embodiments, without departing from the broad general scope of the present disclosure. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive.


Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.

Claims
  • 1. A method for obtaining cryptographic services for a browser executing a webpage on a user device, the method comprising: establishing a persistent peer-to-peer connection over a wireless Internet Protocol communication network between the browser and a cryptographic device, the cryptographic device comprising a private authentication key and a cryptographic key stored thereon;in response to receiving user input to the webpage, transmitting, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, for cryptographic processing of the data by the cryptographic device, wherein cryptographic processing comprises applying the cryptographic key to the data to produce a cryptographic result; andreceiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device, and providing the cryptographic result to a server hosting the webpage,wherein establishing the persistent peer-to-peer connection comprises:displaying, by the browser, signalling information including: challenge information and user device identification information;receiving, by the browser, response information from the cryptographic device, the response information including: a challenge response cryptographically determined by applying the private authentication key to the challenge information, andcryptographic device identification information; andin response to verifying the challenge response using a public authentication key associated with the private authentication key, establishing the persistent peer-to-peer connection,wherein the peer-to-peer connection comprises a communication channel between two internet connected applications,wherein the response information indicates the cryptographic device as one of the two internet connected applications, andwherein the signalling information is signalled via a communication channel other than the peer-to-peer connection, and the signalling the signalling information comprises displaying a Quick Response (QR) code which encodes the signalling information.
  • 2. The method of claim 1, further comprising: receiving, by the cryptographic device, from the browser, data via the persistent peer-to-peer connection between the browser and the cryptographic device;performing, by the cryptographic device, the cryptographic function on the data using the cryptographic key stored on the cryptographic device, to produce the cryptographic result; andtransmitting, by the cryptographic device, the cryptographic result to the browser, over the persistent peer-to-peer connection.
  • 3. The method of claim 1, wherein the persistent peer-to-peer connection remains established over multiple iterations of the steps of: transmitting, by the browser, the data over the persistent peer-to-peer connection to the cryptographic device; andreceiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device.
  • 4. The method of claim 1, further comprising sending confidential data stored on the cryptographic device, from the cryptographic device to the browser.
  • 5. The method of claim 1, wherein the cryptographic processing of the data by the cryptographic device comprises signing or encrypting the data with the cryptographic key to produce the cryptographic result.
  • 6. The method of claim 1, wherein the browser embeds the cryptographic result in the webpage.
  • 7. The method of claim 1, wherein the browser receives an updated webpage from the server hosting the webpage, in response to providing the cryptographic result to the server.
  • 8. The method of claim 1, wherein the method further comprises injecting, by the browser, software that defines the method into the webpage.
  • 9. The method of claim 1, wherein the cryptographic device signs the challenge information by applying the private authentication key to the challenge information to produce the challenge response.
  • 10. The method of any claim 1, wherein the data is indicative of data entered by a user of the browser into an input field of the webpage.
  • 11. The method of claim 1, wherein establishing a persistent peer-to-peer connection between the browser and the cryptographic device occurs in response to receiving establishment input from the user of the user device.
  • 12. A system comprising: at least one processor; anda non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the system to: execute, by a browser, a webpage;establish a persistent peer-to-peer connection over a wireless Internet Protocol communication network between the browser and a cryptographic device, the cryptographic device comprising a private authentication key and a cryptographic key stored thereon;in response to receiving user input to the webpage, transmit, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, for cryptographic processing of the data by the cryptographic device, wherein cryptographic processing comprises applying the cryptographic key to the data to produce a cryptographic result; andreceive, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device, and providing the cryptographic result to a server hosting the webpage,wherein to establish the persistent peer-to-peer connection the instructions when executed by the at least one processor further cause the system to: display, by the browser, signalling information including: challenge information; and user device identification information;receive, by the browser, response information from the cryptographic device, the response information including: a challenge response cryptographically determined by applying the private authentication key to the challenge information; andcryptographic device identification information; andin response to verification of the challenge response using a public authentication key associated with the private authentication key, establishing the persistent peer-to-peer connection,wherein the peer-to-peer connection comprises a communication channel between two internet connected applications,wherein the response information indicates the cryptographic device as one of the two internet connected applications, and wherein the instructions when executed by the at least one processor further cause the system to signal signalling information via a communication channel other than the peer-to-peer connection, and to display a Quick Response (QR) code which encodes the signalling information.
  • 13. The system of claim 12, further comprising the cryptographic device, the cryptographic device configured to: receive, from the browser, data via the persistent peer-to-peer connection between the browser and the cryptographic device;perform, the cryptographic function on the data using the cryptographic key stored on the cryptographic device, to produce the cryptographic result; andtransmit the cryptographic result to the browser, over the persistent peer-to-peer connection.
  • 14. The system of claim 13, wherein the instructions, when executed by the at least one processor, further cause the system to send confidential data stored on the cryptographic device, from the cryptographic device to the browser.
  • 15. The system of claim 12, wherein the instructions, when executed by the at least one processor, further cause the persistent peer-to-peer connection to remain established over multiple iterations of: transmission, by the browser, of the data over the persistent peer-to-peer connection to the cryptographic device; andreception, by the browser, of the cryptographic result over the persistent peer-to-peer connection from the cryptographic device.
  • 16. The system of claim 12, wherein the instructions, when executed by the at least one processor, further cause the data to be cryptographically processed by the cryptographic device by a signing or an encryption of the data with the cryptographic key to produce the cryptographic result.
  • 17. The system of claim 12, wherein the instructions, when executed by the at least one processor, cause the browser to embed the cryptographic result in the webpage.
  • 18. The system of claim 12, wherein the instructions, when executed by the at least one processor, cause the browser to receive an updated webpage from the server hosting the webpage, in response to providing the cryptographic result to the server.
  • 19. The system of claim 12, wherein the data is indicative of data entered by a user of the browser into an input field of the webpage.
  • 20. A non-transitory computer readable storage medium having stored thereon executable program instructions that, when executed by a computer, cause the computer to perform operations including: executing, by a browser, a webpage;establishing a persistent peer-to-peer connection over a wireless Internet Protocol communication network between the browser and a cryptographic device, the cryptographic device comprising a private authentication key and a cryptographic key stored thereon;in response to receiving user input to the webpage, transmitting, by the browser, data indicated by the user input over the persistent peer-to-peer connection to the cryptographic device, for cryptographic processing of the data by the cryptographic device, wherein cryptographic processing comprises applying the cryptographic key to the data to produce a cryptographic result; andreceiving, by the browser, the cryptographic result over the persistent peer-to-peer connection from the cryptographic device, and providing the cryptographic result to a server hosting the webpage,wherein establishing the persistent peer-to-peer connection comprises: displaying, by the browser, signalling information including: challenge information; and user device identification information;receiving, by the browser, response information from the cryptographic device, the response information including: a challenge response cryptographically determined by applying the private authentication key to the challenge information; andcryptographic device identification information; andin response to verifying the challenge response using a public authentication key associated with the private authentication key,establishing the persistent peer-to-peer connection,wherein the peer-to-peer connection comprises a communication channel between two internet connected applications,wherein the response information indicates the cryptographic device as one of the two internet connected applications, andwherein the signalling information is signalled via a communication channel other than the peer-to-peer connection, and the signalling the signalling information comprises displaying a Quick Response (QR) code which encodes the signalling information.
Priority Claims (1)
Number Date Country Kind
2019903591 Sep 2019 AU national
PCT Information
Filing Document Filing Date Country Kind
PCT/AU2020/051020 9/25/2020 WO
Publishing Document Publishing Date Country Kind
WO2021/056069 4/1/2021 WO A
US Referenced Citations (595)
Number Name Date Kind
5134700 Eyer Jul 1992 A
5481610 Doiron Jan 1996 A
5557346 Lipner Sep 1996 A
5557765 Lipner Sep 1996 A
5577121 Davis Nov 1996 A
5590196 Moreau Dec 1996 A
6052468 Hillhouse Apr 2000 A
6144739 Witt Nov 2000 A
6278783 Kocher Aug 2001 B1
6289455 Kocher Sep 2001 B1
6510518 Jaffe Jan 2003 B1
6711740 Moon Mar 2004 B1
7051199 Berson May 2006 B1
7082535 Norman et al. Jul 2006 B1
7353252 Yang Apr 2008 B1
7478172 Lee Jan 2009 B1
7707225 Akashika Apr 2010 B2
7783046 Sklyarov Aug 2010 B1
7797423 Holden Sep 2010 B2
7813822 Hoffberg Oct 2010 B1
7844670 Roskowski Nov 2010 B2
7853995 Chow Dec 2010 B2
7916864 Juffa Mar 2011 B2
7917628 Hesselink Mar 2011 B2
7917744 Radatti Mar 2011 B2
7987510 Kocher Jul 2011 B2
8086844 Buer Dec 2011 B2
8136025 Zhu Mar 2012 B1
8290161 Yung Oct 2012 B2
8302169 Presotto Oct 2012 B1
8315381 Qi Nov 2012 B2
8316237 Felsher Nov 2012 B1
8494168 Tolfmans Jul 2013 B1
8582760 Rosati Nov 2013 B2
8615787 Murray Dec 2013 B2
8693686 Radatti Apr 2014 B2
8695077 Gerhard et al. Apr 2014 B1
8752203 Reinertsen Jun 2014 B2
8856869 Brinskelle Oct 2014 B1
8924505 Molland Dec 2014 B2
9015857 Sprague et al. Apr 2015 B2
9177293 Gagnon Nov 2015 B1
9189627 Islam Nov 2015 B1
9208488 Liberty Dec 2015 B2
9235714 Cignetti Jan 2016 B1
9258120 Allen Feb 2016 B1
9288190 Brinskelle Mar 2016 B1
9292711 Roth Mar 2016 B1
9317708 Lee Apr 2016 B2
9332433 Dotan May 2016 B1
9363073 Teglia Jun 2016 B2
9397835 Campagna Jul 2016 B1
9406043 Amacker Aug 2016 B1
9444795 Kowalski Sep 2016 B1
9466054 Bradley Oct 2016 B1
9471466 Garcia Oct 2016 B1
9485098 Lepeshenkov Nov 2016 B1
9495145 Brech Nov 2016 B1
9565175 Saylor Feb 2017 B1
9569735 Zhu Feb 2017 B1
9584325 Brandwine Feb 2017 B1
9608813 Roth Mar 2017 B1
9609003 Chmielewski Mar 2017 B1
9614899 Rukonic Apr 2017 B1
9680908 Saylor Jun 2017 B1
9692757 Mikulski Jun 2017 B1
9729524 Brandwine Aug 2017 B1
9754130 Trent Sep 2017 B2
9756020 Kaufman Sep 2017 B2
9806887 Campagna Oct 2017 B1
9853811 Levy Dec 2017 B1
9866393 Rush Jan 2018 B1
9871652 Morikawa Jan 2018 B2
9882720 Levy Jan 2018 B1
9992029 Jackson Jun 2018 B1
10021113 Oberheide Jul 2018 B2
10078754 Brandwine Sep 2018 B1
10091144 Nodine Oct 2018 B1
10110382 Roth Oct 2018 B1
10123230 Govindassamy Nov 2018 B1
10129211 Heath Nov 2018 B2
10129321 Mayya Nov 2018 B2
10142301 Sharifi Mehr Nov 2018 B1
10165490 Govindassamy Dec 2018 B1
10185957 Quigley Jan 2019 B2
10193690 Self Jan 2019 B1
10218682 Kawach Feb 2019 B1
10230790 Wang Mar 2019 B2
10237246 Mulayin Mar 2019 B1
10277576 Yau Apr 2019 B1
10284530 Kuo et al. May 2019 B1
10291401 Norum May 2019 B1
10313117 Carlough Jun 2019 B1
10313123 Grubin et al. Jun 2019 B1
10348702 Sundaram Jul 2019 B1
10374809 Dasarakothapalli Aug 2019 B1
10411894 Yavnilovich Sep 2019 B1
10425225 Grubin Sep 2019 B1
10425497 de Waal Sep 2019 B1
10454897 Rajanna Oct 2019 B1
10462114 Poffenbarger Oct 2019 B2
10469262 Schroeder Nov 2019 B1
10476663 Lazier Nov 2019 B1
10491576 Pfannenschmidt Nov 2019 B1
10503918 Byszio Dec 2019 B2
10505736 Meixler Dec 2019 B1
10511448 Brinskelle Dec 2019 B1
10523434 Sharifi Mehr Dec 2019 B1
10558824 Remington Feb 2020 B1
10560539 Loch Feb 2020 B1
10608813 Lazier Mar 2020 B1
10630682 Bhattacharyya Apr 2020 B1
10740974 Cowburn Aug 2020 B1
10742626 Oberheide Aug 2020 B2
10749925 Hudgin Aug 2020 B1
10764294 Wasiq Sep 2020 B1
10771255 Roth Sep 2020 B1
10797871 McCormack Oct 2020 B1
10819709 M'Raihi Oct 2020 B1
10862689 Aizikovich Dec 2020 B1
10887107 Chan Jan 2021 B1
10911224 Marappan Feb 2021 B1
11017067 Smales May 2021 B2
11023595 Allen Jun 2021 B1
11029922 Chabrier Jun 2021 B2
11057210 Sierra Jul 2021 B1
11089081 Karppanen Aug 2021 B1
11153074 Nikitas Oct 2021 B1
11184157 Gueron Nov 2021 B1
11184406 Shashank Nov 2021 B1
11190569 Yu Nov 2021 B2
11218317 Miller Jan 2022 B1
11218435 Brody Jan 2022 B1
11218465 Glozman Jan 2022 B2
11233647 Fontaine Jan 2022 B1
11240023 Donlan Feb 2022 B1
11245521 Hathorn Feb 2022 B2
11343242 Manikantan May 2022 B2
11388226 Anderton Jul 2022 B1
11392714 Matthews Jul 2022 B1
11475140 Buonora Oct 2022 B1
11537421 Brooker Dec 2022 B1
11544677 Vagare Jan 2023 B2
11630877 Cansizoglu Apr 2023 B1
11677846 Howes Jun 2023 B1
11764948 Rambhia Sep 2023 B1
11765698 Kurian Sep 2023 B2
11770260 Pamucci Sep 2023 B1
11921905 Savagaonkar Mar 2024 B2
11960611 Pohl Apr 2024 B2
20020114470 Mauro, II Aug 2002 A1
20020116342 Hirano Aug 2002 A1
20020141582 Kocher Oct 2002 A1
20020147771 Traversat Oct 2002 A1
20020194483 Wenocur Dec 2002 A1
20030093663 Walker May 2003 A1
20030105812 Flowers, Jr. Jun 2003 A1
20030110296 Kirsch Jun 2003 A1
20030174843 Odell Sep 2003 A1
20030187918 Burbeck Oct 2003 A1
20030187973 Wesley Oct 2003 A1
20040008249 Nelson Jan 2004 A1
20040008635 Nelson Jan 2004 A1
20040066770 Pabla Apr 2004 A1
20040078775 Chow Apr 2004 A1
20040088646 Yeager May 2004 A1
20040101141 Alve May 2004 A1
20040249993 Hori Dec 2004 A1
20050088983 Wesslen Apr 2005 A1
20050125661 Vaidyanathan Jun 2005 A1
20050174986 Emond Aug 2005 A1
20060005048 Osaki Jan 2006 A1
20060037072 Rao Feb 2006 A1
20060129813 Narayanan Jun 2006 A1
20060149840 Thompson Jul 2006 A1
20060174352 Thibadeau Aug 2006 A1
20060198515 Forehand Sep 2006 A1
20060200550 Nelson Sep 2006 A1
20060212592 Gupta Sep 2006 A1
20060242415 Gaylor Oct 2006 A1
20060280191 Nishida et al. Dec 2006 A1
20060291657 Benson Dec 2006 A1
20060294213 Saridakis Dec 2006 A1
20070033419 Kocher Feb 2007 A1
20070098153 Nishikawa May 2007 A1
20070124406 Liu May 2007 A1
20070143397 Guedalia Jun 2007 A1
20070278285 Ehrensvaerd Dec 2007 A1
20080063183 Greco Mar 2008 A1
20080104399 Fascenda May 2008 A1
20080114995 Jogand-Coulomb May 2008 A1
20080141336 Haller Jun 2008 A1
20080181399 Weise Jul 2008 A1
20080209075 Shamma Aug 2008 A1
20090010424 Qi Jan 2009 A1
20090037338 Braun Feb 2009 A1
20090041245 Torisaki Feb 2009 A1
20090066788 Baum Mar 2009 A1
20090066789 Baum Mar 2009 A1
20090070473 Baum Mar 2009 A1
20090070477 Baum Mar 2009 A1
20090074184 Baum Mar 2009 A1
20090097651 Whillock Apr 2009 A1
20090129586 Miyazaki May 2009 A1
20090138700 Miyazaki May 2009 A1
20090214030 Price, III Aug 2009 A1
20090276547 Rosenblatt Nov 2009 A1
20090287837 Felsher Nov 2009 A1
20090288159 Husemann Nov 2009 A1
20090319804 Qi Dec 2009 A1
20100005297 Ganesan Jan 2010 A1
20100030734 Chunilal Feb 2010 A1
20100077212 McReynolds Mar 2010 A1
20100105322 Bertin Apr 2010 A1
20100138666 Adams Jun 2010 A1
20100153989 Jing Jun 2010 A1
20100161995 Browning Jun 2010 A1
20100189262 Ducharme Jul 2010 A1
20100232601 Itoh Sep 2010 A1
20100235285 Hoffberg Sep 2010 A1
20100235523 Garcia Sep 2010 A1
20100275025 Parkinson Oct 2010 A1
20100317420 Hoffberg Dec 2010 A1
20100332845 Asaka Dec 2010 A1
20110026474 Freda Feb 2011 A1
20110099278 Marr Apr 2011 A1
20110113034 Sidman May 2011 A1
20110145592 Greiner Jun 2011 A1
20110154025 Spalka Jun 2011 A1
20110185082 Thompson Jul 2011 A1
20110252238 Abuan Oct 2011 A1
20110276700 Chaturvedi Nov 2011 A1
20110296198 Motoyama Dec 2011 A1
20110296238 Abzarian Dec 2011 A1
20120028615 Sundaramurthy Feb 2012 A1
20120084349 Lee Apr 2012 A1
20120087494 Spalka Apr 2012 A1
20120093313 Michiels Apr 2012 A1
20120129493 Vasudevan May 2012 A1
20120173387 Talker Jul 2012 A1
20120209686 Horowitz Aug 2012 A1
20120246301 Vyrros Sep 2012 A1
20120263299 Akhavan-Toyserkani Oct 2012 A1
20120284506 Kravitz Nov 2012 A1
20120316940 Moshfeghi Dec 2012 A1
20130013928 Thom Jan 2013 A1
20130054474 Yeager Feb 2013 A1
20130061054 Niccolai Mar 2013 A1
20130080768 Lagerway Mar 2013 A1
20130111211 Winslow May 2013 A1
20130124860 Maidl May 2013 A1
20130145160 Bursell Jun 2013 A1
20130159021 Felsher Jun 2013 A1
20130238907 Debout Sep 2013 A1
20130254087 Rooz Sep 2013 A1
20130262851 Hirvonen Oct 2013 A1
20140006660 Frei Jan 2014 A1
20140012895 Lieberman Jan 2014 A1
20140012906 Teja Jan 2014 A1
20140013123 Khazan Jan 2014 A1
20140013434 Ranum Jan 2014 A1
20140025944 Maletsky Jan 2014 A1
20140032785 Chaudhuri Jan 2014 A1
20140032902 Agrawal Jan 2014 A1
20140058792 Talker Feb 2014 A1
20140122585 DeLong May 2014 A1
20140123220 Sprunk et al. May 2014 A1
20140149512 Leitch May 2014 A1
20140164250 Sahasranaman et al. Jun 2014 A1
20140195804 Hursti Jul 2014 A1
20140222894 Gangadharan Aug 2014 A1
20140237239 Hursti Aug 2014 A1
20140237252 Hursti Aug 2014 A1
20140259147 L'Heureux Sep 2014 A1
20140282071 Trachtenberg Sep 2014 A1
20140282974 Maher Sep 2014 A1
20140289535 Gan Sep 2014 A1
20140324967 Atias Oct 2014 A1
20140334464 Qi Nov 2014 A1
20140344569 Li Nov 2014 A1
20140351478 Lee Nov 2014 A1
20140351832 Cho Nov 2014 A1
20140366155 Chang Dec 2014 A1
20140380037 Matsuda Dec 2014 A1
20150006672 Morel Jan 2015 A1
20150010146 Matsuda Jan 2015 A1
20150022666 Kay Jan 2015 A1
20150039904 Matsuda Feb 2015 A1
20150054947 Dawes Feb 2015 A1
20150074408 Oberheide Mar 2015 A1
20150081846 Ur-Rahman Mar 2015 A1
20150089233 Roth Mar 2015 A1
20150096001 Morikuni Apr 2015 A1
20150103730 Emmanuel Apr 2015 A1
20150105121 Emmanuel Apr 2015 A1
20150121454 Cox Apr 2015 A1
20150186658 Marien Jul 2015 A1
20150188702 Men Jul 2015 A1
20150189024 Misra Jul 2015 A1
20150195263 Wilson Jul 2015 A1
20150213138 Lee Jul 2015 A1
20150280986 Abuan Oct 2015 A1
20150287026 Yang Oct 2015 A1
20150288682 Bisroev Oct 2015 A1
20150310230 Shirai Oct 2015 A1
20150331727 Mameri Nov 2015 A1
20150350333 Cutler Dec 2015 A1
20150358400 Bartlett, II Dec 2015 A1
20160021167 Park Jan 2016 A1
20160044621 Ding Feb 2016 A1
20160050703 Johnsson Feb 2016 A1
20160057114 Unagami Feb 2016 A1
20160065542 Driscoll Mar 2016 A1
20160080326 Brand Mar 2016 A1
20160080503 Guo Mar 2016 A1
20160099919 Daniels Apr 2016 A1
20160117262 Thom Apr 2016 A1
20160119400 Elliott Apr 2016 A1
20160134599 Ross May 2016 A1
20160134603 Cregg May 2016 A1
20160154744 Zheng Jun 2016 A1
20160156719 Mobarak Jun 2016 A1
20160165376 Qi Jun 2016 A1
20160171221 Arnold Jun 2016 A1
20160173537 Kumar Jun 2016 A1
20160182500 Ligatti Jun 2016 A1
20160205074 Mitchell Jul 2016 A1
20160218873 Spiro Jul 2016 A1
20160234259 Talmaki Aug 2016 A1
20160241660 Nhu Aug 2016 A1
20160255070 Näslund Sep 2016 A1
20160269174 Yasuda Sep 2016 A1
20160277202 Davis Sep 2016 A1
20160285625 Roth Sep 2016 A1
20160285802 Brandenburg Sep 2016 A1
20160285948 Saint-Hilaire et al. Sep 2016 A1
20160294783 Piqueras Jover Oct 2016 A1
20160300306 Simburg Oct 2016 A1
20160308721 Dellisanti Oct 2016 A1
20160308932 Gibbons Oct 2016 A1
20160314513 Velusamy Oct 2016 A1
20160315765 Zheng Oct 2016 A1
20160344549 Campagna Nov 2016 A1
20160366250 Lee Dec 2016 A1
20170019939 Shin Jan 2017 A1
20170026339 Degenkolb Jan 2017 A1
20170032366 Kumar Feb 2017 A1
20170038916 Beach Feb 2017 A1
20170046651 Lin Feb 2017 A1
20170070361 Sundermeyer Mar 2017 A1
20170070563 Sundermeyer Mar 2017 A1
20170098011 Islam Apr 2017 A1
20170111788 Cotta Apr 2017 A1
20170126681 Barrett May 2017 A1
20170140456 Kong May 2017 A1
20170149562 Takada May 2017 A1
20170155694 Pinkovezky Jun 2017 A1
20170192983 Weng Jul 2017 A1
20170195386 Nathan Jul 2017 A1
20170208463 Brand Jul 2017 A1
20170213212 Dicker Jul 2017 A1
20170220011 Hart Aug 2017 A1
20170220012 Hart Aug 2017 A1
20170221011 Von Sichart Aug 2017 A1
20170221055 Carlsson Aug 2017 A1
20170223026 Amiri Aug 2017 A1
20170223057 Amiri Aug 2017 A1
20170223093 Peterson Aug 2017 A1
20170223138 Amiri Aug 2017 A1
20170230365 Poete Aug 2017 A1
20170235956 Maletsky Aug 2017 A1
20170242555 Wragg Aug 2017 A1
20170243271 You Aug 2017 A1
20170244695 Lund Aug 2017 A1
20170244778 Zhu Aug 2017 A1
20170256007 Barman Sep 2017 A1
20170262643 Aldis Sep 2017 A1
20170289233 Margatan Oct 2017 A1
20170293575 Best Oct 2017 A1
20170295226 Basta Oct 2017 A1
20170301063 Merhav Oct 2017 A1
20170302736 Hudda Oct 2017 A1
20170310500 Dawes Oct 2017 A1
20170317997 Smith Nov 2017 A1
20170318074 Margatan Nov 2017 A1
20170322933 Rosenblatt Nov 2017 A1
20170323022 Miranda Nov 2017 A1
20170329569 Wilczynski Nov 2017 A1
20170331870 Giger Nov 2017 A1
20170337247 Tague Nov 2017 A1
20170338951 Fu Nov 2017 A1
20170339164 Oberheide Nov 2017 A1
20170339221 Wang Nov 2017 A1
20170339566 Yasuda Nov 2017 A1
20170346621 Schepers Nov 2017 A1
20170353324 Baum Dec 2017 A1
20170364596 Wu Dec 2017 A1
20170366356 Ramos Dec 2017 A1
20170366568 Narasimhan Dec 2017 A1
20170372289 Fitzsimmons Dec 2017 A1
20180004377 Kitchen Jan 2018 A1
20180018400 Cozzi Jan 2018 A1
20180019871 Gage Jan 2018 A1
20180026925 Kennedy Jan 2018 A1
20180032627 Margatan Feb 2018 A1
20180034804 Steiner Feb 2018 A1
20180041505 Chabanne Feb 2018 A1
20180060589 Polak Mar 2018 A1
20180062828 Cioranesco Mar 2018 A1
20180063158 Dalton Mar 2018 A1
20180069710 De Langen Mar 2018 A1
20180069851 Terao Mar 2018 A1
20180077248 Srour Mar 2018 A1
20180081824 Bacher Mar 2018 A1
20180082351 Wang Mar 2018 A1
20180091296 Johnson Mar 2018 A1
20180101847 Pisut, IV Apr 2018 A1
20180102906 Lindberg Apr 2018 A1
20180107684 Kiapour Apr 2018 A1
20180121369 Poeppelmann May 2018 A1
20180124159 Sun May 2018 A1
20180129826 Kim May 2018 A1
20180137480 Houghton, IV May 2018 A1
20180145840 Advani May 2018 A1
20180145953 Swahn May 2018 A1
20180150568 Hochreuter May 2018 A1
20180152305 Jacquin May 2018 A1
20180164986 Al Majid Jun 2018 A1
20180182048 Stöcker Jun 2018 A1
20180183765 Neumann Jun 2018 A1
20180191720 Dawes Jul 2018 A1
20180198621 Senyuk et al. Jul 2018 A1
20180198788 Helen Jul 2018 A1
20180199386 Yuan Jul 2018 A1
20180206279 Lee Jul 2018 A1
20180219674 Mullins Aug 2018 A1
20180227128 Church Aug 2018 A1
20180234494 Klemets Aug 2018 A1
20180242147 Fransen Aug 2018 A1
20180247657 Marathe Aug 2018 A1
20180248807 Murphy Aug 2018 A1
20180254901 Egorov Sep 2018 A1
20180254970 Gullen Sep 2018 A1
20180255068 Figueroa Sep 2018 A1
20180278588 Cela Sep 2018 A1
20180287785 Pfannenschmidt Oct 2018 A1
20180287801 Donlan Oct 2018 A1
20180302468 Hu Oct 2018 A1
20180315350 Rietman Nov 2018 A1
20180316634 Driscoll Nov 2018 A1
20180323970 Maron Nov 2018 A1
20180330368 Slupesky Nov 2018 A1
20180332122 Shahid Nov 2018 A1
20180338008 Trinite Nov 2018 A1
20180350180 Onischuk Dec 2018 A1
20180367311 Stahlberg Dec 2018 A1
20190020469 Dottax Jan 2019 A1
20190034907 Powers Jan 2019 A1
20190050589 Rane Feb 2019 A1
20190068382 Theodore Feb 2019 A1
20190090252 Park Mar 2019 A1
20190104121 Khandani Apr 2019 A1
20190109714 Clark Apr 2019 A1
20190122443 Stöcker Apr 2019 A1
20190124134 Chmielewski Apr 2019 A1
20190141535 Morgan May 2019 A1
20190147170 Keselman May 2019 A1
20190149332 Rivain May 2019 A1
20190156055 Rosenberg May 2019 A1
20190156212 Bottaro May 2019 A1
20190158293 Chen May 2019 A1
20190158304 Sundermeyer May 2019 A1
20190182335 Chen Jun 2019 A1
20190213356 Vágujhelyi Jul 2019 A1
20190229912 Lee Jul 2019 A1
20190230092 Patel Jul 2019 A1
20190237170 Okajima Aug 2019 A1
20190245686 Rahimi Aug 2019 A1
20190250805 Brewer Aug 2019 A1
20190250944 Pounds Aug 2019 A1
20190260584 Chan Aug 2019 A1
20190268156 Delmas Aug 2019 A1
20190268165 Monica Aug 2019 A1
20190289042 Perreault Sep 2019 A1
20190312750 Bertram Oct 2019 A1
20190318356 Martin Oct 2019 A1
20190319904 Al Majid Oct 2019 A1
20190320038 Walsh Oct 2019 A1
20190334884 Ross Oct 2019 A1
20190340001 Vysotsky Nov 2019 A1
20190342425 Cheng Nov 2019 A1
20190347916 Wild Nov 2019 A1
20190356491 Herder, III Nov 2019 A1
20190361642 Shibata Nov 2019 A1
20190372760 Zheng Dec 2019 A1
20190372961 Circosta Dec 2019 A1
20190379675 Johns Dec 2019 A1
20190379744 Johns Dec 2019 A1
20200004679 Szubbocsev Jan 2020 A1
20200005257 Liberty Jan 2020 A1
20200007332 Girkar Jan 2020 A1
20200012801 Porteret Jan 2020 A1
20200015081 Porteret Jan 2020 A1
20200021481 Tsigkogiannis Jan 2020 A1
20200042746 Avanzi Feb 2020 A1
20200044833 Shpurov Feb 2020 A1
20200053079 Bendersky Feb 2020 A1
20200053163 Ngo Feb 2020 A1
20200074121 Fu Mar 2020 A1
20200074122 Fu Mar 2020 A1
20200076624 Cambou Mar 2020 A1
20200082462 Nguyen Mar 2020 A1
20200084050 Mensch Mar 2020 A1
20200117814 Ito Apr 2020 A1
20200118234 Venkataraman Apr 2020 A1
20200119911 Shemer Apr 2020 A1
20200125563 Fan Apr 2020 A1
20200127813 Millar Apr 2020 A1
20200137354 Nathan Apr 2020 A1
20200139141 Crawford May 2020 A1
20200195525 Fitzer Jun 2020 A1
20200196299 Liu Jun 2020 A1
20200201760 Desai Jun 2020 A1
20200202036 Baruch Jun 2020 A1
20200204357 Seyfried Jun 2020 A1
20200218586 Aghadavoodi Jolfaei Jul 2020 A1
20200228520 Thampi Jul 2020 A1
20200250323 Remington Aug 2020 A1
20200252288 Al-Yousef Aug 2020 A1
20200259642 McCallum Aug 2020 A1
20200259644 McCallum Aug 2020 A1
20200259645 McCallum Aug 2020 A1
20200301752 Mara Sep 2020 A1
20200313895 Ha Oct 2020 A1
20200322306 Serena Oct 2020 A1
20200366674 Gazdzinski Nov 2020 A1
20200374113 Noam Nov 2020 A1
20200389302 Canard Dec 2020 A1
20200389304 Gryb Dec 2020 A1
20200401627 Liu Dec 2020 A1
20200401718 Hennig Dec 2020 A1
20200403784 Rodriguez Dec 2020 A1
20210005302 McFarlane Jan 2021 A1
20210014058 Finchelstein Jan 2021 A1
20210014302 Robison Jan 2021 A1
20210036851 Villapakkam Feb 2021 A1
20210036856 Wang Feb 2021 A1
20210045169 Pupakdee Feb 2021 A1
20210050996 Fries Feb 2021 A1
20210051377 Deshpande Feb 2021 A1
20210058245 Bursell Feb 2021 A1
20210058379 Bursell Feb 2021 A1
20210058493 Huang Feb 2021 A1
20210084027 Johnston Mar 2021 A1
20210090011 Rae Mar 2021 A1
20210092113 Manikantan Mar 2021 A1
20210126879 Liu Apr 2021 A1
20210160340 Narayanan May 2021 A1
20210176049 Kwak Jun 2021 A1
20210226781 Arkko Jul 2021 A1
20210234681 Buendgen Jul 2021 A1
20210310222 Melul Oct 2021 A1
20210320790 Nishimura Oct 2021 A1
20210320792 Cech Oct 2021 A1
20210351919 Liu Nov 2021 A1
20210407322 Ilani Dec 2021 A1
20210407323 Ilani Dec 2021 A1
20220004613 Dange Jan 2022 A1
20220004619 Dange Jan 2022 A1
20220021633 Stafford Jan 2022 A1
20220038264 Yakira Feb 2022 A1
20220038870 Stafford Feb 2022 A1
20220038995 Athlur Feb 2022 A1
20220138349 Saarinen May 2022 A1
20220247579 Bester Aug 2022 A1
20220318080 Henry Oct 2022 A1
20220360445 Kwak Nov 2022 A1
20220376933 Guabtni Nov 2022 A1
20230012013 Livshin Jan 2023 A1
20230068521 Wang Mar 2023 A1
20230133418 Dietrich May 2023 A1
20230171309 Bhatt Jun 2023 A1
20230188341 Ying Jun 2023 A1
20230188485 Stafford Jun 2023 A1
20230196347 Tate Jun 2023 A1
20230254292 Chen Aug 2023 A1
20230269080 Wirth Aug 2023 A1
20230282083 Cornell Sep 2023 A1
20230290177 Jacobs Sep 2023 A1
20240022418 Hawkins Jan 2024 A1
20240097900 Teglia Mar 2024 A1
20240154949 Frosztega May 2024 A1
20240223354 Azouaoui Jul 2024 A1
20250004952 Ahirwar Jan 2025 A1
20250068779 Ramani Feb 2025 A1
Foreign Referenced Citations (7)
Number Date Country
108768938 Nov 2018 CN
2456158 May 2012 EP
2690838 Jan 2014 EP
WO 0122651 Mar 2001 WO
WO-2007038283 Apr 2007 WO
WO 2016112338 Jul 2016 WO
WO 2019129941 Jul 2019 WO
Non-Patent Literature Citations (11)
Entry
Ingle et al “A Review on Secure Communication Protocol for Wireless Ad Hoc Network,” 2015 International Conference on Pervasive Computing (ICPC), IEEE, pp. 1-4 (Year: 2015).
Panton et al “Secure Proximity-Based Identity Pairing using an Untrusted Signalling Service,” 2016 IEEE 13th IEEE Annual Consumer Communications & Networking Conference (CCNC), pp. 1-6 (Year: 2016).
Google Patents Translation of CN 108768938 (Year: 2018).
Panton et al “Secure Proximity-Based Identity Pairing using an Untrusted Signalling Service,” 2016 13th IEEE Annual Consumer Communications & Networking Conference, IEEE, pp. 1-6 (Year: 2016).
Liu et al “Techniques of Secure Web Service and Its Implementation,” Proceedings of the Fourth International Conference on Machine Learning and Cybermetics, IEEE, pp. 161-164 (Year: 2005).
Ramya et al “Review on Quick Response Codes in the Field of Information Security,” pp. 1-5 (Year: 2014).
Khedekar “Security: An Effective Technique to Protecting Sensitive Information using Quick Response Code,” IEEE, pp. 1185-1188 (Year: 2016).
Australian Patent Office International-Type Search Report for National Application No. 2019903591, dated Dec. 9, 2019, 20 pgs.
International Search Report for corresponding International Patent Application No. PCT/AU2020/051020, dated Oct. 13, 2020, 8 pgs.
Written Opinion of the International Searching Authority for corresponding International Patent Application No. PCT/AU2020/051020, 4 pgs.
Extended European Search Report for corresponding European patent application No. 20868522.2, dated Aug. 31, 2023, 11 pgs.
Related Publications (1)
Number Date Country
20220376933 A1 Nov 2022 US