(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY(PCT)
`
`(19) World Intellectual Property Organization
`International Bureau
`
`(43) International Publication Date
`24 January 2002 (24.01.2002)
`
`
`
`PCT
`
`QDAOATI
`
`(10) International Publication Number
`WO 02/07396 Al
`
`(51) International Patent Classification’:
`29/06
`
`HO4L 12/58,
`
`(74) Agents: LESON, Thomas, Johannes, Alois et al.; Bavari-
`aring 4, D-80336 Miinchen (DE).
`
`(21) International Application Number;=PCT/EP00/06708
`(81) Designated States (national): AE, AG, AL, AM, AT, AU,
`AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CR, CU, CZ,
`DE, DK, DM, DZ, EE, ES, FI, GB, GD, GE, GH, GM, HR,
`HU, ID, IL, IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR,
`LS, LT, LU, LV, MA, MD, MG, MK, MN, MW, MX, MZ,
`NO, NZ, PL, PT, RO, RU, SD, SE, SG, SI, SK, SL, TJ, TM,
`TR, TT, TZ, UA, UG, US, UZ, WN, YU, ZA, ZW.
`
`(25) Filing Language:
`
`(26) Publication Language:
`
`English
`
`English
`
`(22) International Filing Date:
`
`13 July 2000 (13.07.2000)
`
`(71) Applicant (for all designated States except US): NOKIA
`CORPORATION[FI/FI]; Keilalahdentie 4, FIN-02150
`Espoo (FT).
`
`(72) Inventors; and
`(75) Inventors/Applicants (for US only): STAACK, Jens
`[FI/FI]; Klaneettitie 12 D 54, FIN-00420 Helsinki (FI.
`KOSKELAINEN,Petri [FI/FI]; c/o Nokia Networks Oy,
`Keilalahdentie 4, FIN-02150 Espoo (FD.
`
`(84— Designated States (regional): ARIPO patent (GH, GM,
`KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZW), Eurasian
`patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), European
`patent (AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, TE,
`IT, LU, MC, NL, PT, SE), OAPI patent (BF, BJ, CF, CG,
`CI, CM, GA, GN, GW, ML, MR, NE, SN, TD, TG).
`
`Published:
`
`with international search report
`
`[Continued on next page]
`
`(54) Titles METHOD AND SYSTEM PROVIDING A MESSAGINGSERVICE
`
`MUAAIANTAA
`
`O02/07396Al
`
`USER
`
`MESSAGE
`
`ser_b@sonera.com
`
`l
`
`4
`
`/ USER
`DATABASE
`
`USER B
`OUT OF
`REACH
`
`3
`
`USER B:
`Out-of-Reach
`Store& Fw: Notify
`Accepts:jpeg, gif
`
`USER C:
`SIP: 172.3.2.2
`Store&Fw: to e-mail
`
`Save
`Message
`
`SIP Store &
`Forward
`
`SERVER
`
`(57) Abstract: The inventionis directed to a instant messaging method and communication system comprising one or more network
`elements, wherein a connection from one to another network element can be established using a protocol which allows the sending
`of one or more messages from the one to the another network element as part of one or more protocol words. The protocol includes
`a protocol portion allowing a network element to specify whether or not the messageis to be storedin case it cannot be promptly
`delivered to the another network element. The protocol portion preferably is part of the protocol header. The protocol may be a
`Session Initiation Protocol (SIP), and the message can be contained in an Invite request sent from the sending equipment to the
`receiving equipment.
`
`I
`
`Facebook Ex. 1020
`Facebook Ex. 1020
`U.S. Pat. 8,243,723
`USS. Pat. 8,243,723
`
`

`

`WO 02/07396 Ad
`
`__IMITINIINNININ INITIN0i000HUNTAT
`
`For two-letter codes and other abbreviations, referto the "Guid-
`ance Notes on Codes and Abbreviations" appearing at the begin-
`ning ofeach regularissue ofthe PCT Gazette.
`
`Il
`II
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`METHOD AND SYSTEM PROVIDING A MESSAGING SERVICE
`
`FIELD OF THE INVENTION
`
`The invention relates to a communication method and system
`
`implementing a messaging service
`
`10
`
`LS
`
`BACKGROUND OF THE INVENTION
`
`Several networks provide messaging services which allow
`messages to be sent
`from one to another network terminal
`without necessity of actually initiating a call. For
`
`instance, a plurality of GSM networks support a short
`
`message service (SMS) which permits the transmission of
`
`short messages. A more recent development is the multimedia
`
`messaging service (MMS) which allows the transmission not
`
`20
`
`only of text messages but also of pictures and the like.
`
`Both these SMS and MMS are store-and-forward messaging
`
`services which necessitate additional network elements
`
`(e.g. SMSC, Short Message Service Center) and dedicated
`
`protocols such as specified in ETSI TS 23.040.
`
`25
`
`30
`
`35
`
`Moreover,
`
`the Internet provides a direct user-to-user
`
`messaging for chatting or instant messaging (e.g. using
`Instant Messaging/Presence Protocol IMPP). Further,
`the
`
`Internet offers a store-and-forward messaging, e.g. e-mail
`service (POP3 "Post Office Protocol, version 3" or IMAP4
`"Internet Message Access Protocol, Version 4").
`
`Presently,
`
`some instant messaging services are either based
`
`on existing standards, or are proprietary solutions such as
`
`AOL instant messaging service. Some requirements of future
`
`instant messaging services are defined in IETF RFC 2778 and
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`RFC 2779. The instant messaging service requests both .
`
`sender and receiver to be on-line and registered to the
`
`instant messaging server. When the receiver is e.g. not
`
`reachable, no instant message can be delivered.
`
`10
`
`For establishing a bidirectional connection between a
`
`caller and a callee, several call control protocols such as
`
`SIP (Session Initiation Protocol, see e.g. RFC 2543 and RFC
`
`2543bis) are proposed. SIP may not only be used as a call
`
`control protocol but also offers the possibility of being
`used as instant messaging service. For instance,
`the SIP
`INVITE message can be used to carry content payloads (MIME
`types such as JPEG)
`inside one protocol message without the
`need of actually setting-up a voice-over-IP (VoIP) call.
`
`15
`
`Other SIP message types (e.g.
`
`INFO) may also be used and
`
`new message types may be defined for this purpose. Note
`
`that the INVITE message is a signalling message. As an
`
`example, a user A may include the following MIME-payloads
`
`into one INVITE message for the user B:
`
`20
`
`- image/jpeg (e.g.
`
`to send a picture)
`
`- audio/midi (e.g. for playing a sound clip).
`
`All such information fits into one SIP message.
`
`Fig.
`
`3 shows one example of using the INVITE message as a
`
`en
`
`messaging possibility. The names and numbers of the
`
`messages shown in Fig.
`3 are as defined in RFC 2543. First,
`user A sends an INVITE message (Fl)
`to user B which message
`includes the payload. User B responds by returning "100
`Trying" (F2),
`"180 Ringing" (F3), and "200 OK"
`(F4), which
`
`confirms receipt of the message. User A then sends a "BYE"
`message (F5),
`to user B which acknowledges this message by
`returning "200 OK"
`(F6).
`Sf
`
`SIP-based messaging provides the advantage of being usable
`without need of any new network elements and is therefore
`
`cheap, and may possibly replace other messaging services.
`
`30
`
`35
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`However,
`
`for performing this SIP-based messaging, both
`
`sender and receiver must be "on-line", i.e. user B must be
`
`actually reachable.
`
`SUMMARY OF THE INVENTION
`
`The present invention aims at providing a messaging service
`
`which can easily be implemented without need of new network
`
`10
`
`elements, and which offers enhanced messaging
`
`possibilities.
`
`The present invention provides a method and/or system as
`defined in any one of the claims. Further,
`the invention
`
`15
`
`provides network element adapted to perform the necessary
`
`functions.
`
`the instant
`In accordance with one aspect of the invention,
`messaging service is enhanced by providing a storing
`
`20
`
`capability for messages. When the intended receiver of the
`
`message is presently unable to receive the message because
`
`he is e.g. not on-line, busy and/or not reachable by the
`
`network, e.g. by the proxy server of the receiving user,
`
`because of any other reason,
`
`the message may be stored.
`
`25
`
`This saving of the message enables its later delivery to
`
`the receiving user when this user is able to receive the
`
`message, e.g. after re-attachment to the network. No
`
`connection for bi-directional communication needs to be
`
`established.
`
`30
`
`The protocol normally used for initiating a connection
`, enabling e.g. a bi-directional communication between a call
`
`originating equipment and a call terminating equipment thus
`
`serves the further purpose of indicating whether or not
`
`35:
`
`transmitted instant messages are to be stored in case of
`
`impossibility of direct delivery. The protocol allowing
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`messages to be sent from the sending to the receiving .
`
`is amended so as to be
`equipment as part of the protocol,
`able to include an identifier which may be or include a
`
`store command. The store command can be,
`
`in a preferred
`
`implementation a store-and-forward command. A serving
`
`network element trying to provide a connection to the
`
`receiving equipment in vain,
`
`is preferably adapted to check
`
`the protocol with respect to the inclusion of such an
`identifier representing a store command. When the store
`
`10
`
`command is found,
`
`the message is not simply discarded but
`
`is stored in an appropriate place, such as in an own memory
`of this network element, or in a storage of another network
`element such as a server.
`re
`
`15
`
`As the identifier can be included in the protocol,
`
`the
`
`message and the identifier (e.g. store command) can be
`
`transmitted in a unidirectional manner from the sending
`
`equipment to the serving network element provided for
`
`establishing connections to the receiving equipment. This
`
`20
`
`feature significantly reduces the signalling and traffic
`
`load necessary for transmitting and handling messages.
`
`In
`
`addition, no new protocols for messaging are necessary, and
`
`the invention can be implemented in existing networks in an
`
`inexpensive manner. Furthermore, no new network elements
`
`25
`
`are necessary for implementing the invention, so that the
`
`disclosed technique is easily and inexpensively deployable
`by a network operator or service provider. This messaging
`service structure may also replace existing messaging
`
`services and hence contribute to a harmonisation of
`
`30
`
`messaging services.
`
`The protocol preferably used is the Session Initiation
`
`Protocol SIP. The protocol comprises a portion allowing a
`
`network element, preferably the sending network element,
`
`to
`
`35
`
`specify whether or not the message is to be stored, or
`
`stored-and-forwarded, by respectively setting or including
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`the identifier. This protocol portion is preferably part of
`
`the protocol header. The message receiving element which
`
`may be the serving network element serving the presently
`
`unreachable receiving network element,
`
`is able to easily
`
`check the protocol header with regard to existence of such
`
`a store, or store-and-forward, command, and will decide on
`
`storing or discarding of the message depending on the
`
`command included in the protocol header (if any).
`
`10
`
`The message is preferable sent in an INVITE request or in
`
`other SIP request sent
`equipment.
`
`from the sending to the receiving
`s
`
`15
`
`20
`
`When the command is a mere "store" command, be message
`will be stored, and the sending equipment will have to
`
`search for any stored messages, e.g. when re-attaching to
`
`the network.
`
`In case of a store-and-forward command,
`
`the
`
`system is adapted to automatically forward the message to
`
`the receiving equipment. This forwarding may e.g. be tried
`
`on a periodical basis, or may be performed when detecting
`
`that the receiving equipment can be reached again.
`
`The network element providing this storing, or storing-and-
`
`forwarding service may be a server such as a proxy server
`
`25
`
`which is already provided as part of existing networks.
`
`In the following, further aspects,
`
`features and advantages
`
`of the invention will be described with reference to some
`
`embodiments as shown in the drawings.
`
`30
`
`35
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Figs.
`
`1 and 2 illustrate a preferred embodiment of a
`
`communication system in accordance with the invention;
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`Fig.
`
`3 shows the basic signalling messages between user
`
`equipments based on SIP;
`
`Figs.
`
`4 and 5 show further examples of successful SIP to
`
`SIP messaging using two proxy servers;
`
`Fig.
`
`6 illustrates the basic structure of a protocol word
`
`adapted in accordance with one implementation of the
`
`invention (based on SIP);
`
`10
`
`Fig.
`
`7 shows a flow diagram illustrating an embodiment of a
`
`method according to the invention; and
`
`= 7
`8 shows a block diagram of an embodiment of a system
`
`Fig.
`
`15
`
`in accordance with the invention.
`
`DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE
`
`INVENTION
`
`20
`
`Fig.
`
`1 shows a first embodiment of the invention and
`
`illustrates a case where a message is to be sent from a
`
`first network element 1
`
`(user A)
`
`to a second network
`
`element 3
`
`(user B). The network elements 1,
`
`3 are,
`
`in the
`
`25
`
`present embodiment, client or user equipments such as
`
`the network element
`In the present example,
`terminals.
`(user A)
`is an equipment trying to send a message (e.g.
`"MESSAGE user_b@sonera.com" addressed to user_b@sonera.com)
`
`1
`
`to the receiving element 3
`
`(user B) which is presently out
`
`30
`
`of reach, e.g. switched-off, busy, or located in a non-
`supported area, or the like. The connection request of
`
`network element 1 is handled by a network element 2 which
`
`may be a server (such as a proxy server) which provides
`
`e.g. CSCF (Call Server Control Function), and/or is a home
`
`35
`
`location server which contains a database storing
`
`information on the present locations of network element 3
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`and further network elements, reachability thereof, and the
`
`like.
`
`As shown in Fig. 1,
`
`the server 2 stores parameters for
`
`several users (user equipments)
`
`to be served by server 2.
`
`These parameters define the users profiles, network
`
`capabilities, and status of the users and terminals. For
`
`user B,
`
`the server 2 stores the information "out-of-reach";
`
`"store-and-forward: notify"; "accepts:
`
`jpeg,gif", etc. This
`
`10
`
`information may be updated by the server 2 or equipment
`
`3
`
`e.g. when re-entering the serving area of server 2, or when
`
`equipment 3 wants to change or supplement the types of
`acceptable messages. The "accepts" field defines the types
`of acceptable messages. The field "store-and-forward" can
`be set by equipment 3, or by the operator or service
`
`provider of the network to "NO",
`
`"YES",
`
`"NOTIFY"
`
`(when the
`
`sending user is to be notified after successful delivery of
`
`the message to the user B)", “Forwarding Address or Service
`for forwarding messages", and the like. The operator or
`service provider may provide different storing services for
`
`different subscribers, such as no storing possibility for
`
`normal subscribers, and storing possibility for premium
`
`subscribers.
`
`L5
`
`20
`
`25
`
`The server 2 furthermore stores e.g. for user C the present
`
`IP address "172.3.2.2" for reaching user C, e.g. via SIP.
`For user C,
`the field "store-and-forward" is set to “to e-
`mail" so as to forward any incoming SIP message to the e-
`
`30
`
`mail address of user C. The server 2 preferably contains
`further information for users B, C and additional users
`served bythis server.
`
`The network additionally contains a network element such as
`
`a server 4 used for storing any SIP message not promptly
`
`35
`
`deliverable to the intended recipient. This server 4 is,
`
`in
`
`the present embodiment, not only used as a storing server
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`but also as a forwarding server for actively forwarding any
`
`stored message to the recipient, e.g. periodically or when
`
`receiving information that the recipient is reachable
`
`again.
`
`wa
`
`As mentioned above,
`
`in the example shown in Fig. 1,
`
`the
`
`user A is trying to send a message "MESSAGE
`
`USER_B@sonera.com" to user B using SIP. The SIP message is
`handled by server 2 which checks reachability of the
`
`10
`
`recipient user B and detects that user B is presently out
`
`of reach. The server 2 then checks the contents of its
`
`database field "store-and-forward" set for user B, and
`detects the condition "notify". Server 2 additionally
`checks the type of received message which,
`in the present
`example, may be a type "jpeg". When this type of message is
`
`45
`
`not comprised in the types mentioned in the field
`
`"accepts",
`
`the message is discarded. Otherwise, server 2
`
`addresses server 4 for saving the presently undeliverable
`
`message received from user A. Hence,
`
`the SIP message is
`
`20
`
`stored in the database of server 4 and waiting for later
`
`delivery to user B.
`
`Fig. 2 shows the embodiment of Fig.
`
`1 in a condition where
`
`the user equipment 3
`
`(user B) can be reached again. When
`
`25
`
`the user equipment 3 can be reached again, it will usually
`
`send a message signalling its present state or condition,
`e.g. its intention to receive access to the network. Such a
`message is shown in Fig.
`2 as step 1.) and may consist in a
`
`request "register",
`
`"PDP context activation", or the like,
`
`30
`
`depending on the type of network and the like. Such a
`
`request is addressed to server 2 which therefore recognises
`
`the reachability of equipment 3. When detecting this
`
`situation,
`
`the server 2 sends,
`
`in step 2.) of Fig. 2, a
`
`message "notify: user B is on-line" to server 4. The server
`
`35
`
`4 checks its database with regard to any waiting message or
`
`messages stored for user B. When detecting such messages,
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`the server 4 sends this message or messages directly to
`
`“MESSAGE
`user equipment 3 as shown in step 3.),
`USER_B@sonera.com". The server 4 may also be adapted to
`send a confirmation to server 2 after successful
`
`transmission of the stored messages to user equipment 3.
`
`a message
`in step 4.),
`The server 2 then preferably sends,
`to user equipment
`1
`informing the latter on successful
`delivery of the message to user equipment 3. This message
`is shown in Fig.
`2 as "NOTIFY A: contents has been
`
`10
`
`received".
`
`the server 2 changes the conditions set for
`Furthermore,
`user B from "out of reach" to e.g.
`the address of user B,
`and/or the field "store-and-forward" to "YES".
`In the
`
`latter case, any message received for user B during
`subsequent unreachability thereof will simply be stored and
`forwarded after later reachability of user B, without
`
`sending any "notify" message to user A such as shown in
`
`step 4.) of Fig. 2.
`
`15
`
`20
`
`As illustrated in Fig. 2,
`
`the server 2 may meanwhile also
`
`have changed the contents of the fields for user C from "to
`
`e-mail" (Fig.
`
`1)
`
`to "NO" based on information received from
`
`the equipment of user C or the network operator or service
`
`25
`
`provider.
`
`The present invention therefore guarantees that the message
`contents (e.g.
`image or audio contents) of a SIP message is
`
`delivered to the receiver even if the receiver should be
`
`30
`
`presently. out of reach or occupied. For achieving this
`
`function,
`
`the invention defines an extension to the syntax
`
`of a connection protocol such as SIP which allows the
`
`sender to define whether or not the message should be
`
`temporarily stored when the receiver should presently be
`
`35
`
`out of reach, and should be sent to the receiver as soon as
`
`possible. This local temporary storage of the message is
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`performed taking account of the present status of the
`receiver. The storing place may be defined by the sender by
`
`adding a storing place address to the message. The storing
`
`place may also be defined by the serving server 2.
`
`The standardisation drafts for SIP define that there may be
`
`a "request-disposition" header to specify caller
`
`preferences for the way how a server such as server 2
`should process a request. The header can include the
`
`10
`
`following items:
`
`Request-disposition = “Request-disposition" ":"
`1# (proxy-feature | cancel-feature |
`fork-feature | recurse-feature |
`parallel-feature | queue-feature |
`ring-feature)
`"proxy" | “redirect"
`"cancel" | "no-cancel"
`"fork" | "no-fork"
`"recurse" | "no-recurse"
`"parallel" | "sequential"
`"queue"
`| "no-queue"
`"ring" | “"no-ring"
`
`proxy-feature
`cancel-feature
`fork-feature
`recurse-feature
`parallel-feature
`queue-feature
`ring-feature
`
`=
`=
`=
`=
`=
`=
`=
`
`15
`
`20
`
`The invention extends this header to specify also "do-not-
`
`25
`
`store" and "store-and-forward-if-not-reached", and the
`
`like.
`
`"Do-not-store" means that this message should not be
`
`stored (e.g. it is instant in nature). "Store-and-forward-
`
`30
`
`if-not~-reached" means that this message should be stored,
`in a place defined by the sender, since it is important.
`E.g. if receiver was out-of-reach, this message is stored
`
`temporarily and sent
`
`to the receiver afterwards, as soon
`
`as possible. Usually local proxy (or e.g. yahoo like of
`
`25
`
`proxy) will be the storing place, That proxy will be
`
`subscribed to presence status service and waits for a
`
`receiver to become on-line. When the receiver becomes on-
`
`line,
`
`the proxy gets a notification, and sends the message
`
`to the receiver. After 200 OK message,
`
`the proxy also
`
`10
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`(optionally) notifies the original sender that "Message
`
`has been delivered", using SIP NOTIFY method.
`
`The above-described implementation ensures correct delivery
`
`to the receiver as soon as same is reachable again, e.g.
`
`after re-attaching to the network or terminating any
`
`ongoing call.
`
`Fig.
`
`4 shows a basic example of a SIP call performed when
`
`10
`
`trying to establish a bi-directional media connection "Both
`
`way RTP media". The example of Fig.
`
`4 shows a successful
`
`SIP to SIP connection between users A and B through two
`proxy servers, proxy 1 and proxy 2. The numbering Fl to F23
`attached to the steps of Fig.
`4 indicate the flow sequence
`
`15
`
`whereas the words or numbers in front of this step
`
`numbering are in line with the definition of the SIP
`
`protocol. As the message flow and sequence steps of Fig.
`
`4
`
`are self-explanatory, no more detailed description is
`
`necessary.
`
`20
`
`When,
`
`in accordance with the above-described embodiments,
`
`SIP is used for messaging, no "both way RTP media" is set-
`
`up. The flow may therefore proceed,
`
`in accordance with one
`
`embodiment of the present invention, as shown in Fig. 5.
`
`25
`
`There are several flow possibilities to achieve SIP-based
`
`messaging.
`
`The INVITE request message sent in step F4 of Fig.
`
`5
`
`contains the message payload (MIME types) sent from user A
`to user B.
`
`In the following, one example of the INVITE request from
`
`user A to proxy 1 is shown:
`
`30
`
`35
`
`F4
`
`INVITE A -> Proxy 1
`
`11
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`INVITE sip:UserB@ssl.wcom.com SIP/2.0
`Via: SIP/2.0/UDP here.com:5060
`From: BigGuy <sip:UserA@here.com>
`To: LittleGuy <sip:UserB@éthere.com>
`Call-ID: 12345601@here.com
`CSeq:
`1
`INVITE
`Contact: BigGuy <sip:UserA@here.com>
`Authorization:Digest username="UserA",
`WorldCom SIP",
`nonce="wf84flceczx4lae6cbhe5aea9c8e88d359", opaque="",
`uri="sip:ssl.wcom.com",
`response="42ce3cef44b22f£50c6a6071bc8"
`Content-Type: multipart/mixed;
`boundary=gc0pJq0M: 085U534c0p
`Content-Length: 147
`
`realm="MCI
`
`v=0
`o=UserA 2890844526 2890844526 IN IP4 here.com
`s=Session SDP
`c=IN IP4 100.101.102.103
`t=0 0
`:
`m=audio 49170 RTP/AVP 0
`a=rtpmap:0 PCMU/8000
`
`ectememn_=NextPart_gc0pJq0M:08jU534c0p
`Content-Type:
`image/jpeg; charset="iso~-8859-1"
`
`10
`
`15
`
`20
`
`25
`
`30
`
`RO1GODLhuQEFAfAAAAAAAP// / yHSBAEAAAEALAAAAAC5AQUBAAL+ 3 I+py+0
`P4wkUyouz3rz7D4biSJZmUAEn172ZW51lbrTNf£2jec6FrvKCt+sJhz0IMcwWO74
`bMpvO5U01RVKn1iMlqt 9wuFWoOi8dkr/mMTqu35Lb7DRet5/S6nRjP6/d8w
`/QPGO}VRLlhoyCSYqLgidO7j 4CBnCOELJF3mJdmR1Rydn5pQkamnnLWWqqJJqq
`anjaaroKG5vnSlspe4tbVrsrmOv7+80rXxAdcbIwzNaw8eNzsvLOcj fRMXWO
`jvWytvwic
`
`35
`
`40
`
`45
`
`50
`
`If there is more than one payload
`in SIP,
`then multiparty MIME is used, as shown in the above
`example (Content-Type: multipart/mixed;
`boundary=gc0OpJq0M: 08jU534c0p).
`In the payload itself there
`are different MIME-types, separated by boundary.
`
`If user B is not reachable then the immediate sending
`fails.
`
`12
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`In order to have a store and forward service in accordance
`with the invention, several possibilities are described
`below.
`
`i
`
`Using the SIP forward capabilities:
`
`User B has a "forwarding on not reachable" activated at
`
`proxy 2
`
`(which may correspond to server 2 of Figs. 1, 2).
`
`If User B can not be reached by proxy 2 then the proxy 2
`
`forwards the message to the user's B "ghost user agent" B2,
`
`10
`
`which can be a "connected" device which is always reachable
`
`/ online, such as server 4. Then user agent B2 periodically
`
`tries to forward the message (using the same SIP based
`messaging capabilities) to the User agent B of the user B.
`The periodical forwarding timer can be of any kind. It may
`
`15
`
`also be provided that the user agent B2 tries to forward
`
`the message only for a certain time and then discards it.
`
`Forwarding the message payload to the user's B e-mail
`
`address:
`
`20
`
`If user B is not reachable by the proxy 2,
`
`then proxy 2
`
`transfers the message payload (MIME type)
`
`to the user's B
`
`e-mail address (e.g. with SMTP) which may be specified in
`
`the INVITE message or which may be contained in a user
`
`profile option used by proxy 2.
`
`25
`
`30
`
`Forward to MMS server:
`
`Same as in 2, but the message payload (MIME types)
`
`is
`
`forwarded to a MMS server. MMS stands for Multimedia
`
`Messaging Service as defined in 3GPP 22.140 and 23.140. The
`
`message is delivered when user B becomes reachable by the
`MMS server. This can be part of the user's B profile.
`
`Forward to SMSC:
`
`Same as in 2, but the text part of the message (MIME type
`
`35
`
`TXT)
`
`is forwarded to the SMSC (Short Message Service
`
`13
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`Centre). The message is delivered when user B becomes
`reachable by the SMSC. This may be also part of the user's
`B profile.
`
`Fig.
`
`6 shows an example of a basic structure of a SIP
`
`protocol word adapted in accordance with the present
`
`invention. The protocol word contains a header 11 which,
`
`in
`
`accordance with the invention,
`
`includes a "store command"
`
`field (as part of the protocol word). The "store command"
`
`10
`
`field represents or includes an identifier which may be
`
`set, by the sender of the message,
`
`to the settings "store",
`
`"store-and-forward", "notify", or "do not store". The
`protocol word furthermore contains a message‘portion 12
`containing a message e.g. of MIME type, and the usual end
`field 13.
`
`In this example, a SIP INVITE message is used for carrying
`
`the payload, wherein the payload is inserted into the MIME
`
`field 12. When the receiving user B has activated
`"forwarding on not reachable" in his/her proxy server 2,
`
`the proxy server 2 will forward any received SIP message to
`
`a network element such as network element 4
`
`(ghost user
`
`agent) which is a device always connected to the proxy
`
`L5
`
`20
`
`server. The proxy server 2, or the server 4 may be adapted
`
`25
`
`to periodically try to forward any stored message (using
`
`SIP)
`
`to the user equipment 3. A maximum lifetime period can
`
`be defined for undelivered messages saved in the storing
`
`network element such as server 4. Upon expiry of the
`
`lifetime period, stored undelivered messages will be
`
`30
`
`cancelled.
`
`As discussed above,
`
`the message payload may also be re-
`
`addressed to another address when the receiving user should
`
`not be reachable or occupied or the like, and may be
`
`35
`
`addressed e.g.
`
`to the e-mail address (see the parameters
`
`14
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`stored for user C in Fig. 1), a MMS server,
`
`a SMSC, or the
`
`like.
`
`Fig.
`
`7 shows a flow chart illustrating method steps
`
`executed in an embodiment of the invention. Steps 701 to
`
`703 may be executed in a sender which may be the user
`
`equipment 1 of user A.
`
`In step 701, a messaging (i.e. no
`
`Signalling) message to be sent is received which message
`
`may be input by a user via a terminal such as keyboard,
`
`10
`
`digital camera and the like. On some embodiments message is
`
`received from another network element such as a messaging
`
`gateway acting as a gateway between the messaging system of
`the SIP based network and the WAP service centers connected
`to the GSM network. An identifier is included into, or
`
`LS
`
`added to,
`
`the message in step 702. The message and the
`
`identifier may be included into a protocol word such as
`
`SIP. Thereafter the message is sent in step 703. The sent
`
`message will be received,
`
`in step 704, by the addressed
`
`network element such as server 2 of Figs. 1, 2.
`
`20
`
`The reachability of the recipient indicated in the message
`
`or transmitting protocol is checked in steps 705 and 706.
`
`When the recipient is reachable,
`
`the message is sent to the
`
`recipient in step 707. When,
`
`to the contrary,
`
`the recipient
`
`25
`
`is presently not reachable, e.g. busy or de-attached from
`
`the network,
`
`the process proceeds to step 708 where the
`
`identifier of the received message is checked in order to
`
`decide on the temporary storing (step 709) of the message
`
`in an internal or external memory, e.g.
`
`in server 4, or
`
`immediate discarding of the message (step 710), depending
`on the status of the identifier. The status of the
`
`identifier may e.g. have the value "00" for storing,
`
`"11"
`
`for discarding,
`
`"01" for "Notify sender after delivery to
`
`the Recipient", and the like.
`
`30
`
`35
`
`15
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`When a message is stored,
`
`the step 705 may be repeatedly
`
`executed until reachability of the sender is detected. The
`
`step 705 may additionally or alternatively be triggered
`
`e.g. when the recipient attaches again to the network. When
`
`reachability is found,
`
`the stored message is read out of
`
`the memory, and is sent to the recipient, e.g.
`
`from server
`
`4 or 2.
`
`10
`
`15
`
`Fig.
`
`8 shows a block diagram of network elements of an
`
`embodiment of a system according to the invention. A sender
`80 includes a receiving means 801 for receiving a messaging
`(i.e. no signalling) message (user traffic) to be sent, and
`is adapted to execute step 701 of Fig. 7. Themessage may
`be input via a terminal such as keyboard, digital camera
`and the like, or from another network element. The sender
`
`80 further comprises an including means 802 for adding, or
`
`including, an identifier into the message, and eventually
`
`including the message into one or more protocol words of a
`
`messaging enabling protocol such as SIP, so as to carry out
`
`20
`
`step 702. A sending means 803 is adapted to execute step
`
`703,
`
`i.e.
`
`to send the protocol word(s)
`
`including the
`
`message and the identifier to a serving network element 81
`
`such as server 2.
`
`25
`
`The serving network element 81 is adapted to carry out the
`
`steps 704 to 710 shown in Fig. 7. The serving network
`element comprises a receiving means 811 for receiving
`
`messages, e.g.
`
`the protocol word(s) sent from sender 80,
`
`30
`
`and a reachability checking means 812 which checks whether
`the intended recipient 82 can be accessed so that the
`message can be promptly delivered to the intended recipient
`82. If yes,
`the message is sent to a sending means 813 of
`
`the serving network element 81. The sending means 813 sends
`
`the message to the indicated receiving address, i.e.
`
`to the
`
`35
`
`recipient 82.
`
`16
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`When the checking means 812 detects that the recipient 81
`can presently not be reached, it transfers the message to a
`checking means 814 which is adapted to check whether the
`
`message is to be stored or discarded. The checking means
`
`814 performs this check by examining the identifier
`
`included in the message or protocol word. When the
`
`identifier does not command a storing of the message,
`
`the
`
`message is discarded by a discarding means 816 which e.g.
`
`actively deletes the message or simply inhibits a storing
`
`10
`
`thereof. Otherwise, when the identifier commands the
`
`storing of the message if not promptly deliverable,
`
`the
`
`checking means 814 sends the message to a storing means 815
`which may be an internal memory or an external storage such
`as in server 4.
`
`15
`
`20
`
`25
`
`30
`
`35
`
`When the checking means 812 subsequently detects that the
`
`recipient 81 may be reached again, it either retrieves the
`
`stored message from the storing means 815 and transfers the
`
`message to the sending means 813, or instructs the storing
`
`means 815 to transmit the message to the recipient 81 via
`
`other means, e.g. server 4.
`
`According to one embodiment of the invention,
`
`the header
`
`11,
`
`in particular,
`
`the Request-Disposition part, of the SIP
`
`protocol word is newly defined so as to include an
`identifier, preferably the protocol portion "store command
`field" which may contain the commands "do-not-store" or
`"store-and-forward-if-not-reached" according to the setting
`of user A. The first header "do-not~store" informs the
`
`system that the message is of instant nature and is to be
`discarded instantly if it cannot be promptly delivered. The
`latter header "store-and-forward-if-not-reached" means that
`
`the message should be stored (usually in the local proxy or
`another storage) and forwarded, if the receiving equipment
`is presently unreachable or occupied, or the like. The
`
`proxy will be subscribed to a present status service for
`
`a
`
`

`

`WO 02/07396
`
`PCT/EP00/06708
`
`being informed on the presence status, and will wait for
`
`the receiver to becom