l|||||||||||||ll||l||||||||l|||||||||||||||||||||l|l||||l|||l|||||||||||||||||||||||||||||
`
`US 20030236892A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0236892 A1
`Coulombc
`(43) Pub. Date:
`Dec. 25, 2003
`
`(54) SYSTEM FOR ADAPTATION OF SIP
`MESSAGES BASED ON RECIPIENT’S
`TERMINAL CAPABILITIES AND
`PREFERENCES
`
`(76) Inventor; Stephane Coulombe, Irving, TX (Us)
`
`Correspondence Address;
`WARE FRESSOLA VAN DER SLUYS &
`ADOLPHSON, LLP
`BRADFORD GREEN BUILDING 5
`755 MAIN STREET, P O BOX 224
`MONROE, CT 06468 (US)
`
`(21) Appl. No.:
`
`10/161,223
`
`(22) Filed:
`
`May 31, 2002
`
`Publication Classi?cation
`
`(51) Int. Cl.7 ................................................... .. G06F 15/16
`(52) US. Cl. ............................................................ .. 709/228
`(57)
`ABSTRACT
`A system of Session Initiation Protocol (SIP) terminals
`capable of processing SIP messages and SIP servers that
`perform selected functions at the request of the SIP termi
`nals, includes a SIP server (12) for pre-registering capabili
`ties and user preferences of a registering terminal (15) after
`resolution by a Capability Negotiation Manager (16), and
`for subsequently receiving an incoming SIP message from a
`sending terminal (19) indicating a message intended for the
`pre-registered terminal, and adaptation means (20) for
`adapting the incoming message to meet the capabilities and
`user preferences of the pre-registered terminal for transmis
`sion by the SIP server to the pre-registered terminal.
`
`13
`
`I_
`I
`I
`I
`I
`l
`|
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I
`I-
`
`MEANS FOR
`RECEIVING SIP
`MESSAGES
`
`MEANS FOR
`RECEIVING SIP
`REGISTER MESSAGES
`
`2
`
`_______________________________ “_|
`32
`14
`'
`I
`I
`I
`|
`|
`I
`l
`I
`l
`I
`I
`I
`I
`I
`I
`I
`I
`SIP PROXY / REGISTRAB
`
`1 38
`
`SIP PROXY/REGISTRAR
`F’
`CONTROL
`36 j
`60 I 58 ‘(I
`MEANS FOR
`STORING/RETRIEVING
`REGISTRATION
`INFORMATION
`(CONTACT+
`CAPABILITIES)
`
`f 34
`
`L 30
`
`74
`
`76 2 22
`MEANS FOR
`SENDING
`ADAPTED SIP
`MESSAGES
`
`62
`
`54
`
`_ _ _ I 16
`I_
`I
`I
`I
`I
`I
`I
`I
`I
`I MEANS FOR I 44
`I EXTRACTING
`MEANS FOR
`I CAPABlLITY
`OBTAINING J 50
`I INFORMATION
`CAPABILITIES
`I
`FROM THE
`I
`FROM URLs
`I
`MESSAGE
`I
`(INCLUDING
`|
`EXPLICIT
`I CAPABILITIES)
`|
`I
`I
`I
`I
`I
`
`38 7
`
`40
`Z
`42
`
`II
`CAPABILITY
`NEGOTIATION
`MANAGER
`CONTROL
`48
`
`I
`l
`f 46 l
`I
`V
`l
`TERMH‘IAL I
`CAPABILITY I
`I
`
`l I CAPABILITY
`I
`LNEGOTIATION MANAGER J
`
`j 20
`1 12
`_| F _____________ “Tl
`I I
`64
`|
`I I
`MESSAGE 5 I
`56 II
`ADAPTATION A 72 I
`I I
`ENGINE
`I
`3
`I l
`CONTROL
`l
`MEANS FOR I I
`I 70 I
`COMBINING I I
`I
`CAPABILITIES II
`I
`l
`I I
`MEANS FOR I
`I I
`ADAPTATING I
`II
`MESSAGE
`I
`I I
`AND ITS
`I
`I I
`COMPONENTS '
`I |
`I
`I I
`l
`'
`I
`I
`'
`l
`I
`MEANS FOR
`I
`I
`COMPARING
`I
`l
`l
`AND
`I
`I
`DETERMINING
`I
`I
`I MESSAGE ADAPTATION
`I
`IEIGINE
`J
`______________ _ _
`
`68
`J-
`
`WhatsApp Inc.'s Exhibit 1003
`
`001
`
`

`
`Patent Application Publication Dec. 25, 2003 Sheet 1 of 2
`
`US 2003/0236892 A1
`
`10 1‘
`
`12
`
`1. Send SIP Message
`_§ ’
`1 8
`
`15
`1. SIP REGISTER (capability data)
`- “
`_§
`1 4
`Re gistrar
`
`3. Send adapted SIP Message
`224
`
`480x640, 72kb, JPEG
`
`Capability
`Negotiation
`16 1 Manager
`
`240x320, 27kb, JPEG
`
`Message
`Adaptation
`Engine ; 2O
`
`FIG. 1
`
`Message
`
`Nessagir'—‘ ‘““—— I
`
`a
`
`2 _l
`
`Y
`
`~
`
`in
`
`a
`
`.
`
`Nbssaga
`
`g
`ea 1
`i l
`i
`I
`i
`
`E
`
`FIG. 2
`
`WhatsApp Inc.'s Exhibit 1003
`
`002
`
`

`
`Patent Application Publication Dec. 25, 2003 Sheet 2 0f 2
`
`US 2003/0236892 A1
`
`I_ ________________________________________ _ _ _|
`
`I
`I
`I
`
`I
`I
`I
`I
`I
`
`I
`I
`I
`I
`I
`I
`I
`l
`I
`I
`L
`
`MEANS FOR
`RECEIVING SIP
`MESSAGES
`
`32
`‘I
`
`MEANS FOR
`RECEIVING SIP
`REGISTER MESSAGES
`
`14 Z
`
`I
`'
`l
`I
`l
`l
`I
`I
`l
`l
`6
`I
`222:
`7
`MEANS FOR
`SENDING
`ADAPTED SIP
`MESSAGES
`
`18
`
`\L 38
`
`f 34
`
`SIP PROXY/REGISTRAR
`F’
`CONTROL
`
`L 30
`
`74
`
`36
`
`I
`
`j
`60 “I 58 3,
`I
`I
`MEANS FOR
`I
`STORING/RETRIEVING
`I
`I
`REGISTRATION
`I
`|
`INFORMATION
`l
`I 62
`(CONTACT+
`I
`I
`SIP PROXY / REGISTRAR-I
`CAPABILITIES)
`I
`515 ___________ “ i1} ___________ “E50
`
`F“- ______________________ “ I" __________ n “"‘l
`
`i 54
`
`I
`64
`I
`_I I
`MESSAGE I I
`I I
`56 II > ADAPTATION
`72 I
`II S
`I I
`ENGINE
`I
`I
`CONTROL
`MEANS FOR II
`I 70 I
`COMBINING I I
`I
`CAPABILITIES I I
`I
`l I
`MEANS FOR I
`66
`I
`I I I ADAPTATING I
`II
`MESSAGE
`I
`II
`I I
`AND ITS
`I
`I I
`COMPONENTS '
`I I
`I
`I I
`I
`I
`I
`I
`I
`J I
`I
`MEANS FOR
`I
`I
`COMPARING 5 68
`I
`I
`AND
`I
`I
`DETERMINING
`I
`I
`I
`' MESSAGE ADAPTATION
`l
`I
`
`5 50
`
`40
`
`38 2
`
`I
`CAPABILITY
`NEGOTIATION
`MANAGER
`CONTROL
`48
`
`I
`46 I
`V f I
`TERMINAL I
`
`I
`I
`I
`I
`I
`42
`I
`I S
`I MEANS FOR I 44
`'
`I EXTRACTING
`MEANS FOR
`I
`CAPABILITY
`I
`OBTAINING
`INFORMATION
`I
`CAPABILITIES
`FROM THE
`I
`FROM URLs
`I
`MESSAGE
`I
`(INCLUDING
`I
`EXPLICIT
`I CAPABILITIES)
`I
`I
`I
`I
`'
`I
`I
`
`DATABASE I
`I
`|
`l
`I CAPABILITY
`l
`LNEGOTIATION MANAGER-J‘
`
`INTERNET
`
`—————————————— ——
`
`F IG. 3
`
`WhatsApp Inc.'s Exhibit 1003
`
`003
`
`

`
`US 2003/0236892 A1
`
`Dec. 25, 2003
`
`SYSTEM FOR ADAPTATION OF SIP MESSAGES
`BASED ON RECIPIENT’S TERMINAL
`CAPABILITIES AND PREFERENCES
`
`TECHNICAL FIELD
`
`[0001] The present invention relates to interoperability
`betWeen terminal devices using session initiation protocol
`(SIP) messages and, more particularly, to multimedia con
`tent adaptation.
`
`BACKGROUND ART
`[0002] Interoperability is of paramount importance in
`messaging. Users expect that messages Will reach their
`destination and Will be handled properly by the recipient’s
`terminal. But emerging mobile terminals have made this
`requirement more challenging, due to the Wide diversity of
`terminal characteristics: display siZe and resolution, avail
`able memory, formats supported, etc. Sometimes the net
`Work also imposes limitations (e.g. maximum message siZe
`over UDP).
`[0003] Content adaptation Was addressed in publication
`EP 1 091 601 A2 in Which a sending terminal ?rst checked
`With a special application service center regarding an
`intended recipient terminal to ?nd out if it could process a
`multimedia message. The service center contacted the
`intended recipient terminal to ?nd out its capabilities. If the
`intended recipient terminal Was not able, the message Was
`posted to a special Website and the intended recipient
`terminal Was sent an SMS message With a URL to access the
`message over the Internet using a PC.
`
`[0004] An example of a Web broWser user interface for
`loW resolution displays can be found in co-oWned, co
`pending US. patent application Ser. No. 09/845,818 ?led
`Apr. 30, 2001 Where less than the full extent of high
`resolution Web site content can be selected for vieWing on a
`loW resolution display, for instance in a broWsing cell phone.
`An example shoWs the fall extent of the Web page content
`doWnloaded to memory in the cell phone and the subsequent
`processing of that content in the cell phone based on a user’s
`selection of a small portion of the full page.
`
`[0005] HoWever, it appears that media content adaptation
`proxies Will play an important role in maintaining interop
`erability and increasing user experience in many domains of
`applications including messaging. These proxies, commonly
`referred as transcoding proxies, actually transform media
`content to make it suitable for the destination terminal. For
`instance, one such transformation is format conversion, e.g.
`PNG to GIF.
`[0006] Although the need for such transcoding proxies is
`clear, the frameWork to facilitate adaptation is not. One
`exception to this is the speci?c case of broWsing. In broWs
`ing, methods to adapt Web pages to different end users have
`been addressed in the past. But those solutions can’t be
`applied directly to all applications. The dynamics of other
`applications are often very different from broWsing. For
`instance, in broWsing, the destination terminal type is knoWn
`since such information is provided in the request for content
`(e. g. User-Agent header in HTTP). In SIP (Session Initiation
`Protocol) messaging, the recipient doesn’t “make a request”
`to receive a message; it arrives Without advance Warning. A
`different mechanism is therefore required in the proxy to
`obtain the recipient’s terminal capabilities.
`
`[0007] The invention tries to overcome the problem of
`interoperability betWeen terminals and to improve the end
`user experience by providing a frameWork for making SIP
`messages conform to the recipient’s terminal capability and
`characteristics. First the message must be able to reach the
`recipient. Message siZe reduction may be required for the
`message to reach the destination terminal due to limited
`terminal memory or netWork restrictions. The second aspect
`relates to the usability of the received message. It needs to
`be ensured that the content has the appropriate formats,
`characteristics (e.g., image resolution or audio sampling
`rate), and presentation (looks good on the small display).
`The invention describes the mechanisms that make possible
`such adaptation based on the destination terminal charac
`teristics and user preferences.
`
`[0008] The problem Was not solved for SIP messages. The
`need for transcoding services is Well-knoWn. In B. Carpen
`ter, S. Brim, “Middleboxes: taxonomy and issues,” draft
`carpenter-midtax-01.txt, IETF, Internet Draft, April 2001,
`transcoders are de?ned as:
`
`[0009] “Transcoders are boxes performing some type of
`on-the-?y conversion of application level data. Examples
`include the transcoding of existing Web pages for display on
`hand-held Wireless devices, and transcoding betWeen vari
`ous audio formats for interconnecting digital mobile phones
`With voice-over-IP services. By de?nition, such transcoding
`cannot be done by the end-systems, and at least in the case
`of voice, it must be done in strict real time With extremely
`rapid failure recovery. Not all media translators are manda
`tory. They may just be useful in case of multicast, for
`example, Where all the loW-bandWidth receivers sit in one
`“corner” of the netWork and it Would be inef?cient for the
`sender to generate tWo streams or send both stream all the
`Way across the netWork if the “thin” one is only needed far
`aWayfrom the sender. Generally, media translators are only
`useful if the tWo end systems don’t have overlapping codecs
`or if the overlapping set is not a good netWork match.”
`
`[0010] There is no mention of hoW this could Work in
`practice in the context of SIP messages. This requires a
`solution different from the Well-knoWn problem of informa
`tion broWsing. In broWsing, a terminal making a request for
`a Web page Will provide his terminal capabilities (often in
`the form of header ?elds: User-Agent, Accept, Accept
`Encoding, etc.). The Web server Will resolve the terminal
`capabilities, compose an appropriate Web page response and
`send it. GateWays (such as WAP gateWays) also knoW the
`terminal capabilities from the Web page request and can
`perform adaptation accordingly.
`[0011] In SIP, the messages ?oW from a sender to a
`recipient. The proxy is in the middle and doesn’t knoW the
`capabilities of the recipient since the recipient did not
`initiate the request. This changes the application dynamics
`and the adaptation frameWork used in broWsing doesn’t
`apply directly for SIP messages. A neW adaptation frame
`Work is required. There is no earlier solution providing a
`frameWork for SIP message adaptation.
`
`DISCLOSURE OF INVENTION
`[0012] An object of the present invention is to provide a
`frameWork for SIP message adaptation services.
`
`[0013] Amethod, according to a ?rst aspect of the present
`invention, comprises the steps of receiving at a server from
`
`WhatsApp Inc.'s Exhibit 1003
`
`004
`
`

`
`US 2003/0236892 A1
`
`Dec. 25, 2003
`
`a registering or subscribing terminal a message having
`information indicative of capabilities or user preferences of
`the registering or subscribing terminal, and storing the
`information for later comparison With the characteristics of
`an incoming message from another entity and adaptation of
`the incoming message to match the capabilities or user
`preferences of the registering or subscribing terminal, if
`needed.
`
`[0014] In further accord With the ?rst aspect of the present
`invention, the method further comprises the steps of receiv
`ing the incoming message, comparing the capabilities or
`user preferences of the registering or subscribing terminal
`With the characteristics of the incoming message from the
`other entity, adapting the incoming message to the capabili
`ties or user preferences of the registering or subscribing
`terminal, and sending an adapted message to the registering
`or subscribing terminal.
`
`[0015] In still further accord With the ?rst aspect of the
`present invention, the step of comparing is carried out by a
`message adaptation engine in communication With the
`server.
`
`[0016] Further still in accord With the ?rst aspect of the
`present invention, the step of adapting is carried out by a
`message adaptation engine in communication With the
`server.
`
`[0017] According further to the ?rst aspect of the present
`invention, the steps of receiving the incoming message and
`sending the adapted message are carried out at the server.
`
`[0018] According still further With the ?rst aspect of the
`present invention, the method further comprises the step of
`determining the capabilities or user preferences of the reg
`istering or subscribing terminal from the message received
`by the server from the registering or subscribing terminal
`prior to the step of storing. The step of determining may be
`carried out by a capability negotiation manager.
`
`[0019] Still further in accord With the ?rst aspect of the
`present invention, the message received at the server from
`the registering or subscribing terminal is a session initiation
`protocol (SIP) register or subscribe message.
`[0020] In accordance still further With the ?rst aspect of
`the present invention, the incoming message from the other
`entity is an SIP message. Likewise, the adaptation of the
`incoming message may be an adaptation of the incoming SIP
`message for sending an adapted SIP message to the regis
`tering or subscribing terminal.
`
`[0021] Further still in accord With the ?rst aspect of the
`present invention, the registering or subscribing terminal is
`a mobile terminal. Likewise, the other entity may be a
`mobile terminal, although it could be a server or any other
`kind of entity.
`
`[0022] A device, according to a second aspect of the
`present invention, comprises means for receiving at a server
`from a registering or subscribing terminal a register or
`subscribe message having information indicative of capa
`bilities or user preferences of the registering or subscribing
`terminal, and means for storing the information for later
`comparison With characteristics of an incoming message
`from another entity and adaptation of the incoming message
`to match the capabilities or user preferences of the register
`ing or subscribing terminal, if needed.
`
`[0023] In further accord With the second aspect of the
`present invention, the device further comprises means for
`receiving the incoming message, means for comparing the
`capabilities or user preferences of the registering or sub
`scribing terminal With the characteristics of the incoming
`message from the other entity, means for adapting the
`incoming message to the capabilities or user preferences of
`the registering or subscribing terminal, and means for send
`ing an adapted message to the registering or subscribing
`terminal. The means for comparing may comprise a message
`adaptation engine in communication With the server. The
`means for adapting may comprise a message adaptation
`engine in communication With the server. The means for
`receiving the incoming message and the means for sending
`the adapted message may both be in the server.
`[0024] In still further accord With the second aspect of the
`present invention, the device further comprises means for
`resolving the capabilities or user preferences of the regis
`tering or subscribing terminal from the message received by
`the server from the registering or subscribing terminal. The
`means for resolving may comprise a capability negotiation
`manager.
`[0025] In accordance still further With the second aspect of
`the present invention, the register or subscribe message from
`the registering or subscribing terminal is a session initiation
`protocol (SIP) message.
`[0026] Further still in accord With the second aspect of the
`present invention, the incoming message from the other
`entity is an SIP message.
`[0027] According still further to the second aspect of the
`present invention, the adapted message is an adapted SIP
`message.
`[0028] In further accord With the second aspect of the
`present invention, the registering or subscribing terminal is
`a mobile terminal.
`[0029] A system having terminals that are capable of
`processing messages and servers that perform selected func
`tions at the request of terminals, according to a third aspect
`of the present invention, includes a server for receiving a
`registration or subscription request message from a regis
`tering or subscribing terminal, a capability negotiation man
`ager for receiving a request from the server to resolve
`capabilities or user preferences of the registering or sub
`scribing terminal, for resolving the capabilities or user
`preferences, and for providing information concerning the
`capabilities or user preferences back to the server, Wherein
`the server, in response to a subsequently received incoming
`message from a sending entity or terminal intended for the
`registering or subscribing terminal provides both the incom
`ing message and the information concerning the capabilities
`or user preferences for use in adapting the incoming mes
`sage, and adaptation means, responsive to the incoming
`message and the information concerning the capabilities or
`user preferences from the server, for adapting the incoming
`message to a format determined by comparing characteris
`tics of the incoming message to the information concerning
`the capabilities or user preferences of the registering or
`subscribing terminal for transmission of an adapted incom
`ing message in that format by the server to the registering or
`subscribing terminal.
`[0030] In further accord With the third aspect of the
`present invention, the registration or subscription request
`
`WhatsApp Inc.'s Exhibit 1003
`
`005
`
`

`
`US 2003/0236892 A1
`
`Dec. 25, 2003
`
`message from the registering or subscribing terminal is a
`session initiation protocol (SIP) message.
`
`[0031] In still further accord With the third aspect of the
`present invention, the incoming message from the sending
`entity or terminal is an SIP message.
`
`[0032] Still further in accord With the third aspect of the
`present invention, the adapted incoming message is an SIP
`message.
`
`[0033] Further still in accord With the third aspect of the
`present invention, the registering or subscribing terminal is
`a mobile terminal.
`
`[0034] A method for use by a device, according to a fourth
`aspect of the present invention, comprises the steps of
`providing a registration or subscription message to a server,
`the message having information indicative of capabilities of
`the device or preferences of a user of the device for purposes
`of registering or subscribing the capabilities or user prefer
`ences at the server for later comparison at the server With
`characteristics of an incoming message from another entity
`and adaptation of the incoming message to match the
`capabilities of the device or user preferences, if needed, and
`receiving an adapted message from the server meeting the
`capabilities or user preferences.
`
`[0035] In further accord With the fourth aspect of the
`present invention, the device is a mobile terminal.
`
`[0036] In still further accord With the fourth aspect of the
`present invention, the registration or subscription message is
`a session initiation protocol (SIP) message.
`
`[0037] Further still in accord With the fourth aspect of the
`present invention, the adapted message is an adapted SIP
`message.
`
`[0038] Advantages of the invention include:
`
`[0039] 1) AlloWing interoperability betWeen termi
`nals: increased revenues for operators, increased user
`experience.
`[0040] 2) Compatibility With existing SIP protocol
`and messaging extensions.
`
`[0041] a) Works With many SIP registrations or
`subscription methods present and future (e.g.
`REGISTER and SUBSCRIBE methods). In the
`scope of this invention, We refer as “register
`message” all registration and subscription requests
`from the terminal.
`
`[0042] b) Works With many SIP messages present
`and future including Instant Messages and noti?
`cations (e.g. MESSAGE and NOTIFY method).
`
`[0043] 3) Can adapt based on many parameters:
`terminal capabilities or user preferences (formats,
`screen resolution, memory), user preferences, net
`Work characteristics, etc.
`
`[0044] 4) May reduce latency and save battery life by
`performing some adaptation of content characteris
`tics on the server rather than on the terminal (e.g.
`image resolution reduction).
`
`[0045] HoWever, possible disadvantages may include:
`[0046] 1) There is a risk that the adaptation is destruc
`tive (small company logo may disappear When image
`resolution or number of colors is reduced)
`[0047] 2) The sender may not alloW the content
`manipulation.
`[0048] 3) Requires more processing on the server.
`[0049] These and other objects, features and advantages of
`the present invention Will become more apparent in light of
`the folloWing detailed description of a best mode embodi
`ment thereof, as illustrated in the accompanying draWing.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0050] FIG. 1 shoWs a typical message How of SIP
`message adaptation, according to the present invention.
`[0051] FIG. 2 shoWs examples of message adaptation
`performed according to the present invention.
`[0052] FIG. 3 shoWs exemplary details of the system of
`FIG. 1.
`
`BEST MODE FOR CARRYING OUT THE
`INVENTION
`
`[0053] As explained earlier, the invention presents a
`frameWork for SIP message adaptation services. The frame
`Work alloWs for the adaptation of messages betWeen the
`sender and recipient. The goal of the adaptation services
`frameWork is to facilitate message adaptation in such a Way
`that incoming messages may be made suitable for the
`recipient’s terminal, user’s preferences and netWork char
`acteristics (but not limited to those characteristics) even
`though the characteristics of the incoming messages may
`require capabilities quite different from that of the intended
`recipient terminal.
`
`[0054] A system 10, according to an embodiment of the
`invention shoWn in FIG. 1, comprises three elements in
`combination: SIP proxy/registrar 12, Capability Negotiation
`Manager 16 and Message Adaptation Engine 20.
`[0055] Adescription of each element and their cooperative
`relationship folloWs:
`[0056] 1) SIP proxy/registrar 12: this element per
`forms the operations required by a SIP proxy and
`registrar speci?ed in RFC 2543 (see M. Handley et
`al, “SIP: Session Initiation Protocol,” RFC 2543,
`IETF, March 1999). In addition, it performs the
`folloWing operations:
`[0057] a) At the time of registration or subscription
`(e.g. SIP REGISTER, SUBSCRIBE methods) 14,
`the registrar “resolves” the terminal capabilities or
`user preferences of the registering terminal 15
`(using the Capability Negotiation Manager Mod
`ule 16 described beloW) and stores them along
`With the registration data (containing the contact
`addresses). The term “resolve” means to obtain or
`determine terminal capabilities or user prefer
`ences, as explained beloW, by various possible
`mechanisms.
`
`[0058] b) When a neW message 18 arrives at the
`proxy (e.g. SIP MESSAGE, NOTIFY method)
`from another entity such as a sending terminal 19,
`
`WhatsApp Inc.'s Exhibit 1003
`
`006
`
`

`
`US 2003/0236892 Al
`
`Dec. 25, 2003
`
`the proxy obtains the terminal capabilities or user
`preferences of the intended recipient’s terminal 15
`already stored in the registrar, adapts the message
`(using the Message Adaptation Engine 20 below),
`and sends the adapted message 22 to the recipi
`ent’s terminal 15.
`
`[0059] 2) Capability Negotiation Manager 16: this
`element is responsible for resolving terminal capa
`bility information. There are many possible mecha
`nisms to obtain the terminal capabilities or user
`preferences: 1) use of the User-Agent header as a key
`to a database, called Terminal Capability Database
`46, containing terminal characteristics associated
`With numerous User-Agents; the Terminal Capability
`Database Would return the terminal capabilities or
`user preferences associated With the speci?c User
`Agent header value 2) use of protocol headers such
`as Accept header, Accept-Encoding header, etc. 3)
`URL, Where the Capability Negotiation Manager 16
`Will make an HTTP request to the given URL and
`Will get back some terminal capability information,
`4) explicit reporting of the capabilities or user pref
`erences in the registration. All these methods may
`lead to a different set of capabilities or user prefer
`ences and it may be required to complement the
`capabilities or user preferences obtained by one
`method With those obtained by others to get a full set
`of obtainable capabilities or user preferences that is
`fully re?ective of the terminal’s capabilities or user
`preferences. For instance, the capabilities from the
`URL may not contain some capabilities that are
`available in the Terminal Capability Database 46.
`Also, one may Want to give more importance to
`parameters Which are more dynamic (e.g. Accept
`formats that may re?ect the user’s preferences)
`rather than something ?xed for all terminals of the
`same model (Which may be the case for a Terminal
`Capability Database). Therefore, it Will be under
`stood that “resolve” refers to the operation of 1)
`gathering all possible capability and preference
`descriptors from the information received about the
`terminal (headers, URL, explicit capabilities or user
`preferences). This operation involves searching data
`bases, making HTTP requests to relevant URLs, etc.
`2) Combining the capabilities or user preferences
`obtained by the different methods in the most appro
`priate manner to make a complete set of capability
`information. This may involve combining capability
`descriptors and giving precedence to some methods
`over others in the case of duplication of certain
`capability descriptors (e.g. Accept header and a
`Terminal Capability Database may contain the infor
`mation about supported formats, precedence Would
`normally be given to Accept header since it is
`dynamic and special to the user). The capabilities
`negotiation manager 16 can (Without limitation)
`resolve capabilities or user preferences from any
`combination of the folloWing inputs:
`
`[0060] a) SIP protocol headers: User-Agent,
`Accept, Accept-Charset, Accept-Encoding, etc.
`
`[0061] b) List of URLs containing the location
`Where the terminal capabilities can be retrieved.
`
`[0062] The Capability Negotiation Manager 16 can use the
`User-Agent header as a key to a terminal capability database
`(local or external to the Capability Negotiation Manager)
`containing terminal capability information for each terminal
`type.
`[0063] 3) Message Adaptation Engine 20: this ele
`ment is responsible for adapting the message for the
`recipient terminal. It performs format conversion,
`presentation adaptation, media characteristics adap
`tation, message siZe reduction as needed, encapsu
`lation adaptation (different packaging of the mes
`sage, different binary encoding, etc.). In general,
`adaptation is any manipulation or modi?cation of the
`message content based on the terminal capabilities,
`user preferences, netWork conditions, or any charac
`teristics of the user, his terminal or his environment.
`
`[0064] The folloWing elements are novel compared to the
`present SIP-related speci?cations:
`[0065] 1) Capabilities negotiation for session-ori
`ented and non-session-oriented applications pro
`vided during the registration process:
`[0066] a) In SIP, the registration is used to provide
`contact information (address to be reached). SIP
`speci?cation says that message body of REGIS
`TER is for future studies.
`[0067] b) In SIP, capability negotiation occurs
`betWeen tWo clients during session establishment
`(using SDP (Session Description Protocol)). With
`out a session, Which is the case for instance With
`SIP instant messaging, there no means of knoWing
`the capabilities or user preferences of the destina
`tion terminal.
`
`[0068] c) This invention provides a method for
`capability negotiation regardless if the application
`is session-based or not.
`[0069] 2) Proxy adapting message based on recipient
`terminal capabilities or user preferences: It is said in
`SIP that proxies may transcode content. HoWever,
`the scope of this claim Was mainly for multimedia
`sessions (audio or video calls) Where codecs or the
`bandWidths betWeen users don’t match. In that case,
`the proxy can use the information in SDP to “?ll the
`gap” betWeen the tWo terminals. There is no mention
`that such adaptation could take place for messaging
`applications and no mention that it should be based
`on recipient’s terminal characteristics. In J. Rosen
`berg et al., “SIP Extensions for Instant Messaging,”
`draft-ietf-simple-im-01, IETF, January 2002, Which
`describes SIP extensions for instant messaging, there
`is no mention of adaptation functionality. It says that
`if a recipient doesn’t support a certain format, it
`should return an error message (415=Unsupported
`Media Type) containing an Accept header listing the
`supported formats. This Would tell the sender the
`valid formats to send.
`[0070] 3) A full system supporting SIP messaging
`adaptation. This is lacking from SIP messaging.
`
`[0071] Thus, the invention provides a frameWork for SIP
`message adaptation services including transcoding. The
`frameWork permits adaptation of messages betWeen the
`
`WhatsApp Inc.'s Exhibit 1003
`
`007
`
`

`
`US 2003/0236892 A1
`
`Dec. 25, 2003
`
`sender and the recipient. It allows making the messages
`suitable for the recipient’s terminal, user preferences and
`network characteristics.
`[0072] Register Operations
`[0073] The registrar 12, in addition to the operations of a
`SIP registrar as speci?ed in RFC 2543, is responsible for
`resolving and storing the terminal capabilities or user pref
`erences for each user. It uses the Capability Negotiation
`Manager to resolve the capabilities or user preferences upon
`reception of a register message. Many methods may be used
`to resolve them, as described above. Regardless of the
`method used, the obtained terminal capability information
`(including User-Agent and Accept header ?elds and other
`relevant ones) is stored along With the standard registration
`information for each user. Those capabilities or user pref
`erences are later used by the proxy When receiving an
`incoming message for that registered user.
`[0074] Capability Negotiation Manager Operations
`[0075] At the request of the SIP Proxy/Registrar 12, the
`Capability Negotiation Manager 16 resolves the terminal
`capabilities and user preferences using different inputs and
`methods. Three methods are shoWn but the system is not
`limited to them. Some or all those methods can be used in
`a complementary Way (i.e. the information obtained by one
`method may complement the information obtained by other
`methods). For the illustrated methods, the registrar 12
`receives the SIP register message on the line 14 and provides
`it to the Capability Negotiation Manager 16 and obtains a set
`of terminal capabilities and user preferences in return.
`
`[0076] In the ?rst method, the terminal provides its capa
`bilities (and the user’s preferences) explicitly in the body of
`the registration message (e.g. REGISTER or SUBSCRIBE
`methods). The registration message may also contain the
`User-Agent, Accept, Accept-Encoding, and Accept-Charset
`header ?elds. The User-Agent header ?eld describes the
`terminal type and softWare version. The Accept header ?eld
`lists the media formats supported (e.g. image/jpeg or text/
`plain). This method requires standardiZation Work to de?ne
`a terminal capability format and vocabulary.
`[0077] The second method involves using the User-Agent
`header ?eld as a key to a Terminal Capability Database
`Which contains, for every knoWn User-Agent, the associated
`terminal’s capabilities or user preferences. ATerminal Capa
`bility