Patent ID: 12204585

DETAILED DESCRIPTION

The disclosure and various features and advantageous details thereof are explained more fully with reference to the exemplary, and therefore non-limiting, embodiments illustrated in the accompanying drawings and detailed in the following description. Descriptions of known starting materials and processes may be omitted so as not to unnecessarily obscure the disclosure in detail. It should be understood, however, that the detailed description and the specific examples, while indicating the preferred embodiments, are given by way of illustration only and not by way of limitation. Various substitutions, modifications, additions and/or rearrangements within the spirit and/or scope of the underlying inventive concept will become apparent to those skilled in the art from this disclosure.

Document management systems often employ a search engine to allow for fast retrieval of information. A search engine can search the metadata and text of documents in a search index to determine which documents match search criteria without having to parse the document itself.

When an object is added to a search system, two types of information may be indexed, one or both of full text and metadata. There are often many metadata fields for an associated object. The metadata may describe the objects being indexed. There can be various types of metadata, various ways metadata can be obtained and/or generated, as well as various ways to associate such metadata with certain objects which, in turn, can be of various types. Document records can be an example type of objects. If an object has or references text content, some metadata may be derived from the text content. This type of metadata can be referred to as derived metadata.

Derived metadata can be fragile in a search system. For example, suppose when an object that has or references text content is added to a search system, a software component in the search system analyzes the text content of the object and determines that the text content is generally positive, say, at 60%. This sentiment value of 60% is a type of derived metadata and is associated with the object in the search system. This derived metadata is indexed in a search index and is searchable by users of the search system to provide further insight about the object. However, this piece of valuable information may be lost when the index or the object is updated. This commonly happens if the metadata associated with the object is replaced, inadvertently also removing the derived metadata.

At this point, it may be helpful to discuss an example search system.

FIG.1depicts a block diagram illustrating one embodiment of a computing environment100with object search system101. Computing environment100includes an object repository105storing objects107of interest (documents, images, emails or other objects that may be searched). Object repository105may comprise a file server or database system or other storage mechanism remotely or locally accessible by search system101.

In the embodiment ofFIG.1, search system101comprises a server having a central processing unit112connected to a memory114and storage unit118via a bus. Central processing unit112may represent a single processor, multiple processors, a processor(s) with multiple processing cores and the like. Storage unit118may include a non-transitory storage medium such as hard-disk drives, flash memory devices, optical media and the like. Search system101may be connected to a data communications network (not shown).

Storage unit118stores computer executable instructions119and index124. Computer executable instructions119can represent multiple programs and operating system code. In one embodiment, instructions119are executable to provide an object analyzer120and search engine122. Object analyzer120and search engine122may be portions of the same program or may be separate programs. According to one embodiment, for example, object analyzer120is a component of a document management system while search engine122is a separate program that interfaces with the document management system. Furthermore, object analyzer120and search engine122can be implemented on different computing systems and can, themselves, be distributed.

Index124includes metadata used to identify objects in response to a search query and may also include text used to identify objects. Index124can include a single index containing metadata and text, separate metadata and text indices or other arrangements of information. While shown as a single index, index124may include multiple indices.

Client computer system130may include components similar to those of the server of search system101, such as CPU138, memory136, and storage140. Additionally, client computer system130may include executable instructions132to provide a user interface134that allows a user to enter a search query. The user interface may be provided through a web browser, file system interface or other program.

The search system101ofFIG.1is merely an example of a computing system and embodiments of a search system that may be implemented using other computing systems (e.g., desktop computers, laptops, mobile computing devices or other computing devices with adequate processing and memory) including multiple computers acting together to provide a search system (e.g., a cluster of servers or other computing devices connected by a network acting together to provide the search system). Similarly, client computer130may include any suitable desktop computer, laptop, mobile device, server or other computing system.

In operation, object analyzer120analyzes objects in object repository105to determine information to be indexed in index124. Object analyzer120can send indexing instructions to search engine122to direct search engine122to add/modify/or delete metadata or text in index124, as discussed below. When a search query is received, search engine122can search the information in index124to identify objects responsive to the search query and return a list or other representation of those objects to client computer130.

FIG.2depicts a diagrammatic representation of one embodiment of an object analyzer120for analyzing an object107. Object analyzer120can comprise various modules to process an object107. Reading source data module154can open the object107. Format identification module156examines the object to determine what type of file or data the object107comprises. Archive expansion module158unzips files or otherwise decompresses files if the object107is a compressed file. Decryption module160decrypts all or part of the data in the object107. Text extraction module162applies rules to text in the object107to extract text for index124. Language detection module164examines the text to determine the language in which the text is written. Classification module166applies rules based upon text and metadata to classify content. Encoding module168can convert text to a supported encoding. Randomness detection module170can analyze data to be indexed to reject random information.

Object analyzer120may include modules that can derive metadata for object107. For example, a document management system may provide a limited amount of metadata with the object107. Object analyzer120can derive other metadata from the metadata provided, text or other properties of the object107. As a specific example, a filter or piece or code that extracts the text from a PowerPoint presentation might also create metadata about the presentation. In this example, the metadata which is not provided by the document management system and which is derived by object analyzer120may include the number of slides in the presentation, the title of the file, the name of the presentation author, or the size of paper the presentation was designed to print on. More complex examples of derived metadata might include statistical analysis to generate a list of keyword or key concepts in the document; determining the subject person or company of the text; sentiment analysis—is the tone of the text positive or negative; or language identification—in what language is the text written. Further examples of metadata that may either be provided by the document management system (or other application) or derived by the analyzer may be the date the object was created, the size of the object in bytes, the name of the object, a description of the object or the like. Further clarification of derived metadata is provided below with reference toFIG.5.

The embodiment ofFIG.2is provided by way of example. Object analyzer120may include any number of other modules to analyze an object and extract text174and metadata172to be indexed. Object analyzer120may be a portion of a larger program, such as a document management program, may be a separate program or may be implemented according to any suitable programming architecture. In one embodiment, the process of determining metadata172and text174to be indexed may be carried out by any number of different programs on a computer system or distributed across computer systems.

Metadata172and text174thus processed by object analyzer120may be provided to a search engine. An example search engine will now be described with reference toFIG.3.

FIG.3depicts a diagrammatic representation of logical blocks for one embodiment of a search engine122. Search engine122may provide an indexing interface200that receives indexing requests (e.g., from object analyzer120) or other source. A distributor module210may distribute the indexing requests to indexing engine220that acts on an indexing request to update index124. Search engine122may also include a search interface230to receive queries (e.g., from a document management system or other source). Search interface230may send queries to search modules240. Federator245gathers the results from all search modules together and generates a response to the query received through search interface230. Search modules240are responsible for performing searches on an index partition, and performing tasks such as computing relevance score, sorting results, and retrieving metadata regions to return in a query.

Search interface230may be configured to receive a search query from a user, and search index124for objects that meet the criteria set forth in the search query. Query language may also be configured to permit sorting results of a search. Various rules may be used to determine the sort order. In this example, a user constructed the search query. It should be noted, however, that the user could be any system that issues queries to the search system, and may include other computer programs searching on behalf of other users, creating reports or running automatic processes. Additionally, as described above, there can be many different types of metadata in the search index. Thus, the search queries are not restricted to “text” based search terms.

In the context of this disclosure, the phrase “search term” represents a technical concept or interpretation. For example, a search term in the context of this disclosure can be a word, a string, or any combination of the following:phrasesnumbersstringslogical operations (e.g., AND, OR, NOT, etc.)ordering or operations (e.g., using parenthesis)relationships (e.g., greater than, less than, not equal to, etc.)similarities based on thesaurus, stemming, sounds-like, etc.wildcards and pattern matching

To this end, a search term can also refer to any term that is used in a query and that has been modified or generated by any commonly used techniques.

For context, a search term could be a word “john” or a more complex expression like: (>“bob” or !=(“123” or a*)) and (sounds-like “smith” or thesaurus “doctor” or “medical doctor” or stem “medical”).

The embodiment ofFIG.3is provided by way of example. Search engine122may include any number of other modules or configurations to update and search an index. For example, search modules240and indexing engines220may be a single module. Search engine122may be a portion of a larger program, such as a document management program, may be a separate program or may be implemented according to any suitable programming architecture. In one embodiment, the processes of search engine122may be distributed across multiple computer systems. Furthermore, while inFIG.3, index124is illustrated as a single index, index124may comprise a set of smaller indexes. For example, a separate index can be used by each indexing engine.

FIG.4depicts a diagrammatic representation of one embodiment of regions or fields for a portion of index124. Index124includes a list of some or all objects107in repository105(FIG.1), each identified by a unique identifier301(also referred to as object ID). Index124further includes a set of metadata regions300(also referred to as metadata fields). A metadata field300may include more than one entry for an object. The metadata fields can each have associated values in value storage locations within storage unit118. In other embodiments, the values may be discarded. The index may include a list of dictionary terms contained in the metadata values of the object and pointers to where the metadata values corresponding to the field are stored. Index124may also include other regions for an object, such as a text region302. Text region302may, for example, include a list of terms in the text of an object.

While shown as a single index, index124may be partitioned. In index partitioning, in one embodiment, the index of objects in repository105may be split into multiple indexes such that some objects are listed in one index partition, while other objects are listed in the other index partitions. Index partitioning may also reduce resource usage and search time. Furthermore, separate indexes may be maintained for metadata and text and/or different metadata regions or fields. Index124can be stored according to any suitable storage scheme.

FIG.5depicts a diagrammatic representation of one embodiment of an indexing engine220to maintain index124. In this embodiment, indexing engine220can include an indexing controller305, a metadata update component310, a text update component315, and a derived metadata list520. In this embodiment, index124is maintained as a separate metadata index312, which contains metadata for objects in repository105, and text index314, which contains content text from objects in repository105.

Indexing controller305receives indexing requests (e.g., from a distributor, another application or other source). An indexing request received at the indexing controller305may include an instruction to add an object, delete an object, modify an object or replace an object in index124. Such an indexing request may also include the information to be added or changed, such as the full text content to be indexed and the associated metadata for the object. An indexing request may also contain derived metadata.

The text (derived text or full text content) of an indexing request may be a text file. It could be data exported from a database or other information system. Commonly, the text is the human-readable information within a document composed on a computer. In this scenario, a file such as a Microsoft Word document would be analyzed by a filtering step to extract the text, which can be stripped of unnecessary information such as fonts, styles, or page layout information.

The metadata portion of an indexing request may specifically be provided by an application providing the indexing request. This might be data such as an identifier for the object, the date or time it was first added to the system, or the identity of the user who manages the object.

Derived metadata can include metadata inferred from the text content. For example, the filter or code that extracts the text from a PowerPoint presentation might also create metadata about the presentation. In this example, the generated metadata may include the number of slides in the presentation, the title of the file, the name of the presentation author stored in the PowerPoint file, or the size of paper the presentation was designed to print on. More complex examples of derived metadata might include statistical analysis to generate a list of keyword or key concepts in the document, determining the subject person or company of the text, sentiment analysis (the positive or negative tone of the text), or identification of the language in which the text is written. Derived metadata may also include data inferred from processing an object. For example, in processing a PowerPoint presentation, derived metadata may include a timestamp of the time the PowerPoint was processed or the location where the PowerPoint presentation was processed.

In one embodiment, a derived metadata list520may be a record of any known metadata fields that have been derived from the text which is indexed. In one embodiment, this list may be consumed by metadata update component310of indexing engine220to provide guidance on whether a given metadata field must be replaced or deleted as if it were part of the text data.

An indexing engine can receive an indexing request510from an application, distributor or other source. Indexing request510specifies an operation to be taken on index124for an object and any metadata or text for that action. For context, an application that generates an indexing request may be a corporate document management system, a web site with a search capability such as an online store, or a desktop search program for email.

According to one embodiment, for example, an indexing request can take the form of an indexing object that includes a unique identification for an object, an operation, the metadata or text regions affected and the metadata and/or text for the index. By way of example, but not limitation, indexing operations may include adding, replacing, modifying and deleting information in the index, or combinations thereof. The following provides some exemplary operations that may be included in indexing requests.

AddOrReplace: this operation can be used to create new objects in the index. According to one embodiment, if the object does not exist, it will be created, but if an entry with the same object identification exists, then it will be completely replaced with the new data, equivalent to a delete and add.

AddOrReplace: this function may distinguish between content and metadata. If an object already exists, and metadata only is provided, the existing full text content is retained.

AddOrModify: this operation will update an existing object, or create a new object if it does not already exist. When modifying an existing object, only the provided content and metadata are updated. Any metadata regions that already exist which are not specified in the AddOrModify command will be left intact.

Delete: this operation will remove an object from the index, including both the metadata and the content.

Indexing controller305, according to one embodiment, is a component which interprets the indexing request to determine how it should be processed. Indexing controller305can identify whether a text indexing command exists, and, if so, send the command with the necessary parameters to the text update component315. Indexing controller305can likewise determine if any metadata indexing operations are required, and if so, send the command with necessary parameters to the metadata update component310.

Text update component315is responsible for processing requests to index full text content. This may include tasks such as maintaining a dictionary of search terms, maintaining the internal search data structures, and updating the storage representation of the text portion of the search index in memory or on disk as appropriate. Text update component315may support instructions such as Add an Object, Replace an Object, or Delete an Object. Non-limiting examples of instructions supported by text update component315are further described below.

Metadata update component310is responsible for processing requests to index metadata312associated with an object in index124. This may include building and maintaining dictionaries of search terms, maintaining internal search data structures, and updating the representation of the metadata portion of the search index in memory or on disk as appropriate. Metadata update component310may support instructions such as Add an Object, Replace an Object, or Delete an Object. Non-limiting examples of instructions supported by metadata update component310are further described below.

As an example, in one embodiment, indexing request510sent by distributor210to indexing engine220may contain an instruction to add an object of a text type. Indexing request510may be received by indexing controller305of indexing engine220. Referring toFIG.6, indexing controller305may operate to parse and analyze indexing request510(step605) and determine what, if any, type of command is in indexing request510(step610). Indexing request510may contain a text indexing command, a metadata indexing command, or both. Indexing engine220may further comprise text update component315and metadata update component310coupled to indexing controller305. In one embodiment, when indexing controller305detects that indexing request510contains a metadata indexing command, indexing controller305may access derived metadata list520and determine whether the metadata indexing command applies to or otherwise affects any derived metadata in index124that should be protected from change (step615). As will be explained below, this may involve using a pattern matching technique to identify any metadata field name in index124that is affected by the metadata indexing command and that matches a derived metadata field from derived metadata list520. Indexing controller305may then forward the metadata indexing command (step620) along with any metadata field name thus identified to metadata update component310. In one embodiment, step615may be performed by metadata update component310after receiving a metadata indexing command from indexing controller305(step620). In this embodiment, indexing controller305may determine what, if any, type of command is in indexing request510(step610) and forward the indexing command(s) to metadata update component310, to text update component315, or both. Metadata update component310, in turn, may access derived metadata list520and determine whether the metadata indexing command applies to or otherwise affects any derived metadata in index124that should be protected from change (step615).

In one embodiment, index124comprises a set of indices including metadata index312and text index314. Metadata update component310may retain derived metadata, identified as being protected using derived metadata list520, in metadata index312and execute the metadata indexing command to update metadata index312without changing the protected derived metadata (step630). Likewise, metadata update component310can execute metadata indexing commands to update the derived metadata fields in metadata index312even though the indexing request510only contains a request to update text index314.

Non-limiting examples of instructions supported by metadata update component310and text update component315will now be described below.

To replace a text object, indexing request510may contain an instruction to replace only the text of an object. In one embodiment, a pre-processing step, such as processing shown inFIG.2, may analyze the text to obtain derived metadata associated with the object, and include this derived metadata in indexing request510. Indexing controller305may then send the instruction to both text update component315and metadata update component310. Text update component315can update text index314with the new data. Metadata update component310determines that this is a text update request. Metadata update component310may examine derived metadata list520and may filter the available metadata in metadata index312against derived metadata list520, and replace only the metadata that may be derived from the text of the object.

As an example, indexing request510may contain an instruction to delete only the text of an object. In one embodiment, indexing controller305may send a command to text update component315to delete the text of the object from text index314. Indexing controller305may also send a command to metadata update component310to delete the text of the object. Metadata update component310reads derived metadata list520and deletes the values for each of the derived metadata fields associated with the object if they exist in metadata index312.

As another example, indexing request510may contain an instruction to replace all the metadata for an object. In one embodiment, indexing controller305may send a command to metadata update component310, along with necessary parameters, to replace only the metadata for the object. Metadata update component310may compare the existing metadata in metadata index312against derived metadata list520. According to one embodiment, metadata fields specified in derived metadata list520are considered protected. Consequently, metadata update component310will not erase or modify values in metadata index312that have been identified per derived metadata list520as being associated with the protected metadata fields.

As another example, indexing request510may contain an instruction to delete only the metadata of an object. Indexing controller305may send a command to metadata update component310to delete only the metadata of the object. According to one embodiment, metadata update component310reads derived metadata list520and deletes values for all metadata fields in metadata index312for the particular object except for the metadata fields identified per derived metadata list520as being protected.

In one embodiment, pattern matching may be used to identify derived metadata fields. For example, a value of ‘OTDoc*’ in derived metadata list520may ensure that any metadata field name that starts with the characters ‘OTDoc’ may be considered to be derived metadata. A derived metadata field name of ‘OTDoc*!OTDocCAR’ indicates that any metadata field name that begins with OTDoc is a derived field name except for the field named OTDocCAR. The rules and patterns for identifying field names which meet the criteria for derived metadata may be made arbitrarily complex. For example, suppose an entity must protect a large amount of documents related to an ongoing legal proceeding for the next 60 days. Derived data fields containing “CourtCaseDoc” may be searched for and prevented from being changed for the duration of the identified 60 days.

One advantage of pattern matching is that a user can define many derived metadata field names with a few patterns, which may be especially useful when the metadata field names are not explicitly known (e.g., when the system is first configured).

Further, derived metadata list520may be provided by a number of different mechanisms. In one embodiment, derived metadata list520may be generated from values stored in a configuration file. In another embodiment, each metadata item for each object might be marked in a way that identifies it as derived metadata. Essentially, the way that the derived metadata list is stored can be distributed in various ways, and it does not need to be the same list for each partition or for each object in the index.

Derived metadata list520may be defined and maintained in various ways. Non-limiting examples may include:Use a programming interface (API) to define and manage the list.Identify derived metadata values in an indexing request.Define a known list of derived metadata values within the software (e.g., ‘hard coded’).Manage a list of derived metadata in an external database or application, with which the search index components can interact to obtain the derived metadata values.

The above list is shown by way of example and is not exhaustive.

Derived metadata list520may be retained by the search components in persistent storage. In one embodiment, the list may be recreated each time the search components are started. Examples of locations in which the derived metadata list520can be retained include a configuration file, a distributed cache system, an external system, or within the search index itself.

In one embodiment, the analysis of the text to derive metadata occurs in a step prior to the generation of an indexing request. In another embodiment, deriving metadata from the text occurs at other locations in the indexing process. For example, the Indexing controller may contain or control functional components that perform the analysis of text to derive metadata.

For illustration purposes, Table 1 below contains examples of search index preparation steps that may generate derived metadata. This is information that may be derived primarily from text content, and may not be replaced when a “Replace Metadata” indexing command is received. In one example, when using Language Detection, a derived metadata field may be called “OTLanguage” with a value being “English.”

TABLE 1Types of DerivedSample Values for DerivedMetadata FieldsPurposeMetadata FieldsFormatAnalyze the file format, mime types, fileMicrosoft WordIdentificationname extensions and other cues toAdobe Acrobat PDFaccurately determine the type of a file.MetadataApply a filter that can parse a knownWord: Author, date savedExtractionfile type to extract metadata that isJPEG: Camera, imageincluded in the file.pixels, date photographedLanguageAnalyze the text to guess whichEnglishDetectionlanguage was used to write the contentGerman 60%with a confidence score.SentimentApply language rules to determinePositive 30%Analysiswhether text is positive, negative orneutral.Keywords/Use semantic or statistical methods toFinancial servicesConceptsidentify keywords or concepts that theMortgage defaultstext relates to.Entity ExtractionApply language rules and known lists toGeorge Bushidentify significant people, places orChristmasevents in the content.Chicago, ILGeotaggingCreate a list of the geospatial+27.5916 + 086.5640 +coordinates that represent the most8850/+ 40.6894 −likely locales in the content or074.0447/metadata.ClassificationApply business rules and patterns toContractidentify the most likely classification ofCustomer complaintthe record.Census formSimilarityGenerate codes that can be used to817728fe34help match documents that are8992783476identical or have similar sections.File InformationAttributes of the file, such as the fileSize: 899458name and size.Name: test.doc

The embodiments disclosed herein are advantageous over previous solutions. For optimization reasons, requests to replace only the metadata or replace only the text content for an object may be given to the search Index. One previous solution involves incorporating derived metadata into the text portion of the search Index. For example, derived classification values may be appended to the text. The problem that arises in this previous solution is that a user may not be able to search specifically in the metadata field and this reduces the accuracy and capabilities of the search index.

Another previous solution is to replace both the text and metadata associated with an object at once. Replacing text and metadata at once loses the performance capability of the search index. Replacement is slower since both text and metadata must be replaced for the object. As a result, performance optimization is not possible.

By allowing for the replacement of the metadata portion associated with an object, without the replacement of the text portion associated with the object, without corrupting the derived metadata, embodiments can provide a reduction of the load on the computer which performs the indexing tasks, a reduction of load on the computer which analyzes the text to derive metadata, and a reduction in the amount of information an attached application must provide to the indexing process for replacement operations.

The embodiment ofFIG.5is provided by way of example. Indexing engine220may include any number of other modules to update and search an index. Indexing engine220may be a portion of a larger program, such as a document management program, may be a separate program or may be implemented according to any suitable programming architecture. In one embodiment, the processes of indexing engine220may be distributed across multiple computer systems. Other alternative embodiments are also possible.

Although the invention has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the invention. The description herein of illustrated embodiments of the invention, including the description in the Abstract and Summary, is not intended to be exhaustive or to limit the invention to the precise forms disclosed herein (and in particular, the inclusion of any particular embodiment, feature or function within the Abstract or Summary is not intended to limit the scope of the invention to such embodiment, feature or function). Rather, the description is intended to describe illustrative embodiments, features and functions in order to provide a person of ordinary skill in the art context to understand the invention without limiting the invention to any particularly described embodiment, feature or function, including any such embodiment feature or function described in the Abstract or Summary. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the invention in light of the foregoing description of illustrated embodiments of the invention and are to be included within the spirit and scope of the invention. Thus, while the invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the invention.

Reference throughout this specification to “one embodiment”, “an embodiment”, or “a specific embodiment” or similar terminology means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment and may not necessarily be present in all embodiments. Thus, respective appearances of the phrases “in one embodiment”, “in an embodiment”, or “in a specific embodiment” or similar terminology in various places throughout this specification are not necessarily referring to the same embodiment. Furthermore, the particular features, structures, or characteristics of any particular embodiment may be combined in any suitable manner with one or more other embodiments. It is to be understood that other variations and modifications of the embodiments described and illustrated herein are possible in light of the teachings herein and are to be considered as part of the spirit and scope of the invention.

In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment may be able to be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, components, systems, materials, or operations are not specifically shown or described in detail to avoid obscuring aspects of embodiments of the invention. While the invention may be illustrated by using a particular embodiment, this is not and does not limit the invention to any particular embodiment and a person of ordinary skill in the art will recognize that additional embodiments are readily understandable and are a part of this invention.

Embodiments discussed herein can be implemented in a computer communicatively coupled to a network (for example, the Internet), another computer, or in a standalone computer. As is known to those skilled in the art, a suitable computer can include a central processing unit (“CPU”), at least one read-only memory (“ROM”), at least one random access memory (“RAM”), at least one hard drive (“HD”), and one or more input/output (“I/O”) device(s). The I/O devices can include a keyboard, monitor, printer, electronic pointing device (for example, mouse, trackball, stylus, touch pad, etc.), or the like.

ROM, RAM, and HD are computer memories for storing computer-executable instructions executable by the CPU or capable of being compiled or interpreted to be executable by the CPU. Suitable computer-executable instructions may reside on a computer readable medium (e.g., ROM, RAM, and/or HD), hardware circuitry or the like, or any combination thereof. Within this disclosure, the term “computer readable medium” is not limited to ROM, RAM, and HD and can include any type of data storage medium that can be read by a processor. For example, a computer-readable medium may refer to a data cartridge, a data backup magnetic tape, a floppy diskette, a flash memory drive, an optical data storage drive, a CD-ROM, ROM, RAM, HD, or the like. The processes described herein may be implemented in suitable computer-executable instructions that may reside on a computer readable medium (for example, a disk, CD-ROM, a memory, etc.). Alternatively, the computer-executable instructions may be stored as software code components on a direct access storage device array, magnetic tape, floppy diskette, optical storage device, or other appropriate computer-readable medium or storage device.

Any suitable programming language can be used to implement the routines, methods or programs of embodiments of the invention described herein, including C, C++, Java, JavaScript, HTML, or any other programming or scripting code, etc. Other software/hardware/network architectures may be used. For example, the functions of the disclosed embodiments may be implemented on one computer or shared/distributed among two or more computers in or across a network. Communications between computers implementing embodiments can be accomplished using any electronic, optical, radio frequency signals, or other suitable methods and tools of communication in compliance with known network protocols.

Different programming techniques can be employed such as procedural or object oriented. Any particular routine can execute on a single computer processing device or multiple computer processing devices, a single computer processor or multiple computer processors. Data may be stored in a single storage medium or distributed through multiple storage mediums, and may reside in a single database or multiple databases (or other data storage techniques). Although the steps, operations, or computations may be presented in a specific order, this order may be changed in different embodiments. In some embodiments, to the extent multiple steps are shown as sequential in this specification, some combination of such steps in alternative embodiments may be performed at the same time. The sequence of operations described herein can be interrupted, suspended, or otherwise controlled by another process, such as an operating system, kernel, etc. The routines can operate in an operating system environment or as stand-alone routines. Functions, routines, methods, steps and operations described herein can be performed in hardware, software, firmware or any combination thereof.

Embodiments described herein can be implemented in the form of control logic in software or hardware or a combination of both. The control logic may be stored in an information storage medium, such as a computer-readable medium, as a plurality of instructions adapted to direct an information processing device to perform a set of steps disclosed in the various embodiments. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will appreciate other ways and/or methods to implement the invention.

It is also within the spirit and scope of the invention to implement in software programming or code an of the steps, operations, methods, routines or portions thereof described herein, where such software programming or code can be stored in a computer-readable medium and can be operated on by a processor to permit a computer to perform any of the steps, operations, methods, routines or portions thereof described herein. The invention may be implemented by using software programming or code in one or more digital computers, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nanoengineered systems, components and mechanisms may be used. In general, the functions of the invention can be achieved by any means as is known in the art. For example, distributed, or networked systems, components and circuits can be used. In another example, communication or transfer (or otherwise moving from one place to another) of data may be wired, wireless, or by any other means.

A “computer-readable medium” may be any medium that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, system or device. The computer readable medium can be, by way of example only but not by limitation, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, system, device, propagation medium, or computer memory. Such computer-readable medium shall generally be machine readable and include software programming or code that can be human readable (e.g., source code) or machine readable (e.g., object code). Examples of non-transitory computer-readable media can include random access memories, read-only memories, hard drives, data cartridges, magnetic tapes, floppy diskettes, flash memory drives, optical data storage devices, compact-disc read-only memories, and other appropriate computer memories and data storage devices. In an illustrative embodiment, some or all of the software components may reside on a single server computer or on any combination of separate server computers. As one skilled in the art can appreciate, a computer program product implementing an embodiment disclosed herein may comprise one or more non-transitory computer readable media storing computer instructions translatable by one or more processors in a computing environment.

A “processor” includes any [,] hardware system, mechanism or component that processes data, signals or other information. A processor can include a system with a central processing unit, multiple processing units, dedicated circuitry for achieving functionality, or other systems. Processing need not be limited to a geographic location, or have temporal limitations. For example, a processor can perform its functions in “real-time,” “offline,” in a “batch mode,” etc. Portions of processing can be performed at different times and at different locations, by different (or the same) processing systems.

It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. Additionally, any signal arrows in the drawings/figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted.

As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” or any other variation thereof, are intended to cover a non-exclusive inclusion. For example, a process, product, article, or apparatus that comprises a list of elements is not necessarily limited to only those elements but may include other elements not expressly listed or inherent to such process, product, article, or apparatus.

Furthermore, the term “or” as used herein is generally intended to mean “and/or” unless otherwise indicated. For example, a condition A or B is satisfied by any one of the following: A is true (or present) and B is false (or not present), A is false (or not present) and B is true (or present), and both A and B are true (or present). As used herein, including the claims that follow, a term preceded by “a” or “an” (and “the” when antecedent basis is “a” or “an”) includes both singular and plural of such term, unless clearly indicated within the claim otherwise (i.e., that the reference “a” or “an” clearly indicates only the singular or only the plural). Also, as used in the description herein and throughout the claims that follow, the meaning of “in” includes “in” and “on” unless the context clearly dictates otherwise. The scope of the present disclosure should be determined by the following claims and their legal equivalents.