KR101626302B1 - Natural enrolment process for speaker recognition - Google Patents

Abstract

A natural biometric registration system describes a method and associated device for extracting oral biometric text data from a user / registrant in a manner that masks conventional automated interactive voice response operations using a natural process of live agent validation. Natural biometric registration systems also provide the ability to synchronize agent locations and agent IDs, and thus do not require traditional CTI system integration; This is accomplished in both bidirectional and dual verification procedures where both agent and sender statements are matched within the common database and software controls are used to match the caller with the registration and verification widget located on the agent desktop. In addition, the agent can generate human judgment notations using this registration / verification widget, which allows the system to: a) have an improved score for registration and verification; b) to record notations reflecting the live agent reliability of the user's validity; c) cause a PIN reset for fake callers in a native or third party system.

Description

[0001] NATURAL ENROLMENT PROCESS FOR SPEAKER RECOGNITION [0002]

Field of the Invention The present invention relates generally to biometrics authentication methods and, in particular, to minimize uncontrollable users' inconveniences and maximize access security by protecting the entire interaction, using uncertainty modeling, Lt; RTI ID = 0.0 > and / or < / RTI > continuously.

Organizations with considerable customer base dealing with personal or financial information or transactions often require identity verification of parties to ensure that transactional parties receive the critical information or have the appropriate authority to complete a particular transaction. These persons may be agents or agents of the institution's customers or organizations. In the case of representatives of the institution, verification of qualification or authority may be required.

A variety of techniques are used, including one or more criteria that provide the degree of certainty that an individual is the person he claims to be. This criterion may be based on something someone knows (birthday, password), something that the individual has (a kind of token), or unique physical attributes (biometric data such as gates, iris scans, retina scans, fingerprints, etc.) have.

The bio-identification verification first requires registration of the relevant individual, thereby knowing the physical attributes to match at the time of verification. Verification typically occurs only at the beginning of an interaction, and once it is implemented it is considered valid for the entire interaction. This does not allow the person's identity verification to be completed correctly but the interaction is then passed on to another person. This is a significant potential flaw in interactions that require a very high level of identity verification.

Using voice as a biometric attribute has the advantage that registration and verification can be completed through a common telephony system. Also, unlike passwords and tokens, voice attributes may not be forgotten or easily stolen. In addition, verification can be repeated throughout the interaction, thereby preventing a false user from taking over the verified interaction. However, registration of users is a complex and time-consuming process, since a significant amount of speech capture is required to achieve reliable registration. So far, this has limited the adoption of voice biometrics as a telephone-based authentication means.

Related Technology

U.S. Patent No. 6,078,807 to Dunn et al. Discloses a speaker-dependent (or wireless) system for preventing excessive misuse of certain telephone system lines (or wireless channels) or selectively limiting the class of service allowed for various users of a common line. ≪ / RTI > discloses a system / method for selecting telephone system callers using speech-type text-independent speech recognition. The speech recognition process is configured to provide a degree of mismatch indication between a speech sample obtained from a caller currently using a secure line (or channel) and a recorded reference speech sample, and this indication indicates that the current caller It corresponds to the possibility of not being the same as one person.

U.S. Patent No. 7,212,613 to Kim et al. Discloses a voice biometric authentication system and method wherein the authentication system is used to authenticate a user of the telephone device. The system includes a configuration system for capturing and storing real user voice samples, a comparison system for comparing actual user voice samples with input voice samples to generate comparison results, and a control system for controlling access to the telephone device . The control system analyzes the comparison result for the initial input speech samples received when the telephone call is started and periodically re-analyzes the comparison results for the continuous input speech samples received during the telephone call.

U.S. Patent No. 7,340,042 to Cluff et al. Discloses a system and method for providing voice authentication to institutional consumers, including consumers or users. The system includes a registration module, a verification module, and a database. Each institutional consumer has an authentication profile on the system that includes both instructions indicating that one or more voice bioengine should be used for registration and / or authentication of a given consumer, and variables for executing these commands have. A given institutional consumer may have more than two sets of instructions or variables for various classes of users. Voice information is received from the user, and a baseline sentence is configured for registration. Then, more voice information is received from the user to construct the temporary gates. Temporary gates are compared to corresponding baseline gates according to the institutional consumer's authentication profile.

U.S. Patent No. 7,367,049 to Robinson et al. Discloses a system and method for registering potential system users for a biological system for identity verification. Potential system user information is entered into the system by a user or system operator and is stored as a partially-enabled user record. The user of the partially-driven user record fully drives the recording by presenting the pre-stored information to the user record and presenting the remainder of the user information needed to complete the recording activation. Registration data is used to authenticate the identity of the system user and to authorize relevant transaction accesses in the biometric system for identity verification.

According to various embodiments of the present invention, the above-described system provides the ability to continuously monitor voice interaction for the purpose of voice biometric registration and verification while providing feedback of current status to the agency agent.

In terms of registration, this allows the live agent to guide the enrollee through the process. The design ensures that only the subject's voice is processed for registration purposes.

It is expected that the interactions guided by the live agent are more likely to yield more successful results than the automated interactions. The agent will be provided with feedback via a "whisper (inaudible to the registrant)" or by a visual indication of whether the voice data of the quantity and quality sufficient to complete the registration has been captured.

Recognition of the registrant for the design and implementation of an interaction dialogue is a matter of local jurisdiction and institutional policy.

From a validation point of view, the design provides continuous verification of all stakeholder identities throughout the transaction. This will detect whether any party in the transaction has changed or any unverifiable party has spoken. From a consumer perspective, this provides enhanced security. For an authority, it also allows verification that an authorized agent is performing an interaction. This is particularly important for remote-based agents where the organization may have limited physical control.

The notification of the change to the verification status will be appropriately known to the agent or manager or both. This can be done through a visual alert or whisper or both. Optionally, the interaction may be terminated.

Since the agent and consumer voice streams are carefully separated, it is possible to perform continuous validation of the agent identity while registering the consumer using the natural registration procedure.

The verification score may be presented directly to the agent or manager or any other party, or may be further processed in accordance with the agency policy.

A preferred embodiment is a computer program product that is computed using techniques such as those described briefly in U. S. Serial No. 12 / 663,163, A1, " Confidence levels for Speaker Recognition, " filed December 19, The verification score is used, but any other method may be used.

1 is a block diagram illustrating one embodiment of a natural registration process developed in various environments.
Figure 2 is a flow diagram of an embodiment of the registration process of the present invention in which agent mediation is not required during the registration process;
Figure 3 is a flow diagram of an embodiment of the registration process of the present invention in which a live agent participates in the verification of a pre-registered user that is supported by a registration widget.
Figure 4 is a flow diagram of an embodiment of the registration procedure of the present invention used for verification purposes, in which the system processes the verification of a pre-registered user (but the live agent can participate in the judgment of the suspect case).
5 is a flow diagram of an embodiment of the registration procedure of the present invention used for verification purposes, in which a live agent participates in validation of a pre-registered user that is supported by a registration widget.

The following detailed description with reference to the accompanying drawings is intended as a description of certain embodiments of the disclosure and is not intended to represent the only forms that may be developed or utilized. Although the description describes various functions associated with the illustrated embodiments, it should be understood that the same or equivalent functions may be accomplished by different embodiments that are intended to be within the scope of the present disclosure. It is added that the use of relative terms such as top and bottom, first and second, etc. are used to distinguish different objects from only one object, without necessarily requiring or implying this actual relationship or order between objects .

1, an embodiment of a natural registration procedure may be implemented in a public switched telephone network (PSTN), an IP-based network such as the Internet, a mobile communication network, and a multimedia-oriented high speed network But is not limited to, communication networks, including but not limited to telecommunications networks.

Registered Person Side ( Enrollee Aspect )

100 < / RTI > The person to be registered comprises the user 105, the terminal device 110, e.g., the PSTN 115 and / or alternatively a SIP / VoIP (Voice over IP) network 120. The sender 105, who is the registration target, initiates a registration transaction or a validation transaction by making a telephone call to the system employing the biocomplexes 600, 700, 800.

In a preferred embodiment of the present invention, user 105 initiates a registration or verification transaction using a telephone device or terminal device 110; However, such an apparatus is not limited to the telephone apparatus, but may include a microphone coupled with other terminal apparatuses that transmit the recorded voice utterance to the biological engine 600 via IP or telephone network.

At 115, the user 105 makes a call using the terminal device 110 via the PSTN. Alternatively, the user 105 may initiate the transaction over the IP-based network using the VoIP-enabled device 110.

Overlay  Complex Overlay Complex )

The overlay complex consists of a VoIP gateway 125 and / or a session border controller 130 and an arbitrary preamble engine 200. At 125, the telephone call from the user 105 is terminated on the common VoIP gateway. These gateways are available from vendors such as CISCO, Sangoma, and Audiocodes. Those skilled in the telephony art will appreciate that the gateway 125 may convert PSTN signals to VoIP signals for further transmission to an IP based telephony engine.

In a preferred embodiment of the present invention, the IP signal will be processed by an arbitrary preamble engine 200. At 130, an IP-based telephone call from the user 105 will terminate on a session border controller which is a commonly available device. These devices are available from vendors such as CISCO and ACME Packets. In the context of the present invention, the purpose of the session border controller is to provide security and firewall functions for incoming and outgoing IP based phone calls.

All telephone calls from the user 105 regardless of whether they have been delivered from the gateway 125 or the session border controller 130 can be further processed in the preferred embodiment of the present invention, &Quot; drop and insert "function can be achieved with a preamble engine. Those skilled in the art will appreciate that such "drop & insert" functions may be performed in accordance with U.S. Patent No. 5,046,888 entitled " Converter for in-band routing and / or origination information " . ≪ / RTI >

Here, at 200, IP-based voice communication derived from the user 105 can be separately recorded and analyzed in real time by the biomedical complexes 600, 700, and 800. This creates a way to analyze the individual statement data while allowing arbitration of the live agent 505. [

Alternatively, an arbitrary preamble engine 200 may be used as a switching resource after a transition point 310 or 320 indicated by 310 and 320. Here, signaling schemes such as the ECR of Verizon Business or ICM of CISCO can be used to share preamble engine resources only in the call portion where the biocomponent needs to be called.

Native  Complex Native Complex )

At 210, the original phone call is delivered from the arbitrary preamble engine 200 and proceeds to the main preamble system 300. This major preamble system may be an existing interactive voice response (IVR) system that is collocated or network based. In a preferred embodiment of the present invention, the arbitrary preamble engine 200 can be combined with the main PS 300 with the ability to record and analyze the user 105 voice in real time. However, if the existing IVR system can not be changed, it may be advantageous that the preamble engine 200 is standalone.

Similarly, at 220, the original IP based call continues to be delivered to the primary preamble system 300 in the same manner as a PSTN based call.

At 310, the original PSTN phone call exits the primary preamble system 300 and ends on an automatic telephone distributor / private branch exchange (ACD / PABX) This transfer between the main preamble system 300 and the ACD / PABX 400 is well known to those skilled in the art of contact center systems. For example, this transmission may be accomplished using regular telephony signaling using a direct connection between the primary preamble system 300 and the ACD / PABX 400. [ Alternatively, this transfer may be facilitated through the use of a network-based conversion system as employed by Verizon Business (ECR) or CICSO (ICM).

At 320, the original IP based call exits the primary preamble system 300 and ends on the ACD / PABX 400. Like the phone call delivered via the PSTN 310, the IP-based calls may be redirected or SIP re-invited as specified in the SIP RFC 3261, as promulgated by the IETF Network Working Group, ). ≪ / RTI >

At 400, the phone call is handled by the ACD or PABX, where the most appropriate and valid agent decision is made. Those skilled in the art of contact center will recognize the use of generally available systems to obtain such agent selection and routing results. For example, vendors such as Avaya, Aspect, and Alcatel manufacture telephone systems that can route calls to local or remote agents using PSTN and / or IP-based facilities.

Registrant Side ( Enroller Aspect )

At 410, the original PSTN phone call exits the ACD / PABX 400 and ends on the phone device 510. Alternatively, at 420, the original IP-based telephone conversation is terminated on the computer 550 using the so-called softphone or alternatively on the IP-based device 510.

Also, the registrant side point 550 (agent workstation) can accommodate the registration widget. In a preferred embodiment of the present invention, the registration widget will be implemented using a common computer language such as JavaScript, Adobe Flex, or Adobe AIR. A person skilled in the desktop software field will be able to communicate with the bio-application gateway RESTlet 700 via HTTP. The purpose of the registration widget is to allow the registrant / agent 505 to verify the identity of the sender and to match this verification with the biometric key of the sender. The widget may also be employed so that the biometric application gateway RESTlet 700 can send a message to the registrant agent 505 indicating the score of the automated verification of a particular sender.

Biocomplex Biometric Complex )

The biomedical complex includes a bioengine engine 600, a bio-application RESTlet 700, and a bio-application database 800. [

At 600, the bio-engine accepts highly specialized speech algorithms and score calculation mechanisms that match stored biometric keys (biometric) to identify the identity of the caller. Such bioengineering can be deployed by generally available software. Those skilled in the art can develop bioengine technology provided by vendors such as Nuance, Persay, or Validvoice.

At 700, there is a bio-engine 600 and a software state controller for the natural registration process. These biometric application gateways can use various computer applications and languages, such as C ++ or Java.

In a preferred embodiment of the present invention, the biometric application gateway 700 includes a biometric engine 600, an arbitrary preamble engine 200, a main preamble server 300, a registration / validation widget 550, Processes instructions to / from database 800.

Various protocols may be used to communicate between the biometric application gateway 700 and related components. For example, the link between the bio-engine 600 and the bio-application gateway 700 may be TCP / IP, HTTP, or MRCP (Media Resource Control Protocol). For example, the protocol between the biometric application gateway 700 and the arbitrary preamplifier engine 200 and the main preamplifier server 300 may be HTTP, TCP / IP, or MRCP. For example, the protocol linking the biometric application gateway 700 with the registration / validation widget 550 may be HTTP, TCP / IP, or various other web services. For example, the biometric application gateway 700 may communicate with the biometric application database 800 using protocols such as JDBC or SQL Query.

Depending on the computer application language and protocol preferences, the biocomposite may be implemented as an integrated application encapsulated in a single computer, or it may be implemented as separate logical systems that operate as a whole but are distributed over the network.

At 800, the gateways and associated score data are stored in a biometric database that acts as a secure repository for gateways captured from the to-be-registered recipient / These stored biometric keys are used by the sender to be verified (e.g., by the sender to be verified) to verify the exact match between the real-time remark from the registrationee / originator 105 claiming to be a previously successfully registered or verified individual and the stored biometric key Used to compare consecutive utterances (apparently verbally expressed).

Conventional automated registration - Figure 2

A) Registration scenario where agent mediation is not required

In 2000, the conventional automated registration process begins. In 2010, callers who are not yet registered call the telephone number associated with the ACD or interactive voice response system that represents the target enterprise. 2020, depending on whether the connection to the biomedical complexes 600, 700, 800 is performed in a distributed fashion (arbitrary preamble engine is located in front of the main preamble server) or integrated as a function of the main preamble server, And is connected to the preamble engine 200 or the main preamble server 300. Access to the biomedical complexes 600, 700, 800 may be performed by various methods (including the optional preamble engine 200 as a passive listening device in front of the main preamble server 300, or as the main preamble server 300, Including but not limited to using as a shared resource either before or after. This may be achieved by providing access to the biocomplexes 600, 700, 800 via non-telephone access methods (e.g., computer microphones and VoIP devices) as described in the registration subject side 100 of FIG. 1 have.

In view of the logical flow, step 2020 performs a function of collecting the sender's gateways such that the sender's gateways can be digitized and stored as biometric keys within the biocomplexes 600, 700, and 800 irrespective of the topology.

At 2030, the primary preamble system 300 collects a standard personal identification number (PIN) (or consumer or user number) as represented by most of the currently deployed self-service systems. These PIN numbers used for the first step identification can be entered via the touch tone digits or verbally as will be understood by those skilled in the art of interactive voice response.

In a preferred embodiment of the present invention, this PIN number is used to compare consumer records in a standard database to ascertain whether the calling party has already been registered. If it is possible to collect a biological sample from a sender to verify a previous registration of the sender's identity using a match for the stored biometric key of the sender, then the step of collecting the PIN may be skipped arbitrarily.

At 2040, it is determined whether the sender has been pre-registered. If the sender is not registered, the "unregistered state flag" is stored in the memory. Which is then used to determine the appropriate call flow to be used by the IVR. If it is confirmed that the sender has already been registered, the system performs a verification process or other appropriate process as briefly described in FIG. 4 or FIG.

At 2050, the algorithm in the PABX or ACD processes the caller appropriately to complete the registration. If the user has already been registered, step 2060 is used to process the user's verification.

At 2070, it is determined whether the verification was successful. If successful, the caller is transferred to the agent with the appropriate status. Optionally, the caller may be escalated to the agent with a failure status. This data is passed to the agent registration / validation widget 550 via the biometric application gateway RESTlet 700 as described in FIG.

At 2080, the IVR issues a first registration question and collects a user response.

At 2090, it is determined whether or not sufficient voice data has been collected to complete the registration. If sufficient data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 2130. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu. Alternatively, if the only requirement is to complete the registration, the call may be terminated.

If it is determined at 2090 that insufficient registered voice data has been captured, a follow-up question will be made at 2100.

At 2110, it is determined whether sufficient voice data has been collected to complete the registration. If sufficient voice data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 2130. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu. Alternatively, if the only requirement is to complete the registration, the call may be terminated.

If it is determined at 2110 that insufficient registered voice data has been captured, a follow-up question will be made at 2120.

If sufficient voice data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 2130. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu. Alternatively, if the only requirement is to complete the registration, the call may be terminated.

If registration fails, the appropriate information will be delivered to the agent. This data is passed to the agent registration / validation widget 550 via the biometric application gateway RESTlet 700 as described in FIG. The agent may then choose to support the user / enrollment subject, perhaps in a similar fashion to that described briefly in Fig.

If verification fails, the caller will be escalated to the agent, and at the same time all data stored for the already registered sender or the score of the current utterance will be delivered to the appropriate agent registration / verification widget 550.

In addition, the primary preamble system 300 will extract the agent identity from the ACD / PABX 400 over the common CTI data path and deliver the agent identity to the bioapplication gateway RESTlet 700.

Alternatively, the arbitrary preamble engine 200 may have a CTI data link to the ACD to extract selected agent information. Alternatively, the biometric application gateway RESTlet 700 may extract selected agent identity information via common CTI links. It should be noted that there are various methods of extracting the selected agent information from the ACD or PABX. In addition to the above examples, it is also possible to extract the same information from a real time database. For example, the biometric database 800 as illustrated in FIG. 1 may be used as a shared repository by which the ACD, PABX, or CTI application gateway can inject agent data selected in real time. Such data may be extracted using a third party data proxy as supplied by Oracle Corporation. In addition, the real-time agent selection data may be transmitted from the CTI application gateway to the bio-application gateway RESTlet 700 via real-time HTTP / REST or web service commands.

Alternatively, when a call arrives at the agent desktop at the time of answer management or key press from an agent or a password reminder from an agent, the bioconjugates 600, 700, 800 identify the agent to which the system has dialed, Lt; RTI ID = 0.0 > voice < / RTI > In this scenario, all enterprise agents will register themselves to record the biometric key within the biocomplexes 600, 700, 800. Those skilled in the art will appreciate that such biometric keys are associated with agent names, employee numbers, extensions, and other data within the biometric database 800 to create an agent record in the database. In this way, in-line verification of the identity of the agent can be accomplished without using CTI and without extracting any data from the currently installed legacy IVR or ACD.

At 2140, the agent receives the call and the agent registration / verification widget 550 is synchronized. Synchronization is performed by the CTI method described above or the biometric validated agent itself so that the biometric application gateway RESTlet 700 knows which biometric registration / verification widget 550 should send the sender data.

In a preferred embodiment of the present invention, the arbitrary preamble engine 200 or one of the above equivalents is used to idle the transmission timeslot on the telephone connection so that the caller needs to speak to the agent to complete the biometric verification I will not listen to the contents. While the agent is verifying, the arbitrary preamble engine 200 may be equipped with a music file for playback to the caller, such as a call progress tone and in this particular case a call ring back tone. Once agent bio-routing is achieved, the telephone ring tone will stop and both parties will hear each other.

At 2170, if the process fails, the agent may use a standard procedure to reset the PIN generated by the enterprise as described in step 2030. [ This is to ensure that the false sender, who may intend to steal the identity of the actual sender, can not use the PIN that granted him access at the beginning of the process 2000.

Agent Support Natural Registration Process - Figure 3

At 3000, agent support natural registration process begins. At 3010, an unregistered caller dials a telephone number associated with the ACD or interactive voice response system that represents the target enterprise. 3020, depending on whether the connection to the biomedical complexes 600, 700, 800 is performed in a distributed manner (arbitrary preamble engine is located in front of the main preamble server) or integrated as a function of the main preamble server, And is connected to the preamble engine 200 or the main preamble server 300. Access to the biomedical complexes 600, 700, 800 may be performed by various methods (including the optional preamble engine 200 as a passive listening device in front of the main preamble server 300, or as the main preamble server 300, Including but not limited to using as a shared resource either before or after. This may be achieved by providing access to the biocomplexes 600, 700, 800 via non-telephone access methods (e.g., computer microphones and VoIP devices) as described in the registration subject side 100 of FIG. 1 have.

From the viewpoint of the logical flow, step 3020 performs a function of collecting the sender's gateways such that the sender's gateways can be digitized and stored as biometric keys within the biomedical complexes 600, 700, and 800 irrespective of the topology.

At 3030, the primary preamble system 300 collects a standard personal identification number (PIN) (or consumer or user number) as represented by most of the currently deployed self-service systems. This PIN number used as the first step identification can be entered via the touchtone button or verbally input, as is commonly accomplished by those skilled in the art of interactive voice response.

In a preferred embodiment of the present invention, this PIN number is used to compare consumer records in a standard database to ascertain whether the calling party has already been registered. If it is possible to collect a biological sample from a sender to verify a previous registration of the sender's identity using a match for the stored biometric key of the sender, then the step of collecting the PIN may be skipped arbitrarily.

At 3040, it is determined whether the sender has been pre-registered. If the caller is not registered, an "unregistered state flag" is stored in memory and the flag is used in subsequent sequences to inform the agent that a full agent support natural registration is required, Lt; RTI ID = 0.0 > 550 < / RTI > If it is confirmed that the sender has already been registered, the system will store the confidence score of the current remarks to inform the agent via the desktop widget whether subsequent live validation is appropriate. These utterances will not be required as part of the regular IVR procedure by the arbitrary preamble engine 200 or the main preamble system 300; Regardless, the optional preamble engine 200 function will listen to the recorded speech data and deliver it to the biomedical complexes 600, 700, 800.

At 3050, the algorithm in the PABX or ACD routes the caller to the appropriate agent and at the same time all data stored for the already registered caller or the score of the current speech will be delivered to the appropriate agent registration / verification widget 550. This data is passed to the agent registration / validation widget 550 via the biometric application gateway RESTlet 700 as described in FIG.

In addition, the primary preamble system 300 will extract the agent identity from the ACD / PABX 400 over the common CTI data path and deliver the agent identity to the bioapplication gateway RESTlet 700.

Alternatively, the arbitrary preamble engine 200 may have a CTI data link to the ACD to extract selected agent information. Alternatively, the biometric application gateway RESTlet 700 may extract selected agent identity information via common CTI links. It should be noted that there are various methods of extracting the selected agent information from the ACD or PABX. In addition to the above examples, it is also possible to extract the same information from a real time database. For example, the biometric database 800 as illustrated in FIG. 1 may be used as a shared repository by which the ACD, PABX, or CTI application gateway can inject agent data selected in real time. Such data may be extracted using a third party data proxy as supplied by Oracle Corporation. In addition, the real-time agent selection data may be transmitted from the CTI application gateway to the bio-application gateway RESTlet 700 via real-time HTTP / REST or web service commands.

Alternatively, when a call arrives at the agent desktop at the time of answer management or key press from an agent or a password reminder from an agent, the bioconjugates 600, 700, 800 identify the agent to which the system has dialed, Lt; RTI ID = 0.0 > voice < / RTI > In this scenario, all enterprise agents will register themselves to record the biometric key within the biocomplexes 600, 700, 800. Those skilled in the art will appreciate that such biometric keys are associated with agent names, employee numbers, extensions, and other data within the biometric database 800 to create an agent record in the database. In this way, in-line verification of the identity of the agent can be accomplished without using CTI and without extracting any data from the currently installed legacy IVR or ACD.

At 3060, the agent receives the call and the agent registration / verification widget 550 is synchronized. Synchronization is performed by the CTI method described above or the biometric validated agent itself so that the biometric application gateway RESTlet 700 knows which biometric registration / verification widget 550 should send the sender data.

In a preferred embodiment of the present invention, the arbitrary preamble engine 200 or one of the above equivalents will be used to idle the transmission timeslot on the telephone connection so that the caller needs to tell the agent to perform biometric verification You will not hear the contents. While the agent is verifying, the arbitrary preamble engine 200 may be equipped with a music file for playback to the caller, such as a telephone progress tone and such a special case telephone call tone. Once agent bio-routing is achieved, the telephone ring tone will stop and both parties will hear each other.

At 3070, once the registration / validation widget 550 has been synchronized and the call data and biometric score have been presented to the agent, the agent is ready to begin the validation query, and the sender's answer to that (assuming the sender is already registered , The agent may be used to compare the sender biometric key with the stored biometric key, or, in the case of an already registered sender with a low biometric score, the agent will be ready to capture additional samples to augment the trustworthiness score of the bioengineer.

Also, for a sender who is not yet registered, the sender's first verification question can be asked. The agent registration / validation widget 550 may be equipped with a button that allows the agents to quench their sounds after questioning, so that the biocomplexes 600, 700, 800 only record the text samples from the sender do.

At 3080, the agent determines the score at this point.

At 3090, during normal progress of the live validation, the agent will ask additional verification questions if further questions are required based on the company's policy, or more glossary data is required to complete the registration.

At 3100, the agent determines the score at this point.

At 3110, during normal progress of the live validation, if another query is required based on the company's policy, or if more glossary data is required to complete the registration, the agent will issue a further verification question.

At 3120, the agent may determine based on the answers to the verification steps as to whether the caller is the person claiming to be. The agent may then select a pass or fail button on the agent registration / validation widget 550 and the agent registration / validation widget 550 may then select the pass or fail button on the agent registration / Lt; / RTI >

At 3130, the biometric application gateway RESTlet 700 accesses the biometric database 800 to set the registration / verification success / failure flag in the sender record.

At 3140, if the process fails, the agent may use a standard procedure to reset the PIN generated by the enterprise, as described in step 3030. < RTI ID = 0.0 > This is to ensure that the false sender, who may intend to steal the identity of the actual sender, can not use the PIN that granted him access at the beginning of the process 3000.

Conventional automated verification procedure - FIG. 4

Conventional verification without live agent arbitration

At 4000, a conventional automated verification process begins. At 4010, an unregistered caller dials a telephone number associated with the ACD or interactive voice response system that represents the target enterprise. 4020, depending on whether the connection to the biomedical complexes 600, 700, 800 is performed in a distributed fashion (arbitrary preamble engine is located in front of the main preamble server) or integrated as a function of the main preamble server, And is connected to the preamble engine 200 or the main preamble server 300. Access to the biomedical complexes 600, 700, 800 may be performed by various methods (including the optional preamble engine 200 as a passive listening device in front of the main preamble server 300, or as the main preamble server 300, Including but not limited to using as a shared resource either before or after. This may be achieved by providing access to the biocomplexes 600, 700, 800 via non-telephone access methods (e.g., computer microphones and VoIP devices) as described in the registration subject side 100 of FIG. 1 have.

In view of the logical flow, step 4020 performs a function of collecting the sender's gateways so that the sender's gateways can be digitized and stored as biometric keys within the biocomplexes 600, 700, and 800 irrespective of the topology.

At 4030, the primary preamble system 300 collects a standard personal identification number (PIN) (or consumer or user number) as represented by most of the currently deployed self-service systems. This PIN number used as the first step identification can be entered via the touchtone button or verbally input, as is commonly accomplished by those skilled in the art of interactive voice response.

In a preferred embodiment of the present invention, this PIN number will be used to compare consumer records in a standard database to ascertain whether the calling party has already been registered.

According to a precise embodiment, the step of collecting the PIN may be arbitrarily skipped if it is possible to collect a biological sample from the sender to confirm the previous registration of the sender's identity using the match for the stored biometric key of the sender .

At 4040, a determination is made as to whether the sender has been pre-registered. If the sender is not registered, the "unregistered state flag" is stored in the memory. Which is then used to determine the appropriate call flow to be used by the IVR. If it is confirmed that the sender is not registered, the system performs a registration process or other appropriate process as briefly described in FIG. 2 or FIG.

At 4050, the call flow within the PABX or ACD processes the caller appropriately to complete the verification.

At 4070, the IVR issues a first verification question and collects a user response.

At 4080, it is determined whether sufficient voice data has been collected to complete the verification. If sufficient data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 4130. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu.

If it is determined that insufficient verification voice data is captured at 4080, then a follow-up question will be made at 4090.

At 4100, it is determined whether sufficient voice data has been collected to complete the verification. If sufficient data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 4120. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu.

If it is determined that insufficient verification voice data is captured at 4100, a follow-up question will be made at 4110.

If sufficient data has been collected, the data will be updated in the biometric database, and if an additional transaction is required by the user, the call will be arbitrarily delivered to the agent at 4130. Alternatively, in order to allow the user to select a transaction, control may again be transferred to the upper IVR menu.

If verification fails, the appropriate information will be delivered to the agent. This data is passed to the agent registration / validation widget 550 via the biometric application gateway RESTlet 700 as described in FIG. The agent may then choose to support the user / enrollment subject, perhaps in a similar fashion to that described briefly in Fig.

If verification fails, the caller will be escalated to the agent, and at the same time all data stored for the already registered sender or the score of the current utterance will be delivered to the appropriate agent registration / verification widget 550.

In addition, the primary preamble system 300 will extract the agent identity from the ACD / PABX 400 over the common CTI data path and deliver the agent identity to the bioapplication gateway RESTlet 700.

Alternatively, the arbitrary preamble engine 200 may have a CTI data link to the ACD to extract selected agent information. Alternatively, the biometric application gateway RESTlet 700 may extract selected agent identity information via common CTI links. It should be noted that there are various methods of extracting the selected agent information from the ACD or PABX. In addition to the above examples, it is also possible to extract the same information from a real time database. For example, the biometric database 800 as illustrated in FIG. 1 may be used as a shared repository by which the ACD, PABX, or CTI application gateway can inject agent data selected in real time. Such data may be extracted using a third party data proxy as supplied by Oracle Corporation. In addition, the real-time agent selection data may be transmitted from the CTI application gateway to the bio-application gateway RESTlet 700 via real-time HTTP / REST or web service commands.

Alternatively, when a call arrives at the agent desktop at the time of answer management or key press from an agent or a password reminder from an agent, the bioconjugates 600, 700, 800 identify the agent to which the system has dialed, Lt; RTI ID = 0.0 > voice < / RTI > In this scenario, all enterprise agents will register themselves to record the biometric key within the biocomplexes 600, 700, 800. Those skilled in the art will appreciate that such biometric keys are associated with agent names, employee numbers, extensions, and other data within the biometric database 800 to create an agent record in the database. In this way, in-line verification of the identity of the agent can be accomplished without using CTI and without extracting any data from the currently installed legacy IVR or ACD.

At 4120, the agent receives the call and the agent registration / verification widget 550 is synchronized. Synchronization is performed by the CTI method described above or the biometric validated agent itself so that the biometric application gateway RESTlet 700 knows which biometric registration / verification widget 550 should send the sender data.

In a preferred embodiment of the present invention, the arbitrary preamble engine 200 or one of the above equivalents is used to idle the transmission timeslot on the telephone connection so that the caller needs to speak to the agent to complete the biometric verification I will not listen to the contents. While the agent is verifying, the arbitrary preamble engine 200 may be equipped with a music file for playback to the caller, such as a telephone progress tone and such a special case telephone call tone. Once agent bio-routing is achieved, the telephone ring tone will stop and both parties will hear each other.

At 4140, if the process fails, the agent may use a standard procedure to reset the PIN generated by the enterprise as described in step 4030. [ This is to ensure that a false sender, who may intend to steal the identity of the actual sender, can not use the PIN that granted him access at the beginning of the process (4000).

Agent support validation process - Figure 5

Validating live agent support

At 5000, the live agent support verification process begins. At 3010, an unregistered caller dials a telephone number associated with the ACD or interactive voice response system that represents the target enterprise. 3020, depending on whether the connection to the biomedical complexes 600, 700, 800 is performed in a distributed manner (arbitrary preamble engine is located in front of the main preamble server) or integrated as a function of the main preamble server, And is connected to the preamble engine 200 or the main preamble server 300. Access to the biomedical complexes 600, 700, 800 may be performed by various methods (including the optional preamble engine 200 as a passive listening device in front of the main preamble server 300, or as the main preamble server 300, Including but not limited to using as a shared resource either before or after. This may be achieved by providing access to the biocomplexes 600, 700, 800 via non-telephone access methods (e.g., computer microphones and VoIP devices) as described in the registration subject side 100 of FIG. 1 have.

From the viewpoint of the logical flow, step 5020 performs a function of collecting the sender's gateways so that the sender's gateways can be digitized and stored as biometric keys in the biocomplexes 600, 700, and 800 irrespective of the topology.

At 5030, the primary preamble system 300 collects a standard personal identification number (PIN) (or consumer or user number) as represented by most of the currently deployed self-service systems. This PIN number used for the first step identification can be entered via the touchtone button or verbally input as will be apparent to those skilled in the art of interactive voice response.

In a preferred embodiment of the present invention, this PIN number will be used to compare consumer records in a standard database to ascertain whether the calling party has already been registered.

If it is possible to collect a biological sample from the sender to confirm the previous registration of the sender's identity using the match for the stored biometric key of the sender, then the step of collecting the PIN may be skipped arbitrarily.

At 5040, it is determined whether the caller has been pre-registered. If the sender is not registered, the "unregistered state flag" is stored in memory and at 5045 control is transferred from step 3050 to the process as briefly described in FIG. 3, where the flag is used in subsequent sequences, Full agent support will be pushed to the appropriate agent's agent registration / validation widget 550 to inform the agent that natural registration is required. If it is confirmed that the sender has already been registered, the system will store the confidence score of the current remarks to inform the agent via the desktop widget whether subsequent live validation is appropriate. These utterances will not be required as part of the regular IVR procedure by the arbitrary preamble engine 200 or the main preamble system 300; In any case, the optional preamble engine 200 function will listen to the recorded speech data and deliver it to the biocomplexes 600, 700, 800.

At 5050, the algorithm in the PABX or ACD will route the caller to the appropriate agent and at the same time all data stored for the already registered caller or the score of the current utterance will be delivered to the appropriate agent registration / verification widget 550. This data is passed to the agent registration / validation widget 550 via the biometric application gateway RESTlet 700 as described in FIG.

In addition, the primary preamble system 300 will extract the agent identity from the ACD / PABX 400 over the common CTI data path and deliver the agent identity to the bioapplication gateway RESTlet 700.

Alternatively, the arbitrary preamble engine 200 may have a CTI data link to the ACD to extract selected agent information. Alternatively, the biometric application gateway RESTlet 700 may extract selected agent identity information via common CTI links. It should be noted that there are various methods of extracting the selected agent information from the ACD or PABX. In addition to the above examples, it is also possible to extract the same information from a real time database. For example, the biometric database 800 as illustrated in FIG. 1 may be used as a shared repository by which the ACD, PABX, or CTI application gateway can inject agent data selected in real time. Such data may be extracted using a third party data proxy as supplied by Oracle Corporation. In addition, the real-time agent selection data may be transmitted from the CTI application gateway to the bio-application gateway RESTlet 700 via real-time HTTP / REST or web service commands.

Alternatively, when a call arrives at the agent desktop at the time of answer management or key press from an agent or a password reminder from an agent, the bioconjugates 600, 700, 800 identify the agent to which the system has dialed, Lt; RTI ID = 0.0 > voice < / RTI > In this scenario, all enterprise agents will register themselves to record the biometric key within the biocomplexes 600, 700, 800. These biometric keys are associated with an agent name, an employee number, an extension number, and other data in the biometric database 800 to generate an agent record in the database. In this way, in-line verification of the identity of the agent can be accomplished without using CTI and without extracting any data from the currently installed legacy IVR or ACD.

At 5060, the agent receives the call and the agent registration / verification widget 550 is synchronized. Synchronization is accomplished by the CTI method described above or by an agent verifying itself so that the biometric application gateway RESTlet 700 knows which biometric registration / verification widget 550 should send the sender data.

In a preferred embodiment of the present invention, an arbitrary preamble engine 200 or one of the above equivalents will be used to idle the transmission timeslot on the telephone connection so that the caller needs to speak to the agent to achieve biometric validation You will not hear the contents. While the agent is verifying, the arbitrary preamble engine 200 may be equipped with a music file for playback to the caller, such as a telephone progress tone and such a special case telephone call tone. Once agent bio-routing is achieved, the telephone ring tone will stop and both parties will hear each other.

At 5070, once the registration / validation widget 550 has been synchronized and the phone data and biometric score have been presented to the agent, the agent is ready to begin the validation question, and the sender's answer to that (assuming the sender is already registered , The agent may be used to compare the sender biometric key with the stored biometric key, or, in the case of an already registered sender with a low biometric score, the agent will be ready to capture additional samples to augment the trustworthiness score of the bioengineer.

Also, for a sender who is not yet registered, the sender's first verification question can be asked. The agent registration / validation widget 550 may be equipped with a button that allows the agents to quench their sounds after questioning, so that the biocomplexes 600, 700, 800 only record the text samples from the sender do.

At 5080, the agent determines the score at this point.

At 5090, during normal progress of the live verification, if another query is required based on the company's policy, or if more statement data is required to complete the registration, the agent will ask another verification question.

At 5100, the agent determines the score at this point.

At 5110, during normal progress of the live validation, if another query is required based on the company's policy, or if more glossary data is required to complete the registration, the agent will ask another validation question.

At 5120, the agent may determine based on the answers to the verification steps as to whether the caller is the person claiming to be. The agent can then select a success or failure button on the agent registration / validation widget 550 and the agent registration / validation widget 550 then communicates with the biometric gateway RESTlet 700 that the sender has succeeded or failed.

At 5130, the biometric application gateway RESTlet 700 accesses the biometric database 800 to set a registration / verification success / failure flag within the caller record.

At 5140, if the process fails, the agent may use a standard procedure to reset the PIN generated by the enterprise, as described in step 5030. [ This is to ensure that a false sender, who may intend to steal the identity of the actual sender, can not use the PIN that granted him access at the beginning of the process 5000.

It is therefore to be understood that the appended claims are intended to cover such modifications as would be apparent to those skilled in the art to which the invention pertains, as defined in the claims and their equivalents, as well as to the appended claims. Those skilled in the art will appreciate that various adaptations and modifications of the preferred embodiments described above may be made without departing from the scope of the present invention. The illustrated embodiment has been described above for purposes of illustration only and should not be construed as limiting the invention. It is, therefore, to be understood that within the scope of the appended claims, the invention may be practiced otherwise than as specifically described herein.

Claims (36)

delete delete delete delete delete delete delete delete Registration target side for receiving user voice input via PSTN, SIP, or VoIP; And
A biocomplex for processing speech samples,
Wherein the biocomposite comprises: a bio-engine for receiving the speech samples;
A biometric application gateway for generating biometric keys from the speech samples to compare biometric keys; And
A biomedical database including a biometrics database for storing biometrics keys generated by the biometrics application gateway;
A live agent / subscriber comprising means for sending the voice input of the user to a live agent and for sending voice of the live agent in response to the user;
A registration subsystem for determining the reliability of a user's identity using an input from a user, the method comprising: storing, in a biometric database, biometric keys from a user's voice input if the user is a trustworthy person; A registration subsystem extracted without sampling by the agent / registrant voice input and securing a good biometric key for the user; And
And a verification subsystem for verifying the user by determining whether the user matches the stored biometric key using voice input from the user. delete 10. The biometric listening apparatus of claim 9, further comprising an ability to extract exclusive agent / registrant sentence data without sampling client / registrant sentence data to obtain a good biometric token sample for the agent. delete delete delete delete delete delete delete delete delete delete delete delete 10. The living body listening apparatus according to claim 9, which is applied to a speech recognition system. The living body listening apparatus according to claim 9, which is applied to a softphone and a VoIP network. delete delete delete delete 10. The biometric listening device of claim 9, further comprising a registration widget for receiving and displaying results from the biocomplex, and receiving and executing commands from the live agent. 31. The living body listening apparatus of claim 30, wherein the live agent determines success / failure of a pending registration. 32. The apparatus of claim 31, wherein the determination is based on a user's answer to registration questions. The living body listening apparatus of claim 30, wherein the live agent determines success / failure of pending verification. 34. The apparatus according to claim 33, wherein the determination is based on an output from the biometric application gateway. 34. The apparatus according to claim 33, wherein the determination is based on a user's answer to verification questions. 34. The apparatus according to claim 33, wherein the determination is based on an output from a biometric application gateway and information provided by a user.

Images