Message bus key agreement scheme

Methods, computer program products, and systems are provided for using a single shared secured connection among all servers in a cluster by efficiently establishing and securely disseminating a shared key between the servers. In particular, this is done by using a Diffie-Hellman key agreement scheme among the servers using an ordered list of servers generated on-the-fly.

BACKGROUND

A virtual appliance is a pre-installed, pre-configured operating system and software solution delivered inside a virtual machine (VM), running on a VM server machine. A VM “Snap Shot” is a copy of the state of a VM at a particular point in time. VM Snap Shots can be instantiated to create a new VM from the state when the VM Snap Shot was created. Multiple VMs can be created on the same physical server by starting multiple instances of the same VM Snap Shot. The VMs thus created would be clones of one another, starting out from the same state. The virtualizing operating system alters the clones slightly, assigning each a different IP address and other parameters to ensure the VMs can interoperate. In some environments, a large number of VMs run on a cluster of VM servers, connected by a network. In some virtualizing operating systems, resource schedulers exist which automatically detect the load on a VM server. If the load is too great, the resource scheduler can be configured to cause a new VM server to boot up to spread the load among a greater number of VM servers.

When a new VM server starts up, it should, without intervention, be able to automatically configure itself. It should also be able to detect other VM servers which it needs to communicate with, as well as other entities within the cluster.

In some systems, each VM server in the cluster has an encrypted transport layer security (TLS) connection to each other VM server within the cluster, forming a mesh of TLS connections. In some arrangements, the TLS connections utilize elliptic curve cryptography (ECC) for the encryption. Thus, when a new VM server is activated, it establishes a new mutually authenticated TLS connection with each server already operating within the cluster.

In other systems, each server in the cluster communicates with other servers via a central message bus. Each server in the cluster has a separate encrypted TLS connection to the message bus. Thus, when a new VM server is activated, it establishes a new mutually authenticated TLS connection with the message bus.

SUMMARY

The above described approaches suffer from deficiencies. In particular, in the meshed TLS connection approach, if there are N servers, 3(N2−N) ECC scalar multiplications are required to establish, sign, and verify the full meshwork of mutually authenticated keys, which may be slow. Moreover, each VM server is required to maintain N separate encryption keys and messages sent to multiple servers must be encrypted several times. In the separate TLS central message bus approach, data needs to encrypted and re-encrypted at the message bus, which may be slow, and it allows the data to be temporarily unsecured within the message bus. In addition, in both approaches, data at the servers must either be locally stored in unencrypted form, or it must be re-encrypted prior to local storage, wasting processing resources through repetitive decryption/encryption.

In contrast to the above-described approaches, embodiments of the present disclosure are directed to techniques for using a single shared secured connection between all servers in the cluster by efficiently establishing and securely disseminating a shared key among the servers. In particular, this is done by using a Diffie-Hellman key agreement scheme among the servers using an ordered list of servers generated on-the-fly. This approach allows the servers in the cluster to securely communicate with each other with efficient setup and without necessitating re-encryption at a central message bus or for local storage.

In particular, in one embodiment, a method is provided for securely establishing an encryption key shared among members of a set of servers on a network, the set of servers including at least three servers. The method includes, at a first server of the set of servers, (a) computing a one-way function of a private key, a, uniquely associated with the first server, and a base element, Z, yielding a first public key, A, uniquely associated with the first server, as the result of this one-way function, (b) broadcasting a signal to the network, the signal requesting all servers of the set of servers, excluding the first server, to respond with identifying information, (c) receiving the identifying information from all servers of the set of servers, excluding the first server, (d) creating an ordered list of the identifying information of the set of servers, identifying information of the first server being at the beginning of the ordered list, (e) sending the ordered list and A to a second server of the set of servers, the second server being a server identified by the identifying information immediately following the first server's identifying information on the ordered list, (f) receiving, from a last server identified by the last identifying information on the ordered list, a set of one-way function results calculated by the last server based on information received from servers of the set of servers, (g) computing the one-way function of a and a last one-way function result of the received set of one-way function results, yielding a shared secret, and (h) deriving the encryption key from the shared secret. A system and computer program product for performing this method are also provided.

DETAILED DESCRIPTION

Embodiments of the present disclosure are directed to techniques for using a single shared secured connection between all servers in the cluster by efficiently establishing and securely disseminating a shared key among the servers. In particular, this is done by using a Diffie-Hellman key agreement scheme among the servers using an ordered list of servers generated on-the-fly. This approach allows the servers in the cluster to securely communicate with each other with efficient setup and without necessitating re-encryption at a central message bus or for local storage.

FIG. 1depicts an example system30for use in practicing various embodiments. System30may include a network32, connected to a plurality of server machines34, such as, for example, VM servers in a cluster arrangement. It should be understood that the servers34may be any sort of computerized devices, such as a computer, a mainframe, a terminal, a smart phone, etc.

It should also be understood that network32may be any sort of connection medium capable of connecting servers34such as a packet-switched network, a local area network, a wide area network, a storage area network, the Internet, a circuit-switched network, a fabric of interconnected cables and/or wires, a wireless network, a cellular network, or a point-to-point connection.

The system30is configured to utilize a multi-party key agreement scheme to allow servers34to agree on a shared encryption key for communication amongst them. In operation, servers34are configured to exchange messages in order to establish a shared secret and encryption key for use in cluster-wide secured communications. In particular, one server34, depicted as first server34(a) is configured to broadcast an invitation message40to the network32to begin the process of establishing the shared key. In response, the other servers34(b-f) all send identifying information42back to the first server34(a), which then assembles the identifying information into an ordered list44of identifying information about the servers34. First server34(a) then sends the ordered list44as well as various additional data for Diffie-Hellman key agreement in a first-round message50-1to a second server34(b), as will be described in detail below. A series of first-round messages, depicted as50-1through50-5, are sent in a circular arrangement between the servers34in the order from the ordered list44. Once the final first-round message50-5is received by the last server34(f), last server34(f) sends a second-round message52-1to first server34(a), as will be described in detail below. A series of additional second-round messages, depicted as52-2through52-5, are sent between the first server34(a) and the intermediate servers34(b-e) in the order from the ordered list44. Once this process, which will be described in further detail below, is completed, each server34has enough information to compute the shared encryption key, allowing for efficient and secured communications between the various servers34. For example, any one of servers34may communicate with any other of the servers34, such as first server34(a) and last server34(f), engaging in secured communications56across network32using the shared key.

FIG. 2depicts an example server34in further detail. All servers34have a similar design, but there may be some minor differences between them, particularly with respect to the data stored thereon.FIG. 2is primarily directed towards first server34(a), but differences will be pointed out in this Description between first server34(a), last server34(f), and the various intermediate servers34(b-e).

As depicted, server34includes a network interface62, a user interface64, a controller/processor66, and memory68. Controller66may be a processor, a microprocessor, a central processing unit, an integrated circuit, a collection of integrated circuits, a set of processing circuitry, a field programmable gate array, a signal processor, similar elements, or some combination thereof.

In some embodiments, controller66is a general purpose processor configured to execute operations stored in software programs contained within memory68. In connection with these embodiments, it should be understood that, within this document, any time a piece of software contained within memory68is described as performing a particular task or operation, that is mere shorthand for performance of the particular task or operation by the controller66executing code contained within that piece of software.

In other embodiments, controller66includes a set of processing circuitry that may be configured to perform operations directly in its hardware design as a pipeline of connected modules each having specifically-designed operations. In connection with these embodiments, it should be understood that, within this document, any time a piece of software contained within memory68is described as performing a particular task or operation, that is mere shorthand for performance of the particular task or operation by an appropriate circuitry module of the controller66.

Network interface62is a hardware device that is configured to connect server34to network34so that communications can be carried out across the network32. It should be understood that network interface62may have one or more connections to network32and that network interface62may connect to other networks in addition to network32. Network interface62, or, in some embodiments, an additional network interface, may also connect to other computerized devices, such as user terminals, personal computers, etc., for various purposes, such as, for example, remotely running a VM session or otherwise communicating with VM servers.

User interface64is an optional hardware interface that is configured to connect to various user interface devices (not depicted) that allow for communication between a human user and the server34by receiving user input and/or by providing information to the user. Examples of user interface devices that may connect to user interface64may include, for example, a display, a monitor, a television, a cathode ray tube, a liquid crystal display, a plasma display, a light-emitting diode display, a keyboard, a keypad, a mouse, a tracking pad, a tracking stick, a tracking ball, a touch screen, a biometric device, a joystick, a printer, a plotter, a projection screen, similar devices, or some combination thereof (not depicted).

Memory68may be any kind of digital memory, such as for example, system memory, cache memory, volatile memory, random access memory, read-only memory, static memory, programmable read-only memory, flash memory, magnetic disk-based storage, optical disk-based storage, a hard disk, a floppy disk, a compact disc, a digital versatile disc, a blu-ray disc, similar devices, or some combination thereof. Typically memory68will include high-speed volatile system memory for storage of executing programs and data as well as lower-speed non-volatile long-term storage for permanent storage of programs.

Memory68stores a key sharing module (KSM)70, an encrypted communication module72, and operating system (OS)74for execution by controller66. In some embodiments, OS74is a virtualizing OS, having a virtualization manager module75for execution by controller66.

Memory68also stores data area76. Data area76includes a set78of VM instances79managed by virtualization manager75, ordered list44, a variety of key-sharing data80-96used by key sharing module70, scratch space98for temporary use in performing calculations, and other data99, including, for example, executing programs as well as user files and application data. The key-sharing data80-96used by key sharing module70will be described in further detail below, in connection withFIG. 3.

The first server34(a) is configured to initiate a key agreement process to create a new key for a set of servers34, typically, upon first booting up and joining a cluster.

FIG. 3depicts a method100according to various embodiments. As depicted, method100is performed by first server34(a). Ancillary method102, also depicted inFIG. 3, includes various steps (depicted as boxes having dotted borders) associated with method100performed by the intermediate servers34(b-e) and/or last server34(f).

In optional preliminary step108, KSM70of first server34(a) randomly generates a base element, Z, and stores it as base element80within data area76. In one embodiment, used throughout this Description as the primary example, the elliptic curve (EC) Diffie-Hellman (DH) key agreement scheme is used rather than a basic Diffie-Hellman key agreement scheme. Thus, in one embodiment, step108includes choosing a random base point located on a specific EC. Typically, a pre-selected EC will be used.

ECs in common use are standardized by organizations such as the National Institute of Standards and Technology (NIST) and American National Standards Institute (ANSI). These standardized curves are given names and are referred to as named curves. Despite being called named curves, they actually define an elliptic curve group. An elliptic curve group is defined by an operation that can be applied to points on an elliptic curve, referred to as point addition, together with a set of points on the curve. This set of points is defined such that, given a point on the elliptic curve (i.e., a generator point), all points in the set can be obtained by successive application of the point addition operation to the base point. The elliptic curve group includes the point at infinity which is the additive identity of the group. The number of points in the elliptic curve group is called the order. An example named curve is P256, which is defined in NIST's Digital Signature Standard issued on Jan. 27, 2000 as FIPS 186-2, the contents and teachings of which are hereby incorporated by reference in their entirety. Other examples of named curves include B283, K283, B409, K409, P384, B571, K571, and P521. EC cryptography (ECC) scalar multiplication is the multiplication of a point on the elliptic curve by a scalar according to well-known procedures.

Returning back to optional step108, an example pre-selected EC might be, for example, P384. Any random point on the specific EC can be chosen as the base point, Z.

It should be understood that, in some embodiments, step108is not performed on-the-fly. Rather, in some embodiments, base point, Z, may be pre-selected according to the same criteria.

In step110, KSM70of first server34(a) computes a one-way function h(p, Q) of a private key, a, (stored as private key82in data area76) uniquely associated with the first server34(a), and Z yielding a first public key, A, to be stored as public key84in data area76, public key A being uniquely associated with the first server34(a), as the result of this one-way function. Step110, although depicted as being performed prior to the next step120, in some embodiments, actually may be performed in parallel or subsequent to that step. In any case, step110is performed prior to step150.

It should be understood that in the EC DH embodiment, one-way function h(p, Q) represents ECC scalar multiplication of scalar value p with point Q on an EC, typically depicted as p×Q, or pQ for short. If P384 is being used, private key82is then typically a 384-bit integer. It should be understood that, although ECC scalar multiplication has not been proven to be a strict one-way function, it is typically assumed in the field of cryptography that it is, and that assumption will be made for the purposes of this Description, there being no known general solution to the EC discrete logarithm problem.

Therefore, in the EC DH embodiment, in step110, KSM70of first server34(a) computes A=a×Q, storing the calculated public key A as public key84in data area76.

It should be understood that in servers34other than first server34(a), private key82and public key84in data area76do not store private key a and public key A, respectively, but rather, they store a local private and a local public key. For example, last server34(f) stores a last private key f as private key82in data area76and a last public key F (computed as f×Z) as public key84in data area76. Last private key f and last public key F are uniquely associated with last server34(f). While last private key f is kept a secret from the other servers34and other external entities, public key F is not a secret, and, in fact, as will be seen later, it is shared with first server34(a). The various intermediate servers34(b-e) also each locally store a unique local private key82and local public key84, keeping the local private key82secret, and sharing the local public key84with the next server on ordered list44, as will be described in further detail below.

In step120, KSM70of first server34(a) broadcasts a signal40to the network, the signal40requesting all servers34(b-f) (excluding the first server34(a)) to respond with identifying information. In one embodiment, first server34(a) will be a new VM server joining a cluster. Upon first booting up and joining the cluster, KSM70of first server34(a) initiates step120to initiate a new key agreement process to create a new key for the cluster.

In step125, KSM70of each of the remaining servers34(b-f) sends identifying information to the first server34(a) within response messages42(b-f). Each response message42includes information such as the network address (e.g., an IP address or a MAC address) of the server34that send that response message42. Other identifying information may also be included, such as a server name, etc.

In step130, KSM70of first server34(a) receives the response messages42from all the servers remaining servers34(b-f). Typically, upon receiving each response message, it is time-stamped with a time of receipt or a time of sending.

In step140, KSM70of first server34(a) creates ordered list44on-the-fly and stores it in data area76. The ordered list includes identifying information (e.g., IP address) from each of the servers34(a-f) in order. The identifying information of first server34(a) is listed first, followed by the identifying information of the remaining servers34(b-f) in some order. In one embodiment, KSM70of first server34(a) orders the identifying information of the remaining servers34(b-f) within ordered list44based on the timestamps of receipt time. In another embodiment, KSM70of first server34(a) orders the identifying information of the remaining servers34(b-f) within ordered list44based on the timestamps of sending time. In yet another embodiment, KSM70of first server34(a) orders the identifying information of the remaining servers34(b-f) within ordered list44in a random order. In any case, for the purposes of this Description, it is assumed that the order of the identifying information of the servers34in the ordered list is in the alphabetical arrangement depicted (i.e.,34(a),34(b),34(c),34(d),34(e),34(f)). In order to ensure that all of the remaining servers34(b-f) have had a chance to respond to the broadcast signal40of step120, a set period of time (e.g., 10 seconds) after sending the signal40in step120, KSM70of first server34(a) assumes that all of the other servers34(b-f) have had a chance to respond and it stores the ordered list44in data area76and proceeds to step150.

In step150, KSM70of first server34(a) sends first-round message50-1to second server34(b), as indicated by the second line of the ordered list44. First-round message50-1includes the ordered list44and the first public key A. In embodiments in which base point Z has been generated on-the-fly in step108, base point Z is also included within first-round message50-1. In embodiments in which base point Z is pre-selected, base point Z may be omitted from first-round message50-1as well as all other first-round messages50if all servers34are pre-configured with the value of base point Z stored as base point80within their respective data areas76.

In step154, KSM70of each intermediate server34(b-e) receives and transmits a first-round message50in a circular arrangement indicated by ordered list44. Thus, in the arrangement depicted inFIG. 1, KSM70of second server34(a) receives first-round message50-1from first server34(a), stores various values, performs various calculations, and then sends first-round message50-2to third server34(c). KSM70of third server34(c) similarly receives first-round message50-2from second server34(b), stores various values, performs various calculations, and then sends first-round message50-3to fourth server34(d). Eventually, KSM70of final intermediate server34(e) receives first-round message50-4, stores various values, performs various calculations, and then sends first-round message50-5to last server34(e). The contents of the various first-round messages50according to the example ofFIG. 1are shown in the first five data rows of Table 1. Each first-round message50includes the ordered list44, (optionally) base point Z, and a set of one-way function results.

In detail, when KSM70of any intermediate server34(b-e) receives a first-round message50, KSM70of that intermediate server34(b-e) stores the ordered list44in data area76, stores base point Z80in data area76(if applicable), and stores the received set of one way function results86in data area76. KSM70of that intermediate server34(b-e) also computes local public key84by applying the one-way function (e.g., ECC scalar multiplication) to the local private key82and the received base element Z80(e.g., for second server34(b), local public key B=b×Z, where b is the local private key82). The local private key82is also ECC scalar multiplied by all elements88of the received set of one-way function results86to create a set of intermediate one-way function results, which are then combined with the local public key84to form a set of new one-way function results94which may then be included within the first-round message50sent to the next server34(b-f), as indicated by the ordered list44, together with the ordered list44and, optionally, the base point Z.

In step156, KSM70of final server34(f) receives final first-round message50-5from final intermediate server34(e), stores various values, performs various calculations, and then sends second-round message52-1to first server34(a), based on the first line of the ordered list44. The contents of second-round message52-1according to the example ofFIG. 1are shown in the sixth data row of Table 1. Second-round messages52differ from first-round messages50in that they no longer contain the ordered list44and the base point Z, and the set of one-way function results contained contains the results of scalar multiplication of the local private key82with all elements88of the received one-way function results86except for the last element.

In detail, when KSM70of last server34(f) receives first-round message50-5, KSM70of the last server34(f) stores the ordered list44in data area76, stores base point Z80in data area76(if applicable), and stores the received set of one way function results86in data area76. The KSM70of the last server34(f) also computes local public key84by applying the one-way function (e.g., ECC scalar multiplication) to the local private key, f,82and the received base element Z80(e.g., local public key F=f×Z). The local private key82is also ECC scalar multiplied by all elements88of the received set of one-way function results86except for the last element88(e.g., edcbA) of that set86to create a set of intermediate one-way function results, which are then combined with the local public key, F,84to form a set of new one-way function results94which may then be included within the second-round message52-1sent to the first server34(a), as indicated by the ordered list44, together with the ordered list44and, optionally, the base point Z. The excluded last element88(e.g., edcbA) of the received set of one-way function results86is ECC scalar multiplied by the private key, f,82and stored as shared secret, S,90(e.g., S=fedcbA). KSM70of last server34(f) derives and stores encryption key, K,92from shared secret S. In some embodiments, this derivation is performed by taking a particular coordinate value from the EC point S, while in other embodiments, a more complicated transformation is applied to S.

In step160, KSM70of first server34(a) receives second-round message52-1from last server34(f) and stores various values in data area76. In detail, when KSM70of first server34(a) receives second-round message52-1, KSM70of the first server34(a) stores the received set of one way function results86in data area76. As depicted inFIG. 3, the example received set of one way function results86includes elements88(1-5), or (F, fE, feD, fedC, fedcB). It should be understood that the specific elements88illustrated inFIG. 3specifically represent the elements stored in first server34(a) in step160in the example ofFIG. 1and not the elements stored within the received set of one way function results86of any of the other servers34(b-f).

In step170, KSM70of first server34(a) computes and stored shared secret, S,90by applying the one-way function to the first private key, a,82and the last element88(5) of the received set of one way function results86(e.g., S=afedcB). It should be noted that last element88(5) is equal to the private keys of each of the servers, excluding the first server34(a), ECC scalar multiplied by the base point Q, and that the shared secret90is equal to the shared secret90calculated by the last server34(f) in step156, since, mathematically, fedcbA=(fedcb)×aQ=(afedcb)×Q=(afedc)×bQ=afedcB for ECC scalar multiplication.

In step180, KSM70of first server34(a) derives and stores encryption key, K,92from shared secret S in the same manner as was done by last server34(f), as described above in connection with step156.

In step172(which is labeled as optional because first server34(a) is able to determine shared secret S and encryption key K—which it can already use to communicate with last server34(f) at this point—prior to performing step172), KSM70of the first server34(a) calculates and stores a set of new one-way function results94by applying the one-way function to the first private key, a,82and the elements88(1-4) of the received set of one way function results86, excluding the last element88(5), storing the results as elements96(1-4), or (aF, afE, afeD, afedC). It should be understood that the specific elements96illustrated inFIG. 3specifically represent the elements stored in first server34(a) in step172in the example ofFIG. 1and not the elements stored within the new set of one way function results94of any of the other servers34(b-f). Step172may be performed in parallel with steps170and180, or before or after those steps.

In step174, the KSM70of the first server34(a) sends the second-round message52-2to the second server34(b), as indicated by the ordered list44. The contents of second-round message52-2according to the example ofFIG. 1are shown in the seventh data row of Table 1.

In step176, KSM70of each intermediate server34(b-e) receives and (except in the case of final intermediate server34(e)) transmits a second-round message52in the circular arrangement indicated by ordered list44. Thus, in the arrangement depicted inFIG. 1, KSM70of second server34(a) receives second-round message52-2from first server34(a), stores various values, performs various calculations, and then sends second-round message52-3to third server34(c). KSM70of third server34(c) similarly receives second-round message52-3from second server34(b), stores various values, performs various calculations, and then sends second-round message52-4to fourth server34(d). Eventually, KSM70of final intermediate server34(e) receives second-round message52-5, stores various values and performs various calculations. The contents of the various second-round messages52according to the example ofFIG. 1are shown in the last five data rows of Table 1. Each second-round message52includes a set of one-way function results.

In detail, when KSM70of any intermediate server34(b-e) receives a second-round message52, KSM70of that intermediate server34(b-e) stores the received set of one way function results86in data area76. In some embodiments, the previously-stored received set of one way function results86(from step154) may be deleted at this point. The local private key82is then ECC scalar multiplied by all elements88(e.g., in the case of second server34(b), {aF, afE, afeD}) of the received set of one-way function results86except for the last element88(e.g., in the case of second server34(b), afedC) of that set86to create a set of new one-way function results94which may then be included within the second-round message52sent to the next intermediate server34(b-e), if any, as indicated by the ordered list44. In some embodiments, the previously-stored set of new one-way function results94(from step154) may be deleted at this point. In the case of the final intermediate server34(e), since there are no more intermediate servers remaining on the ordered list44, execution stops without ever sending out a second-round message52. In any case, the excluded last element88(e.g., in the case of second server34(b), afedC) of the received set of one-way function results86is ECC scalar multiplied by the local private key,82and stored as shared secret, S,90(e.g., in the case of second server34(b), S=bafedC). KSM70of each intermediate server34(b-e) also derives and stores encryption key, K,92from shared secret S in the same manner as was done by last server34(f), as described above in connection with step156.

At this point, after execution of steps176and180has completed, the key agreement has been completed, and all servers34are in possession of shared secret S and encryption key K. Thus, encrypted communication module72of first server34(a) is able to, in optional step190, perform secured communication with another server34(b-f) of the set of servers across network32using encryption key, K,92. Similarly, any two servers34are able to perform secured communication with each other across network32using encryption key, K.

It should be understood that, although six servers34(a-f) are depicted inFIG. 1, and although four intermediate servers34(b-e) are depicted inFIG. 1, this is by way of example only. In fact, any number greater than two of servers34is suitable for use in various embodiments. As used in this Description, the character34(a) always refers to the first server, and the character34(f) always refers to the last server, while any positive integer number of intermediate servers34(b-e) is suitable.

Furthermore, it should be understood that although various embodiments have been described as being methods, software embodying these methods is also included. Thus, one embodiment includes a tangible computer-readable medium (such as, for example, a hard disk, a floppy disk, an optical disk, computer memory, flash memory, etc.) programmed with instructions, which, when performed by a computer or a set of computers, cause one or more of the methods described in various embodiments to be performed. Another embodiment includes a computer which is programmed to perform one or more of the methods described in various embodiments.

Furthermore, it should be understood that all embodiments which have been described may be combined in all possible combinations with each other, except to the extent that such combinations have been explicitly excluded.

Finally, nothing in this Specification shall be construed as an admission of any sort. Even if a technique, method, apparatus, or other concept is specifically labeled as “prior art,” “background,” or “conventional,” Applicants make no admission that such technique, method, apparatus, or other concept is actually prior art under 35 U.S.C. §102, such determination being a legal determination that depends upon many factors, not all of which are known to Applicants at this time. For example, Applicants make no admission that any technique, method, apparatus, or other concept labeled as “prior art,” “background,” or “conventional,” is not the work of the same inventive entity under 35 U.S.C. §102(a). As an additional example, Applicants make no admission that any technique, method, apparatus, or other concept labeled as “prior art,” “background,” or “conventional,” was patented or described in a printed publication in this or a foreign country or in public use or on sale in this country more than one year prior to the filing date of this Application under 35 U.S.C. §102(b). As an additional example, Applicants make no admission that any technique, method, apparatus, or other concept labeled as “prior art,” “background,” or “conventional,” was not owned by the same person or subject to an obligation of assignment to the same person as embodiments of the present Application at the time the embodiments were made under 35 U.S.C. §103(c).