WO2014015379A1

WO2014015379A1 - Technologies, methodologies, and computer implemented frameworks configured to enable delivery of electronic messages to recipients

Info

Publication number: WO2014015379A1
Application number: PCT/AU2013/000824
Authority: WO
Inventors: Glen STEVENS; Dimity KENNEDY; John Bowles; Divian DE BEER
Original assignee: NINJA MESSAGE Pty Ltd
Current assignee: NINJA MESSAGE Pty Ltd
Priority date: 2012-07-24
Filing date: 2013-07-24
Publication date: 2014-01-30
Anticipated expiration: 2015-01-24
Also published as: AU2013296142A1

Description

TECHNOLOGIES, METHODOLOGIES, AND COMPUTER

IMPLEMENTED FRAMEWORKS CONFIGURED TO ENABLE DELIVERY OF ELECTRONIC MESSAGES TO

RECIPIENTS

FIELD OF THE INVENTION

[0001] The present invention relates to technologies, methodologies, and computer implemented frameworks configured to enable delivery of electronic messages to recipients. For example, embodiments include the likes of systems and methods for coordinating message delivery, systems and methods for automated direct delivery of audio messages to voicemail accounts, a multi-modem device configured to enable automated delivery of audio messages directly to voicemail accounts, an Automated Voice Messaging (AVM) Server, and a mobile app configured to enable a user to communicate an audio message directly to a voicemail account. Embodiments of the invention have been particularly developed for operation in the context of technology for coordinating the delivery of voicemail-type messages to recipients, for example in the context of a message coordination server and API interface. While some embodiments will be described herein with particular reference to that application, it will be appreciated that the invention is not limited to such a field of use, and is applicable in broader contexts.

BACKGROUND

[0002] Any discussion of the background art throughout the specification should in no way be considered as an admission that such art is widely known or forms part of common general knowledge in the field.

[0003] There are many situations where it is desirable to contact a person via telephone (such as a land-line, cellular telephone, VOIP phone, or the like). The main approaches for doing so are to either make a voice call (using conventional voice-call technology, or a proprietary data-based voice-calling application), or sending a text/data type message (for example SMS, MMS, email, or other messaging protocol). The degrees to which these are appropriate for various personal and commercial purposes vary. However, for many purposes, including the likes of market research, both have significant drawbacks. In particular, often there is a preference to communicate via voice, but to automate that process. Various devices have been developed which enable automated calling using a pre-recorded message, however those can seem quite impersonal to recipients, who are unable to interact with a machine playing a pre-recorded message.

SUM MARY OF THE INVENTION

[0004] It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative.

[0005] One embodiment provides a computer implemented method for coordinating message delivery, the method including the steps of:

[0006] providing an interface that is configured to receive data indicative of a message plan requests, wherein each request is indicative of a message plan defined by a set of one or more target contact numbers associated with a set of one or more target messages, wherein each target message is defined by an audio data file;

[0007] defining a set of message actions thereby to enable implementation of the messaging plan; and

[0008] instructing a set of one or more calling modules to execute Automated Voice Messaging (AVM) scripts respectively associated with the set of message actions;

[0009] wherein a given AVM script is executed in respect of a particular target contact number and a particular target message, and wherein the execution includes placing a plurality of calls to the target contact number, wherein a target message is delivered.

[0010] One embodiment provides a computer implemented method for coordinating message delivery, the method including:

[0011] (i) identifying a target contact number and a target audio message; [0012] (ii) initiating one or more blocking calls to the target contact number; [0013] within a predetermined period of (ii), initiating a message-delivery call to the contact number;

[0014] upon completion of a predetermined delay period, communicating the target audio message via the message-delivery call.

[0015] One embodiment provides a method wherein the predetermined period is between 0.01 seconds and 60 seconds.

[0016] One embodiment provides a method wherein the predetermined delay period is measured from initiation or connection of the message-delivery call.

[0017] One embodiment provides a method wherein the predetermined delay period is between 0.01 seconds and 120 seconds.

[0018] One embodiment provides a method wherein the predetermined delay period is measured by reference to an observed silence.

[0019] One embodiment provides a method wherein the predetermined delay period is between 0 seconds and 5 seconds.

[0020] One embodiment provides a method claim wherein (ii) includes initiating two or more blocking calls.

[0021] One embodiment provides a method wherein each blocking call has a finite duration of between 0.01 seconds and 30 seconds.

[0022] One embodiment provides a method wherein the one or more blocking calls and/or the message-delivery call are initiated using VOIP.

[0023] One embodiment provides a method including terminating the message-delivery call at a fixed time following commencement of communicating the target audio message via the message-delivery call.

[0024] One embodiment provides a device configured for coordinating message delivery, the device including: [0025] at least two modem components;

[0026] time-based activation switches that configure the device thereby to:

[0027] control the at least two modem components thereby to initiate at least one blocking call to a target number and, within a predetermined period of the blocking calls, initiating a message-delivery call to the contact number;

[0028] control the device thereby to communicate a target audio message via the message-delivery call, upon completion of a predetermined delay period.

[0029] One embodiment provides a device wherein the predetermined period is between 0.01 seconds and 60 seconds.

[0030] One embodiment provides a device wherein the predetermined delay period is measured from initiation or connection of the message-delivery call.

[0031] One embodiment provides a device wherein the predetermined delay period is between 0.01 seconds and 120 seconds.

[0032] One embodiment provides a device wherein the predetermined delay period is measured by reference to an observed silence.

[0033] One embodiment provides a device wherein the predetermined delay period is between 0 seconds and 5 seconds.

[0034] One embodiment provides a device wherein there are three or more modem components, with at least two configured for initiating blocking calls.

[0035] One embodiment provides a device wherein each blocking call has a finite duration is between 0.01 seconds and 30 seconds.

[0036] One embodiment provides a device wherein the one or more blocking calls and/or the message-delivery call are initiated using VOIP. [0037] One embodiment provides a device wherein the device is configured for terminating the message-delivery call at a fixed time following commencement of communicating the target audio message via the message-delivery call.

[0038] One embodiment provides a method for coordinating message delivery, the method including the steps of:

[0039] providing an interface that is configured to receive data indicative of a message plan requests, wherein each request is indicative of a message plan defined by a set of one or more target contact numbers associated with a set of one or more target messages, wherein each target message is defined by an audio data file;

[0040] defining a set of message actions thereby to enable implementation of the messaging plan; and

[0041] instructing a set of one or more calling modules to execute AVM scripts respectively associated with the set of message actions.

[0042] One embodiment provides a method wherein the interface includes an API interface configured to receive respective requests from a plurality of software applications.

[0043] One embodiment provides a method wherein the software applications include any one or more of the following:

[0044] CRM applications operable on respective computer systems;

[0045] software applications operable on servers that are configured to receive input from browser-based clients;

[0046] software applications executable on mobile devices; and

[0047] software applications operable on servers that are configured to receive input from mobile-device clients. [0048] One embodiment provides a method including a step of adding the set of message actions to a message action queue.

[0049] One embodiment provides a method including operating a queuing module configured to coordinate execution of AVM scripts associated with message actions in the message action queue via the set of one or more calling modules.

[0050] One embodiment provides a method wherein each of the set of one or more calling modules is configured to execute AVM scripts, wherein each AVM script is associated with a target message and a target contact number.

[0051] One embodiment provides a method wherein execution of a given one of the AVM scripts delivers the target message to a voicemail account associated with the target contact number.

[0052] One embodiment provides a method execution of a given one of the AVM scripts includes performing a method as described herein.

[0053] One embodiment provides a method wherein each message plan request is indicative of a requestor, and wherein the method includes operating a billing module configured to associate a charge to the requestor in respect of the message plan.

[0054] One embodiment provides a method wherein the billing module is configured to calculate the charge responsive to data indicative of success of implementation of the message plan.

[0055] One embodiment provides a method for coordinating message delivery, the method including:

[0056] receiving data indicative of a set of one or more target contact numbers;

[0057] receiving data indicative of a set of one or more target messages, wherein each target message is defined by an audio data file;

[0058] receiving data indicative of association of each of the target contact numbers with a respective one of the target messages; [0059] defining data indicative of a message plan request, wherein the request is indicative of a message plan defined by the set of one or more target contact numbers associated with the set of one or more target messages; and

[0060] delivering the data indicative of the message plan request to a message plan implementation server.

[0061] One embodiment provides a method wherein the message plan implementation server is configured to execute a method described herein.

[0062] One embodiment provides a server device configured to coordinate delivery of voicemail messages to a plurality of target devices based upon a set of client instructions, wherein the delivery of voicemail messages is implemented by way a multi-call methodology that includes at least one blocking call and at least one associated message delivery call.

[0063] One embodiment provides a non-transitive carrier medium for carrying computer executable code that, when executed on a processor, causes the processor to perform a method as described herein.

[0064] One embodiment provides a system configured for performing a method as described herein.

[0065] Reference throughout this specification to "one embodiment", "some embodiments" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrases "in one embodiment", "in some embodiments" or "in an embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment, but may. Furthermore, the particular features, structures or characteristics may be combined in any suitable manner, as would be apparent to one of ordinary skill in the art from this disclosure, in one or more embodiments.

[0066] As used herein, unless otherwise specified the use of the ordinal adjectives "first", "second", "third", etc., to describe a common object, merely indicate that different instances of like objects are being referred to, and are not intended to imply that the objects so described must be in a given sequence, either temporally, spatially, in ranking, or in any other manner.

[0067] In the claims below and the description herein, any one of the terms comprising, comprised of or which comprises is an open term that means including at least the elements/features that follow, but not excluding others. Thus, the term comprising, when used in the claims, should not be interpreted as being limitative to the means or elements or steps listed thereafter. For example, the scope of the expression a device comprising A and B should not be limited to devices consisting only of elements A and B. Any one of the terms including or which includes or that includes as used herein is also an open term that also means including at least the elements/features that follow the term, but not excluding others. Thus, including is synonymous with and means comprising.

[0068] As used herein, the term "exemplary" is used in the sense of providing examples, as opposed to indicating quality. That is, an "exemplary embodiment" is an embodiment provided as an example, as opposed to necessarily being an embodiment of exemplary quality.

BRIEF DESCRIPTION OF THE DRAWINGS

[0069] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings in which:

[0070] FIG. 1 schematically illustrates a message delivery framework according to one embodiment.

[0071] FIG. 2 illustrates a message coordination server according to one embodiment.

[0072] FIG. 3 illustrates a client-server framework leveraged in some embodiments.

[0073] FIG. 4A illustrates a method according to one embodiment.

[0074] FIG. 4B illustrates a method according to one embodiment.

[0075] FIG. 4C illustrates a method according to one embodiment. DETAILED DESCRIPTION

[0076] Described herein are systems and methods for coordinating message delivery. For example, embodiments include methodologies, software, components and systems configured to facilitate coordination of message delivery. In particular, the present embodiments are focussed on message delivery in the context of audio messages that are delivered directly to voicemail accounts. Some embodiments relate to a scalable platform thereby to provide a range of users, via a range of channels, with convenient access to message delivery technology.

[0077] One embodiment provides a method that allows for the depositing of a pre-recorded voice message at a recipient's voicemail account (i.e. voice message service), achieved by placing a single voice call (preferably of fixed duration) to the recipient's telephone service (which may be a land-line telephone service, cellular/mobile telephone service, Voice Over IP we, or other telephone service) thereby to render the telephone service incapable of receiving a further incoming call. A second voice call is then placed, at a time determined by predefined timing rules, to the recipient's telephone service. This second call is rerouted to the recipient's voice message service (due to the blocking effect of the first call), assuming such a voice message service exists. Following a predefined period, the pre-recorded voice message is played via the second call, so that it is recorded to the voice message service. After another fixed period of time from the start of the message transmission, the second call is terminated (or alternatively, in some embodiments the call is terminated on the completion of the voice message delivery).

[0078] In another embodiment, two calls of fixed duration (with a predetermined time period between their commencement) are placed to a recipients' telephone service to render service incapable of receiving a further incoming call. A third voice call is then placed, at a time determined by predefined timing rules, to the recipient's telephone service. This third call is rerouted to the recipient's voice message service (due to the blocking effect of the first call), assuming such a voice message service exists. Following a predefined period, the pre-recorded voice message is played via the third call, so that it is recorded to the voice message service. After another fixed period of time from the start of the message transmission, the third call is terminated (or alternatively, in some embodiments the call is terminated on the completion of the voice message delivery). [0079] In some embodiments the use of an application program interface (API) allows for the integration of the above methods (or other methods for delivering audio messages) with various initiators for the action of the service regardless of the delivery method. Initiators may include, by way of example, external software programs, a customer relationship management (CRM) software program, a bulk messaging service software application, or external application program interface (API) or iOS or Android Device (and/or other device/software platform).

[0080] It will be appreciated that the present technology is by no means limited to embodiments that make use of an API; in some embodiments a closed platform is used thereby to provide an end-to-end solution without the provision of an API for third parties.

[0081] Although various embodiments leverage software modules to initiate calls and communicate audio messages, some embodiments leverage and/or provide a physical device consisting of electronic circuitry and two modems (which does not necessarily contain a software program) attached to two physical trunk lines. This is configured to perform a method of rendering the telephone or mobile phone or voice over internet protocol service (or other audio communication technology) incapable of receiving an incoming call allowing for a further call (a messaging call) to be rerouted to the recipients voice message service (and which is then connected to that voice message service), and once a fixed time period has passed, the pre-recorded voice message is playing on the line so that it is recorded to the voice message service and after another fixed period of time the second call is terminated (or alternatively, in some embodiments the call is terminated on the completion of the voice message delivery). In a further variation, a physical device consists of electronic circuitry and three or more modems thereby to allow additional blocking calls.

Framework Overview.

[0082] FIG. 1 illustrates a framework for coordinating message delivery, according to one embodiment. A message coordination server 100 operates in conjunction with a set of one or more calling modules 101 thereby to coordinate delivery of pre-recorded audio messages (defined by respective audio files) to a set of user contact numbers 103.

[0083] The term "contact number" as used herein refers in some embodiments to a telephone number (i.e. a contact number for a telephone service belonging to a recipient), preferably being a cellular telephone number, and in some cases or a landline-type telephone number. However, the term should be read sufficiently broadly to cover a range of other identifiers (numeric, alphanumeric, and otherwise) that are used for the purpose of identifying recipients and/or routing communications. Preferably each contact number is associated with a voicemail account (however it is appreciated that this is not the case for all contact numbers, and hence message delivery as considered herein is not always possible). As is customary in the present day technological framework, a call placed to a contact number diverts to a voicemail account when predetermined conditions are met. These conditions vary between contact numbers (dependent, for example, on telecommunications carrier settings and/or user device settings).

[0084] As discussed in greater detail further below, calling modules 101 are in some embodiments configured to execute "AVM scripts" (Automated Voice Messaging scripts). An AVM script includes a set of instructions for placing a plurality of calls to a contact number in accordance with a predetermined protocol. These preferably include one or more "blocking calls", which are intended to ensure that a subsequent "message delivery call" is automatically diverted to the voicemail account associated with the contact number. An audio message is communicated via the message delivery call.

[0085] In some cases the calling module or calling modules are integrated with message coordination server 100, whereas in other embodiments they are provided individually or collectively by one or more distinct components. For example, in one embodiment a server device is configured to provide a plurality of calling modules. In another embodiment, each calling module is a distinct hardware component.

[0086] Calls placed via calling modules may be data-based calls, for example using Voice Over IP (VOIP) protocols or the like. However, in some embodiments conventional land-line based calls are used as an alternative, and in some embodiments a combination of data-based and land-line based calls are used. It will be appreciated that cost factors, and implementation factors, tend to favour the use of data-based calls. It will also be appreciated that the methodologies described herein are applicable across a range of call- placement technologies, and will be applicable to technologies developed at a later date.

[0087] Server 100 includes an API interface 104 thereby to facilitate communication between server 100 and a plurality of other components. In general terms, this API enables other software applications to interface with software executing at server 100, thereby to enable other parties to define instructions for "message plans". A "message plan" is defined by a set of one or more target contact numbers associated with a set of one or more target messages, wherein each target message is defined by an audio data file. For example, a message plan may be defined by:

• A single target contact number and a single target message.

• A plurality of target contact numbers associated with a common target

message.

• A plurality of target numbers associated with a plurality of target messages, with one-to-one association.

• A plurality of target numbers associated with a plurality of target messages, with other than one-to-one association (i.e. a given message is associated with multiple target numbers).

[0088] As illustrated in FIG. 1 , API interface 104 enables communication with mobile apps 1 10, website portals 1 11 , CRMs 112 and other compatible software 1 13. In some cases client devices implement software compatible with the API interface, and hence communicate with server 100 directly. However, in other cases an application server interposes client devices and server 104, with software compatible with the API interface being implemented on the application server. For example, such an approach is appropriate for websites (where client terminal execute browser applications and communicate data to a web server that is compatible with the API interface) or mobile apps (where mobile devices communicate with an application server that is centrally responsible for communicating with server 100 via the API interface 104).

[0089] Various aspects of the framework of FIG. 1 are described in greater detail further below.

Exemplary Message Coordination Server

[0090] FIG. 2 illustrates an exemplary message coordination server 200, according to one embodiment. Server 200 includes at least one microprocessor coupled to a memory module, thereby to enable execution of computer-executable code (software instructions) thereby to configure server 200 to perform various functionalities discussed herein. [0091] Server 200 is described by reference to a plurality of "modules". Each "module" is a functionally defined component, and may be physically represented by a software component. In some cases multiple modules are provided by a common software component, and in some cases a given module is provided by a plurality of distinct software components. Furthermore, it should be appreciated that it is by no means necessary that all components/modules illustrated are housed in a common machine; in some cases server 200 is defined by multiple distinct computing machines, optionally at distinct remote locations. As part of this, data storage modules may be defined by physically separate storage subsystems.

[0092] Server 200 includes a set of one or more API interface modules 201 , which are each configured to receive data indicative of a message plan requests (or data that enables the generation of message plans). Each message plan request is indicative of a message plan defined by a set of one or more target contact numbers associated with a set of one or more target messages (with each target message being defined by an audio data file). In some embodiments the message plan request includes data indicative of the contact number(s) and/or audio data file(s), and in other embodiments instead includes data indicative of a location from which the contact number(s) and/or audio data file(s) are retrievable.

[0093] It is not necessary that a message plan be defined by a discrete data set; in some embodiments a message plan is defined by an ongoing stream of data from client.

[0094] FIG. 2 illustrates a number of exemplary components that are configured to provide message plan requests to API interface modules 201 :

• An exemplary mobile device 220 that executes a mobile app (for example an iOS or Android app) that is configured to interact with API interface module 201. This enables creation of message plans using, for example, contact numbers stored on the mobile device. It will be appreciated that a wide range of mobile apps are possible, ranging from simple one-off voice messaging apps, to complex multi- recipient marketing plan creation apps.

• An exemplary user terminal 222 that executes a CRM or other application 223. In the case of a CRM, a CRM is either configured to operate with the relevant API, or as a plug-in module is installed thereby to configure the CRM for such operation. This enables, for example, a message plan to be defined using contacts stored in the CRM (for example to automatically send reminders to customers when certain conditions are met in CRM data, or the like).

• An exemplary web server 224 that implements API-compatible web server modules. These enable an exemplary website user 226 (via a web browser application) to define message plans.

• An exemplary application server 227 that implements client communication modules 228 for communicating with client devices that execute applications for defining message plans, such as an exemplary app user 229. Server 227 is API compatible, thereby to communicate data indicative of defined message plans to API modules 201.

[0095] Communication between the client servers and/or devices and server 200 occur through an AVM API using a standard that allows for multiple requests to be sent simultaneously from each user (for example in batched form via a message plan that is launched to an entire address book at the same time, or the like). Although the example of FIG. 2 is heavily focussed in API-based communications, it will be appreciated that other approaches are used in further embodiments.

[0096] Upon receipt of a message plan request, an authentication module 202 authenticates the request by reference to user data maintained in a user data storage module 204. This determines whether the requestor of the message plan is authorised to submit such a plan. In some cases additional two-way communications are performed thereby to confirm/confer such authority. If authentication cannot be achieved, the requestor is informed of the error, and the message plan is not progressed.

[0097] In some embodiments, each client (i.e. user account) is manually set up through an administration interface, providing a secure way to prevent improper use of the system.

[0098] In terms of the manner by which user data is stored, some embodiments maintain an arrangement whereby at least some end users are associated with resellers (such as CRM vendors, and/or parties that distribute software that interacts with sever 200 via an intermediary). For example, each client of a reseller will also need to be set up manually under the reseller's ID, and given their own unique identification key so that they may be able to use the system directly. This unique ID is preferably automatically created when the client is set up within module 204, and is used to verify the client each time they use the system. Each request is checked off against the database to ensure that their account is in good order (for example whether it is active, doesn't have any overdue or outstanding bills against it, etc).

[0099] In the case that authentication is successful, a message plan coordination module 203 operates in conjunction with a contact data storage module 205 and audio message storage module 206 thereby to prepare the plan for execution. This, in some embodiments, includes defining a set of message actions thereby to enable implementation of the messaging plan. This may include defining a list of AVM scripts for execution via one or more calling modules. Preferably, a queuing module 208 maintains a queue of actions (having associated AVM scripts) awaiting execution, and coordinates the execution of those by instructing calling modules. In some cases the queue of actions is defined by references to target numbers and associated target messages, and an AVM script is executed for each action, which includes initiation of one or more blocking calls and a message call.

[00100] FIG. 2 illustrates a single calling module 209, however there may be a set of two or more calling modules. It will be appreciated that having a larger number of calling modules operating in parallel increases the rate at which a list of AVM scripts are able to be executed.

[00101] In some cases AVM scripts are defined by module 203, whereas in other embodiments the scripts are defined immediately preceding execution (for example by populating a generic script with values for a target contact number and audio message from modules 205 and 206 respectively).

[00102] In the example of FIG. 3A, executing an AVM script includes initiating three calls (preferably using VOIP) to the relevant target contact number, which may be hosted by an exemplary telecommunications network 240. These include blocking calls 241 a and 241 b. In some cases, both of these will be directed to the exemplary contact number 242 (provided that number is configured to handle two consecutive calls) otherwise either or both divert to voicemail 244). It will be appreciated that having either or both of calls 241a and 241 b divert to voicemail 244 is not problematic. A third call 243 diverts to voicemail 244 and the target message is communicated via that call. [00103] A billing module 207 is, in the illustrated example, configured for defining charges to clients in respect of executed message plans. Preferably charges are calculated responsive to the number of AVM scripts that successfully execute. Other factors may also impact on charge calculations, such as variable rates based on the total number of scripts executed over a given time period.

Exemplary AVM Script Execution Method

[00104] FIG. 4A illustrates an exemplary software- based script execution method 200 according to one embodiment. This method is optionally implemented by one or more calling modules in the context of the arrangement of FIG. 2.

[00105] Functional block 201 includes initiating one or more blocking calls. In some embodiments only a single blocking call is made, whereas in other embodiments two or more calls are made. These calls are in some embodiments made substantially simultaneously, using separate VOIP threads, and in some embodiments made at predefined intervals (preferably between 0.5 seconds and 2 seconds).

[00106] Functional block 202 represents a delay between initiation or connection of blocking calls and initiation or connection of a message-delivery call at 203. That is, in some embodiments the delay may be defined by reference to initiation of blocking calls, and in other embodiments the delay may be defined by reference to connection of the blocking calls (for example commencement of ringing). In some embodiments the delay is defined by reference to another event.

[00107] Functional block 204 represents a delay following initiation or connection of the message delivery call. This is intended to provide an opportunity for a voicemail greeting and/or instructional message to pass, and is preferably between A seconds and B seconds, measured from initiation or connection of the message delivery call. Following this delay, the target message is communicated via the message-delivery call at 205.

[00108] It will be appreciated that alternate message delivery methodologies are used in further embodiments. For example, some embodiments make use of "special" contact numbers that inherently connect directly to a voicemail account associated with a target number, without the need for blocking calls or the like. Variable Timing Parameters

[00109] As noted above, execution of an AVM script includes performing various actions (for example initiation of calls) based on a predefined time-based schedule. For example, a time-based schedule defines the timing of blocking calls relative to message delivery calls, the timing of message delivery relative to the placement of a message delivery call, and so on. These can be considered in terms of script timing parameters.

[00110] In some embodiments, variable timing parameters may be implemented. That is, in embodiments variable timing parameters are used, for a first AVM script the timing parameters have a first set of values, and for a second AVM script the timing parameters have a second set of values. This may be achieved by, for instance:

(i) Providing a plurality of distinct executable AVM scripts, with respective timing parameters. Which of these scripts is selected for execution may be determined by a process that takes into consideration timing parameter influencing factors, such as those considered below,

(ii) Using variable values a given AVM scripts to control timing parameters. For example, timing influencing factors are considered during execution of a script thereby to dynamically set values for timing variables.

[0011 1] As noted above, timing parameters are preferably set based on one or more influencing factors. For example, these influencing factors may relate to network congestion, thereby to account for varying amounts of time it may take to connect a given call. This may be especially important in terms of time delay between placing a message delivery call, and playback of the relevant audio message via that call. Network delays may increase the time to voicemail connection by a number of seconds, which could in turn clip the beginning of the message (i.e. not the full message is recorded by the recipient's voicemail). Influencing factors may include

• Time of day. Timing parameters may be set of different values for different times of day. In this manner, for example, the delays at 202 and/or 204 may be increased during peak load times, where networks are congested. This allows for an approximation of network load/congestion to be applied based on known peak times. • Network Performance Data: Network performance (for example in terms of connection times, load, congestion, and the like) may be measured and used to influence timing parameters. For example, one approach is to implement a network monitoring module, which repeatedly places calls to predefined contact numbers, and measures connection times. These measurements are used to define objective values indicative of network performance, which are in turn used to influence timing parameters. For example, in one embodiments four calls are placed to the same four numbers every minute, and the times between call initiation and connection (for example defined by audible recognition of a ringing tone) are measured for each call. The measured values are used to determine network performance on a predefined scale.

• Recipient characteristics. Timing parameters mar be adjusted based on characteristics of a recipient, for example where characteristics such as location, network, voicemail type, and so on, are known. It will be appreciated that the availability of such information is inherently limited in some circumstances.

[00112] Other approaches may also be used. The net effect, in any case, is that AVM script timing parameters are able to be adjusted responsive to external factors, such as external factors representing network performance.

Exemplary Message Plan Request Processing Method

[00113] FIG. 4B illustrates an exemplary message plan request processing method 210. This method includes, at 21 1 receiving a request via the API interface. Then, at 212, the requestor is authenticated. In the case of successful authentication, the method progresses to 213. Otherwise, an error is logged and reported to the requestor.

[00114] At 213, the contact numbers associated with the request are verified (for example to ensure that they represent valid or potentially valid contact numbers). In the cases of successful verification, the method proceeds to 214. Otherwise, an error is logged and reported to the requestor (for example to enable the requestor to modify the contact numbers associated with the request).

[00115] At 214, AVM scripts are defined for the request. This may include defining actual scripts, or defining data including a set of referential instructions for enabling definition of the actual scripts just prior to runtime. These are then added to a queue for execution at 215.

Exemplary Script Queuing Method

[00116] FIG. 4C illustrates an exemplary queue scripting method 220. This method is performed by a component of server 220 that instructs calling modules to process queued AVM scripts. However, in other embodiments calling modules are configured to actively seek queued scripts.

[00117] The method commences at 221 , for example on start-up of server 200. At decision 222, it is determined whether there is a script in the queue. This step repeats continually if the queue is empty. If there is a script in the queue, the method progresses to decision 223, where it is determined whether a call module is available. Once a call module becomes available, the next script in the queue is delegated to that call module at 224. Based on a response from the call module, it is determined at 225 whether the script executed successfully. Success is logged at 226, or failure logged at 227. The method then loops to 222.

[00118] In some embodiments, each message plan request is received from the API by the numerous clients and remote servers, requests (or individual actions within those requests) are assigned respective priority numbers. They are then processed in the order of this priority on the next available free calling module (or SIP line/trunk). The AVM script will automatically scan for a free set of lines (remembering it takes 2-3 calls to effectively execute the AVM script) and then use that set in order to make the calls. Calls are not processed and made immediately, in the same way that SMS's are, as each call takes time to occur. As each sip trunk/line becomes available, the next call in the priority queue is assigned to it and the process repeats in this fashion until the priority queue is emptied and there are no calls left to make.

Exemplary System-Level Overview

[00119] In some embodiments, methods and functionalities considered herein are implemented by way of a server, as illustrated in FIG. 3. In overview, a web server 302 provides a web interface 303. This web interface is accessed by the parties by way of client terminals 304. In overview, users access interface 303 over the Internet by way of client terminals 304, which in various embodiments include the likes of personal computers, PDAs, cellular telephones, gaming consoles, and other Internet enabled devices.

[00120] Server 303 includes a processor 305 coupled to a memory module 306 and a communications interface 307, such as an Internet connection, modem, Ethernet port, wireless network card, serial port, or the like. In other embodiments distributed resources are used. For example, in one embodiment server 302 includes a plurality of distributed servers having respective storage, processing and communications resources. Memory module 306 includes software instructions 308, which are executable on processor 305.

[00121] Server 302 is coupled to a database 310. In further embodiments the database leverages memory module 306.

[00122] In some embodiments web interface 303 includes a website. The term "website" should be read broadly to cover substantially any source of information accessible over the Internet or another communications network (such as WAN, LAN or WLAN) via a browser application running on a client terminal. In some embodiments, a website is a source of information made available by a server and accessible over the Internet by a web-browser application running on a client terminal. The web-browser application downloads code, such as HTML code, from the server. This code is executable through the web-browser on the client terminal for providing a graphical and often interactive representation of the website on the client terminal. By way of the web- browser application, a user of the client terminal is able to navigate between and throughout various web pages provided by the website, and access various functionalities that are provided.

[00123] Although some embodiments make use of a website/browser-based implementation, in other embodiments proprietary software methods are implemented as an alternative. For example, in such embodiments client terminals 304 maintain software instructions for a computer program product that essentially provides access to a portal via which the framework s accessed (for instance via an iPhone app or the like).

[00124] In general terms, each terminal 304 includes a processor 311 coupled to a memory module 313 and a communications interface 312, such as an internet connection, modem, Ethernet port, serial port, or the like. Memory module 313 includes software instructions 314, which are executable on processor 31 1. These software instructions allow terminal 304 to execute a software application, such as a proprietary application or web browser application and thereby render on-screen a user interface and allow communication with server 302. This user interface allows for the creation, viewing and administration of profiles, access to the internal communications interface, and various other functionalities.

Conclusions and Interpretation

[00125] It will be appreciated that the disclosure above provides various significant systems and methods for coordinating message delivery.

[00126] Unless specifically stated otherwise, as apparent from the following discussions, it is appreciated that throughout the specification discussions utilizing terms such as "processing," "computing," "calculating," "determining", analyzing" or the like, refer to the action and/or processes of a computer or computing system, or similar electronic computing device, that manipulate and/or transform data represented as physical, such as electronic, quantities into other data similarly represented as physical quantities.

[00127] In a similar manner, the term "processor" may refer to any device or portion of a device that processes electronic data, e.g., from registers and/or memory to transform that electronic data into other electronic data that, e.g., may be stored in registers and/or memory. A "computer" or a "computing machine" or a "computing platform" may include one or more processors.

[00128] The methodologies described herein are, in one embodiment, performable by one or more processors that accept computer-readable (also called machine-readable) code containing a set of instructions that when executed by one or more of the processors carry out at least one of the methods described herein. Any processor capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken are included. Thus, one example is a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or a static RAM, and/or ROM. A bus subsystem may be included for communicating between the components. The processing system further may be a distributed processing system with processors coupled by a network. If the processing system requires a display, such a display may be included, e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT) display. If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit such as a keyboard, a pointing control device such as a mouse, and so forth. The term memory unit as used herein, if clear from the context and unless explicitly stated otherwise, also encompasses a storage system such as a disk drive unit. The processing system in some configurations may include a sound output device, and a network interface device. The memory subsystem thus includes a computer-readable carrier medium that carries computer-readable code (e.g., software) including a set of instructions to cause performing, when executed by one or more processors, one of more of the methods described herein. Note that when the method includes several elements, e.g., several steps, no ordering of such elements is implied, unless specifically stated. The software may reside in the hard disk, or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute computer-readable carrier medium carrying computer-readable code.

[00129] Furthermore, a computer-readable carrier medium may form, or be included in a computer program product.

[00130] In alternative embodiments, the one or more processors operate as a standalone device or may be connected, e.g., networked to other processor(s), in a networked deployment, the one or more processors may operate in the capacity of a server or a user machine in server-user network environment, or as a peer machine in a peer-to-peer or distributed network environment. The one or more processors may form a personal computer (PC), a tablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), a cellular telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.

[00131] Note that while diagrams only show a single processor and a single memory that carries the computer-readable code, those in the art will understand that many of the components described above are included, but not explicitly shown or described in order not to obscure the inventive aspect. For example, while only a single machine is illustrated, the term "machine" shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. [00132] Thus, one embodiment of each of the methods described herein is in the form of a computer-readable carrier medium carrying a set of instructions, e.g., a computer program that is for execution on one or more processors, e.g., one or more processors that are part of web server arrangement. Thus, as will be appreciated by those skilled in the art, embodiments of the present invention may be embodied as a method, an apparatus such as a special purpose apparatus, an apparatus such as a data processing system, or a computer-readable carrier medium, e.g., a computer program product. The computer-readable carrier medium carries computer readable code including a set of instructions that when executed on one or more processors cause the processor or processors to implement a method. Accordingly, aspects of the present invention may take the form of a method, an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of carrier medium (e.g., a computer program product on a computer-readable storage medium) carrying computer-readable program code embodied in the medium.

[00133] The software may further be transmitted or received over a network via a network interface device. While the carrier medium is shown in an exemplary embodiment to be a single medium, the term "carrier medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "carrier medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by one or more of the processors and that cause the one or more processors to perform any one or more of the methodologies of the present invention. A carrier medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, optical, magnetic disks, and magneto-optical disks. Volatile media includes dynamic memory, such as main memory. Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus subsystem. Transmission media also may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications. For example, the term "carrier medium" shall accordingly be taken to included, but not be limited to, solid-state memories, a computer product embodied in optical and magnetic media; a medium bearing a propagated signal detectable by at least one processor of one or more processors and representing a set of instructions that, when executed, implement a method; and a transmission medium in a network bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions.

[00134] It will be understood that the steps of methods discussed are performed in one embodiment by an appropriate processor (or processors) of a processing (i.e., computer) system executing instructions (computer-readable code) stored in storage. It will also be understood that the invention is not limited to any particular implementation or programming technique and that the invention may be implemented using any appropriate techniques for implementing the functionality described herein. The invention is not limited to any particular programming language or operating system.

[00135] It should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, FIG., or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. This method of disclosure, however, is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the claims following the Detailed Description are hereby expressly incorporated into this Detailed Description, with each claim standing on its own as a separate embodiment of this invention.

[00136] Furthermore, while some embodiments described herein include some but not other features included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention, and form different embodiments, as would be understood by those skilled in the art. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[00137] Furthermore, some of the embodiments are described herein as a method or combination of elements of a method that can be implemented by a processor of a computer system or by other means of carrying out the function. Thus, a processor with the necessary instructions for carrying out such a method or element of a method forms a means for carrying out the method or element of a method. Furthermore, an element described herein of an apparatus embodiment is an example of a means for carrying out the function performed by the element for the purpose of carrying out the invention. [00138] In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

[00139] Similarly, it is to be noticed that the term coupled, when used in the claims, should not be interpreted as being limited to direct connections only. The terms "coupled" and "connected," along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. Thus, the scope of the expression a device A coupled to a device B should not be limited to devices or systems wherein an output of device A is directly connected to an input of device B. It means that there exists a path between an output of A and an input of B which may be a path including other devices or means. "Coupled" may mean that two or more elements are either in direct physical or electrical contact, or that two or more elements are not in direct contact with each other but yet still co-operate or interact with each other.

[00140] Thus, while there has been described what are believed to be the preferred embodiments of the invention, those skilled in the art will recognize that other and further modifications may be made thereto without departing from the spirit of the invention, and it is intended to claim all such changes and modifications as falling within the scope of the invention. For example, any formulas given above are merely representative of procedures that may be used. Functionality may be added or deleted from the block diagrams and operations may be interchanged among functional blocks. Steps may be added or deleted to methods described within the scope of the present invention.

Claims

CLAIMS:

1. A computer implemented method for coordinating message delivery, the method including the steps of:

providing an interface that is configured to receive data indicative of a message plan requests, wherein each request is indicative of a message plan defined by a set of one or more target contact numbers associated with a set of one or more target messages, wherein each target message is defined by an audio data file; defining a set of message actions thereby to enable implementation of the messaging plan; and

instructing a set of one or more calling modules to execute Automated Voice Messaging (AVM) scripts respectively associated with the set of message actions;

wherein a given AVM script is executed in respect of a particular target contact number and a particular target message, and wherein the execution includes placing a plurality of calls to the target contact number, wherein a target message is delivered.

2. A method according to claim 1 wherein the interface includes an API interface configured to receive respective requests from a plurality of software applications, including one or more of the following:

CRM applications operable on respective computer systems;

software applications operable on servers that are configured to receive input from browser-based clients;

software applications executable on mobile devices; and

software applications operable on servers that are configured to receive input from mobile-device clients.

3. A method according to claim 1 including adding the set of message actions to a message action queue, and operating a queuing module configured to coordinate execution of AVM scripts associated with message actions in the message action queue via the set of one or more calling modules.

4. A method according to any one of claim 1 wherein each of the set of one or more calling modules is configured to execute AVM scripts, wherein each AVM script is associated with a target message and a target contact number.

5. A method according to claim 4 wherein execution of a given one of the AVM scripts delivers the target message to a voicemail account associated with the target contact number.

6. A method according to claim 1 wherein each message plan request is indicative of a requestor, and wherein the method includes operating a billing module configured to associate a charge to the requestor in respect of the message plan, wherein the billing module is configured to calculate the charge responsive to data indicative of success of implementation of the message plan.

7. A method according to claim 1 wherein execution of an AVM script includes:

(i) identifying a target contact number and a target audio message;

(ii) initiating one or more blocking calls to the target contact number;

(iii) within a predetermined period of (ii), initiating a message-delivery call to the contact number;

(iv) upon completion of a predetermined delay period, communicating the target audio message via the message-delivery call.

8. A method according to claim 7 wherein the one or more blocking calls and/or the message-delivery call are initiated using VOIP.

9. A computer implemented method for coordinating message delivery, the method including:

receiving data indicative of a set of one or more target contact numbers;

receiving data indicative of a set of one or more target messages, wherein each target message is defined by an audio data file;

receiving data indicative of association of each of the target contact numbers with a respective one of the target messages;

defining data indicative of a message plan request, wherein the request is indicative of a message plan defined by the set of one or more target contact numbers associated with the set of one or more target messages; and delivering the data indicative of the message plan request to a message plan implementation server.

10. A method according to claim 9 wherein the message plan implementation server is configured to perform a method including:

wherein a given AVM script is executed in respect of a particular target contact number and a particular target message, and wherein the execution includes placing a plurality of calls to the target contact number, wherein a target message is delivered .

11. A computer system configured to perform a method according to any one of claims 1 to 10.

12. A computer program configured to perform a method according to any one of claims 1 to 10.

13. A non-transitive carrier medium carrying computer executable code that, when executed on a processor, causes the processor to perform a method according to any one of claims 1 to 10.

14. A computer system including

an interface that is configured to receive data indicative of a message plan requests, wherein each request is indicative of a message plan defined by a set of one or more target contact numbers associated with a set of one or more target messages, wherein each target message is defined by an audio data file; a module configured to define a set of message actions thereby to enable implementation of the messaging plan; and a module configured to instruct a set of one or more calling modules to execute Automated Voice Messaging (AVM) scripts respectively associated with the set of message actions;

15. A system according to claim 14 wherein the interface includes an API interface configured to receive respective requests from a plurality of software applications, including one or more of the following:

CRM applications operable on respective computer systems;

software applications executable on mobile devices; and

16. A system according to claim 14 wherein each of the set of one or more calling modules is configured to execute AVM scripts, wherein each AVM script is associated with a target message and a target contact number.

17. A system according to claim 14execution of a given one of the AVM scripts delivers the target message to a voicemail account associated with the target contact number.

18. A system according to claim 14wherein execution of an AVM script includes:

(i) identifying a target contact number and a target audio message;

(ii) initiating one or more blocking calls to the target contact number;

19. A system according to claim 18 wherein the one or more blocking calls and/or the message-delivery call are initiated using VOIP.

20. A server device configured to coordinate delivery of voicemail messages to a plurality of target devices based upon a set of client instructions, wherein the delivery of voicemail messages is implemented by way a multi-call methodology that includes at least one blocking call and at least one associated message delivery call.