Title of Invention

METHOD AND APPARATUS TO CONVEY A URI FOR CONTENT INDIRECTION USE IN SIP

Abstract

A content indirection communications method, server, device, data storage medium and computer program product where in a method executed by the server, in response to a Session Initiation Protocol (SIP) registration request from a device, informing the device in a SIP message of the identity of an address where the device may send information that is to be referenced by a SIP content indirection operation, and allocating storage for the information. Informing the device-preferably uses a SIP message Call-Info header field with a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies an identity of the storage location.

Full Text

METHOD AND APPARATUS TO CONVEY A URI FOR CONTENT INDIRECTION USE IN SIP TECHNICAL FIELD: This invention relates generally to wireless communications systems and methods and, more specifically, relates to wireless terminals and wireless network nodes that use a Session Initiation Protocol (SIP) or similar or equivalent messaging exchange. BACKGROUND: The Session Initiation Protocol (SIP) is defined in IETF RFC3261 (Rosenberg et al., June 2002). In general, the SIP is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. The sessions can include Internet telephone calls, multimedia distribution and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. In addition, an IETF draft "draft-ietf-sip-content-indirect-mech-03", entitled "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages" (S. Olson, June 2,2003), describes the mechanism to provide for content indirection in SIP messages. More specifically, the purpose of the SP is to create, modify, or terminate sessions with one or more participants, and SIP messages, like HTTP, are syntactically composed of a start line, one or more headers, and an optional body. Unlike HTTP, SIP is not designed as a general purpose transport of data. There are various reasons why it may be desirable to indirectly specify the content of the SIP message body. For bandwidth limited applications, such as in cellular wireless applications, indirection provides a means to annotate the (indirect) content with meta-data which may be used by the recipient to determine whether or not to retrieve the content over the resource limited link. It is also possible that the content size to be transferred might potentially overwhelm intermediate signaling proxies, thereby unnecessarily increasing network latency. For time-sensitive SIP applications, this may be unacceptable. The use of indirect content can alleviate these shortcomings by moving the transfer of the content out of the SIP signaling network and into apotentially separate data transfer channel. There may also be scenarios where the session related data (body) that needs to be conveyed does not directly reside on the endpoint or User Agent (UA). In such scenarios, it is desirable to have a mechanism whereby the SIP message can contain an indirect reference to the desired content. The receiving party would then use this indirect reference to retrieve the content via a non-SIP transfer channel, such as HTTP, FTP, or LDAP. It is stated in this IETF draft that the purpose of content indirection is purely to provide an alternative transport mechanism for SIP Multipurpose Internet Mail Extensions (MIME) body parts. With the exception of the transport mechanism, indirected body parts are equivalent, and should have the same treatment, as in-line body parts. In general, MIME is originally intended to extend the format of Internet mail to allow non-US-ASCII textual messages, non-textual messages, multipart message bodies and non-US-ASCE information in message headers. The following RFCs define MIME: RFC 2045: MIME Part One: Format of Internet Message Bodies; RFC 2046: MIME Part Two: Media Types; RFC 2047: MIME Part Three: Message Header Extensions for Non-ASCII Text; RFC 2048: MIME Part Four: Registration Procedures; and RFC 2049: MIME Part Five: Conformance Criteria and Examples. Another IETF draft "draft-khartabil-sip-policy-uri-call-info-purpose-OO", entitled "Conveying a Session Policy Uniform Resource Identifier (URI) in the Session Initiation Protocol (SIP)" (H. Khartabil and A. Niemi, February 5, 2004) describes an extension to a Call-Info header field for introducing a new purpose parameter value that can be used by a request originator or recipient to convey a URI where certain information to a session can be accessed. More specifically, this IETF draft provides, a "policy-uri" which can be used by a conference server to indicate the URI of the conference policy to a UA participating in that conference. The above-mentioned IETF draft document "draft-ietf-sip-content-indirect-mech-03" defines the SIP content indirection mechanism as providing an alternative transport mechanism for SIP MME body parts. This is done by providing a URI for the indirect content/where the URI is specified in a "URI" parameter of the message/external-body MIME type. However, before conveying this URI in a SIP request or response, the SIP client needs to be informed of the URI so that it can upload the indirect content before the indirect content is referenced in a SIP request or response. The IETF draft document draft-ietf-sip-content-indirect-mech-03 does not define the client or server behavior with respect to determining a URI to be used for content indirection. That is, what was not defined, prior to this invention, was a technique or protocol for a SIP UA to request, or be informed of, a storage location on an Application Server (AS) wherein the SIP UA can store the information that is to be referred to by a subsequent content indirection operation. SUMMARY OF THE PREFERRED EMBODIMENTS The foregoing and other problems are overcome, and other advantages are realized, in accordance with the presently preferred embodiments of these teachings. hi a first aspect thereof this invention provides a communications method that comprises receiving a registration request from a device; and foforrning the device of the identity of an address for the device to send information to be referenced by a content indirection operation. In another aspect thereof this invention provides a device operable with a server, comprising a data processor responsive to a receipt of a second message from the server, sent in response to the device originating a first message, to extract from the second message an identify of a location for the device to send information to be referenced by a content indirection operation. In another aspect thereof this invention provides a content indirection communications method, comprising in response to a Session Initiation Protocol (SIP) registration request from a device, informing the device in a SIP message of the identity of an address where the device may send information that is to be referenced by a SIP content indirection operation; and allocating storage for the information. In another aspect thereof this invention provides a SIP Server that comprises a data processor that is responsive to an occurrence of a SIP registration request made by a device to inform the device by a SIP message of an identity of an address where the device may send information to be referenced by a subsequent SIP content indirection operation. In a another aspect thereof this invention provides a device operable with a SIP Server, comprising a data processor responsive to a receipt of a SIP message from the SIP Server, sent in response to the device originating a registration request message, to extract from the SIP message an identification of a location where the device may send information to be referenced by a subsequent SIP content indirection operation. In a further aspect thereof this invention provides a data storage medium readable by a digital data processor, said data storage medium storing program instructions for use in a content indirection procedure in a SIP operation and comprising operations of, in response to receiving a SIP registration request from a device, reserving a storage location for the device where the device may store information that is to be referenced by a SIP content indirection operation; and informing the device of an identity of the storage location using a SIP message Call-Info header field with a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of the storage location. In another aspect thereof this invention provides a Multimedia Messaging Service (MMS) Relay/Server for conducting a SIP operation with a device, comprising meanSj responsive to receiving a SIP registration request from the device, for reserving a storage location for the device where the device may store information that is to be referenced by a SIP content indirection operation; and means for informing the device of an identity of the storage location using a SIP message Call-Info header field -with a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of the storage location. In a still further aspect thereof this invention provides a data storage medium readable by a digital data processor, the data storage medium storing program instructions for use in a content indirection procedure in a SIP operation and comprising operations of receiving a SIP message originated from a SIP server in response to sending a registration request message towards the SIP server; identifying a case where the received SIP message comprises a Call-Info header field having a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of a storage location that has been reserved for the device wherein the device may store information that is to be referenced by a SIP content indirection operation, and sending information to the storage location. In another further aspect thereof this invention provides a device operable with a SIP Server, where the device comprises a data processor that operates in response to a receipt of a SIP message originated from a SIP server to identify a case where the received SIP message comprises a Call-Info header field having a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of a storage location that has been reserved for the device wherein the device may store information that is to be referenced by a SIP content indirection operation, said data processor further operating to send information to the storage location. In another aspect thereof this invention provides a device operable with a Session Initiation Protocol (SIP) Server, comprising means, responsive to a receipt of a SIP message originated from a SIP server to indicate success/failure of a registration request, for identifying a case where the received SIP message comprises a Call-Info header field having a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of a storage location that has been reserved for the device wherein the device may store information that is to be referenced by a SIP content indirection operation; and means for uploading information that corresponds to indirect content with a HTTP PUT to the storage location specified by the URI that comprises part of the Call-Info field of the SIP message. In another aspect thereof this invention provides a SIP Server that includes a data processor that is responsive to an occurrence of a SIP registration request made by a device to inform the device by a SIP message of an identity of a storage location where the device may send information to be referenced by a SIP content indirection operation and, responsive to the device sending the information, allocating storage and directing the information to the allocated storage. In a further aspect thereof this invention provides a method to operate a Session Initiation Protocol (SIP) Server, comprising in response to an occurrence of a SIP registration request made by a device, sending the device a SIP message that comprises an identity of a storage location where the device may send information to be referenced by a SIP content indirection operation; and responsive to the device sending the information, allocating storage and directing the information to the allocated storage. In another aspect thereof this invention provides a computer program product operable for a SIP Server to conduct a SIP session with a device, comprising operations of, in response to an occurrence of a SIP registration request made by the device, sending the device a SIP message that comprises an identity of a storage location where the device may send information to be referenced by a SIP content indirection operation, and responsive to the device sending the information, allocating storage and directing the information to the allocated storage. hi another aspect thereof this invention provides a computer program product operable for a device to conduct a SIP operation with a SIP Server, comprising operations of receiving a SIP message originated from a SIP server in response to sending a registration request message towards the SIP server; identifying a case where the received SIP message comprises a Call-Info header field having a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of a storage location that has been reserved for the device wherein the device may store information that is to be referenced by a SIP content indirection operation; and sending information to the storage location. In another aspect thereof this invention provides a method for operating a SIP Server to conduct a SIP session with a device, comprising a step for, executed in response to an occurrence of a SIP registration request made by the device, sending the device a SIP message that comprises an identity of a storage location where the device may send information to be referenced by a SP content indirection operation; and a step for, executed in response to the device sending the information, allocating storage and for directing the information to the allocated storage. In yet another aspect thereof this invention provides a method for operating a device to conduct a SIP operation with a SIP Server comprising, in response to receiving a SIP message originated from a SIP server in response to sending a registration request message towards the SIP server, a step for identifying a case where the received SIP message comprises a Call-Info header field having a purpose parameter set to ci-uri for indicating that the Call-Info header field contains a Uniform Resource Identifier (URI) that specifies the identity of a storage location that has been reserved for the device wherein the device may store information that is to be referenced by a SIP content indirection operation; and a step for sending information to the storage location. BRIEF DESCRIPTION OF THE DRAWINGS The foregoing and other aspects of the embodiments in accordance with the teachings of this invention are made more evident in the following Detailed Description of the Preferred Embodiments, when read in conjunction with the attached Drawing Figures, wherein: Fig. 1 is diagram showing the functional architecture of an IP Multimedia System (IMS) that is one suitable embodiment in which to practice this invention, and specifically shows the Ut interface placed between a UE and a SEP Application Server; and Fig. 2 is a message flow diagram that illustrates the use of this invention in a Multimedia Messaging Service (MMS) architectured system. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS SEP defines a Call-Info header (see RFC 3261, Section 20.9, page 166). The purpose of the Call-Info header field is to provide additional information about the caller or callee, depending on whether the header is used in a request or a response. This information contains a URI, and the purpose of the URI is described by a "purpose" parameter. The "info" parameter describes the caller or callee in general, for example, through a web page. Referring to RFC 3261 at page 166, an example of the Call-Info header is given as follows: Call-Info: ;purpose=icon, ;purpose=infb. In accordance with an aspect of this invention, a new purpose parameter value of "ci-uri" is used by an Application Server to convey a URI, which can be used by a SIP UA for content indirection. As an example of applying this invention to a generic content indirection case, it is assumed that a server supports both SIP and HTTP, if one further assumes that the content indirection mechanism uses the HTTP URI scheme. During a SIP transaction between the client and the server (e.g., during a SIP registration transaction) the server conveys the HTTP URI in a SIP Call-Info header field specifying the storage location to be used for content indirection (see the example shown in Fig. 2 and described below). In addition to the "purpose" parameter, it is preferred that the Call-Info header field also contain additional parameters, such as those defined in the above-captioned draft-ietf-sip-content-indirect-mech-03 document: "expiration", "access-type" and "size". One non-limiting example of a Call-Info header field carrying an HTTP URI for "ci-uri" purposes is as follows: Call-Info: ;purpose=ci-uri ;access-type-'URL" ;expiration="Mon, 24 June 2004 09:00:00 GMT" ;size=4123 When applying the teachings of this invention to the IP Multimedia Subsystem (IMS) architecture, it is possible to assume than an Application Server may function as the content indirection server. Referring to Fig. 1 (obtained from document 3GPP TSG-CN Meeting#22,10th-12th December, Maui, Hawaii, NP-030457), a Ut interface 1 is shown placed between the UE 2 and a SIP Application Server/OSA-SCS 3 (also referred to simply as the AS 3), that in turn is coupled to a S-CSCF 4 via Sh and Cx interfaces 5 and 6, respectively, and a HSS 7, as well as directly through an ISC interface 8. The S-CSCF 4 (Serving Call Session Control Function) is an IMS element that provides the session control services for the UE 2, which enables a network operator to support the services. Functions include: the management of mobile registrations, maintaining of the session, interaction with other services, charging and security. The HSS 7 (Home Subscriber Server) describes the various database functions that are required in modern mobile networks. These functions include the Home Location Register (HLR), the Domain Name Server (DNS) and security and network access databases. In the context of this invention, the Ut interface 1 between the UE 2 and the AS 3 is assumed to support HTTP, and SIP communication is possible from the AS 3 to the UE 2 via the S-CSCF. During a SIP transaction between the AS 3 and the UE 2, the AS 3 can convey the "ci-uri" in the SIP Call-Info header field to the UE 2, thereby triggering the UE 2 to upload the indirect content to the AS 3 using HTTP on the Ut interface 1. It is understood that in this embodiment, as well as the MMS embodiment described next, that the SIP Application Server and the UE or UA, which may be genetically referred to herein simply as devices, each contain a programmed digital data processor of some sort that is operable for executing the SIP-related content indirection procedures in accordance with this invention. For example, the UE or UA may be embodied in a cellular telephone or apersonal communicator that includes an embedded microprocessor that operates in accordance with a stored program for performing extraction of the URI from a SEP message received from the SIP Application Server, and for then subsequently sending the information to be stored at the address specified by the extracted URI, where the information is that information that is to be referenced later in a content indirection type of SIP message interaction. In general, the various embodiments of devices corresponding to the UE or UA 2 can include, but are not limited to, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals or more generally devices that incorporate combinations of such functions. The teachings of this invention may also be practiced using non-wireless devices, such as desk top computers and other types of equipment that have a wired (e.g., electrical wire or optical fiber) connection to a data communications network. Aspects of this invention thus relate as well to data storage medium for storing computer programs for operating servers and devices in accordance with this invention, as well as to computer program products executable by servers and devices so as to operate in accordance with this invention. As such, Fig. 2 shows that the UA 2 device includes a data processor (DP) 2A and a data storage medium (DSM) 2B, and the server 3 includes aDP3AandaDSM3B. This invention may also be used hi the context of a Multimedia Messaging Service (MMS) architecture. The Multimedia Messaging Service provides a mechanism to send not only text messages, as with the Short Message Service (SMS), but also drawings, photographs, music or voice clips and video. The system operates on the "store and forward" principle, with messages being stored and possibly formatted at a Multimedia Messaging Service Center (MMSC) when sent between users. Reference may be had, for example, to GSM Association Permanent Reference Document: IR.52, PRD IR.52, MMS Interworking Guidelines, Version 3.1.0, February 2003. Referring now to Fig. 2, and more specifically when applying this invention to the 3GPP2 SIP-based MMS MM1 interface specification, the specification is revised in the following manner: the third-party registration procedure between a Home Service Proxy (HSP) 10 and the MMS Relay/Server (the AS 3 in the MMS case) is extended so that the MMS Relay/Server preferably always informs the MMS UA 2 about the success/failure of the registration with the MMS service. This allows the MMS Relay/Server to send a SIP MESSAGE request to the MMS UA 2 after every registration or re-registration cycle. When sending the SIP MESSAGE request to the MMS UA 2, the MMS Relay/Server includes a Call-Info header field carrying an HTTP URI for "ci-uri" purposes. This URI remains valid until the MMS UA 2 re-registers, de-registers, or the registration of the MMS UA 2 expires. This implies that the MMS Relay/Server reserves a HTTP URI for every registering MMS UA, with the lifetime equal to the registration lifetime, thereby allowing the MMS UA 2 to perform content indirection at any time during its valid registration period. This procedure also eliminates the need for the MMS UA 2 to explicitly request a storage location before MM submission, since the storage location is reserved on the MMS Relay/Server after the MMS UA 2 registers with the service, and it remains available for the MMS UA 2 while it stays registered. The message exchange diagram of Fig. 2 illustrates the foregoing behavior. Note that the SIP message informing the MMS UA 2 of the successful SIP registration has a Call-Info header with the purpose parameter set to "ci-uri". Subsequently the MMS UA 2 performs a HTTP PUT (or some other equivalent type of push operation, depending on the technology) to upload the information that corresponds to the indirect content to the location specified by the URI found in the Call-Info part of the SIP message received after registration. It should be noted that te URI found in the Call-Info header field may not point to an actual or physical storage location reserved by the HSP 10 for indirect content. Instead, the HSP 10 redirects a MMS UA 2 PUT request that is directed to the URI found in the Call-Info header field to an actual storage location. Redirection may be performed by the HSP 10 replying to the HTTP PUT request with HTTP 3xx responses. One benefit that is obtained through the use of this approach is that HSP 10 need not allocate physical storage locations for the MMS US 2 at the time of the MMS UA 2 registration. Instead, the HSP 10 need only reserve or allocate storage locations when there is an actual need for the storage, at the time of the MMS UA 2 sending the HTTP PUT request. These operations are shown in Fig. 2 as the (optional) block 12, which is intended to indicate that the server 3 may allocate storage, and redirect uploaded information to the allocated storage in response to the HTTP PUT from the device 2.. Examining the message flow of Fig. 2 in even greater detail, it can be noticed that the first REGISTER transaction is between the UA 2 and the HSP 10. The HSP 10 functions as a SIP registrar, exhibiting normal SIP functionality. Based on this transaction, the HSP 10 generates a third-party REGISTER request to inform the AS 3 (the MMS Relay Server in this case) of the registration status of the UA 2. From the SP point of view, this is another SIP registration functionality, where the AS 3 acts as a registrar and the HSP 10 registers the UA 2 as a third-party. It can be noted that in the IMS case (Fig. 1) the requirement is not to register the UE 2 with the AS 3, the goal is instead only to inform the AS 3 that the UE 2 has been registered with the HSP 10 (the HSP, interposed between the UE 2 and the AS 3, is not shown in Fig. 1). Therefore the AS 3 does not actually function as a SIP registrar in the IMS case, instead it simply stores the registration status of the UE 2, with the expiry. In any event, based on the previous third-party registration from the HSP 10 the AS 3 generates a SIP MESSAGE, which is targeted to the UA 2 and routed via the HSP 10 (routing via the HSP 10 is performed simply because the AS 3 has no direct SIP interface to the UA 2). This SIP message originated by the AS 3 conveys the Call-Info header field to the UA 2 with the purpose parameter set to ci-uri for indicating to the UA 2 (or UE 2) that the Call-Info header contains a URI that specifies the address of the storage location for use in content indirection, hi that all UEs/UAs upon registration are automatically allocated a URI for content indirection purposes, whether used or not, the use of this invention eliminates a need to provide additional (possibly unstandardized) signalling exchanges where the UE/UA must specifically request the allocation of a URI. It should be noted that the allocated URI may be one that is allocated in common to all UEs/UAs, and as was noted previously, a "real" URI that points to the actual storage location(s) is only reserved when the UE/UA actually needs to perform content indirection. Reference is again made to the draft-khartabil-sip-policy-viri-call-info-purpose-OO document. Note that while this document extends the Call-Info purpose parameter with a value of "policy-uri", that is used by a caller or a callee to convey a URI where a certain policy pertaining to the session can be accessed, this document does not suggest the use of the purpose parameter for SEP content indirection in the manner that is disclosed with regard to the embodiments of this invention. Also, it is noted that one possible application for SIP content indirection is described in 3GPP2 X.P0016-312. This specification defines the behavior for a SIP-based MM submission. If the size of the MMS message does not satisfy the message size constraints described in RFC3428 (SIP MESSAGE method), then the MMS UA uses content indirection to submit the MM to a MMS Relay/Server. In order to perform this operation the MMS UA requests a storage location from the MMS Relay/Server. However, the request of a storage location by the MMS UA is not equivalent to the use of the Call-Info header with a purpose=ci-uri procedure in accordance with this invention. SIP protocol details of the 3GPP IP Multimedia Subsystem (IMS) and 3GPP2 Multimedia Domain (MMD) are defined in 3GPP TS 24.229 and 3GPP2 X.S0013.4. 3GPP2 X.P0016-312 is the 3GPP2 SIP-based MMS MM1 interface specification (Stage-3). The foregoing description has provided by way of exemplary and non-limiting examples a full and informative description of the best method and apparatus presently contemplated by the inventor for carrying out the invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings and the appended claims. As but some examples, the use of other similar or equivalent messaging formats and system architectures (e.g., other than the IMS and MMS architectures) may be attempted by those skilled in the art. This invention may also be employed for secure SIP (SIPS) operations. However, all such and similar modifications of the teachings of this invention will still fall within the scope of this invention. Furthermore, some of the features of the present invention could be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles of the present invention, and not in limitation thereof. WE CLAIM: 1. A method for wireless indication messaging exchange comprising: receiving a session initiation protocol (SIP) registration request from a device (2) at a session initiation protocol ((SIP) server (3); and in response to receiving the said request, sending a session initiation protocol ((SIP) message from the server (3) to the device (2), where the session initiation protocol message comprises an address of a storage location for the device (2) to send information that is to be referenced by a subsequent content indirection operation, said session initiation protocol message comprising a Call-Info (ci) header with a purpose parameter set to ci-uri for indicating that the Call-Info header contains a uniform resource identifier (uri) that specifies the address of the storage location. 2. The method as claimed in claim 1, wherein said uniform resource identifier allocates a resource for storage of said information. 3. The method as claimed in claim 2, wherein said resource for storage of information is allocated in response to the device (2) sending said information. 4. The method as claimed in claim 1 wherein said session initiation protocol ((SIP) message is sent from the server (3) through a Ut interface (1) of an internet protocol multimedia system (MMS) to the device (2). 5. The method as claimed in claim 1, wherein said information is sent via a home service proxy node (10) in a multimedia messaging service system. 6. The method as claimed in claim 1, where the uniform resource identifier of server (3) reserves the storage location for the device (2) and remains available for the time during which device (2) is registered. 7. An apparatus for wireless indication messaging exchange comprising: a receiver (3) configured to receive a session initiation protocol (SIP) registration request from a device (2); and a data processor (3A) responsive to the receipt of said SIP registration request to send a session initiation protocol (SIP) message and said session initiation protocol (SIP) registration request to the device (2), the session initiation protocol message comprising an address of a storage location for the device (2) to send information that is to be referenced by a subsequent content indirection operation, where the session initiation protocol message comprises a Call-Info (ci) header with a purpose parameter set to ci-uri for indicating that the Call-Info header contains a uniform resource identifier (uri) that specifies the address of the storage location. 8. The apparatus as claimed in claim 7 wherein said session initiation protocol (SIP) message and said session initiation protocol (SIP) registration request are sent by said data processor (3A) to said device (2) through a Ut interface (1) of an internet protocol multimedia system (MMS) provided between said data processor (3A) and said device (2). 9. The apparatus as claimed in claim 7, where, in said multimedia messaging service system (MMS), said session initiation protocol (SIP) registration request triggers a third party registration request that is made by a home server proxy node (10), and the message reaches the device (2) via said home server proxy node (10). 10. The apparatus as claimed in claim 7 where the uniform resource identifier of receiver (3) is connected to the device (2) to reserve the storage location for the device (2) and remains available for the time during which device (2) is registered.

Documents:

6123-DELNP-2006-Abstract-(23-05-2011).pdf

6123-delnp-2006-abstract.pdf

6123-DELNP-2006-Claims-(02-11-2011).pdf

6123-DELNP-2006-Claims-(21-10-2011).pdf

6123-delnp-2006-Claims-(23-05-2011).pdf

6123-delnp-2006-claims.pdf

6123-DELNP-2006-Correspondence Others-(02-11-2011).pdf

6123-DELNP-2006-Correspondence Others-(21-10-2011).pdf

6123-delnp-2006-Correspondence Others-(23-05-2011).pdf

6123-delnp-2006-correspondence-others-1.pdf

6123-delnp-2006-correspondence-others.pdf

6123-delnp-2006-description (complete).pdf

6123-delnp-2006-drawings.pdf

6123-delnp-2006-form-1.pdf

6123-delnp-2006-Form-13-(23-05-2011).pdf

6123-delnp-2006-form-18.pdf

6123-delnp-2006-form-2.pdf

6123-delnp-2006-Form-3-(23-05-2011).pdf

6123-delnp-2006-form-3.pdf

6123-delnp-2006-form-5.pdf

6123-delnp-2006-gpa.pdf

6123-delnp-2006-pct-304.pdf

6123-delnp-2006-pct-search report.pdf

6123-delnp-2006-Petition-137-(23-05-2011).pdf