Interface Sockets, Remote Consoles,
and Natural Language Agents

A V2 URC Standards Whitepaper

V1.5 August, 2004

Gregg Vanderheiden Ph.D.
Trace R&D Center,
University of Wisconsin – Madison

Gottfried Zimmermann Ph.D.
Trace R&D Center,
University of Wisconsin – Madison

Shari Trewin Ph.D.
IBM Corporation

Key advantages of products that implement V2: in a nutshell: 2

Abstract 2

Part 1 - Introduction. 2

INCITS/ANSI URC Standard. 2

Targets and URCS. 2

Part 2 - Example User Scenarios 2

Part 3 - Architecture. 2

Major Components of the URC framework. 2

Availability of Simulations 2

For more information: 2

Key advantages of products that implement V2: in a nutshell:

Flexible – the product can be controlled by any V2 URC-compatible user device without that device having prior knowledge of the product, so the product manufacturer does not need to author user interfaces for all possible user devices.

Simpler to use – people can use the same familiar remote control with any device. They can find a remote they like (or a program on their PDA or phone) that has just the controls they like and want to use and be able to use it on any VCR that they encounter anywhere - without ever having to program it.

Even simpler to use – if the person purchases a natural language remote. Again, without programming, the person can simply tell their intelligent agent in their PDA or phone what they want to have happen and the PDA/phone can find the product and carry out the commands. (Note: The ability for remote controls to use natural language is facilitated by the V2 standards, but natural language processes are not included in the standards.)

Provide feedback (to user and remote) – bi-directional communication means that the user and the remote always know the exact state of the product so more intelligent controllers and more informed users are possible even when they are not in the same room as the product.

Provide notifications (to user and remote) – bi-directional communication makes it possible to notify the user about important events, e.g. when the oven has reached the selected temperature, when the laundry is done, etc.

Easy to internationalize – all language specific resources are separate and replaceable. A single product can support remotes in a multitude of languages (both built in and provided by third parties) and support even more with online translation resources.

Standards based – V2 products are based on existing standards that are flexible and robust. They can use Bluetooth, Ethernet, Powerline, and most any other IP network and can work with UPnP, Java/Jini, or any Web protocols based networking platforms.

Cooperative compatible –V2 products can be designed to work together, read and set each other’s data, and support intelligent cross product interactions.

One remote sufficient for all products – use one remote control for all home appliances (TV, VCR, stereo, oven, thermostat, washing machine, etc.). If, however, the user wishes to have a dedicated remote for each product, that's fine too. The user can decide.

Use whatever device is handy – the user can control the product with whatever device is handy. For example, a person could program their home VCR via a dedicated remote control, or their PDA etc (whichever is within reach).

Manufacturer customizable/tunable – in addition to using the generic cross product compatible interfaces, V2 allows manufacturers to implement extremely specific, highly polished user interfaces (e.g. written in Java, Flash, SVG, object code, etc., or in any proprietary language) which work only with their products (if they wish) providing additional packaging and marketing opportunities.

Manufacturers can bring new features to market without notice or hassle – manufacturers can add special functions or new capabilities to their products, and have them instantly work with all existing URCs. And this can be done without having to pre-register the functions or update URCs as would be true of protocols that rely on the central registry of commands.

Future proof – although future proofing is not really attainable, V2 allows systems to be constructed using today’s technologies aiming for the friendliness and versatility of products that can only be achieved with tomorrow's technologies. V2 provides the fundamental underlying architecture and resource framework that can accommodate the need for highly adaptable intelligent natural language agent based control that is now emerging.

Abstract

A new standard has been drafted to enable full functioned remote operation of products. It also allows operation of products through intermediate devices and intelligent agents. The standards build on existing network and communication standards, adding components and capabilities as necessary to allow for user interface descriptions that are standardized, flexible and versatile.

The V2 URC standards are network neutral they work with diverse networking and control technologies including Universal Plug and Play, Java-Jini, etc. The standards describe methods a product can use to provide user interface information for any remote console or artificial agent. This information is sufficient to construct a full-function user interface for the product without any prior knowledge of the product or product type. The methods also allow direct access to the functionality of the product; an individual can execute a specific command without having to walk menus in order to get to it. Entirely visual, entirely audio, or natural language interfaces can all be constructed from the information provided by the product. URC devices with no displays can be used, or URCs can make full use of DTV home theater displays.

The standard also allows companies to project very custom interfaces, specific to a particular device (e.g. a color Palm Pilot) or any URC-capable device of their choice.

Part 1 - Introduction

The vision of a personal controller, a "Universal Remote Console" (URC), that a user can employ to access and control products at home, at work, and in public places may soon be realized. Technologies for wireless connectivity and networked computing are available, providing methods for seamless discovery, controlling and eventing. However, user interfaces of networked products still must be authored separately for each controller platform. Furthermore, many existing user interfaces are not intuitive and easy to understand for many users.

What is needed is a standardized, versatile user interface description for products, a "user interface socket" to which any URC can connect to discover, access and control a remote product. The user interface socket would provide an abstract description of the product's functions, and the URC would build custom-tailored interaction mechanisms based on the description. Thus with only one user interface description diverse URC technologies can be supported, including direct manipulation techniques via desktop computers and PDAs, and voice recognition and natural language technologies employed by PDAs and wearable computers. It is important that the URC provide the necessary technologies for user interaction (e.g. natural language processing), so as not to impose this burden on the product being controlled.

INCITS/ANSI URC Standard

The Universal Remote Console (URC) standards developed by the V2 technical committee of INCITS are focused on providing a standard mechanism for manufacturers to build a “user interface socket” into their products that would allow users to be able to control the products from other devices, including intelligent user agents.

The V2 URC standards build upon and work with other standards such as Universal Plug and Play, Java-Jini, etc. They provide not only a means to control the product remotely, but also all of the information needed to build a remote (alternate) interface to the product.

Based on an abstract user interface description, the URC may employ URC- or user-specific extensions in building specialized user interfaces. Extensions may include new skins or layouts, or modality-specific resources such as images, animations, or audio and video clips. Manufacturers of networked products, manufacturers of URCs and third parties can provide these extensions as supplemental resources, available on the products themselves or on the Internet. This mechanism also provides for easy localization of the user interface to foreign languages and cultures.

Targets and URCS

In this paper, the products being controlled (e.g., coffee pots, alarm clocks, VCRs, thermostats, appliances, etc.) are referred to as “targets”. The devices being used to control the targets (e.g., remote controls, cell phones, PDAs, computers and natural language processing user agents) are referred to as Universal Remote Consoles (URC). They are referred to as Universal Remote “Consoles” rather than Universal Remote “Controls” because they not only provide the ability to control the products, but also the ability to present all of the displays and feedback information provided by the product. Thus, an individual can control a “target” product without being in sensory range or without being anywhere near the target and still have full access to all of its displays, status, etc.

Using the URC standards, a target can present (to any qualified URC) not only its interface sockets (through which it can be controlled) but also sufficient information about the functions of the products, and constraints of its use, to allow the URC to construct a user interface to the target. The URC does not need to know of the existence of a particular product or have any knowledge of particular functions or capabilities in advance. Thus, the URC could discover and present a user with an interface to anything from a coffee pot, to an oscilloscope, to a scanning electron microscope, to an anesthesiology machine, to a VCR, without any previous knowledge of the devices, or without referring to any “registry” of commands or codes. This not only makes the standards very flexible and extensible to any type of product, but also allows manufacturers to add any special functions or new capabilities to their products, and have them instantly work with all URCs. And this can be done without having to pre-register the functions or update URCs as would be true of protocols that rely on the central registry of commands. However, this does not prevent users from having a particular interface that they like to use for VCRs and having it work for all of the VCRs that they encounter.

The V2 URC standards also provide support for the use of intelligent user agents. In addition to providing the information for a browsable interface (e.g., screens of buttons or pull down menus), the interface also provides a flat full functionality listing for the target device. That is, in addition to providing the information needed to construct series of menus, etc., like one would traditionally find on a VCR, it also provides all of the functions in a flat format, so that a person, for example, could find a “clock” functionality, which the individual could set directly without having to navigate menus. Using a natural language interface the person could say, “Set the clock on my VCR to 11:30 pm”. The user agent would be able to do this directly without having to force the user (or itself) to wander through menus, and ‘up’ and ‘down’ button presses, to adjust the parameters.

Use of the V2 URC approach has many advantages and provides manufacturers of target product(s) with a robust, standards-based control mechanism which is stable over time. It allows manufacturers to use simple straightforward Universal Remote Consoles today. It also allows the same products to be controlled by ever increasingly intelligent controllers in the future - without needing to upgrade. This is because the V2 URC standards are designed to allow products to expose their functionality in a simple but rich fashion that gives intelligent controllers the information they need. Members of the household who want very simple controls could use very simple controls with the product. Individuals wanting highly sophisticated controls which provide full access to all of the functions and features could have those. And those who would like to interact with their products using natural language and conversational interaction would be able to use those as they become available. A project is already underway at the University of Wisconsin with some new natural language technologies that could allow this type of control much sooner than expected.

URC standards – versus – traditional remote control standards

Below are a number of functions or capabilities that the V2 URC standards provide that go beyond current universal remote control mechanisms.

Product Display information – Because the URC standards are based on bi-directional IP based communication, the universal remote console is capable of knowing and displaying the complete state of the product.

User Notifications – Again, because of the bi-directional communication of the standards, the user can be notified about important events through the Universal Remote Console. For example, when the oven has reached the selected temperature, or when the microwave oven has completed its operation.

Network Neutral – The V2 URC standards are based on IP transmission of data that does not assume a particular network or protocol. It can work equally well over LAN, wireless Ethernet (WiFi), Bluetooth, HomePlug, etc. One possible approach would be to have all appliances communicate over household wiring so that simply plugging the appliance into the wall would provide both power and network connection.

No User Programming - Because the products expose their functionality and command sets to the URC (e.g., phone, PDA, etc.) the user never has to look up or enter any special codes to tell the URC how to control the target. People can (without programming anything) use a URC to control unknown, unusual, or even one-of-a-kind devices.

Modality Independence – The URC standards do not presume that the URC is operating in any particular modality. Thus, the URC could operate all verbally, all visually or any other fashion that best suits the user at any point in time. The same URC could present an all verbal interface to someone when they are driving, yet, present an all visual interface to someone when they are in a very noisy environment or in a place that requires absolute silence.

Use whatever control device is handy – The user can control the product with whatever device is handy. For example, a person could program their home VCR via their desktop computer upstairs to record a show they are missing. .

Highly Customized Interfaces – Although the target would always present the information to allow URCs to build an interface, the target manufacturer can also provide a very specialized, carefully crafted interface with a particular look and feel as well. They could, for example, provide a custom interface meant to work on any Palm Pilot or any pocket PC device. They could provide a user interface written in Flash or SVG. Or they could provide a user interface that only ran on their own proprietary remote control giving an animated, highly functional and highly product/manufacturer specific interface (while still providing the basic information needed to allow their products to be controllable from any generic V2 URC compatible devices that the individual may have).

Dynamically Upgradeable – If the user has access to the internet it is possible for the manufacturer to update the projected user interfaces of their target devices even if it has been a year or two since the product shipped and was installed in the user’s home. The URC can either use the product descriptive documents that come from the product, or updated documents from a manufacturer specified location.

Multi-Language – The structure of the V2 URC user interface specification documents allows them to be easily localized. Although it may only be possible for a manufacturer to print one set of labels on the front of a product, the V2 URC standard makes it very easy for the manufacturer to provide URC labels in many languages. The target devices can easily have labels in multiple languages stored in the product so that the URC can automatically select one that is preferred by the user. Or network resources can be tapped to call up translations or to translate the labels for languages not supported by the target device itself.

Both Browsable and Direct Control – In addition to the typical interfaces that allow an individual to scroll through menus and screens of information in order to explore the various capabilities of a product, the V2 URC also allows the individual to directly access any functionality that they already know the product may have. This can greatly accelerate the speed with which an individual can control the product and enable the use of intelligent user agents.

Allows (real) natural language and intelligent controllers /agents - The standard supports the provision of additional context, status and local and remote semantic information to support multiple levels of natural language and intelligent controllers – not just voice operated macros. Thus it can support user agents that can converse with the user allowing the user to control products as if they were talking to a person who was familiar with the devices and asking that person to operate the devices for them.

Part 2 - Example User Scenarios

This section provides a number of user scenarios to exemplify some of the ways that these standards might be used.

Language Translation

	A Japanese businessman enters a hotel room in the Netherlands …
	He finds that all the signs and all the products in the room are labeled in Dutch – of which he knows none.
	Pulling out his cell phone which has a V2 URC application on it, he is presented with a list of the various devices in his room, and is able to select and control them in Japanese since his URC presents an interface for each in Japanese. The URC finds Japanese labels on the manufacturers' web resource sites for those devices that do not provide them directly.
	He sets the alarm for 6:30 wake up and adjusts the temperature of the air conditioning via his URC.
	Turning, he is able to control the television using his URC – again in Japanese. “So nice to be able to operate everything in my own language” he reflects as he pulls up CNN and gets captions in Japanese on his URC via a network translation service. “Someday they will integrate these services into Televisions so I can see Japanese captions directly on the TV”.

Choose a Simple Interface and Use it Everywhere

Woman looking at remote control.

“Let’s see now….

I just select ‘TV’ and my new remote control should work with this TV.

Woman sitting on couch in front of television set.

“If this works….. boy will it be nice. I’ll be able to use the same control for any TV

…. and being part of my phone, I’ll always have it with me and handy”

Woman on couch in front of television set that is turned on to TV show.

”It worked!

… and I didn’t have to program it or anything!”

Natural Language - to allow natural interaction with even simple appliances that have no intelligence – but do have a V2 URC interface

	A man is turning in at the end of the day
	He picks up his PDA (which has a V2 URC program in it) and tells it to · set the alarm for 4:30 (he needs to get up early) · set the coffee pot for 4 am (so it is ready for him) · set the VCR to record the news tomorrow at 6 pm on channel 4 (he will not be back from his trip) and · turn on the house alarm.
	As it confirms that it has successfully set the alarm to 4:30 am. He flops in bed … And it continues to confirm that it…. Set the coffee maker to 4 am
	Set the VCR to record channel 4 at 6 pm .
	And turned the house alarm on.
	…. but the man has already fallen asleep

V2 sockets allow products to be sold today that will work with ever increasingly intelligent controllers and natural language URCs that will evolve over time.

	A woman is talking with salesman who is explaining that any of the V2 products will work with any of the V2 Universal Remote Consoles. – including ones that can run on (and are even packaged with) many popular phones.
	The woman is worried about the fact that things go out of date so quickly. She asks him to confirm that if she buys one of the TVs today – that it will work with the newer controllers that she hears will be out next year or so.
	The salesman confirms that as newer controllers, including new natural language speech based controllers come out – the current V2 products will work with them – because the intelligence is in the controllers and not the products.
	That is good enough for her – she is now interested in seeing what he has for her to choose from.

Part 3 - Architecture

The title of the family of V2 URC standards is:

"Protocol to Facilitate Operation of Information and Electronic Products through Remote and Alternative Interfaces and Intelligent Agents"

The first is the URC standard, describing the overall concepts and framework:

Universal Remote Console Standard (ANSI/INCITS 389)
- Specifies the URC framework and technical components of the standard. This should be the first document read by those unfamiliar with the URC standard and its scope. This document provides requirements for Targets, URCs and the network that connects them.

There are four additional standards which complement the URC standard, yielding a set of 5 standards.

User Interface Socket Description Standard (ANSI/INCITS 390)
- Describes the User Interface Socket Description component of the URC Portal. A user interface socket description represents the functionality and state of a Target in a machine interpretable manner

Presentation Template Standard (ANSI/INCITS 391)
- Specifies a language for providing a Presentation Template. A Presentation Template is a modality-independent scaffold for a user interface that provides the necessary structure and hints to build a browsable user interface.

Target Properties Sheet Standard (ANSI/INCITS 392)
- Describes the Target Properties Sheet component of the Target. A Target Properties Sheet (TPS) is an XML document that provides the information needed by a URC to connect to the Target for a control session.

Resource Description Standard (ANSI/INCITS 393)
- Specifies resources and resource descriptions for user interface components that are used in building concrete user interfaces, including labels, help texts, access keys and keywords.

Major Components of the URC framework

The URC architecture can be thought of as comprising four major components and two networks.

The Universal Remote Console (URC)
The Target
Supplemental User Interface Implementation Descriptions (UIIDs)
Supplemental Resources

The two networks are

Target-URC Network (TUN) - between the URC and the Target (required)
Resource-URC Network (RUN) – between the URC and sources of additional resources

This set of standards specifies communications between a Target product that a user wishes to access and operate, and a URC. The URC presents the user with a remote user interface through which they can discover, select, access and operate the Target. The URC is software that is typically hosted on the user's physical device, but a distributed approach is also possible.

Communications between the Target and URC take place over a network, the Target-URC Network. This standard does not specify the network protocol to be used, and a Target or URC may support any number of appropriate connection protocols. These protocols are used to provide discovery of Targets, and to establish and maintain control sessions between URCs and Targets. Targets and URCs access the Target-URC Network through Target-URC Network Links. Targets support discovery by providing essential information in a Target Properties Sheet.

Each Target provides a Portal, or set of Portals, through which it can be controlled. Each Portal contains documents that describe the interface of the Target, as viewed through that Portal. These documents are used by the URC to find or generate an appropriate user interface, given the functionality of the Target, the nature of the URC device, and the user's interaction preferences. Each Portal has a User Interface Socket through which a URC can access the Target's state and control it.

The User Interface Socket Description is a Portal document that describes the Portal's Socket in a machine interpretable manner.

Interaction between a Target and a URC consists of a discovery phase and an optional control phase. The discovery phase is initialized by the URC to locate and identify all available Targets and their URC Portals. The control phase is the time period during which a Target and a URC initiate, maintain and terminate a control session. A control session is a connection between the URC and a Target's Portal for the purpose of the URC controlling a functional unit of the Target via the Portal's Socket. When multiple URCs are connected to the same Portal, each has an independent control session, although Target state values may be shared.

Another type of Portal document is a User Interface Implementation Description (UIID). A UIID is a description of an interface for a particular Portal and its Socket. This description may take an abstract or concrete form, and may be very general or specific to a given URC device class, user profile and task. The UIIDs provide a mechanism by which a manufacturer can provide tuned interfaces for their Target Portals which are predefined and optimized to work on particular URCs, for example Pocket PCs or Palm-based PDAs. UIIDs can be provided by a Target or by external sources.

This standard defines one, very general, form of UIID - the Presentation Template. A Presentation Template provides general hints as to how to build a usable user interface for the Portal and its Socket, and does not assume any particular class of URC. One Presentation Template that is implemented using a defined set of elements is required. It is the only required UIID.

Socket Descriptions and UIIDs are documents that are independent of any natural language. In order to render their content to a user, Resources are provided (by the Target and optionally external to it) in the form of Resource Sheets. A Resource is an identifiable object within a user interface that is used as an atomic entity in the construction of a concrete user interface. Resources include labels, help text, access keys and keywords. A Resource may be of any form and modality, including text, images, sounds, animations and video clips.

A URC may take advantage of Resources from the Target or from a Resource Service. These are referred to as Target Resources and Supplemental Resources respectively. Supplemental Resources can be used by a URC to replace, to supplement, or to help interpret or translate, any Resources provided by a Target.

In general, Resources for building user interfaces may be obtained from the Target, stored on the URC, or gathered from the Internet. A URC uses the Target-URC Network to retrieve Target Resources. It may use any form of networking or other mechanism to access external Resources via a Resource-URC Network. This standard does not specify the mechanism by which a URC accesses Resources external to the Target.

Note that only 3 of the 6 major components are actually needed for a URC to function. The rest are optional. The three essential components are:

The URC,
The Target, and
The Target-URC Network

The optional ones are

Supplemental User Interface Implementation Descriptions (UIIDs)
Supplemental Resources
Resource-URC Network (RUN) – between the URC and sources of additional resources

Note: Please see the actual standards for more specific technical details.

Availability of Simulations

Simulations of the V2 URC framework are available and new ones are under development. The latest in simulations can always be found at http://www.myurc.com/.

Figure 1 shows one simulation which has been developed by the Trace Center at the University of Wisconsin that allows you to directly view the operation of the standard and its interaction with a number of simulated products including a television set, thermostat, lamp, programmable coffee pot and alarm clock. This simulation shows a relatively simple user interface controlling these products, and it is meant primarily to familiarize the viewers with the standards, the various descriptions and resources and how the messaging works. Users can also edit the descriptions and resources and observe the results.

Picture of V2 simulation which is described in the figure caption.

Figure 2: The left window is an image of an iPAQ PDA with a URC program running on it. Multiple URCs can be invoked simultaneously as desired for the simulation. On the right are three overlapping windows depicting different target simulations. Each simulation includes a table with all of the socket elements and their statuses. To the left of the table is a list showing all of the URCs that are connected to the target at any time. Below these is a scrolling field that contains all of the messages that pass back and forth between the URC and the Target.