Note: Descriptions are shown in the official language in which they were submitted.
SYSTEM AND METHOD FOR CALLER VERIFICATION
CROSS-REFERENCE TO RELATED APPLICATION(S)
[0001] This application claims priority from U.S. Provisional Application
No.
63/143,318 filed on January 29, 2021.
FIELD
[0002] This disclosure relates to security systems, in particular, user
authentication or verification of a caller.
BACKGROUND
[0003] Entities receiving calls, for example, call centers for
organizations such as
financial institutions, traditionally use security questions as a means to
verify callers, in
an example, to verify a caller as an account owner. However, security
questions can
pose several risks and problems. For example, many personal security questions
are
easily guessable. Common questions include "What is your birthday?", or "In
what city
did you meet your partner?". Such "milestone" questions are highly insecure,
as many
people post about their birthdays or their partners on social media, which is
easily
accessible to fraudsters.
[0004] Security questions based on an account's information can also be
difficult
for a caller to remember. If a bank asks a caller for details on when they set
up their
savings account or what their last payment was, it can be hard to remember
specifics.
Picking an easier question usually results in the question becoming too easy
for
fraudsters to guess. For example, if the caller lives in a metropolitan area,
and their
insurance company asks them if they have snowmobile insurance, the answer is
probably "no" (and even if they did, a fraudster has a 50% chance of getting a
simple
yes/no question right without knowing the answer).
[0005] Security questions can also be based on a passcode on a caller's
bill.
Callers need to locate their last bill which can be an added frustration.
Visually impaired
1
Date Recue/Date Received 2021-02-26
account owners may have difficulty finding and reading this on their bill, and
family
fraudsters may have access to the account owner's bill.
SUMMARY
[0006] According to an aspect, there is provided a computer-implemented
method for verifying a caller, the method comprising: receiving a unique
identifier from
the caller; identifying an account based at least in part on the unique
identifier; sending
a soft token verification request to an identity provider to send a soft token
push
notification to a device associated with an owner of the account; receiving a
result of the
soft token push notification from the identity provider; and upon the result
of the soft
token push notification being successful, classifying the caller as verified
for the
account.
[0007] In some embodiments, the sending the soft token verification
request is
using an application programming interface (API).
[0008] In some embodiments, the API is a representational state transfer
(REST)
API.
[0009] In some embodiments, the method further comprises serving a web
interface.
[0010] In some embodiments, the serving the web interface is over
Hypertext
Transfer Protocol Secure (HTTPS).
[0011] In some embodiments, the method further comprises displaying the
result
on the web interface.
[0012] In some embodiments, the unique identifier includes one or more of
an
email address, a phone number, or an account number.
[0013] In some embodiments, the method further comprises upon the result
being unsuccessful, sending a notification of the response to a fraud
department.
2
Date Recue/Date Received 2021-02-26
[0014] According to another aspect, there is provided a computer system
comprising: a processor; and a memory in communication with the processor, the
memory storing instructions that, when executed by the processor cause the
processor
to perform a method as disclosed herein.
[0015] According to a further aspect, there is provided a non-transitory
computer-
readable medium having computer executable instructions stored thereon for
execution
by one or more computing devices, that when executed perform a method as
disclosed
herein.
[0016] Other features will become apparent from the following description
and
appendices.
BRIEF DESCRIPTION OF DRAWINGS
[0017] In the figures which illustrate example embodiments,
[0018] FIG. 1 is a schematic diagram of a system for caller verification,
according
to an embodiment;
[0019] FIG. 2 is a high-level architecture diagram of a system for caller
verification including a call center, according to an embodiment;
[0020] FIG. 3 is a flow chart of a method for verifying a caller with a
call center,
according to an embodiment;
[0021] FIG. 4 is a high-level architecture of a system for caller
verification
including Interactive Voice Response (IVR), according to an embodiment;
[0022] FIG. 5 is a flow chart of a method for verifying a caller with
IVR, according
to an embodiment;
[0023] FIGS. 6A-6B illustrate a flow chart of a method of caller
verification via soft
token success with a call center agent, according to an embodiment;
3
Date Recue/Date Received 2021-02-26
[0024] FIGS. 7A-7D illustrate a flow chart of a method of caller
verification via soft
token failure with a call center agent, according to an embodiment;
[0025] FIGS. 8A-8B illustrate a flow chart of a method of caller
verification via soft
token success with IVR, according to an embodiment;
[0026] FIGS 9A-9B illustrate a flow chart of a method of caller
verification via soft
token failure with IVR, according to an embodiment;
[0027] FIGS. 10A-10I illustrate screenshots of a caller verify web
interface,
according to an embodiment;
[0028] FIG. 11 is a flowchart of a method for verifying a caller,
according to an
embodiment;
[0029] FIG. 12 is a block diagram of example hardware components of a
computing device for caller verification, according to an embodiment; and
[0030] FIG. 13 is a heat map illustrating the relative security of soft
tokens, texted
codes, and security questions, according to an embodiment.
DETAILED DESCRIPTION
[0031] In verifying the identity or status of a caller as an account
owner,
organizations such as financial institutions can struggle using traditional
techniques to
prevent and detect fraud. In an example, a family member who knows enough
about the
victim to answer their security questions could call into the financial
institution help desk
and impersonate the victim. The family member could then commit fraud by
having a
wire transfer sent from the victim's account to theirs. Existing solutions to
improve
security can be too time-consuming, too expensive, too insecure, or all three.
[0032] Other traditional caller verification techniques include using PIN
or text
codes, which can also be vulnerable. PINs can be stolen, either by
intercepting SMS
messages intended for a caller, or by executing a SIM swap attack on the
caller.
4
Date Recue/Date Received 2021-02-26
[0033] Existing caller verification systems are vulnerable to compromise
and
attack for a variety of reasons.
[0034] Security questions are vulnerable to social engineering or family
fraud and
are answers are often publicly available on the caller's social media accounts
(such as
birthdate). Security questions place a burden on the caller to remember
responses to
questions that are often challenging for callers with memory issues or elderly
callers.
Security questions are also a burden to the organization, as changes must be
maintained and it is often difficult to port them to new systems, when systems
are
inevitably upgraded or replaced.
[0035] SMS (text message) verification is vulnerable to SIM swap attacks
that
occur when a bad actor steals a phone number from the rightful owner by
impersonating
them on a call with the telecom that provides service to the phone number. SMS
(text
message) notifications are also vulnerable to being intercepted by spyware or
monitoring applications on a caller's phone. This is a particular concern with
family
fraud, as family fraudsters often have access to seeing SMS notifications
displayed on
the victim's devices. Furthermore, text message codes may be difficult to read
for
visually challenged callers.
[0036] Existing solutions have a significant amount of friction for the
caller, who
may get frustrated typing codes into the phone or having to remember
forgettable or
changing security questions. This encourages callers to follow poor practices
such as
writing down codes and security answers, or setting weak codes or security
answers
that are easy to guess. This feedback loop leaves callers more vulnerable to
phishing or
fraud by encouraging them to weaken their own security posture.
[0037] A system and method for caller verification, as disclosed herein,
may
ensure that callers are who they say they are, for example, account owners.
This may
be achieved in some embodiments using a secure factor (a soft token) as a
secure
factor of authentication on the caller's online and mobile banking platforms)
to a call
center so that callers have a consistent, secure and easy experience. A video
explainer
Date Recue/Date Received 2021-02-26
outlining an overview of an embodiment can be found at:
https://www.youtube.com/watch?v=Gyds71JytZo.
[0038] Embodiments as disclosed herein may allow for a caller's identity
to be
securely and easily verified when they phone an organization, to prevent the
caller from
making any changes to an account owner's account if they are not the rightful
account
owner.
[0039] Embodiments as disclosed herein provide a new combination of a
security
concept and a novel process, combining the security of a soft token
verification and a
novel process of verifying callers to a call center, an Interactive Voice
Response (IVR)
or an automated telephony system.
[0040] Soft tokens are a form of authentication token traditionally used
in a first-
party process, where users verify themselves signing on to a computer or
similar
device. Soft tokens have not previously been applied in a third-party call
center or IVR
process where callers are verified via third-party interaction as disclosed
herein.
[0041] This new process of caller verification disclosed in embodiments
disclosed
herein introduces soft token verification via the third-party interaction with
a call center
agent or IVR. This verification is facilitated by embodiments of caller verify
as disclosed
herein. This unique process marries the security concept of soft tokens with
the need
for verifying callers to a call center or IVR.
[0042] Embodiments as disclosed herein may address some of the time-
consuming and interoperability issues of existing solutions by:
= Having callers use a secure soft token to verify their identity. The
token is not
vulnerable to SIM swap attacks as SIM swapping only gets a fraudulent caller
the
phone number, not the contents of the phone. The secure token application also
does not transmit an SMS signal and isolates it from being scraped or
recorded,
making it resistant to spyware applications on the phone itself.
6
Date Recue/Date Received 2021-02-26
= Providing a lightweight interoperable service that can be connected to an
organization's current identity provider via API. This reduces the
organization's
barrier to adopting more secure caller verification for callers by reducing
the cost
and labor involved in implementing secure verification.
= Embodiments disclosed herein can be highly accessible. Soft token
applications
are usually free and widely available. They are easy to use for callers who
are
visually impaired or memory impaired. Soft tokens offer consistency of
experience as callers can use the same soft token they use with embodiments
disclosed herein, on their online or mobile experiences with the
organization's
other applications.
= A caller can be verified using embodiments disclosed herein in under 30
seconds
whereas text code or security question verification can take 2 -10 minutes.
This
facilitates time savings for both the caller and organization, as well as cost
savings for the organization.
= Caller friction can be reduced by embodiments disclosed herein as the
caller
does not have to remember answers to security questions or be frustrated by
entering awkward text codes.
[0043] Embodiments of a system and method for caller verification as
disclosed
can make both organizations and callers more secure, while being easy for both
to use.
It places secure verification in the reach of all organizations.
[0044] FIG. 1 is a schematic diagram of a system 100 for caller
verification, for
example, to confirm that a caller such as a user 101 is an account owner, to
allow them
access to account information and changes, according to an embodiment.
[0045] As shown in FIG. 1, system 100 can include a local device 102
associated
with an account user, who may or may not be the same individual as user 101, a
call
receiver 104, a caller verify 106, and an identity provider (IDP) 108. User
101 can be in
communication with call receiver 104, for example using local device 102 or
other
suitable device, by way of plain old telephone service (POTS) or Public
Switched
7
Date Recue/Date Received 2021-02-26
Telephone Network (PSTN), Voice over IP (VOIP) or other suitable communication
protocol, for example, for voice telephony. Call receiver 104, caller verify
106, IDP 108
and local device 102 can be in communication by way of a suitable network, for
example, be a packet-switched network, in the form of a LAN, a WAN, the public
Internet, a Virtual Private Network (VPN) or the like.
[0046] Local device 102 is a computing device associated with user 101.
[0047] Local device 102, may be, for example, a mobile device. Example
mobile
devices include without limitation, cellular phones, cellular smart-phones,
computers,
laptops, handheld wireless communication devices, wirelessly enabled notebook
computers, tablet computers, or any other portable electronic device with
processing
and communication capabilities, for example, with the ability to download and
manage
soft token applications. In one example, computing device 102 may be a
smartphone.
[0048] Call receiver 104 can be human agent, embodied as call center 114,
or an
interactive voice response (IVR) 124, or a combination of both. IVR 124 can be
an
automated telephony system that interacts with callers such as user 101,
gathers
information, and routes calls to the appropriate recipients.
[0049] Embodiments of caller verify 106 include a user interface or web
interface
116 and an application programming interface (API), an interface that defines
interactions between multiple software systems. In an example, caller verify
106
includes a Representational State Transfer (REST) API 126, a software
architecture for
interactive applications.
[0050] In some embodiments, web interface 116 is a lightweight, cloud-
hosted
user interface for use by call center agents of call center 114. Web interface
116 can be
built in Python and based on the Flask web application framework, or other
suitable
application framework. A widget is another way the concept can be extended.
[0051] In some embodiments, web interface 116 is built as a single page
web
application from which call center agents at call center 114 may verify a
caller or access
8
Date Recue/Date Received 2021-02-26
an account owner's account in the Organization's Identity Provider (IDP) to
make
changes.
[0052] In some embodiments, web interface 116 is hosted on cloud
infrastructure
which provides availability, scalability, and network access security.
[0053] Hosting for web interface 116 may be provided by cloud providers
in
containers which can be geographically localized to provide improved
connectivity to
clients and integrated services and provide scalability, as web interface
containers can
be automatically scaled up or out depending on the needs of the client and to
support
high traffic spikes.
[0054] A cloud infrastructure can also provide network access security by
supporting access restrictions and WAF (web application firewall) rules to
target specific
access to network segments. In an example, only designated staff may be
allowed to
access the web interface from the corporate network.
[0055] Caller verify 106 can include an API such as REST API 126. REST
API
126 may utilize several technologies to ensure that only validated requests
are
permitted. In some embodiments, REST API 126 is protected with an access
token. A
valid 0Auth 2.0 access token may be used to authenticate an agent at call
center 114
or a service application, provided by the identity provider during
authentication. The
access token audience may authenticate by matching the client ID associated
with IDP
108.
[0056] Conveniently, embodiments of caller verify 106 may allow for easy
integration to an IVR 124, which can be an IVR systems such as Genesys via
Genesys
API (Application Programming Interface) endpoints, as well as integration to
IDP 108,
such as Okta and PING Federate by implementing the IDP's APIs to send factor
prompts and parse responses.
[0057] Caller verify 106 may also support integration with an
organization's multi-
factor authentication (MFA) policies to secure access from call receiver 104,
such as
9
Date Recue/Date Received 2021-02-26
agents at a call center 114, to the application. This is typically handled via
a widget or
API provided by an IDP.
[0058] Caller verify 106 may support integration with publicly available
third party
tokens, and soft tokens/authenticator applications, such as those freely
available on
Google Play or the Apple Store.
[0059] Tokens used with caller verify 106 may be customizable, and in an
example, may be selected by an organization using it. In some embodiments,
soft
tokens used with caller verify 106 may be branded and customized if the soft
token
supports such customizations. For example, instead of the soft token message
to the
caller saying: "did you just try to log in", the message may be customized to
say: "Did
you just try to verify yourself at your friendly-neighborhood bank?"
[0060] In some embodiments, caller verify 106 logs all verification
events in
accordance with security and audit best practices.
[0061] In some embodiments, caller verify 106 does not store any P11
(personally
identifying information) of a user 101 or account owner, and only shows the
minimum
Personally Identifiable information (PII) necessary to identify user 101.
[0062] IDP 108 can be used to store account owner profiles, and in some
embodiments can be a third-party tool. Examples of possible identity providers
are Okta
or PING Federate.
[0063] IDP 108 may implement soft token authentication for use with local
device
102 associated with user 101 to authenticate local device 102, and thus user
101. Soft
token authentication can provide multi-factor authentication. A soft token
differs from a
hard token which is a physical device, whereas a soft token is provided using
installed
software or applications (usually on a smart phone such as local device 102).
Soft token
authenticators can be freely available applications on Google Play or Apple
Store that
securely authenticate a user.
Date Recue/Date Received 2021-02-26
[0064] A soft token/authenticator application may provide improved
security than
email, text message, or phone call PINs. Use of these authenticators is
recommended
by the National Institute of Standards and Technology (NIST), among others,
(Paul A.
Grassi, 2017). NIST is a non-regulatory agency of the US Department of
Commerce.
NIST supplies industry, academia, and government with standards for key
operations,
including cybersecurity standards.
[0065] Soft token authenticators may be advantageous since soft token
applications are tied to a particular installation on a specific device and
not to a phone
number that can be moved or ported; transmissions to soft token applications
are
encrypted, which increases their security and reduces the risk of a PIN being
intercepted by spyware; soft token applications will only accept a push once
per
authentication to prevent replay attacks. A replay attack is a form of network
attack in
which valid data transmission is maliciously or fraudulently repeated or
delayed.
[0066] FIG. 2 illustrates a high-level architecture of system 100 having
call center
114, and interaction or work flows between a user 101 attempting to access an
account,
call center 114, caller verify 106, the account owner (who may be user 101),
and a soft
token registered with the account in IDP 108, according to an embodiment.
[0067] At work flow 201, user 101, a caller, phones into call center 114
and a call
center agent answers.
[0068] At work flow 202, the call center agent navigates to caller verify
106 to
retrieve the account profile via a unique attribute provider by user 101 (for
example,
phone number, email, account number, etc.). In some embodiments, caller verify
106
web interface 116 is served over Hyper Text Transfer Protocol Secure (HTTPS)
(port
443) network protocol that is used to request, navigate, and deliver web
content (such
as web pages, web applications, APIs, etc.).
[0069] At work flow 203, caller verify 106 communicates with IDP 108
using an
exposed REST API 126 to retrieve the account profile. In some embodiments,
REST
API 126 is served over HTTPS (port 443).
11
Date Recue/Date Received 2021-02-26
[0070] At work flow 204, caller verify 106 communicates with IDP 108
using
exposed REST API 126 to trigger a soft token verification request to the
account
owner's registered local device 102, such as a cell phone.
[0071] At work flow 205, a push notification as an automated message sent
by an
application to a user when the application is not open, which may be easy to
use, for the
soft token verification is sent to local device 102 for display on local
device 102, for
example, the account owner's registered cell phone. The account owner can
respond to
the soft token verification on local device 102, in an example, by selecting
either [YES]
or [NO].
[0072] FIG. 3 illustrates a flow chart of a method 300 for verifying a
caller
performed, in an example, by components of system 100 including call center
114,
according to an embodiment. The steps are provided for illustrative purposes.
Variations
of the steps, omission or substitution of various steps, or additional steps
may be
considered. It should be understood that one or more of the blocks may be
performed in
a different sequence or in an interleaved or iterative manner.
[0073] At block 301, an account owner has registered a soft token as the
factor of
authentication in IDP 108.
[0074] At block 302, a caller, such as user 101, phones call center 114.
[0075] At block 303, a human call center agent at call center 114 asks
user 101
for their email address, phone number, account number, or other unique
identifier.
[0076] At block 304, call center 114 enters the unique identifier in
caller verify 106
interface, and retrieves the account information.
[0077] At block 305, the call center agent uses caller verify 106
interface to
trigger a push notification to the account owner, requesting that they verify
that they are
trying to access their account.
12
Date Recue/Date Received 2021-02-26
[0078] At block 306, if the account owner confirms that they are trying
to access
their account, for example, by pressing [YES] on the push notification, the
call center
agent can move on to helping them with what they called in about.
[0079] At block 307, if the account owner denies that they are trying to
access
their account, for example, by pressing [NO] on the push notification or
ignoring it, the
call center agent does not allow the caller to access or change the account.
[0080] FIG. 4 illustrates a high-level architecture of system 100 having
IVR 124,
illustrating interaction between a user 101 attempting to access an account,
IVR 124,
caller verify 106, the account owner (who may be user 101), and a soft token
registered
with the account in the identity provider, according to an embodiment.
[0081] At work flow 401, a caller, such as user 101, phones into a call
center and
IVR 124 answers.
[0082] At work flow 402, IVR 124 communicates with caller verify 106
using
exposed REST API 126 to retrieve the account profile. REST API 126 is served
over
HTTPS (port 443).
[0083] At work flow 403, IVR 124 communicates with caller verify 106
using
exposed REST API 126 to trigger a soft token verification request to the
account
owner's registered cell phone, such as local device 102.
[0084] At work flow 404, an easy to use, accessible push notification for
the soft
token verification is displayed on local device 102. The account owner
responds to the
soft token verification on local device 102, in an example, by selecting
either [YES] or
[NO].
[0085] IVR 124 can then communicate with caller verify 106 using exposed
REST
API 126 to retrieve the result of the soft token verification.
[0086] FIG. 5 illustrates a flow chart of a method 500 for verifying a
caller
performed, in an example, by components of system 100 including IVR 124,
according
to an embodiment. The steps are provided for illustrative purposes. Variations
of the
13
Date Recue/Date Received 2021-02-26
steps, omission or substitution of various steps, or additional steps may be
considered.
It should be understood that one or more of the blocks may be performed in a
different
sequence or in an interleaved or iterative manner.
[0087] At block 501, an account owner has registered a soft token as the
factor of
authentication in IDP 108.
[0088] At block 502, a caller, such as user 101, phones IVR 124
(automated
phone system) and IVR 124 verifies that user 101 is calling from the number
associated
with the requested account or prompts user 101 for a unique identifier.
[0089] At block 503, IVR 124 sends a communication to caller verify 106
to
trigger a push notification to the account owner, requesting that the account
owner
verifies that they are trying to access their account.
[0090] At block 504, the account owner receives a notification on local
device
102, such as a smartphone, with a soft token of authentication.
[0091] At block 505, if the account owner confirms that they are trying
to access
their account, in an example, by pressing [YES] on the push notification, IVR
124 can
then allow user 101 to make changes to their account.
[0092] At block 506, if the account owner denies that they are trying to
access
their account, in an example, by pressing [NO] on the push notification or
ignoring it,
IVR 124 may then deny any changes to the requested account.
[0093] FIGS. 6A-6B illustrate a flow chart of a method 600 of caller
verification via
soft token success with a call center agent, in an embodiment. FIGS. 7A-7D
illustrate a
flow chart of a method 700 of caller verification via soft token failure with
a call center
agent, in an embodiment. FIGS. 8A-8B illustrate a flow chart of a method 800
of caller
verification via soft token success with IVR, in an embodiment. FIGS. 9A-9B
illustrate a
flow chart of a method 900 of caller verification via soft token failure with
IVR, in an
embodiment.
14
Date Recue/Date Received 2021-02-26
[0094] Methods 600, 700, 800 and 900 can be performed, in an example, by
components of system 100 as disclosed herein. Actors of methods 600, 700, 800
and
900 and associated goals, are described by way of example below.
[0095] A Caller may be a person who phones the Organization for the
purpose of
making changes to an account they claim to own, and their goal may be to make
changes to the account that they claim to own.
[0096] A Call Center may be the place of employment for the Call Center
Agent,
where a group of human workers answer calls and make changes to accounts if
the
Caller is successfully verified as the rightful Account Owner, and their goal
may be to
facilitate rightful Account Owners accessing their account(s).
[0097] An IVR may be an automated telephony system, its goal to automate
call
center workflow.
[0098] An IDP is an Identity Provider, and may be a 3rd party tool used
that is the
authoritative source of Account Owner profiles including attributes like:
first name, last
name, phone number, email address. Caller Verify makes calls to the IDP in the
course
of identifying the user. The IDP can trigger soft token via push notifications
to verify that
the Caller trying to authenticate is who they say they are. Examples of
possible IDP are
solutions like OKTA or PING Federate. Goals of the IDP may be to act as the
authoritative source for Account Owner attributes such as first name, last
name, cell
phone number, and email address; act as a source of registration of soft
tokens to
rightful Account Owners (outside the scope of these use cases but exists as a
functional
process pre-condition); and trigger soft token push notifications and verify
the response
to those notifications.
[0099] An Account Owner may be a person who is the rightful owner of the
account that the Caller wants to make changes to, and their goal may be to use
a soft
token verification to protect unauthorized access to their account.
[00100] A Call Center Agent may be a person who works in the
Organization's Call
Center answering phone calls and has access to the Caller Verify Interface,
and their
Date Recue/Date Received 2021-02-26
goals may be to use Caller Verify to ensure they only allow rightful Account
Owners to
make changes to their account; optionally notify a fraud department if an
unauthorized
Caller is trying to access an account; assist the Caller in the most efficient
and secure
way possible.
[00101] An Organization may be a Company, Non-profit or other entity that
hosts
the account the Caller wants to modify and owns the IVR or Call Center that
the Caller
calls into, and their goals may be to reduce fraud by ensuring Callers are
only permitted
to make changes to account(s) of which they are the rightful owner; mitigate
risk of a
breach by ensuring Callers are only permitted to make changes to account(s) of
which
they are the rightful owner; provide a low friction experience to their
Account Owners;
meet audit requirements and meet or exceed the security standards to which
their
industry is held accountable.
[00102] A Caller Verify may be an embodiment of caller verify 106, to
facilitate a
process by which a Caller is verified using a soft token that the Account
Owner has
previously registered to their profile in the IDP, the goals may be to inform
the Call
Center Agent OR the IVR if a Caller is the rightful Account Owner or not and
to verify
Callers in the most efficient and secure way possible.
[00103] Turning to FIGS. 6A-6B, method 600 is illustrated for caller
verification via
soft token success performed, in an example, by components of system 100
including a
call center agent, according to an embodiment. The steps are provided for
illustrative
purposes. Variations of the steps, omission or substitution of various steps,
or additional
steps may be considered. It should be understood that one or more of the
blocks may
be performed in a different sequence or in an interleaved or iterative manner.
[00104] As shown in FIGS. 6A-6B, Caller phones into a Call Center and the
answering Call Center Agent asks the Caller for a unique identifier to search
for account
(phone, email, account number, etc.). The Call Center prompts the Caller to
verify they
own the account they are calling about. The Account Owner touches the [YES]
button
on the soft token application on their smart phone. After this successful
verification that
16
Date Recue/Date Received 2021-02-26
the Caller is the rightful Account Owner, the Caller is permitted to make
changes to the
account.
[00105] A precondition may be that Account Owner has registered their
profile in
the identity provider (IDP) with a soft token.
[00106] A success guarantee may be that Caller is successfully verified as
the
rightful Account Owner with their soft token and permitted to make changes to
the
account as a result.
[00107] A main success scenario for method 600 is described below. Account
Owner has registered their profile in the identity provider (IDP) with a soft
token.
[00108] At block 601, Caller phones Call Center.
[00109] At block 602, Call Center Agent answers Caller.
[00110] At block 603, Call Center Agent asks the Caller for account
identifier
(phone, email, or account number).
[00111] At block 604, Call Center Agent uses Caller Verify Interface to
find the
Account Owner using the unique identifier provided by the Caller. FIG. 10A
illustrates a
screenshot 1002 of web interface 116 of caller verify 106, prompting a login
for a call
center agent, in an embodiment. FIG. 10B illustrates a screenshot 1004 of a
sign in
page and FIG. 10C illustrates a screenshot 1006 of a prompt for soft token
authentication for the call center agent. FIG. 10D illustrates a screenshot
1008 of entry
of the unique identifier, in this example, a primary email address.
[00112] At block 605, Call Center Agent uses Caller Verify Interface to
trigger a
soft token verification request to the Account Owner's cell phone number on
record.
FIG. 10E illustrates a screenshot 1010 of a lookup of the caller or account,
and an
action option. FIG. 1OF illustrates a screenshot 1012 of options for
authentication verify
the account, including, by way of example, Okta Verify Push, Okta Verify TOTP,
and
Google Authenticator, which can be MFA from the perspective of IDP 108 that
can use
both password and second factor to authenticate users in their online
experience.
17
Date Recue/Date Received 2021-02-26
[00113] At block 606, Caller Verify contacts IDP to send soft token push
notification. FIG. 10G illustrates a screenshot 1014 of selection of "Okta
Verify Push",
and a screenshot of a push notification received at local device 102.
[00114] At block 607, Account Owner receives soft token push notification.
FIG.
10H illustrates a screenshot 1016 of web interface 116 awaiting response from
the push
notification, and a screenshot of the push notification at local device 102.
[00115] At block 608, Account Owner presses [YES] to verify they are the
Caller.
[00116] At block 609, Caller Verify displays the successful verification
response on
the Caller Verify Interface. FIG. 101 illustrates a screenshot 1018 of a
confirmation of
push notification successfully verified.
[00117] At block 610, Caller Verify displays successful verification
response on
Interface for Call Center Agent.
[00118] At block 611, Call Center Agent proceeds with assisting Caller.
[00119] At block 612, control ends. Caller is successfully verified as the
rightful
Account Owner with their soft token and permitted to make changes to the
account as a
result.
[00120] Turning to FIGS. 7A-7D, method 700 is illustrated for caller
verification via
soft token failure performed, in an example, by components of system 100
including a
call center agent, according to an embodiment. The steps are provided for
illustrative
purposes. Variations of the steps, omission or substitution of various steps,
or additional
steps may be considered. It should be understood that one or more of the
blocks may
be performed in a different sequence or in an interleaved or iterative manner.
[00121] As shown in FIGS. 7A-7D, Caller phones into a Call Center and a
Call
Center Agent answers and prompts the Caller to verify they own the account
they are
calling about. The Account Owner touches the [NO] button on the soft token
application. After this failed verification, the Caller is NOT permitted to
make changes to
the account.
18
Date Recue/Date Received 2021-02-26
[00122] A precondition may be that Account Owner has registered their
profile in
the identity provider (IDP) with a soft token.
[00123] A success guarantee may be that Caller fails to be verified with
the rightful
Account Owner's soft token and is NOT permitted to make changes to the
account.
[00124] A main success scenario for method 700 is described below. Account
Owner has registered their profile in the identity provider (IDP) with a soft
token.
[00125] At block 701, Caller phones Call Center.
[00126] At block 702, Call Center Agent answers Caller.
[00127] At block 703, Call Center Agent asks Caller for account identifier
(phone,
email, or account number).
[00128] At block 704, Call Center Agent enters account identifier in
Caller Verify
Interface.
[00129] At block 705, Caller Verify calls IDP to retrieve Account Owner's
profile.
[00130] At block 706, Call Center Agent uses Caller Verify Interface to
trigger a
soft token verification request to the Account Owner's cell phone number on
record.
[00131] At block 707, Caller Verify contacts IDP to send a soft token push
notification.
[00132] At block 708, Caller Verify polls and waits for verification
response.
[00133] At block 709, Account Owner receives soft token push notification.
[00134] At block 710, Account owner presses [NO] to verify they are NOT
the
Caller.
[00135] If the Account Owner takes no action, control proceeds to block
721 as an
extension. Otherwise, control proceeds to block 711.
19
Date Recue/Date Received 2021-02-26
[00136] At block 721, the request times out.
[00137] At block 722, Caller Verify displays the failed verification
response and
displays in Caller Verify interface.
[00138] At block 723, Call Center Agent declines to make changes to the
Account
Owner's profile.
[00139] At block 724, optionally Call Center Agent alerts fraud
department.
[00140] At block 725, control ends.
[00141] Returning to block 711, Caller Verify displays the failed response
on the
Caller Verify Interface.
[00142] At block 712, Call Center Agent sees failed verification and
declines to
make changes to the Account Owner's account.
[00143] At block 713, optionally Call Center Agent notifies fraud
department.
[00144] At block 714, control ends. Caller fails to be verified with the
rightful
Account Owner's soft token and is not permitted to make changes to the
account.
[00145] Turning to FIGS. 8A-8B, method 800 is illustrated for caller
verification via
soft token success performed, in an example, by components of system 100
including
an IVR, according to an embodiment. The steps are provided for illustrative
purposes.
Variations of the steps, omission or substitution of various steps, or
additional steps
may be considered. It should be understood that one or more of the blocks may
be
performed in a different sequence or in an interleaved or iterative manner.
[00146] As shown in FIGS. 8A-8B, Caller phones into an Organization and an
IVR
(automated telephony system) prompts the Caller to verify they own the account
they
are calling about. The Account Owner touches the [YES] button on the soft
token
application. After this successful verification that the Caller is the
rightful Account
Owner, the Caller is permitted to make changes to the account.
Date Recue/Date Received 2021-02-26
[00147] A precondition may be that Account Owner has registered their
profile in
the identity provider (IDP) with a soft token.
[00148] A success guarantee may be that Caller is successfully verified as
the
rightful Account Owner with their soft token and permitted to make changes to
the
account as a result.
[00149] A main success scenario for method 800 is described below. Account
Owner has registered their profile in the identity provider (IDP) with a soft
token.
[00150] At block 801, Caller phones Organization.
[00151] At block 802, IVR answers Caller.
[00152] At block 803, IVR prompts Caller for account identifier (phone or
account
number).
[00153] At block 804, IVR contacts Caller Verify to initiate verification
process.
[00154] At block 805, Caller Verify contacts IDP to send soft token
verification to
the cell phone associated to the account.
[00155] At block 806, IVR polls and waits for verification response.
[00156] At block 807, Account Owner receives verification prompt on their
phone.
[00157] At block 808, Account Owner presses [YES] to verify they are the
Caller.
[00158] At block 809, IDP passes successful verification to Caller Verify.
[00159] At block 810, Caller Verify passes successful verification to IVR.
[00160] At block 811, Caller passes to the next step in the IVR workflow
to make
changes to the account via self-service or via transfer to a human agent.
21
Date Recue/Date Received 2021-02-26
[00161] At block 812, control ends. Caller is successfully verified as the
rightful
Account Owner with their soft token and permitted to make changes to the
account as a
result.
[00162] Turning to FIGS. 9A-9B, method 900 is illustrated for caller
verification via
soft token failure performed, in an example, by components of system 100
including an
IVR, according to an embodiment. The steps are provided for illustrative
purposes.
Variations of the steps, omission or substitution of various steps, or
additional steps
may be considered. It should be understood that one or more of the blocks may
be
performed in a different sequence or in an interleaved or iterative manner.
[00163] As shown in FIGS. 9A-9B, Caller phones an Organization and an IVR
(automated telephony system) prompts the Caller to verify they own the account
they
are calling about. The Account Owner touches the [NO] button on the soft token
application. After this failed verification, the Caller is not permitted to
make changes to
the account.
[00164] A precondition may be that Account Owner has registered their
profile in
the identity provider (IDP) with a soft token.
[00165] A success guarantee may be that Caller fails to be verified with
the rightful
Account Owner's soft token and is NOT permitted to make changes to the account
as a
result.
[00166] A main success scenario for method 900 is described below. Account
Owner has registered their profile in the identity provider (IDP) with a soft
token.
[00167] At block 901, Caller phones Organization.
[00168] At block 902, IVR answers Caller.
[00169] At block 903, IVR prompts Caller for account identifier (phone or
account
number).
22
Date Recue/Date Received 2021-02-26
[00170] At block 904, IVR contacts Caller Verify which triggers a soft
token
verification to the cell phone registered to the account.
[00171] At block 905, IVR polls and waits for verification response.
[00172] At block 906, Account Owner receives push notification.
[00173] At block 907, Account Owner presses [NO] to indicate they are NOT
the
Caller.
[00174] If the Account Owner takes no action, control flow proceeds to
block 911.
Otherwise, control flow proceeds to block 908.
[00175] At block 911, the verification request times out.
[00176] At block 912, IVR receives the failed verification response.
[00177] At block 913, Caller does NOT pass to the next step in the IVR
workflow
and is NOT allowed to make changes to the account.
[00178] At block 914, control ends.
[00179] Returning to block 908, IVR receives the failed verification
response.
[00180] At block 909, Caller does NOT pass to the next step in the IVR
workflow
and is NOT allowed to make changes to the account.
[00181] At block 910, control ends. Caller fails to be verified with the
rightful
Account Owner's soft token and is not permitted to make changes to the account
as a
result.
[00182] FIG. 11 illustrates an embodiment of a method 1100 for verifying a
caller
performed, in an example, by components of system 100. The steps are provided
for
illustrative purposes. Variations of the steps, omission or substitution of
various steps,
or additional steps may be considered. It should be understood that one or
more of the
23
Date Recue/Date Received 2021-02-26
blocks may be performed in a different sequence or in an interleaved or
iterative
manner.
[00183] At block 1101, caller verify 106 receives a unique identifier from
the caller,
for example, by way of call center 114 or IVR 124.
[00184] In some embodiments, the unique identifier includes one or more of
an
email address, a phone number, or an account number.
[00185] At block 1102, caller verify 106 identifies an account based at
least in part
on the unique identifier.
[00186] At block 1103, caller verify 106 sends a soft token verification
request to
an identity provider, such as IDP 108, to send a soft token push notification
to a device
associated with an owner of the account, such as local device 102.
[00187] In some embodiments, the sending the soft token verification
request is
using an application programming interface (API).
[00188] In some embodiments, the API is a representational state transfer
(REST)
API.
[00189] At block 1104, caller verify 106 receives a result of the soft
token push
notification from the identity provider.
[00190] At block 1105, upon the result of the soft token push notification
being
successful, caller verify 106 classifies the caller as verified for the
account.
[00191] In some embodiments, method 1100 further includes serving a web
interface. In some embodiments, the serving the web interface is over
Hypertext
Transfer Protocol Secure (HTTPS). In some embodiments, method 1100 further
includes caller verify 106 displaying the result on the web interface.
24
Date Recue/Date Received 2021-02-26
[00192] In some embodiments, method 1100 further includes upon the result
being
unsuccessful, caller verify 106 sending a notification of the response to a
fraud
department.
[00193] System 100 for caller verification, or one or more components
thereof,
including local device 102, call receiver 104, caller verify 106, and IDP 108,
may be
implemented as software and/or hardware, for example, in one or more computing
device(s) 1200 as illustrated in FIG. 12. Method 1100, in particular, one or
more of
blocks 1101 to 1105, may be performed by software and/or hardware of one or
more
computing device(s) such as computing device 1200.
[00194] FIG. 12 is a high-level block diagram of computing device 1200.
Computing device 1200, under software control, may perform caller
verification.
[00195] As illustrated, computing device 1200 includes one or more
processor(s)
1210, memory 1220, a network controller 1230, and one or more I/O interfaces
1240 in
communication over bus 1250.
[00196] Processor(s) 1210 may be one or more Intel x86, Intel x64, AMD x86-
64,
PowerPC, ARM processors or the like.
[00197] Memory 1220 may include random-access memory, read-only memory, or
persistent storage such as a hard disk, a solid-state drive or the like. Read-
only memory
or persistent storage is a computer-readable medium. A computer-readable
medium
may be organized using a file system, controlled and administered by an
operating
system governing overall operation of the computing device.
[00198] Network controller 1230 serves as a communication device to
interconnect
the computing device with one or more computer networks such as, for example,
a local
area network (LAN) or the Internet.
[00199] One or more I/O interfaces 1240 may serve to interconnect the
computing
device with peripheral devices, such as for example, keyboards, mice, video
displays,
Date Recue/Date Received 2021-02-26
and the like. Such peripheral devices may include a display of device 1200.
Optionally,
network controller 1260 may be accessed via the one or more I/O interfaces.
[00200] Software instructions are executed by processor(s) 1210 from a
computer-
readable medium. For example, software may be loaded into random-access memory
from persistent storage of memory 1220 or from one or more devices via I/O
interfaces
1240 for execution by one or more processors 1210. As another example,
software may
be loaded and executed by one or more processors 1210 directly from read-only
memory.
[00201] Example software components and data stored within memory 1220 of
computing device 1200 may include software to perform caller verification, as
disclosed
herein, and operating system (OS) software allowing for basic communication
and
application operations related to computing device 1200.
[00202] Traditional run-of-the-mill security questions make fraudulent
impersonation more common than ever. With embodiments of the system and method
of caller verification disclosed herein, bad actors may be prevented from
accessing an
organization's users' confidential information. Embodiments disclosed herein
send a
push notification to the account owner's phone, so if the account owner is not
trying to
access their account they can press [NO] or ignore it, and only the real
account owner
may be able to verify their account.
[00203] Conveniently, the simplicity of the one touch verification makes
the
process accessible to callers with technical, memory or visual challenges.
Embodiments
disclosed herein may be more secure than the traditional methods of verifying
callers
via security questions, PINs, passwords or text messages. Soft tokens may
provide an
increased level of security over traditional techniques such as texted codes
or security
questions, as illustrated in the heat map of FIG. 13, illustrating the
relative security of
soft tokens, texted codes, and security questions, according to an embodiment.
[00204] Embodiments may extend the superior security of soft tokens to
callers
accessing their accounts via phone, where callers were previously verified by
insecure
26
Date Recue/Date Received 2021-02-26
methods such as being asked easily guessable security questions. Current
security
questions often include things like "What is your address?", "What is your
birthday?" and
other basic facts about a caller that can easily be found by fraudsters on
social media or
public records.
[00205] Embodiments may also improve the caller experience. Currently,
callers
are subjected to answering a barrage of security questions. These questions
tend to be
easily guessable, or so obscure that even the rightful account owner may not
even
know the answer to them. (e.g. When was the anniversary of when we sent you
your
first credit card?").
[00206] In some embodiments, verification time may be reduced to under a
minute, so customers can be assisted in record time (as compared to time it
takes
answering many verification questions).
[00207] In some embodiments, caller verification may be more accessible to
callers who struggle with technology or are partially visually impaired. The
ease of the
solution may reduce the hurdle to callers that struggle with technology, as it
is a one
touch solution.
[00208] In a circumstance in which a caller loses their phone or local
device they
may not be able to authenticate with their phone. Once the account holder
registers a
soft token on their new device to the organization's Identity Provider (IDP)
this would be
resolved. In the event a caller is not able to register a soft token before
they have to call
in, they may have challenges verifying. It is recommended that the
organization have a
procedure to verify the caller via traditional means like security questions
as a backup.
[00209] Account owners may require a soft token registered with the IDP to
use
Caller Verify. There is a short registration process to associate the soft
token to the
Account Owner's profile in the Identity Provider (IDP). This can be mitigated
by
customer service assisting the caller on initial registration and by clear
instructions and
documentation from the Organization. Documentation and instructional videos on
the
registration process can be provided to facilitate this process for
Organizations.
27
Date Recue/Date Received 2021-02-26
[00210] Some of the use cases for embodiments of the system and method for
caller verification disclosed herein include:
= Verifying the identity of a Caller who is phoning a Call Center to make a
high-risk
change to their account at a financial institution. For example, to verify
that
Callers phoning in are who they say they are when they make major transactions
or changes. Such transactions may include making changes to their banking
information, wire transfers, or major payments. This may protect the financial
institution from issues with family fraud, in which a family member who knew
the
answers to an elderly relative's security question would request transfers and
access by posing as the Account Owner.
= Verifying the identity of a Caller being serviced in a wealth management
advisory
session over phone or video conference. With the COVID-19 pandemic, many
such services have gone virtual. As wealth management discussions typically
deal with sensitive, high-value financial matters, it's imperative that the
advisor
knows that the person on the other end of the call is who they say they are.
[00211] Additional use cases for embodiments of the system and method for
caller
verification disclosed herein include:
= Preventing the unauthorized porting of a cell phone number by accurately
verifying the Caller requesting to port the phone number is who they say they
are
by their ability to respond to the push soft token notification. This may
prove the
Caller is both in possession of the phone that currently holds the phone
number
and have authenticated to that phone if the phone has security features like a
PIN, face recognition or fingerprint to access the device. Regulators have
mandated that telecoms solve this use case, which some are doing with a text
verification, however text is inferior to a soft token from a security
perspective
(See NIST).
= Verifying a Caller's identity when they are making significant
transactions over
the phone. For example, there is a common scam in the telecom industry where
28
Date Recue/Date Received 2021-02-26
a bad actor will call a telecom and order a new smartphone (which may be
valued at $1,000 or more), then have it sent to their "new address", which is
not
the "real address" of the Account Owner.
= Airline ticket fraud, in which a bad actor orders an air ticket using
stolen credit
card information, is another big source of fraud. Requiring that the purchaser
of a
major item prove they are who they say they are would cut into a big source of
fraud losses for airlines and credit card companies.
= Large ticket fraud, in which a bad actor orders a high-value item using
stolen
credit card information. Requiring that the purchaser of a major item prove
they
are who they say they are would cut into a big source of fraud losses for
telecommerce and credit card companies.
[00212] Of course, the above described embodiments are intended to be
illustrative only and in no way limiting. The described embodiments are
susceptible to
many modifications of form, arrangement of parts, details and order of
operation. The
disclosure is intended to encompass all such modification within its scope, as
defined by
the claims.
[00213] References
[00214] AARP Research. (2019, December). 2020 Tech and the 50+ Survey.
Retrieved from AARP Research:
https://www.aarp.org/content/dam/aarp/research/surveys_statistics/technology/20
19/20
20-tech-trends-survey.doi.10.26419-2Fres.00329.001.pdf
[00215] Paul A. Grassi, J. P. (2017, June). NIST Special Publication 800-
63C:
Digital Identity Guidelines: Federation and Assertions. Retrieved from NIST -
National
Institute of Standards and Technology (US Department of Commerce):
https://pages.nist.gov/800-63-3/sp800-63c.html
[00216] Pew Research Center. (2019, June 12). Mobile Fact Sheet. Retrieved
from Pew Research Center: https://www.pewresearch.org/internet/fact-
sheet/mobile/
29
Date Recue/Date Received 2021-02-26
[00217] Statistics Canada. (2018). Table 22-10-0113-01 Use of Internet
services
and technologies by age group and household income quartile. Retrieved from
Statistics
Canada: https://www150.statcan.gc.ca/t1/tb11/en/tv.action?pid=2210011301
Date Recue/Date Received 2021-02-26
