`571-272-7822
`
`Paper 25
`Entered: June 1, 2016
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`DISH NETWORK CORPORATION, DISH DBS CORPORATION,
`DISH NETWORK L.L.C., ECHOSTAR CORPORATION, and
`ECHOSTAR TECHNOLOGIES L.L.C.,
`Petitioner,
`
`v.
`
`CRFD RESEARCH, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00627
`Patent 7,191,233 B2
`____________
`
`
`
`Before JUSTIN T. ARBES, THOMAS L. GIANNETTI, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`ARBES, Administrative Patent Judge.
`
`FINAL WRITTEN DECISION
`35 U.S.C. § 318(a) and 37 C.F.R. § 42.73
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`I. BACKGROUND
`Petitioners DISH Network Corporation, DISH DBS Corporation,
`DISH Network L.L.C., EchoStar Corporation, and EchoStar Technologies
`L.L.C. (collectively, “Petitioner”) filed a Petition (Paper 1, “Pet.”) seeking
`inter partes review of claims 1, 4, 23, and 25 of U.S. Patent No. 7,191,233
`B2 (Ex. 1001, “the ’233 patent”) pursuant to 35 U.S.C. §§ 311–319. On
`June 3, 2015, we instituted an inter partes review of claims 1, 4, 23, and 25
`on four grounds of unpatentability (Paper 9, “Dec. on Inst.”). Patent Owner
`CRFD Research, Inc. filed a Patent Owner Response (Paper 14,
`“PO Resp.”), and Petitioner filed a Reply (Paper 16, “Reply”). An oral
`hearing was held on January 19, 2016, and a transcript of the hearing is
`included in the record (Paper 23, “Tr.”).
`We have jurisdiction under 35 U.S.C. § 6(c). This final written
`decision is issued pursuant to 35 U.S.C. § 318(a) and 37 C.F.R. § 42.73.
`For the reasons that follow, we determine that Petitioner has shown by
`a preponderance of the evidence that claims 1, 4, 23, and 25 are
`unpatentable.
`
`
`A. The ’233 Patent1
`The ’233 patent describes a system and method for “user-directed
`transfer of an on-going software-based session from one device to another
`
`
`1 The ’233 patent also is the subject of Cases IPR2015-00055 and
`IPR2015-00259, in which inter partes reviews were instituted, and was the
`subject of Case IPR2015-00157, in which the request for inter partes review
`was denied. On April 22, 2016, we issued a final written decision in
`Case IPR2015-00055 determining that claims 1, 4–6, and 8–11 of the
`’233 patent had been shown to be unpatentable.
`
`
`2
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`device.” Ex. 1001, col. 1, ll. 8–11. A user may have a number of
`communication-enabled devices (e.g., cellular telephone, wireless personal
`digital assistant (PDA), laptop computer, desktop computer) through which
`the user conducts software application sessions. Id. at col. 1, ll. 15–52. The
`user may conduct a session on one device and then decide to switch to
`another device. Id. at col. 1, ll. 53–59. For example, the user may want to
`switch from a stationary device to a mobile device, or to switch to a device
`with a different graphical user interface. Id. According to the ’233 patent,
`conventional systems that required the user to “discontinue the current
`session on the first device and reinitiate a new session on the second device”
`could entail inconveniences such as the history of the original session being
`lost or time delays involved in logging off and reinitiating. Id. at col. 1,
`ll. 59–66.
`Figure 1 of the ’233 patent is reproduced below.
`
`
`
`
`
`
`3
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`Figure 1 depicts wireless clients 120 (e.g., a cellular telephone or PDA) and
`wired clients 125 (e.g., a desktop or laptop computer) of a user that connect
`over various networks to application services network 105. Id. at col. 4,
`ll. 4–11, 30–33, col. 5, ll. 3–6. Wireless clients 120 and wired clients 125
`execute client programs that support session services for the respective
`devices, and are “configured to have a preferred mode of interaction,
`i.e., modality,” such as a graphical user interface for transferring sessions
`between devices. Id. at col. 4, ll. 33–50. Application services network 105
`provides session-based services (e.g., instant messaging, database querying),
`and application server 140 provides applications for those services
`(e.g., instant messaging application, database querying application), to
`wireless clients 120 and wired clients 125. Id. at col. 5, ll. 21–30.
`The ’233 patent describes the method of session transfer as follows:
`(1) a “redirect or transfer command” is sent from a first device (wireless
`client 120 or wired client 125); (2) session server 145 begins intercepting
`messages destined for the first device; (3) the first device transmits a
`“transaction or session history” to session server 145; (4) session server 145
`retrieves the previously stored “device profile” of the second device to
`which the session is to be redirected, “convert[s] the stored messages [of the
`session history] into a data format” and/or modality compatible with the
`second device, and converts the “state” of the session to a state compatible
`with the second device; and (5) when the user activates the second device,
`session server 145 “pushes the converted session to the redirected device
`over the network 100 as a normal session with the converted transaction
`log.” Id. at col. 7, l. 46–col. 8, l. 58, Figs. 3A–3B.
`
`
`
`
`
`4
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`B. Illustrative Claim
`Claim 1 of the ’233 patent recites:
`1. A method for redirecting an on-going, software based
`session comprising:
`conducting a session with a first device;
`specifying a second device;
`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 history.
`
`
`C. Prior Art
`The pending grounds of unpatentability in the instant inter partes
`review are based on the following prior art:
`U.S. Patent No. 6,963,901 B1, filed July 24, 2000, issued
`Nov. 8, 2005 (Ex. 1004, “Bates”);
`Mun Choon Chan & Thomas Y. C. Woo,
`Next-Generation Wireless Data Services: Architecture and
`Experience, IEEE PERS. COMM., Feb. 1999, 20 (Ex. 1005,
`“Chan”);
`Thomas Phan et al., A New TWIST on Mobile
`Computing: Two-Way Interactive Session Transfer, PROC.
`SECOND IEEE WORKSHOP ON INTERNET APPLICATIONS (WIAPP
`2001) (Ex. 1019, “Phan San Jose”); and
`Thomas Phan et al., Handoff of Application Sessions
`Across Time and Space, IEEE INT’L CONF. ON COMM. (ICC
`2001) (Ex. 1020, “Phan Helsinki”).2
`
`
`2 Petitioner refers to Phan San Jose as “Phan WIAPP,” and refers to Phan
`Helsinki as “Phan ICC.” Because the two references were discussed
`
`
`5
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`D. Pending Grounds of Unpatentability
`The instant inter partes review involves the following grounds of
`unpatentability:
`Reference(s)
`Phan Helsinki
`
`Claim(s)
`Basis
`35 U.S.C. § 102(a) 1, 4, 23, and 25
`
`Phan Helsinki and
`Phan San Jose
`Bates
`
`35 U.S.C. § 103(a) 4 and 25
`
`35 U.S.C. § 102(e) 1 and 23
`
`Bates and Chan
`
`35 U.S.C. § 103(a) 1, 4, 23, and 25
`
`
`II. ANALYSIS
`A. Claim Interpretation
`The Board interprets claims using the “broadest reasonable
`construction in light of the specification of the patent in which [they]
`appear[].” 37 C.F.R. § 42.100(b); see In re Cuozzo Speed Techs., LLC,
`793 F.3d 1268, 1278–79 (Fed. Cir. 2015), cert. granted sub nom. Cuozzo
`
`
`previously in Case IPR2015-00055, we use the same nomenclature as the
`earlier proceeding for consistency. The copies of Phan San Jose and Phan
`Helsinki submitted by Petitioner include Library of Congress date stamps of
`August 28, 2001, and July 31, 2001, respectively. Petitioner argues that the
`references were publicly available “at least as early as” August 18, 2001
`(presumably August 28, 2001), and July 31, 2001, respectively. Pet. 3.
`Patent Owner does not dispute Petitioner’s contentions. Based on the record
`presented, we are persuaded that Phan San Jose and Phan Helsinki are prior
`art printed publications under 35 U.S.C. § 102(a). See Kyocera Wireless
`Corp. v. ITC, 545 F.3d 1340, 1350–51 (Fed. Cir. 2008). Also, when citing
`Phan San Jose and Phan Helsinki, we refer to the page numbers added by
`Petitioner in the bottom-right corner of each page. See 37 C.F.R.
`§ 42.63(d)(2).
`
`
`
`6
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`Speed Techs. LLC v. Lee, 136 S. Ct. 890 (mem.) (2016). Under this
`standard, we interpret claim terms using “the broadest reasonable meaning
`of the words in their ordinary usage as they would be understood by one of
`ordinary skill in the art, taking into account whatever enlightenment by way
`of definitions or otherwise that may be afforded by the written description
`contained in the applicant’s specification.” In re Morris, 127 F.3d 1048,
`1054 (Fed. Cir. 1997). We presume that claim terms have their ordinary and
`customary meaning. See Trivascular, Inc. v. Samuels, 812 F.3d 1056, 1062
`(Fed. Cir. 2016) (“Under a broadest reasonable interpretation, words of the
`claim must be given their plain meaning, unless such meaning is inconsistent
`with the specification and prosecution history.”); In re Translogic Tech.,
`Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007) (“The ordinary and customary
`meaning is the meaning that the term would have to a person of ordinary
`skill in the art in question.” (internal quotation marks omitted)). A patentee,
`however, may rebut this presumption by acting as his or her own
`lexicographer, providing a definition of the term in the specification with
`“reasonable clarity, deliberateness, and precision.” In re Paulsen, 30 F.3d
`1475, 1480 (Fed. Cir. 1994).
`
`
`1. Previously Interpreted Terms
`In the Decisions on Institution in Cases IPR2015-00055,
`IPR2015-00157, IPR2015-00259, and IPR2015-00627, we interpreted
`various claim terms of the ’233 patent as follows:
`Claim Term
`Interpretation
`“modality”
`a preferred mode of interaction
`
`
`
`
`7
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`Claim Term
`“device profile”
`
`“in response to . . .
`activation of said
`second device”
`“session”
`
`“discontinuing”
`
`“discontinued”
`
`“session transfer
`module”
`
`Interpretation
`information pertaining to the operation of a
`device, such as the data format or modality of
`the device
`in response to the second device being made
`active, such as by a user logging on to the
`second device
`a series of information transactions between
`communicating devices during a particular
`time period
`terminating or otherwise stopping, with the
`ability to be resumed
`terminated or otherwise stopped, with the
`ability to be resumed
`computer hardware and/or software that
`participates in the transfer of a session
`
`See Dec. on Inst. 6–9; Hulu, LLC v. CRFD Research, Inc., Case
`IPR2015-00259, slip op. at 6–9 (PTAB June 3, 2015) (Paper 8); Unified
`Patents Inc. v. CRFD Research, Inc., Case IPR2015-00157, slip op. at 6–9
`(PTAB Apr. 30, 2015) (Paper 8); Iron Dome LLC v. CRFD Research, Inc.,
`Case IPR2015-00055, slip op. at 6–10 (PTAB Apr. 27, 2015) (Paper 10).
`The parties do not dispute these interpretations in their Patent Owner
`Response and Reply. We do not perceive any reason or evidence that
`compels any deviation from these interpretations. Accordingly, we adopt
`our previous analysis for purposes of this Decision. We also interpret one
`other limitation.
`
`
`
`
`
`8
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`2. Ordering of the “Specifying” Step3
`Although the parties do not address specifically how “specifying a
`second device” in claims 1 and 23 should be interpreted, the parties disagree
`as to whether the step must occur in a specific order with respect to the step
`of “discontinuing said session on said first device.” Patent Owner argues in
`its Response that Phan Helsinki, in describing the “pull mode” that is further
`explained in Phan San Jose, fails to disclose the “specifying” step because
`the user merely clicks “Suspend” to discontinue the session and then chooses
`a particular device on which to resume the session at a later time. PO Resp.
`16–31. At the hearing, Patent Owner argued that the “specifying” step must
`occur before the “discontinuing” step, and that it must be the user or the first
`device that performs the specifying, citing as support an embodiment
`described in the Specification of the ’233 patent. Tr. 21:1–23:18. Petitioner
`disagreed, arguing that nothing in the claim language itself requires the
`“specifying” step to occur before the “discontinuing” step. Reply 4–5;
`Tr. 18:1–22. We agree with Petitioner.
`To determine whether the steps of a method claim that do not
`otherwise recite an order must nonetheless be performed in a particular
`order, we first “look to the claim language to determine if, as a matter of
`logic or grammar, they must be performed in the order written.” Altiris, Inc.
`v. Symantec Corp., 318 F.3d 1363, 1369 (Fed. Cir. 2003). “If not, we next
`look to the rest of the specification to determine whether it ‘directly or
`
`
`3 In the final written decision in Case IPR2015-00055, we interpreted
`claim 1 not to require that the “specifying” step take place before the
`“discontinuing” step. Iron Dome LLC v. CRFD Research, Inc.,
`Case IPR2015-00055, slip op. at 8–10 (PTAB Apr. 22, 2016) (Paper 30).
`Our analysis herein is similar to that in Case IPR2015-00055.
`
`
`9
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`implicitly requires such a narrow construction.’” Id. at 1370 (citation and
`emphasis omitted); see also Mformation Techs., Inc. v. Research In Motion
`Ltd., 764 F.3d 1392, 1398–99 (Fed. Cir. 2014) (“a claim ‘requires an
`ordering of steps when the claim language, as a matter of logic or grammar,
`requires that the steps be performed in the order written, or the specification
`directly or implicitly requires’ an order of steps” (citation omitted)).
`Claims 1 and 23 require certain steps to be performed before others.
`For example, the “transmitting” step must take place “after said session is
`discontinued on said first device” (emphasis added). Likewise, “conducting
`a session with a first device” logically must take place before “discontinuing
`said session on said first device.” There is nothing in the language of the
`claims, however, expressly requiring “specifying a second device” to take
`place before “discontinuing said session on said first device” or requiring
`such an order as a matter of logic or grammar. See Altiris, 318 F.3d at
`1370–71 (concluding that the claim at issue required “several of the steps” to
`take place in order, but not the particular step argued by the plaintiff). The
`“discontinuing” step, as well as the subsequent “transmitting” step, do not
`even refer to the second device.
`Thus, we look to the Specification to determine whether it expressly
`or implicitly requires a particular order. The Specification discloses that
`“[t]he client software of the wireless/wired client devices, 120 and 125 may
`be . . . configured to provide a selection of devices that a transferring session
`may be redirected thereto,” and “[t]he selection of the redirected device may
`. . . be forwarded from the user of a wireless/wired client device, 120 and
`125 to the session server [145].” Ex. 1001, col. 4, ll. 53–61. Also, as shown
`in Figures 3A and 3B, session server 145 receives a “redirect or transfer
`
`
`
`
`10
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`command” from the first client device (step 305) before it begins
`intercepting messages destined for the first client device (step 310) and
`“access[es] the device profile of the selected second client (or redirected)
`device” (step 320). Id. at col. 7, l. 49–col. 8, l. 13. These portions of the
`Specification, however, describe only “exemplary” embodiments of the
`invention. Id. at col. 4, ll. 4–6, col. 7, ll. 46–49. They do not show,
`expressly or implicitly, that the “specifying” step of the claims must occur
`before the “discontinuing” step. Moreover, the Specification indicates the
`opposite, stating that “although the method of the present invention has been
`described by examples, the steps of the method may be performed in a
`different order than illustrated or simultaneously.” Id. at col. 9, ll. 22–25.
`Applying the broadest reasonable interpretation of the claims in light
`of the Specification, we do not interpret claims 1 and 23 to require that the
`“specifying” step take place before the “discontinuing” step.
`
`
`B. Grounds Based on Phan Helsinki and Phan San Jose
`Petitioner argues that claims 1, 4, 23, and 25 are anticipated by Phan
`Helsinki under 35 U.S.C. § 102(a), and that claims 4 and 25 are unpatentable
`over Phan Helsinki and Phan San Jose under 35 U.S.C. § 103(a), relying on
`the supporting testimony of W. Leo Hoarty. Pet. 40–56 (citing Ex. 1018).4
`We have reviewed the Petition, Patent Owner Response, and Reply, as well
`
`
`4 In numerous paragraphs of his Declaration, Mr. Hoarty repeats the
`testimony of Mark Claypool, Ph.D., from Case IPR2015-00259, states that
`he agrees with Dr. Claypool’s analysis and conclusions, and adopts them
`“as [his] own.” See, e.g., Ex. 1018 ¶¶ 43, 52, 55–64. Petitioner filed a copy
`of Dr. Claypool’s declaration from Case IPR2015-00259 in this proceeding
`as Exhibit 1003.
`
`
`
`11
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`as the evidence discussed in each of those papers, and are persuaded, by a
`preponderance of the evidence, that claims 1, 4, 23, and 25 are anticipated
`by Phan Helsinki, and that claims 4 and 25 are unpatentable over Phan
`Helsinki and Phan San Jose.
`
`
`1. Phan Helsinki
`Phan Helsinki describes a research project called the “Interactive
`Mobile Application Support for Heterogeneous Clients (iMASH),” which
`allows medical practitioners at a hospital to use different types of devices
`(e.g., desktop computers, PDAs) and “experience uninterrupted and
`seamless data access across multiple devices by performing application
`session handoff.” Ex. 1020, 7 (emphasis omitted). The system provides for
`session handoff by placing a set of middleware servers between the client
`devices and the application server, storing state data on the middleware
`servers for the user’s session on a first device (e.g., user preferences,
`URL history), and transferring the data to the second device upon session
`handoff. Id. at 8–10. Figure 1 of Phan Helsinki is reproduced below.
`
`
`
`
`12
`
`
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`Figure 1 depicts wired and wireless client devices, a “distributed set of
`middleware servers” that is “the source for all services for clients,” and an
`application server. Id. at 8. A client device “contacts only the local
`middleware server for all services,” and the middleware server “takes
`responsibility for getting the data from the right [application] servers, and
`makes necessary conversion to fit the clients’ needs.” Id. at 9. Figure 2 of
`Phan Helsinki is reproduced below.
`
`
`Figure 2 depicts functionality provided by the middleware server, such as
`user authentication and profiling, data caching, and presentation conversion
`(i.e., converting data for the particular client device requesting it). 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.” Id.
`Phan Helsinki also describes the “Middleware-Aware Remote Code”
`(MARC) on the client device that facilitates “session saving and
`
`
`
`
`13
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`restoration,” and the process by which a session is transferred using MARC
`and a web browser. Id. at 9–10. Specifically, Phan Helsinki describes the
`following steps:
`1. The user starts the client application and provides it
`with a unique user id.
`2. The MARC within the application discovers and
`contacts the middleware server using Jini and begins a new
`session using the user id. The last saved state, if it exists, is
`retrieved from the middleware server. This step uses Java
`[Remote Method Invocation (RMI)] to acquire the most
`recently saved bookmarks, history, and user preferences, all of
`which are stored on and transported from the middleware as
`serialised Java Objects.
`3. The returned data from the middleware is received by
`the MARC and then incorporated into the client before the
`user’s current interactive application session begins. Within
`Mozilla, the data is deserialised by the MARC and then read
`into Mozilla’s bookmark, history, and user preference
`dataspace. . . .
`4. As the user changes the current session state, the state
`is updated at the middleware server at the appropriate times.
`For example, whenever Mozilla flushes the bookmarks to disk,
`our MARC will also transmit this data to the middleware via
`RMI.
`
`5. When the user exits the session, the client updates the
`state at the middleware. Because Mozilla flushes all data upon
`exiting, our MARC likewise updates data on the middleware.
`Id. at 10.
`
`
`2. Phan San Jose
`Phan San Jose pertains to the same iMASH research project as Phan
`Helsinki, and explains how the system allows physicians and staff at a
`hospital to use different types of devices (e.g., desktop and laptop
`
`
`
`
`14
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`computers, display tablets) and “seamlessly move an application’s session
`from one machine to another machine” using the hospital’s “network as a
`conduit.” Ex. 1019, 5.
`Phan San Jose describes how the system could be used with a
`“Teaching File” Java applet that displays medical images and associated
`information, and allows users to create and modify instructional “teaching
`files.” Id. at 10. In the Teaching File implementation, when a user requests
`a teaching file, the application server (AS) sends the image file (stored in the
`system’s proprietary picture archiving and communication system (PACS)
`image format) to the middleware server (MWS). Id. at 10–11. The MWS
`then “performs the image assembly on behalf of the client, including the
`conversion of the proprietary PACS image to [a] Java Image and the
`manipulation of that image according to the teaching file state description.”
`Id. at 11. Phan San Jose describes two ways of performing the session
`handoff. Id. In the “pull” mode, “the user selects a ‘Suspend’ operation, 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.” Id. In the “push”
`mode, “the user can select the hostname of the target from a list.” Id.
`“When the handoff occurs, the MWS will contact a daemon running on the
`target machine to immediately launch the Teaching File applet and
`automatically retrieve the session state . . . [and the] applet on the first client
`terminates when the state is fully reinstantiated on the second client.” Id.
`
`
`
`
`15
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`
`Figure 5 of Phan San Jose is reproduced below.
`
`
`Figure 5 depicts the user interface of the Teaching File applet. Id. at 10. In
`the dropdown menu labeled “Target,” the user is able to choose “Suspend”
`(corresponding to the “pull” mode) or one of three hostnames to which the
`session may be transferred (corresponding to the “push” mode). Id. at
`10–11.
`
`
`3. Anticipation Ground (Claims 1, 4, 23, and 25)
`Petitioner has presented sufficient evidence showing that Phan
`Helsinki discloses every limitation of claims 1, 4, 23, and 25. For example,
`as to claim 1, Petitioner explains how a user conducts a session with a “first
`device” (e.g., an office desktop computer), then discontinues the session on
`the “first device” by suspending the session, causing the user’s session
`history (e.g., bookmark list, history file, user preferences) to be transmitted
`
`
`16
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`from the computer to a “session transfer module” (i.e., the middleware
`server), and chooses to reinstantiate the session on a “second device”
`(e.g., a PDA) using the previously saved session history. Pet. 40–48 (citing
`Ex. 1020, 8–10, Ex. 1018 ¶¶ 84, 85, 87–90).
`Patent Owner makes two arguments. First, Patent Owner argues that
`“[t]o better understand Phan Helsinki, it is useful to first examine the
`teachings of Phan San Jose,” and Phan San Jose’s description of the “push”
`mode does not disclose “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,” as recited in claim 1. PO Resp. 17–19
`(emphasis added). Patent Owner cites as support testimony from Prasant
`Mohapatra, Ph.D., which largely repeats Patent Owner’s arguments in its
`Response. See id. (citing Ex. 2001 ¶¶ 27, 31). We do not see the relevance
`of Phan San Jose to Petitioner’s asserted anticipation ground, however,
`because the ground is based on Phan Helsinki alone. See Corning Glass
`Works v. Sumitomo Elec. U.S.A., Inc., 868 F.2d 1251, 1255–56 (Fed. Cir.
`1989) (“Anticipation requires that every limitation of the claim in issue be
`disclosed, either expressly or under principles of inherency, in a single prior
`art reference.”). The parties agree that Phan Helsinki and Phan San Jose
`both describe a “pull” mode, which is different from the “push” mode that
`also is disclosed in Phan San Jose. See PO Resp. 12, 17, 22–23, 29;
`Ex. 2004, 67:23–68:5 (Petitioner’s declarant, Mr. Hoarty, testifying that he
`“believe[s] that the skilled person would perceive steps 1 through 3 [in Phan
`Helsinki] to be a pull mechanism as defined by Phan San Jose”). Patent
`Owner agreed at the hearing that Phan Helsinki, in describing the “pull”
`mode, discloses the “transmitting” step of claim 1. Tr. 24:6–15. Based on
`
`
`
`
`17
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`the record presented during trial, we are persuaded that Phan Helsinki
`discloses the “transmitting” step recited in claim 1.
`Second, Patent Owner argues that Phan Helsinki (as further explained
`by Phan San Jose) does not disclose “specifying a second device.” PO Resp.
`8–12, 16–24 (citing Ex. 2001 ¶¶ 32–35). Patent Owner contends that in the
`“pull” mode described in the references, the user selects a “Suspend”
`operation without specifying a device on which to resume the session. Id. at
`19–24. Selecting “Suspend” causes the session history to be sent to the
`middleware server, then, later, if the “user wishes to resume a session [on a
`different device], the session state is ‘pulled’ from the [middleware server].”
`Id. According to Patent Owner, there is no disclosure in the references of
`the second device on which the session will be resumed being “specified.”
`Id. We disagree.
`As an initial matter, although we agree that Phan Helsinki and Phan
`San Jose pertain generally to the same system, Petitioner’s anticipation
`ground is based on Phan Helsinki alone. Thus, we evaluate only whether
`Phan Helsinki discloses, expressly or inherently, the limitations of claim 1.
`To the extent Patent Owner’s argument is that Phan Helsinki does not
`specify a second device because the user does not identify a second device
`before choosing to suspend the session on the first device, we are not
`persuaded. As explained above, we do not agree with Patent Owner that the
`claim requires the “specifying” step to take place before the “discontinuing”
`step. See supra Section II.A.2. In other words, there is nothing preventing
`the specification of the second device from occurring after the user chooses
`to suspend the session on the first device, discontinuing the session and
`causing the session history to be transmitted to the middleware server. The
`
`
`
`
`18
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`specification of the second device may take place at a later time, such as
`when the user chooses to resume the session on a different device.
`To the extent Patent Owner’s argument is that Phan Helsinki does not
`specify a second device at all, we also are not persuaded. Petitioner
`contends that the second device is specified when the user “logs on to or
`starts a new device to continue the session.” See Pet. 43–45; Reply 2–5.
`The system described in Phan Helsinki “enable[s] a user to experience
`uninterrupted and seamless data access across multiple devices by
`performing application session handoff,” i.e., from one client device (e.g.,
`desktop computer) to another (e.g., PDA). Ex. 1020, 7–9 (emphasis
`omitted). “When a user changes devices or spawns a new branch of a
`session to a new device, the middleware server authenticates the user on the
`new device.” Id. at 9. Specifically, “[w]hen the user exits the session [on a
`first client device], the client updates the state at the middleware.” Id. at 10.
`Later, the user chooses a second client device on which to resume the
`session, “[t]he user starts the client application [on the second client device]
`and provides it with a unique user id,” the second client device retrieves the
`session state from the middleware server, and the session continues. Id.
`Petitioner’s contention that the second device in Phan Helsinki is
`specified when the user takes action on the second device to resume the
`session (e.g., logging on or starting the new device) is persuasive. See
`Pet. 43–45; Reply 2–5. Claim 1 is broadly worded. It does not specify who
`or what does the specifying, or to whom or what the second device is
`specified. See Tr. 22:14–19 (acknowledging that “the claim language does
`not state explicitly who does the specifying”). The claim only requires that
`the second device be specified. Phan Helsinki discloses that the user
`
`
`
`
`19
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`chooses a device on which he or she wants to resume the session and takes
`action on that device to do so, which causes the client application on the
`second device to communicate with the middleware server to retrieve the
`session state. We are persuaded that this constitutes “specifying” the second
`device. Indeed, Patent Owner’s declarant, Dr. Mohapatra, acknowledged
`that in the “pull” mode of Phan Helsinki and Phan San Jose, the “[s]econd
`device is specified at some point in time.” Ex. 1027, 67:19–24.
`Dr. Mohapatra appears to disagree that Phan Helsinki discloses the
`“specifying” step only to the extent that “specifying” the second device must
`occur before “discontinuation” of the session on the first device. Id. at
`42:9–17. As explained above, however, we do not agree with Patent Owner
`that the claim requires such ordering. See supra Section II.A.2.
`Patent Owner argued at the hearing that at the time of resuming the
`session on the second device, the middleware server only knows the identity
`of the user (via the user logging on and providing a unique user ID to the
`second device), but identifying a user is not the same as specifying a device.
`Tr. 21:10–14. Patent Owner further argued that the middleware server may
`not know the address (e.g., IP address) to which to send the session state
`because the device may be behind a firewall. Id. at 23:8–18.
`Patent Owner’s arguments are not persuasive. First, as explained
`above, we do not see anything in the claim that would prohibit the user from
`specifying a second device by taking action on that particular device (as
`opposed to a different device) to resume the session. Second, even if the
`second device had to be specified to the middleware server, the middleware
`server in Phan Helsinki must receive enough information from the second
`device to be able to distinguish the chosen second device from other
`
`
`
`
`20
`
`
`
`
`
`IPR2015-00627
`Patent 7,191,233 B2
`
`potential devices, even if only by virtue of the second device’s association
`with a user account; otherwise, the middleware server would not be able to
`transmit the session history to the second device. See PO Resp. 22
`(acknowledging that the client devices involved in the session communicate
`with the middleware server); Ex. 1020, 8–10 (describing how the
`middleware server is able to communicate with both the first client device
`and the second client