JP2006039750A - Method, system, and program for managing device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a method, system and program for managing a device according to the circumstances of a user without using any help from a user. <P>SOLUTION: The explicit execution configurations of this invention include a means for managing a device. This explicit method comprises a step for receiving a plurality of user metrics, a step for generating relevant metrics according to a plurality of user metrics, a step for generating user metrics vectors having at least one user metrics and at least one relevant metrics, a step for generating a user metrics space having a plurality of metrics ranges and a step for deciding whether or not the user metrics vectors are outside the user metrics space. When the user metrics vectors are outside the user metrics space, the explicit execution configurations include a step for identifying actions and a step for executing actions. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The scope of the present invention is data processing, and more specifically, methods, systems, and programs for managing devices.

  Conventional networks include various devices. The user often uses various devices or adjusts specific settings of the device according to the user's current situation. That is, in many cases, the user's current situation is motivated, and the user changes the settings of the device so that the device operates in a way that is more positively useful for the current situation. For example, a user with a headache may feel discomfort due to strong light. The user can weaken or turn off the light so that it is not bothered by the light. However, in a conventional network connection device, a user needs to intervene in order to manage a specific device individually in response to the user's situation.

It would be advantageous if there was a way to manage the device according to the user's situation without requiring user intervention.

  An exemplary embodiment of the present invention includes a device management method. Such an exemplary method includes receiving a plurality of user metrics, generating a relational metric based on the plurality of user metrics, at least one user metric and at least one association. Generating a user metric vector having a metric; generating a user metric space having a plurality of metric ranges; and determining whether the user metric vector is outside the user metric space. If the user metric vector is outside the user metric space, an exemplary embodiment includes identifying an action and performing the action.

  In many exemplary embodiments, generating an associated metric based on a plurality of user metrics includes filtering user metrics. In some exemplary embodiments, generating an associated metric based on a plurality of user metrics includes determining a relationship between a first filtered user metric and a second filtered user metric. Including. In some embodiments, the step of determining a relationship between the first filtered user metric and the second filtered user metric compares the first filtered user metric with the second filtered user metric. Including the steps of: In many exemplary embodiments, generating an associated metric in response to a plurality of user metrics determines the magnitude of the relationship between the first filtered user metric and the second filtered user metric. Includes steps.

  In some exemplary embodiments, generating an associated metric based on a plurality of user metrics includes determining whether the plurality of user metrics match a predetermined metric pattern. Many such embodiments include searching for a related metric if multiple user metrics match a predefined metric pattern. In some exemplary embodiments, generating a user metric vector including at least one user metric and at least one related metric includes associating at least one user metric with the user metric vector, and at least one Associating an associated metric with a user metric vector.

In some exemplary embodiments, identifying actions includes determining a user's location, selecting an action ID based on the user's location,
including. In many such embodiments, identifying an action includes determining a user movement and selecting an action ID based on the user movement.

  The foregoing and other objects, features and advantages of the present invention will be apparent from the following specific description of exemplary embodiments of the invention as illustrated in the accompanying drawings. In the drawings, like reference numbers generally refer to like parts of exemplary embodiments of the invention.

Introduction The present invention is described in detail herein in terms of device management methods. However, those skilled in the art will recognize that any computer system that includes suitable programming means that operates in accordance with the disclosed methods falls within the scope of the present invention.

  Suitable program means include any means for instructing the computer system to perform the steps of the method of the invention. This is, for example, a system comprising a processing unit and an arithmetic logic circuit coupled to a computer memory and having a function of storing in the computer memory. This computer memory is executed by data and program instructions, the processing unit. Including an electronic circuit configured to store program steps of the method of the present invention. The invention can also be embodied in computer program products such as diskettes or other recording media for use with any suitable data processing system.

  Embodiments of a computer program product can be implemented by using any recording medium for machine readable information, including magnetic media, optical media, or other suitable media. Those skilled in the art will readily recognize that any computer system having suitable programming means can perform the steps of the method of the invention embodied in a program product. Although most of the exemplary embodiments described herein are directed to software that is installed and executed on computer hardware, alternative embodiments implemented as firmware or hardware are contemplated by the present invention. It will be readily appreciated by those skilled in the art that it is within range.

Definitions “802.11” refers to a specification family developed by IEEE for wireless LAN technology. 802.11 defines a radio interface between a wireless client and a base station or between two wireless clients.

  “API” is an abbreviation for “application programming interface”. An API is a collection of routines, protocols, and tools for building software applications.

  “Bluetooth” refers to the industry specification of short-range wireless technology for RF coupling between client devices or between client devices and resources over a LAN or other network. A management organization called the Bluetooth Special Interest Group tests and certifies Bluetooth-compliant devices. The Bluetooth specification consists of “FoundationCore” that provides design specifications and “FoundationProfile” that provides guidelines for interoperability.

  “Coupling for data communication” includes wireless, 802.11b, Bluetooth, infrared, wireless, Internet protocol, HTTP protocol, email protocol, network connection, direct connection, dedicated telephone line, dial-up, RS-232 (EIA232 Or any other form of data connection, such as a serial connection via a universal serial bus, a parallel port connection via wiring, a network connection according to the power line protocol, and other forms of connection for data communication as will occur to those skilled in the art Means. Coupling for data communication includes coupling through a network connection for data communication. Examples of networks useful in various embodiments of the present invention include cable networks, intranets, extranets, the Internet, local area networks, wide area networks, and other network configurations as will occur to those skilled in the art. The use of coupling by any network connection between television channels, cable channels, video providers, telecommunications sources, etc. is within the scope of the present invention.

  “Driver” means a program for controlling a device. Devices (printers, disk drives, keyboards) usually have drivers. The driver functions as a translator between the device and a software program that uses the device. Each device has a dedicated set of commands that its driver knows. Software programs typically access devices by using general commands. Thus, the driver receives generic commands from the program and then translates them into dedicated commands for the device.

  “ESN” is an abbreviation for “electronic serial number”. The ESN is a serial number that is programmed in a device such as a coffee pot and uniquely identifies the device.

  "field". In this specification, the terms “field” and “data element” are generally used synonymously and refer to individual elements of digital data unless the context indicates otherwise. A set of data elements is referred to as a “record” or “data structure”. A set of records is referred to as a “table” or “file”. A collection of files or tables is referred to as a “database”. In addition to data elements, complex data structures that contain member methods, functions, or software routines are referred to as “classes”. An instance of a class is referred to as an “object” or “class object”.

  “HAVi” stands for “Home AudioVideo Interoperability” and is the name of a vendor-neutral audio-video standard, particularly for home entertainment environments. With HAVi, different home entertainment and communication devices (VCRs, televisions, stereos, security systems, video monitors, etc.) can be networked and controlled from one main device such as a service gateway, PC, television, etc. Using the IEEE 1394 or “Firewire” specification as an interconnection medium, HAVi allows products from different vendors to adapt to each other based on defined connection and communication protocols and APIs. Services provided by HAVi's distributed application system include addressing scheme and message transfer, lookup for resource discovery, notification and reception of local or remote events, and streaming and control of isochronous data streams.

  “HomePlug” represents the HomePlug Powerline Alliance. HomePlug is a non-profit organization formed to provide a forum for the creation of open specifications for high-speed home power line networking products and services. The HomePlug specification is designed to deliver Internet communications and multimedia to homes via a household power outlet using the power line network connection standard.

  The HomePlug protocol allows HomePlug compatible devices to communicate over power lines using radio frequency signals (RF). The HomePlug protocol uses Orthogonal Frequency Division Multiplexing (OFDM) to divide the RF signal into a number of smaller sub-signals that are separated from one HomePlug-enabled device at different frequencies over the power line. Send to a HomePlug compatible device.

  “HTTP” stands for “Hyper Text Transport Protocol” and is a standard data communication protocol for the World Wide Web.

  “ID” is an abbreviation for “identification” and is used herein with nouns that are customarily represented in data elements. Therefore, “user ID” indicates the identifier of the user, and “userID” is the name of the data element in which the user identifier is stored. In yet another example of the use of “ID”, “metric ID” is a metric identifier and “metricID” is the name of the data element in which the metric identifier is stored.

  “IEEE1394” is an external bus standard that supports data transfer rates up to 400 Mbps (400 million bits per second). Apple, which first developed IEEE 1394, uses the trade name “FireWire”. Other companies use other names such as i.link and Lynx to represent their 1394 products.

  A single 1394 port can be used to connect up to 63 external devices. In addition to being fast, 1394 supports isochronous data transfer. That is, data is transmitted at a guaranteed speed. This is ideal for devices that need to transfer high levels of data in real time, such as video.

  “Internet” is a global network for connecting a large number of computers, and “Internet protocol”, that is, “IP” is used as a network layer of a network connection protocol stack. The Internet is decentralized by design. Each computer on the Internet is independent. The operator of each computer on the Internet can select which Internet service to use and which local service is available to the global Internet community. There are various ways to access the Internet. Many online services, such as America Online, provide access to several Internet services. It can also be accessed by a commercial internet service provider (ISP). An “internet” (not starting with a capital letter) is any network that uses IP as the network layer of the network protocol stack.

  “JAR” is an abbreviation for “Java (registered trademark) archive”. JAR is a file format used for bundling components used by Java applications. The JAR file simplifies applet download. This is because many components (.class files, images, sounds, etc.) can be packaged into a single file. JAR also supports data compression, which further reduces download time. Conventionally, JAR files end with a “.jar” extension.

  “JES” is an abbreviation for Java Embedded Server. JES is a commercial implementation of OSGi and provides a framework for the development, deployment, and installation of applications and services for embedded devices.

  “LAN” is an abbreviation for “local area network”. A LAN is a computer network that spans a relatively small area. Many LANs are limited to a single building or group of buildings. However, one LAN can be connected to another LAN through any distance by telephone line or radio wave. The LAN system connected in this way is called a wide area network (WAN). The Internet is an example of a WAN.

  “Lon Works” is a network connection platform available from Echelon (registered trademark). Lon Works is currently used in various network applications such as home appliance control and lighting control. The Lon Works network connection platform uses a protocol called "LonTalk", which is embedded in a "Neuron Chip" installed in a Lon Works compatible device.

  A neuron chip is an on-chip system with multiple processors, read-write and read-only memory (RAM and ROM), and communication and I / O subsystems. The read only memory includes an operating system, a LonTalk protocol, and an I / O function library. The chip has non-volatile memory for configuration data and application programs, which can be downloaded to the device via the Lon Works network. The neuron chip provides the first six layers of the standard OSI network model. That is, the neuron chip provides a physical layer, a data link layer, a network layer, a transport layer, a session layer, and a presentation layer.

  Neuron chips do not provide application layer programming. Applications for the Lon Works network are written in a programming language called "Neuron C". Applications written in Neuron C are usually event driven, thus reducing network traffic.

  “OSGI” refers to the Open Services Gateway Initiative, which is an industry organization that develops specifications for service gateways. It sends out service bundles, software middleware that provides compliant data communication, and service gateways. Engaged in the specifications for the service. The Open Services Gateway specification is a Java-based application layer framework that provides service-neutral, network operators, device manufacturers, and consumer electronics manufacturers with vendor-neutral application and device layer APIs and functionality.

  The “OSI Model” or OpenSystem Interconnection model defines a network connection framework for implementing a seven layer protocol. Control is passed from one layer to the next. Start from the application layer in one network station, go to the lowest layer, go to the next network station through the channel, and go back up the hierarchy.

  The seventh layer of the OSI model is the application layer. The application layer supports applications and end user processes. The application layer provides application services for file transfer, email, and other network software services.

  The sixth layer of the OSI model is the presentation layer. The presentation layer provides independence from differences in data presentation. The presentation layer performs the conversion from the application data format to the network data format and vice versa. The presentation layer is sometimes referred to as the “syntax layer”.

  The fifth layer of the OSI model is the session layer. The session layer establishes, manages and terminates connections between network connection applications. The session layer sets up, coordinates and terminates conversations, exchanges and interactions between networked applications.

  The fourth layer of the OSI model is the transport layer. The transport layer provides transparent transfer between network connection systems or hosts. The transport layer is also responsible for flow control and guarantees complete data transfer.

  The third layer of the OSI model is the network layer. The network layer creates a logical path known as a virtual circuit to transmit data from one network node to another. Routing, forwarding, addressing, and packet ordering are network layer functions.

  The second layer of the OSI model is the data link layer. The data link layer decodes the data packet into bits and encodes the bits into data packets. The data link layer provides a transmission protocol and manages data flow transmission in the physical layer.

  The data link layer is divided into two sublayers. The first sub-layer of the data link layer is a media access control (MAC) layer. The MAC sublayer controls access and authorization for computers on the network to transmit data. The second sub-layer of the data link layer is a logical link control (LLC) layer. The LLC layer controls data flow transmission in the physical layer.

  The first layer of the OSI model is the physical layer. The physical layer transmits bitstreams over the physical network at the electrical and mechanical level (electrical impulses, optical or radio signals). The physical layer provides hardware for sending and receiving data.

“SMF” represents “Service Management Framework _™ ” available from IBM (registered trademark). SMF is a commercial implementation of OSGi to manage applications transmitted over the network on the service gateway.

  “USB” is an abbreviation for “Universal Serial Bus”. USB is an external bus standard that supports a data transfer rate of 12 Mbps. A single USB port can be used to connect up to 127 peripheral devices such as a mouse, modem, and keyboard. USB also supports plug and play installation and hot plugging.

  “WAP” refers to a wireless application protocol and is a protocol for use with a handheld wireless device. Examples of wireless devices useful with WAP include cell phones, pagers, two-way radios, and handheld computers. WAP supports many wireless networks and WAP is supported by many operating systems. Operating systems specifically designed for handheld devices include PalmOS, EPOC, Windows® CE, FLEXOS, OS / 9, and JavaOS. A WAP device that uses the display and accesses the Internet executes a “microbrowser”. Microbrowser uses a small file size, which can accommodate the small memory limitations of handheld devices and the low bandwidth of wireless networks.

  “X-10” means the X-10 protocol. A typical X-10 enabled device uses an X-10 transmitter and an X-10 receiver to communicate over AC power wiring, such as existing AC wiring at home. X-10 transmitters and X-10 receivers exchange digital information using radio frequency (RF) signals. X-10 transmitters and X-10 receivers communicate by short RF bursts that represent digital information. A binary 1 is represented by a 1 millisecond 120 KHz burst, and a binary 0 is represented by the appearance of a burst after the absence of a 120 KHz burst.

  In the X-10 protocol, data is transmitted in units of data strings called frames. The frame begins with a 4-bit start code designated “1110”. After the start code, the frame identifies a particular domain, such as a house, by a 4-bit “house code” and identifies devices in that domain by a 4-bit “device code”. Also, the frame is 8 bits that identify certain preset commands such as “on”, “off”, “dark”, “bright”, “status on”, “status off”, and “status request”. Contains the command string.

Exemplary Architecture FIG. 1 is a block diagram of an exemplary architecture useful in implementing a device management method according to an embodiment of the invention. The architecture of FIG. 1 includes a domain (118). In this specification, the term “domain” means a specific network connection environment. Examples of various domains include home networks, car networks, company networks, and others that are conceived by those skilled in the art.

  The domain (118) of FIG. 1 includes a service gateway (106). The service gateway (106) is an OSGi compliant service gateway (106) in some exemplary architectures. Although an exemplary embodiment of a device management method is described herein using OSGi, many other applications and frameworks also function to implement the device management method according to the present invention, Therefore, it is within the scope of the present invention. In addition, a commercial implementation of OSGi, such as JES and SMF, is also useful when implementing a device management method.

  In the exemplary architecture of FIG. 1, the service gateway (106) includes a service framework (126). The service framework (126) of FIG. 1 is a host platform for executing “services”. A service is the main building block for generating an application in OSGi. The OSGi service framework (126) is written in Java and therefore typically runs on the Java Virtual Machine (JVM) (150).

  The exemplary architecture of FIG. 1 includes a DML (108). “DML” (108) is an abbreviation for Domain Mediation Layer. In many embodiments of the architecture of FIG. 1, DML (108) is application software useful in implementing the device management method according to the present invention. In some embodiments of the present invention, the DML is OSGi compliant application software and is therefore implemented as a set of services packaged as services or bundles installed on the service framework (126). In this specification, DML is often considered in the context of OSGi. However, the discussion of OSGi is for explanation and not for limitation. In fact, the DML according to various embodiments of the present invention can be implemented in any programming language implemented by those skilled in the art, such as C, C ++, COBOL, FORTRAN, BASIC, and developed in languages other than Java. Is installed directly on the operating system or operating environment rather than the JVM.

  In the exemplary architecture of FIG. 1, the service gateway (106) is coupled with a metering sensor (406) for data communication. The weighing sensor (406) is a device that reads a user status indication and generates a user metric in response to the user status indication. The “user status indication” is a feature that can quantify the user status, and is an amount obtained by measuring this feature. As an example, a quantifiable feature of a user's situation is a body temperature of 99.2 degrees Fahrenheit. Examples of quantifiable features of the user's situation include body temperature, heart rate, blood pressure, location, electrodermal response, and others that will occur to those skilled in the art.

  “User metric” is a data structure representing an instruction of a user situation. In many examples of device management methods according to the present invention, user metrics are implemented as a data structure, class, or object that includes a userID field, a metricID field, and a metric value field. A typical userID field identifies a user whose status indication is represented by a metric. A typical metricID field identifies a quantifiable feature of the user situation that the metric represents, such as blood pressure, heart rate, location, or electrodermal response. A typical metric field stores a measure of this user situation characteristic.

  Wearable and wireless heart rate monitors, electrodermal response monitors, ocular response monitors, and respiratory monitors that are useful or easily adaptable for use as metering sensors are currently available from Quibit Systems, Inc. The “Polar” series of heart rate monitors from Body Trends, Inc., and the magnetoelastic gastric pH sensor from Sentec Corporation are useful or easily adaptable for use as metering sensors, readily available biomedical It is another example of a sensor.

In order for a conventional sensor, such as a biomedical sensor, to be useful as a metric sensor that transmits multiple metric types in a domain that includes a large number of users, the sensor has not only a value for each feature to be measured, but also a user ID and metric It is convenient to also send the ID. The reason user ID is useful is that exemplary embodiments of the present invention include DML that can manage devices for many users simultaneously. metric The reason why ID is useful is that only one user can use two or more weighing sensors at the same time, or use a weighing sensor that can monitor and transmit data on two or more characteristics of the user situation. It is because there is a case where it is. All wireless sensors transmit metric values at least according to some wireless data communication protocol. Any particular “off-the-shelf” sensor has a user ID or metric If the ID is not sent, such a sensor will simply change its control software to send the user ID and metric to the send. Easily adapted to include an ID.

  Although most DMLs are expected to support metric ID and user ID, in some situations within the scope of the present invention, even if the sensor does not provide a metric ID and user ID in its output telemetry data An off-the-shelf sensor can be used as the sensor. Consider an example where only one person lives in a domain that has a device controlled or managed by a DML that tracks only a single metric, such as a heart rate. A DML that tracks only one metric for a single user can function without requiring a metric type code in the telemetry data received from the metric sensor. This is of course because only one type of metric is received. In this example, strictly speaking, an existing Bluetooth enabled heart rate sensor, such as the “Polar” sensor from Body Trends, could function as a metering sensor. This example is presented for illustrative purposes only. Because, in practice, most DMLs according to embodiments of the present invention require two or more types of metrics (and thus remote telemetry) for two or more users (thus requiring a user ID for telemetry data). This is because it is presumed that it is useful and advantageous to manage the measurement data).

  In many embodiments of the present invention, the metering sensor is advantageously coupled wirelessly with the service gateway (106) for data communication. In many alternative embodiments, the metering sensor uses a variety of protocols such as Bluetooth, 802.11, HTTP, WAP, or any other protocol conceived by those skilled in the art to service user metering. Send to DML via gateway.

  In the exemplary architecture of FIG. 1, domain (118) includes a device (316) coupled to a service gateway (106) via a LAN (105) for data communication. In many embodiments of the invention, domain (118) includes a number of devices. For example, the home domain may be a television, many lights, refrigerators, freezers, coffee pots, automatic dishwashers, dryers, CD players, DVD players, personal video recorders, or any other network conceived by those skilled in the art A home network with connectable devices can be included. For ease of explanation, the exemplary architecture of FIG. 1 shows only three devices (316), but the use of any number of devices is within the scope of the present invention.

  To manage the device (316), the DML provides a device class for the device that includes access mechanism methods to obtain and set attributes on the device, and possibly a protocol that is necessary to communicate with the device. Must have a class. In some examples of the architecture of FIG. 1, the DML is pre-installed with device classes and communication classes for many devices that the DML supports.

  If the DML does not have a pre-installed device class and communication class for a particular device, the DML can obtain the device class and communication class in many ways. One way for the DML to obtain the device class and communication class for a device is to read the device class and communication class from the device. This requires that sufficient memory is installed in the device to store the device class and communication class. Further, the DML can acquire a device class and a communication class from a device that does not include the installed device class and the communication class. One way for the DML to obtain the device class and communication class is to read the device ID from the device, search the internet for the device class and communication class, and download them. Another way for the DML to obtain the device class and communication class is to read the network location from the device and download the device class and communication class from the network location. Three methods have been described for obtaining the device classes and communication classes necessary for managing devices according to the present invention. Other methods will also occur to those skilled in the art.

  The example architecture of FIG. 1 includes a non-domain entity (102) coupled to a service gateway (106) via a WAN (104) for data communication. A “non-domain entity” is any computing device or network location that is coupled to a domain for data communication but not within the domain. The term “non-domain entity” is broad and, when included in the architecture of FIG. 1, in many embodiments of the architecture useful in implementing the device management method according to the present invention, Can be combined with an outer non-domain entity for data communication.

  One example of a non-domain entity is the manufacturer's web server (outside the domain) of a device (316) installed in the domain. The manufacturer can operate a website that becomes available for device driver downloads, device updates, or any other information or software for the device. Drivers, updates, information or software for the device can be downloaded to the device through the WAN and through the service gateway.

  FIG. 2 is a block diagram of an exemplary service gateway (106) useful in implementing the device management method according to the present invention. The service gateway (106) of FIG. 2 is an OSGi compliant service gateway (106) in some exemplary architectures useful in embodiments of the present invention. Although an exemplary embodiment of a device management method is described herein using OSGi, many other applications and frameworks other than OSGi will also implement the device management method according to the present invention. And therefore within the scope of the present invention. In addition, a commercial implementation of OSGi, such as JES and SMF, is useful when implementing the method of the present invention.

  OSGi represents “Open Services Gateway Initiative”. The OSGi specification is a Java-based application layer framework that provides vendor-neutral application and device layer APIs and functionality to a variety of devices using any communication protocol that operates over a network in the home, automobile, and other environments. I will provide a. OSGi includes various network connection technologies such as Ethernet, Bluetooth, “Home, Audio and Video Interoperability Standard (HAVi)”, IEEE 1394, Universal Serial Bus (USB), WAP, X-10, Lon Works, HomePlug, and other It works by various network connection technologies. The OSGi specification can be downloaded free from the OSGi website at www.osgi.org.

  The service gateway (106) of FIG. 2 includes a service framework (126). In many exemplary embodiments, the service framework is the OSGi service framework (126). The OSGi service framework (126) is written in Java and thus typically runs on a Java Virtual Machine (JVM). In OSGi, the service framework (126) of FIG. 1 is a host platform for executing "services" (124). In this disclosure, the term “service” or “services” generally refers to an OSGi compliant service, depending on the context.

  Service (124) is the main building block for generating applications according to OSGi. A service (124) is a group of Java classes and interfaces that implement a certain mechanism. The OSGi specification provides a number of standard services. For example, OSGi provides a standard HTTP service that creates a web server that can respond to requests from HTTP clients.

  OSGi also provides a standard service set called a device access specification. A device access specification ("DAS: Device Access Specification") provides a service for identifying a device to connect to a service gateway, searching for a driver for the device, and installing a driver for the device.

  Services (124) in OSGi are packaged in “bundles” (121) along with other files, images, and resources that the service (124) needs for execution. The bundle (121) is a Java archive or “JAR” file that includes one or more service implementations (124), an activator class (127), and a manifest file (125). The activator class (127) is a Java class used by the service framework (126) to start and stop the bundle. The manifest file (125) is a standard text file that describes the contents of the bundle (121).

  The example architecture of FIG. 2 includes a DML (108). In many embodiments of the invention, the DML is an OSGi service that performs a device management method. The DML (108) of FIG. 2 is packaged in a bundle (121) and installed on the service framework (126).

  The OSGi service framework (126) also includes a service registry (128). The service registry (128) includes a service registration (129), which provides a service name and service for each bundle (121) installed on the framework (126) and registered in the service registry (128). Contains an instance of the class to implement. The bundle (121) can request a service that is not included in the bundle (121) and is registered on the framework service registry (128). To find the service, the bundle (121) performs a query on the framework's service registry (128).

Exemplary Classes and Class Collaboration FIG. 3 is a block diagram illustrating exemplary classes useful in implementing the device management method according to the present invention. The exemplary classes of FIG. 3 are presented to assist in understanding the present invention, not for limitation. The device management method according to the present invention is generally discussed herein in connection with Java, which is used for illustration only and not for limitation. In fact, the device management method according to the present invention can be implemented in many programming languages conceived by those skilled in the art including C ++, Smalltalk, C, Pascal, Basic, COBOL, Fortran, and the like.

  The class diagram of FIG. 3 includes an exemplary DML class (202). The instance of the exemplary DML class (202) of FIG. 3 provides member methods that perform the steps useful for implementing a device according to the present invention. The exemplary DML class of FIG. 3 is shown by the Activator.start () method, so the DML can be started as a service in the OSGI framework. Although only one member method is shown for this DML, the DML often actually has more member methods as required for a particular embodiment. Also, the DML class of FIG. 3 includes member data elements for storing references to service classes, often generated by DML builders. In this example, the DML has a metric service (552), a metric range service (558), a communication service (554), an action service (560), a device service (556), a metric vector service (559), and a metric space service (561). ), And a storage field for reference to the dynamic action list service (563).

  The member method provided by the metric service class (204) of FIG. 3 receives a user metric from the DML and creates an instance of the metric class in response to receiving the user metric from the DML. The metric service class (204) of FIG. 3 includes a createMetric (userID, MetricID, Metric Value) member method (562). The CreateMetric () member method, in some embodiments, is a factory method represented by a parameter by a metric ID, and creates and returns a metric object corresponding to the metric ID. In response to obtaining a user metric from the DML, the example instance of the metric service class (204) of FIG. 3 creates an instance of the metric class and returns a reference to the new metric object to the DML.

Strictly speaking, none of the limitations of the present invention require the DML to create a metric object with a factory method. DML can proceed, for example, as illustrated in the following pseudo code segment.

In this example, a metric object is created and its member data is loaded using an access mechanism method. This approach provides the exact same metric object class for each metric, but there are situations where it is advantageous to use a specific class structure that varies from metric to metric. For example, in the case of a heart rate and blood pressure metric, both metric values may be encoded as integers, in which case, for example, a metric value for polar coordinates on the ground surface from a GPS transceiver, for example, its own It may be advantageous to encode into a more complex data structure that also has a location class. Using factory methods facilitates the use of more than one metric class. DML using factory methods to create a metric object can proceed as shown in the following example pseudocode segment.

This example uses the factory method createMetric () to set the parameter value in a new metric object. Factory methods for metering services and metering objects can be implemented as shown in the following pseudo-code segment.

The MetricService in this example implements a so-called parameterized factory design pattern that includes factory methods. In this example, the factory method is a member method named “createMetricObject ()”. createMetricObject () receives three parameters: user ID, metric ID, and metric value. createMetricObject () executes a switch statement according to the metric ID to select and instantiate a specific concrete metric class. The specific metric classes in this example are HeartRatemetric, BloodPressureMetric, and GPSMetric, each of which extends the Metric base class. createMetricObject () returns a reference to the new metric object to the calling DML. The call from DML is as follows,
Metric aMetric = MetricService.createMetricObject (userID, metricID, metricValue)
Since this is polymorphic and uses a reference to the base class Metric, the calling DML does not know or care about which metric object class is actually instantiated and returned. The following is an example extension of the Metric base class to define a specific metric class that represents the location of the user on the ground surface that extends the Metric base class.

  The concrete class GPSMetric in this example provides storage for latitude and longitude. GPSMetric provides GPSMetric () to the builder, which takes integer arguments to set the userID and metricID, but expects that metricValue argument to be a reference to a GPSLocation object, Provides storage for member data for latitude and longitude.

  The class diagram of FIG. 3 includes an exemplary metric class (206). The example metric class (206) of FIG. 3 represents a user metric. The user metric has data describing an indication of the user situation. The user status indication is a quantifiable feature of the user status and is an amount to measure this feature. Examples of quantifiable features of the user situation include body temperature, heart rate, blood pressure, position, galvanic response, and any other user situation feature that will occur to those skilled in the art.

  The exemplary metric class (206) of FIG. 3 includes a user ID field (486), a metric ID field (488), and a value field (499). The user ID field (486) identifies the user. The metric ID (488) identifies the user metric represented by an instance of the metric class. That is, the type of user measurement. The value field (490) contains the value of the user metric.

  The exemplary metric class of FIG. 3 also includes a data storage area for the metric action list (622). A metric action list is a data structure that includes an action ID that identifies an action, which, when executed, manages the device to affect the same characteristics of the user situation that the metric represents. For example, a body temperature metric may have an associated metric action list that includes an action ID that, when executed, turns on a ceiling fan. In many examples of device management methods, action IDs in the metric action list are used to identify action IDs for inclusion in the dynamic action list.

  The exemplary metric class (206) is an example of a class that can be used as a generic class in various embodiments, and using instances thereof, two or more having the same or similar member data elements as described above. Types of metrics can be stored or represented. Alternatively, in other embodiments, a class such as the metric class (206) of this example can be extended as a base class, with specific derived classes, each of which is described above. Can have widely different member data types.

  The class diagram of FIG. 3 includes an exemplary related metric service class (684). An exemplary related metric service class includes a member method, createRelationalMetric () (686). In many embodiments, createRelationalMetric () (686) determines the relationship between user metrics in the metric cache and instantiates a related metric that represents the determined relationship between user metrics in the metric cache. In other embodiments, createRelationalMetric () compares the user metrics in the metric cache with a default metric set that forms a default metric pattern. If the user metric in the metric cache matches the default metric that forms the default metric pattern, createRelationalMetric retrieves a pre-generated related metric that represents the relationship defined by the default metric pattern.

  The class relationship diagram of FIG. 3 includes related metrics. An associated metric is a metric that is generated in response to a user metric in the metric cache or that is generated in anticipation of a user metric arriving at the cache. That is, the related metric is sometimes generated as a result of determining the relationship between user metrics in the metric cache. In other cases, the associated metric is a metric generated according to a predetermined pattern of a predetermined metric. Such a predetermined related metric is often selected from a related database depending on the user metric in the metric cache.

  The example associated metric of FIG. 3 includes a userID field that identifies the user. The associated metric in FIG. 3 includes a metric ID field. The associated metric also includes a value field (490). In many cases, the value field typically represents the magnitude of the particular relationship that the associated metric represents. In some examples, the relationship record may have more than one value field that represents different characteristics of the associated metric. For example, an associated metric for “movement” may have a value field that indicates direction and another value field that indicates speed.

The class diagram of FIG. 3 includes a metric vector service (207). The metric vector service class (207) of FIG. 3 provides a member method that creates an instance of the metric vector class in response to receiving a user metric from the metric service and a related metric from the associated metric service. . In many exemplary embodiments, the createMetric vectorObject () member method (565) determines the metric vector ID for the user metric vector from the metric vector list, depending on the user ID, the metric ID of the user metric, and the associated metric. Identify. If a metric vector does not exist in the metric vector list of the metric vector service, the metric vector service instantiates one metric vector and stores its metric vector ID in the metric vector table, indicated by the associated user ID and metric ID. To do. The generation of the metric vector object can be implemented as shown in the following pseudo code segment.

  In the above pseudocode example, when the metric vector service receives a metric or associated metric with a userID whose metric vector is not identified in the metric vector table of the metric vector service, the metric vector service is new for the user. A new metric vector having a metric vector ID is generated, and the metric vector is added to the metric vector list.

  The class diagram of FIG. 3 includes a metric vector class (606). A metric vector class object represents a complex indication of the user situation. A user metric vector typically includes a set of user metrics, each of which is a single quantifiable feature of the user's situation and a quantity that measures that feature, as well as a user metric in or from a metric cache. Represents an associated metric that was generated in anticipation. Thus, a user metric vector consisting of a plurality of different user metrics represents a complex indication of a user situation with a number of quantifiable features of the user situation and a number of quantities that measure that feature. The metric vector class (606) includes a data element for storing a user ID (486) identifying the user and a metric list (652) for storing references to a plurality of different metric objects.

  The exemplary metric vector (606) of FIG. 3 also includes a data storage area for the dynamic action list (626). The dynamic action list is a list of action IDs and is generated in response to a metric action list associated with a particular metric of the user metric vector that is outside the corresponding metric range of the user metric space. That is, each metric in the metric vector that is outside the corresponding metric range has an associated metric action list. The dynamic action list includes an action ID identified in response to a metric action list associated with a particular metric of the user metric vector that is outside the corresponding metric range of the user metric space. The dynamic action list advantageously provides a list of action IDs tailored to the user's current situation.

  Also, exemplary metric vector class objects typically include member methods that determine whether the metric vector is outside the user metric space. This exemplary metric vector class is an example of a class that can be used as a generic class in various embodiments, and an instance of which can be used to represent two or more types of vectors having the same or similar member data elements. Can be stored or represented. Alternatively, in other embodiments, a class such as the metric vector class of this example can be used as a base class and extended with specific derived classes that can each have a different member data type.

  The class diagram of FIG. 3 includes a metric range service class (208). The metric range service class (208) provides member methods that instantiate an instance of the metric range class. The metric range service class (208) in FIG. 3 includes a createRangeObject (UserID, MetricID) member method (572). The CreateRangeObject () member method is a factory method represented by a parameter by userID and metric ID that generates a metric range object according to userID and metric ID. The CreateRangeObject () factory method returns a reference to the metric range object in the metric vector. CreateRangeObject () is a parameterized factory method that can be implemented using the same design pattern outlined by the example pseudocode provided in the description of the createMetricObject () factory method.

  The class diagram of FIG. 3 includes an exemplary metric range class (210). An example metric range class instance represents a metric range defined for a user for a metric or related metric. The maximum value and minimum value in the weighing range object are compared with the weighing value to determine whether the weighing value of the weighing object is outside the predetermined weighing range. The exemplary metric range class (210) of FIG. 3 includes a range ID field (463) that identifies a metric range and a metric ID field (462) that identifies a user metric. The exemplary metric range class (210) of FIG. 3 includes a user ID field (464) that identifies the user. The metric range class also includes a Max field (468) and a Min field (470) that include maximum and minimum values that define the metric range.

  The exemplary metric range class (210) of FIG. 3 is an example of a so-called data object, ie, a class that functions only as a container for data that has not been processed at all by the class member methods. . In this example, the objects of the weighing range class are mainly used to transfer the minimum and maximum values of the weighing range between other objects. The metric range class of FIG. 3 includes a default constructor (not shown), but strictly speaking, no other member methods are required. If no other member methods are given to the metric range class, the cooperating object can directly access its member data elements by encoding, for example, “someMetricRange.max” or “someMetricRange.min”. I will. However, the specific example (210) in this case is illustrated as including access mechanism methods (471, 473) for the minimum and maximum values of the range, and is an implementation not required by the present invention, Consistent with programming in an oriented paradigm.

The class diagram of FIG. 3 includes a metric space service class (209). The metric space service class (209) includes a member method createMetricSpace () that searches a metric space list or other data structure to identify a metric space for the user. If no such metric space exists, createMetricSpace () instantiates one metric space and stores the metric space ID in the metric space list. The creation of the metric space object can be implemented by the following exemplary pseudo code.

  In the above pseudo code example, the metric space service retrieves the metric space from the metric space list. If the list does not include a metric space for userID and metric vector ID, MetricSpaceService.createMetricSpace (userID, MetricVectorIC) creates a new metric space with a new metric space ID.

  The class diagram of FIG. 3 includes a metric space class. The user metric space consists of a plurality of user metric ranges for different user metrics and related metrics. The exemplary metric space includes data elements for storing a user metric (405) that identifies the user and a space ID (908) that identifies the metric space. The metric space (610) of FIG. 3 also includes a data storage area (655) for a reference list for different metric ranges for user metrics and related metrics. Different metric ranges in the metric space essentially correspond to the metric in the user metric vector. That is, in an exemplary embodiment, the user metric vector includes a set of different current user metrics and associated metrics, and the user metric space includes a set of corresponding metric ranges for the user.

The class diagram of FIG. 3 includes an action service class (217). The action service class contains member methods that instantiate a metric action list for user metrics or related metrics, instantiate action objects, store references to action list action objects, Return a reference to the action list. All of them can be implemented as shown by the following exemplary pseudo code.

  The createActionList () method in the ActionService class instantiates a weighing action list for user weighing by “ActionList anActionList = newActionList ()”. Next, createActionList () searches the action record table of the database for a record having a user ID and a metric ID that match the call parameter. For each matching record in the table, createActionList () instantiates an action object with its switch statement. The switch statement selects a specific concrete derived action class for each action ID retrieved from the action record table. createActionList () stores a reference to each action object in the action list by "anActionList.add ()". createActionList () returns a reference to the action list by "return and ActionList".

  The class diagram of FIG. 3 includes an exemplary action class (216). An instance of an action class represents an action for managing a device as a result when executed. The example action class of FIG. 3 includes an action ID field (450). The doAction () method (456) of the example action class (216) is programmed to obtain the device list (458) from a call to DeviceService.createDeviceList (), for example. Also, Action.doAction () (456) is normally programmed to execute the device control action by calling the interface method on each device in the device list.

  The class diagram of FIG. 3 includes a dynamic action list service. The dynamic action list service of FIG. 3 includes a member method createDynamicList () (569). In many embodiments, createDynamicList is called by a member method in a user metric vector and is parameterized by an action ID retrieved from a metric action list associated with specific metrics that are outside their corresponding metric range. createDynamicList generates a dynamic action list including an action ID identified according to the metric ID retrieved from the metric action list, and returns a reference to the dynamic action list to the caller.

The class diagram of FIG. 3 includes a device service class (218). The device service class provides a factory method named createDeviceList (actionID), which creates a list of devices and returns a reference to the list. In this example, createDeviceList () operates in the same manner as ActionService.createActionList () described above, instantiates a device list, searches the device table for device IDs that have matching action ID entries, Instantiate a device object of the specific derived device class of, add a reference to each new device object to the device list, and return a reference to the device list to the calling action object. However, in this example, the factory method createDeviceList () not only retrieves the device ID from its supported data table, but is also controlled by each instantiated device object, as shown in the following example pseudocode: Find the network address or communication location of a physical device.

  The createDeviceList () method of the DeviceService class instantiates a device list for measurement by “DeviceList aDeviceList = newDeviceList ()”. Next, createDeviceList () searches the device record table in the database for a record having an action ID that matches the call parameter. For each matching record in the table, createDeviceList () instantiates a device object with its switch statement and passes three parameters: CommsService, deviceAddress, and deviceID. CommsService is a reference to a communication service, from which a device object can obtain a reference to a communication object used for communication with a physical device controlled by the device object. deviceAddress is the network address and is obtained from the device table as described above for the physical device controlled by the particular device object. The switch statement selects a specific specific derived device class for each device ID retrieved from the device table. createDeviceList () stores a reference to each device object in the device list by “aDeviceList.add ()”. createDeviceList () returns a reference to the device list by "return aDeviceList".

  The class diagram of FIG. 3 includes an exemplary device class (214). The example device class (214) of FIG. 3 includes a deviceID field (472) that uniquely identifies the physical device managed by the execution of the action. The example device class (214) of FIG. 3 includes an address field (480) that identifies the location of the physical device on the data communications network. The example device class (214) of FIG. 3 includes a communication field (478) for reference to an instance of a communication class that implements a data communication protocol to communicate between the device class instance and a physical device. I will provide a.

  The device class of FIG. 3 includes an attribute field (481) that contains the current attribute value of the device. An example of a current attribute of a device is an indication that the device is “on” or “off”. Other examples of current attributes include values that indicate specific settings of the device. The device class of FIG. 3 also includes an access mechanism method (474, 476) for obtaining and setting physical device attributes. The exemplary device class of FIG. 3 includes only one attribute field and an access mechanism method for obtaining and setting that attribute, but many device classes useful in implementing the method of the present invention. Can support more than one attribute. Such a class can also include an attribute ID field for each attribute supported by the device class and an accessor method for obtaining and setting the attribute.

  The example class diagram of FIG. 3 includes a communication service class (219). The communication service class (219) is named createCommsObject (deviceID, networkAddress) (574) that instantiates a communication object that implements a data communication protocol for performing communication between an instance of a device class and a physical device. Provide factory methods. The createCommsObject () method (574) searches for the communication class ID in the communication class record in the communication class table having the device ID that matches the call parameter. In many embodiments, the createCommsObject () method (574) instantiates a specific concrete derived communication class identified by the switch statement as described above and passes the networkAddress from its parameter list to the constructor, so the new The communication object knows the address on the network where the new object communicates data. Each specific derived communication class is designed to perform data communication according to a specific data communication protocol, such as a specific data communication protocol, Bluetooth, 802.11b, LonWorks, X-10, or the like.

  The class diagram of FIG. 3 includes an exemplary communication base class (215). In an exemplary embodiment, at least one specific communication class is derived from the base class for each data communication protocol supported by a particular DML. Each specific communication class implements a specific data communication protocol for communication device objects and physical devices. Each specific communication class implements a specific data communication protocol by invalidating the interface method (482, 484), and performs actual data communication according to the protocol.

  Depending on the communication class, the device class (214) can operate independently with respect to the particular protocol required for communication with the various physical devices. For example, one lighting in the user's home can communicate using the LonWorks protocol, while another lighting in the user's home can communicate using the X-10 protocol. Both lights can be controlled by device objects of the same device class, with communication objects of different communication classes, one implementing LonWorks and the other implementing X-10. Both device objects control lighting by calls to the same communication class interface methods, send () (482) and receive () (484), and do not know that these communication objects actually use different protocols. Don't do it.

  FIG. 4 is a class relationship diagram illustrating an exemplary relationship between the exemplary classes of FIG. In the class relationship diagram of FIG. 4, solid arrows represent instantiation. A solid arrow points to a class being instantiated from a class being instantiated. In the class relationship diagram of FIG. 4, dotted arrows represent references. The arrow points from the referenced class to the class in which the object has a reference to this referenced class. That is, a dotted arrow indicates a complex object-oriented relationship, ie, a “has-a” relationship between classes.

これによって、計量サービス（２０４）は、計量クラス（２０６）のオブジェクトをインスタンス化する。計量サービスは、計量オブジェクト（２０６）に対する参照を、計量ベクトルサービスオブジェクト（２０７）に渡す。計量オブジェクトは、アクションサービスクラス（２１７）のオブジェクトに対する参照および計量アクションリスト（６２２）を含む。 The example class relationship diagram of FIG. 4 includes a DML class (202). The DML object of the DML class (202) instantiates an object of the metric service class (204), an object of the metric vector service class (207), and an object of the metric space service class (209). Further, the DML object instantiates an object of the metric range service class (208), an object of the action service class (217), and an object of the dynamic action list service class (211). The DML object instantiates an object of the device service class (218) and an object of the communication service class (219). When the DML receives a metering (200) from the metering sensor, the DML uses the following call:

Thus, the metric service (204) instantiates an object of the metric class (206). The metric service passes a reference to the metric object (206) to the metric vector service object (207). The metric object includes a reference to an object of the action service class (217) and a metric action list (622).

  As shown in the class relationship diagram of FIG. 4, the metric vector service (207) instantiates an object of the metric vector class (606). In many embodiments, the metric vector service class receives a reference to a metric object and instantiates the metric vector object using a factory method represented by parameters such as createMetricVectorObject (). As shown in the class relationship diagram of FIG. 4, the objects of the metric vector class (606) are references to the objects of the metric class (206), objects of the metric space service class (209), objects of the metric space class (610), It includes objects of dynamic action list service class (211) and dynamic action list (212626).

  As shown in the class relationship diagram of FIG. 4, the metric space service (209) instantiates an object of the metric space class (610). In many exemplary embodiments, the metric space service instantiates a metric space object using a factory method represented by parameters such as createMetricSpace (). The metric space service passes a reference to the metric space object (610) to the metric vector object. The metric space object (610) contains a reference to an object of the metric range class (210). As shown in the class relationship diagram of FIG. 4, the metric range service (208) instantiates an object of the metric range class (210). In many exemplary embodiments of the invention, the metric range service (208) instantiates the metric range (210) using a factory method represented by parameters such as createRangeObject (). The weighing range service (208) passes a reference to the weighing range (210) to the weighing space service (209).

  As shown in the class relationship diagram of FIG. 4, the action service (217) instantiates objects of the metric action list (622) and the action class (216). The metric action list (622) is instantiated by reference to each of the instantiated actions (216). Each action (216) is instantiated by reference to a device service (218). In a typical example of a method according to the present invention, the action service (217) instantiates a metric action list (622) and instantiates an action (216) using a factory method represented by parameters such as createActionList (). To do. The action service (217) passes a reference to the metric action list (622) to the metric (206).

  As shown in FIG. 4, the dynamic action list service (211) instantiates the dynamic action list (626) and passes a reference to the dynamic action list (626) to the calling method of the metric vector (606). In a typical example of the method according to the invention, the dynamic action list service (211) instantiates a dynamic action list using a method such as createDynamicActionList (). In many embodiments, createDynamicActionList () is parameterized by the action ID of a metric action list associated with user metrics that are outside their corresponding metric range. The dynamic action list (626) has a reference to an object of the action class (216).

  In the example of FIG. 4, the device service (218) instantiates a device list of the device list class (222) and instantiates a device object of the device class (214). The device list (222) is instantiated by reference to the device object (214). The device object (214) is instantiated by reference to the communication service (219). In a typical example of the method according to the invention, the device service (218) instantiates a device list (222) and instantiates a device object (216) using a factory method represented by parameters such as createDeviceList (). To do. The device service (218) passes a reference to the device list (222) to the action (216).

  In the example of FIG. 4, the communication service (219) instantiates a communication object of the communication class (215). In a typical example of the method according to the present invention, the communication service (219) instantiates the communication object (215) using a factory method represented by a parameter such as createCommsObject (). The communication service (219) passes a reference to the communication object (215) to the device object (214).

  FIG. 5 is a class relationship diagram illustrating exemplary relationships between some of the classes of FIG. In the example of FIG. 5, the object of the DML class (202) instantiates the object of the related metric service class (684). The associated metric service class has a reference to the user metric (206) available in the metric cache.

  The related metric service class (684) instantiates an object of the related metric class (664) according to the user metric in the metric cache, or selects a previously generated related metric according to the user metric in the metric cache. To do. The associated metric has a reference to the metric action list (622). The metric vector receives a reference to the associated metric (664) from the associated metric service.

Device Management According to User Metrics FIG. 6 is a data flow diagram illustrating an exemplary device management method. The method of FIG. 6 includes receiving (302) a user metric (206). As described above, the “user metric” is composed of data describing an instruction of a user situation. “Instruction of user situation” is a quantifiable feature of the user situation and is an amount for measuring the feature. Examples of quantifiable features of the user's situation include body temperature, heart rate, blood pressure, location, electrodermal response, and other features that will occur to those skilled in the art.

  In an exemplary embodiment of the invention, user metrics are implemented as user metric data structures or records (206), such as the exemplary user metric (206) of FIG. The user metric in FIG. 6 includes a userID field (405) that identifies the user whose status indication is represented by the metric. The user metric (206) in FIG. 6 includes a metric ID field (407) that identifies the characteristics of the user situation represented by the metric such as blood pressure, heart rate, position, and electrical skin response. The user metric (204) also includes a value field (409) that contains the value of the user situation feature represented by the metric. An example of a metric value is a body temperature of 100 degrees Fahrenheit.

  In many embodiments of the method of FIG. 6, receiving a user metric (302) includes receiving a user metric from a metric sensor (406). In some examples of the method of FIG. 6, the metric sensor (406) reads a user status indication, generates a user metric in response to the user status indication, and transmits the user metric to the DML. In many embodiments, the metering sensor can be configured using, for example, a protocol such as Bluetooth, 802.11, HTTP, WAP, or any other protocol that will occur to those skilled in the art, such as the metering (206) of FIG. Send user metrics to DML with default data structure.

  In the method of FIG. 6, receiving user metrics (302) includes receiving user metrics in a metric cache memory (305). That is, user metrics are received by the DML and then stored in the cache. In many embodiments of the method of FIG. 6, the metric cache memory (305) is a cache memory available for DML, facilitating the execution of device management steps according to the present invention.

  The method of FIG. 6 includes a determination (306) whether the value of the user metric is outside the specified metric range (309). The specified metric range includes a predetermined range of values for a given metric ID for a particular user. In many embodiments of the method of FIG. 6, the predetermined metric range is designed as a typical or normal metric value range for the user. One example of a predetermined metering range is a metered value range that represents a resting heart rate of 65 to 85 per minute.

  In many examples of the method of FIG. 6, the user's default metric range is implemented as a data structure or record, such as the metric range (210) of FIG. The metric range of FIG. 6 includes a metric ID field (462) that identifies the type of user metric. The metric range of FIG. 6 includes a user ID field (464) that identifies the user whose metric range represents the metric value range. The metric range of FIG. 6 includes, for example, a Max field (468) representing the maximum metric value of the metric range and a Min field (470) representing the minimum metric value of the metric range. That is, in an exemplary embodiment, it is the maximum and minimum metric values of the range that define the metric value range.

  In many embodiments, the determination (306) of whether the value of the user metric (206) is outside of the default metric range (309), the metric value of the user metric is determined for the same user metric range of the metric. Includes comparing with maximum and minimum values. In many examples of the method of FIG. 6, the determination that the user metric is outside the default metric range is that the metric value (409) of the user metric (206) is greater than the maximum value (468) of the metric range (210). It includes the determination of being greater than or less than the minimum value (470) of the weighing range (210). For example, a user metric with a metric ID that identifies the metric as “heart rate” has a metric value of 100 heartbeats per minute, with an exemplary metric range of resting heart rates of 65 to 85 per minute. Outside.

  If the value of the user metric is outside the metric range, the method of FIG. 6 includes identifying the action responsive to the user metric (310). An action includes one or more computer programs, subroutines, or member methods that, when executed, control one or more devices. Actions are usually implemented as object-oriented classes and are manipulated as objects or references to objects. Indeed, in this document, the terms “action”, “action object”, and “reference to an action object” are more or less synonymous unless the context indicates otherwise. In many embodiments of the method of FIG. 6, the action object invokes a member method of the device class and affects the current attributes of the physical device. In many embodiments of the method of FIG. 6, action classes or action objects are deployed in the DML on the service gateway in an OSGi bundle.

  In the method of FIG. 6, identifying an action (310) includes receiving (365) an action ID (315) from a metric action list (622) configured with a user ID and a metric ID. In the method of FIG. 6, the action ID retrieval from the weighing action list is performed when the specific weighing ID and the specific user weighing value are outside the predetermined weighing range of the user (“action ID”). )) Search from the list. The action list can be implemented, for example, as a Java list container, as a table in random access memory, as a SQL database table with storage on a hard drive or CD ROM, and in other ways as will occur to those skilled in the art be able to.

As described above, since the action itself is composed of software, for example, it can be implemented as a specific action class that is imported into the DML at the time of compilation and thus embodied in a Java package that is always available when the DML is executed. . Accordingly, execution (314) of action (312) is often performed in such an embodiment by use of a DML switch () statement. Such a switch () statement statement operates in response to an action ID and can be implemented, for example, as indicated by the following pseudo code segment.

  The example switch statement selects a specific device control object to execute according to the action ID. The device control objects managed by switch () in this example are external action classes named actionNumber1, actionNumber2, etc., each having an executable member method named "take_action ()" The actual work performed by the action class is executed.

Also, execution (314) of action (312) is often performed in this embodiment by using a hash table in DML. Such a hash table can store a reference to an action object input by an action ID, as shown in the following pseudo code example. This example begins with the action service generating an action hash table that is a reference to an object of a specific action class associated with a particular metric ID using the action ID as a key. In many embodiments, it is the action service that creates such a hash table, populates it with a reference to an action object associated with a particular metric ID, and returns a reference to the hash table to the calling metric object.

The execution of a specific action can be performed according to the following pseudo code:

Many embodiments herein are described with a list, often with a list of actions, which are returned with a reference to the list, eg, from an action service. In many cases, lists function like hash tables. For example, the execution of a specific action can be performed according to the following pseudo code:

The execution of a specific action can be performed according to the following pseudo code:

  The three examples above illustrate the execution of actions according to embodiments of the present invention using switch statements, hash tables, and list objects. The use of switch statements, hash tables, and list objects in these examples is for purposes of illustration and not limitation. In fact, as will occur to those skilled in the art, there are many ways of performing actions in accordance with embodiments of the present invention, all of which are within the scope of the present invention.

  FIG. 7 shows a data flow diagram illustrating an exemplary method for performing an action. In the method of FIG. 7, execution of the action includes identification (380) of a device class (214) that represents the physical device (316) that the action manages. A typical device class includes member methods for managing devices. Typical member methods for managing devices include member methods for getting and setting device attribute values of physical devices. For example, for a lamp that supports many settings of light intensity, the device class member method get () can obtain the value of the light intensity from the lamp, and the device class member method set () Set the light intensity.

  In the method of FIG. 7, performing the action includes identifying (384) the communication class (215) for the physical device (316). In order for a member method of a device class to communicate with a physical device, the communication class implements a protocol for communicating with the physical device. A typical communication class includes member methods that construct, send, and receive data communication messages according to the protocol implemented by the communication class. The communication class member methods send and receive data communication messages to and from the physical device. The communication class advantageously separates the protocol used to communicate with the physical device from the actions performed on the device, so a device class interface with eg get () and set () It would be useful to be able to communicate with a physical device using any of the data communication protocols without having to reprogram and without having to provide one device class for each combination of physical device and protocol.

  For a more detailed explanation, consider the following simple use case. The user's metric sensor reads the user's heart rate 100 times per minute and generates a user metric having a user ID identifying the user, a metric ID identifying the metric as “heart rate”, and a metric value of 100 . The metering sensor transmits this user metering to the DML via the service gateway. The DML receives the user metric and compares this user metric to a resting heart rate user metric range having a range of 65 to 85 times. The DML determines that the user metric is outside the default metric range. In response to determining that the user's heart rate metric is outside the user's heart rate metric range, the DML uses the user ID and metric ID to retrieve the action ID of the default action to perform from the list. . The DML has a class name of “someAction”, for example, and further searches for a device control action ID that identifies an action object having an interface member method known to the DML, such as the take_action () method described above in the switch () statement. .

  In this example, the DML performs the action identified by calling someAction.take_action (). The take_action () method in this example is programmed to invoke a device service for a list of references to device objects that represent physical devices whose attributes are affected by the action. The device service is programmed with a switch () statement to generate a list of references to the device object according to the action ID, and return the device list to the calling action object or to the calling take_action () method in the action object. .

  In generating the device list, the device service is programmed to instantiate each device that has a reference entered in the list and passes a reference to the communication service as a constructor parameter. Each device instantiated in this way has a constructor parameter programmed to call the factory method represented by the parameter in the communication service, and passes the identifier of the calling device object as a parameter. In order to communicate with the corresponding physical device, the communication service instantiates a reference to the communication object for the communication protocol required for that device object and returns it to the device.

  In embodiments of the present invention, the main control logic for performing actions typically resides in the main interface method of the action class and the objects instantiated therefrom. In this example, the take_action () method is programmed to execute a control sequence of method calls to perform the changes on the physical device for which this action class was originally developed. The take_action () method performs this function by a series of calls to access mechanism methods (set () and get () methods) on the device objects in the device list.

  FIG. 8 is a data flow diagram illustrating an exemplary method for determining (306) that a user metric (206) is outside a predetermined metric range (210). In many embodiments of the device management method, the user metric (206) is represented in the data as a data structure or record, such as the user metric record of FIG. The user metric (206) includes a user ID field (405), a metric ID field (407), and a value field (409).

  In the example of FIG. 8, the predetermined measurement range of the measurement is represented in the data as a measurement range such as the measurement range (210) of FIG. The exemplary metric range (210) shows a particular user's maximum range value (468) and minimum range value (470) for a particular metric. The specific user and specific metric for the exemplary range are identified in the user ID field (464) and the metric ID field (462), respectively.

  In the method of FIG. 8, a determination (306) that the value of the user metric (206) is outside the predetermined metric range (210) (309) indicates that the user metric (206) is outside the predetermined metric range (210). Measurement (502) of about (309) (504). In many embodiments of the present invention, measurements (502) on the order of (309) (504), where the user metric (206) is outside the metric range (210), the user metric value is greater than the maximum metric value in the metric range. It includes identification to a greater extent or to the extent that the user metric value is less than the minimum value of the predetermined metric range. When the metric is out of range and some measurement includes identifying the measurement as being greater than the maximum range value or less than the minimum range value, the measurement is, for example, a sign (+ or −), eg “up” Alternatively, it is often advantageous to include both magnitude and direction indications, such as list indications such as “below” or Boolean indications such as true for high and false for low.

  In the method of FIG. 8, the identification (310) of the action according to the user metric depends on the degree of (309) (504) that the value of the user metric (206) is outside the metric range. Includes identification (512) of the action as a function of the direction that is out of range. In many embodiments of the method of FIG. 8, the identification (512) of the action in response to the degree (504) that the user metric is outside of the predetermined metric range is a metric configured by the metric ID, user ID, degree, and direction. This includes retrieving an action ID from the action list (622).

  In many DMLs according to the present invention, device classes are pre-installed on all devices supported by the DML. Newly acquired physical devices identify themselves as being on the network, and the DML associates the device ID with a device class that is already installed on the DML. In such exemplary embodiments, the DML identifies the device by associating the device ID with a pre-installed device class.

Device management according to user metric vector including associated metrics and device control based on location FIG. 9 is a data flow diagram illustrating a device management method according to the present invention. The method of FIG. 9 includes receiving (660) a plurality of user metrics (206). In many embodiments of the method of FIG. 9, receiving (660) a plurality of different user metrics (206) includes receiving different user metrics from one or more metering sensors (406). The term “different” user metrics means different types of user metrics. That is, different types of user metrics that usually have different metric values.

  In some examples of the method of FIG. 9, the metric sensor (406) reads the user status indication, generates a user metric in response to the user status indication, and transmits the user metric to the DML. In many instances, the metering sensor is a pre-defined data structure such as the metering (206) of FIG. 3, such as a protocol such as Bluetooth, 802.11, HTTP, WAP, or any other that will occur to those skilled in the art. The user metric is transmitted to the DML using the following protocol.

  The method of FIG. 9 includes generating (662) an associated metric (664) in response to a plurality of user metrics (206). In many examples of the method of FIG. 9, the associated metric (664) is derived in response to a plurality of user metrics or is generated in anticipation of a user metric received in the future, a specific indication of user status. Is a data structure representing That is, in some examples of the method of FIG. 9, the associated metric is a metric generated in response to a plurality of user metrics in the metric cache. For example, an associated metric for “movement” can be generated from at least two other metrics for position. In another example of the method of FIG. 9, the associated metric is pre-generated in anticipation of a user metric received in the metric cache. In many of these examples, if a user metric in the metric cache matches a predefined metric set that produces a predefined metric pattern, a pre-generated associated metric is selected for the user. Examples of related metrics are user movement, no user movement, rotation, speed of movement, biometric value increase, biometric value decrease, rate of change of biometric value, or any other that will occur to those skilled in the art Includes a metric representing the relationship.

  Related metrics often provide information about user status that is not available in a single received user metric. A single receiving user metric with a metric value often shows only the current value of that metric. In other words, a single user metric often provides a single feature fragment of the user situation. On the other hand, the associated metric often provides further information about the user situation, such as how the user metric has changed, or other information as will occur to those skilled in the art, in response to performing an action.

  In many examples of the method of FIG. 9, the generation of a related metric (664) in response to a plurality of user metrics (206) involves calling a member method in a related metric service such as createRelationalMetric () (686 in FIG. 3). Including. In some examples of the method of FIG. 9, createRelationalMetric () (686) determines the relationship between user metrics in the metric cache and instantiates the appropriate associated metric. In another embodiment, createRelationalMetric () compares the user metrics in the metric cache with a default metric set that together form a default metric pattern. If the user metric in the metric cache matches the default metric that forms the default metric pattern, createRelationalMetric () receives an appropriate pre-generated related metric from the related metric database.

  The method of FIG. 9 includes generating (604) a user metric vector (606) comprising at least one user metric (206) and at least one associated metric (664). A user metric vector consisting of at least one user metric (206) and at least one related metric (664) is a complex of user situation with a number of quantifiable features of the user situation and a number of quantities that measure these features. Represent instructions. That is, a user metric vector is typically a set of user metrics each representing a single quantifiable feature of the user situation and the amount by which this feature is measured. In the method of FIG. 9, the user metric vector also includes at least one associated metric that identifies a relationship between at least two received user metrics.

  In an exemplary embodiment of the invention, the user metric vector is implemented as a user metric vector data structure or record, such as the exemplary user metric vector (606) described above with reference to FIG. The user metric vector (606) includes a user ID that identifies the user (486 in FIG. 3) and a metric vector ID that uniquely identifies the user metric vector (408 in FIG. 3). The user metric vector (606) also includes a data storage area for a metric list (652 in FIG. 3) that includes references to user metrics. The user metric vector (606) also includes a data storage area for an associated metric list (653 in FIG. 3) that includes a reference to the associated metric.

  The method of FIG. 9 includes generating (605) a user metric space (610) consisting of a plurality of metric ranges (210). The user metric space (610) consists of a plurality of different metric ranges for the user. That is, the metric space is defined by a plurality of metric ranges for a plurality of different metric IDs. In many examples of the method of FIG. 9, the metric range of the user metric space represents a normal or comfortable range of metric values for a given user metric for a given user. In many examples of the method of FIG. 9, the user metric space includes a metric range for the associated metric of the user metric vector. In many exemplary embodiments of the present invention, the metric space includes the data storage area (655) for the reference list for the user ID and the user's different metric ranges, the exemplary metric space (610) of FIG. Is implemented as a metric space data structure.

  The method of FIG. 9 includes a determination (608) that the user metric vector (606) is outside (309) the user metric space (610). In various alternative exemplary embodiments, the determination (608) that the user metric vector (606) is outside (309) the user metric space (610) is performed using different methods. A method for determining (309) that the user metric vector (606) is outside the user metric space (610) is a relatively simple comparison of the metric vector user metric and the associated metric to the corresponding metric space metric range. From complexity to more complex algorithms, the complexity varies. An exemplary method for determining (608) that the user metric vector (606) is outside (309) of the user metric space (610) is described in more detail below with reference to FIG.

  If the user metric vector (606) is outside the user metric space (610) (309), the method of FIG. 9 includes an identification (630) of the action (315). An action typically includes one or more computer programs, subroutines, or member methods that, when executed, control one or more devices. Actions are usually implemented as object-oriented classes and are manipulated as objects or references to objects. Indeed, in this document, the terms “action”, “action object”, and “reference to an action object” are more or less synonymous unless the context indicates otherwise. In many examples of the method of FIG. 9, action objects invoke device class member methods to affect the current attributes of a physical device. In many examples of the method of FIG. 9, action classes or action objects are deployed in the DML on the service gateway with OSGi bundles.

  In many examples of the method of FIG. 9, the identification (630) of the action (315) includes generating (624) a dynamic action list (626) in response to the user metric vector (606). In many examples of the method of FIG. 9, the dynamic action list is an action ID generated in response to a metric action list associated with a particular metric of the user metric vector that is outside the corresponding metric range of the user metric space. It is a list. That is, each metric in the metric vector that is outside its corresponding metric range has an associated metric action list. The associated metric action list includes an action ID for execution if the associated metric is outside its corresponding metric range. A dynamic action list is an action list that includes an action ID that is identified in response to a metric action list associated with a particular metric of a user metric vector that is outside the corresponding metric range of the user metric space. The dynamic action list advantageously provides a list of action IDs tailored to the user's current situation.

  In many exemplary embodiments of the invention, the generation of a dynamic action list includes a call to a member method on the dynamic action service object. In many examples of the method of FIG. 9, the generation of the dynamic action list is based on the action ID retrieved from the action list associated with a particular user metric of the user metric vector outside the corresponding metric range of the user metric space. This includes representing member methods such as createDynamicActionList () with parameters. In many examples of the method of FIG. 9, actionDynamicActionList () returns to the caller of its user metric vector a dynamic action list that includes an action ID that is identified according to the action ID included in the metric action list. In various alternative examples of the method of FIG. 9, the dynamic action list is a SQL database having storage areas on a hard drive or CD ROM, for example as a hash table, Java list container, as a table in random access memory. It can also be implemented as a table and in other ways as will occur to those skilled in the art.

The method of FIG. 9 includes performing an action (614). Thus, execution of actions is often performed in such embodiments by the use of switch () statements in DML. Such a switch () statement operates in response to an action ID and can be implemented, for example, as shown in the following pseudo code segment.

  The example switch statement selects a specific device control object for execution according to the action ID. The device control objects managed by switch () in this example are extraneous action classes named actionNumber1, actionNumber2, etc., each with an executable member method named "take_action ()" This performs the actual work performed by each action class.

In many examples of the method of FIG. 9, the execution of actions is done through the use of hash tables in DML. Such a hash table stores a reference to an action object input by an action ID, as shown in the following pseudo code example. This example begins with the dynamic action list service generating an action hash table that is a reference to an object of a specific action class associated with a particular metric ID using the action ID as a key. In many embodiments, such a hash table is created and populated with a reference to an action object associated with a particular metric ID of a user metric vector that is outside the corresponding metric range of the user metric space, and a reference to the hash table is invoked. It is the dynamic action list service that returns to the side vector object.

A specific action can then be performed according to the following pseudo code:

Also, many examples of the method of FIG. 9 are implemented through the use of lists. In many cases, lists function like hash tables. Construction of such a list can be performed according to the following pseudo code:

A specific action can then be performed according to the following pseudo code:

  The three examples above illustrate the execution of actions according to embodiments of the present invention using switch statements, hash tables, and list objects. The use of switch statements, hash tables, and list objects in these examples is for purposes of illustration and not limitation. In fact, as will occur to those skilled in the art, there are many ways of performing actions in accordance with embodiments of the present invention, all of which are within the scope of the present invention.

  In some examples of the method of FIG. 9, performing the action includes identifying a device class for the device. A typical device class includes member methods for managing devices. Typical member methods for managing devices include member methods for getting and setting device attribute values for physical devices. For example, for a lamp that supports multiple settings of light intensity, the device class member method get () can obtain the value of the light intensity from the lamp, and the device class member method set () Set the light intensity.

  In many examples of the method of FIG. 9, performing an action includes identifying a communication class for the device. Because the member methods of the device class communicate with the physical device, the communication class implements a protocol for communicating with the physical device. A typical communication class includes member methods that construct, send, and receive data communication messages according to the protocol implemented by the communication class. The communication class member methods send and receive data communication messages to and from the physical device. The communication class advantageously separates the protocol used to communicate with the physical device from the action that implements the device, so a device class interface with eg get () and set () reprograms the device class. It is useful to be able to communicate with a physical device using any of the data communication protocols without having to do this, and without having to provide one device class for each combination of physical device and protocol.

  FIG. 10 is a data flow diagram illustrating an exemplary method for generating (662) an associated metric (664) in response to a plurality of user metrics (206). As described above, in some examples of the method of FIG. 10, the associated metric is a metric generated in response to a received user metric in the metric cache. In the method of FIG. 10, the generation (662) of an associated metric (664) in response to a plurality of user metrics (206) includes user metric filtering (665). In many examples of the method of FIG. 10, user metric filtering includes identifying a received user metric metric ID in the metric cache and classifying the user metric by metric ID.

  FIG. 10 shows only two resulting filtered user metrics (206A, 206B). However, in many examples of the method of FIG. 10, as a result of user metric filtering, a number of filtered user metrics are stored in a cache and used to generate an associated metric. In various examples of the method of FIG. 10, how many filtered user metrics are maintained in the metric cache, such as the filtered user metric metric ID, the type of associated metric generated in response to the filtered user metric, etc. Or any other factor that will occur to those skilled in the art. For example, an associated metric for “user movement” can be generated from only two filtered user metrics, while an associated metric for “user movement in a circle” is due to its position in the metric cache. May require more than two filtered user metrics.

もしくは

In the method of FIG. 10, the generation (662) of an associated metric (664) in response to a plurality of user metrics (206A, 206B) includes a first filtered user metric (206A) and a second filtered user metric. The determination (666) of the relationship (668) with (206B). In the method of FIG. 10, the determination (666) of the relationship (668) between the first filtered user metric (206A) and the second filtered user metric (206B) is determined by the first filtered user metric (206A). A comparison (670) of the user metric (206A) and the second filtered user metric (206B) is included. In many examples of the method of FIG. 11, comparing the first filtered user metric and the second filtered user metric to determine the relationship is performed by an algorithm. That is, for example, in terms of computer program encoding, the determination of the relationship between user metrics is by using a switch statement or a sequence of if-then-else statement enforcement logic similar to that shown, for example: Executed.

Or

In many examples of the method of FIG. 11, determining the relationship as a function of user metrics is not limited to comparing only two user metrics. As an example of the comparison of three or more user metrics, consider the following example of algorithm logic that determines the relationship “rotate right”.

  In the method of FIG. 10, the generation (662) of an associated metric (664) in response to a plurality of user metrics (206A, 206B) includes a first filtered user metric (206A) and a second filtered user metric. The determination (672) of the magnitude (674) of the relationship (668) with (206B). In many examples of the method of FIG. 10, the determined magnitude is included as a value for the associated metric generated. In some examples of the method of FIG. 10, determining the magnitude (674) of the relationship (668) between the first filtered user metric (206A) and the second filtered user metric (206B). (672) includes subtracting (676) the value of the second filtered user metric (206B) from the value of the first filtered user metric (206A). In another alternative example of the method of FIG. 10, the magnitude (674) of the relationship (668) between the first filtered user metric (206A) and the second filtered user metric (206B). Determining (672) the first filtered user metric by adding the first filtered user metric and the second filtered user metric, or any other function or algorithm conceived by those skilled in the art. And applying to the second filtered user metric.

  FIG. 11 is a data flow diagram illustrating an exemplary method for generating (662) an associated metric (664) in response to a plurality of user metrics (206). In the method of FIG. 11, the generation (662) of an associated metric (664) in response to a plurality of user metrics (206) is determined by whether the plurality of user metrics (206) matches a predetermined metric pattern (663) (681). Determination (678). In many examples of the method of FIG. 11, the predetermined metric pattern includes a pre-generated user metric set that is predetermined to form a specific pattern of metric that proves the predetermined relationship.

  In many examples of the method of FIG. 11, determining whether a plurality of user metrics (206) matches a predetermined metric pattern (663) (681) (678) is performed by measuring a plurality of user metrics in a metric cache. Comparing (679) with a predefined metric set forming a predefined metric pattern (663). In many examples of the method of FIG. 11, comparing a user metric in the metric cache with a default metric pattern in the associated metric database may result in the user metric values being stored in individual default metrics contained within the default metric pattern. Comparing with the value of the metric and comparing the metric ID of the user metric in the metric cache to the individual metric metric ID included in the default metric pattern. In many examples of the method of FIG. 11, the default metric pattern may include different types of default metrics that together form a metric pattern.

  The multiple user metrics in the metric cache need not be exactly the same as the default metric set that forms the default metric pattern that is considered a match. The degree to which the user metric in the metric cache must be the same as the default metric of the default metric pattern to be matched is the tolerance of the method used for comparison, the type of information contained in the user metric and the default metric, the user metric and the default metric It depends on various factors such as the accuracy and precision used in generating the metric, as well as other factors that will occur to those skilled in the art.

  In the method of FIG. 11, the default metric pattern is stored in the metric pattern table (680). In many examples of the method of FIG. 11, the metric pattern table includes a predetermined metric set that forms a default metric pattern, for example, indicated by a metric ID for the associated metric to identify. In many examples of the method of FIG. 11, user metrics in the metric cache are compared to a predetermined set of metrics that form a default metric pattern. If the user metric matches a predetermined metric set that forms a default metric pattern, the metric ID is identified for the associated metric.

  In the method of FIG. 11, generating (662) a related metric (664) in response to a plurality of user metrics (206) includes a search (683) of the related metric (664). In many examples of the method of FIG. 11, the related metric is a related metric table (665) in response to a metric ID identified by comparing the user metric in the metric cache with a default metric pattern stored in the metric pattern table. )

  FIG. 12 is a data flow diagram illustrating an exemplary method of generating (604) a user metric vector (606) and an exemplary method of generating (605) a user metric space (610). In the method of FIG. 12, the generation (604) of a user metric vector (606) comprising at least one user metric (206) and at least one related metric (664) associates at least one user metric with the user metric vector. (603) and associating (682) at least one associated metric (664) with the user metric vector (606). In this disclosure and depending on the context, the term “associate” generally means association by reference. That is, associating an object of one class with another object means that the second object has a reference to the first object. Objects are associated with each other, each with a reference to the other. Other relationships between objects, collections, configurations, etc. are typically types of associations, and the use of any of them is within the scope of the invention, as are others that will occur to those skilled in the art. In the exemplary method of FIG. 12, associating a plurality of different user metrics (206) with a user metric vector (606) (603) provides a reference to a plurality of different metric objects in the user metric vector (606). Executed by.

  In the method of FIG. 12, generating (604) a user metric vector (606) comprising a plurality of different user metrics (206) associates (620) at least one metric action list (622) with each user metric (206). Including that. In many examples of the method of FIG. 12, multiple metric action lists are associated with each user metric in the user vector. The action ID included in the metric action list associated with a particular metric identifies an action designed to manage the device according to the specific characteristics of the user situation that the metric represents. That is, the metric action list is configured to affect the user situation represented by the user metric or the related metric. For example, a metric list associated with a body temperature metric can include actions to manage devices such as air conditioners, fans, heaters, automatic awnings.

  In many examples of the method of FIG. 12, generating a user metric vector includes associating multiple metric action lists with a single user metric. Some examples of the method of FIG. 12 are performed when a user metric value is greater than its corresponding metric range, so associating a metric action list with a user metric that includes an action ID, To associate with another metric action list that includes an action ID to execute if the value of is less than its corresponding metric range. Also, some examples of the method of FIG. 12 include associating a metric action list with a user metric that includes an action ID, as the user metric runs outside of its corresponding metric range and depending on the direction and direction.

  In the method of FIG. 12, the generation (604) of a user metric vector (606) comprising a plurality of different user metrics (206) associates at least one metric action list (622) with each associated metric (664) (683). )including. In many examples of the method of FIG. 12, multiple metric action lists are associated with each associated metric in the user vector. The action ID included in the metric action list associated with a particular related metric identifies an action designed to manage the device according to the particular characteristics of the user situation that that related metric represents. That is, the metric action list is configured to influence the user situation represented by the related metric. For example, a metric list associated with a body temperature metric can include actions to manage devices such as air conditioners, fans, heaters, automatic awnings.

  In many examples of the method of FIG. 12, generating the user metric vector includes associating multiple metric action lists with a single related metric. Some examples of the method of FIG. 12 are performed when the value of the associated metric is greater than its corresponding metric range, so associating a metric action list with an associated metric that includes an action ID, To associate with another metric action list that includes an action ID to execute if the value of is less than its corresponding metric range. Also, some examples of the method of FIG. 12 include associating a metric action list that includes an action ID with an associated metric in order for a user metric to execute depending on the extent and direction outside its corresponding metric range. .

  The method of FIG. 12 includes generating (605) a user metric space (610) consisting of a plurality of metric ranges. In many examples of the method of FIG. 12, the user metric space (610) consists essentially of a plurality of different metric ranges corresponding to the user metric and associated metrics included in the user metric vector. In many examples of the method of FIG. 12, the metric range of the user metric space represents a normal or comfortable metric range for the user. In the method of FIG. 12, the creation (602) of user metric space (610) identifies (610) a plurality of metric ranges (210) for a plurality of different metrics (206), and a plurality of different metrics. Associating a plurality of different metric ranges (210) for (206) with a user metric space (610).

  In many examples of the method of FIG. 12, the identification (601) of multiple metric ranges (210) and the association (607) of multiple metric ranges (210) with user metric spaces (610) are instantiated by the DML. Performed by a metric space service. The metric space service receives a user metric vector ID from the user metric vector, searches the metric space list identified by the metric vector ID, and sets a metric space for comparison with the user metric vector in the user metric vector. Returns the metric space ID to identify. If there is no metric space for the metric vector ID, the metric space service instantiates one metric space and stores the metric space ID in the metric space table.

  FIG. 13 is a data flow diagram illustrating two exemplary methods for determining (608) whether the user metric vector (606) is outside the user metric space (610) (309). Determining whether the user metric vector (606) is outside the user metric space (610) (309) (608) The first exemplary method is the user metric (206) of the user metric vector (606) and related Comparing (806) the metric value of the metric (664) with the metric range (210) of the metric space (610). In some examples of the present invention, a comparison between a user metric or related metric value and its corresponding metric range is a measure of the degree that the value is outside the metric range and the value is a metric Includes identification of being above or below the range.

  In many exemplary embodiments of the invention, the determination of whether the user metric vector is outside the metric space is a function of a number of individual comparisons between the metric value and the metric range. In various alternative embodiments of the invention, different criteria are used to identify the number of metric values that should be outside the corresponding metric range to determine that the user metric vector is outside the metric space. Or to some extent any metric value is outside the corresponding metric range. In some embodiments, using strict criteria for determining whether the user metric vector is outside the user metric space, if only one metric value is outside the corresponding metric range, The user metric vector is determined to be outside the metric space. In other embodiments, all of the user metric vectors are, to some extent, outside the corresponding metric range, using a less stringent criterion for determining whether the user metric vector is outside the user metric space. The user metric vector is determined to be outside the user metric space. In various embodiments, the number of metric values that should be outside the corresponding metric range, or the metric value is outside the corresponding metric range, to determine that the user metric vector is outside the metric space. To some extent, it is different. All these methods of determining whether a user metric vector is outside the metric space are within the scope of the present invention.

  A second exemplary method shown in FIG. 13 for determining that the user metric vector (606) is outside the user metric space (610) (608) is to calculate a metric vector value (812) (810), and Metric space value (816) calculation (814) and metric vector value (812) comparison with metric space value (816) (818). One way to calculate a metric vector value is to use a predetermined equation to reveal a single value that is a function of the user metric of the user metric vector and the metric value of the associated metric. In one exemplary embodiment of the present invention, the calculation of the metric vector value includes averaging the metric value of the user metric vector. In another exemplary embodiment, calculating the metric vector value includes prioritizing certain metrics and related metrics, and calculating the metric vector value using a weighted average based on the metric priority. .

  In some exemplary embodiments, the calculation (814) of the metric space value (818) uses a predetermined formula to determine a metric space value that is a function of the minimum and maximum values of each metric range of the user metric space. Including seeking. In one exemplary embodiment, the calculation of the metric space value includes finding the center point of the minimum and maximum values of each metric range and then averaging the center points.

  The illustrated method includes a comparison (818) of the metric space value (816) and the metric vector value (812). In various embodiments of the present invention, there are various ways in which the metric vector value and the metric space value are compared to determine whether the metric vector is outside the metric space. In one exemplary embodiment, the metric vector value is subtracted from the metric space value. If the result of the subtraction is within a predetermined range, it is determined that the user metric vector is in the metric space. In the same example, if the result of the subtraction is not within the predetermined range, the metric vector value is not determined to be in the metric space.

  The illustrated method of FIG. 13 is provided for purposes of illustration and not limitation. There are many other ways in which the metric range and metric values can be compared, combined, manipulated, or otherwise used to determine that the user metric vector is outside the metric space. All such comparisons, combinations, manipulations, and other methods of using metric values and metric ranges to determine that a user metric vector is outside the metric space are within the scope of the present invention.

  FIG. 14 is a data flow diagram illustrating an exemplary method for identifying (630) an action (315). In the method of FIG. 14, identifying an action includes generating a dynamic action list (626) in response to a user metric vector (606). The normal dynamic action list is associated with a specific metric of the user's metric space outside the corresponding metric range or multiple metric ranges and the user's metric vector outside the corresponding metric range of the specific associated metric An action ID that is dynamically identified according to an action ID included in the weighing action list is included. Such dynamic action list generation advantageously provides a set of action IDs configured to manage the device in response to the user's current situation.

  In the method of FIG. 14, the generation (624) of the dynamic action list (626) in response to the user metric vector (606) includes each user metric of the user metric vector (622) having a value outside the metric range of the user metric space. (206) and a metric action list (622) identification (752) for each associated metric. In many examples of the method of FIG. 14, a metric for each user metric (206) and associated metric (664) that is outside the corresponding metric range, and for each associated metric that is outside the corresponding metric range. The identification (752) of the action list (622) is based on the weighing action list from the weighing object previously identified as being outside the corresponding weighing range when it is determined that the user weighing vector is outside the user weighing space. And retrieving a reference to the weighing action list from the associated metric previously identified as being out of the corresponding metric range. In many instances, a metric object that is outside the metric range is identified when the metric object is compared to the metric range to determine if the user metric vector is outside the metric space.

  In many examples of the method of FIG. 14, a metric has a plurality of metric action lists associated with it. Each associated weighing action list includes a set of action IDs for the weighing value to be executed depending on the degree and direction outside the weighing range. Accordingly, in some examples of the method of FIG. 14, the identification of a metric action list (622) for each user metric (206) of a user metric vector (606) having a value outside the metric range of the user metric space ( 752) includes identifying the metric list to some extent that the value of each user metric in the user metric vector is outside the metric range of the user metric space. In another example of the method of FIG. 14, the identification (752) of the metric action list (622) for each user metric (206) of the user metric vector (606) having a value outside the metric range of the user metric space is Identifying the metric list according to a direction in which each user metric value of the user metric vector is outside the metric range of the user metric space.

  In the method of FIG. 14, generating (624) a dynamic action list (626) in response to a user metric vector (606) retrieves at least one action ID (315) from each metric action list (622) ( 754). Some metric action lists include multiple action IDs, and thus many examples of the method of FIG. 14 include multiple action IDs from the metric action list associated with each metric having a value outside the corresponding metric range. Including searching.

  In the example of FIG. 14, the generation (624) of the dynamic action list (626) according to the user metric vector (606) is performed according to the action ID (315) retrieved from the metric action list (622). (756) identifying at least one action ID (315) for inclusion in (626). In many examples of the method of FIG. 14, at least one action ID (315) is identified for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). (756) includes the identification of the action ID retrieved directly from the metric action list for inclusion in the dynamic action list. That is, in some examples of the method of FIG. 14, the same action ID retrieved from the metric action list is included in the dynamic action list.

  In the method of FIG. 14, at least one action ID (315) is identified (756) for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). Includes comparing (758) the action ID (315) of the metric action list (622) and omitting the repetitive action. In some examples of the method of FIG. 14, omitting repeated actions includes determining that the same action ID is included in more than one metric action list. In such an example, generating a dynamic action list includes identifying a metric action list that has the same action ID and includes the action ID only once in the dynamic action list.

  In the method of FIG. 14, at least one action ID (315) is identified (756) for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). Includes retrieving (760) the action ID (315) from the dynamic action table (762) in response to at least one action ID in the metric action list. In many examples of the method of FIG. 14, the dynamic action table (762) is a data structure that includes action IDs that are indexed by other action IDs. That is, the dynamic action table is a data structure designed to index a predetermined action ID for inclusion in the dynamic action list in accordance with the action ID retrieved from the weighing action list.

  Accordingly, in many examples of the method of FIG. 14, such a dynamic action table identifies conflicting actions retrieved from the metric action list, identifies replacement actions retrieved from the metric action list, and Designed to identify other actions not included in the action list. In some examples of the method of FIG. 14, at least one action ID (315) is identified for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). Doing (756) includes omitting conflicting actions. In many examples of the method of FIG. 14, a dynamic action table is used to identify action IDs previously determined to be in conflict. For example, an action ID included in one metering action list that identifies a device control action that turns on a ceiling fan conflicts with an action ID that identifies a device control action that turns off the same ceiling fan. Such competitive action ID is omitted from the dynamic action list.

  In some examples of the method of FIG. 14, at least one action ID (315) is identified for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). Doing (756) includes omitting the replaced action. A replaced action is an action that, when executed, manages the same device in the same direction as another replacing action, but manages the device to a lesser degree than another replacing action. That is, an action is replaced when another action manages the same device to a greater degree, and execution of the replaced action is hidden by execution of the replacing action. For example, execution of an action ID that changes the current attribute value of a ceiling fan from “5” to “4” is replaced by execution of an action ID that changes the attribute of the same ceiling fan from “5” to “2”. Is done. In many examples of the method of FIG. 14, a dynamic action table is used to identify action IDs that are predetermined to replace other action IDs. Many examples of the method of FIG. 13 include omitting the replaced action ID from the dynamic action list and including an action ID that replaces it.

  In the method of FIG. 14, at least one action ID (315) is identified (756) for inclusion in the dynamic action list (626) in response to the action ID (315) retrieved from the metric action list (622). Includes identifying action IDs that are not included in any of the identified metric action lists (622) for inclusion in the dynamic action list. In many examples of the method of FIG. 14, the action ID identified by the lookup of the dynamic action table (762) is not included in any of the identified weighing actions. In some of these examples, action IDs that are predetermined to affect the same user situation as other action IDs when executed are set in the dynamic action table. Such a dynamic action table is indexed to identify action IDs for execution when one or more other action IDs are retrieved from the metric action list. Thus, the dynamic action table advantageously provides a means for identifying and executing more actions that affect the user's current situation.

  To further illustrate the identification of action IDs not included in any metric action list associated with a user metric outside the corresponding range, the following example is given. The two user metrics in the user metric vector exceed the corresponding metric range in the user metric space. The first metric represents body temperature and has a first action ID in the associated metric action list that, when executed, turns on the ceiling fan. The second metric represents the heart rate and has a second action ID in the associated metric list that, when executed, turns on the air conditioner. The dynamic action table lookup according to the first action ID and the second action ID retrieves a third action ID that is not included in either metric action list of either metric. Execution of the third action ID results in turning on the ceiling fan, turning on the air conditioner, and drawing automatic awning. Additional actions for automatic awning are predetermined to affect the same user situation as turning on the air conditioner and ceiling fan. The dynamic action table lookup identifies a third action ID for inclusion in the dynamic action list based on the first and second action IDs.

  FIG. 15 is a data flow diagram illustrating an exemplary method for identifying (630) an action. In the method of FIG. 15, identifying the action includes determining (970) the user's location (972). In many examples of the method of FIG. 15, determining a user's position includes retrieving a reference to a user metric (206) for a position from a user metric vector, and retrieving a value for the user metric for the position. In other examples of the method of FIG. 15, determining the user's position may include inferring the user's position from other metrics, identifying changes in device attributes caused by direct management of the device by the user, or the like. Including estimation of the user's position by any other user position estimation method recalled by the merchant.

  In the method of FIG. 15, the identification of the action includes a determination (971) of the user movement (974). In some examples of the method of FIG. 15, determining user movement includes searching a user metric vector for an associated metric (664) that represents the user's movement, and retrieving a value for the associated metric. In some examples of the method of FIG. 15, the determination of user movement includes retrieving a plurality of related metrics (664) representing various characteristics of user movement from a user metric vector, and a plurality of related metric values. Including searching.

  In the method of FIG. 15, identifying an action (630) includes selecting an action ID (315) (975) in response to the user's location (972) and the user's movement (974). In the method of FIG. 15, selecting an action ID in response to the user's location and user movement (975) includes retrieving an action ID from the action table in response to the user's location and user movement.

  In many examples of the method of FIG. 15, the action table (975) includes an action ID indicated by a location and a particular user movement. In the exemplary example of the method of FIG. 15, the action ID in the action table identifies an action whose scope is designed to manage a particular device that covers the user's current location, and further Designed to manage devices in a way that matches the movement of the device. For example, there may be a case where the user is in the living room and the living room has a radio whose effective range covers this living room. Furthermore, the action may be designed to slowly reduce the volume of the radio as the user approaches the position of the radio. Conveniently, the specific action ID selected from the action table in response to the user's location and the user's movement can perform device control based on location.

  Consider the following example: The user's metric vector indicates that the user's heart rate has exceeded the corresponding metric range. The DML turns on the user's music player and identifies and executes an action ID that identifies the action to set the player to play music designated to calm the user. The DML also determines that the user is in the living room, and the DML determines that the user is moving toward the music player. Another action ID designed to lower the volume at a speed appropriate to the user's speed and direction is identified and executed. As a result of lowering the volume, the volume does not seem to change for the user.

  Some examples of the method of FIG. 15 generate a dynamic action list by selecting (975) an action ID (315) in response to a user location (972) and a user movement (974). Identifying the action (630) by identifying the action. That is, more than one method of identifying actions is performed in conjunction, often identifying and performing many actions. In other examples, action identification may be performed by selecting (975) an action ID (315) in response to the user's location (972) and user movement (974), or generating a dynamic action list. This is done by identifying the action or by any other method of identifying actions that will occur to those skilled in the art.

  From the foregoing description, it will be appreciated that various modifications and changes can be made in the various embodiments of the present invention without departing from the true spirit. The descriptions in this specification are for purposes of illustration only and are not to be construed in a limiting sense. The scope of the invention is limited only by the language of the claims.

FIG. 2 is a block diagram illustrating an exemplary architecture useful in implementing a device management method according to the present invention. FIG. 3 is a block diagram illustrating an exemplary service gateway. FIG. 3 is a block diagram illustrating exemplary classes useful in implementing a device management method according to the present invention. FIG. 4 is a class relationship diagram illustrating example relationships between some of the example classes of FIG. FIG. 4 is another class relationship diagram illustrating exemplary relationships between some of the exemplary classes of FIG. FIG. 4 is a data flow diagram illustrating an exemplary device management method according to the present invention. FIG. 3 is a data flow diagram illustrating an exemplary method for performing an action. FIG. 4 is a data flow diagram illustrating an exemplary method for determining whether a user metric is outside a user's default metric range in accordance with the present invention. FIG. 4 is a data flow diagram illustrating an exemplary device management method according to the present invention. FIG. 4 is a data flow diagram illustrating an exemplary method for generating an associated metric in accordance with the present invention. FIG. 4 is a data flow diagram illustrating an exemplary method for generating an associated metric according to the present invention. FIG. 3 is a data flow diagram illustrating an exemplary method for generating a user metric vector and an exemplary method for generating a metric space in accordance with the present invention. FIG. 4 is a data flow diagram illustrating an exemplary method for determining whether a user metric vector is outside a user metric space in accordance with the present invention. FIG. 4 is a data flow diagram illustrating an exemplary method for generating a dynamic action list in accordance with the present invention. FIG. 4 is a data flow diagram illustrating an exemplary method for identifying actions in accordance with the present invention.

Claims (30)

A method for managing devices,
Receiving a plurality of user metrics;
Generating an associated metric based on the plurality of user metrics;
Generating a user metric vector having at least one user metric and at least one associated metric;
Generating a user metric space having a plurality of metric ranges;
Determining whether the user metric vector is outside the user metric space;
Identifying an action if the user metric vector is outside the user metric space;
Performing the action;
Having a method. The method of claim 1, wherein generating an associated metric based on the plurality of user metrics comprises filtering the user metric. 3. The method of claim 2, wherein generating an associated metric based on the plurality of user metrics comprises determining a relationship between a first filtered user metric and a second filtered user metric. The step of determining a relationship between a first filtered user metric and a second filtered user metric comprises comparing the first filtered user metric with a second filtered user metric. Method 3. Generating an associated metric based on the plurality of user metrics comprises determining a magnitude of the relationship between the first filtered user metric and the second filtered user metric. Item 4. The method of item 3. The method of claim 1, wherein generating an associated metric based on the plurality of user metrics comprises determining whether the plurality of user metrics match a predetermined metric pattern. 7. The method of claim 6, comprising searching for an associated metric if the plurality of user metrics match the predetermined metric pattern. Generating a user metric vector having at least one user metric and at least one associated metric includes associating at least one user metric with the user metric vector, and associating at least one associated metric with the user metric vector. The method of claim 1, comprising steps. The step of identifying actions is
Determining the position of the user;
Selecting an action ID based on the location of the user;
The method of claim 1 comprising: The step of identifying actions is
Determining user movement; and
Selecting an action ID based on the movement of the user;
10. The method of claim 9, comprising: A system for managing devices,
Means for receiving a plurality of user metrics;
Means for generating an associated metric based on the plurality of user metrics;
Means for generating a user metric vector having at least one user metric and at least one associated metric;
Means for generating a user metric space having a plurality of metric ranges;
Means for determining whether the user metric vector is outside the user metric space;
Means for identifying an action if the user metric vector is outside the user metric space;
Means for performing the action;
Having a system. The system of claim 11, wherein the means for generating an associated metric based on the plurality of user metrics comprises a means for filtering the user metric. The means for generating an associated metric based on the plurality of user metrics comprises means for determining a relationship between a first filtered user metric and a second filtered user metric. System. The means for determining a relationship between the first filtered user metric and the second filtered user metric comprises means for comparing the first filtered user metric with the second filtered user metric. 14. The system of claim 13, comprising: The means for generating an associated metric based on the plurality of user metrics is a means for determining the magnitude of the relationship between the first filtered user metric and the second filtered user metric. 14. The system of claim 13, comprising: The system of claim 11, wherein the means for generating an associated metric based on the plurality of user metrics comprises means for determining whether the plurality of user metrics match a predetermined metric pattern. 17. The system of claim 16, comprising means for retrieving an associated metric when the plurality of user metrics match the predetermined metric pattern. Means for generating a user metric vector having at least one user metric and at least one associated metric are: means for associating at least one user metric with the user metric vector; and 12. The system of claim 11, comprising means for associating with a metric vector. The step of identifying actions is
Means for determining the position of the user;
Means for selecting an action ID based on the location of the user;
12. The system of claim 11, comprising: Means for identifying actions are:
Means for determining user movement;
Means for selecting an action ID based on the movement of the user;
20. The system of claim 19, comprising: A computer program product for managing devices,
A recording medium;
Means for receiving a plurality of user metrics recorded on the recording medium;
Means for generating an associated metric based on the plurality of user metrics recorded on the recording medium;
Means for generating a user metric vector recorded on the recording medium having at least one user metric and at least one associated metric;
Means for generating a user metric space having a plurality of metric ranges recorded on the recording medium;
Means for determining whether the user metric vector recorded on the recording medium is outside the user metric space;
Means recorded on the recording medium for identifying an action if the user metric vector is outside the user metric space;
Means for performing the action recorded on the recording medium;
Having a product. The means for generating an associated metric based on the plurality of user metrics recorded on the recording medium comprises means for filtering the user metric recorded on the recording medium. 21 computer program products. The means for generating an associated metric based on the plurality of user metrics recorded on the recording medium includes a first filtered user metric and a second filtered user recorded on the recording medium. 23. The computer program product of claim 22, comprising means for determining a relationship between metrics. The means for determining a relationship between the first filtered user metric and the second filtered user metric recorded on the recording medium is the first filtering recorded on the recording medium. 24. The computer program product of claim 23, comprising means for comparing the measured user metric with a second filtered user metric. The means for generating an associated metric based on the plurality of user metrics recorded on the recording medium includes the first filtered user metric and the second filtering recorded on the recording medium. 24. The computer program product of claim 23, comprising means for determining the magnitude of the relationship between the measured user metric and the user metric. The means for generating an associated metric based on the plurality of user metrics recorded on the recording medium is configured to determine whether the plurality of user metrics recorded on the recording medium match a predetermined metric pattern. 26. The computer program product of claim 25, having means for determining whether or not. 27. The computer program product of claim 26, comprising means recorded on the recording medium for retrieving an associated metric if the plurality of user metrics match the predetermined metric pattern. The means for generating a user metric vector having at least one user metric and at least one associated metric recorded on the recording medium is the at least one user metric recorded on the recording medium. 22. The computer program product of claim 21, comprising means for associating with a metric vector and means for associating at least one associated metric recorded on the recording medium with the user metric vector. Identifying an action recorded on the recording medium comprises:
Means for determining a user's position recorded on the recording medium;
Means for selecting an action ID based on the position of the user recorded on the recording medium;
The computer program product of claim 21, comprising: The means for identifying the action recorded on the recording medium is:
Means for determining movement of a user recorded on the recording medium;
Means for selecting an action ID recorded on the recording medium based on the movement of the user;
30. The computer program product of claim 29, comprising:

Images