The Puget Patent Blog
Claim Construction in Patent Litigation
Posted Sunday, January 22, 2012.
When interpreting the meaning of patent claim terms, the words are generally given the ordinary and customary meaning that they would have to a person of ordinary skill in the art in question at the time of the invention. The process of ascertaining that meaning is called claim construction.
Court decisions have provided a framework for claim construction in a patent litigation. The first principle is that intrinsic evidence is the first place to look for the meaning of claim terms. Markman v. Westview Instruments, Inc., 517 U.S. 370 (1996) divided evidence for construing claim terms into an intrinsic evidence category and an extrinsic evidence category. Intrinsic evidence is the patent itself, including the claims and specification, along with the prosecution history. It includes affidavits made by inventors, and any content submitted on an Information Disclosure Statement. Extrinsic evidence is anything that is not intrinsic evidence, for example, an inventor’s in-court testimony as to his understanding of the claim terms.
Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576 (Fed. Cir. 1996) furthered the principle, by stating that when the intrinsic evidence unambiguously settles the meaning of a claim term, extrinsic evidence should not be relied upon at all (“is entitled to no weight”) in claim construction. Vitronics also prioritized the various pieces of intrinsic evidence. The specification should always be consulted to ensure the drafter has not defined a term differently than the common meaning of that term. The prosecution history is also to be consulted, although it is given less weight, recognizing that the prosecution history represents a negotiation between the applicant and the USPTO, such that any given document in the file history may not represent the final meaning ascribed to a term.
Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005), affirmed that the intrinsic evidence is most important in claim construction. Particularly, the Federal Circuit held that over-reliance on dictionary definitions was to be avoided. A dictionary may still be consulted when a claim term is left ambiguous by the specification, provided the definition is still used within the context of the specification.
When drafting a patent claim, leaving a claim term undefined in the specification can be perilous. The USPTO, in applying the broadest reasonable interpretation principle, can find a dictionary meaning broader than what is intended by the applicant, resulting in a rejected claim or invalidated patent. For example, in a re-examination case appealed from the BPAI where a patent claim for a financial instrument to receive an inflation adjustment “directly” after a change in a market indicator, “directly” was not defined in the specification or prosecution history, but the applicant’s intent ostensibly was that the instrument be tied to the indicator (“a continuous, one-to-one correlation with the inflation rate”). But the Federal Circuit found a dictionary definition where “directly” meant “in a little while.” This broader view of the claim was sufficient to support rejection of the claim. In re Trans Tex. Holdings Corp., 498 F.3d 1290 (Fed. Cir. 2007). Here, locking down the meaning of the term “directly” in the specification could have distinguished the subject matter from the prior art.
Clarity of Patent Claim Terms
Posted Sunday, January 22, 2012.
A patent application concludes with one or more patent claims, which are the legal description of the intellectual property the inventor considers as his or her own. Among the functions that patent claims serve is to provide notice to others with similar inventions, so as to inform them of what to do to avoid infringement.
Accordingly, the claims must have a particular scope, which requires that claims use terms with meanings that are clearly understandable. If the claim terms can’t reasonably be understood, then a different inventor would not know whether or not a new invention infringed on the original patent claims. So one measure of patentability for an application being examined is whether the terms used in the claims are precise and clear. In other words, the claim terms must be definite.
When interpreting the claim terms, a patent examiner will look to the specification for the meaning of any given term. See 37 CFR 1.75(d)(1). (“The claim or claims must conform to the invention as set forth in the remainder of the specification and the terms and phrases used in the claims must find clear support or antecedent basis in the description so that the meaning of the terms in the claims may be ascertainable by reference to the description.”)
When claim terms in a patent application do not have the precision and clarity needed to permit a reader to understand the bounds of the intellectual property being claimed, the proposed patent claim might be rejected as indefinite by a patent examiner. Just because the claim term is not defined in the specification does not require that the claim term is necessarily indefinite, however. See MPEP 2173.02, Clarity and Precision.
For example, the claim term may have previously been defined in the “teachings of the prior art.” In other words, if the application for a patent is an improvement on an existing technology, then provided the applicant uses the same terminology utilized in prior patents in that technology, the claim term will be construed to have the same meaning as in the previous patents.
If the claim term is not already known in other patents and patent applications in the same art, it still might not be indefinite. If a particular term is a term that one with skill in the art would understand, then the term will take on that meaning. In the case of a patent application for administering and tracking the value of life insurance policies, a patent claim could use the term “surrender value protected investment credits” without further definition in the specification, for example, because one with an average understanding of life insurance administration would know what the term meant without further explanation. See Bancorp Services, L.L.C. v. Hartford Life Ins. Co., 359 F.3d 1367, 1372, 69 USPQ2d 1996, 1999-2000 (Fed. Cir. 2004).
Failing all of the above, a claim term without definition in the specification may not have sufficient meaning to satisfy the requirements of 35 U.S.C. §112, the statute which requires patent claims to particularly point out and distinctly claim the subject matter which the applicant regards as the invention. Still, an examiner has a fairly high burden to meet in rejecting a claim on the grounds that it is indefinite. “Only when a claim remains insolubly ambiguous without a discernible meaning after all reasonable attempts at construction must a court declare it indefinite.” Metabolite Labs., Inc. v. Lab. Corp. of Am. Holdings, 370 F.3d 1354, 1366, 71 USPQ2d 1081, 1089 (Fed. Cir. 2004). “Insolubly ambiguous” suggests that for an examiner to assert a patent claim is indefinite, not a single meaning could plausibly be attributed to a claim term.
"Patent Eligible" vs. "Patentable"
Posted Sunday, January 15, 2012.
I have been a guest blogger on the website of a colleague of mine for a few months. I posted a blog there today on the meanings of the terms “patent eligible” and “patentable.”
I am often asked by inventors whether they can get a patent for their invention. Most often, upon hearing more about the invention, my answer is “it’s definitely patent eligible, but whether it’s patentable is up to the patent office.”
For more about what exactly that statement means, you can view my guest blog post at my colleague Jim Ruttler’s site here.
Obviousness and Secret Prior Art
Posted Monday, January 2, 2012.
Recently, I blogged about “secret prior art.” To review, because the USPTO conducts patent proceedings confidentially, it is possible to conduct a thorough patent search for an invention and file an application for the apparently-novel invention, only to find that another inventor filed for the exact same thing three months earlier. Even if one pays a patent attorney or patent agent to conduct a search and that practitioner gives the green light, because nobody knows what is pending at the USPTO that’s been filed recently, we may find a different application is pending that anticipates our invention. That other pending application is called “secret prior art.”
Anticipation in patent-speak is when another invention for which an application was filed earlier has every aspect of the invention for which we are filing. Another type of rejection at the USPTO is an “obviousness” type rejection. I previously blogged about obviousness recently as well. Essentially, an invention is held obvious when it combines elements from more than one already-known inventions in a way that renders the new invention non-obviousness.
Let’s say you wanted to patent a highlighter pen that had a tape flag dispenser. Highlighter pens are known, as are tape flag dispensers. The result of combining the two would be that everywhere you needed to highlight, you’d also have tape flags at your disposal. This is a likely combination to get rejected by the USPTO for obviousness, because the results of the combination would be predictable.
But let’s say that tape flag dispensers in fact weren’t publicly available when you filed your application for the combination highlighter pen and tape flag dispenser. And it turns out that someone had filed an application for a tape flag dispenser a month before we submitted the application for the combination. Is the combination still obvious?
In this example, the application for the tape flag dispenser would be secret prior art. We’ve already seen how secret prior art can torpedo a patent application by anticipating the invention. Does secret prior art apply in an obviousness-type rejection? After all, in an obviousness-type rejection, the USPTO is asserting that it would have been obvious to combine two existing technologies, but if one of the two is secret prior art, then by definition the inventor of the combination couldn’t have known about it. Why exactly would it have been obvious to combine something nobody knew about?
Conceptually, the answer to this question is exactly the same as in the secret prior art for anticipation instance. With respect to anticipation and secret prior art, the Supreme Court held in Alexander Milburn Co. v. Davis-Bournonville Co., 270 U.S. 390 (1926) that in a perfect world where the USPTO issued patents the day the application was filed, there would be no secret prior art, and that just because we don’t have this hypothetically-perfect USPTO we shouldn’t start making exceptions to the patent laws where two inventors can get patents on the exact same thing.
For obviousness, it’s the same rationale. If there was a USPTO that issued patents the day the application was filed, there would be no secret prior art for obviousness either. In our combination highlighter / tape-flag dispenser case, the tape-flag dispenser would be known by the time we filed for our combination device, and a patent search would have yielded it. The Supreme Court ruled on these very circumstances (an obviousness rejection using secret prior art) in 1965 (Hazeltine Research, Inc. v. Brenner), holding that the rationale articulated in the 1926 Alexander Milburn case for anticipation still held true for obviousness.
Interestingly, in most foreign jurisdictions, secret prior art may not be used in an obviousness-type (aka “inventive step”) rejection.
But in the U.S., secret prior art is becoming more of an issue as patent application backlogs increase. The longer it takes for an application to issue as a patent, the more secret prior art there is. Let’s hope that the recent increase in funding for the USPTO in the America Invents Act of 2011 brings down the application backlog, and thus, cuts down on the universe of secret prior art.
Patent Eligibility of Software
Posted Saturday, December 31, 2011.
Software patents have had much written about them recently. Inventors wonder whether software is patent-eligible, and if so, whether it even should be patent-eligible.
At one time in my career I was a software engineer. Thinking back on my experience writing code has been helpful as I consider patent eligibility of software.
I once worked for a company that manufactured high-speed printing systems. The company combined printing presses, on which rolls of paper passed by a printer mounted to the press at up to 150 feet per minute. As the paper went past the printer, the printer would print an image. Later in the process, the paper was cut into individual sheets, and sometimes folded or glued or otherwise turned into a direct mail piece, or a ticket or a label, for example.
I worked on software that controlled the printers. Often, the software was a mail-merge, the end result of which was a form letter or direct mail piece individually addressed to recipients. Sometimes the software produced individual labels or tickets. I worked on code that was used by a state department of transportation to make vehicle registration stickers that drivers would affix to their windshields. I even worked on a project to produce lottery scratch tickets, where the input data file had been seeded with random numbers that corresponded to images of bells and cherries to print in a certain location on the scratch ticket.
One day, my supervisor told me he wanted me to work on a method of enabling a customer to send a print job to one or our high-speed printing presses by fax. The concept was that a printing system with a fax board in Kansas could receive content to be printed by someone sending a fax in New York. I didn’t really know anything about how fax machines worked, but it was my job to figure them out and then design a way to receive a fax and dump the contents to a printing press 150 times a minute.
As I mentioned, the printing press had a printer mounted to it. That printer had a microprocessor, memory, an input bus and storage. Basically, it was a computer, just without a keyboard and display. We controlled it with programmable logic arrays. I would write a program that would then get burned into the programmable logic array, which was then inserted into a socket on the control board for the print controller.
Code for programmable logic arrays was very basic and low level. For complex tasks, like decoding an incoming fax, it would have been very challenging to create a program to burn to a chip and get it right the first time. So the process I personally used was to first create the code in a high-level programming language, and then once I had the algorithm working correctly, to transform the algorithm to lower levels until I was ready to burn it into a chip and install it into the printer.
First I wrote a piece of software in the Pascal programming language. The software opened an incoming fax data stream and analyzed the stream, rendering it as an image on my computer’s display. This was when I began to understand how fax machines work, and how the ones and zeroes that make up a fax transmission can actually represent an image destined for a printed page.
Once I had an algorithm that could reliably take any incoming fax data stream and correctly display it on my computer monitor, I rewrote it in assembly language for my PC. Assembly is essentially a lower-level language that more directly manipulates the microprocessor and memory of a computer. The reason I re-coded my Pascal program in assembly was because assembly more closely resembles the code that gets burned into a programmable logic array. Now, I had a low-level program running on my PC that interpreted an incoming fax stream and rendered it on my monitor.
The last step was to take the assembly code and re-write it as code for the programmable logic array. The actual commands and syntax weren’t the same, but the order of the steps – the process – was the same. This step was essentially a line-by-line language conversion from a piece of software running on a PC to a program implemented in a chip that got inserted in a socket of a computer control board.
The end result was that we had created a 150 page-per-minute fax machine. The heart of the system was my code that was burned into a programmable logic array -– a chip –- and inserted into a socket on the control board for the printer. That code once existed as an assembly language program –- a piece of software -– running on my computer. The code on the printer wasn’t exactly the same as the software running on my computer because I had translated it. However, the process –- the steps that each piece of code took to handle the incoming data stream -– was exactly the same.
The above example illustrates why software is, and should be, patent-eligible. 35 U.S.C. 101, a portion of our patent laws in the United States, says “Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.” My assembly code embodied a process of opening an incoming data stream, chunking it up into individual segments representing single horizontal lines of dots, and further converting each single line of dots into the alternating blacks and whites of each line which altogether make up a faxed page. The previous sentence represents a process, and whether you run that process from a chip in a 150-fpm fax machine or as a piece of software on a PC, the process itself is patent-eligible.
Put another way, are you going to tell me that a 150-fpm fax machine isn’t eligible for a patent? Now, take all the logic that drives the fax machine and vacuum it up into a piece of software code, which you then run on a computer that has a modem installed for receiving calls from fax machines. What’s the difference? Why is one patent-eligible and the other isn’t? The answer is, they are both patent-eligible, because at the process level (a process being statutorily patent-eligible) they are the same.
Technology has progressed to the point that the difference between hardware, firmware and software is merely a design choice, representing a series of tradeoffs between speed, cost, flexibility of updates and other factors. But give me any piece of software and I’ll distill it into a process -– an algorithm -– which could be easily recoded into a chip and installed in a portable device of some type. That device, by the way, is a machine – a different patent-eligible category.
In my mind, software is patent-eligible. Having the benefit of some experience with creating software and transforming it into different types of machines has helped me better understand why.
‹‹ Newer Entries | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | Older Entries ››