WO2012003534A1 - Gestionnaire de communications téléphoniques - Google Patents

Gestionnaire de communications téléphoniques Download PDF

Info

Publication number
WO2012003534A1
WO2012003534A1 PCT/AU2011/000846 AU2011000846W WO2012003534A1 WO 2012003534 A1 WO2012003534 A1 WO 2012003534A1 AU 2011000846 W AU2011000846 W AU 2011000846W WO 2012003534 A1 WO2012003534 A1 WO 2012003534A1
Authority
WO
WIPO (PCT)
Prior art keywords
call
conversation
node
merchant
map
Prior art date
Application number
PCT/AU2011/000846
Other languages
English (en)
Inventor
Darren Younger
Vinuraj Koliyat
John Niu
Original Assignee
Ipscape Pty Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from AU2010902979A external-priority patent/AU2010902979A0/en
Application filed by Ipscape Pty Ltd filed Critical Ipscape Pty Ltd
Publication of WO2012003534A1 publication Critical patent/WO2012003534A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/42—Systems providing special services or facilities to subscribers
    • H04M3/50—Centralised arrangements for answering calls; Centralised arrangements for recording messages for absent or busy subscribers ; Centralised arrangements for recording messages
    • H04M3/51—Centralised call answering arrangements requiring operator intervention, e.g. call or contact centers for telemarketing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/12—Setup of transport tunnels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M2203/00—Aspects of automatic or semi-automatic exchanges
    • H04M2203/35—Aspects of automatic or semi-automatic exchanges related to information services provided via a voice call
    • H04M2203/357—Autocues for dialog assistance
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/088—Load balancing or load distribution among core entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/12—Messaging; Mailboxes; Announcements

Definitions

  • the present disclosure relates to systems and methods for managing communication data.
  • the arrangements presently disclosed have been particularly developed for providing communication management functionalities via a scalable distributed architecture, for example in the context of a call centre or dial-out campaign arrangement. While some embodiments will be described herein with particular reference to that application, it will he appreciated that the present disclosure is not limited to such a field of use, and is applicable in broader contexts.
  • a system for managing communication data including:
  • a managing core configured for centrally managing a plurality of distributed nodes
  • each node being configured to execute:
  • a channel driver module that provides access to a plurality of communications channels including at least an incoming call channel and outgoing call channel;
  • a communications gateway component for managing communications between the node and the managing core
  • node application module that provides logic to drive node functionalities.
  • One embodiment provides a system including a load balancing layer for load balancing incoming calls, wherein the load balancing component receives data indicative of an incoming call from an external gateway, processes that data thereby to select a node for that incoming call, and provides an instruction for the external gateway to communicate directly with the selected node in respect of that incoming call.
  • the load balancing layer includes a plurality of distributed load balancing components, each load balancing component being configured to receive data indicative of an incoming call from an external gateway, process that data thereby to select a node for that incoming call, and provide an instruction for the external gateway to communicate directly with the selected node in respect of that incoming call.
  • One embodiment provides a system wherein the managing core is defined by a plurality of distributed sub-cores.
  • One embodiment provides a system wherein the plurality of distributed sub- cores are configured for intercommunication thereby to allow synchronisation of predefined selection of data aspects.
  • One embodiment provides a system wherein the plurality of nodes includes a first node within a first local system and a second node within a second local system, the second local system being distributed with respect to the first local system.
  • One embodiment provides a system wherein the plurality of communications channels include ingoing and outgoing Short Message Service (SMS) messages.
  • SMS Short Message Service
  • One embodiment provides a system wherein inbound SMS messages are matched to an SMS conversation database thereby to determine whether a particular inbound SMS message is a reply to a current conversation or a new conversation initiated by the sender.
  • One embodiment provides a system wherein, when an outbound SMS message is initiated, the outbound SMS message is placed into a conversation data store thereby to monitor conversations to which subsequent inbound SMS messages are matched upon receipt.
  • One embodiment provides a system wherein the plurality of communications channels include web-based chat channels.
  • One embodiment provides a system wherein the plurality of communications channels include channels for interfacing with social media.
  • One embodiment provides a system wherein each node performs a node heartbeat process by which the nodes each communicate with the managing core on a regular basis thereby to allow the managing core to manage the resources of the node.
  • One embodiment provides a system wherein, via the heartbeat process, each node repeatedly sends a request to the managing core to determine if there are any tasks for that node to perform.
  • One embodiment provides a system wherein, if there is a task to be performed, the managing core responds with that task, and the node notifies the managing core upon completion of that task.
  • One embodiment provides a system wherein each node performs its own self maintenance by requesting any latest changes from the ICC core and, if there is an upgrade to be performed, the node downloads and installs the required files from the managing core.
  • One embodiment provides a system wherein the media driver configuration for each communications channel is maintained by an automated process within each node, wherein the managing core publishes driver configurations and applications for release and each node checks the latest versions against its local settings and, if the node requires an update for a given channel, the node transfers the update from the managing core and re-initialises the channel.
  • a node for use in a system for managing communication data including:
  • a channel driver module that provides access to a plurality of communications channels including at least an incoming call channel and outgoing call channel;
  • a communications gateway component for managing communications between the node and a managing core configured for centrally managing a plurality of distributed nodes
  • node application module that provides logic to drive node functionalities.
  • a method for operating a node for use in a system for managing communication data including:
  • executing a channel driver module that provides access to a plurality of communications channels including at least an incoming call channel and outgoing call channel;
  • node application module that provides logic to drive node functionalities.
  • a computer program product for performing a method as described herein.
  • 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.
  • a contact centre system comprising: a plurality of nodes, each node having a plurality of call channels, the call channels being connectable to at least one communications network and including at least one incoming channel and at least an outgoing channel; and a managing core coupled to each of the nodes, the core comprising a data store with at least one call architecture of a merchant defining a call handling process for the merchant, the call handling process being operable to detect receipt by a first said node of an incoming call on a corresponding incoming channel, and to couple the call from said first node via one of said call channels thereof to a second said node for connection to an agent associated with the merchant.
  • a distributed communication management system comprising: a plurality of nodes, each node having a plurality of call channels ⁇ the call channels being connectable to at least one communications network and including at least one incoming voice channel and at least an outgoing voice channel; and a managing core coupled to each of the nodes, the core comprising a data store with at least one call architecture of a merchant defining a call handling process for the merchant, the call handling process being operable to detect receipt by a first said node of an incoming voice call on a corresponding incoming voice channel, and to couple the voice call from said first node via one of said call channels thereof to a second the node for connection to an agent associated with the merchant.
  • a call conversation mapping method comprising the steps of: creating a call conversation map that includes a plurality of objects and at least one connecting link to define a call handling process, wherein the objects include at least one task relating to receiving an incoming communication or generating an outgoing communication; activating the call conversation map in response to a trigger; and processing communications in accordance with the call handling process of the call conversation map.
  • a call conversation mapping system comprising: a conversation map for creating a call conversation map that includes a plurality of objects and at least one connecting link to define a call handling process, wherein the objects include at least one task relating to receiving an incoming communication or generating an outgoing communication; a data store for storing a call conversation map; a conversation triggers module defining a trigger for activating the stored call conversation map; and a conversation engine for activating the stored call conversation map in response to the trigger and processing communications in accordance with the call handling process of the stored call conversation map.
  • an apparatus for implementing any one of the aforementioned methods.
  • a computer program product including a computer readable medium having recorded thereon a computer program for implementing any one of the methods described above.
  • 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.
  • the term comprising, when used in the claims should not be interpreted as being limitative to the means or elements or steps listed thereafter.
  • 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/fearures that follow the term, but not excluding others.
  • “including” is synonymous with and means “comprising”.
  • FIG. 1 is a schematic block diagram representation that illustrates a logical software architecture.
  • FIG. 2 is a schematic block diagram representation that illustrates a load balancing arrangement for incoming calls.
  • FIG. 3A is a schematic block diagram representation that illustrates an arrangement for managing incoming SMS messages.
  • FIG. 3B is a schematic block diagram representation that illustrates an arrangement for managing outgoing SMS messages.
  • FIG. 4 is a schematic block diagram representation that illustrates an arrangement.
  • FIG. 5 is a schematic block diagram representation that illustrates a live data arrangement.
  • FIG. 6 is a schematic block diagram representation that illustrates a physical architecture for a distributed system.
  • FIG. 7 is a schematic block diagram representation that illustrates load balancing for a distributed system.
  • FIG. 8 is a schematic block diagram representation that illustrates a data clustering arrangement.
  • FIG. 9 is a schematic block diagram representation that illustrates a node architecture.
  • FIGs 10A and 10B collectively form a schematic block diagram representation of a computing system upon which described arrangements can be practised.
  • FIG. 11 is a schematic block diagram representation illustrating a contact centre system in accordance with an embodiment of the present disclosure.
  • FIG. 12 is a schematic block diagram representation illustrating connection of a call from a customer to an agent using the contact centre system of FIG. 1 1.
  • FIG. 13 is a flow diagram illustrating functionality of a node during the call connection of FIG. 12.
  • FIG. 14 is a flow diagram illustrating functionality of the contact centre system during the call connection of FIG. 12.
  • FIG. 15 is a schematic block diagram representation illustrating functionality of the ICC Core 101 of FIG. 1.
  • FIG. 16 is a schematic block diagram representation illustrating a
  • FIG. 17 is a flow diagram illustrating a method of utilising the communication management system of FIG. 16 to establish a voice call from a customer to a merchant agent.
  • FIG. 18 is a flow diagram illustrating a method of utilising the communication management system of FIG. 16 to establish a web-based chat session between a customer and a merchant agent.
  • FIG. 19 is a flow diagram illustrating a method of utilising the communication management system of FIG. 16 to establish an SMS message conversation between a customer and a merchant agent.
  • FIG. 20 is a screenshot of a call conversation map.
  • FIG. 21 is a schematic block diagram representation illustrating a logical architecture of a call mapping system.
  • FIG. 22 is a schematic block diagram representation illustrating an example of a contact library.
  • FIG. 23 is a flow diagram illustrating a conversation mapping method.
  • FIG. 24 is a flow diagram illustrating a conversation mapping method 2400 utilising the example of FIG. 20.
  • FIG. 25 is a schematic block diagram representation illustrating activation of tasks from the conversation map of FIG. 20. DETAILED DESCRIPTION
  • Described herein are systems and methods for managing communication data and mapping call conversations.
  • the present embodiments are directed to a cloud-based distributed architecture for managing incoming and outgoing communications. These communications occur over a range of channels, including voice-based channels (telephonic, for example), and messaging-based channels (such as email, SMS, multimedia messaging service (MMS), web-based chat, and so on).
  • voice-based channels telephonic, for example
  • messaging-based channels such as email, SMS, multimedia messaging service (MMS), web-based chat, and so on.
  • the purposes of communications vary between embodiments, and include the likes of providing customer support, such as through a contact centre system, and delivering marketing materials.
  • a contact centre system manages communications between an end user and a customer service
  • a call is an exchange of at least one communication between an end user and the contact centre system and may utilise one or more communication media, including, but not limited to, voice, SMS messages, emails, and web chat sessions.
  • the end user may be, for example, a customer, prospective customer, a merchant manager, or an agent of the merchant.
  • a contact centre is a call centre for handling voice calls.
  • the contact centre system includes a plurality of nodes and a managing core coupled to each of the nodes.
  • Each node has a plurality of call channels, including at least one incoming channel and at least one outgoing channel.
  • Each of the call channels is connectable to at least one communications network, which may include, for example, a wired or wireless communications link, or combinations thereof.
  • the managing core includes a data store with at least one call architecture of a merchant defining a call handling process for the merchant, the call handling process being operable to detect receipt by a first node, of the plurality of nodes, of an incoming call on a corresponding incoming channel, and to couple the call from the first node via one of said call channels thereof to a second node of the plurality of nodes for connection to an agent associated with the merchant.
  • the at least one incoming channel is a voice channel
  • the at least one outgoing channel is a voice channel
  • the incoming call received by the first node is a voice call received on a corresponding incoming voice channel.
  • the agent associated with the merchant advises the contact centre system of the availability of the agent through registration and login processes.
  • the agent may communicate with the contact centre system using multiple communication media, including a voice connection and a web connection.
  • the method creates a call conversation map that includes a plurality of objects and at least one connecting link to define a call handling process.
  • the objects include at least one task relating to receiving an incoming communication or generating an outgoing communication.
  • the method activates the call conversation map in response to a trigger and processes communications in accordance with the call handling process of the call conversation map.
  • the system includes a conversation map application, a data store for storing a call conversation map, a conversation triggers module defining a trigger for activating the stored call conversation map, and a conversation engine.
  • the conversation map application is for creating a call conversation map that includes a plurality of objects and at least one connecting link to define a call handling process, wherein the objects include at least one task relating to receiving an incoming communication .or generating an outgoing communication.
  • the conversation engine activates the stored call conversation map in response to the trigger and processing communications in accordance with the call handling process of the stored call conversation map.
  • An exemplary contact centre system includes a managing core, also referred to throughout this description as an intelligent contact cloud (ICC) core.
  • This ICC core is configured for centrally managing a plurality of distributed nodes.
  • the ICC core is implemented as a distributed component, defined by a plurality of synchronised sub-cores.
  • the system includes a plurality of distributed nodes, these nodes providing a distributed scalable resource for handling communications.
  • Each node is configured to execute a channel driver module that provides access to a plurality of communications channels. In the present example, these communication channels include at least one incoming call channel and one outgoing call channel.
  • Each node is additionally configured to execute a communications gateway component for managing communications between the node and the ICC core, and a node application module that provides logic to drive general node functionalities.
  • the ICC core and nodes provide a distributed software application.
  • FIG, 1 1 is a schematic block diagram representation of a distributed communication management system in the form of a contact centre system 1100, in accordance with an embodiment of the present disclosure.
  • the contact centre system 1100 includes a firewall 1 102 for regulating communications between the contact centre system 1100 and the external world, wherein the firewall 1102 is capable of handling various types of communications messages.
  • the types of communications messages may include, for example, telephony, Internet Protocol (IP) messages, and Short Message Service (SMS) messages.
  • IP Internet Protocol
  • SIP Session Initiation Protocol
  • the firewall 1 102 couples via at least one communication link 1103 to a communication network (not illustrated) for exchanging communication messages between the contact centre system 1 100 and externally located computing devices and telephone handsets.
  • the firewall 1 102 directs incoming communications messages to one of a Session Initiation Protocol (SIP) Gateway 1 104 and a Web Gateway 11 16, based on the type of the incoming SIP protocol (SIP) Gateway 1 104 and a Web Gateway 11 16, based on the type of the incoming SIP) Gateway 1 104 and a Web Gateway 11 16, based on the type of the incoming
  • SIP Session Initiation Protocol
  • IP Internet Protocol
  • the SIP Gateway 1 104 is coupled to a SIP Load Balancer 1 106.
  • the SIP Load Balancer 1 106 distributes incoming communications messages received by the SIP Gateway 1 102 among a plurality of nodes 1 108a, ..., 1108n.
  • each of the plurality of nodes is equipped with a plurality of call channels, including at least one incoming channel and at least one outgoing channel.
  • the call channels include at least one incoming voice channel and the at least one outgoing voice channel.
  • the SIP Load Balancer 1106 distributes new incoming SIP requests across the plurality of nodes 1 108a, ..., 1 108n utilising a round robin method.
  • the Web Gateway 1 116 is coupled to a Web Load Balancer 1 1 18.
  • the Web Load Balancer 1 1 18 distributes incoming communications messages received by the Web Gateway 1 116 among a plurality of nodes 1 120a, ..., 1120n. Each of the nodes
  • 1 120a, ..., 1 120n is equipped with at least one channel for handling Internet Protocol (IP) communication messages.
  • IP Internet Protocol
  • the Web Load Balancer 11 18 distributes new incoming web requests across the plurality of nodes 1120a, ..., 1120n utilising a round robin method.
  • Voice communications between the outside world and the plurality of nodes 1 108a, ..., 1108n and 1120a, ..., 1 120n may be exchanged via a Public Switched
  • PSTN Telephony Network
  • VOIP Voice over Internet Protocol
  • Each of the nodes 1 108a, 1 108n and 1 120a, 1 120n is coupled via an optional internal firewall 1122 to a managing core 1 130.
  • the internal firewall 1 122 regulates communication between each of the nodes 1108a, ..., 1 108n and
  • the managing core 1 130 receives inbound service requests 1126 from the plurality of nodes 1108a, ..., 1108n and 1120a, ..., 1120n and sends outbound instructions 1128 to the plurality of nodes 1 108a, ..., 1 108n and 1120a, ..., 1120n.
  • the inbound service requests and outbound instructions between the nodes 1108, 1 120 and the managing core 1130 utilise the extensible Markup Language (XML). It will be appreciated, however, that other metalanguages and coding formats may equally be used. In the example of FIG.
  • the managing core 1 130 is implemented using a plurality of sub-cores 1 132a, 1 132b.
  • the internal firewall 1 122 is coupled to an optional core load balancer 1 124, which distributes communications received from the nodes 1 108a, ..., 1 108n and 1 120a, ..., 1120n among the plurality of sub-cores 1132a, 1 132b.
  • core load balancer 1124 In implementations that utilise a single managing core 1 130, rather than a plurality of sub-cores 1132a, 1132b, it is not necessary to include the core load balancer 1124.
  • Each sub-core 1 132a, 1132b is coupled to a data store 1170 for storing at least one call architecture 1 175 of a merchant, wherein the call architecture 1175 defines a call handling process for that merchant.
  • the data store 1170 may be integral with the managing core 1 130 or may alternatively be coupled to the managing core 1 130.
  • the data store 1170 may be implemented as a single entity or may be a distributed entity, such as an array of computer disk drives.
  • Each call handling process defined in a call architecture 1 175 of a merchant is operable to detect receipt by a first node in the contact centre system 1100 of an incoming call on a corresponding incoming channel, and to handle the call in a predefined manner.
  • the call handling process couples the call from the first node via one of the call channels thereof to a second of the plurality of nodes in the contact centre system 1100 for connection to an agent associated with the merchant.
  • Node 1 108a is an exemplary node and includes a plurality of communication channels 1109a, a channel driver 11 10a, a node application 1 112a, and a communications gateway 1 1 14a.
  • the functionality of the node architecture is described in further detail below with reference to FIG. 9.
  • Each of the nodes 1 108n and 1 120a, ..., 1 120n includes a corresponding plurality of communication channels, a channel driver, a node application, and a communications gateway, which for the sake of clarity are not illustrated.
  • Each of the nodes 1108a, 1 108n and 1120a, 1 120n and each of the sub-cores 1 132a, 1 132b may be implemented using a computing system 1000 of the type described below with reference to FlGs 1 OA and 10B.
  • the contact centre system 1 100 of FIG. 11 is arranged to establish call connections between customers and agents that represent one or more merchants.
  • the contact centre 1100 is able to receive input requests from a number of different sources and connect those requests to a plurality of agents.
  • the agents may be physically located together in a structured contact centre arrangement or may be disparately located, such as contact centre agents working from home or contact centre agents located across multiple time zones so as to provide 24 hour customer service.
  • the contact centre system 1100 includes call architectures 1 175 that define call handling processes for merchants utilising the contact centre system 1 100.
  • Merchants define call handling processes that establish how incoming requests are to be handled. Incoming requests may generate responsive emails or SMS messages, connection of the incoming request to a recorded voice announcement or interactive voice response system, or connection of the incoming request to a computing device or telephone attended by an agent of the merchant.
  • a call handling process may utilise a plurality of different communication types, including, for example, but not limited to, voice, SMS, email, web chat, recorded announcements, and interactive voice responses.
  • a merchant defines a call architecture 1175 for a dial-out campaign, wherein the call architecture 1 175 includes a list of contacts, the material that is to be sent to each contact, and timing relating to the transmission of outbound messages.
  • the timing may include a start time, a stop time, a call rate, or any combination thereof.
  • a dial-out campaign may be defined to send an outgoing SMS message with the content "Send reply SMS for a chance to win" to each contact in a defined set of 10,000 contacts, wherein the campaign runs from 1 1 :00am on Monday to 5:00pm on Friday with a call rate of 100 SMS messages per hour.
  • the outbound messages may include, for example, SMS messages, emails, video or voice calls.
  • Merchants are able to modify associated call architectures 1175 to provide personalised customer service.
  • the call architecture 1 175 of a merchant can be defined to provide offers or services in response to a keyword received in an incoming SMS message or web request or in response to an incoming telephone request received on a predefined number associated with the merchant.
  • FIG. 16 is a schematic representation of a communication management system 1600, embodied using an instance of the ICC system 1100.
  • the communication system 1600 includes a merchant agent 1 10, Customer A 1620, Customer B 1630, Customer C 1640, and Merchant Manager 1650, each of which is able to communicate with the ICC system 1 100 via a telecommunications network 1660.
  • the telecommunications network 1660 may be implemented using a public switched telephone network (PSTN), a mobile telephony network, a wireless access network, a local access network, the Internet, or any combination thereof.
  • PSTN public switched telephone network
  • the merchant manager 1 50 utilises a personal computer 1652 to access the ICC system 1 100 via the telecommunications network 1660 and configure a call architecture 1175 associated with that merchant.
  • the merchant manager 1650 is thus able to change parameters of the call architecture 1 175 to modify an existing call handling process or configure a new call handling process, such as may arise in conjunction with targeted marketing activities.
  • the merchant agent 1610 utilises a personal computer 1612, a telephone 161 , or a combination thereof, to access the ICC system 1100 via the telecommunications network 1660.
  • the merchant agent 1 10 is employed by the merchant or an operator of the communication management system 1600 to handle enquiries received from customers and potential customers relating to services offered or provided by the merchant.
  • the merchant agent 1610 registers an availability for handling enquiries by logging into the ICC system 1 100 through the use of the personal computer 1612 or the telephone 1614.
  • the merchant agent 1610 remains coupled to the ICC System 1 100 via the telecommunications network 1662 and waits for enquiries to arrive.
  • the merchant agent 1610 registers an availability with the ICC system 1 100 and waits for the ICC system 1 100 to subsequently connect calls to the merchant agent 1610.
  • Customer A 1620 utilises a telephone 1622, such as a conventional telephone handset, a mobile telephone handset, or a smartphone, to access the ICC system 1 100 via the telecommunications network 1660.
  • Customer A 1620 may generate an incoming call to the ICC System in relation to an account, a service enquiry, in response to a promotion, or in response to a received telephone call or message received from a merchant.
  • the ICC System 1 100 identifies a merchant from the incoming call, retrieves a call architecture 1 175 of the identified merchant, and handles the incoming call in accordance with the retrieved call architecture 1175.
  • Customer B 1630 utilises a personal computer (PC) 1 32 to access the ICC system 1100 via the telecommunications network 1660.
  • a node of the ICC System 1 100 pushes web content to the personal computer 1632 via the telecommunications network 1660.
  • Customer B is able to provide information relating to the enquiry, which may include a customer identifier or an account number.
  • Customer B 1630 is able to complete data fields in any pro-forma data sheets that are hosted on the website.
  • Customer B can send emails or data requests from the personal computer 1632.
  • the ICC System 1 1 0 identifies a merchant from the incoming web request or email, retrieves a call architecture 1175 of the identified merchant and handles the incoming call in accordance with the call architecture 1 175.
  • Customer C 1640 utilises an SMS engine 1642 to interact with the ICC system 1 100 via the telecommunications network 1660.
  • the SMS engine 1642 may be implemented using a mobile telephone handset, a computing device, or a smartphone.
  • Customer C sends an SMS message from the SMS engine 1642 to the ICC System 1 100 via the telecommunications network 1660.
  • the ICC System 1 100 identifies a merchant from the incoming SMS message, retrieves a call architecture 1 175 of the identified merchant and handles the incoming call in accordance with the call architecture 1 175.
  • the merchant manager 1650 is running a promotional campaign.
  • the merchant manager 1 50 utilises the personal computer 1652 to access the ICC system 1 100 via the telecommunications network 1660 and configure a call architecture 1175 of the merchant manager 1650.
  • the merchant manager defines a call handling process in the call architecture 1175 whereby calls received on a telephone number associated with the promotional campaign are connected to the merchant agent 1610.
  • the telephone number associated with the promotional campaign is a smart-number in the form of "1800 CAMPAIGN".
  • FIG. 17 is a flow diagram illustrating a method 1700 for establishing a telephone call from Customer A 1620 to the merchant agent 1610.
  • the method 1700 begins at a start step 1705 and proceeds to step 1710, in which Customer A 1620 utilises the telephone 1622 to dial a number associated with the merchant manager 1650.
  • Customer A dials "1800 CAMPAIGN" and the telecommunications network 1660 routes the call from the telephone 1 22 to the ICC System 1 100.
  • step 1720 the ICC system 1 100 receives the inbound call from Customer A 1620 via the PSTN 1 180 and the call is connected to a voice communication channel on a receiving node 1 108, 1 120.
  • the receiving node 1108, 1120 sends an inbound service request via the internal firewall 1 122 to the managing core 1 130.
  • the managing core 1 130 utilises a service system gateway to validate that the number is valid and identifies that the inbound service request relates to merchant manager 1650, based on the dialed number.
  • Control passes from step 1720 to step 1730, in which the managing core 1 130 of the ICC system 1 100 interrogates the data store 1 170 within the ICC system 1 100 to retrieve a call architecture 1175 associated with the merchant manager 1650.
  • Control passes from step 1730 to step 1740, in which the ICC system 1100 handles the call in accordance with the retrieved call architecture 1 175 associated with the identified merchant.
  • the call architecture 1175 of merchant manager 1650 defines that the call is to be routed to merchant agent 1610, who has previously registered an availability for handling enquiries relating to merchant manager 1650.
  • the managing core 1130 sends an outbound instruction to the receiving node 1 108, 1 120 to connect the call to the telephone 1614 of the merchant agent 1610.
  • the receiving node 1 108, 1 120 connects the call to the second node 1 108, 1 120, which receives the incoming call from the receiving node 1 108, 1 120 and sends an inbound service request to the managing core 1 130 seeking instructions for handling the call.
  • the managing core 1130 sends an outbound instruction, based on the retrieved call architecture, to the second node 1108, 1 120 to connect the incoming call via the telecommunications network 1 60 to the telephone 1614 of the merchant agent 1610. Control passes to step 1750 in which Customer A is connected to the Merchant Agent 1610. Control passes from step 1750 to an End step 1760 and the process 1700 terminates.
  • FIG. 18 is a flow diagram illustrating a method 1800 for establishing a chat session between Customer B 1630 and the merchant agent 1610.
  • the method 1800 begins at a Start step 1810 and proceeds to step 1810, in which Customer B 1630 utilises the personal computer 1632 to send an incoming web request via the telecommunications network 1660 to the ICC system 1 100.
  • the ICC system 1 100 receives the incoming web request from Customer B 1 30 via the firewall 1 102.
  • the incoming web request passes to the Web Gateway 1 1 16 and then to the Web Load Balancer 1 1 18.
  • the Web Load Balancer 1118 utilises a round robin algorithm or other algorithm to allocate the incoming web request to a receiving nodes 1108, 1120 that is equipped with a web communication channel.
  • the receiving node 1108, 1120 sends an inbound service request to the managing core 1130.
  • the managing core 1130 utilises the service system gateway to validate that the request is valid and identifies that the inbound service request received from Customer B 1630 relates to the merchant manager 1650, based on an incoming internet protocol (IP) address, a hyperlink, or other metadata associated with the inbound service request from Customer B 1630.
  • IP internet protocol
  • Control passes from step 1820 to step 1830, in which the ICC system 1 100 utilises the managing core 1 130 to retrieve from the data store 1170 a call architecture 1 175 associated with the merchant manager 1650 and determine how to process the inbound service query request.
  • Control passes to step 1840, in which the ICC system 1 100 sends an outbound instruction to the receiving node 1 108, 1120 to establish a connection to the Merchant Agent 1610, in accordance with the retrieved call architecture 1 175.
  • the ICC system 1 100 transmits the request received from Customer B 1630 via the telecommunications network 1660 to the personal computer 1612 of the merchant agent 1610.
  • step 1850 Customer B 1630 is connected to Merchant Agent 1610 and the merchant agent 1610 is then able to establish a chat session with Customer B 1630.
  • the ICC System 1100 may push web content via the telecommunications network 1660 to the personal computer 1632. Control passes from step 1850 to an End step 1860 and the method 1800 terminates.
  • Fig. 19 is a flow diagram illustrating a method 1900 for establishing an SMS conversation between Customer C 1640 and the ICC system 1100. The method 1900 begins at a Start step 1900 and proceeds to step 191 , in which Customer C 1640 utilises the SMS engine 1642 to generate an incoming SMS message to the ICC system 1 100.
  • step 1920 the ICC system 1 100 receives the inbound service SMS message from Customer C 1640 via the firewall 1 103 and the SIP Gateway 1 104 and SIP Load Balancer 1 106.
  • the SIP Load Balancer utilises a round robin algorithm or other algorithm to allocate the inbound SMS message to a receiving node 1 108, 1 120 equipped with an SMS communication channel.
  • the receiving node 1108, 1120 sends an incoming service request to the managing core 1130, which determines that merchant manager 1650 is associated with the inbound SMS text message.
  • Control passes from step 1920 to step 1930, in which the ICC system 1 100 utilises the managing core 1 130 to retrieve from the data store 1 170 a call architecture 1175 associated with the merchant manager 1650.
  • Control passes from step 1930 to step 1940, in which the ICC system 1100 handles the call in accordance with the retrieved call architecture 1175 associated with the identified merchant.
  • the merchant manger 1650 has configured the call architecture 1175 of the merchant manger 1650 to transmit a predefined SMS message in response to any received SMS messages that contain the keyword associated with the promotional campaign. Accordingly, in step 1940 the ICC system 1 100 transmits, via the
  • FIG. 16 refers to the use of personal computers 1612, 1632, and 1652, a person skilled in the art will understand that equivalent functionality may be delivered by other computing devices, without departing from the spirit and scope of the present disclosure.
  • Such computing devices may include, for example, but are not limited to, a data-capable mobile telephone handset, a smartphone, or a personal digital assistant.
  • FIGs 10A and 10B depict a general-purpose computer system 1000, upon which the various arrangements described can be practised.
  • the communication management systems 1100, 1600 and call conversation mapping system utilise the general purpose computer system 1000 to implement one or more of the functional components, including the nodes 1108, 1120, the managing core 1 130, the gateways 1104, 1116, the load balancers 1 106, 1118, 1124, the personal computers 1612, 1632, 1652, the telephones 1614, 1622, and the SMS engine 1642.
  • the computer system 1000 includes: a computer module 1001 ; input devices such as a keyboard 1002, a mouse pointer device 1003, a scanner 1026, a camera 1027, and a microphone 1080; and output devices including a printer 1015, a display device 1014 and loudspeakers 1017.
  • An external Modulator- Demodulator (Modem) transceiver device 1016 may be used by the computer module 1001 for communicating to and from a communications network 1020 via a connection 1021.
  • the communications network corresponds to the telecommunications network 1660 of FIG.
  • the modem 1016 may be a Public Switched Telephone Network (PSTN), a wide-area network (WAN), such as the Internet, a cellular telecommunications network, or a private WAN.
  • PSTN Public Switched Telephone Network
  • WAN wide-area network
  • the modem 1016 may be a traditional "dial-up" modem.
  • the modem 1016 may be a broadband modem.
  • a wireless modem may also be used for wireless connection to the communications network 1020.
  • the computer module 1001 typically includes at least one processor unit 1005, and a memory unit 1006.
  • the memory unit 1006 may have semiconductor random access memory (RAM) and semiconductor read only memory (ROM).
  • the computer module 1001 also includes an number of input/output (I/O) interfaces including: an audio- video interface 1007 that couples to the video display 1014, loudspeakers 1017 and microphone 1080; an I/O interface 1013 that couples to the keyboard 1002, mouse 1003, scanner 1026, camera 1027 and optionally a joystick or other human interface device (not illustrated); and an interface 1008 for the external modem 1016 and
  • the personal computer 1630 is implemented using the computing device 1000 and Customer B is able to utilise the printer 1015 to print a record of a receipt or voucher issued by the ICC System 1100.
  • the loudspeakers 1017 and microphone 1080 may be utilised in conjunction with instructions executing on the processor unit 1005 to effect a telephone handset for VOIP communications.
  • Such a VOIP telephone handset may be utilised to implement the telephones 1614 and 1622 of FIG. 16.
  • the camera 1027 may be utilised to enhance a chat session established between a customer 1630 and a merchant agent 1610 by facilitating the connection of a video call, in conjunction with software instructions executing on the processor 1005.
  • the personal computer 1652 is implemented using the computing device 1000 and software instructions execute on the processor 1005 to provide the merchant manager 1650 with a user interface displayed on the display device 1014.
  • the Merchant Manager 1650 utilises one or more input devices, such as the keyboard 1002 and mouse 1003 to send commands to the ICC System 1100 to configure the call architecture 1 175 associated with the Merchant Manager 1650, including the creation and modification of a call conversation map.
  • the personal computer 1632 is implemented using the computing device 1000 and web content is displayed on the display device 1014. Customer C can utilise any one or more of the keyboard 1002, mouse 1003, microphone 1080, and camera 1027 to establish and maintain a web call utilising the ICC System 1100, which may include a chat session with the Merchant Agent 1610.
  • the personal computer 1652 is implemented using the computing device 1000 and software instructions execute on the processor 1005 to provide the merchant manager 1650 with a user interface displayed on the display device 1014.
  • the Merchant Manager 1650 utilises one or more input devices, such as the keyboard 1002 and mouse 100
  • the modem 1016 may be incorporated within the computer module 1001, for example within the interface 1008.
  • the computer module 1001 also has a local network interface 1011 , which permits coupling of the computer system 1000 via a connection 1023 to a local-area communications network 1022, known as a Local Area Network (LAN).
  • LAN Local Area Network
  • the local communications network 1022 may also couple to the wide network 1020 via a connection 1024, which would typically include a so-called "firewall" device or device of similar functionality.
  • the local network interface 101 1 may comprise an Ethernet circuit card, a Bluetooth wireless arrangement or an IEEE 802.1 1 wireless arrangement; however, numerous other types of interfaces may be practised for the interface 1011.
  • the I/O interfaces 1008 and 1013 may afford either or both of serial and parallel connectivity, the former typically being implemented according to the Universal Serial Bus (USB) standards and having corresponding USB connectors (not illustrated).
  • Storage devices 1009 are provided and typically include a hard disk drive (HDD) 1010. Such storage devices 1009 may be utilised to implement the data store 1170 of FIG. 1 1, which is used to store call architectures 1 175 associated with merchants. Such call architectures 1 175 can include or be coupled to a stored list of contacts and other customer information stored on the same or other storage devices 1009. Other storage devices such as a floppy disk drive and a magnetic tape drive (not illustrated) may also be used.
  • An optical disk drive 1012 is typically provided to act as a non- volatile source of data.
  • Portable memory devices such as optical disks (e.g., CD-ROM, DVD, Blu-ray DiscTM), USB-RAM, portable, external hard drives, and floppy disks, for example, may be used as appropriate sources of data to the system 1000.
  • optical disks e.g., CD-ROM, DVD, Blu-ray DiscTM
  • USB-RAM Universal Serial Bus
  • portable, external hard drives, and floppy disks for example, may be used as appropriate sources of data to the system 1000.
  • the components 1005 to 1013 of the computer module 1001 typically communicate via an interconnected bus 1004 and in a manner that results in a conventional mode of operation of the computer system 1000 known to those in the relevant art.
  • the processor 1005 is coupled to the system bus 1004 using a connection 1018.
  • the memory 1006 and optical disk drive 1012 are coupled to the system bus 1004 by connections 1019. Examples of computers on which the described arrangements can be practised include IBM-PCs and compatibles, Sun Sparcstations, Apple MacTM, or alike computer systems.
  • the communication management system and call conversation mapping system may be implemented using the computer system 1000, wherein the processes of FIGs 1 to 9 and 1 1 to 25, described herein, may be implemented as one or more software application programs 1033 executable within the computer system 1000.
  • the steps of the method of managing data communications are effected by instructions 1031 (see FIG. 10B) in the software 1033 that are carried out within the computer system 1000.
  • the method of managing data communications includes the functionality performed by the managing core 1 130, including the sub-functions of an Inbound Service Manager, an Outbound Job Manager, a Service Security Gateway, a Job Scheduler 140, a Maintenance application 180, a Management Application 150, a Conversation Map application, a contact library, a conversation triggers module, a conversation management application programming interface, and a conversation engine.
  • the method of managing data communications further includes the functionality performed by the nodes, including the channel driver 127, the node application 126, and the ICC Communication Gateway 102.
  • the software instructions 1031 may be formed as one or more code modules, each for performing one or more particular tasks.
  • the software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the communication management methods and a second part and the corresponding code modules manage a user interface between the first part and the user.
  • the software may be stored in a computer readable medium, including the storage devices described below, for example.
  • the software is loaded into the computer system 1000 from the computer readable medium, and then executed by the computer system 1000.
  • a computer readable medium having such software or computer program recorded on the computer readable medium is a computer program product.
  • the use of the computer program product in the computer system 1000 preferably effects an
  • the software 1033 is typically stored in the HDD 1010 or the memory 1006.
  • the software is loaded into the computer system 1000 from a computer readable medium, and executed by the computer system 1000.
  • the software 1033 may be stored on an optically readable disk storage medium (e.g., CD-ROM) 1025 that is read by the optical disk drive 1012.
  • a computer readable medium having such software or computer program recorded on it is a computer program product.
  • the use of the computer program product in the computer system 1000 preferably effects an apparatus for communication management.
  • the application programs 1033 may be supplied to the user encoded on one or more CD-ROMs 1025 and read via the corresponding drive 1012, or alternatively may be read by the user from the networks 1020 or 1022. Still further, the software can also be loaded into the computer system 1000 from other computer readable media.
  • the nodes 1108, 1120 are configured to load application programs from other computer readable media coupled to the managing core 101. In this way, the distributed nodes are maintained with the same software.
  • Computer readable storage rnedia refers to any non-transitory tangible storage medium that provides recorded instructions and/or data to the computer system 1000 for execution and/or processing.
  • Examples of such storage media include floppy disks, magnetic tape, CD-ROM, DVD, Blu-ray Disc, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto- optical disk, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the computer module 1001.
  • Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the computer module 1001 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like.
  • the second part of the application programs 1033 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1014.
  • GUIs graphical user interfaces
  • a user of the computer system 1000 and the application may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUl(s).
  • Other forms of functionally adaptable user interfaces may also be
  • FIG. 10B is a detailed schematic block diagram of the processor 1005 and a "memory" 1034.
  • the memory 1034 represents a logical aggregation of all the memory modules (including the HDD 1009 and semiconductor memory 1006) that can be accessed by the computer module 1001 in FIG. 10A.
  • a power-on self-test (POST) program 1050 executes.
  • the POST program 1050 is typically stored in a
  • the POST program 1050 examines hardware within the computer module 1 01 to ensure proper functioning and typically checks the processor 1005, the memory 1034 (1009, 1006), and a basic input-output systems software (BIOS) module 1051 , also typically stored in the ROM 1049, for correct operation. Once the POST program 1050 has run successfully, the BIOS 1051 activates the hard disk drive 1010 of FIG. 10A. Activation of the hard disk drive 1010 causes a bootstrap loader program 1052 that is resident on the hard disk drive 1010 to execute via the processor 1005.
  • BIOS basic input-output systems software
  • the operating system 1053 is a system level application, executable by the processor 1005, to fulfil various high level functions, including processor management, memory management, device management, storage management, software application interface, and generic user interface.
  • the operating system 1053 manages the memory 1034 (1009, 1006) to ensure that each process or application running on the computer module 1001 has sufficient memory in which to execute without colliding with memory allocated to another process. Furthermore, the different types of memory available in the system 1000 of FIG. 10A must be used properly so that each process can run effectively. Accordingly, the aggregated memory 1034 is not intended to illustrate how particular segments of memory are allocated (unless otherwise stated), but rather to provide a general view of the memory accessible by the computer system 1000 and how such is used.
  • the processor 1005 includes a number of functional modules including a control unit 1039, an arithmetic logic unit (ALU) 1040, and a local or internal memory 1048, sometimes called a cache memory.
  • the cache memory 1048 typically include a number of storage registers 1044 - 1046 in a register section.
  • One or more internal busses 1041 functionally interconnect these functional modules.
  • the processor 1005 typically also has one or more interfaces 1042 for communicating with external devices via the system bus 1004, using a connection 1018.
  • the memory 1034 is coupled to the bus 1004 using a connection 1019.
  • the application program 1033 includes a sequence of instructions 1031 that may include conditional branch and loop instructions.
  • the program 1033 may also include data 1032 which is used in execution of the program 1033.
  • the instructions 1031 and the data 1032 are stored in memory locations 1028, 1029, 1030 and 1035, 1036, 1037, respectively.
  • a particular instruction may be stored in a single memory location as depicted by the instruction shown in the memory location 1030.
  • an instruction may be segmented into a number of parts, each of which is stored in a separate memory location, as depicted by the instruction segments shown in the memory locations 1028 and 1029.
  • the processor 1005 is given a set of instructions which are executed therein.
  • the processor 1 105 waits for a subsequent input, to which the processor 1005 reacts to by executing another set of instructions.
  • Each input may be provided from one or more of a number of sources, including data generated by one or more of the input devices 1002, 1003, data received from an external source across one of the
  • the disclosed communication management arrangements use input variables 1054, which are stored in the memory 1034 in corresponding memory locations 1055, 1056, 1057.
  • the communication management arrangements produce output variables 1061 , which are stored in the memory 1034 in corresponding memory locations 1062, 1063, 1064.
  • Intermediate variables 1058 may be stored in memory locations 1059, 1060, 1066 and 1067.
  • each fetch, decode, and execute cycle comprises:
  • a further fetch, decode, and execute cycle for the next instruction may be executed.
  • a store cycle may be performed by which the control unit 1039 stores or writes a value to a memory location 1032.
  • Each step or sub-process in the processes of FIGs 1 to 9 and 1 1 to 25 is associated with one or more segments of the program 1033 and is performed by the register section 1044, 1 45, 1047, the ALU 1040, and the control unit 1039 in the processor 1005 working together to perform the fetch, decode, and execute cycles for every instruction in the instruction set for the noted segments of the program 1033.
  • the method of communication management and call conversation mapping may alternatively be implemented in dedicated hardware, such as one or more integrated circuits performing the functions or sub functions of call handling, inbound service management, outbound job management, service security gateway, and load balancing.
  • dedicated hardware may include graphic processors, digital signal processors, or one or more microprocessors and associated memories.
  • Embodiments are described by reference to a system referred to as a communication management system or an Intelligent Contact Cloud (ICC) system.
  • the system features a distributed "cloud" of semi-autonomous nodes, each of which is configured to handle incoming and outgoing communications over a range of
  • the communication channels may include, for example, voice channels, SMS channels, chat channels, and so on.
  • FIG. 1 illustrates, from a logical perspective, a communication system 100, for example for implementing multiple contact-centre processes, with an application architecture split into a plurality of major functional components.
  • the physical architecture of the system 100 is discussed separately further below.
  • the components shown in FIG. 1 are independent of each other, yet combine to realise the complete system. This gives a high level of distribution and scalability, as the location of individual hardware and/or software components becomes relatively unimportant. In this manner, the logical location of the components within the application is structured, however the physical location of the components can be diverse.
  • the ICC core 101 is a software application executable within a computing device, such as the computing device 1000 of FIGs 10A and 10B, and defines a set of processes and procedures that provide the logic to power a contact centre process for a merchant.
  • components within the ICC core are built from base class modules with inheritance and standard communications methods providing the backbone for a scalability and flexibility for multiple merchant processes.
  • the ICC Core 101 includes an Inbound Service Manager (ISM) 110, an Outbound Job Manager (OJM) 120, a Service Security Gateway (SSG) 130, a Job
  • ISM Inbound Service Manager
  • OJM Outbound Job Manager
  • SSG Service Security Gateway
  • Scheduler 140 Scheduler 140, a Maintenance Application 180, a Merchant 1 Call Architecture 160, and a Merchant 2 Call Architecture 170, each of which is coupled to a Management
  • the Management Application 150 controls communication among the functional processes of the ICC Core 101.
  • the Inbound Service Manager (ISM) 110 is an application that is responsible for allowing and responding to inbound service requests 1126 received by the ICC
  • Inbound service requests 1126 can be received on many different channels, at any time, and the ISM 1 10 interprets each request and delivers an appropriate response.
  • the ISM 1 10 performs a first check with the Service Security Guard 130 to ensure that the request is for a valid service, and that the source of the request is a valid source for the requested service.
  • the ISM 1 10 proceeds to check the strategy of the requested service and requests any actions to be carried out by the ICC core 101. For example, a requested service may require the playing of a recorded message and the ISM 1 10 retrieves from the data store 1 170 information relating to the event of playing the recorded message.
  • the Outbound Job Manager (OJM) 120 controls all the node requests for jobs to be completed (for example, the sending of a particular message via SMS to a set of recipients) and sends outbound instructions 1128 to the plurality of nodes 1 108, 1 120.
  • a queue of jobs to be performed is distributed across tenants, organisation units, broadcasts ,and services as evenly as possible and in accordance with any predefined priorities.
  • a tenant may correspond, for example, to an organisation or company that has commissioned an operator of the communication management system 1100 to handle customer service contact centre operations, marketing operations, or a combination thereof.
  • the communication management system of the present disclosure is adapted to handle multiple tenants through the logical architecture built into the OJM 120.
  • This logical architecture allows a plurality of tenants (such as different companies) to share the physical components of the distributed architecture, such as communication channels of nodes, based on varying requirements over time. For example, the share of overall resources utilised by a given tenant varies over time based on the requirements of that particular tenant.
  • the logical architecture is configured to balance priorities of outbound service requests to ensure there is minimum lag or delay for real-time services, such as webdial.
  • the ICC Service Security Guard 130 adds a protection layer to the communication management system in the same way a firewall adds protection to a network. Every inbound request received from an external source is validated by the Service Security Guard 130 to ensure that the request is a valid request.
  • the ICC Service Security Guard 130 also optionally maintains a blacklist of invalid request sources to provide an extra level of protection against possible threats. If the ICC Service Security Guard 130 identifies a potential security breach, the ICC Security Guard 130 automatically adds the source of the request to the blacklist. Only system administrators have the level of access to manually change the entries in the blacklist.
  • the ICC Job Scheduler 140 allows scheduled jobs to be activated when required. Scheduled jobs are planned in advance and need to be monitored and activated when the schedule is due.
  • the Merchant 1 Call Architecture 160 defines a call handling process for calls relating to Merchant 1.
  • the call handling process may define, for example, how incoming telephone or web requests are to be routed, when to generate and transmit SMS messages or emails as part of a promotional campaign for Merchant 1 and to whom those messages and emails are to be sent.
  • Merchant 1 is able to access the Merchant 1 Call Architecture 160 to define parameters of the call handling process via a connection 165.
  • the connection 165 couples the ICC Merchant 1 Call Architecture 160 of the ICC Core 101 to a management gateway of a node.
  • the Merchant 2 Call Architecture 170 defines a call handling process for calls relating to Merchant 2.
  • Merchant 2 is able to access the Merchant 2 Call Architecture 160 to define parameters of the call handling process via a connection 175.
  • the connection 175 couples the ICC Merchant 2 Call Architecture 170 of the ICC Core 101 to a management gateway of a node.
  • the Maintenance application 180 is utilised to maintain and monitor the functional processes of the ICC Core 101.
  • An authorised user accesses the Maintenance application 180 via a connection 185, which may be via a user input interface to the ICC Core 101 , via a direct communications link, or via communications link with appropriate security parameters, such as a user identifier and an associated password.
  • the connection 185 couples the Maintenance application 180 of the ICC Core 101 to a management gateway of a node.
  • FIG. 1 is a schematic representation illustrating functional components of the ICC core 101.
  • the ICC Core 101 includes an Inbound Service Manager 110, an Outbound Job Manager 120, a Service Security Gateway 130, a Job Scheduler 140, and a Maintenance Application 180, each of which is coupled to the Management Application 150.
  • the ICC Core 101 further includes at least one call architecture of a merchant.
  • the ICC Core 101 includes a plurality of call architectures, each associated with a merchant and defining a call handling process for that merchant.
  • the ICC Core 101 includes a Merchant 1 Call Architecture 160 through to Merchant "n" Call Architecture 170, each of which is coupled to the Management
  • the call architecture associated with that merchant may include a plurality of call handing processes for voice calls. This may occur, for example, when a merchant utilises a plurality of different telephone numbers to identify incoming calls with different services offered by that merchant.
  • a first telephone number may identify a call as a new customer enquiry and a second telephone number may identify a call as an existing customer with a payment query.
  • Merchant 1 Call Architecture 160 includes a plurality of call handling processes associated with Merchant 1 : Call Processing A 162, Call Processing B 164, and Call Processing C 166.
  • Call Processing A 162 defines a call handling process for inbound voice calls relating to Merchant 1
  • Call Processing B 164 defines a call handling process for inbound web requests relating to Merchant 1
  • Call Processing C 166 defines a call handling process for inbound SMS messages relating to Merchant 1.
  • Call Architecture 170 includes a plurality of call handling processes associated with Merchant "n”: Call Processing A 172, Call Processing B 174, Call Processing C 176, Call Processing D 178, and Call Processing E 179.
  • Call Processing A 172 defines a call handling process for inbound SMS messages relating to a first promotion being run by Merchant "n”
  • Call Processing B 174 defines a call handling process for inbound web requests relating to Merchant "n”
  • Call Processing C 176 defines a call handling process for inbound SMS messages in response to SMS payment reminders relating to Merchant "n”
  • Call Processing D 178 defines a call handling process for inbound inbound voice calls relating to a first telephone number associated with Merchant "n”
  • Call Processing E 179 defines a call handling process for inbound voice calls relating to a toll-free Smart-number relating to Merchant "n”.
  • the ICC Communication Gateway 102 facilitates the media communication for all communications channels (including voice calling and SMS/MMS/email), and is flexible to support future channels as such channels are developed (e.g., social media, such as integration to channels provided via Facebook, Twitter, or the like).
  • the ICC Communication Gateway 102 is embodied within each
  • node 1 108, 1 120 in the communication system 1100.
  • a node application 126 within each node 1108, 1 120 provides logic to manage each of the ICC Communication Gateway 102 and a channel driver 127, and thus control communication between the ICC
  • the ICC Communication Gateway 102 includes a plurality of gateways, corresponding to the defined system architecture. These gateways and corresponding applications within the system are described in brief below and are detailed further in later areas of this document.
  • Conversation Gateway 103 provides connectivity to external gateway services (Voice, SMS, MMS, Email, Chat, Video).
  • a "one channel presence" treats multiple communication modes as a single channel, such that an agent of a merchant can communicate with a customer in a single conversation channel using different communication modes, such as voice, SMS messages, web chat, and emails.
  • Management Gateway 105 - provides a gateway for managers, supervisors and administrators to configure, monitor, and otherwise administer the contact centre system.
  • Live Data Gateway 106 - provides a gateway for providing live data feeds
  • CRM Gateway 107 provides for 3rd party Customer Relationship Management (CRM) communications. This is typically delivered through a set of Application Programming Interfaces (APIs).
  • APIs Application Programming Interfaces
  • Data Vault Gateway 108 provides access to historical data, voice recording files, sound files, images.
  • the conversation gateway 103 provides a connection to the outside world of the ICC system 1100. This includes the services that provide a gateway to external provider services, thereby to allow the present system to have a real world application. Exemplary types of service gateways are detailed below. These services are provided by each of the distributed nodes of the ICC system 1100.
  • An Inbound Calls service provided by the conversation gateway 103 provides for connection directly to multiple telecommunication service providers ('Telcos") via Session Initiation Protocol (SIP) over Ethernet or El .
  • 'Telcos telecommunication service providers
  • SIP Session Initiation Protocol
  • El Ethernet or availability of El termination from the telecommunication service provider.
  • Smart-Number is a telephone number presented as a phone word and is typically utilised in conjunction with a freephone or toll-free telephone service.
  • a Smart-Number typically includes a freephone or toll-free prefix, such as 1800, 13, or 1300, and one or more words relating to a service.
  • a Smart-Number relating to a plumber may be 1800 PLUMBER, which corresponds to the telephone number 1800 7586237 on a standard telephone handset.
  • the inbound call traffic is load balanced across multiple Inbound Call services to allow for a very large number of concurrent inbound calls, if required. This is useful when handling call loads generated in response to promotional materials, competitions, and in conjunction with live or broadcast events.
  • Inbound calls which are provided via SIP are distributed via a load balancing process performed by the ICC Core 101.
  • This load balancing is separate from the incoming load balancing performed by the SIP Load Balancer 1 106 and Web Load Balancer 1 1 18.
  • the ICC Core 101 interprets the SIP control information associated with an incoming service request derived from an inbound SIP call and the ICC Core 101 selects a node to handle the call.
  • the ICC Core 101 sends an outbound communication message back to the SIP gateway 1 104 instructing the SIP gateway 1104 to redirect the call to the selected node. This then allows the selected node to take the call directly and then the selected node communicates directly with the SIP gateway 1104.
  • the Real-Time Transport Protocol (RTP) stream is always between the SIP gateway 1 104 and the selected Node.
  • RTP Real-Time Transport Protocol
  • FIG. 2 illustrates the inbound call load balancing process mentioned above.
  • Inbound calls are provided by a SIP gateway 201 , corresponding to the SIP Gateway 1 104 of FIG. 1 1 , and arrive at a SIP call load balancer 202, corresponding to the SIP Load Balancer 1 106 of FIG. 1 1.
  • the SIP load balancer 202 provides instructions to each of a plurality of nodes 203. Specifically, for each call an instruction is provided by the SIP load balancer 202 to a selected one of the nodes 203. That selected node then communicates directly with the SIP gateway 201 via an RTP stream.
  • the nodes 203 are all in communication with the ICC core 101, which manages the allocation and scheduling of jobs among the nodes 203.
  • the outbound calls service is connected to the telecommunication (Telco) service providers via SIP over Ethernet or El .
  • the SIP and Web gateways 1 104, 1 1 16 are limited only by the hardware used for the traversal of the calls and the available bandwidth or availability of EI termination.
  • the Inbound and outbound calls services are functionally separate within the managing core 101 , 1130 to allow for the confirmed availability of both inbound and outbound channels for the system users.
  • Outbound calls are load balanced by the ICC core 101.
  • Each outbound voice call is directed by the core 101 , 1 130 to a selected node 203 from the plurality of nodes 1 108, 1 120 in the system 1 100, based on predefined criteria.
  • the managing core 1130 selects a node 203 with the least load at the relevant point in time. This direction of outbound calls ensures that the load is spread evenly across the node base.
  • Inbound emails are received from a customer via a third-party service, such as a web server provided by an Internet Service Provider (ISP), wherein the web server couples to one or more of the communication channels 1 109 via the firewall 1 102, Web Gateway 1 1 16, and Web Load Balancer 1118.
  • ISP Internet Service Provider
  • Each of the inbound email services has non-contended Ethernet connectivity to the Internet.
  • Each of the inbound email services may optionally have point-to-point links to mail services of one or more particular client, which assists in implementations in which the volume of email is very large.
  • the inbound email services are limited by the hardware and bandwidth available, and a load balancing protocol may be implemented.
  • Outbound email services much like the inbound email services, use a third party provider, such as a web server provided by an Internet Service Provider and coupled to one or more of the communication channels 1 109 via the firewall 1 102, Web Gateway 1 1 16, and Web Load Balancer 1118.
  • a third party provider such as a web server provided by an Internet Service Provider and coupled to one or more of the communication channels 1 109 via the firewall 1 102, Web Gateway 1 1 16, and Web Load Balancer 1118.
  • Each of the outbound email services has non- contended Ethernet connectivity to the Internet.
  • each of the outbound email services may optionally have point-to-point links to mail services of one or more particular client, which assists in implementations in which the volume of email is very large.
  • the outbound email services are limited by the hardware and bandwidth available.
  • Inbound and outbound email services are functionally separate to allow for capacity confirmation to an end customer for the inbound and outbound email traffic for that end customer.
  • Inbound SMS services are connected to an SMS service provider via an Application Programming Interface (API).
  • API Application Programming Interface
  • the inbound SMS service has non-contended Ethernet connectivity to the Internet and may have direct connectivity to the SMS provider.
  • the inbound SMS service is again limited only to the hardware and available bandwidth.
  • load balancing provided by the SMS provider, the inbound SMS system can optionally be grown across multiple services.
  • the SMS service provider couples to one or more of the communication channels 1109 in a node 1108, 1120 via the mobile network 1 186.
  • FIG. 3A is a schematic block diagram representation illustrating handling of an inbound SMS message.
  • Inbound SMS messages are received by the communication management system 1100.
  • the managing core 1130 analyses information derived from the SMS message, such as the called number, calling number, customer identifier, customer account number, keyword, or a combination thereof, to search a conversation data store 301 stored in the data store 1170.
  • the conversation data store 301 stores a record for each conversation that is presently active. This allows the managing core 1 130 to determine if the inbound SMS is a reply to a current conversation or a new conversation initiated by the sender.
  • the managing core 1130 applies any work flow that is applicable to the current conversation.
  • the work flow is established by a call handling process defined in a call architecture 1 175 of a merchant relating to the SMS message.
  • FIG. 3 shows a user utilising a remote computing device 302, such as a mobile telephone or smartphone, to send an inbound SMS.
  • the inbound SMS is received by a channel bank of the communication management system 1 100, represented by module 304 and implemented by the plurality of communication channels on the nodes 1 108, 1 120.
  • Information derived from the inbound SMS is passed to the conversation data store 301.
  • Module 306 interrogates the conversation data store 301 to identify whether the inbound SMS relates to a current conversation and subsequently apply any relevant work flow.
  • the data store 301 is stored in the datastore 1170 or in another storage medium 1010, 1009.
  • outbound SMS services are connected to the SMS provider via an API.
  • the outbound SMS service also has non-contended Ethernet connectivity to the internet and may have direct connectivity to the SMS provider.
  • the outbound SMS service is also limited only to the hardware and available bandwidth.
  • Inbound and outbound SMS services are functionally separate to allow for capacity confirmation to an end customer for inbound and outbound SMS traffic for that end customer.
  • FIG. 3B is a schematic block diagram representation illustrating initiation of an outbound SMS message.
  • the communication management system 1 100 is configured to implement a dial-out campaign.
  • An SMS channel bank is a set of telephone numbers that can be utilised in a dial-out campaign.
  • a merchant can utilise a subset of the SMS channel bank for different campaigns.
  • each number in the SMS channel bank is associated with an identifier that associates the number with a particular merchant, campaign, contact, or any combination thereof.
  • One arrangement also associates each number in the SMS channel bank with an operating timeframe, which defines a time period during which that number is active for the identifier associated with that number.
  • the communication management system 1 100 knows which numbers from the SMS channel bank are being utilised in the sending of outbound SMS messages, the communication management system 1 100 can match incoming SMS replies to the outgoing SMS messages in an existing conversation record.
  • a phone number "555 1234" is utilised to send an SMS message to Customer C 1640.
  • Phone number "555 1234" is reserved for communications with Customer C 1640 for a predefined operating timeframe, so an identifier associated with that number is marked "Customer C 1640".
  • the system 1100 checks information pertaining to the SMS message to determine whether the system 1 100 has sent an outbound SMS message to that number within the operating timeframe and, if so, matches the incoming SMS message to the outbound SMS message.
  • a. single telephone number from the SMS channel bank is utilised in the sending of an outbound SMS message to a selected list of contacts.
  • customers reply to that single number the system 1100 utilises a combination of the single number and the number of the customer to identify uniquely each conversation.
  • Module 310 selects a phone number from an SMS channel bank and passes the number to the conversation data store 301.
  • the conversation data store 301 creates a record for a new conversation relating to the selected phone number and then passes the selected phone number to module 320, which sends an SMS message from the selected phone number to a remote computing device 330, such as a mobile telephone.
  • a chat service is an online messaging system provided over a communications network, such as the Internet, and may be implemented as a web-based interface to enable a customer accessing a computing device to communicate with a customer service representative, or agent, associated with a particular merchant. Chat services in the present embodiment include multiple chat provider interfaces in place, thereby to allow
  • the chat services have non-contended Internet bandwidth.
  • An end user interface of the ICC system 1100 is propagated from the system 1 100 through the firewall to a remote computing device accessed by a customer, wherein the end user interface is a dialog box or "popup" window on a website of a merchant.
  • the chat engine sends the interpretation of the message to the ICC system's end user interface, while if a message is sent from the end user interface desktop, the message is translated into the required chat engine required format by the chat services.
  • the scalability of the chat services is limited to hardware and available bandwidth and load balancing can be performed by limiting the number of concurrent connections allowed for each API.
  • Video services are configured to operate substantially in the same way that the voice services work, either to be delivered via the SIP Gateway 1 104 using SIP over Ethernet (using an available video codec such as H.263) or be delivered over ISDN, transcoded, and delivered via SIP over Ethernet to the customer.
  • Availability of video over SIP is heavily dependent on the availability of a telecommunications service provider that can handle the traffic. Aside from the telecommunications service provider, the scalability of these services is limited only by the hardware available to perform functionality associated with the video services.
  • Outbound video is provided through the use of SIP over Ethernet to the end user or customer.
  • the outbound video may be transcoded to video over ISDN if the service is the only one available, but ultimately the video traffic will be passed, using SIP, over one or multiple telecommunications service providers with video capabilities.
  • Inbound video and outbound video services are kept separate at all times, so as to allow for the confirmed allocation of available services for clients, i.e., to make sure that a large influx in either types of traffic would not affect the other service.
  • Contact centre gateway 104 of FIG. 1 manages agents of merchants, wherein those agents have logged into the system 100 and are active, and manages the components of the system architecture that facilitate communication between agents and customers. These components of the system architecture include communication channels
  • an agent of a merchant logs into the system 1 100 and establishes a voice connection and a web connection to the system 1 100.
  • the contact centre gateway 104 manages the voice connection and web connection. The key services offered by the contact centre gateway 104 are detailed below.
  • the load balancing of web requests is the process that allows the scalability of the contact centre gateway 104. This is illustrated in FIG. 4.
  • a request 405 for a web session is first received by a load balancer 401 , 1 1 8 via a public facing firewall 1 102, and the load balancer 401 then allocates a node 402 from the plurality of distributed nodes to connect that web session.
  • the plurality of nodes 402 are implemented in this example as an expandable web server cluster that is coupled to an internal firewall 1 122, which in turn is coupled to the ICC Core 101.
  • Each new web session is balanced by the load balancer 401 across all the online nodes that have web session capability. Every request after that session initiation that relates to the same session is then handled by the same allocated node.
  • the login service In order for the login service to be scalable within the application, the login service needs to be an extremely light process. That is, the login process preferably consumes relatively few resources and time.
  • the login process in the present embodiment makes the login service a "one touch" process. This login process acts as a redirection process for when a user attempts a connection to the ICC system.
  • the login process is used by an agent of a merchant to indicate an availability for communication with a customer through the system 1 100.
  • the agent of the merchant accesses a computing device to visit a predetermined Uniform Resource Locator (URL) access portal and enters a user identifier and password associated with that agent, The user identifier and password are then securely posed to the login process, which does not deal with the actual login, but rather sends a request to an Allocation Service to request a physical service, with enough resource, to which the user can connect.
  • the Allocation Service is resident on the managing core 101. Once the request is answered, a login request is sent to the allocated Security/Authentication service for validation.
  • the Security/ Authentication service forms part of the node application 126. Whilst this embodiment relates to the login process followed by an agent of a merchant, a similar login process can be implemented for enabling authorised access to a merchant manager or customer.
  • This service receives a login request and authenticates the login request for access to the remainder of the services. Once authenticated, a certificate is assigned to the user for a limited access time and a request is then sent to the Allocation Service for the relevant Interface Service and Extensions Service (if it is a voice system) to which the user is sent.
  • Interface Service Once the user (agent) has successfully authenticated into the system, that user needs to be able to interface with the system via a web page. These web pages are hosted on web servers.
  • the Interface System Service is provided by the web servers used for the system, wherein the web servers are implemented by the nodes 1 108, 1 120.
  • the ICC system offers a hosted PABX system.
  • IVR Interactive Voice Response
  • An Extensions Service is assigned to the agent when the agent logs in, via a request to the Allocation services.
  • the ICC system delivers PABX functionality to voice calls handled by the system, wherein the PABX functionality includes, but is not limited to, routing of calls to different numbers, and voicemail.
  • Logging When a transaction is performing associated tasks, the transaction needs to log the status and outcomes of those tasks. Each transaction in the system is allocated a Logging service, which the transaction requests from the Allocation service. Once a transaction has an event that needs to be logged, the transaction sends a request to the Logging service, which logs that information as required. The Logging service logs information that will be used for all levels of reporting.
  • the Management Gateway is the interface that enables the management of the ICC system platform. This gateway is preferably delivered via a web based application.
  • FIG. 5 shows the ICC core 501 coupled to a Live Data Gatherer 501.
  • the real-time Live Data Gatherer engine 501 is a process which repeatedly polls the ICC core 101 for information to be available for any of the Live Gateway data feeds 502.
  • the live data feeds are a constant stream of data in XML format that are broadcast to any listening processes.
  • the listening processes can then update visual interfaces, such as live reports 504 and wallboards 503.
  • the distributed communication management system of the present disclosure makes use of a distributed application, and therefore the associated hardware is also distributed.
  • the hardware can be split across multiple physical systems and data centres. For example, a first group of one or more nodes may form part of a first local system, whilst a second group of one or more nodes may form part of a second local system distributed with respect to the first system.
  • the distributed architecture model enables substantially infinite scalability of the communication management system. This is achievable using a single managing "ICC" core, which in some embodiments is a distributed component in itself, and many nodes which each perform work for the overall system.
  • Each node repeatedly submits, as a "heartbeat" to the ICC core 101, 1 130, requests for a task to perform. If the ICC core 101 , 1 130 has no jobs for allocation to a given node, that node remains dormant until the next heartbeat from that node is due.
  • the ICC core 101 , 1 130 manages all the tasks performed by the system 1 100 and distributes tasks based on the capacity, load, and capabilities of respective nodes.
  • FIG. 6 is a schematic representation of a Distributed Architecture model, which includes a plurality of distributed ICC sub cores 601, and a plurality of distributed nodes 602.
  • Each local system may be allocated to a particular merchant, campaign, communication medium, or any combination thereof. Alternatively, one or more of the local systems may operate together.
  • FIG. 7 is a schematic representation illustrating a physical layout of a distributed communication management system 700 in accordance with the present disclosure.
  • the system
  • the load balancers 703 direct requests 702 to nodes in an expandable node cluster 705, which includes one or more nodes as described elsewhere herein. These nodes communicate with a managing ICC core 101 via an internal firewall 707 and primary load balancer 708.
  • the managing core 101 is defined by expandable database (DB) server clusters and expandable file server clusters 706. These clusters 706 have respective disk arrays 709.
  • DB expandable database
  • Data Synchronisation allows multiple cores to be replicated across locations.
  • the use of Data Clusters allows the ICC core itself to scale to any size without the need of any architecture changes.
  • the ICC Data Cluster is managed at the database level and allows the database to be clustered across servers. With a managed cluster the data is split internally with a map of the data managed by the database system.
  • FIG. 8 is a schematic representation illustrating a data clustering arrangement.
  • FIG. 8 shows incoming core database requests being received by the internal firewall 707, 1 122.
  • the internal firewall 707, 1 122 passes the requests to a load balancer 708, 1124 for allocation to a server in an expandable server cluster 706 implementing the core 101, 1 130.
  • the core 101, 1130 is coupled to a data store 709, 1170.
  • the Nodes 1108, 1 120 are individual servers which are commissioned to work for the ICC core 101, 1130.
  • each node 1108, 1120 is implemented using the computing system 1000 of FIGs 10A and 10B.
  • Each node communicates with the ICC core 101 , 1130 and communicates with the outside world via its own media gateway.
  • the plurality of nodes 1 108, 1 120 may be referred to as a "cloud" of distributed nodes for actioning tasks for the core 101, 1130.
  • the node heartbeat process mentioned above allows each node to communicate with the ICC core on a regular basis and provides a constant pulse allowing the ICC core to manage the resources of the node.
  • Each node is repeatedly asking the ICC core if there are any tasks for that node to perform. If there is a task to be performed, the ICC core responds to the requesting node with that task. The node performs that task, and then notifies the ICC core with the outcome of the task.
  • the heartbeat is a variable process and can speed up and slow down, as required.
  • Each node performs its own self maintenance. This is achieved by requesting any latest changes from the ICC core. Such changes may include, for example, software or firmware updates or changes to parameters. Any such change is notified to the node by the ICC core in response to a heartbeat message. If there is an upgrade to be performed, the Node downloads the required files from the core and upgrades the appropriate modules on the node. Self maintenance is extremely important in this scalable model to keep the effort required for maintenance to a minimum. It is also important for each node to be substantially the same as each other node at all times, so that tasks to be performed may be allocated across as much of the distributed architecture as possible.
  • the media driver configuration for each communications channel on a node is maintained by an automated process within each node.
  • the ICC core publishes the latest driver configurations and applications for release and each node checks the latest versions against its local settings. If the node requires an update, the node transfers the update from the ICC core and re-initialise the affected channel(s).
  • Extra media channels are in some embodiments added using the same general process. This allows for additional media drivers to be deployed as those media drivers are developed for new technologies or media interfaces, such as social networking.
  • Certain channels require media to be located locally on the node. Some examples of this are sound files for Interactive Voice Response (IVR) and images for web pages.
  • IVR Interactive Voice Response
  • all nodes are repeatedly checking if any files are required to be copied from the ICC core and stored locally on the nodes. If there are new or updated files, the node downloads the file(s).
  • the channel capacity of each node is configured by the ICC core, based on the build and specifications of the node.
  • the nodes may differ greatly in channel capacity. For example, one node may be configured with a high number of voice channels, but a low number of SMS channels.
  • Each node is configured independently and managed from the ICC core to ensure the most even distribution of channel activity across the entire platform.
  • FIG. 9 shows an exemplary node 900, and is discussed below.
  • the node 900 includes an ICC Communication Gateway 901 , an ICC Node application 902, an ICC Channel Driver 903, and a plurality of communication channels 904.
  • the communication between each node 900 and the ICC core 101 , 1 130 goes through the ICC Communication Gateway 901.
  • the ICC Communication Gateway 901 is responsible for all the communications between the ICC Node application 902 and the ICC core 101, 1 130. In one implementation, all messaging between the ICC Node application 902 and the ICC Communication Gateway 901 uses standard XML. Other metalanguages and programming languages may equally be practised without departing from the spirit and scope of the present application.
  • the Communication gateway 901 converts all messages from the ICC core 101, 1130 to XML to be passed to the ICC Node Application 902.
  • the ICC Node application 902 controls functionality of the ICC Nodes, however the ICC Node application 902 is only a communication tool. There is no business logic within the ICC Node Application 902, as the business logic resides in the ICC core 101, 1 130. All the node functionalities mentioned in the section above entitled "Node Overview" are carried out by the ICC Node Application 902.
  • the ICC Channel driver 903 is the interface layer to the communication channels 904.
  • the channel driver 903 is responsible for communications with a selected channel of the communication channels 904.
  • the channel driver 903 translates the commands from the ICC Node application 902 to the appropriate commands for the selected channel.
  • the communication channels depend on the configuration of the particular node. In the example of FIG. 9, the communication channels include an SMS channel, a voice channel, an email channel, a World Wide Web channel, a video channel, and a SalesForce.com customer relationship management (CRM) channel.
  • the communication channels also include a plurality of other channels available for other communication types provided by third-parties, including, for example, but not limited to, twitterTM, facebookTM, and NetSuiteTM, wherein the channels function as an application programming interface between the node and the third-party.
  • FIG. 12 is a schematic block diagram representation illustrating the use of the contact centre system 1 100 of FIG. 1 1 to establish a call from a customer to an agent of a merchant, wherein the contact centre system 1100 has a data store 1170 that stores a call architecture 1 175 of that merchant.
  • the data store 1170 is presented as a first data store 1 170a integral with the managing core 1 130 and a second data store 1 170b coupled to the managing core 1130.
  • tOhe call architecture 1 175 defines a call handling process for the merchant, wherein the call handling process is operable to detect receipt by a first node of an incoming voice call on a corresponding incoming voice channel of that first node, and to couple the voice call from the first node via one of the call channels of the first node to a second node for connection to an agent associated with the merchant.
  • the contact centre system 1 100 includes five nodes 1108a, ... , 1 108e.
  • the customer accesses a telephone handset 1206 or a computing device 1205, which may be a general purpose computer implemented using the general purpose computing device 1000 of FIGs 10A and 10B, to send a request 1215 to the contact centre system 1100 seeking to establish a connection to the merchant.
  • the request 1215 may, for example, be based on a telephone number or World-Wide- Web hyperlink associated with the merchant.
  • the telephone handset 1206 ma be a
  • the request is from the computing device 1205 for a voice over Internet Protocol (VOIP) call to the merchant.
  • VOIP voice over Internet Protocol
  • the contact centre system 1100 receives the request 1215 at the firewall 1102, which determines that the request 1215 is for a voice call.
  • the firewall 1 102 sends a request 1220 to the SIP Gateway 1104.
  • the SIP Gateway 1 104 forwards the request 1225 to the SIP Load Balancer 1 106 for allocation to a node that is able to handle the call request.
  • the SIP Load Balancer 1 106 forwards the request 1230 to node 1 108c.
  • Node 1108c receives the request 1230 on an incoming voice channel and sends an incoming service request 1235 to the managing core 1130 seeking clarification of how the request is to be handled.
  • the managing core 1 130 receives the incoming service request 1235 and identifies the merchant associated with the request.
  • the managing core 1 130 then retrieves from the data store 1170 the call architecture associated with the identified merchant and determines the required handling process.
  • the call is to be routed to an agent associated with the merchant.
  • the agent has previously logged-in to the contact centre system 1 130 using a computing device 1210, to advise of the availability of that agent.
  • the managing core 1130 maintains a conversation data store 301 for each new incoming and outgoing request.
  • the managing core 1130 sends an outbound instruction in the form of a call handling message 1240 to the node 1108c, which in this example instructs node 1 108c to couple the call to node 1108a, based on the retrieved call architecture 1175 of the merchant.
  • Node 1108c sends a request 1245 to establish a connection with node 1108a.
  • Node 1108a receives the request 1245 and sends an incoming service request 1250 to the managing core 1130 seeking clarification of how the request 1245 is to be handled.
  • the managing core 1 130 receives the incoming service request 1250 and identifies the merchant associated with the request.
  • the managing core 1 130 retrieves the call architecture 1 175 associated with the identified merchant and determines the required handling process.
  • the call is to be routed to an agent associated with the merchant, wherein the agent has previously logged-in to the contact centre system 1 100 to advise of the availability of that agent.
  • the managing core sends an outbound instruction 1255 to the node 1 108a advising node 1 108a to connect the call to the computing device 1210 associated with the agent, based on the call architecture of the merchant.
  • Node 1108a sends a request 1260 to the SIP Load Balancer 1 106, which in turns forwards a request 1265 to the SIP Gateway 1 104.
  • the SIP Gateway 1 104 forwards a request 1270 to the firewall 1102, which in turn forwards a request 1275 to establish a connection to the computing device 1210.
  • the distributed nature of the contact centre system 1 100 allows for the system to be readily scaled through the addition of further nodes, sub-cores, or a combination thereof.
  • a node 1 108, 1 120 receives a request to establish a connection
  • the node 1108, 1120 sends an incoming service request 1235 to the managing core 1 130 to seek instructions for how the connection is to be established.
  • the managing core 1130 utilises information in the incoming service request 1235 from the node 1108, 1 120 to identify a merchant architecture 1 175 stored in a data store 1 170 associated with the managing core 1130, wherein the merchant architecture 1175 defines a call handing process for that merchant.
  • the data store 1170 may be integral with the managing core 1130 or alternatively may be located remotely from the managing core 1 130 and coupled to the managing core 1 130 by a communications link.
  • the data store 1 170 may be a database implemented, for example, using the disk storage medium 1025, storage devices 1009, or a combination thereof.
  • Storing an associated merchant architecture 1 175 for each merchant enables the contact centre system 1 00 to handle a plurality of merchants, with each merchant architecture defining a call handling process for call requests associated with the respective merchant.
  • FIG. 13 is a flow diagram illustrating a call handling process 1300 performed by the node 1 108c in the example described with reference to FIG. 12.
  • the node call handling process 1300 begins at a start step 1305 and proceeds to step 1310, in which the node 1 108c receives an incoming request 1230 from a customer.
  • This incoming request is typically a voice call initiated by the customer wanting to communicate with a merchant.
  • the customer dials a toll-free "1800" number associated with the merchant.
  • the call may be initiated, for example, by a customer seeking clarification of services offered by a merchant or may be in response to a billing query or payment, or may be in response to a communication sent from the merchant or on behalf of the merchant to the customer.
  • the node 1 108c sends an incoming service request 1235 to the managing core 1130, wherein the incoming service request 1235 seeks instructions for handling the request received from the customer.
  • the incoming service request 1235 may include information pertaining to the call, such as the incoming caller number associated with the customer or the dialed number, or a combination thereof.
  • Control passes from step 1315 to step 1320, in which the node 1 108c receives an outbound call handling communication 1240 from the managing core 1 130.
  • the outbound call handling information 1240 may include, for example, routing information and may be based on the caller number associated with the customer or the dialed number.
  • the outbound call handling information may include, for example, routing information and instructions to connect the call to an external agent or one of the other nodes 1 108a, 1 108n in the distributed system 1 100.
  • the node 1 108c receives outbound call handling information 1240 instructing the node 1 108c to connect the call to node 1 108a.
  • Control passes from step 1320 to step 1325 and the node 1 108c connects the call to node 1108a, based on the outbound call handling information 240 received from the managing core 1 130. In this way, the call from the customer is now routed from the computing device 1205 accessed by the customer to the first node 1108c then onto the second node 1 108a. Control passes to an End step 1330 and the process 1300 terminates.
  • node 1 108c In establishing the call from the customer to node 1 108c and then to node 1 108a to be coupled to a merchant agent, the call is not connected to the managing core 1 130. Rather, node 1 108c sends the incoming service request communication 1235 to the managing core 1130 and receives the outbound call handling communication 1240 from the managing core 1 130.
  • the incoming service request communication 1235 and the outbound call handling communication 1240 contain information relating to the call, but there is no voice path to or from the managing core 1 130.
  • the distributed architecture of the contact centre system 1100 is arranged to enable the managing core 1 130 to manage the distributed nodes 1 108, 1 120, wherein the nodes 1108, 1120 handle direct
  • FIG. 14 is a flow diagram illustrating a call handling process 1400 performed by the managing core 1 130 in the example described with reference to FIG. 12.
  • the managing core call handling process 1400 begins at a start step 1405 and proceeds to step 1410, in which the managing core 1130 receives an incoming service request
  • the incoming service request communication 1235 may be related to an incoming call received by the node 1 108c from a customer 1205.
  • the incoming service request communication 1235 may include, for example, information pertaining to the call received by the node 1 108c such as, for example, the caller number associated with the customer, a customer reference number, a customer account number, a called number associated with a merchant, Internet Protocol (IP) address, or any combination thereof.
  • Control passes from step 1410 to step 1415, in which the managing core 1 130 identifies a merchant, based on the received incoming service request communication 1235.
  • Control passes from step 1415 to step 1420, in which the managing core 1130 retrieves from the data store 1170 a call architecture 1 175 of the identified merchant.
  • the call architecture 1 175 of the identified merchant defines a call handling process for calls relating to identified merchant.
  • Control passes from step 1420 to step 1425, in which the managing core 1 130 sends outbound call handling information 1240 to the node 1 108c.
  • the outbound call handling information 1240 instructs the node 1 108c how to proceed with handling of the call.
  • the outbound call handling information 1240 instructs the node 1 108c to connect the call to an outgoing channel of that same node 1108c to establish a connection to an agent associated with the identified merchant.
  • the outbound call handling information 1240 instructs the node 1108c to connect the incoming call from the customer to a recorded voice announcement (RVA) or interactive voice recording (IVR) system.
  • RVA recorded voice announcement
  • IVR interactive voice recording
  • the call handling information 1240 instructs the node 1 108c to connect the incoming call from the customer to a second node in the system. That second node subsequently contacts the managing core 1130 to seek further instructions for handling the call. Control passes from step 1425 and returns to step 1410, where the managing core 1 130 awaits a further communication from another node.
  • One aspect of the present disclosure provides a conversation mapping method and system.
  • the conversation mapping method and system are embodied utilising the communication management system 1100 of FIG. 1 1 , wherein a conversation map application and conversation engine form part of the management application 150 of the managing core 101.
  • the conversation mapping method and system enable a merchant to create a call conversation map that establishes a call workflow in a multi-channel environment.
  • the call conversation map is modifiable by the merchant and is able to handle communications on multiple media, including voice, data, SMS messages, email, and calendar entries.
  • the mapping method may be implemented as an application for execution as a portion of the management application 150 in the managing core 101, 1130 of the communication system 100, 1 100.
  • a call conversation map utilises a plurality of linked objects to define a logical call workflow for a given scenario. Each object corresponds to a state in the conversation map representing an event in a call handling process. Objects that involve the generation of an outbound message 1 128 or receipt of an inbound request 1 126 are termed "tasks".
  • One implementation of the conversation mapping system utilises a graphical user interface to provide a visual tool for designing a call conversation map.
  • a call conversation map can be linear or alternatively can include one or more branches.
  • the call conversation map can be activated by a trigger, which may be a timing event, an outbound broadcast from the communication management system 1 100, or an inbound service to the communication management system 1100. Once triggered, a conversation map becomes active and a conversation engine handles incoming communications and generates outbound communications in accordance with the call workflow defined by the active conversation map.
  • the call conversation map is stored in the data store 1170 of FIG. 11 as part of a call architecture 1 175 of an associated merchant.
  • the call architecture 1175 includes one or more call handling processes for communications associated with the merchant.
  • a Merchant 1 Call Architecture 1160 includes three call handling processes associated with Merchant 1 : Call Processing A 162, Call Processing B 164, and Call Processing C 166.
  • the merchant establishes a call conversation map to define the workflow for each call handling process 162, 1 4, 1 6. Whilst the example of FIG. 15 demarcated call handling processes based on the communication medium, the call conversation map is able to handle multiple call conversation map to define the workflow for each call handling process 162, 1 4, 1 6. Whilst the example of FIG. 15 demarcated call handling processes based on the communication medium, the call conversation map is able to handle multiple
  • call handling processes may still be appropriate for a merchant under some circumstances, such as separate call handling processes for different marketing campaigns.
  • the conversation mapping method and system provide a merchant with a flexible mechanism for defining and controlling call handling processes.
  • a merchant can define a separate conversation map for each call scenario, including, but not limited to, calls relating to marketing campaigns, different types of customers, different services, or different accounts.
  • Each conversation map is optionally associated with one or more triggers that activate the conversation map.
  • the merchant can modify each conversation map to update or change the call handling process, contact details associated with the merchant, a list of contacts to whom materials are to be sent, or triggers associated with the conversation map.
  • a trigger defines a time at which a conversation map becomes active.
  • a trigger defines that a conversation map becomes active upon receipt of an incoming message 1 126 from a particular source.
  • a merchant defines a call conversation map to handle the payment of overdue accounts, wherein an initial task in the conversation map relates to the sending of a group SMS message to all customers with overdue accounts.
  • the group SMS message includes predefined content provided by the merchant.
  • the merchant defines a trigger to activate that conversation map on the first day of the month at 9am, so that every month the communication management system 1100 running an instance of the conversation mapping method generates outgoing SMS messages with predefined content.
  • FIG. 21 is a schematic block diagram representation illustrating a logical architecture of a call mapping system 2100.
  • the call mapping system 2100 includes a conversation map module 2130 coupled to each of a conversation engine 2120, a conversation triggers module 2140, a contact library 2150, and a conversation management application programming interface (API) 2160.
  • the conversation engine 2120 also couples to a media gateway 2110.
  • the conversation management API 2160 couples to each of an external API gateway 2170 and a conversation management interface 2180 to exchange communications with merchants, administrators, and other authorised persons.
  • the conversation management interface 2180 provides a web-based interface for a merchant, administrator, or other authorised person to access the conversation mapping system 1100 to create or modify a call conversation map.
  • the external API gateway 2170 provides an alternative interface for the merchant, administrator, or other authorised person to access the conversation mapping system 1 100, whereby the external API gateway 2170 receives instructions for creating or modifying a call conversation map in accordance with a third party programming interface.
  • a merchant may utilise a third party application to provide via the external API gateway 2170 a batch set of instructions to configure a contacts list, a conversation map, triggers associated with one or more conversation maps, or other parameters of the conversation mapping system 1 100.
  • the conversation management API 2160 couples to each of the contact library 2150, the conversation map module 2130, and the conversation triggers module 2140. Instructions received from the external API gateway 2170 and the conversation management interface 2180 are passed to the conversation management API 2160 and then to one or more of the contact library 2150, the conversation map module 2130, and the conversation triggers module 2140.
  • the instructions may relate, for example, but are not restricted to, adding, deleting, or modifying contacts in the contact library 2150, creating, deleting, or modifying a conversation map via the conversation map module 2130, or creating, deleting, or modifying a trigger associated with a conversation map via the conversation triggers module 2140.
  • the media gateway 21 10 represents a logical module for managing communications between the conversation mapping system 2100 and the outside world.
  • the media gateway is implemented by one or more nodes 1108, 1120 in the communication management system 1100.
  • the conversation engine 2120 is a software application containing instructions for execution on a processor 1005 to effect a process that utilises information from a conversation map to manage communications with an end customer.
  • the conversation engine 2120 continually monitors and acts on events, based on the objects and links defined in the conversation map.
  • the conversation engine 2120 retrieves information from a conversation map 2130 that has been activated and interprets current events, such as the receipt of an inbound request 1126 or transmission of an outbound communication 1 128, to determine when to activate an outbound communication, how to respond to any inbound communications, and also when to proceed to a next object in the conversation map.
  • the conversation engine 2120 is able to manage multiple active conversation maps.
  • the contact library 2150 is a data store of information for contacts that have been added to the call mapping system 2100.
  • the call mapping system 1 100 utilises the information stored in the contact library 2150 to communicate with the contacts stored therein.
  • contacts may be classified into different types, such as customer, potential customer, service provider, and merchant manager, wherein different information is stored for each type of contact.
  • each contact is stored as a record with one or more fields.
  • the customer contact record includes fields for recording each of a name, address, telephone number, email address, and customer number.
  • the merchant manager contact record includes fields for recording each of a name, company number, mailing address, billing address, telephone number, email address, and merchant number. It will be appreciated by a person skilled in the art that the actual type of information recorded for each contact will depend on the particular implementation and changes to the number and types of fields may be practised without departing from the spirit and scope of the present disclosure.
  • FIG. 23 is a flow diagram illustrating a conversation mapping method 2300.
  • the conversation mapping method 2300 utilises a conversation map application 2130 implemented as software instructions forming part of a management application 150 of a managing core 101, wherein the software instructions execute on a processing unit 1005 of a computing system 1000 implementing the communication management system 100.
  • the conversation mapping method 2300 begins at a Start step 2305 and proceeds to step 2310, in which a merchant manager 1650 utilises a computing device 1652 to provide instructions via one of the external API gateway 2170 and the conversation management interface 2180 to the conversation map application 2130.
  • the merchant manager 1650 utilises the conversation map application 2130 to create a call conversation map by allocating a plurality of objects and connecting links.
  • the call conversation map defines a call handling process for a particular call scenario for that merchant.
  • the call conversation map may relate, for example, to account enquiries and payments, promotional offers, or marketing campaigns.
  • Control passes from step 2310 to step 2320, which stores the call conversation map in a data store 1 170 of the
  • Step 2330 activates a stored call conversation map, based upon a predefined trigger from the conversation triggers module 2140.
  • One or more triggers may be associated with a call conversation map.
  • a trigger is based on a calendar entry or time of day, wherein activation of a call conversation map is scheduled.
  • a trigger is based on receiving an incoming call conversation map.
  • the at least one predefined criterion may relate, for example, to an inbound calling number, a dialed number, a source identifier, a range of times or dates, or any combination thereof.
  • the source identifier may be, for example, a calling number or an Internet Protocol (IP) address.
  • IP Internet Protocol
  • Control passes from step 2330 to step 2340, in which a conversation engine 2120 monitors and handles incoming and outgoing communications in accordance with the activated call conversation map.
  • the conversation engine 2120 utilises a Task Memory stored in the data store 1 170 to record information relating to each object This allows the conversation mapping system to utilise information from previously executed objects within the same conversation map or from other conversation maps.
  • Control passes to decision step 2350, which determines whether the call conversation map has been completed. If the call conversation map has reached an end of a branch, Yes, control passes to an End step 2360 and the method 2300 terminates. The call conversation map is then marked as inactive. If at step 2350 the map has not reached an end of a branch and further actions are expected in the call conversation map, No, control returns from step 2350 to step 2340 to monitor and handle further incoming and outgoing communications.
  • One implementation of the call conversation mapping method and system utilises Extensible Markup Language (XML) to define a call conversation map.
  • Objects and links within the call conversation map are defined separately and the call handling workflow is defined as an XML file.
  • One embodiment optionally provides a second file to define display properties associated with the call conversation map.
  • the second file includes parameters relating to the layout properties of the objects and links.
  • FIG. 20 is a screenshot of a call conversation map 2000 created using a graphical user interface.
  • the graphical user interface may be implemented using text and graphics presented to a computing device 1652 accessed by a merchant manager 1650.
  • the computing device may be implemented using a computing device 1000, whereby the graphical user interface is displayed on a video display unit 1014 and the merchant manager provides input via one or more of the keyboard 1002, microphone .1080, and mouse pointing device 1003.
  • the conversation map 2000 is stored in call architecture 1 175 of a merchant and establishes a call handling process for that merchant.
  • the merchant creates or modifies a conversation map by utilising the mouse 1003 or keyboard 1002 to position one or more objects on a window displayed in the video display 1014 and connect those objects in a desired workflow by connecting the objects with links.
  • the links are utilised by the conversation engine 2120 to determine a next step in a conversation map from a current object. Each link can utilise one or more of an outcome, time schedule, or task expiry to determine a workflow within the call
  • the merchant manager 1650 provides information relating to each object, wherein objects relating to the handling of incoming or outgoing communications are denoted as tasks and each conversation map includes at least one task.
  • different objects are displayed in different colours to provide a visual distinction in the conversation map. For example, all tasks are displayed in green to indicate a communication action to be performed and objects relating to payment are displayed in orange to indicate an accounting transaction.
  • One embodiment provides a task master template for grouping together objects that relate to a particular phase of a call handling process. Such a task master template can be stored either locally on the computing device 1652 of the merchant manager 1650 or on the data store 1 170 of the communication management system 1 100 for retrieval at a later time. Task master templates facilitate the later creation or modification of the same or other conversation maps in which the same or similar functionality is required.
  • the conversation map 2000 relates to collection of payments for customer accounts that are overdue by less than 15 days.
  • the call handling process 2000 begins at an initial object 2005, which is a task for sending an outbound group SMS message from the communication management system 1 100 to a list of selected customers having overdue accounts, wherein those selected customers have mobile telephone contact numbers suitable for receiving SMS messages and the contact details are stored in the contact library 2050.
  • the SMS message has the content "Payment Reminder. Arrears less than 15 days. Reply PAY to pay now. Reply SERVICE to speak to customer service ".
  • the communication management system 1100 When the conversation map 2000 is triggered, the communication management system 1100 generates an outbound SMS message to each of the selected customers 1640 via one or more of the nodes 1108, 1120.
  • the conversation map 2000 defines two possible responses to the sending of the group SMS message: (i) the customer 1640 receiving the outbound SMS message sends an incoming SMS message with "PAY” in the content; or (ii) the customer 1640 receiving the outbound SMS message sends an incoming SMS message with "SERVICE" in the content.
  • the workflow of the call conversation map 2000 passes from object 2005 to object 2010, which is a task for establishing a call from an agent 1610 of the merchant to the customer 1640.
  • the call may be implemented using an exchange of further SMS messages, a web chat session, a video call, or a voice call, depending on the
  • Object 2010 links to a further object 2015, which is a task indicating that the call has been answered by the customer 1640, thus confirming the establishment of a call between the agent 1610 and the customer 1640.
  • the customer 1640 is then able to query the account with the agent 1610, discuss payment options, or provide payment details.
  • the workflow of the call conversation map 2000 passes from object 2005 to object 2010, which is a task for establishing a call from a node 1 108, 1 120 of the communication management system 1 100 to the customer 1640.
  • the call is generated by a node 1108, 1120 equipped with IVR capabilities.
  • Object 2010 links to a further object 2025, which indicates that when the call has been, answered by the customer 1640, the node 1108, 1 120 is to connect the IVR to play a recorded message introducing the customer 1 40 to the payment system.
  • the IVR may utilise dual tone multi-frequency (DTMF) tones to interact with the keypad of a telephone being utilised by the customer 1640. This enables the customer 1640 to navigate a menu hosted by the IVR.
  • Object 2025 links to a further object 2030 that records payment details provided by the customer 1 40. In this example, object 2030 records digits of a credit card.
  • Object 2030 links to another object 2045 that records digits of an expiry date of the credit card recorded in object 2030.
  • Object 2045 links to object 2050, which validates the credit card.
  • object 2050 is linked to a payment facility, such as that provided by PayPalTM.
  • a payment facility such as that provided by PayPalTM.
  • Object 2040 connects the call to an agent 1610.
  • a link connects object 2050 to object 2055, which engages the IVR to play a recorded message thanking the customer 1640 for the payment and reciting a receipt number for the payment.
  • Object 2055 links to object 2060, which is a task for sending a single SMS message to customer 1640, wherein the SMS message again thanks the customer 1640 for the payment received in object 2050 and provides the receipt number for that payment.
  • task master template A 2070 includes object 2005 relating to the task of generating an outbound SMS message.
  • Task master template B 2072 includes objects 2010 and 2015 relating to that part of the conversation map 2000 that arises if the customer 1640 replies to the group SMS message with an SMS message containing the word "SERVICE”.
  • Task master template C 2074 includes objects 2020, 2025, 2030, and 2045 relating to the acquisition of credit card details to effect payment.
  • Task master template D 2076 includes objects 2035 and 2040 relating to a failed attempt to pay the account.
  • the task master templates are optional and it is not essential for all objects to belong to a task master template. In the example of FIG. 20, objects 2050, 2055, and 2060 do not belong to a task master template.
  • FIG. 22 is a schematic block diagram representation illustrating an example of the contact library 2150.
  • the contact library 2150 includes one or more contact lists. Each contact list may correspond, for example, to customers, suppliers, geographical locations, services, merchant managers, marketing campaigns, or any combination thereof.
  • the contact library includes a plurality of contact lists: Contact List A 2052, ..., Contact List "n" 2058.
  • Contact List A 2052 stores customer contacts for Merchant Manager 1650 and Contact List "n" 2058 stores agent contacts for Merchant Manager 1 50.
  • Contact List A 2052 includes Contact Fields 2053, which defines the types of fields in each record for the contacts in Contact List A 2052.
  • Contact Fields 2053 defines fields for storing name, address, telephone number, email address, and account number.
  • Contact List A 2052 also includes Contacts 2054, which is a list of the customer contacts for Merchant Manager 1650. Contacts can be added individually or through a bulk importation process. A bulk importation of contacts may be performed, for example, by the merchant manager 1650 utilising the external gateway 2170 to upload an existing database of contacts or by the merchant manager 1650 utilising the conversation management interface 2180 to access a web interface to enter a new contact.
  • the Contacts 2054 form at least one contact pool, based on at least one matching criterion. In the simple case, all of the contacts in Contacts 2054 form a contact pool.
  • Merchant manager 1650 can apply a contact pool filter to the Contacts 2054 to form one or more further contact pools, based on the parameters of the contact pool filter.
  • a contact pool filter can include one or more rules. Multiple contact pool filters can be applied to generate multiple contact pools. Contact pools are used to group contacts that match the contact pool filter. This is useful for organizing a marketing campaign using a filtered contact pool. Different contact pools can overlap.
  • Contacts 2054 includes Contact Pool A 2055, Contact Pool B 2056, and Contact Pool C 2057.
  • Contacts 2054 Some of the contacts in Contacts 2054 are common to each of Contact Pool A 2055, Contact Pool B 2056, and Contact Pool C 2057. There are also contacts in Contact Pool A 2055 that are common to Contact Pool C 2057, but not to Contact Pool B 2056. Similarly, there are contacts in Contact Pool A 2055 that are common to Contact Pool B 2056, but not to Contact Pool C 2057. Further, there are contacts in Contact Pool B 2056 that are common to Contact Pool C 2057, but not to Contact Pool C 2055.
  • Contact List “n” 2058 includes Contact Fields 2059, which defines the types of fields in each record for the contacts in Contact List “n” 2058.
  • Contact Fields 2059 defines fields for storing name, address, telephone number, email address, and agent number for each agent associated with merchant manager 1650.
  • Contact List “n” 2058 also includes Contacts 2060, which is a list of the agent contacts for Merchant Manager 1650.
  • the Contacts 2060 includes Contact Pool D 2061, Contact Pool E 2062, and Contact Pool F 2063, wherein there is some overlap between the contacts in Contact Pool D 2061 and Contact Pool E 2062.
  • the conversation engine 2120 migrates tasks within the conversation map from the conversation map into an Active Task Template.
  • the Active Task Template includes task templates, which are the actual tasks to be actioned by the conversation engine 2120.
  • the task templates are the individual steps that require an outbound communication to be triggered.
  • a task template includes information relating to an incoming or outgoing communication channel that is to be used, the content that is to be sent or received, and the source or destination of the task.
  • a Task Scheduler is responsible for monitoring all the task templates. When a task template is triggered to be actioned, that task template is migrated to a Task Online area to be actioned.
  • the Task Online area is a staging area where the actual communication is performed.
  • a task When a task is online, that task is marked as being currently active and is referred to as an online task.
  • An online task has five phases: scheduled, allocated, started, waiting, and completed.
  • An online task that is "scheduled” is active and waiting to be allocated.
  • An online task is "allocated” when the task is waiting to be allocated to a resource, such as a node 1 108, 1120.
  • a node 1 108, 1120 When an online task is allocated to a node 1 108, 1 120 in response to a heartbeat message from the node 1 108, 1 120, the online task changes to a "started" phase.
  • a "started" phase indicates that an initial outbound instruction 1 128 has been sent from the managing core 1 130 to a node 1108, 1 120 and the managing core 1130 is waiting for a response from the node 1 108, 1120.
  • the managing core 1130 receives a response from the node 1 108, 1 130, the online task enters a "waiting" phase, in which the conversation engine 2120 executing on the managing core 1130 waits for notification from the node 1108, 1 120 that the task has been completed.
  • the online task is marked as "completed” and the task is moved from the Online Task area and is stored in an archived history.
  • Such a history may be recorded, for example, on the data store 1 170 of the managing core 1 130, and form part of a conversation record for that instance of the call conversation map 2000.
  • the conversation records can be used for later analysis of the call handling process and for managing subsequent objects within the call conversation map 2000.
  • An initial phase of an online task is to create an outbound communication from the conversation mapping system 2100 to a designated contact.
  • the designated contact may be a customer, a merchant manager, or other contact. This step uses Router Control to allocate a specific outbound communications router.
  • Router Control is a function of the Node Application 125, 1 112 within a node 1 108, 1 120 of the system 1 100.
  • the Router Control selects a service provider for a required service.
  • an outbound communication is a voice call and an allocated node has three outgoing voice channels, each channel corresponding to a different service provider.
  • Router control selects one of the outgoing voice channels on which to send the outbound communication.
  • Router Control may be implemented as a manual process in which an administrator allocates outbound communications among the plurality of communication channels.
  • Router Control is an automated process that allocates outbound communications to channels.
  • One embodiment assigns a priority to each router and utilises the priorities when allocating communications.
  • the task will be available to be allocated in response to a heartbeat request from one of the distributed nodes 1 108, 1 120.
  • a node 1 108, 1120 will then actually perform the communication by generating the required outbound communication, such as a phone call, SMS message, email, etc.
  • the communication is sent out via the media gateways.
  • FIG. 25 is a schematic block diagram representation illustrating activation of tasks from the conversation map of FIG. 20.
  • Fig. 25 shows the conversation map 2000 of FIG. 20, which includes a first task 2060 relating to the sending of a Group SMS message.
  • the task 2060 includes a set of task properties that define the actions to be performed in relation to task 2060.
  • the task 2060 includes task properties indicating that the Group SMS message is to be sent to all of the contacts in Contact List A 2052 at a rate of 500 calls per minute.
  • the conversation map 2000 is associated with one or more triggers in a triggers module 2140, wherein the triggers define when the conversation map 2000 becomes active.
  • the conversation engine 2120 migrates the tasks of the conversation map 2000 to corresponding task templates in an Active Task Template 2520.
  • task 2060 migrates to
  • Task Template A 2522 Other tasks in the conversation map 2000 migrate to Task Template B 2524, ..., Task Template n 2526.
  • Task Template A 2522 includes the set of task properties associated with task 2060.
  • a Task Scheduler 2530 forms part of the conversation engine 2120 and manages the task templates in the Active Task Template 2520. In particular, the Task Scheduler monitors events associated with the call conversation map and determines when to activate a next task template in the Active Task Template 2520.
  • the Task Scheduler 2530 migrates the task template to a task in a Task Online area 2540.
  • the Task Scheduler 2530 populates the task with all of the information required to perform that task.
  • the Task Scheduler may retrieve information from the contacts library 2150 to populate a destination for an outbound communication from the system 1100.
  • the Task Scheduler 2530 migrates Task Template A 2522 to the Task Online area 2540 as an online task 2542 and the online task 2542 is in the
  • the online task 2542 includes all of the information to perform the task.
  • the online 2542 includes information indicating that the task to be performed is the sending of an SMS message to Customer C 1640 with content "Payment overdue. Reply 'PAY' to pay account or 'SERVICE' to speak with an agent".
  • the Active Task Template 2520, Task Scheduler 2530 and Task Online Area 2540 combine to perform the logical functionality of the Outbound Job Manager 120.
  • the nodes 1108, 1120 send heartbeat messages to the managing core 1 130 asking for online tasks that are to be performed.
  • the managing core 1 130 allocates the online tasks from the Task Online area 2540 to the nodes 1 108, 1 120 in response to the heartbeat messages.
  • the task 2542 then enters the "allocated" phase.
  • the online task 2542 becomes “started” and then progresses to "waiting" until a timer expires or part of the online task 2542 completes. Once the timer expires or all aspects of the online task 2542 have been performed, the online task 2542 becomes "completed”. Completed online tasks are removed from the Task Online area 2540.
  • FIG. 24 is a flow diagram illustrating a conversation mapping method 2400 utilising the example of FIG. 20 and the communication management system 1600 of FIG. 16, which is embodied using an instance of the system 1100 of FIG. 1 1.
  • a merchant manager 1650 first logs into the system 1 100 through a login process running on the node application 126 of a node 1 108, 1 120.
  • the conversation mapping method 2400 begins at a Start step 2405 and proceeds to step 2410 in which the merchant manager 1650 utilises a computing device 1652 to communicate with the communication management system 1 100.
  • the merchant manager 1650 utilises a keyboard 1002, mouse pointer device 1003, or other input device to provide input to the computing device 1652, implemented using a computing system 1000 as described with reference to FIGs 10A and 10B.
  • the computing device 1652 exchanges communications with the communication system 1100 via the telecommunications network 1660.
  • the communication system 1 100 includes a conversation map application 2130 and conversation engine 2120 as part of a management application 150 in the managing core 1 130.
  • the managing core 1130 is implemented using a computing system 1000 as described with reference to FIGs 1 OA and 10B and the conversation map application 2130 and conversation engine 2120 include a set of software instructions executing on a processing unit 1005.
  • the merchant manager 1652 utilises the conversation map application 2130 to create a call conversation map in step 2410 corresponding to the call conversation map 2000 of FIG. 20, which relates to a call handling process for
  • the call conversation map 2000 is stored in the data store 1170.
  • the method 2400 proceeds from step 2410 to step 2415, in which the merchant manager 1650 defines a trigger associated with the conversation call map 2000.
  • the trigger is 9am on the first Monday of each month.
  • Step 2415 also stores the trigger in the data store 1 170 as part of the conversation triggers module 2140.
  • Control passes from step 2415 to step 2420, in which the conversation engine 2120 activates the call conversation map 2000, based on the trigger.
  • the conversation engine 2120 activates the call conversation map 2000.
  • the conversation engine 2120 migrates tasks from the call conversation map 2000 to an Active Task Template 2520, which includes a set of task templates 2522, ..., 2526.
  • the task templates 2522, ..., 2526 are the tasks that are to be actioned in respect of the call conversation map 2000.
  • a Task Scheduler 2530 within the conversation engine 2120 manages the task templates 2522, ..., 2526.
  • Control passes from step 2425 to step 2430, in which the Task Scheduler 2530 migrates the task templates to online tasks in a Task Online area 2540 and allocates each task template to an outbound communications router, being an outgoing communication channel on a node 1108, 1 120.
  • the Task Scheduler 2530 retrieves from the contact library 2050 a set of contacts to whom the group SMS message is to be sent.
  • the set of contacts having overdue accounts may be stored in the contact library 2050 as a separate contact list 2052, 2058.
  • the Task Scheduler 2530 applies a contact pool filter to Contacts 2054 to retrieve the set of contacts having overdue accounts, wherein the pool filter includes parameters that identify customers of merchant manager 1650 that have accounts that are overdue by less than 15 days.
  • the task templates are now arranged as online tasks in a pipeline and are ready to be allocated to nodes 1 108, 1 120 in response to heartbeat communications from the nodes 1 108, 1120 that seek jobs to perform.
  • Control passes from step 2430 to step 2435, which receives a heartbeat request from a node 1108, 1120.
  • the initial object in the call conversation map 2000 is the task of sending a group SMS message to each customer having an overdue account.
  • step 2440 the conversation engine 2120 assigns the initial task 2005 in the call conversation map 2000 to one or more of the nodes 1 108, 1 120 by sending outbound instructions 1 128 from the managing core 1 130 to one or more of the plurality of nodes
  • the group SMS messages may be implemented by utilising a bank of telephone numbers. As the conversation engine 2120 knows which outgoing SMS messages relate to which of the telephone numbers in the bank of numbers, the
  • conversation map application matches incoming and outgoing communications to one or more active call conversation maps by utilising the telephone numbers that appear in calling numbers, called numbers, or signaling information.
  • the next steps in the call conversation map 2000 branch from object 2005, depending on whether a customer replies to the group SMS message with an SMS message containing the content "PAY" or "SERVICE".
  • the conversation engine 2120 monitors incoming communications received after the Group SMS message has been sent and determines whether the incoming communications relate to an existing conversation. Control passes from step 2440 to step 2442, in which a customer 1640 receives the group SMS message and utilises an SMS engine 1642, which in this example is implemented as a mobile telephone handset, to send a reply SMS message.
  • the reply SMS message is received by the system 1 100 as an incoming message and is allocated to one of the nodes 1 108, 1120.
  • the node 1 108, 1120 sends an incoming request 1 126 to the managing core 1 130 seeking instructions for handling the incoming SMS message.
  • Control passes to step 2445, in which the conversation engine 2120 monitors incoming communications relating to this call conversation map and identifies the incoming request 1 126 as relating to the call conversation map 2000.
  • Control passes to decision step 2450, which determines whether the incoming message includes the content "PAY" or "SERVICE".
  • the conversation engine 2120 sends an outbound instruction 1128 to the node 1 108, 1 120 that handled the incoming SMS message, wherein the outbound instruction 1 128 instructs the node to establish a voice link with an agent 1610 of the merchant manager.
  • the instruction 1 128 may inform the node 1 108, 1 120 to effect the connection to the agent 1610 directly or to forward instructions to another one of the plurality of nodes 1108, 1 120.
  • the managing core utilises the nodes to establish a voice connection between the customer 1640 and the agent 1610, in the manner described above with reference to FIG. 12.
  • the customer is connected to the agent to discuss the outstanding account balance, corresponding to object 2015 of the call conversation map 2000. Control passes from step 2455 to step 2460 and the method 2400 terminates.
  • the conversation engine 2120 sends an outbound instruction 1 128 to the node 1 108, 1120 that handled the incoming SMS message, wherein the outbound instruction 1128 instructs the node to establish a voice link with the customer 1640.
  • the instruction 1128 may inform the node 1 108, 1120 to effect the connection to the customer 1640 directly or to forward instructions to another one of the plurality of nodes 1108, 1120.
  • Control passes from step 2465 to step 2470, in which the managing core 1 130 utilises the nodes to establish a voice connection between the customer 1640 and then utilises an IVR coupled to a node 1108, 1102 to play a recorded announcement welcoming the customer 1640 to the payment system, corresponding to object 2025 of the call conversation map 2000.
  • Control passes from step 2470 to step 2475, in which the customer 1640 utilises a keypad of the mobile telephone handset to enter credit card details, corresponding to object 2035.
  • step 2475 the customer 1640 utilises the keypad of the mobile telephone handset to enter credit card expiry details, corresponding to object 2040.
  • Control passes to step 2485, which processes the credit card payment, corresponding to object 2050. Control then passes to decision step 2490, which determines whether or not the payment is successful. If the payment is successful, YES, control passes to step 2495, in which the conversation engine 2120 instructs a node to play a recorded announcement from the IVR thanking the customer 1640 for the payment and advising the customer 1640 of the receipt number, corresponding to object 2055. Control passes to step 2496, in which the conversation engine 2120 instructs a node 1 108, 1 120 to send an SMS message to the customer 1640 confirming payment and again providing the receipt number, corresponding to object 2060. Control passes from step 2496 to step 2460 and the method 2400 terminates.
  • the recorded message provides the customer 1640 with the option of pressing "1” to re-attempt the payment process and pressing "2" to speak to an agent 1610.
  • the disclosure above provides various significant systems and methods for managing communication data.
  • the present embodiments allow for a distributed system architecture that allows for high levels of scalability and adaptability.
  • 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.
  • 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.
  • 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 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.
  • computer-readable code e.g., software
  • 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.
  • the memory and the processor also constitute computer-readable carrier medium carrying computer-readable code.
  • a computer-readable carrier medium may form, or be included in a computer program product.
  • 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.
  • PC personal computer
  • PDA Personal Digital Assistant
  • 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 anyone or more of the methodologies discussed herein.
  • 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.
  • a computer-readable carrier medium carrying 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.
  • 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.
  • 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.
  • the software may further be transmitted or received over a network via a network interface device.
  • 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 centralised 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 anyone 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.
  • carrier medium shall accordingly be taken to include, 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; a carrier wave bearing a propagated signal detectable by at least one processor of the one or more processors and representing the set of instructions a propagated signal and representing the set of instructions; 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.
  • 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.
  • 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.
  • 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.
  • the arrangements described are applicable to the computer and data processing industries and particularly for the telecommunications, call centre, and data management industries.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • Marketing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Telephonic Communication Services (AREA)

Abstract

La présente invention concerne un procédé et un système de cartographie d'une communication téléphonique. Ce procédé consiste à créer une carte de la communication téléphonique (2000) qui comporte une pluralité d'objets (2005, 2010, 2015) et au moins une liaison de connexion permettant de définir un procédé de traitement de la communication. Selon ce procédé, les objets (2005, 2010, 2015) comportent au moins une tâche (2010) se rapportant à la réception d'une communication entrante ou à la génération d'une communication sortante. Le procédé consiste alors à activer la carte de communication téléphonique (2000) en réaction à un déclenchement (2140) et à traiter les communications conformément au procédé du traitement de la communication de la carte de communication téléphonique (2000).
PCT/AU2011/000846 2010-07-05 2011-07-05 Gestionnaire de communications téléphoniques WO2012003534A1 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
AU2010902979A AU2010902979A0 (en) 2010-07-05 Systems and methods for managing communication data
AU2010902979 2010-07-05
AU2011901844 2011-05-13
AU2011901844A AU2011901844A0 (en) 2011-05-13 Call conversation manager

Publications (1)

Publication Number Publication Date
WO2012003534A1 true WO2012003534A1 (fr) 2012-01-12

Family

ID=45440698

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/AU2011/000846 WO2012003534A1 (fr) 2010-07-05 2011-07-05 Gestionnaire de communications téléphoniques

Country Status (1)

Country Link
WO (1) WO2012003534A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110351442A (zh) * 2019-06-06 2019-10-18 平安科技（深圳）有限公司 坐席消息提示方法、装置、计算机设备及存储介质
US20230031114A1 (en) * 2021-07-27 2023-02-02 Synchrony Bank Unique device identification system

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006031200A1 (fr) * 2004-09-15 2006-03-23 Crimsonlogic Pte Ltd Service de gestion des appels
US20070124740A1 (en) * 2005-11-04 2007-05-31 Sap Ag Systems and methods for adapting procedure calls to service providers
US20100153106A1 (en) * 2008-12-15 2010-06-17 Verizon Data Services Llc Conversation mapping

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006031200A1 (fr) * 2004-09-15 2006-03-23 Crimsonlogic Pte Ltd Service de gestion des appels
US20070124740A1 (en) * 2005-11-04 2007-05-31 Sap Ag Systems and methods for adapting procedure calls to service providers
US20100153106A1 (en) * 2008-12-15 2010-06-17 Verizon Data Services Llc Conversation mapping

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110351442A (zh) * 2019-06-06 2019-10-18 平安科技（深圳）有限公司 坐席消息提示方法、装置、计算机设备及存储介质
CN110351442B (zh) * 2019-06-06 2022-10-28 平安科技（深圳）有限公司 坐席消息提示方法、装置、计算机设备及存储介质
US20230031114A1 (en) * 2021-07-27 2023-02-02 Synchrony Bank Unique device identification system

Similar Documents

Publication Publication Date Title
US9489658B2 (en) Universal communication system
US11516345B1 (en) Template-based management of telecommunications services
US9001975B2 (en) Contact center recording service
US8705712B2 (en) System and method for delivering content to a user of a telephony device
US20060050686A1 (en) Software platform for developing, delivering and managing data-voice applications operating on an internet protocol (IP) phone
JP2013540407A (ja) 通話の転送速度の効率を最大限にするためのシステムおよび方法
US9681278B2 (en) VOIP service with streamlined conferencing options
US20190260877A1 (en) Centralized crm and call routing service for multiple enterprises
US11115373B1 (en) Multi-channel engagement platform converter
US10298751B1 (en) Customization of alerts using telecommunications services
US20210392234A1 (en) Voice enabled iot using second line service
WO2012003533A1 (fr) Système et procédé de centre de contact
US20230188503A1 (en) Data analytics collection using vpn gateway
WO2012003534A1 (fr) Gestionnaire de communications téléphoniques
US20210392232A1 (en) Audio broadcast system with cloud communications platform and related methods
US10122862B2 (en) Systems and methods for connecting heterogeneous networks
US9042528B2 (en) Data communication
Ilag et al. Teams Audio Conferencing and Phone System Management
US11412084B1 (en) Customization of alerts using telecommunications services
US11818011B2 (en) User experience workflow configuration
US20230298041A1 (en) Event-Based Contact Center Deployment
Ilag et al. Microsoft Teams Phone (Voice) Configuration and Management
Kajendran et al. 24/7 Call Center Solution: Business Purpose Call Center System with Asterisk PABX
WO2020049323A1 (fr) Système pour passer et recevoir des appels téléphoniques
WO2018235090A1 (fr) Systèmes et procédés d'exécution de programmes interactifs sélectionnés au cours d'un appel téléphonique

Legal Events

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

Ref document number: 11803010

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11803010

Country of ref document: EP

Kind code of ref document: A1