PREPARED REMARKS FROM MR. DANIEL J. KLUTH
TESTIMONY OF DANIEL J. KLUTH
AT THE PUBLIC HEARINGS BY THE 
U.S. DEPARTMENT OF COMMERCE 
PATENT & TRADEMARK OFFICE ON 
PATENT PROTECTION FOR SOFTWARE-RELATED INVENTIONS
February 11, 1994 Marriot Crystal Forum, Arlington, VA.
Good morning ladies and gentlemen.  My name is Daniel J. Kluth
and I am a patent attorney with Schwegman, Lundberg &
Woessner, P.A. of Minneapolis, Minnesota.  I am the chair of
the Software Protection Committee of the Minnesota
Intellectual Property Law Association and I am the Chair of
the Government Relations Committee of the Minnesota Software
Association.  Although I am the chair of these two Committees,
I must point out that my remarks today do not have the
complete endorsement of these organizations.  I have polled
many of the members of these two organizations and,
specifically, the Software Protection Committee, and I will
try to convey the impressions I received.
The USPTO has been kind enough to allow me some extra time
today to address both Topic B (Standards and Practices used in
Examination of Patent Applications for Software Related
Inventions) and Topic C (Significance of and Protection for
Visual Aspects of Software Related Inventions).  Thus, I will
speak on both topics. 
First, Topic B.  In reviewing the testimony given in the San
Jose hearing last month, many concerns were voiced about the
quality of the examination process and the issuance of
seemingly overbroad and invalid software patents.  I won't
belabor that point.  I would like to point out, however, that
I believe establishing new rules in the CFR or new or special
procedures in the MPEP for software inventions would be wrong. 
Software patent applicants should stand on the same footing as
any other technology groups or classes.  I do not believe
there is any basis in the current statutes which would allow
special burdens to be placed on software applicants.  The
first insurmountable barrier would be how to decide if a
patent application is a "software" patent.
Because there already has been so much comment in this area,
I thought I would focus on questions 7-12 of Topic B.  This
set of questions deals with the problem of effectively and
meaningfully disclosing software-related inventions.
A patent application must teach one skilled in the art how to
make and use the invention (enablement) and the best mode in
which an invention may be practiced.  Failure to disclose the
invention and teach the best mode robs the public of its part
of the bargain in the patent system.
In many instances, the application is filed with a source code
appendix in accordance with 37 CFR Section 1.96, either in
paper form or on microfiche.  This is one of the few rules
promulgated by the USPTO which provides special consideration
to a technology class: namely software.
As an aside, I would like to point out that a lot of the
testimony presented in January and yesterday was directed to
areas outside of the control of the USPTO.  Many comments, if
acted upon, would require changes to statutes and in one or
two extreme cases, an amendment to the Constitution.  But
improving the quality of examination of software patents is
very much in the sphere of authority of the Patent Office and
in some cases, can be done without rule changes.  Simple
refinements in procedure and using existing statutes and rules
will suffice.  This is particularly true in the area of
disclosures.  The source code appendix has proven in many
instances to be a burden on the USPTO and does not appear to
provide the applicant with a better patent application.  I
suggest that we eliminate Rule 96 and place the burden on the
applicant to do a better job in explaining the software
operation in the body of the specification.  
Many patent applicants provide the source code in a patent
application as a "backstop" to their application to satisfy
both the best mode and the enablement requirements.  I will
first discuss enablement. Applicants hope that they can
overcome an enablement rejection from the USPTO on their
software patent application by relying on the source code to
overcome the rejection.  This reliance actually works against
the public interest in permitting lax disclosures or poorly
written disclosures in the body of the specification.  By
eliminating Rule 96, the applicants would be forced to do a
better job of describing their invention.
In many cases, Rule 96 encourages this poor practice.  In many
cases, the source code appendix does not teach the public
anything unless an expert is hired to decode, decompile or
flow chart the appendix.  Unfortunately, Rule 96 has become a
de facto standard.  By itself, eliminating Rule 96 would
return the earlier practice of submitting source code listings
in the body of the specification.  This practice was a
terrible burden on the public and the USPTO in creating many
jumbo patent applications.  But this practice should never
have been allowed to flourish since it violates the
requirements under 35 USC Section 112 which requires that the
applicant describe the invention in clear and concise terms. 
Patent applications filed with the source code embodiment in
the specification should be rejected as not being concise and
the rules allowing substitute specifications be invoked to
clean up the application.  This procedure would be still
useful in the case of rush-filed applications, especially if
the U.S. adopts a first-to-file system.  Applicants who file
source code listings [only if necessary] in the body of the
specification would be required to follow up with a concise
substitute specification.
Source code listings are also submitted to satisfy the best
mode requirement.  But best mode is an objective standard
which can rarely be tested in the USPTO examination process. 
This determination is made during litigation and is assisted
by the discovery practice to determine the inventor's state of
mind and to determine if the best mode was suppressed or
concealed.  In all other technology areas for patents, the
best mode for practicing the invention is a comparison of the
specification to information obtained during discovery. 
Software patents should be treated the same as other
technology areas and the specification should stand alone
without reliance on a source code appendix.  Allowing for and
even encouraging the submission of source code listings also
hurts the public by discouraging some applicants from filing
software patent applications for fear of losing trade secret
protection for the non-patentable aspects of the software
disclosed in the source code appendix.  In short, source code
listings are similar to the submission of a model of the
invention which is no longer required or even allowed. 
Eliminating Rule 96 is consistent with my position that no
special burdens or rules be carved out for software-related
technology or patent applications.
Once the source code is gone, how best to describe software? 
Question 9 asks the question in effect "Should the PTO require
a standardized disclosure format for software patent
applications?"
Patent applicants already are granted a broad range of
disclosure options in all other technology classes.  Requiring
a standard submission format would place a heavy burden on the
application since different software is best described in
different ways.  In many cases, high level pseudo-code is more
descriptive than flow charts.  State diagrams are often better
for sequential operation descriptions.  All these forms should
still be allowed.
It is true that many players in the software industry have
complained about the readability of the patent applications. 
But the existing drawing requirements in the CFR require that
the claimed invention be shown in a drawing (with some limited
exceptions).  This rule should be used by examiners to improve
the disclosures and allow the submission of drawings taken
from the description in the specification..
Another existing rule which is used very little in my
experience is the discretionary authority of Examiners to
require that the Abstract and the Summary of the Invention
sections of the patent application be amended to reflect the
allowed claims.  The use of this tool by the Patent Office may
work to improve the readability of many software patents
thereby diffusing much unfounded criticism of overbroad
software patents in the software industry. And now I would
like to address my remarks to Topic C:  The Significance of
and Protection for Visual Aspects of Software- Related
Inventions.
I will not go into a lengthy history of the development of
this issue, but I have followed the topic with great interest
ever since the first icon design patents issued to Xerox
Corporation in June of 1988.  In August of 1988, Steven
Lundberg and I published an article in the Computer Lawyer
entitled "Design Patents: A New Form of Intellectual Property
Protection for Computer Software", which was later republished
in the JPOS.  This article and the ensuing interest in the
matter resulted in a single letter being written to the
Commissioner of Patents and Trademarks opposing this form of
protection.  I learned through an FOIA request that other
letters were also received, but they were all supportive. 
This led to a chain of events in which the pending Xerox
design patent applications were rejected under 35 USC Section
171 and that those rejections led to the Patent Office Board
of Patent Appeals and Interferences decision In re Strijland
and other decisions.
The strict holding in the Strijland decision was that the
Xerox design patent applications as originally filed did not
show an article of manufacture and, hence, were deficient. 
The later amendments to the application to describe the icons
for use on a computer screen were rejected as new matter by
the Board.
The Strijland decision went beyond the holding to suggest that
if Xerox had shown a three-dimensional article of manufacture
on which the icon was displayed, this would be proper subject
matter under 35 USC Section 171 and the article of manufacture
was then a programmed computer screen display.
To date, the Patent Office has not issued any comments on the
Strijland decision or the other related cases.  The Patent
Office is instead suspending all prosecution of these cases
even if they comply with the Strijland requirements.
My position is that the Strijland decision was correct in
stating that the application as originally filed did not
disclose an article of manufacture if you adopt their position
that the word ICON is not limited to the computer field.  If
an application for an icon or a screen display properly
describes the article of manufacture in the title or
description as being software for a programmed computer screen
display, I believe this is enough to pass muster under 35 USC
Section 171.
This leads me to my second point which is that the Board
misconstrued what is the article of manufacture.  I contend
that the article of manufacture is the software, not the
programmed screen display.  This is consistent with the test
for infringement for a design patent which as stated in the
Supreme Court case of Gorham v. White reads:
"If in the eye of the ordinary observer, giving such attention
as a purchaser usually gives, two designs are substantially
the same, if the resemblance is such as to deceive such an
observer, inducing him to purchase one supposing it to be the
other, the first one patented is infringed by the other".
So, like in the trademark infringement test, inducement of an
ordinary purchaser is key.  
The point is that an ordinary purchaser of software would not
be induced to purchase one computer thinking it to be another. 
The purchaser would confuse the software.  This clarity of
definition of the article of manufacture harmonizes the
infringement test with the other issue in the Strijland
decision: namely - the dicta which required future cases to
show a three-dimensional computer screen adorned by the icon. 
This is not necessary since the article of manufacture, the
software, defies a three-dimensional drawing.
The drawing requirements of 37 CFR are not rigid in their
requirement of a three-dimensional object and the statute, 35
USC Section 171, does not require it.  The Patent Office has
not required it in type font design patents, game board design
patents and watch faces, to name a few.  To require
three-dimensional drawings for icon or screen display design
patent application is setting an extra burden for these cases
which is unjustified.  
In summary, I believe that the holding in the Strijland
decision can be satisfied by describing the icon designs as
for display on a screen display of a programmed computer.  I
do not believe the dicta of the Strijland decision need be
followed since three- dimensional drawings are not required,
and I believe that the article of manufacture is the software.
Finally, I have detected very little concern in the software
industry for the issuance of design patents for screen
displays.  35 USC Section 171 should not be used as a
gatekeeper in this regard since the requirements of novelty
and non-obviousness under 35 USC Sections 102 and 103 will
ferret out designs that are not worthy of protection. Thank
you,
Daniel J. Kluth
 

Forward to D. C. Toedt