WO2007010756A1 - コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを表示可能な端末装置 - Google Patents

コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを表示可能な端末装置 Download PDF

Info

Publication number
WO2007010756A1
WO2007010756A1 PCT/JP2006/313553 JP2006313553W WO2007010756A1 WO 2007010756 A1 WO2007010756 A1 WO 2007010756A1 JP 2006313553 W JP2006313553 W JP 2006313553W WO 2007010756 A1 WO2007010756 A1 WO 2007010756A1
Authority
WO
WIPO (PCT)
Prior art keywords
content
image
character information
display area
terminal device
Prior art date
Application number
PCT/JP2006/313553
Other languages
English (en)
French (fr)
Inventor
Kazuhide Tanaka
Noriyuki Hosaka
Original Assignee
Access Co., Ltd.
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 Access Co., Ltd. filed Critical Access Co., Ltd.
Publication of WO2007010756A1 publication Critical patent/WO2007010756A1/ja

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/12—Use of codes for handling textual entities
    • G06F40/14—Tree-structured documents
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/431—Generation of visual interfaces for content selection or interaction; Content or additional data rendering
    • H04N21/4312—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations
    • H04N21/4314—Generation of visual interfaces for content selection or interaction; Content or additional data rendering involving specific graphical features, e.g. screen layout, special fonts or colors, blinking icons, highlights or animations for fitting data in a restricted space on the screen, e.g. EPG data in a rectangular grid
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/8543—Content authoring using a description language, e.g. Multimedia and Hypermedia information coding Expert Group [MHEG], eXtensible Markup Language [XML]

Definitions

  • the present invention relates to a method and program for rendering content described in a markup language, and a terminal device capable of displaying such content. More specifically, the present invention relates to a rendering method, a program, and a terminal device related to content layout.
  • SMIL Synchronization Multimedia Integration Language
  • W3C World Wide Web Consortium
  • MMS Multimedia Messaging Service
  • MMS Multimedia Messaging Service
  • 3GPP 3rd Generation Partnership Project
  • OM A Open Mobile Alliance
  • S MIL content content described in SMIL
  • S MIL content includes elements such as characters and images.
  • SMIL content should be created, for example, in accordance with OMA-MMS Conformance Document (hereinafter referred to as “OMA—SMIL content”), and in compliance with specifications established by 3GPP and W3C There is something to be done (hereinafter referred to as “3GPP—SMIL content”). Both OMA—SMIL content and 3GPP—SMIL content can be sent and received using MMS.
  • OMA—SMIL content OMA-MMS Conformance Document
  • 3GPP—SMIL content 3GPP—SMIL content
  • OMA-SMIL content when displayed on the screen, an Image area, which is an area for displaying images, and a Text area, which is an area for displaying character information, etc. are laid out.
  • Japanese Patent Application Laid-Open No. 2004-56469 discloses a method for OMA-S MIL content, in which a layout process is performed in accordance with a display screen of a terminal.
  • Japanese Patent Application Laid-Open No. 2004-56469 discloses a synchronized multimedia presentation described in SMIL when the display screen size of a portable terminal device is severe and limited. A method of playing is described. That is, according to Japanese Unexamined Patent Application Publication No. 2004-56469, the layout is optimized according to various conditions such as the size and resolution of the display screen provided in the terminal device, and the multimedia presentation is reproduced.
  • 3GPP—SMIL content is often richer than OMA—SMIL content.
  • 3GPP-SMIL content it is important that the layout intended by the content creator (for example, content pronoida) is reflected and displayed as it is. Therefore, the application for rendering SMIL (rendering engine) force
  • the screen size will be optimized according to various conditions such as resolution. That is not desirable.
  • the rendering engine faithfully lays out the 3GPP-SMIL content even if, for example, not all images are displayed on the display screen, and the content is only displayed for the first time by means such as scrolling the content screen by the user. Rendering must be done so that the whole can be browsed.
  • OMA-SMIL content is used as mail with an image on a mobile phone or the like, it is desirable that the text part be laid out to fit on one screen.
  • the OMA-SMIL content allows the display to be displayed with the layout changed as appropriate. For example, it is possible to change the layout so that the image and text fit on one screen.
  • the rendering engine compares the entire image and text when they cannot fit within the display screen. If so, the rendering process is performed to reduce the display. As a result, the user can browse the entire content without an operation such as scrolling.
  • the Text area and the Image area may overlap depending on the relationship between the contents of the tag that specifies the layout and the screen size of the receiving terminal.
  • the user may not be able to read the text partially depending on how the areas overlap each other.
  • the Text area and the Image area overlap. Due to the nature of OMA—SMIL content being messaging, the situation where text cannot be read should be avoided as much as possible.
  • the Text area and the Image area may be separated depending on the relationship between the contents of the tag specifying the layout and the screen size of the receiving terminal. In this case, it is assumed that there will be an extra space between the image and characters on the display screen. If such extra space is created, the content may look bad, which can go against the intention of the author.
  • an image is displayed in the Image area.
  • the aspect ratio of the vertical width and horizontal width (aspect ratio) of the image is equal to the aspect ratio of the mage area
  • the image is displayed in the Image area as the same size as the Image area by performing enlargement / reduction on the image.
  • the horizontal width (or vertical width) of the image is expanded and reduced to fit the horizontal width of the image area (or! / ⁇ is the vertical width). Is done.
  • the image is displayed with a blank area in the Image area, or the image area is filled with the image but the image area is displayed. The image protrudes.
  • the present invention is a content rendering method capable of appropriately executing layout processing according to received content, a terminal device capable of displaying content, and rendering content.
  • the challenge is to provide a program to do this.
  • a rendering method that solves the above problem is a method of rendering content that is described in a predetermined markup language and that has a specified layout.
  • the rendering method includes a content interpretation step for interpreting the content, a position determination step for determining the position of each element of the content on the display screen on which the content is displayed based on the interpretation result of the interpretation step, An array determination step for determining whether or not each element is arranged in a close state at the determined position, and when it is determined in the array determination step that each element is not arranged in a close state, Layout adjustment step of adjusting the layout of each element so as to be visible.
  • a terminal device capable of displaying content described in a predetermined mark-up plan gauge and designated in a layout on a display screen.
  • the terminal device includes content interpreting means for interpreting the content, position determining means for determining the position of each element of the content on the display screen based on the interpretation result by the interpreting means, and the determined position.
  • the arrangement determining means for determining whether or not each element is arranged in a close state, and when it is determined that the elements are not arranged in a close state by the arrangement determining means, And a layout adjusting means for adjusting the layout of each element so as to be visible.
  • the rendering method or the terminal device of the present invention on the display screen
  • the power force / non-power (for example, the overlap between the image and the text region or the presence / absence of a gap) of each element is determined, and the layout of each element is adjusted according to the determination result.
  • the rendering method that solves the above-described problem allows the received markup language content to be interpreted and the layout to be changed depending on whether or not a predetermined condition is satisfied. It is characterized in that it is determined whether the content should be displayed without changing the power and layout, and the layout processing is performed according to the determination result.
  • a terminal device that solves the above problem interprets received markup language content, and determines a layout depending on whether the markup language content satisfies a predetermined condition. It is characterized in that it is provided with a rendering means that determines whether the content is allowed to be changed or should be displayed without changing the layout, and performs layout processing according to the determination result. is there.
  • a program according to an aspect of the present invention for solving the above-described problem is a program for causing a computer to execute the rendering method.
  • FIG. 1 is an external view of a mobile phone according to an embodiment of the present invention.
  • FIG. 2 is a functional block diagram showing a hardware configuration of the mobile phone according to the embodiment of the present invention.
  • FIG. 3 is a diagram showing the structure of MMS.
  • FIG. 5 is a diagram schematically showing an example of SMIL content.
  • FIG. 6 is a diagram for explaining the function of the messaging client.
  • FIG. 7 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 8 is a schematic diagram showing a screen displayed by the process of FIG.
  • FIG. 9 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 10 is a schematic diagram showing a screen displayed by the process of FIG. 9.
  • FIG. 11 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 12 is a schematic diagram showing a screen displayed by the process of FIG. 11.
  • FIG. 13 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 14 is a schematic diagram showing a screen displayed by the process of FIG.
  • FIG. 15 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 16 is a diagram showing a relationship between an image area and a text area calculated by the process of FIG. 15 and the size of the image.
  • FIG. 17 is a diagram showing a case where the image of FIG. 16 is enlarged / reduced by the processing of FIG.
  • FIG. 18 is a diagram showing the relationship between the image area and text area calculated by the process of FIG. 15, and the size of the image.
  • FIG. 19 is a diagram showing a case where the image of FIG. 18 is enlarged / reduced by the processing of FIG.
  • FIG. 20 is a diagram showing a screen displayed by the process of FIG.
  • FIG. 21 is a diagram showing a screen displayed by the process of FIG.
  • FIG. 22 is a flowchart showing the processing operation of the messaging client.
  • FIG. 23 is a flowchart showing processing by the SMIL rendering engine.
  • FIG. 24 is a diagram for explaining a function of a messaging client according to another embodiment.
  • FIG. 25 is a flowchart showing the processing operation of the messaging client.
  • FIG. 26 is a flowchart showing processing by the SMIL rendering engine.
  • SMIL Synchronization Multimedia Integration Language
  • the markup language for implementing the present invention is SMIL. It is not limited to.
  • FIG. 1 shows an external view of a mobile phone 10 capable of realizing the rendering method according to the present invention.
  • FIG. 2 is a functional block diagram showing the hardware configuration of the mobile phone 10.
  • a liquid crystal display 111 and an operation unit are provided on the operation surface side of the casing of the mobile phone 10.
  • the operation unit includes a dial button 114, a direction instruction key 115, an on-hook button 121, and an off-hook button 122.
  • a hole for a spin force 119 and an antenna 105 are provided in the upper part on the operation surface side, and a hole for a microphone 118 is provided in the lower part.
  • a mobile phone is taken as an example of a terminal device that renders and displays SMIL content, but the present invention can also be implemented in a terminal device other than a mobile phone.
  • the mobile phone 10 has a CPU 100 that controls the entire apparatus.
  • ROM 101, RAM 102, flash memory 103, wireless communication control unit 104, liquid crystal display 111, input interface unit 113, and audio control unit 117 are each connected to CPU 100.
  • the wireless communication control unit 104 is connected to an antenna 105, the input interface unit 113 is connected to various key forces of the operation unit, and the voice control unit 117 is connected to a microphone 118 and a speaker 119.
  • the ROM 101 is a nonvolatile read-only memory that stores various programs executed by the CPU 100 and fixed data.
  • the RAM 102 is a writable memory that provides a work area for the CPU 100 and a temporary data storage area.
  • the flash memory 103 is a rewritable nonvolatile memory that stores additional application programs and various data.
  • the wireless communication control unit 104 has a function of performing wireless communication (transmission / reception) of voice and data with the base station via the antenna 105.
  • the liquid crystal display 111 constitutes a display unit having a display screen.
  • the input interface unit 113 has a function of accepting input operations such as a dial button 114 and a direction instruction key 115.
  • a microphone 118 and a speaker 119 are connected to the audio control unit 117.
  • the voice control unit 117 controls voice input / output via the microphone 118 and the speaker 119.
  • the ROM 101 stores a browser, a mailer, a messaging client, and other various applications used for the mobile phone 10. As the browser is activated, the mobile phone 10 is connected to the communication network via the wireless communication control unit 104 and can browse various contents.
  • the mailer has a function to send and receive e-mails.
  • message Client has a function to send and receive a message (MMS message) with SMIL content attached by MMS (Multimedia Messaging Service).
  • MMS Multimedia Messaging Service
  • the messaging client has a rendering engine for SMIL.
  • the SMIL rendering engine has functions for rendering and playing SMIL content. Note that the SMIL rendering engine may be an application independent of the messaging client, rather than the configuration included in the messaging client.
  • MMS is a service that can be used to send and receive text, voice, and images as messages on mobile phones.
  • Figure 3 is a schematic diagram showing the structure of an MMS message.
  • the MMS message 200 is composed of an MMS header part 210 and a message body part 220.
  • Various information is attached to the MMS header section 210.
  • the information attached to the MMS header section 210 includes, for example, the sender's e-mail address, telephone number, message title, sender's recipient's 3GPP, and an identifier specified by the OMA.
  • the MMS header section 210 further has an extension header, and the sender can arbitrarily add information. Further, the extension header may be included in the header part of the communication protocol for transmitting and receiving MMS messages in addition to the MMS header part 210.
  • Message body 220 has SMIL content.
  • FIG. 4 is an example of a SMIL (OMA—SMIL content) document.
  • a SMIL document has a header part 230 surrounded by a head tag and a body part 240 surrounded by a body tag in a smil tag.
  • the header part 230 has a meta tag, a layout tag, and the like.
  • the meta tag usually contains bibliographic items such as the title ("title”), the author's name ("author”), and copyright information ("copyright”).
  • the mail sender can be specified by the information in the meta tag.
  • Within the layout tag there is a region tag to specify the layout of each region (image, text, etc.).
  • the body part 240 has a par tag.
  • the par tag is a tag for simultaneously reproducing each content such as an image, text, and audio.
  • FIG. 5 is a diagram schematically showing the reproduction display of the SMIL content shown in FIG.
  • the slide 300 is first played (5 seconds), and then the slide 310 is played (10 seconds).
  • an image is displayed in the image area 301, the text “Morning!” Is displayed in the text area 302, and sound is also reproduced at the same time.
  • the force at which the slide 310 is subsequently played back The image area 311 and text area 312 of the slide 310 are equal to the layout of the image area 301 and text area 302 of the slide 300 (that is, the layout is fixed between the slides).
  • the display time can also be set for the image area and text area in each slide.
  • the region tag causes the image region 30 1 (311) to have a width 160, a height 160, a start position (from the top) 0%, and a text region 302 (312). Is defined as width 160, height 40, and starting position (from top) 80%. That is, the layout assumes that the screen size is 160 width x height 200 or more. Note that the specification of these values using the region tag is exemplary, for example, the start position can be specified by a numerical value instead of a percentage specification (for example, the start position of the text area 302 is 160 from the top). .
  • the SMIL content described above is OMA—SMIL content, and is a content that has a limited display / playback method compared to 3GPP—SMIL content.
  • OMA-SMIL content can specify only one text, one image, and one sound in par tag (one video and one text when using video).
  • OMA-SMIL content only two region tags appear: one that sets the image area and one that sets the text area.
  • OMA—SMIL content is created mainly by general users of mobile phones.
  • 3GPP—SMIL content is a combination of, for example, still images, sounds, keyed 3D, and moving images.
  • 3GPP—SMIL content each content is synchronized on the time axis, enabling a TV-like effect. Therefore, more tags are usually used than OMA-SMIL content.
  • hyperlinks can be added to 3GPP-SMIL content. It is also possible to use DRM (Digital Rights Management) protection for copyright management.
  • 3GPP—SMIL content is created by content providers for the purpose of paying for that content. There are many cases.
  • 3GPP—SMIL content the content creator's intention is reflected on the screen of the terminal. In this embodiment, the layout is not changed according to the size of the screen by rendering.
  • DRM is a technique for protecting the copyright of digital data.
  • DRM formats such as Forward Lock (FL), Seno ⁇ Separate Delivery (SD), and Combined Delivery (CD).
  • the forward lock is a format in which transfer prohibition processing is performed on the content.
  • Combined delivery is a format in which rights (Rights) and content for playback are delivered as a set, and content is subject to restrictions such as transfer prohibition processing and the number of playback times and duration.
  • Separate delivery is a format in which Rights and encrypted content are distributed separately, and content can be played back by the user purchasing Rights.
  • FIG. 6 is a diagram for explaining the function of the messaging client.
  • the messaging client 400 is an application having a function of transmitting and receiving the MMS message 200 and has a SMIL rendering engine 410.
  • the messaging client 400 has a message reception function (F01).
  • the SMIL rendering engine 410 has a function for interpreting SMIL (ie, Versa) (F02), a function for calculating the size of each area displayed on the display screen (F03), and the results. And a function (F04) for performing layout.
  • layout processing is executed based on the layout tag, the actual display screen width, and the like.
  • the rendering process is executed with the layout specified by the layout tag without considering the display screen.
  • the layout is changed according to the display screen and the rendering process is executed.
  • OMA-SMIL content if the Image area and Text area do not overlap, the rendering process is executed with the layout specified by the layout tag. Also, when the Image area and the Text area overlap, a predetermined process is executed.
  • the messaging client 400 does not necessarily include the SMIL rendering engine 410. It may not have. That is, it may be a module different from the SMIL rendering engine 410 power S messaging client 400. In that case, the SMIL rendering engine 410 may be activated by the messaging client 400 force instruction.
  • the first to fifth embodiments relate to layout processing for OMA-SMIL content that performs layout processing for improving the visibility of text included in the content for the user. For this reason, all the SMIL contents in the description of the first to fifth embodiments mean OMA-SMIL contents.
  • FIG. 7 is a flowchart illustrating processing executed by the SMIL rendering engine 410.
  • step S101 the received SMIL content is interpreted.
  • step S102 the image area and the text area are calculated in consideration of the size of the display screen.
  • step S103 based on the calculation result in step S102, it is determined whether the image area and the text area overlap. If there is an overlapping portion between the image area and the text area (step S103: YES), the process proceeds to step S104. If there is no overlapping part in the image area and the text area (step S103: NO), the process proceeds to step S106.
  • step S104 the layout area (F04) of the SMI L rendering engine 410 is shifted to a position where the image area and the text area do not overlap. For example, by ignoring the specification by the region tag and setting another value, it is possible to lay out so that the Image area and Text area do not overlap.
  • step S105 if there is an area that does not enter the display screen in the Text area, a process for enabling scroll display is performed.
  • step S106 display processing is performed. That is, the image is displayed on the liquid crystal display 111 of the mobile phone 10. After the display process is completed in step S106, this process ends.
  • FIG. 8 shows a schematic diagram of the layout after the processing of FIG. 7 (however, in the case of YES in step S103).
  • An image area 511, a text area 512, a text area 513 that does not fit in the display screen, and a scroll bar 514 are provided.
  • the user can view all the character information to be displayed in the Text area by operating the scroll bar.
  • Book In the embodiment of the invention, the Text area is moved in the direction perpendicular to the display screen. However, the moving direction depends on the shape and size of the display screen and is not limited to the vertical direction.
  • FIG. 9 is a flowchart illustrating processing executed by the SMIL rendering engine 410.
  • the processing shown in steps S201 force and S203 is the same as the processing shown in steps S101 and S103 in FIG. However, if “NO” in step S203 (that is, if there is no overlapping portion between the image area and the text area), the process proceeds to step S205.
  • step S204 the Text area is placed on the Image area, and the background of the Text area is made transparent. In other words, in the overlapping area of the Text area and the Image area, text etc. is displayed on the Image, so that part of the text etc. is not hidden.
  • step S205 display processing is performed. That is, it is displayed on the liquid crystal display 111 of the mobile phone 10. After the display process is completed in step S205, this process ends.
  • FIG. 10 shows a schematic diagram of the layout after the processing of FIG. 9 (in the case of YES in step S203). It has an image area 521, a text area 522, and an overlapping area 523. In the overlapping area 523, the text is displayed on the image, so that the user can see all the character information to be displayed in the text area.
  • the Text area and the Image area overlap in the vertical direction.
  • the overlapping method depends on the shape and size of the display screen and is not limited to the vertical direction.
  • FIG. 11 is a flowchart showing processing executed by the SMIL rendering engine 410.
  • the processing shown in steps S301 force and S304 is the same as the processing shown in steps S201 force and S204 in FIG. However, if “NO” in step S303 (that is, if there is no overlap between the image area and the text area), the process proceeds to step S306.
  • step S305 the text color is extracted from the table 535.
  • the table 535 can be provided in the mobile phone 10.
  • Table 535 is the back of the Image area It keeps text color information as a table for the user to see the colors of the scene!
  • display processing is performed. That is, it is displayed on the liquid crystal display 111 of the mobile phone 10. After the display process is completed in step S306, this process ends.
  • FIG. 12 shows a schematic diagram of the layout after the processing of FIG. 11 (however, in the case of YES in step S303). It has an image area 531, a text area 532, and an overlap area 533.
  • the text is displayed on the Image and in a color that is easy to see with respect to the background color of the Image area, so that the user can see all the character information that should be displayed in the Text area.
  • the possibility increases.
  • the Text area and the Image area overlap in the vertical direction.
  • the overlapping method depends on the shape and size of the display screen, and is not limited to the vertical direction.
  • FIG. 13 is a flowchart showing the processing executed by the SMIL rendering engine 410.
  • the processing shown in steps S401 force and S404 is the same as the processing shown in steps S101 force and S104 in FIG.
  • step S406 a process for displaying the contents to be displayed in the Text area using the area excluding the Image area on the display screen is performed. More specifically, the text to be displayed is automatically scrolled at a predetermined speed. As a result, the slide can be displayed and the entire contents of the text can be displayed during the period (telop display).
  • the speed of moving the text in this case is, for example, the size of the display area, the length of the text (calculated based on the font size, character spacing, etc.), and the slide display time specified by the par tag (or Image , Text display time).
  • step S406 display processing is performed. That is, it is displayed on the liquid crystal display 111 of the mobile phone 10. After the display process is completed in step S406, this process ends.
  • FIG. 14 shows a schematic diagram of the layout after the processing of FIG. 13 is completed (however, in the case of YES in step S403).
  • An image area 541 and a text area 542 (that is, an area excluding the image area 541 on the display screen) are included.
  • Text is telop in Text area 542 Is displayed. This telop display allows the user to see all the character information and the like to be displayed in the Text area specified by the SMIL content.
  • the Text area is moved in the vertical direction with respect to the display screen.
  • the moving direction depends on the shape and size of the display screen and is not limited to the vertical direction.
  • the telop display in this embodiment may be displayed in the force image area 541 in a part or all of the text displayed in the force telop in the area (Text area 542) excluding the image area 541 (however, the image area 541 (In 541, the background of the text is transparent).
  • OMA—SMIL content it is assumed that the Image area and the Text area are displayed on the same screen, and the layout (position and size) on the screen is specified, so MMS Depending on the display screen size of the terminal device that receives the message and displays the OMA—SMIL content, the image area and the text area may overlap. In that case, the text becomes partially unreadable.
  • the present invention provides a OMA-SMIL content rendering method that solves the problem and realizes an appropriate display for the user.
  • OMA-SMIL content is often created by general users of mobile phones.
  • the display screen sizes of portable terminal devices are still various. It is considered difficult for general users to create OMA-SMIL content in consideration of the display screen size of the destination terminal device. Since the present invention eliminates the possibility that the text becomes partially unreadable, the convenience of the OMA-SMIL content can be improved.
  • the description has been given using OMA-compliant OMA-SMIL content as an example of markup language content in which the Image region and the Text region can overlap.
  • mark-up plan gauge content compliant with another standard can be applied to the above embodiment.
  • the rendering method, terminal device, and program of the present invention can be applied to SMIL content acquired by a terminal without going through MMS.
  • the size of the image displayed in the Image area is equal to the size of the mage area (that is, the image is displayed in the entire Image area).
  • the Text area is necessarily hidden by the image by overlapping the Image area and the Text area.
  • an explanation will be given on the assumption that an image is displayed in at least a part or all of the image area.
  • the image data is transmitted together with the MMS message, and is laid out based on the Image area when OMA-SMIL content is rendered.
  • the ratio of the vertical width to the horizontal width is usually fixed for images. If the aspect ratio of the image is the same as the aspect ratio of the mage area, the image can be enlarged and reduced to be the same size as the image area. If the aspect ratio of the image is different from the aspect ratio of the mage area, for example, the image is enlarged or reduced so that the horizontal width of the image matches the horizontal width of the Image area. Also, when the image area is larger than the screen size, the image is reduced.
  • the processing executed by the SMIL rendering engine 410 when an image is laid out in the Image area is shown using the flowchart of FIG.
  • step S501 and step S502 are the same as the processing in step S101 and step S102 in Fig. 7, and thus the description thereof is omitted.
  • step S503 the image enlargement / reduction amount and layout are calculated. That is, in step S502, an enlargement / reduction amount is calculated in order to adapt the image to the image area calculated in consideration of the size of the display screen. Specifically, the width of the image is calculated to be equal to the width of the Image area. It is assumed that the aspect ratio of the image is fixed as described above. The concept of processing performed in step S503 will be described with reference to FIGS. 16 to 19. To do.
  • Fig. 16 shows the image area 551 (vertical 90 x horizontal 120) and text area 552 (vertical 40 x horizontal 120) calculated in step S502, and image 555 (vertical 30 x horizontal 30) in the image data.
  • the image area 551 and the text area 552 are adjacent to each other (that is, the coordinates on the display screen of the side that is the boundary thereof are the same).
  • the display screen size is 130 x 120 x 120.
  • the coordinates of the upper left vertex of the image 555 are arranged in accordance with the coordinates of the upper left vertex of the image area 551. In this case, the width of the image 555 is smaller than the width of the image area 551.
  • step S503 the enlargement ratio of the image 555 is calculated (vertically and horizontally 4 times).
  • Figure 17 shows a schematic diagram of the layout of image 555 after calculation.
  • the size of the image 555 is 120 ⁇ 120 in width, and as a result, a part of the image 555 overlaps the text region 552.
  • the image area 551 (vertical 90 X horizontal 120) and text area 552 (vertical 40 X horizontal 120) calculated in step S502 and the image 556 (vertical 100 X horizontal 240) in the image data are displayed. Is shown schematically. As in FIG. 16, the Image area 551 and the Text area 552 are adjacent to each other (that is, the coordinates of the boundary side on the display screen match). The display screen size is 130 x 120 x 120. In addition, the coordinates of the upper left vertex of the image 556 are arranged in accordance with the coordinates of the upper left vertex of the image area 551.
  • FIG. 19 shows a schematic diagram of image 556 after calculation outside the layer.
  • the size of the image 556 is 50 ⁇ 120 in height, and as a result, a gap is created between the image 556 and the text area 552.
  • step S504 it is determined whether or not the image and the text area 552 overlap. For example, in the example shown in FIG. 17, since it is calculated that the image 555 and the text area 552 force S overlap by 30 in the vertical direction (step S504: YES), the process proceeds to step S506. If the image and the text area 552 do not overlap (step S504: NO), the process proceeds to step S505. In step S505, it is determined whether or not a gap is generated between the image and the text area 552. For example, in the example shown in FIG. 19, it is calculated that there is a gap of 40 in the vertical direction between the image 556 and the text area 522 (step S505: YES). Proceed to S506. If it is determined that there is no gap between the image and the text area 552 (step S50 5: NO), the process proceeds to step S507.
  • step S502 as a result of the calculation in step S502, it is determined whether or not the image and the text region 552 are arranged in close contact. Also good.
  • step S506 image and text area adjustment processing is performed. For example, if the image 555 and the text area 552 overlap as shown in FIG. 17, the layout process is performed by shifting the text area 552 downward by 30 so as not to overlap as shown in FIG. Do. In this case, a part of the Text area 552 will protrude from the display screen. For example, as shown in the first embodiment, the text area that does not enter the display screen can be scrolled (see FIG. It is possible to lay out including the processing (Step S405 in FIG. 13) for displaying the contents of the text as a telop in the remaining part of the Image area as shown in the fourth embodiment (Step S105 in FIG. 7). . Note that, as shown in FIG. 20, without shifting the text area 552, the background of the text area is overlaid on the image in the transparent state as in the second or third embodiment. Processing (step S204 in FIG. 9 and steps S304 and S305 in FIG. 11) can also be performed.
  • step S506 for example, if there is a gap between the text image 556 and the text area 552 as shown in FIG. 19, the text area 552 is displayed in the gap as shown in FIG. The layout process is performed so that it is shifted upward by 40 so that there is no longer any problem.
  • step S507 the laid out image, text, etc. are displayed on the display screen.
  • step S504 and step S505 in FIG. 15 determines the relationship between the image and the text area 552, even if there is an overlap between the image area 551 and the text area 552 Can be implemented.
  • the first to fourth embodiments described above are included in the fifth embodiment shown in FIGS. 15 to 21 and are equal to the aspect ratio of the aspect specific force mage region 551 of the image. It can be said that this is an embodiment under the specific conditions.
  • step S503 in FIG. Large 'reduced layout' does not necessarily have to be done. That is, for example, when the lateral force is smaller than the lateral width of the mage area 551 as in the case of the image 555, a case where it is arranged in the image area 551 is assumed.
  • the position of the Text area on the display screen is specified by the tag, but it is ignored and the display position of the Text area is changed. be able to. That is, when no image is displayed, an unnecessary blank space is formed on the upper part of the display screen, for example, so the Text area is moved upward. Note that the display position of the Text area is not changed for content in which images are not temporarily displayed during slide playback (only text is displayed). This is because it is difficult for the user to view the content if the Text area is moved during playback due to the presence or absence of an image.
  • the sixth and seventh embodiments relate to determining the type of received SMIL content and performing layout processing on the received content according to the determination result.
  • OMA-SMIL content layout processing is executed according to various conditions such as the screen size of the terminal device.
  • FIG. 22 is a flowchart showing the processing operation of the messaging client 400 from when the MMS message 200 is received until the SMIL content is displayed.
  • the MMS message 200 is received (step S1101).
  • the messaging client 400 checks whether the content media (image, sound, video, etc.) is DRM protected. Discriminate (step SI 102). If DRM protection is attached (step SI 102: YES), the process proceeds to step SI 103. If DRM protection is not attached (step S 1102: NO), the process proceeds to step SI 104.
  • the messaging client 400 has a counter for 3GPP-SMIL content (hereinafter referred to as "3GPP counter”) and a counter for OMA-SMIL content (hereinafter referred to as "OMA counter”). ing.
  • 3GPP counter 3GPP-SMIL content
  • OMA counter OMA-SMIL content
  • step S1103 the received SMI L content is determined to be 3GPP-SMIL content, and the 3GPP counter is incremented by one.
  • step S1104 the MMS header section 210 is referred to and it is determined whether or not the SMIL content is created by a content pronoider.
  • a content pronoider For example, a content provider registered in advance in the mobile phone 10 or an external server with reference to the De-mail address described in the From field, 2) telephone number, 3) sender's receiver identifier, etc. Check against information (e-mail address, phone number, identifier, etc.). If there is content provider information in the MMS header section 210 (step S1104: YES), the process proceeds to step SI105, the received SMIL content is determined to be 3GPP—SMIL content, and the 3GPP counter is incremented by one. If it is determined that there is no information indicating the content provider in the MMS header section 210 (step S 1104: NO), the process proceeds to step SI 106.
  • step S1106 the extension header in MMS header section 210 is referred to, and it is determined to which specification the SMIL content is created.
  • MMS can extend the same header as the message data defined in RFC2822.
  • the sender can explicitly specify the rendering method for the receiver (mobile phone).
  • headers such as "X-Mms-SMIL-Rendering-Option:" are defined.
  • the messaging client 400 interprets and stores this header on receipt. The stored value is referenced to determine whether this SMIL content is OMA—SMIL content.
  • Step S1107 OMA—If not determined by SMIL content (step S1106: NO), go to step SI108.
  • the received SMIL content is determined to be OMA SMIL content, and the OMA counter is incremented by one.
  • step S1106 it was determined whether or not it can be processed as OMA—SMIL content.
  • the header that defines 3GPP—SMIL content in the extension header or the OM A—SMIL content that is not defined in 3GPP—SMIL content It may be determined whether or not it is 3GPP—SMIL content by determining whether the attributes defined by the content are included. If it is estimated that the content is 3GPP—SMIL content (step S1106: YES), in step S1107, the received SMIL content is determined to be 3GPP—SMIL content, and the 3GPP counter is incremented by one.
  • step S1108 the SMIL rendering engine 410 performs a rendering process on the SMIL content.
  • the SMIL content is output to the screen (step S1109).
  • This process determines whether or not to change the layout based on whether the received SMIL content is OMA-SMIL content 3GPP-SMIL content.
  • the layout can be changed arbitrarily according to user instructions.
  • FIG. 23 is a flowchart showing processing by the SMIL rendering engine 410.
  • step S1 201 processing by a versa is performed, and a document tree is generated.
  • the content of the meta tag ("title”, "author”, “copyright”, etc.) is referenced to determine whether the content has been created by the content provider (step S1202). If the name of a known content provider is included, it is determined that the content is created by the content pronoider (step S1202: YES), and the process proceeds to step S1203.
  • step S1203 the received SMIL content is determined to be 3GPP—SMIL content, and the 3GPP counter is incremented by one. If the name of a known content provider is included! /, In this case (step S1202: NO), the process proceeds to step S1204.
  • step S1202 the ability to determine whether the received SMIL content was created by a content provider is known. Determine if it was created by someone who could create SMIL content. If it is created by a known user or the like (step S1202: YES), in step S1203, the received SMIL content is determined to be OMA—SMIL content, and the OMA counter is incremented by one.
  • Known information indicating OM A-SMIL content or 3GPP-SMIL content contained in these meta tags is registered in advance in the mobile phone 10 or external server !. When collating information indicating 3GPP-SMIL content, the OMA—SMIL content or!
  • the meta tag can also contain information other than the information for identifying the content creator and sender. For example, any information that can be determined as 3GPP-SMIL content or OMA-SMIL content can be included. Further, for example, instruction information from the content creator regarding the layout (for example, information about whether the layout can be changed or prohibited) may be included.
  • step S 1204 tags other than the meta tag are determined.
  • 3GPP Determines whether the tag defined in OMA—SMIL content is not defined in SMIL content, or the appearance count of region tag. If the region tag appears only twice, it is likely that it is OMA—SMIL content. If the region tag appears twice or if it is defined only in OMA—SMIL content !, if there is a tag (step S 1204: YES), the process proceeds to step S 1205. If the region tag does not appear twice and is defined only in OMA—SMIL content !, and there is no tag (step S 1204: NO), the process proceeds to step S 1206. In step S1205, the received SMIL content is determined to be OMA—SMIL content, and the OMA counter is incremented by one.
  • step S1204 it is determined from the tag that the content is OMA—SMIL content, but the number of appearances of a tag or region tag that is not defined in OMA—SMIL content but defined only in 3GPP—SMIL content is 2. It may be determined whether or not it is 3GPP-SMIL content by not being times. If it is estimated that the content is 3GPP—SMIL content (step S 1204: YES), in step S 1205, the received SMIL content is determined to be 3GPP—SMIL content, and the 3GPP counter is incremented by one. In step S1206, layout processing is started. In this layout process, it is determined whether the layout can be changed based on the counter values of the 3GPP counter and the OMA counter (step S1207).
  • the SMIL rendering engine 410 operates so as to give priority to the OMA-SMIL content in the determination process in step S1207. Therefore, the counter values of both the 3GPP counter and the OMA counter are “0” (ie, step S1102, S1 104, S1106 (Fig. 22), step S1203, SI 205). ! / ⁇ ⁇ Maybe, if the counter value of the OMA counter is “1” or more (that is, OMA—SMIL content and half-IJ disconnection at any step), the received content is judged to be OMA—SMIL content. (1207: YES), go to step S1208.
  • step S 1207 NO
  • step S1207 may be set stepwise. For example, if the priority of OMA—SMIL content is set higher, even if the counter value of the OMA counter is “0”, the counter value of the 3GPP counter is not “2” or more! O! /, “YES” may be determined (ie, processed as OMA—SMIL content).
  • step S1208 for example, a layout process in accordance with the display screen (liquid crystal display 111) of the mobile phone 10 is performed. Further, the same layout process as in any of the first to fifth embodiments may be executed.
  • step S 1209 layout processing is performed as specified in layout (in this case, if the content does not fit on the screen, the entire content can be viewed by scrolling or the like). Thereafter, the layout process is completed in step S1210, and the present process by the SMIL rendering engine 410 ends.
  • the SMIL rendering engine 410 may be operated to give priority to the 3GPP-SMIL content.
  • the process proceeds to Step SI 209.
  • the counter value of the 3GPP counter is “0” and the counter value of the OMA counter is “1” or more, it is determined that the received content is OMA—SMIL content (step S1207: YES), and step S120 8 Proceed to
  • the determination as to whether it should be rendered as SMIL content is based on the following conditions (1) to (8). Judging by combination. Note that the determination method described in the flowcharts of FIGS. 22 and 23 is an example, and any one of the following ( 1) to ( 8) or a plurality of combinations are not limited. Also, it may be determined as 3GPP-SMIL content or OMA-SMIL content using any one or more of the following (1) to (8).
  • OMA whether it is defined in SMIL content or not, but a tag defined in 3GPP-SMIL content is used.
  • OMA whether or not defined in SMIL content is used, but attributes defined in 3GPP-SMIL content are used
  • the user can appropriately play back the layout as changed or unchanged without knowing which content it is.
  • FIG. 24 shows a message according to this embodiment.
  • FIG. 6 is a diagram for explaining functions of the ging client 500.
  • the messaging client 500 is an application having a function of transmitting and receiving MMS messages, and has a SMIL rendering engine 510.
  • the messaging client 500 has a message receiving function (F11), a function for analyzing SMIL contents (F12), and a function for distributing folders (F13).
  • the SMIL rendering engine 510 includes a SMIL parser (F14) and a SMIL layouter (F15), which are functions for rendering.
  • the messaging client 500 analyzes the received MMS message and SMIL content (F12). That is, as in the above-described embodiment, (l) presence / absence of DRM protection, (2) content of meta tag of SMIL, (3) information identifying the sender in the MMS header part, (4) information in the MMS header part The contents of the extension header, (5) The number of occurrences of the region tag, (6) OMA—is defined in the SMIL content !, NA! / Is defined in the 3GPP—SMIL content! (7) OMA—whether the attribute defined in 3GPP-SMIL content is used but not defined in SMIL content, (8) used in 3GPP-SM IL content! / !
  • OMA—SMIL content and 3GPP—SMIL content are temporarily stored in separate folders (F13).
  • the SMIL Rendering Engine 510 performs different rendering processes depending on the type of folder from which the SMIL content is extracted.
  • FIG. 25 is a flowchart showing the processing operation of messaging client 500 from when a message is received until SMIL content is displayed.
  • the processing from step S1301 to step S1307 is the same as the processing from step S1101 to step S1107 (Fig. 22) of the messaging client 400.
  • the processing from step S1308 to step S1311 is as follows. Since it is the same as the processing from step S1202 to step 1205 (FIG. 22), description thereof will be omitted.
  • step S1312 if the counter values of both the 3GPP counter and the OMA counter are "0" or the counter value of the OMA counter is "1" or more, the received content is OMA-SM IL content. To the folder for OMA-SMIL content. The process of temporarily storing the content is performed. On the other hand, when the counter value of the OMA counter is “0” and the counter value of the 3GPP counter is “1” or more, it is determined that the received content is 3GPP-S MIL content, and it is stored in the folder for 3GPP-SMIL content. A process for temporarily storing the received content is performed.
  • step S1313 the SMIL content temporarily stored in the folder for 3GPP-SMIL content or the OMA-SMIL content is taken out and rendered. Thereafter, the SMIL content is displayed on the display screen based on the rendering result (step S 1314), and the process is terminated.
  • the user can set which of OMA—SMIL content force 3GPP—SMIL content is prioritized. Accordingly, in the above embodiment, priority is given to OMA-SMIL content. In another embodiment, 3GPP-SMIL content can be prioritized. In this case, for example, when both the 3GPP counter and the OMA counter are “0”, or the counter value of the 3GPP counter is “1” or more, it is determined that the received content is 3GPP-SMIL content, Processing to temporarily store the received content in the folder for PP SMIL content.
  • the counter value of the 3GPP counter is “0” and the counter value S of the OMA counter is S “l” or more, it is determined that the received content is OMA—SMIL content, and it is stored in the folder for OMA—SMIL content. Performs processing to store the received content temporarily.
  • FIG. 26 is a flowchart showing processing by the SMIL rendering engine 510.
  • step S1401 it is determined whether the input SMIL content is stored in the 3GPP-SMIL content folder or the OMA-SMIL content folder (step S1401). If it is stored in the folder for OMA—SMIL content (step S 1401: YES), the process proceeds to step S 1402. In step S 1402, processing by the parser is performed and a document tree is generated. Thereafter, in step S1403, layout processing is started, and layout processing conforming to the OMA—SMIL content is performed (step S1404). In other words, layout processing tailored to the display screen Done. After the layout process is completed (step S1405), this process ends.
  • step S1406 If the input SMIL content is stored in the 3GPP—SMIL content folder (step S1401: NO), the process proceeds to step S1406. Since the processing from step S140 6 to S 1407 is the same as the processing from step S 1402 to S 1403, the description is omitted. In step S1408, layout processing conforming to 3GPP-SMIL content is performed. In other words, the layout process specified by layout is performed. After the layout process is completed (step S1409), this process ends.
  • the messaging client 400 (or 500) shown in FIG. 6 (or FIG. 24) does not necessarily have to have the SMIL rendering engine 410 (or 510). That is, the SMIL rendering engine 410 (510) may be a separate module from the messaging client 400 (500). In this case, the SMIL rendering engine 410 (510) may be activated by the messaging client 400 (500) force instruction.
  • a plurality of contents described in a markup language that also receives an external force are the same as SMIL.
  • the situation is described in the markup language, the situation where the layout is interpreted using the same rendering engine, the situation where MMS and! Are transmitted in the same messaging format, and the same This is realized for the situation where reception management is performed by the messaging client.
  • content that is allowed to change layout such as OMA-SMIL content, would be confused and there was a possibility that proper layout would not be performed.
  • markup language content that is allowed to be changed in layout and markup language content that should not be changed in layout is not limited to the above.
  • the SMIL content that is allowed to be changed in layout is compliant with OMA-SMIL content, and the SMIL content that is to be displayed without changing the layout is 3GPP.
  • the power given by exemplifying what conforms to SMIL content It is not necessarily limited to that standardized by 3GPP or OMA.
  • the mailer and message client may be a single program.
  • the character information display area and the image display area are described by the markup language in which the size and position are specified and laid out on the display screen of the terminal device.
  • a rendering method and a terminal device that can make all the contents of each display region visible and improve the appearance of the content.
  • the label is appropriately set according to the received markup language content.
  • Out processing can be performed.
  • the position of the character information display area where the information should be displayed and the position of the image display area where the image should be displayed may be determined as the position of each element.
  • the determined character information display area and an image arranged in the image display area overlap it is determined whether or not the determined character information display area and an image arranged in the image display area overlap, and it is determined that there is no overlap. Sometimes it may be further determined whether or not the force is separated.
  • the size of the image, the position of the image, the size of the image display area, the position of the image display area, the position of the character information display area, the size of the character information display area may be adjusted by making a predetermined change in at least one of the image display method and the character information display method.
  • the markup language is described so that a plurality of slides including a character information display area and an image display area are arranged on a time axis. Also good.
  • the image or the character information display area when it is determined that a gap is generated between the image and the character information display area, the image or the character information display area is changed so as to fill the gap. Also good.
  • the character information display area is laid out according to the image and / or the image is enlarged according to the gap. By performing one of these, the image or character information display area may be changed so as to fill the gap.
  • the character information display area when it is determined that there is an overlap between the image and the character information display area, the character information display area is moved to a position that does not overlap the image! Of the character information display area, an area arranged outside the display screen of the terminal device may be displayed by a user operation.
  • the character information display area is moved to a position that does not overlap the image, and the range of the display screen of the terminal device in the character information display area is moved. Placed in In the designated area, the entire content of the character information may be displayed within the predetermined time designated in the markup language content.
  • the predetermined time can be equal to any one of the display times of the slide, the character information display area, or the image display area. Also, displaying the entire text information within the time specified in the markup language content means that the length of the text information display, the size of the text information display area in the display screen, and the predetermined time.
  • the display of character information can be moved at a speed calculated in consideration of the above.
  • the character information display area when it is determined that there is an overlap between the image and the character information display area, the character information display area is arranged so as to overlap the image, and further the character information is displayed. Make the background of the display area transparent.
  • the execution content of the predetermined change may be set by the user's operation.
  • the execution content of the predetermined change may be determined according to the content described in a predetermined tag of the markup language. Further, whether or not to execute a predetermined change may be determined based on the contents described in a predetermined tag of the markup language. It should be noted that the contents instructing how to perform the predetermined change according to the user selection can be included in the predetermined tag.
  • the image may be enlarged or reduced so that the horizontal width or the vertical width of the image display area whose position with respect to the display screen is determined to coincide with each other. good.
  • the content described in the markup language may be transmitted and received by the terminal device as a message created by the user or content provider.
  • the predetermined condition may be a condition for determining which specifications the markup language content is created according to.
  • the predetermined condition is whether or not DRM protection is designated for markup language content, and the markup language content If it is determined that DRM protection is specified, the content may be determined to be displayed without changing the layout.
  • the predetermined condition may be based on the content of a meta tag in the markup language content.
  • the content of the meta tag may include information that can specify the content provider.
  • the predetermined condition is that the markup language content is SMIL (Synchronization Multimedia Integration Language), and the SMIL is received via MMS (Multimedia Messaging Service). This is based on information that identifies the sender in the MMS message, including up-load content, and if it contains the specified information, it should be displayed without changing the layout. It may be judged.
  • SMIL Synchronization Multimedia Integration Language
  • MMS Multimedia Messaging Service
  • the predetermined condition is that the markup language content is SMIL (Synchronization Multimedia Integration Language), and the SMIL is received when the SMIL is received via MMS (Multimedia Messaging Service).
  • MMS messages that contain up-ranging content! /, May be based on a header defined for functional enhancements!
  • the predetermined information may include information for specifying whether or not the content is to be displayed without changing the layout.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • General Health & Medical Sciences (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Computer Security & Cryptography (AREA)
  • Controls And Circuits For Display Device (AREA)

Abstract

　コンテンツを解釈するコンテンツ解釈ステップと、解釈ステップによる解釈結果に基づき、該コンテンツが表示される表示画面上における当該コンテンツの各要素の位置を決定する位置決定ステップと、該決定された位置において各要素が密接した状態に配列されるか否かを判定する配列判定ステップと、該配列判定ステップにおいて密接した状態に並んで配列されないと判定されたとき、各要素それぞれがユーザに視認可能となるように当該各要素のレイアウトを調整するレイアウト調整ステップとを含むレンダリング方法を提供する。

Description

明 細 書
コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを 表示可能な端末装置
技術分野
[0001] 本発明は、マークアップランゲージで記述されたコンテンツをレンダリングするため の方法、プログラム、及び、このようなコンテンツを表示可能な端末装置に関するもの である。より詳細には、コンテンツのレイアウトに係るレンダリング方法、プログラム、及 び、端末装置に関するものである。
背景技術
[0002] 近年、 W3C (World Wide Web Consortium)により XMLの応用言語として SMIL (S ynchronization Multimedia Integration Language)の標準ィ匕が進められ、幅リムく禾 IJ用 されている。 SMILを用いることにより、動画、静止画、音声、音楽、文字など様々な 形式のデータの再生を制御して同期させ、マルチメディアプレゼンテーションを作成 することができる。
[0003] また、携帯電話等にお!、て、文字 (Text)、画像 (Image)、音声などを短!、メッセ一 ジにして送受信できるサービスである MMS (Multimedia Messaging Service)が普及 している。 MMSは 3GPP (3rd Generation Partnership Project)や OM A (Open Mobi le Alliance)において標準化されている。 MMSでは、 SMILで記述されたコンテンツ (以下、「SMILコンテンツ」と記す)をメッセージに添付して送受信することができる。 S MILコンテンッには、文字や画像等の要素が含まれる。
[0004] SMILコンテンツには、例えば OMA- MMS Conformance Documentに準拠して作成 されるべきもの（以下、「OMA— SMILコンテンツ」と称す）と、 3GPP及び W3Cにより 策定された仕様に準拠して作成されるべきもの（以下、「3GPP— SMILコンテンツ」と 称す）がある。 OMA— SMILコンテンツも 3GPP— SMILコンテンツも MMSを利用 して送受信することができる。
[0005] OMA— SMILコンテンツにおいては、画面上に表示される際、画像等を表示する ための領域である Image領域と文字情報等を表示するための領域である Text領域 とがそれぞれレイアウトされる。例えば特開 2004— 56469号公報には、 OMA— S MILコンテンツに対する方法であって、端末の表示画面に合わせてレイアウト処理を する方法が開示されている。
[0006] より詳細には、特開 2004— 56469号公報には、携帯端末機器のような表示画面 サイズに厳し 、制約がある場合にぉ 、て、 SMILで記述された同期化マルチメディア プレゼンテーションを再生する方法が記載されている。すなわち特開 2004— 56469 号公報によれば、端末機器が備える表示画面のサイズや解像度などの諸条件に合 わせてレイアウトが最適化され、マルチメディアプレゼンテーションが再生される。
[0007] また、米国特許第 6, 326, 970 B1公報及び WO 2004/023450 A1公報に は、 HTMLにお!/、て Image領域や Text領域のレイアウトを画面サイズに合わせて変 更させる旨が記載されて 、る。
発明の開示
[0008] 3GPP— SMILコンテンツは、 OMA— SMILコンテンツと比較してリッチなコンテン ッであることが多い。 3GPP— SMILコンテンツでは、コンテンツ作成者（例えばコン テンップロノイダ等）の意図したレイアウトがそのまま反映されて表示されることが重 要である。従って、 SMILを再生するためのアプリケーション（レンダリングエンジン） 力 3GPP— SMILコンテンツに対して、 OMA— SMILコンテンツと同様に、画面サ ィズゃ解像度等の諸条件に合わせてレイアウトを最適化させてしまうことは望ましくな い。すなわち、レンダリングエンジンは、 3GPP— SMILコンテンツに対して、例えば 表示画面内に全ての画像が表示されない場合であっても忠実にレイアウトを行い、ュ 一ザによるコンテンツ画面のスクロール等の手段によって初めてコンテンツ全体がブ ラウジング可能となるようレンダリング処理を行う必要がある。
[0009] 一方で OMA— SMILコンテンツは、携帯電話等で画像付きメールとして用いられ ることから、本文部分が一画面中に収まるようにレイアウトされることが望ましい。これ を考慮して、 OMA— SMILコンテンツではレイアウトを適宜変更して表示させること が仕様上許されて 、る。例えば画像とテキストを一画面中に収めるようにレイアウト変 更することが可能である。すなわち、 OMA— SMILコンテンツに対しては、レンダリン グエンジンは、表示画面内に画像とテキストが収まりきらない場合、その全体を例え ば縮小表示させるようレンダリング処理を行う。これにより、ユーザは、スクロール等の 操作なしでも当該コンテンツ全体をブラウジングすることが可能となる。
[0010] し力し、レンダリングエンジンの実装を OMA— SMILコンテンツに合わせた場合、 処理対象が 3GPP— SMILコンテンツであるにも拘わらず、そのレイアウトが変更され てしまうことが想定される。この場合、 3GPP— SMILコンテンツの作成'提供側の意 図が端末装置上では反映されないという問題が起こり得る。またレンダリングエンジン の実装を 3GPP— SMILコンテンツに合わせた場合、 OMA— SMILコンテンツであ つても端末側の諸条件に合わせたレイアウトの最適化が実行されな 、と 、う問題が起 こり得る。
[0011] また OMA— SMILコンテンツにおいてレイアウトを変更させたとき、以下の問題が 起こり得る。例えばレイアウトを指定するタグの内容と受信端末の画面サイズの関係 によっては、 Text領域と Image領域とが重なってしまうことがあり得る。このときの互い の領域の重なり具合によっては、ユーザがテキストを部分的に読み取れなくなること が想定される。先に挙げた公報では Text領域と Image領域とが重なることは想定さ れていない。 OMA— SMILコンテンツはメッセージングであるという性質上、テキスト が読めなくなる事態は、なるべく避けるべきである。
[0012] また、 OMA— SMILコンテンツでは、レイアウトを指定するタグの内容と受信端末 の画面サイズの関係によっては、 Text領域と Image領域とが離れてしまうことがあり 得る。この場合、表示画面上の画像と文字の間に余分なスペースが生じてしまうこと が想定される。そのように余分なスペースが生じると、コンテンツの見栄え力 ッセ一 ジング作成者の意図に反して悪くなるという問題が生じ得る。
[0013] また、 OMA— SMILコンテンツでは、 Image領域に画像が表示される。該画像の 縦幅と横幅の比（アスペクト比）力 mage領域のアスペクト比と等しい場合、画像に対 し拡大'縮小を行うことにより Image領域に等しいサイズとして Image領域内に画像が 表示される。しかし、画像のアスペクト比力 mage領域のアスペクト比と異なる場合、 該画像の横幅（或いは縦幅）を Image領域の横幅（或!/ヽは縦幅）に合うように拡大'縮 小してレイアウトされる。この場合、 Image領域内に空白領域を有しつつ画像が表示 された状態、或いは、 Image領域は全て画像で満たされるが当該 Image領域力ゝら画 像がはみ出た状態となる。すなわち前者の場合、画像と Text領域の間に余分なスぺ ースが生じた状態となり得る。後者の場合、画像と Text領域に重なりが生じた状態と なり得る。画像と Text領域の間に余分なスペースが生じるとコンテンツの見栄えが悪 くなるという問題がある。また画像と Text領域に重なりが生じるとユーザがテキストの 少なくとも一部を読み取れなくなるという問題がある。
[0014] そこで、本発明は上記の事情に鑑みて、受信したコンテンツに応じてレイアウト処理 を適切に実行することができるコンテンツのレンダリング方法、コンテンツを表示可會 な端末装置、及び、コンテンツをレンダリングするためのプログラムを提供することを 課題としている。
[0015] 上記の課題を解決する本発明の一態様に係るレンダリング方法は、所定のマーク アップランゲージで記述されレイアウトが指定されたコンテンツをレンダリングする方 法である。このレンダリング方法は、該コンテンツを解釈するコンテンツ解釈ステップと 、解釈ステップによる解釈結果に基づき、該コンテンツが表示される表示画面上にお ける当該コンテンツの各要素の位置を決定する位置決定ステップと、該決定された位 置において各要素が密接した状態に配列されるか否かを判定する配列判定ステップ と、該配列判定ステップにおいて密接した状態に配列されないと判定されたとき、各 要素それぞれがユーザに視認可能となるように当該各要素のレイアウトを調整するレ ィアウト調整ステップとを含む方法である。
[0016] また上記の課題を解決する本発明の一態様に係る端末装置は、所定のマークアツ プランゲージで記述されレイアウトが指定されたコンテンツを表示画面上に表示可能 なものである。この端末装置は、該コンテンツを解釈するコンテンツ解釈手段と、解釈 手段による解釈結果に基づき、その表示画面上における該コンテンツの各要素の位 置を決定する位置決定手段と、該決定された位置にお!、て各要素が密接した状態 に配列されるか否かを判定する配列判定手段と、該配列判定手段にぉ 、て密接した 状態に配列されないと判定されたとき、各要素それぞれがユーザに視認可能となるよ うに当該各要素のレイアウトを調整するレイアウト調整手段とを具備したことを特徴と したものである。
[0017] したがって、本発明のレンダリング方法或いは端末装置では、表示画面上において 各要素が密接した状態に配列される力否力 (例えばイメージと Text領域との重なり或 いは隙間の有無)を判断し、その判定結果に応じて当該各要素のレイアウトが調整さ れる。このような構成により、各要素に対するユーザの視認性が確保されると共にコン テンッ自体の見栄えも向上する。
[0018] また上記の課題を解決する本発明の別の態様に係るレンダリング方法は、受信した マークアップランゲージコンテンツを解釈し、所定の条件を満たす力否かにより、レイ アウトを変更することが許容されるコンテンツである力、レイアウトを変更しな 、で表示 されるべきコンテンツであるかを判断し、その判断結果に応じてレイアウト処理を行う ことを特徴としたものである。
[0019] また上記の課題を解決する本発明の別の態様に係る端末装置は、受信したマーク アップランゲージコンテンツを解釈し、マークアップランゲージコンテンツが所定の条 件を満たすか否かにより、レイアウトを変更することが許容されるコンテンツであるかレ ィアウトを変更しないで表示されるべきコンテンツであるかを判断し、その判断結果に 応じてレイアウト処理を行うレンダリング手段を備えることを特徴としたものである。
[0020] また上記の課題を解決する本発明の一態様に係るプログラムは、上記レンダリング 方法をコンピュータに実行させるためのプログラムである。
図面の簡単な説明
[0021] [図 1]本発明の実施形態の携帯電話機の外観図である。
[図 2]本発明の実施形態の携帯電話機のハードウェア構成を示す機能ブロック図で ある。
[図 3]MMSの構造を示す図である。
[図 4]OMA— SMILコンテンツの一例である。
[図 5]SMILコンテンツの一例を模式的に示す図である。
[図 6]メッセージングクライアントの機能を説明するための図である。
[図 7]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 8]図 7の処理により表示される画面を示す模式図である。
[図 9]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 10]図 9の処理により表示される画面を示す模式図である。 [図 11]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 12]図 11の処理により表示される画面を示す模式図である。
[図 13]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 14]図 13の処理により表示される画面を示す模式図である。
[図 15]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 16]図 15の処理により計算される Image領域及び Text領域と、イメージの大きさ の関係を示す図である。
[図 17]図 15の処理により、図 16のイメージを拡大 ·縮小を行った場合を示す図である
[図 18]図 15の処理により計算される Image領域及び Text領域と、イメージの大きさ の関係を示す図である。
[図 19]図 15の処理により、図 18のイメージを拡大 ·縮小を行った場合を示す図である
[図 20]図 15の処理により、表示される画面を示す図である。
[図 21]図 15の処理により、表示される画面を示す図である。
[図 22]メッセージングクライアントの処理動作を示すフローチャートである。
[図 23]SMILレンダリングエンジンによる処理を示すフローチャートである。
[図 24]他の実施形態によるメッセージングクライアントの機能を説明するための図で ある。
[図 25]メッセージングクライアントの処理動作を示すフローチャートである。
[図 26]SMILレンダリングエンジンによる処理を示すフローチャートである。
発明を実施するための最良の形態
[0022] 以下、本発明に係るレンダリング方法および端末装置について図を参照して説明 する。なお、本発明の実施形態においては、マークアップランゲージとして SMIL (Sy nchronization Multimedia Integration Language)を用 ヽ" 兄！ ^を? Tつ。し力し、本発明 を実施するためのマークアップランゲージは SMILに限定されるものではない。
[0023] 図 1は本発明に係るレンダリング方法を実現することができる携帯電話機 10の外観 図を示す。図 2は携帯電話機 10のハードウェア構成を表す機能ブロック図である。図 1に示すように、携帯電話機 10の筐体の操作面側には、液晶ディスプレイ 111と、操 作部とが設けられている。操作部には、ダイヤルボタン 114、方向指示キー 115、ォ ンフックボタン 121、オフフックボタン 122が含まれる。また、操作面側上部には、スピ 一力 119用の孔と、アンテナ 105とが設けられ、下部にはマイク 118用の孔が設けら れている。本実施形態では、 SMILコンテンツをレンダリングして表示する端末装置と して携帯電話を例に挙げているが、本発明は携帯電話以外の他の端末装置におい ても実施可能である。
[0024] 図 2の機能ブロック図について説明する。携帯電話機 10は、装置全体を制御する CPU100を有する。 ROM101、 RAM102、フラッシュメモリ 103、無線通信制御部 104、液晶ディスプレイ 111、入力インタフェース部 113、および音声制御部 117は それぞれ CPU100に接続されている。また、無線通信制御部 104にはアンテナ 105 力 入力インタフェース部 113には操作部の各種キー力 音声制御部 117にはマイ ク 118およびスピーカ 119が接続されて!、る。
[0025] ROM101は、 CPU100により実行される各種プログラムおよび固定的なデータを 格納した不揮発性の読み出し専用メモリである。 RAM102は、 CPU100の作業領 域およびデータの一時記憶領域を提供する書き込み可能なメモリである。フラッシュ メモリ 103は、追カ卩的なアプリケーションプログラムや各種データを記憶する再書き込 み可能な不揮発性メモリである。
[0026] 無線通信制御部 104は、アンテナ 105を介して基地局との間で音声およびデータ の無線通信 (送受信）を行う機能を有する。液晶ディスプレイ 111は表示画面を有す る表示部を構成する。入力インタフェース部 113は、ダイヤルボタン 114や方向指示 キー 115等の入力操作を受け付ける機能を有する。音声制御部 117には、マイク 11 8およびスピーカ 119が接続される。音声制御部 117は、マイク 118およびスピーカ 1 19を介して音声の入出力を制御する。
[0027] ROM101は、ブラウザ、メーラ、メッセージングクライアント、その他携帯電話機 10 に使用する各種アプリケーションを格納している。ブラウザの起動に伴い携帯電話機 10は無線通信制御部 104を介して通信ネットワークと接続され各種コンテンツの閲 覧が可能になる。メーラは Eメール等のメールを送受信する機能を有する。メッセージ ングクライアントは、 MMS (Multimedia Messaging Service)により SMILコンテンツの 添付されたメッセージ (MMSメッセージ)を送受信する機能を有する。また、メッセ一 ジングクライアントは、 SMIL用のレンダリングエンジンを有している。 SMILレンダリン グエンジンは SMILコンテンツをレンダリングして再生するための機能を有する。なお 、 SMILレンダリングエンジンは、メッセージングクライアントに含まれている構成では なぐメッセージングクライアントと独立したアプリケーションであってもよい。
[0028] MMSについて説明する。 MMSは、携帯電話等において、文字、音声、画像など をメッセージにして送受信することができるサービスである。図 3は、 MMSメッセージ の構造を示す模式図である。 MMSメッセージ 200は、 MMS header部 210と Messag e body部 220と力らなる。 MMS header部 210には、種々の情報が付カ卩されている。 MMS header部 210に付カ卩されている情報には、例えば送信者の e- mailアドレス、電 話番号、メッセージのタイトル、送信者'受信者の 3GPPや OMAが定める識別子等 が挙げられる。 MMS header部 210はさらに拡張ヘッダを有し、送信者が任意に情報 を付与することができる。また、拡張ヘッダは、 MMS header部 210の他、 MMSメッセ ージを送受信するための通信プロトコルのヘッダ部に含まれて 、てもよ 、。 Message body部 220は、 SMILコンテンツを有する。
[0029] 図 4は、 SMIL (OMA— SMILコンテンツ）文書の一例である。 SMILの文書は smil タグ内に、 headタグで囲まれたヘッダ部 230と bodyタグで囲まれたボディ部 240とを 有する。ヘッダ部 230は、 metaタグ、 layoutタグ等を有する。 metaタグ内には通常、タ ィトル ("title")、作成者の名称 ("author")、著作権情報（"copyright")等の書誌的事 項が記載される。 metaタグ内の情報により例えばメール送信者を特定することができ る。 layoutタグ内には、各領域 (画像、テキスト等）のレイアウトを指定するための region タグ等がある。ボディ部 240は、 parタグを有する。 parタグは画像 (Image)、テキスト（ Text)、音声 (Audio)等の各コンテンツを同時に再生させるためのタグである。
[0030] 図 5は、図 4に示す SMILコンテンツの再生表示を模式的に示す図である。図 4に 示す OMA— SMILコンテンツは、スライド形式で再生される。すなわち、複数のスラ イドが時間軸上に配列されて 、る。各スライドは SMIL文書中に記載された時間だけ 表示され (例えばく par dur="5s"〉と記載されていれば 5秒間）、その後次のスライドに 入れ替わる。このコンテンツの場合、まずスライド 300が再生され (5秒間）、その後ス ライド 310が再生される（10秒間）。スライド 300は、画像領域 301に画像が表示され るとともにテキスト領域 302にテキスト「朝だ！」が表示され、音声も同時に再生される 。その後スライド 310が再生される力 スライド 310の画像領域 311及びテキスト領域 312は、スライド 300の画像領域 301及びテキスト領域 302のレイアウトと等しい（す なわち、スライド間でレイアウトは固定されている)。また、 SMIL文書では、各スライド 中の画像領域及びテキスト領域にもそれぞれ表示時間を設定することができる。
[0031] 図 4及び図 5に示す OMA— SMILコンテンツでは、 regionタグにより、画像領域 30 1 (311)は幅 160、高さ 160、開始位置（上から） 0%、テキスト領域 302 (312)は幅 1 60、高さ 40、開始位置（上から） 80%、とそれぞれ規定されている。すなわち、画面 サイズが幅 160 X高さ 200以上である場合を想定しているレイアウトである。なお、 re gionタグによるこれらの値の指定は例示的なものであり、例えば開始位置はパーセン ト指定ではなく数値により指定することもできる (例えばテキスト領域 302の開始位置 を上から 160とする）。
[0032] 上述した SMILコンテンツは、 OMA— SMILコンテンツであり、 3GPP— SMILコン テンッと比して表示 ·再生方法が限定的なコンテンツである。例えば、 OMA-SMIL コンテンツは、 parタグ内に 1つの text、 1つの image、 1つの soundのみ指定可能である (videoを用いる場合には、 1つの videoと、 1つの text)。また、 OMA— SMILコンテン ッでは、 regionタグは image領域を設定するものと text領域を設定するものとの 2つの み出現する。 OMA— SMILコンテンツは、主に携帯電話の一般ユーザにより作成さ れる。
[0033] 3GPP— SMILコンテンツは、例えば静止画、サウンド、ァ-入 3D、動画などが組 み合わされたものである。 3GPP— SMILコンテンツでは、各コンテンツが時間軸で 同期されることにより TV的な演出が可能である。従って、通常、 OMA— SMILコン テンッよりも使用されるタグの種類が多くなる。附言するに 3GPP— SMILコンテンツ では、ハイパーリンクを付加することも可能である。また著作権管理のための DRM (D igital Rights Management)保護を使用することも可能である。 3GPP— SMILコンテン ッは、当該コンテンツに対する対価を得る目的でコンテンツプロバイダにより作成され る場合が多い。 3GPP— SMILコンテンツは、コンテンツ作成者の意向を端末の画面 に反映させるため、本実施形態においてレンダリングにより画面の大きさ等に応じた レイアウト変更は実施されな 、。
[0034] なお DRMとは、デジタルデータの著作権を保護するための技術である。 DRMに は、フォワードロック（Forward Lock: FL)、セノ《レートデリノくリ（Separate Delivery : SD) 、コンバインドデリバリ（Combined Delivery: CD)等の形式がある。フォワードロックは、 コンテンツに対して転送禁止の処理がされている形式である。コンバインドデリバリは 、再生するための権利（Rights)とコンテンツがセットで配信されてくる形式であり、コン テンッに対して転送禁止処理や再生回数 ·期間等の制限が付されて 、る。セパレー トデリバリは、 Rightsと暗号ィ匕されたコンテンツが別々に配信されてくる形式であり、ュ 一ザが Rightsを購入することによりコンテンツを再生することができる。
[0035] 図 6は、メッセージングクライアントの機能を説明するための図である。メッセ一ジン グクライアント 400は、 MMSメッセージ 200を送受信する機能を有するアプリケーショ ンであり、 SMILレンダリングエンジン 410を有している。メッセージングクライアント 40 0は、メッセージ受信機能（F01)を有する。 SMILレンダリングエンジン 410は、 SMI Lを解釈する機能 (すなわちバーサ）（F02)と、表示画面上に表示される各領域のサ ィズを計算する機能 (F03)と、それらの結果に基づ 、てレイアウトを行う機能 (F04) とを有する。
[0036] 附言するにレイアウト機能 (F04)にお 、ては、 layoutタグや実際の表示画面幅など に基づいてレイアウト処理が実行される。なお本発明の実施形態では、 3GPP-SM ILコンテンツの場合は表示画面を考慮せず layoutタグで指定されたレイアウトでレン ダリング処理が実行される。一方で OMA— SMILコンテンツの場合は表示画面に合 わせてレイアウトが変更されてレンダリング処理が実行される。また OMA— SMILコ ンテンッの場合、 Image領域と Text領域が重ならな 、ときには layoutタグで指定され たレイアウトでレンダリング処理が実行される。また、 Image領域と Text領域が重なる ときには所定の処理が実行される。 SMILレンダリングエンジン 410による以上のよう な処理を経て、 SMILコンテンツが携帯電話 10の表示画面に表示される。
[0037] なお、メッセージングクライアント 400は、必ずしも SMILレンダリングエンジン 410を 有していなくてもよい。すなわち、 SMILレンダリングエンジン 410力 Sメッセージングク ライアント 400とは別のモジュールであってもよい。その場合、メッセージングクライア ント 400力 指示により、 SMILレンダリングエンジン 410を起動する構成であってもよ い。
[0038] 以下、本発明の幾つかの実施の形態について説明する。第一乃至第五の実施形 態は、 OMA— SMILコンテンツに対するレイアウト処理であって、ユーザに対する当 該コンテンツに含まれるテキストの視認性を向上させるレイアウト処理を行うものに関 する。このため、第一乃至第五の実施形態の説明における SMILコンテンツは全て O MA— SMILコンテンツを意味する。
[0039] 本発明の第一の実施形態を図 7及び図 8を用いて説明する。
[0040] 図 7は、 SMILレンダリングエンジン 410により実行される処理を示すフローチャート である。ステップ S101では、受信した SMILコンテンツを解釈する。ステップ S102で は、表示画面のサイズを考慮して、 Image領域の及び Text領域を計算する。ステツ プ S103では、ステップ S102の計算結果に基づ!/、て Image領域と Text領域が重な るかどうか判断する。 Image領域と Text領域にぉ 、て重なる部分があれば (ステップ S103 :YES)、ステップ S104に進む。 Image領域と Text領域において重なる部分 がなければ (ステップ S103 :NO)、ステップ S106に進む。ステップ S104では、 SMI Lレンダリングエンジン 410のレイアウト機能（F04)により、 Image領域と Text領域と が重ならない位置にずらす。例えば regionタグによる指定を無視し、別の値を設定す ることにより、 Image領域と Text領域とが重ならないようにレイアウトすることができる。 ステップ S105では、 Text領域うち、表示画面に入らない領域があれば、スクロール 表示可能とする処理を行う。ステップ S 106では、表示処理を行う。すなわち、携帯電 話機 10の液晶ディスプレイ 111に表示させる。ステップ S 106による表示処理完了後 、本処理は終了する。
[0041] 図 8に、図 7の処理終了後（ただし、ステップ S103において YESの場合）のレイァゥ トの模式図を示す。 Image領域 511と、 Text領域 512と、表示画面に入りきらない Te xt領域 513と、スクロールバー 514とを有する。ユーザはスクロールバーを操作する ことにより、 Text領域に表示されるべき文字情報等を全て見ることができる。なお、本 発明の実施形態においては、 Text領域を表示画面に対して垂直方向に移動させた 。しかし、その移動方向は、表示画面の形状及びサイズに依存するものであり、垂直 方向に限定されるものではない。
[0042] 次に、本発明の第二の実施形態を図 9及び図 10を用いて説明する。
[0043] 図 9は、 SMILレンダリングエンジン 410により実行される処理を示すフローチャート である。ステップ S201力ら S203に示す処理は、図 7のステップ S101力ら S103に示 す処理と同様であるので説明を省略する。ただし、ステップ S203において「NO」の 場合 (すなわち、 Image領域と Text領域に重なる部分がない場合）は、ステップ S 20 5へ進む。ステップ S204では、 Text領域は Image領域の上に配置され、さらに Text 領域の背景は透過状態にされる。すなわち、 Text領域と Image領域の重なった部分 においては、 Imageの上にテキスト等が表示されるため、テキスト等の一部が隠れて しまうことがない。ステップ S205では、表示処理を行う。すなわち、携帯電話機 10の 液晶ディスプレイ 111に表示させる。ステップ S205による表示処理完了後、本処理 は終了する。
[0044] 図 10に、図 9の処理終了後（ただし、ステップ S203において YESの場合）のレイァ ゥトの模式図を示す。 Image領域 521と、 Text領域 522と、重なり領域 523とを有す る。重なり領域 523においては、テキストが Image上に表示されるため、ユーザは Te xt領域に表示されるべき文字情報等を全て見ることができる。なお、本発明の実施形 態においては、 Text領域と Image領域とが垂直方向に重なっている。し力し、その 重なり方は、表示画面の形状及びサイズに依存するものであり、垂直方向に限定さ れるものではない。
[0045] 次に、本発明の第三の実施形態を図 11及び図 12を用いて説明する。
[0046] 図 11は、 SMILレンダリングエンジン 410により実行される処理を示すフローチヤ一 トである。ステップ S301力ら S304に示す処理は、図 9のステップ S201力ら S204に 示す処理と同様であるので説明を省略する。ただし、ステップ S303において「NO」 の場合 (すなわち、 Image領域と Text領域に重なる部分がない場合）は、ステップ S 306へ進む。ステップ S305では、テキストの色をテーブル 535から抽出する。テープ ル 535は、携帯電話機 10に備えることができる。テーブル 535は、 Image領域の背 景の色に対してユーザが見やす 、テキストの色の情報をテーブルとして保有して!/ヽ る。ステップ S306では、表示処理を行う。すなわち、携帯電話機 10の液晶ディスプ レイ 111に表示させる。ステップ S306による表示処理完了後、本処理は終了する。
[0047] 図 12に、図 11の処理終了後（ただし、ステップ S303において YESの場合）のレイ アウトの模式図を示す。 Image領域 531と、 Text領域 532と、重なり領域 533とを有 する。重なり領域 533においては、テキストが Image上に表示され、且つ Image領域 の背景色に対して見やすい色で表示されるため、ユーザは、より Text領域に表示さ れるべき文字情報を全て見ることができる可能性が高くなる。なお、本発明の実施形 態においても、 Text領域と Image領域とが垂直方向に重なっている。しかし、その重 なり方は、表示画面の形状及びサイズに依存するものであり、垂直方向に限定される ものではない。
[0048] 本発明の第四の実施形態を図 13及び図 14を用いて説明する。
[0049] 図 13は、 SMILレンダリングエンジン 410により実行される処理を示すフローチヤ一 トである。ステップ S401力ら S404に示す処理は、図 7のステップ S 101力ら S104に 示す処理と同様であるので説明を省略する。ただし、ステップ S403において「NO」 の場合 (すなわち、 Image領域と Text領域に重なる部分がない場合）は、ステップ S 406へ進む。ステップ S405では、 Text領域に表示されるべき内容を、表示画面上 の Image領域を除く領域を用いて表示させるための処理を行う。より詳細には、表示 されるべきテキストを所定の速度で自動スクロールさせる。これにより、スライドを表示 させて 、る期間中にテキストの全内容を表示させることが可能となる（テロップ表示)。 この場合のテキストを移動させる速度は、例えば、表示領域のサイズと、テキストの長 さ（フォントサイズ、文字間隔等により算出される）と、 parタグで指定されるスライドの表 示時間（或いは Image、 Textの表示時間）により算出することができる。ステップ S40 6では、表示処理を行う。すなわち、携帯電話機 10の液晶ディスプレイ 111に表示さ せる。ステップ S406による表示処理完了後、本処理は終了する。
[0050] 図 14に、図 13の処理終了後（ただし、ステップ S403において YESの場合）のレイ アウトの模式図を示す。 Image領域 541と、 Text領域 542 (すなわち、表示画面上の Image領域 541を除く領域）とを有する。 Text領域 542においてテキストがテロップ 表示される。このテロップ表示により、ユーザは、 SMILコンテンツにより指定された T ext領域において、当該領域で表示されるべき文字情報等を全て見ることができる。 なお、本発明の実施形態においては、 Text領域を表示画面に対して垂直方向に移 動させた。しかし、その移動方向は、表示画面の形状及びサイズに依存するものであ り、垂直方向に限定されるものではない。また、本実施形態におけるテロップ表示は 、 Image領域 541を除く領域 (Text領域 542)において行った力 テロップ表示され るテキストの一部或いは全部力 Image領域 541に表示されてもよい（ただし、 Image 領域 541にお 、てはテキストの背景透過とする）。
[0051] 上述の第一から第四の実施形態に示すレンダリング処理 (第一から第四の実施形 態をそれぞれ第一モードから第四モードとする）のうちいずれのモードを用いるかは、 ユーザの操作等により切替可能であってもよい。また、 SMILコンテンツの metaタグ内 に、いずれのモードを用いてレンダリングするかを示す情報が含まれていてもよい。ま た、 SMILコンテンツの metaタグ内に、いずれのモードをも用いないでレンダリングす べき（従来のレンダリング方法)ことを指定する情報が含まれて 、てもよ 、。コンテンツ 作成者がレイアウトの変更を望まな 、場合には、 V、ずれのモードも使用しな!、ように 設定することができる。
[0052] OMA— SMILコンテンツでは、 Image領域と Text領域とが同画面内に表示される ことが前提であり、更にこれらが画面上でのレイアウト (位置とサイズ）が指定されてい るため、 MMSメッセージを受信して OMA— SMILコンテンツを表示する端末装置 の表示画面サイズによっては、 Image領域と Text領域とが重なってしまうという問題 が起こりうる。その場合、テキストが部分的に読めなくなってしまう。本発明は、その問 題を解決し、ユーザにとって適切な表示を実現する OMA— SMILコンテンツのレン ダリング方法を提供する。
[0053] また、 OMA— SMILコンテンツは、携帯電話の一般ユーザにより作成されることも 多い。現在、携帯端末装置の表示画面サイズは未だ様々である。一般ユーザが、送 信先の端末装置の表示画面サイズを配慮して OMA— SMILコンテンツを作成する ことは困難であると考えられる。本発明は、テキストが部分的に読めなくなる可能性を 排除するものであるから、 OMA— SMILコンテンツの利便性を高めることができる。 [0054] なお上記実施形態では、 Image領域と Text領域が重なり得るマークアップランゲ ージコンテンツの例として OMAに準拠した OMA— SMILコンテンツを用いて説明を 行った。しかし OMA— SMILコンテンツの代替として、別の規格に準拠したマークァ ップランゲージコンテンツを上記実施形態に適用させることも可能である。また、 MM Sを経由せずに端末が取得した SMILコンテンツにおいても、本発明のレンダリング 方法、端末装置及びプログラムを適用することができる。
[0055] 上述の第一力 第四の実施形態に示すレンダリング処理では、 Image領域に表示 される画像のサイズ力 mage領域のサイズと等し 、場合 (すなわち、 Image領域中全 てに画像が表示される場合）について説明をおこなった。そのため、 Image領域と Te xt領域が重なることによって、画像により Text領域が必然的に隠されることとなって いた。以下に示す実施形態 (第五の実施形態)では、 Image領域中の少なくとも一部 或いは全部に画像が表示されるものとして説明をおこなう。
[0056] 画像データは、 MMSメッセージとともに送信され、 OMA— SMILコンテンツのレン ダリング時においては Image領域を基準としてレイアウトされる。なお、画像は通常、 縦幅と横幅の比（アスペクト比）は固定とされている。画像のアスペクト比力 mage領 域のアスペクト比と同じであれば、その画像を拡大 '縮小することにより Image領域と 等し 、サイズとすることができる。画像のアスペクト比力 mage領域のアスペクト比と異 なる場合は、例えば、 Image領域の横幅に画像の横幅が合うようにその画像を拡大 · 縮小をする等の処理が行われる。また、画面サイズよりも Image領域が大きい場合も 画像を縮小する処理が行われる。 Image領域に画像をレイアウトする場合の SMILレ ンダリングエンジン 410により実行される処理を図 15のフローチャートを用いて示す。
[0057] ステップ S501およびステップ S502の処理は図 7のステップ S101およびステップ S 102の処理と同様であるので説明を省略する。ステップ S503では、画像の拡大'縮 小量およびレイアウトが計算される。すなわち、ステップ S502において、表示画面の サイズを考慮して計算された Image領域に対して画像を適合させるためにその拡大 · 縮小量が計算される。具体的には、画像の横幅が Image領域の横幅と等しくなるよう に計算される。なお、上述のように画像はそのアスペクト比が固定されているものとす る。このステップ S503において行われる処理の概念を図 16から図 19を用いて説明 する。
[0058] 図 16は、ステップ S502により計算された Image領域 551 (縦 90 X横 120)と Text 領域 552 (縦 40 X横 120)、及び画像データ中の画像 555 (縦 30 X横 30)を模式的 に示す。 Image領域 551と Text領域 552とは隣接している（すなわちその境界となる 辺の表示画面上の座標が一致する）。また、表示画面サイズは、縦 130 X横 120とす る。さらに、画像 555の左上頂点の座標は、 Image領域 551の左上頂点の座標に合 わせて配置されるものとする。この場合、画像 555の横幅は、 Image領域 551の横幅 と比して小さい。従って、ステップ S503においては、画像 555の拡大倍率が計算さ れる（縦及び横に 4倍)。画像 555のレイアウト計算後の模式図を図 17に示す。図 17 では、画像 555のサイズが縦 120 X横 120となり、結果として、画像 555の一部が Te xt領域 552上に重なる。
[0059] 図 18では、ステップ S502により計算された Image領域 551 (縦 90 X横 120)と Tex t領域 552 (縦 40 X横 120)、及び画像データ中の画像 556 (縦 100 X横 240)を模 式的に示す。図 16同様、 Image領域 551と Text領域 552とは隣接している（すなわ ちその境界となる辺の表示画面上の座標が一致する）。また、表示画面サイズは、縦 130 X横 120とする。また、画像 556の左上頂点の座標は、 Image領域 551の左上 頂点の座標に合わせて配置されるものとする。この場合、画像 556の横幅は、 Image 領域 551の横幅と比して大きいので、ステップ S503においては、画像 556の縮小倍 率が計算される (縦及び横に 1Z2倍)。画像 556のレイァ外計算後の模式図を図 1 9に示す。図 19では、画像 556のサイズが縦 50 X横 120となり、結果として、画像 55 6と Text領域 552との間に隙間が生じる。
[0060] 図 15のステップ S503の処理後、ステップ S504では、画像と Text領域 552が重な るかどうかが判定される。例えば、図 17に示す例では、画像 555と Text領域 552力 S 縦方向に 30だけ重なるものと計算されているので (ステップ S504 : YES)、ステップ S 506へ進む。画像と Text領域 552が重ならなければ (ステップ S504 : NO)、ステップ S505へ進む。ステップ S505では、画像と Text領域 552間に隙間が生じるかどうか が判定される。例えば、図 19に示す例では、画像 556と Text領域 522との間に縦方 向に 40だけ隙間が生じるものと計算されているので (ステップ S505 : YES)、ステップ S506へ進む。画像と Text領域 552に隙間がないものと判定されれば (ステップ S50 5 : NO)、ステップ S 507へ進む。
[0061] なお別の実施の形態においては、ステップ S504と 505の代替として、ステップ S50 2における計算の結果、画像と Text領域 552が密接した状態に並ぶよう配置される か否かを判定しても良い。
[0062] ステップ S506では、画像と Text領域の調整処理が行われる。例えば、図 17に示 すように画像 555と Text領域 552とが重なるものであれば、図 20に示すように、 Tex t領域 552を重ならないように下に 30だけシフトさせてレイアウトする処理を行う。この 場合、 Text領域 552の一部は表示画面からはみ出してしまうこととなるので、例えば 、第一の実施形態に示したような、表示画面に入らない Text領域をスクロール表示 可能とする処理（図 7のステップ S105)や、第四の実施形態で示したような、 Textの 内容を Image領域の余った部分でテロップ表示する処理（図 13のステップ S405)を 含めてレイアウトすることが可能である。なお、図 20に示すように Text領域 552をシ フトさせなくても、第二の実施形態や第三の実施形態で行ったような、 Text領域の背 景を透過状態としてイメージの上に重ねる処理（図 9のステップ S 204及び図 11のス テツプ S304、 S305)を行うことも可能である。
[0063] また、ステップ S506では、例えば、図 19〖こ示すよう〖こ画像 556と Text領域 552と の間の隙間が生じるものであれば、図 21に示すように、 Text領域 552を該隙間がな くなるように上方に 40だけシフトさせるようにレイアウト処理を行う。ステップ S506の処 理終了後、ステップ S507へ進む。ステップ S507では、レイアウトされた画像、テキス ト等を表示画面に表示する。
[0064] なお、図 16から図 21に示した例では、 Image領域 551と Text領域 552との重なり · 隙間は考慮していない。し力し、図 15のステップ S504及びステップ S505の判定は、 画像と Text領域 552との関係を判定するものであるため、 Image領域 551と Text領 域 552間の重なり'隙間があつたとしても実施することができる。また、上述の第一か ら第四の実施形態は、図 15から図 21に示す第五の実施形態に含まれるものであり、 画像のァスぺクト比力 mage領域 551のアスペクト比と等しいという特定条件のもとで の実施形態であるということができる。また、図 15のステップ S503において画像の拡 大'縮小のレイアウトが必ずしも行われる必要はない。即ち例えば、画像 555のように その横幅力 mage領域 551の横幅よりも小さい場合には、 Image領域 551内にセン タリングして配置されるような場合が想定される。
[0065] 従って、本発明の第一から第五の実施形態によれば、画像及びテキスト情報の一 部をユーザが視認できなくなる状況を回避することが可能である。また、領域間に生 じ得る無駄な隙間を削減できるため、コンテンツの見栄えを向上させることが可能とな る。
[0066] また、画像と Text領域が重なる場合に、 Text領域を変更するというように、画像を 優先して Text領域を変更させるように記載した力 場合によっては、 Text領域をそ のままとして、画像を縮小させる等の変更を行うことも可能である。
[0067] また、 SMILコンテンツ中に画像データが全くな 、場合は、 Text領域の表示画面 上の位置がタグにより指定されて 、てもそれを無視して、 Text領域の表示位置を変 更することができる。すなわち、画像が表示されない場合、表示画面の例えば上側部 分に不必要な空白ができてしまうため、 Text領域を上側に移動する。なお、スライド 再生中に一時的に画像が表示されない (テキストのみ表示される）コンテンツでは、 T ext領域の表示位置の変更は行わな 、。再生中に画像の有無により Text領域が移 動してしまっては、ユーザがコンテンツを見づらくなつてしまうからである。
[0068] 次いで、本発明の第六及び第七の実施の形態について説明する。第六及び第七 の実施形態は、受信した SMILコンテンツの種類を判断し、その判断結果に応じて 受信コンテンツをレイアウト処理するものに関する。附言するに、上記判断処理にお いて受信コンテンツが 3GPP— SMILコンテンツ又は OMA— SMILコンテンツの何 れであるかが判断される。 3GPP— SMILコンテンツである場合には、その記述に従 つたレイアウト処理が実行される。 OMA— SMILコンテンツである場合には、例えば 端末装置の画面サイズ等の諸条件に合わせたレイアウト処理が実行される。
[0069] 図 22は、 MMSメッセージ 200を受信して SMILコンテンツを表示するまでの、メッ セージングクライアント 400の処理動作を示すフローチャートである。まず、 MMSメッ セージ 200を受信する（ステップ S1101)。その後メッセージングクライアント 400は、 コンテンツのメディア（image、 sound, video等）に DRM保護が付されているかどうかを 判別する（ステップ SI 102)。 DRM保護が付されていれば (ステップ SI 102 : YES) 、ステップ SI 103へ進む。 DRM保護が付されていなければ (ステップ S 1102 : NO) 、ステップ SI 104へ進む。
[0070] ここで、メッセージングクライアント 400は 3GPP— SMILコンテンツに対するカウン タ（以下、「3GPPカウンタ」と記す）、及び、 OMA— SMILコンテンツに対するカウン タ（以下、「OMAカウンタ」と記す）を有している。ステップ S1103では、受信した SMI Lコンテンツが 3GPP— SMILコンテンツと判断され、 3GPPカウンタが 1インクリメント される。なお、これらのカウンタのカウント値は、ステップ S 1101のメッセージ受信に応 じてリセット (カウント値 =0)される。
[0071] ステップ S1104では、 MMS header部 210を参照し、その SMILコンテンツがコンテ ンップロノイダにより作成されたものであるかどうかを判別する。例えば、 Fromの箇所 に記述された De-mailアドレス、 2)電話番号、 3)送信者'受信者の識別子等を参照 して、予め携帯電話機 10もしくは外部サーバ内に登録されているコンテンツプロバイ ダ情報 (e-mailアドレス、電話番号、識別子等）と照合を行う。 MMS header部 210にコ ンテンップロバイダ情報があれば (ステップ S 1104 : YES)、ステップ SI 105に進み、 受信した SMILコンテンツが 3GPP— SMILコンテンツと判断され、 3GPPカウンタが 1インクリメントされる。 MMS header部 210にコンテンツプロバイダを示す情報がないと 判断された場合は（ステップ S 1104 : NO)、ステップ SI 106へ進む。
[0072] ステップ S1106では、 MMS header部 210内の拡張ヘッダを参照し、その SMILコ ンテンッがどのような仕様に準拠して作成されているかを判別する。 MMSでは RFC2 822で定義するメッセージデータ同様のヘッダの拡張が可能である。この拡張ヘッダ を利用して送信者が明示的にレンダリング手法を受信者 (携帯電話機）に対して指定 することができる。具体的には" X-Mms- SMIL- Rendering- Option:"のようなヘッダが 定義される。メッセージングクライアント 400は受信時にこのヘッダを解釈 Z保存する 。そしてこの保存された値を参照してこの SMILコンテンツが OMA— SMILコンテン ッであるかどうかを判別する。またステップ S 1106において、 3GPP— SMILコンテン ッで定義されず OMA— SMILコンテンツで定義される属性を含むか否かを判定して も良い。従って OMA— SMILコンテンツと判定されれば (ステップ S1106 : YES)ス テツプ S1107、 OMA— SMILコンテンツで判定されなければ (ステップ S1106 :NO )ステップ SI 108へ進む。ステップ S1107では、受信した SMILコンテンツが OMA SMILコンテンツと判断され、 OMAカウンタが 1インクリメントされる。
[0073] なおステップ S1106において、 OMA— SMILコンテンツとして処理してもよいかど うかを判別したが、拡張ヘッダに 3GPP— SMILコンテンツを定義するヘッダや、 OM A— SMILコンテンツで定義されず 3GPP— SMILコンテンツで定義される属性等が 含まれているかを判定して、 3GPP— SMILコンテンツであるかどうかを判別してもよ い。 3GPP— SMILコンテンツであると推定されれば (ステップ S1106 :YES)、ステツ プ S1107では、受信した SMILコンテンツが 3GPP— SMILコンテンツと判断され、 3 GPPカウンタが 1インクリメントされる。
[0074] ステップ S1108では、 SMILレンダリングエンジン 410により SMILコンテンツに対 するレンダリング処理が行われる。レンダリング処理が終了すると、当該 SMILコンテ ンッが画面に出力される（ステップ S1109)。本処理は、受信した SMILコンテンツが OMA— SMILコンテンツである力 3GPP— SMILコンテンツであるかに基づいて、レ ィアウト変更する力否かを判断して表示させるものである力 本処理終了後は、ユー ザの指示により任意にレイアウト変更を行うことができる。
[0075] 図 23は、 SMILレンダリングエンジン 410による処理を示すフローチャートである。
本処理は図 22におけるステップ S1108において実行される処理である。ステップ S1 201では、バーサによる処理が行われ、ドキュメントツリーが生成される。バーサによ る処理後、 metaタグの内容（"title"、 "author", "copyright"等）を参照して、コンテン ップロバイダにより作成されたものであるかどうか判別する（ステップ S1202)。既知の コンテンツプロバイダの名称等が含まれているような場合にはコンテンツプロノイダに より作成されたコンテンツであると判断し (ステップ S1202 : YES)、ステップ S1203に 進む。ステップ S1203では、受信した SMILコンテンツが 3GPP— SMILコンテンツと 判断され、 3GPPカウンタが 1インクリメントされる。既知のコンテンツプロバイダの名称 等が含まれて!/、な 、場合は (ステップ S 1202 : NO)、ステップ S 1204へ進む。
[0076] なおステップ S1202において、受信した SMILコンテンツがコンテンツプロバイダに より作成されたものであるかどうかを判別した力 既知のユーザ等（すなわち、 OMA SMILコンテンツを作成する可能性のある者）により作成されたものであるかどうか を判別してもよ 、。既知のユーザ等により作成されたものであれば (ステップ S1202： YES)、ステップ S1203では、受信した SMILコンテンツが OMA— SMILコンテンツ と判断され、 OMAカウンタが 1インクリメントされる。これらの metaタグに含まれる OM A— SMILコンテンツ或いは 3GPP— SMILコンテンツを示す既知の情報は予め携 帯電話機 10或!、は外部のサーバに登録されて!、る。 OMA— SMILコンテンツ或!ヽ は 3GPP— SMILコンテンツを示す情報を照合する際、まず携帯電話機 10に登録さ れている情報と照合し、対応する情報が無ければ外部サーバに問い合わせて照合 する。なお、 metaタグには、上記のコンテンツ作成者や送り手を特定するための情報 以外も含まれ得る。例えば 3GPP— SMILコンテンツ或いは OMA— SMILコンテン ッと判断可能な任意の情報が含まれ得る。また例えばレイアウトに関するコンテンツ 作成者からの指示情報 (例えばレイアウト変更可能か、或いは、禁止するかについて の情報)が含まれ得る。
[0077] ステップ S 1204では、 metaタグ以外のタグを判定する。 3GPP— SMILコンテンツ で定義されず OMA— SMILコンテンツでは定義されるタグが含まれているかどうか、 或いは、 regionタグの出現回数等を判定する。 regionタグの出現回数が 2回のみであ れば、 OMA— SMILコンテンツである可能性が高い。 regionタグの出現回数が 2回 であれば或いは OMA— SMILコンテンツのみで定義されて!、るタグがあれば (ステ ップ S 1204 : YES)、ステップ S 1205へ進む。 regionタグの出現回数が 2回でなく且 つ OMA— SMILコンテンツのみで定義されて!、るタグがなければ (ステップ S 1204： NO)、ステップ S 1206へ進む。ステップ S1205では、受信した SMILコンテンツが O MA— SMILコンテンツと判断され、 OMAカウンタが 1インクリメントされる。
[0078] なお、ステップ S1204において、タグから OMA— SMILコンテンツであることを判 断したが、 OMA— SMILコンテンツで定義されず 3GPP— SMILコンテンツでのみ 定義されるタグ或いは regionタグの出現回数が 2回でないこと等により 3GPP— SMI Lコンテンツかどうかを判断してもよい。 3GPP— SMILコンテンツであると推定されれ ば (ステップ S 1204 : YES)、ステップ S 1205では、受信した SMILコンテンツが 3GP P— SMILコンテンツと判断され、 3GPPカウンタが 1インクリメントされる。 [0079] ステップ S1206では、レイアウト処理が開始される。このレイアウト処理では、 3GPP カウンタ及び OMAカウンタのカウンタ値に基づいてレイアウト変更の可否が判定され る（ステップ S1207)。本実施形態において SMILレンダリングエンジン 410は、ステ ップ S 1207の判定処理で OMA— SMILコンテンツを優先するよう動作する。従って 3GPPカウンタ、 OMAカウンタの両カウンタ値が「0」（すなわちステップ S1102、 S1 104、 S1106 (図 22)、ステップ S1203、 SI 205【こお!ヽて全て「NO」半 I』定）、或!/ヽ【ま 、 OMAカウンタのカウンタ値力 「1」以上（すなわち何れかのステップで OMA— SMI Lコンテンツと半 IJ断）であるとき、受信コンテンツが OMA— SMILコンテンツであると 判定して（1207 : YES)、ステップ S 1208へ進む。
[0080] 一方で OMAカウンタのカウンタ値が「0」で且つ 3GPPカウンタのカウンタ値が「1」 以上であるとき、受信コンテンツが 3GPP— SMILコンテンツであると判定して (ステツ プ S 1207 : NO)、ステップ S 1209へ進む。
[0081] なおステップ S1207における優先度は段階的に設定できるようにしても良い。例え ば OMA— SMILコンテンツの優先度をより高く設定した場合、 OMAカウンタのカウ ンタ値が「0」であっても 3GPPカウンタのカウンタ値が「2」以上でな!、と、ステップ S1 207にお!/、て「YES」と判定（すなわち OMA— SMILコンテンツとして処理）されるよ うにしても良い。
[0082] ステップ S1208では、例えば携帯電話機 10の表示画面 (液晶ディスプレイ 111)に 合わせたレイアウト処理が行われる。また、第一乃至第五の実施形態の何れかと同 様のレイアウト処理が実行されても良い。
[0083] ステップ S 1209では、 layoutに指定されたとおりにレイアウト処理が行われる（この 場合、コンテンツがー画面中に収まらなければスクロール等により当該コンテンツ全 体を閲覧できる状態となる）。その後、ステップ S1210においてレイアウト処理が完了 し、 SMILレンダリングエンジン 410による本処理は終了する。
[0084] 例えばユーザの設定により、ステップ S1207において SMILレンダリングエンジン 4 10が 3GPP— SMILコンテンツを優先するよう動作させることもできる。この場合、 3G PPカウンタ、 OMAカウンタの両カウンタ値が「0」、或いは、 3GPPカウンタのカウンタ 値が「 1」以上であるとき、受信コンテンッが 3GPP - SMILコンテンッであると判定し て（ステップ SI 207 : NO)、ステップ SI 209へ進む。一方で 3GPPカウンタのカウンタ 値が「0」で且つ OMAカウンタのカウンタ値が「1」以上であるとき、受信コンテンツが OMA— SMILコンテンツであると判定して（ステップ S1207 :YES)、ステップ S120 8へ進む。
[0085] 上述のように、本発明では、受信した SMILコンテンツを OMA— SMILコンテンツ としてレンダリングすべき力 3GPP— SMILコンテンツとしてレンダリングすべきかの 判断を、以下の（1)〜（8)の条件を組み合わせて判断している。尚、図 22、図 23の フローチャートで説明した判断方法は一例であり、以下の（1)〜（8)のいずれかもしく は複数の組み合わせ方に限定はない。また、以下の（1)〜（8)のいずれ力もしくは複 数を用いて、 3GPP— SMILコンテンツと判断する、或いは、 OMA— SMILコンテン ッと判断するのであってもょ 、。
(1) DRM保護の有無
(2) SMILの metaタグの内容
(3) MMS header部の、送信者を特定する情報 (例えばメールアドレス、電話番号等
)
(4) MMS header部の拡張ヘッダの内容（或いは、通信プロトコルのヘッダ部の拡張 ヘッダの内容）
(5) regionタグの出現回数（OMA— SMILコンテンツの場合は 2回のみ）
(6) OMA— SMILコンテンツで定義されて!ヽな 、が、 3GPP - SMILコンテンツで 定義されて 、るタグが使用されて 、るかどうか
(7) OMA— SMILコンテンツで定義されて!ヽな 、が、 3GPP - SMILコンテンツで 定義されて ヽる属性が使用されて ヽるかどうか
(8) 3GPP— SMILコンテンツでは使われていないが、 OMA— SMILコンテンツで は定義されている属性もしくはタグを含むコンテンツかどうか
したがって、 MMSにより受信した SMILコンテンツを自動的に判定して再生するの で、ユーザはいずれのコンテンツであるか知らなくても、レイアウトを変更または不変 更として適切に再生することができる。
[0086] また、本発明の他の実施形態を以下に示す。図 24は、この実施形態によるメッセ一 ジングクライアント 500の機能を説明するための図である。メッセージングクライアント 500は、 MMSメッセージを送受信する機能を有するアプリケーションであり、 SMIL レンダリングエンジン 510を有している。メッセージングクライアント 500は、メッセージ 受信機能 (F11)と、 SMILコンテンツを解析する機能 (F12)と、フォルダを振り分け る機能（F13)とを有する。 SMILレンダリングエンジン 510は、レンダリングのための 機能である、 SMILバーサ（F14)と、 SMILレイァウタ（F 15)とを有する。
[0087] メッセージングクライアント 500は、受信した MMSメッセージ及び SMILコンテンツ を解析する (F12)。すなわち、上述の実施形態のように、（l) DRM保護の有無、 (2 ) SMILの metaタグの内容、（3) MMS header部の、送信者を特定する情報、 (4) MMS header部の拡張ヘッダの内容、（5) regionタグの出現回数、（6) OMA— SMILコン テンッで定義されて!、な!/、が 3GPP— SMILコンテンツで定義されて!、るタグが使用 されているかどう力、（7) OMA— SMILコンテンツで定義されていないが、 3GPP- SMILコンテンツで定義されている属性が使用されているかどうか、 (8) 3GPP-SM ILコンテンツでは使われて!/、な!/、が、 OMA— SMILコンテンツでは定義されて!、る 属性もしくはタグを含むコンテンツ力どうか、を判定する。その判定結果に応じて、 O MA— SMILコンテンツとみなされるものと 3GPP— SMILコンテンツとみなされるもの とをそれぞれ別々のフォルダに一時的に格納する（F13)。 SMILレンダリングェンジ ン 510は、 SMILコンテンツを取り出したフォルダの種類に応じてそれぞれ異なるレン ダリング処理を行う。
[0088] 図 25は、メッセージを受信して SMILコンテンツが表示されるまでの、メッセ一ジン グクライアント 500の処理動作を示すフローチャートである。ステップ S1301からステ ップ S1307までの処理は、メッセージングクライアント 400のステップ S1101からステ ップ S 1107までの処理（図 22)と同様であり、ステップ S 1308力らステップ S 1311ま での処理は、ステップ S1202からステップ 1205までの処理（図 22)と同様であるので 、説明は省略する。
[0089] ステップ S1312では、 3GPPカウンタ、 OMAカウンタの両カウンタ値が「0」、或い は、 OMAカウンタのカウンタ値力 「1」以上であるとき、受信コンテンツが OMA—SM ILコンテンッであると判定して、 OMA - SMILコンテンッ用のフォルダに当該受信コ ンテンッを一時的に格納する処理を行う。一方で OMAカウンタのカウンタ値が「0」で 且つ 3GPPカウンタのカウンタ値力 「1」以上であるとき、受信コンテンツが 3GPP— S MILコンテンッであると判定して、 3GPP - SMILコンテンッ用のフォルダに当該受 信コンテンツを一時的に格納する処理を行う。
[0090] ステップ S1313では、上述の 3GPP— SMILコンテンツ用或いは OMA— SMILコ ンテンッ用のフォルダに一時的に格納された SMILコンテンツを取り出してレンダリン グ処理を行う。その後、レンダリング結果に基づいて SMILコンテンツを表示画面に 表示し (ステップ S 1314)、本処理は終了となる。
[0091] なお、ステップ S1312におけるフォルダ振り分け処理は、 OMA— SMILコンテンツ 力 3GPP— SMILコンテンツのどちらを優先させるかをユーザが設定可能である。従 つて上記実施形態では OMA— SMILコンテンツを優先させた力 別の実施形態で は 3GPP— SMILコンテンツを優先させることもできる。この場合、例えば 3GPPカウ ンタ、 OMAカウンタの両カウンタ値が「0」、或いは、 3GPPカウンタのカウンタ値が「1 」以上であるとき、受信コンテンツが 3GPP— SMILコンテンツであると判定して、 3G PP SMILコンテンッ用のフォルダに当該受信コンテンッをー時的に格納する処理 を行う。一方で 3GPPカウンタのカウンタ値が「0」で且つ OMAカウンタのカウンタ値 力 S「l」以上であるとき、受信コンテンツが OMA— SMILコンテンツであると判定して、 OMA— SMILコンテンツ用のフォルダに当該受信コンテンツを一時的に格納する処 理を行う。
[0092] 図 26は、 SMILレンダリングエンジン 510による処理を示すフローチャートである。
本処理は、図 25におけるステップ S1313において実行される処理である。まず、入 力された SMILコンテンッが、 3GPP - SMILコンテンッ用のフォルダに格納されて いたものか OMA— SMILコンテンツ用のフォルダに格納されていたものかを判断す る（ステップ S1401)。 OMA— SMILコンテンツ用のフォルダに格納されていたもの であれば (ステップ S 1401： YES)、ステップ S 1402へ進む。ステップ S 1402では、 バーサによる処理が行われ、ドキュメントツリーが生成される。その後、ステップ S140 3では、レイアウト処理が開始され、 OMA— SMILコンテンツに準拠したレイアウト処 理が行われる (ステップ S 1404)。すなわち、表示画面に合わせたレイアウト処理が 行われる。レイアウト処理完了後 (ステップ S1405)、本処理は終了する。
[0093] 入力された SMILコンテンッが 3GPP— SMILコンテンッ用のフォルダに格納され ていたものであれば (ステップ S1401 :NO)、ステップ S1406に進む。ステップ S140 6から S 1407までの処理はステップ S 1402から S 1403までの処理と同様であるため 説明を省略する。ステップ S1408では、 3GPP— SMILコンテンツに準拠したレイァ ゥト処理が行われる。すなわち、 layoutで指定されたとおりのレイアウト処理が行われ る。レイアウト処理完了後（ステップ S1409)、本処理は終了する。
[0094] したがって、図 24から図 26に示した実施形態では、 SMILレンダリングエンジン 51 0に SMILが入力される前に（すなわち、受信時に）、 OMA— SMILコンテンツに準 拠してレンダリングされるべき力 3GPP— SMILコンテンツに準拠してレンダリングさ れるべきかが決定されるため、 SMILレンダリングエンジン 510内での判定を要しな い。また、図 25のフローチャートで説明した判断方法は一例であり、上述の（1)〜（8 )のいずれかもしくは複数の組み合わせ方に限定はない。また、上述の（1)〜（8)の いずれ力もしくは複数を用いて、 3GPP— SMILコンテンツと判断する、或いは、 OM A— SMILコンテンツと判断するのであってもよい。
[0095] なお、図 6 (または図 24)に示したメッセージングクライアント 400 (または 500)は、 必ずしも SMILレンダリングエンジン 410 (または 510)を有していなくてもよい。すな わち、 SMILレンダリングエンジン 410 (510)がメッセージングクライアント 400 (500) とは別のモジュールであってもよい。その場合、メッセージングクライアント 400 (500) 力 指示により、 SMILレンダリングエンジン 410 (510)を起動する構成であってもよ い。
[0096] 以上述べた 2つの実施形態は、図 6及び図 22、或いは図 24及び図 25に記載され たように、外部力も受信したマークアップランゲージで記述された複数のコンテンツが 、 SMILという同一のマークアップランゲージで記述されているという状況、同一のレ ンダリングエンジンを用いて解釈してレイアウトを行う状況、 MMSと!、う同一のメッセ 一ジング形式にて送信される状況、及び、同一のメッセージングクライアントにて受信 管理が行われるという状況に対して実現されるものである。従来、これらの状況下に お！、ては、 3GPP— SMILコンテンツのようにレイアウトを変更すべきでな!/、コンテン ッと、 OMA— SMILコンテンツのようにレイアウトを変更することが許容されたコンテ ンッとが、それぞれ混同されてしまい、適切なレイアウトが行われない可能性があった 。そこで、コンテンツに含まれる情報や解釈した結果に基づいて、レイアウトを変更す るべきでないコンテンツである力、或いは、場合によってはレイアウトを変更することが 許容されるコンテンツであるかを自動的に判断し、コンテンツに対し意図されたレイァ ゥトを適切に表示することを実現している。なお、レイアウトを変更することが許容され るマークアップランゲージコンテンツとレイアウトを変更すべきでないマークアップラン ゲージコンテンツとを判断すべき状況は上記に述べたものに限定されるものではない
[0097] また、上記の 2つの実施の形態にあるように、コンテンツに含まれる所定要素によつ て複数の仕様のうちのどれに準拠したコンテンツであるかを判断し、どの仕様に準拠 したコンテンツであるかに応じてレイアウト処理を行うことができる。また、具体的には 、受信した SMILコンテンッが OMA - SMILコンテンッに準拠したレンダリング処理 が行われるべき力、 3GPP— SMILコンテンツに準拠したレンダリング処理を行うべき 力 の判断を可能にし、 SMILコンテンツを適切なレンダリング方法にて表示させるこ とがでさる。
[0098] なお、上記の 2つの実施形態において、レイアウトを変更することが許容される SMI Lコンテンツとして OMA— SMILコンテンツに準拠したものを、レイアウトを変更しな いで表示されるべき SMILコンテンツとして 3GPP— SMILコンテンツに準拠したもの を例示して説明を行った力 3GPPや OMAにより標準化されているものに必ずしも 限定されるものではない。また、メーラとメッセージクライアントは一つのプログラムで あってもよい。
[0099] 以上説明したように、本発明によれば、文字情報の表示領域とイメージの表示領域 とがそれぞれ端末装置の表示画面にサイズや位置が指定されてレイアウトされるマ ークアップランゲージで記述されるコンテンツレンダリング方法にぉ 、て、各表示領域 の全ての内容を見えるようにすると共にコンテンツとしての見栄えをよくすることができ るレンダリング方法および端末装置を提供することができる。
[0100] また本発明によれば、受信したマークアップランゲージコンテンツに応じて適切にレ ィアウト処理を行うことができる。
[0101] なお、本発明の一つの実施形態において、解釈されたコンテンツが表示される表 示画面上における当該コンテンツの各要素の位置を決定する場合、該表示画面中 の領域であって、文字情報を表示させるべき文字情報表示領域と、イメージを表示さ せるべきイメージ表示領域の位置を各要素の位置として決定しても良 、。
[0102] また、本発明の一つの実施形態において、該決定された文字情報表示領域と、該 イメージ表示領域中に配置されるイメージとが重なり合うか否かを判定し、重なり合わ ないと判定したときには離隔する力否かを更に判定しても良い。
[0103] また、本発明の一つの実施形態において、イメージのサイズ、イメージの位置、ィメ ージ表示領域のサイズ、イメージ表示領域の位置、文字情報表示領域の位置、文字 情報表示領域のサイズ、イメージの表示方法、及び、文字情報の表示方法のうち、少 なくとも何れか一つについて所定の変更を行うことにより該コンテンツのレイアウト調 整を行っても良い。
[0104] また、本発明の一つの実施形態において、マークアップランゲージは、文字情報表 示領域とイメージ表示領域とを含む複数のスライドを時間軸上に配列するように記述 されたものであっても良い。
[0105] また、本発明の一つの実施形態において、イメージと文字情報表示領域との間に 隙間が生じると判断された場合に、隙間を埋めるようにしてイメージ或いは文字情報 表示領域を変更しても良い。或いは、イメージと文字情報表示領域との間に隙間が 生じると判断された場合に、文字情報表示領域をイメージに合わせてレイアウトを行う 、イメージを隙間に合わせて拡大を行う、ことのうち少なくともいずれか一方を行うこと により、隙間を埋めるようにしてイメージ或いは文字情報表示領域を変更しても良い。
[0106] また、本発明の一つの実施形態において、イメージと文字情報表示領域とに重なり が生じると判断された場合に、文字情報表示領域をイメージと重ならな!/、位置に移動 させ、文字情報表示領域のうち端末装置の表示画面の範囲外に配置された領域を、 ユーザの操作により表示できるようにしても良い。或いは、イメージと文字情報表示領 域とに重なりが生じると判断された場合に、文字情報表示領域をイメージと重ならな い位置に移動させ、文字情報表示領域のうち端末装置の表示画面の範囲内に配置 された領域に、文字情報の内容全てをマークアップランゲージコンテンツ内で指定さ れた所定時間内に表示させても良い。なお、所定時間は、スライドまたは文字情報表 示領域またはイメージ表示領域の表示時間のうちのいずれか一つと等しくすることが できる。また、文字情報の内容全てをマークアップランゲージコンテンツ内で指定され た時間内に表示させることは、文字情報の表示上の長さと、表示画面のうちの文字情 報表示領域のサイズと、所定時間とを考慮して算出される速度で文字情報の表示を 移動させることができる。
[0107] また、本発明の一つの実施形態において、イメージと文字情報表示領域とに重なり が生じると判断された場合に、文字情報表示領域をイメージの上に重なるように配置 させ、さらに文字情報表示領域の背景を透明にする。
[0108] また、本発明の一つの実施形態において、所定の変更の実行内容がユーザ'オペ レーシヨンにより設定可能であっても良い。或いは、所定の変更の実行内容を、マー クアップランゲージの所定のタグ内に記述された内容に従って決定するようにしても 良い。また、所定の変更を実行すべきかを、マークアップランゲージの所定のタグ内 に記述された内容により判断するようにしても良い。なお、所定のタグ内に、どのよう に所定の変更を行うかをユーザ選択に従って行うことを指示する内容を含めることが できる。
[0109] また、本発明の一つの実施形態において、表示画面に対する位置が決定されたィ メージ表示領域の横幅或 、は縦幅の 、ずれかが一致するようにイメージを拡大又は 縮小しても良い。
[0110] また、本発明の一つの実施形態において、マークアップランゲージで記述されたコ ンテンッは、ユーザ或いはコンテンツプロバイダにより作成されるメッセージとして端 末装置により送受信可能であっても良い。
[0111] また、本発明の一つの実施形態において、所定の条件は、マークアップランゲージ コンテンツがどの仕様書に準拠して作成されたコンテンツであるかを判断するための 条件であっても良い。
[0112] また、本発明の一つの実施形態において、所定の条件は、マークアップランゲージ コンテンツに対する DRM保護の指定の有無であり、マークアップランゲージコンテン ッに DRM保護が指定されていると判断した場合、レイアウトを変更しないで表示され るべきコンテンツであると判断されても良い。
[0113] また、本発明の一つの実施形態において、所定の条件は、マークアップランゲージ コンテンツ内の metaタグの内容に基づくものであっても良い。さらに、 metaタグの内容 は、コンテンツの提供者を特定することができる情報を含むものであっても良い。
[0114] また、本発明の一つの実施形態において、所定の条件は、マークアップランゲージ コンテンツが SMIL (Synchronization Multimedia Integration Language)であり SMIL が MMS (Multimedia Messaging Service)経由で受信されるときに当該マークアップラ ンゲージコンテンツを含んで 、る MMSメッセージにお 、て送信者を特定する情報に 基づくものであり、所定の情報が含まれている場合、レイアウトを変更しないで表示さ れるべきコンテンツであると判断されても良い。
[0115] また、本発明の一つの実施形態において、所定の条件は、マークアップランゲージ コンテンツが SMIL (Synchronization Multimedia Integration Language)であり SMIL が MMS (Multimedia Messaging Service)経由で受信されるときに当該マークアップラ ンゲージコンテンツを含んで 、る MMSメッセージある!/、は通信プロトコルにお!/ヽて機 能拡張のために定義されたヘッダに基づくものであっても良 、。
[0116] また、本発明の一つの実施形態において、所定の情報が、レイアウトを変更しない で表示されるべきコンテンツの提供者力どうかを特定する情報を含むものであっても 良い。

Claims

請求の範囲
[1] 所定のマークアップランゲージで記述されレイアウトが指定されたコンテンツをレン ダリングする方法において、
該コンテンツを解釈するコンテンツ解釈ステップと、
前記解釈ステップによる解釈結果に基づき、該コンテンツが表示される表示画面上 における当該コンテンツの各要素の位置を決定する位置決定ステップと、 該決定された位置において各要素が密接した状態に配列される力否かを判定する 配列判定ステップと、
前記配列判定ステップにお 、て密接した状態に並んで配列されな 、と判定された とき、各要素それぞれがユーザに視認可能となるように当該各要素のレイアウトを調 整するレイアウト調整ステップと、を含むレンダリング方法。
[2] 前記位置決定ステップが、該表示画面中の領域であって、文字情報を表示させる べき文字情報表示領域と、イメージを表示させるべきイメージ表示領域の位置を前記 各要素の位置として決定すること、を特徴とする請求項 1に記載のレンダリング方法。
[3] 前記配列判定ステップにお!、て、該決定された文字情報表示領域と、該イメージ表 示領域中に配置されるイメージとが重なり合うか否かが判定され、重なり合わないと判 定されたときには離隔する力否かを更に判定すること、を特徴とする請求項 2に記載 のレンダリング方法。
[4] 前記マークアップランゲージは、前記文字情報表示領域と前記イメージ表示領域と を含む複数のスライドを時間軸上に配列するように記述されて 、ることを特徴とする 請求項 2又は請求項 3の何れかに記載のレンダリング方法。
[5] 前記レイアウト調整ステップは、前記イメージのサイズ、前記イメージの位置、前記ィ メージ表示領域のサイズ、前記イメージ表示領域の位置、前記文字情報表示領域の 位置、前記文字情報表示領域のサイズ、前記イメージの表示方法、及び、前記文字 情報の表示方法のうち、少なくとも一つについて所定の変更を行うことにより該コンテ ンッのレイアウト調整を行うこと、を特徴とする請求項 2から請求項 4の何れかに記載 のレンダリング方法。
[6] 前記所定の変更は、前記イメージと前記文字情報表示領域との間に隙間が生じる と判断された場合に、前記隙間を埋めるようにして前記イメージ或いは前記文字情報 表示領域を変更することを特徴とする請求項 5に記載のレンダリング方法。
[7] 前記所定の変更は、前記イメージと前記文字情報表示領域との間に隙間が生じる と判断された場合に、前記文字情報表示領域を前記イメージに合わせてレイアウトを 行う、前記イメージを前記隙間に合わせて拡大を行う、ことのうち少なくともいずれか 一方を行うことにより、前記隙間を埋めるようにして前記イメージ或いは前記文字情報 表示領域を変更することを特徴とする請求項 5の何れかに記載のレンダリング方法。
[8] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージと重ならな！/ヽ位置に移動さ せ、前記文字情報表示領域のうち前記端末装置の表示画面の範囲外に配置された 領域を、ユーザの操作により表示可能とすることを特徴とする請求項 5に記載のレン ダリング方法。
[9] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージと重ならな！/ヽ位置に移動さ せ、前記文字情報表示領域のうち前記端末装置の表示画面の範囲内に配置された 領域に、前記文字情報の内容全てをマークアップランゲージコンテンツ内で指定さ れた所定時間内に表示させることを特徴とする請求項 5に記載のレンダリング方法。
[10] 前記所定時間は、前記スライドまたは前記文字情報表示領域または前記イメージ 表示領域の表示時間のうちのいずれか一つと等しいことを特徴とする請求項 9に記 載のレンダリング方法。
[11] 前記文字情報の内容全てをマークアップランゲージコンテンツ内で指定された時間 内に表示させることは、前記文字情報の表示上の長さと、前記表示画面のうちの前 記文字情報表示領域のサイズと、前記所定時間とを考慮して算出される速度で前記 文字情報の表示を移動させることを特徴とする請求項 9又は請求項 10の何れかに記 載のレンダリング方法。
[12] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージの上に重なるように配置さ せ、さらに前記文字情報表示領域の背景を透明にすることを特徴とする請求項 5に 記載のレンダリング方法。
[13] 前記所定の変更の実行内容がユーザ'オペレーションにより設定可能であることを 特徴とする請求項 5から請求項 12の何れかに記載のレンダリング方法。
[14] 前記所定の変更の実行内容を、前記マークアップランゲージの所定のタグ内に記 述された内容に従って決定することを特徴とする請求項 5から請求項 12の何れかに 記載のレンダリング方法。
[15] 前記所定の変更を実行すべきかを、前記マークアップランゲージの所定のタグ内に 記述された内容により判断することを特徴とする請求項 5から請求項 14の何れかに 記載のレンダリング方法。
[16] 前記所定のタグ内に、どのように前記所定の変更を行うかをユーザ選択に従って行 うことを指示する内容が含まれることを特徴とする請求項 15に記載のレンダリング方 法。
[17] 前記表示画面に対する位置が決定された前記イメージ表示領域の横幅或 ゝは縦 幅の ヽずれかが一致するように前記イメージを拡大又は縮小することを特徴とする請 求項 2から請求項 16の何れかに記載のレンダリング方法。
[18] 前記マークアップランゲージで記述されたコンテンツは、ユーザ或いはコンテンツプ ロバイダにより作成されるメッセージとして端末装置により送受信可能であることを特 徴とする請求項 1から請求項 17の何れかに記載のレンダリング方法。
[19] 所定のマークアップランゲージで記述されレイアウトが指定されたコンテンツを表示 画面上に表示可能な端末装置において、
該コンテンツを解釈するコンテンツ解釈手段と、
前記解釈手段による解釈結果に基づき、前記表示画面上における該コンテンツの 各要素の位置を決定する位置決定手段と、
該決定された位置において各要素が密接した状態に配列される力否かを判定する 配列判定手段と、
前記配列判定手段にお!ヽて密接した状態に配列されな!ヽと判定されたとき、各要 素それぞれがユーザに視認可能となるように当該各要素のレイアウトを調整するレイ アウト調整手段と、を具備したこと、を特徴とする端末装置。
[20] 前記位置決定手段は、該表示画面中の領域であって、文字情報を表示させるべき 文字情報表示領域と、イメージを表示させるべきイメージ表示領域の位置を前記各 要素の位置として決定すること、を特徴とする請求項 19に記載の端末装置。
[21] 前記配列判定手段は、該決定された文字情報表示領域と、該イメージ表示領域中 に配置されるイメージとが重なり合うか否かを判定し、重なり合わな 、と判定したとき には離隔する力否かを更に判定すること、を特徴とする請求項 20に記載の端末装置
[22] 前記マークアップランゲージは、前記文字情報表示領域と前記イメージ表示領域と を含む複数のスライドを時間軸上に配列するように記述されて 、ることを特徴とする 請求項 20又は請求項 21の何れかに記載の端末装置。
[23] 前記レイアウト調整手段は、前記イメージのサイズ、前記イメージの位置、前記ィメ ージ表示領域のサイズ、前記イメージ表示領域の位置、前記文字情報表示領域の 位置、前記文字情報表示領域のサイズ、前記イメージの表示方法、及び、前記文字 情報の表示方法のうち、少なくとも何れか一つについて所定の変更を行うことにより 該コンテンツのレイアウト調整を行うこと、を特徴とする請求項 20から請求項 22の何 れかに記載の端末装置。
[24] 前記所定の変更は、前記イメージと前記文字情報表示領域との間に隙間が生じる と判断された場合に、前記隙間を埋めるようにして前記イメージ或いは前記文字情報 表示領域を変更することを特徴とする請求項 23に記載の端末装置。
[25] 前記所定の変更は、前記イメージと前記文字情報表示領域との間に隙間が生じる と判断された場合に、前記文字情報表示領域を前記イメージに合わせてレイアウトを 行う、前記イメージを前記隙間に合わせて拡大を行う、ことのうち少なくともいずれか 一方を行うことにより、前記隙間を埋めるようにして前記イメージ或いは前記文字情報 表示領域を変更することを特徴とする請求項 23に記載の端末装置。
[26] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージと重ならな！/ヽ位置に移動さ せ、前記文字情報表示領域のうち前記端末装置の表示画面の範囲外に配置された 領域を、ユーザの操作により表示可能とすることを特徴とする請求項 23に記載の端 末装置。
[27] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージと重ならな！/ヽ位置に移動さ せ、前記文字情報表示領域のうち前記端末装置の表示画面の範囲内に配置された 領域に、前記文字情報の内容全てをマークアップランゲージコンテンツ内で指定さ れた所定時間内に表示させることを特徴とする請求項 23に記載の端末装置。
[28] 前記所定時間は、前記スライドまたは前記文字情報表示領域または前記イメージ 表示領域の表示時間のうちのいずれか一つと等しいことを特徴とする請求項 27に記 載の端末装置。
[29] 前記文字情報の内容全てをマークアップランゲージコンテンツ内で指定された時間 内に表示させることは、前記文字情報の表示上の長さと、前記表示画面のうちの前 記文字情報表示領域のサイズと、前記所定時間とを考慮して算出される速度で前記 文字情報の表示を移動させることを特徴とする請求項 27又は請求項 28の何れかに 記載の端末装置。
[30] 前記所定の変更は、前記イメージと前記文字情報表示領域とに重なりが生じると判 断された場合に、前記文字情報表示領域を前記イメージの上に重なるように配置さ せ、さらに前記文字情報表示領域の背景を透明にすることを特徴とする請求項 23に 記載の端末装置。
[31] 前記所定の変更の実行内容がユーザ'オペレーションにより設定可能であることを 特徴とする請求項 23から請求項 30の何れかに記載の端末装置。
[32] 前記所定の変更の実行内容を、前記マークアップランゲージの所定のタグ内に記 述された内容に従って決定することを特徴とする請求項 23から請求項 30の何れか に記載の端末装置。
[33] 前記所定の変更を実行すべきかを、前記マークアップランゲージの所定のタグ内に 記述された内容により判断することを特徴とする請求項 23から請求項 32の何れかに 記載の端末装置。
[34] 前記所定のタグ内に、どのように前記所定の変更を行うかをユーザ選択に従って行 うことを指示する内容が含まれることを特徴とする請求項 23に記載の端末装置。
[35] 前記表示画面に対する位置が決定された前記イメージ表示領域の横幅或 ゝは縦 幅の ヽずれかが一致するように前記イメージを拡大又は縮小することを特徴とする請 求項 20から請求項 34の何れかに記載の端末装置。
[36] 前記マークアップランゲージで記述されたコンテンツは、ユーザ或いはコンテンツプ ロバイダにより作成されるメッセージに含まれ、該メッセージを送受信可能であること を特徴とする請求項 20から請求項 35の何れかに記載の端末装置。
[37] 受信したマークアップランゲージコンテンツを解釈し、前記マークアップランゲージ コンテンツが所定の条件を満たす力否かにより、レイアウトを変更することが許容され るコンテンツである力、レイアウトを変更しないで表示されるべきコンテンツであるかを 判断し、その判断結果に応じてレイアウト処理を行うことを特徴とする請求項 1から請 求項 18の何れかに記載のレンダリング方法。
[38] 前記所定の条件は、前記マークアップランゲージコンテンツがどの仕様書に準拠し て作成されたコンテンツであるかを判断可能な条件であることを特徴とする請求項 37 に記載のレンダリング方法。
[39] 前記所定の条件は、前記マークアップランゲージコンテンツに対する DRM保護の 指定の有無であり、前記マークアップランゲージコンテンツに DRM保護が指定され て 、ると判断した場合、レイアウトを変更しな 、で表示されるべきコンテンツであると判 断することを特徴とする請求項 37又は請求項 38の何れかに記載のレンダリング方法
[40] 前記所定の条件は、前記マークアップランゲージコンテンツ内の metaタグの内容に 基づくものであることを特徴とする請求項 37又は請求項 38の何れかに記載のレンダ リング方法。
[41] 前記所定の条件は、前記マークアップランゲージコンテンツが SMIL (Synchronizati on Multimedia Integration Language)でめり目 ij ciSMIL^MMS (Multimedia Messagi ng Service)経由で受信されるときに当該マークアップランゲージコンテンッを含んで いる MMSメッセージにおいて送信者を特定する情報に基づくものであり、所定の情 報が含まれている場合、レイアウトを変更しないで表示されるべきコンテンツであると 判断することを特徴とする請求項 37又は請求項 38の何れかに記載のレンダリング方 法。
[42] 前記所定の条件は、マークアップランゲージコンテンツが SMIL (Synchronization Multimedia Integration Languageリであり目 ij dSMILか MMS (Multimedia Messaging Service)経由で受信されるときに当該マークアップランゲージコンテンッを含んで!/、る MMSメッセージあるいは通信プロトコルにおいて機能拡張のために定義されたへッ ダに基づくものであることを特徴とする請求項 37又は請求項 38の何れかに記載のレ ンダリング方法。
[43] 前記 metaタグの内容は、コンテンツの提供者を特定することができる情報を含むこ とを特徴とする請求項 40に記載のレンダリング方法。
[44] 前記所定の情報が、レイアウトを変更しないで表示されるべきコンテンツの提供者 力どうかを特定する情報を含むことを特徴とする請求項 41に記載のレンダリング方法
[45] 受信したマークアップランゲージコンテンツを解釈し、前記マークアップランゲージ コンテンツが所定の条件を満たす力否かにより、レイアウトを変更することが許容され るコンテンツであるかレイアウトを変更しないで表示されるべきコンテンツであるかを判 断し、その判断結果に応じてレイアウト処理を行うレンダリング手段を備える請求項 1
9から請求項 36の何れかに記載の端末装置。
[46] 前記所定の条件は、前記マークアップランゲージコンテンツがどの仕様書に準拠し て作成されたコンテンツであるかを判断するための条件であることを特徴とする請求 項 45に記載の端末装置。
[47] 前記所定の条件は、前記マークアップランゲージコンテンツに対する DRM保護の 指定の有無であり、前記マークアップランゲージコンテンツに DRM保護が指定され て 、ると判断した場合、レイアウトを変更しな 、で表示されるべきコンテンツであると判 断することを特徴とする請求項 45又は請求項 46の何れかに記載の端末装置。
[48] 前記所定の条件は、前記マークアップランゲージコンテンツ内の metaタグの内容に 基づくものであることを特徴とする請求項 45又は請求項 46の何れかに記載の端末 装置。
[49] 前記所定の条件は、前記マークアップランゲージコンテンツが SMIL (Synchronizati on Multimedia Integration Language)であり前記 SMILが MMS (Multimedia Messagi ng Service)経由で受信されるときに当該マークアップランゲージコンテンッを含んで いる MMSメッセージにおいて送信者を特定する情報に基づくものであり、所定の情 報が含まれている場合、レイアウトを変更しないで表示されるべきコンテンツであると 判断することを特徴とする請求項 45又は請求項 46に記載の端末装置。
[50] 前記所定の条件は、前記マークアップランゲージコンテンツが SMIL (Synchronizati on Multimedia Integration Language)でめり目 ij ciSMIL^MMS (Multimedia Messagi ng Service)経由で受信されるときに当該マークアップランゲージコンテンッを含んで いる MMSメッセージあるいは通信プロトコルにおいて機能拡張のために定義された ヘッダに基づくものであることを特徴とする請求項 45又は請求項 46に記載の端末装 置。
[51] 前記 metaタグの内容は、コンテンツの提供者を特定することができる情報を含むこ とを特徴とする請求項 48に記載の端末装置。
[52] 前記所定の情報が、レイアウトを変更しないで表示されるべきコンテンツの提供者 力どうかを特定する情報を含むことを特徴とする請求項 49に記載の端末装置。
[53] 請求項 1から請求項 18、請求項 37から請求項 44の何れかに記載のレンダリング方 法をコンピュータに実行させるためのプログラム。
PCT/JP2006/313553 2005-07-19 2006-07-07 コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを表示可能な端末装置 WO2007010756A1 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
JP2005208471 2005-07-19
JP2005-208471 2005-07-19
JP2005-219983 2005-07-29
JP2005219983 2005-07-29
JP2005-250908 2005-08-31
JP2005250908 2005-08-31

Publications (1)

Publication Number Publication Date
WO2007010756A1 true WO2007010756A1 (ja) 2007-01-25

Family

ID=37668638

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2006/313553 WO2007010756A1 (ja) 2005-07-19 2006-07-07 コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを表示可能な端末装置

Country Status (1)

Country Link
WO (1) WO2007010756A1 (ja)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10326169A (ja) * 1997-05-27 1998-12-08 Toshiba Corp 情報処理装置、表示制御方法及び表示制御プログラムを記録した記録媒体
JPH1186014A (ja) * 1997-09-08 1999-03-30 Fujitsu Ltd 文書画像表示方法および表示装置
JP2002351779A (ja) * 2001-05-22 2002-12-06 Minolta Co Ltd データ表示システム、データ送信装置、携帯端末、データ表示方法、データ表示プログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003030179A (ja) * 2001-07-13 2003-01-31 Murata Mach Ltd 構造化文書管理装置とそのプログラム
JP2004056469A (ja) * 2002-07-19 2004-02-19 Sony Corp 電子機器装置とそのメディア再生方法
JP2005156626A (ja) * 2003-11-20 2005-06-16 Matsushita Electric Ind Co Ltd スクロール処理付表示装置、記録媒体、コンピュータ読み取り可能なプログラム

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH10326169A (ja) * 1997-05-27 1998-12-08 Toshiba Corp 情報処理装置、表示制御方法及び表示制御プログラムを記録した記録媒体
JPH1186014A (ja) * 1997-09-08 1999-03-30 Fujitsu Ltd 文書画像表示方法および表示装置
JP2002351779A (ja) * 2001-05-22 2002-12-06 Minolta Co Ltd データ表示システム、データ送信装置、携帯端末、データ表示方法、データ表示プログラムおよびそのプログラムを記録したコンピュータ読み取り可能な記録媒体
JP2003030179A (ja) * 2001-07-13 2003-01-31 Murata Mach Ltd 構造化文書管理装置とそのプログラム
JP2004056469A (ja) * 2002-07-19 2004-02-19 Sony Corp 電子機器装置とそのメディア再生方法
JP2005156626A (ja) * 2003-11-20 2005-06-16 Matsushita Electric Ind Co Ltd スクロール処理付表示装置、記録媒体、コンピュータ読み取り可能なプログラム

Similar Documents

Publication Publication Date Title
KR100484181B1 (ko) 멀티미디어 문서 저작 장치 및 방법
US7466987B2 (en) User interface for a radiotelephone
EP1764985B1 (en) Mobile terminal for sending and receiving graphic contents associated to a text message and methods thereof
EP1653700B1 (en) Method for presenting multimedia messages
CA2723049C (en) Method of remotely controlling a presentation to freeze an image using a portable electronic device
EP1261180A2 (en) System for personal messaging
US20050136953A1 (en) User interface for creating multimedia message of mobile communication terminal and method thereof
US8935335B2 (en) Stationery for electronic messaging
KR20050083558A (ko) 텍스트 표시 단말 장치 및 서버
JP2010252345A (ja) 無線通信メッセージでピクチャを提供するためのシステムおよびプロトコル
EP2755409B1 (en) Multimedia message editing method and device
CN109120517B (zh) 一种富媒体消息的展现方法及装置
JP2008515259A (ja) 携帯電話を制御する方法
WO2015050966A1 (en) Image and message integration system and method
JP2001265688A (ja) 印刷出力制限方法、コンテンツサーバおよび通信端末
KR101467840B1 (ko) 이동통신 단말기의 사용자 데이터를 이용한 영상 제작시스템, 장치 및 방법
KR100806578B1 (ko) 이동통신 단말기의 멀티미디어 메시지 전송 방법
WO2007010756A1 (ja) コンテンツをレンダリングするための方法、プログラム、及び、コンテンツを表示可能な端末装置
JP2009271881A (ja) 移動式小型通信機器及びメールシステム並びにプログラム
KR100474305B1 (ko) 이동 통신 단말기의 멀티미디어 메시지 작성을 위한 사용자 인터페이스 방법
TWI244012B (en) Server and communication terminal device
WO2009066944A2 (en) Method and device for displaying of message
KR100619803B1 (ko) 이동 단말기의 대기화면 설정방법
JP2001051919A (ja) 電子メール処理装置、電子メール処理方法、電子メール処理プログラムを記録した記録媒体
JP4452678B2 (ja) コンテンツ管理方法及び移動通信端末装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06767963

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP