The courts have been particularly active recently with respect to the question of what is patentable subject matter.  Despite this activity, there has been no real guidance provided by the courts to practitioners. In CLS Bank v. Alice Corp., the Federal Circuit found the claimed computer-related subject matter not patentable.  Unfortunately, there were seven different opinions in the case containing at least three different approaches to determining whether particular subject matter is patentable.

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;

(b)  electronically adjust said shadow credit record and/or said shadow debit record in order to effect an exchange obligation arising from said transaction, allowing only those transactions that do not result in a value of said shadow debit record being less than a value of said shadow credit record; and

(c)  generate an instruction to said exchange institution at the end of a period of time to adjust said credit record and/or said debit record in accordance with the adjustment of said shadow credit record and/or said shadow debit record, wherein said instruction being an irrevocable, time invariant obligation placed on said exchange institution.

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:

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:

(a)  creating a shadow credit record and a shadow debit record for each stakeholder party to be held independently by a supervisory institution from the exchange institutions;

(b)  obtaining from each exchange institution a start-of-day balance for each shadow credit record and shadow debit record;

(c)  for every transaction resulting in an exchange obligation, the supervisory institution adjusting each respective party’s shadow credit record or shadow debit record, allowing only these [sic] transactions that do not result in the value of the shadow debit record being less than the value of the shadow credit record at any time, each said adjustment taking place in chronological order; and

(d)  at the end-of-day, the supervisory institution instructing one of the exchange institutions to exchange credits or debits to the credit record and debit record of the respective parties in accordance with the adjustments of the said permitted transactions, the credits and debits being irrevocable, time invariant obligations placed on the exchange institutions.

Again, this activity could read on human activity exclusively, with the parties involved being accountants and their respective supervisors.

Representative Media Claim

Claim 39 of the ’375 Patent, representative of the product (media) claims, recites:

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:

program code for causing a computer to send a transaction from said first party relating to an exchange obligation arising from a currency exchange transaction between said first party and said second party; and

program code for causing a computer to allow viewing of information relating to processing, by a supervisory institution, of said exchange obligation, wherein said processing includes

(1)  maintaining information about a first account for the first party, independent from a second account maintained by a first exchange institution, and information about a third account for the second party, independent from a fourth account maintained by a second exchange institution;

(2)  electronically adjusting said first account and said third account, in order to effect an exchange obligation arising from said transaction between said first party and said second party, after ensuring that said first party and/or said second party have adequate value in said first account and/or said third account, respectively; and

(3)  generating an instruction to said first exchange institution and/or said second exchange institution to adjust said second account and/or said fourth account in accordance with the adjustment of said first account and/or said third account, wherein said instruction being an irrevocable, time invariant obligation placed on said first exchange institution and/or said second exchange institution.

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>;

wherein

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:

(a) <element>;

(b) <…>;

(c) <element>;

wherein

said <element> … ;

said … ; and

said <element> … ;

…

wherein said method comprises the steps of:

(1)  <step>;

(2)  <…>; and

(3)  <step>.

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).

Title

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:

…

wherein said method comprises the steps of:

…

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:

…

wherein said method comprises the steps of:

…

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.

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.

Abstract

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:

Conclusion

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);

wherein

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:

(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.

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:

Generalized Computer Usable Medium

In various alternate embodiments, the present invention may be implemented as a computer program product for use with a computerized computing system.  Those skilled in the art will readily appreciate that programs defining the functions defined by the present invention can be written in any appropriate programming language and delivered to a computer in many forms, including but not limited to: (a) information permanently stored on non-writeable storage media (e.g., read-only memory devices such as ROMs or CD-ROM disks); (b) information alterably stored on writeable storage media (e.g., floppy disks and hard drives); and/or (c) information conveyed to a computer through communication media, such as a local area network, a telephone network, or a public network such as the Internet.  When carrying computer readable instructions that implement the present invention methods, such computer readable media represent alternate embodiments of the present invention.

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.

Claim Formatting

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]

Acronyms

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.

Claim Interpretation

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:

Claims

Although a preferred embodiment of the present invention has been illustrated in the accompanying drawings and described in the foregoing Detailed Description, it will be understood that the invention is not limited to the embodiments disclosed, but is capable of numerous rearrangements, modifications, and substitutions without departing from the spirit of the invention as set forth and defined by the following claims.

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.

What is claimed is:

…

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 financial transaction processing system comprising:

(a)  exchange institution computer (EIC);

(b)  exchange transaction computer (ETC); and

(c)  computer communications network (CCN);

wherein

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

A financial transaction processing method comprising:

(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

A tangible non-transitory computer usable medium having computer-readable program code means embodied thereon comprising a financial transaction processing method comprising:

(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 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.

Summary

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.

---

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.

This blog is maintained by Carstens, Allen & Gourley, LLP to inform readers of recent developments in intellectual property. Solely informational in nature, this blog is not intended to create an attorney-client relationship or to be used as a substitute for legal advice or opinions. For more information, please visit www.caglaw.com.

By Kevin Klughart