Patent ID: 12242417

DETAILED DESCRIPTION

A detailed description of one or more embodiments is provided below along with accompanying figures that illustrate the principles of the described embodiments. While aspects of the invention are described in conjunction with such embodiment(s), it should be understood that it is not limited to any one embodiment. On the contrary, the scope is limited only by the claims and the invention encompasses numerous alternatives, modifications, and equivalents. For the purpose of example, numerous specific details are set forth in the following description in order to provide a thorough understanding of the described embodiments, which may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the embodiments has not been described in detail so that the described embodiments are not unnecessarily obscured.

It should be appreciated that the described embodiments can be implemented in numerous ways, including as a process, an apparatus, a system, a device, a method, or a computer-readable medium such as a computer-readable storage medium containing computer-readable instructions or computer program code, or as a computer program product, comprising a computer-usable medium having a computer-readable program code embodied therein. In the context of this disclosure, a computer-usable medium or computer-readable medium may be any physical medium that can contain or store the program for use by or in connection with the instruction execution system, apparatus or device. For example, the computer-readable storage medium or computer-usable medium may be, but is not limited to, a random-access memory (RAM), read-only memory (ROM), or a persistent store, such as a mass storage device, hard drives, CDROM, DVDROM, tape, erasable programmable read-only memory (EPROM or flash memory), or any magnetic, electromagnetic, optical, or electrical means or system, apparatus or device for storing information. Alternatively, or additionally, the computer-readable storage medium or computer-usable medium may be any combination of these devices or even paper or another suitable medium upon which the program code is printed, as the program code can be electronically captured, via, for instance, optical scanning of the paper or other medium, then compiled, interpreted, or otherwise processed in a suitable manner, if necessary, and then stored in a computer memory. Applications, software programs or computer-readable instructions may be referred to as components or modules. Applications may be hardwired or hard coded in hardware or take the form of software executing on a general-purpose computer or be hardwired or hard coded in hardware such that when the software is loaded into and/or executed by the computer, the computer becomes an apparatus for practicing the invention. Applications may also be downloaded, in whole or in part, through the use of a software development kit or toolkit that enables the creation and implementation of the described embodiments. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.

Some embodiments of the invention involve software development and deployment in a distributed system, such as a cloud based network system or very large-scale wide area network (WAN), metropolitan area network (MAN), however, those skilled in the art will appreciate that embodiments are not limited thereto, and may include smaller-scale networks, such as LANs (local area networks). Thus, aspects of the one or more embodiments described herein may be implemented on one or more computers executing software instructions, and the computers may be networked in a client-server arrangement or similar distributed computer network.

Embodiments are directed to a system and method for providing flexible and dynamic automatic retention lock policies for backup dataset, andFIG.1illustrates a computer network system that implements one or more embodiments of such a system. In system100, a storage server102executes a data storage or backup management process112that coordinates or manages the backup of data from one or more data sources104,106, or108to storage devices, such as local storage in102itself, network storage114, or possible cloud storage111in network110. The backup server102hosts the backup application to manage and trigger backup jobs. These backup jobs will backup data (VMs, databases, files, etc.) from the data sources (like VMs, Databases, files etc.) to the backup/storage server.

With regard to virtual storage104, any number of virtual machines (VMs) or groups of VMs (e.g., organized into virtual centers) may be provided to serve as backup sources. The data sourced by the data source may be any appropriate data, such as database data that is part of a database management system, and the data may reside on one or more hard drives for the database(s) in a variety of formats. Thus, a data source may be a database server106executing one or more database processes116, or it may be any other sources of data108for use by the resources of system100.

The network server computers are coupled directly or indirectly to the data storage114, VMs104, and the data sources and other resources through network110, which is typically a LAN, WAN or other appropriate network like a cloud network. Network110provides connectivity to the various systems, components, and resources of system100, and may be implemented using protocols such as Transmission Control Protocol (TCP) and/or Internet Protocol (IP), well known in the relevant arts. In a cloud computing environment, network110represents a network in which applications, servers and data are maintained and provided through a centralized cloud computing platform. In an embodiment, network110may be a private network or it may be a public network provided by a third-party cloud service provider (CSP).

The data generated or sourced by system100and transmitted over network110may be stored in any number of persistent storage locations and devices. In a backup case, the backup process112causes or facilitates the backup of this data to other storage devices of the network, such as network storage114, which may at least be partially implemented through storage device arrays, such as RAID components. In an embodiment network100may be implemented to provide support for various storage architectures such as storage area network (SAN), Network-attached Storage (NAS), or Direct-attached Storage (DAS) that make use of large-scale network accessible storage devices114, such as large capacity disk (optical or magnetic) arrays. In an embodiment, system100may represent a Power Protect Data Domain Restorer (DDR)-based deduplication storage system, and storage server102may be implemented as a DDR Deduplication Storage server provided by Dell. However, other similar backup and storage systems are also possible.

In an embodiment, the storage (or backup) server102applies one or more backup policies (e.g., conforming to application rules or governance/compliance rules) for storing the data. The deduplication backup system112deduplicates the data according to its processes and then sends this data to storage media, also referred to as a ‘storage target’, which may be local storage124, network storage114, or any other storage of any appropriate media (e.g., disk, tape, solid state memory, etc.). For full or partial cloud-based networks, the backup data can also, or instead be sent to cloud storage111in network110after local storage in the backup system.

After the data is received in the backup system and data ingest is complete, the backup application112issues lock requests through process120to set the lock for the newly written files. Files are thus generally retention locked after they are written to the storage media or cloud storage. The retention lock can be applied to any appropriate data object or element (e.g., directory, file, filesystem, etc.) as it is written and stored in the storage media. For the embodiment ofFIG.1, the lock is applied automatically by process121using certain defined automatic retention lock attributes that are associated with or encoded in the file to be retained and locked.

It should be noted that the data backup system ofFIG.1is provided for purposes of illustration, and retention lock process121can be used with any appropriate deduplicated backup system (other than Power Protect Data Domain), and other or alternative retention policies, rules, and standards. Furthermore, although embodiments are described with relation to retention locking for certain reasons, such as regulatory compliance, embodiments are not so limited and files may be retention locked for a variety of other reasons as well.

As shown inFIG.1, system100includes file retention lock process120that locks selected files against modification or deletion to protect these files from unintended or unwanted changes, or malicious tampering. In present systems, retention locking is typically enabled by user or administrator command at time of file creation or modification to lock the file for a certain period of time, which may be extended or reverted by the user, as per allowed policies. Retention locking may also be implemented automatically by the storage server102as part of backup management process112, or it may be executed by a cloud or network110resource, such as if a set of files is governed by a policy that automatically locks the files.

The two common ways used to lock the data are thus manual locking and automatic locking. For manual locking, the lock operation is performed on the file explicitly by executing a command or calling a retention lock API provided by the backup server or cloud storage REST API. This is done either manually by the user/admin or by the backup application after the data is ingested. For example, updating the “Last access time” of a file can trigger a lock operation in some backup servers. In one example, a PowerProtect Data Domain system, the Power Protect DDBoost client software provides explicit retention lock APIs that can be triggered by any application to lock individual files. In another example, AWS S3 REST APIs can be instructed to lock a file by adding certain HTTP Headers. Other manual retention lock mechanisms are also commonly available.

For automatic retention locking (ARL) or default locking, there is no deliberate or manual lock operation executed by users or applications (no APIs invoked to lock a file). The files are locked automatically for a predefined duration once the file or backup data is ingested by the backup server. The predefined duration is generally known as Auto Lock Period or Default Lock Period or Auto Retention Period. In this mode, the backups server or cloud storage software is responsible to ensure that the dataset (file or directory, etc.) gets locked automatically. Many backup servers provide a cooling period buffer before the file gets locked automatically, where the cooling period (COP) is the amount of time after which a file gets auto-locked if it is not modified within that time. For example, a COP of 2 hours would mean that file would get auto locked if it is not modified within 2 hours. If it is modified during this time, the COP period restarts.

As mentioned above, one issue with ARL is the restriction of having only one default lock or ARL period for the whole directory or cloud storage bucket. That is, if the ARL period is set to 6 months, for example, then all files would be locked for 6 months only. In such a system, it is generally not possible to specify different ARL periods for different sets/groups of files under the same directory, filesystem share, or bucket, etc. To get around this limitation, some users resort to creating multiple directories, filesystem shares, mounts, or cloud buckets etc., each with different ARL periods. As can appreciated, however, this approach is simply not feasible beyond a certain point, and also imposes a large management overhead. In extreme instances, users may resort to not using ARL, and fall back to the manual locking of each file with different durations as needed. In this case, the whole flexibility of auto-locking is lost, and clients need to call additional lock API for each file in the backup server.

A second major issue with ARL is extending lock durations of already locked files. Extending retention locks is an important and common procedure given that backup policies, data classifications, and so on, may change over the course of an originally set lock duration period. A traditional lock extension method works by iterating the filesystem and extending the locks at individual file level, one at a time. This filesystem iteration and lock extension operation together are time and resource consuming operations, and can greatly impact the performance of the backup server until the process completes, which can take many hours or days if there are significantly large number of files.

Modifying the configured ARL duration in present ARL methods may impact only the future new files or all existing files as well as future new files. However, this option depends on how it is implemented. One negative side effect of this is that locks are extended for all unwanted files as well as intended files, leading to capacity lockout, unnecessary cloud costs, and so on. Another side-effect is that all of the new files are now locked for a greater duration even if it was never the requirement. This problem just increases as more extensions are attempted.

To overcome these issues, embodiments of the dynamic ARL policy process121includes an efficient method to dynamically define and manage different ARL periods and lock extensions on the same file. It should be noted that the dynamic ARL process121can be configured on any directory, filesystem share, cloud storage bucket, container, or any other kind of storage volume or device, and described embodiments are equally applicable to any kind of storage unit type. For simplicity, embodiments will only refer to a directory structure, but embodiments are not so limited, as just mentioned.

In an embodiment, this directory structure may comprise an MTree, where system100is a Power Protect Data Domain deduplication backup system, and a Power Protect Data Domain Managed Tree (MTree) is a user-defined logical partition of the Power Protect Data Domain file system that enables granular management of a data in Data Domain system. In an embodiment, retention lock software120can be enabled at an individual MTree level. In general, once a backup file has been migrated onto a Data Domain system, it is the responsibility of the backup application to set and communicate the retention period attribute to the Data Domain system.

In an embodiment, process121provides dynamic ARL management in which backup applications or users can define multiple “ARL labels”, each having different values, such as retention lock period and COP, but applied on different sets or groups of files on the same MTree. This gives the backup applications a much fine-grained control for ARL without any kind of additional management overhead. The ARL labels are stored in a label database and a stored ARL label then be applied to many different files, with one label per file. When a protection policy is created in the backup application, a user can select one existing ARL label ID as per applicable retention requirements. Once the label is selected and the protection policy is created, the ARL label ID becomes part of the protection policy information. For every file ingested in a backup job, the backup application attaches this ARL label ID to indicate the retention requirements for the file.

For this embodiment, an ARL label comprises a data element, such as text string, table, or similar data element, that encodes a definition that includes: (i) ID: a unique identifier among all the labels in the system, (ii) ARL period: the amount of time a file will be locked automatically, (iii) cooling period (COP): the amount of time after which the file will be locked if no modifications happen in that time, and (iv) reference count: the number of files utilizing the ARL label.

As shown inFIG.1, system100also includes an instantaneous lock extension processing component123that allows the system to extend the lock duration on numerous files instantly virtually without any processor overhead, and also allows for the definition of multiple ARL labels, each potentially having different values (ARL period, COP) that can be applied to different sets of files in the same directory tree (MTree). For this embodiment, the ARL label includes as fourth definition (iv) comprising a reference count that specifies a number of files utilizing the particular label identified by the ID field. This reference count definition generally comprises an integer value of the number of discrete files that use the label. Depending on configuration, other data units may also be used for the reference count, such as number of directories, filesets, trees, and so on, as appropriate, and any number of counted items may be specified depending on system configuration, capacity, and so on. The instantaneous lock extension process123uses the reference count value to process the lock extension setting for these files.

As shown in this example, the ARL label generally describes the type of lock for which the attributes are used, such a critical lock, a short-term lock, and so on. Any appropriate lock type may be labeled accordingly based on file type, data type, or other characteristics. In conjunction with the reference count field (iv), a lock definition may be formatted as follows:

Lock_Type(ID)ARL_PeriodCOPReference_Count

One example of an ARL label might be: {ShortTermLocks, 7 days, 2 hours, 5}, which means that the default lock duration is 7 days and the cooling period is 2 hours, for an ID of “ShortTermLocks” that is used by 5 files. A second example might be: {CriticalLocks, 3 months, 10 minutes, 0}, which means that the default lock duration is 3 months and the cooling period is 10 minutes for lock ID CriticalLocks, and which 0 files are using. These are provided for purposes of example only, and any other label definition is possible.

FIG.2is a flowchart illustrating a method200for implementing dynamic ARL management using ARL labels, under some embodiments. In some current systems, to enable ARL on a MTree, a user may already configure the default ARL period and COP (if supported). Process200allows users to create additional ARL labels with different (ARL period, COP) values, which can be later attached to files, step202. All of the labels are managed in-memory and also stored in a persistent database. There can be a configurable maximum limit on the number of labels that can be created in the system or for each MTree. Any practical number can be used, and an example default could be maximum of 64 labels.

FIG.3illustrates an ARL label attached to a file302, in an example embodiment. Each file has a single label, and as shown inFIG.3, file302has a label304comprising the ID313, ARL period314, COP316, and reference count318values. A portion of the label is copied to and stored as metadata308attached to the file302. In an embodiment, the metadata portion306includes the label ID and COP value only, and the ARL period and reference count values are not copied to the metadata.

In general, the label304may be encapsulated as a text string or other data element, while the metadata portion (ID, COP)308is formatted in any appropriate metadata format for incorporation into the file302itself. The entire label304may thus comprise data in the form of a string of label data or a flat table, or other similar data element, and is stored as part of or associated with the file302. As shown inFIG.3, the system looks up labels in the label database310. The file302itself may be stored in the storage target in an MTree directory, or any other similar filesystem directory.

As shown inFIG.2, the ARL label ID (e.g., “LOCK_CRITICAL”) is specified during file creation,204. The label IDs are stored in a label database310that is typically stored locally in the server, such as in storage312. Most backup applications use the backup server's client software and its APIs to interact with the backup servers (e.g., Power Protect DDBoost in PowerProtect DD systems). Process200enhances the client software to allow users and applications to specify an “ARL Label ID” in the API calls when ingesting new files. Similarly, for cloud storage operations, the label ID can be specified via a specific HTTP header in the PUT or POST request (e.g., x-amz-arl-label-id: “ARL_LOCK_CRITICAL”). In this embodiment, the cloud storage software is configured to detect the presence of this header and act accordingly.

As shown inFIG.2, step206, when the backup server receives a file create request on ARL enabled directories, cloud storage or filesystem MTrees/buckets, etc., the method will first check for the presence of any ARL label ID in the request.

Label IDs are sent in a file create request, and upon finding a label ID in the request, the system will perform a lookup of the label contents for the given label ID,208. As shown inFIG.3, the label304comprises the ID, ARL period, COP and reference count values. The system then stores the label ID313and COP316values in the file's metadata308, step210. The COP value is stored in metadata to prevent the impact of any future modifications to the COP in the label that may change the lock state back to unlocked.

Upon a successful label lookup,208, the system will then perform an atomic increment of the reference count for the label ID as well to indicate that one more file is associated with the label,212.

A lock state check routine will fetch the ARL label ID from the file's metadata and uses it to lookup the label in the label database to obtain the ARL period from the database for the identified label,214. The system will then fetch the COP value directly from file metadata as it was copied during the file create phase,216.

Any change to the ARL period for a given label ID will also automatically reflect for all existing files as well as new ones, as they all refer to the values from the label DB itself, and any change to COP value for a label ID will reflect only in new files (as COP values are copied to the file metadata),218. For example, to extend the locks on already locked files, the system simply needs to update the corresponding ARL label's attributes (i.e. ARL period and COP values) as needed, and this will reflect automatically in all of the existing and new files. This process thus utilizes the ARL label framework and uses it to provide instant lock extension for millions of files.

It should be noted that although certain process steps ofFIG.2are shown in a sequential order, certain steps may occur out of the illustrated sequence or concurrently with other steps. For example, the lock state check214may be performed independently of the other steps, and likewise, the lock extension step218may also be performed independently of the other steps.

Through process200, a file can be retention locked through an automatic process for a retention period subject to a cooling period as specified by a specific ARL attached to the file, and any changes (extension) of the lock period will be automatically instituted in new and existing files through the use of a label database-stored ARL period and metadata-stored COP value.

In certain cases, it may be necessary to validate the lock state of a file, such as for auditing purposes. For validating if a file is locked or not, component121fetches the ARL attributes (label ID, COP) from the file metadata308and the ARL period from the label database, and evaluates the lock state (i.e., lock or no_lock). For example, in a PowerProtect DD, for an ARL file, this might be expressed as:If (LastModifiedTime of File+COP)>Current_time), then the file is still in cooling period.If (LastModifiedTime of File+COP)<Current_time, then file is locked.If (LastModifiedTime of File+ARL period)<Current_time), then the lock has already expired.

In another example, the system may use the CreationTime instead of LastModifiedTime to deduce if the file is locked or in a cooling period. Many filesystem operations like write( ), setattr( ), remove( ), rename( ) etc. check the lock state of a file before allowing or rejecting the operation.

In an embodiment, the ARL label attributes may be modified. For this type of operation, certain rules may be imposed by process121. For example, the ARL period of a label can only be increased (within the system allowed limit) and never decreased, but the cooling period value of a label can be both increased and decreased within the allowed limits, but generally only for new files and not any existing files. If the ARL period is modified for a given label ID, the new period will be reflected immediately across all existing and new files, thus lock extensions can take effect immediately and flexibly through a simple database update.

In an embodiment, modifying a label's attributes through the database and/or metadata changes may require multi-level authorizations, e.g., admin and security officer credentials, multi-factor authorization, etc., and the new values would be synced to disk immediately. Other or additional similar rules may also be defined and required by the system100.

In some cases, it may be necessary to revert the lock on a file, that is, to unlock a previously or automatically locked file. For process121, using the instant lock extension process, reverting a lock on a file will remove the ARL label ID from the file metadata to indicate that the file is no longer locked. The reversion operation will also decrement the ARL labels reference count to indicate that one less file is now associated with the label.

As shown inFIG.3, the system maintains a persistent Label DB310kept in in-memory storage312. This database list can be stored as part of the MTree metadata or filesystem metadata. Alternatively, it can be a stored in a simple database on media such as SSD/NVME, where synchronous updates are fast. This takes advantage of the fact that many backup servers today utilize SSDs/NVMEs for storing the filesystem metadata, and so on. The labels can also be persisted in any other form that the backup server already supports and ensures integrity and consistency.

In an embodiment, labels stored in database310can be deleted only if their reference count is zero (0), that is, if all the referencing files are already deleted, or the locks are reverted on all the referencing files. This can be a use-case for backup applications which create a label with a new protection policy and then delete it when the policy and all its backups are deleted. If the same label ID is referenced by an application after it is deleted, then those file creates will fail. If the label is referenced by files whose lock state has already expired, then the label can be deleted only after deleting all those expired files first.

In a process using the label mechanism ofFIG.3, the system defines ARL and COP periods, associates the ARL period and COP period as attributes to a unique ARL label identifying the ARL policy, stores the ARL label in a label database, and attaches the ARL label to one or more files to automatically set a lock on the file corresponding to the ARL period and COP period. In this way, a single label can be applied to any number of files to quickly and conveniently define the ARL and COP periods for those files.

With respect to file replication, labels can constitute replicable attributes that are replicated or synced to replication destination systems as well. Such labels replicated to the destination would be read-only in nature and cannot be utilized by other files in the destination system. In the destination system, if there is already a label with the same name, then replication would fail until that is removed from the destination system. This would ensure the same level of ARL lock state is seen on all copies of the data.

As described, the dynamic ARL process121provides much fine-grained control in defining different ARL attributes for different sets of files or different backup policy levels. It ensures that no new MTree or filesystem share or S3 bucket needs to be created to support different sets of ARL attributes. The process applies equally on backup servers as well as cloud storage providing default and automatic retention locking capabilities to users, thus eliminating the need for manual locking.

The file retention lock process includes software that allows a user to set the lock on a file to prevent deletion or modification of a file for a set number of years (e.g., such as up to 70 years). This lock is automatically set after the specified cooling period and for the amount of time specified by the ARL period, during which no one is able to modify or delete the file. A number of different ARL and associated COP periods may be defined for each file to provide flexibility and greater granular control over the retention lock for each file.

As previously, one disadvantage of present retention lock methods is that they do not adequately provide for flexible extension of defined lock durations. For a set of locked files, extending any of the locks may affect other locked files or unnecessarily increase the lock duration of files, and may require iterating the filesystem to extend locks at an individual file level, which can impose great processing overhead, especially when there upwards of tens to hundreds of millions of files. Embodiments overcome these disadvantages by providing a method to extend the lock duration on numerous files instantly, and essentially without any additional processing overhead. They also allow the system or user to define multiple ARL labels, each having different (ARL period, COP) values which can be applied on different sets of files under the same MTree.

FIG.4is a flowchart that illustrates a method of extending a lock period of files using ARL labels, under some embodiments. As shown inFIG.4, the lock extension process400starts in step402with locking the files with the appropriate ARL label304, and as described in the description of process200ofFIG.2. In this step, a set of files are locked by the label. The ARL period is stored and looked up from the label database310through link320. The lock duration can be extended instantly by increasing the ARL period314of the label304through a database update, step404. Any number of files can thus have their lock durations extended in this manner. The new values will apply to all the existing and new files utilizing that particular label ID for ARL locking. For example, if the ARL period is increased by 30 days more, then all locked files would also be now locked for 30 more days automatically and instantly.

The ARL period314can be extended by any appropriate mechanism, such as by replacing an existing time period value with a greater time period value, e.g., 30 days to 60 days, 6 months to 9 months, etc., or it can be extended by specifying an addition period, such as “+30 days,” and so on. Such input can be provided by appropriate user interface (UI), command line interface (CLI), REST API, or any other similar mechanism.

In an embodiment, a request to extend the retention lock period can be made by any appropriate user, or system process. Such a process may be an automated process (e.g., backup process) that is subject to periodic or extraordinary changes to processing periods. Alternatively, users may decide at will as to whether or not to extend the retention lock period of certain files.

In an embodiment, modifying the attributes of a label304including the ARL period would require an appropriate authorization method. For example, a dual authorization model may be used, such as where both the administrator and security officer must provide credentials for the change to be enacted, or through dual sign-in capability of the system, or other multi-factor (MFA) mechanisms.

In general, any change in the retention locking period under this process only provides for lock extension, and no reduction of the ARL period is allowed. The COP value316can be increased or decreased to further modify ARL locking parameters,406, but such changes will apply to new files only, and will not impact previously locked files, as the COP values are copied to the file metadata during the create workflow.

As stated above, the reference count318is used to ensure that the label304cannot be deleted as long as one or more files referencing it (i.e., having the label ID in their metadata) are present. When all such files are deleted, the reference count as it has been previously updated (incremented or decremented) becomes zero, and only then can the label can be deleted, as shown in step408ofFIG.4. The overall process ofFIGS.2and4thus include a step of checking the reference count to verify that it is not zero prior to any attempted deletion of the ARL label.

Although embodiments are illustrated and described with respect to a Power Protect Data Domain system, which is a purpose-built backup appliance providing streaming deduplication, it should be noted that embodiments are not so limited and any other deduplication backup system may be used. Similarly, network110if cloud-based may integrate with an Dell ECS (or similar) system embodied as a public cloud or hosted private cloud to provide a scalable storage architecture. The system100may thus be implemented as an ECS-based object storage platform designed around use cases of an ever expanding cloud enabled data center. Object containers that can be created as an endless pool and scaled out across an expandable pool of storage nodes, and data may be stored as objects and accessed through API calls across multiple protocols including S3, Swift, and NFS among others. Embodiments are not so limited however, and other similar cloud-based storage systems may be used.

Embodiments of the processes and techniques described above can be implemented on any appropriate backup system operating environment or file system, or network server system. Such embodiments may include other or alternative data structures or definitions as needed or appropriate.

The network ofFIG.1may comprise any number of individual client-server networks coupled over the Internet or similar large-scale network or portion thereof. Each node in the network(s) comprises a computing device capable of executing software code to perform the processing steps described herein.FIG.5shows a system block diagram of a computer system used to execute one or more software components of the present system described herein. The computer system1005includes a monitor1011, keyboard1017, and mass storage devices1020. Computer system1005further includes subsystems such as central processor1010, system memory1015, I/O controller1021, display adapter1025, serial or universal serial bus (USB) port1030, network interface1035, and speaker1040. The system may also be used with computer systems with additional or fewer subsystems. For example, a computer system could include more than one processor1010(i.e., a multiprocessor system) or a system may include a cache memory.

Arrows such as1045represent the system bus architecture of computer system1005. However, these arrows are illustrative of any interconnection scheme serving to link the subsystems. For example, speaker1040could be connected to the other subsystems through a port or have an internal direct connection to central processor1010. The processor may include multiple processors or a multicore processor, which may permit parallel processing of information. Computer system1005is only one example of a computer system suitable for use with the present system. Other configurations of subsystems suitable for use with the present invention will be readily apparent to one of ordinary skill in the art.

Computer software products may be written in any of various suitable programming languages. The computer software product may be an independent application with data input and data display modules. Alternatively, the computer software products may be classes that may be instantiated as distributed objects. The computer software products may also be component software.

An operating system for the system1005may be one of the Microsoft Windows®. family of systems (e.g., Windows Server), Linux, Mac OS X, IRIX32, or IRIX64. Other operating systems may be used. Microsoft Windows is a trademark of Microsoft Corporation.

The computer may be connected to a network and may interface to other computers using this network. The network may be an intranet, internet, or the Internet, among others. The network may be a wired network (e.g., using copper), telephone network, packet network, an optical network (e.g., using optical fiber), or a wireless network, or any combination of these. For example, data and other information may be passed between the computer and components (or steps) of a system of the invention using a wireless network using a protocol such as Wi-Fi (IEEE standards 802.x), near field communication (NFC), radio-frequency identification (RFID), mobile or cellular wireless. For example, signals from a computer may be transferred, at least in part, wirelessly to components or other computers.

In an embodiment, with a web browser executing on a computer workstation system, a user accesses a system on the World Wide Web (WWW) through a network such as the Internet. The web browser is used to download web pages or other content in various formats including HTML, XML, text, PDF, and postscript, and may be used to upload information to other parts of the system. The web browser may use uniform resource identifiers (URLs) to identify resources on the web and hypertext transfer protocol (HTTP) in transferring files on the web.

For the sake of clarity, the processes and methods herein have been illustrated with a specific flow, but it should be understood that other sequences may be possible and that some may be performed in parallel, without departing from the spirit of the invention. Additionally, steps may be subdivided or combined. As disclosed herein, software written in accordance with the present invention may be stored in some form of computer-readable medium, such as memory or CD-ROM, or transmitted over a network, and executed by a processor. More than one computer may be used, such as by using multiple computers in a parallel or load-sharing arrangement or distributing tasks across multiple computers such that, as a whole, they perform the functions of the components identified herein; i.e., they take the place of a single computer. Various functions described above may be performed by a single process or groups of processes, on a single computer or distributed over several computers. Processes may invoke other processes to handle certain tasks. A single storage device may be used, or several may be used to take the place of a single storage device.

Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.

All references cited herein are intended to be incorporated by reference. While one or more implementations have been described by way of example and in terms of the specific embodiments, it is to be understood that one or more implementations are not limited to the disclosed embodiments. To the contrary, it is intended to cover various modifications and similar arrangements as would be apparent to those skilled in the art. Therefore, the scope of the appended claims should be accorded the broadest interpretation so as to encompass all such modifications and similar arrangements.