Patent Description:
Corporate entities and individuals alike can be affected, to varying degrees, by unauthorized accesses to confidential information. As such, whether access is to a physical object (e.g., a computer, a building, an office, etc.), an online account, or a storage medium, access is oftentimes restricted to only those who are authorized such access. However, certain technologies for authenticating authorized access have been proven to be fairly easily circumvented. For example, access cards can be lost, passwords can be compromised, etc. As such, various biometric recognition techniques have been implemented in an effort to increase the security of authentication procedures, as the biometric indicators are generally considered to be unique to the individual and not easily replicated. For example, such biometric recognition techniques include iris scans, retina scans, fingerprint scans, facial recognition systems, speaker recognition systems, heart rate monitors, etc..

Speaker recognition systems rely on voice biometrics, or voice characteristics, to verify a person based on their speech, such as for authentication purposes, which is commonly referred to as speaker verification or speaker authentication in such context. Speaker verification consists of comparing a speaker' s speech with only the speech of the person to be authenticated, which has been previously stored in the database, in order to determine that the person requesting authentication (i.e., speaking) is who they claim to be. However, present technologies rely on features of speech signal pertaining to filter/vocal tract (i.e., source-filter models of speech production) of the speaker. Such source-filter model filter/vocal tract technologies typically only rely on filter parameters. Accordingly, there exists a need for improvements in technologies for authenticating a speaker using voice biometrics.

Kinnunen et al (<NUM>) "An overview of text-independent speaker recognition" (XP26699600) gives an overview of the fundamentals of automatic speech recognition. It discusses how speech signals can be used for speaker discrimination.

<CIT> discloses a method for forming the excitation signal for a glottal pulse model based parametric speech synthesis system.

<CIT> discloses a system and method for forming the excitation signal for a glottal pulse model based parametric speech synthesis system.

The invention sets out a method for authenticating a speaker in a voice authentication system using voice biometrics according to claim <NUM> and speech authentication computing device for authenticating a speaker in a voice authentication system using voice biometrics according to claim <NUM>.

The embodiments and other features, advantages and disclosures contained herein, and the manner of attaining them, will become apparent and the present disclosure will be better understood by reference to the following description of various exemplary embodiments of the present disclosure taken in conjunction with the accompanying drawings, wherein:.

<FIG> is an illustrative voice authentication system <NUM> for authenticating a speaker <NUM> using voice biometrics that includes a speech collection computing device <NUM> and a speech authentication computing device <NUM>. In an illustrative example, the speaker <NUM> speaks (see, e.g., the speech utterance <NUM>) into a speech collector (e.g., the microphone <NUM>) of the speech collection computing device <NUM>. The speech collector is configured to convert the speech utterance <NUM> into a speech signal and transmits the speech signal to the speech authentication computing device <NUM>. The pitch of the speaker's voice is usually set by the frequency of glottal pulses (i.e., short bursts of air) during vowels or voiced consonants. Accordingly, the speech authentication computing device <NUM> is configured to determine the glottal pulses of the speech signal and compute a unique measurement (e.g., a feature vector) that is usable to identify the speaker <NUM> by their voice.

In an illustrative embodiment, upon receiving the speech signal of the speaker <NUM> from the speech collection computing device <NUM>, the speech authentication computing device <NUM> can authenticate the speaker <NUM>. To authenticate the speaker <NUM>, the speech authentication computing device <NUM> is configured to compute a feature vector of the speaker <NUM> based on the received speech signal and feed the computed feature vector to a previously trained two-class statistical classifier associated with the speaker <NUM>. Based on the output of the speech signal classifier, the speech authentication computing device <NUM> is configured to determine whether the speaker <NUM> was authenticated. Accordingly, as a result of the authentication determination, the speaker <NUM> may be authorized or denied access to a particular asset/location.

The speech collection computing device <NUM> is primarily configured to function as a resource for obtaining a speech utterance <NUM> from a speaker <NUM>. However, it should be appreciated that, in some embodiments, the speech collection computing device <NUM> may be configured to perform other functions, such as one or more of those functions described herein as being performed by the speech authentication platform <NUM>. In other words, in other embodiments, the functions described herein as being performed by the speech collection computing device <NUM> and the speech authentication computing device <NUM>, respectively, may be performed by a single computing device or system of networked computing devices. The speech collection computing device <NUM> may be embodied as, but is not limited to, one or more desktop computers, mobile computing devices (e.g., a smartphone, a wearable, a tablet, a laptop, a notebook, etc.), access control system devices, and/or any other type of computing device capable of collecting a speech utterance <NUM> from a speaker <NUM>.

Referring now to <FIG>, an illustrative speech collection computing device <NUM> includes a central processing unit (CPU) <NUM>, an input/output (I/O) controller <NUM>, a main memory <NUM>, network communication circuitry <NUM>, a data storage device <NUM>, and I/O peripherals <NUM>. In some alternative embodiments, the computing device <NUM> may include additional, fewer, and/or alternative components to those of the illustrative speech collection computing device <NUM>, such as a graphics processing unit (GPU). It should be appreciated that one or more of the illustrative components may be combined on a single system-on-a-chip (SoC) on a single integrated circuit (IC).

Additionally, it should be appreciated that the type of components and/or hardware/software resources of the speech collection computing device <NUM> may be predicated upon the type and intended use of the speech collection computing device <NUM>. For example, the speech collection computing device <NUM> embodied as an access control device may include one or more access control components, such as a camera, a card reader <NUM>, etc. Accordingly, it should be appreciated that the voice authentication system <NUM> as described herein may be used in conjunction with other authentication technologies, in some embodiments.

The CPU <NUM>, or processor, may be embodied as any combination of hardware and circuitry capable of processing data. In some embodiments, the speech collection computing device <NUM> may include more than one CPU <NUM>. Depending on the embodiment, the CPU <NUM> may include one processing core (not shown), such as in a single-core processor architecture, or multiple processing cores, such as in a multi-core processor architecture. Irrespective of the number of processing cores and CPUs <NUM>, the CPU <NUM> is capable of reading and executing program instructions. In some embodiments, the CPU <NUM> may include cache memory (not shown) that may be integrated directly with the CPU <NUM> or placed on a separate chip with a separate interconnect to the CPU <NUM>. It should be appreciated that, in some embodiments, pipeline logic may be used to perform software and/or hardware operations (e.g., network traffic processing operations), rather than commands issued to/from the CPU <NUM>.

The I/O controller <NUM>, or I/O interface, may be embodied as any type of computer hardware or combination of circuitry capable of interfacing between input/output devices and the speech collection computing device <NUM>. Illustratively, the I/O controller <NUM> is configured to receive input/output requests from the CPU <NUM>, and send control signals to the respective input/output devices, thereby managing the data flow to/from the speech collection computing device <NUM>.

The memory <NUM> may be embodied as any type of computer hardware or combination of circuitry capable of holding data and instructions for processing. Such memory <NUM> may be referred to as main or primary memory. It should be appreciated that, in some embodiments, one or more components of the speech collection computing device <NUM> may have direct access to memory, such that certain data may be stored via direct memory access (DMA) independently of the CPU <NUM>.

The network communication circuitry <NUM> may be embodied as any type of computer hardware or combination of circuitry capable of managing network interfacing communications (e.g., messages, datagrams, packets, etc.) via wireless and/or wired communication modes. Accordingly, in some embodiments, the network communication circuitry <NUM> may include a network interface controller (NIC) capable of being configured to connect the speech collection computing device <NUM> to a computer network (e.g., a local area network (LAN)), as well as other devices, depending on the embodiment.

The data storage device <NUM> may be embodied as any type of computer hardware capable of the non-volatile storage of data (e.g., semiconductor storage media, magnetic storage media, optical storage media, etc.). Such data storage devices <NUM> are commonly referred to as auxiliary or secondary storage, and are typically used to store a large amount of data relative to the memory <NUM> described above.

Each of the I/O peripherals <NUM> may be embodied as any type of auxiliary device configured to connect to and communicate with the speech collection computing device <NUM>. As illustratively shown, the I/O peripherals <NUM> includes a microphone <NUM> and, in some embodiments, a card reader <NUM>. However, it should be appreciated that, depending on the embodiment of the speech collection computing device <NUM>, the I/O peripherals <NUM> may include additional and/or alternative I/O devices, such as, but not limited to, a camera, a display, a speaker, a mouse, a keyboard, a touchscreen, a printer, a scanner, etc. Accordingly, it should be appreciated that some I/O devices are capable of one function (i.e., input or output), or both functions (i.e., input and output).

In some embodiments, the I/O peripherals <NUM> may be connected to the speech collection computing device <NUM> via a cable (e.g., a ribbon cable, a wire, a universal serial bus (USB) cable, a high-definition multimedia interface (HDMI) cable, etc.) connected to a corresponding port (not shown) of the speech collection computing device <NUM> through which the communications made therebetween can be managed by the I/O controller <NUM>. In alternative embodiments, the I/O peripherals <NUM> may be connected to the speech collection computing device <NUM> via a wireless mode of communication (e.g., Bluetooth®, Wi-Fi®, etc.) which may be managed by the network communication circuitry <NUM>.

Referring again to <FIG>, the speech collection computing device <NUM> is communicatively coupled to the speech authentication computing device via a network <NUM>. The network <NUM> may be implemented as any type of wired and/or wireless network, including a WLAN/LAN, a wide area network (WAN), a global network (the Internet), etc.. Accordingly, the network <NUM> may include one or more communicatively coupled network computing devices (not shown) for facilitating the flow and/or processing of network communication traffic via a series of wired and/or wireless interconnects. Such network computing devices may include, but are not limited, to one or more access points, routers, switches, servers, compute devices, storage devices, etc. It should be appreciated that the speech collection computing device <NUM> and the speech authentication computing device <NUM> may use different networks (e.g., LANs, provider networks, etc.) to connect to the backbone of the network <NUM> such that a number of communication channels can be established therein to enable communications therebetween.

The speech authentication computing device <NUM> may be embodied as one or more servers (e.g., stand-alone, rack-mounted, etc.), compute devices, storage devices, and/or combination of compute blades and data storage devices (e.g., of a storage area network (SAN)) in a cloud architected network or data center. It should be appreciated that, in some embodiments, the speech authentication computing device <NUM> may be embodied as more than one computing device (e.g., in a distributed computing architecture), each of which may be usable to perform at least a portion of the functions described herein of the speech authentication computing device <NUM>. Accordingly, in such embodiments, it should be further appreciated that one or more computing devices of the speech authentication computing device <NUM> may be configured as a database server with less compute capacity and more storage capacity relative to another of the computing devices of the speech authentication computing device <NUM>. Similarly, one or more other computing devices of the speech authentication computing device <NUM> may be configured as an application server with more compute capacity relative and less storage capacity relative to another of the computing devices of the speech authentication computing device <NUM>.

Referring now to <FIG>, an illustrative speech authentication computing device <NUM> includes a CPU <NUM>, an I/O controller <NUM>, a main memory <NUM>, network communication circuitry <NUM>, and a data storage device <NUM>. It should be appreciated that such components may be similar to those components of the illustrative speech collection computing device <NUM> of <FIG>, which were described previously. Accordingly, the illustrative components of the speech authentication computing device <NUM> are not described herein to preserve clarity of the description.

As shown in <FIG>, the illustrative speech authentication computing device <NUM> includes a speech authentication platform <NUM>. Referring now to <FIG>, an illustrative environment <NUM> of the speech authentication platform <NUM> is shown. The speech authentication platform <NUM> may be embodied as any combination of hardware, firmware, software, or circuitry usable to perform the functions described herein. The speech authentication platform <NUM> includes one or more computer-readable medium (e.g., the memory <NUM>, the data storage device <NUM>, and/or any other media storage device) having instructions stored thereon and one or more processors (e.g., the CPU <NUM>) coupled with the one or more computer-readable medium and configured to execute instructions to perform the functions described herein.

The illustrative environment <NUM> includes a glottal pulse database <NUM>, a feature vector database <NUM>, and an authorized speaker database <NUM>. While the glottal pulse database <NUM>, the feature vector database <NUM>, and the authorized speaker database <NUM> are illustratively shown as residing on the speech authentication platform <NUM>, in some embodiments, one or more of the glottal pulse database <NUM>, the feature vector database <NUM>, and the authorized speaker database <NUM> may be located remote of the speech authentication platform <NUM> (e.g., on dedicated storage devices). It should be appreciated that, in some embodiments, the illustrative databases described herein may be combined or further segregated. Additionally or alternatively, it should be further appreciated that the data stored therein may not be mutually exclusive to the respective database as described herein.

In some embodiments, access to the data provided to and/or generated as described herein may require authorization and/or that such data is encrypted while in storage and/or transit. Accordingly, in some embodiments, one or more authentication and/or encryption technologies known to those of skill in the art may be employed to ensure the storage and access to the data complies with any legal and/or contractual requirements. It should be further appreciated that, in some embodiments, the data stored in the respective databases may not be mutually exclusive. In other words, certain data described herein as being stored in one database may additionally or alternatively be stored in another database described herein, or another database altogether. It should be further appreciated that, in some embodiments, the data may be stored in a single database, or an alternative database / data storage arrangement.

The illustrative speech authentication platform <NUM> includes a glottal pulse manager <NUM>, a feature vector generator <NUM>, a background data manager <NUM>, a speech enrollment manager <NUM>, and a speaker authenticator <NUM>, each of which may be embodied as any type of firmware, hardware, software, circuitry, or combination thereof that is configured to perform the functions described herein. While the functionality of the speech authentication platform <NUM> is described herein as being performed by a particular component or set of components, it should be appreciated that, in other embodiments, the speech authentication platform <NUM> may include additional and/or alternative components for performing the functions described herein.

The glottal pulse manager <NUM> is configured to extract glottal pulses from the speech signals received by the speech authentication platform <NUM>. In some embodiments, the extracted glottal pulses may be stored in the glottal pulse database <NUM>. To extract the glottal pulses, the glottal pulse manager <NUM> is configured to extract, from a pre-emphasized speech signal of the received speech signal, one or more linear prediction coefficients (e.g., on an order of <NUM> for a sampling rate of <NUM>). The glottal pulse manager <NUM> is further configured to form an inverse filter as a function of the extracted linear prediction coefficients and obtain an inverse filtered signal (i.e., an approximation of the glottal excitation) as a function of the inverse filter and the received speech signal. Additionally, the glottal pulse manager <NUM> is configured to segment the inverse filtered signal into a number of glottal pulses, such as by using zero frequency filtering techniques.

It should be appreciated that the energy of the glottal pulses are not uniform in the spectral domain, and are usually high in low frequency, which can result in a metric between two pulses depending more on matching at the low frequencies, thereby reducing the accuracy of the matching (e.g., for authentication purposes described below) in the low frequencies. Accordingly, to remedy this deficiency, the glottal pulse manager <NUM> is configured to decompose each glottal pulse into three sub-band pulses, apply a metric between corresponding sub-band pulses, and associate the overall metric with the respective glottal pulse. To do so, the glottal pulse manager <NUM> is configured to transform a glottal pulse into the frequency domain, such as by using a discrete cosine transform.

The glottal pulse manager <NUM> is further configured to identify two sharp change points in the spectrum that may be used as cut-off frequencies, such as may be identified by applying zero frequency resonator techniques on the discrete cosine transform of the glottal pulse. Additionally, the glottal pulse manager <NUM> is configured to segment the spectrum into three bands based on the two cut-off frequencies. It should be appreciated that, in certain embodiments, one or both of the cut-off frequencies may not be determinable. In such embodiments, a predetermined cut-off frequency (e.g., <NUM>, <NUM>, <NUM>, <NUM>, etc.) may be used. In an illustrative embodiment in which neither cut-off frequency is determinable, the predetermined cut-off frequencies may be <NUM> and <NUM>. The glottal pulse manager <NUM> is additionally configured to convert the three bands into the time domain to get three sub-band pulses of the glottal pulse. It should be appreciated that, in some embodiments, the sub-band pulses may be associated with the corresponding glottal pulse and stored in the glottal pulse database <NUM>.

The glottal pulse manager <NUM> is also configured to perform metric-based clustering of the glottal pulses. In an illustrative embodiment, the glottal pulse manager <NUM> is also configured to perform the metric-based clustering of the glottal pulses using a modified k-means clustering algorithm. To do so, the glottal pulse manager <NUM> is configured to replace the Euclidean distance metric of the traditional k-means clustering algorithm with a metric d(x,y) defined for two glottal pulses x and y. As such, the glottal pulse manager <NUM> is configured to determine a metric, or notion of distance (i.e., d(x, y)), between the two glottal pulses (i.e., x and y).

To determine the metric, the glottal pulse manager <NUM> is configured to decompose each of the glottal pulses into their respective three sub-band pulses (e.g., x(<NUM>), x(<NUM>), x(<NUM>)), as described above, such that each of the sub-band pulses has the same length. Accordingly, the glottal pulse manager <NUM> is configured to determine the metric between two glottal pulses x and y using the following equation: <MAT> wherein ds(f, g) is the sub-band metric between any two pulses f, g. The glottal pulse manager <NUM> is additionally configured to determine the normalized circular cross correlation between f and g using the following equation: <MAT>.

The glottal pulse manager <NUM> is further configured to determine the highest of the lengths f, g as a function of the period for circular correlation and linearly extend the shorter signal(s). Additionally, the glottal pulse manager <NUM> is configured to compute Rh(n) as the discrete Hilbert transform of R(n) to obtain the signal using the following equation: <MAT> wherein the glottal pulse manager <NUM> is configured to determine the cosine of the angle (θ) between the two signals f and g using the following equation: <MAT> wherien supnH(n) corresponds to the maximum value among all the samples of signal H(n). As such, the glottal pulse manager <NUM> is further configured to determine the metric d(f, g) using the following equation: <MAT>.

In addition to replacing the Euclidean distance metric of the traditional k-means clustering algorithm, the glottal pulse manager <NUM> is additionally configured to update the centroids of the clusters in a different manner than the traditional k-means clustering algorithm. To do so, given a cluster of glottal pulses whose elements are denoted as {g<NUM>, g<NUM>,. gN}, the centroid (i.e., the medoid) is considered as element gc, such that the following equation: <MAT> is the minimum for m = c. The glottal pulse manager <NUM> is further configured to terminate the clustering iterations when there is no shift in any of the centroids of the k clusters.

The feature vector generator <NUM> is configured to generate a feature vector for a glottal pulse associated with a speaker (e.g., the speaker <NUM> of <FIG>) that is usable to identify that speaker by their voice. To generate the feature vector, the feature vector generator <NUM> is configured to assign each pulse in the glottal pulse database having a size L to the closes cluster centroid, based on the distance metric, given a global pulse xi, and assuming c<NUM>, c<NUM>,. cN are the centroid glottal pulses determined by the previously performed clustering (e.g., by the glottal pulse manager <NUM>). Assuming the total number of elements assigned to a centroid cj is nj, the feature vector generator <NUM> is configured to define the following equation: <MAT> wherein x<NUM> is a fixed glottal pulse selected from the glottal pulse database. It should be appreciated that, while the choice of the x<NUM> selected from the glottal pulse database should not affect the accuracy of the voice authentication system <NUM>, the x<NUM> selected from the glottal pulse database should be maintained constant.

The feature vector generator <NUM> is further configured to determine the vector representation (Vi) for the sub-band pulse xi using the following equation: <MAT> The feature vector generator <NUM> is also configured to store the calculated feature vector for every glottal pulse extracted from the speech signal. It should be appreciated that the feature vectors may be associated with a corresponding speaker and/or glottal pulse and stored in the feature vector database, in some embodiments.

Additionally, the feature vector generator <NUM> is configured to determine the feature vector for each speech signal. To determine the feature vector, the feature vector generator <NUM> is configured to obtain an eigenvector for each of the feature vectors associated with a glottal pulse. To obtain the eigenvector, the feature vector generator <NUM> is configured to perform a principal component analysis (PCA) on the collection of feature vectors associated with a glottal pulse (e.g., such as may be stored in the glottal pulse database <NUM>).

To perform the PCA, the feature vector generator <NUM> is configured to determine the mean vector (i.e., vmean) of the entire vector database {vi} and subtract the mean vector from each vector to obtain mean subtracted vectors {ui}. The feature vector generator <NUM> is further configured to compute eigenvectors of the covariance matrix of the collection of vectors {ui} and select the eigenvector corresponding to the highest eigenvalue as the feature vector for that speech signal. The selected feature vectors may be stored in the feature vector database <NUM>, in some embodiments.

The background data manager <NUM> is configured to create and manage the background data usable to train a statistical classifier for a speaker during enrollment in the voice authentication system <NUM>. To create the background data, the background data manager <NUM> is configured to collect a predetermined number of speech signals (e.g., <NUM> speech signals, <NUM> speech signals, <NUM> speech signals, etc.) from a predetermined number of speakers (e.g., <NUM> speakers, <NUM> speakers, <NUM> speakers, etc.). Upon collection, the background data manager <NUM> is configured to transmit each speech signal to the respective component(s) for feature vector computation (e.g., as may be performed by the feature vector generator <NUM>). Upon each feature vector being computed, the background data manager <NUM> is further configured to classify each computed feature vector as being rejected and associated with the background data. In some embodiments, the background data may be stored in the rejected vector database <NUM>.

The speech enrollment manager <NUM> is configured to train a classifier for a speaker during enrollment in the voice authentication system <NUM> such that the speaker can be authenticated using their voice. To do so, the speech enrollment manager <NUM> is configured to collect a predetermined number of speech signals (e.g., <NUM> speech signals, <NUM> speech signals, <NUM> speech signals, etc.) for a duration of time (e.g., <NUM> seconds, <NUM> seconds, <NUM> seconds, etc.) from a speaker. Upon collection, the background data manager <NUM> is configured to transmit each speech signal to the respective component(s) for feature vector computation (e.g., as may be performed by the feature vector generator <NUM>). Upon each feature vector being computed, the background data manager <NUM> is further configured to classify each computed feature vector as being authenticated and associated with the speaker.

The speech enrollment manager <NUM> is additionally configured to train a stastical classifier with two classes: authenticated and rejected. As noted previously, the rejected class refers to the background data, such as may be created by the background data manager <NUM>. For example, in some embodiments, the background data manager <NUM> may be configured to use a two-class support vector machine (SVM) classifier with a cosine similarity metric. The resulting speech signal classifier may be associated with the speaker and stored in the authorized speaker database <NUM>, in some embodiments. To ensure consistency, it should be appreciated that the background data should remain fixed and the same two-class statistical classifier employed for each speaker.

The speaker authenticator <NUM> is configured to authenticate a speaker as a function of the previously trained speech signal classifier and a speech signal received from the speaker during an authentication attempt. To do so, the speaker authenticator <NUM> is configured to collect a speech signal from a speaker attempting to authenticate their identity. Upon collection, the speaker authenticator <NUM> is configured to transmit the received speech signal to the respective component(s) for feature vector computation (e.g., as may be performed by the feature vector generator <NUM>).

Upon the feature vector being computed, the speaker authenticator <NUM> is further configured to feed the computed feature vector to the trained speech signal classifier (e.g., as may be performed by the speech enrollment manager <NUM>) associated with that speaker. Additionally, the speaker authenticator <NUM> is configured to determine whether to authenticate the user as a function of the output of the speech signal classifier. In other words, the speaker authenticator <NUM> is configured to determine whether the speaker is authenticated or rejected based on the output of the speech signal classifier, such that the determination may be used by an access control system to either permit or deny access to the speaker.

Referring now to <FIG> and <FIG>, an illustrative method <NUM> is provided for creating background data (i.e., a background data collection phase), which may be executed by the speech authentication computing device <NUM>, or more particularly the speech authentication platform <NUM> of the speech authentication computing device <NUM>. The method <NUM> begins in block <NUM>, in which the speech authentication platform <NUM> determines whether to create the background data. If so, the method <NUM> advances to block <NUM>, in which the speech authentication platform <NUM> collects a speech signal from a speaker (e.g., the speaker <NUM> of <FIG>). As described previously, a speech utterance (i.e., the speaker's voice) is received by a speech collection computing device (e.g., the speech collection computing device <NUM> of <FIG>) and the converted speech signal is transmitted to the speech authentication computing device <NUM> for analysis by the speech authentication platform <NUM>.

In block <NUM>, the speech authentication platform <NUM> pre-emphasizes the collected speech signal. It should be appreciated that pre-emphasizing the speech signal comprises the speech signal being filtered using a finite impulse response filter with coefficients <NUM>, -<NUM>. In block <NUM>, the speech authentication platform <NUM> extracts linear prediction coefficients from the pre-emphasized signal. In block <NUM>, the speech authentication platform <NUM> forms an inverse filter from the extracted linear prediction coefficients. In block <NUM>, the speech authentication platform <NUM> filters the speech signal using the inverse filter to obtain an inverse filtered signal. In block <NUM>, the speech authentication platform <NUM> segments the inverse filtered signal into a number of glottal pulses. To do so, in some embodiments, in block <NUM>, the speech authentication platform <NUM> segments the inverse filtered signal using zero frequency filtering techniques.

In block <NUM>, the speech authentication platform <NUM> stores each glottal pulse in a glottal pulse database (e.g., the glottal pulse database <NUM> of <FIG>). In block <NUM>, the speech authentication platform <NUM> determines whether a required number of speech signals have been collected. As described previously, creating the background data requires a collecting a predetermined number of speech signals (e.g., <NUM> speech signals, <NUM> speech signals, <NUM> speech signals, etc.) from a predetermined number of speakers (e.g., <NUM> speakers, <NUM> speakers, <NUM> speakers, etc.). If the speech authentication platform <NUM> determines the required number of speech signals have not been collected, the method <NUM> returns to block <NUM> to collect a speech signal from that same speaker or another speaker; otherwise, the method <NUM> advances to block <NUM> (shown in <FIG>).

In block <NUM>, the speech authentication platform <NUM> decomposes each glottal pulse into three sub-band pulses. To do so, in block <NUM>, the speech authentication platform <NUM> transforms each glottal pulse into the frequency domain using a discrete cosine transform. Additionally, in block <NUM>, the speech authentication platform <NUM> determines two sharp change points (i.e., the cut-off frequencies) of each discrete cosine transform signal using zero frequency resonator techniques. Further, in block <NUM>, the speech authentication platform <NUM> splits each discrete cosine transform signal into three sub-bands as a function of the determined cut-off frequencies. As described previously, in certain embodiments, one or both of the cut-off frequencies may not be determinable, in which case a predetermined cut-off frequency may be used. Additionally, in block <NUM>, the speech authentication platform <NUM> converts the three sub-bands into time domain, which results in the three sub-bands being converted into three sub-band pulses for the corresponding glottal pulse.

In block <NUM>, the speech authentication platform <NUM> performs a metric-based clustering as a function of the glottal pulses. As described previously, the speech authentication platform <NUM> performs the metric-based clustering of the glottal pulses using a modified k-means clustering algorithm. In block <NUM>, the speech authentication platform <NUM> computes a feature vector for each glottal pulse, which has been described previously (see the description of the feature vector generator <NUM> of <FIG> described above). In block <NUM>, the speech authentication platform <NUM> stores each glottal pulse feature vector in a feature vector database (e.g., the feature vector database <NUM> of <FIG>). Additionally, in block <NUM>, the speech authentication platform <NUM> associates each stored glottal pulse feature vector with its corresponding glottal pulse.

In block <NUM>, the speech authentication platform <NUM> computes a feature vector for each speech signal. To do so, as described previously, in block <NUM> the speech authentication platform <NUM> performs a PCA on the collection of feature vectors associated with a glottal pulse (e.g., such as may be stored in the glottal pulse database <NUM>) to compute the corresponding eigenvectors. Additionally, in block <NUM> the speech authentication platform <NUM> determines the feature vector as a function of the eigenvalues associated with the computed eigenvectors. As also described previously, the speech authentication platform <NUM> selects the eigenvector corresponding to the highest eigenvalue as the feature vector for that speech signal. In block <NUM>, the speech authentication platform <NUM> stores each speech signal feature vector in the feature vector database. Additionally, in block <NUM>, the speech authentication platform <NUM> classifies each speech signal feature vector as being rejected.

Referring now to <FIG>, an illustrative method <NUM> is provided for training a statistical classifier for authenticating a speaker (i.e., an enrollment and training phase), which may be executed by the speech authentication computing device <NUM>, or more particularly the speech authentication platform <NUM> of the speech authentication computing device <NUM>. The method <NUM> begins in block <NUM>, in which the speech authentication platform <NUM> determines whether to perform enrollment of a speaker (e.g., the speaker <NUM> of <FIG>). For example, the speech authentication platform <NUM> may determine that a new speaker (e.g., that is authorized access to an asset/location) is being added to the voice authentication system <NUM>.

If so, the method <NUM> advances to block <NUM>, in which the speech authentication platform <NUM> collects a speech signal from a speaker. As described previously, a speech utterance (i.e., the speaker's voice) is received by a speech collection computing device (e.g., the speech collection computing device <NUM> of <FIG>) and the converted speech signal is transmitted to the speech authentication computing device <NUM> for analysis by the speech authentication platform <NUM>. In block <NUM>, the speech authentication platform <NUM> computes a feature vector for the collected speech signal (see, e.g., the speech signal feature vector generation described in block <NUM> of the method <NUM>). In block <NUM>, the speech authentication platform <NUM> stores the authenticated speech signal feature vector in a feature vector database (e.g., the feature vector database <NUM> of <FIG>). Additionally, in block <NUM>, the speech authentication platform <NUM> classifies the authenticated speech signal feature vector as being authenticated.

As described previously, the speech authentication platform <NUM> collects a predetermined number of speech signals over a duration of time from the speaker. Accordingly, in block <NUM> the speech authentication platform <NUM> determines whether the required number of speech signals has been collected to enroll the speaker. If not, the method <NUM> returns to block <NUM> to collect another speech signal; otherwise, the method <NUM> advances to block <NUM>. In block <NUM>, the speech authentication platform <NUM> trains a two-class statistical classifier as a function of the feature vector classifications: authorized and rejected. To do so, in some embodiments, in block <NUM>, the speech authentication platform <NUM> uses a two-class SVM classifier with a cosine similarity metric. In block <NUM>, the speech authentication platform <NUM> stores the trained classifier of the speech signal (i.e., the speech signal classifier) in an authorized speaker database (e.g., the authorized speaker database <NUM> of <FIG>). Additionally, in block <NUM>, the speech authentication platform <NUM> associates the speech signal classifier with the speaker.

Referring now to <FIG>, an illustrative method <NUM> is provided authenticating a speaker (i.e., an authentication phase), which may be executed by the speech authentication computing device <NUM>, or more particularly the speech authentication platform <NUM> of the speech authentication computing device <NUM>. The method <NUM> begins in block <NUM>, in which the speech authentication platform <NUM> determines whether to perform authentication of a speaker (e.g., the speaker <NUM> of <FIG>). For example, the speech authentication platform <NUM> may determine that a speaker (e.g., that may or may not be authorized access to an asset/location) is requesting access to a particular asset/location secured at least in part by the voice authentication system <NUM>.

If so, the method <NUM> advances to block <NUM>, in which the speech authentication platform <NUM> collects a speech signal from a speaker. As described previously, a speech utterance (i.e., the speaker's voice) is received by a speech collection computing device (e.g., the speech collection computing device <NUM> of <FIG>) and the converted speech signal is transmitted to the speech authentication computing device <NUM> for analysis by the speech authentication platform <NUM>. In block <NUM>, the speech authentication platform <NUM> computes a feature vector for the collected speech signal (see, e.g., the speech signal feature vector generation described in block <NUM> of the method <NUM>). In block <NUM>, the speech authentication platform <NUM> retrieves a speech signal classifier associated with the speaker from an authorized speaker database (e.g., the authorized speaker database <NUM> of <FIG>).

In block <NUM>, the speech authentication platform <NUM> feeds the speech signal feature vector for that speaker to the retrieved speech signal classifier associated with that speaker. In block <NUM>, the speech authentication platform <NUM> receives an output from the speech signal classifier indicating whether the speech signal has been authorized or rejected. In block <NUM>, the speech authentication platform <NUM> determines whether the speaker is authenticated as a function of the output received from the speech signal classifier.

If the speech authentication platform <NUM> determines the speaker has been authenticated, the method <NUM> branches to block <NUM>, in which the speech authentication platform <NUM> provides an indication to the speaker (e.g., via the speech collection computing
device <NUM>) that they were authenticated; otherwise, the method <NUM> branches to block <NUM>, in which the speech authentication platform <NUM> provides an indication to the speaker (e.g., via the speech collection computing device <NUM>) that they are not authorized access. It should be appreciated that, in some embodiments, the authentication indication may be further processed (e.g., in conjunction with other access technologies) to make a final authentication decision.

Claim 1:
A method for authenticating a speaker in a voice authentication system (<NUM>) using voice biometrics, the method comprising:
receiving, by a speech authentication computing device (<NUM>), a speech signal of a speaker collected by a speech collection computing device (<NUM>);
computing, by the speech authentication computing device (<NUM>), a speech signal feature vector for the received speech signal,
wherein computing the speech signal feature vector comprises
(i) segmenting the speech signal into a plurality of glottal pulses,
(ii) computing a glottal pulse feature vector for each of the plurality of glottal pulses by decomposing each of the glottal pulses into three sub-band pulses, performing a metric-based clustering as a function of the glottal pulses and the corresponding three sub-band pulses, and computing the glottal pulse feature vectors as a function of a result of the metric-based clustering,
and (iii) computing the speech signal feature vector as a function of the glottal pulse feature vectors;
retrieving, by the speech authentication computing device (<NUM>), a speech signal classifier associated with the speaker;
feeding, by the speech authentication computing device (<NUM>), the speech signal feature vector to the retrieved speech signal classifier; and
determining, by the speech authentication computing device (<NUM>), whether the speaker is an authorized speaker based on an output of the retrieved speech signal classifier.