DISTRIBUTED HOME AUTOMATION SYSTEM ARCHITECTURE

DEVICE ADDRESS BOOK

RELATED APPLICATIONS

This patent claims priority to and the benefit of the previously filed provisional patent applications “Home Networking,” filed on August 17, 1999, and assigned serial no. 60/149,390 [attorney docket no. 1018.050US0], and “Home Networking System,” filed on February 24, 2000, and assigned serial no. 60/184,631 [attorney docket no. 141388.2].[MAD1]

field of the invention

This invention relates generally to a distributed system, such as a distributed home automation system, and more particularly to a device address book for such a system for referencing devices.

BACKGROUND OF THE INVENTION

With the increasing popularity of the World Wide Web (WWW, also referred to as “the web”), there is increasing movement towards a fully connected world. The web, which started as an information access mechanism, is now changing the way people live, by providing multimedia communications, electronic commerce, etc. The success of the web has demonstrated that the power of being connected can drive innovations and create new applications.

As broadband communications are being brought to homes at an accelerating pace, and as small handheld devices are becoming smarter, more popular, and better connected, the notion of being able to communicate with anything that one cares to at any time from anywhere is starting to become a reality. Within this context, home networking, in which existing devices and future smart appliances are fully connected inside the house and accessible to homeowners whenever needed, is becoming more popular. Home networking is moving towards enabling multi-computer games, digital video and audio anywhere in the house, device automation, remote diagnosis of out-of-order home appliances, etc.

Different people have different ideas as to what home networking should accomplish, depending on their lifestyles. While some people are most interested in the ease of operating their audio/video equipment, and rich multimedia entertainment in general, other people are more concerned about the security and safety of their homes, and would like to be able to remotely monitor their houses, control their appliances, and be notified when something important happens.

Currently, there are two popular home networking infrastructures. The first is phoneline networking. To provide in-home networking without requiring the rewiring of houses, the Home Phoneline Networking Alliance (HomePNA) was formed to create standards that leverage the existing phonelines in people’s homes. Commercial products are now available for providing essentially one or ten megabit-per-second Ethernet networking capability over phonelines. The technology occupies the frequency range between 5.5 MHz and 9.5 MHz, and can coexist with standard voice communications, which lie between 20 Hz and 3.4 kHz, and digital-subscriber loop (DSL) high-speed data communications, which lie between 25 kHz and 1.1 MHz, without interference. Products based on a newer ten megabit-per-second Ethernet technology are also expected to emerge[WGR2] .

A second home networking infrastructure is powerline networking. Powerline networking provides ubiquitous wired connectivity throughout the majority of homes. However, due to the varying quality of physical wiring and the inherently less secure connection topology, commercial powerline networking products have not made as significant progress as their phoneline counterparts in terms of both bandwidth and programming abstraction. Currently, the X10 powerline control protocol is most popular, and has the most consumer-ready products available. The X10 protocol transmits binary data over a powerline by using a 120 kHz signal burst for one millisecond at the zero-crossing point of a 60 Hz alternating current (AC) sine wave. In most cases, computers communicate with X10 protocol interfaces through their serial ports, where the interfaces generate the corresponding X10 signals.

Difficulties with home networking systems, such as powerline and phoneline networking, are numerous. Their heterogeneity, while offering homeowners many different options, make intercommunication difficult. Because product cost is an issue, many of these consumer devices are inherently undependable. Furthermore, because by definition home networking systems are to be installed in the home, usually there is a lack of knowledgeable system administrators in the home networking environment, as compared to, for example, the corporate networking environment.

Described in the cofiled, copending and coassigned patent application entitled “Distributed Home Automation System Architecture” [attorney docket no. 1018.050US1] is a distributed home automation system architecture that overcomes these disadvantages. In one embodiment of the system described in this patent application, a device address book is described that provides for the referencing of devices. Such a device address book is the focus of this patent application.

SUMMARY OF THE INVENTION

The invention relates to a device address book for utilization within a distributed system, such as a distributed home automation system. In one embodiment, each device or object having an entry within the device address book has a number of synchronous addresses and/or a number of asynchronous addresses. The synchronous addresses are for when a caller desires synchronous communication with the device. If the device goes offline, the synchronous addresses times out or are specifically revoked within the address book, such that only asynchronous communication is possible. The asynchronous addresses are thus for when a caller desires asynchronous communication with the device, and are available within the address book even if the device goes offline (although it is noted that asynchronous addresses can also time out, for example). Synchronous communication is analogous in some respects to a phone call, while asynchronous communication is analogous in some respects to email communication. Methods, home automation systems, distributed systems, device address books, and computer- and machine-readable media of varying scopes are encompassed by the invention. Other aspects, embodiments and advantages of the invention, beyond those described here, will become apparent by reading the detailed description and with reference to the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of a home automation system architecture according to an embodiment of the invention;

FIG. 2 is a diagram of a more concrete home automation system architecture according to an embodiment of the invention;

FIG. 3 is a diagram showing that one object, such as a device, can have multiple addresses for communicating therewith, according to an embodiment of the invention;

FIG. 4 is a diagram of a system according to an embodiment of the invention;

FIG. 5 is a diagram of a software architecture for a home automation system according to an embodiment of the invention; and,

FIG. 6 is a diagram of an example computer or a computerized device in conjunction with which embodiments of the invention can be practiced.

DETAILED DESCRIPTION OF THE INVENTION

In the following detailed description of exemplary embodiments of the invention, reference is made to the accompanying drawings which form a part hereof, and in which is shown by way of illustration specific exemplary embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that logical, mechanical, electrical and other changes may be made without departing from the spirit or scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

Overview

An overview of a distributed home automation system architecture in conjunction with which embodiments of the invention can be practiced is shown in FIG. 1. It is noted that embodiments of the invention are applicable to any type of distributed system; the home automation system described herein is one type of such a system. The system 100 includes the powerline layer 102, the abstraction layer 104, and the Internet layer 106. The powerline layer 102 is the layer in which home automation devices, such as X10 devices, reside. The abstraction layer 104 is above the powerline layer 102, and abstracts the manner by which the devices in the powerline layer 102 can be accessed and controlled. For example, lookup services can be implemented for maintaining information announced by devices, as well as by purely software entities. As another example, the abstraction layer 104 can provide a natural language interface for accessing and controlling the devices in the powerline layer 102. The Internet layer 106, which is optional, is above the abstraction layer 104, and provides for remote, off-site access and control of the powerline layer 102 through the abstraction layer 104. For example, a homeowner can utilize the Internet layer 106 from work (e.g., using email) in order to access and control his or her home networking system.

There are two paths through the system 100, a notification path 108, and a control path 110. The notification path 108 starts with the devices in the powerline layer 102, and moves up to the abstraction layer 104, and can also move up to the Internet layer 106. The notification path 108 includes notifications from the devices in the powerline layer 102, such as the initial announcements of the existence of the devices when they are first plugged in, to various alerts generated by the devices for user review (e.g., a smoke alarm has detected smoke, etc.). The control path 110 starts at either the Internet layer 106 or the abstraction layer 104, and moves down to the powerline layer 102. The control path 110 includes control of the devices within the powerline layer 102 as originating from either the Internet layer 106 or the abstraction layer 104 (e.g., a user indicating that the garage door should be closed, etc.).

A more concrete example of a home automation system in conjunction with which embodiments of the invention can be practiced is shown in FIG. 2. The system 200 of FIG. 2 shows how a user can perform home automation tasks remotely, such as sending an email 202 to request closing the garage door via the garage door opener 204 that the user forgot to close when he or she left the house. Beginning with device discovery, when the garage door opener 204 is plugged into an electrical outlet in the garage, the server 208 of the system 200 is automatically notified that the opener is available. When a computer 212 is plugged into a garage outlet and when a camera 210 is installed on that computer 212, the server 208 of the system 200 knows that it is the camera to use when someone requests a snapshot or a video clip of the garage. Such information is maintained by the lookup services 214, which can use file replication and periodic multicasts to provide high availability.

The user, off-site at the laptop computer 218, sends a digitally signed and encrypted email 202 using a regular Internet service provider (ISP) account over the Internet 216. A daemon process within the server 208 of the system 200 periodically connects to the Internet to check for such emails, and thus receives the request within the email 202. The process invokes language understanding 220 to understand and convert the request, which is then presented to the lookup services 214 to locate the target devices, which in this case are the garage door opener 204 and the garage camera 210. Device control commands are then sent over the appropriate media (e.g., powerline, phoneline, radio frequency (RF), infrared (IR), etc.) to reach the devices and perform the requested actions. In the example of FIG. 2, the garage door is closed, and a video clip of the closing action is sent back to the user as confirmation.

It is noted that in one embodiment, the lookup services 214 are hosted by a third server, not shown in FIG. 2, such that the server 208 is the Internet server and the server for the garage door opener, and the server 212 is the host for the camera 210. [MAD3]

In FIG. 5, a home automation system software architecture 500 in conjunction with which embodiments of the invention can be practiced is shown. The architecture 500 provides an abstraction over the hardware devices 502, and connects them to external communication infrastructure 510; the architecture 500 can act as the abstraction layer previously described. The architecture includes a system infrastructure 504, an application layer 506, and a user interface 508. Each is described in turn.

The system infrastructure 504 includes six components. The soft-state store 511 manages the lifetime and replication of soft-state variables across individual data stores on each computer, and is more specifically described in the cofiled, copending and coassigned patent application entitled “Soft-State Store for a Home Automation System” [attorney docket no. 1018.050US4]. The publication/subscription eventing component 512 allows programs to subscribe to events related to changes in the soft-state store 511, and is also more specifically described in the cofiled, copending and coassigned patent application entitled “Soft-State Store for a Home Automation System” [attorney docket no. 1018.050US4]. The attribute-based lookup service (ABLS) (part of the services 514) maintains a database of all available devices and supports queries based on device attributes such as device type, physical location, etc. The name-based lookup service (NBLS) (also part of the services 514) maintains a table of all running object instances and supports simple name-to-object address mapping. In one embodiment, the NBLS is an instantiation of a device address book that can be utilized to accommodate multiple programming paradigms necessary for a dynamic environment, such that each device can be reached by multiple objects and each object can be reached through multiple addresses (e.g., an address for asynchronous calls and an address for synchronous calls). This is more particularly described in later sections of the detailed description.

The device announcement protocol 516 describes how devices not connected to the main Ethernet network announce their existence to the attribute-based lookup service. A device adapter can be used to implement an instance of that protocol for powerline devices, as is more specifically described in to cofiled, copending and coassigned patent application entitled “Device Adapter for a Home Automation System” [attorney docket no. 1018.050US5]. Finally, the system management daemons 518 are responsible for detecting the failures of computers and devices, and initiating recovery actions. The daemons 518 can include a node diagnosis daemon that, upon suspecting a node failure, initiates diagnosis through multiple networks and either locally resets the failed node or remotely power-cycles the node, as well as a powerline activity monitoring daemon that constantly monitors the powerline control-command traffic and, upon detecting intrusions or reliability problems, either alerts the homeowner or initiates corrective actions. The former daemon is more particularly described in the cofiled, copending and coassigned patent application entitled “Weak Leader Technique for a Home Automation System” [attorney docket no. 1018.050US3]. The latter daemon is more particularly described the cofiled, copending and coassigned patent application entitled “Determination of Powerline Pattern Acceptability and Unacceptability” [attorney docket no. 1018.050US2].

With respect to the application layer 506, there are two types of home networking applications 524 provided by the system 500. In a control-type scenario, the applications receive user requests as input, consult the lookup services to identify the devices and device objects that should be involved, and perform actions on them to satisfy the request. Device objects 520 encapsulate device- and network-specific details and present interfaces (e.g., sets of method calls) as the programming abstraction for device control in one embodiment; more generally, the device objects 520 define the semantics of control for that object, using whatever protocol(s) they deem appropriate. Examples include camera objects for taking snapshots and recording video clips, garage door opener objects for operating the garage doors, etc. In a sensing-type scenario, the applications monitor a list of environmental factors and take actions when any of the monitored events occur. Through the attribute-based lookup service, the applications identify the appropriate events to subscribe to. Independently, device daemons 522 act as proxies for sensors by monitoring sensor signals and updating appropriate soft-state variables to trigger events. For example, an alerting application running on every UAP can subscribe to all events corresponding to critical sensors (water sensors, temperature sensors, safe-box sensors, etc.), as defined by a homeowner or a particular system, etc., and sound alerts when any of the sensors fires.

Next is the user interface 508, which provides for user access to the system infrastructure 504 and the application layer 506. Unlike many other distributed systems, home networking systems are intended for use by computer users who may be naïve in their computer knowledge, so providing a friendly user interface can be important. The user interface 508 has three parts: a browser interface 526, a voice-based interface 528, and a text-based natural language interface 530. The browser interface 526 allows the user to browse through all available devices or select devices based on attributes using a web browser program or operating system component, and to control devices through a standard point-and-click process. The text-based natural language interface 530 is based on a limited but customizable vocabulary, while the voice-based interface 528 employs speech recognition technology based on the same vocabulary.

The user interface 508 can be extended to support remote home automation when the user is away from the house. For example, when an always-on Internet connection such as DSL or cable modem is available, the browser interface 516 can be used from remote locations. The text-based natural language interface 530 can be extended to an email-based remote home automation interface. The user can send an email containing a control request to an account hosted by an Internet service provider (ISP). The email daemon 532 periodically dials up the ISP, retrieves and parses the request, performs the actions, and sends a reply email that may optionally contain a video clip confirming these actions, as is more specifically described in the copending, cofiled and coassigned application entitled “Video Confirmation Process for a Home Automation System” [attorney docket. 1018.050US6]. In addition to standard security mechanisms such as digital signatures and data encryption, the home control vocabulary can be customized to provide additional security. Through the text-messaging support provided by cell phones the email daemon 532 can almost synchronously alert the users wherever they are when, for example, any of the critical sensors fires at home. The voice-based interface 528 can also be extended to work over telephony.

It is noted that the system infrastructure 504 attempts to ensure dependability in the presence of undependability sources such as computer failure, network failure, device failure, and service failure. This can be accomplished through stabilization. That is, if the system is placed in an arbitrary state, it eventually reaches a state from where the system computation is as desired. This can be accomplished by utilizing a hierarchy of desired computations, and allowing the system to converge to those computations in the hierarchy that it can recover to most effectively. This is sometimes referred to within the art as pseudo-stabilization. [WGR4]

Device Address Book

In this section of the detailed description, a device address book that can be utilized with distributed systems, such as distributed home automation systems as described in the previous section of the detailed description, is described. The device address book accommodates multiple programming paradigms that may be necessary for a dynamic heterogeneous environment. Each device can be reached by multiple objects, and each object can be reached through multiple addresses – for example, one for synchronous calls when the object is active and another address for queued, asynchronous calls when the object is temporarily unavailable. This is analogous to the human communication model in which each person can have a phone number, an email address, a web page Universal Resource Locator (URL) address, etc., in an address book entry.

That an object, such as an object for a device, can have multiple addresses is shown in FIG. 3. In the diagram 300 of FIG. 3, the object 302, such as a device[WGR5] , may have one or more synchronous addresses 304, and one or more asynchronous addresses 306. The synchronous addresses 304 may include an address in the form of a marshaled distributed-object interface pointer, or any other type of ~~pointer~~reference that when utilized results in direct synchronous communication with the device object. Other entities can unmarshal this address to obtain the interface pointer and use it to make synchronous Object Remote Procedure Calls (ORPC’s). This is analogous to one person calling another on the phone to have a synchronous communication. The asynchronous addresses 306 may be in the form of a queue name, a marshaled handle to a queue, or other address. Other entities can use this queued address to asynchronously communicate with the object when it is temporarily unavailable or too busy, or when the caller prefers not doing synchronous communication. This is analogous to the use of email. However, it is noted that asynchronous addresses can time out as well. In one embodiment, all addresses can time out, but with a variable timescale. For example, the asynchronous address may not time out until after a period of days, while the synchronous address may time out as soon as its associated object is unavailable or busy.

When an object for a device goes offline, such as a result of a failure of the device, etc., the synchronous address is desirably automatically removed from the address book, so that callers cannot attempt synchronous communication with the device. However, the asynchronous address remains in the address book, although it can also time out, but at a longer time interval as compared to the synchronous address. In one embodiment, the object must periodically refresh its entry in the address book for the synchronous address of the entry to remain in the address book; in another embodiment, the asynchronous address must also be refreshed (albeit at longer intervals). Thus, while there can be a period of time that the synchronous address is in the book while the device to which the address corresponds has already gone offline, this situation will be for a short period of time, until the address times out. Thus, it is said that the synchronous address remains in the address book only substantially as long as the device therefor is online.

Thus, an object such as a device may have both synchronous and asynchronous addresses for communication therewith, depending on the availability of the device and/or the preference of the calling entity. Several different specific types of addresses are now described in more detail. These addresses include phone number, voice mailbox numbers, email addresses, mobile phone numbers, and web pages.

Phone numbers are first described. Humans use phone calls for real-time communications just like objects use RPC calls for synchronous communications. Therefore, phone numbers correspond to object references through which RPC [WGR6] calls can be made. A single phone call is modeled as a series of RPC calls. A synchronous communication paradigm in general simplifies programming and allows objects to interact optimally based on up-to-date state information exchange. These are the same reasons that many people still prefer making phone calls today when they can.

Voice mailbox numbers are now described. Distributed objects can have the equivalent of voice mailboxes for clients to synchronously deliver queued requests with optional callback addresses. In analogy to the human behavior of leaving a message after failing to reach a person, a client of an object can switch to a queued call after a synchronous RPC call fails. Just like some people have phone numbers that are dedicated for voice mails, objects’ voice mailboxes can also be used independently, instead of serving as a fallback mechanism. In those cases, issuing only queued calls and handling the responses uniformly through callbacks may greatly simply programming. Another natural use of voice mailboxes is to deliver one-way messages.

Email addresses are now described. Sending emails is the asynchronous version of leaving voice mails. For most people, emails may have a lower priority than voice mails. Also, the senders can mark emails with different priorities and the inbox assistants at the receiving end can help sort out incoming messages into multiple queues for prioritized processing. Due to the asynchronous nature, the sending object may shortly receive an automatic Out-Of-Office (or vacation) reply if the destination object had set up such a service before it went off-line. In its callback routine, the sender can decide whether special actions need to be taken upon receiving an automatic reply.

Mobile phone numbers are now described. Mobile phones are a way for reaching people on the road. In the object world, mobile phones correspond to a synchronous RPC mechanism for communicating with mobile objects. Depending on whether the mobility is supported at the networking layer or the distributed-object infrastructure layer, mobile phones for objects may or may not need additional support beyond what is needed for non-mobile phones, as will be discussed later. Mobile phones can also have voice mailboxes either as a fallback mechanism for failing to synchronously communicate with mobile objects, or as an independent mechanism for synchronous delivery of queued calls.

Finally, web pages are described. It is increasingly popular for people to set up personal web pages that contain commonly requested information. In essence, a web page can be considered a personal assistant capable of serving a subset of the requests that are sent to the represented person. For example, the web page may supply electronic copies of the person’s previous papers, but it does not contain the particular paper that the person is currently working on. The web page is useful for serving the subset of the requests in the person’s absence. It also helps reducing the person’s workload. By analogy, objects can have web pages to serve the subset of method calls that can be satisfied even when the objects themselves are not running. They can also redirect some requests to their web pages at run time so that they can preserve more computing power and communication bandwidth for serving higher-priority requests. For example, a video cassette recorder (VCR) device object may want to publish the timed recording schedule that it has been programmed with on its web page so that a home automation program can retrieve that information even when the VCR is powered off. The same VCR object may also want to redirect such requests to its web page when it is busy serving multimedia streams.

A distributed system including a device address book according to an embodiment of the invention is shown in the diagram of FIG. 4. The system 400 includes a device address book 402, a client 404, a server 406, ~~proxy servers 408~~, an email server 410, a voicemail server 412, and a web server 414. The address book 402 contains the address(es) for each object or device within the system 400 (and which are not specifically shown in FIG. 4). Thus, these addresses can include asynchronous addresses and synchronous addresses. For example, the phone numbers, voice mailbox numbers, email addresses, mobile phone numbers, web page addresses, etc., as have been described are stored for an object or a device in the address book 402. Each object and device can decide which addresses it would like to publish in the address book 402. It can also restrict certain addresses to be available only to certain clients, such as the client 404. Publishing and updating of the address book 402 entries can occur upon server installation, object instantiation, object migration, object failure and restart, etc.

When a client, such as the client 404, needs access to a service, it looks up the address book 402 with the service name that identifies an object. If the client specifies particular types of addresses, only the matching addresses (that it has access permission to) are returned; otherwise, all addresses of the requested object are returned. Optionally, the address book 402 can be integrated with a capability-based lookup service, such as the ABLS lookup service described in the previous section of the detailed description. In this case, the client submits a list of capabilities that it needs, and the combined lookup service matches that list with the published capability descriptions of objects and returns the appropriate addresses. It may also be desirable to integrate the object web servers with the address book 402.

The address book 402 can be implemented as a single-daemon service, as a few cooperating daemons, or as a one-daemon-per-machine service. It can also be implemented with different levels of consistency guarantees with respect to failures. For example, when an object publishes only a phone number and then fails. The phone number is invalid until the object restarts. Different address book 402 implementations may take different approaches to address this issue. A non-masking address book never attempts to check the validity of the addresses that objects submit for publishing. The clients are responsible for handling the exceptions of invalid addresses. A masking addressing book incorporates an additional failure detection facility. Objects that have addresses registered with the address book are potentially monitored with either polling or heartbeats. Inconsistency of any address book entry is immediately corrected when it occurs, and hence masked from the clients. A self-stabilizing address book periodically checks the consistencies of its entries according to a set of rules, which also specify the appropriate correcting actions upon detecting errors. The guarantee provided to the clients is that any inconsistency will be corrected within a specified amount of time.

The infrastructure for the client 404 is next described. In one embodiment, the client 404 can be a computer or a computerized device, as is described in more detail in a later section of the detailed description. In some cases, the client 404 may wish to handle the use of multiple addresses explicitly because, for example, the synchronous version and the queued version of a call may take different input formats. In another scenario, the client 404 may want the explicit knowledge of which types of addresses are available so that it can dynamically select the address to use potentially on a per-call basis.

The infrastructure for the server 406 is next described. In one embodiment, the server 406 can be a computer or a computerized device, as is described in more detail in a later section of the detailed description. To support objects and devices with multi-mode communications (i.e., with corresponding multiple addresses), servers may have concurrent threads for listening on sockets, “listening to voice mails”, “reading emails”, etc. The default priority assignments for the various incoming message queues can be determined by mimicking the human behavior when a person first walks into his office in the morning. The assignments can also be customized as part of the server initialization procedure.

In one embodiment, the use of multiple device objects is desirable when device announcements from a device adapter for the device, as described in the previous section of the detailed description, reach multiple computers, but such that the set of reachable computers is dynamically changing due to, for example, the dynamically changing powerline partitioning in a home networking environment. When multiple device objects can be used to control a device, the device has two levels of addresses: the first level indicates which computer to select to run the device-control software, and then the second level provides all the possible ways to reach that software (or, object).

When the powerline partitioning changes in a way that a given proxy can no longer receive the periodic refresh announcements from an adapter, the device attached to the adapter loses all addresses associated with that proxy. In contrast, when the machine running a proxy fails and reboots, the device may typically lose the synchronous address associated with that proxy, but not the queued address. During recovery, others can still send requests to that queued address. When the proxy comes back online, it will process those queued requests much like a person walks into his or her office the first thing in the morning and checks his or her emails.

Each of the email server 410, the voicemail server 412, and the web server 414 is a different type of communication server. Such communication servers are described as a whole. Synchronous RPC calls usually happen directly between the client 404 and the server 406 processes. Queued calls, on the other hand, require intermediate communication servers, such as the server 410, the server 412, and the server 414, that can receive messages on the server 406’s behalf when the server is too busy or unavailable. To support email-like asynchronous delivery, the actual email protocol can be used in order to reuse as much email client and server code as possible. An alternative design is to use message queues. Voice mail-like synchronous delivery of queued calls can be implemented as synchronous RPC’s [WGR7] between the clients and the voice mail server 412.

Most mobile devices will also have non-mobile phone numbers. When they are plugged into power outlets or phone jacks, wired synchronous communications can occur through the powerline and phoneline networks, respectively. When they start moving, the support for mobile objects can be divided into two cases. If a mobile device is sufficiently powerful and can accommodate the distributed object infrastructure, the object that represents the device can run on the device itself. If the network provides transparent mobility support, the object can always listen on the same socket no matter where it moves and there is no need for additional support from the address book 402 and the infrastructure of the client 404.

For small wireless devices that are not capable of running distributed objects, the representing objects usually run on proxies and communicate with the devices directly through wireless protocols. When such a device moves around, for example, from one room to another, its object may need to migrate from one proxy server to another, which implies a change of address. The address book 402 entry therefore needs to be updated when object migration occurs. The client 404 may need to perform another address book 402 lookup when it decides to “call the object on its cell phone” because the cached number from the initial lookup may no longer be valid.

The information that can be served by an object’s web page is usually a snapshot of part of the object’s state. It is not as static as the capability descriptions in the lookup service, but also not as dynamic as the object’s real-time volatile state. For proxied devices, the objects are available on the proxies even when the devices themselves are turned off. The objects can still serve a subset of requests, but may need to fail those requests that require communications with the devices. For non-proxied devices, web pages are used to serve the same subset of requests in the objects’ absence. To make information available through the web pages, objects running on devices periodically checkpoint part of their states to the web server 414. All the communication servers, such as the servers 410, 412 and 414, are required to run on a machine (i.e., a computer) that will always stay on, while devices are turned on and off on a regular basis. In a home networking environment, such a machine can be a dedicated stand-alone computer, a refrigerator computer, a wall control panel, etc.

Example Computer or Computerized Device

In the previous sections of the detailed description, computers have been referred to as implementing and/or being used in conjunction with varying aspects of embodiments of the invention. The computers can be computers or computerized devices as is now described. In FIG. 6, the example computerized device 600 can be, for example, a desktop computer, a laptop computer, a personal digital assistant (PDA) device, a palm-size computer, a handheld computer, a cell phone, a simple, voice only phone etc.; the invention is not so limited. The description of FIG. 6 is intended to provide a brief, general description of a suitable computerized device in conjunction with which the invention may be implemented. Those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PC’s, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.

The device 600 includes one or more of the following components: processor(s) 602, memory 604, storage 606, a communications component 608, input device(s) 610, a display 612, and output device(s) 614. It is noted, that for a particular instantiation of the device 600, one or more of these components may not be present. For example, a PDA may not have any output device(s) 614, while a cell phone may not have storage 606, etc. Thus, the description of the device 600 is to be used as an overview as to the types of components that typically reside within such a device 600, and is not meant as a limiting or exhaustive description of such computerized devices.

The processor(s) 602 may include a single central-processing unit (CPU), or a plurality of processing units, commonly referred to as a parallel processing environment. The memory 604 may include read only memory (ROM) and/or random access memory (RAM). The storage 606 may be any type of storage, such as fixed-media storage devices such as hard disk drives, flash or other non-volatile memory, as well as removable-media storage devices, such as tape drives, optical drives like CD-ROM’s, floppy disk drives, etc. The storage and their associated computer-readable media provide non-volatile storage of computer-readable instructions, data structures, program modules and other data. It should be appreciated by those skilled in the art that any type of computer-readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read only memories (ROMs), and the like, may be used.

Because the device 600 may operate in a network environment, such as the home automation networks as described herein, Internet, intranets, extranets, local-area networks (LAN’s), wide-area networks (WAN’s), cellular phone networks, Plain Simple Telephony Networks (PSTN’s) etc., a communications component 608 can be present in or attached to the device 600. Such a component 608 may be one or more of a network card, such as an Ethernet card, an analog modem, a cable modem, a digital subscriber loop (DSL) modem, an Integrated Services Digital Network (ISDN) adapter, etc.; the invention is not so limited.

Furthermore, the input device(s) 610 are the mechanisms by which a user indicates input to the device 600. Such device(s) 610 include keyboards, pointing devices, microphones, joysticks, game pads, satellite dishes, scanners, etc. In an embodiment where the device 600 is a cell phone, the input device(s) 610 can include voice input capability, where the user speaks commands as a manner by which input is accomplished. Furthermore, such a cell phone or other device may include a small typewriter-style keyboard, with the keys organized in QWERTY fashion as known within the art. Or, such a device may include a standard cell phone-style numeric keyboard, or such a keyboard that has been extended in that there are one or more other keys than those usually found on such a numeric keyboard. That is, embodiments of the invention contemplate usage with any type of keyboard as the input device.

The display 612 is how the device 600 typically shows output to the user, and can include, for example, cathode-ray tube (CRT) display devices, flat-panel display (FPD) display devices, etc. In an embodiment where the device 600 is a cell phone, the display 612 can include a small display. In addition, the device 600 may indicate output to the user via other output device(s) 614, such as speakers, printers, etc. For example, in an embodiment where the device 600 is a cell phone, the output device(s) 614 can include voice output capability, where the device 614 provides voice feedback as a manner by which output is accomplished. It is noted that the combination of input devices, output devices, displays, etc., of the device 600 constitute the user interface media, or simply the media, of the device 600.

Furthermore, methods of embodiments of the invention can be computer-implemented. A computer-implemented method is desirably realized at least in part as one or more programs running on a computer – that is, as a program executed from a computer-readable medium such as a memory by a processor of a computer. The programs are desirably storable on a machine-readable medium such as a floppy disk or a CD-ROM, for distribution and installation and execution on another computer. The program or programs can be a part of a computer system or a computer. The invention is not so limited, however. Furthermore, software architectures according to embodiments of the invention can be stored on such computer- and machine-readable media.

In addition, data structures according to embodiments of the invention that represent the device address book described herein can be stored on machine-readable and computer-readable media as well. Such a device address book has an entry corresponding to each of one or more objects for a device, as has been described in the previous sections of the detailed description. That is, the entry may have one or more asynchronous addresses and one or more synchronous addresses for the object of a device.

Conclusion

It is noted that, although specific embodiments have been illustrated and described herein, it will be appreciated by those of ordinary skill in the art that any arrangement which is calculated to achieve the same purpose may be substituted for the specific embodiments shown. This application is intended to cover any adaptations or variations of the present invention. Therefore, it is manifestly intended that this invention be limited only by the claims and equivalents thereof.

We claim:

1.      A machine-readable medium having a data structure stored thereon representing a device address book for utilization within a distributed system, the device address book having an entry corresponding to each of one or more objects for a device, each entry comprising at least one address, each address comprising one of:[MAD8]
      an asynchronous address for the object, so that a caller can initiate asynchronous communication with the object; ~~and~~or,
      a synchronous address for the object, so that the caller can initiate synchronous communication with the object.

2. The medium of claim 1, wherein each synchronous address for the object remains in the address book only substantially as long as the object is online, so that synchronous communication is not initiated by the caller when the object is offline.

3. The medium of claim 2, wherein the object periodically refreshes itself such that each synchronous address therefor remains based on the periodic refreshing.

4. The medium of claim 3, wherein the object periodically refreshes itself such that each asynchronous address therefor also remains based on the periodic refreshing, wherein the periodic refreshing for each asynchronous address is less often than that for each synchronous address.

5. The medium of claim 1, wherein at least one of the synchronous addresses comprises one or more of: phone numbers, voice mailbox numbers[WGR9] , and mobile phone numbers.

6. The medium of claim 1, wherein at least one of the asynchronous addresses comprises one or more of: email addresses, and web page addresses.

7.      A distributed system including a device address book, the device address book including a number of entries, each entry comprising an address, each address comprising one of:
            an asynchronous address for a device, so that a caller can initiate asynchronous communication with the device; ~~and~~or,
            a synchronous address for the device, so that the caller can initiate synchronous communication with the device,
            wherein each synchronous address remains in the address book only substantially as long as the device is online, so that synchronous communication is not initiated by the caller when the device is offline.

8. The system of claim 7, wherein the device periodically refreshes itself such that the each synchronous address therefor remains based on the periodic refreshing.

9. The system of claim 8, wherein the object periodically refreshes itself such that each asynchronous address therefor also remains based on the periodic refreshing, wherein the periodic refreshing for each asynchronous address is less often than that for the each synchronous address.[WGR10]

10. The system of claim 7, wherein the synchronous addresses comprises one or more of: phone numbers, voice mailbox numbers[WGR11] , and mobile phone numbers.

11. The system of claim 7, wherein the asynchronous addresses comprise one or more of: email addresses, and web page addresses.

12. A home automation system comprising:
      a powerline layer of devices, each device able to be accessed and controlled remotely; and,
      an abstraction layer over the powerline layer of devices, the abstraction layer providing for abstracted remote access and control of the devices of the powerline layer, and including a device address book having at least one entry for each device, each entry comprising at least one address, each address comprising one of:[MAD12]
      an asynchronous address for the object, so that a caller can initiate asynchronous communication with the object; or,
      a synchronous address for the object, so that the caller can initiate synchronous communication with the object. ~~each entry including an asynchronous address and a synchronous address for the device.~~

13. The system of claim 12, further comprising an Internet layer over the abstraction layer, the Internet layer providing for abstracted off-site remote access and control of the devices of the powerline layer through the abstraction layer.

14. The system of claim 12, wherein the abstraction layer further provides natural language abstracted remote access and control of the devices of the powerline layer.

15. The system of claim 12, wherein a notification path starts from the powerline layer of devices and moves up to the abstraction layer.

16. The system of claim 12, wherein a control path starts from the abstraction layer and moves down to the powerline layer of devices.

17. A home automation system software architecture comprising:
      a system infrastructure to manage a plurality of devices and including a device address book having an entry for each device, each entry comprising at least one address, each address comprising one of:[MAD13]
      an asynchronous address for the object, so that a caller can initiate asynchronous communication with the object; or,
      a synchronous address for the object, so that the caller can initiate synchronous communication with the object. ~~each entry having an asynchronous address and a synchronous address for the device~~; and,
      an application layer providing at least one of controlling and sensing the devices managed by the system infrastructure.

18. The architecture of claim 17, further comprising a user interface to provide for user access to the system infrastructure and the application layer.

19. The architecture of claim 18, wherein the user interface comprises one or more of: a browser interface, a natural language interface, and a voice recognition interface.

ABSTRACT OF THE DISCLOSURE

A device address book for utilization with a distributed system, such as a distributed home automation system, is disclosed. In one embodiment, each device or object having an entry within the device address book has a number of synchronous addresses and/or a number of asynchronous addresses. The synchronous addresses are for when a caller desires synchronous communication with the device. If the device goes offline, the synchronous addresses times out within the address book, such that only asynchronous communication is possible. The asynchronous addresses are for when a caller desires asynchronous communication with the device, and are available within the address book even if the device goes offline, although asynchronous addresses can also time out.