US20130290247A1 - Context platform - Google Patents

Context platform Download PDF

Info

Publication number
US20130290247A1
US20130290247A1 US13/927,062 US201313927062A US2013290247A1 US 20130290247 A1 US20130290247 A1 US 20130290247A1 US 201313927062 A US201313927062 A US 201313927062A US 2013290247 A1 US2013290247 A1 US 2013290247A1
Authority
US
United States
Prior art keywords
context
item
describing
store
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US13/927,062
Inventor
Gregory Parks
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US13/927,062 priority Critical patent/US20130290247A1/en
Publication of US20130290247A1 publication Critical patent/US20130290247A1/en
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Abandoned legal-status Critical Current

Links

Images

Classifications

    • G06F17/30194
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking

Definitions

  • Personal computers are frequently used to access digital information or to assist users in creating such digital information.
  • personal computers can be used to create and access word processing documents, spreadsheets, presentations, digital media, and other forms of digital information.
  • Some computing systems are configured to use one or more sensors to measure aspects of the physical world.
  • personal computers have not yet been configured to allow application developers to take full advantage of information from such sensors in an extensible and easy to use manner.
  • a network-accessible context store holds a plurality of different context items. Each context item includes one or more context-describing values.
  • An arbitration engine resolves conflicting requests to assign different context-describing values to a context item held in the network-accessible context store.
  • FIG. 1 shows an example computing system for implementing a context platform in accordance with an embodiment of the present disclosure.
  • FIG. 2 shows a context store of the computing system of FIG. 1 .
  • FIG. 3 shows an arbitration engine that can be used with a context platform.
  • FIG. 4 schematically shows a computing system for implementing a context platform in accordance with an embodiment of the present disclosure.
  • FIG. 5 shows a process flow of a method of providing a plurality of domain interpreters universal access to a common context store.
  • FIG. 1 schematically shows a computing system 10 that includes, among other elements, a context store 12 , one or more domain interpreters 14 , a context store API 16 (application programming interface), an operating system 18 , one or more applications 20 , and one or more devices 22 .
  • the computing system may communicate with other computing systems, devices, sensors, effectors, and the like via a network 24 , such as the Internet, an intranet, or another suitable network.
  • computing system 10 may include a personal computer, such as a desktop, laptop, or tablet personal computer, although other devices are within the scope of this disclosure.
  • operating system 18 may include one or more modules for providing at least some of the functionality provided by the herein described context store, context store API, and domain interpreters. In other embodiments, such functionality may be provided by modules designed to cooperate with an operating system (e.g., plug-ins to the operating system or third party applications).
  • computing system 10 is illustrated and described in accordance with its application of serving as a context platform.
  • the computing system may include additional and/or alternative components and/or software for providing other functionality.
  • the present disclosure does not include description of such components and software.
  • Augmentation is the ability of a computing system to act intelligently as an agent on behalf of the user but under the supervision of the user.
  • autonomy the ability for a computing system to know what to do and take unsupervised action without prompting.
  • Access and assistance are relatively simple to achieve because the computing system need not know much about the environment.
  • An increased level of contextual knowledge is needed in order for a computing system to provide advice, augmentation, or agency functionality.
  • the herein disclosed context platform of computing system 10 provides an extensible framework which developers can utilize to improve access to and use of contextual knowledge, so as to more easily equip the computing system for providing adaption, advice, augmentation, or agency functionality.
  • Context is a complex concept and comes in many forms with a wide variation across a spectrum of complexity.
  • physical context can be derived from devices, location, senses, and other physical conditions or stimuli.
  • Some physical context is relatively easy to assess (e.g., brightness of light falling on a light sensor or physical location measured by GPS).
  • Other physical context is more difficult to assess (e.g., the concept of “darkness” is complex, it is not composed of simple sense data, but rather a combination of information, including the time of day, the season, transitory phenomena like cloudiness, and information about what a particular user considers to qualify as dark).
  • the light falling on a photo-sensor is certain; it is a fact.
  • the notion that it is dark in a room or outside is uncertain; it is a belief, and one user may believe it is dark when another does not.
  • Social context is another example of context having a range of concepts that can be assessed with varying levels of ease. On one end of the spectrum, it is relatively easy to determine the number of people in a room and even who is in a room. It is more difficult to determine how two people are interacting in a social, work, or personal situation.
  • Context store 12 of FIG. 1 is configured to hold one or more context items 30 , such as Context Item A, Context Item B, Context Item C, Context Item D, through Context Item n. It is to be understood that the context store can hold virtually any number of context items. Each context item may correspond to a physical phenomenon, logical condition, a relation, or other piece of information that can be processed to make contextual decisions.
  • the context store is the heart of the context platform. It is the one place that all context items may be instantiated, accessed, and/or updated.
  • the context store serves as a central repository for all context items of the computing system.
  • the context store is configured to hold only state information, and is not intended to include a logic engine for processing information from the context store. Instead, domain interpreters 14 are configured to apply logic for altering context items in the context store and/or making other contextual decisions. Keeping state information separate from logical operations favors the extensibility of the context store, as a variety of different context items can be held by the same context store, even if such items correspond to diverse contextual concepts.
  • domain interpreters may instantiate, access, and/or update context items in a universally compatible manner, thus simplifying development of such domain interpreters.
  • domain interpreters may be included as part of the context store.
  • the context store may include a database, which may be comprised of computer-readable media (i.e., memory) holding or storing a structured collection of data (e.g., context items).
  • a computing system will use a locally located context store.
  • a computing system will use a remotely located context store, which, for example, may be accessed via a network.
  • the context store may be physically located in two or more different locations (e.g., a distributed database), though presenting itself as a single storage location to the computing system.
  • the context store can be configured to suspend execution in the time between alterations to context items of the context store.
  • the context store may be implemented as a database that includes only state information, the context store need not concern itself with the logical operations that are instead performed by the domain interpreters. As such, the context store can be configured to not consume any processing cycles when suspended, thus decreasing energy requirements.
  • FIG. 2 schematically shows a more detailed view of context store 12 .
  • each context item includes a unique identifier (e.g., Unique ID A and Unique ID B) and one or more context-describing values (e.g., Context-Describing Value X, Context-Describing Value Y, and Context-Describing Value Z).
  • Each context item may additionally or alternatively include a specification of how that context item is related to another context item. The unique identifier distinguishes a context item from all other context items.
  • the Unique ID may be comprised of a composite ID including two or more different subparts.
  • a Unique ID may include a user-id subpart, a context-id subpart, and a location-id subpart.
  • the context-id subpart may refer to a particular chain of coffee shops, for example, and all coffee shops in the chain may share the same context-id subpart.
  • the location-id subpart may refer to a particular instance of the coffee shops (e.g., the coffee shop at a particular physical address). In this way, coffee shops at two different physical addresses will be associated with different location-id subparts.
  • Unique IDs having different subpart clasifications are within the scope of this disclosure.
  • Each context item may be referred to by a unique ID, which may optionally be comprised of two or more subparts, and each context item may use one or more context-describing values to describe a context with which that context item is concerned and/or a relationship that context item may have with other context items.
  • a current GPS position could be referred to as ⁇ GPS_position, [latitude, longitude]>.
  • That context item may be a well-known public context description that is published by a context platform developer or a third party. That context may alternatively be a private context that is not published.
  • a party might want to refer to a different GPS position with more precision, such as ⁇ GPS_position_plus, [latitude, longitude, altitude, heading]>.
  • a new context item with a different unique identifier can be instantiated in the context store. Either context item is valid, and an application with suitable permissions can access one or both context items provided the application is made aware of the proper unique identifiers (e.g., GPS_position and/or GPS_position_plus).
  • a context item may include an archival log of previous context-describing values.
  • the context item may include a history of time-stamped values for one or more context-describing values, thus allowing a domain interpreter to analyze potential trends that can be used to more accurately assess a particular context.
  • Context Item A also includes a Friendly Name 40 providing a human-readable alias to the unique identifier; Permissions 42 defining the computing systems, users, or processes that have permission to access the context item; and a Subscribing-Consumers Listing 44 of context consumers subscribing to the context item.
  • a context item may include a specification of how that context item is related to other context items.
  • a context item may exist for a particular coffee shop at a particular physical address. Such a coffee shop is a “kind-of” restaurant, which in turn is a “kind-of” business establishment, and so on up the chain of relations to a root “place.” Such “kind-of” relations may be specified as part of a context item. Relations other than “kind-of” relations may additionally or alternatively be specified as part of a context item.
  • relations may themselves form a context and may be defined as other contexts are defined in the context store.
  • an ontology may include a “place,” which among other items, may include one or more “countries,” each of which may include, among other items, one or more “cities,” each of which may include, among other items, one or more business establishments, and such ontology can be further refined until a particular coffee shop at a particular physical address, for example, is included in the ontology.
  • a particular coffee shop at a particular physical address for example, is included in the ontology.
  • the relations set forth in an ontology may be specified in a relational manner with each particular context in the context store including a specification of the items that are above, below, or an the same level as that item in the hierarchy.
  • the context store provides for the definition of an ontology, but can be used without such an ontology.
  • a context item may include executable code for execution by the context store itself, or which may be passed to a context consumer or a context provider for execution.
  • a context item may include data that a user wishes to keep secret from one or more computing systems, users, or processes (e.g., a user may wish to keep his current location secret from all but a single trusted domain interpreter).
  • Permissions 42 may optionally be associated with one or more context items, such Permissions including permissions data used to track which computing systems, users, or processes have been granted permission to access the context item. Such Permissions may be granted in varying degrees (e.g., read only, read/write, etc.). Getting or setting context-describing values for the context item can be forbidden to any computing system, user, or process not having permission to access the context item.
  • Subscribing-Consumers Listing 44 may be used to track which domain interpreters are interested in a particular context item. This allows, for example, such domain interpreters to be notified if changes are made to the context item.
  • the Consumer-Subscription Listing may include one or more subscription parameters indicating which alterations to context-describing values are to trigger a callback method.
  • the Consumer-Subscription Listing may include, for each such subscription parameter, identification of the callback method to be triggered. In this way, a domain interpreter may register a callback method with the context item, thus allowing the context store to notify interested domain interpreters when changes are made.
  • a context item representing a sensor may also include a Sensor Location 46 .
  • the Sensor Location may include an indication of a physical location of a sensor that has been used to supply the context item with information.
  • the Sensor Location may include an indication of a physical location of the sensor (or other context provider) that last updated a context-describing value of the context item.
  • the Sensor Location can be used to discern information that may be relative to the context.
  • the Sensor Location may include an indication allowing a domain interpreter to differentiate between a smoke detector in a bedroom and a smoke detector in a basement.
  • a context item may also include an inference source and possible definition (e.g., an indication of a method that a domain interpreter uses to establish the values and/or certainty factor for a particular context-describing value). It will be understood that a variety of different data can be included with a particular context item.
  • a characteristic of the context store is the extensibility that permits a domain interpreter to define a new context that is represented differently from any others presently defined, while at the same time being able to take advantage of the same context items used by other domain interpreters.
  • FIG. 1 shows a plurality of domain interpreters 14 in operative communication with context store 12 .
  • Each domain interpreter may include one or more of a context provider 50 and a context consumer 60 .
  • some domain interpreters may include one or more context providers but no context consumers; some domain interpreters may include one or more context consumers but no context providers; and some domain interpreters may include both of one or more context providers and one or more context consumers.
  • Each context item held in the context store can be accessed, updated, or otherwise altered by one or more domain interpreters, as described in more detail below. Publishing definitions for context items allows domain interpreters to more easily share information amongst each other.
  • Each context provider of a domain interpreter such as context provider 50 of FIG. 1 , may be configured to output a context-describing value that can be held as part of a context item of the context store.
  • a context provider can be used to feed information to a context item of the context store.
  • context provider 50 may include one or more sensors, such as sensor 52 .
  • Context providers may include virtually anything that can establish and maintain context items in the context store.
  • sensors are a type of context provider that maintains information about the physical world in the context store.
  • context providers other than sensors may also be used.
  • a context provider may include a logic module configured to assign to a corresponding context-describing value of the context store a value derived from a logical operation.
  • a logical provider may include an application that queries the state of another application, such as whether an e-mail is being read, and instantiates that state information in the context store.
  • Context providers may determine context from a wide variety of different sources, nonlimiting examples of which include:
  • Sensors e.g., position, light, acceleration, humidity, temperature, traffic, etc.
  • Devices e.g., the number and/or types of devices connected to a computing system
  • Connections e.g., the types of available network access
  • Software e.g., the applications being used, and the states of such applications
  • Data e.g., information from calendar, to - do lists, preferences, contact lists, personal info, etc.
  • Services e.g., network services providing location by IP, traffic information, weather, news, etc.
  • Declarative and interrogative e.g., proactive instructions and instructions provided in response to a question or other request for input
  • Inferences e.g., algorithms, heuristics, predicate logic, fuzzy logic, neural networks, expert systems, Bayesian networks, etc.
  • Relation e.g. the relations between contexts, such as resides-in, contains, has-a, is-a, kind-of, etc.
  • a context platform may be extensibly configured for compatibility with context providers that assess context using any one or more of the above listed techniques, as well as virtually any other suitable technique. While any one of the above techniques may be independently useful, additional value may be achieved when two or more context assessing techniques are considered collectively.
  • a GPS sensor alone may be interesting, providing a coordinate location of a user. However, with the addition of information about the user's compass orientation and the direction that his eyes are looking, it may be possible to identify objects that are within the user's field of view. Those objects can then become a part of the collection of context items for the person or the place in which the person resides.
  • a context provider may include a sensor configured to measure a quantifiable phenomenon of the physical world and assign to a corresponding context-describing value of the context store a quantified value of the phenomenon as measured.
  • Sensor devices are a particular case of context provider. Generally speaking, sensors may alter context, but generally do not respond to changes in context. Although changes in context may alter the ways in which a sensor analyzes or reports sensor data.
  • Sensor devices may interface with the context platform through a standard mechanism for discovering and connecting sensor class devices and for describing data from common types of sensors in a uniform but extendable manner. This mechanism works with either external or internal sensors. Furthermore, this mechanism does not force compliance with a particular bus standard.
  • External sensors can interface with the context platform through a sensor class driver by using a data description schema.
  • a sensor may use a custom driver that can accommodate different transports or additional processing corresponding to that sensor.
  • the sensor platform may optionally calibrate and filter sensor data in addition to logging raw data.
  • Some sensors may include logical sources of data.
  • Sensors can be classified by a location and a relationship relative to a user.
  • sensors may include onboard sensors embedded within the enclosure of a computing system such as a mobile computer, a tablet computer, or the like. Such sensors may sense the environment relative to that enclosure.
  • the sensed information may be related to conditions within the enclosure, such as temperature, fan speeds, and g-forces.
  • the sensed information may also be related to conditions outside the enclosure.
  • a brightness sensor can be located at least partially inside the enclosure of a mobile computer, and such brightness sensor may detect ambient light levels outside the enclosure.
  • Sensors may include on-person sensors carried on or near the body of a person. Such sensors may sense the environment relative to that person. In other words, such sensors may effectively share with the context platform one or more of a person's five natural senses (i.e., sight, sound, smell, touch, taste). Such sensors often can provide improved and/or more accurate sense data than is naturally available to a user, and such sense data can be utilized by the context platform. In addition, sensors can be used to augment a person's senses, such as by providing the ability to sense compass orientation or the proximity to unseen objects and obstacles.
  • Sensors may include nearby sensors that can sense the physical world within a space relative to the sensors (e.g., same room or some nearby area). For example, such sensors can sense objects or sounds in a room and people moving about the space. Extending this concept to nearby space under a user's control, this class of sensors can sense a baby crying in an upstairs bedroom or motion occurring in any room in a house.
  • Sensors may include remote sensors that are not within the immediate vicinity of a user. Such sensors may sense private or public information that is important to a user. Private remote sensors include home automation sensors, which may be located at one or more locations of interest. Public remote sensors include traffic cameras, weather sensors, and other information that is often presented as a web service.
  • Each context consumer of a domain interpreter such as context consumer 60 of FIG. 1 , may be configured to input a context-describing value from a context item held in the context store and/or establish relations between those contexts.
  • a context consumer can be used to retrieve information from a context item of the context store.
  • Context consumers may include virtually any user-mode component that can query context items in the context store or subscribe to changes in context items in the context store. For example, a context consumer may subscribe to a context event that the context store fires when the context “at home” is fired in response to the user walking in the front door of her home.
  • a consumer may subscribe to a collection of context items.
  • a ‘DEVICES’ collection could be defined, and a consumer could subscribe to the ‘DEVICES’ collection.
  • any device that comes into the system would register as a device, and subscribed consumers could be passed a message notifying the subscribed consumers of the device.
  • This can be extended to include subscribing to any kind of collection, including, for example, the collection of every context in the system. In this way, consumers could remain aware of entrance to or exit from the system of any contexts in which they are interested. Effectors, such as effector 62 of FIG. 1 , are a nonlimiting example type of context consumer.
  • An effector device may be configured to alter a quantifiable phenomenon of the physical world in accordance with a context-describing value held in the context store.
  • effectors are devices that can make changes in the physical world (e.g., closing a door, ringing a bell, opening a water valve, changing the brightness of a display, etc.). This is different than making changes in the logical world of a computer, which usually involves making changes in the state of software.
  • effectors are a type of context consumer
  • context consumers can include nonphysical logic modules configured to use information from the context store to perform one or more logical operations. Such logical operations can alter one or more values of the context store and/or such logical operations can be used to effectuate some action outside of the context store (e.g., change the state of an application).
  • context consumers may include logic modules and/or effectors that enhance the capabilities of the context platform.
  • Effector devices can be conceptualized as virtual mirror images of sensor devices.
  • sensor devices can be configured to have direct access to effector devices, as is schematically illustrated by arrow 70 of FIG. 1 . While arrow 70 shows direct access between a context provider and a context consumer of the same domain interpreter, it should be understood that direct access may be established between a context provider of a different domain interpreter than a context consumer.
  • a domain-specific rules engine can be configured to allow an effector device to input data directly from a sensor device. In this way, developers can create real-time, high-bandwidth, control loops when desired.
  • an accelerometer that senses acceleration of a laptop can send acceleration information directly to a hard drive so that the hard drive may park its heads in the event the laptop is dropped. Because it is advantageous to perform this action quickly, the direct communication between the sensor and the effector may be beneficial. Such direct communication may be established between other types of context providers and context consumers.
  • a sensor device with direct access to an effector device may allow a computing system to remain in a low power (e.g., sleep) state without interfering with the synergy between the sensor (or other context provider) and the effector (or other context consumer). If the only processing capability in the system is in the operating system, the operating system would need to be active to handle simple asynchronous processing tasks, such as ringing a bell when the doorbell is pressed. Smart sensor and effector devices can process such simple “reflex” events without needing to wake the operating system, which can greatly reduce average power requirements.
  • the state or value of that direct ‘reflex’ connection may be instantiated in the context store as the value of a context item when the store awakens.
  • computing system 10 may include a context store API 16 .
  • the context store API can be used to provide a domain interpreter access to context items in the context store.
  • the context store API may enable a plurality of methods for interacting with the context store. Such methods may use the unique identifier of a context item as a parameter for accessing that context item.
  • Context providers can instantiate new context items in the store and/or all expected contexts may be instantiated without values, allowing context providers to supply values at a later time. Relations also may be predefined at startup and/or instantiated by providers at runtime.
  • a compatibility convention of a context item, including its unique identifier, may be published or otherwise made known to developers. As such, developers can design domain interpreters that access the context items of the context store using the unique identifier as a parameter, even though such domain interpreters may not initially have any knowledge of what other domain interpreters have worked with the context items.
  • the context store API allows a single context item to be altered by different domain interpreters. This kind of system—a central store with a plethora of co-operating domain-specific “experts,” each contributing their domain knowledge or reasoning ability to the store—is sometimes called a blackboard system.
  • the context store API may provide a context consumer direct access to data from a context provider without first holding data in the context store.
  • a direct exchange can be used to decrease latency and/or improve energy consumption, as described above.
  • the context store API may be described with pseudo-code having the form of method(CID, values), where CID is the unique identifier of a context item and values are context-describing values or other information associated with the context item.
  • CID is the unique identifier of a context item
  • values are context-describing values or other information associated with the context item.
  • a context store may include an arbitration engine 70 configured to resolve conflicting requests to change a context-describing value of a context item held in the context store.
  • the arbitration engine may arbitrate changes to context items by using an algorithm (e.g., a domain-specific arbitration algorithm associated with a context item, a default arbitration algorithm associated with two or more different context items, a custom algorithm associated with one or more particular context providers, etc.).
  • Possible arbitration mechanisms include prioritization, voting, most certain wins, least salient losses, and persistence of the most recent, to name a few.
  • FIG. 4 schematically shows one example computing system 80 that can be used to implement a context platform.
  • Computing system 80 includes a memory 82 , a logic subsystem 84 , and an I/O subsystem 86 . It should be understood that computing system 80 may include several components, subsystems, and software modules not shown.
  • Logic subsystem 84 may be configured to execute one or more instructions.
  • the logic subsystem may be configured to execute one or more instructions that are part of one or more programs, routines, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement an abstract data type, or otherwise arrive at a desired result. In particular, such instructions may provide the context store, context store API, and/or domain interpreter functionality described above.
  • the logic subsystem may include one or more processors that are configured to execute software instructions. Additionally or alternatively, the logic subsystem may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions.
  • the logic subsystem may optionally include individual components that are distributed throughout two or more devices, which may be remotely located in some embodiments.
  • Memory 82 may be a device configured to hold instructions that, when executed by the logic subsystem, cause the logic subsystem to implement the herein described methods and processes.
  • Memory 82 may include volatile portions and/or nonvolatile portions.
  • memory 82 may include two or more different devices that may cooperate with one another to hold instructions for execution by the logic subsystem.
  • logic subsystem 84 and memory 82 may be integrated into one or more common devices and/or computing systems.
  • I/O subsystem 86 may be configured to communicatively couple computing system 80 with one or more sensors, effectors, peripheral devices, networked computing devices, or other distinct entities. Such communication may be established using virtually any communication technology (e.g., USB, IEEE 1394, IEEE 802.3, IEEE 802.11x, IEEE 802.15, etc.).
  • communication technology e.g., USB, IEEE 1394, IEEE 802.3, IEEE 802.11x, IEEE 802.15, etc.
  • FIG. 5 shows a process flow of a method 90 of providing a plurality of domain interpreters universal access to a common context store.
  • method 90 includes publishing a compatibility-convention for defining one or more contextual concepts as context items. Such a compatibility convention may that each context item includes at least a unique identifier and one or more context-describing values.
  • method 90 includes holding one or more context items in a common context store. Each context item can be held in accordance with the compatibility-convention published for that context item.
  • method 90 includes granting provider access to one or more domain interpreters including a context provider configured to set a context-describing value of a context item in the context store.
  • provider access is granted to one or more domain interpreters via an application programming interface.
  • method 90 includes granting consumer access to one or more domain interpreters including a context consumer configured to get a context-describing value of a context item from the context store.
  • programs include routines, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types.
  • program may connote a single program or multiple programs acting in concert, and may be used to denote applications, services, or any other type or class of program.
  • computer “computing device,” “computing system,” and the like include any device that electronically executes one or more programs, including two or more such devices acting in concert.
  • a domain translator can reside on the same machine(s) as the context store and/or a domain translator may be remote from the context store. Domain translators may include domain specific processing elements (e.g., hardware, software, and/or firmware) and can be local or remote.
  • domain specific processing elements e.g., hardware, software, and/or firmware

Abstract

A network accessible context store holds a plurality of different context items. Each context item includes one or more context-describing values. An arbitration engine resolves conflicting requests to assign different context-describing values to a context item held in the network-accessible context store.

Description

    RELATED APPLICATIONS
  • This is a continuation of U.S. patent application Ser. No. 12/144,640, filed on Jun. 24, 2008, and entitled “CONTEXT PLATFORM”, the entire contents of which are hereby incorporated herein by reference.
  • BACKGROUND
  • Personal computers are frequently used to access digital information or to assist users in creating such digital information. For example, personal computers can be used to create and access word processing documents, spreadsheets, presentations, digital media, and other forms of digital information. Some computing systems are configured to use one or more sensors to measure aspects of the physical world. However, personal computers have not yet been configured to allow application developers to take full advantage of information from such sensors in an extensible and easy to use manner.
  • SUMMARY
  • A network-accessible context store holds a plurality of different context items. Each context item includes one or more context-describing values. An arbitration engine resolves conflicting requests to assign different context-describing values to a context item held in the network-accessible context store.
  • This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. Furthermore, the claimed subject matter is not limited to implementations that solve any or all disadvantages noted in any part of this disclosure.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 shows an example computing system for implementing a context platform in accordance with an embodiment of the present disclosure.
  • FIG. 2 shows a context store of the computing system of FIG. 1.
  • FIG. 3 shows an arbitration engine that can be used with a context platform.
  • FIG. 4 schematically shows a computing system for implementing a context platform in accordance with an embodiment of the present disclosure.
  • FIG. 5 shows a process flow of a method of providing a plurality of domain interpreters universal access to a common context store.
  • DETAILED DESCRIPTION
  • FIG. 1 schematically shows a computing system 10 that includes, among other elements, a context store 12, one or more domain interpreters 14, a context store API 16 (application programming interface), an operating system 18, one or more applications 20, and one or more devices 22. The computing system may communicate with other computing systems, devices, sensors, effectors, and the like via a network 24, such as the Internet, an intranet, or another suitable network.
  • In some embodiments, computing system 10 may include a personal computer, such as a desktop, laptop, or tablet personal computer, although other devices are within the scope of this disclosure. It should be understood that in some embodiments, operating system 18 may include one or more modules for providing at least some of the functionality provided by the herein described context store, context store API, and domain interpreters. In other embodiments, such functionality may be provided by modules designed to cooperate with an operating system (e.g., plug-ins to the operating system or third party applications).
  • It is to be understood that computing system 10 is illustrated and described in accordance with its application of serving as a context platform. The computing system may include additional and/or alternative components and/or software for providing other functionality. However, to avoid obfuscating the computing system's function as a context platform, the present disclosure does not include description of such components and software.
  • In the world of personal computing, a hierarchy of increasingly valuable functionality exists, starting from simple access and assistance, advancing to more compelling scenarios that include domain-specific and general advice, and further advancing to include sensory, cognitive, and social augmentation. Augmentation is the ability of a computing system to act intelligently as an agent on behalf of the user but under the supervision of the user. At the highest end of the spectrum is autonomy, the ability for a computing system to know what to do and take unsupervised action without prompting.
  • Access and assistance are relatively simple to achieve because the computing system need not know much about the environment. An increased level of contextual knowledge is needed in order for a computing system to provide advice, augmentation, or agency functionality. The herein disclosed context platform of computing system 10 provides an extensible framework which developers can utilize to improve access to and use of contextual knowledge, so as to more easily equip the computing system for providing adaption, advice, augmentation, or agency functionality.
  • Context is a complex concept and comes in many forms with a wide variation across a spectrum of complexity. For example, physical context can be derived from devices, location, senses, and other physical conditions or stimuli. Some physical context is relatively easy to assess (e.g., brightness of light falling on a light sensor or physical location measured by GPS). Other physical context is more difficult to assess (e.g., the concept of “darkness” is complex, it is not composed of simple sense data, but rather a combination of information, including the time of day, the season, transitory phenomena like cloudiness, and information about what a particular user considers to qualify as dark). In other words, the light falling on a photo-sensor is certain; it is a fact. In contrast, the notion that it is dark in a room or outside is uncertain; it is a belief, and one user may believe it is dark when another does not.
  • Social context is another example of context having a range of concepts that can be assessed with varying levels of ease. On one end of the spectrum, it is relatively easy to determine the number of people in a room and even who is in a room. It is more difficult to determine how two people are interacting in a social, work, or personal situation.
  • Within each of the physical and social realms, as well as intentional, mental, temporal, and preferential realms (among others), some contexts are discernable to some relatively higher degree of certainty, while others are discernable to a relatively lower degree of certainty. It is relatively easy to discern with some certainty a user's intentional context based on items in their to-do list or on their calendar. However, it is more difficult to discern with any certainty a user's intentions based on interpreting their emotions. Over time, knowledge of how to increase the certainty of such contexts will increase. The herein described context platform of computing system 10 provides an extensible framework for taking advantage of contextual knowledge in a virtually endless number of applications.
  • Context store 12 of FIG. 1 is configured to hold one or more context items 30, such as Context Item A, Context Item B, Context Item C, Context Item D, through Context Item n. It is to be understood that the context store can hold virtually any number of context items. Each context item may correspond to a physical phenomenon, logical condition, a relation, or other piece of information that can be processed to make contextual decisions.
  • The context store is the heart of the context platform. It is the one place that all context items may be instantiated, accessed, and/or updated. The context store serves as a central repository for all context items of the computing system. In some embodiments, the context store is configured to hold only state information, and is not intended to include a logic engine for processing information from the context store. Instead, domain interpreters 14 are configured to apply logic for altering context items in the context store and/or making other contextual decisions. Keeping state information separate from logical operations favors the extensibility of the context store, as a variety of different context items can be held by the same context store, even if such items correspond to diverse contextual concepts. As described in more detail below, standardization of the context store allows domain interpreters to instantiate, access, and/or update context items in a universally compatible manner, thus simplifying development of such domain interpreters. In other embodiments, domain interpreters may be included as part of the context store.
  • The context store may include a database, which may be comprised of computer-readable media (i.e., memory) holding or storing a structured collection of data (e.g., context items). In some embodiments, a computing system will use a locally located context store. In other embodiments, a computing system will use a remotely located context store, which, for example, may be accessed via a network. In still other embodiments, the context store may be physically located in two or more different locations (e.g., a distributed database), though presenting itself as a single storage location to the computing system.
  • The context store can be configured to suspend execution in the time between alterations to context items of the context store. In other words, because the context store may be implemented as a database that includes only state information, the context store need not concern itself with the logical operations that are instead performed by the domain interpreters. As such, the context store can be configured to not consume any processing cycles when suspended, thus decreasing energy requirements.
  • FIG. 2 schematically shows a more detailed view of context store 12. As shown by example with Context Item A and Context Item B, each context item includes a unique identifier (e.g., Unique ID A and Unique ID B) and one or more context-describing values (e.g., Context-Describing Value X, Context-Describing Value Y, and Context-Describing Value Z). Each context item may additionally or alternatively include a specification of how that context item is related to another context item. The unique identifier distinguishes a context item from all other context items.
  • In some embodiments, the Unique ID may be comprised of a composite ID including two or more different subparts. As a nonlimiting example, a Unique ID may include a user-id subpart, a context-id subpart, and a location-id subpart. In such a formulation, the context-id subpart may refer to a particular chain of coffee shops, for example, and all coffee shops in the chain may share the same context-id subpart. However, the location-id subpart may refer to a particular instance of the coffee shops (e.g., the coffee shop at a particular physical address). In this way, coffee shops at two different physical addresses will be associated with different location-id subparts. Such a formulation is provided as an example, and Unique IDs having different subpart clasifications are within the scope of this disclosure.
  • Each context item may be referred to by a unique ID, which may optionally be comprised of two or more subparts, and each context item may use one or more context-describing values to describe a context with which that context item is concerned and/or a relationship that context item may have with other context items. As a nonlimiting example, a current GPS position could be referred to as <GPS_position, [latitude, longitude]>. That context item may be a well-known public context description that is published by a context platform developer or a third party. That context may alternatively be a private context that is not published. In the above example, a party might want to refer to a different GPS position with more precision, such as <GPS_position_plus, [latitude, longitude, altitude, heading]>. As such, a new context item with a different unique identifier can be instantiated in the context store. Either context item is valid, and an application with suitable permissions can access one or both context items provided the application is made aware of the proper unique identifiers (e.g., GPS_position and/or GPS_position_plus).
  • In some embodiments, a context item may include an archival log of previous context-describing values. As a nonlimiting example, the context item may include a history of time-stamped values for one or more context-describing values, thus allowing a domain interpreter to analyze potential trends that can be used to more accurately assess a particular context.
  • As shown in FIG. 2, a context item may include additional information. As a nonlimiting example, Context Item A also includes a Friendly Name 40 providing a human-readable alias to the unique identifier; Permissions 42 defining the computing systems, users, or processes that have permission to access the context item; and a Subscribing-Consumers Listing 44 of context consumers subscribing to the context item.
  • In some embodiments, a context item may include a specification of how that context item is related to other context items. For example, a context item may exist for a particular coffee shop at a particular physical address. Such a coffee shop is a “kind-of” restaurant, which in turn is a “kind-of” business establishment, and so on up the chain of relations to a root “place.” Such “kind-of” relations may be specified as part of a context item. Relations other than “kind-of” relations may additionally or alternatively be specified as part of a context item. In some embodiments, relations may themselves form a context and may be defined as other contexts are defined in the context store.
  • The organization of objects, attributes, and/or values, and the relations between such objects, may be referred to as an ontology. As an example, a portion of such an ontology may include a “place,” which among other items, may include one or more “countries,” each of which may include, among other items, one or more “cities,” each of which may include, among other items, one or more business establishments, and such ontology can be further refined until a particular coffee shop at a particular physical address, for example, is included in the ontology. The above is provided as a nonlimiting example, and virtually any hierarchy can be established.
  • The relations set forth in an ontology may be specified in a relational manner with each particular context in the context store including a specification of the items that are above, below, or an the same level as that item in the hierarchy. The context store provides for the definition of an ontology, but can be used without such an ontology.
  • In some embodiments, a context item may include executable code for execution by the context store itself, or which may be passed to a context consumer or a context provider for execution.
  • A context item may include data that a user wishes to keep secret from one or more computing systems, users, or processes (e.g., a user may wish to keep his current location secret from all but a single trusted domain interpreter). Accordingly, Permissions 42 may optionally be associated with one or more context items, such Permissions including permissions data used to track which computing systems, users, or processes have been granted permission to access the context item. Such Permissions may be granted in varying degrees (e.g., read only, read/write, etc.). Getting or setting context-describing values for the context item can be forbidden to any computing system, user, or process not having permission to access the context item.
  • Subscribing-Consumers Listing 44 may be used to track which domain interpreters are interested in a particular context item. This allows, for example, such domain interpreters to be notified if changes are made to the context item. For each context consumer subscribing to a context item, the Consumer-Subscription Listing may include one or more subscription parameters indicating which alterations to context-describing values are to trigger a callback method. Furthermore, the Consumer-Subscription Listing may include, for each such subscription parameter, identification of the callback method to be triggered. In this way, a domain interpreter may register a callback method with the context item, thus allowing the context store to notify interested domain interpreters when changes are made.
  • As shown by example with Context Item B of FIG. 2, a context item representing a sensor may also include a Sensor Location 46. The Sensor Location may include an indication of a physical location of a sensor that has been used to supply the context item with information. For example, the Sensor Location may include an indication of a physical location of the sensor (or other context provider) that last updated a context-describing value of the context item. The Sensor Location can be used to discern information that may be relative to the context. As a nonlimiting example, the Sensor Location may include an indication allowing a domain interpreter to differentiate between a smoke detector in a bedroom and a smoke detector in a basement.
  • The above described parameters are nonlimiting examples of items that can be associated with and held as part of a context item. Nonlimiting examples of other information that may be held as part of a context item includes aging policy, persistence, depth, arbitration, and certainty. As another example, a context item may also include an inference source and possible definition (e.g., an indication of a method that a domain interpreter uses to establish the values and/or certainty factor for a particular context-describing value). It will be understood that a variety of different data can be included with a particular context item. A characteristic of the context store is the extensibility that permits a domain interpreter to define a new context that is represented differently from any others presently defined, while at the same time being able to take advantage of the same context items used by other domain interpreters.
  • FIG. 1 shows a plurality of domain interpreters 14 in operative communication with context store 12. Each domain interpreter may include one or more of a context provider 50 and a context consumer 60. In other words, some domain interpreters may include one or more context providers but no context consumers; some domain interpreters may include one or more context consumers but no context providers; and some domain interpreters may include both of one or more context providers and one or more context consumers.
  • Each context item held in the context store can be accessed, updated, or otherwise altered by one or more domain interpreters, as described in more detail below. Publishing definitions for context items allows domain interpreters to more easily share information amongst each other.
  • Each context provider of a domain interpreter, such as context provider 50 of FIG. 1, may be configured to output a context-describing value that can be held as part of a context item of the context store. In other words, a context provider can be used to feed information to a context item of the context store.
  • As illustrated, context provider 50 may include one or more sensors, such as sensor 52. Context providers may include virtually anything that can establish and maintain context items in the context store. As described in more detail below, sensors are a type of context provider that maintains information about the physical world in the context store. However, context providers other than sensors may also be used. A context provider may include a logic module configured to assign to a corresponding context-describing value of the context store a value derived from a logical operation. As an example, a logical provider may include an application that queries the state of another application, such as whether an e-mail is being read, and instantiates that state information in the context store.
  • Context providers may determine context from a wide variety of different sources, nonlimiting examples of which include:
  • Sensors (e.g., position, light, acceleration, humidity, temperature, traffic, etc.);
  • Devices (e.g., the number and/or types of devices connected to a computing system);
  • Connections (e.g., the types of available network access);
  • Software (e.g., the applications being used, and the states of such applications);
  • Data (e.g., information from calendar, to-do lists, preferences, contact lists, personal info, etc.);
  • Services (e.g., network services providing location by IP, traffic information, weather, news, etc.);
  • Declarative and interrogative (e.g., proactive instructions and instructions provided in response to a question or other request for input);
  • Inferences (e.g., algorithms, heuristics, predicate logic, fuzzy logic, neural networks, expert systems, Bayesian networks, etc.)
  • Relations (e.g. the relations between contexts, such as resides-in, contains, has-a, is-a, kind-of, etc.)
  • A context platform may be extensibly configured for compatibility with context providers that assess context using any one or more of the above listed techniques, as well as virtually any other suitable technique. While any one of the above techniques may be independently useful, additional value may be achieved when two or more context assessing techniques are considered collectively. As an example, a GPS sensor alone may be interesting, providing a coordinate location of a user. However, with the addition of information about the user's compass orientation and the direction that his eyes are looking, it may be possible to identify objects that are within the user's field of view. Those objects can then become a part of the collection of context items for the person or the place in which the person resides.
  • When present in a domain interpreter, a context provider may include a sensor configured to measure a quantifiable phenomenon of the physical world and assign to a corresponding context-describing value of the context store a quantified value of the phenomenon as measured.
  • Sensor devices are a particular case of context provider. Generally speaking, sensors may alter context, but generally do not respond to changes in context. Although changes in context may alter the ways in which a sensor analyzes or reports sensor data.
  • Sensor devices may interface with the context platform through a standard mechanism for discovering and connecting sensor class devices and for describing data from common types of sensors in a uniform but extendable manner. This mechanism works with either external or internal sensors. Furthermore, this mechanism does not force compliance with a particular bus standard.
  • External sensors can interface with the context platform through a sensor class driver by using a data description schema. In some embodiments, a sensor may use a custom driver that can accommodate different transports or additional processing corresponding to that sensor. The sensor platform may optionally calibrate and filter sensor data in addition to logging raw data.
  • Some sensors may include logical sources of data. In some embodiments, it is possible to use sensors or other devices that have no knowledge of the context platform. Rather than making those devices conform to a new driver standard, the context platform can offer proxy drivers that access device data and convert it into a form that is suitable for the context platform. This capability may enable device manufacturers to retrofit devices that produce nonstandard outputs.
  • Sensors can be classified by a location and a relationship relative to a user. As an example, sensors may include onboard sensors embedded within the enclosure of a computing system such as a mobile computer, a tablet computer, or the like. Such sensors may sense the environment relative to that enclosure. The sensed information may be related to conditions within the enclosure, such as temperature, fan speeds, and g-forces. The sensed information may also be related to conditions outside the enclosure. For example, a brightness sensor can be located at least partially inside the enclosure of a mobile computer, and such brightness sensor may detect ambient light levels outside the enclosure.
  • Sensors may include on-person sensors carried on or near the body of a person. Such sensors may sense the environment relative to that person. In other words, such sensors may effectively share with the context platform one or more of a person's five natural senses (i.e., sight, sound, smell, touch, taste). Such sensors often can provide improved and/or more accurate sense data than is naturally available to a user, and such sense data can be utilized by the context platform. In addition, sensors can be used to augment a person's senses, such as by providing the ability to sense compass orientation or the proximity to unseen objects and obstacles.
  • Sensors may include nearby sensors that can sense the physical world within a space relative to the sensors (e.g., same room or some nearby area). For example, such sensors can sense objects or sounds in a room and people moving about the space. Extending this concept to nearby space under a user's control, this class of sensors can sense a baby crying in an upstairs bedroom or motion occurring in any room in a house.
  • Sensors may include remote sensors that are not within the immediate vicinity of a user. Such sensors may sense private or public information that is important to a user. Private remote sensors include home automation sensors, which may be located at one or more locations of interest. Public remote sensors include traffic cameras, weather sensors, and other information that is often presented as a web service.
  • Each context consumer of a domain interpreter, such as context consumer 60 of FIG. 1, may be configured to input a context-describing value from a context item held in the context store and/or establish relations between those contexts. In other words, a context consumer can be used to retrieve information from a context item of the context store. Context consumers may include virtually any user-mode component that can query context items in the context store or subscribe to changes in context items in the context store. For example, a context consumer may subscribe to a context event that the context store fires when the context “at home” is fired in response to the user walking in the front door of her home.
  • In some embodiments, a consumer may subscribe to a collection of context items. For example, a ‘DEVICES’ collection could be defined, and a consumer could subscribe to the ‘DEVICES’ collection. In such a scenario, any device that comes into the system would register as a device, and subscribed consumers could be passed a message notifying the subscribed consumers of the device. This can be extended to include subscribing to any kind of collection, including, for example, the collection of every context in the system. In this way, consumers could remain aware of entrance to or exit from the system of any contexts in which they are interested. Effectors, such as effector 62 of FIG. 1, are a nonlimiting example type of context consumer. An effector device may be configured to alter a quantifiable phenomenon of the physical world in accordance with a context-describing value held in the context store. In other words, effectors are devices that can make changes in the physical world (e.g., closing a door, ringing a bell, opening a water valve, changing the brightness of a display, etc.). This is different than making changes in the logical world of a computer, which usually involves making changes in the state of software. While effectors are a type of context consumer, context consumers can include nonphysical logic modules configured to use information from the context store to perform one or more logical operations. Such logical operations can alter one or more values of the context store and/or such logical operations can be used to effectuate some action outside of the context store (e.g., change the state of an application).
  • The ability to sense the physical environment becomes particularly useful when combined with the ability to make changes in that environment. For example, being able to remotely sense that a garage door has been left open becomes very useful when coupled with the ability to remotely close the garage door. As such, context consumers may include logic modules and/or effectors that enhance the capabilities of the context platform.
  • Effector devices can be conceptualized as virtual mirror images of sensor devices. One consequence of such mirror-imaging is that sensor devices can be configured to have direct access to effector devices, as is schematically illustrated by arrow 70 of FIG. 1. While arrow 70 shows direct access between a context provider and a context consumer of the same domain interpreter, it should be understood that direct access may be established between a context provider of a different domain interpreter than a context consumer.
  • A domain-specific rules engine can be configured to allow an effector device to input data directly from a sensor device. In this way, developers can create real-time, high-bandwidth, control loops when desired. As a nonlimiting example, an accelerometer that senses acceleration of a laptop can send acceleration information directly to a hard drive so that the hard drive may park its heads in the event the laptop is dropped. Because it is advantageous to perform this action quickly, the direct communication between the sensor and the effector may be beneficial. Such direct communication may be established between other types of context providers and context consumers.
  • A sensor device with direct access to an effector device may allow a computing system to remain in a low power (e.g., sleep) state without interfering with the synergy between the sensor (or other context provider) and the effector (or other context consumer). If the only processing capability in the system is in the operating system, the operating system would need to be active to handle simple asynchronous processing tasks, such as ringing a bell when the doorbell is pressed. Smart sensor and effector devices can process such simple “reflex” events without needing to wake the operating system, which can greatly reduce average power requirements. The state or value of that direct ‘reflex’ connection may be instantiated in the context store as the value of a context item when the store awakens.
  • As shown in FIG. 1, computing system 10 may include a context store API 16. The context store API can be used to provide a domain interpreter access to context items in the context store. To this end, the context store API may enable a plurality of methods for interacting with the context store. Such methods may use the unique identifier of a context item as a parameter for accessing that context item.
  • Context providers can instantiate new context items in the store and/or all expected contexts may be instantiated without values, allowing context providers to supply values at a later time. Relations also may be predefined at startup and/or instantiated by providers at runtime.
  • A compatibility convention of a context item, including its unique identifier, may be published or otherwise made known to developers. As such, developers can design domain interpreters that access the context items of the context store using the unique identifier as a parameter, even though such domain interpreters may not initially have any knowledge of what other domain interpreters have worked with the context items. The context store API allows a single context item to be altered by different domain interpreters. This kind of system—a central store with a plethora of co-operating domain-specific “experts,” each contributing their domain knowledge or reasoning ability to the store—is sometimes called a blackboard system.
  • In some embodiments, the context store API may provide a context consumer direct access to data from a context provider without first holding data in the context store. Such a direct exchange can be used to decrease latency and/or improve energy consumption, as described above.
  • In some embodiments, the context store API may be described with pseudo-code having the form of method(CID, values), where CID is the unique identifier of a context item and values are context-describing values or other information associated with the context item. The following are example methods that may be included in a context store API.
  • New(CID); Add(CID, values); Remove(CID); Delete(CID); Clone(CID, CID′);
  • Get(CID, values); Set(CID, values); Update(CID, values);
  • Subscribe(CID, callback, ID); Unsubscribe(CID, ID)
  • Relate(CID1, CID2, relation); Unrelate(CID1, CID2, relation).
  • Also contemplated are methods for registering rules, enumerating unique identifiers, values, or attributes, finding relations, collecting related contexts, and searching friendly names, among others.
  • As shown in FIG. 3, a context store, or other aspect of a context platform, may include an arbitration engine 70 configured to resolve conflicting requests to change a context-describing value of a context item held in the context store. The arbitration engine may arbitrate changes to context items by using an algorithm (e.g., a domain-specific arbitration algorithm associated with a context item, a default arbitration algorithm associated with two or more different context items, a custom algorithm associated with one or more particular context providers, etc.). Possible arbitration mechanisms include prioritization, voting, most certain wins, least salient losses, and persistence of the most recent, to name a few.
  • Computing systems for implementing the herein described context platform may be variously configured while remaining within the scope of this disclosure. As discussed above, various aspects of such computing systems, including the context store and domain interpreters, may include hardware and software components. The domain interpreters may include peripheral devices, sensors, and/or independent computing devices. FIG. 4 schematically shows one example computing system 80 that can be used to implement a context platform. Computing system 80 includes a memory 82, a logic subsystem 84, and an I/O subsystem 86. It should be understood that computing system 80 may include several components, subsystems, and software modules not shown.
  • Logic subsystem 84 may be configured to execute one or more instructions. For example, the logic subsystem may be configured to execute one or more instructions that are part of one or more programs, routines, objects, components, data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement an abstract data type, or otherwise arrive at a desired result. In particular, such instructions may provide the context store, context store API, and/or domain interpreter functionality described above. The logic subsystem may include one or more processors that are configured to execute software instructions. Additionally or alternatively, the logic subsystem may include one or more hardware or firmware logic machines configured to execute hardware or firmware instructions. The logic subsystem may optionally include individual components that are distributed throughout two or more devices, which may be remotely located in some embodiments.
  • Memory 82 may be a device configured to hold instructions that, when executed by the logic subsystem, cause the logic subsystem to implement the herein described methods and processes. Memory 82 may include volatile portions and/or nonvolatile portions. In some embodiments, memory 82 may include two or more different devices that may cooperate with one another to hold instructions for execution by the logic subsystem. In some embodiments, logic subsystem 84 and memory 82 may be integrated into one or more common devices and/or computing systems.
  • I/O subsystem 86 may be configured to communicatively couple computing system 80 with one or more sensors, effectors, peripheral devices, networked computing devices, or other distinct entities. Such communication may be established using virtually any communication technology (e.g., USB, IEEE 1394, IEEE 802.3, IEEE 802.11x, IEEE 802.15, etc.).
  • FIG. 5 shows a process flow of a method 90 of providing a plurality of domain interpreters universal access to a common context store. At 92, method 90 includes publishing a compatibility-convention for defining one or more contextual concepts as context items. Such a compatibility convention may that each context item includes at least a unique identifier and one or more context-describing values. At 94, method 90 includes holding one or more context items in a common context store. Each context item can be held in accordance with the compatibility-convention published for that context item. At 96, method 90 includes granting provider access to one or more domain interpreters including a context provider configured to set a context-describing value of a context item in the context store. In some embodiments, provider access is granted to one or more domain interpreters via an application programming interface. At 98, method 90 includes granting consumer access to one or more domain interpreters including a context consumer configured to get a context-describing value of a context item from the context store.
  • It will be appreciated that the embodiments described herein may be implemented, for example, via computer-executable instructions or code, such as programs, stored on computer-readable storage media and executed by a computing device. Generally, programs include routines, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. As used herein, the term “program” may connote a single program or multiple programs acting in concert, and may be used to denote applications, services, or any other type or class of program. Likewise, the terms “computer,” “computing device,” “computing system,” and the like include any device that electronically executes one or more programs, including two or more such devices acting in concert.
  • A domain translator can reside on the same machine(s) as the context store and/or a domain translator may be remote from the context store. Domain translators may include domain specific processing elements (e.g., hardware, software, and/or firmware) and can be local or remote.
  • It should be understood that the configurations and/or approaches described herein are exemplary in nature, and that these specific embodiments or examples are not to be considered in a limiting sense, because numerous variations are possible. The specific routines or methods described herein may represent one or more of any number of processing strategies. As such, various acts illustrated may be performed in the sequence illustrated, in other sequences, in parallel, or in some cases omitted. Likewise, the order of the above-described processes may be changed.
  • The subject matter of the present disclosure includes all novel and nonobvious combinations and subcombinations of the various processes, systems and configurations, and other features, functions, acts, and/or properties disclosed herein, as well as any and all equivalents thereof.

Claims (20)

1. A computing machine, comprising:
a network-accessible context store holding a plurality of different context items, each context item including one or more context-describing values;
an input for receiving a context-describing value from a context provider via a communication network, the context-describing value assignable to a context item of the network-accessible context store, the context item configured to receive context-describing values from different context providers;
an arbitration engine configured to resolve conflicting requests to assign a context-describing value to a context item held in the network-accessible context store; and
an output for sending a context-describing value from a context item of the network-accessible context store to a context consumer via the communication network.
2. The computing machine of claim 1, where a context item of the plurality of context items includes permissions defining computing systems, users, or processes that have permission to access the context item, and where getting or setting context-describing values for the context item is forbidden to any computing system, user, or process not having permission to access the context item.
3. The computing machine of claim 1, where a context item of the plurality of context items includes a listing of context consumers subscribing to the context item.
4. The computing machine of claim 3, where the context item includes, for each context consumer subscribing to the context item, subscription parameters indicating which alterations to context-describing values are to trigger a callback method.
5. The computing machine of claim 4, where the context item includes, for each subscription parameter, identification of the callback method to be triggered.
6. The computing machine of claim 1, where a context item of the plurality of context items includes a specification of how the context item is related to another context item.
7. The computing machine of claim 1, where a context item includes a friendly name providing a human-readable identification of the context item.
8. The computing machine of claim 1, where a context item includes an indication of a physical location of a sensor of the context provider that last updated a context-describing value of the context item.
9. The computing machine of claim 1, where the context item includes an archival log of previous context-describing values.
10. The computing machine of claim 1, where the network-accessible context store is configured to hold only state information, and where domain interpreters are configured to apply logic for altering context items in the network-accessible context store.
11. The computing machine of claim 1, where the context-describing value is a quantified value of a physical world phenomenon measured by a sensor of the context provider.
12. The computing machine of claim 1, where the context-describing value is derived from a logical operation performed by a logic module of the context provider.
13. The computing machine of claim 1, where the context-describing value is useable by an effector device of the context consumer to alter a quantifiable phenomenon of a physical world.
14. The computing machine of claim 1, where the network-accessible context store is configured to suspend execution between context-describing value inputs and outputs.
15. The computing machine of claim 14, where the network-accessible context store is configured to not consume any processing cycles when suspended.
16. The computing machine of claim 1, where at least one of the plurality of context items is defined differently than any other context item held by the network-accessible context store.
17. A computing machine, comprising:
a network-accessible context store holding a plurality of different context items, each context item including one or more context-describing values, and at least one of the plurality of context items defined differently than any other context item held by the network-accessible context store;
an input for receiving a context-describing value from a context provider via a communication network, the context-describing value assignable to a context item of the network-accessible context store, the context item configured to receive context-describing values from different context providers; and
an output for sending a context-describing value from a context item of the network-accessible context store to a context consumer via the communication network.
18. A computer-executable method of managing context for a plurality of different domain interpreters, the method comprising:
receiving, at a computing device, a first context-describing value from a context provider via a communication network;
receiving, at the computing device, a second context-describing value from a context provider via the communication network, the second context-describing value conflicting with the first context-describing value;
arbitrating, at the computing device, conflicting requests to assign the first context-describing value and the second context-describing value to a context item held in a network-accessible context store;
assigning, at the computing device, an arbitration-winning context-describing value selected from the first context-describing value and the second context-describing value to the context item; and
responsive to receiving a request from a context consumer, outputting, from the computing device, the arbitration-winning context-describing value of the context item to the context consumer via the communication network.
19. The method of claim 18, where arbitrating conflicting requests includes arbitrating based on prioritization of context provider from which context-describing value is received.
20. The method of claim 18, where arbitrating conflicting requests includes selecting a last received context-describing value.
US13/927,062 2008-06-24 2013-06-25 Context platform Abandoned US20130290247A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US13/927,062 US20130290247A1 (en) 2008-06-24 2013-06-25 Context platform

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12/144,640 US8516001B2 (en) 2008-06-24 2008-06-24 Context platform
US13/927,062 US20130290247A1 (en) 2008-06-24 2013-06-25 Context platform

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US12/144,640 Continuation US8516001B2 (en) 2008-06-24 2008-06-24 Context platform

Publications (1)

Publication Number Publication Date
US20130290247A1 true US20130290247A1 (en) 2013-10-31

Family

ID=41432339

Family Applications (2)

Application Number Title Priority Date Filing Date
US12/144,640 Active 2030-10-24 US8516001B2 (en) 2008-06-24 2008-06-24 Context platform
US13/927,062 Abandoned US20130290247A1 (en) 2008-06-24 2013-06-25 Context platform

Family Applications Before (1)

Application Number Title Priority Date Filing Date
US12/144,640 Active 2030-10-24 US8516001B2 (en) 2008-06-24 2008-06-24 Context platform

Country Status (1)

Country Link
US (2) US8516001B2 (en)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8516001B2 (en) * 2008-06-24 2013-08-20 Microsoft Corporation Context platform
US20110071971A1 (en) * 2009-09-22 2011-03-24 Microsoft Corporation Multi-level event computing model
US9390403B2 (en) * 2012-02-09 2016-07-12 International Business Machines Corporation Augmented screen sharing in an electronic meeting
US9325792B2 (en) 2012-11-07 2016-04-26 Microsoft Technology Licensing, Llc Aggregation framework using low-power alert sensor
US9671468B2 (en) 2012-11-07 2017-06-06 Microsoft Technology Licensing, Llc Battery with computing, sensing and communication capabilities
JP6417654B2 (en) * 2013-10-30 2018-11-07 富士ゼロックス株式会社 Document recommendation program and apparatus
US9756091B1 (en) * 2014-03-21 2017-09-05 Google Inc. Providing selectable content items in communications
US9111221B1 (en) 2014-08-06 2015-08-18 Belkin International, Inc. Detector devices for presenting notifications and supporting context inferences
US11190400B2 (en) 2014-08-06 2021-11-30 Belkin International, Inc. Identifying and automating a device type using image data
US10176457B2 (en) 2015-02-05 2019-01-08 Sap Se System and method automatically learning and optimizing sequence order
US10419540B2 (en) 2015-10-05 2019-09-17 Microsoft Technology Licensing, Llc Architecture for internet of things

Citations (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5418888A (en) * 1992-06-04 1995-05-23 Alden; John L. System for revelance criteria management of actions and values in a rete network
US5877746A (en) * 1995-11-16 1999-03-02 Apple Computer, Inc. User interface for all-in-one integrated office system
US20020120370A1 (en) * 2000-12-22 2002-08-29 Gopal Parupudi Context-aware systems and methods, location-aware systems and methods, context-aware vehicles and methods of operating the same, and location-aware vehicles and methods of operating the same
US20020122055A1 (en) * 2000-12-22 2002-09-05 Gopal Parupudi Environment-interactive context-aware devices and methods
US20020198829A1 (en) * 2001-04-03 2002-12-26 Bottomline Technologies, Inc. Modular business transactions platform
US20040117436A1 (en) * 2002-12-12 2004-06-17 Xerox Corporation Methods, apparatus, and program products for utilizing contextual property metadata in networked computing environments
US20050084082A1 (en) * 2003-10-15 2005-04-21 Microsoft Corporation Designs, interfaces, and policies for systems that enhance communication and minimize disruption by encoding preferences and situations
US20050149342A1 (en) * 2003-12-24 2005-07-07 International Business Machines Corporation Method and apparatus for creating and customizing plug-in business collaboration protocols
US20050216302A1 (en) * 2004-03-16 2005-09-29 Icontrol Networks, Inc. Business method for premises management
US20050240943A1 (en) * 2001-07-10 2005-10-27 Microsoft Corporation Application program interface for network software platform
US20060140205A1 (en) * 2004-12-07 2006-06-29 Baik Seoung H Intelligent management apparatus and method of digital home network system
US7080322B2 (en) * 1998-12-18 2006-07-18 Tangis Corporation Thematic response to a computer user's context, such as by a wearable personal computer
US7092928B1 (en) * 2000-07-31 2006-08-15 Quantum Leap Research, Inc. Intelligent portal engine
US20060279772A1 (en) * 2005-06-14 2006-12-14 Bottomline Technologies (De) Inc. Secure web based system for generating a printed document at a remote printer
US20070268200A1 (en) * 2006-05-22 2007-11-22 Microsoft Corporation Auxiliary display within a primary display system
US7376658B1 (en) * 2005-04-11 2008-05-20 Apple Inc. Managing cross-store relationships to data objects
US7483882B1 (en) * 2005-04-11 2009-01-27 Apple Inc. Dynamic management of multiple persistent data stores
US20090083768A1 (en) * 2007-09-20 2009-03-26 Hatalkar Atul N Context platform framework for aggregation, analysis and use of contextual information
US20090204576A1 (en) * 2008-02-08 2009-08-13 Daniel Paul Kolz Constructing a Domain-Specific Ontology by Mining the Web
US20090261978A1 (en) * 2005-12-06 2009-10-22 Hyun-Jeong Lee Apparatus and Method of Ubiquitous Context-Aware Agent Based On Sensor Networks
US20090297126A1 (en) * 2008-06-02 2009-12-03 Apple Inc. System and method of generating a media package for ingesting into an on-line downloading application
US20090319569A1 (en) * 2008-06-24 2009-12-24 Microsoft Corporation Context platform
US7725628B1 (en) * 2004-04-20 2010-05-25 Lexar Media, Inc. Direct secondary device interface by a host
US20130339232A1 (en) * 2005-10-06 2013-12-19 C-Sam, Inc. Widget framework for securing account information for a plurality of accounts in a wallet

Family Cites Families (54)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5764928A (en) * 1994-09-30 1998-06-09 Rosemount Inc. Microprocessor communication protocol in a multiprocessor transmitter
US5737557A (en) * 1995-05-26 1998-04-07 Ast Research, Inc. Intelligent window user interface for computers
US5778150A (en) * 1996-07-01 1998-07-07 International Business Machines Corporation Flexible procedural attachment to situate reasoning systems
US6223214B1 (en) * 1996-09-06 2001-04-24 Sensiview Corporation Computer implemented virtual sensor object and tangible medium utilizing same
US6013108A (en) * 1997-03-18 2000-01-11 Endevco Corporation Intelligent sensor system with network bus
US7076737B2 (en) * 1998-12-18 2006-07-11 Tangis Corporation Thematic response to a computer user's context, such as by a wearable personal computer
US6842877B2 (en) * 1998-12-18 2005-01-11 Tangis Corporation Contextual responses based on automated learning techniques
US7046263B1 (en) * 1998-12-18 2006-05-16 Tangis Corporation Requesting computer user's context data
US6920616B1 (en) * 1998-12-18 2005-07-19 Tangis Corporation Interface for exchanging context data
US6791580B1 (en) * 1998-12-18 2004-09-14 Tangis Corporation Supplying notifications related to supply and consumption of user context data
US6747675B1 (en) * 1998-12-18 2004-06-08 Tangis Corporation Mediating conflicts in computer user's context data
US6801223B1 (en) * 1998-12-18 2004-10-05 Tangis Corporation Managing interactions between computer users' context models
US7225229B1 (en) * 1998-12-18 2007-05-29 Tangis Corporation Automated pushing of computer user's context data to clients
US7107539B2 (en) * 1998-12-18 2006-09-12 Tangis Corporation Thematic response to a computer user's context, such as by a wearable personal computer
US6466232B1 (en) * 1998-12-18 2002-10-15 Tangis Corporation Method and system for controlling presentation of information to a user based on the user's condition
US7779015B2 (en) * 1998-12-18 2010-08-17 Microsoft Corporation Logging and analyzing context attributes
US7231439B1 (en) * 2000-04-02 2007-06-12 Tangis Corporation Dynamically swapping modules for determining a computer user's context
US6513046B1 (en) * 1999-12-15 2003-01-28 Tangis Corporation Storing and recalling information to augment human memories
US6812937B1 (en) * 1998-12-18 2004-11-02 Tangis Corporation Supplying enhanced computer user's context data
US7055101B2 (en) * 1998-12-18 2006-05-30 Tangis Corporation Thematic response to a computer user's context, such as by a wearable personal computer
US7073129B1 (en) * 1998-12-18 2006-07-04 Tangis Corporation Automated selection of appropriate information based on a computer user's context
US7356580B1 (en) * 2000-03-30 2008-04-08 Lam Research Corporation Plug and play sensor integration for a process module
WO2001075676A2 (en) * 2000-04-02 2001-10-11 Tangis Corporation Soliciting information based on a computer user's context
US7464153B1 (en) * 2000-04-02 2008-12-09 Microsoft Corporation Generating and supplying user context data
DE10030845B4 (en) * 2000-06-23 2008-11-20 Abb Ag Fieldbus connection system for actuators or sensors
GB2386724A (en) * 2000-10-16 2003-09-24 Tangis Corp Dynamically determining appropriate computer interfaces
US20020054130A1 (en) * 2000-10-16 2002-05-09 Abbott Kenneth H. Dynamically displaying current status of tasks
US20020078382A1 (en) * 2000-11-29 2002-06-20 Ali Sheikh Scalable system for monitoring network system and components and methodology therefore
US20020073340A1 (en) * 2000-12-12 2002-06-13 Sreenath Mambakkam Secure mass storage device with embedded biometri record that blocks access by disabling plug-and-play configuration
US7296042B2 (en) * 2001-04-20 2007-11-13 Palo Alto Research Center Incorporated System and method for enabling communication among arbitrary components
US20050101841A9 (en) * 2001-12-04 2005-05-12 Kimberly-Clark Worldwide, Inc. Healthcare networks with biosensors
US6771208B2 (en) * 2002-04-24 2004-08-03 Medius, Inc. Multi-sensor system
US7134994B2 (en) * 2002-05-20 2006-11-14 Volcano Corporation Multipurpose host system for invasive cardiovascular diagnostic measurement acquisition and display
US6810363B2 (en) * 2002-12-12 2004-10-26 Xerox Corporation Methods, apparatus, and program products for analyzing context in a networked computing environment
EP1484716A1 (en) * 2003-06-06 2004-12-08 Sony France S.A. An architecture for self-developing devices
US20040266480A1 (en) * 2003-06-27 2004-12-30 Hjelt Kari Tapani System and method for implementing sensor functionality in mobile devices
US20070162957A1 (en) * 2003-07-01 2007-07-12 Andrew Bartels Methods, systems and devices for securing supervisory control and data acquisition (SCADA) communications
US7315791B2 (en) * 2004-02-18 2008-01-01 National Instruments Corporation Application programming interface for synchronizing multiple instrumentation devices
US7149660B2 (en) * 2005-02-17 2006-12-12 The Boeing Company Sensor application integration framework (SAIF)
EP1785933A3 (en) * 2005-04-29 2008-04-09 Angelo Dalli Method and apparatus for displaying processed multimedia and textual content on electronic signage or billboard displays through input from electronic communication networks
US7233830B1 (en) * 2005-05-31 2007-06-19 Rockwell Automation Technologies, Inc. Application and service management for industrial control devices
JP2006344017A (en) * 2005-06-09 2006-12-21 Hitachi Ltd Sensor network system and data processing method for sensor network system
US7856661B1 (en) * 2005-07-14 2010-12-21 Mcafee, Inc. Classification of software on networked systems
US8355804B2 (en) * 2005-09-15 2013-01-15 Honda Motor Co., Ltd. Interface for sensor query and control
WO2007098468A1 (en) * 2006-02-21 2007-08-30 University Of Florida Research Foundation Inc. Modular platform enabling heterogeneous devices, sensors and actuators to integrate automatically into heterogeneous networks
US8015547B2 (en) * 2006-06-29 2011-09-06 Augusta Systems, Inc. Reconfigurable, hierarchical component-based architecture and framework and methods for rapidly developing sensor device-enabling software applications
US7765203B2 (en) * 2006-09-11 2010-07-27 International Business Machines Corporation Implicit context collection and processing
US8953567B2 (en) * 2006-10-20 2015-02-10 T—Mobile USA, Inc. System and method for utilizing IP-based wireless telecommunications client location data
US7730198B2 (en) * 2006-11-10 2010-06-01 Bally Gaming, Inc. UDP broadcast for user interface in a download and configuration gaming method
JP2010514028A (en) * 2006-12-22 2010-04-30 バーチャルロジックス エスエイ A system that enables multiple execution environments to share a single data process
US9202357B2 (en) * 2007-03-13 2015-12-01 Oracle International Corporation Virtualization and quality of sensor data
KR100874652B1 (en) * 2007-06-26 2008-12-17 한국전자통신연구원 Integrated interface apparatus and method for various sensor network
US7769767B2 (en) * 2007-09-27 2010-08-03 Domingo Enterprises, Llc System and method for filtering content on a mobile device based on contextual tagging
US20090236346A1 (en) * 2008-03-22 2009-09-24 Albert John Hofeldt Article for storing and dispensing food

Patent Citations (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5418888A (en) * 1992-06-04 1995-05-23 Alden; John L. System for revelance criteria management of actions and values in a rete network
US5877746A (en) * 1995-11-16 1999-03-02 Apple Computer, Inc. User interface for all-in-one integrated office system
US7080322B2 (en) * 1998-12-18 2006-07-18 Tangis Corporation Thematic response to a computer user's context, such as by a wearable personal computer
US7092928B1 (en) * 2000-07-31 2006-08-15 Quantum Leap Research, Inc. Intelligent portal engine
US20020120370A1 (en) * 2000-12-22 2002-08-29 Gopal Parupudi Context-aware systems and methods, location-aware systems and methods, context-aware vehicles and methods of operating the same, and location-aware vehicles and methods of operating the same
US20020122055A1 (en) * 2000-12-22 2002-09-05 Gopal Parupudi Environment-interactive context-aware devices and methods
US20020198829A1 (en) * 2001-04-03 2002-12-26 Bottomline Technologies, Inc. Modular business transactions platform
US20050240943A1 (en) * 2001-07-10 2005-10-27 Microsoft Corporation Application program interface for network software platform
US20040117436A1 (en) * 2002-12-12 2004-06-17 Xerox Corporation Methods, apparatus, and program products for utilizing contextual property metadata in networked computing environments
US20050084082A1 (en) * 2003-10-15 2005-04-21 Microsoft Corporation Designs, interfaces, and policies for systems that enhance communication and minimize disruption by encoding preferences and situations
US20050149342A1 (en) * 2003-12-24 2005-07-07 International Business Machines Corporation Method and apparatus for creating and customizing plug-in business collaboration protocols
US20050216302A1 (en) * 2004-03-16 2005-09-29 Icontrol Networks, Inc. Business method for premises management
US7725628B1 (en) * 2004-04-20 2010-05-25 Lexar Media, Inc. Direct secondary device interface by a host
US20060140205A1 (en) * 2004-12-07 2006-06-29 Baik Seoung H Intelligent management apparatus and method of digital home network system
US7483882B1 (en) * 2005-04-11 2009-01-27 Apple Inc. Dynamic management of multiple persistent data stores
US7376658B1 (en) * 2005-04-11 2008-05-20 Apple Inc. Managing cross-store relationships to data objects
US20060279772A1 (en) * 2005-06-14 2006-12-14 Bottomline Technologies (De) Inc. Secure web based system for generating a printed document at a remote printer
US20130339232A1 (en) * 2005-10-06 2013-12-19 C-Sam, Inc. Widget framework for securing account information for a plurality of accounts in a wallet
US20090261978A1 (en) * 2005-12-06 2009-10-22 Hyun-Jeong Lee Apparatus and Method of Ubiquitous Context-Aware Agent Based On Sensor Networks
US20070268200A1 (en) * 2006-05-22 2007-11-22 Microsoft Corporation Auxiliary display within a primary display system
US20090083768A1 (en) * 2007-09-20 2009-03-26 Hatalkar Atul N Context platform framework for aggregation, analysis and use of contextual information
US20090204576A1 (en) * 2008-02-08 2009-08-13 Daniel Paul Kolz Constructing a Domain-Specific Ontology by Mining the Web
US20090297126A1 (en) * 2008-06-02 2009-12-03 Apple Inc. System and method of generating a media package for ingesting into an on-line downloading application
US20090319569A1 (en) * 2008-06-24 2009-12-24 Microsoft Corporation Context platform

Also Published As

Publication number Publication date
US20090319569A1 (en) 2009-12-24
US8516001B2 (en) 2013-08-20

Similar Documents

Publication Publication Date Title
US8516001B2 (en) Context platform
US11544273B2 (en) Constructing event distributions via a streaming scoring operation
Bu et al. Managing quality of context in pervasive computing
KR20170015129A (en) Computing system with privacy control mechanism and method of operation thereof
US20160103996A1 (en) Methods and Systems for Behavioral Analysis of Mobile Device Behaviors Based on User Persona Information
US20200019635A1 (en) Constructing Distributions of Interrelated Event Features
KR20070037281A (en) Rules framework for definition and execution of end-user rules logic
WO2017019467A1 (en) Inferring logical user locations
Parate et al. Leveraging graphical models to improve accuracy and reduce privacy risks of mobile sensing
Fogarty et al. Toolkit support for developing and deploying sensor-based statistical models of human situations
Luger et al. Terms of agreement: Rethinking consent for pervasive computing
El Allioui et al. User profile Ontology for the Personalization approach
Pradeep et al. Conflict detection and resolution in IoT systems: A survey
Alom et al. Helping users managing context-based privacy preferences
Riboni et al. Context provenance to enhance the dependability of ambient intelligence systems
Trăscău et al. Detecting activities of daily living using the CONSERT engine
Chiang et al. Culture as a sensor? A novel perspective on human activity recognition
Baldoni et al. An embedded middleware platform for pervasive and immersive environments for-all
Hartmann et al. Context models and context awareness
Pallapa et al. A scheme for quantizing privacy in context-aware ubiquitous computing
Gerbert-Gaillard et al. Self-aware model-driven pervasive systems
Huynh et al. Towards an Ambient Data Mediation System.
Chehab LP-SBA-XACML.(c2019)
Dobre A Platform to Support Context-Aware Mobile Applications
Xu et al. A smart brain: an intelligent context inference engine for context-aware middleware

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034544/0541

Effective date: 20141014

STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION