Videos

Ten Strategies for Software IP Litigation

Outlines some strategies that may be helpful when software is involved in a copyright, patent, or trade secret litigation.

If you’re involved in software IP litigation, there’s one thing that’s for sure: You need every strategy possible to win your case.

With over 30 total years of professional engineering experience, Gary Stringham is a published author on embedded systems. He’s been awarded 12 US patents for his innovative embedded systems designs, and has authored fifteen defensive publications. And his solutions have helped companies save millions of dollars in prototype costs, development time and warranty costs.

All of these accomplishments have made Gary Stringham a highly-respected expert witness in cases concerning embedded systems. He’s served as an expert witness in cases involving:

  • Infringement and violations of patents
  • Copyrights
  • Trade secrets and other intellectual property, and
  • Cases regarding defective products.

This experience has given Gary unique, pragmatic insights which can help you in your software IP litigation cases. That’s why he’s composed Ten Strategies for Software IP Litigation.

  1. When requesting software during discovery, request commented source code, executable files, build files, data files, design documents, manuals, etc., in their original electronic formats.
  2. Even if the source code from opposing parties is written in different languages, infringement could still have occurred.
  3. If security is a concern, it might be possible to examine software source code on a computer with no internet connection and with USB ports disabled.
  4. Signs of potential source code copying include similar variable and function names, author names, comments, lines of code, and program flow.
  5. To examine code for content that might have previously existed, request all past revisions of source code files between a specific start and end date.
  6. Comprehending what the software is doing by reading source code could be a time-consuming effort. Extra time may be needed for that effort.
  7. Extracting executable code from a device, and performing a “reverse assembly” to make it human-readable, may be possible and could require significant effort to understand.
  8. Use of open source and third-party source code is common. It must first be identified and removed from the file set before examining the rest for IP content.
  9. CodeSuite® is a tool specifically designed to detect possible copying and plagiarism of source code and executable code.
  10. In looking for an expert, a horizontal expert (an expert in a technology across many products) may be preferable to a vertical expert (an expert in a product using many technologies).

Today, businesses across the country are turning to Gary for his expertise in embedded systems development, firmware development, source code comparisons, patent claim analysis, and intellectual property litigation.

If you need an expert to consult in software source code and hardware designs, and reverse-engineering the designs of others, the search is over. Let’s talk.

What Is an Embedded System?

Explains what an embedded system is and gives examples of embedded systems that helps us every day.

No matter where you go, or what you do, an embedded system is helping you, serving you, protecting you.

Embedded systems are computer components which interface with and control mechanical and electrical systems. They often rely on sensors, like an airbag in a car, or a human interface, like pushing a button, to perform a specific task.

Unlike general purpose computers which perform multiple tasks, embedded systems are designed to do a specific task. They can be large enough to run a factory assembly line or small enough to fit in your watch. And they can be found in every industry on the planet. A few examples: finance, defense, home appliances, computer electronics, automotive, business and manufacturing, medical.

If you think mankind couldn’t develop another type of embedded system, think again. The outlook for the embedded system industry is bright and very positive.

Introducing Gary Stringham & Associates, LLC

An introduction to embedded systems and Gary Stringham.

Embedded systems. They’re computer systems designed to perform a specific task, or control hardware or mechanical parts. You interact with them every day. You wake up and adjust your home thermostat. You cook breakfast in your microwave. You stop by the bank’s ATM then you use your GPS system to find a new restaurant.

Embedded systems are the product of engineers who transform ideas into devices, and devices into convenience.

For over 30 years, Gary Stringham has worked with embedded systems. That includes 15 years of work in the printer industry where he received 12 US patents and wrote 15 defensive articles. Today businesses across the country are turning to Gary for his expertise in embedded systems development, firmware development, source code comparisons, patent claim analysis, and intellectual property litigation.

If you need an expert in software source code and hardware designs, and reverse engineering the designs of others, let’s talk. Gary Stringham & Associates. Embedded Systems Consulting.

EDACafé Interview at DVCon 2011

Graham Bell of EDACafé interviews Gary Stringham at DVCon, March 1, 2011.

Graham Bell: Hi this is Graham Bell with EDACafé and IB Systems. I have the pleasure of speaking with Gary Stringham. Hi Gary.

Gary Stringham: Hi. How are you doing?

GB: Good Gary. What brings you to DVCon?

GS: Well there’s a bunch of like-minded engineers here that are wanting to improve their designs. Some come with problems that they’re trying to solve. In fact, last year when I was here, an engineering manager was trying to figure out how he could get software teams involved with the hardware designs early on when there was no budget for the software teams to be involved yet. So we talked about it and I gave him a couple of suggestions like having one software member involved early on or having a list of requirements early on that the hardware team can use even though there’s no software teams involved.

GB: Great. Well what do you see the trends for the industry?

GS: I see the industry moving towards the having software more involved, there’s a lot of emphasis on that which is good because you want to know what the software is going to be running on it so you know how to design the hardware. Unfortunately, not everybody is moving to that yet, and so there are still problems. In fact last month, I heard a couple of managers talk about how software is an afterthought and software is also the safety net for the hardware products. So companies are trusting the success of their products to an afterthought? It makes me wonder about that. But on the other hand, I did get an email just this morning from a guy who said that years ago, a software engineer made a comment to, not a few years ago, a software engineer made a comment to a hardware engineer who added a minor feature to the hardware and that feature had a positive impact even to today.

GB: Excellent. Can you tell us a little bit about the challenges that designers and design teams are facing to get out new products?

GS: Well there’s the chips are getting more complex and the time, the market windows are always getting shorter. But what I’ve seen is a lot of focus on tools and downstream activities, when a focus on upstream activities and design methodologies could have a big impact on cutting out the cost in the verification and system integration later on.

GB: So what does Gary Stringham bring in terms of products and services to these kind of challenges?

GS: I’m a consultant in this space. I’m in the hardware/software domain. I’ve worked with both sides. I’ve even written the book on the subject called Hardware/Firmware Interface Design. I’ve had attendees and clients comment about how my principles and my practices concepts have helped them in their design. So I can help companies out with their challenges in trying to get software more involved with hardware.

GB: Would you like to comment on a particular customer success that you’re especially proud of?

GS: One that I really liked was at Hewlett Packard when I was an engineer there, which was where I developed this, was there was one particular block that was real nasty and it took me over twelve months to write the device driver for it and there were all sorts of other issues with it. When the next generation came out, I had the device driver running in three days.

GB: Cool, sounds like you’ve got some good methodologies that can help out design teams. How can our audience find out more, Gary?

GS: They can go to my website, garystringham.com, and my phone and email address are listed there.

GB: Gary, thanks for speaking with our EDACafé audience.

GS: Thank you for having me here.

EDACafé Interview at DAC 2010

Graham Bell of EDACafé interviews Gary Stringham at DAC, July 15, 2010.

Graham Bell: Hi this is Graham Bell with EDACafé and IB Systems. Today I’m speaking with Gary Stringham of Gary Stringham & Associates. Welcome.

Gary Stringham: Thank you very much. Glad to be here.

GB: Gary, I understand this is your first DAC you’ve exhibited at. What brings you to DAC, what are you showing and talking about with the engineers here?

GS: Well this is my first time here at DAC but I have been working in this domain of the hardware/firmware interface. There are people who focus on hardware, people who are focused on the firmware side, but the two sides have to come together to make a final product that can be shipped to customers. That interface in between there has to be designed in such a way that the integration will happen smoothly. Sometimes there are defects in the hardware and you don’t want to spend the money to respin the chips. So firmware has to do some things to work around them to get a shippable product. But something could have been done, maybe, hopefully, to have avoided those defects in the first place.

I have a lot of best practices and principles that are used in how to design the hardware to make it easier for firmware to integrate with it. These best practices are more than just with the designs but also the process and procedures. It’s a methodology. So it starts from the very beginning of the early conceptual design phase and goes clear to the end when the product is being shipped out the door. So it’s more than just verification, more than just co-simulation and virtual prototypes. It’s involved from the beginning to the end.

The areas cover things like collaboration. Get the hardware and the firmware engineers in the same room and have them talk to each other before hand instead of at the end of the project when they’re pointing fingers at each other. Documentation is a very important part of collaboration, what kinds of things are in there? The firmware engineers need to have some information in order to do their part. What kind of information is needed in that? How do you design the registers? How do you lay out the bits in a register? What kind of bits should you have in the same register? There are some things that can be done to avoid problems later on down the road.

Now nobody’s perfect; human beings aren’t perfect. But later on, when you’re trying to get the hardware and firmware integrated together, there’s going to be problems and you’re in a buttoned up system. There’s no in-circuit emulators, there’s no JTAG connected. How do you figure out what’s going on? By having some test and debug hooks in the hardware, then it gives the firmware some hooks that can help diagnose problems and work around solutions.

I cover a whole gamut of things from the beginning to the end in how to improve the whole process. I’m more of the methodology kind of guy. I’m not selling tools. I do have a book out, it’s available on Amazon.com. Just look for Gary Stringham, you’ll find it. But I cover a whole bunch of things like that and what I’m looking for is to help companies with that as a consultant and trainer to teach your engineers, your design engineers, on how to design the products to make your products better.

GB: Can you share with us some of the projects you’ve worked on as an engineer over the years?

GS: Well I spent 20 years at Hewlett Packard, the last several years was in the LaserJet business. So I was designing, writing the device driver for some of the blocks in the ASICs. There was one particular block that had all sorts of issues, I won’t go into the details why, but that was just one block. The rest of everything else was normal. But that one particular block took me over twelve months to get the device driver written for it. The abort function was 250 lines of code. And at the end of it, when I finally got the thing to work, we didn’t have to respin it, fortunately, there were times when it was real close, but we didn’t have to respin it. But at the end I started writing down all the things I wanted to change in the next version and that’s when I looked at it and said, “Oh, this is just common stuff, common sense stuff for all types of blocks.” So that’s what led me into this direction here and trying to convey this out to the industry and help the industry as a whole.

GB: Gary, what’s your contact information, what’s your website out there on the web?

GS: GaryStringham.com. It’s fairly easy. And my info’s there and you can contact me through that.

GB: Gary, thanks for speaking with our EDACafé audience today.

GS: You’re welcome, glad to be here.

John Blyler Interview at DAC 2010

Interview by John Blyler, Editorial Director of ExtensionMedia, take at DAC, July 14, 2010.

John Blyler: Hi this is John Blyler. I’m the editor-in-chief of Chip Design magazine. Today, on the DAC floor, I have the chance to talk with Gary Stringham who has just written a new book on hardware and firmware through Elsevier press. The reason this is important, as all of us know in the EDA community, Cadence has made a big push to recognize and work with the importance of software, and by that, most folks recognized it as firmware in the chip design world. Here’s an example of something that speaks directly to that.

Gary Stringham: Hi, I’m a firmware engineer. I’ve done a lot of stuff with firmware working very closely with hardware. I’ve done a lot of things in trying to get the software and hardware to work together. I have seen problems with the hardware in trying to get these issues together and so what I have done is collected a whole bunch of best practices and principles to try to get the hardware and software world together. It’s not just verification or virtual prototypes but it’s a whole system from the beginning of the design to the end when the product is being shipped out the door.

One of the things I have done is to collect a whole bunch of best practices. For example, one of them is when you design a chip with the bits in the register and you come out with a new version, don’t move the bits around. It makes it difficult for firmware to work on both versions of the hardware. Another example is to keep the addresses in the right place. Add some test and debug hooks so that it makes it easier for firmware to try to figure out what’s going on when the thing isn’t working correctly.

A very key part is documentation. I know that’s a not-so-nice word among engineers, they don’t like to write. But it is a very key tool. One of the things that is very important though is collaboration between the hardware and firmware teams. They need to collaborate before the hardware is designed, before they start designing the registers so that the hardware has the right tools and hooks that it needs for firmware to use.

Video Interview at DAC 2010

Video interview taken at DAC, July 14, 2010, in Anaheim, California.

Gary Stringham & Associates is the company name. What I specialize in is the hardware/firmware interface, or in other words, how to get the hardware and the firmware to play nice in the same sandbox. Some of you have worked with trying to integrate firmware and hardware together and it can be difficult because the two sides haven’t talked to each other.

I have a bunch of best practices to get things to work well. For example, how to lay out the bits and registers that makes it easy to integrate the firmware later. I do some consulting and training. I’m not doing designing services. But we do help other teams of engineers get the hardware and firmware engineers in the same room to have them work together on what their best practices should be.

It’s not just in the verification area or the co-simulation or virtual prototypes, but I cover the whole gamut from the very beginning in the conceptual phase trying to make sure that all the pieces are there that’s necessary to get the product working together. And also towards the end phase, especially with test and debug hooks so that when you have problems in the end trying to get the whole thing working together there’s enough hooks and stuff to try to diagnose and troubleshoot and work around the issues that are there.

I work closely with the clients in trying to assess their needs. With best practices, best practices are only good for a specific situation so obviously it needs to be with your specific situation, with your needs and what your situation is and we work closely with that.