US20220329897A1 - System and method for ubiquitous appliance control - Google Patents

Abstract

A slave relay station is adapted to serve and/or host pages comprising a simplified graphic user interface (GUI) encoded in a widely recognized format such as, for example, HTML, or WML. The GUI embodies activatable links corresponding to control functions for configured appliances. A wireless phone or other device with network access and the capability to process and present such pages, for example via a Web browser, may then be utilized to effect control of such appliances by simply navigating to the network address of the slave relay station, obtaining an appropriate GUI page, and interacting with the links.

Description

• This application claims the benefit of and is a continuation of U.S. application Ser. No. 15/711,381, filed on Sep. 21, 2017, which application claims the benefit of and is a continuation of U.S. application Ser. No. 13/542,146, filed on Jul. 5, 2012, which application claims the benefit of and is a continuation of U.S. application Ser. No. 12/147,770, filed on Jun. 27, 2008, the disclosures of which are incorporated herein by reference in their entirety.
BACKGROUND
• Portable controlling devices, such as for example universal remote controls, and the features and functions offered by such devices are well known in the art. Increasingly sophisticated implementations of these devices incorporate technologies such as color touch screens, wireless home network compatibility, user configurable graphical user interfaces, slave relay stations positioned to control appliances not situated in line of sight of the controlling device, etc. Contemporaneously, personal communication, productivity, and entertainment devices such as cellular phones, portable email devices, hand-held games, etc. have begun to offer features such as graphical user interfaces on color touch screens, wireless Internet capability, etc.
SUMMARY OF THE INVENTION
• This invention relates generally to systems and methods for adapting various appliance control capabilities of a universal remote control system such that they may be ubiquitously accessed by personal communication devices within a wireless network. Specifically, one or more network-capable slave relay stations installed in conjunction with a universal remote control device may additionally be adapted to serve and/or host pages comprising a simplified graphic user interface (GUI) encoded in a widely recognized format such as for example HTML or WML, which GUI embodies activatable links corresponding to control functions for configured appliances. A wireless phone or other device with network access and the capability to process and present such pages, for example via a Web browser, may then be utilized to effect control of such appliances by simply navigating to the network address of that slave relay station. Such devices may include without limitation cellular phones, smartphones, personal productivity devices, personal gaming, audio, or video players, game controllers, PDAs, etc., all collectively referred to hereafter as personal communication devices.
• In some embodiments, the GUI pages to be served by slave relay stations may be created using the same editor as provided for use in creating or modifying the universal controlling device graphical user interface. Further, in certain embodiments the GUI pages to be served may be dynamically selected, scaled, or otherwise modified by a local or remote service based upon the known or inferred capabilities of the requesting personal communication device.
• A better understanding of the objects, advantages, features, properties, and relationships of the invention will be obtained from the following detailed description and accompanying drawings which set forth illustrative embodiments and which are indicative of the various ways in which the principles of the invention may be employed.
BRIEF DESCRIPTION OF THE DRAWINGS
• For a better understanding of the various aspects of the invention, reference may be had to preferred embodiments shown in the attached drawings in which:
• FIG. 1 illustrates an exemplary prior art universal controlling device and system;
• FIG. 2 illustrates an exemplary prior art system for creating graphical user interface pages for the controlling device ofFIG. 1;
• FIG. 3 illustrates a block diagram of exemplary components of an exemplary slave relay device;
• FIGS. 4aand 4billustrate exemplary systems in which exemplary personal communication devices may be used as controlling devices in accordance with the teachings of the instant invention;
• FIG. 5 illustrates in flow chart form exemplary actions of an exemplary slave relay device when serving GUI pages to a personal communication device;
• FIG. 6 illustrates an exemplary personal communication device functioning as a controlling device;
• FIG. 7 illustrates a second exemplary personal communication device functioning as a controlling device;
• FIG. 8 illustrates in flow chart form an exemplary method for adapting or selecting GUI pages to match the capabilities of exemplary personal communication devices;
• FIG. 9 illustrates an exemplary editing program which may be used to create GUI pages for use with personal communication devices;
• FIG. 10aillustrates an exemplary set of data files which may define a GUI page from which an appliance may be controlled;
• FIG. 10billustrates an exemplary tag file comprising XML which may be executed by a slave relay device to effect control of an appliance; and
• FIG. 11 illustrates in flow chart form another exemplary method for adapting or selecting GUI pages to match the capabilities of an exemplary personal communication device.
DETAILED DESCRIPTION
• With reference toFIGS. 1 and 2, which are representative of prior art, it is known to provide a universal controllingdevice102 comprising a touch screengraphical user interface120 through which various appliances, for example aTV108, cable set top box (STB)104 and/orAV receiver104 may be controlled. For further detail regarding this type of controlling device, reference may be made to U.S. Pat. No. 7,143,214, entitled “Hand Held Device Having a Browser Application,” or 7,266,777, entitled “Configurable Controlling Device Having an Associated Editing Program,” both of like assignee and incorporated herein by reference in their entirety.
• In order to facilitate control of infrared (IR) signal responsive appliances which are not positioned in line of sight of controllingdevice102, it is also known to provide aslave relay station100 which receivesRF communications110 from controllingdevice102 and outputsIR signals112 to the various controlled devices. In the simplest form, said slave relay station may consist of nothing more than an analog RF demodulator and IR remodulator such as described, for example, in U.S. Pat. No. 5,142,397, entitled “System for Extending the Effective Operational Range of an Infrared Remote Control System.” However, in the more general case where theRF communication path110 utilizes a standardized protocol such as for example WiFi, Bluetooth, Zwave, Zigbee, etc., theslave relay device100 may be required to receive and decode incoming messages in one format and translate these into IR commands (or even sequences of commands) having one or more different format(s) recognizable by the intended target device(s) for said commands. In this regard, see for example the “Nevo Link” brochure NSL007-2 published by Universal Electronics Inc. which is incorporated herein by reference in its entirety. To this end, the slave relay devices contemplated by the teachings of this invention incorporate processing capabilities, as will be described in greater detail in conjunction withFIG. 3.
• As illustrated inFIG. 2, it is also known to provide application software comprising aneditor200 for execution on a PC202 or other computer which may be used to configure and create individualized graphical user interfaces and command libraries for downloading into a controllingdevice102. Such editor software may also be used to configure/assign slave relay device(s)100 attached to a local area network and accessible to controllingdevice102. The editor software may make use of local204 and/or remote208 database facilities for the retrieval of appliance command data, interface graphics, etc., as well as for storage of edited configurations.Remote database208 may be hosted on aserver210 accessible via, for example, the Internet or a similarwide area network206. For further detail regarding controlling device editor applications, the reader may refer to, for example, the aforementioned U.S. Pat. Nos. 7,266,777, 6,211,870, entitled “Computer Programmable Remote Control,” and pending U.S. patent application Ser. No. 11/357,681, entitled “Configurable Controlling Device and Associated Configuration Distribution System and Method,” all of like assignee and incorporated herein by reference in their entirety, as well as U.S. Pat. No. 6,937,972, entitled “Fully Functional Remote Control Editor and Emulator,” also incorporated herein by reference in its entirety.
• Turning now toFIG. 3, the architecture of an exemplary slave relay station is illustrated in block diagram form. For use in commanding the functional operations of one or more appliances in response to messages received via a wired or wireless network connection, aslave relay station100 may include, as needed for a particular application, aprocessor300 coupled to aROM memory304, aRAM memory302, a non-volatile read/writememory306, circuit(s)308 for transmission of operating commands to appliances (e.g., IR and/or RF), a wireless network transceiver310 (e.g. WiFi, Bluetooth, etc.) and/or a wired network interface312 (e.g. Ethernet) for communication with a local network, ameans314 to provide feedback to the user (e.g., one or more LEDs, LCD display, speaker, and/or the like), and apower source316.
• As will be understood by those skilled in the art, some or all of thememories302,304,306 may include executable instructions (collectively, the program memory) that are intended to be executed by theprocessor300 to control the operation of theslave relay station100, as well as data that serves to define appliance control protocols and command values to the operational software (the appliance code data). In this manner, theprocessor200 may be programmed to control the various electronic components within theslave relay station100 and process the input and output data thereof, for example, to receive and transmit data vianetwork interfaces308 and/or310, to act upon commands and requests embodied in such data, to cause the transmission of appliance command signals via transmission circuits(s)308 to appliances to be controlled, to control visual feedback device(s)314, etc. In a contemplated embodiment, the non-volatile read/writememory306, for example an EEPROM, battery-backed up RAM, FLASH, Smart Card, memory stick, or the like, may additionally be used to store HTML page data for serving to requesting devices, as described in greater detail hereafter. While thememory304 is illustrated and described as a ROM memory,memory304 may also be comprised of any type of readable media, such as ROM, FLASH, EEPROM, or the like. Preferably, thememories304 and306 are non-volatile or battery-backed such that data is not required to be reloaded after power interruptions. In addition, thememories302,304, and306 may take the form of a chip, a hard disk, a magnetic disk, an optical disk, and/or the like. Still further, it will be appreciated that some or all of the illustrated memory devices may be physically incorporated within the same IC chip as the microprocessor300 (a so called “microcontroller”) and, as such, they are shown separately inFIG. 3 only for the sake of clarity.
• To cause theslave relay device100 to perform an action,slave relay device100 is adapted to be responsive to events, such as a received signal fromnetwork interface port310 or312. In response to an event, appropriate instructions within the program memory (hereafter the “operating program”) may be executed. For example, receipt of a command message from controllingdevice102 may result in the retrieval from the appliance code data the command value and control protocol appropriate for an intended target device and a resulting transmission of the requested command to the intended target appliance, e.g., the STB106, in a format recognizable by the intended target appliance. Additionally, in keeping with the teachings of the instant invention, receipt of, for example, an HTTP page request from a browser capable, client, personal communication device may result in the retrieval of HTML formatted data and serving of a page comprised of the HTML formatted data back to the requesting client, as will be described in greater detail hereafter.
• For selecting a set of appliance code data to be associated with an appliance to be controlled, data may be provided to theslave relay device100 that serves to identify an intended target appliance by its type and make (and sometimes model). Such data may allow theslave relay device100 to identify the appropriate appliance code data elements within a preprogrammed library of appliance code data, to be used to transmit recognizable commands in a format appropriate for such identified appliances. Alternatively, either in place of or in addition to a pre-stored library, appliance code data may be downloaded intoslave relay device100 via a network interface(s)310,312 either during an initialization phase or on an as required basis.
• Referring now toFIG. 4a, in an exemplary embodiment a wirelesslocal area network406, for example a WiFi network, provides a means for communication betweenslave relay devices100 and100′ and auniversal controlling device102.Slave relay devices100 and100′ provide a conduit for controllingdevice102 to issue operational commands toappliances108,106,104 and108′,106′ respectively. Various embodiments of such slave relay devices may interface directly to wireless network406 (e.g., via a built-in wireless network transceiver310) as illustrated bydevice100, or may interface to the network via a hardwired connection to a router408 (e.g., via a built-in wired network interface312) as illustrated bydevice100′. In either case, wireless commands originating from controllingdevice102 are converted into appliance control commands of a format suitable for use with the target appliance(s), e.g.104,106 or108, as previously described in conjunction withFIGS. 1 and 3. A localpersonal computer202 or other device having Internet connectivity and an Internet connection410 (e.g., a cable modem) are also connected torouter408 and thus accessible via the wirelesslocal network406.
• In an exemplary embodiment, in addition to servicing requests fromuniversal controlling device102 as is known in the art, the illustratedslave relay devices100 and100′ of the instant invention are also capable of serving HTML-formatted pages overlocal area network406 as requested by browser-capable devices such aspersonal communications devices400 or402, thereby allowing such devices to be used as surrogate or additional universal controlling devices, as will be described hereafter in greater detail.
• As will be appreciated by those of skill in the art, not all personal communication devices may be equipped to communicate directly with a local network (e.g., have a WiFi capability). As illustrated inFIG. 4b, certain exemplary personal communication devices, e.g.,cell phone422, may be adapted to communicate only via a closedwide area network424,426 (e.g., a cellular phone network) to a contractedservice provider420. Such a personal communication device may however offer access to theInternet206 via aservice provider gateway428. In such cases, it will be appreciated that the exemplary personal communication device may request HTML, formatted GUI pages fromslave relay station100 viaInternet206 andlocal router408. Accordingly in the discussions that follow, it is to be understood that the services described are not intended to be limited to only those devices which are equipped to directly accesslocal network406.
• Turning now toFIG. 5, there is illustrated in flowchart form an exemplary series of steps which may be performed by the operating program of a slave relay device upon receipt of a communication from the local network. While for the purpose of this illustrative example certain terminology common to a WiFi-based local network and HTTP transaction protocol may be used for clarity, this is not intended to be limiting as it will be appreciated that the concepts presented may be practiced equally effectively using other appropriate network architectures and/or protocols.
• Upon initial receipt of a network communication, atstep502 the operating program of the slave relay station may first determine if the communication comprises a function command from an associated universal controlling device (e.g., controller102). If so, atsteps514,516 and518 the operating software may retrieve the requested command function from the appliance code data previously associated with the desired appliance, transmit that command to the appliance in the appropriate format, and then issue a completion confirmation response to the initiating device, all as is known in the prior art.
• If the received communication is not a function command from a universal controlling device, the operating software may next determine if the communication is a request from a user agent, e.g., a browser application resident in a networked device such aspersonal communication devices400,402, or422 (each alternatively referred to hereafter as the “client device”). If not, atstep520 an error message, e.g., an HTTP “Error404—Not Found” response is issued to the originating network device. Alternatively the operating software may be configured to issue a simplified default interface page in the event that the unknown client device is able to render rudimentary HTML, or other markup language pages. If the communication is a recognized user agent request, the operating software atstep506 then determines if this is GUI page request, e.g., a request for an HTML file. If so, atstep530 the operating software resolves the request file path and determines the GUI page to be served in response to the user agent request. (If any error is encountered, e.g., the file path/name does not exist, an error response akin to step520 may be issued to the requesting device. For the sake of clarity, this and other similar error conditions are not exhaustively illustrated in the flowchart ofFIG. 5.) Once the GUI page to be served has been identified, the operating software atstep534 may next optionally determine the requesting client device type and capabilities. This may include, for example, examining various fields in the received request (for example, “accept” and “user agent” data in an HTTP request header) or other pre-defined identification data, searching a local or remote cross-reference table of IP or MAC addresses to device types, or even interacting with the requesting device itself to obtain the identification data. Alternatively, a fixed set of device capabilities for the request issuing device may have been predetermined at the time the slave relay device was configured. Once the client device capabilities are known or inferred, atstep538 the page data corresponding to the identified GUI page may be scaled or reformatted, or an alternate GUI page selected, based on the capabilities of the client device. This process will be described in greater detail later. Finally, atstep540 the requesting client device is responded to with the GUI page data.
• Turning momentarily toFIG. 6, by way of example only, such a GUI page may compriseHTML data600 as illustrated. When rendered on apersonal communication device402, such an HTML page may appear as illustrated at602. In particular such a GUI page display may comprise a series of icons representative of appliance control actions which may be initiated from the displaying client device. When one of the displayed icons or links is selected (it will be appreciated that such selection may be by touch, by cursor movement, by operation of navigation keys, etc., as appropriate to the particular client device currently rendering the GUI page) this may result in a message being transmitted back to the originating slave relay device, receipt of which causes the desired command(s) to be issued to an appliance. By way of more detailed example, theGUI page display602 of the embodiment illustrated inFIG. 6 comprises six channel selection icons, four of which are configured to cause a tunable appliance (e.g., set top box106) to be set to particular channel, while the remaining two are configured to issue generic “channel up” and “channel down” commands to the appliance. To this end, the HTML data comprisingGUI page600 may include six HTML “tags” such as forexample tag604 corresponding to the broadcast TV channel “ABC” or tag606 corresponding to the “channel up” function. In this implementation, each tag comprises a definition of an icon to be displayed, e.g., “abc_button.png” (in this example, a graphic file to be retrieved from the originating server), an action to be taken if and when the icon is selected (in this example, an HTTP request back to the originating server for a filename such as for example “switch_to_abc.irm” or “channel_up.irc”), and size and formatting information for positioning the displayed icon.
• Returning now toFIG. 5, if the operating program of the slave relay device has determined that a received communication is not a function command from an associated universal controlling device and is not a GUI page request, it next determines atstep510 if the received message is a request for an individual appliance command function (e.g., “Channel up”, “Mute” or “Pause”). This may be determined, for example, by the type or format of the request. By way of further specific example, in the HTML example described above in conjunction withFIG. 6, the file extension “.irc” may have special significance to the slave relay device operating software, i.e., receipt of a request for “channel_up.irc” may cause the operating software to retrieve from the stored appliance code data the appropriate command value and control protocol and use these to transmit the requested command to the designated appliance as illustrated atsteps524 and526. The manner in which an association is formed between a function request and the appropriate appliance command will be discussed in greater detail later. Thereafter, atstep528 the operating software may determine the next GUI page to be presented, if any, and serve this back to the requesting client device as previously described.
• If the received communication is not a request for an individual appliance command function, the operating software next checks if the request is for a sequence of commands (e.g., the digits “0”, “0”, “7” to tune to channel seven). Once again, this may be determined, for example, by the type or format of the request. If the request is for a command sequence, the desired series of commands is determined atstep522 and then transmitted to the specified appliance(s) in similar manner to that described previously. By way of further specific example, in the HTML example described above in conjunction withFIG. 6, the file extension “.irm” may have special significance to the slave relay device operating software, i.e. receipt of a request for “switch-to-abc.irm” may cause the operating software to retrieve a stored series of commands operable to change a pre-determined channel tuning device to the ABC broadcast channel and transmit these to that appliance. The manner in which an association is formed between a command sequence request and a series of appliance command will be discussed in greater detail later. Upon completion of the sequence transmission, the operating software may determine the next GUI page to be presented, if any, and serve this back to the requesting client device as previously described. By way of example, on completion of a channel changing sequence, it may be desirable to automatically switch to a GUI page from which television volume may be controlled, e.g., thepage412 illustrated inFIG. 4a.
• Finally, atstep542 the operating program of the slave relay device may check for other valid requests (for example, requests for icon graphics as mentioned above in conjunction with the HTML data ofFIG. 6). If valid, other requests may be serviced as appropriate atstep544, else an error message may be returned to the requesting client device.
• As mentioned above in connection withstep538 ofFIG. 5, GUI pages to be served may be scaled, reformatted, or selected to match the capabilities of the requesting client device. By way of specific example, again using HTTP as an exemplary transfer protocol, the HTTP request header issued byclient device402 illustrated inFIGS. 4aand6 may include a user agent string such as:
• User-Agent=[Mozilla/5.0 (iPhone; u; CPU like Mac OS X; en) AppleWebKit/420.1
• (KHTML, like Gecko) Version/3.0 Mobile/4A102 Safari/419.3]
• while the HTTP request header issued byclient device422 illustrated inFIGS. 4band7 and may include a user agent string such as:
• User-Agent=[Nokia6500s-1/2.0 (04.80) Profile/MIDP-2.1 Configuration/CLDC-1.1]
• Upon receipt of an HTTP “GET” command requesting a GUI page, the operating program of a slave relay device may examine the request header contents (or forward them to another system for examination) to determine an appropriate format for the GUI page to be served. Continuing the specific example, an examination of the HTML defining the “ABC” tags illustrated at604 and704 will reveal that the size of the button icon (i.e., the “width” and “height” parameters) is adjusted to better match the screen resolution, screen size, orientation capabilities, and rendering engines of the respective client devices402 (e.g., an Apple iPhone) and422 (e.g. a Nokia6500s).
• Turning now toFIG. 8, by way of further example a method by which GUI pages may be modified or selected to match specific requesting client devices, corresponding tosteps534 and538 ofFIG. 5, is illustrated in greater detail once again using HTTP as an exemplary transfer protocol, without limitation. Having determined that a particular GUI page (for example, an HTML file) is to be served to a requesting client device, the operating software of the exemplaryslave relay device100 may, atstep802, determine if GUI page scaling/selection is enabled. If not, at step820 a fixed GUI page is returned and no further page formatting action is taken. This may occur, for example, when an author of a group of universal remote control GUI pages has decided to support only a lowest common denominator set of client device capabilities, when a specific GUI page comprises only a single function such as a status message or on/off button, etc. In various embodiments such pages may be stored inmemory302,304,306 ofslave relay device100, may be retrieved from a local202 or remote210 server by theslave relay device100, or a combination thereof, as appropriate. In addition, it will be appreciated that such pages may be stored in a local202 or remote210 server and merely caused by theslave relay device100 to be forwarded to the client device via an appropriate communications channel. Still further, the local202 or remote210 server may forward such pages to the client device via an appropriate communications channel upon seeing a page request being issued from the client device without requiring theslave relay device100 itself to initiate any operations associated with such page fulfillment requests.
• If however GUI page scaling/selection is enabled, adevice adaptation service800 may be invoked. Atstep804 the user agent string may be retrieved from the client device's HTTP request header, which as previously illustrated may contain information which serves to identify the requesting client device. If the user agent string is recognized atstep806, device capability information corresponding to the requesting client device is retrieved atstep814. By way of example only, in one contemplated embodiment client devices may be categorized into several classes based on maximum supported horizontal screen resolution, e.g., less than 105 pixels, 106 to 175 pixels, 176 to 239 pixels, 240 to 319 pixels, 320 to 639 pixels, etc., etc. Once a client device has been identified, its class may be determined via a look-up table and an appropriate HTML, file selected by the device adaptation service atstep818 from a library of pre-formatted versions of each GUI page, one for each device class. Alternatively, in another exemplary embodiment, a single master HTML file may be created for each GUI page based on a default resolution, and then scaled by the device adaptation service atstep818 to match the exact resolution of the target client device, once again determined from a look-up table. In this regard, it should be noted that certain client device browser implementations may be adapted to compress or shrink received graphic pages in order to emulate a browser screen of greater resolution than that of the underlying personal communication device hardware. In such instances, it will be appreciated that the parameters used by the device adaptation service in creating or scaling GUI pages should match the emulated, and not the actual, resolution of the target client device. Further, in various embodiments, other client device capabilities, e.g., color versus monochrome, touch screen selection of icons versus navigation keys, etc., may also be used to additionally refine GUI pages to match a specific target client device.
• In the event a user agent string is not immediately recognized, e.g. by being found in a look-up table as described above, at step808 a determination is made by the device adaptation service whether additional analysis is possible. When possible, atstep810 such analysis may include forwarding the user agent string data to additional search services for further processing, inspection of additional fields in the HTTP request header (e.g., a URL pointing to profile data for the client device), direct interaction with the requesting client device, etc. By way of specific example, the HTTP request header issued byclient device422 illustrated inFIGS. 4band7 may include a reference to a device profile, e.g.:
• x-wap-profile=[“http://ndsl.nds.nokia.com/uaprof/N6500sr100.xml”]
• which profile data, when retrieved from the indicated URL, may include for example statements such as:
• <prf ColorCapable>Yes</prf:ColorCapable>
• . . .
• <prflmageCapable>Yes</prf:ImageCapable>
• . . .
• <prf:ScreenSize>240×320</prf:ScreenSize>
• which are indicative of the capabilities of that client device.
• As illustrated atstep812, if the client device is successfully identified via these further measures, the device adaptation service proceeds with retrieval of client device capability information atstep814, else atstep816 the client device capabilities are set to a default value, for example the most common capability set, the set of capabilities used in creating a master HTML file, etc.
• As will be appreciated, the steps of the exemplary method described above in conjunction withFIG. 8 may be performed locally by the operating software of the slave relay device, or by a service hosted on a local (e.g.202) or remote (e.g.210) computer system and available to the operating software via network(s)406,206, or by any combination thereof, as appropriate to a particular embodiment. For example, the service performed by the device adaptation service may be performed at the slave relay station itself, may be performed at another device in communication with the slave relay station with a modified HTML page being returned to the slave relay station for transfer, and/or may be performed at a device in the communication channel between the slave relay station and the requesting client device whereupon a HTML page received or already stored by such device is modified prior to its being forwarded on to the requesting client device. Accordingly the above descriptions are not intended to be limiting as to location of the various steps of the device adaptation services described.
• In order to create fully functional GUI page definitions for use in the above described systems, a means may be provided to generate graphic pages with activatable icons suitable for rendering by target client devices (e.g., HTML files) as well as means to generate an association between each activatable icon and a desired control action on the part of the host slave relay device. While these activities may be performed as separate steps using separate tools, for example, any convenient HTML editor to generate loadable graphic pages with embedded tags and any convenient text editor to create slave relay device-recognizable XML files defining the actions to be taken for each tag, in certain embodiments a single software tool may be made available to perform both functions, thereby offering greater ease of use and consistency of output. Advantageously, this may comprise an extension to an editor provided for creation and/or modification of the graphic user interface of a universal controlling device (e.g. controlling device102) used in conjunction with the slave relay device (e.g. device100), examples of which may be found described in the previously referenced and incorporated U.S. Pat. Nos. 7,266,777, 6,211,870, 6,937,972 and pending U.S. patent application Ser. No. 11/357,681.
• Turning now toFIG. 9, there is illustrated an exemplary editor adapted to support the creation of GUI files for use with a slave relay device as described above. Such an editor application may be resident on a local PC (e.g., PC202) or may be located remotely and used to create edited GUI pages for later transfer to the local systems. In either case, theeditor screen900 comprises alayout area902 in which a WYSIWYG image of the GUI page under creation may be displayed, together with a gallery oficons904 from which images be dragged and placed intolayout area902. After placement into the layout, an icon, for example906, may be selected and the action or series of actions to be performed upon activation of that icon may be defined in anactions panel908. Such actions may, for example include transmission of appliance commands910, the specification of such commands being performed by dragging specific actions from a displayeddevice function list914 intoaction panel908; or GUIpage switching actions912, specified by dragging pointers to other GUI pages, e.g.918, from apage tree916 intoaction panel908. In the exemplary embodiment, once the layout is completed and all actions specified to the satisfaction of the user, the edited GUI may be saved as a group of files suitable for use by a slave relay device acting as a server to a requesting client device. It will be appreciated that in accordance with the needs of the device adaptation service(s) of the particular embodiment, the GUI definition may be saved as a single master version suitable for scaling, as a set of several selectable file groups, one for each class of client device to be supported, etc.
• By way of example only,FIG. 10aillustrates such a group offiles1000. As illustrated, this group may comprise an HTML, file600 to be served to the requesting client device together with the resources to support that page, for example, graphics files1010 representing icons to be displayed and tag files1012. Tag files1012 may specify the actions to be performed by a slave relay device when an HTML tag is activated on the client device. In an illustrative embodiment tag files may comprise a series of XML statements to be executed by the operating software of a slave relay device, e.g.,device100. By way of further example only,FIG. 10billustrates an exemplary XML encoding of the tag file “switch_to_abc.irm,” corresponding to theeditor action panel908 ofFIG. 9 and theHTML statement604 ofFIG. 6. The illustrative tag file content includes adefinition1020 of the appliance to which commands are to be directed, alist1022 of the functions to be transmitted, and aspecification1024 of the GUI page to be served the client device upon completion of the command transmission. In summary, when the exemplary slave relay device receives an HTTP “GET” request for “switch_to_abc.irm” from a client, this will result in appliance type “C1376” (e.g., a Motorola cable STB) being commanded to tune to channel “007” (e.g., by transmitting the digit commands “0”, “0” and “7” in sequence) after which the GUI page “tv_controls_html” will be retrieved and served to the requesting client device (with appropriate scaling and/or reformatting if this is enabled).
• The data files which comprise the GUI pages to be supported by the slave relay device may be downloaded directly to it for storage in memory (e.g.,memories302,306), or may be stored on a local (e.g., computer202) or remote (e.g., computer210) server system and accessed on an as needed basis by slave relay devices (e.g.100) for transfer to the client device. In the latter example, the data transfer may take place by having the requested data downloaded to and served from the slave relay station to the client device and/or by having the requested data served directed from the storage source to the client device via the network. Further, it will be appreciated that in some embodiments these data may reside in multiple locations, for example HTML files (e.g., HTML page600) may be stored locally on a slave relay device while resources such graphics files (e.g., button images1010) may be stored on a network-accessible server (e.g.,computers202 or210) and retrieved on an as needed basis by the slave relay device, or even directly by a client device.
• In certain embodiments, it may also be desirable to allow a user to configure appliance control functionality directly on a personal communication device without necessitating the use of a separate editor application as described above. In this regard, it will be appreciated that an HTML, or other markup language generating application or “engine” (such as ActiveX software technology developed by Microsoft Corporation, or that described in U.S. Pat. No. 7,216,298 assigned to Oracle Corporation, which is hereby incorporated by reference herein in its entirety) may be stored on or made available to the slave relay device, or stored on a network-accessible server (e.g.,computers202 or210) and used or retrieved on an as needed basis by the slave relay device, or even directly by a client device. In this way a user may be presented with a generic interface for purposes of setting up her client device to control the desired appliance(s) upon an initial interaction with the engine (e.g., browsing to the IP or host URL of the slave relay device). As described herein, the engine may be configured to read and analyze user agent string information from the client device in order to present a generic interface appropriate for display on the particular requesting client device, and/or to customize various features and functions presented to the user during a setup process or subsequent control based operations. During the setup process a user may interact with the engine to set up individual appliances (e.g.,devices104,106,108, etc) using device type and model number searching, direct code entry from a library of available codes, or a variety of other known universal remote control setup techniques as may be configured in the engine. For each appliance set up via the engine a default interface may be automatically generated and presented to the user for immediate testing and/or operation of appliance commands via the slave relay device. After set up of individual devices a user may save the whole configuration for later customization either on the slave relay device, on a network-accessible server (e.g.,computers202 or210) or even directly on the client device. It will be appreciated that such configuration actions may be completely in lieu of, or may be a prelude to further refinement of the GUI using, for example, an editor application as described previously.
• By way of further example, turning toFIG. 11 there is illustrated a series of steps which in certain embodiments may be performed, for example, betweensteps504 and506 of the flowchart previously presented inFIG. 5. Upon receipt of a request message, the operating software of a slave relay device may atstep1102 examine the request header user agent information in order to identify the requesting client device type. If the client device is determined to be an already configured client at step114, processing continues as previously described in conjunction withFIG. 5. If not, the operating software next checks atstep1106 if the target appliances to be controlled have been identified and set up, i.e., that the appropriate appliance code data and protocols have been identified and are available for use by the operating software. If not, the operating software atstep1108 may interact with the user (e.g., via HTTP and pre-formatted HTML, pages) to obtain appliance identification information. Such information may include for example, appliance types, brand name(s), model number(s), set up codes derived from a printed list or web-based look up site, etc. without limitation. Atstep1110, the obtained appliance identification(s) are submitted to a set-up service. Such a set up service may be part of the operating software ofslave relay device100, or may be an application hosted on a local202 or remote210 computing system, or any combination thereof. The set up service may analyze the submitted appliance identification information and identify to the operating software ofslave relay device100 which appliance code data and protocols are to be used to communicate to each of the appliances. In certain embodiments, if the necessary appliance code data and/or protocol definition are not already present in a pre-programmed library of the slave relay device, these may be downloaded into the slave relay device by the set up service. Once the appliances to be controlled have been identified, at step1112 the user agent and appliance identity information may be submitted to a GUI selection engine, e.g., as described above, which may once again be part of the operating software ofslave relay device100, or may be an application hosted on a local202 or remote210 computing system, or any combination thereof. It will also be appreciated that the set up service and the GUI selection engine may be separate application programs, resident on different computing systems or co-resident on a single system; or may be combined into a single application program, as appropriate for a particular implementation. Based upon the supplied information, the GUI selection engine may select and/or generate appropriate default HTML GUI pages commensurate with the capabilities of the client device and the control functions of the target appliance (for example, a page scaled for the display of the client device providing function keys only for operations that are actually supported by the target appliance). Atstep1114 these pages (or pointers thereto) are identified and stored by the operating software ofslave relay device100, where after they may be used to service HTTP requests from the identified client device. It will be appreciated that alternative embodiments providing similar functionality are also possible: for example, a slave relay device may store only the user-supplied appliance identification information and re-submit this together with the user agent identity every time a request is received, e.g., using a GUI selection engine which re-generates the HTML GUI page(s) for every instance of use.
• In order to guard against unauthorized manipulation of a user's appliances, various security measures may be implemented to limit GUI page access to only authorized clients. These may take the form of, for example, password protection of a slave relay device's master (e.g., “home”) pages, restriction of access to only certain pre-defined client devices (e.g., using MAC or IP address filtering), mutual authentication, or any other suitable method, all as are well known in the art.
• While various concepts have been described in detail, it will be appreciated by those skilled in the art that various modifications and alternatives to those concepts could be developed in light of the overall teachings of the disclosure. For example, while many of the exemplary embodiments above are described in terms of HTP and HTML methodologies, it will be appreciated that other communication and transfer protocols may be used as appropriate. Further, while an exemplary slave relay device communicates with controlled appliances via an IR signal, it will be appreciated that for the purposes of this invention various alternate embodiments of slave relay device may communicate with controlled appliances via any combination of IR, RF and/or hard wired connections. Yet further, it will be appreciated that while the exemplary slave relay devices of the illustrative embodiments are presented as stand alone units, in alternative embodiments the described slave relay device functionality may be incorporated into one or more of the controlled appliances, or accommodated in any other convenient item of furniture or equipment, as appropriate for a particular implementation.
• Further, while described in the context of functional modules and illustrated using block diagram format, it is to be understood that, unless otherwise stated to the contrary, one or more of the described functions and/or features may be integrated in a single physical device and/or a software module, or one or more functions and/or features may be implemented in separate physical devices or software modules. It will also be appreciated that a detailed discussion of the actual implementation of each module is not necessary for an enabling understanding of the invention. Rather, the actual implementation of such modules would be well within the routine skill of an engineer, given the disclosure herein of the attributes, functionality, and inter-relationship of the various functional modules in the system. Therefore, a person skilled in the art, applying ordinary skill, will be able to practice the invention set forth in the claims without undue experimentation. It will be additionally appreciated that the particular concepts disclosed are meant to be illustrative only and not limiting as to the scope of the invention which is to be given the full breadth of the appended claims and any equivalents thereof.
• All patents and published documents cited within this application are hereby incorporated by reference in their entirety.

Claims (20)

What is claimed is:

1. A method for using a relay device; comprising:

receiving by the relay device from an input device via a first wireless communications link a communication that functions to indicate that an activatable link in a graphical user interface of the input device was activated;

using by the relay device the communication to select a file from amongst a plurality of files stored in a memory of the relay device;

using by the relay device a first data as stored in the selected file to select a code data from amongst a plurality of code data stored in the memory of the relay device;

using by the relay device a second data as stored in the selected file to select one or more commands from amongst a plurality of commands of the selected code data; and

using a protocol associated with the selected code data to transmit the selected one or more commands from the relay device to a controllable device via a second communications link.

2. The method as recited inclaim 1, wherein the communication that functions to indicate that the activatable link was activated comprises a file name of the file.

3. The method as recited inclaim 1, wherein the communication that functions to indicate that the activatable link was activated comprises an HTTP protocol request message which includes a file name of the file.

4. The method as recited inclaim 1, wherein the graphical user interface page having the activatable link is provided to the input device by the relay device via the first wireless communications link.

5. The method as recited inclaim 4, wherein the first wireless communications link is a radio frequency protocol communications link.

6. The method as recited inclaim 4, wherein the first wireless communications link is an infrared protocol communications link.

7. The method as recited inclaim 1, wherein the graphical user interface page having the activatable link is provided to the input device by a network server device.

8. The method as recited inclaim 1, wherein the file further comprises instructions that are executable by the relay device.

9. The method as recited inclaim 1, wherein the file is XML encoded.

10. The method as recited inclaim 1, wherein the second communications link comprises a wireless communications link.

11. The method as recited inclaim 1, wherein the second communications link comprises an infrared protocol communications link.

12. A non-transitory, computer readable media having instructions stored thereon, wherein the instructions, when executed by a relay device, cause the relay device to perform steps comprising:

receiving by the relay device from an input device via a first wireless communications link a communication that functions to indicate that an activatable link in a graphical user interface of the input device was activated;

using by the relay device the communication to select a file from amongst a plurality of files stored in a memory of the relay device;

using by the relay device a first data as stored in the selected file to select a code data from amongst a plurality of code data stored in the memory of the relay device;

using by the relay device a second data as stored in the selected file to select one or more commands from amongst a plurality of commands of the selected code data; and

using a protocol associated with the selected code data to transmit the selected one or more commands from the relay device to a controllable device via a second communications link.

13. The non-transitory, computer readable media as recited inclaim 12, wherein the communication that functions to indicate that the activatable link was activated comprises a file name of the file.

14. The non-transitory, computer readable media as recited inclaim 12, wherein the communication that functions to indicate that the activatable link was activated comprises an HTTP protocol request message which includes a file name of the file.

15. The non-transitory, computer readable media as recited inclaim 12, wherein the graphical user interface page having the activatable link is provided to the input device by the relay device via the first wireless communications link.

16. The non-transitory, computer readable media as recited inclaim 15, wherein the first wireless communications link is a radio frequency protocol communications link.

17. The non-transitory, computer readable media method as recited inclaim 15, wherein the first wireless communications link is an infrared protocol communications link.

18. The non-transitory, computer readable media as recited inclaim 12, wherein the graphical user interface page having the activatable link is provided to the input device by a network server device.

19. The non-transitory, computer readable media as recited inclaim 12, wherein the second communications link comprises a wireless communications link.

20. The non-transitory, computer readable media as recited inclaim 12, wherein the second communications link comprises an infrared protocol communications link.

Images