Every practitioner who utilizes method claims should be cognizant of the PTAB’s precedential decision: in re Schulhauser. We have discussed the case previous (here and here), and review yet another example today illustrating where Schulhauser’s rubber hits the road.

The case is Appeal 2020-003159 Application 14/108,128 in an application to Airbnb. The invention relates to managing third party web page assets. claim 1 on appeal is listed below:

A computer implemented method comprising:
storing, by a first party system, a plurality of third party web page assets received from one or more third parties located at one or more third party web addresses, the plurality of third party web page assets configured to provide functionality to a web page operated by the first party system distinct from the one or more third parties;
periodically sending, by a first party system, requests for the plurality of third party web page assets to the one or more third parties located at the one or more third party web addresses, the requests for the plurality of third party web page assets sent at predetermined intervals of time;
receiving, by the first party system, one or more of the requested plurality of third party web page assets;
responsive to receiving one or more of the requested plurality of third party web page assets, determining, by the first party system, a hash value for each of the received third party
web page assets;
determining, by the first party system, whether one or more of the received third party assets differs from a stored version of that third party web page asset by comparing the determined hash value of an asset to a hash value of a sorted version of the asset; and responsive to determining that one or more of the received third party assets differ from a stored version of that third party web page asset:
[L1] determining, relative to a last request of theperiodically sent requests, whether a requested third party webpage asset of the last request is not received after a first threshold amount of time, and [L2] responsive to determining that the requested third party web page asset of the last request is not received after the first threshold amount of time: [L3] merging the received third party web page assets of the last request and a stored version of the third party web page asset that was not received into a merge file, and [L4] storing, at a web address other than the third parties web addresses and other than a web address of the first party system, the second merge file, the web addressaccessible to clients requesting the web page operated bythe first party system.

The examiner’s final rejection (before Airbnb’s appeal brief) was relatively weak and failed the basic “mapping rule” of 37 CFR 1.104(c)(2). Ainbnb pointed out the lack of disclosure in the cited art (Seshadri and Joel) regarding the “merging . . . a merge file” and “the second merge file” limitations. In the Answer, the examiner, recognizing the problem, switched tack and relied on Schulhauser. The PTAB agreed with Ainbnb, but nevertheless let the examiner rely on Schulhauser:

…, in reviewing the portions of Seshadri and Joel cited by the Examiner, we find the Examiner has not fully developed the record to clearly show how the argued claim 1 “merging . . . a merge file” and “the second merge file” limitations L3 and L4, respectively are being read on the corresponding features found in Seshadri and/or Joel.

Nevertheless, we agree with the Examiner (Ans. 7–8) that the disputed limitations L3 and L4 of claim 1 are conditional limitations that may never be reached within the scope of method claim 1 in the alternative case in which it is determined that relative to a last request of the periodically sent requests, a requested third party web page asset of the last request IS received BEFORE a first threshold amount of time. See Claim 1, cf. with “determining” limitation L1 (“is not received after a first threshold amount of time”).

And because under Schulhauser the Examiner need not present evidence of the obviousness of the disputed conditional method steps, the rejection was affirmed.

Ainbnb even recognized the Answer’s new reliance on Schulhauser was a new ground, but one cannot merely complain about that in the Reply Brief. Either one must find a way to use the new ground to illustrate errors in the rejection, or one must petition (which Airbnb did not do). See our previous post (here).

This case illustrates the interplay of the “mapping rule”, Schulhauser, and new grounds of rejection in an Answer - and all three spelled trouble for Airbnb. Be wary if you are headed to appeal with method claims in which missing claim elements could be categorized as conditional. However, Airbnb did have a system claim (that essentially re-cast the method claim as instructions stored in computer-readable storage medium). The Board’s analysis of those claims was 180 degrees:

In contrast to our discussion above, we particularly note that independent claims 16 and 21 are not “method” claims that fall under Schulhauser’s controlling precedent. But each of independent claims 16 and 21 recite limitations L3 and L4 of claim 1 using similar language. Because Schulhauser is inapplicable to independent claims 16 and 21, and because we have found supra that the Examiner has not fully developed the record to show how the argued “merging . . . a merge file” and “second merge file” limitations L3 and L4 (of claim 1, respectively) are being read on the corresponding features found in Seshadri and/or Joel, we are constrained on this record to reverse the Examiner’s rejection A of independent claims 16 and 21, and the associated rejections of all claims that
depend thereon.

This case clearly shows one solution to a Schulhauser problem as well as the advantage of using both method claims and system claims to keep options open all the way up to the Reply Brief.