+

WO2013037007A1 - Système de messagerie - Google Patents

Système de messagerie Download PDF

Info

Publication number
WO2013037007A1
WO2013037007A1 PCT/AU2012/001106 AU2012001106W WO2013037007A1 WO 2013037007 A1 WO2013037007 A1 WO 2013037007A1 AU 2012001106 W AU2012001106 W AU 2012001106W WO 2013037007 A1 WO2013037007 A1 WO 2013037007A1
Authority
WO
WIPO (PCT)
Prior art keywords
message
recipient
server
sender
mobile terminal
Prior art date
Application number
PCT/AU2012/001106
Other languages
English (en)
Inventor
Jeff LENHAM
Original Assignee
Bopcards Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2011903823A external-priority patent/AU2011903823A0/en
Application filed by Bopcards Pty Ltd filed Critical Bopcards Pty Ltd
Publication of WO2013037007A1 publication Critical patent/WO2013037007A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L51/00—User-to-user messaging in packet-switching networks, transmitted according to store-and-forward or real-time protocols, e.g. e-mail
    • H04L51/06—Message adaptation to terminal or network requirements
    • H04L51/063—Content adaptation, e.g. replacement of unsuitable content
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements
    • H04W4/14—Short messaging services, e.g. short message services [SMS] or unstructured supplementary service data [USSD]

Definitions

  • 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.
  • PMA Personalized Message Arrangements
  • 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.
  • 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:
  • 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;
  • 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:
  • 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;
  • a sender mobile terminal 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:
  • 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:
  • 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:
  • 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 computer readable storage medium comprising a program for execution on the processor, the program comprising;
  • 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
  • a computer readable storage medium comprising a program for execution on the processor, the program comprising;
  • 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;
  • 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:
  • 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:
  • 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 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;
  • 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;
  • GUI graphical user interface
  • 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;
  • Fig. 17 is a flow chart showing how the "received recipient first name input" step in Fig. 16A can operate.
  • 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
  • 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 phone.
  • a reference to the server 101 is equivalent to a reference to the PMA server software application 102 unless otherwise indicated.
  • a reference to the sender's telephone 109 is equivalent to a reference to the PMA client software application 108 unless otherwise indicated.
  • the sender 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.
  • Non-personalized messages (which may be still images, animated videos, ringtones and the like)
  • the Gangsta Kid message comprises a non-personalized audio/animated video in MP4 format.
  • 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.
  • 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.
  • 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 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, 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.
  • 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.
  • selecting the button 1 102 will insert the word "brother" into the message.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • the GUI 1500 enables a user to enter, using a kepad 1503, a name for the recipient in a window 1501.
  • 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.
  • 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
  • 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.
  • GUI graphical user interface
  • the process 200 then follows an arrow 204 to a 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.
  • 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.
  • 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.
  • 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.
  • the server 101 sends a message to the client for preview.
  • the process fragment 200' then follows an arrow 218 to a step 219.
  • the sender previews the customised message on the sender's phone 109.
  • a 'Preview' button 906 can play the personalized animation.
  • 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.
  • 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.
  • the process fragment 200' follows an arrow 220 to a 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • WAN wide-area network
  • the modem 316 may be a traditional "dial-up" modem.
  • 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.
  • 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.
  • 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).
  • LAN Local Area Network
  • 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 DiscTM), 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.
  • the processor 103 is coupled to the system bus 304 using a connection 318.
  • 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 MacTM 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.
  • 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.
  • 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.
  • 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.
  • GUIs graphical user interfaces
  • 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
  • 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.
  • 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.
  • BIOS basic input-output systems software
  • 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.
  • 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.
  • ALU arithmetic logic unit
  • 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.
  • a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 330.
  • 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.
  • 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.
  • each fetch, decode, and execute cycle comprises:
  • a further fetch, decode, and execute cycle for the next instruction may be executed.
  • 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.
  • 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.
  • 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.
  • the process 224 follows a NO arrow 405 to a decision 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.
  • 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.
  • SMS Short Message Service
  • 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.
  • a step 410 which constitutes an error condition.
  • 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.
  • the SMS takes the following form:
  • the SMS takes the following form:
  • 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.
  • the recipient 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.
  • 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.
  • 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.
  • the customised message is executed, typically presenting an animated display including customised voice and animation elements on the recipient's phone 106.
  • the process 500 follows an arrow 515 to a 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.
  • the email takes the following form: " ⁇ custom message> You have received a NameTonz animated message. Click on www.nametonz.com/7c-XXXX to view your card.
  • the sender may remain anonymous if they choose.
  • 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.
  • 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.
  • step 606 the recipient terminal 106 receives the web delivery page, and the process 600 follows an arrow 607 to a step 608.
  • step 608 the recipient terminal 106 displays the web page, and the process 600 then follows an arrow 609 to a 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.
  • the process 205 commences with a step 1602.
  • the sender's telephone 109 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the process fragment 205' follows a NO arrow 1621 to a decision 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.
  • 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.
  • the process fragment 205' follows a NO arrow 1627 to a decision 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.
  • 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.
  • 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").
  • the process 1613 follows a YES arrow 1708 to a step 1709.
  • the PMA arrangements make provision for alternate phonetic pronunciation of particular names.
  • 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.
  • the process 1613 follows a NO arrow 1712 to the decision 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.
  • the PMA arrangement recognizes that may be a choice to be made by the sender regarding the gender of the recipient.
  • 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.
  • '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.
  • 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.
  • the process 1613 follows a NO arrow 1717 to the step 1616 in Fig. 16B.
  • 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").
  • the sender is directed to a selection of generic options such as 'lover', 'friend', 'mum' etc.
  • the list is different for each animated message.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

L'invention porte sur un procédé (200, 200'), dans un système (100) comprenant un terminal mobile expéditeur (109), un terminal destinataire (106) et un serveur (101) communiquant sur un réseau (107), pour envoyer, par le terminal mobile expéditeur, un message personnalisé au terminal destinataire, le procédé consistant à demander (201) un menu de messages prédéfinis au serveur, les messages comprenant des éléments de contenu auxquels peut être attribué un type parmi une pluralité de types ; recevoir (1613), en ce qui concerne un message sélectionné, un nom d'un utilisateur du terminal destinataire, et des informations de genre relatives à l'utilisateur et/ou à des éléments de contenu du message sélectionné ; attribuer, aux éléments de contenu du message sélectionné, des types sur la base du nom reçu du destinataire et/ou des informations de genre reçues, pour ainsi construire (1634) le message personnalisé ; et envoyer (224) le message personnalisé au terminal destinataire.
PCT/AU2012/001106 2011-09-16 2012-09-14 Système de messagerie WO2013037007A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
AU2011903823A AU2011903823A0 (en) 2011-09-16 A messaging system
AU2011903823 2011-09-16

Publications (1)

Publication Number Publication Date
WO2013037007A1 true WO2013037007A1 (fr) 2013-03-21

Family

ID=47882455

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2012/001106 WO2013037007A1 (fr) 2011-09-16 2012-09-14 Système de messagerie

Country Status (1)

Country Link
WO (1) WO2013037007A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200374403A1 (en) * 2014-10-27 2020-11-26 Rideshark Corporation Methods and systems for notifications in communications networks

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7301093B2 (en) * 2002-02-27 2007-11-27 Neil D. Sater System and method that facilitates customizing media
US20110222672A1 (en) * 2006-06-20 2011-09-15 Dustin Kenneth Sapp System and method for providing voice messaging with dynamic content

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7301093B2 (en) * 2002-02-27 2007-11-27 Neil D. Sater System and method that facilitates customizing media
US20110222672A1 (en) * 2006-06-20 2011-09-15 Dustin Kenneth Sapp System and method for providing voice messaging with dynamic content

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200374403A1 (en) * 2014-10-27 2020-11-26 Rideshark Corporation Methods and systems for notifications in communications networks
US11677878B2 (en) * 2014-10-27 2023-06-13 Rideshark Corporation Methods and systems for notifications in communications networks

Similar Documents

Publication Publication Date Title
US11151187B2 (en) Process to provide audio/video/literature files and/or events/activities, based upon an emoji or icon associated to a personal feeling
US9002410B2 (en) Method and apparatus for creating, using, and disseminating customized audio/video clips
CN115361463B (zh) 用于在移动计算设备上管理与消息上下文相关联的媒体内容的方法和系统
CN111343074B (zh) 一种视频处理方法、装置和设备以及存储介质
CN101843086B (zh) 在维持于电子设备中的联系人列表中使用图像的装置、方法和计算机程序产品
US20110007077A1 (en) Animated messaging
CN112241397B (zh) 多媒体文件的分享方法、装置、电子设备及可读存储介质
US20070245006A1 (en) Apparatus, method and computer program product to provide ad hoc message recipient lists
US20100125795A1 (en) Method and apparatus for concatenating audio/video clips
US20170359283A1 (en) Music creation app in messaging app
KR101633212B1 (ko) 사용자 맞춤형 템플릿을 제공하는 메신저 서비스를 제공하는 방법과 시스템 및 기록 매체
US20240114197A1 (en) Video file processing method and apparatus, electronic device, and computer storage medium
US20160203112A1 (en) Method and arrangement for processing and providing media content
CN102866987A (zh) 移动终端中发送消息的装置及方法
KR101567555B1 (ko) 이미지가 이용되는 소셜 네트워크 서비스 시스템 및 방법
WO2021225104A1 (fr) Programme, procédé d'affichage et terminal
KR20140017959A (ko) 스마트 기기를 위한 카툰 형태의 모바일 메신저 서비스 제공 방법
US20140013193A1 (en) Methods and systems for capturing information-enhanced images
US11644946B2 (en) Method and user terminal for displaying icon representing set of content on a chat room screen
US11132419B1 (en) Configuring output controls on a per-online identity and/or a per-online resource basis
WO2013037007A1 (fr) Système de messagerie
CN114500739B (zh) 一种通话请求方法、装置、设备和计算机可读存储介质
CN113362802B (zh) 语音生成方法、装置和电子设备
CN114390216A (zh) 带有语音消息的图像的生成控制装置及生成方法
US12010386B2 (en) System and method for providing digital graphics and associated audiobooks

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12831263

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12831263

Country of ref document: EP

Kind code of ref document: A1

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载