FIELD

The present invention relates to a message service system, and in particular a system which facilitates the delivery of message service messages to a number of persons associated with an entity, such as a club, group or company.

BACKGROUND

Message service messages (i.e. SMS, MMS or EMS messages) are delivered using existing telecommunications networks to client devices of individuals. The client devices are typically handheld devices, such as mobile telephones produced by Nokia, Apple Inc., RIM (e.g. the Blackberry), etc. The use of message service messages, particularly SMS messages, has grown to become an established and popular mode of communication between individuals and groups of people, primarily because it is convenient and personal.

SMS messages are normally composed on a handheld device and sent to an individual recipient. SMS messages can also be sent to groups of recipients, but depending on the software available on the device, this can be quite cumbersome. SMS messages can also be sent using a software application running on a personal computer or using a software service accessible via the Internet using a web browser on the computer. The services can allow a user to compose a message and manage a list of recipients, in order to send messages to groups of recipients. The messages are sent using a SMS gateway that connects into a mobile telecommunications network.

Whilst message service messages allow immediate and targeted contact with individuals and groups, the cost associated with sending each message can restrict their usage, particularly when sending messages to groups of people. The cost can range from 5 cents to 25 cents depending on the service provider or network operator associated with delivery of the message. This can be particular prohibitive for a number of entities, such as sporting clubs who may wish to contact people via their mobile phones with details of last minute changes to arrangements, such as sporting fixtures. Accordingly, it is desired to provide a system that addresses the technical challenges associated with supporting a service that allows these entities to at least reduce or eliminate these costs, or a system that at least provides a useful alternative. Ideally the system would be easy to access and convenient to use for message senders or publishers.

SUMMARY

In accordance with the present invention there is provided a message service system including: a database including:

(i) at least one publisher record representing a respective message publisher;

(ii) recipient records including phone numbers of respective recipients and associated with the publisher record; and

(iii) advertisement records including the text of respective advertisements; and a message creation component for processing message data representing text of a message provided by the publisher, presenting advertisements, with respective prices, of the advertisement records associated with the publisher record, and processing a selection of a selected advertisement for transmission with the text of the message in a message service message.

The present invention also provides a message service process, including: processing message data representing text of a message provided by a publisher; providing advertisements, with respective prices to be paid by an advertiser, and associated with the publisher; and processing a selection of a selected advertisement for transmission with the text of the message in a message service message to recipients associated with the publisher.

The present invention also provides a message service process, executed by a computer system, including: serving advertisement messages for selection and display with respective prices to be paid by an advertiser; allocating a portion of a message service message to the selected advertising message; and invoking transmission of message service messages with the selected advertising message.

The present invention also provides a message service process, including: presenting demographic data of recipients associated with respective publishers; receiving and storing advertising messages for a selected publisher; and displaying the stored messages for the publisher for selective inclusion in message service messages for the recipients associated with the publisher.

The present invention also provides a message service process, including: providing a message text entry box; dynamically providing selectable advertising messages, with respective prices to be paid by an advertiser, on entry of text data into said box; and sending a selected advertising message with the text data to a messaging process for transmission in a message service message to mobile phones of recipients.

DRAWINGS

Preferred embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

Figure l is a block diagram of a preferred embodiment of a message service system according to the present invention;

Figure 2 is a block diagram of components of a web server of the system;

Figure 3 is a diagram of a database schema of the system;

Figure 4 is a diagram of two tables of the schema;

Figure 5 is a flow diagram of a publication creation process of the system;

Figure 6 is a flow diagram of an advertiser creation process of the system; Figure 7 is a flow diagram of an advertisement campaign creation process of the system;

Figure 8 is a flow diagram of an advertisement approval process of the system;

Figures 9 and 10 are flow diagrams of a message composition and sending process of the system; and

Figures 11 to 16 are screenshots of user interfaces generated by the system.

DESCRIPTION

A message service system 100, as shown in Figure 1, enables publishers (i.e. senders) to compose, schedule and control the delivery of message service messages (i.e. SMS, MMS, EMS messages) to selected groups of recipients. The system 100 is able to perform an analysis to match each message, during the composition process, to one or more advertising messages submitted by an advertiser for the recipient. By selecting matched messages, a publisher is able to control the cost of delivery of the messages. The cost of delivery of each message may be reduced, nil or such that it results in a payment to the publisher.

The system 100 allows publishers and advertisers to control composition, scheduling and delivery of the messages to recipients remotely using a web browser (e.g. Internet Explorer, Firefox, Safari) 104 installed on a client computer device 102 (such as a personal computer or phone produced by Apple Inc.) by connecting to a web server 110 of the system. The web server 110 serves code (e.g. HTML, JavaScript etc.) for storage on computer memory (RAM, Flash etc.) of the computer device 102 and which is used by the browser 104 to generate the user interfaces of the system 100.

The web server 110 includes a publisher creation component 202, an advertiser creation component 204, an advertisement ("ad") campaign creation component 206, an ad approval component 208 and a message composition and sending component 210. The web server 110 can be implemented using a web application framework such as Ruby on Rails or Microsoft .Net. The components 202 to 210 can then be implemented as computer program classes, methods and files as part of the framework using computer program instruction code such as Ruby or Java. The objects instantiated by the computer program code of the components 202 to 210 generate and provide the code elements for the user interfaces that are served by the web server 110 and requested by the web browser 104.

The web server 110 processes and maintains data for the system 100 that is stored in a database 120, according to a database schema as shown in Figures 3 and 4. The database 120 can be implemented using a relational database management system such as MySQL, which runs as a database server.

The web server 110 controls composition, generation and transmission of message service messages that are sent to a message queue 124. The message queue 124 is implemented by a message broker such as Apache ActiveMQ. The message queue 124 communicates with a messenger daemon 126 that transmits the messages to an SMS gateway 130 for delivery to recipients' mobile phones 140. The messenger daemon 126 may be implemented using computer program code such as Ruby. A weekly spend reset process 128 may also be implemented using computer program code such as Ruby. The process 128 communicates with the database 120 to set to zero (every week) the value of spend this week variables stored in the database 120.

The web server 110, the database 120, the message queue 124, the messenger daemon 126 and the weekly spend process 128 may all be stored on computer readable memory (e.g. ROM, RAM, hard disk, etc.) of a hardware server 150, such as a computer server produced by IBM Corporation and Apple Inc. Alternatively, the components 110 to 128 may be stored and run on a number of hardware servers that may be distributed across a communications network. At least parts of the components 110 to 128 can also be replaced by hardware circuits, such as ASICs and FPGAs, to perform the same processing at enhanced speeds.

The SMS gateway 130 that is used may be one of a number of SMS gateways that are part of mobile telecommunication networks and supported by network providers, such as AT&T Inc., BT PIc, Telstra Corporation Limited, etc., to allow messages to be received on a number of different protocols and transmitted to recipients' mobile phones 140 using SMS, MMS or EMS. The message service messages are characterised by including a telephone number (e.g. MSISDN) associated with the recipients' phone 140 and at least a text message of a limited number of characters (e.g. 160) for displaying to the recipient on the phone 140. The messages are transferred to the phone 140 using one of the message service protocols (e.g. SMS, MMS or EMS) specified by 3GPP. The phone 140 is any client computer device (such as a mobile or cellular phone or web based client service) capable of receiving a message service message. The SMS gateway 130 will charge a cost per message for transmission and this cost is passed to an identified sender of the message, e.g. the publisher associated with the recipient or the delivery platform 150. A sender is identified by the gateway 130 for billing purposes using connection authentication data (such as a username and password combination) provided when the daemon 126 connects to the gateway 130. Different MSISDNs can be set in the sender field of each message by the platform 150. Depending on how the message is composed, the delivery platform 150 may be identified as the sender of a message transmitted by the delivery platform 150 and the platform 150 may pass the cost of the message to more than one entity associated with it, i.e. a publisher and an advertiser.

The publisher creation component 202 performs a publisher creation process as shown in Figure 5. The publisher creation component 202 generates and serves (502) a publisher creation page, as shown in Figure 11. The page provides a number of text entry boxes and drop down lists that allow a new publisher to enter a number of details associated with the publisher, including:

(i) publisher name (1101);

(ii) email address (1102);

(iii) a number of recipients of each SMS message (1103);

(iv) ages of the recipients as percentage ranges (1104);

(v) income ranges of recipients (1105);

(vi) percentage of percipients that are female, indicating the sex of the recipients (1106); (vii) the location of the recipients as a percentage of those living in a metropolitan area (1107);

(viii) a start date for sending the messages (1108;) (ix) an ending date for stopping sending of the messages (1109); (x) particular schedules for sending messages (1110); and (xi) an email address to send a notification to the publisher that advertising messages (ads) submitted by an advertiser against a publisher are available for approval by the publisher (1111).

The schedules are each identified by a name, a day of the week and an hour of the day. For example, if the publisher is a sporting club then a "fixtures" schedule can be defined for sending out fixtures information, and a "results" schedule can be defined for delivering results information. The publisher may be a person, group of persons or other entity that wishes to send messages to recipients.

Once all the publisher details have been entered into the text boxes and using the drop downs, a create publisher button 1112 can be selected so as to submit the details back to the web server 110. On receiving data representing the publisher details (504) the publisher creation component 202 creates a Publisher record with fields as shown in Figure 4 (506), and creates a message schedule record, for each schedule submitted, with the fields as shown in Figure 3 (508). Associated with each Publisher record is a number of Subscriber records, as shown in Figure 3, for each recipient associated with the publisher. A Subscriber record includes at least a telephone number, e.g. a MSISDN, of the recipient, and in particular for a device 140 associated with the recipient and which is able to receive a message service message. The publisher can submit the phone numbers of associated recipients for the subscriber records using a number of mechanisms. For example, the publisher can load a list of mobile phone numbers from a pre-existing database or via a subscription service using a system, as described in International Patent Publication WO 2008/148157 (PCT/AU2008/000803), which allows a person to opt-in to receive message service messages. All records are stored in the database 120. The advertiser creation component 204 performs an advertiser creation process as shown in Figure 6. The advertiser creation component 204 serves (602) an advertiser creation page, as shown in Figure 12. The page includes a number of text entry boxes and radio buttons that allows the following advertiser details to be entered:

(i) advertiser name (1201);

(ii) email address (1202);

(iii) size of the target audience to which the advertiser wishes to advertise (1203);

(iv) the frequency of advertising required by the advertiser (1204);

(v) the preferred target sex of the audience (1205);

(vi) the target income of the audience (1206);

(vii) the target age of the audience (1207);

(viii) the target location of the audience (1208);

(ix) the estimated amount that the advertiser wishes to spend (1209); and

(x) a spending limit per week (1210)

A create advertiser button (1211) is provided on the page which when selected submits data representing the entered details to the web server 110. On receiving the entered advertiser details data (604), the advertiser creation component 202 creates an Advertiser record (606) with respective fields, as shown in Figures 3 and 4, including and/or representing the received data.

The ad campaign creation component 206 controls performance of an ad campaign creation process, as shown in Figure 7. The component 206 generates and serves the code for a first page, as shown in Figure 13, as part of the ad campaign creation process (702). This allows an advertiser, after logging onto the platform 150, to create a campaign for:

(a) any one of the publishers having a corresponding Publisher record (by selecting a link 1301), i.e. a blanket campaign;

(b) a single publisher by selecting one of the associated links 1302, 1303 and 1304, i.e. a publisher ad campaign; or

(c) a scheduled message for an associated publisher by selecting the links 1305, 1306 or 1307, i.e. a message schedule ad campaign. For the single publisher selections 1302 to 1304, audience (recipient) demographic data from the associated Publisher record is displayed for the advertiser, including the audience, the age range, sex percentage, income range and location details associated with the publisher. For the scheduled message selections a link 1305, 1306, 1307 is provided for each MessageSchedule record for each publisher together with details from the MessageSchedule record and associated Publisher record including the audience demographic data and the day and time details associated with the schedule.

The advertiser is able to select the type of campaign the advertiser wishes to create by using information presented in the first campaign creation page, and selecting the associated link 1301 to 1307. On selecting one of the links, the web server 110 receives a HTTP request identifying the selection (704). Based on the selection, the campaign creation component generates and serves (706) an ad creation page, as shown in Figure 14, associated with the selection. For example, if link 1305 is selected for a fixture schedule for Acme Publisher, the served ad creation page provides a set of text boxes for entering ads of 30 characters 1401, entering ads of 60 characters 1402, and entering ads of 100 characters 1403. The advertiser can also stipulate in associated data entry boxes the payment that they are prepared to make for the 30 character ads 1404, the 60 character ads 1405, and the 100 character ads 1406. The advertiser is further able to stipulate in a data entry box the maximum spending limit per week for this specific ad campaign, 1407. Once the text boxes have been completed, the advertiser can then select a save ads button 1408 to send data representing the entered text to the web server 110 and create AdCampaign and Ad records with respective fields for each of the ads. The Ad records, as shown in Figure 3, stored in the database 120 each include fields for the text body, length, and the submitted price. The ads are each associated with an AdCampaign record including fields for the entered maximum weekly spend (max weekly spend) and a running total of the spend this week (spend this week). AdCampaign records are associated with an Advertiser record. The type of AdCampaign record created is either BlanketAdCampaign, PublisherAdCampaign or MessageScheduleAdCampaign, based on the selection made at step 704. A MessageScheduleAdCampaign is also associated with a MessageSchedule record, which in turn is associated with a Publisher record. Similarly, a PublisherAdCampaign is associated with a Publisher record.

Once the Ad and AdCampaign records are created (712) the ad campaign creation component 206 emails (714) the publishers associated with the AdCampaign record (714). For a blanket ad campaign this would be all publishers, whereas for a publisher ad campaign or a message schedule ad campaign, the email will go to the publisher of the associated Publisher record, using the email address in the Publisher record (714). The email sent to the publisher includes text advising as to the fact that new ads are available for approval from a particular advertiser and providing a link for approval of the ads. For example, the email may include the following:

From: TxtWords Ad Approvals <approvals@txtwords.redtxt.com.au> To: Acme Publisher <fred@acme.com> Subject: New TxtWords Ads To Approve

You have new ads to approve from Alpha Advertiser.

Click the following link to view the ads and approve them: http://txtwords.local/publishers/l/ad_approvals

On selecting the link, a HTTP request is sent from the publisher's browser 104 to the web server 110 to invoke the ad approval component 208. The ad approval component 208 performs an ad approval process, as shown in Figure 8, where the BlanketAdCampaign records stored in the database are accessed (802) together with all the PublisherAdCampaigns and MessageScheduleAdCampaigns records associated with the Publisher record for the publisher. The text body of the ads associated with these campaigns are returned in an ad approval user interface for the publisher, as shown in Figure 15, to enable them to be approved by selecting a check box 1501 to 1503 associated with each ad text. If the check box is not selected then a text entry box is provided associated with each ad text 1504, 1505 and 1506 that enables a description to be entered regarding a reason for rejection of the ad. Once the user interface is completed, then the publisher can select an approve ads button 1507 which sends a request back to the server 110 to create an AdApproval record for each of the ads. The AdApproval record, as shown in Figure 3, includes a field indicating whether the associated ad has been accepted or not and a field including the text of a rejection reason if this has been entered.

The message sending component 210 is invoked when a publisher selects or submits a HTTP link to create a new message, as shown in the address bar of Figure 16. The message sending component 210 performs a message composition and send process, as shown in Figures 9 and 10. Firstly, all of the AdApproval records associated with the Publisher record of the publisher and with their accepted fields set are accessed, and the Ad records associated with these accepted ad approvals (902) are accessed. The ads are then filtered to ensure that the cost of sending the ads does not exceed the associated ad campaign's max weekly spend parameter value (904). This is done by using the price parameter for each Ad record multiplied by the associated publisher subscribers count parameter value plus the ad campaign's current spend this week parameter value to ensure it does not exceed the ad campaign's max_weekly_spend parameter value. The ads are also filtered out to ensure the advertiser's maximum weekly spend is not exceeded (906). This is done by using the Ad.price value multiplied by Publisher.subscribers count value added to the current Advertiser.spend this week parameter value to ensure the total does not exceed the Advertiser.max_weekly_spend value (906). The

Publisher.subscribers count parameter value is determined by adding the number of Subscriber (recipient) records associated with the Publisher record. If it is determined the max weekly spend value of either the Advertiser or AdCampaign will be exceeded for an ad, then that ad is removed from the filtered list of ads.

Once the Ad records have been filtered, the message sending component generates and serves HTML and JavaScript code (908) in order to display a new message composition interface, as shown in Figure 16. The interface includes a text entry box 1602 in which the publisher can enter the text of the messages to be sent (910) to recipients of Subscriber records associated with the Publisher record. The characters entered in the text box 1602 are considered part of the message body, and the interface updates, using JavaScript, the number of characters remaining 1620 based on whether an ad has been selected using a radio button 1606, 1608. The interface also includes a drop down list 1612 of the names of the MessageSchedule records associated with the publisher enabling one of the records to be selected, or an ad hoc message to be sent associated with no message schedule (912). The interface is updated using JavaScript served to the web browser (1002) to display a subset of the ads of the filtered Ad records in the "Pick an ad" section 1604. The subset includes ads for message schedule ad campaigns associated with the selected message schedule 1612, ads for blanket ad campaigns and ads associated with publisher ad campaigns for the publisher. The subset is then further dynamically filtered on the client device 102 based on the number of characters entered into the message body entry box 1602. The text body of the message service messages that will be sent includes the entered message body text and the text of a selected Ad.body, selected using one of the associated radio buttons 1606, 1608. The entire text for the message service message is displayed in a message preview section 1608.

Initially, the pick an ad section 1604 displays a subset of ads that is not dependent on the text entered, but as the number of characters entered increases then first the longer 100 character ads are not displayed then the 60 character ads are not displayed and then only the 30 character ads are left until no ads are displayed. This is dynamically altered based on the fixed character length of the text of the message service messages that can be sent. For example, if the limit is 160 characters, then the 100 character ads are removed once 61 characters are entered in text entry box 1602. Associated with each ad displayed is the price for the ad, which represents the cost that the advertiser will pay to reduce, offset or eliminate the cost of sending the messages. The dynamic parameter value for the characters remaining 1620 adjusts depending on the length of the ad which has been selected 1606, 1608 in the pick an ad section 1604, and the text that has been entered in 1602, so as to indicate the remaining message body number of characters that can still be entered with that selected ad. Once the message has been composed by entering the message body text 1602 and selecting an ad, the publisher can then press a send message button 1610 (1004). This sends data representing the entered message body text, the selected ad and any selected schedule to the web server 110. The web server 110 creates a Message record associated with the Ad record. The Message record created is either an AdhocMessage or ScheduledMessage record depending on the selection made in the drop down list 1612 (1006). A Message record includes a text body field. A ScheduledMessage record is associated with the selected MessageSchedule record. An AdhocMessage record is associated with the Publisher record.

The message sending component 210 then creates an entry (1008) in the message queue for the ad hoc message or the scheduled message. Ad hoc messages are processed immediately by the message queue 124 whereas scheduled messages are processed at a time according to the associated MessageSchedule record. The price of any ad associated with the Message record is multiplied by the Publisher.subscriber count parameter value and added to the spend this week parameter value for both the associated Advertiser record and the AdCampaign record.

The messenger daemon 126 removes messages to be sent from the message queue 124, and forwards them to the SMS gateway 130. The information sent to the gateway includes the sender MSISDN of the message, the list of recipient MSISDNs for the message, and the text data of the message. The sender MSISDN is obtained from a senderJvlSISDN field of the Publisher record. The MSISDN can be provided by the publisher or generated by the platform 150.

The message server system 100 allows a publisher to be matched with advertisers who are willing to contribute to the cost of sending a message to a large number of recipients. This enables the publisher to pay a lower price, or even be paid by an advertiser to send a message to the recipients. A publisher can simply log into the platform 150 to compose a message and determine whether there are any advertisers willing to contribute to the cost of sending the messages. If there are, the publisher can select an ad the publisher is willing to have inserted into a space reserved for advertising messages.

Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.