System and method for providing a callback cloud

A system for providing a callback cloud, comprising an application server operated by a callback cloud service provider, a media server, a session management server, an interaction manager, and an intent analysis engine. The application server receives registrations from callback providers unaffiliated with the callback service provider. The application server is adapted to receive callback requests from users, comprising a specific callback provider from whom a callback is requested, when a requested callback should be made, and allowable media types. The application server directs the callback request to the interaction manager, and the interaction manager sends data elements pertaining to the request to the intent analysis engine and receives therefrom data elements pertaining to the callback request determined based on an analysis of the requester's intent. The interaction manager directs the session management server to initiate a callback, and the session management server provides signaling to the media server to conduct the callback.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The systems and methods described herein relate to managing the queuing of clients waiting to be connected by telephone to a service agent of a business communication center. More particularly, the systems and methods described herein relate to providing a callback cloud service that enables client interactions to be added to a cloud-based virtual queue utilizing web service messaging and relate to establishing a communications interaction or connection between clients and service agents on an automated basis and in an order maintained by a queue.

2. Discussion of the State of the Art

Many businesses use groups of service representatives for communicating with clients who initiate communications with the business, such as by telephone calls. To most efficiently use the time and skills of each service representative, the service representatives may be organized into groups based on a skill set. For example, the groupings may be based on the representative's ability to handle client issues such as the opening of new accounts, billing issues and customer service issues on existing accounts.

Typically, if a client calls such a business, voice prompt menu choices enable the calling client to identify the issue for which the client requires service and the client is then queued for a service agent capable of handling the identified issue. As such, it is expected that clients who identify the purpose of their call as a “billing issue” will be queued for, and connected to, a service representative with the ability to handle billing issues. Similarly, it is expected that clients who identify the purpose of their call as a “customer service issue” will be queued for, and connected to, a service representative with the ability to handle customer service issues.

There are problems with existing communications systems, such as contact centers, including the following two problems. First, the voice prompt menus that are used to channel callers to the queue for the appropriate group of service agents are exacerbating to a client at best. It takes significant time to navigate the layered menus of voice prompts.

Second, waiting on-hold while the telephone connection is maintained in queue for connection to a service agent is also exacerbating to a client at best.

In an effort to reduce customer exacerbation caused by having to maintain a connection while on-hold in queue, secondary queue systems have been developed. A typical secondary queue system obtains a telephone number at which the calling client can be reached when a service representative is available (i.e., a call back number). The client disconnects, and then, at the proper time, a call back system establishes a connection to the client utilizing the call back number and couples the client to an available representative without waiting on-hold in queue. One exemplary system is disclosed in U.S. Pat. No. 6,563,921 to Williams et al., which is commonly assigned with the present application.

While such a system may make the experience of waiting for a connection to a service representative slightly less exasperating, it does not address the inconvenience of having to navigate an irritatingly slow and usually complicated voice prompt menu to enter the queue.

What is needed is a system and various methods for providing a callback cloud and related services that overcome the limitations of the prior art noted above.

SUMMARY OF THE INVENTION

Accordingly, the inventor has conceived, and reduced to practice, various systems and methods for providing a callback cloud.

In a preferred embodiment of the invention, a system for providing a callback cloud is disclosed. According to the embodiment, the system comprises a callback cloud, which may accept requests from a plurality of communications networks, such as a Public Switched Telephone Network (PSTN) or the Internet. Such requests may include a request for callback, request for estimated callback time, or a status or presence request from a customer service group or individual. In addition, the Internet connected device sends a callback number in the form of data to the callback cloud, which it will utilize to create a voice connection between the requester and the party to be reached. In addition to the phone number of the originating party, the callback cloud also accepts data requests in the form of a logo, avatar, photograph, QR code, or other symbol. Communication networks may be connected to a plurality of consumer users communicating via a variety of devices such as a traditional or cellular telephone, laptop or desktop computer, or mobile tablet. Such devices may be communicating via a variety of means, such as a traditional telephone dialer for placing calls, a Voice over IP (VOIP) client application for placing calls over an Internet connection, or one of a host of web browsing applications. A communications network may be further connected to a variety of enterprise users communicating through a network switch or directly through a cellular telephone, and additional devices may be connected via internal Local Area Networks (LANs) or Wide Area Networks (WANs), such as mobile tablets or personal computers, again each of which may use a variety of communication means such as dialers, VOIP, or web browsers. Such devices may then be connected via a computer acting as a network bridge, which connects two different communications networks so that devices may share them—such as allowing a mobile tablet PC to communicate via a PSTN using common telephone technology rather than using the Internet for VOIP or web browsing. It will be appreciated by one having ordinary skill in the art that such network configurations are exemplary, and a host of additional devices, technologies, and arrangements are possible and becoming possible as the art progresses.

In another preferred embodiment of the invention, an infrastructure for a callback cloud is disclosed. According to the embodiment, a callback cloud may receive incoming data from a communications network such as a PSTN via a telephony switch or media server, or from the Internet via a media or web server. Data from such servers may then be processed by a plurality of second-layer integration services, such as a Computer Telephony Integration (CTI) server or Session Initiation Protocol (SIP) server, which may translate data to make it usable and available to other internal services such as a rules engine, which may apply conditions or routing rules for callback requests, and a data store which may collect requester data. It will be appreciated that such services are exemplary, and additional elements may be incorporated according to the invention.

In another preferred embodiment of the invention, a method for providing a callback cloud comprising the steps of registration, acceptance, matching, acknowledgement, and connection is disclosed. According to the embodiment, in an initial registration step a user or organization desiring to be available for requests for callbacks from the user's friends, the organization's customers, or the like (collectively, these may be considered to be “callback participants”), may register with a callback cloud so that they can be reached through it. Similarly, persons anticipating future needs to be called back using a callback service may be allowed to register with the service, providing a plurality of contact means (phone numbers and the like) that may be maintained (generally in confidence) by the provider of the callback cloud (these registrants may be referred to herein also as “callback requesters”). In some cases, certain individuals or organizations may act at various times as both callback participants and callback requesters, and registration should be understood to encompass both scenarios. This prevents the need for individuals to publish their phone numbers in directory listings, and maintains a level of anonymity and privacy that may be desirable to many users. Parties may be groups, companies, or individuals and they may register their name, phone numbers, logos, avatars, photographs, QR codes or other unique symbol or identifier (which may be completely arbitrary and chosen by the requester)—this is in contrast to traditional telephone directories, where the forms of identification are often limited to a phone number, name, and address information or other language-based identifiers which can be easily entered on a traditional telephone keypad or dialer and which may require a user to make personally-identifiable information available to unknown parties rather than arbitrarily-chosen unique symbolic identifiers. After registration, a callback cloud accepts requests for callback from individuals, each request specifying a person or organization from whom a callback is desired. The callback cloud then attempts to match the data received with the request against a database of registration data to determine if the party from whom a callback is requested has previously registered with the callback cloud. Once a match is found in a matching step, a callback cloud may obtain additional data from the request or from the party from whom a callback was requested, and may thereupon send the obtained data back to the requester in an acknowledgement step indicating an estimated callback time or a status, and may include additional information such as application-specific details depending on how the initial request was received, or user-specific data based on additional requests by the requester. In a final connection step, callback cloud connects the two parties without either party knowing the phone number of the other, based entirely on the unique identifier(s) provided by each user upon registration. Such a method allows users to disclose only that information which they feel comfortable making available to unknown parties, and it will be appreciated that such a level of privacy may be highly desirable and at the same time difficult to achieve with existing systems and methods.

In a very real sense, the invention disclosed herein shifts away from “routing interactions” to “routing intentions”. That is, when a consumer decides to call a toll-free number to reach an enterprise, on one level she is dialing or entering an address that corresponds to a particular endpoint device such as a phone. But on a more meaningful level, her intent is quite different; she wants to contact someone who can help her with some problem or question pertaining to the company she is calling. Similarly, when a person dials a number of a colleague's work phone, then checks presence status of that colleague on an instant messaging system, then dials that colleague's mobile phone, he is carrying out three distinct interaction initiations targeting three different endpoints (and two different types of interactions), but his intent is the same throughout: he urgently wishes to converse with the colleague. Conventional routing systems are designed to route an interaction (such as a phone call or an instant message) to an available resource. The instant invention, on the other hand, in a very real sense enables businesses or individuals (or indeed other entities) to specify rules for routing intentions, or to provide an intent routing system. Taking the previous example, the person trying to reach his colleague could state his intent: “I need to reach the head of sales in Wisconsin”, and a system according to the invention could analyze that intention. For example, the system could determine who is the head of sales in Wisconsin (the person stating his intent might not actually know); it could consult default rules and person-specific rules applying to or set up by the head of sales in Wisconsin; it could decide based on circumstances which is the best channel (office phone, home phone, mobile phone, instant messaging, a conference room phone, etc.) to use to connect the person seeking and the person being sought; it could make prioritization decisions, and might for example come back to the requester and state, “Bob Jones is in a meeting, but could speak with you at 3:30 this afternoon; please advise if this time is acceptable”. Thus intent analysis is an important part of the overall scheme of the invention: what is intended, with what priority, with what time and channel constraints (if any), and who may satisfy the intended need (a specific person, an application, anyone with a specific skill, and so forth, can all be determined by automated analysis of the intentions of a person initiating contact. In the context of a callback cloud, “intent” generally relates either to a callback provider's registering with the callback cloud and specifying rules of availability, priority, and the like; or to a callback requester's intentions as explicitly or implicitly provided at the moment when a callback is requested. Importantly, in many cases the callback cloud will be able to mediate intentions of callbacks providers and requesters and initiate callbacks accordingly, without requiring either party to obtain or use sensitive information such as phone numbers, account numbers, and the like. In some situations, a plurality of intents may be combined and handled via a single callback. In some embodiments, one or more entities may act as “intent brokers” and may thereby facilitate connection of two or more parties or resources (which may comprise entities such as persons, communications devices, applications, and the like) to satisfy a plurality of intents pertaining to one or more of the parties or resources.

According to a preferred embodiment of the invention, a system for providing a callback cloud, comprising an application server software module operating on a network-attached computer and operated by a callback cloud service provider; a media server accessible via a network by the application server; a session management server operating on a network-attached computer and coupled to the media server; an interaction manager software module operating on a network-attached server; an intent analysis engine software module operating on a network-attached server; and a callback cloud database operating on a network-attached computer is disclosed. According to the embodiment, the application server is adapted to receive registrations from participating callback providers unaffiliated with the callback service provider, the registrations providing at least a plurality of channels and endpoints from which callbacks may be placed and a plurality of rules regarding when callbacks may be made; the application server is adapted to receive a callback request from a first user, the callback request comprising at least an indicia of a specific callback provider from whom a callback is requested, an indicia of when a requested callback should be made, and an indicia of allowable media types for a requested callback; upon receiving a callback request, the application server directs the callback request to the interaction manager, and the interaction manager sends at least a first plurality of data elements pertaining to the callback request to the intent analysis engine and receives from the intent analysis engine a second plurality of data elements pertaining to the callback request, the second plurality of data elements being determined based at least on an analysis of the intent of the callback request; and the interaction manager directs the session management server to initiate a first callback at a specific time and using a specific channel and resource based at least on the second plurality of data elements, and the session management server provides signaling to the media server to conduct the first callback using the specific channel and resource specified by the interaction manager.

According to another preferred embodiment of the invention, a method for providing a callback cloud, the method comprising the steps of: (a) receiving, at an application server software module operating on a network-attached computer and operated by a callback cloud service provider, a registration from a participating callback provider unaffiliated with the callback service provider, the registration providing at least a plurality of channels and endpoints from which callbacks may be placed and a plurality of rules regarding when callbacks may be made; (b) receiving, at the application server software module, a callback request from a first user, the callback request comprising at least an indicia of a specific callback provider from whom a callback is requested, an indicia of when a requested callback should be made, and an indicia of allowable media types for a requested callback; (c) directing the callback request to an interaction manager software module operating on a network-attached server; (d) sending, using the interaction manager, at least a first plurality of data elements pertaining to the callback request to an intent analysis engine software module operating on a network-attached server; (e) receiving, from the intent analysis engine, a second plurality of data elements pertaining to the callback request, the second plurality of data elements being determined based at least on an analysis of the intent of the callback request; (f) directing a session management server operating on a network-attached computer and coupled to the media server to initiate a first callback at a specific time and using a specific channel and resource based at least on the second plurality of data elements; (g) providing signaling, using the session management server, to a media server accessible via a network, to conduct the first callback using the specific channel and resource specified by the interaction manager; and (h) conducting the first callback as specified.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, various systems and methods for providing a callback cloud. Various techniques will now be described in detail with reference to a few example embodiments thereof, as illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide a thorough understanding of one or more aspects and/or features described or referenced herein. However, it will be apparent to one skilled in the art, that one or more aspects and/or features described or referenced herein may be practiced without some or all of these specific details. In other instances, well known process steps and/or structures have not been described in detail in order to not obscure some of the aspects and/or features described or reference herein.

One or more different inventions may be described in the present application. Further, for one or more of the inventions described herein, numerous alternative embodiments may be described; it should be understood that these are presented for illustrative purposes only. The described embodiments are not intended to be limiting in any sense. One or more of the inventions may be widely applicable to numerous embodiments, as is readily apparent from the disclosure. In general, embodiments are described in sufficient detail to enable those skilled in the art to practice one or more of the inventions, and it is to be understood that other embodiments may be utilized and that structural, logical, software, electrical and other changes may be made without departing from the scope of the particular inventions. Accordingly, those skilled in the art will recognize that one or more of the inventions may be practiced with various modifications and alterations. Particular features of one or more of the inventions may be described with reference to one or more particular embodiments or figures that form a part of the present disclosure, and in which are shown, by way of illustration, specific embodiments of one or more of the inventions. It should be understood, however, that such features are not limited to usage in the one or more particular embodiments or figures with reference to which they are described. The present disclosure is neither a literal description of all embodiments of one or more of the inventions nor a listing of features of one or more of the inventions that must be present in all embodiments.

When a single device or article is described, it will be readily apparent that more than one device or article may be used in place of a single device or article. Similarly, where more than one device or article is described, it will be readily apparent that a single device or article may be used in place of the more than one device or article.

Hardware Architecture

The present invention will now be described in detail with reference to the drawings. In the drawings, each element with a reference number is similar to other elements with the same reference number independent of any letter designation following the reference number. In the text, a reference number with a specific letter designation following the reference number refers to the specific element with the number and letter designation and a reference number without a specific letter designation refers to all elements with the same reference number independent of any letter designation following the reference number in the drawings.

It should also be appreciated that many of the elements discussed in this specification may be implemented in a hardware circuit(s), a processor executing software code which is encoded within computer readable media accessible to the processor, or a combination of a hardware circuit(s) and a processor or control block of an integrated circuit executing machine readable code encoded within a computer readable media. As such, the term circuit, module, server, or other equivalent description of an element as used throughout this specification is intended to encompass a hardware circuit (whether discrete elements or an integrated circuit block), a processor or control block executing code encoded in a computer readable media, or a combination of a hardware circuit(s) and a processor and/or control block executing such code.

It should also be appreciated that the table structures represented in this application are exemplary only and intended to show the mapping of relationships between various data elements. Other table structures may store similar data elements in various manners. Further, the applicant's use of the term “plurality” is intended to indicate not just “at least one”, but one, two, three, or any other quantity. The applicant's use of the term “group” is intended to indicate not just “at least one”, but two, three, or more of the items within the group.

In one embodiment, computing device100includes one or more central processing units (CPU)102, one or more interfaces110, and one or more busses106(such as a peripheral component interconnect (PCI) bus). When acting under the control of appropriate software or firmware, CPU102may be responsible for implementing specific functions associated with the functions of a specifically configured computing device or machine. For example, in at least one embodiment, a computing device100may be configured or designed to function as a server system utilizing CPU102, local memory101and/or remote memory120, and interface(s)110. In at least one embodiment, CPU102may be caused to perform one or more of the different types of functions and/or operations under the control of software modules or components, which for example, may include an operating system and any appropriate applications software, drivers, and the like.

CPU102may include one or more processors103such as, for example, a processor from one of the Intel, ARM, Qualcomm, and AMD families of microprocessors. In some embodiments, processors103may include specially designed hardware such as application-specific integrated circuits (ASICs), electrically erasable programmable read-only memories (EEPROMs), field-programmable gate arrays (FPGAs), and so forth, for controlling operations of computing device100. In a specific embodiment, a local memory101(such as non-volatile random access memory (RAM) and/or read-only memory (ROM), including for example one or more levels of cached memory) may also form part of CPU102. However, there are many different ways in which memory may be coupled to system100. Memory101may be used for a variety of purposes such as, for example, caching and/or storing data, programming instructions, and the like.

In one embodiment, interfaces110are provided as network interface cards (NICs). Generally, NICs control the sending and receiving of data packets over a computer network; other types of interfaces110may for example support other peripherals used with computing device100. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, graphics interfaces, and the like. In addition, various types of interfaces may be provided such as, for example, universal serial bus (USB), Serial, Ethernet, Firewire™, PCI, parallel, radio frequency (RF), Bluetooth™, near-field communications (e.g., using near-field magnetics), 802.11 (WiFi), frame relay, TCP/IP, ISDN, fast Ethernet interfaces, Gigabit Ethernet interfaces, asynchronous transfer mode (ATM) interfaces, high-speed serial interface (HSSI) interfaces, Point of Sale (POS) interfaces, fiber data distributed interfaces (FDDIs), and the like. Generally, such interfaces110may include ports appropriate for communication with appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile and/or non-volatile memory (e.g., RAM).

Although the system shown inFIG. 1illustrates one specific architecture for a computing device100for implementing one or more of the inventions described herein, it is by no means the only device architecture on which at least a portion of the features and techniques described herein may be implemented. For example, architectures having one or any number of processors103may be used, and such processors103may be present in a single device or distributed among any number of devices. In one embodiment, a single processor103handles communications as well as routing computations, while in other embodiments a separate dedicated communications processor may be provided. In various embodiments, different types of features or functionalities may be implemented in a system according to the invention that includes a client device (such as a tablet device or smartphone running client software) and server systems (such as a server system described in more detail below).

Regardless of network device configuration, the system of the present invention may employ one or more memories or memory modules (such as, for example, remote memory block120and local memory101) configured to store data, program instructions for the general-purpose network operations, or other information relating to the functionality of the embodiments described herein (or any combinations of the above). Program instructions may control execution of or comprise an operating system and/or one or more applications, for example. Memory120or memories101,120may also be configured to store data structures, configuration data, encryption data, historical system operations information, or any other specific or generic non-program information described herein.

Because such information and program instructions may be employed to implement one or more systems or methods described herein, at least some network device embodiments may include nontransitory machine-readable storage media, which, for example, may be configured or designed to store program instructions, state information, and the like for performing various operations described herein. Examples of such nontransitory machine- readable storage media include, but are not limited to, magnetic media such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROM disks; magneto-optical media such as optical disks, and hardware devices that are specially configured to store and perform program instructions, such as read-only memory devices (ROM), flash memory, solid state drives, memristor memory, random access memory (RAM), and the like. Examples of program instructions include both object code, such as may be produced by a compiler, machine code, such as may be produced by an assembler or a linker, byte code, such as may be generated by for example a Java™ compiler and may be executed using a Java virtual machine or equivalent, or files containing higher level code that may be executed by the computer using an interpreter (for example, scripts written in Python, Perl, Ruby, Groovy, or any other scripting language).

In some embodiments, systems according to the present invention may be implemented on a standalone computing system. Referring now toFIG. 2, there is shown a block diagram depicting a typical exemplary architecture of one or more embodiments or components thereof on a standalone computing system. Computing device200includes processors210that may run software that carry out one or more functions or applications of embodiments of the invention, such as for example a client application230. Processors210may carry out computing instructions under control of an operating system220such as, for example, a version of Microsoft's Windows™ operating system, Apple's Mac OS/X or iOS operating systems, some variety of the Linux operating system, Google's Android™ operating system, or the like. In many cases, one or more shared services225may be operable in system200, and may be useful for providing common services to client applications230. Services225may for example be Windows™ services, user-space common services in a Linux environment, or any other type of common service architecture used with operating system210. Input devices270may be of any type suitable for receiving user input, including for example a keyboard, touchscreen, microphone (for example, for voice input), mouse, touchpad, trackball, or any combination thereof. Output devices260may be of any type suitable for providing output to one or more users, whether remote or local to system200, and may include for example one or more screens for visual output, speakers, printers, or any combination thereof. Memory240may be random-access memory having any structure and architecture known in the art, for use by processors210, for example to run software. Storage devices250may be any magnetic, optical, mechanical, memristor, or electrical storage device for storage of data in digital form. Examples of storage devices250include flash memory, magnetic hard drive, CD-ROM, and/or the like.

In some embodiments, systems of the present invention may be implemented on a distributed computing network, such as one having any number of clients and/or servers. Referring now toFIG. 3, there is shown a block diagram depicting an exemplary architecture for implementing at least a portion of a system according to an embodiment of the invention on a distributed computing network. According to the embodiment, any number of clients330may be provided. Each client330may run software for implementing client-side portions of the present invention; clients may comprise a system200such as that illustrated inFIG. 2. In addition, any number of servers320may be provided for handling requests received from one or more clients330. Clients330and servers320may communicate with one another via one or more electronic networks310, which may be in various embodiments of the Internet, a wide area network, a mobile telephony network, a wireless network (such as WiFi, Wimax, and so forth), or a local area network (or indeed any network topology known in the art; the invention does not prefer any one network topology over any other). Networks310may be implemented using any known network protocols, including for example wired and/or wireless protocols.

In addition, in some embodiments, servers320may call external services370when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services370may take place, for example, via one or more networks310. In various embodiments, external services370may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in an embodiment where client applications230are implemented on a smartphone or other electronic device, client applications230may obtain information stored in a server system320in the cloud or on an external service370deployed on one or more of a particular enterprise's or user's premises.

Similarly, most embodiments of the invention may make use of one or more security systems360and configuration systems350. Security and configuration management are common information technology (IT) and web functions, and some amount of each are generally associated with any IT or web systems. It should be understood by one having ordinary skill in the art that any configuration or security subsystems known in the art now or in the future may be used in conjunction with embodiments of the invention without limitation, unless a specific security360or configuration350system or approach is specifically required by the description of any specific embodiment.

Description of System Architecture

FIG. 4is a block diagram of a preferred embodiment of the invention, illustrating an exemplary architecture of a system400for providing a callback cloud service. According to the embodiment, callback cloud401may receive requests440via a plurality of communications networks such as a public switched telephone network (PSTN)403or the Internet402. Such communications networks may be connected to a plurality of consumer endpoints410and enterprise endpoints420as illustrated, according to the particular architecture of communication network involved. Exemplary consumer endpoints410may include, but are not limited to, traditional telephones411, cellular telephones412, mobile tablet computing devices413, laptop computers414, or desktop personal computers (PC)415. Such devices may be connected to respective communications networks via a variety of means, which may include telephone dialers, VOIP telecommunications services, web browser applications, SMS text messaging services, or other data communications services. It will be appreciated by one having ordinary skill in the art that such means of communication are exemplary, and many alternative means are possible and becoming possible in the art, any of which may be utilized as an element of system400according to the invention. PSTN403(or alternatively Internet402, not shown explicitly inFIG. 4for simplicity) may be further connected to a plurality of enterprise endpoints420, which may comprise cellular telephones421, telephony switch422, desktop environment425, internal Local Area Network (LAN) or Wide-Area Network (WAN)430, and mobile devices such as tablet computing device428. As illustrated, desktop environment425may include both a telephone427and a desktop computer426, which may be used as a network bridge to connect a telephony switch422to an internal LAN or WAN430, such that additional mobile devices such as tablet PC428may utilize switch422to communicate with PSTN402. Telephone427may be connected to switch422or it may be connected directly to PSTN402. It will be appreciated that the illustrated arrangement is exemplary, and a variety of arrangements that may comprise additional devices known in the art are possible, according to the invention. Callback cloud401may respond to requests440received from communications networks with callbacks appropriate to the technology utilized by such networks, such as data or Voice over Internet Protocol (VOIP) callbacks447sent to Internet402, or time-division multiplexing (TDM) such as is commonly used in cellular telephony networks such as the Global System for Mobile Communications (GSM) cellular network commonly used worldwide, or VOIP callbacks to PSTN403. Data callbacks447may be performed over a variety of Internet-enabled communications technologies, such as via e-mail messages, application pop-ups, or Internet Relay Chat (IRC) conversations, and it will be appreciated by one having ordinary skill in the art that a wide variety of such communications technologies are available and may be utilized according to the invention. VOIP callbacks may be made using either or both traditional telephony networks such as PSTN403or over VOIP networks such as Internet402, due to the flexibility to the technology involved and the design of such networks. It will be appreciated that such callback methods are exemplary, and that callbacks may be tailored to available communications technologies according to the invention.

According to the embodiment, callback participants (a person or organization that makes callbacks using callback cloud, when requested) and users (callback requesters) may register with callback cloud400. Callback participants generally provide detailed information about their availability to make callbacks, telecommunications data pertaining to generating callbacks (for instance, phone numbers and possibly queue numbers to which callback attempts from callback cloud400should be connected). Callback participants also typically provide information such as their names, phone numbers, logos, avatars, photographs, QR codes or other unique symbol or identifier (which may be completely arbitrary and chosen by the participant). For requesters, registration typically captures information including, but not limited to, their name, phone number (or other contact information such as instant messaging user identifier), as well as optional information such as hours when they desire callbacks to be made, hours which they designate as “off limits”, special handling instructions, and the like. Requesters may be individuals, organizations or enterprises, or any other entity that may have need for a callback service. An exemplary method of registration is illustrated later in greater detail, referring toFIG. 9.

As an example of operation, an individual requester might register with callback cloud400and provide some level of personal information including (for example) a telephone number and hours during which such number might be used to reach them, as well as some information on products or services which they might be qualified to assist others with. According to the embodiment, another individual may register with callback cloud400for the purpose of requesting a callback from a previously registered individual, an exemplary method for which is described later in detail, with reference toFIG. 10.

FIG. 5is a block diagram illustrating an exemplary architecture of a callback cloud500, according to a preferred embodiment of the invention. According to the embodiment, a callback cloud500may comprise a plurality of front-end elements to accept incoming data requests, such as web server501, which may accept requests from Internet402, media server502which may accept requests from either Internet402or a PSTN403, or telephony switch504which may accept requests from a PSTN403. It will be appreciated that such elements are exemplary, and additional or alternate arrangements accepting requests from a variety of communications networks are possible according to the invention. Data requests may be passed from front-end services to secondary services for processing, such as CTI server505, SIP server503, or callback application server510, each of which may translate incoming request data for interaction with a plurality of computer services, such as campaign manager511which may manage information about requesters such as when or why an interaction should take place between two resources, interaction manager512which may handle matching, distribution, and queuing of interactions with a plurality of processing parties such as agents, chatbots, or other virtual assistants or adding a request to a callback queue if a selected resource is busy, rules engine513which may receive incoming requests and apply predetermined or configurable rules to determine possible actions, such as when a callback is to be performed, to what available contact method a callback should be made, what to do if a callback attempt fails, how to prioritize a callback in a queue, or other relevant actions, operational analysis engine514which may work in conjunction with an intent analyzer515for the purpose of handling decision-making logic such as selecting and assigning resources to handle callback requests, such that callbacks will be handled by the most relevant and capable available resource. A “resource” in this case may refer to an individual, a contact center agent, an automated response application, chatbot, or other relevant party according to the nature of the callback request and, optionally, any rules assigned to the callback during processing as described previously. Callback cloud500may further comprise a database520, which may collect and store requester data and may be any of a variety of database types, such as an SQL-based relational database or distributed non-relational database such as Hadoop HDB. Callback cloud500may further comprise an integration server516, which may connect to a plurality of enterprise applications530. In general, switch504and media server502are examples of, and act as, media handling endpoints of callback cloud500. Similarly, CTI server505and SIP server503are examples of, and act as, signaling components that may be further characterized as session management components. Operational analysis engine514is a software component used to analyze operational data such as call arrival rates, callback request and completion rates, availability patterns of skilled resources, interaction lengths of various kinds (channel types or skills), and so forth. Thus operational analysis engine514may be used to determine an optimal time for reaching a specific person based on patterns determined from historical data; it may be used to determine when (or if) to expose a callback button or link on a web page based on for example inbound call volumes (which can be used to compute an estimate of resources that will be available in a certain period based on an expected call arrival rate and an expected staffing level for that period); or it can be used to select an optimal channel for a given callback based on an analysis of which channels are most successful at different times for the person or class of persons in question. Similarly, intent analysis engine515may be used to take an expression of intent (such as, “Get me Bob Sherman”), and to analyze it to determine whether, when, and how to connect the requester with Bob Sherman; such analyses may be based on a host of available data elements, such as stated preferences of the requester, communications capabilities or preferences of Bob Sherman, Bob Sherman's work schedule, corporate security or availability policies, and so forth. Intent analysis engine515may determine what channel to use, how many attempts to make before signaling failure, and also what targets to use (sometimes a user will express an intent such as “get me a service expert for dishwashers”, and intent analysis engine515may determine which resources may be considered for conducting a callback). Similarly, rules engine513may be used to store and test a plurality of rules set by default, by a specific enterprise, by a requester, or by the system, in order for example to determine using conventional rules-based techniques whether a callback is in fact authorized, or whether it must be scheduled for a later time, and so forth. In some embodiments, one or more instances of rules engine513, operational analysis engine514, and intent analyzer515may reside and operate on a single machine or even as a single executable program; the three components are shown separately inFIG. 5and elsewhere in order to highlight their various logical functions within callback clouds of the invention.

FIG. 6is a block diagram illustrating an exemplary architecture of a system600comprising a callback cloud500, which may be connected to PSTN403, Internet402, or an enterprise endpoint610, according to an embodiment of the invention. According to the embodiment, a callback cloud500may comprise a plurality of front-end elements to accept incoming data requests, such as web server501which may accept requests from Internet402, and media server502which may accept requests from a PSTN403. It will be appreciated that such elements are exemplary, and additional or alternate arrangements accepting requests from a variety of communications networks are possible according to the invention. Data requests may be passed from front-end services to secondary services for processing, such as SIP server503which may translate incoming request data for interaction with a plurality of computer services, such as campaign manager511which may manage information about requesters such as when or why an interaction should take place between two requesters, interaction manager512which may handle matching, distribution, and queuing of interactions with a plurality of processing parties such as agents, chatbots, or other virtual assistants, rules engine513which may receive incoming requests and apply predetermined or configurable rules to determine whether a callback is appropriate, operational analysis engine514, or intent analyzer515which may handle decision-making and assigning resources to handle callback requests. Callback cloud500may further comprise an integration server513which may connect to an enterprise endpoint610via CTI server612or statistics server613, each of which may be internal to enterprise endpoint610and which handle the routing of data between callback cloud500and a plurality of enterprise user workstations, each of which comprising a telephone620or similar telecommunications device and a PC621, and which may also be further connected to an Automatic Call Distributer (ACD)611, which handles the routing and distribution of telephony calls between enterprise users and a PSTN403. PSTN403may be connected to a plurality of consumer endpoints, such as a telephone411or cellular phone412. Internet402may be similarly connected to a plurality of consumer endpoints, such as cellular phones412, tablet computing devices413, laptop PCs414, or desktop PCs415. It will be appreciated by one having ordinary skill in the art that such configurations are exemplary, and alternate configurations are possible according to the invention.

As an example, when a requester submits a callback request for a previously registered participant, their request might be sent to an interaction manager512for initial handling. Interaction manager512might then determine that callback-specific rules need to be applied (such as when an individual might request a callback in reference to a company's product or services, necessitating that the resource chosen to complete the callback request at least be knowledgeable about the subject matter), and request is then sent to rules engine513to apply any necessary rules or conditions and determine how to further process request. Continuing with the above example, the request might then be sent to either or both an analysis engine514or intent analyzer515for determination of which resource to complete a callback, based on previously-determined information and rules specific to this interaction. The request now has enough information to attempt an interaction, and interaction manager512may then attempt to complete a callback by connecting the requester to the chosen resource, or add the interaction to a new or existing queue if the resource is currently unavailable, such as a contact center agent currently engaged in a previous interaction. An exemplary method for this process is described in greater detail later, referring toFIG. 11.

FIG. 7is a block diagram illustrating an exemplary architecture of a system700comprising a callback cloud500further comprising a federation manager710which may handle interactions between a plurality of enterprise endpoints as shown, which may be connected to PSTN403, which may then be connected to a plurality of enterprise endpoints via a variety of means such as a media server722, ACD731, or media server741, each of which may then be connected to a request handler internal to an enterprise endpoint, such as SIP server721, CTI server732, or SIP server742. In this manner callback cloud500may provide federated customer service for enterprise endpoints such that requests may be handled optimally by a plurality of endpoints for any exemplary enterprise, and such that a requester need not necessarily be aware of their plural nature. As illustrated, request handlers (such as SIP server721, CTI server732, or SIP server742, previously described) may be further connected to Internet402, which relays incoming requests701. As illustrated in exemplary enterprise endpoint A720, a SIP server721may be connected internally to enterprise agents723, Customer Relationship Management server724, or enterprise applications725. In an exemplary enterprise B730, a CTI server732may be connected to enterprise agents733, CRM server734, or enterprise apps735as well as directly connected to Internet402such that it may accept data requests directly without the need for an ACD731. In an exemplary Enterprise C740, a SIP server742may be connected to enterprise agents743, CRM744, or enterprise apps745, as well as directly to Internet402such that it may directly accept incoming data requests without the need for a media server741. It will be appreciated by one having ordinary skill in the art that such configurations are exemplary, and that a wide variety of enterprise architectures are possible according to the invention.

As an example, when an individual requests a callback from an enterprise entity, they may only perceive a single contact point such as a customer service number or tech support e-mail address. When a callback request is submitted, during the handling process internal to callback cloud500a federation manager710is consulted, which may contain stored information about a plurality of actual enterprise endpoints such as individual contact centers or tech support personnel, each of which has a unique contact that need not be exposed to the requester. An exemplary method for this is discussed in greater detail later, referring toFIG. 12.

FIG. 8is a block diagram illustrating an exemplary architecture of a system800comprising a callback cloud500, which may be connected to Internet402, which may be further connected to a plurality of service brokers810, which may receive incoming requests801, which may then be consolidated and sent to callback cloud500via an integration server516, according to an embodiment of the invention. According to the embodiment, a callback cloud500may comprise a plurality of front-end elements to accept incoming data requests, such as web server501which may accept requests from Internet402. It will be appreciated that such elements are exemplary, and additional or alternate arrangements accepting requests from a variety of communications networks are possible according to the invention. Data requests may be passed from front-end services to secondary services for processing, such as SIP server503which may translate incoming request data for interaction with a plurality of computer services, such as campaign manager511which may manage information about requesters such as when or why an interaction should take place between two requesters, interaction manager512which may handle matching, distribution, and queuing of interactions with a plurality of processing parties such as agents, chatbots, or other virtual assistants, rules engine513which may receive incoming requests and apply predetermined or configurable rules to determine whether a callback is appropriate, operational analysis engine514, or intent analyzer515which may handle decision-making and assigning resources to handle callback requests. Callback cloud500may further comprise an integration server513which may receive incoming consolidated requests811from brokers810.

As an example, when a requester submits a callback request to a callback cloud500, a portion of the internal request handling is dedicated to determining the intent or nature of the callback, such as any products or services the request may be in reference to, or any rules specific to the enterprise from which a callback is requested. According to the embodiment, this handling need not be performed internal to a callback cloud, and may be distributed to one or more external service brokers810with their own internal handling procedures and stored information, in such a way that callback cloud500operation may be further distributed and optimized. An exemplary method for this operation is discussed later in greater detail, in reference toFIG. 13.

Description of Method Embodiments

FIG. 9is a process flow diagram illustrating a method900for providing a callback cloud service. In an initial step901, callback participants register with a callback cloud service and provide some initial relevant information, such as their name, telephone number, logo, avatar, photograph, QR code, or other symbol that can be used to uniquely identify the user. Such a user may be an individual, group of persons, an organization, or any of a variety of other entities. In step902, this registration information may be added to a database in the callback cloud, and added to an existing store of registered callback participants and information. In step903, a callback requester may request a callback from the cloud, and in step904the callback requester may specify one or more rules or constraints governing when and how such a callback is to be actualized. In step905any default rules may be obtained from the cloud database, based on such criteria as the user type, callback request type, user-specific defaults, or other criteria. Rules implemented may include scheduled callback times or time ranges, conditions to be met for a callback to take place (Such as when a product is released, or when another user is within their scheduled time range for availability), or queue-based rules determining that a callback is to be placed based on its position in a queue relative to other, similar callback requests. It will be appreciated that such rules and criteria are exemplary, and a multitude of criteria and information may be relevant and used according to the invention. In step906the callback request may be optionally sent to an intent analysis engine515to determine if any further additional rules may be applied based on available information such as resource types, channels available, or other internal information that may not be available to a user for self-expressed rules as described above.

FIG. 10is a process flow diagram illustrating an exemplary method1000for providing a callback service to a contact center, such as might be utilized when a requester submits a callback request from an enterprise customer service department. In an initial step1001, a requester submits a request for callback to the callback cloud. Such a requester may be an individual, group, enterprise, or other entity that might need to contact an enterprise endpoint comprising a contact center. In step1002, request is sent to an interaction manager512, which controls handling of the request. In step1003, interaction manager512may compare the request to known resource information which may be stored in a database520to match the request with existing resources such as known identification or other relevant information about requester, preselected rules for requesters, registered callback participants such as registered enterprise contact centers, rules for handling contact request such as operating hours and contact center service details or ratings, how to handle a failed callback attempt should one or more parties be unreachable at the time a callback takes place, and to further determine which specific resource to match the request with for handling. In step1004, interaction manager512may distribute the request to the selected resource, and optionally may add the request to an existing queue if selected resource is presently unavailable. In a final step1005, interaction manager optionally determines whether to loop back to step1003for further examination after a failed callback attempt, to determine handling for a second callback attempt.

FIG. 11is a process flow diagram illustrating a method1100for providing a consumer-to-consumer (C2C) callback service, such as might be utilized when a requester submits a callback request from a known individual (target) rather than from a customer service endpoint such as, for example, an enterprise contact center or automated response system. In an initial step1101, a requester submits a request for callback to a callback cloud. Request may then be sent to interaction manager512for handling in step1102, and in step1103interaction manager512may compare request data against known data such as identification or other information relevant to requester, known information about the resource form which the callback was requested, such as availability times or contact information, predefined rules or other resource- or interaction-specific details, which may be stored in a database520, as described above. In step1104, interaction manager512may send this information to rules manager513which may act upon the retrieved resource information to determine specific callback procedures such as when a callback should be scheduled to take place based on specified availability times or trigger events, what contact numbers should be used for each participating party, how to react if a callback attempt should fail to reach one or both parties, or other rules defined either globally by one or both parties or defined specifically for this interaction by requester. In step1105, interaction manager512may attempt to complete a callback request when the rules or conditions have been met, if any, and connect requester with the target resource from which a callback was requested. In a final step1106, interaction manager512may re-examine the callback conditions in the event of a contact failure, and optionally determine whether to loop back to step1104for handling of a second callback attempt.

FIG. 12is a process flow diagram illustrating a method1200for providing federated customer service via a callback cloud, such as might be utilized when a requester submits a callback request from an enterprise contact comprising a plurality of contact centers operating independently, optionally with varied contact information, rules or conditions, while serving jointly as contact endpoints for a single enterprise with optionally global rules governing callback interactions or contact conditions. In an initial step1201, a requester submits a request for callback to a callback cloud. Request may then be sent to interaction manager512for handling in step1202, and in step1203interaction manager512may compare request data against known data such as identification or other information relevant to requester, known information about the resource form which the callback was requested, such as availability times or contact information, predefined rules or other resource- or interaction-specific details, which may be stored in a database520, as described above. In step1204, interaction manager512may send this information to federation manager710which may act upon the retrieved resource information to determine specific callback procedures such as when a callback should be scheduled to take place based on specified availability times or trigger events, what contact numbers should be used for each participating party, how to react if a callback attempt should fail to reach one or both parties, or other rules defined either globally by one or both parties or defined specifically for this interaction by requester, and which handles any rules that may apply across a plurality of potential enterprise contact endpoints that may act collectively as contact resources for a single enterprise entity. In step1205, federation manager710may select a contact resource from known federated contact endpoints, and returns this resource to interaction manager512for queuing or completion of callback attempt. In step1206, interaction manager512may distribute the request to the selected resource, and optionally may add the request to an existing queue if selected resource is presently unavailable. In a final step1207, interaction manager512may re-examine the callback conditions in the event of a contact failure, and optionally determine whether to loop back to step1204for handling of a second callback attempt.

FIG. 13is a process flow diagram illustrating a method1300for providing aggregated intention management via service brokers810optionally in place of or in addition to intent manager515or rules engine512. In an initial step1301, a requester submits a request for callback to a callback cloud. In step1302request may be sent to an interaction manager512, which may route request to one or more service brokers810for intent management in step1303. Service brokers810may perform analysis of request to determine handling criteria or rules such as required skills, potentially relevant rules, or potentially relevant contact resources for handling request. In step1304a modified request is returned to interaction manager512for further handling with new intent data taken into account. Interaction manager512may then continue with handling in step1305, according to the nature of the callback request such as C2C, request for a contact center, or other interaction type as previously described.

FIG. 14is a process flow diagram illustrating a method1400for an application callback scenario, such as might be utilized when a callback function is embedded within an application such that a user (requester) may request a callback directly from within the application without necessarily knowing any contact information for a target resource that will respond to the request. In an initial step1401, a requester may be using an application on a computing device such as a mobile phone, tablet computing device, a laptop, or desktop PC. Such devices are exemplary, and it will be appreciated that any electronic or computing device capable of supporting user-interactive applications or programs may be used according to the invention. In step1402, requester may request a callback from within an application via an embedded interface element such as a popup, menu, or button. In step1403, request from application may be enhanced or “bundled” with relevant information gathered from the application such as individual or enterprise contact endpoints, specific products or services, requester's contact information, or other relevant information that may be obtained from the requesting application. In step1404, request and any bundled information may be sent to a callback cloud for handling or distribution according to the nature of the request, as described previously.

FIG. 15is a process flow diagram illustrating a method1500for campaign management using a callback cloud, such that a callback cloud may provide for outbound functionality in addition to accepting inbound requests, and may handle optimization logic or scheduling for callback interactions. In an initial step1501, a requester may establish rules for running an outbound campaign within a callback cloud, optionally establishing rules or criteria for such parameters as target resources (what numbers to call), prioritizing resources based on defined criteria such as (for example) likelihood of contact success or potential profitability, timeframes for outbound calls, decision-making logic for selecting resource contact information (which numbers to call, what contact method to use such as sending a text message to a cellular number vs. a voice call), optimization logic for outbound dialing such as the use of predictive or progressive dialing, or post-dialing logic such as any scripts to be run or prompts to present to an agent upon establishing an interaction, or how to handle a failed callback attempt. According to the embodiment, requester may be an individual, organization, enterprise, or any other entity that may desire to conduct an outbound calling campaign, such as (for example) an enterprise contact center calling potential customer or a public figure campaigning for public support. In step1502, campaign manager511may consult known rules specific to a campaign for the purpose of initiating an outbound callback, optionally in conjunction with rules engine513for rules specific to resources or interactions but not applicable to a campaign globally. Campaign-specific rules may include, but are not limited to, specific rules or policies of an enterprise or individual conducting a campaign, or procedures to be used such as predictive or progressive dialing techniques for outbound contact attempts. Predictive dialing techniques may allow a contact center to optimize agent scheduling by dialing an outbound contact number based on known factors such as handle or response times (such as, for example, if an agent is known to have an average call handle time of 180 seconds and outbound calls have an average wait time of ten second before being answered, an outbound number may be dialed 170 seconds into a current interaction such as to minimize downtime where agent is not engaged in an interaction), and progressive dialing techniques may allow for optimized call handling by presenting information relevant to an outbound contact attempt to an agent prior to dialing a contact number, allowing an agent time to review information prior to an interaction. In step1503, campaign manager511may send an interaction request to interaction handler512, optionally bundled with information specific to campaign or interaction in particular, for interaction handling and processing as described previously. In a final step1504, interaction manager513may perform post-attempt handling such as (for example) determining whether to send information back to campaign manager511and loop to step1501for further processing after a failed contact attempt. It will be appreciated by one having ordinary skill in the art that such campaign and contact descriptions are exemplary, and many possible approaches may be used according to the invention, and that there are many ways in which campaign management may be desirable to an individual, enterprise, or other entity.

FIG. 16is a process flow diagram illustrating a method1600for search-based embedded ad callbacks with estimated wait times (EWTs). In an initial step1601, a requester may be viewing advertisements embedded in a displayed webpage or other electronic document, such as commonly seen in search engine results or on electronic storefronts, any of which may have embedded callback elements such as buttons, popups, or other elements alerting requester to the possibility of a callback and potentially allowing the request thereof. It will be appreciated by one having ordinary skill in the art that such instances are exemplary, and that the presence of embedded advertising is a growing feature in the art and many alternate scenarios are possible according to the invention. Such an advertisement with an embedded callback element may utilize known information about current interactions relevant to the advertisement, such as number or scheduling of available agents to handle interactions, number of current interactions in queue, or other relevant information to display EWT such that an appropriate expectation is set with requester. In step1602, requester may submit a callback request via an embedded element in an advertisement being viewed, such as a button or popup that may notify requester that a callback is possible. In step1603, callback request may be bundled with relevant information gathered from the advertisement or requester's computing device, such as relevant contact endpoints, products or services, geographical location, browser preference, or any other potentially relevant information. In step1604, request with any bundled information may be sent to a callback cloud for handling or distribution according to the nature of the request, as described previously.

FIG. 17is an illustration of exemplary messaging structures packaged with transport layer and media layer information. Message1700shows an exemplary embodiment of a structure for communications or messages passing between communication devices1900and service providers. In this example, the structure of an active provider's remote processing call1703is shown. The structure may be an XML structure1710with applicable SOAP or other remote processing call protocol information1711. The exemplary structure includes at least a method identifier1712, which identifies the active provider routine or process as the remote process, and data arguments1713for the active provider routine. The data arguments1713may include at least identification of the user.

The remote processing call1703may be encapsulated within appropriate TCP/IP and HTTP headers and other transport layer information1702such as source IP address and source port number of the requesting device1900and destination IP address and destination port number of the sequence component. Such combination may be encapsulated within appropriate media layer protocols1701for transmission across physical communication media via various physical layer segments interconnecting the requesting device1900and the sequence component.

Messages1715,1720, and1730show exemplary structures of other messages or communications within system400similar to that of active providers remote processing call1703. The other communications that may be similarly structured, encapsulated, and transported may include the active queue remote processing call1703(message1715), expected wait time call1703(message1720), add-to-queue remote processing call1733, the active providers message1731, the active queue message1733, the expected wait time message1723, and the confirmation remote processing call1703(message1730), for example.

FIG. 18is a block diagram illustrating an exemplary provider control and an exemplary service control, according to an embodiment of the invention. Shown is an illustration of a provider control1800. Provider control1800may be a drop down menu control that displays a group of providers1801. From this menu, a user may select a provider from the selected business communication center.

Service control may be a drop down menu, which displays, for the selected provider, the services/queues of a group of services/queues1802,1803associated with the selected provider's business communication center. A user may select a service from this menu.

Exemplary providers include Company A and Company B. For purposes of illustration, Company A may be a utility company and its services/queues associated with its business communication center may include a service/queue for reporting loss of services, a service/queue for handling billing matters, and a default service/queue for handling other matters.

Company B, for illustration, may be a bank and its services/queues associated with its business communication center may include a service for handling of checking, savings, or other deposit accounts, a service for handling credit card accounts, a service for handling mortgage accounts, and a default service for handling other matters.

FIG. 19Aillustrates an embodiment of the system for managing, directing, and queuing communication events that uses an image sensor located on a communication device1908(e.g., a mobile communicating device) to capture an image of a company logo1902located on, for example, a product and cross-references the captured company logo1904with a database of company contacts. Various available queues, divisions, or individual contacts may be made shown and viewed by the user. An embodiment of the system allows a user to submit a request for a callback, determines an expected wait time1906, and places an outgoing call to the communication device1908after the expected wait time (or an approximately equivalent time) has passed. Alternatively, an embodiment of the system places an outgoing call to another communication receiving device (not shown) having the phone number provided by the user. One skilled in the art will appreciate that the expected wait time1906may be 0 minute and a call is placed immediately, connecting the user to a person or group of people eligible to provide information or answer questions.

FIG. 19Billustrates an embodiment of the system for managing, directing, and queuing communication events that uses an image sensor, such as a bar code scanner, located on, for example, a communication device1918(e.g., a mobile communication device) to scan a bar code1912located on, for example, a product's shipping box1910. One skilled in the art will appreciate that the bar code scanner can be any scanner device, such as a stationary scanner device, handheld or kiosk. Various configurations of scanners are available on the market. The scanner may be removably plugged into the communication device1918. An embodiment of the system retrieves the company information1914from the bar code1912and cross-references the company information1914with a database of company contacts. In one embodiment, the bar code refers directly to a particular queue. In another embodiment, the bar code refers to a set of queues. An embodiment of the system allows a user to submit a request for a callback, determines an expected wait time1916, and places an outgoing call to the mobile device1918after the expected wait time (or an approximately equivalent time) has passed. Alternatively, an embodiment of the system places an outgoing call to another communication receiving device (not shown) having the phone number provided by the user. One skilled in the art will appreciate that the expected wait time1916may be 0 minute and a call is placed immediately, connecting the user to a person or group of people eligible to provide information or answer questions.

FIG. 19Cillustrates an embodiment of the system for managing, directing, and queuing communication events that uses an image sensor, such as a QR code reader, located on, for example, a communication device1928(e.g., a mobile communication device) to scan a QR code1922located on, for example, a company's business card1920. One skilled in the art will appreciated that the QR code reader can be located on any device, such as a non-mobile device or kiosk. Various configurations of QR code readers may be used. An embodiment of the system retrieves the company information1924from the QR code1922and cross-references the company information1924with a database of company contacts. In one embodiment, the QR code refers directly to a particular queue. In another embodiment, the QR code refers to a set of queues. In one embodiment, the system maintains a database of QR codes with additional data associated with the QR codes. In yet another embodiment, a third party maintains a QR code database for referral by the system. An embodiment of the system allows a user to submit a request for a callback, determines an expected wait time1926, and places an outgoing call to the mobile device1928after the expected wait time (or an approximately equivalent time) has passed. Alternatively, an embodiment of the system places an outgoing call to another communication receiving device (not shown) having the phone number provided by the user. One skilled in the art will appreciate that the expected wait time1926may be 0 minute and a call is placed immediately, connecting the user to a person or group of people eligible to provide information or answer questions.

FIG. 9Dillustrates an embodiment of the system for managing, directing, and queuing communication events that uses an image sensor, such as a QR code reader, located on, for example, a communication device1938(e.g., a mobile communication device) to scan a QR code1932located on, for example, a company's webpage1930. One skilled in the art will appreciate that the QR code reader can be located on or connected to any device, such as a non-mobile device or kiosk. The QR code or image to be read can be rendered or created by many different electronic devices such as computers, laptops, tablet/pad devices, phones and other devices with visual displays. An embodiment of the system retrieves company information1934or product information from the QR code1932and cross-references the company information1934with a database of company contacts or product information with a set of queues. An embodiment of the system allows a user to submit a request for a callback, determines an expected wait time1936, and places an outgoing call to the mobile device1938after the expected wait time (or an approximately equivalent time) has passed. Alternatively, an embodiment of the system places an outgoing call to another communication receiving device (not shown) having the phone number provided by the user. One skilled in the art will appreciate that the expected wait time1936may be 0 minute and a call is placed immediately, connecting the user to a person or group of people eligible to provide information or answer questions.

Embodiments of the system and method for managing, directing, and queuing communication events eliminate the need for a user to research, locate and find a specialist of a company to provide information or answer questions regarding a product. When a question about a product or service arises, a user can simply scan the bar code or QR code that is located in the store, on a brochure, on a coupon, or on the actual product, and initiate a callback from a specialist who can answer questions, provide information, or complete an order to be shipped. The specialist may be in any location including for example, a contact center, in the same store, or in a different store. Thus, a purchaser can obtain information about a particular product he is contemplating on purchasing while viewing the product at the store.

In another embodiment (not shown), a card is scanned to locate available queues for a user. Like the other images, the data on the card is associated either directly or indirectly to queues. In other words the card is associated directly to queues or with particular people or a business group of people. Those people or groups of people correspond to or are related to available queues. Virtually any type of card may be used with the system including for example, plastic, paper, magnetic, metal cards and the like, credit cards, store cards, VIP cards, money cards, gift cards, point cards, award cards, library card, cards associated with products or devices such as a doll's ID card or an automobile card, and cards associated with services.

An image device, or more particularly a card scanner, is used to read data from the card. The data from the card is sent to a central location that looks-up the card information and relates it to queues. Information about the queues is sent to the user. A session queuing component displays the associated queues to the user. Estimated wait time information may or may not be made available to the user. Using this queue information, the user is able to select a desired queue or queues. A callback or scheduled call can then be arranged. As with the other embodiments, the card reader may be portable, handheld, or stationary. Various types of card readers and card combinations may be used.

FIG. 19Eillustrates an embodiment of the system for managing, directing, and queuing communication events that uses an image sensor located on a communication device1948(e.g., a mobile communicating device) to capture a registered personal image1942of an individual posted on a social networking website, for example. Individuals can register their own unique image, similar to a Facebook Avatar, in a database. The database of registered individual images and the registration process may be a standalone system or may be hosted on an embodiment of the system for managing, directing, and queuing communication events. The unique image may be placed on various media including electronic, paper, metal, plastic, and fabric for example a tablet computer, a poster, tote bag, brochure, coupon, pen, shirt, or a business card. An embodiment of the system cross-references the captured personal image1944with a database of registered personal images. The image may represent a particular individual or may represent a product, division, or company. An embodiment of the system allows a user to submit a request for a callback from the individual with the registered personal image1942, determines an expected wait time1946, and places an outgoing call to the communication device1948after the expected wait time (or an approximately equivalent time) has passed. Alternatively, an embodiment of the system places an outgoing call to another communication receiving device (not shown) having the phone number provided by the user. One skilled in the art will appreciate that the expected wait time1946may be 0 minute and a call is placed immediately, connecting the user to the individual with the registered personal image1942.

Embodiments of the system and method for managing, directing, and queuing communication events eliminate the need for an individual to give out a phone number. The individual can pass out business cards with the registered personal image1942. The individual can change the personal image and re-register it to change how people contact him or her, similar to changing the individual's phone number.

An embodiment of the system may be in a callback cloud that bridges the user that requests a callback and the individual from which the callback is requested.

An embodiment of the system provides the database and directory for looking up people's personal images, similar to a phone book. Individuals who register their personal images may have an online account in a hosted system. An individual may log into his or her online account and may change his or her personal image and the preferences of communication, e.g., via phone, email, text message, or instant message. The database may also include companies and other callback participants, their registered logos and symbols, and variations of said logos that include accompanying words or images.

An embodiment of the system may add a special symbol to any QR code, bar code, company logo, or personal unique image that indicates that this QR code, bar code, company logo, or personal unique image triggers a callback for a user and connects the user to a relevant person.

FIGS. 20A and 20Bprovide illustrations of an exemplary communication device adapted for use according to an embodiment of the invention. Referring now toFIG. 20A, each device2000may include user interface inclusive of display screen2001and controls2002(such as keys, touch panel, or other controls) for operation of controls rendered on the display screen (keys are represented), memory2005, and processor2004for executing applications encoded in the memory2005.

The applications encoded in memory2005may include a telephone application2010, and/or appropriate systems adapted to drive operation of the user interface, and the session queuing component2011.

The telephone application2010may be adapted to signal, establish, and maintain an audio communication session (either as the session initiator or receiver) with remote endpoint devices over compatible networks (PSTN, VOIP, and other networks utilized for audio communication sessions). The endpoint devices include the business communication center systems for signaling, establishing, and maintaining audio communication sessions between each service agent and the business clients, each of which may utilize one of the communication devices2000for communication with the business.

The session queuing component2011may include a launch object2003rendered as a “My Providers” icon on the display screen2001and adapted to launch operation of the session queuing component2011upon detecting user selection of the launch object2003.

Referring now toFIG. 20B, for purposes of performing the above described functions, visible objects of the session queuing component2011(following activation by selection of the launch icon2003as depicted inFIG. 20A) include a provider control2030, a service control2031, and a confirmation control2020.

The confirmation control2020may include a window2021for confirming the identifier of a communication device2000(i.e., the call back telephone number utilized to establish an inbound telephone call to the communication device2000or other unique “call back” identifier used to establish an audio session with the communication device2000), an accept control object2022and a cancel control object2023.

In an exemplary embodiment, the telephone number of the communication device2000may be pre-populated to the window object2021with the window object being active to enable the user to modify the telephone number in the event he or she desires the call back to be at a different telephone station.

The cancel control object2023may be a selection button adapted to detect user selection. Upon detecting user selection, cancel control object2023may be adapted to terminate operation of the session queuing component.

The accept control object2022may be a selection button adapted to launch the confirmation client upon user selection.

Upon launch of the session queuing component2011the visible objects of the session queuing component2011may be rendered on the display screen2001as depicted inFIG. 19B.

The provider control2030may be rendered in an active state with the group of providers1801populated into its drop down menu. From this menu, the user may select providers from the selected business communication center. The service control2031is shown in an active state. The service control2031and the confirmation control2023may be rendered in an inactive state (i.e., rendered with no populated data, inoperable, and rendered with a gray tint to indicate the inactive state).

FIG. 21is an illustration of an exemplary screenshot illustrating the use of a callback cloud widget, according to an embodiment of the invention. Illustrated is an exemplary social networking webpage2100, such as might be used by such services as Facebook™ or LinkedIn™ by an entity such as an individual or enterprise, or such as might be used by an enterprise to represent products or services in a manner available and convenient for potential consumers to view and interact with. As illustrated, some initial information may be presented on such a page, including but not limited to an individual's name and photograph2101, enterprise identity2102, product or service information2103, or contact information2104. It will be appreciated by one having ordinary skill in the art, that such information is exemplary and a wide variety of page layouts and contents are possible, and that any configuration may be used according to the invention. Page2100may also include an embedded user interface widget2110, which may alert requester to the possibility of a callback from an individual or enterprise represented by page2100, and which may contain interactive elements such as one or more fields2111where requester may enter additional information about a desired interaction, or a button or popup2112allowing requester to submit their request directly from the webpage. As discussed previously in reference toFIG. 14, callback request may be bundled with initial information collected from an electronic environment from which the request originates, such as information presented on page2100which may be relevant to the request or any additional information requester may enter via interactive elements, such as why they requested an interaction or what products or services they wish to discuss.

FIG. 22is an illustration of an exemplary screenshot illustrating the use of embedded ad-based callback cloud functionality, according to an embodiment of the invention. According to the embodiment, embedded advertisements2210may be included on a webpage2200for presentation to a requester. Such advertisements may vary in content such as advertisement for products or services, or as may be the case with a webpage containing search engine results, advertisements for products, services, or entities which may be relevant to the requester's search query. It will be appreciated by one having ordinary skill in the art that these are merely exemplary, and a wide variety of advertising content and relevance is possible in the art and may be used according to the invention. Optionally, one or more advertisements may have one or more embedded callback elements, which may optionally display an EWT2211or other information2212which may be relevant to a requester or callback request, or may have one or more fields2213for requester to enter additional information about their request. In this manner, a requester may submit a callback request that is immediately relevant and does not require they know or obtain contact information needed to place a request, allowing a greater convenience than traditional methods.