(12) United States Patent
`Paatero et al.
`
`(io) Patent No.: US 7,093,198 Bl
`Aug. 15, 2006
`(45) Date of Patent:
`
`US007093198B1
`
`(54) SKINS FOR MOBILE COMMUNICATION
`DEVICES
`
`(75) Inventors: Lauri Paatero, Helsinki (FI); Christian
`Lindholm, Helsinki (FI)
`
`(73) Assignee: Nokia Corporation, Espoo (FI)
`
`( * ) Notice: Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 181 days.
`
`(21) Appl. No.: 09/930,484
`
`(22) Filed:
`
`Aug. 16, 2001
`
`(51)
`
`(56)
`
`Int. Cl.
`(2006.01)
`G06F 3/14
`(2006.01)
`G06F 3/00
`(52) U.S. Cl............................ 715/746; 715/762; 715/864
`(58) Field of Classification Search ................. 345/762,
`345/760, 864, 763, 967, 733, 744, 764, 778,
`345/747; 715/513,762,864; 709/219,328
`See application file for complete search history.
`References Cited
`U.S. PATENT DOCUMENTS
`1/2000 Bayeh et al...................... 709/246
`6,012,098 A *
`2/2000 Hill et al.......................... 715/513
`6,023,714 A *
`7/2000 Straub et al...................... 345/747
`6,091,411 A *
`8/2000 DeRose et al.................... 715/514
`6,101,511 A *
`6,130,933 A
`10/2000 Miloslavsky
`12/2000 King et al.
`6,161,114 A
`6,473,609 Bl 10/2002 Schwartz et al.
`6,477,549 Bl 11/2002 Hishida et al.
`1/2003 Yalcinalp ......................... 715/513
`6,507,857 Bl*
`6/2003 Namiki et al.................... 427/575
`6,582,778 Bl *
`6,636,175 Bl * 10/2003 Russell et al................. 342/357.1
`
`CN
`EP
`EP
`EP
`
`6,650,889 Bl* 11/2003 Evans et al..................... 455/418
`6,718,182 Bl * 4/2004 Kung .......................... 455/556.1
`FOREIGN PATENT DOCUMENTS
`1220427 A 6/1999
`0715246 Al * 6/1996
`0908832 A2 4/1999
`4/2001
`1091540
`OTHER PUBLICATIONS
`Topdesktop.com/skinl.htm, Feb. 27, 2001 (1 page).
`Shopping.altavista.com (netscape skins), Feb. 27, 2001 (p. 1).
`www.netscape.com/themes/, Feb. 27, 2001 (3 pages).
`www.nokia.com/phones/3310/index,html, Feb. 27, 2001 (1 page).
`www.nokia.com/phones/3310/index,html, Feb. 27, 2001 (p. 1).
`www.intertrust.com/main/metatrust/whatsdrm.html, Feb. 27, 2001
`(p. 1).
`AAP Releases E-book Standards, Paul Hilts, Dec. 4, 2000 (2 pages).
`Jan. 6, 2006, Office Action in corresponding Chinese application.
`* cited by examiner
`Primary Examiner—Kieu D. Vu
`(74) Attorney, Agent, or Firm—Banner & Witcoff Ltd.
`
`(57)
`
`ABSTRACT
`
`A skin is provided for the user interface of a mobile
`communication device. The skin is obtained by providing a
`data file including information defining characteristics of the
`skin, providing a markup language style sheet describing a
`manner in which data is to be represented on a display of the
`mobile communication device; transforming the data file
`into a markup language document according to the markup
`language style sheet, and providing the markup language
`document to an user interface application to represent the
`data on the display.
`
`65 Claims, 5 Drawing Sheets
`
`Netflix v. VideoLabs
`IPR2023-00628
`Netflix. Ex. 1013
`
`

`

`U.S. Patent
`U.S. Patent
`
`Aug. 15, 2006
`Aug. 15, 2006
`
`Sheet 1 of 5
`Sheet 1 of 5
`
`US 7,093,198 Bl
`
`
`
`6a
`
`

`

`U.S. Patent
`U.S. Patent
`
`Aug. 15, 2006
`Aug. 15, 2006
`
`Sheet2 of 5
`Sheet 2 of 5
`
`US 7,093,198 Bl
`US 7,093,198 B1
`
`RAM
`ifa
`
`FLASH ROM
`i7b
`
`
`
`TRANSMITTER/
`RECEIVER
`CIRCUIT
`19
`
`F | G ° 2
`
`PROCESSOR
`18
`
`AUDIO
`
`PART
`
`14
`
`SIM CARD
`16
`LCD DRIVER
`13
`13
`KEYBOARD
`2
`
`NAVIGATION AND
`T
`
`SELEC i KEYS
`
`3
`3
`
`SPEAKER
`2
`
`MICROPHONE
`6a
`
`BUZZER
`6b
`
`

`

`U.S. Patent
`
`Aug. 15, 2006
`
`Sheet 3 of 5
`
`US 7,093,198 Bl
`
`OPERATING SYSTEM 80
`APPLICATION 81
`
`Ul
`
`81.1
`
`VAS
`
`81.2
`
`VOICE
`RECORDER BROWSER
`
`COMMUNICATIONS MANAGER 82
`
`SERVER 83
`
`Ul
`SMN
`No.1
`83.1
`
`Ul
`Sts {KT
`No.k
`B3.k
`
`ID
`CONTROL
`
`83.(k+1)
`
`NETWORK
`CONTROL
`
`8?.m
`
`COWTflOL
`Sin
`
`SUBSYSTEMS 84
`
`GSM
`SW
`
`84 1
`
`SIM
`
`84.2
`
`ENERGY
`MANAGEMENT
`
`84p
`
`HW DRIVERS 85
`
`HW RESOURCES 86
`
`AUDIO
`
`• · *
`
`SIM
`
`8*671
`
`ID
`UNIT
`
`20
`
`DIS­
`PLAY
`
`3
`
`KEY­
`BOARD
`
`2
`
`FI6-. 3
`
`

`

`U.S. Patent
`
`Aug. 15, 2006
`
`Sheet 4 of 5
`
`US 7,093,198 Bl
`
`F16-.4
`
`APPLICATION
`SERVER
`104
`
`101-6
`
`OS SERVICE API
`
`

`

`U.S. Patent
`U.S. Patent
`
`Aug. 15, 2006
`Aug. 15, 2006
`
`Sheet 5 of 5
`Sheet 5 of 5
`
`US 7,093,198 Bl
`US 7,093,198 B1
`
`FAG 5 10,
`
`

`

`1
`SKINS FOR MOBILE COMMUNICATION
`DEVICES
`
`BACKGROUND
`
`1. Field of the Invention
`The present invention relates generally to user interfaces
`in mobile communication devices. Particular aspects of the
`invention relate to methods of providing skins for the user
`interface of a mobile communication device.
`2. Discussion of the Related Art
`With some software written for desktop and laptop com­
`puters, various aspects and features of the user interface,
`such as graphical elements, icons, animations, colors, tex­
`ture, fonts, sounds, etc., can be easily changed all at the same
`time. The changes can be accomplished using data files
`referred to as “skins”, which can be easily downloaded from
`the Internet and installed without altering the functionality
`of the software. Skins are available for the Netscape 6 web
`browser at www.netscape.com, and for the Windows oper­
`ating system software and various applications software at
`www.topdesktop.com. Most of the skins are available for
`free. Even for a skin that is only available for a fee, there is
`nothing to prevent the skin from being copied and forwarded
`or distributed to others without payment to the party origi­
`nally providing the skin. This inhibits the development of an
`effective commercial market for skins.
`The circumstances for customization or personalization
`are quite different in the field of mobile communications
`devices, such as cellular phones, personal digital assistants
`(PDAs), web pads, pagers, cordless telephones, handheld
`computers, etc. Customization of the user interface is limited
`to ringing tones, screen savers and simple logos, usually
`determined by a user profile maintained by the operator of
`the wireless communication network which the device
`accesses for communications, and/or exchangeable covers
`and keypads for the housing of the device such as described
`in EP 1091540.
`Mobile communications devices have been growing rap­
`idly in computing power and can now perform many func­
`tions in addition to voice telephony (such as a phonebook,
`personal organizer, etc). In particular, they are capable of
`requesting, receiving and displaying information consisting
`of alphanumeric text or graphics. An example of alphanu­
`meric text is a short message service (SMS) in GSM, which
`permits the user to send and receive short text messages
`transmitted through a cellular public land mobile network
`(PLMN). More recently, mobile communications devices
`have been developed which allow the user to access docu­
`ments or graphics data from the Internet or elsewhere using
`the Wireless Application Protocol (WAP) over wireless
`communication networks.
`WAP enabled devices allow information to be accessed
`from various remote servers offering data services such as
`banking, stock quotes, and weather forecasts. Data content
`is provided in a markup language, such as wireless markup
`language (WML) or extensible hypertext markup language
`(XHTML). WML is configured to allow data to be displayed
`as a deck of individual cards which are of a size suited for
`display on the relatively small display screen typical. A
`micro-browser software application is typically provided in
`the mobile communication device to receive the data and
`display it in different screens. The user interface of the
`mobile communication device provides some way for the
`user to navigate between different display screens.
`Since mobile communications devices typically use dis­
`plays of relatively small size and/or resolution, the degree of
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,093,198 Bl
`
`2
`user satisfaction depends greatly on the ability to display
`data in a manner preferred by the user. Since mobile
`communication devices are typically battery powered, they
`generally use black and white displays rather than color
`displays which consume more power. This creates also a
`disadvantage insofar as color cannot be used to enhance the
`user interface.
`Because of the relatively fixed architecture of mobile
`communications devices, a user cannot install or change
`software and there are no skins or other possibilities for the
`user of a mobile communications device to alter the display
`of information as there are in the field of desktop or laptop
`computers. Customization of the user interface according to
`user preference is limited to ringing tones, screen savers,
`logos and the use of exchangeable covers for the housing of
`the device, such as described in EP 1091540.
`
`BRIEF SUMMARY
`
`The present invention addresses mobile communications
`devices, software applications and micro-browsers thereof
`which are disadvantageous for at least the reasons recog­
`nized above. There are several different aspects to the
`invention, some of which may be practiced without the
`others.
`One aspect of the present invention is directed to a method
`of allowing graphical elements of a screen display of a
`mobile communication device to have animations, colors,
`texture and fonts changed in order to match them to current
`trends or to the color and texture of the phone. In particular,
`the invention is directed to a method of providing skins for
`mobile communication devices so that the graphical ele­
`ments of the display can be changed as easily as they are in
`a desktop or laptop computer.
`In another aspect of the invention, a copy protection
`scheme is provided for the skins of mobile communication
`devices. This enables an economically sustainable market
`for their creation and distribution and a payment system so
`that a user of a mobile communications device can easily
`arrange for payment when a new skin is installed on this
`device.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`is an illustration of an exemplary mobile phone to
`FIG. 1
`which an embodiment may be applied.
`is a diagram illustrating the major elements in an
`FIG. 2
`example of the hardware architecture of the mobile phone
`illustrated in FIG. 1.
`is a block diagram illustrating an example of the
`FIG. 3
`software architecture of the mobile phone illustrated in FIG.
`1, including elements useful in providing skins in a first
`operating system embodiment.
`FIG. 4 is a block diagram illustrating the mobile phone in
`a wireless communication network, and the major elements
`of an exemplary browser.
`FIG. 5 shows various elements in a server and in a
`browser equipped mobile phone for providing skins to the
`mobile phone according to a second browser embodiment.
`
`DETAILED DESCRIPTION
`
`While the foregoing and following written and illustrated
`disclosure focuses on disclosing several embodiments, it
`should be clearly understood that the same is by way of
`illustration and example only and is not to be taken by way
`of limitation. The embodiments are described with respect to
`
`

`

`3
`a cellular phone. However, they may be practiced with
`respect to any type of mobile communication device.
`The phone preferably contains software including a set of
`software components that enables it to communicate with a
`wireless communication network, various software applica­
`tions and a set of application programming interfaces (APIs)
`so that software components and applications can work
`together on the mobile device. In particular, the software
`includes a browser for the World Wide Web that enables it
`to render a display on a screen as described below. However,
`the invention however is not limited to such a set of software
`modules or APIS, to implementation in a particular wireless
`communication network or to particular specifications, such
`as Wireless Access Protocol (WAP).
`Mobile Phone
`FIG. 1 shows an example of a mobile phone to which an
`embodiment may be applied. The phone, which is generally
`designated by 10, comprises a keypad 2, a liquid crystal
`display 3, an on/oif button 4, a speaker 5 (only openings are
`shown in FIG. 1) and/or ear-piece (not shown), a micro­
`phone 6a (only the opening is shown in FIG. 1) and a
`transducer 6b. Liquid crystal display (LCD) 3 is preferably
`formed integrally within mobile phone 10. The keypad 2 has
`a first group 7 of keys as alphanumeric keys, by means of
`which the user can enter a telephone number, write a text
`message (SMS), write a name (associated with the phone
`number), etc. Each of the twelve alphanumeric keys 7 is
`provided with a FIGS.“0-9” or a sign “#” or respec­
`tively. In alpha mode, each key is associated with a number
`of letters and special signs and can be used to select
`characters, for example, to produce and edit short SMS text
`messages. The selected key is pressed successively rela­
`tively quickly to change the character selected by the key
`between the characters marked on the key concerned, with
`each successive key operation. When the desired character is
`displayed, the user waits and a timeout occurs with the result
`that the displayed character becomes the selected character.
`The keypad 2 additionally comprises two soft keys 8
`adjacent the underside of LCD 3, two call handling keys 9,
`a navigation key 15 for navigating the cursor in display 3, a
`key 17 for switching between numbers and letters for the
`twelve alphanumeric keys in the first group 7 of keys, and
`a “clear key” 16 for clearing one or more letters from the
`display. The two soft keys 8 preferably comprise manually
`depressible buttons. Their functionality can be pre-pro­
`grammed depending upon the task performed. The function­
`ality of the two soft keys 8 depends on the state of the phone
`and navigation through display 3 using navigation key 15.
`The functionality attributed to the two soft keys 8 is dis­
`played as soft key function legends in separate fields in the
`display 3 just above the respective soft keys 8. The two call
`handling keys 9 according to the preferred embodiment are
`used for establishing a call or a conference call, terminating
`a call or rejecting an incoming call.
`The navigation key 15 is an up/down key placed centrally
`on the front surface of the phone between the display 3 and
`the group of alphanumeric keys 7. When pushed upwardly,
`it scrolls up. Conversely, when pushed downwardly, it
`scrolls down. In use, an active or focus region is provided on
`the display which, as explained in more detail later, can be
`modified. The focus region may be delineated by a rectan­
`gular box which is moved around the display. It can be
`provided in different ways, such as a region highlighted with
`a different intensity or color from the rest of the display, an
`underlining of a menu option or by means of a pointer
`movable across the display in the manner of a conventional
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,093,198 Bl
`
`4
`mouse pointer. Hereby the user will be able to control this
`key by simply pressing the up/down key using their thumb.
`Since many experienced phone users are used to one-hand
`control, it is a very good solution to place an input key,
`requiring precise motor movements. Thus, the user may
`place the phone in the hand between the finger tips and the
`palm of the hand. Hereby, the thumb is free for inputting
`information.
`Navigation key 15 may comprise a three-way roller which
`is manually depressible inwardly of the handset, in the
`direction of arrow 26, to perform a “select” function. Alter­
`natively, it may be configured as a five-way roller (not
`shown) so as to perform additional right and left scrolling
`functions, a roller ball, a pivot device to scroll for LCD3, a
`touch pad or other navigation device of the type used in
`laptop computers.
`Mobile Phone Hardware Architecture
`FIG. 2 is a block diagram of the major parts of possible
`hardware architecture for mobile phone 10. It should be
`understood that FIG. 2 is an example and that mobile phone
`10 invention is not limited to such a hardware architecture.
`Mobile phone 10 has a transmitter/receiver circuit 19,
`which is preferably a standardized transceiver adapted to
`operate according to cellular standards, connected to a
`processor unit 18 and communicatively connecting it to a
`cellular communication network (not shown). The phone is
`preferably adapted for communication via a wireless com­
`munication network, e.g., a cellular network, but it may also
`be adapted for a cordless network. For example, it may be
`adapted for use in connection with a GSM network, CDMA
`network, TDMA network, or other kinds of cellular net­
`works and various forms of cordless phone systems or in
`dual band phones or tri-mode phones accessing sets of these
`systems/networks. Although not shown in FIG. 2, mobile
`phone 10 may also have a standard infrared (ir) or Bluetooth
`wireless port enabling it to directly receive data from
`another device via a wireless connection.
`Speech signals received through transmitter/receiver cir­
`cuit 19 are A/D converted in an A/D converter (not shown),
`fed to audio part 14 (preferably a codec configured to
`process signals under the control of processor unit 18) and
`encoded so as to produce analog signals fed to speaker 5
`(and/or an ear-piece) through an amplifier (not shown).
`Audio part 14 receives analog signals from microphone 6a,
`after being amplified by an amplifier (not shown) and A/D
`converted in an A/D converter (not shown), encodes and
`transfers the encoded signals to processor unit 18 for trans­
`mission through transmitter/receiver circuit 19. The audio
`part 14 also decodes the signal, which is transferred from the
`processor unit 18 to the earpiece 5 via a D/A converter and
`amplifier (not shown).
`Audio part 14 is also able to give an output of a ring tone
`to the buzzer 6b. The ring tone can be stored in either of the
`memories 17α, b, and is recalled when the transmitter/re­
`ceiver circuit 19 receives an incoming signal, by means of
`the processor unit 18. Thus, the ring tone is recalled from the
`memory, forwarded to audio part 14, and the ring tone is
`generated as an output from the buzzer 6b.
`Processor unit 18 is connected to, and has an interface
`associated with, random access memory (RAM) 17α and to
`Flash ROM 17Λ. Other memory (including ROM) may also
`be provided, either separate from or integrated with RAM
`17α. It is also connected to a power supply, such as a battery.
`Processor unit 18 also has an interface with a smart card,
`preferably SIM card 16 containing mobile subscriber iden­
`tity and removably received in a SIM card holder (not
`
`

`

`5
`shown), a display driver 13 connected to LCD 3, and keypad
`2. It receives instruction signals from keypad 2 and soft keys
`8 and controls LCD 3.
`There may be an input/output (I/O) unit (not shown)
`configured for any or all of the parts connected to processor
`unit 18. During operation, the processor unit 18 monitors the
`activity in the phone and controls the display 3 in response
`thereto. Therefore, it is the processor unit 18 which detects
`the occurrence of a state change event and changes the state
`of the phone and thus the display text. A state change event
`can be caused by the user activating the keypad, including
`navigation key 15, and these types of events are called entry
`events or user events. However, the network communicating
`with the phone may also cause a state change event. This
`type of event and other events beyond the user’s control are
`called non-user events. Non-user events comprise status
`change during call set-up, change in battery voltage, change
`in antenna conditions, message on reception of SMS, etc.
`Mobile Phone Software Architecture
`Processor unit 18 also supports software in the phone. A
`variety of software applications, including software mod­
`ules, are stored in Flash ROM 17Λ (or other persistent
`storage of mobile phone 10, but are not shown in FIG. 2 for
`the sake of convenience. The software can be ported to and
`integrated into mobile phone 10 at or near the time of
`manufacture or by the operator of a wireless communication
`network having appropriate facilities, but the user does not
`necessarily have the same rights to install the software as the
`manufacturer or the operator.
`Mobile phone 10 can have any software architecture, but
`the example known as Intelligent Software Architecture
`(ISA) is shown in FIG. 3. Operating system 80 has a
`communication manager 82 controller by processor unit 18.
`Communication manager 82 handles the communication
`between a number of software applications 81 and a number
`of servers 83. Software applications 81.1 to 81.» and servers
`83.1 to 83.m communicate under control of the communi­
`cation manager 82. Software applications 81.1-81.» use the
`services from the servers 83 to build features, and to present
`the features to the user via the user interface panels.
`The server 83 controls a resource and provides an inter­
`face that allows other entities to access the controlled
`resource. Each server 83 controls, for example the user
`interface setting, the audio, etc., but only accesses the
`resource when requested via communication manager 82. A
`server may use services provided by one or more other
`servers as part of its own services, but the server does not
`present information to the user via the user interface panels.
`A subsystem 84 is an autonomous part of the software,
`with a special service interface to the other subsystems.
`Subsystems 84 may include a number of subsystems
`84.1-84./2, such as GSM software 84.1, SIM software 84.2
`and energy management 84.//. The hardware drivers 85 are
`the interface to the hardware resources shown in FIG. 2.
`Operating System Embodiment
`As shown in FIG. 3, there may be a plurality of UI skin
`servers 83.1-83./:. Although one or more of UI skin servers
`83.1-83./: may be included when the mobile phone 10 is
`manufactured, it is preferable that at least the data file(s)
`associated with a skin can be downloaded from a server in
`or communicating with a wireless communication network
`through transmitter/receiver circuit 19 and under control of
`processor unit 18. Furthermore, the user of mobile phone 10
`is preferably also able to arrange for payment of such a
`downloaded skin data file in a method interacting with and
`supported by the data skin file downloading server.
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,093,198 Bl
`
`6
`One or more of UI skin servers 83.1-83./: may contain a
`copy-forbidding flag in the skin data to prevent subsequent
`copying of the associated skin to other devices. Alterna­
`tively, copy protection can be provided by a separate digital
`rights management (DRM) server 83.». This DRM server
`83.» can be implemented for a specific software application,
`such as a web browser as described later, or it may be
`implemented as an extension to operation system software
`80 with an API to provide communication access to a
`plurality of different software applications. In the latter
`operating system embodiment, DRM server 83.» provides
`DRM support for skin type personalization for all software
`applications having an API interface to DRM server 83.».
`Also, implementation of DRM as an extension in operating
`system software 80 allows full use of all security mecha­
`nisms otherwise provided by operating system software 80.
`In this way a common skin can be provided for a plurality
`of software applications, thus resulting in a theme for the
`user across all applications similar to that presently possible
`in desktop computer systems.
`Browser Embodiment
`Although an implementation using operating system soft­
`ware 80 is possible, an implementation in a specific software
`application, such as web browser 81.0 shown in FIG. 3, can
`be more self-contained and simple. In such an embodiment,
`the digital rights management can be included in and spe­
`cially adapted for the particular software application. This is
`advantageous for a web browser application which provides
`for the easy transfer of data back and forth, such as to and
`from the Internet, which allows for easy distribution of
`unauthorized copies.
`Designed to closely model the World-Wide Web archi­
`tecture, specifications of, for example, the standard naming
`model, content typing, content formats, protocols, etc., have
`been developed for a general-purpose application environ­
`ment for wireless mobile communication devices having
`limited CPU speeds, memory battery life, display size, and
`a wide variety of input devices. WAP is a set of specifica­
`tions, promulgated by the WAP Forum (www.wapforu-
`m.org), which defines the interfaces between mobile com­
`munication devices and wired Internet devices.
`FIG. 4 illustrates a browser equipped mobile phone 10
`(preferably conforming to the specification provided by the
`WAP Forum) within a wireless network infrastructure 100.
`Connections from mobile phone 10 to WAP server 102 are
`arranged through a bearer service of wireless network 100.
`The WAP protocol defines a set of bearer services such as
`Short Message Service (SMS) and High Speed Circuit
`Switched Data (HSCSD). The WAP content may originate in
`WAP server 102 or may reside on Web Server 103 or
`Application Server 104, in which case WAP server 102
`functions as a gateway to Web Server 103 and Application
`Server 104. Connections between WAP Server 102 and Web
`Server 103 and Application Server 104 are made through the
`Internet or an intranet 105 or other TCP/IP network, usually
`with HyperText Transfer Protocol (HTTP) messaging.
`The Wireless Application Environment (WAE) model of
`WAP is based on the WWW client-server model and
`includes all elements of the WAP architecture related to
`application specification and execution. It specifies an appli­
`cation framework for wireless mobile communication
`devices with the goal of enabling network operators, device
`manufacturers, and content developers to develop differen­
`tiating services and applications in a fast and flexible man­
`ner. Specifically, the WAE application framework specifies
`networking schemes, content formats, programming lan­
`
`

`

`7
`guages, and shared services. Software components 101-1 to
`101-5 in mobile phone 10 correspond to elements specified
`in the WAE application framework. The Operating System
`(OS) Service Application Programming Interface (API)
`101-6 (drawn to the left) of software components 101-1 to
`101-5 allows the components to interact with the operating
`system of mobile phone 10. WAE does not specify any
`particular user agent, but only specifies the services and
`formats required to ensure interoperability among the vari­
`ous possible implementations of WAP. Furthermore, it
`assumes an environment in which one or more user agents
`providing a specific functionality may operate simulta­
`neously.
`The software modules consist of various components
`corresponding generally to User Agent Layer 101-2, Trans­
`port Layer (Loader Layer) 101-3, Wireless Application
`Protocol Stack 101-4 and OS Service API 101-6 in FIG. 4.
`The software modules preferably allow mobile phone 10 to
`browse WML content, XML content, XHTML content and
`other types of content, execute WMLScript, receive and
`display Push messages, and receive and display Wireless
`Bitmap (WBMP) graphics. The browser may support vari­
`ous combinations of markup language standards.
`For the second browser embodiment now described, it is
`preferable that the browser supports at least XML and XSL
`style sheets. The XML specification is preferable because it
`separates content and data presentation. The skins are pref­
`erably created in XML by using one or more style sheets to
`adapt the skin to function to display data on LCD 3 of mobile
`phone 10. Additionally, the skin may be adapted to be best
`suited for a certain phone or type of mobile communication
`device (including type of display capabilities, such as size
`and resolution, as well as certain type of user navigation and
`control, such as navigation and select keys 15, a touch
`sensitive display, etc.).
`FIG. 5 illustrates a method of providing a final XSL
`document representing a skin for a user interface of a mobile
`communication device from a server 20 or other device on
`the network side of a wireless communication network
`communicating with the mobile communication device. The
`original skin data file is one of a set of XML files 21
`available at server 20. When the user of mobile phone 10
`contacts server 20, the server 20 can obtain, for example,
`mobile subscriber information and information indicating
`the type of mobile phone 10 or mobile communication
`device to be used in the session (typical information is type
`of display with pixel resolution, display size, colored or
`non-colored, etc.). The information may be obtained from
`the mobile phone or may be part of a user profile maintained
`at the server. The appropriate XSL style sheet 23 is chosen
`using the information, and the user selected skin is trans­
`formed in a XML Style Language Transformation (XSLT)
`22 to, for example, a XML (or WML) skin data file for
`mobile phone 10. When a user contacts server 20 to obtain
`a skin, server 20 may utilize the information, particularly the
`information indicating the type of mobile phone or mobile
`communication device, to present and offer for user selec­
`tion only those skins which are most suitable for that type of
`mobile phone or mobile communication device. For
`example, a skin may depend greatly on color (which should
`not be used on phones with black and white displays) or on
`a display having enough resolution or size for the user
`interface area or on some animation sections (a blinking eye
`for example), which may not be supported by all mobile
`phones. Preferably, server 20 permits the user to view how
`the skin looks on their particular mobile communication
`device before purchase thereof. If the user indicates that the
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 7,093,198 Bl
`
`8
`skin is satisfactory, the user may initiate a procedure to buy
`the skin and, as result of the purchase, a download procedure
`is initiated whereby the skin is downloaded to the mobile
`communication device.
`The XSL style sheet 23 can be located in the mobile
`phone, but it or other types of style sheets may be located at
`server 20. If a device dependent style sheet is located in
`mobile phone 10, then the final XSL transformation 24 is
`performed by mobile phone 10. At mobile phone 10, the
`XML parser 11 in browser 81.0 applies the processor of the
`terminal to translate the XML (or WML) format document
`of the user interface skin data file in a manner suitable for the
`user interface application 12. Alternatively, parsing can be
`performed in server 20 to make the skin ready on the
`network side to be used by the user interface of mobile
`phone 10 as soon as the skin is received without any
`processing.
`Instead of transmitting an XML document from server 20
`to mobile phone 10, alternative files include, but are not
`limited to, WML, HTML or metadata. As an example, the
`metadata may be compatible or backward compatible with
`the specifications for the Resource Description Framework
`(RDF) promulgated by the World Wide Web Consortium
`(W3C). (See http://www.W3.orq/TR/REC-rdf-svntax for
`model & syntax and http://www.w3.org/TR/CR-rdf-schema-
`20000327 for schema.) RDF provides for the use of multiple
`identification and identification references within a single
`document, the establishment of naming and linking conven­
`tions and definitions for the interpretation of attributes. RDF
`thus makes it possible to provide different metadata for
`different applications. It enables, for example, classification
`of a browser’s pages. In the context of providing skins to a
`mobile communication device, the user interface of a soft­
`ware application may have particular obligatory syntax
`sections for which metadata vocabulary rules can be defined.
`For example, the skin may have a Uniform Resource Loca­
`tor (URL) to a site, such as Club Nokia, in certain points
`therein. This may be used in conjunction with DRM control
`83.W, where DRM control 83./? does not permit a copy of a
`skin to be kept when the user obtains a different mobile
`phone or mobile communication device. For example, a skin
`created as an RDF document may require that, after contact
`is made to a URL address and there is payment of usage
`and/or other DRM rights, the skin is then translated to be
`ready for a software application and it’s the user interface
`from then on.
`An important aspect of the embodiments is to be able to
`provide DRM protected skins to mobile communication
`devices. For example, a skin can be sold so that it can be
`installed on any type of mobile phone or mobile communi­
`cati