+

WO2013111185A1 - 移動体用情報機器 - Google Patents

移動体用情報機器 Download PDF

Info

Publication number
WO2013111185A1
WO2013111185A1 PCT/JP2012/000459 JP2012000459W WO2013111185A1 WO 2013111185 A1 WO2013111185 A1 WO 2013111185A1 JP 2012000459 W JP2012000459 W JP 2012000459W WO 2013111185 A1 WO2013111185 A1 WO 2013111185A1
Authority
WO
WIPO (PCT)
Prior art keywords
screen
api
moving
data
screen data
Prior art date
Application number
PCT/JP2012/000459
Other languages
English (en)
French (fr)
Inventor
水口　武尚
渡邊　義明
康明 瀧本
武史 三井
良弘 中井
Original Assignee
三菱電機株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 三菱電機株式会社 filed Critical 三菱電機株式会社
Priority to DE112012005745.7T priority Critical patent/DE112012005745T5/de
Priority to US14/350,325 priority patent/US20140259030A1/en
Priority to PCT/JP2012/000459 priority patent/WO2013111185A1/ja
Priority to CN201280068034.3A priority patent/CN104066623A/zh
Publication of WO2013111185A1 publication Critical patent/WO2013111185A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/542—Event management; Broadcasting; Multicasting; Notifications
    • G—PHYSICS
    • G01—MEASURING; TESTING
    • G01C—MEASURING DISTANCES, LEVELS OR BEARINGS; SURVEYING; NAVIGATION; GYROSCOPIC INSTRUMENTS; PHOTOGRAMMETRY OR VIDEOGRAMMETRY
    • G01C21/00—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00
    • G01C21/26—Navigation; Navigational instruments not provided for in groups G01C1/00 - G01C19/00 specially adapted for navigation in a road network
    • G01C21/34—Route searching; Route guidance
    • G01C21/36—Input/output arrangements for on-board computers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/451—Execution arrangements for user interfaces

Definitions

  • the present invention relates to an information device for a moving body that is mounted on a moving body such as a vehicle and includes a display unit that displays an application image.
  • Non-Patent Document 1 describes that the amount of information displayed on the screen by the vehicle information device should be optimized so that the driver can check in a short time.
  • Patent Document 1 includes a contact input unit such as a touch panel that performs an input operation based on a screen display, and a mobile input unit that performs a selection operation by moving a focus on the screen such as a dial switch.
  • a contact input unit such as a touch panel that performs an input operation based on a screen display
  • a mobile input unit that performs a selection operation by moving a focus on the screen such as a dial switch.
  • An in-vehicle device is disclosed. In this device, when the vehicle is stopped, a menu screen composed of an array of menu items suitable for input by a touch panel is displayed on the display device, and when the vehicle is traveling, suitable for input by a dial switch. A menu screen composed of an array of menu items is displayed on the display device.
  • Patent Document 1 a menu screen suitable for a case where the vehicle is stopped and a menu screen suitable for a case where the vehicle is traveling are prepared in advance, and the menu screen is switched according to the state of the vehicle. Therefore, the operability of selecting menu items is improved.
  • third-party apps applications developed by third parties other than manufacturers of in-vehicle information devices
  • third-party apps applications developed by third parties other than manufacturers of in-vehicle information devices
  • the manufacturer of the in-vehicle information device needs to comply with the operation content restriction when the vehicle is traveling for the third-party application.
  • UI User Interface
  • API Application Program Interface
  • display elements constituting a screen such as a character string, an image, and a button can be specified.
  • display elements can be freely arranged and a size can also be specified. For this reason, when a third-party application is not designed for in-vehicle use, it can freely display character strings, images, buttons, etc. on the screen regardless of whether the vehicle is stopped or traveling. .
  • the confirmation work by the manufacturer of the in-vehicle information device can be omitted.
  • the vehicle even when the vehicle is running, there may be cases where it is desired to browse a small amount of information or perform simple operations as long as it does not hinder driving, and the operation is uniformly prohibited while the vehicle is running. Therefore, the convenience for the user is significantly impaired.
  • Patent Document 1 the conventional technique represented by Patent Document 1 is premised on preparing in advance a menu screen suitable when the vehicle is stopped and a menu screen suitable when the vehicle is traveling. It cannot be applied as it is to a third-party application developed by a manufacturer other than the manufacturer of the in-vehicle information device. Furthermore, Patent Document 1 is premised on an application that is installed at the time of manufacture of the in-vehicle device, and does not have an idea of switching the screen display or operation content by a third-party application to a suitable one when the vehicle is running. .
  • the present invention has been made to solve the above-described problems, and an object of the present invention is to obtain a moving body information device that can display a suitable screen while the moving body is moving.
  • a first API that generates screen data having a screen configuration specified by an application and a layout of a moving screen configuration that is displayed while the mobile body is moving are defined.
  • a second API that generates screen data of a moving screen configuration designated by the application, and a first API that is provided in the application execution environment and the mobile object is stopped
  • a control unit configured to display the generated screen data on the display unit and display the screen data generated by the second API on the display unit when the moving body is moving;
  • FIG. 1 It is a block diagram which shows the structure of the information apparatus for mobile bodies which concerns on Embodiment 1 of this invention. It is a figure which shows an example of the screen data which represented the screen structure when the vehicle has stopped in the HTML (HyperText Markup Language) format. It is a figure which shows the screen displayed based on the screen data of FIG. It is a figure which shows an example of the screen data which represented the screen structure when the vehicle is drive
  • HTML HyperText Markup Language
  • FIG. 3 is a flowchart showing an operation of the mobile information device according to the first embodiment. It is a flowchart which shows operation
  • FIG. 1 is a block diagram showing a configuration of a mobile information device according to Embodiment 1 of the present invention, and shows a case where the mobile information device according to Embodiment 1 is applied to an in-vehicle information device.
  • the in-vehicle information device 1 illustrated in FIG. 1 includes an application execution environment 3 that executes the application 2, a traveling determination unit 4, a display unit 5, and an operation unit 6.
  • the application 2 is software operated by the application execution environment 3, and software that executes processing according to various purposes, for example, software that monitors and controls the in-vehicle information device 1, software that performs navigation processing And software for playing games.
  • the program of the application 2 may be stored in advance in the in-vehicle information device 1 (storage device not shown in FIG. 1), downloaded from the outside via a network, or USB ( It may be installed from an external storage medium such as a Universal Serial Bus) memory.
  • the application execution environment 3 is an execution environment for operating the application 2 and includes a control unit 31, a normal UI API 32, a running UI API 33, and an event notification unit 34 as its functions.
  • the control unit 31 is a control unit that controls the overall operation for operating the application 2.
  • the control unit 31 has a function of drawing a normal screen from screen data of a screen configuration (hereinafter referred to as a normal screen configuration) displayed while the vehicle on which the in-vehicle information device 1 is mounted is stopped, and the traveling of the vehicle It has a function of drawing a traveling screen from screen data of a screen configuration displayed inside (hereinafter referred to as a traveling screen configuration).
  • the normal UI API 32 is an API for designating a normal screen configuration from the application 2.
  • the normal UI API 32 is provided to the application 2 when screen display is performed by the processing of the application 2, and generates screen data of a normal screen configuration designated by the application 2.
  • the traveling UI API 33 is an API for designating a traveling screen configuration from the application 2.
  • the running UI API 33 is provided to the application 2 when screen display is performed by the processing of the application 2, and generates screen data of the running screen configuration designated by the application 2.
  • the UI UI 33 for traveling is limited in the designation of the screen configuration compared to the normal UI API 32, and only a screen configuration suitable for traveling of the vehicle can be designated.
  • the event notification unit 34 notifies the application 2 of events such as a change in the running state of the vehicle and a user operation event using the operation unit 6.
  • the traveling determination unit 4 determines whether the vehicle is traveling or stopped by connecting to a vehicle speed sensor or the like mounted on the vehicle, and sends the determination result to the application execution environment 3 as a traveling state change event.
  • the display unit 5 is a display device that performs screen display, and is a display device such as a liquid crystal display. In the display unit 5, screen drawing data obtained by the drawing process by the control unit 31 is displayed on the screen.
  • the operation unit 6 is an operation unit that receives an operation from the user, and is realized by, for example, a touch panel or hardware keys installed on the screen of the display unit 5 or software keys displayed on the screen.
  • FIG. 2 is a diagram illustrating an example of screen data in which the screen configuration (normal screen configuration) when the vehicle is stopped is expressed in the HTML format, and is specified using the normal UI API 32.
  • FIG. 3 is a diagram showing a screen displayed based on the screen data of FIG. In the example shown in FIG. 2, five ⁇ div> elements and four ⁇ button> elements for drawing a rectangle are described in the screen.
  • the style of each element is specified by a style specification such as padding, margin, border, width, height, background, and the like described in a CSS (Cascading Style Sheet) format in the ⁇ style> element.
  • the application 2 determines the arrangement, size, font, font size, number of characters, etc.
  • Such a normal screen configuration is designated in the normal UI API 32.
  • the normal UI API 32 generates screen data representing the normal screen configuration in an internal data format for handling in the application execution environment 3 in accordance with the content specified by the application 2.
  • This internal data format is for holding screen data so that the application execution environment 3 can be easily processed, and the format is arbitrary.
  • An example of this internal data format is DOM (Document Object Model, http://www.w3.org/DOM/), which is known as a format for processing HTML and XML by a computer program.
  • This screen data is transferred from the normal UI API 32 to the control unit 31 of the application execution environment 3.
  • the control unit 31 analyzes the screen data received from the normal UI API 32 and performs a normal screen drawing process according to a drawing command based on the analysis result.
  • the display unit 5 receives the drawing data generated by the control unit 31 and displays the screen shown in FIG.
  • FIG. 4 is a diagram showing an example of screen data expressing the screen configuration (screen configuration for traveling) when the vehicle is traveling in the XML format, and is specified using the traveling UI API 33.
  • FIG. 5 is a diagram showing a screen displayed based on the screen data of FIG.
  • the example shown in FIG. 4 is the screen data of the running screen corresponding to the normal screen shown in FIG. 3, and indicates that the screen display according to the content of “template-A” is performed.
  • “template-A” is a screen configuration prepared in advance in the running UI API 33 and includes a page header (shown as “News: Headline” in FIG. 5) and “cannot be displayed while running”. A message string and two buttons are displayed.
  • FIG. 5 is a diagram showing an example of screen data expressing the screen configuration (screen configuration for traveling) when the vehicle is traveling in the XML format, and is specified using the traveling UI API 33.
  • FIG. 5 is a diagram showing a screen displayed based on the screen data of FIG.
  • the running UI API 33 replaces the character string of the page header defined by “msg1” with “news: headline” by the ⁇ text> element according to the instruction of the application 2. , The character string of the button defined by “btn2” is replaced with “voice reading”.
  • template data that defines the layout of the on-travel screen is prepared in advance.
  • the application 2 determines display elements that constitute the traveling screen in accordance with the contents of the operation event, and designates the displayed elements in the traveling UI API 33.
  • the running UI API 33 selects the template data (“template-A”) for the above-mentioned traveling screen, and based on the display element designated by the application 2, the traveling-screen UI configuration shown in FIG. Generate screen data.
  • This screen data is transferred from the running UI API 33 to the control unit 31 of the application execution environment 3.
  • the control unit 31 analyzes the screen data received from the running UI API 33, and performs drawing processing for the running screen according to the drawing command based on the analysis result.
  • the display unit 5 receives the drawing data generated by the control unit 31 and displays the screen shown in FIG.
  • FIG. 5 for example, among the display elements in the normal screen of FIG. 3, “ABC Won!”, “Yen appreciation is more advanced”, “Partnership with DEF and GHI” are omitted.
  • the “Page” and “Next Page” buttons are omitted.
  • the screen operation is not disabled uniformly, but the driver's attention that the processing is completed with a single operation is diffused. If the operation is unlikely to be performed, the display element corresponding to the screen operation is left. For example, in FIG. 5, a “return” button for making a screen transition to the previous screen and a “speech reading” button for just reading out information by voice are displayed.
  • FIG. 6 is a diagram showing another example of screen data in which the screen configuration (screen configuration for traveling) when the vehicle is traveling is expressed in the XML format, and is specified using the traveling UI API 33.
  • FIG. 7 is a diagram showing a screen displayed based on the screen data of FIG.
  • the example shown in FIG. 6 is screen data representing a running screen corresponding to the normal screen shown in FIG. 3, and indicates that screen display according to “template-B” is performed.
  • “template-B” is a screen configuration prepared in advance in the traveling UI API 33, and a character string indicated by an identifier “msg1” and buttons “Yes” and “No” are displayed on the screen. Is done.
  • the running UI API 33 uses the ⁇ text> element to specify the character string of the page header specified by “msg1” according to the instruction of the application 2 and execute “abc”. "?”
  • the running UI API 33 selects the template data (“template-B”) for the running screen, and is expressed in the XML format as shown in FIG. 6 based on the display element specified by the application 2.
  • Screen data is generated from the running screen configuration. This screen data is transferred from the running UI API 33 to the control unit 31 of the application execution environment 3.
  • the control unit 31 analyzes the screen data received from the running UI API 33 and performs drawing processing of the running screen according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays the screen shown in FIG.
  • the layout UI screen 33 suitable for the traveling of the vehicle is defined in the traveling UI API 33 regardless of the application 2.
  • Template data is available.
  • the running UI API 33 applies a part of display elements (character string, image, button, etc.) constituting the screen to this template, Replace with simple characters or character strings prepared in advance in the data (for example, “Do you want to execute abc?”), Or perform simple screen operations in advance for the data (for example, “speech reading”) It is possible to generate screen data for a traveling screen suitable for traveling of the vehicle simply by disposing display elements corresponding to ().
  • the screen suitable for traveling of the vehicle is a screen in which display contents including display elements related to the screen operation are omitted and changed so that the driver's attention is not distracted, for example.
  • the template data is a template that defines the layout of a screen that is configured independently of the application 2, the arrangement of character strings, images, buttons, and the like that constitute the screen, size, font, font In principle, the size and number of characters cannot be changed.
  • the mode of the display element may be changeable on the condition that it is within a predetermined limit range that defines a range in which the driver's attention is not distracted. For example, when the font size suitable for the case where the vehicle is traveling is set to 20 points or more, when the traveling UI API 33 generates screen data from the template data of the traveling screen in accordance with an instruction from the application 2, The font size is changed with the 20 points as a lower limit.
  • a plurality of template data each having a plurality of layouts with screen configurations suitable for traveling of the vehicle are prepared in the application execution environment 3, and the traveling UI API 33 selects the template data from these template data.
  • the template data may be selected according to the contents specified by the application 2. Even in this case, since the layout of the screen for traveling defined in the individual template data cannot be changed from the application 2, the screen configuration specified by the application 2 is surely suitable for the traveling of the vehicle. (During driving screen). In addition, the application 2 developer can easily specify the running screen by using the template data.
  • FIG. 8 is a flowchart showing the operation of the mobile information device according to Embodiment 1, and shows details of screen display according to the stop state or running state of the vehicle.
  • FIG. 8A shows processing that occurs when the application 2 is executed
  • FIG. 8B shows processing in the application execution environment 3.
  • the control unit 31 determines the type of the received event (step ST2a).
  • the event types are a traveling state change event from the traveling determination unit 4 and an operation event from the operation unit 6.
  • the travel state change event is an event indicating a change in the travel state of the vehicle, and indicates a case where the traveling vehicle has stopped or a stopped vehicle has started traveling.
  • the operation event is an event indicating an operation such as touching a button or pressing a key displayed on the screen of the display unit 5.
  • the operation is for performing screen display by the application 2.
  • step ST2a running state change event
  • step ST2a running state change event
  • step ST6a the control unit 31 operates the operation event via the event notification unit 34 on the application 2 running in the application execution environment 3.
  • the application 2 designates a normal screen configuration corresponding to the event (step ST2). That is, when an event is notified, the application 2 calls the normal UI API 32 and designates the display elements constituting the normal screen corresponding to the event contents and the display contents thereof.
  • the normal UI API 32 generates screen data (for example, see FIG. 2) of the normal screen designated from the application 2 and passes it to the control unit 31 of the application execution environment 3.
  • the arrangement, size, font, and font size of character strings, images, buttons, and the like constituting the screen can be changed as appropriate.
  • the application 2 specifies a running screen configuration corresponding to the event notified from the application execution environment 3 (step ST3). That is, the application 2 calls the running UI API 33 and designates the display elements constituting the running screen corresponding to the event contents and the display contents thereof.
  • the running UI API 33 obtains the screen data of the running screen (see, for example, FIGS. 5 and 7) based on the template data in which the layout of the running screen configuration is defined and the content specified by the application 2. Generated and transferred to the control unit 31 of the application execution environment 3. In this way, when the screen UI is generated by the normal UI API 32, the traveling UI API 33 generates the screen data of the corresponding traveling screen configuration.
  • step ST3 the process returns to step ST1, and the process from step ST1 to step ST3 is repeated each time an event is received.
  • the control unit 31 receives the normal screen configuration (step ST4a), and then receives the traveling screen configuration (step ST5a). That is, the control unit 31 inputs screen data of the normal screen from the normal UI API 32 and inputs screen data of the during-travel screen from the during-use UI API 33. Thereafter, control unit 31 determines whether or not the vehicle is traveling (step ST6a). This determination is performed by referring to the determination result of whether or not the vehicle is traveling by the traveling determination unit 4. This process is also performed when a traveling state change event is received from the traveling determination unit 4.
  • step ST6a When the vehicle is stopped (step ST6a; NO), the control unit 31 analyzes the screen data of the normal screen, and performs the normal screen drawing process according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays the normal screen (step ST7a).
  • step ST6a When the vehicle is traveling (step ST6a; YES), the control unit 31 analyzes the screen data of the traveling screen, and performs drawing processing of the traveling screen according to the rendering command based on the analysis result. .
  • the display unit 5 receives the drawing data generated by the control unit 31 and displays a traveling screen (step ST8a). Thereafter, the application execution environment 3 repeats the above process.
  • the layout of the normal UI API 32 that generates screen data having the screen configuration designated by the application 2 and the screen configuration for traveling that is displayed while the vehicle is traveling is provided.
  • the running UI API 33 that generates screen data of the running screen configuration that is displayed while the vehicle specified by the application 2 is running, and the application execution environment 3 are provided.
  • the screen data generated by the normal UI API 32 is displayed on the display unit 5.
  • the screen data generated by the running UI API 33 is displayed on the display unit 5.
  • the control part 31 to be provided is provided.
  • the developer of the application 2 also uses a screen configuration for traveling defined in the traveling UI API 33 to display a screen suitable for traveling for each application 2 or for each process executed by the application 2. Easy to build.
  • the application execution environment 3 has a plurality of template data in which a plurality of layouts of the on-travel screen configuration are respectively defined, and the on-travel UI API 33 has a plurality of template data.
  • the screen data for the on-the-run screen configuration is generated based on the template data selected according to the specification content of the application 2, so that the screen data suitable for the traveling of the vehicle can be easily constructed. .
  • the traveling UI API 33 changes the display elements constituting the layout of the screen configuration defined by the template data in accordance with the instruction of the application 2, and the traveling screen Generate screen data for the configuration.
  • the character string in the template data that defines the screen configuration for traveling is replaced with the character string instructed from the application 2 to generate screen data for the traveling screen.
  • the screen for driving according to the application 2 can be constructed. It should be noted that the same effect can be obtained by replacing with a simple image other than characters or character strings.
  • the mode of display elements that constitute the screen for traveling generated by the traveling UI API 33 based on the template data in accordance with an instruction from the application 2 is changed to a predetermined limit range.
  • the aspect of the display element can be changed within a predetermined limit range that defines a range in which the driver's attention is not distracted. In this way, user convenience can be improved.
  • Embodiment 2 the case where the normal screen configuration and the running screen configuration are designated every time from the application 2 to the application execution environment 3 is shown.
  • the second embodiment a mode in which only the screen configuration for traveling is specified from the application 2 by notifying the application execution environment 3 to the application 2 that the vehicle is traveling will be described.
  • the application 2 performs a process of designating only the screen configuration for traveling in response to the notification indicating that the vehicle is traveling.
  • the basic configuration of the mobile information device according to the second embodiment is described in the embodiment. Same as 1. Therefore, for the configuration of the mobile information device according to Embodiment 2, the configuration of the in-vehicle information device 1 shown in FIG. 1 is referred to.
  • FIG. 9 is a flowchart showing the operation of the mobile information device according to Embodiment 2 of the present invention, and shows details of screen display according to the stop state or running state of the vehicle.
  • FIG. 9A shows processing that occurs when the application 2 is executed
  • FIG. 9B shows processing in the application execution environment 3.
  • step ST1c when the control unit 31 receives a travel state change event from the traveling determination unit 4 or an operation event from the operation unit 6 (step ST1c), the control unit 31 receives the event via the event notification unit 34. The event is notified to the application 2 (step ST2c). At this time, the control unit 31 refers to the determination result of whether or not the vehicle is traveling by the traveling determination unit 4 and includes data indicating the traveling state of the vehicle in the event to be notified. Thereafter, if the vehicle is stopped (step ST3c; NO), the control unit 31 proceeds to the process of step ST4c. If the vehicle is traveling (step ST3c; YES), the control unit 31 proceeds to the process of step ST6c. To do.
  • the application 2 determines whether or not the vehicle is traveling based on data indicating the traveling state of the vehicle included in the event (step ST2b).
  • the application 2 designates a normal screen configuration corresponding to the received event (step ST3b). That is, as in the first embodiment, the application 2 calls the normal UI API 32 and designates the display elements constituting the normal screen according to the event contents and the display contents.
  • the normal UI API 32 generates screen data of a normal screen designated by the application 2 and passes it to the control unit 31 of the application execution environment 3.
  • the control unit 31 receives the normal screen configuration (step ST4c). That is, the control unit 31 inputs the screen data of the normal screen from the normal UI API 32. Thereafter, the control unit 31 analyzes the screen data of the normal screen and performs the normal screen drawing process according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays the normal screen (step ST5c).
  • the application 2 designates a traveling screen configuration corresponding to the received event (step ST4b). That is, as in the first embodiment, the application 2 calls the running UI API 33 and designates the display elements constituting the running screen and the display contents corresponding to the event contents.
  • the running UI API 33 generates screen data for the running screen based on the template data in which the layout of the running screen configuration is defined and the content specified by the application 2, and controls the application execution environment 3. Delivered to part 31.
  • the control part 31 receives the screen structure for driving
  • step ST7c When it is determined that the screen data has been normally received (step ST7c; YES), the control unit 31 analyzes the screen data and performs a drawing process for the running screen according to the drawing command based on the analysis result.
  • the display unit 5 receives the drawing data generated by the control unit 31 and displays a traveling screen (step ST8c). Thereafter, the application execution environment 3 repeats the above process.
  • the control unit 31 determines that the screen data cannot be received normally because the screen data cannot be received in a state where it can be analyzed, or has not been received within a predetermined reception time (step ST7c; NO).
  • the default running screen data prepared in advance in the application execution environment 3 is analyzed, and the running screen is drawn according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays a predetermined traveling screen (step ST9c). Thereafter, the application execution environment 3 repeats the above process.
  • the default screen data for traveling is screen data indicating a screen with simplified display contents corresponding to the case where the vehicle is traveling, regardless of the processing corresponding to the application 2 and the event.
  • the normal UI API 32 generates screen data for the normal screen when the vehicle is stopped, and the traveling UI API 33 causes the vehicle to travel.
  • the screen data for the running screen is generated when the vehicle is running.
  • the application 2 designates one of the normal screen configuration and the running screen configuration using the normal UI API 32 and the running UI API 33 according to whether the vehicle is stopped or running. The processing amount of the application 2 can be reduced. In this case, different screen transitions are possible while the vehicle is stopped and while traveling.
  • Embodiment 3 when displaying the screen on the display unit 5, at least one screen data of the normal screen and the running screen is created and a screen related to any one of the screen data is displayed. Indicated.
  • an off-screen buffer for storing drawing data obtained by analyzing screen data is provided, and drawing data for a normal screen and a running screen are created and drawn in the off-screen buffer. A mode in which drawing data of each screen of the off-screen buffer is displayed according to the traveling state of the vehicle will be described.
  • the basic configuration of the mobile information device according to Embodiment 3 is the same as that in the above embodiment. Same as 1. Therefore, for the configuration of the mobile information device according to Embodiment 3, the configuration of the in-vehicle information device 1 shown in FIG. 1 is referred to.
  • FIG. 10 is a flowchart showing the operation of the mobile information device according to Embodiment 3 of the present invention, and shows details of screen display according to the stop state or running state of the vehicle.
  • FIG. 10A shows processing that occurs when the application 2 is executed
  • FIG. 10B shows processing in the application execution environment 3.
  • the control unit 31 determines the type of the received event (step ST2e) as in the first embodiment.
  • the event types are a traveling state change event from the traveling determination unit 4 and an operation event from the operation unit 6.
  • step ST2e running state change event
  • step ST8e the control unit 31 proceeds to the process of step ST8e.
  • step ST2e operation event
  • the control unit 31 operates the operation event via the event notification unit 34 on the application 2 executed in the application execution environment 3. Is notified (step ST3e).
  • the application 2 designates a normal screen configuration corresponding to the received event (step ST2d). That is, as in the first embodiment, the application 2 calls the normal UI API 32 and designates the display elements that constitute the normal screen according to the content of the event and the display content thereof.
  • the normal UI API 32 generates screen data of the normal screen designated by the application 2 and passes it to the control unit 31 of the application execution environment 3.
  • the application 2 designates a running screen configuration corresponding to the event notified from the application execution environment 3 (step ST3d). That is, the application 2 calls the running UI API 33 and designates the display elements constituting the running screen corresponding to the event contents and the display contents thereof.
  • the running UI API 33 generates screen data of the running screen based on the template data in which the layout of the running screen configuration is defined and the content specified from the application 2, and the control unit of the application execution environment 3 Pass to 31.
  • the traveling UI API 33 completes the process of step ST3d, the process returns to step ST1d, and the process from step ST1d to step ST3d is repeated each time an event is received.
  • the control unit 31 receives the normal screen configuration (step ST4e), and then receives the traveling screen configuration (step ST5e). That is, the control unit 31 inputs the screen data of the normal screen from the normal UI API 32 and inputs the screen data of the traveling screen from the traveling UI API 33. Next, the control unit 31 analyzes the screen data of the normal screen, generates drawing data of the normal screen according to the drawing command based on the analysis result, and draws (saves) it in the off-screen buffer (step ST6e). . Further, the control unit 31 analyzes the screen data of the traveling screen and generates drawing data of the traveling screen according to the rendering command based on the analysis result. The display layer is different from the rendering data of the normal screen. To draw (save) in the off-screen buffer (step ST7e).
  • control unit 31 determines whether or not the vehicle is traveling (step ST8e). This determination is performed by referring to the determination result as to whether or not the vehicle is traveling by the traveling determination unit 4 as in the first embodiment.
  • the control unit 31 controls the display unit 5 to display the drawing data of the normal screen drawn in the off-screen buffer. Thereby, the display unit 5 displays the normal screen drawn in the off-screen buffer (step ST9e).
  • the control unit 31 controls the display unit 5 to switch to and display the drawing data of the running screen drawn in the off-screen buffer. Thereby, the display part 5 displays the screen for driving
  • the screen data generated by the normal UI API 32 is provided with the off-screen buffer for storing the drawing data obtained by drawing the screen data.
  • the drawing data of the screen data generated by the running UI API 33 are stored in the off-screen buffer with different display layers, and are saved in the off-screen buffer depending on whether the vehicle is running or not.
  • Each drawing data is switched and displayed on the display unit 5.
  • the case where the screen for normal use and the screen for running are switched and displayed is shown.
  • the layer for the on-travel screen may be superimposed and displayed.
  • a part of the lower layer screen may be transmitted through the upper layer or semi-transparently displayed.
  • Embodiment 4 FIG.
  • the configuration including the normal UI API 32 used for specifying the normal screen configuration and the running UI API 33 used for specifying the running screen configuration is shown.
  • the fourth embodiment includes only the normal UI API 32 as the API used for designating the screen configuration.
  • the running screen is obtained from the screen data of the normal screen generated by the normal UI API 32. A mode of generating the screen data will be described.
  • FIG. 12 is a block diagram showing a configuration of a mobile information device according to Embodiment 4 of the present invention, and shows a case where the mobile information device according to Embodiment 4 is applied to an in-vehicle information device.
  • An in-vehicle information device 1A illustrated in FIG. 12 includes an application execution environment 3A for executing the application 2, a running determination unit 4, a display unit 5, and an operation unit 6.
  • the application execution environment 3A is an execution environment in which the application 2 is executed, and includes a control unit 31, a normal UI API 32, an event notification unit 34, and a running UI generation unit 35.
  • the application execution environment 3 ⁇ / b> A corresponds to the application execution environment 3 of the in-vehicle information device 1 shown in FIG. 1, in which the running UI generation unit 35 is provided instead of the running UI API 33.
  • the traveling UI generation unit 35 generates screen data for the traveling screen from the screen data for the normal screen generated by the normal UI API 32 according to a predetermined rule.
  • FIG. 12 the same components as those in FIG.
  • FIG. 13 is a flowchart showing the operation of the mobile information device according to the fourth embodiment, and shows details of screen display by the in-vehicle information device 1 ⁇ / b> A according to the stop or running of the vehicle.
  • FIG. 13A shows processing that occurs when the application 2 is executed
  • FIG. 13B shows processing in the application execution environment 3A.
  • the control unit 31 determines the type of the received event (step ST2g) as in the first embodiment.
  • the event types are a traveling state change event from the traveling determination unit 4 and an operation event from the operation unit 6.
  • step ST2g running state change event
  • step ST6g operation event
  • step ST2g operation event
  • the application 2 designates a normal screen configuration corresponding to the event (step ST2f). That is, as in the first embodiment, the application 2 calls the normal UI API 32 and designates the display elements that constitute the normal screen according to the content of the event and the display content thereof.
  • the normal UI API 32 generates screen data of the normal screen designated by the application 2 and passes it to the control unit 31 of the application execution environment 3A.
  • the control unit 31 receives the normal screen configuration (step ST4g). That is, the control unit 31 inputs screen data of the normal screen from the normal UI API 32.
  • the traveling UI generation unit 35 inputs screen data of the normal screen from the control unit 31 and automatically generates screen data of the traveling screen from the screen data based on a predetermined rule.
  • a predetermined rule For example, the following rules (1) to (3) are provided.
  • (2) The first character string in the screen data of the normal screen is extracted and replaced with the character string of the page header defined by “msg1” in the template of the traveling screen.
  • Two button elements are extracted from the head of the screen data of the normal screen, and the character string of the button in the template of the traveling screen is replaced.
  • FIG. 14 shows screen data for the running screen generated based on the rules (1) to (3) from the screen data for the normal screen shown in FIG.
  • the traveling UI generation unit 35 selects “template-A” as a template for the traveling screen, as shown in FIG.
  • the running UI generation unit 35 extracts “news: headline” (see FIG. 2), which is the first character string in the screen data of the normal screen, and “msg1” in the template defines it. Replace with the character string described in the page header.
  • the traveling UI generation unit 35 extracts “back” and “spoken reading” that are two button elements arranged in order from the top of the screen data of the normal screen, and generates a template for the traveling screen. Replace the character string written in the button inside with "Back" and "Speech Reading”. Thereby, the screen data of the in-travel screen similar to FIG. 5 is generated.
  • the control unit 31 determines whether or not the vehicle is running (step ST6g). ). This determination is performed by referring to the determination result of whether or not the vehicle is traveling by the traveling determination unit 4.
  • the control unit 31 analyzes the screen data of the normal screen, and performs the normal screen drawing process according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays the normal screen (step ST7g).
  • step ST6g when the vehicle is traveling (step ST6g; YES), the control unit 31 analyzes the screen data of the traveling screen and performs drawing processing of the traveling screen according to the rendering command based on the analysis result. .
  • the display unit 5 inputs the drawing data generated by the control unit 31 and displays the traveling screen (step ST8g). Thereafter, the application execution environment 3A repeats the above process.
  • the running UI generation unit 35 that generates the screen data of the running screen from the screen data of the normal screen is provided, the normal screen configuration is configured from the application 2. By simply designating, it is possible to simultaneously designate the screen configuration for running. Further, when the screen data is generated by the normal UI API 32, the traveling UI generation unit 35 generates screen data of the traveling screen configuration corresponding to the screen data, so that the vehicle state (stopped or traveling) is changed. When changed, it is possible to quickly switch to a screen corresponding to the state of the vehicle after the change.
  • the traveling UI generation unit 35 generates the screen data for the traveling screen from the screen data for the normal screen in step ST5g, and then the vehicle is traveling in step ST6g.
  • the traveling screen is displayed on the display unit 5 with the drawing data based on the screen data of the traveling screen is shown.
  • the present invention is not limited to the above processing flow, and the traveling UI generation unit 35 is traveling from the screen data of the normal screen until a determination result as to whether or not the vehicle is traveling is obtained.
  • the screen data for the running screen is generated from the screen data for the normal screen only when the vehicle is running according to the above judgment without generating the screen data for the driving screen, and the screen data for the running screen is displayed. You may make it display the screen for driving
  • FIG. 15 is a diagram illustrating an example of screen data in which the screen configuration when the vehicle is stopped is expressed in the HTML format, and illustrates screen data of a normal screen including an animation image as a display element.
  • FIG. 16 is a diagram showing a screen displayed based on the screen data of FIG. In FIG. 15, it is assumed that an animation element is designated by the “img” element. Also, in FIG. 16, the animation a designated by the “img” element is displayed on the right side of the rectangle in which “ABC wins!”, “Yen appreciation is more advanced”, and “Alliance with DEF and GHI” are described. It is displayed.
  • the traveling UI generation unit 35 generates screen data for the traveling screen from the screen data for the normal screen shown in FIG. 15 according to the following rules (1A) to (4A).
  • (1A) “template-C” is selected as a template for the running screen.
  • (2A) The first character string in the screen data of the normal screen is extracted and replaced with the character string of the page header defined by “msg1” in the running screen template.
  • (4A) The first animation in the screen data of the normal screen is extracted, and the “img” element is replaced with the animation converted into a still image.
  • FIG. 17 shows screen data of the traveling screen generated from the screen data of FIG. 15 by the traveling UI generation unit 35 in accordance with the rules (1A) to (4A).
  • FIG. 18 is a diagram showing a screen displayed based on the screen data of FIG. “Animation-fixed.gif” in FIG. 17 is obtained by converting the animation indicated by “animation.gif” in the screen data of the normal screen in FIG. 15 into a still image. The conversion of the animation into a still image is performed by the running UI generation unit 35. For example, a predetermined frame image (such as the first frame) in the animation is extracted to be a still image.
  • a predetermined frame image such as the first frame
  • the traveling screen shown in FIG. 18 is displayed on the display unit 5.
  • the still image b converted from the animation a is described at the location where the animation a is described on the screen of FIG.
  • the normal UI API 32 includes information constituting the running screen in the screen data of the normal screen as supplementary information, and the running UI generation unit 35 You may make it produce
  • FIG. 19 is a diagram showing screen data of a normal screen including information constituting the traveling screen. The screen data shown in FIG. 19 is obtained by adding a “running-ui type” element and a “running-param” attribute to the screen data of FIG. 2 shown in the first embodiment.
  • the “running-ui type” element indicates template data used by the screen data of the traveling screen generated from the screen data of FIG.
  • the “running-param” attribute indicates a character string described in the “text” element in the screen data of the running screen generated from the screen data of the normal screen.
  • the running UI generation unit 35 combines the “running-param” element and the “running-param” attribute, which are information constituting the running screen included in the screen data of FIG. Screen data can be generated. In the screen data of FIG. 19, screen data similar to the screen data of the traveling screen shown in FIG. 4 is generated.
  • an off-screen buffer for storing drawing data obtained by drawing the screen data is provided, and the control unit 31 has the drawing data of the screen data generated by the normal UI API 32,
  • the drawing data of the screen data generated by the traveling UI generation unit 35 is stored in the off-screen buffer with different display layers, and each drawing data stored in the off-screen buffer depending on whether or not the vehicle is traveling Are displayed on the display unit 5.
  • the normal screen or the running screen is displayed simply by switching the drawing data stored in the off-screen buffer.
  • the screen display can be switched in a short time.
  • FIG. FIG. 20 is a block diagram showing a configuration of a mobile information device according to Embodiment 5 of the present invention, and shows a case where the mobile information device according to Embodiment 5 is applied to an in-vehicle information device.
  • the in-vehicle information device 1B shown in FIG. 20 includes an application execution environment 3B that executes the application 2, a running determination unit 4, a display unit 5, an operation unit 6, and a voice operation unit 7.
  • the application execution environment 3B is an execution environment in which the application 2 is executed, and includes a control unit 31A, a normal UI API 32, a running UI API 33, and an event notification unit 34.
  • the voice operation unit 7 recognizes the voice uttered by the user and notifies the recognition result to the control unit 31A of the application execution environment 3B as a voice event.
  • a command character string is registered in the voice operation unit 7 from the control unit 31A, and if a voice that matches or resembles this command character string is emitted, it is determined that a voice event has occurred.
  • FIG. 20 the same components as those in FIG.
  • FIG. 21 is a flowchart showing the operation of the mobile information device according to the fifth embodiment, and shows details of screen display by the in-vehicle information device 1B according to the stop or running of the vehicle.
  • FIG. 21A shows processing that occurs when the application 2 is executed
  • FIG. 21B shows processing in the application execution environment 3B.
  • the control unit 31A determines the type of the received event (step ST2i).
  • the event types are a running state change event from the traveling determination unit 4, an operation event from the operation unit 6, and a voice event from the voice operation unit 7.
  • control unit 31A proceeds to the process of step ST6i.
  • event type is “operation event” or “sound event” (step ST2i; operation event or sound event)
  • the control unit 31A notifies the application 2 running in the application execution environment 3B of the event. The event is notified via the unit 34 (step ST3i).
  • the application 2 designates the normal screen configuration corresponding to the event (step ST2h). That is, as in the first embodiment, the application 2 calls the normal UI API 32 and designates the display elements that constitute the normal screen according to the content of the event and the display content thereof.
  • the normal UI API 32 generates screen data of a normal screen designated by the application 2 and transfers it to the control unit 31A of the application execution environment 3B.
  • the application 2 designates a traveling screen configuration corresponding to the event notified from the application execution environment 3B (step ST3h). That is, the application 2 calls the running UI API 33 and designates the display elements constituting the running screen corresponding to the event contents and the display contents thereof.
  • the running UI API 33 generates screen data of the running screen based on the template data in which the layout of the running screen configuration is defined and the content specified by the application 2, and the control unit 31A of the application execution environment 3B Pass to.
  • the running UI API 33 receives the voice command of the operation related to the contents of the received event. Incorporated into the screen data of the screen for running.
  • the traveling UI API 33 completes the process of step ST3h, the process returns to step ST1h, and the process from step ST1h to step ST3h is repeated every time an event is received.
  • the control unit 31A receives the normal screen configuration (step ST4i), and then receives the traveling screen configuration (step ST5i). That is, the control unit 31A inputs the screen data of the normal screen from the normal UI API 32, and inputs the screen data of the traveling screen from the traveling UI API 33. Thereafter, control unit 31A determines whether or not the vehicle is traveling (step ST6i). This determination is performed by referring to the determination result of whether or not the vehicle is traveling by the traveling determination unit 4.
  • step ST6i NO
  • the control unit 31A analyzes the screen data of the normal screen, and performs the normal screen drawing process according to the drawing command based on the analysis result.
  • the display unit 5 inputs the drawing data generated by the control unit 31A and displays the normal screen (step ST7i). Thereafter, the application execution environment 3B repeats the above processing.
  • control unit 31A analyzes the screen data of the traveling screen, and performs drawing processing of the traveling screen according to the rendering command based on the analysis result.
  • the display unit 5 receives the drawing data generated by the control unit 31A, and displays the traveling screen (step ST8i).
  • the control unit 31A registers the voice command included in the screen data of the running screen in the voice operation unit 7 (step ST9i).
  • FIG. 22 is a diagram showing screen data of a running screen in which a voice command is incorporated.
  • the screen data in FIG. 22 is obtained by adding two “speech” elements indicating voice commands to the screen data shown in FIG.
  • the control unit 31A registers the voice commands “middle” and “onsei omiage” described in the “speech” element in the voice operation unit 7. Note that the running screen displayed based on the screen data of FIG. 22 is the same as FIG.
  • the voice operation unit 7 sends a voice event to the control unit 31A of the application execution environment 3B. Notice.
  • the control unit 31 ⁇ / b> A notifies the application 2 of the audio event via the step ST event notification unit 34.
  • the recognition result is used as the voice event.
  • a voice operation unit 7 for notifying the control unit 31A is provided, and the running UI API 33 generates screen data of a running screen configuration in which voice commands are incorporated. Therefore, an operation by voice recognition can be performed on the running screen. .
  • the voice operation unit 7 is added to the configuration of the first to third embodiments.
  • the voice operation unit 7 may be added to the configuration of the fourth embodiment.
  • the traveling UI generation unit 35 when the traveling UI generation unit 35 generates screen data of the traveling screen from the screen data of the normal screen, the voice command is incorporated into the screen data of the traveling screen. In this way, the same effect as described above can be obtained.
  • the API for specifying the screen configuration in the HTML format or the XML format is shown.
  • the screen configuration may be specified in other languages or methods.
  • an API using a Java (registered trademark) language class or method may be used.
  • the traveling screen is displayed on the display unit 5 when the vehicle is traveling.
  • the vehicle has a plurality of display units for the passenger seat and the rear seat.
  • the display unit other than the display unit that is mainly visually recognized by the driver may display the normal screen without switching to the traveling screen even when the vehicle is traveling.
  • the control unit 31 specifies the display unit 5 that is mainly viewed by the driver based on the identification information that identifies each of the plurality of display units, and the vehicle is running for the display unit 5.
  • the normal screen and the running screen are switched depending on whether or not, and the display screen other than the display unit 5 displays the normal screen without switching to the running screen even when the vehicle is running. .
  • the mobile information device may be mounted on a railway, ship, or aircraft. It may be a portable information terminal that is carried by a person and used in a vehicle, for example, a PND (Portable Navigation Device).
  • PND Portable Navigation Device
  • any combination of each embodiment, any component of each embodiment can be modified, or any component can be omitted in each embodiment. .
  • the mobile information device can display a screen suitable for each of the case where the mobile body is stopped and the case where the mobile body is moving. It is suitable for in-vehicle information equipment such as.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Remote Sensing (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Multimedia (AREA)
  • User Interface Of Digital Computer (AREA)
  • Navigation (AREA)

Abstract

　アプリケーション２から指定された画面構成の画面データを生成する通常用ＵＩ　ＡＰＩ３２と、車両の走行中に表示する走行中用の画面構成のレイアウトが規定されたテンプレートデータに基づいて、アプリケーション２から指定された車両の走行中に表示する走行中用画面構成の画面データを生成する走行中用ＵＩ　ＡＰＩ３３と、アプリケーション実行環境３に設けられ、車両が停止しているとき、通常用ＵＩ　ＡＰＩ３２により生成された画面データを表示部５に表示させ、車両が走行しているときは、走行中用ＵＩ　ＡＰＩ３３により生成された画面データを表示部５に表示させる制御部３１とを備える。

Description

移動体用情報機器
　この発明は、車両などの移動体に搭載され、アプリケーション画像を表示する表示部を備えた移動体用情報機器に関する。
　車両などに搭載される情報機器では、運転者による車両の運転を妨げないように、車両が走行中であるときの画面表示およびこの画面表示に基づく操作の内容を制限する必要がある。例えば、非特許文献１には、車両用情報機器が画面に表示する情報量を、運転者が短時間で確認できるように適正化すべきことが記載されている。
　また、特許文献１には、画面表示に基づいて入力操作を行うタッチパネルなどの接触式入力手段と、ダイヤルスイッチなどの画面上のフォーカスを移動させることで選択操作を行う移動式入力手段とを備えた車載装置が開示されている。
　この装置では、車両が停車中の場合、タッチパネルによる入力に適したメニュー項目の並びで構成されるメニュー画面を表示装置に表示し、車両が走行中の場合には、ダイヤルスイッチによる入力に適したメニュー項目の並びで構成されるメニュー画面を表示装置に表示する。
　このように、特許文献１では、車両が停止中の場合に適したメニュー画面と車両が走行中の場合に適したメニュー画面を予め用意しておき、車両の状態に応じてメニュー画面を切り替えることで、メニュー項目の選択の操作性を向上させている。
　一方、近年の車載情報機器の通信機能および情報処理能力の高性能化に伴い、車載情報機器の製造メーカー以外の第三者に開発されたアプリケーション（以下、第三者アプリと記載する）を、車載情報機器にダウンロードして利用したいという要望が増えている。
　この場合も、車載情報機器の製造メーカーは、第三者アプリについて車両が走行中の場合の操作内容制限を遵守させる必要がある。
特開２００８－６５５１９号公報
「画像表示装置ガイドライン　画像表示装置の取り扱いについて　改訂第３．０版」、日本自動車工業会、平成１６年８月１８日
　第三者アプリの画面表示や操作の受け付けなどのＵＩ（Ｕｓｅｒ　Ｉｎｔｅｒｆａｃｅ）は、車載情報機器が提供するＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）を用いて開発される。ＡＰＩでは、文字列、画像、ボタンなどの画面を構成する表示要素を指定することができ、一般的には、表示要素を自由に配置でき、サイズも指定可能である。このため、第三者アプリは、車載用に設計されていない場合、車両が停止中であるか、走行中であるかにかかわらず、自由に文字列、画像、ボタンなどを画面上に表示できる。
　一方、第三者アプリが車両の走行時における操作内容制限を遵守しているか否かを確認するには、第三者アプリの車載情報機器上における全ての動作を試験して確認する必要がある。このため、車載情報機器の製造メーカーが、全ての第三者アプリに対して当該確認を実施するのは非常に困難である。
　そこで、車両が走行中であれば第三者アプリの操作を禁止すれば、車載情報機器の製造メーカーによる確認作業を省略することができる。
　しかしながら、車両が走行中であっても、運転に支障を来さない程度で、少ない情報を閲覧したり、簡易操作を行いたい場合もあり、車両の走行中に画一的に操作を禁止するのでは、ユーザの利便性が著しく損なわれる。
　また、特許文献１に代表される従来の技術では、車両が停止中の場合に適したメニュー画面と車両が走行中の場合に適したメニュー画面とを予め用意しておくことを前提としているので、車載情報機器の製造メーカー以外が開発する第三者アプリにそのまま適用することは不可能である。さらに、特許文献１は、車載装置の製造時にインストールしておくアプリケーションを前提としており、第三者アプリによる画面表示や操作内容を、車両が走行中の場合に適したものに切り替えるという発想すらない。
　この発明は、上記のような課題を解決するためになされたもので、移動体の移動中に適した画面を表示することができる移動体用情報機器を得ることを目的とする。
　この発明に係る移動体用情報機器は、アプリケーションから指定された画面構成の画面データを生成する第１のＡＰＩと、移動体の移動中に表示する移動中用の画面構成のレイアウトが規定されたテンプレートデータに基づいて、アプリケーションから指定された移動中用の画面構成の画面データを生成する第２のＡＰＩと、アプリケーション実行環境に設けられ、移動体が停止しているとき、第１のＡＰＩにより生成された画面データを表示部に表示させ、移動体が移動しているときは、第２のＡＰＩにより生成された画面データを表示部に表示させる制御部とを備える。
　この発明によれば、移動体の移動中に適した画面を表示することができるという効果がある。
この発明の実施の形態１に係る移動体用情報機器の構成を示すブロック図である。 車両が停止しているときの画面構成をＨＴＭＬ（ＨｙｐｅｒＴｅｘｔ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）形式で表現した画面データの一例を示す図である。 図２の画面データに基づいて表示される画面を示す図である。 車両が走行しているときの画面構成をＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）形式で表現した画面データの一例を示す図である。 図４の画面データに基づいて表示される画面を示す図である。 車両が走行しているときの画面構成をＸＭＬ形式で表現した画面データの別の例を示す図である。 図６の画面データに基づいて表示される画面を示す図である。 実施の形態１に係る移動体用情報機器の動作を示すフローチャートである。 この発明の実施の形態２に係る移動体用情報機器の動作を示すフローチャートである。 この発明の実施の形態３に係る移動体用情報機器の動作を示すフローチャートである。 実施の形態３における車両が走行しているときの表示画面の一例を示す図である。 この発明の実施の形態４に係る移動体用情報機器の構成を示すブロック図である。 実施の形態４に係る移動体用情報機器の動作を示すフローチャートである。 車両が走行しているときの画面構成をＸＭＬ形式で表現した画面データの一例を示す図である。 車両が停止しているときの画面構成をＨＴＭＬ形式で表現した画面データの一例を示す図である。 図１５の画面データに基づいて表示される画面を示す図である。 車両が走行しているときの画面構成をＸＭＬ形式で表現した画面データの別の例を示す図である。 図１７の画面データに基づいて表示される画面を示す図である。 車両が停止しているときの画面構成をＨＴＭＬ形式で表現した画面データの別の例を示す図である。 この発明の実施の形態５に係る移動体用情報機器の構成を示すブロック図である。 実施の形態５に係る移動体用情報機器の動作を示すフローチャートである。 車両が走行しているときの画面構成をＸＭＬ形式で表現した画面データの一例を示す図である。
　以下、この発明をより詳細に説明するため、この発明を実施するための形態について、添付の図面に従って説明する。
実施の形態１．
　図１は、この発明の実施の形態１に係る移動体用情報機器の構成を示すブロック図であり、実施の形態１に係る移動体用情報機器を車載情報機器に適用した場合を示している。図１に示す車載情報機器１には、アプリケーション２を実行するアプリケーション実行環境３、走行中判断部４、表示部５および操作部６が設けられている。
　アプリケーション２は、アプリケーション実行環境３によって動作されるソフトウエアであり、各種の目的用途に応じた処理を実行するソフトウエア、例えば車載情報機器１の監視・制御を行うソフトウエア、ナビゲーション処理を行うソフトウエア、ゲームを行うソフトウエアなどである。
　なお、アプリケーション２のプログラムは、車載情報機器１の内部（図１にて不図示の記憶装置）にあらかじめ格納したものでもよく、ネットワークを介して外部からダウンロードしたものであってもよく、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ　Ｓｅｒｉａｌ　Ｂｕｓ）メモリなどの外部記憶媒体からインストールされたものであってもよい。
　アプリケーション実行環境３は、アプリケーション２を動作させる実行環境であって、その機能として制御部３１、通常用ＵＩ　ＡＰＩ３２、走行中用ＵＩ　ＡＰＩ３３およびイベント通知部３４を備える。
　制御部３１は、アプリケーション２を動作させるための全体動作を制御する制御部である。また、制御部３１は、車載情報機器１を搭載する車両の停止中に表示する画面構成（以下、通常用画面構成と呼ぶ）の画面データから通常用画面を描画する機能と、当該車両の走行中に表示する画面構成（以下、走行中用画面構成と呼ぶ）の画面データから走行中用画面を描画する機能を有する。
　通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から通常用画面構成を指定するためのＡＰＩである。この通常用ＵＩ　ＡＰＩ３２は、アプリケーション２の処理で画面表示を行うときにアプリケーション２に提供されて、アプリケーション２から指定された通常用画面構成の画面データを生成する。
　走行中用ＵＩ　ＡＰＩ３３は、アプリケーション２から走行中用画面構成を指定するためのＡＰＩである。この走行中用ＵＩ　ＡＰＩ３３は、アプリケーション２の処理で画面表示を行うときにアプリケーション２に提供されて、アプリケーション２から指定された走行中用画面構成の画面データを生成する。なお、走行中用ＵＩ　ＡＰＩ３３は、通常用ＵＩ　ＡＰＩ３２と比べて画面構成の指定に制限があり、車両の走行中に適した画面構成のみが指定可能とされる。
　また、イベント通知部３４は、車両の走行状態の変化や操作部６を用いたユーザ操作イベントなどのイベントをアプリケーション２に通知する。
　走行中判断部４は、車両に搭載された車速センサなどに接続して当該車両が走行中であるか、停止中であるかを判断し、判断結果をアプリケーション実行環境３へ走行状態変化イベントとして通知する。
　表示部５は、画面表示を行う表示装置であり、例えば液晶ディスプレイなどの表示装置である。表示部５では、制御部３１による描画処理で得られた画面の描画データが画面に表示される。
　操作部６は、ユーザからの操作を受け付ける操作部であり、例えば表示部５の画面上に設置されたタッチパネルやハードウエアキー、画面上に表示するソフトウエアキーなどで実現される。
　図２は、車両が停止しているときの画面構成（通常用画面構成）をＨＴＭＬ形式で表現した画面データの一例を示す図であって、通常用ＵＩ　ＡＰＩ３２を用いて指定される。また、図３は、図２の画面データに基づいて表示される画面を示す図である。
　図２に示す例では、画面内に矩形を描画する＜ｄｉｖ＞要素が５つ、＜ｂｕｔｔｏｎ＞要素が４つ記述されている。また、これらの要素について＜ｓｔｙｌｅ＞要素内のＣＳＳ（Ｃａｓｃａｄｉｎｇ　Ｓｔｙｌｅ　Ｓｈｅｅｔ）形式で記述された、ｐａｄｄｉｎｇ，ｍａｒｇｉｎ，ｂｏｒｄｅｒ，ｗｉｄｔｈ，ｈｅｉｇｈｔ，ｂａｃｋｇｒｏｕｎｄなどのスタイル指定により、各要素のスタイルが指定されている。
　アプリケーション２は、操作イベントの内容に応じて、通常用画面を構成する表示要素（文字列、画像、ボタンなど）の配置、サイズ、フォント、フォントサイズ、文字数などを決定して、図２に示すような通常用画面構成を通常用ＵＩ　ＡＰＩ３２に指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２の指定内容に従って、通常用画面構成を、アプリケーション実行環境３内で扱うための内部データ形式で表現した画面データを生成する。この内部データ形式は、アプリケーション実行環境３が処理し易いように画面データを保持するためのものであり、形式は任意である。この内部データ形式の例としては、ＨＴＭＬやＸＭＬをコンピュータプログラムで処理するための形式として知られている、ＤＯＭ（Ｄｏｃｕｍｅｎｔ　Ｏｂｊｅｃｔ　Ｍｏｄｅｌ、ｈｔｔｐ：／／ｗｗｗ．ｗ３．ｏｒｇ／ＤＯＭ／）がある。ＤＯＭは、ＨＴＭＬやＸＭＬをコンピュータプログラムから扱い易いデータ形式に変換しただけであるため、以降の画面データの説明では、ＨＴＭＬまたはＸＭＬ形式で説明する。
　この画面データは、通常用ＵＩ　ＡＰＩ３２からアプリケーション実行環境３の制御部３１に受け渡される。制御部３１は、通常用ＵＩ　ＡＰＩ３２から受け付けた画面データを解析し、この解析結果に基づく描画コマンドに従って通常用画面の描画処理を行う。表示部５は、制御部３１によって生成された描画データを入力して、図３に示す画面を表示する。
　図４は、車両が走行しているときの画面構成（走行中用画面構成）をＸＭＬ形式で表現した画面データの一例を示す図であり、走行中ＵＩ　ＡＰＩ３３を用いて指定される。また、図５は、図４の画面データに基づいて表示される画面を示す図である。
　図４に示す例は、図３に示した通常用画面に対応する走行中用画面の画面データであり、“ｔｅｍｐｌａｔｅ－Ａ”の内容に従った画面表示を行うことを示している。
　ここで、“ｔｅｍｐｌａｔｅ－Ａ”は、走行中ＵＩ　ＡＰＩ３３にあらかじめ用意された画面構成であって、ページヘッダ（図５では、「ニュース：ヘッドライン」と表示）、「走行中は表示できません」のメッセージ文字列および２つのボタンが表示される。
　また、この図４の例では、走行中用ＵＩ　ＡＰＩ３３が、アプリケーション２の指示に従い、＜ｔｅｘｔ＞要素により、“ｍｓｇ１”で規定されるページヘッダの文字列を「ニュース：ヘッドライン」に置換し、“ｂｔｎ２”で規定されるボタンの文字列を「音声読上」に置換している。
　なお、アプリケーション実行環境３には、走行中用画面のレイアウトを規定するテンプレートデータがあらかじめ用意されている。
　アプリケーション２は、操作イベントの内容に応じて走行中用画面を構成する表示要素を決定して、走行中用ＵＩ　ＡＰＩ３３に指定する。走行中用ＵＩ　ＡＰＩ３３は、上記走行中用画面のテンプレートデータ（“ｔｅｍｐｌａｔｅ－Ａ”）を選択し、アプリケーション２から指定された表示要素を基に、図４に示すような走行中用画面構成から画面データを生成する。この画面データは、走行中用ＵＩ　ＡＰＩ３３からアプリケーション実行環境３の制御部３１に受け渡される。
　制御部３１は、走行中用ＵＩ　ＡＰＩ３３から受け付けた画面データを解析して、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して、図５に示す画面を表示する。
　図５では、例えば図３の通常用画面における表示要素のうち、「ＡＢＣ優勝！」、「円高がより進行」、「ＤＥＦ社、ＧＨＩ社と提携」が省略されており、また、「前ページ」および「次ページ」のボタンが省略されている。
　ただし、本発明では、従来のように、車両が走行中であれば画一的に画面操作を不可にするのではなく、一回の操作で処理が完結するような運転者の注意力を散漫にする可能性が低い操作の場合には、その画面操作に対応する表示要素を残している。例えば、図５では、前の画面に画面遷移させるための「戻る」ボタンや音声で情報の読み上げを行わせるだけの「音声読上」のボタンが表示される。
　図６は、車両が走行しているときの画面構成（走行中用画面構成）を、ＸＭＬ形式で表現した画面データの別の例を示す図であり、走行中ＵＩ　ＡＰＩ３３を用いて指定される。また、図７は、図６の画面データに基づいて表示される画面を示す図である。
　図６に示す例では、図３の通常用画面に対応する走行中用画面が表現された画面データであり、“ｔｅｍｐｌａｔｅ－Ｂ”に従った画面表示を行うことを示している。
　ここで、“ｔｅｍｐｌａｔｅ－Ｂ”は、走行中ＵＩ　ＡＰＩ３３にあらかじめ用意された画面構成であり、画面中に“ｍｓｇ１”という識別子で示される文字列と、「はい」と「いいえ」というボタンが表示される。
　また、この図６に示す例では、走行中用ＵＩ　ＡＰＩ３３が、アプリケーション２の指示に従い、＜ｔｅｘｔ＞要素により、“ｍｓｇ１”で規定されるページヘッダの文字列を、「ａｂｃを実行しますか？」という文字列に置換している。
　ここで、走行中用ＵＩ　ＡＰＩ３３は、走行中用画面のテンプレートデータ（“ｔｅｍｐｌａｔｅ－Ｂ”）を選択し、アプリケーション２から指定された表示要素を基に、図６に示すようなＸＭＬ形式で表現した走行中用画面構成から画面データを生成する。この画面データは、走行中用ＵＩ　ＡＰＩ３３からアプリケーション実行環境３の制御部３１に受け渡される。制御部３１は、走行中用ＵＩ　ＡＰＩ３３から受け付けた画面データを解析して、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して、図７に示す画面を表示する。
　以上のように、図４および図６のような画面データを構成するために、走行中用ＵＩ　ＡＰＩ３３には、アプリケーション２と無関係に、車両の走行中に適した画面構成のレイアウトが規定されたテンプレートデータが用意されている。アプリケーション２を実行して操作イベントに対応した画面表示を行うにあたり、走行中用ＵＩ　ＡＰＩ３３は、画面を構成する表示要素（文字列、画像、ボタンなど）の一部を、このテンプレートに当てはめるか、当該データにあらかじめ用意された簡易な文字または文字列（例えば、「ａｂｃを実行しますか？」）に置換するか、当該データにあらかじめ用意された簡易な画面操作（例えば、「音声読上」）に対応する表示要素を配置するだけで、車両の走行中に適した走行中用画面の画面データを生成することができる。
　なお、本発明において、車両の走行中に適した画面とは、例えば運転者の注意力が散漫にならないように画面操作に関する表示要素を含む表示内容が省略および変更された画面である。
　また、上記テンプレートデータは、アプリケーション２とは無関係に構成された画面のレイアウトを規定するテンプレートであるので、画面を構成する表示要素である文字列、画像、ボタンなどの配置、サイズ、フォント、フォントサイズ、文字数などは原則変更できない。
　しかしながら、完全に固定とするだけでなく、運転者の注意力を散漫にさせない範囲を定めた所定の制限範囲内であることを条件に表示要素の態様を変更可能としてもよい。
　例えば、車両が走行中の場合に適するフォントサイズを２０ポイント以上とした場合、走行中用ＵＩ　ＡＰＩ３３が、アプリケーション２からの指示に従って、走行中用画面のテンプレートデータから画面データを生成するときに、当該２０ポイントを下限として、フォントサイズを変更する。
　さらに、車両の走行中に適した画面構成の複数種類のレイアウトがそれぞれ規定された複数のテンプレートデータをアプリケーション実行環境３に用意しておき、走行中用ＵＩ　ＡＰＩ３３が、これらのテンプレートデータの中から、アプリケーション２の指定内容に従ってテンプレートデータを選択できるようにしてもよい。
　このようにしても、個々のテンプレートデータに規定される走行中用画面のレイアウトは、アプリケーション２から変更できないことから、アプリケーション２から指定された画面構成が、確実に車両の走行中に適した画面（走行中用画面）になる。
　また、アプリケーション２の開発者にとっても、テンプレートデータを用いることで、走行中用画面を容易に指定できるという効果がある。
　次に動作について説明する。
　図８は、実施の形態１に係る移動体用情報機器の動作を示すフローチャートであって、車両の停止状態または走行中状態に応じた画面表示の詳細を示している。
　ここで、図８（ａ）は、アプリケーション２の実行により発生する処理を示しており、図８（ｂ）は、アプリケーション実行環境３における処理を示している。
　アプリケーション実行環境３において、制御部３１は、イベントを受信すると（ステップＳＴ１ａ）、受信したイベントの種類を判定する（ステップＳＴ２ａ）。
　ここでは、イベントの種類が、走行中判断部４からの走行状態変化イベントと、操作部６からの操作イベントであるものとする。
　なお、走行状態変化イベントとは、車両の走行状態の変化を示すイベントであり、走行していた車両が停止したことや、停止していた車両が走行を開始した場合を示す。
　また、操作イベントは、表示部５の画面上に表示されたボタンのタッチやキー押下などの操作を示すイベントである。ここでは、特にアプリケーション２で画面表示を行うための操作であるものとする。
　制御部３１は、受信したイベントの種類が“走行状態変化イベント”である場合（ステップＳＴ２ａ；走行状態変化イベント）、ステップＳＴ６ａの処理に移行する。
　また、イベントの種類が“操作イベント”である場合（ステップＳＴ２ａ；操作イベント）、制御部３１は、アプリケーション実行環境３で実行しているアプリケーション２に対して、イベント通知部３４を介して操作イベントを通知する（ステップＳＴ３ａ）。
　アプリケーション２は、アプリケーション実行環境３からイベントが通知されると（ステップＳＴ１）、当該イベントに応じた通常用画面構成を指定する（ステップＳＴ２）。
　すなわち、イベントが通知されると、アプリケーション２は、通常用ＵＩ　ＡＰＩ３２を呼び出して、イベント内容に応じた通常用画面を構成する表示要素およびその表示内容を指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から指定された通常用画面の画面データ（例えば、図２参照）を生成してアプリケーション実行環境３の制御部３１に受け渡す。なお、通常用画面の生成では、画面を構成する文字列、画像、ボタンなどの配置、サイズ、フォント、フォントサイズは適宜変更可能である。
　次に、アプリケーション２は、アプリケーション実行環境３から通知されたイベントに応じた走行中用画面構成を指定する（ステップＳＴ３）。
　すなわち、アプリケーション２が、走行中用ＵＩ　ＡＰＩ３３を呼び出して、イベント内容に応じた走行中用画面を構成する表示要素およびその表示内容を指定する。
　走行中用ＵＩ　ＡＰＩ３３は、走行中用画面構成のレイアウトが規定されたテンプレートデータとアプリケーション２から指定された内容に基づいて、走行中用画面の画面データ（例えば、図５、図７参照）を生成して、アプリケーション実行環境３の制御部３１に受け渡す。このように、走行中用ＵＩ　ＡＰＩ３３が、通常用ＵＩ　ＡＰＩ３２によって画面データが生成されると、これに対応する走行中用画面構成の画面データを生成するので、例えば、車両が停止から走行中に状態が遷移したときに、通常用画面から走行中用画面に迅速に切り替えることができる。
　走行中用ＵＩ　ＡＰＩ３３が、ステップＳＴ３の処理を完了すると、ステップＳＴ１に戻り、イベントを受信するたびにステップＳＴ１からステップＳＴ３までの処理が繰り返される。
　制御部３１は、通常用画面構成を受け付け（ステップＳＴ４ａ）、次に、走行中用画面構成を受け付ける（ステップＳＴ５ａ）。すなわち、制御部３１が、通常用ＵＩ　ＡＰＩ３２から通常用画面の画面データを入力し、走行中用ＵＩ　ＡＰＩ３３から走行中用画面の画面データを入力する。この後、制御部３１は、車両が走行中であるか否かを判定する（ステップＳＴ６ａ）。この判定は、走行中判断部４による車両が走行中であるか否かの判断結果を参照することにより行う。なお、この処理は、走行中判断部４から、走行中状態変化イベントを受信した場合にも行われる。
　車両が停止中である場合（ステップＳＴ６ａ；ＮＯ）、制御部３１は、通常用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って通常用画面の描画処理を行う。表示部５は、制御部３１によって生成された描画データを入力して通常用画面を表示する（ステップＳＴ７ａ）。
　また、車両が走行中である場合（ステップＳＴ６ａ；ＹＥＳ）、制御部３１は、走行中用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して、走行中用画面を表示する（ステップＳＴ８ａ）。
　この後、アプリケーション実行環境３は、上記処理を繰り返す。
　以上のように、この実施の形態１によれば、アプリケーション２から指定された画面構成の画面データを生成する通常用ＵＩ　ＡＰＩ３２と、車両の走行中に表示する走行中用の画面構成のレイアウトが規定されたテンプレートデータに基づいて、アプリケーション２から指定された車両の走行中に表示する走行中用画面構成の画面データを生成する走行中用ＵＩ　ＡＰＩ３３と、アプリケーション実行環境３に設けられ、車両が停止しているとき、通常用ＵＩ　ＡＰＩ３２により生成された画面データを表示部５に表示させ、車両が走行しているときは、走行中用ＵＩ　ＡＰＩ３３により生成された画面データを表示部５に表示させる制御部３１とを備える。このように構成することで、アプリケーション２の動作に関わらず、車両の走行中に適した画面を表示することができる。
　また、アプリケーション２が車載情報機器メーカー以外の第三者により開発されたものであっても、車両が走行中の場合には、走行中に適した画面のみが表示されるため、走行中に不適な画面が表示されるか否かを、車載情報機器メーカーが検査する必要がない。
　なお、従来では、第三者により開発されたアプリケーションを実行した際に表示される画面が車両の走行中に適しているか否かが不明である場合、その検査の労力を考慮して車両が走行中であれば、画面を非表示とし画面操作を不可としていたが、上記実施の形態１によれば、図５や図７に示したような走行中に適した画面のみを表示することができる。
　また、テンプレートデータに簡易な画面操作の表示要素を含めておくことで、走行中用画面においても、運転者の注意が散漫にならない範囲で画面操作も可能となり、ユーザの利便性を高めることができる。
　さらに、アプリケーション２の開発者も、走行中ＵＩ　ＡＰＩ３３に定義された走行中用画面構成を利用して、アプリケーション２ごと、もしくは、アプリケーション２で実行される処理ごとに、走行中に適した画面を容易に構築することができる。
　また、この実施の形態１によれば、アプリケーション実行環境３が、走行中用画面構成の複数のレイアウトがそれぞれ規定された複数のテンプレートデータを有し、走行中用ＵＩ　ＡＰＩ３３が、複数のテンプレートデータの中から、アプリケーション２の指定内容に応じて選択したテンプレートデータに基づいて、走行中用画面構成の画面データを生成するので、車両の走行中に適した画面データを容易に構築することができる。
　さらに、この実施の形態１によれば、走行中用ＵＩ　ＡＰＩ３３が、アプリケーション２の指示に応じてテンプレートデータにより規定される画面構成のレイアウトを構成する表示要素を変更して、走行中用の画面構成の画面データを生成する。
　例えば、走行中用画面構成を規定するテンプレートデータにおける文字列を、アプリケーション２から指示された文字列に置換して走行中用画面の画面データを生成する。
　このようにすることで、アプリケーション２に応じた走行中用画面を構築することができる。なお、文字または文字列以外の簡易な画像などに置換しても同様の効果を得ることができる。
　さらに、この実施の形態１によれば、走行中用ＵＩ　ＡＰＩ３３が、アプリケーション２の指示に応じて、テンプレートデータに基づいて生成した走行中用画面を構成する表示要素の態様を、所定の制限範囲内で変更する。例えば、運転者の注意力を散漫にさせない範囲を定めた所定の制限範囲内で表示要素の態様を変更可能とする。このようにすることで、ユーザの利便性を向上させることができる。
実施の形態２．
　上記実施の形態１では、アプリケーション２からアプリケーション実行環境３に対して通常用画面構成および走行中用画面構成を毎回指定する場合を示した。
　この実施の形態２では、アプリケーション実行環境３からアプリケーション２へ車両が走行中である旨を通知することで、アプリケーション２から走行中用画面構成のみを指定する態様について述べる。
　なお、車両の走行中を示す通知に応じてアプリケーション２が走行中用画面構成のみを指定する処理を行うが、実施の形態２に係る移動体用情報機器の基本的な構成は、実施の形態１と同様である。従って、実施の形態２に係る移動体用情報機器の構成については、図１に示した車載情報機器１の構成を参照することとする。
　次に動作について説明する。
　図９は、この発明の実施の形態２に係る移動体用情報機器の動作を示すフローチャートであって、車両の停止状態または走行中状態に応じた画面表示の詳細を示している。
　ここで、図９（ａ）は、アプリケーション２の実行により発生する処理を示しており、図９（ｂ）は、アプリケーション実行環境３における処理を示している。
　アプリケーション実行環境３において、制御部３１は、走行中判断部４からの走行状態変化イベント、もしくは、操作部６からの操作イベントを受信すると（ステップＳＴ１ｃ）、イベント通知部３４を介して、受信したイベントをアプリケーション２に通知する（ステップＳＴ２ｃ）。
　このとき、制御部３１は、走行中判断部４による車両が走行中であるか否かの判断結果を参照して、通知するイベントに車両の走行状態を示すデータを含める。この後、制御部３１は、車両が停止中であれば（ステップＳＴ３ｃ；ＮＯ）、ステップＳＴ４ｃの処理に移行し、車両が走行中であれば（ステップＳＴ３ｃ；ＹＥＳ）、ステップＳＴ６ｃの処理に移行する。
　アプリケーション２は、アプリケーション実行環境３からイベントが通知されると（ステップＳＴ１ｂ）、当該イベントに含まれる車両の走行状態を示すデータに基づいて車両が走行中か否かを判定する（ステップＳＴ２ｂ）。
　ここで、車両が停止中であれば（ステップＳＴ２ｂ；ＮＯ）、アプリケーション２は、受信したイベントに対応する通常用画面構成を指定する（ステップＳＴ３ｂ）。
　すなわち、上記実施の形態１と同様に、アプリケーション２は、通常用ＵＩ　ＡＰＩ３２を呼び出して、イベント内容に応じた通常用画面を構成する表示要素およびその表示内容を指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から指定された通常用画面の画面データを生成してアプリケーション実行環境３の制御部３１に受け渡す。
　制御部３１は、通常用画面構成を受け付ける（ステップＳＴ４ｃ）。すなわち、制御部３１が、通常用ＵＩ　ＡＰＩ３２から通常用画面の画面データを入力する。
　この後、制御部３１は、通常用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って、通常用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して通常用画面を表示する（ステップＳＴ５ｃ）。
　一方、車両が走行中であると（ステップＳＴ２ｂ；ＹＥＳ）、アプリケーション２は、受信したイベントに対応する走行中用画面構成を指定する（ステップＳＴ４ｂ）。
　すなわち、上記実施の形態１と同様に、アプリケーション２が、走行中用ＵＩ　ＡＰＩ３３を呼び出して、イベント内容に応じた走行中用画面を構成する表示要素およびその表示内容を指定する。走行中用ＵＩ　ＡＰＩ３３は、走行中用画面構成のレイアウトが規定されたテンプレートデータとアプリケーション２から指定された内容に基づいて、走行中用画面の画面データを生成して、アプリケーション実行環境３の制御部３１に受け渡す。
　続いて、制御部３１は、走行中用画面構成を受け付ける（ステップＳＴ６ｃ）。
　すなわち、制御部３１が、走行中用ＵＩ　ＡＰＩ３３から走行中用画面の画面データを入力する。このとき、制御部３１は、走行中用ＵＩ　ＡＰＩ３３から画面データを正常に受け付けたか否かを判定する（ステップＳＴ７ｃ）。ここでは、画面データが解析可能な状態で受信できたか、または、所定の受付時間内に受信できたかを、判定基準として正常に受け付けられたか否かが判定される。
　画面データを正常に受け付けたと判定した場合（ステップＳＴ７ｃ；ＹＥＳ）、制御部３１は、当該画面データを解析して、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して、走行中用画面を表示する（ステップＳＴ８ｃ）。
　この後、アプリケーション実行環境３は、上記処理を繰り返す。
　また、制御部３１は、画面データが解析可能な状態で受信できなかったり、所定の受付時間内に受信できなかったことで、画面データを正常に受け付けられなかったと判定した場合（ステップＳＴ７ｃ；ＮＯまたはＴｉｍｅ　ｏｕｔ）、アプリケーション実行環境３にあらかじめ用意した既定の走行中用画面データを解析し、この解析結果に基づいた描画コマンドに従って、走行中用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して既定の走行中用画面を表示する（ステップＳＴ９ｃ）。
　この後、アプリケーション実行環境３は、上記処理を繰り返す。
　なお、既定の走行中用画面データとは、アプリケーション２およびイベントに対応する処理とは無関係に、車両が走行中の場合に対応して表示内容を簡易にした画面を示す画面データである。
　以上のように、この実施の形態２によれば、通常用ＵＩ　ＡＰＩ３２が、車両が停止しているときに通常用画面の画面データを生成し、走行中用ＵＩ　ＡＰＩ３３が、車両が走行しているときに、走行中用画面の画面データを生成する。
　このように、アプリケーション２が、車両の停止または走行中に応じて、通常用ＵＩ　ＡＰＩ３２および走行中用ＵＩ　ＡＰＩ３３を用いて通常用画面構成と走行中用画面構成のいずれか一方を指定することで、アプリケーション２の処理量を減らすことができる。
　なお、この場合、車両の停止中と走行中で互いに異なる画面遷移が可能である。
実施の形態３．
　上記実施の形態１，２では、表示部５に画面表示する際に、通常用画面および走行中用画面の少なくとも一方の画面データを作成し、いずれか一方の画面データに関する画面を表示する場合について示した。
　この実施の形態３は、画面データを解析して得られた描画データを保存するオフスクリーンバッファを設けて、通常用画面と走行中用画面の描画データをそれぞれ作成してオフスクリーンバッファに描画しておき、車両の走行状態に応じてオフスクリーンバッファの各画面の描画データを表示する態様について述べる。
　なお、オフスクリーンバッファに通常用画面と走行中用画面を描画して画面表示を行う処理動作を行うが、実施の形態３に係る移動体用情報機器の基本的な構成は、上記実施の形態１と同様である。従って、この実施の形態３に係る移動体用情報機器の構成については、図１に示した車載情報機器１の構成を参照することとする。
　次に動作について説明する。
　図１０は、この発明の実施の形態３に係る移動体用情報機器の動作を示すフローチャートであって、車両の停止状態または走行中状態に応じた画面表示の詳細を示している。
　ここで、図１０（ａ）はアプリケーション２の実行により発生する処理を示しており、図１０（ｂ）はアプリケーション実行環境３における処理を示している。
　アプリケーション実行環境３において、制御部３１は、イベントを受信すると（ステップＳＴ１ｅ）、上記実施の形態１と同様に、受信したイベントの種類を判定する（ステップＳＴ２ｅ）。ここでは、イベントの種類が、走行中判断部４からの走行状態変化イベントと、操作部６からの操作イベントであるものとする。
　制御部３１は、受信したイベントの種類が“走行状態変化イベント”である場合（ステップＳＴ２ｅ；走行状態変化イベント）、ステップＳＴ８ｅの処理に移行する。
　また、イベントの種類が“操作イベント”である場合（ステップＳＴ２ｅ；操作イベント）、制御部３１は、アプリケーション実行環境３で実行しているアプリケーション２に対して、イベント通知部３４を介して操作イベントを通知する（ステップＳＴ３ｅ）。
　アプリケーション２は、アプリケーション実行環境３からイベントが通知されると（ステップＳＴ１ｄ）、受信したイベントに対応する通常用画面構成を指定する（ステップＳＴ２ｄ）。すなわち、上記実施の形態１と同様に、アプリケーション２は、通常用ＵＩ　ＡＰＩ３２を呼び出して、イベントの内容に応じた通常用画面を構成する表示要素およびその表示内容を指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から指定された通常用画面の画面データを生成して、アプリケーション実行環境３の制御部３１に受け渡す。
　次に、アプリケーション２は、アプリケーション実行環境３から通知されたイベントに応じた走行中用画面構成を指定する（ステップＳＴ３ｄ）。
　すなわち、アプリケーション２が、走行中用ＵＩ　ＡＰＩ３３を呼び出して、イベント内容に応じた走行中用画面を構成する表示要素およびその表示内容を指定する。
　走行中用ＵＩ　ＡＰＩ３３は、走行中用画面構成のレイアウトが規定されたテンプレートデータとアプリケーション２から指定された内容に基づいて走行中用画面の画面データを生成して、アプリケーション実行環境３の制御部３１に受け渡す。
　走行中用ＵＩ　ＡＰＩ３３がステップＳＴ３ｄの処理を完了すると、ステップＳＴ１ｄに戻り、イベントを受信するたびにステップＳＴ１ｄからステップＳＴ３ｄまでの処理が繰り返される。
　制御部３１は、通常用画面構成を受け付け（ステップＳＴ４ｅ）、次に、走行中用画面構成を受け付ける（ステップＳＴ５ｅ）。すなわち、制御部３１が、通常用ＵＩ　ＡＰＩ３２から通常用画面の画面データを入力し、走行中用ＵＩ　ＡＰＩ３３から走行中用画面の画面データを入力する。
　次いで、制御部３１は、通常用画面の画面データを解析して、この解析結果に基づいた描画コマンドに従って通常用画面の描画データを生成してオフスクリーンバッファに描画（保存）する（ステップＳＴ６ｅ）。
　さらに、制御部３１は、走行中用画面の画面データを解析して、この解析結果に基づいた描画コマンドに従って走行中用画面の描画データを生成し、通常用画面の描画データとは表示レイヤ違いでオフスクリーンバッファに描画（保存）する（ステップＳＴ７ｅ）。
　この後、制御部３１は、車両が走行中であるか否かを判定する（ステップＳＴ８ｅ）。この判定は、上記実施の形態１と同様に、走行中判断部４による車両が走行中であるか否かの判断結果を参照することにより行う。
　車両が停止中の場合（ステップＳＴ８ｅ；ＮＯ）、制御部３１は、表示部５に対して、オフスクリーンバッファに描画した通常用画面の描画データを表示するように制御する。これにより、表示部５は、オフスクリーンバッファに描画された通常用画面を表示する（ステップＳＴ９ｅ）。
　また、車両が走行中の場合（ステップＳＴ８ｅ；ＹＥＳ）、制御部３１は、表示部５に対して、オフスクリーンバッファに描画した走行中用画面の描画データに切り替えて表示するように制御する。これにより、表示部５は、オフスクリーンバッファに描画された走行中用画面を表示する（ステップＳＴ１０ｅ）。
　以上のように、この実施の形態３によれば、画面データを描画処理して得られた描画データを保存するオフスクリーンバッファを備え、制御部３１が、通常用ＵＩ　ＡＰＩ３２により生成された画面データの描画データと、走行中用ＵＩ　ＡＰＩ３３により生成された画面データの描画データとを表示レイヤ違いでオフスクリーンバッファに保存し、車両が走行しているか否かに応じてオフスクリーンバッファに保存された各描画データを切り替えて表示部５に表示させる。このように構成することで、車両の状態が変化した際に、オフスクリーンバッファに保存した描画データを切り替えるだけで、通常用画面または走行中用画面を表示することができ、画面表示の切り替えを短時間で行うことができる。
　なお、上記実施の形態３では、通常用画面と走行中用画面を切り替えて表示する場合を示したが、例えば、車両が走行中の場合、図１１に示すように、通常用画面のレイヤ上に走行中用画面のレイヤを重ねて表示してもよい。この場合、デザイン性を向上させるために、下層の画面の一部を上層に透過または半透過させて表示してもよい。
実施の形態４．
　上記実施の形態１～３では、通常用画面構成の指定に用いる通常用ＵＩ　ＡＰＩ３２と走行中用画面構成の指定に用いる走行中用ＵＩ　ＡＰＩ３３を備えた構成を示した。
　この実施の形態４は、画面構成指定に用いるＡＰＩとして通常用ＵＩ　ＡＰＩ３２のみを備え、車両が走行中の場合には、通常用ＵＩ　ＡＰＩ３２が生成した通常用画面の画面データから、走行中用画面の画面データを生成する態様について述べる。
　図１２は、この発明の実施の形態４に係る移動体用情報機器の構成を示すブロック図であり、実施の形態４に係る移動体用情報機器を車載情報機器に適用した場合を示している。図１２に示す車載情報機器１Ａには、アプリケーション２を実行するアプリケーション実行環境３Ａ、走行中判断部４、表示部５および操作部６が設けられている。
　アプリケーション実行環境３Ａは、アプリケーション２が実行される実行環境であり、制御部３１、通常用ＵＩ　ＡＰＩ３２、イベント通知部３４および走行中用ＵＩ生成部３５を備える。すなわち、アプリケーション実行環境３Ａは、図１に示した車載情報機器１のアプリケーション実行環境３のうち、走行中用ＵＩ　ＡＰＩ３３の代わりに、走行中用ＵＩ生成部３５を設けたものに相当する。
　走行中用ＵＩ生成部３５は、通常用ＵＩ　ＡＰＩ３２が生成した通常用画面の画面データから、所定のルールに従って走行中用画面の画面データを生成する。なお、図１２において、図１と同一の構成要素には、同一符号を付して説明を省略する。
　次に動作について説明する。
　図１３は、実施の形態４に係る移動体用情報機器の動作を示すフローチャートであり、車両の停止または走行に応じた車載情報機器１Ａによる画面表示の詳細を示している。
　ここで、図１３（ａ）は、アプリケーション２の実行により発生する処理を示しており、図１３（ｂ）は、アプリケーション実行環境３Ａにおける処理を示している。
　アプリケーション実行環境３Ａにおいて、制御部３１は、イベントを受信すると（ステップＳＴ１ｇ）、上記実施の形態１と同様に、受信したイベントの種類を判定する（ステップＳＴ２ｇ）。ここでは、イベントの種類が、走行中判断部４からの走行状態変化イベントと、操作部６からの操作イベントであるものとする。
　制御部３１は、受信したイベントの種類が“走行状態変化イベント”である場合（ステップＳＴ２ｇ；走行状態変化イベント）、ステップＳＴ６ｇの処理に移行する。
　また、イベントの種類が“操作イベント”である場合（ステップＳＴ２ｇ；操作イベント）、制御部３１は、アプリケーション実行環境３Ａで実行しているアプリケーション２に対して、イベント通知部３４を介して操作イベントを通知する（ステップＳＴ３ｇ）。
　アプリケーション２は、アプリケーション実行環境３Ａからイベントが通知されると（ステップＳＴ１ｆ）、当該イベントに対応する通常用画面構成を指定する（ステップＳＴ２ｆ）。すなわち、上記実施の形態１と同様に、アプリケーション２は、通常用ＵＩ　ＡＰＩ３２を呼び出して、イベントの内容に応じた通常用画面を構成する表示要素およびその表示内容を指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から指定された通常用画面の画面データを生成して、アプリケーション実行環境３Ａの制御部３１に受け渡す。制御部３１は、通常用画面構成を受け付ける（ステップＳＴ４ｇ）。すなわち、制御部３１が、通常用ＵＩ　ＡＰＩ３２から通常用画面の画面データを入力する。
　次に、走行中用ＵＩ生成部３５は、制御部３１から通常用画面の画面データを入力して、この画面データから所定のルールに基づいて、走行中用画面の画面データを自動的に生成する（ステップＳＴ５ｇ）。
　例えば、下記（１）～（３）のルールを設ける。
（１）走行中用画面のテンプレートとして“ｔｅｍｐｌａｔｅ－Ａ”を選択する。
（２）通常用画面の画面データにおける最初の文字列を抽出して、走行中用画面のテンプレート中の“ｍｓｇ１”が規定するページヘッダの文字列として置き換える。
（３）通常用画面の画面データにおける先頭からｂｕｔｔｏｎ要素を２つ抽出して、走行中用画面のテンプレート中のボタンの文字列を置き換える。
　図１４は、図２に示した通常用画面の画面データから、上記（１）～（３）のルールに基づいて生成された走行中用画面の画面データである。
　走行中用ＵＩ生成部３５は、図１４に示すように、走行中用画面のテンプレートとして“ｔｅｍｐｌａｔｅ－Ａ”を選択する。
　次に、走行中用ＵＩ生成部３５は、通常用画面の画面データにおける最初の文字列である「ニュース：ヘッドライン」（図２参照）を抽出し、上記テンプレート中の“ｍｓｇ１”が規定するページヘッダに記述する文字列として置き換える。
　続いて、走行中用ＵＩ生成部３５は、通常用画面の画面データの先頭から順に並んだ２つのｂｕｔｔｏｎ要素である「戻る」と「音声読上」を抽出して、走行中用画面のテンプレート中のボタンに記述する文字列を「戻る」と「音声読上」に置き換える。
　これにより、図５と同様な走行中用画面の画面データが生成される。
　図１３の説明に戻る。
　制御部３１は、通常用画面の画面データと、走行中用ＵＩ生成部３５により生成された走行中用画面の画面データを入力すると、車両が走行中であるか否かを判定する（ステップＳＴ６ｇ）。この判定は、走行中判断部４による車両が走行中であるか否かの判断結果を参照することにより行う。
　車両が停止中である場合（ステップＳＴ６ｇ；ＮＯ）、制御部３１は、通常用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って通常用画面の描画処理を行う。表示部５は、制御部３１により生成された描画データを入力して通常用画面を表示する（ステップＳＴ７ｇ）。
　一方、車両が走行中である場合（ステップＳＴ６ｇ；ＹＥＳ）、制御部３１は、走行中用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１によって生成された描画データを入力して走行中用画面を表示する（ステップＳＴ８ｇ）。
　この後、アプリケーション実行環境３Ａは、上記処理を繰り返す。
　以上のように、この実施の形態４によれば、通常用画面の画面データから走行中用画面の画面データを生成する走行中用ＵＩ生成部３５を備えたので、アプリケーション２から通常用画面構成を指定するだけで、走行中用画面構成も同時に指定することができる。
　また、走行中用ＵＩ生成部３５は、通常用ＵＩ　ＡＰＩ３２によって画面データが生成されると、これに対応する走行中用画面構成の画面データを生成するので、車両の状態（停止または走行）が変化した際に、変化後の車両の状態に対応する画面に迅速に切り替えることが可能である。
　また、上記実施の形態４では、ステップＳＴ５ｇで、走行中用ＵＩ生成部３５が、通常用画面の画面データから走行中用画面の画面データを生成してから、ステップＳＴ６ｇで車両が走行中の場合に、走行中用画面の画面データに基づく描画データで表示部５に走行中用画面を表示する場合を示した。
　本発明は、上記処理の流れに限定されるものではなく、車両が走行中であるか否かの判定結果がでるまで、走行中用ＵＩ生成部３５が、通常用画面の画面データから走行中用画面の画面データを生成せず、上記判定で車両が走行中である場合にのみ、通常用画面の画面データから走行中用画面の画面データを生成して、走行中用画面の画面データに基づく描画データで表示部５に走行中用画面を表示するようにしてもよい。
　さらに、上記実施の形態４において、表示部５に、画像、アニメーション、映像などを表示するにあたり、アニメーションや映像などの動画については、車両が走行中の場合、静止画に変更して表示することが望ましい。
　図１５は、車両が停止しているときの画面構成をＨＴＭＬ形式で表現した画面データの一例を示す図であり、表示要素にアニメーション画像を含んだ通常用画面の画面データを示している。また、図１６は、図１５の画面データに基づいて表示される画面を示す図である。図１５において、“ｉｍｇ”要素でアニメーション要素が指定されているものとする。また、図１６において、“ｉｍｇ”要素で指定されるアニメーションａは、「ＡＢＣが優勝！」、「円高がより進行」、「ＤＥＦ社、ＧＨＩ社と提携」が記述された矩形の右側に表示されている。
　走行中用ＵＩ生成部３５は、図１５に示す通常用画面の画面データから、下記（１Ａ）～（４Ａ）のルールに従って、走行中用画面の画面データを生成する。
（１Ａ）走行中用画面のテンプレートとして“ｔｅｍｐｌａｔｅ－Ｃ”を選択する。
（２Ａ）通常用画面の画面データにおける最初の文字列を抽出して、走行中用画面のテンプレート中の“ｍｓｇ１”が規定するページヘッダの文字列として置き換える。
（３Ａ）通常用画面の画面データにおける先頭からｂｕｔｔｏｎ要素を２つ抽出し、走行中用画面のテンプレート中のボタンの文字列を置き換える。
（４Ａ）通常用画面の画面データ中の最初のアニメーションを抽出し、このアニメーションを静止画に変換したもので“ｉｍｇ”要素を置き換える。
　図１７は、走行中用ＵＩ生成部３５が、上記（１Ａ）～（４Ａ）のルールに従って、図１５の画面データから生成した走行中用画面の画面データを示している。また図１８は、図１７の画面データに基づいて表示される画面を示す図である。
　図１７における“ａｎｉｍａｔｉｏｎ－ｆｉｘｅｄ．ｇｉｆ”は、図１５の通常用画面の画面データにおける“ａｎｉｍａｔｉｏｎ．ｇｉｆ”で示されるアニメーションを静止画に変換したものである。アニメーションの静止画への変換は、走行中用ＵＩ生成部３５により実施され、例えば、アニメーションにおける所定のフレーム画像（最初のフレームなど）を抽出して静止画とする。
　図１７の画面データに基づいて生成された描画データにより、表示部５には、図１８に示す走行中用画面が表示される。図１８に示すように、図１６の画面でアニメーションａが記載されていた箇所に、アニメーションａから変換された静止画ｂが記載されている。
　上記のように、通常用画面の画面データから走行中用画面の画面データを生成する際、アニメーションや動画を静止画に変換することで、車両の走行中に適した画面を表示することができる。
　さらに、上記実施の形態４において、通常用ＵＩ　ＡＰＩ３２が、通常用画面の画面データの中に走行中用画面を構成する情報を付帯情報として含めておき、走行中用ＵＩ生成部３５が、この付帯情報から走行中用画面の画面データを生成するようにしてもよい。
　図１９は、走行中用画面を構成する情報を含んだ通常用画面の画面データを示す図である。図１９に示す画面データは、実施の形態１で示した図２の画面データに対して“ｒｕｎｎｉｎｇ－ｕｉ　ｔｙｐｅ”要素と“ｒｕｎｎｉｎｇ－ｐａｒａｍ”属性を追加したものである。ここで、“ｒｕｎｎｉｎｇ－ｕｉ　ｔｙｐｅ”要素は、図１９の画面データから生成される走行中用画面の画面データが用いるテンプレートデータを示している。
　また、“ｒｕｎｎｉｎｇ－ｐａｒａｍ”属性は、上記通常用画面の画面データから生成される走行中用画面の画面データ中の“ｔｅｘｔ”要素に記述される文字列であることを示している。
　走行中用ＵＩ生成部３５は、図１９の画面データに含まれる走行中用画面を構成する情報である“ｒｕｎｎｉｎｇ－ｕｉ　ｔｙｐｅ”要素と“ｒｕｎｎｉｎｇ－ｐａｒａｍ”属性の内容を組み合わせることで、走行中用画面の画面データを生成することができる。
　図１９の画面データでは、図４に示した走行中用画面の画面データと同様の画面データが生成される。
　さらに、上記実施の形態４において、画面データを描画処理して得られた描画データを保存するオフスクリーンバッファを設け、制御部３１が、通常用ＵＩ　ＡＰＩ３２により生成された画面データの描画データと、走行中用ＵＩ生成部３５により生成された画面データの描画データとを表示レイヤ違いでオフスクリーンバッファに保存し、車両が走行しているか否かに応じてオフスクリーンバッファに保存された各描画データを切り替えて表示部５に表示させる。このように構成することでも、上記実施の形態４と同様に、車両の状態が変化した際に、オフスクリーンバッファに保存した描画データを切り替えるだけで、通常用画面または走行中用画面を表示することができ、画面表示の切り替えを短時間で行うことができる。
実施の形態５．
　図２０は、この発明の実施の形態５に係る移動体用情報機器の構成を示すブロック図であり、実施の形態５に係る移動体用情報機器を車載情報機器に適用した場合を示している。図２０に示す車載情報機器１Ｂには、アプリケーション２を実行するアプリケーション実行環境３Ｂ、走行中判断部４、表示部５、操作部６および音声操作部７が設けられる。
　また、アプリケーション実行環境３Ｂは、アプリケーション２が実行される実行環境であり、制御部３１Ａ、通常用ＵＩ　ＡＰＩ３２、走行中用ＵＩ　ＡＰＩ３３およびイベント通知部３４を備える。
　音声操作部７は、ユーザが発した音声を認識して、その認識結果を音声イベントとしてアプリケーション実行環境３Ｂの制御部３１Ａに通知する。ここでは、制御部３１Ａから音声操作部７にコマンド文字列を登録しておき、このコマンド文字列に一致または類似する音声が発せられた場合に、音声イベントが発生したと判断される。
　なお、図２０において、図１と同一構成要素には同一の符号を付して説明を省略する。
　次に動作について説明する。
　図２１は、実施の形態５に係る移動体用情報機器の動作を示すフローチャートであり、車両の停止または走行に応じた車載情報機器１Ｂによる画面表示の詳細を示している。
　ここで、図２１（ａ）は、アプリケーション２の実行により発生する処理を示しており、図２１（ｂ）は、アプリケーション実行環境３Ｂにおける処理を示している。
　アプリケーション実行環境３Ｂにおいて、制御部３１Ａは、イベントを受信すると（ステップＳＴ１ｉ）、受信したイベントの種類を判定する（ステップＳＴ２ｉ）。
　ここでは、イベントの種類が、走行中判断部４からの走行状態変化イベントと、操作部６からの操作イベントと、音声操作部７からの音声イベントであるものとする。
　制御部３１Ａは、受信したイベントの種類が“走行状態変化イベント”である場合（ステップＳＴ２ｉ；走行状態変化イベント）、ステップＳＴ６ｉの処理に移行する。
　また、イベントの種類が“操作イベント”または“音声イベント”である場合（ステップＳＴ２ｉ；操作イベントまたは音声イベント）、制御部３１Ａは、アプリケーション実行環境３Ｂで実行しているアプリケーション２に対し、イベント通知部３４を介して当該イベントを通知する（ステップＳＴ３ｉ）。
　アプリケーション２は、アプリケーション実行環境３Ｂからイベントが通知されると（ステップＳＴ１ｈ）、当該イベントに対応する通常用画面構成を指定する（ステップＳＴ２ｈ）。すなわち、上記実施の形態１と同様に、アプリケーション２は、通常用ＵＩ　ＡＰＩ３２を呼び出して、イベントの内容に応じた通常用画面を構成する表示要素およびその表示内容を指定する。通常用ＵＩ　ＡＰＩ３２は、アプリケーション２から指定された通常用画面の画面データを生成してアプリケーション実行環境３Ｂの制御部３１Ａに受け渡す。
　次に、アプリケーション２は、アプリケーション実行環境３Ｂから通知されたイベントに対応する走行中用画面構成を指定する（ステップＳＴ３ｈ）。
　すなわち、アプリケーション２が、走行中用ＵＩ　ＡＰＩ３３を呼び出して、イベント内容に応じた走行中用画面を構成する表示要素およびその表示内容を指定する。走行中用ＵＩ　ＡＰＩ３３は、走行中用画面構成のレイアウトが規定されたテンプレートデータとアプリケーション２から指定された内容に基づいて走行中用画面の画面データを生成し、アプリケーション実行環境３Ｂの制御部３１Ａに受け渡す。
　なお、音声操作は、手動で操作する必要のない車両の走行中に適した操作であるので、この実施の形態５に係る走行中用ＵＩ　ＡＰＩ３３は、受信したイベントの内容に関する操作の音声コマンドを走行中用画面の画面データに組み込む。
　走行中用ＵＩ　ＡＰＩ３３がステップＳＴ３ｈの処理を完了すると、ステップＳＴ１ｈに戻り、イベントを受信するたびにステップＳＴ１ｈからステップＳＴ３ｈまでの処理が繰り返される。
　制御部３１Ａは、通常用画面構成を受け付け（ステップＳＴ４ｉ）、次に走行中用画面構成を受け付ける（ステップＳＴ５ｉ）。すなわち、制御部３１Ａが、通常用ＵＩ　ＡＰＩ３２から通常用画面の画面データを入力し、走行中用ＵＩ　ＡＰＩ３３から走行中用画面の画面データを入力する。
　この後、制御部３１Ａは車両が走行中であるか否かを判定する（ステップＳＴ６ｉ）。この判定は、走行中判断部４による車両が走行中であるか否かの判断結果を参照することにより行う。
　車両が停止中である場合（ステップＳＴ６ｉ；ＮＯ）、制御部３１Ａは、通常用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って、通常用画面の描画処理を行う。表示部５は、制御部３１Ａにより生成された描画データを入力して通常用画面を表示する（ステップＳＴ７ｉ）。この後、アプリケーション実行環境３Ｂは、上記の処理を繰り返す。
　一方、車両が走行中の場合（ステップＳＴ６ｉ；ＹＥＳ）、制御部３１Ａは、走行中用画面の画面データを解析し、この解析結果に基づいた描画コマンドに従って走行中用画面の描画処理を行う。表示部５は、制御部３１Ａにより生成された描画データを入力して、走行中用画面を表示する（ステップＳＴ８ｉ）。
　次に、制御部３１Ａは、走行中用画面の画面データに含まれる音声コマンドを音声操作部７に登録する（ステップＳＴ９ｉ）。
　図２２は、音声コマンドが組み込まれた走行中用画面の画面データを示す図である。
　図２２の画面データは、図４に示した画面データに対して、音声コマンドを示す“ｓｐｅｅｃｈ”要素を２つ追加したものである。ステップＳＴ９ｉにおいて、制御部３１Ａが、“ｓｐｅｅｃｈ”要素に記述されている「モドル」および「オンセイヨミアゲ」という音声コマンドを音声操作部７に登録する。なお、図２２の画面データに基づいて表示される走行中用画面は、図５と同様である。
　上記走行中用画面が表示部５に表示されている際に、上記の音声コマンドに一致または類似する音声が発せられると、音声操作部７は、アプリケーション実行環境３Ｂの制御部３１Ａに音声イベントを通知する。制御部３１Ａは、音声操作部７からの音声イベントを受信すると、ステップＳＴイベント通知部３４を介して当該音声イベントをアプリケーション２へ通知する。
　以上のように、この実施の形態５によれば、ユーザが発した音声を認識して、認識結果が制御部３１Ａから登録された音声コマンドに一致または類似する場合、当該認識結果を音声イベントとして制御部３１Ａに通知する音声操作部７を備え、走行中用ＵＩ　ＡＰＩ３３が、音声コマンドを組み込んだ走行中用画面構成の画面データを生成するので、走行中画面において音声認識による操作が可能となる。
　なお、上記実施の形態５では、上記実施の形態１～３の構成に音声操作部７を追加した場合を示したが、上記実施の形態４の構成に音声操作部７を追加してもよい。
　この場合、走行中用ＵＩ生成部３５が、通常用画面の画面データから走行中用画面の画面データを生成する際に、音声コマンドを走行中用画面の画面データに組み込む。
　このようにすることでも、上記と同様の効果を得ることができる。
　また、上記実施の形態１～５では、ＨＴＭＬ形式またはＸＭＬ形式で画面構成を指定するＡＰＩを示したが、他の言語または方法で画面構成を指定しもよい。例えば、Ｊａｖａ（登録商標）言語のクラスやメソッドを用いたＡＰＩであってもよい。
　さらに、上記実施の形態１～５では、車両が走行中の場合、走行中用画面を表示部５に表示する場合を示したが、車両が助手席用やリア席用などの複数の表示部のうち、運転者によって主に視認される表示部以外の表示部については、車両が走行中でも走行中用画面に切り替えず、通常用画面を表示するようにしてもよい。
　例えば、制御部３１が、複数の表示部のそれぞれを識別する識別情報に基づいて、運転者によって主に視認される表示部５を特定し、当該表示部５については、車両が走行中であるか否かに応じて通常用画面と走行中用画面を切り替え、当該表示部５以外の表示部については、車両が走行中であっても走行中用画面に切り替えず、通常用画面を表示する。
　上記実施の形態１～５では、本発明に係る移動体用情報機器を車載情報機器に適用した場合について示したが、車両以外に、鉄道、船舶または航空機に搭載される移動体用情報機器であってもよく、人が携帯して車両内に持ち込んで使用される携帯情報端末、例えばＰＮＤ（Portable Navigation Device）であってもよい。
　なお、本発明はその発明の範囲内において、各実施の形態の自由な組み合わせ、あるいは各実施の形態の任意の構成要素の変形、もしくは各実施の形態において任意の構成要素の省略が可能である。
　この発明に係る移動体用情報機器は、移動体が停止中である場合と移動中である場合のそれぞれに適した画面を表示できるので、車両の走行中に操作内容が制限されるカーナビゲーション装置などの車載情報機器に好適である。
　１，１Ａ，１Ｂ　車載情報機器、２　アプリケーション、３，３Ａ，３Ｂ　アプリケーション実行環境、４　走行中判断部、５　表示部、６　操作部、７　音声操作部、３１，３１Ａ　制御部、３２　通常用ＵＩ　ＡＰＩ、３３　走行中用ＵＩ　ＡＰＩ、３４　イベント通知部、３５　走行中用ＵＩ生成部。

Claims (13)

  1. 　画面表示を行う表示部と、アプリケーションが実行されるアプリケーション実行環境とを備える移動体用情報機器において、
    　前記アプリケーションから指定された画面構成の画面データを生成する第１のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）と、
    　移動体の移動中に表示する移動中用の画面構成のレイアウトが規定されたテンプレートデータに基づいて、前記アプリケーションから指定された前記移動中用の画面構成の画面データを生成する第２のＡＰＩと、
    　前記アプリケーション実行環境に設けられ、前記移動体が停止しているとき、前記第１のＡＰＩにより生成された前記画面データを前記表示部に表示させ、前記移動体が移動しているときは、前記第２のＡＰＩにより生成された前記画面データを前記表示部に表示させる制御部とを備えることを特徴とする移動体用情報機器。
  2. 　前記アプリケーション実行環境は、前記移動体の移動中に表示する画面構成の複数のレイアウトがそれぞれ規定された複数のテンプレートデータを有し、
    　前記第２のＡＰＩは、前記複数のテンプレートデータの中から前記アプリケーションの指定内容に応じて選択したテンプレートデータに基づいて前記移動体の移動中に表示する画面構成の画面データを生成することを特徴とする請求項１記載の移動体用情報機器。
  3. 　前記第２のＡＰＩは、前記アプリケーションの指示に応じて、前記テンプレートデータにより規定される画面構成のレイアウトを構成する表示要素を変更して、前記移動中用の画面構成の画面データを生成することを特徴とする請求項１記載の移動体用情報機器。
  4. 　前記第２のＡＰＩは、前記アプリケーションの指示に応じて、前記テンプレートデータに基づいて生成した前記移動中用の画面を構成する表示要素の態様を、所定の制限範囲内で変更することを特徴とする請求項１記載の移動体用情報機器。
  5. 　前記第１のＡＰＩは、前記移動体が停止しているときに、前記画面データを生成し、
    　前記第２のＡＰＩは、前記移動体が移動しているときに、前記移動中用の画面構成の画面データを生成することを特徴とする請求項１記載の移動体用情報機器。
  6. 　前記画面データを描画処理して得られた描画データを保存するオフスクリーンバッファを備え、
    　前記制御部は、前記第１のＡＰＩにより生成された画面データの描画データと、前記第２のＡＰＩにより生成された画面データの描画データとを表示レイヤ違いで前記オフスクリーンバッファに保存し、前記移動体が移動しているか否かに応じて、前記オフスクリーンバッファに保存された前記各描画データを切り替えて前記表示部に表示させることを特徴とする請求項１記載の移動体用情報機器。
  7. 　ユーザが発した音声を認識して、認識結果が前記制御部から登録された音声コマンドに一致または類似する場合、当該認識結果を音声イベントとして前記制御部に通知する音声操作部を備え、
    　前記第２のＡＰＩは、前記音声コマンドを組み込んだ移動中用の画面構成の画面データを生成することを特徴とする請求項１記載の移動体用情報機器。
  8. 　画面表示を行う表示部と、アプリケーションが実行されるアプリケーション実行環境とを備える移動体用情報機器において、
    　前記アプリケーションから指定された画面構成の画面データを生成する第１のＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ　Ｐｒｏｇｒａｍ　Ｉｎｔｅｒｆａｃｅ）と、
    　前記第１のＡＰＩにより生成された画面データに基づいて、前記アプリケーションから指定された、前記移動体の移動中に表示する移動中用の画面構成の画面データを生成する移動中用ＵＩ生成部と、
    　前記アプリケーション実行環境に設けられ、前記移動体が停止しているとき、前記第１のＡＰＩにより生成された画面データを前記表示部に表示させ、前記移動体が移動しているときは、前記移動中用ＵＩ生成部により生成された画面データを前記表示部に表示させる制御部とを備えることを特徴とする移動体用情報機器。
  9. 　前記移動中用ＵＩ生成部は、前記第１のＡＰＩにより生成された画面データの画面に動画が含まれている場合、当該動画を静止画に変換した画面構成の画面データを生成することを特徴とする請求項８記載の移動体用情報機器。
  10. 　前記第１のＡＰＩは、前記移動中用の画面構成の画面データを構成する情報を付帯情報として含む画面データを生成し、
    　前記移動中用ＵＩ生成部は、前記第１のＡＰＩにより生成された画面データにおける前記付帯情報に基づいて、前記移動中用の画面構成の画面データを生成することを特徴とする請求項８記載の移動体用情報機器。
  11. 　前記画面データを描画処理して得られた描画データを保存するオフスクリーンバッファを備え、
    　前記制御部は、前記第１のＡＰＩにより生成された画面データの描画データと、前記移動中用ＵＩ生成部により生成された画面データの描画データとを表示レイヤ違いで前記オフスクリーンバッファに保存し、前記移動体が移動しているか否かに応じて、前記オフスクリーンバッファに保存された前記各描画データを切り替えて前記表示部に表示させることを特徴とする請求項８記載の移動体用情報機器。
  12. 　ユーザが発した音声を認識して、認識結果が前記制御部から登録された音声コマンドに一致または類似する場合、当該認識結果を音声イベントとして前記制御部に通知する音声操作部を備え、
    　前記移動中用ＵＩ生成部は、前記音声コマンドを組み込んだ移動中用の画面構成の画面データを生成することを特徴とする請求項８記載の移動体用情報機器。
  13. 　複数の表示部を備え、
    　前記制御部は、
    　前記移動体が停止しているとき、前記第１のＡＰＩにより生成された前記画面データを前記複数の表示部のうちの所定の表示部に表示させ、前記移動体が移動しているときは、前記移動中用の画面構成の画面データを前記所定の表示部に表示させ、
    　前記複数の表示部のうちの前記所定の表示部以外の表示部には、前記移動体が移動しているか否かによらず、前記第１のＡＰＩによって生成された前記画面データを表示させることを特徴とする請求項１または請求項８記載の移動体用情報機器。
PCT/JP2012/000459 2012-01-25 2012-01-25 移動体用情報機器 WO2013111185A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
DE112012005745.7T DE112012005745T5 (de) 2012-01-25 2012-01-25 Mobile Informationsvorrichtung
US14/350,325 US20140259030A1 (en) 2012-01-25 2012-01-25 Mobile information device
PCT/JP2012/000459 WO2013111185A1 (ja) 2012-01-25 2012-01-25 移動体用情報機器
CN201280068034.3A CN104066623A (zh) 2012-01-25 2012-01-25 移动体用信息设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/000459 WO2013111185A1 (ja) 2012-01-25 2012-01-25 移動体用情報機器

Publications (1)

Publication Number Publication Date
WO2013111185A1 true WO2013111185A1 (ja) 2013-08-01

Family

ID=48872967

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/000459 WO2013111185A1 (ja) 2012-01-25 2012-01-25 移動体用情報機器

Country Status (4)

Country Link
US (1) US20140259030A1 (ja)
CN (1) CN104066623A (ja)
DE (1) DE112012005745T5 (ja)
WO (1) WO2013111185A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015145541A1 (ja) * 2014-03-24 2015-10-01 日立マクセル株式会社 映像表示装置
WO2018179943A1 (ja) * 2017-03-29 2018-10-04 富士フイルム株式会社 タッチ式操作装置、その作動方法及び作動プログラム、並びにタッチ式操作装置を用いた情報処理システム
JP2021079895A (ja) * 2019-11-22 2021-05-27 株式会社Ｍｏｂｉｌｉｔｙ Ｔｅｃｈｎｏｌｏｇｉｅｓ コミュニケーションシステム、コミュニケーション方法及び情報端末

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150193090A1 (en) * 2014-01-06 2015-07-09 Ford Global Technologies, Llc Method and system for application category user interface templates
US10248472B2 (en) * 2015-11-02 2019-04-02 At&T Intellectual Property I, L.P. Recursive modularization of service provider components to reduce service delivery time and cost

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005037375A (ja) * 2003-06-30 2005-02-10 Matsushita Electric Ind Co Ltd ナビゲーション装置およびナビゲーション表示方法
JP2006350469A (ja) * 2005-06-13 2006-12-28 Xanavi Informatics Corp ナビゲーション装置
JP2007096392A (ja) * 2005-09-27 2007-04-12 Alpine Electronics Inc 車載ビデオ再生装置
WO2007069573A1 (ja) * 2005-12-16 2007-06-21 Matsushita Electric Industrial Co., Ltd. 移動体用入力装置、及び方法
JP2008065519A (ja) * 2006-09-06 2008-03-21 Xanavi Informatics Corp 車載装置
JP2011219058A (ja) * 2010-04-14 2011-11-04 Denso Corp 車両用表示装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7970749B2 (en) * 2004-03-11 2011-06-28 Navteq North America, Llc Method and system for using geographic data in computer game development
US7640101B2 (en) * 2004-06-24 2009-12-29 Control Technologies, Inc. Method and apparatus for motion-based disabling of electronic devices
US9298783B2 (en) * 2007-07-25 2016-03-29 Yahoo! Inc. Display of attachment based information within a messaging system
US20120268294A1 (en) * 2011-04-20 2012-10-25 S1Nn Gmbh & Co. Kg Human machine interface unit for a communication device in a vehicle and i/o method using said human machine interface unit
US9041556B2 (en) * 2011-10-20 2015-05-26 Apple Inc. Method for locating a vehicle

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005037375A (ja) * 2003-06-30 2005-02-10 Matsushita Electric Ind Co Ltd ナビゲーション装置およびナビゲーション表示方法
JP2006350469A (ja) * 2005-06-13 2006-12-28 Xanavi Informatics Corp ナビゲーション装置
JP2007096392A (ja) * 2005-09-27 2007-04-12 Alpine Electronics Inc 車載ビデオ再生装置
WO2007069573A1 (ja) * 2005-12-16 2007-06-21 Matsushita Electric Industrial Co., Ltd. 移動体用入力装置、及び方法
JP2008065519A (ja) * 2006-09-06 2008-03-21 Xanavi Informatics Corp 車載装置
JP2011219058A (ja) * 2010-04-14 2011-11-04 Denso Corp 車両用表示装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015145541A1 (ja) * 2014-03-24 2015-10-01 日立マクセル株式会社 映像表示装置
WO2018179943A1 (ja) * 2017-03-29 2018-10-04 富士フイルム株式会社 タッチ式操作装置、その作動方法及び作動プログラム、並びにタッチ式操作装置を用いた情報処理システム
JP2018169757A (ja) * 2017-03-29 2018-11-01 富士フイルム株式会社 タッチ式操作装置、その作動方法及び作動プログラム、並びにタッチ式操作装置を用いた情報処理システム
JP2021079895A (ja) * 2019-11-22 2021-05-27 株式会社Ｍｏｂｉｌｉｔｙ Ｔｅｃｈｎｏｌｏｇｉｅｓ コミュニケーションシステム、コミュニケーション方法及び情報端末
JP7436184B2 (ja) 2019-11-22 2024-02-21 Ｇｏ株式会社 コミュニケーションシステム、コミュニケーション方法及び情報端末

Also Published As

Publication number Publication date
DE112012005745T5 (de) 2014-10-16
CN104066623A (zh) 2014-09-24
US20140259030A1 (en) 2014-09-11

Similar Documents

Publication Publication Date Title
Paterno' et al. MARIA: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environments
US10452333B2 (en) User terminal device providing user interaction and method therefor
US20120268294A1 (en) Human machine interface unit for a communication device in a vehicle and i/o method using said human machine interface unit
JP6076897B2 (ja) 車載情報システム、車載装置、情報端末用プログラム
JP5999573B2 (ja) 情報表示処理装置
WO2013111185A1 (ja) 移動体用情報機器
CN109690481A (zh) 动态功能行定制
EP2587371A1 (en) Improved configuration of a user interface for a mobile communications terminal
JP2008165735A (ja) 携帯端末機及びその画面表示方法
CN106415469A (zh) 用于使显示单元上的视图适配的方法和用户界面
US9383815B2 (en) Mobile terminal and method of controlling the mobile terminal
CN101490644B (zh) 事件处理装置
KR100855698B1 (ko) 사용자 인터페이스 변경 시스템 및 방법
CN113553017A (zh) 一种终端屏幕的适配方法、系统、设备及介质
JP2010176429A (ja) 電子コンテンツ配信システム
JPWO2013111185A1 (ja) 移動体用情報機器
JP2015196487A (ja) 規制情報配信装置、規制情報配信システム
Hofmann et al. Development of speech-based in-car HMI concepts for information exchange internet apps
JP4765893B2 (ja) タッチパネル搭載装置、外部装置、及び外部装置の操作方法
JP2007058607A (ja) 表示装置、表示方法、および、表示プログラム
JP2018097659A (ja) 出力処理装置および出力処理方法
Masuhr et al. Designing context-aware in-car information systems
CN119782495A (zh) 页面标注方法、装置、车辆、存储介质及产品
CN115080007A (zh) 语音开发方法、系统、电子设备和介质
CN116540913A (zh) 一种基于安卓系统的窗口跨屏装置、方法及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12866928

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013554990

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14350325

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 1120120057457

Country of ref document: DE

Ref document number: 112012005745

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12866928

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载