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

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.

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.

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.

• CA and Rocket Software reach settlement
• Facebook founder paid $100 million to settle theft claims
• More than half of booted workers steal data on way out, survey finds
• Swedish man indicted in 2004 Cisco code theft
• Cisco makes peace with Free Software Foundation
• Facebook loses lawsuit against German clone StudiVZ
• China backs down on installing blocking software
• iPhone game accused of plagiarizing flOw
• Programmer accused of stealing Goldman Sachs source code
• UBS files code theft lawsuit
• 10th Circuit strips Novell of Unix copyright
• Skype’s founders sue EBay over copyright infringement
• StoneLoops! of Jurassica pulled from App Store due to copyright complaint?
• Microsoft lifts GPL code, uses in Microsoft Store tool
• Judge rules for Apple in Psystar case
• Copyright infringement lawsuit filed against Palm
• Symantec wins $545 million decision in federal tax case
• Best Buy, JVC, Samsung, more hit with lawsuit
• Microsoft joint venture in China plagiarizes competitor
• Seagate misappropriated Convolve technology, says ex-employee

The likeability of the expert witnesses was found to be significantly related to the jurors’ perception of their trustworthiness, but not to their displays of confidence or knowledge or to the mock jurors’ sentencing decisions.

Reading the paper doesn’t make it a whole lot clearer for me, and I think their mock trial setup is a bit contrived, particularly since the jury consisted of psychology students, a demographic that you’d be unlikely to find on a real jury. Also there were only two expert witnesses for the comparison. To their credit, they discuss these potential shortcomings. I do think, however, that the paper points out something (that may have already been obvious)—there is more to being an expert witness than just being correct. Personality and presentation are strong factors.

On the other hand, I feel that this subjective aspect should be minimized. Experts need standards and measurable quantities whenever possible. Before I began developing the concept of source code correlation, the way software copyright infringement and trade secret theft cases were resolved was to have two experts give contrary opinions based on their years of experience. The judge or jury would tend to get lost in the technical details, a strategy purposely employed by some experts and attorneys, and a judgment would depend on which expert appeared more credible.

Instead, I decided to expand the field of software forensics and made it my goal to bring as much credibility to the field as DNA analysis, another very complex process that is well accepted in modern courts. I still believe that an expert’s credibility and likeability will always be factors in IP litigation, but that the emergence of source code correlation and object code correlation provide standard measures that bring a great deal of objectivity to a lawsuit’s outcome.

If you have a research idea relating to code analysis, and you can use the SAFE tools, let us know. Email Larry Melling, VP of Sales and Marketing with your ideas. If they pass our review process you’ll get free licenses to our tools, free support, and help getting your results published. This could be the beginning of a beautiful friendship.

There are three factors that are common to all definitions; a trade secret always has these three specific characteristics:

1. It is not generally known to the public.
2. It confers some sort of economic benefit on its holder, where the benefit is due to the fact that it is not known to the public.
3. The owner of the trade secret makes reasonable efforts to maintain its secrecy.

With regard to software trade secrets, algorithms that are known to the public usually cannot be trade secrets, though some jurisdictions require not only that the information be public but that it be “readily ascertainable,” meaning easily to find. For example, a sorting algorithm found in a well known textbook or in an application note on a high traffic website is, or can be, known to the public and easily ascertained.

There must be an economic benefit, so a sorting algorithm that can be easily replaced with a well-known sorting algorithm with comparable results is not a trade secret. Similarly if your company develops a program, perhaps as a side project, but does not sell it or incorporate it in any products, then it’s not a trade secret.

If the owner of the source code allows programmers to share code, or does not put notices of confidentiality in the source code, or does not take reasonable steps to insure that employees do not take the code home with them, then that source code cannot be a trade secret. This third point is a particularly important reason to take precautions to ensure your software does not go somewhere it shouldn’t. Make sure your employees, investors, and partners sign nondisclosure agreements (NDAs). Make sure you have written policies about how to handle source code. And make sure you treat all individuals and companies equally. You don’t want to be in court, defending a trade secret, and have to explain why one “trusted employee” or “trusted friend” was allowed to take home source code while others were not. That doesn’t look like “reasonable efforts to maintain secrecy.”