Archive for August, 2011

In re Aoyama (10-1552) is yet another head scratcher from the Federal Circuit in the area of software patents, and in particular on the topic of what constitutes sufficient software strucutre under 35 U.S.C. § 112 ¶ 6. Judge Newman’s dissent is the only thing that makes any sense in this case. Claim 11, which is representative, and its supporting Figure 8, are set forth below.

11. A system for supply chain management com-prising:

an order controller system including

reverse logistics means for generating transfer data; and

a warehouse system receiving the transfer data and generating shipping data.

As set forth by the majority in In re Aoyam, “The first step in construing a means-plus-function claim limitation is to define the particular function of the claim limitation. … Here, both parties agree that the identified function of the limitation of claims 11 and 21 at issue is “generating transfer data.” The majority goes on: “The next step in construing a means-plus-function claim limitation is to look to the specification and identify the corresponding structure for that function.”

The majority then found, agreeing with the Board, that “[t]here is no structure or algorithm for generating transfer data disclosed in the discussion of Figure 8 at Specification paragraphs 0088-93. These paragraphs do discuss generating shipping data, but again without disclosing any structure or algorithm for doing so.” According to the majority, the Board properly recognized that while Figure 8 provides a high level process flow, “it does not describe any structure.” Accordingly, the majority agreed with the Board’s conclusion that Figure 8 “fails to describe, even at a high level, how a computer could be programmed to produce the structure that provides the results described in the boxes.” Finally, the majority found that “[b]ecause the means-plus-function limitation of claims 11 and 21 lacked sufficient disclosure of structure under 35 U.S.C. § 112 ¶ 6, these claims are unpatentable as indefinite under 35 U.S.C. § 112 ¶ 2.

The majority further states that “For means-plus-function limitations where the disclosed structure is a computer programmed to implement an algorithm, the patent must disclose enough of an algorithm to provide the necessary structure under 35 U.S.C. § 112 ¶ 6.”

As aptly pointed out by the dissenting Judge Newman, Figure 8 and the corresponding portion of the Applicants’ specification discuss at length the computer operation corresponding to the claimed function of generating transfer data. As such, it is difficult to understand the majority’s insistence that the disclosure did not describe sufficient structure or disclosure to satisfy 35 U.S.C. § 112 ¶ 6, particularly since the specification specifies that the functionality described in the flow charts:

“can be implemented in hardware, software, or a suitable combination of hardware and software, and each of which can be one or more software systems operating on separate general purpose processing platforms. As used herein, a hardware system can include discrete semiconductor devices, an applica-tion-specific integrated circuit, a field programma-ble gate array or other suitable devices. A software system can include one or more objects, agents, threads, lines of code, subroutines, separate soft-ware applications, user-readable (source) code, ma-chine-readable (object) code, two or more lines of code in corresponding software applications, data-bases, or other suitable software architectures. “

One question raised by In re Aoyama is whether or not the disclosure supports any structural claim that requires “generating transfer data”, or whether it is only means plus function claims that the disclosure is inadequate to support. Logically speaking, it would seem that if Figure 8 and the specification do not disclose enough structure to support a means plus function claim element, it would not likely comply with 112 (2) either.

﻿If one seeks to avoid having software patent claims found inadequate under 112(2) or 112(6), it would appear that the safest bet is to include object or source code to support the claimed functionality. With object or source code, the application would describe at least one highly particular implementation that would, for any given compiler or interpreter, define a specific software structure. On the other hand, anything short of what might be considered a specific machine-implemented process may be found inadquate.

In the previous post my guest blogger Greg Stark discussed the Federal Circuit’s recent decision in Cybersource Corp v. Retail Decisions, Inc. Greg’s take on on the case is an academic one, one that assumes the the case fits into a logical framework of legal jurisprudence that logical minds can digest and use for sorting inventions, and in particular software inventions, into Section 101 eligible and ineligible categories.

Unfortunately, if we didn’t all know already that the Federal Circuit and Supreme Court were stuck in an endless loop of a hopelessly contradictory algorithm (one part bizarre, one part incomprehensible, and one part schizoid) for deciding the Section 101 issue for software, we were painfully reminded again by the Cybersource decision. It seems that no one is ever going to simply acknowledge that the Supreme Court’s Benson and Flook decisions are largely if not entirely contradictory to the Diehr decision. For example, in my estimation it is quite reasonable to say that the invention in the ‘154 patent constituted an improvement to an automated verification system for use in verifying credit card transactions. If we assume for the sake of argument that such verification systems constitute patent eligible “machines”, then it stands to reason that the application of an otherwise abstract idea to the improvement of the operation of such a machine is patent eligible under the standard laid down in Diehr. In Diehr, an abstract mathematical algorithm was applied to making a rubber mold work better. Accordingly, had the Diehr Court decided the Cybersource decision, using my assumption that an automated credit card verification system is patent eligible, it would have most likely found that the “invention” was an improved credit card verification system, and therefore patent eligible notwithstanding that the point of novelty is found in an abstract idea. In fact, I thought one of the key points in Diehr was to avoid dissecting claimed subject matter into novel and old portions, and focusing on the novel part for patent eligibility. Obviously, if that had been done in Diehr, it would have resulted in rejection of the patent for failure to claim patent eligible subject matter.

Perhaps the Federal Circuit considered an automated credit card verification system as falling outside the type of technology or machines eligible for protection, but on this point they would definitely be flying in the face of common sense. For instance, take a look at the definition for USPTO Patent Class 705:

“This is the generic class for apparatus and corresponding methods for performing data processing operations, in which there is a significant change in the data or for performing calculation operations wherein the apparatus or method is uniquely designed for or utilized in the practice, administration, or management of an enterprise, or in the processing of financial data.”

Granted, the US patent classification system has no bearing on patent eligibility, but it represents the commonly held view that apparatus to perform data processing operations in support of the administration of an enterprise, or the processing of financial data, is real technology, not a mere abstraction.

The Federal Circuit put a warning shot across the bow of patent attorneys that focus on patenting software related inventions. In the case of Cybersource Corp v. Retail Decisions, Inc. the Federal Circuit held that a computer-readable medium claim (Beauregard claim) that merely recites an unpatentable method is also non-statutory subject matter. In other words, the Federal Circuit held that merely putting method steps on a computer-readable medium (CRM) cannot make the method statutory subject matter.

The method claim found unpatentable recites:

3. A method for verifying the validity of a credit card transaction over the Internet comprising the steps of:
a) obtaining information about other transac-tions that have utilized an Internet address that is identified with the [ ] credit card transaction;
b) constructing a map of credit card numbers based upon the other transactions and;
c) utilizing the map of credit card numbers to determine if the credit card transaction is valid.

The unpatentable computer readable medium claim read as follows:

program instructions for detecting fraud in a credit card transaction between a consumer and a mer-chant over the Internet, wherein execution of the program instructions by one or more processors of a computer system causes the one or more processors to carry out the steps of:
a) obtaining credit card information relating to the transactions from the consumer; and
b) verifying the credit card information based upon values of plurality of parameters, incombination with information that identi-fies the consumer, and that may provide an indication whether the credit card transac-tion is fraudulent,
wherein each value among the plurality of pa-rameters is weighted in the verifying step according to an importance, as determined by the merchant, of that value to the credit card transaction, so as to provide the mer-chant with a quantifiable indication of whether the credit card transaction is fraudulent,
wherein execution of the program instructions by one or more processors of a computer system causes that one or more processors to carry out the further steps of;
[a] obtaining information about other transactions that have utilized an Internet address that is identified with the credit card transaction;
[b] constructing a map of credit card numbers based upon the other trans-actions; and
[c] utilizing the map of credit card num-bers to determine if the credit card transaction is valid.

The Federal Circuit analogized this case to In re Abele to support disposing of the CRM claim as non-statutory subject matter. The court states that “[r]egardless of what statutory category a claim’s language is crafted to literally invoke, we look to the underlying invention for patent-eligibility purposes.” Thus, the Federal Circuit considered this CRM claim to be nothing more than a claim to a process, which they considered analogous to the method claim that was already determined to be unpatentable subject matter.

What about the fact that operations stored on a CRM can only be executed on a computer, one might ask. The opinion does not directly address this, but does make the following related arguments. The first concerning related argument is stated as, “Cybersource has not met its burden to demonstrate that claim 2 is ‘truly drawn to a specific’ computer readable medium, rather than to the underlying method of credit card fraud detection.” What is a specific computer readable medium? At least in theory, any CRM with unique instructions stored on it would have been considered a “specific computer readable medium,” at least prior to this opinion. Judge Dyk continues with the following statement regarding the CRM claim, “the incidental use of a computer to perform the mental process of claim 3 does not impose a sufficiently meaningful limit on the claim’s scope.” While it is undeniable that the claims at issue in this matter are broad, reciting operations in a CRM format means that all of the operations must be performed by a computer. The fact that the operations must be performed on a computer seems to make it more than “incidental use” of a computer.

It will be interesting to watch this case to see if the patent owner requests a rehearing en banc. Unfortunately, despite the opinion’s statement that “it is clear from the emphasized text that claim 2 recites nothing more than a computer readable medium containing program instructions for executing the method of claim 3,” the CRM actually contains at least one additional element. The additional recitation in the CRM claim reads as follows:

verifying the credit card information based upon values of plurality of parameters, in combination with information that identifies the consumer, and that may provide an indication whether the credit card transaction is fraudulent,

wherein each value among the plurality of parameters is weighted in the verifying step according to an importance, as determined by the merchant, of that value to the credit card transaction, so as to provide the merchant with a quantifiable indication of whether the credit card transaction is fraudulent,…

Interestingly, at least the highlighted portion of the additional recitation in the CRM appears to be claiming a tangible result that would be produced by a computer performing these operations (e.g., scoring a transaction – quantifiable indication). The fact that this panel of the Federal Circuit appears to ignore this portion of the CRM claim provides any future panel an easy out for overturning this decision. Because the CRM claim does not literally recite only the unpatentable method steps, this case is unlikely to provide any clear guidance to the patent community.

Obviously, this decision from the Federal Circuit is concerning for patent attorney’s attempting to draft valid claims to software implemented inventions. The decision highlights the need to include independent claims from as many different statutory classes as possible (e.g., method, system, and CRM). Additionally, the decision emphasizes the importance of drafting method claims that recite statutory subject matter (ideally methods that satisfy the machine or transformation test). At a minimum, the Federal Circuit has made the difficult job of claiming software implemented inventions more difficult and less predictable.

Greg Stark and Suneel Arora of Schwegman, Lundberg & Woessner, P.A., together with law student Ryan Sharp, recently wrote an informative article for William Mitchell’s Cybaris IP review, entitled, “Can Beauregard Claims Show You The Money?” It has been 15 years since In Re Beauregard. The article answers some interesting questions, including: 1)are people still using these claims?; are they being litigated?; and, are they effective? The article also comments on the impact of last year’s Finjen v. Secure Computing case.

This post, from Greg Stark, Schwegman, Lundberg & Woessner, P.A., addresses some of the issues raised by the recent publicity offensive Google has launched against Apple and Microsoft.

August 4, 2011:

Patent Disputes continue in the Mobile OS and Application Space – Does any of this “Progress the Useful Arts” (Drive Innovation)?

News outlets and blogs have been filled with hyperbole regarding the offensive use of patents (or potential offensive use of patents) in the smartphone wars between Apple, Google, Microsoft, and RIM. The latest volley getting noticed came from Google’s David Drummond who is accusing various organizations, including Microsoft and Apple, of wagging a patent war against Android. This particular post received a great deal of attention when Microsoft released an email indicating that they invited Google to join the group bidding for the Novell patent portfolio. I highlight this exchange only to emphasize the amount of hand waving and misinformation that is being put forth on this issue.

Mr. Drummond does start to get at the real issue, innovation and whether the US patent system (or any patent system) drives or hinders innovation. Mr. Drummond claims to be on the side of the patent system harming innovation (at least when used against Android). As a patent professional, I believe (somewhat self-servingly) in the benefits of the patent system. However, it is admittedly difficult to determine whether the system actually drives innovation.

There can be little dispute that Google is a fast-follower in the mobile operating system business, and until recently Android did not appear to break much new ground. It is also certain that the strong competition from Android has forced Apple, Microsoft, RIM, and others to work harder on multiple fronts. Hopefully, the increased competition has been good for innovation, only time will tell.

What role are patents playing in the smartphone wars? Well if you believe the media patents are being used as the offensive weapon of choice to slow or tax the growth a new entrants, such as Google’s Android. As a fast-follower, it is hard to feel bad for a large well funded organization like Google, when a pioneering competitor attempts to use valid legal methods to maintain its position in the marketplace. For example, Apple may be attempting to hinder the growth of the Android operating system by asserting its patent portfolio against Google and handset manufacturers, such as Samsung. However, Apple is merely asserting presumably valid intellectual property covering its own mobile operating system and smartphone.

Getting back to the question of driving innovation, did the ability for Apple to receive a limited Government sanctioned monopoly (e.g., a patent) drive early innovation in Apple’s mobile operating system? On some level I am sure that the protections afforded by patent did drive some of the innovation, but it is very difficult to measure. At a minimum one can reasonably assume that companies like Apple and Google obtain patents to assist in obtaining a return on investments in research and development. Can anyone blame Apple, a company that was hugely influential in driving the multi-touch display smart-phone boom, for defending its turf against what they perceive to be a copy-cat technology?

Defending patents as driving innovation becomes much more difficult when an organization like Lodsys, LLC sues individual smartphone application developers. Lodsys appears to be a typical non-practicing entity (commonly referred to as a Patent Troll) with a business model of developing (or more likely purchasing) a portfolio of patents and then attempting to collect loyalties from potential infringers. Lodsys is hard to defend as a driver of innovation primarily because they do not produce a product, much less a product that would be protected by the patents they are asserting. Additionally, Lodsys does not do or presumably drive any additional innovation to develop new technology.

The primary argument made in favor of organizations like Lodsys is that they help individual inventors and small companies to protect their innovations, and more easily receive value for those innovations even when they are unable, for any one of a number of reasons, to successfully bring their innovations to market. Thus, encouraging individual inventors or small companies to continue to innovate (or so the argument goes). The patents being asserted by Lodsys do appear, to a degree, to fit into this argument (of course records indicate that the inventor on the Lodsys patents first assigned the rights to these patents back in 2005 long after his initial innovation). Additionally, Mr. Abelow, the inventor on the patents being asserted by Lodsys, was probably not encouraged to develop the technology protected by these patents simply to have an organization like Lodsys stop others from allegedly using his invention.

According to Engadget, in at least one of the suits, Lodsys is asserting that application developers using in-app upgrade purchases, a feature of iOS from Apple, are infringing one or more of the patents. A quick review of the patents at issue does not immediately reveal how Lodsys intends to support this claim. However, the patent claims use very broad language and the patents have a fairly early priority date (1994). The issue these patents raise for small organizations, like smartphone application developers, is that it is difficult to judge what the patent may actually cover without engaging expensive legal counsel. Without conducting fairly extensive claim construction based on the patent’s specification and file history, the exact boundaries of the claims are unknown.

Generally, the downside to an organization such as Lodsys for filing questionable law suits (assuming, solely for the sake of argument, that the asserted patents do not actually cover the accused activities), has been minimal. The Federal Courts have historically been surprisingly tolerant of questionable patent assertions. However, a recent Federal Circuit decision may ultimately force organizations such as Lodsys to think twice about making questionable assertions.

In Eon-Net v. Flagstar Bancorp, the Federal Circuit showed some indication that they are looking to reign in frivolous law suits. The Federal Circuit upheld a lower court decision to sanction and fine Eon-Net for bringing a baseless infringement suit against Flagstar. As a result of Eon-Net’s misconduct, the patentee-plaintiff was slapped with Rule 11 sanctions totaling over $140,000 for failure to perform a reasonable pre-filing investigation. The district court also awarded Flagstar over $489,000 in attorney fees and costs. While this is a welcome outcome for a particularly egregious case, to get to this point Flagstar had to be willing to put up close to $500,000 and risk losing much more!

In the end, I believe patents can assist in progressing the useful arts (e.g., driving innovation), by providing the incentive of a limited monopoly.

Recently, James Bessen, a Lecturer in Law at the Boston University School of Law, published the article entitled “A Generation of Software Patents.” (Boston University School of Law Working Paper No. 11-31, June 21, 2011). The article implies that software patents are of little value to software startups. My guest blogger, Peter Leal, has studied this article in detail and has found some surprising and fundamental flaws both in its assumptions and its conclusions.

A new paper[2] from Boston University reports that most “software firms” account for relatively little of the activity in software patenting.[3] The paper also implies that software patents are of little value to software startups.[4] Both of these conclusions appear specious or irrelevant.

The comments below use the paper’s own definition of “software patents.” This is not an endorsement of the definition as being the correct definition of “software patents.”

The Paper’s Conclusion that “Software Firms” Account for Relatively Little of the Activity in Software Patenting

When determining patent activity of companies in a particular industry, one searches the USPTO assignment records to determine patents and/or patent applications that are owned by the companies that make up that industry. To obtain a true picture, the patent applications for inventions those companies make must be assigned to those companies in the USPTO records. If for some contractual reason many, or most, of the inventions made by companies in a particular industry are assigned to firms outside that industry, the person determining the patent activity by simply counting patents assigned to companies within the industry will get a false reading. That’s what happened with the BU paper. The paper’s assumption that all, or even most, patent applications for inventions made by “software firms” are owned by those firms is a false assumption. The paper goes to great lengths to analyze the patent activity of “software firms” that it defines[5] as “software publishing and software services firms,”[6] without addressing the above fact. For this reason, the conclusion the paper draws about the number of patents assigned to “software firms” is flawed.

To illustrate the above, the North American Industry Classification System for Computer Software[7] lists firms in the “software services firms” category as:[8]

Applications software programming services, custom computer

Computer program or software development, custom

Computer programming services, custom

Computer software analysis and design services, custom

Computer software programming services, custom

Computer software support services, custom

Software analysis and design services, custom computer

Software programming services, custom computer

Computer software consulting services or consultants

Web (i.e., internet) page design services, custom

In most, or perhaps even the vast majority, of the above service firms, the service is a custom service and the firm develops custom code for a client. Because the client pays for the code, the service contract between the service firm and the client usually provides that inventions made developing the code are assigned to the client. This means that to the extent there are software inventions made and software patent applications filed, they would be assigned to the client who more likely than not is outside the software services firm category (otherwise the client would probably do the job itself).

Consequently, less than all, and perhaps relatively few, software patents for software inventions made by “software service firms” (a category that comprises a major portion of the paper’s definition of “software firms”) are actually assigned to them. The very nature of their work usually results in software inventions they make being assigned away. The BU paper doesn’t account for this, resulting in a flawed set of numbers and a flawed conclusion.

Furthermore, as to “software publishing firms,” which is the second category of firms in the definition of “software firms,” the conclusion reached by the paper fails to consider whether these firms are likely to make inventions. The basic tenet of patent law is that only inventions can be patented. A corollary to this is that most inventions are made through research, and through the development of products (R&D). Software publishing firms employ some of the most talented and creative people in the country who provide software services that are critical to the nation’s competitiveness. But many, if not most, of these firms do little or no R&D. It’s not in their business plan to do so. Given that patents are granted only for inventions, and that most inventions are made by firms that do R&D, one would expect fewer software inventions (and therefore less software patenting) from the category “software publishing firms” than from firms that primarily develop products. To see this, consider the North American Industry Classification System for Computer Software[9] description of the function of “software publishing” firms:[10]

Establishments in this industry carry out operations necessary for producing and distributing computer software, such as designing, providing documentation, assisting in installation, and providing support services to software purchasers. These establishments may design, develop, and publish, or publish only.[11]

From the above NAICS quotation, some software publishers do perform R&D, but R&D is certainly not the focus of all, or even most, of these firms. Many of these firms, as seen from the above NAICS quotation, perform distributing software, providing documentation, assisting in installation, and providing support services. From a careful inspection of these functions, the conclusion is that although the work of these firms is critical to the country, one would not expect to find a major number of software inventions (and, concomitantly, software patents) arising from this category of firms. So the paper’s conclusion is, again, flawed.

The Paper’s Conclusion that Software Patents are of Little Value to Software Startups.

This conclusion in the paper is also flawed, for at least three reasons.

The first reason is that the paper states[12] that only 24% of venture backed startups had any patents within four years of receiving funding, apparently concluding that this indicates a lower patent propensity for startups. However except for possibly one or two inventions that form the basis for a startup, time would have to be allowed for most startups to conceive and reduce inventions to practice before patent applications would be filed. This, and an understanding of the backlog at the USPTO, would lead one to conclude that even 24% of startups having their patent applications examined and issued within four years illustrates a good rate of patent activity for startups. Most of their patent applications would be expected to be pending and not yet issued during that four year period. The opposite conclusion reached by the paper is not justified by the facts.

The second reason is that the paper states[13]that it has been reported that there is a positive correlation between patent applications and the probability of a startup achieving financing, IPO, and acquisition. The paper then makes a distinction between issued patents and pending patent applications, apparently concluding that this distinction somehow dilutes the positive correlation.[14] Again, in view of the time needed to make inventions and to file patent applications on, them, and in view of the backlog at the USPTO, financing, IPO, and acquisition of a startup usually occurs within the period of time that a patent application would be pending in the backlog and not yet issued. Hence the distinction the paper makes here is irrelevant.

The third reason is that the paper itself acknowledges that 67% of software startups backed by venture capital held patents.[15] However, the paper then suggests that the increase in patenting over the last decade for venture-backed software startups might have more to do with the changing behavior of venture capitalists rather than changing benefits for software startups.[16] However, the better reasoned conclusion would appear to be that venture capitalists, who are among the most seasoned business people in the world, understand that software patents are valuable to software startups. Consequently they tend to select for financing primarily startups that have software patent applications for their software inventions. This is by definition a benefit for software startups, contrary to the paper’s opposite suggestion.

Conclusion

The paper’s conclusion that “software firms,” account for relatively little of the activity in software patenting appears to be irrelevant to any conclusion about the value of software patents. The software inventions that “software services firms” (that comprise a large part of the definition of “software firms”) make are usually assigned to their clients, who are often outside that industry. In addition, one would not expect a large number of inventions to be made by “software publishing firms.” Many software publishing firms perform distributing software, providing documentation, assisting in installation, and providing support services. One would not expect inventions to be made in these functions.

The paper’s conclusion that software patents are of little value to software startups is contradicted by the fact that 67% of venture backed software startups file patent applications. The fact that software startups that obtain venture backing are primarily those that file software patent applications means that venture capitalists, who are some of the most seasoned business people in the world, see value in software patents for software startups.