On-demand secure data entry for representative-assisted transactions

An on-demand secure data entry system and method for representative-assisted transactions that allows for a representative to be present on a call during the entry of private information to assist the customer while still preventing exposure of the private information to the representative. The system and method involve placing an existing call between a representative and customer on hold, creating a secure call “secure call platform,” placing and parking separate calls secured by the secure call platform from the system to the representative and from the system to the customer, bridging the separate calls such that the representative and customer are connected through the calls secured by the secure call platform, and then masking portions of information received on the system-to-customer call from information transmitted to the system-to-representative call.

BACKGROUND

Field of the Art

The disclosure relates to the field of computer data security, and more particularly to the field of secure data entry during representative-assisted transactions.

Discussion of the State of the Art

In the field of representative-assisted calls (e.g., call centers, technical support, online payments for merchants, etc.), data security is an important consideration. One aspect of data security involves representatives having access to the private information of customers such as account numbers, credit card numbers, and passwords. Preventing representatives from seeing or hearing the private information is one way to ensure data security when customers transmit private data during a conversation with a representative.

During phone calls with representatives, for example, it may be necessary for the representative to request private information from a customer for purposes of assisting the customer. Typically, this involves having the customer speak the private information verbally to the representative, which is less secure in that it involves exposing the private information directly to the representative. Where the customer enters the private information using a touch-tone phone via dual-tone multi-frequency (DTMF), the representative could hear and decode the tones to obtain the private information. Existing technologies for securing such calls either require the entire merchant transaction system to be secured for all calls at all time or require that the customer be transferred to a different system where the representative of the merchant is not present to assist the customer.

What is needed is a means for allowing a representative to be present on a call during the entry of private information to assist the customer while still preventing exposure of the private information to the representative.

SUMMARY

Accordingly, the inventor has conceived and reduced to practice, an on-demand secure data entry system and method for representative-assisted transactions that allows for a representative to be present on a call during the entry of private information to assist the customer while still preventing exposure of the private information to the representative. The system and method involve placing an existing call between a representative and customer on hold, creating a secure call “secure call platform,” placing and parking separate calls secured by the secure call platform from the system to the representative and from the system to the customer, bridging the separate calls such that the representative and customer are connected through the calls secured by the secure call platform, and then masking portions of information received on the system-to-customer call from information transmitted to the system-to-representative call. In some embodiments, this process is performed via a unified communications (UC) system. In some embodiments, the masked information is dual-tone multi-frequency (DTMF) tones entered by the customer and received on the system-to-customer call.

According to a preferred embodiment, a system for on-demand secure data entry for representative-assisted calls is disclosed, comprising: a computing device comprising a memory, a processor, and a non-volatile data storage device; a dialed number identification service (DNIS) pool stored on the non-volatile data storage device, the DNIS pool comprising one or more phone numbers; a session worker comprising a first plurality of programming instructions stored in the memory which, when operating on the processor, causes the computing device to: receive a command associated with a customer-to-representative call on a telephony system, the command comprising a request to establish a secured, bridged call, a customer phone number for the customer-to-representative call, and a representative phone number for the customer-to-representative call; request a phone number allocation from the DNIS pool from a dialed number identification service (DNIS) pool worker; receive an allocated phone number from the DNIS pool by the DNIS pool worker; instruct the telephony system to place the customer-to-representative call on hold; instruct the telephony system to place a system-to-customer call from the allocated phone number to the customer phone number; instruct a dual-tone multi-frequency (DTMF) secure call platform to park the system-to-customer call after placement; request and receive validation of the system-to-customer call from the DNIS pool worker; instruct the DTMF secure call platform to secure the system-to-customer call after receipt of validation of the system-to-customer call; instruct the telephony system to place a system-to-representative call from the allocated phone number to the representative phone number; instruct the DTMF secure call platform to park the system-to-representative call after placement; request and receive validation of the system-to-representative call from the DNIS pool worker; instruct the DTMF secure call platform to secure the system-to-representative call after receipt of validation of the system-to-representative call; and instruct the DTMF secure call platform to bridge the system-to-customer call and the system-to-representative call via the allocated phone number; a dual-tone multi-frequency (DTMF) secure call platform comprising a second plurality of programming instructions stored in the memory which, when operating on the processor, causes the computing device to: park the system-to-customer call; secure the system-to-customer call; park the system-to-representative call; secure the system-to-representative call after receipt of validation of the system-to-representative call; bridge the system-to-customer call and the system-to-representative call via the allocated phone number; receive one or more dual-tone multi-frequency (DTMF) tones representing digits from zero to nine from the system-to-customer call; block transmission of the DTMF tones to the system-to-representative call while passing through any other audio from the system-to-customer call to the system-to-representative call; and the DNIS pool worker comprising a third plurality of programming instructions stored in the memory which, when operating on the processor, causes the computing device to: allocate a phone number from the DNIS pool; validate the system-to-customer call; and validate the system-to-representative call.

According to another preferred embodiment, a method for on-demand secure data entry for representative-assisted calls is disclosed, comprising the steps of: storing a dialed number identification service (DNIS) pool stored on a non-volatile data storage device of a computing device comprising a memory, a processor, and the non-volatile data storage device, the DNIS pool comprising one or more phone numbers; using a session worker operating on the computing device to: receive a command associated with a customer-to-representative call on a telephony system, the command comprising a request to establish a secured, bridged call, a customer phone number for the customer-to-representative call, and a representative phone number for the customer-to-representative call; request a phone number allocation from the DNIS pool from a dialed number identification service (DNIS) pool worker operating on the computing device; receive an allocated phone number from the DNIS pool by the DNIS pool worker; instruct the telephony system to place the customer-to-representative call on hold; instruct the telephony system to place a system-to-customer call from the allocated phone number to the customer phone number; instruct a dual-tone multi-frequency (DTMF) secure call platform operating on the computing device to park the system-to-customer call after placement; request and receive validation of the system-to-customer call from the DNIS pool worker; instruct the DTMF secure call platform to secure the system-to-customer call after receipt of validation of the system-to-customer call; instruct the telephony system to place a system-to-representative call from the allocated phone number to the representative phone number; instruct the DTMF secure call platform to park the system-to-representative call after placement; request and receive validation of the system-to-representative call from the DNIS pool worker; instruct the DTMF secure call platform to secure the system-to-representative call after receipt of validation of the system-to-representative call; and instruct the DTMF secure call platform to bridge the system-to-customer call and the system-to-representative call via the allocated phone number; using the dual-tone multi-frequency (DTMF) secure call platform to: park the system-to-customer call; secure the system-to-customer call; park the system-to-representative call; secure the system-to-representative call after receipt of validation of the system-to-representative call; bridge the system-to-customer call and the system-to-representative call via the allocated phone number; receive one or more dual-tone multi-frequency (DTMF) tones representing digits from zero to nine from the system-to-customer call; block transmission of the DTMF tones to the system-to-representative call while passing through any other audio from the system-to-customer call to the system-to-representative call; and using the DNIS pool worker to: allocate a phone number from the DNIS pool; validate the system-to-customer call; and validate the system-to-representative call.

According to an aspect of an embodiment, the DTMF secure call platform is further configured to: decrypt the received DTMF tones into the digits they represent; add the digits to a field; and transmit the field to a payment worker for processing by a secure payment application.

According to an aspect of an embodiment, the DTMF secure call platform is further configured to: mask one or more of the digits in the field; and transmit the field with the masked digits to a representative interface via the system-to-representative call.

According to an aspect of an embodiment, the representative interface operating on a second computing device is configured to receive and display the field with the masked digits.

According to an aspect of an embodiment, a secure border controller (SBC) operating on the computing device acts as a call gateway securing a payment card industry (PCI) compliant zone, and the DTMF secure call platform and secure payment application operate within the PCI compliant zone.

According to an aspect of an embodiment, a messaging broker operating on the computing device is used to manage communications among the session worker, the DTMF secure call platform, and the DNIS pool worker.

According to an aspect of an embodiment, a softswitch operating on the computing device is used for the placement of the system-to-customer call, the placement of the system-to-representative call, and the bridging of the system-to-customer call with the system-to-representative call are performed using the softswitch.

DETAILED DESCRIPTION

The inventor has conceived, and reduced to practice, an on-demand secure data entry system and method for representative-assisted transactions that allows for a representative to be present on a call during the entry of private information to assist the customer while still preventing exposure of the private information to the representative. The system and method involve placing an existing call between a representative and customer on hold, establishing a secure call “secure call platform,” placing and parking separate calls secured by the secure call platform from the system to the representative and from the system to the customer, bridging the separate calls such that the representative and customer are connected through the calls secured by the secure call platform, and then masking portions of information received on the system-to-customer call from information transmitted to the system-to-representative call. In some embodiments, this process is performed via a unified communications (UC) system. In some embodiments, the masked information is dual-tone multi-frequency (DTMF) tones entered by the customer and received on the system-to-customer call.

A primary use case for the secure data entry system and method herein described is for facilitation of customer payments to merchants via a representative of the merchant. It allows for businesses to securely take credit card based payments using a Unified Communications as a Service (UCaaS) extension in office settings, service desk and retail point of sale transactions. UCaaS is the modern form of the modern form of the plain old telephone service (POTS) and allows for software-based call handling as described herein. The application of the system and method herein described allow for new, just-in-time business processes that make customer-merchant transactions faster and more efficient while simultaneously improving data security.

The on-demand secure data entry solution works by moving an existing customer-to-representative call to a secure call “secure call platform.” The secure call platform is a software module that secures real-time communication (RTC) connections and, depending on configuration, filters audio and/or data from the connection prior to transmitting it elsewhere. The secure call platform is established by using third-party call control features in defined steps to make separate system-to-customer and system-to-representative call legs, place those separate call legs onto the secure call platform, and then bridging the calls internally (e.g., within a unified communications (UC) telephony system). After bridging, the customer and representative can talk to each other as usual, but with the added functionality of capturing private information from the system-to-customer leg and masking it from the system-to-representative leg. As one example, if the customer enters DTMF tones on his or her touchtone keypad, the DTMF audio tones and their decryptions into digits can be received by the system and acted upon (e.g., inserted into appropriate fields) while masking that information from the representative. In some embodiments, once the call is bridged via the secure call platform, it will remain bridged until it ends, although in other embodiments the bridged calls can be disconnected and the original call removed from hold such that the customer and representative continue to converse on the original call.

Using third-party call control is convenient in that it allows the on-demand secure data entry solution to work on most class 5 switches. Pluggable software interfaces can be used to abstract the switch-dependent integration details.

The on-demand secure data entry solution described herein supports configurable payment gateways (also known as secure payment applications) to allow collection of credit card information along with other details like amount, card holder name and reference, all of which can be submitted to a configurable payment gateway for a representative to perform the card payment using masked or partially-masked information.

In some embodiments, the on-demand secure data entry solution is operated by a representative using a user interface (which enables the representative to secure the call. This user interface can be configured to run on any compatible platform, a non-limiting list of which includes running stand-alone in a browser, embedded in another webpage, or displayed on a telephony device with an appropriate screen.

In some embodiments, the on-demand secure data entry solution also supports application programming interfaces (APIs). Use of the on-demand secure data entry solution via APIs allows organisations using the solution to incorporate the securing functionality into their existing systems without major changes to their existing systems.

Definitions

“Representative” as used herein means a representative of an organization whose job it is to assist customers via remote communications such as phone, text, or chat. A representative as herein defined includes, but is not limited to, salespeople, administrators, receptionists, payment processors, and other persons who may be involved in assisting customers via remote communications, whether paid or unpaid, whether working for an organization receiving payment or for a third party, and regardless of employer-employee relationships.

“Secure call platform” or “SCP” as used herein means a software component that receives and processes softswitch events to secure real-time communication (RTC) connections and, depending on configuration, filter audio and/or data from the connection prior to transmitting it elsewhere.

“Customer” as used herein means a person requiring assistance via remote communications. A customer may be purchaser or user of the goods and/or services of an organization, but the term as used herein is not so limited, and may include callers seeking assistance from non-profits, helplines, technical support lines, and other sources whether paid or unpaid.

“Phone number” as used herein means any sequence of numerical digits that can be dialed by a telephony system in order to connect to a device associated with the sequence of numerical digits dialed. The term “phone number” includes but is not limited to local numbers, national numbers, international numbers, numbers external to a PBX or UC system, and numbers internal to a PBX or UC system, whether or not having an international calling code or country code, a prefix or area code, or a suffix or extension, and whether or not consisting only of a suffix or extension (such as internally to a PBX or UC system).

“Private Branch Exchange” or “PBX” as used herein means a telephone system within an organization that switches calls between users on local lines while enabling all users to share a certain number of external phone lines. Modern PBX systems are capable of converting analog signals from plain old telephone services (POTS) to digital signals, and often include network switching capabilities that allow use of analog phones with the organization's digital PBX system.

“Unified Communications” as used herein means integration of different types of communications tools such as PSTN audio calls, VOIP audio calls, video calls, email, voice mail, text messaging.

“Unified Communications Telephony System” or “Unified Communications System” as used herein means a communications system that allows for or provides unified communications.

Conceptual Architecture

FIG.1is a block diagram illustrating exemplary operation of a secure call platform in an payment card industry compliance configuration. In this example, a customer110calls a merchant via a public switching telephone network (PSTN)130. The customer call is received by a carrier140which uses a unified communications (UC) telephony system. A representative120is connected to customer's call via carrier140at which point customer110and representative120can converse.

If secure communications are required, for example when representative120requests payment information from customer110to make a payment for goods or services, representative120clicks a button on the screen to secure communications. This starts a process of securing the call via a secure call platform which allows customer110to enter data in a secure manner which is masked from representative120even while representative remains on the call and available to speak with customer110. Two new calls are made from an on-demand secure data entry system using carrier's140PBX or UC system, one from carrier140to customer and another from carrier140to representative120. The new calls are passed as session initiation protocol (SIP) calls to a session broader controller (SBC)340residing within a payment card industry (PCI) compliant zone300. SBC passes the calls to a DTMF secure call platform330, which secures the calls, bridges them, and masks DTMF tones and decryptions entered by customer110from representative120while passing through other audio to representative120, allowing customer110and representative120to continue conversing while customer enters DTMF tones (e.g., credit card numbers). Data entered by customer110using DTMF tones may be displayed to representative in masked or partially masked form (e.g., with asterisks in place of some or all of the decrypted DTMF digits). After customer's data has been entered, representative may submit the information for payment to a secure payment application351which places the payment via an Internet connection through carrier140.

Note that while the customer call is shown in this example as being placed on a regular phone line via a PSTN, no limitation is implied thereby, and the call may be placed through other available means or technologies (e.g., voice-over-Internet-protocol (VOIP), cellular phone service, etc.).

FIG.2is a block diagram illustrating an exemplary system architecture for an on-demand secure data entry system. In this embodiment, the backbone of the system is an internal messaging microservice210through which are passed messages from various workers, each having functionality that implements a portion of the system and directs and controls other components of the system. Internal messaging microservice210can be managed by one of several available messaging brokers such as Rabbit MQ™. The various workers comprise a session worker220a dialed number identification service (DNIS) worker230, a secure call platform worker240, a database worker252, and an interface worker257.

Session worker220is responsible for management of the overall process of receiving an original call, placing it on hold, establishing a secure call platform, placing new calls, and bridging the new calls. Service worker220may store information about the state of the process in a state database221.

DNIS pool worker230is responsible for making dialed number identification service (DNIS) allocations for incoming calls, thereby allowing an organization's PBX or UC system to identify the number from which a call is being made and any DTMF tones associated with that number for use in capturing data. DNIS pool worker230may have access to a DNIS pool database231which stores a list of numbers dialable from the organization for whom the representative is working.

Secure call platform worker240is responsible for management of secure call platforms to secure calls, bridge calls, and mask private information received such as private information in the form of DTMF tones.

A unified communications (UC) backend250implements calls and call management instructions from session worker220, DNIS pool worker230, and secure call platform worker240. UC backend250of this embodiment comprises an external message microservice251, a database worker252, a database253, an interface worker254, cloud functionality256, and a credential service255. External message microservice251operates in a manner similar to internal message microservice210, but for messages with external entities or services. External message microservice251can be managed by one of several available messaging brokers such as Rabbit MQ™. Database worker252manages a cloud-based database service253used to store information such as user profiles, telephony information, and payment gateway information. An example of a cloud-based database service manageable by database worker252is Google Firestore™. Backend-as-a-service256provides cloud-based, scalable, cross-platform backend services via application programming interfaces (APIs) such as database management, cloud storage, user authentication, push notifications, and web hosting. Interface worker254receives and places calls through various carriers140a-npursuant to instructions from session worker220.

A frontend260provides representatives with an interface for accessing and using the system, including an interface for implementing secure call platforms during a call.

In operation, when representative120asks for a call to be secured, DNIS pool worker230temporarily allocates a number from a DNIS pool231. Session worker220then directs both the customer leg and the representative leg via the allocated number to a softswitch instance managed by interface worker254. After validation and securing of the customer leg and representative leg calls, the calls are bridged allowing customer and representative to speak while intercepting and masking from representative any DTMF tones entered by customer.

DNIS pool231is a list of phone numbers that are dialable from the representative's phone service. They can be full national numbers or internal extensions. They can be routable internally via a softswitch on the representative's end or via the PSTN130. In order to bridge the call legs, the number presented to the softswitch should be the same as the number used to dial the call to the secure call platform for each leg. The number presented to the softswitch is used to confirm that the number allocated from DNIS pool is correct and active, and to bridge the two call legs in a session. This procedure may be modified in cases where there is a routing prefix required to get the call out of a trunk line to the secure call platform. Each organization using the on-demand secure data entry system would likely have its own pool of numbers.

DNIS pool231acts as a security measure in that only numbers from the pool will be recognized by the system as valid. In some embodiments, the quantity of numbers available in the DNIS pool231may be dependent on the call volume of the organization and the security level needed. A larger DNIS pool231or a DNIS pool231containing randomly-selected numbers is more secure because attackers will have to guess more digits of the number (e.g., when the pool contains numbers with different prefixes versus numbers with the same prefix) so has a smaller chance of being able to dial a number in the pool which would be recognized as a valid call. If the numbers are not dialable externally then that also increases the security as they cannot be obtained outside of the system, and may allow a smaller quantity of numbers to be used with equivalent security.

Random allocation of numbers from DNIS pool231will enhance security. A further security enhancement is setting a time limit on the validity of the number selected from the pool, after which that number will no longer be recognized as valid. This allows a finite set of numbers to be used and re-used while still providing an acceptable level of security. Ideally, the amount of time a number can be allocated for should be the shortest time needed to reliably connect both customer and representative calls to the secure call platform. If a call comes in with a valid number but after the expiration of the time limit, the call may be rejected, and an alarm may be raised. Using these procedures would require an attacker to guess a number from the pool and dial it within the time limit in order to join a call either as customer or representative. In either case, however, this could not cause a PCI breach as the attacker would either replace the customer (in which case the customer's private information is not available) or would replace the representative (in which case the DTMF tones from the customer would be masked).

Once a number has been selected from DNIS pool231, a series of instructions are orchestrated by the session worker220to establish a secured, bridged call between customer and representative as further described below.

FIG.3is a block diagram illustrating details of exemplary payment card industry compliance zone aspect of an on-demand secure data entry system. When representative120requests that a call be secured, session worker220directs system-to-customer and system-to-representative calls to be made via softswitches320a, bwithin a payment card industry (PCI) compliant zone. A PCI compliant zone is one that meets a set of security standards designed to ensure that all entities involved receive, process, store, and transmit credit card information in a secure environment. The operation of PCI compliant zone300is handled through a PCI message microservice310which operates in a manner similar to internal message microservice210, but for messages within PCI compliant zone300. PCI message microservice310can be managed by one of several available messaging brokers such as Rabbit MQ™. When calls are secured in a secure call platform and bridged messages are passed to PCI message microservice310to notify session worker220of their status. As used in this application, the phrases “system-to-customer” and “system-to-representative” are not intended to imply a directionality with which the call must be made, but rather to specify the end points of each call leg.

Session worker220directs UC backend250to place the existing customer-to-representative call on hold. Once the existing call has been placed on hold, session worker220directly UC backend250to establish a system-to-customer call (call A) through softswitch A320afor which a DMTF secure call platform A is established330a. Once call A has been established and parked, session worker220then directs UC backend250to establish a system-to-representative call (call B) through softswitch B320bfor which a DMTF secure call platform B is established330b. Once call B has been established and parked, session worker220directs UC backend to bridge call A and call B to re-establish communications between customer and representative wherein voice audio is passed between customer and representative, but any DTMF tones entered by customer are masked from representative.

Session Border Controller (SBC)340is responsible for securing VOIP calls within PCI compliant zone300border and for directing telephony sessions from carriers to the appropriate softswitches for securing and bridging.

After secured, bridged calls have been established and customer has entered payment information via DTMF, payment worker350receives payment information fields from DTMF secure call platform via PCI message microservice310to process payments requested by representative. Payment worker350processes the payment via a secure payment application351via an Internet connection.

DETAILED DESCRIPTION OF EXEMPLARY ASPECTS

FIGS.4A &4Bare a messaging diagram illustrating an exemplary messaging sequence for establishing a secured, bridged call for secure data entry. During a customer call (call X) with a representative402, representative initiates a secure data entry session via his or her interface (e.g., by clicking on a “secure connection” button). A new session is started410when the UC backend250directs session worker220to start a session411. A DNIS number is allocated420when session worker220requests a DNIS allocation421from DNIS pool worker230, which responds by allocating a DNIS number422. A secure call platform is initialized and call X is placed on hold430when session worker220requests establishment of a secure call platform431from secure call platform worker240, which sends confirmation of secure call platform initialization432to session worker220. Session worker220then sends a request to UC backend250to place call X on hold433. Call X is held435when placed on hold434by UC backend250, which then sends a hold confirmation436to session worker220. System-to-representative call (call A) is placed and parked440when session worker220sends a call initiation request441to UC backend250. Call A is established443between DTMF secure call platform330and representative120when the call is placed by UC backend442, which sends confirmation of the call A placement444to session worker220. DTMF secure call platform parks call A and sends notification that call A is parked445to secure call platform worker240. Secure call platform worker240requests validation of call A446from DNIS pool worker230, which responds by sending a validation447to secure call platform worker240. Secure call platform worker240secures the session448via DTMF secure call platform330and sends a confirmation that the session has been secured449to session worker220. System-to-customer call (call B) is placed and parked450when session worker220sends a call initiation request451to UC backend250. Call B is established453between DTMF secure call platform330and representative120when the call is placed by UC backend452, which sends confirmation of the call B placement454to session worker220. DTMF secure call platform parks call B and sends notification that call B is parked455to secure call platform worker240. Secure call platform worker240requests validation of call B456from DNIS pool worker230, which responds by sending a validation457to secure call platform worker240. Secure call platform worker240secures the session458via DTMF secure call platform330and sends a confirmation that the session has been secured459to session worker220. Call A and call B are bridged460when session worker220sends a bridge request461to secure call platform worker240, which sends a bridge command462and a mask digits/mask audio command463to DTMF secure call platform330. DTMF secure call platform330responds with a bridge confirmation464and secure call platform worker240sends a notification of the bridge465to session worker220.

FIG.5is a messaging diagram illustrating an exemplary messaging sequence for confirming a state of a secure call platform for a secure data entry system. A heartbeat confirmation sequence510is initiated during each heartbeat of a server operating a softswitch320. Softswitch320sends a heartbeat event511to DTMF secure call platform330, which responds by confirming the state of the secure call platform during that heartbeat512. Softswitch320sends a secure call platform heartbeat notification513to secure call platform worker240.

FIG.6is a messaging diagram illustrating an exemplary messaging sequence for parking a call prior to bridging calls for a secure data entry system. A call parking sequence610is initiated when softswitch320sends a park call event611to DTMF secure call platform330, which responds by parking the call and sending a parked call confirmation to softswitch612. Softswitch320sends a parked call notification613to secure call platform worker240.

FIG.7is a messaging diagram illustrating an exemplary messaging sequence for bridging calls for a secure data entry system. A call bridging sequence710is initiated when softswitch320sends a bridge request711to DTMF secure call platform330, which responds by bridging the call and sending a bridged call confirmation712to softswitch320. Softswitch320sends a bridged call notification713to secure call platform worker240. Likewise, a call unbridging sequence is initiated when softswitch320sends an unbridge request714to DTMF secure call platform330, which responds by bridging the call and sending a bridged call confirmation715to softswitch320. Softswitch320sends a bridged call notification716to secure call platform worker240.

FIG.8is a messaging diagram illustrating an exemplary messaging sequence for secure processing of DTMF tones for a secure data entry system. A DTMF entry sequence810is initiated when softswitch320sends a DMTF tone811to DTMF secure call platform330, which decrypts the tone into a digit, adds the digit to a field, and encrypts the field812, sending a masked digit entry813to softswitch320. Softswitch320sends a masked digit entry notification814to secure call platform worker240.

If the DTMF tone is the “*” tone815, DTMF secure call platform330decrypts the tone, empties the field, and encrypts the field816, and sends a field reset command817to softswitch320. Softswitch320sends a field reset notification818to secure call platform worker240.

If the DTMF tone is the “#” tone819, DTMF secure call platform330decrypts the tone, validates the field820, and sends a masked field entry821to softswitch320. Softswitch320sends a masked field entry notification822to secure call platform worker240.

A DTMF request sequence830is initiated when secure call platform worker240, upon receipt of the masked field entry notification822, sends requests fields831to softswitch320, which in turn requests fields832from DTMF secure call platform330. DTMF secure call platform330retrieves the fields and sends them833to softswitch320which sends the fields834to secure call platform worker240.

FIGS.9-12are exemplary screenshots showing a representative's interface during a secure data entry session. InFIG.9, the call window910seen by the representative shows a notification window911which instructs the representative to click on a “secure call” button912to begin a secure transaction. When the representative clicks on the secure call button912using a pointer901, the call is secured via a secured, bridged call as described above. InFIG.10, the notification window now displays a lock symbol1001with a message to the representative that the call has been successfully secured. InFIG.11, the call window now displays a payment details window1020, a credit card details window1030, and a make payment button1111. The representative fills in the payment details fields comprising a transaction description1021, an amount1022, and the name of the customer1023while the customer is still on the phone. At this point, the representative requests that the customer enter DTMF tones on his or her touchtone keypad for each of the indicated fields, in this example a credit card number field1031, an expiration date field1032, and a card verification value (CCV) field1033. As the customer enters the DTMF tones for each digit, the system intercepts the tones, decrypts them, and enters them into the fields1031-1033masked by asterisks so that the representative neither hears the tones nor sees the masked digits (in this example not all of the digits are masked). When the credit card details fields1031-1033are completed, the representative clicks on the make payment button1111, and the system processes the payment through a secure payment application351.FIG.12shows the completion of the secure data entry process with the notification window911advising the representative that the payment was successful and that the call can be safely terminated, if appropriate.

Hardware Architecture

In addition, in some aspects, servers32may call external services37when needed to obtain additional information, or to refer to additional data concerning a particular call. Communications with external services37may take place, for example, via one or more networks31. In various aspects, external services37may comprise web-enabled services or functionality related to or installed on the hardware device itself. For example, in one aspect where client applications24are implemented on a smartphone or other electronic device, client applications24may obtain information stored in a server system32in the cloud or on an external service37deployed on one or more of a particular enterprise's or user's premises. In addition to local storage on servers32, remote storage38may be accessible through the network(s)31.