Ex Parte Desai

Board of Patent Appeals and Interferences

Jan 29, 2010

09986967 (B.P.A.I. Jan. 29, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
____________

Ex parte ARUN GAGHAVENDRA DESAI
____________

Appeal 2009-005558
Application 09/986,967
Technology Center 2400
____________

Decided: January 29, 2010
____________

Before MAHSHID D. SAADAT, CARLA M. KRIVAK, and KARL D.
EASTHOM, Administrative Patent Judges.

EASTHOM, Administrative Patent Judge.

DECISION ON APPEAL

STATEMENT OF THE CASE
Appellant appeals1 under 35 U.S.C. § 134 from the Examiner’s final
rejection of claims 1-4, 6, 8, 9, 11, 13-16, 18, 20-23, 25, 27, 28, 30, 32-35,
and 37. The Examiner objected to claims 5, 7, 10, 12, 17, 19, 24, 26, 29, 31,

1 Reference is to Appellant’s Brief (filed Sept. 10, 2007) [hereinafter “App.
Br.”] and Reply Brief (filed Feb. 13, 2008) [hereinafter “Reply Br.”], and the
Examiner’s Answer (mailed Dec. 13, 2007) [hereinafter “Ans.”] and
Advisory Action (mailed April 3, 2007) [hereinafter “Ad. Act.”].
Appeal 2009-005558
Application 09/986,967

2
36, and 38 as depending from rejected claims but reciting allowable subject
matter. (See App. Br. 1-2.) No other claims are pending. We have
jurisdiction under 35 U.S.C. § 6(b).
We affirm-in-part.
Appellant’s invention provides an HTTP response including a first
object content and second object content identifier to a device, such as a
proxy agent 22 in device 16a, thereby enabling the device to prefetch the
second content object from a remote web server 12b.2 Prior to sending the
HTTP response to the device, a predictive caching operation in a remote
server identifies the second content object as relevant to the first content
object. The invention allows the device to prefetch and cache the second
content object prior to its having been previously downloaded to the device.
Prior art schemes typically cached only objects previously requested and
downloaded. (Abstract: Spec. 1:10 to 2:3, 10:5-28; Fig. 1.)
Exemplary claim 1 follows:
1. A method of providing content to a device according
to Hypertext Transport Protocol (HTTP), the method comprising:
receiving an HTTP request for a first content object;
identifying a content operation identifier that identifies a
corresponding second content object determined as relevant to the first
content object by a predictive caching operation, the content operation
identifier including a directive for prefetching the second content object as a
content operation distinct from presentation of the first content object by the
device; and
sending to the device an HTTP response to the HTTP request, the
HTTP response including the first content object and the content operation

2 Beyda employs the hyphenated version (i.e., “pre-fetch”) while Appellants
do not, and the Examiner employs both versions. The non-hyphenated
version (i.e., “prefetch”) is employed throughout this opinion unless the
other version is being quoted.
Appeal 2009-005558
Application 09/986,967

3
identifier, enabling the device to perform the prefetching of the second
content object based on receipt of the content operation identifier and
distinct from the presentation of the first content object.

The Examiner relies on the following prior art references:
Schloss US 6, 249,844 B1 June 19, 2001
Beyda US 2003/0061451 Mar. 27, 2003

The Examiner rejected:
Claims 1, 2, 13, 14, 20, 21, 32, and 33 under 35 U.S.C. § 102(e) based
on Beyda; and
Claims 3, 4, 6, 8, 9, 11, 15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and
37 under 35 U.S.C. 103(a) based on Beyda and Schloss.

ISSUES
Appellant contests (App. Br. 10-16) the Examiner’s finding that
Beyda satisfies independent claim 1 and similar limitations in independent
claims 13, 20, and 32. Appellant’s contention raises the following issue:
Did Appellant demonstrate that the Examiner erred in finding that Beyda
discloses “sending to the device an HTTP response to the HTTP request, the
HTTP response including the first content object and the content operation
identifier, enabling the device to perform the prefetching of the second
content object based on receipt of the content operation identifier and
distinct from the presentation of the first content object,” as set forth in
claim 1?
1) Appellant also contests (App. Br. 16-19) the Examiner’s finding
that Beyda and Schloss teach the limitations of the dependent claims, raising
the following issues: Did Appellant demonstrate that the Examiner erred in
Appeal 2009-005558
Application 09/986,967

4
finding that Beyda and Schloss collectively teach an HTTP response which
includes a content operation tag that includes a content operation identifier
including a directive tag specifying the corresponding content operation to
be performed by the device and an object identifier that specifies a location
of the second content object, as required by dependent claims 3, 4, 8, 9, 15,
16, 22, 23, 27, 28, 34, and 35;
2) inserting into the HTTP response at least one extensible HTTP
header that specifies the content operation identifier including a directive tag
specifying the content operation and the object identifier, as set forth in
claims 6, 11, 25, and 30; and
3) a header as recited in claims 18 and 37?
FINDINGS OF FACT (FF)
Beyda
1. Beyda discloses a “method for [a] predictive caching operation
[which] determines a time-based pattern of a high-access period for a web
page, and pre-fetches the web page into a cache before the high access
period begins. A table is generated where the table comprises a URL
[(Universal Resource Locator)], a time of last access and a time stamp of the
pre-fetched web page.” (¶ 0012.) Beyda’s cache system encompasses
HTML pages, images and files, and HTTP protocols. (¶¶ 0002, 0005, 0009.)
2. Beyda’s system pre-fetches or fetches web pages and fills a local
cache based on prior and current client requests for the web page. Each web
page has a unique URL, and also different types of files, such as graphic,
audio, video, and text files, referred to as objects, or elements, with each
having a unique URL. For example, the web page www.cnn.com has three
graphic files and an audio file with the following unique URLs:
Appeal 2009-005558
Application 09/986,967

5
www.cnn.com/graphic.jpg1, www.cnn.com/graphic.jpg2;
www.cnn.com/graphic.jpg1[sic 3], and www.cnn.com/audio. (¶¶ 0010,
0017.)
3. When a client sends a new request to a local server 14 (which
includes a proxy server 16 and cache) for a particular web page, if the
requested URL is not found in the local server cache (previously stored there
via a previous client request from that client or another client), the local
server directs the new request to the remote server 18. The remote server
then sends a response back to the client 10 via the local server, while the
local server updates its cache with the response.
The response includes the requested web page (including all its
associated elements and URLs), the time of last update for the page, and the
time stamp corresponding to the client’s request. The local server/cache
stores the URLs and both time data types in a table as depicted in Figure 2.
(The remote server 18 updates the web page URL time stamp if any part of
the page, including any of its graphic or audio files objects, change.)
On the other hand, if the requested web page URL is found in the
local server, the local server begins downloading the shell of the requested
web page (listing the various elements/objects with different URLs and
timestamps of creation) from the remote server 18. The shell of the page
may have a new URL (e.g., for a new audio file) not listed in the local cache.
If so, the local server assumes the web page has changed and downloads the
new URL (and its element) from the remote server. Similarly, if the time
stamps of the different URLs associated with a web page do not match the
local cache time stamps, the local sever downloads the more recent URL and
its element from the remote server and sends that version to the client. On
Appeal 2009-005558
Application 09/986,967

6
the other hand, if the time stamps of the shell match the time in the local
cache, the local server sends the cached copies of the URL elements to the
client. Beyda refers to this downloading process as “element-by-element
downloading” (¶ 0028). (¶¶ 0010, 0016-0020; Fig. 1.)
4. Beyda’s local server 14 also prefetches the web pages described
above from a remote server 18 that are predicted to be in high demand
during a certain time of the week. The local server 14 predicts this demand
by recording the hit rate of every web page previously requested by clients.
Prefetching may occur, for example, the hour before the expected high
demand, to ensure the most recent web pages, with their associated URLs
and objects, are locally cached. The prefetched pages, including all web
content and associated URLs, are then accessed in the same fashion as
described above (FF 3) by requesting clients. In other words, URLs, the
web shell, and time stamps are sent from the remote server and compared at
the local server on an element-by-element basis. (¶¶ 0021-28; see also FF
1.)
5. In addition to this element-by-element predictive prefetching,
Beyda also discloses that the predictive prefetching operation can be
performed as occurred in the prior art, by downloading the entire web page
and its contents (i.e., downloading all the text, audio, video, and graphic files
associated with the page at the same time). (¶¶ 0010, 0028.)
Appellant’s Specification
6. Appellant describes “HTML directive tags 40 as specified content
operations” which include “HTML tag information 42 and 44.” (Spec.
10:20-23.) Tag 42a includes a command to prefetch, while tag information
44 includes uniform resource indicators (URIs). (Spec. 7:16-20; Fig. 2A.)
Appeal 2009-005558
Application 09/986,967

7
7. Appellants describe a proxy agent 22 as “check[ing] for the
existence of the content object in its cache 24 to determine if the content
object has already been fetched or prefetched.” (Spec. 10:13-15.)
PRINCIPLES OF LAW
“[T]he examiner bears the initial burden, on review of the prior art or
on any other ground, of presenting a prima facie case of unpatentability.” In
re Oetiker, 977 F.2d 1443, 1445 (Fed. Cir. 1992). Appellant carries the
burden on appeal to show reversible error by the Examiner in maintaining
the rejection. See In re Kahn, 441 F.3d 977, 985-86 (Fed. Cir. 2006) (“On
appeal to the Board, an applicant can overcome a rejection by showing
insufficient evidence of prima facie obviousness or by rebutting the prima
facie case with evidence of secondary indicia of nonobviousness.” (Citation
omitted).)
Under § 102, anticipation is established when a single prior art
reference discloses expressly or under the principles of inherency each and
every limitation of the claimed invention. In re Paulsen, 30 F.3d 1475,
1478-79 (Fed. Cir. 1994) (citation omitted).
Under § 103, “there must be some articulated reasoning with some
rational underpinning to support the legal conclusion of obviousness.”
Kahn, 441 F.3d at 988. “On appeal to the Board, an applicant can overcome
a rejection by showing insufficient evidence of prima facie obviousness . . .
.” Id. at 985-986 (quoting In re Rouffet, 149 F.3d 1350, 1355 (Fed. Cir.
1998).)

Appeal 2009-005558
Application 09/986,967

8
ANALYSIS
Anticipation Rejection Based On Beyda
Claims 1, 2, 13, 14, 20, 21, 32, and 33
The sending clause of claim 1 requires “sending to the device an
HTTP response to the HTTP request, the HTTP response including the first
content object and the content operation identifier, enabling the device to
perform the prefecthing of the second content object based on receipt of the
content operation identifier and distinct form the presentation of the first
content object” (emphasis added).
With respect to this sending clause, Appellant appears to direct
attention to Beyda’s alleged lack of a teaching of a specific device which
receives the HTTP response, summarizing as follows:
Hence, although Beyda discloses a local server 14 that
performs its own predictive prefetching based on reviewing its
cache (illustrated in Figure 2), Beyda provides no disclosure or
suggestion that the predictive prefetching is added within an
HTTP response, enabling another device receiving the HTTP
response to perform the prefetching of the second content
object in response to receipt of the content operation identifier
specifying the directive for prefetching.

(App. Br. 15.)

The Examiner responded as follows:
Beyda discloses sending to the device an HTTP response . . .
from remote server 18. . . including both the first content object
[= sub-entry URLs such as either object 36, 38, 40, or 42] and
the content operation identifier [= URL, paragraph 0017] that
includes a directive for prefetching the second content object [=
predictively pre-fetch web pages and their corresponding
elements, e.g. URL . . .] as a content operation distinct from
Appeal 2009-005558
Application 09/986,967

9
presentation of the first content object by the device [=
predictive caching operation can operate independently . . .].

(Ans. 9 (emphasis added).)
Therefore, as the Examiner found that Beyda’s remote server 18 sends
the HTTP response to the device (FF 1-3), it follows that the local server 14
constitutes the device of the claim. Beyda’s local server performs
prefetching, as Appellant’s above-quoted argument notes. (Accord FF 4-5.)
In other words, one of the URLs (of several in a web page) sent by
Beyda’s remote server 18 in response to a prior request for a web page from
the client 10 and local server 14 (FF 2, 3) constitutes a content operation
identifier in the sending clause of claim 1. One of these URLs also satisfies
the same identifier recited in the identifying clause of claim 1: i.e.,
“identifying a content operation identifier that identifies a second content
object determined as relevant to the first object by a predictive caching
operation, the content operation identifier including a directive for
prefetching the second content object as a content object distinct from
presentation of the first content object by the device,” as the Examiner
found. (Ans. 8-10.)
That is, the Examiner found that one of the secondary URLs (from the
remote server 18) constitutes “a content operation identifier . . . [which]
includes a directive for prefetching.” (Ans. 8, 10; Ad. Act.)3 The record

3 The Examiner stated: “In page 7, line 19, of the specification, the
applicant discloses a directive tag 42a specifying a prefetch operation.
However, the claims specify that a directive for prefetching which is nothing
more than pre-ftetching [sic] portion of a single cache e.g. its URL . . . .”
Footnote continued on the next page.
Appeal 2009-005558
Application 09/986,967

10
supports this finding. Beyda’s local server 14 employs all the URLs (in the
web page of the HTTP response sent from the remote server) to determine
which URLs and their objects to prefetch.
While Beyda’s local server uses additional information to determine
which URLs to prefetch, claim 1 does not preclude this, contrary to implied
arguments otherwise made by Appellant. (Reply Br. 10 (referring to internal
operations of the local server 14).) These URLs, sent in the HTTP response
from the remote server, are necessary pre-requisites that “direct” the local
server as to which URLs and objects to later prefetch (based on the
additional requirement of an anticipated high demand according to a pattern
of high demand previous HTTP requests). Also, a particular web page URL,
or an element URL (for a file in that web page), having been previously
requested more than a certain threshold number of times as compared to
other requested URLs, triggers that particular URL as a directive to prefetch,
according to Beyda’s prefetching scheme. (FF 4-5.) As such, each URL, or
only one URL, of a respective web page, reasonably constitutes a directive
according to claim 1.4
While Appellant repeats the Examiner’s finding quoted supra in note
3, Appellant’s response fails to squarely address whether or not a URL
constitutes a directive. For example, Appellant responds as follows: “the
rejection fails to present any interpretation . . . of the claimed ‘directive for
prefetching’: the broadest reasonable interpretation must be (1) consistent

(Ad. Act. 2 (emphasis added).) The Examiner twice repeated this finding.
(Ans. 8, 10.)
4 Beyda’s local server 14 can prefetch either the whole page and all its
elements or each element, element-by-element. (FF 5.)
Appeal 2009-005558
Application 09/986,967

11
with the specification, and (2) consistent with the interpretation that those
skilled in the art would reach.” (App. Br. 15-16.) This response does not
explain why a URL, which the Examiner thrice relied upon (supra note 3) as
part of Appellant’s disclosed directive, fails to suffice as the claimed
directive for prefetching. The response does not explain how the finding is
either inconsistent with the Specification or known interpretations.
Appellant’s Specification supports the Examiner’s interpretation under
which a “directive” (40) merely includes the URL information (44). (FF 6.)
Appellant also responds to the URL directive issue by stating that
“[t]he specification explicitly describes prefetching as fetching new content
without relying on a client request to provide content acceleration.” (App.
Br. 16.) Again, this response does not address whether Beyda’s URL
constitutes the directive recited in claim 1. While it does address
prefetching, Appellant provides no explicit definition (or description) which
would replace the ordinary meaning of that term as evidenced by
Appellant’s (FF 7) and Beyda’s (FF 2-4) use of it. That is, Beyda (FF 2-4)
and Appellants’ Specification (FF 7) clearly demonstrate that prefetching
does not preclude a prior request. Rather, prefetching merely involves
caching (i.e., saving) prior requests in anticipation of further requests. (FF 2,
4, 7.) As such, Appellant’s related remark (Reply. Br. 6) that Beyda
performs a “post fetch” is also unavailing.
Therefore, in response to an HTTP request from a client 10 or the
local server 14, Beyda’s remote server 18 sends a web page, and thereby
identifies a corresponding second content object including a directive for
prefetching (e.g., identifies the object audio file, and its URL directive for
prefetching - www.cnn.com/audio), which is determined to be relevant to the
Appeal 2009-005558
Application 09/986,967

12
first content object (e.g., either the web page associated with the URL
www.cnn.com, or another graphic file in the web page). (FF 2-3.)
Therefore, Beyda satisfies the receiving and identifying steps of claim 1.
After the above two steps, Beyda’s remote server 18 sends, to the
local server 14, an HTTP response including the first content object and the
content operation identifier, which enables the local server device “to
perform the prefetching of the second content object based on receipt of the
content operation identifier and distinct from the presentation of the first
content object,” thereby also satisfying the “sending” step of claim 1. (FF 2-
5.)
Appellant also argues Examiner error with respect to “the claimed
feature of a single HTTP response including both the first content object (for
presentation of the first content object) and the directive for prefetching the
second content object distinct from the presentation of the first content
object.” (App. Br. 16.) Notwithstanding these various underlined portions,
this argument and related arguments in the Appeal Brief and Reply Brief
(see e.g., Reply Br. 10) do not explain in a clear fashion why Beyda does not
disclose any of the elements mentioned.
Moreover, and by way of example, Appellant’s Brief does not specify
any clear support for the “distinct from presentation” and “distinct from the
presentation” elements, which appear respectively in the identifying and
sending steps of claim 1, as indicated supra. (See App. Br. 3: 1-2 (no Spec.
cite); 3:26-27 (citing Spec. 8:7-9).)5 On the other hand, Appellant refers to

5 The cited passage at page 8 of the Specification refers to preferably
“provid[ing] the content operation identifier distinct from the content itself
by inserting the content operation identifiers into the HTTP header.” (Spec.
Footnote continued on the next page.
Appeal 2009-005558
Application 09/986,967

13
“the device” in claim 1 as supported by “16a or 16b of Fig. 1,” which
correspond to proxy agents, as opposed to client devices. (App. Br. 3:3.) In
other words, Appellant’s proxy agents do not “present” content according to
any meaningful distinction over the presentation (i.e., transmission and
processing) of data by Beyda’s local proxy server 14/16. Absent a clear
argument buttressed by support for the elusive meaning behind the clause,
the record provides no basis for a finding of Examiner error.6
Thus, for example, Beyda satisfies the identifying step recitation of “a
directive content operation distinct from presentation of the first content
object by the device,” because the URL directive (e.g., www.cnn.com/audio)
is distinct from the presentation of the first content object (the web page for
www.cnn.com). That is, Beyda’s local server device “presents” (i.e.,
transmits) the first content object (and the URL directive for the second
content object) to the client computer, but employs the URL content
operation directive in a distinct operation, i.e., to facilitate prefetching.
Under an alternative interpretation, the whole web page need not constitute
the first content object of the claim; rather, another graphic file (e.g.,
pertaining to www.cnn.com/graphic.jpg1) satisfies that limitation.

8:7-9.) The passage does not refer specifically or clearly to the presentation
of data content, such as for example on a computer screen, but rather,
appears to relate to the location of commands in a data stream – implying
that distinct presentation embraces different data locations in a data stream.
6 Appellant, for example, also argues, that because Beyda’s local server 14
stores elements in a cache, “the element-by-element [sic] is not a
‘presentation’ of the first content object, as claimed.” (Reply Br. 6.) This
argument not only does not explain what Appellant means by presentation,
but the argument also appears directed to an alleged lack of presentation of
first content operation, as opposed to directed to whether the presentation is
distinct, as argued previously.
Appeal 2009-005558
Application 09/986,967

14
Continuing the interpretation, Beyda’s local server presents the URL content
operation directive (e.g., www.cnn.com/audio) “distinct from the
presentation” of the graphic file, because for example, both are located in
different portions of the web page. Alternatively, one is an object, the other
is a URL, so that any presentation thereof is “distinct.” Also, one pertains to
an audio file, another to graphics, or text, etc., thereby allowing for distinct
presentations.
Beyda also satisfies the “distinct” element in the sending step
recitation of “enabling the device to perform the prefetching of the second
content object based on receipt of the content operation identifier and
distinct from the presentation of the first content object” for similar reasons.
For example, Beyda’s device, the local server 14, prefetches the second
content object, the file pertaining to www.cnn.com/audio, from the remote
server, which is distinct from how Beyda’s device presents (i.e., transmits)
the web page (or another graphic file) to the client. Also, the graphic and
audio files are located in different portions of the data stream (or web page),
assuming for the sake of argument, that the clause requires both items to be
presented in a distinct manner. Moreover, the clause “and distinct from
presentation” does not necessarily require the local server to perform any
presentation, but ambiguously leaves open the possibility that another
device, such as the client computer, performs the presentation. Of course,
under that circumstance, an audio file and graphics file are by nature
presented differently.
Appellant’s remaining arguments throughout both briefs have been
carefully considered. The arguments appear similar to those addressed
above, often with different portions underlined or otherwise emphasized, but
Appeal 2009-005558
Application 09/986,967

15
without clear explanation as to why Beyda does not meet the recited
limitations of claim 1. “The problem in this case is that the appellants failed
to make their intended meaning explicitly clear.” In re Morris, 127 F.3d
1048, 1056 (Fed. Cir. 1997). “It is the applicants’ burden to precisely define
the invention, not the PTO’s.” Id. (citation omitted).
For the remaining independent claims, Appellant relies on the
arguments presented for claim 1, and summarizes as follows: Beyda does
not disclose “the HTTP response, that includes both the first content object
and the directive for prefetching,” which “is sent to the device in claim 1,
received from the destination server in claims 13 and 32, and output by the
interface of the server of claim 20.” (App. Br. 16 (emphasis omitted.).) For
reasons similar to those involved above with respect to claim 1, Beyda’s
remote server 18 constitutes the destination servers recited in claims 13 and
32, and includes the interface of the server recited in claim 20.
Appellant presents no separate patentability argument for claims 2,
14, 21, and 33, which respectively depend from claims 1, 13, 20, and 32.
Based on the foregoing discussion, Appellant has not demonstrated
Examiner error in the rejection based on Beyda of claims 1, 2, 13, 14, 20, 21,
32, and 33.

Obviousness Rejection Based On Beyda and Schloss
Claims 3, 4, 8, 9, 15, 16, 22, 23, 27, 28, 34, and 35
Appellant asserts that the Examiner erred in combining Schloss with
Beyda to arrive at these claims, because Schloss refers to replacing an object
with a tag. (App. Br. 16-19.) The Examiner apparently employed Schloss to
include a teaching of adding a directive tag specifying the corresponding
Appeal 2009-005558
Application 09/986,967

16
operation to be performed and an object identifier. (The Examiner’s
rejection is interpreted as requiring Schloss, in part, because the URL in
Beyda does not, by itself, specify the operation. (See Ans. 5).) The
Examiner responded to Appellant’s argument by stating that replacing
includes adding. (Ans. 10-12.) In other words, the Examiner apparently
reasons that the claims do not preclude subtracting the existing first object of
Beyda and adding the tag elements of Schloss.
In reply to the Examiner’s replacement rationale, Appellant states that
the hypothetical combination simply would teach:
replacing uncacheable objects with identifiers. Consequently,
the hypothetical combination would remove the first content
object and replace the first content object with a persistent
object fragment identifier. Hence, the hypothetical combination
would provide an HTTP response that does not include the first
content object, but instead includes the persistent object
fragment identifier in place of the first content object.
(Reply Br. 12.)
As Appellant’s argument indicates, these claims require both a
directive specifying tag and the first object content in the HTTP response.
Based on the arguments and evidence presented, Appellant’s argument
demonstrates that the hypothetical combination removes the first content
object. Accordingly, Appellant’s argument demonstrates error in the
rejection of these claims.
Claims 6, 11, 25, and 30
Appellant’s argument (App. Br. 18-19) with respect to claims “7 [sic:
6], 11, 25, and 30,”7 asserts that “the rejection fails to provide any analysis

7 Claim 7 does not stand rejected and is not on appeal.
Appeal 2009-005558
Application 09/986,967

17
of any ‘apparent reason’” (id. at 18 (n. 5 citing KSR, cite omitted here)) as
sufficient to arrive at the recited “inserting into the HTTP response at least
one extensible HTTP header . . . .” Appellant is correct, the Examiner failed
to separately address similar claims 6, 11, 25, and 30, or otherwise discuss
the extensible header limitation recited therein in the Final Rejection or the
Answer. “[T]here must be some articulated reasoning with some rational
underpinning to support the legal conclusion of obviousness.” Kahn, 441
F.3d at 988. “On appeal to the Board, an applicant can overcome a rejection
by showing insufficient evidence of prima facie obviousness . . . .” Id. at
985-986 (quoting Rouffet, 149 F.3d at 1355). Accordingly, Appellant has
shown error in the rejection of claims 6, 11, 25, and 30.
Claims 18 and 37
Appellant argues that the combination of Beyda and Schloss does not
satisfy these claims. (App. Br. 17, 18.) These claims require a header which
includes the content operation identifier specified therein. It appears,
although it is not clear from the rejection, that the Examiner may have used
Schloss to satisfy at least the header limitation.
Based on the foregoing discussion and Appellant’s arguments,
Schloss’s teachings would result in replacing the first content object of
Beyda, thereby resulting in “no disclosure or suggestion of the claimed
features as a whole.” (App. Br. 17.) Therefore, the Examiner’s rejection
does not include a sufficient factual foundation to support the rejection of
claims 18 and 37.
CONCLUSION
Appellant did not demonstrate that the Examiner erred in finding that
Beyda discloses “sending to the device an HTTP response to the HTTP
Appeal 2009-005558
Application 09/986,967

18
request, the HTTP response including the first content object and the content
operation identifier, enabling the device to perform the prefetching of the
second content object based on receipt of the content operation identifier and
distinct from the presentation of the first content object,” as set forth in
claim 1.
Appellant did demonstrate that the Examiner erred in finding that
Beyda and Schloss collectively teach the limitations set forth in dependent
claims 3, 4, 6, 8, 9, 11, 15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and 37.
DECISION
We affirm the Examiner’s decision rejecting claims 1, 2, 13, 14, 20,
21, 32, and 33.
We reverse the Examiner’s decision rejecting claims 3, 4, 6, 8, 9, 11,
15, 16, 18, 22, 23, 25, 27, 28, 30, 34, 35, and 37.
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136. See 37 C.F.R.
§ 1.136(a)(1)(iv).
AFFIRMED-IN-PART

rvb

Leon R. Turkevich
2000 M Street, NW
7th Floor
Washington, DC 20036-3307