Knowledge Graph Generation for Data Warehouse

Query language statements are generated from natural language statements using a knowledge graph representing one or more databases. The knowledge graph is obtained by creating nodes representing tables and operations referenced by queries to the databases. The data of the databases is evaluated to identify entities and dimensions of entities from among the nodes. The entities are assigned human-understandable labels by an LLM. A natural language statement is converted to a knowledge graph language (KGL) statement and references in the KGL statement are replaced with references to entities in the knowledge graph. The KGL statement is then programmatically converted to a database language statement.

BACKGROUND

Field of the Invention

This invention relates to generating knowledge graphs for data warehouse.

BACKGROUND OF THE INVENTION

A modern business has abundant data describing every aspect of the business and the customers of the business. A collection of such data is often referred to as a data warehouse or a data lake. A data warehouse may be conveniently stored and accessed using a cloud-based database provider. Although data is abundant and highly available, it may still be difficult for decision makers to utilize the data.

It would be an advancement in the art to provide an improved approach for facilitating usage of data in a data warehouse.

DETAILED DESCRIPTION

Referring toFIG.1, a network environment100may include a server system102. The server system102may include one or more servers implementing a cloud computing platform or on-premise computing facility. The server system102may implement or access a plurality of databases104that collectively implement a data warehouse for one or more objects. The databases104may be hosted by a cloud database platform such as SNOWFLAKE, REDSHIFT, or the like. Each database104may correspond to a different software tool, business unit of an enterprise, geographic region, or other division.

Each database104may have a schema106that defines the logical relationship between tables108of the database104. Each table108may include such information as a table identifier110, a set of keys112and values114for each key112. Each table108may include multiple columns, such as two or more columns in the form of a column of keys112and one or more columns of values for the keys112.

Each database104may be implemented as a structured query language (SQL) database and the server system102may be implemented as an SQL server. Other types of databases may be used in a like manner, such as MYSQL, ORACLE database, IBM DB2, AMAZON RELATIONAL DATABASE SERVICE (RDS), POSTGRE SQL, or the like. SQL is referred to the throughout the following description with the understanding that any other type of database and database language may be used in a like manner.

Users at a user computing device116may submit queries118to the server system102by means of a network120, such as a local area network (LAN), wide area network (WAN), the Internet, or other type of network. Queries may also be submitted by software, such as front-end software for executing ecommerce transactions, interfacing with a client application, or performing other functions. The server system102processes the queries with respect to one or more databases104referenced by the query and returns a response to the user computing device116.

Referring toFIG.2, a query118may be represented as a query tree200. The illustrated query tree200is exemplary only and any type of query tree known in the art may be used to represent a query118. A query tree200may include a root node202, which may represent a command included in the query. The query tree200may specify one or more sources204for data to be processed in the query. A source204may specify one or more database operations206to be performed with respect to one or more tables208and/or the result of another database operation206. For example, the database operations206may be UNION, JOIN, IMPLICIT or other relational algebraic operation to be performed with respect to two or more tables208.

The query tree200may one or more operations210to be performed with respect to the one or more sources204. The operations210may include mathematical (addition, subtraction, multiplication, division, etc.), Boolean, or other operations to be performed with respect to the one or more sources204. One or more inputs to each operation210may be one of the one or more sources204or the result of another operation210. The query tree200may specify results212that identify columns of the results of the operations210that are to be provided as the output of the query118. The results212may include names214that specify one or both of columns or values that are to be selected as the result and a location at which results of the operations210are to be stored.

FIG.3illustrates a method300that may be used to create an initial network of nodes and connections that are used to conduct a knowledge graph as described in more detail below. The method300and the other methods disclosed herein may be executed on the server system102, some other server system, or a combination of the two.

The method300includes collecting302queries with respect to the databases104, such as databases104belonging to a common data warehouse of one or more objects. The method300may be performed continuously or periodically such that step302includes collecting queries118submitted to the server system102since a last iteration of the method300or within a time window (e.g., one month, one year, etc.) preceding execution of the method300.

The method300may include scoring304queries according to frequency of occurrence. For example, queries collected at step302may be grouped together as being identical to one another. The number of queries in a group may then be used as the score for the queries of the group. Other factors may also contribute to the score, such as a source of the queries. Queries from software such as Tableau may be vetted and of known importance and may be given greater weight, e.g., a single query may be counted as more than one query when counting the number of occurrences of a query.

The method300may include creating306initial nodes for a knowledge graph from the queries collected at step302. For example, for each query (which may represent a group of queries), the nodes created for the query may include nodes representing some or all of:Each table referenced in the query.The result of a database operation206with respect to one or more tables, e.g., a result of a JOIN, UNION, or other relational algebraic expression.The result of any logical or mathematical operation210of the query.One of the final results of the query.The entire query.

Each node may be represented by a data structure describing the object (table, operation, result, query, etc.) represented by the node. For example, a node representing a table may include the table identifier110of the table. A node representing the operation (Ship Date—Order Date) may include data referencing a Ship Date table, an Order Date table, and the mathematical subtraction operation. The Ship Date table and Order Date table themselves may represent the result of a database operation, such as a JOIN operation that itself may be represented as a node.

The method300may include creating node connections from the queries selected at step302. For example, connections between nodes may have some or all of the following types:A connection may be created between node representing a table and a node representing a result of an operation206,210performed with respect to the table.A connection may be created between a node representing an object (Table or result of operation with respect to one or more tables) and one or more other objects that represents an operation206,210performed with respect to the object and the one or more other objects.A connection may be created between node representing the result of a first operation206,210and a node representing the result of a second operation206,210that takes a result of the first operation206,210as an input.A connection between a node representing a result of an operation206,210of a query and the final result of the query.A connection between a node representing a part (referenced table, result of an operation206,210) of a query and a node representing the entire query.

Each connection may be represented by a data structure that includes identifiers of the nodes connected by the connection and data describing the type of the connection. Note that a table may be referenced by multiple queries. Accordingly, connections created at step308may likewise connect nodes created from multiple queries.

Each node and connection may have a score assigned310thereto based on the scores from step304. For example, for a table, the score may correspond to the total number of queries referencing the table. For nodes and connections created from queries grouped together as being identical, the nodes and connections may have scores assigned thereto equal to the number of queries in the group.

Referring toFIG.4A, the nodes, connections, and scores assigned to nodes and connections in the method300constitutes an initial version of a knowledge graph.FIG.4Aillustrates a method400for augmenting and refining the initial knowledge graph to obtain a final knowledge graph.

The method400may include consolidating402one or both of the nodes and connections of the initial version of the knowledge graph. For example, step402may include identifying queries that are sufficiently identical in terms of structure of operations206,210. Step402may include identifying parts of queries that are identical in terms of structures of operations206,210. For example, patterns of nodes and connections that are similar may be identified. As noted above, each node includes information indicating the table, operation206,210, or query represented by the node and each connection includes information describing the type of the connection. Accordingly, groups of identical nodes with identical connections may be identified and consolidated.

For example, referring toFIG.4B, suppose a first group of nodes A, B, and C include connections AB between nodes A and B and AC between nodes A and C. Nodes A, B, and C could represent any number of operations206,210or queries. Suppose node B has connections to nodes T1and T2and node C has connections to nodes T3and T4, where T1, T2, T3, and T4represent tables. A second identical group of nodes A, B, and C has the same connections AB and AC but node B is connected to nodes T5and T6and node C is connected to nodes T7and T8, where T5, T6, T7, and T8represent tables. The two groups of nodes A, B, and C therefore represent two queries having identical structures but referencing different tables. For example, a query used to generate monthly reports may be issued repeatedly but reference one or more different tables corresponding to the month for which the report is generated. Accordingly, all such queries may be represented as a single node in the knowledge graph even though not identical.

FIG.4Cillustrates the result of consolidation in which the groups of identical nodes and connections are represented as a single group of nodes. Connections to the group of identical nodes and connections that are not identical will then connect to the single group of nodes. Tables T1, T2, T5, and T6are connected to node B of the consolidated group and tables T3, T7, T4, and T6are connected to node C of the consolidated group. The scores of the consolidated group may also be combined. For example, the score of nodes A, B, and C and connections AB and BC may be the sum of the scores of nodes A, B, and C in the two original groups. Non-identical nodes representing operations206,210may be handled in the same way as the non-identical tables in the above example: the non-identical nodes will remain connected to the same node in the consolidated nodes.

As an example of the approach described above with respect toFIGS.4B and4C, consider nodes representing the following operations “sum(case when moy=1 then 1 else 0)”, “sum(case when moy=2 then 1 else 0),” and “sum(case when moy=3 then 1 else 0)”, where “moy” refers to the month of the year. These nodes all have identical structures with different referenced data, e.g., referring to different months. These nodes may therefore be consolidated402into a single node having nodes for each month of the year (1-12).

The method400may include performing404statistical analysis of the underlying data and determining406relationship information based on the statistical analysis. For example, for a node representing a table, statistical information concerning the values in the table may be determined. For example, the statistical information may include whether values in a column of the table are unique relative to one another and possibly unique relative to values in other columns of the table or other tables.

In a first example, each customer identifier in a customer identifier table may be unique whereas different customer identifiers may have the same birth date from a birth date table, thereby indicating that the birth date table is a dimension of the customer identifier table.

In a second example, if there is a JOIN operation between a key of a first table and a column of a second table, the node representing the first table may be deemed to be a key node whereas the second table is deemed a dimension node of the key node.

In a third example, in a table including order identifiers, all of the order identifiers may be unique whereas other values such as dates, states, zip codes, and product identifiers, price, etc. may be the same in multiple rows. Accordingly, the order identifier may be chosen to be a key node whereas tables of dates, states, zip codes, product identifiers, price, etc. may be deemed dimension nodes having a dimension relationship to the key node.

In a fourth example, a node may represent a join of an order identifier table, a sold date table, and item identifier table. Since the sold date for each item in the same order is the same, the date, as represented by the date table, may be deemed a dimension of the order identifier, as represented by the order identifier table.

In a fifth example, or a given combination of an order identifier and item identifier (i.e., the same order), all prices are constant. Accordingly, for a node representing the combination (e.g., a joint of columns or tables for the order identifier and item identifier), the price, as represented by a price table, may be a dimension. The combination may be identified due to one or more queries performing a JOIN on two tables or columns of tables.

Many databases have a schema106, such as databases generated by or provided by a software as a service (SaaS) company, such as SALESFORCE, MARQETA, SEGMENT, or the like. The schema106may indicate the meaning of data stored in tables and the relationships between tables, such as the meaning of the data stored in each column of each table. Accordingly, the method400may include determining408relationships from any schemas106for the databases104hosting tables108referenced by the initial knowledge graph, including which nodes are key nodes according to the schemas106and which nodes are dimension nodes to a given key node.

The initial knowledge graph may then be augmented410with the relationship information from one or both of steps406and408. For example, a connection between a key node and a dimension node as determined at step406and408may be augmented with information indicating that the connection represents a dimension relationship and the direction of the relationship, i.e., which node is the dimension node and which node is the key node. Other type of relationships, such as between key nodes, may be a “one-to-many” relationship, such as between a key node representing a customer identifier and a key node representing customer orders since a single customer may have multiple orders.

FIG.5illustrates a method500for generating an entity graph for final knowledge graph resulting from the method400. The entity graph may be considered as a human intelligible overlay or subset for the knowledge graph. The entity graph is also formed to include entities likely to be of importance to decision makers.

The entity graph may be derived from the final knowledge graph by pruning502connections with low statistical significance. As noted above, connections may be assigned a score based on the number of queries represented by the connection. Accordingly, connections with a low score are not of high interest to users of the databases104and may be pruned. Connections with low statistical significance may be those with a score below a predetermined threshold. Connections with low statistical significance may be X percent of the connections with the lowest scores, where X is a predetermined value, such as a value between 0 and 90, 0 and 75, 0 and 50, or 0 and 25.

The method500may include selecting 504 nodes of the knowledge graph as entities of the entity graph according to evaluation of the connections between nodes of the knowledge graph and adding 506 nodes from the knowledge graph to the entities as dimensions of the entities according to connections of the knowledge graph. For example, a node representing a customer identifier may be an entity whereas nodes representing attributes of a customer (address, state, orders, etc.) are added as dimensions. In another example, a node representing an order identifier node may be selected as an entity whereas nodes representing tables for purchase date, ship date, item identifiers, purchase price, or other attributes of an order are added as dimensions of the entity.

In one example, key nodes are selected as entities for the entity graph and dimension nodes are added to the entities as dimensions. In another example, only a subset of key nodes are selected as entities, such as the top Y with the highest score, where X is a predetermined value, such as a value between 10 and 20, 20 and 50, 50 and 80, or 80 and 100.

For each entity created for a key node, dimensions may be added to the entity for each dimension node of the knowledge graph connected to the entity. Connections between entities may be retained in the entity graph, i.e., connections between key nodes of the knowledge graph.

To further enhance usability of the entity graph, entities and possibly dimensions may be processed508by a logical learning model (LLM) to assign human-intelligible labels to the entities of the entity graph. The LLM may be an LLM trained to perform the labeling of step508or may be a general purpose LLM such as CHATGPT, BARD, or the like.

For example, for an entity, the LLM may receive the name of the object in the databases104(e.g., table identifier110). The LLM may additionally or alternatively receive underlying data for the entity and possibly the objects represented by dimensions of the entity, such as the contents of the table represented by the entity or dimension of the entity, the results of an operation represented by the entity or dimension of the entity, or other information.

The LLM outputs a human-intelligible label based on the inputs that captures the concept represented by the entity. For example, a database table108for customer identifiers may be labeled CK_customer_db and have dimensions such as 2022_order_db, NA_address_db, or any arbitrary names. The names of tables represented by entities and dimensions may even be arbitrary codes, e.g., GX_2023_CM. By evaluating the identifiers, the underlying data (e.g., orders, addresses, birth date, and other human-related information), the LLM may derive that a table can be represented by the label “customer.”

In some embodiments, the LLM may provide superior results if the entity graph in its entirety, or at least groups of multiple entities and their corresponding dimensions, is submitted to the LLM with the task of assigning unique names to each entity (or possibly to each entity and each dimension).

Referring toFIG.6, the method500converts the knowledge graph consisting of nodes600and connections between nodes to an entity graph that includes entities602representing significant concepts represented in the databases104along with dimensions604of each entity602that are descriptive of the concept represented by the entity602. As described above, the entities602and dimensions604are selected based on actual queries submitted by users of the databases104. The entities602of and dimensions604of the entity graph further have human-intelligible labels that are easy to remember or guess by a user without expert knowledge of the underlying databases104. Connections between nodes selected as entities (e.g., other than dimensions) may also be retained, such as a one-to-many connection described above or any of the other types of connections that may exist between nodes of the knowledge graph.

Referring toFIG.7, the queries118submitted to the server system102for execution with respect to the databases104must be written in a database language, such as SQL in order to be intelligible by the server system102, such as by a database server executing on the server system10. However, a database language such as SQL is not intuitive and requires extensive knowledge that is not possessed by many decision makers.

The knowledge graph generated according to the approach described with respect toFIGS.1to6may be accessed using a knowledge graph language (KGL). The KGL may be a language that both (a) uses operators, variables, and syntax that mimic human speech and (b) can be programmatically translated into an SQL query, i.e., in a fixed and predictable manner without ambiguity as to meaning of terms used in a KGL statement. As such, the KGL functions as an intermediate language between the ambiguity of natural language and the complex technical requirements of an SQL query.

For example, a user may wish for information about “customers who were born in Texas.” This natural language statement can be readily expressed by the user in KGL as “customers where CurrentAddressState=‘TX.’” As another example, a user may wish for information about “Customers who have more than one order.” This natural language statement can be expressed in KGL as “customers where count(orders)>1.”

The KGL may have at least some of the following properties:Variables do not require special declarations.A source of the requested information can be expressed in a position or other syntax used to recite the subject of a natural language is expressed in a given language.An operation may be specified using a prepositional phrase including a preposition indicating an operation (e.g., “where,” “who,” or other interrogative) and a subject of the prepositional phrase indicating an argument to the operation (e.g., state=Texas, count(orders)>1).Database operations such as JOIN, UNION, IMPLICIT, EXPLICIT are either transparent to the user or are represented using natural language conjunctions, such as “and, “or,” or the like.An operation may be specified for one or more entity names using conventional mathematical symbols (+, −, *, /), conventional mathematical function names (exp, sin, cos, etc.), conventional statistical functions (count, max, min, mean, median, standard deviation), or Boolean operators (AND, OR, XOR, NOT),

The KGL may be constrained with respect to a knowledge graph, such that variables included in a KGL statement are constrained to be entities602or dimensions604of the entity graph. However, inasmuch as the entities602and dimensions604are assigned human-intelligible labels, usage of the knowledge graph is made simple. For example, a KGL editor may provide a graphical representation of the entity graph in the form of a directory structure or other graphical representation of the hierarchical structure of the entity graph. A user may therefore select view entities in the entity graph and select therefrom. Likewise, interface aids such as autocomplete may provide suggestions for entities in the entity graph in response to a string input by a user. A search interface to the entity graph may further enable a user to search for potentially relevant entities and dimensions from the entity graph based on a natural language search string. For example, a search engine may enable a user search for an entity matching a natural language search string based on lexical and/or semantic similarity to labels of entities, the labels of the dimensions of entities in the entity graph, and/or a combination thereof. The interface aids may further enable a user to invoke display of the dimensions of an entity in the entity graph.

FIG.7illustrates a method700that may be executed to interpret a KGL statement received from a user. The method700may include receiving702a KGL statement. The KGL statement may be parsed to extract704the names of entities of the entity graph. The KGL statement may be further parsed to extract706relationship references from the KGL statement. The relationship references indicate the role of the entities in the KGL statement. For example, in the example “customers where state=Texas,” the relationship of “customers” is being first recited of all the recited elements. The relationship of “state=Texas” is the reference following the interrogative “where” following the first element.

Each entity references identified at step704may be translated708into database language statements, e.g., SQL statements (“entity statements”). For example, if an entity represents a table108, a database language statements referencing the table108may be generated. As noted above, a node in the knowledge graph may represent the result of a database operation206or operation210performed with respect to one or more tables108or the result of another operation206or operation210. Accordingly, a database language statement may be generated that invokes execution one or more operations206or operations210with respect to one or more tables108represented by an entity referenced in the KGL statement.

The relationships identified at step706may be translated710into database language statements implementing an operation206and/or operation210corresponding to the recited relationships (“relationship statement”).

The method700may then include generating712a database query. For example, the entity statements and relationship statements may be combined along with other statements required by the database language to form a query representing the KGL statement. An entity may represent an operation performed with respect one or more objects that may be tables, the results of other operations, or the like. Accordingly, generating712the database query may include substituting database language statements to implement the operation represented by the entity and any operations generating a result processed by the operation.

The query may then be input to the server system102and a result of the query returned to the source of the KGL statement. The result of the query may be formatted or otherwise processed to facilitate understanding of the result, such as using Tableau or other interface generator.

Referring toFIG.8, the proximity of KGL statements to natural language statements may be used to translate natural language statements into KGL statements. The illustrated system800enables user to formulate a natural language statement describing desired information, generate and revise a corresponding KGL statement, and submit an database language statement to the server system102. The system800enables the user to do so with no knowledge of the databases104or the database language used to access the databases104.

For example, the system800may receive a natural language statement802from a user, such as from an interface executing on the user computing device116. The system800processes the natural language statement802using an LLM804to generate a KGL statement806. The KGL statement806is a preliminary KGL statement and the entities referenced therein may not actually correspond to the labels of entities in the entity graph. However, the KGL statement806may have the form and structure of a KGL statement.

The LLM804may be trained with a plurality of KGL statements and instructed to imitate the structure and form of the KGL statements. The LLM may be general purpose LLM that is provide the KGL statements and the natural language statement802and instructed to convert the natural language statement802into a KGL statement.

The KGL statement may be processed using a semantic search module808. The semantic search module808receives the KGL statement806and, for each entity referenced in the KGL statement806(“input entity”), searches for a corresponding entity in a knowledge graph810(“KG entity”).

The semantic search module808may access the knowledge graph810as well as semantic data812. The semantic data812may include such information as concepts represented by words or phrases and relationships between concepts in the form of a graph. The labels of the entities in the knowledge graph810may be selected from among the concepts in the semantic data812. The semantic module808may search for a concept in the knowledge graph810that is related to the input entity based on one or both of lexical (i.e., spelling) similarity and semantic (i.e., meaning) similarity as indicated in the semantic data812. The semantic module808may, for example, seek for concepts related to each input entity in the semantic graph and attempt to identify the KG entity in the knowledge graph810that is connected to the same concepts either directly or by way of the labels for the dimensions of the entity.

The semantic search module808may further take into account the structure of the KGL statement806. For example, where the KGL statement806includes reference A in the role of an entity, reference B as a dimension of the entity, and reference C as a value for the dimension, the semantic search module808will therefore search for an entity corresponding to reference A in terms of lexical and semantic similarity and having a dimension that corresponds to reference B in terms of lexical and semantic similarity, and having a possible value of C for the dimension. For example, in the KGL statement “Customer where Location=‘TX’ AND Birth Year=“1996”, the entity is Customer, the dimensions are Location and Birth Year, and the values are “TX” and “1996.” Where there are multiple dimensions, the dimensions may be searched separately, e.g. a combination of “Customer” and “Location” and a combination of “Customer and “Birth Year.” Entities identified as a result of both searches may then be evaluated to select an entity for “Customer” and dimensions of the entity corresponding to “Location” and “Birth Year.”

The semantic search module808replaces each input entity in the KGL statement with the corresponding KG entity identified by the semantic search module808, where the KG entity is different from the input entity, to obtain KGL statement814. The KGL statement may be displayed in an editor816, such as using an interface displayed on the user device116from which the NL statement802was received. The user may revise the KGL statement814using the editor816. The user may revise the KGL statement814by changing the entities referenced in the KGL statement814and relationships between entities in the KGL statement814. The editor816may implement some or all of the functions described above for an interface for receiving the input of KGL statements. In particular, the editor816may enable a user to view the knowledge graph, view the dimensions of an entity referenced in a KGL statement, provide suggested or possible values for an entity referenced in a KGL statement, or other aids to the editing of KGL statements.

If the user makes changes to the KGL statement814, the revised KGL statement may be processed in various ways. In a first approach, the revised KGL statement is treated as a new natural language statement and processing repeats by inputting the revised KGL statement to the LLM804. In a second approach, the revised KGL statement is input to the semantic search module to ensure that each entity referenced in the revised KGL statement is represented in the knowledge graph. In some embodiments, the first approach is used if the relationships included in the KGL statement814are revised and the second approach is used if only the entities referenced in the KGL statement814is changed.

Once a KGL statement814is approved by a user, the KGL statement814may be passed to a KGL interpreter818. The KGL interpreter818interprets the KGL statement814to generate a database query820. For example, the KGL interpreter818may implement the method700with respect to the KGL statement814.

The database query820may be submitted to the server system102, processed by the server system102, and a result of the query returned to the source of the natural language statement802, such as the user computing device116. The result of the query820may be formatted or otherwise processed to facilitate understanding of the result, such as using Tableau or other interface generator.

As an example use case of the system800, the natural language statement received from a user may be “customers who live in TX.” The KGL statement814derived therefrom may be “Customers where CurrentAddressState=‘TX.’” The database query820generated from the KGL statement814may be an SQL statement such as:WITH table_0 AD (SELECT customer.c_customer_sk AD output FROM tpcds_1000.customer JOIN tpcds_1000.customer_address AD customer_address_0 ON customer.c_current_addr_sk=customer_address_0.ca_address_sk WHERE customer_address_0.ca_state=‘TX’) SELECT*FROM table_0

As is readily apparent, generating the database query820would require much greater knowledge of SQL as well as the underlying databases104. However, using the system800, a user may generate the query820simply by typing a natural language statement and possibly editing a readily understandable KGL statement814.

FIG.9is a block diagram illustrating an example computing device900. Computing device900may be used to perform various procedures, such as those discussed herein. The server system102may include one or more computing devices900and a user computing device116may be embodied as a computing device900.

Computing device900includes one or more processor(s)902, one or more memory device(s)904, one or more interface(s)906, one or more mass storage device(s)908, one or more Input/Output (I/O) device(s)910, and a display device930all of which are coupled to a bus912. Processor(s)902include one or more processors or controllers that execute instructions stored in memory device(s)904and/or mass storage device(s)908. Processor(s)902may also include various types of computer-readable media, such as cache memory. The processor902may be embodied as or further include a graphics processing unit (GPU) including multiple processing cores.

Memory device(s)904include various computer-readable media, such as volatile memory (e.g., random access memory (RAM)914) and/or nonvolatile memory (e.g., read-only memory (ROM)916). Memory device(s)904may also include rewritable ROM, such as Flash memory.

Mass storage device(s)908include various computer readable media, such as magnetic tapes, magnetic disks, optical disks, solid-state memory (e.g., Flash memory), and so forth. As shown inFIG.9, a particular mass storage device is a hard disk drive924. Various drives may also be included in mass storage device(s)908to enable reading from and/or writing to the various computer readable media. Mass storage device(s)908include removable media926and/or non-removable media.

I/O device(s)910include various devices that allow data and/or other information to be input to or retrieved from computing device900. Example I/O device(s)910include cursor control devices, keyboards, keypads, microphones, monitors or other display devices, speakers, printers, network interface cards, modems, lenses, CCDs or other image capture devices, and the like.

Display device930includes any type of device capable of displaying information to one or more users of computing device900. Examples of display device930include a monitor, display terminal, video projection device, and the like.

Interface(s)906include various interfaces that allow computing device900to interact with other systems, devices, or computing environments. Example interface(s)906include any number of different network interfaces920, such as interfaces to local area networks (LANs), wide area networks (WANs), wireless networks, and the Internet. Other interface(s) include user interface918and peripheral device interface922. The interface(s)906may also include one or more peripheral interfaces such as interfaces for printers, pointing devices (mice, track pad, etc.), keyboards, and the like.

Bus912allows processor(s)902, memory device(s)904, interface(s)906, mass storage device(s)908, I/O device(s)910, and display device930to communicate with one another, as well as other devices or components coupled to bus912. Bus912represents one or more of several types of bus structures, such as a system bus, PCI bus, IEEE 1394 bus, USB bus, and so forth.

These example devices are provided herein purposes of illustration, and are not intended to be limiting. Embodiments of the present disclosure may be implemented in further types of devices, as would be known to persons skilled in the relevant art(s). At least some embodiments of the disclosure have been directed to computer program products comprising such logic (e.g., in the form of software) stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a device to operate as described herein.

Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java, Smalltalk, C++, or the like and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on a computer system as a stand-alone software package, on a stand-alone hardware unit, partly on a remote computer spaced some distance from the computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).