WO2002021298A9 - Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants - Google Patents

Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants

Info

Publication number
WO2002021298A9
WO2002021298A9 PCT/US2001/028091 US0128091W WO0221298A9 WO 2002021298 A9 WO2002021298 A9 WO 2002021298A9 US 0128091 W US0128091 W US 0128091W WO 0221298 A9 WO0221298 A9 WO 0221298A9
Authority
WO
WIPO (PCT)
Prior art keywords
virtual representation
command
generating
template
component
Prior art date
Application number
PCT/US2001/028091
Other languages
English (en)
Other versions
WO2002021298A1 (fr
Inventor
Babak Rezvani
Jack Chen
Original Assignee
Xanboo Inc
Babak Rezvani
Jack Chen
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US09/887,982 external-priority patent/US7555528B2/en
Application filed by Xanboo Inc, Babak Rezvani, Jack Chen filed Critical Xanboo Inc
Priority to CA002421530A priority Critical patent/CA2421530A1/fr
Priority to EP01968660A priority patent/EP1328868A4/fr
Priority to AU2001288894A priority patent/AU2001288894A1/en
Publication of WO2002021298A1 publication Critical patent/WO2002021298A1/fr
Publication of WO2002021298A9 publication Critical patent/WO2002021298A9/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0233—Object-oriented techniques, for representation of network management data, e.g. common object request broker architecture [CORBA]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/02—Standardisation; Integration
    • H04L41/0246—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols
    • H04L41/0253—Exchanging or transporting network management information using the Internet; Embedding network management web servers in network elements; Web-services-based protocols using browsers or web-pages for accessing management information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/08—Protocols specially adapted for terminal emulation, e.g. Telnet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/53—Network services using third party service providers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/535—Tracking the activity of the user
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/75—Indicating network or usage conditions on the user display
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/131—Protocols for games, networked simulations or virtual reality
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Definitions

  • This invention relates to systems and methods for virtually representing devices at remote sites.
  • software applications exist that allow users to directly control devices using on-screen representations of the devices.
  • users In one common application for personal computers for example, users directly control a compact disc (CD) player to play, stop, rewind and fast-forward CDs using a graphical representation of the controls of a CD-ROM player. It may be desirable, however, to control a device from a remote location. Accordingly, a need exists for a system that will allow a device to be controlled by a remote user through a virtual representation of the device.
  • CD compact disc
  • remote devices may be represented by parameters, actions, and indicators.
  • Parameters, actions, and indicators may be text strings that describe or represent various aspects of a remote device.
  • a parameter may be a text string indicating the name, description, type, or manufacturer of a device.
  • An action may be a selectable text string representing one of the various actions that a remote device may take.
  • the text string for an action may be associated with one or more commands for a device, which may be transmitted to the device when a user selects the action.
  • An indicator may be a text string indicating the status of an aspect of a remote device.
  • parameters, actions, and indicators associated with a device may be arranged and presented to a user in any suitable manner.
  • parameters and indicators may be presented to a user as text strings on a web page.
  • Actions may be presented to a user as, for example, selectable links on the web page.
  • a user may command a remote device to perform an action by 'clicking' the desired action link.
  • remote devices may be virtually represented by resources and components.
  • Resources and components may be graphical representations of the physical resources and components of a remote device ("members"), and may be graphically similar to the resources and components that they represent.
  • a template document may be used to specify how resources and components may be arranged and presented to a user.
  • a combination of actions, indicators, resources, or components may be used.
  • a component may be labeled with or contain an indicator.
  • virtual representations of devices may be registered.
  • a web server may generate data to be used in generating a virtual representation of a device from data supplied by a database server. This data may include instructions on how to generate or render a resource or component .
  • FIG. 1 is a block diagram of an illustrative system in accordance with an embodiment of the present invention.
  • FIG. 2 is a diagram showing an illustrative relationship between the database and the web server of FIG. 1 in accordance with an embodiment of the present invention.
  • FIG. 3 is an illustrative block diagram of some of the components of the illustrative system of FIG. 1 in accordance with an embodiment of the present invention.
  • FIG. 4 is an illustrative block diagram of some of the components of the illustrative system of FIG. 1 in accordance with an embodiment of the present invention.
  • FIG. 5 shows an illustrative display screen depicting a virtual representation of a device using parameters, actions, and indicators, in accordance with an embodiment of the present invention.
  • FIG. 6 is a flowchart of illustrative steps involved in the registration and display of a virtual representation of a device in accordance with an embodiment of the present invention.
  • FIG. 7 shows an illustrative display screen depicting a virtual representation of a device using templates, resources, and components, in accordance with an embodiment of the present invention.
  • FIG. 8 is a flowchart of illustrative steps involved in generating a virtual display using a template document in accordance with an embodiment of the present invention.
  • FIG. 9 is a flowchart of illustrative steps involved in the registration and display of a virtual representation of a device in accordance with an embodiment of the present invention.
  • FIG. 10 is a flowchart of illustrative steps involved in associating an installation with a user account during a registration process in accordance with an embodiment of the present invention.
  • FIG. 11 is a block diagram of an illustrative identification information display screen that may be generated by a monitoring module in accordance with an embodiment of the present invention.
  • FIG. 12 is a flowchart of illustrative steps involved in the automatic registration of an installation in accordance with an embodiment of the present invention.
  • FIG..13a is a table of illustrative commands, their parameters, and validity checks in accordance with an embodiment of the present invention.
  • FIG. 13b is an illustrative database schema that may be used in accordance with embodiments of the present invention.
  • FIG. 14a is a flowchart of illustrative steps involved in the registration of parameters, actions, and indicators in accordance with an embodiment of the present invention.
  • FIG. 14b is a flowchart of illustrative steps involved in the registration of components, resources, and templates in accordance with an embodiment of the present invention.
  • FIG. 15a is a flowchart of illustrative steps involved in using handshaking for automatic device detection in accordance with an embodiment of the present invention.
  • FIG. 15b is a flowchart of illustrative steps involved with detecting data streams for automatic device detection in accordance with an embodiment of the present invention.
  • FIG. 16 shows an illustrative registration display screen for a service agreement in accordance with an embodiment of the present invention.
  • FIG. 17 shows an illustrative registration display screen for requesting information from a user in accordance with an embodiment of the present invention.
  • FIG. 18 shows an illustrative registration display screen that displays a listing of event descriptions and the corresponding notifications set up for each even description listing in accordance with an embodiment of the present invention.
  • FIG. 19 shows an illustrative registration display screen for showing user-assigned names for particular devices in accordance with an embodiment of the present invention.
  • FIG. 20 shows an illustrative registration display screen for allowing a user to name an installation being registered in accordance with an embodiment of the present invention.
  • FIG. 21 shows an illustrative registration display screen for instructing the user on how to attach devices to a monitoring module in accordance with an embodiment of the present invention.
  • FIG. 22 shows an illustrative registration display screen for notifying the user of detected devices and to allow the user to rename a device in accordance with an embodiment of the present invention.
  • FIG. 23 shows an illustrative registration display screen that allows the user to provide information communications network being used and to test a connection in accordance with an embodiment of the present invention.
  • FIG. 1 shows an illustrative system 10 in accordance with an embodiment of the present invention.
  • an illustrative client-server Internet based embodiment of the present invention is herein described, but any suitable peer-to-peer or other distributed approach may be used.
  • one computer may have software that enables the computer to act as both a web server and as a database server.
  • System 10 may include an installation 12 and a remote site 14 that may be linked via a communications network 16. In practice, there may be more than one remote site 14 and installation 12, but only one each is shown to avoid overcomplicating the drawing.
  • the term "server” is not limited to a distinct piece of computing hardware or storage hardware, but may also be a software application or a combination of hardware and software.
  • Remote site 14 may be any suitable remote site, and may include various equipment, such as one or more servers, mainframes, personal computers, or any other suitable computer-based equipment.
  • Remote site 14 may include a network of suitable computers that may be interconnected in any suitable way. For example, these computers may be interconnected through a local area network, wide area network, telephone network, cable television network, intranet, Internet, or any other suitable wired or wireless communications network.
  • Communications .network 16 may be any suitable communications network.
  • communications network 16 may be a local area network, wide area network, telephone network, cable television network, intranet, Internet, or any other suitable wired or wireless communications network.
  • Some suitable wireless communications standards that may be used to implement communications network 16 may include global system for mobile communications (GSM) , time-division multiple access (TDMA) , code-division multiple access (CDMA) , Bluetooth, or any other suitable wireless communication standards.
  • GSM global system for mobile communications
  • TDMA time-division multiple access
  • CDMA code-di
  • Installation 12 and remote site 14 may communicate over • communications network 16 using any suitable protocol or protocol stack.
  • installation 12 and remote site 14 may communicate via the Transmission Control Protocol/Internet Protocol (TCP/IP) standard using, for example, IP version 4 or IP version 6 (both of which support 128-bit network addressing) and a hypertext transfer protocol (HTTP) .
  • TCP/IP Transmission Control Protocol/Internet Protocol
  • HTTP hypertext transfer protocol
  • UPN universal plug and play
  • Any suitable request- response type of protocol and socket-based packet transport stack, or suitable peer-to-peer communications approach may be used.
  • Installation 12 and remote site 14 may communicate using any suitable communications. Communications may include, for example, commands, requests, messages, remote procedure calls (e.g., using a proxy-stub pair) , or any other suitable client-server or peer-to-peer communication. Communications may also involve, for example, complex communications between application constructs running on installation 12 and remote site 14. Objects running on the client and server may, for example, communicate using an Object Request Broker (ORB) . Transmitted information may, for example,. be encapsulated as COM objects or Javabeans and persisted to files that are transmitted over a remote access link. In another suitable approach, access communications may include hypertext markup language (HTML) formatted documents (e.g., web pages) that are exchanged between installation 12 and remote site 14 via ISP 23 and communications link 16.
  • HTML hypertext markup language
  • communications may include a series of HTTP posts and responses in which the parameters for the transmissions may be sent as name/value pairs in the normal post method.
  • numbered commands may be parsed out and executed at remote site 14.
  • Remote site 14 may be responsible for parsing the command string into individual commands and executing each of those commands.
  • remote site 14 may utilize a script language and interpreter such as Personal Home Page Tools (PHP) that is embedded within a Web page along with its Hypertext Markup Language (HTML) .
  • PGP Personal Home Page Tools
  • HTML Hypertext Markup Language
  • web server 46 may call PHP to interpret and perform the operations called for.
  • Other similar technologies may also be utilized such as JavaScript, Microsoft's VBScript, or any other applicable script interpreter. If desired, any other suitable client-server or peer-to-peer based approach may be used.
  • Installation 12 may be operated by a local user.
  • Installation 12 may include one or more nodes.
  • FIG. 1 illustrates an approach having two nodes, first user node 18 and second user node 20. It should be understood, however, that any number of nodes may be used.
  • nodes 18 and 20 may be located at a single location, such as the user's main residence. If desired, nodes may be located across more than one location. For example, one node may be in ' a user's main residence and another at the user's vacation house. In embodiments where user accounts are provided, nodes of an installation may be associated with more than one user account.
  • user node 18 may include a client device 22 that may be connected to communications network 16.
  • client device 22 may be connected to the Internet via an Internet service provider (ISP) 23.
  • ISP Internet service provider
  • Client device 22 may be any device suitable for communicating with remote site 14 via communications network 16.
  • client device 22 may be a computer, a personal digital assistant (PDA) , a terminal, a set-top box, or any other suitable device that provides access to remote site 14 via communications network 16.
  • Client device 22 may include, for example, an Internet browser application 26 that may be used to access web pages via communications network 16.
  • client device 22 may run a client application that provides locally generated displays propagated with a format obtained using any suitable client-server or peer-to-peer scheme.
  • Client device 22 may communicate with ISP 23 or directly with communications network 16 using any suitable communications link.
  • the link may include a telephone dial-up link, digital subscriber lines (DSL), a cable modem link (e.g., a data over cable service interface speci ication (DOCSIS) ) , a satellite link, a computer network link (e.g., Ethernet link, Tl line, etc.) or any other suitable communications link or combination of communications links.
  • DSL digital subscriber lines
  • DOCSIS data over cable service interface speci ication
  • Remote site 14 may include one or more servers.
  • remote site 14 may include web server 46 and database server 48.
  • Database server 48 may maintain database 58.
  • remote site 14 may include an application server and any other suitable server or combination of servers.
  • communications between database server 48 and web server 46 may be accomplished using API functions, as shown in FIG. 2.
  • Web server 46 may call a particular API function that causes the database to be accessed. The API may then return a value (in accordance with the specification of the particular function) that is sent to web server 46. This is merely an illustrative way of allowing web server 46 to interact with database server 48. If desired, any other suitable way of allowing the web server to interact with the database may be used.
  • APIs as an interface between database server 48 and web server 46
  • other suitable technologies may be used.
  • Perl scripts, CGI scripts, Cold Fusion, or any other suitable technologies, or combination thereof, may be used to interface database server 48 with web server 46.
  • remote site 14 may provide displays or display definitions to client device 22.
  • web server 46 may generate static and dynamic web pages from data supplied by database server 48.
  • Web page 47 may be viewed by a user using Internet browser 26 running on client device 22.
  • Software applications that interface installation 12 with remote site 14 may be created using any suitable platform and/or software development tools.
  • Java 2 Enterprise Edition, Javabeans, component object model (COM) based technologies e.g., ActiveX, object linking and embedding (OLE), etc.
  • JavaScript JavaScript
  • Visual Basic C, C++
  • scripting languages or any combination of these or other suitable development tools
  • any suitable combination of these or other suitable development tools may be used in preparing other software modules or applications for the various embodiments of the present invention.
  • Remote site 14 may function as the master controller of system 10.
  • users may access system 10 via any computer, monitoring module, or remote user access device linked to communications network 16.
  • Remote user access devices (such as remote user access device 17 in FIG. 1) may include, for example, personal digital assistants, cellular telephones, set-top boxes, personal computers, or any other suitable device a user may use to access remote site 14 via communications network 16.
  • Monitoring modules 28 may serve as an interface between remote site 14 and at least one connected device 32. Monitoring modules 28 may be any suitable hardware, software, or a combination thereof and may be included at any point within the system. For example, monitoring module 28 may be a software application running on client device 22 or a separate piece of hardware that may be connected to client device 22 (as shown at node 18) or partially implemented as software on client device 22 and a separate piece of hardware. In some embodiments, monitoring module 28 may be a stand-alone appliance (as shown at node 20) connected to communications network 16, operating separately and independently from client device 22. Each monitoring module 28 may be shipped with a model identification code, or with the capacity to generate such a code, that may serve to identify each particular monitoring module's model type.
  • One or more monitoring modules 28 may be installed at one or more locations. Monitoring modules 28 may be installed by the user (or any other suitable person) by, for example, connecting the modules to client device 22, and may communicate with remote site 14 over communications network 16.
  • the connection between the monitoring module 28 and the client access device and between devices and the monitoring module may be in the form of a universal serial bus (USB) connection, parallel port connection, serial connection (e.g., RS-232), Firewire connection, any combination of these, or any other suitable type of connection.
  • monitoring modules 28 may be given the capability (e.g., processing hardware, communications equipment, etc.) to communicate, via communications network 16, without the use of a client access device.
  • Monitoring modules 28 may link attached devices or appliances (e.g., sensors, cameras, microwaves, refrigerators, etc.) with remote site 14 via communications network 16.
  • One or more monitoring modules 28 may provide data from attached devices and appliances to remote site 14 via communications network 16.
  • the term "device,” as defined herein, shall include any suitable device or appliance.
  • At least one device 32 may be interfaced with and controlled by each monitoring module 28. Connections between monitoring module 28 and the various devices 32 may be hardwired or wireless (e.g., using Bluetooth technology).
  • Devices 32 may encompass any suitable device capable of being controlled or mediated by an external controller. Such devices may include, but are not limited to, a camera 34, a radio 36, a smoke or fire detector 38, a contact sensor 40, and a light switch 41. Although not illustrated, other suitable devices may include, for example, various audio input and output devices, infrared devices and sensors, various visual displays, washers/driers, microwave ovens, cooking ranges, car alarms, plant watering devices, sprinklers, thermostats, carbon monoxide sensors, humidity sensors, water emersion sensors, radon sensors, temperature sensors, audio sensors, radiation sensors, rain gauges, video cassette recorders, radio tuners, or any other suitable device and the like.
  • One or more notification devices may also be incorporated into the system. As illustrated in FIG. 1, pager 43 is communicating wirelessly with a wireless or cellular transmitter 44 associated with remote site 14.
  • Other suitable notification devices include, for example, e-mail clients, wireless hand-held computers, wireless wearable computer units, automatic web notification via dynamic web content, telephone clients, voice mail clients, cellular telephones, instant messaging clients, and the like. Notification devices may receive notification of events within the system and indicate such events to the user.
  • System 10 provides users with opportunities to remotely control and monitor devices 32 using remote user access devices 17 via communications network 16. In the example of FIG. 1, users may control devices 32 that are interfaced with monitoring modules 28 at node 18 and devices 32 interfaced with monitoring module 28 at node 20.
  • any suitable system architecture and communications network 16 may be used to allow users, or anyone that users permit, to readily monitor and control monitoring modules 28 from any location using any suitable device that is capable of communicating with remote site 14 via communications network 16.
  • users may access installation 12 using remote user access devices 17 without the use of remote site 14.
  • remote user access devices 17 may be used to communicate with monitoring modules 28 of installation 12 via communication network 16 and ISP 23. If desired, two-way communications may be implemented using this approach.
  • Remote user access device 17 may access installation 12 using, for example, special IP addresses assigned to a particular monitoring module, node, installation, or any other suitable element of the installation. The use of IP addresses is merely illustrative. Any other suitable addressing or other communications protocol may be used to allow access to an installation from a remote used access device.
  • Devices 32 may be programmed at the installation with respect to how they respond to certain events. Alternatively, devices 32 may be programmed from a remote location using remote user access device 17, for example. The programming may be stored in devices 32, monitoring modules 28, or at remote site 14. Referring now to FIG. 3, monitoring module 28 may serve, for example, as a common connection point for one or more devices 32 at an installation 12 and as the interface between devices 32 and remote site 14 via communications network 16. Monitoring module 28 may, for example, serve as a translation and brokering agent between remote site 14 and devices 32.
  • monitoring module 28 may be software made up of multiple dynamically loaded objects, or device descriptors 49, that may allow remote site 14 to interface with the devices 32.
  • the dynamically loaded device descriptors 49 may act as device drivers for devices 32, translating, in both directions, monitoring, command, and control data (i.e., via monitoring module 28) exchanged between devices 32 and remote site 14 via communications network 16.
  • Each device descriptor 49 may also translate the signals received from monitoring module 28 into the specific electrical signals that are required to communicate with (both input and output) and control its associated device 32.
  • Device descriptor 49 may be provided for each specific device 32 when, for example, different devices 32 have different interfaces and require specific sets of electrical signals for their monitor and control.
  • Device descriptors 49 may include, for example, a manufacturer identification, product identification, and driver version number to allow a device to be referenced correctly. Once a new device 32 has been detected and is to be integrated into the system, monitoring module 28 may reference, download, and run the appropriate drivers for the new device .
  • monitoring module 28 may communicate with remote site 14 to determine whether the new device 32 has been previously catalogued. Monitoring module 28 may, for example, determine if a general description and a default state of device 32 exists at the remote site. When a device 32 has been catalogued, then, for example, the default state and general parameters of device 32 may be stored at remote site 14. A catalogued device 32 may eliminate the need to resend the general parameters and default state and monitoring module 28 may just communicate the instance-specific parameters. When a device 32 is not already catalogued, device 32 may communicate its default state and static parameters to monitoring module 28 that may, in turn, communicate the default state and static parameters to remote site 14. The communication from monitoring module 28 to remote site 14 may be done using name/value pairs using, for example, the normal HTTP post method discussed hereinbefore. For example, a template document may be a static parameter of device 32. Template documents are discussed in detail below.
  • monitoring module 28 may persist the state of devices 32. This may be done, for example, to allow the real-time states of devices 32 to be stored, to communicate to remote site 14, or to allow for easy recovery from a system crash.
  • the stored state of devices 32 may be used, for example, to maintain a synchronized relationship between an . installation 12 and remote site 14.
  • remote site 14 and installation 12 may use polling and heartbeat mechanisms in order to synchronize state information between remote site 14 and installation 12.
  • Polling may refer to a process whereby monitoring module 28 obtains commands from remote site 14.
  • the commands may reside, for example, in command queue 51. Commands may be accumulated at command queue 51 as a result of any suitable action by the user, by remote site 14, or by both.
  • a user may use a remote user access device to issue a command or a request to remote site 14 to cause a change in state of one of devices 32 (e.g., to turn a lamp on) .
  • Remote site 14 may post the change in state command to a command queue 51.
  • Monitoring module 28 may communicate a request for pending commands to remote site 14. This request may, for example, be communicated periodically as part of the polling process.
  • remote site 14 may provide one or more pending commands from command queue 51, and may notify monitoring module 28 of the number of remaining pending commands in command queue 51. Monitoring module 28 may then communicate another request for pending commands. Remote site 14 may return more of the pending commands from command queue 51. This process may continue until command queue 51 at remote site 14 is empty.
  • Remote site 14 may provide commands to monitoring module 28 using any suitable algorithm. For example, remote site 14 may return commands using first-come, first-serve, round robin, first-in, first- out, weighted prioritization, or any other suitable algorithm. Remote site 14 may also proactively inform monitoring module 28 that commands are waiting in queue 51. Monitoring module 28 may then poll remote site 14 and retrieve commands from remote site 14 until the queue is empty.
  • Commands issued on remote site 14' can be generated by the user while the user is logged on to web page ' 47 provided by remote site 14. If a user is not logged onto web page 47 then fewer commands are being issued and thus the need to poll remote site 14 is low. Therefore, the frequency of polls may decrease.
  • a poll frequency setting process may monitor the usage patterns of a user and set a suitable frequency based on the user's pattern of command generation. For example, the user may not often be logged on to web page 47 at remote site 14 from the hours of 2 AM to 7 AM because the user is sleeping. Therefore, the smart frequency setting process may detect this pattern and automatically decrease the poll frequency at 2 AM and increase it again at 7 AM.
  • monitoring module 28 may use heartbeat process 52 to update device state information at remote site 14.
  • a heartbeat may be a periodic communication from monitoring module 28 to remote site 14 containing updated state information for devices 32 associated with monitoring module 28.
  • monitoring module 28 may send a communication to remote site 14 in response to a change in state of a device 32, a synchronization of a device 32 with remote site 14, a triggered alert event, or in response to any other suitable event.
  • all data intended to be transmitted to remote site 14 may be transmitted to remote site 14 via communications network 16.
  • Remote site 14 may transmit an acknowledgment of receipt and successful processing of the data back to monitoring module 28.
  • Remote site 14 may direct monitoring module 28 to make changes in its own state by, for example, posting commands to data store 51. For example, remote site 14 may post commands that set or modify the polling 50 or heartbeat 52 time intervals. Upon reaching the end of the current polling interval, monitoring module 28 may send a communication to remote site 14, requesting any queued commands. Monitoring module 28 may continue to poll, using any suitable communication scheme, until the queue of commands waiting for monitoring module 28 is empty. Each command received from the queue may be acted upon when the command is received and any associated state changes are effected. Remote site 14 may transmit an acknowledgment of receipt and successful processing of the data back to monitoring module 28.
  • remote site 14 may send unsolicited communications to monitoring module 28.
  • Remote site 14 may send communications to, for example, set or update the heartbeat or polling time, or to cause monitoring module 28 to issue a command to update a component of a device.
  • Remote site 14 may send unsolicited communications to monitoring module 28 for any other suitable purpose.
  • monitoring module 28 may manage network level activities 56. These activities may include, but are not limited to verifying passwords, dialing up an ISP, if necessary, periodically uploading accounting/billing information, and performing security measures. Any other suitable network level activities may be performed by monitoring module 28. Monitoring modules may register themselves, devices, or installations with remote site 14. Illustrative systems and methods for auto-registering devices with remote sites are described, for example, in Rezvani et al . United States patent application Serial No. 09/709,688, filed November 10, 2000, which is hereby incorporated by reference herein in its entirety.
  • contact sensor 40 of FIG. 1 may be associated with the front door (not shown) of a remote location associated with second node 20.
  • Contact sensor 40 may be configured to trip whenever the front door is opened.
  • Camera 34 may be positioned to view the front door location and may be programmed to take a digital picture whenever the sensor contact 40 is tripped. This picture may be transmitted over communications network 16 and stored in database server 48.
  • an event notification or alarm trigger may be transmitted by monitoring module 28 to database server 48.
  • Database server 48 may have been previously programmed to transmit a notification event to the user's pager, for example, via cellular transmitter 44.
  • camera 34 may take a picture of the front door and may transmit that picture, via monitoring module 28 and communications network 16, to database server 48.
  • the user having been notified via pager 42, may now access the picture using web server 46 of remote site 14 via Internet browser 26. In this way, the user may determine who has entered the front door of his or her home.
  • system 10 may allow a user located at one node 18 to control a device at a second node 20.
  • the user may contact web server 46 via, for example, Internet browser 26 of node 18 in order to access a database entry for light switch 41 of node 20.
  • a virtual representation of the light switch 41 may be made available to the user by web server 46 and may be manipulated by the user to remotely change the state of light switch 41 and the connected lamp 42.
  • the system may allow the user to change the state of lamp 42 from being "off” to being "on” by, for example, manipulating the virtual light switch from web server 46 and a corresponding command would be placed in a queue of waiting commands on the server component .
  • the controlling module or monitoring module 28 may poll remote site 14 looking for pending commands, such as the change state command of light switch 41. Thereafter, the command may be transmitted to monitoring module 28 that would instruct the light switch to change from the "off" state to the "on” state, thus turning on lamp 46.
  • a feedback mechanism may be used to indicate to the remote site 14 whether the command was executed. For example, the change in state of lamp 46 may be viewed by an appropriately positioned camera, such as camera 34, which would be used to visually monitor the remote location 20 to determine whether the command had been completed successfully. If the command had not been successfully completed, then an error message may be communicated to the user, using for example, the means specified by the user's notification preferences or through any other suitable means of communicating information to the user.
  • FIG. 4 further illustrates the relationship between devices, monitoring modules, and remote database server 48.
  • FIG. 4 shows five devices, 32, 32a, 32b, 32c, 32d. In practice, there may be any number of devices with each installation. Each device may be interfaced to a monitoring module 28 via a device descriptor or driver 49 (for clarity, only one is shown) . Each device may also be represented by a customizable user interface 58 that may be viewable on a remote user access device over communications network 16. Interfaces 58 may include virtual representations of the actual physical user interface of a device. In some embodiments, virtual representations may be stored on web server 46. Remote site 14 may use changes in the state of a device to change the virtual representations of the devices with which the changed states are associated.
  • a virtual representation of a device may be either a text-based, symbol-based, or image-based representation of an actual device 32.
  • the corresponding virtual representation may include a text string that states "light on”, or it may be an icon that may be either green or red. If the icon is green, that may denote that the actual light switch is in the "on” position. If the icon is red, that may denote that the light switch is in the "off" position.
  • a virtual representation of the light switch may change from indicating an "on” state to an "off” state (i.e., the text string may state “light off” or the icon may change from being green to red.)
  • a virtual representation may be a combination of text and ' graphics .
  • virtual representations may be textual representations of devices. An example of such a virtual representation is shown in FIG. 5.
  • the textual representations may include parameters, actions, and indicators.
  • Parameters, actions, and indicators may be text strings that describe or represent various aspects of a remote device. Parameters may include any suitable information regarding a device.
  • parameters for a device may include the name, description, type, or the manufacturer of the device 32.
  • the device 32 may be a camera.
  • the parameters 2320 for the camera may include the camera's name, description, type, and manufacturer name .
  • Actions may include any suitable action that a device 32 may take, or any suitable commands that may be transmitted to a device.
  • an action may be a selectable text string on a web page representing one of the various actions that a device may take.
  • Actions 2300 for a camera may include, for example, "increase brightness,” “decrease brightness,” “pan left,” “pan right,” “turn on,” “turn off,” “turn on microphone,” and “turn off microphone.”
  • a user may command the camera to turn up the brightness by selecting an appropriate link on a web page, which may read "turn up brightness”.
  • the command associated with a particular action link may be different from the description of the action link that is displayed on the generated web page.
  • an action link that is displayed as "turn on camera” may correspond to a command to check to see if the camera is on, and a conditional command to turn on the camera if it is off.
  • Indicators may provide information regarding particular feedback from a corresponding device 32 that may be displayed to a user.
  • indicators may include, for example, a name and a value.
  • the name may indicate the label of the indicator to be displayed to a user and the value may indicate the state of that indicator .
  • the indicators 2310 for a camera may include, for example, "pan position, " "tilt position, " " "brightness level,” “power status,” "microphone on,” “microphone level, " and "last time motion sensor tripped”.
  • different actions and indicators may be selectively displayed to a user based on specific criteria. These preferences may be set automatically by the user during registration, which is discussed in more detail below. For example, a user may desire to have actions and indicators displayed in English.
  • actions and indicators that are English may be chosen by database server 48, client device 22, or any other suitable retrieval script or program, and displayed.
  • actions and indicators may be displayed in another language, such as Spanish, then Spanish actions and indicators may be chosen by database server 48, client device 22, or any other suitable retrieval script or program, and displayed.
  • actions and indicators may be configured for display on a specific device. For example, one web page may be generated that may be appropriate for a computer using an Internet web browser, and another web page may be generated for a device with a much smaller display, such as a PDA or a WAP enabled cell phone.
  • FIG. 6 depicts a flowchart of general, illustrative steps involved in the use and display of a virtual representation of a device using parameters, actions and indicators in accordance with an embodiment of the xoresent invention.
  • a device 32 may register information regarding its parameters actions, and indicators (step 2000) . Registration may include, for example, those steps of FIG. 14a as discussed below.
  • web server 46 may generate a web page 47 in step 2020 by retrieving the associated record for the device and user from database server 48.
  • the generated web page 47 may indicate actions associated with the device as links on a web page ("action links").
  • the web page 47 generated for the camera may include the action links “increase brightness,” “decrease brightness,” “pan left,” “pan right,” “turn off,” “turn on,” “turn on microphone,” and “turn off microphone”.
  • the web page 47 generated for the camera may also include the indicators for that device. These indicators may be included on the web page as text strings on web page 47.
  • the indicator may also be an audio indicator, such as, for example, a .wav file, or any other suitable audio indicator.
  • the indicator may be a static graphical representation, such as a . gif file, or any other suitable static, graphical representation.
  • a command (or commands) associated with the action link may be transmitted to the device (in the present example, a camera) .
  • the user may select "increase brightness".
  • a command may be stored on the database server 48 in step 2050.
  • the command may then be provided to the device 32 in step 2060, which will in turn execute the command and increase its brightness level in step 2070.
  • the camera device 32 may then generate data indicating that the camera brightness has been increased in step 2080.
  • the data from the indicator may be provided to the database server 48 as, for example, discussed above. Subsequently, this data may be retrieved by web server 46 and used in generating an appropriate indicator on web page 37 in step 2090 as, for example, discussed above.
  • virtual representations may be graphical.
  • the graphical representations may include resources and components.
  • FIG. 7 shows an illustrative display screen depicting a virtual representation of a device using resources and components.
  • a resource may include one or more components (e.g., resource 2400).
  • a component e.g., components 2410
  • the display component may correspond to a "physical" component on device 32 (a "member") .
  • a virtual representation of a device may include only resources, only components, or any suitable combination thereof.
  • components may include actions, parameters or indicators.
  • Display components may represent a variety of different members.
  • display components may represent (or be displayed to a user as) toggle buttons, radio buttons, absolute sliders, proportional sliders, edit fields, labels, images, streaming video, streaming audio, time fields, date fields, edit fields, labels, images, video clips, multiselect list, N- directional components, N-state buttons, N-state selectors (where N may be any suitable integer) , trees, tables, graphs, charts, drawing pads, banners, or any other suitable display components .
  • Display components may act as status indicators. Display components may allow users to toggle settings or otherwise control devices 32. For example toggle buttons may indicate, for example, whether a device is in the "on" position or in the "off" position. Toggle buttons may allow users to change the state of a device, by, for example, turning a device on or off. Sliders may indicate the percentage complete of a particular process a device may be performing (e.g., baking a cake), and may allow users to change the state of a device (e.g., changing oven temperature) . Edit fields may allow users to change textual representations of suitable elements .(e.g., naming a television show to be recorded by the show's name).
  • Video, audio, images, or any other suitable media-based components may indicate what the devices are sensing (e.g., images may be sensed by cameras, streaming video may be sensed by camcorders, audio clips may be sensed by audio recorders, etc.) .
  • Date and time fields may indicate what date and time a VCR is set to start recording. Date and time fields may allow users to set the date and time a VCR may start recording.
  • Multiselect lists may indicate all sound sensors that are detecting noise in the house. Multiselect lists may also be used, for example, to select some of a number of available sensors to turn on.
  • a remote client access device may be provided with appropriate information by a monitoring module for propagation into the user interface. For example, referring back to FIG. 3, the state of a light switch, volume of a speaker, or the actual video from a video camera may be provided by monitoring module 28 to client access device 22 or remote site 14 and indicated in web page 47.
  • users that access a virtual representation of a device may make any suitable changes to the individual components (e.g., that correspond to state changes of the corresponding device) and those changes may be communicated to monitoring module 28.
  • the actual state of components may not be altered in database 58 when the changes are issued by users through, for example, browser 26. Rather, upon monitoring module 28 receiving state changes via, for example, packaged commands from queue 51, the commands may be delivered to an appropriate device descriptor 49.
  • Device descriptor 49 may be responsible for communicating a command to remote site 14 for the purpose of updating database 58 with the respective state changes. The communication from device descriptor 49 may confirm the acceptance of the state changes.
  • Resource 2400 includes a display component 2410 that includes a series of pushbuttons 2411, 2412, 2413, 2414 which a user may use to activate the VCR's play, stop, reverse and fast forward, respectively.
  • Resource 2420 may include pushbuttons 2421, 2422, 2423, and 2424 that a user may use, respectively, to activate up channel and down channel functions and to increase or lower the volume functions of the VCR.
  • the power resource 2430 may include a toggle switch component 2431 that users may use to activate the VCR's power on and power off commands, and an LED indicator 2432 that may indicate the power condition of the VCR.
  • Resources and components may also have additional functionality that is not indicated by the physical interface of a given device.
  • a VCR may not have a button programming regularly scheduled media. This functionality, however, may be represented in the virtual interface using resources or components.
  • display resources or components that represent device 32 may be incorporated to correspond to functionality that may not exist on the device.
  • a button represented on the user interface through web page 47 that "locks" down a VCR, for example, may not correspond to a physical button on the VCR.
  • the unavailable functionality on the VCR may allow the user to remotely access his or her VCR to lock it for the purpose of protection.
  • Such a resource or component may be created in, for example, the device driver in monitoring module 28.
  • templates may be used in creating virtual representations.
  • a template is a layout document that can specify how resources and components may be arranged and displayed to a user in a display (e.g., user's web page 47 at remote site 14). Templates may exist at any suitable point in a given system as either static or dynamic documents. For example, templates may be downloaded from a remote server at registration. The ability to download templates from a remote server (e.g., a device manufacturer's server) may permit a third party (e.g., the manufacturer) to incorporate desired changes and/or new aspects in the device template.
  • a remote server e.g., a device manufacturer's server
  • a third party e.g., the manufacturer
  • Templates incorporating static parameters may exist as a static parameter inside the hardware of device 32, as a static parameter within the driver and setup during registration procedures, may be hard-coded into a remote server, or may be communicated through monitoring module 28 via the device drivers and stored on the user's account. Templates may also be stored on any suitable media and downloaded at registration. For example, a template may be stored on a floppy disk, optical disk, or any other suitable media, and downloaded at registration. Any other suitable approach may be used.
  • a markup language such as SGML, HTML or any other suitable markup language, may be used to generate a template.
  • a template may specify how resources and components may be arranged through the use of place holders .
  • the place holder may be followed with code (e.g., HTML code, JavaScript, etc.) that may include state information of the • particular resource or component, or any other suitable information.
  • code e.g., HTML code, JavaScript, etc.
  • FIG. 8 depicts illustrative steps involved in one embodiment for generating a virtual representation using a template document.
  • a request or other indication is received from remote user access device 17 or client access device 22 that a user wishes to access (i.e., monitor or control) a device 32.
  • one or more templates, resources, or components may be retrieved by database server 48, client access device 22, or any suitable retrieval program or script using any suitable approach (step 2210) .
  • database server 48, client device 22 or any other suitable retrieval program or script may retrieve appropriate templates, resources, or components from its own storage or from another database server (e.g., from the Internet), using URLs or other identifiers of the templates, resources, or components.
  • devices 32 may be programmed with the templates and components or resources and may provide them to client access device 22 or database server 48.
  • the functions necessary to display the display resources and components may be cut and pasted into the template (step 2220) .
  • this may be accomplished by using the retrieved resources or components as inputs into a representation assembly function.
  • the assembly function may then assemble appropriate code that can generate a display resource or component (i.e., "rendering code") into the template.
  • the assembly function may replace the place holders of the template with rendering code.
  • the rendering code may be part of the resource or component.
  • Database server 48, client access device 22, or any other suitable retrieval script or program may retrieve the rendering code from the resource or component, and cut and paste it into the proper place of the template document.
  • the rendering code may be written in any suitable language, such as C, C++, Java, or Perl.
  • the template may be transmitted to a remote access device (step 2230) .
  • the rendering code may be executed, and a display resource or component generated, thus rendering the desired virtual representation.
  • a browser (or any other suitable interface) may be loaded to display the virtual representation of the device.
  • the rendering code may be executed to generate a display resource or component in any suitable manner.
  • the rendering code may be executed as a Java function on the remote user access device. This approach may be suitable when, for example, the use of a cross-platform interpreter (such ' as Java) is desirable or available.
  • the rendering code may be a self-contained executable program encapsulated in the template that, when called, may render the appropriate resource or component. This approach may be may be suitable in instances where, for example, a cross-platform interpreter is either undesirable or unavailable.
  • templates may be available for a device, each including place holders for different resources or components. Each template may be appropriate for different circumstances.
  • the database server 48, client access device 22, or any other retrieval program or script may select an appropriate template, depending on the circumstances. For example, if a virtual representation is to be displayed in English, a template may be chosen by database server 48, client device 22, or any suitable retrieval program or script that includes placeholders for resources and components that have English text. Similarly, if the virtual representation is to be displayed in another language, such as Spanish, then a template may be chosen that includes placeholders for resources and components that have Spanish text.
  • FIG. 9 depicts a flowchart of general, illustrative steps involved in the use and display of a virtual device using components, resources, and templates in accordance with an embodiment of the present invention.
  • Information that may be registered regarding a resource or component may include general information or specific information, or any other suitable information
  • # General information may include, for example, an identification label for the component, whether the component is editable (i.e., whether it may be manipulated by the user) , or whether the component is active.
  • Specific information may be device specific.
  • the device may be a light.
  • the light device may include a component that is a slider, which may control brightness level, for example.
  • Specific information pertaining to the slider that may be registered by the device 32 may include the high range of the slider, the low range of the slider, the increment that the slider should move when dragged
  • a device 32 may be a camera.
  • the camera device may include a directional component for controlling the pan and tilt of the camera lens, a first slider component for controlling recording volume, a second slider component for controlling the tilt of the camera, and a button component for turning the camera's power on and off.
  • the components, resources, and templates associated with a device may be registered in database 48 during the registration of the device 32.
  • Registration may include, for example, those steps as discussed below in FIG. 14b.
  • a device may be capable of registering information about itself. Accordingly, in step 2100, the device may register information regarding its components, templates, and resources.
  • the processes and protocols used to register components may be different than the processes and protocols used for the registration of parameters, actions, and indicators.
  • camera device 32 may register general information for each component.
  • the camera device may also register specific information for each component.
  • this may include the minimum value of the horizontal pan; the maximum value of the horizontal pan; the minimum value for the vertical pan; the maximum value for the vertical pan; the horizontal increment that the pan component should move when selected; the vertical increment that the component should move when selected; the normal, or "home” value of the horizontal pan; and the normal or "home” value of the vertical pan.
  • Special information for the first and second sliders may include orientation (e.g., horizontal or vertical), the maximum range of the slider, the minimum range of the slider, the increment that the slider should move when selected by a user, a label for the minimum value; and a label for the maximum value.
  • Specification information for the button component may include a state label to indicate the state of the button.
  • a style value may also be registered as part of the special information for a component. The style value may indicate which style of component to display, if multiple varieties are available. Such styles may be pre-defined, user-configurable, or any combination of the two.
  • a request may be made to web server 46 to view a virtual representation of the device 32 in step 2115.
  • web server 46 may retrieve the components of the. device 32 registered by the device 32 with database server 48 in step 2120.
  • the data retrieved by device 32 may also include a template document that was registered by the device 32.
  • the template document may be used to generate a web page displaying the resources and components in the format described by the template document.
  • the display components may be generated in step 2125. Once the display components have been generated, the display components may be displayed on web page 47 in the appropriate layout in step 2130, as determined by the template document. If a user indicates a desire to use a component in step 2135 (e.g., turn on a power button or decrease the brightness of a light) , an appropriate command (or commands) associated with the desired command may be provided to the device.
  • a desire to use a component in step 2135 e.g., turn on a power button or decrease the brightness of a light
  • the device is a camera and a user desires to increase the brightness
  • the user may select the appropriate component (e.g., a slider) and execute the appropriate action (e.g., moving the slider by, for example, selecting it with a user ' input device (e.g., a mouse), and moving the slider in increasing increments) .
  • the command may be stored on the database server 48 in step 2150.
  • the command may then be provided to camera device 32 in step 2160. This may be accomplished by, for example, packaging the changed resource or component as a command or other communication.
  • queue 51 When a user remotely controls a device 32, the commands may be entered into, for example, queue 51 of FIG. 3.
  • queue 51 may be, for example, an advanced queue that operates as specialized memory and a separate dequeue process may manage retrieving commands from the queue in a non-first-in- first-out (non-FIFO) process for different devices, but in a FIFO process for commands for the same device.
  • non-FIFO non-first-in- first-out
  • multiple queues may be used for different devices, different users, or using any other suitable approach.
  • Web page 47 (or other display) may indicate that a state change has been submitted and in the process of being executed. Subsequently, the device may in turn execute the command and increase its brightness level in step 2170.
  • the camera device 32 may then generate data indicating that the camera brightness has been increased in step 2180. Subsequently, this data may be retrieved by web server 46 in step 2190 and used to indicate that the brightness has been increased. This may be accomplished, for example, by indicating a percentage above the slider indicating the brightness of the camera, by sending an audible chime, by retaining the display of the slider as the user positioned it, or in any other suitable way.
  • a registration process may be used to allow the registration of new users, monitoring modules, or available devices at remote site 14. Using information from the registration process, remote site 14 may provide the registered user with access to the functionalities of the registered monitoring module and registered devices. Users may access the functionalities of the modules and devices via communications network 16.
  • users may be required to create or open an account before installations, monitoring modules, devices, parameters, actions, and indicators, components, virtual representations, or other elements of the system that are associated with a particular user or entity may be registered with remote site 14. Subsequent access to the registered installations may be granted only to the user account holder or to those that the user account holder has permitted access.
  • the user or users of installation 12 may open an account with remote site 14 by accessing web server 46 of remote site 14 via, for example, web browser 26.
  • accounts may be opened using any other suitable approach, such as, for example, using a telephone, or mailing in a physical contract.
  • Information provided for the purposes of opening an account with remote site 14 may be stored in database server 48.
  • FIG. 10 is a flowchart of illustrative steps involved in associating registered installations (and the registered elements making up the registered installations) with a particular user account.
  • a user account is created. Registration of the user's installations takes place at step 308.
  • Step 308 may include steps 309 and 311.
  • appropriate database entries may be made in database 58 that catalog the elements to be registered (which may effectively serve to register the elements at remote site 14) .
  • remote site 14 associates the registered elements with their corresponding user account. This may be done using any suitable cross- referencing technique. For example, in a relational database, a separate table may list all installations in one field and the corresponding user accounts in another field. Another table may list all installations in one field (that may act as a key field to the first table) and all associated elements in another field. This is merely an illustrative relational database structure for cross-referencing installations and their elements with corresponding user accounts. Any other suitable database construct may be used.
  • Monitoring modules 28 may also register with remote site 14. Information regarding monitoring modules 28, such as model identification, attached devices, etc. may also be stored in database server 48. Once a monitoring module is registered, it may register its attached devices with remote site 14. Information associated with devices, such as device names, may be stored in database server 48 and made available to the user. Each device 32 may communicate with monitoring modules 28 and export its customized interface to database server 48. If the interface is not customized, a default interface may be used.
  • the registration process of some embodiments of the present invention may require user interaction locally, remotely, or both.
  • the system may prompt users to enter registration information on a web site that is resident on web server 46.
  • the system may, for example, require users to set or adjust system settings using set-up software running locally on user access device 22.
  • the set-up information may subsequently be communicated to remote site 14. Any suitable combination of local and remote registration processes may also be used.
  • the monitoring module may generate a globally unique monitoring module identification and a monitoring module password during the registration process. These are illustrated in FIG. 11. Every monitoring module 28 may have a model identification code, identifying the particular model of the monitoring module. During the registration procedure, or at any other suitable time, the monitoring module may generate a monitoring module identification 116 and a monitoring module password 118. If desired, the monitoring module identification 116 and a monitoring module password 118 may be predetermined and stored in memory in the monitoring module during the manufacturing process. The monitoring module identification may be unique to each particular monitoring module in the whole set of existing monitoring modules. This is merely an illustrative embodiment of the monitoring module, and any other suitable embodiment may be used.
  • Monitoring module 28 and remote site 14 may communicate using a communications protocol.
  • the communications protocol between monitoring module 28 and remote site 14 may consist of a series of predefined messages, message parameters, and return codes.
  • the registration protocol may be a subset of this communications protocol and may be specific to the registration process used to register monitoring modules and devices with remote site 14.
  • Registration protocol messages may be initiated by the monitoring module.
  • the monitoring module may, for example, generate a transaction identification for each message.
  • the transaction identification may be an identifier that is unique within a given time window.
  • Registration protocol messages may include, or be accompanied by, the transaction identification, model identification code, monitoring module identification, and monitoring module password.
  • the registration protocol message may include commands and any required command-specific parameters. If desired, any suitable part of the system other than the monitoring module may initiate the communication of registration protocol messages. For example, the user may manually initiate the registration protocol messages using, for example, client device 22.
  • Remote site 14 may process monitoring module registration messages and return confirmation messages to the monitoring module that initiated or generated the registration messages.
  • the confirmation message may contain the original message's transaction identification, a version identification of the software being used at web server 46, database server 48, or both, and the name or other identification of the command to which the confirmation is responding. If desired, confirmation messages may include any other identification information or other suitable information instead of or in addition to those described.
  • Confirmation messages may also include an acknowledge character (ACK) to indicate remote site 14 processed the message correctly.
  • ACK acknowledge character
  • confirmation message may include a negative-acknowledge character (NAK) code.
  • NAK negative-acknowledge character
  • the confirmation message may also include an error message that may indicate the reason for the NAK code.
  • remote site 14 may have the ability to recognize certain errors, forms of errors, or both. Remote site 14 may also correct the recognized errors. Instead of returning a NAK code in this situation, remote site 14 may return an ACK code with a notification of the detected error and the fact that it was corrected. Alternatively, remote site 14 may only return an ACK code without the acknowledgment that an error was corrected. Any such suitable response may be used.
  • multiple registration protocol or other messages may be sent using only one communication. This may be accomplished using any suitable technique.
  • the messages may be bundled into an extensible markup language (XML) command schema.
  • Remote site 14 may, likewise, respond to the bundled message communication in one XML confirmation schema.
  • remote site 14 may provide individual responses for each command in the original communication.
  • XML extensible markup language
  • FIG. 12 is a flowchart of illustrative steps involved in the registration process in accordance with an embodiment of the present invention. It should be understood that the steps shown in FIG. 12 may be altered in any suitable way. For example, steps may be added, deleted, or performed in any suitable order. FIG. 12 is merely an illustrative embodiment of the registration process. Any suitable modifications may be made in accordance with this embodiment of the present invention.
  • the monitoring module may generate a monitoring module identification, a monitoring module password, a model identification code, and a transaction identification. Registration information from devices 32, coupled to the monitoring module may be extracted. These pieces of information may be included in a registration message that is communicated to remote site 14 by monitoring module 28 at step 102.
  • remote site 14 may check the validity of registration messages, of command (or commands) included in the registration messages, or both.
  • Checking message validity may include, for example, checking whether a message has a transaction identification that is unique within the agreed upon time window; checking whether a message includes a unique monitoring module identification and a monitoring module password; and checking whether a message includes a model identification code. If desired, any other suitable technique may be used in checking message validity.
  • Checking message command validity may include, for example, determining whether a command is one that remote site 14 is able to recognize (i.e., is an actual predefined command); and whether a message includes the correct command parameters for the command used. If desired, any other suitable technique may be used in checking message command validity.
  • remote site 14 may also check for command specific validity. This may involve, among other things, ensuring that any contingent devices have already been registered, checking to make sure a device that is to be registered has not already been registered, and any other suitable validity checks.
  • FIG. 13a shows illustrative commands, corresponding command parameters, and corresponding command validity checks for the registration process. If desired, any other suitable commands may be used. If there are no errors, remote site 14 may register the installation, including the monitoring module, devices, resources, components, virtual representations, and any other suitable elements of the installation. If desired, any of the elements may also be registered separately from other elements. Remote site 14 may also associate the registered elements with the corresponding user account.
  • Registering monitoring modules 28 and devices 32 may include, for example, adding the identified monitoring module, devices, user, or any other suitable information contained in the registration message, to a database at remote site 14.
  • Remote site 14 may then generate a confirmation message that includes, in the case of no errors, an ACK.
  • remote site 14 may return a NAK.
  • the confirmation -message may be transmitted from remote site 14 to the monitoring module.
  • the monitoring module checks the confirmation message. If a NAK is found, then the monitoring module may retransmit the registration message at step 112. If an ACK is found then the registration is deemed to be successful at step 110.
  • Information regarding registered monitoring modules and registered devices may be stored in the database.
  • Remote site 14 may access the database to , retrieve information about the registered monitoring module (or monitoring modules) and registered devices.
  • the system may provide the user with the ability to set preferences for the registered devices, gather information from the registered devices, and control the registered devices.
  • the database may allow for an efficient mechanism by which information about devices may be accessed and provided to the user.
  • An illustrative database schema is shown in FIG. 13b. If desired, any other suitable schema may be used.
  • a number of table entries in the database may be created.
  • the user's personal information, billing information, the monitoring module's unique monitoring module identification, the monitoring module password, and any other suitable data may be stored in the database. Entry of the data into the database may be facilitated by using an appropriate database application program interface (API) , such as, for example, an API with a data- parameter that may create a data cell and store the content of the data parameter in the data cell.
  • API database application program interface
  • the function may return a user identification code or number. This user identification may be used by the system to refer to the user rather than having to use the user's name.
  • the process for adding entries for monitoring modules and devices in the database may be similar to the process for adding entries for users. That is, using APIs, new table entries may be added in the database. When registering new monitoring modules and devices, only a single function may need to be called by web server 46 to create the appropriate table entries in database 58. The appropriate table entries may be created and the appropriate identification codes or numbers may be returned. If desired, any other suitable technique for adding entries for monitoring modules and devices in the database may be used.
  • web server 46 may query the database to determine whether certain entries are already in existence. For example, when registering a. new device, a function may be called by web server 46 that returns a boolean value corresponding to whether or not the device already exists in the database. This querying process may be performed using suitable API's.
  • the registration process may be layered with sub-registration processes for registering users, registering installations associated with their respective users, registering monitoring modules associated with their respective installations (and, in turn, associated with their respective users) , registering devices associated with their respective monitoring modules, registering resources associated with their respective devices, registering components associated with their respective resources, and registering virtual representations which are made up of components to provide a virtual device.
  • the registration process for each of these layers may include registration information being sent from the monitoring module to the remote site, including suitable registration commands and parameters (e.g., addComponent (Resource, monitoringModule, componentType, etc.)). Registration messages for the different layers may be generated using a markup language (e.g., HTML).
  • HTML form post commands with name/value pairs may be used in the registration message.
  • web server 46 may process the registration message by parsing the markup language code. Appropriate entries may be made into database 58 at remote site 14 to catalog the registered elements of an installation.
  • Each registered element may be assigned a suitable identification code by remote site 14 that may be used to identify at remote site 14 the element within a particular installation.
  • monitoring module 28 may assign an identification to an element of installation 12 that is unique only to installation 12 or to monitoring module 28.
  • the identification assigned by monitoring module 28 may or may not be made identical to the identification code assigned by remote site 14.
  • the identification code assigned by remote site 14 may be mapped to the identification assigned by monitoring module 28 (e.g., using appropriate database constructs) .
  • remote site 14 may look up the mapped identification assigned by monitoring module 28 and communicate using that identification. In the case where the remote site 14 and monitoring module 28 use the same identification, the identification assigned by remote site 14 may be returned to monitoring module 28.
  • Monitoring module 28 may use the identification in subsequent communications with remote site 14 when referring to the element of installation 12 with which identification is associated.
  • the parameters, actions, indicators, resources, components, templates, or a combination thereof, associated with a device 32 may be registered by the device 32 in database server 48 during the registration of the device 32.
  • web server 46 may generate a predefined virtual representation from data supplied by database server 48, without- knowledge of particular parameters, actions, indicators, resources, components or templates.
  • the database server 48 may include code that stores and retrieves parameters, actions, indicators, resources, components or templates associated with a device, without knowledge of such information. This may provide greater flexibility and manageability of the web server, since it need not be updated to include code to process newly developed devices with new parameters, actions, indicators, resources, components or templates. For example, if a new device is to be registered, such as a garage door opener, it may not be necessary to generate code for the database server 48 to process all of the parameters, actions, indicators, resources, components and templates for that device.
  • the parameters, actions, and indicators associated with a device may be included with registration information and registered with database server 48.
  • FIG. 14a depicts illustrative steps involved in registering the parameters, actions, and indicators associated with a device.
  • Parameters, actions, and indicators associated with a device may, for example, be stored on the device itself. Accordingly, in step 2001, these parameters, actions, and indicators may be transmitted from the device to a database server. Alternatively, an Internet address may be stored on the device where the parameters, actions, and indicators may be retrieved. Accordingly, in step 2002, this Internet address (or Internet addresses) may be transmitted from the device to a database server. In step 2003, the parameters, actions, and indicators located at that Internet address may be downloaded to the database server.
  • parameters, actions, and indicators may be supplied by a client access device.
  • the parameters, actions, and indicators may have been supplied to the client access device by any appropriate means.
  • the parameters, actions, and indicators may be downloaded by the client access device from a remote device, may be read from a floppy disk, a CD-ROM, DVD- ROM, or any other appropriate storage device. Accordingly, in step 2004, the parameters, actions, and indicators may be transmitted from the client access device to the database server.
  • FIG. 14b shows illustrative steps that may be involved in registering the components, resources, and templates associated with a device.
  • Components, resources, and templates associated with a device may, for example, be stored on the device itself.
  • these components, resources, and templates may be transmitted from the device to a database server.
  • an Internet address may be stored on the device where the components, resources, and templates may be retrieved.
  • this Internet address (or. Internet addresses) may be transmitted from the device to a database server.
  • the components, resources, and templates located at that Internet address may be downloaded to the database server.
  • the components, resources, and templates may have been supplied by a client access device.
  • the components, resources, and templates may have been supplied to the client access device by any means desirable.
  • the components, resources, and templates may be downloaded by the client access device from a remote device, may be read from a floppy disk, a CD-ROM, DVD-ROM, or any other appropriate storage devices.
  • the components, resources, and templates may be transmitted from the client access device to the database server.
  • a combination of these approaches may be used.
  • events may be registered at a remote site. An event may be specific to a particular device. For example, "FIRE!!!" may be a unique event to a fire alarm device, whereas "door motion sensor tripped" may be a unique event to a door motion detector device. Any such suitable events may be associated with their respective suitable devices.
  • the monitoring module may automatically (i.e., without any user interaction) detect the presence of the new devices and automatically notify remote site 14 of the presence of the new devices.
  • Remote site 14 may, in turn, add the new devices to the database.
  • the monitoring module may conduct object discovery on a continuous basis. If desired, the object discovery may be conducted on a periodic basis. Once new devices are found, the monitoring module may send a registration message to remote site 14.
  • an installation 12 may be re-registered.
  • the installation may need to be re-registered.
  • Re-registration may be necessary for any suitable reason.
  • the process for re-registration may be substantially similar to the initial registration process for an installation, monitoring modules, resources, components, and virtual representations.
  • remote site 14, remote user access devices 17, or any other suitable remote elements of system 10 may access installation 12 or any of the elements of installation 12 using a special address (e.g., IP address) that is associated with a particular installation 12 or with a particular element of installation 12.
  • the special address may be communicated from the corresponding installation or element of an installation during the registration process .
  • a device may be automatically detected.
  • Automatic detection of devices may be implemented using any suitable software, hardware, or both that may allow devices coupled to a monitoring module to be automatically detected. The approach employed for implementing automatic detection may depend on whether there is one-way communications between devices 32 and monitoring module 28 (i.e., from devices 32 to monitoring module 28) or whether there is two-way communications .
  • monitoring modules may continuously, periodically, or in response to one or more particular events, attempt to handshake with devices. This is illustrated by FIG. 15a.
  • the monitoring module may send a handshake message through all of its interface ports (e.g., USB, parallel, serial, IEEE 1394, infrared, proprietary, and any other suitable wired or wireless based port) in an attempt to reach all devices that may possibly be coupled to the monitoring module (step 200) .
  • the monitoring module may use any suitable algorithm in sending handshake communications to its interface ports. For example, the communications may be sent sequentially, using round robin, weighted fair queuing, or any other suitable algorithm. If a device is coupled to the monitoring module the handshake communication may be sent to the port to which the device was connected
  • the device may respond to the handshake communication (e.g., with another handshake communication) . If a response is received by the monitoring module, then at step 206, the device that communicated the response is detected by the monitoring module. The monitoring module may then request additional information from the detected device (e.g., to use in the registration process) . If no response is received from a particular port, then a device is not detected at that port.
  • the handshake communication e.g., with another handshake communication
  • the handshake may be passed on from one device to another in the chain.
  • Responses from the daisy-chained devices may be returned from one device to the next until the responses reach the monitoring module.
  • a monitoring module may check its ports to determine whether any data streams are coming into the ports. For example, in the case where the device is a video camera, a constant video feed may be communicated from the video camera to the monitoring module. If there is a data stream coming in, then the monitoring module may acknowledge that a device is coupled to that port.
  • FIG. 15b illustrates this method of automatic detection of devices.
  • a device may be coupled to the monitoring module. The device may transmit a data stream at step 210.
  • the monitoring module may check ports for data streams and may detect a data stream (step 214) at the port corresponding to the device.
  • devices may be configured to periodically, continuously, or upon particular events (e.g., power-up, user pressing a button, or any other suitable event) send a message through their respective connection interfaces, identifying themselves.
  • each device may have a user interface such as a button that a user may need to interact with (e.g., pressing the button) in order for the device to be detected.
  • the device may send a communication to its corresponding monitoring module.
  • the communication may be any suitable communication that may allow the monitoring module to detect the device.
  • the communication may include a serial number associated with the device. The serial number may be used by the monitoring module to identify the device in subsequent processes. If desired, this approach may be used with wireless devices (i.e., devices 32 that communicated with monitoring module 28 via a wireless interface such as Bluetooth) , while wired devices may be detected using any other suitable method.
  • the monitoring module may detect whether electrical current is flowing through device ports as a means of detecting devices (in the case of wired devices) .
  • the device may change the state of an interface element (e.g., a connection pin) between a high value and a low value depending on whether power is being sent through the port to the device.
  • an interface element e.g., a connection pin
  • the video camera may be automatically powered by the current from the monitoring module.
  • the flow of current may cause the value of a particular connection pin to change from low to high.
  • the monitoring module may detect the high value of the particular connection pin, thus indicating the presence of a device.
  • the devices and monitoring modules may be configured according to hot- plugging standards (e.g., that make use of IEEE 1394, USB, PCMCIA, or any other interface that accords with hot-plugging standards) . Any such suitable approach may be used.
  • a detected device may communicate a unique string to the monitoring module.
  • the unique string may be used by the monitoring module to detect the device or the unique string may be communicated subsequent to the detection of the device.
  • the unique string may contain a uniform resource identifier (URI), such as, for example, a uniform resource locator (URL) .
  • URI uniform resource identifier
  • the URI may provide a link to a downloadable object, such as, for example, a remote method invocation (RMI), a common object request broker architecture (CORBA) object, a distributed component object model (DCOM) object, a device driver/device descriptor, or any other suitable downloadable object.
  • the downloadable object may be acquired by monitoring module 28 (using, for example, communication network 16) .
  • the downloadable object may be installed at monitoring module 28.
  • the object may be executed and may take responsibility for running the corresponding device, registering parameters, registering events, registering components, or for performing any combination of these or any other suitable functions.
  • FIGs. 16-23 are illustrative displays that the system may provide to the user during the registration process. Although the displays shown in these figures are shown as web pages, it should be understood that the displays need not be limited to being displayed in a web browser or using an Internet- based or client-server based approach. For example, the displays may be generated by web server 46.
  • FIG. 16 shows an illustrative service agreement display that the system may provide as one of the first screens in the registration procedure. When the user agrees to the terms of the service agreement, the system may then prompt the user for personal information as shown in FIG. 17. The system may, for example, prompt the user for a login identifier and password.
  • the system may also provide users with the opportunity to edit preferences for registered devices. For example, the system may provide users with opportunities to set up special notification preferences for particular devices.
  • FIG. 18 shows an illustrative display. The display shows a listing of event descriptions and the corresponding notifications set up for each event description listing. The user may be given the ability to edit the notification action.
  • the system may provide the user with opportunities to set names or identifiers for monitoring modules and/or connected devices.
  • FIG. 19 shows an illustrative display listing devices for a particular installation and the devices' corresponding names and/or descriptions.
  • the system may provide the user with an opportunity to enter names for the monitoring module, the devices, or both, during the registration process. If desired, an entire installation may be given a name chosen by the user.
  • FIG. 20 shows an illustrative display that prompts the user for an installation name.
  • the system may provide displays instructing users how to connect various devices and how to register them with remote site 14.
  • FIG. 21 shows an illustrative display having instructions on how to connect a camera to the monitoring module in order for the camera to be automatically detected and registered with remote site 14.
  • FIG. 22 shows an illustrative display showing which devices have been detected.
  • the registration process may provide users with opportunities to set up or customize the detected devices in any suitable way.
  • the system may allow the user to rename any device, as in the illustrated example, to set parameters for detected devices (e.g., setting a digital camera's resolution, setting default settings for device, etc.), or to customize the devices in any other suitable way.
  • FIG. 23 is an illustrative display that may be displayed for the purpose of requesting this information. Any suitable information may be supplied to remote site 14 during the registration process, including, for example, information regarding client device 22, parameters for devices 32, and information regarding any particular software or hardware component of installation 12. Thus, systems and methods for virtually representing devices at remote sites are provided.
  • One skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration and not of limitation.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Information Transfer Between Computers (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne des systèmes et des procédés pour représenter virtuellement des dispositifs (18, 20) à des emplacements distants (14). Ces procédés peuvent consister à enregistrer des informations associées à un dispositif, à produire une représentation virtuelle du dispositif sur un dispositif d'accès utilisateur distant (17), et à commander le dispositif pour accomplir une action.
PCT/US2001/028091 2000-09-06 2001-09-06 Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants WO2002021298A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
CA002421530A CA2421530A1 (fr) 2000-09-06 2001-09-06 Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants
EP01968660A EP1328868A4 (fr) 2000-09-06 2001-09-06 Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants
AU2001288894A AU2001288894A1 (en) 2000-09-06 2001-09-06 Systems and methods for virtually representing devices at remote sites

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
US23030500P 2000-09-06 2000-09-06
US60/230,305 2000-09-06
US24718300P 2000-11-10 2000-11-10
US60/247,183 2000-11-10
US25033400 2000-11-29
US60/250,334 2000-11-29
US26620701P 2001-02-02 2001-02-02
US60/266,207 2001-02-02
US09/887,982 2001-06-22
US09/887,982 US7555528B2 (en) 2000-09-06 2001-06-22 Systems and methods for virtually representing devices at remote sites

Publications (2)

Publication Number Publication Date
WO2002021298A1 WO2002021298A1 (fr) 2002-03-14
WO2002021298A9 true WO2002021298A9 (fr) 2003-04-03

Family

ID=27539955

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/028091 WO2002021298A1 (fr) 2000-09-06 2001-09-06 Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants

Country Status (3)

Country Link
AU (1) AU2001288894A1 (fr)
CA (1) CA2421530A1 (fr)
WO (1) WO2002021298A1 (fr)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE10317106B4 (de) * 2003-04-14 2006-01-12 Detlev Cherubin Multifunktions-Audio-Video-Daten-Board
FR2969442B1 (fr) * 2010-12-20 2014-10-10 Parkeon Systeme de teleassistance pour le paiement d'une place de stationnement, comprenant un horodateur de stationnement en voirie et un dispositif de teleassistance.

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6212556B1 (en) * 1995-11-13 2001-04-03 Webxchange, Inc. Configurable value-added network (VAN) switching
US6311197B2 (en) * 1996-06-03 2001-10-30 Webtv Networks, Inc. Method for downloading a web page to a client for efficient display on a television screen
US6061738A (en) * 1997-06-27 2000-05-09 D&I Systems, Inc. Method and system for accessing information on a network using message aliasing functions having shadow callback functions
US6236997B1 (en) * 1997-06-23 2001-05-22 Oracle Corporation Apparatus and method for accessing foreign databases in a heterogeneous database system
US6275939B1 (en) * 1998-06-25 2001-08-14 Westcorp Software Systems, Inc. System and method for securely accessing a database from a remote location

Also Published As

Publication number Publication date
CA2421530A1 (fr) 2002-03-14
WO2002021298A1 (fr) 2002-03-14
AU2001288894A1 (en) 2002-03-22

Similar Documents

Publication Publication Date Title
US7555528B2 (en) Systems and methods for virtually representing devices at remote sites
US10284624B2 (en) Functionality inoperable unless node registered at remote site
WO2002021298A9 (fr) Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants
EP1328868A1 (fr) Systemes et procedes pour representer virtuellement des dispositifs a des emplacements distants

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2421530

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 2001968660

Country of ref document: EP

COP Corrected version of pamphlet

Free format text: PAGES 1/27-27/27, DRAWINGS, REPLACED BY NEW PAGES 1/26-26/26; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2001968660

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

DPE2 Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101)