from the United States Patent and Trademark Office, Patent
Trial and Appeal Board in No. IPR2015-00055, IPR2015-00627,
N. Fahmi, Ascenda Law Group, PC, San Jose, CA, argued for
appellant in 2016-2198, 2016-2298 and for appellee in
L. Kelly, Office of the Solicitor, United States Patent and
Trademark Office, Alexandria, VA, argued for intervenor in
2016-2198. Also represented by Nathan K. Kelley, Michael
Sumner Forman, Thomas W. Krause, Scott Weidenfeller.
Damon Williams, Baker Botts LLP, Palo Alto, CA, argued for
appellees in 2016-2298. Also represented by George Hopkins
Batts, Baker Botts LLP, Palo Alto, CA, argued for appellant
Hulu, LLC, in 2016-2437. Also represented by Eliot Damon
Williams; Michael Hawes, Houston, TX.
F. Ward, Kelley Drye & Warren, LLP, New York, NY, argued
for appellants Netflix, Inc., Spotify USA Inc., in 2016-2437.
Also represented by David Lindenbaum, Michael J. Zinna.
Newman, Mayer, and O'Malley, Circuit Judges.
O'Malley, Circuit Judge.
we decide three appeals in companion cases from final written
decisions of the United States Patent and Trademark Office
("PTO") Patent Trial and Appeal Board's
("Board") inter partes reviews ("IPRs")
of U.S. Patent No. 7, 191, 233 ("the '233
patent"), owned by CRFD Research, Inc.
("CRFD"). Iron Dome LLC v. CRFD Research,
Inc., No. IPR2015-00055, 2016 Pat. App. LEXIS 6855
(P.T.A.B. Apr. 22, 2016) (hereinafter "Iron Dome
Final Written Decision, " Appeal No. 16-2198);
DISH Network Corp. v. CRFD Research, Inc., No.
IPR2015-00627, 2016 Pat. App. LEXIS 7567 (P.T.A.B. June 1,
2016) (hereinafter "DISH Final Written
Decision, " Appeal No. 16-2298); Hulu, LLC v.
CRFD Research, Inc., No. IPR2015-00259, 2016 Pat. App.
LEXIS 4340 (P.T.A.B. June 1, 2016) (hereinafter
"Hulu Final Written Decision, " Appeal No.
16-2437). For the reasons stated below, we affirm the
Iron Dome and DISH Final Written Decisions,
but we reverse the Board's determination on obviousness
in the Hulu Final Written Decision.
'233 patent describes methods and systems for
"user-directed transfer of an on-going software-based
session from one device to another device." '233
patent, col. 1, ll. 10-11. These methods and systems operate
to allow the user to begin a session on one
communication-enabled device, such as a cellular telephone,
wireless personal digital assistant, laptop computer, or
desktop computer, and then to transfer the session to another
device. Id. col. 1, ll. 8-11; see id. col.
1, ll. 15-52; see also id. col. 2, ll. 3-20;
id. col. 3, ll. 6-10.
'233 specification explains that, "[i]n conventional
systems, the user would have to discontinue the current
session on the first device and reinitiate a new session on
the second device." Id. col. 1, ll. 59-62. But
the session transfer described in the '233 patent
"provides the capability to initiate a transfer of an
on-going session from a first device to a second device while
maintaining the session and its context." Id.
col. 3, ll. 7-10.
'233 patent describes a method of session transfer in
which: (1) a first device sends a "redirect or transfer
command" to a session transfer module; (2) a session
server begins intercepting messages intended for the first
device; (3) the first device transmits a "transaction or
session history" to the session server; (4) the session
server retrieves the previously stored "device
profile" of a second device to which the session will be
redirected, converts the stored messages of the session
history into a data format compatible and/or modality
compatible with the second device, and converts the session
state to a state compatible with the second device; and (5)
when the user activates the second device, the session server
"push- es the converted session to the redirected device
over the network 100 as a normal session
with the converted transaction log." Id. col.
7, l. 46-col. 8, l. 35.
is illustrative of the independent and dependent claims at
issue in these appeals:
method for redirecting an on-going, software based session
conducting a session with a first device; specifying a second
discontinuing said session on said first device; and
transmitting a session history of said first device from said
first device to a session transfer module after said session
is discontinued on said first device; and
resuming said session on said second device with said session
Id. col. 9, ll. 30-39.
Relevant Prior Art
Board reviewed three prior art references relevant to the
issues raised in these appeals: (1) Thomas Phan et al.,
"A New TWIST on Mobile Computing: Two-Way Interactive
Session Transfer" in the Proceedings of the Second IEEE
Workshop on Internet Applications (WIAPP 2001) ("Phan
San Jose"); (2) Thomas Phan et al., "Handoff of
Application Sessions Across Time and Space" in volume 5
of the IEEE International Conference on Communications (ICC
2001) ("Phan Helsinki"); and (3) U.S. Patent No. 6,
963, 901, filed July 24, 2000, and issued November 8, 2005
Board examined Phan San Jose as part of the Iron
Dome and DISH Final Written Decisions. Phan San
Jose describes the "Interactive Mobile Application
Support for Heterogeneous Clients (iMASH) research
project." iMASH allows hospital physicians and staff to
"seamlessly move an application's session from one
machine to another machine, " such as a desktop or
laptop computer, using the hospital's "network as a
conduit." Using iMASH, a physician may begin a session
on a first device and later resume that session on a
different device using the session data from the first
of its discussion of the iMASH research project, Phan San
Jose discloses a two-way interactive session transfer
("TWIST"). TWIST places middleware servers
("MWSs") between client devices and an application
server. Session state data on a first device is stored on the
MWS and then transferred to another client upon session
San Jose also describes how the iMASH system could be used
with a "Teaching File" Java applet that displays
medical images and associated information to allow users to
create and modify instructional "teaching files."
In responding to a user request, the application server sends
an image file from storage to the MWS. The MWS then performs
a format conversion on the image, and the requesting client
device then receives this image.
San Jose describes two methods for session handoff: a
"pull" mode and a "push" mode. In the
"pull" mode, so named because the target machine
retrieves the session state from the MWS, the session handoff
proceeds as follows:
When the user wishes to perform a session handoff, he must
first decide how the handoff shall be conducted with respect
to the recipient. If the user selects a "Suspend"
operation [at the first client device in the "pull"
mode], his session shall be saved back to the MWS, allowing
the application to terminate, and at a later time the session
can be reinstantiated by the Teaching File application
running on the target machine.
349 (Appeal No. 16-2198); J.A. 1333 (Appeal No. 16-2298). In
the "pull" mode, the second device is specified
after the session is terminated on the first device.
But in the "push" mode, the user selects the target
second device to which the transfer will be made
before the session on the first device is
terminated. Id. When the handoff occurs in the
"push" mode, the MWS contacts a daemon running on
the target device to immediately launch the Teaching File
applet; this action automatically retrieves the session state
data from the first device. Id. The applet on the
first client terminates only after the session state is fully
reinstantiated on the second machine. Id.
Board examined Phan Helsinki in the course of the Iron
Dome and DISH Final Written Decisions. Phan
Helsinki elaborates on the architecture and operation of the
iMASH research project described in Phan San Jose. J.A.
359-64 (Appeal No. 16-2198); J.A. 1343-48 (Appeal No.
16-2298). Phan Helsinki explains that this system employs
MWSs "strategically placed between the application
servers and the clients." J.A. 359 (Appeal No. 16-2198);
J.A. 1343 (Appeal No. 16-2298). The MWSs, rather than the
original application servers, act as the data sources for the
various clients and support session handoffs. Id.
"When a user moves an on-going application session from
one device to another, middleware servers act as a
'home' for the application state (including active
connections, cached data, etc.) to facilitate migration
between devices." J.A. 361 (Appeal No. 16-2198); J.A.
1345 (Appeal No. 16-2298).
Helsinki also describes the "Middleware-Aware Remote
Code" ("MARC") on the client device that
facilitates "session saving and restoration, " and
explains how a session is transferred using a web browser
that has been "outfitted" with MARC. J.A. 361-62
(Appeal No. 16-2198); J.A. 1345-46 (Appeal No. 16-2298).
First, a user starts the client application by providing a
user ID. The MARC within the browser then contacts the MWS
and begins a new session using this user ID. If a previous
session state exists, it is retrieved from the MWS and is
incorporated into the browser before the user's current
session begins. Id.
discloses a system and method for "sharing . . . browser
information between at least two browser applications"
in which a web browsing session is transferred from a first
computer to a second computer via one or more servers. Bates,
col. 1, ll. 63-66; id. col. 3, ll. 4-7; id.
col. 9, ll. 24-30; id. col. 10, l. 51-col. 11, l. 8.
The "browser information includes information generated
during a browsing session, i.e., a period of time when the
browser 240 is executing on a client
computer 106 and a network connection exists
between the client 106 and the network
104 allowing a user to traverse network
addresses corresponding to the servers 108,
" and the information "may be limited to the
information generated during a particular browsing
session." Id. col. 4, ll. 61-67; id.
col. 6, ll. 11-13; id. col. 7, ll. 22-24.
discloses a step-by-step session transfer process in which a
user first conducts a web browsing session on a first client
computer. Id. col. 10, ll. 58-61. Next, "[a]
user may input to the field 302 an e-mail
address for a computer (e.g., a remote client computer
106) to which the browser information
contained in the sending computer's buffer
242 will be sent." Id. col. 5,
ll. 52-56. When the user wishes to switch computers,
"the user may be re- quired to terminate a browsing
session. In such an event, the necessary browser information
may be collected and transmitted to a remote computer
containing another browser program" through the use of
various servers and networks. Id. col. 10, ll.
61-65. "The browser information is then used to
reconfigure the browser program of the remote computer and
restore the user to where he or she left off during the
terminated browsing session." Id. col. 10, l.
65-col. 11, l. 1. "In effect, the present invention
preserves the current status of a browsing session to be
resumed at another location." Id. col. 11, ll.
also describes various "share events, " which are
events "adapted to initiate transmission of the browser
information from the local client computer to the remote
client computer." Id. col. 9, ll. 4-7. Share
events occur in connection with a user interface, where the
local computer is configured to share browser information
with a remote computer. Id. col. 8, ll. 59-66.
Figure 5 of Bates depicts five such events: (1) upon user
request (i.e., the browser information is transmitted
immediately in response to a user request); (2) at shutdown
(where the browser information is transmitted when the client
computer is shutdown); (3) at an idle period (where the
browser information is transmitted when the client computer
is idle-e.g., when it enters a standby or hibernation mode);
(4) periodically (where the browser information is
transmitted at periodic time intervals); and (5) upon a
predetermined action (in which the browser information is
transmitted upon the occurrence of an action performed by the
user, which action is not ...