WO2006112825A2 - Procedes et systemes de telecommunications - Google Patents

Procedes et systemes de telecommunications Download PDF

Info

Publication number
WO2006112825A2
WO2006112825A2 PCT/US2005/012844 US2005012844W WO2006112825A2 WO 2006112825 A2 WO2006112825 A2 WO 2006112825A2 US 2005012844 W US2005012844 W US 2005012844W WO 2006112825 A2 WO2006112825 A2 WO 2006112825A2
Authority
WO
WIPO (PCT)
Prior art keywords
data
server
message
network
recited
Prior art date
Application number
PCT/US2005/012844
Other languages
English (en)
Other versions
WO2006112825A3 (fr
Inventor
Mark J. Marriott
Reza Behravanfar
Mustafa Seifi
Kumar Swamy
Ken Beckett
Original Assignee
Voice Genesis, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Voice Genesis, Inc. filed Critical Voice Genesis, Inc.
Priority to PCT/US2005/012844 priority Critical patent/WO2006112825A2/fr
Publication of WO2006112825A2 publication Critical patent/WO2006112825A2/fr
Publication of WO2006112825A3 publication Critical patent/WO2006112825A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/066—Format adaptation, e.g. format conversion or compression
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
    • H04L51/10—Multimedia information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
    • H04M1/72433—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for voice messaging, e.g. dictaphones
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M1/00—Substation equipment, e.g. for use by subscribers
    • H04M1/72—Mobile telephones; Cordless telephones, i.e. devices for establishing wireless links to base stations without route selection
    • H04M1/724—User interfaces specially adapted for cordless or mobile telephones
    • H04M1/72403—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality
    • H04M1/7243—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages
    • H04M1/72436—User interfaces specially adapted for cordless or mobile telephones with means for local support of applications that increase the functionality with interactive means for internal management of messages for text messaging, e.g. SMS or e-mail
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/58—Message adaptation for wireless communication

Definitions

  • the present invention relates generally to mobile communications devices and related software, and more particularly to mobile phones and handheld computers and associated messaging software therefor.
  • each device has certain advantages with respect to the others in the performance of specific tasks.
  • laptop computers although relatively bulky and difficult to transport, offer a user interface (i.e., display and keyboard) sized to facilitate visual and tactile interaction with the device. This suits the laptop to tasks such as reviewing and entering large amounts of textual information.
  • a PDA is essentially a smaller version of a laptop; while this facilitates transport of the device, the necessarily small size of the display and keyboard makes user manipulation cumbersome. As such, textual input with a PDA is commonly limited to shorter messages.
  • cellular phones offer a popular option for mobile communications.
  • cellular phones are optimized for audio communications, in certain situations, the ability to interact visually via text rather than by voice is desirable (for example, when reviewing lengthy messages or documents).
  • Modern cellular phones do often allow for textual communication by using the traditional 12-key phone keypad, but since several key presses can be required for basic letters, this is slow and only feasible for simple or isolated messages.
  • smart phones have allowed for the combination of cellular phone and PDA technology. These devices offer a lightweight option for communication by both voice and text.
  • the keyboards on these devices are still miniature and, as such, are more difficult and time consuming to use than full size computer keyboards.
  • a smart phone user is still confronted with the two non-ideal options for responding to textual messages: (i) using the awkward textual input interface or (ii) placing a phone call to a telephone number associated with the originator of the textual message.
  • smart phones fail to offer users the smaller size and lower prices common to mass market mobile phones.
  • the network connection serves only to send and receive messages and data that the user can manipulate locally.
  • the network connection serves to deliver the majority of the actual interface to the user.
  • the thin client approach can be advantageous in some cases, as it facilitates "distribution" of new software by requiring only an update to the server. After such an update the change is reflected in the interface sent to the thin client.
  • the thin client approach has the drawback of limiting "practical speed". This comes from the fact that, each time the user must manipulate some data by way of the underlying software, instructions must be sent to the distant server and the user must wait for the task to be completed and the product to be returned. This wait time can be significant due to network latency (often ranging from 3 to 15 seconds per user instruction, depending on a variety of factors). It should be noted that this delay will be seen, for example, each time the user changes screens. As such, these events are common and user delays can be significant.
  • the thin client approach has a second disadvantage.
  • Thin clients are dependent on a remote server not only for sending and receiving data, but to perform much of the processing required for data generation and manipulation. As such, thin clients are often not operational beyond the present screen at times when a network is unavailable.
  • thick client devices only require a network connection at isolated times in order to communicate, and at all other times can operate independently. This allows a thick client to be used at times when a network connection is inconvenient, expensive, or impossible, such as on airplanes or in isolated geographical areas.
  • the disclosure further allows a sender of a message to control message functions and destination via a voice- controlled interface.
  • Hazelaar does not allow simultaneous and complementary audio, visual, and tactile interaction at the end user location, and provides no mobile access to email. Further, the act of attaching sound files makes the resulting message platform specific.
  • Some companies have added voice portal functionality to Web email, making it possible for users to listen to their email and speak replies.
  • International Published Application No. WO 02/054746 Al to Ruotoisten-Maki incorporated herein by reference in its entirety, describes a speech user interface of a mobile station.
  • the mobile station is a so-called "thin client" which contains software that allows speech to be converted to electronic data to control the user interface.
  • the disclosure allows for the retrieval of textual messages through text-to-speech synthesis, allowing the content of textual messages to be heard.
  • Ruotoisten-Maki as with most voice portal approaches, has the disadvantage that an excessive length of time is required to listen to menu items to navigate the speech interface, to listen to a list of summaries of received message, and to listen to the synthesized text messages themselves, and this makes the service very inconvenient for most users. Users may only have the patience for such services when time is in abundance and visual interaction with the mobile station is undesirable, such as when operating a motor vehicle for extended periods.
  • Such a system should allow for visual display and tactile navigation of data and user options, as well as tactile data input.
  • Such a communication device should be a thick client device, such that the user delay in communicating and user dependence on an active network connection for system functionality are minimized. The thick client approach is optimal for devices using mobile communications networks that are known for variable reliability.
  • such a communication device should be capable of communicating wholly over a data channel of the network, in order to avoid simultaneous telephone network and data network communications costs and the network latency associated with connecting a phone call.
  • such a communication device should allow for an interaction between the various communications functions, such that a variety of messages can be sent to any recipient device. For example, such a communication device would allow response to an email message by either a voice message (sent to the email address) or a textual reply.
  • Such communications devices would merge the various communications functions into one unit, so that text, voice, and multimedia communications were all available.
  • Such a communication device is useable or adaptable for use with server technology in which the messaging architecture can handle message creation, receipt and response for any digitalizable message, in any format, via any popular messaging device, interface, or mode, that is received and delivered via any popular channel.
  • server application such a generic, multi- media, multi-channel, messaging (server application) architecture or system is disclosed in International Published Application No. WO 2004/095197 A2 commonly assigned with the present application.
  • a software package would be provided that, in addition to enabling the above, would include features such as the ability to access and download messages from external messaging accounts and the ability to synchronize with external messaging system. Further, such software would be available as an over-the-air downloadable application, thereby reducing delivery cost and providing nearly instant delivery of the product.
  • Such a mobile communication device, system, and software beneficially reduce network latency, improve efficiency, and in general reduce time to use as compared to prior devices, systems, and methodologies. Consequently, the mobile communication device, system, and the methodology embodied in such devices and systems have the beneficial effect of overall improvement in the speed of the functions and actions by a user of the mobile communication device as compared to prior art devices and systems.
  • the present invention features a mobile communications device for communicating with a server over a network, the device including a visual interface device that displays data, an audio interface device that receives acoustic input and converts the acoustic input to data, a network connection, a memory containing an applications program, and a processor operably coupled to the visual interface device, the audio interface device, and the memory, wherein the applications program is executed on the processor.
  • the applications program includes instructions, criteria and/ or code segments that locally generate graphical user interfaces with the visual interface and to control the input of data via the audio interface and the transmission of such data over the network to the server such that the data or instructions for data access are accessible to a recipient via a text-based application.
  • the mobile communications device further includes a tactile interface device for navigating data, the tactile interface device being operably coupled to the processor.
  • the applications program includes instructions, criteria and/ or code segments that allow for communicating via electronic mail.
  • the device more particularly the applications program, can be used to retrieve and visually review a listing of electronic mail messages with the visual interface device, to select a specific user-specified electronic mail message from the list to visualize with the tactile interface device, and to create a spoken response to the electronic mail message with the audio interface device for transmission and subsequent access and review via an electronic mail account.
  • the audio interface device receives data and converts the data to acoustic output.
  • the applications program also is arranged to receive data representing audio messages from a server and to play the received audio message(s) via the audio interface device.
  • the present invention also features a multimedia messaging system for communicating with a server, the server having an architecture including interface/connector subsystems that receive, process, and deliver messages that include metadata and whose content can be of different types delivered to and from devices and computer platforms of different types, over different channels, using different protocols and interfaces.
  • the system includes a mobile communication device that is operationally coupled to the server.
  • the mobile communication device includes a visual interface device that displays data, an audio interface device that receives acoustic input and converts the acoustic input to data, a network connection, a memory containing an applications program, and a processor operably coupled to the visual interface device, the audio interface device, and the memory, wherein the applications program is executed on the processor.
  • the applications program includes instructions, criteria and/or code segments that locally generates graphical user interfaces with the visual interface and controls the input of data via the audio interface and the transmission of such data over the network to the server such that the data or instructions for data access are accessible to a recipient via a text-based application.
  • the present invention further features a computer readable medium whose contents cause a mobile communications device to perform messaging with a remote communications device.
  • the mobile communications device includes an audio interface for converting an acoustic input to data representing the acoustic input and for converting data to acoustic output.
  • the remote communications device also includes an applications program with functions for messaging.
  • the contents of the computer readable medium includes code segments or the like as is known to those skilled in the art that cause such a mobile communications device to perform messaging by performing the steps of: generating graphical user interfaces in the mobile communications device by accessing instructions stored locally in the mobile communications device, storing locally in the mobile communications device data converted from acoustic input with the audio interface, transmitting the data representing acoustic input to a remote communications device via a data network such that the data or instructions for data access are accessible to a recipient via a text- based application.
  • the device of the subject invention can beneficially exploit newly-developed server technology, in which the messaging architecture is designed to handle message creation, receipt and response for any digitalizable message, in any format, via any popular messaging device, interface, or mode, that is received and delivered via any popular channel.
  • FIG. 1 shows a simulated cellular telephone in accordance with the subject invention
  • FIG. 2 shows the typical operating environment of a mobile communications device in accordance with the subject invention
  • FIG. 3 shows a block diagram that illustrates the process by which an exemplary embodiment of the client computer program functions in controlling communications between a mobile communications device and a server;
  • Figs. 4a-h show a progression of views representing the GUIs that would be visible to a user through the process of creating and sending a spoken email;
  • Fig. 5 shows a functional block diagram of the functional components of the client computer program
  • Fig. 6 shows a flowchart depicting a process that enables communication between a mobile communications device and a server
  • Fig. 7 shows a flowchart depicting the process steps undertaken by the client computer program in enabling a communications device-to-server request
  • FIG. 8 shows a flowchart depicting the process steps undertaken by the client computer program in enabling the retrieval of communications responses from a server;
  • Fig. 9 shows a flowchart depicting a process by which communication including the transfer of a voice file is enabled;
  • Fig. 10 shows a flowchart depicting the process steps undertaken by the client computer program in receiving from a server and processing XML- formatted Base64 encoded voice messages;
  • Fig. 1 1 shows a flowchart depicting the process steps undertaken by the client computer program in recording a voice message;
  • Fig. 12 shows a flowchart depicting the process of reviewing a received voice message as enabled by the client computer program
  • Fig. 13 shows a flowchart depicting the process of downloading the client computer program from the mobile communications device via a distribution network
  • Fig. 14 is a block diagram showing a messaging server application architecture particularly suited for use with the mobile communications device and software of Figs. 1-13;
  • Fig. 15 is a more detailed block diagram of the voice user interface gateway shown in Fig. 14;
  • Fig. 16 is a more detailed block diagram of the data gateway shown in
  • Fig. 14 illustrated to show pure HTTP and/or Web Service connections
  • FIG. 17 is more detailed block diagram of the messaging connector shown in Fig. 14; and,
  • Fig. 18 is a more detailed block diagram of the content transformer shown in Fig. 14.
  • Fig. 1 shows a cellular telephone or phone 10 configured in accordance with the present invention.
  • the cellular phone 10 is an exemplary vehicle for the present invention, however, the present invention is not limited to cellular phones, and is compatible with any conventional mobile communications device including a pager, PDA, handheld computer, smart phone, wearable computer, a laptop, or some other portable device as is known to those skilled in the art or hereinafter developed and adaptable for use with the present invention.
  • Phone 10 includes a memory in which is stored (locally) a client computer program (also called "client program” or "program”) 70 (Fig. 5).
  • client program also called "client program” or "program”
  • the memory can be of any variety appropriate for mobile electronics, such as read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), non-volatile random access memory (NVRAM), magnetizable media, combinations thereof, or other types of memory well known to those skilled in the art.
  • Phone 10 also has a processor for running the client computer program 70, the client computer program 70 controlling some functional aspects of device.
  • Phone 10 includes a visual interface 16, an audio interface 18, and a tactile interface 20 (e.g., buttons, keys, glide point, and the like), each existing in a control relationship with the client computer program 70 and allowing a user to interact with the phone 10 in a different manner.
  • the visual interface 16 allows for the display of GUI screens generated by the client computer program, the GUI allowing for the orderly visualization of data.
  • the visual interface is a liquid crystal display (LCD).
  • the audio interface 18 receives acoustic input and converts the input to electrical data that can then be operated on by the client computer program 70.
  • Audio interface 18, for example could be a microphone that converts speech into a binary sound file.
  • audio interface 18 also includes a speaker that allows the user to hear received voice messages and other audio information.
  • the tactile interface 20 includes a keypad 21 for use with program 70 and provides a mechanism for a user to manually input data into the phone 10.
  • the tactile interface 20 also includes navigational keys 22 that work in conjunction with the visual interface 16 to allow a user to navigate between and select options made available by program 70 and displayed on the visual interface 16.
  • the navigational keys 22 include an "UP” directional key 23, a “DOWN” directional key 24, a "LEFT” directional key 25, a "RIGHT” directional key 26, and an "OK” navigational key 27, as well as soft keys 28, 29, and dedicated "SEND” 30, 11 CLR” (representing "clear") 31, and "END” 32 buttons.
  • buttons 30-32 make commonly used options to be readily available to a user, e.g., in ending an ongoing process with the END button 32.
  • Phone 10 also includes a network connection device (not shown).
  • the network connection device is a wireless connection device such that the phone 10 does not need to be physically connected to a network to communicate.
  • the network connection allows phone 10 to connect to a network 40, as illustrated in Fig. 2.
  • the network 40 is a data network using the Hypertext Transfer Protocol (HTTP) over transfer control protocol/internet protocol (TCP/IP).
  • HTTP Hypertext Transfer Protocol
  • TCP/IP transfer control protocol/internet protocol
  • servers 50 such that the network 40 provides a communications path between phone 10 and server 50, i.e., provides a path for the bi-directional transmission of data.
  • the server 50 supports the use of extensible markup language (XML)-based protocol.
  • XML extensible markup language
  • HDML Handheld Devices Markup Language
  • WML Wireless Markup Language I
  • cHTML compact HyperText Markup Language
  • J2ME Java 2 Micro Edition
  • XHTML Extensible HyperText Markup Language
  • Fig. 1 when referring to the visual interface 16, audio interface 18, tactile interface 20, keypad 21, navigational keys 22, directional keys 23-26, OK key 27, soft keys 28, 29, dedicated SEND button 30, CLR button 31 , and END button 32.
  • Fig. 2 when referring to the mobile communications device or phone 10, the network 40, or the server 50.
  • references to figures not containing those numerals implicitly refer to Fig. 2.
  • FIG. 3 there is shown a block diagram that illustrates the process by which an exemplary embodiment of the client computer program 70 functions in controlling communications.
  • Program 70 initiates communications by transmitting a request for data to the server 50 (step 92). This request is made over the network 40 that is, for example, a data network.
  • the server 50 sends data, and those data are received by the program 70 (step 93).
  • the program 70 generates a GUI so that the data can be visualized and processed by a user (step 94).
  • the user instructs program 70 that data are to be generated acoustically by the user and made available to a recipient using a text-based application (step 95).
  • Program 70 controls the input of acoustic data by the user (for example, by alerting the user as to when such input may be made) (step 96), and receives and stores data representing that input (step 97). Finally, the stored data are transmitted to the server 50 over the network 40 for access by a recipient.
  • the recipient uses a text-based application (e.g., email) to access the data or instructions for retrieving the data.
  • the communications between a mobile communications device 10 and a server 50 can take.
  • the communications may consist of sending information (such as messages) for storage or further processing at the server 50.
  • the server 50 contains data regarding email messages, voice messages, multimedia messages, and other forms of information, and the mobile communications device 10 is used to retrieve that information.
  • the client computer program 70 enables both types of communications. Specifically, a cellular phone 10 running program 70 allows a user to connect to network 40 and retrieve email messages from server 50. Those messages are then displayed in textual format on the visual interface 16, by way of a GUI generated by program 70.
  • the user by using the tactile interface 20, can navigate the displayed list of messages in the GUI and select individual messages to read, forward, delete, etc.
  • the audio interface 18 allows for a spoken message to be recorded by program 70 as a data file.
  • the data file is subsequently transmitted over the network 40 by program 70 to be accessed by the user of an email account via that account.
  • the data file representing the spoken message is a binary data file.
  • Figs. 4a-h one specific category of communications between phone 10 and server 50 is the creation of email at phone 10 to be sent to an email account.
  • the figures also illustrate exemplary GUI menus being displayed and the steps taken in generating a spoken email message.
  • the user navigates an introductory menu (Fig. 4a), using the UP and DOWN keys 23, 24 to scroll to the entry "Speak Email" and the OK key 27 to choose this option.
  • This action prompts a GUI screen related to addressing the message, and allows the user to choose to select the message destination information from a list of contacts stored in the device (Fig. 4b), such as, for example, in an address book stored in the memory, or to type/manually input address information using the keypad 21.
  • the email address to which the message will be sent is displayed in the GUI (Fig. 4c).
  • the user is given the option of changing the default subject for the message.
  • a "Record Voice" GUI screen is displayed (Fig. 4d), allowing the user to use the navigational keys 22 to choose "Start Recording".
  • the client computer program 70 calculates a duration limit (e.g. , a maximum duration) for the voice message and causes the calculated duration limit to be displayed with a GUI. Once this option is chosen, a GUI will alert the user that the device is recording (Fig. 4e).
  • Such recording is stopped by action of the user again by using the navigational keys 22 to choose an option displayed on the GUI.
  • recording is automatically stopped after it is determined that the calculated duration for the voice message is reached.
  • the "Recording Finished" GUI screen is displayed (Fig. 4f). This GUI allows the user to send the message to the specified address or addresses, to review the recorded message, or to re-record the message.
  • GUI screen alerts the user that the message is being transmitted (Fig. 4g).
  • the client computer program 70 takes the appropriate actions and functions so as to cause the message (e.g., in the form of the data file) to be transmitted, for example, to the server 50. If transmission is successful (e.g., a message is received from the server 50 acknowledging receipt of message), another GUI screen is displayed that informs the ⁇ user that the message has been sent, and provides options for proceeding (Fig. 4h). If the network connection is interrupted during transmission such that the message is not successfully sent, then another GUI screen is displayed that alerts the user to the error and provides an opportunity for the user to re-transmit the message.
  • Another specific category of communications between phone 10 and server 50 is the creation and sending of text messages from the phone 10 to the server 50.
  • the user navigates an introductory menu (Fig. 4a), using the directional keys 23-26 to scroll to the entry "Type Email" and the OK key 27 to choose this option.
  • This action prompts the display of a GUI screen related to addressing the message, and allows the user to choose from a list or input the message destination information.
  • the email address to which the message will be sent is displayed in another GUI screen.
  • the user is given the option of typing the subject for the message. The user then is alerted that the message can be inputted, for example by displaying another GUI screen.
  • another GUI screen is displayed that allows the user to send the message to the specified email address.
  • the GUI can be arranged so the user also can cancel the message.
  • another GUI alerts the user that the message is being transmitted.
  • the client computer program 70 also takes the appropriate actions and functions so as to cause the text message (e.g., in the form of the data file) to be transmitted, for example, to the server 50.
  • Another GUI is displayed informing the user that the message has been sent, and can provide options for proceeding. If the network connection is interrupted during transmission or the text message is otherwise not successfully sent, then another GUI is displayed that alerts the user to the error and provides an opportunity for the user to re-transmit the text message.
  • Yet another specific category of communications between phone 10 and server 50 is the process by which the user can retrieve a list of messages to the phone 10 from the server 50. As with the process described above, the user navigates an introductory menu (Fig. 4a), using the directional keys 23-26 to scroll to the entry "Inbox" and the OK key 27 to choose this option.
  • a message/request is then outputted by the mobile communication device/phone 10 to the server 50, responsive to this prompt/action of the user.
  • the message/request solicits the desired information contained in the folder ⁇ i.e., Inbox) for the targeted or requesting user/email address.
  • the mobile communication device 10 also determines available RAM and storage and communicates this information with the message to the server 50.
  • the client computer program 70 also takes the appropriate actions and functions necessary to cause the message to be transmitted to the server 50. Thereafter, the server 50 responsive to this request returns the requested information to the mobile communication device/phone 10 which is in turn stored in the memory or phone storage area.
  • server transmission is successful (e.g., a message list is received from the server 50)
  • another GUI is displayed informing the user that the message list has been received and stored sent in the phone. If the transmission of the information or subsequent storage of the message list is otherwise not successfully sent, then another GUI is displayed that alerts the user to the error and provides an opportunity for the user to re-transmit the request.
  • the user can take the appropriate actions to cause such information to be displayed.
  • the user can choose or select a message appearing in the Inbox list.
  • a message/request is then outputted by the mobile communication device/phone 10 to the server 50; which requests the server to transit the requested email message from the appropriate folder for the targeted or requesting user/email address.
  • the mobile communication device 10 also determines available RAM and storage and communicates this information with the message to the server 50.
  • the client computer program 70 also takes the appropriate actions and functions necessary to cause the message/request to be transmitted to the server 50.
  • the server 50 responsive to this request, returns the requested information to the mobile communication device/phone 10 which is in turn stored in the memory or phone storage area.
  • the client computer program 70 determines if the retrieved message is a text message, a text and voice message, or a voice-only message. Thereafter the appropriate actions are taken so that the message, in whatever form it is in, is provided to the user.
  • Yet another specific category of communications between phone 10 and server 50 is the process by which the user can retrieve or import a database, such as contact database, to the phone 10 from the server 50.
  • a database such as contact database
  • the user navigates an introductory menu (Fig. 4a), using the directional keys 23-26 to scroll to the entry "Address Book” and the OK key 27 to choose this option.
  • a message/request is then outputted by the mobile communication device/phone 10 to the server 50, responsive to this prompt/action of the user.
  • the message/request solicits the desired database for the targeted or requesting user/email address.
  • the mobile communication device 10 also determines available RAM and storage and communicates this information with the message to the server 50.
  • the client computer program 70 also takes the appropriate actions and functions necessary to cause the message to be transmitted to the server 50. Thereafter, the server 50, responsive to this request, returns the requested database/contact database to the mobile communication device/phone 10 and stores it. Following receipt of the database, the client computer program 70 deletes the existing database, if any.
  • Yet another specific category of communications between phone 10 and server 50 is the process by which settings, such as the user's account settings, are created, changed and updated between the mobile communication device/phone 10 and the server 50.
  • the user's account settings are stored in a local database on the phone 10.
  • the following process is used when the user decides to update settings, such as the account settings, which are stored on both the mobile communication device/phone 10 and the server 50.
  • the user navigates an introductory menu (Fig. 4a), using the directional keys 23-26 to scroll to the entry "Settings " and the OK key 27 to choose this option.
  • a GUI is then presented that allows the user to view, add, change, delete, or import settings.
  • a message/request is then outputted by the mobile communication device/phone 10 to the server 50, responsive to this prompt/action of the user.
  • This message/request solicits the desired information or database/settings database information for the targeted or requesting user/email address.
  • the mobile communication device 10 also determines available RAM and storage and communicates this information with the ) message to the server 50.
  • the client computer program 70 also takes the appropriate actions and functions necessary to cause the message to be transmitted to the server 50. Thereafter, the server 50 responds to the request as appropriate and returns the appropriate information to the phone 10 to be stored in the appropriate location/database.
  • server transmission is successful (e.g., a message is received from the server 50)
  • another GUI is displayed informing the user that the message has been received and stored sent in the phone. If the transmission of the information or subsequent storage of the message is otherwise not successfully sent, then another GUI is displayed that alerts the user to the error and provides an opportunity for the user to re-transmit the request. As this information is present/stored in the phone 10, the user can take the appropriate actions to cause such information to be displayed.
  • the method allows for visual review of lists of data (such as a list of pending email messages) and the prioritization of individual items within the list for attention. This is a significant improvement over systems in which an entire list must be thoroughly reviewed in the order it is presented (e.g., as is the case with "voice portals" for message retrieval). Further, the method allows a user to visually review the contents of a message, which is both quick and accurate. Additionally, responding by voice allows a user to avoid the need to input large amounts of text on a small and awkward tactile interface (e.g., a keypad on a conventional cellular phone). At the same time, because spoken messages are recorded as data files, a user is not prohibited from transmitting responses to email accounts simply because the response is given in spoken form.
  • users of email accounts can access the messages in spoken form from their email account.
  • the ability to record a spoken message in its entirety before it is transmitted to the server i.e., the ability to "store and forward" allows the user to review the message for accuracy and also greatly increasing the likelihood that the message is transmitted without being distorted (e.g., truncated) by network unavailability.
  • FIG. 5 there is illustrated a block diagram that schematically shows the functional components of an exemplary embodiment of the client computer program 70 according to the present invention.
  • Program 70 generally separates its functions between the User Interface (UI) Module 72, the Transport Module 74, the XML Builder (XMLB) Module 76, and the XML Processor (XMLP) Module 78.
  • the UI Module 72 is responsible for the display of GUIs that enable user interaction and for invoking other portions of the program 70 based on those interactions.
  • the mobile communications device 10 on which program 70 is running is a mobile phone; the UI Module 72 then utilizes the software development kit (SDK) typically included with the mobile phone to generate the GUIs.
  • SDK software development kit
  • the Transport Module 74 governs interactions between the communications device 10 and the server 50.
  • the XMLB and XMLP Modules 76, 78 prepare requests to be sent to the server 50 in XML format and parse XML responses from the server 50 to be operated on by the other modules, respectively.
  • FIG. 6 illustrates a flowchart 100 depicting a process by which communication is enabled between a mobile communications device 10 and a server 50, in accordance with an embodiment of the present invention.
  • the UI Module 72 accepts an instruction entered by a user; this serves to initiate communication.
  • this instruction is entered using an interface 16, 18, 20 of the communications device 10, based on options displayed in a GUI.
  • a specific function is invoked within the Transport Module 74 in response to this instruction.
  • Transport Module 74 establishes communication with the server 50 (e.g., HTTP communication over a cellular phone carrier network 142 and over the Internet 144).
  • step 140 in which a specific request is sent to the server 50.
  • the server 50 processes the request received from the Transport Module 74. In cases where data are simply being sent to the server 50 for storage or disposition, this completes the communication process.
  • a request to the server 50 will require data to be returned to the user.
  • the server 50 generates a response and returns the response in the form of the requested data, which travel over network 40 to the mobile communications device 10 [e.g., over an HTTP channel of the appropriate cellular phone carrier network 142 and over the Internet 144).
  • the Transport Module 74 receives the response from the server 50.
  • the Transport Module 74 invokes a callback function in the UI Module 72 to pass on the data returned from the server 50.
  • the UI Module 72 displays the data in a manner appropriate for review by the user, thereby completing the process.
  • such data might consist of aperies of email messages and be displayed as a list (e.g., email Inbox list) so as to allow a user to review sender information, individual messages a contact database for database updating purposes and the like.
  • the Transport Module 74 also forwards information concerning the amount of free RAM/ storage to the server and the server in turns determines an amount of information that can be sent back based on the received information.
  • the returned data are a database update, such as for example an update to the contact database
  • the client computer program causes the existing database to be deleted and replaced with the updated database.
  • Fig. 7 illustrates a flowchart 200 depicting the process steps undertaken by the client computer program 70 in enabling the communications device-to-server request shown in Fig. 6 and described herein.
  • the UI Module 72 receives a user instruction and invokes a specific function in the Transport Module 74. For example, in a particular instance, the UI Module 72 instructs the Transport Module 74 that a message is to be sent to the server 50.
  • the Transport Module 74 invokes the XMLB Module 76.
  • the XMLB Module 76 composes an XML request corresponding to the user instruction.
  • the XML request is returned from the XMLB Module 76 to the Transport Module 74.
  • the XML request now formatted to be accepted by the server 50, is sent by the Transport Module 74 to the server 50.
  • the Transport Module 74 uses the "ISHELL_CreateInstance()" and "ISOURCEUTIL PeekFromMemoryO" functions to prepare the XML-based request for transmission to the server 50.
  • the Transport Module 74 further invokes the "CALLBACKJnitO" function included in BREW ® to prepare a call-back function for receiving the response from the server 50.
  • the Transport Module 74 invokes the "IWEB_GetResponse()" function, which initiates the connection to the server 50 and transmits the request.
  • Fig. 8 shows a flowchart 300 depicting the process steps undertaken by the client computer program 70 in enabling the retrieval of responses from the server 50 as shown in Fig. 6 and described herein.
  • the Transport Module 74 receives an XML response from the server 50. This response includes the result for successful processing of a user's request (or, it will contain an error message if the processing of the request was unsuccessful).
  • the XML response is sent to the XMLP Module 78 to build the appropriate data structures for later manipulation by the other modules. The building of the data structures is governed by the content of the response from the server 50.
  • the Transport Module 74 invokes the callback function of the UI Module 72 to allow passing on the data structures to the UI Module 72.
  • the UI Module 72 displays the data in a manner appropriate for review by the user.
  • the Transport Module 74 completes its communication with the server 50 in a single round-trip. This is not the case, however, when data representing a recorded voice message (i.e., "voice data") are included in the data file being transferred to the server 50; such a file is sometimes referred to as a "voice file”.
  • a flowchart 400 depicting an exemplary process by which communication including the transfer of a voice file is enabled by program 70.
  • the UI Module 72 invokes a specific function within the Transport Module 74 in response to a user instruction.
  • the Transport Module 74 invokes the XMLB Module 76.
  • the XMLB Module 76 composes a request (e.g., in XML) corresponding to the user instruction, which is returned to the Transport Module 74 at step 408.
  • the Transport Module 74 establishes communication with the server 50 (e.g., over an HTTP channel of the appropriate cellular phone carrier network 401 and over the Internet 403).
  • step 412 in which a specific request is sent to the server 50 via a data channel.
  • the server 50 processes the request received from the Transport Module 74.
  • the server 50 generates a response that travels over the network 40 (e.g., an HTTP channel of the of the appropriate cellular phone carrier network 401 and over the Internet 403) and is received at step 418 by the mobile communications device 10 and at step 420 by the Transport Module 74.
  • the response from the server 50 includes a uniform resource locator (URL) that is subsequently utilized to store the recorded voice message.
  • the Transport Module 74 parses the response from the server to retrieve the destination URL information.
  • the Transport Module 74 again establishes communication with the server 50 (e.g., via an HTTP channel of the of the appropriate cellular phone carrier network 401 and over the Internet 403).
  • the Transport Module 74 transmits a voice file to the server 50 using a data channel, such use often having attendant speed and cost advantages with respect to a voice channel as known to those skilled in the art.
  • the server 50 processes the data sent by the Transport Module 74 ' and stores the voice file.
  • the above process for sending voice files has several advantages. Specifically, a user can record a voice message in binary format and transmit the binary file without the need to transform the file, thereby saving time.
  • a user of a mobile communications device 10 configured in accordance with the subject invention may also receive voice messages from another user of a similar mobile communications device.
  • Fig. 10 there is illustrated a flowchart 500 depicting the process steps undertaken by the client computer program 70 in enabling the retrieval of XML-formatted, encoded voice files stored on server 50.
  • the Transport Module 74 downloads the XML data file from the server 50 (i.e., receives and stores the file locally within the mobile communications device 10).
  • the file includes header information that allows the portion containing the encoded binary voice data to be separated from the rest of the file.
  • the encoded binary voice data are extracted by the Transport Module 74, the extraction being enabled by the header information.
  • the encoded binary voice data are decoded by the Transport Module 74 as the voice data are extracted, and at step 540 the decoded data are stored to as a sound file in the memory of device 10.
  • the Transport Module 74 checks to see if there are more of the voice data to be extracted and decoded. If there are, the Transport Module 74 will repeat steps 520, 530, and 540 until all the voice data are completely decoded. When all the voice data have been decoded, the Transport Module 74 proceeds to step 560 to notify the UI Module 72, via a callback function, that a voice message is received.
  • the UI Module 72 displays an appropriate GUI to the user, who can use the options in the GUI to play the stored sound file.
  • the sound file can be listened to by a user, in much the same way that conventional voice messages are audibly reviewed via telephone.
  • the sound file has arrived via an email account.
  • the described method for receiving voice files in which encoded binary data are formatted in another language for transmission and extracted upon receipt, is generally useful for receiving and processing large files.
  • this scheme can be used for downloading large data files containing contact information.
  • the above process for receiving voice files has several advantages. Specifically, when the voice files being received contain encoded (e.g., Base64 encoded) binary data representing sound, those encoded data being embedded in an alternative format (e.g., XML-based), the ability to separate the encoded portion from other portions of the file obviates the need to parse the entire file, thereby saving time. This is also desirable when the memory available for locally storing such files is limited (as is often the case in mobile communication devices), as it reduces the need to create redundant copies of the involved files. Memory demands are further reduced by decoding the voice message as it is being extracted, further obviating the need for extra file copies.
  • encoded e.g., Base64 encoded
  • an alternative format e.g., XML-based
  • a device configured in accordance with the subject invention is capable of operating independently, without need for an active connection with a server.
  • the client computer program 70 locally provides all of the capabilities necessary to compose text and voice based messages, generate GUIs for displaying and playing downloaded text messages and voice messages, respectively, and for processing user inputs via the interfaces.
  • downloaded text messages are stored as text files and downloaded voice messages are stored as binary voice files.
  • the UI Module opens the message file, constructing an appropriate GUI.
  • a network connection is needed only to send and receive data to/from a server, but not to operate on those data. As such, network connection is only needed at isolated intervals, and much communications device use can take place without a network available (i.e., the device is a thick client).
  • a flowchart 600 depicting the process steps undertaken by the client computer program 70 in recording a voice message.
  • the process begins in step 610, wherein the user selects the proper menu item from a list displayed in a GUI to compose a voice message (Fig. 4a).
  • the UI Module 72 will alert the user that recording has started.
  • the user records a spoken message.
  • the recorded message is stored as a sound file in the memory of the mobile communications device 10.
  • the client computer program 70 allows the receipt of voice messages from standard or cellular telephones. Further, the client computer program 70 also allows for voice messages sent to email accounts by other cellular telephones likewise equipped with the program 70 to be received and played as sound, and similarly to be responded to with voice messages. These actions are also governed by GUIs generated by the UI Module 72 of the client computer program 70. Referring to Fig. 12, there is illustrated a flowchart 700 depicting the process of reviewing a voice message received via an email account from a cellular phone running program 70.
  • the UI Module 72 displays a GUI that allows a user to choose to listen to a received voice message.
  • the user selects the appropriate menu item from the GUI to play the voice message.
  • the user is given the option to replay the message.
  • the client computer program 70 is based on the BREW ® (Binary Run-time Environment for Wireless) software development platform available from QUALCOMM, Inc. of San Diego, CA.
  • BREW Binary Run-time Environment for Wireless
  • the BDS can be accessed through various carriers, such as Verizon Wireless of Bedminster, NJ.
  • another advantage of the present invention is that the program 70 that controls the messaging functions of this invention can be downloaded to an existing device (e.g., a conventional cellular phone as shown in Fig. 1) to upgrade its functionality.
  • FIG. 13 there is illustrated a flowchart 800 depicting an exemplary process by which the client computer program 70 is downloaded to a mobile communications device 10 via the BDS.
  • the user selects the client computer program 70 from a GUI listing applications available to be downloaded via the BDS.
  • the request is sent to the server via a cellular phone carrier network 801.
  • the client computer program 70 is transmitted over the BDS (via the cellular phone carrier network 801) to the mobile communications device 10, where, at step 840, the program 70 is received and stored in the memory.
  • the process is concluded and the client computer program 70 is available for use with the mobile communications device 10.
  • omnimodal servers are those in which the server system architecture can handle message creation, receipt and response for any digitalizable message, in any format, via any popular messaging device, interface, or mode, that is received and delivered via any popular channel.
  • server system architecture 10 is shown in overview in Fig. 14, and is designed to handle message creation, receipt, and response for any sort of digitizable message in any format, including, but not limited to, voicemail, email, short text (Short Message Service (SMS)), Multimedia
  • MMS Multimedia Subsystem
  • instant messages via any popular end user messaging device (phone, mobile phone, handheld computer, desktop/laptop computer, fax machine, converged devices), via any popular interface (Wireless Application Protocol (WAP) browser, voice interface, WAP/voice, SMS client, MMS client, Java client, BREW ® (Binary Run-time Environment for Wireless) client, web browser, thick IM client, etc.), in any mode (text, audio, still image, moving images, or combination thereof), and received or delivered via any popular channel (Public Switched Telephone Network (PSTN), the Internet, etc.).
  • PSTN Public Switched Telephone Network
  • the omnimodal messaging system typically operates as a "core application and application infrastructure" in a communications network or networks in the multiple sender, receiver and user modes of the same or varying design and operational characteristics.
  • the messaging architecture 910 is assembled through machine-to-machine and/or human-to-machine interfaces.
  • This generic or universal messaging system 910 termed herein as "omnimodal", uses a multi-media messaging server application architecture organized using a set of eight loosely-coupled subsystems.
  • Interface/Connector Subsystems 911 (including the Voice User Interface Gateway 912, Data Gateway 914, Multimedia Gateway 916, and Message Connectors 918), Core Subsystems 919 (including Multimedia Messaging Bus 920, Metadata Messaging Bus 922, and Content Transformer 924), and Storage Subsystems 926.
  • the first four of these subsystems 912-918 are interface/connector subsystems. They all interact with the world external to the application. They support all the interfaces. They also manage connections to external telecommunications and data networks as well as to external messaging systems. They are responsible for sending and receiving any popular kind of message in any popular mode for any popular device, as detailed above.
  • the next three subsystems 920, 922, 924 can be thought of as the brains or core of the architecture. They extract message metadata (data about messages), including message type, format, mode of creation, address, originating device, subscriber, etc. They combine this metadata with information about the delivery and routing of the message provided by the networking infrastructure, information encapsulated in the user preferences and the user registry, as well as with instructions on how to process the message and the Metamessage itself. All these elements are contained within an element termed the "Metamessage” (Metamessage is "reflective").
  • the Metamessage is processed to determine what the system must do to deliver the original message; what content transformations (if any) need to be performed on the original message; what formats and interfaces will be used to deliver the original message.
  • Original or transformed parts of the original message and/or a forerunner message may then be sent to external facing subsystems that then handle delivery.
  • the last set of subsystems, the Storage Subsystems 926, store all of the information used by the system, namely the messages themselves, Metamessages, subscriber preferences, registry data, etc.
  • the architecture 910 handles any format, and avoids any architectural commitments that rely on format commonalties.
  • the resulting architecture can be termed "format independent.”
  • the core subsystems reduce any message to two sets of data - the message and data about the message.
  • the only assumption relied upon by the architecture is that all messages can be reduced to binary data.
  • the Content Transformer 924 includes algorithms for converting message formats.
  • this subsystem 912 enables reception of any type of voice message through voice-specific channels 930 such as PSTN, IP telephony, packet-switched telephony, and other cellular telephony of which three representative channels are illustrated.
  • the Voice Gateway 912 is an entry point that accommodates all of the different methods of connecting to the voice user interface, and makes all voice related interactions with the system appear the same to the rest of the system.
  • the Voice Gateway 912 enables the other components of the system to treat voice without the concern for how the voice was obtained, or what format it is in.
  • the - Voice Gateway 912 itself is rendered with standards-compliant VoiceXML, thereby adhering to the Extensible Markup Language (XML) mandate of the architecture.
  • XML Extensible Markup Language
  • the Voice Gateway 912 includes functionality that enables it to synchronize multi-part messages that have one or more types of content. Since the Voice Gateway 912 is only designed to handle the voice portion of the content, through any voice channel, it will use a synchronization mechanism 932 (SMIL — Synchronized Multimedia Integration Language —compliant) to work with the Data Gateway 914, the Multimedia Messaging Bus 920, and other components in the system 910. [0085] Much of the interaction between outside systems 934 (shown in Fig. 16 as three representative such systems 934) and the system 910 is done through the Data Gateway 914. The Data Gateway 914 also handles connections for subscribers. The specific subscriber interfaces are rendered, by proxy, through the Content Transformer 924 and then sent out through the Data Gateway 914.
  • SMIL Synchronized Multimedia Integration Language
  • the Data Gateway enables reception of any type of data message through data specific channels 936 such as HTTP/XML, W-HTTP, i-mode, and BREW.
  • the data gateway 914 offers access to the system 910 through various web service types including Simple Object Access Protocol (SOAP) 936a and Xforms 936b.
  • SOAP 936a allows external applications to communicate with the data gateway independent of the computer platform.
  • SOAP 936a can be thought of as an XML schema for remote procedure calls, like message retrieval.
  • XForms enables rendering of generic interfaces.
  • XForms interfaces can be transformed to specific user interface types at the node. In this way carriers can render proprietary subscriber interfaces that have pre-built interaction sets with the application.
  • XSLTs Extensible Stylesheet Language Transformations
  • XForms 936b is a World Wide Web Consortium (W3C) standard.
  • SOAP and XForms the application optimizes connectivity options for users of the architecture 910. The end result is an application that is more flexible and less costly to deploy than anything now available.
  • the subsystem 916 serves the same general function as the Data Gateway 914, but is designed to receive/send any type of multimedia file or message format such as MMS, Moving Picture Experts Group (MPEG), MPEG-4, MPEG-7, FLIC, Audio Visual Interleaved (AVI), QuickTime Movie (MOV), Artificially Structured Films (ASF), Macromedia Flash, etc.
  • MMS Moving Picture Experts Group
  • MPEG Moving Picture Experts Group
  • MPEG-4 MPEG-4
  • MPEG-7 MPEG-7
  • FLIC Audio Visual Interleaved
  • AVI Audio Visual Interleaved
  • MOV QuickTime Movie
  • AF Artificially Structured Films
  • Macromedia Flash etc.
  • the subsystem 918 shown in Fig. 17 is designed to connect with external messaging systems such as Simple Mail Transfer Protocol (SMTP), Post Office Protocol (POP), Internet Messaging Access Protocol (IMAP), Short Message Service Center (SMSC), and Multimedia Messaging Service Center (MMSC).
  • SMTP Simple Mail Transfer Protocol
  • POP Post Office Protocol
  • IMAP Internet Messaging Access Protocol
  • SMSSC Short Message Service Center
  • MMSC Multimedia Messaging Service Center
  • the Multimedia Messaging Bus 920 allows different types of media to be put in a queue and then processed. It solves several different requirements. First, it allows coordinated access to all of the contents of the message (regardless of what type of content is inside the message) by different processing subsystems (Content Transformer 924, Storage Subsystem 926, etc.). Second, it provides this access in a scalable and asynchronous manner. As a result spikes in message traffic do not cause the system 910 to halt. Finally, it permits the content of the message to be retrieved at run-time while the information about the message (on the Metadata Messaging Bus 922) is replicated to all of the different nodes on a distributed network.
  • the Metadata Messaging Bus 922 transports Metamessages (as defined above) between subsystems, so subsystems can coordinate to process messages. In order to provide a decoupling between messages and information about the messages, the Metadata Messaging Bus 922 creates Metamessages that contain data about the original messages. The Metamessages are themselves provided as messages on a queue. This enables the clients of the Multimedia Message Bus 922 to know needed information about the messages prior to actually processing the messages. This approach provides tunable performance and scalability.
  • the subsystem 924 shown in detail in Fig. 18 transforms any popular message format into any other popular message format to facilitate message creation and delivery via any popular format, interface, device, mode, or channel.
  • content transformation is done asynchronously, that is, on a deferred basis. This approach lessens the performance and scalability requirements inherent to synchronous systems. Transformation appears to be synchronous to the extent that processing resources are available. In other words, while the server system in its present preferred form operates asynchronously, that asynchronous operation can appear to be synchronous, e.g., if there is no queuing on the buses 920 and 922.
  • Transformable content includes any combination of text, still images, audio, and moving images. Because messages may include any combination of these content modes, the total number of combinations is twenty-four on both the sending and receiving side. These modes each contain multiple formats that must be supported.
  • the set of subsystems 926 handles storage of the various content pieces of stored messages.
  • the messages and parts of messages, whether text, still images, audio, and/or moving images, must be stored.
  • These subsystems will be comprised of several off the shelf components amongst which the most important are:
  • Text Message Storage The database 926a will be used to store the message metadata to facilitate searches, queries, and data mining. The database 926a may also be used to store the text portion of messages.
  • File Storage The multimedia or voice files are stored in their native format in a file storage systems 926c and 926b, respectively, and then be processed by the Content Transformer 924 to be played back to the user. The Content Transformer 924 can also write back to the Storage Subsystems 926 to use them as a caching mechanism, or to provide different types of file formats. There are a variety of file formats each of which may require a particular type of storage ' as the system scales. Several standard compression methods are used to facilitate storage of various formats.
  • LDAP Lightweight Directory Access Protocol
  • JNDI Java Naming and Directory Interface
  • the subsystems 926 can be considered as a single storage subsystem with sub-subsystems associated with various message types, and one or more sub- subsystem for message management and retrieval. *
  • omnimodal server has been described with respect to its preferred embodiments, it will be understood that other numbers of subsystems can be used intercommunicating through other bus architectures besides two parallel buses that open multi-media messages and Metamessages.
  • One or more digital data processing devices can be used in connection with various embodiments of the invention.
  • a device generally can be a personal computer, computer workstation, laptop computer, server computer, mainframe computer, handheld device (e.g., personal digital assistants, handheld computers, smart phones, and cellular telephones), information appliance, or any other type of generic or special-purpose, processor-controlled device capable of receiving, processing, displaying, and/or transmitting digital data.
  • a processor generally is logic circuitry that responds to and processes instructions that drive a digital data processing device and can include, without limitation, a central processing unit, an arithmetic logic unit, an application specific integrated circuit, a task engine, and/or any combinations, arrangements, or multiples thereof.
  • Software, programs, or code generally refers to computer instructions which, when executed on one or more digital data processing devices, cause interactions with operating parameters, sequence data/parameters, database entries, network connection parameters/data, variables, constants, software libraries, and/or any other elements needed for the proper execution of the instructions, within an execution environment in memory of the digital data processing device(s).
  • Those of ordinary skill will recognize that the software and various processes discussed herein are merely exemplary of the functionality performed by the disclosed technology and thus such processes and/or their equivalents may be implemented in commercial embodiments in various combinations and quantities without materially affecting the operation of the disclosed technology.
  • a network can be a series of network nodes (each node being a digital data processing device, for example) that can be interconnected by network devices and communication lines (e.g., public carrier lines, private lines, satellite lines, etc.) that enable the network nodes to communicate.
  • network devices e.g., public carrier lines, private lines, satellite lines, etc.
  • the transfer of data (e.g., messages) between network nodes can be facilitated by network devices such as routers, switches, multiplexers, bridges, gateways, etc.
  • the invention has been mainly described as operating wholly on a data network using the standard HTTP.
  • the present invention is usable or adaptable for use with other networks, the other network types being known to those skilled in the art and including, but not limited to: public switched telephone networks (PSTN), mobile telephone networks either with or without 1 x Radio Transmission Technology (IxRTT) networks, IxRTT "evolution data only” (EVDO) networks, Global System for Mobile Communications (GSM) networks, General Packet Radio Service (GPRS) networks, GSM “Enhanced Data GSM Environment” (GSM EDGE) networks, Code- Division Multiple Access (CDMA) networks, Wideband CDMA (WCDMA) networks, CDMA2000 networks, 802.11 networking (i.e., "WiFi”), and public data networks such as the Internet.
  • PSTN public switched telephone networks
  • IxRTT IxRTT "evolution data only”
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • GSM EDGE GSM "Enhanced Data GSM Environment”
  • CDMA Code- Division Multiple Access
  • WCDMA Wideband CDMA
  • FIG. 1 Several of the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor, microprocessor, mobile communications device, or server.
  • FIG. 1 Several of the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor, microprocessor, mobile communications device, or server.
  • FIG. 1 Several of the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor, microprocessor, mobile communications device, or server.
  • FIG. 1 Several of the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor, microprocessor, mobile communications device, or server.
  • FIG. 1 Several of the flow charts herein illustrate the structure or the logic of the present invention as embodied in computer program software for execution on a computer, digital processor, microprocessor, mobile communications device
  • the illustrated embodiments can be understood as providing exemplary features of varying detail of certain embodiments, and therefore, unless otherwise specified, features, components, modules, elements, and/or aspects of the illustrations can be otherwise combined, interconnected, sequenced, separated, interchanged, positioned, and/or rearranged without materially departing from the disclosed systems or methods. Additionally, the shapes and sizes of components are also exemplary and unless otherwise specified, can be altered without materially affecting or limiting the disclosed technology.

Abstract

Un dispositif de communications mobiles pour communiquer avec un serveur via un réseau, incluant un dispositif d'interface visuelle qui affiche des données, un dispositif d'interface audio qui reçoit une entrée acoustique et la transforme en données, une connexion réseau, une mémoire contenant un applicatif, et un processeur fonctionnellement couplé au dispositif d'interface visuelle, au dispositif d'interface audio et à la mémoire, l'applicatif s'exécutant sur le processeur. L'applicatif génère localement des interface utilisateur graphique avec l'interface visuelle et commande l'entrée de données via l'interface audio, et la transmission de telles données via le réseau jusqu'au serveur, de façon que les données soient accessibles au destinataire. L'applicatifs commande également la récupération de messages électroniques depuis un serveur. Dans un mode de réalisation particulier, le dispositif de communications mobiles comprend également un dispositif d'interface tactile pour les données de navigation, le dispositif d'interface tactile étant fonctionnellement couplé au processeur.
PCT/US2005/012844 2005-04-13 2005-04-13 Procedes et systemes de telecommunications WO2006112825A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2005/012844 WO2006112825A2 (fr) 2005-04-13 2005-04-13 Procedes et systemes de telecommunications

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2005/012844 WO2006112825A2 (fr) 2005-04-13 2005-04-13 Procedes et systemes de telecommunications

Publications (2)

Publication Number Publication Date
WO2006112825A2 true WO2006112825A2 (fr) 2006-10-26
WO2006112825A3 WO2006112825A3 (fr) 2008-02-21

Family

ID=37115595

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/012844 WO2006112825A2 (fr) 2005-04-13 2005-04-13 Procedes et systemes de telecommunications

Country Status (1)

Country Link
WO (1) WO2006112825A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105873498A (zh) * 2013-10-29 2016-08-17 寇驰·诺丁 用于向人体发送触觉指令的方法和系统

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040225752A1 (en) * 2003-05-08 2004-11-11 O'neil Douglas R. Seamless multiple access internet portal

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040225752A1 (en) * 2003-05-08 2004-11-11 O'neil Douglas R. Seamless multiple access internet portal

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105873498A (zh) * 2013-10-29 2016-08-17 寇驰·诺丁 用于向人体发送触觉指令的方法和系统

Also Published As

Publication number Publication date
WO2006112825A3 (fr) 2008-02-21

Similar Documents

Publication Publication Date Title
US20050266884A1 (en) Methods and systems for conducting remote communications
US6421707B1 (en) Wireless multi-media messaging communications method and apparatus
US7277951B2 (en) Omnimodal messaging system
US7787867B2 (en) Message accessing
US7725116B2 (en) Techniques for combining voice with wireless text short message services
US8184783B2 (en) User interface for integrating diverse methods of communication
US7286990B1 (en) Universal interface for voice activated access to multiple information providers
US20080207233A1 (en) Method and System For Centralized Storage of Media and for Communication of Such Media Activated By Real-Time Messaging
US8626855B2 (en) Method and apparatus for cordless phone and other telecommunications services
US20100293259A1 (en) Communications system providing multi-layered extensible protocol interface and related methods
US20010042100A1 (en) Unified system and methodology for remote access to e-mail
WO2001052503A2 (fr) Procedes et appareil permettant de faire suivre des contenus audio par utilisation d'un systeme telephonique de recherche d'applications audio sur le web
KR20080086465A (ko) 음성 개시 네트워크 동작 방법 및 컴퓨터 판독가능 매체
US20070081639A1 (en) Method and voice communicator to provide a voice communication
WO2007083234A2 (fr) Système intégré de messagerie vocale et de messagerie électronique
US20090052455A1 (en) Mobile terminal and message transmitting/receiving method for adaptive converged IP messaging
WO2008001961A1 (fr) Procédé, système et terminal pour service mobile de messages à animation
EP2151119B1 (fr) Système de messagerie et procédé de fourniture d'informations à un dispositif utilisateur
WO2006112825A2 (fr) Procedes et systemes de telecommunications
KR100794524B1 (ko) 문자 메시지로 주문된 미디어 컨텐츠를 제공하는 서버 및방법
Andrews Unified communication systems
WO2003100634A1 (fr) Procede et systeme pour manipuler des messages en plusieurs parties provenant de clients de courriel et envoyes a des telephones cellulaires
WO2001024463A1 (fr) Procede et dispositif de messagerie unifiee
AU2003100686A4 (en) Method and Software Product for Creating Mobile Device Messages
WO2001076212A1 (fr) Interface universelle pour un acces a commande vocale a une pluralite de fournisseurs d'information

Legal Events

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

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

122 Ep: pct application non-entry in european phase

Ref document number: 05735502

Country of ref document: EP

Kind code of ref document: A2