Jury Selection Plan

GULF COUNTY
CLERK OF CIRCUIT COURT

SealFLGulfB&W

February 13, 2020

Prepared by:

Rebecca L. Norris
Clerk of Circuit Court, Gulf County

Purpose and Scope

Purpose and Scope3
I. Creation of the Initial Candidate Selection4
A. Source Lists4
B. Source Data Adjustments4
C. Time Frame5
D. Initial Jury Candidate List5
II. Name Selection6
A. Equipment and Software6
B. Security6
C. Process Overview for Name Selection7
D. Name Selection Algorithm7
E. Initialization10
Appendix A: CryptGenRandom Seed Value Generator11
Appendix B: Seedgen Procedure Code and Notes from Original TPR Process 1312
Appendix C: CLCG4 Random Number Generator - Validation Results17
Appendix D: Acknowledgements and References18

Purpose and Scope

The purpose of this document is to describe the design and implementation of the Jury Selection Process to be used in a new Jury Management System for Gulf County, Florida.

The scope of this document includes the algorithms and methods used to:
- Create and Maintain a Master Candidate table

- Select a set of names from the Master Candidate table to create a Jury Pool
Also in scope is a description of the equipment, operating system and programming software, methods, and modes of operation to be used in the Jury Selection process.

Sufficient detail will be provided to satisfy the statutory condition of selection "by lot and at random" and of due process as required by Chapter 40, Florida Statutes.

I. Initial Candidate Selection List Creation List

A. Source Lists

The initial candidate selection list is created from three (3) sources:
1. The quarterly list of names provided by the Department of Highway Safety and Motor Vehicles (“DHSMV”) pursuant to 40.011 F.S. This data file is processed against the Master Candidate (master_jurors) table, adding new names and updating existing information, such as addresses.

2. The list of names of persons who have filed affidavits pursuant to 40.011 F.S. requesting to serve as a Juror. The JMS provides the capability for the Clerk to manually add individuals to the Master Candidate table as required.

3. An exclusion list containing those persons who are unable to serve, have already served, or whose service is otherwise excused or postponed pursuant to 40.013, 40.022, and 40.023 F.S. The JMS provides the capability for the Clerk to Exempt someone from service (i.e. Over 70), to Exclude some from serving on an individual Venire (i.e. a Caretaker), and to Postpone someone so that they will be included in a later Venire. For example, if an individual was postponed until September 30th 2012 due to a scheduling conflict, that postponement date is stored in their Master Candidate record, and the first Venire that is created on or after that date will automatically include that individual in addition to those that were selected at random.

4. The Clerk is the official custodian for the Master Candidate table (Source List) and is responsible for the security and integrity of the list and all processes.

5. The Master Candidate table will contain not less than 250 names, pursuant to 40.02 F.S.

B. Source Data Adjustments

1. Quarterly, DHSMV provides the Florida Court Clerks and Comptrollers (“FCCC”) with a data file that contains all persons holding a valid Florida Driver License or Identification Card. FCCC acts as a distribution agent, grouping the data by County and dispersing it to the Clerk of Court. Gulf County receives this data from FCCC quarterly via a dedicated network connection and the file is placed into a secured folder on a server for processing. The data received is an ASCII, fixed-length file, and is not modified in any way.

Once received, the DHSMV data is parsed and used to update the Master Candidate table in the Jury Management System where new persons are added and existing persons are updated (address, etc.). The Master Candidate table is a MSSQL relational database containing all eligible candidates gathered from the Initial Candidate Source Lists.

2. For those people who have filed affidavits pursuant to 40.011 F.S. requesting to serve as a Juror, their information is manually entered into the Candidates table by the Clerk of Court.

3. FCCC provides an ASCII data file to the Clerk of Court twice per month that contains persons who have deceased. This is an ASCII, fixed-length file similar to the Quarterly DHSMV file, and is also placed into a secured folder on a server for processing. It is not modified in any way. Once received, the data is parsed andused to update the Candidates table in the Jury Management System. Each deceased person is marked as such in the Master Candidate table and is no longer eligible for selection.

C. Time Frame

The DHSMV file is provided by FCCC quarterly, in January, April, July, and October. The Master Candidate table is updated with this information when it is received. Persons requesting to serve by signing an Affidavit are entered manually by the Clerk of Court as received. The Department of Health file containing deceased persons is provided by FCCC twice per month, on the 1st and the 15th. The Master Candidate table is updated with this information when it is received. Candidates that are excused pursuant to 40.013 F.S. or postponed to a later date are updated on-demand by the Clerk of Court.

D. Initial Jury Candidate List

Since this is a new application that is being created to replace an existing application, the Master Candidate table will be initially loaded by converting the current master Jury list file from an Informix database to a MSSQL database. No names will be excluded or modified during this conversion. This table contains all individuals possessing a Florida driver license or ID card as provided by the DHSMV for Gulf County.

II. Name Selection

A. Equipment and Software

The Jury Management System is a graphical, browser-based application written in Microsoft's .NET environment, using the Visual Studio 2015 software development tool. It is a custom application designed and developed by Civitek.

The application will be housed on multiple servers with the following specifications:
• Model: virtual machine; physical HW model HPE proliant BL460 Gen9

• Processor: Physical CPUs = Intel Xeon ES-2630 v3 2.4 GHz. Dual socket; 8 cores per socket; 16 cores per host. Virtual CPUs= 2 virtual cpu's (per vm); total 4 cores (per vm).

• Memory: 8 GB memory per vm

• HDD:[SIZE] (OS Partition - C:\)[size] 80GB (Data Partition - E:\) 20 GB. Can be expanded.

• NIC: physical nic = Broadcom qlogic 57840 10 Gbps; virtual nic = vmxnet3 vmware network adapter.

• OS: Windows Server 2016 Standard Edition x64 version 1607 build 14393.2490
The database will be housed on four clustered database servers/SAN configuration model with the following specifications:

Server
- Model: ProLiant DL380 Gen9

- OS: Windows 2012 R2\ SQL server 2016 enterprise AlwaysOn

- Processor: Xeon e5-2667 v3, 2 sockets with 8 cores at 3.20GHz

- Memory: 768GB Ram Memory
Storage Area Network (SAN)
- Model: HP HP 3Par 7400

- Storage capacity: 54 Terabytes

- Storage allocated to the Jury database: 25 GB
The Server will store the SQL Server 2016 database software. The SAN will store the actual Jury database.

B. Security

The Clerk of Court is the official custodian and is responsible for the security and integrity of the name lists and of the juror pool selection process. All servers are located in the Civitek Data Center, which is secured by magnetic key-lock. Only authorized System Administrators have access to the Data Center. The Data Center is designed for 24x7 operations, and is supported by an Uninterruptible Power Supply and generator systems.

The Jury Management System is an Intranet application and as such, is not accessible to the public via the Internet. Only authorized users have access to the application. Only Civitek application developers and database administrators have access to the database. All information necessary for auditing purposes, including random number seed sets, is stored perpetually in MSSQL Server relational database tables as part of the application base.

C. Process Overview for Name Selection

The Clerk of Court and a Judge determine that a Jury Pool needs to be created and how many potential jurors the pool should contain. Information about this pool is entered into the Jury Management System ("JMS") such as the venire date, number of jurors needed, etc.

The JMS begins the selection process by determining the number of all eligible jury candidates (persons not permanently excused, have not served in the past year, etc.) from the Master Candidate table. For example, the Master Candidate table contains approximately 488,000 names in total, but approximately 280,000 names have either been Exempted (i.e. Over 70, Convicted Felon, Deceased, etc.) , or served or summoned within 1 year, or have been Postponed. The resulting set contains approximately 206,000 names. Each of these 206,000 names by example has a uniquely assigned Juror_ID.

The system seeds the CLCG4 Random Number Generator ("RNG") with a seed set and obtains a random number for each of the eligible jury candidates.

The next step of the Jury Selection process is to assign a Random Number to each of the 206,000 Juror_ID(s) and save to the Eligible Jurors temporary table. (Note: The Eligible Jurors temporary table is emptied at the start of this process.)

The Eligible Jurors temporary table is then sorted by the random number and read providing a randomly ordered list of jurors until the desired number of jurors for the pool is obtained. For example 15,000 requested jurors of the 206,000 Eligible Jurors would be randomly selected from the Eligible Jurors temporary table to create the Jury Pool.

D. Name Selection Algorithm

Random Number Generator

The Random Number Generator ("RNG") used in the Jury Management System is the C# implementation of the CLCG4 Random Number Generator by Pierre L'ecuyer and Terry H. Andres originally written in C and based on the Combination of Four LCGs (Linear Congruential Generators).

This is a portable package for uniform random number generation based on a backbone generator with period length near 2"121, which is a combination of four linear congruential generators. The package provides for multiple (virtual) generators evolving in parallel. Each generator also has many disjoint subsequences, and software tools are provided to reset the state of any generator to the beginning of its first, previous, or current subsequence. Such facilities are helpful to maintain synchronization for implementing variance reduction methods in simulation.

A sample of output showing the C# version of CLCG4 RNG produces identical values as the C version is provided in Appendix B: CLCG4 Random Number Generator.

For testing validation of the CLCG4 Random Number Generator, please refer to Appendix C:
CLCG4 Random Number Generator - Validation Results.
Seed Sets
The RNG must be seeded before use to set a starting point for random number generation.

The CLCG4 Random Number Generator accepts 4, 32-bit (128 bits) seed values and can produce astronomically more (upwards of 3x10^38) streams.

The JMS will create the 4 value seed set automatically in real time when a Jury Pool is being selected (see the Initialization Section (E) for details of how the seeds are created. After the random selection process is complete, the seed set that was used will be stored in a table for auditing purposes as well as an internal JMS step that verifies the same set of 4 Seed values have not been previously used. This will 100% guarantee that the same 4 value seed set combination will never be used more than once.
Name Selection Process
1. A record set is created with an SQL Select from the Master Candidate table. The SQL Select contains the necessary select/omit logic so as to include only persons actually eligible to serve at that point in time. It omits persons who have been excused or are otherwise not eligible to serve in this Jury Pool (i.e. Over 70, Convicted Felon, Deceased, other permanent excusals, or served or summoned within 1 year, and is not postponed to a future venire date.).

2. The RNG is initialized with the seed set (See Section (E) Initialization).

3. The system seeds the CLCG4 Random Number Generator ("RNG") with a seed setand obtains a random number for each of the eligible jury candidates.

4. The Eligible Jurors temporary table is emptied.

5. A Random Number is assigned to each of eligible jurors determined in step 1 and then saved to the Eligible Jurors temporary table. The Eligible Jurors temporary table consists of two columns the Juror_ID and the Random_Integer <random number>.
Juror IDRandom Integer
104144534
139745733
157682723
181316912
196204797
Etc... (Up to All Eligible Jurors determined in step 1).
6. The Eligible Jurors temporary table is then sorted by random number and read providing a randomly ordered list of jurors.
Juror IDRandom Integer
3306982011963
4596782012031
1893242012063
1375392012090
3608492012095
Etc... (Will include All Eligible Jurors determined in step 1, just order by the Random Number).
7. All the jurors who have previously been granted a postponement for the current venire date are the first included into the selection list for jury service.

8. The top number of Eligible Jurors requested minus those previously postponement to this date as described in Step 7, are read from the randomly ordered list of jurors as defined in Step 6 and then inserted into the Pool_Jurors table as the Jury Pool members. During this process the record in the Master Candidate table is updated to reflect selection and thereby omitting them form the next Eligible Juror selection for 1year.

9. The total number of requested jurors has been fulfilled and the Jury Pool has been selected.

E. Initialization

Seed Set Creation
The CLCG4 Random Number Generator requires four seed values upon initialization. These four seed values are four 32-bit integers, automatically system generated by the getSeedValue() class method which uses the Microsoft CryptGenRandom [advapi32.dll] function. The CryptGenRandom is a cryptographically secure pseudorandom number generator function and produces random bytes which are multiples of 8 bits. The CryptoAPI uses underlying system entropy to seed its internal crypto-graphic RNG. The entropy pool is hashed using one of the SHA algorithms so it applies approximately 128-160 bits of randomness (4-5 32-bit words).

The four seeds produced by the getSeedValue() class method are stored in a JMS SQL database table for auditing purposes as well as an internal JMS step that verifies the same set of four Seed values have not been previously used.

The review the C# code of the getSeedValue() class method and the usage of the Microsoft CryptGenRandom [advapi32.dll] function to produce the random four Seed Set values, please refer to Appendix A: CryptGenRandom Seed Value Generator.