• Have us give input into schedules. We know best how much work an analysis is going to take. And some of us have lives outside of work (not me, but I’ve heard that others do). Don’t give us a schedule without our input and expect us to meet it.

• Don’t hire us just to keep us off the other side. I’ve had this happen. It’s flattering, but it’s also unethical. I need to make a living. Also I will never work for you again, and I will warn my colleagues about you.

• Involve us with crafting the strategy. Don’t let us work in the dark and then complain, for example, that our invalidity argument hurts the non-infringement argument or vice-versa. And by the way, a great argument for one will always make the other much more difficult to show.

• Involve us with claim construction. We have the appropriate experience to figure out a decent claim construction. Too often I’m called into a case where the claim construction makes little sense to me. I need to be educated about how the claims are construed and then I need to see if I can work with them. Sometimes adding or removing a word from the claim construction would make things significantly easier for me to understand and explain to the judge and jury.

• Give us enough time to do our jobs. Maybe this is a pipe dream. Lately, cases have been more and more compressed and I’m brought in later, probably to save costs. But it hurts the case and stresses us out.

• Don’t antagonize us. We’re they guys who are going to help your client by clarifying their position and explaining difficult concepts to the judge and/or jury. You don’t want us ticked off, even if we really are stupid jerks. You want us in a good frame of mind and happy about what we’re doing. At least until we’re done testifying.

• Explain your positions to us patiently. If you can’t get us to understand it and adopt it, how can you get a judge or jury?

• Don’t tell us we have to adopt your positions or we’ll lose the case. We’re independent and unbiased. The threat of losing the case is not a reason for us to support your position, and stating this can come back to haunt both of us eventually.

• If things aren’t going well, meet face-to-face. It’s easier to communicate about difficult subjects. It’s easier to wave hands, draw diagrams, point to things. And it’s more likely for both to see each other as humans, not someone being difficult.

• Don’t expect us to understand all the legal issues. I’ve met lawyers who didn’t understand all the legal issues. I actually do understand legal issues more than most experts because of my experience and my writing on the topic. Yet there are still gaps. And the lawyers can disagree. I’ve been in many long sessions where lawyers argued about legal issues.

• Don’t believe you understand all the technical issues. Some of the lawyers I’ve met were once great engineers. Others have no engineering experience whatsoever. Some will take my word completely and others will fight me. I don’t mind reasoned debate—in fact I enjoy it. But remember that my understanding of the technical issues is ultimately what I will present in my reports and my testimony.

• Be clear in your instructions. We know you’re in a hurry, but this is critical to getting good information. I’ve had cases where I got a quick call to do some analysis and then spent the weekend setting up equipment, getting results, and writing a report, only to find there had been a miscommunication about what was needed. Sure I get paid per hour, but I’d still like to know I’m doing something useful. I’m sure you and your client prefer that too.

• Have us sit in on depositions. We can add a lot of knowledge and we can help craft the direction of the questioning. I was in one deposition where, searching the Internet, I found an expert’s presentation slides promoting a software method while she was testifying she would never ever use such an “unreliable” method. I’ve also had lawyers call me after a “very successful” deposition where they thought they’d uncovered some really useful facts but were asking questions about the wrong technology.

• Don’t write the reports and expect us to just sign it. Our reputations and careers are on the line, not yours. Unfortunately, some experts do this and collect their checks. I won’t and neither will any expert worth his or her hourly rate.

• Expect us to sleep some time. OK, the lawyers themselves get little sleep during a case. Me too. I just prefer that you act as though you care about my getting rest even though we both know I won’t. So don’t tell me to be available at midnight, ask me if I can please make myself available at midnight even though you know it’s a burden. It just sounds nicer.

• Pay us on time or be honest about any problems. Sometimes clients run into financial trouble. I prefer to work for a client who is honest about financial trouble than one who constantly tells me “the check is in the mail.” Usually this is an issue with the client not the lawyer, but I’ve had lawyers misplace my final invoice, simply because they had moved onto other more pressing matters. My payment is a pressing matter, and a late or missing payment means I’m unlikely to be available the next time you need my expertise.

• Don’t negotiate our fees after the case is over. This is just poor business practice and makes me not want to work with you again. The time for negotiation is before hiring me, not after I’ve put in time on the case.

• Remember that our job is to be honest and unbiased. Expect us to point out the bad along with the good. If we find your client’s case doesn’t have merit, at least be happy we discovered that before the other party’s expert informed you at trial. You can settle early or limit the damages or just know that you did the right thing.

Overall the book covers the following topics:

• Key concepts of software intellectual property
• Comparing and correlating source code for signs of theft or infringement
• Uncovering signs of copying in object code when source code is inaccessible
• Tracking malware and third-party code in applications
• Using software clean rooms to avoid IP infringement
• Understanding IP issues associated with patents, open source, and DMCA

You can purchase your copy from Amazon.com here.

Which is Right For You?

Which product is right for you, CodeSuite or CodeSuite-LT? Click here for a table that compares the features of both programs so you can choose the right solution.

Second, Zelnick doesn’t foresee the possible ultimate business model of Righthaven. While I don’t agree or disagree with Righthaven’s motives, I believe I see where they’re going. Jerome Lemelson was perhaps the first patent troll, but definitely the first to reach $1 billion in personal fortune from his effort. My understanding is that he started by bringing actions against small companies that could not easily defend themselves and Japanese companies that didn’t understand U.S. patent law. These companies saw his royalty fees as small compared to the costs of hiring lawyers to study and defend the patent infringement suits he brought. After amassing a huge war chest, Lemelson went after bigger and bigger companies and sought bigger and bigger payments. The more capital he had, the easier it was to win these battles.

While Righthaven will probably never collect the multimillion dollar awards that Lemelson did, consider that nearly everyone in the world writes. There are thousands of novelists, thousands of journalists, thousands of researchers, and millions of bloggers. And copyright also applies to artists, filmmakers, and computer programmers. Righthaven, and companies like it, can potentially collect more than Lemelson even hoped for, and at less expense.

I believe that Righthaven and its business model should not be underestimated. The solution to protecting yourself is more complex than simply not copying. The exciting part is that this new business model will create new areas of legal effort and will require the best technology to allow the protection of both copyrights and free speech.

When using the RPG, an expert selects the type of case, type of report, types of technologies involved, types of tools used, and expert background profiles from a GUI. Then a Microsoft Word draft report is generated that includes all of the selected generic information intermixed with blank sections where case-specific information should be filled in manually.

Currently, many experts either dig through their prior works to find specific descriptions or write them from scratch each time. Maintaining a library of generic report elements is a challenge, especially when multiple experts are involved. RPG acts as a version control system between multiple experts who can upload and download detailed descriptions of experts, technologies, and tools from a central server. The reports are generated according to specific formats, so an entire team of experts can easily produce reports that are consistently formatted with the most up-to-date descriptions.

RPG also keeps synced descriptions of CodeSuite, so it can include the most up-to-date descriptions and pricing of the tools without having to search the S.A.F.E. website or CodeSuite help files.

If you’re interested in trying out RPG, contact our Sales Department.

Still confused? So are many others. Except for Bilski who now knows for sure that he doesn’t have a patent. Looking at it as an inventor, I see that the court has broadened the scope of patentable materials, which is good, but has made the test for patentability muddier which means I will spend even more time and more money arguing with patent examiners. Looking at it as an expert witness for patent litigation, this ruling is sure to cause a lot more disagreements, which means a lot more litigation, which means a lot more business for me.

An excellent discussion of the Bilski ruling can be found at Patently-O, written by Dennis Crouch, Associate Professor at the University of Missouri School of Law. His regular columns on patents are the best ones available anywhere.

You’re probably wondering what is the difference between CodeMeasure and CodeCLOC. CodeMeasure is a simple, inexpensive program for generating the CLOC measurement statistics for multiple versions of a program. CodeCLOC, intended for litigation, compares only two versions of code but produces a detailed database of results that can be further filtered and analyzed using CodeSuite or your own custom tools. The results from CodeCLOC can be presented in court and the CodeCLOC database can be presented to the opposing party for verification.

CodeSuite 4.0 also has a few other nice features including a revamped user interface. There’s also a new function to generate statistics from any CodeSuite database and the command line interface has been enhanced for integrating with other programs. CodeSuite 4.0 is available for download here and can be purchased on a term license or project basis. CodeCLOC is priced at $20 per megabyte. A one year term license for CodeSuite is $100,000.

This always sounded intriguing, but I wondered whether anyone had ever tested this theory. We could find no articles or papers on the subject, except for one inconclusive paper, and I dreaded to think that some programmer was convicted based on an untested theory. I decided to have my consulting company, Zeidman Consulting, do some carefully controlled research. If the results turned out well, SAFE Corporation would add whitespace pattern algorithms to CodeSuite to further enhance its ability to detect copying.

Our results were published in a paper entitled Measuring Whitespace Patterns as an Indication of Plagiarism that was recently presented at the ADFSL Conference on Digital Forensics, Security and Law. Our results are summarized in the final paragraph:

This whitespace pattern matching method can be used to focus a search for evidence of similarity or copying, but this method cannot stand by itself.

What we discovered is that even very different files have often have similar whitespace patterns. At Zeidman Consulting we’ve used whitespace patterns to confirm copying that was already detected through the use of CodeMatch to find correlated programming elements. In those cases, the whitespace patterns offered further confidence in our findings and in some cases showed which program had been developed first. For a copy of the paper, email us at info@SAFE-corp.biz.

Our next research project is to look at sequences of whitespace within files. Maybe there we’ll find some clues to copying. But for now our results show that whitespace patterns without any other evidence should not be used to determine that copying occurred.

Actually no. The real inventors of the digital computer were physics professor John Atanasoff and his student Clifford Berry who created the first digital computer in a laboratory at Iowa State University. The ABC (“Atanasoff-Berry Computer“) was built in 1939, yet by the time of ENIAC’s introduction to the world, the ABC had been forgotten. What had happened? World War II broke out and the University of Iowa as well as Atanasoff and Berry simply didn’t realize the power of what they had created. Atanasoff was called up by the Navy to do physics research, eventually participating in the atomic bomb tests at Bikini Atoll.

When Atanasoff returned to Iowa state he found that his invention was gone to make room for other equipment—because the ABC was built piece-by-piece in the laboratory, it was too big to move out and so it had to be dismantled. Iowa State had decided that a patent was too expensive and so never filed one. John Atanasoff went on to gain recognition for a number of inventions involving physics, but the ABC was mostly forgotten.

In the 1970s there were a handful of companies that saw the great potential in the electronic computer. Sperry Rand Corporation, which was formed through a series of mergers and acquisitions including the Eckert–Mauchly Computer Corporation, held U.S. Patent 3,120,606 for the digital computer. In 1973, Sperry Rand sued Honeywell, Inc. and Honeywell reciprocated. Thus began one of the most important intellectual property cases in history.

During the research for this case, Honeywell found out about John Atanasoff and the ABC, which became pivotal information. The case was tried for 7 months after which Judge Earl R. Larson handed down his decision that stated, among other things, that the Eckert-Mauchly patent was invalid.

Some people have disputed this finding, arguing that this was a “legal” finding or a “loophole” or that a lawyer or a judge simply couldn’t understand the complex engineering issues involved. Here’s my take on this.

1. Both sides had a lot of time, and access to technical experts, to make the best case they could.
2. So much was at stake, and a huge amount of money was spent to bring out the truth. Both sides had very significant resources. If a case with this much at stake could not convince a judge after seven months, then there is little hope for any IP case.
3. Evidence was found and witness verified that John Atanasoff had attended a conference in Philadelphia where he met John Mauchly and described his work. He then invited Mauchly out to Iowa where Mauchly spent several days examining Atanasoff’s computer and many late nights reading Atanasoff’s technical specifications. Letters were produced, signed by Mauchly, that thanked Atanasoff for his hospitality and for the tour of his amazing invention.
4. Mauchly testified at the trial. He admitted that he had met Atanasoff and eventually admitted that he had examined the ABC and read its specification.
5. Mauchly and Sperry Rand Corporation were challenged to produce a single piece of evidence that Mauchly or Eckert had written about or researched digital electronics before Mauchly’s meeting with Atanasoff. The best Mauchly could do was produce a circuit for a model railway flasher that he claimed was a binary counter—it counted from 0 to 1 and then back to 0.

In fact, it became clear that Mauchly and Eckert attempted to claim much more credit than they deserved and tried to deny credit to others. They had actually greatly improved on Atanasoff’s original design. Had Eckert and Mauchly been more humble, had they added Atanasoff’s name to their patent, had they patented their own improvements instead of the entire invention, they may have given Sperry Rand the most powerful IP in technology history. Instead the invention of the computer entered the public domain without restriction, and the rest is history…

For a good book on the subject, read The First Electronic Computer: The Atanasoff Story by Alice R. Burks and Arthur W. Burks.