Patent Application
20230113581
The invention relates to the field of (Short Message Service) SMS messaging, particularly to SMS messaging for sending a message to a number of recipients, optionally tailored to each recipient.
Messaging systems currently exist for the sending of bulk or mass messages, particularly SMS (short message service) mass messages, to recipients. These systems permit automation of sending a (potentially large) number of messages from one user or client, providing convenience and speed of messaging to an extended audience. These bulk or mass messages comprise at least one message which is sent to a plurality of recipients. The bulk or mass messages can be tailored to each recipient, for example by personalising a greeting, or specifically comprising the name of the recipient, or comprising details specific to the recipient, such as a time of an appointment. The messages may comprise e.g. outbound campaigns from a business (or Enterprise), notifications, advertising or marketing, information etc.
Currently, some of the conventional messaging systems are capable of processing a reply to the bulk or mass message from one or more of the recipients, handled in a way such that the information from a particular recipient can be accurately associated with said recipient. For example, if a recipient receives a message concerning an appointment, an option may exist to reply with a yes or a no, to confirm attendance at the appointment or not.
Examples of conventional messaging systems, capable of bulk messaging, include; Adobe® Campaign Manager (CM), Avaya® Proactive Outreach Manager (POM), SwampFox® Outbound Campaign Manager (OCM), Acqueon® List and Campaign Manager (LCM) or Acqueon® Outbound Campaign Manager (OCM).
The messaging systems comprised in the art may include hardware and software elements. A message to be sent from a first device (of a sender) to a second device (of a recipient) may be routed via one or more intermediate systems or devices. The first device may comprise e.g. a business system, used by an Enterprise or business, or other device of a client, or user, of the messaging system. The second device may comprise e.g. a mobile device, a laptop or computing device, of another business or Enterprise system or person.
The systems, as shown schematically in
More detailed description of the art will be made in relation to the aforementioned figures, i.e.
The messaging systems of the art comprise a number of drawbacks. These include limitation to hardware aspects of the systems in terms of installation, maintenance, upgradability and scalability. Additionally, such systems are limited with regard to the assessment logic and processes which may be applied to outgoing messages or incoming messages from a recipient. The handling or processing of an assessed reply message may be further restricted by limitations on e.g. escalation processes or forwarding. The art is restricted to offering only escalation or forwarding of incoming messages to their own proprietary systems. This may be limiting and problematic.
The above limitations severely impact the ability of a bulk message originator (e.g. a user) to setup and subsequently operate an efficient, high throughput and multi-channel campaign to serve their message recipients, e.g. their customers. (A channel in this context can refer to SMS or other forms of messaging, relating as much to the format of a message as to the route taken, comprising an end point or destination, e.g. at a recipient, and a message flow). Particularly, should the originator be a business or Enterprise, it is expected by customers that interaction with the business should be possible via an increasing number of channels, communication means or mechanisms. In turn, these channels or communication means or mechanisms may, themselves, present with vastly varied ways of receiving incoming communications. Enterprises recognize that due to the fractured nature of these differing channels it can often result in poor experiences for their customers, affecting relationships in a negative way and culminating in poor relations between Enterprise and customer. Ultimately, this results in negative impact(s) to the Enterprise's performance and eventual loss of potential earnings. It is imperative that the Enterprise have the possibility to efficiently and accurately be able to communicate directly with their customers with minimum effort in a group manner, especially towards larger numbers of customers. It is equally imperative that the Enterprise (or user) be able to direct inbound communications from their customers to the appropriate teams and platform required. Sending out bulk or mass messages without the ability to easily handle (a suitably large number of) any necessary responses, is futile. A technical solution to overcome the practical difficulties of effecting efficient and optimised (bulk or mass) messaging is, thus, needed.
The present invention seeks to address the optimisation of processing bulk or mass message(s) through a messaging system, in an efficient and accurate manner, to a recipient. Additionally, the present invention further seeks to provide appropriate and optimised capability to handle any resulting reply messages which may arise from the send process, or other inbound messages to the messaging system, preferably in a manner desired by the sender of the initiating, original, bulk or mass message(s).
According to a first aspect of the present invention, there is provided a Messaging Campaign Manager, MCM, suitable for use in a bulk or mass messaging system, comprising:—
Advantageously, the MCM facilitates the processing of a bulk or mass message according to user defined instruction through a rule-led procedure, including the output of a processed message, suitable for delivery.
Advantageously, the MCM device (or instance) is particularly suitable for ultra-high throughout campaigns. Here, ultra-high throughput refers to a normal achievable operational throughput (or capacity) of around 75,000 messages per hour (which can be bi-directional), or 1,800,000 messages per day, or 21 messages per second.
Preferably, the MCM operates on fully cloud-based architecture. Consequently, this is advantageous in response to rising capacity requirements, as the resources available to the MCM can be scaled upwards easily and rapidly. In practical terms this can mean scaling up the implementation means for operation of the MCM. Such scaling provides virtually limitless capacity, as opposed to that available by means of dedicated hardware, usually situated at the side, or site, of the user.
Optionally, the MCM is configured to receive the input message of the user and/or a user instruction, via a graphical user interface, GUI, that is accessible via a web-portal or a front-end or client-side application, optionally located on a first device associated with the user,
Advantageously, this facilitates easy access to a user from a first device and convenient, easily understood, tools for forming or editing a mass message where required.
Optionally, the MCM is configured such that the first virtual private server, VPSA, further comprises a graphical user interface, GUI, and/or an input, configured to facilitate receipt of the input message of the user or a user instruction, input directly by the user, and/or wherein the first virtual private, VPSA, is comprised in the second virtual private server, VSPB.
Advantageously, the GUI allows the user to directly access the MCM, removing the need for the user to have hardware or software related to the MCM functionality on a first device or an associated dedicated application.
Optionally, the Messaging Campaign Manager, MCM, further comprises:—
Advantageously, this facilitates a more robust MCM operation and a broader scope of application.
Optionally, the Messaging Campaign Manager, MCM, further comprises a customisable output, configured for message output in at least one predetermined format.
Advantageously, this permits output to be rendered suitable for a particular destination of device.
Optionally, the Messaging Campaign Manager, MCM, further comprises a message queue.
Advantageously, the provision of a message queue facilitates autonomous operation of the Messaging Campaign Manager, MCM (or MCM system).
Optionally, the Messaging Campaign Manager, MCM, further comprises at least one plug-in, said plug-in arranged as comprised in the MCM or configured as accessible to the MCM by network access.
Advantageously, the plug-in enables customisation, such as but not limited to, an extension to existing capabilities of the device, instance or program, the addition of a new feature(s) or upgrade(s), the reduction of the size of an application which must be installed on a main device, text editors, etc.
Optionally, the Messaging Campaign Manager, MCM, further comprises a call back, CB, module comprised in the second virtual private server, VPSB, configured capable of processing at least one inbound message to the Messaging Campaign Manager, MCM, for forwarding to the CM,
Advantageously, the MCM comprises the ability to parse, route, and manipulate an original message with additional functionality such as masking (e.g. of private information such as credit card details or addresses) and routing of any reply messages away from the user or originator of the bulk or mass message. Additionally, routing in either send or receive directions can be facilitated with non-native systems.
According to a second aspect of the present invention, there is provided a Messaging Campaign Manager System, MCM system, comprising one MCM or a plurality of MCMs, arranged as comprised in a virtual private cloud, VPC.
Cloud-based implementation is particularly advantageous—for example, in terms of scalability and throughput. Known systems are confined by hardware-based implementations, in at least one aspect.
Optionally, the Messaging Campaign Manager system, MCM system, further comprises an outbound message module, OMM, for forwarding of Messaging Campaign Manager, MCM, output as an outbound message to at least one recipient or second device.
Optionally, the Messaging Campaign Manager, MCM, system further comprises an inbound message module, IMM, for receipt of a reply message to the MCM from a recipient or second device for forwarding to the call back, CB, module. Further optionally, the inbound message module, IMM, is arranged to comprise a message transfer node, MTN.
Optionally, the Messaging Campaign Manager, MCM, system further comprises a multimedia messaging gateway, MMSGW.
Advantageously, these features provide means by which e.g. a user or Enterprise can process incoming replies from customers based on the user or Enterprise's pre-defined, fully-customized logical rules and conditions. Furthermore, the features provided facilitate the forwarding or transfer of replies to a multitude of integrated external connections—be those contact centres, data-stores or other systems capable of receiving inbound communications. There is also the option of formatting communications in a particular way or to a particular known standard for said communication.
Optionally, the Messaging Campaign Manager, MCM, system further comprises a first device, the first device comprising a graphical user interface, GUI, suitable for receiving input from a user of the first device for configuration of an input message to be processed by the MCM or a user instruction, wherein the graphical user interface, GUI, is accessible via a web-portal or a front-end or client-side application, and/or,
wherein, if a user instruction is received, the user instruction specifies a rule applied to the outbound message or bulk or mass message(s) processed by the Messaging Campaign Manager, MCM, system, and/or,
wherein the web-portal or the front-end or client-side application is administered or maintained by a provider of the Messaging Campaign Manager, MCM, system.
According to a third aspect of the present invention, there is provided a bulk or mass messaging system comprising at least one MCM or at least one MCM system.
According to a fourth aspect of the present invention, there is provided a method of bulk or mass messaging, comprising the steps of:—
Advantageously, the MCM facilitates the processing of a bulk or mass message according to user defined instruction through a rule-led procedure, including the output of a processed message, suitable for delivery.
Advantageously, the MCM device (or instance) is particularly suitable for ultra-high throughout campaigns. Here, ultra-high throughput refers to a normal achievable operational throughput (or capacity) of around 75,000 messages per hour (which can be bi-directional), or 1,800,000 messages per day, or 21 messages per second.
Preferably, the MCM operates on fully cloud-based architecture. Consequently, this is advantageous in response to rising capacity requirements, as the resources available to the MCM can be scaled upwards easily and rapidly. In practical terms this can mean scaling up the implementation means for operation of the MCM.
Such scaling provides virtually limitless capacity, as opposed to that available by means of dedicated hardware, usually situated at the side, or site, of the user.
Optionally, the method includes the step of:—
Advantageously, this facilitates easy access to a user from a first device and convenient, easily understood, tools for forming or editing a mass message where required.
Optionally, the method includes the step of:—
Advantageously, the GUI allows the user to directly access the MCM, removing the need for the user to have hardware or software related to the MCM functionality on a first device or an associated dedicated application.
Optionally, the method includes the steps of:—
Advantageously, this facilitates a more robust MCM operation and a broader scope of application.
Optionally, the method includes the step of:—
Advantageously, this permits output to be rendered suitable for a particular destination of device.
Optionally, the method includes the step of:—
Advantageously, the provision of a message queue facilitates autonomous operation of the Messaging Campaign Manager, MCM (or MCM system).
Optionally, the method includes the step of:—
Advantageously, the plug-in enables customisation, such as but not limited to, an extension to existing capabilities of the device, instance or program, the addition of a new feature(s) or upgrade(s), the reduction of the size of an application which must be installed on a main device, text editors, etc.
Optionally, the method includes the step of:—
Advantageously, the MCM comprises the ability to parse, route, and manipulate an original message with additional functionality such as masking (e.g. of private information such as credit card details or addresses) and routing of any reply messages away from the user or originator of the bulk or mass message. Additionally, routing in either send or receive directions can be facilitated with non-native systems.
Optionally, the method includes the step of:—
Cloud-based implementation is particularly advantageous—for example, in terms of scalability and throughput. Known systems are confined by hardware-based implementations, in at least one aspect.
Optionally, the method includes at least one of the step(s) of:—
Advantageously, these features provide means by which e.g. a user or Enterprise can process incoming replies from customers based on the user or Enterprise's pre-defined, fully-customized logical rules and conditions. Furthermore, the features provided facilitate the forwarding or transfer of replies to a multitude of integrated external connections—be those contact centres, data-stores or other systems capable of receiving inbound communications. There is also the option of formatting communications in a particular way or to a particular known standard for said communication.
According to a fifth aspect of the present invention, there is provided a computer program comprising instructions which, when the program is executed by a computer, cause the computer to carry out the steps of the method.
According to a sixth aspect of the present invention, there is provided a non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the steps of the method.
According to a seventh aspect of the present invention, there is provided a graphical user interface, displayed on a computer screen of a first device, for receiving user input, suitable for configuration of a bulk message by a Messaging Campaign Manager, MCM, said graphical user interface comprising:—
Advantageously, the GUI allows the user to directly access the Messaging Campaign Manager, MCM, removing the need for the user to have hardware or software related to the MCM functionality on a first device or an associated dedicated application.
The various embodiments of the present invention will now be described in more detail by reference to the figures. These examples are for illustrative purposes and should not be considered as limiting. Where reference numerals indicate a specific feature which is consistent across the figures, the associated reference numeral is kept similarly consistent.
A Messaging Campaign Manager (MCM) according to the provisions of the embodiments of the present invention is a device, or instance, to facilitate the construction, deployment, delivery and on-going management of high throughput, multi-channel campaigns. The MCM is described herein in terms of (Short Message Service) SMS messaging but this should not be considered as limiting. The MCM is applicable to other types of messaging, such as (Multimedia Messaging Service) MMS, Facebook® messaging etc. An advantage of the MCM is that it can be configured to handle many different types of messaging. This provides a wide range of output possibilities from the MCM to a wide range of providers or recipients. The MCM can also be configured to comprise adherence to many different formats, programming languages, protocols, communication standards etc. which may be inherent in different types of messaging. Further advantageously, the MCM facilitates extensive handling of replies to any delivered messages from one or more recipients.
A MCM (device or instance) is particularly suitable for SMS messaging.
As previously indicated, the art is restricted to offering only escalation or forwarding of incoming messages to their own proprietary systems. This may be limiting and problematic. Conversely, the MCM can enable connection to a plurality of third-party systems, said third party systems being capable of accepting incoming messages with the purpose of forwarding or escalating, be that to a human agent or to a further programmatic system (e.g. BOT). The ability of the MCM to escalate or forward to third party systems beyond what is offered by the provider of the art, is highly beneficial and advantageous, as it removes the restriction or reliance on certain proprietary systems. Such an ability can be utilised when constructing any set of rules which shall apply to incoming messages as part of the MCM processing. An example of one such rule can be the escalation or forwarding, as described.
Additionally, the MCM can act cooperatively with other components of a system in order to provide additional services e.g. extra processing of a message or special delivery requirements (e.g. language or format tailored to a device to which the message must be delivered or specific timing). For example, the MCM can act cooperatively with a Message Transfer Node (MTN) or Message Transfer System (MTS) or Multi-Media Messaging Service Gateway (MMSMG), these being described in, e.g. patent applications PCT/IB2017/051548 (MTN and MTS) and PCT/US2016/037592 (MMSGW). Said patent applications relate to United States patent application U.S. Ser. No. 15/072,440 and U.S. Ser. No. 15/183,261, the contents of which are incorporated by reference, herein. Examples of said cooperation will be described later.
The MCM is especially suited to the needs of business or Enterprise users. Enterprises, including (but not limited to) examples such as businesses, government organisations, clubs, social networks, call centres etc. have reacted to the changing technologies by ensuring their presence and availability to a user in a variety of ways, including various communication options. Enterprises frequently provide chat services, voice call services, email capability, social media presence e.g. Facebook® and Twitter™ accounts, dedicated websites or web portals, in order to interact with the user. Indeed, the public at large now anticipate at least one or more of such services to be present by default and the Enterprise gains advantage by providing a plurality of communication options. In the context of this application, we refer to Enterprises, (defined according to common usage) as businesses or companies or other related entrepreneurial activities. For example, SME's (small to medium sized Enterprises) are generally referred to as small to medium sized Enterprises, dependent on the company size or business financial turnover. Enterprises may also be considered as any group or organization providing services to customers, with whom it may wish to communicate through a variety of disparate channels or communication types. In particular, this communication may comprise automated messaging, person-to-person messaging, or a combination of the two.
Current provision of such a broad range of services and communication possibilities does present difficulties, however, not only to the Enterprise but also to the user. In order to access a dedicated website belonging to an Enterprise, the user relies on access to an application (APP) present on whatever device is available to them e.g. a mobile device or computer. The user device normally comprises an application programming interface (API) with which the APP is cooperative. In another common arrangement, the APP may poll directly, for information or contact or connection with other devices outside the environment of the user device, such that the APP is in direct contact with the outside world beyond the user device. The APP then facilitates particular functionality, often associated with a particular Enterprise. Examples of APP's for web browsing include, for example, Safari or Explorer. Frequently, the user will want to use a mobile device, such as a smart phone, so as to collect information as easily as possible, on the move, or to retain everything on one device which is usually present with them. In order to access a different kind of information, such as a Facebook® account of the Enterprise, the user must have a Facebook® application (Facebook® APP) installed on their mobile device. Most mobile devices comprise capability or applications (APP's) for various forms of direct communication, such as text messaging (e.g. SMS, MMS, Messenger®) or web chat or voice call. Most Enterprises will have similar provisions at their side to allow interaction. In some cases, the Enterprises comprise contact centres, which facilitate different links of communication with options for chat, messaging and/or email. A provision for call back to a user if the Enterprise is busy, is frequently a further option.
An example of the website or cloud of
Similarly,
Examples of the provider 4 (and message processing) of
Limitations of such systems available in the current art include:—
For example, Avaya® POM is limited in capacity and speed by the nature of the architectural infrastructure of the system. Dedicated hardware (i.e. physical systems) comprises an inherent response depending on characteristics of components, such as CPU (central processing unit), RAM (random access memory), Bandwidth and the like.
MCM (Messaging Campaign Manager) 8a 8b is a device (or instance, e.g. of software running on a device) built to facilitate the construction, deployment, delivery and on-going management of e.g. multi-channel SMS campaigns. The device (or instance) is particularly suitable for ultra-high throughout campaigns. Here, ultra-high throughput refers to a normal achievable operational throughput (or capacity) of around 75,000 messages per hour (which can be bi-directional 6a 6b 6c), or 1,800,000 messages per day, or 21 messages per second. By comparison, systems in the art, such as Avaya® POM are indicated to handle 3,200 messages per hour, while Adobe® CM may achieve 8,300 messages per hour or 200,000 inbound interactions per day. Adobe® CM may also be limited by package or license restrictions which act to limit the technically available throughput.
Preferably, the MCM operates on fully cloud-based architecture. Consequently, this is advantageous in response to rising capacity requirements, as the resources available to the MCM can be scaled upwards easily and rapidly. In practical terms this can mean scaling up the implementation means for operation of the MCM. Such scaling provides virtually limitless capacity, as opposed to that available by means of dedicated hardware, usually situated at the side, or site, of the (first) user.
One or more MCM instances can be installed on any cloud provider, preferably a cloud administered and controlled by the MCM provider, or alternatively on a third-party cloud administered e.g. by Amazon or on a cloud associated with user or client premises. The cloud comprises a server at a different location from the user (near or far). The MCM provides tenancy to a user, with at least one MCM instance per user, known as ‘single tenancy’ or multiple MCM's to the user, known as ‘multi-tenancy’. The provision of database(s) and application(s) APP(s) and Rules Engine(s) RE(s) to the MCM instance(s), provided in a secure VPC for a user, facilitate the rule-based activity and operations of the MCM message processing.
In this illustrative embodiment, the MCM 8a 8b shown in
The MCM enables Enterprises (users) to interact with their customers or clients in a customized, user-centric and automated fashion. The MCM e.g. provides the Enterprise a means by which they can process incoming replies from customers based on the Enterprise's pre-defined, fully-customized logical rules and conditions. Furthermore, the MCM facilitates the forwarding or transfer of replies to a multitude of integrated external connections—be those contact centres, data-stores or other systems capable of receiving inbound communications. MCM is not limited to simply communicating with proprietary, first party software owned by the Enterprise, business or company. Instead the MCM provides unparalleled access to the most widely used contact centre software and processes offered by major industry leaders.
The MCM is preferably cloud based but can also be implemented by computing apparatus, as shown in
Referring now to
However, it is also possible for the MCM 8a 8b to be distributed across different devices or servers.
Each instance of the MCM 8a 8b is preferably related to a particular user, and is restricted to its own Virtual Private Cloud (VPC). (The VPC is not shown in
Components of the MCM reside inside the VPC and are configured to communicate over private sub-networks or subnets. Such subnets are not accessible to external communication but, instead, communicate with the (hardware) components within the VPC and according to security policies defined on a per component/instance level, said polices comprising at least inbound and outbound rules.
If desired, multiple Virtual Private Clouds, VPC's, can be arranged to run on a common physical server or on a plurality of physical servers. Or, a single VPC can be run on a plurality of servers, arranged as distributed across them. The security of a VPC environment dedicated to a particular client can be implemented according to the security level achieved in its implementation. As discussed later, a user or Enterprise can comprise one or more dedicated MCM's, in the secure VPC, and the number of MCM's can be easily (and advantageously) scalable within the VPC according to user need or demand.
The MCM 8a comprises of
Use of the VPSA 9 to locate a GUI for user access to the functionality of the MCM is advantageous to the user, as no special hardware or software is required by the user. The VPSA 9 is not restricted to only a GUI or only an input but can also comprise a combination of options, e.g. input and GUI located on the VPSA, providing two options for the user, or more options if desired. The input can comprise an endpoint for a GUI not located on the MCM itself, e.g. located on a first device 1a 1b of a user, facilitating access to the MCM functionality and VPSB 10. The GUI or customer facing user interface can, alternatively, be located on a first device 1a 1b associated with the user or software associated with the MCM instance, e.g. an input application (APP), as discussed later, can be provided on the first device 1a 1b. The GUI or customer facing user interface or APP assists the user in performing the technical task of input to the MCM by means of a human-machine or human-instance interaction process. The VPSA 9 can be comprised in the VPSB 10, if desired.
Preferably, VPSA and/or VPSB are arranged to run on a Linux operating system, including the Ubuntu distribution. Ubuntu 18.04 is preferred. The operating system (OS) supports the Virtual Private Servers (VPSA 9 and VPSB 10) where front and back end application code can reside.
In the context of the MCM described herein, a server is defined interchangeably in terms of hardware components and/or cloud-based components. A server is usually defined as a computing device configured to provide functionality to other computing devices, which may initiate a connection to it whilst also providing input. A device which initiates such communication with a server is usually known as the ‘client’. In the context of the MCM, a client-server model can describe one possible method of communication between the MCM and its source of input. This should not be considered as limiting, however. Generally, a server can be further categorised according to its specific, required function. For example, a database-server (e.g. DBA 11) is a server with the capability and/or objective of storing and allowing retrieval of data. An application server is a server configured to provide the ability to process inputs, execute functionality and return outputs or information. A web-server is a server with the objective of accepting incoming HTTP network connections and rendering web-pages containing information generated by the application server. These web-pages are rendered on the device or client.
MCM application servers (VPSA 9/VPSB 10) host all the necessary application code and logic. Configuration: capable of receiving input from the client, processing the input according to its contained application logic, completing desired actions based on such logic and subsequently returning an output or response to the originating client. During the execution of their operations, servers can communicate to other connected servers in order to complete tasks, such as but not limited to, gathering data-sources or executing further actions. Cloud based servers, which are those that are preferably utilised or comprised within the MCM architecture, refer to servers created using virtualisation software. This is as opposed to non-cloud-based servers, which comprise servers that reside solely on physical hardware devices.
In an alternative embodiment of the present invention, the VPSA 9 is replaced by an input module, optionally comprising an API (application programming interface), located on VPSB 10.
Optionally, as shown in
The MCM receives input or instruction, e.g. from a first device 1a 1b or means associated with a user of the MCM application (not shown), including the mass message to be distributed. This is received by VPSA 9 across an internet connection to the MCM from the first device (not shown). Processing of the message for bulk distribution occurs at the MCM (predominantly at VPSB 10) and the various messages of the bulk sending are output (not shown) from the MCM towards the relevant providers or systems for distribution to a second device (not shown) associated with an individual recipient.
(Optionally, the MCM can comprise additional inputs (not shown), e.g. an input API located on the MCM instance itself. This may depend somewhat on the method chosen by the user of the first device 1a 1b to interact with the MCM (system)).
In the figure, three MCM instances 8a 8b are shown. The illustrated combination of MCM instances and the number of said instances should not be considered as limiting, nor is it necessary to provide at least one of each type of instance 8a 8b.
The MCM system 14 is comprises a VPC (virtual private cloud) 15 associated with a user (not shown). Location of MCM instances 8a 8b within the VPC 15 is advantageous for the security of the MCM system for the user. The VPC 15 shown here is dedicated to the user.
The single customisable output 16 shown in the figure should not be considered as limiting. More than one customisable output component can be provided to the MCM, each output comprising a particular desired characteristic or at least one output comprising a characteristic different from other outputs of the MCM 8c. In other words, more than one customisable output 16 is possible on a single MCM, the outputs being configured either different from each other or comprising (some or all) multiple instances of the same output. The customisable output enables the MCM to interact with a wide range of different message destinations or hardware. As each instance of the MCM is preferably dedicated to a particular user, the customisable output(s) can be provided on the MCM according to the user required configuration. Optionally, the customisable output(s) 16 can be switched on or off according to need, such as when a message is due to be output to a particular destination, such as a chosen service provider or recipient.
An example of a customisable output component is an SMS Dispatcher API (see
For autonomous operation, a MCM instance is provided with a dedicated message queue 17: the queue effects a ‘store and forward’ facility. The autonomous operation can be effected e.g. over a predetermined time frame as desired or as a fall-back, e.g. in the event that the MCM is unable to connect with other devices or instances. The MCM is also pre-provisioned with account information associated with the user in the database DBA 11. This is made possible by the arrangement where a particular MCM is dedicated to a particular user in a virtual private cloud, thereby removing security concerns which would arise in known systems where a cloud is shared between all clients or users of the system. The message queue 17 can, alternatively, be arranged as a distributed message queue between MCM instances, if more than one MCM is located in the VPC 15 (not shown).
When the MCM is operated cooperatively, with other devices or instances not part of the MCM system 14, as will be described later in connection with e.g. an MTN (message transfer node), the MCM fulfils the role of applying the required user instruction to a (bulk) message to be sent, in accordance with rules, previously set in the MCM according to wishes of the client or user, while the actual message transfer to various destinations can be fulfilled by e.g. the MTN.
Alternatively, the MCM 8d of
Alternatively, the message queue(s) 17 can be located on VPSB 10.
In this instance, the plug-in relies on the MCM and is tailored to work cooperatively with the MCM. In other words, the MCM is an instance or device which can operate without the plug-in but the plug-in requires the MCM to operate. Among other uses, the MCM instance can use a plug-in for updates, additional functionality, additional data storage, etc. These examples should not be considered as limiting.
Referring now to
Referring now to
A plug-in 18a 18b, as shown in either
A plug-in 18a 18b interface to a MCM is preferably configured in a specific format, such as a (chosen) JSON format. Use of such a format facilitates communication across a wide range of other third-party devices or instances. Alternatively, the MCM can be host to a particular software or processes which allow communication with an external party for the receipt of information originating at the external party and/or for return of information back to the MCM. This option is particularly useful for an MCM 8d operating in an autonomous manner but can be applied to other embodiments of the MCM 8a 8b 8c 8e.
Any previously described MCM 8a 8b 8c 8d 8e is suitable for incorporation into the MCM system 20, either alone or in combination with at least one other MCM.
Referring to
Referring to
A bulk message sent out from a user by means of first device 1a is sent to MCM 8a comprised in the MCM system 20 and processed according to pre-determined rules. The MCM 8a then outputs, among a plurality of messages sent to a plurality of specified recipients, optionally using a variety of different formats or service providers, at least one message for an intended recipient to be routed through the appropriate service provider 4. For example, the outbound message can comprise a SMS message, directed through a text message service provider, for second device 2 which comprises a mobile device of the recipient. The recipient receives the message, which e.g. asks for confirmation of an appointment by text reply of Y for yes or N for no. The recipient types Y and sends a reply message back to the service provider 4 which is then sent back to the MCM 8a. According to the configuration of the MCM 8a, rules are applied which determine that the reply message should be sent to BOT 22, which is accumulating all replies concerning affirmative or negative responses to the original message. As indicated by arrow 24, it is possible to configure the BOT to communicate back to the MCM, as well as receive a message from the MCM, for exchange of updated information or to confirm receipt of the reply message at the BOT 22.
Should the BOT 22 be unable to process the reply message (perhaps a reply other than Y or N is present in the reply message, for example), the MCM 8a is configured to receive a refusal of receipt from the BOT 22 (or other indicator as specified in the rules of the MCM 8a or the configuration of the BOT 22 itself) and, in such a circumstance, to redirect the received reply to a human operator 23. As indicated by arrow 25. (Again, the interaction between human operator 23 and MCM 8a can be one- or two-directional, as shown by arrow 25). This can be achieved by a variety of known means, but is especially suitable for forwarding of the original reply SMS or text. The human operator 23 may be part of a contact centre, for example, where a plurality of agents can assess incoming messages and act according to the information presented to them. For example, if the MCM is configured to send an alert message on receipt of the refusal from the Bot 22 then the human operator 23 can be triggered to contact the recipient directly by text or by another means, such as voice call or instant messaging. This allows the human operator to ascertain the required reply information concerning the original bulk message sent out. At the same time, the user associated with the first device 1a 1b is not required to take action in response to a reply.
The example outlined is capable of implementation in many ways and the description above should not be considered as limiting. The MCM facilitates an escalation mechanism, in the example above from an automated device or system to a human operator. Advantageously, the MCM facilitates sending of a bulk or mass message, tailored to at least one recipient, and direction of at least one reply message to at least one recipient (device or human) other than the sender. Further comprising another redirection (or more redirections) if needed or desired. Such processing is especially useful for businesses or Enterprises where a large number of recipients of a bulk message may be intended and speedy processing of any replies is required, with the replies possibly comprising important or large amounts of information needed by the business or Enterprise.
The MCM may 8c or may not 8a comprise a customisable output 16, tailored to the MTN, as shown in
International patent application PCT/IB2017/051548, published as PCT/2017/158558, discloses details of a message transfer node (MTN) 26 and message transfer system (MTS).
Ideally, one or more MCM's 8a 8b 8c 8d 8e are provided in a system (further comprising a virtual private cloud, VPC, not shown), cooperative with at least one Message Transfer Node (MTN) 26. The MTN 26 is not normally comprised as part of the VPC 15 (not shown) of the MCM system 20 (not shown), thereby securing the MCM system for the user. This should not be considered as limiting, however. The business provider of the MTN 26 is, preferably, also the provider of the MCM 8a 8b 8c 8d 8e and the cooperative system facilitates optimisation of processing. Within such an arrangement, the MTN 26 is, preferably, not provided on the same infrastructure as the (one or more) MCM instance(s). Ideally, the MTN 26 is located externally to the VPC within which the at least one MCM resides, the MCM communicating with the MTN over the internet, via encrypted HTTP network calls. The MTN 26 can be arranged as the message delivery agent or as an intermediary between the MCM and another service provider.
The MTN 26 is particularly advantageous in cooperation with a MCM, as a MTN facilitates translation of messages between different formats and languages, such that a very wide range of options are available as output from the MTN. This, in turn, provides a very wide range of possibilities for messaging to the second device 2 of the message recipient (not shown). Preferably, the MCM 8a 8b 8c 8d 8e connects to the MTN 26 via an API (application programming interface) call. Within such a connection details, such as account details of a customer, authentication parameters required by the MTN for operational routing of the messages associated with a customer's particular MCM instance, etc., can be comprised.
A message transfer node (MTN) 26 is capable of autonomous operation for defined periods of time or interaction with a Message Transfer System (MTS). The MTS also comprises administrative and operational components which provide e.g. information and up to date customer details. The system of message transfer is designed to provide an interface between a sender and a receiver. Such interfaces are then connected to delivery agents e.g. network operators. The MTN system permits the routing or forwarding of messages from source to an integrated third-party application or a specific destination. This allows for normally incompatible systems to receive and send message to each other. One MTN can facilitate a single instance for a plurality of connections, which would normally require a plurality of individual connection components. Also, the administrative data of the MTN can be shared with the MCM and used to add to or update rules or information on a user. This kind of cooperation between MTN and MCM is highly advantageous for the efficiency of message transfer and for providing an extended range of options with respect to message processing, such as formatting.
By way of example, Adobe® CM requires an external account to be configured in order to send SMS messages. Such an account requires the integration of third-party connectors such as, but not limited to: NetSize, Sybase365 (SAP SMS 365), CLX communications, Tele2, O2. Such connectors require their own setup with respect to their respective providers.
A MCM 8a 8b 8c 8d 8e configuration is more streamlined, requiring, for example, only an API (application programming interface) call containing the account number and credentials for the user's instance. An MCM is preferably configured with such information during deployment, thereby avoiding further configuration later. However, updated details etc. can be provided to the MCM after deployment.
Within the MCM 8a 8b 8c 8d 8e a flow can be defined for processing of an incoming message from a first device 1 (not shown). Such a flow comprises one or more rules, each of which comprises logic and processes required to process any incoming reply from a recipient, once a message is delivered to a recipient. Each rule facilitates a specific action based on the perceived contents of an incoming message from the first device, such as how to forward the message to an integrated third party or other recipient or second device. For a business or Enterprise, such third-party applications may take the form of contact centre software or a business specific system. An Enterprise may initiate a messaging campaign with bulk messaging destined for a large number of recipients. During construction of the campaign, by the Enterprise, for example by means of a user providing input to a graphical user interface (GUI) in network communication with the MCM, a flow can contain a rule requiring certain replies (from a particular user, for example) to be forwarded to an agent or third-party contact centre, based for example on content or time received (between certain hours, outside normal working hours, for example). Enabling such a rule is facilitated by the MCM while the outgoing message is e.g. relayed by or through the MTN 26. Message replies from the second device 2 (not shown) or recipient are then routed back through the MTN 26 to the MCM 8a 8b 8c 8d 8e, where the MCM applies further processing to the reply message.
The MTN 26 can also be used, advantageously, to provide interface with competitor providers or other types of systems. For example, the MTN can provide output to providers such as Twilio™.
The range and availability of messaging applications has rapidly expanded. Such messaging applications include text messaging, such as SMS (Short Messaging System or Service, suitable for short text messages up to a maximum length of characters) or multimedia messaging, such as MMS (Multimedia Messaging Service, an extension of core SMS technology which allows for the sending of images, such as photos or videos, for example). Development of messaging applications is often driven by the increasing use of mobile devices, such as portable phones. Instant messaging is available through applications such as Jabber™ and Skype®, which allow for exchange of text and files by internet users using a browser or an instant messaging client, and live chat systems such as LivePerson™ and Moxie® which provide chat functionality in websites, among other uses. Generally speaking, a user of these applications chooses to install a particular application on a (often hand-held, mobile) device and accesses the basic functionality through the device. A user may, further, create an account with a company, such as Jabber™, thereby creating a connection in order to access the functionality. The various messaging alternatives are thus accessed by conscious user choice and/or action.
Some companies, such as Twilio™, allow the use of their proprietary messaging applications (by mean of an account) in association with, or embedded in, other applications. The user can build-in parts of the Twilio™ application package as part of their own software product, while maintaining an account relationship with Twilio™. A mark-up language dedicated to Twilio™ is used and it is possible to initiate response to incoming calls or to initiate outgoing calls, for example. The functionality is targeted to provide communication access for sales and mass publicity, for example. The messaging options include SMS, phone calls etc. which can be accessed or connected across different media, such as web or phone connections. Particular language formats and software are available for incorporation into other products. Many of these exist in open source format, available to software developers and other companies, thereby allowing proliferation of the messaging applications. The Twilio™ product is based on cloud communication techniques to remove the need for reliance on traditional hardware. The cloud essentially acts as one large computing device, with components acting together in unison, each component relying on other components in real time and operational decisions being based on the status of the whole system. The system becomes a global entity, a resource for those connected to it by means of the application.
The implementation of messaging relies on a structure of basic protocols and industry standards. Each messaging system uses a propriety message transfer system to route messages between users. In the case of SMS, these protocols have been traditionally implemented in telecommunications hardware systems. More recently, software-based SMS systems have been developed which implement some, or all, of the SMS protocol in software running on servers. Kannel is an example of such an SMS system implemented in software. In the fullest terms, Kannel operates as a gateway to WAP (Wireless Application Protocol) infrastructure, thereby allowing access to a wider user base. In terms of mobile devices and messaging, it provides an SMS gateway for GSM (Global System for Mobile communications, relating to protocols for cellular networks used by mobile phones) networks. The software is provided as open source and therefore is publicly available. Increasingly, development of the internet is driving increasing use of software for communication products.
At the side of the second device 2 (not shown) or recipient, therefore, a significant number of messaging and communication options are available. By forming a system comprising the MCM 8a 8b 8c 8d 8e and the MNT 26, a highly efficient message processing and delivery can be achieved, especially advantageous to the plurality of recipients addressed by bulk or mass messaging.
The messaging gateway (Multimedia Messaging Service GateWay, MMSGW) 28 shown in the figure is arranged in association with a call centre as the second device 2 associated with the recipient. Such an arrangement facilitates a business or Enterprise to make use of an alternative reply route to an existing part of the company, which may be a completely different department from the origin of the bulk or mass message to be sent. Alternatively, as indicated by arrows 29a 29b, the call centre can originate a bulk message for sending, the call centre then being both the first device 1a 1b (not indicated) and the second device 2. The messaging direction can be single direction towards the call centre from the MCM, if desired, but a two-way communication is advantageous.
International patent application PCT/US2016/037592, published as WO/2016/205344, discloses details of a MMSGW messaging gateway. An advantage of the MMSGW is the ability to provide visibility of communications and history between a call centre and a user and/or a business and said user, while providing a secure environment for the information without the need for incorporation into a business system. The call centre may not be a part of the business and access to business systems, which would normally store such information, would usually be prohibited. The MMSGW stores relevant communication information as an intermediary between the business and the call centre, to provide accessibility of necessary and relevant information without compromising the business. The MMSGW information can be accessed by both business and call centre. Interaction of the MCM with the MMSGW is therefore highly advantageous, as the MCM is message handling towards a MMSGW component also specifically dedicated to message handling and can receive replies from the MMSGW, if desired.
The preferred embodiment illustrated in
The first device 1b is shown to include not only an input API 7 but also a graphical user interface, GUI 31, associated with the MCM 8a. The input API 7, GUI 31, or other input options such as a website, not shown, are available to a user of the first device 1b to send instruction to the MCM 8a. The user may have access to only one option or a plurality of options from the same device 1. Alternatively, first device 1a may be used and the MCM 8a accessed via internet communication.
Alternatively, in another preferred embodiment of the present invention (not shown), input comprises a GUI (not shown) for direct access of a user to the MCM 8a with capability to configure a message for input to the MCM, monitor messaging progress, or receive reply messages. This GUI is preferably arranged as resident on a first virtual private server, VPSA. The GUI facilitates tailoring of a message to required format, with rules to be applied, provision of rules associated with the user etc.
In the example shown in
The figure shows the main components of the MCM 8a, namely VPSA 9, VPSB 10 and DBA 11. As previously discussed, virtual private server, VPSA, 9 is configured to serve a customer facing interface or GUI 31 or other means through which the user can interact with the MCM (and application(s)), which can be located on the MCM itself, and/or implement required functions. Database DBA 11 comprises the ‘master’ data store comprising MCM relevant data, e.g. data required for the information relating to messaging campaigns and bulk or mass messaging, rules logic to be applied, recipient contact details, customer details, etc. VPSB 10 is shown (dashed line) in expanded form in
Handlers and Controllers (H&C) module 32: this module is responsible for flow control of the processing of the message and information required by the CM module, through the MCM from receipt at the VPSA 9 to delivery of bulk messages to the SMS Dispatcher API 30.
Campaign Manager (CM) module 33: this module is responsible for the handling and processing of the message received from the first device 1b into the required form for sending as an outbound message(s) and, consequently, interacts with many other sub-modules of the MCM 8a. The sending of one or more outbound messages is referred to here as a campaign. The CM module 33 is preferably configured to contain the code which is responsible for the scheduling of recipients/contacts within the MCM system 20. Planned scheduling allows optimisation of processing for the user and the efficient use of MCM resources. So-called ‘campaign throttling’ can be implemented, by staggered sending of messages of a particular campaign to avoid overload of the system and to avoid a wave of reply messages arriving back into the MCM system in a short timeframe. The CM module 33 is also responsible for the processing of those contacts based on rules/parameters attached to them e.g. name, number, address etc. The CM module is preferably configured to only process such contacts that have not been previously processed. Such restrictions may be due to a recipient having just been added to the campaign or, in some cases, where the recipient/contact has been attached to a campaign which is scheduled to be processed at a certain time. The CM module 33 is configured to determine which campaigns should be run and at which date/time. When the time to process a campaign and its attached contacts—has arrived, the CM module 33 is configured to create a contextual state for each contact-campaign pairing. A user-defined flow, containing processing rules, is then applied to the reply from each contact as it is received. Contained in this flow can be various rules which the user has constructed in order to apply conditional process method or logic to each reply from a contact during the course of an active campaign. Such process or logic is used to determine actions that can be triggered based on evaluation of each rule against a reply.
Application (APP) 33a: this module comprises at least one pre-defined rule or set of rules pre-determined by the user or Enterprise and communicated to the MCM 8a. The APP 33a is arranged to comprise at least Flow rules, Flow rules being applied to inbound messages. For example, this APP 33a assists with implementing e.g. a redirection of a reply message to a destination other than the first device 1a 1b, as previously discussed. One or more APP's 33a can be provided, such APP's providing the user, or Enterprise or originator of the message for bulk distribution, with an ability to store and/or re-use such Flow sets which the user may wish to regularly apply to more than one campaign.
Rules Engine (RE) 33b: this module applies pre-determined rules to the message to be processed by the CM module 33. The RE module 33b comprises the basis for processing, formatting and sending the message according to instruction from the user or Enterprise, facilitating any bulk or mass message to be tailored to each or a group of recipients or contacts. Processing by the MCM is arranged to continue through each applicable rule until either further input from the user of the first device 1b is required or until a pre-determined processing point has been reached or unless the processing is scheduled to run at a later date or time. Once processing has ceased, the CM module 33 will update the current context for that particular recipient (or contact) within the MCM system 20, optionally, updating the DBA 11. The CM module 33 is configured to receive and process input from any recipient (or contact) that is associated with any campaign known to or within the system. This component allows the MCM system to check whether or not processing of contact(s) is permitted at a certain time and if so, provides the ability for certain user-configured variable to be applied to the processing. Examples of conditions which the component/CM module 33 can implement include, but are not limited to:
Comprehensive rules in the RE module 33b can provide e.g. masking application (to remove sensitive information from a message, such as credit card details or addresses, and routing. Other features can comprise rules relating to e.g. dictionary or pattern matching, components being included in the MCM RE.
Data Sources Connector (DSC) module 34: this module is responsible for interaction with the DBA 11 (or other internal MCM database(s)) and for maintenance and application of data information used by the CM module 33, including data on external contacts or sources. The DSC module/component 34 is configured to comprise the functionality controlling how the MCM system 20 will connect and interact with any number of data-sources/stores which reside outside of the system's own internally associated database (e.g. DBA 11). For example, such sources can include some or all of the following:
Call Back (CB) module 35: this module facilitates the processing of inbound messages (replies) to the MCM 8a. Preferably, a single CB module 35 is responsible for the processing of inbound reply messages from recipients associated with a campaign. The CB module 35 is also effective in the escalation or forwarding of a message reply based on multiple parameters, such as message content and/or time of arrival to multiple end points or recipients (BOTs, artificial intelligence (AI) BOT's, contact centres, websites/databases, archives etc.). The CB module 35 can comprise parsing capability or parser component(s) for inspecting incoming messages.
The MCM system 20 as shown in
The MCM system 20 preferably comprises system integrity controls (not shown), such as authentication and authorization.
Authentication is the process of confirming the identity of a (current) user associated with the first device 1. Within the MCM system 20, authentication is preferably arranged to operate as follows:
Authorisation is the process of ensuring that a user has the necessary permission to carry out a desired task, access a piece of data or utilize certain. Within the MCM system 20 authorisation is preferably achieved as follows:
Referring to
The output of a graphical user interface (GUI, e.g. as shown in
The various embodiments of the present invention can also be provided as distributed or cloud-based systems (preferred). Advantageously, the MCM and/or MCM system can be implemented as entirely cloud-based. This limits cost to a user in terms of hardware and maintenance and further allows for easy and speedy scalability, if required.
Messaging user(s), such as users utilising at least one smart phone or other mobile device, may be provided messaging capability by means of messaging platforms. Examples of messaging platforms include but are not limited to: SMS, MMS, (Facebook) Messenger®, Google and/or Viber®. Various messaging platforms operate by means of established means, methods and protocols. An Enterprise or business may comprise a chat or contact centre. Examples of chat and contact centre vendors include but are not limited to: Cisco®, Avaya®, eGain®, Oracle® and/or Salesforce®. Intermediary services may include (artificial intelligence) AI systems, virtual agents and/or automated ‘bot’ services.
Access of a user of the first device to the MCM system can be facilitated by e.g. web-portal and/or API via a front-end that is web-based or that is incorporated in or cooperative with a separate input APP 7, as illustrated in
More particularly, a GUI 31 (not shown) comprising an interface (preferably a visual interface) by which the user of the first device 1 (not shown) can access the MCM 8a 8b 8c 8d 8e (not shown) is a preferred method for input of instruction from the user and the specification of rules to be applied to the outbound message or bulk or mass message(s) to be processed by the MCM system. The GUI facilitates access and operation of the MCM by the user of the first device. The GUI (and the first device where appropriate) including any associated input/output devices (not shown) such as displays, touchscreens, keyboards, mice, operational keys and buttons, and the like, together thus constitute one preferred example of a human-machine interface. The GUI can be incorporated in or cooperate with a separate input APP 7, as illustrated in
The GUI 31 is preferably web-based and accessible by means of a web browser. Navigation in the GUI 31, is preferably facilitated by means of a web browser which is directed to a URL (uniform resource locator, i.e. an address of a World Wide Web page) designated to the user's private instance of the MCM. As indicated above, the GUI 31 can additionally or alternatively be a front-end of an APP 7. The GUI facilitates the user to interact with various functionalities provided by the MCM and to tailor or choose such functionality to their own requirements. Navigation in the GUI 31 can be facilitated by a menu or like navigation structure. For a web-based GUI 31, each screen can also be accessible directly via a unique URL, sub-domain, or like address.
Referring now to
The MCM system can also be configured to enable ‘campaign reporting’, either by inspection of the GUI or by requested export of data from the MCM to the user of the first device.
Similarly,
Referring now to
An example of a rule set definition (comprising at least one rule but more frequently a plurality of rules), used by the Rules Engine 33b is shown below. This rule set definition is configured in JSON format, a preferred format to be utilised by an MCM but particularly useful in the Campaign Manager 33. Rule set definition or individual rules can be stored in the first database server, DBA 11.
A user input message or user instruction can be processed by the MCM as part of a campaign, which can be set up and managed using e.g. the screens on a graphical user interface, GUI 31, as shown in
Preferably, each step comprises a definition of a condition, an action if said condition is met and an indication of a subsequent step. However a step may comprise only one or more of these three parameters. An example of a step would be “START”: Condition: none needed; Action: send a message to a recipient; Next: wait for reply. While waiting for a reply, the step may comprise: Condition: check if office hours, Action: may depend on condition, Next: may depend on condition e.g. reply “we are closed”.
Consider the following exemplary flow, where each step in the flow is a “dict”/“hash” with the following structure:—
In the exemplary flow above, a step begins execution by running all defined conditions. This behavior is fully dynamic. Each condition can update any/all values in its own step and influence further processing. Primarily, the specified conditions update the values of “message”, “matched”, “action”, and “next”. After all conditions have been run (or after each condition, if immediate=True), the system will check whether the value of matched is True. If it is, it will run the action currently specified in the field action. Regardless of whether any actions have been run, it will then continue to the next Step specified in next. It will continue execution Step by Step until it reaches a Step which requires data that is not available (such as user's response). It will then stop execution and come back to it later automatically when data becomes available. If at any point (1) an action results in an error, (2) next remains undefined, or (3) the Step specified in next does not exist, the execution of the Flow on this Contact will be set to DONE and will not be processed again as part of current campaign run. If a Campaign ends (or is stopped) and is then restarted, all the previous data is disregarded and all execution begins anew.
Each condition is arranged as a flexible unit of execution which can run both pre-defined actions as well as custom Jinja templates. Due to the complexity of writing Jinja templates, this is preferably used in custom scenarios dedicated to a particular user. Jinja is a web template engine based on the Python programming language, which allows customisation of tags, filters, test etc. In normal use, pre-defined actions are preferred, for speed, ease of processing and reduction in errors during processing.
For example, a pre-defined action can comprise:—
While a more complex custom Jinja template can comprise:—
CUSTOM JINJA TEMPLATE
(Excerpt from “match_message” which was implemented in Jinja for test.)
{#1. Remove leading and trailing whitespace #}
{% if step.data[‘match_message’].trim %}
{% else %}
{% endif %}
{#2. Turn message to lowercase if case sensitivity is disabled #}
{% if step.data[‘match_message’].case_insensitive %}
{% endif %}
{#3. Update the original message with result of (1) and (2) #}
{% if step.data[‘match_message’].update_message %}
. . . and so on . . .
For maximum flexibility of MCM operation, Conditions and Actions are arranged as equivalent, call-able from both contexts. Usually, some Actions are preferable to execute as an “Action” and are some preferable to execute as a “Condition”. However, advantageously the MCM (e.g. as part of the rules flow and in other parts of the MCM backend) is configured to generalize some or all of its features, without restricting new ways of use or configuration.
For example:
Functionality of the MCM is enhanced by use of these Actions and Conditions in the manner as described above. Ideally, this functionality is available in a user-accessible format, such as through the GUI 31, input APP 7 and/or an API, as previously described. The rules applied by the Rules Engine, as part of the flow of an input message from the user through the MCM processing, to bulk or mass distribution to a plurality of recipients, can make use of these described Actions and Conditions.
Referring now to
It is particularly advantageous in the field of bulk or mass messaging to facilitate escalation of a response to a reply from a recipient. An embodiment of the present invention, as discussed above, allows the MCM to not only direct a reply to, but also to interact with, a BOT or automated programmatic recipient of a message reply. This enables the BOT to flag or return a message which e.g. does not conform to its expected format for processing. A damaged message, a message with inappropriate content or a message with content beyond a simple response expected by the BOT, for example, can all be handled by returning the ‘non-standard’ message back to the MCM. Upon receipt, the MCM facilitates quick and automatic forwarding to e.g. a human operator who can deal with the message context in a more appropriate way. Or other rules can be implemented by the MCM to forward to another destination or back to the first device of the user if needed, with various formatting options available automatically by means of the MCM and MCM system. Such breadth of (MCM) response provides flexibility in the handling and escalation of reply messages which might otherwise be lost or stored waiting for inefficient manual inspection, possibly at the side of a third party to which a user (of the first device) may have no direct access.
Advantageously, the MCM and MCM system of the present invention effect, among other things:—
Although embodiments of the invention are described in the foregoing, it will be appreciated that the present invention is also susceptible to being implemented in a variety of combinations of the different embodiments proposed and in various ways.
Modifications to embodiments of the invention described in the foregoing are possible without departing from the scope of the invention as defined by the accompanying claims. Expressions such as “including”, “comprising”, “incorporating”, “consisting of”, “have”, “is” used to describe and claim the present invention are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. Numerals included within parentheses in the accompanying claims are intended to assist understanding of the claims and should not be construed in any way to limit subject matter claimed by these claims.
| Number | Date | Country | Kind |
|---|---|---|---|
| 20159654.1 | Feb 2020 | EP | regional |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/IB2021/051120 | 2/11/2021 | WO |
