Classifications

• • 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/28—Timers or timing mechanisms used in protocols
• • 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/24—Negotiation of communication capabilities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
  • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
  • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
  • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
  • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
• • 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/14—Session management

Definitions

• the invention relates to a method and apparatus for device control.
• the mvention relates to a method for control of one device through another device with which a user can interact, and to apparatus with which the method can be employed.
• a remote control unit is frequently used for control of a television.
• the remote control unit is convement for the user to use: it is portable, while the user interface attached to the television itself is less convement to use (as it is fixed at the television).
• Computers are similarly often used to control other equipment, as the user interface of a computer is well understood by the user and in many cases interaction between the equipment and the computer is required anyway (for example, if data is to be passed to or received from the equipment).
• a va ⁇ ety of approaches are provided for control of equipment by computers m the different programming options for different computer operating systems.
• devices In Microsoft Wmdows, for example, devices must either conform to a pre-defined gene ⁇ c model (for which an API is provided) under which a set of control commands deemed approp ⁇ ate to the device class must be understood, or else must be supplied with a device-specific control program, or d ⁇ ver, which must be loaded into the computer before control can take place.
• a TV API might have function calls to turn the TV on or off, change the channel to a specific set of values and set the volume, all televisions being able to offer those and only those controls through the API.
• X-Windows which is a GUI built (typically) on Unix and can be used for control of other devices
• X- Wmdows recognises a va ⁇ ety of input devices, such as mouse and keyboard. It is adapted to provide applications with events which desc ⁇ be what is happening to those input devices (e.g. right mouse button pressed at co-ordinate 345,678). The application then decides how to interpret this action (e.g. turn TV on).
• the control program therefore mvolves both the functionality of the controlled device and user interface features of the controlling device.
• the mvention provides m a first aspect a method for tiie control of a controlled device by means of a controlling device, compnsmg. establishment of a means for transmitting signals between the controlling device and the controlled device; provision by the controlled device of a set of possible parameter choices and information identifymg said possible parameter choices and transmission thereof to the controlling device; display at the controlling device of the set of possible parameter choices and of information identifymg possible parameter choices to enable user selection of a set of actual parameter choices with a user selection means; transmission of the set of actual parameter choices to the controlled device; and modification of operational parameters of the controlled device m accordance with the set of actual parameter choices; wherem the set of possible parameter choices and set of actual parameter choices are provided in a form mdependent of the user selection means.
• the controlled device provides to the controllmg device only a set of choices and mformation relating to those choices, that leaves the controllmg device free to display the set of choices and the information relatmg to them in any way that it chooses, or that is convement for it.
• This arrangement divides responsibility for the process of control and device operation ideally between the controlled device and the controllmg device.
• the functionality of the controlled device, and how that functionality may be changed, only needs to be understood by the controlled device instead.
• the controllmg device needs to understand nothing of the functionahty of the controlled device, but is instead left to determine how it should display the available parameter choices: this allows the display options to be matched to the capabilities of the controllmg device.
• the mvention provides an information handling device adapted for the function of a controllmg device in the method mdicated above, the information handling device compnsmg: means for communication of mformation with a controlled device; user interface means for displaying information to a user and for returning values denved from a user input; and means for presentmg the set of possible parameter choices and associated mformation received from the controlled device through the user interface means, and for returning the set of actual parameter choices from the user interface means to the controlled device.
• the mvention provides a control script to enable provision by a controlled device of a set of possible parameter choices and mformation identifymg said possible parameter choices and transmission thereof to a controllmg device, compnsmg for each parameter the possible parameter choices, a type for that parameter, and user interpretable parameter mformation.
• Figure 1 shows a schematic representation of a control arrangement to which the present mvention is applicable
• Figure 2 indicates schematically steps followed m control processes accordmg to aspects of the mvention
• Figure 3 shows a device environment for which aspects of the mvention can be employed
• Figure 4 shows the creation of a surface impression on one device from the surface expression of another
• Figure 5 shows the components of the JetSend architecture and their logical relationship to each other
• Figures 6a to 6j show the use of messages of the JetSend mteraction protocol m exchange of information between appliances
• Figure 7 shows a JetSend policy for provision of a virtual control panel at a controllmg device
• Figure 8 shows a JetSend policy for user control of a controlled device usmg a virtual control panel
• Figure 9 shows a minimal user interface supported by the Control Sc ⁇ pt encodmg
• Figures 10a and 10b show Wmdows user interfaces automatically generated from Control Sc ⁇ pt encodings
• Figures 1 la and 1 lb show user interfaces generated from HTML encodmgs; and Figure 12 shows a fax machine user interface which can be generated with an encodmg which defines a set of user interface controls.
• a gene ⁇ c implementation is shown schematically m Figures 1 and 2 and desc ⁇ bed m detail below.
• Controlled device 11 that performs a device function in accordance with certain user- determinable parameters.
• Controlled device 11 could be a household appliance such as a television, a music system, or a washing machine, an office appliance such as a printer or a scanner, another item of machmery or substantially any device capable of external control.
• controllmg device 12 which acts to provide control information to controlled device 11.
• controllmg device 12 could be a remote controller, a personal computer, or substantially any other device with a user interface.
• controllmg device 12 There must also be a mechanism for two-way communication between controllmg device 12 and controlled device 11- both a means for exchanging messages between the two devices and a protocol such that meamngfiil messages can be exchanged - again, substantially any medium and associated protocol can be used.
• a user 13 interacts with the controllmg device 12.
• Step 21 consists of the provision by the controlled device 11 of a set of possible parameter choices to the controllmg device 12.
• Such choices may be a binary choice such as " ON OR OFF ", a selection from a senes of values such as " 1, 2, 3, 4, 5 " or " 'Parsley', 'Sage', 'Rosemary' 'Thyme' " a selection from a range such as " an integer value between 1 and 12 ".
• Tokens need not be text strings: m approp ⁇ ate implementations they could be, for example, images or icons. Essentially any defined set of choices is possible for this purpose. There must also be provided information identifymg said possible parameter choices.
• a label such as “Volume” could be provided, with an associated parameter choice of " an integer value between 1 and 12 ", or a label of "Recording” with an associated parameter choice of " ON OR OFF "
• This label serves a dual function: it is associated by controlled device 11 with a specific parameter for determining its function, so controlled device 11 is adapted to change its state to reflect a specific choice for that parameter - it is also sufficiently desc ⁇ ptive of the parameter that the user 13, when provided with the label mformation, will be capable of making an appropnate choice for the associated parameter. It however need have no meaning for controllmg device 12 - for controllmg device 12 the label is merely a label. Controllmg device 12 need not be adapted m any way to the function of controlled device 11.
• Step 22 consists of the display at the controllmg device 12 of the set of possible parameter choices and of mformation identifymg the possible parameter choices. This requires presentation to the user of information identifymg each parameter choice available: this may mvolve simple presentation to the user of the label attached to a given parameter choice, together with an indication of the possible selections a user could make for that parameter choice.
• the controllmg device may have a display mdicatmg the label "Volume”, with a user operable dial or slider next to it showing values of 1 to 12, and a button which can be "pressed” by the user labelled "Recording"
• Step 23 is the selection by the user of a set of actual parameter choices. This is done by whatever means is approp ⁇ ate to the user mterface of controllmg device 12.
• this user mterface ensures that the user is only able to make a choice for a given parameter that is among those provided by controlled device 11.
• the user makes selections on the basis of the mformation provided by controlled device 11 and the user's own knowledge and understanding Controllmg device 12 has no role m the selection of choices for any of these parameters.
• Step 24 is the transmission of the set of actual parameter choices made by the user 13 from the controllmg device to the controlled device 11.
• This set of actual parameter choices must be provided in such a way that the controlled device can determine to which parameter each parameter choice relates (for example, by attachment of the approp ⁇ ate label to each parameter choice)
• Step 25 is the modification of operational parameters of the controlled device 11 in accordance with the set of actual parameter choices.
• controllmg device 12 The function of controllmg device 12 is thus limited to exchanging mformation with controlled device 11 and enabling user mteraction such that the user can control the controlled device 11, and these functions operate m the same way irrespective of the nature or functionality of the controlled device 11
• the controllmg device 12 does have control of the mechanisms by which mformation is displayed to the user and by which the user makes his or her choices: consequently, choices can be made appropnate to the ⁇ chness of the user mterface of controllmg device 12.
• Control may require repeatmg of one or more of these steps. Steps 23 to 25 could be repeated over time, as the user decides to change the operation of the controlled device 11. If there is a hierarchical control structure (such that selection of one parameter choice requires the making of another parameter choice), steps 21 to 25 may need repeatmg as a sequence one or more tunes before operation of the device function of controlled device 11.
• User 13 may be replaced by another device, or even controllmg device 12 m another aspect of its operation (for example, a separate program). All that is required of user 13 is the capacity to make a selection for the parameters mdicated by controlled device 11 accordmg to the mformation presented by controlled device 11. This could be achieved by a program adapted to recognise labels attached to parameters, or information made in those labels, and to return a parameter choice from the selection available based on those labels.
• controllmg device 12 It may be necessary for this "user" 13 to have more or less detailed knowledge of the function of controlled device 11, but communication between controllmg device 12 and controlled device 11 still does not depend on the function of controlled device 11, and neither does presentation of parameter choices and associated mformation by controllmg device 12 to user 13 (even if user 13 is a program mtemal to controllmg device 12!
• a useful and practical instance of a non-human user is a control program which comp ⁇ ses a predetermined set of preferred user choices for a particular virtual control panel. The effect of the control program is that whenever controllmg device 12 "sees" that virtual control panel, the program will run so as to return these preferred choices.
• Such a control program is analagous to a macro of a conventional word processmg or spreadsheet program.
• controllmg device 12 is adapted as a universal remote controller, provided with a well featured user mterface compnsmg a display and user means to identify choices (one or more of buttons, a touch screen with a stylus, a keypad etc.) and a communication means (for example an infra-red tranceiver) and means to interpret messages received and provide mformation as messages for transmission through the communication means.
• a communication means for example an infra-red tranceiver
• Such a device could be, say, a handheld controller useful for mteractmg with substantially any controllable device adapted to communicate with it, as the controllmg device itself need have no knowledge of, or adaption to, the function of the controlled device.
• JetSend is an architecture accordmg to which devices transfer information directly without need for intermedia ⁇ es where network considerations allow, mformation bemg transferred accordmg to a common protocol whatever it relates to Devices have no need to have knowledge of the functionality of other devices.
• FIG. 3 illustrates the environment in which JetSend devices operate.
• a network 341 of some kind (m the broadest sense of means to enable communication between devices) exists between devices such as a printer 342, a personal computer 343, and a scanner 344
• Each of these devices must possess a processor 346 of some land, together of course with a connection means 345 to allow mterface with the network 341. It is necessary m this implementation for each of the devices to have some measure of processmg capacity, as such capacity is necessary for processes integral to JetSend.
• the JetSend architecture can be employed effectively for communication of mformation between one device and another. This has been discussed in other applications of Hewlett-Packard Company, in particular Bntish Patent Application No. 9707551.9 filed on 15 April 1997 and entitled “Method of Passmg Information” and US Patent Application Se ⁇ al No. 60/054,047 filed on 18 July 1997 and entitled “HP JetSend Protocol Specification” and subsequent applications m the Umted States of Amenca and elsewhere (entitled “Method and Apparatus for Device Interaction by Protocol” and “Method and Apparatus for Device Interaction by Format") claiming p ⁇ o ⁇ ty therefrom, the contents of these applications bemg incorporated by reference herem.
• the present mvention can readily be applied to the JetSend architecture and protocols to achieve particularly effective control of one device by another.
• the basic prmciples and elements of the JetSend architecture are discussed b ⁇ efly below, and then the application of the present mvention m the context of relevant specific elements of the JetSend architecture is discussed m more detail below
• a surface is a representation of some aspect of internal state possessed by a device The representation is umversal, and is not determmed by the functions performed by the device.
• a surface m this context is analagous to the surface provided by a physical object (such as a telephone, or a bnc ).
• the way m which the object operates is determmed by how the "functional" parts of the object connect to the surface, but the surface itself can be desc ⁇ bed m a simple umversal way, irrespective of function, and provides the medium through which the object is connectable to other physical ob j ects m the world - the nature of the connection between physical objects bemg mdependent of any device function.
• the surface is the fundamental unit of mformation exchange, and images, documents, status messages, device labels and the like are all transferred through use of one or more surfaces.
• a surface consists of a number of elements: descnption, content, properties and class - these will be discussed further below.
• the surface mteraction model defines mechanisms for creating, sharmg, modifying and deleting surfaces. Only a fixed number of generic operations can be performed on a surface, usmg the messages defined by the JetSend Interaction Protocol (JIP), which will be discussed further below
• JIP JetSend Interaction Protocol
• the ongmal copy of a surface is here termed an expression. There is one expression mvolved m any surface mteraction. Devices that have mformation to share with other devices create one or more expressions to represent that information.
• Surface expressions can be impressed on other devices. This creates an impression of that surface - also known as sharing the surface. Impressions are copies of other device's expressions, and connections are maintained between the devices to ensure that impressions are up-to-date with their correspondmg expression.
• two devices will share several surfaces at a given time; surfaces that represent the elements of a job, status mformation from each device, secu ⁇ ty mformation, and so forth.
• Figure 4 shows how an expression 1 on one device (Device A) is shared with another device (Device B), thereby creatmg a new impression 2.
• the same expression can be impressed multiple times on multiple devices. This creates multiple impressions of the same surface expression. When the expression changes, or is deleted, all impressions will be notified.
• a surface comp ⁇ ses a descnption of the surface, and the content contained within the surface.
• the distinction is fundamental to JetSend and of significance m aspects of the present mvention.
• the surface descnption establishes the full range of possible forms m which information associated with a surface (this mformation bemg provided as surface content data) can be shared with another device.
• the descnption consists of a data format hierarchy, and can be represented as a tree structure with a number of nodes each representmg a definable aspect of the data format (refe ⁇ ed to as an att ⁇ bute, and discussed m greater detail elsewhere).
• a specific data format for the information associated with the surface is a path through this tree structure from a root node down to a terminal node (a leaf node of the tree). Such specific paths are reached through a process of negotiation.
• the process of negotiation comp ⁇ ses the surface owner sharing the surface descnption, or a part of the surface descnption, with another device. The other device then chooses the options it prefers (generally such options will be selected so that the receiving device can use its own functionality in the ⁇ chest manner available given the choices offered, but this is essentially a matter for the designer of any given device) and this process continues until a specific path, and thus a specific data format, is chosen.
• the surface content is the mformation associated with the surface, and is provided in a format determmed by negotiation as mdicated above.
• the content data can be provided m all the formats mdicated by the data format hierarchy embodied in the surface descnption, but for a given surface mteraction will generally only be provided m one of the formats available.
• Content data need not exist pnor to completion of the negotiation: for some or all of the choices m the data format hierarchy the data may only be generated after the format choice is known. Alternatively, for some choices the content data may be provided directly together with the descnpnon identifymg a particular pomt in the data format hierarchy as a part of the negotiation process (so no separate step of provision of content is required for that format choice). This is termed providmg content data inline.
• a surface descnption can also conta references to other surfaces. These surfaces are known as subsurfaces (or child surfaces) and they must be requested separately from the owner of the parent surface. Each sub-surface contam its own descnption and content, mdependent of its parent.
• a surface reference, or a surface name is simply an ASCII string - like a URL. All surfaces are identified by their name, and may belong to a particular class All surfaces possess a class. Class is a property mdicatmg the purpose for which the surface is used: m the present implementation, each surface must have one, and only one, class. Specific rules exist, or may be devised, for use of surfaces of a particular class. Classes are used particularly in the context of specific policies. Where a particular class of surface plays a fundamental role m execution of a given policy, surfaces of that class are termed "well-known surfaces" for that policy. Policies applicable to control mformation are discussed further below
• a policy, or interaction policy is a set of conventions for use of gene ⁇ c surface interactions to achieve a particular task.
• the advantage of using a policy for a particular task is that it enables all JetSend devices adapted to perform, or require another device to perform, the particular task to mteract successfully and in a predictable way with other devices m order to achieve that particular task. This does not exclude the possibility of, for example, a pair of devices adapted to perform such a task m a different way not open to other JetSend devices usmg a different class of surface to do so However, it is desirable that such devices still support the relevant JetSend policy so that they can achieve this task with other JetSend devices too.
• E-mate ⁇ al a term corned as a shortened version of "electronic matenal" is the form taken by mformation through which surfaces are expressed and shared. It comp ⁇ ses descnption and content.
• the descnption m dicates a hierarchy of choices of format m which the associated content data can be provided.
• the content is the data associated with the surface itself.
• the descnption m dicates the ways m which the data can be presented, whereas the content is the mformation itself, presented m a form chosen to be suitable for the device sending it and the device receiving it.
• E-mate ⁇ al is not a file format.
• E-mate ⁇ al defines the format of the data that devices exchange, but it does not define how devices process or store that data. Devices that consume e-matenal do so on a manner that is specific to that device. For example, a receiving device such as a printer will process e-mate ⁇ al differently than a receivmg device such as a PC.
• An encodmg is an e-mate ⁇ al representation of a fundamental form m which mformation can be presented in the world.
• a specific encodmg for e-mate ⁇ al used m a control mteraction.
• An attribute is a feature of a piece of e-mate ⁇ al that is defined m the e-matenal descnption (or defined for the piece of e-matenal after the completion of the negotiation process).
• each node m the data format hierarchy provided m the e-matenal descnption represents an att ⁇ bute. From this equivalence between nodes and attributes there is de ⁇ ved the concept of an "att ⁇ bute level": essentially, an att ⁇ bute level is shared by all nodes equally distant from the root node of the data format hierarchy.
• Attnbutes comp ⁇ se a quality that can be provided for the e-matenal content, and a choice or value for that quality, and the choice or value may itself represent a further att ⁇ bute (a quality requiring a choice or value).
• the quality itself is represented by an att ⁇ bute name
• Att ⁇ bute names are keywords, for which the available values or choices are predefined, so the options offered m a given surface descnption for a given keyword must be some selection from these predefined choices. For different encodmgs, certain attributes will be required, others will be optional, and others not used at all.
• E-matenal thus expresses the encodmg choices of a surface with a number of att ⁇ bute-value pairs arranged m a hierarchy. All surface descriptions contam the attribute vEncoding (all att ⁇ bute and value names are prefixed with a lower case v) As mdicated above, this determines the overall encodmg of the surface - for example, if it is control information, vEncoding will be vControl. Each encodmg has a number of standard att ⁇ bute-value pairs associated with it. Some of these attnbutes can also contam choices. In fact, the owner of the surface can express quite complex choices by addmg options to many of the attnbutes m the surface descnption
• FIG. 5 identifies the components of the JetSend architecture and their logical relationships to each other This is followed by an overview of each of the components. Details for each component are provided at a later pomt. It should be noted that Figure 5 is not an implementation diagram. It shows the relationship between the protocol, not between software components. Actual implementations can have similar components, or combme the implementation of multiple protocols mto a smgle module.
• JetSend architecture is applicable mdependent of transport . JetSend devices can address each other directly over any bi-directional transport 36 usmg unique addressing. It is necessary for the transport to be reliable, therefore for an unreliable transport such as UDP, a further protocol layer must be added to make transmissions over the transport reliable (a further protocol here termed Reliable Message Transport Protocol (RMTP) 37 is used for this purpose).
• RMTP Reliable Message Transport Protocol
• Possible transports mclude TCP IP, SPX/IPX, IrDA, IEEE 1284, IEEE 1394, and others
• a device can implement one or more transports, allowing it to communicate with other devices usmg those same transports
• JetSend appliances Communication between JetSend appliances occurs usmg a number of layered protocols, as can be seen from Figure 5. These layers are similar to most networkmg systems, where each protocol layer communicates with the equivalent layer m the other device.
• the layers that compnse the JetSend protocol are the Interaction Policies 35, the Interaction Protocol 33 and the Session Protocol 34
• the RMTP Protocol 37 is not stnctly a part of JetSend, but rather a protocol to allow use of transport protocols which are not both reliable and ordered.
• the policies have been discussed bnefly above and will be discussed further m the context of control, as will be the mteraction protocol which contains messages for requesting and transferring surface descnptions, transferring content data for a surface, and updating surfaces In conjunction with E-matenal, this provides the mechanism for negotiating data types between devices.
• the session protocol defines messages for setting up sessions and channels between two devices.
• a session manages the establishment and termination of data transport between the two JetSend entities. It can create logical channels within that context for commimications. All these interactions take place over whatever transport is provided by the transport layer below.
• JSP is also used m gateways between JetSend and non- JetSend devices.
• RMTP provides the reliability service for that channel.
• RMTP is a reliable, sequenced delivery protocol.
• RMTP is not transport specific, and a smgle mstance of it can maintain connections through all of the transport stacks simultaneously
• the Device Code is the term used for the logic needed to he the JetSend protocols mto an actual device.
• the Device Code 31 m Figure 3 can exist m any device that is capable of either producing or consuming mformation. Typical producing devices are scanners and PC applications Typical consumers are printers and PC viewers A device must be able to convert between the device specific information/data formats and the e-mate ⁇ al used by the JetSend protocols.
• JIP JetSend Interaction Protocol
• the JIP is made up of a small number of messages that allow any number of devices to share pieces of mformation termed surfaces accordmg to the surface exchange model.
• the owner's copy is referred to as the expression of the surface, and the owner itself is known as the expressive device. All other copies of the surface are referred to as impressions, and the devices holding them are called impressive devices.
• the messages provided by the JIP allow the expressive device to create and destroy expressions, the impressive devices to destroy impressions they hold, and any device to modify the ongmal surface expression.
• DescnptionRequestMsg (Descnption Request) - allows a device to request the descnption for a surface it has an impression of
• ContentRequestMsg (Content Request) - allows an impressive device to request some content data from the expressive device • ContentReplyMsg (Content Data) - transmits some content data from the expressive device to an impressive device m response to a content request: there may be a sequence of these messages m response to a content request, and this message is also used to reject a content request
• a surface has a number of attributes. They are a name, an identifier, a class, a set of properties, a descnption, some content data and a version.
• the name is a NULL terminated ASCII string.
• the identifier is allocated to each surface and uniquely identifies it m the JIP.
• the class is used to determme the purpose of the surface.
• the set of properties controls what JIP messages an expressive device will respond to.
• the descnption contams a descnption of the formats the data is available m, or which the expressive device is willing to provide.
• the content data contams the actual bytes of the mformation itself.
• the version is used by the change mechanism so expressive and impressive devices know which version of a surface a change relates to.
• a typical mteraction proceeds as follows. First, the device with information to transfer, which will be the expressive device, creates an expression. To do this it needs to create a name, allocate a umque identifier, create a set of properties, and create a descnption. At this pomt it does not need to create any content data, although it must be able to produce the content desc ⁇ bed m the surface descnption.
• the expressive device uses these attnbutes and attempts to create impressions of this surface by sendmg a SurfaceMsg to the target device or devices.
• SurfaceMsgs may be sent out unsolicited or they may be sent m response to an earlier SurfaceRequestMsg received from another device.
• m order to create an impression usmg the SurfaceMsg the expressive device must have a "target surface" on which to "impress" the expression.
• this target-surface identifier can be found m the SurfaceRequestMsg. If, however, the expressive device is creating an unsolicited impression, the target-surface identifier can be that of an existing impression, m which case the expression must already exist, or it may be set to the "default target” identifier.
• the default target identifier is sometimes referred too as the "work surface".
• the existence of such a default is important for proper implementation of JIP. Otherwise, there is a bootstrap problem when an expressive device is first sendmg a message to an impressive device: the expressive device does not know where to create an impression on the impressive device (of which it has no knowledge at this pomt), and the impressive device cannot conveniently tell the expressive device (without sending some kmd of global message) as it is not aware that the expressive device wishes to create an impression.
• the solution is the existence for all devices accepting impressions of a default or work surface with a default target identifier (m this implementation the default target identifier has been set at 1). This enables any expressive device to create an impression on an impressive device by setting the target identifier field to 1.
• the impressive device can then enter mto communication with the expressive device (for example, with a SurfaceRequestMsg message requestmg impressions to a new target surface).
• Figure 6a is essentially similar to Figure 4, but is provided as Figure 6a for convenience
• An expressive device wishes to create an unrequested impression. First, a surface expression 121 is created. This is then impressed on the impressive device with SurfaceMsg and an impression 122 of the surface exists at the impressive device.
• An expressive device creates a surface expression for mformation that it wishes to exchange with other appliances.
• the expression already exists before it is requested, but this is not necessa ⁇ ly the case (for example, child surfaces may not m some cases be created until they are actually requested).
• the expressive device receives a request for a surface impression m a SurfaceRequestMsg from the impressive device, and m response attempts to create the impression with a SurfaceMsg.
• the end result is as in Example 1, with an impression 122 created at the impressive device.
• An expressive device creates a surface expression and attempts to create an unrequested impression on an impressive device, as m Example 1.
• the impression 122 is created, but is then immediately released 129 with a SurfaceReleaseMsg from the impressive device to the expressive device.
• the end state is with an expression 121 of the surface at the expressive device, but with no impression of the surface at the impressive device.
• an unrequested impression 122 is successfully impressed on the impressive device.
• the impressive device then can use the descnption in the impression 122 to determme what action to take next.
• the surface descnption contained m the onginal SurfaceMsg is not complete.
• the impressive device can then request more mformation from the expressive device with a DescnptionRequestMsg message.
• the expressive device replies to the DescnptionRequestMsg with a Desc ⁇ ptionReplyMsg, which contains the further surface description.
• a surface descnption may contam reference to sub-surfaces, or child-surfaces, of the top-level surface (for example e-material encoded as an association will in practice always contam child surfaces.
• Example 5 relates to a surface A which has a child surface Al.
• An expression 121, 123 of each surface is provided at the expressive device (alternatively, only an expression 121 of surface A may be provided at this pomt).
• Surface A is then impressed on the impressive device with a SurfaceMsg.
• the impressive device may then request an impression of the child surface Al from the expressive device with a SurfaceRequestMsg.
• This request can be rejected, or accepted, m which latter case the expressive device sends a further SurfaceMsg (after first creatmg an expression of child surface Al if such an expression does not already exist).
• the end state is with an expression 121 of surface A and an expression 123 of child surface Al at the expressive device, and conespondmg impressions 122, 124 of surface A and child surface Al at the impressive device.
• the impressive device may request content with a ContentRequestMsg .
• the expressive device may reject the request or provide content 125 m the format requested.
• This content may be sent as a ContentReplyMsg message (as here), a se ⁇ es of ContentReplyMsg messages, or through another means such as a stream.
• An expressive device can itself delete an expression 128 It does this by sendmg a SurfaceDeleteMsg to all impressive devices which have an unpression 122 of the ongmal expression 121: the message mdicates mat the expression has been deleted, and the expressmg device will then ignore any messages relating to the deleted expression surface.
• the properties of an expression surface may be set so that the impressive device may or may not be able to change the expression surface (the expressive device can always do this).
• Figure 6 ⁇ shows a change of expression surface 126 by the expressive device.
• the change of expression surface is reflected by the sendmg of a SurfaceChangeMsg message from the expressive device to all impressive devices to indicate that there has been a change to the ongmal expression . This will be followed, typically, by new content requests, and possibly even new descnption requests
• the impressive device requests a change to the ongmal expression. Again, this is done by means of a SurfaceChangeMsg. This can be either allowed or rejected by the expressive device. If the change is accepted, the expressive device sends a further SurfaceChangeMsg to all impressive devices confirming the change to the requesting unpressive device and notifying the remaining impressive devices. If the change is rejected, the expressive device notifies the requesting impressive device that the request failed.
• a SurfaceChangeMsg This can be either allowed or rejected by the expressive device. If the change is accepted, the expressive device sends a further SurfaceChangeMsg to all impressive devices confirming the change to the requesting unpressive device and notifying the remaining impressive devices. If the change is rejected, the expressive device notifies the requesting impressive device that the request failed.
• a requesting impressive device has successfully requested a change to the expression, it wdl generally not need to request updated content (though other impressive devices may well need to do so). This is because the impressive device will normally be able to update its own content based on the descnption change that it asked of the expressive device.
• JIP runs over the JetSend Session Protocol (JSP).
• JSP JetSend Session Protocol
• the JSP manages all aspects of a session between two devices mcludmg creating and deleting sessions as well as decidmg when a session has become unusable.
• the JSP also provides access to the basic addressing, reliable message transport protocols, and any other transport protocols used by the JIP.
• JSP is discussed m detail elsewhere in other documents incorporated by reference or otherwise publicly available. The skilled man will also understand the transport requirements for a protocol of this type.
• This message is used m three situations' first to initiate a transfer of a surface from the expressive device to another device. Secondly it is used as the response to a SurfaceRequestMsg from another device. Thirdly it is used to reject a SurfaceMsg from an expressive device. A status field- is set to indicate which interpretation is to be used.
• the sendmg device When this message is used either to initiate a surface transfer or as a response to a surface request, the sendmg device creates an entry m its surface table, so the impressive device can be notified of any changes.
• the destination On receipt of the message, if the destination chooses to accept the impression, it creates an entry in its surface table associating the unpression with the expression. This allows it to notify the expressive device subsequently of when it wants to request changes to the surface or when it has finished with it. If the destination chooses not to accept the impression, then it should send back a release message to reject it and not create a table entry. Any subsequent messages relating to the "impression" should then be ignored.
• a sendmg device When a sendmg device receives a release message for an impression it should delete the entry relatmg to the impression from its table. This ensures that the device which released the impression will not receive any messages related to the impression. There is a short pe ⁇ od between the sendmg of an impression and the receipt of a release message rejecting it. Du ⁇ ng this penod the expressive device may consider the impression to exist. This will not cause any practical problem, as the issue will be resolved at the receivmg end: the "impressing device" is required to ignore messages relating to impressions which it has not accepted, or which it no longer has.
• the message provides a source surface identifier: this is an identifier allocated by the expressive device to the surface which is unique for the time between when the first impression is created and the last unpression is unimpressed. This identifier is used by the protocol to identify a surface uniquely
• the values 0 and 1 are reserved 0 meaning a NULL surface and 1 bemg used to designate the "default target" surface expression (used for the work surface, as discussed above)
• the source surface class is also provided. This is the class of the source surface Class is used to determme the use of the surface. The use of each class is addressed further below m the context of control. It is possible that devices will not be able to handle specific classes of surface: such devices may be configured either to ignore all such surfaces or to treat all surfaces of that class as surfaces of a different class which the device is configured to handle.
• the protocol maintains a version number for each surface m use, also identifed m the message. This is updated each time the expressive device changes the surface.
• the expressive device will accept a SurfaceChangeMsg from an unpressive device
• Table 1 Properties of surface impressed with SurfaceMsg This could be extended in other implementations by addmg a value of 3, for which the expressive device will both respond to a SurfaceMsg and accept a SurfaceChangeMsg.
• a field mdicatmg the surface identifier for the target surface If this value is set to 1, then the target is assumed to be the default target surface, or work surface, of the destination Otherwise, this field must contam the surface identifier from an earlier impression of a target surface.
• a status field identifies the status of this SurfaceMsg. The following values are defined.
• the request identifier field is set to the correspondmg request identifier
• an impress identifier field is a unique identifier that is allocated by the expressive device It can be used to distinguish between different impressions of the same surface Note that this identifier need only be unique for each impression of a surface. Impressions of other surfaces may use the same identifier. Thus, while expression identifiers are unique across all local surfaces, an impress identifier need only be unique within the set of impressions related to a specific local surface
• a further field is the target address: the target address is the Session Protocol address of the target device. Impress operations always have a target device and a target surface. In most transactions only a source and a target are mvolved However the protocol allows one device to impress an impression from a second device onto an impression from a third device.
• the third device can only be identified by its JetSend Session Protocol address.
• the protocol allows an explicit specification of the target devices Session Protocol address.
• the address length field should be set to 0 and no target address should be mcluded.
• This message is used by an expressive device to notify unpressive devices that the expression has been deleted.
• an expressive device When an expressive device deletes an expression, it must notify all impressive devices which hold an unpression of the delete It should also delete the entnes for the expression and all impressions of it from its surface table. It must ignore any subsequent messages relating to the expression or any of its impressions.
• This message is used by an unpressive device to notify the expressive device that the impression has been unimpressed.
• an impressive device no longer requires an unpression, it deletes it from its surface table and sends the expressive device a SurfaceReleaseMsg message.
• the unpressive device must then ignore all messages relatmg to the deleted impression. It is possible that a device has multiple impressions of the same surface, in this case, the impressive device will only ignore messages where they relate specifically to the unimpressed unpression.
• an expressive message When an expressive message receives such a message, it should delete the entry relating to that specific unpression from its surface table. It should no longer send any messages relating to that impression to the relevant impressive device There will be a short pe ⁇ od between the impressive device issumg this message and the expressive device receivmg it and deletmg the entry from its surface table. The expressive device may therefore send messages relatmg to the impression during this period, but no practical difficulty results as the impressive device will ignore any messages relatmg to expressions that it has unimpressed.
• This message requures an unimpressed expression identifier: this is the surface identifier for the expression of which an impression has been unimpressed by the impressive device. If this is the last remammg impression of the expression on the impressive device, then that device will ignore all subsequent messages involving this surface identifier.
• each SurfaceMsg is allocated a unique identifier by the expressive device. This allows devices to distinguish between multiple impressions of the same surface.
• the use of the impress identifier m the SurfaceReleaseMsg allows the expressive device to determme which impression was unimpressed.
• This message is used by a device to request an unpression from anomer device.
• the message requests one device to create an unpression on the requestor.
• the name may or may not be a valid surface name on the remote device. If the name is valid, the remote device should create an unpression on the requestor: if the name is not valid, the request should be rejected.
• the target surface identifier must be a valid identifier for an expression of which the remote device has an impression: otherwise, the request will be rejected.
• an expressive device When an expressive device receives a surface request, it should if necessary create the requested surface and use the impress message to impress it on the requesting device. Alternatively if the request is invalid, the expressive device should reject the request.
• the request identifier m the impress or reject message must be the same as the request identifier in the ongmal request message
• a source surface name this is the name of the surface of which the device wants an impression.
• the name is a NULL-termmated ASCII string.
• a source surface class this is the class of the surface of which the device wants an impression. Two expressions may have the same name, and be distinguished by their respective classes.
• a target surface identifier is also required, as is a request identifier so that the surface request can be identified umquely.
• This message is used by an impressive device to request the descnption for a surface of which the device has an impression.
• the impression identifier must be a valid unpression held by the requesting device.
• the expressive device receives a request for further descnption it should use the descnption reply to return the requested descnption. Descnption requests may not be rejected, although the resulting reply may contam no data.
• An impression surface identifier and a unique identifier for the request are required.
• This message is used to return a descnption for a surface m response to a DescnptionRequestMsg message.
• the result of a bad request should contam no data, mdicatmg that there is no more descnption for that specific request.
• There is no possibility of "rejectmg" a descnption request as a device which provides an unpression of a surface has to be prepared to provide a complete descnption of that surface.
• the descnption reply must contam the request identifier from the description request to which it is a response.
• This message is used by an impressive device to request some content data from an expressive device
• the unpression identifier must be a vahd impression held by the requesting device.
• a source surface identifier and a unique identifier for the request are required: mformation can also be provided to establish a separate communication channel for the content.
• ContentReplyMsg ContentReplyMsg (Content Data) This message is used by an expressive device to send some content data to an unpressive device. There may be a sequence of content data messages m response to a smgle content request. This message is also used to reject a request for content data.
• the content provider If the content provider is providing the data over a stream, it sets the stream field to the stream identifier and leaves the content length and data empty. If the content provider does not support streams, or is unable to use a stream for this purpose, it sets the stream identifier to 0 and transmits the content data as a senes of content reply messages: m this case, the content length and data are used to convey the contents of the message.
• the ContentReplyMsg will only be used to reject a content request if the content provider can no longer satisfy the request for mtemal reasons, or if the request is invalid.
• the request identifier m the reply must be set to the request identifier contained m the ongmal request.
• a device When a device receives a content reply it must first determme if the reply is a rejection. If so, the device has to make a decision as to its next action. If the reply is not a rejection, then the device must determme if the content is bemg supplied over a stream or not If the content is bemg supplied over a stream, it should be read from there: if not, then the content should be read from this and subsequent replies which have the same request identifier (as transport is ordered such replies will be in sequence, and the status field will identify the final reply m the senes).
• a source surface identifier and a request identifier are required.
• a status field is provided, with legal values set out in Table 9 below. Value Meaning
• the content data will be empty.
• ContentRequestMsg Sends content to requesting An impressive device requestmg content will device. send a ContentRequestMsg to the expressive device. If the ContentRequestMsg signals that the data should come over a message channel, the expressive device can then send the requested content through the use of the ContentReplyMsg. The expressive device may send one or more ContentReplyMsgs to satisfy the request.
• ContentRequestMsg Rejects the request for content
• An expressive device may reject the request for content by sendmg a ContentReplyMsg with the status value field of the header set to 2 across the message channel. Note that this is the procedure used for rejecting all content-requests, mcludmg those requesting that the data be sent over a stream channel.
• This message is used for three purposes: first, by an expressive device to notify impressive devices of a change to a surface; second, by unpressive devices to request a change to an expression; and third, to notify an unpressive device of a failed request to change an expression.
• an expressive device makes a change to one of its expressions, it must notify all impressive devices of the change. It does this by looking up the unpressions m its surface table and sendmg each impressive device a change message. Where a device has multiple unpressions, it is not necessary for a change message to be sent for each unpression: the impressive device maintains a link between the expression and the impressions.
• an impressive device When an impressive device receives a change message, it needs to perform the change on each of its impressions of the changed expression. In some cases the change message contams the change itself, whereas at other times the message may only contam a notification and the impressive device has to re-fetch the content for the changed surface. If the expressive device knows the encodmg of content requued by each impressive device, then the expressive device can be configured to provide separate change messages each containing the content m the form required by the relevant unpressive device.
• an expressive device On receiving a change request message, an expressive device must decide whether to accept the change or reject it The decision can be based on the version and the nature of the request. An expressive device notifies the requestor as to whether the change is accepted or rejected through a change message with the appropnate status set. The expressive device also notifies all the impressive devices of an accepted change usmg the change message, as previously descnbed.
• An unpressive device which issues a successful change request will thus receive two notifications of the change, one bemg the change acceptance (sent specifically to it), and the other is the change notification, which is sent to all devices with impressions of the expression. These messages can be identified as relating to the same change from either the request identifier or the version information.
• each surface has a version number to allow an expressive device to determme what version of a surface is bemg changed and what state impressions of a surface are in. This field contams the version number of the surface before this change was apphed.
• new surface version when an expressive device issues a SurfaceChangeMsg to notify unpressive devices of a change to a surface, this field contams the new version number of the surface after the change was apphed. This allows the expressive device to skip version numbers. Otherwise this field should be set to 0.
• a status field is provided, with values as set out in Table 11 below.
• each policy relates to a group of surfaces of a given class: control surfaces consequently have a specific class (or may be given a group of classes)
• surfaces of a given class are distinguished by name or by the context m which they appear Such surfaces are here termed "well-known surfaces" because they have a known meaning to devices that exchange them.
• Policies are generally optional. If two devices support a particular policy they will exchange mformation implementing that policy. If only one device mvolved m a session supports a policy, that policy will be ignored.
• control policy merely provides an effective example of how control can be achieved
• the first aspect of the policy is the provision of a "control panel" at a controllmg device which provides the user with the capability to determme the parameters of the controlled device. This provides essentially steps 21 and 22 of the gene ⁇ c control operation shown m Figure 2.
• the messages employed are illustrated m Figure 7, which is desc ⁇ bed m detail below.
• FIG. 7 shows a controllmg device 12 and a controlled device 11, and illustrates the steps mvolved m the communication process between them.
• m step 91 each device is initialized to enable exchange of control mformation. in essence, each device must be connected and aware of each others existence- a session is established between the devices.
• controllmg device 12 which mdicates a desire to control the controlled device 11 by sendmg a SurfaceRequestMsg m step 92 for a control surface from controlled device 11.
• Different mechanisms can be established to ensure that the co ⁇ ect surface is requested: an approp ⁇ ate solution is for the default surface of the control class to be requested (alternatively, the controllmg device 12 may already have been provided with an identifier for the approp ⁇ ate control surface of controlled device 11)
• Controllmg device 12 requires no knowledge of the function of controlled device 11 all it requires is a means to ensure that it receives the approp ⁇ ate surface.
• Controlled device 11 receives this request and responds, m accordance with the protocol, with a SurfaceMsg m step 93 to impress its control surface upon controllmg device 12.
• This control surface contains the choices for a senes of parameters requured for control of controlled device 11, together with information necessary to enable the user to make a selection from these choices: impression of this surface is effectively step 21 from Figure 2
• This mformation may be provided m different encodmgs and negotiation through a data format hierarchy may require one or more parrs of DescnptionRequestMsg and DescnptionReplyMsg messages- the e-matenal associated with such a SurfaceMsg message is discussed at a later pomt where encodmgs for control mformation are discussed.
• controllmg device 12 An encodmg choice is made by the controllmg device 12 m step 94 with the sendmg of a ContentRequestMsg message for a chosen data format. This is followed with a ContentReplyMsg from the controlled device 12, which provides all the control data: this identifies all the parameter choices to be made and provides any supporting mformation.
• the controllmg device 12 now has available all the information necessary for provision of control mformation, which will generally be m the form of a control panel display for a user. It should be noted that the control panel may comprise a plurality of surfaces (a parent surface with one or more child surfaces), m which case a number of surface and content requests and replies will be required for this step to be completed.
• Processmg of the information to provide such a display follows m step 96, which corresponds to step 22 m Figure 2
• m step 96 which corresponds to step 22 m Figure 2
• the provision of such a display from e-mate ⁇ al is discussed further below- however, it is important to mdicate at this pomt that the nature of the display itself may be highly dependent on the display functionahty of controllmg device 12. This may be reflected m either the encodmg negotiated between die devices, or m the manner m which the controllmg device is able to display control information of a particular type: both will be discussed further at a later pomt.
• the controllmg device 12 thus renders the mformation received m the form of a virtual control panel for controlled device 11
• Controllmg device 12 clearly requues a user mterface sufficient that a user can interact with the virtual control panel to select parameter values.
• Controllmg device 12 then needs to pass these selections back to the controlled device 11
• the controllmg device 12 needs have no knowledge of the meaning of a particular parameter (for example, what it means for a paramater labelled "Power" to be set to ON), but it does need to have an understandmg of the types of operation which a user is allowed to make: however, this should be provided in the e-mate ⁇ al already provided by the controlled device 11.
• a second aspect of the control policy relates to these steps of passmg user selections back to the controlled device, correspondmg to steps 23 to 25 m Figure 2. This aspect is illustrated m Figure 8, and discussed further below
• the controlled device 11 is now able to accept or reject the changes to the control panel with a further SurfaceChangeMsg m step 102. If the choices offered by the controllmg device 12 are legal and can be understood by the controlled device 11, the change to the control surface identified with the ongmal SurfaceChangeMsg will generally be accepted. If requured, further content may be provided by the controlled device at this pomt.
• the virtual control panel will generally reflect the current parameter choices, and local updating from the updated surface will be requured after any accepted change at both controllmg and controlled devices: at the controlled device 11 to change the device function accordmg to the selected parameter choices, and at controllmg device 12 so that the virtual control panel reflects the choices adopted.
• e-matenal is the form m which a surface is expressed E-matenal compnses both descnption and content.
• the descnption is used by JetSend to negotiate the exchange of content.
• the description sets out die attnbutes of the surface.
• These attributes typically form a hierarchy of choices encompassmg a number of attribute levels. These attributes indicate how information can be conveyed: the content itself is the perceivable information to be transferred.
• a successful exchange of a surface between appliances requires that each att ⁇ bute level desc ⁇ bmg the surface be identified and processed.
• the process of identifymg and processmg these levels between the appliances is called negotiation
• the surface content is exchanged.
• the exchange of a surface between two JetSend appliances involves surface mteraction messages as defined m the JIP.
• a surface description may be completed usmg descnption requests and descnption replies.
• the surface content exchange is completed usmg content requests and content replies.
• surface content may be mcluded m the surface descnption; this is called m-lme content With m-lme content and a small description, an exchange may require only a smgle message. More commonly several messages are exchanged.
• E-mate ⁇ al is provided m the form of e-mate ⁇ al blocks.
• an e-matenal block can be represented in a two column table with attnbute names in the first column and att ⁇ bute values m the second column.
• An att ⁇ bute name is a smgle specific keyword: an att ⁇ bute value is a value, or a number of values, associated with an att ⁇ bute.
• an attnbute value is specified as a list of values, they appear as a space-separated list in the value field.
• the att ⁇ bute-value pairs which appear m the e-mate ⁇ al block are applicable to some portion of a JetSend surface.
• Att ⁇ bute- value pairs may apply to the whole surface or to a specific portion of the surface. All attributes and some values are drawn from a limited set of predefined keywords. These are denoted m this specification by a "v" prefix such as vEncoding. Some values are drawn from a set of data types These are denoted m this specification by an "em” prefix such as emListType. In this specification, there are a number of representational types defined to simplify the discussion of the grammar-like structure of JetSend surfaces: these will be mdicated by approp ⁇ ate identifiers, generally m the value field
• Attnbutes are associated with a set of values which offer a selection. Each set of values is called a selection list. Selection lists appear as a space-separated list m the value column of a two- column table. Du ⁇ ng the negotiation process, each attnbutes takes one value from the selection list The selection of each value lends to the identification and processmg of each attnbute level of die surface descnption. For convenience m this implementation, it is made a rule that attnbute data that can be lists must be encoded as lists - even if they contam only one value. As the levels are identified and processed, the attnbutes which take selection lists and the selected values are enumerated m an e-matenal block.
• This e-matenal block is called a decision block, smce it represents the decisions as to the specific attributes of the e-matenal.
• the descnption request and content request m clude an e-mate ⁇ al block which mdicates the attnbutes of the e-mate ⁇ al bemg requested.
• An att ⁇ bute block is an e-mate ⁇ al block which sets out all the attribute-value pairs pertaining to a specific att ⁇ bute level of the surface descnption
• a surface descnption block is an ordered set of att ⁇ bute blocks.
• a surface descnption block may be represented as a three-column table with attnbute blocks occupymg the last two columns. The first column of the table contains a decision pa ⁇ applicable to each attnbute block.
• a decision path is constructed usmg the values from the decision block. These are concatenated together m a dot notation m the same order as me attnbute blocks.
• an att ⁇ bute block applicable to an image might be qualified by a decision path such as vlmage.vGray 8 (300,300) vRLE, mdicatmg that it is a run-length encoded image with 300 by 300 dpi resolution and 8 bits per pixel gray scale.
• This notation desc ⁇ bes the composition of the surface which is called the encodmg hierarchy. The root of this hierarchy is called the null level.
• the encodmg hierarchy forms a tree-like structure. Each node m this structure is an att ⁇ bute level. A level is terminal if none of the attnbutes that it contains takes selection lists or requires further descnption.
• the decision path gives the set of decisions down the tree to the level mdicated m the encodmg hierarchy field. Each value m the decision path mdicates descent to a next level down the encodmg hierarchy tree, and the last value m the decision path is the name of the att ⁇ bute level.
• a surface descnption is known to be complete when the level m the encodmg hierarchy is known to be terminal.
• Some surfaces within the surface hierarchy have one or more child surfaces These child surfaces are organized m one or more ordered child lists which are distinct for each parent surface.
• a child list may be well characterized, such as a list of images and text blocks on one side of one page. However it may not be fully available at any given tune.
• die child list which reflects the composition of d e stack is not so readily available at any given time. Such surfaces may not be created until they are requested, or at some other future time approp ⁇ ate for relevant device operation.
• the child list when characterized gives the names of the child surfaces related to a parent surface. In the surface descnption table, this is called a reference list.
• a decision path is constructed from the values m a decision block. These values are m turn taken from selection lists. The encodmg hierarchy is expressed in terms of these decision paths. The decision paths are used to identify the level of each att ⁇ bute block.
• JetSend appliances To ensure that JetSend appliances communicate under all circumstances, specific decision padis must m general be present. These are called default encodmgs. Sendmg appliances must be able to produce e-mate ⁇ al with the attnbutes descnbed by these default decision paths. Similarly receivmg appliances must be able to interpret e-mate ⁇ al with these charactenstics. Default encodmgs are present to ensure that appliances will exchange e-matenal under normal conditions. These encodmgs are the lowest common charactenstics.
• Base encodmgs are recommended decision paths which permit appliances to exchange e-mate ⁇ al with a higher degree of fidelity.
• Other attnbutes and values are considered optional.
• the default encodmgs are decision paths, each element of which comes from a selection list. Associated with each selection list is an attnbute. Each of the attnbutes whose values make up a default encodmg must be present m the surface descnption.
• control encodmg For a control encodmg to be useful, it is necessary for it to be able to address two basic requirements.
• One of ese requirements is for the encodmg to represent the control panel m such a way that it can be rendered on an appliance other than that from which it o ⁇ gmates.
• the other is that the encodmg must define a way of representmg changes made to the control panel m such a way mat the device receivmg the representation of the change can interpret the representation of the changes unambiguously.
• encodmg is desirable, rather than essential.
• a further desirable feature is for the encodmg to require little data to represent the virtual control panel and any changes made to it.
• bandwidth of any communications channel is finite, and as the network mdependence of JetSend means that it could be employed over substantially any communications channel, dns feature is desirable to minimise the likelihood of very long response tunes m establishing and usmg the virtual control panel.
• Control Scnpt it is also often desirable for negotiation to occur for a given encodmg: for example, if Control Scnpt is requested, different Control Scnpt content may be provided accordmg to the capabilities of the controllmg device 12, as could be established through negotiation.
• Control Scnpt is adapted to descnbe a senes of control options, rather than attempting to define the appearance of a control panel.
• a minimal number of assumptions about the display or input capabilities of the controllmg device are made: consequently even a very simple controllmg device can be used for a complex and sophisticated controlled device
• Controllmg devices capable of sophisticated mteraction are however capable of usmg the Control Script descnption to provide user interfaces approp ⁇ ate to their capabilities.
• Control Sc ⁇ pt can thus be used as an encodmg for any controllmg device, from a minimal controller to a data glove or a virtual reality headset.
• Control Sc ⁇ pt is mtended for use as a mandatory encodmg, it is adapted for use with a minimal user mterface. Obviously, it is advisable to require certain features of a minimal user mterface: it will not be practical to design an encodmg suitable for conttol with, say, one LED and one button (m principle such an encodmg could be designed and used m accordance with the mvention - it would however only be useful m certain limited contexts) as the mandatory control encodmg, as such an encodmg would be extremely inefficient for most control panels.
• the limit chosen for Control Scnpt is a display capable of showmg two lmes of sixteen alphanume ⁇ c characters, together with four control buttons. A computer simulation of such a display is provided in Figure 9.
• the minimal display 201 of Figure 9 has a first display lme 206 and a second display lme 207.
• first button 202 and second button 203 To the left and ⁇ ght, as implemented here, of the second display lme 207 are thurd button 204 and fourth button 205.
• the proposed method of use of such a minimal display is for a parameter label to be displayed on first display lme 206 with a choice for that parameter bemg displayed on second display lme 207.
• First and second buttons 202, 203 are used to move backward and forward respectively through the parameters available for selection.
• Third and fourth buttons 204, 205 are used to move backward and forward respectively through the choices available for the parameter mdicated m the first display lme 206.
• This sc ⁇ pt mdicates mat the user may choose between a number of options.
• the parameter labelled “Channel” may take on the value of "BBC1", “BBC2", “ITV” or "C4".
• the symbols “[” and “]” delimit the start and end of the values available, and / mdicates a logical exclusive OR. ".” is used to link a parameter and its available values.
• the parameter labelled "Copies” is to have a user selected value between 1 and 10.
• the grammar may be defined such that tins has to be an mteger value Mixed Types: Volume [Mute/ 1 10]
• a range may be an element m an enumerated choice list.
• “Volume” may take on the value “Mute” or a number between 1 and 10.
• this meta-conttol (which could here act as the label for the virtual control panel) consists of a control "Power” which can take the values "on” and “off and “Volume” and “Channel” controls as descnbed above
• Style guides for common user interfaces are available, and by imposition of additional rules the skdled man would appreciate that these can readily be converted mto a process for automatic user mterface generation.
• Examples m the literature are provided by Olsen D. in "A Programming Language Basis for User Interface Management", Human Factors in Computing Systems, CHF89 Conference Proceedmgs, May 1989, pp 171-176, which relates to generation of a Macmtosh user mterface from embedded Pascal, by Wiecha, C. et al m "Generating Highly Interactive User Interfaces", Human Factors m Computing Systems, CHI'89 Conference Proceedmgs, May 1989, pp 277-282 and by Zanden, B. Vander and Myers, B.A.
• a parameter desc ⁇ bed by a choice of a range or a smgle alternative is represented by a slider bar and a check box.
• Any remammg parameter is represented by a collection of radio buttons
• the programmer is free to choose sensible rules for layout.
• Controls are placed from top to bottom of the dialog box, m the order that they appear m the Control Scnpt.
• Controls whose use is dependent on otiier controls bemg set are indented with respect to their "parent" control.
• the dialog box is resized to accommodate the controls within it.
• the pseudocode parses a control scnpt mto an alternative data structure, then from this data stracmre and the set of basic rules above, calculates which of a set of widgets to represent each control element with. It then calls a set of functions (not given here) to generate these widgets and place accordmg to die rules above on a dialog box
• the pseudocode is not specific to a particular operating system, but the man skilled m the art will readily understand how to apply this pseudocode to a given operation system, such as Microsoft Wmdows
• ControlWidgetType - union of all available types of control elements (widgets, etc) * / union ⁇ "GROUP_OF_RADIO_BUTTONS"
• TheControlStructure ParseControlFromSt ⁇ ng(ControlScr ⁇ pt, NULL), AnalyseControl(TheControlStructure);
• This control element will be represented by a slider bar and a check box
• ControlElement->Widget "SLIDER_BAR_AND_CHECK_BOX"
• Control Element->Widget "GROUP_OF_RADIO_BUTTONS"
• ControlElement->Widget "LABEL”; return "CHOICE”; " CREATE THE WIDGET FOR EACH CONTROL ELEMENT *** / void CreateControlWidget(ControlElementType* ControlElement) ⁇
• NewControlElement Selector->ChildControlElement; do ⁇ CreateControl(NewControiElement);
• NewControl Selector->ChildControl; do ⁇
• implementable controls could be a bellpush button changeable by a "push” and then retummg a value on activation (useful m constructing an on display keypad), a bistable button (an on-off switch) changeable by a "push” and togglmg the value from a choice of two on activation, a slider changeable by movement, with the new slider position providmg a returnable value, a menu with value changeable by selection of a menu item, and text with value changeable upon user entry of new text.
• a user mterface can be created- Figure 12 shows a fax user mterface with bellpush buttons 301, bistable button 302, menu 304 and text field 305
• a number can be entered mto text field 305 by separate keyboard entry or by use of the virtual keyboard created with bellpush buttons 301
• a different encoding type altogether may be negotiated: an example is an HTML encoding employing the Forms extension. Arbitrary text strings, basic layout information and widget types are defined in the HTML encoding, but appearance of the resulting page can be largely determined by the client and can thus be adapted to a wide range of displays.
• the method of controlling one device from another described here is valuably and effectively implemented in the context of the JetSend protocol.
• the present mvention has very general application in control of one device by another, and is not limited to application in JetSend or similar protocols, but is applicable to almost any problem of control of one device by another.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Computer And Data Communications (AREA)
• Selective Calling Equipment (AREA)
• Information Transfer Between Computers (AREA)
• Communication Control (AREA)
• Facsimiles In General (AREA)
• Facsimile Transmission Control (AREA)
• Accessory Devices And Overall Control Thereof (AREA)

Priority Applications (4)

Applications Claiming Priority (4)

Publications (1)

Family

ID=26311377

Family Applications (1)

Country Status (5)

Cited By (1)

Families Citing this family (250)

Citations (3)

Family Cites Families (25)

• 1998
  • 1998-03-13 EP EP98301910A patent/EP0886411A3/en not_active Withdrawn
  • 1998-03-13 EP EP98301909A patent/EP0872991B1/en not_active Expired - Lifetime
  • 1998-03-13 DE DE69835314T patent/DE69835314T2/de not_active Expired - Lifetime
  • 1998-04-13 JP JP10115919A patent/JPH10320310A/ja not_active Withdrawn
  • 1998-04-13 JP JP10115918A patent/JPH10304013A/ja active Pending
  • 1998-04-14 US US09/059,867 patent/US6202096B1/en not_active Expired - Fee Related
  • 1998-04-14 US US09/059,909 patent/US6721286B1/en not_active Expired - Lifetime
  • 1998-04-15 EP EP98917369A patent/EP0976058B1/en not_active Expired - Lifetime
  • 1998-04-15 WO PCT/GB1998/001097 patent/WO1998047076A1/en active IP Right Grant
  • 1998-04-15 JP JP54363098A patent/JP2001524231A/ja not_active Withdrawn
  • 1998-04-15 US US09/367,923 patent/US6502000B1/en not_active Expired - Lifetime
  • 1998-04-15 DE DE69802792T patent/DE69802792T2/de not_active Expired - Lifetime

Patent Citations (3)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events