Personalization content sharing system and method

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation-in-part application of U.S. Ser. No. 11/544,938, filed Oct. 10, 2006, which claims benefit from the following U.S. Provisional Patent Applications: 60/771,883, filed Feb. 10, 2006, 60/772,564, filed Feb. 13, 2006, 60/819,621, filed Jul. 11, 2006 and 60/841,233, filed Aug. 31, 2006, all of which are hereby incorporated in their entirety by reference.

FIELD OF THE INVENTION

The present invention relates to communication devices generally and to personalization content sharing on the communication devices by a community of users in particular.

BACKGROUND OF THE INVENTION

Cellular telephones are known in the art. Such devices were originally developed to provide mobile telephony services to users who for reasons of preference, convenience or circumstance required wireless connections to a public telephony network. The earliest cellular telephones were dedicated devices that lacked the capability to be used for other purposes.

Recent cellular telephones have more advanced operating systems that enable users to enrich and personalize their mobile telephony experience. For example, users can display or play media content such as photos, video clips, and audio files.

One of the most popular ways to personalize a mobile user's telephony experience is to select a unique audio ringtone to be played for incoming calls. The ringtone selected by the user overrides the default ringing sound selected by the telephone manufacturer.

Some cellular telephones run software that supports the definition of unique ringtones for a specific contact or for groups of contacts.

Some of these cellular telephones support user definition of a photo or video clip to display when an incoming call is received from a specific contact or group of contacts.

The media files used for these personalization services are available from a variety of sources. A small selection of files is usually pre-loaded on the devices prior to their distribution. The devices also often come equipped with cameras and audio recorders that may be used to create such media files on the devices themselves. Files may also be transferred from other devices in the user's possession via a physical connection or a short range wireless connection technology such as Bluetooth or infra-red. Some media files are also typically downloaded “over the air” across an Internet connection via the connection supplied by the mobile network operator or other media content provider.

Some cellular network operators have introduced “ringback” personalization services, which enable a mobile subscriber to define the audio clip that the network operator will play instead of the normal “ring” for someone calling the subscriber's phone number.

Ringtones and Ringback tones are available in other systems as well. SIP (Session Initiation Protocol), which may be used to connect devices for a voice over IP (VoIP) connection, also provides an option for the selection of alternative tones. The alternative tone may be indicated by a URL (universal resource locator) that may be used to download the tone at the time the connection is made. The download may be performed using a different channel than the VoIP connection.

“Endtone” personalization services may soon be offered by network operators. Endtones may include specialized disconnect tones to notify wireless device users that voice and data connections are terminated. Endtones have been announced by Endtone of the United States.

BRIEF DESCRIPTION OF THE DRAWINGS

The subject matter regarded as the invention is particularly pointed out and distinctly claimed in the concluding portion of the specification. The invention, however, both as to organization and method of operation, together with objects, features, and advantages thereof, may best be understood by reference to the following detailed description when read with the accompanying drawings in which:

<figref idref="DRAWINGS">FIG. 1</figref> is a schematic illustration of a novel media content sharing system, constructed and operative in accordance with the present invention;

<figref idref="DRAWINGS">FIG. 2</figref> is a block diagram illustration of the method used by the system of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIGS. 3A</figref>, <b>3</b>B and <b>3</b>C are illustrations of data files used by the system of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIGS. 4A and 4B</figref> are schematic illustrations of exemplary mobile devices forming part of the system of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 5</figref> is a schematic illustration of an alternative embodiment of the system of <figref idref="DRAWINGS">FIG. 1</figref>;

<figref idref="DRAWINGS">FIG. 6</figref> is a schematic illustration of a further alternative embodiment of the system of <figref idref="DRAWINGS">FIG. 1</figref>; and

<figref idref="DRAWINGS">FIG. 7</figref> is a schematic illustration of a multi-platform embodiment of the system of <figref idref="DRAWINGS">FIG. 1</figref>.

It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION OF THE PRESENT INVENTION

In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the present invention.

Applicants have realized that there are several barriers to the introduction and success of systems that provide voice connections concurrent with the download and play of media files. Such barriers include, for example, the inability of many current mobile networks to provide concurrent voice and data connections to a single device. Certain variations of a relatively new mobile network technology, known as “3G”, are capable of providing concurrent voice and data connections. However, 3G networks may still suffer from latency that may affect the quality when attempting to synchronize the download and play of media files with a voice connection. Furthermore, the repeated downloading of media files is often prohibitively expensive.

Applicants have realized that creating a community to define media files to be played when two friends, or “buddies”, communicate may provide the illusion of real time sharing of media content between the two buddies. Such media files may be downloaded to a buddy's device prior to the conversation.

Reference is now made to <figref idref="DRAWINGS">FIG. 1</figref>, which illustrates a novel media content sharing system <b>100</b> capable of providing the illusion of real time sharing of media content between a novel communication device <b>110</b>, owned by, for example, Jack, and a telephone <b>120</b>, owned by, for example, Jill, who are simultaneously setting up or using a voice connection <b>140</b> for a telephone conversation.

In accordance with one preferred embodiment of the present invention, Jack and Jill may both be members of a media content personalization sharing community <b>150</b>, organized through a community server <b>130</b>. Community server <b>130</b> may be a web server including, for example, a media file database <b>132</b>.

Members of community <b>150</b>, such as Jack and Jill, who elect to share personalization content (i.e. media files, such as photos, audio clips and video clips) with each other are said to be “buddies.” Typically, the buddy sets of the members are not the same.

In a preferred embodiment of the present invention, individual members of community <b>150</b> may select (arrow <b>131</b>) media content on community server <b>130</b> that they wish some or all of their buddies to see and/or hear. For example, Jill may select a media file <b>134</b>. At some other time, each member may download (arrow <b>133</b>), to their own devices <b>110</b>, the selected media content of his/her buddies. Thus, Jack may download a version <b>136</b> of media file <b>134</b> to his device <b>110</b>, where media file <b>136</b> may be a version of the file suitable for presentation to Jack on his device. It will be appreciated that such a download may be performed as an occasional automated procedure initiated by Jack's device <b>110</b>, or as one initiated by Jack, or as one initiated by server <b>130</b> in response to new selection <b>131</b>.

Novel device <b>110</b> may be any suitable “smart phone” capable at least of providing telephony services, downloading data, and of presenting a variety of media content. Novel device <b>110</b> may include a media player <b>112</b> among its standard feature set and, in accordance with a preferred embodiment of the present invention, may also comprise a personalization content manager <b>137</b> and a media file storage unit <b>138</b> capable of receiving and storing media file <b>136</b>. Telephone <b>120</b> may be a novel communication device like device <b>110</b> or it may be any suitable telephone, such as a landline phone, a mobile phone, a digital phone, a VoIP phone, or an analog phone.

On the occasion of a telephone connection between Jack and Jill over voice connection <b>140</b>, personalization content manager <b>137</b> may cause media file <b>136</b> selected by Jill to be played on media player <b>112</b> of device <b>110</b> belonging to Jack. It will be appreciated that, since media file <b>136</b> may “belong” to Jill and may be downloaded to device <b>100</b> without any intervention from Jack, Jack may have the illusion that media file <b>136</b> was provided from Jill across connection <b>140</b> at the time of the telephone conversation, without any latency.

It will further be appreciated that media file <b>136</b> was not provided concurrently by the operators of voice connection <b>140</b>, even though Jack may have the illusion otherwise. It will still further be appreciated that media file <b>136</b> may be played even on pre-3G devices, as long as such devices can download and play media files.

Reference is now made to <figref idref="DRAWINGS">FIG. 2</figref>, which illustrates the method performed by device <b>110</b> to play media file <b>136</b> when simultaneously involved in a voice connection operation with telephone <b>120</b>.

Personalization content manager <b>137</b> may remain (step <b>200</b>) in a wait state until notification of an activating event <b>210</b> is received. Activating event <b>210</b> may be, for example, a call initiation <b>212</b>, a call ringing <b>214</b>, or an end of call <b>216</b>. Call initiation <b>212</b> may occur when device <b>110</b> is used to initiate a call to telephone <b>120</b>, at the point of dialing or connecting. Call ringing <b>214</b> may occur when device <b>110</b> detects an incoming call from telephone <b>120</b>. End of call <b>216</b> may occur when a phone conversation between device <b>110</b> and telephone <b>120</b> ends and is determined by notification of a hang up or idle state.

After activating event <b>210</b> may be received, personalization content manager <b>137</b> may retrieve (step <b>220</b>) the telephone number of telephone <b>120</b> and may use it to look up (step <b>230</b>) the media file <b>136</b> associated with Jill, whose telephone number was retrieved.

Personalization content manager <b>137</b> may then launch (step <b>240</b>) the associated media file <b>136</b> for play by media player <b>112</b>. Media player <b>112</b> may stop at the completion of media file <b>136</b> or may continue to play media file <b>136</b> in a continuous loop until personalization content manager <b>137</b> may receive notification of an ending event <b>250</b>. Ending event <b>250</b> may be, for example, a call connection <b>252</b>, a call answering <b>254</b>, or a call hang up <b>256</b>.

Call connection <b>252</b> may occur when telephone <b>120</b> answers a call initiated by device <b>110</b>. Such a state may apply when activating event <b>210</b> was, for example, call initiation <b>212</b>. Call answering <b>254</b> may occur when device <b>110</b> answers an incoming call initiated by telephone <b>120</b>. Such a state may apply when activating event <b>210</b> was, for example, call ringing <b>214</b>.

Call hang up <b>256</b> may occur when the phone conversation between device <b>110</b> and telephone <b>120</b> ends, such as when either device <b>110</b> or telephone <b>120</b> hangs up. Such a state may apply when activating event <b>210</b> was, for example, either call initiation <b>212</b> or call ringing <b>214</b> and the connection may not have completed between device <b>110</b> and telephone <b>120</b>.

After personalization content manager <b>137</b> receives notification of an ending event <b>250</b>, personalization content manager <b>137</b> may stop (step <b>260</b>) media player <b>112</b>, after which personalization content manager <b>137</b> may return to wait state <b>200</b>.

In accordance with a preferred embodiment of the present invention, Jill may have selected a different media file <b>134</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for each activating event. Accordingly, personalization media file database <b>138</b> of device <b>110</b> may include, for example, a personalization media file <b>136</b>A to be played for call initiation event <b>212</b>; a second personalization media file <b>136</b>B to be played for call answering event <b>214</b> and a third personalization media file <b>136</b>C to be played for end of call event <b>216</b>.

It will be appreciated that more than one activating event <b>212</b> may occur during the course of a single connection between device <b>110</b> and telephone <b>120</b>. For example, call initiation <b>212</b> may occur when device <b>110</b> calls device <b>120</b>. Personalization content manager <b>137</b> may play associated media file <b>136</b>B until, for example, call connection <b>252</b> occurs. Jack and Jill may then conduct a typical telephone conversation. When the telephone conversation ends, personalization content manager <b>137</b> may play the media file <b>136</b>C associated with end of call <b>216</b>.

Similarly, for example, call ringing <b>214</b> may occur when device <b>110</b> receives an incoming call from telephone <b>120</b>. Personalization content manager <b>137</b> may play associated media file <b>136</b>A until, for example, call answering <b>254</b> occurs. Jack and Jill may then conduct a typical phone conversation. When the telephone conversation ends, personalization content manager <b>137</b> may play the media file <b>136</b>C associated with end of call <b>216</b>.

It will be appreciated that additional examples of activating event <b>210</b> may occur at any time during the set up, execution, or end of a telephone call between device <b>110</b> and telephone <b>120</b>.

In an alternative preferred embodiment of the present invention, such additional examples of activating event <b>210</b> may also be associated with unsuccessful attempts to complete a connection and conduct a typical phone conversation. For example, activating event <b>210</b> may be a busy signal, network congestion (“fast busy” signal), or call waiting. In accordance with this embodiment, Jill may select one or more media files <b>134</b> (<figref idref="DRAWINGS">FIG. 1</figref>) for these activating events <b>210</b> as well.

Reference is now made to <figref idref="DRAWINGS">FIG. 3A</figref> which represents an exemplary user media table <b>390</b>, which may be stored on community server <b>130</b>. For every user <b>360</b> in table <b>390</b>, there may be one or more records indicating activating events <b>370</b> and the associated media files <b>380</b> to play for each activating event <b>370</b>.

In accordance with the embodiment of <figref idref="DRAWINGS">FIGS. 1 and 2</figref>, Jill may have selected the media file VID1.3GP for playing on the device of her buddies, whenever a buddy initiates a call (i.e. call initiation) to Jill. Jill may also have selected the media file VID2.3GP for playing on the device of her buddies, whenever she calls a buddy (i.e. call ringing). She may also have selected the media file VID3.3GP for playing on the devices of her buddies whenever a phone call between her and one of her buddies ends, regardless of who initiated the connection.

Other information which may be stored in the user media table <b>390</b> may include account information for the user, the content source, such as a universal resource locator (URL) for each media file <b>134</b> and/or a record of when the file was copied from the server to media file storage unit <b>138</b>. It will be appreciated that the data in <figref idref="DRAWINGS">FIG. 3A</figref> is exemplary in nature and does not represent an exhaustive listing of the possible events for which Jill may select media files to play. For example, in accordance with an alternative preferred embodiment of the present invention, user media table <b>390</b> may also include selections of media files <b>134</b> to be played when a caller receives a busy signal, a “fast busy” signal, or call waiting.

In accordance with an alternative preferred embodiment of the present invention, user media table may also include selections of default media files <b>134</b> to be played when Jill is called by someone that does not meet any of the criteria for her other selections. For example, a caller may not be a member of community <b>150</b>. It may also be possible that Jill's caller may be a member of community <b>150</b>, but may not be Jill's buddy. Another possibility may be that Jill's caller may be indeed be her buddy, but that neither she nor such caller have previously selected a media file <b>134</b> to be played in such a situation. Jill may select one or more default media files <b>134</b> to be played in such situations.

Different versions of user media table <b>390</b> may be located on device <b>110</b> and on community server <b>130</b>. Device <b>110</b> may store a local version, which may be a small portion of table <b>390</b> having the records of only those buddies of the owner of device <b>110</b>. Community server <b>130</b>, on the other hand, may store the entire table, for all the members of community <b>150</b>.

Reference is now made to <figref idref="DRAWINGS">FIG. 3B</figref> which illustrates a user-buddy table <b>392</b> that may be used to define relevant records to be stored in each local version of user media table <b>390</b>. For every user <b>362</b> in table <b>392</b>, there may be one or more records listing his buddies <b>364</b>. In <figref idref="DRAWINGS">FIG. 3B</figref>, user <b>1</b> is listed as having buddies user <b>2</b>, user <b>3</b>, user <b>4</b>, and user <b>7</b>; and user <b>2</b> is listed as having user <b>1</b> as his buddy.

Reference is now made to <figref idref="DRAWINGS">FIG. 3C</figref>, which shows an alternative format for user-buddy table, here labeled <b>392</b>′. Table <b>392</b>′ records users <b>362</b> and their buddies <b>364</b>, as before. In addition, to enable users <b>362</b> to share different media files <b>380</b> with different buddies <b>364</b>, buddy table <b>392</b>′ may record which media files <b>380</b> are to be shared with which buddy <b>364</b> for which type of activating event <b>370</b>.

In accordance with the preferred embodiment of the present invention, community server <b>130</b> may update the local version of user media table <b>390</b> from time to time, as discussed hereinabove, with data stored in the server version of user media table <b>390</b>. The update process may refer to buddy table <b>392</b> to determine which records to download to the local version as well as which files to download.

The update process may define a population of records in buddy table <b>392</b> where user <b>362</b> matches the name of the owner of device <b>110</b>. The process may then download records from the server version of user media table <b>390</b> for the relevant user <b>362</b>.

It will be appreciated that tables <b>390</b> and <b>392</b> may be updated and stored in other ways and such other ways are included in the present invention. For example, and not inclusive, tables <b>390</b> and <b>392</b> may be stored locally. Additions and changes to them may be generated on community server <b>130</b> and may be downloaded to device <b>110</b> at the appropriate moment. They may be deleted thereafter from community server <b>130</b>.

Reference is now made to <figref idref="DRAWINGS">FIG. 4A</figref>, which details one exemplary device <b>412</b> with its personalization content manager, here labeled <b>416</b>, implemented on a mobile telephone. Device <b>412</b> may comprise, as part of its feature set, an operating system <b>450</b>, a media player <b>425</b> and a phone application <b>414</b>, to which may be added personalization content manager <b>416</b> and a personalization storage unit <b>418</b>.

Operating system <b>450</b> may provide connectivity between the elements of device <b>412</b>, typically via operating system application programming interfaces (APIs). In accordance with a preferred embodiment of the present invention, the operating system of device <b>412</b> may be Symbian OS, commercially available from Symbian Ltd. of the United Kingdom. Alternative embodiments may include, for example, BREW, commercially available from QUALCOMM Incorporated of the United States; derivatives of Microsoft Windows for mobile devices, such as Windows Mobile or MS SmartPhone, commercially available from Microsoft Corporation of the United States; or derivatives of Java such as Java Micro Edition (popularly known as JME or J2ME) and commercially available from multiple vendors.

Phone application <b>414</b> may comprise, for example, all the functions necessary for device <b>412</b> to operate as a cellular telephone and may interface directly with operating system <b>450</b>. Phone application <b>414</b> may pass phone number and caller id information to personalization content manager <b>416</b> through standard operating system APIs. Similarly, personalization content manager <b>416</b> typically may launch the media files via operating system <b>450</b>, which may, in turn, start up media player <b>425</b>.

Personalization content manager <b>416</b> may be started as a resident application when device <b>412</b> may be booted up. Manager <b>416</b> may remain in a dormant wait state until the user initiates a call to another device or when an incoming call is detected.

Personalization content manager <b>416</b> may comprise a main program <b>415</b>, a line status determiner <b>417</b> and a phone number determiner <b>419</b>. Line status determiner <b>417</b> may make API calls to operating system <b>450</b> to receive indications of when an activating event occurs. Line status determiner <b>417</b> may forward the status to main program <b>415</b>. Main program <b>415</b> may activate phone number determiner <b>419</b> whenever line status determiner <b>417</b> may indicate that an activating event has happened and phone number determiner <b>419</b> may determine the phone number associated with the activating event. In one embodiment, phone number determiner <b>419</b> may monitor changes in a phone log (not shown) to find the currently active phone number. In another embodiment, phone number determiner <b>419</b> may register to receive the phone number whenever operating system <b>450</b> provides indications of a new event to line status determiner <b>417</b>. Main program <b>415</b> may then use this phone number to look up the associated media file <b>436</b> in storage unit <b>418</b>.

For some phones, operating system <b>450</b> may accord the highest processing priority to phone application <b>414</b> to ensure that the telephony services take precedence over the execution of other operations, such as the playing of media files. Similarly, phone application <b>414</b> will typically be in a window group with the highest z-order priority, which determines precedence for the display of application data on the device screen. Such z-order priority may interfere with the display of media file <b>136</b>. Therefore, in accordance with a preferred embodiment of the present invention, main program <b>415</b> may raise the priority of the window group associated with media player <b>425</b> in order to enable its display to take precedence over the displays of phone application <b>414</b>. Alternatively, main program <b>415</b> may raise the process priority of the process associated with media player <b>425</b> or with personalization content manager <b>416</b>.

It will be appreciated that some cellular telephones may not gracefully handle such changes to priority of the window and/or of the process. The behavior may vary greatly in response to even minor changes in the handset model or embedded firmware. However, Applicants have realized that the properties of newer cellular telephone handsets may be utilized. Some handsets, such as the Sanyo MM-7500, allow the user to select video ringtones to be played in response to incoming calls. Certain of these handsets, such as the Sanyo MM-7500, even allow the user to specify specific video ringtones to be played in response to incoming calls from particular users.

Applicants have realized that, for such handsets, all that needs to be manipulated is the contact list. In fact, many newer Java handsets support a contact list API through “JSR 75: PDA Optional Packages for the J2ME™ Platform”. This specification provides a framework allowing Java programs access to the handset-maintained propertied associated with contacts in the handset contact list.

The JSR 75 API specifies a variety of “details” associated with each contact and provides a mechanism allowing handset manufacturers and other implementers to extend this list. Standard details include PHOTO and PHOTO_URL, allowing association of a photographic image either from storage or from a URL. Certain manufacturers allow the supplied photographic image to also be a slideshow animation or a video clip. Other manufacturers define custom JSR 75 “details” allowing the application to supply both an audio ringtone and a silent picture or animation. Similar APIs and capabilities may exist in other mobile operating systems, such as Symbian, Windows Mobile, BREW, and proprietary environments. Similar APIs and capabilities may also exist on a variety of other network-enabled communication devices, such as IP phones, VoIP soft phones, set-top boxes, etc.

Reference is now made to <figref idref="DRAWINGS">FIG. 4B</figref>, which illustrates one exemplary such handset <b>461</b> with its personalization content manager, here labeled <b>466</b>. Handset <b>461</b> may comprise an operating environment <b>460</b> which may comprise an operating system <b>462</b>, a phone application <b>463</b>, a media player <b>464</b> and a contact list application <b>465</b>, with an associated storage unit <b>467</b>. Handset <b>461</b> may additionally comprise personalization content manager, here labeled <b>466</b>, and a personalization storage unit <b>468</b>. In this embodiment and as discussed hereinabove, contact list application <b>465</b> may allow personalization content manager <b>466</b>, through an API such as one supporting JSR 75, to select video ringtones to be played in response to incoming calls and/or in response to calls from particular users.

In this embodiment, personalization content manager <b>466</b> may comprise an associator <b>470</b>, a downloader <b>472</b> and a contact list manager <b>474</b>. Similar to the operation of main program <b>415</b> (<figref idref="DRAWINGS">FIG. 4A</figref>), downloader <b>472</b> may download media clips <b>136</b> from community server <b>130</b> to storage unit <b>468</b>, or to contact list storage unit <b>467</b> if an API exists to do so, along with an indication of which buddy to associate it with. Associator <b>470</b>, through a programming API of operating environment <b>460</b> such as one supporting JSR 75, may pass the recently downloaded media clip <b>136</b> to operating environment <b>460</b> as the media content to be associated with the buddy, who is usually already a member of the contact list. If the buddy is not already in contact list <b>465</b>, contact list editor <b>474</b> may first add (also through a programming API) the buddy to contact list <b>465</b>, after which associator <b>470</b> may associate media clip <b>136</b> with the buddy's contact information.

When a call comes from a buddy, phone application <b>463</b>, typically in cooperation with contact list application <b>465</b>, may react to the caller-id and may play the associated media content properly.

Furthermore, in accordance with a further preferred embodiment of the present invention, operating environment <b>460</b> may also allow the registration, via a programming API, of a video ringtone that would play at other activation events, such as call initiation <b>212</b>, end of call <b>216</b>, or the various busy indications (regular busy, fast busy or call waiting), such as described hereinabove.

In this embodiment, associator <b>470</b> may perform any of the following operations:

a. specify the playing of a video clip on both incoming and outgoing calls;

b. specify playing a silent video clip;

c. specify playing an animation, such as an animated GIF slide show;

d. specify showing a still photo, such as a GIF or JPG image;

e. specify playing an audio track, together with silent video, animation, or still image; or

f. specify playing such media content only for incoming or only during outgoing calls.

Certain devices may support creating such associations remotely; for example using synchronization protocols that allow a server, such as community server <b>130</b>, to set the details associated with each contact. Such synchronization may not require the installation of any additional software on the device.

As detailed in the embodiments, the media file <b>136</b> played when a given member of community <b>150</b> receives an incoming call may not have been selected by that same member. Indeed, depending on the number of associated buddies, it may be likely that a large number of constantly changing media files <b>136</b> may be played for incoming calls, such that a given member of community <b>150</b> may not recognize the fact that an incoming call is on his/her device <b>110</b>. Accordingly, in a preferred embodiment of the present invention, members of community <b>150</b> may also select a “self ID” media file to be played before media file <b>136</b> for all incoming calls. With this, members of community <b>150</b> may recognize the incoming call as being on their devices <b>110</b> even though they may not recognize the sounds which follow.

Reference is now made to <figref idref="DRAWINGS">FIG. 5</figref> that illustrates a preferred embodiment of the present invention in which the playing of media file <b>136</b> may be occasioned by an event other than a voice connection between devices operated by Jack and Jill.

Playing device <b>510</b> may be owned by Jack and may be any programmable device capable of storing and playing media files. Such a device may be, for example, a desktop computer running VoIP software such as Skype, available from Skype Limited of Luxemburg, a handheld device having communication capabilities, or a soft phone. Jill's unit <b>520</b> may be any device or method by which Jill may contact, or be contacted by, playing device <b>510</b>. As in the embodiment of <figref idref="DRAWINGS">FIG. 1</figref>, Jack and Jill, the owners of playing device <b>510</b> and unit <b>520</b>, respectively, may be members of media content personalization sharing community <b>150</b> using community server <b>130</b> to select and download media files <b>136</b>.

Activating event <b>530</b> may be associated with any form of communication between playing device <b>510</b> and Jill's unit <b>520</b>, including, for example, email, SMS, instant messages, or VoIP. Activating event <b>530</b> may also be associated with any detail of such communication, including, for example, the timing, length, or contents of the communication, as well as the identity or presence state of the initiating entity.

It will be appreciated that, in addition to being a video file, an image or an audio file as discussed hereinabove, media file <b>136</b> may also be a request to invoke or launch a previously installed program or application. In the latter case, media file <b>136</b> is not necessarily played by a media player.

In accordance with an alternative preferred embodiment of the present invention, media file <b>136</b> may be an audio file, played at the end of a call. For such an embodiment, audio file <b>136</b>, which may be much smaller than a video sequence, may be downloaded from the other party to the conversation (which may or may not be a buddy) at any time, including prior to the conversation or during the conversation for devices that can perform simultaneous voice and data transfer. For devices that cannot simultaneously transfer voice and data, the download may occur just after the conversation ends. This download may occur from the community server <b>130</b> or along the voice channel. In the latter embodiment, the network operator may provide media file <b>136</b>.

Reference is now made to <figref idref="DRAWINGS">FIG. 6</figref>, which may describe a further alternative embodiment in which the communication channel may be an instant messaging (IM) channel between the users Jack and Jill. In this embodiment, the communication channel may include an IM server <b>630</b>. Jill's device may be an IM client <b>620</b> and Jack's device <b>610</b> may include an IM client <b>625</b> in addition to media player <b>112</b>, personalization content manager <b>137</b> and storage unit <b>138</b>.

As is known in the art, instant messaging, also known as “IM” or “chatting”, typically comprises the sending of textual messages, emoticons and/or animated emoticons, between two users, such as between Jack and Jill. In accordance with this embodiment of the present invention, Jill may additionally send Jack a triggering event, such as an identifier <b>635</b>, during their conversation. An exemplary identifier <b>635</b> may be a file name, a number or a URL of media file <b>136</b> to be played.

Jack's IM client <b>625</b> may recognize identifier <b>635</b> and may transfer it to personalization content manager <b>137</b>, along with some indication of the source of event <b>635</b> (e.g. Jill). As in the previous embodiments, manager <b>137</b> may retrieve media file <b>136</b> indicated by identifier <b>635</b> and may play it on media player <b>112</b>. Prior to playing media file <b>136</b>, manager <b>137</b> may additionally check to see that the source, e.g. Jill, was authorized to send identifier <b>635</b>.

As in the previous embodiments, media file <b>136</b> may have been previously downloaded to Jack's device <b>610</b> from community server <b>130</b>. Alternatively, it may be downloaded the first time that Jill may send identifier <b>635</b> and may be stored for later use when Jill may again send identifier <b>635</b>.

It will be appreciated that IM server <b>630</b> may be implemented separately from or as part of community server <b>130</b>. If servers <b>130</b> and <b>630</b> are implemented together, the combined server may perform part of the operation of IM client <b>625</b>. Thus, the combined server may check to see that the source, e.g. Jill, was authorized to send identifier <b>635</b> and/or may download the associated file if it was not previously downloaded to device <b>610</b>.

It will be appreciated that, as shown in <figref idref="DRAWINGS">FIG. 7</figref> to which reference is now briefly made, personalization content manager <b>137</b> may be implemented in many different types of devices, of which four have been discussed above and three are shown in <figref idref="DRAWINGS">FIG. 7</figref>. In addition to smart phones, cellular telephones, programmable devices and devices that allow instant messaging, manager <b>137</b> may be implemented on any type of device and for any type of platform which has communication ability and media playing abilities. Such other types of devices include but are not limited to, mobile handsets, Skype, IM sessions, the new outside screen on laptops, IP (Internet Protocol) phones with color screens, caller id pop ups on televisions, etc.

For example, <figref idref="DRAWINGS">FIG. 7</figref> shows four exemplary devices, a television <b>700</b> with a caller id pop up <b>702</b>, a laptop computer <b>704</b> with a secondary display <b>706</b> on the back of the cover, a video telephone <b>710</b> with a screen <b>712</b>, and a personal computer <b>720</b> with a IM session <b>722</b>, with their elements, including a device processor <b>701</b> to run the standard operation of the device.

The delivery mechanisms through which communication may occur are varied and may include, but are not limited to, IP, SIP (session initiation protocol), SMS (short message system), IVR (interactive voice response), etc. It will be appreciated that the personalization content sharing may be managed through community server <b>130</b>, irrespective of the delivery mechanism.

Furthermore, while the personalization content manager may be different for each type of device and/or delivery mechanism and thus, is labeled <b>137</b>A, <b>137</b>B, <b>137</b>C and <b>173</b>D in <figref idref="DRAWINGS">FIG. 7</figref>, each manager may include at least main program <b>415</b> (not shown in <figref idref="DRAWINGS">FIG. 7</figref>), which may manage the downloading and storage of media content files <b>136</b> and may provide the media file associated with the current buddy to whatever media player, labeled <b>730</b>A, <b>730</b>B, <b>730</b>C and <b>730</b>D, the device may have. In some embodiments, main program <b>415</b> may provide media file <b>136</b> in response to receiving an identification of the current buddy from a call handler <b>732</b> or an identification handler <b>734</b> of the device. Typically, such identification is a caller ID type identification but other identifications, such as customer number, etc., may also be utilized. In other embodiments, where the device has the ability to play different media files per identification, main program <b>415</b> may provide the media file for association with a given buddy prior to its use.

Alternatively, if call handler <b>732</b> or ID handler <b>734</b> is not capable of providing the identification, manager <b>137</b> may determine it from other information available on the device.

While certain features of the invention have been illustrated and described herein, many modifications, substitutions, changes, and equivalents will now occur to those of ordinary skill in the art. It is, therefore, to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the invention.