(12)
`
`United States Patent
`Berry
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,559,773 B1
`May 6, 2003
`
`US006559773B1
`
`(54) RECONFIGURABLE DISPLAY
`ARCHITECTURE WITH SPONTANEOUS
`RE C ONFIGURATION
`
`(75) Inventor: Richard Charles Berry, West
`Bloom?eld, MI (US)
`_
`_
`_
`(73) Asslgnee? Vlsteon Global Technologles, Inc»
`Dearborn, MI (Us)
`_
`_
`_
`_
`SubJect to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`_
`( * ) Notice:
`
`(21) Appl. No.: 09/468,170
`(22) Filed:
`Dec- 21’ 1999
`
`7
`(51) Int. Cl. ................................................ .. G08B 5/00
`(52) US. Cl. .................... .. 340/815.4; 340/531; 701/29;
`701/33; 700/17; 700/83; 345/326
`(58) Field of Search ............................ .. 340/8154, 531;
`701/29, 33; 700/17, 83; 345/326
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`5/1995 Bodin et al.
`5,418,962 A
`5,627,547 A * 5/1997 Ramaswamy et al. .... .. 342/357
`5,742,226 A * 4/1998 SZabo et al. ........... .. 340/4255
`
`5,794,164 A
`
`8/1998 Beckert et al.
`
`OTHER PUBLICATIONS
`Sun Microsystems, Inc., “Why Jini NoW”, Aug. 1, 1998, pp.
`1—14.
`Sun Microsystems, Inc., “What is Jini?”—Summary.
`Clohessy, Kim, Object Technology, Inc., Virtual Machine
`Technology: Managing Complexity and Providing Portabil
`ity for Embedded Systems.
`Mobile GT, “The Architecture for Driver Information Sys
`terns?
`_
`_
`* Clted by examlner
`Primary Examiner—Daniel J. Wu
`Assistant Examiner—Tai T. Nguyen
`(74) Attorney, Agent, or Firm—John E. Kajander
`(57)
`ABSTRACT
`
`Acontrol panel/display subsystem acts as a device portal for
`interacting With multiple devices interconnected via a
`dynamic local network Display Content and the human
`machine interface (HMI) implemented using the display
`subsystem automatically recon?gures itself When neW
`devices are added to the vehicle network. An interface
`speci?er enabling each neW device to Work With the device
`portal is obtained either from a local archive or a remote
`archive via connection With a remote network.
`
`18 Claims, 3 Drawing Sheets
`
`[ll
`
`& mm
`
`f’ n)
`
`2.» VOL E:::::
`:I 10:53 pm
`START MENU
`J
`“A123
`(0 1))
`‘AM-H124
`@ we“, ? sir PgE @ ,5;
`
`NAVIGATION
`
`Press Enter for Address Book
`
`Honda Exhibit 1005
`Page 1
`
`

`
`U.S. Patent
`
`May 6, 2003
`
`Sheet 1 of3
`
`US 6,559,773 B1
`
`START MENU J
`(v »»
`AMAFM % @] E?T P?l; @
`
`NAVIGATION
`
`Press Enter for Address Book
`
`/62
`
`1: R istration
`
`Disglay
`
`I
`l
`
`U 2:
`
`'
`
`'
`
`3: HMI Re uest
`
`4 HMI Re on
`
`Honda Exhibit 1005
`Page 2
`
`

`
`U.S. Patent
`
`May 6, 2003
`
`3«I02t66.h__S
`
`US 6,559,773 B1
`
`.r.,_°.,§L_
`
`"....mmEm.2..“....._.m.m_o§o>_..e<=2:3.
`
`_s_:.2:.2...
`
`
`ovoo_E£Eoo.._u>_om:_<.;;zuuamm=2:
`
`ono~_m.E_mn_
`
`__no.53.50
`
`
`
`>m_%_ouse:3581
`
`o3.5.
`
`
`
`3&5o3m._=m_.E8ox
`
`—..m.=._.
`
`
`
`ouoo_E£E8.=8fi_>.2$¢suuaom.2:o5.5oosuo
`
`o=o:n_=8
`
`
`
`u8u_E£=_8.o.uEu>.§.2Euwzom=2:
`
`
`
`_.no.5.838
`
`_s_:
`
`c8._>un_
`
`
`
`__2_.__.2:
`
`.2.6.
`
`_mason.a838
`
`
`
`
`
`:...._.m_a_o§2,___e<.s_:
`
`
`
` _s__.__2:o..._.~35:2,___e<_s_x
`
`—838o838
`
`
`
`
`
`_...._.m_.w_Eo:s_._2<_s_:
`
`.25.8.
`
`:8_>oo—8_>un_O8_>oo
`
`=833.3.3.
`
`.2:=2:
`
`
`
`.2:_s__._
`
`5..8
`
`_.825o3_>mn_
`
`.3+~_.»_Ee2._._e<_s_:
`
`
`
`
`
`_..._.255.6.o>_:e<.2:
`
`Euuoz
`
`m3_2_>>.2.
`
`NV
`
`nmo_e_>>
`
`Eons:
`
`o_oEm>8.2.
`
`
`
`o_u_:m>uEm=..O
`
`N.O_n_
`
`Honda Exhibit 1005
`Page 3
`
`

`
`U.S. Patent
`
`May 6, 2003
`
`Sheet 3 of3
`
`US 6,559,773 B1
`
`50w
`
`Human-Machine Interface (HMI)
`Application Objects For a
`Climate Control, Radio Tuner, Wireless, E-Mail, Cellular Phone,
`Audio, CD Player, etc...
`
`i
`
`5/ \ HMI Vl?dgets Component Library
`Objects For
`Button Metaphor, List Box, Vlhndow, Text Box, lime, etc...
`
`i
`
`52 Graphics Primitives (Graphics Device interface (GDl))
`\
`VECTOR: Line, Rectangle, Polygon, Arc, etc"
`RASTER: Bitmap, Font, etc...
`WINDOW MANAGEMENT: Clipping, Scrolling, etc...
`ATTRIBUTES: Color, Rotation, LineStyle, etc...
`
`5 {_ Display Frame Buffer
`Bit Plane(s) Target Selection
`Bit Plane(s) Visibility Selection
`Draw Mode (BOOLEAN Operation or REPLACE)
`
`FIG. 3
`
`Honda Exhibit 1005
`Page 4
`
`

`
`US 6,559,773 B1
`
`1
`RECONFIGURABLE DISPLAY
`ARCHITECTURE WITH SPONTANEOUS
`RECONFIGURATION
`
`BACKGROUND OF THE INVENTION
`The present invention relates in general to a recon?g
`urable display/control panel for controlling various elec
`tronic accessories, and more speci?cally to an architecture
`for recon?gurable displays and an overall netWork for
`spontaneously interconnecting the displays With various
`electronic accessories or devices in a manner Which auto
`rnatically recon?gures rnenu elernents shoWn on the recon
`?gurable display to interact With each electronic accessory.
`Recon?gurable displays are used in automotive vehicles
`in order to control a plurality of electronic accessories from
`a single control panel. Such a system reduces cost, saves
`space on the vehicle instrument panel, and makes the
`electronic accessories easier to control. A recon?gurable
`display includes a generic graphic display surface, such as a
`dot matrix, and a collection of “soft keys” (i.e., prograrn
`rnable buttons). The function of each key is dynamically
`recon?gured via softWare to alloW access to all the available
`functions or the accessories, typically using a menu struc
`ture. A typical recon?gurable display subsystern may also
`include a number of “hard keys”, buttons that provide instant
`access to frequently used functions (e. g., navigation, climate
`control, audio players, etc.).
`Because of their generic, reusable nature, recon?gurable
`autornotive displays have facilitated an increase in the
`number of features that are made available to the user.
`Consumers are demanding ever-greater functionality from
`their electronic accessories, While product design cycles of
`the accessories are simultaneously becorning shorter. Thus,
`it becomes a major challenge for manufacturers to provide
`neW and innovative system architectures While delivering
`high content, high quality products and features at a reason
`able cost.
`First generation autornotive recon?gurable display sys
`terns utiliZe ernbedded architectures that build speci?c fea
`ture content into the display design that cannot be altered or
`augrnented after the design is implemented. All supported
`features must be identi?ed at the time of initial design. While
`this approach provides high performance and loW cost, it
`lacks ?exibility.
`Second generation autornotive recon?gurable display sys
`terns utiliZe a personal computer (PC) type of architecture,
`such as the AutoPC platforrn. Such systems enable incre
`rnental feature deployrnent, Wherein neW features can be
`integrated seamlessly with those already present. HoWever,
`such feature deployment is essentially a static model since
`installed softWare applications occupy a percentage of the
`display resources at all times. Thus, it is distinctly possible
`that system resources could be inadvertently depleted during
`installation of a neW feature. Furthermore, such custorniZa
`tion requires installation skills on the part of the users (not
`just system developers and integrators), which limits the
`utility of such custorniZation for a signi?cant percentage of
`customers. Such systems are not truly “plug-and-play” since
`a manual installation procedure is required.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`SUMMARY OF THE INVENTION
`The present invention has the advantage of providing a
`recon?gurable display architecture in Which a human
`rnachine interface (HMI) is dynamically constructed in
`response to the electronic accessories Which are present in
`the system.
`
`65
`
`2
`In one aspect of the invention, an electronic accessory
`display/control system is provided for a transportation
`vehicle. A recon?gurable control panel has a visual display
`for displaying menu items for an electronic accessory and
`has at least one control actuator. Ahurnan-rnachine interface
`controller is coupled to the recon?gurable control panel and
`includes a local archive for storing a plurality of interface
`speci?ers. Each speci?er de?nes interaction betWeen the
`recon?gurable control panel and a respective electronic
`accessory for performing operations via the menu items
`using a predetermined communications protocol. The sys
`tern includes an eXpandable interconnection link for cou
`pling cornpatible electronic accessories With the human
`rnachine interface controller. A Wireless transceiver is
`provided for accessing a remote archive of interface speci
`?ers. The remote archive includes interface speci?ers each
`adapted for a corresponding combination of a particular
`electronic accessory and a particular recon?gurable control
`panel. The hurnan-rnachine interface controller responds to
`a coupling of an electronic accessory to the expandable
`interconnection link by checking the local archive for pres
`ence of a desired interface speci?er corresponding to the
`electronic accessory and the recon?gurable control panel. If
`the desired interface speci?er is not present in the local
`archive, then the Wireless transceiver is activated to auto
`rnatically obtain the desired interface speci?er from the
`remote archive.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a front, plan vieW of a recon?gurable display
`employing the present invention.
`FIG. 2 is a schematic diagram shoWing the overall net
`Work system of the present invention.
`FIG. 3 is a block diagram shoWing the interaction of
`softWare objects for forming a hurnan-rnachine interface and
`its interaction With the recon?gurable display.
`FIG. 4 illustrates the main tasks eXecuted When a neW
`device is joined into the vehicle netWork.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`
`The present invention creates a device portal Within a
`netWork architecture having a dynamically constructed
`hurnan-rnachine interface (HMI). A control panel/display
`subsystern includes a collection of hard and soft controls and
`is made available as a netWork resource on a dynamic local
`netWork. The display subsystem of the device portal may
`include standard ernbedded features such as an audio tuner
`or CD player, but its main purpose is to be dynarnically
`recon?gurable to interact With other netWork resources via a
`collection of standard protocols. These other netWork
`resources include devices such as a navigation system,
`cellular phone, audio player, a palrn-siZe PC, or any other
`device employing an HMI in the vehicle. These devices need
`not be present in the netWork at all times. Using Java/Jini
`technology or similar technology, a dynamic netWork can be
`constructed Which alloWs autornatic installation of devices
`into the netWork.
`Referring to FIG. 1, a control panel/display subsystern 10
`includes a rnulti-elernent graphical display 11. Aplurality of
`push buttons 12—17 provide soft keys for accessing func
`tions as identi?ed by graphic/text labels displayed on display
`screen 11. Hard controls include a knob 18 Which is pressed
`to control system poWer and can be rotated to control audio
`volurne. An arroW pad 19 is used to navigate through rnenus
`displayed on display screen 11. An enter button 20 and a
`
`Honda Exhibit 1005
`Page 5
`
`

`
`US 6,559,773 B1
`
`10
`
`15
`
`35
`
`3
`back button 21 are also used to navigate through menu
`screens. A plurality of shortcut buttons 22—26 are provided
`to create shortcuts to menu screens for device functionality
`embedded in subsystem 10 (e.g., CD player or AM/FM
`radio).
`An HMI for a particular electronic accessory device
`includes graphical display elements to identify the device
`and its available features. Amenu screen for each accessory
`device includes labels to be displayed associated With par
`ticular soft keys 12—17 to identify controllable functions of
`the device. For the electronic accessory of a cellular phone,
`the soft keys may be associated With cellular phone func
`tions of accessing memory locations, initiating a call, ending
`a call, or other functions performable by the phone. Display
`screen 11 can also be used to display event information as
`communicated from the cellular phone, such as connection
`status, duration of call, and other information communicated
`by the cellular phone to display subsystem 10.
`The use of the recon?gurable display subsystem as a
`device portal in a dynamic local netWork is shoWn in FIG.
`2. Recon?gurable display subsystem 30 includes a display
`screen 31 and hard and soft keys 32. Display subsystem 30
`may also receive input commands from a voice recognition
`unit 33. An HMI controller 34 resides in display subsystem
`30 and controls graphical display screen 31, monitors keys
`32, accepts input from voice recognition (VR) unit 33, and
`interfaces With devices on the dynamic local netWork 36. A
`memory 35 stores interface speci?ers (i.e., drivers) used by
`controller 34 to drive graphic display screen 31 and to
`communicate With the various electronic accessory devices
`on dynamic local netWork 36.
`Each particular display subsystem (“device portal”)
`design is uniquely identi?ed by a type identi?er. Thus,
`display subsystem 30 is identi?ed as type 0, While additional
`display subsystems Which may be connected to the local
`dynamic netWork 36 have different identi?ers such as type
`1 for a display subsystem 37 and type n for a display
`subsystem 38.
`Dynamic local netWork 36 includes a collection of soft
`Ware and communication speci?cations and standard proto
`cols for hardWare interconnection. Examples of such a
`system are Jini by Sun Microsystems, Inc., JetSend by
`HeWlett-Packard, and Bluetooth by the Bluetooth Special
`Interest Group. System resources such as recon?gurable
`display subsystems, electronic accessories or other compo
`nents can join the netWork automatically once they are
`connected to it. NetWork 36 recogniZes the coupling of a
`neW device to the netWork and interacts With all the netWork
`resources as appropriate to enable operation of the neW
`device Within the netWork. Examples of electronic accesso
`ries connected to the netWork in FIG. 2 include a cellular
`phone 40, an MP3 audio player 41, and a palm-siZed PC or
`personal digital assistant (PDA) 42. Once connected to the
`netWork 36, these accessories Will communicate core func
`tionality control signals and messages With a particular
`display subsystem. Thus, the accessory and the recon?g
`urable display subsystem Will exchange messages concern
`ing control actions and state changes or events but Would not
`include speci?c messages on hoW to display messages or
`hoW the display is to be driven.
`Each device 40—42 includes a unique device type identi
`?er. Each device type may interact With a predetermined
`recon?gurable display type using an interface speci?er
`developed for the combination of device and display sub
`system. Thus, When HMI controller 34 detects the presence
`of a neW electronic accessory, it determines the device type
`
`45
`
`55
`
`65
`
`4
`for the accessory and checks Whether it currently has an
`interface speci?er to support interaction With the device
`stored in memory 35. If the desired interface speci?er is
`present, then HMI controller 34 can communicate core
`functionality messages betWeen the recon?gurable display
`and the accessory device. If an appropriate interface speci
`?er is not already contained in memory 35, then HMI
`controller 34 takes steps to retrieve an appropriate interface
`speci?er, if possible.
`A memory in each recon?gurable display subsystem
`provides a local archive for storing a plurality of interface
`speci?ers each of Which de?nes interaction betWeen the
`recon?gurable display subsystem and a respective electronic
`accessory. Whenever an additional interface speci?er must
`be retrieved, it may preferably be obtained using a universal
`resource locator (URL) of a server that contains a further
`collection of HMI interface speci?ers. Such a server may
`also be a local archive in the vehicle directly connected to
`dynamic local netWork 36 as shoWn by a server 43 in FIG.
`2. Server 43 is a local server containing a ?rst group of HMI
`interface speci?ers 44 corresponding to the con?gurable
`display type Zero. Additional HMI interface speci?ers are
`stored in other groups for other recon?gurable display types
`as shoWn. For each recon?gurable display type, a plurality
`of interface speci?ers are stored as indexed by device type.
`Server 43 may be constructed With some interface speci?ers
`contained in a read-only memory (ROM) in order to provide
`a ?xed set of interface speci?ers for a knoWn set of elec
`tronic accessories Which are expected to be utiliZed in a
`particular vehicle. In addition, re-Writeable memory may
`also be included for subsequent storage of interface speci
`?ers for other device types in order to provide ?exibility for
`groWth.
`In order to accommodate electronic accessory devices not
`included in local server 43, the present invention also
`provides access to a remote archive Web server outside the
`vehicle. Thus, a Wireless modem 45 is interconnected With
`dynamic local netWork 36 and can be used to communicate
`With a remote Wireless modem 46 Which is connected to a
`remote Web server 47 containing additional interface speci
`?ers in a remote archive. Remote server 47 may be con
`nected to the World-Wide Web or internet and Wireless
`modem 46 may be connected to an internet service provider
`(ISP), for example. The URL address for remote server 47
`may be a predetermined address as de?ned by convention
`and stored in either local server 44 or HMI controller 34, for
`example. Preferably, the URL address of an remote archive
`may be obtained directly from each accessory device itself.
`Thus, cellular phone 40 stores a remote archive address
`providing the URL to the other resources on dynamic local
`netWork 36. Thus, cellular phone 40 stores URL of
`WWW.visteon.com/hmicode Where an appropriate interface
`speci?er corresponding to cellular telephone device type 0
`and a plurality of recon?gurable display types are stored.
`Thus, as neW electronic accessory devices are developed,
`interface speci?ers can also be developed in order to inter
`face the neW device With the existing recon?gurable display
`types. The location from Where these interface speci?ers can
`be retrieved is stored in the neW accessory device, thus
`making the device compatible With all recon?gurable dis
`plays of those types.
`FIG. 3 shoWs the various softWare elements required in
`the system of FIG. 2, including softWare elements compris
`ing the HMI itself, (i.e., the interface betWeen the display
`subsystem and the accessory device and softWare for driving
`the display). Thus, a human-machine interface softWare
`element 50 provides application objects for a particular
`
`Honda Exhibit 1005
`Page 6
`
`

`
`US 6,559,773 B1
`
`5
`accessory such as climate control, radio tuner, Wireless
`information service, e-mail, cellular phone, audio, CD
`player, or others. These objects interact With other objects in
`an HMI Widgets component library 51 including such
`objects as button metaphor (i.e., button icon and identi?ca
`tion of corresponding soft key), list box, WindoW, text box,
`time, and others. These objects interact With graphics primi
`tives 52 providing a graphics device interface. These graph
`ics primitives de?ne vector shapes, raster elements, perform
`WindoW management, and provide graphic attributes. These
`primitives interact With softWare for display frame buffer 53
`for managing display activation such as target selection,
`visibility selection, and draWing mode.
`More speci?cally, an interface speci?er Which Would be
`doWnloaded from either a local or a remote archive contains
`compiled softWare class objects that collectively implement
`an application speci?c HMI for the unique display driver/
`accessory device combination. In a Java implementation,
`these objects Will be precompiled from Java source code into
`Java bytecodes Which are the instructions that run on the
`Java Virtual machine (JVM). Some of these doWnloaded
`objects implement an overall HMI for the speci?c class of
`application of the accessory device, such as cellular phone,
`compact disc player, or address book. Some of the other
`doWnloaded objects are generic (i.e., application
`independent) and can be applied to a Wide range of appli
`cations. These generic, reusable components or Widgets may
`typically already reside in the display subsystem, but may be
`included in a doWnloaded interface speci?er for complete
`ness and ?exibility to use display subsystems not already
`containing the Widgets. DoWnloading may include the capa
`bility to identify objects already residing in the display
`subsystem and then only downloading objects Which are in
`fact needed.
`The behavior of a particular HMI is embedded in the
`collection of class objects Within the interface speci?er and
`include four main functional areas: 1) processing user input
`events, 2) processing device events, 3) rendering graphic
`displays, and 4) sending commands to devices.
`User input events are generated When a user manipulates
`a control actuator of the display subsystem, such as pressing
`a button, issuing a voice command, manipulating the point
`ing device such as a mouse or track ball, or otherWise
`initiates a control action. Physical device events are repre
`sented by softWare abstractions and are reported to the
`accessory device via the dynamic local netWork. Examples
`of physical device events include button pressed, button
`held, button released, sWitch closed, sWitch opened, pointing
`device position change, pointing device pressed, pointing
`device held, and pointing device released. The control
`actuator being used may be physically contained on the
`display subsystem or may be remotely connected to the
`display subsystem, such as a pointing device mounted on a
`steering Wheel in the vehicle.
`Objects for processing device events provide noti?cation
`to the display subsystem of state changes occurring Within
`the electronic accessory device. Speci?c device events
`depend upon the functionality of the particular electronic
`accessory device. For an electronic accessory device pro
`viding navigation features, examples of device events
`include noti?cation of a pending route maneuver, vehicle
`approaching destination, vehicle off-route, and others.
`With regard to softWare objects to render graphics on the
`visual display, these objects respond to user input or device
`or system events (e.g., poWer-up initialiZation) to initiate and
`execute all required rendering operations. The HMI inter
`
`15
`
`25
`
`35
`
`45
`
`55
`
`65
`
`6
`face speci?er embeds the knoWledge of hoW to display the
`information, including font siZe, screen location, number of
`digits, siZe and shape of graphic elements, timing for ani
`mated components, etc.
`The softWare objects include those that send predeter
`mined commands to the electronic accessory devices in
`order to enable the user to control and monitor the devices.
`Some typical examples include incrementing or decrement
`ing a CD track selection, selecting an FM radio pre-set,
`adjusting the time-of-day clock, setting climate control
`temperature or fan speed, dialing a phone number, and
`others. The speci?c implementation of the user interface
`speci?er can enable these actions in many different Ways.
`These objects correlate user input events With the corre
`sponding control action.
`A preferred method of the present invention Will be
`described in connection With FIG. 4. The sequence of steps
`shoWs interaction betWeen an accessory device 60, a recon
`?gurable display subsystem 61, and a server 62 containing
`an archive of interface speci?ers. Device 60 is a pluggable
`device such as a cellular phone, palm-siZe PC, or MP3
`player and is identi?ed via a device type identi?er Which is
`embedded into the device’s persistent storage, such as ROM
`or FLASH. Persistent storage also contains a universal
`resource locator (URL) that indicates the location of an HMI
`server containing interface speci?ers corresponding to the
`device. Display subsystem 61 likeWise has its oWn display
`type identi?er embedded into persistent storage. Server 62
`may be a local server or a World-Wide Web server containing
`collections of HMI interface speci?ers for the various dis
`play subsystem and accessory device combinations. The
`server processes requests for interface speci?ers Which
`include the device type identi?er and the display type
`identi?er. The ?rst phase of the process is registration. In
`registration, device 60 communicates its presence to
`resources on the dynamic local netWork and provides its
`device type identi?er and the URL of a server containing a
`collection of interface speci?ers corresponding to the
`device. The second phase of the process is an HMI check in
`Which the display subsystem 61 checks to see if it already
`has an interface speci?er supporting the accessory device
`represented by the device type identi?er. If a supporting
`interface speci?er is already present, then the device auto
`matically begins to use the display subsystem as a device
`portal.
`If a supporting interface speci?er is not present, then the
`third phase of the process is entered Which comprises an
`HMI request. This phase includes attempting to connect to
`the server speci?ed by the device. If connection is
`successful, the display subsystem communicates the device
`type identi?er and the display type identi?er to the server.
`HMI report is the fourth phase of the process. Once the
`server successfully receives a request it checks its archive of
`HMI interface speci?ers for a match as de?ned by the
`display type identi?er and device type identi?er. If a match
`is found, it returns the interface speci?er packaged as a Java
`archive (JAR) ?le, for example. If not, it sends a message
`specifying that no interface speci?er is available for the
`device/display combination. In the clean-up phase, display
`subsystem 61 responds to the information obtained from the
`server. If the server indicated that no interface speci?er Was
`available, then the display subsystem indicates an error
`condition to the user. If a JAR ?le Was successfully returned,
`then the display subsystem extracts and installs the neW
`softWare objects automatically to alloW the display sub
`system to act as a device portal for the installed device.
`In order to minimiZe the amount of memory required for
`storing interface speci?ers, and to simultaneously reduce
`
`Honda Exhibit 1005
`Page 7
`
`

`
`US 6,559,773 B1
`
`7
`download times required, a memory manager or caching
`technique is used for storing interface speci?ers. Preferably,
`a memory in any individual subsystem is large enough to
`hold interface speci?ers to service the complete maximum
`load of accessory devices that may be in operation using the
`display subsystem at any one time. Since some devices may
`be disconnected after having been used in the system, some
`interface speci?ers may be present in memory in a display
`subsystem for Which the original accessory device is no
`longer present in the netWork. According to the present
`invention, any such inactive interface speci?er is given a
`loWer priority than active interface speci?ers. Furthermore,
`the longer an interface speci?er has been inactive, the loWer
`priority it is given relative to other inactive interface speci
`?ers. If the amount of remaining free memory becomes
`restricted, the HMI controller deletes the loWest priority
`interface speci?ers to make room for additional interface
`speci?ers for other accessory devices that have joined the
`netWork. Priority assignments may also take into account
`?le siZe and/or frequency of use so as to minimiZe overall
`doWnloading to restore interface speci?ers that have been
`deleted.
`Local server 43 in FIG. 2 may also contain a memory
`manager 48 for similarly managing prioritiZing and/or dele
`tion of HMI interface speci?ers to most effectively use
`storage space in server 43.
`With regard to the dynamic local netWork, this may take
`the form of an RF-Wireless netWork using the Bluetooth
`speci?cation, for example. When a Wireless-capable acces
`sory comes Within communication distance of the dynamic
`local netWork, this is detected by means of a Wireless polling
`signal exchanged betWeen the local netWork and the neW
`device. Based on a response to the polling signal, the devices
`exchange netWork messages to establish the neW device as
`a resource available to devices on the local netWork.
`What is claimed is:
`1. An electronic accessory display/control system for a
`transportation vehicle, comprising:
`a recon?gurable control panel having a visual display for
`displaying menu items for an electronic accessory and
`having at least one control actuator;
`a human-machine interface controller coupled to said
`recon?gurable control panel and including a local
`archive for storing a plurality of interface speci?ers,
`each speci?er de?ning interaction betWeen said recon
`?gurable control panel and a respective electronic
`accessory for performing operations via said menu
`items using a predetermined communications protocol;
`an expandable interconnection link for coupling compat
`ible electronic accessories With said human-machine
`interface controller; and
`a Wireless transceiver for accessing a remote archive of
`interface speci?ers, Wherein said remote archive
`includes interface speci?ers each adapted for a corre
`sponding combination of a particular electronic acces
`sory and a particular recon?gurable control panel;
`Wherein said human-machine interface controller
`responds to a coupling of an electronic accessory to
`said expandable interconnection link by checking said
`local archive for presence of a desired interface speci
`?er corresponding to said electronic accessory and said
`recon?gurable control panel, and if said desired inter
`face speci?er is not present in said local archive then
`activating said Wireless transceiver to automatically
`obtain said desired interface speci?er from said remote
`archive.
`
`10
`
`15
`
`25
`
`35
`
`45
`
`55
`
`60
`
`8
`2. The electronic accessory display and control system of
`claim 1 Wherein said desired interface speci?er assigns a
`predetermined function to said control actuator.
`3. The electronic accessory display and control system of
`claim 1 Wherein said expandable interconnection link is
`comprised of a dynamic local netWork.
`4. The electronic accessory display and control system of
`claim 3 Wherein said dynamic local netWork is comprised of
`a Wireless netWork, and Wherein presence of neW electronic
`accessories is detected automatically in response to a Wire
`less polling signal.
`5. The electronic accessory display and control system of
`claim 1 Wherein said compatible electronic accessories each
`provide to said human-machine interface controller a unique
`device identi?er and a remote netWork address for said
`remote archive.
`6. The electronic accessory display and control system of
`claim 1 Wherein said interface speci?ers are comprised of
`softWare objects.
`7. The electronic accessory display and control system of
`claim 6 Wherein said softWare objects include objects to
`process user events initiated by said control actuator.
`8. The electronic accessory display and control system of
`claim 6 Wherein said softWare objects include objects to
`process device events corresponding to a state change Within
`said electronic accessory.
`9. The electronic accessory display and control system of
`claim 6 Wherein said softWare objects include objects to
`render graphics on said visual display.
`10. The electronic accessory display and control system of
`claim 6 Wherein said softWare objects include objects to
`send predetermined commands to said electronic accessory.
`11. The electronic accessory display and control system of
`claim 1 further including said electronic accessory, and
`Wherein said electronic accessory is comprised of a portable
`computing device.
`12. The electronic accessory display and control system of
`claim 1 further including said electronic accessory, and
`Wherein said electronic accessory is comprised of a mobile
`communication device.
`13. The electronic accessory display and control system of
`claim 1 Wherein said control actuator is comprised of a push
`button sWitch.
`14. The electronic accessory display and control system of
`claim 1 Wherein said control actuator is comprised of a
`speech recognition unit.
`15. The electronic accessory display and control system of
`claim 1 further comprising a memory manager for priori
`tiZing interface speci?ers stored in said local archive and
`deleting interface speci?ers of loWer priority When said local
`archive becomes full.
`16. A method of operating