`571-272-7822
`
`Paper 10
`Entered: April 27, 2015
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`IRON DOME LLC,
`Petitioner,
`
`v.
`
`CRFD RESEARCH, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00055
`Patent 7,191,233 B2
`
`
`Before JUSTIN T. ARBES, THOMAS L. GIANNETTI, and
`CHARLES J. BOUDREAU, Administrative Patent Judges.
`
`ARBES, Administrative Patent Judge.
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`Petitioner Iron Dome LLC filed a Petition (Paper 1, “Pet.”) to institute
`an inter partes review of claims 1–6, 8–11, 13–15, 17, 18, 20, and 34 of
`U.S. Patent No. 7,191,233 B2 (Ex. 1001, “the ’233 patent”) pursuant to
`35 U.S.C. §§ 311–19. Patent Owner CRFD Research, Inc. filed a
`Preliminary Response (Paper 8, “Prelim. Resp.”). We have jurisdiction
`under 35 U.S.C. § 314. Pursuant to 35 U.S.C. § 314(a), the Director may
`not authorize an inter partes review unless the information in the petition
`and preliminary response “shows that there is a reasonable likelihood that
`the petitioner would prevail with respect to at least 1 of the claims
`challenged in the petition.” For the reasons that follow, we have decided to
`institute an inter partes review as to claims 1, 4–6, and 8–11 of the ’233
`patent on certain grounds of unpatentability.
`
`
`I. BACKGROUND
`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
`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 switch to a device
`
`
`1 The ’233 patent also is the subject of Cases IPR2015-00157,
`IPR2015-00259, and IPR2015-00627.
`
`
`
`2
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`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”
`were inadequate due to the history of the original session being lost and the
`time delay in logging off and reinitiating. Id. at col. 1, ll. 59–66.
`Figure 1 of the ’233 patent is reproduced below.
`
`
`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
`
`
`
`3
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`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 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.
`
`
`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;
`
`
`
`4
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`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. The Prior Art
`Petitioner relies on the following prior art:
`Thomas Phan et al., “A New TWIST on Mobile
`Computing: Two-Way
`Interactive
`Session Transfer,”
`Proceedings of the Second IEEE Workshop on Internet
`Applications (WIAPP 2001) (Ex. 1002, “Phan San Jose”); and
`Thomas Phan et al., “Handoff of Application Sessions
`Across Time and Space,” IEEE International Conference on
`Communications (ICC 2001) (Ex. 1003, “Phan Helsinki”).2
`
`D. The Asserted Grounds
`Petitioner challenges claims 1–6, 8–11, 13–15, 17, 18, 20, and 34 of
`the ’233 patent on the following grounds:
`
`
`
`
`2 Petitioner argues that Phan San Jose was printed in a book of articles
`presented at a symposium in San Jose, California on July 23–24, 2001, and
`that Phan Helsinki was printed in a book of articles presented at a
`symposium in Helsinki, Finland on June 11–14, 2001. Pet. 3–4. The copies
`of the references submitted by Petitioner include Library of Congress date
`stamps of August 28, 2001, and July 31, 2001, respectively. Thus, based on
`the current record, we are persuaded that the articles are prior art to the ’233
`patent under 35 U.S.C. § 102(a).
`
`
`
`
`5
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`Reference(s)
`
`Basis
`
`Claims Challenged
`
`Phan San Jose
`
`35 U.S.C. § 102(a)
`
`1, 13, and 34
`
`Phan San Jose
`
`35 U.S.C. § 103(a)
`
`2, 3, and 143
`
`35 U.S.C. § 103(a)
`
`4–6, 8–11, 15, 17, 18,
`and 20
`
`Phan San Jose
`and Phan
`Helsinki
`
`
`
`E. 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 Office Patent Trial Practice Guide,
`77 Fed. Reg. 48,756, 48,766 (Aug. 14, 2012); In re Cuozzo Speed Techs.,
`LLC, 778 F.3d 1271, 1278–82 (Fed. Cir. 2015). 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 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
`
`
`3 Petitioner also states in its “Grounds for Challenge” that claim 35 would
`have been obvious over Phan San Jose, but does not list claim 35 in other
`locations in the Petition and does not include any substantive analysis of the
`claim. See Pet. 1, 7; Prelim. Resp. 28. Thus, we assume that the listing of
`claim 35 was a typographical error.
`
`
`
`6
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`quotation marks omitted). However, a patentee may rebut this presumption
`by acting as his 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). For purposes of this
`Decision, we interpret three claim limitations as follows.
`
`
`1. “Modality” (Claims 6 and 11)
`Petitioner argues that the term “modality” should be interpreted to
`mean “a user interface that interacts by graphics, text, or voice.” Pet. 6. As
`support for its proposed interpretation, Petitioner cites the following portion
`of the Specification of the ’233 patent:
`[A] client may be configured to have a preferred mode of
`interaction, i.e., modality. For instance, a client may be
`configured to provide a graphical manner, e.g., a graphical user
`interface, to redirect or transfer command for transferring a
`current session of client to another device without discontinuing
`the session. Alternatively, a client may be configured to
`provide a command line prompt for a user to input the redirect
`command into the client. Alternatively, a client may be
`configured to provide a voice command to input the redirect
`command into the client.
`Ex. 1001, col. 4, ll. 41–50 (emphasis added); see Pet. 6. Petitioner contends
`that “[e]xamples of ways in which the device may interact with the user
`include [a] graphical user interface, voice command, or command line
`prompt.” Pet. 6. Patent Owner argues that Petitioner’s proposed
`interpretation does not reflect how the term would be understood by a person
`of ordinary skill in the art, but does not propose a different interpretation.
`Prelim. Resp. 19–20.
`
`
`
`7
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`We conclude that the use of “i.e.” in the Specification portion cited
`above represents an express definition for the term “modality.” See
`Ex. 1001, col. 4, ll. 41–42; Interval Licensing LLC v. AOL, Inc., 766 F.3d
`1364, 1373–74 (Fed. Cir. 2014) (distinguishing the use of “i.e.” to define a
`term from the use of “e.g.” to provide examples). Further, we are not
`persuaded that the description of graphical, textual, and voice methods of
`interaction is limiting on the claim term, as Petitioner’s proposed
`interpretation would suggest. See Ex. 1001, col. 4, ll. 50–52 (“It is to be
`understood that this invention is not limited to these modes of user
`interaction with the client application.”). On this record, applying the
`broadest reasonable interpretation of the claims in light of the Specification,
`we interpret “modality” to mean a preferred mode of interaction.
`
`
`2. “Device Profile” (Claims 4, 8, 9, 15, 17, 18, and 20)
`Petitioner argues that the term “device profile” should be interpreted
`to mean “at least the data format used by the second device.” Pet. 6.
`Petitioner contends that when a session is transferred to the second device,
`the session data is converted into a format compatible with “parameters such
`as data format, modality, etc.” of the second device. Id. (citing Ex. 1001,
`col. 3, ll. 30–36). Again, Patent Owner disputes Petitioner’s proposed
`interpretation generally, but does not provide its own proposed
`interpretation. Prelim. Resp. 19–20.
`The Specification of the ’233 patent describes a device profile for a
`particular device being retrieved from a database and used to “transfer
`information in a data-format and/or modality compatible with the client
`device.” Ex. 1001, col. 6, ll. 46–58, col. 7, ll. 12–16, col. 8, ll. 4–13.
`
`
`
`8
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`Specifically, session transfer module 220 of session server 145 “reformat[s]
`the session history to conform to the [compatible] data format and/or
`modality . . . according to the redirected device profile in response to the
`receipt of the session history,” and “transmit[s] the reformatted session
`history to the redirected device.” Id. at col. 7, ll. 33–45 (emphasis added).
`Thus, the device profile pertains to the operation of the device, such as the
`device’s modality (e.g., graphical interaction) or data format (e.g., HTML
`for web browsers). See id. at col. 8, ll. 7–13. This reading is consistent with
`the surrounding language of the claims. For example, claim 4 recites
`restructuring session data to conform to the “device profile” of the second
`device, and claims 5 and 6 recite that the restructured session data conforms
`to a “data format” and “modality,” respectively, of the second device. On
`this record, applying the broadest reasonable interpretation of the claims in
`light of the Specification, we interpret “device profile” to mean information
`pertaining to the operation of a device, such as the data format or modality
`of the device.
`
`
`3. “In Response to . . . Activation of Said Second Device”
`(Claims 2, 8, 9, 14, and 17)
`Petitioner argues that the phrase “in response to . . . activation of said
`second device” should be interpreted to mean “any action by the user at the
`receiving device to trigger retrieval of the transferred session, such as
`logging-on to the receiving device, powering-on the receiving device,
`awakening the receiving device from sleep mode, or launching the relevant
`application program.” Pet. 5–6. In support, Petitioner cites the
`Specification’s disclosure of “push[ing] the transferring session to the
`
`
`
`9
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`redirected device in response to an activation (e.g., log-on) of the redirected
`device by the user.” Ex. 1001, col. 7, ll. 16–19; see Pet. 5. Again, Patent
`Owner disputes Petitioner’s proposed interpretation generally, but does not
`provide its own proposed interpretation. Prelim. Resp. 17, 19–20.
`We agree in part with Petitioner’s proposed interpretation. The
`Specification describes different actions performed in response to the
`activation of the device to which a session is to be transferred, and indicates
`that logging on is an example of such activation. See Ex. 1001, Abstract,
`col. 3, ll. 36–42, col. 7, ll. 16–19. The Specification also describes the use of
`an “activation timer . . . to provide a time limit for the user to log on to the
`redirected device.” See id., col. 8, ll. 20–58, Figs. 3A–B. Petitioner’s
`proposed interpretation includes other actions, such as awakening from
`“sleep mode,” that do not appear in the Specification or in any other
`evidence cited by Petitioner. On this record, applying the broadest
`reasonable interpretation of the claims in light of the Specification, we
`interpret “in response to . . . activation of said second device” to mean in
`response to the second device being made active, such as by a user logging
`on to the second device.
`
`
`II. DISCUSSION
`A. Anticipation Ground Based on Phan San Jose
`Petitioner contends that independent claims 1, 13, and 34 are
`anticipated by Phan San Jose under 35 U.S.C. § 102(a). Pet. 9–11, 21–23,
`29–31. We are persuaded that Petitioner has established a reasonable
`likelihood of prevailing on its asserted ground only as to claim 1 for the
`reasons explained below.
`
`
`
`10
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`1. Phan San Jose
`Phan San Jose describes a research project called the “Interactive
`Mobile Application Support for Heterogeneous Client (iMASH),” which
`allows physicians and staff at a hospital to use different types of devices
`(e.g., desktop and laptop 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. 1002, 5. The system provides for
`“Two-Way Interactive Session Transfer (TWIST)” 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., textual annotations, user preferences, URL history), and
`transferring the data to the second device upon session handoff. Id. at 6–7.
`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 image format called “PACS”) 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 “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
`
`
`
`11
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`the hostname of the target from a list. 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.
`
`
`2. Claim 1
`Petitioner explains in its Petition how Phan San Jose discloses each of
`the limitations of claim 1. Pet. 9–11. For example, Petitioner explains how
`a physician conducts a session with a “first device” (e.g., a PDA), then
`discontinues the session on the “first device” upon deciding to suspend the
`session and reinstantiate it on a “second device” (e.g., a desktop computer),
`such that the physician’s session history (e.g., user preferences, URL
`history) is available for use on the “second device.” Id. (citing Ex. 1002,
`5–7, 10). Upon review of the Petition, we are persuaded that Petitioner has
`shown a reasonable likelihood of prevailing.
`Patent Owner makes three arguments. First, Patent Owner argues that
`Petitioner fails to explain how Phan San Jose discloses “specifying a second
`device.” Prelim. Resp. 4–5. Petitioner contends that Figure 2 shows how a
`physician may move from his PDA (“first device”) to a desktop computer
`(“second device”). Pet. 10.
`
`
`
`12
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`Figures 1–3 of Phan San Jose are reproduced below.
`
`
`
`As shown in the figures, the physician conducts an “application session” on
`his PDA in Figure 1, then on his desktop computer “[a]fter handoff” of the
`session to the new device in Figure 2, and then on his laptop computer
`“[a]fter another handoff” of the session in Figure 3. Ex. 1002, 6. Petitioner
`has shown sufficiently that a “second device” to which the session is to be
`transferred is specified in Phan San Jose.
`Second, Patent Owner argues that Phan San Jose 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.” Prelim. Resp. 6–8, 12–14. Patent Owner contends that in Phan San
`Jose, the Java applet on the first device only terminates after the second
`device has received session data from the MWS and resumed the session,
`whereas the claim requires the session to be discontinued on the first device
`prior to the session history being transmitted. Id. at 13. In support of its
`argument, Patent Owner cites the statement in Phan San Jose that “[t]he
`applet on the first client terminates when the state is fully reinstantiated on
`the second client.” Id. (citing Ex. 1002, 11). This statement, however,
`pertains only to the “push” mode of operation. Ex. 1002, 11. In the “pull”
`mode, by contrast, “the user selects a ‘Suspend’ operation, his session shall
`
`
`
`13
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`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.; see also id. at 7 (“[w]hen the user
`decides to move his session he activates the handoff mechanism from his
`client software on C1 to . . . suspend his session (to be later reinstantiated
`explicitly from another machine)”). Thus, although we agree with Patent
`Owner as to the “push” mode of Phan San Jose, we are persuaded based on
`the current record that in the “pull” mode, the session on the first device is
`discontinued prior to transmitting the session history. See Pet. 10, 12 (citing
`the “suspend,” or “pull,” mode and the “push” mode).
`Third, Patent Owner argues that Phan San Jose does not disclose
`transmitting a session history from the first device to a session transfer
`module and “resuming said session on said second device with said session
`history” (emphasis added). Prelim. Resp. 8–12. Patent Owner contends that
`the data sent from the first device in Phan San Jose is not the same data that
`are used to resume the session, citing Figure 4. Id. at 11–12.
`
`
`
`14
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`Figure 4 of Phan San Jose is reproduced below.
`
`
`Figure 4 depicts the steps of a session handoff from client C1 to client C2,
`which Phan San Jose describes as follows:
`As the session begins, (1) the AS returns data object o to the
`MWS, which is immediately cached. (2) The MWS filters o to
`suit the limitations of C1 by applying the filter function f1 to o;
`client C1 thus receives f1(o) from the MWS. (3) The user at C1
`proceeds to modify the data by applying an operation gl to the
`object, resulting in g1·f1(0). At this point the user wishes to
`perform application session handoff to another machine.
`Because this is a two-way interactive transfer, the result of the
`operation gl at C1 must be made visible to C2 when the session
`is reinstantiated. The modified form of the data must thus be
`made available at the MWS so that it can be sent to C2. We
`
`
`
`15
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`
`note for now that (4) upon handoff, only g1 is sent back to the
`MWS. . . . (5) The MWS needs g1·f1(o), so it takes the o that
`was cached, the f1 that was known a priori, and the g1 delivered
`from C1. (6) The result is passed through f2, the content filter
`for C2. (7) Finally, f2·g1·f1(o) is delivered to C2.
`Ex. 1002, 8.
`Patent Owner argues that because client C1 sends g1 to the MWS, and
`client C2 receives f2·g1·f1(o), client C2 cannot resume the session with “only”
`g1. Prelim. Resp. 11–12. This argument is not persuasive, however, because
`claim 1 does not require that the session be resumed with “only” the session
`history transmitted from the first device. The operation gl applied by client
`C1 to the object is included in the f2·g1·f1(o) data delivered to client C2,
`which uses the data to resume the session. See Ex. 1002, 8. Further, Patent
`Owner does not address other statements in Phan San Jose cited by
`Petitioner and indicating that a session history for the first device is used to
`resume the session on the second device. See Ex. 1002, 6–7 (“URL history”
`transferred as a result of the session transfer), 10 (“To the user, the result of
`our implementation is that he is now able to handoff his session from one
`platform to another with little to no interruption in his work. Once on the
`second platform, his session was as he left it.”); Pet. 10–11. Based on the
`current record, Petitioner’s analysis of the “resuming” step in claim 1, as
`well as the other steps, is sufficient to demonstrate a reasonable likelihood of
`prevailing on its assertion that claim 1 is anticipated by Phan San Jose.
`
`
`3. Claims 13 and 34
`Similar to claim 1, claims 13 and 34 recite transmitting the session
`history from the first device “after said session is discontinued on said first
`device.” Claims 13 and 34, however, recite the additional limitation that the
`
`
`
`16
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`“session server is configured to transfer a session from said first device to
`said second device in response to a redirect command from said first
`device.” In its analysis of claims 13 and 34, Petitioner does not identify
`what it believes to be a “redirect command” in Phan San Jose, or explain
`how a session is transferred to a second device “in response to a redirect
`command” from the first device. See Pet. 23, 30–31; 37 C.F.R.
`§ 42.104(b)(4) (a petition must identify “[h]ow the construed claim is
`unpatentable under the statutory grounds identified” and “where each
`element of the claim is found in the prior art patents or printed publications
`relied upon”). Indeed, in the “pull” mode of Phan San Jose, the session is
`reinstantiated on the second device “at a later time” when “the [second
`device] explicitly retrieves the session state from the MWS.” Ex. 1002, 11.
`Thus, Petitioner has not demonstrated a reasonable likelihood of prevailing
`on its assertion that claims 13 and 34 are anticipated by Phan San Jose.
`
`
`B. Obviousness Ground Based on Phan San Jose
`Petitioner contends that claims 2, 3, and 14 are unpatentable over
`Phan San Jose under 35 U.S.C. § 103(a). Pet. 11–14, 24. We are not
`persuaded that Petitioner has established a reasonable likelihood of
`prevailing on the asserted ground for the reasons explained below.
`Claims 2 and 3 recite pushing the session and a notification,
`respectively, to the second device “in response to said discontinuing” of the
`session on the first device. Petitioner relies on the “push” mode of Phan San
`Jose for both limitations. Pet. 11–14. With respect to claim 2, Petitioner
`argues that when performing a “push” session handoff, the user is given the
`ability to select an alternate device to which the session will be transferred,
`
`
`
`17
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`but “it would [have been] obvious to skip this selection step and proceed to
`the step of ‘immediately launch[ing] the Teaching File applet [on the second
`device] and automatically retriev[ing] the session state.’” Id. at 12 (citing
`Ex. 1002, 11). With respect to claim 3, Petitioner similarly argues that
`session data is retrieved automatically in the “push” mode, but “it would
`have been a simple matter of accommodating user preference to retrieve the
`session in a non-automatic manner by first asking the user if he wishes to
`retrieve the prior session” by sending a notification. Id. at 13–14. As
`explained above, we are persuaded based on the current record that only the
`“pull” mode of Phan San Jose, not the “push” mode, meets the limitations of
`claim 1. Because the session handoff in Phan San Jose occurs in one mode
`or the other, and Petitioner has not explained any combination of the two
`that would have been obvious to a person of ordinary skill in the art,
`Petitioner’s analysis of the “push” mode with respect to claims 2 and 3,
`which depend from claim 1, is insufficient to establish a reasonable
`likelihood of prevailing.
`Claim 14 depends from claim 13. Petitioner does not provide any
`additional analysis as to why the “in response to a redirect command”
`limitation of claim 13 is taught or suggested by Phan San Jose. See supra
`Section II.A.3; Pet. 24. Thus, Petitioner has not demonstrated a reasonable
`likelihood of prevailing on its assertion that claims 2, 3, and 14 are
`unpatentable over Phan San Jose.
`
`C. Obviousness Ground Based on Phan San Jose and Phan Helsinki
`Petitioner contends that claims 4–6, 8–11, 15, 17, 18, and 20 are
`unpatentable over Phan San Jose and Phan Helsinki under 35 U.S.C.
`
`
`
`18
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`§ 103(a). Pet. 14–21, 24–29. We are persuaded that Petitioner has
`established a reasonable likelihood of prevailing on the asserted ground only
`as to claims 4–6 and 8–11 for the reasons explained below.
`
`
`1. Phan Helsinki
`Phan Helsinki pertains to the same iMASH research project as Phan
`San Jose, and describes the architecture and operation of the system in
`additional detail. Ex. 1003, 7. For example, Phan Helsinki explains that the
`“[m]iddleware servers fetch data based on user requests (or pre-fetch data
`based on prediction of [a] user’s near-future need) and perform conversion
`as needed,” and “[w]hen 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. at 9. Phan Helsinki also describes the
`“Middleware-Aware Remote Code” (MARC) on the client device that
`facilitates “session saving and restoration,” and the process by which a
`session is transferred using MARC and a web browser. Id. at 9–10.
`
`
`2. Claims 4–6 and 8–11
`Claims 4–6 recite restructuring “said session data”4 to conform to a
`“device profile,” “data format,” and “modality,” respectively, of the second
`
`
`4 Claim 1 refers to a “session history” rather than “session data.” Based on
`how the terms are used in the claims, and how “session history” is used in
`the Specification, we conclude that a person of ordinary skill in the art
`would understand the terms to refer to the same thing. See, e.g., claims 1
`(“resuming said session on said second device with said session history”),
`4 (“restructuring said session data to conform with said device profile of said
`
`
`
`19
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`device. Petitioner contends that Phan San Jose and Phan Helsinki “together
`describe the operation, architecture, and capabilities of the [iMASH]
`platform developed by the Thomas Phan group at UCLA,” and Phan
`Helsinki “provides additional information about how the [iMASH] platform
`works.” Pet. 15. Petitioner cites portions of Phan Helsinki for the additional
`limitations of claims 4–6 and explains why the claims allegedly would have
`been obvious. Id. at 14–17. Patent Owner does not make any arguments
`separate from those presented with respect to parent claim 1. See Prelim.
`Resp. 28–33.
`Similarly, claims 8 and 9 recite reformatting the “session history” to
`conform to a “device profile” of the second device, and “transmitting [the]
`reformatted session history of said session in response to said activation of
`said second device.” Claims 10 and 11 recite that the formatted session
`history conforms to a “data format” and “modality,” respectively, of the
`second device. Again, Petitioner cites portions of Phan Helsinki for the
`additional limitations of claims 8–11 and explains why the claims allegedly
`would have been obvious, and Patent Owner does not make any arguments
`separate from those presented with respect to parent claim 1. See Pet.
`17–21; Prelim. Resp. 28–33.
`On this record, and based on our interpretations of “device profile,”
`“modality,” and “in response to . . . activation of said second device” above,
`see supra Section I.E.1–3, Petitioner has demonstrated a reasonable
`
`
`second device”), 8 (“reformatting said session history of said session to
`conform with said device profile of said second device”). The parties,
`however, are encouraged to address the scope and treatment of claims 4–6 in
`their papers during trial.
`
`
`
`20
`
`
`
`IPR2015-00055
`Patent 7,191,233 B2
`
`likelihood of prevailing on its assertion that claims 4–6 and 8–11 are
`unpatentable over Phan San Jose and Phan Helsinki.
`
`
`3. Claims 15, 17, 18, and 20
`Claims 15, 17, 18, and 20 depend, directly or indirectly, from claim
`13, and Petitioner does not provide any additional analysis as to why the
`“in response to a redirect command” limitation of claim 13 is taught or
`suggested by Phan San Jose and/or Phan Helsinki. See supra Section II.A.3;
`Pet. 24–29. Thus, Petitioner has not demonstrated a reasonable likelihood of
`prevailing on its assertion that claims 15, 17, 18, and 20 are unpatentable
`over Phan San Jose and Phan Helsinki.
`
`
`D. Conclusion
`We conclude that Petitioner has demonstrated a reasonable likelihood
`of prevailing with respect to at least one claim of the ’233 patent challenged
`in the Petition. The Board, however, has not made a final determ