U.S. patent application number 09/183395 was filed with the patent office on 2001-11-22 for interface engine for managing business processes within a multimedia communication-center.
Invention is credited to BERKE, JONATHAN MICHAEL, JOHNSTONE, JOEL A., KNUFF, CHARLES DAZLER, MACLEOD BECK, CHRISTOPHER CLEMMETT, MITCHELL, ROBIN MARIE, POWERS, JAMES KARL, SIDELL, MARK FRANKLIN.
Application Number | 20010044676 09/183395 |
Document ID | / |
Family ID | 22672624 |
Filed Date | 2001-11-22 |
United States Patent
Application |
20010044676 |
Kind Code |
A1 |
MACLEOD BECK, CHRISTOPHER CLEMMETT
; et al. |
November 22, 2001 |
INTERFACE ENGINE FOR MANAGING BUSINESS PROCESSES WITHIN A
MULTIMEDIA COMMUNICATION-CENTER
Abstract
In an operating system (OS) for a multimedia communications
center (MMCC), an interactive process module (IPM) for
accomplishing a process has a plurality of code sets, each adapted
to completion of a specific task in the overall process, an input
interface for providing one or more inputs to the IPM, and an
output function for returning a result. The plurality of code sets
are related by pre-requisite status, creating a required order of
progression for the process, the process is initiated after being
called by the OS and receiving required inputs, the IPM is adapted
to interface with other OS modules for accessing and providing
data, and upon completion of the last task the IPM returns the
result. In one embodiment the IPM is represented by an interactive
GANT chart. In a preferred embodiment a tool kit is provided for a
programmer to create such IPMs to perform business processes. IPMs
thus created may be displayed and edited as object models.
Inventors: |
MACLEOD BECK, CHRISTOPHER
CLEMMETT; (OCEANSIDE, CA) ; BERKE, JONATHAN
MICHAEL; (SAN DIEGO, CA) ; JOHNSTONE, JOEL A.;
(SAN DIEGO, CA) ; MITCHELL, ROBIN MARIE; (CARDIFF,
CA) ; POWERS, JAMES KARL; (CARLSBAD, CA) ;
SIDELL, MARK FRANKLIN; (CHAPEL HILL, NC) ; KNUFF,
CHARLES DAZLER; (CARLSBAD, CA) |
Correspondence
Address: |
CENTRAL COAST PATENT AGENCY
PO BOX 187
AROMAS
CA
95004
US
|
Family ID: |
22672624 |
Appl. No.: |
09/183395 |
Filed: |
October 29, 1998 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
09183395 |
Oct 29, 1998 |
|
|
|
09151429 |
Sep 11, 1998 |
|
|
|
6230197 |
|
|
|
|
Current U.S.
Class: |
701/1 ;
707/E17.009 |
Current CPC
Class: |
H04M 3/5183 20130101;
H04L 65/1043 20130101; H04M 2201/38 20130101; H04L 69/329 20130101;
H04M 3/5191 20130101; G06Q 30/06 20130101; H04L 65/1036 20130101;
H04L 65/104 20130101; H04M 3/5166 20130101; H04M 3/5175 20130101;
H04L 67/00 20130101; H04M 2203/404 20130101; G06F 9/45512 20130101;
H04L 65/1101 20220501; H04L 9/40 20220501; G06F 16/40 20190101;
G06Q 10/06316 20130101; H04L 65/103 20130101; H04L 65/401 20220501;
G06Q 10/06 20130101; H04M 3/42221 20130101; H04M 2201/60 20130101;
H04M 3/5231 20130101; H04M 3/2218 20130101; H04L 65/1026 20130101;
H04L 65/1069 20130101; H04L 67/75 20220501; G06Q 10/0631 20130101;
H04M 2201/42 20130101 |
Class at
Publication: |
701/1 |
International
Class: |
G06F 017/00 |
Claims
What is claimed is:
1. In an operating system (OS) for a multimedia communications
center (MMCC), an interactive process module (IPM) for
accomplishing a process, comprising: a plurality of code sets, each
adapted to completion of a specific task in the overall process; an
input interface for providing one or more inputs to the IPM; and an
output function for returning a result; wherein the plurality of
code sets are related by pre-requisite status, creating a required
order of progression for the process, the process is initiated
after being called by the OS and receiving required inputs, the IPM
is adapted to interface with other OS modules for accessing and
providing data, and upon completion of the last task the IPM
returns the result.
2. The IPM of claim 1 wherein task structure and parameters are
presentable in a graphical interface displaying tasks making up the
IPM in prerequisite order.
3. The IPM of claim 2 wherein the graphical interface is a GANT
chart.
4. The IPM of claim 2 wherein the graphical interface is
interactive, allowing a programmer to add, delete, and edit steps
in the process.
5. The IPM of claim 2 wherein start and finish times are displayed
for each task.
6. The IPM of claim 1 wherein, in performing any one task, next
activity is variable, and is determined by performance to
requirements programmed with the task.
7. The IPM of claim 6 wherein the task requirements include
completion within a preprogrammed allotted time.
8. The IPM of claim 7 wherein next activity includes a choice of
stopping the process and notifying a person in the event of
non-completion of a task in an allotted time.
9. The IPM of claim 7 wherein one or more tasks require human
intervention and activity, and comprising an activity of reminding
a person responsible for an activity of a pending time
deadline.
10. An operating system (OS) for a multimedia call center (MMCC)
comprising one or more interactive process modules (IPMs) for
accomplishing individual processes, each IPM comprising: a
plurality of code sets, each adapted to completion of a specific
task in the overall process; an input interface for providing one
or more inputs to the IPM; and an output function for returning a
result; wherein the plurality of code sets are related by
pre-requisite status, creating a required order of progression for
the process, the process is initiated after being called by the OS
and receiving required inputs, the IPM is adapted to interface with
other OS modules for accessing and providing data, and upon
completion of the last task the IPM returns the result.
11. The OS of claim 10 wherein task structure and parameters are
presentable in a graphical interface displaying tasks making up the
IPM in prerequisite order.
12. The OS of claim 11 wherein the graphical interface is a GANT
chart.
13. The OS of claim 11 wherein the graphical interface is
interactive, allowing a programmer to add, delete, and edit steps
in the process.
14. The OS of claim 11 wherein start and finish times are displayed
for each task.
15. The OS of claim 10 wherein, in performing any one task, next
activity is variable, and is determined by performance to
requirements programmed with the task.
16. The OS of claim 15 wherein the task requirements include
completion within a preprogrammed allotted time.
17. The OS of claim 16 wherein next activity includes a choice of
stopping the process and notifying a person in the event of
non-completion of a task in an allotted time.
18. The OS of claim 16 wherein one or more tasks require human
intervention and activity, and comprising an activity of reminding
a person responsible for an activity of a pending time
deadline.
19. An object-oriented programming tool for use by a programmer in
constructing an Interactive Process Module adapted for use with an
operating system (OS) in a multimedia call center (MMCC),
comprising: a graphical interface comprising an input facility
adapted for defining a task, definition including a task
identifier, a task description comprising activities performable by
the operating system, and prerequisite relationship to any other
tasks; a set of one or more inputs definable by the programmer; and
one or more outputs; wherein entry of tasks with parameters by a
programmer sequentially builds a process comprising multiple tasks
to be performed in a requisite order dictated by the prerequisite
relationship.
20. The programming tool of claim 19 wherein the result of a
programmed IPM is a GANT chart.
Description
FIELD OF THE INVENTION
[0001] The present invention is in the field of telecommunication
encompassing all existing sorts of interaction multimedia
technology, and pertains more particularly to methods and apparatus
for managing defined business processes within a multimedia
communication-center operating a
customer-interaction-network-operating-system (CINOS).
CROSS-REFERENCE TO RELATED DOCUMENTS
[0002] The present application is a continuation-in-part (CIP)of
copending application P3317PA, which is a CIP of copending
application P3316PA, P3315PA, P3314PA, and P3313PA, all of which
are incorporated herein in their entirety by reference.
BACKGROUND OF THE INVENTION
[0003] In the field of telephony communication, there have been
many 25 improvements in technology over the years that have
contributed to more efficient use of telephone communication within
hosted call-center environments. Most of these improvements involve
integrating the telephones and switching systems in such call
centers with computer hardware and software adapted for, among
other things, better routing of telephone calls, faster delivery of
telephone calls and associated information, and improved service
with regard to client satisfaction. Such computer-enhanced
telephony is known in the art as computer-telephony integration
(CTI).
[0004] Generally speaking, CTI implementations of various design
and purpose are implemented both within individual call-centers
and, in some cases, at the telephone network level. For example,
processors running CTI software applications may be linked to
telephone switches, service control points (SCPs), and network
entry points within a public or private telephone network. At the
call-center level, CTI-enhanced processors, data servers,
transaction servers, and the like, are linked to telephone switches
and, in some cases, to similar CTI hardware at the network level,
often by a dedicated digital link. CTI processors and other
hardware within a call-center is commonly referred to as customer
premises equipment (CPE). It is the CTI processor and application
software is such centers that provides computer enhancement to a
call center.
[0005] In a CTI-enhanced call center, telephones at agent stations
are connected to a central telephony switching apparatus, such as
an automatic call distributor (ACD) switch or a private branch
exchange (PBX). The agent stations may also be equipped with
computer terminals such as personal computer/video display unit's
(PC/VDU's) so that agents manning such stations may have access to
stored data as well as being linked to incoming callers by
telephone equipment. Such stations may be interconnected through
the PC/VDUs by a local area network (LAN). One or more data or
transaction servers may also be connected to the LAN that
interconnects agent stations. The LAN is, in turn, typically
connected to the CTI processor, which is connected to the call
switching apparatus of the call center.
[0006] When a call arrives at a call center, whether or not the
call has been pre-processed at an SCP, typically at least the
telephone number of the calling line is made available to the
receiving switch at the call center by the network provider. This
service is available by most networks as caller-ID information in
one of several formats such as Automatic Number Identification
(ANI). Typically the number called is also available through a
service such as Dialed Number Identification Service (DNIS). If the
call center is computer-enhanced (CTI), the phone number of the
calling party may be used as a key to access additional information
from a customer information system (CIS) database at a server on
the network that connects the agent workstations. In this manner
information pertinent to a call may be provided to an agent, often
as a screen pop on the agent's PC/VDU.
[0007] In recent years, advances in computer technology, telephony
equipment, and infrastructure have provided many opportunities for
improving telephone service in publicly-switched and private
telephone intelligent networks. Similarly, development of a
separate information and data network known as the Internet,
together with advances in computer hardware and software have led
to a new multimedia telephone system known in the art by several
names. In this new systemology, telephone calls are simulated by
multimedia computer equipment, and data, such as audio data, is
transmitted over data networks as data packets. In this system the
broad term used to describe such computer-simulated telephony is
Data Network Telephony (DNT).
[0008] For purposes of nomenclature and definition, the inventors
wish to distinguish clearly between what might be called
conventional telephony, which is the telephone service enjoyed by
nearly all citizens through local telephone companies and several
long-distance telephone network providers, and what has been
described herein as computer-simulated telephony or data-network
telephony. The conventional systems are referred to herein as
Connection-Oriented Switched-Telephony (COST) systems, CTI enhanced
or not.
[0009] The computer-simulated, or DNT systems are familiar to those
who use and understand computers and data-network systems. Perhaps
the best example of DNT is telephone service provided over the
Internet, which will be referred to herein as Internet Protocol
Network Telephony (IPNT), by far the most extensive, but still a
subset of DNT.
[0010] Both systems use signals transmitted over network links. In
fact, connection to data networks for DNT such as IPNT is typically
accomplished over local telephone lines, used to reach points in
the network such as an Internet Service Provider (ISP). The
definitive difference is that COST telephony may be considered to
be connection-oriented telephony. In the COST system, calls are
placed and connected by a specific dedicated path, and the
connection path is maintained over the time of the call. Bandwidth
is basically assured. Other calls and data do not share a connected
channel path in a COST system. A DNT system, on the other hand, is
not dedicated or connection-oriented. That is, data, including
audio data, is prepared, sent, and received as data packets over a
data-network. The data packets share network links, and may travel
by varied and variable paths.
[0011] Recent improvements to available technologies associated
with the transmission and reception of data packets during
real-time DNT communication have enabled companies to successfully
add DNT, principally IPNT, capabilities to existing CTI call
centers. Such improvements, as described herein and known to the
inventor, include methods for guaranteeing available bandwidth or
quality of service (QoS) for a transaction, improved mechanisms for
organizing, coding, compressing, and carrying data more efficiently
using less bandwidth, and methods and apparatus for intelligently
replacing lost data via using voice supplementation methods and
enhanced buffering capabilities.
[0012] In addition to Internet protocol (IPNT) calls, a DNT center
may also share other forms of media with customers accessing the
system through their computers. E-mails, Video mails, fax, file
share, file transfer, video calls, and so forth are some of the
other forms of media which may be used. This capability of handling
varied media leads to the term multimedia communications center. A
multimedia communications center may be a combination CTI and DNT
center, or may be a DNT center capable of receiving COST calls and
converting them to a digital DNT format. The term communication
center will replace the term call center hereinafter in this
specification when referring to multimedia capabilities.
[0013] In typical communication centers, DNT is accomplished by
Internet connection and IPNT calls. For this reason, IPNT and the
Internet will be used in examples to follow. IT should be
understood, however, that this usage is exemplary, and not
limiting.
[0014] In systems known to the inventors, incoming IPNT calls are
processed and routed within an IPNT-capable communication center in
much the same way as COST calls are routed in a CTI-enhanced
call-center, using similar or identical routing rules, waiting
queues, and so on, aside from the fact that there are two separate
networks involved. Communication centers having both CTI and IPNT
capability utilize LAN-connected agent-stations with each station
having a telephony-switch-connected headset or phone, and a PC
connected, in most cases via LAN, to the network carrying the IPNT
calls. Therefore, in most cases, IPNT calls are routed to the
agent's PC while conventional telephony calls are routed to the
agent's conventional telephone or headset. Typically separate lines
and equipment must be implemented for each type of call weather
COST or IPNT.
[0015] Due in part to added costs associated with additional
equipment, lines, and data ports that are needed to add IPNT
capability to a CTI-enhanced call-center, companies are currently
experimenting with various forms of integration between the older
COST system and the newer IPNT system. For example, by enhancing
data servers, interactive voice response units (IVR's),
agent-connecting networks, and so on, with the capability of
conforming to Internet protocol, call data arriving from either
network may be integrated requiring less equipment and lines to
facilitate processing, storage, and transfer of data.
[0016] With many new communication products supporting various
media types available to businesses and customers, a communication
center must add significant application software to accommodate the
diversity. For example, e-mail programs have differing parameters
than do IP applications. IP applications are different regarding
protocol than COST calls, and so on. Separate routing systems
and/or software components are needed for routing e-mails, IP
calls, COST calls, file sharing, etc. Agents must then be trained
in the use of a variety of applications supporting the different
types of media.
[0017] Keeping contact histories, reporting statistics, creating
routing rules and the like becomes more complex as newer types of
media are added to communication center capability. Additional
hardware implementations such as servers, processors, etc. are
generally required to aid full multimedia communication and
reporting. Therefore, it is desirable that interactions of all
multimedia sorts be analyzed, recorded, and routed according to
enterprise (business) rules in a manner that provides seamless
integration between media types and application types, thereby
allowing agents to respond intelligently and efficiently to
customer queries and problems.
[0018] Still another goal of multimedia communication centers is to
maintain a certain flexibility with regard to defined business
processes that may be used or in effect within the communication
center. For example, enterprise procedure must be executed in a
timely fashion and in logical order especially where live
interactions hang in the balance. A client who patronizes a
multimedia communication center does not wish to be inconvenienced
by a long wait while a business procedure relating to his call is
being executed within the system.
[0019] Business procedures, as described above, include and
encompass any ordered processes that may be required before a
conclusion may be reached regarding an issue or request. An example
of a standard business procedure may be a process for qualifying a
client for a loan. A business procedure as such may be broken down
into ordered steps and sub-steps. For example, an automated
business application designed to qualify or not a requesting client
may begin with the step of client identification and data
acquisition. Sub-steps involved in client data acquisition may
include 1) obtaining last credit report, 2) obtaining past credit
history with the enterprise, 3) obtaining current income and asset
information, and so on.
[0020] An issue with which to contend regarding current art
communication centers is the fact that human intervention is
required when performing more complicated business processes such
as the one described above. For example, an operator or agent may
be required to manually type in access to certain databases via
keyboard. Obtained information must be processed, in many
instances, via manual calculation such as calculating income to
debt ratio (in the case of a loan process) and so on. Because of
such human involvement in one or more stages in a typical process,
the propensity for error is high. Also, such interference consumes
time both valuable to the enterprise and to the client. Beyond
that, if someone "drops the ball", the transaction may not be
closed in time, and it maybe difficult if not impossible to find in
time at which manual step the issue was dropped.
[0021] What is clearly needed is an ability in a multimedia
communication center for creating interactive process modules,
interactive with other communication center processes, that can be
called to quickly perform particular defined processes according to
enterprise needs in a timely and s orderly fashion wherein human
intervention may be excluded or greatly reduced.
SUMMARY OF THE INVENTION
[0022] In a preferred embodiment of the present invention, in an
operating system (OS) for a multimedia communications center
(MMCC), an interactive process module (IPM) for accomplishing a
process is provided, comprising a plurality of code sets, each
adapted to completion of a specific task in the overall process; an
input interface for providing one or more inputs to the IPM; and an
output function for returning a result. The plurality of code sets
are related by pre-requisite status, creating a required order of
progression for the process, the process is initiated after being
called by the OS and receiving required inputs, the IPM is adapted
to interface with other OS modules for accessing and providing
data, and upon completion of the last task the IPM returns the
result.
[0023] In a preferred embodiment task structure and parameters are
presentable in a graphical interface displaying tasks making up the
IPM in prerequisite order. The graphical interface may be a GANT
chart. Preferably the graphical interface is interactive, allowing
a programmer to add, delete, and edit steps in the process.
[0024] In some cases start and finish times are displayed for each
task. Also in some cases, in performing any one task, next activity
is variable, and is determined by performance to requirements
programmed with the task. Task requirements may include completion
within a preprogrammed allotted time. Next activity may include a
choice of stopping the process and notifying a person in the event
of non-completion of a task in an allotted time.
[0025] In some cases one or more tasks require human intervention
and activity, and there may be a selective activity of reminding a
person responsible for an activity of a pending time deadline.
[0026] In another aspect of the invention an operating system for a
multimedia call center is provided, including IPMs of the type and
structure described in general above. Further, a tool kit for a
programmer provides an interactive object-oriented interface
adapted for building IPMs of the sort described.
[0027] The invention in its various embodiments, taught in enabling
detail below, provides a facility for adapting an operating system
for a multimedia call center to specific business practices and
rules for a host enterprise within a broad set of possibilities,
wherein business procedures, such as logical and calculation
intensive procedures, may be accomplished more or less
automatically with little if any human intervention.
BRIEF DESCRIPTION OF THE DRAWING FIGURES
[0028] FIG. 1 is a diagram of a multimedia communications center
enhanced with a network operating system according to an embodiment
of the present invention.
[0029] FIG. 2 is a block diagram illustrating basic layers of a
customer interaction operating system according to an embodiment of
the present invention.
[0030] FIG. 3 is a flow chart illustrating basic steps performed by
the network operating system of FIG. 2 related to completing
interactive transactions between business partners.
[0031] FIG. 4 is a block diagram illustrating agent-desktop
function according to an embodiment of the present invention.
[0032] FIG. 5 is a block diagram of an exemplary WEB-form customer
interface according to an embodiment of the present invention.
[0033] FIG. 6 is a flow chart illustrating media-presentation and
customer-interface logic steps according to an embodiment of the
present invention.
[0034] FIG. 7 is an exemplary overview of a multimedia interaction
storage system within a communication center according to an
embodiment of the present invention.
[0035] FIG. 8 is a block diagram of the repository of FIG. 7
illustrating threaded text-blocks and their relationship to stored
multimedia according to an embodiment of the present invention.
[0036] FIG. 9 is a process flow chart illustrating logical steps
taken when building a threaded multimedia contact-history of
communication-center interactions according to an embodiment of the
present invention.
[0037] FIG. 10 is a block diagram illustrating an interactive
multimedia application (IMA) tool kit and a created application
according to an embodiment of the present invention.
[0038] FIG. 11 is a process flowchart illustrating logical steps
for building an IMA for a user interacting with CINOS according to
an embodiment of the present invention.
[0039] FIG. 12 is a block diagram illustrating the relationship
between a mass repository, an interaction object model (IOM
interface), and data-interaction systems according to an embodiment
of the present invention.
[0040] FIG. 13 is an exemplary flow chart illustrating interactive
steps associated with IOM functionality according to an embodiment
of the present invention.
[0041] FIG. 14 is a Gant table illustrating a pre-defined business
process according to an embodiment of the present invention.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0042] FIG. 1 is a multimedia communications center enhanced with a
network operating system according to an embodiment of the present
invention. A telephony-network architecture 11 comprises an
enterprise-hosted communication center 17 that is linked to, in
this example, both a publicly-switched telephone network (PSTN) 13,
and a wide area network (WAN) 15, which may be the public Internet
or other digital network, such as a company Intranet.
[0043] In this particular embodiment communication center 17
handles both conventional telephone calls, which may be categorized
as connection oriented switched telephony (COST) calls, and data
network telephony (DNT) calls, which may be DNT calls over a
private digital network or calls according to a protocol such as
the well-known Internet protocol. DNT calls are characterized in
that data is transmitted as addressed data packets as opposed to
dedicated connections in COST calls. As indicated, PSTN 13 may be a
private rather than a public network. WAN 15 may be a company
Intranet, the Internet, or another type of WAN known in the art.
The particular method of call delivery and call center integration
is not particularly relevant for the purposes of this invention.
There are many ways known both to the inventor as well as known in
the art. Particular issues discussed in the disclosure between the
telephones and the computers might be implemented differently
depending on the actual system, but shall be deemed equivalent for
all purposes of this invention.
[0044] Incoming COST calls arrive at a network-level telephony
switching apparatus 19 in network cloud 13 and are connected over
trunk 23 to a central telephony switching apparatus 27 within
communication center 17. From switching apparatus 27, calls are
routed according to existing routing rules over internal wiring 56
to agents' telephones 47, 49, 51, and 53 residing at agents'
workstations 31, 33, 35, and 37 respectively.
[0045] Incoming DNT calls, and other communication events such as
e-mail, file transfers and the like, arrive at a routing node 21 in
WAN 15 and are passed on over digital connection 25 to a routing
server 29 within communication center 17. Once calls arrive at
server 29, they may, in some embodiments, be routed directly over
LAN 55 according to existing routing rules to personal
computer/video display units (PC/VDU) such as PC/VDU 39, 41, 43, or
45 located at agent's workstations 31, 33, 35, and 37
respectively.
[0046] In this embodiment, switch-connected telephones 47-53 are
also connected to PC/VDU's 39-45 via a headset to computer
sound-card according to technique known to the inventor and
accomplished via an I/O cable. Thus connected, agents may respond
to incoming COST and DNT calls with the same headset.
[0047] In the exemplary system and communication center shown, the
equipment and applications are adapted to provide for multimedia
operation at each of the agent stations, so the agents can interact
with clients in many different ways, as are known in the multimedia
arts.
[0048] Computer telephony integration (CTI) enhancement is, in this
embodiment, provided both at communication center 17 and in PSTN
13. For example, in PSTN 13, a processor 61 running instances of a
CTI application known as a T-server (TS) to the inventors, and a
statistics server (Stat) is connected to telephony switch 19 via
CTI link 65. An intelligent peripheral 59 of the form of an
interactive voice response unit (IVR) is connected to processor 61
via data connection 63. Similar CTI equipment is illustrated within
communication center 17. Namely, a processor 67 running instances
of TS and Stat and connected to telephony switch 27 via CTI link
71, and an IVR 69 connected to processor 67 via a data connection
73, with processor 67 further connected to a local area network
(LAN) 55 within communication center 17.
[0049] In alternative embodiments there may also be a CTI processor
22 in WAN 15 connected to server 21 by a CTI link 24. Also in some
embodiments a separate data network 66 connects these CTI
processors. In this way, intelligent routing may be performed at
the network level with negotiation and direction from within
communication center 17.
[0050] It will be appreciated by those with skill in the art that
the CTI enhancements, as immediately described above, may be hosted
on one processor at PSTN 13 and on one processor at communication
center 17 without departing from the spirit and scope of the
present invention. The inventor has chosen to show separate
processors having separate functions for exemplary purposes only.
It will also be appreciated by the skilled artisan that there may
be many more or fewer than the four agent stations shown in
communications center 17, and hardware and software arrangements
may be made is a variety of ways. Also, home agents might be
connected in a variety of ways to the call center.
[0051] In a preferred embodiment of the present invention, a
customer-interaction network operating system, hereinafter termed
(CINOS), is provided for the purpose of managing communications
center 17, and optimizing and recording all agent/customer
interactions received at communication center 17 from networks 13
and 15. CINOS is unique in the fact that it is a multi-tiered
object-and process-orientated system wherein logic regarding the
various aspects of it's functionality is achieved via
knowledge-based architecture and object modeling. Various functions
of CINOS, more fully described below, include capturing
(recording), analyzing, routing, and, in many instances, responding
via automated process to customers engaged in interactions with the
enterprise (company hosting the communication center). CINOS is
adapted to support all planned communication mediums such as
multimedia DNT applications including e-mail, video mail, file
transfers, chat sessions, IP calls, and CTI COST transactions such
as voice calls, voice mails, faxes, and so on.
[0052] Referring back to FIG. 1, CINOS utilizes various
LAN-connected machines in order to perform various operations.
Among these various hardware implementations are a multimedia
server (MIS) 79 adapted to physically store and serve all
multimedia transactions, and a customer-information-system server
(CIS) 57 adapted to physically store and serve information relevant
to customers such as purchase history, financial status, product
preferences, contact information, etc. A central server (COS) 77
acts as a host location for a CINOS manager application (noted in
text balloon) which is, in effect, the parent application that
controls all of the operation and functionality of the system.
[0053] In addition to the above-mentioned machines hosting CINOS
routines, each PC/VDU such as PC/VDU 39, for example, has a
CINOS-agent desktop interface or client application (not shown)
adapted to interact with the parent application. Also, each machine
that provides particular dedicated function to communication center
17 such as switch-connected CTI processors, IVR's, and other
related equipment host instances of CINOS application-program
interfaces (API's) to enable seamless integration of differing
parameters and/or protocols that are used with various planned
application and media types utilized within communication center
17. Such programs may also co-reside or be in any combination or
hosted by themselves. Additionally, for performance purposes,
additional dedicated network links may exist between those servers,
but essentially they are only performance boosters, and hence for
clarity purposes, only a simple network is shown.
[0054] As previously described, CINOS comprises a multi-tiered
architecture. This unique architecture comprises an external media
layer for interfacing with the customer or business contact, a
workflow layer for making routing decisions, organizing automated
responses, recording transactions, and so on, and an internal media
later for interfacing and presenting interactions to an agent or
knowledge worker. An innovative concept associated with CINOS
involves the use of tooled process models, knowledge bases, and
other object models as base instruction for it's various functions.
These modular conventions may be inter-bound with each other, and
are easily editable providing a customizable framework that may
conform to virtually any existing business logic.
[0055] In simple operation, and after any network level routing,
COST calls and DNT calls including other media events arrive at
communication center 17 to telephony switch 27, and routing server
29 respectively. Network level routing, as defined herein, includes
any intelligent implementation that may be in place and aided via
processors 59, 61, and 22. Load balancing to multiple communication
centers, and transferring customer data obtained at network-level
over data-network connection 66 would be examples of such
network-level routing.
[0056] Once a call or other communication event registers at either
switch 27 or routing server 29, CINOS immediately identifies the
media type associated with the call and begins it's processes
depending on enterprise rules. For example, a live COST call may
first be routed to IVR 69 whereby the customer can be presented
with varying choices such as leaving a voice message, waiting in
queue, receiving a call back, or perhaps an e-mail, and so on.
Interaction by IVR 69, in this instance, will preferably be via
voice recognition technique such as is known in the art, but may
also be via touch tone response or other known method. As
previously described, the caller may elect from a number of
options, such as to hold for a next available agent, select an
automated response such as a fax back, or perhaps a later
agent-initiated response such as an e-mail or call back. In all
cases, CINOS seamlessly processes and executes the logic required
to accomplish the goal of the caller in a media and
application-independent fashion.
[0057] DNT events are handled much the same way as described above
for live callers. For example, an IP call may be routed to a
digital equivalent of an IVR for interaction or queued for a next
available agent, and so on. In one embodiment, IVR 69 may be
adapted to handle both COST and DNT interaction.
[0058] All interactions with live external media, including actual
text-based events whether live or not, are recorded and stored in
MIS 79 with an associated text version of the media stored as well,
and becoming part of an overall threaded contact history. This is
accomplished in varying ways according to existing parameters such
as media type, whether the event is a live call, and so on. For
example, CINOS may execute a command directing IVR 69 to digitally
record an incoming COST call during customer interaction and then
store the voice recording of the transaction in MIS 79. A text
version of the recording either created simultaneously from the
voice recording via voice-to-text techniques (known in the art), or
created by a live attendant via manual annotation may be sent to
and stored in DB 79. An IPNT call arriving at routing server 29 may
be similarly recorded and stored in MIS 79 with an associated text
version of the interaction stored in DB 79. E-mails, video calls,
voice mails and so on are similarly handled. For example, an
incoming e-mail is stored in MIS server 79 while text from the
e-mail may be extracted and stored associated with the e-mail.
[0059] The purpose of the text version of the event is twofold.
Firstly, a complete text-based transaction history of communication
center 17 may be compiled and reserved for later access and audit.
Secondly, an agent or knowledge worker may, in some instances, see
the text version of the event at the same time that he receives
routed notification of the event. In this way, an agent may begin
mental preparation before taking a call. The text version of an
event must be machine-readable and human readable at times
displayed. Interactive media-independent viewers, part of the
agent's client application, may be used to disseminate information
which may initially not be human readable.
[0060] It is important to note here that the text-based version of
an event may or may not be a complete and verbatim rendition of an
actual media event. For example, an e-mail may contain many
documents each having many pages of text. Therefore, the text-based
version of a particular e-mail event may simply contain the name
and particulars regarding the author, a purchase order, and a list
of the enclosed documents by title, and basic content or memo as
well as a possible manual annotation. The attachments to the e-mail
may be stored separately, and be also cross-indexed and
retrievable. Seeing the purchase order when the event is routed to
an agent desktop tells the agent that this e-mail is important.
[0061] A fax, stored originally as a bit-mapped document, may be
converted to text in the system via optical recognition (OCR)
technique wherein sometimes only certain content such as the
authors contact information, basic intent of the fax, and perhaps
special numbers or codes contained in the original fax are recorded
in a text version 79, sometimes the whole text is OCR'd, while the
original fax is stored in it's entirety in DB 79. Such codes or
numbers that are specifically parsed from actual media may be part
of a unique coding system set up by the enterprise whereby
customers are directed to include such codes or numbers with their
orders, service requests, and so on.
[0062] Parsing text messages is accomplished via a text-analyzer
known to the inventor. In other non-text media types, such as video
or graphics, descriptive notes may be taken via live attendant and
stored in DB 79 as previously mentioned. Voice recognition
technology may also be used in a case of recorded sound or video
with sound. All transactions regardless of media type are thus
recorded and stored according to enterprise rules with at least a
meaningful part of the content if not all of the content of such
transactions converted to text and stored in DB 79 associated with
the recording of the event. Again, the importance of the text
version is that the extracted knowledge of the transaction therein
is in machine-operable code, allowing search and cross-referencing
functions that may otherwise not be possible.
[0063] After incoming events are analyzed and processed with
regards to queuing, recording, storing, etc. CINOS decides the
disposition paths of each event. For example, live calls in queue
are routed to live agents if available, if this is the priority
action in the enterprise rules. E-mails are either routed to next
available agents using a push technology, or simply stored in MIS
server 79 where they may be retrieved by agents after receiving
notification. Recorded events such as IVR voice requests are stored
in MIS server 79 where they may be retrieved by agents, and so
on.
[0064] By the use of routing and routing notification events, any
media may be routed to an appropriate agent based on skill, or any
other rule-based routing method over LAN 55. Actual multimedia
events may be accessed from MIS server 79 at the agent's
discretion, or by rule, and text-based versions of those events
stored in DB 79 may be mirrored and routed to the agent along with
notification of the incoming event.
[0065] Other services may be performed by CINOS such as responding
to media requests without agent participation via initiating
automated fax responses, out-bound dialing campaigns wherein
recorded information is given to a customer perhaps concerning an
order placed by the customer, and so on. Networking via business or
chat applications between several business partners, customers,
agents, and so on, is possible wherein each entry may be stored in
DB 79 as part of a discussion thread including responses of another
media type, perhaps initiated by a communication-center agent to
one of the participants during the discussion.
[0066] As a general rule, full multimedia storage is done in a mass
storage server, and linked by cross-indexing to the database.
Depending on the business model, full text or only partial
annotation is stored in the database, or a mix therof, e.g by media
type.
[0067] In addition to supporting a wide variety of applications and
protocol, CINOS is provided with the tools for building
media-independent self-help wizards that are adapted for problem
solving and reduction. Similarly, external and internal interaction
media viewers are provided and adapted to support any media of
choice.
[0068] CINOS uses object modeling and linking techniques that are
known in the art to effect much of it's goal of presenting a
seamless customer interaction with an enterprise agent or knowledge
worker operating in a communication center such as center 17. For
example, an interaction object model (IOM) represents a transcript
of all interaction history stored in DB 79 and provides an audit
trail of the state of transactions of all interactions. An
interaction process model (IPM) controls how events are handled
within the operating system.
[0069] An additional set of models handle how agents receive their
routed media such as via traditional push model, blended push
model, publish and subscribe model, or interrupt model.
Prioritizing interaction events may also be accomplished through
varying the push theme or scheme. For example, traditional push
technology for e-mail means that only e-mail (media type) is being
worked on by an agent. By blending the push model with a publish
and subscribe model, the interrupt model is created wherein the
agent may subscribe to various routed media such as answering
phones, and responding to faxes, but may be interrupted for an
important interaction of another media type such as e-mail and so
on. In this way an agent's time may be utilized according to
enterprise rules within an automated environment.
[0070] Outbound campaigns may be configured according to enterprise
rules and media preference using a single rule-set knowledge-base.
This single set of outbound tools can be used to initiate customer
dialog via predictive dialing, e-mail push, automated recorded
messages, and so on.
[0071] It will be apparent to those with skill in the art that
common object modeling (COM) can be used to create virtually any
type of model for any type of enterprise situation. It is the
intention of the inventor to provide the applicable control codes
known in the art for building process and object models and
enabling the linking and interaction between the models. As
previously described, it is partly the fact that CINOS uses these
various models and knowledge bases to achieve desired interaction
that sets it above current-art systems. The inventor knows of no
such network interfacing operating system that is based on the
above described technology.
[0072] CINOS may be implemented in a number of different
topologies. For example, CINOS may be implemented as a centralized
topology with one communication center as shown here in FIG. 1, a
distributed topology wherein a single communication center may span
multiple physical locations, a segmented communication center
wherein a single pool of agents services more than one company or
customer base, or a wide communication network wherein a plurality
of communication centers such as center 17 cooperatively service a
common pool of customers or a customer base. Enterprises involved
in commerce such as large financial institutions hosting many
geographically separate communication centers may build their
entire networking system using CINOS architecture in standardized
and distributed fashion. There is no limitation to the type of
enterprise that may use CINOS as it may be tooled to accommodate
virtually any network architecture linked to a communication center
having DNT capability.
[0073] It will also be apparent to one with skill in the art that
CINOS routines according to various embodiments of the present
invention may be included and implemented at the network level
without departing from the spirit and scope of the present
invention such as in processor 61, and IVR 59 in PSTN 13, or in
routing node 21 in WAN 11.
[0074] FIG. 2 is a block diagram illustrating basic layers of the
network operating system according to an embodiment of the present
invention. As previously described with reference to FIG. 1, CINOS
comprises three basic operating layers. They are an external media
layer 83, a workflow layer 85, and an internal media layer 87.
External media layer 83 interfaces directly with the customers or
business contacts or partners as illustrated via customers a and b,
and business contact c. The bi-directional arrows beneath each of
the above mentioned participants illustrate interactive
participation with CINOS on the customer side.
[0075] External media layer 83 may, in one embodiment, be a
multifaceted, web-based self-help interface providing news
information and a host of other services that may be personalized
by the customer. In many respects, external media layer 83 in this
embodiment is similar to a web browser.
[0076] Workflow layer 85 comprises 3 basic function categories
beginning with a content analysis category 89 wherein textual
analysis, voice analysis, IVR interaction, recording and storing
takes place. A next category is context resolution 91. Context
resolution involves customer identification, business process
binding, preparation for routing, and so on. A third category
termed interaction routing 93 comprises various processes
associated with the presentation of the interaction to agents,
service persons, knowledge workers, business partners, customers
and the like, that is, all transaction partners. Category 93 covers
queuing, skill-based routing, automated treatment, workflow models,
and so on.
[0077] Internal media layer 87 comprises an agent desktop interface
not shown in FIG. 1, but described in more detail below. Both
external layer 83 and internal layer 87 contain the required tools
for enabling media and application-independent interfacing such as
previously mentioned self-help wizards, media viewers, and other
controls as prescribed via enterprise rules.
[0078] Internal media layer 87 provides an agent with, among other
options, information about the customer or contact, information
about current or historical business processes, information about
current interactions and their relationship to business processes,
and a knowledge-base to guide the agent or knowledge worker with
interaction response and workflow. An agent a, and agent b, and a
knowledge worker c are shown herein interacting with the system as
illustrated via bi-directional arrows. The skilled artisan will
recognize these are merely examples, and there may be many more
such persons, and interactions in some instances may be routed to
machines for response.
[0079] It will be apparent to one with skill in the art that the
multi-tiered architecture of CINOS such as is illustrated herein
may comprise many more or differing steps or processes without
departing from the spirit and scope of the present invention.
[0080] FIG. 3 is a flow chart illustrating basic steps performed by
the interaction operating system of FIG. 2 related to completing a
transaction between a customer and an agent, wherein the
transaction is initiated by the customer. Similar steps may be
accomplished in the opposite direction for communications initiated
by an agent, as the system is bi-directional, but the present
example will serve to teach the inventive aspects of the system. In
step 95, an incoming transaction, such as a live call, an e-mail,
etc., is received at the appropriate CTI switch (COST) or routing
server (DNT) in a CINOS communication center such as center 17. In
step 97, customer and media type are identified and interaction
proceeds.
[0081] All transactions, whether live calls, such as video calls,
DNT calls and COST calls, or text-based documents, such as e-mails,
are recorded and stored in one or more mass storage devices handled
by one or more database applications. This may be taken as server
79 of FIG. 1, although the diagram of FIG. 1 is exemplary.
[0082] A principle object of the invention is to extract maximum
information from every transaction for building a knowledge base
that can be used for dynamic management and future analysis and
development. This is done primarily by data mining, which is
applicable to machine-operable code, that is text. Because of the
nature of the extraction, there is a difference in the way live
calls and text-based media is handled.
[0083] Discrimination as to the text nature of the media is made at
step 99. If the media chosen by the customer is already text-based,
then the transaction is recorded as received (101), and a data
mining application extracts important information in step 103 and
stores it in the knowledge base. The distinct portions and versions
of the transaction, such as the originally recorded version and any
extracted data are related to one another and to other knowledge
previously stored, and become part of a threaded interaction
history associated with an ongoing interaction and ultimately of an
overall contact history.
[0084] If the media chosen by the customer is determined in step 99
to be a live interaction such as a COST or IPNT call, then the
existing knowledge base is accessed at step 107, and the call is
routed to the best fit agent. This may, of course, be done in a
number of ways, such as an ADC, skill-based routing as known to the
inventors, transfer to an IVR for automatic processing, and so on,
as may be dictated by enterprise rules. If routing is to an agent,
customer information may be retrieved from CIS server 57 (FIG. 1)
and sent to the agent's PC, and appropriate scripts may be provided
to guide an agent in interacting with the caller.
[0085] In step 109 the actual transaction is recorded as it takes
place, which, in the case of live calls, may be a video or an audio
recording or a combination of both. Preferably the recording is
digitized.
[0086] In step 111, a maximal text version is prepared from the
actual transaction. The ability to do so depends to a degree on the
sophistication of the system. This process may be as simple as a
person adding notes for annotation or as sophisticated as a
voice-to-text application preparing a full text version as the
transaction transpires.
[0087] In step 113 the text version is mined for data and resulting
knowledge is stored in the appropriate knowledge base for future
use, and added to overall record with appropriate
cross-referencing.
[0088] It will be apparent to one with skill in the art that there
will be many routines comprising various steps for performing
different processes as may be determined by enterprise rules which
may likewise vary depending on, among other considerations, company
type, product and or service type, communication center
architecture, whether or not the system architecture is centralized
or distributed, and so on. The embodiment taught herein is meant
only as a basic example of process functionality related to CINOS
processing of an incoming event.
[0089] FIG. 4 is a block diagram illustrating agent-desktop
function according to an embodiment of the present invention. An
agent-desktop client 115, part of the CINOS overall architecture,
enables an agent or knowledge worker to configure and control his
or her interface to the rest of the system and to external media.
Client 115 may be personalized according to a particular agents
parameters. A desktop interface 1 17 may appear and function much
like a personalized web-browser containing many similar attributes
related to network capabilities including full multimedia function,
software tool kits, linking and embedding capability, and so
on.
[0090] An HTML client application 119 oversees all of the network
capability previously mentioned. In this embodiment for example,
HTML client 119 communicates with an Internet information server
121 using HTTP protocol which is standard. Client 119, if provided
minimally, may be used in conjunction with an Internet browser for
full multimedia function. In some embodiments, it may be maximally
provided to be a fully featured client with full web browser
function. For example, an agent may create and edit web forms, web
pages, embed controls into such web-based forms or pages to provide
certain customer interaction mechanisms in addition to having a
fully functional navigation tool at his disposal.
[0091] In another embodiment, Server 121 may be a server on a
private network or corporate WAN instead of an Internet server. In
a preferred embodiment, however, any number of servers on the
Internet and/or linked to a WAN other than the Internet may
communicate with client 1 19 as it intended to support all existing
and known communication protocols.
[0092] A windows client 123 is provided to seamlessly integrate
existing applications on the agent's PC to network applications and
processes. This may be implemented via a desktop tool-kit 125 that
contains all of the required controls for building, integrating and
customizing the interface.
[0093] A business-logic layer comprises business object models 129,
hereinafter termed business objects 129, representing contacts,
interactions, knowledge-bases, events, routing processes, and other
system routines. Integration and interaction of the various
described desktop components with these logics is accomplished via
common object modeling (COM) which is known in the art and
available to the inventor. Desktop to CTI integration is
accomplished via controls provided or created with a CTI set of
tools or tool kit (not shown). For example, if the enterprise
desires to blend voice and e-mail, the CTI tool kit would be used
to build and integrate the interface.
[0094] Existing network applications such as CIS, enterprise
resource planning (ERP), Commerce, and the like interact with
various business objects using COM and may also interact with a
physical database using ODBC and SQL.
[0095] Customer Interface Media Window
[0096] According to a preferred embodiment of the present
invention, CINOS access by customers of an enhanced multimedia
communication center, such as center 17 of FIG. 1, is controlled by
means of a customer-facing media interface, by which customers may
be identified and even categorized according to numerous criteria.
In some cases access may be controlled through subscription, or
according to other qualifying criteria such as may be deemed
appropriate by the enterprise. For example, if the enterprise is an
exclusive investment club, membership may be required. Categorizing
criteria may include demographic information such as income level,
credit history, or any other attribute that may be quantified and
used to categorize a customer.
[0097] An enterprise-controlled access point may be defined as an
interfacing window or portal created and maintained at a typical
customer entry point in a network as may be known in the art. Such
interfaces may take the form of a WEB-based customer interface (a
WEB page), an interactive voice response (IVR) unit, a service
control point (SCP), or some other customer-facing system or
apparatus as may be known in the art.
[0098] For the purposes of this specification, an example of an
enterprise-controlled WEB-form access and interface window is
illustrated as an example for a preferred embodiment. The inventor
deems such an interface to be most adept in offering best-fit media
options while remaining accessible to a large customer or client
base.
[0099] FIG. 5 is a block diagram of a WEB-form customer interface
according to an embodiment of the present invention. WEB form 133,
hereinafter termed access window 133, is provided to be a part of
an enterprise's WEB page which may be accessed through Internet
connection and navigation, as is known in the art. Widow 133 is
part of the CINOS software architecture described above, and
represents the initiation of any customer interaction with the
hosting enterprise. A WEB counter 143 is provided and records the
number of visits to window 133.
[0100] Window 133 is built and edited using COM codes available to
the inventor and typically found in tool kits adapted for the
purpose of creating interactive displays on a WEB page. Such a tool
kit may be located on an agent's desktop, perhaps part of an
agent's HTML client such as client 119 of FIG. 4. In one
embodiment, it may be part of a system administrator's tool
kit.
[0101] Window 133 contains interactive options directed at various
categories and functions. For example, a new client section 135
contains interactive options related to adding a new client to the
active customer base of the enterprise. A customer service section
137 contains interactive options presented to existing clients
needing service. A new order section 139 contains interactive
options presented to existing clients wishing to do new
business.
[0102] Each offered interactive option is an embedded executable
function having the appropriate links to other system areas of
CINOS such as may be relevant to the immediate interaction such as
to services offered, routing routines, database searching,
interaction recording, and so on.
[0103] An innovative function of window 133 is to provide front-end
control of access to the enterprise by existing and potential
clients/customers. For example, as a client, contact, or potential
client interacts with the various media and functional options
presented by the enterprise in window 133, he or she is being
directed according to enterprise rules in such a way that he or she
may first be qualified or not to patronize the enterprise.
Secondly, the contacting person may be categorized and sorted as to
type of qualified customer. Thirdly, the person contacting person
may be directed to pre-selected media options by the enterprise for
various services offered including but not limited to routing live
interactions, and so on.
[0104] In a preferred embodiment of the present invention, access
window 133 is fully customizable, based on customer data and
enterprise rules with the focus of such customization directed
toward benefiting the enterprise and ultimately the client. That
is, the client's options within window 13 3 are pre-selected and
preferred by the hosting enterprise based in part on data about the
client, details about the client's communication equipment and
software, and enterprise rules and constraints. In some
embodiments, the client may aid in customizing window 133. However,
as it is desired by the enterprise to provide service in a
cost-effective manner, the client will be presented with options as
preferred by the enterprise in most cases.
[0105] To further illustrate, refer now to new client section 135.
If window 133 is part of the enterprise WEB page, as is the case
with this example, there will be a variety of visitors which may or
may not be pre-qualified by the enterprise. Therefore, an
interested party would begin (and be restricted to) taking a new
client survey, illustrated as one of the options in section 135. If
the enterprise rules require this as a first step, then the other
options may be enabled only upon completion of the survey. By
choosing new client survey, a second window may contain various
survey options such as via e-mail, interactive voice recording,
type and send method, or the like.
[0106] Information taken in the client survey is recorded and
entered into a CINOS database such as DB 75 of FIG. 1. Such
information may also be compared against enterprise rules or
constraints, and other known information as may be available to the
enterprise. Assuming the client is now recognized by the
enterprise, the client's media hardware and telephony information
may be recorded for future interaction purposes. Such information
may include the client's personal computer parameters including
modem type, Internet connection type, computer platform type, type
of Internet phone application installed, etc. Similarly, COST
telephone parameters may be recorded, such as personal phone
number, business phone number, cellular phone number, forwarding
numbers, and so on. Such data will influence latter customization
of his personal window 133 for the particular client including the
types of media that will be offered.
[0107] Finally, the client may be asked to create a password for
the purpose of accessing CINOS. A section 141 is provided
containing a network log-in option along with download sections for
obtaining permanent and or temporary software as may be desired or
needed, or, in some cases, required for the client to access
certain services, view certain content, and so on.
[0108] Section 137 presents media options for clients seeking
customer service from the enterprise. These options are, in a
preferred embodiment, presented in a customized or personalized
fashion within the client's window 133 as was described above.
Therefore, each client patronizing the enterprise may access a
version of window 133 that differs in look and functionality than
that of another client. In this example, service section 137
contains options for e-mail, chat program, fax program, a self-help
wizard, and a voice wizard. Other media types may be added or
subtracted from the client's window 133 depending on any of several
criteria. Personalization of widow 133 takes into account client
information as stored in CINOS database 75, service-agent media
availability and preferences, and perhaps any overriding enterprise
rules. Unless and until a client is identified there are typically
no options presented to the client for continuing a transaction
with the enterprise.
[0109] For an identified client, by selecting the e-mail option,
the client's preferred e-mail program may be activated for the
purpose of sending a message to or soliciting a reply from a
service agent. By selecting chat program, the client may be
launched into a scheduled service seminar featuring many clients
interacting with a service expert regarding a certain subject. One
enterprise rule regarding section 137 may be that there is no
telephone or I-phone media option for customer service for a client
in the absence of an ongoing project with the particular customer.
In this sense an ongoing project includes any unfinished business
that the client is involved in with the enterprise.
[0110] Self-help wizards and voice wizards as illustrated in
section 137 may be offered to help a client resolve an issue
without taxing further resource. Such wizards may be customized
based on a client's recorded data, perhaps confirming past
interactions, providing account or order status, and so on. In some
embodiments, selecting an option might avail several additional
options. For example, selecting chat program may avail three
possible chat programs to choose from with different schedules,
content, and functionality attributed to each individual
program.
[0111] New order section 139 in this example contains various
options adapted to facilitate placing orders. The options as
illustrated herein include, but are not limited to, I-phone, call
back, promotional models, video presentations, an on-line viewer,
and an order wizard. Interaction is the same as was stated with
regards to section 137. For example, selecting promotional models,
accesses a database containing the current promotional information
and features of products which may be viewed interactively by the
client using an on-line viewer offered as one of the functional
options (tool). The options presented in the New Orders section may
also be customized according to client identity, demographics,
transaction history, and enterprise rules.
[0112] On-line viewers may enable the client to view documents that
are not supported on his computer platform. Selecting video
presentation may avail several types of videos for viewing ,such
that the client may choose one. If the client does not have a
viewer installed on his computer which will support the offered
video, perhaps the on-line viewer may play the video, or the client
could download a temporary viewer from section 141, etc. Selecting
call back may bring up a second array of media choices made
available by the enterprise for receiving a reply interaction from
an agent.
[0113] By providing a controlled interface window such as window
133 the enterprise may control routing and interaction right from
the beginning of customer contact. Through the innovative method of
linking and reporting to other CINOS functions, and repositories,
much real-time personaliation of window 133 according to enterprise
rules and customer parameters may be made automatically. For
example, if a client's history indicates a propensity toward
frequent buying, an I-phone option may be presented in customer
service section 137 in his window 133 immediately after such a
determination so that he may get direct customer service at all
times.
[0114] Certain media options, as described above, may be afforded a
certain priority over one another regarding interaction with the
enterprise. For example, a VIP client may have live interactive
media choices offered in window 133 such as I-phone, call back to
COST phone, video phone, etc. A client known for infrequent contact
or troublesome interactive history may be limited to text-based
interaction such as e-mail and so on.
[0115] As an integral part of CINOS functionality, window 133 acts
as a portal through which existing and potential clients may be
screened, categorized and routed according to enterprise rules.
Customer interfaces such as window 133 may be provided at various
locations on a WAN such as the Internet without departing from the
spirit and scope of the present invention. Such portals may exist
in different geographic regions, and may be created for differing
customer bases such as one for Latin America, and one for the
pacific rim, and so on. Instances of CINOS routine may be
distributed widely over a network.
[0116] Although the example provided herein is of a WEB form, it
will be apparent to one with skill in the art that a CTI
counterpart may be created for the COST telephony network. Such a
case may be a CINOS enhanced IVR at an SCP or customer access point
in the COST network.
[0117] CINOS, as previously described, optimizes customer/agent
interaction in a manner which is economical and cost efficient to
both the enterprise and the patronizing client. The customer
interfacing window as taught herein with regards to FIG. 5 is
innovative in that it is a filly customizable portal that
facilities seamless integration between clients and enterprise
agents according to enterprise rules. Further innovation is evident
in that client data is fully and seamlessly integrated with CINOS
intelligence and enterprise rules regarding routing of interactions
and other constraints or limitations that are programmed into the
system. In effect, logic from the front end, or customer side, to
the back end or agent side is linked and accessible to all
appropriate CINOS routines which include applicable CTI CINOS
routines. The various customer interfacing logic is are explained
more fully below in a series of process logic steps in a flow
chart.
[0118] FIG. 6 is a flow chart illustrating media-presentation and
customer-interface logic steps according to an embodiment of the
present invention. In step 145, a visitor registers at an
enterprise's WEB page. The visitor is identified according to
enterprise rules in step 147. In step 148 CINOS determines the
current status of the visitor after searching known client and
contact data records. For example, the visitor may be a potential
new client, an existing client, or an existing business contact.
Although not specifically illustrated, a potential or
new-business-client is not typically logically separated from a
potential new-client until further process ensues in step 149 with
regards to qualification via survey.
[0119] If the visitor wishes to be a client, he may log-in to the
network system in step 159. Log-in may be automatic in the event
that CINOS remembers the client's assigned password, or perhaps
typing the password or other code may still be required for
security reasons. At the time of log-in, window 133 is presented in
personalized fashion according to client data and enterprise rules
in step 161. In step 163, interaction between an enterprise entity
and the client begins with a media type that is offered by the
enterprise and selected by the client. An enterprise entity, as
immediately described above, is herein defined as an agent,
knowledge worker, service person, or any other live attendant, as
well as any entity constituting an automated response action such
as an automated fax, an IVR, automated file downloads, etc.
[0120] At step 148, if it is determined that the visitor is new,
then a new client survey is conducted in step 149. Step 149 will
determine if the new visitor is a client or business contact via
the survey process. As described with reference to FIG. 6, the
client survey may be conducted using a variety of known techniques
and media. Presuming that a new visitor qualifies as a client or
business contact in step 149, he or she may be asked to create a
password in order to provide access to CINOS. In step 153, the
client's appropriate communication and system parameters are
recorded for future reference and for use in customizing window
133.
[0121] At step 155, a client instance of CINOS, or perhaps another
enabling application, may be presented for download by the client.
In some embodiments, there may be no required software for
download. Therefore, step 155 may be considered optional in this
regard. In step 157, the new client may log-in to the network
system and begin interaction. Because the client, in this case, is
accessing the system for the first time, the steps wherein he would
obtain a customized window and begin interaction with an enterprise
entity are not shown as intermediate configuration of media
choices, product preferences, and the like, may still be required
before a customized interface may be presented. In one embodiment,
the client may not see a customized window until the next time he
or she attempts to access the network.
[0122] Steps 165, 167, and 169 for an existing business contact as
determined in step 148 are similar to steps 159, 161, and 163 for
an existing client although the rules for interaction such as media
used, personnel involved and so forth will be different. For
example, in step 167 an existing business contact may be offered
the option of using a network-collaboration program wherein
I-phone, file sharing, video conferencing and the like are inherent
to that one application.
[0123] It will be appreciated that there are many possible logic
sequences or steps that may be followed in interfacing and enabling
interaction between a client and an enterprise entity without
departing from the spirit and scope of the present invention. FIG.
6 presents just one possible example of many.
[0124] It will be apparent to one with skill in the art that the
rules governing the types of media offered to clients may be based
on a combination of variables such as may be decided upon by the
enterprise without departing from the spirit and scope of the
present invention. Likewise, offered media types may be added or
withheld from a client over a period of time based on such
variables. Moreover, such additions or subtractions of media
availability with regards to customer interface window 133 may be
automated and based on calculated variables.
[0125] In one embodiment, a client may add or subtract media
choices if desired, however, the enterprise may reserve the right
not to engage such media if added by a client.
[0126] In one embodiment, special application-independent media
viewers such as the viewer offered in section 139 of window 133 of
FIG. 5, are offered to clients and possessed by agents so that
initial illegible information may be made human readable regardless
of the authoring application used by the agent or the client in the
process of interaction.
[0127] Rules-Based Storage and Threading of Multimedia
Interactions
[0128] In a preferred embodiment of the present invention, all
CINOS controlled interactions with customers or business contacts
are recorded and stored in a contact history comprising a MIS
database and a text database such as were described with reference
to copending application P3313PA, and described above. That is,
actual multimedia interactions are recorded to one database or to a
section of one database supporting all multimedia types used in the
communication center, and text-based versions are stored in another
database or portion of the same database. All of the actual
recorded transactions and text versions are related as a threaded
contact history which may be separate from or part of the same
database as will be further explained below.
[0129] FIG. 7 is an exemplary overview of a multimedia-interaction
storage system within a communication center according to an
embodiment of the present invention. A system architecture 171 is
illustrated solely for the purpose of providing just one of many
possible architectures in which the methods and apparatus of the
invention may be practiced. Architecture 171, which in a preferred
embodiment comprises both conventional and DNT apparatus, is
exemplary of an architecture that could facilitate CINOS according
to an embodiment of the present invention such as is also the case
of FIG. 1.
[0130] At the heart of the storage system is a mass-storage
repository 187 adapted to store multimedia interactions as well as
text-based related files. Repository 187 may utilize any form of
digital storage technology known in the art such as Raid-Array,
Optical Storage, and so on. The storage capacity of repository 187
will depend directly on it's implementation with regard to the size
of the communication center and predicted amount of data that will
be stored and kept by the system.
[0131] In this example, repository 187 is divided logically into
two sections. One section, multimedia information system (MIS) 189,
is responsible for housing all multimedia interactions defined as
media that is not text-based such as audio, video, and
graphics-based media. All multimedia interactions are stored in MIS
189 whether incoming, outgoing, or internal. A second section,
herein referred to as text section 191 is responsible for all
text-based interactions as well as text versions related to
non-text files. Sections 191 and 189 of repository 187 are
analogous to MIS 79 and DB 75 of FIG. 3.
[0132] Repository 187 is connected to a communication-center local
area network (LAN) 195. Repository 187 is accessible via LAN 195 to
authorized personnel within a communication center such as agents,
knowledge workers, or the like, and may, in some instances, also be
made available to clients communicating with the call center. A
network router (RTN) 175 is shown connected to LAN 195 via network
connection 203. In this example, network router 175 is the first
point within a communication center wherein DNT media arrives.
Network router 175 is exemplary of many types of routers that may
be used to route data over LAN 195. An
Internet-protocol-network-telephony (IPNT) switch 176 is connected
to network router 175 via data link as is known in the art. IPNT
switch 176 further routes or distributes live IPNT calls that do
not require routing to a live agent. IPNT calls that are routed to
live agents are sent over connection 203 to LAN 195 where they
reach agent PC/VDU's (not shown) or DNT-capable phones (not shown)
as illustrated via directional arrows.
[0133] An object of the present invention is to record all
multimedia interactions and store them in MIS 189. A further object
of the present invention is to similarly record text versions of
and text files related to all multimedia interactions and to store
them in text-based section 191. For the purpose of the present
invention, a text version of a non-text file is defined as a
sufficient text rendition or description of a corresponding
multimedia interaction. Still another object of the present
invention is to provide an innovative mechanism wherein authorized
persons may access any particular block of text and if desired,
call up the actual media to which the text relates. More detail
regarding the order and manipulation of repository 187 is described
further below.
[0134] Creating text-based versions of live multimedia interactions
may, in some cases, be accomplished via an automated method. For
example, a digital voice attendant 197 is provided and linked to
IPNT switch 176. Digital voice attendant 197 may be of the form of
a DNT-capable IVR or other digital voice-response mechanism as may
be known in the art. Such automated attendants may interact with a
voice caller instead of requiring a live agent. A speech to text
converter 199 is provided and linked to voice attendant 197. As
digital voice attendant 197 interacts with a caller, speech to text
converter 199 uses voice recognition technology to convert the
audio speech to text. Such text may then be stored automatically
into text section 191 and related to the also-recorded audio
data.
[0135] It will be apparent to one with skill in the art that as
speech recognition technologies are further improved over their
current state, which is adequate for many implementations, reliable
text versions of audio transactions are not only possible but
practical. Such speech to text conversions are used here only for
the convenience of automation wherein no live attendant is needed
to transcribe such audio data. The inventor is familiar with such
converters as used in the CINOS system according to a preferred
embodiment. Such converters provide convenience in the practice of
the present invention but are not specifically required to achieve
the objects of the present invention.
[0136] Manual transcription may also be used to convert audio/video
to text or code that may then be entered into text section 191. For
example, a live attendant 201 is shown connected to LAN 195.
Attendant 201, in this case, may be given the responsibility of
transcribing audio files from speech to text and annotating video
or graphics files for the purpose of creating text files related to
the non-text data. One or more live attendants such as attendant
201 may be provided for this purpose. Some media arriving at a
communication center such as the one represented via architecture
171 will already be text-based and therefore require no conversion
or annotation. Short e-mails, Faxes, word documents, and so on are
part of this media category.
[0137] An automated services system 193 is illustrated as having a
direct connection to section 191 of the data repository. System 193
is provided for certain text-based interactions, as described
above, wherein a complete text record of the interaction may be
mirrored, or otherwise created and stored into text section 191.
Such automated services may include but are not limited to
automated e-mail and fax systems. For example, a fax may be sent
and mirrored into section 191 or, perhaps recreated using an
optical character recognition (OCR) technique and then entered.
Physical text-documents such as legal papers and the like, may be
automatically scanned into text section 191 before they are sent to
clients. There are many possible automated techniques for entering
text files into a database. Such methods described with regards to
automated services 193 are a convenience in practicing the present
invention but are not specifically required to achieve the objects
of the present invention.
[0138] With respect to the dual capability (COST/DNT) of
architecture 171, a central telephony switch 173 is provided to be
a first destination for COST calls arriving from, for example, a
PSTN network. Switch 173 may be a PBX, ACD, or another known type
of telephony switch. Internal COST wiring 182 connects telephony
switch 173 to agent's individual telephones (not shown). Switch 173
is enhanced via a processor 179 running an instance of T-server and
an instance of Stat-server, which are software enhancements known
to the inventor and have been previously described. Such
enhancements provide CTI applications, such as intelligent routing,
but are not specifically required to practice the present
invention. CINOS as previously described is adapted to be
integrated with such software when present in a CINOS enhanced
communication-center.
[0139] An intelligent peripheral in the form of a COST IVR 177 is
provided for the purpose of interacting with callers seeking
information and the like who do not require connection to a live
agent. IVR technology may comprise voice response, touch tone
interaction, or a combination of these technologies. IVR 177 is
linked to processor 179 and also to automated services 193. An
example of an IVR interaction may be the presentation to a caller
of options for using an automated service such as those described
above, or perhaps waiting for a live agent.
[0140] A CTI to DNT interface 181 is provided for the purpose of
converting COST interactions to digital mode compatible with DNT so
as to be adapted for digital storage and interaction according to
CINOS functionality and enterprise business rules as described
above. Interface 181 is not specifically required to practice the
present invention so long as appropriate application programming
interfaces (API's) are provided for equipment that interfaces with
CINOS. Bi-directional arrows illustrated between interface 181 and
IVR 177 represent the ability to route interactions in either
direction. COST to DNT conversion may be accomplished in IVR 177 in
addition to or in place of interface 181. The connection
architecture presented herein is exemplary only.
[0141] A speech to text converter 185 is provided for converting
audio from the CTI side to text for entering into text section 191
as was taught with regards to converter 199 on the DNT side. Actual
recorded media interactions are illustrated entering MIS 189 after
text versions are rendered and entered into section 191, however,
this is not required. In some instances text versions of multimedia
interactions may be rendered after the interaction is stored. There
is no limitation regarding sequence. It is sufficient to say that
converters 185 and 199 are capable of real-time conversion and
entry.
[0142] Server 183 shown connected to LAN 195 is adapted to host a
CINOS MGR.(operating system) application which provides control and
organization with regard to various functions provided by the CINOS
system as a whole. The storage architecture represented herein by
element 171, and all it encompasses in this embodiment, is meant
only to be an example architecture as may be dedicated to the
storage and organization of communication-center data according to
enterprise rules.
[0143] A unique method termed multimedia threading by the inventor
is used in a preferred embodiment of the present invention for
relating each multimedia interaction whether incoming to, out going
from, or internal to the system, such as between an agent and a
supervisor. This innovative process allows agents or other
authorized personnel to access text data and ability
cross-reference the data to actual recorded multimedia interactions
which may be displayed and played back.
[0144] FIG. 8 is an illustration of a relational diagram as might
be displayed on a display monitor, representing entities stored in
the databases described. The blocks of FIG. 8 illustrate threaded
text-blocks and their relationship to stored multimedia according
to an embodiment of the present invention. Repository 187 comprises
section 191 and 189 as illustrated in FIG. 7. Section 191 contains
text versions of interactions that are related by such as
chronology ,issue, participants, company affiliation, and the like.
The text documents and versions of non-text files, represented in
this case by icons, are shown related by serial position. For the
sake of clarity regarding the innovative threading according to an
embodiment of the present invention, a brief description of prior
art threading follows.
[0145] Threaded dialog as is known in prior art involves a system
of strings or threads that are identified as being inherent to a
single entity or subject matter wherein the dialog (questions and
replies) is about that subject or about a question or subject that
an entity has brought forth. A threaded dialog may be finite dialog
(is closed at some point) or it may be ongoing. Typically, a
thread, which connects or associates the pieces of dialog, contains
all of the dialog in the order that it happened such as in
chronological order. Threading may be implemented based on other
criteria as may be appropriate for a particular situation or by
particular rules.
[0146] As previously described with reference to the background
section, prior art threading techniques are confirmed to text such
as with an on-line message board or the like. The inventor knows of
no system that supports full multimedia interaction. The innovative
implementation taught below integrates the text-based thread with
stored multimedia interactions such that one may interact with the
thread and access various stored media associated with the
thread.
[0147] Referring again to FIG. 8, a customer 205 is illustrated as
having two threads. They are issue I and issue II. Customer 205 has
an assigned number XX-XX that identifies him or her with respect to
the CINOS system. Issues I and II may comprise sales dialog,
purchasing dialog, or any other type or purposed dialog as may be
generic to the hosting enterprise. Customer 205 may well be a
business contact, or even an internal agent practicing dialog with
a supervisor or the like.
[0148] A series of icons a-d represent the type of media stored for
each text block (text not shown). For example, issue I comprises
first an e-mail text followed by a fax text, WEB text, and V-phone
text. In this case, a time stamp or other known method may be used
to insure that each text block is in order. Icons a-d are
interactive pointers or links to the actual media interactions that
they represent. That is, the first block of e-mail text is
associated with an interactive icon, in this case icon a. By
clicking on icon a with a pointer device, the actual e-mail may be
accessed and viewed. In an alternative aspect, not only the actual
transaction may be presented to a user for review, but related
files may also be listed or otherwise presented for selection and
review.
[0149] A logical link 207 represents cross-referencing capability
between sections 191 and 189. Dialog may be threaded according to a
wide variety of business rules. For example, a thread or string may
represent dialog about a customer, product, agent, group of agents,
group of customers, and so on. An identifier is assigned to an
entity and to all the communication events to or from that entity,
or those in which the entity may have been involved such as a group
discussion or chat. In this way all interactions may be organized
and stored accordingly.
[0150] In one embodiment, keyboard commands could be used to
cross-reference to actual media instead of icons. In another
embodiment, text versions of actual media are fully viewable with
the text itself appearing in interactive form whereupon a double
click may call up the associated media and so on. There are many
variations within the scope of the invention.
[0151] Although actual recorded media interactions are, in this
embodiment, stored in MIS 189, there does not have to be two
separate databases (one for text and one for actual media). All
data may reside in one database and be sectioned in storage. For
example, one click on the customer name may bring up text only,
while a double click on the text brings up the associated
media.
[0152] In MIS 189, recorded multimedia interactions are represented
by icons I-IV and VI. For example element I represents all recorded
Video phone interactions. Element II represents all e-mails.
Element III represents all recorded COST interactions. Similar
associations are made with respect to elements IV and VI which
represent WEB interactions and Video mails respectively. WEB
interactions IV may include on-line orders, requests, information
forms, signed certificates, and so on.
[0153] Element V represents additional stored multimedia files
dedicated to, for example, promoting the enterprises products or
services. Promotional files V may contain files of the form of any
enterprise supported multimedia. These files may be tools that can
be sent to clients upon request or perhaps periodically.
[0154] Referring again to section 191, element b located on the
thread labeled issue I represents text from a fax. Because a fax is
text-based and not a multimedia interaction, there is no
corresponding media event associated with it. However, the fax is
threaded into the dialog according to, in this case, chronological
order. A short example of a proposed dialog concerning issue I
follows.
[0155] Element a represents an e-mail sent by customer 205 to the
enterprise requesting pricing information. An enterprise agent
responds with a fax (b) to customer 205 containing the requested
information. Customer 205 then places an on-line order (element c)
along with a request for confirmation via video phone (element d).
Issue I may be closed at this point. Issue II may represent a
threaded dialog concerning company service with regards to the
customer order of issue I, or perhaps an agent-to-manufacturer
dialog regarding how the order was handled with respect to issue
I.
[0156] In accordance with CINOS functionality as previously taught
in descriptions above, data may be mined from repository 187 for
the purpose of enhancing service to customer 205. Mined data may be
used to affect routing of interactions, product promotions or
advertisements that may be sent to customer 205. In some cases,
mined data may effect new dialog with a customer or business
contact resulting in new thread additions. A complete contact
history with interactive linking to actual recorded media enables
the enterprise to resolve disputes more easily, better service the
customer, and enhance profitability for the enterprise.
[0157] FIG. 9 is a process flow chart illustrating logical steps
taken when building a threaded multimedia contact-history of
communication-center interactions according to an embodiment of the
present invention. Logical process steps as illustrated herein are
meant to represent just one of many sequences which may be
implemented when building a multimedia-threaded contact-history.
Actual steps will depend on enterprise rules. In step 209, a
current interaction to be recorded is identified. Identifiers may
include special passwords or codes for identifying the contacts
involved with the interaction. The media type of the interaction is
identified in step 211. If the media type is already text-based, as
confirmed in step 213, then the interaction is prepared for entry
into a database such as section 191 of FIG. 8. Preparation may
include such automated processes as scanning, mirroring, file
conversions, and so on. Manual annotation via live attendants such
as attendant 201 of FIG. 7 may also be performed. In step 223, the
text interaction is entered into section 191 of repository 187 and
takes it's place along the associated dialog thread according to
enterprise rules.
[0158] If the interaction is of the form of non-text media as
identified in step 211, then the MIS section of repository 187, or
section 189, is notified to accept the input. At step 219, the
non-text interaction is recorded into section 189 of repository
187. This may occur in real time as the interaction takes place, or
some point after the media interaction was recorded.
[0159] In step 221, a text version of the recorded media or a
text-based document related to the transaction is rendered for
storage into section 191 as part of the thread. In some instances,
as described with reference to FIG. 7, step 221 is automated via
speech to text converters and occurs at the same time or before the
recorded multimedia interaction is entered into section 189. In
other instances, text versions of multimedia interactions may be
rendered after the recorded interaction is stored. A live attendant
such as attendant 201 of FIG. 7 may be assigned to parse video and
or audio for applicable text. Such parsed text is entered into
section 191 and takes it's place along the thread as was described
above.
[0160] In all cases, an identifying medium is used to assign
portions of an ongoing dialog to the proper location along a thread
as well as provide identification to actual recorded media for
cross-referencing such as may occur during a system audit or
contact review. Further, the appropriate icons and or links are
created and associated to entered text wherein actual multimedia
may be cross-referenced in interactive fashion. Hence, the type of
media may be readily identified by an auditing or reviewing agent
simply by browsing the threaded text with accessibility to the
recorded events made by interactive method such as clicking an icon
with a pointer device as was previously described. As an additional
benefit all of the threaded dialog, whether text based or not, is
rendered in a form that data mining may be used to create many
useful relationships and to derive much useful information from the
stored data.
[0161] It will be apparent to one with skill in the art that the
order and specific function of logical steps as taught herein may
vary according to the type of enterprise, existing enterprise
rules, and so on. For example, instead of threaded dialogs being
inherent to a specific customer with the dialog being about the
customers interactions, it may be specific to a particular agent
with the dialog about the agents activities. Such differences in
thread assignment may be incorporated into one rules-based
repository.
[0162] Interactive Multimedia Viewers and Applications
[0163] In a preferred embodiment of the present invention, CINOS
users comprising such as customers, agents, and business associates
are provided with innovative multimedia applications that are
containers for dedicated multimedia viewers enabling a particular
user to perform a dedicated function or functions including gaining
access to and viewing media from selected areas of CINOS data
storage. Provision of such applications allows any objective to be
gained regarding virtually any aspect of the enterprise. These
interactive applications are built from a parent application or
container that may contain all of the interactive modules that may
be desired to effect a specific application to be presented to a
user having a need for such an application.
[0164] According to various embodiments of the present invention,
which are described below, the multimedia applications may be
adapted for such tasks as placing orders, previewing products,
determining customer profitability, calculating sales volumes,
reviewing agent performances, or any other enterprise-conceived
objective. The abilities and constraints applied to these unique
applications are limited only by the imagination, and tools
available to an authorized programmer or worker, such as a
knowledge worker, who creates the applications.
[0165] FIG. 10 is a block diagram illustrating an interactive
multimedia application (IMA) tool kit and a diagram of a created
IMA application according to an embodiment of the present
invention. An IMA tool kit 225 is provided to an authorized
programmer, which may be a knowledge worker, for the purpose of
creating special multimedia applications such as an IMA 239
(illustrated within tool kit) for users of CINOS, wherein users may
access and interact with certain pre-selected data for the purpose
of reaching decisions and performing certain dedicated objectives
as may be defined by enterprise rules. IMA tool kit 225 contains
executable codes or modules represented as building blocks by the
inventors. These modules may be used by themselves for certain
functions, or may be linked to each other to provide additional
function in a programmed order. A good example of such a module
would be a combination of COM codes used to build an interactive
graphical interface (module), and the like.
[0166] Among these functional modules are interactive media viewers
(IMV's) 227 which are provided and adapted for viewing certain
media supported by the enterprise hosting a communication center
employing CINOS. Supported media types may include but are not
limited to telephony (traditional or IP), interactive voice
response (IVR), e-mails, WEB embedded interfaces or forms, faxes,
chat programs, multiparty threaded discussions, etc. IMV's 227 are
unique in the fact that they are dedicated viewers including an
interactive layer that enables viewing of only pre-selected media
as defined by enterprise rules. For example, CINOS users may be
assigned an identification code or number which will also be tagged
to all of their stored interactions as described elsewhere above
with reference to FIG. 9. These codes may be used to associate
individuals with limitations and constraints from viewing media
that is not part of their own contact history (for example). Other
limitations or constraints may also be applied to IMV's 227 as may
be conceived and implemented by a programmer such as playing or
viewing interactions of certain dates, playing or viewing
interactions about certain subjects, and so on. An editable
software layer inherent to each viewer enables a programmer to
build such constraints into a particular viewer, and to add the
edited viewer to an IMA.
[0167] Application Program Interfaces (API's) 229 are provided to
allow a user to send obtained data or calculated results to
connected peripheral devices or software modules or applications as
may be required for operations such as printing, faxing, sending
over a network, etc. If it is desired by enterprise rules, for
example that a customer be able to print certain text or graphic
information obtained through IMA 239, then the appropriate
interface may be provided.
[0168] Database Access Modules (DAM's) 231 are provided for
allowing access to normally restricted databases that may be
connected to CINOS architecture. Such databases will of course
include multimedia information systems (MIS), customer information
systems (CIS), which may also include contact and agent associated
data, external databases such as may be hosted by the enterprise,
and so on. Constraints may be applied to DAM's 231 pertaining to
which and or what portions of certain databases may be accessed by
an application.
[0169] Programming language modules 233 are provided and adapted to
facilitate the type of platform/system that an IMA such as IMA 239
will be created for. One IMA such as IMA 239 may be adapted to run
on a variety of system types and platforms. System platform modules
are provided as API's for intended supported system/platform
combinations. Mathematical function modules (MFM's) are provided
and adapted to interact with CINOS databases for the purpose of
performing pre-selected calculations such as cost averaging and so
on.
[0170] In this particular embodiment, IMA 239 is a finished
application ready to be distributed. IMA 239 contains default
display modules (not shown) for the purpose of enabling computer
screen display on a user's system as is known in the art. IMA 239
may be stored in a special applications server (not shown)
connected to the CINOS network either at WAN level or at the level
of the hosting communication center. The method of distribution for
IMA's such as IMA 239 may be of the form of a WEB-based client
presentation to a user such as in customer window 135 of FIG. 5,
for example. IMA 239 may also be of the form of a browser plug-in
accessible via a server such as may be the case with a special
applications server as described above. In other instances, such
applications may be made a part of an agent's desktop and so on.
There are many and varied possibilities.
[0171] In this particular embodiment, which is exemplary only, IMA
239 is of the form of an interactive purchase guide for bulk paper
products as illustrated via underlined title. IMA 239, in this
example, is logically separated into two distinct operations or
functions. These are operation 241 and operation 243. Operation 241
is a product preview interactive guide, while operation 243 is an
order guide. The number of operations built in to an IMA such as
IMA 239 will depend upon the intended purpose of the application
according to enterprise rules.
[0172] For exemplary purposes, assume that IMA 239 which is, in
this case, a purchase guide for bulk paper products, is to be
presented to a corporate buyer who is new on the job. Because he is
new, he may be uncomfortable with his own knowledge of how much or
what kind of paper to buy. His predecessor may have a long purchase
history with the enterprise. Therefore, he requests an IMA such as
IMA 239 that will allow him to preview products, browse the past
purchase history of his predecessor, and perform a calculation that
averages, by month, the last years paper purchases made by his
company.
[0173] According to enterprise rules, IMA 239 adheres most closely
to the buyer's request. That is, It allows for preview of products
(241), and leads the buyer toward an order (243). IMA 239 may, in
some instances, be designed specifically for one buyer if it is
determined that his level of business contribution warrants it.
However, in most cases, IMA applications such as application 239
will be more generic with interchange between different users
accomplished with some editing performed based upon the intended
use of the application and user parameters.
[0174] A communication center may provide a number of standard
IMA's with each IMA adapted to a different objective. A
communication center may also provide custom-built MIAs for any
specific purpose. A certain amount of editing ability renders one
IMA usable in more than one situation.
[0175] Referring now to IMA 239, as previously described,
operations 241 (product preview) and operation 243 (order guide)
are available and related to purchasing bulk paper products.
Operation 241 begins by presenting two different platform options
from which a user may select. A platform A may be a Windows
platform, and a platform B may be a UNIX platform. There may be
more or fewer options regarding platforms. Similarly, applicable
modules such as may be generic to a certain platform are installed
with each platform. In this way, one application may be run on
differing platforms.
[0176] An API, labeled as such, shown logically connected beneath
platforms A and B is illustrative of an interface for linked
modules depended on platform choice. A database module (DAM) is
first logically connected to the API module previously described.
The DAM controls which database or databases may be accessed by IMA
239. A window shown immediately beneath the DAM provides an edit
interface wherein the author or programmer may insert additional
constraints, such as allowing access to only certain database
sections and so on.
[0177] A mathematical function module (MFM) labeled as such is
shown beneath, and logically connected to the edit window. MFM is
adapted to allow prescribed mathematical operations to be performed
relative to database information such as cost averaging, grouping
by product preference, and so on. Various modules as have been
described herein may bring up additional displays on a user's
computer if the module in question offers a choice of operation or
returns readable results. Furthermore, standard preview modules
(not shown) may be presented as object models and invoke standard
viewers such as may be installed on the user's computer system.
[0178] An interactive media viewer block (IMV) shown logically
connected to MFM, allows the user to view pre-selected media
interactions that are persistently stored in a database such as MIS
189 of FIG. 7. The IMV block shown may represent a plurality of
unique IMVs or a single IMV. In this case three IMVs are involved,
and these are represented by the blocks labeled TXT (text), VID
(video), and AU (audio). Each individual IMV has an edit layer
wherein a programmer may apply limitations or constraints relative
to viewing capability. In some cases the same limitations may be
applied to all the IMVs of an application in one editing sequence,
such as by doing one edit and copying that edit to other IMVs.
Although there are three illustrated viewer modules that make up
the IMV in this example, more or fewer viewer modules may be used
depending upon the intended use of IMA 239 and enterprise
rules.
[0179] Although not explicitly shown, each IMV is editable through
a software layer. In this way, a user may be limited to viewing
certain media interactions and transactions that are allowed via
enterprise rules. For example, TXT viewer may only be able to view
e-mails from the user and agent in a specific interaction thread,
but not intermittent e-mails on the thread that may be from agent
to agent or supervisor to agent and so on. Because each interactor
with CINOS has an identification, and all interactions from or to
them are so identified, these identifiers may be used in the edit
layer of each viewer to constrain the user. In this way, a user may
be granted access to a history database and view only his
interactions without imposing on other users who share the system.
Likewise, agents or supervisors charged with the task of reviewing
the activities of certain other agents may use applications such as
IMA 239, adapted for the stated purpose, and be constrained in
terms of whose interactions (agent's) may be viewed, and so on. In
this manner full use may be provided to specialized users without
exposing otherwise sensitive information that is not pertinent to
the user or the purpose of the IMA.
[0180] Operation 243 created to allow a user to place an order for
products is, in this case, a logical close for the previous
operation. A module labeled Media Options may present standard
media choices that the enterprise accepts for placing an order such
as IP phone, e-mail, and so on. A connected text module (TXT)
allows the user to send a quick text order while on-line. A send
button sends a completed order to the enterprise.
[0181] It will be apparent to one with skill in the art that an IMA
such as IMA 239 may be programmed for virtually any enterprise
objective without departing from the spirit and scope of the
present invention, such as those already described. By utilizing
pre-built modules instead of writing codes line-by-line,
programmers may greatly increase the efficiency of application
preparation and presentation to users. In many cases only slight
editing is required to present a new application to a particular
user. By using COM, and other known conventions such as Java,
applications are quickly assembled or modified as has been taught
herein.
[0182] FIG. 11 is a process flowchart illustrating logical steps
for building an IMA for a user interacting with CINOS according to
an embodiment of the present invention. The process described below
is meant to be just one example of many differing processes that
may be implemented when building and customizing an IMA such as IMA
239 of FIG. 10. The process components and order of which they are
assembled will depend largely upon the type and purpose of the
application being assembled and enterprise rules.
[0183] In step 238, the programmer or application author opens his
tool kit. Such a tool kit may be part of tool kit 125 of FIG. 4 on
a CINOS desktop interface. In step 240, the author sets system and
platform parameters. That is, he inserts the proper functional
modules for use of the application on specific platforms and or
system types. For example, the author may set up one application to
run on more than one platform or system such as IBM and Macintosh.
It should be noted here that if more than one type of system is
supported in one application, then the associated modules will need
to be included as well.
[0184] In step 242, the author selects a programming language
module containing libraries of known programming languages and
codes. As known in the art, there are different programming
languages used for different platforms. The author, in addition to
building with pre-assembled modules, or building blocks, may have
to write certain functional code in the supported language. In a
preferred embodiment, the author has access to these language
libraries from within his tool kit.
[0185] In step 245, database access module(s) (DAMs) are selected
and inserted. As previously described with reference to FIG. 10,
these modules will determine which and what portions of databases
may be accessed. In an alternative embodiment these restrictions
may also be a part of the editable layer of IMVs. Step 247 covers
mathematical functions relative to selected databases. Mathematical
function modules (MFM's) allow a user to perform pre-defined
operations. MFMs may or may not be needed in an IMA. This step may
be omitted if no such functions are requested by a user or
otherwise required in an application.
[0186] In step 249, interactive media viewers (IMV's) are created
using viewer modules adapted to view certain media of the type that
stored interactions comprise. An IMV is a module that may comprise
one or more than one media viewer. Each of these viewer modules are
editable (via software layer) and may function alone or as a
component of a larger module (comprising more than one viewer).
[0187] In step 251, closing modules are inserted to complete the
application. For example, order modules are one example of a
closing modules. Modules adapted to return displayed results would
be another example. Moreover, peripheral device API's may be
inserted to allow results to be printed, faxed, sent over the
network, etc. In this way, a supervisor reviewing the performance
of a group of agents may report to other concerned parties such as
managers, enterprise board members, or the like.
[0188] The example as illustrated herein is basic but is deemed
adequate by the inventor for illustration of one typical IMA
building sequence. The description and order of steps may vary
considerably.
[0189] IMA's such as IMA 239 are transportable over a network and
may be stored on a special applications server at network level, or
within the communication center. In some embodiments, user's will
be connected to the Internet when using IMA's allowing CINOS
access. In other embodiments, agents may access CINOS resources
while working off-line with respect to the Internet. In such cases,
logging on to CINOS is still required.
[0190] It will be apparent to one with skill in the art that IMA
239 as taught herein is interactive and displayable on a PC/VDU
that is logged into CINOS through a WAN. However, this is not
specifically required to practice the present invention, but rather
preferred. Other embodiments may include presenting a CTI interface
such as an IVR wherein a user may interact with the application via
voice or touch tone response.
[0191] In still another embodiment, such applications may be
presented via external media such as on a floppy disk(s) or CD-ROM
wherein a user may, by inserting the disk or CD, obtain the ability
of accessing the enterprise via WAN, gaining access to CINOS, and
performing an objective with the IMA.
[0192] Stored-Media Interface Engine (Interaction Object Model)
[0193] An object of the present invention is to allow certain CINOS
systems to utilize data, such as data about customers, contacts,
business associates, products and agents, to accomplish objectives
and to effect improvements in overall system performance. Such data
must be utilized very quickly in order to aid in influencing such
system objectives as efficient routing to clients based on client
data, or as another example, generating an updated sales-volume
report based on an entire customer base's latest transactional
history. Certain CINOS automated systems will have to be able to
make decisions in a time frame that would not be sufficient to
allow physical accessing of actual media. Therefore, an innovative
interface between stored multimedia data and various CINOS
intelligent systems is provided and taught below.
[0194] According to a preferred embodiment of the present
invention, a stored-media interface engine is provided in the form
of an interaction object model (IOM). This unique convention
provides a system-accessible abstract of all stored interactions
within a multimedia communication center.
[0195] FIG. 12 is a block diagram illustrating a relationship
between a mass repository 263, an interaction object model (IOM
interface) 253, and several data-interaction systems according to
an embodiment of the present invention. Interaction object model
(IOM) 253 functions as a memory-based interface-engine between mass
repository 263 and a variety of CINOS data-interaction systems
illustrated in this example as customer information system (CIS)
255, audit system (AT SYS) 257, routing system (RT SYS) 259, and
automated services system (AS SYS) 261. It will be apparent to the
skilled artisan that there may be many different interaction
systems, and the ones illustrated here are exemplary.
[0196] Repository 263 is analogous to mass repository 187 of FIG.
7. It is logically divided into two sections. One section is for
threaded text labeled Text-Based Data, and one is for multimedia
storage labeled MIS Database. All of the communication center's
interactions and transactions in this example are persistently
stored in repository 263.
[0197] Automated CINOS systems such as systems 255 through 261 are
adapted to interact with data stored in repository 263 in order to
perform their intended functions related to CINOS operation. For
example, CIS 255 uses data in repository 263 for presenting
information to agent's at the time of or ahead of a live
interaction. AT SYS 257 has to access and process data for
generating system audits. RT SYS 259 requires data for intelligent
routing purposes. AS SYS 261 uses data to update and configure
services such as faxes, e-mails, voice messaging, and the like.
[0198] IOM 253 is adapted to function as an interface between
repository 263 (hard data) and the data interaction systems as
described above. IOM 253 is an object model comprising objects as
representations of stored files in repository 263, such as non-text
files of recorded transactions. Each object making up the model is
a representation of one such file. In a preferred embodiment, IOM
is a COM-based model with which other CINOS COM-based applications
may readily interact without language conversion interfaces.
However, in other embodiments, API's may be provided where language
differences are present.
[0199] IOM 253 has various capabilities in various embodiments
which may include, among other functions, a search function 265
adapted to accept parameters as a guide to obtain requested
information from IOM memory (element 275). There is in this
embodiment a data-mining function 267 adapted for mining hard data
and converting mined data into suitable code for applying to memory
objects (represented interactions). A display function 269 is
adapted to enable data results to be displayed on suitable screen
monitors which may be associated with various data interaction
systems as previously described. An API function 271 provides
appropriate interface for linking interaction-data systems such as
systems 255-261 to IOM 253. An edit function provides editing
ability to object parameters by system applications which may, in
some instances be automated, or, in other instances, manned by
administrators or knowledge workers. An object memory 275 is a
single file containing all of the objects which represent all of
the communication center's stored interactions.
[0200] IOM 253 is run in much the same way as a standard relational
object model as is known in the art, except that it is confined to
text data and capable of multi-tasking (performing multiple
simultaneous and unrelated functions) with respect to multiple
system access. Another marked difference from a standard object
model is the data mining functionality 267. In a preferred
embodiment, function 267 may be used to add additional data to IOM
memory in real time.
[0201] IOM 253 uses metadata, meaning data about data, in it's
abstract representation of hard data files stored in repository 263
similar to other data warehousing systems. Such metadata may be, in
some embodiments, compressed in memory for economy in storage. In a
case such as that described above, a compression and decompression
function would be added to IOM 253. IOM 253 utilizes memory area
275 for storing metadata objects a-z as illustrated. Metadata
objects a-z, as illustrated, each represent a single transaction or
interaction file stored in repository 263. Hence, the number of
actual objects stored in memory 275 will equal the number of
interactions stored in repository 263, if every stored transaction
is shadowed in the IOM.
[0202] IOM 253 is innovative in the fact that it is an object model
interface used as an accessible abstract representation of hard
data files. Therefore, data-interaction systems may typically
utilize IOM 253 in performing their dedicated functions without
accessing any hard data stored in repository 263. The inventor
knows of no system wherein data systems may obtain stored
information to aid their dedicated functions in the manner and with
the apparatus described above.
[0203] Memory 275 is typically located in repository 263 as is the
rest of IOM functionality as illustrated via directional arrows
emanating from repository 263 and pointing to a separate IOM 253.
Software adapted to communicate with IOM 253 (not shown) may reside
in each of the data-interaction systems 255-261 as illustrated via
directional arrows pointing to API function 271. The above
described relationship is not specifically required to effect the
goal of the present invention, but rather preferred in it's
practice. IOM 253 may reside on a separate database that is linked
to repository 263. Similarly, API function 271 may contain all of
the necessary components for interface with all communication
center data-interaction systems without requiring each system to
host software. There are many differing architectural
possibilities.
[0204] According to an embodiment of the present invention, IOM 253
is continually updated in real time as interactions may be stored
or deleted in repository 263. Rules-based routines determine what
type of data will be used in each meta-data object stored in memory
275. Typically, enterprise important information such as client ID,
client parameters, transactional analysis (such as profitability
rating), credit rating, and so forth, will accompany more
interaction-specific data, such as media type, interaction date,
participating party ID's and their parameters, and any parsed
information specific to the interaction and known to be required by
one or more of the automated services. Interaction-specific
information may include interaction purpose or goal, interaction
results such as purchase information, resolved issue information,
and so on.
[0205] Memory objects, such as objects a-z representing
interactions, are not only identified with regards to involved
parties as previously described, but may also be identified and
associated according to the common thread order of interaction as
represented in repository 263, or more specifically, the text-based
portion which is threaded dialog.
[0206] It will be apparent to one with skill in the art that an IOM
such as IOM 253 may be utilized with databases other than
repository 263 without departing from the spirit and scope of the
present invention. For example, IOM 253 may also be used as a
system interface to product information databases, external
knowledge databases, or virtually any other database such as may be
connected to CINOS or a similar operating system.
[0207] FIG. 13 is a flow chart illustrating interactive steps
associated with IOM functionality according to an embodiment of the
present invention. The following basic example of IOM functionality
is meant to illustrate just one possible sequence of logical steps
taken when utilizing IOM 253. This example should in no way limit
the present invention in terms of the broadest scope to which the
present invention should be afforded.
[0208] In step 277, a request to access an IOM such as IOM 253 of
FIG. 12 is received from a data-interaction system such as RT SYS
259 of FIG. 12. In step 279, the IOM is activated to receive
commands related to a dedicated operation or pre-defined process.
Activation in this sense is defined as activation to receive from
or communicate with a specific requesting system.
[0209] In step 281 commands are sent to the IOM for the purpose of
initiating IOM functions as may be desired. In step 283, the IOM
performs the requested function or functions. In this case, the
function or functions are adapted to provide information to be used
in routing of a new interaction. A simple example of a
routing-related function would be to return the information
associated with the identified client's last 5 interactions in
order to determine a best fit agent to accept the new interaction.
If it is determined that the last 5 interactions are leading to a
purchase, and the prominent agent involved in the last 5
interactions is identified, then the new interaction may be held
for that agent in the hopes that statistically, he is more likely
to obtain a new order from the client. However, if the last 5
interactions are stagnant or leading away from a purchase, than the
interaction may be routed to a new agent, perhaps with more skill
at motivating clients to buy, and so on.
[0210] In step 285, displayable results from performed functions
are returned to requesting systems. In some instances, results will
not be required to be human readable or to be displayable on a
monitor. However in other instances, this may be required such as
an instance wherein data about a client is forwarded to the
receiving agent ahead of the clients interaction.
[0211] It will be readily apparent to the skilled artisan that the
process steps described above may vary in number and description
according to type of business, type of data-interaction system
requesting information, enterprise rules, and type of data
accessed. This basic example is meant to provide a broad scope of
functionality.
[0212] Interactive Modules for Managing Business Processes
[0213] In a preferred embodiment of the present invention, a
multimedia communication center operating CINOS according to
previous co-related embodiments is provided, as part of CINOS, a
means to initiate and manage various business processes related to
communication workflow. Such business processes are defined as
enterprise-created applications, procedures and so forth, that are
adapted to return a result or provide a solution regarding an issue
or request made by a client or other entity.
[0214] As briefly described in the background section above, in a
multimedia communication center it is desired to automate business
processes where possible and to be able to break down the processes
into tasks and sub-tasks that are strictly controlled and timed.
Prior art network systems require considerable human intervention
while proceeding with a business process while, for example, a
client waits for a resolution. Similarly, more time is consumed
because actual media and hard data may be accessed and processed
without the benefit of an abstract representation of data
(metadata) as discussed above relative to an interaction object
model (IOM). Therefore, an Interactive Process Model (IPM), is
provided as a generic programmable module, which when complete,
represents and conducts a defined business process. An IPM
according to this invention has ability to obtain data from an IOM
and to manage business applications in terms of timing and
execution of main tasks and sub-tasks that are programmed according
to enterprise rules.
[0215] FIG. 14 is a Gant table illustrating a pre-defined business
process according to an embodiment of the present invention. A Gant
table 287 represents the tasks and sub-tasks of a business
procedure, in this case qualifying an exemplary loan application,
as they might appear on a programmers screen after an automated
execution sequence has been completed. Gant table 287 will
hereinafter be termed Interaction Process Model (IPM) 287 for the
purpose of simplifying explanation.
[0216] IPM 287 is a programmable interactive engine as previously
described. That is, one may program IPM 287 according to various
tasks and sub-tasks that may be required for the execution of a
particular business process. After basic programming or set-up, IPM
287 has the capability of accessing data from, among other possible
sources, the IOM described above, and using that data in the
execution of it's intended goal. IPM 287 is innovative in the fact
that it begins as a generic object model (for example a COM
container) in which a programmer may add specific functionality
(COM objects) to create a functional interface engine or model that
may execute a timed business procedure according to enterprise
rules.
[0217] Although IPM 287 is, in this case, a loan application
process, such an IPM may be programmed to execute virtually any
conceivable business process that an enterprise may offer as a
wholly or partially automated service to clients. IPM 287, in this
example, is presented as a series of rows and columns comprising
entry fields and return fields in a GANT chart. For example, before
the desired functionality is inserted into IPM 287, it is a generic
COM model that is adaptable via programming for various business
processes and resource interface as previously described. It will
be apparent to those with skill in the art that a COM model and a
GANT form are each simply exemplary of known devices that may be
employed in practicing the invention The format of entry and return
fields presented herein is not required to practice the present
invention. The inventor merely deems this particular format to be
friendly to a programmer building the model and analyzing the
returns such as may be displayed on a computer screen. A tool kit
aids a programmer with building and fine tuning an IPM such as IPM
287. Such a tool kit may be part of the programmers desk-top CINOS
application such as perhaps tool kit 125 of FIG. 4, or may reside
in and be accessible from a server hosting a CINOS Manager
application such as server 77 of FIG. 1.
[0218] FIG. 14 is a GANT chart for a process executable by a CINOS
operating system according to an embodiment of the present
invention. This chart in this embodiment is an interactive input
and display and editing interface wherein a programmer may program
a business process having discrete steps and sub-steps. It will be
apparent to the skilled artisan that such an interface is but one
of a number of interfaces that would be suitable for the purposes
of the invention, and is meant to illustrate features of the
invention. Broadly speaking, by listing steps of a process in this
chart along with parameters to be described more fully below, an
application module is created which, by execution, performs the
process step by step, and tracks completion of individual tasks, as
well as providing reminders when and if allotted completion times
are pending or exceeded, and so forth. It will be apparent to the
skilled artisan that GANT processes may also be illustrated by flow
diagrams (typically PERT charts), and, in a preferred embodiment,
the chart depicted in FIG. 14 may be converted to an editable GANT
flow chart as well. For Example, standard products like MSProject
Planner may be used to generate a PERT or GANT chart, and by using
certain labels both for steps and resources, the generated file may
directly become an IPM Object.
[0219] Referring again to FIG. 14, a title row 289 comprises column
headers and a link to a pop-up editing window that provides for
entering steps and necessary parameters. The pop-up window in a
preferred embodiment has input fields for entering task numbers,
specific action for the task, sequence and pre-requisites related
to other tasks, allotted time to complete, and notification
parameters, as well as a Cancel and a Save function. Through the
input window a programmer can design and relate all tasks and
sub-steps needed for a process.
[0220] Because IPM 287 is a container for COM objects, task objects
may also be loaded as required by the programmer in order to set up
the main and sub-tasks inherent to the process as previously
described such as by drag and drop method as is known in the art.
For example, certain objects or modules to be inserted are for
access to certain data from the IOM, while other objects are
adapted for accessing certain other databases or resources, or for
performing certain process-related functions.
[0221] A variety of notification/command modules may be inserted
into IPM 287 according to possible results or states that may
appear during process execution. The actual module that will be
invoked will depend in part on the programmer, and in part on the
process sequence. Some of the windows are return windows that
return results during execution of the process. These are windows
in the columns labeled time begin, time end, and actual time.
[0222] In this embodiment, as a programmer enters new steps and
sub-steps in building a new application module, the step numbers
with name and generic parameters appear as new rows. When the last
step is entered and configured the GANT chart is complete, and the
process is ready to invoke and execute.
[0223] A completed chart is editable in the sense that steps and
sub-steps may be altered, added, deleted, and the like, along with
names, allotted times, action parameters, and the like. A
programmer may therefore select an existing application module and
edit it to save as a new application module.
[0224] When a module is complete the application created may be
stored and related to other tasks such that the application may be
called whenever necessary to perform functions for the operating
system. Such processing will typically be transparent to agents,
clients, knowledge workers and the like, but on certain occasions,
by need, a chart may be displayed while a process is running or for
other diagnostic purpose.
[0225] In general, building modules (objects) contained in a
programmers tool kit are generic to the basic processes being
created by the enterprise including standard interface and command
objects to other resources or CINOS systems. These building objects
used to program IPM 287 may be provided by the provider of the
CINOS system according to the general type of business and system
architecture used by the enterprise. In one embodiment, an
enterprise programmer may create the building objects according to
desired enterprise functionality and custom CINOS architecture.
Therefore, one CINOS system software package may be provided
specifically for a loan company while another CINOS system software
package may be provided for an investment firm and so on.
[0226] Referring now back to FIG. 14, as a programmer defines steps
and sub-steps as tasks to be performed, he/she is setting up the
main tasks and sub-tasks that the application will perform when
executed. In this particular example, task 1 is a pre-qualification
task for a loan as evidenced by the name Pre-Qual in window 291 in
the Name column.
[0227] Task 1 comprises 3 sub-tasks, namely sub-task 1a, sub-task
1b, and sub-task 1c. Sub-task 1a comprises a module for obtaining
data from a general credit field such as may be stored in a
database and represented via metadata in the IOM described above.
Hence, sub-task 1a would comprise the necessary modules or objects
for interface with the IOM previously described above and for
obtaining general credit data which may be an enterprise rating
system code derived from actual credit reports. Additional related
data may also be accessible in step 1a such as a list of creditors,
payment history, and so on. Step 1b provides access to data about
credit to the enterprise, and step 1c provides access to data about
income such as total monthly income, source of income, etc. In this
way, main task 1 may be completed by executing the sub-tasks
1a-1c.
[0228] In building an IPM such as IPM 287, a goal is to provide an
interfacing process application that may execute and perform an
entire business process from start to end according to CINOS
constraints, time constraints, and enterprise rules. Once
completed, tested, and fine tuned, an IPM such as IPM 287 may be
used as a functional model for the business process that it
represents.
[0229] Column 293 represents a time that each step and sub-step
begins executing within the CINOS system. Numerals illustrated in
column 293 represent units of time expired as the process is
executed. For example, Main task 1 named Pre-Qual begins at 0000
(the time that the application is invoked). A client who is
requesting a loan via telephone or other media may invoke IPM 287
thus beginning it's automated execution while the client waits in
queue. In some embodiments, wherein a client is not live in queue,
an agent may initiate the process based on a not-live request such
as an e-mail or fax. In general the time displayed in windows under
TIME Begin are returns only, based on the actual times related and
previously required steps are completed. That is, typically a task
will not begin at a fixed time from 0000, but will begin as soon as
pre-requisite tasks are all completed.
[0230] Windows in column 295 show the time that a step actually
ends. This is typically a return window as well, and the time
displayed will be the begin time plus the task elapsed time to
completion. The programmer typically allots a time for each task,
and the actual time may be more or less than the allotted time.
Other actions may be invoked in the case that the actual time
exceeds the allotted time.
[0231] All sub-steps under a main task typically are allotted time
increments (according to completion goal) of the allotted time for
the main task such that the their sum equals the time allotted for
the main task. The purpose for allotting time segments for each
task and sub-task is so that efficiency improvements may be pursued
with regards to client waiting and system performance and that
interfaces with other systems such as routing systems or the like
are handled smoothly. The time allotments, as described are in
effect, time goals set by the enterprise. Time modules (not shown)
are COM tools inserted by the programmer.
[0232] Windows in column 297 represents return fields that return
actual elapsed times associated with each task and sub-task. For
example, Main task 1 (Pre-Qual) began at time 0000. Allotted time
for main task 1 is 0010. Main task 1 was actually completed at time
0008 or 0002 ahead of schedule. As is the case with column 295
(Time End), times in which the associated sub-tasks are completed
are increments whose sum equals the actual time for the main task
to obtain completion.
[0233] Windows under column 299 contains notification fields under
the name-field Notify, which is part of title row 289. If there are
no problems in the execution of a task or sub-task then
notification is given to go on to the next task or sub-task.
However, if there are problems in execution such as operation time
out, or insufficient data for return, then a suitable
notification-command may be given to the system such as return to
agent, repeat prior task or sub-task, and so on.
[0234] It is important to note here that according to enterprise
rules, notification may include stopping the process and requesting
human intervention, allowing more allotted time for a task or
sub-task to complete and then repeating the task or sub-task, or
any variety of other options.
[0235] In this example, IPM 287 comprises 4 main tasks of which
main task 1 has already been described. Main task 2 is
determination of loan type. IPM 287 may comprise tasks or sub-tasks
that may be executed in parallel under certain circumstances. Such
is the case with part of main task 2 or more specifically sub-task
2a. For example, choices and data regarding loan type, amounts of
loan, purpose for loan, and the like may be held in a separate
section or database such as product database or the like. Therefore
the multi-taskable IPM 287 may begin main task 2 upon invocation at
time 0000. However, because a sub-task 2b requires the same data
obtained with regards to main task 1, it cannot begin until main
task 1 is complete or at 0008 as indicated in column 293.
[0236] A sub-task 2b1 is depended from sub-task 2b and is a data
sorting operation. An example would be the sorting of assets from
liabilities. Sub-task 2c allows insertion of data on a selected
interactive or multimedia loan application in an automated fashion.
Hence, the first 2 Main tasks and their associated sub-tasks
pre-qualifies a client and obtains and inserts required data into
an interactive application. For the purpose of this example, there
have been no errors or problems with the first 2 main tasks
allowing all notifications to proceed with the process without
human intervention.
[0237] IPM 287 includes a main task 3 for post qualification and
data validation. Such a task may be required according to
enterprise rules with a system recommendation to be returned
regarding weather or not a particular client should qualify. It
should be noted here that a small amount of time elapses between a
main task and a first sub-task with regards to main tasks 1-3 this
is meant by the inventor to show system preparation time to execute
to first sub-tasks.
[0238] Under main task 3, a sub-task 3a validates income. For
example, a client's income data, instead of being current, may be
out of date according to a time constraint imposed by the
enterprise for updating income data in a database. If this is the
case, then a suitable notification may be made to the system. The
process may be temporarily halted due to the notification while an
IVR interacts with the client to provide more current data. After
the client has provided the data, it is updated to the IOM and
sub-task 3a may be repeated. In some embodiments, subsequent tasks
or sub-tasks in a process may be executed while an IVR solicits
more data from the client provided that they are not critically
tied to the problem task or sub-task that could not be
completed.
[0239] A sub-task 3b validates the applicant's source of income,
perhaps by accessing a current database containing employment
records provided by the client's employer. In one embodiment, an
automated out-dialer may be used to contact the employer. When
connection is made, the call may be transfer to an IVR or a live
attendant so that validation may be completed. In some cases this
will take more than the allotted time shown in this example because
human intervention is utilized. In such cases where it is known or
perceived that human intervention will be required, then more time
will be allotted for the planned purpose. However, if the required
data is supplied ahead of the loan application and stored for
access by IPM 287, no human interface will be required.
[0240] Similarly, a sub-task 3c may prompt the client via IVR or
live attendant for inclusion of any added income such as may not be
indicated in data storage such as spousal income, an additional
job-income source, and so on. Such IVR or live attendant
interaction may be part of the loan procedure with appropriate time
allotted to complete such procedures and not specifically the
result of a problem or notification. Therefore, the amount of human
intervention included in a business process such as represented by
IM 287 may be dictated by enterprise rules.
[0241] A sub-task 3d calculates the debt to income ratio and other
required calculations or manipulations of data and then makes a
system recommendation, based on the calculation and enterprise
rules, to the agent to which the client will be transferred for
closing. Hence, the notify field for sub-task 3d is labeled
present. Upon receiving the present notification, the system
forwards the information (completed loan application) to an agent
ahead of the client's call. An interface to the automated routing
system enables IPM 287 to determine which agent will receive the
client out of queue.
[0242] A main task 4 is simply to display, on an agent's graphical
user interface (GUI) a completed copy of the loan application
associated with the client's identification and incoming call. The
notification field returns END at task 4 because it is the end of
the procedure. At this time, a copy of IPM 287 with all of the
fields complete may be sent to the programmer or system
administrator as indicated on a top row comprising the label field
(loan application), Time begin field (0000), Time End field
(00305), Actual Time field (00255), and an update notification
option labeled Update.
[0243] In this example, the actual time of 00255 for completing a
loan application and routing it to an agent is 0005 ahead of the
allotted time or goal time. The programmer may elect to update IPM
287 as the most efficient model yet created thereby using it again
for subsequent applications, or he may elect to fine tune IPM 287
further based on the information provided in the returned
model.
[0244] Each Interactive Process Module created is adapted to
operate with a CISNOS operating system according to the present
invention. As such, each completed module is callable by the OS
when needed to perform its programmed function. Further, each
module is provided with one or more inputs to be able to perform
its function. In the example of qualifying a loan applicant as
described above, the required inputs will be such as (a) potential
borrower's identity, (b) type of loan desired, (c) amount of loan
requested, and (d) payback period requested. Moreover, each module
is adapted to interact with other CINOS modules. For example the
loan qualification application described is adapted to access other
modules, such as the IOM, using the potential borrower's ID as a
key, to recall information, such as income information. Generally
speaking, process modules will have, then, certain commonalties,
such as at least one defining input, a task to be performed based
on input, and a result to be returned, as well as a facility for
returning the result. Such results may in some cases be Yes/No, a
recommendation or the like, and may be either displayed for a
recipient or used as a further input to another Interactive Process
Module.
[0245] It will be apparent to one with skill in the art that one
IPM may be employed for one business process containing various
secondary alterations to the generic process without departing from
the spirit and scope of the preset invention. For example, a
mortgage loan may have differing tasks and sub-tasks than an auto
loan and so on. However, because access to system repositories and
resources are similar in most loan processes regardless of type or
amount of loan, modules may be inserted that cover the options.
Moreover, separate business processes may be run from one IPM as
long as the required modules are present and operational.
[0246] It will further be apparent to one with skill in the art
that the present invention may utilize a convention other than COM
such as by Java applett or the like.
[0247] As previously described, IPM 287 is innovative in part
because a generic application or model may be used for building
several differing automated processes, and because it breaks down a
process into tightly controlled tasks and sub-tasks that are
executed in concert through interface with other CINOS systems. As
a result, complicated business processes may be executed within
CINOS much faster and more efficiently than with prior art systems.
Furthermore, processes may in many instances be wholly automated
and integrated with system routing and other intelligent
services.
[0248] It will be apparent to one with skill in the art that CINOS
may be implemented in a single communication center, or in a
plurality of communication centers linked via WAN without departing
from the spirit and scope of the present invention.
[0249] It will also be apparent to one with skill in the art that
rules may be created which govern access to CINOS without departing
from the spirit and scope of the present invention. For example,
customers may be required to subscribe to CINOS, and may also be
provided with a customer application enabling such access. In
another embodiment, access may be given to the general public
according to established security rules governing commerce,
financial transactions, and other processes.
[0250] There are many existing and future implementation
opportunities for an interaction operating system such as CINOS
many of which have already been stated. The spirit and scope of the
present invention is limited only by the claim that follow.
* * * * *