San Diego DUI criminal defense attorneys - Source Code litigation New Jersey update:

State v. Chun, et al.
New Jersey Supreme Court
Docket Number 58,879

New Jersey's Source Code question, per closing arguments record presented by an excellent DUI defense attorney John Menzel, J.D. to Judge Michael Patrick King:

Is firmware version 3.11 used in the Alcotest 7110 MK-III-C scientifically reliable by clear and convincing evidence?

From the testimony by examiners on both sides of the question, from revelations dawning for the first time during cross examination, from the overwhelming weight of the evidence, the answer is: NO!

This software is not scientifically reliable at all.

The following remarks address these issues:

¨ What the Supreme Court charged us to do.
¨ What we have learned about that charge in this case.
¨ The legal standards of general acceptance which we must apply.
¨ The particular scientific field in which source code resides.
¨ The relevant scientific community we must consider.
¨ How that scientific community was represented in this case.
¨ How general acceptance is defined.
¨ The quality of proof required.
¨ The burden of proof.
¨ Methods of proof.
¨ The application of standards.
¨ The problems of complexity and culture.
¨ How standards may one day fix these problems.
¨ What to do now.

The Supreme Court’s Charge

After we concluded the first round of these hearings last year, Your Honor ultimately came to these conclusions about Draeger’s source code:
¨ We do not think that this dispute about the source codes has any substantial relevance to our ultimate conclusion, that the Alcotest 7110 instrument is very good at measuring breath alcohol.[1]
¨ The firmware currently in the Alcotest NJ Version 3.11, and any future modifications or upgrades of that present firmware, does not impact upon or affect the scientific reliability, accuracy or precision of the Alcotest evidential breath test instrument to detect, analyze and accurately report a breath alcohol reading.[2]
This was because Your Honor saw “no hint of source code problems or failure throughout this litigation.”[3]
The Supreme Court disagreed. It has now charged us to perform a particular task in this case. Here is what they said:
IT IS ORDERED that, the matter is temporarily remanded to the Special Master for the limited purpose of providing defendants the opportunity to conduct, at defendants' expense, an analysis of the software referred to as Firmware version...3.11 used in the Alcotest 7110..., which analysis is to be limited to determining whether Firmware version...3.11 reliably analyze[s], record[s] and report[s] alcohol breath test results....
The Supreme Court directed Draeger to provide an independent software house for the purpose of:
conducting that analysis...in accordance with the methodology previously agreed upon by defendants and DSDI, as set forth in Addendum A....
Addendum A, a.k.a. the “Sachs protocol” and D-232, provides that
This software house will examine the source code for obvious concerns within the code, and also for consistency with the algorithms as documented in the software.... [and to] certify to the State and the public that the software properly employs the algorithms and that no errors exist in the source code.[4]
Of course, being a Fine Arts major in college, I would not know an “obvious concern” if it bit me.
But two examiners were retained for the purpose of source code review: (a) SysTest, represented by Bruce Geller, and (b) BaseOne, represented by John Wisniewski. They each found what they considered “obvious concerns” with the code, the most telling of which were excessive cyclomatic complexity and an excessive use of global variables.
From their respective examinations, neither examiner could certify to either condition demanded by the Supreme Court. They could not certify that the software properly employs the algorithms. Nor could they certify that no errors exist in the source code.
Without going any further, the State and Draeger have failed to meet the requirements established for this case by our Supreme Court.

What We Have Learned in General
Of course, we have learned a number of things in these hearings that no one knew or appreciated when we started.
First, we learned that the Sachs protocol was incomplete in that the way a software house examines code must be specified with reference to some standard. We saw how a cursory review where no concerted effort is made to find “obvious concerns” will yield a report with innocuous findings and conclusions which, on the surface, sound impressive but, on closer examination, mean nothing. We will speak more of standards later.
Second, we learned that no source code is error free. But code can be written in a way that makes it reliable. So the effort to find error-free code is not a fool’s errand. In reliable code, we constantly search for errors and, when we find them, we correct them according to a systematic, standardized, well-thought-out method. Each time a correction is made over the life of such code, it just gets better and better.
Unfortunately, the Alcotest source code is not reliable. My previous colleagues have provided many examples of just how unreliable this Alcotest source code is.
In any event, the final step of the Sachs protocol’s examination -- that the Alcotest be “tested against and measured in compliance with O.I.M.L. [International Organization of Legal Metrology] specifications adopted and current at the time of such tests” -- is not now applicable to this case.

The Legal Standard We Must Apply
The legal standard we must apply to version 3.11 has been stated in our cases thus:
“[T]he thing from which the deduction is made must be sufficiently established to have gained general acceptance in the particular field in which it belongs.”[5]
“Thus, the test in criminal cases remains whether the scientific community generally accepts the evidence.”[6]
Here is how we must apply these legal requirements:
¨ First, we define the particular field in which this source code analysis resides.
¨ Second, we must consider who is the scientific community encompassing this particular field.
¨ Third, we must consider whether the source code in question here would be generally accepted within the relevant scientific community.

The Particular Field in Which Source Code Resides
The particular fields with which we are concerned in this case are those of computer science, electrical engineering, and software programming -- fields separate and distinct from that of forensic science with which we were so concerned last year. We know this because:
¨ NHTSA [National Highway Traffic Safety Administration] has no programming standards. NHTSA’s Ed Conde relied on incomplete computer generated data -- the alcohol influence reports -- and flawed data, accepting one test that the Alcotest itself rejected.
¨ All of those witnesses from last year that purported to be members of the forensic science field -- Edward Conde, Samuel Chappell, Barry Logan, Rod Gullberg, J. Robert Zettl, Patrick Harding, Thomas Brettell for the State; even Michael Hlastala and Gerald Simpson for the defense -- not only professed no knowledge of computer science but affirmatively disavowed such knowledge.
No one from that community of forensic scientists put it more poetically than Robert Zettl, who declared that, for all he knew, “two magic rocks from Ireland banging together will give you a .10....”[7] Rod Gullberg, recognizing his limitations as a statistician and forensic scientist, specifically recommended that source code be independently verified.[8] That is what our Supreme Court has charged us to do here.

The Relevant Scientific Community
Thus, we leave the field of endeavor in which we examined the Alcotest last year -- that of the forensic science community -- and consider it in these new and closely aligned fields of computer science, electrical engineering, and software programming that encompass source code review.
The relevant witnesses presented by the State last year were Stephen Seidman, Norman Dee, and Hansuli Ryser. This year, the State called SysTest’s Bruce Geller and Norman Dee. Your Honor called Draeger’s Brian Shaffer. The defense called expert examiner John Wisniewski of BaseOne and standards expert Thomas Workman.

Source Code Witnesses
Geller, Wisniewski, and Shaffer had the advantage of having actually reviewed the source code itself, albeit from three distinctly different perspectives.
¨ Geller, hired by Draeger, was able to compile the code early with the help of Draeger’s Shaffer. He used certain automated tools for his examination, including something called Module Finder EX, a “proprietary” program created by SysTest which apparently has problems of its own given the way it has been developed in secret and not according to any recognizable standard. Your Honor may recall Geller’s lament when asked, “Were any development standards adhered to when Module Finder was built?” His response: “Sadly, not.”[9] It is ironic that Geller examined the secret Alcotest code with another secret program for which SysTest could only claim reliability by asserting that it is a trade secret and gave SysTest a competitive edge. Geller’s regrets Module Finder’s lack of standardization because of how hard it has become to maintain that program.
¨ Wisniewski began working on this project believing he was hired by the State. Later, he discovered otherwise. But, nonetheless, he conducted his review using automated tools much like SysTest. But Wisniewski used different automated tools -- notably, a program called lint, a generally available open-source tool which has been described as “verbose,” probably because it found so many errors. Coupled with his demonstrably superior practical experience in embedded system programming for applications from aerospace to washing machines, Wisniewski homed in on very significant specific problems in the Alcotest source code.
¨ Shaffer, the company man, is Draeger’s principle programmer of the application now before us. He uses no standard methodology. Indeed, his coding style seems to be de-evolutionary, given the way he has deleted headers within the code that would ordinarily provide signposts for others to follow. He has conceded to introducing unintentional error like the buffer overflow that Draeger created as a very helpful exhibit in this litigation. The high point of Shaffer’s experience with embedded systems programming prior to his employment with Draeger was in the model railroading field.
Geller, Wisniewski, and Shaffer all appeared to be credible. None had ever testified in court before. Their lack of familiarity with what has been described as this ancient form of Anglo-Saxon combat may have affected the way they prepared for or answered questions. But some specific comments about each of these witnesses are warranted:
¨ First, Geller: He was somewhat evasive when answering questions. He often paused for long periods before giving a response. He often disclaimed a challenge citing the limited scope of his assigned task. He often distanced himself from the report he and the others at SysTest wrote. One must question whether it is the opinion of Geller or SysTest by which we should be guided. It was awful troubling that he lacked command of the powers of two and did not know the definition of an average.
¨ Second, Shaffer: He appeared to respond credibly, even when constrained by his status as a Draeger employee. His responses seemed thoughtful and, for the most part, direct. Indeed, on cross examination, he disclosed errors that neither SysTest nor BaseOne detected -- most notably the algorithm that forced EC and IR results to agree when the EC value drifts too far aware from the IR value. His confession of engaging in questionable practices like deleting header information within the code seems borne more of ignorance than an intent to deceive. Like Geller, he had difficulty with the powers of two and the definition of an average.
¨ Finally Wisniewski: He appeared to be the most objective and credible in his remarks. He began his task under the mistaken impression that he worked for the State. He is the epitome of the independent software reviewer the Supreme Court probably had in mind when they ordered this remand. For the most part, he was able to document every error he discovered and reported about. His discomfort with the use of the term “standards” seemed more semantic than substantive. He preferred the term “developmental methodologies.” The latter term was more consistent with the way he himself reviewed and developed reliable code throughout his career.

Expert Witnesses
The remaining experts -- Norman Dee, Stephen Seidman, and Thomas Workman -- did not have the benefit of actually seeing source code, except for the few snippets offered in evidence. But Thomas Workman is probably the person who is most representative of what the relevant scientific community is for this case. He has more than 30 years experience working in high technology for various corporations in many capacities, including management, engineering, research, quality assurance, and software development.
¨ He has written source code and developed coding standards.
¨ He has used and applied standards in the course of source code review and vendor selection for such massive technology-based companies as Hewlett-Packard, Digital Equipment, Xerox, and Texas Instruments.
¨ As HP’s representative on the IEEE Computer Standards Board, he wrote and reviewed standards. He peer reviewed the work of Thomas McCabe, the man recognized by both BaseOne and SysTest, for developing ways to measure cyclomatic complexity.
¨ For Digital, he performed ISO 9000 certification for a major corporation with operations here and in Scotland .
¨ He has worked with embedded systems dependent on sensors, much as the Alcotest is dependent on sensors.
¨ A major scientific principle in the field, “Workman’s Law,” is named after him!
¨ He has testified not only in courts but also before Congress as an expert on computer software issues.
¨ He is unrebutted by anyone else who has testified in this hearing.
Workman also provides the added credential of patent attorney, adding much depth to his weighty opinions, which Your Honor should not dismiss.
Stephen Seidman testified last year about source code with errors. Your Honor stated:
¨ “If there were errors in the software, Seidman would want to know about them as they would raise questions in his mind about the instrument's accuracy....”[10]
¨ “When shown several AIRs with apparent errors, Seidman said that he would want to understand the reasons for them before he gave an opinion on the accuracy of New Jersey 's breath-testing program....”[11]
Norman Dee, on the other hand, still holds the opinion that source code review is unnecessary and minimizes the importance of the reviews done for the present hearings. This view is clearly at odds with the instructions handed down from our Supreme Court in this case.

General Acceptance Defined
Now that we have defined the scientific community and discussed how they are represented in this case, we can ask: How does a court determine what scientific reliability is, and what are the hallmarks of general acceptance in this community?
To answer this question, let us examine what science and the scientific method is. Scientific method rests on a foundation of testing, standards, and peer review and publication. The U.S. Supreme Court described scientific method this way:
¨ Testing:
Scientific methodology today is based on generating hypotheses and testing them to see if they can be falsified; indeed, this methodology is what distinguishes science from other fields of human inquiry.[12]
¨ Standards:
[T]he court ordinarily should consider the known or potential rate of error...and the existence and maintenance of standards controlling the technique's operation....[13]
¨ Peer Review and Publication.
Another pertinent consideration is whether the theory or technique has been subjected to peer review and publication.”[14] This is because “submission to the scrutiny of the scientific community is a component of ‘good science,’ in part because it increases the likelihood that substantive flaws in methodology will be detected.[15] **** The fact of publication (or lack thereof) in a peer reviewed journal thus will be a relevant, though not dispositive, consideration in assessing the scientific validity of a particular technique or methodology on which an opinion is premised.[16]

Quality of Proof
Our cases hold that “a belief that the device is broadly accurate is not sufficient.”[17] “Proving general acceptance ‘entails the strict application of the scientific method, which requires an extraordinarily high level of proof based on prolonged, controlled, consistent, and validated experience.’"[18]
All four pillars -- prolonged, controlled, consistent, and validated experience -- must stand to support a finding of scientific reliability by that highest of the civil burdens of proof, clear and convincing evidence -- a standard of proof defined as:
evidence that “'produce[s] in the mind of the trier of fact a firm belief or conviction as to the truth of the allegations sought to be established,' evidence 'so clear, direct and weighty and convincing as to enable [the fact finder] to come to a clear conviction, without hesitancy, of the precise facts in issue.'"[19]

Burden of Proof
“[T]he responsibility for establishing all conditions as to the admissibility of [Alcotest] results is properly allocated to the State.”[20] And, by extension Draeger, thanks to our Supreme Court’s order permitting Draeger to intervene. As we will see, they have failed to meet that burden. While the defense has no burden whatsoever, we have, nonetheless, not only called the code and Alcotest into question; we have affirmatively demonstrated that it is unreliable and should not be used.

Methods of Proof
A proponent of a newly-devised scientific technology can prove its general acceptance in three ways: (1) by expert testimony as to the general acceptance, among those in the profession, of the premises on which the proffered expert witness based his or her analysis; (2) by authoritative scientific and legal writings indicating that the scientific community accepts the premises underlying the proffered testimony; and (3) by judicial opinions that indicate the expert's premises have gained general acceptance.[21]
Let’s review these three methods of proof in the present case in reverse order.
We see no judicial opinions about Draeger source code reliability at all. That is because this case is the first of its kind. Other jurisdictions are fighting over discovery of source code. Some have even ordered the production of code. But nowhere else has a review of code taken place as it has here.
Similarly, there are no authoritative scientific or legal writings about Draeger source code. But there is ample authority in the scientific community about what makes source code and computer programs reliable. One need look no further that the bibliography included with Workman’s report to understand the technical and scientific underpinnings of what Wisniewski called proper coding methodologies.
Finally, we examine expert testimony. The great weight of credible expert testimony in this case clearly demonstrates what it takes for a computer program (as represented by source code) to be considered scientifically reliable.

The Application of Standards
For the computer science community, the hallmarks of reliability are embodied in the application of standards -- or more descriptively -- standardized developmental methodologies. John Wisniewski, in the context of his experience and the present code review, discussed such standardized developmental methodologies as yielding, in a technical sense, more reliable code. Tom Workman, from his career experience, told us of how standards were developed, how they are employed, and what makes them scientific.
He told us how standards take into account the first requirement of science by requiring the statement of hypotheses through documentation -- with a requirements document at the outset of coding and further documentation for error detection and error correction.
He told us how standards were developed in a collaborative fashion, subjected to rigorous peer review, and requiring a high degree of consensus. As I recall, the degree of consensus required was something on the order of 80 percent. Dissenters had to explain their dissent, and those views were given full consideration before their proposals were either accepted or rejected.
Standards were developed by industry, IEEE -- not imposed by governments. But governments do adopt them as part of their product specifications when a high degree of reliability is required. Standards are used to keep rockets from blowing up and satellites from crashing. Standards keep hearts beating and help motorists find their way with GPS technology. Standards are important because we know that source code, like human beings, can never be perfect. But, through the application of standards, source code can be scientifically reliable.
Standards have been in use at least 30 years. While there may have been some debate whether coding standards were necessary 20 or 30 years ago, there is no true debate any more. If an application is sufficiently important, it must be developed and maintained according to some standard. There is nothing new or novel about this concept. The use of standards is a prerequisite to a determination that source code is scientifically reliable.
The application with which we are concerned is clearly important. Evidence developed with this technology will send people to jail, particularly in the context of per se offenses under N.J.S. 39:4-50. I daresay it already has. The importance of the application here is more on par with airplane landing gear, pace maker functioning, and satellite navigation than it does with a model train whistle or even a voting machine.
So, would Draeger’s version 3.11 software in use in its Alcotest 7110 MK-III-C be considered generally acceptable for such an important application? The answer is a resounding, NO. This is so for many reasons, including these:
¨ There is no sign of any standard developmental methodology ever being used. If software development standards were like a building code, Draeger’s code would be a slapped-together slipshod tumbled-down shack.
¨ There is no documentation -- no initial requirements document, no pseudo-code, nothing. Norman Dee spoke of pseudo-code, but his definition of pseudo-code differs from that of IEEE. For IEEE, pseudo-code is prospective and the result of prior planning. For Dee , pseudo-code is retrospective and the product of reverse engineering.
¨ Draeger’s source code is too complex and disorganized. As changes are made from one version to the next, errors will be inserted and the code will become more and more unreliable with each revision. It contains blind alleys within a maze of unused, walled-off, and errant code.
¨ The range of accepted deviation was increased to mask potential error. In New Jersey , the legal standard for agreement of results from two breath samples was .01, then 10 percent. That increased to the greater of .02 or 20 percent, effectively eliminating any need for requiring third test verification.
Furthermore, both SysTest and BaseOne found specific problems in the code that raise serious questions as to its reliability. These include:
¨ The disabling of fundamental safeguards.
¨ Incorrect functions as fundamental as averaging.
¨ Arbitrarily substituting data values at various points.
¨ Forcing drifting fuel cells to agree with the infrared sensors, thereby putting the lie to the claim that these two technologies, IR and EC, cross check and verify each other.
My colleagues have already discussed most of these problems, they are extensively catalogued in the reports from BaseOne and SysTest, and they were extensively discussed and explained in testimony from Shaffer, Wisniewski, and Geller.

The Complexity Problem
Let me focus a little now on complexity. The Alcotest source code is much too complex -- a complexity which invites error both in the original coding and in updates to the present code. Both SysTest and BaseOne found complexity to be a real problem undermining any finding of reliability.
McCabe complexity metrics tell us just how complex Draeger’s source code is. Complexity levels should exceed no more that 10, with a level less than 7 recommended, according to SysTest. After all, software engineers, being human beings, can only track so many things at one time. With most of Draeger’s source code modules well exceeding this level, the code is prone to corruption and unpredictable execution. Indeed, one snippet of the code produced by the 3.11 proponents shows how Draeger’s programmer Shaffer unintentionally inserted error when he “upgraded” the source code from version 3.8 to 3.11 by failing to correct buffer capacity and thereby creating the famous buffer overflow.
The prospect of error insertion is very real, given that source code revisions must be made to the present program to account for several factors, including:
¨ The change in Daylight Savings Time.
¨ The need to list the temperature probe serial number and probe value of that temperature probe on any report where such information is relevant, including the AIR, New Standard Solution Change Report, and Calibration, Control Test, and Linearity Reports.
¨ The need to “deploy a software program to create and maintain a centralized data base of digital information stored by all Alcotest 7110s throughout the State.”[22]
Further changes to source code will be inevitable as the law and other circumstances change.
Adding to this complexity is the presence of an excessive number of global variables and a rat’s nest of excess, irrelevant, and purportedly unused code. Indeed, between 40 and 60 percent of the code appears to be irrelevant to the hardware’s functioning. This isn’t just bad housekeeping. These excessive bits and pieces of superfluous code are invitations for error and unnecessarily expose anyone tested on the Alcotest to undetectable error. As Thomas Workman said of our Middlesex County data, the 1900+ alcohol influence reports in that universe appear to be 99 to 100 percent reliable, but in actuality, none can be considered reliable. The notion, as Your Honor had held, that “the Alcotest 7110 uses newer technology and is more transparent because it produces a printout,”[23] is simply incorrect.

The Institutional Problem
Complexity and errors are certainly real issues compromising the scientific reliability of Alcotest source code. So, too, is Draeger’s failure to document its coding processes and its failure to use standards. But the biggest problem of all is institutional. Draeger’s corporate culture elevates:
¨ False appearances above scientific reliability.
¨ So-called trade secrecy above objective verification.
¨ Profits above justice.
Compounding Draeger’s culture of concealment is our own Attorney General’s culture of ignorance. While the AG’s office knew it was embarking into a novel scientific field with equipment dependent on a computer, it failed to consult anyone with the requisite expertise in computer science -- a negligent lack of inquisitiveness. They not only failed to see any problems. They did not even look.
Draeger can implement standards, but that implementation may fail if their culture of concealment persists. The State may find an appropriate breath testing instrument, but only if they open their eyes and look the right way and in the right places.

How Standards Fix the Problems
Despite these complementary cultures of concealment and ignorance, perhaps Draeger and the State, respectively, can save the Alcotest -- but not with its present source code version. It is impossible to make the Alcotest using version 3.11 reliable. If throwing all readings out in pending cases is “throwing the baby out with the bath water,” that is what must be done.
To save the Alcotest -- to make it scientifically reliable -- to avoid the necessity of serial courtroom proceedings to determine whether the device is scientifically reliable -- Draeger, with direction from the State, must adopt recognized standards. They must make sure to take a scientific approach to source code development, error detection, and error correction -- just as I am sure they do with their medical devices. Standards will force Draeger to:
¨ Assure that, in initial coding, most common errors are avoided.
¨ Assume that all released code is still imperfect.
¨ Institutionalize a systematic search for imperfections.
¨ Require documentation at both implementation stage and for each correction.
In short, the Alcotest source code must be rewritten from scratch and deployed correctly, scientifically, according to a recognized standard, and in a traceable provable way. Only then can it be considered scientifically reliable.

Conclusion
We have learned that the Alcotest 7110 using firmware version 3.11 is just as likely to produce results that inculpate the innocent and exculpate the guilty. We know that the code, and, thus, the instrument itself, is scientifically unreliable.
The right thing to do is to throw out all of its results from every case now pending.
But knowing what the right thing to do is, and doing it, are often two different things. Factors beyond the realm of objective scientific principles may affect these decisions.
I fear that extraneous unrelated facts that have nothing to do with whether the Alcotest is reliable will dictate an unjust outcome to this case. Those facts relate to the way both the State and our Supreme Court have handled the Alcotest and disserved the public to date.
The State selected, approved, and implemented the Alcotest program improperly by:
¨ Formulating a bid specification that permitted only one manufacturer’s product and precluded any competition in the selection process.
¨ Delaying the replacement of the antiquated Breathalyzer until it became so out of date that it could no longer be equipped or maintained.
¨ Promulgating regulations that handcuffed it to the Alcotest.
¨ Rolling out the Alcotest in such a reckless and overpowering way that it is now the only technology available for breath testing in most of New Jersey .
¨ Ordering arbitrary changes to the source code such that range of agreement between breath test results would obscure issues third tests might otherwise flush out.
The Supreme Court disregarded well-established evidentiary principles and constitutional protections by:
¨ Issuing a premature order in January 2006 that requires municipal courts to receive Alcotest results.
¨ Entering this Order sua sponte without providing the parties with an opportunity to be heard.
¨ Encompassing within the Order not only the present parties to the above captioned matter but all similarly situated defendants [i.e., those defendants with cases involving Alcotest 7110 breath test evidence].
¨ Requiring defendants to face conviction based on unreliable incompetent evidence.
¨ Creating a presumption of guilt based on presumably incompetent evidence.[24]
¨ Precluding the right of defendants to timely confront this evidence against them.[25]
¨ Causing undue prejudice and unfair trials.
¨ Improperly imposing collateral consequences like insurance premium increases, job loss, and driving privilege revocations for out-of-State drivers.
¨ Unduly delaying disposition, implicating the right to a speedy trial.[26]
As a result:
¨ Innocents have faced conviction based on this incompetent evidence.
¨ Guilty people have been released, also based on this incompetent evidence.
¨ Those whose driving privileges should have been revoked were allowed to drive.
¨ Those whose driving privileges should not have been revoked have lost jobs, gone broke, failed their friends and families.

I am concerned that the tragic and untimely death of a young woman by another woman whose DUI conviction was stayed based on the Supreme Court’s Order in this case will lead to an over-reaction.

I am concerned that, given the way the State and the Supreme Court have created an almost untenable situation in the administration of DUI defendants, this Court will “throw the baby out with the bath water” by whitewashing the terrible truth that was uncovered in this case and, to save face, convict innocent people.

Unfortunately, there is no easy, face-saving way to rationalize these extraneous mistakes away. This Court, the Attorney General, can only acknowledge that these mistakes were made and make amends by learning from their mistakes.

Relief Requested

The only reasonable recommendations to make to the Supreme Court are these:

¨ Declare the Alcotest 7110 using firmware version 3.11 unreliable and unscientific.
¨ Exclude all Alcotest results in all prosecutions affected by the Supreme Court’s January 2006 Order.
¨ Vacate all refusal convictions where there was some indication that the defendant blew into the machine.




--------------------------------------------------------------------------------

[1] SMR45.
[2] SMR233.
[3] SMR45.
[4] Emphasis added.
[5] State v. Harvey, 151 N.J. 117, 169 (1997), quoting Frye v. United States, 293 F. 1013, 1013-14 (D.C.Cir. 1923) (emphasis added).
[6] State v. Harvey, 151 N.J. 117, 170 (1997).
[7] 15T7-21/23.
[8] 13T52-13/24, 13T53-24/54-4; D-16
[9] 72T155-8/10.
[10] SMR108, citing 18T67.
[11] SMR108, citing 18T77, D-59, D-60, D-61, D-62, D-63, D-64).
[12] Daubert v. Merrell Dow Pharmaceuticals, Inc., 509 U.S. 579, 593, 113 S.Ct. 2786, 125 L.Ed.2d 469 (1993).
[13] Id. , 509 U.S. at 594 (citations omitted).
[14] Id. , 509 U.S. at 593.
[15] Id.
[16] Id. , 509 U.S. at 594.
[17] In re LTI Marksman 20-20 Laser Speed Detection System, 314 N.J.Super. 211, 230 (Law Div. 1996) [“Laser I”].
[18] State v. Harvey, 151 N.J. 117, 171 (1997), quoting Rubanic v. Witco Chemical Corp., 125 N.J. 421, 436 (1991).
[19] In re Seaman, 133 N.J. 67, 74 (1993) (citations omitted).
[20] Romano v. Kimmelman, 96 N.J. 66, 91 (1984).
[21] State v. Harvey, 151 N.J. 117, 170 (1997).
[22] SMR247.
[23] SMR108, citing 57T23-24.
[24] Romano v. Kimmelman, 96 N.J. 66, 90 (1984). See In re Winship, 397 U.S. 358, 364, 90 S.Ct. 1068, 25 L.Ed.2d 368 (1970).
[25] See Pointer v. Texas , 380 U.S. 400, 406, 85 S.Ct. 1065, 13 L.Ed.2d 923 (1965); see also Crawford v. Washington, 541 U.S. 36, 59, 124 S.Ct. 1354, 158 L.Ed.2d 177 (2004).
[26] See State v. Farrell, 320 N.J.Super. 425 (App.Div. 1999); Barker v. Wingo, 407 U.S. 514, 92 S.Ct. 2182, 33 L.Ed.2d 101 (1972).