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

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