Friday, January 15, 2016

PTAB agrees with Applicant that claimed feature "would make no sense in the context" of the reference


Takeaway: The application on appeal used biometrics from multiple users to measure software application ease-of-use. The Examiner asserted that "averaging quantitative metrics across the plurality of users" was taught by the primary reference, and the Applicant argued this feature was not disclosed. The Applicant also argued that averaging would run counter to the main purpose of the primary reference. The Board reversed. "Appellants contend the claimed averaging across a plurality of users would make no sense in the context of Franz where cursor tracking responsive to keycap forces is customized for each user's preference. Id. ( see, e.g., Franz col. 2, 11. 22-26). We agree." (Ex parte Verma, PTAB 2015.)

Details:
Ex parte Verma
Appeal 2012-007587; Appl. No. 12/057,950; Tech. Center 2400
Decided:  February 3, 2015

The application on appeal used biometrics from multiple users to measure ease of use for a particular software application. "By correlating the application that a user is currently engaged in with the biometric measurements obtained from the devices, software ease of use can be done while [filtering out interactions with other concurrent applications]." "The information obtained from different users needs to be compiled into a single quantitative measure for ease of use index for the software, which can then be used as a user-independent index for its ease-of-use."

The claims on appeal recited:
     1. A computer implemented method for quantitative determination of software ease of use, comprising the steps of:
     using sensors to collect biometric data from each of a plurality of users engaged in using a software application operating on a computer  or computer network;
     monitoring and recording changes in the biometric data which occur while the software application is being used by each of the plurality  of users;
     combining recorded changes in the biometric data for each user into quantitative metrics;
     averaging quantitative metrics across the plurality of users;
     compiling the averaged quantitative metrics into a single quantitative measure for an ease of use index for the software application; and
     providing an output as a user-independent index for ease­ of-use of the software application.
(Emphasis added.)
The Examiner rejected as obvious over Franz in view of Kotzin. Franz was directed to keyboard cursor control, where cursor responsiveness could be adjusted for each user. Kotzin was directed to selecting from among multiple biometric sensors.

The Examiner read the claimed biometric sensors on Franz's keycap force sensors. The Examiner read the generating and averaging metrics steps on Franz's teaching that "several different parameters maybe stored, one for each of a plurality of users where the corresponding settings would be invoked depending upon who logged into the system." For the remaining single quantitative measure and user-independent index limitations, the Examiner relied on Kotzin's abstract, which stated: "Biometric samples are collected from multiple users [to enable a feature] when the sample matches a known sample corresponding to the user from a list of [sensors] prioritized according to accuracy and ease of use."

The Applicant appealed and made a variety of arguments in the Appeal Brief. One such argument related to the "averaging across users" limitation. The Applicant first argued that the reference simply did not disclose what the Examiner asserted, and then backed this up with a one sentence explanation of why the Examiner's interpretation didn't make sense:
The stored parameter settings are not combined, as specifically required by the claim. [Combining or averaging] would eliminate the personalization of the game controller response settings (the focus of Franz et al.). 
Later on in the response, the Applicant restated this argument about Franz, and then explained why averaging across users didn't make sense in Kotzin either.
Neither Franz et al. nor Kotzin average measures from different users. In Franz et al., this would make no sense whatsoever, because the purpose is to identify specific individuals and correlate their desired performance criteria (one wants to have the cursor tracking device perform in the desired manner, not in a manner averaged among several users). In Kotzin, this would also not make any sense. In Kotzin, the effort is to identify specific users so that only specific users can have access to a feature or service provided via a wireless communication device.
The Applicant also included arguments that neither reference taught the limitation "monitoring ... while the software application is being used," and that Kotzin was non-analogous art.

The Examiner's Answer included some rebuttal of each Appeal Brief argument. The Examiner explained why Kotzin was analogous by first addressing claim construction for "biometric data." The Examiner discussed the "monitoring" limitation by referring to Franz's keyboard microcontroller software. For the "averaging across users" limitation, the Examiner newly relied on a mention of averages in Franz. ("At initialization time, and periodically thereafter, the keyboard needs to read the individual sensor values and individually average them.")

The Applicant filed a Reply Brief. It mostly focused on the Examiner's claim construction position for "biometric data."

The Board reversed the § 103 rejection on the grounds that Franz did not teach, or even suggest, averaging the metrics across a plurality of users:
Appellants contend the claimed averaging across a plurality of users would make no sense in the context of Franz where cursor tracking responsive to keycap forces is customized for each user's preference. Id. ( see, e.g., Franz col. 2, 11. 22-26). We agree. Appellants further contend, in Franz, "one wants to have the cursor tracking device perform in the desired manner [(for each user)], not in a manner averaged among several users." Id. We agree.
Commenting on Franz's brief mention of "average," the Board found that the calibration procedure described in this passage was not performed across users.

My two cents: For the vast majority of Applicants, a "does not teach" argument amounts to quoting the reference, quoting the claim language, and then asserting that A is not B. And sometimes, this alone can be persuasive. But often a more persuasive argument can be made with judicious (and careful) use of paraphrasing, summarizing, and/or providing context. I  find the argument made by the Applicant in Verma to be more persuasive because it did just this.

The typical do-nothing-but-quote argument looks like:
Franz teaches "several different parameters maybe stored, one for each of a plurality of users where the corresponding settings would be invoked depending upon who logged into the system." However, this is not the same as "averaging quantitative metrics across the plurality of users" as recited in the claim.
For this argument to be persuasive, the Examiner must map the words, phrases, and concepts expressed in the reference to the words, phrase, and concepts in the claim. But claims are almost always hard to parse, and references too can be obtuse.

Paraphrase makes it easier to see the contrast between the reference teachings and the claims:
Franz stores parameters for each user, and then invokes corresponding per-user settings. In contrast, the clam recites averaging across multiple users
Here the Applicant went one step further and tied it all together, by providing a bit of context for the comparison:

[Combining or averaging] would eliminate the personalization of the game controller response settings (the focus of Franz et al.). ... In Franz et al., averaging measures from different users would make no sense whatsoever, because the purpose is to identify specific individuals and correlate their desired performance criteria (one wants to have the cursor tracking device perform in the desired manner, not in a manner averaged among several users).
I find this version of the argument even more persuasive. Notably, this explanation of context was preceded by an argument that stuck closely to the claim language. I think that's important. Because the "purpose" of the reference doesn't trump a reference that really does disclose the claim element. Instead, the purpose must be used to provide further explanation of how or why the relied-upon teachings do not disclose to the claim element.

I expect a lot of practitioners to disagree with me. And I can't stress enough that paraphrasing and summarizing must be done thoughtfully and carefully. Still, when done well, this form of argument can be very persuasive. 

I'll also point out that I am not advocating for arguing outside the claims, i.e., importing limitations into the claims. Here, the plain and ordinary meaning of the claim, read as a whole, actually does boil down to "averaging across multiple users." That's much different than arguing that "user" has a narrower meaning by importing statements in the Applicant's spec.

5 comments:

  1. That's interesting. I have not read the decision, but from the post it seems that in fact, averaging over the users by the main reference would render the reference useless for its intended use. This language would be commensurate with well-established case-law language.
    Wouldn't it be preferable to put the argument this way?

    ReplyDelete
    Replies
    1. Good point. I do agree that the Applicant's argument could have been framed as unsuitable for intended use. And if the argument is indeed a good fit for a recognized type of argument, might be best to frame it that way. I opined a bit on this topic -- framing arguments --- in my last post.

      Delete
  2. yes, MPEP 2143 is your friend, and it is not cited enough when the facts fit

    ReplyDelete
    Replies
    1. rather, the case lase discussed under this section is underutilized

      Delete
  3. Thanks Karen for the recent updates. love your blog and got worried about the relatively long silence in the second half of 2015.

    ReplyDelete