WO2006058544A1 - Method for delivering multimedia files - Google Patents
Method for delivering multimedia files Download PDFInfo
- Publication number
- WO2006058544A1 WO2006058544A1 PCT/EP2004/013593 EP2004013593W WO2006058544A1 WO 2006058544 A1 WO2006058544 A1 WO 2006058544A1 EP 2004013593 W EP2004013593 W EP 2004013593W WO 2006058544 A1 WO2006058544 A1 WO 2006058544A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- data file
- recipient
- originator
- server
- mms
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/24—Negotiation of communication capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/07—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail characterised by the inclusion of specific contents
- H04L51/10—Multimedia information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/21—Monitoring or handling of messages
- H04L51/234—Monitoring or handling of messages for tracking messages
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
- H04L51/58—Message adaptation for wireless communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
Definitions
- the invention relates to communications. More specifically, the invention relates to a technique for efficiently delivering multimedia files such as Multimedia Messaging Service messages containing multimedia content.
- MMS Multimedia Messaging Service
- an MMS is typically sent from an originator network component to a server or relay associated therewith, which forwards the multimedia message to a server or relay associated with a recipient network component (or simply recipient).
- the recipient server then notifies the recipient about the MMS upon which the recipient retrieves the content from the server.
- the content retrieval and a read-reply are acknowledged by the recipient and returned to the originator server and eventually to the originator network node.
- Fig. 1 provides a signaling diagram 100 which details the signals exchanged among an Originator MMS User Agent (UA) 110 of an originating terminal, an Originator MMS Relay/Server (or briefly Originator MMS Server) 120, a Recipient MMS Relay/Server (or briefly Recipient MMS Server) 130, and a Recipient MMS UA 140 of a recipient terminal with regard to the transfer of an MMS using conventional techniques.
- UA Originator MMS User Agent
- Originator MMS Relay/Server or briefly Originator MMS Server
- Recipient MMS Relay/Server or briefly Recipient MMS Server
- a Recipient MMS UA 140 of a recipient terminal with regard to the transfer of an MMS using conventional techniques.
- Via signal IA a request is issued to transfer an MMS from the Originator MMS UA 110 to the Originator MMS Server 130 (e.g., MMl_submit.REQ) which is replied to via signal IB (e.g., MMl
- the Originator MMS Server 120 forwards the request to the Recipient MMS Server 130 via signal 1C (e.g., MM4_forward.REQ), which is replied to by signal ID (e.g., M4_forward.RES).
- the Recipient MMS Server 130 then notifies the Recipient MMS UA 140 about the request via signal IE (e.g., MMl_notification.REQ) which is responded to by signal IF (e.g., MMl_notification.RES).
- signal IE e.g., MMl_notification.REQ
- IF e.g., MMl_notification.RES
- signal IG is generated and sent to the Recipient MMS Server 130 (e.g., MMl_retrieve.REQ) and a response is then sent back to the Recipient MMS UA 140 via signal IH (e.g., MMl_retrieve.RES).
- the Recipient MMS UA 140 then sends a content retrieval acknowledgment to the Recipient MMS Server 130 (e.g., MMl_acknowledgment.REQ), which then sends a signal U to the Originator MMS Server 120 reporting about the content (e.g., MM4_delivery_report.REQ) which is subsequently replied to via signal IK (e.g., MM4_delivery_report.RES).
- the Originator MMS Server 120 then sends signal IL to the Originator MMS UA 110 acknowledging the delivery report (e.g., MMl_delivery_report.REQ).
- the Recipient MMS UA 140 also sends a read reply acknowledgment via signal IM (e.g.,
- MMl_read_reply_recipient.REQ which then sends a signal IN to the Originator MMS Server 120 reporting about the content (e.g., MM4_delivery_report.REQ) which is subsequently replied to via signal IK (e.g., MM4_delivery_report.RES).
- the Originator MMS Server 120 thereafter sends a read reply acknowledgment signal IP (e.g., MMl_read_reply_originator.REQ) to the Originator MMS UA 110.
- IP e.g., MMl_read_reply_originator.REQ
- Fig. 2 illustrates signaling among an originating network component such as an originating terminal 210, a Short
- the originating terminal 210 sends an MMS in signal 2A via WAP Proxy 230 and signal 2B to the originating MMC 250.
- MMS Multimedia Messaging Center
- the originating terminal 210 sends an MMS in signal 2A via WAP Proxy 230 and signal 2B to the originating MMC 250.
- WAP Proxy 230 and signal 2B With slow-speed network access, it can take up to forty (40) seconds until the MMS content is fully uploaded to the MMC 250. After the upload is finalized, the reception of the MMS is acknowledged by the originating MMC 250 via signals 2C and 2D.
- the originator MMC 250 then forwards the MMS to the recipient MMS Relay/Server (not shown) which also acknowledges the reception of the MMS.
- Fig. 3 illustrates a signaling diagram 300 with similar components as Fig. 2, but in relation to the retrieval of an MMS by a recipient network component such as a re- cipient terminal 310.
- a Push Access Protocol message is sent from an MMC, i.e., the Recipient MMS Relay/Server 350 associated with the recipient terminal 310 to a PPG 340, which acknowledges the message via signal 3B.
- a Short Message Peer-to-Peer protocol message 3C is sent from the PPG 340 to a SMS-C 320, which subsequently notifies the recipient terminal 310 of the MMS via signal 3D.
- the recipient terminal 310 may then send a notification to obtain the MMS in signal 3E via WAP Proxy 330 and signal 3F to the recipient MMC 350.
- the MMC 350 then downloads the MMS to the recipient terminal via signals 3G and 3H. Similar to the uploading of the MMS to the originating MMC 250, the downloading of the MMS from the recipient MMC 350 to the recipient terminal 310 may also take up to forty (40) seconds depending on the speed of the network.
- Originating network component to originator MMS Relay/Server
- the delivery of an MMS using conventional techniques is unnecessarily ⁇ lengthy (especially if there is only a low-speed network access available) and results in the consumption of significant buffer space in the Originator and Recipient MMS Relay/Servers (which is based in part on the high number of parallel ongoing transmissions).
- Such delays can be compounded as the size of the MMS increases (e.g., in the case of large video clips).
- the delays in receiving an MMS negatively affect user experience at a recipient net- work component and may discourage users from sending an MMS (and thus reduces potential throughput revenues to network operators). For example, in some cases, such as with regard to sports or news clips, a user may be eagerly waiting for the MMS to be fully loaded. In other cases, a user may know that an MMS is on the way, such as when the user is also participating in a voice session with the originating user and the MMS is sent in parallel (e.g., via combinational services, and the like), and that delay in delivery may negatively affect the interactions with other users. Delays are also problematic in multi-user group sessions in which a single user sends an MMS to all participants. As the receiving participants may have registered for the multi-user content, they are supposed to be ready for content reception.
- the invention is embodied in a method for delivering a multimedia data file, such as an MMS, from an originator having an originator server associated therewith to a recipient having a recipient server associated therewith.
- a method may comprise establishing a communication path from the originator to the recipient via the originator server and recipient server.
- the method may further comprise the reception, by the recipient server, of portions of the data file from the originator server (with each of the data file portions or the complete data file being uploaded to the originator server from the originator). Thereafter, and without waiting for receipt of the complete data file, the recipient server individually forwards the data file portions received from the originator server for reassembly by the recipient.
- the communication path to the recipient server and also to the recipient may be established before the entire data file was uploaded to the originator server. Accordingly, the recipient (or it's internal component handling the data file, such as an MMS User Agent) may be online and reachable already initially (e.g., before the upload of the data file to the originator server starts). Delivery of the data file may thus be ac- celerated by a simultaneous upload, propagation and download of the data file content. Alternatively, the communication path may be established in two or more steps (e.g. during data file upload or after the data file was uploaded to the originator server).
- the individual data file portions could be directly forwarded towards the recipient via a (semi-) permanent communication path that is established for the time of the data file transmission.
- the information necessary to establishe the communication path to the recipient is initially available (e.g., before the upload of the data file content or portions thereof to the originator server starts).
- a negotiation may be performed (also to agree on the communication principles to be used for the data file transfer).
- the information exchanged in this regard may include information about the size of the data file to be transferred.
- various optional modifications may be made to the method depending on the desired configuration.
- the method may further comprise the step of receiving, by the recipient server, an acknowledgment that the data file was correctly reassembled.
- the method may also include the step of sending, by either the recipient server to the originator server or the recipient to the recipient server to the originator server, a message indicating that a data file portion has not been received.
- messages may be sent by either the recipient server to the originator server or the recipient to the recipient server to the originator server, a message indicating that a data file portion has been properly received.
- At least one of the originator server and the recipient server may cache received data file portions so that such data file portions may be quickly resent if they were not prop- erly received by the adjacent component within the data traffic flow.
- the method may also include the step of subdividing, by at least one of the originator and the originator server, the data file into the data file portions. If the data file is subdivided by the originator, then fewer network resources are consumed. As a re- suit, network operators might charge different tariffs depending on whether a data file is subdivided by the originator or by the originator server or some other network component (especially if at least one of the originator and the recipient is a mobile communications device). In connection therewith, the method may also include the step of associating a billing charge with the transfer of the data file based on the amount of processing capacity utilized by at least one of the originator server and the recipient server.
- the method may also include steps in which parameters for transferring the data file from the originator to the recipient are established or negotiated.
- the method may further comprise the steps of receiving, by the recipient server, a transfer inquiry from the originator server generated in response to a request from the originator, the transfer inquiry containing or referencing initial parameters regarding the transfer of the data file, determining, by the recipient server, whether to modify the initial parameters, and sending, by the recipient server, a response to the transfer inquiry including or referencing final parameters that include either an acceptance of the initial parameters or modified parameters, and receiving, by the recipient server, the data file delivered according to the final parameters for transfer to the recipient.
- a pre- transfer negotiation may be utilized both in connection with the data file transfer method described above as well as separately and that the negotiation technique may also be applied to other communication scenarios.
- the parameters pertaining to the delivery of the data file may relate to a variety of factors and may optionally be chosen from the group comprising data file content type, data file content size, codecs applied to code the content, the number of parts of the data file, the size of each data file part, sequence numbering of data file parts, procedure to request lost data file parts, number of recipients, and acknowledgment protocols utilized.
- the initial parameters may con- tain at least two different techniques for delivering the data file to the recipient and the response may include either an acceptance of one of the at least two different techniques or modified parameters.
- the method may also provide that the originator selects the communications parameters from at least two pre-defined communication parameter sets and these sets may ultimately be forwarded to the recipient server and/or the recipient.
- the method may also provide that the originator server stores the request and it may also provide that the recipient server stores the transfer inquiry - e.g., in case retransmission of such messages (or messages resulting therefrom) is required or in case a transcoding is to be performed.
- Additional steps that may be included in the method include forwarding, by the recipient server, the transfer inquiry to the recipient, and receiving, by the recipient server, a response to the transfer inquiry including the final parameters.
- the recipient server may modify the transfer inquiry according to predetermined transfer inquiry criteria (which may in turn be stored in a database) and forwards the modified transfer inquiry to the recipient.
- the method may include the step of generating, by the recipient server (rather than by the recipient), a response to the transfer inquiry based on predeter- mined delivery criteria (which may be stored in a database).
- the predetermined delivery criteria may include known capabilities of the recipient.
- the method may also include the step of converting, by either the recipient or the recipient server, the response to a format compatible with at least one of the originator server and the originator.
- a method for delivering a multimedia data file, such as an MMS, from an originator having an originator server associated therewith to a recipient having a recipient server associated therewith comprises establishing a communication path from the originator to the recipient via the originator server and the recipient server.
- the method further comprises receiving, by the originator server from the originator, the data file or portions of the data file, and, if the data file is received, splitting the data file into data file portions, and individually forwarding, by the originator server and without waiting for receipt of the complete data file, the data file portions received from the originator for reassembly by the recipient.
- At least one of the originator server and the recipient server receives one or more data file portions including at least one of a header and control information in relation to the data file.
- the originator server receives the data file in a single message together with at least one of a header and control information. Both variants allow the originator server and/or the recipient server to immediately start processing at least one of the header and the control information without waiting for the complete receipt of the data file. Accordingly, the originator server and/or the recipient server may determine transmission related aspects like the recipient of the data file and/or the length of the data file at a very early stage of the data file transmission.
- the originator server may notify the recipient server of information in relation to the data file that is to be forwarded by the originator server while the originator server still receives the data file or the data file portions from the originator.
- the advantage of such a procedure is the fact that the recipient server may for example allocate resources for the data file it will receive and/or inform the recipient of the data file transmission at a very early stage.
- the invention may also be embodied in a computer program product, which may be stored on a computer readable recording medium, comprising program code portions for performing the steps of the methods described herein when the computer pro- gram product is run on one or more computers or computer systems.
- the invention is embodied in a system comprising a computer processor and a memory coupled to the processor, where the memory is encoded with one or more programs that perform the steps of the methods described herein.
- An apparatus to deliver a multimedia data file, such as an MMS, from an originator having an originator server associated therewith to a recipient via an established communication path is also enabled by the current invention.
- Such an apparatus may comprise a reception unit to receive portions of the data file from the originator server, the data file or the data file portions being uploaded to the originator server from the originator, and a relay unit to individually forward the portions of the data file received from the originator server for reassembly by the recipient, wherein the data file portions are forwarded without waiting for receipt of the complete data file.
- the invention may also comprise an apparatus to deliver a multimedia data file, such as an MMS, from an originator to a recipient having a recipient server associated therewith via an established communication path.
- a multimedia data file such as an MMS
- Such an apparatus may comprise a reception unit to receive the data file or portions of the data file from the originator, and, if the data file is received, to split the data file into data file portions, and a relay unit to individually forward the data file portions received from the originator for reassembly by the recipient, wherein the data file portions are forwarded without waiting for receipt of the complete data file.
- the invention takes the form of a system to deliver a multimedia data file, such as an MMS, via an established communication path.
- the system includes an originator user agent to initiate transmission of the data file, a recipient user agent, an originator server associated with the originator user agent, and a recipient server associated with the recipient user agent.
- the originator uploads the data file or data file portions to the originator server
- the originator server sends a plurality of portions of the data file to the recipient server
- the recipient server individually forwards the portions of the data files received to the recipient for reassembly without waiting for receipt of the complete data file.
- Fig. 1 is a first signalling diagram showing a technique relating to the transfer of a multimedia data file
- Fig. 2 is a second signalling diagram showing a technique relating to the transfer of a multimedia data file
- Fig. 3 is a third signalling diagram showing a technique relating to the transfer of a multimedia data file
- Fig. 4 is a process flow diagram according to a method embodiment of the invention.
- Fig. 5 is a schematic diagram according to an apparatus embodiment of the invention.
- Fig. 6 is a signalling diagram of an example relating to the initiation of the transfer of a multimedia data file useful for understanding and implementing the invention
- Fig. 7 is a signalling diagram of an example relating to the transfer of a multimedia data file useful for understanding and implementing the inven- tion;
- Fig. 8 is a first signalling diagram showing an immediate forwarding and notification process according to the present invention.
- Fig. 9 is a second signalling diagram showing an immediate forwarding and notification process according to the present invention. -14/7L0 -
- Fig. 4 discloses a method 400 for delivering a data file, such as an MMS, from an originator (such as a first mobile terminal) having an originator server associated therewith to a recipient (such as a second mobile terminal) having a recipient server associated therewith.
- the method commences, at step 410, with establishing a communication path from the originator to the recipient via the originator server and the recipient server.
- the method continues, at step 420, with the receipt, by the originator server from the originator or by the recipient server from the originator server, of at least portions of the data file (uploaded to the originator server from the originator).
- the method continues with the individual forwarding, by the originator server or by the recipient server and without waiting for receipt of the complete data file, of the received portions of the data file for reas- sembly by the recipient (e.g., based on a sequence number that may be associated with each data file portion). -13/7 L l -
- Fig. 5 illustrates an apparatus 500 to deliver a multimedia data file, such as an MMS, from an originator having an originator server associated therewith to a recipient via an established communication path.
- the apparatus 500 includes two main components, a reception unit 510 to receive at least portions of the data file from the origi- nator or the originator server, the data file or the data file portions being uploaded to the originator server from the originator, and a relay unit 520 to individually forward the portions of the data files received from the originator or the originator server for reassembly by the recipient, wherein the data file portions are forwarded without waiting for receipt of the complete data file.
- network component is a mobile communications device or mobile unit, it will be appreciated that the foregoing is also applicable to a wide variety of computer network components including wired terminals.
- a signaling diagram 600 is provided in which signals are exchanged among an Originator MMS UA (User Agent) 610, an Originator MMS Re- lay/Server 620, a Recipient MMS Relay/Server 630, and a Recipient MMS UA 640 as part of a negotiation that takes place prior to the actual transfer of an MMS and regarding the parameters by which the MMS will be delivered from the Originator MMS UA 610 to the Recipient MMS UA 640. It will be noted, that if desired, the Originator MMS Server 620 and Recipient MMS Server 630 may combined within the same physical network entity.
- the Originator MMS UA 610 sends proposed communication parameters to the Originator MMS Server 620.
- These communication parameters may comprise a variety of communication principles that will dictate the manner in which an MMS or other multimedia file is ultimately transferred from the Originator MMS UA 610 to the Recipient MMS UA 640.
- the parameters may include MMS content type and size, codecs applied to code the multimedia file (and/or the underlying content), the number of MMS content parts and optionally the size of each data file portion (which may not be known in advance depending on the desired configuration), the sequence number of each data file portion (unless standardized), the procedure to request lost portions of the data file (unless standardized), information pertaining to the underlying content within each portion of the data file (which may, for example, be used by the Recipient MMS UA 640 to inform the Originator MMS UA 610 that certain portions of the data file need not be transmitted), single or multiple user data file delivery, whether ACKs / NACKs are to be used to (passively) confirm the correct reception of a data file portion, and the like.
- the Originator MMS UA 610 may also send several options of communications parameters (e.g., fixed transmission templates) such that the Recipient MMS Server 630 and/or the Recipient MMS UA 640 may select the optimal set of communication parameters.
- communications parameters e.g., fixed transmission templates
- Signal 6B (which may be an MMS_Comm.REQ signal), that is sent from the Originator MMS Server 620 to the Recipient MMS Server 630, forwards the proposed communication parameters (or sends a modified message signal associated with the communication parameters or a set of communication parameters).
- the Originator MMS Server 620 may also store (e.g., in a local memory or in a database) the information pertaining to the communications parameters contained within signal 6A.
- signal 6B may simply contain a reference to a particular set of predefined communications parameters.
- the Recipient MMS Server 630 forwards the proposed communications parameters (or information pertaining thereto) to the Recipient MMS UA 640.
- the Recipient MMS Server 630 may also optionally store the information contained within signal 6B (e.g., in a load memory or in a database) prior to sending signal 6C. If the Recipient MMS Server 630 has been provided with information regarding the capabilities of the Recipient MMS UA 640, it may optionally exclude certain proposed communication parameters or modify the individual communication parameters sent within signal 6C.
- the Recipient MMS UA 640 (which may optionally store the proposed communication parameters) returns a result to the request of signal 6C.
- the result may be a simple OK indication (meaning that the proposed communication parameters are acceptable), or alternatively, the result may comprise a list of accepted or excluded parameters or a list of modified parameters. These exclusions or changes may be based on defined parameters or limitations present within the Recipient MMS UA 640. If sets of parameters are used, then simplified and more efficient signaling may be exchanged. In case profile information was sent, the result may indicate a selected profile. As indicated by the dashed-lines in Fig.
- signals 6C and 6D may not be required depending on the desired configuration.
- the Recipient MMS Server 630 may access or include a database that contains information relating to the capabilitiesi- ties or multimedia file transfer preferences of the Recipient MMS UA 640, therefore obviating the need for signals 6C and 6D.
- the first message containing a data file portion should be preceded by an MMljiotification.REQ message and an MMl_notification.RES message. In the existing MMS specifications, these messages are used to notify the recipient that there is a MMS content that can be retrieved.
- the Recipient MMS Server 630 via signal 6E, returns the response regarding the proposed communication parameters to the Originator MMS Server 620.
- the Recipient MMS Server 630 may install a converter function and still return the unmodified communication parameters back to the Originator MMS Server 620. This may be done when there are inconsistencies between the proposed communication parameters and the communication parameters supported at the receiving side.
- the Recipient MMS Relay/Server 630 may then, for example, perform a codec conversion of the actual content, remove color bits and/or perform similar operations.
- the Originator MMS Server 620 then returns the communications parameters back to the Originator MMS UA 610 via signal 6F.
- the Originator MMS Server 620 may install a converter function if the communications parameters have not previously been converted by the Recipient MMS Server 630.
- the MMS_Comm.REQ signal indicates that the communication parameters might be fixed and cannot be changed (due, in part, to the fact that the data file must be delivered in a uniform manner and the recipient UAs have agreed to such delivery when registering for the multicast or other multiple user session or service).
- no MMS_Comm.RES signal may be returned by the Recipient MMS UAs (as such signaling could overload the network).
- Fig. 7 provides a signaling diagram 700 that illustrates the exchange of signals among the Originator MMS UA 610, the Originator MMS Server 620, a Recipient MMS -10/7.4 -
- the Recipient MMS UA 640 may send signal 7A (such as a MMl_retrieve.REQ signal) to the Recipient MMS Server 630 to initiate the retrieval of a data file portion from the MMS Relay Server 630 (e.g., whenever each data file portion arrives at the Recipient MMS Relay Server 630). Via signal 7B (such as a MMl.submit.REQ signal), the Originator MMS UA 610 uploads a data file portion to the Originator MMS Server 620.
- signal 7A such as a MMl_retrieve.REQ signal
- signal 7B such as a MMl.submit.REQ signal
- signal 7C such as a MM4_forward.REQ signal
- the Originator MMS Server 630 directly (and, optionally, as soon as it has been received) forwards the data file portion to the Recipient MMS UA 630.
- signal 7D such as a MMl.retrieve.RES signal
- the Recipient MMS UA 630 directly (and, optionally, as soon as it has been received) forwards the data file portion to the Recipient MMS UA 640.
- the signaling sequence represented by signals 7B (via signals 7E and 7K), 7C (via signals 7F and 7L), and 7D (via signals 7G and 7M), may be repeated multiple times until all data file portions have been received by the Recipient MMS UA 640.
- signal 7A may be sent before, during, or after signals 7B and 7C. However, the delivery of the data file portion to the Recipient MMS UA 640 (via signal 7D) will not commence before signal 7A has been received. In the case of multiuser services, signal 7A may not be sent (and could overload the network), and the data file portions are delivered to the Recipient MMS UA 640 as soon as they are received by the Recipient MMS Server 630.
- Each of the data file portions includes a sequence number that may be used to detect missing data file portions and/or for re-assembling purposes. If the Originator MMS Server 620, the Recipient MMS Server 630, or the Recipient MMS UA 640 detects a missing data file portion, such components inform their counterparts in the traffic chain accordingly (as shown by signals 7H, 71, 7J, 7N, 7O, and 7P all of which are indicated by dashed lines). In order to minimize any further delays and traffic that would result from the retransmission of data file portions that were not correctly received, the Originator MMS Server 620 and the Recipient MMS Server 630 may cache the data file portions in order to avoid such data file portions from being up- loaded once more via the radio network.
- a signal from any of the Originator MMS Server 620, the Recipient MMS Server 630, and the Recipient MMS UA 640 may be ultimately sent to the Originator MMS UA 610 indicating that a certain data file portion (or subdivision thereof) need not be transferred.
- the recipient may then decide that not all content parts are actually needed or wanted. Assume, for example, that an MMS includes a trailer plus video/audio content. In such an scenario the recipient may indicate that only the trailer is wanted. In another scenario the MMS may include slights, video content plus audio content. The recipient may then indicate that only the slights and the au- dio content are wanted (i.e., that the video content need not be transferred).
- the correct reception of the complete data file portion is confirmed by the Recipient MMS UA 640 to the Recipient MMS Server 630 which forwards the confirmation, via signal 7R, to the Originator MMS Server 620 which is acknowledged via signal 7S and subsequently forwarded, via signal 7T, to the Originator MMS UA 610.
- the Recipient MMS UA 640 may also send a read-reply-report, via signal 7U, to the Recipient MMS Server 630, which in turn forwards the read-reply-report to the Originator MMS Server 620 by way of signal 7V which is acknowledged via signal 7W and forwarded, via signal 7X, to the Originator MMS UA 610.
- the read-reply- report may also contain diverse information such as when the data file portions were read, how long the data file portions were accessed, etc.
- the objective of alternative embodiments is to minimize the terminal impacts on the sender and the receiver.
- the basic idea is to start the forwarding and notification process as soon as the Originator MMS Relay/Server (i.e., the originator MMSC) can determine the Recipient MMS User Agent and thus the Recipient MMS Relay/Server.
- the parsing of the MMS is started immediately after the Originating MMSC receives the MMl_submit.REQ message.
- two new interactions are introduced to upload a message header separately from the message content.
- the intermediate nodes do not need to know the full MMS content.
- the intermediate nodes just need the header and control information and maybe also a flag, indicating that the actual MMS content is delivered in a "streamed" way. This also means that the end-to-end message sequence is changed for a MMS delivery.
- the sequence on the interface e.g., MMl or MM4 is not necessarily impacted.
- Fig. 8 illustrates the first variant of a modified signaling diagram for the progressive MMS delivery.
- the sequences on the MMl and the MM4 interfaces are "interleaved", which allows for a much quicker delivery of the MMS from the originator to the recipient.
- An Originator MMS User Agent 810 sends the MMS (including a header and control information) "as usual" to an Originator MMSC 820.
- the Originator MMSC 820 starts processing and evaluating the MMS header and control information as soon as they have been received (it is not necessary to wait for the end of the MMS transmission to evaluate the already received parts).
- a "header length" field extends the MMl message 8A. The field would allow the Originator and a Recipient MMSCs 820, 830 to first count the received bytes, before trying to extract and process the header.
- the Originator MMSC 820 When the Originator MMSC 820 has received the MMS header and control information, the Originator MMSC 820 immediately parses the header and determines a Re- cipient MMSC 830. The Originator MMSC 820 uses an MM4_forward.REQ message 8B to send the MMS header to the Recipient MMSC 830. The communication link between the Originator and Recipient MMSCs 820, 830 is kept open for the actual MMS content. Optionally, the Originator MMSC 820 keeps a copy of the entire MMS (header and content) for failure operations until it receives a MM4_forward.RES mes- sage from the recipient MMSC.
- the Originator MMSC 820 has determined the Recipient MMSC 830 capabilities before this procedure. There are several ways to determine the supported capabilities of the Recipient MMSC 830. Here, it is assumed, that the Originator MMSC 820 knows the capabilities of the Recipient MMSC 830.
- an MMS content length field extends the MM4 messages. This is mainly used for monitoring purposes, since the used protocols between Originator and Recipient MMSC 720, 830 are reliable.
- the Recipient MMSC 830 receives first the header and control information for the incoming MMS (e.g. in an initial MMS portion generated by the Originator MMSC 820 by splitting the MMS in a plurality of MMS portions individually forwarded to the Recipient MMSC 830). It allocates a file name for the incoming MMS before the entire MMS is received from the Originator MMSC 820. The URL of the filename is for- warded in the notification message 8C to a Recipient MMS User Agent 840 (the standard procedure for storing the incoming MMS is considered). The Recipient MMSC 830 starts the notification procedure and sends an SMS with the URL to the MMS to the Recipient User Agent 840 although the entire MMS content is not yet available in the Recipient MMSC 830.
- the receiving MMS User Agent 840 starts the retrieval procedure and contacts the Recipient MMSC 830 using an MMl_retrieve.REQ message 8E.
- the Recipient MMSC 830 answers with an MMl_retrieve.RES message 8E, although it does not have yet the full MMS content (it is likely, that the Recipient MMSC 830 has already received further parts of the MMS content, since the notification procedure takes some time).
- the Recipient MMSC 830 is receiving the MMS content from the Originator MMSC 820 while already delivering the MMS content to the Recipient MMS User Agent 840. Since the MMl link is usually slower than the MM4 link, the Recipient MMSC 830 will have sufficient information to send to the Recipient MMS User Agent 840.
- the Recipient MMSC 830 responds with an MM4_forward.RES message 8H.
- the second variant shown in Fig. 9 follows mainly the first variant of Fig. 8. The only difference is that new procedures to forward the header information are introduced. The procedures are used to forward (one or both of) the MMS header and control information (e.g., in an initial MMS portion that is followed by subsequent MMS portions containing the actual MMS content). This allows a network node to first fully receive a transmission before processing it.
- the procedures are also used to determine the capabilities of the next node (i.e. Originating and Recipient MMSCs 920, 930). In case the node reacts with an error messages (or not all all), the sender can fall back to standard procedures.
- a signaling diagram of the second variant is depicted.
- RES] messages 9C, 9D are newly introduced messages just to forward the MMS header and control information.
- the Originator MMSC 920 processes this message and establishes a communication path to the Recipient MMSC 930 using the MM4-header messages. Both MMSCs 920, 930 keep state information to handle and forward the actual MMS transmission (optionally only the MMS content).
- the notification procedure may be started.
- the notification message contains an URL to a still empty file. It should be noted that due to the duration of the MMl_notification procedure, the file might already contain parts of the MMS content.
- the Recipient MMS User Agent 940 When the Recipient MMS User Agent 940 is online and available to receive an incoming MMS, it starts the MMl retrieve procedure to fetch the content. In an optimal situation (when also Recipient 940 is online), the Recipient 940 will receive the MMS while the Originator 910 is still sending.
- This invention is also beneficial in case an MMS is sent from a server to one or several Recipient MMS UA's, because still the terminating part of the MMS delivery is optimized in that case.
- the current invention provides many advantages over conventional techniques for delivering a multimedia data file such as faster delivery (approaching real-time), reduced average holding of network and terminal buffers, and reduced processing ca- pacity requirements. Additionally, there is in principle no limit concerning the (maximum) size of an MMS. Furthermore, as the techniques described herein provide more efficient data transfer, network operators may provide incentives for originator UAs to subdivide multimedia data files prior to transfer, such as by charging a lower tariff.
- the current invention has been described with respect to particular embodiments (including certain system arrangements and certain orders of steps within various methods), those skilled in the art will recognize that the current invention is not limited to the specific embodiments described and illustrated herein.
- the current invention may be used to transfer any type of data file from a first network component (such as an originator user agent) to a second network component (such as a recipient user agent).
- a first network component such as an originator user agent
- a recipient user agent such as a second network component
- the subdivision of the multimedia data file into portions may occur in a recipient MMS server rather than an originator MMS server or even by the WAP gateway (provided that an indication is provided in one of the data file portions).
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Multimedia (AREA)
- Information Transfer Between Computers (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
Description
Claims
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2004/013593 WO2006058544A1 (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
CN2004800445230A CN101073237B (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
US11/720,382 US8095116B2 (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
EP04803372.4A EP1829315B1 (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/EP2004/013593 WO2006058544A1 (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
Publications (2)
Publication Number | Publication Date |
---|---|
WO2006058544A1 true WO2006058544A1 (en) | 2006-06-08 |
WO2006058544A9 WO2006058544A9 (en) | 2006-09-28 |
Family
ID=34959678
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/EP2004/013593 WO2006058544A1 (en) | 2004-11-30 | 2004-11-30 | Method for delivering multimedia files |
Country Status (4)
Country | Link |
---|---|
US (1) | US8095116B2 (en) |
EP (1) | EP1829315B1 (en) |
CN (1) | CN101073237B (en) |
WO (1) | WO2006058544A1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2009079794A1 (en) * | 2007-12-20 | 2009-07-02 | Chalk Media Service Corp. | A method and system for the delivery of large content assets to a mobile device over a mobile network |
WO2009106683A1 (en) * | 2008-02-25 | 2009-09-03 | Floobs Oy | An apparatus, a method, a computer program product and a system for encoding video stream |
EP1691505A3 (en) * | 2005-02-07 | 2010-01-20 | Samsung Electronics Co., Ltd. | Method and system for transmitting a multimedia message |
US20120023244A1 (en) * | 2007-10-17 | 2012-01-26 | Twitchell Jr Robert W | Ip server facilitating network communications between devices utilizing virtual network connections |
US8560634B2 (en) | 2007-10-17 | 2013-10-15 | Dispersive Networks, Inc. | Apparatus, systems and methods utilizing dispersive networking |
WO2014169233A3 (en) * | 2013-04-12 | 2015-01-22 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
US8941659B1 (en) | 2011-01-28 | 2015-01-27 | Rescon Ltd | Medical symptoms tracking apparatus, methods and systems |
US8955110B1 (en) | 2011-01-14 | 2015-02-10 | Robert W. Twitchell, Jr. | IP jamming systems utilizing virtual dispersive networking |
Families Citing this family (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9282081B2 (en) * | 2005-07-28 | 2016-03-08 | Vaporstream Incorporated | Reduced traceability electronic message system and method |
US8437751B2 (en) * | 2006-04-25 | 2013-05-07 | Core Wireless Licensing S.A.R.L. | Method, apparatus and computer program product for providing confirmed over-the-air terminal configuration |
CN101345776B (en) * | 2008-08-14 | 2011-12-07 | 中兴通讯股份有限公司 | Content adapting implementing method and content adapting server |
GB2464354B (en) * | 2009-03-13 | 2011-06-08 | 4Energy Ltd | Equipment enclosure |
US8458597B1 (en) * | 2010-02-04 | 2013-06-04 | Adobe Systems Incorporated | Systems and methods that facilitate the sharing of electronic assets |
KR101293370B1 (en) * | 2011-02-10 | 2013-08-05 | 주식회사 엘지씨엔에스 | System and method for servicing customized mobile content |
US9060255B1 (en) * | 2011-03-01 | 2015-06-16 | Sprint Communications Company L.P. | Adaptive information service access |
WO2013074006A1 (en) * | 2011-11-17 | 2013-05-23 | Telefonaktiebolaget L M Ericsson (Publ) | Divided multimedia messaging delivery |
US9596183B2 (en) | 2014-12-12 | 2017-03-14 | Western Digital Technologies, Inc. | NAS off-loading of network traffic for shared files |
CN106850426B (en) * | 2017-01-10 | 2020-09-29 | 北京交通大学 | Multi-path data transmission method and device based on partial data overlapping |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5996015A (en) * | 1997-10-31 | 1999-11-30 | International Business Machines Corporation | Method of delivering seamless and continuous presentation of multimedia data files to a target device by assembling and concatenating multimedia segments in memory |
WO2001024474A1 (en) * | 1999-09-27 | 2001-04-05 | Koninklijke Philips Electronics N.V. | Partitioning of file for emulating streaming |
EP1315354A1 (en) * | 2001-11-23 | 2003-05-28 | Ibrahim Evsan | Method for transfer and playback of multimedia data |
WO2004088501A1 (en) * | 2003-03-28 | 2004-10-14 | Thomson Licensing S.A. | System and method for transmitting media based files |
Family Cites Families (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6865191B1 (en) * | 1999-08-12 | 2005-03-08 | Telefonaktiebolaget Lm Ericsson (Publ) | System and method for sending multimedia attachments to text messages in radiocommunication systems |
FI110297B (en) * | 2000-08-21 | 2002-12-31 | Mikko Kalervo Vaeaenaenen | Short message system, method and terminal |
US7164680B2 (en) * | 2001-06-04 | 2007-01-16 | Koninklijke Philips Electronics N.V. | Scheme for supporting real-time packetization and retransmission in rate-based streaming applications |
US7243366B2 (en) * | 2001-11-15 | 2007-07-10 | General Instrument Corporation | Key management protocol and authentication system for secure internet protocol rights management architecture |
JP2003242008A (en) * | 2002-02-18 | 2003-08-29 | Riso Kagaku Corp | File downloading device and program, and file creating device |
US7103681B2 (en) * | 2003-06-19 | 2006-09-05 | Nokia Corporation | System for rendering multimedia messages by providing, in a multimedia message, URL for downloadable software to receiving terminal |
EP1751956B1 (en) * | 2004-05-13 | 2011-05-04 | Qualcomm, Incorporated | Delivery of information over a communication channel |
US20050287993A1 (en) * | 2004-05-26 | 2005-12-29 | Aleksandar Gogic | Apparatus, system, and method for providing voicemail service using a packet data messaging system |
-
2004
- 2004-11-30 CN CN2004800445230A patent/CN101073237B/en not_active Expired - Fee Related
- 2004-11-30 WO PCT/EP2004/013593 patent/WO2006058544A1/en active Application Filing
- 2004-11-30 EP EP04803372.4A patent/EP1829315B1/en not_active Not-in-force
- 2004-11-30 US US11/720,382 patent/US8095116B2/en not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5996015A (en) * | 1997-10-31 | 1999-11-30 | International Business Machines Corporation | Method of delivering seamless and continuous presentation of multimedia data files to a target device by assembling and concatenating multimedia segments in memory |
WO2001024474A1 (en) * | 1999-09-27 | 2001-04-05 | Koninklijke Philips Electronics N.V. | Partitioning of file for emulating streaming |
EP1315354A1 (en) * | 2001-11-23 | 2003-05-28 | Ibrahim Evsan | Method for transfer and playback of multimedia data |
WO2004088501A1 (en) * | 2003-03-28 | 2004-10-14 | Thomson Licensing S.A. | System and method for transmitting media based files |
Cited By (30)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1691505A3 (en) * | 2005-02-07 | 2010-01-20 | Samsung Electronics Co., Ltd. | Method and system for transmitting a multimedia message |
US8560634B2 (en) | 2007-10-17 | 2013-10-15 | Dispersive Networks, Inc. | Apparatus, systems and methods utilizing dispersive networking |
US8341292B2 (en) | 2007-10-17 | 2012-12-25 | Dispersive Networks Inc. | Network communications of applications running on device utilizing different virtual network connections with different routing protocols |
US8848704B2 (en) | 2007-10-17 | 2014-09-30 | Dispersive Networks Inc. | Facilitating network routing using virtualization |
US8341291B2 (en) | 2007-10-17 | 2012-12-25 | Dispersive Networks Inc. | Network communications of application running on device utilizing virtual network connection and routing protocol based on application connection criteria |
US9350794B2 (en) | 2007-10-17 | 2016-05-24 | Dispersive Networks, Inc. | Transmitting packet from device after timeout in network communications utilizing virtual network connection |
US8352636B2 (en) | 2007-10-17 | 2013-01-08 | Dispersive Networks Inc. | Transmitting packets from device in network communications with other device utilizing multiple virtual network connections |
US8423664B2 (en) | 2007-10-17 | 2013-04-16 | Dispersive Networks Inc. | Network communications of application running on device utilizing multiple virtual network connections |
US8429226B2 (en) | 2007-10-17 | 2013-04-23 | Dispersive Networks Inc. | Facilitating network communications with control server, hosting server, and devices utilizing virtual network connections |
US8429293B2 (en) * | 2007-10-17 | 2013-04-23 | Dispersive Networks Inc. | IP server facilitating network communications between devices utilizing virtual network connections |
US8433819B2 (en) | 2007-10-17 | 2013-04-30 | Dispersive Networks Inc. | Facilitating download of requested data from server utilizing virtual network connections between client devices |
US8433818B2 (en) | 2007-10-17 | 2013-04-30 | Dispersive Networks Inc. | Network communications of application running on device utilizing virtual network connections with redundancy |
US9246980B2 (en) | 2007-10-17 | 2016-01-26 | Dispersive Networks Inc. | Validating packets in network communications |
US8539098B2 (en) | 2007-10-17 | 2013-09-17 | Dispersive Networks, Inc. | Multiplexed client server (MCS) communications and systems |
US9241025B2 (en) | 2007-10-17 | 2016-01-19 | Dispersive Networks Inc. | Network communications of applications running on devices utilizing virtual network connections with asymmetrical network paths |
US20120023244A1 (en) * | 2007-10-17 | 2012-01-26 | Twitchell Jr Robert W | Ip server facilitating network communications between devices utilizing virtual network connections |
US9241026B2 (en) | 2007-10-17 | 2016-01-19 | Dispersive Networks Inc. | Facilitating network communications with control server and devices utilizing virtual network connections |
US8447882B2 (en) | 2007-10-17 | 2013-05-21 | Dispersive Networks Inc. | Software router facilitating network communications between devices utilizing virtual network connections |
US9167025B2 (en) | 2007-10-17 | 2015-10-20 | Dispersive Networks Inc. | Network communications of application running on device utilizing routing of data packets using virtual network connection |
US8959627B2 (en) | 2007-10-17 | 2015-02-17 | Dispersive Networks, Inc. | Quarantining packets received at device in network communications utilizing virtual network connection |
US9055042B2 (en) | 2007-10-17 | 2015-06-09 | Dispersive Networks Inc. | Providing network communications satisfying application requirements using virtualization |
US9059975B2 (en) | 2007-10-17 | 2015-06-16 | Dispersive Networks Inc. | Providing network communications using virtualization based on protocol information in packet |
US9071607B2 (en) | 2007-10-17 | 2015-06-30 | Dispersive Networks Inc. | Virtual dispersive networking systems and methods |
US9100405B2 (en) | 2007-10-17 | 2015-08-04 | Dispersive Networks Inc. | Apparatus, systems and methods utilizing dispersive networking |
WO2009079794A1 (en) * | 2007-12-20 | 2009-07-02 | Chalk Media Service Corp. | A method and system for the delivery of large content assets to a mobile device over a mobile network |
WO2009106683A1 (en) * | 2008-02-25 | 2009-09-03 | Floobs Oy | An apparatus, a method, a computer program product and a system for encoding video stream |
US8955110B1 (en) | 2011-01-14 | 2015-02-10 | Robert W. Twitchell, Jr. | IP jamming systems utilizing virtual dispersive networking |
US8941659B1 (en) | 2011-01-28 | 2015-01-27 | Rescon Ltd | Medical symptoms tracking apparatus, methods and systems |
WO2014169233A3 (en) * | 2013-04-12 | 2015-01-22 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
US9900166B2 (en) | 2013-04-12 | 2018-02-20 | Qualcomm Incorporated | Methods for delivery of flows of objects over broadcast/multicast enabled networks |
Also Published As
Publication number | Publication date |
---|---|
WO2006058544A9 (en) | 2006-09-28 |
EP1829315B1 (en) | 2016-08-17 |
CN101073237B (en) | 2012-02-01 |
US8095116B2 (en) | 2012-01-10 |
EP1829315A1 (en) | 2007-09-05 |
US20080305773A1 (en) | 2008-12-11 |
CN101073237A (en) | 2007-11-14 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP1829315B1 (en) | Method for delivering multimedia files | |
JP4884924B2 (en) | Terminal and its message processing method | |
US8209432B2 (en) | Method and arrangement for communicating multimedia content | |
US20070070988A1 (en) | Method For Transmitting Deferred Messages | |
JP4948525B2 (en) | Instant message transmission method and system for mobile communication terminal | |
CN100542172C (en) | A kind of deferred information method of sending and receiving | |
US20020087549A1 (en) | Data transmission | |
JP5274668B2 (en) | Method and apparatus for controlling session for interworking in integrated IP messaging service and system thereof | |
AU2009281584B2 (en) | A method for performing multimedia messaging service interworking forwarding message removing duplication protection and multimedia messaging service interworking gateway thereof. | |
WO2008074235A1 (en) | Interconnection methods and message interconnection gateways between message systems | |
WO2002100066A1 (en) | Method and device for messaging | |
EP1569409A2 (en) | Method for transferring a message file between a client and a server | |
CN113489786A (en) | Long connection network weak network reconnection method and retransmission method | |
KR101372385B1 (en) | Method and system for transmitting converged ip message in large message mode | |
KR100431466B1 (en) | System And Method For Streaming Service In Mobile Internet | |
CN116896546B (en) | Visual intercom method, system and storage medium based on SRT communication protocol | |
CN101588546A (en) | Method, device and system for transmitting non-CPM service | |
CN108337215A (en) | A kind of document transmission method and system, device, electronic equipment | |
KR101006141B1 (en) | Method of transmitting a sip message | |
WO2009152717A1 (en) | Method, apparatus and system for transmitting messages |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AK | Designated states |
Kind code of ref document: A1 Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW |
|
AL | Designated countries for regional patents |
Kind code of ref document: A1 Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG |
|
DPE2 | Request for preliminary examination filed before expiration of 19th month from priority date (pct application filed from 20040101) | ||
121 | Ep: the epo has been informed by wipo that ep was designated in this application | ||
WWE | Wipo information: entry into national phase |
Ref document number: 200480044523.0 Country of ref document: CN |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
REEP | Request for entry into the european phase |
Ref document number: 2004803372 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2004803372 Country of ref document: EP |
|
WWP | Wipo information: published in national office |
Ref document number: 2004803372 Country of ref document: EP |
|
WWE | Wipo information: entry into national phase |
Ref document number: 11720382 Country of ref document: US |