GB2495338A - Sending a multimedia message from a first to a second user via first and second portions of a memory coupled to a server - Google Patents

Abstract

Sending a multimedia message, comprising video and/or audio, from a first user to a second user, comprising: receiving a first multimedia message from a first user device at a streaming media server; storing the first message in a first portion of memory coupled to the server, in a folder associated with the first user; and, to send the message to another user, a copy of the first multimedia message is stored in a second portion of memory coupled to the server, different to the first portion, in a folder associated with the second user. In order for the second user to view the message the copy of the first message is streamed, using the streaming media server, to a second user device. Because both users have access to their own physical copies of the message both can view the message by streaming it to their respective user devices without degraded or slowed performance.

Description

VIDEO COMMUNICATION SYSTEM

FIELD OF THE INVENTION

The present invention relates to a system and method for sending and receiving video messages between user terminals over the Internet or other available communication channels.

BACKGROUND OF THE INVENTION

Systems exist to allowing individuals to communicate over the Internet. Examples include audio exchanges between user terminals using "Voice over Internet Protocols" (VoIP) that provide the communication protocols and transmission techniques for delivering voice communications. There also exist video email systems for delivering multimedia content, containing both video and audio content, from one user to another.

Known video email systems tend to require the user to attach a video recording to an email message which is then sent over the internet via email servers according to email protocols such as IMAP, POP3 and SMTP. The problem with such systems is that accessing the attached video tends to be cumbersome. Not only does the user need to find the video message within the email text, but they must then wait for the video message to download to their system.

An improved email video system is described in US patent application US 2003,0172116 which describes a system in which the video message is recorded within the email program itself, improving access to video email functionality. Unfortunately, such a system still operates on conventional email rules where, despite the video feature being incorporated into the user interface, the email and video features each remain as two separate technical functions-The functionality is such that a video is treated as an attachment to an email and is served as an additional item to the email. This leads to a series of user experience and technical performance issues including requiring the user to manually enter one or more recipients for a video message. Such systems are also still prone to delays between the user sending a video file and the intended recipient being able to view it.

What is required is an improved system and method for sending and receiving multimedia messages between two or more users.

SUMMARV OF THE INVENTION

The invention is defined in the independent claims, to which reference is now directed.

Preferied features are set out in the dependent claims.

Embodiments of the present invention enable video messages, which may otherwise be known as visual messages, to be sent between one or more users. The term "video" is not intended to refer to a predetermined format of moving image such as film, video, CD, DVD etc. Rather the term is intended to represent a series of images combined to form a moving picture.

Embodiments according to a first aspect of the invention may provide a method for sending a multimedia message, comprising video and/cr audio, from a first user to a second user.

The method comprises receiving a first multimedia message from a first user device at a streaming media server. The first message is stored, in memory coupled to the server such as an internal or external memory, in a folder associated with the first user. The first multimedia message occupies a first portion of memory. In order to send the message to another user a copy of the first multimedia message is stored, in memory coupled to the server, in a folder associated with the second user. The second multimedia message occupies a second portion of memory different to the first portion. In order for the second user to view the message the copy of the first message is streamed, using the streaming media server, to a second user device. Because both users have access to their own physical copies of the message both can view the message by streaming it to their respective user devices without degraded or slowed performance.

The method may further accommodate replies to the first message. A second multimedia message may be received from the second user device, the second message being identified as a reply to the first message. The method then further comprises storing, in memory coupled to the server, the second multimedia message in the folder associated with the second user, creating, within the respective folders associated with the first and second users, a folder associated with the first message and storing, in memory coupled to the server, a copy of the second message in each of the folder associated with the first user and the folders associated with the first message for both the first and second users.

Each copy is distinct on memory, occupying a different portion of memory from the other copies. In order to view the second message the user streams a copy of it to the first user device. Separate copies of the message again ensure each user can access a message without degradation in access quality or speed, as well as ensuring control of each user over their stored messages is not impeded by actions taken by another user.

Preferably, the method further comprises, at the server, generating respective copies of the first message and inserting a copy into each of the folders associated with the first message located in the first and second users' files respectively, each copy occupying a different portion of memory.

The method preferably further includes, at the server, inserting, into each copy of the first message, data indicating that the first message is part of a conversation being an exchange of two or more messages between the first and second users. The data is preferably inserted as a tag, or data field, within the message file name.

The second multimedia message from the second user device is preferably identified as a reply to the first message by user input caused by the operator of the second user device selecting an option to reply to the first message. This allows checking to be performed, at the server, as to whether the second message is a reply to the first message. In addition, the method may further include checking, at the server, whether the second message contains metadata indicative of the file name of the first message. If the second message does not contain metadata indicative of the file name of the first message the method preferably further comprises inserting, as metadata within the second message, data indicative of the file name of the first message. If the second message does contain metadata indicative of the file name of the first message the method preferably further comprises inserting, as metadata within the second message, the metadata from the first message. The message file name preferably comprises one or more of the message creator's user ID, a user defined title and the message creation date.

Embodiments according to a second aspect of the invention may provide a method for exchanging multimedia messages between a first user and a second user. Any feature described in relation to the second aspect of the invention may be incorporated into embodiments employing the first aspect and/or the third aspect. The method comprises, at a streaming media server, receiving a first multimedia message from the first user device, storing it in memory coupled to the server and streaming the first message from the server to the second user device. A second message is received from the second user device, and a check is performed, at the server, as to whether the second message is a reply to the first message. A check is also performed, at the server, to determine whether the first message contains metadata indicative of a previous message. If the first message does not contain metadata indicative of a previous message the method further comprises inserting, as metadata within the second message, data indicative of the first message.

Such a method ensures that messages are correctly associated with one another when they are part of an ongoing chain or series of messages.

Preferably, if the first message already contains metadata indicative of a previous message the method further comprises inserting, as metadata within the second message, the metadata from the first message. This allows a message chain to continue.

The second multimedia message from the second user device is preferably identified as a reply to the first message by user input by the operator of the second user device selecting an option to reply to the first message.

The method may further comprise, at the server, inserting, into the first message and the second message, data indicating that the messages are part of a conversation, being a series of messages or an exchange of two or more messages between the first and second users. Preferably the data is inserted as a tag, or a parameter within a data field, within the message file names.

The metadata within a message preferably comprises at Least a portion of the filename of a previous message. The message file name preferably comprises one or more of the message creator's user ID, a user defined title and the message creation date.

The method may further comprise, at the server, creating a folder in memory coupled to the server, in response to receiving the second message, the folder being associated with the first message; and storing the first and second messages within the folder, or linking the first and second messages to the folder. Preferably a folder is created for each of a first user and a second user each associated respectively with the first and second user device.

The method may further comprise the step of determining when a message is being made publicly accessible and, in response, removing the metadata indicative of a previous message, The method may also include removing any tag or parameter within a data field

S

within the message file name-Making the message publicly accessible preferably involves storing it in a publicly accessible folder.

Embodiments according to a third aspect of the invention may provide a method for recording multimedia messages at a streaming media server. Any feature described in relation to the third aspect of the invention may be incorporated into embodiments employing the first aspect and/or the second aspect. The method comprises providing a user device comprising a processor arranged to receive video from a video capture device and an internet connection for sending the received video to the streaming media server.

The user device is configured to control, in response to user input, one or more properties of the video received from the video capture device. This may be achieved, for example, by appropriate software being executed on the user device, or by software executing on the server apparatus with an interface being provided at the user device. The method further comprises detecting when the user device is sending video to the streaming media server for recording at the streaming media server, and deactivating user control of the one or more properties of the video when the user device is sending received video to the streaming media server for recording.

When the user device is used to provide an interface, with control being performed by software running on the server apparatus, the method may comprise configuring a user device, comprising a processor arranged to receive video from a video capture device and an internet connection for sending the received video to the streaming media server, to control, in response to user input, one or more properties of the video received from the video capture device. The method further includes detecting when the user device is sending video to the streaming media server for recording at the streaming media server, recording the received video at the streaming media server and controlling the user device to deactivate user control of the one or more properties of the video when recording the received video.

Whichever method is employed, the one or more properties of the video that may be controlled may comprise one or more of the screen size of the video window showing the images being captured by the video capture device, the number of frames per second captured by the video capture device, and the video quality.

A first predetermined countdown period is preferably initiated prior to the user device sending video to the streaming media server, whereby recording of the video at the server commences after the first countdown period has finished. The first countdown period is preferably displayed, on a display, to the user and may be adjusted to a desired value by the user.

Upon initiation of the start of recording video at the server, a second countdown period may be initiated and upon expiry of the second countdown period the recording of video is stopped.

A corresponding user device may be provided for streaming multimedia messages to a streaming media server, the user device comprising a processor arranged to receive video from a video capture device and an Internet connection for sending the received video to the streaming media server. The user device is configured to control, in response to user input, one or more properties of the video received from the video capture device, to detect when the user device is sending video to the streaming media server for recording at the streaming media server, and to deactivate the user control of the one or more properties of the video when the user device is sending received video to the streaming media server for recording.

A corresponding streaming media server may be provided, configured to perform the methods described above. This may be achieved by operating, on a streaming media server, appropriate software. A corresponding system for sending multimedia messages may also be provided, comprising such a streaming media server, along with a first user device and a second user device. The first user device comprises at least a processor arranged to receive as input from a device an audio and video signal and an internet connection for sending the received audio and video to the streaming media server. The second user device comprises at least an internet connection for receiving the captured audio and video from the streaming media server and a processor arranged to output the audio and video to an output device.

A computer program may be provided which, when operated on a streaming media server as described above, causes it to carry out the methods described above or herein. A computer program may also be provided which, when operated on a user device as described herein, causes it to carry out the methods described herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described in more detail with reference to the drawings, in which: Figure 1: is a diagram showing the basic elements of a system embodying the invention; Figure 2: is a chart showing the user actions and system functions involved in recording a multimedia message according to an embodiment of the invention; Figure 3: is a diagram of an example folder structure according to an embodiment of the invention; Figure 4: is a chart showing the user actions and system functions involved when sending a message according to an embodiment of the invention; Figure 5: is a chart showing the user actions and system functions involved in replying to a message according to an embodiment of the invention; Figure 6: is a chart showing in which user folders recorded messages are stored in accordance with an embodiment of the present invention; Figure 7: is a chart showing where further reply messages are stored in accordance with an embodiment of the present invention; Figure 8: is a chart showing the user actions and system functions involved in sending a message to a group of users; and Figure 9: is a chart showing the user actions and system functions involved in sending a message to a world file-space accessible by multiple users.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The basic elements of a system according to an embodiment of the invention are shown in Figure 1. The figure shows a first user device 101, being a communication device having a processor, an internet connection, a visual/video capture or replay device (e.g. video camera)103 for capturing moving images and a sound capturing device 104, such as a microphone, for capturing audio. A second user device 105 is also shown, being a communication device also having a processor 102, an internet connection, visual/video capture or replay device and Sound capturing device 104. Preferably both user devices are coupled to a display device 109 such as a screen, or are formed integral with a display.

The server apparatus 106 is connectable to both user devices via the internet and comprises a processor 107, operating server software, and memory 108. The user devices are located remotely from the server apparatus and from one another.

Both user devices either run a video messaging application which interacts with software running on the server or access the video messaging application via the internet, such as via an internet web-page. The user device, executing the appropriate software by any suitable means, provides a screen with a series of icons allowing the user to perform certain functionalities, including interfacing with the video camera and microphone hardware coupled to, or integral with, their communication device. A first icon, when activated by the user may cause the video capture device and microphone to start recording. The user is provided with a preview pane showing the moving images/video being recorded. Icons may be activated by, for example, using an interface control device such as a mouse, touch pad or touch screen, to click the icon.

The user records their multimedia message comprising audio, visual and data components.

The message is preferably recorded directly to the server by first streaming the recorded multimedia content, including the video and any accompanying audio, as produced by the audio and visual recording devices, to the server 106 and particularly to a user's "sent" folder. This is sent, for example, according to RIMP. At the server, the video and audio are encoded, using the processor 107, according to respective video and audio encoding codecs such as, for example H.264, or MPEG4 for video content or MP3 for audio content.

The encoded video and audio is stored as a message within a memory accessible to the server hardware 106, which may be a memory coupled to the server hardware or contained therein.

Once the message is recorded, the user has the option of sending it to a recipient. The sending process is activated, preferably, by the user controlling an icon on the screen. In particular, an icon representative of the desired recipient is selected using an interface control device and moved into the area of the display occupied by the preview screen or panel. At this point, releasing the icon, or"dropping" it, in this region of the screen causes

S

the message sending process to commence. Of course, any other suitable method of initiating the sending process may be used An example of the process involved in recording a message within the messaging application is shown in Figure 2. Figure 2 shows the actions undertaken by the user and the resulting steps taken by the messaging application. In order to record a message the user starts at step 21 and begins the process by activating an appropriate icon, such as a "record" icon, on the screen. This may begin an optional process that allows the user to input text data such as a message title, or other additional information and, in order to do so, the system may display an input panel. At steps 23 and 23A the user can then input a message title and additional information if required. The user may then, at step 24, activate an appropriate icon, such as a "start recording" icon or button, which initiates the recording process.

The system does not, preferably, start recording immediately once the "start recording" icon is activated, but rather a first countdown period may be initiated and presented to the user, with recording commencing after the first countdown period has finished. During the first countdown period the user may abort the process and avoid the recording being started.

The user may also stop recording at any time after initiating the recording start. Such a countdown provides the user with time to prepare to record their message and the first countdown period can be adjusted to a desired value between, for example, a range of 0-seconds.

Simultaneously with, or subsequent to, the initiation of the start of recording message content, the system may also initiate a second countdown period, which once expired forces recording to stop. Providing such a second countdown period and configuring the application to stop recording after a predetermined time ensures that messages cannot exceed a predetermined size, ensuring that messages keep to manageable data sizes.

The second countdown period may be set to any predetermined length of time, such as, for example, a period between 30 seconds and 2 minutes. The second countdown period, which sets the maximum message duration, may be adjusted and managed centrally on the server by a system administrator.

The system may provide to the user a number of internal controls accessible through an interface presented to the user by the application running on their user device, or accessible over the internet by the user device. The user may be presented with icons or user controls for adjusting parameters of the video or audio capture and playback. The controls that may be provided are variable and subject to parameter limits available in the development environment and the user device employed.

The user may be provided with controls to adjust the screen size of the video window that shows the images being captured by the video capture device or messages being played back. The video window screen size may be determined by the number of pixels, for example 480x240 pixels and the user may be presented with controls to vary the screen size between a minimum and maximum size, either continuously or in predetermined steps of video screen size.

The user may be presented with controls to vary the number of frames per second captured by the video capture device, from a minimum value to a maximum value (for example 30 frames per second).

The user may be presented with controls to vary the stream quality to of from the streaming media server. The stream quality is determined by a variable within the media server (such as a flash media server) environment ensuring that even with a slow connection, the required video or visual data is passed to the server, even if this could result in degradation of the video/audio. The stream quality may include variables such as the level of compression applied to a stream from the media server, and/or the maximum bandwidth the streaming media server may use. A single control may be provided to control both of these parameters, or separate controls could be provided. Where a single control is provided the stream quality may be shown as a % from a minimum value to a maximum of 100%.

Preferably, in response to the initiation of a recording, in response to the initiation of the first countdown period, or in response to the "record" icon being activated, the system running the application disables one or more, and preferably all, of the interface controls, the system being configured to automatically deactivate one or more of the internal controls such that the user cannot adjust these during recording. Adjustments made during the recording process can complicate the data contained within the message, rather than retaining the integrity of a quality transmission being optimised automatically by the system during the transmission stage. If there are too many setting changes within the message, the optimisation will be working unnecessarily. Using the system to automatically disable the internal controls ensures any adjustments to settings are made prior to the recording being started. Disabling some or all internal controls can also ensure that the user cannot interfere with processes that might involve calls to the system where a high level of security is maintained.

When recording of a message begins, a file is created in a memory 108 located within the server 106, and the file is updated as the recorded media is streamed to the server The recording file is located in the "sent" folder 43 which, since it can contain messages that may or may not have actually been sent to users, may instead be labelled the "recorded" folder. Once recording finishes, either by the recording timer elapsing, or the user activating a stop button at step 25, the server closes the recording file and makes it available to the user-Access to the file by users is only possible once it has been closed by the server. This avoids the situation whereby, in embodiments in which a user is able to send a message whilst recording, the recipient would be able to see the unfinished recorded message up to the point at which the user has recorded. Optionally, the system may also create an attachment folder on the server as soon as recording of the multimedia message finishes, allowing users to upload attachments to their message, such as documents, files or other multimedia content. When the system finishes recording a message, a still image taken from the recorded message is preferably displayed to the user, which provides the user with an indication of the content of the message for later reference, and the system alerts the user that the file is ready to be sent.

Embodiments of the invention may be implemented using various streaming media server platforms and programs. A media server program operates on the server computer 106 and provides the framework for receiving and distributing video messages. User devices A and B operate application software, or an "application", which allows the user to interact with the server program. The application executed on the local user device may be known as a client.

Examples of streaming media servers, or streaming media server programs, that may be used as a framework for embodiments of the invention are media servers such as the Flash Media Server (FMS), Wowza Media Server and the RedS Media Server, which use streaming protocols including RTSP, RIMP and RTMPE, and which are media servers capable of streaming media content to and/or from a recipient device. In the media server, a web server delivers the client application to the user device using HTTP, which allows the client to create a socket connection to a media server. Communication between the media server and client may be performed using Real Time Messaging Protocol (RTMP)I a TCP based transport layer protocol, or any other suitable protocols such as those mentioned above.

The basic operation of the system requires the recording and simultaneous encoding of a multimedia/visual message into suitable formats; the transfer of the content to the server, according to a streaming protocol, for encoding and storage; and the subsequent distribution of the content to a recipient party using the streaming protocol.

As the user records their multimedia message both the visual and audio components are converted, at the server, into respective encoded formats for optimisation for streaming such a5MPEG-2/MPEG-41MP4 for video and MP3 for audio, for example. As the visual message is produced it is streamed, or continuously sent, to the server using the streaming protocol, where it is assembled into an encoded message file.

Figure 3 shows the logical folder structure used at the server to store the multimedia messages. Within a master folder 41 there is provided a distinct folder for each individual user. Only four users are shown in Figure 3 but clearly there could be more, or fewer, users. Each personal user folder includes certain subfolders. A single example is shown for user 2's folder 42. The subfolders may include a sent (or recorded) folder 43, a received folder 44, a conversation folder 45 and a temporary folder 48. The term "folder" is intended to refer to the typical use within computer operating systems, referring to a logical construct with which files are associated for grouping and storing. The folders are directories that contain, logically, the files stored within them, but may not correspond to predefined sections or segments of physical memory.

As a message is recorded by the user, the encoded video and audio message is stored within the "sent" folder until recording finishes and the message file is closed. The complete message file is thus stored in the sent message subfolder of that user. When it is said that a message or file is stored in a particular folder, it is meant that the message is stored in server memory and associated with a particular folder, such as by using appropriate metadata, such that the message can be accessed by viewing or entering a folder in the way commonly used in computer operating systems. Folders represent the logical location of files within the system memory.

Once the server has closed the message, such that the message is finalised, the user can access said message from the sent folder on the server. If the user chooses to play back the message and preview it before sending, the message is streamed from the server back to the user. The message is streamed back to the user using the RTMP protocol or similar, and is handled within the application running on, or being accessed by, the user's communication device. Because the message is streamed directly to the application operating on the user device 101 from the media server, the user does not need to store the recorded message locally in order to preview it, neither do they need to download the message to a temporary folder in, for example, an internet browser.

Once the user has recorded a message, optionally first reviews it, and then decides to send it, the message can be sent to one or more other users. Figure 4 shows an example of the processes involved in sending a message to another user. Starting at step 51, the message to be sent has already been recorded in the manner described above. The user then selects a recipient, preferably by clicking on an icon representative of the desired recipient, using an interface device, and manipulating the icon by dragging it over to the same area of the screen as occupied by the preview screen used by the user to record and preview their video message.

Upon "dropping" the icon into that region of the screen, preferably by releasing a button on the interface device, or similar, the system initiates the sending process. The system first performs, at step 1. a check to ensure that the user has correctly selected a message. This happens whenever a user ends the recording of a visual message or plays back a visual message. If no message is selected, then no message wilt be transmitted when the user performs the steps needed to implement message sending, and instead the user will invoke another function of the system, for example initiating a live visual communication with the selected user.

Further checks may then be applied, and relate to additional functionality described below, particularly in relation to conversations between users and sending messages to a group of users. A check may be performed at step 3 to determine whether the message to be sent is a reply to a previous message-A subsequent check is performed at step 4, if the message is designated as a reply, to determine whether the contact to which the user is replying to is the author of the original message to which a reply was created. An optional check may be performed to determine whether the previous message, to which the message to be sent is a response, was contained in, or played back from, a conversation folder-At step 5 a check may be performed to determine whether the user has decided to send the message to a group of users, as wilt be described in more detail below. At step 6

S

a check is performed to determine whether the message is a reply to a message that is part of a conversation, being an exchange of messages.

Once the system determines that the message is ready to be sent to another user, the message program executing on the server proceeds to copy the message data, containing the audio and visual data, from the "sent" folder of the sending party to the "received" folder of the recipient party. "Copying" of the file is intended to refer to the term commonly used in operating systems wherein a physical and distinct copy of the message data is created and stored in the server memory and logically linked with the incoming messages folder of the recipient party. The memory, or store, or storage device on which the message is stored is a hard disk drive or similar type of permanent storage rather than temporary storage such as RAM. The copy occupies a different physical and logical portion of memory to the original, occupying a different segment of, or collection of bits within, the memory. In other words, a clone is made of the original message and the clone is then associated with the relevant folder of the recipient party. For example, if a message were generated having a size of 1 MB, then the storage requirement for that file, in order to send the message to a single other user, would be 2MB. This can be contrasted to other arrangements that do not copy messages, and which may be used in other embodiments of the invention, such as a system in which the message data is stored in a single location, and pointers are used to reference to that information. Rather than providing a single message file having multiple entry points, each user that receives or sends a message stores a physical copy of that message within their personal folder space.

Messages are physicaSly copied into both the sender's and recipient's folders to ensure that each user can access the files with equal speed (subject to, for example, the individual users situation in relation to device capability, internet connection type and speed); each user will be playing back their own message rather than having multiple users playing back the same message, which would result in slowdowns on playback. Having a physical copy of the message for each user ensures that each user is playing their own copy, avoiding concurrent playback of a single message copy. When the system is scaled to multiple users, the speed of the system does not suffer, as may be the case with typical streaming arrangements, because a single user is only ever accessing a single physical copy of the file. Therefore, the speed issues associated with the multiple users attempting to stream a common file are not experienced.

As an example, in which it is assumed that user A has already recorded a message "MSG-X". user A sends MSG-X to user B. The system copies MSG-X within user B incoming folder. User B plays back MSG-X from his incoming messages folder and user A plays back MSG-X from his recorded messages folder. In effect, both users view the same message, but access files in different folders on the media server(s) thereby each viewing a different instance of the message. User A is not slowing down user B's playback because user A is watching their own personal copy of the message. In addition, user B could send MSG-X to user C who could then watch the message as well. This would not affect playback speed because, again, user C is watching a distinct copy of the message.

User A may then decide to delete MSG-X without affecting user B or C's incoming message folder. This is also true for messages within a conversation, as described below, where files are also copied within the conversation folder, giving the user more flexibility allowing them to decide whether to, for example, delete a message from the conversation folder or remove the original message that subsequently became part of the conversation.

It should be noted that as the message is copied from user A's sent folder to user B's received folder the file name of the message is preferably changed to indicate that the message is unread by user B. It should be noted that there may be circumstances in which it would be desirable to use a mixture of both the method of storing separate copies or clones for each user and having referenced files, such as when a large number of users are taking part in a conversation involving the same messages. For example, if the number of users receiving a particular message exceeds a predetermined threshold amount, the storage method may switch to storing one or more copies of the message that are referenced by multiple users in order to play the message back. The referencing of a file may be performed in any manner known in the art.

The system does not simply rely on a database or table of recorded messages when recalling messages for playback because that could also open up the system to potential attacks. Instead, each time a user requires a list of messages, such as all recorded messages, or all messages received from a particular user (e.g. the user clicks on a contact's thumbnail), the media server sends back to the user a list of messages (recorded files) present on the server, that corresponds to the selected user or other selected criteria.

Thus there are no references' to the messages/containing folder stored on the system.

The list of messages is created each time the user system requests the list, ensuring that no traces are left behind of the user's action and there are no references to the message.

The effect is that the user gains a new access to their folders on each entry to the system meaning that rogue users cannot follow the previous track of entry to the system to gain access another user's folders: This is a security feature to avoid instances of illegal or uninvited intrusion of messages by users on other users' folders or messages.

Once a user has sent a new multimedia message to the desired recipient, an indicator is activated in the recipient's user interface to inform them that they have a message waiting to be viewed. This notification is indicative of the fact that a message has been successfully copied into the "received" folder of the recipient. The notification message may be implemented within the media server environment based on existing functionality.

Prior to the alert message being activated on the recipient client the server may perform a series of checks. In particular, the server may check to ensure that the recipient has the required folders already present within their folder structure. If the recipient does not have the necessary folder structure it may be that the user is not yet set up on the communication system and a warning may be sent to the sender. Only if the message file is correctly copied to the relevant folder in the recipient's folder space will the indicator to the recipient be triggered.

The recipient may be alerted to the presence of a new message by audio and/or visual signals such as by increasing a counter on or next to an icon representative of the sending party. By activating or clicking the sending party icon the user can initiate viewing of the message, which streams the message from the "received" folder 44 of the recipient user, streaming the physical copy of the message that was placed in their received folder from the "sent" folder 43 of the sending party. The message is streamed in encoded, and preferably compressed, form to the recipient's communication device for viewing by the recipient. Once the message has been viewed, either in its entirety or a predetermined proportion or amount thereof, a data field within the message file name is changed to indicate that the message has been read.

A multimedia message will preferably comprise message data containing several fixed core components and a number of variables. In particular, the message data may comprise a number of different data fields including the unique user ID of the message creator, the message title as created by the user at message creation, the creation date of the message preferably using system time configuration set to a system clock, a read/unread tag and a conversation tag. Preferably, this message data is associated with the message by being incorporated into the file name used to identify the message. This may be achieved by structuring the filename into a plurality of data fields, each one being separated by a field separator such as the symbol "..." (underscore), being a symbol that the system is configured to recognise as a field separator. In addition to message data contained within the title, the multimedia message further comprises the actual message data (i.e. the video and audio data), and may also include other metadata as described below. The overall structure of the message containing this data ensures that each message is unique and can be universally tracked within the system. This is primarily to ensure that the system delivers highest levels of security and that user experiences are optimised.

The user ID, message title and creation date fields may be fixed components of a message. The read/unread tag and conversation tag fields are variable elements that may be subsequently altered as the message is sent between users. The filename variable elements are determined by activity subsequent to the creation of the original message and relating to the determination of a message as a reply, which for the purposes of example are labelled as "r", and a conversation which for the purposes for example are labelled as "c", and are created by the system only after the subsequent action influences the status of the original message.

The read/unread tag indicates whether the message has been viewed by the recipient and is updated by the server(s) when the recipient finishes viewing a message or a portion thereof. The conversation tag indicates whether a message should be treated according to a particular set of conversation" rules and is described in more detail below. The conversation tag can be set to no value (empty) indicating that a message is not part of a conversation, a first value, such as "r", indicating that a message is a reply to a previous message and therefore part of a conversation, and a second value, such as "C, indicating that the message is part of a conversation and that the message was the originator of the conversation.

Whilst the filename defines categorisation of the message as, for example, a single sent message, a reply or part of a conversation, additional metadata contained within the message file determines how the message identifies with and relates to other messages in the system. It is the metadata that will ensure that a message (M802) in reply to an earlier message (MSG1) will identify the MSG1 and the related filename information to ensure that the messages are assigned to their correct positions within the system, for example, to the respective conversation folders.

A particular manner in which messages may be handled is now described in relation to a "conversation" involving in an exchange of two or more messages between users. As with the system design overall, the system design for conducting and managing a conversation is specifically designed to replicate human interaction in visual and verbal communication.

In brief, a user may record a message and initiate the sending process to another user.

The system then checks if a new conversation has been created by this message being sent, or if the message is to be added to an existing conversation. In the case of a new conversation, the system automatically starts a new conversation. This involves creating, at the server, two new folders within the "conversation" folder of both users (the sender of the message and the recipient). The server then copies the message recorded by the sender into the newly created conversation folders. The messages are renamed accordingly in the manner described above/below to identify them as being part of a conversation. The system also copies the message into the "received" folder of the recipient and, in doing so, renames the message accordingly to identify it as being part of a conversation. The server also copies the original message, the message to which a reply was generated, into the conversation folders previously created for both users. The server renames the original message in the recipient's "received" folder, and in the sender's "sent" folder to identify it as being part of a conversation.

An example will now be given in which user A has sent a message, MSG1, to user B. User B then replies to MSG1 by sending MSG2 to user A, initiating a conversation.

Referring to Figure 5, the conversation process begins at step 61, at which the recipient (user B) of a message, MSG1, (from user A) sent in the manner described above, has played back a message and is now replying to it with MSG2. The user, user B, selects the option to reply to MSG1 preferably by clicking on a "reply" icon at step 62. The "reply" button may not appear if the user is playing back a message he/she recorded. Selecting the reply option at step 62 may have a similar effect of the user clicking on the "record" icon at step 22 of Figure 2, as indicated by step 1 of Figure 5, in that the message record procedure is then activated to record MSG2. This procedure is not repeated in Figure 5 for clarity purposes, and may omit steps such as providing an input for a title or other data as shown in Figure 2, since the title used for MSG1 may be copied.

In addition to the normal procedure of recording a message, the system performs a check for metadata contained within the message to which a reply is being generated, i.e. MSG1.

This check may be performed at any time after the receipt of MSG1 by the recipient.

The system checks the metadata fields of MSG1. If there is no metadata present this indicates that MSG1 is not part of a conversation. At the point of recording a reply, metadata is created, based on properties of MSG1, and inserted into MSG2 preferably during the reply recording process. In particular, the metadata may include one or more of the user ID, the title and the creation date found in the message file name of MSG1. In the present example there will be no rnetadata present in MSG1, since no conversation is ongoing at this point. If there were metadata present in MSG1 then this would indicate that MSGI is part of a conversation and the metadata of MSG1 is copied into MSG2. In either case, the result of step 1 of Figure 5 is that a message, MSG2, containing metadata indicative of an earlier message, is ready to be sent by user B as a reply to user A's message.

Once the reply message has been recorded user B then proceeds in the same manner as outlined above to send a message, by selecting the recipient(s) of the message, at step 63.

A similar process is followed as outlined in Figure 4, commencing at step 1 of this figure. In addition to the checks to determine whether a message has correctly been selected, a check may be performed at step 3 to determine whether the message to be sent is a reply to a previous message. This is a check to determine whether the message was recorded by selecting the "record" button, or by selecting the "reply" button in response to an earlier message. If the message was generated as a reply, a "reply" variable is set indicative of this fact. In the present example the message, MSG2, was generated by selecting the reply" option, and so the system would detect the "reply" variable indicative of this.

A subsequent check is performed at step 4 of Figure 4, if the message is designated as a reply, to determine whether the contact to which the user is replying to is the author of the original message to which a reply was created. If there is a match then this indicates to the system that the message may be part of an existing or new conversation. In this example, user A composed MSG1, to which MSG2 is a reply, and so there is a match. If there were no match, or only some of the selected users matched, the sending party may be given one

S

or more options to involve the non-matching parties in a new conversation involving some or all of the messages within the conversation to this point.

Skipping step 5, which relates to a group send functionality described below, the system checks, at step 6, whether the user is replying to a message that is part of an existing conversation. This is performed by comparing a property of the message against a property of the previous message, and in particular checking metadata within the message to be sent against the filename, or a portion thereof, of the previous message. Since the metadata within the message to be sent will be indicative of an earlier message, there are two possibilities, Either the metadata will match or correspond to the filename of the previous message, indicating that a new conversation has begun, or the metadata will not match the filename of the previous message, indicating that an existing conversation is being continued.

If the system determines, at step 6 of Figure 4, that a message is not a reply to a message that is part of an existing conversation then a new conversation needs to be created, along with the associated folders. This is the case with the present example in which user B is replying to user A with MSG2. The metadata within MSG2 contains parameters from the filename of MSG1, and so there is a match. Therefore, the system proceeds to step 9 of Figure 4, going to step 3 of Figure 5. In addition to this, the additional steps of Figure 4, from step 7, are also performed.

At step 3 of Figure 5, the server(s) create(s) a new conversation folder within the conversations folder 45, shown in Figure 3 within the folder structure of each user. This folder is created for each user, such that each user has a new conversation folder within their personal conversations folder 45. The newy created conversation folder is named based on data contained within the metadata of the reply message, MSG 2, which corresponds to data contained within the message filename of the original message, MSG1, within the conversation. That is, the conversation folder is named based upon data contained, ultimately, in the filename of the original message from user A to user B. In particular, the folder name may include, referring to Figure 3, one or more fixed fields from the identification field, the title field and the security data, and in particular the creation date. In this way, the initiator of the conversation can be tracked because the conversation folder created adopts the name of the first message in the conversation. Creating unique folders used to contain messages related to a particular conversation, in each user's personal folder space, allows each user participating in the conversation to handle the messages of the conversation independently from other users. For example, messages can be removed from one user's conversation folder without compromising any messages in the other user's conversation folder, allowing both a high level of security and ensuring that conversations can be tracked within the system.

Having created the new conversation folders the system copies the message being sent (the reply message MSG2) into the conversation folders. In certain embodiments copies, or clones, of the message are placed in each conversation folder, each copy occupying a portion of data in the server memory, in the manner described above. In other embodiments other manners of referencing commonly stored messages may be used.

The reply message, MSG2, is initially composed in the sent" folder 43 of the sending party user B, in the same manner as outlined for recording a typical message in Figure 2, and is also copied into the "received" folder 44 of the recipient user A, in the same manner as for a typical message when sent in the manner shown in Figure 4. In addition, the reply message is copied into the conversation folder of each user at step 4 of Figure 5. The original reply message file from the "sent" folder of user B is renamed to indicate that it is a reply message at step 5A. The reply message copied into the "received" folder 44 of the recipient party user A is also renamed to indicate that it is a reply message at step SB, although this may be achieved equally by copying across the message from the sent' folder of user B after the file is renamed. The reply message in the conversation folder of both user A and user B may also be renamed to indicate that they are reply messages. As a result of these steps, the creator of the reply message MSG2. user B, has two distinct copies of MSG2 within their user folder, one in the sent message folder and one in the conversations folder. Likewise, the recipient of the reply message, user A, also has two distinct copies of MSG2, one in their received folder and one in the conversations folder.

The server makes a clone of user A's original message MSG1, to which the reply was generated by user B, and places it within the conversation folder of each user as mentioned above. At the same time, the "conversation" field within the filename of the original message is changed from no value (i.e. empty) to a second value indicative of the fact that the message is part of the conversation. Preferably this is achieved by inserting a tag, for the purposes of example to indicate a conversation, "C, within the "conversation" field of the filename. This maintains the conversation structure and ensures that each user has the ability to handle the messages within a conversation independently. Users are thus able to delete a message within a conversation folder, or from within their incoming/sent folder without affecting either the conversation or the messages of another user. In addition, the original message, to which the user B replied, is amended within the user B "received" folder by amending the metadata to insert the value indicative of the fact that it is now part of a conversation.

Although a specific order is shown in Figures 4 and 5, it should be appreciated that this is not a limitation, and steps may be performed in a different order. For example, steps SA and 5B may be performed before or after steps 6A, 68 and 7. The only order that is of importance is that the conversation folders are created before files are inserted into them.

It can be seen from the example above that a first and second conversation label (which for the purposes of example are labelled as "c' and "r") and message metadata can be used to designate a first message as the source of a conversation and the subsequent messages as replies within a particular conversation identified by the source message.

The system, when determining where to store a message, may first look at the conversation tag field within the message filename. This indicates whether a message is part of a conversation or not. If the conversation tag field is set to a predetermined value then the system then checks the metadata within the message. The metadata, for messages forming part of a conversation, contains data indicative of the original message within that conversation, and preferably at least a portion of the filename of the orignaI message. The conversation folders for participating members are, as mentioned above, named after the filename of the original message in the conversation. Therefore, the system need only match the metadata within a reply message to the fiLename of the conversation folder in order to determine where the message should be located.

The message structure allows the additional rnetadata. as mentioned above, to be contained within the message file itself, at the file level. When a conversation begins with a reply message generated in response to another message, metadata is inserted into the reply message indicative of data related to the source message. In particular, this may include the user ID of the creator of the source message, the source message title and the creation date of the source message, These fields may be extracted from the source message filename. When the system performs checks on sending a message it is determined whether the message is a reply to another message, indicating it is part of a conversation thread. If this is determined to be the case the system extracts the metadata and determines to which conversation folders the message should be directed, since the metadata contains data indicative of the source message, which is also the same data used to generate the folder name for the conversation. It should be noted that this type of metadata would not be present in a message unless it is a reply to an earlier message.

The source message would contain this data in the message filename, but not within the

metadata fields mentioned above.

The system first checks that the user is replying to a message. If so, there is a further check to determine whether there is a match between the contact the user is replying to and the author of the original message. If there is a match, the system is alerted to start a new conversation. To start a new conversation the system needs to know with whom the conversation has to take place. To do so, metadata is added to the reply message, which creates a unique ID to which the system will then refer when dealing with conversations.

If metadata is already present in the message, it will be treated differently from the system that now knows that a conversation started already. This method ensures that each conversation is uniquely related to the users that are pad of the conversation. Furthermore, a folder structure based on this unique ID is also created for each user in a conversation, so as to ensure uniqueness and increase security at servers' level. Server usage may be reduced by checking if metadata is already present in the message, which rninimises the number of required calls to the server.

If the system determines, at step 6 of Figure 4, that a message is a response to a message within an existing conversation then steps 4, 5A and 5B of Figure 5 can be followed before skipping to stepS. In other words the conversation folders already exist as they would have been previously created. As a result, the reply message needs to be copied into the conversation folders of all users and the reply copies renamed or tagged as replies.

Figure 6 illustrates where copies of messages are stored for each user taking part in a conversation, as well as which messages are renamed or altered during the process.

Starting at step 71 a first message, "MSG1", is sent from user A to user B before a conversation begins. Figure 6 illustrates what occurs within the server during the procedure. Each arrow from a message to a folder indicates that a copy of the file, occupying its own portion of server memory, has been created. Firstly, MSG1, which is generated within the "sent" folder of user A, is copied to the "received" folder of user B. User B decides to reply to MSG1, and records "MSG2". The reply message "MSG2" is created in the "sent" folder of user S and copied to the relevant incoming and conversation folders. MSG2 is labelled "r" as shown in Figure 6, indicating that it is a reply and causing the sever to generate, in the file space of each of user A and B, a conversation folder labelled "MSG1", this being the original message of the conversation. The folder label preferably incorporates an identifier, such as the title of MSG1, or the creation date and optionally the unique user reference or the message creator, or a combination of all three.

MSG2 copies are then placed into the received folder and conversation "MSGl" folder of user A, and into the conversation "MSG1" folder of user B at step 72a. In addition, original message MSG1 is re-labelled to indicate that it is now part of a conversation by changing the relevant filename field "conversation" tag to the value "C for the purposes of example.

This can be achieved by changing the copies in each of user A's sent folder and user B's received folder, or by changing one copy and inserting copies of this into these folders to replace the unlabelled MSG1. Relabelled MSG1 copies are also inserted into the MSG1 conversation folders of users A and B. Figure 7 shows, in a similar manner to Figure 6, how copies of a message are stored for each user when a message is replied to as part of an ongoing conversation. In particular, a third message "MSG3" is generated by user A, within their "sent" folder, in response to MSG2 from user B. In a similar manner to MSG2, MSG3 is situated in user A's sent folder and is copied into the conversation folder "MSG1" of user A. In addition, the MSG3 is copied into the received folder and into the conversation folder "MSG1" of user B. It should be noted that the above has been described with a message being created within the users respective "sent" folder. This is the preferred method but it is, however, possible that the message is created in a temporary folder, such as temporary folder 46 before being copied into the "sent" folder for recorded and sent messages-It is also possible that the temporary folder is used in the operation of messages within a group.

Although conversations may take place between two users, it is possible to involve further users in message exchanges.

A user (user B) may wish to forward on a message received from another user (user A) to a third user (user C). In this case, step 71 of Figure 6 has already occurred. User B views the message, MSG1, from user A and decides to forward it to user C. This may be achieved by dragging an icon representative of user C over the viewing panel just used to view MSG1, for example. The system server then determines whether MSG1 is part of a conversation by analysing or checking the conversation tag field, and performing a check for relevant metadata. At step 71 of Figure 6 the message MSG1 is not yet part of a conversation and so the server simply undertakes the same procedure shown at step 71, with the message instead being sent from user B to user C. Alternatively, user B may wish to include user C in a conversation between users A and B. As mentioned above, when user B forwards a message to user C the server performs a check to determine whether the message, say MSG3, is part of a conversation. In this instance, referring to the example of Figure 7, MSG3 is part of a conversation denoted by the "r" label in the conversation tag in the filename, and by virtue of the fact that it would include metadata representative of the first message of the conversation, MSGI, as mentioned above. Upon determining that MSG3 is already part of a conversation, the system presents user B with two or more options. User B can forward the message to user C and involve user C in the conversation between users A and B. This may include giving user C access to all previous messages in the conversation by creating a conversation folder within user C's file space, labelled in this example as "MSGl" and copying across all messages within the conversation. Alternatively, user C may only be given access to messages issued after the message forwarded to user C to join them with the conversation. Another option that can be provided is to initiate a new conversation between user B and user C, to which user A has no access. In this case, only messages recorded by user B may be copied into the conversation folder of user C. Embodiments of the invention may provide the feature of enabling users to create a group of users to which messages can be sent. The user may have the option to assign users to a group, or delete users from a group, or subsequently change a group title at any time by enacting respective system command protocols as previously described.

Specifically, the user may add users to a group by dragging and dropping an icon indicative of a given user into a panel or region of a display, created to accommodate the group members. A user may be removed from a group by moving their icon from the region of the display accommodating the group members. Users invited into a group, for the purposes of example, users B, C, up to n users, may at any time create and send messages to the members of that group.

If replying to a message from a user in a group of which they are a part, each user has the choice of replying to only the sender of the message or to reply to the original message whilst including all members of the group in the reply. In this case, the system protocols with regard to sending video messages including, for example, sending messages, replying to messages, creating conversations between users, may be replicated for each of the users in the group.

Figure 8 shows the basic steps involved in such a process, in which it is assumed that a user has recorded a message, in the same manner as described above, that is ready to send to a group. Rather than selecting a single user's icon and dragging this over the preview panel the user selects a "groups" icon at step 82 causing the system to present to the user icons representative of one or more groups of users. The user may then select one or more of the group icons and drag these over the preview panel. At step 2 of Figure 8 the system copies the file from the message creator's "sent" folder into the "received" folder of each user within the selected group and alerts the group members of a new message. A check may also be performed to ensure that the messages were sent, or copied, correctly.

Referring back to Figure 4, a check is performed during the normal message sending process, at step 5, as to whether the message is being sent to a group of users. This can be identified by virtue of the fact that the user has selected an icon indicative of a group at step 52, rather than an icon indicative of a single user. The message may or may not be part of a conversation and may therefore be treated in the same manner as described above, involving a group of users rather than a single user.

Embodiments of the invention also include the feature to enable users to further replicate human interaction by enabling any user to create a world' into which they may send a message at any time. All messages described in the previous sections are, unless specifically noted otherwise, secure, private and confidential to the users to whom messages have been specifically identified and sent.

This additional feature of the system enables any system user to record and send a message to a publicly accessible folder or user group category called system "worlds". A user may, in a process similar to the creation of groups of users within the system, create a category of recipient labelled a "world" and assign a title as determined by the user at the time of creation, or subsequently changed by the creator.

Any user of the system may have automatic access to this category of message assigned as a "world" message. Any user may send any message, new or otherwise to a "world" either in existence or of their creation, at any time.

At the point at which a user sends a message to a world" the system checks the message file structure and metadata and removes the required filename tags and metadata that forms the critical element of the message to enable replies and conversations. This means that a user may not reply or start a conversation with a user who has created and sent a message to a "world" that they, or any other user, have created.

The "world" message file space can be provided by creating a folder in the creating user's personal folder space, such as within folder 37 of Figure 3, and providing access to all users of the system. Alternatively, the folder may be created in another location within server memory. For example, a "worlds" folder may be provided within a dedicated folder space contained within the master folder 41, with each "world" being provided a dedicated sub-folder containing messages sent to the "world". The folder, or a sub-folder thereof, corresponds to the message file space of the world, and users are granted access to the messages contained within the world folder on a read-only basis. Preferably only the creator of the world and system administrators have access to delete messages.

Figure 9 shows the processes involved in sending a message to a world for viewing by multiple users. The user has a message ready to send to the world folder for viewing by other users. This message may have been specifically recorded for posting to a world, or it may alternatively have been taken from a conversation between two or more users or be a message that was recently viewed by the user. In order to access the "worlds" functionality the user accesses the corresponding icon on the screen causing the system to recall a list or set of worlds from the server and display these to the user. The system calls a server side script to populate the "worlds" panel with an updated list of worlds. To ensure that an updated list of worlds is available to the user, the list is refreshed each time this is shown to the user. The user may then, at step 93, select a world icon to which to send the message, preferably by dragging the world icon over the preview panel of the message to be sent.

The sending process involves a similar process to that described above, in that a copy or clone of the message is made from the message in the user's file space and inserted into the folder used to contain the world messages. At step 3 of Figure 9, a check is performed to determine whether there is a conversation tag c' and whether there is any metadata contained within the message, as would be the case if the message were part of a conversation as described above, If this is the case, the metadata is removed from the message, preferably by calling a script to set all possible values to "zero". Metadata is removed from messages to avoid situations where the information attached to a conversation might be used by users that are not part of the conversation. In addition, any conversation tags within the file name may be removed. This restores the message to its original state (i.e. same as a MSG1) such that it won't be seen as being part of a conversation.

Whilst embodiments of the invention have been described in which message copies are provided in personal folders relating to each users, it is possible to implement embodiments of the invention without this requirement. For example, the conversation logic may be implemented in other embodiments by storing a central copy of the message and providing each user with a pointer to the message, with message data, for example including filename and metadata, being provided within the pointer, or associated therewith, to indicate whether the message has been read by a user and whether it is labelled as being part of a conversation.

Embodiments of the invention provide a system that enables software and hardware to process data related to images, audio and associated or supplementary information performing a number of complex tasks. These tasks involve the recording, storing, transmission and re-transmission of visual images in static and moving representations together with or supplemented by additional information and files in various formats. The embodiments described herein are preferably not reliant on an email server and do not use email as a carrier for the attachment or transfer of the video/visual communications.

Embodiments of the invention have been described in relation to a streaming media server.

This is intended to refer to a server program, operating on server hardware, for the purposes of receiving media content such as audio and video from user devices and distributing the content to user devices by streaming over the internet or any other appropriate type of network. The streaming media server operates on server hardware including a network connection, one or more processors and an internal or external memory. Examples of streaming media servers include Flash Media Server (FMS), Wowza Media Server and the Reds Media Server. Multiple server programs operating on multiple distinct hardware apparatus may be used in place of a single server program and apparatus should additional resources be required.

Embodiments have been described in which a user device is used to record or view a message. User devices are communication devices and may include one or more of a computer, a laptop, a tablet computer, a smartphone, a PDA, a computer gaming console, and any other type of device having an appropriate internet or network connection for sending and receiving data from a remote sewer. The video capture device and audio capture device may be integral to the user device or may be coupled to it by a suitable connection, including wired or wireless arrangements. 3D

Claims (1)

1. <claim-text>CLAIMS1. A method for sending a multimedia message, comprising video and audio, from a remotely located first user to a remotely located second user, the method comprising, at a streaming media server: -receiving a first multimedia message from a first user device; -storing, in memory coupled to the server, the first multimedia message in a folder associated with the first user, the first multimedia message occupying a first portion of memory; -storing, in memory coupled to the server, a copy of the first multimedia message in a folder associated with the second user, the copy of the first multimedia message occupying a second portion of memory different to the first portion; and -streaming the copy of the first multimedia message to a second user device.</claim-text> <claim-text>2. The method according to claim 1, the method further comprising: -receiving a second multimedia message from the second user device, the second message being identified as a reply to the first message; -storing, in memory coupled to the server, the second multimedia message in the folder associated with the second user; -creating, within the respective folders associated with the first and second users, a folder associated with the first message; -storing, in memory coupled to the server, a copy of the second message in each of the folder associated with the first user and the folders associated with the first message for both the first and second users, each copy occupying a different portion of memory: and -streaming a copy of the second message to the first user device.</claim-text> <claim-text>3. The method according to claim 2, the method further comprising, at the server: -generating respective copies of the first message and inserting a copy into each of the folders associated with the first message located in the first and second users' files respectively, each copy occupying a different portion of memory.</claim-text> <claim-text>4 The method according to claim 3 further comprising, at the server: -inserting, into each copy of the first message, data indicating that the first message is part of a conversation being an exchange of two or more messages between the first and second users.</claim-text> <claim-text>5. The method according to claim 4 wherein the data is inserted as a tag within the message file name.</claim-text> <claim-text>6. The method according to claim 2, 3, 4 or 5 wherein the second multimedia message from the second user device is identified as a reply to the first message by user input caused by the operator of the second user device selecting an option to reply to the first message.</claim-text> <claim-text>7. The method according to claim 6 further comprising the steps of: -checking, at the server, whether the second message is a reply to the first message; -checking, at the server, whether the second message contains metadata indicative of the file name of the first message; -wherein if the second message does not contain metadata indicative of the file name of the first message the method further comprises inserting, as metadata within the second message, data indicative of the file name of the first message; andI-wherein if the second message does contain rnetadata indicative of the file name of the first message the method further comprises inserting, as metadata within the second message, the metadata from the first message.</claim-text> <claim-text>8. The method according to claim 6 or 7 wherein the message file name comprises one or more of the message creator's user ID, a user defined title and the message creation date.</claim-text> <claim-text>9. A streaming media server configured to perform the methods of any of claims ito 8.</claim-text> <claim-text>10. A system for sending multimedia message, comprising video and audio, the system comprising: -a streaming media server according to claim 9; -a first user device comprising: -a processor arranged to receive as input from a device an audio and video signal; -an Internet connection for sending the received audio and video to the streaming media server; and -a second user device comprising: -an internet connection for receiving the captured audio and video from the streaming media server; and -a processor arranged to output the audio and video to an output device.ii. A method for exchanging multimedia messages between a first user and a second user, the method comprising, at a streaming media server: -receiving a first multimedia message from a first remote user device, storing it in memory coupled to the server and streaming the first message from the server to the second user device; -receiving a second message from a second remote user device; -checking, at the server, whether the second message is a reply to the first message; -checking, at the server, whether the first message contains metadata indicative of a previous message; -wherein if the first message does not contain metadata indicative of a previous message the method further comprises inserting, as metadata within the second message, data indicative of the first message.12. The method according to claim 11 wherein if the first message does contain metadata indicative of a previous message the method further comprises inserting, as metadata within the second message, the metadata from the first message.13. The method according to claim 11 or 12 wherein the second multimedia message from the second user device is identified as a reply to the first message by user input by the operator of the second user device selecting an option to reply to the first message.14. The method according to claim 11, 12 or 13 further comprising, at the server -inserting, into the first message and the second message, data indicating that the messages are part of a conversation, being an exchange of two or more messages between the first and second user& 15. The method according to claim 14 wherein the data is inserted as a tag within the message file names.1 6 The method according to any of claims 11 to 15 wherein the metadata within a message comprises at least a portion of the filename of a previous message.17. The method according to claim l6wherein the message file name comprises one or more of the message creator's user ID, a user defined title and the message creation date.18. The method according to any of claims Ii to 17 further comprising: -creating a folder in memory coupled to the server, in response to receiving the second message, the folder being associated with the first message; and -storing the first and second messages within the folder, or linking the first and second messages to the folder.19. The method according to claim 18 wherein a folder is created for each of a first user and a second user each associated respectively with the first and second user device.20. The method according to any of claims 11 to 19 further comprising the step of determining when a message is being made publicly accessible and, in response.removing the metadata indicative of a previous message.21. The method according to claim 20 wherein making the message publicly accessible involves storing it in a publicly accessible folder.22. A streaming media server configured to carry out the methods of any of claims 11 to 21.23. A system for sending multimedia message, comprising video and audio, the system comprising: -a streaming media server according to claim 22; -a first user device comprising: -a processor arranged to receive as input from a device an audio and video signal; -an internet connection for sending the received audio and video to the streaming media server; and -a second user device comprising: -an internet connection for receiving the captured audio and video from the streaming media server; and -a processor arranged to output the audio and video to an output device.24. A method for recording multimedia messages at a streaming media server, the method comprising: -providing a user device comprising: -a processor arranged to receive video from a video capture device; -an Internet connection for sending the received video to the streaming media server; -the user device being configured to control, in response to user input, one or more properties of the video received from the video capture device; -the method further comprising detecting when the user device is sending video to the streaming media server for recording at the streaming media server; and -deactivating user control of the one or more properties of the video when the user device is sending received video to the streaming media server for recording.25. A method for recording multimedia messages at a streaming media server, the method comprising: -configuring a user device, comprising a processor arranged to receive video from a video capture device and an internet connection for sending the received video to the streaming media server, to control, in response to user input, one or more properties of the video received from the video capture device; -detecting when the user device is sending video to the streaming media server for recording at the streaming media server and recording the received video at the streaming media server; and -controlling the user device to deactivate user control of the one or more properties of the video when recording the received video.26. A method according to claim 24 or 25 wherein the one or more properties of the video that may be controlled comprise one or more of the screen size of the video window showing the images being captured by the video capture device, the number of frames per second captured by the video capture device, and the stream quality.27. A method according to claim 26 wherein the stream quality includes the level of compression applied to a stream from the media server, and/or the maximum bandwidth the streaming media server may use.26. A method according to claim 24, 25 26 or 27 wherein a first predetermined countdown period is initiated prior to the user device sending video to the streaming media server, whereby recording of the video at the server commences after the first countdown period has finished.29. A method according to claim 26 wherein the first countdown period is displayed on a display to the user.30. A method according to claim 28 or 29 wherein the first countdown period can be adjusted to a desired value.31. A method according to any of claims 24 to 30 further comprising, upon initiation of the start of recording video at the server, initiating a second countdown period and upon expiry of the second countdown period ending the recording of video.32-A user device for streaming multimedia messages to a streaming media server, the user device comprising: -a processor arranged to receive video from a video capture device; -an internet connection for sending the received video to the streaming media server; -the user device being configured to: -control, in response to user input, one or more properties of the video received from the video capture device; -detect when the user device is sending video to the streaming media server for recording at the streaming media server; and -deactivate the user control of the one or more properties of the video when the user device is sending received video to the streaming media server for recording.33. A user device according to claim 32, or a streaming media server according to claim 9 or claim 22, further configured to undertake the methods of any one of claims 26 to 31.34. A computer program which when operated on a streaming media server causes it to carry out the method of any of claims ito 8 or 11 to 21 35. A computer program which when operated on a user device according to any of claims 32 or 33 causes it to carry out the method of any of claims 24 to 31.36. A method according to any of claims 1-8, 11-21 or 24-31 wherein the messages are sent to and/or from the server encoded according to RTSP, RTMP or RIMPE over the Internet.</claim-text>