Thursday, February 02, 2006

Software’s knowledge architecture

Picture a software product as lots of boxes connected by lines; each box is a chunk of code, and the lines are inter-dependencies. Now imagine that you have a pot of red paint, which is the set of claims of some software patent. How would you color the block diagram?

For some patents, all the claims might fall inside one module. You’d paint one block is bright red, but the rest remain white. For other patents, the claims may be so general that all the blocks are some shade of pink.

It would be much easier to work around an infringement claim in the case with only one red block. If all the blocks are pink, every part of the product would infringe, and it would be harder to avoid paying licensing fees.

Of course, more than one patent is probably involved: you now have pots of many colors, let’s say red, yellow and blue. Some blocks may be a single color, while others are various rainbow shades.

A color pattern gives one a sense of how patents map to a product. It will show areas where just one patent is in play, and modules where there are many.

One can play a similar game with product families and groups of patents. Now each box represents a product, and each paint color is a patent owner. A manufacturer could then tell for which parts of their line-up a they would have to strike licensing deals, and where they control their intellectual property destiny.

Patents themselves have an architecture, too, and can be represented as block diagrams: they depend on each other, and can be nested one within the other. One can imagine an overlay where a patent block diagram is distorted to map onto a software block diagram. A very distorted mapping is equivalent to kaleidoscopic coloring.

A range of questions present themselves:

  1. Can one divide patents into categories: those whose scope is limited to a module, vs. those who cover the whole product?
  2. Are these categories specific to a product, and/or tied to a type of patent?
  3. Do different kinds of software have characteristic “patent colorings”?
  4. Are there regularities in how patents, or categories of patents, apply to software designs? Can one use this information to guide a software architecture to be minimally at risk of infringement – perhaps even in advance of knowing what the specific outside patents might be?
  5. There are other industries where products contain a large number of patentable elements; for example, computer and telecommunications equipment. Are there systematic differences between the patent/product mappings for different industries?
  6. Specifically, does the highly interconnected nature of software, and/or its intangibility, lead to differences in the way patents are structured relative to products compared to physical goods?

It is difficult to do such an analysis in practice because of the willful infringement rule: if you are aware of a patent and are then later found to have infringed on it, a court can award punitive triple damages. Consequently, companies are reluctant to know too much about patents which might apply to their products. The people who are best placed to assess whether a patent applies to code, the developers, are those who create the biggest risk to their employers by making this very assessment. For example, Open Source Risk Management (OSRM) declined to list the 283 issued, but not yet court-validated, software patents in the Linux kernel which it announced in August 2004, because it would expose Open Source developers to litigation risk.

One way to work around this difficulty is to swap figure and ground, that is, to map pieces of knowledge that are in the public domain. For example, one could look for commonly used algorithms, or the distribution of important software ideas, like stacks, semaphores, security algorithms.

In fact, patents are just a useful crutch in formulating this problem. My core goal is to understand the structure of knowledge as embodied in software. Patents, for all their faults, are a well-understood way of delimiting pieces of knowledge that are used in products. Ultimately one wants to explore the generality of the problem by replacing “patent” with “any knowledge chunk” in the above discussion.