`
`(l 9) World Intellectual Property Organization
`International Bureau
`
`
`
`|[lllllllll||||||||||||||||||||||||||||||||||||||||||||||l|||||||||||l|||ll|||
`
`(43) International Publication Date
`24 January 2002 (24.01.2002)
`
`{I0} International Publication Number
`
`PCT
`
`WO 02/07396 Al
`
`{51) International Patent Classification":
`29tll6
`
`H04L I258,
`
`(74) Agents: LESON, Thomas. Johannes,Alois etal.; Bavari-
`an'ng 4, 0-80336 Milnehen (DIE).
`
`(2]) International Application Number:
`
`[’(Yl‘ttil’tittttltiTtJt-l
`
`(22} International Filing Date:
`
`l3 July 2000 {13.07.2000}
`
`(81) Designated States rotational): A13. AG, A]... AM. AT, AU.
`AZ, BA, BB, BG. BR, BY, BX, CA, (Tl-l, (IN. CR, CU, CZ,
`DIE, DK, DM, DZ, tilt, l'ES, It‘l, GB, GI), (31E. Gl-l, GM. HR,
`lIU, [D, [L, 1N, IS, JP, K13, KG, KP, KR. KZ, LC. LK, LR,
`
`{25} Filing Language:
`
`[English
`
`LS» LT, LU- LV, MA, MD. MG. MK, MN. MW, MX. M2.
`NO. NZ, PL, PT. RO, RU, SD, SE. SG. SI, SK. SL. TJ, TM,
`
`{25} pubnmiun Language,
`
`English
`
`’[ R, 'l'l‘, on, on. no, us, ttz. VN, YU, not, new.
`
`(71} Applicant 02» all designated States except US): NOKIA (84) Designated States fivglomlfi ARH’O Flam“t [GH- GM-
`CORPORATION lt-‘ttt-‘tl: Keilaltthdenlie 4. FIN-02150
`KE. LS. MW. M2251). SI... 521'qu 136. ZWi. Eurasian
`Iispoo (Fl).
`patent (AM. AZ. BY. KG. KZ. Ml), RIJII‘LTM). European
`patent (AT, Bil, CI [, CY, Dll, DK, [53, VI, FR, GB, GR, Hi,
`
`{72) mentors: and
`(75) lnventorstApplicants (or US onto: STAACK. Jens
`[Flt-Fl]; Klaneettitie 13 D 54, FIN-00430 Helsinki (Fl).
`KOSKELAINEN, Pctri [l'll'l‘wlIL Ck) Nolo'a Networks 0}"
`Keilalahdentio 4, HN—tiz I St) lispoo (Ft).
`
`1111.1], MC, NL, PT, SE). OAPI patent (or, BJ, CF. CG,
`“LCM- “A: GN‘ GW- Mk MR‘ NE SN‘ ""1 T“)-
`
`Published:
`with international seat-cit report
`
`[continued on next page}
`
`{5-1) Title: METHOD AND SYS’I'HM PROVIDING A MESSAGING SERVICE
`
`i
`E
`i
`
`5
`
`USER B
`OUT OF
`REACH
`
`USER
`B
`
`/
`3
`
`USER B:
`USER
`A W Out-of—Reach
`ser_b@sonera.com StorextFw: Notify
`Acceptsjpeg. 8”
`
`
`
`USERc:
`SIP: 172.322
`/ Store&Fw: to e-mail
`.... ..
`
`l
`
`2
`
`4
`
`Save
`
`Message
`
`SIP Store &
`Forward
`
`DATABASE
`
`SERVER
`
`{57) Abstract: The invention is directed to a instant messaging method and communication system comprising one or more network
`elements= wherein a connection [tom one to another network element can he established using a protocol which allows the sending
`ol‘ one or more messages from the one lo 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 message is to he attired in case it cannot be promptly
`delivered to the another network element. The protocol portion preferably is part of the protocol header. The protocol ma)r he a
`Session lnitialion Protocol (SIP), and the message can be contained in an invite request sent from the sending equipment to the
`receiving equipment.
`
`||||||||l|l|||||Illllllllllllll||||||l|||l|||||||||||||l||||l|||||||||l|||||||||
`
`O02/07396A1
`
`
`
`
`
`I
`1
`
`Facebook Ex. 1020
`Facebook Ex. 1020
`U.S. Pat. 8,243,723
`US. Pat. 8,243,723
`
`
`
`WO 02107396 A]
`
`|||||||||||||||||||||||||||||||||||||||l||||||||||||I|||||||||||||Hl|||l||||||
`
`Fbr .rwo-lefler codes and mixer abbmviatiom, ragfé'r m the "Guid-
`ance News on Codes and/1 bbrm’fafl'ous ” appearing at the begin-
`ning Qfeach regular Issue offlre PCT Gazette.
`
`
`
`II
`II
`
`
`
`W0 02!!)7396
`
`PCTI‘EPIJOIOGTGS
`
`METHOD AND SYSTEM PROVIDING A MESSAGING SERVICE
`
`5
`
`FIELD OF THE INVENTION
`
`The invention relates to a communication method and system
`
`implementing a messaging service
`
`10
`
`BACKGROUND OF THE INVENTION
`
`instant messaging services are defined in IETF RFC 2778 and
`
`Several networks provide messaging services which allow
`messages to be sent
`from one to another network terminal
`
`15
`
`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
`
`Moreover,
`
`the Internet provides a direct user-touuser
`
`messaging for chatting or instant messaging (e.g. using
`
`Instant Messaging/Presence Protocol IMPP). Further,
`
`the
`
`Internet offers a store—andwforward messaging, e.g. e—mail
`
`30
`
`service (EOP3 "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
`
`35
`
`AOL instant messaging service. Some requirements of future
`
`
`
`W0 02(07396
`
`PCTIEP00f06708
`
`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.
`
`cheap, and may possibly replace other messaging services.
`
`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
`
`10
`
`control protocol but also offers the possibility of being
`
`the SIP
`used as instant messaging service. For instance,
`INVITE message can be used to carry content payloads (MIME
`types such as JPEG)
`inside one protocol message without the
`
`need of actually settingvup a voice—over—IP (Vol?) 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 shews one example of using the INVITE message as a
`
`25
`
`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 (F1)
`
`to user B which message
`
`includes the payload. User B responds by returning "100
`
`Trying" {F2},
`
`"180 Ringing" (F3), and "200 OK"
`
`(F4), which
`
`30
`
`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].
`
`SIP-based messaging provides the advantage of being usable
`
`35
`
`without need of any new network elements and is therefore
`
`
`
`W0 021'07396
`
`PCTIEP00f06708
`
`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 andfbr system as
`
`defined in any one of the claims. Further,
`
`the invention
`
`15
`
`provides network element adapted to perform the necessary
`
`functions.
`
`impossibility of direct delivery. The protocol allowing
`
`In accordance with one aspect of the invention,
`
`the instant
`
`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 protbcol normally used for initiating a connection
`
`I enabling e.g. a bi—directional communication between a call
`Ioriginating 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
`
`
`
`WO 02307396
`
`PCTJEPHOJ'OWOS
`
`messages to be sent from the sending to the receiving_
`
`equipment as part of the protocol,
`
`is amended so as to be
`
`able to include an identifier which may be or include a
`
`store command. The store command can be,
`
`in a preferred
`
`5
`
`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.
`
`i
`
`stored—and—forwarded, by respectively setting or including
`
`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
`
`
`
`WO 02107396
`
`PCTIEPIJWOGTGS
`
`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
`
`5
`
`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
`
`from the sending to the receiving
`
`equipment.
`
`I?
`
`When the command is a mere "store" command,
`
`the message
`
`15
`
`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—andwforward command,
`
`the
`
`system is adapted to automatically forward the message to
`
`the receiving equipment. This forwarding may e.g. be tried
`
`20
`
`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.
`
`communication system in accordance with the invention;
`
`30
`
`35
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`Figs.
`
`1 and 2 illustrate a preferred embodiment of a
`
`
`
`WO 02307396
`
`PCTJEPIJOJ'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
`
`5
`
`SI? 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
`
`Fig.
`
`8 shows a block diagram of an embodiment of a system
`
`15
`
`in accordance with the invention.
`
`_i
`
`information on the present locations of network element 3
`
`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
`
`terminals.
`
`In the present example,
`
`the network element 1
`
`{user A)
`
`is an equipment trying to send a message (e.g.
`
`"MESSAGE user_b@sonera.com" addressed to user_b@sonera.com)
`
`to the receiving element 3
`
`(user B} which is presently out
`
`30
`
`of reachk e.g. switcheduoff, 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
`
`
`
`W0 02(07396
`
`PCTIEP00f06708
`
`and further network elements, reachability thereof, and the
`
`like.
`
`As shown in Fig. 1,
`
`the server 2 stores parameters for
`
`5
`
`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—ofereach";
`
`"store—andvforward: 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—andeforward" can
`
`15
`
`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
`
`20
`
`service provider may provide different storing services for
`
`different subscribers, such as no storing possibility for
`
`normal subscribers, and storing possibility for premium
`
`subscribers.
`
`the present embodiment, not only used as a storing server
`
`25
`
`The server 2 furthermore stores e.g. for user C the present
`
`I? address "172.3.2.2" for reaching user C, e.gr 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—
`
`mail address of user C. The server 2 preferably contains
`
`30
`
`further information for users B, C and additional users
`
`served by this 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
`
`
`
`WO 02307396
`
`PCTJEPHOJ'OWOS
`
`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.
`
`Ln
`
`messages stored for user B. When detecting such messages,
`
`As mentioned above,
`
`in the example shown in Fig.
`
`l,
`
`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
`
`_
`
`15
`
`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.
`
`l
`
`in a condition where
`
`the user equipment 3
`
`(user B} can be reached againx 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
`
`
`
`W0 0307396
`
`PCTIEP00f06708
`
`the server 4 sends this message or messages directly to
`
`user equipment 3 as shown in step 3.),
`
`"MESSAGE
`
`USER_B@sonera.com". The server 4 may also be adapted to
`send a confirmation to server 2 after successful
`
`5
`
`transmission of the stored messages to user equipment 3.
`
`The server 2
`
`then preferably sends,
`
`in step 4.), a message
`
`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".
`
`Furthermore,
`the server 2 changes the conditions set for
`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
`
`15
`
`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.
`
`20
`
`possible. This local temporary storage of the message is
`
`As illustrated in Fig. 2,
`
`the server 2 may meanwhile also
`
`have changed the contents of the fields for user C from "to
`
`enmail" (Fig.
`
`l)
`
`to "N0" 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
`
`
`
`WO 02307396
`
`PCTJEPIJOJ'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.
`
`5
`
`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" ":"
`l# (proxy—feature | cancelwfeature |
`fork—feature 1 recurse—feature |
`parallel—feature | queue—feature l
`ringufeature)
`"proxy" | "redirect"
`"cancel" |
`"no—cancel"
`"fork" l
`"no—fork"
`"recurse" | "no-recurse"
`
`proxy-feature
`cancel—feature
`fork—feature
`recurse—feature
`
`=
`=
`=
`=
`
`10
`
`15
`
`20
`
`parallel—feature
`queue—feature
`ring—feature
`
`=
`=
`=
`
`"parallel" | "sequential"
`"queue"
`[
`"no—queue"
`"ring" I
`"no—ring"
`
`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
`
`ianot—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
`
`35
`
`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
`
`
`
`W0 02!!)7396
`
`PCTIEPIJOI'UG'IGB
`
`(optionally) notifies the original sender that "Message
`
`has been delivered", using SIP NOTIFY method.
`
`The above—described implementation ensures correct delivery
`
`5
`
`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 F1 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 Selfuexplanatory, 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
`
`30
`
`to user B.
`
`ll
`
`In the following, one example of the INVITE request from
`
`user A to proxy 1 is shown:
`
`35
`
`F4
`
`INVITE A —> Proxy 1
`
`
`
`WO 02307396
`
`PCTJEPHOJ'OWOS
`
`INVITE sip:UserB@ssl.wcom.com SIP/2.0
`Via: SIP/2.0/UDP here.com:5060
`
`From: BigGuy (sip205erA@here.com>
`To: LittleGuy <sip:UserB@there.com>
`Call—ID: 12345601@here.com
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`INVITE
`1
`CSeq:
`Contact: BigGuy <sip:UserA@here.oom>
`Authorization:Digest username="UserA",
`WorldCom SIP",
`nonce="wf84flceczx41ae€cbe5aea9c8e88d359",
`
`realm="MCI
`
`opaque="",
`
`uri="sip:ssl.wcom.com",
`response="420e3oef44b22f5006a607lbo8"
`Content-Type: multipart/mixed;
`boundary=gc0pJq0Mz08j053400p
`Content—Length: 147
`
`v=0
`o=UserA 2890844526 2890844526 IN IP4.here.oom
`s=Session SDP
`c=IN 1P4 100.101.102.103
`t=0 0
`.
`m=audio 49170 RTP/AVP 0
`
`a=rtpmapz0 PCMU/BOOO
`
`———— ——_=_NextPart_gc0pJq0M:08j0534c0p
`Content~Typez image/jpeg; charset="iso~8859—l"
`
`R016001huQEFAfAAAAAAAP///yH5BABAAAEALAAAAACSAQUBAAL+jI+py+0
`P4wKUyouz3rz7D4biSJZmUAEnl7ZW51brTNf2jecGFrvKC+thzOIMcWQ7Z
`bMvaSU0lRVKnliMlqt9quwoOi8dkr/mMTqu35Lb7DRetS/S6nRjPG/dBw
`/0PGOjVR1hoyCSYngIdOj4CBnCOE1JF3meR1RydanQkamnnlWquJJqq
`anjaaroKGSvnSlspe4thrsrmOv7+8QrXAdcwazNaw8estvLchfRMXWO
`ijythlC
`
`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=gc0pJq0M=08j053400p).
`In the payload itself there
`are different MIME—types, separated by boundary.
`
`If user B is not reachable then the immediate sending
`fails.
`
`
`
`12
`
`
`
`
`
`W0 02!!)7396
`
`PCTIEPIJOI'UG'IGB
`
`In order to have a store and forward service in accordance
`
`with the invention, several possibilities are described
`below.
`
`(j
`
`H 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" 32,
`
`10
`
`which can be a "ccnnected" 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 Bfof 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.
`
`13
`
`2. 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
`
`3. 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.l40 and 23.140. The
`
`30
`
`message is delivered when user B becomes reachable by the
`
`MMS server. This can be part of the user‘s B profile.
`
`4. 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
`
`
`
`WO 02307396
`
`PCTJEPHOJ'OWOS
`
`Centre}. The message is delivered when user B becomes
`reachable by the SMSC. This may be also part of the user‘s
`
`B profile.
`
`5
`
`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 messagefportion 12
`containing a message e.g. of MIME type, and the usual end
`field 13.
`
`15
`
`14
`
`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
`
`2O
`
`"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
`
`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
`
`
`
`W0 02f07396
`
`PCTI‘EPIJOIOGTOS
`
`stored for user C in Fig. 1), a MMS server,
`
`a SMSC, or the
`
`like.
`
`15
`
`Fig.
`
`7 shows a flow chart illustrating method steps
`
`5
`
`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
`
`15
`
`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 ?08 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
`
`30
`
`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, "ll"
`
`for discarding,
`
`"01" for "Notify sender after delivery to
`
`the Recipient", and the like.
`
`35
`
`
`
`W0 02(07396
`
`PCTIEP00f06708
`
`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
`
`5
`
`reachability is found,
`
`the stored message is read out of
`
`the memory, and is sent to the recipient, e.g.
`4 or 2.
`
`from server
`
`16
`
`Fig.
`
`8 shows a block diagram of network elements of an
`
`10
`
`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. Thegmessage may
`be input via a terminal such as keyboard, digital camera
`
`15
`
`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 ?02. 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,
`
`and a reachability checking means 812 which checks whether
`
`30
`
`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.
`
`
`
`WO 02307396
`
`PCTJEPIJOJ'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
`
`5
`
`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.
`:
`
`17
`
`15
`
`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
`
`20
`
`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
`
`25
`
`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
`
`30
`
`system that the message is of instant nature and is to be
`discarded instantly if it cannot