WO2014127075A1 - Controlling devices using cloud services and device-agnostic pipe mechanisms - Google Patents
Controlling devices using cloud services and device-agnostic pipe mechanisms Download PDFInfo
- Publication number
- WO2014127075A1 WO2014127075A1 PCT/US2014/016153 US2014016153W WO2014127075A1 WO 2014127075 A1 WO2014127075 A1 WO 2014127075A1 US 2014016153 W US2014016153 W US 2014016153W WO 2014127075 A1 WO2014127075 A1 WO 2014127075A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- pipe
- pipe mechanism
- target
- service system
- service
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
-
- 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
- H04L67/125—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks involving control of end-device applications over a network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/40—Bus structure
- G06F13/4004—Coupling between buses
- G06F13/4022—Coupling between buses using switching circuits, e.g. switching matrix, connection or expansion network
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/38—Information transfer, e.g. on bus
- G06F13/40—Bus structure
- G06F13/4063—Device-to-bus coupling
- G06F13/4068—Electrical coupling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/01—Input arrangements or combined input and output arrangements for interaction between user and computer
- G06F3/048—Interaction techniques based on graphical user interfaces [GUI]
- G06F3/0484—Interaction techniques based on graphical user interfaces [GUI] for the control of specific functions or operations, e.g. selecting or manipulating an object, an image or a displayed text element, setting a parameter value or selecting a range
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06J—HYBRID COMPUTING ARRANGEMENTS
- G06J3/00—Systems for conjoint operation of complete digital and complete analogue computers
-
- 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/12—Discovery or management of network topologies
-
- 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
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- 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/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering 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/50—Network services
- H04L67/55—Push-based network services
-
- 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
- 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/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q1/00—Details of selecting apparatus or arrangements
- H04Q1/18—Electrical details
- H04Q1/30—Signalling arrangements; Manipulation of signalling currents
- H04Q1/50—Conversion between different kinds of signals
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q2209/00—Arrangements in telecontrol or telemetry systems
- H04Q2209/10—Arrangements in telecontrol or telemetry systems using a centralized architecture
Definitions
- Some device manufacturers have attempted to make their devices more "intelligent" by embedding processing modules into the devices.
- a high-end automobile manufacturer may produce a control system that is driven by one or more processing modules.
- Each processing module may run one or more applications.
- a user may interact with these applications via an on-board display device, such as an LCD display or the like. The user may also program the applications through this manner of interaction.
- Some device manufacturers also provide devices that have the ability to interact with remote functionality.
- a control system of an automobile may couple its processing modules to a remote server.
- Applications running on the control system may exchange data with this remote functionality for various purposes, e.g., to receive maps, media content, etc.
- An environment is described herein that includes a service system that hosts one or more services.
- the services provide logic which controls the operation of a plurality of target devices. This strategy eliminates the need for the target devices to provide local "embedded" intelligence.
- the target devices may be produced as "dumb” equipment which lacks (or has limited reliance on) local control logic.
- the services are coupled to the target devices via respective pipe mechanisms.
- the pipe mechanisms handle the flow of data from the target devices to the service system, and the flow of control instructions from the service system to the target devices.
- the pipe mechanisms are constructed in a device-agnostic manner. This means that any pipe mechanism is capable of interacting with plural types of target devices, without regard to the native functionality provided by the target devices.
- the device-agnostic pipe mechanisms can be supplied to device manufacturers. The device manufacturers can then incorporate the pipe mechanisms into their respective target devices. Alternatively, or in addition, the pipe mechanisms can be supplied to end users of target devices.
- each pipe mechanism may be pre-programmed to interact with the service system, e.g., by storing the address of the service system in its data store.
- Each pipe mechanism may also include functionality that enables it to interact with the service system in a secure manner; for example, the interaction may utilize the Transport Layer Security (TLS) protocol, and/or some other security protocol or mechanism.
- TLS Transport Layer Security
- a user may interact with a service via an application that runs on any user device, such as a smart phone, a tablet device, a personal computer, etc. Through this channel, the user may configure the service to control the user's target device in a desired manner.
- the service system may provide set-up functionality that allows a user to establish a nexus between a user account, a particular target device, and the pipe mechanism associated with the target device.
- control strategies can be manifested in various types of systems, components, methods, computer readable storage media, data structures, articles of manufacture, and so on.
- Fig. 1 shows an illustrative environment in which a service system interacts with a plurality of target devices via a plurality of pipe mechanisms, for the purpose of controlling the target devices.
- Fig. 2 provides a high-level summary of two strategies for providing pipe mechanisms to recipients (device manufacturers and end users, respectively).
- Figs. 3-5 show three different options for coupling a pipe mechanism to a target device.
- Fig. 6 shows one implementation of a pipe mechanism.
- Fig. 7 shows one implementation of computing functionality that can be used to provide the service system, or a user device which interacts with the service system.
- Fig. 8 is a procedure which describes a strategy for controlling target devices using the environment of Fig. 1.
- Fig. 9 is a procedure which describes one way of establishing an association that links a target device, a pipe mechanism, and a user account.
- Fig. 10 is a procedure which describes one way of providing an application to an entity, for use by the entity in interacting with a service.
- Fig. 11 is a procedure which describes one way of handling communication in which data flows from the target devices to the service system.
- Fig. 12 is a procedure which describes one way of handling communication in which a user interacts with the service system.
- Series 100 numbers refer to features originally found in Fig. 1
- series 200 numbers refer to features originally found in Fig. 2
- series 300 numbers refer to features originally found in Fig. 3, and so on.
- Section A describes an illustrative environment for controlling target devices using a service system and device-agnostic pipe mechanisms.
- Section B describes illustrative methods which explain the operation of the functionality of Section A.
- the phrase "configured to” encompasses any way that any kind of physical and tangible functionality can be constructed to perform an identified operation.
- the functionality can be configured to perform an operation using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof.
- logic encompasses any physical and tangible functionality for performing a task.
- each operation illustrated in the flowcharts corresponds to a logic component for performing that operation.
- An operation can be performed using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof.
- a logic component represents an electrical component that is a physical part of the computing system, however implemented.
- FIG. 1 shows an illustrative environment 100 in which a service system 102 interacts with a plurality of target devices 104 (Di, D 2 , .... D n ) via a plurality of respective pipe mechanisms 106 (Pi, P 2 , ... P n ).
- a plurality of users may also interact with the service system 102 using a plurality of user devices 108 (Ui, U 2 , ... U n ) running applications 110 (Ai, A2, . .. An). Users can control the target devices 104 through these channels. For example, a user can interact with an application to program a service hosted by the service system 102.
- the service may then send instructions to a target device that have the effect of controlling the target device.
- the service may also receive data from the target device.
- the devices 104 are referred to as "target" devices to indicate that they represent the target of control, and to distinguish these target devices 104 from the user devices 108.
- Each pipe mechanism serves a control-agnostic role of passing information between a target device and the service system 102.
- the pipe mechanism is said to be control-agnostic because it is not configured to perform any particular control function(s), or to interpret the information that passes through it with respect to any particular control regimen. Rather, it may be used in the context of any type of control regimen.
- each pipe mechanism is constructed in a device-agnostic manner. This means that each pipe mechanism has the capacity to interact with different kinds of target devices 104, irrespective of the native functionality provided by the target devices 104.
- the environment 100 achieves this result by hosting a set of identically- constructed pipe mechanisms 106. That is, in this case, each pipe mechanism has the same hardware and programming as other pipe mechanisms.
- the environment 100 provides different classes of pipe mechanisms 106. Each class may differ from the others by accommodating a different type of communication, such as cellular communication, satellite communication, WiFi communication, communication via hardwired connection, etc.
- the environment 100 offers one or more potential benefits.
- the environment 100 delegates the "intelligence" associated with a control task to the service system 102, rather than each individual target device.
- the environment 100 gives the device manufacturers the freedom to produce target devices 104 that are - to varying degrees - considered "dumb".
- a dumb device refers to a device that lacks processor-implemented intelligence and/or other facets of local-implemented control.
- the environment 100 also allows the device manufacturers to eliminate or reduce input/output mechanisms that are typically used by intelligent devices, e.g., to program and interact with these devices. These aspects, in turn, may reduce the complexity and cost of the manufacturing process.
- the environment 100 provides a uniform and standard framework for controlling different kinds of target devices 104. This aspect, in turn, may benefit device manufacturers and end users alike by reducing the complexity and cost associated with the task of controlling plural target devices 104. For example, the environment 100 frees an end user from the responsibility of learning different control protocols associated with different target devices. The environment 100 also offers the end user a more convenient mechanism for programming each target device (to be described below), compared to interacting with the input/output mechanism associated with the target device itself.
- Fig. 2 shows two strategies that may be used to provide the pipe mechanisms 106 to device manufacturers (in the case of option A) and end users (in the case of option B).
- an entity (or entities) which provide the pipe mechanisms is referred to as a pipe provider 202.
- the pipe provider 202 corresponds to the same entity which provides and administers the service system 102.
- the pipe provider 202 and the entity which hosts the service system 102 are two different respective entities. That is, in this embodiment, a first business enterprise can produce the pipe mechanisms, while a second business enterprise can operate the service system 102.
- the pipe provider 202 can provide the pipe mechanisms 106 to device manufacturers 204.
- the term “device manufacturer” encompasses manufacturers which produce target devices from “scratch” based on raw materials, as well as manufacturers which assemble target devices from smaller pre-constructed components, as well as manufacturers which perform a combination of these activities.
- the device manufacturers 204 may add the pipe mechanisms 106 to the target devices 104 as part of the manufacturing process of the target devices 104.
- the device manufacturers 204 can use different strategies to achieve this result.
- the device manufacturers can embed pipe mechanisms as fixed components of target devices.
- the device manufacturers can add the pipe mechanisms as detachable components of the target devices.
- the device manufacturers offer target devices 104 to end users which include the pipe mechanisms 106 already installed therein.
- the pipe provider 202 can provide the pipe mechanisms 106 to end users 206.
- the end users 206 may then add the pipe mechanisms 106 to the target devices 104.
- the device manufacturers 204 can produce a kind of target device that has a mating slot or other type of interface which accommodates the later attachment of a pipe mechanism.
- An end user may purchase such a target device, and then, optionally, later purchase a pipe mechanism for use in conjunction with the target device.
- the end user may then couple the pipe mechanism to the target device via the interface that is provided by the target device.
- the end user may remove an existing pipe mechanism that is currently coupled to the target device and replace it with an updated or enhanced version of the pipe mechanism.
- the entity which hosts the service system 102 can ask the recipient of a pipe mechanism to agree to the terms of a license agreement in order to use the pipe mechanism.
- the recipient may correspond to a device manufacturer or an end user.
- the host entity can request the recipient to pay a single lump sum in order to use a pipe mechanism. This type of license may be the most appropriate option for a device manufacturer.
- the host entity can request the recipient to pay a periodic fee (e.g., a monthly fee) to use a pipe mechanism.
- the host entity can request the recipient to pay a usage- based fee to use a pipe mechanism.
- the hosting entity can monitor the amount of data that passes through a pipe mechanism (in an upstream and/or downstream direction), and then compute a monthly fee that is based on this amount.
- the hosting entity can allow the recipients to use the pipe mechanisms 106 without payment of a fee.
- the hosting entity may provide advertisements to the end users who visit the service system 102 for any reason, e.g., to obtain new applications, or to configure services.
- the hosting entity can collect advertising fees from the advertisers.
- the hosting entity can use the advertisements to direct online traffic to other products and services which it offers. Still other approaches are possible by which the hosting entity can monetize the use of the pipe mechanisms 106, even if it does not itself manufacture or distribute the pipe mechanisms 106.
- target devices 104 these devices can represent any type of functionality.
- a subset of the target devices 104 may correspond to appliances or other equipment provided in homes.
- Such target devices encompass lighting mechanisms, locks, garage door openers, automated shades, security equipment, heaters, air conditioning units, humidifiers, laundry equipment (dryers, clothes washers, etc.), kitchen equipment (refrigerators, stoves, ovens, fan vents, blenders, coffee makers, etc.), bathroom equipment (hair dryers, electric toothbrushes, shaving equipment, etc.), media equipment (televisions, music-playing equipment, etc.), game-playing equipment, toys, irrigation equipment, pool- related equipment, and so on.
- target devices correspond to equipment provided in a vehicle of any type.
- Other target devices correspond to equipment provided in a business environment of any type, including a warehouse environment, a manufacturing environment, a care-giving environment (e.g., a hospital), a government-related environment of any type, and education-related environment of any type, and so on.
- the target devices 104 can encompass yet other types of equipment for use in any environment.
- the target devices 104 may include "dumb" equipment that lacks local processor-implemented control mechanisms or other facets of local control logic.
- Processor-implemented control mechanisms include, for instance, microprocessors, application-specific integrated circuits, and so on.
- a simple light switch is an example of a dumb device.
- a door lock is another example of a dumb device.
- the target devices 104 may include equipment having some local control logic.
- a security system is an example of a device that may employ some local control logic.
- the service system 102 provides services which supplement the local intelligence of the target devices.
- each pipe mechanism can include a device interface mechanism for interacting with a target device, and a service interface mechanism for interacting with the service system 102.
- Each pipe mechanism may also include a processing module, together with a data store.
- the pipe mechanisms 106 may interact with the service system 102 via any communication mechanism 112, such as a wide area network (e.g., the Internet), a local area network, a point-to-point connection, and so on, or any combination thereof. More specifically, each pipe mechanism can connect to the communication mechanism 112 in different ways. Without limitation, a pipe mechanism can connect to the communication mechanism 112 via wireless link(s) (e.g., cellular communication of any type, WiFi communication, satellite communication, etc.) and/or hardwire link(s) (e.g., a broadband connection of any type, a dial-up modem connection, etc.).
- wireless link(s) e.g., cellular communication of any type, WiFi communication, satellite communication, etc.
- hardwire link(s) e.g., a broadband connection of any type, a dial-up modem connection, etc.
- the user devices 108 may correspond to different types of computing units, including, but not limited to, personal computers, computer work stations, lap top computers, tablet-type computers, personal digital assistant devices, mobile telephones of any type (e.g., smart phones), non-mobile telephones of any type, electronic book reader devices, set-top box devices, game-playing consoles, portable game-playing devices, and so on.
- the applications 110 may correspond to software -implemented logic that can be downloaded from the service system 102 (and/or elsewhere) and stored in data stores provided by the user devices 108. Alternatively, or in addition, the applications 110 may correspond to hardware-implemented logic provided by the user devices 108.
- the user devices 108 may interact with service system 102 via any communication mechanism 114, such as a wide area network (e.g., the Internet), a local area network, a point-to-point connection, and so on, or any combination thereof. More specifically, the user devices 108 can connect to the communication mechanism 114 using any of the techniques described above with respect to the communication mechanism 112. (Note that the communication mechanism 114 may represent the same network as the communication mechanism 112; these mechanisms are shown as distinct in Fig. 1 to merely facilitate illustration and explanation).
- the service system 102 may correspond to any computer functionality that is accessible via the communication mechanisms (112, 114).
- the service system 102 may correspond to one or more servers in conjunction with one or more data stores. That is, colloquially speaking, the service system 102 can be implemented by cloud computing resources that are accessible via the Internet or other wide area network.
- the components of the service system 102 can be provided at a single site, or distributed over plural sites.
- the service system 102 hosts a collection of service modules 116 (Si, S 2 , ... S n ). Each service module, in turn, provides a service that governs the manner in which a class of target devices operates. For example, a first service may provide scheduling logic which turns a type of lighting mechanism on and off at various times during the day. A second service may turn a type of irrigation system on and off at various times during the day. A third service may control a type of oven, e.g., by turning it on and off at certain times of the day, and setting the cooking temperature to a specified value while in its "on" state. Many other examples are possible.
- some services may control target devices by providing binary on/off- type decisions.
- other services may control target devices by setting values within a continuous range of values or within a discrete set of values (as in the above-mentioned oven example).
- Other services may provide yet other types of control instructions to the target devices 104.
- Some services may provide their control without taking into consideration the operational state of the affected target devices. This may be the case, for instance, for services that control simple light switches. Other services may take the state of the target devices into account. For example, consider a service which controls a thermostat. That service may receive a reading from a temperature gauge, which reflects the current temperature within a room. In response to this reading, the service may increase or decrease the temperature, or maintain the temperature at its current value.
- Some services may also receive information from external sources, meaning sources other than the target devices 104.
- a service that controls an irrigation system may receive information from a website that provides weather information. The service can take that information into account when controlling the irrigation system, e.g., by reducing the amount of water that is applied to a lawn when rain is expected on a particular day.
- the service system 102 can also provide one or more interfaces that allow the applications 110 to interact with each service module.
- each interface may be implemented as an application programming interface (API) or the like.
- a user may use an application, running on the user's device, to configure a service in a particular manner. For example, a user can interact with a security application to identify the circumstances in which the user's home security system will generate an alarm. The associated service may then interact with the home security system based on the configuration information provided by the user. As noted above, a user may find that this method of controlling a device is more efficient and user-friendly, compared to directly interacting with local control logic provided by the device itself.
- a first communication flow can handle the exchange of information between the pipe mechanisms 106 and the service modules 116.
- a second communication flow can handle the exchange of information between the user devices 108 and the service modules 116.
- Fig. 1 shows an instance of the first and second communication flows in dashed lines.
- a user uses an application A 2 on a user device U 2 to configure a service Si.
- the service Si sends control instructions to a device D 2 via a pipe P 2 .
- a controlled device interface module (CDIM) 118, a device driver module 120, and a user device interface module (UDIM) 122 implement aspects of the above-described first and second communication flows.
- CDIM controlled device interface module
- UDIM user device interface module
- the CDIM 118 can provide different mechanisms for implementing different message transfer protocols. For instance, consider a first case in which a pipe mechanism interacts with the service system 102 on a continuous-connection basis. The CDIM 118 can accommodate this mode by immediately passing instructions to the pipe mechanism as soon as those instructions are received from the service modules 116, and by immediately passing data to the service modules 116 as soon as that data is received from the pipe mechanism.
- a pipe mechanism interacts with the service system 102 on an intermittent-connection basis.
- the pipe mechanism may connect to the service system 102 every n seconds or minutes, or on an event-driven basis (e.g., when an event occurs that warrants interaction between the pipe mechanism and the service system 102).
- the CDIM 118 can accommodate this type of pipe mechanism using a queuing mechanism to store instructions to be passed to the pipe mechanism. When it comes time to establish a connection with the pipe mechanism, the CDIM 118 can transfer any outstanding instructions that are provided in its queue to the pipe mechanism.
- the CDIM 118 can use a pull-based and/or push-based technique to interact with a pipe mechanism.
- a push-based technique the CDIM 118 initiates transfer of control instructions to the pipe mechanism.
- the CDIM 118 relies on the pipe mechanism to pull the instructions from the service system 102.
- the CDIM 118 relies on the pipe mechanism to push data to the service system 102.
- the CDIM 118 actively pulls data from the pipe mechanism. Still other transfer strategies are possible.
- the device driver module 120 provides driver mechanisms that allow the server modules 116 to control different types of target devices 104. For instance, the device driver module 120 may use a first kind of driver mechanism to convert control instructions into an appropriate form for use in controlling a relatively simple lighting mechanism. The device driver module 120 may use a second kind of driver mechanism to convert control instructions into an appropriate form for use in controlling a more complex and versatile lighting switch, e.g., a lighting switch which incorporates a dimming function in addition to an on-off function. From a high-level perspective, the device driver module 120 allows each service to be constructed in a device-agnostic manner, e.g., without taking into account the particular nature of the native functionality provided by the target devices 104.
- the UDIM 122 allows a user to forward information to the services module 116, and allows the service modules 116 to send information to the user.
- the UDIM 122 can accommodate multiple modes of interconnection in the same manner as the CDIM 118, e.g., by accommodating continuous and intermittent connectivity.
- a system management module 124 controls different aspects of the service system 102.
- the system management module 124 can perform this function based on information stored in a data store 126.
- the system management module 124 can establish an association between a particular target device, its pipe mechanism, and a user account.
- the user account may be associated with a user who owns or is otherwise authorized to control the target device under consideration.
- the system management module 124 can use different protocols to establish the above-described association.
- a user who wishes to register a new target device may access the system management module 124 via a user device, e.g., by logging onto a web site associated with the system management module 124. Through that connection, the user may: (1) identify himself or herself; (2) identify the type of target device that is being registered; and/or (3) identify the pipe mechanism that is coupled to the target device.
- a user may also connect the target device's pipe mechanism to the service system 102. Through that connection, the pipe mechanism can provide additional identifying information to the service system 102 regarding itself and/or the target device.
- the pipe mechanism can transmit one or more identifying codes, a digital certificate and/or other information which helps authenticate the identity of the pipe mechanism and/or the target device.
- the system management module 124 may establish a link that relates the target device, the pipe mechanism, and a user account associated with the user.
- the system management module 124 can store the collected information in the data store 126. The user is thereafter permitted to control his or her target device via the service system 102.
- the pipe mechanism is a permanent part of the new target device.
- a device manufacturer may convey a code associated with the new target device in paperwork that accompanies the sale of the new target device, or by affixing the code to the new target device itself in any manner.
- the pipe mechanism may be an independent component that can be attached to any target device. In this case, the user may provide two codes during the registration process, a first code associated with the pipe mechanism and a second code associated with the target device.
- the system management module 124 may also set up a secure connection with the pipe mechanism using any security mechanism, such as, but not limited to, the Transport Layer Security (TLS) protocol (or the predecessor protocol, Secure Sockets Layer (SSL)).
- TLS Transport Layer Security
- SSL Secure Sockets Layer
- the system management module 124 and the pipe mechanism exchange security information to establish a secure connection. Data and instructions may thereafter be transmitted between the service system 102 and the pipe mechanism in a secure form.
- the service system 102 may provide an application marketplace 128.
- a separate system (not shown) may provide the application marketplace 128.
- the application marketplace 128 offers a collection of applications that provide different control functions associated with different types of target devices. For example, a user who owns a coffee maker may search the application marketplace 128 for an application that is designed to control this kind of device. The user can then download this application and use it to control his or her coffee maker. Some coffee makers may be more complex than others. Hence, the user may seek out an application that is most aptly suited for the kind of coffee maker that he or she owns.
- Figs. 3-6 show three different ways that a pipe mechanism may be coupled to a device.
- a target device 302 includes any native device functionality 304 and a pipe interface mechanism 306.
- the native device functionality 304 represents any functions performed by the target device 302.
- the pipe interface mechanism 306 provides any mechanism by which the native device functionality 304 may interact with a pipe mechanism 308.
- the pipe interface mechanism 306 may correspond to a relay which is connected to various switches provided by the native device functionality 304. The relay, in turn, is controlled by the pipe mechanism 308.
- the target device 302 may already provide the pipe interface mechanism 306 as part of its pre-existing ("legacy") design.
- a device manufacturer may modify its legacy design to provide the pipe interface mechanism 306, so that the target device 302 can successfully interact with the pipe mechanism 308.
- the pipe mechanism 308 and the target device 302 are separate components.
- the pipe mechanism 308 can be detachably connected to the target device 302 at any stage, e.g., during assembly of the target device 302 at a manufacturing site, or at the end user's site.
- the pipe mechanism 308 can couple to the pipe interface mechanism 306 using any connection strategy, generically denoted in Fig. 3 as a connection 310.
- the connection 310 may represent a plug-type outlet that receives a chip-type pipe mechanism.
- the connection 310 may represent a cable-type connection or a wireless connection, and so on.
- Fig. 4 shows a target device 402 having native functionality 404, a pipe interface mechanism 406, and a pipe mechanism 408. These modules may perform the same functions as the same-named components of Fig. 3. But in the case of Fig. 4, the pipe mechanism 408 corresponds to an embedded component of the target device 402, rather than a readily-detachable component that is considered separate from the target device 402. For example, the pipe mechanism 408 may represent a chip that is hardwired to a substrate provided in the target device 402 (such as, in more complex target devices, a printed circuit board, etc.).
- Fig. 5 shows a service-controlled switch 502 that incorporates a pipe mechanism 504, a power switch 506, and a power interface mechanism 508.
- the power switch 506 is coupled to a power source 510, such as an AC wall outlet.
- the power switch 506 receives control instructions from the service system 102. Those instructions cause the power switch 506 to toggle the power on and off.
- the power switch 506 directs power from the power source 510 to the power interface mechanism 508; when in an "off state, the power switch 506 turns off the power to the power interface mechanism 508.
- a separate target device 512 may include any native device functionality 514 and a power interface mechanism 516.
- the power interface mechanism 516 of the target device 512 can be coupled to the power interface mechanism 508 of the service-controlled switch 502.
- the power switch 506 can effectively control the application of power to the target device 512, based on control instructions received by the pipe mechanism 504.
- the service-controlled switch 502 comprises a small unit having a male plug that may be inserted into an AC power outlet.
- the service-controlled switch 502 provides a female plug (associated with the power interface mechanism 508) for mating with a male plug (associated with the power interface mechanism 516) of the target device 512 (or vice versa).
- Fig. 5 is an example of a class of control devices that can control a separate target device in any manner.
- the control device can provide a multi-valued output (either continuous or discrete) based on control instructions received by the pipe mechanism.
- This kind of control device can control any type of target device that accepts a multi-valued input signal, such as a thermostat.
- Fig. 6 shows one implementation of a pipe mechanism 602.
- the pipe mechanism 602 includes a device interface mechanism 604 for interacting with a target device 606, and a service interface mechanism 608 for interacting with the service system 102.
- the device interface mechanism 604 can be implemented in any manner, such as by interface pins provided by a chip, a male or female connection member, a relay, etc.
- the service interface mechanism 608 can likewise be implemented in different ways depending on the manner in which the pipe mechanism 602 is connected to the communication mechanism 112.
- the service interface mechanism 608 can provide cell-based logic for providing cellular communication, WiFi logic for providing WiFi communication, and so on.
- the service interface mechanism 608 can include logic for establishing a hardwired- type connection of any type.
- different classes of pipe mechanisms can be provided that include different types of service interface mechanisms.
- the different types of service interface mechanisms can handle different types of communications (e.g., cellular, WiFi, etc.) and/or different transfer strategies (e.g., continuous, intermittent, etc.).
- a device manufacturer or end user can choose the appropriate class of pipe mechanism for use with a particular type of target device that is to be controlled.
- a single type of pipe mechanism can be provided that offers a multi-mode service interface mechanism 608, where each mode offers a different type of communication and/or a different transfer strategy.
- a device manufacturer or end user can then select the appropriate mode for use with a particular target device to be controlled. For example, a device manufacturer can configure the pipe mechanism to provide intermittent WiFi communication with the service system 102.
- the pipe mechanism 602 can also include a processing module 610 that governs it operation.
- the processing module 610 may correspond to one or more microprocessors and/or hardwired logic circuitry.
- the processing module 610 can include transfer logic which governs the transfer of instructions from the service interface mechanism 608 to the device interface mechanism 604, and the flow of data from the device interface mechanism 604 to the service interface mechanism 608.
- the processing module 610 can also include security logic for establishing a secure connection with the service system 102.
- the processing module 610 remains agnostic as to the meaning of the information that flows through the pipe mechanism 602. That is, in this case, the processing module 610 is not adapted for any particular target device or any particular control function.
- the processing module 610 may perform its tasks based on information stored in a data store 612.
- the data store 612 may store an address 614 associated with the service system 102, such as a URL address. This information allows the pipe mechanism 602 to connect to the service system 102.
- the data store 612 may also store any kind of identification information, such as one or more identification codes, security-related information, certificates, etc.
- the identification information may identify the pipe mechanism 602. And if the pipe mechanism 602 is a fixed component of a target device, the identification information also implicitly identifies the target device.
- the pipe mechanism 602 may append some of this identification information as a header to data that it forwards to the service system 102. This will allow the service system 102 to identify the source of the data.
- the processing module 610 can also receive any identification and/or security-related information from any source, such as the system management module 124, and then store this information in its data store 612.
- the pipe mechanism 602 may optionally incorporate other functions and associated inputs.
- the pipe mechanism 602 can include a "connect" button or the like. An end user can activate this button to instruct the pipe mechanism 602 to connect to the service system 102 via the communication mechanism 112.
- FIG. 7 sets forth illustrative computing functionality 700 that can be used to implement any aspect of any user device, or any aspect of any server provided by the service system 102.
- the computing functionality 700 can include volatile and non-volatile memory, such as RAM 702 and ROM 704, as well as one or more processing devices 706 (e.g., one or more CPUs, and/or one or more GPUs, etc.).
- the computing functionality 700 also optionally includes various media devices 708, such as a hard disk module, an optical disk module, and so forth.
- the computing functionality 700 can perform various operations identified above when the processing device(s) 706 executes instructions that are maintained by memory (e.g., RAM 702, ROM 704, or elsewhere).
- instructions and other information can be stored on any computer readable medium 710, including, but not limited to, static memory storage devices, magnetic storage devices, optical storage devices, and so on.
- the term computer readable medium also encompasses plural storage devices. In many cases, the computer readable medium 710 represents some form of physical and tangible entity.
- the term computer readable medium also encompasses propagated signals, e.g., transmitted or received via physical conduit and/or air or other wireless medium, etc. However, the specific terms "computer readable storage medium” and "computer readable medium device” expressly exclude propagated signals per se, while including all other forms of computer readable media.
- the computing functionality 700 also includes an input/output module 712 for receiving various inputs (via input devices 714), and for providing various outputs (via output devices).
- Illustrative input devices include a keyboard device, a mouse input device, a touchscreen input device, a gesture input device, a voice recognition mechanism, tabletop or wall-projection input mechanisms, and so on.
- One particular output mechanism may include a presentation device 716 and an associated graphical user interface (GUI) 718.
- GUI graphical user interface
- the computing functionality 700 can also include one or more network interfaces 720 for exchanging data with other devices via one or more communication conduits 722.
- One or more communication buses 724 communicatively couple the above-described components together.
- the communication conduit(s) 722 can be implemented in any manner, e.g., by a local area network, a wide area network (e.g., the Internet), etc., or any combination thereof.
- the communication conduit(s) 722 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.
- any of the functions provided by the computing functionality 700 can be performed, at least in part, by one or more hardware logic components.
- the computing functionality can be implemented using one or more of: Field-programmable Gate Arrays (FPGAs); Application-specific Integrated Circuits (ASICs); Application-specific Standard Products (ASSPs); System-on-a-chip systems (SOCs); Complex Programmable Logic Devices (CPLDs), etc.
- Figs. 8-12 show procedures that explain one manner of operation of the environment 100 of Fig. 1. Since the principles underlying the operation of the environment 100 have already been described in Section A, certain operations will be addressed in summary fashion in this section.
- this figure shows an illustrative procedure 800 for providing the environment 100.
- the service system 102 is provided.
- the service system 102 may be implemented as a cloud computing resource, or in some other manner.
- a plurality of device-agnostic pipe mechanisms 106 are provided for use in association with respective target devices 104.
- Fig. 2 sets forth two strategies for accomplishing this task.
- the service system 102 is used to control the target devices 104 via the pipe mechanisms 106.
- the operations of Fig. 8 can be performed by one or more entities. For example, in one representative case, a first entity can perform blocks 802 and 806, while a second entity can perform block 804.
- Fig. 9 shows an illustrative procedure 900 for associating a device and a pipe mechanism with a user.
- the service system 102 can receive a registration request which identifies one or more of: (1) an entity (e.g., a user) which owns or otherwise is authorized to control a target device; (2) the target device; and/or (3) the pipe mechanism associated with the target device.
- a user may perform this task by using a user device to log onto a web site associated with the system management module 124.
- the user may identify himself or herself (e.g., by providing a user ID and password), and then provide a code associated with the pipe mechanism and/or a code associated with the target device.
- the service system 102 may receive a communication from the pipe mechanism under consideration.
- the communication may provide additional identifying information regarding the pipe mechanism and/or the target device.
- the service system 102 can use the information collected in blocks 902 and 904 to establish a nexus between the user, a target device, and the pipe mechanism that is coupled to the target device.
- Fig. 9 shows that block 902 precedes block 904, but block 904 may alternatively follow block 902.
- Fig. 10 shows a procedure 1000 for downloading an application from the service system 102 to a user device.
- the service system 102 receives a request from a user for an application.
- the service system 102 provides the requested application.
- Fig. 11 shows a procedure 1100 for uploading data from a pipe mechanism to the service system 102.
- the service system 102 receives a communication from the pipe mechanism associated with a device. This communication can be received via any transfer protocol, e.g., using a continuous connection protocol or an intermittent queuing protocol.
- the service system 102 processes the communication using an appropriate service module.
- the service system 102 can perform any postprocessing action(s), such as notifying a user of the data that has been received, controlling the target device based on the data, and so on.
- the service system 102 can use any connection protocol to forward instructions to the pipe mechanism, such as a continuous connection protocol or an intermittent connection protocol.
- Fig. 12 shows a procedure 1200 for providing configuration instructions from an entity to the service system 102.
- the service system 102 receives configuration instructions from an entity, such as a user. The user may enter those instructions by interacting with an application running on a user device.
- the service system 102 processes the instructions using an appropriate service module.
- the service system 102 can provide any post-processing action(s), such as by controlling a target device associated with the user, etc.
- the service system 102 can use any connection protocol to forward instructions to the pipe mechanism associated with the target device, such as a continuous connection protocol or an intermittent connection protocol.
- functionality described herein can employ various mechanisms to ensure the privacy of user data maintained by the functionality, if any.
- the functionality can allow a user to expressly opt in to (and then expressly opt out of) the provisions of the functionality.
- the functionality can also provide suitable security mechanisms to ensure the privacy of the user data (such as data-sanitizing mechanisms, encryption mechanisms, password-protection mechanisms, etc.).
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Human Computer Interaction (AREA)
- General Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Computing Systems (AREA)
- Health & Medical Sciences (AREA)
- Mathematical Physics (AREA)
- Automation & Control Theory (AREA)
- Evolutionary Computation (AREA)
- Fuzzy Systems (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Selective Calling Equipment (AREA)
- Computer And Data Communications (AREA)
- Telephonic Communication Services (AREA)
Abstract
An environment is described in which a cloud-implemented service system controls a plurality of target devices via a plurality of respective device-agnostic pipe mechanisms. The target devices themselves may represent "dumb" devices, e.g., lacking local control logic, or providing reduced reliance on local control logic. Users may interact with the service system via applications running on any type of user devices.
Description
CONTROLLING DEVICES USING CLOUD SERVICES AND DEVICE- AGNOSTIC PIPE MECHANISMS
BACKGROUND
[0001] Some device manufacturers have attempted to make their devices more "intelligent" by embedding processing modules into the devices. For example, a high-end automobile manufacturer may produce a control system that is driven by one or more processing modules. Each processing module may run one or more applications. A user may interact with these applications via an on-board display device, such as an LCD display or the like. The user may also program the applications through this manner of interaction.
[0002] Some device manufacturers also provide devices that have the ability to interact with remote functionality. For example, a control system of an automobile may couple its processing modules to a remote server. Applications running on the control system may exchange data with this remote functionality for various purposes, e.g., to receive maps, media content, etc.
[0003] The above control strategies provide consumers with more versatile and complex devices. However, for reasons specified herein, these strategies also have potential drawbacks.
SUMMARY
[0004] An environment is described herein that includes a service system that hosts one or more services. The services provide logic which controls the operation of a plurality of target devices. This strategy eliminates the need for the target devices to provide local "embedded" intelligence. In other words, in one implementation, the target devices may be produced as "dumb" equipment which lacks (or has limited reliance on) local control logic.
[0005] According to one illustrative aspect, the services are coupled to the target devices via respective pipe mechanisms. The pipe mechanisms handle the flow of data from the target devices to the service system, and the flow of control instructions from the service system to the target devices. In one implementation, the pipe mechanisms are constructed in a device-agnostic manner. This means that any pipe mechanism is capable of interacting with plural types of target devices, without regard to the native functionality provided by the target devices.
[0006] According to another illustrative aspect, the device-agnostic pipe mechanisms can be supplied to device manufacturers. The device manufacturers can then incorporate the pipe mechanisms into their respective target devices. Alternatively, or in addition, the pipe mechanisms can be supplied to end users of target devices. The end users may then couple the pipe mechanisms to the target devices in a detachable manner. In one implementation, each pipe mechanism may be pre-programmed to interact with the service system, e.g., by storing the address of the service system in its data store. Each pipe mechanism may also include functionality that enables it to interact with the service system in a secure manner; for example, the interaction may utilize the Transport Layer Security (TLS) protocol, and/or some other security protocol or mechanism.
[0007] According to another illustrative aspect, a user may interact with a service via an application that runs on any user device, such as a smart phone, a tablet device, a personal computer, etc. Through this channel, the user may configure the service to control the user's target device in a desired manner.
[0008] According to another illustrative aspect, the service system may provide set-up functionality that allows a user to establish a nexus between a user account, a particular target device, and the pipe mechanism associated with the target device.
[0009] The above control strategies can be manifested in various types of systems, components, methods, computer readable storage media, data structures, articles of manufacture, and so on.
[0010] This Summary is provided to introduce a selection of concepts in a simplified form; these concepts are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] Fig. 1 shows an illustrative environment in which a service system interacts with a plurality of target devices via a plurality of pipe mechanisms, for the purpose of controlling the target devices.
[0012] Fig. 2 provides a high-level summary of two strategies for providing pipe mechanisms to recipients (device manufacturers and end users, respectively).
[0013] Figs. 3-5 show three different options for coupling a pipe mechanism to a target device.
[0014] Fig. 6 shows one implementation of a pipe mechanism.
[0015] Fig. 7 shows one implementation of computing functionality that can be used to provide the service system, or a user device which interacts with the service system.
[0016] Fig. 8 is a procedure which describes a strategy for controlling target devices using the environment of Fig. 1.
[0017] Fig. 9 is a procedure which describes one way of establishing an association that links a target device, a pipe mechanism, and a user account.
[0018] Fig. 10 is a procedure which describes one way of providing an application to an entity, for use by the entity in interacting with a service.
[0019] Fig. 11 is a procedure which describes one way of handling communication in which data flows from the target devices to the service system.
[0020] Fig. 12 is a procedure which describes one way of handling communication in which a user interacts with the service system.
[0021] The same numbers are used throughout the disclosure and figures to reference like components and features. Series 100 numbers refer to features originally found in Fig. 1, series 200 numbers refer to features originally found in Fig. 2, series 300 numbers refer to features originally found in Fig. 3, and so on.
DETAILED DESCRIPTION
[0022] This disclosure is organized as follows. Section A describes an illustrative environment for controlling target devices using a service system and device-agnostic pipe mechanisms. Section B describes illustrative methods which explain the operation of the functionality of Section A.
[0023] As a preliminary matter, some of the figures describe concepts in the context of one or more structural components, variously referred to as functionality, modules, features, elements, etc. The various components shown in the figures can be implemented in any manner by any physical and tangible mechanisms, for instance, by software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof. In one case, the illustrated separation of various components in the figures into distinct units may reflect the use of corresponding distinct physical and tangible components in an actual implementation. Alternatively, or in addition, any single component illustrated in the figures may be implemented by plural actual physical components. Alternatively, or in addition, the depiction of any two or more separate components in the figures may reflect different functions performed by a single actual physical component. Figs. 1-7, to be described in turn, provide additional details regarding one illustrative physical implementation of the functions shown in the figures.
[0024] Other figures describe the concepts in flowchart form. In this form, certain operations are described as constituting distinct blocks performed in a certain order. Such implementations are illustrative and non-limiting. Certain blocks described herein can be grouped together and performed in a single operation, certain blocks can be broken apart into plural component blocks, and certain blocks can be performed in an order that differs from that which is illustrated herein (including a parallel manner of performing the blocks). The blocks shown in the flowcharts can be implemented in any manner by any physical and tangible mechanisms, for instance, by software, hardware (e.g., chip- implemented logic functionality), firmware, etc., and/or any combination thereof.
[0025] As to terminology, the phrase "configured to" encompasses any way that any kind of physical and tangible functionality can be constructed to perform an identified operation. The functionality can be configured to perform an operation using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof.
[0026] The term "logic" encompasses any physical and tangible functionality for performing a task. For instance, each operation illustrated in the flowcharts corresponds to a logic component for performing that operation. An operation can be performed using, for instance, software, hardware (e.g., chip-implemented logic functionality), firmware, etc., and/or any combination thereof. When implemented by a computing system, a logic component represents an electrical component that is a physical part of the computing system, however implemented.
[0027] The phrase "means for" in the claims, if used, is intended to invoke the provisions of 35 U.S.C. § 112, sixth paragraph. No other language, other than this specific phrase, is intended to invoke the provisions of that portion of the statute.
[0028] The following explanation may identify one or more features as "optional". This type of statement is not to be interpreted as an exhaustive indication of features that may be considered optional; that is, other features can be considered as optional, although not expressly identified in the text. Finally, the terms "exemplary" or "illustrative" refer to one implementation among potentially many implementations.
A. Illustrative Environment
[0029] Fig. 1 shows an illustrative environment 100 in which a service system 102 interacts with a plurality of target devices 104 (Di, D2, .... Dn) via a plurality of respective pipe mechanisms 106 (Pi, P2, ... Pn). A plurality of users may also interact with the service system 102 using a plurality of user devices 108 (Ui, U2, ... Un) running applications 110
(Ai, A2, . .. An). Users can control the target devices 104 through these channels. For example, a user can interact with an application to program a service hosted by the service system 102. Based on that programming, the service may then send instructions to a target device that have the effect of controlling the target device. The service may also receive data from the target device. Generally, the devices 104 are referred to as "target" devices to indicate that they represent the target of control, and to distinguish these target devices 104 from the user devices 108.
[0030] Each pipe mechanism serves a control-agnostic role of passing information between a target device and the service system 102. The pipe mechanism is said to be control-agnostic because it is not configured to perform any particular control function(s), or to interpret the information that passes through it with respect to any particular control regimen. Rather, it may be used in the context of any type of control regimen.
[0031] Moreover, each pipe mechanism is constructed in a device-agnostic manner. This means that each pipe mechanism has the capacity to interact with different kinds of target devices 104, irrespective of the native functionality provided by the target devices 104. In one case, the environment 100 achieves this result by hosting a set of identically- constructed pipe mechanisms 106. That is, in this case, each pipe mechanism has the same hardware and programming as other pipe mechanisms. In another case, the environment 100 provides different classes of pipe mechanisms 106. Each class may differ from the others by accommodating a different type of communication, such as cellular communication, satellite communication, WiFi communication, communication via hardwired connection, etc.
[0032] The environment 100 offers one or more potential benefits. First, the environment 100 delegates the "intelligence" associated with a control task to the service system 102, rather than each individual target device. As a result, the environment 100 gives the device manufacturers the freedom to produce target devices 104 that are - to varying degrees - considered "dumb". A dumb device refers to a device that lacks processor-implemented intelligence and/or other facets of local-implemented control. The environment 100 also allows the device manufacturers to eliminate or reduce input/output mechanisms that are typically used by intelligent devices, e.g., to program and interact with these devices. These aspects, in turn, may reduce the complexity and cost of the manufacturing process.
[0033] Second, the environment 100 provides a uniform and standard framework for controlling different kinds of target devices 104. This aspect, in turn, may benefit device
manufacturers and end users alike by reducing the complexity and cost associated with the task of controlling plural target devices 104. For example, the environment 100 frees an end user from the responsibility of learning different control protocols associated with different target devices. The environment 100 also offers the end user a more convenient mechanism for programming each target device (to be described below), compared to interacting with the input/output mechanism associated with the target device itself.
[0034] The above advantages are cited by way of example, not limitation. Other implementations of the environment 100 may offer additional technical advantages.
[0035] Jumping ahead momentarily in the sequence of figures, consider the high-level conceptual overview provided in Fig. 2. That figure shows two strategies that may be used to provide the pipe mechanisms 106 to device manufacturers (in the case of option A) and end users (in the case of option B). In both options, an entity (or entities) which provide the pipe mechanisms is referred to as a pipe provider 202. In one case, the pipe provider 202 corresponds to the same entity which provides and administers the service system 102. In another case, the pipe provider 202 and the entity which hosts the service system 102 are two different respective entities. That is, in this embodiment, a first business enterprise can produce the pipe mechanisms, while a second business enterprise can operate the service system 102.
[0036] In option A, the pipe provider 202 can provide the pipe mechanisms 106 to device manufacturers 204. (Here, the term "device manufacturer" encompasses manufacturers which produce target devices from "scratch" based on raw materials, as well as manufacturers which assemble target devices from smaller pre-constructed components, as well as manufacturers which perform a combination of these activities.) The device manufacturers 204 may add the pipe mechanisms 106 to the target devices 104 as part of the manufacturing process of the target devices 104. The device manufacturers 204 can use different strategies to achieve this result. In one case, the device manufacturers can embed pipe mechanisms as fixed components of target devices. In another case, the device manufacturers can add the pipe mechanisms as detachable components of the target devices. In either case, the device manufacturers offer target devices 104 to end users which include the pipe mechanisms 106 already installed therein.
[0037] In option B, the pipe provider 202 can provide the pipe mechanisms 106 to end users 206. The end users 206 may then add the pipe mechanisms 106 to the target devices 104. For example, the device manufacturers 204 can produce a kind of target device that has a mating slot or other type of interface which accommodates the later attachment of a
pipe mechanism. An end user may purchase such a target device, and then, optionally, later purchase a pipe mechanism for use in conjunction with the target device. The end user may then couple the pipe mechanism to the target device via the interface that is provided by the target device. Alternatively, the end user may remove an existing pipe mechanism that is currently coupled to the target device and replace it with an updated or enhanced version of the pipe mechanism.
[0038] The two strategies identified above are cited by way of example, not limitation. Still other strategies may be used to supply the pipe mechanisms 106 to entities for use in conjunction with the target devices 104.
[0039] In either of the above cases, the entity which hosts the service system 102 ("the hosting entity") can ask the recipient of a pipe mechanism to agree to the terms of a license agreement in order to use the pipe mechanism. For instance, the recipient may correspond to a device manufacturer or an end user. In one approach, the host entity can request the recipient to pay a single lump sum in order to use a pipe mechanism. This type of license may be the most appropriate option for a device manufacturer. In another case, the host entity can request the recipient to pay a periodic fee (e.g., a monthly fee) to use a pipe mechanism. In another case, the host entity can request the recipient to pay a usage- based fee to use a pipe mechanism. For example, the hosting entity can monitor the amount of data that passes through a pipe mechanism (in an upstream and/or downstream direction), and then compute a monthly fee that is based on this amount.
[0040] In another approach, the hosting entity can allow the recipients to use the pipe mechanisms 106 without payment of a fee. In this case, the hosting entity may provide advertisements to the end users who visit the service system 102 for any reason, e.g., to obtain new applications, or to configure services. The hosting entity can collect advertising fees from the advertisers. In addition, or alternatively, the hosting entity can use the advertisements to direct online traffic to other products and services which it offers. Still other approaches are possible by which the hosting entity can monetize the use of the pipe mechanisms 106, even if it does not itself manufacture or distribute the pipe mechanisms 106.
[0041] Returning to Fig. 1, the components in this figure will now be described in detail. Starting with the target devices 104, these devices can represent any type of functionality. For example, a subset of the target devices 104 may correspond to appliances or other equipment provided in homes. Such target devices encompass lighting mechanisms, locks, garage door openers, automated shades, security equipment, heaters, air conditioning
units, humidifiers, laundry equipment (dryers, clothes washers, etc.), kitchen equipment (refrigerators, stoves, ovens, fan vents, blenders, coffee makers, etc.), bathroom equipment (hair dryers, electric toothbrushes, shaving equipment, etc.), media equipment (televisions, music-playing equipment, etc.), game-playing equipment, toys, irrigation equipment, pool- related equipment, and so on. Other target devices correspond to equipment provided in a vehicle of any type. Other target devices correspond to equipment provided in a business environment of any type, including a warehouse environment, a manufacturing environment, a care-giving environment (e.g., a hospital), a government-related environment of any type, and education-related environment of any type, and so on. The target devices 104 can encompass yet other types of equipment for use in any environment.
[0042] As noted above, in some cases, the target devices 104 may include "dumb" equipment that lacks local processor-implemented control mechanisms or other facets of local control logic. Processor-implemented control mechanisms include, for instance, microprocessors, application-specific integrated circuits, and so on. A simple light switch is an example of a dumb device. A door lock is another example of a dumb device. In other cases, the target devices 104 may include equipment having some local control logic. A security system is an example of a device that may employ some local control logic. In these cases, the service system 102 provides services which supplement the local intelligence of the target devices.
[0043] As will be described in greater detail below in connection with Fig. 4, each pipe mechanism can include a device interface mechanism for interacting with a target device, and a service interface mechanism for interacting with the service system 102. Each pipe mechanism may also include a processing module, together with a data store.
[0044] The pipe mechanisms 106 may interact with the service system 102 via any communication mechanism 112, such as a wide area network (e.g., the Internet), a local area network, a point-to-point connection, and so on, or any combination thereof. More specifically, each pipe mechanism can connect to the communication mechanism 112 in different ways. Without limitation, a pipe mechanism can connect to the communication mechanism 112 via wireless link(s) (e.g., cellular communication of any type, WiFi communication, satellite communication, etc.) and/or hardwire link(s) (e.g., a broadband connection of any type, a dial-up modem connection, etc.).
[0045] The user devices 108 may correspond to different types of computing units, including, but not limited to, personal computers, computer work stations, lap top
computers, tablet-type computers, personal digital assistant devices, mobile telephones of any type (e.g., smart phones), non-mobile telephones of any type, electronic book reader devices, set-top box devices, game-playing consoles, portable game-playing devices, and so on. The applications 110 may correspond to software -implemented logic that can be downloaded from the service system 102 (and/or elsewhere) and stored in data stores provided by the user devices 108. Alternatively, or in addition, the applications 110 may correspond to hardware-implemented logic provided by the user devices 108.
[0046] The user devices 108 may interact with service system 102 via any communication mechanism 114, such as a wide area network (e.g., the Internet), a local area network, a point-to-point connection, and so on, or any combination thereof. More specifically, the user devices 108 can connect to the communication mechanism 114 using any of the techniques described above with respect to the communication mechanism 112. (Note that the communication mechanism 114 may represent the same network as the communication mechanism 112; these mechanisms are shown as distinct in Fig. 1 to merely facilitate illustration and explanation).
[0047] The service system 102 may correspond to any computer functionality that is accessible via the communication mechanisms (112, 114). For example, the service system 102 may correspond to one or more servers in conjunction with one or more data stores. That is, colloquially speaking, the service system 102 can be implemented by cloud computing resources that are accessible via the Internet or other wide area network. The components of the service system 102 can be provided at a single site, or distributed over plural sites.
[0048] The service system 102 hosts a collection of service modules 116 (Si, S2, ... Sn). Each service module, in turn, provides a service that governs the manner in which a class of target devices operates. For example, a first service may provide scheduling logic which turns a type of lighting mechanism on and off at various times during the day. A second service may turn a type of irrigation system on and off at various times during the day. A third service may control a type of oven, e.g., by turning it on and off at certain times of the day, and setting the cooking temperature to a specified value while in its "on" state. Many other examples are possible.
[0049] In general, some services may control target devices by providing binary on/off- type decisions. In addition, or alternatively, other services may control target devices by setting values within a continuous range of values or within a discrete set of values (as in
the above-mentioned oven example). Other services may provide yet other types of control instructions to the target devices 104.
[0050] Some services may provide their control without taking into consideration the operational state of the affected target devices. This may be the case, for instance, for services that control simple light switches. Other services may take the state of the target devices into account. For example, consider a service which controls a thermostat. That service may receive a reading from a temperature gauge, which reflects the current temperature within a room. In response to this reading, the service may increase or decrease the temperature, or maintain the temperature at its current value.
[0051] Some services may also receive information from external sources, meaning sources other than the target devices 104. For example, a service that controls an irrigation system may receive information from a website that provides weather information. The service can take that information into account when controlling the irrigation system, e.g., by reducing the amount of water that is applied to a lawn when rain is expected on a particular day.
[0052] Although not specifically enumerated in the figure, the service system 102 can also provide one or more interfaces that allow the applications 110 to interact with each service module. For example, each interface may be implemented as an application programming interface (API) or the like.
[0053] A user may use an application, running on the user's device, to configure a service in a particular manner. For example, a user can interact with a security application to identify the circumstances in which the user's home security system will generate an alarm. The associated service may then interact with the home security system based on the configuration information provided by the user. As noted above, a user may find that this method of controlling a device is more efficient and user-friendly, compared to directly interacting with local control logic provided by the device itself.
[0054] More specifically, a first communication flow can handle the exchange of information between the pipe mechanisms 106 and the service modules 116. A second communication flow can handle the exchange of information between the user devices 108 and the service modules 116. Fig. 1 shows an instance of the first and second communication flows in dashed lines. In the second communication flow, a user uses an application A2 on a user device U2 to configure a service Si. In the first communication flow, the service Si sends control instructions to a device D2 via a pipe P2. A controlled device interface module (CDIM) 118, a device driver module 120, and a user device
interface module (UDIM) 122 implement aspects of the above-described first and second communication flows.
[0055] More specifically, the CDIM 118 can provide different mechanisms for implementing different message transfer protocols. For instance, consider a first case in which a pipe mechanism interacts with the service system 102 on a continuous-connection basis. The CDIM 118 can accommodate this mode by immediately passing instructions to the pipe mechanism as soon as those instructions are received from the service modules 116, and by immediately passing data to the service modules 116 as soon as that data is received from the pipe mechanism.
[0056] Consider a second case in which a pipe mechanism interacts with the service system 102 on an intermittent-connection basis. For example, the pipe mechanism may connect to the service system 102 every n seconds or minutes, or on an event-driven basis (e.g., when an event occurs that warrants interaction between the pipe mechanism and the service system 102). The CDIM 118 can accommodate this type of pipe mechanism using a queuing mechanism to store instructions to be passed to the pipe mechanism. When it comes time to establish a connection with the pipe mechanism, the CDIM 118 can transfer any outstanding instructions that are provided in its queue to the pipe mechanism.
[0057] The CDIM 118 can use a pull-based and/or push-based technique to interact with a pipe mechanism. In a push-based technique, the CDIM 118 initiates transfer of control instructions to the pipe mechanism. In a pull-based technique, the CDIM 118 relies on the pipe mechanism to pull the instructions from the service system 102. Similarly, in a push- based technique, the CDIM 118 relies on the pipe mechanism to push data to the service system 102. In a pull-based technique, the CDIM 118 actively pulls data from the pipe mechanism. Still other transfer strategies are possible.
[0058] The device driver module 120 provides driver mechanisms that allow the server modules 116 to control different types of target devices 104. For instance, the device driver module 120 may use a first kind of driver mechanism to convert control instructions into an appropriate form for use in controlling a relatively simple lighting mechanism. The device driver module 120 may use a second kind of driver mechanism to convert control instructions into an appropriate form for use in controlling a more complex and versatile lighting switch, e.g., a lighting switch which incorporates a dimming function in addition to an on-off function. From a high-level perspective, the device driver module 120 allows each service to be constructed in a device-agnostic manner, e.g., without taking into account the particular nature of the native functionality provided by the target devices 104.
[0059] The UDIM 122 allows a user to forward information to the services module 116, and allows the service modules 116 to send information to the user. The UDIM 122 can accommodate multiple modes of interconnection in the same manner as the CDIM 118, e.g., by accommodating continuous and intermittent connectivity.
[0060] A system management module 124 controls different aspects of the service system 102. The system management module 124 can perform this function based on information stored in a data store 126. According to one management function, the system management module 124 can establish an association between a particular target device, its pipe mechanism, and a user account. For example, the user account may be associated with a user who owns or is otherwise authorized to control the target device under consideration.
[0061] The system management module 124 can use different protocols to establish the above-described association. In one non-limiting protocol, a user who wishes to register a new target device may access the system management module 124 via a user device, e.g., by logging onto a web site associated with the system management module 124. Through that connection, the user may: (1) identify himself or herself; (2) identify the type of target device that is being registered; and/or (3) identify the pipe mechanism that is coupled to the target device. A user may also connect the target device's pipe mechanism to the service system 102. Through that connection, the pipe mechanism can provide additional identifying information to the service system 102 regarding itself and/or the target device. For example, the pipe mechanism can transmit one or more identifying codes, a digital certificate and/or other information which helps authenticate the identity of the pipe mechanism and/or the target device. Based on this collected information, the system management module 124 may establish a link that relates the target device, the pipe mechanism, and a user account associated with the user. The system management module 124 can store the collected information in the data store 126. The user is thereafter permitted to control his or her target device via the service system 102.
[0062] For example, consider the particular case in which the pipe mechanism is a permanent part of the new target device. A device manufacturer may convey a code associated with the new target device in paperwork that accompanies the sale of the new target device, or by affixing the code to the new target device itself in any manner. In this case, it may be sufficient for the user to provide a single code associated with the target device, as this code also implicitly identifies the pipe mechanism that is associated with the target device. In another case, the pipe mechanism may be an independent component
that can be attached to any target device. In this case, the user may provide two codes during the registration process, a first code associated with the pipe mechanism and a second code associated with the target device.
[0063] The system management module 124 may also set up a secure connection with the pipe mechanism using any security mechanism, such as, but not limited to, the Transport Layer Security (TLS) protocol (or the predecessor protocol, Secure Sockets Layer (SSL)). In this protocol, the system management module 124 and the pipe mechanism exchange security information to establish a secure connection. Data and instructions may thereafter be transmitted between the service system 102 and the pipe mechanism in a secure form.
[0064] Finally, the service system 102 may provide an application marketplace 128. Or a separate system (not shown) may provide the application marketplace 128. The application marketplace 128 offers a collection of applications that provide different control functions associated with different types of target devices. For example, a user who owns a coffee maker may search the application marketplace 128 for an application that is designed to control this kind of device. The user can then download this application and use it to control his or her coffee maker. Some coffee makers may be more complex than others. Hence, the user may seek out an application that is most aptly suited for the kind of coffee maker that he or she owns.
[0065] Figs. 3-6 show three different ways that a pipe mechanism may be coupled to a device. Beginning with Fig. 3, a target device 302 includes any native device functionality 304 and a pipe interface mechanism 306. The native device functionality 304 represents any functions performed by the target device 302. The pipe interface mechanism 306 provides any mechanism by which the native device functionality 304 may interact with a pipe mechanism 308. For example, in one non-limiting case, the pipe interface mechanism 306 may correspond to a relay which is connected to various switches provided by the native device functionality 304. The relay, in turn, is controlled by the pipe mechanism 308.
[0066] In some cases, the target device 302 may already provide the pipe interface mechanism 306 as part of its pre-existing ("legacy") design. In other cases, a device manufacturer may modify its legacy design to provide the pipe interface mechanism 306, so that the target device 302 can successfully interact with the pipe mechanism 308.
[0067] In Fig. 3, the pipe mechanism 308 and the target device 302 are separate components. The pipe mechanism 308 can be detachably connected to the target device
302 at any stage, e.g., during assembly of the target device 302 at a manufacturing site, or at the end user's site. The pipe mechanism 308 can couple to the pipe interface mechanism 306 using any connection strategy, generically denoted in Fig. 3 as a connection 310. For example, the connection 310 may represent a plug-type outlet that receives a chip-type pipe mechanism. Or the connection 310 may represent a cable-type connection or a wireless connection, and so on.
[0068] Fig. 4 shows a target device 402 having native functionality 404, a pipe interface mechanism 406, and a pipe mechanism 408. These modules may perform the same functions as the same-named components of Fig. 3. But in the case of Fig. 4, the pipe mechanism 408 corresponds to an embedded component of the target device 402, rather than a readily-detachable component that is considered separate from the target device 402. For example, the pipe mechanism 408 may represent a chip that is hardwired to a substrate provided in the target device 402 (such as, in more complex target devices, a printed circuit board, etc.).
[0069] Fig. 5 shows a service-controlled switch 502 that incorporates a pipe mechanism 504, a power switch 506, and a power interface mechanism 508. The power switch 506 is coupled to a power source 510, such as an AC wall outlet. The power switch 506 receives control instructions from the service system 102. Those instructions cause the power switch 506 to toggle the power on and off. When in an "on" state, the power switch 506 directs power from the power source 510 to the power interface mechanism 508; when in an "off state, the power switch 506 turns off the power to the power interface mechanism 508.
[0070] A separate target device 512 may include any native device functionality 514 and a power interface mechanism 516. The power interface mechanism 516 of the target device 512 can be coupled to the power interface mechanism 508 of the service-controlled switch 502. In this coupled state, the power switch 506 can effectively control the application of power to the target device 512, based on control instructions received by the pipe mechanism 504. In one particular implementation, the service-controlled switch 502 comprises a small unit having a male plug that may be inserted into an AC power outlet. The service-controlled switch 502 provides a female plug (associated with the power interface mechanism 508) for mating with a male plug (associated with the power interface mechanism 516) of the target device 512 (or vice versa).
[0071] More broadly stated, Fig. 5 is an example of a class of control devices that can control a separate target device in any manner. In another case, for example, the control
device can provide a multi-valued output (either continuous or discrete) based on control instructions received by the pipe mechanism. This kind of control device can control any type of target device that accepts a multi-valued input signal, such as a thermostat.
[0072] Fig. 6 shows one implementation of a pipe mechanism 602. The pipe mechanism 602 includes a device interface mechanism 604 for interacting with a target device 606, and a service interface mechanism 608 for interacting with the service system 102. The device interface mechanism 604 can be implemented in any manner, such as by interface pins provided by a chip, a male or female connection member, a relay, etc. The service interface mechanism 608 can likewise be implemented in different ways depending on the manner in which the pipe mechanism 602 is connected to the communication mechanism 112. For example, the service interface mechanism 608 can provide cell-based logic for providing cellular communication, WiFi logic for providing WiFi communication, and so on. Or the service interface mechanism 608 can include logic for establishing a hardwired- type connection of any type.
[0073] More specifically, in a first embodiment, different classes of pipe mechanisms can be provided that include different types of service interface mechanisms. The different types of service interface mechanisms can handle different types of communications (e.g., cellular, WiFi, etc.) and/or different transfer strategies (e.g., continuous, intermittent, etc.). A device manufacturer or end user can choose the appropriate class of pipe mechanism for use with a particular type of target device that is to be controlled. In a second implementation, a single type of pipe mechanism can be provided that offers a multi-mode service interface mechanism 608, where each mode offers a different type of communication and/or a different transfer strategy. A device manufacturer or end user can then select the appropriate mode for use with a particular target device to be controlled. For example, a device manufacturer can configure the pipe mechanism to provide intermittent WiFi communication with the service system 102.
[0074] The pipe mechanism 602 can also include a processing module 610 that governs it operation. The processing module 610 may correspond to one or more microprocessors and/or hardwired logic circuitry. For example, the processing module 610 can include transfer logic which governs the transfer of instructions from the service interface mechanism 608 to the device interface mechanism 604, and the flow of data from the device interface mechanism 604 to the service interface mechanism 608. The processing module 610 can also include security logic for establishing a secure connection with the service system 102. Other than these types of communication-related functions, in one
implementation, the processing module 610 remains agnostic as to the meaning of the information that flows through the pipe mechanism 602. That is, in this case, the processing module 610 is not adapted for any particular target device or any particular control function.
[0075] The processing module 610 may perform its tasks based on information stored in a data store 612. For example, the data store 612 may store an address 614 associated with the service system 102, such as a URL address. This information allows the pipe mechanism 602 to connect to the service system 102. Although not shown, the data store 612 may also store any kind of identification information, such as one or more identification codes, security-related information, certificates, etc. The identification information may identify the pipe mechanism 602. And if the pipe mechanism 602 is a fixed component of a target device, the identification information also implicitly identifies the target device. The pipe mechanism 602 may append some of this identification information as a header to data that it forwards to the service system 102. This will allow the service system 102 to identify the source of the data. The processing module 610 can also receive any identification and/or security-related information from any source, such as the system management module 124, and then store this information in its data store 612.
[0076] The pipe mechanism 602 may optionally incorporate other functions and associated inputs. For example, the pipe mechanism 602 can include a "connect" button or the like. An end user can activate this button to instruct the pipe mechanism 602 to connect to the service system 102 via the communication mechanism 112.
[0077] Fig. 7 sets forth illustrative computing functionality 700 that can be used to implement any aspect of any user device, or any aspect of any server provided by the service system 102.
[0078] The computing functionality 700 can include volatile and non-volatile memory, such as RAM 702 and ROM 704, as well as one or more processing devices 706 (e.g., one or more CPUs, and/or one or more GPUs, etc.). The computing functionality 700 also optionally includes various media devices 708, such as a hard disk module, an optical disk module, and so forth. The computing functionality 700 can perform various operations identified above when the processing device(s) 706 executes instructions that are maintained by memory (e.g., RAM 702, ROM 704, or elsewhere).
[0079] More generally, instructions and other information can be stored on any computer readable medium 710, including, but not limited to, static memory storage
devices, magnetic storage devices, optical storage devices, and so on. The term computer readable medium also encompasses plural storage devices. In many cases, the computer readable medium 710 represents some form of physical and tangible entity. The term computer readable medium also encompasses propagated signals, e.g., transmitted or received via physical conduit and/or air or other wireless medium, etc. However, the specific terms "computer readable storage medium" and "computer readable medium device" expressly exclude propagated signals per se, while including all other forms of computer readable media.
[0080] The computing functionality 700 also includes an input/output module 712 for receiving various inputs (via input devices 714), and for providing various outputs (via output devices). Illustrative input devices include a keyboard device, a mouse input device, a touchscreen input device, a gesture input device, a voice recognition mechanism, tabletop or wall-projection input mechanisms, and so on. One particular output mechanism may include a presentation device 716 and an associated graphical user interface (GUI) 718. The computing functionality 700 can also include one or more network interfaces 720 for exchanging data with other devices via one or more communication conduits 722. One or more communication buses 724 communicatively couple the above-described components together.
[0081] The communication conduit(s) 722 can be implemented in any manner, e.g., by a local area network, a wide area network (e.g., the Internet), etc., or any combination thereof. The communication conduit(s) 722 can include any combination of hardwired links, wireless links, routers, gateway functionality, name servers, etc., governed by any protocol or combination of protocols.
[0082] Alternatively, or in addition, any of the functions provided by the computing functionality 700 can be performed, at least in part, by one or more hardware logic components. For example, without limitation, the computing functionality can be implemented using one or more of: Field-programmable Gate Arrays (FPGAs); Application-specific Integrated Circuits (ASICs); Application-specific Standard Products (ASSPs); System-on-a-chip systems (SOCs); Complex Programmable Logic Devices (CPLDs), etc.
B. Illustrative Processes
[0083] Figs. 8-12 show procedures that explain one manner of operation of the environment 100 of Fig. 1. Since the principles underlying the operation of the
environment 100 have already been described in Section A, certain operations will be addressed in summary fashion in this section.
[0084] Starting with Fig. 8, this figure shows an illustrative procedure 800 for providing the environment 100. In block 802, the service system 102 is provided. For instance, the service system 102 may be implemented as a cloud computing resource, or in some other manner. In block 804, a plurality of device-agnostic pipe mechanisms 106 are provided for use in association with respective target devices 104. Fig. 2 sets forth two strategies for accomplishing this task. In block 806, the service system 102 is used to control the target devices 104 via the pipe mechanisms 106. The operations of Fig. 8 can be performed by one or more entities. For example, in one representative case, a first entity can perform blocks 802 and 806, while a second entity can perform block 804.
[0085] Fig. 9 shows an illustrative procedure 900 for associating a device and a pipe mechanism with a user. In block 902, the service system 102 can receive a registration request which identifies one or more of: (1) an entity (e.g., a user) which owns or otherwise is authorized to control a target device; (2) the target device; and/or (3) the pipe mechanism associated with the target device. For example, a user may perform this task by using a user device to log onto a web site associated with the system management module 124. The user may identify himself or herself (e.g., by providing a user ID and password), and then provide a code associated with the pipe mechanism and/or a code associated with the target device. In block 904, the service system 102 may receive a communication from the pipe mechanism under consideration. The communication may provide additional identifying information regarding the pipe mechanism and/or the target device. In block 906, the service system 102 can use the information collected in blocks 902 and 904 to establish a nexus between the user, a target device, and the pipe mechanism that is coupled to the target device. Fig. 9 shows that block 902 precedes block 904, but block 904 may alternatively follow block 902.
[0086] Fig. 10 shows a procedure 1000 for downloading an application from the service system 102 to a user device. In block 1002, the service system 102 receives a request from a user for an application. In block 1004, the service system 102 provides the requested application.
[0087] Fig. 11 shows a procedure 1100 for uploading data from a pipe mechanism to the service system 102. In block 1102, the service system 102 receives a communication from the pipe mechanism associated with a device. This communication can be received via any transfer protocol, e.g., using a continuous connection protocol or an intermittent queuing
protocol. In block 1104, the service system 102 processes the communication using an appropriate service module. In block 1106, the service system 102 can perform any postprocessing action(s), such as notifying a user of the data that has been received, controlling the target device based on the data, and so on. To perform a control action, the service system 102 can use any connection protocol to forward instructions to the pipe mechanism, such as a continuous connection protocol or an intermittent connection protocol.
[0088] Fig. 12 shows a procedure 1200 for providing configuration instructions from an entity to the service system 102. In block 1202, the service system 102 receives configuration instructions from an entity, such as a user. The user may enter those instructions by interacting with an application running on a user device. In block 1204, the service system 102 processes the instructions using an appropriate service module. In block 1206, the service system 102 can provide any post-processing action(s), such as by controlling a target device associated with the user, etc. As stated above, the service system 102 can use any connection protocol to forward instructions to the pipe mechanism associated with the target device, such as a continuous connection protocol or an intermittent connection protocol.
[0089] In closing, functionality described herein can employ various mechanisms to ensure the privacy of user data maintained by the functionality, if any. For example, the functionality can allow a user to expressly opt in to (and then expressly opt out of) the provisions of the functionality. The functionality can also provide suitable security mechanisms to ensure the privacy of the user data (such as data-sanitizing mechanisms, encryption mechanisms, password-protection mechanisms, etc.).
[0090] Further, the description may have described various concepts in the context of illustrative challenges or problems. This manner of explanation does not constitute an admission that others have appreciated and/or articulated the challenges or problems in the manner specified herein. Further, the claimed subject matter is not limited to implementations that solve any or all of the noted challenges/problems.
[0091] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
Claims
1. A service system, implemented by one or more computer devices, comprising: a plurality of service modules configured to provide a plurality of respective services, the services, in turn, for use in controlling a plurality of target devices;
a controlled device interface module configured to allow the target devices to interact with the services via a plurality of pipe mechanisms that are associated with the respective target devices; and
a user device interface module configured to allow a plurality of user devices to interact with the services,
the service system being accessible to the pipe mechanisms via a wide area network.
2. The service system of claim 1, wherein each pipe mechanism incorporates device-agnostic functionality that enables the pipe mechanism to interact with plural kinds of target devices.
3. The service system of claim 1, further including a system management module configured to establish a plurality of associations, each association linking a particular target device, a particular pipe mechanism that couples to the target device, and a particular entity that is authorized to control the target device.
4. A pipe mechanism for providing interaction between a service system and a target device, comprising:
a device interface mechanism configured to:
receive data from the target device;
provide control instructions to the target device, which cause the target device to perform a function;
a service interface mechanism configured to communicate with a remote service system, the service system having at least one service that is configured to:
receive the data from the target device; and
provide the control instructions to the target device;
a processing module configured to control operation of the pipe mechanism; and a data store for storing data for use in controlling operation of the pipe mechanism, the pipe mechanism being configured in a device-agnostic manner, enabling the pipe mechanism to interact with plural kinds of target devices.
5. The pipe mechanism of claim 4, wherein the pipe mechanism and the target device are separate respective components coupled together in a detachable manner.
6. The pipe mechanism of claim 4, wherein the pipe mechanism represents an embedded component within the target device.
7. The pipe mechanism of claim 4, wherein the target device corresponds to a control device that includes the pipe mechanism, wherein the control device controls another target device based on control instructions provided to the pipe mechanism.
8. A method for interacting with a plurality of target devices, comprising:
providing a service system implemented by one or more servers, the service system providing a plurality of service modules, each service module providing a service; and using the service system to control a plurality of target devices via a plurality of pipe mechanisms which couple to the target devices,
each pipe mechanism incorporating device-agnostic functionality that enables the pipe mechanism to interact with plural kinds of target devices.
9. The method of claim 8, wherein the pipe mechanisms are provided to one or more device manufacturers for incorporation into target devices.
10. The method of claim 8, wherein the pipe mechanisms are provided to end users for attachment to target devices.
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201480009188.4A CN105075188B (en) | 2013-02-18 | 2014-02-13 | Pipeline mechanism and making uses it to method, system and the medium of control equipment |
EP14709002.1A EP2957076B1 (en) | 2013-02-18 | 2014-02-13 | Controlling devices using cloud services and device-agnostic pipe mechanisms |
ES14709002.1T ES2604609T3 (en) | 2013-02-18 | 2014-02-13 | Control of devices using cloud services and device agnostic tube mechanisms |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/769,392 | 2013-02-18 | ||
US13/769,392 US9288102B2 (en) | 2013-02-18 | 2013-02-18 | Controlling devices using cloud services and device-agnostic pipe mechanisms |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014127075A1 true WO2014127075A1 (en) | 2014-08-21 |
Family
ID=50239952
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2014/016153 WO2014127075A1 (en) | 2013-02-18 | 2014-02-13 | Controlling devices using cloud services and device-agnostic pipe mechanisms |
Country Status (5)
Country | Link |
---|---|
US (3) | US9288102B2 (en) |
EP (1) | EP2957076B1 (en) |
CN (1) | CN105075188B (en) |
ES (1) | ES2604609T3 (en) |
WO (1) | WO2014127075A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2528630A (en) * | 2014-04-28 | 2016-02-03 | Univ Central Lancashire | Computer based system and method of functionally testing aircraft subsystems |
Families Citing this family (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
TR200805998A2 (en) | 2008-08-12 | 2009-12-21 | Kodalfa B�Lg� Ve �Let���M Teknoloj�Ler� Sanay� Ve T�Caret A.�. | Remote wireless climate monitoring and control system for greenhouses |
US10716269B2 (en) | 2008-08-12 | 2020-07-21 | Rain Bird Corporation | Methods and systems for irrigation control |
US9703275B2 (en) | 2011-06-23 | 2017-07-11 | Rain Bird Corporation | Methods and systems for irrigation and climate control |
US9288102B2 (en) | 2013-02-18 | 2016-03-15 | Microsoft Technology Licensing, Llc | Controlling devices using cloud services and device-agnostic pipe mechanisms |
US10871242B2 (en) | 2016-06-23 | 2020-12-22 | Rain Bird Corporation | Solenoid and method of manufacture |
US20180075409A1 (en) * | 2016-09-09 | 2018-03-15 | Dematic Corp. | Communication system for operation and management of workflows and integration of multiple devices utilizing different operating platforms |
US20200073352A1 (en) * | 2017-01-11 | 2020-03-05 | Intel Corporation | Techniques for enabling intelligent functionality for non-intelligent devices |
US10980120B2 (en) | 2017-06-15 | 2021-04-13 | Rain Bird Corporation | Compact printed circuit board |
CN109560945B (en) * | 2017-09-25 | 2021-02-12 | 华为技术有限公司 | Method, device and system for detecting service quality |
US11503782B2 (en) | 2018-04-11 | 2022-11-22 | Rain Bird Corporation | Smart drip irrigation emitter |
US11721465B2 (en) | 2020-04-24 | 2023-08-08 | Rain Bird Corporation | Solenoid apparatus and methods of assembly |
CN112786227B (en) * | 2020-07-29 | 2022-07-29 | 中核检修有限公司 | Control system, control method, master control device, and storage medium |
CN113599118B (en) * | 2021-08-24 | 2022-05-31 | 深圳市呵康科技有限公司 | Control method of intelligent bedridden excretion multipoint distribution treatment system |
CN115277699A (en) * | 2022-07-22 | 2022-11-01 | 江苏睿科大器机器人有限公司 | Intelligent device management cloud service platform applied to medical institution |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050076125A1 (en) * | 2003-10-03 | 2005-04-07 | Wolf-Dietrich Weber | Low power shared link arbitration |
US20080080552A1 (en) * | 2006-09-28 | 2008-04-03 | Microsoft Corporation | Hardware architecture for cloud services |
Family Cites Families (58)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5606493A (en) * | 1992-06-18 | 1997-02-25 | International Business Machines Corporation | Distributed applications processing network |
US5787245A (en) * | 1995-11-13 | 1998-07-28 | Object Technology Licensing Corporation | Portable debugging service utilizing a client debugger object and a server debugger object |
JP3636399B2 (en) * | 1996-05-29 | 2005-04-06 | 富士通株式会社 | Protocol conversion system and protocol conversion method |
JP4060414B2 (en) * | 1997-10-03 | 2008-03-12 | 日本テキサス・インスツルメンツ株式会社 | Program load device |
US6269473B1 (en) * | 1998-03-23 | 2001-07-31 | Evolve Software, Inc. | Method and apparatus for the development of dynamically configurable software systems |
US6539433B1 (en) * | 1998-09-30 | 2003-03-25 | Matsushita Electric Industrial Co., Ltd. | System for distributing native program converted from Java bytecode to a specified home appliance |
US6457081B1 (en) * | 1998-11-23 | 2002-09-24 | Advanced Micro Devices, Inc. | Packet protocol for reading an indeterminate number of data bytes across a computer interconnection bus |
US6633929B1 (en) * | 1999-04-30 | 2003-10-14 | Microsoft Corporation | Method and system for abstracting network device drivers |
US6629166B1 (en) * | 2000-06-29 | 2003-09-30 | Intel Corporation | Methods and systems for efficient connection of I/O devices to a channel-based switched fabric |
WO2002054697A1 (en) * | 2000-12-28 | 2002-07-11 | Abb Ab | Method, system architecture and computer software for communication between devices |
US6728789B2 (en) * | 2001-04-30 | 2004-04-27 | Lsi Logic Corporation | System and method employing a static logical identifier in conjuction with a look up table to provide access to a target |
US20050261816A1 (en) * | 2004-05-21 | 2005-11-24 | Audiovox Corporation | Remote programmer for a vehicle control system |
KR100412358B1 (en) * | 2001-08-24 | 2003-12-31 | 엘지전자 주식회사 | Control Data Offering System and Method for the Same |
KR100409008B1 (en) * | 2001-08-24 | 2003-12-06 | 엘지전자 주식회사 | Home Appliance Controlling Data Transferring System and Method for the Same |
US7650325B2 (en) * | 2001-11-13 | 2010-01-19 | International Business Machines Corporation | Dynamic interface adapter for integration of source and target applications |
US20030172077A1 (en) * | 2002-03-08 | 2003-09-11 | Mir3, Inc. | Device-independent notification system |
FR2837585B1 (en) * | 2002-03-25 | 2004-06-25 | Airbus France | INSTALLATION, GATEWAY AND METHOD FOR DOWNLOADING INFORMATION BETWEEN EQUIPMENT ON BOARD ON AN AIRCRAFT AND NON-ON-BOARD LOADING MEANS |
US6816728B2 (en) * | 2002-04-24 | 2004-11-09 | Teledyne Technologies Incorporated | Aircraft data communication system and method |
US7340737B2 (en) * | 2002-07-03 | 2008-03-04 | National Instruments Corporation | Wireless deployment / distributed execution of graphical programs to smart sensors |
US6763226B1 (en) * | 2002-07-31 | 2004-07-13 | Computer Science Central, Inc. | Multifunctional world wide walkie talkie, a tri-frequency cellular-satellite wireless instant messenger computer and network for establishing global wireless volp quality of service (qos) communications, unified messaging, and video conferencing via the internet |
US7484095B2 (en) * | 2003-01-16 | 2009-01-27 | Sun Microsystems, Inc. | System for communicating program data between a first device and a second device |
US7440408B1 (en) * | 2003-09-10 | 2008-10-21 | Sprint Communications Company L.P. | Method and system for inventorying a network |
US7797733B1 (en) * | 2004-01-08 | 2010-09-14 | Symantec Corporation | Monitoring and controlling services |
US7660871B2 (en) * | 2004-05-28 | 2010-02-09 | Microsoft Corporation | System and method for automatically generating networked service installation based on subscription status |
US20130332343A1 (en) * | 2005-10-06 | 2013-12-12 | C-Sam, Inc. | Multi-tiered, secure mobile transactions ecosystem enabling platform comprising a personalization tier, a service tier, and an enabling tier |
FR2900263B1 (en) * | 2006-04-19 | 2009-11-06 | Somfy Sas | METHOD FOR TESTING AND INSTALLING DOMOTIC REMOTE CONTROL |
US8364968B2 (en) * | 2006-05-19 | 2013-01-29 | Symantec Corporation | Dynamic web services systems and method for use of personal trusted devices and identity tokens |
US20070286181A1 (en) * | 2006-05-25 | 2007-12-13 | Dennis Bushmitch | Remote home/office monitoring and control using Skype |
US7996730B2 (en) * | 2006-06-05 | 2011-08-09 | International Business Machines Corporation | Customizable system for the automatic gathering of software service information |
US8005236B2 (en) * | 2006-09-07 | 2011-08-23 | Porto Vinci Ltd. Limited Liability Company | Control of data presentation using a wireless home entertainment hub |
US20100276482A1 (en) * | 2006-09-28 | 2010-11-04 | Smart Light Tech. LLC | Apparatus and method for managing energy consumption within an unoccupied room |
US8892767B1 (en) * | 2007-09-26 | 2014-11-18 | Qualcomm Incorporated | Method and apparatus for communication of a target over point-to-point interface with a host managing wireless LAN services and target resources |
US8040888B1 (en) * | 2007-12-17 | 2011-10-18 | Integrated Device Technology, Inc. | Packet switch with port route tables |
US20090199203A1 (en) * | 2008-02-01 | 2009-08-06 | International Business Machines Corporation | Interacting with applications via an instant messaging client to perform application specific tasks |
JP5129617B2 (en) * | 2008-03-12 | 2013-01-30 | キヤノン株式会社 | COMMUNICATION CONTROL METHOD, COMMUNICATION SYSTEM, COMMUNICATION DEVICE, AND COMPUTER PROGRAM |
US8200795B2 (en) * | 2008-06-05 | 2012-06-12 | Sony Computer Entertainment Inc. | Mobile phone game interface |
US8250215B2 (en) | 2008-08-12 | 2012-08-21 | Sap Ag | Method and system for intelligently leveraging cloud computing resources |
US20120105249A1 (en) * | 2008-09-09 | 2012-05-03 | T-Systems International Gmbh | Method and Distributed System for Detecting and Managing Data from a Plurality of Measuring Devices |
AU2009290589B2 (en) * | 2008-09-15 | 2015-03-26 | Haier Us Appliance Solutions, Inc. | Energy management of household appliances |
US20100168914A1 (en) * | 2008-12-29 | 2010-07-01 | Electronics And Telecommunications Research Institute | Diagnosis and management server for multi-kinds robots |
CN101826061A (en) * | 2009-03-03 | 2010-09-08 | 华硕电脑股份有限公司 | Shared system and management method of hardware device |
US8660355B2 (en) * | 2010-03-19 | 2014-02-25 | Digimarc Corporation | Methods and systems for determining image processing operations relevant to particular imagery |
US8914471B2 (en) * | 2010-05-28 | 2014-12-16 | Qualcomm Incorporated | File delivery over a broadcast network using file system abstraction, broadcast schedule messages and selective reception |
US8010993B1 (en) * | 2010-07-14 | 2011-08-30 | Domanicom Corp. | Devices, systems, and methods for enabling reconfiguration of services supported by a network of devices |
US9246332B2 (en) * | 2010-10-01 | 2016-01-26 | General Electric Company | Household energy management system and method for one or more appliances and power generator |
US20120109395A1 (en) * | 2010-10-28 | 2012-05-03 | General Electric Company | Controlling multiple smart appliances with a single communication interface |
US20120117271A1 (en) * | 2010-11-05 | 2012-05-10 | Sony Corporation | Synchronization of Data in a Distributed Computing Environment |
US8321605B2 (en) * | 2010-12-13 | 2012-11-27 | Apple Inc. | PIO interjection between beats of a DMA operation |
KR101183885B1 (en) * | 2011-01-05 | 2012-09-19 | 전자부품연구원 | Method for providing service executed in various service modules and home gateway using the same |
KR101595527B1 (en) | 2011-03-22 | 2016-02-22 | 한국전자통신연구원 | System for configurating dynamic service network based on netstore and method thereof |
US9032493B2 (en) | 2011-03-31 | 2015-05-12 | Intel Corporation | Connecting mobile devices, internet-connected vehicles, and cloud services |
TWI683593B (en) * | 2011-06-29 | 2020-01-21 | 澳大利亞商自由科技有限公司 | Systems, methods, and/or apparatus for enabling communication between devices using different communication protocols |
TW201308087A (en) * | 2011-08-02 | 2013-02-16 | Hon Hai Prec Ind Co Ltd | Method and system for controlling household appliances |
US20140157355A1 (en) * | 2012-01-06 | 2014-06-05 | Optio Labs, LLC | Systems and methods for enhancing mobile device security with a processor trusted zone |
US20130201316A1 (en) * | 2012-01-09 | 2013-08-08 | May Patents Ltd. | System and method for server based control |
US8825020B2 (en) * | 2012-01-12 | 2014-09-02 | Sensory, Incorporated | Information access and device control using mobile phones and audio in the home environment |
US20140047124A1 (en) * | 2012-08-10 | 2014-02-13 | Honeywell International Inc. | Trivial file transfer protocol (tftp) data transferring prior to file transfer completion |
US9288102B2 (en) | 2013-02-18 | 2016-03-15 | Microsoft Technology Licensing, Llc | Controlling devices using cloud services and device-agnostic pipe mechanisms |
-
2013
- 2013-02-18 US US13/769,392 patent/US9288102B2/en active Active
-
2014
- 2014-02-13 WO PCT/US2014/016153 patent/WO2014127075A1/en active Application Filing
- 2014-02-13 EP EP14709002.1A patent/EP2957076B1/en active Active
- 2014-02-13 CN CN201480009188.4A patent/CN105075188B/en active Active
- 2014-02-13 ES ES14709002.1T patent/ES2604609T3/en active Active
-
2016
- 2016-01-19 US US15/001,165 patent/US9667727B2/en active Active
-
2017
- 2017-03-28 US US15/471,724 patent/US20170201586A1/en not_active Abandoned
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050076125A1 (en) * | 2003-10-03 | 2005-04-07 | Wolf-Dietrich Weber | Low power shared link arbitration |
US20080080552A1 (en) * | 2006-09-28 | 2008-04-03 | Microsoft Corporation | Hardware architecture for cloud services |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2528630A (en) * | 2014-04-28 | 2016-02-03 | Univ Central Lancashire | Computer based system and method of functionally testing aircraft subsystems |
Also Published As
Publication number | Publication date |
---|---|
US20160134706A1 (en) | 2016-05-12 |
US20170201586A1 (en) | 2017-07-13 |
US9667727B2 (en) | 2017-05-30 |
CN105075188B (en) | 2019-01-04 |
US9288102B2 (en) | 2016-03-15 |
EP2957076A1 (en) | 2015-12-23 |
ES2604609T3 (en) | 2017-03-07 |
CN105075188A (en) | 2015-11-18 |
US20140237092A1 (en) | 2014-08-21 |
EP2957076B1 (en) | 2016-08-31 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9667727B2 (en) | Controlling devices using cloud services and device-agnostic pipe mechanisms | |
US10819806B2 (en) | Internet of things (IOT) device discovery platform | |
KR101662396B1 (en) | Method and system for controlling device based internet of things | |
CN111667384B (en) | Building automation management apparatus and method | |
CA2910090C (en) | Thermostat code input system and method therefor using ssid | |
JP6268122B2 (en) | Energy management equipment | |
CN106054957B (en) | Method, system and related framework for managing network connection thermostat | |
US20150280935A1 (en) | Thermostat code input system and method therefor | |
US10063499B2 (en) | Non-cloud based communication platform for an environment control system | |
CN107087015B (en) | Mobile device having contractor accessible screen for configuring building devices | |
CN107534657A (en) | The system of third party's control of network access device | |
KR20180116873A (en) | Smart home controller and smart home service method, system and service server using it | |
CN105049337B (en) | Communication means and device between a kind of smart machine based on instant messaging | |
Yeoh et al. | e2Home: A lightweight smart home management system | |
CN103941599A (en) | Intelligent household electrical appliance control method, intelligent household electrical appliance and control system | |
CN111953677B (en) | System, method, equipment and storage medium for cross-platform linkage of intelligent equipment | |
US20210021695A1 (en) | System and method for remote execution of real time control (rtc) hardware | |
KR101812170B1 (en) | An information management system for home appliance | |
Khan et al. | Resource-based direct manipulation: a user-centric visual interface for operational customization of future smart appliances | |
Singh et al. | Facebook based home appliances control and security monitoring using raspberry pi 3 | |
Prasad et al. | Controlling of Home Appliances Using Internet of Things | |
Faizrakhmanov et al. | Prototype, Method, and Experiment for Evaluating Usability of Smart Home User Interfaces | |
Viitanen | Creation of a building operating system: holistic approach | |
Saini | Design and requirements of IoT based smart buildings | |
elkarim Jezzini | Final Year Project Home Automation with NFC & Raspberry Pi |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
WWE | Wipo information: entry into national phase |
Ref document number: 201480009188.4 Country of ref document: CN |
|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14709002 Country of ref document: EP Kind code of ref document: A1 |
|
DPE1 | Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101) | ||
REEP | Request for entry into the european phase |
Ref document number: 2014709002 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2014709002 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |