Ex Parte Baumeister et al

Board of Patent Appeals and Interferences

Sep 27, 2010

10624353 (B.P.A.I. Sep. 27, 2010)

UNITED STATES PATENT AND TRADEMARK OFFICE
_____________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
_____________

Ex parte SASCHA BAUMEISTER and BERNHARD SCHMID
_____________

Appeal 2009-006351
Application 10/624,353
Technology Center 2400
______________

Before JOHN C. MARTIN, CARLA M. KRIVAK,
and ELENI MANTIS MERCADER, Administrative Patent Judges.

MARTIN, Administrative Patent Judge.

DECISION ON APPEAL1

1 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, or for filing a request for rehearing,
as recited in 37 C.F.R. § 41.52, begins to run from the “MAIL DATE”
(paper delivery mode) or the “NOTIFICATION DATE” (electronic delivery
mode) shown on the PTOL-90A cover letter attached to this decision.
Appeal 2009-006351
Application 10/624,353

2
STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s
rejection of claims 1-7 and 11-18, which are all of the pending claims.2
We have jurisdiction under 35 U.S.C. § 6(b). We reverse.

A. Appellants’ invention
Appellants’ invention relates to a method, a computer program
product, and a device for streaming a media file over a distributed
information system, such as the Internet, to a client computer running a
browser application. Specification 1:4-7.3 The invention is summarized in
the Specifcation as follows:
First, a server receives a request for a particular media file from
the client computer. Then, the server provides a metafile[,] e.g.,
by dynamically generating the metafile or, alternatively, statically
querying the metafile from a respective data storage, whereby said
metafile contains information about the identification, location
and format of the media file, and returns it back to the client
computer. Advantageously, the server intercepts a download
request for the actual media file and reinterprets the download
request in[to] a request for receiving a corresponding metafile.
Thus, instead of returning the requested media file, a metafile is
returned that allows immediate streaming of the requested media

2 The Examiner, as noted at page 2 of the October 15, 2007, Advisory
Action, approved entry of a September 24, 2007, Amendment canceling
claims 8-10.
3 Citations herein to Appellants’ Specification (“Spec.”) are to the
Application as filed rather than to corresponding Patent Application
Publication 2004/0078470 A1.
Appeal 2009-006351
Application 10/624,353

3
file without the need of waiting for the download to be finished.
Id. at 6:4-12.
Figure 1 of the Application is reproduced below.

Figure 1 is a block diagram illustrating a system 100 in accordance
Appellants’ invention (id. at 9:4-5). In web client 102, the web browser 122
composes an HTTP (Hypertext Transfer Protocol4) request for a particular
media content file and sends the request to network interface 124 (id. at

4 Spec. 2:17.
Appeal 2009-006351
Application 10/624,353

4
11:14-15). Regarding generation of this HTTP request, the Specification
explains that
[a] user clicking an HTML [Hypertext Markup Language5]
document link may initiate this action. Alternatively a user may
initiate this action by typing the request URL [Uniform Resource
Locator6] into the browser[’]s URL input field. Please note that
the request URL points to the media file itself, and neither to a
streaming metafile nor a CGI/Java Servlet program component.
Id. at 11:15-19. The HTTP request is received by network interface 134 in
metadata server 104 and forwarded to an HTTP protocol handler 132 in that
server (id. at 11:14-25). In contrast to a conventional HTTP protocol
handler, which answers an HTTP request either by returning the content of
the resource requested (default HTTP behavior) or by executing the resource
and forwarding its reply (Java Servlets, CGI scripts), HTTP protocol handler
132 “reinterprets the HTTP request so that it returns streaming metadata”
(id. at 12:1-5), i.e., metadata about the requested data stream or steams.
Specifically, HTTP protocol handler 132 obtains the metadata for the
requested media resource from the metadata generator 136 or from the
metadata query component 138 (id. at 12:5-7). In either case, the resulting
“streaming metadata” is returned to HTTP protocol handler 132 (id. at
12:18-19). This streaming metadata is accompanied by a MIME
(Multipurpose Internet Mail Extension)-Type suitable for the streaming
metadata (id. at 12:19-21).

5 Spec. 2:13-14.
6 Spec. 4:20-21.
Appeal 2009-006351
Application 10/624,353

5
HTTP protocol handler 132 sends the streaming metadata and MIME-
Type through network interfaces 134 and 124 to web browser 122, which
analyzes the MIME-Type, selects a suitable multimedia player 126 based on
this information, and forwards the streaming metadata information to the
multimedia player (id. at 13:8-11). The multimedia player analyses the
streaming metadata passed to it and extracts all relevant information, such as
which streaming server to contact, which streaming protocol to use, and
which file to stream (id. at 13:12-14). Streaming protocols may be RTSP
(Real Time Streaming Protocol7), HTTP, or proprietary protocols, depending
on the streaming technology provider (id. at 13:14-15). Next, multimedia
player 126 composes a streaming protocol request and sends it via network
interface 124 to network interface 146 on delivery server 106 (id. at 13:15-
19). Delivery server 106 transfers real-time protocol packets via network
interfaces 146 and 124 to multimedia player 126, which renders their content
as they arrive (id. at 14:1-14).

B. The claims
The independent claims before us are claims 1, 11, and 18, of which
claim 1 reads as follows:
1. A method for streaming a media file over a distributed
information system to a client computer running a browser
application, the method comprising the steps of:

7 Spec. 3:10-11.
Appeal 2009-006351
Application 10/624,353

6
receiving a request for a particular media file from a client
computer,
providing a metafile, wherein said metafile contains
information about the identification, location and format of the
media file,
returning said metafile back to said client computer,
characterized in that
the step of receiving a request for a particular media file
from a client computer comprises the steps of:
intercepting a download request for the actual media file
and
reinterpreting said download request into a request for
receiving a corresponding metafile.
Claims App. (Br. 24).8
Appellants, in identifying the support for claim 1 in the Specfication,
read the step of “receiving a request for a particular media file from a client
computer” on the receipt by metadata server 104 of the HTTP request
generated by web client 102 (Br. 8) and read the recited “metafile” that is
returned back to the client computer on the “streaming metadata” transmitted
by metadata server 104 to web client 102 (id. at 9).

C. The reference
The Examiner’s rejections are based on the following reference:
Klemets US 2003/0236912 A1 Dec. 25, 2003
In the discussion of the anticipation rejection, the Examiner also relies
on H. Schulzrinne et al., Network Working Group, Request for Comments:
Appeal 2009-006351
Application 10/624,353

7
2326, Category: Standards Track (April 1998) [hereinafter “Schulzrinne”].
Final Action 7-8.

D. The rejections
Claims 1-4, 6-14, and 16-18 stand rejected under 35 U.S.C. § 102(e)
for anticipation by Klemets. Final Action 2, para. 3.9
Claims 5 and 15 stand rejected under 35 U.S.C. § 103(a) for
obviousness over Klemets. Id. at 5, para. 5.

THE ISSUE
The dispositive issue raised by Appellants’ arguments is whether the
Examiner erred in reading the recited “download request for the actual
media file” (claim 1) on Klemets’s DESCRIBE request.10

ANALYSIS

8 Apeal Brief filed December 19, 2007.
9 Although claim 18 is not identified in the statement of the rejection at
page 3, paragraph 3 of the Final Action, that claim is addressed at page 5
thereof in the discussion of the rejection.
10 See Ex parte Frye, 94 USPQ2d 1072, 1075 (BPAI 2010) (precedential)
(“If an appellant fails to present arguments on a particular issue — or, more
broadly, on a particular rejection — the Board will not, as a general matter,
unilaterally review those uncontested aspects of the rejection.”). Designated
as precedential at
http://www.uspto.gov/ip/boards/bpai/decisions/prec/index.jsp.
Appeal 2009-006351
Application 10/624,353

8
Klemets’s invention relates to content streaming and more particularly
to embedding a streaming media format header within a session description
message. Klemets [0002], [0003].
Figures 1 and 3 are reproduced below.

Figure 1 is a block diagram of Klemets’s system (id. at [0030]), and
Figure 3 is an exemplary flow diagram illustrating the interaction between
the client and the server for initiating a streaming media session (id. at
[0023]).
Appeal 2009-006351
Application 10/624,353

9
To initiate a session, the client 106 sends a description request (e.g.,
an RTSP DESCRIBE request) to the server 104 to obtain a description of the
available content (id. at [0041]). Server 104 responds by encapsulating the
streaming media format header within a description message (e.g., an SDP --
Session Description Protocol11 -- message) and transmitting the description
message via a description protocol (e.g., SDP) to the client 106 (id.). The
SDP message includes a streaming media format file header and a content
description list (id. at [0031]). The client 106 then initiates a connection to
the server 104 using a RTSP SETUP command (id. at [0045]). The client
106 is free to choose which streams it wants to SETUP (i.e., receive from the
server 104) (id.). The client 106 can, for example, issue a separate RTSP
PLAY request for each stream that has been chosen (id.).
The Examiner reads the claim 1 step of “receiving a request for a
particular media file” on the receipt, by media server 104, of a DESCRIBE
request. See Final Action 8 (“the RTSP DESCRIBE method requires
identification of a particular media file . . . , which is typically identified by a
specific URL.”). As support for the finding that an RTSP DESCRIBE
request identifies a particular media file, the Examiner relies on the
discussion of an RTSP DESCRIBE request in Section 10.2 (at pages 31-32)
of Schulzrinne. Id. at 7-8. In the October 15, 2007, Advisory Action, the
Examiner further finds (at page 3) that “the RTSP DESCRIBE message is a
request for [initiating] a particular media file”) (brackets in original).

11 Klemets [0007].
Appeal 2009-006351
Application 10/624,353

10
Appellants responded to the Examiner’s reading of the “request for a
particular media file” on Klements’s RTSP DESCRIBE request by arguing
that
[t]he RTSP DESCRIBE request disclosed in the Klemets et
al. reference is clearly not a request for a particular media file as
required by each of independent claims 1 and 11. The RTSP
DESCRIBE request disclosed in the Klemets et al. reference is
merely a request from the client to the server to describe the
available content. See, Klemets et al., page 2, paragraph [0015]
and paragraph [0016]; and page 4, paragraph [0041].
(Br. 16-17.) Because Appellants have not challenged the Examiner’s above-
quoted finding that an RTSP DESCRIBE request identifies a particular
media file, we understand Appellants to be arguing that the DESCRIBE
request nevertheless is not “a request for a particular media file” (emphasis
added), as required by the claim. We agree with the Examiner that this
claim language is broad enough to read on a request with regard or respect
to a particular media file and thus is broad enough to read on the DESCRIBE
request (Answer 8).
Appellants next argue that “the RTSP DESCRIBE request does not
involve the steps of intercepting a download request for the actual media
file, and reinterpreting the download request into a request for receiving a
corresponding metafile as further required by each of independent claims 1
and 11” (Br. 17). The Examiner responded to this argument by discussing
the meaning of the recited “download request for the actual media file”
separately from the meanings of the terms “intercepting” and
“reinterpreting.” Regarding the recited “download request for the actual
Appeal 2009-006351
Application 10/624,353

11
media file,” the Examiner concludes that this claim language does not
necessarily mean a request to download the actual media file:
[T]he phrase “intercepting a download request for the actual
media file” does not necessarily mean that the request is a request
to download the actual media file. . . . [T]he phrases “for a
particular media file” and “for the actual media file” could mean
either that the request is to acquire, or download, the media file
(which is the interpretation that Appellant is apparently relying
upon), or that the request is with regard or respect to a particular
media file (which is clearly within the scope of the instant claims,
and is the interpretation relied upon by the Examiner).
(Answer 8.) We agree with Appellants that the Examiner’s interpretation of
the phrase “download request for the actual media file” is unduly broad.
When that phrase is viewed in light of the further recitation of
“reinterpreting said download request into a request for receiving a
corresponding metafile,” it is clear that the “download request for the actual
media file” is a request to download the actual media file rather than a
request to download information with regard to or with respect to the actual
media file. Because the Examiner apparently agrees with Appellants that the
“download request for the actual media file” so interpreted does not read on
Klemets’s DESCRIBE request, we will not sustain the anticipation rejection
of: (a) claim 1; (b) independent claims 11 and 18, which include limitations
similar to those recited in claims 1; and (c) dependent claims 2-4, 6, 7, 12-
14, 16, and 17, which are not separately argued. In re Nielson, 816 F.2d
1567, 1572 (Fed. Cir. 1987).
Appeal 2009-006351
Application 10/624,353

12
For the same reason, and because the Examiner does not alternatively
rely on obviousness to remedy the above-noted deficiency, we will not
sustain the rejection of claims dependent 5 and 15 under 35 U.S.C. § 103(a)
for obviousness over Klemets.

DECISION
The Examiner’s decision that claims 1-7 and 11-18 are unpatentable
over the prior art is reversed.

REVERSED

gvw

IBM CORPORATION
ROCHESTER IP LAW DEPT. 917
3605 HIGHWAY 52 NORTH
ROCHESTER, MN 55901-7829