Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
  • G06F16/2457—Query processing with adaptation to user needs
  • G06F16/24575—Query processing with adaptation to user needs using context
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
  • G06F16/2453—Query optimisation
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/23—Updating
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/242—Query formulation
  • G06F16/2425—Iterative querying; Query formulation based on the results of a preceding query
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/242—Query formulation
  • G06F16/2433—Query languages
  • G06F16/2445—Data retrieval commands; View definitions
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
  • G06F16/2452—Query translation
  • G06F16/24522—Translation of natural language queries to structured queries
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
  • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
  • G06F16/2471—Distributed queries
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/953—Querying, e.g. by the use of web search engines
  • G06F16/9535—Search customisation based on user profiles and personalisation
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/21—Design, administration or maintenance of databases
  • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/24—Querying
  • G06F16/245—Query processing
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/30—Information retrieval; Database structures therefor; File system structures therefor of unstructured textual data
  • G06F16/33—Querying
  • G06F16/335—Filtering based on additional data, e.g. user or group profiles

Definitions

• Such software applications include database applications that access an enterprise's internal database comprising structured data records (e.g., table data).
• the database applications are built on a development platform for a database management system.
• a database application accesses the internal database and (ordinarily) provides a response comprising table data that matches the database query.
• various aspects of the subject matter described herein are directed towards maintaining a translation mechanism that allows data retrieved from internal database queries to be enriched with data from external data sources, using straightforward query commands.
• the translation mechanism facilitates the retrieval of external data because separate providers are not needed for different external data sources. There is no need for a query author or application developer to deal with how database queries are authenticated, how table data is imported from the external data sources or how a user is billed for access, for example.
• an enrichment server uses the translation mechanism to combine an internal database with table data from one or more external databases.
• the enrichment server enables a seamless augmentation of the non-public data with various public information.
• the enrichment server extracts parameters from the database query from which an entity is identified.
• the entity includes a grouping of data types as components whose values are requested by a user.
• the parameters also include values that are used as search criteria or the like for selecting data from the external data sources.
• the translation mechanism initiates appropriate native function calls of a protocol for requesting data from the external data sources.
• FIG. 1 is a block diagram illustrating an exemplary system for enriching database query responses using data from external data sources.
• FIG. 2 is a flow diagram illustrating steps for enriching database query responses using data from external data sources according to one example implementation.
• FIG. 3 is a flow diagram illustrating steps for using a directory to communicate requests for various information to an external data source according to one example implementation.
• FIG. 4 is a flow diagram illustrating steps for converting data from external data sources into an enriched database query response according to one example
• FIG. 5 is a flow diagram illustrating steps for building a directory for translating a database query into native requests for an external data source according to one example implementation.
• FIG. 6 is a flow diagram illustrating steps for mapping entity components to external data sources according to one example implementation.
• FIG. 7 is a block diagram representing exemplary non-limiting networked environments in which various embodiments described herein can be implemented.
• FIG. 8 is a block diagram representing an exemplary non-limiting computing system or operating environment in which one or more aspects of various embodiments described herein can be implemented.
• a database query includes one or more parameters specifying one or more criteria for selecting data from the external data sources.
• One exemplary parameter includes an entity identifier (e.g., a name) of a group of data types. Each data type may include one or more other data types.
• Other exemplary parameters include one or more values for one or more data types of the group of data types. Some other exemplary parameters may be contextual parameters that limit the values returned by the external data source to a particular time and/or location, for example.
• enriched responses to the database query include table data
• the group of data types defines one or more columns, while the one or more values define one or more rows.
• column data within each row of the table data corresponds with the one or more values.
• the database query pertains to enriching company data with various information exemplified as financial information, such as stock prices, employee statistics, earnings reports, market capitalization values ("market caps"), recent stock ticker prices and/or the like.
• financial information such as stock prices, employee statistics, earnings reports, market capitalization values ("market caps"), recent stock ticker prices and/or the like.
• One or more external data sources such as financial news media, stock markets, search engines and/or the like, provide the various financial information for the one or more company names in response to native function calls or queries ("requests") requesting such data.
• data types that define portions of the various financial information constitute an entity.
• the database query includes an entity name and one or more company names as parameters.
• An exemplary entity includes a number of components (i.e., data types), including components representing a number of employees, a market cap and a stock price. Many other components may be included in the entity, e.g., company officers, gross sales, state of incorporation, years in existence, and so forth.
• a translation mechanism provides one or more exemplary parameters, including any of the entity components (e.g., identified in a user query), and instructs connectivity software running at an appropriate external data source to execute a native function. Consequently, the connectivity software returns values for the number of employees, the market cap and/or the stock price, for example, if those are specified.
• the first line specifies the columns of data to retrieve, of which name and zipcode are available from the enterprise's internal database, while ticker and
• the second line indicates the table to enrich.
• the third line is the data enrichment, which specifies the predefined entity "CompanyFinancial” that includes the components for the external data, with the c.name parameter specifying which companies to return external data for, namely those in the "Companies c" table. Note that the user can view the "CompanyFinancial” entity to determine that the needed data columns (ticker and num employees in this example) will be satisfied by specifying this entity.
• the translation mechanism may instruct connectivity software running at another external data source to execute a different native function in order to access the unknown entity component.
• the translation mechanism replaces the need for one or more data separate providers to communicate with each type of external data source.
• an external data source may utilize a unique or proprietary protocol (e.g., Application Programming Interface (API)) to communicate data
• a translation mechanism accesses configuration data (e.g., maintained in a directory) to configure a function call or remote query that is compatible with such a protocol.
• the function call or remote query includes criteria for identifying some of the various information (e.g., financial information) to use for enrichment.
• the external data source After the translation mechanism initiates the function call or query, the external data source returns data matching such criteria.
• the translation mechanism may call a function requesting a particular company stock price from a stock market database.
• a call includes a specific company name (or symbol) along with some indication (e.g., an attribute) indicating that the stock price is requested.
• the stock price is communicated to the translation mechanism in a native format.
• the translation mechanism extracts the stock price and inserts the stock price in the table data that forms a portion of an enriched database query response.
• the table data may be used to populate one or more columns of an internal database of the enterprise's data, including private data.
• some of the exemplary parameters may include contextual parameters that specify a location and/or time value.
• the translation mechanism uses the contextual parameters to identify data that corresponds with the location and/or the time value from the external data source. For example, the translation mechanism uses a specific date/time as a native function call parameter to select a stock price at the specific data/time. As another example, the translation mechanism initiates another native function call for computing an average stock price over a time interval (e.g., a number of days).
• the database query includes parameters for enriching private company data with various news information at or near a particular geographic location, which may be represented as a physical location (e.g., geographic or geodetic coordinates) or an Internet resource location (e.g., an Internet Protocol (IP) address).
• IP Internet Protocol
• the translation mechanism may initiate a native function call for company-related news within a range of a certain Global Positioning System (GPS) location.
• GPS Global Positioning System
• the native function call may further request company-related news for a particular time period, such as historical news or current news.
• FIG. 1 is a block diagram illustrating an exemplary system for enriching database query responses using data from external data sources.
• the exemplary system (e.g., implemented in one server among many servers) may support various database services.
• the exemplary system includes various example components, such as a SQL engine 102, an enrichment server 104 and a translation mechanism 106 as described herein.
• the enrichment server 104 may be one or more servers comprising an enrichment service.
• the SQL engine 102 receives database queries including various parameters (i.e., sometimes referred to as enrichment parameters), such as an entity identifier.
• the enrichment server 104 may access entity data 108 and verify that each component in the query is available from internal data 109 or via an entity that matches the entity identifier.
• the enrichment server 104 uses the translation mechanism 106 to access data at one or more external data sources 1 lOi-l 10 n and select values for various entity components. These values may be stored in a form of table data within an enriched database query response that is communicated to the SQL engine 102 via the enrichment server 104.
• the SQL engine 102 is configured to populate portions (e.g., one or more columns of table data) of an internal database 109 with the enriched database query response.
• the translation mechanism accesses a directory 112 with information maintained for each data source that corresponds to an entity component.
• the directory 112 has entries for each external data source 1 lOi-l 10 n , with each entry defining a protocol for communicating data with the external data source including native function calls, data formats, billing procedures, security credentials and/or the like.
• any suitable mechanism may be used to determine such information, including maintaining the protocol / related data in another data store, hard coding the protocol / related data into the translation mechanism and so forth.
• the enrichment server 104 and the translation mechanism 106 may be stored and operated at a local computer / network to control access to local and/or networked databases.
• the enrichment server 104 and/or the translation mechanism 106 may be included in cloud computing applications where the local computer primarily functions as an interface for a share of computing resources at a remote server data center. While the cloud computing applications store the table data in an internal database, the internal database is not stored at the local computer, for example.
• the enrichment server 104 may utilize a policy 114 to map each of the various entity components to an appropriate external data source amongst the plurality of data sources 1 lOi-l 10 n .
• the policy 114 may include preferences associated with selecting the appropriate external data source.
• the policy 114 may indicate a preference for free data services over commercial/paid data services, whereby the enrichment server 104 selects a commercial/paid data service only if a free option does not exist; a price limit may be specified in the policy as well.
• the policy 114 may assign a high priority to a specific data source. Unless a value for an entity component cannot be retrieved or computed, the enrichment server 104 uses that specific data source to access data for enriching the database query response.
• the plurality of external data sources 1 lOi-l 10 n include any type of remote or Internet data service (e.g., data feeds, reports, commercial or free databases, search engines and/or the like) from which table data is retrieved and then used to generate an enriched database query response.
• Each of the external data sources 1 lOi-l 10 n implements a particular protocol that allows other computer systems to access the table data.
• the particular protocol may include an
• Input parameters for the native functions identify the portions of the table data to be returned.
• the translation mechanism 106 calls a function with input parameters specifying a company name and a requested data type, such as a current stock price.
• One of the external data sources searches a database that provides stock prices and returns table data comprising the company name and the current stock price.
• the translation mechanism 106 may request a stock price for a previous day, such as yesterday.
• the input parameters include a parameter specifying a day.
• FIG. 2 is a flow diagram illustrating steps for enriching database query responses using data from external data sources according to one example implementation. Steps depicted in FIG. 2 commence at step 202 and proceed to step 204 when database queries are processed by the SQL engine 104. Step 204 represents recognition of enrichment parameters within a database query and transmission of the database query to the enrichment server 104.
• Step 206 illustrates extraction of the enrichment parameters from the database query, which includes an entity identifier and one or more values of one or more entity components. As described herein, these entity components include data types associated with enriching the database query. Results from external data sources correspond with the one or more values as also described herein.
• Step 208 represents the mapping of the entity components to external data sources. One exemplary implementation of Step 208 is illustrated in FIG. 6 in which a policy determines which external data source to use for retrieving data for a particular entity component.
• Step 210 implements the translation mechanism 106, which produces and communicates native requests for various data to the external data sources.
• the native requests are configured in accordance with a protocol for connecting to the external data sources, executing compatible commands and retrieving results.
• the native requests include native function calls that are implemented by the external data sources.
• FIG. 3 illustrates an exemplary implementation of Step 210 in which a directory is used to translate the database query into such native function calls requesting data for the entity components.
• Step 212 is directed to processing data received from the external data sources as a response to the native requests.
• the translation mechanism 106 converts the data provided by the external data source into table data that is used to generate an enriched database query response.
• the enrichment server 204 communicates the enriched database query response to the SQL engine 102, which returns a view of the enriched table response and/or inserts the table data into an internal table of an internal database, e.g., according to a schema.
• the internal table may be refreshed automatically on a scheduled basis or the like, e.g., by automatically generating a new query for external data and using the data in the enriched data response to insert the updated data.
• the enrichment server 204 collects statistics regarding billing activity, data source diagnostics and/or the like. These statistics may be used for various purposes, such as auditing billing expenses, analyzing data sources and updating the policy.
• the policy may include a usage limit for a particular data source. If the statistics indicate that the usage limit has been reached, another data source may be selected from the policy.
• Step 214 represents termination of enriching database query responses.
• FIG. 3 is a flow diagram illustrating steps for using a directory to communicate requests for various information to an external data source according to one example implementation. These requests are configured to be a native command for the external data source.
• the enrichment server 104 uses the translation mechanism to produce these requests based on a database query that is transmitted from the SQL engine 102. Steps depicted in FIG. 3 commence at step 302 and proceed to step 304 where the enrichment server 104 accesses a directory implementing the translation mechanism 106.
• Step 306 represents an examination of a directory entry associated with the external data source. Step 308 refers to identifying a protocol for communicating with the external data source.
• the directory entry defines a protocol for communicating data with the external data source including native function calls, data formats, billing procedures, security credentials and/or the like. Hence, such a protocol is used by the translation mechanism 106 to initiate one or more native function calls to the external data source.
• Step 310 is directed to connecting with the external data source.
• the protocol within the directory entry also includes a location, such as an IP address, as well as any authenticating procedures for the external data source. For example, an account user name and password may be required for accessing the external data source.
• the translation mechanism 106 selects one or more specific databases or tables and initiates calls requesting various information as illustrated by step 312. These calls include native function calls associated with an API of the external data source.
• Step 314 refers to termination of using the directory to communicate requests for various information to the external data source.
• FIG. 4 is a flow diagram illustrating steps for converting data from external data sources into an enriched database query response according to one example
• Steps depicted in FIG. 4 commence at step 402 and proceed to step 404 when the translation mechanism 106 receives data from the external data sources in response to native requests for various information, such as financial or news information.
• Step 406 is directed to examining a format associated with the data received from the external data sources (although the format may be known in advance from information in the directory, for example).
• a particular external data source returns values in a unique format, such as JavaScript Object Notation (JSON) format.
• JSON JavaScript Object Notation
• the translation mechanism 106 converts these values into table data and prepares an enriched database query response as represented in step 408.
• the translation mechanism 106 may perform additional processing on these values, such as aggregating stock prices over a period of time and computing a mean or median stock price.
• Step 410 is directed to returning a view of the enriched table and/or populating an internal database using the enriched database query response.
• the table data created from the values that were returned by the particular external data source may be inserted into a certain table or one or more columns within the internal database according to one exemplary implementation.
• the table data shares a similar schema with the certain table rendering the insertion operation into a series of copy data operations.
• the certain table is blank or a temporary table outside of a relational paradigm associated with the internal database.
• Step 412 signifies a completion of the enriched database query response.
• FIG. 5 is a flow diagram illustrating steps for building a directory for translating a database query into native requests for an external data source according to one example implementation.
• the directory forms a portion of the translation mechanism 106. Steps depicted in FIG. 5 commence at step 502 and proceed to step 504 when the translation mechanism 106 generates a blank directory entry.
• the translation mechanism 106 stores various information in the blank directory entry, such as a protocol for communicating with the external data source, according to one exemplary implementation.
• the protocol defines native functions calls for requesting information and formats for organizing the requested information.
• the protocol requires various credentials such as a username and password.
• Step 506 is directed to connecting with the external data source.
• the translation mechanism 106 creates a session using an IP address with an interface to the external data source, such as an Application Programming Interface (API).
• API Application Programming Interface
• the translation mechanism 106 proceeds to communicate with the external data source via the interface, which is represented by step 508.
• the translation mechanism 106 uses the interface to enumerate each available database and selects an appropriate database in response to a policy as described herein.
• Step 510 refers to determining requirements for using a protocol associated with the external data source.
• the translation mechanism 106 identifies functions that are executable by the interface and configured to return various information. These functions are native to the external data source and enable access to one or more available databases. The translation mechanism 106 also
• the translation mechanism determines which credentials are needed to search the one or more available databases according one example.
• the translation mechanism also determines whether a unique or propriety format is used to exchange data with the external database. Any information regarding the requirements for using the protocol is stored in the blank directory entry as represented by step 512. When complete, the directory entry is used to update the directory, which is denoted by step 514.
• Step 516 represents a decision as to whether to further update the directory with another entry for a next external data source. If there are more external data sources to examine, steps 504 to 514 are repeated. If, on the other hand, there are no more external data sources to examine, step 516 is performed during which the building of the directory terminates. The directory may be rebuilt and/or updated at any appropriate time, e.g., whenever a new data source is added or changes its protocol.
• FIG. 6 is a flow diagram illustrating steps for mapping entity components to external data sources according to one example implementation.
• Each entity component includes a data type whose value or values enrich a database query response.
• a database query specifies an entity that represents a grouping of the data types. Steps depicted in FIG. 6 commence at step 602 and proceed to step 604 when the translation mechanism 106 examines an entity component.
• Step 606 refers to identifying matching external data sources for the entity component.
• the matching external data sources are configured to provide information that corresponds with the entity component.
• the matching external data sources provide data having a same data type as the entity component.
• the data provided by the matching external data sources may require further processing.
• such data includes values of which an algorithm uses as input parameters in order to compute another value, which is stored in the entity component.
• step 608 is directed to accessing a policy for selecting an appropriate one to request various information, which is represented as step 610.
• the policy includes preferences for particular external data sources based on various factors, such as billing requirements, performance and/or the like.
• the policy indicates a preference for free data sources. As such, only free ones of the matching external data sources are considered options. If more than one matching external data source is free, any of them can be selected.
• Step 612 represents a decision as to mapping another entity component to an appropriate external data source. If there are more entity components, the enrichment server, via the translation mechanism 106, returns to Step 604 are repeats each step until 610 for a next entity component. If, on the other hand, there are no more entity
• mapping of the entity components terminates, which is represented by step 614.
• FIG. 7 provides a schematic diagram of an exemplary networked or distributed computing environment.
• the distributed computing environment comprises computing objects 710, 712, etc., and computing objects or devices 720, 722, 724, 726, 728, etc., which may include programs, methods, data stores, programmable logic, etc. as represented by example applications 730, 732, 734, 736, 738.
• computing objects 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. may comprise different devices, such as personal digital assistants (PDAs), audio/video devices, mobile phones, MP3 players, personal computers, laptops, etc.
• PDAs personal digital assistants
• Each computing object 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. can communicate with one or more other computing objects 710, 712, etc. and computing objects or devices 720, 722, 724, 726, 728, etc. by way of the communications network 740, either directly or indirectly.
• communications network 740 may comprise other computing objects and computing devices that provide services to the system of FIG. 7, and/or may represent multiple interconnected networks, which are not shown.
• an application can also contain an application, such as applications 730, 732, 734, 736, 738, that might make use of an API, or other object, software, firmware and/or hardware, suitable for communication with or implementation of the application provided in accordance with various embodiments of the subject disclosure.
• computing systems can be connected together by wired or wireless systems, by local networks or widely distributed networks.
• networks are coupled to the Internet, which provides an infrastructure for widely distributed computing and encompasses many different networks, though any network infrastructure can be used for exemplary communications made incident to the systems as described in various embodiments.
• client/server peer-to-peer
• hybrid architectures a host of network topologies and network infrastructures, such as client/server, peer-to-peer, or hybrid architectures.
• the "client” is a member of a class or group that uses the services of another class or group to which it is not related.
• a client can be a process, e.g., roughly a set of instructions or tasks, that requests a service provided by another program or process.
• the client process utilizes the requested service without having to "know” any working details about the other program or the service itself.
• a client is usually a computer that accesses shared network resources provided by another computer, e.g., a server.
• a server e.g., a server
• computing objects or devices 720, 722, 724, 726, 728, etc. can be thought of as clients and computing objects 710, 712, etc.
• computing objects 710, 712, etc. acting as servers provide data services, such as receiving data from client computing objects or devices 720, 722, 724, 726, 728, etc., storing of data, processing of data, transmitting data to client computing objects or devices 720, 722, 724, 726, 728, etc., although any computer can be considered a client, a server, or both, depending on the circumstances.
• a server is typically a remote computer system accessible over a remote or local network, such as the Internet or wireless network infrastructures.
• the client process may be active in a first computer system, and the server process may be active in a second computer system, communicating with one another over a communications medium, thus providing distributed functionality and allowing multiple clients to take advantage of the information-gathering capabilities of the server.
• the computing objects 710, 712, etc. can be Web servers with which other computing objects or devices 720, 722, 724, 726, 728, etc. communicate via any of a number of known protocols, such as the hypertext transfer protocol (HTTP).
• HTTP hypertext transfer protocol
• Computing objects 710, 712, etc. acting as servers may also serve as clients, e.g., computing objects or devices 720, 722, 724, 726, 728, etc., as may be characteristic of a distributed computing environment.
• Embodiments can partly be implemented via an operating system, for use by a developer of services for a device or object, and/or included within application software that operates to perform one or more functional aspects of the various embodiments described herein.
• Software may be described in the general context of computer executable instructions, such as program modules, being executed by one or more computers, such as client workstations, servers or other devices.
• computers such as client workstations, servers or other devices.
• client workstations such as client workstations, servers or other devices.
• FIG. 8 thus illustrates an example of a suitable computing system environment 800 in which one or aspects of the embodiments described herein can be implemented, although as made clear above, the computing system environment 800 is only one example of a suitable computing environment and is not intended to suggest any limitation as to scope of use or functionality. In addition, the computing system environment 800 is not intended to be interpreted as having any dependency relating to any one or
• an exemplary remote device for implementing one or more embodiments includes a general purpose computing device in the form of a computer 810.
• Components of computer 810 may include, but are not limited to, a processing unit 820, a system memory 830, and a system bus 822 that couples various system components including the system memory to the processing unit 820.
• Computer 810 typically includes a variety of computer readable media and can be any available media that can be accessed by computer 810.
• the system memory 830 may include computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) and/or random access memory (RAM).
• system memory 830 may also include an operating system, application programs, other program modules, and program data.
• a user can enter commands and information into the computer 810 through input devices 840.
• a monitor or other type of display device is also connected to the system bus 822 via an interface, such as output interface 850.
• computers can also include other peripheral output devices such as speakers and a printer, which may be connected through output interface 850.
• the computer 810 may operate in a networked or distributed environment using logical connections to one or more other remote computers, such as remote computer 870.
• the remote computer 870 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, or any other remote media consumption or transmission device, and may include any or all of the elements described above relative to the computer 810.
• the logical connections depicted in Fig. 8 include a network 872, such local area network (LAN) or a wide area network (WAN), but may also include other networks/buses.
• LAN local area network
• WAN wide area network
• Such networking environments are commonplace in homes, offices, enterprise-wide computer networks, intranets and the Internet.
• a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program, and/or a computer.
• an application running on computer and the computer can be a component.
• One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Physics & Mathematics (AREA)
• Databases & Information Systems (AREA)
• Data Mining & Analysis (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Computational Linguistics (AREA)
• Mathematical Physics (AREA)
• Artificial Intelligence (AREA)
• Computing Systems (AREA)
• Fuzzy Systems (AREA)
• Probability & Statistics with Applications (AREA)
• Software Systems (AREA)
• Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
• Information Transfer Between Computers (AREA)

Priority Applications (11)

Applications Claiming Priority (2)

Publications (2)

Family

ID=47354574

Family Applications (1)

Country Status (11)

Cited By (2)

Families Citing this family (49)

Family Cites Families (38)

• 2011
  • 2011-06-14 US US13/159,666 patent/US9122720B2/en active Active
• 2012
  • 2012-06-05 CA CA 2838500 patent/CA2838500A1/en not_active Abandoned
  • 2012-06-05 MX MX2013014791A patent/MX2013014791A/es active IP Right Grant
  • 2012-06-05 AU AU2012271083A patent/AU2012271083B2/en not_active Ceased
  • 2012-06-05 KR KR1020187034381A patent/KR102048653B1/ko active Active
  • 2012-06-05 JP JP2014515867A patent/JP5940149B2/ja not_active Expired - Fee Related
  • 2012-06-05 CN CN201280029313.9A patent/CN103608810B/zh active Active
  • 2012-06-05 EP EP12800711.9A patent/EP2721533A4/en not_active Ceased
  • 2012-06-05 WO PCT/US2012/040947 patent/WO2012173823A2/en not_active Ceased
  • 2012-06-05 RU RU2013155624A patent/RU2611967C2/ru active
  • 2012-06-05 BR BR112013031948A patent/BR112013031948A2/pt not_active Application Discontinuation
  • 2012-06-05 KR KR1020137033036A patent/KR101925165B1/ko active Active
• 2014
  • 2014-01-28 US US14/166,437 patent/US9122721B2/en active Active
  • 2014-01-28 US US14/166,442 patent/US9128979B2/en active Active
• 2015
  • 2015-08-03 US US14/816,547 patent/US20150339352A1/en not_active Abandoned
• 2017
  • 2017-01-31 AU AU2017200613A patent/AU2017200613B2/en not_active Ceased

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events