Wednesday, May 9, 2018

Patent Board extends software per se, printed matter doctrines to reject computer-readable media (CRM) claims


Takeaway: Bucking decades of settled precedent and USPTO guidance, the Patent Board rejected claims reciting computer-readable media (CRM) as subject-matter ineligible software per se and printed matter, even as it reversed Alice rejections of the same claims.

Note: This is the second of two posts covering the same PTAB decision.  For the other, see "IBM wins reversal of Alice rejections for targeted ad delivery at airports".

Details:

Ex parte Musial

Appeal No. 2017-001164; Application No. 13/396,177; Tech. Center 3600
Decided: Apr. 30, 2018

Inventors for IBM filed an application relating to "a computer implemented method, data processing
system, and computer program product for . . . distributing advertisements to receptive audiences", and more specifically captive audiences sitting in airport terminals waiting to board their flights, or aboard airplanes waiting to take off or deboard.  The Board reproduced rejected independent claim 14 as representative:
14.     A computer program product for selecting an advertisement, the computer program product comprising:
         a computer readable non-transitory medium having computer readable program code stored thereon, the computer readable program code comprising:
                  program instructions to receive a first check-in corresponding to at least one person, wherein the first check-in is a indication of presence relative to an airport gate servicing a flight and the first check-in is received from a kiosk;
                  program instructions to receive a second check-in to form an aggregation of people, wherein the second check-in is a indication of presence relative to the airport gate servicing the flight;
                  program instructions to characterize the aggregation based on cumulative characteristics selected of at least one vital statistic of each person checking-in to form an aggregated population characteristic;
                  program instructions to receive flight details concerning the flight, wherein the flight details comprise a flight destination, and the advertisement concerns a service provider at the flight destination;
                  program instructions to select at least one advertisement based on the aggregated population characteristic and the flight details, in response to the second check-in;
                  program instructions to receive a check-out of at least one person, wherein the check-out comprises reading an identifier of an at least one person who departs;
                  program instructions to select at least one advertisement based on the aggregated population characteristic;
                  program instructions to second characterize the aggregation based on the cumulative characteristics to form a second cumulative characteristic based on the aggregation without at least one vital statistic corresponding to the at least one person who departs, wherein the program instructions to select at least one advertisement based on the aggregated population characteristic perform to select the at least one advertisement is based on the second cumulative characteristic;
                  program instructions to select at least one advertisement based on the second cumulative characteristic, and a destination of the flight details, wherein the destination is stated within the at least one advertisement;
                  program instructions to dispatch the at least one advertisement; and
                  program instructions to detect presence of a service vehicle associated with a flight near and outside an aircraft associated with the flight, wherein the detecting presence relies on at least one global positioning satellite (GPS) signal received at the service vehicle and reported as location data to the hardware processor, wherein program instructions to dispatch comprises instructions to dispatch the at least one advertisement to the service vehicle for rendering and such dispatching is responsive to detecting presence of the service vehicle.
(Emphasis added.)  The examiner rejected the claims as subject-matter ineligible under the Alice framework and its judicially-made exceptions to 35 U.S.C. § 101, but the Board reversed those rejections, and entered new grounds of rejection, finding the claims to be subject-matter ineligible as "directed to software per se and, thus, are not within one of the four classes of statutory subject matter", and also as "a mere arrangement of 'printed matter' and merely claiming the content of 'printed' information."

My two cents:

There are a couple of ways to read this surprising decision, but either interpretation leads to the conclusion of egregious Board error.  In the first and more generous interpretation of what happened in Musial's new grounds, the Board got distracted by the description in the specification and overlooked the limitations of the claims.  This would explain why the Board devotes ink to two long footnotes (notes 4 and 5) quoting portions of the specification allegedly supportive of a software per se interpretation, including, among other selections, language providing that "one or more embodiments may take the form of . . . an entirely software embodiment."  Although specification language may be used to construe or define claim terms, it would be an obvious misapplication of the law if the Board looked to the specification to override and effectively delete limiting language in the claims, in this case, the language specifying that the computer program product comprised a computer readable non-transitory medium having computer readable program code stored thereon.  Recitation of computer-readable media (specified as non-transitory in compliance with the prohibition of claiming transitory signals per se, as discussed in In re Nuijten, 500 F.3d 1346, 1356-57 (Fed. Cir. 2007)) suffices to avoid a software per se rejection, as discussed below.  The applicants' casting of the claims in CRM form must be seen as an express disclaimer of any broader scope inclusive of software per se, even if such may be described in the specification.

The theory that the Board simply got distracted by spec language is also difficult to reconcile with the Board's express finding that "the 'computer readable non-transitory medium' as claimed . . . also does not exclude it being software [per se]."  Except that it does; see, e.g., MPEP § 2111.05(III); Ex parte Kouznetsov, No. 2007-003470 (B.P.A.I. June 30, 2008) (“When functional descriptive material is recorded on some computer-readable medium, it becomes structurally and functionally interrelated to the medium and will be statutory in most cases since use of technology permits the function of the descriptive material to be realized.”).  The Board makes this conclusory declaration without any reasoning or citation to established law.  Indeed, the Board's decision goes against established law, the MPEP, and published USPTO guidance.  Thus, the second reading of the Board's decision is that it was made in ignorance.

The Board's new grounds of rejection cannot be reconciled with the ultimate outcome of the trilogy of mid-'90s Federal Circuit cases of In re Warmerdam, 33 F.3d 1354 (Fed. Cir. 1994), In re Lowry, 32 F.3d 1579 (Fed. Cir. 1994), and In re Beauregard, 53 F.3d 1583 (Fed. Cir. 1995), of which discussion can be found in the journal article by Vincent Chiappetta, Patentability of Computer Software Instruction as an 'Article of Manufacture": Software as Such as The Right Stuff, 17 J. Marshall J. Computer & Info. L. 89 (1998).  These cases culminated in the February 1996 USPTO Examination Guidelines for Computer-Related Inventions.  These guidelines state, with regard to functional descriptive material:
   [C]omputer programs claimed as computer listings per se, i.e., the descriptions or expressions of the programs, are not physical "things," nor are they statutory processes, as they are not "acts" being performed.  Such claimed computer programs do not define any structural and functional interrelationships between the computer program and other claimed aspects of the invention which permit the computer program's functionality to be realized.  In contrast, a claimed computer-readable medium encoded with a computer program defines structural and functional interrelationships between the computer program and the medium which permit the computer program's functionality to be realized, and is thus statutory.  Accordingly, it is important to distinguish claims that define descriptive material per se from claims that define statutory inventions.
   Computer programs are often recited as part of a claim.  Office personnel should determine whether the computer program is being claimed as part of an otherwise statutory manufacture or machine.  In such a case, the claim remains statutory irrespective of the fact that a computer program is included in the claim.  The same result occurs when a computer program is used in a computerized process where the computer executes the instructions set forth in the computer program.  Only when the claimed invention taken as a whole is directed to a mere program listing, i.e., to only its description or expression, is it descriptive material per se and hence non-statutory.
(Emphases added.)  These guidelines were published after Beauregard, wherein the USPTO finally ceded the issue and recognized that claims reciting software embodied on a tangible medium constituted patent-eligible subject matter.  The '90s trilogy led to the evolution of the distinction between functional and non-functional descriptive material; even as late as Beauregard, software, despite being functional, was being rejected under the printed matter doctrine.  As the Federal Circuit found earlier in Lowry, "the printed matter cases have no factual relevance where 'the invention as defined by the claims  requires that the information be processed not by the mind but by a machine, the computer.'"  32 F.3d at 1583 (citing In re Bernhart, 417 F.2d 1395, 1399 (C.C.P.A. 1969), having an identical holding) (emphasis in original).  Lowry's claim 1 read as follows:
1.      A memory for storing data for access by an application program being executed on a data processing system, comprising:
         a data structure stored in said memory, said data structure including information resident in a database used by said application program and including:
                  a plurality of attribute data objects stored in said memory, each of said  attribute data objects containing different information from said database;
                  a single holder attribute data object for each of said attribute data objects, each of said holder attribute data objects being one of said plurality of attribute data objects, a being-held relationship existing between each attribute data object and its holder attribute data object, and each of said attribute data objects having a being-held relationship with only a single other attribute data object, thereby establishing a hierarchy of said plurality of attribute data objects;
                  a referent attribute data object for at least one of said attribute data objects, said referent attribute data object being nonhierarchically related to a holder attribute data object for the same at least one of said attribute data objects and also being one of said plurality of attribute data objects, attribute data objects for which there exist only holder attribute data objects being called element data objects, and attribute data objects for which there also exist referent attribute data objects being called relation data objects; and
                  an apex data object stored in said memory and having no being-held relationship with any of said attribute data objects, however, at least one of said attribute data objects having a being-held relationship with said apex data object.
(Emphasis added.)  With regard to this broadest claim, the Federal Circuit concluded:
More than mere abstractions, the [claimed] data structures are specific electrical or magnetic structural elements in memory. . . . [They] provide tangible benefits: data stored in accordance with the claimed data structures are more easily accessed, stored and erased. . . . [They] are physical entities that provide increased efficiency in computer operation.  They are not printed matter.  The Board is not at liberty to ignore such limitations.
Id. at 1583-84.  In other words, Lowry's claims related to the physical organization imparted to the data in the memory, and not data in the abstract.  Id. at 1583.

In Beauregard, the solicitor didn't even bother to defend the Board's affirmance of the examiner's rejection of computer program product claims as printed matter.  The solicitor averred before the Federal Circuit "that computer programs embodied in a tangible medium, such as floppy diskettes, are patentable subject matter under 35 U.S.C. § 101".  The CAFC appeal was withdrawn without a fight, and the February 1996 Guidelines were issued a few months later.  The USPTO position as to functional descriptive material was repeated in the November 2005 Interim Guidelines for Examination of Patent Applications for Patent Subject Matter Eligibility ("When functional descriptive material is recorded on some computer-readable medium it becomes structurally and functionally interrelated to the medium and will be statutory in most cases since use of technology permits the function of the descriptive material to be realized.").  CRM claims came to be known as "Beauregard claims".  Although § 101 law as a whole has evolved considerably since the time of the February 1996 and November 2005 Guidelines, particularly with the Supreme Court's judicial-exception decisions in Bilski, Mayo, and Alice, that evolution is not pertinent in the present consideration rejecting Beauregard claims as software per se, since the Board found the claims not to be ineligible under the framework that evolved from the abstract-idea cases.

It's also notable that the Board made the software per se new grounds of rejection despite the claims being amended, immediately prior to appeal, specifically to recite the "computer readable non-transitory medium" by examiner request and with examiner assurance, in an interview, that such language constitutes the preferred phrasing.

As alluded to above, the Board's rejection of the claims under the "printed matter" doctrine (or what is modernly and more accurately termed "nonfunctional descriptive material" doctrine) is as flawed as the rejection of the claims as software per se.  As explained in the "informative" Board decision of Ex parte Mathias, No. 2005-1851, 84 USPQ2d 1276, 1278-79 (B.P.A.I. Aug. 10, 2005),
[c]ommon situations involving nonfunctional descriptive material are:
- a computer-readable storage medium that differs from the prior art solely with respect to nonfunctional descriptive material, such as music or a literary work, encoded on the medium,
- a computer that differs from the prior art solely with respect to nonfunctional descriptive material that cannot alter how the machine functions (i.e., the descriptive material does not reconfigure the computer), or
- a process that differs from the prior art only with respect to nonfunctional descriptive material that cannot alter how the process steps are to be performed to achieve the utility of the invention
None of these scenarios are applicable here in Musial.  The Board in the present case cites to In re DiStefano, 808 F.3d 845 (Fed. Cir. 2015), in support of its finding that the claimed CRM computer program product constitutes printed matter, but DiStefano does not support the Board's conclusion; on the contrary, the CAFC in DiStefano vacated a Board finding that web assets amounted to printed matter.  "The common thread amongst all" printed matter cases, the reviewing court explained, "is that printed matter must be matter claimed for what it communicates", and the content of the information was not being claimed in DiStefano.  In re Miller, 418 F.2d 1392 (C.C.P.A. 1969), also cited by the Board in the present case, likewise was a court reversal of a Board decision of unpatentability, and fails to support the Board's contention that the CRM claims are printed matter.

It is, of course, not correct to say that the nonfunctional descriptive material doctrine never applies to software claims.  When the doctrine is properly applied, an isolated feature at the point of novelty is shown to be descriptive rather than functional.  Mathias presents the classic case, wherein, in a claim directed to an "on-screen icon", the recited sporting event icon was "non-functional descriptive material [that] cannot lend patentability to an invention that would have otherwise been anticipated by the prior art."  As a sampling of representative cases, one can point to, e.g., Ex parte Curry, No. 2005-0509, 84 USPQ2d 1272 (B.P.A.I. June 30, 2005); Ex parte Nehls, No. 2007-1823, 88 USPQ2d 1883, 1887-89 (B.P.A.I. Jan. 28, 2008) (precedential); Ex parte Kerr, No. 2009-013183 (P.T.A.B. Dec. 26, 2012); Ex parte Okamoto, No. 2012-000836 (P.T.A.B. Jan. 23, 2013); Ex parte Gooch, No. 2010-008687 (P.T.A.B. July 26, 2013); Ex parte Sen, No. 2011-006544 (P.T.A.B. Dec. 23, 2013); Ex parte Sharma, No. 2010-011909 (PT.A.B. June 7, 2013).  However, the Board in Musial fails to explain how any of these cases are relevant or how the point-of-novelty feature (if any single one can be pointed to) amounts to matter that is purely nonfunctional and descriptive.  Consequently, the rejection of the claims as printed matter is misplaced.

Generally, when the Board suspects a new reason for unpatentability but would prefer not to do the heavy lifting of demonstrating it with reasoned explanation in its opinion, the Board notes the potential new grounds, as in a footnote, by way of suggestion to the examiner to inquire into such grounds upon return of the application to the examiner's jurisdiction.  The Board did not do that in this case, and instead made rejections inconsistent with the law in this area.  The panel overlooked the significance of the physical media recitation or misapprehended the meaning of "software per se".

32 comments:

  1. "erroneously rejecting Beauregard claims as directed to printed matter."

    I disagree with the characterization of the Dom opinion. At the outset, it must be remembered that the claims in Beauregard were in the form of "means plus function" and required construction in accordance with 35 usc 112, paragraph six. In Dom, the panel found that one of the claims (not mpf) did not preclude printed matter embodiments -- e.g., mere printed instructions on paper, such a computer program listing. Accordingly, the panel rejected the claim as being directed to non-statutory subject matter. Slip op. at 8-9. In any event, there would be no non-obvious structural or functional relationship between the printed matter and the paper substrate == resulting in non-functional descriptive material.

    ReplyDelete
    Replies
    1. Not to mislead, there is one claim in the Beauregard patent that does not define the software in terms of means plus function. But that claim could not be read as being directed to computer instructions on paper (e.g., a source code listing). But also, not to forget, the Beauregard case was pulled from the Federal Circuit by a copyright lobbyist, with no patent experience, somehow appointed Director of the PTO. Also of interest, the online PTO records show that the patent expired due to nonpayment of maintenance fees.

      Delete
    2. "nontransitory storage media storing instructions that have recited causes when executed on processor(s), in other words, functional descriptive material."

      Ay, there's the rub. The Board expressly found that paper is a "non-transitory storage medium" and the claim did not distinguish over printed instructions on paper -- _non_-functional descriptive material. If you want to now argue that the claim cannot be so construed, well, note that appellant accepted that interpretation without protest.

      Delete
    3. "But being printed on paper is not what makes something 'printed matter'".

      Huh? Why risk brain damage by going beyond that. Once it is determined that something is mere information or instructions printed on paper, why go further? The "something" is not statutory subject matter. End of analysis.

      Delete
    4. I think I muddied the issues by noting the problems inherent in the birth of Beauregard claims. But what exactly are "the precedential holdings of Beauregard" that the Board cannot overturn? There was no decision on the merits in the Beauregard case, much less a precedential decision. In any event, Beauregard claims are becoming less important and somewhat anachronistic. Most software is now delivered by signals, which are, um, non-statutory.

      Delete
    5. I take it you agree there was no decision on the merits in Beauregard, and thus no "precedential holdings." As for the "content" of the order, it indicates little more than that the court no longer had jurisdiction.

      Delete
    6. Most folks know that Constitution Article III trumps the designation of a decision by a clerk in a publishing house, but, whatever.

      Delete
  2. The commentary here is also a bit off in its contention, without citation to any authority, that "software per se" is a form of "functional descriptive material." "Software per se" is an idea without physical embodiment. The Supreme's 2007 case of Microsoft Corp. v. AT&T Corp. contains a nice discussion about the difference between abstract software code and its embodiment in a computer-readable medium.

    ReplyDelete
    Replies
    1. "If 'data structures and computer programs' = 'software', then software, 'per se' or otherwise, constitutes functional descriptive material."

      A data structure per se is not statutory subject matter -- see Warmerdam. So, by your analogy, sofware per se is not statutory subject matter. Significantly, you left out the part about being "encoded on a computer-readable medium," which imparts the functionality. Think of software per se as a data structure and nothing more than a data structure.

      I see many words in response to the observation that Microsoft v. AT&T contains a nice discussion about the difference between abstract software code and its embodiment in a computer-readable medium. The problem is your commentary does not provide a definition of "software per se" but accuses the Board of not understanding what it is. You can define a term any way you want. But know that contending "software per se" is statutory subject matter will not get you what you want from the Office. The term of art in 2018 is similar in meaning to the "[C]omputer programs claimed as computer listings per se" in the guidelines published last millennium, from which you quote. When you write "software per se" in a paper presented to the Office, just envision the "software detached from an activating medium" discussed in Microsoft v. AT&T. And think, is this really what I want to say?

      Delete
    2. As I said, software per se is an idea. It doesn't matter how the idea may be characterized by words such as "descriptive." An idea of itself is not patentable.

      In the early days, applicants tried to claim software as an idea, such that any possible way of implementing the software was covered. You can read multiple specifications where the "software" extends to anything, including instructions printed on paper and signals, each of which are non-statutory.

      While it is true that a computer listing may be OCRed, the listing is not "machine-readable object code" as discussed in Microsoft v. AT&T. To get a bit pedantic, but as an aid to understanding where the Office is coming from, source code listing of a program on a computer-readable, non-transitory medium constitutes non-functional descriptive material (similar to music on a CD). Without further processing, such as submitting the source code to an interpreter or compiler, the source code is useful and intelligible only to the human mind. On the other hand, computer-executable object code on a computer-readable, non-transitory medium constitutes functional descriptive material

      Delete
    3. If the number 5 were a color, what color would it be and why? Yes or no?

      Delete
  3. I thought it might be pedantry to explain the difference between a source code listing (non-functional descriptive material) and executable object code (functional descriptive material). However, coincidentally, that is why the apoplexy-inducing new ground of rejection in the Musial decision is not erroneous. I looked at Dom first, and just now read Musial.

    The Board in Musial determined that the claims did not distinguish over printed matter in digital form, such as a computer listing per se residing on a "computer readable non-transitory medium." The claims call for "program instructions" that could be no more than, for example, instructions in a source code listing, or even a verbal description of "program instructions" -- i.e., information as to what a machine is supposed to do.

    Source code, usually, is encoded in alphanumeric characters that provide information that is intelligible to a human being. There is no functional difference at this stage of "software" between the "source code" and a sonnet -- both do no more than convey information. The source code on a magnetic medium such as a disk is "computer-readable" but not _executable_ by a machine, such that it could be displayed on a monitor for editing by a human being. Compare that to executable object code on a non-transitory storage medium that provides functionality to the machine, to actually implement the program instructions.

    I understand the learned tendency to say, "Ah-Hah, I can distinguish that case!" But Microsoft v. AT&T is instructive in pointing out the differences between the various things that can be called "software" and the end-product, the actual machine-readable object code that provides the functionality of the "software." With help from the parties and amici, the Supremes nailed it. Note their discussion of the facts relating to "software" prior to applying the law to the facts. The facts do not change, whether considering 35 usc 101, 102, 103, 112, or 271.

    ReplyDelete
    Replies
    1. My understanding has always been that software, whether in source code, machine code, or some intermediate like assembly language, is functional descriptive material; that non-functional descriptive material is essentially limited to mere data or instructions "that cannot exhibit any functional interrelationship with the way in which computing processes are performed"; and that the gap between nonstatutory functional descriptive material and statutory functional descriptive material is bridged when functional descriptive material is "recorded on some computer-readable medium, making it structurally and functionally interrelated to the medium". See 1996 and 2005 Guidelines. So long as "use of technology permits the function of the descriptive material to be realized", the descriptive material is not non-statutory as nonfunctional.

      I know of no holding that says source code is nonfunctional descriptive material, but if you can find something like that, it would be helpful to share it. In my opinion, it would not make sense to classify source code as nonfunctional descriptive material. The 1996 Guidelines make clear that all that is required of descriptive material to be functional is that it "impart[s] functionality when encoded on a computer-readable medium." Machines can and do read and interpret source code to execute programs just as much as they do machine code and assembly. I'll also note that many humans are capable of reading machine code and assembly; I was once good at it myself.

      Delete
  4. "I know of no holding that says source code is nonfunctional descriptive material, but if you can find something like that, it would be helpful to share it."

    Ex parte Musial.



    "Machines can and do read and interpret source code to execute programs just as much as they do machine code and assembly."

    Not really. Suppose an AI machine tells a story based on instructions taken from a book. Does that process transform the book into non-functional descriptive material? Or suppose a machine OCR's source code from paper and submits the source code to an interpreter, resulting in digital computer function. Does that process transform the printed matter into non-functional descriptive material? Answer in both cases: No.


    "The 1996 Guidelines make clear that all that is required of descriptive material to be functional is that it "impart[s] functionality when encoded on a computer-readable medium.""

    Of course. But source code does not "impart functionality" to anything when it is encoded on a disk. Further processing of the information on the disk is necessary for implementing the functions described.



    "many humans are capable of reading machine code and assembly; I was once good at it myself."

    Methinks you are confusing assembly language SOURCE code with machine executable code. Humans get lost after the first few thousand ones and zeros.

    ReplyDelete
    Replies
    1. Delete the two "non-"s in the above fourth paragraph. This negative logic gets tiring sometimes.

      Delete
    2. About 5 minutes of browsing PTAB final decisions yielded the following discussion of the difference between source code and machine-readable object code (i.e., machine code). Ex parte Heiney, Appeal 2014-001824, slip op. at 10.

      "Separately, we point out that even if Appellants' claim 1 were amended to reflect Appellants' argued claim construction (e.g., by adding "non-transitory" to claim 1, or even narrowly limiting the "storage medium" consisting of a hard drive), the claim would still encompass non-statutory subject matter under 35 U.S.C. § 101. At Appellants' Specification para. 23, Appellants act as their own lexicographer to define "executable" broadly to include "source code."

      ___'In this respect, the term "executable" includes a program file that is in a form that can be directly (e.g., machine code) or indirectly (e.g., source code that is to be compiled) performed by the processor 204.'____

      Unlike "machine code," such "source code that is to be compiled" is no more part of the processor than a circuit diagram of the wiring interconnections of the processor. Rather, such "source code" is an abstraction that even in any of its non-transitory forms does not provide a practical application until, as admitted by Appellants, it is compiled into machine code. In addition to any amendment recommended by the Examiner to cure the claims problems under § 101, we recommend deletion of the above sentence from Appellants' Specification."

      Delete
    3. The Board's position in Heiney is unsupported by the law or issued guidance. The attempted distinction between source code and machine code is sophistical, creates a form-over-substance problem, and would end patent protection for software (something neither Congress nor the Supreme Court have ever signaled an intention to do) since an infringing distributor could always "design around" a patent merely by distributing source code rather than compiled code. It would also mean that some software would never be patentable merely by virtue of the language that it is written in (i.e., an interpreted rather than a compiled language), which would be pointlessly discriminatory. It is simply wrong to say that source code does not "impart functionality" to anything when it is encoded on a disk. As an example, no justifiable distinction can be made between compiled and uncompiled PHP or Python code, which in either case instruct a computer just the same when executed.

      Delete
    4. Now you want to talk about the law of infringement? Because 101 has been resolved?

      Back to the subject of 101, not granting patents for some "software" would be "discriminatory" ?!!? I do not follow. By Constitution? By statute? A regulation? Really, really hurt feelings? Please be specific.

      Delete
    5. Back to 101, nobody but you has suggested that choice of programming language or whether something has been "compiled" might be thought to force the legal conclusion of statutory vs. non-statutory subject matter. The proper inquiry is more along the lines of, is this a tangible tool such as a screwdriver? Statutory subject matter. Is this a set of instructions about how to make the screwdriver? Non-statutory subject matter.

      Now would be a good time to provide your definition of "software per se." Please be specific.

      Delete
  5. I don't perceive in your comments a response as to why software realized as PHP or Python code, among other languages such as JavaScript, that run just as well from source code as from compiled code, should in your view any less "impart functionality when encoded on a computer-readable medium," or otherwise why a CRM claim directed to such should be any less patentable than a CRM claim directed to a compiled software product. One of your view may, I suppose, argue that PHP, Python, or JavaScript source code does not actually have the ability to tell a processor what to do until it is interpreted and brought into the binary realm. But it is also true that the ones and zeroes of machine code do not inherently tell a processor what to do unless the processor has the correct circuitry to translate the instructions therein into actions of the processor's machinery, operations on data to produce outputs. And, consider the hypothetical case where the interpreter portions of the process that translate source code into machine code, normally themselves implemented as software, are implemented as hardware, such that the processor reads source code just as much as it reads machine code. In this case, is a CRM claim that can broadly be construed to encompass source code encoded on one or more non-transitory computer-readable media still non-statutory? Why? It is really a sophistical distinction. The only meaningful distinction is not, as you suggest, between source and compiled code, but between non-instruction data and "data" that includes instructions for manipulating data.

    As to the screwdriver hypothetical, while a set of instructions on how to make a screwdriver are not patentable under the printed matter doctrine, a set of instructions written as a "data structure" that drives a screwdriver-making machine, when encoded on one or more media readable by that machine, "defines structural and functional interrelationships between the data structure [i.e., the screwdriver-making instructions] and the medi[a] which permit the data structure's functionality to be realized, and is thus statutory." 1996 Guidelines.

    You can argue with the 1996 Guidelines. The Federal Circuit can argue with them. The Supreme Court can argue with them. But, I submit, the Board cannot, at least not absent overriding guidance from the courts, which we do not have.

    ReplyDelete
    Replies
    1. It's unclear why you think the PTAB is constrained to follow your interpretation of the statutory subject matter guidelines. Both the 1996 and 2005 guidelines emphasized that the guidelines are just that -- guidelines -- and do not have the force and effect of law. In fact, the guidelines specifically state that "any failure by Office personnel to follow the Guidelines is neither appealable nor petitionable."

      In re screwdrivers, problem is, Lowry does not stand for the broad proposition that calling something a "data structure" on a magnetic medium results in statutory subject matter, or patentable weight given to the content of the "data structure." Lowry claimed a very specific data structure, the kind of which we have never seen, and perhaps never will, in the real world. The "data structure" certainly was not a computer program. Why should it matter whether a computer listing is visually encoded on paper, or magnetically encoded on a magnetic medium? What magic lies in the arrangement of magnetic domains?

      "But it is also true that the ones and zeroes of machine code do not inherently tell a processor what to do unless the processor has the correct circuitry to translate the instructions therein into actions of the processor's machinery, operations on data to produce outputs."

      Yes. I think you understand more than you let on. If someone wants to provide ones and zeros to a processor that cannot be acted upon by the processor, their invention fails under the utility prong of Section 101.

      "consider the hypothetical case where the interpreter portions of the process that translate source code into machine code, normally themselves implemented as software, are implemented as hardware, such that the processor reads source code just as much as it reads machine code."

      I do not wish to consider any "hypothetical" cases. The real world provides enough of a challenge in this area of the law. You cannot provide a real-world definition of "software per se" that fits your schema.

      Delete
  6. "If someone wants to provide ones and zeros to a processor that cannot be acted upon by the processor, their invention fails under the utility prong of Section 101."

    CRM claims do not encompass a processor, they at best only need inferentially mention a processor. They infringe as a product sitting on a shelf independent of any processor. Whether an invention is statutory or not shouldn't depend on whether a processor uses hardware or software to reduce source code to machine code and thereby execute it, but that seems to be your interpretation.

    Software per se is functional descriptive material in the abstract, i.e., not encoded on a computer-readable medium, but disembodied or divorced from functional technological apparatus. I think that fits the established schema, which has been the status quo for decades, pretty well. The counter-proposals offered in this thread would make software unpatentable. As an example, it's not clear what the Board thinks the applicant did wrong in Musial, or what amendments would fix their claims to overcome the new grounds of rejection. The PTO has merrily chugged along issuing CRM claims for decades with full understanding of software per se and printed matter doctrines, so what's happening now to disturb that?

    ReplyDelete
    Replies
    1. "Software per se is functional descriptive material in the abstract. . . ." Is there a typo there? You are defining a term by oxymoron.

      There are many ways of limiting "software" to statutory subject matter. Why not go back to your gold standard of Beauregard? The non-mpf claim in Beauregard set forth "A program storage device readable by a machine, tangibly embodying a program of instructions executable by the machine to perform method steps for ... the method steps comprising. . . ." Note the instructions are "executable by the machine" as opposed to merely "readable" by the machine -- i.e., the claim is limited to machine code. In light of later developments, Beauregard would amend to a "non-transitory" program storage device.

      Delete
    2. "In light of later developments" ... you mean in light of later developments in which the Board establishes that they don't understand the difference between a signal and a medium in which a signal propagates or is stored.

      Delete
  7. "'executable by the machine' as opposed to merely 'readable' by the machine -- i.e., the claim is limited to machine code"

    Again, your interpolation with no basis in law or guidelines, so we end where we began. But thanks again.

    ReplyDelete
    Replies
    1. Interpretation? Yes, that is my interpretation. Even if you want to loosely call interpreted-language source code "executable," the claim simply, simply, simply does not extend to source code that requires compilation to yield executable files.

      Delete
  8. So can we simply agree that the PTO makes stuff up as it goes along, and then engages in chicken-or-egg sophistry when you try to nail them down?

    ReplyDelete
  9. Consummate case of hypothesis, compassion and expression. Here I took in another approach to theorize through writer's written work. It enabled me to feel another approach to estimate your considerations and express them in a simple and clear way. super download

    ReplyDelete
  10. The information which you have provided is very good. It is very useful who is looking for salesforce Online Training Bangalore

    ReplyDelete
  11. The prohibition is on software per se. Notice the "per se" part. It has a specific meaning. A "computer readable non-transitory medium having computer readable program code stored thereon" includes both the software per se part (i.e., the computer readable program code") and the something else (i.e., the computer readable non-transitory medium). Consequently, software per se is NOT being claimed.

    The Board blatantly misrepresents this point by asserting "claims 14, 21, and 22 are directed to a computer program product comprising program code, i.e., software per se, and are, accordingly, not patent-eligible." The Board wrote that the specification does not exclude a computer readable non-transitory medium from being software per se. However, that is NOT the standard for claim construction. There is no requirement that a specification must explicitly disclaim an (unreasonable) interpretation. The broadest reasonable interpretation of a non-transitory medium is a device or manufacture. It is not "software per se." The Board presents no evidence to support their unreasonable claim construction.

    Additionally, the printed matter doctrine applies to "novel arrangements of printed lines or characters, useful and intelligible only to the human mind." Program code is not "useful and intelligible only to the human mind."

    This is just an APJ trying to pull a fast one.

    ReplyDelete
    Replies
    1. The applicants let this case go abandoned, but have petitioned for revival on grounds of unintentional abandonment. Did the attorney only read the file wrapper headline ("Examiner Reversed") and not read the opinion to note the new grounds of rejection? The attorney redrafted the claims to make them method claims rather than CRM claims, and hoped to get around the new grounds of rejection that way. I'm disappointed that this decision was allowed to stand, but so long as it is not labeled "informative" or "precedential", the damage it does will be isolated to this one case.

      Delete
    2. I saw that as well. Something like Mewherter is where you have to watch out. It was originally issued as non-precedential decision. However, there were 5 APJs on the panel, which should have clued the responsible attorney as to something being up. Mewherter should have been designated a new grounds of rejection, but the responsible attorney didn't catch that either since the Board present a ton of analysis not presented by the Examiner. Anyway, after the attorney amended the claims, the Board then designated Mewherter as precedential. In this case, however, there are no 5 APJs on the panel. Also, Allen MacDonald isn't on the panel, which is another clue that the Board is trying to pull a fast one.

      Delete