WO2007145669A1

WO2007145669A1 - Data collection and processing for the bail bond industry

Info

Publication number: WO2007145669A1
Application number: PCT/US2006/060303
Authority: WO
Inventors: Daniel J. Kern; Scott Rose; Terry Cressy; Douglas Schultz
Original assignee: Hide 'n Seek, Llc
Priority date: 2005-11-16
Filing date: 2006-10-27
Publication date: 2007-12-21

Abstract

A bail bond issuing method according to an embodiment includes receiving a bond request for a defendant and receiving identifying information for the defendant. Utilizing the identifying information, the defendant is associated with a defendant record maintained in a database. The bond request is approved or denied at least in part according to information contained in or otherwise associated with the defendant record.

Description

DATA COLLECTION AND PROCESSING FOR THE BAIL BOND INDUSTRY

BACKGROUND

[0001] Anyone arrested for a crime, other than a capital offense, has an Eighth Amendment right to reasonable bail set by the presiding court. Bail amounts or bail schedules are set and reviewed periodically by the judges of each jurisdiction. Judges often times deviate from the bail schedules taking into account the danger to the public, the defendant's ties to the community, the severity of the crime, and the likelihood the defendant will flee if bail is posted. [0002] Once bail is set, the accused has the option of paying the entire amount in cash himself, or using a licensed bail bond company that will post an appearance bond on his behalf for a non-refundable fee of approximately 10% to 15% of the bail amount. Needless to say, most defendants opt for the latter. [0003] When the appearance bond or bail bond is issued, the bonding company guarantees with the backing of a surety that the accused will appear in court at a given time and place. A typical bail bond is backed by a surety and written by a bondsman and is a guarantee to a court that a defendant will appear for all proceedings as required. Should the defendant fail to appear the bond can be forfeited and both the bondsman and the surety are liable to pay to the court the face value of the bond. Typically, the surety will pay this amount and then attempt to collect from the bondsman. Non-appearing defendants and forfeited bonds are quite expensive in terms of time and money and are to be avoided.

[0004] The bondman's authority to obligate a surety to a bond is typically derived from a power of attorney, often referred to as a "power." As used here a power is a legal document given by a surety to a bondsman. Typically, the power is a physical document having a unique serial number and a face value. A given bondman may maintain an inventory of such powers provided by a particular surety. A bond, when written, references or is otherwise linked to a power. That bond cannot be for more than the face value of the power that it references. Many sureties, unfortunately, only know that they have provided inventories of "powers" to various bondsmen but are unaware when a particular power is used by a bondsman when writing a bail bond. For this reason, sureties are unaware of their real exposure at any given time.

DESCRIPTION OF THE DRAWINGS

[0005] Fig. 1 is a schematic representation of an exemplary network environment in which embodiments may be implemented.

[0006] Fig. 2 is an exemplary block diagram of the network environment of

Fig. 1 according to an embodiment.

[0007] Fig. 3 is an exemplary block diagram of a bondsman device according to an embodiment.

[0008] Fig. 4 is an exemplary block diagram of a surety device according to an embodiment.

[0009] Fig. 5 is a block diagram illustrating an example of defendant data according to an embodiment.

[0010] Fig. 6 is a block diagram illustrating an example of bond history according to an embodiment.

[0011] Fig. 7 is a block diagram illustrating an example of administrative data according to an embodiment.

[0012] Fig. 8 is a block diagram illustrating an example of notification data according to an embodiment.

[0013] Figs. 9-11 are exemplary flow diagrams illustrating steps taken to implement various embodiments.

DETAILED DESCRIPTION

[0014] INTRODUCTION: Embodiments of the present invention operate to compile, sort, categorize, edit, and disseminate bail bond data in real time both nationally and internationally. In many states, bail bonds are issued by licensed bail agents or bail bondsmen and the process is governed by each state's Department of Insurance. A few states have opted to issue bail bonds through their own state agencies and do not allow commercial bondsman. [0015] It is estimated that 6,000 bail bond companies in the United States issue over $74 million in bonds every day of the year. Bail bond companies range from small one-man operations to large corporations with several locations in several states. Most of these companies, both large and small, cannot afford to underwrite all of the bonds they issue because the financial liability is too great. Therefore, the majority of bonds issued are guaranteed by a number of insurance companies acting as sureties. [0016] The bail agent and surety split the bond premium paid by the defendant, with the surety's underwriting fee set at a percentage of the premium. Most sureties also accumulate a "build-up fund" (BUF) account for each bond company they underwrite by withholding another percentage of the premium. If the bondsman defaults on the payment of a forfeited bond, the surety will pay it out of the BUF account. It is important for the reader to understand that ultimately the sureties look to the individual bail agents to indemnify them for all forfeited bonds they must pay to the courts. Under collateralized bonds can lead to financial ruin for both the agents and sureties, and agents that write an excessive number of bad bonds are subject to being dropped. Numerous sureties have been left holding the bag when their agents have taken unnecessary risks. Embodiments are designed to motivate the bail bond companies and their individual agents to make sure their clients appear in court. Bond forfeitures are an increasingly serious problem in most U.S. jurisdictions, amounting to hundreds of millions of dollars. [0017] It is estimated that bail agents bond out approximately 5.4 million defendants every year and issue twenty billion dollars in appearance bonds. This can generate two billion dollars in bond fees that are shared by the sureties and bondsmen. The sureties receive two hundred million dollars in underwriting fees and another two hundred million dollars is deposited in BUF accounts to help pay for defaulted forfeitures.

[0018] It has been estimated eighteen percent of the individuals bonded out of jail fail to make at least one court appearance. The majority of these skips are readily located by the bondsman and returned in time to prevent the forfeiture of the bond. However, approximately 396,000 will run every year with the intention of permanently avoiding court. With an average bond value of $4,544, the industry is at risk of paying $1.7 billion in bond forfeitures if these people cannot be located and returned to jail in time. [0019] From these figures the reader can easily see the bail bond industry generates a tremendous amount of financial activity, and the sureties and bondsmen are subject to a great deal of exposure. Consequently, there is a need for a system to help identify, manage, and avoid risk. [0020] Once arrested, the accused is handcuffed and taken to the police station where he is booked, fingerprinted, and photographed. Often bail is set at the time of the arrest, however some jurisdictions require defendants arrested on felony charges to be arraigned in front of a judge. Arraignment generally happens within 80 hours of arrest. Depending on the crime and the individual, bail will either be set or the defendant will be held in custody until trial. Approximately sixty percent of all people arrested are bailed out. [0021] Bondsmen, and not the underwriting surety, typically make the decision to write a bond. Sureties set maximum dollar limits (usually $30,000), but anything under that limit can be issued by the agent without prior approval. The bondsman must evaluate the defendant in an effort to determine if they want to incur the liability for posting his appearance bond. Presently, they have few tools available to assist them. Bond agents often times require a third party indemnitor to guarantee the bond amount if the defendant skips. This is usually a family member or close friend. Unfortunately, for a variety of reasons, indemnification does not always work in real world application and bonds are often under col lateral ized. It is far better to have defendants make their court appearances than try to collect restitution from disgruntled indemnitors.

[0022] Once the agent is convinced the defendant is a good bond candidate, he will post the bond with the court and the defendant is released. From this point on there is very little contact between the defendant and the bondsman. If the defendant makes all of his court appearances right up to sentencing, the requirements of the bond are met and the bond is exonerated.

[0023] If the defendant fails to make a single appearance, the court serves the bondsman with a "notice of forfeiture" within 5 to 30 days. Failure to do so within the statutory period generally cancels the bond and releases the bondsman from further liability. Understandably, the courts are usually organized well enough that notices of forfeiture are served within the required time limit.

[0024] When a defendant fails to make his court appearance one of two things happened:

• He intended to appear, but was prevented from doing so for some reason (he forgot, the car broke down, he could not get off work), or

• He has no intention of appearing and is hiding.

[0025] Fifty percent of all skips fall into the first category and for the most part are easily located with a phone call. However, they now have an additional "failure to appear" charge levied against them and a subsequent warrant has been issued for their arrest. A second bond is set for the failure to appear at an amount generally higher than the original bond. If the defendant cannot meet the premium requirements of the new bond, the bondsman can usually convince them to surrender to jail where they will be held until trial. The bondsman has now met his obligation and the bond is exonerated. The fifty percent in the second category that "skip" are the source of gray hairs for the sureties and bondsmen alike.

[0026] The bondsman now has 30 to 188 days (depending on the jurisdiction) to produce the skip or the bond becomes payable to the court. With the average bond amount set at $4,544, it is easy to understand why the bondsman and the surety are concerned when a defendant runs. Anxiety levels increase proportionately when bond amounts exceed $20,000. [0027] In the process of locating the skip, bondsmen must assemble a recovery file based upon the information (good or bad - complete or incomplete) they gathered in the initial interview process. Using this information they have to determine where the skip is most likely to be hiding. The investigator must follow up on every lead and quite often this means flying back and forth across the country, renting a car and hotel room, and incurring substantial overhead costs.

[0028] The essential players in an exemplary business model implanted according to an embodiment are listed below, followed by a detailed explanation of what they contribute and how they can benefit from embodiments of the present invention

• Sureties.

• Bail bond companies.

• Bounty hunters and fugitive recovery agents.

• Federal and state judicial systems, and law enforcement agencies.

• The general public.

• The entertainment industry.

[0029] Embodiments of the present invention lure sureties with efficiency, increased control over underwriting, and decreased costs. Efficiencies are created in their bail agents being able to pre-screen and select those clients most likely to make their court appearance, efficiency in utilizing a centralized decision-making process, and efficiency in apprehending skips that decide to run. With estimates of as much as $544 million in bond payouts made every year, a program that saves sureties and bondsmen that kind of money will be wholeheartedly supported. [0030] Sureties currently rely on their bail agents to do the best job they can with very little supervision. Strange as it may seem, given the size of the industry and the money it generates, there is currently no system in place where sureties and bail agents can readily communicate with each other. Even stranger is that control of the underwriting decision is not centralized with the underwriter, but remains within the bail agent's province. [0031] As in most opportunities, timing can be very important. Sureties can receive timely if not immediate reports from their agents indicating for whom and in what amounts bonds are being issued. Eventually prospective clients will receive "bond scores" much like the highly relied upon credit scores currently being used. If they so desire, sureties can require the bail agents send the data collected to them before the bond is issued for confirmation and final approval.

[0032] Through an implantation of an embodiment of the present invention, sureties, bondsmen, and governmental agencies are given have access to valuable statistical information. Local county courts and state governments have no system in place that compiles this information at this time. Embodiments not only include client pre-screening and skip apprehension components, but also provides for sophisticated record keeping and data analysis.

[0033] As anecdotal evidence of the laxity in the current surety/bail agent system, a bail company inadvertently failed to report a $254,000 bond to the underwriting surety. The client made her court appearance so the bond did not go into forfeiture, however the surety was never aware the bond was issued and was never compensated for underwriting it. Even though the omission was unintentional, the damage was done. If this can happen accidentally, it can happen intentionally and probably does. Embodiments of the present invention provide the sureties with a record of every bond they underwrite. [0034] Bail Bond Companies make up the largest number of players in the business, all fiercely competing for the same defendants' dollars. What would make them join together working towards a common goal? There are five primary reasons why bail bondsmen will utilize various embodiments of the present invention:

• Most importantly, the sureties may demand it as a requirement before underwriting their bonds and this reason alone carries a tremendous amount of weight and persuasion. Without a surety, most bondsmen would be out of business.

• The bondsmen will have access to the most current and complete national and international database of bail bond history available anywhere, enabling them to pre-screen potential clients, thereby issuing more secure bonds.

• The threat of having a defendant's profile published on the Internet will motivate them to make their court appearances, thereby reducing the number of bond skips and overhead costs incurred by the bondsmen. Reduced expenses mean greater profits.

• The number of bond forfeitures will decrease because the bondsmen will use the most efficient, effective, and up to date fugitive locator program available anywhere.

• No information sensitive to the individual bond companies as competitors will be disclosed, so no bondsmen will feel threatened.

[0035] The bail agents have as much incentive to reduce bond payouts as the sureties, since 10% of the bond premiums are deposited in BUF accounts. For every dollar the surety pays the courts in forfeitures, they look to the individual bail bondsman for indemnification. As stated earlier, this is estimated to be as much as $544 million annually. Realistically, once the money is deposited in the BUF account, the bondsmen never see it again. [0036] Bounty hunters and fugitive recovery agents are often independent from the bail bond companies and are compensated from rewards paid when they recover a fugitive. When the time remaining before forfeiture on a $54,000 bond begins to approach 30 days with no luck in locating the skip, bond companies begin to panic. It is now time to bite the bullet and offer a $5,000 or $10,000 reward, with the amount growing larger as the time to forfeiture grows shorter.

[0037] Bounty hunters and recovery agents live fast and furious lives where days, hours and minutes count. Utilizing embodiments of the present invention, they can be notified within seconds of an offered reward anywhere in the world. They have immediate access to complete, up-to-the-minute information on any fugitive, as well as direct communication with the bail bond company. [0038] Bounty hunters and recovery agents can sign up for automatic email notices whenever a fugitive is believed to be hiding in a specific area. For example, a bounty hunter in Los Angeles can receive an email whenever a skip is believed to be in the southern California area. They will know in real time who is wanted and how much the bail company is willing to pay for their apprehension.

[0039] Recovery agents will also be able to advertise their services. A bond company in Billings, Montana is easily able to find and retain a recovery agent in Tampa, Florida to apprehend a skip. This reduces travel and apprehension overhead costs.

[0040] Embodiments of the present invention tap the Internet's ability to transmit and receive data from anywhere in the world in a manner of seconds, thereby allowing users be updated and informed in real time. The larger bail bond companies are sophisticated enough to compile and maintain small databases of their past clients. This gives them an edge when evaluating the bail requests of repeat customers. These companies pre-screen every potential client by doing a search of their own records to see if they have a prior history. If the search indicates the client did not make a court appearance or presented other problems, it is not likely the bondsman will issue a new bond. With significant percentage of all bail clients being repeat offenders, information is king.

[0041] Embodiments of the present invention compile and maintain the a comprehensive bail bond database. An exemplary database includes at least three kinds of data:

1. Informational data

2. Video and audio data

3. Biometric data

[0042] The informational data is gathered at the time the client is first interviewed and includes such things as:

• Name, aliases, current address and phone numbers

• Weight, height, birth date, hair and eye color, race, complexion, social security number

• Current and prior address

• Spouse's name, address, social security number

• Parents' name, address, and phone number

• Work history, employer names, addresses, phone numbers for past five years

[0043] Video and audio data consists digital audio/video file(s). Bondsmen are equipped with a camcorder connected to a laptop computer. This data file makes a record of:

• The client's mannerisms and overall visual appearance including detailed facial impressions. Facial recordings can be used later in conjunction with computer identification programs to match an unknown face or suspected known face to a positively identified face. • Visual recordings of unique physical characteristics such as scars, birth marks or tattoos. These are known as positive identifiers by recovery agents and are highly valued information.

• Audio recordings can be used in matching an unknown or suspected known voice to a positively identified voice through computer voice exemplar matching.

[0044] Biometrics refers to the immediate identification of a person based on his or her physiological or behavioral characteristics. Biometric identification can, for example, be implemented on fingerprint matching, retinal and iris scans, voice exemplars, facial thermograms, and hand geometry.

[0045] Two exciting biometric technologies include DNA analysis and the less costly ISA matching. ISA relies on a unique set of antibodies called

"individual specific antibodies" found in blood, serum, saliva, urine, semen, perspiration, tears and body tissues. An unskilled technician using inexpensive equipment can complete a test in a couple of hours.

[0046] The biometric data contained in the database can include:

• Iris and retinal scans recorded by simply looking into a camcorder lens.

• Digitized finger and palm prints recorded by pressing a hand on a laptop peripheral screen.

• DNA and ISA samples collected from oral swabs.

• Facial and voice data from audio/video recordings.

[0047] Imagine a crime scene anywhere in the world where blood, hair or semen samples have been gathered. Using DNA and ISA technology, this sample can be digitized and run through the database looking for a match. A database containing this type of information would be invaluable. [0048] Processing the information, audio/video, and biometric data in the database, the following questions can be answered:

• Is this potential client who they are representing themselves to be?

• Is the information they provided consistent with information provided in a previous bond?

• Did the client make a previous court appearance or do they have a history of bond skips?

• Are they currently out on bond in another jurisdiction?

• Are they bond shopping because they have been turned down by another bond company?

• Are they a current bond skip wanted by another bond company?

• Are they a wanted criminal with an outstanding arrest warrant?

• Are their indemnitors reliable or have they defaulted on previous bonds?

• Are their relatives and employers credible, or do they have an extensive bond history?

[0049] Through the use of "spider" programs, the database can, for example, include millions of current bail records and millions of records from the Department of Justice identifying individuals that are currently in prison or have served time.

[0050] If a client makes all of his court dates, no further action is taken and the client's informational and biometric data is maintained for future reference. However, an advantage of various embodiments becomes apparent when a bail company is at a loss in locating a skip and the forfeiture date is quickly approaching. A $54,000 hit for a failure to appear is not something any surety looks forward to, nor would any bail agent want his company to be liable for incurring. Fortunately, within minutes a bondsman can activate a skip's data file and the worldwide Internet community has immediate access to: • The skip's reward information, which is the primary motivator for recovery agents - professional and amateur alike.

• Complete informational and biometric data files including suspected locations where the skip may be hiding.

• Immediate email broadcasts to subscribers who have requested notification based upon certain criteria, i.e. amount of reward or suspect location.

• Access to audio/video mpeg files so the viewer has a first hand impression of who they are looking for, plus visuals of identifying tattoos, scars, and birth marks.

• Computer assisted face identification and suspect confirmation from sources such as cell phone picture scans or a digital camera file sent for analysis. Cell phones are particularly suited for this purpose because the picture can be sent immediately via the cell phone.

[0051] All of the information above can be placed in the "public access" section of a web site. Now the entire world can become pseudo detectives trying to earn the next $54,000 reward and professional bounty hunters and recovery agents can immediately see who is wanted, where they are believed to be, how much is offered for their capture, and how long they have until the bond becomes due.

[0052] COMPONENTS: Fig. 1 illustrates an exemplary network 10 in which various embodiments may be implemented. Network 10 includes a central database manager 12, bondsman device 14, surety device 16, interested party device 18, and defendant communication device 19. Central database manager 12 represents generally any combination of hardware and programming capable of data analysis, storage, manipulation, archiving, and other similar tasks. Bondsman device 14 represents generally any computing device and associated programming that can be utilized by or on behalf of a bail bondsman to interact with central database manager 12. Surety device 16 represents generally any computing device and associated programming that can be utilized by or on behalf of a surety to interact with central database manager 12. Interested party device 18 represents generally any computing device and associated programming that can be utilized by or on behalf of a interested party to interact with central database manager 12. An interested part is any party who might have an interest in data stored or analyzed by central database manager 12. Examples of interested parties could include bail bondsman, sureties, recovery agents, lawyers, court systems, and any other party that might have an interest. Defendant communication device 19 represents any device through which a defendant can communicate with one or more of devices 12-18. For example, defendant communication device 19 may be a land line telephone located at the defendant's residence. [0053] Link 20 interconnects central database manager 12 with devices 14- 18 and represents generally a cable, wireless, or remote connection via a telecommunication link, an infrared link, a radio frequency link, or any other connector or system that provides electronic communication between components 12-18. Link 20 may represent an intranet, an Internet, or a combination of both. Components 12-18 can be connected to network 10 at any point and the appropriate communication path established logically between components 12-18.

[0054] It is noted that the various functions of central database manager 12 may be provides by one or more of devices 14-18. For example, the functionality of database server 12 may be implemented on bondsman device 12 or may be distributed across multiple bondsman devices 14, surety devices 16, and third party devices.

[0055] Fig. 2 is an exemplary block diagram of network 10 from Fig. 1 illustrating the logical components of central database manager 12. it is noted that defendant communication device 19 is not shown. As shown, central database manager 12 includes central database 22, screening engine 24, administration engine 26 and notification engine 28. Central database 22 represents generally any memory such as a hard drive, configured to store records. In this example, those records are categorized as defendant data 30, administrative data 32, notification data 34, and public/private records 36 which are discussed in more detail below. It is noted that while central database manager 12 is shown as a single device, its responsibilities may be distributed across multiple devices interconnected by link 20. [0056] Screening engine 24 represents generally any combination of hardware and programming capable of creating, manipulating, and analyzing data within central database 22 for the purpose of assisting in a determination as to whether a bond request will be approved and a bond written or otherwise issued on behalf of a particular defendant.

[0057] Administration engine 26 represents generally any combination of hardware and programming capable of creating, manipulating, and analyzing data within central database 22. Administration engine 26 is responsible for updating central database 22 according in information received from bondsmen, sureties, other interested parties e information as well as screening engine 24 and notification engine 28. Administration engine 26 is also responsible for providing bondsmen, sureties, and other interested parties with information related to the bonding process. As is discussed below, such information might include a surety's exposure with respect to a particular bondsman or group of bondsmen. It might include a bondsman's potential liability. It might include accounting information for a particular bondsman or surety with respect to the creation, maintenance, and distribution of data within and from central database 22.

[0058] Notification engine 28 represents generally any combination of hardware and programming capable of creating, manipulating, and analyzing data within central database 22 for the purpose of notifying interested parties of the occurrence of specified events related to information discerned from central database 22. For example, a given event may be the occurrence of a bonded defendant's failure to appear before a court. Interested parties in this case may be a bail bondsman, the surety for the bond in question, the court system, the defendant's attorney, and a recovery agent.

[0059] Fig. 3 is an exemplary block diagram of bondsman device 14 illustrating the logical components of local database manager 12'. As shown, local database manager 12' includes local database 22', screening engine 24', administration engine 26' and notification engine 28'. Components 22'-28' serve functions similar to components 22-28 of central database manager 12 except in this example they are local to bondsman device 14. It is noted that in this example bondsman device 14 may still be interconnected with surety device 16, third party device 18, and even central database manager 12. [0060] Fig. 4 is an exemplary block diagram of surety device 16 illustrating the logical components of local database manager 12". As shown, local database manager 12" includes local database 22', administration engine 26" and notification engine 28". Components 22", 26" and 28" serve functions similar to components 22, 26, and 28 of central database manager 12 except in this example they are local to bondsman device 14. It is noted that in this example surety device 16 may still be interconnected with bondsman device 14, third party device 18, and even central database manager 12. [0061] Fig. 5 is an exemplary block diagram illustrating the logical contents of defendant data 30. In this example, defendant data 30 includes a number of defendant records 42. Each defendant record 42 represents electronic information associated with a particular person - a defendant. Here each record is shown to contain data in a number of sections 44-54. Name section 44 contains a defendant's given name. Alias section 46 contains any aliases associated with that defendant. Contact section 48 contains information for use in contacting the defendant. Such information may include one or more physical addresses, email addresses, and phone numbers. Biometrics section 46 represents electronic data associated with the defendant's unique physical body demographics or behavioral characteristics. Examples include finger prints, retinal scans, speech patterns, DNA and ISA sample, and the like. [0062] Bond history section 52 represents electronic data relates to the defendant's bond history. Such information can include data relates to past bonds issued in behalf of the defendant, whether the defendant has ever skipped a bond or missed a court appearance, and whether the defendant has attempted to obtain a bond and been denied. Bond score section 54 represents data identifying a bond score for a defendant. A bond score is information that can be used to predict a likelihood that a defendant will skip. An exemplary bond score could be calculated based on any combination on items such as a defendant's bond history, credit rating, marital status, age, and criminal record. [0063] Fig. 6 is an exemplary block diagram of illustrating the logical contents of bond history 52. In this example, bond history 52 includes bond requests section 44, active bonds section 46, discharged bonds section 48, and compliance section 52. Bond requests section 44 contains information corresponding to attempts by a particular defendant to obtain a bond. Active bonds section 46 represents data corresponding to bonds issued on behalf of that defendant that have not been discharged. Discharged bonds section 48 represents data corresponding to bonds issued on behalf of that defendant that have been discharged.

[0064] Compliance section 52 represents data corresponding to a defendant's compliance with various requirements. Examples of requirements include a responsibility placed on a defendant to periodically check in with a bondsman. A defendant may be required to periodically call an automated system with a land line telephone and enter a code identifying the defendant. Administrative engine 26, described above may serve as such an automated system and upon receiving a call from a defendant will confirm that the call originated from an appropriate location and then update compliance section 52 accordingly. In a particular example, compliance section 52 may have a flag that is not set or set to a specified status as the case may be when a defendant is not in compliance. In such a manner, defendant's who are not in compliance can be detected and appropriate action taken.

[0065] Fig. 7 is an exemplary block diagram of illustrating the logical contents of administrative data 32. In this example, administrative data 32 includes surety records 50, bondsman records 58, power records 60 and bond records 62. Each surety record 50 represents data identifying or otherwise associated with a particular surety. Each bondsman record 58 represents data identifying or otherwise associated with a particular bondsman. Similarly, each power record represents a power (power of attorney) that is in the inventory of a particular bondsman, and each bond record 62 represents data identifying or otherwise associated with a particular bond that has been issued. A given power record 60 can identify a power of attorney by serial number and face value. A given bond record 62 can contain data identifying the characteristics of a bond such as whether or not it has been issued on behalf of a given defendant and, if so, data linking that bond record 62 to a defendant record 42 in defendant data 30 (Fig. 3). A given bond record can contain information related to the bond amount, if issued, as well as data identifying whether or not the bond has been forfeited.

[0066] A given surety may be associated with or do business with a number of bondsmen providing each of those bondsmen with any number of powers.. A record 50 for a given surety may be linked with the bondsman records 58 for those bondsmen associated with that surety. Furthermore, that surety record 50 may also be linked to the power records 60 for those powers provided by the surety associated with that surety record. Each power record is linked to a bond records 62 for those bonds issued under the power of attorney associated with that power record 60.. Similarly, a record 58 for a given bondsman may be linked to the records 50 for those sureties with whom the bondsman is associated. That same bondsman record 58 may also be linked to the power records 60 for those powers in that bondsman's inventory as well as the bond records 62 for those bonds written or otherwise issued by that bondsman. [0067] In this manner, administration engine 26 can parse administrative data 32 to identify relationships between records 50-58. For example, administration engine 26 can parse administrative data 32 to identify, on behalf of a surety, information regarding a particular bond guaranteed by that surety, information regarding bonds provided to or written by one or a group of bondsmen, and the status of all bonds guaranteed by that surety. Administration engine 26 can parse administrative data 32 to identify, on behalf of a surety, information regarding the various powers provided by that surety that are in the inventory of one or more bondsmen. Moreover, where the bond records 62 for bonds issued on behalf of defendants each contain data identifying the amount of the particular bond, a surety can utilize administration engine 26 to sum those amounts to reveal the surety's potential exposure. Similarly, administration engine 26 can parse administrative data 32 to identify, on behalf of a bondsman, information regarding the status of a particular bond associated with a particular surety as well as information regarding all bonds written by the bondsman and associated with a surety or group of sureties. [0068] Fig. 8 is an exemplary block diagram of illustrating the logical contents of notification data 34. In this example, notification data 34 includes interested party records 64. Each interested party record 64 can include or be otherwise linked to one or more event records 66 and one or more action records 68. Each event record 66 is linked to one or more action records 68. Interested party records 64 each represent a collection of electronic data identifying a party that desires a particular action to be taken upon the occurrence of a given event. Event records 66 each represents data identifying a particular event. Each action record represents data identifying an action to be taken upon the occurrence of an event identified by an event record 66 linked with that action record 68. For example, a particular interested party record 64 might identify and provide contact information for an attorney representing a particular defendant. A corresponding event record 66 might identify an event in which the defendant attempts to obtain a bond, misses an appearance, or the like. A corresponding action record 68 might then include data instructing that the attorney be notified upon the occurrence of the event. [0069] In another example, a particular an interested party record 64 might identify and provide contact information for a particular recovery agent. A corresponding event record 66 might identify an event in which any defendant skips a bond in a particular geographic location. A corresponding action record 68 might then include data instructing that the recovery agent be notified upon the occurrence of the event.

[0070] In another example, an interested party record 64 might identify a particular defendant. A corresponding event record 66 might identify an event in which a date is nearing for a requirement with which the defendant must comply. Such may include a court appearance or that the defendant check in with a bondsman. A corresponding action record 68 might then include data instructing that the defendant be notified of the upcoming requirement. [0071] In yet another example, an interested party record 64 might identify and provide contact information for a court system in a particular jurisdiction. A corresponding event record 66 might identify an event in which a particular defendant attempts to obtain a bond, skips a bond, misses an appearance, or the like. A corresponding action record 68 might then include data instructing that the court system be notified upon the occurrence of the event. [0072] Many other scenarios are possible. For example, a surety may be interested in being notified when a bond is issued, when defendant skips, and when a bond is forfeited. A bondsman may be interested in being notified when a currently bonded defendant attempts to obtain another bond. [0073] USE: The exemplary flow charts of Figs 9-11 illustrate various actions taken by the components of central database manager 10 (Fig. 2). Fig. 9 illustrates steps taken by screening engine 24 (Fig. 2) when assisting in a determination of whether a bond will be issued on behalf of a defendant. Fig. 10 illustrates steps taken by administration engine 26 (Fig. 2) when populating and updating database 22 and responding to queries requesting information from database 22. Fig. 11 illustrates steps taken by notification engine 28 (Fig. 2) monitoring for the occurrence of an event and taking a corresponding action. [0074] Starting with Fig. 9, a bond request is received via a bondsman device (step 70). The bondsman is then associated with a particular surety (step 72). Screening engine 24 may automatically communicate with administration engine 26 to identify a relationship between the bondsman and the particular surety. Administration engine 26 may also obtain data identifying the particular surety via bondsman device 14.

[0075] A defendant is associated with a defendant record 42 (step 74). Step 74 may involve identifying an existing defendant record 42 or establishing a new defendant record 42. For example, administration engine 26 may receive information identifying the defendant via bondsman device 14. Such information can include a name, alias, social security number, address, and biometric information. Using this identifying information, administration engine 26 parses defendant data 30 to determine if the information corresponds to an existing defendant record 42. If so the defendant is associated with that defendant record. If not, administration engine 26 creates a new defendant record 42 for the defendant.

[0076] A bond score is then generated or obtained (step 76). If in step 74, the defendant was associated with an existing defendant record 42, administration engine 26 can obtain the bond score from that defendant record 42. If a new record was created in step 74, administration engine 26 can communicate with screening engine 24 to generates a bond score based upon information provided via bondsman device 14 and corresponding information in public/private records 36. For example, screening engine 24 may obtain the defendant's social security number from bondsman device 14. Using that number, screening engine 24 parses public/private records 36 corresponding to the social security number. For example, screening engine 24 may access public/private records 36 to obtain the defendant's credit score, employment history, age, marital status, UCC filings, and the like to use in generating the bond score.

[0077] A determination is then made as to whether or not to deny the defendant's request for a bond based on the bond score (step 78). As an example screening engine 24 may automatically deny if the bond score is below a first threshold, conditionally deny if the bond score is between the first threshold and a second threshold, and approve if the bond score is above the second threshold.

[0078] If the request is denied in step 78, screening engine 24 denies the bond in step 80 otherwise it is determined if additional approval is required (step 82). Such additional approval may be appropriate where the request was conditionally denied in step 78 or where there is a discrepancy between information collected from the defendant and information contained in the defendant record 42. If additional approval is required the process moves to step 84 otherwise the process moves to step 86. In step 84, screening engine 24 determines whether that additional approval can be obtained. The decision in step 84 may be automatic or may be made manually by a surety or the bondsman. It may also be made based on the defendant's bond history, if any, obtained from the defendant's record. Other factors influencing the decision can include the amount of the bond request, whether that amount exceeds a face value of the power of attorney that would obligate the surety to guarantee the bond, the surety's exposure related to bonds already issued, and the bondsman's history in avoiding bond forfeitures. These other factors can be determined by a surety or a bondsman utilizing administration engine 26 to query administrative data 32. If additional approval is obtained in step 84 the process proceeds to step 86. Otherwise the request is denied in step 80. These various other factors can also be used to establish the various thresholds against which a bond score is compared.

[0079] A bond is written or otherwise issued on behalf of the defendant (step 88). The bond may be issued according the defendant's bond score. For example, the defendants cost in obtaining the bond may be based on that bond score - the better the score the lower the cost. The defendant's record 42 is then updated (step 88). Administration engine 26 updates the bond history to reflect whether the bond request was denied in step 80 or that a bond was issued on the defendant's behalf in step 86. The bond history can also be updated to identify that the issued bond is associated with the bondsman and guaranteed by the surety associated with the bondsman. [0080] At this point either a bond has been issued or a bond request has been denied. Where a bond is issued it may be desirable for administration engine to update administrative data 32 accordingly. For example, administration engine 26 would then updates administrative records accordingly adding a new bond record 62 inked to a corresponding bondsman record 58, power record 60, and a corresponding surety record 56 . [0081] Moving on to Fig. 10, a bond record 62 is established for each bond written or otherwise issued by a bondsman (step 90). That bond record 62 is linked to a bondsman record 58 for the corresponding bondsman. The bond record 62 is also linked to the power record 60 for the corresponding power giving that bondsman the authority to obligate a particular surety (step 93). The bond record 62 is also linked to the surety record 56 for the obligated surety. [0082] At some point administration engine 26 receives a query from a particular device 14, 16, or 18 (step 96). Examples of queries include queries for a surety's exposure with respect to issued bonds, queries for bonds associated with a particular bondsman or group of bondsman, and queries for bonds associated with a particular surety or a particular defendant. This list is not exhaustive and is meant only to provide examples. Administration engine 26 parses the administrative data 80 according to the query (step 98) and returns a response to the query (step 100.)

[0083] At some point in time administration engine 26 receives update information (step 102). Such update information may be provided via bondsman device 14, surety device 16, third party device 18, or defendant communication device 19 (Fig. 1 ). Update information may also be received from screening engine 24 and notification engine 28. Examples of update information can include information used to populate and update database 22. The type of update data is identified (step 104). Administration engine 26 may make this identification based on the source of the information and the content. Examples of update information include information used to create or update defendant data 30, administrative data 32, notification data 34, and public/private records 36. More specific examples can include information identifying a defendant received via bondman device 14 to be used to locate or create a defendant record 42, evidence of a defendant's periodic check in with a bondsman received via defendant communication device 19, and information indicating a defendant has missed a court appearance received via third party device 18.

[0084] Database 22 is updated according to the update type and update information (step 106). This may include creating or updating a defendant record 42, a surety record 56, a bondsman record 58, a power record 60, an interested party record 64, an event record 66, or an action record 68. [0085] Fig. 11 illustrates steps taken by administration engine 26 and notification engine 28 (Fig. 2) when populating notification data 36 (fig. 5), monitoring for the occurrence of an event, and taking a corresponding action. An interested party record 64 is established (step 108). That interested party record 64 is linked with an event record 66 (step 110). The event record 66 is linked with an action record 68 (step 112).

[0086] As described above an interested party record 64 represents a collection of electronic data identifying a party that desires a particular action to be taken upon the occurrence of a given event. Event records 66 each represent data identifying a particular event. Each action record represents data identifying an action to be taken upon the occurrence of an event identified by an event record 66 linked with that action record 68. For example, a particular interested party record 64 might identify and provide contact information for an attorney representing a particular defendant. A corresponding event record 66 might identify an event in which the defendant attempts to obtain a bond, misses an appearance, or the like. A corresponding action record 68 might then include data instructing that the attorney be notified upon the occurrence of the event.

[0087] As further examples, an interested party record 64 may provide contact information for a particular defendant. A corresponding event record 66 may identify a date to remind that defendant of an upcoming requirement with which the defendant need comply to remain in compliance. Such a requirement may be a court appearance or a need to check in with a bail bondsman. A corresponding action record 68 might then include data instructing that the defendant be notified of the upcoming requirement when that date is reached. Similarly, an interested party record 64 may provide contact information for a particular bondsman who wrote a bond for a given defendant. A corresponding event record 66 may identify an ecent that occurs when a defendant record 42 for that defendant indicates that the given defendant is not in compliance. A corresponding action record 68 might then include data instructing that the bondsman be notified of the defendant's non-compliance. [0088] Notification engine 28 identifies the occurrence of an event identified by a given event record 66 linked to a particular interested party record 64 (step 114). Notification engine 28 instigates an action according to the action record 68 linked to the event record 66 (step 116). Such action may involve notifying the interested party identified the corresponding interested party record 64. [0089] AN EXEMPLARY SCENARIO: John Doe's Miami, Florida employer suspects John has embezzled $1 million in company funds and files a complaint with the local prosecuting attorney. The prosecutor agrees there is sufficient evidence to try John and she convinces a grand jury to indict him and a judge signs a warrant for John's arrest. The police arrest John and take him to the county jail for booking where he is photographed and finger printed. [0090] John calls his attorney and tells him of his predicament. The attorney meets John at the courthouse where he is to be arraigned. John pleads not guilty to the crime and the judge sets bail at $200,000. John does not have $200,000 to bail himself out so he calls UrFree Bail Bonds. If they accept John as a client, UrFree will post an appearance bond on his behalf for a fee. [0091] The UrFree bondsman packs up his laptop computer (bondsman device 14) complete with a Wi Fi wireless Internet connection card, a camcorder, and various other components and drives to the jail to interview John. At the jail, the bondsman begins the interview process by recording all of John's informational data.

[0092] The bondsman then makes an audio/video recording of John using his camcorder and has John place his palm on a small screen plugged into the computer's UBI port. The bondsman also has John look into the lens of the camcorder to make a retinal scan.

[0093] Using his wireless connection, the agent connects directly to the Internet at the jail and transmits the collected data to central database manager 12 for analysis. Screening engine 24 searches defendant data 30 for a defendant record 42 for John Doe based upon one or more of the following:

• The name, social security number and other informational data collected;

• John's facial features;

• Finger and palm prints;

• Iris and retinal scans; and

• Facial and voice recognition.

[0094] If John has a defendant record 42, that record will be located and the current information compared to the information previously recorded. Questions such as, "Is John Doe who is says he is?" and "Does he appear to be a good bond candidate?" can now be answered. Searches are also done on John's third party indemnitors to determine their credibility. [0095] If there is no defendant record 42 for John because he is a first time arrestee, his data file is still complete and is recorded in the event he should decide to run later, or he is arrested in the future for another crime. Depending on the requirements of the surety, John's information can be transmitted to them for final approval and centralized control.

[0096] In this scenario, John is determined to be a good candidate and UrFree issues a bond. John is released from jail and leaves with his attorney to prepare for trial two months from now. Notification engine 28 transmits the bond data to the surety who now has a record the bond was issued. [0097] Before John was released, he paid UrFree a fee. UrFree sent a portion of that fee to the surety as an underwriting fee, and another portion is deposited in UrFree's BUF account. A debit or ACH charge to UrFree's bank account is processed and the financial transaction is complete. [0098] When the time for trial arrives John is nowhere to be found. The judge issues a warrant for John's arrest for failure to appear and UrFree is notified within five days of John's errant ways. UrFree's investigator immediately reviews John's file in the central database and the search begins. UrFree has 96 days to find John or lose $200,000. Not an enviable position to be in, but UrFree is not without the best tools and resources available to successfully complete the task.

[0099] Sixty days have gone by and UrFree cannot locate John, however they strongly believe he is in the Houston, Texas area. It is now time to activate John's file on a web site. A $10,000 reward is offered for information leading to the apprehension of John Doe. Notification engine 28 sends emails containing information from John's defendant record 42 to all interested parties indicating they want to receive notification of Houston area skips. UrFree is charged for the activation and the $10,000 reward is electronically deposited into a trust account. [00100] A 24-hour hot line is maintained where leads are taken and informants registered. All information received on the identity of an informant will be strictly confidential and never revealed to anyone. Only the substance of the lead is passed on to UrFree for follow up.

[00101] In this hypothetical, Irene Informant knows John is staying at the Pine Crest apartments in Houston and calls the hotline. Irene is the first caller and is registered as such. Now, UrFree can either fly to Houston or hire a Houston recovery agent to check out the lead. If they choose to use an outside recovery agent, the agent can familiarize himself with the case by reviewing John's defendant record 42. Positive identifiers such as scars, tattoos and birth marks can be visually observed - as can mannerisms, weight, height, hair color, facial hair and voice. During surveillance, the recovery agent can take cell phone pictures of John coming and going from the apartment and send the file to the central database for face matching and confirmation. [00102] Once UrFree is confident the individual in the Houston Pine Crest apartments is John Doe, they can work with the recovery agent and/or the Houston police to apprehend him. When John is finally in custody, Irene Informant is paid a reward and the recovery agent is paid for services rendered. [00103] CONCLUSION: The network 10 of Fig. 1 illustrates an exemplary environment in which embodiments may be implemented. Implementation, however, is not limited to network 10. The block diagrams of Figs. 2-5 show the architecture, functionality, and operation of various embodiments of the present invention. A number of the blocks are defined at least in part as programs. Each of those blocks may represent in whole or in part a module, segment, or portion of code that comprises one or more executable instructions to implement the specified logical function(s). Each block may also represent a circuit or a number of interconnected circuits to implement the specified logical function(s).

[00104] Also, the present invention can be embodied at least in part, in any computer-readable media for use by or in connection with an instruction execution system such as a computer/processor based system. "Computer- readable media" can be any media that can contain, store, or maintain programs and data for use by or in connection with the instruction execution system. Computer readable media can comprise any one of many physical media such as, for example, electronic, magnetic, optical, electromagnetic, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, a portable magnetic computer diskette such as floppy diskettes, hard drives or a portable compact disc. [00105] Although the flow diagrams of Figs. 6-8 show specific orders of execution, the orders of execution may differ from that which is depicted. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession may be executed concurrently or with partial concurrence. All such variations are within the scope of the present invention.

[00106] The present invention has been shown and described with reference to the foregoing exemplary embodiments. It is to be understood, however, that other forms, details and embodiments may be made without departing from the spirit and scope of the invention that is defined in the following claims.

Claims

CLAIMS What is claimed is:

1. A bail bond issuing method, comprising: receiving a bond request for a defendant; receiving identifying information for the defendant; and associating a defendant with a defendant record maintained in a database utilizing the identifying information.

2. The method of Claim 1 , further comprising approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record.

3. The method of Claim 2, further comprising obtaining or generating a bond score for the defendant and wherein approving or denying comprises approving or denying the bond request at least in part according to the bond score.

4. The method of Claim 2, wherein associating comprises: determining if the database contains a bond record associated with the defendant utilizing the identifying information; if the database contains a defendant record for the defendant, associating the defendant with that defendant record; otherwise generating a new defendant record according to the identifying information.

5. The method of Claim 4: further comprising if a defendant record is determined to exist, obtaining a bond score contained in or otherwise associated with the defendant record, and if a defendant record is generated for the defendant, generating a bond score for the defendant and updating the generated defendant record to include or otherwise be associated with the bond score; and wherein approving or denying comprises approving or denying the bond request at least in part according to information contained or otherwise associated with the defendant record where that information includes the bond score.

6. The method of Claim 2, further comprising updating the defendant record to reflect the approval or denial of the bond request.

7. The method of Claim 2, further comprising associating the bond request with a bondsman and a surety and if the request is approved: establishing a bond record associated with the bond; linking the bond record to a surety record associated with the surety; and linking the bond record to a bondsman record associated with the bondsman.

8. A bail bond administration method, comprising: establishing bond records in a database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; and linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record.

9. The method of claim 8, further comprising linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

10. The method of claim 8, further comprising: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

11. The method of Claim 8, further comprising: establishing defendant records in the database, each at least indirectly associated with one or more of one or more bond records, power records, bondsman records, and surety records; receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant records, bond records, bondsman records, and surety records according to the update type and the update information.

12. A bail bond notification method, comprising: establishing interested party records in a database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events.

13. The method of Claim 12, further comprising: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.

14. A bail bond issuing, notification, and administration method, comprising: receiving a bond request for a defendant; receiving identifying information for the defendant; associating a defendant with a defendant record maintained in a database utilizing the identifying information; approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record; updating the defendant record to reflect the approval or denial of the bond request; establishing bond records in a database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; and linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record; establishing interested party records in a database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; and linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events.

15. The method of claim 14, further comprising linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

16. The method of Claim 14, further comprising: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

17. The method of Claim 14, further comprising: receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant record, bond records, bondsman records, and surety records according to the update type and the update information.

18. The method of Claim 14, further comprising: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.

19. A computer readable medium having computer executable instructions for: receiving a bond request for a defendant; receiving identifying information for the defendant; and associating a defendant with a defendant record maintained in a database utilizing the identifying information.

20. The medium of Claim 19 having further instructions for approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record.

21. The medium of Claim 20, having further instructions for selectively obtaining or generating a bond score for the defendant and wherein the instructions for approving or denying include instructions for approving or denying the bond request at least in part according to the bond score.

22. The medium of Claim 20, wherein the instructions for associating include instructions for: determining if the database contains a bond record associated with the defendant utilizing the identifying information; if the database contains a defendant record for the defendant, associating the defendant with that defendant record; otherwise generating a new defendant record according to the identifying information.

23. The medium of Claim 22: having further instructions for if a defendant record is determined to exist, obtaining a bond score contained in or otherwise associated with the defendant record, and if a defendant record is generated for the defendant, generating a bond score for the defendant and updating the generated defendant record to include or otherwise be associated with the bond score; and wherein the instructions for approving or denying include instructions for approving or denying the bond request at least in part according to information contained or otherwise associated with the defendant record where that information includes the bond score.

24. The medium of Claim 20, having further instructions for updating the defendant record to reflect the approval or denial of the bond request.

25. The medium of Claim 20 having further instructions for associating the bond request with a bondsman and a surety and if the request is approved: establishing a bond record associated with the bond; linking the bond record to a surety record associated with the surety; and linking the bond record to a bondsman record associated with the bondsman.

26. A computer readable medium having computer executable instructions for: establishing bond records in a database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; and linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record.

27. The medium of claim 26, having further instructions for, linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

28. The medium of claim 26, having further instructions for: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

29. The medium of claim 26, having further instructions for: establishing defendant records in the database, each at least indirectly associated with one or more of one or more bond records, power records, bondsman records, and surety records; receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant records, bond records, bondsman records, and surety records according to the update type and the update information.

30. A computer readable medium having computer executable instructions for: establishing interested party records in a database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events.

31. The medium of Claim 30, having further instructions for: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.

32. A computer readable medium having computer executable instructions for: receiving a bond request for a defendant; receiving identifying information for the defendant; associating a defendant with a defendant record maintained in a database utilizing the identifying information; approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record; updating the defendant record to reflect the approval or denial of the bond request; establishing bond records in a database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; and linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record; establishing interested party records in a database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; and linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events.

33. The medium of Claim 32, having further instructions for linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

34. The medium of Claim 32, having further instructions for: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

35. The medium of Claim 32, having further instructions for: receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant record, bond records, bondsman records, and surety records according to the update type and the update information.

36. The medium of Claim 32, having further instructions for: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.

37. A bail bond issuing system, comprising an administration engine, a screening engine, and a database configured to store defendant records; wherein: the administration engine is configured for receiving a bond request for a defendant and receiving identifying information for the defendant; the screening engine is configured for associating a defendant with a defendant record maintained in the database utilizing the identifying information and approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record.

38. The system of Claim 37, wherein the screening engine is further configured for selectively obtaining or generating a bond score for the defendant and approving or denying the bond request at least in part according to the bond score.

39. The system of Claim 37, wherein the screening engine is configured for associating the defendant with the defendant record by: determining if the database contains a bond record associated with the defendant utilizing the identifying information; if the database contains a defendant record for the defendant, associating the defendant with that defendant record; otherwise causing the administration engine to generate a new defendant record according to the identifying information.

40. The system of Claim 39 wherein the screening engine is further configured for obtaining a bond score contained in or otherwise associated with the defendant record if that defendant record is determined to exist the screening engine is further configured for generating a bond score for the defendant and causing the administration engine to update a generated defendant record to include or otherwise be associated with the bond score; and the screening engine is configured for approving or denying by approving or denying the bond request at least in part according to information contained or otherwise associated with the defendant record where that information includes the bond score.

41. The system of Claim 37, wherein the administration engine is further configured for updating the defendant record to reflect the approval or denial of the bond request.

42. The system of Claim 37, wherein the database is configured to store bond records, surety records, and bondsman records and wherein the bond request is associated with a bondsman and a surety and the administration engine is configured, following approval of the bond request, for: establishing a bond record associated with the bond; linking the bond record to a surety record associated with the surety; and linking the bond record to a bondsman record associated with the bondsman.

43. A bail bond administration system, comprising an administration engine and a database configured to store bond records, surety records, and bondsman records and wherein following approval of the bond request, the administration engine is configured for: establishing bond records in the database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; and linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record.

44. The system of Claim 43, wherein the administration engine is configured for linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

45. The system of claim 43, wherein the administration engine is further configured for: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

46. The system of Claim 43, wherein the administration engine is configured for: establishing defendant records in the database, each at least indirectly associated with one or more of one or more bond records, power records, bondsman records, and surety records; receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant records, bond records, bondsman records, and surety records according to the update type and the update information.

47. A bail bond notification system, comprising an administration engine, a notification engine and a database configured to store interested party records, event records, and action records, wherein:

The administration engine is configured for:: establishing interested party records in the database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events; the notification engine is configured for utilizing the interested party records, the event records, and the action records to instigate an action with respect to an interested a party following the occurrence of an event.

48. The system of Claim 47, wherein the notification engine is configured for: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.

49. A bail bond issuing, notification, and administration system, comprising a screening engine, an administration engine, a notification engine and a database configured to store defendant records, bond records, surety records, bondsman records; interested party records, event records, and action records, wherein: the administration engine is configured for: receiving a bond request for a defendant; receiving identifying information for the defendant; the screening engine is configured for associating a defendant with a defendant record maintained in the database; approving or denying the bond request at least in part according to information contained in or otherwise associated with the defendant record; updating the defendant record to reflect the approval or denial of the bond request; the administration engine is further configured for: establishing bond records in the database each bond record being associated with a bond guaranteed by a surety and written by a bondsman; linking each bond record to a bondsman record associated with a bondsman who wrote the bond corresponding to that bond record; linking each bond record to a surety record associated with a surety responsible for guaranteeing the bond corresponding to that bond record; establishing interested party records in the database, each interested party record identifying an interested party; linking each interested party record to one or more event records each identifying a particular event or events; and linking each event record to one or more action records each indicating an action to be performed upon the occurrence of one or more events. the notification engine is configured for utilizing the interested party records, the event records, and the action records to instigate an action with respect to an interested a party following the occurrence of an event.

50. The system of claim 49, wherein the administration engine is configured for linking each bond record with a power record associated with a power of attorney giving a bondsman authority to obligate a surety to the bond corresponding to that bond record.

51. The system of Claim 49, wherein the administration engine is further configured for: receiving a query; parsing bond records, bondsman records, and surety records according to the query; and returning a response to the query.

52. The system of Claim 49, wherein the administration engine is configured for: receiving update information; identifying an update type according to one or more of a source of the update information and the update data; updating one or more of the of the defendant record, bond records, bondsman records, and surety records according to the update type and the update information.

53. The system of Claim 49, wherein the notification engine is further configured for: identifying an occurrence of an event identified by a particular event record; instigating an action indicated by an action record linked to the particular event record with respect to the interested party identified by the interested party record linked to the particular event record.