Voice and text group caht display management techniques for wireless mobile terminals

Method and system to visualize group chat sessions in mobile wireless terminals.

TECHNICAL FIELD The present invention generally relates to wireless communication systems incorporating voice and text input and output modes, and in particular an improved technique for textually presenting real-time conversations (eg chat chains) in the elements of display of mobile units.

BACKGROUND OF THE INVENTION Text chat systems, and to a lesser degree of voice, are generally known in the art, particularly in relation to personal computer systems. Published US Patent Applications No. 2001/0042095 A1; 2001/0011293 A1; and 2002/0023128 and U.S. Patent No. 6,212,548 and 6,286,034 illustrate exemplary systems of user interfaces used today. A common feature of such systems is that the various conversations (or chains) are normally divided into different regions (or windows) in the display or screen element. In addition, when a single chain comprises a plurality of both text and voice exchange, such systems normally separate the two modalities: the voice is normally played on a speaker, while the plurality of text messages are displayed on the screen. Users have no means to reference old voice messages or distinguish when they have occurred in the chain in relation to other messages in the chain.

US Patent Application No. 2002/0023128 A1 (& quot; Publication ´128 & quot;) describes a system in which the screen area is divided into six different windows. One window presents a chat history of a chain (the chain in question) while another window presents a chat history of the combined plurality of remaining chains. A chat history comprises a plurality of entries presented or displayed on the screen that describe both incoming chat messages (ie, received by the user's mobile terminal) and outgoing chat messages (ie sent by the user's mobile terminal) . Entries are usually presented or displayed on the screen in chronological order and usually only describe text messages. Document US6081830 discloses a computer with a chat application connected to a computer chat room through a server.

Although the chat systems described above meet the needs of some users of chat groups, they are mainly concentrated on large screens such as those found on personal computers. The regions visible on the screen are dedicated to the particular functionality. Such interfaces do not adapt well to devices where the presentation or display area is small. In such small screen devices, such as mobile devices, dedicating a region exclusively for text entries or other ephemeral functionality consumes a precious screen area.

Such schemes do not allow the device to take full advantage of the available display or display area when ephemeral functionality (for example, editing a new message) is not in use.

Common practices on mobile devices nowadays normally move the user through a series of scenes. For example, when it is time to edit a message, conventional practice on limited screen devices is to move the user from a chat history screen that occupies the entire display or display region of the screen content to an editing screen. text, which also occupies the display or display region of the screen. Such schemes do not allow the user to see a chat story as it progresses in real time while the user composes the message. When there is an incoming message, the user must move back to the history screen to see if the message that is currently being composed is still relevant given the context of received messages. A user interface that addresses such matters increases the desire and comfort of participating in a chat session. Therefore, there is a need to improve a chat message delivery system that has an improved user interface in mobile units, which allows simultaneous presentation or display of chat channels and the composition and / or editing of messages from demand response, taking into account the limitations of mobile devices.

SUMMARY OF THE INVENTION It is an advantage of the present invention to provide improved methods and systems for managing both the wireless single-mode (ie, voice or text) and multimodal (ie voice and text combined) chat services.

It is a further advantage of the present invention to provide a mobile terminal interface that allows a user to view a chat session as it occurs in real time, while at the same time allowing the user to compose a message in response to messages from chat that are being displayed at that time.

According to an embodiment of the present invention, a wireless system allows chat-based communications between mobile terminals. Each of the mobile terminals includes a presentation screen or

visualization capable of presenting message text, graphic user interface and other information. At least some of the terminals run a chat client application that provides chat services on power networks wireless The mobile terminals that run the chat client are able to present a conversation of chat that is updated at or near real time so that the messages in the conversation progressively move on the screen. In addition, the chat client allows a mobile terminal to present a text editing area on a part of your screen while concurrently displaying the conversation of in another part of the screen. A text editor resident in the mobile terminal allows a user to compose a message in the text editing area while simultaneously watching the conversation progress. He Composite message can be a response to the conversation that is being presented at that time. A Once the act of composing and sending the message is completed, the chat client allows the mobile terminal Remove the text editing area and expand the chat history area to occupy the area of ​​the released screen.

Other systems, methods, features and advantages of the invention will be apparent to those skilled in the art. After examining the following figures and the following description. It is intended that all such systems Additional, methods, features are included in this description, are within the scope of the invention and are protected by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS The components of the figures are not necessarily to scale, being placed instead of to emphasize, to illustrate the principles of the invention. In the Figures, the same reference numbers designate parts corresponding in the different views.

Fig. 1 is a schematic illustration of a wireless mobile terminal usable in a chat system of according to an embodiment of the present invention. Fig. 2 is a block diagram of a wireless communication system that supports services of chat according to a further embodiment of the present invention. Fig. 3 is a block diagram of communication chat components included in the system of the Fig. 2. Fig. 4 it is a schematic illustration of an outgoing text message usable in the system of Fig.

two. Fig. 5 is a schematic illustration of an incoming text message usable in the system of Fig. 2. Fig. 6 is a schematic illustration of a friend list update message usable in the system of Fig. 2. Fig. 7 is a table illustrating the data contained in the presence manager shown in Fig. 2. Fig. 8 is a table that illustrates the data contained in the nickname manager (or "nickname") shown in Fig. 2. Fig. 9 show a presentation or display of friends list, which presents a list of nicknames by way of example in alphabetical order. Fig. 10 shows a presentation or display of friends list, which presents a list of example nicknames in group order. Fig. 11 is a schematic illustration of a presentation or visualization of chat history. Fig. 12 is a schematic illustration of a title bar for the presentation or display of Chat story when voice is recorded. Fig. 13 is a schematic illustration of a presentation or detailed view display of a single communication message as an example. Fig. 14 is a schematic illustration of a text message editor. Fig. fifteen it is a block diagram of a wireless communication system that has been extended to Integrate legacy mobile terminals. Figs. 16-17 show a combination of presentation or display of chat history / text editor according to a preferred embodiment of the present invention.

DETAILED DESCRIPTION OF THE CURRENTLY PREFERRED EMBODIMENT The embodiment can be fully described with reference to Figs. 1-17. Fig. 1 illustrates a wireless mobile terminal 100 that can comprise any wireless communication device such as a handheld cell phone or an enabled Personal Digital Assistant (PDA). The configuration of the mobile terminal 100 shown in Fig. 1 It is only by way of example, and it is generally understood that a wide variety of terminals and terminal configurations could be used. As shown, the mobile terminal 100 comprises a loudspeaker 103, for interpreting signals, such as the received voice, audible; and a display element or screen 102 for displaying visible text and graphic elements; a navigation button 105 that allows the user to move in a list or menu presented or displayed on the screen; programmable buttons (or "function keys") 104; a keyboard 106 that allows the user to enter numbers, letters and other symbols (eg punctuation); a microphone 107 that captures audio such as the user's voice; and a push-to-talk button 101 that allows the user to start recording and transmitting the audio. These and other components of the mobile terminal (not shown) are well known in the art and need not be described here in greater detail. Additionally, there are a variety of styles and examples of components that can be used instead of (or in combination with) the components described in Fig. 1. For example, the push-to-talk button 101 can be omitted and replaced by mechanisms Automatic voice detection. Touch screens and handwriting recognition techniques can replace the need for function key 104, navigation button 105 and keyboard 106. The present invention is not limited to this aspect. Additional terminal components that are not necessarily visible to the user but are necessary to implement the chat functionality, are further described with reference to Fig. 3. The input devices available in the wireless mobile terminal (for example keyboard, function keys, etc.) can be used by the user of the wireless mobile terminal to start a chat software session and, within the operation of the chat software, Start one or more chat conversations (chains) as described in more detail below.

Fig. 2 illustrates the overall system architecture of a wireless communication system comprising a plurality of mobile terminals 100 in accordance with an embodiment of the present invention. The terminals 100 communicate with at least one chat server complex 20 4 wirelessly transmitting data to a corresponding wireless carrier infrastructure 202. As is known in the art, wireless carrier infrastructures 202 comprise those elements necessary to support wireless communications with terminals 100. Several service providers (such as Verizon or Spirit in the United States, or Orange in Europe) build and maintain such infrastructures The data packets are sent to a communication network 203 that sends them to the server complex 204. The communication network 203, which is a packet-based network, may comprise a public network such as the Internet or Word Wide Web, a private network such as a corporate intranet, or some combination of public or private network elements. The server complex 204 preferably comprises a plurality of network server computers that may be programmed to implement the functionality described below. The particular number of servers used and the way they communicate with each other is a matter of design choice. Techniques for programming server computers and mobile terminals with well known in the art.

When the server complex 204 communicates with one or more mobile terminals, the server complex 204 sends its data to the network 203 which, in turn, sends the data in at least one of the bearer infrastructures 202. Each relevant bearer infrastructure 202 then transmits the data to one or more of its corresponding mobile terminals 100. Preferably when a plurality of users chat together (ie, they send messages from one terminal 100 to another), the data comprising text, voice and / or graphic messages (or some combination thereof) are sent to the server complex 204. The server complex 204 when sending message copies outside the target terminals 100, preferably including, in one embodiment, the initiation or sending terminal.

The server complex 204 may be placed within a bearer infrastructure 202, or that may be removed in cases where direct terminal to terminal transfer is supported. In the latter case, substantially all chat message sending functionality is supported by mobile terminals. In addition, the present invention would benefit systems other than systems based on data packets, as well as systems that are limited to a single wireless carrier domain.

In the preferred embodiment at least one chat server complex 204 resides outside the bearer domain. As such, it is enabled for service to a plurality of mobile terminals 100 that may be associated with a plurality of wireless carriers. Indeed, the systems exposed here are independent of wireless operators. They do not require that any special hardware or software be placed within the wireless operator network 202. The wireless operator network (in combination with a public network 203) acts as a communication conduit between the mobile terminal 100 and the server complex 204. Preferably, standard packet data transfer protocols are used to transmit and route data messages from one side to another between the mobile terminal 100 and the server complex 204, such as the Internet Protocol (IP), Control Protocol of Transmission (TCP), User Datagram Protocol (UDP) and Word Wide Web Protocol, such as Hypertext Transfer Protocol (HTTP). The server complex 204 acts as a gateway between the different transfer protocols. Each plurality of mobile terminals 100 establishes a connection with each chat server complex 204 using a suitable transfer protocol. The massages flow from the mobile terminal 100 to the server complex 204 over at least one protocol. The server complex 204 copies the message content and broadcasts it to other intended mobile terminals 100 using the appropriate transfer protocol suitable for each of the target mobile terminals 100.

Fig. 3 illustrates in more detail the components found in both terminals 100 and the server complex 204 used to exchange voice chat messages and group text. Focusing on the components of terminal 100, readable and executable machine instructions (typically referred to as software, code, or program) are preferred stored in an application storage (or memory) 310 and executed (or processed) in a central processing unit (CPU) 211. All of the storage devices described herein may comprise any combination of volatile (e.g., random access memory) or non-volatile (e.g., read-only memory) storage as is known in the art. Similarly, the CPU 211 may comprise a microprocessor, microcontroller, digital signal processor, coprocessor, similar devices or combinations thereof. Using known programming techniques, the software can manipulate the presentation or display 102, capture the voice from the microphone 107, capture the input data from the keyboard 106, navigation button 101 using the I / O controller 312. The outgoing chat messages sent to the server complex 204, as well as the incoming chat messages received from the server complex, pass through the network interface 306 that provides connectivity between the terminal and the data network. When the terminal 100 comprises a wireless device, the network interface 306 comprises all the physical interface necessary to communicate with the server complex 204, including the wireless transceiver. Preferably, but not necessarily, the voice sent to the server complex 204 is first encoded using a voice codec 307, which may be implemented in a software, but which is preferably implemented using a combination of hardware and software components. Similarly, the voice from the server complex 204 may, when necessary, be decoded using the voice codec 307 before it is sent to the speaker 103. The software uses temporary storage 309 to save work data that does not persist between software initiations (sessions). On the other hand, the software uses permanent storage 305 for data that persists for long periods of time that may span multiple software sessions.

Focusing on the components of server complex 204, data traffic comprising encoded voice and text messages (eg outgoing chat messages 400; see Fig. 4) flows to server complex 204 preferably through router 301. Note that router 301, presence manager 302, message diffuser 303 and nickname manager 304 may be implemented in one or more server complexes or the like that reside within server complex 204. Router 301 directs the message outgoing chat 400 to a message diffuser 303 that determines the plurality of incoming chat message copies (eg incoming chat messages 500, see Fig. 5) and their destinations. In the context of the present disclosure, the term incoming refers to messages addressed to one or more mobile terminals, while the outgoing term refers to messages sent by mobile terminals. Message diffuser 303 decomposes incoming messages 400 and locates the list of recipient identifiers 402. Then ask a presence manager 302 to set the current status of the recipient 702 (i.e. an indicator of whether the recipient is ready to receive the particular type of message, only voice and / or text messages, etc.) and the terminal address 703. Fig. 7 illustrates a table with the plurality of presence data records 700 contained in the presence manager 303. Each presence register 700 of presence 700 comprises the user identifier 701, the current state 702, the current terminal address 703 (if known) a public presentation or display identifier, such as a public nickname 704 and a public abbreviation 705 , and a plurality of other user identifiers 706 that subscribe to the user's presence information corresponding to that record. Public presentation or display identifiers or set of public nicknames 704-705 are used in incoming chat messages 500 sent to terminal 100 unless the recipient (i.e., the receiving user) overrides the public nickname set 704- 705 with private presentation or display identifiers or set of 802-803 private nicknames. When presence status 702 changes, presence manager 302 sends a friend list update message 600 to all subscribers listed in the subscriber identifier field 706 of the corresponding presence register 700. Presence records 700 may contain other information and attributes such as shipping addresses, processing rules that describe what to do in various circumstances, graphic representation for various states, profiles (that is, a plurality of different sets of values ​​that you can use. at different times depending on the receiver, etc.) and the like.

Although not illustrated in Fig. 3m, the server complex 204 may include other components such as authentication and encryption servers that ensure the authenticity of chat communication messages and ensure the privacy of their contents. The server complex 204 may also include a plurality of other components such as voice-to-text and text-to-speech translators, natural language translators, voice transcoders, and other similar information gateways that transform the message, its contents and any arrangement. (for example, voice tones, images, etc.) to a more usable and consistent format by the receiver. The techniques for implementing such other devices are well known in the art.

In the preferred embodiment, each plurality of wireless operators can make use of different wireless data technologies in the wireless carrier network 202, such as Global System for Mobile Communications (GSM) General Package Radio Services (GPRS) and Multiple Access Code Division (CDMA) Single Carrier Radio Transmission Technology (1xRTT). In this sense, the systems exposed here do not depend on the wireless technology used.

In the preferred embodiment, the voice codec 307 used in the plurality of mobile terminals 100 is innate to the terminals. The innate voice codec 307 to the mobile terminal 100 is optimized for both the terminal processing strategy and the wireless technologies used. To make the system independent of the underlying wireless technology, the system uses commercially available media scheme gateways (not shown). Media gateways transcode voice samples from one encoding to another. During operation, message diffuser 303 sets the type of encoding used in incoming messages. Determine the type of coding required for each plurality of target mobile terminals 100. For each copy of the message, the message diffuser 303 uses at least one media gateway to transcode the voice to an appropriate coding scheme of the target recipient. The techniques for detecting the type of coding used by the incoming message and / or required by the target terminals, as well as the establishment of an interface for the media gateways are well known in the art. Exception processing can also be performed by the system in cases where the media gateway is disabled to complete a conversion. For example, a message can be sent back to the sender informing the sender that the message has not been delivered to the target recipient because the system does not support the required transcoding techniques.

In addition, the system can be configured to optimize transcoding. For example, the message diffuser 303 can re-use the same transcoding for all messages that are the target of mobile terminals 100 that require the same encoding. In addition, the message diffuser 303 can avoid transcoding the voice if it detects that the message, on the other hand, cannot be sent to a target. Other optimization techniques can also be used.

In the preferred embodiment, the plurality of mobile terminals 100 are grouped and allocated among a plurality of chat server complexes 204. As such, each server complex 204 serves a set of homogeneous mobile terminals 100 that require the same coding of voice. Multiple server complexes 204 can use the same encoding. When the message reaches the message diffuser 303 of one of the server complexes 204, the diffuser sends at least one copy of the message to another server complex 204 that manages the connection with a subset of intended recipients of the message. The message sent is transcoded by a media gateway en route between the two server complexes 204. The system benefits from the use of a common encoding to transfer the voice sample between the different server complexes 204. In particular, the message that is received by a server complex 204 is transcoded to the common encoding before it is sent. to the plurality of the other target server complexes 204 (in this case only a transcoding is required). After the arrival of the message to each plurality of target server complexes 204, the message is converted to the encoding that is suitable for the target mobile terminal 100. Only one encoding in the server complex is necessary since all terminals served by The complex use the same coding. Messages not sent outside the server complex 204 do not need transcoding since all mobile terminals served by the complex use the same encryption. In this arrangement, the simplest media gateways can be used between the complexes 204 because the gateways only need to transcode the content between the common coding and the coding used by the mobile terminals 100 served by the complex 204. Also, the detection of the type of transcoding required is inherent in the routing of the messages, that is, the structure and distribution of the mobile terminals and do not require real resolution based on any coding information. This is done only based on the target address of the mobile terminal, which is resolved in all cases to route and direct the messages. For example, instead of using multiple server complexes 204, a single server complex 204 can be subdivided into which a plurality of message diffusers 303 are used in the same spirit as distributed server complexes 204. The invention is not limited to any particular provision of server complexes. Alternative arrangements can be used for server complexes.

Preferably, a nickname manager 304 resides in the server complex 204 and is responsible for managing lists of 802-803 nickname sets used by the recipient of an incoming chat message 500 to override public nicknames and abbreviations. Note that nicknames and abbreviations differ mainly in length. The nicknames can be of any arbitrary length (possibly limited by a matter of design choice) while the abbreviations preferably have fixed length and size. Additionally, nicknames and abbreviations are examples of presentation or display identifiers used to identify the creators of the messages. Such presentation or display identifiers are distinguished from identifiers used internally by the system to identify particular users (for example identifiers having reference numbers 701, 403 and 604 in the attached Figs.). It should also be noted that the abbreviations may differ from the nicknames in format or type. The system can use graphic, symbolic or other forms of abbreviations that are compact and of fixed dimensions while text forms are used for nicknames. The system can vary graphics and symbols based on context, user preferences, presentation or display themes and personalities.

Fig. 8 illustrates the nickname register 800 contained within the nickname manager 304. Preferably, each nickname register 800 comprises a receiving user identifier 701, the friend identifier 801 (ie, the chat friend identifier for whom the receiving user wishes the broadcaster to replace the public friend nickname set 704 -705 for the set of 802803 private receiver nicknames in all incoming chat messages 500) and the 802 private nickname and 803 private abbreviation. As in the case of presence records 700, nickname records 800 may contain other information and attributes such as shipping addresses, processing rules, graphical representation for various states, profiles (ie, different field values ​​that could be used in different moments, etc.) and so on. After receiving the object message for a recipient designated by the receiving user identifier 701, the nickname manager 304 determines the friend identifier 801 (ie the identification of the participant in the chat that initiated the transmission of the message). Based on friend identifier 801, nickname manager 304 inspects the nickname records corresponding to the target recipient. If the friend identifier is not found in the target recipient nickname records, the message is sent to the target recipient as an incoming message with the public nickname and the public abbreviation of the sender. In this case, the public nickname and / or the abbreviation of the sender will then be presented or displayed on the display element or screen of the mobile terminal of the target recipient. If the friend identifier is located in the target nickname records, the nickname manager determines the private nickname and private abbreviation associated with the friend identifier and replaces the public nickname with the private nickname and the public abbreviation with the private abbreviation in the next incoming message sent the target recipient, thereby causing the private nickname and / p the private abbreviation to be presented or displayed on the display element or screen of the recipient's mobile terminal. In this way, users (i.e. recipients) have a greater degree of control over how chat stories are presented in their terminals. Note that the process of determining private presentation or display identifiers and replace them with public presentation or display identifiers could be performed by mobile terminals that assume that the necessary nickname records are stored in the mobile terminals.

Fig. 4 illustrates an outgoing chat message 400 that terminal 100 sends to message diffuser 303. The outgoing chat message 400 comprises a type of message 401 (eg, text, voice, etc.) to a number of recipients. desaturated 402, a plurality of recipient identifiers 403, a string identifier 404, a message length 405, message content 406, and a number of accessories 407. Preferably, the mobile terminal 100 generates the string identifier 404 by adding a client identifier and a session identifier with a string sequence number. The string sequence number is a terminal side number that starts at 0 every time a session is initiated. The client increases the string sequence number by one each time terminal 100 generates a new string. Although not illustrated in Fig. 4, the payload may contain message encoding types and other accessories (for example, icons, ringtones, etc.). Other elements can be added to the outgoing chat message, such as sequence numbers, time stamps or the like.

The message diffuser 303 after receiving the outgoing chat message 400, first compiles a list of target recipients comprising the sender identifier (ie, the first recipient identifier in the recipient identifier list 403) and the plurality of recipient identifiers (that is, the recipient identifiers in the identifier list 403 other than the sender identifier). For each objective, the message diffuser 303 determines the state 702 of the objective by locating the objective identifier in a presence register 700 with the coincidence identifier 701. For each available objective (ie, in which the presence register indicates that the recipient can receive message type 401) broadcast manager 303 composes an incoming chat message 500. Message diffuser 304 asks the nickname manager to find the set of local nicknames of the recipient 802-803 for the other recipients (that is, the identifiers that comprise the original list of targets without the receiver identifier.) If not find information (i.e. the receiver did not build a 800 nickname record for the particular recipient), the message diffuser 304 asks the presence manager 302 for the public nickname information of the recipient 704-705. The message diffuser 303 extracts the address of the receiver 704 from the presence manager 302 and sends an incoming message 500 to the terminal of the receiver 100 through the router 301. Those skilled in the art will undoubtedly recognize that means can be employed to optimize the creation and dissemination of messages, such as using common decoding compression techniques, and that other information may be included in the incoming chat message 500, such as sequence numbers, time stamps, etc.

Fig. 5 illustrates an incoming message 500 sent by the server complex 204 to terminal 100. As shown, the incoming message 500 is largely a copy of an outgoing chat message 400 sent from a terminal 100 to the server complex 204. The incoming message 500 preferably comprises the original outgoing message 400 and a definition of new users not shown in terminal 100 (ie, not listed in the recipient friend list). The new user definition comprises a certain number of definitions 501 and a plurality of individual definitions comprising recipient identification 502, full name 503, public nickname 504, a public abbreviation 505. In some cases, the original outgoing message has to be transformed. to be understood by the reception terminal 100. It should also be noted that the server complex 204 may only need to include the new user definition once during a session. That user definition is placed in temporary storage 309 of terminal 100. This makes less wireless data transfer possible. Other attributes can be placed in the incoming chat message 500 including things like time stamps, sequence numbers, and so on. It should also be noted that anonymous virtual or group identification identifications can also be used.

When a participant presence status 702 changes, the message diffuser 303 sends an update message 600 to other users subscribed in the participant presence status 702. Fig. 6 illustrates a friend list update message 600 sent from server complex 204 to mobile terminal 100. Message 600 comprises a type of list 601 (for example an alphanumeric list, group list, etc.) the number of groups identified in message 602, at least one group definition 603-604, a list of ungrouped individuals 605 -606, and a plurality of user definitions 502-505, 607. Note that the status field of the recipient 607 indicates the value of the presence status 702. A group definition in this context comprises a group name 603 and a plurality of recipient identifiers 604. A recipient identifier may exist in a plurality of group definitions. In addition, preferably, for each identifier of the recipient identifier list 604 there is at least one user definition 502-505, 607 for that recipient of the friend list update message 600. The list of ungrouped individuals is a special group with no name.

It comprises the number of ungrouped individuals 605 and the list of recipient identifiers 606. Preferably, the recipient identifiers in the ungrouped definition cannot be in other groups. The records 600 may contain other fields of attributes and information such as presentation or display icons, hearing aids or the like. In addition, it should be noted that the messages do not have to contain the entire list of groups or individuals in the updates, incremental updates could be used instead.

Presence manager 302 can send friend list update messages 600 to terminal 100 after receiving an update request from terminal 100. Those skilled in the art will recognize other reasons for sending friend list updates (eg initial connection ) also as optimizations in the way of coding the contents by sending incremental updates of the whole list, etc.

In another embodiment, part of (or all) the functionality of the message diffuser 303 and the nickname manager 304 may reside in the terminal 100. In that case, the terminal 100 communicates with the server complex 204 when the data information changes presence. Chat communication messages are broadcast from one terminal 100 to the plurality of the other terminals 100 in a point-to-point manner.

Fig. 9 illustrates a presentation or display of body list with its entries sorted alphabetically. Screen 102 is divided into three regions. In a higher region there is a title bar region 901 that allows the presentation or display of a line of text and graphic symbols (ie icons). The software uses this region 901 to provide the user with notifications and other meta information about the current task. In the case of presentation or display of the friends list, the title bar 901 comprises the presence indicator of the user 904. The public nickname of the user 704 itself and, in some occasions, the incoming chat message indicator 905. Preferably , the presence indicator 904 is an icon that varies in appearance depending on the presence status 702 (ie, there is a different and distinguishable characteristic associated with the different status values). Preferably the chat message indicator 905 is an icon accompanied by an audible sound when the icon is presented or displayed first. Combined, the visual and audible warning indicates to the user that there is at least one incoming chat message not heard and / or unread that has reached terminal 100. If the nickname the user is too long for the title bar 901, the software moves the title bar leaving only the incoming chat message indicator 905 in a fixed position for quick access. There are many familiar examples in the art today of such presentation or display techniques, any of which can be incorporated for use with the present invention.

In the middle region of the presentation or display there is a content region 903. In the case of the presentation or display of friend list, the software preferably places a multiple selection list in the content region 903, whose list has a plurality each representing a friend who was received by terminal 100 from server complex 204 in a friend list update message 600 and stored in temporary storage 309. Each entry can be highlighted 908 by the user. The highlighting and navigation list entries are implemented using common techniques of the technique. Each entry in the list comprises a selection indicator 906 that indicates whether the user has selected the particular friend to chat (ie, sending a chat communication message), the friend presence indicator 911, the friend nickname 802 or 704, and / or the friend abbreviation indicator 907. Note that symbols other than text could serve the same function as abbreviation indicator 907 for abbreviation information 705 or 803 as previously indicated. For example, icons or other graphic elements could be used as long as some friends differ sufficiently from others. Moreover, a combination of such graphic elements and text could be used if there is sufficient screen space available.

In the lower part of the screen 102 there is a function key tag region 202. Preferably, it is a minimum of two labels 909-910. The number of labels depends on the actual number of function keys 104 available on terminal 100. As shown, the left function key label 910 is "select" while the right function key label 909 is "write" if there is at least one selected entry in the friends list. If not, the right function key label 909 is labeled as "chat". If the user activates the left function key with a single click (referred to hereinafter as "single click") the highlighted entry 908 is selected (or deselected if it was already selected) and consequently if selection indicator 906 changes to Reflect the new state. If the user presses and holds (referred to hereinafter as "hold click") the left soft key, the software presents the user with a plurality of options, such as the option to deselect or select the entire list; Switch to other presentations (for example the presentation or visualization of history described in Fig. 11, the presentation or display of the list of friends sorted by groups described in Fig. 10. etc.; request the friend's details (for example full name, public nickname set 704 705, etc.); change the set of nicknames 802-803; show or hide fields (for example, the abbreviation indicator 907) and so on. Again, the techniques for programming such functionality and associated with the single click and / or the retention click are well known in the art. It should also be noted that the use of a text string to present a function key tag is by way of example and is only intended to show the philosophy or purpose of the invention. Other forms of labels, such as graphic symbols, and the like can be used.

If there are no friends selected, the right soft key label is "chat". Performing a single click or hold click on the right soft key in this context changes for the user to the presentation or display of chat history described in more detail with reference to Fig. 11. If the user presses the push-to-talk button 2101 (referred to hereafter as "push-to-talk") an audible indicator reminds the user that friends have to be selected first. If there is at least one friend selected, by pressing with a single click or hold click the right function key starts composing a message for a new chain for the selected friends. The presentation or display in that case changes to the next presentation or display of text message editing described in more detail with reference to Fig. 14. If the user presses to speak, the presentation or display changes to the chat history and The user is able to record and transmit a voice message and then start a new chain with the selected friends.

Fig. 10 illustrates a presentation or display of friends list with their entries stored in groups. In a preferred embodiment, the group entries and their member friends are listed first followed by a list of ungrouped friends. Individual entries are identical to those presented in an alphabetically ordered list with the exception of a preferred indentation or indentation (that is, an entry indicating the partner to a group). The group entries comprise a group name 1005 and a group selection indicator 1001 that is similar to the individual selection indicator 906 except that a group selection indicator may indicate more than just the selected and unselected states; You can also indicate the partial selection. Referring now to the example illustrated in Fig. 10, solid squares (group selection indicators) such as in groups 3 and 4, are completely selected. Group 5 has an empty square 4, which indicates partial selection. If there is a group without any of its members selected, there is no indicator at all at the group level (or the level of individual friend). To select a group, a user can either select all the members one by one or select the group directly. To partially select a group, a user can start by selecting a group after deselecting one or more members. Alternatively, a user can start with an unselected group and select one or more members. A group entry may be collapsed (that is, group members are deleted from the presentation or display). In that case, the input is annotated with a collapse indicator 1002. If the user highlights a collapsed group over a period of time, the group automatically expands to show the members. When, the user moves to another group, the presentation design or group display is returned to a collapsed state. If a user selects or deselects a group entry, all group members are automatically selected or deselected. Function key labels 1003-1004 are similar in behavior to those described with reference to Fig. 9. However, by clicking hold when the group stand is highlighted (or an individual within a group is highlighted) presents to the user additional options to manage the group, such as renaming the group: withdraw the group or its members; add a new group or individual, collapse or expand the group; collapse or expand all groups; etc. It should be noted that, in a preferred embodiment, only one grouping tag is allowed (ie, nested groups are not allowed) although multiple levels could be provided.

Preferably, when the system supports presence profiles that are paired to user recipients or groups, then when the user highlights the plurality of friend entries 908, the user presence indicator 904 and the nickname 704 of the title bar 901 will vary to indicate the presence information of that particular friend (or group of friends). It should also be noted that if the information in the highlighted entry 908 is too long, the software can move the information, expand it or use other techniques common to the technique to present all the information to the user.

It is to be understood that there are other means for ordering lists (by date, events, etc.) and that other entries could be added to the entries. For example, you can use an indicator that has messages that have not been read / read available from the individual or group.

Fig. 11 illustrates a presentation or visualization of chat history. The 903 content region of the presentation

or display is a unique selection list comprising a plurality of entries representing incoming chat messages 500 received from terminal 100 and a plurality of entries representing outgoing chat messages 400 transmitted by terminal 100. Outgoing chat messages are preferably returned to the sender totally or partially (for example, voice messages may not include the actual voice sent) in the form of incoming messages. That is, outgoing chat messages go to the server complex for transmission to the target recipient (s). In addition to sending the message to the target recipient (s), the message diffuser sends a copy of the outgoing message to the transmission terminal (ie, the sender) as an incoming message. In some cases, the copy of the message (the incoming message) to the transmission terminal may not be identical to the message that was sent (the outgoing message). For example, the voice content of an outgoing voice message is not copied to the transmission terminal, only part of the text of a voice message is sent again as an incoming message. Note that in this case, the voice messages have texts attached to them, even if only a string of characters or generic symbols is used to indicate that the message was a voice message. Of course, if the voice to text conversion is available the actual voice content of the message could be converted to text and copied back to the transmission terminal. In this way, the concurrence of voice message results in an entry that is presented on the screen. In an alternative approach, instead of having the text of an outgoing message sent back to the transmission terminal through an incoming message, the transmission terminal can locally return the text to the presentation or display directly. In this way, the use of wireless resources can be minimized.

A common problem in the chat technique is the representation of successful delivery. A preferred approach for notifying delivery is to send an outgoing message 400 again (such as an incoming return message 500) to the sender mobile unit to notify the sender that the message has been delivered reliably to the message diffuser 303 in the chat server complex 204. Alternatively, the representation of that notification may be a text message that is placed in the chat history with a message indicating that the message sent was received by all recipients. The return can be sent again when the outgoing message 400 is received by the message diffuser 303. The chat server complex 204 can then send a reception notification when all the recipients have received the message. Preferably, the original return is noted when the delivery recipient arrives (for example it changes color and / or font, or is adorned with a symbol such as a check mark, etc.) to notify the receipt. In an alternative approach, the return message back to the user may be delayed until the diffuser 303 has received confirmation that all desired recipients received copies of the message. However, the approach may have some effects on the presentation or display side that may confuse the user in environments where the delivery latency is relatively long and there is a high degree of latency variability between deliveries of the plurality of message messages. copy. In such situations, at least one recipient can reply back to the sender before the message reaches the remaining recipients. In that case, the sender varies his presentation or display of chat history (see for example Fig. 11) the response to the message before the return. Several techniques can be used to solve this problem. For example, mobile terminal 100 or server complex 204 could delay the presentation or display or deliver the recipient's response until the original message was received by all recipients and the return sent back to the user.

Although not illustrated, at any time, the user can ask the system who has (or has not) received the message. Other implementations may choose to waive allowing the user to ask the system for pending deliveries and instead provide comparable information by sending a plurality of reception notifications (one each time a copy is delivered to the user). Although such techniques may be simpler to support in the chat server complex 204, they may require more communication resources.

In an example of Fig. 11, each entry comprises an attached file indicator 1104-1105 that affects whether there is any attached content (eg, documents, files, etc.) or transmitted voice available; the abbreviation of the sender 705 or 803, and at least part of the content of the message or text (all text if the text fits within 2-3 lines). Although not illustrated in Fig. 11, there may be other indicators present in a teles entry as a blocked entry indicator (i.e. it indicates that an entry was saved in permanent storage 305 and will always appear in the presentation or display unit of chat history until it is unlocked ). Note that less amounts of information can be included in each entry of the presentation

or display For example, only the content of the message could be presented or displayed without the abbreviations of the senders.

When an entry is highlighted 1106, the plurality of 802 or 704 nicknames of the sender and the other recipients is placed in the title bar 1101. If the list is too long, the contents of the title bar 401 are scrolled. Alternatively, abbreviations or other symbols may be used instead of the nicknames in the title bar 1101. When the user selects an entry 1106, all related chat messages in the same chain are emphasized 1103 as well. The emphasis can be made by changing or noting related entries or changing unrelated entries (for example by shading the entries). If a selected entry is too long to be presented in its entirety and is selected for a period of time, the contents of the entry can be automatically expanded to present all text content. In that case, when the user moves to another entry, the entry immediately shrinks again to fit within its originally allocated space of 2-3 lines of text. The actual number of assigned lines depends on the size of the screen. When new 400 incoming chat messages arrive, new entries are automatically added to the list, for example, at the bottom of the list. The bottom or friend list entry 1107 is a special entry that refers to the list of friends currently selected in the presentation or display of friends list. The user can use the entry to start a new chain with friends. The lower entry 1107 only appears when the user has selected friends, and is composed of an icon 1110 that distinguishes the entry from other chat message entries "regular". If the user selects the lower entry 1107, the list of friends appears in the title bar 1101 in the same way that the recipients are presented or displayed when the entries "regular" of chat history are highlighted.

The 1108 function key tag is "friends". By simply clicking or holding click, the function key changes the user to the presentation or display of the friends list (see Figs. 9 and 10). The right function key tag 1109 is "answer" If the highlighted entry is a chat message entry. If not, it is labeled "write" as before. By clicking the right soft key, the user moves to a presentation or display of the message editor described in more detail with reference to Fig. 14. The target recipients of a message are either derived from the list of recipients of an entry of a chat message 1106 or those associated with the 1107 friends list entry. In the case where the highlighted entry is a chat message entry 1106, by clicking hold the right function key presents user options similar to those described in more detail with reference to Fig. 13. If not, yes to the highlighted entry is the friend list entry 1107, an action of "send to all" is indistinguishable from the & quot; answer all the action & quot; normal single click. If the user presses to speak, the target recipients are compiled (that is, either the sender and the recipients of the chat message entry 1106, or the friends of the friend list entry 1107), the title bar it is updated in the manner described in more detail with reference to Fig. 12, and the recording and the transfer of a voice chat message begins.

It should be noted that if an incoming voice message arrives while the presentation or display of chat history is not visible to the user, the received voice is queued. In a current implementation, the most recently received voice message (or at least that part that will fit in the available memory) is queued at the receiving terminal. In an alternative approach, such queuing can occur in the server complex so that the recipient can request reproduction within a predetermined period of time. Still further, queuing could occur both at the terminal and at the server side so that playback can be requested from the server in the event that a given voice message is no longer available at the terminal. Although the voice input is the most recent voice input, the associated voice remains queued and ready for playback after the user's return to the presentation or display of chat history. When the user switches back to the presentation or display of chat history, if the voice input is visible on the screen, it is automatically played. Only the last voice message received is automatically played. Playback is abandoned if the user returns to the chat history to record and transmit a voice chat message.

The unambiguous delivery of voice messages to the user is a problem when multiple multimodal conversation chains are integrated into a single chat story. In the current technique, it is difficult for a user to associate voice with particular discussion chains. The system presented here solves the association problem in two ways. First, as stated above, each voice message leaves an entry in the presentation or display. The entries link to their corresponding chains and represent at least the sender and the list of other recipients of the message. This, however, is not enough in cases where the user is not able to view the presentation or display while listening to voice messages. For this reason, the system set forth here uses a second technique in combination with the first. Preferably, when a user selects a chain, all voice messages associated with the selected chain are automatically played back to the user, unless otherwise available to the user. Any voice messages that do not belong to the selected chain are not automatically played. Instead, mobile terminal 100 presents an audible signal to the user indicating that there is another incoming voice message (s) in another chain (s). The user at that point can choose to play the message

or request that the system skip it. Regardless of whether the incoming voice message is played, the text portion of the incoming voice message is presented in the presentation or display. This helps the user in the decision process of choosing to listen to the message or ignore it. Additional optimizations are possible. For example, the user may be given the option to skip the message. Any voice data that is transmitted is then omitted and the server is notified that it can stop the transmission of the rest of the voice message and begin the transmission of the next message in the queue (if any).

Delivery techniques can be optimized. For example, the mobile terminal 100 can send a message to the chat server complex 204 whenever the user selects a chain. This allows the chat server complex 204 to suppress the sending of voice components of the voice message that does not belong to the selected chain until the user indicates that he wishes to hear the voice. This minimizes the sending of large amounts of data to mobile terminal 100 that may not be used.

Fig. 12 illustrates the title bar of a presentation or chat history display when the user is recording and transmitting an outgoing voice message. The title bar comprises a recording indicator 1201: the plurality of recipient nicknames 705 or 802 (which does not include the sender) and optionally, a single label 1203 indicating to the user that he is speaking to the identified recipients. If the list of recipients is too long, the list scrolls; however, the recording indicator 1201 remains fixed in its position. There may be a delay between the hours when the user presses to speak requesting to record and transmit voice and when the system gives the user access to do so. Preferably, the recording indicator 1201 is an icon that changes its appearance (for example, the color of the graphic symbol) to indicate when the user has or loses the voice / recording access. Shortly after the user releases the push-to-talk button 101, the title bar returns back to the normal title bar 1101 in the presentation or display of chat history.

Fig. 13 illustrates a presentation or detailed view display of an incoming chat message 500. The title bar 1301 comprises the sender presence indicator 904; sender nickname 705 or 802; and optionally a time stamp (when the message was sent or received). If the information in the title bar is too long, the nickname moves. In that case, the remaining indicators preferably remain fixed. The content region 1303 comprises an attachment file indicator 1302 that notifies the user of the availability of attachments or voice; the full text of message 1309; a separator 1304; and the plurality of entries representing other recipients (not including the sender or the receiver). In the example shown in Fig. 13, each entry comprises the set of nicknames 703-705 or 802-803. Alternatively, each entry could comprise only some part of the set of nicknames (either the nickname or the abbreviation) to some type of presentation or display identifier. The left soft key label 606 is "cancel". By simply clicking and holding click on the left function key, the screen is exited and the previous display or display is restored. The right function key label 607 is "write". By clicking on the right soft key, the user moves to a presentation or message editor display described in more detail in Fig. 14. Clicking hold on the right soft key presents the user with options such as playing the available voice; view or store available attachments: block entry in the presentation or display of chat history; save the incoming chat message in permanent storage 305; Move to the next or previous chat message, replying only to the sender or to one or the other recipients (that is, starting a new chain) and so on. If the user presses to speak, he leaves the presentation or view view in detail. The user moves to the chat history and starts talking to the sender (unless the user is the sender) and all other recipients. The reproduction of any queued voice is abandoned in that case.

Fig. 14 illustrates a presentation or display of text message editor. In this example, the title bar 1401 comprises a plurality of nickname of target recipients 704 or 802 and a single action tag indicating to the user that he is composing a message. Title bar 1401 scrolls if the contents are too long. A text input area 1402 is provided below the title bar 1401 to compose text messages. The left soft key label 1401 is "cancel". By clicking and holding click on the left soft key, the presentation or display is exited, the contents are preferably abandoned, and the presentation or previous display is restored (except in the case where the previous presentation or display was a presentation or display of detail view, in which case, the presentation or price display of presentation or visualization of detail view is restored instead of the presentation or visualization of detail view). The right function tag 1043 is "send". By simply clicking on the right soft key, the software is made to build and send an outgoing text message 400. Clicking on hold on the right soft key provides the user with a set of options such as the anointing of other content (for example, ringtones, etc.), checking the spelling of the message and so on. Preferably, if the user presses to speak, the presentation or display is exited, its contents are abandoned; The user moves to the chat history and starts talking to the selected recipients. The reproduction of any queued voice is also abandoned in this case.

The present invention is not limited to multimodal chat between people. There are text-based chat systems, such as those used by Active Buddy, Inc., that allow users to interact with interactive services on the network using a chat metaphor. Unlike these systems, however, the systems exposed here allow the chat dialog to use both text and voice. For example, a user wishing to obtain a status of a package delivery can send a voice message to a package delivery service presence. The voice would include at least the package identifier. The automatic response service, which uses voice recognition techniques known in the art, determines the user's request and composes a response. That response can be voice based (for example, you can send a voice message that indicates that it was not possible to understand the request) or it can be textual (for example, the list of package details en route to your destination). The service subscribes to the presence of the user. The service sends the user again when it notifies that the user presence status allows the details to be sent in the preferred format.

The systems of the invention also allow all services to incorporate commands that can fulfill either the mobile terminal 100 (for example, initiate a telephone call) or the server complex 204 (possibly in combination with other services of the network), or some combination thereof. For example, an individual chat with another user may at some point wish to start a telephone conversation. Preferably, the user requests that the server complex 204 initiate a telephone conversation by sending a command from the mobile terminal 100 to the server complex 204 by comparing at least the information necessary to establish a telephone call between the sender and the target recipient. The server complex 204 initiates a request to a Voice Over IP (VoIP) telephone system. This system then establishes the telephony access points closest to the endpoints and establishes a call by calling the sender and the target user routed the calls between those access points using such a common protocol as the Session Initiation Protocol ( SIP) and the Real Time Transport Protocol (RTP). The system can use a chat interface to collect and establish the call details (as described above) or it can collect the information and initiate a command using common techniques known to those skilled in the art. In an alternative approach, the server complex 204 sends a command back to the mobile terminal 100 comprising at least the target telephone number. The mobile terminal 100 then initiates a telephone call with the objective. Conventional techniques can be used to establish a phone call on the mobile terminal

100.

The quality characteristics of connections in wireless data networks may change over time. For example, a mobile user can move to an area without coverage in which the data connection is dropped. The connection can be reestablished later when coverage is available again, however, in the process, mobile terminal 100 can acquire a new IP address. Consequently, server complex 204 is unable to send messages to mobile terminal 100. To handle this, the system set forth herein uses a session identifier between the particular mobile terminal 100 and the server complex 204. Whenever the mobile terminal reestablishes a connection (after losing it due to loss of coverage, as an example) the mobile terminal 100 reuses the session id of the interrupted session. The server complex 204 then reconnects the new connection with the existing session. If the mobile terminal 100 does not reconnect within a given timeout period, the server complex 204 may terminate the session. Other events that cause a disconnection may include a lost session termination command sent from mobile terminal 100, incorrect disconnection of the chat application on mobile terminal 100, battery failure or the like.

Preferably all routing that occurs within (or between) server complexes 204 is done using session ids. A session id is preferably used instead of a client id because a user can choose to end one session and establish another. In this way, all messages attached to the finished session can be deleted from the system. Only transactions associated with active sessions are maintained. Also, in a distributed server complex environment 204 there are many message diffusers 303 (ie, main physical computers) the client can connect to the different servers. Using the ids provides simple means to find where the client is currently connected. In addition, in reestablishing a connection, the server complex 204 may use what is normally known in the art as linked load balancing switches that direct a client reconnection to physically reestablish its connection with its previous host server in based on the session id (even in cases where the IP address of the mobile terminal 100 may have changed).

In addition, many wireless operator networks do not allow initiated network messages to reach mobile terminal 100. Initiated network messages, since they belong to the systems described herein, are messages ranging from server complex 204 to mobile terminal 100 which appears in the network operator as if it were not requested by mobile terminal 100. This is a common problem in chat environments since a 030 message diffuser commonly sends 500 unsolicited incoming messages to the recipients of a message. To overcome this, the system uses strategies to keep alive. These strategies vary depending on the data transfer protocol established between the particular mobile terminal 100 and the server complex 204. The keep alive strategy involves periodically sending a message from the mobile terminal 100 to the server complex 204. The keep alive message appears on the mobile network as a request. Subsequent messages sent back to the mobile terminal 100 can be considered by the operator as responses to requests as long as the messages sent to the mobile terminal 100 originate from the same address as the mobile terminal 100 sent in a keep alive message. The frequency of keeping messages alive is a matter of design choice and transfer protocol used. When HTTP is used as a transfer protocol, the system uses a voting mechanism. Using this mechanism, the keep alive message is sent frequently and acts as a vote to determine if there are any pending messages in the server complex. If there are pending messages, those messages are sent again in response to the voting request. TCP and / or UDP do not require a voting mechanism and may use live-keeping techniques, such as simply sending at least the session id in a message to server complex 204 with significantly longer time between messages. Sending messages to keep alive can be optimized. For example, keep alive messages do not have to be sent when outgoing messages 400 have recently been sent from mobile terminal 100 to server 204.

Preferably, all messages sent to the mobile terminal 100 from the server complex 204 travel through the same router and possibly the same physical host server to which the mobile terminal 100 of the server complex 204 is attached. This ensures that the operators they can treat the messages as responses to a request from mobile terminal 100. Other techniques to make traffic appear from the same location, such as address mapping and the like, can also be used by the system.

In addition, the keep alive messages work in combination with following techniques described above to inform the chat server complex 204 if the address of the mobile terminal has changed. This is especially useful in cases where UDP is used as a transport protocol. In each keep live message sent, the server complex 204 notifies the address of the mobile terminal 100. If the address changed, the server complex 204 then re-linking the session id for the new address. As such, the keep alive message can still benefit the system even if the operator does not block messages from the initiated network.

It is possible, that the server complex 204 is unable to deliver a message to a mobile terminal 100 because it does not have most of the updated addresses - the address of the mobile terminal 100 may have changed before the message keep alive be sent In this situation, the system may, for example, retain an undeliverable message for a period until the next message to keep alive arrives; You can skip the message and inform the sender that you have failed to send the message; or you can send the message using some out-of-band mechanism, such as the out-of-band mechanism described in relation to Figure 15.

A problem in some wireless packet data networks currently used is the containment of communication channel resources. Although, a wireless connection is established, some systems (for example 1xRTT) may lose the ability to route phone calls and other wireless services related to mobile terminals 100. As such, the keep alive strategy used by the system described above It can become problematic. To solve this problem, preferred embodiments use a backtracking strategy ("back off") that is based on predicting user involvement in the chat service. The recoil strategy uses a dynamic timeout scheme. For example, when mobile terminal 100 is presenting a presentation or display of chat history where there are active updates (for example, incoming messages 500) and the probability of participation is high, the length of the waiting time is significantly longer than when there are no updates or when mobile terminal 100 is presenting a presentation or display of friends list and the probability of participation is lower. The purpose of the waiting time is to avoid cases in which the user could have forgotten or otherwise inadvertently left the chat application running by preventing any incoming telephone call or other communications from reaching the user. When the timeout occurs, the user is read an opportunity to continue the session. A quick notification to the user that the connection between mobile terminal 100 and server complex 204 is about to be interrupted. The user can choose to cancel the action and keep the connection alive. If, on the contrary, the user does not cancel within the allotted time to respond, the connection automatically ends. When the mobile terminal is disconnected, it can no longer receive chat messages through established packet data connections.

Alternative disconnection schemes can be used. For example, the chat program that is running on the mobile terminal may choose to periodically reconnect with the server complex 204 to see if there is any message pending delivery. If not, the chat program on the mobile unit can be automatically disconnected. On the contrary, the messages are delivered and the program updates the presentation or display of chat history as described above and resumes operations until either the user ends the session or the timeout expires as described above. .

Fig. 15 illustrates how the total system architecture of a wireless communication system comprising the elements described in Fig. 2 is extended to integrate with a legacy mobile terminal 1502. Within the context of the systems described here, an inherited mobile terminal is capable of transmitting and receiving at least text messages in some well established conventional mechanism, such as Short Message Service (usually referred to in the art as SMS messages or simply SMS) . However, unlike a mobile terminal 100, the legacy mobile terminal 1501 is missing the elements required to communicate directly with the chat server complex 204 and to participate directly in some chat transactions described herein.

To integrate a legacy terminal, the chat server complex 204 communicates with at least one SMS aggregator 1501 through a 2'3 communication network (such as the Internet or Word Wide Web). The SMS aggregator 1501, which can be a commercially available device, comprises all the necessary elements to allow entities that do not have any direct affiliation with wireless carriers to inject SMS messages into at least one wireless carrier network 202. The SMS aggregator 1501 takes as input (via the communication network) a description of the SMS. The description comprises all the elements necessary to send a message to the target mobile terminal 100. The description comprises at least the originator's address, such as a mobile terminal address 100, or a special return address known as a short code or a code Long, the destination address. Such as a terminal address 100, and the content of the message.

The SMS aggregator 1501 communicates with the target operator through its wireless carrier network interfaces 202 and injects an SMS on behalf of the applicant. In this system, the requestor is the chat server complex 204 or any agents acting on its behalf.

The mobile terminal 100 allows the user to enter the address of the legacy mobile terminal 1502. This can be done in an ad-hoc manner in which the user is pushed to the address at the time of creating the outgoing message 400. The address in This context is typically the telephone number of the mobile terminal 1502. Alternatively, for a user who frequently aims at a particular legacy mobile terminal 1502, the system can provide that user with means to build a presence of friends in the system comprising at least one presence data record 700 and one data record of nickname 800. Conventional data collection and construction methods can be used for the processes of adding an inherited friend or using ad-hoc addressing.

The inherited address, be it the real address, the recipient id of the inherited friend, can be used in the same way as any other recipient id. This is placed in the list of recipient ids (403 and 502) in outgoing messages 400 and incoming messages 500. In the case where the actual address is used, the presentation or display of address is usually distinguishable from uninherited addresses . This allows the system to process the address differently than the remaining recipient ids.

The inherited address may be part of a group communication with at least one other inherited mobile terminal 1502 and at least one other [non-inherited] mobile terminal 100. Alternatively, the inherited address may be the address provided only in a one-to-one communication with the legacy terminal. The inherited address may be part of the initiation of a new conversation thread, or it may be part of a reply from an existing chain.

In the case of legacy ad-hoc address entry, the system has to set recipient fields (503505) in incoming messages 500. The system can place generic representation in these fields. For example, the address can be used as the 503 recipient's name. When available, the system can ask public address books to find the real name. Other techniques can be used. For example, in cases where the information is considered private and the system does not allow it to be presented, the mobile terminal 100 (or the server complex 204) may replace the information with the representations of the host computer.

The outgoing message 400 carrying an inherited address is sent to the message diffuser 303 of the chat server complex 204. The message diffuser 303 detects the inherited address of the inherited mobile terminal 1502 (either the actual address or a reference for it used an inherited friend recipient id). For each non-inherited mobile terminal 100, the message diffuser 303 constructs incoming messages 500 as described hereinbefore.

For each target legacy terminal 1502, the diffuser 303 sends an SMS request to the SMS aggregator 1501. To do this, the diffuser 303 sets the originator address of the SMS request for the mobile address of the sender's mobile terminal 100 that initiates the message. The SMS aggregator 1501 sends an SMS on behalf of the chat server complex 204 and the sending user to the legacy mobile terminal 1502.

The message sent to the legacy mobile terminal 1502 contains at least the original message. Other information can be included in the message. For example, the message may comprise the list of other recipients, the identification of the chain, the delivery time, a service provider identity, a warning, or the like. In the case of a voice message that cannot be delivered through the out-of-band message generation scheme, the chat server complex 204 can replace the voice content with the text content. When the voice-to-text service is available, the chat server complex 204 may replace the text message delivered whole or truncated. Otherwise, the chat server complex 204 may place a representation of the exposure. For example, you can skip the voice part or only send the text part similar to the one that is presented in a presentation or chat history display when an incoming voice message is received.

Once the SMS is narrowed to the mobile terminal inherited from the recipient 1502, the SMS application innate to the mobile terminal 1502, which typically resides in an application storage and is executed on a CPU inside terminal 1502 intercepts the SMS and notifies to the user allowing the user to read the contents of the message. The recipient can reply to the message using the SMS request on the legacy mobile terminal 1502. In that case, the application constructs a reply SMS in the original incoming SMS that was supplied by the chat server complex 204. In this situation, the message does not return to the chat server complex.

204. Instead, the reply SMS goes directly to the target mobile terminal 100 through the wireless carrier network 202. When the response reaches the target mobile terminal 100, the chat application intercepts the message and presents it as part of the presentation or display of chat history as described in Fig. 11) as an incoming message.

Some mobile terminals do not allow the chat application to access the out-of-band message generation system. In that case, the user would either have to respond using the innate out-of-band application, move the message (partly or completely) between the two applications, or otherwise manage the message in the application.

The most common SMS systems do not comprise the elements necessary to allow the chat server complex 204 to predictably insert any information that could manifest itself in an SMS response returning from the legacy mobile terminal 1502 (such as a string id , recipient list, or similar). As such, the reply SMS is not guaranteed to have any identification that would allow the chat application program in mobile terminal 100 to link the incoming message to an existing chain. As a result, the message may appear in the presentation or display of chat history as a new message in a new chain. The client in mobile terminal 100 under these conditions may generate the string id on behalf of the legacy mobile terminal 1502. In the event that the user answers, the new message and the address of the legacy mobile terminal 1502 (ie, the originator address of the reply SMS address) are sent to the chat server complex 204.

In an alternate embodiment, the chat server complex 204 does not place the sender's mobile address as the SMS originator's address as described in the preferred embodiment. Instead, the chat server complex 204 uses a long code or alternatively a short code. In this case, the SMS response from the legacy mobile terminal 1502 returns to the server complex 204. The server complex 204 can multiply the messages from the legacy mobile terminals 1502 about the codes using several conventional techniques to link a reply SMS to an existing chain. In this case, the message diffuser 303 in the chat server complex 204 may broadcast the message again to the participants in the chain through the appropriate channels. For example, if another legacy mobile device was participating in the chain, the message diffuser 303 could send the message through the SMS aggregator 1501 as described here above.

The inherited integration rule of message diffuser 303 can be performed on mobile terminal 100 instead of on chat server complex 204. In this case, mobile terminal 100 does not use SMS aggregator 1501. Instead, the mobile terminal 100 could inject the SMS directly into at least one wireless carrier network 202 for each of the target legacy mobile terminals 1502.

Other out-of-band communication mechanisms such as email, Multimedia Message Services (MMS) or the like can be used. In such cases, other forms of gateway replace the SMS aggregator 1501. Other delivery mechanisms may allow information to be embedded in the response message from the mobile terminal, also allowing the system to link responses to existing chains.

A problem faced by some mobile terminals 100 is the loss of application context when the user starts another non-chat application in terminal 100. For example, when a user of a mobile terminal 100 receives an incoming telephone call, the mobile terminal 100 may drop the data connection resources, suspend or half-run the chat program and / or otherwise disable the application. chat communication transactions and perform chat transactions with the chat server complex 204. In this case, the user can close the chat application when there is a small activity or the chat program can be automatically disconnected to free up resources, as described here above. As such, what was once considered a valid mobile terminal 100 for chatting in accordance with the systems set forth herein may act in an indistinguishable manner from the legacy mobile terminal 1501. The techniques described here as methods for integrating the chat environment with legacy mobile terminals 1502 can be applied to these situations as well. Out-of-band message delivery (via SMS for example) acts as a greeting to the user. Inform the recipient that the chat chain is in progress. The user can then choose to reactivate the chat program and resume the chat conversation. Alternatively, if resumption is not possible, the user can still choose to participate using the available out-of-band mechanism. In cases where the chat application has accessed the incoming out-of-band message, the chat application on mobile terminal 100 may extract the content and place them in the presentation or display of chat history. This also allows the recipient to respond to the sender. The response may return again as an out-of-band message or it may go through the chat system as an outgoing message band 500 through the chat systems set forth herein.

The presence status 702 represented in the mobile terminal 100 by the presence status indicators 904 and 911 describes what is referred to as availability. Availability in such contexts indicates that a user is able to receive 500 incoming messages (and optionally the type of 500 incoming messages). A status indicating lack of availability in such contexts presents the fact that a user is unable to receive 500 incoming messages (or a particular type thereof). As such, either the system will skip messages that are directed to the unavailable user, or it will store the messages for some time until the user is available again. For example, the system may always try to deliver the message (even to legacy mobile terminals 1502). In addition, the availability (as defined in the current technique) of mobile terminals 1502 may not be determinable. In addition, it should be stated that the utility of availability (as defined in the current technique) is somewhat diminished in cases where mobile terminal 100 (and 1502) accompanies the user most of the time.

Presence status 702 can implement availability as defined above. In addition, the systems use presence stage 702 and presence status indicators 904 and 911 to communicate other information, such as the type of message delivery. To do this, the user in the mobile terminal 100 is presented or displayed with a representation of the means the system will probably use to deliver the message such as using in-band communications over the wireless packet data or through an outside method. of band such as SMS, email, or similar. This can also provide a representation of the subset or type of messages that are probably delivered. For example, a text-only SMS representation may indicate that only the text parts of the message would probably be sent via SMS to the target recipient. As such, any attachments (eg photographs) as well as any voice components or outgoing messages 400 would probably be omitted or otherwise not delivered to the mobile recipient. For example, the cost associated with the delivery of the message, the expected delays and the quality of the service can be communicated to the user.

Figs. 16-17 show a combination of presentation or display of chat history / text editor according to a preferred embodiment of the present invention.

Fig. 16 illustrates a terminal screen 1600 in a first display or display mode. In the first presentation or display mode, the screen 1600 presents the chat history 1602, as well as the graphical user interface controls (GUI) 1604. Other information may also be presented on the screen 1600, as set forth herein. As shown in the example, the chat session history 1602 that includes a sequence of messages sent by the participants in the current chat group. As described here above, the exposed messages identify the sender and show the text sent.

By activating the GUI 1604 controls, the user can selectively place the terminal screen 1600 in the second mode, as shown in Fig. 17. For example, in the preferred embodiment, the user can select a message response or option of composing a new message from a selection list control 1604. In the second mode, the screen 1600 presents the chat history 1702 concurrently with a text editing area 1704. The chat history 1702 continues to be updated and can be scrolled on the screen while the text editing area 1704 is presented. A text editor resident in the mobile terminal is also activated so that the user can write one or more messages of text in editing area 1704 while chat history 1702 is simultaneously displayed as it progresses. GUI 1604 controls allow the user to send composite messages in the text editing area 1704 to the chat session. They are then presented or displayed in chat history 1702 in chronological order. Preferably, once the user sends the message using the GUI control 1604, the text editor can be deactivated by the user to collapse the text editing area 1704 so that the text editing area 1704 is removed and the screen automatically switch back to the first mode. The chat history 1702 can then be expanded to cover the entire screen area.

Preferably, the screen 1600 can again switch between the first and second modes using a user selectable area of ​​the GUI mobile terminal, such as a button or selection included in the drop-down menu or the toolbar. However, with user-operable switches, such as the momentary contact switch, numeric keypad button (s), configurable function key (s) or the like, can be used to place the display or display screen of terminal in any mode.

The functionality for the presentation or display modes illustrated in Figs. 16-17 can be implemented using the software included in the mobile terminal, and preferably implemented by the chat client application.

What has been described above is merely illustrative of the application of the principles of the present invention. Other arrangements and methods can be implemented by those skilled in the art without departing from the scope of the present invention.