WO2009133544A1 - Dispositif et système serveur de messagerie - Google Patents

Dispositif et système serveur de messagerie Download PDF

Info

Publication number
WO2009133544A1
WO2009133544A1 PCT/IE2009/000024 IE2009000024W WO2009133544A1 WO 2009133544 A1 WO2009133544 A1 WO 2009133544A1 IE 2009000024 W IE2009000024 W IE 2009000024W WO 2009133544 A1 WO2009133544 A1 WO 2009133544A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
message
client
cms
messaging
Prior art date
Application number
PCT/IE2009/000024
Other languages
English (en)
Inventor
David Geen
David Harmony
Louis G. Alexander
Roelof Dekker
Klaas Wijbrans
Katja Sizova
Original Assignee
Markport Limited
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 Markport Limited filed Critical Markport Limited
Publication of WO2009133544A1 publication Critical patent/WO2009133544A1/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/56—Unified messaging, e.g. interactions between e-mail, instant messaging or converged IP messaging [CPM]

Definitions

  • the invention relates to messaging in communication networks.
  • client applications are typically dedicated to a single messaging type/bearer, i.e. they are essentially sole-purpose applications: for example an SMS client for text messaging, an MMS client for multimedia, Email client for managing an Inbox, Web/WAP client for browsing, or a TUI (DTMF) client for voicemail.
  • client application typically includes a protocol stack dedicated to the given messaging type (for example Email via IMAP/POP/SMTP, MMS via MM1-MM7).
  • Fig. 1 depicts a high level view of typical messaging device-server interaction.
  • One problem is that, from the end user perspective, the functionality provided by the messaging device is fragmented.
  • client applications or “clients”
  • clients are typically standalone, although deployed on the same device, they may each have unique skins, command input/output schemes (i.e. key sequences), colour schemes, fonts, and/or error handling schemes.
  • the standalone nature of the clients necessitates context switching to jump from one messaging type to another - for example, exit the email client then launch the SMS client to manage text messages.
  • protocols developed for the internet are in some cases stateful protocols; these are ill suited for use in the mobile environment wherein connections are typically non-persistent, thus requiring re-establishment of state information on the client side in the event of broken connections.
  • the invention described herein addresses. the above problems.
  • a communications system comprising:
  • a communications server comprising: interface means for communication with messaging devices in a network; interface means for communicating with a plurality of back-end servers using protocols specific to the back-end servers, processing means comprising normalization functions for bi-directionally converting between back-end server protocols and a universal protocol, and for communicating with the remote messaging devices using said universal protocol, wherein the universal protocol encompasses back-end server primitives and also aggregated primitives which are combinations of said back-end server primitives,
  • each of said messaging devices comprises: at least one client application, and a programmatic interface for communicating on behalf of said client applications with the communications server using said universal protocol,
  • normalization functions are adapted to perform messaging operations at least one of which involves use of a logical grouping of back-end servers, in response to the programmatic interface of a device exercising an aggregated primitive.
  • the no ⁇ nalization functions perform said operations in a manner whereby involvement of logical grouping of the back-end servers is transparent to the device, and in which involvement of other back-end servers is transparent to any one back-end server of the logical grouping.
  • the server further comprises combinatorial functions, which together with the normalization functions respond to an aggregated primitive of a single device client application request to perform decision logic, scheduling, and routing for a combination of back- end server capabilities so that combination services can be provided to a messaging device.
  • the server is adapted to download to a messaging device the programmatic interface over a bearer such as SMS.
  • the normalization functions are adapted to be modified to change the range of back-end server services which can be provided by the server.
  • the server and the device are adapted to choose one of a plurality of bearers for communication using the universal protocol.
  • the bearers are HTTP or SMS.
  • the choice is according to a condition including network performance, size of message, device presence or device address, or any combination of these.
  • a condition includes likelihood of subsequent operations arising from the communication wherein the operations are tagged for identification of subsequent related operations.
  • the server normalization functions are synchronised with the device programmatic interfaces in terms of device client application operations and expected size of interactions.
  • the server is adapted to store message, subscriber, and presence state information of a device client application, and the device is adapted to maintain a cache of said state information, for synchronisation between the device and the server.
  • the server normalization functions are adapted to identify the capabilities or the level of service of a client application in response to a programmatic interface operation or by recognising a string of control characters in a message such as a backward compatibility message.
  • the server normalization functions are adapted to operate without specific knowledge of the type or originating bearer of a message, either from a back-end server or a device.
  • At least one normalization function is adapted to list incoming messages from back-end servers fulfilling specific filter criteria.
  • the server normalization functions and the combinatorial logic functions are adapted to provide to messaging devices a visual voicemail service which includes visual voicemail protocol operations.
  • At least some normalization functions are adapted to allow mixed mode use of a bearer, in which an initial communication between the server and a messaging device is over one bearer and a subsequent communication for the same session is over a different bearer.
  • the messaging device is adapted to provide a uniform user interface according to the universal protocol regardless of the message type or client application being executed.
  • a messaging device is adapted to automatically switch between messaging modes without intervention from the user.
  • the modes are SMS and instant messaging modes.
  • the normalization functions are adapted to perform content transcoding according to device capabilities.
  • the device programmatic interface is extensible whereby new client application capabilities and back-end server capabilities may be added in the future.
  • the server comprises a message bus linked with:
  • connectors for normalizing protocols of back-end servers and placing normalized messages on the bus feature objects encapsulating normalization functions, and connectors adapted to transmit universal protocol messages between the bus and the devices.
  • the server further comprises a service engine linked with the message bus and comprising normalization functions and combinatorial logic functions for execution of services together with the feature objects.
  • the service engine and the feature objects communicate with each other using normalized messages on the bus, said messages using the primitives including the back- end server primitives and the aggregated primitives to perform services.
  • the feature objects are bearer-agnostic, and the service engine configures reuse of feature objects for multiple services configured using capabilities of back-end servers.
  • the server is adapted to instantiate the feature objects with granularity selected to promote reuse of feature objects when configuring services.
  • a function is adapted to request, transparently to a client, transcoding services of a back-end server for message transmission.
  • the device programmatic interface and the normalization and combinatorial logic functions of the server are adapted to exercise an intuitive-send aggregated primitive, and in which:
  • a client application is adapted to invoke said primitive on the server with a message comprising a plurality of media types
  • a function on the server is adapted to interact with profile store and presence back-end servers
  • a function on the server is adapted to: invoke the profile store back-end server for an intended recipient to determine the user's preference settings with regard to receiving messages, and invoke the presence server to gain information about the current status of the user, and transmit the message according to the profile and status information.
  • the normalization and combinatorial logic functions are adapted to deposit the message in one or more back-end servers for subsequent delivery to the recipient.
  • At least one device client application and the nonnalization and combinatorial logic functions are adapted to process a multi-modal conversation aggregated primitive, in which
  • the client application provides a unique client identifier within the multi-modal conversation aggregated primitive together with a presence value, a function of the server sets the presence value and subsequently updates a back- end server profile store and presence server, and subsequently sends the message according to said settings to a media server.
  • the invention provides a computer readable medium storing computer readable code for causing a digital processor of a server to perform the steps of the interface means and the processing means of a server of any system defined above.
  • Fig. 1 is a diagram illustrating typical prior art messaging device/server interaction as set out above;
  • Fig. 2 is a block diagram showing a messaging system of the invention
  • Figs. 3 and 4 show basic client-server interactions of the system
  • Fig. 5 shows an embodiment of the invention in which HTTP is used as a bearer for communication between a messaging device and a messaging server
  • Fig. 6 shows an embodiment of the invention in which both HTTP and SMS are used as bearers for communication
  • Fig. 7 illustrates an embodiment, in which various caches and other components are illustrated
  • Figs. 8 is a diagram showing architecture of the messaging server in more detail.
  • Figs. 9 to 19 are message sequence diagrams showing server and client interaction and server operations..
  • the invention provides messaging devices 1 (only one of which is shown) and a “comprehensive messaging server” ("CMS") 10.
  • CMS prehensive messaging server
  • the device 1 has a processor and memory for executing client applications ("clients") 2, communicating via a protocol stack.
  • clients client applications
  • the device 1 may be of any of a variety of types such as a portable computer, a mobile phone, a PDA, or a television / set top box for example. It could operate in mobile, fixed line, cable/broadband or IMS network domains.
  • the CMS 10 is a central link between the devices 1 and back-end servers 20, Server A - Server G. Communication between the CMS 10 and the devices 1 is via a single, universal, protocol.
  • the CMS 10 has functions 13 performing normalization of the protocols of the back-end servers 20 onto the single protocol.
  • the CMS also provides combinatorial logic functions 14 which, together with the normalization functions 13, are executed upon the primitives of the back end servers A to G, thus enabling additional aggregate primitives H to Z over the universal protocol.
  • the device 1 communication is via only one server, namely the CMS 10, using the single protocol. The fact that the device 1 exercises a single, universal, protocol and that the CMS 10 is involved is transparent to the back-end servers 20.
  • Normalization of the various protocols employed by the back end servers 20 enables any number of clients 2 to be executed on the messaging device 1 using the single protocol.
  • any one of the primitives A-G of the back-end servers 20 may be utilized, or any combination of these primitives may be utilized.
  • the normalization functions 13 and the combinatorial logic functions 14 executing on the CMS 10 enable aggregated primitives H-Z to be added to the single protocol, also exercisable by the messaging device 1 clients 2.
  • the aggregated primitives (H-Z) represent value added services created through the combination and aggregation of the basic primitives (A-G) both in terms of the logic they implement and also in terms of the sequence in which one or more of the back-end servers 20 are involved.
  • the client application 2 (and likewise the application developer) need not be aware of the inter-communication details for two or more back-end servers 20, simplifying the creation of the client applications and provision of value added services using more than one back end server A-G.
  • Communication between the messaging client 2 and the CMS 10 may be originated either by the client 2 or the CMS 10, shown in Figs. 3 and 4 as request / response and notification / acknowledgement sequences.
  • the CMS understands the state of the client as needed for the given service, and provides notifications to alert of state changes.
  • the client may in turn initiate a client to server request to download i.e. message/mailbox information.
  • Fig. 5 provides a more detailed view of one embodiment.
  • the protocol is realized as a RESTful API 4, on top of an HTTP/TCP bearer 5, 6.
  • the device 1 may communicate with any one of the back-end servers 20 using the REST API 4, which provides a superset of the functionality offered by the back-end servers 20 set as a result of the combinatorial logic functions 14 in the CMS 10.
  • the device 1 may exercise the (superset of the) capabilities of the back-end servers 20 using only the single protocol stack, relieving the device 1 of the need to be programmed with the required primitives for communication with the relevant back end servers 20.
  • the RESTful API 4 may be implemented on top of alternate bearers, i.e. other than HTTP.
  • Fig. 6 provides a view of a second embodiment, in which the RESTful API is implemented on top of HTTP as well as SMS bearers.
  • the realization of the RESTful API on top of alternate and / or multiple bearers provides several advantages, the choice of bearer being selectable of different criteria, including :
  • Fig. 7 shows the system with inbox, address book and presence caches 40, 41, 42 on the device and CMS 10 having corresponding inbox, address book, and presence agents 43, 44, 45. This is described in more detail below.
  • the functional architecture of the CMS is depicted in Fig. 8.
  • the CMS 10 is comprised of a number of principal elements: a central message bus 50, feature objects implemented as Java beans 51, connectors 52 to link the back-end servers 20 to the CMS 10, and a service engine 53 for execution of services 54.
  • Universal Protocol (REST) Connectors 55 are also linked to the message bus 50. These provide connectivity to the client devices 1.
  • Each connector 55 is associated with a particular underlying bearer.
  • the message connectors 52 on the lower portion of the diagram provide for the normalization of the protocols employed by the various back-end servers 20 such that messages can be routed to / transported over the central message bus 50; in this manner the aggregate set of primitives offered by the back-end servers 20 can be exercised in the single protocol.
  • Features are implemented as Java beans 51, providing new functionality which may be executed upon the various messages carried on the central message bus 50.
  • the service engine 53 provides for the execution of services 54; services being logic applications employing combinatorial logic to connect features 51 to primitives carried on the central message bus 50.
  • the services themselves are also exposed as new messages on the central message bus 50, with the net result that the comprehensive set of messages carried on the centra] message bus 50 is the aggregate, or collective set of primitives offered by the back-end servers 20 plus the new primitives which are the services built upon the original aggregate set using combinatorial logic executed by the service engine 53.
  • the comprehensive set of primitives carried on the central message bus 50 is exposed to the client 2 via the REST connectors on the upper portion of the diagram, available via HTTP as well as SMS bearers.
  • the features 51 are implemented in a manner so as to be channel agnostic, for example AutoReply versus SMSAutoReply. This promotes reuse of features 51 in multiple services 54 created using the various back end servers connected to the CMS 10; for example an AutoReply feature may be reused for services SMSAutoReply, MMSAutoReply, EmailAutoReply.
  • Features are implemented with appropriate granularity so as to promote reuse in building more complex services. For example, Whitelist and AutoCopy as independent features 51 enable the creation of a service which copies messages passed through a Whitelist filter. As all of the features 51 run in a common environment, adding features is simplified.
  • Enabling a given feature 51 for use in a service 54 with a new back-end server 20 capability is also simplified, as the various capabilities are all connected to the CMS 10.
  • the engine 53 in which the services 54 execute operates on normalized messages carried on the bus 50
  • service creation is possible without apriori knowledge of the individual elements connected to the message bus 50. This is an important aspect for extensibility; services can be created or extended in the future by 'plugging in' new capabilities (i.e. back end servers) and/or features to the CMS, without the need for modification to the CMS framework itself.
  • Services 54 may be requested by a client 2 or performed automatically in response to a condition (i.e. a time based trigger) and performed by the CMS 10 in conjunction with the capabilities of the back-end servers 20.
  • the CMS 10 services 54 in turn invoke a set of one or more features 51 to use a range of back-end server 20 capabilities.
  • the CMS 10 aggregates programmatic interfaces offered by the individual messaging back-end servers 20 into a single interface, adding as well a functional capability to the aggregated interface. It provides a single programmatic interface towards messaging clients 2 of all types, in addition to serving as a VASP interface.
  • the interface API itself is extensible: new capabilities may to be added to the interface in the future to broaden the range of applications achievable through use of the interface. Similarly the range of capabilities aggregated behind the CMS 10 is not bounded, i.e. new components may be "plugged into" the CMS 10 via IP or other protocols in the future.
  • Functional capability in combination with a single interface API enables rapid service creation: new VASs can be implemented simply by adjusting the functional logic to invoke the applications, providing the new service logic.
  • the device 1 and CMS 10 allow rich application and service development. Client applications need not be concerned with the specifics of programmatic interface A or B, as a consistent interface is presented for all capabilities, at the same time speeding development of new services. Specifics of inter-working between programmatic interfaces offered by the individual messaging servers are provided by the CMS 10. Functional capability (logic, scheduling, routing) inherent in the new server component can be applied to capabilities provided by any one messaging server, any combination of messaging servers or those provided by external applications invoked by the messaging server using the unified interface. This enables development of a seemingly boundless range of applications and rapid creation of services by a user or a service provider via a high level interface (such as a GUI or a natural language interface), over a single protocol, which provides the aggregate capabilities in a consistent manner.
  • a high level interface such as a GUI or a natural language interface
  • the CMS 10 acts as a gateway to messaging servers such as profile server, mail store, SMSC, MMSC, WAP gateway, IM(PS), or a transcoding server. It converts between the aggregated interface protocol and the specific messaging server access protocols e.g. IMAP/SMTP for mail store, SMPP or UCP for SMSC, MM7 for MMSC, SIP messaging interface for SIP-enabled service centres.
  • the CMS 10 can intercept messages by being configured in-network. e.g. for SS7 interception and relay, for IP interception and relay.
  • the CMS 10 provides single generic handling of all messages being processed, irrespective of the type or content of the message, or of the underlying network or messaging service of the recipient or destination, and irrespective of the device type, capabilities or location of the recipient or destination. Also, the CMS supports network access protocols and messaging server access protocols for inter-working with clients such as for backward compatibility purposes.
  • the (single) protocol exposed by the CMS is based on the REST paradigm, transported via HTTP. This results in a simple implementation of the primitives as the various operations are mapped on HTTP operations with only the minimum amount of data necessary.
  • REST as a programmatic paradigm is well suited for building scalable server architectures designed for web services.
  • a web services type interface is also well suited from the client device/application perspective; i.e. it is deployable on the range of devices envisioned for messaging services - mobile, computer, or television, in standalone or mashup applications, and inherently makes accessible the wide variety of value added services deployed on the CMS to external agents.
  • the REST protocol is suitable for network domains as it is stateless; it does not require persistent connections between client and server across transactions (duration of a session). This characteristic makes the REST protocol well suited for deployment in mobile networks, wherein connections may be intermittent.
  • a client 2 transmits a message to the CMS 10 over REST, requesting a service 54.
  • the request message is routed to the service engine 53 via the message bus 50 which invokes the service 54.
  • the service engine 53 invokes the features 51 and the primitives of the back-end servers 20 exposed by the connectors 52 as defined by the logic within the given service.
  • the response to the client request is subsequently delivered via the message bus 50 through the appropriate REST connector.
  • Deployment descriptors are used on the CMS to map a given trigger condition to a specific service to be invoked. Trigger conditions for example could include client requests received via the REST interface, or primitives received from one of the back end servers 20.
  • the deployment descriptors also provide granularity to control the mapping function based on specific properties of a given trigger condition. For example, in the case of the SMPP connector, deployment descriptors may specify specific services to be launched based on ESME, Time of Day, Addressing Fields, etc.
  • bearers for the transport of the REST protocol itself are also possible, the transport being selectable based on application needs, network availability, cost, and/or performance. Additionally 'mixed mode' use of the bearer is possible, i.e. an initial communication between client and server may use one bearer, and subsequent transactions may use a different bearer.
  • the device 1 and the CMS 10 provide a level of service and capabilities indicator
  • the CMS 10 or client 2 can identify themselves, their capabilities and the level of service possible through the exchange (or non-exchange) of information indicating the level of services and capabilities supported. This can be implemented via REST API operations. Thus for example a server-originated API/protocol operation at session initiation could indicate the server side capabilities and the client if capable of doing so could respond indicating its capabilities.
  • a level of service and capabilities indicator could also be implemented via backward compatibility mechanisms.
  • the back-end server and clients identify themselves, their capabilities and the level of service possible through the exchange or non-exchange of an embedded string of visible or invisible 'control' characters as payload to a normal service message, which can be responded to.
  • a server could originate a voicemail alert with a string "comprehensive messaging”.
  • the client receives this, if the client does not support/understand "comprehensive messaging" it can just ignore the tag. If it does support "comprehensive messaging", the small client recognizes what it is and should respond.
  • Capabilities which can be aggregated behind the CMS 10 are not bounded/limited. New capabilities may be plugged into the CMS 10 via IP or other protocols, their feature sets also added to the REST API. As information exchanged over the API is via defined (and extensible) XML schema, the protocol/ API is also not bounded/limited.
  • the underlying delivery mechanism and protocols are selected automatically by the CMS 10 to deliver the message to the recipient based on the network over which the message will be delivered and on the client device 1 to which the message will be delivered, both of which will be determined automatically based on the current location of the user and/or on his explicit or implicit preferences.
  • the underlying delivery mechanism and protocols are selected automatically by the client using the REST API to originate a message to the messaging service based on the type and content of the message being originated, the level of service required, the capabilities of the client device and current network, the messaging servers in the network and the service being provided by an underlying service provider.
  • the system (devices 1 and CMS 10) can automatically and dynamically detect a preferred mode , of service based on parameters such as message content and recipient address type, and/or on stored explicit and implicit preferences.
  • a single message originating interface is presented to the user by the client 2, regardless of the type and content of the message being originated, and regardless of the underlying messaging service being used or provided by a service provider.
  • This client 2 will be capable of capturing, accepting, and aggregating any messaging content types supported by the underlying device. For example for messaging chat services the clients can detect messaging conversations and automatically switch between messaging and chat modes without intervention from the user. Another example would be a client 2 detecting messages to or from a particular VASP and being capable of reacting to that.
  • a single message inspection/review interface is presented to the user by the client, regardless of the type and content of the message being inspected, and regardless of the underlying messaging service being used or provided by a service provider.
  • This client 2 will be capable of capturing, inspecting and reacting upon any messaging content types supported by the underlying device by responding to the CMS 10 with a modified set of message parameters. For example a VAS client 1 or client application within a
  • VASP infrastructure can inspect and modify message parameters e.g. inject advertisement content into message content, or divert to a divert service such as an out of office service.
  • the aggregation of messaging servers behind the CMS 10 results in a single common view on messaging, regardless of whether it originates from the e-mail world, instant messaging, a short message, a multimedia message or a voice mail with the network hiding the idiosyncrasies of each protocol.
  • client 2 vendors are almost automatically able to build a single integrated view on the messaging inbox, the address book and the presence status with respect to the various communication channels, which provides a reliable message delivery service capable of retaining and retransmitting a message to a recipient when that recipient explicitly or implicitly elects to be available to receive a message.
  • the messaging inbox is an optional feature; i.e.
  • the CMS 10 also facilitates direct messaging between IP to IP messaging clients (using the programmatic API), between IP and legacy, or legacy to legacy direct messaging. Transcoding across the messaging types is facilitated by the CMS 10 as needed; additionally choice of suitable (ideal) messaging type for direct messaging may be presented based on preferences, profiles, cost, performance, presence, or simply application specification.
  • suitable (ideal) messaging type for direct messaging may be presented based on preferences, profiles, cost, performance, presence, or simply application specification.
  • the CMS 10 accepts the MT-FSM from the SMSC and stores the
  • SMS message in the network mailstore b. If an MMS message arrives, the MMS notification is not delivered to the handset but instead to the CMS. The CMS accepts the MMS notification and updates the network mailstore. c. If an SMTP message arrives directly, the SMTP message is accepted and stored in the network mailstore. d. Periodically, the CMS polls configured (external) IMAP and/or POP3 mail servers for new messages or changed messages. If new messages or changed messages are found, the network mailstore is updated. e. If a chat message arrives using a chat protocol (IMPS, IM, IMS-SIP) the network mailstore is updated with the chat message. f. Inside the network mailstore, messages are stored in canonical format with meta information.
  • IMPS IMPS, IM, IMS-SIP
  • Meta information consists of message type, originating channel, originator, time-stamp and any flags and/or other meta-information (potentially part of the specific messaging protocols), g. Inside the network mailstore, the CMS 10 adds additional meta-information by for example organizing messages in conversations based on the originator-recipient combinations, time-stamps of messages and channel vised. h. Periodically or after arrival of a message, the CMS 10 sends an update to the client, providing notification of the change and / or the need to synchronize in the event that the client provides for on-board storage.
  • the CMS 10 provides inter-working/translation and message exchange between various legacy systems (e.g. e-mail, SMS text messaging, IM Instant Messages, Cellular Picture or MultiMedia Messages, Voice Message to e-mail or text messages, Legacy Voice Messages to voice encoded MultiMedia Attachments, textual messages (SMS/e-mail) to Voice Encoded Messages) - based on the capabilities of the network and device to which is being delivered and/or based on explicit or implicit (stored or default) service preferences of the intended recipient.
  • legacy systems e.g. e-mail, SMS text messaging, IM Instant Messages, Cellular Picture or MultiMedia Messages, Voice Message to e-mail or text messages, Legacy Voice Messages to voice encoded MultiMedia Attachments, textual messages (SMS/e-mail) to Voice Encoded Messages) - based on the capabilities of the network and device to which is being delivered and/or based on explicit or implicit (stored or default) service preferences of the intended recipient.
  • the CMS 10 provides for transcoding of message contents as required via connectivity to a network based transcoding server.
  • the message contents will automatically be tailored as determined by a. capabilities of the underlying network b. service provided by the underlying service provider c. device of the originator and/or recipient d. explicit or implicit preferences of the recipient (stored in profile server) e. straightforward logic preference determined by client application.
  • SMS Short Streaming Protocol
  • a transport bearer This offers increased flexibility for deployment of messaging clients 2 in the mobile environment, enabling a choice of bearer for communication dependent on for example network conditions, performance, or cost.
  • a specific bearer may be selected dependent on the communication itself, i.e. server initiated notification may be via SMS and the client requests via HTTP.
  • Network context for adding SMS as a bearer transport is depicted in Fig. 6.
  • both the device client and the CMS 10 can base their transport bearer choice on one or more criteria or rules such as:
  • the REST operations can be tagged to indicate whether they are likely to be stand-alone or part of a conversation. If such operations are for example part of a conversation, then this favours choice of IP bearer.
  • Bearer availability If the IP bearer is already connected this favours choice of using the IP bearer.
  • Bearer cost For example data bearer cost can be predicated on location, such as when roaming where data is often charged in specific bundle sizes.
  • the CMS or device client
  • a multimedia message arrives at the MMSC.
  • the MMSC notifies the CMS that a multimedia message has arrived (e.g., the CMS is seen as the handset client by the MMSC).
  • the CMS retrieves the message from the MMSC, converts it to the canonical format used in the CMS and stores it in the network mailstore / Inbox.
  • the CMS must update the client with this information.
  • a Radius database query is performed to check whether the client is currently connected to the network over an IP bearer. a. If the client is connected to the IP bearer, the CMS sends a packet containing a REST datagram to the client indicating the change in the Inbox including the meta information of the change (e.g., Sender, type of message (MMS). Subject, size). b. If the client is not connected to the IP bearer, the CMS constructs an SMS message with a compressed form of the REST message (e.g., using encoding/ techniques translating each XML tag to a single binary number, e.g. like in WSP) including meta information of the change. 6. The client updates the client-side inbox with the received information.
  • a REST datagram e.g., Sender, type of message (MMS). Subject, size.
  • MMS type of message
  • Subject size
  • the CMS constructs an SMS message with a compressed form of the REST message (e.g., using encoding/ techniques translating each X
  • the users scroll through the Inbox and selects a message for viewing.
  • the Messaging Client does a message retrieval request to the Messaging API.
  • the response to the REST request is returned by the CMS, containing the remaining content of message and meta-informat ⁇ on (as the CMS is aware of the meta-information already sent in the update to the client- side Inbox) as a number of SMS messages. c. If no IP connectivity is available but IP bearers are not congested, and the remaining content of the message is more than a configurable threshold, the client-side Messaging API sets up the IP bearer, and then does a REST request to retrieve the message over the IP bearer. The response to the REST request is returned by the CMS, containing the message and its meta information over the IP bearer.
  • a second example where the bearer choice is made by the client is to convey metadata related to delete and / or message status update operations. With these operations, additional optimization is possible by postponing the sending of an update so that multiple updates are combined in a single message:
  • the client-side Messaging API gathers these updates in a buffer. b. When the buffer fills up above a certain threshold, or after expiry of a timer, the client-side Messaging API creates a single compressed REST datagram with multiple state updates from the buffer to exactly fit in one SMS. c. The SMS is sent to the CMS. d. The CMS returns the REST response to the multiple updates in a single SMS datagram.
  • IP connectivity is available, the buffer is not used and a REST datagram is sent out for each individual state change.
  • the Messaging API has knowledge of the operations and thus of the expected size of the interactions.
  • both server side and client side are able to optimize the communications to the most appropriate channel based on the actual operation.
  • the state information on the client is seen as a 'cache', with the actual up to date information residing in the network. Using standard caching and updating technologies, this means that the amount of communication between client and network can be optimized significantly.
  • An example of this is the scenario where the user is browsing through the inbox and reading and composing messages.
  • the information is first retrieved from the cache. Only if the information is not available in the cache (for example because the content of the message has not been downloaded yet), the client-side Message API contacts the server using the REST protocol, either via SMS (if it knows that the size of the message is small) or via the IP bearer. If communication is set up over the IP bearer, the specific request is performed but in addition, a background task may be started in the API that scans through the caches and updates them with new information.
  • an explicit 'refresh cache' option may be present on the API to the Messaging client. This for example would allow an end user to explicitly synchronize his address book or his inbox.
  • An example of such optimization is for example that at initial log-on the client negotiates specific presence settings for the device using TCP/IP over the packet radio bearer. After that, the radio channel is released. However, if a presence state change occurs of any of the parties the client is interested in, the server can send the changes in an appropriately coded binary SMS instead of requesting a radio channel to be built up. As a result, the radio channel resource usage at the cell level is decreased significantly.
  • An example flow of this scenario may consist of the following:
  • the IMPS server indicates a presence update for a specific 'buddy'.
  • the CMS discovers that the client has IP connectivity.
  • the CMS sends an update to the presence status over the IP bearer.
  • the IMPS server indicates a presence update for a specific 'buddy'.
  • the CMS discovers that the client has no IP connectivity.
  • the CMS stores the update in its server-side presence cache.
  • Step 1-3 may occur multiple times.
  • the cache contains more updated entries than a configurable limit, or the maximum allowed delay between a presence update and its indication on the phone may have expired.
  • the CMS combines the presence updates in the cache into a single REST PDU mapped onto an SMS message.
  • the CMS sends out the SMS message.
  • the CMS 10 provides a unified view on the Inbox through the following techniques:
  • the messaging operations for listing and retrieving messages operate on the single Inbox without specific knowledge with respect to the type or originating channel of a message
  • Messages sent by the client are accepted by the CMS using a generic address and in canonical format.
  • the CMS decides based on the address (which determines the addressable channels), the contents in the canonical format (which determines the available channels supporting that format) and presence information (which determines the channels available for direct delivery) which channel to use for a specific delivery to the recipient.
  • TMs is however a dynamic adaptation of a generic Inbox that might be sorted by time stamp.
  • the client-side Messaging API will accept a message containing a recipient address and a generic content.
  • the recipient address may consist of the internal identil ⁇ cation of a recipient in the address book.
  • the client-side Messaging API sends the message using a REST request to the server-side CMS.
  • the CMS 10 accepts the request and first looks up the recipient in the address book. In the address book, three addresses are found:
  • the message contents contain multi-media.
  • the recipient is not logged on to the chat server with the SIP URI, but is known to have his handset switched on and be in a network with GPRS/UMTS coverage.
  • the CMS takes the decision to proceed sending the message to the recipient using MMS using the MSISDN as the recipient address.
  • the aggregation of messaging capabilities (back-end servers) behind the CMS 10 enables the development of a wide range of applications deployed to the various device clients found in today's networks. Some example use cases are provided below.
  • VVM Visual Voicemail
  • Figs. 9 to 15 Visual Voicemail
  • VVM provides subscribers with a fully integrated, easy-to-use graphical multimedia interface that significantly improves the voicemail experience.
  • the service is equally well suited for the different messaging clients found in many network domains, such as mobile phones, PDAs, computers, and televisions.
  • VVM Client Initialization Signalling flow for VVM client initialization is depicted in Fig. 9; the CMS interacts with the subscriber profile, network mailstore, and transcoding server in response to the client invoked combinatorial primitives to fulfil the the operation. Steps required for the initialization are as follows : 1. Upon application launch, the combinatorial primitive "inbox" is invoked by the VVM client to retrieve the mailbox state information. (Note this is the default behaviour for the client upon application launch)
  • the CMS checks the subscriber profile information (to retrieve mailbox location information) and identifies that the mailbox is uninitialized (greeting not recorded).
  • a return code to the client request conveys the need for client initialization.
  • the CMS transcodes the uploaded audio content as required by the subscriber profile
  • the CMS uploads the transcoded audio to the greeting folder in the network mailstore.
  • the CMS updates the subscriber profile information to reflect that the mailbox is now initialized 7.
  • a successful return status is returned by the CMS to the VVM client.
  • VVM Client Greeting Review Signalling flow for VVM client greeting review is depicted in Fig. 10; the CMS interacts with the subscriber profile, network mailstore, and transcoding server in response to the client invoked combinatorial primitives to fulfill the operation. Steps required are as follows :
  • the user selects to listen to their current greeting.
  • the VVM client invokes the combinatorial primitive "greeting" to fetch the all calls greeting
  • the CMS checks the subscriber profile to locate the appropriate mailbox on the network mailstore. 3. The CMS fetches the all calls greeting from the subscriber mailbox on the network mailstore.
  • the CMS transcodes the uploaded audio content as required by the subscriber profile (preferences) / client device capabilities.
  • the CMS returns the transcoded audio to the VVM client 6.
  • the VVM client plays back the all calls greeting to the user.
  • VVM Client Greeting Upload Signaling flow for WM client greeting upload is depicted in Fig 11 ; the CMS interacts with the subscriber profile, network mailstore, and transcoding server in response to the client invoked combinatorial primitives to fulfil the operation. Steps required are as follows:
  • the user selects to record a greeting within the VVM client. After capturing the recorded audio, the VVM client invokes the combinatorial primitive "greeting" to upload the recorded greeting.
  • the CMS transcodes the uploaded audio content as required by the subscriber profile (preferences) / client device capabilities.
  • the CMS updates the subscriber profile as necessary to reflect that the all calls greeting is active. 4. A successful return status is returned by the CMS to the VVM client.
  • TUI Message Deposit Signaling flow for legacy client ("TUI client") message deposit is depicted in Fig 12; the CMS interacts with the media server, network mailstore, SMSC, and transcoding server to fufill the operation.
  • the service is triggered by the legacy client; the service logic in this case causes the CMS to use the SMS bearer for the notification communication while the messaging client uses the HTTP bearer to invoke the combinatorial primitives required to complete the operation. Steps required are as follows:
  • the user receives a new message in their inbox via standard message deposit from another mobile or fixed line device.
  • the media server relays the deposited audio to the CMS, invoking the "tui deposit"' service.
  • Logic in "tui deposit” service causes the CMS to deposit the provided audio message into the network mailstore.
  • the CMS notifies the VVM client of the need to synchronize via SMS trigger with a REST "synchronize” command (note logic in the "tui deposit” service determines the
  • SMS bearer as most suitable for the given communication.
  • the VVM client in response to receiving the REST notification via SMS, invokes the combinatorial primitive "inbox" to retrieve updated inventory information of the subscriber inbox.
  • the CMS retrieves the subscriber inventory information from the network mailstore.
  • the CMS returns the subscriber inventory information to the VVM client.
  • the VVM client upon checking local cache / storage of messages, determines the need to retrieve the newly deposited message and invokes the combinatorial primitive "inbox" supplying the id of the message to be retrieved.
  • the CMS fetches the deposited message from the subscriber mailstore.
  • the CMS transcodes the recorded message as required by the subscriber profile (preferences) / client device capabilities.
  • the CMS returns the transcoded message to the VVM client.
  • TUI Message Delete Signaling flow for legacy ("TUI client") message delete is depicted in Fig. 13; the CMS interacts with the media server, network mailstore, SMSC, and transcoding server to fulfil the operation.
  • the service is triggered by the legacy client; the service logic in this case causes the CMS to use the SMS bearer for the notification communication while the messaging client uses the HTTP bearer to invoke the combinatorial primitives required to complete the operation. Steps required are as follows:
  • the user checks their message via traditional TUI access, with either their personal mobile device or another device (fixed or mobile). Upon reviewing messages the user selects to delete a given message. 2.
  • the media server relays information as to the specific message to delete to the CMS, invoking the "tui delete" service.
  • the CMS deletes the given message from the network mailstore.
  • Logic in the ''tui deposit” service causes the CMS to notify the VVM client of the need to synchronize via SMS trigger with a REST "synchronize” command. 5.
  • the VVM client in response to receiving the REST notification via SMS, invokes the , combinatorial primitive "inbox" to retrieve updated inventory information of the subscriber inbox.
  • the CMS retrieves the subscriber inventory information from the network mailstore.
  • the CMS returns the subscriber inventory information to the VVM client.
  • the VVM client upon checking local cache / storage of messages, determines the need to delete the specific message from the onboard storage in order to be in sync with the network mailstore, and subsequently removes the message.
  • VVM Client Message Update Signaling flow for VVM client message update is depicted in Fig 14; the CMS interacts with the subscriber profile and network mailstore to fufill the operation. Steps required are as follows:
  • the user selects a message for playback on the VVM client. Options for pause and restart are provided for the given message while reviewing on the client. After playback the message status (unread/read) is updated in the onboard storage / cache of the VVM client.
  • the VVM client invokes the combinatorial primitive "inbox" to post the updated mailbox inventory information to the CMS.
  • the CMS checks the subscriber profile to locate the appropriate mailbox on the network mailstore.
  • the CMS updates the message status (unread / read) in the network mailstore to synchronize with the inventory information provided by the VVM client.
  • VVM Client Message Delete Signaling flow for VVM client message delete is depicted in Fig 15; the CMS interacts with the subscriber profile and network mailstore to fufill the operation. Steps required are as follows:
  • the user selects to delete a message via the VVM client. After removing the given message from the onboard storage / cache, the VVM client invokes the combinatorial primitive "inbox" to post the updated mailbox inventory information to the CMS. 2. The CMS checks the subscriber profile to locate the appropriate mailbox on the network mailstore.
  • the CMS deletes the prescribed message from the network mailstore to synchronize with the inventory information provided by the VVM client.
  • a 'Composite Virtual Mailbox' service offers a mailbox with the following traits:
  • the contents of the virtual mailbox is a composition of more than one data source that can be characterized as "new content” that "arrives or is published” on a “timely basis” (e.g. Mail Store, RSS Feeds, News Service, Traffic Alerts)
  • the virtual composite mailbox is made available by the CMS 10 to the client device 1 via the REST interface.
  • the combinatorial primitive "virtual inbox" is invoked by the client resulting in the CMS 10 interacting with the mail store and the subscriber profile server.
  • the set of devices 1 accessing the virtual composite mailbox may be heterogeneous in nature as the underlying system has provisions for the ability to transcode the modality of the content (e.g. speech to text, text to speech, speech to video, video to speech, or any combination thereof) based upon: 1. the rights and privileges afforded the user (as determined in a profile store),
  • the "meta state" of the virtual composite mailbox is composed of at least the following data elements:
  • a series of external data sources e.g. Mail Store, RSS Feeds, News Service, Traffic Alerts. Note in this case the external data sources are aggregated behind the CMS using the extensibility (piugability) characteristic of the CMS.
  • a set of privileges indicating the extent of modal transcoding operations afforded to the subscriber including: a. Variations of modality change allowed b. Maximum modality changes allowed per day/month/billing cycle or unlimited
  • Fig. 16 text based messaging client
  • Fig. 17 video based messaging client
  • Messaging Client invokes the CMS, requesting inventory of the virtual inbox for a subscriber with the unique identifier, UlD
  • CMS interrogates the subscriber profile service to retrieve a table of contents for the composite mailbox, along with additional "state" information about each data source.
  • the CMS inteiTogates the profile service to determine if the modality conversion is allowed
  • the Modality Transcoding Service is invoked to transcode the content
  • Steps 7 and 8 are illustrated in Fig. 17.
  • the following table describes the virtual inbox primitive and parameters employed therein.
  • UID Integer The value represents the unique ID of the message in network store, and when used in the path ⁇ UID>/virtual_inbox, solicits a "list" of the messages in the virtual inbox. This is in fact the union of all recent content atoms retrieved through listing the state of all back end content sources (i.e. new emails + new voicemails + unread blog posts, etc).
  • ContentType String The value represents the category of content that the client is requesting, suitable values would include 'blogs' to indicate that HTTP consumption of the content, or 'email' to indicate IMAP consumption, etc. When used in the path
  • ContentSource String The value represents the id that represents the Id source of the content.
  • the id is correlated to a content source in the subscriber's preference store.
  • ⁇ UID>/virtual_inbox/ ⁇ ContentType>/ ⁇ Content Sourceld> a list of all content atoms belonging to this ContentSource is retrieved (i.e. total number of blog posts for this content source in the past 24 hours, and the number of unread blog posts in the past 24 hours).
  • Contentltemld String The value represents the unique identifier of the content item (i.e. the blog post, or mail item, or other atom of content).
  • the content item is returned in its native state (e.g. XML representation for Blog post as retrieved with ATOM).
  • An optional parameter that modifies the content type of the content atom returned using the ⁇ UID>/virtual_inbox/ ⁇ ContentType>/ ⁇ Content SourceId>/ ⁇ ContentItemId>?As ⁇ modifier> path.
  • Use of the As parameter invokes the transcoding server back end service for the purpose of converting the content atom to a different codec type or even media type described by the modifier (e.g. text to speech, speech to video, etc).
  • the end client making use of the transmission mechanism has no a priori knowledge of either: a. The availability of the intended recipient, or the recipient's intention to engage in communication b. The current multimedia capabilities of the recipient (i.e. what device is the intended recipient using- STB, MMS Phone, Dumb 'Black Phone')
  • a message involving multiple media types is transmitted in an intelligent and intuitive manner with respect to: a. The availability (presence) of the user b. The desire of the user to engage in a form of communication (contained in profile) c. Capability of devices where (a) and (b) intersect.
  • the IMT is made available by the CMS to the client device 1 via the REST interface.
  • the combinatorial primitive "intuitive_send” is invoked by the client resulting in the CMS interacting with the profile store and the presence server. It is assumed that the device utilizing the intuitive_send primitive has multimedia capabilities that a user that wishes to originate a message and deliver it intuitively can leverage to compose a message.
  • the composed message- may contain any logical combination of media types (e.g. audio with transcript, video with text commentary, etc) and is transmitted to the IMT via HTTP POST with the multimedia content encoded into a MIME multipart body
  • the IMT Upon receipt of the (1) HTTP PUT, the IMT proceeds to invoke the (2) profile store for the intended recipient to determine the user's preference settings with regard to receiving messages, as well as the (3) presence server where the IMT can gain information about the current status of the user.
  • the IMT deduces the method and format of delivery of the original content based upon information gathered in (2) and (3).
  • the message flow represents one where presence inquiries for XYZ revealed the user to be offline, but that a preference store inquiry reported that the user wishes the text portion of messages to be forwarded to his mobile device as a text message (SMS).
  • SMS text message
  • a transcoding server could be leveraged as in the Virtual Composite Mailbox example to convert any part of the original message into a more suitable content type based upon the final routing decision (e.g. in this case, convert audio to text to send as a SMS).
  • the message is transmitted in its native state using the SMS back end channel.
  • MMS multimedia message service
  • the CMS invokes two additional back end services, one to deposit the message as an SMTP transaction, and one as a MMS transaction.
  • the value is the HTTP authorization necessary to submit a message to the IMT.
  • UID The value represents the unique ID of a user that can be addressed via the IMT.
  • intuitive_send/ ⁇ UlD> When used as intuitive_send/ ⁇ UlD> with a HTTP post, it indicates the submission of content that should be routed in an intuitive manner as described above.
  • Multipart as a MIME multipart.
  • This multipart object may contain any number of sub parts, each MIME encoded.
  • the CMS extracts the MIME parts and makes use of them in an intuitive manner as described above.
  • a multi-modal conversation service is provided, wherein
  • the Mutimodal Conversation service is made available by (enabled by) the CMS to the client device via the REST interface.
  • the combinatorial primitive "multimodal-conversation" is invoked by the client to initiate the service.
  • the client provides a unique client identifier within the given combinatorial primitive, along with the (social) presence value which should be set and subsequently checked for by the CMS to trigger the resultant multimodal conversation.
  • the CMS Upon receipt of the (1) HTTP POST, the CMS sets the given users preference in the profile store ' to enable the given service (2). Following this the CMS sets the users (social) presence with the supplied presence status provided in the client POST request (3), and replies positively to the client submission (4).
  • Text messages submitted by a legacy client B for user A (5) are routed via the SMSC to the CMS (6).
  • the CMS checks the profile store for user A (7) to determine user preference for value added treatment of text messages.
  • the profile setting governs that for text messages received wherein the user (social) presence setting matches ("Speech Only") that multimodal conversations should be enabled, the CMS checks presence status for User A (8) with a positive match. Subsequently the CMS submits the text message content to the transcoder for conversion to speech (9, 10).
  • the speech content is submitted to the media server as input to a script to contact user A for delivery (11).
  • the media server rings user A (12) and delivers the content (13) followed by a record operation to capture User A's reply as speech (14) and subsequent return to the CMS (15).
  • the CMS submits the resultant speech to the transcoder for conversion (16, 17) and thereafter delivers the (speech to text) result to user B as text (18) as one or more Short Messages via the SMSC in this embodiment.
  • the value is the HTTP authorization necessary to submit a message to the IMT.
  • the value represents the unique ID of a user that can be addressed via the multimodal conversation service.
  • multimodal_conversation / ⁇ User> with a HTTP POST, it indicates the subscriber preference should be marked as indicating multimodal conversation enabled for the given subscriber
  • Presence The value indicated the social presence value which should be set for the given user in the presence server. Following receipt of text messages and a positive check for subscriber preference of multimodal conversations, the service will check the presence server for the supplied presence status to launch the service.
  • the goal of the interface is to provide a singular, extensible API to be used for implementing' simple or rich messaging services with ease.
  • the interface is designed to provide rich functionality, enabling services which otherwise would require implementation of a suite of protocols on a given client; the result being 'thick client functionality on a thin client' messaging device.
  • the server-side implementation of the protocol will implement the sophisticated computing requirements, i.e. message format transcoding, language internationalization, alert aggregation / propagation, greetings management, user preferences.
  • the design of the interface is suitable for use on a range of clients deployed in converged or silo networks i.e. mobile devices, broadband devices web browsers.
  • the applications themselves may be standalone, or developed in partnership with another service via i.e. a mashup approach.
  • the stateless nature of the protocol makes it suitable for use in network environments where connections may be intermittent.
  • the REST Messaging Server runs on top of HTTP protocol.
  • the server handles the full HTTP specification of the protocol, which uses TCP as the underlying transport layer.
  • the server supports SSL, which can encrypt the traffic between the two endpoints.
  • HTTP Authorization enforcement is used to protect message access. This allows the use of HTTP Basic Authentication to restrict access by looking up users in LDAP. It requires that requests to the apache server provide a HTTP header Authorization in the request. On cases when the request does not contain an Authorization or the credentials, do not match the credentials in LDAP the server generates a 401 response that details the request for BASIC credentials. The client must then prompt the user for their username and password and submit the request back to the application server. HTTP BASIC Authorization is inherently insecure as it is only an MD5 hash of the username and password. Consequently, it will be required to use this in a secure network, perform the functions over an SSL connection, or modify the authorization to use Digest, which is more secure in open networks.
  • REST strictly refers to a collection of network architecture principles that outline definition and addressing of resources.
  • the interface that transmits domain-specific data over HTTP without an additional messaging layer such as SOAP or session tracking via HTTP cookies.
  • SOAP Simple Object Access Protocol
  • the RESTful model provides a simple, lightweight, and clearly defined API/Data Model for third party developers to use. Thus, clients do not need to know the specifics of IMAP to gain access.
  • Further additional backend servers can come into play (e.g. SQL databases, presence servers and location servers) that can provide additional functionality while maintaining a backwards compatible XML interface.
  • the following description describes the functionality of this API with particular emphasis on visual voicemail back-end capabilities.
  • the CMS handles the majority of the internationalization, localization, and language support for the client. Examples of the features are conversion of time to subscriber local time zone, conversion of telephone numbers to local/national/international numbers for the subscriber, and sentences that are grammatically correct for users defined language for example with regards to message inventory.
  • the action returns message counts for the subscriber.
  • Total Integer The value represents the total number of
  • UID Integer The value represents the unique ID of the message in network store
  • the value represents the index of the message for display purposes.
  • the value may be in order of the UID but may be in reverse order etc.
  • Subscriber Boolean Denotes whether reply is allowed for the message
  • Date The value represents the date when the receipt of the message. This value will be localized for the user and presented in standard format for their region (e.g. DD/MM, MM/DD, etc) Argument Type Description
  • Type String The value represents the possible different type of messages stored in the network, (e.g. voice, fax, video, email, SMS, MMS) . Consult the XSD for simpleType message_types for a definitive list.
  • CaIlId String The value represents the caller/sender of the message.
  • the service returns the localized number based on user settings.
  • Calledld String The called destination or recipient of the message.
  • the service returns the localized number based on user settings.
  • the action returns details of a specific message including information concerning the attachments embedded in the message.
  • This request retrieves a specific message and provides additional details about the message that are not returned from the inbox retrieval.
  • the value is the HTTP authorization necessary to view the subscribers' inbox.
  • Argument Type Description ⁇ iD Integer The value represents the unique ID of the message in network store
  • the value represents the index of the message for display purposes.
  • the value may be in order of the UID but may be in reverse order etc.
  • Date String The value represents the date when the receipt of the message. This value will be localized for the user and presented in standard format for their region (e.g. DD/MM, MM/DD, etc)
  • the value represents the sender of the message.
  • Subscriber Boolean Denotes whether reply is allowed for the message
  • Type String The value represents the possible different type of messages stored in the network, (e.g. voice, fax, video, email, SMS, MMS). Consult the XSD for simpleType message_types for a definitive list.
  • CaIlId String The value represents the caller/sender of the message.
  • the service returns the localized number based on user settings.
  • Text Body String The value represents the text representation of the body of the message which may be HTML or similar textual type
  • Part Integer The value represents the specific part id.
  • this action allows the client to change the status of the messages in the inbox for the subscriber.
  • Targeted Link ⁇ BASEJ/inbox
  • the vahie represents the unique ID of the message in the folder
  • Action String The value represents the type of action to take on the message (e.g. mark as read, delete, unread).
  • the action will convert the audio from the network-stored codec to a usable codec for handset.
  • Targeted Link ⁇ BASE ⁇ /inbox/ ⁇ UIDJ/ ⁇ PART ⁇ ?codec
  • Codec String Request a specific codec for the audio.
  • Default is amrnb example options are g71 Iu, g711 a, or amrnb.
  • Tempfile String Yes/No. Decides whether or not to return the url to the attachment or the attachment directly
  • Type String Type of the message e.g. voice
  • Codec String Codec of the encoded audio e.g. g71 Iu, g71 Ia, amrnb.
  • this action allows retrieval or modification of greetings, either disabling them or updating them with new information as well as information concerning the status of greetings.
  • Targeted Link ⁇ BASE ⁇ /greeting
  • the value represents the status of the greeting (e.g. disabled, enabled). . Consult the XSD for simpleType greeting_status for a definitive list.
  • this action returns the converted audio of the greeting specified in the URL. It accepts an optional query string argument to specify codec
  • the value is the HTTP authorization necessary to view the subscribers ' inbox.
  • Action String The value represents the action to take on the greeting (e.g. delete, deactivate, activate, and upload). Consult the XSD for simpleType greeting_actions for a definitive list.
  • Size Integer The value represents the size of the greeting passed to the network
  • Codec String The value represents the codec of the greeting passed to the network.
  • the value represents the base64 encoding of the greeting passed to the network.
  • the action provides access for retrieving ldap entries and performing specific subscriber settings updates.
  • the action returns LDAP values for a subscriber.
  • a list of attributes must be specified separated by &.
  • the value is the HTTP authorization necessary to view the subscribers' inbox.
  • settingname String The value represents the name of the setting retrieved settingvalue String The value represents the value of the setting retrieved
  • the action returns a set of configuration values for a specific section in the uOneXP.ini file.
  • the section is determined by using the X-Application Header passed concatenated with a ':' and the uoneconfigsection attribute in the Cos of the Subscriber.
  • X-Application This value is a header that gets passed in the GET request and is used for determining the section in uOneXP.ini to access.
  • configname This value represents the name of the entry in the uOneXP.ini file configvalue String The value represents the value of the configuration entry retrieved
  • Folder List Referring to the table below , the action returns a list of folders for the subscriber
  • the action incorporates POST and GET methods for managing folders and messages contained within.
  • the action returns a high-level presentation of the folder. Provides messages types, status, and callers.
  • Folder String The value represents the name of the folder to access
  • UID Integer The value represents the unique ID of the message in network store Argument Type Description
  • the value represents the index of the message for display purposes.
  • the value may be in order of the UID but may be in reverse order etc.
  • Subscriber Boolean Denotes whether reply is allowed for the message
  • Date String The value represents the date when the receipt of the message. This value will be localized for the user and presented in standard format for their region (e.g. DD/MM, MM/DD, etc)
  • Type String The value represents the possible different type of messages stored in the network, (e.g. voice, fax, video, email, SMS, MMS) . Consult the XSD for simpleType message_types for a definitive list.
  • CaIlId String The value represents the caller/sender of the message.
  • the service returns the localized number based on user settings.
  • Folder String The value represents the name of the folder to access
  • UID Integer The value represents the unique ID of the message in network store
  • the value represents the index of the message for display purposes.
  • the value may be in order of the UID but may be in reverse order etc.
  • Subscriber Boolean Denotes whether reply is allowed for the message
  • Date The value represents the date when the receipt of the message. This value will be localized for the user and presented in standard format for their region (e.g. DD/MM, MM/DD, etc) Argument Type Description
  • Type String The value represents the possible different type of messages stored in the network, (e.g. voice, fax, video, email, SMS, MMS) . Consult the XSD for simpleType message_types for a definitive list.
  • CaIlId String The value represents the caller/sender of the message.
  • the service returns the localized number based on user settings.
  • Calledld String The called destination or recipient of the message.
  • the service returns the localized number based on user settings.
  • the action returns details of a specific message including information concerning the attachments embedded in the message.
  • This request retrieves a specific message and provides details about the message that are not returned from the folder inventory access.
  • Folder String The value represents the name of the folder the message is in
  • UID Integer The value represents the unique ID of the message in network store
  • the value represents the index of the message for display purposes.
  • the value may be in order of the UID but may be in reverse order etc.
  • Date String The value represents the date when the receipt of the message. This value will be localized for the user and presented in standard format for their region (e.g. DD/MM, MM/DD, etc)
  • the value represents the sender of the message.
  • Subscriber Boolean Denotes whether reply is allowed for the message
  • Type String The value represents the possible different type of messages stored in the network, (e.g. voice, fax, video, email, SMS, MMS). Consult the XSD for simpleType message_types for a definitive list.
  • Calledld String The called destination or recipient of the message.
  • the service returns the localized number based on user settings.
  • Text Body String The value represents the text representation of the body of the message which may be HTML or similar textual type
  • Part Integer The value represents the specific part id.
  • this action allows the client to change the status of the messages in the inbox for the subscriber.
  • Folder String The values represents the name of the folder to access
  • Action String The value represents the type of action to take on the message (e.g. mark as read, delete, unread).
  • the action returns a URL to download the content of the attachment.
  • the action will convert the audio from the network-stored codec to a usable codec for handset.
  • Folder String The value represent the folder name where the message exists
  • Codec String Request a specific codec for the audio.
  • Default is amrnb example options are g71 Iu, g71 Ia, or amrnb.
  • Folder Reply Message Referring to the table below the action allows a user to submit a new message to subscribers on the system.
  • Type String Type of the message e.g. voice
  • Codec String Codec of the encoded audio e.g. g71 Iu, g71 Ia, amrnb.
  • Type String Type of the message e.g. voice
  • Codec String Codec of the encoded audio e.g. g71 Iu, g71 Ia, amrnb.
  • the XML Style Document (XSD) and Web Application Description Language (WADL) documents the available API; the XSD provides the XML style information of the requests an.
  • the WADL details the available requests that the server can handle. For each requests the WADL documents the arguments, request bodies and response bodies.
  • the XSD details the specifics of the XML returned by requests or provided to requests.
  • WM Visual voicemail in which voicemail messages are displayed in a visual format.
  • Failure Code generated on errors on requests or temporal data that may no longer be present ⁇

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)

Abstract

Un système de messagerie présente des dispositifs de messagerie (1) et un « serveur de messagerie complet » (« CMS », 10). Chaque dispositif (1) possède un processeur et une mémoire destinés à exécuter des applications clients (« clients », 2), en communiquant par l'intermédiaire d'une pile de protocoles (3). Le dispositif (1) peut être de n'importe quel type parmi un grand nombre de types tels qu'un ordinateur portable, un téléphone mobile, un PDA ou une télévision/un boîtier décodeur par exemple. Le CMS (10) est une liaison centrale entre les dispositifs (1) et des serveurs principaux (20), le serveur A - serveur G. Une communication entre le CMS (10) et les dispositifs (1) se fait par l'intermédiaire d'un protocole unique. Le CMS (10) a pour fonction (13) d’exécuter une normalisation des protocoles des serveurs principaux (20) sur le protocole unique. Le CMS fournit en outre des fonctions de logique combinatoire 14 qui sont exécutées sur les primitives des serveurs principaux (A à G), autorisant ainsi des primitives agrégées supplémentaires H à Z sur le protocole unique. La communication du dispositif 1 se fait par l'intermédiaire d'un seul serveur, à savoir le CMS (10), à l'aide du protocole unique. Le fait que le dispositif (1) sollicite un protocole unique, et que le CMS 10 est impliqué, est transparent par rapport serveurs principaux (20). La normalisation des divers protocoles utilisés par les serveurs principaux permet d'exécuter n'importe quel nombre de clients (2) sur le dispositif de messagerie (1) à l'aide du protocole unique. A l'intérieur de chaque client (2) n'importe laquelle des primitives des serveurs principaux (20, A – G) peut être utilisée, ou toute association de primitives des serveurs principaux (A – G) peut être utilisée.
PCT/IE2009/000024 2008-05-02 2009-05-01 Dispositif et système serveur de messagerie WO2009133544A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US7152008P 2008-05-02 2008-05-02
US61/071,520 2008-05-02

Publications (1)

Publication Number Publication Date
WO2009133544A1 true WO2009133544A1 (fr) 2009-11-05

Family

ID=40810080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IE2009/000024 WO2009133544A1 (fr) 2008-05-02 2009-05-01 Dispositif et système serveur de messagerie

Country Status (1)

Country Link
WO (1) WO2009133544A1 (fr)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2432260A1 (fr) * 2010-09-15 2012-03-21 Sony Ericsson Mobile Communications AB Gestion de dispositif utilisant une interface reposante
WO2012173752A1 (fr) * 2011-06-15 2012-12-20 Alcatel Lucent Interface entre des services web de type rest et des réseaux à commutation de paquets en vue de la transmission de messages texte
US8745394B1 (en) 2013-08-22 2014-06-03 Citibank, N.A. Methods and systems for secure electronic communication
EP2533603A4 (fr) * 2010-02-03 2017-11-22 ZTE Corporation Procédé, appareil et n ud de service de liaison montante pour réaliser un pilotage de service côté service
CN110086704A (zh) * 2014-02-11 2019-08-02 阿里巴巴集团控股有限公司 一种即时通讯未读消息的同步方法和系统
US20210119953A1 (en) * 2014-07-16 2021-04-22 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing instant messages between multiple clients
CN112788054A (zh) * 2021-01-27 2021-05-11 杭州萤石软件有限公司 一种物联网数据处理方法、系统及设备

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001024463A1 (fr) * 1999-09-27 2001-04-05 Cti Squared Ltd. Procede et dispositif de messagerie unifiee
WO2001048985A1 (fr) * 1999-12-28 2001-07-05 Comverse Ltd. Agregation en ligne dans un systeme de messagerie unifie
US6813507B1 (en) * 2001-05-02 2004-11-02 Cisco Technology, Inc. Unified messaging system having short message service command processor
WO2004095197A2 (fr) * 2003-04-22 2004-11-04 Voice Genesis, Inc. Systeme de messagerie omnimodale
US20050036498A1 (en) * 2003-08-11 2005-02-17 Teamon Systems, Inc. Communications system providing extensible protocol translation features and related methods
US7120455B1 (en) * 2004-05-20 2006-10-10 Cellco Partnership Method and system for mobile instant messaging using multiple interfaces

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001024463A1 (fr) * 1999-09-27 2001-04-05 Cti Squared Ltd. Procede et dispositif de messagerie unifiee
WO2001048985A1 (fr) * 1999-12-28 2001-07-05 Comverse Ltd. Agregation en ligne dans un systeme de messagerie unifie
US6813507B1 (en) * 2001-05-02 2004-11-02 Cisco Technology, Inc. Unified messaging system having short message service command processor
WO2004095197A2 (fr) * 2003-04-22 2004-11-04 Voice Genesis, Inc. Systeme de messagerie omnimodale
US20050036498A1 (en) * 2003-08-11 2005-02-17 Teamon Systems, Inc. Communications system providing extensible protocol translation features and related methods
US7120455B1 (en) * 2004-05-20 2006-10-10 Cellco Partnership Method and system for mobile instant messaging using multiple interfaces

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2533603A4 (fr) * 2010-02-03 2017-11-22 ZTE Corporation Procédé, appareil et n ud de service de liaison montante pour réaliser un pilotage de service côté service
US8438246B2 (en) 2010-09-15 2013-05-07 Sony Mobile Communications Ab Device management using a RESTful interface
WO2012035461A3 (fr) * 2010-09-15 2012-05-24 Sony Ericsson Mobile Communications Ab Gestion de dispositifs au moyen d'une interface basée sur le transfert d'état de représentation (rest)
EP2432260A1 (fr) * 2010-09-15 2012-03-21 Sony Ericsson Mobile Communications AB Gestion de dispositif utilisant une interface reposante
US20120322468A1 (en) * 2011-06-15 2012-12-20 Yigang Cai Interface between restful web services and packet-switched networks for text messaging
CN103636243A (zh) * 2011-06-15 2014-03-12 阿尔卡特朗讯 Restful web服务和分组交换网络之间用于文本消息发送的对接
US8923899B2 (en) 2011-06-15 2014-12-30 Alcatel Lucent Interface between restful web services and packet-switched networks for text messaging
KR101567292B1 (ko) * 2011-06-15 2015-11-09 알까뗄 루슨트 텍스트 메시징을 위한 레스트풀 웹 서비스들 및 패킷-교환 네트워크들 간의 인터페이스
WO2012173752A1 (fr) * 2011-06-15 2012-12-20 Alcatel Lucent Interface entre des services web de type rest et des réseaux à commutation de paquets en vue de la transmission de messages texte
US8745394B1 (en) 2013-08-22 2014-06-03 Citibank, N.A. Methods and systems for secure electronic communication
CN110086704A (zh) * 2014-02-11 2019-08-02 阿里巴巴集团控股有限公司 一种即时通讯未读消息的同步方法和系统
US20210119953A1 (en) * 2014-07-16 2021-04-22 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing instant messages between multiple clients
US11848903B2 (en) * 2014-07-16 2023-12-19 Tencent Technology (Shenzhen) Company Limited Method and system for synchronizing instant messages between multiple clients
CN112788054A (zh) * 2021-01-27 2021-05-11 杭州萤石软件有限公司 一种物联网数据处理方法、系统及设备

Similar Documents

Publication Publication Date Title
US10097486B1 (en) Messaging system and method
US7277951B2 (en) Omnimodal messaging system
TWI397277B (zh) 統一訊息服務之系統及方法
KR101506029B1 (ko) 통합 메시징 서비스를 제공하기 위한 시스템과 방법
US20020087549A1 (en) Data transmission
GB2435146A (en) Group communications
WO2009133544A1 (fr) Dispositif et système serveur de messagerie
US8315249B2 (en) Integration of voice chat services
Wong Goals for Internet Messaging to Support Diverse Service Environments
Wong RFC 4416: Goals for Internet Messaging to Support Diverse Service Environments
Wang et al. MMSEmail: Delivering Emails to Mobile Phone Through MMS
KR20070072998A (ko) 이메일을 이용한 멀티미디어 메시지 전송 시스템 및 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09738557

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09738557

Country of ref document: EP

Kind code of ref document: A1