Patent Application
20170270628
Identity verification is critical for field operators, such as police officers or security officers, during their routine operations. Field operators need to check and authenticate identification documents, and verify the identities of individuals in a safe and efficient way while maintaining their attention on the individuals. In a traditional fashion, a field operator will typically bring an identification document associated with an individual to a computer (such as a computer installed in a police vehicle or at a security station) and manually input the data from the identification document into the computer. The computer submits entered information to a dispatcher who then performs queries to find information about the individual. The results of the queries are returned to the field operator in order to provide the field operator with information that can be used to verify the individual's identity and information that is noteworthy about the individual, for example, wants, warrants and criminal history, among many data sets that would be important to the authorities. The field operator making the contact may also request information on the individual via radio. In this situation, the field operator requesting information may need to create distance from the individual to ensure the individual does not hear the radio response. Unfortunately, manual entry of the information by the field operator, availability of dispatch personnel to process requests, and manual review by the field operator of any resulting information can be a time-consuming and inefficient process. Keying errors or compiling errors by field operator and dispatcher can introduce inaccuracies in the analysis. In addition, bringing the identification document to the computer diverts, at least to some extent, the field operator's attention from the individual and increases the time between initial contact and query response. This increased time period poses a potential threat to the field operator requesting information.
One way to overcome the problems with manual identification checks is to utilize an automatic scanning system that can quickly scan and accurately verify an identification document. One downside of these automatic scanning systems is that they may require a field operator to operate with both hands. Another disadvantage is that the whole verification process performed by these automatic scanning systems can take a long time. Yet another drawback is that these automatic scanning systems can only search a local database (e.g., a local police department wanted suspect list). Still another downside of these automatic scanning systems is that they fail to provide a field operator with sufficient information to support his/her further action in a timely manner. Also, even with automatic scanning systems, a field operator still needs to manually record or collect information that can be used for an incident report, which can sometimes be troublesome and time-consuming.
Identity verification plays an important role in various field operations such as law enforcement operations. Before taking any action, a field operator needs to check and verify the identity of an individual standing in front of him/her and to know his/her threat level (e.g., dangerous, wanted, normal, etc.) in a timely manner. In addition, it is advantageous to allow the field operator to perform such identity verification tasks without interfering with the field operator's routine operation (e.g., without requiring a field operator to carry additional equipment or devices).
The present system and methods provide an effective and convenient way to verify the identity of an identification document holder in a timely manner. The present system and methods provide a proper alert to a field operator (e.g., a police officer, a private investigator, a security guard, etc.) of the threat level of the identification document holder.
In addition to verifying the identity of an individual, the present system can also verify the identity of an item, such as a vehicle or firearm, after collecting item-related information. Based on the collected information, the present system can perform a search and analyze the search result, so as to provide useful information relating to the item (e.g., a firearm is “reported missing”; a vehicle is “to be seized”) to a field operator. In some embodiments, the item-related information can be collected by scanning related item identification documents such as a vehicle registration or a firearm license. In other embodiments, the system receives the item-related information by manual input. In some embodiments, the item-related information can be collected by directly scanning related items (e.g., capturing an image of a license plate; an image of a gun) and then using optical character recognition (OCR) technologies to detect text present in the image (e.g., the serial number on the gun; the license plate number).
More particularly, the present system and methods enable: (1) scanning or retrieving identification information derived from identification documents (including personal identification documents or item identification documents) or from images of items; (2) generating one or more queries for one or more suitable databases according to a search strategy; (3) performing a search, based on a pre-determined search strategy, in the suitable databases based on the queries; (4) forming a search result; (5) analyzing the search result; and (6) presenting the analyzed search result as a simplified alert (e.g., as a red area shown on a display to indicate that the identification document holder is a wanted suspect) to a field operator in a timely manner (e.g., within 5 seconds, depending on the data transmission speed) so as to facilitate the field operator to make a decision of taking further action (e.g., arrest the identification document holder or seize the item) in response to the alert.
One feature of the system is that it performs a thorough background search for the identification document holder or the item by searching multiple available databases. Various databases can have different data structures and security mechanisms. Accessing these databases may require different query formats or syntaxes. The present system and methods provide a quick and convenient way for a field operator to perform a search in multiple databases.
Another aspect of the system is that a search result can be presented in an easily-understandable, straightforward manner to a field operator. For example, the search result can be presented as a simple visual, audible, or tactile alert that quickly provides the user with an assessment of the relative risk of the individual associated with the identification document or item. The alert can include a threat level of the identification document holder or a current status of the item (such as “reported missing”) along with a recommendation of the field operator's next action (e.g., arrest the identification document holder or seize the item). Visual alerts may be, for example, a colored light or a graphic icon shown on a display. Audible alerts may be a tone or other sound played through a speaker or through an earpiece. Tactile alerts may be a distinctive vibration of a wearable item by the field operator. Whether visual, audible, or tactile, an alert can be “secretly” presented to the field operator. By doing so, the system enables the field operator to take proper action without alerting the identification document holder.
The system may be contained in an integrated device, such as a scanning device that can search various online or local databases. Alternatively, the system can be distributed across multiple devices connected via communication links. For example, a portable scanning/displaying device to be used in the field can be responsible for scanning an identification document and displaying an alert to a field operator. Meanwhile, a remote query server in communication with the portable device can be responsible for performing a search in various databases.
Another aspect of the system is that it can be implemented in conjunction with existing devices that might already be carried by a field operator, such as a mobile device (e.g., a smartphone). In such embodiments, the field operator does not need to carry additional devices to access the disclosed features. Accordingly, the field operator's daily operation is not significantly interfered or burdened. When implemented on existing devices, the system is typically provided as a suitable software product for installation on mobile devices like smart phones or tablets.
In some embodiments, the system disclosed herein can maintain a record or generate a report describing an “incident.” The incident can be, for example, an event in which a field operator (1) verifies an identification document associated with an individual, (2) performs a search, based on a pre-determined search strategy, in various databases, and (3) arrests the individual. The incident report can include, for example, a description of the incident (e.g., why the field operator initiated the identification verification process), an incident category (e.g., an auto vehicle theft investigation, a stop-and-frisk event, etc.), a recommended action (e.g., arrest the individual, collect evidence, etc.), an incident resolution (e.g., how the field operator actually acts), comments/notes, related images/audio files (e.g., scene pictures or audio recordings), time/locations, related queries in various databases, an incident map (e.g., a map visually presenting where the incident happens), etc. The incident report can be in any format that is in compliance with a field operator's current role. For example, the incident report can be in the same format as a police report. By generating an incident report, the system can save a field officer's time preparing reports. The incident reports can be automatically and periodically uploaded to a centralized database for record keeping.
Various embodiments of the system will be described below. The following description provides specific details for a thorough understanding and an enabling description of these embodiments. One skilled in the art will understand, however, that the system may be practiced without many of these details. Additionally, some well-known structures or functions may not be shown or described in detail, so as to avoid unnecessarily obscuring the relevant description of the various embodiments. The terminology used in the description presented below is intended to be interpreted in its broadest reasonable manner, even though it is being used in conjunction with a detailed description of certain specific embodiments of the system.
As shown in
In some embodiments, the system 10 can be a mobile device (e.g., a smartphone, a notebook, a tablet, a phablet, an identification scanner, or other suitable devices). The system 10 and the query server 117 can together (1) retrieve information from the identification document; (2) perform a search in one or more databases based on a pre-determined search strategy and the retrieved information to generate search results; (3) analyze the search results; (4) generate an alert or an all-clear signal to the field operator based on the search results; and (5) present the alert or the all-clear signal to a field operator with one or more recommended actions. The predetermined search strategy is a set of rules that describes how a search (or multiple searches) should be performed. In some embodiments, the predetermined search strategy can include: (1) the type of searches to be performed (e.g., a personal search, a firearm search, an automobile search); (2) the number and identity of databases to be searched; (3) rules for analyzing search results; and/or (4) rules for presenting the search results. A personal search is a search associated with the identity of an individual. For example, a personal search can be initiated by scanning a driver's license provided by an individual who requests access to a facility or has been pulled over for speeding. An item search is a search associated with the identity of an item. For example, an item search can be initiated by scanning a title, license registration, or insurance document associated with an automobile. In some embodiments, an item search can be initiated by taking a picture of an item and detecting any text in the picture using OCR technologies. In other embodiments, an item search can be initiated by a manual input of a serial number associated with an item.
As shown in
During a typical operation, a field operator of the system 10 encounters an individual and would like to verify or check the identity of that individual. After obtaining an identification document from the encountered individual, the field operator uses the system 10 to scan, read, or enter identification information from the identification document presented by the individual. That is, the system may be used to scan the identification document (e.g., using a barcode or magnetic-stripe reader) and/or to manually enter related information from the identification document or encounter.
More particularly, the input component 103 of the system 10 is utilized to retrieve information from the identification document by scanning or manual entry. In some embodiments, the input component 103 includes a scanning device. The scanning device can retrieve the identification information via image capture and optical character recognition (OCR), barcode reader, magnetic stripe reader, wireless sensor (e.g., RFID) reader, or other suitable technologies. Additional details about techniques for scanning identification documents are described in commonly-owned U.S. Pat. No. 5,864,623, filed on Jul. 15, 1996 and entitled, “AUTHENTICATION SYSTEM FOR DRIVERS LICENSES” and U.S. Pat. No. 8,322,605, filed on Aug. 22, 2007 and entitled, “DYNAMIC IDENTITY MATCHING IN RESPONSE TO THREAT LEVELS,” which are incorporated by reference herein in their entirety. For example, the input component 103 can be a camera installed in a smartphone carried by a field operator. In various embodiments, the input component 103 can also receive a user input (e.g., information manually input through a virtual or physical keyboard, or audibly using speech-to-text processing).
In some embodiments, the system retrieves item-related information by scanning related item identification documents such as a vehicle registration or a firearm license. After capturing an image of the document, for example, the system 10 uses barcode recognition technologies to extract the encoded information within the barcode or use OCR technologies to analyze the image and convert the image into text for further analysis. Once converted into text, the system 10 uses semantic analysis or pattern-recognition technologies in order to identify data having a certain format. For example, a vehicle registration will contain a VIN number of a vehicle, or a firearm license may contain a registration number that is of a known format and content. Using such an analysis methodology, the system 10 identifies item description information that can be used in search queries pertaining to the associated item. In some embodiments, the system 10 can retrieve item-related information by capturing and analyzing images related to the item. For example, the field operator can use the system to take a picture of an item with a serial number thereon, or the picture of an item that contains a barcode. The system 10 then analyzes the picture in order to detect the identifying information contained on the item. For example, the system may use OCR technology to detect text that is contained in the picture, or the system may use barcode interpretation software to read and interpret a bar code that is reflected in the picture.
In some embodiments, when the retrieved information does not provide a sufficient basis for the system 10 to perform desired queries, the system can send a request for further information to an operator. For example, a query associated with a personal search may require an individual's social security number, which cannot be retrieved from a driver's license. In such cases, the system 10 can display a dialogue box asking the system operator to manually input the individual's social security number.
After the information from the identification document is retrieved, the search component 105 either selects or allows a field operator to specify a search strategy that is to be applied related to the retrieved or scanned information. Generally speaking, the system 10 enables a field operator to perform different types of searches, such as a personal search (e.g., search criminal records related to a person in various databases), and an item search (e.g., search a vehicle in the DMV database; search a gun in a firearm database; search a drug in a controlled-substance database). In some embodiments, a personal search can include an activity search associated with a person (e.g., search for a specific type of criminal conduct or a suspected terrorist activity in a person's social network profile). The search component 105 therefore determines what search strategy is to be followed and builds an appropriate search query (or multiple queries) to send to the query server(s) based on the selected search strategy. The search query specifies the search that is to be performed, including the databases to be searched and, in some cases, how the search results from the databases are to be analyzed. Moreover, the search query also provides any scanned or entered information necessary to implement the search strategy. In some embodiments, the search component 105 suggests a search strategy to a field operator based on a user's query (e.g., a query relating to a vehicle, a person, a location, or a criminal activity). In other embodiments, the search strategy is specified by the field operator without a recommendation from the search component 105. For example, the field operator can choose to search the DMV database only. As another example, the field operator can decide to search certain databases (e.g., due to personal preference, or to avoid generating additional search expenses for certain databases). In other cases, the search strategy is pre-determined by the search component 105. That is, the search component applies a pre-configured search strategy that is stored in the data storage unit 113.
In some embodiments, the applied search strategy and the databases that are accessed by the system will depend on a “role” of the field operator. For example, the field operator may be a private investigator who is hired to investigate an automobile theft case. In that case, the field operator can set the default search strategy as a type of item search, namely a vehicle search based on a license plate number or a Vehicle Identification Number. Based on the selected search strategy, the system 10 generates a search query using either default settings (e.g., by automatically performing an item search in both the DMV database and the NCIC database) or using custom settings selected by the field operator (e.g., by performing an item search in only the DMV database). As another example, the field operator can be a federal agent who is primarily responsible for federal crime investigations. In that case, the field operator can set the default search strategy as a personal search, namely a suspect search in criminal record databases relating to federal crimes. Based on the selected search strategy, the system 10 generates a search query using either default settings (e.g., by automatically performing a personal search in all available databases) or using custom settings selected by the field operator (e.g., by performing a personal search only in the DMV database or the NCIC database). As yet another example, the field operator can be a special agent responsible for preventing potential terrorist attacks. In that case, the field operator can set the default search strategy as a personal search (e.g., as a terrorist search). Based on the selected search strategy, the system 10 generates a corresponding search query using either default settings (e.g., by performing a personal search in the NCIC database, several social media databases, a terrorist-watch-list database, etc.) or using custom settings selected by the field operator (e.g., in a social network database to see if there are any leads relating to the retrieved identification information). For instance, the retrieved identification information may be associated with an existing social network account (e.g., by name matching or image matching) that includes a statement of unlawful conduct or a plan to commit a crime.
When the search strategy is determined, the search component 105 of the system 10 can then transmit some or all of the retrieved information and the search strategy to the query server 117 through the transmitting component 109. As shown in
In a typical operation, the system then analyzes the returned search results. As will be described in additional detail herein, the analysis can include: (1) summarizing the search results; and (2) calculating a score associated with the search results and using the score to assess the threat level. A score may be calculated for the search results by performing a search for different keywords in the search results and adding different point values for each keyword that is identified. In order to calculate scores, the system maintains a table or other data structure that correlates certain keywords with certain point values. For example, identifying the keyword “homicide” in the search results can result in 10 score points; identifying the keywords “traffic violation” in the search results can result in 2 score points; and identifying the keyword “wanted” in the search results can result in 50 score points. After each keyword is identified and the corresponding point value determined, the resulting point values are summed together. The system can then define various threat levels based on the calculated score and provide corresponding recommended actions. For example, a score between 0-5 means “no record” or “not dangerous,” a score between 10-50 means “suspect,” and a score of 50 or above means “dangerous.” For cases with the “no record” or “not dangerous” analyzed result, the recommended action can be “keep records only” or “do nothing.” For cases with the “suspect” analyzed result, the recommended action can be “detain the individual for further investigation” or “collect further evidence.” For cases with the “dangerous” analyzed result, the recommended action can be “arrest the individual immediately.”
In some embodiments, the query server 117 analyzes the search results and generates the analyzed result. The query server 117 then transmits the analyzed result to the system 10 (e.g., through the receiving component 111 of the system 10) for further processing. For example, the system may generate an alert and present the alert to the field operator, as discussed in detail below. In other embodiments, however, the search results can be analyzed by the search component 105 of the system 10. In such embodiments, the query server 117 transmits the search results to the system 10, and the search component 105 directly generates the analyzed result.
After generation of the analyzed result, the system 10 determines the type of alert to present based on the analyzed result. The alert is indicative of a threat level (e.g., dangerous, wanted, suspect, normal or no threat, etc.) of the individual. The alert is preferably an easily-understandable and straightforward signal to the field operator. The alert thereby can quickly and effectively signify to the field operator the threat level of the identification document holder. The alert can also convey a recommendation to the field operator of his/her next action in response to the scan and the analysis of the identification document. In some embodiments, the alert is generated by the search component 105 of the system 10. When the analyzed result indicates that there is limited or no threat, the system 10 can generate an all-clear alert (e.g., a green light) reflecting the analysis results. In some embodiments, the alert can be generated based on a status of an item in question (e.g., auto, boat, gun, etc.). For example, the alert can indicate that the item in question has been reported stolen.
Once the form of the alert has been determined, the presentation component 107 of the system 10 presents the alert to the field operator. The alert can be presented as a visual signal, an audio sound, a tactile notification, or any combination thereof. As an example, the alert can be presented as a colored icon in a specified area on a display of the system 10. In some embodiments, various colors displayed in the specified area can represent different levels of threat. For example, a green signal in an area indicates that the identification document holder has no record and is presumably safe; a yellow signal in the same area indicates that the search is still in progress and thus the current status is unknown; and a red signal in the same area indicates that the individual is dangerous or wanted. In some embodiments, other colors may be used by the system to convey more nuanced information about the individual. For example, the color pink may be used to indicate that the individual is suspect but not dangerous (e.g., has only traffic violations but no criminal charges). In some embodiments, while the search is pending, the system may display either no icon or may display an icon that reflects the pending search (e.g., a blinking orange display).
In various embodiments, the alert can include various visual cues that help an operator more quickly process the displayed information. For example, the presented information may be blinking or flashing, may be displayed with different shapes reflecting the seriousness of the alert, may be presented in different colors or patterns, etc. In some embodiments, the severity of the alert can be indicated based on the displayed location. For example, a light signal at a corner of a display can mean “dangerous,” while the same signal showing in the center of the display can mean “normal.”
In some embodiments, the alert can be presented to the field operator in an audible fashion (e.g., through an earpiece or speaker) or tactile fashion (e.g., by vibration of a wearable item). For example, the alert can be a synthesized warning voice that is transmitted to the field operator through an earpiece. As another example, the alert can be different patterns of vibration of a watch worn by the field operator.
In some embodiments, the search component 105 also generates a record or an incident report for each processing step and result performed by the system 10. For example, the incident report may include a date/time code and descriptive information associated with the document scan, the searching performed, and the alert generated by the system. Examples of an incident report can be found in
In some embodiments, the search component 105 can also be configured to verify the authenticity of the identification document. Additional details about techniques for verifying identification documents are described in commonly-owned U.S. Pat. No. 5,864,623, filed on Jul. 15, 1996 and entitled, “AUTHENTICATION SYSTEM FOR DRIVERS LICENSES,” U.S. Pat. No. 8,322,605, filed on Aug. 22, 2007 and entitled, “DYNAMIC IDENTITY MATCHING IN RESPONSE TO THREAT LEVELS,” U.S. Pat. No. 7,860,318, filed on Nov. 9, 2004 and entitled, “SYSTEM AND METHOD FOR COMPARING DOCUMENTS,” and U.S. Pat. No. 7,708,189, filed on May 16, 2003 and entitled, “IDENTIFICATION VERIFICATION SYSTEM AND METHOD,” which are incorporated by reference herein in their entirety. For example, the search component 105 can check the formats/content of the presented identification document and verify it by communicating with an internal database (e.g., information stored in the data storage unit 113) or an external database (e.g., the databases 119a, 119b, . . . 199n, through the query server 117).
In some embodiments, the data storage unit 113 is configured to store, permanently or temporarily, retrieved information, search results, analyzed search results, alerts, and/or generated incident reports. In several embodiments, the data storage unit 113 is configured to store information that can be used to verify the authenticity of the identification documents. In various embodiments, the data storage unit 113 is configured to store information that can be used to perform a local search. By storing information on the device itself, the system 10 is able to function normally even without a network connection.
To summarize, after the field operator scans the identification documents (or inputs the identification information), the system 10 promptly provides the field operator with an alert that signifies a threat level of the individual and a recommended action. The speed that the alert is generated by the system is dependent on the data transmission speed, the response time of queried databases, and/or the speed at which the resulting data is analyzed. As a result, the system 10 can effectively assist the field operator during his/her field operation by providing timely information with a recommended action. With the assistance of the system 10, the field operator can be more focused on other tasks (e.g., searching for evidence) and can pay more attention to suspects during the interaction. Accordingly, the system 10 can improve the efficiency and safety of the field operator's routine operations.
In addition, the search component 105 of system 11 can also be configured to (1) generate suitable queries for the multiple databases based on a search strategy; (2) communicate (e.g., via the transmitting component 109) with the multiple databases to perform a search; (3) receive (e.g., via the receiving component 111) search results from the multiple databases; (4) analyze the search results to form an analyzed result; and (5) transmit the analyzed result to the presentation component 107 so as to generate an alert. By this arrangement, the system 11 can provide a field operator with alerts regarding a threat level of a suspect and a recommended action in a timely manner without reliance upon a query server 117.
Another distinguishing feature of system 11 is that the search component 105 can be configured to prioritize the databases (e.g., to decide which database is a preferred database based on the search strategy of a field operator, or to decide an order of displaying search results from multiple databases; see
Yet another distinguishing feature of system 11 is that it includes a report component 121. The report component 121 generates an incident report, examples of which are described herein with respect to
Still another distinguishing feature of system 11 is that it includes an identification verification component 123. The identification verification component 123 is configured to verify the authenticity of the identification document. For example, the identification verification component 123 can check the format/content of the identification document and verify it by communicating with an internal database (e.g., information stored in the data storage unit 113) or an external database (e.g., the databases 119a or 119b). Additional details about techniques for verifying identification documents are described in commonly-owned U.S. Pat. No. 5,864,623, filed on Jul. 15, 1996 and entitled, “AUTHENTICATION SYSTEM FOR DRIVERS LICENSES,” U.S. Pat. No. 8,322,605, filed on Aug. 22, 2007 and entitled, “DYNAMIC IDENTITY MATCHING IN RESPONSE TO THREAT LEVELS,” U.S. Pat. No. 7,860,318, filed on Nov. 9, 2004 and entitled, “SYSTEM AND METHOD FOR COMPARING DOCUMENTS,” and U.S. Pat. No. 7,708,189, filed on May 16, 2003 and entitled, “IDENTIFICATION VERIFICATION SYSTEM AND METHOD,” which are incorporated by reference herein in their entirety.
To summarize, the system 11 provides a field operator with an alert that signifies a threat level of an individual and a recommended action by directly communicating with multiple databases to be searched. Also, the system 11 enables the field operator to access multiple databases to ensure robust search results. According to the search strategy of the field operator (e.g., involving a personal search or an item search), the system 11 can then determine proper databases to be searched. In some embodiments, the system 11 enables the field operator to select preferred databases to be searched such that the field operator can have a customized system that fits best to his/her role during field operations. In some embodiments, the system 11 searches multiple databases in a particular order (e.g., based on the system's default setting or the field operator's preferences). In other embodiments, the system 11 searches multiple databases in parallel. In order to implement the appropriate search strategy, the system maintains a table or other data structure containing a mapping of search strategies to databases. The mapping may include both system-generate search strategies/databases as well as user-specified search strategies/databases.
The presentation component 107 of the system generates multiple user interfaces which present an alert to a field operator or allow the operator to interact with the system.
It will be appreciated that the number and identity of databases reflected in the interface 200 will vary depending on the particular incident being investigated. Moreover, the number and identity of displayed databases may also vary depending on any system- or operator-defined preferences regarding databases to be searched. In the event that different databases were selected by the system or operator for searching, the databases would be reflected by different tiles 202.
To initiate a search of the listed databases, the operator presses a “Person Lookup” button shown in the third region 23. The “Person Lookup” button indicates that the system is going to perform a personal search strategy (e.g., queries relating to a person). The displayed button to initiate the search strategy is configurable based on an operator's search strategy preference. For example, if the operator wants to search an item (e.g., a gun), then the system replaces the “Person Lookup” button with an “Item Lookup” button or a “Gun Search” button. The field operator can also return to a welcome page or a menu page (not shown) by clicking a “Back” button shown in the third region 23.
In contrast, the user interface 200 in
Meanwhile, as shown in
In contrast, the user interface 200 in
The incident report 212 also includes a number of fields that allow the field operator to capture or record data that is associated with the incident. For example, the incident report includes an incident resolution note field 221 that allows the field operator to include additional notes about the incident resolution (e.g., further details about the field operator's response to the incident). The system allows the field operator to enter notes using, for example, a virtual or physical keyboard or voice dictation. The incident report 212 contains a photo field 223 that allows a field operator to attach photographs taken of the incident to the incident report 212. When the system is implemented on a mobile phone, for example, the field operator may use a camera in the mobile phone to take pictures of an accident, crime scene, or to capture other pertinent images. The incident report also includes a voice memo field 228, which allows a field operator to record a voice memo that is associated with the incident.
In the incident report 212, the system also automatically displays the results of certain scanned or queried data that is associated with the incident. For example, in the scan field 227, the system indicates that a scan of a suspect's identification was performed and displays a portion of the scanned information (in the depicted example, the name of the individual scanned from the identification document). By selecting the scan field 227, the system displays an interface (not shown) which depicts more of the scanned information, such as the physical characteristics or image of the individual associated with the identification document, or any other associated information (e.g., a statement such as “there were two persons in a vehicle and both of them provided IDs to scan”). In the query field 225, the system indicates the number of queries that were performed by the system. By selecting the query field 225, the system displays an interface (not shown) with the queries and/or the result of the queries to the field operator.
It will be appreciated that the displayed fields in the incident report 212 of
The lower region 233 displays a list showing the order of incident codes that can be selected by the field operator when completing an incident report. In some embodiments, the incident codes may be displayed in order of frequency, in order of severity, or in another order. For example, the system allows a field operator to configure the system to display incident codes in a particular order (e.g., “010 Homicide,” “020 Rape,” “030 Robbery” etc.) in the Session Start Categories field.
The method 500 continues to block 503 where the query server determines one or more query formats of one or more databases to be searched. Query formats for multiple databases may be stored by the query server, and selectively retrieved when queries are to be made. A query format may include a database address as well as specific information about the API used to make calls to the database. At block 505, the query server generates one or more queries based on the received information, the system or system operator's search strategy, and the resulting necessary query format. At block 507, the query server transmits each generated query to the corresponding database. At block 509, the query server receives information generated by each database in response to the query. At block 511, the query server analyzes the integrity of the search results. For example, the query server may verify that search results were received from each database and that the received search results are in the expected format. The query server also analyzes the content of the search results and summarizes, truncates, or otherwise reformats the received information. For example, the query server may (1) examine the search results and identify the types of the search results (e.g., a name match during a personal search); and (2) determine whether the search results are positive or negative. In some embodiments, the query server can supplement the search results with summaries or additional information so as to simplify the display of the search result by the identification scanning system. The operation of the query server described in method 500 allows the system 10 to check the identity and characteristics of an individual or of an item by accessing various databases. At block 513, the query server transmits the responsive results to the identification scanning system.
At block 607, the system selects information scanned from the identification documents. The information can be all or part of the information retrieved from the identification documents. For example, the selected information can include a name, an identification number, a date of birth, an address, gender information, a height/weight, an eye color, an image, a signature, and/or other suitable information of the individual. Because the query server may access different databases, each containing different fields or types of information, the system will typically provide all scanned information that is necessary to the query server to facilitate the formulation of search queries. In some embodiments, the system determines whether the scanned information is sufficient to formulate the desired search queries. If the scanned information is insufficient, the system may send a request for further information to the operator. The operator can then manually input the missing information or scan additional documents in order to provide sufficient information to formulate the search queries.
At block 609, the system transmits the selected information and a search strategy to a query server. The selected information and search strategy may be encrypted or encoded prior to transmission to the query server. As discussed above, the search strategy can be automatically selected by the system based on the selected role of the field operator. In some embodiments, the system can make recommendations of the search strategy to the field operator based on the operator's prior interaction with the system. For example, the system can suggest a search strategy to a field operator appropriate for an auto-theft investigator if the field operator has scanned a vehicle title document. Alternatively, the search strategy may be selected by the field operator. The search strategy indicates which databases are to be searched by the query server. The search strategy may also include any limitations on the searches, such as keywords to use in the search, priorities of search, certain emphasis in search strategies, etc. Once the query server receives the selected information and the search strategy, it generates one or more queries to databases to be searched.
Upon receiving results that are responsive to the search query, the query server formats the results for delivery to the system. Formatting may include summarizing, coding, or otherwise interpreting the query results. In some embodiments, the query server waits until search results are received from all queried databases before transmitting the results to the system. In some embodiments, the query server transmits search query results to the system as the results are received from queried databases. The query server then transmits the search results to the system. The transmitted search results may be encrypted or encoded prior to transmission to the system.
At block 611, the system receives search results from the query server. As discussed above, in some embodiments, the search results can be generated by the query server. In some embodiments, the search results are directly routed back to the system from the database at which the search was performed.
At block 613, the system analyzes the search results and then generates an alert or an all-clear signal based on the search results. For example, the system can calculate a score based on the search results and use the score to determine a threat level of the individual. As previously discussed, the score may be based on an algorithm that determines the frequency of certain keywords within the search results. The system then generates an appropriate alert based on the calculated score, such as by assigning different colors to reflect different threat levels. In some embodiments, the system can form the alert based directly on information in the search results. For example, the search results might include a piece of information that indicates that the individual has outstanding warrants for the arrest of the subject. In such case, the system can directly translate the search results into an alert. For example, the system may generate a visual signal such as a flashing red light to indicate that the individual is a wanted suspect. The system may also generate an all-clear signal when the system determines that nothing atypical or suspicious was found in the search result. In some embodiments, the all-clear signal can be a green light. At block 615, the system presents the alert or the all-clear signal to the user. As previously discussed, the alert can be visually (e.g., a color shown on a display), audibly (e.g., through an earpiece), or tactilely (e.g., a vibration of a wearable item) presented to the user. In some embodiments, the alert includes not only a threat level of the individual but also a recommended action thereto. For example, an alert of a red light signal can mean that an individual is dangerous, while an alert of a flashing light signal can mean that the system recommends arresting the individual. Accordingly, when a user receives an alert of a red flashing light signal, he/she would know that the individual is dangerous and the recommended action from the system is to arrest that individual. At block 617, the system can present details of the alert or the all-clear signal to the user upon the user's request. For example, the details of the alert can include (1) details of the factors that caused the system to generate the alert, and (2) a list of the specific search results and the contents of those results. The method 600 then ends. In general, through the use of simple visual alerts, the system can effectively notify the user of the authenticity of the presented identification document, signify a threat level of the individual, and present a recommended action.
In some embodiments, the system can perform a series of database searches by treating initial search results from one database as input (e.g., as a search keyword) for subsequent searches to be automatically performed in other databases. The use of initial search results to formulate a subsequent search query will be referred to as a “follow-up” search. For example, the system can perform an initial personal search based simply on an individual's name in multiple databases including the DMV database. The result of the DMV search can include a driver's license number associated with the individual's name. The system can then use the driver's license number as part of a subsequent search query or queries in the same or different databases. A follow-up search is particularly useful in cases where the initial retrieved information conveys limited actionable information. Follow-up searches can be repeatedly performed by the system so as to maximize search results based on limited information retrieved from an identification document or collected by other suitable means. In some embodiments, the system can recommend to the field operator that an additional (follow-up) search should be performed. The recommendation may be based on certain pre-determined criteria. For example, if a previously unavailable database becomes available based on information that was received as a result of a prior search, the system may recommend a follow-up search within the database. In some embodiments, the system can make recommendations for follow-up searches based on empirical data. For example, the system can recommend performing a stolen car search associated with a car that an individual is driving, if initial search results indicate that the individual has a prior criminal record of auto theft.
It will be appreciated by those skilled in the relevant art that the components or units that are part of the system or interact with the system may be implemented by computer-executable instructions, such as program modules, executed by one or more computers or other devices. Those skilled in the art will further appreciate that the system or aspects of the system disclosed herein may be implemented on any computing system or device. Suitable computing systems or devices include server computers, multiprocessor systems, microprocessor-based systems, network devices, minicomputers, mainframe computers, distributed computing environments that include any of the foregoing, and the like. Such computing systems or devices may include one or more processors that execute software instructions to perform the functions described herein. Processors include programmable general-purpose or special-purpose microprocessors, programmable controllers, application specific integrated circuits (ASICs), programmable logic devices (PLDs), or a combination of such devices. Software may be stored in a memory, such as a random access memory (RAM), a read-only memory (ROM), a flash memory, or a combination of such devices. Software may also be stored in one or more storage devices, such as magnetic or optical based disks, flash memory devices, or any other type of non-volatile storage medium for storing data. Software may include one or more program modules which include routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular data types. The functionality of the program modules may be combined or distributed as desired in various embodiments.
From the foregoing, it will be appreciated that specific embodiments of the system have been described herein for purposes of illustration, but that various modifications may be made without deviating from the spirit and scope of the system. Accordingly, the present technology is not limited except as by the appended claims.
This application is a continuation of U.S. patent application Ser. No. 15/043,182 entitled “SYSTEM AND METHODS FOR ANALYZING INFORMATION FROM IDENTIFICATION DOCUMENTS” filed on Feb. 12, 2016, the disclosure of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15043182 | Feb 2016 | US |
| Child | 15612199 | US |
