Title of Invention	A MOBILE TERMINAL, AND AN ASSOCIATED METHOD, WITH MEANS FOR MODIFYING A BEHAVIOUR PATTERN OF A MULTI-MEDIAL USER INTERFACE
Abstract	A mobile terminal (100, 200) having a multi-medial user interface (340), a controller (400) and a memory (352, 402) is presented. The memory is adapted to store a plurality of profiles (354), each profile defining a respective behavior pattern of said multi-medial user interface and being definable by a user of the mobile terminal. The controller is adapted to provide a first control parameter representative of a desired profile as selected by said user. The controller is also adapted to provide a second control parameter representative of a contextual status of said mobile terminal. The controller is adapted to modify a behavior pattern of said multi-medial user interface depending on said first and second control parameters.

Title of Invention

A MOBILE TERMINAL, AND AN ASSOCIATED METHOD, WITH MEANS FOR MODIFYING A BEHAVIOUR PATTERN OF A MULTI-MEDIAL USER INTERFACE

Abstract

A mobile terminal (100, 200) having a multi-medial user interface (340), a controller (400) and a memory (352, 402) is presented. The memory is adapted to store a plurality of profiles (354), each profile defining a respective behavior pattern of said multi-medial user interface and being definable by a user of the mobile terminal. The controller is adapted to provide a first control parameter representative of a desired profile as selected by said user. The controller is also adapted to provide a second control parameter representative of a contextual status of said mobile terminal. The controller is adapted to modify a behavior pattern of said multi-medial user interface depending on said first and second control parameters.

Full Text	A MOBILE TERMINAL, AND AN ASSOCIATED METHOD, WITH MEANS FOR MODIFYING A BEHAVIOR PATTERN OF -A MULTI-MEDIAL USER INTERFACE Field of the Invention The present invention relates to mobile telecommunication and more particularly to a mobile terminal having a multi-medial user interface and means for modifying a behavior pattern thereof. Background of the Invention A mobile (cellular) telephone for a telecommunications system like GSM, UMTS, D-AMPS or CDMA2000 is a common example of a mobile terminal according to the above. In recent years, mobile terminals have become a necessity in the everyday life of many people. The functionality of modern mobile terminals has expanded broadly, e.g. with the introduction of digital cameras and digital calendars in mobile telephones, thereby making mobile terminals attractive to persons who previously had no particular reason for using a mobile terminal. With the increased number of people using mobile terminals, personalization has become an important issue. Users may want to personalize'their mobile terminals for at least two different reasons. Firstly, having a heavy personalized mobile terminal in public areas such as locker rooms, conference halls, restaurants, etc, reduces the risk of confusing the user's terminal with someone else's terminal of the same brand and the same model. In order for a user to reduce the risk of mixing up his mobile terminal with other users' mobile terminals, the user must personalize the mobile terminal m some way. A second reason behind personalization is the well- known human need for expressing herself - i.e., the same need that byway of example-is—a~lso—appaxent--from- numerous car and motorcycle customizations, personalized muitimedial layout of personal computers, wearing designer clothes, tattoos, piercings, extravagant hair cuts, etc. One way of personalizing a mobile terminal is to change its casing. Today, it is possible to buy a specific model of a mobile telecommunications terminal and subsequently exchange the original casing for another casing of a d:fferent color or with a different surface pattern. Hence, to some extent, the mobile terminal will be personal.1 zed by the exchanged casing. However, the number of different exchange casings available for a specific model of a mobile terminal is often quite limited. Another approach to personalize a mobile terminal is to select one theme among a plurality of predefined themes in the mobile terminal. In many mobile terminals it is possible to simultaneously change a background image displayed on the terminal's display screen and the sounds used for indicating incoming telephone calls and messages (such as SMS, SMS, MMS etc) by selecting a particular theme. For example, selecting a "Christmas" theme may cause the display background to show a snowy Christmas landscape with Santa Claus and his reindeers, set the ringtone for incoming calls to "Jingle Bells" and set the alert signal for an SMS arrival to "Frosty the Snowman". In addition to the predefined themes stored in the mobile terminal, the user may also download further themes from a server on the Internet. WO 2004/057467 discloses a mobile terminal upgrading system in which content packages including themes may be downloaded in this way. A similar concept for personalization is the use of profiles. A profile is a set of settings that define the behavior of various functionality of the mobile terminal in a certain context. Thus, many mobile terminals have predefined and editable prof_ile_s__f o_r, e.g., handsf ree _ mode, silent mode, connected to PC, office, meeting and default (normal). The settings of each profile typically specify the behavior of the terminal's illumination (light), ring tone, keypad sound, warning tones, sound volume, vibration, call diversion, network availability, etc. EP-0 S65 188 discloses a mobile terminal with different profiles (which are referred to as "phone setting modes";. The user may define new profiles and edit existing ones, In EP-0 865 188, the personalization and the user convenience are extended by introducing automatic selection of which profile that is to be currently active in response to a current change in context. To this end, the mobile terminal in EP-0 865 188 has a plurality of detectors 12, 13, 14, 15, 16 each capable of supplying a control parameter representing the current context. A CPU and a controller in the mobile terminal receive the control parameters thus detected and searches a predefined table that matches control parameter values and profiles. In case of a match, the matching profile is automatically set as the active one. While the approach in EP-0 865 188 has its benefits, there is on the other hand a risk of inconvenience, since the user cannot interact in the continuous process for selection of active profile; this is entirely handled by the automaLie control process described above. Thus, the user may sometimes experience that his terminal switches profiles out of his control, e.g. too often or at unexpected occasions. There is a possibility for the user to select between automatic-mode profile selection and manual-mode profile selection (see mode selection box 27 in Fig 2),. but if manual mode is selected, the user is left with purely manual operation and all the benefits of the automatic control process are lost. It is therefore believed to be desirable to provide a new manner of personalization that combines the advantages of manual and automatic control to modify _a An embodiment 200 of the mobile terminal 100 is illustrated in slightly more detail in Fig 2. As is well known in the art, the mobile terminal 2 00 comprises an apparatus housing 201, a loudspeaker 2 02, a display 2 03, a set of keys 2 04 which may include a keypad of common ITU-T type (alpha-numerical keypad), and a microphone 205. In addition, but not shown in Fig 2, the mobile terminal 200 comprises various internal components, the more important of which are illustrated in Fig 4 and will be described larer. External components 202-205 are all part of the user interface of the mobile terminal. Furthermore, the user interface involves a multi-way input device 210 in the form of a joystick, the handle of which may be actuated by the user in a plurality of directions 212/214 so as to command navigating operations, i.e. to navigate in corresponding directions among information 2 0(5 shown on display 203, in a manner which is conventional per se for joystick-equipped mobile terminals. The navigation directions may be 4 in number, as indicated by solid arrows 212 in Fig 2a, and may be distributed orthogonally in an "up, down, left, right" or "north, south, west, east" fashion with respect to a base plane which is essentially coincidental or parallel with the display 2 03 and the front surface of apparatus housing 201. Alternatively, the navigation directions may be 8 in number, as indicated by dashed lines 214 together with solid arrows 212 in Fig 2a, and may be distributed around a virtual circle in aforesaid base plane with successive 4 5° displacements, representing corresponding actuations of the joystick handle by the user. The user may also perform a selecting operation among information 206 by actuating the joystick 210 in a direction perpendicular to the base plane, e.g. by depressing the joystick at its top. Depending on implementation, this will either cause displacement of the entire joystick handle, or will cause depression of a joystick .select, but_t_o_n_.__In_s_ome _embodiments sjac_h__a_jp^st_ic;Jc_select butter, nay be located at the top of the joystick handle; in others it may be mounted next to the joystick handle on the base plane. The internal component and software structure of a mobile terminal according to one embodiment will now be described with reference to Fig 4. The mobile terminal has a controller 4 00 which is responsible for the overall operation of the mobile terminal and is preferably implemented by any commercially available CPU ("Central Processing Ur.it"' T DSP ^"Digital Signal Processor") or any ether electronic programmable logic device. The controller 400 has associated electronic memory 402 such as RAM memory, ROM memory, EEPROM memory, flash memory, or any combination thereof. The memory 402 is used for various purposes by the controller 4 00, one of them being for storing data and program instructions for various software in the mobile terminal. The software includes a real-time operating system 42 0, man-machine interface (MMI) drivers 434, an application handler 432 as well as various applications 450-470. The applications may include a call handling application, a contacts (phonebook) application, a messaging application, a calendar application, a control panel application, a camera application, a mediaplayer, a video game, a notepad application, a WAP/WWW browser, etc. The MMI drivers 434 cooperate with the display 436 as well as various other I/O devices 438-439 such as a microphone, a speaker, a vibrator, a keypad, a joystick, a ringtone generator, an LED indicator, volume controls, etc. As is commonly known, a user may operate the mobile terminal through the man-machine interface thus formed. The software also includes various modules, protocol stacks, drivers, etc., which are commonly designated as 430 and which provide communication services (such as transport, network and connectivity) for an RF interface 406, and optionally a Bluetooth interface 408 and/or an IrDA interf ace_A10\_.„T_he ^RF__in_t_erf_ace_. _4.0_6, comprises __a.n_ internal or externa] antenna as well as appropriate radio circuitry for establishing and maintaining a wireless link to a base station (e.g. the link 102 and base station 104 in Fig 1 ;■ . As is well known to a man skilled in the art, the radio circuitry comprises a series of analog and digiral electronic components, together forming a radio receiver and transmitter. These components include, i.a., band pass filters, amplifiers, mixers, local oscillators, low pass filters, AD/DA converters , etc . The mob:le terminal also has a SIM card 404 and an associated reader. As is commonly known, the SIM card 404 comprises a processor as well as local work and data memory. Reference is now made to Fig 3. This drawing illustrates a software structure that provides dynamic and flexible raodif ica Lion of the behavior pattern of a multi-medial user interface 340 of the mobile terminal 100, 2 00. The software structure involves a Look & Feel Manager 350, a Context Monitor 330 and at least one application 310 among aforesaid software applications 450-470, In Fig 3, this application 310 is a Calendar application. The user interface 340 is multi-medial, i.e. it involves visual components (such as display screen backgrounds, screen savers, menu systems, buttons, dialog boxes, welcome message, etc) as well as audio components 'such as ring tones. alert signals, keypad sounds, etc) and tactile components (such as a vibrator signal). These various components are defined and represented by UI elements in a UI element store 342. The Look & Feel Manager 350 allows a user to create, edit and delete profiles at his will, i.e. it is a profile editor. Existing profiles 354 are stored in a profile store 352. Thus, each profile 354 will define a desired behavior pattern of the user interface 340, i.e. _lts-JLl.o.ok _and_f eel"., j_n a .given _context... _A_grqf ile _may__ Fig 5 .i liust rates in more detail the interaction between cli if ersnt ::of "ware components when a user defines a new profile in the Look & Feel Manager 350. The Lock & Feel Manager 350 is not the only place where the user may define the look and feel of his terminal, As seen in Fig 3, the user may create calendar events 312 for meetings, anniversaries , reminders, etc, in the Calendar application 310. When defining such a calendar event,- the user has the opportunity to specify Look & Feel attribute data 314. This attribute data may designate one of the available profiles 354, or a modified version of any of them, or generally any set of rules for the multi-medial behavior pattern of the user interface that are to be applied when the calendar event in question occurs. Thus, aforementioned "first control parameter" may also be represented by such Look & Feel attribute data 314 as specified by the user. One example of the above will be given later with reference to Fig 7. hi so other applications than Calendar may have Look 5 Feel attribute data specified as part of their application data. For instance, in a Bluetooth application a profile may be specified which is to be used when pairing a device. In a Chat application, different profiles may be used depending on whether or not particular remote users are attending. In a Presence application, different profiles may be linked to the presence or non-presence of a certain communication device in proximity of the mobile terminal (as detected e.g. by way of the Bluetooth ID of such communication device'. The Conrext Mori;) tor 330 serves to monitor for any context change, i.e. change in status for the mobile terminal, any of its applications or in its environment, that may trigger activation of any of the profiles 354. Therefore, Context Monitor 330 is susceptive of input data from a real-time clock 322, from a Location detector 324 and from th^^roximity__applicatipn_ 326. .In_this -way, -he Ccmext Monitor 330 -nay identify the current date and/or time, rhe current iocation of the mobile terminal (on the form of GPS information or a current cell/base station ID), and the current presence of other devices. The Context Monitor 330 is also susceptive of input from any and all application, such as the Calendar application 31C, which has application data 312 that includes Look £ Feel attribute data 314 as described above. In this way, the Context Monitor 330 will be informed of all relevant events in the applications that it monitors. Moreover, the Context Monitor 330 has access to the profiles 3't 4 rlence, 7. he Context Monitor 3 30 may regularly check ail available profiles to determine whether any of them has a defined usage context that matches the current context and thus should be activated. Any of the different inputs to the Context Monitor 33 0 may represent the "second control parameter", as mentioned in the Summary section. Whenever the Context Monitor 330 has determined that a change in context has occurred that calls for modification of the mobile terminal's multi-medial behavior pattern, the Context Monitor 330 will command the user interface 34C to perform the required modifications. Fig 6 illustrates in more detail how this is performed. A use case will now be described with reference to Fig 7. This use case will demonstrate an example of how profiles may be set both manually and automatically according to the invention. In step 700, at some moment in the past, the user has entered the Calendar application 310 (Fig 3) and created a calendar event 312 for a future meeting. In more detail, the calendar event contains a meeting specification 702 which, in a normal way, defines necessary data for the meeting, such as start time, end _t_ime, date, location, etc. In_ addition_,_ _the user_ specifies hock 6i Feel attribute data 314 by indicating a '^rtain xl r: -rneaiaJ behavior pattern that the user wants the mobile terminal to apply when the actual meeting occurs. As already explained, this may be defined in different ways; in Fig 7 it is assumed that the user selects an existing profile, Prof ile__14, among the available profiles 3 54 ♦ Profile_14 specifies that all personal data and applications are to be removed from display on the mobile terminal. Some time passes. Shortly before the start of the meeting on the designated date, in step 710 the user manually changes profile in the Look & Feel Manager 350 to Profile J2 [a predefined "Meeting" profile). The Look & Feel Manager 350 executes the selected profile immediately and commands the user interface 340 to adopt its multi-medial behavior pattern accordingly in step 712. This may involve actions like muting the ring signal, enabling the vibrator and applying call diversion. At the designated start time for the meeting, 14:00 on 27 December 2004, the Context Monitor 330 detects the occurrence of calendar event 702 in step 720. The Context Monitor 330 immediately proceeds to step 722 and executes the profile defined in the calendar event 702, i.e. Profile_14. The user interface 340 is accordingly commanded by Context. Monitor 330 to modify its multi-medial behavior pattern. As already mentioned, this involves hiding ail personal data and applications. All personal messages disappear from the Messaging application, the buddy lisr in the Char application is hidden, games are no longer available- Ln the menu system, personal bookmarks in the WAP/WWW browser are removed, etc. When the meeting ends, at 16:00, the Context Monitor 330 detects this in step 730 and restores, in step 732, all personal data and applications so that they again will be available to the user. Therefore, in effect, the Context Monitor 330 "undoes" all actions performed at the beginning^of the jneeting, and Profile_14 no longer applies - The manually set meeting profile ?rofiie_2, on rhe other hand, still applies, and the user will have to either select another profile or manually turn the ring signal back on, etc. The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims. 4,A mobile terminal as defined in claim 3, wherein said attribute data (314) of said another application [310] contains a representation of said first control parameter. 5. A mobile terminal as defined in claim 3 or 4, wherein said second control parameter is generated upon a change in context of said another application (310). 6. A mobile terminal as defined in claim 5, wherein said another application (310) is a Calendar application and saic change in context, pertains to the occurrence of a calendar event. 7. A mobile terminal as defined in any of claims 3-6, wherein the attribute data (314) of said another application (310) is definable by said user. 8. A mobile terminal as defined in any of claims 1-4, wherein said second control parameter is generated in response to at least one of the following: the occurrence of a predefined event in a software application '310, 450-470) of said mobile terminal; the presence of a communication device (112) in a proximity of said mobile terminal; an output from a real-time clock (322), such as a current time and/cr a current date; and location data pertaining to a current location of said mobile terminal, 9. A mobile terminal as defined in claim 8, wherein said communication device (112) is a Bluetooth device. 10. A mobile terminal as defined in claim 8 or 9, wherein said location data relates to at least one of the following: the occurrence of a predefined event in a software application : 310, 4 5 0-4 70) of said mobile terminal; the presence of a communication device (112) in a proximity of said mobile terminal; an output from, a real-time clock (322) , such as a current time and/or a current date; and location data pertaining to a current location of said mobile terminal.

Full Text

A MOBILE TERMINAL, AND AN ASSOCIATED METHOD, WITH MEANS FOR MODIFYING A BEHAVIOR PATTERN OF -A MULTI-MEDIAL USER
INTERFACE
Field of the Invention
The present invention relates to mobile telecommunication and more particularly to a mobile terminal having a multi-medial user interface and means for
modifying a behavior pattern thereof.
Background of the Invention
A mobile (cellular) telephone for a telecommunications system like GSM, UMTS, D-AMPS or CDMA2000 is a common example of a mobile terminal according to the above. In recent years, mobile terminals have become a necessity in the everyday life of many people. The functionality of modern mobile terminals has expanded broadly, e.g. with the introduction of digital cameras and digital calendars in mobile telephones, thereby making mobile terminals attractive to persons who previously had no particular reason for using a mobile terminal. With the increased number of people using mobile terminals, personalization has become an important issue. Users may want to personalize'their mobile terminals for at least two different reasons.
Firstly, having a heavy personalized mobile terminal in public areas such as locker rooms, conference halls, restaurants, etc, reduces the risk of confusing the user's terminal with someone else's terminal of the same brand and the same model. In order for a user to reduce the risk of mixing up his mobile terminal with other users' mobile terminals, the user must personalize the mobile terminal m some way.
A second reason behind personalization is the well-
known human need for expressing herself - i.e., the same
need that byway of example-is—a~lso—appaxent--from-

numerous car and motorcycle customizations, personalized muitimedial layout of personal computers, wearing designer clothes, tattoos, piercings, extravagant hair cuts, etc.
One way of personalizing a mobile terminal is to change its casing. Today, it is possible to buy a specific model of a mobile telecommunications terminal and subsequently exchange the original casing for another casing of a d:fferent color or with a different surface pattern. Hence, to some extent, the mobile terminal will be personal.1 zed by the exchanged casing. However, the number of different exchange casings available for a specific model of a mobile terminal is often quite limited.
Another approach to personalize a mobile terminal is to select one theme among a plurality of predefined themes in the mobile terminal. In many mobile terminals it is possible to simultaneously change a background image displayed on the terminal's display screen and the sounds used for indicating incoming telephone calls and messages (such as SMS, SMS, MMS etc) by selecting a particular theme. For example, selecting a "Christmas" theme may cause the display background to show a snowy Christmas landscape with Santa Claus and his reindeers, set the ringtone for incoming calls to "Jingle Bells" and set the alert signal for an SMS arrival to "Frosty the Snowman". In addition to the predefined themes stored in the mobile terminal, the user may also download further themes from a server on the Internet. WO 2004/057467 discloses a mobile terminal upgrading system in which content packages including themes may be downloaded in this way.
A similar concept for personalization is the use of
profiles. A profile is a set of settings that define the
behavior of various functionality of the mobile terminal
in a certain context. Thus, many mobile terminals have
predefined and editable prof_ile_s__f o_r, e.g., handsf ree _

mode, silent mode, connected to PC, office, meeting and default (normal). The settings of each profile typically specify the behavior of the terminal's illumination (light), ring tone, keypad sound, warning tones, sound volume, vibration, call diversion, network availability, etc.
EP-0 S65 188 discloses a mobile terminal with different profiles (which are referred to as "phone setting modes";. The user may define new profiles and edit existing ones, In EP-0 865 188, the personalization and the user convenience are extended by introducing automatic selection of which profile that is to be currently active in response to a current change in context. To this end, the mobile terminal in EP-0 865 188 has a plurality of detectors 12, 13, 14, 15, 16 each capable of supplying a control parameter representing the current context. A CPU and a controller in the mobile terminal receive the control parameters thus detected and searches a predefined table that matches control parameter values and profiles. In case of a match, the matching profile is automatically set as the active one.
While the approach in EP-0 865 188 has its benefits, there is on the other hand a risk of inconvenience, since the user cannot interact in the continuous process for selection of active profile; this is entirely handled by the automaLie control process described above. Thus, the user may sometimes experience that his terminal switches profiles out of his control, e.g. too often or at unexpected occasions. There is a possibility for the user to select between automatic-mode profile selection and manual-mode profile selection (see mode selection box 27 in Fig 2),. but if manual mode is selected, the user is left with purely manual operation and all the benefits of the automatic control process are lost.
It is therefore believed to be desirable to provide a new manner of personalization that combines the advantages of manual and automatic control to modify _a

An embodiment 200 of the mobile terminal 100 is illustrated in slightly more detail in Fig 2. As is well known in the art, the mobile terminal 2 00 comprises an apparatus housing 201, a loudspeaker 2 02, a display 2 03, a set of keys 2 04 which may include a keypad of common ITU-T type (alpha-numerical keypad), and a microphone 205. In addition, but not shown in Fig 2, the mobile terminal 200 comprises various internal components, the more important of which are illustrated in Fig 4 and will be described larer. External components 202-205 are all part of the user interface of the mobile terminal.
Furthermore, the user interface involves a multi-way input device 210 in the form of a joystick, the handle of which may be actuated by the user in a plurality of directions 212/214 so as to command navigating operations, i.e. to navigate in corresponding directions among information 2 0(5 shown on display 203, in a manner which is conventional per se for joystick-equipped mobile terminals. The navigation directions may be 4 in number, as indicated by solid arrows 212 in Fig 2a, and may be distributed orthogonally in an "up, down, left, right" or "north, south, west, east" fashion with respect to a base plane which is essentially coincidental or parallel with the display 2 03 and the front surface of apparatus housing 201. Alternatively, the navigation directions may be 8 in number, as indicated by dashed lines 214 together with solid arrows 212 in Fig 2a, and may be distributed around a virtual circle in aforesaid base plane with successive 4 5° displacements, representing corresponding actuations of the joystick handle by the user.
The user may also perform a selecting operation among information 206 by actuating the joystick 210 in a direction perpendicular to the base plane, e.g. by depressing the joystick at its top. Depending on implementation, this will either cause displacement of the entire joystick handle, or will cause depression of a joystick .select, but_t_o_n_.__In_s_ome _embodiments sjac_h__a_jp^st_ic;Jc_select

butter, nay be located at the top of the joystick handle; in others it may be mounted next to the joystick handle on the base plane.
The internal component and software structure of a mobile terminal according to one embodiment will now be described with reference to Fig 4. The mobile terminal has a controller 4 00 which is responsible for the overall operation of the mobile terminal and is preferably implemented by any commercially available CPU ("Central Processing Ur.it"' T DSP ^"Digital Signal Processor") or any ether electronic programmable logic device. The controller 400 has associated electronic memory 402 such as RAM memory, ROM memory, EEPROM memory, flash memory, or any combination thereof. The memory 402 is used for various purposes by the controller 4 00, one of them being for storing data and program instructions for various software in the mobile terminal. The software includes a real-time operating system 42 0, man-machine interface (MMI) drivers 434, an application handler 432 as well as various applications 450-470. The applications may include a call handling application, a contacts (phonebook) application, a messaging application, a calendar application, a control panel application, a camera application, a mediaplayer, a video game, a notepad application, a WAP/WWW browser, etc.
The MMI drivers 434 cooperate with the display 436 as well as various other I/O devices 438-439 such as a microphone, a speaker, a vibrator, a keypad, a joystick, a ringtone generator, an LED indicator, volume controls, etc. As is commonly known, a user may operate the mobile terminal through the man-machine interface thus formed.
The software also includes various modules, protocol stacks, drivers, etc., which are commonly designated as 430 and which provide communication services (such as transport, network and connectivity) for an RF interface 406, and optionally a Bluetooth interface 408 and/or an IrDA interf ace_A10\_.„T_he ^RF__in_t_erf_ace_. _4.0_6, comprises __a.n_

internal or externa] antenna as well as appropriate radio circuitry for establishing and maintaining a wireless link to a base station (e.g. the link 102 and base station 104 in Fig 1 ;■ . As is well known to a man skilled in the art, the radio circuitry comprises a series of analog and digiral electronic components, together forming a radio receiver and transmitter. These components include, i.a., band pass filters, amplifiers, mixers, local oscillators, low pass filters, AD/DA converters , etc .
The mob:le terminal also has a SIM card 404 and an associated reader. As is commonly known, the SIM card 404 comprises a processor as well as local work and data memory.
Reference is now made to Fig 3. This drawing illustrates a software structure that provides dynamic and flexible raodif ica Lion of the behavior pattern of a multi-medial user interface 340 of the mobile terminal 100, 2 00. The software structure involves a Look & Feel Manager 350, a Context Monitor 330 and at least one application 310 among aforesaid software applications 450-470, In Fig 3, this application 310 is a Calendar application.
The user interface 340 is multi-medial, i.e. it involves visual components (such as display screen backgrounds, screen savers, menu systems, buttons, dialog boxes, welcome message, etc) as well as audio components 'such as ring tones. alert signals, keypad sounds, etc) and tactile components (such as a vibrator signal). These various components are defined and represented by UI elements in a UI element store 342.
The Look & Feel Manager 350 allows a user to create, edit and delete profiles at his will, i.e. it is a profile editor. Existing profiles 354 are stored in a profile store 352. Thus, each profile 354 will define a desired behavior pattern of the user interface 340, i.e. _lts-JLl.o.ok _and_f eel"., j_n a .given _context... _A_grqf ile _may__

Fig 5 .i liust rates in more detail the interaction between cli if ersnt ::of "ware components when a user defines a new profile in the Look & Feel Manager 350.
The Lock & Feel Manager 350 is not the only place where the user may define the look and feel of his terminal, As seen in Fig 3, the user may create calendar events 312 for meetings, anniversaries , reminders, etc, in the Calendar application 310. When defining such a calendar event,- the user has the opportunity to specify Look & Feel attribute data 314. This attribute data may designate one of the available profiles 354, or a modified version of any of them, or generally any set of rules for the multi-medial behavior pattern of the user interface that are to be applied when the calendar event in question occurs. Thus, aforementioned "first control parameter" may also be represented by such Look & Feel attribute data 314 as specified by the user.
One example of the above will be given later with reference to Fig 7. hi so other applications than Calendar may have Look 5 Feel attribute data specified as part of their application data. For instance, in a Bluetooth application a profile may be specified which is to be used when pairing a device. In a Chat application, different profiles may be used depending on whether or not particular remote users are attending. In a Presence application, different profiles may be linked to the presence or non-presence of a certain communication device in proximity of the mobile terminal (as detected e.g. by way of the Bluetooth ID of such communication device'.
The Conrext Mori;) tor 330 serves to monitor for any context change, i.e. change in status for the mobile terminal, any of its applications or in its environment, that may trigger activation of any of the profiles 354. Therefore, Context Monitor 330 is susceptive of input data from a real-time clock 322, from a Location detector 324 and from th^^roximity__applicatipn_ 326. .In_this -way,

-he Ccmext Monitor 330 -nay identify the current date and/or time, rhe current iocation of the mobile terminal (on the form of GPS information or a current cell/base station ID), and the current presence of other devices.
The Context Monitor 330 is also susceptive of input from any and all application, such as the Calendar application 31C, which has application data 312 that includes Look £ Feel attribute data 314 as described above. In this way, the Context Monitor 330 will be informed of all relevant events in the applications that it monitors.
Moreover, the Context Monitor 330 has access to the profiles 3't 4 rlence, 7. he Context Monitor 3 30 may regularly check ail available profiles to determine whether any of them has a defined usage context that matches the current context and thus should be activated.
Any of the different inputs to the Context Monitor 33 0 may represent the "second control parameter", as mentioned in the Summary section.
Whenever the Context Monitor 330 has determined that a change in context has occurred that calls for modification of the mobile terminal's multi-medial behavior pattern, the Context Monitor 330 will command the user interface 34C to perform the required modifications. Fig 6 illustrates in more detail how this is performed.
A use case will now be described with reference to Fig 7. This use case will demonstrate an example of how profiles may be set both manually and automatically according to the invention.
In step 700, at some moment in the past, the user has entered the Calendar application 310 (Fig 3) and created a calendar event 312 for a future meeting. In more detail, the calendar event contains a meeting specification 702 which, in a normal way, defines necessary data for the meeting, such as start time, end _t_ime, date, location, etc. In_ addition_,_ _the user_

specifies hock 6i Feel attribute data 314 by indicating a '^rtain xl r: -rneaiaJ behavior pattern that the user wants the mobile terminal to apply when the actual meeting occurs. As already explained, this may be defined in different ways; in Fig 7 it is assumed that the user selects an existing profile, Prof ile__14, among the available profiles 3 54 ♦ Profile_14 specifies that all personal data and applications are to be removed from display on the mobile terminal.
Some time passes. Shortly before the start of the meeting on the designated date, in step 710 the user manually changes profile in the Look & Feel Manager 350 to Profile J2 [a predefined "Meeting" profile). The Look & Feel Manager 350 executes the selected profile immediately and commands the user interface 340 to adopt its multi-medial behavior pattern accordingly in step 712. This may involve actions like muting the ring signal, enabling the vibrator and applying call diversion.
At the designated start time for the meeting, 14:00 on 27 December 2004, the Context Monitor 330 detects the occurrence of calendar event 702 in step 720. The Context Monitor 330 immediately proceeds to step 722 and executes the profile defined in the calendar event 702, i.e. Profile_14. The user interface 340 is accordingly commanded by Context. Monitor 330 to modify its multi-medial behavior pattern. As already mentioned, this involves hiding ail personal data and applications. All personal messages disappear from the Messaging application, the buddy lisr in the Char application is hidden, games are no longer available- Ln the menu system, personal bookmarks in the WAP/WWW browser are removed, etc.
When the meeting ends, at 16:00, the Context Monitor 330 detects this in step 730 and restores, in step 732, all personal data and applications so that they again will be available to the user. Therefore, in effect, the Context Monitor 330 "undoes" all actions performed at the beginning^of the jneeting, and Profile_14

no longer applies - The manually set meeting profile ?rofiie_2, on rhe other hand, still applies, and the user will have to either select another profile or manually turn the ring signal back on, etc.
The invention has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the invention, as defined by the appended patent claims.

4,A mobile terminal as defined in claim 3, wherein said attribute data (314) of said another application [310] contains a representation of said first control parameter.
5. A mobile terminal as defined in claim 3 or 4, wherein said second control parameter is generated upon a change in context of said another application (310).
6. A mobile terminal as defined in claim 5, wherein said another application (310) is a Calendar application and saic change in context, pertains to the occurrence of a calendar event.
7. A mobile terminal as defined in any of claims 3-6, wherein the attribute data (314) of said another application (310) is definable by said user.
8. A mobile terminal as defined in any of claims 1-4, wherein said second control parameter is generated in response to at least one of the following:
the occurrence of a predefined event in a software application '310, 450-470) of said mobile terminal;
the presence of a communication device (112) in a proximity of said mobile terminal;
an output from a real-time clock (322), such as a current time and/cr a current date; and
location data pertaining to a current location of said mobile terminal,
9. A mobile terminal as defined in claim 8, wherein
said communication device (112) is a Bluetooth device.
10. A mobile terminal as defined in claim 8 or 9,
wherein said location data relates to at least one of the
following:

the occurrence of a predefined event in a software application : 310, 4 5 0-4 70) of said mobile terminal;
the presence of a communication device (112) in a proximity of said mobile terminal;
an output from, a real-time clock (322) , such as a current time and/or a current date; and
location data pertaining to a current location of said mobile terminal.

Documents:

http://ipindiaonline.gov.in/patentsearch/GrantedSearch/viewdoc.aspx?id=+6jQ301UvAG/d/nPOQpirA==&loc=egcICQiyoj82NGgGrC5ChA==

« Previous Patent

Next Patent »

Patent Number

269176

Indian Patent Application Number

2839/CHENP/2007

PG Journal Number

41/2015

Publication Date

09-Oct-2015

Grant Date

07-Oct-2015

Date of Filing

27-Jun-2007

Name of Patentee

NOKIA CORPORATION

Applicant Address

KEILALAHDENTIE 4, FI-02150 ESPOO, FINLAND

Inventors:

#	Inventor's Name	Inventor's Address
1	ANTTILA, AKSELI	PAJALADENTIE 6 B 25, FI-00200 HELSINKI, FINLAND
2	GRIGNANI, RAPHAEL	SANTAKATU 2 C 37, FI-00180 HELSINKI, FINLAND

PCT International Classification Number

H04M 1/725

PCT International Application Number

PCT/IB05/03772

PCT International Filing date

2005-12-14

PCT Conventions:

#	PCT Application Number	Date of Convention	Priority Country
1	11/023,129	2004-12-27	U.S.A.