Patent Publication Number: US-10311537-B1

Title: System for facilitating the execution of law enforcement duties

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
     The present application is a continuation of U.S. application Ser. No. 14/977,075, entitled “System for Facilitating the Execution of Law Enforcement Duties”, filed on Dec. 21, 2015, which is a continuation of U.S. application Ser. No. 14/252,734, entitled “A System and Method for Facilitating the Execution of Law Enforcement Duties”, filed on Apr. 14, 2014, now U.S. Pat. No. 9,218,634; which is a continuation-in-part of U.S. Nonprovisional patent application Ser. No. 13/872,150, entitled “A System and Method for Facilitating the Execution of Law Enforcement Duties and Enhancing Anti-Terrorism and Counter-Terrorism Capabilities”, filed Apr. 28, 2013, now U.S. Pat. No. 8,742,934; which claims the benefit of U.S. Provisional Patent Application No. 61/639,938, entitled “A System and Method for Facilitating the Execution of Law Enforcement Duties and Enhancing Anti-Terrorism and Counter-Terrorism Capabilities”, filed on Apr. 29, 2012, the disclosure of each of which is hereby incorporated by reference as if set forth in their entirety herein. 
    
    
     STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT 
     Not Applicable. 
     NAMES OF THE PARTIES TO A JOINT RESEARCH AGREEMENT 
     Not Applicable. 
     INCORPORATION BY REFERENCE OF MATERIAL SUBMITTED ON A COMPACT DISK 
     Not Applicable. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The invention generally relates to a system and method for facilitating the execution of law enforcement duties and enhancing anti-terrorism and counter-terrorism capabilities. More particularly, the invention relates to an electronic system and associated method that is adapted to facilitate the performance of law enforcement duties by quasi-instantaneously providing actionable intelligence to front-line law enforcement officers in response to a real-time query. 
     2. Background Description 
     The successful enforcement of local, state, and federal criminal statutes greatly rely upon the effectiveness with which law enforcement agencies carry out their mission to protect the public by preventing, investigating, and solving crimes and preventing terrorists attacks. The degree of effectiveness achieved by law enforcement in this endeavor is dependent upon numerous critical factors, one of the most critical being its ability to collect, document, analyze, disseminate, and utilize the massive amounts of criminal intelligence information developed by law enforcement daily. The events of Sep. 11, 2001, hastened the development of numerous data management systems and processes that succeeded in improving the quality and availability of criminal intelligence information; however, these systems have been typically designed to distribute information to selected groups of system users within a local or regional footprint. Of particular significance is the fact that these new and disparate systems failed to create a national data management system which quasi-instantaneously and in real-time provides (1) criminal intelligence information in an actionable form, (2) on a national scale, (3) to all law enforcement agencies, to include local, state, tribal, and federal; most notably the front-line officer. Consistent success in the modern criminal environment dominated by constantly changing and improving technology requires that law enforcement make more effective and efficient use of its criminal intelligence information; information that must not only be accurate, reliable, and accessible, but also be available in an actionable form to all law enforcement officers both quasi-instantaneously and directly. 
     Considering the complex and often unpredictable nature of crime, the execution of law enforcement duties is a difficult and dangerous task. Routinely during the course of their daily mission to fight crime, law enforcement officers must make expeditious decisions not only to ensure the safety of the public and the officers themselves, but also to ensure the preservation of evidence; decisions which necessarily must also strictly adhere to the rules of criminal procedure. One tool that would immediately and dramatically improve a law enforcement officer&#39;s ability to perform these duties more effectively and efficiently—all while increasing officer safety—would be direct, quasi-instantaneous access to a national criminal intelligence database containing reliable, concise, actionable intelligence about a particular subject, or suspected criminal property. In jurisdictions throughout the United States, valuable criminal intelligence information exists and, in many cases, is being maintained in some form of data or records management system; criminal intelligence information that in many circumstances would, if provided to front-line officers directly, quasi-instantaneously, and in an actionable form, provide them with sufficient information to satisfy the requisite legal standards to support a desired enforcement action. Unfortunately, as discussed above, the current data and records management systems and processes for collecting, storing, accessing, and distributing the aforementioned criminal intelligence information are not designed to provide this information in an actionable form to an officer in the field quasi-instantaneously, in real-time, on a national scale. Resultantly, these systems not only fail to make efficient use of the criminal intelligence information already developed and maintained by law enforcement, they also fail to effectively facilitate critically important law enforcement procedures commonly utilized by front-line officers such as investigative detentions, searches, and seizures. 
     Yet another deficiency of the current data and records management systems available to law enforcement are the limitations and inherent weaknesses of reports-based systems. The current systems create large, scalable databases comprised of law enforcement reports which are stored within these databases and can thereafter be searched in response to a law enforcement query. When matches are identified in a reports-based database, the querying user is presented with the opportunity to review the contents of any reports determined by the system to match the search criteria. A reports-based database system creates two significant problems when employed in the law enforcement environment which limit the capabilities and effectiveness of such systems, namely (1) the need for participating agencies to submit copies of their reports to these systems for viewing and potential use by other system participants and (2) the formation of a database containing too much information for the front-line officer to effectively analyze and use on-scene. 
     Concerning the first problem identified above, one of the primary concerns of a law enforcement agency considering whether to participate in a multi-agency reports-based database is its capability to maintain control of the use and dissemination of its agency reports and the information they contain. Such reports-based databases create serious information control and security issues for many agencies and therefore inspire a reluctance to contribute information to such systems. Security controls and protocols for reports-based systems can be designed to address this problem, but necessarily result in limiting access to the information and thereby diminishing the system&#39;s effectiveness. In some cases, agency policy or statutes governing the sharing of information with outside agencies may even prevent participation in such a system. 
     Concerning the second problem identified above, the use of a reports-based database by front-line officers necessitate an on-scene review of the reports contained in that database and a concurrent subjective analysis of that information. This review and analysis must be accomplished by those officers before the information the report(s) contains can be utilized. Because reports-based database systems contain all information detailed in the reports comprising such a database, they consequently contain too much information. Instead, what is needed is system and method designed to accomplish the sharing of only actionable criminal intelligence information, providing front-line officers with exactly the information they need to know about a given subject; information classified in such way that it doesn&#39;t require an officer to review one or more reports and draw a subjective conclusion about that subject, based on the information contained in the report(s), before proceeding with an investigation. 
     Current database and records management systems claim to provide actionable intelligence, but actually fall well short of that claim—providing a database full of reports is not the same as providing actionable intelligence. It is also important to note that actionable intelligence alone doesn&#39;t give an officer probable cause or reasonable suspicion, but it does serve to color his perception of the subject with whom or which he is dealing. Truly actionable intelligence enables officers to better articulate and support their actions and result in law enforcement conducting safer, better informed, better supported, and consequently, more effective investigations. 
     One of the most important law enforcement procedures available in the fight against crime is the seizure of criminal assets, also known as asset forfeiture. Asset forfeiture is the confiscation of assets, by local, state, and federal agencies which are either (1) the alleged proceeds of crime or (2) the alleged instrumentalities of crime. Criminal proceeds or profits refer to the money and/or property generated from criminal activity, whereas instrumentalities of crime refer to property that is used to facilitate the commission of a crime. Criminal proceeds and instrumentalities can be associated with a plethora of different crimes such as, but not limited to drug trafficking and terrorist activities. 
     There are two main types of forfeiture actions, namely criminal forfeiture actions and civil forfeiture actions. A criminal forfeiture action is an in personam action that is carried out in conjunction with the criminal prosecution of a defendant. In a criminal forfeiture action, the government is required to indict the property used or derived from the crime along with the defendant and is generally subject to the same “beyond a reasonable doubt” legal standard of proof that is required in criminal cases. In contrast, a civil forfeiture action is an in rem action that is carried out against the property being seized and the possessor of the property at the time of seizure—effectively a third party claimant. Initially, the government must have probable cause to seize the property and, thereafter, the possessor at the time of seizure, or the property&#39;s owner, may challenge the government&#39;s seizure. If the government demonstrates that the property is subject to forfeiture by a preponderance of the evidence in a subsequent judicial proceeding, the property can be forfeited. Because the burden of proof is substantially less in a civil forfeiture action, it is the type of forfeiture action that is most commonly favored by the government. Less than eighty percent (80%) of civil seizures are ever challenged in a legal proceeding. 
     In general, civil forfeiture can occur by means of one of the following three procedures: (1) summary forfeiture, (2) administrative forfeiture, or (3) judicial forfeiture. The property subject to a summary forfeiture proceeding is very limited in nature and normally involves a limited category of property specified under the Controlled Substances Act (“CSA”). In contrast, an administrative forfeiture proceeding can be commenced by a seizing agency against most property valued at $500,000 or less, as well as any amount of cash. The administrative action must be contested by the original owner in a timely manner or the original owner loses any legal claim to the property and the government acquires ownership thereof. A judicial forfeiture procedure occurs before a judge and is carried out in a manner analogous to that of a trial. If the value of the property exceeds $500,000, a claim of ownership is filed during an administrative procedure; if however, real property is involved, then a judicial forfeiture procedure is required. 
     All forms of asset forfeiture are very important mechanisms for combating crime in our society. The effective enforcement of asset forfeiture enactments directly attacks the economic basis of criminal enterprises, significantly diminishing their ability to profit from criminality and depleting the funds from their operations. Additionally, law enforcement agencies, many of which are desperately in need of economic resources, utilize the proceeds of asset forfeitures to hire additional police officers, fund overtime expenses, and to purchase vital equipment necessary to support their mission to prevent, investigate, solve and prosecute crime. 
     In order for asset forfeiture laws to be effectively utilized by today&#39;s law enforcement agencies, its front-line officers must have actionable intelligence, available to them quasi-instantaneously, so it can be utilized to produce or aid in the development of the probable cause required to seize criminal assets. As previously discussed, the systems currently in use by law enforcement are not capable of providing the criminal intelligence information they contain in an expeditious manner such that it can be consistently employed by front-line officers in the performance of their duties. Moreover, the current format of this criminal intelligence information is not actionable, further contributing to the dilution of its usefulness. Because the information contained in these systems is typically maintained in a format that is either of inadequate detail or too voluminous, a time consuming, subjective analysis of the information is often required before it can be considered actionable intelligence. As a consequence, valuable criminal intelligence information already collected, documented, and maintained by law enforcement is effectively unusable by the front-line officer for asset forfeiture investigations conducted in the field. This failure by law enforcement to maximize the use of available criminal intelligence information in support of its enforcement of existing asset forfeiture laws greatly diminishes the ability of the government to utilize these laws for their designed purpose—that being to facilitate the dismantling of criminal enterprises through the confiscation of criminal assets. 
     In recent years, asset forfeiture proceedings have become a very important countermeasure against terrorist activities. Terrorist organizations, like other criminal enterprises, require substantial economic resources to carry out their heinous acts of destruction. Successful asset forfeiture proceedings possess the ability to strip terrorist organizations of the economic resources they need to exist. In fact, the federal civil forfeiture statute (18 U.S.C. § 981) specifically authorizes the forfeiture of terrorist assets. In particular, section 981(a)(1)(G) authorizes the forfeiture of all assets, whether foreign or domestic, (i) “of any individual, entity, or organization engaged in planning or perpetrating any act of domestic or international terrorism against the United States, citizens or residents of the United States, or their property, and all assets, foreign or domestic, affording any person a source of influence over any such entity or organization; (ii) acquired or maintained by any person with the intent and for the purpose of supporting, planning, conducting, or concealing an act of domestic or international terrorism against the United States, citizens or residents of the United States, or their property; or (iii) derived from, involved in, or used or intended to be used to commit any act of domestic or international terrorism against the United States, citizens or residents of the United States, or their property” (emphasis added). 
     In order for the above cited provisions of the federal civil forfeiture statute to be used effectively in counter-terrorism investigations, and in particular, the time-sensitive environment of law enforcement interdiction actions, front-line officers must be capable of accurately and expeditiously identifying suspected or confirmed terrorists or their aiders and abettors and promptly establishing the requisite probable cause to seize their assets and/or instrumentalities. To do this, the criminal intelligence information needed in support of these investigations must necessarily be nationally available and accessible in real-time, quasi-instantaneously, in an actionable format. Furthermore, this information must be provided preferably before, if not concurrently with the front-line officer engaging a subject or prior to that officer disengaging from the subject. Therefore, any criminal intelligence information intended to be used in support of such investigations must be concise, providing only the most critical details in an actionable format, directly and quasi-instantaneously to the front-line officer. As with other criminal investigations, the limitations of the current data and records management systems and processes make it difficult for the front-line law enforcement officer to acquire the actionable intelligence needed for seizing the assets and instrumentalities of a terrorist. Consequently, existing systems result in a less effective use of asset forfeiture laws against terrorist organizations and fail to strip them of the economic resources they use to fund their heinous acts. 
     Finally, to effectively combat the threat posed to the public by criminal activity, and more importantly, the danger posed to the United States and its citizens by terrorist organizations, today&#39;s law enforcement agencies need a national data and records management system capable of providing front-line law enforcement officers with mobile, direct, real-time, quasi-instantaneous access to, and delivery of, actionable intelligence in support of their investigative, asset forfeiture, officer safety, and public safety responsibilities. In addition, what is needed is one or more methods, carried out by such a system, which employ a set of classification criteria for subjects that specifically and concisely characterizes a subject&#39;s involvement in an unlawful activity. Such a system, and methods carried out thereby, would greatly facilitate the execution of law enforcement duties, particularly those of the front-line officers who are attempting to identify and seize the assets of criminals and terrorists. 
     SUMMARY OF EMBODIMENTS OF THE INVENTION 
     Accordingly, the present invention is directed to a system and method for facilitating the execution of law enforcement duties and enhancing counter-terrorism defenses that substantially obviate one or more problems resulting from the limitations and deficiencies of the related art. 
     In the system and method hereinafter described, the information contained in an agency&#39;s report is used to identify a subject (i.e. a person, vehicle, address, phone number, stolen property, evidence buy funds, bait money, etc.) and classify that subject&#39;s criminal nature prior to that information being entered into the database. Although the identification and classification of a subject is supported by the criminal intelligence contained in that agency report, the report itself is not needed to populate the database. Instead, only the limited information about a subject, the agency&#39;s report number, and the agency&#39;s contact information are needed. Such a succinct presentation of only the most pertinent information concerning a subject is what a front-line officer needs in the time constrained environment of law enforcement operations. For example, a front-line officer working a traffic stop simply doesn&#39;t have the time to read through reports in a database and develop subjective conclusions concerning the subjects (e.g. the driver, any passengers, the vehicle, items located within the vehicle, etc.) he has encountered. Rather, that officer only needs the identity of the subject and the nature of that subject&#39;s criminal activity. Once a front-line officer has this basic, yet sharply focused, information, he can expeditiously continue his investigation armed with what can be truly characterized as “actionable intelligence.” 
     In accordance with one embodiment of the present invention, there is provided a system for facilitating the execution of law enforcement duties, which includes a data processing and records management system (“CDMS”) including one or more processors and data storage means operatively coupled by Ethernet or a cellular internet network, radio, short-range wireless, or satellite connection, hereafter available connectivity to at least one digital computer or mobile digital device, or to a network of digital computers and mobile digital devices (collectively referred to as the network of digital devices—“NDD”), with the CDMS and NDD being configured and arranged to: submit a subject query to the CDMS via the NDD from a first system user; receive, by the CDMS via the NDD, a subject query from a first system user that contains information identifying a subject; CDMS assigns a unique transaction number to the transaction; conduct a search by the CDMS for any subject packet(s) containing information that matches the information identifying the subject of the query by accessing a data records management system (“DRMS”) of subject packets stored on the DRMS; determine whether a match exists between the subject queried and any one of the subject packets in the DRMS; when a match is found not to exist between the subject queried and any of the subject packets in the DRMS, generate and send a negative response from the CDMS via the NDD to the first system user; when a match is found to exist between the subject queried and at least one of the subject packets, further determine the status classification of the subject queried and generate and send a response from the CDMS via the NDD to the first system user—the content of the response being based upon the status classification of the matched subject packet(s) and its respective unique transaction number(s); generate and send a subject queried notification from the CDMS via the NDD to the second system user(s); receive, by the CDMS via the NDD, a subject queried response packet from the second system user; and generate and send that subject queried response packet from the CDMS via the NDD to the first system user. 
     In a further embodiment of this aspect of the present invention, the status classification comprises one of a suspected or confirmed status and the CDMS and NDD are further configured and arranged to: when the status classification is a suspected status, send from the CDMS via the NDD a suspected confirmation response to the first system user referencing the unique transaction number; when the status classification is a confirmed status, generate and send from the CDMS via the NDD a confirmed confirmation response to the first system user referencing the unique transaction number; when the status classification is a suspected status, generate and send from the CDMS via the NDD a suspected subject queried notification to the second system user(s) referencing the unique transaction number(s) for the matched subject packet(s)—the second system user(s) being the user(s) that originally submitted the matched subject packet(s) into the DRMS; when the status classification is a confirmed status, generate and send from the CDMS via the NDD a confirmed subject queried notification to the second system user(s) referencing the unique transactions number(s) for the matched subject packet(s); for either a suspected subject queried notification or a confirmed subject queried notification, receive, by the CDMS via the NDD, a completed subject queried response packet from the second system user; and generate and send that completed subject queried response packet from the CDMS via the NDD to the first system user. 
     In yet a further embodiment, when the first system user does not make a seizure of the subject&#39;s assets, the CDMS and NDD are further configured and arranged to: receive, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a non-seizure notice confirming with CDMS that a seizure was not made; and generate and send from the CDMS via the NDD a non-seizure notice to the second system user(s). 
     In still a further embodiment, when the first system user makes a seizure of the subject&#39;s assets, the CDMS and NDD are further configured and arranged to: receive, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a seizure notice confirming with CDMS that a seizure was made; generate and send from the CDMS via the NDD a seizure notice to the second system user(s) and to a third system user, so that the third system user can initiate an asset forfeiture proceeding; receive a status of asset forfeiture notification from the third system user; determine, by the CDMS, if the third system user is an automated participant or manual participant in the asset forfeiture proceeds disbursement process; generate and send from the CDMS via the NDD final asset forfeiture notification and disbursement notices to the first, second, and third system users; and receive by the CDMS via the NDD acknowledgement of disbursement completed notifications from the first, second, and third system users; if the third system user is an automated participant in the asset forfeiture proceeds distribution process, the CDMS schedules and facilitates the disbursement of the asset forfeiture proceeds to the first, second, and third system users via electronic funds transfer (“EFT”) from the third system users&#39; asset forfeiture fund (“AFF”) account; generate and send from the CDMS via the NDD disbursement completed notifications to the first, second, and third system users; and receive by the CDMS via the NDD acknowledgement notifications from the first, second, and third system users. 
     In yet a further embodiment, the first system user is a querying law enforcement agency, the second system user is a source law enforcement agency, and the third system user is a prosecutor&#39;s office. 
     In still a further embodiment, the subject is one of: (i) a confirmed narcotics dealer, (ii) a confirmed terrorist, and (iii) a confirmed criminal subject of some type. 
     In accordance with another embodiment of the present invention, there is provided a method for facilitating the execution of law enforcement duties, which comprises the steps of: receiving, by the CDMS via the NDD, a subject query from a first system user that contains information identifying a subject; assigning by the CDMS, a unique transaction number to the subject query; conducting a search by the CDMS of the DRMS for subject packet(s) containing information that matches the information identifying the subject of the query by accessing the DRMS of subject packets stored on a data storage means; determining, by the CDMS, whether a match exists between the subject queried and any one of the subject packets in the DRMS; when a match is found not to exist between the subject and any of the subject packets in the DRMS, generating and sending from the CDMS via the NDD a negative response to the first system user; and when a match is found to exist between the subject queried and at least one of the subject packets in the DRMS, further determining the status classification of the subject packet(s) and generating and sending by the CDMS via the NDD a confirmation response to the first system user—the content of the confirmation response being based upon the status classification of the matched subject packet(s) and its unique transaction number(s); generating and sending a subject queried notification from the CDMS via the NDD to the second system user(s); receiving, by the CDMS via the NDD, a completed subject queried response packet from the second system user; and generating and sending that completed subject queried response packet from the CDMS via the NDD to the first system user. 
     In yet a further embodiment of this aspect of the present invention, the status classification comprises one of either suspected or confirmed, and the method further comprises the steps of: when the status classification is suspected, generating and sending a suspected confirmation response from the CDMS via the NDD to the first system user referencing the unique transaction number; when the status classification is confirmed generating and sending a confirmed confirmation response from the CDMS via the NDD to the first system user referencing the unique transaction number; when the status classification is suspected, generating and sending a suspected subject queried notification from the CDMS via the NDD to the second system user(s)—the second system user(s) being the user that originally submitted the matched subject packet(s) into the DRMS of the CDMS; when the status classification is confirmed, generating and sending a confirmed subject queried notification from the CDMS via the NDD to the second system user(s) referencing the unique transaction number(s) for the matched subject packet(s); for either a suspected subject queried notification or a confirmed subject queried notification, receiving, by the CDMS via the NDD, a completed subject queried response packet from the second system user; and generating and sending that completed subject queried response packet from the CDMS via the NDD to the first system user. 
     In still a further embodiment, when first system user does not make a seizure of the subject&#39;s assets, the method further comprises the steps of: receiving, by the CDMS via the NDD, an acknowledgement from the first system user confirming the first system user received the confirmation response from the CDMS and a non-seizure notice confirming with CDMS that a seizure was not made; and generating and sending from the CDMS via the NDD a non-seizure notice to the second system user(s). 
     In yet a further embodiment, when first system user makes a seizure of the subject&#39;s assets, the method further comprises the steps of: receiving, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a seizure notice confirming with CDMS that a seizure was made; generating and sending from the CDMS via the NDD a seizure notice to the second system user(s) and to a third system user, so that the third system user can initiate an asset forfeiture proceeding; receiving, by the CDMS via the NDD, a status of asset forfeiture notification from the third system user; determining, by the CDMS, if the third system user is an automated participant or manual participant in the asset forfeiture proceeds disbursement process; generating and sending, from the CDMS via the NDD, final asset forfeiture notification and disbursement notices to the first, second, and third system users; and receiving, by the CDMS via the NDD acknowledgement of disbursement completed notifications from the first, second, and third system users; if, the third system user is an automated participant, the CDMS schedules and facilitates the disbursement of the asset forfeiture proceeds to the first, second, and third system users via EFT from the third system users&#39; AFF account; generating and sending, from the CDMS via the NDD, disbursement completed notifications to the first, second, and third system users; and receiving, by the CDMS via the NDD, an acknowledgement notification from the first, second, and third system users. Alternatively, if the third system user is a manual participant in the asset forfeiture proceeds disbursement process, generating and sending from the CDMS via the NDD, final asset forfeiture notification and disbursement notices to the first, second, and third system users; receiving, by the CDMS via the NDD, final asset forfeiture notices from the first, second, and third system users; transferring, via EFT, to the first and second system users, by the third system user, the disbursements detailed in the disbursements notice; generating and sending to the CDMS via the NDD, a confirmation notice from the third system user; receiving, by the CDMS via the NDD, the confirmation of disbursement notice from the third system user; generating and sending, from the CDMS via the NDD, disbursement completed notices to the first, second, and third system users; receiving, from the CDMS via the NDD, the disbursement completed notices by the first, second, and third system users; generating and sending, to the CDMS via the NDD, the acknowledgment of disbursement completed notices from the first, second, and third system users; and receiving by the CDMS via the NDD, the acknowledgment of disbursement completed notices from the first, second, and third system users. 
     In still a further embodiment, the first system user is a querying law enforcement agency, the second system user is a source law enforcement agency, and the third system user is a prosecutor&#39;s office. 
     In yet a further embodiment, the subject is one of: (1) a confirmed narcotics dealer, (2) a confirmed terrorist, and (3) a confirmed criminal subject of some type. 
     In accordance with yet another embodiment of the present invention, there is provided a system for enhancing anti-terrorism and counter-terrorism capabilities by gathering, analyzing, and disseminating actionable intelligence essential to investigations and seizing terrorist&#39;s assets, which includes a data processing and records management system (“CDMS”) including one or more processors and data storage means operatively coupled connected via available connectivity to the NDD with the CDMS and NDD being configured and arranged to: submit to the CDMS via the NDD, a subject query from a first system user; receive, by the CDMS via the NDD, a subject query from a first system user that contains information identifying a subject; conduct a search by the CDMS for any subject packet(s) containing information that matches the information identifying the subject of the query by accessing a data records management system (“DRMS”) of subject packets stored on the CDMS; determine whether a match exists between the subject queried and any one of the subject packets in the DRMS; when a match is found not to exist between the subject queried and any of the subject packets in the DRMS, generate and send a negative response from the CDMS via the NDD, to the first system user; when a match is found to exist between the subject queried and at least one of the subject packets in the DRMS, further determine the status classification of the subject queried as a suspected or confirmed terrorist and generate and send a confirmation response from the CDMS via the NDD, to the first system user—the content of the response being based upon the status classification of the matched subject packet(s) and its unique transaction number(s); generate and send a terrorist subject queried notification via the NDD, from the CDMS to the second system user(s); receive, by the CDMS via the NDD, a completed terrorist subject queried response packet from the second system user; and generate and send that completed terrorist subject queried response packet from the CDMS via the NDD to the first system user. 
     In a further embodiment of this aspect of the present invention, the status classification comprises one of a suspected terrorist or confirmed terrorist and the CDMS and NDD are further configured and arranged to: assign a unique transaction number to the subject query; when the status classification is suspected terrorist, generate and send, from the CDMS via the NDD, a suspected terrorist confirmation response to the first system user referencing the unique transaction number; when the status classification is confirmed terrorist, generate and send from the CDMS via the NDD, a confirmed terrorist confirmation response to the first system user referencing the unique transaction number; when the status classification is suspected terrorist, generate and send from the CDMS via the NDD, a suspected terrorist subject queried notification to the second system user(s) referencing the unique transaction number(s) for the matched subject packet(s)—the second system user(s) being the user(s) that originally submitted the matched subject packet(s) into the DRMS; when the status classification is confirmed terrorist, generate and send from the CDMS via the NDD, a confirmed terrorist subject queried notification to the second system user(s) referencing the unique transaction number(s) for the matched subject packet(s); for either a suspected terrorist subject queried notification or a confirmed terrorist subject queried notification, receive, by the CDMS via the NDD, a completed terrorist subject queried response packet from the second system user; and generate and send that completed terrorist subject queried response packet from the CDMS via the NDD to the first system user. 
     In yet a further embodiment, when the first system user does not make a seizure of the terrorist subject&#39;s assets, the CDMS and NDD are further configured and arranged to: receive, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a non-seizure notice confirming with CDMS that a seizure was not made; and generate and send from the CDMS via the NDD, a non-seizure notice to the second system user(s). 
     In still a further embodiment, when the first system user makes a seizure of the terrorist subject&#39;s assets, the CDMS and NDD are further configured and arranged to: receive, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a seizure notice confirming with CDMS that a seizure was made; generate and send, from the CDMS via the NDD, a seizure notice to the second system user(s) and to a third system user, so that the third system user can initiate an asset forfeiture proceeding; receive a status of asset forfeiture notification from the third system user; determine if the third system user is an automated or manual participant in the asset forfeiture proceeds disbursement process; generate and send, from the CDMS via the NDD, final asset forfeiture notification and disbursement notices to the first, second, and third system users; and receive, by the CDMS via the NDD, acknowledgement of disbursement completed notifications from the first, second, and third system users; if the third system user is an automated participant, the CDMS schedules and facilitates the disbursement of the asset forfeiture proceeds to the first, second, and third system users via EFT from the third system users&#39; AFF account; generate and send, from the CDMS via the NDD, disbursement completed notifications to the first, second, and third system users; and receive, by the CDMS via the NDD, an acknowledgement notification from the first, second, and third system users. 
     In yet a further embodiment, the first system user is a querying law enforcement agency, the second system user is a source law enforcement agency, and the third system user is a prosecutor&#39;s office. 
     In still a further embodiment, the subject is one of: (1) a suspected terrorist, (2) a confirmed terrorist, and (3) a terrorist subject of some type. 
     One or more embodiments of the present invention provides a system that implements a set of automated status classifications for subjects with suspected or confirmed involvement in terrorist activities. The status classifications specifically and concisely establish the subject&#39;s involvement in terrorist activities—(See 18 U.S.C. § 2331(1), § 2331(5), USA PATRIOT Act, International Money Laundering Abatement and Financial Anti-Terrorism Act of 2001—included in the USA PATRIOT Act, HSPD-2, Public Law 107-306, and IRTPA). Moreover, the preferred embodiments of this system facilitate the seizure of terrorist assets in accordance with section 981(a)(1)(G) of the federal civil forfeiture statute (18 U.S.C. § 981) by providing front-line law enforcement officers with an automated, efficient means by which they have quasi-instantaneous, direct access to actionable intelligence highly useful for preventing the unlawful use of force and violence against persons or property to intimidate or coerce a government, the civilian population, or any segment thereof, in furtherance of political or social objectives, identifying terrorists incidents, and establishing probable cause necessary to seize terrorist&#39;s assets. (See 28 C.F.R. Section 0.85). Accordingly, the present invention materially contributes to countering terrorism and enhances counter-terrorism defenses by providing front-line law enforcement personnel with an automated system that (1) implements a set of automated status classifications for characterizing a subject&#39;s involvement in terrorist activities, (2) operates as a quasi real-time electronic data processing and records management system and gateway to actionable terrorist intelligence that will prevent terrorists&#39; activities, identify terrorist incidents, and facilitate the establishment of the probable cause necessary to effectuate seizure of terrorist assets, and (3) implements an automated and streamlined electronic process for asset forfeiture actions that ensure terrorist assets are efficiently and effectively seized. As a result of the present invention, the actionable intelligence necessary to prevent acts of terrorism will be made available quasi-instantaneously, on a national scale, to law enforcement officers, most importantly, front-line law enforcement officers. Further, this actionable intelligence will make terrorist subjects known to front-line law enforcement officers, thereby stripping terrorists of their most prized asset—anonymity. Finally, this actionable intelligence will allow for a more effective use of asset forfeiture proceedings against terrorists, thereby depleting terrorist organizations&#39; economic resources and preventing them from funding or obtaining assets necessary to carry out their heinous acts of destruction. 
     In accordance with one embodiment of the present invention, there is provided a method for enhancing anti-terrorism and counter-terrorism capabilities by gathering, analyzing, and disseminating actionable intelligence essential to countering terrorism and seizing terrorist&#39;s assets, which comprises the steps of: receiving, by the CDMS via the NDD, a subject query from a first system user that contains information identifying a subject; conducting a search by the CDMS of the DRMS for a subject packet(s) containing information that matches the information identifying the subject of the query by accessing the DRMS of subject packets stored on a data storage means; determining, by utilizing the CDMS, whether a match exists between the subject queried and any one of the subject packets in the DRMS; when a match is found not to exist between the subject and any of the subject packets in the DRMS, generating and sending from the CDMS via the NDD, a negative response to the first system user; and when a match is found to exist between the subject queried and at least one of the subject packets in the DRMS, further determining the status classification of the subject queried as a suspected or confirmed terrorist; and generating and sending, by the CDMS via the NDD, a response to the first system user—the content of the response being based upon the status classification of the matched subject packet(s) and its unique transaction number(s); and generating and send a terrorist subject queried notification, via the NDD from the CDMS, to the second system user(s); receiving, by the CDMS via the NDD, a completed terrorist subject queried response packet from the second system user; and generating and sending that completed terrorist subject queried response packet from the CDMS via the NDD to the first system user. 
     In a further embodiment of this aspect of the present invention, the status classification comprises one of suspected terrorist or confirmed terrorist and the method further comprises the steps of: assigning, by the CDMS, a unique transaction number to the subject query when the status classification is suspected terrorist, generating and sending a suspected terrorist confirmation response from the CDMS via the NDD, to the first system user referencing the unique transaction number; when the status classification is confirmed terrorist, generating and sending a confirmed terrorist confirmation response from the CDMS via the NDD, to the first system user referencing the unique transaction number; when the status classification is suspected terrorist, generating and sending a suspected terrorist subject queried notification from the CDMS via the NDD, to the second system user(s)—the second system user(s) being the user that originally submitted the matched subject packet(s) into the DRMS of the CDMS; and when the status classification is a confirmed terrorist, generating and sending a confirmed terrorist subject queried notification from the CDMS via the NDD, to the second system user(s) referencing the unique transaction number(s) for the matched subject packet(s); for either a suspected terrorist subject queried notification or a confirmed terrorist subject queried notification, receiving, by the CDMS via the NDD, a completed terrorist subject queried response packet from the second system user; and generating and sending that completed terrorist subject queried response packet from the CDMS via the NDD to the first system user. 
     In yet a further embodiment, when the first system user does not make a seizure of the terrorist subject&#39;s assets, the method further comprises the steps of: receiving, by the CDMS via the NDD, an acknowledgement from the first system user confirming the first system user received the confirmation response from the CDMS and a non-seizure notice confirming with CDMS that a seizure was not made; and generating and sending, from the CDMS via the NDD, a non-seizure notice to the second system user(s). 
     In still a further embodiment, when the first system user makes a seizure of the terrorist subject&#39;s assets, the method further comprises the steps of: receiving, by the CDMS via the NDD, an acknowledgement from the first system user confirming that the first system user received the confirmation response from the CDMS and a seizure notice confirming with CDMS that a seizure was made; generating and sending, from the CDMS via the NDD, a seizure notice to the second system user(s) and to a third system user, so that the third system user can initiate an asset forfeiture proceeding; receiving, by the CDMS via the NDD, a status of asset forfeiture notification from the third system user; determining, by the CDMS, if the third system user is an automated participant or manual participant in the asset forfeiture proceeds disbursement process; generating and sending, from the CDMS via the NDD, final asset forfeiture notification and disbursement notices to the first, second, and third system users; and receiving, by the CDMS via the NDD, acknowledgement of disbursement completed notifications from the first, second, and third system users; if, the third system user is an automated participant in the asset forfeiture proceeds disbursement process, the CDMS schedules and facilitates the disbursement of the asset forfeiture proceeds to the first, second, and third system users via EFT from the third system users&#39; AFF account; generating and sending, from the CDMS via the NDD, disbursement completed notifications to the first, second, and third system users; and receiving, by the CDMS via the NDD, an acknowledgement notification from the first, second, and third system users. Alternatively, if the third system user is a manual participant in the asset forfeiture proceeds disbursement process, generating and sending, from the CDMS via the NDD, final asset forfeiture notification and disbursement notices to the first, second, and third system users; receiving, by the CDMS via the NDD, final asset forfeiture notices from the first, second, and third system users; transferring via EFT to the first and second system users by the third system user the disbursements detailed in the disbursements notice; generating and sending, to the CDMS via the NDD, a confirmation notice from the third system user; receiving, by the CDMS via the NDD, the confirmation of disbursement notice from the third system user; generating and sending, from the CDMS via the NDD, disbursement completed notices to the first, second, and third system users; receiving, from the CDMS via the NDD, the disbursement completed notices by the first, second, and third system users; generating and sending, to the CDMS via the NDD, the acknowledgment of disbursement completed notices from the first, second, and third system users; and receiving, by the CDMS via the NDD, the acknowledgment of disbursement completed notices from the first, second, and third system users. 
     In yet a further embodiment, the first system user is a querying law enforcement agency, the second system user is a source law enforcement agency, and the third system user is a prosecutor&#39;s office. 
     In still a further embodiment, the subject is one of: (i) a suspected terrorist, (ii) a confirmed terrorist, and (iii) a terrorist subject of some type. 
     One or more embodiments of the present invention provide a method that comprises the steps for determining the status classification of terrorist subjects as either suspected or confirmed. This method of status classification determination specifically and concisely establishes a subject&#39;s involvement in terrorist activities—(See 18 U.S.C. § 2331(1), § 2331(5), USA PATRIOT Act, International Money Laundering Abatement and Financial Anti-Terrorism Act of 2001—included in the USA PATRIOT Act, HSPD-2, Public Law 107-306, and IRTPA) Moreover, preferred embodiments of this method facilitate the seizing of terrorist assets in accordance with section 981(a)(1)(G) of the federal civil forfeiture statute (18 U.S.C. § 981) by providing front-line law enforcement officers with an automated, efficient means by which they have quasi-instantaneous, direct access to actionable intelligence highly useful for preventing the unlawful use of force and violence against persons or property to intimidate or coerce a government, the civilian population, or any segment thereof, in furtherance of political or social objectives, identifying terrorists incidents, and establishing probable cause necessary to seize terrorist&#39;s assets. (See 28 C.F.R. Section 0.85) Accordingly, the present method of the invention materially contributes to countering terrorism and enhances counter-terrorism defenses by providing front-line law enforcement personnel through the development and automation of both processes and methods: (1) a set of status classifications for determining and clarifying a subject&#39;s involvement in terrorist activities, (2) operating a quasi real-time electronic data processing and records management system and gateway to actionable terrorist intelligence preventing terrorists activities, identifying terrorists incidents, and facilitating the establishment of the probable cause necessary to effectuate the seizure of terrorist assets, and (3) implementing a streamlined electronic process and method for asset forfeiture actions ensuring terrorist assets are efficiently and effectively seized. As a result of the present invention, the actionable intelligence necessary to prevent acts of terrorism will be made accessible quasi-instantaneously to front-line law enforcement officers. Further, this method of providing actionable intelligence to front-line law enforcement officers will make terrorist subjects identifiable, thereby stripping terrorists of their most prized asset—anonymity. Finally, this method for providing actionable intelligence will allow law enforcement to perpetuate the more effective use of asset forfeiture proceedings against terrorists, thereby depleting the terrorist organizations&#39; economic resources and preventing them from funding or obtaining assets necessary to carry out their heinous acts of destruction. 
     It is understood that the objects and summary, and the following detailed description of the present invention, are merely exemplary and explanatory in nature. As such, the objects and summary, and the following detailed description of the invention, should not be construed to limit the scope of the appended claims in any sense. 
     One object of one or more embodiments is to provide an automated system and method for facilitating the execution of law enforcement duties, which enables a national database to be quasi-instantaneously and directly accessible by a QLEA(s) via available connectivity to a network of digital devices (“NDD”) configured and arranged to use a program or application loaded thereon or accessible therefrom. 
     Another object of one or more embodiments is to provide an automated system and method for facilitating the execution of law enforcement duties that establishes a set of classification criteria for subjects, which identifies the subject and specifically and concisely determines and identifies the subject&#39;s involvement in an unlawful activity. 
     Still another object of one or more embodiments is to provide an automated system and method for facilitating the execution of law enforcement duties that provides actionable intelligence from a national database to a QLEA or querying system user. 
     Yet another object of one or more embodiments is to provide an automated system and method for enhancing counter-terrorism defenses by gathering, analyzing, and disseminating actionable intelligence essential to counter-terrorism investigations and seizing terrorist&#39;s assets. 
     Still another object of one or more embodiments is to provide an automated system and method for enhancing counter-terrorism defenses by establishing a set of classification criteria for terrorist subjects which identifies a terrorist subject and specifically and concisely determines and identifies that subject&#39;s involvement in terrorist activity. 
     Yet another object of one or more embodiments is to provide an automated system and method for enhancing counter-terrorism defenses by providing actionable intelligence from a national database to a QLEA or querying system user. 
     Additional objects and advantages of the present invention will be apparent from the following detailed description, the accompanying drawings, and the appended claims. 
    
    
     
       BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS 
       The invention will now be described, by way of example, with reference to the accompanying drawings, in which: 
         FIG. 1  is a block diagram of an exemplary system for facilitating the execution of law enforcement duties and enhancing anti-terrorism and counter-terrorism capabilities, according to an embodiment of the present invention. 
         FIG. 2  is a block diagram of an exemplary system for facilitating the submission of subject packet information to the system by a SLEA through a subject packet input application or program using a local digital computer or mobile digital device networked together or connected, via available connectivity, to the primary load balanced client interface server of the CDMS. Each local digital computer or mobile digital device will be configured, arranged and loaded with the subject packet input application or program or be connected to the CDMS, via available connectivity, making the subject packet input application accessible to the SLEA. When available connectivity is unavailable, each local digital computer or mobile digital device will be configured, arranged and loaded with the subject packet input application or program capable of storing the SLEA&#39;s subject packet information submission within the local digital computer or mobile digital device until available connectivity is available; at that time, the SLEA may upload the subject packet submission to the CDMS. Finally, the DRMS of the CDMS will be configured and arranged to store all subject packets uploaded to it by SLEAs. 
         FIG. 3  is a block diagram of an exemplary system for facilitating a subject query by a QLEA through the subject query application or program using a local digital computer or mobile digital device networked together or connected, via available connectivity, to the primary load balanced client interface server of the CDMS. Each local digital computer or mobile digital device will be configured, arranged and loaded with the subject query application or be connected to the CDMS, via available connectivity, making the subject packet query application or program accessible to the system users. When available connectivity is unavailable, each local digital computer or mobile digital device will be configured, arranged and loaded with the subject packet query application or program capable of storing the QLEA&#39;s subject query within the local digital computer or mobile digital device until available connectivity is available; at that time, the QLEA may submit the subject query to the CDMS. The DRMS of the CDMS will be configured and arranged to create, receive, and store every subject query submitted by a QLEA. 
         FIG. 4  is a block diagram of an exemplary system for creating an investigative alert and related processes by a system user through the investigative alert application or program using a local digital computer or mobile digital device networked or connected, via available connectivity, to the primary load balanced client interface server of the CDMS. Each local digital computer or mobile digital device will be configured, arranged and loaded with the investigative alert application or program or be connected to the CDMS, via available connectivity, making the investigative alert application or program accessible to the system users. When available connectivity is unavailable, each local digital computer or mobile digital device will be configured, arranged and loaded with the investigative alert application or program capable of storing the system user&#39;s investigative alert within the local digital computer or mobile digital device until available connectivity is available; at that time, the system user may submit the investigative alert to the CDMS. The DRMS of the CDMS will be configured and arranged to create, receive, and store every investigative alert submitted by a system user. 
         FIG. 5  is a partial flowchart illustrating exemplary subject query and retrieval processes carried out by the system of  FIG. 3  and detailed in  FIGS. 5-13 , according to an embodiment of the present invention. 
         FIG. 6  is a continuation of the flowchart of  FIG. 5 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 7  is a continuation of the flowchart of  FIG. 6 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 8  is a continuation of the flowchart of  FIGS. 6 and 7 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 9  is a continuation of the flowchart of  FIG. 8 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 10  is a continuation of the flowchart of  FIG. 9 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 11  is a continuation of the flowchart of  FIG. 10 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 12  is a continuation of the flowchart of  FIG. 9 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 13  is a continuation of the flowchart of  FIG. 9 , which illustrates additional steps of the exemplary subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 14  is a partial flowchart illustrating an exemplary subject packet input processes for submitting subject packets into the system of  FIG. 2  and detailed in  FIGS. 14-17 , according to an embodiment of the present invention. 
         FIG. 15  is a continuation of the flowchart of  FIG. 14 , which illustrates additional steps of the exemplary subject packet input processes, according to an embodiment of the present invention. 
         FIG. 16  is a continuation of the flowchart of  FIG. 15 , which illustrates additional steps of the exemplary subject packet input processes, according to an embodiment of the present invention. 
         FIG. 17  is a continuation of the flowchart of  FIG. 15 , which illustrates additional steps of the exemplary subject packet input processes, according to an embodiment of the present invention. 
         FIG. 18  is a partial flowchart illustrating an exemplary terrorist subject query and retrieval processes carried out by the system of  FIG. 3  and detailed in  FIGS. 18-26 , according to an embodiment of the present invention. 
         FIG. 19  is a continuation of the flowchart of  FIG. 18 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 20  is a continuation of the flowchart of  FIG. 19 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 21  is a continuation of the flowchart of  FIGS. 19 and 20 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 22  is a continuation of the flowchart of  FIG. 21 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 23  is a continuation of the flowchart of  FIG. 22 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 24  is a continuation of the flowchart of  FIG. 23 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 25  is a continuation of the flowchart of  FIG. 22 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 26  is a continuation of the flowchart of  FIG. 22 , which illustrates additional steps of the exemplary terrorist subject query and retrieval processes, according to an embodiment of the present invention. 
         FIG. 27  is a partial flowchart illustrating an exemplary input and issuance of an investigative alert processes carried out by the system of  FIG. 4 , detailed in  FIGS. 27-30 , according to an embodiment of the present invention. 
         FIG. 28  is a continuation of the flowchart of  FIG. 27 , which illustrates additional steps of the exemplary input and issuance processes of an investigative alert, according to an embodiment of the present invention. 
         FIG. 29  is a continuation of the flowcharts of  FIGS. 27 and 28  which illustrates additional steps of the exemplary input and issuance processes of an investigative alert, according to an embodiment of the present invention. 
         FIG. 30  is a continuation of the flowchart of  FIG. 28 , which illustrates additional steps of the exemplary input and issuance processes of an investigative alert, according to an embodiment of the present invention. 
         FIG. 31  is a flowchart illustrating an exemplary creation of an archive record processes carried out by the system of  FIG. 1 , according to an embodiment of the present invention. 
         FIG. 32  is a partial flowchart illustrating an exemplary subject query of paper currency and retrieval processes carried out by the system of  FIG. 1 , detailed in  FIGS. 32-33 , according to an embodiment of the present invention. 
         FIG. 33  is a continuation of the flowchart of  FIG. 32 , which illustrates additional steps of the exemplary subject query of paper currency and retrieval processes, according to an embodiment of the present invention. 
         FIG. 34  is a flowchart illustrating exemplary archive record query and retrieval processes carried out by the system of  FIG. 1 , according to an embodiment of the present invention. 
         FIG. 35  is a partial flowchart illustrating an exemplary subject packet input processes for submitting subject packets for paper currency into the system of  FIG. 1 , according to an embodiment of the present invention. 
         FIG. 36  is a flowchart illustrating an exemplary process for the issuance, completion, transmission, and delivery of a subject queried response packet carried out by the system of  FIG. 1 , according to an embodiment of the present invention. 
     
    
    
     Throughout the figures, the same components and process steps are always denoted using the same reference characters so that, as a general rule, they will only be described once. 
     DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION 
     The present invention is described herein, in an exemplary manner, with reference to data processing system architecture and flowcharts that illustrate exemplary processes carried out by the central data management system (“CDMS”). In a preferred embodiment, functional blocks of the flowchart illustrations can be implemented by computer program instructions. As such, it is to be understood that the operations performed in subsequent functional blocks of the flowchart illustrations are typically carried out by the computer program instructions in response to operations performed in one or more preceding functional blocks of the flowchart illustrations. These computer program instructions may be loaded directly onto an internal data storage device of a data processing system (e.g., a hard drive of a computer). Alternatively, these computer program instructions could be stored on a portable computer-readable medium (e.g., a flash drive, a floppy disk, a compact disk, etc.), and then subsequently loaded onto a data processing system such that the instructions can be executed thereby. In other embodiments, these computer program instructions could be embodied in the hardware of the data processing system, rather than in the software thereof. Thus, as used herein, it is to be understood that, when a computer or data processing system is said to be configured and arranged to perform one or more steps or functions, this is equivalent to reciting that the computer or data processing system is specifically programmed or specially programmed to carry out the one or more steps or functions. 
     For the sake of brevity, conventional data processing system components, conventional data networking, and conventional software coding will not be described in detail herein. Also, it is to be understood that the connecting lines shown in the block diagram(s) included herein are intended to represent functional relationships and/or operational couplings between the various components. Similarly, connecting lines are also used between the elements of the flowcharts in order to illustrate functional relationships there between. In addition to that which is explicitly depicted, it is to be understood that many alternative or additional functional relationships and/or physical connections may be incorporated in a practical application of the system. 
     1. Terminology 
     As used herein, the term “actionable intelligence” refers to information of a defined quantity and quality “based upon an established legal standard” that is concise and provided electronically in response to a real-time query. 
     As used herein, the term “subject” broadly refers to any one of the following: a person, a motor vehicle, a marine vessel, an aircraft, an address, paper currency, a telephone number, an e-mail address, an Internet protocol address (“IP”), or any other thing that can be described with specificity. In a non-limiting, exemplary embodiment, a subject is established in a data records management system (“DRMS”) of a central data management system (“CDMS”) by a second system user who submits a subject packet. 
     As used herein, the term “descriptive data” refers to information used to describe with specificity or identify a subject. In a non-limiting, exemplary embodiment of the invention, descriptive data for a person is comprised of a person&#39;s full name, sex, and race, and other known descriptive information obtained from official government documentation, such as date of birth, social security account number, driver&#39;s license number, state identification card number, state identification number (“SID”), alias(es), Integrated Automated Fingerprint Identification System (“IAFIS”) number, fingerprints, other biometric data, etc. While in a preferred embodiment, descriptive data for a motor vehicle comprises a license plate number or Vehicle Identification Number (“VIN”), descriptive data for an aircraft comprises an aircraft registration number, and descriptive data for a marine vessel comprises a vessel registration number. The descriptive data for each of the aforementioned vehicles may also include the state and/or country in which the registration was issued. In one embodiment, descriptive data for an address is comprised of a complete property address. Descriptive data for real, personal or other property can be submitted to the CDMS if the item can be specifically described using official government identification documentation or other available identifying documentation. Furthermore, in one embodiment of the invention, a photograph of a subject can be attached as descriptive data. 
     The term “subject packet” is used herein to describe a group of data preferably consisting of the following four components: (1) a subject, (2) descriptive data, (3) a status classification, and (4) the second system user&#39;s report number(s) documenting the information upon which the status classification is based. 
     The term “confirmation response” is used herein to refer to a response message sent from a central data management system (“CDMS”) to the first system user notifying the user of the results found when a subject query is made of the data records management system (“DRMS”). In a non-limiting, exemplary embodiment, the response message is sent from the CDMS, via available connectivity, to the first system user&#39;s local digital computer or mobile digital device. 
     The terms “querying law enforcement agency” or “querying LEA” or “QLEA” are used herein to refer to the one or more individuals of a law enforcement agency who submit a subject query to the CDMS, via available connectivity, from a local digital computer or mobile digital device. 
     The terms “source law enforcement agency” or “source LEA” or “SLEA” are used herein to refer to the one or more individuals of a law enforcement agency who input data into the DRMS of the CDMS, via available connectivity, using a local digital computer or mobile digital device. 
     In an exemplary embodiment, the term “status classification” is used herein to refer to the stipulative definition component of a subject packet submitted to the CDMS by a second system user that establishes said subject packet as actionable intelligence. A status classification is comprised of two elements, the first element being either of the terms “Confirmed” or “Suspected”, which are used to describe the quality and quantity of articulable evidence or facts known or possessed by a second system user about a particular subject, and the second element being any definable criminal activity or illegal condition associated with that particular subject (e.g. drug dealer, kidnapper, bank robber, drug transport vehicle, bait money, drug buy money, terrorist meeting location, money launderer, stolen property, etc.). The first element of a status classification is based on the legally recognized standards of “probable cause” or “reasonable suspicion.” For example, a status classification of “Confirmed—Drug Dealer,” indicates that, at a minimum, the second system user who submitted the subject packet has information and/or evidence equivalent to the legal standard of probable cause; that is to say, evidence in a quality and quantity of sufficient articulable facts, supported by circumstances sufficiently strong to justify a prudent and cautious person&#39;s belief, that the subject is a drug dealer. A status classification of “Suspected—Drug Dealer,” indicates that, at a minimum, the second system user who submitted the subject packet has information and/or evidence equivalent to the legal standard of reasonable suspicion; that is to say, “specific and articulable facts,” “taken together with rational inferences from those facts,” such that a reasonable person could have reasonable cause to suspect that the subject is a drug dealer. The status classification, as defined in the CDMS, is not in and of itself to be considered by the first system user as probable cause or reasonable suspicion. Instead, the status classification provides a first system user with an objective minimum standard upon which to evaluate the quality and quantity of the second system user&#39;s information upon which the status classification is based. 
     2. Exemplary System 
       FIGS. 1-4  are schematic representations of an exemplary system  12 ,  14 ,  16 , and  18  for facilitating the execution of law enforcement duties and enhancing anti-terrorism and counter-terrorism capabilities, according to an embodiment of the invention. At its core, the system  12 ,  14 ,  16 , and  18  includes a central data management system (“CDMS”). In a preferred embodiment, as shown in  FIG. 1 , the CDMS  16  comprises a central data processing system that is in the form of a central digital computer or central server  10 , (“primary server”), which has one or more processors and one or more data storage means. Alternatively, a preferred embodiment of the CDMS  16  comprises a central data processing system that is in the form of multiple digital computers or servers arranged in a multi-tier web application  10 , each having one or more processors and one or more data storage means. In a preferred embodiment of the CDMS  16 , the digital computers or servers may use virtualization software, such as VM Ware, Hyper-V or Xen, to more effectively utilize the digital computer or server resources while providing application software  30 , storing system data  20 , or serving as a webserver  10 , database  20 , record management system  20 , or client interface server  10 . Alternatively, in a preferred embodiment of the CDMS  16 , the primary load balanced client interface server  10  may be operatively coupled by Ethernet or a cellular, Internet, network, radio, short-range wireless, or satellite connection (collectively “available connectivity”)  80 . The servers will generally be of the Intel, AMD, Sun, or mainframe variety and will utilize Linux, Windows, Solaris, z/OS, or AIX operating systems. 
     The primary load balanced client interface server  10  will serve as the entry point for all CDMS system users. CDMS software applications will be stored on the application server  30  while the database and/or records management system will be stored in the database/records management system  20 . The primary load balanced client interface server  10 , application server  30 , and database/records management system  20  will all be operatively coupled together, via Ethernet or available connectivity. The primary load balanced client interface server  10  will handle initial CDMS system user interactions while the application server  30  will reside behind a firewall separating the primary load balanced client interface server  10  from the application server  30 . The database/records management system  20  will reside behind a firewall separating the application server  30  from the database/records management system  20 . This multi-tier configuration will allow security to be maximized by allowing the integration of multi-level firewalls. 
     In a preferred embodiment, the application server  30  will store the CDMS software applications used to accept, validate, match, and store all input data submitted by system users to the CDMS  16 . Additionally, in a preferred embodiment, the application server  30  will store all applications and programs for the execution of a subject query, the archive feature, the investigative alert feature, the law enforcement agency report feature, the public/private video surveillance monitoring feature, the six-person photo array line-up feature, the fingerprint recording and/or query feature, the satellite downlink feature, the GPS officer tracking feature, the mobile tracking device monitoring feature, the license plate tracking and notification feature, the iris/retina recording and/or query feature, the facial recognition recording and/or query feature, the palm-print recording and/or query feature, the hand geometry recording and/or query feature, the voice recording and/or query feature, the administrative management feature, and the report and evidence exchange feature (collectively “available software applications”). 
     The data, which includes a plurality of subject packets, investigative alerts, and the system archive, is compiled and maintained in the database and record management system  20  and would include data stored on one or more data storage devices (e.g., hard drive(s)) of the database and/or records management system  20 . This preferred embodiment would have the database and record management system  20 , configured, arranged, and replicated through operative coupling via Ethernet, to the primary load balanced client interface server  10 , but may be connected by other available connectivity. This multi-tier configuration provides for maximum security of the database and/or records management systems  20  by allowing the integration of multi-level firewalls. In a preferred embodiment, the primary load balanced client interface server  10  would not function as an application server  30  for the CDMS system  16  or as the database/records management system  20 . However, by storing or serving applications to CDMS system users  40  and  60 , the primary load balanced client interface server  10  could serve CDMS applications or programs to include the subject packet input application  32 , subject query application  34 , investigative alert application  38 , or archive record query application. The subject packet input application  32  enables a second system user (via  52  or  72 ) to input subject packet data into the CDMS  12  via the NDD  22 . The subject query application  34  enables a first system user (via  54  or  74 ) to query the CDMS  14  via the NDD  24 . The investigative alert application  38  enables a system user (via  58  or  78 ) to create or receive investigative alerts from the CDMS  18  via the NDD  28 . The subject input data is prepared for uploading into the CDMS  12  by the subject packet input application  32  or  52 . Subject packet data is queried by a first system user through a local digital computer or mobile digital device running  54  or  74 , or queried by the subject query application  34 . Investigative alerts are created or received by CDMS  18  system users through a local digital computer or mobile digital device  48  or  68  running the investigative alert application  58  or  78 . A local digital computer  40  will be configured and arranged to include a central processing unit, running an available operating system compatible with the CDMS client interface or web-interface software, mouse, keyboard, monitor, among other optional hardware (collectively “local digital computer”)  40 . The second system user will input data into the subject packet input application  32 ,  52 , or  72  through the use of multiple pieces of hardware connected, via wired or wireless connectivity, to a SLEA local digital computer  42  or SLEA mobile digital device  62  to include: (1) keyboard, (2) mouse, (3) passive stylus or digital pen. Alternatively, the second system user will input data into the CDMS  12  using availability connectivity and the subject packet input application  32 ,  52 , or  72  through the use of an onscreen virtual keyboard. In one embodiment, the subject packet input application  32 ,  52 , or  72  is loaded directly on the CDMS  12  such that a second system user is able to access the subject packet input application  32  by logging onto the primary load balanced client interface server  10  from the SLEA local digital computer  42  which is configured and arranged and operatively connected to the CDMS  12  via available connectivity  80 . In other embodiments of the invention, the subject packet input program  52  is loaded onto a SLEA&#39;s local digital computer  42  and then the subject packet data entered by the SLEA is transmitted from the SLEA&#39;s local digital computer  42  to the primary load balanced client interface server  10  by available connectivity  80 . The SLEA&#39;s local digital computer  42  is configured and arranged to communicate with the primary load balanced client interface server  10  through the utilization of client interface or web-interface software. As the name implies, a SLEA local digital computer  42  will usually be located on the premises of a SLEA. 
     Referring again to  FIG. 1 , it can be seen that the primary load balanced client interface server  10  is accessed by a system user via available connectivity  80  using either a local digital computer  40  or a mobile digital device  60 . As used herein a “mobile digital device”  60  includes devices such as a personal digital assistant (“PDA”), mobile or smartphone, mobile internet device (“MID”), Ultra-Mobile PC (“UMPC”), Internet computer or tablet, or other short-range wireless, cellular, satellite, radio, or network enabled devices. As the name implies, a mobile digital device  60  can be deployed in any setting for use by a system user, so long as there is available connectivity  80 . Referring again to  FIG. 2 , in a preferred embodiment, a SLEA who is accessing the primary load balanced client interface server  10  from a local digital computer  42  enters a subject packet into the DRMS  20  using available connectivity  80  and the subject packet application  32  loaded on the application server  30 , whereas a SLEA who is accessing the primary load balanced client interface server  10  from a SLEA mobile digital device  62 , enters subject packet data into the DRMS  20  using a mobile digital device subject packet input application  72  which is loaded on the SLEA mobile digital device  62  and connected to the CDMS  12  via available connectivity  80 . In another embodiment, the SLEA mobile digital device  62  is configured and arranged to use the web browsing functionality of the SLEA mobile digital device  62  and available connectivity  80  to access the subject packet input application  32  loaded directly on the application server  10  such that a SLEA is able to access the subject packet input application  32  by logging onto the primary load balanced client interface server  10 . In either of the preferred embodiments, the mobile digital device  62  will be configured and arranged to use applications allowing the mobile digital device  62  to communicate with the primary load balanced client interface server  10 , which will then pass information to the application server  32 —the brains of the system, an application server will facilitate communication with the database/record management system  20  to query or store data. The SLEA mobile digital devices  62  use mobile device operating systems such as Apple iOS, Google Android (Linux), Google Chrome OS, Hewlett-Packard webOS, RIM BlackBerry Tablet OS (ONX Neutrino), Intel/Nokia MeeGo (Linux), Nokia Maemo (Linux), Microsoft Windows CE for MID, Palm OS, BlackBerry OS, Symbian, RIM, iOS, iOS 4, Windows CE/Pocket PC OS, and Windows 7 among numerous other mobile device operating systems. The SLEA mobile digital device  62 , configured and arranged with a mobile operating system and available connectivity  80 , communicates with the primary load balanced client interface server  10  via client interface or web-interface software located on the primary load balanced client interface server  10 . Additionally, a SLEA mobile digital device  62  can be configured and arranged to connect to a SLEA local digital computer  42  via a docking station or wired connection (collectively “optional connectivity”)  90 . A SLEA mobile digital device  62  is configured and arranged to accept data input through multi-touch interface, keypad, keyboard, passive stylus or electronic pen, Bluetooth connected input device, USB connected device, dock connected device, 3.5 mm input mini-jack among other wireless and wired input devices. 
     A local digital computer  40  will be configured and arranged to include a central processing unit, running an available operating system compatible with the CDMS client interface or web-interface software, mouse, keyboard, monitor, among other optional hardware (collectively “local digital computer”)  40 . The first system user will query the CDMS  14  using the subject query application or program  34 ,  54 , or  74  through the use of multiple pieces of hardware connected, via wired or wireless connectivity, to a QLEA local digital computer  44  or QLEA mobile digital device  64  to include: (1) keyboard, (2) mouse, (3) passive stylus or digital pen. Alternatively, the first system user will query the CDMS  14  using the subject query application  34  through the use of an on-screen virtual keyboard. In one embodiment, the subject query application  34  is loaded directly on the CDMS  14  such that a first system user is able to access the subject query application  34  by logging onto the primary load balanced client interface server  10  from the QLEA local digital computer  44  which is configured and arranged and operatively connected to the CDMS  14  via available connectivity  80 . In other embodiments of the invention, the subject query program  54  is loaded onto a QLEA&#39;s local digital computer  44  and then, the subject query entered by the QLEA is transmitted from the QLEA&#39;s local digital computer  44  to the primary load balanced client interface server  10  by available connectivity  80 . The QLEAs will not always have the subject query application or program loaded on their local digital computer  44  or mobile digital device  64 ; therefore, the local digital computer  44  or mobile digital device  64  will communicate with the primary load balanced client interface server  10 , which will communicate with the application server  30  to obtain the subject query application  34 . The QLEA&#39;s local digital computer  44  is configured and arranged to communicate with the primary load balanced client interface server  10  through the utilization of client interface or web-interface software. As the name implies, a QLEA local digital computer  44  will usually be located on the premises of a QLEA. 
     Referring again to  FIG. 1 , it can be seen that the primary load balanced client interface server  10  is accessed by a system user via available connectivity  80  using either a local digital computer  40  or a mobile digital device  60 . As used herein a “mobile digital device”  60  includes devices such as a personal digital assistant (“PDA”), mobile or smartphone, mobile internet device (“MID”), Ultra-Mobile PC (“UMPC”), Internet computer or tablet, or other short-range wireless, cellular, satellite, radio, or network enabled devices. As the name implies, a mobile digital device  60  can be deployed in any setting for use by a system user, so long as, there is available connectivity  80 . Referring again to  FIG. 3 , in a preferred embodiment, a QLEA who is accessing the primary load balanced client interface server  10  from a local digital computer  44 , enters a subject query into the CDMS  14  using available connectivity  80  and the subject query application  34  loaded on the application server  30 , whereas a QLEA who is accessing the primary load balanced client interface server  10  from a QLEA mobile digital device  64  enters a subject query into the CDMS  14  using a mobile digital device subject query application  74  which is loaded on the QLEA mobile digital device  64  and connected to the CDMS  14  via available connectivity  80 . In another embodiment, the QLEA mobile digital device  64  is configured and arranged to use the web browsing functionality of the QLEA mobile digital device  64  and available connectivity  80  to access the subject query application  34  loaded directly on the application server  30  such that a QLEA is able to access the subject query application  34  by logging onto the primary load balanced client interface server  10 . The QLEA mobile digital devices  64  use mobile device operating systems such as Apple iOS, Google Android (Linux), Google Chrome OS, Hewlett-Packard webOS, RIM BlackBerry Tablet OS (ONX Neutrino), Intel/Nokia MeeGo (Linux), Nokia Maemo (Linux), Microsoft Windows CE for MID, Palm OS, BlackBerry OS, Symbian, RIM, iOS, iOS 4, Windows CE/Pocket PC OS, and Windows 7 or 8 among numerous other mobile device operating systems. The QLEA mobile digital device  64 , configured and arranged with a mobile operating system and available connectivity  80 , communicates with the primary load balanced client interface server  10  via client interface or web-interface software located on the primary server  10 . Additionally, a QLEA mobile digital device  64  can be configured and arranged to connect to a QLEA local digital computer  44  via a docking station or wired connection (collectively “optional connectivity”)  90 . A QLEA mobile digital device  64  can accept data input through multi-touch interface, keypad, keyboard, passive stylus or electronic pen, Bluetooth connected input device, USB connected device, dock connected device, 3.5 mm input mini-jack among other wireless and wired input devices. 
     Turning to  FIG. 4 , a local digital computer  48  will usually be configured and arranged to include a central processing unit, running an available operating system compatible with the CDMS client interface or web-interface software, mouse, keyboard, monitor, among other optional hardware (collectively “local digital computer”)  48 . The system user will create or receive investigative alerts using the investigative alert application  38  through the use of multiple pieces of hardware connected, via wired or wireless connectivity, to a QLEA or SLEA local digital computer  48  or QLEA or SLEA mobile digital device  68  to include: (1) keyboard, (2) mouse, (3) passive stylus or digital pen. Alternatively, the system user will input data into the investigative alert application  38  through the use of an on-screen virtual keyboard. In one embodiment, the investigative alert application  38  is loaded directly on the application server  30  such that a system user is able to access the investigative alert application  38  by logging onto the primary load balanced client interface server  10  from the QLEA or SLEA local digital computer  48  which is configured and arranged and operatively connected to the CDMS  18  via available connectivity  80 . In other embodiments of the invention, the investigative alert program  58  is loaded onto a QLEA&#39;s or SLEA&#39;s local digital computer  48  and then, the investigative alert entered by the system user is transmitted from the QLEA&#39;s or SLEA&#39;s local digital computer  48  to the primary load balanced client interface server  10  by available connectivity  80 . The QLEA&#39;s or SLEA&#39;s local digital computer  48  is configured and arranged to communicate with the primary load balanced client interface server  10  through the utilization of client interface or web-interface software. As the name implies, a QLEA or SLEA local digital computer  48  will usually be located on the premises of a QLEA or SLEA. 
     Referring again to  FIG. 1 , it can be seen that the primary load balanced client interface server  10  is accessed by a system user via available connectivity  80  using either a local digital computer  40  or a mobile digital device  60 . As used herein a “mobile digital device”  60  includes devices such as a personal digital assistant (“PDA”), mobile or smartphone, mobile internet device (“MID”), Ultra-Mobile PC (“UMPC”), Internet computer or tablet, or other short-range wireless, cellular, satellite, radio, or network enabled devices. As the name implies, a mobile digital device  60  can be deployed in any setting for use by a system user, so long as, there is available connectivity  80 . Referring again to  FIG. 4 , in a preferred embodiment, a QLEA or SLEA who is accessing the primary load balanced client interface server  10  from a local digital computer  48  enters an investigative alert into the CDMS  18  using available connectivity  80  and the investigative alert application  38  loaded on the application server  30 , whereas a QLEA or SLEA who is accessing the primary load balanced client interface server  10  from a QLEA or SLEA mobile digital device  68  enters an investigative alert in the CDMS  18  using a mobile digital device investigative alert application  78  which is loaded on the QLEA or SLEA mobile digital device  68  and connected to the CDMS  18  via available connectivity  80 . In another embodiment, the QLEA or SLEA mobile digital device  68  is configured and arranged to use the web browsing functionality of the QLEA or SLEA mobile digital device  68  and available connectivity  80  to access the investigative alert application  38  loaded directly on the application server  30  such that a QLEA or SLEA is able to access the investigative alert application  38  by logging onto the primary load balanced client interface server  10 . The QLEA or SLEA mobile digital devices  68  use mobile device operating systems such as Apple iOS, Google Android (Linux), Google Chrome OS, Hewlett-Packard webOS, RIM BlackBerry Tablet OS (ONX Neutrino), Intel/Nokia MeeGo (Linux), Nokia Maemo (Linux), Microsoft Windows CE for MID, Palm OS, BlackBerry OS, Symbian, RIM, iOS, iOS 4, Windows CE/Pocket PC OS, and Windows 7 or 8 among numerous other mobile device operating systems. The QLEA or SLEA mobile digital device  68 , configured and arranged with a mobile operating system and available connectivity  80 , communicates with the primary load balanced client interface server  10  via client interface or web-interface software located on the primary load balanced client interface server  10 . Additionally, a QLEA or SLEA mobile digital device  68  can be configured and arranged to connect to a QLEA or SLEA local digital computer  48  via a docking station or wired connection (collectively “optional connectivity”)  90 . A QLEA or SLEA mobile digital device  68  can accept data input through multi-touch interface, keypad, keyboard, passive stylus or electronic pen, Bluetooth connected input device, USB connected device, dock connected device, 3.5 mm input mini-jack among other wireless and wired input devices. 
     3. Exemplary Data Query and Retrieval Processes 
     In accordance with an embodiment of the invention, a flowchart illustrating exemplary subject query and retrieval processes carried out by the central data management system (“CDMS”)  14  via the NDD  24  (as shown in  FIG. 3 ) is detailed in  FIGS. 5-13  and  FIG. 36 . For the sake of clarity, the subject query and retrieval processes of the CDMS  14  will be described in relation to different scenarios that are possible when an exemplary QLEA submits a subject query via the NDD  24 , to the CDMS  14 . These scenarios include: (1) a QLEA subject query of the CDMS  14  resulting in a “Negative” response only; ( 2 A) a QLEA subject query of the CDMS  14  resulting in a “Confirmed” status classification confirmation response, seizure, and successful asset forfeiture; ( 2 B) a QLEA subject query of the CDMS  14  resulting in a “Suspected” status classification confirmation response, seizure, and successful asset forfeiture; ( 2 C) a QLEA subject query of the CDMS  14  resulting in a “Suspected” status classification confirmation response, seizure, and unsuccessful asset forfeiture; and (3) a QLEA subject query of the CDMS  14  resulting in a “Suspected” status classification confirmation response only. 
     In a first exemplary scenario, a QLEA subject query of the CDMS  14  results in a “Negative” response only. Referring to  FIG. 5 , the process commences at  100 , and in step  102 , a QLEA submits, via the NDD  24 , a subject query to the CDMS  14 . The QLEA submits the subject query to the CDMS  14  in step  102  in order to determine whether or not a particular subject matches a subject packet in the DRMS  20 . In step  104 , the CDMS  14  receives the subject query from the QLEA via the NDD  24 , and assigns it a unique transaction number. In a preferred embodiment of the invention, a unique transaction number is assigned by the CDMS  14  to each submitted subject query at step  104 ,  FIG. 5 . This unique transaction number is thereafter referenced by the CDMS  14  with regard to any communications relating to that specific QLEA subject query. 
     In subsequent step  106 , the CDMS  14  conducts a search of the DRMS  20  for a subject packet matching the QLEA subject query, and determines at decision block  108  whether a match exists between the subject and any one of the subject packets in the DRMS  20 . In this first exemplary scenario, the CDMS  14  determines that no match exists at decision block  108 , and thus proceeds to step  112 , where the CDMS  14  sends, via the NDD  24 , a “Negative” response to the QLEA, referencing the unique transaction number assigned by the CDMS  14  to the original QLEA subject query in step  104 . Thereafter, the process associated with the first exemplary scenario is concluded at step  114 . 
     In a second exemplary scenario, a QLEA subject query of the CDMS  14  submitted via the NDD  24  results in a “Confirmed” Confirmation Response, seizure, and successful asset forfeiture. Referring again to  FIG. 5 , the process commences at step  100 , and steps  102 ,  104 , and  106  are the same as described above for the first exemplary scenario. However, the second exemplary scenario differs from the first exemplary scenario starting at decision block  108 . In the second exemplary scenario, when the search is conducted of the DRMS  20 , the CDMS  14  determines at decision block  108  that a match exists between the subject of the QLEA subject query and at least one of the subject packets in the DRMS  20 . For the situation in which multiple matching subject packets are identified in a search of the DRMS  20 , the CDMS  14  will associate all identified matching subject packets, their SLEA(s), and their respective unique transaction number(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ), with the unique transaction number assigned by the CDMS  14  to the QLEA subject query in step  104 . Thereafter, at decision block  110 , the CDMS  14  determines the status classification of the matching subject packet(s) identified in the DRMS  20 . 
     Continuing this second exemplary scenario on  FIG. 5 , at step  110 , the matching subject packet is determined by the CDMS  14  to have a status classification of “Confirmed.” Referring now to step  118  in  FIG. 6 , the CDMS  14  sends a “Confirmed” Confirmation Response to the QLEA, via the NDD  24 , referencing the unique transaction number assigned by the CDMS  14  to the QLEA&#39;s subject query in step  104 ,  FIG. 5 . In a preferred embodiment of the invention, for subject queries resulting in a subject packet match, the Confirmation Response provides (1) the status classification, either “Confirmed” or “Suspected”, of the matched subject packet(s), (2) the name and contact information for the SLEA(s), (3) the unique transaction number(s) of the matched subject packet(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ), and (4) the unique transaction number of the QLEA&#39;s subject query assigned at  104 ,  FIG. 5 . 
     In one or more embodiments of the invention, each of the “Confirmed” and “Suspected” Confirmation Responses comprises concisely presented actionable intelligence retrieved from a database of subject packets about a positively identified subject. Notably and significantly different from responses obtained from reports-based database systems, the information contained in the response from the subject packet-based database system described herein contains only positively identified subjects, the identification of which are each established and confirmed by specific descriptive data. Consequently, the Confirmation Response received by a querying officer resulting from the query of the subject packet-based database contains a positive match(es) of a queried subject with matching descriptive data specific to that data defined in the initial query; not a list of possible key-word matches which require further examination by the querying officer to ascertain and confirm applicability to the subject queried. Furthermore, each subject packet contains a concise, specifically defined criminal nature associated with a given subject. This positive subject match, coupled with the specifically defined criminal nature of the subject, provides the querying officer with actionable intelligence; actionable intelligence which can be immediately utilized by that officer in support of a necessary or desired law enforcement action without the need to review a list of key-word matched searches of subjects or to read a report, subjectively review the information it contains, develop the needed actionable intelligence therefrom and then utilize it. The concise, specific nature of the information contained in the Confirmation Response significantly expedites the delivery and utilization of actionable intelligence in support of law enforcement actions. Additionally, this concise presentation enables the database to provide more usable actionable intelligence to the querying officer at one time, because the information that is provided is only what the officer needs to know about the criminal nature(s) of a queried subject; not all the extraneous detail and supporting information surrounding the origin of the information. Also important to note is the evidentiary value of the actionable intelligence contained in the Confirmation Response and how it directly supports a querying officer&#39;s subsequent decisions and actions. Specifically, the actionable intelligence provided in the Confirmation Response can be utilized to serve an evidentiary function in a given legal proceeding resulting from the law enforcement action in which the actionable intelligence was used, meaning a querying officer can directly cite the actionable intelligence in the Confirmation Response as part of the officer&#39;s articulable facts and circumstances supporting such law enforcement actions as investigative detentions, interrogations, arrests, searches, or seizures being prosecuted before a court of law. 
     Also, in one or more embodiments, the “Confirmed” and “Suspected” Confirmation Responses generated by the system described herein include the following attributes: (1) the absence of the need for the querying officer to review lists of key-word matches and read individual report(s), (2) the immediate delivery of actionable intelligence to the querying officer, (3) the evidentiary usefulness of the actionable intelligence in support of law enforcement actions and the resultant legal proceedings such as arrests, suppression hearings, seizure/asset forfeiture prosecutions, and criminal prosecutions, (4) the enhanced facilitation of seizures and asset forfeitures, and (5) the automation of the equitable sharing of asset forfeiture proceeds. 
     At step  122  in  FIG. 6 , the CDMS  14  sends via the NDD  24 , a “Confirmed Subject Queried” notification to the SLEA(s), notifying the SLEA(s) that a subject query matched a subject packet it submitted. Preferably, a “Confirmed Subject Queried” notification contains the following information: (1) the name of the subject queried, (2) the date of the subject query, (3) the QLEA&#39;s name and contact information, (4) the unique transaction numbers for both the QLEA subject query and the SLEA(s)′ matched subject packet(s), and (5) a subject queried response packet. The contact information of the QLEA is maintained in the CDMS  16  under the system user&#39;s account and is automatically attached to the “Confirmed Subject Queried” notification based on the unique transaction number. In step  126 , the QLEA receives, via the NDD  24 , a “Confirmed” confirmation response from the CDMS  14 . The CDMS “Confirmed” confirmation response, received by the QLEA at step  126 , requires the QLEA to confirm or deny that a seizure was made. In step  130 , the SLEA receives, via the NDD  24 , the “Confirmed Subject Queried” notification from the CDMS  14 . As part of the “Confirmed Subject Queried” notification received by the SLEA in step  130 ,  FIG. 6 , the process for the completion of the subject queried response packet begins at step  130  of  FIG. 36 , occurring contemporaneous to the investigation conducted by the QLEA in step  132 ,  FIG. 6 . At step  1104 ,  FIG. 36 , the SLEA is presented with a subject queried response packet. The subject queried response packet solicits the SLEA to provide immediate input/feedback to the QLEA concerning the subject query which resulted in the “Confirmed” confirmation response at step  118 ,  FIG. 6 . At step  1108 , if the SLEA decides to complete the subject queried response packet, the process continues at step  1116  where the SLEA completes the subject queried response packet using the available response options. The subject queried response packet is comprised of pre-populated information from the “Confirmed” confirmation response and offers the SLEA three response options from which to select, to include (1) “no response”, (2) a drop-down style menu of operational responses (e.g. “Contact SLEA immediately,” “Contact SLEA at earliest convenience,” “Obtain photograph of subject,” “Identify all associates,” “Newly developed investigative information available,” “Surveillance on-going,” “SLEA will contact QLEA by cellphone immediately,” “SLEA will contact QLEA at a later time,” etc., or (3) a customized text message. Upon completion of the subject queried response packet by the SLEA, the completed subject queried response packet is sent by the SLEA to the CDMS via the NDD. If at step  1108  the SLEA either selects the “no response” option or fails to submit a response within the CDMS&#39;s designated response time, the process continues at step  1112  where a “no response” response is assigned to the subject queried response packet and it is automatically sent to the CDMS via the NDD. At step  1120 , the CDMS receives the completed subject queried response packet or the “no response” response from the SLEA. At step  1124 , the CDMS sends the SLEA&#39;s completed subject queried response packet or the “no response” response to the QLEA via the NDD. At step  1128 , the QLEA receives the SLEA&#39;s completed subject queried response packet or the “no response” response from the CDMS. The process then continues at step  132 ,  FIG. 6 . It should be reiterated the process described above concerning the completion and transmission of the subject queried response packet by the SLEA and its delivery to the QLEA occurs contemporaneous to the investigation conducted by the QLEA at step  132 ,  FIG. 6 . 
     At step  132  of  FIG. 6 , as described below, utilizing the actionable intelligence provided by the CDMS  14  and any information provided by the SLEA via the subject queried response packet, the QLEA conducts its investigation to further develop reasonable suspicion, probable cause, or advance its investigation as it deems appropriate. The actionable intelligence provided by the CDMS  14 , namely the “Suspected” or “Confirmed” status classification of a subject, serves an evidentiary function similar to that of a reliable informant and thus, contributes to the developing of evidence sufficient in both quality and quantity for a legal finding of probable cause necessary to effectuate, substantiate, and successfully prosecute a seizure of assets and/or asset forfeiture. The “Confirmed” status classification of the subject can be used by a QLEA as evidentiary support or specific articulable facts, together with the other items of evidence or information the QLEA has in its possession, for developing reasonable suspicion and/or probable cause. At decision block  134 , it is determined whether or not the QLEA&#39;s investigation resulted in a seizure of assets. In this second exemplary scenario, a seizure of assets does result from the QLEA&#39;s investigation, and thus, the process is continued in  FIG. 8 , step  146 . 
     In a preferred embodiment of the invention, as stated above, when the QLEA receives a confirmation response for a subject with a “Confirmed” status classification at block  126 , the CDMS  14  requires the QLEA to submit an “Acknowledgement of Receipt” of the “Confirmed” Confirmation Response and “Seizure” Notice at step  146 . At step  146 , in the preferred embodiment, the acknowledgement of receipt of the “Confirmed” confirmation response and “Seizure” notice by the QLEA contains the following information: (1) whether or not a seizure was accomplished, (2) if a seizure was accomplished, the amount of the seizure or the item(s) seized, (3) the QLEA&#39;s report number(s) documenting the results of its investigation, (4) the unique transaction number of the QLEA subject query (this field is pre-populated by the CDMS  14 ), (5) the unique transaction number for the SLEA subject packet(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ) (this field is pre-populated by the CDMS  14 ), and (6) when a seizure is made, the name and contact information of the prosecutor&#39;s office in the seizing jurisdiction (selected from a pre-populated “drop-down” menu), hereafter referred to as the Designated Prosecutor&#39;s Office (“DPO”). A Confirmation Response remains in “open” status in the CDMS  14  until the QLEA submits the acknowledgment of receipt of the “Confirmed” confirmation response and “Seizure” notice to the CDMS  14  via the NDD  24 . 
     Continuing with step  146  in  FIG. 8 , the QLEA sends the CDMS  14 , via the NDD  24 , an acknowledgement of receipt of “Confirmed” confirmation response and “Seizure” notice indicating that a seizure was made. Because the QLEA&#39;s investigation resulted in a seizure in this exemplary scenario, the QLEA&#39;s acknowledgement of receipt of the “Confirmed” confirmation response and “Seizure” notice would contain the following information: (1) a seizure was accomplished, (2) the amount of the seizure and/or item(s) seized, (3) the QLEA&#39;s report number(s) documenting the results of its investigation, (4) the unique transaction number for the QLEA&#39;s subject query, (5) the unique transaction number for the SLEA(s)&#39;s subject packet(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ), and (6) the name and contact information of the DPO. In step  148 , the CDMS  14  receives, via the NDD  24 , the QLEA&#39;s acknowledgment of receipt of the “Confirmed” confirmation response and “Seizure” notice indicating that a seizure was made. Then, in step  150 , the CDMS  14  sends, via the NDD  24 , a “Seizure” notice to the SLEA(s) and the DPO. In a preferred embodiment, the “Seizure” notice contains the following information: (1) a seizure confirmation, (2) the amount of the seizure and/or the item(s) seized, (3) the unique transaction number assigned in block  104  to the QLEA subject query, (4) the QLEA&#39;s report number(s) documenting the results of its investigation, (5) the QLEA&#39;s name and contact information, (6) the contact information for the SLEA(s), (7) the contact information for the DPO, and (8) the unique transaction number(s) assigned to the SLEA(s)&#39;s matched subject packet(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ). The contact information for the QLEA, SLEA(s), and DPO(s) is maintained in the DRMS  20  under each user&#39;s personal or designated account and is automatically attached based on the unique transaction numbers assigned to the subject query and subject packet(s). The CDMS  14  sends, via the NDD  24  the “Seizure” notice in step  150  which is received by the SLEA(s) and DPO in step  152 . At step  154 , the SLEA(s) and DPO send the CDMS  14 , via the NDD  24 , acknowledgement of receipt of “Seizure” notices. After the CDMS  14  receives the SLEA(s)&#39;s and DPO&#39;s acknowledgement of receipt of “Seizure” notice at step  156 , the asset forfeiture process commences at step  158 , outside the CDMS  14 . 
     In a first variation of the second exemplary scenario, the matching subject packet is determined at step  110 ,  FIG. 5  to have a status classification of “Suspected.” Referring now to step  116 ,  FIG. 6 , the CDMS  14  sends, via the NDD  24 , a “Suspected” confirmation response to the QLEA identifying the subject&#39;s status classification as “Suspected”. In a preferred embodiment of the invention, the “Suspected” confirmation response for this scenario contains the following information: (1) the status classification of “Suspected” of the matched subject packet(s), (2) the name and contact information for the SLEA(s), (3) the SLEA(s)&#39;s unique transaction number(s) of the matched subject packet(s) (assigned by the CDMS  12  at step  304 ,  FIG. 14 ), and (4) the unique transaction number of the QLEA&#39;s subject query assigned at step  104 ,  FIG. 5 . The CDMS  14  also sends a “Suspected Subject Queried” notification, via the NDD  24 , at step  120 , to the SLEA(s), notifying the SLEA(s) of the QLEA&#39;s subject query. Preferably, the “Suspected Subject Queried” notification contains the following information: (1) the name of the subject queried, (2) the date of the subject query, (3) the QLEA&#39;s name and contact information, (4) the unique transaction number for the QLEA&#39;s subject query, (5) the unique transaction number(s) assigned to the SLEA&#39;s original subject packet input (assigned by the CDMS  12  at step  304 ,  FIG. 14 ), and (6) a subject queried response packet. The contact information of the QLEA and SLEA(s) is maintained in the DRMS  20  under the user&#39;s account and is automatically attached to the “Suspected Subject Queried” notification based on the unique transaction number. In step  124 , the QLEA receives the “Suspected” confirmation response from the CDMS  14 , via the NDD  24 , identifying the status classification of the subject as “Suspected.” 
     In step  128 , the SLEA receives the “Suspected Subject Queried” notification from the CDMS  14 , via the NDD  24 . As part of the “Suspected Subject Queried” notification received by the SLEA in step  128 ,  FIG. 6 , the process for the completion of the subject queried response packet begins at step  128  of  FIG. 36 , occurring contemporaneous to the investigation conducted by the QLEA in step  132 ,  FIG. 6 . At step  1104 ,  FIG. 36 , the SLEA is presented with a subject queried response packet. The subject queried response packet solicits the SLEA to provide immediate input/feedback to the QLEA concerning the subject query which resulted in the “Suspected” confirmation response at step  116 ,  FIG. 6 . At step  1108 , if the SLEA decides to complete the subject queried response packet, the process continues at step  1116  where the SLEA completes the subject queried response packet using the available response options. The subject queried response packet is comprised of pre-populated information from the “Suspected” confirmation response and offers the SLEA three response options from which to select, to include (1) “no response”, (2) a drop-down style menu of operational responses (e.g. “Contact SLEA immediately,” “Contact SLEA at earliest convenience,” “Obtain photograph of subject,” “Identify all associates,” “Newly developed investigative information available,” “Surveillance on-going,” “SLEA will contact QLEA by cellphone immediately,” “SLEA will contact QLEA at a later time,” etc., or (3) a customized text message. Upon completion of the subject queried response packet by the SLEA, the completed subject queried response packet is sent by the SLEA to the CDMS via the NDD. If at step  1108  the SLEA either selects the “no response” option or fails to submit a response within the CDMS&#39;s designated response time, the process continues at step  1112  where a “no response” response is assigned to the subject queried response packet and it is automatically sent to the CDMS via the NDD. At step  1120 , the CDMS receives the completed subject queried response packet or the “no response” response from the SLEA. At step  1124 , the CDMS sends the SLEA&#39;s completed subject queried response packet or the “no response” response to the QLEA via the NDD. At step  1128 , the QLEA receives the SLEA&#39;s completed subject queried response packet or the “no response” response from the CDMS. The process then continues at step  132 ,  FIG. 6 . It should be reiterated the process described above concerning the completion and transmission of the subject queried response packet by the SLEA and its delivery to the QLEA occurs contemporaneous to the investigation conducted by the QLEA at step  132 ,  FIG. 6 . 
     Next, at step  132  of  FIG. 6 , the QLEA conducts its investigation utilizing the actionable intelligence provided by the CDMS  14  and any information provided by the SLEA via the subject queried response packet, and a seizure results at decision block  134 . As in the case of the second exemplary scenario discussed above involving a “Confirmed” confirmation response, a seizure, and a successful asset forfeiture, this first variation of the second exemplary scenario involves a “Suspected” confirmation response, a seizure, and a successful asset forfeiture. Consequently, at decision block  134 , when it is determined that the QLEA&#39;s investigation resulted in a seizure, in this first variation of the second exemplary scenario, the process is continued in  FIG. 8 , step  146 , and thereafter progresses the same as it had for the original version of the second exemplary scenario through steps  148 ,  150 ,  152 ,  154 , and  156 . 
     As it did in the original version of the second exemplary scenario above, after the CDMS  14  receives the SLEA(s)&#39;s and DPO&#39;s acknowledgement of receipt of “Seizure” notices via the NDD  24  at step  156 , the asset forfeiture process commences at step  158 , outside the CDMS  14 . Hereafter, the process steps for both the second exemplary scenario (“Confirmed” confirmation response, seizure, and successful asset forfeiture) and the first variation of the second exemplary scenario (“Suspected” confirmation response, seizure, and successful asset forfeiture) are the same. The first step in the asset forfeiture process conducted outside the CDMS occurs when the QLEA provides a copy of its agency report(s) documenting the results of its investigation and the resultant seizure to the DPO who will be handling the asset forfeiture process. The QLEA&#39;s agency report(s) will reference the unique transaction number associated with the subject query that resulted in the seizure. Next, the DPO initiates asset forfeiture proceedings and issues a discovery request to the SLEA(s) for its respective agency report(s) identified in the seizure notice(s) issued by the CDMS  14  in step  150 , upon which the “Confirmed” or “Suspected” status classification of the matched subject packet in the DRMS  20  was based. After the SLEA(s) provides the DPO with the requested report(s) in response to the discovery request, the DPO continues the asset forfeiture process. Following the conclusion of the asset forfeiture process, at step  160 ,  FIG. 9 , the DPO sends a “Status of Asset Forfeiture” notification via the NDD  24  to the CDMS  14 . In a preferred embodiment, the “Status of Asset Forfeiture” notification contains the following information: (1) the asset forfeiture status as successful or not successful, (2) the total amount or value of the asset forfeiture, and (3) the unique transaction number assigned to the QLEA&#39;s subject query at step  104 ,  FIG. 5 , that resulted in the seizure. Referring again to  FIG. 9 , the CDMS  14  receives the “Status of Asset Forfeiture” notification from the DPO via the NDD  24  at step  162 . The process next continues at step  164 ,  FIG. 9 , based on the status of the asset forfeiture, that being either successful or unsuccessful, as identified by the DPO in its Status of Asset Forfeiture notification in step  162 . 
     In a second variation of the second exemplary scenario, the asset forfeiture is unsuccessful at decision block  164 ,  FIG. 9 . Referring now to step  190 ,  FIG. 12 , the CDMS  14  sends via the NDD  24  a Final Asset Forfeiture Notification and Disbursement Notice to the QLEA, SLEA(s), and DPO. The Final Asset Forfeiture notification and Disbursement notice notifies the QLEA, SLEA(s), and confirms with the DPO that the asset forfeiture was unsuccessful. In a preferred embodiment of the invention, the Final Asset Forfeiture Notification and Disbursement Notice for an unsuccessful asset forfeiture would include the following information: (1) asset forfeiture was unsuccessful, (2) no asset forfeiture proceeds are pending disbursement, and (3) the unique transaction number of the subject query which resulted in the seizure. At step  192 , the QLEA, SLEA(S), and DPO receive via the NDD  24  the Final Asset Forfeiture Notification and Disbursement Notice from the CDMS  14 . Thereafter, in step  194 , the QLEA, SLEA(s), and DPO send via the NDD  24  an Acknowledgement of Final Asset Forfeiture and Disbursement Notice to the CDMS  14 . After the CDMS  14  receives via the NDD  24  the Acknowledgement of Final Asset Forfeiture and Disbursement Notices from the QLEA, SLEA(s), and DPO, at step  196 , the process for this second variation of the second exemplary scenario involving an unsuccessful asset forfeiture concludes at step  198 . 
     Referring again to  FIG. 9 , if, at decision block  164 , the asset forfeiture was successful, the process continues at step  166 ,  FIG. 9 , where the CDMS  14  determines if the DPO is an automated participant or a manual participant in the asset forfeiture proceeds disbursement process. If the DPO is determined to be an automated participant at decision block  166 ,  FIG. 9 , the process continues in  FIG. 10 , step  168 , where the CDMS  14  sends a “Final Asset Forfeiture” notification and “Disbursement” notice via the NDD  24  to the QLEA, SLEA(s), and DPO. In a preferred embodiment of the invention, when an asset forfeiture is successful the “Final Asset Forfeiture” notification and “Disbursement” notice notifies the QLEA, SLEA(s), and DPO of the details of the pending asset forfeiture proceeds disbursement transaction and includes the following information: (1) total disbursement amounts for each agency involved in the seizure/asset forfeiture process (disbursement percentages are determined in accordance with those established in each agency&#39;s CDMS user agreement/contract), (2) the bank routing information and AFF account number for each recipient agency, and (3) the unique transaction number of the subject query which resulted in the seizure. At step  170 , the QLEA, SLEA(s), and DPO receive the “Final Asset Forfeiture” notification and “Disbursement” notice from the CDMS  14  via the NDD  24 . At step  172 , the QLEA, SLEA(s), and DPO send via the NDD  24  acknowledgement of “Final Asset Forfeiture” notifications and “Disbursement” notices to the CDMS  14 . The acknowledgement of “Final Asset Forfeiture” notification and “Disbursement” notice serves to provide the CDMS  14  with the QLEA&#39;s, SLEA(s)&#39;s, and DPO&#39;s concurrence with the disbursement amounts detailed in the “Final Asset Forfeiture” notification and “Disbursement” notice sent by the CDMS  14  in step  168 . After receiving the acknowledgement of “Final Asset Forfeiture” notifications and “Disbursement” notice from the QLEA, SLEA(s), and DPO at step  174 , the CDMS  14  next schedules and facilitates the disbursement of the asset forfeiture proceeds, at step  176 , to the QLEA&#39;s, SLEA&#39;s, and DPO&#39;s asset forfeiture fund (“AFF”) bank accounts, transferring those proceeds via electronic funds transfer (“EFT”) at step  178 ,  FIG. 11 . Upon completion of the EFT, at step  180 , the CDMS  14  sends via the NDD  24  a “Disbursement Completed” notification to the QLEA, SLEA(s), and DPO. The QLEA, SLEA(s), and DPO receive via the NDD  24  the “Disbursement Completed” notification from the CDMS  14  in step  182  and, thereafter, send via the NDD  24  the acknowledgement of “Disbursement Completed” notifications, confirming their receipt of the EFT, to the CDMS  14  at step  184 . At step  186 , the CDMS  14  receives via the NDD  24  the acknowledgement of “Disbursement Completed” notification from the QLEA, SLEA(s), and DPO. 
     If, at step  166 ,  FIG. 9 , the DPO was determined by the CDMS  14  to be a manual participant in the asset forfeiture proceeds disbursement process, the process continues in  FIG. 13 , at step  200 , where the CDMS  14  sends a “Final Asset Forfeiture Notification and Disbursement Notice” via the NDD  24  to the QLEA, SLEA(s), and DPO. In a preferred embodiment of the invention, the “Final Asset Forfeiture Notification and Disbursement Notice” notifies the QLEA, SLEA(s), and DPO of the details of the pending asset forfeiture proceeds disbursement transaction and directs the DPO to disburse the proceeds of the asset forfeiture from its AFF account to the recipient agencies, and it includes the following information: (1) total disbursement amounts for each agency involved in the seizure/asset forfeiture process (disbursement percentages are determined in accordance with those established in each agency&#39;s CDMS user agreement/contract), (2) the bank routing information and AFF account number for each recipient agency, and (3) the unique transaction number of the subject query which resulted in the seizure. At step  202 , the QLEA, SLEA(s), and DPO receive via the NDD  24  the “Final Asset Forfeiture Notification and Disbursement Notice” from the CDMS  14 . At step  204 , the DPO transfers via EFT the disbursements detailed in the “Final Asset Forfeiture Notification and Disbursement Notice” to the QLEA and SLEA(s). After the EFT transfer of the asset forfeiture proceeds to the QLEA and SLEA(s) is completed at step  204 , the DPO sends via the NDD  24  a Confirmation of “Disbursement” notice to the CDMS  14 . The CDMS  14  receives via the NDD  24  the Confirmation of “Disbursement” notice from the DPO at step  208  and subsequently sends a “Disbursement Completed” notice via the NDD  24  to the QLEA, SLEA(s), and DPO at step  210 . The QLEA, SLEA(s), and DPO receive the “Disbursement Completed” notice from the CDMS  14  at step  212  and at step  214 , send via the NDD  24  an acknowledgement of “Disbursement Completed” notice to the CDMS  14 . After the CDMS  14  receives via the NDD  24  the acknowledgement of “Disbursement Completed” notice from the QLEA, SLEA(s), and DPO at step  186 ,  FIG. 11 , for an automated participant or at step  216 ,  FIG. 13  for a manual participant, the process associated with second exemplary scenario is concluded at step  188 ,  FIG. 11 , or step  218 ,  FIG. 13 , respectively. 
     In a third exemplary scenario, a QLEA subject query of the CDMS  14  results in a “Suspected” classification status confirmation response only. Referring to  FIGS. 3 and 5 , the process commences at step  100 , and steps  102 ,  104 ,  106 , and the outcome of decision block  108  are the same as that described above for the second exemplary scenario. However, the third exemplary scenario differs from the second exemplary scenario starting at decision block  110 . In the third exemplary scenario, unlike the second exemplary scenario, at step  110 , the status classification of the subject is “Suspected”. Thereafter, steps  116 ,  120 ,  124 ,  128 , and  132 ,  FIG. 6 , and steps  1104 ,  1108 ,  1112 ,  1116 ,  1120 ,  1124 , and  1128 ,  FIG. 36 , are the same as the first variation of the second exemplary scenario above; however, at decision block  134 ,  FIG. 6 , no seizure is made. Consequently, continuing on  FIG. 7 , step  138 , the QLEA sends via the NDD  24  the CDMS  14  an acknowledgment of receipt of the “Suspected” confirmation response and “Non-Seizure” notice. Because the QLEA&#39;s investigation did not result in a seizure in this third exemplary scenario, the QLEA&#39;s acknowledgement of receipt of the “Suspected” confirmation response and “Non-Seizure” notice would provide the following information: (1) no seizure was accomplished, (2) the QLEA&#39;s report number(s) documenting the results of its investigation, and (3) the unique transaction number of the QLEA&#39;s subject query. In step  140 , the CDMS  14  receives via the NDD  24  the QLEA&#39;s acknowledgement of receipt of “Suspected” confirmation response and “Non-Seizure” notice indicating a seizure was not made. Then, in step  142 , the CDMS  14  sends via the NDD  24  a “Non-Seizure” notice to the SLEA(s). In a preferred embodiment of the invention, the “Non-Seizure” notice includes the following information: (1) no seizure was accomplished, (2) the QLEA&#39;s report number(s) documenting the results of its investigation, (3) the unique transaction number assigned to the QLEA&#39;s subject query, and (4) the unique transaction number assigned to the SLEA(s)&#39;s original subject packet input. Thereafter, the process associated with the third exemplary scenario is concluded at step  144 . 
     In  FIGS. 18-26 , which comprises flowcharts for an exemplary terrorist subject query and retrieval processes carried out by the system of  FIG. 3 , it is to be understood that steps  400 - 518  of  FIGS. 18-26  are analogous to steps  100 - 218  described above, except that they are specific to the terrorist application of the system. For example, steps  100 ,  102 , and  104  of  FIG. 5  are analogous to steps  400 ,  402 , and  404  of  FIG. 18 , etc. 
     4. Exemplary Subject Packet Input Processes 
     In accordance with an embodiment of the invention, a flowchart illustrating exemplary subject packet input processes for entering data into the central data management system (“CDMS”)  12  is set forth in  FIG. 2  and  FIGS. 14-17 . In a preferred embodiment of the invention, these processes are performed by using the CMDS  12  Subject Packet Input Application  32 , Local Digital Computer Subject Packet Input Program  52 , Mobile Digital Device Subject Packet Input Application  72 , and Data Records Management System (“DRMS”)  20 , which enable a SLEA to input subject data into the DRMS  20 . Referring to  FIG. 14 , the process commences at step  300 , and in step  302 , a SLEA accesses the CDMS  12  via the NDD  22 . Then, in step  304 , the SLEA selects the “Create Subject Packet” option from the CDMS  12  and the CDMS  12  assigns a unique transaction number to the transaction. In subsequent step  306 , the CDMS  12  accesses the CDMS  12  Subject Packet Input Application  32  and presents the SLEA with the “Subject Packet” input screen. At step  308 , the SLEA completes the entering of all required information into the Subject Packet Input Screen. 
     In a preferred embodiment of the invention, the Subject Packet Input Screen displays for the SLEA a selection of data fields used to describe the subject. The initial subject field selection is the category of the subject, such as a “Person”, “Currency”, “Vehicle”, “Aircraft”, “Marine Vessel”, “Address”, or “Other” (for a subject that is not properly categorized by any of the listed standard categories). After a subject category is selected, the appropriate descriptive data fields for the selected category are displayed. For example, for the subject category “Person”, the Subject Packet Input Application  32  displays descriptive data fields for first name, middle name, last name, alias(es), sex, date of birth, social security number (“SSN”), driver&#39;s license number and state of issuance, state identification card and state of issuance, Integrated Automated Fingerprint Identification System (“IAFIS”) number, etc. A special descriptive data field is included for persons titled “Health Warnings.” The Health Warnings field is used to include legally obtained medical information (such as the medical files of a formerly arrested or incarcerated subject) concerning a subject&#39;s medical condition which would present an immediate health hazard to law enforcement officers, such as Hepatitis C, AIDS, Tuberculosis, etc. For the subject category “Vehicle,” the Subject Packet Input Application  32  displays fields for make, model, year, license plate number and state of issuance, vehicle identification number (“VIN”), color, and other descriptors, etc. For the subject category “Address,” the Subject Packet Input Application  32  displays fields for numerical address, street name, unit or apartment number, city, state, zip code, and other descriptors, etc. A photograph of any subject can be submitted as descriptive data. The mandatory minimum number of descriptive data fields to be completed for each subject category will be established by the CDMS administrator. In a preferred embodiment, a minimum number of descriptive data fields are required to be completed for a selected subject category before the Subject Packet Input Application  32  will allow the SLEA user to proceed to the next step in the process. After the SLEA enters the available information into the descriptive data fields, the Subject Packet Input Application  32  displays the subject field selections for the status classification of the subject packet. In a preferred embodiment, status classifications are either “Confirmed” or “Suspected.” The status classification of a subject packet submitted for inclusion in the CDMS  12  is selected by the SLEA and is based on the SLEA&#39;s application of the stipulative definition of “Confirmed” or “Suspected” characterizing the quantity and quality of information it possesses concerning a respective subject. A “Confirmed” status classification denotes a higher standard of evidentiary support than a “Suspected” status classification. After the SLEA enters all of the descriptive data for its subject, the Subject Packet Input Application  32  displays all the information entered for the subject packet created by the SLEA. 
     In step  310 , the SLEA reviews the information that was entered into the Subject Packet input screen and decides whether it is satisfied with the Subject Packet Input at decision block  312 . If at decision block  312  the SLEA is not satisfied with the descriptive data entered into the Subject Packet Input Screen, it can select the “Edit Subject Packet” option in step  314 , where the process returns the SLEA to step  306  to make any desired changes to the descriptive data. Conversely, if the SLEA is satisfied at step  312  with the descriptive data entered into the Subject Packet Input Screen, the SLEA can select the “Submit Subject Packet” option at step  316 ,  FIG. 15 , to submit the pending subject packet to the CDMS  12 . When the “Submit Subject Packet” option is selected by the SLEA, the CDMS Subject Packet Input Application  32  receives the pending subject packet at step  318  and searches the pending subject packet for error(s). If one or more errors are identified by the CDMS  12  in the pending subject packet at decision block  320 , the CDMS  12  denies the pending subject packet and sends via the NDD  22 , a “Subject Packet Declination” notification to the SLEA at step  322  which identifies the error(s) resulting in the declination and references the unique transaction number assigned to the pending subject packet at step  304 ,  FIG. 14 . At step  326 , the CDMS  12  holds the pending subject packet in the SLEA&#39;s account until the SLEA corrects the identified error(s) or the pending subject packet is deleted by the SLEA. In decision block  330 ,  FIG. 16 , the SLEA must decide whether to delete the pending subject packet or to correct the errors in the pending subject packet. If the SLEA elects to “Delete” the pending subject packet, the CDMS  12  deletes the pending subject packet from the DRMS  20  at step  340  and the subject packet input process is concluded at step  342 ,  FIG. 16 . However, if the SLEA, at decision block  330 ,  FIG. 16 , selects the “EDIT Subject Packet” option, the process returns to step  306 ,  FIG. 14 , where the SLEA is again presented with the Subject Packet Input screen where it corrects the identified errors in the pending subject packet. The process then proceeds as before through steps  308 ,  310 ,  312 , and  316  in  FIGS. 14 and 15 . Then, at step  318 , the CDMS  12  receives the corrected pending subject packet and again searches for any errors. At step  320 , if the CDMS  12  still finds an error in the pending subject packet, then the process repeats beginning at step  322 , wherein the CDMS  12  sends another “Subject Packet Declination” notification to the SLEA identifying the error(s) in the pending subject packet. This edit, review, and submit process continues until the pending subject packet is either submitted without errors or the SLEA deletes the pending subject packet. 
     However, if at decision block  320  the CDMS  12  finds no errors in the pending subject packet, the process continues at step  324  where the CDMS  12  searches the DRMS  20  for any subject packets matching the pending subject packet. At decision block  328 , the CDMS  12  determines if there is a match between the pending subject packet and one of the existing subject packets in the DRMS  20 . If no match is identified in decision block  328 , the CDMS  12  places the pending subject packet into the DRMS  20  as a newly submitted subject packet at step  334 ,  FIG. 17 . Conversely, if a match with an existing subject packet(s) is identified at decision block  328 , the CDMS  12  will create a link within the DRMS  20  between the matched subject packet(s) and the pending subject packet at step  332  and then the CDMS  12  places the pending subject packet in the DRMS  20  as a newly submitted subject packet. 
     In step  336 , the CDMS  12  sends via the NDD  22  a “Subject Packet Confirmation” notification to the SLEA and any other SLEA(s) who have subject packets matching the newly submitted subject packet, thereby confirming the acceptance of the new subject packet by the CDMS  12  in the DRMS  20 . In a preferred embodiment of the invention, a “Subject Packet Confirmation” notification includes the following information: (1) the subject packet is accepted, (2) the status classification of the new subject packet, (3) date of acceptance, (4) the name(s) and contact information for any SLEA(s) who has a subject packet(s) linked in the DRMS  20  with the newly submitted subject packet, (5) the unique transaction number(s) of the matching subject packet(s), (6) the status classification of any matched subject packets, and (7) the unique transaction number of the newly submitted subject packet. Thereafter, the processes associated with the exemplary subject packet input processes are concluded at step  338 . 
     5. Exemplary Data Query and Retrieval for Paper Currency Processes 
     In accordance with an embodiment of the invention, a flowchart illustrating exemplary query and retrieval processes for paper currency carried out by the central data management system (“CDMS”)  14  via the NDD  24  is set forth in  FIG. 32-33  and  FIG. 36 . For the sake of clarity, the subject query and retrieval process for paper currency of the CDMS  14  will be described in relation to two different scenarios that are possible when an exemplary QLEA submits a subject query for paper currency via the NDD  24  to the CDMS  14 . These scenarios include (1) a QLEA subject query for paper currency of the CDMS  14  resulting in a “Negative” response only and (2) a QLEA subject query for paper currency of the CDMS  14  resulting in a “Confirmed” status classification confirmation response. 
     In a first exemplary scenario, a QLEA subject query for paper currency of the CDMS  14  results in a “Negative” response only. Referring to  FIG. 32 , the process commences at step  600 , and at step  602 , a QLEA submits a subject query for paper currency to the CDMS  14  via the NDD  24 . The QLEA submits the subject query for paper currency to the CDMS  14  in step  602  in order to determine whether or not a particular subject—paper currency serial number(s)—matches a subject packet in the DRMS  20 . The CDMS  14  receives the subject query for paper currency from the QLEA via the NDD  24  at step  604  and assigns it a unique transaction number. In a preferred embodiment of the invention, a unique transaction number is assigned by the CDMS  14  to each submitted subject query for paper currency at step  604 . This unique transaction number is thereafter referenced by the CDMS  14  with regard to any communications relating to that specific QLEA subject query for paper currency. 
     In subsequent step  606 , the CDMS  14  conducts a search of the DRMS  20  for a subject packet with serial numbers that match those of the QLEA subject query for paper currency and determines at decision block  608  whether a match exists between that subject and any one of the subject packets in the DRMS  20 . In this first exemplary scenario, the CDMS  14  determines that no match exists at decision block  608  and thus, proceeds to step  612 , where the CDMS  14  sends via the NDD  24  a “Negative” response to the QLEA referencing the unique transaction number assigned by the CDMS  14  to the original QLEA subject query for paper currency in step  604 . At step  614 , the QLEA receives via the NDD  24  the Negative response. Thereafter, the processes associated with the first exemplary scenario are concluded at step  616 . 
     In a second exemplary scenario, a QLEA subject query for paper currency of the CDMS  14  submitted via the NDD  24  results in a “Confirmed” status classification confirmation response. Referring again to  FIG. 32 , the process commences at step  600 , and steps  602 ,  604 , and  606  are the same as described above for the first exemplary scenario. However, the second exemplary scenario differs from the first exemplary scenario starting at decision block  608 . In the second exemplary scenario, when the search is conducted of the DRMS  20 , the CDMS  14  determines at decision block  608  that a match exists between one or more of the serial numbers in the subject query for paper currency of the QLEA and those in a subject packet in the DRMS  20 . (i.e., a response of “yes” at decision block  608 ). For a situation in which multiple matching subject packets are identified in a search of the DRMS  20 , the CDMS  14  will associate all identified matching subject packets, their SLEA(s) and their respective unique transaction number(s) (assigned by the CDMS  12  at step  1004 ,  FIG. 35 ) with the unique transaction number assigned by the CDMS  14  to the QLEA subject query for paper currency in step  604 ,  FIG. 32 . Thereafter, at decision block  610 , the CDMS  14  determines the status classification of the matching subject packet(s) for paper currency identified in the DRMS  20 . 
     Continuing this second exemplary scenario in  FIG. 33  at step  610 , the matching subject packet for paper currency is determined to have a status classification of “Confirmed”. Referring now to step  616 , the CDMS  14  sends a “Confirmed” confirmation response via the NDD  24  to the QLEA referencing the unique transaction number assigned by the CDMS  14  to the QLEA&#39;s subject query for paper currency in step  604 . In a preferred embodiment of the invention, for a subject query for paper currency resulting in a subject packet match, the “Confirmed” confirmation response for paper currency provides (1) the unique transaction number assigned to the QLEA&#39;s subject query for paper currency at step  604 ; (2) the status classification (e.g. Confirmed—Drug Buy Funds), (3) the total number of serial number matches per matching subject packet, (4) the unique transaction number(s) for the matching subject packet(s), and (5) the name and contact information for the SLEA(s) for each of the matching subject packet(s). At step  622 , the CDMS  14  sends a “Confirmed Subject Queried” notification to the SLEA(s) via the NDD. Preferably, a “Confirmed Subject Queried” notification for paper currency contains the following information: (1) the subject queried, (2) the date of the subject query, (3) the number of serial number matches per matching subject packet, (4) the unique transaction number(s) for the SLEA(s) matched subject packet(s), (5) the name and contact information for the QLEA, (6) the unique transaction number assigned to the QLEA&#39;s subject query for paper currency assigned in step  604 , and (7) a subject queried response packet. The contact information of the QLEA is maintained in the CDMS  14  under the system user&#39;s account and is automatically attached to the “Confirmed Subject Queried” notification based on the unique transaction number. In step  626 , the QLEA receives via the NDD  24  the “Confirmed” confirmation response from the CDMS  14 . In step  630 , the SLEA(s) receives via the NDD  24  the “Confirmed Subject Queried” notification from the CDMS  14 . As part of the “Confirmed Subject Queried” notification received by the SLEA in step  630  of  FIG. 33 , the process for the completion of the subject queried response packet begins at step  630 ,  FIG. 36 , occurring contemporaneous to the investigation conducted by the QLEA in step  132 ,  FIG. 6 . At step  1104 ,  FIG. 36 , the SLEA is presented with a subject queried response packet. The subject queried response packet solicits the SLEA to provide immediate input/feedback to the QLEA concerning the subject query which resulted in the “Confirmed” confirmation response at step  616 ,  FIG. 33 . At step  1108 , if the SLEA decides to complete the subject queried response packet, the process continues at step  1116  where the SLEA completes the subject queried response packet using the available response options. The subject queried response packet is comprised of pre-populated information from the “Confirmed” confirmation response and offers the SLEA three response options from which to select, to include (1) “no response”, (2) a drop-down style menu of operational responses (e.g. “Contact SLEA immediately,” “Contact SLEA at earliest convenience,” “Obtain photograph of subject,” “Identify all associates,” “Newly developed investigative information available,” “Surveillance on-going,” “SLEA will contact QLEA by cellphone immediately,” “SLEA will contact QLEA at a later time,” etc.), or (3) a customized text message. Upon completion of the subject queried response packet by the SLEA, the completed subject queried response packet is sent by the SLEA to the CDMS via the NDD. If at step  1108  the SLEA either selects the “no response” option or fails to submit a response within the CDMS&#39;s designated response time, the process continues at step  1112  where a “no response” response is assigned to the subject queried response packet and it is automatically sent to the CDMS via the NDD. At step  1120 , the CDMS receives the completed subject queried response packet or the “no response” response from the SLEA. At step  1124 , the CDMS sends the SLEA&#39;s completed subject queried response packet or the “no response” response to the QLEA via the NDD. At step  1128 , the QLEA receives the SLEA&#39;s completed subject queried response packet or the “no response” response from the CDMS. The process then continues at step  132 ,  FIG. 6 . It should be reiterated the process described above concerning the completion and transmission of the subject queried response packet by the SLEA and its delivery to the QLEA occurs contemporaneous to the investigation conducted by the QLEA at step  132 ,  FIG. 6 . 
     The CDMS  14  “Confirmed” confirmation response received by the QLEA at step  626  (see  FIG. 33 ) requires the QLEA to confirm or deny that a seizure was made. This second exemplary scenario continues at step  132 ,  FIG. 6 , where the subject query continues in the same manner described in Section 3, Page45, paragraph 00125 of the Exemplary Subject Data Query and Retrieval Processes. That is, the processes depend on whether or not a seizure was made at step  134 ,  FIG. 6 . If a seizure was made, the process continues as it did above in the second exemplary scenario described in step  134 ,  FIG. 8 , in which the QLEA subject query of the CDMS  14  resulted in a “Confirmed” status classification confirmation response and seizure. If a seizure was not made, the processes would continue as it did above in the third exemplary scenario described in step  134 ,  FIG. 7 , in which the QLEA subject query of the CDMS  14  resulted in a “Suspected” status classification confirmation response only. 
     6. Exemplary Subject Packet for Paper Currency Input Processes 
     In accordance with an embodiment of the invention, a flowchart illustrating exemplary subject packet for paper currency input processes for entering data into the central data management system (“CDMS”)  12  and data records management system (“DRMS”)  20  is set forth in  FIG. 35 . In a preferred embodiment of the invention, these processes are performed by using the CDMS Subject Packet Input Application  32 , local digital computer Subject Packet Input Program  52 , or mobile digital device Subject Packet Input Application  72 , which enable a SLEA to input subject data into the DRMS  20 . Referring to  FIG. 35 , the process commences at step  1000 , and in step  1002 , a SLEA accesses the CDMS  12  via the NDD  22 . In step  1004 , the SLEA selects the “Create Subject Packet for Paper Currency” option from the CDMS  12  and the CDMS  12  assigns a unique transaction number to the transaction. In subsequent step  1006 , the CDMS  12  accesses the CDMS Subject Packet Input Application  32  and presents the SLEA with the “Subject Packet for Paper Currency” input screen. In a preferred embodiment, subject packets in the DRMS  20  for paper currency include (1) the type of currency, (2) the serial number of each note, (3) a description of the currency identifying its “Confirmed” status classification (e.g. “Drug Buy Funds”, “Money Laundering Funds”, “Bait Money”, “Bribe Money”, or the general term “Evidence”), and (4) the SLEA&#39;s contact information. At step  1008 , the Subject Packet Input Application  32  prompts the SLEA for the method to be used to enter the paper currency serial numbers into the CDMS  12 . Paper Currency serial number(s) can either be input (1) manually, or (2) uploaded through an automated commercial scanning process. At decision block  1010 , if the paper currency serial numbers will be entered manually, the process continues at step  308 ,  FIG. 14 , where the SLEA completes the entering of all required information, to include the serial number for each item of paper currency, into the Subject Packet for Paper Currency input screen. An image or photograph of the paper currency can be submitted as descriptive data. The mandatory minimum number of descriptive data fields to be completed for the paper currency will be established by the CDMS administrator. In a preferred embodiment, a minimum number of descriptive data fields are required to be completed for the paper currency category before the Subject Packet Input Application  32  will allow the SLEA user to proceed to the next step in the process. After the SLEA enters the available information into the descriptive data field, the Subject Packet Input Application  32  displays the subject field selection for the status classification of the subject packet for paper currency. In a preferred embodiment, the only status classification available for paper currency is “Confirmed”. The status classification of the subject packet for paper currency submitted for inclusion in the CDMS  12  is selected by the SLEA and is based on the SLEA&#39;s application of the stipulated definition of “Confirmed” characterizing the quantity and quality of information the SLEA possesses concerning the paper currency. After the SLEA enters all of the descriptive data for its subject paper currency, the Subject Packet Input Application  32  displays all the information entered in the subject packet for paper currency screen by the SLEA at step  308 ,  FIG. 14 . Thereafter, in step  310 , the SLEA reviews the information that was entered into the Subject Packet for Paper Currency input screen and decides whether it is satisfied with the Subject Packet for Paper Currency input. At decision block  312 , the SLEA must decide if it is satisfied with the saved Subject Packet for Paper Currency. If the SLEA is not satisfied with the descriptive data entered into the Subject Packet for Paper Currency input screen in step  308 , the QLEA can select the “Edit Subject Packet” option in step  314 , where the process returns the SLEA to step  306  to make any desired changes to the descriptive data. Conversely, if the SLEA is satisfied at step  312  with the descriptive data entered into the Subject Packet for Paper Currency input screen at step  308 , the SLEA can select the “Submit Subject Packet” option at step  316 ,  FIG. 15 , to submit the pending subject packet to the CDMS  12  for storage in the DRMS  20 . Now referring back to  FIG. 35 , if at decision block  1010 , the SLEA is going to utilize the automated scanning and upload process for entering the paper currency serial numbers, additional hardware and software are needed and the process differs slightly. For the automated scanning and uploading of paper currency serial numbers, the process starts at step  1000  and continuing at step  1002 , the SLEA accesses the CDMS  12  via the NDD  22 . Steps  1004 ,  1006 , and  1008  are the same for both the manual and automated paper currency serial number input process; however, at decision block  1010 , the processes change when the SLEA selects “Automated”. In a preferred embodiment, the automated paper currency serial number input process requires the use of a commercial grade currency scanner equipped with character or image recognition and serial number capture functionality and the capability to export the digitized data files into the CDMS  12 . If the SLEA selects “automated” at decision block  1010 , the process continues at step  1012  where the SLEA is prompted by the Subject Packet Input Application  32  to begin the scanning and uploading of paper currency serial number process. The QLEA then loads the paper currency into the attached scanner which scans all the paper currency capturing and digitizing the serial number of each item of currency. At step  1014 , the CDMS Subject Packet Input Application  32  retrieves the digitized serial numbers and populates the appropriate fields of the Subject Packet for Paper Currency input screen. Thereafter, the process continues at step  308 ,  FIG. 14 , where the SLEA completes the entering of all required information, except the serial number for each item of paper currency, which was automatically retrieved from the currency scanner and populated into the Subject Packet for Paper Currency input screen. Referring again to  FIG. 14 , the processes for the creation of a Subject Packet for Paper Currency option mirrors the processes for the creation of a subject packet option, that is, the process continues as previously discussed through steps  310 ,  312 ,  314 ,  316 ,  318 ,  320 ,  322 ,  324 ,  326 ,  328 ,  330 ,  332 ,  334 ,  336 ,  338 ,  340 , and  342  in  FIGS. 14-17 . 
     7. Exemplary Creation of an Investigative Alert and the Related Processes 
     In accordance with an embodiment of the invention, a flowchart illustrating an exemplary creation of the Investigative Alert process carried out by the central data management system (“CDMS”)  18  via the NDD  28  is set forth in  FIG. 4  and thoroughly detailed in  FIGS. 27-30 . In a preferred embodiment of the invention, the central data management system (“CDMS”)  18  and the NDD  28  includes an Investigative Alert feature. An Investigative Alert (“IA”) is a proactive notification created by a SLEA to provide information pertinent to on-going law enforcement operations to a designated user(s) of the CDMS  18  via the NDD  28 . The CDMS  18  can forward an IA via the NDD  28  immediately to the entire network of system users, to a geographical group of users (e.g., users in the northeast U.S., the southwestern U.S. border states, or users in the State of Ohio), to a targeted group of users (e.g. users located along the I-20 corridor from Dallas, Tex., to Jackson, Miss.), to a specific user agency (e.g., the Bossier City Police Department, the Louisiana State Police, or the Desoto Parish Sheriff&#39;s Office), or to individual users (e.g. two Shreveport Police Department interdiction units and one Caddo Parish Canine Unit working a local highway interdiction operation). Preferably, an IA includes the following information: (1) the SLEA&#39;s contact name and 24-hour contact information (e.g., cellular telephone number or dispatch center telephone number), (2) the date and time of issuance, (3) the effective period for the IA (e.g., start time/date, end time/date), (4) identification of all system users to whom the IA is being directed—referred to as “Designated Recipients”, (5) a succinct summary of the information being provided, to include any requested actions by the SLEA, and (6) and the unique transaction number assigned to the IA by the CDMS  18  in step  704 ,  FIG. 27 . 
     Referring now to  FIG. 27 , the process for creating and issuing an IA using the CDMS  18  and the NDD  28  will be described. The process for creating an IA begins in  FIG. 27 , step  700  and continues with the SLEA accessing the CDMS  18  via the NDD  28  at step  702 . At step  704 , the SLEA selects the “Create Investigative Alert” option from the CDMS IA Application  38  and the CDMS  18  assigns a unique transaction number to the transaction. In subsequent step  706 , the CDMS  18  accesses the CDMS IA Application  38 , presents the SLEA with the “IA” input screen, and prepopulates some of the required data fields based on the SLEA&#39;s user account identification number. Preferably, each field in the IA Input screen requires that the requested information be provided. The IA input screen is prepopulated by the CDMS  18  using the information maintained in the SLEA&#39;s user account and also offers the SLEA the option to make any changes/additions to the specific contact name(s) or 24-hour contact number(s). At step  708 , the SLEA completes the entering of all required information into the IA Input screen. As part of step  708 , the SLEA user must select the designated recipients of the IA. The IA Input Application  38  has prepopulated designee recipient groups including all system users, specific geographical groups of users, targeted groups of users, individual users, or it allows the SLEA user to customize combinations of users for designation as a recipient(s). The CDMS  18  also provides the SLEA the option to save customized distribution lists in the DRMS  20 , under the user&#39;s account identification number. Finally, as part of step  708 , the SLEA is prompted to enter a succinct summary of the information to be contained in the IA, to include any special directions or requests by the SLEA and the effective start date and time and end date and time for the IA. The date and time of issuance will automatically be noted when the final IA submission is completed and submitted to the CDMS  18  for issuance. 
     Upon completion of all the required input fields in the IA input screen, the SLEA reviews the content of the pending IA at step  710 . Based on the SLEA&#39;s review of the pending IA, the SLEA determines in the decision block  712  if the SLEA is satisfied with the content of the pending IA. If the SLEA user is not satisfied with the content of the IA, the process continues at decision block  732 ,  FIG. 29 , where the SLEA must select either the “Edit IA” or “Delete IA” option. If the SLEA selects the “Delete IA” option, the CDMS  18  deletes the pending IA at step  734  and the process thereafter concludes at step  736 . If however, at the decision block at step  732 , the SLEA selects the “Edit IA” option, the process continues at step  714 ,  FIG. 27 . Thereafter, the CDMS returns the SLEA user to the IA Input Screen at step  706  and continues as before through steps  708 ,  710 , and  712 . Continuing again at step  712 ,  FIG. 27 , if the SLEA is satisfied with the content of the pending IA, the process continues at step  716 ,  FIG. 28 , where the SLEA selects the “Submit IA” option. At step  718 , the CDMS  18  receives the pending IA and reviews it for errors. If the CDMS  18  identifies any errors in the pending IA at decision block  720 , the CDMS  18  next sends the SLEA via the NDD  28 , at step  722 , an “IA Declination” notification referencing the unique transaction number initially assigned to the IA in step  704  ( FIG. 27 ). Thereafter, at step  726 , the CDMS  18  holds the pending IA in the SLEA&#39;s user account in the DRMS  20  or in the NDD  28  as a pending IA until the errors are corrected or the pending IA is deleted by the SLEA. At step  730 , the SLEA selects the pending IA from the SLEA&#39;s user account and in decision block  732 ,  FIG. 29 , presents the SLEA with the “Edit IA” option or “Delete Pending IA” option. If the SLEA selects the “Delete IA” option at decision block  732 , the pending IA is deleted at step  734  and the process concludes at step  736 . If, however, at decision block  732  the SLEA selects the “Edit IA” option, the IA Input Application  38  continues through step  714 ,  FIG. 27  and returns the SLEA user to step  706 ,  FIG. 27 . Thereafter, the IA Input Application  38  allows the SLEA to tab through the IA Input screen&#39;s data fields to edit the data as needed to correct the identified errors. The process again continues through steps  706 ,  708 ,  710 ,  712 ,  716 , and  718  as before. Again referring to the decision block at  720 ,  FIG. 28 , if the CDMS  18  does not identify any errors in the Pending IA, the CDMS  18  presents the SLEA with the “Final IA Review” screen at step  738  and allows the SLEA to review the entire pending IA. If the SLEA is not satisfied with the pending IA at decision block  740 , the process continues as before at decision block  732 ,  FIG. 29 . However, if at step  740  the SLEA is satisfied with the pending IA, the SLEA selects the “Submit IA” option and the pending IA is sent via the NDD  28  to the CDMS  18 . At step  742 , the CDMS  18  receives via the NDD  28  the Final Pending IA from the SLEA and at step  744 ,  FIG. 30 , the CDMS  18  sends the IA, via the NDD  28 , to the Designated Recipient(s). At step  746 , the CDMS  18  determines if the IA is successfully received by each Designated Recipient(s). The Designated Recipient(s)&#39;s device is configured and arranged to automatically notify the CDMS  18  if it successfully receives an IA. At step  748 , the CDMS  18  receives via the NDD  28  the IA Receipt Confirmation(s) from the Designated Recipient(s). At decision block  750 , the CDMS  18  determines if an IA Receipt Confirmation was received from each Designated Recipient. If the CDMS  18  determines at decision block  750  that any Designated Recipient did not receive the IA, the process continues at decision block  752 , where the CDMS  18  next determines if the failed receipt was the CDMS  18 &#39;s second attempt to deliver the IA. If it was not the second failed attempt, the process again returns to step  744  and repeats through steps  746 ,  748  and  750 . Again at step  750 , if the CDMS  18  determines that any Designated Recipient did not receive the IA, the process continues at decision block  752 , where the CDMS  18  next determines if the failed receipt was the CDMS  18 &#39;s second attempt to deliver the IA. If the CDMS  18  determines at decision block  752  that a second failed attempt to deliver the IA has occurred, the process continues at step  754  where the CDMS  18  records in the DRMS  20  any Designated Recipient(s) from which the CDMS  18  did not receive an IA Receipt Confirmation. Thereafter, the process would continue at step  756 . Returning to decision block  750 , if the CDMS  18  determines that an IA Receipt Confirmation was received from any Designated Recipient(s), the process continues at step  756  where the CDMS  18  records in the DRMS  20  a list of Designated Recipients (1) who successfully received the IA and (2) those to whom IA delivery attempts failed, referencing the unique transaction number associated with each, and compiles an “IA Distribution Confirmation” notice. Then, at step  758 , the CDMS  18  sends via the NDD  28  the IA Distribution Confirmation notice to the SLEA containing, in a preferred embodiment, (1) the list of Designated Recipient(s) who successfully received the IA, (2) the list of Designated Recipient(s) who failed to successfully receive the IA, and (3) the unique transaction number assigned to the IA. The exemplary creation of an IA process is thereafter concluded at step  760 . 
     8. Exemplary Creation of an Archive Record and Related Processes 
     In a preferred embodiment of the invention, the central data management system (“CDMS”)  16  includes an archive feature which creates an Archive Record consisting of all Subject Queries, accepted Subject Packets, successfully issued Investigative Alerts, and Archive Record Queries in the DRMS  20 . Preferably, each Archive Record includes (1) the subject and descriptive data entered by the QLEA or SLEA, (2) the date of the query or entry, (3) the name and contact information of the QLEA or SLEA, and (4) the unique transaction number for the respective transaction. Maintenance of such archives enables a QLEA to conduct an historical search, using the CDMS  16 , of the massive amount of data contained in the DRMS Archive Record. Unlike the Subject Packets contained in the DRMS  20  which have assigned Status Classifications with a known criminal involvement, the Archive Records include all negative queries; negative queries which individually taken can appear inconsequential and unrelated and whose existence would not be made known to a QLEA as the result of a Subject Query. However, with the archive feature, a QLEA is able to perform an Archive Record Query of the DRMS&#39;s  20  Archive Records to determine if a subject was ever queried or inputted by another QLEA or SLEA, thereby identifying other locations or circumstances which prompted law enforcement to make contact with, and query, a given subject. If the QLEA discovers from an Archive Record Query that the Archive Record contains information that a given subject was previously queried by another QLEA or inputted by an SLEA, the QLEA can contact that QLEA or SLEA for additional information using the name and contact information stored in the Archive Record. By contacting a QLEA or SLEA who previously entered a query or inputted an entry for the same subject, the QLEA is likely to obtain additional information about that subject that would have otherwise likely gone unnoticed and could potentially further its investigation. 
     In a preferred embodiment of the invention, the creation of an Archive Record starts at step  800  of  FIG. 31 . At step  802 , a QLEA or SLEA accesses the CDMS  12 ,  14 ,  16 , or  18  (collectively referred to in this exemplary embodiment as CDMS) via the NDD  22 ,  24 ,  26 , or  28  (collectively referred to in this exemplary embodiment as NDD) and submits a Subject Query, inputs a Subject Packet, creates an IA, or submits an Archive Record Query. At step  804 , the CDMS receives via the NDD the Subject Query, inputted Subject Packet, created IA, or Archive Record Query and assigns a unique transaction number (A unique transaction number is assigned by the CDMS at step  104 ,  FIG. 5 , for a Subject Query; at step  304 ,  FIG. 14 , for a Subject Packet input; at step  704 ,  FIG. 27 , for an IA; and at step  904 ,  FIG. 34 , for an Archive Record Query.) At step  806 , the CDMS processes the Subject Query, inputted Subject Packet, created IA, or Archive Record Query. If during the process the inputted Subject Packet or the created IA is deleted by the SLEA, the Archive Record process is aborted and no Archive Record of the transaction is generated. At step  808 , at the completion of the Subject Query, inputted Subject Packet, created IA, or the Archive Record Query processes, the CDMS generates an Archive Record of the transaction, referencing the unique transaction number, and sends that Archive Record to the DRMS  20 . Thereafter, the Archive Record creation process ends at step  810 . 
     10. Exemplary Archive Record Query and Related Processes 
     In yet another preferred embodiment of the invention, the process for submitting an Archive Record Query of the DRMS  20  begins at step  900 ,  FIG. 34 . At step  902 , the QLEA accesses the CDMS  16  and submits an Archive Record Query via the NDD  26 . At step  904 , the CDMS  16  receives the QLEA&#39;s Archive Record Query and assigns a Unique Transaction Number to the query. At step  906 , the CDMS  16  conducts a search of the DRMS  20  for a matching Archive Record(s). Thereafter, at the decision block  908 , the CDMS  16  determines if an Archive Record(s) matching the Archive Record Query was identified in the DRMS  20 . If no matching Archive Record was identified, the process continues at step  912  where the CDMS  16  sends a Negative Response via the NDD  26  referencing the Unique Transaction Number assigned to the query at step  904  to the QLEA and the Archive Record Query process subsequently concludes at step  916 . If however, at the decision block at step  908  a matching Archive Record is identified, the process continues at step  910  where the CDMS sends an Archive Record Confirmation Response via the NDD  26  to the QLEA. In a preferred embodiment of the invention, an Archive Record Confirmation Response contains (1) the date of the matched Archive Record(s), (2) the Unique Transaction Number for the matched Archive Record(s), (3) the name and contact information of the QLEA(s) or SLEA(s) for the matched Archive Record(s), and (4) the Unique Transaction Number for the QLEA&#39;s Archive Record Query. Thereafter, at step  914 , the QLEA receives via the NDD  26  the Archive Record Confirmation Response from the CDMS. The Archive Record Query process then concludes at step  918 . 
     11. Additional Features of the System 
     In one or more preferred embodiments of the invention, the system for facilitating the execution of law enforcement duties includes additional features that further enhance its functionality. Several exemplary features will be described hereinafter. 
     In one preferred embodiment of the invention, additional categories of status classifications could be developed for the submission of subject packets, as determined by the needs of system users. For example, a third tier of status classification based on a lesser standard of evidentiary support than that defined for “Confirmed” or “Suspected” could be utilized. Additionally, compulsory responses of the system could be modified, added, or removed as needed for queries involving such third tier defined subject packets. Another example of additional types of subject packets could be those identifying a “Local Warrant.” Confirmed—Local Warrant subject packets could be submitted to the system not only by law enforcement agencies, but also court systems. Currently, information concerning the existence of local warrants is not available in any national database, but instead is more typically available through local or regional systems or through manual searches necessarily conducted by telephone. 
     In one preferred embodiment of the invention, one exemplary feature of the central data management system (“CDMS”) is its inherent capability to continually generate intelligence information. Although the CDMS  16  is designed to be proactively queried for intelligence by any system user, local, state, tribal, and federal, the significance of the design of the CDMS  16  and DRMS  20  is the fact that it automatically and continually generates intelligence through the use of Subject Queries, Subject Packet inputs, Investigative Alerts, and Archive Record Queries by system users. Each and every use of the CDMS  16  generates intelligence by adding to the DRMS  20 , whether that intelligence information results from a Subject Query, a Confirmed or Suspected Confirmation Response, an Investigative Alert, or an Archive Record Query. The most significant user of the CDMS is the front-line law enforcement officer who, on a daily basis, has the most frequent and consistent contact with known subjects and potential subjects and therefore has the greatest potential to generate intelligence. 
     In one preferred embodiment of the invention, the CDMS of the system  16  is provided with a feature that enhances law enforcement officer safety with respect to health hazards posed by subjects. Use of this feature is subject to the legal limitations governing the release of personal medical information. Arrested or convicted individuals whose hazardous medical conditions are documented by a law enforcement agency or government corrections agency in that person&#39;s arrest records or inmate medical records can be included as a health warning in the DRMS  20 . If such a subject is queried in the CDMS  16 , the CDMS  16  will notify the QLEA of the hazardous health condition of that subject thereby enabling an officer encountering the subject to take the necessary precautions to protect his or her own health in the course of performing his or her law enforcement duties. 
     In another preferred embodiment of the invention, the CDMS of the system  16  is provided with a feature that assists in the enforcement of immigration laws. By using data submitted by U.S. Immigration and Customs Enforcement concerning current and expired immigration documentation, this feature of the CDMS assists in the identification and tracking of individuals using false immigration documentation or who are illegally in the U.S. 
     In yet another preferred embodiment of the invention, the CDMS  16  of the system is provided with a photographic line-up feature to support law enforcement investigations. Using commercially available software programs, this feature of the CDMS enables law enforcement officers to create photographic line-ups to be generated remotely for immediate use in the field by law enforcement officers in on-going investigations (e.g., a six-person photo line-up). In addition to the commercially available software needed to create the line-ups, this feature will require the use of a mobile digital device such as a smartphone, notepad, or laptop computer, programmed and configured for the remote creation and presentation of these line-ups. Thus, the system provides an automated method for generating quasi-instantaneous, in the field, six-person photo line-ups by law enforcement officers. 
     In still another preferred embodiment of the invention, the CDMS  16  of the system is provided with an emergency satellite communications feature. With this feature, a special version of the smart phone for use with the CDMS is designed with the capability to receive satellite communications. Equipped in this manner, the smart phone provides command and control notification capabilities to government and law enforcement agencies operating in an emergency situation in which normal communications are unavailable. As such, the system is capable of providing a satellite capable specific or general purpose mobile digital device for receiving and/or sending information to law enforcement officers operating in areas, or during natural disasters, that render cellular, radio, network, or land-line based communication unavailable. 
     In yet another preferred embodiment of the invention, the CDMS  16  of the system is provided with a license plate reader feature. This feature, utilizing commercially available and law enforcement implemented technology and networks, enables the CDMS to track the movements of particular license plates of interest and have that information delivered directly to a mobile digital device appropriately programmed and configured. Thus, the system is capable of providing an automated system for tracking the movement of license plates that are subjects within the DRMS using commercially available License Plate Reader System LPRS technology. 
     In still another preferred embodiment of the invention, the CDMS  16  of the system is provided with a feature for monitoring of video and surveillance camera systems. With this feature, utilizing the available connectivity of the CDMS and commercially available digital video camera systems, video feeds or digital photographs can be remotely monitored/viewed using the special version of the smart phone or mobile digital device, appropriately programmed and configured, described above as a mobile platform. As one such exemplary application of this feature, commercially available digital video and photographs generated from a digital video surveillance system being used by a bank can be instantly or rapidly transmitted to responding law enforcement units as they respond to a robbery alarm at that bank. Using this feature, banks and other frequently robbed businesses employing a digital video surveillance system in their facilities compatible with the CDMS could greatly enhance effectiveness and safety operations in which law enforcement units are called to their facilities in response to a robbery. Specifically, law enforcement units and investigators could either (1) receive a live or recorded video feed, via the CDMS, from the bank or (2) quickly upload photos or video of a robbery in an Investigative Alert for expedited distribution to responding and investigating personnel. Consequently, the system provides an automated means for monitoring video and surveillance camera systems of a third party by a law enforcement agency user when requested or directed to do so by the third party camera system owner. 
     In yet another preferred embodiment of the invention, the CDMS  16  of the system is provided with a feature for monitoring mobile tracking devices. With this feature, by employing a plurality of commercially available mobile tracking devices, the mobile tracking devices can be monitored from either a fixed position, local digital computer or a mobile digital device. Mobile tracking devices compatible with the CDMS  16  could be monitored by system users across the CDMS system  16  as long as access and connectivity to the CDMS exists. By employing mobile tracking devices compatible with the CDMS, this feature would solve the problem presented by current disparate systems, which require tracker specific software to be installed on any monitoring device to enable it to monitor a given mobile tracking device. Furthermore, CDMS compatible mobile tracking devices could be monitored seamlessly throughout the CDMS system with an access code provided by the SLEA to designated system users via an Investigative Alert. 
     In still another preferred embodiment of the invention, the CDMS of the system  16  is provided with a fingerprint analysis feature. By utilizing this feature, a subject&#39;s fingerprints are scanned and queried, using commercially available, portable scanning hardware, against the DRMS  20 , the Integrated Automated Fingerprint Identification System (“IAFIS”), and the National Crime Information Center (“NCIC”), to facilitate subject identifications. As such, the system provides an automated mobile platform and/or process by which a subject or potential subject could have their fingerprints verified or recorded by front-line law enforcement officers or SLEAs and transmitted back to the CDMS for storage or, as a QLEA, as a query against the national DRMS  20 . 
     In still another preferred embodiment of the invention, the CDMS of the system  16  is provided with a retinal scanning feature. By utilizing this feature, a scan of a subject&#39;s retina is queried, using commercially available, portable scanning hardware, against the DRMS  20  to facilitate subject identifications. Thus, the system provides an automated platform and/or process by which a subject or potential subject could have their retina-print scanned, verified or recorded by front-line law enforcement officers or SLEAs and transmitted back to the CMDS for storage or, as a QLEAs, as a query against the national DRMS  20 . 
     In yet another preferred embodiment of the invention, using commercially available CDMS compatible software, the CDMS of the system provides for an automated process for facilitating the execution of law enforcement duties with a feature for writing police reports. This feature comprises a software program that is compatible with the CDMS, which is designed to enable the drafting and submission of police reports from mobile digital devices such as smart phones, tablets, or laptops. In particular, law enforcement officers or agents can utilize a docking station installed in a patrol unit or an office to dock their mobile digital device. Then, the report writing software enables officers to access data files saved in the mobile digital device, such as pictures, audio recordings, data files, and GPS fixes, and digitally attach those files to the report file. Files for photos taken during investigations, criminal histories (data files), vehicle registrations (data files), wanted persons notices (data files), etc. are capable of being loaded in the report from the mobile digital device. As such, the system provides an automated platform and/or process by which information obtained by a law enforcement or government agency can be used to produce any nature of law enforcement presentation or report. 
     As one particular example, the system facilitates the automated exchange of relevant reports and related subject information necessary to successfully prosecute civil forfeiture proceedings. Using the CDMS  16 , agencies could electronically transmit reports and other related subject information. 
     In yet another preferred embodiment of the invention, the CDMS  16  of the system for facilitating the execution of law enforcement duties includes mobile digital devices with administrative management features. This feature, which utilizes commercially available software, would enable mobile digital devices compatible with the CDMS to provide e-mail, calendar, and text messaging capabilities to officers and their managers. As such, the system provides an automated platform and/or process containing administration management functions. 
     In one embodiment, by employing the Subject Packet and Status Classification concepts to summarize a second system user&#39;s criminal intelligence on a given subject, the system and method does not require that law enforcement reports be stored in its database or be transmitted to a first system user in response to a query. Consequently, when compared to a reports-based database, the Subject Packet-based system and method results in dramatically reduced data storage space requirements. Furthermore, given the significantly reduced size of the data files afforded by the use of the Subject Packet concept, the system and method is capable of transmitting effectively the same actionable intelligence to system users with greater speed (i.e. Subject Packet vs. one or more law enforcement reports/documents). 
     In another embodiment, the system and method does not limit the users of the system to law enforcement users. Although the information contained in the system&#39;s database is law enforcement sensitive, the Subject Packet concept allows the system to make relevant law enforcement sensitive information contained within the database available to non-law enforcement users by limiting the types of Subject Packets to which a specific user has access. For example, fire department and emergency medical personnel have a need to know information contained in law enforcement sensitive files (e.g. inmate records) that identify health hazards and violent/dangerous behavioral tendencies of a subject not only for their safety, but also for the safety of the subject. Accordingly, fire department and emergency medical personnel&#39;s user accounts could be limited to view just the health hazards and behavioral warnings contained in a Subject Packet. In contrast, a reports-based system would necessitate these types of users be given access to the law enforcement sensitive reports (i.e. inmate medical files/reports) in order to obtain the health hazard and behavioral warnings they need to protect themselves and their victim/patient. 
     Similarly, with respect to law enforcement users, their access to relevant sensitive health related information contained in a given Subject Packet could be limited to a general notification of the existence of a “health hazard” posed by a subject. Law enforcement officers do not need to know that a subject has AIDS, or hepatitis C, or tuberculosis. Instead, they simply need to know that a health hazard exists and can then strategically employ tactics to handle the subject accordingly to avoid exposure to the hazard. Use of the Subject Packet concept enables law enforcement agencies, specifically jails, to make the medically sensitive health hazard information contained in their inmate medical records available in a useable form to law enforcement users without significantly compromising the inmates&#39; health privacy. Such health information made available to law enforcement can also serve to better protect the subjects themselves. For instance, a subject who suffers from severe asthma who is confronted by law enforcement in relation to a drunk and disorderly or a domestic violence incident would be safer in such an encounter if the responding law enforcement agency received a health hazard warning notifying them of the subject&#39;s condition. Armed with such information, an officer would know not to utilize pepper spray to subdue such a subject and could employ an alternative strategy to handle the circumstance. 
     In yet another embodiment, use of the Subject Packet concept to store law enforcement criminal intelligence and inmate records does not preclude the use of the system by non-law enforcement government entities such as local and state government administrative agencies (e.g. social security services, child support, and court systems). Again, by restricting user access to specific classifications of subject packets or the information they contain, users other than law enforcement agencies can derive benefit from the law enforcement sensitive information the database contains, as well as the national scope of the database. For example, a state agency which is responsible for the distribution of social security benefits can be given limited access to the system to query its recipients&#39; names in an effort to determine if any are incarcerated. A Confirmation Response received by such an agency concerning a subject, indicting that subject is a Confirmed—Inmate, would (1) delay the distribution of social security benefits to a possibly ineligible beneficiary and (2) immediately provide that agency the contact information to the jail facility to verify the subject&#39;s inmate status before denial of any benefits. Use of the system&#39;s information in this manner would dramatically increase such an agency&#39;s administrative efficiency and its effective capability to prevent fraud. 
     In another embodiment, the system does not restrict the broadened use of the law enforcement sensitive information contained in its database of Subject Packets by non-government, private entities. For example, a pawn shop private business could submit queries to the national database for Subject Packets identifying stolen property. A Confirmation Response to the pawn shop could prevent the pawn shop from conducting a transaction involving Suspected or Confirmed—Stolen Property thereby preventing a financial loss by the business. Additionally, the system would instantaneously provide a Subject Queried Notification to the second system user (Source Law Enforcement Agency) providing it with the contact information for the pawn shop in support of its effort to locate the stolen property and a possible suspect or witness. Similar uses of the system by other private entities with government reporting obligations could be applied to background checks (e.g. for firearms, employment, large equipment sales/purchases, real estate, securities, etc.). 
     In yet another embodiment, the system would not restrict the submission of useful information to the database to only information contained in law enforcement reports. Private entities such as insurance companies could offer a service to private citizens to create Subject Packets containing emergency medical information essential for emergency medical personnel (e.g. fire departments, emergency medical technicians, and emergency room personnel) in the performance of their duties and responsibilities. Once again, by controlling access to specific status classifications of Subject Packets and/or the information they contain, emergency medical personnel could have access to a national database that holds private emergency medical information Subject Packets containing critical information on their victim/patient such as identifying information, emergency contact information, health conditions (e.g. a heart condition, diabetes, allergies, and current medications), and medical insurance policy information. Law enforcement officers would not have access to such Subject Packets, because there is no job-related need for them to know this information. However, the national database this system and method will establish for use by law enforcement agencies and first responders makes such a utilization of the system by a non-government entity effective and fulfills a useful public safety need. Other uses for such Subject Packets could be employed for workers in high-risk professions such as law enforcement, construction, oil and gas industry workers, and emergency first responders. Employing agencies for such high-risk professions could place these types of non-law enforcement sensitive Subject Packets into the national database, so that, in the event of an employee is injured and incapacitated on the job, that employee&#39;s emergency medical information is readily accessible by responding emergency medical personnel, wherever the incident were to occur. 
     Although the invention has been shown and described with respect to a certain embodiment or embodiments, it is apparent that this invention can be embodied in many different forms and that many other modifications and variations are possible without departing from the spirit and scope of this invention. 
     Moreover, while exemplary embodiments have been described herein, one of ordinary skill in the art will readily appreciate that the exemplary embodiments set forth above are merely illustrative in nature and should not be construed as to limit the claims in any manner. Rather, the scope of the invention is defined only by the appended claims and their equivalents, and not, by the preceding description.