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.



23 Comments

David Billinghurst · 22 March 2010 at 9:56 pm

roadarooa[?] is probably Rotorua http://en.wikipedia.org/wiki/Rotorua

    Ciaran · 23 March 2010 at 2:51 am

    Fixed, thanks. I searched for various phonetic matches but forgot to try it with a ‘t’.

J.B. Nicholson-Owens · 22 March 2010 at 10:16 pm

I’m seeing http://2009.r2.co.nz/20100118/50091.htm as a bad link because there appears to be no process on 2009.r2.co.nz responding on port 80. Perhaps the video could be uploaded to archive.org and the “download” link could be used here instead? archive.org is pretty sweet: unlimited downloads of data of any size, derivative formats created for you automatically, all services provided at zero cost to anyone.

    Ciaran · 23 March 2010 at 3:24 am

    I’ve added a bunch of mirrors now. If someone puts it on archive.org, I’ll link to that.

    archive.org is great alright – en.swpat.org is full of archive.org links. So many campaigns and documents have disappeared and archive.org is the only place where they still exist. …but I’ve never gotten the habit of uploading stuff there.

tranto · 23 March 2010 at 1:33 pm

I’m kind of baffled by the prior art part — why in the world would I need to cover any and all claims for that? Say, if the patent claims A, B, C, …, Z, and only A reads over my work, then I should only have to demonstrate prior art for A, and leave B-Z alone.

Gregory Maxwell · 23 March 2010 at 4:50 pm

Tranto: Lets say that a patent is structured like this (1) A red car; with shiny panels (2) the method of (1) with multicolored wheels (3) the method of claim (2) with jet-turbines (4) the method of (2) with an outboard propeller (5) the method of claims (3) or (4) with beautiful plumage.

Your prior art may slay (1) good, but the dependant claims become increasingly specific and increasingly hard to slay using prior art. You’ve found red cars with shiny panels, but they were used for different purposes, with different propulsion systems, etc.

With a prior art defence you have to kill each part, its not transitive to the dependant claims. What you can do is slay general things with prior art and specific things with non-infringement, but because correctly interpreting the very fine details is hard it’s _much_ better to avoid the patent using a non-infringement at each of the top level terms.

Another reason why prior art arguments are not the best path is because the patent already has been through a bunch of experienced people who were specifically looking for prior-art and narrowing the patent until that prior art no longer applied. Even if you managed to find some possible prior art they missed it’s fairly common that different prior-art already forced them to a level of specificness that avoids your prior art. The plus side is that all this narrowing works in the favour of a non-infringement defence. Because of the peculiar language used in patents it just isn’t always clear to laymen how astonishingly specific they usually are.

    tranto · 24 March 2010 at 11:31 am

    The very specific point that I was trying to make was: if I only clash with specific parts of the patent, then I shouldn’t need to kill the whole patent, but only the relevant claims. Thus, if only fall under a single claim, and none of the others, and if I can kill that claim by prior art, then I shouldn’t need to deal with the rest.

    As I’m thinking of it now, my notion of “irrelevant” obviously corresponds to “non-infringement,” which I’d still need to demonstrate, as I understand from your explanation.

    Thanks for the clarification.

Jose_X · 23 March 2010 at 7:01 pm

I think the best defense (from the pov of those not directly affected but who are able to benefit if you succeed) is to take a suit to the SCOTUS on grounds that patent law (along with that patent) is unconstitutional. The system is too broad, especially when many individuals are hand-cuffed directly. It is much more broad that copyright law. Certainly, the progress of science and useful arts is not promoted and patent law makes no effort to measure or tune itself so that there is even a remote chance that progress is promoted.

Patents are not automatic as is copyright (despite a lot more being at stake and unfair), and they are very expensive. There is no excuse why just these two problems with the law could not have been avoided by Congress. This is just one way in which Congress failed in due diligence in clearly favoring the large and sophisticated groups against innovators (prior art is a joke in terms of leverage against patent attackers because they can stump your growth significantly and can laugh while they use your innovation without restraint).

One clue as to why Congress and perhaps the courts appeared to have failed miserably is that the traditional use for patents was to subsidize small entities against much larger foes. That system has been turned around on its head (especially with software) and makes the patent law’s failings actually hurt ordinary folks and a very large number of innovators greatly — this significantly stifles progress. Worse, the products being damaged are no charge and open software.

A second defense would be to make a lot of noise and ultimately perhaps divert the resources applied towards writing software for the attacked project in order to instead seek and write patents against the attacker and against supporters of the attacker. Let people join you in searching for and in writing patents. Make a lot of noise and consider seeking extension patents on the products the attacker uses or produces.

Then let people see how independent FOSS development is being hampered (and with it very large societal gains are lost) by a broken and very unjust law. Expose the attacker for the crooks and leeches on society that they are.

A third defense would be (as just hinted) to focus on spreading awareness of how bad this law is and how directly it affects FOSS and hence many people. Of course, this is a large task, I mean promoting FOSS in the first place. Make noise to citizens and to legislators. The initial attacker might change his/her mind; otherwise, another defense would be needed.

A fourth defense would perhaps be to explain to the attacker that they are confused. Though the following is not an elixir by any means, today, software is not patentable according to SCOTUS and the trivial step of putting it on a programmable machine is .. trivial. Hence, most software developers and FOSS users likely are not violating the law despite being harassed now and then as if they were infringing.

Again, follow up by making a lot of noise so you can rally support. The attacker, the patent, and the law must be placed in the light. People are abusing the legal system to intimidate competition. In fact, consider reporting the attacker to as many authorities, social groups, media, and government representatives as you can manage (and ask others to help, but try to make their job easy by doing the leg work for them).

A fifth defense could be to actually yield, play their illegal games, and try to change your software. In this case, start by reading this article. Afterward, ask the attacker to detail how they think you are infringing. Also, state your case to the attacker on why you think they are wrong (if you think the attacker is wrong). Finally, query them on the legitimacy of their own use of software. Again, a great defense to a stubborn attacker would be a counter-attack, both at the patent level and in terms of exposing the attacker and their wicked tools.

After I read the transcript (scanning over it indicated to me it has good elements if partly misguided), perhaps I’ll post again. I’m currently avoiding getting into a long discussion on this topic. There is some discussion here http://www.cio-weblog.com/50226711/an_embarrassment_of_patents.php , here http://www.unionsquareventures.com/2010/01/we-need-an-independent-invention-defense-to-minimize-the-damage-of-aggressive-patent-trolls.php , here http://www.tbray.org/ongoing/When/201x/2010/02/22/Patent-Fail , etc. The briefs filed by the FSF http://endsoftpatents.org/amicus-bilski-2009 and by the FFII http://media.ffii.org/BilskiFFII/ACB_FFII.pdf for Bilski are great.

    Jose_X · 24 March 2010 at 12:26 am

    Here is one specific comment from the list of links given: http://www.unionsquareventures.com/2010/01/we-need-an-independent-invention-defense-to-minimize-the-damage-of-aggressive-patent-trolls.php?dsq=30100479#comment-30100479 . It describes a hypothetical scenario to convey various observations about inventing. Experiments should be able to be designed to capture some of those points which argue that monopoly grants can stifle progress significantly.

    Progress is stifled proportionately to the number of inventors that are being hand-cuffed in any of various ways. There are many participants creating FOSS because of the low bar to participation.

    Also, the degree of stifling is generally proportional to the broadness of the IP monopoly. Patents have a scope that is usually extremely broad (vs copyright if we take a tight definition of “derivative works”), considering just how many details are missing from a patent claim. The broader in language/scope the patent claim the more details are missing and more unimagined and unimplemented creations would infringe.

    Also increasingly stifling is that software is created, cloned, distributed, redesigned, re-xxx, etc, in many cases very quickly when contrasted with many tangible products. Software also allows the laws of physics to be violated in the virtualized realm. This impressively fast and otherwise almost boundless creation mechanism means a 20 year monopoly is that much more devastating that would be the case for many other products (certainly for products of centuries past).

    Also, stifling is inversely proportional to the the costs involved with software. Thus, a monopoly royalty takes away that much more wealth from society vs the no monopoly scenario. [Incidentally, the low cost to participate with software is part of why so many would be hand-cuffed.]

    The one link above cio-weblog.com site includes a comment (at the bottom when I last looked) that suggests various general guidelines to still preserve motivations to conduct costly R&D without hand-cuffing so many people and resources through the broad government monopoly subsidies. Remember that these monopolies are tickets to slacking off for many years and mean that potentially a huge number of humans and their contributions for many years will not exist when they otherwise might. It also means the most competent to pursue a problem might be stopped in their tracks, eg, simply for having been distracted working on some other problem or advancing something and not taking out a (costly and antisocial anti-progress) patent or perhaps simply reaching their maturity a few years after the broad patent claims were written. In short, the monopoly subsidy system is insulting and defies reason in so many ways.

    The main reason I mention these things in this article is to help communicate that the patent system’s flaws have been greatly magnified in cases where patent claims are applied to tangible and (especially) intangible products created primarily through the work of software. People should not accept this significant failure of law to promote the progress of science and useful arts in the 21st century. We should be mindful not to lose track of the forest as we dive in to study some trees here and there. Blindly trying to look for prior art or what not can help out the attackers in a number of ways including all the time wasted by us and time not spent trying to work to get this system eliminated or at least significantly neutered so that many fewer inventors and consumers suffer through these broad and long-lasting monopoly grants.

    I have to believe that legislators who have the problems explained convincingly should be able to agree to a at least a few fundamental changes in the system. If not, hopefully sufficient constituents can be rallied to help make the argument.

Jose_X · 23 March 2010 at 7:12 pm

A partial patent dissection: http://www.linuxtoday.com/news_story.php3?ltsn=2000-05-26-004-04-OP-LF&tbovrmode=1

Jose_X · 24 March 2010 at 1:17 am

Should we look at patents? Keep in mind that tomorrow an independent invention defense might be accepted (eg, after a change in law or on a particular Constitutionality argument that not accepting such a defense would almost guarantee by itself that the law would not promote the progress of science and useful arts). If this case comes to pass (where the law still stinks but indep def is accepted), then looking over a bunch of patents could clearly hurt your case regardless of how useless you consider the 3X damage aspect of the law to be.

Jonathan Swartz wrote recently http://jonathanischwartz.wordpress.com/2010/03/09/good-artists-copy-great-artists-steal/ :

>> I understand the value of patents – offensively and, more importantly, for defensive purposes. Sun had a treasure trove of some of the internet’s most valuable patents – ranging from search to microelectronics – so no one in the technology industry could come after us without fearing an expensive counter assault. And there’s no defense like an obvious offense.

Looking for prior art is much less useful (if you want to play the patent game) than actually trying to come up with patents that your attacker is likely to violate. [One such source of patent claims would be extension claims that would cover the future direction of products used or created by the attacker. In other words, you’d add specificity to their core invention, much as Microsoft has almost surely been doing for many years with core dotnet so as to entangle MSdotnet and mono users in loads of liabilities.]

If FOSS devs switched from designing, coding, testing, etc, to writing software patents in an open fashion: (a) much less of useful and no charge software would get written, (b) the patent office would bring in much more money, (c) it would become clear in a few years that anyone attacking FOSS with patents would have their business (and even useful activities) wiped off the map if they pressed on.

I’d rather help make (c) clear without having to achieve (a) or (b). [Even better would be to make sure software is not patentable.] However, if push came to shove and no better way was found, a lot of devs might actually end up becoming millionaires through their patenting and suing efforts (as “trolls”).

If you give in to playing the patent game, perhaps you want to seek patents so that you have actual leverage in the future.

kats · 24 March 2010 at 3:01 am

Very informational, thanks for posting!

Michael Kay · 24 March 2010 at 10:15 am

Great article, very useful. Hope I never need it.

Georg Jakob · 24 March 2010 at 2:35 pm

This is a article describes the fallacies of communication between programmers, lawyers and patent attorneys quite nicely.

There is at least one *CRUCIAL* mistake however: You are by no means on the safe side of non-infringement if you manage to dismantling just one (or more, but not all) of the patent claims. What still can — and quite often will — be alleged is known as “equivalent infringement”, at least in the U.S. and quite everywhere around the EU.

As the U.S. Supreme Court put it in Graver Tank & Mfg. v. Linde Air Prods (USSC 1950): “One who seeks to pirate an invention, like one who seeks to pirate a copyrighted book or play, may be expected to introduce minor variations to conceal and shelter the piracy. Outright and forthright duplication is a dull and very rare form of infringement.”

For starters, even the Wikipedia entry on the doctrine of infringements might be helpful.

    Jose_X · 25 March 2010 at 1:29 am

    You quote from a time prior to the dissemination of inexpensive computing, software, and online communication. We can tolerate a broken system if the players are all huge corporations or the small guy is on the “inventor” end seeking protection. With many fewer inventing entities (and involving essentially large firms as the potential “abusers”), we are less likely to have clashes or can give the benefit of the doubt to the alleged inventor.

    Once we move to the domain of attacking small businesses or individuals, we have to revisit our assumptions and also realize that the rough parts of the law can get magnified tremendously.

    The SCOTUS hearing on Bilski should have made it very clear that the Justices were very hostile to the notion of the patenting of business methods, even if arguably such would be allowed by the law as written. [Note business method patents also weren’t an issue in 1950.]. As I just mentioned, when we deal with material goods that cost a lot and where much time might be needed to distribute and recoup costs (though likely much less than 20 years), we can look aside some problems and even worry about the “poor inventor” being shut down unfairly. When we deal with “inventions” within the purvue of ordinary folks and small firms, we have to realize this system is very broken.

    Also, note that copyrights are $0 and this means anyone can participate. We have a much more educated population today, so this $0/auto combo is very useful. We also have much more advanced (cheap) tools and collaboration available today [yes, copyright law needs more revising as well.] Patenting is still not $0 and implicit. This creates a tremendous disadvantage for the small entities (who in the past were assumed not to be participants by and large — obviously, an assumption that doesn’t hold for software today).

    Again, as stated in earlier comments above, SCOTUS has ruled software is not patentable and it is a trivial step to load it into a computer. [Except at the hardware interface end] software are algorithms based on an ideal model that transcend physics. Software is already covered by copyrights. Well… I won’t repeat everything I’ve already stated above….

      Georg Jakob · 25 March 2010 at 12:48 pm

      My point was not if the system is broken or not. And I have high hopes in the upcoming Bilski decision as well (so high that I actually co-submitted an amicus curiae brief).

      The point of my comment is that it is misleading to suggest that by

      0. reading patents
      1. not caring about dependent claims
      2. making sure you’re not using ALL elements of an independent claim 3. you can’t be infringing the claim in question and therefore you’re on the safe side

      is misleading at best and probably quite dangerous. That’s one of the
      main reasons why software patents are so dangerous and
      happily coexisting with them is a much more complex issue than
      Andrew’s talk suggests.

    Andrew Tridgell · 25 March 2010 at 7:01 am

    Unfortunately the time for the talk didn’t allow me to discuss the doctrine of equivalents.

    You are right that it can mean that patents are more broadly interpreted, but the key thing to understand is that
    the doctrine of equivalents is a fragile thing. It can easily be lost, especially through the normal to-and-fro discussion
    between the patent office and the patent applicant.

    For the patents I deal with, it is common that the patents have been through a very lengthy process of rejection and revival
    during the examination process. This may leave very little of the doctrine of equivalents left for the patent, if any. That is
    also why I suggested that reading the file wrapper can be helpful, as it tends to narrow the claim construction.

    The main idea of this talk was also to teach people how to prepare material for a patent attorney to review. The patent attorney
    will be able to offer an assessment of how broad the claims of the patents would be interpreted at a potential Markman hearing.
    It is still up to the engineer to present the possible non-infringement arguments, it is then up to the patent attorney
    to decide of that defence material is sufficient.

    I am planning on writing more extensive “field guide to patent analysis” at some stage, perhaps as a series of blog postings which
    would then be collated into a single work. I’ll have more time in that format to do into detail on these sorts of issues.

    Teaching patent analysis in a 45 minute talk was always going to be a challenge 🙂

    Cheers, Tridge

      Georg Jakob · 25 March 2010 at 1:14 pm

      Hi Andrew,

      First of all, let me say that I admire your work, especially on Samba 🙂

      I think your message, as far as you encourage reading and carefully analyzing patents is a *very* important one.

      But I’m also afraid you’re dangerously underestimating the power of equivalent infringement. Maybe what you suggest is true for Australia – I don’t know anything about the specifics of that country’s patent system.

      However in the E.U. and the EPC member states (especially in Germany, the leading “patent country” under the EPC regime), equivalent infringement is a *very* powerful tool. Probably as many infringers loose their case based on it as on direct infringement. From what I understand, in the U.S and Japan it is a quite serious thing, too.

      I understand that it is difficult to say everything important in only 45 minutes (oh my, I suffer from the same problem in almost each of my talks…) but I suggest it’d be important to at least clarify that one would have to check *all* elements of the independent claims and should at least also generally consider what the dependent claims add to that.

      Or you’ll have to put more emphasis on the fact that all these suggestions apply only when one is already talking to a lawyer and building a defense in a case.

      You’re suggesting that by only checking some elements of independent claims and ignoring dependent claims, we are “safe”.

      We are *not*.

        Andrew Tridgell · 26 March 2010 at 12:36 am

        Hi Georg,

        My primary experience has been with the US patent system, and my talk
        was based on spending many years working with very experienced patent
        attorneys in the US system.

        When I write this up more fully, instead of in a short talk, the type
        of reference I will use will be this sort of thing:

        http://nopr.niscair.res.in/bitstream/123456789/3068/1/JIPR%2014%281%29%207-13.pdf

        which explains the doctrine of equivalence quite well, as well as the
        ways that the doctrine can be limited by the prosecution history,
        prior art and other considerations.

        My experience has been that the broader the patent claims look at
        first glance, the more that you end up finding they are narrowed by
        the prosecution history. This is not a hard and fast rule, it is just
        the observation based on the patents that I have had to develop
        defensive materials for.

        The aim of my talk was to teach engineers what they should do. It
        wasn’t a talk aimed at patent attorneys, or even general lawyers. It
        is the job of the engineer to put forward the best non-infringement
        arguments they can, then it is the job of the patent attorney to shoot
        it down based on a judgment of the likelihood of the success of the
        defense, usually using as a basis whether a positive result at summary
        judgment is likely.

        I have had plenty of my non-infringement arguments shot down by patent
        attorneys. When that happens I go back and develop better arguments,
        or I work out ways to change the code so the weaknesses in the
        arguments are removed.

        I do not want to stop people from developing non-infringement
        arguments because they are afraid of the bogey man of the doctrine of
        equivalents. It is not for a lay person to judge whether the doctrine
        applies in a specific instance. That requires deep knowledge of the
        patent system, and possibly consultation with a patent litigator.

        I tried to be careful in my talk to emphasize the importance of
        presenting your arguments to a patent attorney. I hope that came
        through clearly enough. What I really want to do though is stop the
        insanity that currently prevails in the FOSS community where people
        stop at the title or abstract of a patent and shout “prior art!” then
        think they are done.

        If I can get people to start developing non-infringement arguments
        instead, then I think we will have moved forward a long way.

        Cheers, Tridge

Jose_X · 25 March 2010 at 1:47 am

Let me note something else. Patent monopoly subsidies are subsidies most have deemed worthwhile (in part) as a check against abuse by large wealthy groups. At least this is the traditional justification for such an imperfect system. In the past, you would not expect someone in their garage to come up with an invention and seek to distribute it widely very frequently or without patents to help them out.

Today, we have a totally different picture with software. Not just a few or some but a great many people do create in their “garages”, and in fact beat out the large “bully” corporations to the distribution punch, all without even considering taking out a patent or even a major loan. This was an unheard of concept when patent was worked into law. [Note that when creation is inexpensive, you find many talented people willing to create for something greater than money.]

Because of the special properties of software, many did not attempt to use the patent system on software; however, the greediest among us eventually realized what was perhaps possible and sought exploitation, and others had to move as well for defensive purposes (in fact, the line between hardware/tangible and software is blurred).

Today, this patent system is being used not as it was intended. [Something like the machine test from Bilski was essentially implied throughout our history with patenting.] As an individual user or small business or even a larger user, I should never have to worry about software patents being used against me. Not only might the law as it stands today back me, but arguments of equity and reasonableness surely do.

Clifford Heath · 29 March 2010 at 2:05 am

Tridge,

You might recall the occasion when I pointed out how rsync infringes Travelling Software’s patent, and how the protocol could be reversed (checksum blocks on the sender, scan on the receiver) to avoid the patent – which actually improves the scalability of file distribution servers because the block checksums can be pre-computed and no server-side computation is needed, just an HTTP server, and even an HTTP cache, including one that can cache partial (HTTP subrange) entities (does such a thing even exist?)

I never understood why you didn’t take that suggestion seriously. Is it because you never actually received an infringement claim from TS? My employer took the possibility seriously, and we even improved on the reversed protocol by using compressor flushing to allow remote differencing of compressed files (as also discussed with you at the time)… The technique is unencumbered AFAIK – we certainly didn’t proceed with our patent application, thank goodness.

On another note, if you’re hit with a patent attack and you clearly don’t infringe the patent being used, yet due to whatever reason it goes to the (hella expensive) “process of discovery”, is there any way you can shortcircuit that process by reactivating a non-infringement argument?

    Andrew Tridgell · 31 March 2010 at 12:02 pm

    Hi Clifford,

    yes, I recall it, and you may recall that I didn’t agree with your
    assessment. The situation with rsync is quite complex, and it is
    certainly not nearly as clearcut as you make out.

    I have spent considerable time looking at the various patents on
    differencing techniques. As is common, I can’t disclose the details of
    that analysis (that is one of the problems with this field, and is why
    I chose a defused patent and a made-up patent in my talk).

    On your second question, my understanding is that there is no need to
    ‘re-active’ the non-infringement argument. You should discuss with a
    patent attorney for real advice, but I think the most likely way it
    would go is you would try to prevail using a non-infringement argument
    as a summary judgment motion. You would also put your claim
    construction arguments at the Markman hearing (if it gets that far).

    This is straying outside of my area of expertise however. What I’m
    trying to teach is patent analysis from the engineers perspective,
    where the primary role is to develop the argument which can then be
    presented to a patent attorney. I want to ensure the engineers in the
    FOSS community know how to present their knowledge effectively, and to
    ensure they know what their role is in the whole patent defense
    process.

    Cheers, Tridge

      Clifford Heath · 1 April 2010 at 2:38 am

      Thanks Tridge. The non-infringement path wasn’t taken (this was several years ago), but I believe the attack was stymied anyhow, not sure how. Not until after it cost a heap though… annoying. I suspect that the process of discovery can be abused by scum-sucking IP companies looking for more complainants too, despite it no doubt being an illegal use of the material. I’m glad it’s not my problem now…

Comments are closed.