United States: Practical Suggestions For Successfully Developing A Patent Portfolio In A Software Company

Originally published on 27 February, 2001

The development of an effective patent portfolio strategy for a software company, whether large or small requires a coordinated set of processes which address training, motivation and reward, and efficient application development. Each of these areas will be discussed in terms of today’s cultural environment as perceived by the author. This perception is based upon experiences gained in managing programmers/software engineers for 20 years in the development of scientific and commercial applications and systems, and over six years of software patent prosecution and helping to build a patent portfolio at Sun Microsystems, Inc. The thoughts and suggestions are those of the author and are not necessarily the views of nor endorsed by Sun Microsystems, Inc.

While the following discussion focuses primarily upon companies that develop and sell computer products, the comments apply equally as well to enterprise companies that have large in-house programming staffs. Companies such as Texaco, Inc., American Airlines, Wells Fargo Bank, Charles Schwab, etc.

A number of studies of software engineers/programmers over the past 30 years have shown a high correlation between persons with musical training and creative and effective programmers. It is generally conceded by most people, that software development is more art than science. Gifted software developers are more like gifted musicians or composers or other artists, than they are like engineers. Indeed, it is only in the past 10 years that some engineering schools have added computer science to their engineering curricula.

Thus the culture of software developers tends to be less conducive to patent portfolio development than the mechanical and hardware based arts. This is not to say that engineering formalism and proven development rigors have not been successfully applied to software development. However the software development process remains loosely formal and highly artistic.

Very few software developers including recent computer science graduates have had any training in Intellectual Property law, whereas many engineering graduates have some exposure to patents, engineering notebooks, etc. Many developers have some sketchy understanding of copyright law but very few have any real understanding of patent law. In many cases, patent law is grossly misunderstood and actively resisted by software developers. The mistaken notion that "ideas" can be patented as opposed to specific implementations leads to misguided opposition to software patents. One still frequently hears comments like, "A person should not be allowed to obtain a patent on the idea of a word processor" (or spell-checker, or debugger, or calendar manager, etc., etc.). Similarly, one still hears comments like "whatever I independently create should not be attacked by someone else who claims to have a patent on the idea."

Related to these thoughts are those of many artistic developers who say "Look, I am not creating anything new or novel here. I am just taking old ideas and making them work in a different combination or on a different platform or in a different way." "There is nothing patentable in this, it is just a different compiler. Compilers have been around for years." The essence of these misunderstandings is a lack of training in "what an invention is?" "what’s Patentable?" These issues are discussed elsewhere in this book but these are fundamental questions which must be articulated to software developers in ways which are simple, non-legalistic, and relevant to software.

Other cultural characteristics of software developers create impediments to the patent process. For example, it is not uncommon for a software development group of from 3 or 4 to perhaps 20 or more persons to meet to discuss a technical problem and to "brain - storm" about possible solutions. This creates serious questions of inventorship. Thus specific training about "who is an inventor?" and "who is a co-inventor?" is required.

For companies whose products include software such as Sun, H-P, Apple, Microsoft, Intel, etc., the marketplace itself creates perhaps the most significant impediment to the patent process. This impediment may be characterized as the "time-to-market squeeze". That is, the competition today to get a new product into the marketplace has radically changed the way software is produced. The growth of the Internet and the marketing of software through the Internet (through "try-and-buy" processes) have exacerbated the management push to get products to market quickly. This results in software development regimes wherein three months from "concept" to " program release" is the goal. This type of shortened development cycle only works if other related concepts are well understood. Like - "80% is good enough for the version 1.0 release"; "I release it to the internet world of potential customers, and let them help debug it while you work on the next release." This type of shortened production schedule puts great pressure on product managers and individuals (inventors) to "get the product completed and released." Activities which "interfere" with the product development process, such as invention disclosure and assisting in the preparation of a patent application are often not tolerated where the project managers only measure of performance is "did he/she meet the release schedule?"

Early identification of patentable inventions and scheduling "application development time" into the product development schedule requires an understanding Top Management, a trained and adequately rewarded Project Management, and trained and adequately rewarded inventors.

So, within this context of a perceived software development culture, some practical approaches to patent portfolio development will be discussed.

We take it for granted that the concepts of "protecting the company shareholder’s investments" and "protecting the product from piracy by a competitor" are well understood. Indeed, these concepts do seem to be ingrained in the psyche of the circuit designer or hardware developer. It does not seem to be well understood by Software developers. For years, copyright protection was deemed to be enough for software. The Apple v. Microsoft¹ and Lotus v. Borland² cases have made it abundantly clear that methods of operation and functionality can only be protected by patents. These events and the U.S. Patent & Trademark Office Computer Related Invention Guidelines have lead to an explosion of software patents being issued in recent years.³ It is a necessity for a company to obtain patents on inventions in all strategically important products in order to prevent a competitor from shutting the company out of a strategic area. Some companies (i.e., Dolby, TI, not to mention IBM) have made either entire or significant portions of their net revenues from patent licenses. Most larger software developers seem to be more concerned about the defensive aspects of a patent portfolio.

Enterprise Companies Information Systems Groups are not immune from attack by software patent holders. They have a similar need to protect their R & D investments in software even though the products may never be sold or licensed to others. Mission critical applications with unique and novel systems should have patent coverage to protect the competitive advantage of the developer and to have a portfolio with which to barter with a potential attacker.

The answer is a function of a company’s strategic products and product development plan. If a company has only a few key products, then only a few patents may be needed to protect them. But if a company has a full line of strategic products, such as operating systems, server and client software, development tools (compilers, debuggers, test suites, etc.), network systems, management tools, etc., that company needs a patent portfolio that contains some protection for each of these areas. Strategic Development Plans must incorporate goals for protecting inventions resulting from the new product development. The idea is to have enough patent protection in each key area so as to cover your own technology and possibly have some patent protection in a strategic area known to be a target of a competitor. Strategic forecasting of competitor products provide a basis for early patent application in key developing technology areas.

The Association of Chief Patent Counsels develops data periodically on general spending levels by the corporate patent function in America. While it is not clear what percent of the R&D budget is a reasonable amount of expenditure on the patent budget it does seem clear that the amount should be a function of the R&D expenditure (1 -x%). If a company is trying to build a portfolio, the spending level could be significantly higher than the steady state level. In the building-the-portfolio phase, quantity of patents pursued may be more important than quality, although the goal of maximum protection Must always be the corporate patent counsel’s target.

What is needed is a knowledgeable and supportive Top Management, a project development process that contains mandatory milestones for early invention identification, easy-disclosure of inventions, and a minimum of 5 hours per invention application built into the project schedule; developers trained in the invention patent process; and a cadre of patent attorneys (both in-house and out-house) who are knowledgeable of both the software technology and the invention application development process (more about this below).

Many companies have invention incentive award programs. These generally contain some form of monetary award for invention disclosure, patent application filing and patent issue awards. Such programs very with each company but generally include small amounts ($1-300) per disclosure. They also vary from small amounts ($500 per inventor) for application filing and larger amounts ($2000 per inventor) for patent issue, to programs more heavily weighted on the patent filing award ($1-2000 per inventor for filing) and lesser amounts at patent issue.

However, of more importance than the amounts or the loading of the process maybe the accounting treatment of the awards. The award process appears to be most effective if the amounts, when paid to the inventors, are charged to a corporate patent cost account. Some companies have charged these amounts to a normal payroll or bonus account in the operating manager’s budget. This works effectively in many situations. However in some cases, astute managers may quickly perceive that they can control these discretionary accounts by filtering the invention disclosing/ filing process. This seems to be especially true if the manager’s performance has no patent filing related goals attached.

The most effective reward system appears to be some sort of inventor award program for disclosure/filing/issue (as described above) coupled with an award or management goal for invention disclosures for Project Managers and Department Directors. it appears that if the Project Managers and Department Directors are not motivated in some way to get inventions disclosed and applications filed, they will not be disposed to allow the inventors time to get the disclosures submitted and the applications filed. "We don’t have time to do patent applications!" is often heard in these circumstances.

A final word about accounting for patent related expenses is appropriate. The overall cost of filing and maintaining the patent portfolio should be charged to a corporate account. Charging these costs directly to an operating department quickly becomes a discretionary expenditure which operating managers will find easy to control. While corporate expense accounts may eventually get allocated to operating units on some basis (i.e., Engineering head-count, R&D expenditure, etc.) with the normal complaints about the particular basis used this nevertheless appears to be a better approach.

Having defined the culture, some underlying reasons for developing the portfolio, accounting for the costs and development of an effective award program, it remains to try to fill in the final pieces. The awards program can provide some incentive to disclosure and if constructed to include the managers in some way, the time to assist patent counsel in filing the application will be made available. The two pieces of the process yet to be discussed are training of the developers and training and selection of Patent Counsel.

Training of the developer clients takes at least two forms. One form is the training of Top Management, Department Directors and Project Managers. The focus of this training is on the need for developing/maintaining the portfolio, on the requirement to fold Intellectual Property protection plans into long range strategic product plans, and on the requirement to adequately set goals and measurements to determine whether Project Managers are doing the job of patent filings where possible.

The other form of training is "bottom-up" training of the developers. Here the focus must be on "what is patentable?" "Who is an inventor?" "Who is a co-inventor?" and "what is the process of submitting a disclosure and getting the application done?" Because of the rapid growth of some companies in Silicon Valley, the optimum training for developers needs to occur frequently and as soon after an employee joins the company as possible. If some of this training can be inserted in the basic new-employee orientation so much the better. This orientation must be followed-up with a 1-2 hour technical patent law training session for all developers at least once a year. Developer training and the patent award program are two of the essentials to make the program work. However, the training, understanding and encouragement of the management structure is also needed to produce a viable on-going patent development process.

Putting such awards programs, management emphasis and measurement, and dedicated training in place will likely result in more invention disclosures than the company can reasonably afford to prosecute. In this circumstance, a Departmental or Operating Company "Patent Review Committee" can be an effective tool to limit the filing process to only those inventions deemed to be most strategic, most valuable to the company’s future. Those disclosed inventions deemed to be not strategically valuable enough to pursue, can be formally published so as to constitute prior-art to preclude patenting by another.

The final piece to the patent development puzzle is the selection of suitable patent counsel to prepare the applications.

A big part of the process of convincing Product Managers to put time into their department schedules is to be reasonable in how much time is assigned per application. A reasonable amount of time for the developer/inventor to assist in getting the patent application filed is 5 hours. This breaks down as follows:

½ hour to fill out and submit the invention disclosure form,

1½ – 2 hours for a full disclosure meeting with counsel,

1 – 1½ hours for review of the draft application, and

1 hour for review of the final application and signing papers.

This is a tight schedule which means that the patent counsel must be conversant with the technology and prepared to get enough disclosure details during that first 1½ – 2 hours to do a reasonably clean first draft.

For this to work reasonably well, outside patent counsel familiar with computer science and software techniques such as object oriented technology, networks, advanced operating systems, etc. must be found and/or developed. Additionally, patent counsel must be trained to come to the first patent disclosure meeting well prepared. Patent counsel are not permitted to try to get the inventors to write the application for them by insisting that they be provided with flow-charts, and detailed written description as well as fully analyzed prior-art. Modern day software developers generally do not have flow-charts, and in many cases, no detailed written descriptions of new inventions exist. Accordingly the patent counsel must be trained to extract the necessary drawings (perhaps by bringing a few to the meeting himself) and details of the prior-art and new invention at the disclosure meeting. Young patent associates at many law firms are not trained in how to do this. Thus it generally takes a mature patent attorney, skilled in the software disciplines, and in the art of interviewing and detail development, to make the 5 hour target for filing really work.

Conclusion.

The development of a patent portfolio at a software company thus requires.

• Executive commitment that a portfolio is necessary and that a reasonable level of funding for the Patent department and process is appropriate;
• Top Management and Project Management training in how to make the program work;
• Continued training of the developers/inventors in the patent process;
• A well reasoned award program for the inventors and their project managers; and
• A well trained stable of outside patent counsel who can make the application process as painless as possible for the inventors.

1 Apple Computer Inc. v. Microsoft Corp and Hewlett-Packard Co., 35 F.3d 1435 (1994, CA 9) cert. denied 115 S. Ct. 1176 (1995)

2 Lotus Development Corp. v. Borland International Inc., 49 F.3d 807 (1995, CA l) aff’d by an equally divided court 133 L ED-2d 610 (1996)

3 Preliminary counts for Software patents issued in 1997 is that over 200 software patents are issued each week, resulting in about 12,000 software patents for 1997.