Abstract:
A device streams assets to network-based storage, and servers administering the network-based storage operate to notify other authorized devices that the assets are available to download, including initiating the download of assets automatically or in response to user input. With streaming enabled on their device, a user is able to make assets, such as digital photograph, video or other type of media file, data file, or other type of electronic content, available immediately to all of their other devices and to other users having permission to follow assets streamed by their device. Servers secure access to the stream of assets, on both an account level and an asset level in accordance with asset metadata registered for the assets during streaming.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
       [0001]    This application claims the benefit of an earlier filed provisional application, Application Ser. No. 61/493,491 filed on Jun. 5, 2011, entitled ASSET STREAMING. 
     
    
     TECHNICAL FIELD 
       [0002]    The technical field relates generally to the distribution of electronic content. 
       SUMMARY OF THE DESCRIPTION 
       [0003]    Methods, machine readable tangible storage media, and data processing systems that enable distribution of content across devices are described. In the description that follows, a data processing system or mobile computing device are collectively referred to as a device, and content for the device, which may be a digital photograph, video or other type of media file, data file, or other type of electronic content, is referred to as an asset. 
         [0004]    In one embodiment, a device having an account permitting access to network-based storage, also termed cloud storage, streams assets to the network-based storage, and servers administering the network-based storage operate to notify other authorized devices that the assets are available to download, including initiating the download of assets automatically or in response to user input. Servers administering the network-based storage of assets further control the streaming of assets from and to devices, including securing access to the stream of assets, on both an account level and an asset level. 
         [0005]    Other features of the present invention will be apparent from the accompanying drawings and from the detailed description that follows. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0006]    The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which: 
           [0007]      FIG. 1  is a block diagram overview illustrating one embodiment of network systems for asset streaming; 
           [0008]      FIG. 2  is a block diagram overview illustrating an exemplary system for asset uploading in accordance with one embodiment of network systems for asset streaming; 
           [0009]      FIG. 3  is a block diagram overview illustrating an exemplary system for asset downloading in accordance with one embodiment of network systems for asset streaming; 
           [0010]      FIG. 4  is a block diagram overview illustrating an exemplary system for asset following in accordance with one embodiment of network systems for asset streaming; 
           [0011]      FIGS. 5-8  are flow diagrams illustrating embodiments of a process to upload assets to network-based storage from a device; 
           [0012]      FIGS. 9-12  are flow diagrams illustrating embodiments of a process to download of assets from network-based storage to a device; 
           [0013]      FIG. 13-16  are exemplary screen snapshots from a device illustrating embodiments of user interfaces for use in devices supporting asset streaming; 
           [0014]      FIG. 17  illustrates an example of a typical computer system which may be used in conjunction with the embodiments described herein. 
       
    
    
     DETAILED DESCRIPTION 
       [0015]    Methods and apparatuses for enabling distribution of content across devices are described herein. In the following description, numerous specific details are set forth to provide thorough explanation of embodiments of the present invention. It will be apparent, however, to one skilled in the art, that embodiments of the present invention may be practiced without these specific details. In other instances, well-known components, structures, and techniques have not been shown in detail in order not to obscure the understanding of this description. 
         [0016]    Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification do not necessarily all refer to the same embodiment. 
         [0017]    The processes depicted in the figures that follow, are performed by processing logic that comprises hardware (e.g. circuitry, dedicated logic, etc.), software (such as is run on a general-purpose computer system or a dedicated machine), or a combination of both. Although the processes are described below in terms of some sequential operations, it should be appreciated that some of the operations described may be performed in different order. Moreover, some operations may be performed in parallel rather than sequentially. 
         [0018]    In one embodiment, devices generate assets that may be streamed, including capturing photos or videos with image capturing features on a mobile communications device, such as a cell phone, or other type of computing device, including an iOS® device, an iPhone® or iPad® device from Apple Inc. 
         [0019]    In one embodiment, the assets can be purchased from vendor stores in the cloud. For example, purchased assets, such as songs, movies, and/or applications etc., can be downloaded from iTunes® stores in the cloud. 
         [0020]    In one embodiment, network-based storage may be available for streaming assets to and from a device. For example, network-based storage may be offered in the cloud (or cloud storages, cloud services) via third party vendors such as Amazon, S3, Microsoft, etc., to user devices such as an iOS® device, an iPhone® or iPad® device from Apple Inc. 
         [0021]      FIG. 1  is a block diagram overview illustrating one embodiment of network systems for asset streaming according to one embodiment described herein. Networked systems for asset streaming  100  may include dynamically configured networks  109  connecting servers  101 ,  103 , 105 ,  107  and  113  and streaming-enabled devices  111 A and  111 B. For example, an asset uploading device  111 A, such as a phone device, may be sporadically connected with an assets server, such as the Mobile Me Cloud Service (MMCS) provided by Apple Inc., depending on where device  111 A is located. Device  111 A may intermittently be locally coupled or directly connected (e.g. via a wire) to another device  111 B, or an asset downloading device, which, for example, can be another mobile computing device or, more typically, a stationary device, such as a desktop computer capable of accessing mass storage devices, such as hard disks, solid state devices, flash memories or other storage services. 
         [0022]    In one embodiment, device  111 A captures or otherwise generates assets that may be streamed via network  109  to multiple recipients (e.g. servers, asset stores, storage services)  101 ,  103 ,  105 ,  107 ,  113  generally referred to as cloud storage or the cloud, and subsequently to other recipient devices  111 B. The recipients may be identified on the fly, and in some cases the recipients that are identified vary depending on the current location of the device  111 A from which the assets originated. 
         [0023]    In one embodiment, an account server  101 , such as the account server of the Mobile Me service offered by Apple Inc., maintains an account for the device  111 A that identifies, among other information, whether the device  111 A and other devices  111 B associated with the account are eligible to participate in asset streaming, including identifying whether other devices  111 B not normally associated with the account are currently following assets streamed by the device  111 A. 
         [0024]    In one embodiment, a streams server  105 , also referred to as a metadata server maintains information in the form of metadata about assets that are eligible for streaming. The streams server  105  operates in conjunction with the account server  101  to filter those assets that are eligible for streaming based on the asset metadata, account and other information associated with the devices  111  to and from which assets are streamed. The metadata may include information about assets for filtering which assets can be streamed or downloaded from the network-based storage service to other devices associated with the device, including a size of the asset, an image resolution of the asset when the asset is an image, a date of the acquired asset, and security information restricting access to the acquired asset, such as restricting access to certain other accounts or devices. 
         [0025]    In one embodiment, an assets server  103 , such as the assets server provided by the Mobile Me Cloud Service (MMCS) of Apple, Inc., maintains the assets themselves in conjunction with various storage services, such as the aforementioned asset store  107  and third party cloud backup service  113 . The assets can be broken into chunks of actual data (e.g. of certain size of asset bits) for cloud service(s) to store. Typically, multiple chunks may be aggregated into one container as a storage unit for the cloud service offered by, for example, third party vendors. The streamed asset may be created, updated, deleted, disabled or operated on as requested. For example, assets no longer being streamed due to time limits or discontinuation of the streaming service associated with the account may be deleted. 
         [0026]    Assets identified in a device  111 A,  111 B for streaming operations may be split into chunks of data bits ready for cloud storage. In one embodiment, MMCS code in a service framework of the device  111 A may communicate with an MMCS asset server  103  in the cloud  109  to prepare the chunks of data for streaming to other devices  111 B. For example, assets may be prepared for streaming by being split into multiple chunks of data according to certain chunk configurations (e.g. a specific size of data bits for each chunk). 
         [0027]    The network-based system for asset streaming  100  may determine which of multiple chunks of data prepared from assets being streamed are not currently available in the cloud and need to be uploaded. In some embodiments, the assets server  103  (e.g. via MMCS code) may hash each chunk into a signature, e.g. via SHA hashing algorithms or other applicable algorithms. The signature functions as an identifier for the MMCS server (or service)  103  to determine whether the identified chunk has already been streamed to the cloud  109 . 
         [0028]      FIG. 2  is a block diagram overview illustrating an exemplary system for asset uploading  200  in accordance with one embodiment of network systems for asset streaming  100 . In operation, the asset streaming device  111  is configured with an asset streaming plug-in  203  containing the logic/instructions for carrying out operations for asset streaming  100 , and stores an asset  205 , or an asset derivative, such as a version of the asset in a different resolution or format (e.g., a different resolution image or a differently formatted image). 
         [0029]    In one embodiment, the asset streaming device  111  sends an account authorization request  202  to account server  101  for account authorization to upload/stream assets, such as asset  205 . The account server  101  evaluates the account authorization request  202  and, if appropriate, authorizes the device  111  to stream assets for this account. In one embodiment, the account server  101  generates and sends to the device  111  an account authorization token  204 , and the device  111  receives the account token  204 . 
         [0030]    In one embodiment, upon receiving the account token  204 , the device  111  then sends an asset upload authorization request  206  to the streams server  105  to request permission to stream a particular asset, such as the asset  205 . The streams server  105  evaluates the asset upload authorization request  206  and, if appropriate, authorizes the device  111  to upload the asset  205  to network-based cloud storage, for example via network  109  and assets server  103  to asset store  107  and/or a third party storage server  113 . 
         [0031]    In one embodiment, to upload the asset  205  to network-based cloud storage, the streams server  105  generates and sends to the device  111  an asset authorization token  208 , and the device  111  receives the asset token  208 . Upon receiving the asset token, 208  the device  111  then uploads the asset  205  to an assets server  103 , which in turn stores the prepared chunks of data that make up the asset  205  on a storage server  107 / 113  or the like, in accordance with an asset data bits storage algorithm. 
         [0032]    In one embodiment, the account server  101  has a known address and can point any transactions generated to upload the asset  205  using different streams servers  105  and assets servers  103  in remote locations. 
         [0033]      FIG. 3  is a block diagram overview illustrating an exemplary system for asset downloading in accordance with one embodiment of network systems for asset streaming. In one embodiment, the account server  101  generates a push notification  302  that causes the other devices associated with the account to “wake up” and request a list of the new streamed assets, e.g., asset  205  that may be available for downloading. In one embodiment, the asset streaming device  111  receives the push notification  302 , and sends an asset download authorization request  304  for authorization to download a streamed asset that does not yet reside on the device  111 , such as asset  205 . The streams server  105  evaluates the asset download authorization request  304  and, if appropriate, authorizes the device  111  to download the asset  205  from network-based cloud storage. In one embodiment, the asset download authorization request  304  to download an asset includes a change tag or other information that indicates to the streams server  105  how to filter the assets, such as filtering out those assets that may have already been downloaded to the device  111 , or those assets having a certain image resolution or format. For example, the change tag may indicate that the device  111  is to receive only the lower resolution version of an image asset. 
         [0034]    In one embodiment, the streams server  105  generates and sends to the device  111  an asset download authorization token  306 , and the device  111  receives the asset download authorization token  306 . Upon receiving the asset download authorization token  306 , the device  111  then downloads  308  the asset  205  from the assets server  103 . As with the uploading of assets, in one embodiment, the account server  101  has a known address but can point any transactions generated to download the asset  205  to the device  111  using different streams servers  105  and assets servers  103  in remote locations. 
         [0035]      FIG. 4  is a block diagram overview illustrating an exemplary system for asset following  400  in accordance with one embodiment of network systems for asset streaming. In one embodiment, a user of a device  111  for which asset streaming is enabled, say device A  402 , invites (e.g. via email)  404  another user of a device  111 , say device B  406 , to follow A&#39;s asset streams. Upon receiving the invitation, user B  406  can decide whether to accept the invitation, and if she does, sends an acceptance  408  back to user A  402 . 
         [0036]    In one embodiment, user A  402  relays the acceptance  408  to the account server  101 , and requests to update  410  the account server  101  to send push notifications to user B&#39;s devices and not just A&#39;s devices associated with A&#39;s account. In one embodiment, user A can specify with particularity which asset or categories of assets that user A will allow to be downloaded by user B, and requests to update  412  the stream server  105  to filter which assets can be downloaded to user B in accordance with user A&#39;s specification. In one embodiment the filter request is typically based on the asset metadata associated with the asset and maintained on the streams server  105 . 
         [0037]      FIGS. 5-8  are flow diagrams illustrating embodiments of a process to upload assets to network-based storage from a device. As illustrated beginning with  FIG. 5 , during an asset upload process  500  a device  111  saves an asset at process block  502 , and the device determines at decision block  504  whether asset streaming is enabled for the device. If not, the process  500  terminates at block  520 . Otherwise, process  500  continues, and the device at process block  506  sends a request to the account server for authorization to upload/stream assets. At process  508 , the device receives an account authorization token from the account server that authorizes the device to stream assets. 
         [0038]    In one embodiment, at process block  510 , the device optionally generates derived assets, e.g. assets in different image resolutions (e.g. number of pixels) or using different formatting standards (e.g. RAW, JPEG), that may be streamed. At process block  512 , the device sends a request to the streams server to register metadata for the asset (and/or the derived asset) and requests authorization to upload the asset to the network-based storage. 
         [0039]    In one embodiment, at process block  514 , the device receives one or more asset upload authorization tokens corresponding to the assets that may be uploaded to the cloud. At process block  516 , the device uploads the assets to the assets server for storage and in preparation for subsequent downloading to other devices. At process block  518 , the device receives a notification form the assets server about whether the assets have been successfully uploaded. 
         [0040]    Turning now to  FIG. 6 , as illustrated, in upload process  600  at process block  602  an account server receives the request from the device requesting the account authorization to register and upload assets to the streams and asset servers in preparation for subsequent downloading to other devices from cloud storage. At decision block  604 , the account server evaluates whether the requester can be authenticated and the associated account validated and, if not, the process  600  terminates  610 . For authenticated and validated requests, the process  600  continues at process block  606  to generate an account authorization token and at process  608  to send the account authorization token back to the requesting device. 
         [0041]    Turning now to  FIG. 7 , as illustrated, in upload process  700  at process block  702 , a streams server receives a request from a device requesting authorization to register one or more assets. At decision block  704 , the streams server evaluates whether the requester has obtained a valid account authorization token and, if not, the process  700  terminates  710 . For validated requests, the process  700  continues at process block  706  to register asset metadata with the streams server and to generate an asset authorization token for each asset authorized for uploading. At process  708  the streams server sends the asset authorization token back to the requesting device. 
         [0042]    Turning now to  FIG. 8 , as illustrated, in upload process  800  at process block  802 , receives an asset upload request from a device to upload assets. At decision block  804 , the assets server determines whether the asset upload request is accompanied by a valid asset authorization token and, if not, processing terminates  810 . For validated asset upload requests, the process  800  continues at process block  806  in which the assets server uploads from the device the authorized assets, including any derived assets. The process  800  concludes at process block  808  in which the assets server sends an upload notification to the device confirming that the asset(s) were successfully uploaded to the assets server/cloud storage as requested. 
         [0043]      FIGS. 9-12  are flow diagrams illustrating embodiments of a process to download assets from network-based storage to a device. As illustrated, beginning with  FIG. 9 , during an asset download process  900  a device  111  receives an asset availability notification from an account server that assets are available to download from the assets servers/cloud storage. The process  900  continues at process block  904 , in which notified devices wake up and send a new assets list request to the streams server for a list of new assets available to download. In one embodiment, the notified devices send an account authorization request to the account server as described below with reference to  FIG. 10  before sending the new assets list request to the streams server. 
         [0044]    In one embodiment, the process  900  continues at process block  906 , in which a device, upon receiving the requested list of new assets available, sends an asset download authorization request to the streams server to obtain an asset authorization token for each asset to be downloaded. At process  908 , upon receiving the asset authorization token, the device sends a asset download request to the assets server to download authorized assets to the device. The process  900  concludes at process block  910 , in which the device receives the download of the authorized assets. 
         [0045]    Turning now to  FIG. 10 , an asset download process  1000  begins with process block  1002 , in which an account server sends the aforementioned asset availability notification to devices associated with an account (or to devices that have accepted an invitation to follow or have otherwise subscribed to the account&#39;s asset streams), the asset availability notification alerting the devices that assets are available to download from the assets servers. In one embodiment, the process  1000  optionally continues at process block  1004 , in which the account server receives an account authorization request from a notified device requesting an account authorization to download assets. At decision block  1006 , the account server determines whether the requester is authenticated and the account valid and, if not, terminates  1012 . The process  1000  continues at process block  1008 , in which the account server generates an account authorization token for authenticated requesters having valid accounts, and at process block  1010 , in which the account server sends the account authorization token to the requesting device as needed. In one embodiment, a notified device may already be authenticated at the account level and an account authorization token can be generated without having to re-authenticate the requester and the account, in which case the account authorization token may be transmitted to the device separately or as part of the asset availability notification described with reference to  FIG. 9 . 
         [0046]    Turning now to  FIG. 11 , an asset download process  1100  begins at process block  1102 , in which a streams server receives an asset authorization request from a device requesting authorization to download streamed assets for an account. At decision block  1104 , the process  1100  determines whether the asset authorization request is accompanied by a valid account authorization token and, if not, terminates at  1110 . Otherwise, the process  1100  continues at process block  1106 , in which the streams server identifies assets for download and generates a separate asset download authorization token for each asset authorized for downloading. The process  1100  concludes at process block  1108 , in which the streams server sends the asset download authorization token(s) to the requesting device. 
         [0047]    Turning now to  FIG. 12 , an asset download process  1200  begins at process block  1202 , in which an assets server receives an asset download request from a device that has received an asset download authorization token to commence downloading asset(s) to the device. The process  1200  continues at decision block  1204 , in which the assets server determines whether the asset download request was accompanied by a valid asset download authorization token and, if not, terminates at  1208 . Otherwise, the process  1200  concludes at process block  1206 , in which the assets server proceeds to download the authorized asset(s) to the device. 
         [0048]      FIGS. 13-16  are exemplary screen snapshots from a device illustrating embodiments of user interfaces for use in devices supporting asset streaming. As illustrated in  FIG. 13 , in an exemplary user interface  1300  for a mobile communication device, such as the iPhone®, an option for a Photo Stream feature may be selected by a user to turn on asset streaming for photo assets, and displays  1302  an “ON” status accompanied by the message “Photo Stream uploads and stores the last  30  days of your photos on MobileMe® and downloads them to all of your devices. Learn more . . . ” 
         [0049]    As illustrated in  FIG. 14 , in an exemplary user interface  1400  for a mobile communication device, such as the iPhone®, an option for a Photo Stream feature may include the automatic generation of a separate album devoted to the assets for Photo Stream, as indicated in the display  1402  under the Albums interface, Photo Stream ( 189 ) Updated Yesterday at 7:13 am.” 
         [0050]    As illustrated in  FIG. 15 , in an exemplary user interface  1500  for a mobile communication device, such as the iPhone®, selecting the Albums interface can display the asset images, or streamed photos, along with an informational footer  1502  “Updated Today 2:56 PM” 
         [0051]    As illustrated in  FIG. 16 , in an exemplary user interface  1600  for a mobile communication device, such as the iPhone®, an option for a Photo Stream feature may be de-selected by a user to turn off asset streaming for photo assets, and displays  1602  an “OFF” status accompanied by the warning message and button “DELETE PHOTOS, Turning off Photo Stream will delete all Photo Stream photos from your iPhone®,” with an option to cancel out of the action. 
         [0052]    Any one of the methods described herein can be implemented on a variety of different data processing devices, including general purpose computer systems, special purpose computer systems, etc. For example, the data processing systems which may use any one of the methods described herein may include a desktop computer or a laptop computer or a tablet computer or a smart phone, or a cellular telephone, or a personal digital assistant (PDA), an embedded electronic device or a consumer electronic device. 
         [0053]      FIG. 17  shows one example of a typical data processing system which may be used with the present invention. Note that while  FIG. 17  illustrates the various components of a data processing system, such as a computer system, it is not intended to represent any particular architecture or manner of interconnecting the components as such details are not germane to the present invention. It will also be appreciated that other types of data processing systems which have fewer components than shown or more components than shown in  FIG. 17  may also be used with the present invention. The data processing system of  FIG. 17  may be a Macintosh computer from Apple Inc. of Cupertino, Calif. As shown in  FIG. 17 , the data processing system  1701  includes one or more buses  1709  which serve to interconnect the various components of the system. One or more processors  1703  are coupled to the one or more buses  1709  as is known in the art. Memory  1705  may be DRAM or non-volatile RAM or may be flash memory or other types of memory. This memory is coupled to the one or more buses  1709  using techniques known in the art. The data processing system  1701  can also include non-volatile memory  1707  which may be a hard disk drive or a flash memory or a magnetic optical drive or magnetic memory or an optical drive or other types of memory systems which maintain data even after power is removed from the system. The non-volatile memory  1707  and the memory  1705  are both coupled to the one or more buses  1709  using known interfaces and connection techniques. A display controller  1711  is coupled to the one or more buses  1709  in order to receive display data to be displayed on a display device  1713  which can display any one of the user interface features or embodiments described herein. The display device  1713  can include an integrated touch input to provide a touch screen. The data processing system  1701  can also include one or more input/output (I/O) controllers  1715  which provide interfaces for one or more I/O devices, such as one or more mice, touch screens, touch pads, joysticks, and other input devices including those known in the art and output devices (e.g. speakers). The input/output devices  1717  are coupled through one or more I/O controllers  1715  as is known in the art. While  FIG. 17  shows that the non-volatile memory  1707  and the memory  1705  are coupled to the one or more buses directly rather than through a network interface, it will be appreciated that the data processing system may utilize a non-volatile memory which is remote from the system, such as a network storage device which is coupled to the data processing system through a network interface such as a modem or Ethernet interface or wireless interface, such as a wireless WiFi transceiver or a wireless cellular telephone transceiver or a combination of such transceivers. As is known in the art, the one or more buses  1709  may include one or more bridges or controllers or adapters to interconnect between various buses. In one embodiment, the I/O controller  1715  includes a USB adapter for controlling USB peripherals and can control an Ethernet port or a wireless transceiver or combination of wireless transceivers. It will be apparent from this description that aspects of the present invention may be embodied, at least in part, in software. That is, the techniques and methods described herein may be carried out in a data processing system in response to its processor executing a sequence of instructions contained in a tangible, non-transitory memory such as the memory  1705  or the non-volatile memory  1707  or a combination of such memories, and each of these memories is a form of a machine readable, tangible storage medium. In various embodiments, hardwired circuitry may be used in combination with software instructions to implement the present invention. Thus the techniques are not limited to any specific combination of hardware circuitry and software or to any particular source for the instructions executed by the data processing system. 
         [0054]    Portions of what was described above may be implemented with logic circuitry such as a dedicated logic circuit or with a microcontroller or other form of processing core that executes program code instructions. Thus processes taught by the discussion above may be performed with program code such as machine-executable instructions that cause a machine that executes these instructions to perform certain functions. In this context, a “machine” may be a machine that converts intermediate form (or “abstract”) instructions into processor specific instructions (e.g. an abstract execution environment such as a “virtual machine” (e.g. a Java Virtual Machine), an interpreter, a Common Language Runtime, a high-level language virtual machine, etc.), and/or, electronic circuitry disposed on a semiconductor chip (e.g. “logic circuitry” implemented with transistors) designed to execute instructions such as a general-purpose processor and/or a special-purpose processor. Processes taught by the discussion above may also be performed by (in the alternative to a machine or in combination with a machine) electronic circuitry designed to perform the processes (or a portion thereof) without the execution of program code. 
         [0055]    An article of manufacture may be used to store program code. An article of manufacture that stores program code may be embodied as, but is not limited to, one or more memories (e.g. one or more flash memories, random access memories (static, dynamic or other)), optical disks, CD-ROMs, DVD ROMs, EPROMs, EEPROMs, magnetic or optical cards or other type of machine-readable media suitable for storing electronic instructions. Program code may also be downloaded from a remote computer (e.g. a server) to a requesting computer (e.g. a client) by way of data signals embodied in a propagation medium (e.g. via a communication link (e.g. a network connection)). 
         [0056]    The term “memory” as used herein is intended to encompass all volatile storage media, such as dynamic random access memory (DRAM) and static RAM (SRAM). Computer-executable instructions can be stored on non-volatile storage devices, such as magnetic hard disk, an optical disk, and are typically written, by a direct memory access process, into memory during execution of software by a processor. One of skill in the art will immediately recognize that the term “machine-readable storage medium” includes any type of volatile or non-volatile storage device that is accessible by a processor. 
         [0057]    The preceding detailed descriptions are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the tools used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of operations leading to a desired result. The operations are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like. 
         [0058]    It should be kept in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system&#39;s registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices. 
         [0059]    The present invention also relates to an apparatus for performing the operations described herein. This apparatus may be specially constructed for the required purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), RAMs, EPROMs, EEPROMs, magnetic or optical cards, or any type of media suitable for storing electronic instructions, and each coupled to a computer system bus. 
         [0060]    The processes and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct a more specialized apparatus to perform the operations described. The required structure for a variety of these systems will be evident from the description below. In addition, the present invention is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the invention as described herein. 
         [0061]    In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.