throbber
Trials@uspto.gov
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket