Transcript: Andrew Tridgell on Patent Defence

The following is a transcript of a talk given in New Zealand, 2010. Andrew Tridgell discusses why reading patents is usually a good idea, how to read a patent, and how to work through it with a lawyer to build a solid defence. For the free software community, Tridgell also suggests how cooperation could help scare off patent holders.

Video "50091" available via: mirror 1 (Aus), mirror 2 (Aus?), mirror 3 (Ger), mirror 4 (North Am), mirror 5 (NZ).

Andrew Tridgell is an award-winning software developer, primarily known for the Samba fileserver and printer sharer.

Transcript by Ciaran O’Riordan, End Software Patents.

Start

Andrew Tridgell: Okay. So, I’m going to be talking today about patent defence for free software developers, and, as it says on the slide there, I am not a lawyer, but, the point of this talk is not to have a talk by a lawyer. The point is to learn about how an engineer interacts with patent attorneys, to teach you the basics of language and the day-to-day you do when you try to communicate with patent attorneys in building patent defence. So that’s the first part of this talk. The first part is a bit like a tutorial how an engineer interacts with patent attorneys to do analysis of patents.

The second part of it is a discussion on how the free software community can lower its exposure to patent attacks. This is something I’m quite passionate about, I am concerned that patent attacks on the free software community are going to become more common in the future, and I believe there are things that we can do as a community, as developers within the community, to lower our exposure to those attacks. That’s the aim of the second part of the talk.

Okay, so, patent lawyers are shy creatures. The closest animal I can really think of would be a platypus, and the platypus are shy, industrious creatures. It’s hard to spot one in the lagoon, but they do a lot of work under the water. I didn’t manage to find a nice image of a shy platypus, so I didn’t put one up for you. Getting time with a patent lawyer can be quite difficult, particularly if you don’t have them available at whatever company you work for. There are resources within the free software community where you can talk to places like the Software Freedom Law Center and get in touch with patent lawyers. I think it’s important to have some understanding of some of the basics so that when you do need to communicate with members of the legal fraternity, you can communicate reasonably efficiently and get across the knowledge that you have, to them.

Patent defence actually starts with engineers. It starts with developers. The patent attorneys are there to validate and to guide. You might think of the a bit like the "lint" program which would validate your c code for common programming errors. A patent attorney will validate the analysis that an engineer does. But, even though patent attorneys often have engineering degrees —they often are quite good programmers— they probably don’t know your code, and your code is going to be a horrendous, complex spaghetti lump of code, because that’s what code is like. So, your code, you understand it, you are the one who has to be able to explain in the appropriate terminology whether your particular code matches or doesn’t match some patent that is out there. And in order to do that you have to understand some basics of the structures of patents, you have to understand how to communicate your knowledge of your code to somebody who can then guide you on whether you have an issue or not.

Okay, so where do you start? You need to learn to read patents. And that doesn’t mean just the abstract. In fact, many people in the free software community, a lot of discussions on sites like Slashdot, people stop at the title. And they think that based on the title they can say "Ah, that was done by the FooHits Corporation in 1925, therefore it’s not a problem". Right? And it doesn’t work like that. You can’t stop at the title, you can’t just stop at the abstract.

The whole idea of saying that it’s not a problem because somebody else did it previously, the so-called "prior-art defence", that is a defence that will cause these shy platypus-like creatures to cringe because the prior-art defence is extremely difficult to pull off. Really hard. The defence you want to go for is something called a "non-infringement defence", which I’ll explain in a minute.

[↑menu↑]  Okay, next thing: is it dangerous to read patents? Now, a lot of people make this statement saying you shouldn’t talk about patents, you shouldn’t read patents because it’s dangerous to do so. Who can tell me why? What is the basis for that statement?

Audience member: Triple damages.

Andrew Tridgell: Triple damages. Right. Okay. In the free software community, imagine you have a little project, say, ccache, my little compiler caching project. If you’ve got one lot of damages for patent infringement, what would happen to the project? It’s dead. If it gets three lots of damages for patent infringement, what happens to the project? It’s still dead. For most free software projects —not all there’s some that have the resources and could sustain a patent infringement damages type case— the vast majority of projects in your average distro, one death is enough.

So in that case, do you walk blindly across the minefield in the hope that the blindfold will protect you from the shrapnel, or do you actually take it off and have a look and step around the mines? I propose that for most FOSS projects, stepping around the mines is the right way to go. Not all companies agree, and this doesn’t apply to all projects. Some of the larger projects, some of the projects with more corporate relationships, this may not be applicable to.

So, what I’m going to do now is, I’m going to go through some key terminology in dealing with patents. Just to give you some of the basics. And once you’ve got some of the basics, I am going to actually show you a patent. I’m going to put up a warning slide before it comes up, so if you’re in a company that does say "never look at a patent", you can flee the room at that point. Run out or cover your eyes or whatever. Somebody can tap your shoulder when the patent is no longer visible.

So, the key terminology that you need to know: the first thing is what types of defence, what types of arguments can you make to defend yourself against the potential patent claim. Now, a patent claim doesn’t mean that somebody’s necessarily launched a law suit. An example is, I was in a carpark with another company’s —I won’t particularly name— executive. He happened to be giving me a lift to a venue at a conference and he happened to mention vaguely to me, "Oh, I think you might be violating such-and-such a patent on such-and-sucha" which happened to be one of his patents. Right? He’s told me. Very unsubtle, but he told me. Now, at that point I have to be careful. I have to make sure that all my patent defence for that patent has been put in order. I have to make sure that I am absolutely certain that we are in the clear on that patent, because one death is enough for a free software project. So you’ve got to get it right.

[↑menu↑]  So, at that point I need to make sure my defence is right. What types of defense can I arrange? This doesn’t mean hiring boydguards. That’s not the type of defence I’m talking about. Might work in some countries, not in the sort of countries I tend to deal with.

[↑menu↑]  That first type of defence is really the one you want, it’s called: non-infringement. And that is: "we don’t do that. The patent says X, we don’t do X, therefore go away, sue someone else, it’s not relevant for us". That’s the defence you want. If you can demonstrate really strongly that you do not do that, then you’re in the clear. And you wanna make sure that you demonstrate it really clearly. And if this is a patent that you really have to be concerned about, you really have to check your arguments with a patent attorney, but, that is the argument you want to be aiming for.

[↑menu↑]  Next one, prior art: someone did that before. Someone else has done that before. Before what? Before the priority date for the patent, which is actually, in many countries, a year before the patent was filed or even earlier in some cases. I’ll be talking about that later in the talk, about priority dates. Basically the argument is: somebody else did that before. It’s a very, very tricky argument to get right. Extremely tricky, and it is the most common argument bandied about in the free software community. And if you see it in the primary defence against a patent, you should cringe because it is an extremely unsafe way of doing things. You’ll see why as we go through examples.

[↑menu↑]  Invalidity, which is really just variant of prior art, ah "you can’t claim that! you can’t do that!" That’s the invalidity type argument, which is very strongly related, a very close relative to prior art type arguments. They’re really a variant of each other. And that borders on the almost impossible. That’s a matter of: you better have some pretty high-powered attorneys on your side who are willing to spend mega bucks, and, ah, maybe you better be where the judges are pliable or something, I don’t know. You really… that is hard. It’s been done, but people write papers about it in law journals when it happens. Y’know, it’s not really that common.

So, next key terms you need to understand in order to understand about these types of defence is: independent versus dependent claims. A patent has lots of different parts. The most important part of a patent is a series of claims, and that is the part that the patent holder is actually claiming the monopoly on. That’s the part where they’re saying: "we own this idea". And that’s what the patent office has said: "yeh, we’re going to give them that idea, they own that idea".

[↑menu↑]  Now, a dependent claim is a claim that references an earlier claim. It might be, say, the second claim in the patent which says "Just like in claim #1, but with this extra bit". That’s a dependent claim.

An independent claim is a claim that doesn’t… that stands alone by itself and doesn’t say "like that other claim, with something else" Now, the key thing about this —and I’m going to give some nice examples of dependent/independent claims in a minute, so if you’re feeling baffled, there will be some simple examples— for a non-infringement defence, you only have to care about the independent claims. Rigth? So if there’s, say, fifty claims in the patent, there might be two independent claims and they might in fact be very similar. That’s very common. You only have to look at those two for a non-infringement argument. If you don’t do the independent claims, you cannot do the dependent claim because a dependent claim is: the independent claim plus something else. Okay? For prior art, or invalidity, you must annihilate every claim in the patent completely. That’s really, really hard. They start off easy, perhaps, at the beginning of the patent. By the time you get to the end of the patent you’re really scratching your head trying to line up the precise prior art. And, that’s largely the reason why a patent attorney will wince if you think, if he thinks the only possible defense you’ve got is prior art. Okay, there are some cases where prior art is a little bit better, and I’ll go into those a bit later in the talk.

Audience member: If you manage to disprove an independent claim, does that automatically disprove all the dependent claims?

Andrew Tridgell: You don’t disprove claims. It’s not about disproving a claim. It’s a matter of having an argument —if it’s non-infringement defence you’re going for— then if you have an argument that says you don’t do the independent claim, then automatically you cannot do the dependent claim. Right? This is where the example… I’ve got a nice, simple example. Those of you with kids will hopefully appreciate the example.

So, at this point, we’re going to start looking at examples. Those of you who are under strict orders never to look a patent in the eye, should leave now. Okay? Or cover your eyes.

Alright, so, first example patent is "NZ9647631: A large red car". File on the 22nd of January 2010, here. The abstract for this patent… So this patent consists of a number of pieces. We have a filing date up here. This one. [highlights "Filed: 22nd Jan 2010"] That filing date is a hint towards the priority date of the patent. Now, the priority date is the date at which prior art cuts off. So, if you are going to make a prior-art defence, then you have to find stuff that is earlier than the priority date. The priority date… You should probably start with that date minus one year and one day. So what date would that be? Twenty-first of january 2009. Start with that. Start with the assumption that if anything that you are trying to use as prior art is after January 21st 2009, then forget it.

But if it’s before that, then there’s a chance and that’s where you need to pin down the priority date more precisely. But then it depends upon jurisdiction and various other rules. And that’s where, if it matters, if the precise date matters… And it also depends on continuations, is this patent a contiuation of an earlier patent? Did somebody file a patent and then give up on it and then start a new patent based on the earlier one, they might get the earlier date. So, that’s where you may need some legal advice just to work out what that date is. But, if you’re going down that route and you’re caring about priority dates, that immediately implies that you’re caring about prior art, so you’re already on dangerous ground.

So, the abstract, which is really just a vague setence or two about the general area. Do not just stop at the abstract. The abstracts are often very different from the actual claims. This is where Slashdot tends to get stuck, because they start on the abstract. So, the abstract for this one is "A transport system for entertainment of children". Ok, let’s go on to the claims. Now, between the abstract and the claims, there’s usually a whole lot of other stuff. Now, I’m skipping it. When you’re reading a patent, usually you should skip it too. You come back to it later. It does matter, all that stuff in between. All the diagrams, and the description of the invention, and the typical usage, and all this other guff —which is often pages and pages and pages— jump past that, I would advise you. Go on to the actual claims and come back to the descriptions and the diagrams in order to understand the terms in the claims. That stuff in between is merely there to clarify the terms in the claims. It isn’t the patent.

Now, that claims. Here we are are down in the claims. It typically starts with a wording something like "What is claimed is:" and then there’s a series of claims. Now, this here is an "independent claim". That’s an independent claim, it doesn’t depend on any other claims in the patent. So that claim says:

• "Claim 1) A transport system consisting of:
  • a red car,
  • with shiny plastic panels"

Now, this has got three pieces to it. The first piece, the "transport system consisting of", that is called the "claim preamble". That introduces the area you’re talking about. That introduces what sets the scene for the rest of that claim. You don’t try and defeat the preamble. You don’t try and say "I don’t do that". It’s not something that you do, it’s something that is. It’s a situation that you’re in.

When you’re trying to defend yourself through non-infringement by saying "I don’t do this", what you need to do is knock out these things here which are called the "claim elements". [highlights "a red car" and "with shiny plastic panels"] So that’s the claim elements, and there’s two elements here and there’s an implied "and" between these in this case, unless somebody actually sticks an "or" in, right? usually it’s an "and". So this means there’s these two elements, and imagine it’s got, like a Python script: has to be a red car and it’s got shiny plastic panels. If you can demonstrate that whatever you do isn’t a red car or doesn’t have shiny plastic panels, you’re done. That independent claim is gone. You need to then write that up, and I’ll show you how to write that up. There’s a particular way of writing up your analysis to pass on to somebody who can check the lint, like I said, compiler-checker type thing checking that you’ve done it right. There’s a particular way of writing it up, a form called a claim chart, which I’ll show you later in the talk.

Okay, so what you’re trying to do with a non-infringement defence, is find claim elements that you don’t do.

Audience member: If, however, I can prove that I may be using a red car with plastic panels, but it’s not a transport system under their definition, that doesn’t matter?

Andrew Tridgell: I don’t think it’s going to help you. It might. But, trying to do it based on the claim preamble is generally not the best thing to do. …and this is of course a very badly written patent, one I made up last night. It hasn’t actually been filed yet with the patent office, and so it hasn’t been through all the usual lawyering that one would expect of a full New Zealand patent. But, yes, you would normally try to knock off the elements, not the preamble. There may be an argument you could build up, but go first of all by trying to knock off the claim elements: highlighting claim elements that you can say "I don’t do".

So then we have down here… this is a dependent claim.

[highlights: "Claim 2) The system of claim 1, with multicoloured wheels" ]

So this is the system of claim 1, in other words a red car with shiny panels, but it’s also got multicoloured wheels. So it’s that thing plus this other thing. Now, if you’re not the first thing, if you’re not a red car with shiny plastic wheels, you can’t be that and have multicoloured wheels. It’s just basic logic. And that’s the way the logic works.

You can notice this is a dependent claim because it starts with wording like "The system of claim 1", or similar wording. And usually there’s a hyperlink in something like Google or whatever if you’re looking at it in a modern patent viewing system, you’ll see it links back to the earlier claim. That’s a dependent claim. For non-infringement argument, which is the argument you really want to make: forget them! You’re trying to knock off all the independent claims. The dependent claims take care of themselves. If you’re not doing the independent claims, you can’t be doing the dependent claims, you can’t be doing the dependent claims.

So then there’s a second dependent claim at the bottom, which is: "A system of Claim 2…" building on the previous claim "also driven by a green dinosaur. And hopefully you can now recognise what is being patented here. Those of you who have small kids and watch Australian ABC television. So, that is a really simple patent, and that’s how you go through the process.

At this point, we’re going to go off and have a look at a real patent. Now, this is a patent that has been defused. It’s current, but it’s been defused because it was part of the settlement out of the European Commission, where we got a universal licence for the whole free software fraternity and all third-parties, from Microsoft. It’s no longer a patent that is a great threat. Plus, even before that, we had sufficient analysis to be completely confident that this wasn’t a problem. That’s why, after talking to the appropriate people in the Software Freedom Law Center, that this was chosen.

Let’s have a look. So this is a real patent. Notice that, first of all, it’s a scan. This is a 1998 patent. A lot of them are scanned. If you look at it, it’s something like patents.google.com, or one of the other patent searching things, they’re often there as text. Cut-and-pasteable text. Real HTML. You need to be careful. The OCR process is not perfect. You get real clangers occaisionally in the OCR. If this is a patent that you care about, you do have to go back and check the PDF, look at it yourself and make sure some key term that you’re relying on is not written differently in the original scan. They can be different.

Okay. Let’s have a look at what this patent looks like. So this is "a method for changing passwords on a remote computer", and what we’ve got down here is a priority date. This is the date it was filed. So January 12th 1996 it was filed. So our first guess, our first estimate of the priority date is January 11th 1995. Now, it could be earlier than that. It could be earlier based on continuations or other criteria but it’s a good first estimate for prior art, if you’re looking for prior art.

[↑menu↑]  It’s got this bit over on the right which is the "Abstract". That bit over there. And, you don’t just read that. You should read it. I do find it useful reading the abstract, but don’t stop at the abstract. You are really doing yourself a major disservice if you just stop at that point. It’s got things like the references cited, down there. And it talks about earlier patents. That’s very useful when you are trying to work out what the actual words in the claims mean. A lot of the task of patent defence is about narrowing down, or working out the breadth of meaning of a particular set of words or phrase. The previous patents that are declared in this can be extemely useful for that. As can several other sources of information that I’ll go through later on in this talk. At this point, there’s then a bunch of diagrams and things: skip them. At this stage, skip them. At this stage you jump right through and hidden deep inside the patent somewhere… Oh, there’s a "Background to the invention", skip that too. The Background to the invention really just helps you to define terms later, but you’re not into the defining of terms yet because you don’t yet know what terms you need to define. And the Background to the invention will leave your head spinning, very likely, so you then might not be mentally capable of understanding the claims.

Right. So let’s keep going down and going down. Down, down, down, down, and down. And somewhere here, there’s actually going to be a patent. Here it is! There we are there: "What is claimed is". Notice just how it stands out.

[audience laughter]

Right? They really want you to find this bit. "What is claimed is", and that’s what really matters, and here it is. And you can see there the first claim. What’s that first paragraph before the colon? What’s that called? The "claim preable", right. There’s your preamble. You need to read that to understand the scope, the setting that you’re dealing with, and then after the colon, comes what? And "independent claim element". A claim element, and because it’s the first claim in the patent, it’s pretty darn likely to be an independent claim. Otherwise you’ve got some funny loops in the patent.

So, the actual claim is "computing by the client a first message by encrypting a first status sequence". This is the point that you start taking notes. What’s a client, in this context? I mean, is it somebody who buys something? They’re a client? No? Is it maybe something on a network? Talking about network client-server computing? Could that be it? Y’know, you start taking notes about what these words might mean, so you can actually translate that into your own terms of reference as an engineer in this field. So, "…first message by encrypting…" — what is encryption? what does "encrypting" mean? Reversible encryption? Non-reversible encryption? A hashing? Y’know, what’s included in that? And this is where you start… at the term you have to work out what the hell they’re talking about, by "encrypting" And you need to go and find out by reading other parts, other sections of the patent. Look up in encyclopedias. There’s all sorts of things you can get information on what that might mean in this context. The diagrams might help. All sorts of things help. Etc. etc.

And notice that within that, there’s lots of different elements, and your job in building a non-infringement patent defence, is to highlight sequences of words that you don’t do. And, very often you only have to find one. This is what people often don’t understand about patents. An engineer reading a patent usually reads it like he would go to a talk at LCA, and he’ll talk about "oh yeh, the ext4 filesystem, just like the talk I heard on the ZFS filesystem at this other one" Patents tend to be more specific than that, usually. Usually the terminology is more specific. And just because 90% matches, if the last 10% doesn’t: you don’t do it! If that 10%… if you can really show you don’t do one of those required elements: you don’t do it. And that’s were a lot of the agro on Slashdot comes from. People say "Ah, but somebody else did it in 1960" — yeh, but they put a comma after it. Right? They did something slightly different. They were using MB4 and here’s someone else that was using MB5. Whatever, there was a difference.

And if that difference is encoded in these claim elements, that matters. And you’ve got to communicate that. It’s your job not to just blow your stack at the whole patents system, y’know, and when you’re writing up your patent defence, you’ve got to encode that knowledge of the differences between what you do and what they did and what is in here… encode that in a form that a patent attorney —that has an engineering degree, very likely— can understand. And that patent attorney needs to then look at what you’ve written and say "yep, you’ve got it. Move on. Next patent please" Or the patent attorney might ask you questions, he might say "ahh, but did they do it in this way or that way?" and you’re going to say "oh, well, I’m not certain." Back to the drawing board. That’s how patent defence works.

Ok, so they’re the bits that really matter. And you can see there, that that first claim goes over half a page, and then eventually comes onto the next page, where that first claim continues. Then we get the second claim, over here. This second claim over here is a dependent claim: "the method of claim 1, wherein…" etc. etc. etc. And so on and so forth. That’s how you go through a patent.

Moving back to the main talk. You’ve seen a real patent now. You’re all tainted. Let’s talk a little bit about prior art. As I have said again and again, because it’s important within this community to understand it, prior art is not a panacea. It is very very hard to kill all claims. Look at the length of that patent, look at the complexity of some of the claims. You’ve got to knock them off completely. Not just one claim element but the lot. It’s like, a massive amount of work, if you can even do it.

Claims are also interpreted, very often, much more specifically than engineers expect. If you are trying to make a prior art defence, then what you are trying to do is you are trying to make the claim terms as broad as possible. If you are trying to do a non-infringement defence, you want the claims to be as narrow as possible. Those two things are opposites. And that’s a very difficult thing to do.

There is a type of prior art that’s a little bit better…

Audience member: So if I’m being sued by some patent, is it practical to do a combination of: I don’t infringe these terms, and these extra ones are…

Andrew Tridgell: Maybe. You’d have to look at the specific case with a patent attorney on that, but you’re on unsafe ground. You’re on very unsafe ground. You’re standing on one of the bogs in Rotorua.

Audience member: If you can show that you are infringing on an earlier expired patent…

Andrew Tridgell: Right. You would never say you would show you’re infringing.

Audience member: Well, not infringing, I’m sorry. You would be infringing if that prior patent had not yet expired. Would that in fact be the… they could…

Andrew Tridgell: My understanding is: no. I’m not enough of an expert to say absolutely, but usually, I think the answer would be no, and that that wouldn’t be sufficient. That’s basically a prior-art defence.

Audience member: For your earlier Wiggles example, would I be able to say: "My panels are metal"? Or, "my car is green", would they be non-infringement…?

Andrew Tridgell: If it says "a red car" and your car is green, that’s… you’re not matching that element.

Audience member: It is that obviously simple?

Andrew Tridgell: Yeh.

Audience member: My panels are actually…

Andrew Tridgell: Your car is green. It said "a red car". Your car is not the same colour as what it says. It’s a required element: red car. You car’s not red.

Okay, so, let’s move on a little bit. Invalidating a patent is also very hard, even if you’re successful, patents can come back from the dead. There’s the famous case of the VFAT patents that were invalidated and came back. The patent doesn’t have a "final, it’s really dead" sticker to put on a patent. They have things called "final rejections" — a single patent can get six of them, and then it can still be back. A real final rejection doesn’t exist. And of course, when it is resurected, it’s even harder to kill — just like Buffy.

[↑menu↑]  You’ve got also… you may need to read the file wrapper. The patent office is not always incompetent. They have often thought about prior art. They often interpret claims very narrowly. Let’s show you what a file wrapper is. A file wrapper is the record of the entire conversation between the patent office and the patent applicant. Hundreds of pages of scanned letters and emails and things like that, going through the entire years and years of discussions. Everything noted down in precise detail.

We see letters here where… the really interest bit is the letters from the patent office to the patent applicant, rejecting some of their claims, saying "I am rejecting claim 3 because the following prior art…". The file wrapper serves to narrow the meaning of the words. Because, if the applicant responds to the patent office and says "Oh, but the word doesn’t mean that, it really means that" — in order to try and wedge the patent through. In doing so, they have narrowed the meaning of those words. And they can narrow them extraordinarily narrow. So reading the file wrapper can be a useful source of ways to narrow it.

It can also be useful for humour as well. This is part of the VFAT patent reexamination, from the patent office, and I don’t know what Microsoft was smoking when they sent that, but, I don’t know what that chemical formula is! Anyway, they make mistakes sometimes. They’re human.

Okay, so, what do the claims mean? You get hints on what the claims mean from several sources: descriptions of the claims, industry terminology. It’s not like code. It eventually gets resolved at something called a markman hearing, where the judge, and the two sides get in front of the judge, and they decide exactly what something means. That’s called a markman hearing. If you get to a markman hearing, you’ve failed in your patent defence efforts. Your supposed to knock things off… it’s not supposed to go to court. How many of you have done patent analysis with a patent attorney? A few? Okay. How many have ended up going to court? Right, almost none. So if you get to that stage, really, you’ve flunked patent analysis.

You can also often have a bet both ways. You can say something like, "if the claims were broadly interpreted, then it would be invalid due to X, X, X, but if it’s narrowly interpreted, then we are not infringing". That sort of thing often comes up. It’s not ideal, but it often comes up.

[↑menu↑]  Okay, claim chart. This is how to get yourself organised. Unfortunately, I’m running low on time. A claim chart is a way of organising your defense arguments, and it’s a way of communicating with patent lawyers. What I’ll do is, I’ll just go straight to bringing up a claim chart. Here’s a claim chart. This is a claim chart for that same patent, and this is my first draft as an engineer. The lawyer hadn’t seen this yet. This is my first attempt, and I’m looking at the patent and I’m starting to analyse it. All of the words of the claims are in the first column. Every single word. The reason every single word is there, broken out into the different elements, is you want to make sure you don’t miss one.

Then there’s matching: "server = could be samba 3, maybe samba 4, perhaps when running as a PDC, maybe" Y’know, it’s notes on what it might mean. What is a "server" in this case? What do the terms mean? What possible prior art, in this other column, what it could mean in somebody else’s context, what other people did this sort of stuff. This is how you take notes. You might have a sketch of your defence up the top, as from an engineering point of view. Hasn’t been vetted by a lawyer yet, just your rough sketch. You send this, these notes, to the patent attorney. That’s your first communication, one of your communications. You might establish privilege first. That’s how you communicate: you write one of these things called a claim chart.

[↑menu↑]  Now I want to get on to the second half of my talk, which is going to be very brief, which is: what can we do? I believe that patents are unfortunately going to be more and more of a problem for the free software community. The GPL, for I think very good reasons, requires extremely broad licensing if patents are ever licensed — if a licence is used as a reason why you can use a patent. Requires extremely broad licensing. Witness the Firestar patent that Red Hat licensed, but they licensed it for the entire community.

Unfortunately, that sort of licence also has a down side. It was an extroadinary thing that Red Hat was able to do, but it also has a down side. The down side is this: imagine you are a patent holder. You’ve got a patent here. You want to try the waters out there with this patent, to see how much money you can make out of it. What do you do with that patent? Well, you could… if you go to sue a company that is required to license the patent for the entire community, then if you convince them, then they’ve got to pay you a licence fee for everyone. The licence fee is going to be huge, right? And they have no choice. They’re required by the GPL to do broad licensing. So that makes you potentially a very attractive target for the patent holder.

So how can we turn that around? How can we make ourselves a tough target? And I think it’s very important that we be the toughest, meanest target for patents on the block. We can do it, because we have something that other people don’t. We have a technical community that is really really good at the sort of logic of protocols you need to defend against patents. If we can find a way to coordinate within that community to actually build the patent defence, then we can do something rather interesting: if any time somebody in a carpark mentions some patent and FOSS might violate it, jump on it! Squash the living daylights out of it. What do you do? You find a non-infringement argument. You find a workaround. If you find a workaround, then you shout it from the rooftops. You publicise it.

What does publicising that workaround do? What does it do to the motivation of the people who own the patents? The people trying to make money out of these patents? If you publicise the workaround, then not only do they not get the licence fee from the free software community, they might stop getting the licence fees from the proprietary vendors as well because those proprietary vendors say "hmm, we don’t have to pay $10 for a copy anymore, we can use this workaround the free software community has found". So that means that this person holding a patent, wondering who to strike first, wondering who to try this patent out on, will say: "if I try this out on a proprietary company and they find a workaround, they’re going to keep it secret, because they want to keep it secret because they don’t want other people to have the workaround because they want to be the only ones not paying the fee.

If we go after the free software community, they’re going to advertise the workaround, we might lose our entire value of this patent. We might lose the lot. And it’s expensive, getting patents, expensive maintaining them. So they don’t want to lose them. That’s where I want us to be as a community. I want us to jump on patents, squash them, find workarounds — but rigourously, not the Slashdot way of the title and "Apple did it in 1915" or whatever. Not that sort of thing. It’s the type of serious analysis that I’ve tried to show you how to do today. I’m sure that nearly everyone in this room is quite capable of doing this analysis. You’re the type of engineers that can do it. You just need to be lead a little bit along the way, to start building up your knowledge of how to analyse patents.

The problem is that we’re hamstrung by privilege. This is something that I haven’t worked out how to solve. Companies don’t like their employees talking to other employees about patents. For good reasons. We need to find a forum where we can communicate without causing all the lawyers to have heart attacks, so that we can take advantage of our collective engineering knowledge to make ourselves a tough target. If we can do that, we will be the meanest, badest guys on the block when it comes to patent defence, and nobody’s going to be able to take us on.

Thank you.

[applause]

[↑menu↑]  Questions? Anyone first, I don’t mind.

Audience member #1: Let’s say I had a patent on the red car you were talking about earlier…

Andrew Tridgell: You hold the patent.

Audience member #1: Yeh. And let’s say I did not like the Not Much Email project and I wanted to put them out of business…

Andrew Tridgell: Using the red car patent?

Audience member #1: I could sue them using the red car patent and because they could not afford to get a lawyer and continue, I could put them out of business.

Andrew Tridgell: Nah. People sometimes say that on the red car and sue some mail client. It just won’t happen. Any example of anyone ever doing that? They’d just get laughed out of court. The judge would say "Go away" — might even slap a fine on them.

Audience member #1: Well, SCO is a perfect example, completely invalid lawsuit…

Andrew Tridgell: Nah, they didn’t do that. That wasn’t a patent law suit. It wasn’t anything like that. That type of threat… maybe in other areas, perhaps, there’s this thing "slapsuits", but in patents it’s unknown as far as I’m aware. I’m not aware of any cases like that. If you’re aware of an actual case that has happened somewhere in the world like that, let me know. Until one has happened somewhere in the world, I wouldn’t consider it to be a real concern.

Also, there are legal resources in the free software community. The Software Freedom Law Center, Linux Foundation, others. They have patent attorneys available. There is plenty of legal resources out there for a real threat like that. If NotMuch got sued over the red car patent, then some lawyer on his weekend would write a letter and it’s gone. It’s just not an issue.

Audience member #2: More of a comment than anything else, just, in New Zealand, the 1953 Patents Act still doesn’t really provide a facility to access the file wrapper. And, that’s just something for people in New Zealand.

Andrew Tridgell: Even buying the file wrapper? You can’t buy the file wrapper?

Audience member: No.

Andrew Tridgell: You may find that the file wrapper is available… Very often, patents are filed in many jurisdictions. It would be quite unusual for a patent only to be filed in New Zealand, but might be in thirty or forty jurisdictions around the world. One of them might provide the file wrapper sufficiently. And, in particular the US one. The US Patent Office site itself you can get file wrappers. Delphion is very good. You can sign up for a free account on Delphion and you can purchase file wrappers one at a time, a couple of hundred bucks a throw, for a file wrapper. Most of the time you don’t need the file wrapper. I wanted to show you a way you can go if you need to define terms, but for the vast majority of patents I’ve analysed, I’ve never needed the file wrapper. And when you do want one, it might cost a couple of hundred bucks, but if you’re spending weeks of your time on that patent, it’s worth a couple of hundred bucks to buy the file wrapper. And somebody else might buy it for you. Just ask on a mailing list — "can you buy me the file wrapper for this patent?" Or, I might not do that on a mailing list, but you might go talk to SFLC and get them to buy you the file wrapper.

Next question? Oh, we’re out of time? So, if anyone else wants to ask me questions, then we can meet up outside. We need to get on with the next talk. So, thank you very much.

[applause]

END.

---

End Software Patents note: You can assist campaigns against software patents by contributing to the en.swpat.org wiki.

---