System and method for migrating data between devices

CROSS-REFERENCE TO RELATED APPLICATION

The present application claims the benefit of U.S. Provisional Application No. 62/171,960, entitled SYSTEM AND METHOD FOR MIGRATING DATA BETWEEN DEVICES,” filed Jun. 5, 2015, the content of which is incorporated herein by reference in its entirety for all purposes.

FIELD

The described embodiments set forth a technique for migrating data between devices over a private wireless network.

BACKGROUND

When a user purchases a new device, the user generally desires to transfer data from his or her old device to the new device. Utilizing a third-party service to transfer the data between the devices can lead to privacy and content ownership issues. Moreover, the data transfer via the third-party service may not be performed in a secure manner. Furthermore, all data relevant to the user may not be transferred seamlessly between the devices, which can degrade the user's overall satisfaction with the process. Consequently, there is a need for a system that is capable of seamlessly migrating data between the devices in a secure manner.

SUMMARY

Representative embodiments set forth herein disclose various techniques for migrating data between a first device and a second device that are owned by a user. In particular, the embodiments set forth various techniques for migrating data between the first and second devices via a private wireless network hosted by the first device. During a setup of the first device, the first device receives a request to migrate data from the second device. In response to the request, the first device generates a code that is used to establish the private wireless network. In turn, a connection is established between the first and second device via the private wireless network and the data is migrated from the second device to the first device over the private wireless network. In this manner, the data can be securely exchanged directly between the first and second devices without requiring a third-party service.

This Summary is provided merely for purposes of summarizing some example embodiments so as to provide a basic understanding of some aspects of the subject matter described herein. Accordingly, it will be appreciated that the above-described features are merely examples and should not be construed to narrow the scope or spirit of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following Detailed Description, Figures, and Claims.

Other aspects and advantages of the embodiments described herein will become apparent from the following detailed description taken in conjunction with the accompanying drawings that illustrate, by way of example, the principles of the described embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

The included drawings are for illustrative purposes and serve only to provide examples of possible structures and arrangements for the disclosed inventive apparatuses and methods for providing wireless computing devices. These drawings in no way limit any changes in form and detail that may be made to the embodiments by one skilled in the art without departing from the spirit and scope of the embodiments. The embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings, wherein like reference numerals designate like structural elements.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a block diagram of different components of a system configured to implement the various techniques described herein, according to some embodiments.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a sequence diagram of a method for enabling data migration between the first device and the second device of <figref idref="DRAWINGS">FIG. 1</figref>, according to some embodiments.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates a conceptual diagram of an example sequence that involves enabling a user to request data to be migrated from the second device of <figref idref="DRAWINGS">FIG. 1</figref>, according to one embodiment.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a method that is carried out by the first device of <figref idref="DRAWINGS">FIG. 1</figref>, according to one embodiment.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates a method that is carried out by a migration application executing at the second device of <figref idref="DRAWINGS">FIG. 1</figref>, according to one embodiment.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a detailed view of a computing device that can be used to implement the various components described herein, according to some embodiments.

DETAILED DESCRIPTION

Representative applications of apparatuses and methods according to the presently described embodiments are provided in this section. These examples are being provided solely to add context and aid in the understanding of the described embodiments. It will thus be apparent to one skilled in the art that the presently described embodiments can be practiced without some or all of these specific details. In other instances, well known process steps have not been described in detail in order to avoid unnecessarily obscuring the presently described embodiments. Other applications are possible, such that the following examples should not be taken as limiting.

The embodiments described herein set forth techniques for enabling data migration between a first device running a first operating system and a second device running a second operating system that is different from the first operating system. According to some embodiments, the data migration is carried out over a private wireless network hosted by the first device. The wireless network parameters associated with the private wireless network are derived from a code generated at the first device. When a connection is established between the first and second devices via the private wireless network, the data from the second device can be migrated to the first device.

Accordingly, the techniques described herein provide a mechanism for migrating data between the first and second devices that are owned by a user in a secure manner over the private wireless network. A more detailed discussion of these techniques is set forth below and described in conjunction with <figref idref="DRAWINGS">FIGS. 1-6</figref>, which illustrate detailed diagrams of systems and methods that can be used to implement these techniques.

<figref idref="DRAWINGS">FIG. 1</figref> illustrates a block diagram of different components of a system <b>100</b> that is configured to implement the various techniques described herein, according to some embodiments. More specifically, <figref idref="DRAWINGS">FIG. 1</figref> illustrates a high-level overview of the system <b>100</b>, which, as shown, includes a first device <b>110</b> and a second device <b>120</b>. In most cases, each of the first device <b>110</b> and the second device <b>120</b> are owned by a same user, but the embodiments set forth herein are not limited to such a scenario. The first device <b>110</b> can represent a mobile computing device (e.g., an iPhone®, an iPad®, or other any other mobile computing device by Apple®) running a first operating system (e.g., a mobile operating system (iOS) by Apple®). The second device <b>120</b> can represent a mobile computing device (e.g., a smartphone, a tablet computing device, or any other mobile computing device) running a second operating system (e.g., a mobile operating system (Android™) by Google). The second device <b>120</b> can represent a device that supports Application Programming Interfaces (APIs) for gathering data, is capable of connecting to a wireless network, and is capable of running applications provided by a manufacturer of the first device <b>110</b> (e.g., Apple®). The first device <b>110</b> and the second device <b>120</b> are configured to communicate via a wireless network <b>102</b> that is hosted by the first device <b>110</b>. The wireless network <b>102</b> can include a Wi-Fi network, a Bluetooth network, a Bluetooth low energy (BT LE) network, or other wireless networks, as would be appreciated.

Although not illustrated in <figref idref="DRAWINGS">FIG. 1</figref>, the processor <b>112</b>, in conjunction with the memory <b>114</b>, can implement the first operating system (OS) that is configured to execute various applications (e.g., native OS applications and user applications) on the first device <b>110</b>. Similarly, the processor <b>122</b>, in conjunction with the memory <b>124</b>, can implement the second OS that is configured to execute various applications (e.g., native OS applications and user applications) on the second device <b>120</b>.

According to some embodiments, the first device <b>110</b> represents a new device that is recently purchased or recently acquired by the user and the second device <b>120</b> represents a device that the user owns and has been operating over time. The user typically desires to transfer/migrate data (e.g., personal and/or irreplaceable data) from the old device to the new device such that the transition from the old device to the new device is seamless for the user. The data can include, for example, contact information, calendar information, message history, mail, bookmarks, wallpaper settings, information regarding installed applications, pictures/photos, songs, movies, books, and so on.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates a sequence diagram of a method <b>200</b> for enabling data migration between the first device <b>110</b> and the second device <b>120</b>, according to some embodiments. As shown in <figref idref="DRAWINGS">FIG. 2</figref>, at step <b>202</b>, the first device <b>110</b> receives a request to migrate data from the second device <b>120</b>. In some embodiments, the request is received during a setup phase of the first device <b>110</b> (e.g., when the newly acquired first device <b>110</b> is being set up). In some implementations, the user is presented with various options for setting up the first device <b>110</b>. The user is presented with a user interface (UI) at the first device that enables the user to select how the first device <b>110</b> is to be set up. For example, the options can include: 1) set up as a new device, 2) set up by restoring from backup, 3) set up by restoring from a media library (e.g., iTunes® by Apple®), or 4) set up by migrating from the second device <b>120</b>. When the user selects the fourth option of “migrating from the second device <b>120</b> to the first device <b>110</b>”, the user is presented with a setup screen <b>302</b> (as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>) in the UI. The setup screen <b>302</b> acknowledges the selection of the user and presents text/instructions explaining operations to be carried out at the second device <b>120</b>. When the user selects the “next” button <b>306</b> on the setup screen <b>302</b>, the user is presented with a setup screen <b>304</b> (as illustrated in <figref idref="DRAWINGS">FIG. 3</figref>).

Referring back to <figref idref="DRAWINGS">FIG. 2</figref>, at step <b>204</b>, the first device <b>110</b> generates a code that is utilized to establish a secure private wireless network that is local to and hosted by the first device <b>110</b>. The code can include a numeric code or any other code that can be securely shared between the first device <b>110</b> and the second device <b>120</b>. For example, the first device <b>110</b> can generate a five or a six digit pairing PIN as the code. The code is presented at the setup screen <b>304</b> (as shown in <figref idref="DRAWINGS">FIG. 3</figref>) where the user is instructed to enter the generated code at the second device <b>120</b>. As will be appreciated, other forms of codes and/or pairing information (e.g., QR codes, barcodes, pairing images, etc.) can be generated by the first device <b>110</b> for purposes of establishing the secure private wireless network. For example, the first device <b>110</b> can generate a QR code that is presented at the setup screen <b>304</b> where the user can be instructed to scan the QR code at the second device <b>120</b>.

The first device <b>110</b> establishes the private wireless network, at step <b>206</b>. In some embodiments, the first device <b>110</b> disconnects any existing wireless network connections prior to establishing the private wireless network. In some embodiments, the first device <b>110</b> serves as a wireless access point and functions as a hotspot such that the private wireless network hosted by the first device <b>110</b> can be utilized for data exchange between the first device <b>110</b> and the second device <b>120</b>. The first device <b>110</b> derives, based on the code, a number of wireless network parameters associated with the private wireless network. The wireless network parameters can include a network name (also referred to as a service set identifier (SSID)) and pre-shared key(s) (or other shared secret) used for encryption purposes. In some embodiments, the first device <b>110</b> initiates a number of services associated with the private wireless network. For example, the services can include Dynamic Host Configuration Protocol (DHCP) for Internet Protocol (IP) address allocation, multicast Domain Name System (mDNS) for discovery of the first device <b>110</b> and the second device <b>120</b>, and/or other services.

According to some embodiments, the generation of the code is triggered in response to the selection of the “next” button <b>306</b> on the setup screen <b>302</b>, as shown in <figref idref="DRAWINGS">FIG. 3</figref>. In some embodiments, when the user selects the “next” button <b>306</b>, the first device <b>110</b> performs a number of operations, including: 1) generating the code, 2) presenting the code at setup screen <b>304</b>, <b>3</b>) establishing the private wireless network, 4) deriving the network name and pre-shared key(s), and 5) initiating the services associated with the private wireless network. At this point, the first device <b>110</b> and the second device <b>120</b> are not in communication with one another.

Referring to <figref idref="DRAWINGS">FIG. 3</figref>, the setup screen <b>302</b> displays instructions explaining the operations to be carried out by the user at the second device <b>120</b>. Thus, during the setup phase, the user is also instructed to carry out a number of operations at the second device <b>120</b>, where the operations can include: 1) go to an application store (e.g., Google Play Store or other app store), 2) download a migration application that facilitates the migration of data between the first device <b>110</b> and the second device <b>120</b>, and 3) run the migration application. In some embodiments, the migration application comprises an application provided by the manufacturer of the first device <b>110</b> (e.g., Apple®).

Referring back to <figref idref="DRAWINGS">FIG. 2</figref>, at step <b>208</b>, the migration application is downloaded at the second device <b>120</b>. When the migration application is executing at the second device <b>120</b>, the migration application presents a UI at the second device <b>120</b> requesting the user to input the code being displayed at the setup screen <b>304</b> of the first device <b>110</b>. At step <b>210</b>, the migration application at the second device <b>120</b> receives the code entered by the user. At step <b>212</b>, the migration application at the second device <b>120</b> also derives the wireless network parameters (e.g., the network name and pre-shared key(s)) of the private wireless network hosted by the first device <b>110</b> based on the code.

When the migration application derives the wireless network parameters, the migration application at the second device <b>120</b> automatically connects to the private wireless network hosted by the first device <b>110</b>. In other words, at step <b>214</b>, a connection is established between the first device <b>110</b> and the second device <b>120</b> via the private wireless network hosted by the first device <b>110</b>. When the first device <b>110</b> and the second device <b>120</b> are on the private wireless network (i.e., are directly connected to one another via the private wireless network), they perform discovery and handshake procedures and exchange a series of keys and certificates (that offer an additional layer of security at transport layer) to ensure that any communication over the private wireless network will be performed in a secure manner. In some embodiments, during the handshake procedures, the first device <b>110</b> and the second device <b>120</b> can exchange basic information regarding capabilities of the devices (e.g., wireless protocol(s) supported, hardware features, information transfer rate, types of data (e.g., photos, videos, and the like) supported, etc.). Moreover, the first device <b>110</b> and the second device <b>120</b> can negotiate an appropriate wireless protocol to be used for the data migration process based on the exchange.

At this point, the first device <b>110</b> and the second device <b>120</b> are able to communicate with one another over the private wireless network. According to some embodiments, the second device <b>120</b> can act as a web service (e.g., a RESTful web service, HTTPS web service) that can respond to queries made by the first device <b>110</b>.

At step <b>216</b>, a migration phase is initiated where the first device <b>110</b> receives a summary of data from the second device <b>120</b> over the private wireless network. In some embodiments, the first device <b>110</b> queries the second device <b>120</b> for the summary of data that is available on the second device <b>120</b>. In some implementations, the summary of data includes a subset of available data on the second device <b>120</b>. For example, the subset of available data can include address book data, calendar data, and/or other data that is known to be compatible with the first device <b>110</b>. The summary of data is received at the first device <b>110</b> where determinations are made regarding whether the first device <b>110</b> has enough space to store all the data and an amount of time required to perform the migration of the data from the second device <b>120</b>. In some implementations, in response to a determination that the first device <b>110</b> does not have enough space to store all the data from the second device <b>120</b>, the first device <b>110</b> can trigger the second device <b>120</b> to present a UI (via the migration application) for selection of particular types of data that the user desires to migrate. For example, the UI can present various options (e.g., songs, photos, videos, etc.) from which the user can make a selection. In this manner, when all the data from the second device <b>120</b> cannot be migrated to the first device <b>110</b>, the user is provided with an option to choose the types of data to be migrated.

At step <b>218</b>, the first device <b>110</b> receives data records associated with the summary of data over the private wireless network. In other words, user data associated with the summary of data is migrated from the second device <b>120</b>. When the data records are received at the first device <b>110</b>, the wireless connection between the first device <b>110</b> and the second device <b>120</b> can be disconnected, at step <b>220</b>. At this point, the second device <b>120</b> can be powered off.

In some embodiments, the data records received from the second device <b>120</b> are imported at the first device <b>110</b>. In other words, the data records are imported and written to a database at the first device <b>110</b>. For example, the data records are analyzed and particular categories of data records (e.g., pictures, movies, songs, etc.) are imported into appropriate folders on the first device <b>110</b>. In some embodiments, the migration of data records and synchronization of the database is an atomic process, i.e., when confirmation is obtained that a data record has been imported, any updates to the data record can be performed.

According to some embodiments, when the data records have been imported, a post-migration phase is initiated at the first device <b>110</b> where a number of post-migration operations can be performed. The post-migration operations can include account setup, matching of free applications, creating a wish list of applications, and/or other operations. During the account setup operation, any user settings or personalization (e.g., mail, contacts, calendar, wallpaper, etc.) identified from data received from the second device <b>120</b> are applied at the first device <b>110</b>. Also, when a determination is made that the user had a particular account (e.g., a mail account, a chat service account, etc.) at the second device <b>120</b>, the parameters associated with the account (e.g., account ID) are pre-configured at the first device <b>110</b>. Thus, the account is already set up for the user at the first device <b>110</b> and the user is simply prompted to enter his or her credentials (e.g., password) when the user tries to access/log in the account at the first device <b>110</b>. Hence, the account setup operations described herein offer a seamless experience to the user as they obviate the need for the user to have to individually re-create accounts at the first device <b>110</b> that already are functional on the second device <b>120</b>. Notably, situations can potentially occur where data records are received at the first device <b>110</b> and are uninterpretable by the first device <b>110</b>. This can occur, for example, when certain data records that are understood by the second device <b>120</b> (but not by the first device <b>110</b>) are mistakenly gathered from the second device <b>120</b> and included in the data records that are sent to the first device <b>110</b> for processing. Accordingly, to avoid situations where the first device <b>110</b> undergoes a failure when encountering such uninterpretable data records, the first device <b>110</b> can be configured to implement exception handlers that cause the first device <b>110</b> to (1) cease processing an uninterpretable data record, and (2) take a corrective course of action. A corrective course of action can include, for example, ignoring the uninterpretable data record and moving on to a next data record, attempting to identify and process the uninterpretable data record using auxiliary processing techniques, and the like. According to some embodiments, the first device <b>110</b> can be configured to maintain a record of the uninterpretable data records that are processed so that they can be presented to a user of the first device <b>110</b> during the migration or upon a completion of the migration. In this manner, the user of the first device <b>110</b> can review the uninterpretable data records and make his or her own decisions about migrating those records to the first device <b>110</b> (e.g., using manual techniques).

According to some embodiments, the user is provided at the first device <b>110</b> with an option to download matching applications (i.e., applications that match installed applications on the second device <b>120</b>) from an application store (e.g., App store by Apple®) at the first device <b>110</b>. This can be based on, for example, information associated with the applications installed on the second device <b>120</b> (e.g., names of applications, developer names, etc.). When the user launches the application store at the first device <b>110</b>, the user is provided with a recommendation to download free matching applications from the application store. Also, a wish list of applications can be created for the user at the first device <b>110</b>, where the wish list contains a list of paid applications that the user might be interested in or that the user had installed on the second device <b>120</b>.

According to some embodiments, the data migration process between the first device <b>110</b> and the second device <b>120</b> is fault-tolerant. In other words, if the network connection is lost or one of the devices loses power (due to reboot or other reasons), the data migration process is only temporarily interrupted and can be resumed as soon as the network connection or device power is restored. In some implementations, the status of the data migration process is maintained at the first device <b>110</b>. The first device <b>110</b> keeps record of a particular state in the data migration process. The particular state can include information regarding the operation (e.g., transfer of summary of data, transfer of data records, etc.) that was being performed when the connection/device power was lost, an amount of data (e.g., bytes of data, a number of records) that was migrated or imported prior to losing the connection/device power, and the like. In some embodiments, the data migration can be stopped and resumed as desired without affecting the consistency of the migration process.

In some embodiments, the first device <b>110</b> and the second device <b>120</b> are usable while the data migration process is being carried out. Also, because the data migration occurs over the private wireless network hosted by the first device <b>110</b> and is not dependent on the external network environment the devices are in, the devices can continue the data migration (so long as the connection between the devices remains intact). For example, if a user takes the two devices to a retail store where the data migration process over the private wireless network is started, the user can walk out of the retail store with the two devices without interrupting the data migration process as the process does not rely on any third-party network (e.g., retail store network).

In some embodiments, when an existing connection between the first device <b>110</b> and the second device <b>120</b> is disconnected during the data migration process and the user attempts to restart the data migration process, a different private wireless network can be established based on a new code generated at the first device <b>110</b>. The second device <b>120</b> can derive the wireless network parameters associated with the different private wireless network and establish a new connection. When the first device <b>110</b> and the second device <b>120</b> discover one another, they are able to identify one another (e.g., based on unique identifiers), and the data migration process can be resumed from the point where the existing connection was disconnected.

<figref idref="DRAWINGS">FIG. 4</figref> illustrates a method <b>400</b> that is carried out by the first device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>, according to one embodiment. As shown, the method <b>400</b> begins at step <b>402</b>, where the first device <b>110</b> receives a request to migrate data from the second device <b>120</b> during the setup phase of the first device <b>110</b>. In response to the request, the first device <b>110</b> generates a code, at step <b>404</b>. At step <b>406</b>, the code is utilized to establish a private wireless network that is hosted by the first device <b>110</b>. The first device <b>110</b> derives wireless network parameters associated with the private wireless network.

At step <b>408</b>, a connection is established with the second device <b>120</b> via the private wireless network. In some embodiments, when the migration application at the second device <b>120</b> also derives the wireless network parameters based on the code, the connection between the first device <b>110</b> and second device <b>120</b> is automatically established via the private wireless network.

At step <b>410</b>, the first device <b>110</b> queries the second device <b>120</b> for the data to migrated to the first device <b>110</b>. At step <b>412</b>, the first device <b>110</b> receives the data records from the second device <b>120</b>. In some embodiments, the first device <b>110</b> receives a summary of data that is available on the second device <b>120</b>. When the summary of data is collected, the data records containing actual user data are received from the second device <b>120</b>.

<figref idref="DRAWINGS">FIG. 5</figref> illustrates a method <b>500</b> carried out by the migration application executing at the second device <b>120</b> of <figref idref="DRAWINGS">FIG. 1</figref>, according to one embodiment. As shown, the method <b>500</b> begins at step <b>502</b>, where the migration application is downloaded to the second device <b>120</b>. When executed at the second device <b>120</b>, the migration application presents a UI that requests the user to enter the code. At step <b>504</b>, the migration application receives the code entered by the user via the UI. At step <b>506</b>, the migration application derives, based on the code, the wireless network parameters associated with the private wireless network hosted by the first device <b>110</b>.

When the wireless network parameters are derived, the migration application establishes a connection with the first device <b>110</b> via the private wireless network, at step <b>508</b>. At step <b>510</b>, the migration application responds to any queries/requests for data made by the first device <b>110</b>. In particular, the summary of data and the data records at the second device <b>120</b> are provided to the first device <b>110</b> based on the requests.

<figref idref="DRAWINGS">FIG. 6</figref> illustrates a detailed view of a computing device <b>600</b> that can be used to implement the various components described herein, according to some embodiments. In particular, the detailed view illustrates various components that can be included in the first device <b>110</b> or second device <b>120</b> illustrated in <figref idref="DRAWINGS">FIG. 1</figref>. As shown in <figref idref="DRAWINGS">FIG. 6</figref>, the computing device <b>600</b> can include a processor <b>602</b> that represents a microprocessor or controller for controlling the overall operation of computing device <b>600</b>. The computing device <b>600</b> can also include a user input device <b>608</b> that allows a user of the computing device <b>600</b> to interact with the computing device <b>600</b>. For example, the user input device <b>608</b> can take a variety of forms, such as a button, keypad, dial, touch screen, audio input interface, visual/image capture input interface, input in the form of sensor data, etc. Still further, the computing device <b>600</b> can include a display <b>610</b> (screen display) that can be controlled by the processor <b>602</b> to display information to the user (for example, email interface described herein). A data bus <b>616</b> can facilitate data transfer between at least a storage device <b>640</b>, the processor <b>602</b>, and a controller <b>613</b>. The controller <b>613</b> can be used to interface with and control different equipment through and equipment control bus <b>614</b>. The computing device <b>600</b> can also include a network/bus interface <b>611</b> that couples to a data link <b>612</b>. In the case of a wireless connection, the network/bus interface <b>611</b> can include a wireless transceiver.

The computing device <b>600</b> also include a storage device <b>640</b>, which can comprise a single disk or a plurality of disks (e.g., hard drives), and includes a storage management module that manages one or more partitions within the storage device <b>640</b>. In some embodiments, storage device <b>640</b> can include flash memory, semiconductor (solid state) memory or the like. The computing device <b>600</b> can also include a Random Access Memory (RAM) <b>620</b> and a Read-Only Memory (ROM) <b>622</b>. The ROM <b>622</b> can store programs, utilities or processes to be executed in a non-volatile manner. The RAM <b>620</b> can provide volatile data storage, and stores instructions related to the operation of the computing device <b>600</b>.

The various aspects, embodiments, implementations or features of the described embodiments can be used separately or in any combination. Various aspects of the described embodiments can be implemented by software, hardware or a combination of hardware and software. The described embodiments can also be embodied as computer readable code on a computer readable medium. The computer readable medium is any data storage device that can store data that can thereafter be read by a computer system. Examples of the computer readable medium include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, hard disk drives, solid state drives, and optical data storage devices. The computer readable medium can also be distributed over network-coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

The foregoing description, for purposes of explanation, used specific nomenclature to provide a thorough understanding of the described embodiments. However, it will be apparent to one skilled in the art that the specific details are not required in order to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to one of ordinary skill in the art that many modifications and variations are possible in view of the above teachings.