Source: https://www.cclaw.com/2013/11/14/cls-bank-patent-analysis-claims-salvaging/
Timestamp: 2020-01-28 04:32:13
Document Index: 62993378

Matched Legal Cases: ['§101', '§101', '§112', '§101', '§ 1', '§101', '§103', '§101', '§101', '§103', '§101', '§112', '§112', '§101', '§102', '§103', '§112', '§103', '§101', '§ 1', '§ 1', '§101', '§102', '§103']

CLS Bank Patent Analysis and Claims Salvaging - Carstens & Cahoon
Posted November 14, 2013 by CCLaw & filed under Patent Litigation.
While the Federal Circuit and commentators have concentrated on the claims formation and issues regarding §101 patentable subject matter, the real issue not addressed by either party are the deficiencies in the SPECIFICATION and DRAWINGS. Without a properly written specification with supporting drawings that define the invention, there is no hope of generating supporting claims that meet the court’s requirements for §101 patentable subject matter. Thus, when properly analyzed, the issue in the CLS case is one of §112 disclosure and enablement, not subject matter. Had the invention been disclosed and claimed in the proper manner, the chances of the Federal Circuit finding patentable subject matter would have been much better.
This article will provide an analysis of several of the practical issues associated with the CLS patents as well as a proposed methodology to address these deficiencies for newly drafted computer-related patent applications. Some discussion will also be provided on possible techniques that could have been used to salvage claims of the CLS patents. For example, it is important to use a coordinated methodology to describe the invention. This requires that the information content conveyed be more than just data, but also structure so that it is clear how the claimed invention is implemented, both in the specification and in the drawings. When choosing a title for the patent application, the title should be terse, generally six words or less, and should describe the gist of the invention. It is also important to pay close attention to the claim preamble to make sure that it directly recites the invention with proper system/method/media modifiers as appropriate. Heeding these suggestions and others described in further detail below will greatly improve the chances of a patent withstanding an attack based on patentable subject matter regardless of how the courts finally come down on the appropriate framework to be applied.
Claims As Analyzed by the Court
Representative System Claim
Claim 1 of the ’720 Patent, representative of the system claims, recites:
Claim 1. A data processing system to enable the exchange of an obligation between parties, the system comprising:
a data storage unit having stored therein information about a shadow credit record and shadow debit record for a party, independent froma credit record and debit record maintained by an exchange institution; and
a computer, coupled to said data storage unit, that is configured to (a) receive a transaction;
It is instructive to look at this base system claim and realize that unless the preamble limits the claim to operation on a piece of computer hardware, the remainder of the claim only involves processing within a single entity that could read on human activity exclusively.
Representative Method Claim
Claim 33 of the ’479 Patent, representative of the method claims, recites:
Again, this activity could read on human activity exclusively, with the parties involved being accountants and their respective supervisors.
Representative Media Claim
Claim 39. A computer program product comprising a computer readable storage medium having computer readable program code embodied in the medium for use by a party to exchange an obligation between a first party and a second party, the computer program product comprising:
Architectural Deficiencies
Before addressing the claims, it should be noted that the CLS applications are poorly drafted, both on a formal level and a technical level. The following sections will detail several of the architectural deficiencies with the applications.
Patent Application Generation Methodology
An overarching issue with the CLS patent is their lack of a coordinated methodology to describe the invention. A patent application is by necessity a descriptive document. This requires that the information content conveyed be more than just data, but include structure.[1] In other words, it is not sufficient to indicate WHAT the invention does, but HOW it achieves the claimed activity. To do this the invention must be analyzed using some form of methodology to ensure that its proper components (elements) are identified and that the structure connecting these components is properly identified. A procedure achieving this function can be described as a Synthesis/Integration/Abstraction Methodology (SIAM), and is depicted below:
As can be seen from this diagram, the Synthesis process identifies the essential elements in the invention, the Integration process identifies how these components are interconnected (and any relationships between the components or characteristics of the components), and the Abstraction process attempts to abstract various components or relationships in order to achieve wider claims coverage.
While the SIAM approach is not the only approach that may be taken to generate claims coverage for an invention (many other equivalent function-based methodologies may achieve identical results), the SIAM approach is guaranteed to provide a fully-mapped claims solution if properly applied. However, within the context of complex computer-related inventions, use of the SIAM approach or its equivalent is essential to generating a claim set that can be verified as correct.
Note that the SIAM processes do not start with the definition of claims (as is commonly performed by patent practitioners) but rather the generation of SYSTEM/METHOD diagrams describing the essential invention components and their relationships. These drawings are then abstracted (using a nested hierarchy) until the true invention (as compared to the inventor’s disclosed embodiments) is defined by diagrams that describe the invention and support independent base SYSTEM/METHOD/MEDIA claims.
With respect to the CLS case, it is clear that the core concept of the invention was never fully developed in the specification and drawings. Specifically, base SYSTEM/METHOD claims were never specifically depicted in any of the drawings. While patent Examiners often overlook this disclosure requirement, this omission is often fatal to accurately describing the invention in terms of its essential elements and the relationships between these elements. Often (as discussed below), errors in these procedures are projected into essential patent application elements such as the title, abstract, and claims definitions.
Proper Claims Construction
Patent practitioners will agree that there are a wide variety of methods possible to generate correctly formed claims for any given patent application. However, within the scope of computer-related inventions, it is very important to tie the claims construction to the overall patent generation methodology. In other words, the patent specification and drawings should be constructed so that the claims may be directly recited from the specification text and drawings. This is especially important in computer-related inventions where the interactions between elements can become confused both due to the number of interacting components and the types of communication occurring between these elements.
For this reason, only two claim forms should be used when describing these types of inventions. A prototype SYSTEM claim is provided below:
A <INVENTION TITLE> system comprising:
(a) <element>;
(b) <…>;
(c) <element>;
said <element> …;
said … ; and
said <element> … .
The <INVENTION TITLE> is extracted directly from the patent specification. The <element> items are BRIEF TITLED descriptions of the components. No verbose descriptions of the <elements> should be placed in the (a)…(c) element identification lines. The WHEREIN clauses are where detailed limitations, relationships, and constraints on the <elements> are placed. Each WHEREIN clause should be limited in scope to one limitation, relationship, or constraint.
Similarly constructed METHOD claims are provided below and illustrate situations where the method steps are integrated into the SYSTEM claims and cases where the METHOD claims are independently tied to a specific system hardware configuration:
A <INVENTION TITLE> method comprising:
(1) <step>;
(2) <…>; and
(3) <step>.
A <INVENTION TITLE> method operating in conjunction with a <INVENTION TITLE> system, said system comprising:
said <element> … ;
In many circumstances the choice of METHOD claim formulation is one of practitioner preference. However, the second example may be effectively used in situations where the hardware platform is relatively well defined and the METHOD steps only serve to show how the SYSTEM operates in commercially viable embodiments.
The rationale for this strict claims construction format is simple: if properly applied, it forces the patent practitioner to avoid imprecise overlap of the invention elements and relationships. This also forces the claims description of the invention to more accurately map the structure of computer-related inventions, which are essentially function blocks connected by procedural relationships.[2]
Note that these claim structure directly maps the SIAM analysis discussed above. As will be shown later in this document, adherence to the SIAM analysis technique along with strict demarcations between the claim elements and functional relationships is essential to ensure that concrete embodiments rather than abstract concepts are claimed. In other words, the SIAM structure forces the practitioner to refine the nature of the invention construction and fully define the essential relationships between elements and this provides the basis for a clean claim construction that focuses on concrete invention hardware rather than aspirational invention function (concentration on HOW the invention functions versus WHAT the invention does).
The invention title (“SYSTEMS FOR EXCHANGING AN OBLIGATION”) is inappropriate for this type of computer-related invention. Unfortunately, the patent drafter failed to determine the real technical “gist” of the invention. The title chosen could apply equally well to a computer-related invention as to a human “handshake” agreement and doesn’t convey much information on what the invention IS. A more appropriate title would be something like “BIDIRECTIONAL MUTEX PROCESSING SYSTEM AND METHOD”[3] which describes the interlocked nature of the mutually dependent financial transaction processors that are being implemented by the claimed system.
For some reason I have never been able to discern, there is a strong tendency for patent practitioners and inventors alike to gravitate towards verbose and lengthy invention titles. We should all remember that a patent application is not a technical journal paper or a thesis/dissertation – it is a descriptive document. The use of a lengthy and verbose title can become a problem when attempting to define the invention in the claims. For this reason a good hard-and-fast rule to follow is that the invention title should be generally descriptive but terse. A good rule of thumb is that any invention title can be described in six words or less, including the trailing “SYSTEM AND METHOD.” If the patent practitioner cannot describe the invention in these terms, they probably don’t have a grasp on what the invention IS.
This emphasis on the invention title is in some ways critical in defining the invention as being more than an abstract idea without a physical embodiment. Given that all computer-related inventions as modernly claimed typically do not involve any form of custom hardware, emphasis must be placed on HOW the claimed elements operate in a coordinated fashion to achieve the desired result. Failure to properly define the invention title can easily lead to a situation where the claims have been abstracted outside the realm of physical hardware and thus outside the realm of patentable subject matter. As further discussed below, the title is critical in computer inventions as it should be directly recited in the claims preamble.
Claims Preambles
Note that the issue of poor invention title selection transcends the title alone and is promulgated to the claims as well:
Claim 1. A data processing system to enable the exchange of an obligation between parties, the system comprising: …
Claim 33. A method of exchanging obligations as between parties, each party holding a credit record and a debit record with an exchange institution, the credit records and debit records for exchange of predetermined obligations, the method comprising the steps of: …
Claim 39. A computer program product comprising a computer readable storage medium having computer readable program code embodied in the medium for use by a party to exchange an obligation between a first party and a second party, the computer program product comprising: …
Note that these preambles if read carefully could include situations in which the claimed subject matter is covered by human activity only, and not the elements or behavior of a claimed machine. Of particular importance is the SYSTEM claim, in that it recites a scenario that could be performed by human effort alone and does not specifically recite sufficient hardware detail or activity to make the claim concrete. In general
These claim preambles are more properly formulated as follows:
Claim 1. A bidirectional mutex processing system comprising:
Claim 33. A bidirectional mutex processing method comprising:
Claim 39. A tangible non-transitory computer usable medium having computer-readable program code means embodied thereon comprising a bidirectional mutex processing method comprising:
The method/media claims may be alternatively formulated as directly reciting the system hardware and subsequently reciting method steps executed on the hardware as follows:
Claim 33. A bidirectional mutex processing method, said method operating in conjunction with a bidirectional mutex processing system, said system comprising:
Claim 39. A tangible non-transitory computer usable medium having computer-readable program code means embodied thereon comprising a bidirectional mutex processing method, said method operating in conjunction with a bidirectional mutex processing system, said system comprising:
In these types of applications the claim preamble should be terse and directly recite the invention title with proper system/method/media modifiers as appropriate. Furthermore, while patent practitioners and inventors alike are often prone to proffer verbose invention titles, this is always inappropriate in drafting claims for computer related inventions, as this just increases the tendency to litigate what the invention IS and whether the claims preambles are limiting. Any limitations on how the invention is constructed or how the invention works should be placed within the body of the claim and not the preamble. These are hard-and-fast rules when defining the claims scope in these types of inventions.
Note that by selecting the proper invention title and directly reciting this invention title in the preamble the patent practitioner has ensured that the claimed invention is not named in an abstract manner but rather tied to physical phenomenon that can be directly related to hardware. While some practitioners may disagree with this approach and even go so far as to further limit the preamble to “A system comprising: …” or “A method comprising: …” it should be evident that inclusion of the invention title verbatim in the claim preamble should not appreciably limit the claims scope if the invention title is chosen properly.
Claims Duality
A common problem in most computer-related claims construction is the inability of patent practitioners to recognize the duality between SYSTEM and METHOD claims and the tautology between METHOD claims and MEDIA claims.
When properly abstracted, the SYSTEM claims in a computer-related invention will directly map the steps recited in the METHOD claims. As can be seen from the exemplary SYSTEM and METHOD claims, this duality rule was not followed by in the CLS applications. A good hard-and-fast rule for computer-related invention is that if SYSTEM claims do not have a direct dual in the METHOD claims, then one or the other (or both) of these claims sets is defective or improperly abstracted.
With respect to METHOD/MEDIA claims, the mapping is a tautology, with a one-to-one correspondence between the two claim sets. As evidenced by standard industry practice, this tautology rule is often not followed or the MEDIA claims are constructed as paraphrased versions of the METHOD claims.
From the above discussion it can be correctly surmised that with the scope of a computer-related invention, a given claim abstraction is replicated THREE times: once for the SYSTEM, once for the dual METHOD, and once for the MEDIA claim using the METHOD claim content. If properly formed, dependent claims following a given independent claim in each set will be identical except for references to the base SYSTEM/METHOD/MEDIA claim.
A review of the CLS claims reveals that this simple rule of claim abstraction has been violated. A reading of the CLS SYSTEM/METHOD/MEDIA claims can result in confusion because it is not clear from the claims formation that the claim sets are coextensive with respect to the same invention. It should be noted that disputes within the Federal Circuit regarding whether SYSTEM/METHOD claims should rise or fall together based on a §101 rejection are moot if the claims are identically structured and are constructed to recite patentable subject matter that is disclosed in the specification and drawings.
Not noted in any of the discussions on CLS is the fact that there is no diagram illustrating the claimed system/method/media as required by 37 CFR § 1.83.[4] While I have rarely seen Examiners require drawings to support claimed invention scope for computer-related inventions, I also note that it is common for these types of applications to have missing or poor quality drawings as evidenced in the CLS patents. This type of patent application MUST have the following drawings complement:
a system level block diagram that specifically includes recitation of a computer;
recitation of a computer readable medium used to load executable code on the computer;
a flowchart illustrating the method steps associated with the operation of the computer;
dataflow diagrams illustrating data flow among the various system components;
recitation of the Internet and communication links between various computer elements;
for the CLS patent applications, a recitation of a STATE MACHINE diagram was required to fully explain the mutex functionality embodied in the financial system.
While the CLS patents show some abstract (“canned”) system diagrams, there is no integrated drawing that expresses the gist of the invention.
An exemplary system level diagram describing the CLS invention might look as follows:
It is instructive to observe that nowhere in the CLS patent is there a single drawing that describes the overall SYSTEM invention.
Similarly, there is no corresponding overarching METHOD flowchart in the CLS patent application. The CLS METHOD invention may be exemplified by a typical flowchart as depicted below:
As stated above, an invention of this type should include a STATE MACHINE diagram to illustrate the interaction between the TCS and PCS. A key reason for this inclusion is that the interlocked access to the credit-debit records that constitute the invention is an essential element of the invention novelty. Failure to include this renders the claimed invention something that is entirely within the scope of human activity and devoid of a concrete hardware foundation. Stated another way, incorporating a state machine within the invention description is another way of moving the abstracted invention closer to a concrete hardware implementation. An exemplary state diagram is illustrated below:
These drawings take less than one hour total to generate and there simply is no excuse in not generating this information for inclusion into the patent application in support of the independent SYSTEM and METHOD base claims. The CAD tools to generate this level of drawing quality are neither expensive[5] nor difficult to use[6] and as such should be a part of every practitioner’s standard application generation flow.
The invention abstract was originally recited as:
A system for exchanging an obligation between parties where the exchange is administered by a supervisory institution that ensures real-time settling of obligations between parties by updating shadow records in real-time and instructing one or more exchange institutions to effect, from time to time, the exchange of obligations in accounts maintained external to the supervisory institution. Updates to the exchange institution accounts may reflect the net obligations of parties over a nominated period of time. The role of the supervisory institution is to ensure that obligations are only settled where parties have sufficient balance in their shadow records to complete the transaction. Obligations that can be exchanged include, but are not limited to: shares in financial or physical assets, participation rights in wagers, national or synthetic currencies, exchange settlement account deposits, taxation account deposits, and deposits of financial instruments or precious metals.
I mention this because the ABSTRACT is one area of the patent specification that is invariably done poorly in part because the patent practitioner typically fails to ensure that a diagram is provided that reads directly on the overarching concepts being conveyed in the ABSTRACT text. A properly formed ABSTRACT and corresponding drawing are provided below:
A bidirectional mutex processing system/method supporting coordinated financial transactions is disclosed. The system incorporates a transaction computer system (TCS) configured to communicate with a posting computer system (PCS) responsible for reconciling credit-debit transactions associated with a plurality of remote computer users (RCU) each interacting with a remote computer system (RCS). The TCS is configured to mirror RCU credit-debit records (CDR) obtained from the PCS and communicate with the RCS to accept RCU transaction directives. The mirrored CDR information is periodically examined by the TCS for potential credit-debit reconciliation and credit-debit reconciliation candidates are selected based on a positive credit-debit balance in the mirrored CDR data. This candidate selection triggers TCS-to-PCS communication to affect a bidirectional data update of PCS CDR data based on a mutex semaphore to ensure an interlocked unitary transaction step for the PCS CDR data.
It should be noted that since the ABSTRACT is not technically part of the patent specification, the following CONCLUSION section should have be included in the CLS specification just prior to the CLAIMS section:
A bidirectional mutex processing system/method supporting coordinated financial transactions has been disclosed. The system incorporates a transaction computer system (TCS) configured to communicate with a posting computer system (PCS) responsible for reconciling credit-debit transactions associated with a plurality of remote computer users (RCU) each interacting with a remote computer system (RCS). The TCS is configured to mirror RCU credit-debit records (CDR) obtained from the PCS and communicate with the RCS to accept RCU transaction directives. The mirrored CDR information is periodically examined by the TCS for potential credit-debit reconciliation and credit-debit reconciliation candidates are selected based on a positive credit-debit balance in the mirrored CDR data. This candidate selection triggers TCS-to-PCS communication to affect a bidirectional data update of PCS CDR data based on a mutex semaphore to ensure an interlocked unitary transaction step for the PCS CDR data.
Note that there is only a slight grammatical difference between the ABSTRACT and CONCLUSION.
It is instructive to note how the ABSTRACT is constructed. The first sentence is always of the same form, reciting the invention title, summary of functionality, and “is disclosed” termination. Remaining sentences read on the base SYSTEM/METHOD diagrams that constitute the abstracted invention. While the revised ABSTRACT provided seems somewhat clinical in its recitation of the invention, note how it also incorporates terminology that is far more concrete than that provided in the original CLS ABSTRACT. A careful reading of the CLS ABSTRACT might indicate a system that could be performed solely by human effort or thought and thus be devoid of the necessary hardware context to support an allowable claim under §101.
Exemplary Claims Complement
While a variety of claims formulations are possible using the updated drawings and flowcharts illustrated above, the following SYSTEM/METHOD/MEDIA claim sets are exemplary of a proper claims format for the CLS invention:
Exemplary System Claim
A financial transaction processing system comprising:
(a) transaction computer system (TCS);
(b) posting computer system (PCS); and
(c) computer communications network (CCN);
said PCS is configured to communicate with said TCS via said CCN;
said PCS hosts customer credit-debit records in a database;
said TCS is configured to duplicate said customer debit-credit records to generate a mirrored data copy of said debit-credit records;
said TCS is configured communicate via said CCN with a plurality of remote user computers (RUC) each interacting with a respective customer;
said RUC are configured to accept a financial transaction directive (FTD) from said respective customers;
said TCS is configured to accept said FTD from said RUC;
said TCS is configured to detect if said FTD can be reconciled against said TCS mirrored data to maintain a credit-debit surplus for accounts associated with said FTD; and
said TCS is configured to communicate with said PCS and instruct said PCS to commit said FTD against said credit-debit records hosted by said PCS if said credit-debit surplus is detected.
Exemplary Method Claim
A financial transaction processing method comprising:
(1) via a posting computer system (PCS), hosting customer credit-debit records;
(2) via a transaction computer system (TCS), accessing said PCS over a computer communications network (CCN) and duplicating said customer debit-credit records to generate a mirrored data copy of said debit-credit records;
(3) via said TCS, communicating via said CCN with a plurality of remote user computers (RUC) each interacting with a respective customer;
(4) via said RUC, accepting financial a transaction directive (FTD) from said respective customers;
(5) via said TCS, accepting said FTD from said RUC;
(6) via said TCS, detecting if said FTD can be reconciled against said TCS mirrored data to maintain a credit-debit surplus for accounts associated with said FTD; and
(7) via said TCS, communicating with said PCS and instructing said PCS to commit said FTD against said credit-debit records hosted by said PCS if said credit-debit surplus is detected.
The preambles for each step may be equivalently changed to “by execution of machine instructions on said …” without loss of generality. Some Examiners may prefer this more specific recitation of the hardware activity in each step.
Exemplary Media Claim
A tangible non-transitory computer usable medium having computer-readable program code means embodied thereon comprising a financial transaction processing method comprising:
Note that in the above claim sets the SYSTEM claim has a corresponding dual METHOD construction that mirrors exactly the MEDIA claim.
Media Claim Support
Generally speaking, the support for media claims in the invention disclosure can be readily achieved using a three-part approach where
the system block diagram figures visually depict a computer readable medium and associated computer system;
the system level specification description is augmented with recitation of a computer readable medium; and
a form paragraph reciting the claim scope of media coverage is placed just before the CONCLUSION[7] section of the application.
An example of the visual depiction of computer readable media is provided in FIG. 1 above. Examples of the remaining individual parts are provided below.
Exemplary System Description Incorporating Media Support
Incorporation of support for computer media in the system specification is best described by example as follows:[8]
A preferred exemplary system embodiment of the present invention is generally depicted in FIG. 1 (0100) and is configured to permit a number of customer users (0111, 0121, 0131) to interact with a transaction process (0112, 0122) that operate on a remote user computer (RUC) (0113, 0123) (each incorporating a user interface component that may in come embodiments be configured as a graphical user interface (GUI)) by execution of software comprising machine instructions read from a computer-readable medium (0114, 0124). The computer systems (0113, 0123) under control of machine instructions read from the computer-readable medium (0114, 0124) communicate over the Internet (0101) to a transaction computer system (TCS) (0141) that operates under control of software comprising machine instructions read from a computer readable medium (0142).
The TCS (0141) communicates over the Internet (0101) to a posting computer system (PCS) (0151) that operates under control of software comprising machine instructions read from a computer readable medium (0152). The TCS maintains a mirrored duplicate credit-debit record database (0143) by communicating over the Internet (0101) with the PCS (0151) which hosts the corresponding master credit-record database (0153).
The TCS (0141) is configured to receive a financial transaction directive (FTD) from customers (0111, 0121, 0131) via their respective RUCs (0113, 0123) and detect if the FTD can be reconciled to maintain a surplus credit-debit surplus against the TCS mirrored database (0143) using a reconciliation process (0144) operating under control of the TCS (0141). If credit-debit surplus can be maintained for the FTD, the TCS communicates over the Internet (0101) with the PCS (0151) to commit the FTD by posting this transaction information to the PCS credit-debit record database (0153).
Italicized detail within the above paragraphs denotes support for computer media claims. While additional detail should be included to describe the mutex semaphore implementation operating between the TCS and the PCS to actually perform the interlocked financial transaction, the general structure of the above paragraphs should provide sufficient detail to show how the media claims can be supported in this narrative system description context.
Exemplary Media Support Form Paragraph
A form paragraph describing the scope of the media claims may be recited as follows:
As generally illustrated herein, the present invention system embodiments can incorporate a variety of computer readable media that comprise computer usable medium having computer readable code means embodied therein. One skilled in the art will recognize that the software associated with the various processes described herein can be embodied in a wide variety of computer accessible media from which the software is loaded and activated. Pursuant to In re Beauregard, 35 USPQ2d 1383 (U.S. Patent 5,710,578), the present invention anticipates and includes this type of computer readable media within the scope of the invention. Pursuant to In re Nuijten, 500 F.3d 1346 (Fed. Cir. 2007) (U.S. Patent Application S/N 09/211,928), the present invention scope is limited to computer readable media wherein the media is both tangible and non-transitory.
While this seems somewhat verbose, the USPTO has been very adamant since the Nuijten decision that the “magic language” of “tangible non-transitory” must be included to support media claims.[9]
Exemplary Detail Method Claim
The exemplary flowchart provided above in FIG. 2 may be described in terms of the following detail method claim:
A bidirectional mutex processing method comprising:
(1) mirroring updated credit-debit dataset information that is hosted by a posting computer system (PCS) on a transaction computer system (TCS) via communication between said PCS and said TCS over a computer communication network (CCN);
(2) via said TCS, receiving remote computer user (RCU) credit-debit transactions from respective remote computer systems (RCS)
(3) via said TCS, examining said transactions for a potential credit-debit reconciliation match;
(4) via said TCS, determining if said potential reconciliation match produces a positive account balance, and if not, proceeding to step (1);
(5) via said TCS, requesting a mutex semaphore interlock for a credit-debit reconciliation from said PCS over said CCN;
(6) via said TCS, detecting if said mutex semaphore interlock was granted by said PCS via communication with said PCS over said CCN, and if not, proceeding to step (1);
(7) via said TCS, transmitting said potential credit-debit reconciliation request to said PCS over said CCN;
(8) via said TCS, detecting if said credit-debit reconciliation request to said PCS was successful via communication with said PCS over said CCN; and
(9) via said TCS, requesting an update of mirrored credit-debit records on said TCS then proceeding to step (1).
Note that each numbered step maps identically to the corresponding method step in the flowchart. The preambles for each step may be equivalently changed to “by execution of machine instructions on said …” without loss of generality. Some Examiners may prefer this more specific recitation of the hardware activity in each step.
The specific recitation of the mutex semaphore interlock and its relation to the two computer systems (TCS and PCS) is essentially the core concept of the invention. It is for this reason that the state machine depicted previously is an important part of the overall system description. Without it, there are serious questions as to whether the invention can pass §103 muster because the TCS is essentially just a mirror site of the PCS. Without some form of interlock, there is no way to ensure transaction integrity between the two computer systems.
Note also that the incorporation of this mutex semaphore interlock element takes the claim outside the realm of what is possible to perform in the context of human behavior. This is an important aspect in limiting the claim scope to something other than an abstract idea. For situations in which the invention includes such, a schematic describing a hardware implementation of this mutex semaphore interlock should be provided and claimed.
Finally, it should be noted that this level of method scope detail should be included in the disclosure even if the method is not explicitly claimed in the patent application. The rationale for this is that if the original system/method claims are found to be too broad, inclusion of this method detail is generally sufficient to overcome the prior art rejections and obtain an allowance.
The above claim structures rely on several claims formatting conventions to tighten the nexus between the recited claims and the specification disclosure. These include:
Independent claims always begin on a new page.
System claims have elements alphabetically identified starting at (a).
Method claims have steps numerically identified starting at (1).
WHEREIN clauses are indented to form separate claims limitation structures;
Spacing is provided between the preamble/elements/wherein clauses to further identify information content.
It should be emphasized that “form implies function” when generating claims, and the easier the claim is to read, the less chance there will be of making a drafting error.[10] Sloppy claims formatting will invariably lead to drafting errors. This same concept applies to the patent application specification,[11] especially in the computer-related arts, as they are often 100+ pages in length. Use of appropriate section headings, section hierarchies, and a table of contents is appropriate in drafting all computer-related patent applications.[12]
A review of the above claim sets will reveal that much use has been made of acronyms within the claim definition. There are several reasons for this approach:
If analyzed properly, the naming of elements within a claim is somewhat irrelevant, in that the function of the element is all that is important in conjunction with how the element relates to others in the invention.
The use of acronyms can be analogized to that of component identifiers in an electrical netlist. As such, the netlist contains additional information regarding the electrical connectivity between the component nodes. This connectivity information is contained in the WHEREIN clauses.
Acronyms provide a demarcation between the components and their role in the invention operation.
Claims proofing is much easier if descriptive element names are shortened.
A very important side benefit of this approach is that very complex claims if properly drafted can be represented on 1-2 pages of typewritten text.[13] This can often avoid very lengthy claims that are both difficult to read and proof.
I have found in practice that use of this technique and other automation techniques[14] greatly simplifies the generation and verification of claims. It should also be noted that since the claims are generated after the drawings, the acronym choices have already been decided and presented in the drawings. This lays the groundwork for rapid and consistent claims construction.
It should be noted that there has been much argument among patent practitioners, patent Examiners, and the courts as to (a) whether the claims preamble is limiting, and (b) whether WHEREIN clauses are limiting. For this reason a form paragraph can be included to clarify this interpretation within the patent application:
Within the context of the following CLAIMS, the CLAIM PREAMBLE should be considered as limiting the scope of the claimed invention. Within the context of the following CLAIMS, “wherein” clauses should be considered as limiting the scope of the claimed invention.
While there is no reason for the Examiner to discount the limiting nature of a WHEREIN clause, I have seen this done in some cases and as such have resorted to explicitly noting this restriction in the specification. Practitioners may argue that the above paragraph unnecessarily narrows the scope of the invention, but remember that the claim preamble should only contain a recitation of the invention title (and nothing else) and that WHEREIN clauses only recite the required invention limitations as they relate to relationships and constraints among the invention components and elements. If you have failed to properly define the invention name or the invention limitations, then there are more substantive problems with the patent application than claims structure.
Salvaged Claims Complement
As stated previously, the CLS disclosure is defective in not providing sufficient detail to support a level of concrete interpretation so as to avoid claiming an abstract concept. However, in an attempt to provide insight into proper claims construction for this type of invention, the following claims edits have been provided as an example of a more proper format for this patent:
Salvaged System Claim
(a) exchange institution computer (EIC);
(b) exchange transaction computer (ETC); and
said EIC is configured to communicate with said ETC via said CCN;
said ETC is configured to maintain a shadow copy of debit-credit records hosted by said ETC;
said ETC is configured communicate via said CCN with a plurality of remote user computers (RUC) each interacting with a respective customer;
said RUC are configured to accept a financial transfer transaction (FTT) from said respective customers;
said ETC is configured to accept said FTT from said RUC;
said ETC is configured to detect if said FTT results in a credit-debit surplus for said ETC shadow copy debit-credit records corresponding to said respective customers; and
said ETC is configured to communicate with said EIC and instruct said EIC to commit said FTT to said credit-debit records hosted by said EIC if said credit-debit surplus is detected.
Salvaged Method Claim
(1) maintaining a shadow copy of debit-credit records hosted by an exchange transaction computer (ETC) on an exchange institution computer (EIC) by communication between said ETC and said EIC over a computer communications network (CCN);
(2) via said ETC, communicating via said CCN with a plurality of remote user computers (RUC) each interacting with a respective customer;
(3) via said RUC, accepting a financial transfer transaction (FTT) from said respective customers;
(4) via said ETC, accepting said FTT from said RUC;
(5) via said ETC, detecting if said FTT results in a credit-debit surplus for said ETC shadow copy debit-credit records corresponding to said respective customers; and
(6) via said ETC, communicating with said EIC over said CCN and instructing said EIC to commit said FTT to said credit-debit records hosted by said EIC if said credit-debit surplus is detected.
Note that in the above claim sets the SYSTEM claim has a corresponding dual METHOD construction.
Salvaged Media Claim
Note that in the above claim sets METHOD construction mirrors exactly the MEDIA claim.
This claims salvaging effort would probably not have been sufficient to save claims scope if the §101 rejections were asserted during prosecution because the specification did not provide for much of the computer and communication infrastructure recited above. Assuming that the claims had in fact overcome the §101 rejection, the next issue would have been whether the claims could have overcome a §103 rejection.[15]
Patent Practitioner Suggestions
While the CLS Bank case may be fertile ground for discussion of the more esoteric aspects regarding the bounds of §101 statutory subject matter, this discussions does little for patent practitioners who need concrete guidance on how to counsel their clients and produce quality patent applications that pass both USPTO scrutiny and attacks when litigated as issued patents. While the following list of observations and suggestions is not exhaustive, it does address several of the problems with the CLS patents and many others that are routinely issued by the USPTO:
Be sure the technical art matches patent practitioner education/experience. We are mandated to act competently for our clients[16] and not to draft applications outside of our area of technical competence.[17] However, it is clear that this mandate is not always followed in the patent practitioner corps. As an example, the CLS application and similar computer related applications may only be competently handled by a relatively small portion of the available patent attorney corps.[18] This demand for highly skilled technical background is becoming more and more a problem in the patent practitioner ranks as the technical complexity of inventions increases while the educational level of candidates decreases.[19] As technology becomes more complex and the educational level of inventors increases, this will continue to be a problem in the future. As a practical matter, it is imperative that the person drafting a patent application have a firm grasp on the underlying technical principles of the invention. Note that years of experience as a patent practitioner is not a substitute for this requirement.
Beware of the UNKNOWN UNKNOWNS. Practitioners should be aware that there are always “unknown unknowns”[20] that can spell disaster when writing patent applications. By this I mean that there are areas within our own general area of technical study that are outside of our scope of competence. For example, a person with a computer science degree may have adequate knowledge of a variety of application programming contexts but not be versed in operating system internals or computer hardware design. As another example, an individual with an undergraduate electrical engineering (EE) degree may practice in one of several general areas, such as power electronics, communications, control systems, digital circuit design, analog circuit design, or electromagnetics. However, education/experience in one field of EE doesn’t necessarily mean that the individual is aware of information specific to other branches of EE that is critical to the preparation of a patent application in that EE field of art. An excellent example of this phenomenon can be seen in the following diagram extracted from an issued U.S. Patent:[21]
While this circuit seems innocuous at first glance to the average EE graduate, those skilled in analog integrated circuit (IC) design at a graduate level will immediately recognize that the circuit has several fatal flaws which would prevent its operation.[22] While the practitioner in this case may have had a general undergraduate EE education, the failure to ferret out the §112 problem with this diagram could be fatal to disclosing and claiming the real novelty in the invention(s).[23] The practice tip to take from these examples is that your educational background may match the field of the invention, but there is always some risk that your technical competence may not. Again as stated above, years of experience as a patent practitioner is not a substitute for this technical competence requirement.[24]
Proper training is essential. Part of the problem with many computer-related patent applications is the fact that the patent practitioners have not been provided proper training on how to draft patent applications, and in particular, patent applications in this computer-related technical field. This has been a serious problem over the last two decades but has not been directly addressed by the courts but rather couched in abstract suggestions such as “the applications have to disclose more and get better.” Unfortunately law schools and law firms have not directly addressed this problem. I am not sure how this issue is to be corrected, but I do recognize it as a serious problem. Obviously, it is not sufficient for a patent practitioner to be trained to achieve allowance for a prepared patent application only to have the patent overturned in the courts on substantive grounds as in the CLS case. Training as has been traditionally provided will not alone be sufficient to solve this problem.[25]
All patent applications are the same. Patent practitioners should realize after some reflection that this statement is true. While the elements and relationships contained in an invention may vary, the approach to drafting patent applications is identical for every patent application. Absent invention data content, the applications are identical. The common view for practitioners is that these are “custom” documents that must be “hand crafted” much as automobiles were constructed before Henry Ford introduced the concept of assembly lines and interchangeable parts. This mentality is both inefficient and error prone, in that without use of a structured approach to converting the data associated with the invention embodiments provided by the inventor into the proper patent application form, the practitioner is forced to reconstruct a unique path to success for each patent application. To this end it should be noted that the patent practitioner’s job is not to reformat the inventor’s disclosure into a patent application, but to restructure the information content of the invention into the proper patent application hierarchy. The only practical way to accomplish this is by automating error-prone tasks and adhering to a disciplined patent application preparation methodology such as SIAM.[26] The adherence to a standards-based rule set for patent application preparation guarantees that patents prepared using this methodology can be freely moved among practitioners (much as interchangeable parts on an assembly line) who draft and prosecute these applications.[27]
Quality has a singular standard of excellence. If all patent applications are identical, then the quality standards associated with all applications should achieve a singular standard of excellence. For this to occur, there must be some identification of what constitutes excellent quality in the application preparation process and a desire by the patent practitioner community to strive towards this standard of quality.
A structured approach to analysis of the invention must occur before claims drafting can begin. Remember that the summary system/method diagrams, title, abstract, and conclusion should all be completed before claims drafting begins. Some form of SIAM analysis should be used to define the invention elements and their relationships before claims construction begins. This will define the drawings and from that the structure of the detailed description and claims can be formulated. Remember that claims follow the drawings, and not the other way around.
Remember that patent claims construction begins with the patent specification. You can’t claim what you don’t disclose. This has always been the rule and hasn’t changed in the last two decades. Generally speaking, most computer-related patent applications are deficient in the level of disclosure. This can only be remedied by “doing the work” and generating specifications and drawings that include sufficient detail to constitute novelty. The hard part of this directive is not “doing the work” but rather “making yourself do the work.”[28]
Drawings are the most critical element in a patent application. You can always amend the claims, but you can’t add new matter to the drawings and these are the fundamental elements describing the invention. Particularly in computer-related applications, the drawings must provide overarching SYSTEM and METHOD disclosure. If you haven’t summarized the invention into 1-page SYSTEM/METHOD diagrams, the invention isn’t properly disclosed. Use of generic “stock” diagrams without novelty detail is insufficient to meet this requirement. As a practical matter, it is best for patent practitioners to generate their own drawings in these types of computer-related cases. This is more efficient and accurate than using a draftsman and allows the practitioner to generate the volume of detail necessary to properly disclose these inventions.
Drawings should include hierarchical flowcharts. Computer-related inventions are typically very complex and the use of nested flowcharts is generally a requirement to fully define the invention and the nuances of HOW the invention operates. Generally speaking, there is too much “waiving your hand at the point of novelty” in most computer-related applications. This requires that the patent practitioner have some concept of what is “old” and what is “new” in the processes/procedures used in the invention. This in part is the critical error in the CLS patents in that the essential elements to implementing the invention as a practical system were never disclosed. As this information on flowchart detail is often buried in documentation to which only the inventor has access, it is important for the patent practitioner to mine this information for inclusion in the patent application specification/drawings.
Drawings should be formal. There is no excuse for drawings being of a quality poorer than original documentation received from the client. Use proper tools and templates for this purpose.[29] Computer-related invention drawings should be generated by the patent practitioner in most circumstances as this is both efficient and promotes more visual disclosure in the patent application.
Drawings alone should be sufficient to describe the invention. The invention should be fully disclosed in the drawings apart from the claims and specification, much as a design document would do in a traditional formal software development project.[30]
The ABSTRACT should directly read on a SYSTEM/METHOD drawing. If this isn’t the case, either the ABSTRACT is deficient or you are missing a drawing.
The ABSTRACT should have a corresponding CONCLUSION section in the specification. This ensures that at a minimum the overarching SYSTEM is disclosed.[31]
The specification should be hierarchically structured. Computer-related inventions are by their very nature composed of a tree-based hierarchy. The specification should match this structure. The specification content should have formatting that permits easy reading and proofing.
Mirror the SYSTEM/METHOD/MEDIA claims. Computer-related inventions generally provide disclosure support for all three types of claims. The SYSTEM and METHOD claims should be duals of each other. If you are not including all three types of claims, this is either in error or dictated by client financial constraints. Structure the base claims so that all of the dependencies off of the base independent claims are identical. This will lessen the likelihood that dependent claims coverage is missed or incorrect.
Remember the contextual definition of “one of ordinary skill in the art.” The phrase “one of ordinary skill in the art” is regularly applied to patent Examiners, patent practitioners, and sometimes inventors or their colleagues. Generally speaking this isn’t true. Given the level of technical education and experience required for the creation of many computer-related inventions, this phrase doesn’t equally apply to all three classes of individuals. Generally speaking, you must teach to a lower level of technical expertise than that of individuals in the inventor’s technical field, as most if not all of the individuals working in the inventor’s technical field will have more education and experience than either the patent Examiner or the patent practitioner.[32] This often requires more work in fleshing out the invention details (how it works) than would be normally necessary for a typical individual working in the technical field to understand the invention.
The Examiner will not typically find your §112 disclosure/enablement problems. This is tied to the point above and requires that the patent practitioner be disciplined to ensure that the invention is both fully disclosed and enabled. It must be remembered that the job of a patent practitioner is more than just transcribing the inventor’s disclosure into a proper document template for submission to the USPTO. The content must be developed and structured to ensure that there is sufficient disclosure and that this disclosure is enabled to a level of specificity that is concretely tied to hardware.
Many §101/§102/§103 rejections are in fact §112 problems. In many circumstances salvaging the patent application in prosecution or the issued patent in litigation is heavily dependent on the patent application disclosure. Once the drawings/specification is filed, the concrete has set and there is very little that can be done to correct omissions in the disclosure. Taking a lesson from industry experience,[33] patent practitioners should endeavor to “do it right the first time” when generating the patent disclosure to ensure that there is sufficient technical detail to overcome anticipated potential §103 rejections as well as distinguish the invention from the prior art. During this process the invention disclosure should involve sufficient concrete disclosure to avoid a potential §101 rejection. Careful review of the CLS patents reveals that the real problem with the claims stems from the application disclosure. A proper application disclosure would have driven the claims out of the realm of abstraction into an area of allowable subject matter.
This list is non-exhaustive but hopefully will provide some insight into how practitioners may move forward from CLS to draft patent applications that both generate allowable claims and can survive scrutiny in a litigation context.
While the CLS patents are in some cases in excess of 150 pages in length, this volume does not necessarily mean that the proper technical content is contained in the specification and drawings to support the business method claims in the patent applications. More directly, it must be stated that without proper drawings to describe the invention, the subsequent specification support and claims coverage will be lacking. Couple this deficiency with the patent’s use of terminology in the invention TITLE and ABSTRACT that is sufficiently vague as to permit the invention scope to cover human operation as the claimed system/method is a sure path to invalidity based on excessive claims abstraction.
Solving problems presented in CLS requires more than clever modifications to the claims to positively recite computer hardware and machine transformations. It requires a better understanding of the underlying concepts of the invention and how they relate to hardware systems and historical computer engineering problems that must be addressed in a wide variety of application contexts. In this particular instance the CLS patents essentially attempt to claim the concept of an escrow service without providing any basis for a technical improvement over the prior art. If the patent application had correctly described the problem in terms of computer engineering terminology (Bidirectional Mutex Processing System And Method) with supporting technical support for the corresponding semaphore controls, then claims reading on this system/method/media would have been allowable as reading on physical phenomenon rather than abstractions of transactions that could have been performed solely by human effort.
At a more fundamental level, it must be emphasized that computer-related applications are by their very nature complex and accordingly large in size. The ‘720 patent as issued was over 150 pages in length, with 117 pages of drawings and 40 pages of condensed specification (approximately 200 normally typewritten pages). Systems of this complexity level cannot be reliably described in a patent application absent a systematic methodology that employs coordinated synthesis/integration/abstraction techniques. This is evident in the CLS issued patents and associated claims, as they both fail to describe the true invention and simultaneously fail to properly abstract the invention embodiments to a statutorily allowable claims scope. Formalizing patent application preparation is the only way to avoid these pitfalls.
[1] This is akin to providing an executable program file and expecting this file to adequately describe the structure of the underlying concepts embodied in the code. While the executable may be useful in describing WHAT the program does, it does little to describe HOW the code functions on a more abstract level.
[2] Recall for example the equivalence between a Turing machine and all modern day computing systems. A Turing machine is a hypothetical device that manipulates symbols on a strip of tape according to a table of rules. Despite its simplicity, a Turing machine can be adapted to simulate the logic of any computer algorithm, and is particularly useful in explaining the functions of a CPU inside a computer.
[3] In computer science, particularly in operating systems, a semaphore is a variable or abstract data type that is used for controlling access, by multiple processes, to a common resource in a parallel programming or a multi user environment. A mutex is essentially the same thing as a binary semaphore and sometimes uses the same basic implementation. It may differ in the following ways:
[4] 37 CFR § 1.83 means what is says:
37 CFR § 1.83 Content of drawing
(a) The drawing in a nonprovisional application must show every feature of the invention specified in the claims. …
[5] The CAD tool generating these drawings is priced at less than USD$50.
[6] With very little work use of a proper CAD tool for these types of computer-related inventions can easily outperform that of a skilled draftsman.
[7] Remember that the CONCLUSION section is a verbatim copy of the ABSTRACT with the substitution “has been disclosed” for “is disclosed” in the ABSTRACT text. The CONCLUSION section is placed as the last piece of specification just before the CLAIMS section.
[8] This paragraph makes reference to the FIG. 1 system diagram previously presented.
[9] Note, however, it is still possible to cover some aspects of signaling claims if a proper hardware context is provided for the claim.
[10] It cannot be overemphasized how the use of MICROSOFT WORD® styles can improve the quality and readability of patent application claims as well as the specification.
[11] For this reason the use of paragraph numbering (“[XXXX]”) should be avoided in writing patent application specifications. This format is very difficult to read and proof, and for long applications such as those in the computer-related arts, impossible to properly form to deal with the hierarchical nature of software-related systems (that by necessity are formed of nested levels of subroutines and other machine procedures).
[12] A good practitioner practice is to include a table of contents at the front of every patent application specification for use by the practitioner and inventor when reviewing the application. Appropriate use of section heading styles (and their hierarchy) within the patent application specification will make both generating the application and proofing it far easier than just incorporating an endless series of numbered paragraphs within the specification that have no apparent structure. As stated before, computer-related inventions have structure, and the patent application should mimic this fact.
[13] A good general rule of thumb is that base SYSTEM and METHOD claims should be compact enough to fit on one page. If the claim is longer than one page, then there should be serious investigation as to whether the claim has been properly abstracted.
[14] Such as the use of MICROSOFT WORD® SEQ field codes to automatically number claims and identify claim dependencies.
[15] It is instructive to note the interplay between invention disclosure and §101/§102/§103 rejections. The more detailed the disclosure, the better chance you have of avoiding these rejections.
[16] 37 CFR 10.76 – CANON 6
A practitioner should represent a client competently.
[17] 37 CFR 10.77 – Failing to act competently
(a) Handle a legal matter which the practitioner knows or should know that the practitioner is not competent to handle, without associating with the practitioner another practitioner who is competent to handle it.
(b) Handle a legal matter without preparation adequate in the circumstances.
(c) Neglect a legal matter entrusted to the practitioner.
[18] There are approximately 40000+ USPTO registered patent attorney/agents, of which approximately 25000 are active. Of these, around 25% have electrical/computer engineering and/or computer science backgrounds. Approximating this at 6000 potential candidates, I estimate that the number of these candidates that could deduce the mutex requirement in the CLS application to be less than 25%. Of the 1500 candidates, my guess is that only about 10% (150) have ever actually implemented a mutex in a computer application. The number of candidates in this subgroup that have actually implemented a mutex on a hardware level is probably counted on one hand. The basis for this estimate lies in the migration towards high level abstraction in electrical engineering/computer technology training. Fewer and fewer coders and hardware developers actually deal with this level of detail in the systems they develop, and the vast majority of software developers that are currently defined as “senior software engineers” are what were traditionally termed “application developers” rather than “system programmers.” The difference in software context constitutes a relatively steep gulf in basic computer science knowledge and experience. A similar migration has occurred in the electrical/computer engineering ranks with an emphasis on logic synthesis rather than primitive hardware level design expertise. This migration has resulted in a loss of fundamental EE and CS knowledge within the ranks of the patent practice corps.
[19] This is in part because the increasing cost of graduate education (both technical and legal) has put significant financial pressures on potential patent practitioners to skip their graduate technical education and proceed directly to law school. For most candidates, the cost of a graduate education (in lost income and debt) coupled with law school tuition rates makes additional technical education and/or industry experience an unaffordable luxury.
[20] As stated by Donald Rumsfeld in a press conference “There are known knowns. These are things we know that we know. There are known unknowns. That is to say, there are things that we know we don’t know. But there are also unknown unknowns. There are things we don’t know we don’t know.”
[21] See U.S. Patent 6,362,697 (FIG. 6).
[22] The circuit is designed as a current reference, but as implemented is bistable. The lack of a startup circuit in this configuration is a fatal omission that fails to enable the circuit. Those skilled in analog IC design will recognize that the startup circuit is the “secret sauce” of any current reference and is very difficult to implement reliably over process variations, power supply fluctuations, and power consumption requirements. I would suggest that most EE undergraduate candidates have never analyzed a current reference of this topology, as it is a topic generally taught in depth only in graduate level analog circuit design courses.
[23] It cannot be overemphasized how difficult it is to properly design and characterize the startup circuitry for these types of circuits. Significant design effort and resources are routinely devoted to ensuring these types of circuits are reliable, efficient, and repeatable. Note also that while the patent in question related to a relaxation oscillator, the patent practitioner may have ignored an opportunity to obtain patent protection for the current reference subcircuit used as an integral part of the oscillator topology (a stable current reference was essential to the proper operation of the oscillator).
[24] The fact that patent practitioners are not required to complete continuing education in their technical field as they are in their legal field only adds to this problem.
[25] Proper training is required. Repeated training that mimics methodologies that have proven to fail in the past cannot be a path to success to solve this problem. It is obvious that there are a good number of trained patent practitioners. The problem is in many cases their training is flawed and has instilled habits inconsistent with the preparation of quality patent applications.
[26] A full discussion of all of the rules and guidelines associated with SIAM is beyond the scope of this article. However, SIAM does incorporate a “best practices” set of rules and templates that ensure that all patent applications are constructed in a similar fashion.
[27] Note that this is in contrast to the current state of the art in which one patent practitioner may draft a patent application and provide this document to an associate who may be prosecuting the patent application before the USPTO. There is currently no standards methodology used among patent practitioners to ensure that these two practitioners operate from the same playbook in this situation. In fact, this same problem occurs among any two patent practitioners that serially work with content in a given patent application.
[28] To paraphrase a quote by George Young, “Running 100 miles a week isn’t hard. Making yourself run 100 miles a week is hard.” Applied to patent preparation, “Writing a 100 pages of disclosure per week isn’t hard. Making yourself write 100 pages of disclosure per week is hard.”
[29] For some reason MICROSOFT VISEO® seems to be a popular choice for this purpose. In my opinion this software when used by most practitioners does not produce an acceptable level of professional quality for computer-related patent applications.
[30] Traditionally large software development projects required a full flowchart complement to be completed before software development could begin. “Modern” software development has essentially eliminated this preliminary design step and as such most patent practitioners today have not been exposed to this design discipline. It is, however, an essential step in ensuring that the generated patent application fully describes the invention. By forcing the invention to be described graphically, missing components (or components that are insufficiently described) are visually evident in the formal drawings. A good rule of thumb for computer-related inventions is that they rarely have less than 16 drawing sheets. While this may seem excessive, the time required to accomplish this is rarely more than 4 hours from the initial intake of the inventor disclosure.
[31] Assuming that the ABSTRACT has been properly written.
[32] A good rule of thumb is “if the individual hasn’t worked in or wouldn’t be employable in the technical field, he/she probably isn’t one of ordinary skill in the art.”
[33] As an example of this instruction, a typical Integrated Circuit (IC) designer will thoroughly vet his/her design before submitting the IC layout for mask generation and eventual production because any error in the design will most likely result in spending an additional $250,000 for new mask sets and a revised production run of the new IC design. The difference with patent practitioners is that the cost of failure can be much higher, isn’t discovered for years, and is typically not recoverable. Thus, the diligence level of patent practitioners should be commensurate with the risk associated with defective or incomplete patent application content.
Kevin Klughart is a lifelong learner who also happens to be a patent/IP/tax attorney and electrical engineer. His practice includes all aspects of intellectual property law, with an emphasis in electrical, electronic, semiconductor, and software technologies.