SHARING ENCRYPTED ITEMS WITH PARTICIPANTS VERIFICATION

Abstract

A method and apparatus for establishing a trust relationship between users is disclosed. The apparatus includes at least two user devices containing the Application, a service provider server (SPS) comprising an application programming interface (API), a network communicably coupling the sender device, the receiver device and the SPS, and an out-of-band (OOB) channel, separate from the network, communicably coupling the sender device and the receiver device. The method includes obtaining a receiver's Public Key provided by an Application Programming Interface (API) on an service provider server, encrypting a verification message with the Receiver's Public key and the Sender's Private Key, sending the encrypted verification message from the Sender's device to the Receiver's device through the out-of-band channel, decrypting the encrypted verification message using Receiver's Private Key and Sender's Public Key, and communicating decrypted verification message via out-of-band channel.

Claims

1. A method comprising: establishing, by a sender system, cryptographic trust with a receiver system, wherein establishing cryptographic trust includes: obtaining, from a service provider server, via a first electronic communication network, a public encryption key of the receiver system; generating a verification message including first verification message content; generating a signed, encrypted, verification message by encrypting the verification message using the public encryption key of the receiver system and a private encryption key of the sender system; sending, via a second electronic communication network that differs from the first electronic communication network, the signed verification message to the receiver system; receiving, from the receiver system, via a third electronic communication network that differs from the first electronic communication network, second verification message content; and verifying that the first verification message content matches the second verification message content.

2. The method of claim 1, wherein: the public encryption key of the receiver system is a part of a device-independent asymmetric key pair that includes a private encryption key of the receiver system; and the private encryption key of the sender system is a part of a device-independent asymmetric key pair that includes a public encryption key of the sender system.

3. The method of claim 2, wherein generating the signed, encrypted, verification message includes: generating an encrypted verification message by encrypting the verification message using the public encryption key of the receiver system; and generating the signed, encrypted, verification message by encrypting the encrypted verification message using the private encryption key of the sender system.

4. The method of claim 2, wherein establishing cryptographic trust includes: signing the public encryption key of the receiver system with the private encryption key of the sender system.

5. The method of claim 2, wherein the third electronic communication network is the second electronic communication network, wherein the second electronic communication network excludes the service provider server.

6. The method of claim 2, further comprising: sharing, by the sender system, an encrypted digital item with the receiver system, wherein sharing the encrypted digital item includes: obtaining an unencrypted digital item; obtaining an item key for encrypting the digital item; obtaining the encrypted digital item by encrypting the unencrypted digital item using the item key; obtaining an encrypted item key by encrypting the item key with the public encryption key of the receiver system; and outputting the encrypted digital item and the encrypted item key to the service provider server, such that the unencrypted digital item is accessible to the receiver system by: obtaining the encrypted digital item, the encrypted item key, and the public encryption key of the sender system from service provider server; obtaining the item key by decrypting the encrypted item key using the private encryption key of the receiver system; and obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key.

7. The method of claim 6, wherein obtaining the item key includes: generating a symmetric key for encrypting the digital item; and using the symmetric key as the item key.

8. The method of claim 6, wherein obtaining the public encryption key of the receiver system includes: receiving, from service provider server, the public encryption key of the receiver system in response to sending, to service provider server, a request to identify the receiver system.

9. The method of claim 6, wherein obtaining the item key includes: obtaining a second encrypted item key, encrypted with the public encryption key of the sender system; and obtaining the item key by decrypting the second encrypted item key using the private encryption key of the sender system.

10. The method of claim 9, wherein sharing the encrypted digital item includes: obtaining a symmetric master key using a master password and a salt value; generating the public encryption key of the sender system and the private encryption key of the sender system; and encrypting the private encryption key of the sender system using the symmetric master key, such that the private encryption key of the sender system is unavailable in the absence of the symmetric master key.

11. A system comprising: a memory storing instructions for establishing cryptographic trust; a processor that executes the instructions to establish cryptographic trust between the system and an external system, wherein to establish cryptographic trust between the system and the external system, the processor executes the instruction to: obtain, from a service provider system, via a first electronic communication network, a public encryption key of the external system, wherein the public encryption key of the external system is a part of a device-independent asymmetric key pair that includes a private encryption key of the external system; generate a verification message that includes first verification message content; generate a signed, encrypted, verification message, wherein, to generate the signed, encrypted, verification message, the processor executes the instructions to use the public encryption key of the external system and a private encryption key of the system to encrypt the verification message, wherein the private encryption key of the system is a part of a device-independent asymmetric key pair that includes a public encryption key of the system; send, to the external system, via a second electronic communication network that differs from the first electronic communication network, the signed verification message; receive, from the external system, via a third electronic communication network that differs from the first electronic communication network, second verification message content; and verify that the first verification message content matches the second verification message content.

12. The system of claim 11, wherein to generate the signed, encrypted, verification message, the processor executes the instruction to: generate an encrypted verification message, wherein, to generate the encrypted verification message, the processor executes the instruction to use the public encryption key of the external system to encrypt the verification message; and generate the signed, encrypted, verification message, wherein, to generate the signed, encrypted, verification message, the processor executes the instruction to use by the private encryption key of the system to encrypt the encrypted verification message.

13. The system of claim 11, wherein, to establish cryptographic trust, the processor executes the instruction to: sign the public encryption key of the external system, wherein, to sign the public encryption key of the external system, the processor executes the instruction to use the private encryption key of the system to encrypt the public encryption key of the external system.

14. The system of claim 11, wherein the third electronic communication network is the second electronic communication network, and wherein the second electronic communication network excludes the service provider server.

15. The system of claim 11, wherein the processor executes the instruction to: share an encrypted digital item with the external system, wherein, to share the encrypted digital item, the processor executes the instruction to: obtain an unencrypted digital item; obtain an item key for encrypting the digital item; obtain the encrypted digital item, wherein, to obtain the encrypted digital item, the processor executes the instruction to use the item key to encrypt the unencrypted digital item; obtain an encrypted item key, wherein, to obtain the encrypted item key, the processor executes the instruction to use the public encryption key of the external system to encrypt the item key; and output the encrypted digital item and the encrypted item key to the service provider server, such that the unencrypted digital item is accessible to the external system by: obtaining the encrypted digital item, the encrypted item key, and the public encryption key of the system from service provider server; obtaining the item key by decrypting the encrypted item key using the private encryption key of the external system; and obtaining the unencrypted digital item by decrypting the encrypted digital item using the item key.

16. The system of claim 11, wherein, to obtain the item key, the processor executes the instruction to: generate a symmetric key for encrypting the digital item; and use the symmetric key as the item key.

17. The system of claim 11, wherein, to obtain the public encryption key of the external system, the processor executes the instruction to: receive, from service provider server, the public encryption key of the external system in response to sending, to service provider server, a request to identify the external system.

18. The system of claim 11, wherein, to obtain the item key, the processor executes the instruction to: obtain a second encrypted item key, encrypted with the public encryption key of the system; and obtain the item key, wherein, to obtain the item key, the processor executes the instruction to use the private encryption key of the system to decrypt the second encrypted item key.

19. The system of claim 18, wherein, to share the encrypted digital item, the processor executes the instruction to: use a master password and a salt value to obtain a symmetric master key; generate the public encryption key of the system and the private encryption key of the system; and use the symmetric master key to encrypt the private encryption key of the system, such that the private encryption key of the system is unavailable in the absence of the symmetric master key.

20. A non-transitory computer-readable storage medium, comprising executable instructions that, are executed by a processor to perform: establishing, by a sender system, cryptographic trust with a receiver system, wherein establishing cryptographic trust includes: obtaining, from a service provider server, via a first electronic communication network, a public encryption key of the receiver system; generating a verification message including first verification message content; generating a signed, encrypted, verification message by encrypting the verification message using the public encryption key of the receiver system and a private encryption key of the sender system; sending, via a second electronic communication network that differs from the first electronic communication network, the signed verification message to the receiver system; receiving, from the receiver system, via a third electronic communication network that differs from the first electronic communication network, second verification message content; and verifying that the first verification message content matches the second verification message content.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0048] FIG. 1 is a component diagram of a computing system that may be the participant of an encryption protection application setup.

[0049] FIG. 2 is a component diagram of an Application user device.

[0050] FIG. 3 is a component diagram of API

[0051] FIG. 4 is a depiction of encrypted item sharing method 400.

[0052] FIG. 5 is to support application user verification method 500.

[0053] FIG. 6 is a demonstration of an exemplary method involving the present embodiments. As shown in the diagram, the method 400 involves a customer of the encryption protection application sharing an encrypted item with another customer of said application.

[0054] FIG. 7 is a display of a method comprising the present embodiments. Demonstrated in the diagram is the method 500 that involves a customer of the encryption protection application initiating a verification flow in order to validate another customer of said encryption protection application.

[0055] FIG. 8 is an architectural layout of an apparatus for sharing encrypted items with participants verification.

DETAILED DESCRIPTION

[0056] Some general terminology definitions as well as descriptions of invention components and participants may be helpful and are included herein for convenience and are intended to be interpreted in the broadest possible interpretation:

[0057] Application 202—a computer program, a computer code, a set of instructions executed within the User device with the particular purpose of protecting digital objects and items with encryption, sharing the protected objects and items with other users of the same application, as well as verifying other users of the same application.

[0058] User device 200—a computing device where a person installs and executes the application. The person can be a Sender or a Receiver, or both.

[0059] Sender—a role that a computer user assumes when initiating a Sharing of an encrypted item with another computer user.

[0060] Receiver—a role that a computer user is assigned when an encrypted item has been shared with the said user, for example from the Sender.

[0061] API (300)—the designated name of the sum of programmatic endpoints for communication between the service provider and Application 202 users. Service provider can be any legal entity, that owns and is responsible for the functioning of API. In the context of the described embodiments service provider can be represented by a Service Provider Server (SPS), a computing device that has the programmatic code of API 300 deployed and executed within. The provider participates in sharing and verification workflows as an assisting mediator and is not intended to have access to the decrypted items or the cryptographic keys necessary to decrypt said items. API also contains data comprised of user attributes, encrypted items and corresponding Item encryption Keys, stored in API in an encrypted form.

[0062] Out-of-band channel, or OOB—the exchange of messages or data between Sender and Receiver that circumvents API, be it a direct contact, a phone call, email communication, SMS communication, communication by any chat application or any other channel that is not related to the API.

[0063] Master Key 204—a symmetric encryption key, which is unique for each user of the solution, and is derived from a Master password known only to a user. Additionally, the Master Key 204 includes additional entropy, e.g. Salt 212, which is unique to each user, provided by the service provider. The Master Key 204 is used to encrypt a Private Key 206 of an asymmetric key pair of the user.

[0064] Public Key 214—the public part of an asymmetric key pair belonging to the user. This key is publicly accessible to everyone, e.g. another user of the Application 202. This key is used to encrypt data so that only the owner of the corresponding private key can decrypt the data. The secondary function of the Public Key 214 is to verify cryptographic signatures produced with the corresponding private key. According to some embodiments, the Public Key 214 is also employed to encrypt Item Keys 208 to protect the Item Keys 208 from being accessed by anyone except the legitimate owner of the corresponding asymmetric key pair.

[0065] Private Key 206—the private part of the asymmetric key pair belonging to the user. This key is kept secret and is not supposed to be accessible to an entity other than the owning user. The primary function of the key is to decrypt the data encrypted with the corresponding Public Key 214. The secondary function is to cryptographically sign a piece of data, for example a particular item belonging to a user. The signature can be verified by anyone who can access the corresponding Public Key 214. According to some embodiments, the Private Key 206 is used to decrypt item keys before they can be used to access protected items.

[0066] Item—any object stored in API, accessed through the Application 202, protected by encrypting an object or item with an individual symmetric Item Key 208.

[0067] Item Key 208—a symmetric key, created for individually encrypting a single protected item. This key is encrypted by the user's Public Key 214 and can only be decrypted with the user's Private Key 206. Verification message—an arbitrary string of characters, numbers and symbols, that when encrypted by Sender and communicated to Receiver, is a prerequisite for user verification.

[0068] The current embodiments disclose a computer implemented method for establishing a two-way trust between users of the Application 202. The disclosed method comprises: obtaining, at a Sender's device, a receiver's Public Key 214 provided by API; encrypting, at the Sender's device, a verification message with the Receiver's Public Key 214 and the Sender's Private Key 206; sending the encrypted verification message from the Sender's device to the Receiver's device through the out-of-band channel; decrypting, at the Receiver's device, the encrypted verification message using Receiver's Private Key 206 and Sender's Public Key 214; communicating, from the Receiver to the Sender, decrypted verification message via out-of-band channel 602; confirming by the Sender that the decrypted verification message, communicated by the Receiver, is identical to the verification message encrypted by the Sender; establishing, by the Receiver, a one-way trust by signing the Sender's Public Key 214 at the Receiver's device, with the Receiver's Private Key 206; signing, at the Sender's device, the Receiver's Public Key 214 with the Sender's Private Key 206, to establish a two-way trust.

[0069] In the verification method, the signed Sender's Public Key 214 is stored in at least one of the following: the API, the Receiver's device, or a database, accessible from the Application 202 user's device. The API is provided by a service provider server, serving as a communication mediator between the Sender's device and the Receiver's device during verification flow.

[0070] During the verification flow, the out-of-band channel 602 is used. It can be at least one of the following: a direct conversation, phone call, email communication, SMS, communication by an Internet chat application, or any other communication channel that does not rely upon the API. The asymmetrical encryption method is used.

[0071] The disclosed method also describes the sharing of an encrypted item with another user of the Application 202. The sharing contains the following steps: requesting, from the sender to the API, receiver's Public Key 214 by providing at least one of an email ID or other identifying information of the receiver to the API; receiving, at the sender device, Receiver's Public Key 214 from the API; encrypting an Item Key 208 with Receiver's Public Key 214, the individual Item Key 208 corresponding to an Item 210 to be sent from the Sender's device to the Receiver's device; sending, from the Sender's device, the encrypted Item Key 208 to the API with an Item 210 identification; obtaining, at the receiver device, the encrypted Item Key 208 from the API; decrypting the Item Key 208 with Receiver's Private Key 206; decrypting the Item 210 using the decrypted Item Key 208; informing the Sender, by the API, about the access occurring, marking the share as successful within the API.

[0072] The method for sharing encrypted items, further comprising the steps of assigning a unique item identification to the Item 210 that is shared; and encrypting the Item 210 using an individual symmetric Item Key 208.

[0073] In case the Receiver's Public Key 214 is not accessible to the Sender, the Sender records the information about the attempted share in API 300, signing this information with Sender's Private Key 206. The information includes Sender's identification, Item Identification, Receiver's email and Sender's digital signature. In such a scenario, Receiver generates an asymmetric key pair at the Receiver's device and makes the Receiver's Public Key 214 available to the Sender for download of the Receiver's Public Key 214 from API 300.

[0074] The embodiments also disclose an apparatus for establishing a trust relationship between users. The apparatus comprises: a sender device containing the Application; a receiver device containing the Application; a service provider server (SPS) containing the application programming interface (API); a network communicably coupling the sender device, the receiver device and the SPS; and an out-of-band (OOB) channel, separate from the network, communicably coupling the sender device and the receiver device, wherein the apparatus performs a method of: obtaining, at a Sender's device, a receiver's Public Key provided by an Application Programming Interface (API), encrypting, at the Sender's device, a verification message with the Receiver's Public key and the Sender's Private Key, sending the encrypted verification message from the Sender's device to the Receiver's device through the out-of-band channel, decrypting, at the Receiver's device, the encrypted verification message using Receiver's Private Key and Sender's Public Key, communicating, from the Receiver to the Sender, decrypted verification message via out-of-band channel, confirming by the Sender that the decrypted verification message, communicated by the Receiver, is identical to the verification message encrypted by the Sender, establishing, by the Receiver, a one-way trust by signing the Sender's Public Key at the Receiver's device, with the Receiver's Private Key.

[0075] In the disclosed apparatus the signed Sender's Public Key is stored in at least one of the following: the API, the Receiver's device, or a database, accessible from the Application user's device. The API is provided by a service provider server, serving as a communication mediator between the Sender's device and the Receiver's device during verification flow.

[0076] In the disclosed method and apparatus, the Application can be a stand-alone application installed locally within the user's device or remotely, an application's plug-in, an application executed locally or remotely, or an application made available to the user in any other form.

[0077] The embodiments herein may be combined in a variety of ways as a matter of design choice. Accordingly, the features and aspects herein are not intended to be limited to any particular embodiment. Furthermore, the embodiments can take the form of hardware, firmware, software, and/or combinations thereof. In one embodiment, such software includes but is not limited to firmware, resident software, microcode, etc. FIG. 1 illustrates a computing system 100 in which a Computer Readable Medium 106 may provide instructions for performing any of the methods and processes disclosed herein.

[0078] Furthermore, some aspects of the embodiments herein can take the form of a computer program product accessible from the Computer Readable Medium 106 to provide program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, the Computer Readable Medium 106 can be any apparatus that can tangibly store the program code for use by or in connection with the instruction execution system, apparatus, or device, including the Computing System 100.

[0079] The Computer Readable Medium 106 can be any tangible electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device). Some examples of a Computer Readable Medium 106 include solid state memories, magnetic tapes, removable computer diskettes, random access memories (RAM), read-only memories (ROM), magnetic disks, and optical disks. Some examples of optical disks include read only compact disks (CD-ROM), read/write compact disks (CD-R/W), and digital versatile disks (DVD).

[0080] The Computing System 100 can include one or more processors 102 coupled directly or indirectly to Program and Data Memory 108 through a system bus 110. The Program and Data Memory 108 can include local memory employed during actual execution of the Application 202, bulk storage, and/or cache memories, which provide temporary storage of at least some of the program code in order to reduce the number of times the code is retrieved from bulk storage during execution.

[0081] Input/output (I/O) devices 104 (including but not limited to keyboards, displays, pointing devices, I/O interfaces, etc.) can be coupled to the Computing System 100 either directly or through intervening I/O controllers. Network adapters may also be coupled to the Computing System 100 to enable the Computing System 100 to couple to other data processing systems, such as through Host Systems Interfaces 112, printers, and/or or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just examples of network adapter types.

[0082] FIG. 1 is a component diagram of a Computing System 100 that shows an overall hardware architecture of a computer system that is running the Application 202. The Computing System 100 combines I/O devices 104, Processor 102, Computer Readable Medium 106, Program and Data Memory 108, Host Systems Interfaces 112. The Computing System 100 is a User device 200.

[0083] FIG. 2 is a component diagram of elements that are contained within User device 200. The User device 200 contains at least the following: computer Application 202, Master Key 204, Private Key 206, Item Key 208, Item 210, Salt 212, Public Key 214.

[0084] FIG. 3 is a component diagram of the API 300. API 300 contains Users data, such as: User Public Key 214 and User Salt 212. API also contains Protected items and keys: Item Key 208 encrypted with User Public Key 214 and encrypted Item 210. Items and keys contained therein are the encrypted versions of objects in User device 200, or objects publicly available.

[0085] FIG. 4 is a sequence diagram of a method 400 for sharing an Item encrypted 308, according to embodiments of the present invention. At step 402, sender opens an Item 210 locally and decrypts the Item 210. At step 404, the sender obtains Receiver's Public Key from API at service provider. Next, as step 406, the sender encrypts Item Key 208 with Receiver's Public Key. Next, at step 408, the Sender stores encrypted Item Key 208 and the corresponding Item 210 in API, step 408. The Sender launches the verification, step 410 and notifies Receiver of the shared Item 210, step 412. Receiver obtains Sender's Public Key, step 414 and verifies the Sender, step 416. By the next step, the Receiver obtains encrypted Item Key from API, step 418. The Receiver decrypts encrypted Item Key locally 420 and obtains Item 210 from API, step 422. Receiver decrypts Item 210 locally, step 424.

[0086] FIG. 5 depicting a method 500 for user verification, as implemented by the Application 202 of FIG. 2. The diagram discloses the steps of Receiver verifying the Sender. Sender obtains from API Receiver's Public Key, step 502, then Sender generates verification message, step 504. Verification message is encrypted with Receiver's Public Key and Sender's Private Key, step 506. Sender sends an encrypted verification message to Receiver through OOB (Out-of-band channel), step 508. Receiver obtains Sender's Public Key from API, step 510. Receiver decrypts the verification message with Receiver's Private Key and Sender's Public Key, step 512. After this step, Receiver communicates the decrypted verification message to Sender through OOB, step 514. If the verification messages coincide, Receiver signs Sender's Public Key with Receiver's Private Key, step 516 and Receiver stores signed Sender's Public Key at API, step 518.

[0087] FIG. 6 adds additional clarity regarding the initiators of particular steps and the direction of communication. FIG. 6 shows a method for sharing an Item encrypted with Item Key 308, according to an embodiment of the present invention. At step 402, Sender opens an Item 210 locally and decrypts the Item 210. At step 404, the sender obtains Receiver's Public Key from API at service provider. Next, as step 406, the sender encrypts Item Key 208 with Receiver's Public Key. Next, at step 408, the Sender stores encrypted Item Key 208 and the corresponding Item 210 in API, step 408. The Sender launches the verification, step 410 and notifies Receiver of the shared Item 210, step 412. Receiver obtains Sender's Public Key, step 414 and verifies the Sender, step 416. By the next step, the Receiver obtains encrypted Item Key from API, step 418. The Receiver decrypts encrypted Item Key locally 420 and obtains Item 210 from API, step 422. Receiver decrypts Item 210 locally, step 424. For the person skilled in the art it should be clear that the verification flow mentioned in this description can be initiated by any participant of the sharing flow, since in the end of the verification flow both users have sufficient information to trust their counterpart. Therefore, the trust established based on the verification can be one-way in any direction or two-way. Also it should be noted that verification is not rigidly attached to a particular place in the sharing flow, therefore it can be launched either by the Sender before sharing a protected item with another user of the Application, or by the Receiver on getting notification about an Item being shared with Receiver.

[0088] FIG. 7 adds additional clarity regarding the initiators of particular steps and the direction of communication. FIG. 7 depicts a method 500 for user verification, as implemented by the Application 202 of FIG. 2. The diagram discloses the steps of Receiver verifying the Sender. Sender obtains from API Receiver's Public Key, step 502, then Sender generates verification message, step 504. Verification message is encrypted with Receiver's Public Key and Sender's Private Key, step 506. Sender sends an encrypted verification message to Receiver through OOB (Out-of-band channel), step 508. Receiver obtains Sender's Public Key from API, step 510. Receiver decrypts the verification message with Receiver's Private Key and Sender's Public Key, step 512. After this step, Receiver communicates the decrypted verification message to Sender through OOB, step 514. If the verification messages coincide, Receiver signs Sender's Public Key with Receiver's Private Key, step 516 and Receiver stores signed Sender's Public Key at API, step 518. For the person skilled in the art it should be clear that in the current embodiment the verification flow can be initiated by any participant of the sharing flow, since in the end of the verification flow both users have sufficient information to trust their counterpart. Therefore, the trust established based on the verification can be one-way in any direction or two-way. Also it should be noted that verification is not rigidly attached to a particular place in the sharing flow, therefore it can be launched either by the Sender before sharing a protected item with another user of the Application, or by the Receiver on getting notification about an Item being shared with Receiver.

[0089] In one aspect, the present embodiments include a system and a method for effectively sharing encrypted data (such as passwords, access to digital items). Those of ordinary skill in the art will realize that the following detailed description of the present embodiments is illustrative only and is not intended to be in any way limiting. Other embodiments of the present system(s) and method(s) will readily suggest themselves to such skilled persons having the benefit of this disclosure. Reference will now be made in detail to implementations of the present embodiments as illustrated in the accompanying drawings. The same reference indicators will be used throughout the drawings and the following detailed description to refer to the same or like parts.

[0090] Although several embodiments have been described, one of ordinary skill in the art will appreciate that various modifications and changes can be made without departing from the scope of the embodiments detailed herein. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present teachings.

[0091] Moreover, in this document, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. The terms “comprises”, “comprising”, “has”, “having”, “includes”, “including”, “contains”, “containing” or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises, has, includes, contains a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. An element preceded by “comprises . . . a”, “has . . . a”, “includes . . . a”, “contains . . . a” does not, without more constraints, preclude the existence of additional identical elements in the process, method, article, or apparatus that comprises, has, includes, contains the element. The terms “a” and “an” are defined as one or more unless explicitly stated otherwise herein. The terms “substantially”, “essentially”, “approximately”, “about” or any other version thereof, are defined as being close to as understood by one of ordinary skill in the art. The term “coupled” as used herein is defined as connected, although not necessarily directly and not necessarily mechanically. A device or structure that is “configured” in a certain way is configured in at least that way, but may also be configured in ways that are not listed.