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 from a 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.
Prof. Mark Lemley of Stanford, in Software Patents and the Return of Functional Claiming, suggests that many software claims are essentially “functional claims”, where a function is claimed instead of a structure, and that functional claims are responsible for many of the issues surrounding software claims. He points out that the inherent flexibility of computing hardware means that recitations of computer structure in claims does not actually provide meaningful limitations. His solution: treat software claims as means- (or steps-) plus-function claims according to 35 USC 112(f), thereby restricting the claims only to the embodiments disclosed in the specification and equivalents.
Part 1 of the article provides historical background on functional claims and the evolution of 35 USC 112(f). Part 2 explains why software patent claims are “functional claims”. Part 3 describes why Prof. Lemley believes that functional claiming is responsible for many of the problems associated with software patent claims, and the pros and cons of some potential solutions. Part 4 describes Prof. Lemley’s own proposed solution, which is to read software claims as means- (or steps-) plus-function claims. Prof. Lemley argues that this solution (a) does not require drastic changes, (b) will require that patentees “disclose the algorithms they use to achieve particular ends”, and (c) will limit a patent only to disclosed algorithms and “equivalents thereof”, thereby addressing the “functional claim” issue and solving many of the problems associated with software claims.
Will restricting a software claim only to “disclosed algorithms” really make a difference though? Many "functional" software claims recite a series of steps (e.g., "receiving..., determining..., adjusting...", etc.; see claim above as an example). Most of these steps can be expressed as steps in an algorithm. Leaving aside the debate as to whether algorithms themselves should be patentable, reading these software claims as steps-plus-function claims under 112(f) merely moves the description of the algorithm from the claims into the specification. The specification will of course have to describe the algorithm steps in detail, and perhaps even provide concrete examples of how particular steps can be implemented. However, algorithms at their root are lists of operations, with each operation selected from a finite set. Patent drafters would certainly attempt to capture that finite set of operations in the specification. If they succeed, then we are essentially back in the same boat.
Also, what about “equivalents”? Prof. Lemley notes that 112(f) equivalents “do not apply to later-developed structures, but only to equivalents known at the time the patent issued,” and “[b]ecause software changes so quickly, most litigated software patents today are asserted against technologies that did not exist at the time of patenting.” If the "structure" being patented is an algorithm, wouldn't later technology using that algorithm still be equivalent?
Would treating software claims as 112(f) claims make a significant difference? I don't know, but I lean towards "no". However, treating software claims as means- (or steps-) plus-function claims probably won't be worse than the current state of affairs. I would be curious to see a study of software patent cases comparing the claim construction that actually occurred with embodiments actually disclosed in the specification.
