U.S. patent application number 16/259717 was filed with the patent office on 2019-08-22 for system and method for providing controlled environment resident status.
The applicant listed for this patent is GLOBAL TEL*LINK CORPORATION. Invention is credited to Stephen Lee HODGE.
Application Number | 20190258819 16/259717 |
Document ID | / |
Family ID | 65032099 |
Filed Date | 2019-08-22 |
![](/patent/app/20190258819/US20190258819A1-20190822-D00000.png)
![](/patent/app/20190258819/US20190258819A1-20190822-D00001.png)
![](/patent/app/20190258819/US20190258819A1-20190822-D00002.png)
![](/patent/app/20190258819/US20190258819A1-20190822-D00003.png)
![](/patent/app/20190258819/US20190258819A1-20190822-D00004.png)
![](/patent/app/20190258819/US20190258819A1-20190822-D00005.png)
United States Patent
Application |
20190258819 |
Kind Code |
A1 |
HODGE; Stephen Lee |
August 22, 2019 |
SYSTEM AND METHOD FOR PROVIDING CONTROLLED ENVIRONMENT RESIDENT
STATUS
Abstract
Disclosed herein are system, method, and computer program
product embodiments for providing controlled environment resident
statuses. In an embodiment, a resident status communication system
communicates with non-resident communication devices via audio
calls and/or textual messages to provide inmate statuses as well as
information related to the operation and administration of a
correctional facility. The resident status communication system
receives requests for information from the non-resident
communication devices, determines whether the non-resident is
authorized to access the requested information, and provides the
requested information in a natural language format to facilitate
the user experience. The resident status communication system also
allows law enforcement officials and/or correctional facility staff
to maintain statuses related to inmates and selectively distribute
this information to authorized non-residents.
Inventors: |
HODGE; Stephen Lee; (Aubrey,
TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
GLOBAL TEL*LINK CORPORATION |
Reston |
VA |
US |
|
|
Family ID: |
65032099 |
Appl. No.: |
16/259717 |
Filed: |
January 28, 2019 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
15724618 |
Oct 4, 2017 |
10192070 |
|
|
16259717 |
|
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 21/32 20130101;
G06F 21/6245 20130101; G06Q 50/26 20130101; G06F 21/44 20130101;
G06F 16/685 20190101 |
International
Class: |
G06F 21/62 20060101
G06F021/62; G06F 21/32 20060101 G06F021/32 |
Claims
1. A resident status communication system, comprising: a memory
that stores a list of authorized individuals; and one or more
processors and/or circuits coupled to the memory, wherein the one
or more processors and/or circuits are configured to: receive a
request for correctional facility information from a communication
device, wherein the request is received as audio data; request
audio identification information from the communication device
related to the user of the communication device; search the list of
authorized individuals for information matching the audio
identification information, wherein the audio identification
information was previously added to the list of authorized
individuals based on a previously completed registration process of
the user of the communication device; and in response to
identifying information matching the audio identification
information based on the search, transmit the correctional facility
information as computer-generated audio data to the communication
device.
2. The resident status communication system of claim 1, wherein the
correctional facility information includes statistics related to
inmate recreational activities.
3. The resident status communication system of claim 1, wherein the
correctional facility information includes an amount of funding
available in an inmate account.
4. The resident status communication system of claim 1, wherein the
correctional facility information includes correctional facility
visitation hours.
5. The resident status communication system of claim 1, wherein the
one or more processors and/or circuits are further configured to:
store a record associating the request with the audio
identification information in the memory.
6. The resident status communication system of claim 1, wherein to
transmit the correctional facility information as
computer-generated audio data, the one or more processors and/or
circuits are further configured to: package the correctional
facility information using natural language processing.
7. The resident status communication system of claim 1, wherein the
one or more processors and/or circuits are configured to perform
the search by: converting the audio identification information to a
textual format to generate textual identification information;
comparing the textual identification information with textual
entries of the list of authorized individuals; and designating a
match in response to identifying a textual entry that matches the
textual identification information.
8. The resident status communication system of claim 1, wherein the
one or more processors and/or circuits are further configured to:
in response to identifying information matching the audio
identification information based on the searching, fetch the
correctional facility information from a resident status database
located in a correctional facility.
9. A method, comprising: receiving, from a first communication
device, first data requesting personal information related to a
first inmate; prompting the first communication device for first
identification data related to a first non-inmate; authenticating
the first communication device based on the first identification
data; transmitting the personal information related to the first
inmate to the first communication device in response to
authenticating the first communication device; receiving, from a
second communication device, second data requesting personal
information related to a second inmate; prompting the second
communication device for second identification data related to a
second non-inmate, wherein the second identification data is a
different type of identification data than the first identification
data; authenticating the second communication device based on the
second identification data; and transmitting the personal
information related to the second inmate to the second
communication device in response to authenticating the second
communication device.
10. The method of claim 9, wherein the first identification data
includes a government identification number and wherein the second
identification data includes biometric data.
11. The method of claim 9, wherein prompting the first
communication device for first identification data utilizes a
natural language textual response process and wherein prompting the
second communication device for second identification data utilizes
a natural language interactive voice response process.
12. The method of claim 9, wherein: data associated with the first
inmate indicates that the first inmate has been charged with a
first crime; data associated with the second inmate indicates that
the second inmate has been charged with a second crime; the type of
identification data of the first identification data is associated
with the first crime; and the type of identification data of the
second identification data is associated with the second crime.
13. The method of claim 9, wherein the type of identification data
of the first identification data is associated with a request for
information related to inmate activity within a correctional
facility and wherein the type of identification data of the second
identification data is associated with a request for judiciary
information related to the inmate.
14. The method of claim 9, further comprising: storing a record of
the first data and first identification data against metadata
associated with the first communication device.
15. A method, comprising: receiving a request for correctional
facility information from a communication device, wherein the
request is received as audio data; requesting audio identification
information from the communication device related to the user of
the communication device; searching the list of authorized
individuals for information matching the audio identification
information; and in response to identifying information matching
the audio identification information based on the search,
transmitting the correctional facility information as
computer-generated audio data to the communication device.
16. The method of claim 15, wherein the correctional facility
information includes correctional facility visitation hours.
17. The method of claim 15, further comprising: storing a record
associating the request with the audio identification information
in the memory.
18. The method of claim 15, wherein transmitting the correctional
facility information as computer-generated audio data, further
comprises: packaging the correctional facility information using
natural language processing.
19. The method of claim 15, wherein the searching further
comprises: converting the audio identification information to a
textual format to generate textual identification information;
comparing the textual identification information with textual
entries of the list of authorized individuals; and designating a
match in response to identifying a textual entry that matches the
textual identification information.
20. The method of claim 15, further comprising: in response to
identifying information matching the audio identification
information based on the searching, fetching the correctional
facility information from a resident status database located in a
correctional facility.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application is a Continuation of U.S. patent
application Ser. No. 15/724,618 filed on Oct. 4, 2017, now U.S.
Pat. No. 10,192,070 which is hereby incorporated by reference in
its entirety.
BACKGROUND
Field
[0002] The disclosure relates to a system and method for providing
information and statuses related to a controlled environment
resident.
Background
[0003] After an arrest or conviction, an individual suspected of
committing a crime is incarcerated in a jail or prison. During the
inmate's stay, non-residents, such as friends or family members,
often seek information related to the inmate. For example, family
members request information related to inmate communication methods
and costs, depositing funds into inmate accounts, visitation hours
or rules, and/or how to send items to the inmate. Additionally,
non-residents seek information related to an inmate status, such
as, for example, whether the inmate has visited the infirmary, if
the inmate has borrowed books, the amount of money in an inmate
account, or relevant court dates or parole hearing dates for the
inmate.
[0004] Law enforcement officials or correctional facility staff may
not have the resources for handling a large volume of these
requests for information or may be wastefully expending resources
to handle these requests. Also, for example, correctional facility
staff may not even manage inmate statuses in a manner accessible to
the public or utilize an effective means for monitoring requests
for information from non-residents.
BRIEF DESCRIPTION OF THE DRAWINGS
[0005] The accompanying drawings are incorporated herein and form a
part of the specification.
[0006] FIG. 1 illustrates a block diagram of a resident status
communication environment, according to exemplary embodiments.
[0007] FIG. 2 illustrates a block diagram of a resident status
communication system, according to exemplary embodiments.
[0008] FIG. 3 illustrates a flowchart illustrating a method for
identifying non-residents in a serial manner and reporting resident
statuses, according to exemplary embodiments.
[0009] FIG. 4 illustrates a flowchart illustrating a method for
identifying non-residents in a parallel manner and reporting
resident statuses, according to exemplary embodiments.
[0010] FIG. 5 illustrates an example computer system useful for
implementing various embodiments.
[0011] The present disclosure will be described with reference to
the accompanying drawings. In the drawings, like reference numbers
generally indicate identical or similar elements. Additionally,
generally, the left-most digit(s) of a reference number identifies
the drawing in which the reference number first appears.
DETAILED DESCRIPTION
[0012] The following Detailed Description refers to accompanying
drawings to illustrate exemplary embodiments consistent with the
disclosure. References in the Detailed Description to "one
exemplary embodiment," "an exemplary embodiment," "an example
exemplary embodiment," etc., indicate that the exemplary embodiment
described may include a particular feature, structure, or
characteristic, but every exemplary embodiment may not necessarily
include the particular feature, structure, or characteristic.
Moreover, such phrases are not necessarily referring to the same
exemplary embodiment. Further, when a particular feature,
structure, or characteristic is described in connection with an
exemplary embodiment, it is within the knowledge of those skilled
in the relevant art(s) to affect such feature, structure, or
characteristic in connection with other exemplary embodiments
whether or not explicitly described.
[0013] The exemplary embodiments described herein are provided for
illustrative purposes, and are not limiting. Other exemplary
embodiments are possible, and modifications may be made to the
exemplary embodiments within the spirit and scope of the
disclosure. Therefore, the Detailed Description is not meant to
limit the invention. Rather, the scope of the invention is defined
only in accordance with the following claims and their
equivalents.
[0014] Embodiments may be implemented in hardware (e.g., circuits),
firmware, software, or any combination thereof. Embodiments may
also be implemented as instructions stored on a machine-readable
medium, which may be read and executed by one or more processors. A
machine-readable medium may include any mechanism for storing or
transmitting information in a form readable by a machine (e.g., a
computing device). For example, a machine-readable medium may
include read only memory (ROM); random access memory (RAM);
magnetic disk storage media; optical storage media; flash memory
devices; electrical, optical, acoustical or other forms of
propagated signals (e.g., carrier waves, infrared signals, digital
signals, etc.), and others. Further, firmware, software, routines,
instructions may be described herein as performing certain actions.
However, it should be appreciated that such descriptions are merely
for convenience and that such actions in fact result from computing
devices, processors, controllers, or other devices executing the
firmware, software, routines, instructions, etc. Further, any of
the implementation variations may be carried out by a general
purpose computer, as described below.
[0015] For purposes of this discussion, any reference to the term
"module" shall be understood to include at least one of software,
firmware, or hardware (such as one or more circuit, microchip, or
device, or any combination thereof), and any combination thereof.
In addition, it will be understood that each module may include
one, or more than one, component within an actual device, and each
component that forms a part of the described module may function
either cooperatively or independently of any other component
forming a part of the module. Conversely, multiple modules
described herein may represent a single component within an actual
device. Further, components within a module may be in a single
device or distributed among multiple devices in a wired or wireless
manner.
[0016] The following Detailed Description of the exemplary
embodiments will so fully reveal the general nature of the
invention that others can, by applying knowledge of those skilled
in relevant art(s), readily modify and/or adapt for various
applications such exemplary embodiments, without undue
experimentation, without departing from the spirit and scope of the
disclosure. Therefore, such adaptations and modifications are
intended to be within the meaning and plurality of equivalents of
the exemplary embodiments based upon the teaching and guidance
presented herein. It is to be understood that the phraseology or
terminology herein is for the purpose of description and not of
limitation, such that the terminology or phraseology of the present
specification is to be interpreted by those skilled in relevant
art(s) in light of the teachings herein.
[0017] Provided herein are system, apparatus, device, method and/or
computer program product embodiments for providing information and
statuses related to a controlled environment resident.
[0018] In an embodiment, the systems and methods described herein
maintain status information related to residents of a jail or
prison. For example, a resident status communication system
maintains personal information related to the inmates of a
correctional facility as well as information related to the
operation and administration of the correctional facility.
Correctional facility staff and law enforcement officials are also
able to update information stored on the resident status
communication system or a resident status database. When a
non-resident contacts a correctional facility via a phone call or
website, the resident status communication system intercepts the
incoming request.
[0019] In an embodiment, the resident status communication system
receives an information request from a non-resident communication
device. For example, the information request is a phone call from a
non-resident to the correctional facility. The resident status
communication system initiates an interactive voice response (IVR)
system using artificial intelligence and rules-based natural
language processing algorithms as well as a response monitoring
system to monitor responses provided. In an embodiment, the IVR
system requests identification information from the non-resident so
that the resident status communication system can authenticate the
non-resident prior to delivering inmate status information. For
example, the resident status communication system utilizes a
whitelist to determine non-residents authorized to receive personal
inmate details. The resident status communication system then
interacts with the nonresident via the IVR system to facilitate
requested information.
[0020] In an embodiment, the requested information relates to
administrative or operations details of the correctional facility.
For example, the non-resident may ask about visitation hours or
package delivery instructions. In these cases, the resident status
communication system may not require authentication of the
non-resident or may require a lower-level of authentication
relative to the amount required to access personal details related
to the inmate. In this manner, correctional facility staff or law
enforcement officials are able to customize information provided by
the resident status communication system and/or the level of
authentication required for a non-resident to obtain information.
Also, correctional facility staff or law enforcement officials are
able to monitor information requests and conduct further
investigations if the resident status communication system detects
suspicious activity, such as, for example, a request from a
suspected co-conspirator. The resident status communication system
records these requests and allows law enforcement officials to
search these records based on the name or prisoner identification
of the inmate.
[0021] FIG. 1 illustrates a block diagram of a resident status
communication environment 100, according to exemplary embodiments.
In an embodiment, resident status communication environment 100
includes a resident status communication system 110, a resident
status database 120, network 130, non-resident communication
devices 140A, 140B, . . . , 140n, correctional facility reporting
system 150, and law enforcement reporting system 160.
[0022] Resident status communication system 110 includes one or
more processors, memory, servers, routers, modems, and/or antennae
configured to interface with resident status database 120, network
130, non-resident communication devices 140A, 140B, . . . , 140n,
correctional facility reporting system 150, and/or law enforcement
reporting system 160. Resident status communication system 110 is a
system that receives requests from non-resident communication
devices 140 for information related to the operation or
administration of a correctional facility and/or personal
information related to an inmate. Non-resident communication
devices 140 may be a phone, tablet, and/or computer. In an
embodiment, non-resident communication devices 140 are equipped
with telephony capabilities and request information via a phone
call to resident status communication system 110. In an embodiment,
non-resident communication devices 140 include display screens and
communicate with resident status communication system 110 via a web
browser or installed application.
[0023] To communicate with resident status communication system
110, non-resident communication devices 140 utilize network 130
and/or a network protocol to send and receive data over network
130. Network 130 is a network capable of transmitting information
either in a wired or wireless manner and may be, for example,
telephone cables or wiring, the Internet, a Local Area Network
(LAN), or a Wide Area Network (WAN). The network protocol may be,
for example, a hypertext transfer protocol (HTTP), a TCP/IP
protocol, User Datagram Protocol (UDP), Ethernet, cellular,
Bluetooth, an asynchronous transfer mode, Plain old telephone
service (POTS), or Voice over IP (VoIP), to name just a few
examples, or any combination thereof.
[0024] After receiving an initial request for information, such as
via a phone call or web access request, resident status
communication system 110 utilizes artificial intelligence and
rules-based natural language processing algorithms to interact with
the non-resident communication device 140 requesting information.
For example, resident status communication system 110 utilizes an
interactive voice response (IVR) system to communicate with the
non-resident communication device 140. In an embodiment, if a
non-resident communication device 140 initializes an information
request via a web browser or an application, resident status
communication system 110 generates a graphical user interface
display allowing the resident status communication system 110 to
submit data or information to resident status communications system
110. Communicating with non-resident communication device 140 via
an IVR or graphical user interface design system allows for a more
user-friendly method of requesting information from and/or
providing information to non-resident communication device 140.
[0025] In an embodiment, after initializing a channel of
communication with a non-resident communication device 140 via
network 130, resident status communication system 110 initializes
an authorization procedure to determine the identity of the
non-resident seeking information and/or to provide the information
sought. Identifying, verifying, authenticating, and/or authorizing
allows correctional facility staff or law enforcement officials to
control the information provided by resident status communication
system 110. For example, correctional facility staff may be legally
obligated not to provide personal inmate information to the public
but may be allowed to provide the information to family members. In
an embodiment, to protect the inmate's privacy, resident status
communication system 110 first authenticates the non-resident
requesting the information. FIG. 3 and FIG. 4 illustrate
embodiments of methods for authenticating and verifying individuals
as well as providing requested information.
[0026] To authenticate a non-resident, resident status
communication system 110 utilizes an IVR or graphical user
interface design system to request non-resident identification
information from the non-resident communication device 140
requesting inmate information. Non-resident identification
information includes, for example, a name, birthday, residence
address, relationship to the inmate, social security number,
government identification number (e.g., driver's license), contact
information, biometric data such as a voiceprint, fingerprint data,
facial recognition data, and/or retina scanner data, and/or other
information for identifying an individual.
[0027] After receiving the non-resident identification information,
resident status communication system 110 authenticates the
individual and determines whether the individual is authorized to
receive information related to the inmate. In an embodiment, to
verify the individual, resident status communication system 110
compares the received non-resident identification information to a
list of approved individuals, such as a whitelist. Law enforcement
officials and/or correctional facility staff may define this list.
In an embodiment, resident status communication system 110 stores
this list in an internal memory and/or an external memory, such as,
for example, resident status database 120.
[0028] In an embodiment, resident status communication system 110
associates each inmate with a list of approved non-residents. When
a non-resident communication device 140 submits an information
request, the information request includes an inmate identifier,
such as a name and/or prisoner identification number. After
receiving the information request, resident status communication
system 110 identifies the particular inmate associated with the
received information request. Resident status communication system
110 then utilizes a list of approved non-residents associated with
the particular inmate to determine if the non-resident requesting
the information is authorized to receive the information.
[0029] Resident status communication system 110 searches the list
associated with the inmate to determine if the provided
non-resident identification information matches information stored
on the list. The information stored on the list includes, for
example, a name, birthday, residence address, relationship to the
inmate, social security number, government identification number
(e.g., driver's license), contact information, biometric data such
as a voiceprint, fingerprint data, facial recognition data, and/or
retina scanner data, and/or other information for identifying an
individual. For example, in an embodiment, resident status
communications system 110 compares a provided name and/or social
security number in the non-resident identification information to
the names and associated social security numbers included on the
list. If the provided name and social security number matches a
listed name and social security number, then resident status
communication system 110 confirms the identity of the non-resident
as being an approved individual. Resident status communication
system 110 notes that the approved individual may receive
information related to the inmate. In an embodiment, to generate
the list, resident status communications system 110 communicates
with a third party database (such as a governmental agency
database) to confirm provided non-resident information.
[0030] In an embodiment, the non-resident has completed a
registration process in the past and resident status communication
system 110 verifies the provided non-resident identification
information against this registered information. For example, the
non-resident may create an account and/or provide biometric data to
be saved. If approved, resident status communications system 110
may utilize this biometric data in future access attempts to verify
the identity of the non-resident. To verify the identity of the
non-resident, the provided non-resident identification information
includes biometric data and the biometric data is compared to other
stored biometric data in the list associated with the inmate.
Resident status communication system 110 identifies the
non-resident as approved if a match in biometric data is found in a
search of the list. In an embodiment, resident status communication
system 110 stores lists and associated inmate information in memory
internal to resident status communication system.
[0031] In an embodiment, resident status database 120 stores the
lists of approved individuals associated with inmates. Resident
status database 120 is memory external to resident status
communication system 110. In an embodiment, resident status
database 120 maintains statuses and personal information related to
the inmates. After resident status communication system 110
verifies that an non-resident is authorized to access personal
information related to an inmate, resident status communication
system 110 retrieves the personal information from resident status
database 120. Personal information or inmate status includes, for
example, the offense for which the inmate is charged, offenses
committed by an inmate while residing at a correctional facility
(e.g., violence or disruption), whether the inmate has visited the
infirmary including dates or reason for visit, if the inmate has
borrowed books including the titles, quantity, or duration of
rental, if the inmate has borrowed an electronic device such as a
tablet or computer including the applications or content accessed
(e.g., websites, movies, music, video games) and duration of
rental, other recreational activities, the amount of money in an
inmate account, such as a commissary account, items purchased using
a commissary account, and/or relevant court dates/times, parole
hearing dates/times, or release date/times.
[0032] Correctional facility staff and/or law enforcement officials
are able to update the information stored in resident status
database 120. In an embodiment, correctional facility staff
utilizes a correctional facility reporting system 150. Correctional
facility reporting system 150 may be a phone, tablet, laptop
computer, and/or desktop computer capable of communicating with
resident status communication system 110 and/or resident status
database 120. Correctional facility reporting system 150 may be
wired to communicate with resident status communication system 110.
In an embodiment, resident status communications system 110 is
located remote from correctional facility reporting system 150 and,
correctional facility reporting system 150 communicates with
resident status communication system 110 via network 130. For
example, correctional facility reporting system 150 may utilize an
application installed on correctional facility reporting system 150
to communicate or may utilize an Internet browser to
communicate.
[0033] In an embodiment, law enforcement officials utilize law
enforcement reporting system 160. Law enforcement reporting system
160 may be a phone, tablet, laptop computer, and/or desktop
computer capable of communicating with resident status
communication system 110 and/or resident status database 120. Law
enforcement reporting system 160 may be wired to communicate with
resident status communication system 110. In an embodiment,
resident status communications system 110 is located remote from
law enforcement reporting system 160 and, law enforcement reporting
system 160 communicates with resident status communication system
110 via network 130. For example, law enforcement reporting system
160 may utilize an application installed on law enforcement
reporting system 160 to communicate or may utilize an Internet
browser to communicate.
[0034] Utilizing correctional facility reporting system 150 or law
enforcement reporting system 160, correctional facility staff
and/or law enforcement officials are able to update the information
stored in resident status database 120. In an embodiment,
correctional facility reporting system 150 and law enforcement
reporting system 160 access and edit records stored in resident
status database 120 representing personal information related to an
inmate. For example, if a hearing date for the inmate has changed,
law enforcement reporting system 160 is able to transmit data to
resident status database 120 to update the record stored in
resident status database 120. When an authorized non-resident
communication device 140 attempts to access this information,
resident status communication system 110 is able to retrieve the
updated hearing date and return the date to the non-resident
communication device.
[0035] In an embodiment, to provide updated status information
correctional facility reporting system 150 and/or law enforcement
reporting system 160 communicate with resident status communication
system 110 to store new information in resident status database
120. Resident status communication system 110 and resident status
database 120 also allow for correctional facility reporting system
150 and law enforcement reporting system 160 to share information
regarding inmates such that correctional facility staff is informed
of issues related to non-incarcerated individuals and so that law
enforcement officials are informed about inmate statuses from
within a correctional facility.
[0036] In an embodiment, resident status communication system 110
can interface with existing hardware at a correctional facility or
can be adapted to receive phone calls to a phone number associated
with the correctional facility. Resident status communication
system 110 also stores information related to the administration or
operation of the correctional facility. In an embodiment, resident
status database 120 stores this information. Based on the requested
information from a non-resident communication device 140, resident
status communication system 110 is able to report information
related to the administration or operation of the correctional
facility.
[0037] In an embodiment, if a non-resident communication device is
requesting information about the correctional facility rather than
personal information related to an inmate, resident status
communication system 110 requires a less stringent requirement for
authentication. For example, resident status communication system
110 only requires a name rather than a name and a social security
number. In an embodiment, resident status communication system 110
does not require authentication if non-personal information is
requested, delivering information to the public if the information
is not confidential.
[0038] For example, if the requested information relates to the
cost of a phone call with an inmate, how to deposit funds into an
inmate account, the visitation hours and visitation rules of the
correctional facility, available methods of communications with
inmates generally, how to deliver a letter or package to an inmate,
the cost of an item at a prison commissary, and/or other
information related to the administration or operation of the
correctional facility, resident status communication system 110
will provide this information without requiring the level of
authentication and security needed to access personal inmate
information.
[0039] In an embodiment, however, a correctional facility may
choose not to publicly disseminate this information or portions of
this information to maintain confidentiality and/or reduce threats
to security. Using correctional facility reporting system 150,
correctional facility staff is able to adjust rules related to
authentication and authorization and specify which types of
information require which levels of authorization. With this
customization, correctional facility staff are able to generate a
spectrum of information ranging from information available to the
public to confidential information that only certain individuals
may access. In an embodiment, different types of identification
information may be define. In an embodiment, the type of
identification information required is based on the inmate. For
example, a first inmate may require biometric data to access
personal information related to the first inmate while a second
inmate may require a social security number to access personal
information related to the second inmate. In an embodiment,
resident status communication system 110 determines the type of
information required based on the level of confidentiality
associated with the inmate and/or the information sought. In an
embodiment, resident status communication system 110 determines the
type of information required based on the crime with which the
inmate is charged.
[0040] After determining that a non-resident is authorized to
access personal information related to an inmate and/or information
related to correctional facility administration and operation,
resident status communication system 110 transmits this information
to the non-resident communication device 140 requesting the
information via network 130. In an embodiment, the resident status
communication system 110 delivers the requested information using
an IVR system. For example, residents status communication system
110 authenticates the non-resident using non-resident communication
device 140 using the IVR system and returns requested information
using the same IVR system. In an embodiment, a computer-generated
voice relays the information to non-resident communication device
140. The computer-generated voice then prompts the non-resident
communication device 140 to provide any additional information
requests. These information requests may be verbal, and resident
status communication system 110 is able to analyze and process
these requests using speech recognition algorithms, artificial
intelligence, and machine learning to identify the inquiry and
relevant information.
[0041] In an embodiment, resident status communication system 110
communicates with non-resident communication device 140 via an
application installed on non-resident communication device 140
and/or a website or Internet browser. In an embodiment, resident
status communication system 110 is able to interface with different
non-resident communication devices 140 communicating via different
means with resident status communication system 110 and provide
corresponding answers. For example, resident status communication
system 110 is able to maintain a phone call with non-resident
communication device 140A while maintaining a textual chat exchange
with non-resident communication device 140B.
[0042] As information is requested and/or retrieved, resident
status communication system 110 is able to monitor and/or generate
a record of non-resident communication device 140 interactions with
resident status communication system 110. For example, resident
status communication system 110 logs information requested as well
as information presented. In an embodiment, resident status
communication system 110 stores a record of the request and
provided identification data against metadata related to the first
communication device, such as, for example, an IP address and/or
caller ID information. Using these records, correctional facility
staff or law enforcement officials are able to utilize resident
status communication system 110 and determine if suspicious
activity is occurring.
[0043] In an embodiment, resident status communication system 110
also implements a monetization scheme for providing information to
non-resident communication devices 140. For example, to access
personal inmate information, resident status communication system
110 may charge an account and/or credit card before supplying the
requested information. Resident status communication system 110 may
charge based on the information sought or grant access to
information for a one-time fee. In an embodiment, even with the
monetization system, resident status communication system 110 will
still first authenticate a non-resident communication device 140
prior to supplying requested information.
[0044] FIG. 2 illustrates a block diagram of a resident status
communication system 200, according to exemplary embodiments. In an
embodiment, resident status communication system 200 operates in a
manner similar to resident status communication system 110 as
described with reference to FIG. 1. Resident status communication
system 200 includes but is not limited to processing subsystem 210
and internal memory 260. Processing subsystem 210 includes one or
more processors, computers, or servers identified as subsystems and
can be constructed as individual physical hardware devices, or as
virtual devices, such as a virtual server. The number of processing
subsystems 210 can be scaled to match the number of simultaneous
user connections desired to be supported by a resident status
communication system such as resident status communication system
110 of FIG. 1. Processing subsystem 210 includes but is not limited
to authentication subsystem 220, inmate profile subsystem 230,
communication subsystem 240, and native language subsystem 250.
[0045] In some embodiments, communication subsystem 240 controls
the routing of communications including voice data and/or Internet
browser exchanges between resident status communication system 110
and non-resident communication devices 140. Communication subsystem
240 also controls the routing of communications exchanged with
resident status database 120, correctional facility reporting
system 150, and law enforcement reporting system 160. Communication
subsystem 240 also routes data from non-resident communication
device 140 to the appropriate subsystems within resident status
communication system 200 for processing of the data. For example,
communication system routes voice data received from a non-resident
communication device 140 to native language subsystem 250. In an
embodiment, communication subsystem 240 communicates with
correctional facility reporting system 150 and/or law enforcement
reporting system 160 to receive updates related to inmate profile
information stored on resident status database 120 and/or internal
memory 260. Internal memory 260 may be a hard disk drive, solid
state drive, database, and/or other data repository. Communication
subsystem 240 routes updates to inmate profile subsystem 230 to
process the updates. Communication system 240 also retrieves
requested information and delivers the requested information
external to resident status communication system 200.
[0046] In an embodiment, authentication subsystem 220 performs
authentication functions for authenticating non-resident
communication devices 140. Authentication subsystem 220 receives
non-resident identification information from non-residents
utilizing non-resident communication devices 140. Non-resident
identification information includes, for example, a name, birthday,
residence address, relationship to the inmate, social security
number, government identification number (e.g., driver's license),
contact information, biometric data such as a voiceprint,
fingerprint data, facial recognition data, and/or retina scanner
data, and/or other information for identifying an individual.
Non-resident identification information can also include but is not
limited to at least one of a username and password data, challenge
questions, challenge answers, device data such as make and model of
a communication device, and/or location data related to the
non-resident communication device 140. Biometric data includes one
or more of a finger print, a hand print, a voice sample, an iris or
retinal sample, a facial image of the user (2D or 3D), a gait
identification, a hand geometry, a signature identification, an
infrared camera identification, or any other biometric as deemed
appropriate. Authentication subsystem 220 has biometric
capabilities and analyzes voice data to determine the identities of
parties in the voice data. Authentication subsystem 220 then is
able to determine whether the identified parties are allowed to
request personal inmate information. Authentication subsystem 220
further assists in establishing a secure communication between
non-resident communication devices 140 and resident status
communication system 200.
[0047] In an embodiment, authentication subsystem 220 maintains
rules for determining a level of authentication required for
allowing a non-resident communication device to access personal
inmate data. For example, authentication subsystem 220 may require
a non-resident communication device 140 to provide a name and
social security number before authorizing the non-resident.
Authentication subsystem 220 also performs the check of received
identification data with lists of approved individuals maintained
by inmate profile subsystem 230.
[0048] Authentication subsystem 220 also generates notifications
and alerts to correctional facility staff and/or law enforcement
agents. These notifications may be transmitted from resident status
communication system 200 to correctional facility reporting system
150 and/or law enforcement reporting system 160. For example,
authentication subsystem 220 triggers a notification when a
particular non-resident communication device 140 has initiated a
large volume of information requests.
[0049] Authentication subsystem 220 interfaces with inmate profile
subsystem 230 after authenticating a non-resident communication
device 140 and authorizing the non-resident communication device
140 to receive requested information. If the non-resident
communication device 140 is requesting personal information related
to an inmate, inmate profile subsystem 230 retrieves the requested
personal information. Inmate profile subsystem 230 retrieves the
information from resident status database 120 and/or internal
memory 260. In an embodiment, resident status database 120 may
store the inmate information external to resident status
communication system 200 because the inmate profile information is
confidential or securely maintained by correctional facility staff
and/or law enforcement officials. Inmate profile subsystem 230 is
able to generate the proper requests and/or utilize the proper
database protocols to fetch the requested information.
[0050] In an embodiment, if a portion of requested information is
stored in resident status database 120 and a portion of the
requested information is stored in internal memory 260, inmate
profile subsystem 230 is able to access both memory repositories
and package the information to be transmitted to the requesting
non-resident communication device 140. For example, inmate profile
subsystem 230 is able to handle a request for information that
requires information from both memories and/or is able to handle
two requests that require information from one memory and then the
other memory.
[0051] For example, in an embodiment, a non-resident communication
device 140 may first request the visiting hours of the correctional
facility. The general visiting hours are stored in internal memory
260. Inmate profile subsystem 230 retrieves this information from
internal memory 260 to be delivered to the requesting non-resident
communication device 140. In a subsequent request, the non-resident
communication device 140 requests the specific times that a
particular inmate is available for visitation. This information may
be stored in resident status database 120. Inmate profile subsystem
230 recognizes the location of information storage and queries
resident status database 120 for this specific information. In an
embodiment, internal memory 260 creates local copies and/or mirrors
of resident status database 120. In an embodiment, inmate profile
subsystem 230 periodically copies residents status database 120
and/or updates internal memory 260 when resident status database
120 is updated. In an embodiment, resident status database 120
notifies resident status communication system 200 of updates
provided by correctional facility staff and/or law enforcement
officials.
[0052] After retrieving requested information from internal memory
260 or resident status database 120, inmate profile subsystem 230
passes the information to native language subsystem 250. Native
language subsystem 250 converts the requested information into
natural language to present to non-resident communication device
140. In an embodiment, native language subsystem 250 utilizes
natural language processing algorithms to select appropriate words,
syntax, semantics, and grammar to package the requested
information. If non-resident communication device 140 is
communicating with resident status communication system 200 via a
phone call, native language subsystem 250 synthesizes a
computer-generated voice to respond to non-resident communication
device 140. If non-resident communication device 140 is
communication with resident status communication system 200 via a
web browser or in a textual form, native language subsystem 250
generates a textual message, such as an email or chat message, that
is sent to non-resident communication device 140.
[0053] In addition to generating response to information requests,
native language subsystem 250 also receives the information
requests and parses the information requests to determine the
information requested. For example, native language subsystem 250
utilizes speech-to-text algorithms to convert audio data to textual
data. Authentication subsystem 220 and inmate profile subsystem 230
are then able to utilize this textual data to perform keyword
comparisons to authenticate a non-resident communication device
and/or to perform keyword comparisons to identify the type of
information sought.
[0054] FIG. 3 illustrates a flowchart illustrating a method 300 for
identifying non-residents in a serial manner and reporting resident
statuses, according to exemplary embodiments. Method 300 shall be
described with reference to FIG. 1; however, method 300 is not
limited to that example embodiment.
[0055] In an embodiment, resident status communication system 110
utilizes method 300 to authenticate non-residents, determine the
information requested by the non-resident, and/or supply the
information requested. The foregoing description will describe an
embodiment of the execution of method 300 with respect to resident
status communication system 110. While method 300 is described with
reference to resident status communication system 110, method 300
may be executed on any computing device, such as, for example, the
computer system described with reference to FIG. 5 and/or
processing logic that may comprise hardware (e.g., circuitry,
dedicated logic, programmable logic, microcode, etc.), software
(e.g., instructions executing on a processing device), or a
combination thereof.
[0056] It is to be appreciated that not all steps may be needed to
perform the disclosure provided herein. Further, some of the steps
may be performed simultaneously, or in a different order than shown
in FIG. 3, as will be understood by a person of ordinary skill in
the art.
[0057] In an embodiment, at 310, resident status communication
system 110 receives an information request from a non-resident
communication device 140. The information request includes a
question concerning operational or administrative procedures of a
correctional facility and/or a request for personal information
related to an inmate. In an embodiment, the information request
also includes an inmate identification, such as an inmate name or
prison identification number. In an embodiment, the information
request is a voice call initiated by a non-resident communication
device 140. The information requested may take the form of a
question and/or a statement. In an embodiment, the information
request is provided in response to a greeting and/or a
computer-generated voice prompt initialized by resident status
communication system 110.
[0058] In an embodiment, the information request also includes a
selection from a menu using a dial-tone keypad, such as a dual-tone
multi-frequency signaling (DTMF) protocol. If the resident status
communication system 110 is interacting with the non-resident
communication device 140 via a textual communication such as an
Internet browser or application, the information request is a
textual question and/or selection. For example, resident status
communication system 110 generates chat graphical user interface
display and sends instructions to non-resident communication device
140 to display the graphical user interface on a display screen. A
non-resident is then able to interact with the graphical user
interface and supply information requests to resident status
communication system 110 using textual messages.
[0059] In an embodiment, non-resident communication device 140 may
supply an incomplete and/or indiscernible information request to
resident status communication system 110. For example, resident
status communication system 110 may receive a partial question,
partial identification, and/or nonsense words that do not specify
what information is requested. Resident status communication system
110 identifies incomplete and/or indiscernible information requests
using natural language speech to text and/or textual analysis
algorithms. In these cases, resident status communication system
110 alerts the non-resident communication device 140 that the
information request was unclear and/or prompts the non-resident
communication device 140 to submit another information request.
[0060] At 320, if resident status communication system 110 receives
a complete information request, resident status communication
system 110 analyzes the information request to determine if the
non-resident communication device is seeking personal inmate
information. In an embodiment, resident status communication system
110 converts an audio information request into textual information
and scans the textual information for keywords related to personal
information. For example, resident status communication system 110
utilizes a predefined list of keywords to identify personal
information sought. If one or more of the words spoken in the
information request matches a keyword from the predefined list,
resident status communication system 110 recognizes that
non-resident communication system 110 is seeking personal inmate
information. Similarly, if the received information request is in a
textual form, resident status communication system 110 identifies
keywords in the text information. At 330, based on an analysis of
the information request, resident status communication system 110
determines whether personal information is sought.
[0061] At 340, if resident status communication system 110
determines that the information request is not seeking personal
information, resident status communication system 110 generates an
answer to the information request. For example, resident status
communication system 110 fetches the desired information from
resident status database 120 and/or memory internal to resident
status communication system 110. Resident status communication
system 110 packages the retrieved information in a format
accessible by the non-resident communication device. For example,
resident status communication system 110 delivers the information
using a computer-generated voice if the non-resident communication
device 140 initiated a phone call with the resident status
communication system 110. Resident status communication system 110
delivers the information using textual information if the
information requests as a textual request submitted via an
application and/or an Internet browser. In an embodiment, resident
status communication system 110 is able to interface with different
non-resident communication devices 140 communicating via different
means with resident status communication system 110 and provide
corresponding answers. For example, resident status communication
system 110 is able to maintain a phone call with non-resident
communication device 140A while maintaining a textual chat exchange
with non-resident communication device 140B.
[0062] At 350, if resident status communication system 110
determines that the information request includes a request for
personal inmate information, resident status communication system
110 requests non-resident identification information from the
non-resident communication device 140. If the non-resident
communication device 140 has already supplied identification
information at 310, resident status communication system 110 will
utilize the provided identification information in verifying the
non-resident. At 350, if resident status communication system
determines that the provided identification information is
insufficient, resident status communication system 110 will
requests additional identification information. For example, if the
non-resident provided a name at 310 but in order to access personal
inmate information, the non-resident's birthday is required,
resident status communication system 110 will request the birthday
information at 350.
[0063] Using the non-resident identification information, resident
status communication system 110 is able to verify whether the
non-resident is authorized to receive personal inmate information
at 360. Based on the level of authentication defined by a law
enforcement official and/or correctional facility staff, at 360,
resident status communication system 110 determines if the supplied
non-resident identification information is sufficient.
[0064] In an embodiment, resident status communication system 110
determines sufficiency based on whether the requested
identification information matches stored identification
information. For example, resident status communication system 110
may request a name and associated social security number. If the
provided name and social security number do not match the stored
information, resident status communication system 110 determines
that the non-resident is not authorized at 370. Similarly, if the
non-resident fails to provide a response or fails to provide a
response within a predetermined period of time, resident status
communication system 110 determines that the non-resident is not
authorized at 370.
[0065] In an embodiment, resident status communication system 110
determines authorization in a determinative manner. That is,
resident status communication system 110 will request specific
identification information at 350. To be authorized, non-resident
communication device 140 must supply the requested identification
information, and the supplied identification information must match
the information stored in resident status communication system 110
and/or resident status database 120. In this manner, resident
status communication system 110 may randomize and/or select
different requirements of identification information to enhance
security.
[0066] In an embodiment, resident status communication system 110
allows the non-resident to supply multiple types of verification
information. Resident status communication system 110 will
authenticate a non-resident based on the quantity of matching
information supplied. For example, if the amount of matching
information exceeds a predefined threshold, resident status
communication system 110 authorizes the non-resident at 370. In an
embodiment, if provided information does not match, resident status
communication system 110 may weigh the amount of information that
matches with the information that does not match and generate a
verification score. If the verification score exceeds a threshold,
resident status communication system 110 authorizes the user. Using
multiple types of verification information allows for more
flexibility in authenticating a non-resident that is seeking
information.
[0067] In an embodiment, resident status communication system 110
utilizes a combination of a determinative authorization process as
well as a flexible process to achieve a balance in security. For
example, resident status communication system 110 may require that
a social security number provided matches a social security name
stored on a white list of approved non-residents. The resident
status communication system 110 then prompts the non-resident
communication device to provide secondary identification
information, allowing the non-resident to select from, for example,
a birthday, driver's license number, or home address. If the
selected secondary identification information matches stored
information, resident status communication system 110 authorizes
the non-resident at 370.
[0068] At 380, if resident status communication system 110
authorizes the non-resident, resident status communication system
110 generates an answer to the information request. Similarly to
the process described at 340, resident status communication system
110 retrieves the requested personal inmate information and
packages the information in a manner accessible on the non-resident
communication device 140. Resident status communication system 110
may also prompt non-resident communication device 140 to submit
another information request and/or continue to execute method 300
until resident status communication system 110 disconnects from
non-resident communication device 140. Similar to 340, at 380,
resident status communication system 110 also logs the request for
information as well as the answer. In an embodiment, resident
status communication system 110 generates a record of
communications between resident status communication system 110 and
non-resident communication device 140. This logging allows for
future investigations into suspicious requests and/or allows
resident status communication system 110 to generate an alert when
suspicious activity, such as, for example, multiple failed attempts
at authorization, are detected. Resident status communication
system 110 records these requests and allows law enforcement
officials to search these records based on the name or prisoner
identification of the inmate.
[0069] At 390, if resident status communication system 110 does not
authorize the non-resident, resident status communication system
110 rejects the information request. In an embodiment, resident
status communication system 110 allows the non-resident to attempt
to re-authenticate and to supply new identification information to
be registered. In an embodiment, if resident status communication
system 110 rejects an information requests a predetermined number
of times, resident status communication system 110 locks-out the
particular non-resident communication device 140 attempting to
access inmate personal information. For example, using caller ID or
IP address monitoring, resident status communication system 110
blocks non-resident communication devices 140 based on the phone
number and/or IP address utilized to access resident status
communication system 110.
[0070] In an embodiment described with reference to method 300, if
the non-resident is not seeking personal information as determined
at 330, resident status communication system 110 generates an
answer to the information request at 340. For example, resident
status communication system 110 generates an answer if a
non-resident is seeking information related to correctional
facility administration or operations or general correctional
facility information. In this embodiment, resident status
communication system 110 need not request identification
information from the non-resident communication device 140. When
requesting general information that is not associated with a
particular inmate, in an embodiment, resident status communication
system 110 provides the information without additional verification
of non-resident identity. This embodiment contrasts the embodiment
described with respect to FIG. 4, which requests identification
information even if the information sought is general in
nature.
[0071] FIG. 4 illustrates a flowchart illustrating a method 400 for
identifying non-residents in a parallel manner and reporting
resident statuses, according to exemplary embodiments. Method 400
shall be described with reference to FIG. 1; however, method 400 is
not limited to that example embodiment.
[0072] In an embodiment, resident status communication system 110
utilizes method 400 to authenticate non-residents, determine the
information requested by the non-resident, and/or supply the
information requested. The foregoing description will describe an
embodiment of the execution of method 400 with respect to resident
status communication system 110. While method 400 is described with
reference to resident status communication system 110, method 400
may be executed on any computing device, such as, for example, the
computer system described with reference to FIG. 5 and/or
processing logic that may comprise hardware (e.g., circuitry,
dedicated logic, programmable logic, microcode, etc.), software
(e.g., instructions executing on a processing device), or a
combination thereof.
[0073] It is to be appreciated that not all steps may be needed to
perform the disclosure provided herein. Further, some of the steps
may be performed simultaneously, or in a different order than shown
in FIG. 4, as will be understood by a person of ordinary skill in
the art.
[0074] In an embodiment, at 410, resident status communication
system 110 receives an information request from a non-resident
communication device 140. The information request includes a
question concerning operational or administrative procedures of a
correctional facility and/or a request for personal information
related to an inmate. In an embodiment, the information request
also includes an inmate identification, such as an inmate name or
prison identification number. In an embodiment, the information
request is a voice call initiated by a non-resident communication
device 140. The information requested may take the form of a
question and/or a statement. In an embodiment, the information
request is provided in response to a greeting and/or a
computer-generated voice prompt initialized by resident status
communication system 110.
[0075] In an embodiment, the information request also includes a
selection from a menu using a dial-tone keypad, such as a dual-tone
multi-frequency signaling (DTMF) protocol. If the resident status
communication system 110 is interacting with the non-resident
communication device 140 via a textual communication such as an
Internet browser or application, the information request is a
textual question and/or selection. For example, resident status
communication system 110 generates chat graphical user interface
display and sends instructions to non-resident communication device
140 to display the graphical user interface on a display screen. A
non-resident is then able to interact with the graphical user
interface and supply information requests to resident status
communication system 110 using textual messages.
[0076] In an embodiment, non-resident communication device 140 may
supply an incomplete and/or indiscernible information request to
resident status communication system 110. For example, resident
status communication system 110 may receive a partial question,
partial identification, and/or nonsense words that do not specify
what information is requested. Resident status communication system
110 identifies incomplete and/or indiscernible information requests
using natural language speech to text and/or textual analysis
algorithms. In these cases, resident status communication system
110 alerts the non-resident communication device 140 that the
information request was unclear and/or prompts the non-resident
communication device 140 to submit another information request.
[0077] At 420, if resident status communication system 110
determines that the information request includes a complete request
for information, resident status communication system 110 requests
non-resident identification information from the non-resident
communication device 140. If the non-resident communication device
140 has already supplied identification information at 410,
resident status communication system 110 will utilize the provided
identification information in verifying the non-resident. At 420,
if resident status communication system determines that the
provided identification information is insufficient, resident
status communication system 110 will requests additional
identification information. For example, if the non-resident
provided a name at 410 but in order to access personal inmate or
correctional facility information, the non-resident's birthday is
required, resident status communication system 110 will request the
birthday information at 420.
[0078] In an embodiment, to execute method 400, resident status
communication system 110 requests non-resident identification
information at 420 independent of the type of information sought by
non-resident communication device 140. In this embodiment, resident
status communication system 110 protects personal inmate
information as well as general operational and administrative
details related to a correctional facility against unauthorized
non-residents. In an embodiment, law enforcement officials and/or
correctional facility staff may define multiple authorization
policies in resident status communication system 110. Based on a
common authorization process at 420, resident status communication
system 110 may receive required information and determine whether a
user is authorized to access personal inmate information and/or
administrative or operational details related to the correctional
facility.
[0079] After requesting non-resident identification information at
420, resident status communication system 110 analyzes the
information request to determine if the non-resident communication
device is seeking personal inmate information at 430 and verifies
that the non-resident is authorized to receive information based on
the non-resident identification information at 440. In an
embodiment, this processes occur simultaneously and/or in parallel.
In an embodiment, these processes occur serially.
[0080] At 430, if resident status communication system 110 receives
a complete information request, resident status communication
system 110 analyzes the information request to determine if the
non-resident communication device is seeking personal inmate
information. In an embodiment, resident status communication system
110 converts an audio information request into textual information
and scans the textual information for keywords related to personal
information. For example, resident status communication system 110
utilizes a predefined list of keywords to identify personal
information sought. If one or more of the words spoken in the
information request matches a keyword from the predefined list,
resident status communication system 110 recognizes that
non-resident communication system 110 is seeking personal inmate
information. Similarly, if the received information request is in a
textual form, resident status communication system 110 identifies
keywords in the text information. At 470, based on an analysis of
the information request, resident status communication system 110
determines whether personal information is sought.
[0081] At 440, using the non-resident identification information,
resident status communication system 110 is able to verify whether
the non-resident is authorized to receive correctional facility
and/or personal inmate information. Based on the level of
authentication defined by a law enforcement official and/or
correctional facility staff, at 420, resident status communication
system 110 determines if the supplied non-resident identification
information is sufficient.
[0082] In an embodiment, resident status communication system 110
determines sufficiency based on whether the requested
identification information matches stored identification
information. For example, resident status communication system 110
may request a name and associated social security number. If the
provided name and social security number do not match the stored
information, resident status communication system 110 determines
that the non-resident is not authorized at 450. Similarly, if the
non-resident fails to provide a response or fails to provide a
response within a predetermined period of time, resident status
communication system 110 determines that the non-resident is not
authorized at 450.
[0083] In an embodiment, resident status communication system 110
determines authorization in a determinative manner. That is,
resident status communication system 110 will request specific
identification information at 420. To be authorized, non-resident
communication device 140 must supply the requested identification
information, and the supplied identification information must match
the information stored in resident status communication system 110
and/or resident status database 120. In this manner, resident
status communication system 110 may randomize and/or select
different requirements of identification information to enhance
security.
[0084] In an embodiment, resident status communication system 110
allows the non-resident to supply multiple types of verification
information. Resident status communication system 110 will
authenticate a non-resident based on the quantity of matching
information supplied. For example, if the amount of matching
information exceeds a predefined threshold, resident status
communication system 110 authorizes the non-resident at 450. In an
embodiment, if provided information does not match, resident status
communication system 110 may weigh the amount of information that
matches with the information that does not match and generate a
verification score. If the verification score exceeds a threshold,
resident status communication system 110 authorizes the user. Using
multiple types of verification information allows for more
flexibility in authenticating a non-resident that is seeking
information.
[0085] In an embodiment, resident status communication system 110
utilizes a combination of a determinative authorization process as
well as a flexible process to achieve a balance in security. For
example, resident status communication system 110 may require that
a social security number provided matches a social security name
stored on a white list of approved non-residents. The resident
status communication system 110 then prompts the non-resident
communication device to provide secondary identification
information, allowing the non-resident to select from, for example,
a birthday, driver's license number, or home address. If the
selected secondary identification information matches stored
information, resident status communication system 110 authorizes
the non-resident at 450.
[0086] In an embodiment, at 450, if resident status communication
system 110 does not authorize the non-resident, resident status
communication system 110 rejects the information request at 460. In
an embodiment, resident status communication system 110 allows the
non-resident to attempt to re-authenticate and to supply new
identification information to be registered. In an embodiment, if
resident status communication system 110 rejects an information
requests a predetermined number of times, resident status
communication system 110 locks-out the particular non-resident
communication device 140 attempting to access inmate personal
information. For example, using caller ID or IP address monitoring,
resident status communication system 110 blocks non-resident
communication devices 140 based on the phone number and/or IP
address utilized to access resident status communication system
110.
[0087] At 470, if resident status communication system 110
authorizes the non-resident, resident status communication system
110 determines if the information request seeks personal inmate
information as described with reference to 430.
[0088] At 490, if resident status communication system 110
determines that the information request is not seeking personal
information, resident status communication system 110 fetches
locally stored information. Resident status communication system
110 utilizes the locally stored information to generate an answer
to the information request. In an embodiment, resident status
communication system 110 stores information related to correctional
facility operations and/or administration in memory internal to
resident status communication system 110. This embodiment allows
for faster retrieval of information. When interfacing with multiple
non-resident communication devices 140, resident status
communication system 110 is able to query internal memory to
quickly service information requests related to general
correctional facility operations. Additionally, if correctional
facility staff maintains a resident status database separate from
resident status communication system 110, querying the remote
resident status database 120 may require a large amount of time.
Similarly, if resident status database 120 is a database that
correctional facility staff are modifying or that is access by
multiple servers, fetching results may require waiting and/or
queuing while other processes are completed. If resident status
communication system 110 is able to store general information in
internal memory, answers to information requests accessing this
information may be generated in a faster manner than waiting to
query an external resident status database 120.
[0089] After fetching locally stored information 490, resident
status communication system 110 packages the retrieved information
in a format accessible by the non-resident communication device.
For example, resident status communication system 110 delivers the
information using a computer-generated voice if the non-resident
communication device 140 initiated a phone call with the resident
status communication system 110. Resident status communication
system 110 delivers the information using textual information if
the information requests as a textual request submitted via an
application and/or an Internet browser. In an embodiment, resident
status communication system 110 is able to interface with different
non-resident communication devices 140 communicating via different
means with resident status communication system 110 and provide
corresponding answers. For example, resident status communication
system 110 is able to maintain a phone call with non-resident
communication device 140A while maintaining a textual chat exchange
with non-resident communication device 140B.
[0090] At 480, if resident status communication system 110
determines at 430 that the information request includes a request
for personal inmate information, resident status communication
system 110 fetches the personal inmate information from resident
status database 120. As described above, resident status database
120 may be a database maintained and/or operated by correctional
facility staff and/or law enforcement officials. Correctional
facility staff and/or law enforcement officials utilize resident
status database 120 to maintain information and status updates
regarding inmates. Resident status communication system 110 is able
to query the resident status database 120 for this information once
a user is authenticated. Resident status communication system 110
packages the answer similar to the manner described with reference
to 490.
[0091] After supplying answers are 480 or 490, resident status
communication system 110 may also prompt non-resident communication
device 140 to submit another information request and/or continue to
execute method 400 until resident status communication system 110
disconnects from non-resident communication device 140.
[0092] Resident status communication system 110 also logs the
request for information as well as the answers fetched and/or
provided at 480 and/or 490. In an embodiment, resident status
communication system 110 generates a record of communications
between resident status communication system 110 and non-resident
communication device 140. This logging allows for future
investigations into suspicious requests and/or allows resident
status communication system 110 to generate an alert when
suspicious activity, such as, for example, multiple failed attempts
at authorization, are detected.
[0093] Referring now to FIG. 5, various embodiments may be
implemented, for example, using one or more computer systems, such
as computer system 500 shown in FIG. 5. One or more computer
systems 500 (or portions thereof) can be used, for example, to
implement method 300 of FIG. 3 or method 400 of FIG. 4.
[0094] Computer system 500 can be any well-known computer capable
of performing the functions described herein.
[0095] Computer system 500 includes one or more processors (also
called central processing units, or CPUs), such as a processor 504.
Processor 504 is connected to a communication infrastructure or bus
506.
[0096] One or more processors 504 may each be a graphics processing
unit (GPU). In an embodiment, a GPU is a processor that is a
specialized electronic circuit designed to process mathematically
intensive applications. The GPU may have a parallel structure that
is efficient for parallel processing of large blocks of data, such
as mathematically intensive data common to computer graphics
applications, images, videos, etc.
[0097] Computer system 500 also includes user input/output
device(s) 503, such as monitors, keyboards, pointing devices, etc.,
that communicate with communication infrastructure 406 through user
input/output interface(s) 502.
[0098] Computer system 500 also includes a main or primary memory
508, such as random access memory (RAM). Main memory 508 may
include one or more levels of cache. Main memory 508 has stored
therein control logic (i.e., computer software) and/or data.
[0099] Computer system 500 may also include one or more secondary
storage devices or memory 510. Secondary memory 510 may include,
for example, a hard disk drive 512 and/or a removable storage
device or drive 514. Removable storage drive 514 may be a floppy
disk drive, a magnetic tape drive, a compact disk drive, an optical
storage device, tape backup device, and/or any other storage
device/drive.
[0100] Removable storage drive 514 may interact with a removable
storage unit 518. Removable storage unit 518 includes a computer
usable or readable storage device having stored thereon computer
software (control logic) and/or data. Removable storage unit 518
may be a floppy disk, magnetic tape, compact disk, DVD, optical
storage disk, and/any other computer data storage device. Removable
storage drive 514 reads from and/or writes to removable storage
unit 518 in a well-known manner.
[0101] According to an exemplary embodiment, secondary memory 510
may include other means, instrumentalities or other approaches for
allowing computer programs and/or other instructions and/or data to
be accessed by computer system 500. Such means, instrumentalities
or other approaches may include, for example, a removable storage
unit 522 and an interface 520. Examples of the removable storage
unit 522 and the interface 520 may include a program cartridge and
cartridge interface (such as that found in video game devices), a
removable memory chip (such as an EPROM or PROM) and associated
socket, a memory stick and USB port, a memory card and associated
memory card slot, and/or any other removable storage unit and
associated interface.
[0102] Computer system 500 may further include a communication or
network interface 524. Communication interface 524 enables computer
system 500 to communicate and interact with any combination of
remote devices, remote networks, remote entities, etc.
(individually and collectively referenced by reference number 528).
For example, communication interface 524 may allow computer system
500 to communicate with remote devices 528 over communication path
526, which may be wired and/or wireless, and which may include any
combination of LANs, WANs, the Internet, etc. Control logic and/or
data may be transmitted to and from computer system 500 via
communication path 526.
[0103] In an embodiment, a tangible apparatus or article of
manufacture comprising a tangible computer useable or readable
medium having control logic (software) stored thereon is also
referred to herein as a computer program product or program storage
device. This includes, but is not limited to, computer system 500,
main memory 508, secondary memory 510, and removable storage units
518 and 522, as well as tangible articles of manufacture embodying
any combination of the foregoing. Such control logic, when executed
by one or more data processing devices (such as computer system
500), causes such data processing devices to operate as described
herein.
[0104] Based on the teachings contained in this disclosure, it will
be apparent to persons skilled in the relevant art(s) how to make
and use embodiments using data processing devices, computer systems
and/or computer architectures other than that shown in FIG. 5. In
particular, embodiments may operate with software, hardware, and/or
operating system implementations other than those described
herein.
[0105] It is to be appreciated that the Detailed Description
section, and not the Abstract section, is intended to be used to
interpret the claims. The Abstract section may set forth one or
more but not all exemplary embodiments as contemplated by the
inventor(s), and thus, are not intended to limit the disclosure or
the appended claims in any way.
[0106] While the disclosure has been described herein with
reference to exemplary embodiments for exemplary fields and
applications, it should be understood that the scope of the
disclosure is not limited thereto. Other embodiments and
modifications thereto are possible, and are within the scope and
spirit of the disclosure. For example, and without limiting the
generality of this paragraph, embodiments are not limited to the
software, hardware, firmware, and/or entities illustrated in the
figures and/or described herein. Further, embodiments (whether or
not explicitly described herein) have significant utility to fields
and applications beyond the examples described herein.
[0107] Embodiments have been described herein with the aid of
functional building blocks illustrating the implementation of
specified functions and relationships thereof. The boundaries of
these functional building blocks have been arbitrarily defined
herein for the convenience of the description. Alternate boundaries
can be defined as long as the specified functions and relationships
(or equivalents thereof) are appropriately performed. Also,
alternative embodiments may perform functional blocks, steps,
operations, methods, etc. using orderings different than those
described herein.
[0108] References herein to "one embodiment," "an embodiment," "an
example embodiment," or similar phrases, indicate that the
embodiment described may include a particular feature, structure,
or characteristic, but every embodiment may not necessarily include
the particular feature, structure, or characteristic. Moreover,
such phrases are not necessarily referring to the same embodiment.
Further, when a particular feature, structure, or characteristic is
described in connection with an embodiment, it would be within the
knowledge of persons skilled in the relevant art(s) to incorporate
such feature, structure, or characteristic into other embodiments
whether or not explicitly mentioned or described herein.
[0109] The breadth and scope of disclosed inventions should not be
limited by any of the above-described exemplary embodiments, but
should be defined only in accordance with the following claims and
their equivalents.
* * * * *