Video image transfer system for mobile terminals

The present invention relates to a video image transfer system for mobile terminals for providing social networking services (SNS) with which the mobile terminals are compatible.

At present, services for downloading videos or sounds from contents holders that are being performed as part of SNS are targeted at users' computer terminals. In the past, download services of this type have not been provided to mobile terminals such as mobile phones and portable appliances, since they have low line bit rates and small storage capacities, having difficulties in allowing video data to undergo complex decoding process on the mobile terminals. The present applicant has already proposed an encoding and compressing technique as a video image encoding and compressing technique that is most suitable for mobile terminals such as compact size gaming machines and mobile phones, said encoding and compressing technique performing neither inter-frame difference encoding nor motion compensation, and therefore, being highly functional yet of low- load (WO 2004/070651 ) and called herein Mobiclip encoding.

The present invention aims at providing a video image transfer system for mobile terminals for SNS targeting mobile terminals, using a low-load encoding compression technique.

According to the present invention, there is provided a video image transfer system for mobile terminals comprising: a portal site equipped with a server having an encoder which compresses a received video data through a low-load encoding technique and a storage which stores the compressed video data; and a receiving mobile terminal which is capable of accessing said portal site and then downloading said compressed video data, said receiving terminal including a decoder capable of decoding the compressed video data thus downloaded.

The present invention enables the provision of services of downloading video images from portal site to mobile terminals, as well as services of transferring video images to the mobile terminals via portal site.

The invention is related to a video image transfer system for mobile terminals comprising a portal site equipped with a server having an encoder which compresses a received video data through a low-load encoding technique and a storage which stores the compressed video data and a receiving mobile terminal which is capable of accessing said portal site and then downloading said compressed video data, said receiving terminal including a decoder capable of decoding the compressed video data thus downloaded.

According to a particular embodiment, the video image transfer system further comprises a sending terminal which is capable of accessing said portal site and then uploading a video data onto said portal site.

According to a particular embodiment, said sending terminal is a terminal of a user who has an account issued by said portal site.

According to a particular embodiment, said portal site further comprises a private storage for storage of compressed video data addressed to a specific personal user and a public storage for storage of compressed video data which is/are made publicly available to an unspecified number of users. According to a particular embodiment, said portal site further comprises a data erasing means which erases the compressed video data stored in said storage(s) after a certain period of time.

According to a particular embodiment, said portal site further comprises a data erasing means which erases the compressed video data stored in said storage(s) following download statistics.

According to a particular embodiment, said portal site further comprises an aggregation service :

- a playlist management module to manage a list of links to available videos ; and

- an encoder intended to encode these available videos to fit the destination terminal constraints regarding videos play. According to a particular embodiment, said system comprises a user station from which the user can access and customize the aggregation service.

According to a particular embodiment, the playlist management module allows the user to store links to various kind of videos gathered by groups depending on the type of the video. According to a particular embodiment, the playlist management module allows the user to manage a list of registered destination terminals to access the service with the constraints associated to each terminal regarding videos play.

According to a particular embodiment, the playlist management module allows the user to set up an audience to each link to control who can access the video linked. According to a particular embodiment, the user can receive on the destination terminal a link from another user to add to his playlist.

According to a particular embodiment, the user can find on the destination terminal a link from a search motor to add to his playlist.

According to a particular embodiment, the encoder is located on the user station. According to a particular embodiment, an encoder on the portal server is used as a fallback when the encoder located in the user station cannot be used.

The characteristics of the invention will emerge more clearly from a reading of the following description of an example embodiment, the said description being produced with reference to the accompanying drawings, among which: Fig. 1 is a schematic drawing showing the general structure of the video image transfer system for mobile terminals for performing SNS according to one embodiment of the present invention.

Fig. 2 is a flow chart explaining overall operation in the video image transfer system for mobile terminals of Fig. 1.

Fig. 3 is a flow chart explaining in more detail an operation for processing the video data uploaded from the personal user's terminal at the portal site.

Fig. 4 is a flow chart explaining an operating procedure for a personal user to upload the video data. Fig. 5 is an explanatory drawing explaining the screen of a mobile phone of a personal user in the case of uploading in a private form.

Fig. 6 is a flow chart explaining an operating procedure for a personal user to download the video data.

Fig. 7 is an explanatory drawing explaining the screen of a mobile phone of a personal user in the case of downloading.

Fig. 8 is an explanatory diagram explaining the screen of the Mobiclip player built in the mobile terminal beforehand, such as a mobile phone.

Fig. 9 is an explanatory drawing explaining the screen of the mobile phone in the case that the category of the contents provided by the portal site is chosen. Fig. 10 is an explanatory drawing explaining the screen of the mobile phone in the case that the category of movie was chosen.

Fig. 11 is an explanatory drawing explaining the screen of the mobile phone in the case that the category of music was chosen.

Fig. 12 is an explanatory drawing explaining the screen of the mobile phone in the case that the category of Mobiclip was chosen.

Fig. 13 is a flow chart explaining an operating procedure for a corporate user to upload the video data.

Fig. 14 is a schematic of the architecture of an alternate embodiment of the invention. Fig. 15 is an explanatory drawing explaining the screen of the customization tool from the user station.

Fig. 16 is a flow chart of the operation of viewing a content from the user terminal.

In Fig. 1, numeral 10 designates a portal site, and 11 a mobile terminal or a computer terminal of a personal user who is to sign or has already signed an account contract with the portal site 10 and is going to upload a video image data. Numeral 12 designates a computer terminal of a corporate user that is to sign or has already signed a corporate account contract with the portal site 10, and numeral 13 a mobile terminal

of a personal user (recipient) who is to sign or has already signed a contract for SNS and is going to download the video data, respectively.

The portal site 10 is equipped with a server 10a having an encoder (Mobiclip encoder) which compresses the received video data with low-load encoding technique; and a private storage 1 Ob, a public storage 1 Oc and a corporate storage 1 Od, in addition to ordinary functional elements.

As shown in Fig. 2, the personal user's mobile terminal or computer terminal 11 first accesses the portal site 10 and connects therewith (Step Sl), and then subscribes an account contract which enables the uploading of video (including sound) data (Step S2), and thus a personal account (for example, δδδ@mobiclip-jp) is obtained (Step

S3).

Subsequently, the personal user's mobile terminal or computer terminal 11 chooses a form to upload the taken video image (including sounds), for example, and notifies it to the portal site 10 (Step S4). When uploading the video image in a private form to transfer it only to a specific user, the address of the recipient's address, more specifically a mail address or phone number of the receiving mobile terminal, is attached to the video image data, and then it is uploaded onto the portal site 10 (Step

S5). In the case of uploading the video image in a public form for an unspecified number of users to be able to download, a category corresponding to the video is chosen from a category list set up by the portal site 10, and then the video data is uploaded onto the portal site 10 (Step S6).

At the portal site 10, the uploaded video data is compressed by the Mobiclip encoder of the Server 10a (Step S7). If the compressed video data is in a private form, it is stored in the private storage 10b (Step S8). In that case, a mail or a SMS notifying that the video data is already on the site is sent to the recipient's address.

If the compressed video data is in a public form, the portal site 10 could determine whether there is a possibility that the video data may infringe on any copyright, and if it does, the compressed video data is discarded (Step S9), whereas if it does not, the compressed video data is sorted by category, and stored in the public storage 1 Oc (Step S 10).

On the other hand, the computer terminal 12 of the corporate user as a contents holder or the like, subscribes a corporate account contract with the portal site 10 in advance (Step SI l ), and uploads beforehand video or sound contents for the general public that are basically determined by the intent of the corporation, e.g., video or

sound data such as CMs, promotional music video clips, movie previews, etc. The video data thus uploaded are compressed by the Mobiclip encoder of the server 10a (Step S7), and then stored in the corporate storage 1Od (Step S 12).

The mobile terminal 13 of the personal user (recipient) receives from the portal site 10 a mail to the effect that the video data has arrived (Step S 13). If the recipient clicks on the mail, the access to the portal site 10 is made, so that the compressed video data addressed to the recipient and stored in the private storage 10b are downloaded (Step S 14). The downloaded compressed video data are decoded by the decoder (Mobiclip decoder) which decodes the data encoded by the low-load encoding technique provided in the mobile terminal 13, thus enabling the viewing and listening of the video image.

If a personal user who has signed the SNS contract desires to view either the public or corporate video image at the portal site 10, then he/she accesses the portal site 10 from the mobile terminal 13, and chooses a desired category, and thus the compressed video data stored in the public storage 1 Oc or the corporate storage 1 Od are downloaded (Step S 15). The compressed video data thus downloaded are decoded by the Mobiclip decoder that is incorporated beforehand in the mobile terminal 13 by a cell phone service contractor (carrier) etc, thus enabling the viewing and listening thereof. In the meantime, the portal site 10 erases the compressed video data stored in the private storage 10b a certain period of time after the recipient has downloaded the same (Step S 16), and it also erases the compressed video data stored in the public storage 10c a certain period of time after the data is uploaded (Step S 17). Alternatively the erasing can occur, following download statistics. For example, it can occur when no more download happen.

Fig. 3 is a flow chart illustrating in more detail the operation for handling the video data at the portal site 10 that has been uploaded from the personal user's terminal 11.

First, the video data uploaded from the personal user's mobile terminal or computer terminal 11 are received (Step S20), and then the received video data are transferred to the Mobiclip encoder (Step S21).

In the Mobiclip encoder, the video data are encoded and compressed using the encoding technique which is substantially low-load compared to MPEG encoding (Step S22).

After the encoding compression of the video image data by the Mobiclip encoder at Step S22 of Fig. 3, it is determined whether the video image data has been uploaded in a private form (Step S23).If it is determined that it is in a private form, the compressed video data is stored in the private storage 1 Ob (Step S24), and a mail to the effect that the video image data has arrived at a delivery address provided by the sender (Step S25). The portal site 10 automatically erases the compressed video image data stored in the private storage 10b after storing the data for a certain period of time (for example, for several days) after the recipient's mobile terminal 13 has downloaded the same (Step S26). If it is determined that it is in a public form at Step S23, the compressed video data are sorted by category (Step S27), and then, possibly, it is determined whether there is a possibility of copyright infringement or not (Step S28).

If it is determined that there is no possibility of copyright infringement, the compressed video data is stored in the public storage 1 Oc after being sorted for each category (Step S29). If it is determined that there is a possibility of copyright infringement at the processing of Step S28, then the compressed video data is discarded (Step S30). The portal site 10 automatically erases the compressed video image data stored in the private storage 1 Oc after storing the data for a certain period of time (for example, for three weeks) after it is uploaded (Step S31). In the meantime, since the processing operation performed at the portal site 10 for the video data uploaded from the computer terminal 12 of the corporate user is fundamentally similar to that for the video data in the public form uploaded from the personal user's terminal 11, a detailed description thereof will be omitted.

Fig. 4 is a flow chart explaining an operating procedure for a personal user to upload video data, and Fig. 5 is an explanatory diagram showing the screen of a personal user's mobile phone in the case of uploading in a private form. Hereafter, a personal user's upload operating procedure is explained with reference to these drawings.

As shown in Fig. 4, firstly, connection is established by accessing the portal site 10 through the mobile terminal (e.g., mobile phone) or the computer terminal 1 1 (Step S50). Then, at the time of a first-time use, an account contract for uploading purpose is made through the portal site 10, and thus a personal account is obtained (Step S51). This personal account is something like δδδ@mobic!ip.jp, for example, and a fixed

price contract, such as monthly fixed price contract, is made after terms of service are agreed upon.

Subsequently, a video data is obtained by shooting, or a video data obtained beforehand is called up (Step S52), and then the portal site 10 is accessed to thereby establish connection (Step S53). Unloadable data form as used herein is a digital data form, such as video image data (including sound data) shot by mobile phones, video cameras, digital cameras, etc. At this moment, the personal user who has connected with the portal site 10 chooses an uploading form, i.e., chooses between a private form targeting video images addressed to specific personal users, and a public form targeting those made publicly available for an unspecified number of personal users (Step S54).

If the private form is chosen and then upload is to be performed (Step S55), a personal user, as shown in Fig. 5, creates a mail by leaving a message addressed to a destination (two or more destinations may be possible) of the video image, and then clicks a "Send" button with the video image file being attached to thereby upload the same (Step S56). This video image file is not sent to any other address(es) than is/are specifically designated.

As mentioned above, the video data uploaded onto the portal site 10 is automatically transferred to the encoder server 10a (Step S57), and then compressed by the Mobiclip encoder (Step S58). The compressed video data is then stored in the private storage 10b (Step S59), and a mail with a message that the video image data has arrived is sent to the address (es) thereof (Step S60). As mentioned above, this video data stored in the private storage 10b is erased a certain period of time after the recipient has downloaded the same (Step S61). In the case of uploading the data with the public form being chosen (Step S62), a personal user chooses the category of the video image and clicks the "Send" button (Step S63). Examples of the categories to be chosen include "travel", "nature", "pet", "dance", "entertainment", etc. The video image data is uploaded by this operation (Step S64). As mentioned above, the video data uploaded onto the portal site 10 is automatically transferred to the encoder server 1 Oa, and compressed by the Mobiclip encoder (Step S65). As for the compressed video image data, if it is from personal users, it is determined whether there is any possibility of infringing copyright (Step S66). If it is eventually determined that there is no possibility of copyright

infringement, the compressed video data is sorted for each category, and is stored in the public storage 1 Oc (Step S67). As mentioned above, this video data stored in the public storage 10c is erased a certain period of time after it is uploaded (Step S68).

Fig. 6 is a flow chart explaining an operating procedure for a personal user to download the video data. Fig. 7 is an explanatory diagram explaining the screen of a personal user's mobile phone in the case of downloading, and Fig. 8 is another explanatory diagram explaining the screen of a Mobiclip player incorporated beforehand into the mobile terminal 13, such as mobile phone. Hereafter, a personal user's download operating procedure is explained with reference to these drawings. As shown in Fig. 6, firstly, connection is established by accessing the portal site

10 through the mobile terminal 13 (Step S70). Then, at the time of a first-time use, an account contract for downloading purpose is made through the portal site 10, and thus a personal account is obtained (Step S71). This personal account is something like δδδ@mobiclip.jp, for example, and a fixed price contract, such as monthly fixed price contract, is made after terms of services are agreed upon.

When a mail with a video image file attachment, is received, it is directed to downloading in a private form (Step S72). When a personal user (recipient) clicks the video image file in the mail on the mobile terminal 13 shown in Fig. 7 (Step S73), the portal site 10 is accessed, so that the compressed video file stored in the private storage 10b and addressed to the recipient is downloaded onto this mobile terminal 13 (Step S74).

Simultaneously with the termination of downloading, the Mobiclip player for video data as shown in Fig. 8 (A) or (B) pops up on the screen of the mobile phone 13, which is then operated by the recipient to thereby decode the downloaded compressed video data by the Mobiclip decoder, thereby enabling the listening and viewing thereof (Step S75), and, as a result, viewing and listening are actually performed (Step S76). In the meantime, Fig. 8 (A) illustrates a case where the screen is vertically long, while Fig. 8 (B) illustrates a case where the screen is horizontally long, and icons on the screen function as a fast -rewind and fast-forward button 1 , a play button 2, a stop button 3, a fast-rewind button 4, a fast-forward button 5, a mute button 6, a volume button 7 and a window-closing button 8, respectively.

Accordingly, on the screen of the mobile phone 13 are displayed the categories of the contents provided by the portal site 10, as shown in Fig. 9, so the recipient chooses a desired category and clicks it (Step S78). For example, when choosing a

video image in a public form, the recipient chooses one category from among "movie", "music", and "Mobiclip" in the field of "enjoy" and then clicks it. When the category of "movie" is chosen, the contents thereof are displayed as shown in Fig. 10, when the category of "music" is chosen, the contents thereof are displayed as shown in Fig. 11, and when the category of the Mobiclip is chosen, the contents thereof are displayed as shown in Fig. 12, respectively.

Subsequently, the recipient chooses the video image which he/she wants to view and then clicks it (Step S79), so that the video file thus chosen is downloaded onto the mobile phone 13 (Step S80). Simultaneously with the termination of downloading, the above-mentioned

Mobiclip player for video data pops up on the screen, which is then operated by the recipient to thereby decode the downloaded compressed video data by the Mobiclip decoder, thereby enabling the listening and viewing thereof (Step S81), and, as a result, viewing and listening are actually performed (Step S82). Fig. 13 is a flow chart explaining an operating procedure for a corporate user to upload the video data. Hereafter, a corporate user's upload operating procedure is explained with reference to the drawing.

As shown in the drawing, a corporate user, firstly, makes an account contract with the portal site 10, thus obtaining a corporate account (Step S 150). This corporate account is made available for a monthly or yearly fee, for example.

Subsequently, video or sound contents for the general public that are basically determined by the intent of the corporate user, such as CMs, promotional music video clips, movie previews, etc, are provided as advertisements (Step Sl 51), and the video or sound data are uploaded onto the portal site for corporate use (Step S 152). The video data thus uploaded are compressed by the Mobiclip encoder of the server 1 Oa (Step Sl 53), and transferred to the public corporate storage 10a (Step S 154), and then sorted for each category to be stored in a downloadable form (Step Sl 55). As mentioned above, the video data stored in the corporate storage 1Od are erased a certain period of time after having been uploaded (Step Sl 56). In a particular embodiment of the invention, the uploaded videos could be aggregated in an aggregation service on the portal server.

This aggregation service intends to offer to the user the ability to manage an online playlist of various types of videos. The user can customize the videos of his playlist. Once the playlist is built, the user can connect easily to any of the aggregated

content from any registered terminal. The goal is to allow an easy customization of the service from a user station, typically a home computer, and an easy consultation of the aggregated content from a user terminal, typically a mobile phone, a PDA {personal digital assistant), a games console. Fig. 14 illustrates the architecture of the aggregation service according to this particular embodiment. The portal server 14.1 hosts two different modules. The first module is a playlist management module 14.2 to manage a list of links to available videos. The second one in an encoder module 14.3 intended to encode these available videos to fit the destination terminal constraints regarding videos play. These modules could be deployed on different numbers of physical servers. In a minimal implementation they could be hosted on the same physical server. Moreover for real services each module is likely to be hosted on several servers to fit the load. The user can access the playlist management module from a user station 14.4. The user station is used to access the account and to customize the service. The user station is likely to be a personal computer as it is convenient for manipulating the customization interface. But this is not mandatory and the customization interface could also be accessed from any terminal, including mobiles' one, able to connect to the site hosting the playlist management module.

The playlist module allows the user to customize the content he wants to make accessible from various terminals 14.5. These terminals could consist of mobile phones, PDA, games console or any terminal able to access the net and to play multimedia content. The user is able to manage a plurality of terminals via the customization interface. For each of these devices, some constraints will be stored. We can cite the size of the screen, the processing resource or any feature that can be useful in order to be able to prepare suitable content to be delivered to the terminal. When the user is using his terminal to access the content of the playlist, this content will be accessed, for example from Internet 14.6 or local storage on the service and processed by the encoder 14.3. The encoder 14.3 will receive the content to be delivered and will process it. The process could involve some compression step, encoding step, change the resolution, the number of colours. These steps are made according to the constraints of the dedicated terminal. Then, the content is broadcast to the terminal for play. The broadcast is generally done by streaming content to the terminal.

Fig. 15 is an explanatory drawing explaining the screen of the customization tool from the user station. A first block of menus is there to manage the login and subscription to the service. A second block of menus is dedicated to the management of content. The content that can be aggregated on the playlist is gathered by group depending on the type of content. Seven types of content are described in this figure, but other groups could be added, or content could be gathered in a different manner. A first group is dedicated to video on demand (VOD) movies. The user can gather there all the movies he bought right for. The interface offers the ability to add or delete some items in the group. A second group is dedicated to TV programs. These programs are from channel the user receive at home and are broadcast from his set top box or ADSL gateway. The user is able to list here his favourite programs. In a third group he could gather programs from webtv channels accessible on the network. In a fourth group he can aggregate some user generated videos from sharing sites like YouTube or MySpace. In a fifth group he can gather free videos. In a sixth group are aggregated some personal videos that are uploaded on the mobiclip servers by the user. A seventh group aggregates some webcams.

The user can freely add or delete some items in all these groups. Optionally he could also create or suppress entire groups of content. For each item, the playlist will store a link to the content. The real content can be available from various sources. One can cite web servers, home set top boxes or ADSL gateways, user storage on the mobiclip server itself. The content can even be available for broadcast from the user station. In that case, the service allows the user to become its own content provider. As, the service is managed by the playlist management module, this last option does not imply to open ports on the user station as requests from terminals will not be served directly by the user station but by the playlist management module.

When surfing the network from his user station, the user can add a content in his mobiclip aggregation service by simply right click the content and select a field "mobiclip it". Then the link is automatically saved in his account.

A third menu block allows the user to manage the destination terminals he will use to access the content. He can register new terminals, delete a terminal or view the list of registered terminals. For each registered terminal a set of feature representing the constraints of the terminal regarding videos play is stored by the playlist management module. This set of feature is used by the encoder to customize the encoding process according to the actual terminal requesting the content.

When registering a terminal via the web site, the user is also proposed to manage a list of shortcuts to give direct access to some items. For example, if the terminal is a mobile phone with a keypad, it is possible to assign an item to each touch of the keypad. The number of shortcut depends on the type of terminal used. For example, if the mobile terminal has a complete mini keyboard, it is possible to assign a shortcut to each touch.

Optionally the user can also set the audience for the content to control who can access the content linked. This audience can be set from private where the content is to be accessed only by the user, to public where everybody can access the content. An intermediate option could be to reserve the access to a friend or family list registered on the server. This audience can be set for the whole aggregation service, or a group, or even to an individual item.

Fig. 16 is a flow chart of the operation of viewing a content from the user terminal. After launching the mobiclip application on the terminal, in a first step 16.1 , the user connects to the service. In response, the playlist management module sends the playlist to the terminal in a step 16.2. Once the playlist received by the user, he is able to browse this playlist to select a content. He can also use one of the customized shortcuts for direct access. Then, the selected content id is sent back to the playlist management module in a step 16.3. Advantageously the request contains the id of the terminal. On reception of the request the playlist management module sends a request for the URL {Unified Resource Locator) of the selected content to the encoder. It is the step 16.4. Advantageously this request contains the features of the terminal found from its id as the terminal should be registered. The encoder responds to the playlist management module with the requested URL in a step 16.5. The playlist management module sends this URL to the terminal in a step 16.6. Once the terminal get the URL of the content, it sends the request to this URL to the encoder in the step 16.7. Then, the encoder connects to the content source through the network in the step 16.8. The source could be a server on the net or by user equipment like a set top box, an ADSL gateway or the user station itself. Once connected to the source and receiving the requested content, step 16.9, the encoder processes this content to fit the terminal features. The requested stream is then broadcast to the terminal by the encoder in the step 16.10.

Alternatively, in order to distribute the load of encoding, the encoder module can be implemented on the user station. In this embodiment, the user station has to be

on and connected to be used for streaming content to the terminal. In this case, an encoder could be foreseen on the server in cases where the user station is not usable as a fallback solution.

The access to subscription services can be managed by the playlist management module. In a particular embodiment, the user can register its digital right on the server. For example, the access rights to pay TV could be stored on the server. In this case, the user could access to the pay TV programs from the server without the need to use the home user equipments. The encoder on the server could directly access to the protected content using the user access rights and broadcast the content to the terminal in case the home equipment is unreachable. Of course, this operating mode is restricted to private items to be viewed only by the user.

As an option, two users using the service can exchange some items of their playlist. When a user is sending to another user an item, the id of this item is automatically added to the receiver playlist automatically. To do this, the user when manipulating his playlist with the mobiclip application on the terminal or on the web site is able to select one item to be sent. A message is then sent to the receiver with the item id. On reception by the terminal of the receiver of the message, the item id is processed by the mobiclip application of the receiver. The mobiclip application on the receiver's terminal sends then an update request to the playlist management module with the item id. The item id is added to the receiver playlist by the playlist management module. The user can also receive a link from a commercial server in a shop for example. He can also use a search motor on his mobile to search for videos to add to his playlist.

The above-described embodiments are shown for purposes of illustration, not limitation, and the present invention may be implemented in other various modification modes and alternative modes. Therefore, the scope of the present invention is only prescribed by patent claims and their equivalent range.