PATNEWS: Version 0.0 of my patent claims analysis program
Gregory Aharonian
There are six related problems when it comes to handling patent
applications inside and outside the Patent Office. These problems are:
1) determine the classification of the patent application
2) contrast the patent application with issued patents
3) contrast the patent application with non-patent prior art
4) analyze the patent application in light of statutory rules
5) analyze the patent application for style considerations
6) prepare claims charts for invalidation purposes
While all of these problems have requirements specific to the task, they all
share to some degree one common problem: understanding the structure/content
of the patent claims. Know this, and problems 1) to 6) lend themselves to
having useful software tools developed.
Automated patent claims analysis is aided by the fact that patent claims have
(some) structure imposed on them statutorily, and are written mostly clearly
due to the decompositional nature of technical inventions. Despite these
advantages, it is surprising that there are so few tools for computer analysis
of patent applications beyond spell checkers, SmartPatents of Palo Alto being
one of the few to do anything non-trivial.
To address this issue (and to automate part of the development of my software
prior art databases), I have been working on a program to analyze patent
claims. My goal is to create a system that can parse patent claims, and feed
the resulting parse trees to expert systems for the above problems and others.
It's actually somewhat of a tricky problem, in that while the majority of
patent claims are easy to parse and decompose, there is a few percent that
even confuse humans (including one issued claim where the transition clause
was at the end of the patent).
Attached to the end of this email is version 0.0 of the program. The
attachment is UUENCODED, which when you decode results in a file CLAIMS.ZIP,
which contains two files, CLAIMS.EXE and TEST.CLM. CLAIMS.EXE is a plain
DOS executable, and should be invoked with the command CLAIMS TEST.CLM
at the DOS prompt (you need color graphics to see the output). After a little
analysis, it writes a file RESULTS and then displays a color coded version
of the patent claims on your screen. You can basically scroll up and down
through the color coded text. Ugly, but illustrative.
The program is quite primitive and guaranteed not to work on much of anything,
but it does demonstrate what can be done. You can adapt other sets of claims
to the generic format you will see in the file TEST.CLM, but I don't promise
anything. I am thinking of starting a for-fee monthly email newsletter this
fall where I talk about patent claims analysis issues and periodically send
out updates to the program (I am thinking of $30/$300 {people/firms} a year).
Before I pursue this further, I thought I would get some feedback from you all
on the potential utility of such a tool. Run the program, look at the output,
and let me know what you think: what you like, what you don't like, what you
want added in terms of features, etc. No comment on the user interface (it
stinks), and no comments on the sacrilege of trying to automate any sort of
patent analysis (especially by a rank amateur like myself), or my current
interpretation of examining rules as implemented in the program (they are
probably wrong). Its utility is in what it suggests, not in any real use.
What I want is suggestions, ideas, etc.
Currently the program is standalone, but could be converted into the macro
languages inside word processors, or as an add-on module for groupware
products like Lotus Notes. If I find some funding, I want to create a Java
accessible patent full text database onto the Internet, and develop the patent
claims analysis tools in Java so that people could do a wide variety of
technical analysis and query on the Internet. Million dollar project, but
it would spin off lots of tools and products. (Anyone out in Silicon Valley
interested in teaming up with me on this, give me a buzz).
Anyways, I'd appreciate it if you could take a look at it and let me know
what you think.
Greg Aharonian
Internet Patent News Service
/* ------------ Cut here, uudecode, and then unzip. -------------------- */
begin 666 claims.zip
<uuencoded_portion_removed>
<4U0N0TQ-4$L%!@`````"``(`;@````62````````
`
end
Alan Engel
Question:
Can one write a program for analyzing claims when one doesn't
understand what a claim is?
John Nagle
Sure. Claims have to be written in such a rigid style that
machine parsing of them is reasonable. The idea, I expect, is
to extract the dependency structure ("The apparatus of claim N, where ...")
and display it in some useful form.
John Nagle
Andrew C. Greenberg
Even there, it is unclear to me how helpful this can be. Although some
attorneys draft claims "clearly," I have found that the process of manually
parsing these claims is VERY important in comprehending how that dependency
works, and that the actual dependencies of subordinate clauses is usually
far more subtle (requiring deeper semantic analysis than a merely
syntactice review of the connecting words and punctuation) it seems.
Indeed, an automatic parse and print may be as misleading as it is
helpful. But I would certainly find it useful to look at the results of a
few randomly chosen examples (and I have some convoluted ones in mind for
testing) to see how useful or useless such a program could be.
I have found the programs that take the text of a spec and break it down
into the descriptive phrases a very useful tool for drafting. Recognizing
that these guys are as limited as spell checkers in producing good
documents, or understanding the meaning of a document, they can be pretty
helpful from time to time.
--
just another view,
Andy Greenberg (wer...@gate.net)
Carlton Fields
Alan Engel
John Nagle wrote:
>
> Alan Engel <aen...@netaxs.com> writes:
> >Question:
> >Can one write a program for analyzing claims when one doesn't
> >understand what a claim is?
>
> Sure. Claims have to be written in such a rigid style that
> machine parsing of them is reasonable. The idea, I expect, is
> to extract the dependency structure ("The apparatus of claim N, where ...")
> and display it in some useful form.
>
I was referring more to the programmer than to the task. I would be
surprised if Greg is doing much more than co-occurrence analysis.
I agree with you about the structure in claims. That and the precision
required in patent specifications is what leads my to believe that
patents are more amenable to machine translation than other forms
of text, in contrast to conventional wisdom.
Fred Meeker
John Nagle wrote:
>
> Alan Engel <aen...@netaxs.com> writes:
> >Question:
> >Can one write a program for analyzing claims when one doesn't
> >understand what a claim is?
>
> Sure. Claims have to be written in such a rigid style that
> machine parsing of them is reasonable. The idea, I expect, is
> to extract the dependency structure ("The apparatus of claim N, where ...")
> and display it in some useful form.
>
A standard claim tree would seem to be useful.
Fred Meeker
Alan Engel
Fred Meeker wrote:
> A standard claim tree would seem to be useful.
This is interesting. What is a standard claim tree?
Does anyone use them? And where can I learn about
them?
Alan
Bill Larkins
Alan Engel (aen...@netaxs.com) wrote:
I assume he's merely referring to a chart showing claim dependency.
Robert P. Bell
Yes, and I've never heard of a "standard" one. Even in Patent Academy,
when I asked the instructor how to draw a claim chart, he replied "use
whatever format you are comfortable with". Of course, a PTO file wrapper
has a standardized claim chart (table) in it, and I follow that format
closely.
So..... If you really care, here is the Bob Bell method...
First, I circle independent claims, which I will illustrate here with
parentheses, e.g., (1) means claim 1 is independent (it always is, BTW).
Second, I use an arrow after a dependent claim to show what claim it
is dependent from.
Third, I use the PTO check mark and equal signs (from the file wrapper
claim chart format) to indicate rejected or allowed claims. "=" menas
allowed, "./" (the closest I can get to a check mark here) means
rejected.
Fourth, I draw the claim chart veritcally on the inside of the file
wrapper (in the margin) - that way I have a road map of the claims while
I am reviewing the case.
Miscellaneous notations migh be added to remind me about the scope of the
claims or other notes. e.g., "A" for apparatus, "M" for method, "o" for
objected to, etc.
Example: A ten claim case with 3 independent claims might have a chart
like this:
A (1) ./
2 -> 1 =
3 -> 1 ./
4 -> 3 =
M (5) =
6 -> 5 =
7 -> 6 =
A (8) ./
9 -> 8 o
10 -> 9 o
Or you can use whatever notation you desire. A "tree" might look more
like a directory "tree" for your computer and might have further
notations as to the scope of individual claims. There really is no
"Standard" format.
Enjoy.
--Bob.
Alan Engel
Thanks for the description of a claim tree.
I gather that they are not standard day-to-day fare for analyzing
patent information.
Robert P. Bell
Au contraire. If one is to analyze a patent from an infringement
standpoint, one should look to the _claims_. As I've said before "The
Claim's the thing!". So-called "analysis" based upon patent abstracts,
specification, or drawings is dribble.
Similarly, in the prosecution arena, a patent, when applied as a
_reference_ is looked upon for its _teachings_, not what it claims.
It never ceases to amaze me in this regard. I expect Joe Public, or the
Engineers I work with to miss this point. A typical Engineer, when
confronted with a patent applied against his application will immediately
go to the _claims_ of that patent. "See? He doesn't claim this! This
refernce is no good!" Sigh.
To summarize: Infringement -> Look at _CLAIMS_
Patentability -> Look at _teaching_ of reference.
You'd be surprised how many seasoned attorneys miss this simple point.
Ask any Examiner - Far too many amendments are filed which argue the
novelty of the _specification_ of the pending application while
discussing the _claims_ of a reference. That's Bass-ackwards!
Regards,
--Bob.
Alan Engel
Robert P. Bell wrote:
>
> Alan Engel wrote:
> >
> > Thanks for the description of a claim tree.
> >
> > I gather that they are not standard day-to-day fare for analyzing
> > patent information.
>
> Au contraire. If one is to analyze a patent from an infringement
> standpoint, one should look to the _claims_. As I've said before "The
> Claim's the thing!". So-called "analysis" based upon patent abstracts,
> specification, or drawings is dribble.
Please. The statement refers to the _tree_, not the claims. In
day-to-day
analysis of claims, do people use the claim _tree_ as a way to visualize
the analysis.
Good grief.
Robert P. Bell
Well, Charlie Brown, the answer is YES.
Good Golly, Miss Molly!
Regards,
--Bob.
Robert P. Bell
Robert P. Bell
Fred Meeker
Alan Engel wrote:
> Please. The statement refers to the _tree_, not the claims. In day-to-day
> analysis of claims, do people use the claim _tree_ as a way to visualize
> the analysis.
Yes, for complex claim structures.
For example, in an application with 100+ claims and an extended
prosecution history (e.g., with many canceled, revised, and newly added
claims), a visual depiction of the dependency structure of the claims
(e.g. using a tree structure similar to Windows Explorer) can be
invaluable. Some people take a further step of annotating the tree
structure to reflect the content of the claim and any references cited
against the claim. Of course, there are many variations.
Fred Meeker
Alan Engel
Fred Meeker wrote:
> For example, in an application with 100+ claims and an extended
> prosecution history (e.g., with many canceled, revised, and newly added
> claims), a visual depiction of the dependency structure of the claims
> (e.g. using a tree structure similar to Windows Explorer) can be
> invaluable. Some people take a further step of annotating the tree
> structure to reflect the content of the claim and any references cited
> against the claim. Of course, there are many variations.
>
Thanks. This _means_ of analyzing claims is of interest as I am
working on patent parsers as they relate to machine translation.
Alan Engel
Robert P. Bell wrote:
> > > Au contraire. If one is to analyze a patent from an infringement
> > > standpoint, one should look to the _claims_. As I've said before "The
> > > Claim's the thing!". So-called "analysis" based upon patent abstracts,
> > > specification, or drawings is dribble.
> >
> > Please. The statement refers to the _tree_, not the claims. In
> > day-to-day
> > analysis of claims, do people use the claim _tree_ as a way to visualize
> > the analysis.
> >
> > Good grief.
>
> Well, Charlie Brown, the answer is YES.
>
> Good Golly, Miss Molly!
Three posts - seems to be a desire for emphasis. Don't lump me
in with the Erronian approach to patent analysis.
Next question: Are there any other visual _devices_ (graphs, charts,
etc.) that are commonly used to analyze patents?
Thanks.
Robert P. Bell
As an Examiner, we used to use the patent claim dart-board in considering
allowability. Larger claims naturally formed bigger targets. ;)
Seriously, the claim chart I referred to (you are _reading_ these posts,
eh?) comprises the elements of the claim in question on one side (I use
the _columns_ format in WP) and corresponding elements of the prior art
(or an accused infringing device) on the other.
Each element has a corresponding YES or NO and a description telling
whether it is anticipated by the prior art or infringed (you can use
these charts for both purposes). Very simple and direct and can be
enlarged for a trial exhibit.
A claim chart also forces you to address each _element_ of a claim,
something prose can gloss over.
Example: Validity chart
CLAIM 1 PRIOR ART
================================================================
1. An apparatus comprising: | YES - Smith '456 teaches
First means... | (col. 6, lines 23-36)...
|
For hi-tech fans, I once made a laser videodisc for a trial exhibit which
zoomed out and highlighted portions of claim language and then
highlighted corresponding portions of circuits, including animation of
signals and the like. Using a remote control, an attorney could zoom to
any part of the laser disc at trial to highlight a particular portion of
a claim and corresponding prior art. How well did it work? Beats me,
they settled before trial. It was an interesting experience and I
learned a lot about video production.
Now maybe a 3-D hologram......
Regards,
--Bob.
Alan Engel
Thanks for your description of the claim chart and validity chart. I am
saving it for reference when I work on parsers.
Andrew C. Greenberg
> Next question: Are there any other visual _devices_ (graphs, charts,
> etc.) that are commonly used to analyze patents?
Just a few more remarks. Robert's validity chart is not only useful
for 102 analyses, but also 103 analyses, particularly the combining
references type. Consider
Claim 1 | Reference '345 | Reference '134
---------------------------------------------------+-------------------
A widget apparatus, | Widget apparatus: | Widget subassembly
comprising: | |
| |
1) a frobosinator, | Yes (col 1, line 10) | No.
| |
2) a pixilator, and | Yes (col 1, line 12) | Yes (col 7, line 3)
| |
3) a green cogscreen | No (but there is a | Yes (col 9, line 12)
| blue cogscreen at |
| col 7, line 10) |
This chart supports a rejection of claim 1 as obvious over '345
in view of '134.
The most useful automating tool that I have found is the shareware program
that takes a draft specification and produces reports of the numbered items
referred to in the claims and produces reports with respect to the same. It
saves time in producing a Sec. 112 check.
For the most part, I have found analysis of claims not to be terribly
difficult to do with human eyeball, but can see massive problems in
trying to do them automatically, making it a project unsuitable for
automation, because the cost/benefit ratio seems unfavorable. On the
other hand, while this is certainly true for novelty searches, where you
compare the claims of your application with the teachings of the prior art,
where you pretty much ignore the claims, it may not be so true for a
validity search, where you compare the claims of many patents with the
accused device.
Alan Engel
Thanks to Robert and Andrew for their descriptions and examples
of validity charts.
Bruce Hayden
Andrew C. Greenberg wrote:
>
> In article <32538B...@netaxs.com>, Alan Engel <aen...@netaxs.com> wrote:
>
> > Next question: Are there any other visual _devices_ (graphs, charts,
> > etc.) that are commonly used to analyze patents?
>
> Just a few more remarks. Robert's validity chart is not only useful
> for 102 analyses, but also 103 analyses, particularly the combining
> references type. Consider
>
> Claim 1 | Reference '345 | Reference '134
> ---------------------------------------------------+-------------------
> A widget apparatus, | Widget apparatus: | Widget subassembly
> comprising: | |
> | |
> 1) a frobosinator, | Yes (col 1, line 10) | No.
> | |
> 2) a pixilator, and | Yes (col 1, line 12) | Yes (col 7, line 3)
> | |
> 3) a green cogscreen | No (but there is a | Yes (col 9, line 12)
> | blue cogscreen at |
> | col 7, line 10) |
>
> This chart supports a rejection of claim 1 as obvious over '345
> in view of '134.
Also useful in litigation - though I have been involved more with 102
type claim charts (i.e. single reference). Nothing better to show a
court as to infringement or invalidity.
> For the most part, I have found analysis of claims not to be terribly
> difficult to do with human eyeball, but can see massive problems in
> trying to do them automatically, making it a project unsuitable for
> automation, because the cost/benefit ratio seems unfavorable. On the
> other hand, while this is certainly true for novelty searches, where you
> compare the claims of your application with the teachings of the prior art,
> where you pretty much ignore the claims, it may not be so true for a
> validity search, where you compare the claims of many patents with the
> accused device.
I am not as hopeful as you for the sucess of the latter, since a
computer
is going to do even a worse job than many examiners do in reading the
claims in view of the specification. Ever have an examiner reject claims
because he found something similar in another patent, only to have the
other reference turn out to be nowhere close? Invariably it seems that
the examiner is interpreting the claims without reference to either
your spec, or the spec in the reference.
One problem that I have seen with attempts to analyze claims at anything
other than the highest level (such as what claim does this depend upon)
is that the determination of exactly what is an element, and what is
not is not always that easy. I remember one litigation where part of
the question of infringement revolved around whose claim chart was
correct. Finally note that even scanning for antecedent basis is not
all that sucessful given today's technology.
--
---------------------------------------------------------------------
The preceding was not a legal opinion, and is not my employer's.
Original portions Copyright 1996 Bruce E. Hayden, All Rights Reserved
My work may be copied in whole or part, with proper attribution,
as long as the copying is not for commercial gain.
---------------------------------------------------------------------
Bruce E. Hayden bha...@acm.org
Austin, Texas bha...@copatlaw.com