Patent Publication Number: US-9893896-B1

Title: System and method for remote storage auditing

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     This application is a continuation application of and claims priority to U.S. application Ser. No. 15/299,779, filed on Oct. 21, 2016, which is a continuation application of and claims priority to U.S. application Ser. No. 11/797,485, filed on May 3, 2007. The entire contents of each application are hereby incorporated by reference. 
    
    
     BACKGROUND OF THE INVENTION 
     Field of the Invention 
     The present invention relates to computer aided remote storage auditing. 
     Background Art 
     The demand for data storage continues to increase. The need for accessibility of data from multiple locations across the internet also continues to increase. Therefore, the ability to store and access data remotely is increasingly important in a variety of applications. One solution is to provide large storage at one or more central locations. Centralized storage, however, requires infrastructure that can support high bandwidth and large storage capacity. Such infrastructure is costly. Another solution is a distributed approach where computer systems having storage are coupled across one or more networks. In the absence of a central manager it can be difficult to use storage efficiently. For instance, with such networked systems, individual computer systems may have storage that goes unused. Peer-to-peer storage architectures have been developed to use this available storage to lower the bandwidth and storage costs to central managers. Peer-to-peer systems however, are difficult to manage and audit. For example, some users may attempt to cheat the system by discarding data after initial storage. Consequently, in peer-to-peer systems it is difficult to ensure that data is properly being stored. 
     What is needed is improved auditing of remote storage. 
     BRIEF SUMMARY OF THE INVENTION 
     The present invention relates to remote storage auditing. 
     In an embodiment, a remote storage auditor audits a storage donor that stores a data block on behalf of a data owner in a distributed storage environment. The remote storage auditor queries the storage donor for audit information associated with a sub-block of the data block. The remote storage auditor receives the audit information in the form of an audit path associated with the sub-block and a fingerprint for the data block. The remote storage auditor verifies the presence of the data block based on the audit information. 
     In another embodiment, a remote storage manager locally stores remote data. The remote storage manager receives remote data from a client for local storage in the form of a data block and a fingerprint for the data block. The remote storage manager verifies that the remote data is associated with the client and locally stores the remote data and fingerprint. The remote storage manager returns the locally stored remote data to the client in response to a return request. The remote storage manager generates an audit path for the locally stored data block in response to an audit request. The remote storage manager sends audit information to a remote storage auditor in the form of the audit path associated with a sub-block of the first data block and the first fingerprint. 
     In a further embodiment, the remote storage manager stores data remotely. The remote storage manager may encrypt data and send it to another remote computer system. The encrypted data may be in the form of a data block and a signed fingerprint for the data block. The remote storage manager may retrieve the encrypted data sent to the remote computer system. 
     In another embodiment, a remote storage auditing system may include a first remote storage manager configured to be a data owner, a second remote storage manager configured to be a storage donor, and a remote storage auditor. The first remote storage manager sends a data block and a signed fingerprint for the data block to the second remote storage manager. The second remote storage manager verifies that the signed fingerprint is associated with the data block and stores the data block and signed fingerprint. The second remote storage manager calculates a fingerprint for a sub-block of the data block, and sends the fingerprint for the sub-block and signed fingerprint to the remote storage auditor. The remote storage auditor audits a sub-block of the data block and verifies the fingerprint for the sub-block and signed fingerprint. 
     Also, in an embodiment, a computer implemented remote storage auditing system may operate on one or more computer systems. 
     Further embodiments, features, and advantages of the invention, as well as the structure and operation of the various embodiments of the invention are described in detail below with reference to accompanying drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES 
       The present invention will be described with reference to the accompanying drawings, wherein like reference numbers indicate identical or functionally similar elements. Also, the leftmost digit(s) of the reference numbers identify the drawings in which the associated elements are first introduced. 
         FIGS. 1A and 1B  are diagrams of a remote storage auditing system according to an embodiment of the present invention. 
         FIG. 2  is a diagram of a remote storage auditor according to an embodiment of the present invention. 
         FIG. 3  is a diagram of a remote storage manager according to an embodiment of the present invention. 
         FIG. 4A  is a flow diagrams for a storing process according to an embodiment of the present invention. 
         FIG. 4B  is a flow diagrams for a storing process according to another embodiment of the present invention. 
         FIG. 5  is a flow diagram for the auditing process according to an embodiment of the present invention. 
         FIG. 6  is a hash tree according to an embodiment of the present invention. 
         FIG. 7  is a diagram of an example computer system that can be used to implement an embodiment of the present invention. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     While the present invention is described herein with reference to illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the relevant art(s) with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility. 
     Overview 
     The present invention relates to computer aided remote storage auditing. In a remote storage environment, users send information to one or more remote users for remote storage. This can be, for example, a peer to peer (P2P) system or a P2P system with a central manager. A given user can send information for remote storage and receive information from a remote user for local storage. Users access the remote storage environment using computer systems or clients. 
     Example Remote Storage Auditing Environment 
     Various aspects of the present invention can be implemented by software, firmware, hardware, or a combination thereof. An example of a remote storage auditing system  100  is depicted in  FIG. 1A . Remote storage auditing system  100  includes one or more clients  110 , web server  130 , server  140 , and database  150 . Clients  110  may be coupled through one or more network(s)  120  to web server  130  and to one another. Network(s)  120  can be any one or more networks or combination of networks extending over small to large areas, including, but not limited to the internet. Server  140  is coupled to web server  130  and to database  150 . 
     In an embodiment, server  140  includes a remote storage auditor  160 . Remote storage auditor  160  may operate on server  140  and interface with database  150 . Clients  110  each include a remote storage manager  170 . Remote storage managers  170  may operate on one or more clients  110  as a storage donor or a data owner, or both, as described below. For clarity, in  FIG. 1 , clients  110  are labeled  110 A and  100 B to show examples of clients having remote storage managers  170  that operate as data owners and storage donors, respectfully. In this example, client  100 A is referred to as a data owner and client  110 B is referred to as a storage donor. However, any combination of clients operating as storage donors and data owners may be used. Clients that store data remotely are referenced in this application as data owners. Clients that store remote data are referenced in this application as storage donors. Operations performed by data owners and storage donors referenced in this application may refer to operations performed by users of the clients or to operations performed by the remote storage managers without user input. 
     In an embodiment, remote storage auditor  160  may manage storage quotas for clients  110 . These storage quotas represent the amount of storage allocated for each client  110  regardless of particular users of devices at a client  110 . In another embodiment, remote storage auditor  160  manages the storage quotas for each user. These storage quotas represent the amount of storage allocated for each user regardless of what client  110  he or she uses. Remote storage auditor  160  may also compensate storage donor  110 B for storing data from data owner  110 A. In another embodiment,  FIG. 1B  depicts more than one client  110 B′ which may operate as redundant storage donors. Clients  110 B′ are independently connected to network(s)  120  to ensure that data is stored on distinct devices. In a further embodiment, remote storage auditor  160  may scale the quota of a data owner  110 A that requests redundant storage donors  110 B′ in proportion to the redundancy. Remote storage auditor  160  may periodically audit storage donor  110 B for the stored data and adjust storage quotas based on audit performance. 
     In order to ensure that storage donor  110 B only stores information from valid clients, data owner  110 A may provide identification to storage donor  110 B. In an embodiment, data owner  110 A may encrypt some or all of the information by various encryption methods readily known in the art. Data owner  110 A signs a fingerprint of the data with a private key and storage donor  110 B may verify the signed fingerprint with a public key. In one embodiment, the fingerprint is a root hash of the data. 
     In another embodiment, remote storage auditor  160  may provide a signed token containing storage session information. For example, the storage session information may include the identity of data owner  110 A, the identity of storage donor  110 B and the root hash of the data. Remote storage auditor  160  may sign the token with a private key. Storage donor  110 B receives the token from data owner  110 A and verifies its contents with a public key. This may provide further assurance that storage donor  110 B only stores information from valid clients and is described in greater detail with reference to  FIG. 4B  below. 
     Upon an audit request, storage donor  110 B may use one or more functions (e.g., hash functions) to generate the audit information and provides it to remote storage auditor  160  for verification. Storage donor  110 B, however, could cheat the audit by pre-calculating the audit information and then moving the data to another device or deleting it. Storage donor  110 B could then provide the pre-calculated audit information to remote storage auditor  160  upon request. 
     In order to reduce the incentive to pre-calculate the audit information, remote storage auditor  160  directs storage donor  110 B to provide an audit path for one or more randomly selected sub-blocks of the stored data. In this example, the audit information is a multi-level hash path from the sub-block to the root hash of the stored data. To cheat this type of audit with high probability, all possible audit paths for every sub-block of the stored data would have to be pre-calculated and stored. Storage of the pre-calculated audit paths would require more disk space than the stored data. The audit path provided to the auditor for any particular audit, however, requires relatively little bandwidth between the storage donor and the auditor. Additionally, verifying the audit path from the sub-block to the root verifies the presence of the entire stored data with high probability. 
     Remote Storage Auditor 
       FIG. 2  depicts a remote storage auditor  160  according to an embodiment of the present invention. Remote storage auditor  160  may include a controller  210 , and interfaces for communicating with clients ( 260 ,  270 , and  280 ). Key interface  260  may provide public key  261  to clients  110 . Remote storage request interface  270  communicates with data owner  110 A and audit interface communicates with storage donors  110 B. Remote storage auditor  160  may also be coupled to a user interface  290  to accept input and deliver output to a user of remote storage auditor  160 . Remote storage auditor  160  may include client quota manager  220 , storage location lookup  240 , data auditor  230  and hash verifier  250 . 
     In an embodiment, remote storage auditor  160  may direct remote storage managers  170  operating on clients  110  to available storage space supplied by other clients. Remote storage auditor  160  may also audit clients  110 . For example, remote storage auditor  160  may direct a remote storage manager  170 A operating as a data owner to an available remote storage manager  170 B operating as a storage donor. Remote storage auditor  160  may respond to a storage request made by a data owner. Storage location lookup  240  receives a storage request  272  and interfaces with client quota manager  220  to provide an identity of an available storage donor  271  to the data owner. This operation is described in greater detail in the storing data section below. 
     In another embodiment, remote storage auditor  160  may provide a signed token containing storage session information. For example, the storage session information may include the identity of data owner  170 A, the identity of storage donor  170 B and the root hash of the data. Remote storage auditor  160  may sign the token with a private key and storage donor  170 B receives the signed token from data owner  170 A and verifies its contents with a public key. This may provide further assurance that storage donor  110 B only stores information from valid clients and is described in greater detail with reference to  FIG. 4B  below. 
     In another embodiment, remote storage auditor  160  may issue audit requests to remote storage manager  170 B operating as storage donors. The frequency of the audits may be periodic or may be based on client or user reputation or other criteria. Data auditor  230  sends an audit request  281  to a storage donor, and receives audit information  282 . Audit request  281  defines a sub-block of a data block to verify. Hash verifier  250  uses public key  261  to verify audit information  282  and sends results to data auditor  230 . Data auditor  230  may interface with client quota manager  220  to punish or reward the storage donor based on the audit results. Client quota manager  220  may maintain client or user reputation information to schedule audits and change the size of a client&#39;s or user&#39;s available remote storage based on audit results. This operation is described in greater detail in the auditing storage donors section below. 
     Remote Storage Manager 
     In an embodiment, a remote storage manager  170  may operate as a data owner or a storage donor or both. Remote storage manager  170  is depicted in  FIG. 3  according to an embodiment of the present invention. Remote storage manager  170  may include a controller  305 , and interfaces for communicating with a remote storage auditor  160  and other remote storage managers ( 350 ,  355 ,  360 ,  365 ). Key interface  350  may provide public key  321  to clients  110 , remote storage auditor  160 , or a third party publisher (not shown). Remote storage request interface  355  and audit interface  365  communicates with remote storage auditor  160 . Remote storage interface  360  communicates with clients  110 . Remote storage manager  170  may also be coupled to a user interface  370  to accept input and deliver output to a user of remote storage manager  170 . Remote storage manager  170  may also include data  310  for remote storage, remote storage request generator  325 . Additionally, remote storage manager may include key generator  320 , signer verifier  335  and data packer  345 . Remote storage manager  170  may also include a local storage  315 , local storage interface  330 , and a hash tree calculator  340 . In another embodiment, local storage interface  330  may access storage outside the remote storage manager (not shown). 
     In another embodiment, remote storage manager  170  may operate as a data owner. Remote storage request generator  325  issues a storage request  326  to a remote storage auditor for storing data  310 . Hash tree calculator  340  calculates a fingerprint for data step  310 . In an embodiment, key generator  320  may generate a public and a private key  321  for data owner  170 . Data owner  170  may publish the public key with a publisher (not shown), or with a remote storage auditor and stores the private key locally. Signer/verifier  335  may use the private key  321  to sign fingerprint  341 . Data packer  345  receives the location for a storage donor from a remote storage auditor and sends data  310  and signed fingerprint  336  to the storage donor. This is described in greater detail in the storing data section below. In a further embodiment, the fingerprint is sent with the storage request. In this case, data packer  345  received the location along with a signed token and sends data  310 , signed fingerprint  336  and signed token to the storage donor. 
     In another embodiment, remote storage manager  170  may operate as a storage donor for locally storing data from a data owner. Hash tree calculator  340  receives a data block and signed fingerprint  361  from a data owner and calculates a fingerprint for the data block. Signer/verifier  335  uses public key  321  associated with the data owner the signed fingerprint and the calculated fingerprint to verify that the data block is from a valid data owner. If the verification is successful, local storage interface  330  stores the data block and signed fingerprint on local storage  315 . This is described in greater detail in the storing data section below. 
     In a further embodiment, storage donor additionally receives a signed token from the data owner. Storage donor verifies the contents of the signed token with a public key associated with the remote storage auditor. The contents of the signed token may contain storage session information. For example, the storage session information may include the identity of the data owner, the identity of the storage donor and the root hash for the data. This may provide further assurance that storage donor  110 B only stores information from valid clients and is described in greater detail with reference to  FIG. 4B  below. 
     In another embodiment, remote storage manager  170  may operate as a storage donor in response to an audit request. Hash tree calculator  340  receives an audit request  366  defining a sub-block of a data block to audit. Local storage interface  330  retrieves the data block and signed fingerprint from local storage  315 . Hash tree calculator  240  calculates an audit path from the sub-block to the root and sends the audit path and signed fingerprint to the remote storage manager. This is described in greater detail in the auditing section below. 
     Storing Data Remotely and Locally Storing Remote Data 
     In a remote storage environment, a client or user thereof wanting to store a data block requests the location of a storage donor from a remote storage auditor. For brevity, a method for storing data on a storage donor is described with reference to remote storage auditing system  100  but is not necessarily intended to be limited to the structure of remote storage auditing system  100 . In this example, a client  110 A operating as a data owner and a client  110 B operating as a storage donor is referenced. However, any combination of clients  110  operating as storage donors and data owners may be used. A storage method  400  is depicted in  FIG. 4A . According to an embodiment of the present invention, steps  4010  may be performed by a remote storage auditor  160 , steps  4020  may be performed by a data owner  110 A, and steps  4030  may be performed by a storage donor  110 B. 
     Remote storage auditor  160  receives a request for storage from a data owner (step  410 ) and provides the location for an available storage donor to the data owner (step  420 ). The data owner generates a signature to identify itself to the storage donor. In an embodiment, the data owner generates a public key (K PUB ) and a private key (K PRIV ) and may publish the public key with a publisher (not shown), or with a remote storage auditor and stores the private key locally (step  430 ). This key generation may only be performed the first time the data owner requests storage. This is an asymmetric encryption where a private key is used to encrypt data which can later be decrypted by anyone with the corresponding public key. In other embodiments, other signature methods may be used, for example, a single key (symmetric encryption), combined keys (shared secret), or other signatures. 
     The data owner calculates the fingerprint for the data block to be stored (step  440 ). In one example, the data owner uses a hash function to generate the fingerprint; however, other functions may be used.  FIG. 6  shows a Merkle tree for data block D. Hash function H is applied to sub-blocks B 0 -B 7  to produce leaf hashes L 0 -L 3 , and R 0 -R 3 . Hash function H is then applied recursively to pairs of hashes (i.e. H(L 6 |R 6 )=H(H(L 4 |R 4 )|H(L 5 |R 5 ))) until a single hash, the root hash, is produced. In this example root hash R is the hash H(L 6 |R 6 ). In an embodiment the data owner generates signed root hash R S  by signing the root hash R with the private key K PRIV  and sends data block D and signed root hash R S  to the storage donor (step  450 ). 
     The storage donor then calculates the root hash R of data block D (step  460 ). The storage donor may then verify signed root hash R S  with the public key K PUB  and the calculated root hash R (step  470 ). This ensures that data block D is, in fact, from the data owner and prevents the storage donor from being used by unsecured and unmonitored users. After the storage donor has verified data block D, it then stores signed root hash R S  and data block D locally (step  480 ). The storage donor can then respond to routine retrieve requests from the data owner. 
     Storage method  400 ′ depicted in  FIG. 4B  is an alternative implementation. According to an embodiment of the present invention, steps  4010  may be performed by a remote storage auditor  160 , steps  4020  may be performed by a data owner  110 A, and steps  4030  may be performed by a storage donor  110 B. In this alternative implementation data owner  110 A calculates the fingerprint for the data block to be stored (step  440 ) prior to issuing a storage request (step  405 ). 
     Remote storage auditor  160  receives a request for storage from a data owner (step  410 ) and generates storage session information. For example, the storage session information may include the identity of data owner  170 A ID DO , the identity of storage donor  170 B ID SD  and the root hash for the data R. Remote storage auditor  160  generates a public key (AK PUB ) and a private key (AK PRIV ) and may publish the public key with a publisher (not shown), or store it locally and stores the private key locally (step  425 ). This key generation may only be performed the first time the data owner requests storage. Remote storage auditor  160  then signs the storage session information with its private key AK PRIV  to produce token T. This is an asymmetric encryption, however, in other embodiments, other signature methods may be used as described above. Remote storage auditor provides the location for an available storage donor and token T to the data owner (step  420 ). 
     In this embodiment, the data owner sends data block D, signed root hash R S , and signed token T to the storage donor (step  450 ). The storage donor then verifies signed root hash R S  as described above and also verifies signed token T with the remote storage auditor&#39;s public key AK PUB  (step  470 ). This may provide further assurance to the storage donor that the data owner is a valid client because the storage owner knows that the remote storage auditor has endorsed the storage session by signing the session information with its private key. This also allows the storage donor to ensure that the session information accurately reflects the identity of the data owner ID DO , the identity of the data owner ID DO  and the root hash of data block D. 
     Auditing Storage Donors 
     In a remote storage environment, a remote storage auditor  160  can monitor storage donors. For brevity, a method for auditing storage donors is described with reference to remote storage auditing system  100  but is not necessarily intended to be limited to the structure of remote storage auditing system  100 . In one example, a client  110 B operating as a storage donor is referenced. However, a remote storage auditor may audit any number of clients  110  operating as storage donors. An auditing method  500  is depicted in  FIG. 5 . According to an embodiment of the present invention, steps  5010  may be performed by a remote storage auditor  160 , and steps  5020  may be performed by a storage donor  110 B. 
     In an embodiment, the remote storage auditor initiates an audit of data block D by identifying a random sub-block Bi of data block D and sends that information to a storage donor (step  510 ). In an embodiment, the storage donor generates an audit path. In this example, the storage donor uses a multi-level hash function, such as a Merkle tree; however, other functions may be used. The storage donor generates the tree by hashing each sub-block of the data recursively (step  520 ). 
     Remote storage auditor  160  performs audits on a sub-block of the data, whereby the storage donor generates the multi-level hash information, but need only provide the audit path for the sub-block (step  530 ). In an embodiment, the audit path may be a hash representation of data in all the sub-blocks of data block D. In one example with  8  sub-blocks, the audit path comprises the hash nodes from the sub-block to the root.  FIG. 6  shows a Merkle tree for data block D with the audit path from shown in gray. The audit path comprises one pair of hash nodes for each hash level and the root. For each hash level, the pair comprises the hash that contains sub-block B 2  and its companion hash. For example, with reference to  FIG. 6 , the audit path includes 3 pairs (L 1 ,R 1 ; L 4 ,R 4 ; and L 6 ,R 6 ) and the root This reduces the bandwidth required between the storage donor and the remote storage auditor since the hash path scales logarithmically with the size of the data block. This also discourages pre-calculating audit information because the storage space required for all possible audit results is greater that the storage space required for storing the data. For example, twice the storage space is required to store the Merkle tree for data block D than is required to store data block D. The storage donor sends the audit path to the remote storage auditor (step  540 ). The storage donor optionally provides signed root hash R S  and/or sub-block B i  to the remote storage auditor. 
     Upon receipt of the audit information, the remote storage auditor verifies the signature information (step  550 ). For example, where a multi-level hashing function is employed, the remote storage auditor can verify the hash path by hashing each level of child nodes starting at the leaf nodes and comparing the result with the parent node of the next level, ending with the root hash. Remote storage auditor  160  may then verify signed root hash R S  with the public key K PUB  and the calculated root hash R (step  550 ). Because the sub-block is selected randomly and all sub-blocks of the data are used in to generate the audit path, a passing audit either verifies the presence of the multi-level hash information or the data block. As discussed above, the required storage for the multi-level hash information is greater than that of the data block; therefore a passing audit is most likely a verification of the entire data block. 
     Upon completion of an audit, the storage donor and/or its user may be rewarded or penalized depending upon the audit results (steps  460 - 80 ). Audit frequency may be adjusted based on outcomes of prior audits. For example, remote storage auditor  160  may audit a trusted storage donor less frequently. Remote storage auditor  160  may then delete the audit information. 
     Remote storage auditor  160  may also manage the distributed storage environment. Management of the distributed storage environment may include managing user accounts and storage quotas, and identifying remote locations for storage. Data transmitted for remote storage is typically sent from the data owner to the storage donor. The remote storage auditor need not receive or store any portion of the remotely stored information, except as desired or required during auditing operations. 
     Alternatively, the distributed storage environment may be implemented in a peer-to-peer system without a central remote storage auditor, in which case audits can be performed by data owners and/or by a third party auditor. 
     Example Computer System Implementation 
     Various aspects of the present invention, such as client  110 , web server  130 , server  140 , remote storage auditor  160  and remote storage manager  170 , can be implemented by software, firmware, hardware, or a combination thereof. Clients  110  may be any computing or processing device that supports network communication. Example computing or processing devices include, but are not limited to, a computer, workstation, distributed computing system, embedded system, stand-alone electronic device, networked device, mobile device, set-top box, television, or other type of processor or computer system. 
       FIG. 7  illustrates an example computer system  700  in which the present invention, or portions thereof, can be implemented as computer-readable code. Various embodiments of the invention are described in terms of this example computer system  700 . After reading this description, it will become apparent to a person skilled in the relevant art(s) how to implement the invention using other computer systems and/or computer architectures. 
     Computer system  700  includes one or more processors, such as processor  704 . Processor  704  can be a special purpose or a general purpose processor. Processor  704  is connected to a communication infrastructure  706  (for example, a bus or network). 
     Computer system  700  also includes a main memory  708 , and may also include a secondary memory  710 . Main memory  708  may include, for example, cache, and/or static and/or dynamic RAM. Secondary memory  710  may include, for example, a hard disk drive  712  and/or a removable storage drive  714 . Removable storage drive  714  may comprise a floppy disk drive, a magnetic tape drive, an optical disk drive, a flash memory, or the like. The removable storage drive  714  reads from and/or writes to a removable storage unit  718  in a well known manner. Removable storage unit  718  may comprise a floppy disk, magnetic tape, optical disk, flash memory, etc., which is read by and written to by removable storage drive  714 . As will be appreciated by persons skilled in the relevant art(s), removable storage unit  718  includes a computer usable storage medium having stored therein computer software and/or data. 
     In alternative implementations, secondary memory  710  may include other similar means for allowing computer programs or other instructions to be loaded into computer system  700 . Such means may include, for example, a removable storage unit  722  and an interface  720 . Examples of such means may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM, or PROM) and associated socket, and other removable storage units  722  and interfaces  720  which allow software and data to be transferred from the removable storage unit  722  to computer system  700 . 
     Computer system  700  may also includes a main memory  702 . Main memory  702  may include, for example, cache, and/or static and/or dynamic RAM. Main memory  702  may be separate from main memory  708  or may be a part thereof. Main memory  702  may be adapted to communicate with display unit  716 . Display unit  716  may comprise a computer monitor or similar means for displaying graphics, text, and other data received from main memory  702 . 
     Computer system  700  may also include a communications interface  724 . Communications interface  724  allows software and data to be transferred between computer system  700  and external devices. Communications interface  724  may include a modem, a network interface (such as an Ethernet card), a communications port, a PCMCIA slot and card, or the like. Software and data transferred via communications interface  724  are in the form of a plurality of signals, hereinafter referred to as signals  728 , which may be electronic, electromagnetic, optical, or other signals capable of being received by communications interface  724 . Signals  728  are provided to communications interface  724  via a communications path  726 . Communications path  726  carries signals  728  and may be implemented using wire or cable, fiber optics, a phone line, a cellular phone link, an RF link or other communications channels. 
     In this document, the terms “computer program medium” and “computer usable medium” are used to generally refer to media such as removable storage unit  718 , removable storage unit  722 , a hard disk installed in hard disk drive  712 , and signals  728  carried over communications path  726 . Computer program medium and computer usable medium can also refer to memories, such as main memory  708  and secondary memory  710 , which can be memory semiconductors (e.g. DRAMs, etc.). These computer program products are means for providing software to computer system  700 . 
     Computer programs (also called computer control logic) are stored in main memory  708  and/or secondary memory  710 . Computer programs may also be received via communications interface  724 . Such computer programs, when executed, enable computer system  700  to implement the present invention as discussed herein. In particular, the computer programs, when executed, enable processor  704  to implement the processes of the present invention, such as the steps in the methods illustrated by flowcharts in  FIGS. 5-6  discussed above. Accordingly, such computer programs represent controllers of the computer system  700 . Where the invention is implemented using software, the software may be stored in a computer program product and loaded into computer system  700  using removable storage drive  714 , interface  720 , hard drive  712  or communications interface  724 . 
     Embodiments of the invention also may be directed to computer products comprising software stored on any computer usable medium. Such software, when executed in one or more data processing device, causes a data processing device(s) to operate as described herein. Embodiments of the invention employ any computer usable or readable medium, known now or in the future. Examples of computer usable mediums include, but are not limited to, primary storage devices (e.g., any type of random access memory), secondary storage devices (e.g., hard drives, floppy disks, CD ROMS, ZIP disks, tapes, magnetic storage devices, optical storage devices, MEMS, nanotechnological storage device, etc.), and communication mediums (e.g., wired and wireless communications networks, local area networks, wide area networks, intranets, etc.). 
     CONCLUSION 
     Exemplary embodiments of the present invention have been presented. The invention is not limited to these examples. These examples are presented herein for purposes of illustration, and not limitation. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope and spirit of the invention.