Patent ID: 12248553

DETAILED DESCRIPTION

Disclosed are various approaches for signing electronic documents on clients such as devices. Users can open and review documents on their devices. If desired, a user can also sign the documents using trusted digital certificates. The trusted digital certificates can be derived from user credentials, such as a cryptographic token generated by a smart card or similar hardware security device. The trusted digital certificates can then be provided to clients associated with the user when a user attempts to sign a document. Revocation or expiration of the trusted digital certificates can be used to enforce signing privileges, such as when an employee leaves an organization. In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

To begin,FIG.1Adepicts a client device100with a display103that can render a user interface. As depicted, a user is able to view a document on the display103of a client device100. With the user interface, a user can interact with a user interface element106to electronically sign the document. The electronic signature can include an electronic acknowledgement of assent to or approval of the content of the document and can involve cryptographic operations to provide for authentication and non-repudiation of the electronic signature and verification of the document signed.

FIG.1Bprovides an example illustration of the user experience of electronically signing a document on a mobile device. After interacting with the user interface element106, a prompt109can be rendered within the user interface. The prompt109can be used to allow for a user to authenticate himself or herself with the client device100in order to verify that the user attempting to electronically sign the document is the authorized signatory. In some implementations, the prompt109may be configured to allow the user to input a password, personal identification number (PIN), or similar authorization code. However, the prompt109may also be configured to allow the input to provide a biometric identifier (e.g., a prompt109instructing the user to use a fingerprint reader or look at a camera for facial recognition), cryptographic value generated from a hardware security token (e.g., a universal second factor (U2F) authentication token, a smart card, etc.), select a key-file, or input some other credential.

An example of a result is depicted inFIG.1C, where an electronic signature113that has been appended to or inserted into the document is rendered on the display103. The electronic signature113can include a graphical or similar digital representation of the user's signature. The electronic signature113can also include information such as the date the document was signed, an identifier of a certificate that was used to sign the document, and potentially other information.

With reference toFIG.2, shown is a network environment200according to various embodiments. The network environment200includes a computing environment203and a client device100, which are in data communication with each other via a network206. The network206can include wide area networks (WANs) and local area networks (LANs). These networks can include wired or wireless components or a combination thereof. Wired networks can include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks can include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) 802.11 wireless networks (i.e., WI-FI®), BLUETOOTH® networks, microwave transmission networks, as well as other networks relying on radio broadcasts. The network206can also include a combination of two or more networks206. Examples of networks206can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

The computing environment203can include a server computer or any other system providing computing capability. Alternatively, the computing environment203can employ a plurality of computing devices that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the computing environment203can include a plurality of computing devices that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the computing environment203can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time.

Various applications or other functionality can be executed in the computing environment203according to various embodiments. The components executed on the computing environment203can include a certificate authority216, a management service219, a derived credentials service221, as well as other applications, services, processes, systems, engines, or functionality.

Also, various data is stored in a data store223that is accessible to the computing environment203. The data store223can be representative of a plurality of data stores223, which can include relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. The data stored in the data store223is associated with the operation of the various applications or functional entities described below. This data can include user accounts225, compliance policies227, and potentially other data.

A user account225represents a user of a client device100that is registered or enrolled with the management service219. This can include a user who is viewing and electronically signing documents in various implementations of the present disclosure. The user account225can include account credentials229, a certificate233, and potentially other data.

The account credentials229represent the authentication factors used to verify the identity of a user. Examples of account credentials229include passwords or passcodes, one-time codes generated by an application, cryptographic keys or certificates, or authentication tokens generated by hardware security devices previously identified as being associated with a user.

The certificate233is an electronic document which identifies the owner of a respective cryptographic key, such as a public encryption key-pair or a symmetric encryption key. The cryptographic key associated with the certificate may be used to encrypt or decrypt data, as well as perform cryptographic or digital signature operations. The certificate233may include information about the key (e.g., a fingerprint of the key and the type of encryption key), the user account225for which the key is assigned, and a digital signature by an entity that has verified the contents of the certificate233.

In some implementations, a certificate233can also include authentication credentials236which a user can provide to verify that the user is allowed to utilize the certificate233. For instance, the authentication credentials236could include a password or passphrase required to decrypt the certificate233, such as a password or passphrase used to access certificates233stored in a Public-Key Cryptography Standards version 12 (PKCS #12) formatted file. As another example, the authentication credentials236could include a password, passphrase, authentication code or token, encryption key, or similar data that the certificate authority216may request prior to providing a certificate233in response.

A compliance policy227represents a definition of a required state or configuration of the client device100. The compliance policy227may also specify one or more remedial actions to be performed if the client device100is not in the required state or match the required configuration specified by the compliance policy227. For example, a compliance policy227may specify that particular applications cannot be executed at specified times of day or in specified locations defined by a geofence. As another example, a compliance policy227may specify that the client device100cannot access specified types of data (e.g., particular documents or types of documents) at specified locations defined by a geofence. Similarly, a compliance policy227may specify that a certificate233cannot be installed on the client device100if the client device100is located within a specified geofence. Accordingly, such a compliance policy227may specify a remedial action that the certificate233be deleted from the client device100when it enters the specified geofence. Various other compliance policies227may be specified by administrators as appropriate for individual users, client devices100, or enterprises.

The certificate authority216is executed to issue and validate cryptographic certificates233. For example, the certificate authority216can issue certificates233to services or devices in response to a request for a certificate233. The certificate authority216can also validate the authenticity of certificates233that have been issued by the certificate authority216(e.g., to evaluate whether the certificate233is a forgery, the certificate233has been revoked, etc.). For example, the certificate authority216can issue a certificate233for a user account225in response to request from the derived credentials service221.

The management service219is executed to monitor and control the operation of enrolled client devices100through the use of compliance policies227. For example, the management service219may send one or more commands to a client device100to bring the client device100into a compliant state with respect to a compliance policy227. Similarly, the management service219could provide copies of applicable compliance policies227to the client device100for enforcement by a locally executing agent.

The derived credentials service221is executed to generate or request the creation of derived credentials on behalf of the user account225. In order to protect the account credentials229from third-party services, a user may wish for a substitute credential derived from the account credentials229to be used. Similarly, where one type of account credential229may be impractical to use, a user may wish for a substitute credential derived from the account credentials229to be used in its place. For example, a one-way hash of a password may be used in place of the password itself to obfuscate the password. As another example, smart cards may be unavailable for authentication by users when using a mobile device (e.g., a smartphone). Accordingly, a user may wish for a certificate233to be issued and stored on the client device100for use as a substitute to the smart card for authentication purposes.

The client device100is representative of a plurality of client devices that can be coupled to the network206. The client device100can include any computer system, such as a personal computer (e.g., a desktop computer, a laptop computer, or similar device) or a mobile computing device (e.g., personal digital assistants, cellular telephones, smartphones, web pads, tablet computer systems, music players, portable game consoles, electronic book readers, and similar devices). The client device100can include one or more displays103, such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink (“E-ink”) displays, projectors, or other types of display devices. In some instances, the display103can be a component of the client device100or can be connected to the client device100through a wired or wireless connection.

The client device100can be configured to execute various applications such as a client application239, a multifactor authentication application241, a management agent242, a credential application243, or other applications. The client device100can also include a client data store246, which can be representative of a plurality of client data stores246, including relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. The data stored in the client data store246is associated with the operation of the various applications or functional entities described below. This data can include files249, certificates233, and potentially other data. In some embodiments, multiple client data stores246may be used by the client device100to provide for secure separation of data. For instance, a first client data store246may be used to securely store certificates233(e.g., a password or credential management system), while other client data stores246may be used to store other types of data, such as files249.

The client application239can be executed in a client device239to access network content served up by the computing environment203or other servers, thereby rendering a user interface on the display103. Examples of a client application239include a web browser, an email application, a messaging or chat application, a document viewer, a file browser, social networking application, word processors, spreadsheets, etc. The user interface can include a network page, an application screen, or other user mechanism for obtaining user input.

The multifactor authentication application241can be executed to allow a user to input additional authentication factors when logging onto the client device100or a service accessible across the network206(e.g., a single sign-on (SSO) portal, a login screen or page for an application, etc.). For example, the multifactor authentication application241may be configured to allow a user to submit an authentication token generated by a smart card or similar device in data communication with the client device100when his or her account credentials229are requested. As another example, the multifactor authentication application241may be configured to generate numeric or alphanumeric codes at periodic intervals or in a pseudorandom sequence derived from an initial seed value. These codes could then be inputted or submitted as an account credential229for authenticating a user.

The management agent242can be executed to register or enroll the client device100with the management service219and to implement or enforce applicable compliance policies227. For example, the management agent242may be configured to regularly contact the management service219to provide status updates on the operation, state, or configuration of the client device100and retrieve commands from the management service219to implement in order to bring the client device100into compliance with an applicable compliance policy227. As another example, the management agent242may be configured to retrieve compliance policies227from the management service219and implement or enforce the compliance policies227on the client device100.

The credential application243can be executed, in some implementations, to provide electronic and cryptographic signing functions for client applications239installed on the client device100. In some implementations, the functionality of the credential application243may be implemented as a library that can be incorporated into a client application239(e.g., as part of a software development kit (SDK)). In other implementations the credential application243may be implemented as an independent service or application.

Next, a general description of the operation of the various components of the network environment200is provided. Although the following general description illustrates how the various components of the network environment200can interoperate with each other, more detailed descriptions of the operation and interaction between the various components is provided in the discussion ofFIGS.3-6.

To begin, the derived credentials service221can cause one or more derived credentials, such as certificates233, to be created on behalf of a user. For example, when a user logs onto his or her computer (e.g., a laptop, desktop, etc.), the user may be prompted to provide multiple account credentials229. The first account credential229could be a password associated with the user account225, while a second authentication credential229could be a cryptographic token generated by a hardware security device (e.g., a smart card, U2F security token, biometric reader, etc.) in data communication with the user's laptop or desktop. As many hardware security devices cannot be used with mobile devices, the derived credentials service221can cause a certificate233to be generated for use on mobile devices in place of a hardware security device associated with the user.

To generate the certificate233, the derived credentials service221can create a public-key pair based off of the cryptographic token generated by the hardware security device. For example, the derived credentials service221could use the cryptographic token as an initial seed value for a pseudorandom number generator serving as an entropy source for the creation or selection of the public-key pair. However, in some instances, the derived credentials service221can alternately generate the public-key pair in response to receipt of the account credentials229authenticating the user. In these instances, the public-key pair would be subsequently stored in a certificate233linked with the user account225.

Once the derived credentials service221generates the public-key pair, the derived credentials service221sends a request to the certificate authority216to generate or issue a certificate for the user account225. The request can include the public-key pair created by the derived credentials service and identifying information from the user account225. The certificate authority216can then generate and issue the certificate233, and provide it to the derived credentials service221in response. In some implementations, the certificate authority236may secure the certificate233by linking authentication credentials236to the certificate233. For example, the certificate authority233could encrypt the certificate233with authentication credentials236(e.g., a password or PIN). In order to use the certificate233, a user would have to decrypt the certificate233using the appropriate authentication credentials236. As another example, the certificate authority233could link authentication credentials236to the certificate233, which would require the user to supply the appropriate authentication credentials236to access the certificate233.

The certificate233can then be provided to the client device100for use in electronically signing files249, such as documents. For example, when a client application239attempts to electronically sign a file249, the credential application243may authenticate the user of the client device100and retrieve the certificate233. The credential application243may then use the certificate to electronically sign the file249, as discussed in detail later.

Referring next toFIG.3, shown is a sequence diagram that provides one example of the interaction between the various components of the network environment200. The sequence diagram ofFIG.3provides merely an example of a possible implementation of the present disclosure, whereby the functionality of the credential application243is included as part of a client application239. This can occur, for example, when the credential application243is provided as a library of an SDK which is utilized by the client application(s)239installed on the client device100. As an alternative, the flowchart ofFIG.3can be viewed as depicting an example of elements of a method implemented in the network environment200according to one or more embodiments.

Beginning at step303, a first client application239asends a request to the certificate authority216for a signing certificate233. The request can include an identifier of the user account associated with the client device100in order to allow the certificate authority216to provide the appropriate certificate233in response. The request may be sent when the first client application239ais first installed on the client device100. As another example, the request may also be sent in response to a determination by the first client application239athat the certificate233is absent from the memory of the client device100. This could occur, for example, when the certificate233has not been previously used for electronically signing documents or files249or when a previously used certificate233has expired or been revoked and a new certificate233is required.

In some implementations, the request can include authentication credentials236to allow the first client application239ato verify with the certificate authority216that the first client application239ais authorized to receive the certificate233. For example, the first client application239acould cause a prompt109to be rendered on the display103of the client device100. The user could input his or her authentication credentials236into the prompt.

Then at step306, the certificate authority216provides the certificate233in response. In some implementations, the certificate authority216may first verify that the authentication credentials236included in the request for the certificate233match the authentication credentials236recorded in association with the certificate233. If the certificate233has not yet been created, the certificate authority216may create the certificate233prior to providing the certificate233to the first client application239a.

Moving on to step309, the first client application239acan optionally store the retrieved certificate233in the client data store246. For example, if the certificate233has not been previously used or requested by the client device100, then the first client application239acan store the retrieved certificate233in the client data store246for use by other client applications239.

Next at step313, the first client application239acan open a file249stored in the client data store246. This can occur, for example, when a user wishes to view or edit a file249using the first client application239a.Examples can include a user attempting to view a portable document format (PDF) file249attached to an email, a user opening a file249stored in a network accessible file repository or content locker, a user opening a locally stored file249, or similar file operations.

Then at step316, the first client application239acan retrieve the certificate233from the client data store246. This may be done, for example, in response to a manipulation of a user interface element106rendered on the display103of the client device100designed to allow a user to electronically sign the file249.

Moving on to step319, the first client application239acan then electronically sign the file249. For example, the first client application239acould insert a graphical representation of the user's signature into the document. In addition, the first client application239acould also cryptographically sign the file249utilizing the certificate233and insert the digital signature into the file249along with additional information to allow the signature to be authenticated, verified, and irrefutable.

In some implementations, the first client application239amay convert the file249from a first file type to a second file type prior to signing the file249. For example, some types of files (e.g., a portable document file (PDF)) may natively support electronic or digital signatures, while other file types (e.g., plaintext files) may not. In such an example, the first client application239acould first convert the plaintext file249into a PDF file249prior to signing the file249.

Once the certificate233has been stored in the client data store246by the first client application239a,other client applications239that incorporate the functionality of the credential application243(e.g., other client applications239that link to the same SDK as the first client application239a) can also use the certificate233to electronically sign other files or documents. For example, at steps323,326, and329, a second client application239bcould open a file249, retrieve the same certificate233stored by the first client application239a,and use the certificate233to electronically sign files249or documents on behalf of a user.

Referring next toFIG.4, shown is a sequence diagram that provides one example of the interaction between the various components of the network environment200. The sequence diagram ofFIG.4provides merely an example of a possible implementation of the present disclosure. As an alternative, the flowchart ofFIG.4can be viewed as depicting an example of elements of a method implemented in the network environment200according to one or more embodiments.

Beginning at step403, the credential application243sends a request to the certificate authority216for a certificate233for use for electronically signing files249or documents. The request might be sent, for example, when a client device100is first registered with the management service219or when a previous certificate233has expired or been revoked. The request can include an identifier of the user account associated with the client device100in order to allow the certificate authority216to provide the appropriate certificate233in response.

Next at step405, the certificate authority216provides the requested certificate233in response. If necessary, the certificate authority216may generate the certificate233at this stage. This can occur, for example, if a valid certificate233has not been previously created or if a previous certificate233has expired but not yet been replaced or reissued. At respective step407, the credential application243receives the certificate233and stores it in the client data store246for subsequent use.

Then at step409, a client application239opens a file249. This may occur, for example, when a user of the client device100uses the client application239to view or edit a file249on the client device100.

Subsequently at step413, the client application239sends the file249to the credential application243to be electronically signed. This can occur, for example, when a user manipulates a user interface element106rendered on the display103of the client device to electronically sign the file249.

Next at step416, the credential application243may optionally request authentication credentials236associated with the certificate233from the client application239. This may be done, for example, to authenticate or otherwise verify that the user of the client device100is authorized to utilize the certificate233to electronically sign the file249.

Then at step419, the client application239can obtain the authentication credentials236from the user and send the authentication credentials236to the credential application243. For example, the client application239could cause a prompt109to be rendered on the display103of the client device100. The user could input his or her authentication credentials236, such as a password or personal identification number (PIN), into the prompt. The authentication credentials236could then be sent to the credential application243.

Subsequently at step423, the credential application243can verify the authentication credentials236received from the client application239. For example, the credential application243could compare the received authentication credentials236with the authentication credentials236stored in association with the certificate233. If the two sets of authentication credentials236match, then the user of the client device100is permitted to utilize the certificate233. As another example, if the authentication credentials236received from the client application239are able to successfully decrypt the certificate (e.g., where the certificate is encrypted within a PKCS #12 container), then the credential application243could determine that the user of the client device100is permitted to utilize the certificate233.

Next at step426, the credential application243signs the file249. For example, the credential application243could insert a graphical representation of the user's signature into the file249. Further, the credential application243could use the certificate233to generate a cryptographic signature of the file249and include information about the certificate233used to generate the cryptographic signature of the file249in the file249. This additional information could include a fingerprint or similar unique identifier of the certificate233, the date and time that the cryptographic signature for the file249was generated, and potentially other information.

In some implementations, the credential application243may first convert the file249from a first file type to a second file type prior to signing the file249. For example, some types of files (e.g., a portable document file (PDF)) may natively support electronic or digital signatures, while other file types (e.g., plaintext files) may not. In such an example, the credential application243could first convert the plaintext file249into a PDF file249prior to signing the file249.

Finally, at step429, the credential application243can then return the signed file249to the client application239.

Referring next toFIG.5, shown is a sequence diagram that provides one example of the interaction between the various components of the network environment200. The sequence diagram ofFIG.5provides merely an example of a possible implementation of the present disclosure. As an alternative, the flowchart ofFIG.5can be viewed as depicting an example of elements of a method implemented in the network environment200according to one or more embodiments.

Beginning at step503, the credential application243can request a certificate233for signing files249or other documents. For example, the credential application243may send a request for a certificate133in response to registration or enrollment of the client device100with the management service219or in response to installation of the client application239. Accordingly, the request can include an identifier of a user account225.

Then at step506, the certificate authority216can provide the certificate233in response to the request. For example, the certificate authority216may select a certificate233associated with the user account225identified in the request and return the certificate233to the credential application243.

Subsequently at step509, the client application239can open a file249. For example, a user of the client device100may attempt to open a document attached to an email. As another example, the user of the client device100may attempt to open a file249stored in a file hosting service or similar content locker.

Proceeding to step513, the client application239can then request the certificate233from the credential application243. The request for the certificate may occur in response to a user interaction with a user interface element106that allows for a user to electronically sign the file249.

Then at step516, the credential application243can optionally request authentication credentials236from the client application239to verify that the user of the client application239or client device100is authorized to sign the file249using the certificate233.

Next at step519, the client application239provides the requested authentication credentials236. For example, the client application239may, in response to the request at step516, cause a prompt109to be rendered on the display103of the client device100. The user could then enter authentication credentials236(e.g., a password, PIN, one-time password token, etc.), which can be provided to the credential application243.

Proceeding to step523, the credential application243can verify the authentication credentials236received from the client application239. For example, the credential application243could compare the received authentication credentials236with the authentication credentials236stored in association with the certificate233. If the two sets of authentication credentials236match, then the user of the client device100is permitted to utilize the certificate233. As another example, if the authentication credentials236received from the client application239are able to successfully decrypt the certificate (e.g., where the certificate is encrypted within a PKCS #12 container), then the credential application243could determine that the user of the client device100is permitted to utilize the certificate233.

Then at step526, the credential application243can provide the certificate233to the client application239. The certificate233can be provided in response to a determination at step523that the authentication credentials236provided by the client application239match the authentication credentials236associated with the certificate233.

Next at step529, the client application239can electronically sign the file249using the certificate233received from the credential application243. For example, the client application239could insert a graphical representation of the user's signature into the file249. Further, the client application239could use the certificate233to generate a cryptographic signature of the file249and include information about the certificate233used to generate the cryptographic signature of the file249in the file249. This additional information could include a fingerprint or similar unique identifier of the certificate233, the date and time that the cryptographic signature for the file249was generated, and potentially other information.

In some implementations, the client application239may first convert the file249from a first file type to a second file type prior to signing the file249. For example, some types of files (e.g., a portable document file (PDF)) may natively support electronic or digital signatures, while other file types (e.g., plaintext files) may not. In such an example, the client application239could first convert the plaintext file249into a PDF file249prior to signing the file249.

Referring next toFIG.6, shown is a sequence diagram that provides one example of the interaction between the various components of the network environment200. The sequence diagram ofFIG.6provides merely an example of a possible implementation of the present disclosure. As an alternative, the flowchart ofFIG.6can be viewed as depicting an example of elements of a method implemented in the network environment200according to one or more embodiments.

Beginning at step603, the client application239identifies a recipient for the file249. For example, an email client might identify a recipient based off of an email address in the “To” or “CC” fields of an email. As another example, a chat or messaging application might identify a recipient based off of a username or similar identifier. In some instances, the client application239may provide a mechanism for a user to manually identify the recipient.

Then at step606, the client application sends the file249to the credential application243for encryption. The request can include both a copy of the file249and the identifiers of the recipients. In some instances, the request may also specify encryption preferences, such as a minimum key-strength, a preferred encryption algorithm, etc.

Next at step609, the credential application243can request a copy of an encryption certificate233from the certificate authority216. For example, the credential application243can send the user identifiers received from the client application239to the certificate authority216.

Proceeding to step613, the certificate authority provides the certificates233associated with the identified user accounts225in response to the request from the credential application243.

Moving to step616, the credential application243receives the certificates233. In some implementations, the certificates233may be locally stored on the client device100(e.g., in the client data store246) for future use. In other implementations, the certificates233may be deleted after subsequent encryption operations are performed in order to provide an extra degree of security should the client device100be compromised.

Then at step619, the credential application243can encrypt the file249using the certificate233associated with the recipient. For example, if the certificate233specifies a user's public encryption key, the public encryption key specified in the certificate could be used to encrypt the file249. In some implementations, the file249may also be signed either before and/or after the file249is encrypted. Signing the file249and obtaining the requisite signing certificates233may occur utilizing one of the approaches described previously with respect toFIGS.3-5.

Next at step623, the credential application243can return the encrypted file249to the client application239. In some implementations, the credential application243may securely delete the unencrypted version of the file249from the memory of the client device100. This may be done, for example, to minimize the chances of accidental disclosure of sensitive information contained in the file249.

Then at step626, the client application239can share or send the encrypted file249with the recipient(s). For example, an email application could attach and send the encrypted file249to the specified recipients. As another example, a chat or messaging application could embed the encrypted file249in a message sent to another user.

Although the certificate authority216, the management service219, the derived credentials service221, the client application239, the multifactor authentication application241, the management agent242, and the credential applications243, and other various systems described herein can be embodied in software or code executed by general-purpose hardware as discussed above, as an alternative, the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components.

The sequence diagrams show examples of the functionality and operation of various implementations of portions of components described in this application. If embodied in software, each block can represent a module, segment, or portion of code that can include program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that can include human-readable statements written in a programming language or machine code that can include numerical instructions recognizable by a suitable execution system such as a processor in a computer system or other system. The machine code can be converted from the source code. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

Although the sequence diagrams show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. In addition, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some examples, one or more of the blocks shown in the drawings can be skipped or omitted.

Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as, for example, a processor in a computer system or other system. In this sense, the logic can include, for example, statements including program code, instructions, and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system.

The computer-readable medium can include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium include solid-state drives or flash memory. Any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices.

It is emphasized that the above-described examples of the present disclosure are merely possible examples of implementations set forth for a clear understanding of the principles of the disclosure. Many variations and modifications can be made to the above-described embodiments without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure.