Ex Parte Choi et al

Board of Patent Appeals and Interferences

Jul 14, 2009

10179583 (B.P.A.I. Jul. 14, 2009)

UNITED STATES PATENT AND TRADEMARK OFFICE
________________

BEFORE THE BOARD OF PATENT APPEALS
AND INTERFERENCES
________________

Ex parte YEJIN CHOI, ALEXANDRE GRIGOROVITCH, and
TROY BATTERBERRY
________________

Appeal 2008-004820
Application 10/179,583
Technology Center 2400
________________

Decided:1 July 15, 2009
________________

Before JAMES D. THOMAS, JOSEPH L. DIXON, and JAY P. LUCAS,
Administrative Patent Judges.

THOMAS, Administrative Patent Judge.

1 The two-month time period for filing an appeal or commencing a civil
action, as recited in 37 C.F.R. § 1.304, begins to run from the Decided Date
shown on this page of the decision. The time period does not run from the
Mail Date (paper delivery) or Notification Date (electronic delivery).

Appeal 2008-004820
Application 10/179,583

2
DECISION ON APPEAL

STATEMENT OF THE CASE
This is an appeal under 35 U.S.C. § 134(a) from the Examiner’s final
rejection of claims 1 through 42. We have jurisdiction under 35 U.S.C. §
6(b).
We affirm.

Invention
A system and method to automatically recover from broken network
connections in streaming media scenarios. Server software (112) executing
on the server communicates with client software (114) executing on the
client during the streaming media session. If the streaming media session is
interrupted, the server software and the client software exchange messages
to associate the client with a client state stored by the server and to re-
synchronize playback of the content. Once a network connection is broken,
a client issues a reconnection request 302 to a server, where the request
includes a session identifier 304 and a stream identifier 306 (Abstract; Spec.
51; and Figures 1 and 3).
Representative Claim
1. A method of streaming media content from a server to at least one
client, said method comprising:
establishing a streaming media connection between the server and the
at least one client;
associating a session identifier and a stream identifier with the
established streaming media connection;
streaming the media content from the server to the client;
receiving, by the client, the streamed media content from the server;
Appeal 2008-004820
Application 10/179,583

3
maintaining, by the server, a state based on said streaming the media
content from the server to the client, and associating the maintained state
with the session identifier and the stream identifier;
sending a reconnect request from the client to the server if said
streaming is interrupted, said reconnect request including the session
identifier and the stream identifier;
receiving, by the server, the reconnect request from the client;
retrieving the maintained state based on the session identifier and the
stream identifier in the received request;
re-establishing the streaming media connection with the client based
on the retrieved state; and
continuing, based on the retrieved state, with said streaming the media
content and said receiving, by the client, the streamed media content from
the server.

Prior Art and Examiner’s Rejection
The Examiner relies on the following references as evidence of
anticipation:

Raman US 6,910,078 B1 Jun. 21, 2005
(filed Nov. 15, 2001)

Claims 1-42 stand rejected under 35 U.S.C. § 102(e) as being
anticipated by Raman.

Claim Groupings
In accordance with the arguments set through pages 4 through 6 of the
Brief, Appellants consider independent claim 1 as representative of the
subject matter of independent claims 1, 12, and 26 on appeal. In accordance
with the arguments set through pages 6 through 8 of the Brief, Appellants
consider independent claim 39 as representative of claims 39 through 41 and
separately argue independent claim 42 at pages 8 through 10 of the principal
Appeal 2008-004820
Application 10/179,583

4
Brief. No arguments are presented before us as to any dependent claim on
appeal.
ISSUE
Have Appellants shown that Examiner erred in finding that Raman
teaches the feature common among each independent claim 1, 12, 26, 39,
and 42 on appeal of associating a session identifier and a stream identifier
with an established streaming connection?

FINDINGS OF FACT (“FF”)
1. Appellants make reference to prior art streaming media protocols at
Specification page 7:

[0030] In one embodiment, communication between the servers
108 and client 110 in FIG. 1 is implemented using a real-time
streaming protocol (RTSP) and a session description protocol
(SDP). RTSP, as described in the Internet Engineering Task
Force (IETF) RFC 2326, the entire disclosure of which is
incorporated herein by reference, is an application-level
protocol for control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio
and video. Sources of data can include both live data feeds and
stored clips. This protocol is intended to control multiple data
delivery sessions, provide a means for choosing delivery
channels such as a user datagram protocol (UDP), a multicast
UDP and a transmission control protocol, and provide a means
for choosing delivery mechanisms based upon a real-time
transport protocol.

[0031] For example, the Real-time Transport Protocol (RTP),
as described in the IETF RFC 1889, the entire disclosure of
which is incorporated herein by reference, provides end-to-end
network transport functions suitable for applications
transmitting real-time data, such as audio, video or simulation
Appeal 2008-004820
Application 10/179,583

5
data, over multicast or unicast network services. RTP does not
address resource reservation and does not guarantee quality-of-
service for real-time services. The data transport is augmented
by a control protocol (RTCP) to allow monitoring of the data
delivery in a manner scalable to large multicast networks, and
to provide minimal control and identification functionality.
RTP and RTCP are designed to be independent of the
underlying transport and network layers.

[0032] SDP, as described in the IETF RFC 2327, the entire
disclosure of which is incorporated herein by reference, is an
application level protocol intended for describing multimedia
sessions for the purposes of session announcement, session
invitation, and other forms of multimedia session initiation.
SDP can be used in conjunction with RTSP to describe and
negotiate properties of the multimedia session used for delivery
of real-time data.
(Spec. [0030], [0031], [0032].)

2. For his part, Raman independently makes reference to substantially
identical prior art protocols:

For complete details on the operation of RTSP, the reader is
directed to Request for Comment 2326 (RFC-2326) which is a
document maintained by the Internet Engineering Task Force
(IETF) that specifies an Internet standards track protocol for
RTSP. The teaching and contents of the RFC-2326 document
are hereby incorporated by reference herein in their entirety.

Other conventional data transfer communications protocols can
carry out the processing and messaging required to carry or
transport the actual stream data. As an example, the Real Time
Protocol (RTP) can be used as a transport mechanism to
propagate real-time stream data through a computer network.
The RTP protocol encodes the real-time stream data into a
packet and includes sequencing and/or timing information into
the data such as virtual time fields that allow a recipient to
identify how the portions of stream data in one RTP encoded
Appeal 2008-004820
Application 10/179,583

6
packet relate to other portions of stream data in other RTP
packets. In other words, RTP can encode data with timing
information about the media thus providing a reference to the
recipient for how the media can be played back.
(Col. 2, ll. 33-54.)

In another embodiment, monitoring operation of the stream
control protocol can include monitoring operation of the
protocol actually used to transfer stream data, such as the RTP
protocol. In such a case, the packet of RTP protocol encoded
data can be monitored to obtain timing and/ or sequencing
information regarding the media to allow the failover manager
150 to track where in the media (e.g., at what time relative to
the start of the media stream) the current transmission of stream
data exists. In other words, monitoring RTSP can be used to
gain insight into the control flow of the stream data, and
monitoring of RTP information within the stream data packet
170 can be used to gain further information on exact play times
of the stream data 170 during passage of this data through the
data communications device 110 operating the failover manager
150. Other examples of stream transfer and control protocols
that actually carry stream data as well are MPEG encoding
techniques such as MPEG4 in which framing information is
encoded within the stream data packet 170. In such cases, the
monitoring operation of the stream control protocol includes
monitoring the actual stream data packets 170 as the stream
control protocol is “built into” such package along with the
stream data. Specific techniques for obtaining timing or
framing information concerning a specific playback point in a
media stream of data from the data encoded that is encoded
with a stream control protocol such as RTP or MPEG area
known to those skilled in the art.
(Col. 11, ll. 33-59.)

3. Raman illustrates in Figures 1 and 3, a stream control protocol 180
to which is independently associated a stream of media data 170, the
latter of which includes relative time identifiers T1-TN and position
identifiers P1-PN as noted beginning with the discussion of Figure 1
Appeal 2008-004820
Application 10/179,583

7
at the middle of column 9. The details of the ongoing dialogue
messages between a server 120/122 and a client 130 include an
intermediate server or the like 110 that includes a failover manager
application 151, which include various processes 150 within its
memory 113 in Figure 3. This process is shown first in broad
perspective in Figure 2 and then in detail in Figures 5 through 7.
Once a mid stream failover occurs, such as to indicate a stream
change event, Raman’s intent is to switch from a first stream server
120 to a second stream server 122 so that client does not “see” any
disruptions in the media stream to it.

4. Raman also teaches that a plurality of media streams may exist
from/to each client and/or server:

Furthermore, embodiments of the invention are not limited to
the stream server only serving data to the client computer
system 130. In some situations, stream data may flow in both
directions from a stream server to a client and from a client to a
stream server. In either or both of these cases, the stream
control monitor can monitor stream control protocol messages
180 traveling in both directions in order to control stream data
for one or more stream traveling in either direction.
(Col. 16, ll. 11-19.)

As an example, the stream data 170 can comprise multiple
flows of data. In such situations, the operation of identifying a
relative position within the stream data identifies respective
relative positions 192 within each flow of the stream data 170.
That is, the monitoring operation of the stream control protocol
180 can monitor and maintain a steam state for each stream of
data served by (to or from) each stream server. Then, upon
detection of a stream change event, this relative position
Appeal 2008-004820
Application 10/179,583

8
information for each separate stream or flow of data can be
used to perform mi-stream failover as previously explained.
(Col. 19, ll. 49-59.)

PRINCIPLES OF LAW
“A claim is anticipated only if each and every element as set forth in
the claim is found, either expressly or inherently described, in a single prior
art reference.” Verdegaal Bros. v. Union Oil Co. of California, 814 F.2d
628, 631 (Fed. Cir. 1987). Analysis of whether a claim is patentable over
the prior art under 35 U.S.C. § 102 begins with a determination of the scope
of the claim. We determine the scope of the claims in patent applications
not solely on the basis of the claim language, but upon giving claims their
broadest reasonable construction in light of the specification as it would be
interpreted by one of ordinary skill in the art. In re Am. Acad. of Sci. Tech.
Ctr., 367 F.3d 1359, 1364 (Fed. Cir. 2004). The properly interpreted claim
must then be compared with the prior art.

ANALYSIS
We begin our analysis by noting that the Court of Appeals for the
Federal Circuit has determined “[t]eaching away is irrelevant to
anticipation.” Seachange Intl’, Inc., v. Co-Cor, Inc., 413 F.3d 1361, 1380
(Fed. Cir. 2005) (citing Celeritas Tech., Ltd. v. Rockwell Intl’ Corp., 150
F.3d 1354, 1361(Fed. Cir. 1998); Bristol-Mysers Squibb Co. v. Ben Venue
Labs., Inc., 246 F.3d 1368, 1378 (Fed. Cir. 2001)). Thus, to the extent
Appellants urge beginning at page 5 of the principal Brief on appeal that
Raman teaches away from the claimed invention, this argument is
inapposite.
Appeal 2008-004820
Application 10/179,583

9
With respect to the argued feature represented in the issue that we
have characterized earlier in this opinion, Appellants’ own disclosed
invention we reproduced in FF 1 provides a basis for the argued feature from
the admitted prior art. Independently of this, however, what we have
isolated in FF 2 in Raman again appears to teach the same features of the
existence of some kind of session identifier and stream identifier as prior art.
The artisan would understand any given session between a client and server
must be identified to separate it from any other session that may exist
between a server and a different client at the same time. Correspondingly, a
given stream identifier would be necessarily inherent to identify a particular
stream of data sent to a given client from a server at any given time. The
prior art protocols we identified in FF 2 at columns 2 and 11 of Raman
appear to indicate these exist in terms of sequencing and/or timing
information associated with the flow of the media stream itself for various
types of prior art streaming protocols.
Notwithstanding these considerations, it appears to us that the artisan
understands from the actual teachings we identified in FFs 3 and 4 from
Raman and illustrated in Figures 1 and 2 that a stream control protocol/
identifier 180 in addition to the separate data stream 170, which itself
contains relative position and timing information, uniquely identify this
position and/or time in which the disruption in Raman occurs for any given
server-client session. Correspondingly, the argued features of the various
“states” recited in representative independent claim 1, for example, maybe
met by the use of the noted time and position code information illustrated at
the upper right in Figure 1 and discussed in FF 2. For these so-called “state”
information items to exist to be monitored by failover manager 150 within
Appeal 2008-004820
Application 10/179,583

10
the intermediate server device 110 in Figures 1 and 3, they must have been
originally identified by the server sending the media stream.
Thus, it appears to us that from an artisan’s perspective (or a person of
ordinary skill in the art), Raman indicates that it was known in the art that
some form of session identifier and stream identifier existed to establish
streaming media connections, and the various states associated with the
streaming data existed in association with the server sending the information
to a client for any given session and any given stream. We are, therefore,
unpersuaded by the bulk of the Appellants’ arguments in the Brief and Reply
Brief as to these argued features.
We have identified earlier the inappropriateness of arguing that
Raman teaches away from the claimed invention generally speaking within a
rejection under 35 U.S.C. § 102. As correctly noted by the Examiner at
pages 21 and 22 of the Answer, Appellants’ argument that Raman
essentially teaches away or, in other words, does not teach, reestablishing a
connection between the client and the same server, the Examiner correctly
points out that the language “the same server” is not recited in the body of
representative independent claim 1 on appeal. What is recited in this
representative claim is only “the server,” which ultimately refers back to the
broad recitation of “a server” in the preamble of this claim. The argument is
not appropriate to the subject matter of independent claim 12 anyway, which
does not recite a server at all, and to independent claim 39, which merely
recites a server component associated with a similar broad recitation “a
server” in the preamble of this claim. As such, the argument at most applies
only to independent claims 1, 26, and 42, each of which recites broadly “a
server” in the preamble of these claims. We, therefore, agree with the
Appeal 2008-004820
Application 10/179,583

11
Examiner’s view in effect that the teachings of Raman apply equally well,
even though the reference switches between one server and another server,
because the same server was not recited in the body of these claims. What is
actually reestablished in the claims is the immediate connection itself, which
is plainly recited and required of each independent claim on appeal and
which is taught in Raman. With regard to actual recitation of “the server” in
the body of the claims that recited the server to be fairly interpreted, it refers
back to the preamble recitation of “a server” and thus to any of the servers
within Raman’s teachings.
With respect to the separate recitations of the respectively recited
server and client components in independent claim 39, these refer to
disclosed software entities 112, 114 illustrated in Figure 1 of the disclosed
invention. As noted in FF 3, these software components are embodied
within the flowchart of Figure 2, which is detailed in Figures 5 through 7 of
Raman. The broadly recited data structure in the preamble of independent
claim 42 is stated to comprise a session identifier and a stream identifier.
These features have already been addressed by our earlier discussion of the
argued features associated with all claims on appeal.

CONCLUSION AND DECISION
Appellants have not shown that the Examiner erred in finding that
Raman teaches the claimed session identifier and stream identifier and the
maintenance of streaming states associated therewith, to the extent recited in
independent claims 1, 12, 26, 39, and 42 on appeal. The Examiner’s
rejection under 35 U.S.C § 102 of all claims on appeal, claims 1 through 42,
is affirmed. All claims on appeal are unpatentable.
Appeal 2008-004820
Application 10/179,583

12
No time period for taking any subsequent action in connection with
this appeal may be extended under 37 C.F.R. § 1.136(a)(1)(v).

AFFIRMED

erc

MERCHANT & GOULD (MICROSOFT)
P.O. BOX 2903
MINNEAPOLIS, MN 55402-0903