Web distributed storage system

A method is provided for storing a file as slices on storage elements. A computer having memory and at least one computer processor receives a request to store a file. The file is split into slices. A respective header is generated to individually identify each one of the slices. Emails are generated and for each email: an email body includes one of the slices and an email subject line includes the respective header. Each of the emails is stored on storage elements. First metadata is generated for the file, and the first metadata includes information to reconstruct the file from the slices.

BACKGROUND OF THE INVENTION

The present invention relates to data storage, and more specifically, to distributing portions of data for storage on email servers and/or storage systems.

The increase in the amount of data generated by businesses and the importance of the ability of a business to retrieve the information reliably has put a greater demand on data storage systems. Information technology professionals desire a data storage system that can efficiently handle and store vast amounts of data generated by the business. As well, individuals desire a data storage system that can efficiently handle and store personal data in a safe and secure manner, without high costs.

Moreover, the data needs to be safe from theft or corruption and stored in a manner that provides rapid accessibility. The data storage system should also make efficient use of current information technology resources of the business/individual and not put additional strain on the bottom line of the business or a burden on the individual.

BRIEF SUMMARY OF THE INVENTION

In accordance with exemplary embodiments, a method, implemented on a computer, for storing a file as slices on storage elements is provided. A computer having memory and at least one processor receives a request to store a file. The file is split into slices. A respective header is generated to individually identify each one of the slices. A plurality of emails are generated, where for each email of the plurality of emails, an email body includes one of the slices and an email subject line includes the respective header. Each of the plurality of emails is stored on storage elements. First metadata is generated for the file, and the first metadata includes information to reconstruct the file from the slices.

In accordance with exemplary embodiments, a method implemented on a computer for restoring a file that has been split into slices for storage is provided. A computer having memory and at least one processor receives a request to retrieve a file. Restore parameters are retrieved from a first metadata corresponding to the file. Slices of the file are retrieved from a plurality of email bodies of a plurality of emails based on the restore parameters. The slices of the file are reconstructed to a restored file based on the restore parameters. Computer program products for the above methods are provided in accordance with exemplary embodiments. Also, additional features are realized through the techniques of the exemplary embodiments. Embodiments are described in detail herein and are considered a part of the claimed invention. For a better understanding of features, refer to the description and to the drawings.

DETAILED DESCRIPTION OF THE INVENTION

Although data storage is a service that allows someone to store and recover a file employing a password, exemplary embodiments provide that after encoding a file, the file is split into little pieces of data and distributed among several storage systems such as, e.g., e-mail servers and/or storage systems. This distribution makes it very difficult for a server administrator or for someone to grab and decode a file because the stolen file can be incomplete, encoded, out of order, “garbaged” and/or without its decryption keys.

Exemplary embodiments allow for changing services independent of the employed hardware, independent of the employed software, and independent of the geographic location. After enciphering (encrypting) a file, a file is sliced and distributed among several simple e-mail accounts, email servers or proprietary storage systems, and a metadata document is generated for document recovering purposes.

A file can be spread around the world. Unless someone has access to the metadata document and to the file decryption key, it is not possible to restore the original data. Also, to increase security of the storage system, the metadata database can be stored by splitting it into pieces of data and distributing the metadata database among several storage services such as, e.g., e-mail servers and/or storage systems.

Now turning toFIG. 1,FIG. 1illustrates an architecture for archiving and restoring files in accordance with exemplary embodiments. It is understood that the architecture illustrated inFIG. 1is only for explanatory purposes and exemplary embodiments are not meant to be limited by the architecture shown inFIG. 1. The architecture illustrates an infrastructure through which users can archive and store files having any type of data. Various features, processes, modules, interfaces, hardware/software components, and services discussed herein may collectively be referred to as a web storage system and/or a web storage tool for explanation purposes. The various features, processes, modules, interfaces, hardware/software components, and services communicate with one another using standards and protocols known in the art, such as a Service Oriented Architecture (SOA, which is an architectural style that provides coupling among interacting software/hardware agents) protocol, Internet protocols (such as TCP/IP), etc.

In the following scenario, archiving a file will be discussed with reference toFIG. 1. A user utilizes a requests interface5of a communication device100to request to store a file. The requests interface5transmits the request to store the file to an administrative processor module10of a server105via a network115. The administrative processor module10routes the store request to a metadata generator50of a server110. It is contemplated that the administrative processor module10on the server105may receive requests from the communication device100either to establish a service account or to access network services for archiving or restoring files. The administrative processor10may implement authentication software for restricting or controlling access to archiving and restoring services discussed herein. The administrative processor module10on the server105may be in communication with a customer identity system (CIS) database (not shown), which stores user credentials (e.g., user names and passwords), along with account records.

The metadata generator50receives parameters (defined in a tool configurator) from the administrative processor module10. The tool configurator may be implemented in the administrative processor module10, or the tool configurator may be a separate module from the administrative processor module10. The metadata generator50generates metadata (for the file) that is used to restore the file, controls the storing service, ensures that all storing is traceable, and logs all transactions in a metadata database130. The metadata itself may be, e.g., an XML file or any other suitable file. The metadata generator50routes the file to an encryption module15.

The encryption module15receives the file encryption request and parameters from the metadata generator50. Based on the received parameters, the file is encrypted by the encryption module15. The encryption module15returns an encryption result to the metadata generator50, provides a keep alive signal to the metadata generator50, and sends an encryption done message to the metadata generator50. The encryption module15may forward the encrypted file to a splitter20.

The splitter20receives a file split request from the encryption module15. Based on split parameters, the encrypted file is sliced into slices by the splitter20. The splitter20transmits the file split result to the metadata generator50. Also, the splitter20forwards the file slices to an email header generator25, provides a keep alive signal to the metadata generator50, and sends a split done message to the encryption module15.

The email header generator25receives a slice store request from the splitter20. The header generator25is responsible for email message encapsulation of the file slices. The header generator25puts a header such as a subject line with each file slice to be saved as an email message in, for example, email servers and/or storage systems125. For redundancy, the header generator25is responsible for routing the same file slice to more than one place. For example, the header generator25can route the same file slice to one email server and/or storage system125at a particular geographical location and to a different email server and/or storage system125located at a different geographical location. Accordingly, the same file slice might be sent to different servers125and if one server fails, other servers125can supply the missing data (i.e., file slice). As discussed herein, the email servers and/or storage systems125inFIG. 1represent numerous servers and storage systems which may be located at various locations and/or numerous servers and storage systems which may be co-located.

Further, the header generator25may incorporate a garbage generator (not shown) for creating fake slices as garbage. Randomly and/or based upon header parameters, the header generator25via the garbage generator creates a dummy email message that will be stored as a valid file slice. The dummy garbage messages may be random data that have a header like the real file slices. Although file slices may be stored in email messages identified with a respective header, it is understood that the header generator25may provide a header and encapsulate the file slices as instant messages. Also, the header generator25may store some file slices as email messages on email servers and/or storage systems125and may store other file slices on instant messaging servers (not shown) for the same file or different files.

Also, the header generator25, based upon received parameters (e.g., from the splitter20) provides the key (e.g., of a public key/private key scheme for decrypting the file) for file recovery to the requests interface5of the communication device100. If no parameters were received, a default parameter will be employed by the header generator25. The header generator25provides a keep alive signal to the metadata generator50.

Now, restoring a file from its various file slices is discussed with reference toFIG. 1. A user may utilize the requests interface5to log into the administrative processor module10. Using a file key or password, the requests interface5makes a file restore request to the administrative processor module10. The administrative processor module10routes the file restore request to a document requester30of the server120. The document requester30controls and logs the file recovery activities to ensure traceability of the file recovery activities. The document requester30receives the file restore request and retrieves metadata for the file from the metadata database130. Using the parameters in the metadata, the document requester30routes the file slices for the requested file in the email servers and/or storage systems125to a de-splitter40. The document requester30can cause the file slices (which may be encapsulated in email messages) to be read from the email servers and/or storage systems125directly to the de-splitter40, regardless of whether email servers, storage devices, and/or a combination of both are used to store the file slices. Also, if there happens to be any missing file slices needed to recover the file, the document requester30is responsible for determining and recovering any missing file slices using redundancy, since the same file slices are stored on different email servers125. The document requester30keeps a list of on-line trusted de-splitter and decryption service providers.

Using the metadata from the metadata databases130, the de-splitter40reconstructs the sliced encrypted file from the file slices. For example, when file slices are received from the email server and/or storage systems125, the de-splitter40in cooperation with a garbage collector35determine if garbage slices are found, and if found, the garbage slices are discarded. For the remaining file slices, the de-splitter40discards the file slice header leaving only, for example, a binary code of the file slice. The de-splitter40queues the binary code from each file slice in order. For example, the de-splitter40is configured to extract the data of each file slice from the body of the email messages, and the de-splitter40compiles each file slice in the proper order. The de-splitter40reassembles the encrypted file after all the file slices are recovered, returns a file slices received result to the document requester30, and forwards the encrypted file to a decryption module45.

The decryption module45receives the encrypted file from the de-splitter40and retrieves the decryption method from the metadata database. Although the document requester30and the de-splitter40can recover an encrypted file, exemplary embodiments are configured so that the document requester30and the de-splitter40do not have access to the decryption method. The decryption module45decodes the encrypted file using the decryption method and routes the decoded file to the requests interface5of the communication device100. The user of the communication device100is able to access the restored file via the requests interface5.

In accordance with exemplary embodiments, for each sliced file, the metadata database130may include information about the file, information about splits and file slices, information about email accounts, information about addresses to email servers and/or storage services, and information about header identifications.

InFIG. 1, it is understood that in exemplary embodiments and implementations, the communication device100can be a variety of other communication devices, such as general purpose or laptop computers, wireless devices such as cellular telephones and smart phones, portable computing devices, digital music players (for example, MP3 players), personal digital assistant (PDA), mobile devices, digital televisions, etc. According to exemplary embodiments, the architecture includes the communication device100as discussed above, which can also be an IP enabled television communicatively coupled to a set top box for accessing the network115, such as but not limited to the Internet. The network115may include circuit-switched and/or packet-switched technologies and devices, such as routers, switches, hubs, gateways, etc., for facilitating communications among the communication device100, server105, server110, server120, email servers and/or storage systems125, and metadata database130. The network115may include wireline and/or wireless components utilizing, e.g., IEEE 802.11 standards for providing over-the-air transmissions of communications.

In exemplary embodiments, the network115can be a managed IP network administered by a service provider, which can control bandwidth and quality of service for the communications discussed herein. The network115may be implemented in a wireless fashion, e.g., using wireless protocols and technologies, such as WiFi, WiMax, BLUETOOTH, etc. The network115can also be a packet-switched network, such as a local area network, a wide area network, a metropolitan area network, an Internet network, or other similar types of networks. The network115may be a cellular communications network, a fixed wireless network, a wireless local area network (LAN), a wireless wide area network (WAN), a personal area network (PAN), a virtual private network (VPN), an intranet or any other suitable network, and the network115may include equipment for receiving and transmitting signals, such as a cell tower, a mobile switching center, a base station, a wireless access point, and a satellite.

The servers105,110,120, and the email servers and/or storage systems125may be implemented using a high-speed processing device (e.g., a computer system) that is capable of handling high volume activities conducted over the network115.

Furthermore, exemplary embodiments are not limited to but are capable of being implemented in the architecture illustrated inFIG. 1. Additionally, the servers105,110, and120may be representative of numerous servers. The email servers and/or storage systems125may be representative of numerous email servers and/or storage systems125. Likewise, the network115may be representative of numerous networks, and the communication device100may be representative of numerous communication devices. Therefore, the architecture illustrated inFIG. 1is neither limited numerically to the elements depicted therein nor limited to the exact configuration and operative connections of elements. Further, it is understood by those skilled in the art that elements may be added to, subtracted from, or substituted for the elements described in the architecture ofFIG. 1. It is also understood that each module (for example, requests interface5, administrative processor module10, encryption module15, splitter20, header generator25, document requester30, garbage collector35, de-splitter40, and decryption module45) may reside and be implemented on individual high speed processing devices or be implemented on a single high speed processing device.

FIG. 2illustrates splitting metadata in accordance with exemplary embodiments. For explanatory purposes, metadata is described inFIG. 2as 1stmetadata205, 2ndmetadata210, and through n metadata215, where 1stmetadata205is information about splitting and restoring the file slices, where 2ndmetadata210is information about splitting and restoring the 1stmetadata205, where n metadata215, which represents a last metadata is information about splitting and restoring n−1 metadata which represents metadata next to the last metadata, such as a 1st, 2nd, 3rd, 4th, 5th, 6th. . . metadata. Also, it is understood that the 2ndmetadata210may also include information about splitting and restoring the file slices, along with information about splitting and restoring 1stmetadata205; this is also true for any subsequent metadata through n metadata215.

FIG. 2illustrates a 1stmetadata205that includes various parameters for restoring file slices of a file. With reference toFIG. 1, the 1stmetadata205may be sent by the metadata generator module50to the splitter20. The splitter20receives the 1stmetadata205and splits the 1stmetadata205into 1stmetadata slices205a,205b,205nwhich represents a last 1stmetadata slice shown inFIG. 2. The splitter20sends the 1stmetadata slices205a,205b, and205nto the header generator25. For the 1stmetadata slices205a,205b, and205n, the header generator25creates individual headers, creates individual email messages, provides the addresses for the email messages, inserts the respective 1stmetadata slices205a,205b, and205nin the body of the email messages, and transmits the email messages to respective email servers and/or storage systems125(seeFIG. 3).

InFIG. 2, information regarding splitting and restoring 1stmetadata205is stored in 2ndmetadata210, and/or the 2ndmetadata210may include information for restoring the file slices of the file. The 2ndmetadata210may be sent from the metadata database130to the splitter20by the metadata generator module50, and the splitter20divides the 2ndmetadata210into 2ndmetadata slices210a,210b, and210n. The 2ndmetadata slices210a,210b, and210nare sent by the splitter20to the header generator25. As discussed herein, the header generator25creates individual headers, creates individual email messages, provides the addresses for the email messages, inserts the respective 2ndmetadata slices210a,210b, and210nin the body of the email messages, and transmits the email messages to respective email servers and/or storage systems125(seeFIG. 3).

Likewise, n metadata215comprises information regarding splitting and restoring n−1 metadata, and for the sake of this example, n−1 metadata will be the 2ndmetadata210. It is understood by one skilled in the art that there may be numerous metadata before n metadata215, and exemplary embodiments are not limited to the 2ndmetadata being immediately before n metadata215. Additionally, n metadata may include information for restoring the file slices of the file. In one example, n metadata215may not be split and may be stored in the metadata database130and/or the emails servers and/or storage systems125. In another example, n metadata215may be split into n metadata slices215a,215b, and215nso that respective emails messages can be created and stored for n metadata slices215a,215b, and215naccording to exemplary embodiments. When n metadata215is split into n metadata slices215a,215b, and215n, an additional metadata (not shown) may be generated by metadata generator50to store information regarding splitting and restoring the n metadata215. In accordance with exemplary embodiments, it is contemplated that the 1stmetadata slices205a,205b, and205nof the 1stmetadata205, the 2ndmetadata slices210a,210b, and210nof the 2ndmetadata21a, and n metadata slices215a,215b, and215nof n metadata215may be reconstructed and restored in accordance with the processes discussed herein for restoring files from file slices.

FIG. 3illustrates an example of slices of data being incorporated in messages300in accordance with exemplary embodiments. The example discusses file slices, but as discussed herein, one skilled in the art understands that the slices of data may be instant message slices, metadata slices, etc.

With reference toFIG. 3, the header generator25is configured to select an appropriate server and/or storage system125as the address in the address box310. The header generator25creates an appropriate header in a subject box320for the file slice and inserts the file slice in the email body330of one of the email messages300. For example, for the first file slice, the header generator25may select the address of server01to input in the address box310and creates a header file slice01to input in the subject box320. The header generator25adds the file slice data (for example, binary code) in the email body330of the email message300.

The header generator25can create as many email messages300as needed for each file slice of the file. For example, the header generator25creates the email message300that is addressed to server n, with a header file slice n and inputs the corresponding file slice data in the email body330. InFIG. 3, there is no limitation with regard to the address of servers01through n. For example, some file slices for a file may be sent to servers at different geographical locations, to different servers at the same location, and/or to servers managed by different entities all across the world. Additionally, some file slices may be sent to different partitions of a server.

Also, in accordance with exemplary embodiments, the messages300may be instant messages that are created and sent by header generator25to various instant messaging servers, and the instant messages may utilize the address box310, the subject box320and/or email body330as shown inFIG. 3.

Tables 1, 2, 3, and 4 are respectively illustrated inFIGS. 4,5,6, and7. Tables 1, 2, 3, and 4 provide a general description of elements utilized in exemplary embodiments. Although elements in Tables 1, 2, 3, and 4 are designated as having certain responsibilities, services, and features, it is understood by one skilled in the art that the particular responsibilities, services, and features of any element may be shared with, integrated with, and/or independent from any other element discussed herein.

As discussed herein, exemplary embodiments provide redundancy so that the same file slice can be sent to different servers. If one server fails, other servers can supply the missing data. Exemplary embodiments provide speed and download/load balancing, since it is possible to recover parts (for example, file slices) of the file from different servers. Exemplary embodiments can also use existing Internet infrastructure, and there is no need to change the existing storage services structure or email services, because email services are only utilized for sending/receiving messages and storage systems are only sending/receiving files. Further, in accordance with exemplary embodiments all modules (such as the document requester30, splitter20, metadata generator50, etc.) of the web storage tool are services, and exemplary embodiments provide service redundancy. For example, if a module (service) is off line, exemplary embodiments can route the slice or file to a trusted and available service provider in place of the service (module) that is off line. In other words, if any file slice is lost or if any specific service provider is off line, exemplary embodiments provide redundancy for each file slice and redundancy for each service. Service redundancy may be implemented in a service oriented architecture.

Further, with regard to security, since the file is enciphered (encrypted), the file contents (such as file slices) will not be indexed by an unauthorized search mechanism. Also, the user (for example, of the communication device100) may not have direct access to the data or to the metadata, and the decryption keys are held by the file owner (which may be the user). So even if an unauthorized metadata database administrator attempted to reassemble a file, decryption is not possible because decryption keys are held by the file owner (for example, the user of communication device100).

FIG. 8is a flow chart800illustrating archiving files in accordance with exemplary embodiments. The striped arrows in the flow chart800illustrate the flow of a process for storing a document805as file slices in accordance with exemplary embodiments. Herein, the terms document and file may be used interchangeably to represent data that can be archived and restored according to exemplary embodiments.

A user utilizing the communication device100may log into the requests interface5, and the requests interface5in turn logs into the administrative processor module10residing on the server105. The administrative processor module10responds to the requests interface5with a logon acceptable indication. The user is allowed to store the document805via the requests interface5. The requests interface5transmits the document805(for example, a file) and its related information to the administrative processor module10. The administrative processor module10determines an available metadata generator50to receive the document805and its related information. The metadata generator50generates metadata for the document805and stores the metadata in the metadata database130, such as a metadata database of a trusted metadata database service. The metadata generated by the metadata generator50may include, for example, file (document) name, file size, creation date of metadata, etc. The metadata generator50receives a done response from the metadata database10. The metadata generator50transmits the document805for encoding, along with optional encryption parameters, to the available encryption module15.

The encryption module15encrypts the document805and transmits the encrypted file name and encryption result to the metadata generator50. The metadata generator50transmits the encryption result, encrypted file name, owner of the encrypted file, size of the encrypted file, and creation date to the metadata database130. The metadata generator50receives a done response from the metadata database130. In response to the metadata generator receiving the encrypted file name, split parameters are supplied to the encryption module15from the metadata generator50. The encryption module15transmits the encrypted document805and split parameters to the available splitter20.

In response to receiving the encrypted document805and its split parameters, the splitter20splits the encrypted document805into file slices based on the received split parameters. If, for example, no split parameters were received by the splitter20, the splitter20may be configured to split the encrypted document805into file slices in accordance with predefined parameters of the splitter20. The splitter20transmits the encrypted file name, file slices information, and a split done message to the metadata generator50, and in response to the metadata generator receiving this information, the metadata generator50transmits the header parameters to the splitter20. The splitter20transmits the file slices and header parameters to the header generator25, and the header generator25responds to the splitter20with a slices received message.

Based on the header generator parameters, the header generator20generates the proper header for a message for each file slice, provides an address to and determines each email server and/or storage system125that is to receive each file slice in a message, inserts the garbage in dummy messages with appropriate headers, and provides redundancy so that the same file slice can be duplicated in a different message and stored on a different email server and/or storage system125from the original file slice.

The header generator25transmits the file slices in individual messages to the available email servers and/or storage systems125. In response to receiving the file slices, the email servers and/or storage systems125transmit an acknowledgement to the header generator25. The header generator25transmits the slices information and a store result to the metadata generator50, and in response, the metadata generator50transmits slices sent result message to the metadata database130. In response to receiving an acknowledgement from the metadata database130, the metadata generator50indicates a file store result message to the administrative processor module10. The administrative processor module10informs the user that the document805was archived via the requests interface5.

FIG. 9is a flow chart900illustrating restoring files in accordance with exemplary embodiments. The striped arrows in the flow chart900illustrate the flow of a process for reconstructing and restoring the stored document805in accordance with exemplary embodiments.

A user utilizing the communication device100may log into the requests interface5, and the requests interface5in turn logs into the administrative processor module10residing on the server105. The administrative processor module10responds to the requests interface5with a logon acceptable indication. The user is allowed to request that the document805be restored via the requests interface5. The requests interface5transmits the file name and request for restoration of the document805to the administrative processor module10.

Using the received file name, the administrative processor module10retrieves the restore parameters for the document805from the metadata database130. The administrative processor module10selects the available document requester30and transmits the file name and restore parameters to the available document requester30. Using the received restore parameters, the document requester30transmits a get slices message to the email servers and/or storage systems125. For example, if the file slices (for example, as email messages) for the document805are stored on 25 different email servers and/or storage systems125, the document requester30requests the corresponding file slice from each respective email server and/or storage system125.

The email servers and/or storage systems125each transmits respective file slices to the available de-splitter40. The de-splitter40receives each file slice and transmits a slices received message to the document requester30. Based on the restore parameters, the de-splitter40, via a garbage collector35that may be integrated with and/or separate from the de-splitter, determines whether there are any garbage files in dummy messages, and if there are garbage files, the de-splitter40, via the garbage collector35, discards the garbage files in the dummy messages. Based on the restore parameters, the de-splitter40reconstructs the encrypted document from the received file slices. The de-splitter40transmits the encrypted document to the decryption module45.

The decryption module45receives the encrypted document and transmits an encrypted file received message to the document requester30. The decryption module45requests and retrieves the decryption method from the metadata database130for the encrypted document. The decryption module45may use the decryption key or any other decryption method retrieved from the metadata database130to decrypt the encrypted document, and the decryption module45provides the restored document805to the requests interface5of the communication device100for the user. The decryption module45transmits a decryption result message to the documents requester30. The document requester30transmits a restore result message to the administrative processor module10, and the administrative processor module10transmits a restore result message to the requests interface5.

FIG. 10illustrates an example of a computer1000having capabilities, which may be included in exemplary embodiments. Various methods, procedures, modules, and techniques discussed herein may also incorporate and/or utilize the capabilities of the computer1000. One or more of the capabilities of the computer1000may be implemented in any element discussed herein, such as the communication device100, server105, server110, server120, metadata database130, email server and/or storage systems125, and network115.

Generally, in terms of hardware architecture, the computer1000may include one or more processors1010, computer readable memory1020, and one or more input and/or output (I/O) devices1070that are communicatively coupled via a local interface (not shown). The local interface can be, for example but not limited to, one or more buses or other wired or wireless connections, as is known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communications. Further, the local interface may include address, control, and/or data connections to enable appropriate communications among the aforementioned components.

The processor1010is a hardware device for executing software that can be stored in the memory1020. The processor1010can be virtually any custom made or commercially available processor, a central processing unit (CPU), a data signal processor (DSP), or an auxiliary processor among several processors associated with the computer1000, and the processor1010may be a semiconductor based microprocessor in the form of a microchip or a macroprocessor.

The software in the memory1020may include one or more separate programs, each of which comprises an ordered listing of executable instructions for implementing logical functions. The software in the memory1020includes a suitable operating system (O/S)1050, compiler1040, source code1030, and one or more applications1060of the exemplary embodiments. As illustrated, the application1060comprises numerous functional components for implementing the features, processes, methods, functions, and operations of the exemplary embodiments. The application1060of the computer1000may represent numerous applications, agents, software components, modules, interfaces, etc., as discussed herein but the application1060is not meant to be a limitation.

The operating system1050may control the execution of other computer programs, and provides scheduling, input-output control, file and data management, memory management, and communication control and related services.

The application(s)1060may employ a service oriented architecture, which may be a collection of services that communicate with each. Also, the service oriented architecture allows two or more services to coordinate and/or perform activities (for example, on behalf of one another). Each interaction between services can be self-contained and loosely coupled, so that each interaction is independent of any other interaction.

Further, the application1060may be a source program, executable program (object code), script, or any other entity comprising a set of instructions to be performed. When a source program, then the program is usually translated via a compiler (such as the compiler1040), assembler, interpreter, or the like, which may or may not be included within the memory1020, so as to operate properly in connection with the O/S1050. Furthermore, the application1060can be written as (a) an object oriented programming language, which has classes of data and methods, or (b) a procedure programming language, which has routines, subroutines, and/or functions.

The I/O devices1070may include input devices (or peripherals) such as, for example but not limited to, a mouse, keyboard, scanner, microphone, camera, etc. Furthermore, the I/O devices1070may also include output devices (or peripherals), for example but not limited to, a printer, display, etc. Finally, the I/O devices1070may further include devices that communicate both inputs and outputs, for instance but not limited to, a NIC or modulator/demodulator for accessing remote devices, other files, devices, systems, or a network, a radio frequency (RF) or other transceiver, a telephonic interface, a bridge, a router, etc. The I/O devices1070also include components for communicating over various networks, such as the Internet or an intranet. The I/O devices1070may be connected to and/or communicate with the processor1010utilizing Bluetooth connections, cables (via, for example, Universal Serial Bus (USB) ports, serial ports, parallel ports, firewire, HDMI (High-Definition Multimedia Interface), etc.).

When the computer1000is in operation, the processor1010is configured to execute software stored within the memory1020, to communicate data to and from the memory1020, and to generally control operations of the computer1000pursuant to the software. The application1060and the O/S1050are read, in whole or in part, by the processor1010, perhaps buffered within the processor1010, and then executed.

Aspects of the present invention may take the form of a computer program product embodied in one or more computer readable mediums having computer readable program code embodied therein. The application1060can be embodied in any computer-readable medium for use by or in connection with an instruction execution system, apparatus, or device, such as a computer-based system, processor-containing system, or other system that can fetch the instructions from the instruction execution system, apparatus, or device and execute the instructions. The computer readable medium may be a computer readable signal medium or a computer readable storage medium.

When the application1060is implemented in software it should be noted that the application1060can be stored on virtually any computer readable storage medium for use by or in connection with any computer related system or method. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

More specific examples (a nonexhaustive list) of the computer-readable storage medium would include the following: an electrical connection (electronic) having one or more wires, a portable computer diskette (magnetic or optical), a hard disk, a random access memory (RAM) (electronic), a read-only memory (ROM) (electronic), an erasable programmable read-only memory (EPROM, EEPROM, or Flash memory) (electronic), an optical fiber (optical), a portable compact disc memory (CDROM, CD R/W), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Note that the computer-readable storage medium could even be paper or another suitable medium, upon which the program is printed or punched, as the program 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. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

It is understood that the computer1000includes non-limiting examples of software and hardware components that may be included in various devices and systems discussed herein, and it is understood that additional software and hardware components may be included in the various devices and systems discussed in exemplary embodiments.

The capabilities of the exemplary embodiments can be implemented in software, firmware, hardware or some combination thereof.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one ore more other features, integers, steps, operations, element components, and/or groups thereof. “Exemplary embodiments” means exemplary embodiments of the present invention.