WO2013037007A1

WO2013037007A1 - A messaging system

Info

Publication number: WO2013037007A1
Application number: PCT/AU2012/001106
Authority: WO
Inventors: Jeff LENHAM
Original assignee: Bopcards Pty Ltd
Priority date: 2011-09-16
Filing date: 2012-09-14
Publication date: 2013-03-21

Abstract

A method (200, 200'), in a system (100) comprising a sender mobile terminal (109), a recipient terminal (106), and a server (101), communicating over a network (107), for sending, from the sender mobile terminal, a customised message to the recipient terminal, the method comprising requesting (201) a menu of pre-defined messages from the server, the messages having content elements that can be assigned one of a plurality of types; receiving (1613), in regard to a selected message, a name of a user of the recipient terminal, and gender information relating to at least one of the user and content elements of the selected message; assigning, to the content elements of the selected message, types based upon at least one of the received name of the recipient and the received gender information, to thereby construct (1634) the customised message; and sending (224) the customised message to the recipient terminal.

Description

- i -

A MESSAGING SYSTEM

Technical Field of the Invention

The present invention relates generally to messaging systems and, in particular, to messaging systems which enable pre-defined messages to be customised before they are sent to a recipient. The present invention also relates to a method and apparatus for sending a customised message, and to a computer program product including a computer readable medium having recorded thereon a computer program for sending a customised message.

Background

As mobile terminals become more commonplace, one popular application of such terminals is to send messages to friends and acquaintances. Messages come in many forms, including static images, video animations, audio ringtones and the like. Present systems for sending messages, particularly to friends and social acquaintances, are cumbersome and do not enable a person to easily customise a message according to the designated recipient, or to express feelings such as humour or romance in the messages. ·

Summary

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

Disclosed are arrangements, referred to as Personalized Message Arrangements (PMA), which seek to address the above problems by constructing customised messages based upon pre-defined templates, each of which has content elements, such as the gender of the voice which sings a song in the customised message, or the aura (male or female) of the animation presented in the message, which can assume one or more types, wherein the selection of the pre-defined template places constraints upon which of the content elements can assume which types.

Some messages can be personalized, which means that the name of the recipient can be incorporated into the message so that, for example, the song that is sung in an animated video will incorporate the name of the recipient into the song. Some messages can be customised but not personalized, meaning that the sender can include a greeting, usually text based, into the message being sent to the recipient, however the recipient's name is not incorporated into the animated video, if this is the form the message takes.

According to a first aspect of the disclosure, there is provided a method, performed by a server, in a system comprising a sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and the server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

providing to the sender mobile terminal a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre-defined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

receiving from the sender mobile terminal a command selecting a pre-defined message, and a name and an address of the recipient;

receiving from the sender mobile terminal, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient; receiving information from the sender mobile terminal, depending upon the identifier of the pre-defined message, said information specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient;

constructing the customised message wherein the gender of the singer of the song and the gender aura of the animated production is specified the received gender information; and

sending to the sender mobile terminal the customised message to the recipient terminal.

According to another aspect of the disclosure, there is provided a method, performed by a sender mobile terminal, in a system comprising the sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

receiving from the server a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre-defined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

sending to the server a command, dependent upon an input from the sender, selecting a pre-defined message, and a name and an address of the recipient;

sending to the server, if the name of the recipient has a number of possible pronunciations, a command dependent upon an input from the sender selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient;

^• sending to the server, depending upon the identifier of the pre-defined message, information dependent upon an input from the sender specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient; and sending the customised message to the recipient terminal.

According to another aspect of the disclosure, there is provided a method, in a system comprising a sender mobile terminal, a recipient terminal, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

providing by the server to the sender mobile terminal a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

receiving by the server from the sender mobile terminal a name of a user of the recipient terminal and a command selecting a pre-defined message;

receiving by the server from the sender mobile terminal/ depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

assigning by the server, to the content elements of the selected message, types based upon at least one of the received name of the recipient and the received gender information, to thereby construct the customised message; and

sending the customised message to the recipient terminal.

. According to another aspect of the disclosure, there is provided a method, performed by a sender mobile terminal in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

requesting from the server a menu of pre-defined messages having content elements that can be^' assigned one of a plurality of types; outputting to the server a name of a user of the recipient terminal and a command selecting a pre-defined message;

outputting to the server, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

receiving from the server the customised message having content elements that have been assigned types based upon at least one of the outputted name of the recipient and the outputted gender information; and

sending the customised message to the recipient terminal.

According to another aspect of the disclosure, there is provided a method, performed by a server in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

providing to the sender mobile terminal a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

receiving from the sender mobile terminal a name of a user of the recipient terminal and a command selecting a pre-defined message;

receiving from the sender mobile terminal, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

assigning, to the content elements of the selected message, types based upon at least one of the received name of the recipient and the received gender information, to thereby construct the customised message; and

sending the customised message to the recipient terminal. According to another aspect of the disclosure, there is provided a sender mobile terminal, in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, the sender mobile terminal being configured for sending a customised message to the recipient terminal, the sender mobile terminal comprising:

a processor; and

a computer readable storage medium comprising a program for execution on the processor, the program comprising;

computer program software code for requesting from the server a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

computer program software code for outputting to the server a name of a user of the recipient terminal and a command selecting a pre-defined message;

computer program software code for outputting to the server, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

computer program software code for receiving from the server the customised message having content elements that have been assigned types based upon at least one of the outputted name of the recipient and the outputted gender information; and

computer program software code for sending the customised message to the recipient terminal.

According to another aspect of the disclosure, there is provided a server, in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said server being configured for sending a customised message to the recipient terminal, the server comprising: a processor; and

computer program software code for providing to the sender mobile terminal a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

computer program software code for receiving from the sender mobile terminal a name of a user of the recipient terminal and a command selecting a pre-defined message;

computer program software code for receiving from the sender mobile terminal, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

computer program software code for assigning, to the content elements of the selected message, types based upon at least one of the received name of the recipient and the received gender information, to thereby construct the customised message; and computer program software code for sending the customised message to the recipient terminal.

According to another aspect of the disclosure, there is provided a computer readable storage medium comprising a program for execution by a processor in a sender mobile terminal, in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, the sender mobile terminal being configured for sending a customised message to the recipient terminal, the program comprising: computer program software code for requesting a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

computer program software code for outputting a name of a user of the recipient terminal and a command selecting a pre-defmed message;

computer program software code for outputting, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

computer program software code for receiving the customised message having content elements that have been assigned types based upon at least one of the outputted name of the recipient and the outputted gender information; and

According to another aspect of 'the disclosure, there is provided a computer readable storage medium comprising a program for execution by a processor in server, in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said server being configured for sending a customised message to the recipient terminal, the program comprising:

According to another aspect of the disclosure, there is provided a computer readable storage medium comprising a program for execution by a processor in a server, in a system comprising a sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and the server, communicating over a network, said program performing a method sending a customised message to the recipient terminal, the program comprising:

computer program software code for providing to the sender mobile terminal a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the predefined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

computer program software code for receiving from the sender mobile terminal a command selecting a pre-defined message, and a name and an address of the recipient; computer program software code for receiving from the sender mobile terminal, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient; computer program software code for receiving information from the sender mobile terminal, depending upon the identifier of the pre-defined message, said information specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient;

computer program software code for constructing the customised message wherein the gender of the singer of the song and the gender aura of the animated production is specified the received gender information; and

According to another aspect of the disclosure, there is provided a computer readable storage medium comprising a program for execution by a processor in a sender mobile terminal, in a system comprising the sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and a server, communicating over a network, said program performing a method for sending a customised message to the recipient terminal, the program comprising:

computer program software code for receiving from the server a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre-defined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

computer program software code for sending to the server a command selecting a predefined message, and a name and an address of the recipient; computer program software code, for sending to the server, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient;

computer program software code for sending to the server, depending upon the identifier of the pre-defined message, information specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient; and

computer program software code for arranging to send the customised message to the recipient terminal.

Other aspects of the invention are also disclosed .

Brief Description of the Drawings

At least one embodiment of the present invention will now be described with reference to the drawings, in which:

Fig. 1 is a functional block diagram of one example of a PMA arrangement;

Figs. 2A and 2B are flow charts showing process fragments depicting how the PMA arrangement of Fig. 1 sends a customised message;

Figs. 3A and 3B form a schematic block diagram of a general purpose computer system upon which the PMA arrangement of Fig. 1 can be practiced;

Fig. 4 is a flow chart showing a process of how the "record purchase/send" step of Fig. 2B can be performed;

Fig. 5 is a flow chart showing a process of how the PMA arrangement of Fig. 1 operates when a message is received in SMS form;

Fig. 6 is a flow chart showing a process of how the PMA arrangement of Fig. 1 operates when a message is received in email form; Fig. 7 shows a graphical user interface (GUI) and a file structure used in one example of the PMA arrangement of Fig. 1;

Fig. 8 depicts a GUI on the sender's mobile device relating to a message that can be customised but not personalized;

Fig. 9 depicts a GUI relating to a romantic message;

Fig. 10 depicts a GUI requesting gender information about the recipient;

Fig, 11 depicts a GUI requesting selection of a generic label for the recipient;

Fig. 12 depicts a GUI requesting gender information about the recipient;

Fig. 13 depicts a GUI asking how the recipient's name is pronounced;

Fig. 14 depicts a template used in the PMA arrangements by a user choosing between a personalized and a non-personalized ririgtone;

Figs. 15A and 15B depict GUIs used for constructing a personalized ringtone;

Figs. 16A and 16B show flow charts depicting process fragments of how the "select and customise/personalise card" step of Fig 2A can operate; and

Fig. 17 is a flow chart showing how the "received recipient first name input" step in Fig. 16A can operate.

Detailed Description including Best Mode

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears.

It is to be noted that the discussions contained in the "Background" section and the section above relating to prior art arrangements relate to discussions of devices which may form public knowledge through their use. Such discussions should not be interpreted as a representation by the present inventor or the patent applicant(s) that such documents or devices in any way form part of the common general knowledge in the art.

Fig. 1 is a functional block diagram of one example 100 of a PMA arrangement. The PMA system 100 comprises a server 101 communicating with a sender mobile terminal 5 109 and a recipient terminal 106 over a network 107, as depicted by respective arrows 105 and 1 15. The server 101 has a PMA server software application 102 which executes on a processor 103, and accesses a database 104 which, among other functions, acts as a repository for the pre-defined templates used as building blocks for construction of the customised messages. The sender terminal 109 has a PMA client software application

10 108 that , executes on a processor 1 12. The recipient terminal 106 has a browser or equivalent software application 1 1 1 that executes on a processor 1 14. A user of the sender mobile terminal is referred to hereinafter as the "sender". A user of the recipient terminal 106 is referred to hereinafter as the "recipient". The sender mobile terminal 109 is typically, but not necessarily, a smart phone. The recipient terminal 106 may be a smart

1 5 phone, or an older phone, or even a Personal Computer (PC).

In this specification, a reference to the server 101 is equivalent to a reference to the PMA server software application 102 unless otherwise indicated. Similarly, a reference to the sender's telephone 109 is equivalent to a reference to the PMA client software application 108 unless otherwise indicated. Similarly, a reference to the recipient terminal

20 106 is equivalent to a reference to the browser 1 1 1 unless otherwise indicated.

When the sender wishes to send a customised message to the recipient the sender communicates with the server 101 using his phone 109, and constructs the customised message. Having done so, the sender directs the server 101 to send the customised message to the recipient terminal 106. In ah alternate arrangement, having arranged with the server 101 to construct the customised message, the server 101 can send the customised message to the sender's phone 109, and the sender can then send it to the recipient terminal 106.

The messages in the PMA arrangements fall into two main categories as follows: 1. Non-personalized messages (which may be still images, animated videos, ringtones and the like)

2. Personalized messages:

a) With no choice for male/female singing voice; OR

b) With a choice for male or female singing voice, for example romantic songs. Special variations are handled at the production stage. Thus, for example, in the case of the 'Lounge' card within the 'Birthday' category, a male voice sings to female recipients, and a female voice sings to male recipients. The animations are also different depending on the gender of the recipient. Certain cards such as 'Rock God' and 'Good Looking' from the 'Fun' category are sung by a single voice, but have a different visual component depending on the gender of the recipient. The other main type of personalized card offers a choice of male or female voice; for example any card from the 'Romance' category.

In one example of a PMA arrangement, Jeff wishes to send a customised funny message to Felicity. Jeff executes (see 201 in Fig. 2) the PMA client application 108 on his phone 109, which then communicates with the server 101 and downloads a menu of pre-defined messages, as depicted at 701 in Fig, 7.

Jeff selects (see 1601 in Fig. 16A), as depicted by an arrow 702, a "Fun" icon and is then presented, on his phone 109, with a number of possible fun messages as depicted by a file structure 704. Jeff selects a "Gangsta Kid" message, which produces, as depicted by an arrow 705, a display of a pre-defined message template 800 in Fig. 8 on Jeffs phone 109.

The Gangsta Kid message comprises a non-personalized audio/animated video in MP4 format.

Jeff enters Felicity's address (see 1606 in Fig. 16A), either a phone number or email address, at 808. Felicity's addresses are already listed in the address book in Jeffs phone 109, and therefore Felicity's name rather than the address appears in the template at 808. Jeff, being the sender, has his name appear at 801.

Jeff can "customise" the message by inserting a greeting (see 1606 in Fig. 16A) to Felicity at 802, using a soft keyboard 801 which is displayed on his phone 109. Jeff may preview the message (see 215 in Fig. 2B) by selecting a "preview" button 806, or can send the message (see 223 in Fig. 2B) by pressing a "send" button 807. When Jeff presses the send button 807, the server 101 determines (see 401, 406 in Fig. 4) whether Jeff is sending the message to a phone or a PC, and sends the appropriate type of message. If the message is an email, the server 101 sends the email directly (see 403 in Fig. 4) to Felicity's PC 106. If the message is an SMS, the server 101 constructs the SMS and returns (see 408 in Fig. 4) this to Jeffs phone for him to send to Felicity's phone 106.

If Jeff wants, instead of a fun message to send a romantic message to Felicity, and does not want to identify himself as the sender, Jeff can select, as depicted by an arrow 706, a "Romance" icon from the menu at 700 in Fig. 7. This will cause a template 900 in Fig. 9 to be displayed on Jeffs phone 109.

An example of a Romance message comprises a personalized animated audio/video message for example "Get to know you". This message can be "personalized", which means that Jeff can incorporate Felicity's first name into the message, and he does so by inserting Felicity's first name (see 1613 in Fig. 16A) at 904. Jeff can also select (see 1618 in Fig. 16B) the gender of the singer who sings the message, and he does so by selecting a male singer at 902. Personalisation is a particular type of customisation, where the recipient's name or gender information is reflected in the message.

Some messages which can be personalized use singers whose gender is dependent upon the gender of the recipient. Such messages generate a template such as 1000 in Fig. 10 on the sender's phone 109. The sender can identify the gender of the recipient (see 1624 in Fig. 16B) by selecting a "girl" button 1001 or a "guy" button 1002.

An example of this type of function comprises a case in which the sender selects whether Alex is either a girl or a guy.

Some messages can be personalized by incorporating a generic name associated with the recipient if the name entered at the step 1613 is not available. Such messages generate a template such as 1 100 in Fig. 11 on the sender's phone 109. The sender can select one of the generic choices by selecting an appropriate button 1 101 , 1 102, 1 103 or 1 104 in order to insert (see 1703 in Fig. 17) the selected generic label into the message. Thus for example, selecting the button 1 102 will insert the word "brother" into the message. It is noted that the available generic names are determined by the message selected in the step 205 in Fig. 2A (also see the step 1602 in Fig. 16A).

An example of this type of function is where if an AO message (ie an "Adults Only") is selected, then the generic, names "Mum" and "Dad" will not be available.

Some recipient's names have different possible pronunciations. Such names generate a template such as 1300 in Fig. 13 on the sender's phone 109. The sender can select a location such as 1301 in Fig. 13 in order to insert (see 1709 in Fig. 17) the selected pronunciation into the message.

Many subtle variations are considered when personalising and then delivering messages in the PMA arrangements. Some variations are taken care of in the production phase. Thus, for example, a few romantic songs have slightly different lyrics when a male sings to a male compared to when a male sings to a female. The audio files are recorded and mixed audio appropriately for each name and case. The audio files are then combined with animations (which can also vary depending on the sex of the recipient).

Fig. 8 depicts a GUI on the sender's mobile device relating to a message that can be customised but not personalized. There are no fields in the template for personalizing the actual card, that is, there is no 'First name' field, nor are there choices for male voice/female voice. There is however provision for the sender to write a message to be delivered along with the card.

Fig. 9 depicts a GUI relating to a romantic message. The address of the recipient can be entered at 905, their first name at 904, for personalisation of the message, voice selection of the performer in the message is selected at 902 / 903.

Fig. 10 depicts a GUI requesting gender information, at 1001 or 1002 about the recipient. Fig. 11 depicts a GUI requesting selection of a generic label for the recipient, such as "baby" (at 1 102), "brother" (at 1 102), "mum" (at 1 104), or "sweetheart" (at 1 103).

Fig. 12 depicts a GUI requesting gender information about the recipient, at 1201 or 1202. - Fig. 13 depicts a GUI asking how the recipient's name is pronounced, one pronunciation being selectable at 1301, and an alternate pronunciation being selectable at 1302.

Fig. 14 depicts a template used in the PMA arrangements by a user choosing between a personalized and a non-personalized ringtone. In addition to animated message cards (being one form of customised / personalized message) the PMA arrangements also provide a range of Standard and Personalized ringtones. Standard ringtones are non- personalized, whereas Custom ringtones allow users to input a name, which has been seamlessly inserted into the recording. Fig. 14 shows the choices as they appear to the sender. Once the ringtone has been selected and previewed, the PMA arrangements allow the ringtone to be sent to any email address.

Figs. 15A and 15B depict GUIs used for constructing a personalized ringtone. Once the sender has requested a menu of available ringtones, made a selection and received a GUI 1500 for the selected ringtone, according to the respective steps 201 , 202 and 234 in Fig. 2, the GUI 1500 enables a user to enter, using a kepad 1503, a name for the recipient in a window 1501. Thereafter the sender can preview the personalized ringtone by pressing a key 1 502 and the entire personalized ringtone will be played by the sender's phone 109. The sender can then send the personalized ringtone to the recipient by pressing the key 1504, and the server will attach an M4R file, for example, to an email and send the email to the recipient. Alternately, a GUI 1550 enables the user to enter, using a kepad 1554, a name for the recipient in a window 1556. Thereafter the sender can preview the personalized ringtone by pressing a key 1555 and the entire personalized ringtone will be played by the sender's phone 109. The aforementioned preview can be paused by using a pause button 1552, and/or rewound by using a rewind button 1551. Once the user is satisfied, the sender can then send the personalized ringtone to the recipient by pressing a key 1553, and the server will attach an M4R file, for example, to an email and send the email to the recipient.

Figs. 2A and 2B are flow charts showing process fragments 200 and 200' respectively of how the PMA arrangement of Fig. 1 sends a customised message. The process steps in Figs. 2 A and 2B are arranged in two columns, under respective headings "client" and "server". This indicates that process steps arranged under the heading "client" are performed by the PMA client software application 108 executing on the sender mobile terminal 109, The process steps arranged under the heading "server" are performed by the PMA server software application 102 executing on the server 101.

The process 200 commences with a step 201 in which the sender's telephone

109, after receiving an input from the sender as depicted by dashed arrow 233, sends a request to the server 101 for a list of animated songs, cards, messages, greetings and ring tones (all being referred to as "messages" unless otherwise specified). The process 200 then follows an arrow 202 to a step 203 in which the server 101 returns a categorised list of pre-defined messages to the sender's phone 109. This list may be provided in different forms, one of which is depicted in Fig. 7 as a graphical user interface (GUI) 701.

The process 200 then follows an arrow 204 to a step 205. In the step 205, the sender's telephone 109, directed by the sender as depicted by a dashed arrow 234, selects and customises and/or personalises a particular message selected from the list. This is described hereinafter in more detail with reference to Figs. 16A, 16B and Fig. 17.

As noted previously in regard to the examples briefly described above, a "customised" message is a message which the sender can amend in order to reflect the intended recipient in some way. One type of customisation is referred to as "personalisation" in which the name and/or gender of the intended recipient is incorporated in the message. Another form of customisation is inclusion of a message (being a message of some form such as "Hi Joe - hope you enjoyed the party!) in the message.

The process 200 then follows an arrow 210 to a step 211. In the step 21 1 the server 101 returns a preview URL and key to the sender's phone 109, enabling the message to be sent to the recipient if the sender wishes to do so. The process 200 then follows an arrow 212 to a decision step 213.

Returning to the step 213, in this step the sender's phone 109 determines, based upon an input from the sender depicted by a dashed arrow 235, whether a preview of the customised message is desired. If this is the case, then the process 200 follows a YES arrow 214 to a step 215 in Fig. 2B. If, on the other hand, a preview is not desired, then the process 200 follows a NO arrow 229 to a step 221 in Fig. 2B.

Fig. 2B shows a second process fragment 200' which commences, if the sender desires a preview, with a step 215 in which the sender's phone 109, directed by the sender as depicted by dashed arrow 236, sends a preview request to the server 101. The process fragment 200' then follows 216 to a step 217. In the step 217, the server 101 sends a message to the client for preview. The process fragment 200' then follows an arrow 218 to a step 219. In the step 219, the sender previews the customised message on the sender's phone 109.

If a name has been entered in the 'First name' field within a template (eg at 904 in Fig. 9), a 'Preview' button 906 can play the personalized animation. However, when no name has been entered in the 'First name' field, there is a special 'preview' version for each card. This is the same animation but with a spoken audio clip stating "name goes here" where the name would usually be heard. If the animation is different for male and female recipients, such as 'Rock God' from the 'Fun' category, then the sender is asked to specify the gender of the recipient. If the animation differs for male and female recipients, or the card can be simg by male voice or female voice, the preview reflects this, prompting a choice by the sender.

Having completed the preview, the process fragment 200' follows an arrow 220 to a decision step 221. In the decision step 221 the sender's phone 109 determines, according to an input from the sender as depicted by a dashed arrow 237, whether the sender wishes to send the customised message to the intended recipient. If the sender wishes to send the customised message, then the process fragment 200' follows a YES arrow 222 to a step 223. In the step 223 the sender's telephone sends a "send" command to the server 101 with a key associated with the particular customised message. The process fragment 200' then follows an arrow 231 to a step 224.

In the step 224 the server 101 records a purchase, reflecting that the sender pays for the message, and sends the customised message the recipient terminal 106. This is described in more detail hereinafter with reference to Fig. 4. The process 200' then follows an arrow 232 to an end step 225. Returning to -the decision step 221, if the sender does not wish to send the customised message for some reason, then the sender indicates this preference as depicted by the dashed arrow 237, and the process fragment 200' follows a NO arrow 230 back to the step 205 in Fig. 2A.

Figs. 3A and 3B depict a general-purpose computer system 300, upon which the various arrangements described can be practiced.

Although the following description is directed primarily to the server 101, the sender's telephone 109 and the recipient's terminal 106 have similar structural and functional features, and accordingly the following description applies to those devices with appropriate amendments. Furthermore, references in the following description to the PMA server software application 102 should be understood, where appropriate, as being directed to the PMA server software application 102 and/or the PMA client software application 108 and/or the browser 1 1 1, interoperating as appropriate.

As seen in Fig. 3A, the computer system 300 includes: a computer module 301 ; input devices such as a keyboard 302, a mouse pointer device 303, a scanner 326, a camera 327, and a microphone 380; and output devices including a printer 315, a display device 314 and loudspeakers 317. An external Modulator-Demodulator (Modem) transceiver device 316 may be used by the computer module 301 for communicating to and from the sender's telephone 109 and the recipient's terminal 106 over a communications network 107 via a connection 321 , The communications network 107 may be a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN. Where the connection 321 is a telephone line, the modem 316 may be a traditional "dial-up" modem. Alternatively, where the connection 321 is a high capacity (e.g., cable) connection, the modem 316 may be a broadband modem. A wireless modem may also be used for wireless connection to the communications network 107.

The computer module 301 typically includes at least one processor unit 103, and a memory unit 306. For example, the memory unit 306 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM). The computer module 301 also includes an number of input/output (I/O) interfaces including: an audio- video interface 307 that couples to the video display 314, loudspeakers 317 and microphone 380; an I/O interface 313 that couples to the keyboard 302, mouse 303, scanner 326, camera 327 and optionally a joystick or other human interface device (not illustrated); and an interface 308 for the external modem 316 and printer 315. In some implementations, the modem 316 may be incorporated within the computer module 301 , for example within the interface 308. The computer module 301 also has a local network interface 311 , which permits coupling of the computer system 300 via a connection 323 to a local-area communications network 322, known as a Local Area Network (LAN). As illustrated in Fig. 3A, the local communications network 322 may also couple to the wide network 107 via a connection 324, which would typically include . a so-called "firewall" device or device of similar functionality. The local network interface 311 may comprise an Ethernet ^rM circuit card, a Bluetooth ^rM wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practiced for the interface 31 1 .

The I/O interfaces 308 and 313 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated). Storage devices 104 are provided and typically include a hard disk drive (HDD) 310. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used. An optical disk drive 312 is typically provided to act as a non-volatile source of data. Portable memory devices, such optical disks (e.g., CD-ROM, DVD, Blu-ray Disc™), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 300.

The components 103, 313, 306, 312, 307, 308, 31 1 and 104 of the computer module 301 typically communicate via an interconnected bus 304 and in a manner that results in a conventional mode of operation of the computer system 300 known to those in the relevant art. For example, the processor 103 is coupled to the system bus 304 using a connection 318. Likewise, the memory 306 and optical disk drive 312 are coupled to the system bus 304 by connections 319. Examples of computers on which the described arrangements can be practised include IBM-PC's and compatibles, Sun Sparcstations, Apple Mac™ or a like computer systems.

The PMA method may be implemented using the computer system 300 wherein the processes of Figs. 2A, 2B, 4-6, 16A, 16B and 17 may be implemented as one or more software application programs 102, executable within the computer system 300. Reference to the software 102 can be understood to refer to the software 102 operating in concert with one or more software application programs 108, executable in the sender's telephone 109, and one or more software application programs 1 1 1, executable in the recipient's terminal 106, unless otherwise specified.

Accordingly, the steps of the PMA method are effected by instructions 331 (see Fig. 3B) in the software 102 that are carried out within the computer system 300. The software instructions 331 may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the PMA methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software may be stored in a computer readable medium, including the storage devices described below, for example. The software is loaded into the computer system 300 from the computer readable medium, and then executed by the computer system 300. A computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product. The use of the computer program product in the computer system 300 preferably effects an^■ advantageous apparatus for effecting the PMA arrangements.

The software 102 is typically stored in the HDD 310 or the memory 306. The software is loaded into the computer system 300 from a computer readable medium, and executed by the computer system 300. Thus, for example, the software 102 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 325 that is read by the optical disk drive 312. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer system 300 preferably effects an apparatus for effecting the PMA arrangements.

In some instances, the application programs 102 may be supplied to the user encoded on one or more CD-ROMs 325 and read via the corresponding drive 312, or alternatively may be read by the user from the networks 107 or 322. Still further, the software can also be loaded into the computer system 300 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the. computer system 300 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD- ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 301. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 301 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.

The second part of the application programs 102 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 314. Through manipulation of typically the keyboard 302 and the mouse 303, a user of the computer system 300 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via the loudspeakers 317 and user voice commands input via the microphone 380.

Fig. 3B is a detailed schematic block diagram of the processor 103 and a

"memory" 334. The memory 334 represents a logical aggregation of all the memory modules (including the HDD 104 and semiconductor memory 306) that can be accessed by the computer module 301 in Fig. 3A. When the computer module 301 is initially powered up* a power-on self-test (POST) program 350 executes. The POST program 350 is typically stored in a ROM 349 of the semiconductor memory 306 of Fig. 3A. A hardware device such as the ROM 349 storing software is sometimes referred to as firmware. The POST program 350 examines hardware within the computer module 301 to ensure proper functioning and typically checks the processor 103, the memory 334 (104, 306), and a basic input-output systems software (BIOS) module 351, also typically stored in the ROM 349, for correct operation. Once the POST program 350 has run successfully, the BIOS 351 activates the hard disk drive 310 of Fig, 3 A. Activation of the hard disk drive 310 causes a bootstrap loader program 352 that is resident on the hard disk drive 310 to execute via the processor 103. This loads an operating system 353 into the RAM memory 306, upon which the operating system 353 commences operation. The operating system 353 is a system level application, executable by the processor 103, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.

The operating system 353 manages the memory 334 (104, 306) to ensure that each process or application running on the computer module 301 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 300 of Fig. 3 A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 334 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 300 and how such is used. As shown in Fig. 3B, the processor 103 includes a number of functional modules including a control unit 339, an arithmetic logic unit (ALU) 340, and a local or internal memory 348, sometimes called a cache memory. The cache memory 348 typically includes a number of storage registers 344 - 346 in a register section. One or more internal busses 341 functionally interconnect these functional modules. The processor 103 typically also has one or more interfaces 342 for eommunicating with external devices via the system bus 304, using a connection 318. The memory 334 is coupled to the bus 304 using a connection 319.

The application program 102 includes a sequence of instructions 331 that may include conditional branch and loop instructions. The program 102 may also include data 332 which is used in execution of the program 102. The instructions 331 and the data 332 are stored in memory locations 328, 329, 330 and 335, 336, 337, respectively. Depending upon the relative size of the instructions 331 and the memory locations 328-330, a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 330. Alternately, an instruction may be segmented into a number of parts each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 328 and 329.

In general, the processor 103 is given a set of instructions which are executed therein. The processor 1 105 waits for a subsequent input, to which the processor 103 reacts to by executing another set of instructions. Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 302, 303, data received from an external source across one of the networks 107, 302, data retrieved from one of the storage devices 306, 104 or data retrieved from a storage medium 325 inserted into the corresponding reader 312, all depicted in Pig. 3A. The execution of a set of the instructions may in some cases result in output of data. Execution may also involve storing data or variables to the memory 334.

The disclosed PMA arrangements use input variables 354, which are stored in the memory 334 in corresponding memory locations 355, 356, 357. The PMA arrangements produce output variables 361, which are stored in the memory 334 in corresponding memory locations 362, 363, 364. Intermediate variables 358 may be stored in memory locations 359, 360, 366 and 367.

Referring to the processor 103 of Fig. 3B, the registers 344, 345, 346, the arithmetic logic unit (ALU) 340, and the control unit 339 work together to perform sequences of micro-operations needed to perform "fetch, decode, and execute" cycles for every instruction in the instruction set making up the program 102. Each fetch, decode, and execute cycle comprises:

(a) a fetch operation, which fetches or reads an instruction 331 from a memory location 328, 329, 330;

(b) a decode operation in which the control unit 339 determines which instruction has been fetched; and

(c) an execute operation in which the control unit 339 and/or the ALU 340 execute the instruction.

Thereafter, a further fetch, decode, and execute cycle for the next instruction may be executed. Similarly, a store cycle may be performed by which the control unit 339 stores or writes a value to a memory location 332.

Each step or sub-process in the processes of Figs. 2A, 2B, 4-6, 16A, 16B and 17 is associated with one or more segments of the program 102 and is performed by the register section 344, 345, 347, the ALU 340, and the control unit 339 in the processor 103 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 102.

The PMA method may alternatively be implemented in dedicated hardware such as one or more integrated circuits performing the PMA functions or sub functions. Such dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.

Fig. 4 is a flow chart of the process 224 showing how the "record purchase/send" step of Fig. 2B operates. The process 224 in Fig. 4 is entered by an arrow 231 which is directed to a step 401. In the step 401 the server 101 determines if the destination address of the recipient is an email address. If this is the case, then the process 224 follows a YES arrow 402 to a step 403 in which the server 101 constructs and sends the email to the recipient terminal 106. The process 224 then follows an arrow 404 to the END step 225 in Fig. 2B.

Returning to the decision step 401, if the server 101 determines that the destination address is not an email address, the process 224 follows a NO arrow 405 to a decision step 406. In the step 406, the server 101 determines if the destination is a phone number. If this is the case, then the process 224 follows a YES arrow 407 to a step 408. In the step 408 the server 101 constructs, from the customised message, the body of a Short Message Service message (SMS), and returns this to the sender's phone 109 for sending to the recipient at the sender's expense. The process 224 then follows the arrow 232 to the END step 225 in Fig. 2B.

Returning to the decision step 406, if the server 101 determines that the destination is not a phone number, then the process 224 follows a NO arrow 409 to a step 410 which constitutes an error condition. Thus for example if an entered phone number contains an illegal character, then the user is given an alert message and asked to re-enter the phone number.

Fig. 5 is a flow chart showing how the PMA arrangement of Fig. 1 operates when a message is received in SMS form. Fig. 5 relates to the situation in which the recipient terminal 106 receives a customised message in the form of an SMS. Process steps in Fig. 5 are arranged in two columns, underneath respective headings "recipient" and "server". Those process steps under the heading "recipient" are processed steps performed by the recipient terminal 106. Process steps located under the heading "server" are performed by the server 101.

The process 500 commences with a decision step 502 in which the recipient terminal 106 determines if an SMS has been received. If this is not the case, then the process 500 follows a NO arrow 501 back to the step 502 in a looping fashion. If, on the other hand, an SMS has been received, then the process 500 follows a YES arrow 503 to a step 504.

If the sender has entered a custom message, the SMS takes the following form:

" <custom message> You have received a NameTonz animated message. Click www.nametonz.com/?c=XXXXX

or visit nametonz.com and enter XXXXX"

If there is no custom message, then there are two cases:

a) If the sender has put their name in the 'From' field within the app, the SMS takes the following form:

"<recipient>, <sender> has sent you a NameTonz animated message. Click www.nametonz.com/?c=^;XXXXX or

visit nametonz.com and enter XXXXX" b) If the sender has left the 'From' field blank, the SMS takes the following form:

"<recipient>, you have received a NameTonz animated message. Click www.nametonz.com/^c^XXXXX or visit

nametonz.com and enter XXXXX"

There is no such thing as a truly anonymous SMS message, because the SMS comes straight from the sender's phone 109, This means that the recipient will always see the sender's number or their name if they are already a contact.

Returning to Fig. 5, the recipient, as depicted by a dashed arrow 517, directs the recipient terminal 106, in the step 504, to "select a link" in the received SMS if the recipient terminal 106 is capable of doing so. If the recipient terminal 106 is a relatively modern "smart phone", then it is possible to have hyperlinks embedded in received SMSs. If, on the other hand, the recipient terminal 106 is an older mobile phone then hyperlinks cannot be embedded in received SMSs. Accordingly, in the step 504 the recipient is able to either select a link, if a hyperlink is embedded in the SMS or alternatively, can send a manual code which is incorporated into the SMS, back to the server 101. This code includes sufficient information about the recipient terminal 106 to enable the server to take the appropriate action.

The process 500 then follows an arrow 505 to a decision step 51 1. In the step 51 1 the server 101 determines whether the recipient terminal 106 is a known smart phone, or an unknown, and likely "older" phone. The term "known smart phone" reflects the fact that the server 101 has information on a number of smart phones, and is able to construct a suitable web delivery page for forwarding to the recipient terminal 106. If the decision step 51 1 returns a TRUE result, then the process 500 follows an "known smart phone" arrow 512 to a step 513. In the step 513 the server, consulting its information about the particular smart phone 106 being used by the recipient, constructs and returns a corresponding web delivery page to the recipient terminal 106. The process 500 then follows an arrow 514 to a step 506. In the step 506, the recipient terminal 106 receives the web delivery page, and the process 500 follows an arrow 507 to a step 508 in which the recipient terminal 106 displays the web page. The process 500 then follows an arrow 509 to a step 510 in which the recipient, as depicted by a dashed arrow 518, directs the recipient terminal 106 to activate a "view it now" button. Thereafter, the customised message is executed, typically presenting an animated display including customised voice and animation elements on the recipient's phone 106.

Returning to the decision step 51 1 , if the server 101 determines that the recipient terminal 106 is an unknown or old phone, the process 500 follows an arrow 515 to a step 516. In the step 516, the server 101 sends an SMS to the recipient terminal 106. The SMS instructs the recipient to navigate to the server web page over the internet, and to enter a five letter code in order to retrieve their customised web page. The process 500 then follows an arrow 519 to a step 520 in which the server 101 constructs the customised message on a web page hosted by the server 101, ready for the recipient to access using a PC (not shown).

Fig. 6 is a flow chart showing how the PMA arrangement of Fig. 1 operates when a message is received in email form. The process 600 commences with a step 602 in which the recipient terminal 106 determines if an email has been received or not. If an email has not been received, then the process 600 follows a NO arrow 601 back to the step 602 in a looping fashion. If, on the other hand, an email has been received then the process 600 follows a YES arrow 603 to a step 604. The sender can choose to send a message to an email address. They do this either by entering the email address directly in the 'To' field within the app, or by choosing an email address from the dropdown contacts list.

The email is delivered from our server so it comes from no- reply@nametonz.com (just like ringtones). If the sender has entered their email address as a setting (under the 'Settings' icon within the app), then that becomes the return address.

If the sender has entered a custom message, the email takes the following form: "<custom message> You have received a NameTonz animated message. Click on www.nametonz.com/7c-XXXXX to view your card.

In this case the sender may remain anonymous if they choose.

If there is no custom message, there are two cases:

a) If the sender has put their name in the 'From' field within the iPhone app, the email takes the following form:

"<recipient>, <sender> has sent you a NameTonz animated message. Click on www.nametonz.com/?c=XXXXX to view your card.

b) If the sender has left the 'From' field blank, the email remains anonymous and takes the following form:

"<recipient> you have received a NameTonz animated message. Click on www.nametonz.com/?c=XXXXX to view your card.

Returning to Fig. 6, in the step 604, the recipient terminal 106, in accordance with an input from the recipient depicted by a dashed arrow 613, selects a hyperlink embedded in the received email. The recipient terminal 106 sends a request to the server

1* 101 including a recipient platform identifier, enabling the server 101 to make decisions based upon the type of the recipient platform 106.

The process 600 then follows an arrow 605 to a step 61 1. In step 61 1 the server 101 returns a corresponding web delivery page to the recipient terminal 106, and the process 600 follows an arrow 612 to a step 606. In the step 606 the recipient terminal 106 receives the web delivery page, and the process 600 follows an arrow 607 to a step 608. In the step 608, the recipient terminal 106 displays the web page, and the process 600 then follows an arrow 609 to a step 610. In the step 610, the recipient terminal 106, as directed by a dashed arrow 614 from the recipient, selects a "view it now" button in the displayed web page, thus activating the received customised message.

Figs. 16A and 16B show flow charts of process fragments 205 and 205' depicting the "select and customise/personalise card" step 205 of Fig 2A in more detail.

Turning to Fig. 16A, the process 205 commences with a step 1602. In the step 1602, the sender's telephone 109, according to an input from the sender depicted by a dashed arrow 1601 , receives a selection command. The process 205 then follows an arrow 1603 to a decision step 1604 in which the server 101 determines if the selected card can be personalized. If this is the case, then the process 205 follows a YES arrow 1609 to a step 1610. In the step 1610 the sender's phone 109, directed by an input from the sender depicted by a dashed arrow 161 1, receives information about the recipients address. The process 205 then follows an arrow 1612 to a step 1613. In the step 1613, the sender's phone 109, directed by the sender as depicted by a dashed arrow 1614, receives a first name for the intended recipient. The process 205 then follows an arrow 1615 to a step 1616 in Fig. 16B. Returning to the decision step 1604, if the selected card can not be personalized, then the process 205 follows a NO arrow 1605 to a step 1606 in which the sender's phone 109, directed by an input from the sender depicted by a dashed arrow 1607, receives the address of the intended recipient, and, possibly, an additional message to be sent to the recipient. The process 205 then follows the arrow 206 to the step 207 in Fig. 2A.

Turning to Fig. 16B, the process 205' commences with a decision step 1616 in which the server 101 determines whether the card selected by the sender has male/female singing voice options. If this is the case, then the process 205' follows a YES arrow 1617 to a step 1618. In the step 1618 the sender's phone 109, directed by the sender as depicted by a dashed arrow 1619, receives a selection command choosing either a male or a female voice, (ie the voice is classified as being either a male "type" or a female "type") and sends this to the server 101. The process fragment 205' then follows an arrow 1620 to a step 1634 which constructs the personalized message according to the aforementioned information inputs.

Returning to the decision step 1616, if the selected card does not have male/female singing voice options, then the process fragment 205' follows a NO arrow 1621 to a decision step 1622. In the step 1622 the server 101 determines whether the selected message has different voice options for male/female recipients. If this is the case, then the process fragment 205' follows a YES arrow 1623 to a step 1624. In the step 1624 the sender's telephone 109, instructed by the sender as depicted by a dashed arrow 1625, receives indication of the gender of the intended recipient, (ie the recipient is classified as being either a male "type" or a female "type"). The process fragment 205' then follows an arrow 1626 to the step 1634. Returning to the decision step 1622, if the selected card does not have different voice Options for male/female recipients, then the process fragment 205' follows a NO arrow 1627 to a decision step 1628. In the step 1628, the server 101 determines if the selected card has different animation options for- male/female recipients, ie whether an animation having a male "aura" is used for a male recipient, and an animation having a female "aura" is used for a female recipient. If this is the case, then the process fragment 205' follows a YES arrow 1629 to a step 1631. In the step 1631 the sender's telephone 109, directed by the sender as depicted by a dashed arrow 1632, receives gender selection information for the intended recipient, (ie the recipient is classified as being either a male "type" or a female "type"). The process fragment 205' then follows an arrow 1633 to the step 1634. If, however, the decision step 1628 determines that the selected card does not have different animations for male/female recipients, then the process fragment 205' follows a NO arrow 1630 to the step 1634.

From the step 1634, the process fragment 205' follows the arrow 206 from the step 1634 to the step 207 in Fig. 2 A.

Fig. 17 is a flow chart of the process 1613 showing how the "receive recipient first name input" step 1613 in Fig. 16A operates, in more detail. The process 1613 commences with a decision step 1701 in which the server 101 determines if the name selected by the sender is available for the selected message. If this is the case, then the process 1613 follows a YES arrow 1706 to a decision step 1707. In the step 1707 the server 101 determines if a number of pronunciations are available for the recipient's name selected by the sender, (ie the recipient's name is classified as being either a single pronunciation "type" or a multi-pronunciation "type"). If this is the case, then the process 1613 follows a YES arrow 1708 to a step 1709. The PMA arrangements make provision for alternate phonetic pronunciation of particular names. Accordingly, in the step 1709, the server 101 displays a number of pronunciation options on the sender's telephone 109 which receives, from the sender as depicted by a dashed arrow 1710, a selection from one of these displayed pronunciations and conveys this selection information to the serverlOl . The process 1613 is. then directed, as indicated by an arrow 171 1 , to a decision step 1713.

Returning to the decision step 1707, if only one pronunciation is available for the selected name, then the process 1613 follows a NO arrow 1712 to the decision step 1713. In the step 1713, the server 101 determines if the selected name is a unisex name. If this is the case, then the process 1613 follows a YES arrow 1714 from the step 1713 to a step 1716.

In the case of a unisex name, the PMA arrangement recognizes that may be a choice to be made by the sender regarding the gender of the recipient. For a card such as 'Country' from the 'Birthday' category, no special handling is required for unisex names because there is no difference in audio or visual content, when the song is sung to a male or female. By contrast, 'Rock God' from the 'Fun' category has identical audio for unisex names. The message is always sung by a male voice and the same lyrics are used for male and female recipients, however, the animation varies depending on the sex of the recipient.

Depending upon the selected message, in the step 1716 the server 101 requests, on the sender's telephone 109, a gender selection from the sender. The sender's telephone receives, according to an input from the sender as depicted by a dashed arrow 1715, a gender selection input, and conveys this to the server 101. The process 1613 then follows an arrow 1615 to the step 1616 in Fig. 16B. Returning to the decision step 1713, if the name is not a unisex name, then the process 1613 follows a NO arrow 1717 to the step 1616 in Fig. 16B.

Returning to the decision step 1707, if the selected name is not available for the selected message, then the process 1613 follows a NO arrow 1702 to a step 1703, (ie the selected name is classified as being either an available "type" or a generic "type").

Accordingly, if a particular name is not present in the PMA arrangement memory, the sender is directed to a selection of generic options such as 'lover', 'friend', 'mum' etc. The list is different for each animated message.

In the step 1703^' the server 101 displays, on the sender's phone 109, a number of generic name options and requests an input selection from the sender. The sender's phone 109 receives, from the sender as depicted by a dashed arrow 1704, a selection of one of the generic options and conveys this to the server 101. The process 1613 then follows an arrow 1705 to the step 1616 in Fig. 16B.

Industrial Applicability

The arrangements described are applicable to the computer and data processing industries and particularly for the personal communications market.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

Claims

CLAIMS:

1. A method, performed by a server, in a system comprising a sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and the server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

providing to the sender mobile terminal a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre-defined message, a singer of the song ca be male or female and the animated production can have a male aura or a female aura;

receiving from the sender mobile terminal, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient;

receiving information from the sender mobile terminal, depending upon the identifier of the pre-defined message, said information specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient;

sending the customised message to the recipient terminal.

2. A method, performed by a sender mobile terminal, in a system comprising the sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

sending to the server, if the name of the recipient has a number of possible pronunciations, a command dependent upon an input from the sender selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient; sending to the server, depending upon the identifier of the pre-defined message, information dependent upon an input from the sender specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient; and sending the customised message to the recipient terminal.

3. A method, in a system comprising a sender mobile terminal, a recipient terminal, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

providing by the server to the sender mobile terminal a menu of pre-defined messages having content elements that can be assigned one of a plurality of types ; receiving by the server from the sender mobile terminal a name of a user of the recipient terminal and a command selecting a pre-defined message;

receiving by the server from the sender mobile terminal, depending upon the content elements of the selected pre-defined message, gender information relating to at least one of the user and the content elements of the selected message;

assigning by the server, to the content elements of the selected .message, types based upon at least one of the received name of the recipient and the received gender information, to thereby construct the customised message; and

sending the customised message to the recipient terminal.

4. A method, performed by a sender mobile terminal in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, said method sending a customised message to the recipient terminal, the method comprising the steps of:

requesting from the server a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

outputting to the server a name of a user of the recipient terminal and a command selecting a pre-defined message;

receiving from the server the customised message having content elements that have been assigned types based upon at least one of the outputted name of the recipient and the outputted gender information; and sending the customised message to the recipient terminal.

5. A method, performed by a server in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said

5 method sending a customised message to the recipient terminal, the method comprising the steps of;

receiving from the sender mobile terminal a name of a user of the recipient terminal and 10. a command selecting a pre-defined message;

assigning, to the content elements of the selected message, types based upon at least one 15 of the received name of the recipient and the received gender information, to thereby construct the customised message; and

sending the^' customised message to the recipient terminal.

6. A method according to claim 5, wherein:

20 a first content element of the selected message is the voice of a song to be sung in the customised message; and

the voice can be assigned one of a first type being male, and a second type being female; and wherein

a second content element of the selected message is an animation; and the animation can be assigned one of a first type being a male aura and a second type being a female aura; and wherein

a third content element of the selected message is a first name of the recipient; and the first name can be assigned one of a first type being a first name that is known to the server, and a second type being a generic name when the first name of the recipient is not known to the server.

7. A sender mobile terminal, in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, the sender mobile terminal being configured for sending a customised message to the recipient terminal, the sender mobile terminal comprising:

a processor; and

computer program software code for receiving from the server the customised message having content elements that have been assigned types based upon at least one of the outputted name of the recipient and the outputted gender information; and computer program software code for sending the customised message to the recipient terminal. ^"

8. A server, in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said server being configured for sending a customised message to the recipient terminal, the server comprising:

a processor; and

9. A computer readable storage medium comprising a program for execution by a processor in a sender mobile terminal, in a system comprising the sender mobile terminal, a recipient terminal, and a server, communicating over a network, the sender mobile terminal being configured for sending a customised message to the recipient terminal, the program comprising:

computer program software code for requesting a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

computer program software code for outputting a name of a user of the recipient terminal and a command selecting a pre-defined message;

10. A computer readable storage medium comprising a program for execution by a processor in server, in a system comprising a sender mobile terminal, a recipient terminal, and the server, communicating over a network, said server being configured for sending a customised message to the recipient terminal, the program comprising: computer program software code for providing to the sender mobile terminal a menu of pre-defined messages having content elements that can be assigned one of a plurality of types;

.

1 1. A computer readable storage medium comprising a program for execution by a processor in a server, in a system comprising a sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and the server, communicating over a network, said program performing a method sending a customised message to the recipient terminal, the program comprising:

computer program software code for providing to the sender mobile terminal a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre- defined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

computer program software code for receiving from the sender mobile terminal a command selecting a pre-defined message, and a name and an address of the recipient; 5 computer program software code for receiving from the sender mobile terminal, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient;

computer program software code for receiving information from the sender 10 mobile terminal, depending upon the identifier of the pre-defined message, said information specifying at least one of the gender of the singer, the gender of the sender and the gender of the recipient;

computer program software code for constructing the customised message wherein the gender of the singer of the song and the gender aura of the animated production is 15 specified the received gender information; and

20 12. A computer readable storage medium comprising a program for execution by a processor in a sender mobile terminal, in a system comprising the sender mobile terminal for use by a sender, a recipient terminal for use by a recipient, and a server, communicating over a network, said program performing a method for sending a customised message to the recipient terminal, the program comprising: computer program software code for receiving from the server a menu of pre-defined messages each having an identifier and each comprising at least one of a song and an animated video production wherein, depending upon the identifier of the pre-defined message, a singer of the song can be male or female and the animated production can have a male aura or a female aura;

computer program software code for sending to the server a command selecting a predefined message, and a name and an address of the recipient;

computer program software code for sending to the server, if the name of the recipient has a number of possible pronunciations, a command selecting, from a list, a pronunciation matching a preferred pronunciation of the name of the recipient;