Most lawyers know the importance of treating experts with respect. Even if we turn out to be ignorant, arrogant, immature idiots, we hold the keys to presenting the facts and the analysis that will win your client’s case or at least put it in the best light possible given all of the facts. If we’re going to testify, you want us feeling good about it, about the client, about you, and about ourselves. Most attorneys know this but some, in the emotion of the “battle,” forget this. Here’s a checklist to serve as a reminder.

• 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.

When I began writing my book on software intellectual property, I often needed definitions of terms, lawsuit citations, technical references, and historical facts. In those long ago pre-Internet times, this meant reserving whole days at local libraries to sort through catalogs, walk through mazes of bookshelves, run my fingers along Dewey Decimal-coded book spines, pull heavy volumes off the shelves, spread them across big wooden tables, flip back and forth between indexes and pages, and skim dense paragraphs of text. Now I just Google, and usually it’s Wikipedia that comes up.

As I wrote my book it became filled with references from Wikipedia. Some of the information I knew was correct but I needed a formal reference and Wikipedia seemed good enough. Other information I could verify at multiple sites, but the Wikipedia definition was always concise. I had been told by many attorneys that Wikipedia references were not considered legitimate in court, and I never use them in expert reports for litigation, but I figured it was good enough for my book. It was only when one of the reviewers pointed out that using Wikipedia would hurt the reputation of my book, especially among lawyers, that I gave it a second thought. I went back and found alternate references and though the main concepts that I was referencing in Wikipedia were essentially correct, it was the details that Wikipedia often got wrong.

And I knew this fact already. My Cornell roommate Rob Smigel had gone on to be a fairly famous comedy writer for Saturday Night Live. The Wikipedia page originally said he had graduated from Cornell. I figured this needed correction, because Rob dropped out (before nearly failing out) and transferred to NYU where his dad sat on the board. Rob’s story is actually that old cliché where his dad insisted he become a dentist like himself, but Rob only wanted to be a comedian, a career that his dad strongly disapproved. My corrections to the page were regularly removed because I couldn’t document this fact with external references, yet most of the other information in the bio was unreferenced.

This points out one significant problem with Wikipedia. In the early days, people entered what they wanted with little if any fact checking required. Eventually those early pages, and there are probably millions of them, became accepted as incontrovertible fact. I have at least one friend whose Wikipedia page was created by colleagues as a joke, yet it gets quoted as true.

Later I submitted a reference to a Rolling Stone interview with my roommate Rob Smigel where he mentions not completing a degree at Cornell, but somehow a Wikipedia editor did not find even this credible enough and edited my sentence into a short phrase that has since been removed. In fact, as of today all references to Cornell have been removed from Rob’s bio even though he attended for two years.

So this points out yet another significant problem with Wikipedia. There are now editors who have taken it upon themselves to be the correctness police. They go about removing edits of others if they don’t conform to their own beliefs. Many of these editors boast tens of thousands of page edits. Wikipedia has set up rules for editing, but there is only a long process and many level of effort to disputing an edit, that still rely on these same biased Wikipedia editors who do not necessarily have any expertise in anything let alone the subject under consideration. In fact, although my company and my software is the most widely used copyright infringement detection software in court cases, even simple links to our website in Wikipedia have all been eventually removed by an editor who says this is self-promotion. Why is self-promotion bad if the facts are provably true?

Even Wikipedia states that the information on its site may be incorrect, as confirmed in this Wikipedia page about using Wikipedia¹:

Wikipedia’s most dramatic weaknesses are closely associated with its greatest strengths. Wikipedia’s radical openness means that any given article may be, at any given moment, in a bad state: for example it could be in the middle of a large edit or it could have been recently vandalized…

Where does Wikipedia stand in courts? There have been many references to Wikipedia in court cases, but the rule is that it’s a bad thing to do. Recent studies have shown that courts are allowing Wikipedia references much less than in the past^{2, 3, 4, 5}.

So my advice is that Wikipedia is great for cocktail party banter, but don’t rely on it for critical facts. The anonymity of its contributors, the poor fact-checking on the early contributions, and the bias of unqualified volunteer editors make it an increasingly inaccurate source that is losing its initial attraction for many.

Footnotes:
1. Wikipedia:Researching with Wikipedia
2. The Citation of Blogs in Judicial Opinions
3. Badasa v. Mukasy, 2008
4. Bing Shun Li v. Holder, 2010
5. Cohen v. Google, 2010

My book on software intellectual property, a labor of love (and hate) for the last two years, has just been published by Prentice-Hall. The book is intended for several different audiences including computer scientists, computer programmers, business managers, lawyers, engineering consultants, expert witnesses, and high-tech entrepreneurs. Some chapters give easy-to-understand explanations of intellectual property concepts including copyrights, patents, and trade secrets. Other chapters are highly mathematical treatments describing quantitative ways of comparing and measuring software and software IP. The first chapter of the book outlines which chapters are most important for the different audiences.

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.

In a recent editorial in the Wall Street Journal entitled Digital Innovators vs. the Patent Trolls, Peter Huber, a senior fellow at the Manhattan Institute, argues that software patents are the shotguns that kill innovation (my analogy) and that non-practicing entities (NPEs derisively referred to as “patent trolls”) are pulling the trigger (again, my analogy). I disagree.

Peter Huber makes some contradictory and misleading arguments where he claims that non-practicing entities are ruining innovation in America. On the one hand, he acknowledges that only a small percentage of patents, roughly 2% by his own estimate, end up court. Yet he also believes that “[o]ur patent laws have drifted way off course.” He states that “[t]he patent office now grants more than 4,000 patents a week” but neglects to mention that the total number of patent applications and the number of patent rejections have both similarly risen. And one major goal of USPTO director David Kappos, appointed in 2009 by President Obama, is to reduce the backlog of 1.2 million patents around the time he took office. Many more patents are being submitted and examined than ever before-—a sign of the vigorous spirit of innovation in America.

Dr. Huber’s logic is equally baffling when he claims that companies rarely sue each other but that companies spend lots of money collecting patents. Why would a company spend so much on worthless patents? Patents are used to protect their investments in technology, and the vast majority of patent lawsuits are between large corporations like the recent ones between Oracle and Google, Apple and Samsung, Dish Network and Tivo, and many, many others.

Dr. Huber claims that the Supreme Court’s decision in Bilski v. Kappos somehow agrees with his view that patentability must be restricted. In fact, this decision did just the opposite. While business method patents were rejected by the court, as expected, the patentability of software was expanded.

Dr. Huber claims that plaintiffs in the Eastern District of Texas almost blindly reward plaintiffs in patent cases, but a recent study by the Stanford
Intellectual Property Clearinghouse showed that plaintiffs in that jurisdiction win only 40.3% of the time.

Finally Dr. Huber gets to his point. Patent examiners and juries just aren’t smart enough to figure out which patents are good and which are “sketchy.” So instead, he wants the patent system changed to restrict inventors from owning the fruits of their intellectual labor. As an individual inventor I object to his condescension and to his attempt to limit this constitutionally protected driver of American innovation.

S.A.F.E. has recently announced the release of DocMatch, a new tool for comparing all kinds of documents to find plagiarism. Our unique, patented technology has proved very useful for finding copied computer code in court. We decided to apply our technology to general documents like articles, papers, and novels. There have been a few cases where we built custom applications to compare written engineering specifications. The results were very useful. In one case, finding copied but modified software specifications gave clues that showed how one company copied another’s software.

DocMatch can be licensed as the full version or the LT version. The full version is the professional tool. It creates a database containing matching elements between two sets of documents. The full version can automatically search the Internet for all references to commonly used words and filter them from the database. Also, sophisticated statistics can be extracted from the database. The full version costs $150 for a one-year license. The LT version produces an easy-to-read HTML report showing words, sentences, and paragraphs that are identical or similar in every pair of documents. The LT version costs $30 for a one-year license. Register to download your copy here.

Antivirus company McAfee and R&D company SAIC recently published a report entitled Underground Economies, a study of corporate IP theft. According to the study, many cyberthieves now see stealing IP as more profitable than credit card theft and identity theft. According to the study:

In the past, cybercriminals targeted personal information such as credit cards and social security numbers, which were then sold on the black market. Now, these criminals understand that there is much greater value in selling a company’s proprietary information to competitors and foreign governments. For example, a company’s legal documents can fetch far more money than a list of customer credit cards.

The cyber underground economy has shifted its focus to the theft of corporate intellectual capital–the new currency of  cybercrime. Intellectual capital encompasses all the value that a company derives from its intellectual property including trade  secrets, marketing plans, research and development findings and even source code. For example, Operation Aurora, a targeted attack on Google and at least 30 other companies, represented a sophisticated attack designed to steal intellectual capital.

Some of the more interesting findings are:

• Theft of corporate intellectual property is “the new currency of cybercrime.”
• Some governments support or even conduct theft of trade secrets. Forrester Research estimates that corporate IP is twice as valuable as custodial data such as credit card information and customer and medical data.
• Cloud-based services are not only a new target for cyber criminals, but also but extensive but inexpensive resources into their hands
  for carrying out cybercrimes.
• Data breaches, or the credible threat of a data breach, stopped or slowed a merger, acquisition, or new product rollout at one
  fourth of organizations surveyed.
• Yet only a quarter of organizations conduct forensic analysis after a breach or attempted breach.
• Organizations reported that IP was most often leaked or stolen by their own employees.

Read the entire study here.

As an ironic side note, the day that this report was released, security researchers announced that McAfee’s own website has serious vulnerabilities. Read that article here.

In the past few years I’ve been interviewing students for job openings at my companies. Some students came from large, well-known universities while other came from small colleges. Some students had bachelor’s degrees in computer science while others had master’s degrees. One thing that many of these recent graduates had in common was that they couldn’t program competently.

I found that these graduating students were adept at finding code on the Internet. When I gave assignments to code a particular algorithm, I was seriously impressed with how quickly they were able to find the code online. When I asked them to modify the algorithm, they struggled. Also, testing and debugging code often seemed beyond their abilities. Many of them were unaware of debugging techniques that allow them to focus in on the problem, such as using breakpoints to isolate chunks of code or forcing conditions that cause certain code paths to be executed.

The art of commenting also seems to have been ignored in most computer science education programs as well as in many companies. In my companies, our coding standard requires that every routine, no matter how small, must have a header comment that describes the functionality of the routine, all input parameters, the output of the routine, and any other information that someone using the routine would need. Yet most programmers out of school, and many working in the industry, produce uncommented code that is difficult to understand, difficult to debug, and very difficult to maintain.

Can you imagine a medical program that didn’t teach how to stitch up a patient after surgery or use the latest CT scanner? University computer science departments need to take a serious look at the skills they’re teaching. At my companies, I now require prospective employees to sit down at a computer and write a program that works correctly according to a written specification, is fully commented, and is completely their own code. I hope that the percentage of graduates passing this test increases in future years.

You can now run CodeMeasure to graph the growth of your software project development effort over multiple versions of the software. CodeMeasure uses the Changing Lines of Code (CLOC) method to calculate the growth. The graph that CodeMeasure produces illustrates various CLOC measurements. An example is shown below.

Now there is a caveat (we do need to make a profit after all). You can examine the graph and take a screen shot of it, but you can’t save the results to a spreadsheet without a paid license. The good news is that a license is only $500 for a 1-year unlimited license. You can download CodeMeasure here and purchase a license here. This way you get to try out CodeMeasure and see how the results can help you measure your software development effort.

Last year my consulting company presented a paper entitled Measuring Whitespace Patterns As An Indication of Plagiarism that examined and tested the concept that patterns of whitespace in two source code files can be used to determine whether one program was copied from the other. The conference was an enjoyable three days in St. Paul, Minnesota. We even got a tour of the Forensic Science Laboratory of the Bureau of Criminal Apprehension where we learned the real forensic science used to catch criminals (the CSI TV shows are a “little bit” exaggerated, but the reality is just as interesting).

This year the conference will be at Longwood University in Richmond, Virginia from May 25 through 27. I’m serving on the conference committee. We’re looking for paper, presentation, and panel submissions in the following areas:

Curriculum

1. Digital Forensics Curriculum
2. Cyber Law Curriculum
3. Information Assurance Curriculum
4. Accounting Digital Forensics Curriculum

Teaching Methods

5. Digital Forensics Teaching Methods
6. Cyber Law Teaching Methods
7. Information Assurance Teaching Methods
8. Accounting Digital Forensics Teaching Methods

Cases

9. Digital Forensics Case Studies
10. Cyber Law Case Studies
11. Information Assurance Case Studies
12. Accounting Digital Forensics Case Studies

Information Technology

13. Digital Forensics And Information Technology
14. Cyber Law And Information Technology
15. Information Assurance And Information Technology
16. Accounting Digital Forensics Information Technology

Networks And The Internet

17. Digital Forensics And The Internet
18. Cyber Law And The Internet
19. Information Assurance And Internet
20. Digital Forensics Accounting And The Internet

Anti-Forensics And Counter Anti-Forensics

21. Steganography
22. Stylometrics And Author Attribution
23. Anonymity And Proxies
24. Encryption And Decryption

International Issues

25. International Issues In Digital Forensics
26. International Issues In Cyber Law
27. International Issues In Information Assurance
28. International Issues In Accounting Digital Forensics

Theory

29. Theory Development In Digital Forensics
30. Theory Development In Information Assurance
31. Methodologies For Digital Forensic Research
32. Analysis Techniques For Digital Forensic And Information Assurance Research

Digital Rights Management (DRM)

33. DRM Issues In Digital Forensics
34. DRM Issues In Information Technology
35. DRM Issues In Information Assurance
36. DRM Issues In Cyber Law

Privacy Issues

37. Privacy Issues In Digital Forensics
38. Privacy Issues In Information Assurance
39. Privacy Issues In Cyber Law
40. Privacy Issues In Digital Rights Management

Software Forensics

41. Software Piracy Investigation
42. Software Quality Forensics

Other Topics

43. Cyber Culture And Cyber Terrorism

The deadline for submissions is February 19. The website for the conference is at http://www.digitalforensics-conference.org where you’ll find more information about the conference, the venue, and submission guidelines.

Software Analysis & Forensic Engineering Corporation today released a case study of Online IP Screening between Zynga’s FarmVille game and CrowdStar’s Happy Aquarium game. The study shows some interesting correlation between the source code for the two games. SAFE Corporation is officially announcing its SAFE Online IP Screening service that is targeted at social games and other online applications. The screening service is a subscription service to regularly examine online applications for signs of copying. In this first case study, we already found surprising results. Even after the normal process of eliminating correlation due to third party code, commonly used identifier names, automatically generated code, common algorithms, and common authors, correlation remained. Was this intentional? Illegal? Acceptable? Coincidence? Decide for yourself: see summaries of this and other case studies here and register to download the full case studies here.

One unique feature of online applications is that often the full source code is downloaded to the user’s machine. This makes it easier for your competitors to copy your code. It also makes it easier for us to detect that copying. Learn more about SAFE Online IP Screening here or email us for details about how we can protect you from unauthorized copying and dissemination of your code.