Petition for Inter Partes Review of

Transcription

1 United States Patent & Trademark Office Patent Trial & Appeal Board IRON DOME LLC Petitioner v. CRFD RESEARCH, INC. Patent Owner Petition for Inter Partes Review of Patent No. 7,191,233 (to Michael Miller) Titled: System for Automated, Mid-Session, User-Directed, Device-to-Device Issue date: March 13, 2007 For Paralegal: Number of Claims Challenged = 17 Power of Attorney enclosed Fee paid online by credit card Contact: Steven Yu Phone: syu@irondome.com

2 Table of Contents I. Introductory Matters A. Relief Requested B. Grounds for Standing C. Mandatory Notices II. Prior Art References A. The claims have an effective filing date of September 17, B. List of Prior Art III. Technical Background & Claim Construction A. Technical Background of the Challenged Patent B. Claim Construction IV. Grounds for Challenge Independent Claim Claim Claim Claim Claim Claim Claim Claim Claim Claim Independent Claim Claim Claim Claim Claim Claim ii

3 Independent Claim iii

4 Exhibit List Exh U.S. Patent No. 7,191,233 ( challenged patent ) Exh Thomas Phan et al., A New TWIST on Mobile Computing: Two-Way Interactive Session Transfer in the Proceedings of the Second IEEE Workshop on Internet Applications (WIAPP 2001). IEEE Computer Society Selected pages: Table of Contents, pp ( Phan San Jose or San Jose ) Exh Thomas Phan et al., Handoff of Application Sessions Across Time and Space in volume 5 of the IEEE International Conference on Communications (ICC 2001). Institute of Electrical & Electronic Engineers Selected pages: Table of Contents, pp ( Phan Helsinki or Helsinki ) Citation Form Used Reference to supporting documents indicated Citations to U.S. Patents are shown as [column number : line numbers]. Citations to line-numbered documents are shown as [page number : line numbers]. Claim terms are distinguished from other text by underlining. iv

5 I. Introductory Matters Iron Dome LLC ( Petitioner ) petitions for Inter Partes Review ( IPR ) of U.S. Patent No. 7,191,233 ( challenged 1001), which is owned by CRFD Research, Inc. A. Relief Requested Petitioner requests cancellation of claims 1-6, 8-11, 13-15, 17, 18, 20, and 34 (total of 17 claims) of the challenged patent for anticipation and/or obviousness under 35 U.S.C. 102 and 103. B. Grounds for Standing Petitioner certifies that the challenged patent is available for IPR and that Petitioner is not barred or estopped from requesting an IPR challenging the patent claims on the grounds identified in this petition. C. Mandatory Notices Real Parties-in-Interest: IRON DOME LLC, a Virginia limited liability company, which is a wholly-owned subsidiary of ROZMED LLC, a Virginia limited liability company, are the real parties-in-interest. Individual Steven S. Yu, who is the principal of IRON DOME LLC, managing member of ROZMED LLC, and lead counsel on this petition, declares that there are no other parties that are funding this IPR, nor participating in any manner in this IPR; and further that this statement is being made with the knowledge that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States - 1 -

6 Code. Related Matters: The challenged patent has been asserted by the patent owner in litigation against Amazon, Netflix, Spotify, AT&T, Comcast, and other defendants alleging infringement by streaming video devices, streaming music devices, and homenetworked digital video recorders (DVR) that allow the user to pause a recorded show and resume viewing in another room. The patent owner CRFD Research, Inc. filed the following civil actions in the U.S. District Court for Delaware: Jan. 17, 2014 Mar. 7, :14-cv through and against defendants Cablevision Systems Corp., Time Warner Cable Inc., Comcast Corp., Dish Network Corp., AT&T Inc., DirecTV, and Cox Communications Inc. 1:14-cv through against Hulu LLC, Netflix Inc., Spotify USA Inc., Amazon.com Inc., and Verizon Communications Inc. Individual Steven S. Yu, who is the principal of IRON DOME LLC, managing member of ROZMED LLC, and lead counsel on this petition, declares that Petitioner is not a party to any of these civil actions, nor has Petitioner been given or taken any direct financial interest relating to the outcome of these civil actions; and further that this statement is being made with the knowledge that willful false statements and the like so made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the United States Code. Electronic Service: Petitioner consents to service by at: syu@irondome.com

7 Lead Counsel Steven S. Yu (Reg. No. 58,776) IRON DOME LLC P.O. Box Gaithersburg, MD Tel: Back-Up Counsel Loree J. Kim (Reg. No. 36,154) IRON DOME LLC P.O. Box Gaithersburg, MD Tel: II. Prior Art References A. The claims have an effective filing date of September 17, The challenged patent was granted from application Serial No. 09/953,408 filed on September 17, This application did not claim priority to any prior-filed applications. Accordingly, the earliest possible effective filing date for the claims of the challenged patent is September 17, B. List of Prior Art The prior art publications referenced herein are as follows. 1. Thomas Phan et al., A New TWIST on Mobile Computing: Two-Way Interactive Session Transfer in the Proceedings of the Second IEEE Workshop on Internet Applications (WIAPP 2001). IEEE Computer Society 2000 ( Phan San Jose or San 1002) 1 2. Thomas Phan et al., Handoff of Application Sessions Across Time and Space in volume 5 of the IEEE International Conference on Communications (ICC 2001). Institute of Electrical & Electronic Engineers 2001 ( Phan 1 Phan San Jose was printed in a book containing a collection of articles presented at a symposium proceeding in San Jose, California on July 23-24, The copy held by the Library of Congress in Washington, D.C. is date-stamped August 28, Therefore, Phan San Jose is prior art under 35 U.S.C 102(a)

8 Helsinki or 1003) 2 Neither of the above publications were cited in the original prosecution of the challenged patent. III. Technical Background & Claim Construction A. Technical Background of the Challenged Patent The challenged patent (Exh. 1001) relates to a method of transferring sessions between a user s networked devices, such as transferring a user s web browsing session from his desktop machine to his mobile device. FIG. 1 shows a communication network 100 with both wireless clients 120 (connected to a wireless network 130) and wired clients 125 (connected to a wired network Both the wireless network 130 and the wired network 135 are part of an overall network An application server 140 operates on the network 112 and provides various application services 105 such as instant messaging, web browsing, or database The components of application services 105 are a session server 145, message routers 150, databases 155, and a data handler module In operation, the session server 140 can perform a session transfer between its 2 Phan Helsinki was printed in a book containing a collection of articles presented at a symposium proceeding in Helsinki, Finland on June 11-14, The copy held by the Library of Congress in Washington, D.C. is date-stamped July 31, Therefore, Phan Helsinki is prior art under 35 U.S.C 102(a)

9 multiple clients 120 and At the originating device, a user conducting an on-going session makes a request to transfer that session to another The session transfer module 220 (within session server 145) receives this request and stores the session history in 8:3. The session transfer module 220 retrieves the device profile of the target device and the data handler 160 converts the session data for compatibility with the target When the user activates or logs onto the target device, the reconfigured session is pushed to the target There may be an activation timer whereby if the user does not activate/login to the target device within a certain timeframe, the session is pushed back to the originating The session transfer module 220 can send an alert to the target device that notifies the user that a transferred session is awaiting to be B. Claim Construction In the context of an inter partes review, claim terms must be given their broadest reasonable interpretation in view of the specification. 1. in response to an activation of said second device This claim term relates to how the session handoff is triggered at the receiving device ( second device ). According to the challenged patent, this session transfer can be triggered by logging-on or activating the session on the receiving - 5 -

10 Accordingly, we interpret the term in response to an activation of said second device as encompassing 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. 2. conforms to a modality of said second device This claim term relates to making the transferred session conform to the user interface for the second Examples of ways in which the device may interact with the user include graphical user interface, voice command, or command line Thus, we interpret the term modality to encompass a user interface that interacts by graphics, text, or voice. 3. conform with said device profile of said second device (and variations thereof) This claim term relates to making the transferred session conform to the system requirements of the second device. When the session is transferred to the receiving device, the session data is converted into a format that is compatible with the receiving This data conversion may conform with parameters such as data format, modality, Thus, we interpret the term device profile to encompasses at least the data format used by the second device

11 IV. Grounds for Challenge The challenged patent has independent claims 1, 12, 13, 21, 23, 32, 34, and 42. Claims 1 and 12 are directed to a method of redirecting an on-going session. Claims 13, 21, 34, and 42 are directed to a system for transferring a session. Claims 23 and 32 are directed to a computer-readable storage medium that implements a method for redirecting a session. Petitioner requests cancellation of claims 1-6, 8-11, 13-15, 17, 18, 20, and 34 for anticipation and/or obviousness under 35 U.S.C. 102 and 103. Claims 1, 13, and 34 are anticipated by Phan San Jose (Exh. 1002). Claims 2, 3, 14, and 35 are obvious over Phan San Jose. Claims 4-6, 8-11, 15, 17, 18, and 20 are obvious over Phan San Jose in view of Phan Helsinki (Exh. 1003). Introduction to the Prior Art The imash mobile computing platform developed by the Thomas Phan group at UCLA anticipates the challenged claims or renders them obvious. The work on the imash platform is reported in two conference proceedings in the summer of In June 2001 in Helsinki, Finland, the Thomas Phan group presented its work on the imash platform as implemented for use with the Mozilla web Helsinki (Exh. 1003) 1367 abst., The following month in July 2001 in San Jose, California, the Thomas Phan group presented its further work on the imash platform as implemented on the UCLA hospital s wireless computer San Jose - 7 -

12 (Exh. 1002) 2 abst. & L bott. Phan San Jose cites to the authors previous work described in Phan Jose 4 L bott, 11 (cite #12). Together, Phan San Jose and Phan Helsinki describe the operation, architecture, and capabilities of the imash platform. In this obviousness analysis, Phan San Jose is applied as the primary prior art reference and Phan Helsinki is applied as the secondary reference. Phan San Jose reports the ongoing work on the imash research project, which was a multi-year, multi-discipline collaborative effort geared towards the development and deployment of a wireless computing infrastructure to aid physicians and their staff in a new state-of-the-art UCLA clinical and research hospital being built for this nascent Jose 2 L bott. Development of the imash platform was motivated by the belief that the convergence of desktop and mobile applications into a seamless computing experience will provide a strong motivation for future anytime, anywhere 2, abst. To address this need for a seamless mobile computing experience, the platform must have the capability to perform the handoff of application sessions across heterogeneous platforms using the network as a As such, Phan San Jose states its objective for the imash project as follows: With the session handoff mechanism, we envision physicians and staff running their typical applications continuously across client platforms which communicate with an Application Server acting as a data repository. The clients may be some set of desktop workstations, laptops, display tablets, handheld pocket - 8 -

13 computers, or personal digital assistants (PDAs), all of which have their own diverse bandwidth, display, and computation characteristics. Despite this degree of client machine variation, users will be able to seamlessly move an application s session from one machine to another machine running some version of the same application. This session transfer will use the network as a conduit, thereby allowing sessions to be suspended and restored from any networkconnected R 2 nd. Details about the operation, architecture, and capabilities of the imash platform, as described in Phan San Jose and Phan Helsinki, are given below in conjunction with the claim analysis. Independent Claim 1 a) (preamble) A method for redirecting an on-going, software based session comprising: All the steps of this claimed method are met by the imash platform developed by the Thomas Phan group at UCLA. In particular, this claim is anticipated by Phan San Jose (Exh. 1002). The imash platform was designed for physicians and staff at the UCLA medical center and allows for handoff of an ongoing session from device-to-device while the physician is roaming through the hospital to see different San Jose (Exh. 1002) 2 L bott. R 2 nd. Figures 1-3 show a roaming physician in a hospital having his ongoing clinical information session migrate from this PDA (personal digital assistant) to his desktop computer and then to his 3 top

14 b) (claim 1) conducting a session with a first device; Figure 1 of Phan San Jose shows the physician reviewing clinical data on his PDA (personal digital Jose 3 top. His PDA corresponds to a first device. c) (claim 1) specifying a second device; Figure 2 of Phan San Jose shows that the physician has moved from his PDA to his desktop computer, which corresponds to a second d) (claim 1) discontinuing said session on said first device; Phan San Jose indicates that the user can suspend his session at the first device and then have the session reinstantiated at the second device: When the user decides to move his session he activates the handoff mechanism from his client software on C 1 to either suspend his session (to be later reinstantiated explicitly from another machine) or to launch the session immediately on a target platform C 4 L top. e) (claim 1) 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; Regarding the session handoff shown in Figure 2, the state of his data on the PDA, such as rendered images, textual annotations, and user preferences, is automatically sent to a functionally similar application on his Jose 3 R 2 nd. Other types of data that may be transferred when the session is handed-off include the bookmark list, user preferences, and URL 4 R top (italics

15 added). These data elements constitute the session history of said first device. Phan San Jose explains that the most important hardware component in the imash architecture is the distributed middleware server (MWS) layer whose actions enable application session 3 R bott. This middleware server in the imash architecture contains the hardware and software that constitutes the session transfer module. f) (claim 1) resuming said session on said second device with said session history. Phan San Jose reports that the imash platform was implemented on a medical image display application used for pedagogical dissemination of information at UCLA and have augmented it to allow for session handoff from one platform to 7 L 2 nd (#4). The functionality of the medical image display application was improved by operating it on the imash 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. Claim 2 Claim 2 depends from claim 1 and adds the step of pushing said session to said second device in response to said discontinuing. This claim is obvious in view of Phan San Jose (Exh. 1002)

16 In imash, the user can transfer a session by a push mechanism or a pull mechanism. In the pull mode, the user terminates his session at the first device and then at the second (target) device, he retrieves the session by launching the relevant application Jose 8 R 3 rd. On the other hand, the push mode operates as follows: Alternatively, at the first client, the user can select the hostname of the target from a list. When the handoff occurs, the MWS [middleware server] will contact a daemon running on the target machine to immediately launch the Teaching File applet and automatically retrieve the session state. We consider this a push (italics added). Thus, when pushing a session handoff, imash gives the user the ability to select from multiple alternate computers (i.e. select the hostname of the target from a list That is, imash includes an intermediate step whereby the user can select which one of his alternate computers to transfer the session. However, in the situation where the user has only one alternate computer, it would be obvious to skip this selection step and proceed to the step of immediately launch the Teaching File applet and automatically retrieve the session This action, with the obvious omission of the intermediate step, constitutes pushing said session to said second device in response to said discontinuing [at the first device]. Claim 2 further specifies resuming said session in response to an activation of

17 said second device. In imash s push mode of session handoff, the target machine ( second device ) immediately launch[es] the Teaching File applet and automatically retrieve[s] the session (italics added). However, it would have been simple matter of accommodating user preference to perform this in a non-automatic manner by waiting for the user to launch the relevant application at the target machine, i.e. let the user perform the step manually. Instead of immediately launching the program application and automatically retrieving the transferred session, letting the user initiate the transfer results in resuming said session in response to an activation of said second device. As we explain above, we construe the term activation of said second device to encompass the user launching the relevant application program at the second 5. Claim 3 Claim 3 depends from claim 1 and adds the step of pushing a notification to said second device in response to said discontinuing. This claim is obvious over Phan San Jose (Exh. 1002). The challenged patent (Exh. 1001) explains that after the initial session is paused, a notification or alert can be sent to the redirected device to notify the user that the session is waiting and that the user can access it by activating the session on the redirected In imash, the user can transfer a session by a push mechanism or a pull mechanism. The push mechanism operates as

18 follows: Alternatively, at the first client, the user can select 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. We consider this a push Jose 8 R 3 rd (italics added). Thus, in this push mechanism, the session state is automatically retrieved at the target machine ( second device ). However, 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 instead of assuming that he does. Asking the user about retrieving the prior session in this manner constitutes a notification about the prior session that is waiting to be resumed. Claim 4 Claim 4 depends from claim 1 and adds the step of accessing a device profile of said second device. This claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). The imash platform takes into consideration that clients may be some set of desktop workstations, laptops, display tablets, handheld pocket computers, or personal digital assistants (PDAs), all of which have their own diverse bandwidth, display, and computation Jose 1 R 2 nd. Because the imash platform must be able to handle heterogeneous client devices, Phan San Jose explains

19 that [w]e can specify the client s characteristics in a device profile that will be made available to the MWS [middleware 4 R bott. (italics added). This description indicates that the middleware servers are accessing a device profile of said second device. Claim 4 further recites the step of restructuring said session data to conform with said device profile of said second device. As we explain above, Phan Helsinki and Phan San Jose together describe the operation, architecture, and capabilities of the imash platform developed by the Thomas Phan group at UCLA. Phan Helsinki (Exh. 1003) provides additional information about how the imash platform 1367 abst. Phan Helsinki explains: Middleware takes responsibility for getting the data from the right servers, and makes necessary conversion to fit the clients 1369 L 1 st. Accordingly, the middleware servers provide the following functionalities: Presentation conversion. Middleware servers fetch data based on user requests (or pre-fetch data based on prediction of user s near-future need) and perform conversion as needed. Session handoff. 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 L 2 nd & bott. When the imash servers fetch data and makes necessary

20 conversion to fit the clients needs for the session handoff, it is restructuring said session data to conform with said device profile of said second device. As explained above, we construe the term device profile to encompass the data format used by the 6. Claim 5 Claim 5 depends from claim 4 and specifies that the restructured session data conforms to a data format of said second device. Same as its base claim 4, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). When the imash platform was implemented for the Teaching File program used by clinicians at the UCLA Medical Center, there was a need to convert the data from a propriety image format called PACS. Phan San Jose explains: When the user requests a teaching file, the AS [application server], as before, responds via HTTP with the PACS image file Here we implement a key performance enhancement to the system: the MWS performs the image assembly on behalf of the client, including the conversion of the proprietary PACS image to Java Image The resulting image along with the accompanying textual annotation are shipped to the Jose 8 R 2 nd. This conversion from the propriety PACS format to the Java format of the client device is a conversion of data such that it conforms to a data format of said second device

21 Claim 6 Claim 6 depends from claim 4 and specifies that the restructured session data conforms to a modality of said second device. Same as its base claim 4, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). As we explain above, the term modality refers to the mode of user interaction such as graphical, text, or voice. In the sessions shown in Figures 1-3 of Phan San Jose, the handed-off session conforms to the text and/or graphical interface of the desktop computer (in Figure 2) and the laptop computer (in Figure Jose 3 top. Claim 8 Claim 8 depends from claim 1 and adds the step of reformatting said session history of said session to conform with said device profile of said second device. This claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). The imash platform was also used for transferring web browsing sessions. Phan Helsinki reports a case study using the imash platform with the Mozilla web 1370 L 4. In this implementation, transferring a web browsing session involves acquiring the most recently saved bookmarks, history, and user preferences, all of which are stored on and transported from the middleware as serialised Java R 1 st (#2,3) (italics added)

22 When the user transfers that session to a different machine, that saved session data is retrieved and incorporated into the client before the user s current interactive application session R 1 st (#3). Within Mozilla, the data is deserialised by the MARC and then read into Mozilla s bookmark, history, and user preference (italics added). Thus, the middleware server reformats the session history into Java Object data structures and copies them into the Mozilla browser s bookmark, history, and user preference dataspace on the second device. This conversion of the browser s bookmarks and history data into Java Objects format, storing the Java Objects on the middleware server, converting it out of the Java Objects format, and reading it into the target device s browser dataspace constitutes reformatting said session history to conform with said device profile of said second device. As explained above, we construe the term device profile to encompass the data format used by the 6. Claim 8 further adds the step of transmitting reformatted session history of said session in response to said activation of said second device. As we explain above, in imash, the user can transfer a session by a push mechanism or a pull 11. The user can push the session from the first device to the target machine, causing it to immediately launch the relevant program application; or the user can pull the session from the target machine, in which the session is reinstantiated by lanuching the program application on the target machine. Thus, in

23 imash s pull mode, the reformatted session history is transmitted to the second device upon activation of said second device. As we explain above, we interpret the term activation of said second device to encompass the user launching the relevant program application at the second 5. Claim 9 Claim 9 depends from claim 1 and adds the step of accessing said session history of said session. This claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). As we explain above for claim 8, Phan Helsinki reports a case study using the imash platform with the Mozilla web browser, in which the browser s most recently saved bookmarks, history, and user preferences were transferred to the new 1370 R 1 st (#2,3) (italics added). Claim 9 further specifies the step of reformatting said session history of said session to conform to said device profile of said second device. As we explain above for claim 8, imash converts the browser s bookmarks and history data into Java Objects format, stores the Java Objects on the middleware server, converts it out of the Java Objects format, and reads it into the target device s browser This action constitutes reformatting said session history to conform to said device profile of said second device. As explained above, we construe the term device profile to encompass the data format used by the

24 Claim 9 further specifies the step of transmitting reformatted session history of said session in response to said activation of said second device. As we explain above, in imash, the user can transfer a session by a push mechanism or a pull 11. The user can push the session from the first device to the target machine, causing it to immediately launch the relevant program application; or the user can pull the session from the target machine, in which the session is reinstantiated by launching the program application on the target machine. Thus, in imash s pull mode, the reformatted session history is transmitted to the second device upon activation of said second device. As explained above, we interpret the term activation of said second device to encompass the user launching the relevant program application at the second 5. Claim 10 Claim 10 depends from claim 9 and specifies that the formatted session history conforms to a data format of said second device. Same as its base claim 9, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). Whereas base claim 9 specifies reformatting the session history to conform with the device profile of the second device, claim 10 specifies more narrowly conformance to the data format. As explained above in the analysis of claim 9, this reformatting to conform with the data format occurs when imash converts the

25 browser s bookmarks and history data into Java Objects format, stores the Java Objects on the middleware server, converts it out of the Java Objects format, and reads it into the target device s browser 1370 R 1 st (#2,3) (italics added). Claim 11 Claim 11 depends from claim 9 and specifies that the formatted session history conforms to a modality of said second device. Same as its base claim 9, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). As we explain above, the term modality refers to the mode of user interaction such as graphical, text, or 6. In the sessions shown in Figures 1-3 of Phan San Jose, the handed-off session conforms to the text and/or graphical interface of the desktop computer (in Figure 2) and the laptop computer (in Figure Jose 3 top. Independent Claim 13 a) (preamble) A system for transferring a session, comprising: As compared to independent claim 1 directed to a method of transferring sessions, claim 13 is directed to a computer system for doing so. Much of the elements of independent claim 13 parallel those of claim 1. As such, this claim is anticipated by Phan San Jose (Exh. 1002)

26 b) (claim 13) a network; The imash project operated on the wireless computing infrastructure in a new state-of-the-art UCLA clinical and research hospital being built for this nascent Jose 2 L bott. This wireless computing infrastructure is a network. c) (claim 13) a session transfer module; The imash platform uses Middleware Servers that act as intermediaries between the heterogeneous devices being used by physicians ( desktop workstations, laptops, display tablets, handheld pocket computers, or personal digital assistants Jose 2 R 2 nd. Phan San Jose states: The most important hardware portion of our imash architecture is the distributed Middleware Server (MWS) layer placed between the AS and the clients. The MWS tier will play a variety of roles within imash, but in the context of this paper we shall concentrate on a sole Middleware Server and its actions that enable application session handoff. Thus, the relevant hardware/software components of imash s middleware servers that perform the session handoff correspond to the session transfer module. d) (claim 13) a first device to transmit a session history of said first device to said session transfer module after said session is discontinued on said first device; e) a second device to receive said session history; Figure 1 of Phan San Jose shows the physician reviewing clinical data on his PDA (personal digital Jose 3 top. His PDA corresponds to a first

27 device. Regarding the session handoff shown in Figure 2, the state of his data on the PDA, such as rendered images, textual annotations, and user preferences, is automatically sent to a functionally similar application on his 3 R 2 nd. Other types of data that may be transferred when the session is handed-off include the bookmark list, user preferences, and URL 4 R top (italics added). These data elements constitute the session history of said first device. As shown in the progression from Figure 1 to 3, the session is discontinued on one device ( first device ), transmitted to the middleware server (MWS) ( session transfer module ), and then resumed on another device ( second device ) that receives the stored session history. f) (claim 13) a session server providing a session service between said first device and said session server over said network, wherein said 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. According to the challenged patent (Exh. 1001), the session transfer module 220 is a functional part of the session server 2, 6: The session transfer module is already discussed above for element (c). Turning to the prior art, the imash middleware servers that reside between the Application Server and the multiple mobile clients, and which perform the session handoff, constitutes the session Jose 2 R 2 nd

28 Claim 14 Claim 14 depends from claim 13 and specifies that the session server is configured to push said session to said second device in response to an activation of said second device. This claim is obvious over Phan San Jose (Exh. 1002). As we explain above regarding claim 13, imash s middleware servers constitute the session server. As we also explain above, in imash, the user can transfer a session by a push mechanism or a pull 11. The user can push the session from the first device to the target machine, causing it to immediately launch the program application; or the user can pull the session from the target machine, in which the session is reinstantiated by launching the program application on the target machine. Thus, in imash s pull mode, the middleware server push[es] said session to said second device in response to an activation of said second device. As we explain above, we construe the term activation of said second device to encompass the user launching the relevant program application at the second 5. (Note: imash and the challenged patent use the words pull and push differently. In the challenged patent, the word push has a meaning synonymous with transmit or transfer.) Claim 15 Claim 15 depends from claim 13 and specifies that the system further comprises a device database configured to store a profile for each device registered

29 to a user, wherein said session server is configured to access a second device profile from said device database and to restructure said session to conform with said second device profile. This claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). This claim term is essentially stating that the system uses a database of device profiles to reconfigure the transferred session data to conform with said second device profile. To allow this, the device database stores individual device profiles and the session server accesses this database to get the relevant device information for making this conversion. Turning to the prior art, Phan San Jose summarizes the imash platform as follows: We have developed an application session handoff capability that allows for the seamless transfer of application data across multiple OS Jose 11 L 3 rd. Because imash is designed to work with heterogeneous client devices, [w]e can specify the client s characteristics in a device profile that will be made available to the MWS [middleware 4 R bott. Although Phan San Jose omits details about how the device data is made available to the MWS [middleware server], it is well understood that the device profile data is stored in some kind of database, i.e. a device database. Phan Helsinki gives further information about the imash platform. The session state at the destination should be adapted to the underlying device characteristics, which may be dramatically different from that on the source

30 L 4 th (italics added). Moreover, a separate profile can be assigned to each user. Phan Helsinki explains: User re-authentication. 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 1369 R top. Thus, the imash platform as described in Phan San Jose and Phan Helsinki includes a database that stores a profile for each device registered to a user. Although Phan San Jose and Phan Helsinki omit this detail, it is well understood that the imash middleware server is configured to access this database to restructure said session to conform with said second device profile. Claim 17 Claim 17 depends from claim 13 and specifies that the system further comprises a data handler server configured to reformat said messages of said session to conform with said second device profile. This claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). The reformatted messages are then transmitted in response to said activation of said second device. The term said messages lacks antecedent basis in claim 13. But for the purposes of analyzing this claim, we interpret this to mean said session history as recited in claim 13. With this correction, this claim parallels the language of claim 8, which recites reformatting said session history of said session to conform with said device profile of said second device and then transmitting

31 reformatted session history of said session in response to said activation of said second device. Accordingly, we apply the same analysis above for claim 8 regarding this 17. In claim 17, this data reformatting function is performed by a data handler server. According to the challenged patent, as shown in FIG. 1, the data handler module 160 is part of a cluster of components within an application services network 105 that also includes a session server 145, multiple message routers 150, and multiple databases Turning to the prior art, Phan San Jose indicates: To facilitate this [session handoff] functionality, we place a cadre of Middleware Servers as a new layer between the clients and the Application Jose 2 R 2 nd (italics). It would be obvious that one of this cadre of servers could serve as the data handler server to perform the above-described function. Claim 18 Claim 18 depends from claim 17 and specifies that the session server is configured to receive said session history of said session from said [first] device. Same as base claim 17, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). This claim parallels the language of claim 9 (first step), which recites accessing said session history of said session [from the first device], with the word accessing substituted with its counterpart function of receive. That is, accessing the data

32 results in receiving the data. Accordingly, we apply the same analysis above for claim 9 (first step) regarding this 19. Claim 18 further specifies that the session server is configured to reformat said session history of said session to conform with said second device profile. This claim parallels the language of claim 9 (second step), which recites reformatting said session history of said session to conform to said device profile of said second device. Accordingly, we apply the same analysis above for claim 9 (second step) regarding this 19. Claim 20 Claim 20 depends from claim 17 and specifies that the system further comprises a session handler module configured to maintain said session history of said session. Same as its base claim 17, this claim is obvious over Phan San Jose (Exh. 1002) in view of Phan Helsinki (Exh. 1003). The imash platform was also used for transferring web browsing sessions. Phan Helsinki reports a case study using the imash platform with the Mozilla web 1370 L 4. In this implementation, transferring a web browsing session involves acquiring the most recently saved bookmarks, history, and user preferences, all of which are stored on and transported from the middleware as serialised Java R 1 st (#2,3) (italics added). Thus, imash performs the function of maintain[ing] said session history of said session

33 According to the challenged patent, the session handler module 210 is a functional part of the session server 2, 6: Turning to the prior art, the hardware and software components of imash s middleware servers that maintain said session history as described above constitutes the session handler module. Independent Claim 34 a) (preamble) A system for transferring a session, comprising: As compared to independent claim 13 directed to a computer system for transferring a session, claim 34 is directed to another embodiment of the computer system that performs a session transfer. This claim is anticipated by Phan San Jose (Exh. 1002). b) (claim 34) a plurality of networks; The challenged patent (Exh. 1001) refers to the plural form networks in the following passage: Accordingly, messages from wireless clients 120 and/or wired clients 125 are transmitted to their protocol gateways, 110 and 115, respectively, over their respective networks, 110 and 115, Thus, the term plurality of networks encompasses a network configuration in which there is a wireless network and a wired network, i.e. two networks. Turning to the prior art, Figure 1 of Phan San Jose shows the PDA which is on the hospital s wireless network. Figure 2 shows the physician working on a desktop machine, which is presumed to be plugged into the hospital s wired network. But even

34 if this presumption is incorrect (i.e. the desktop machine is on a wireless network instead), it would be a simple matter of convenience to have the desktop on the hospital s wired network instead (for example, if a network wall socket is nearby). c) (claim 34) a session transfer module; This claim term parallels that of claim 13, step (c), which recites a session transfer module. Accordingly, we apply the same analysis above for claim 13, step (c) regarding this 22. d) (claim 34) a first device to transmit a session history of said first device to said session transfer module after said session is discontinued on said first device; This claim term parallels that of claim 13, step (d), which recites a first device to transmit a session history of said first device to said session transfer module after said session is discontinued on said first device. Accordingly, we apply the same analysis above for claim 13, step (d) regarding this 22. e) (claim 34) a second device to receive said session history; This claim term parallels that of claim 13, step (e), which recites a second device to receive said session history. Accordingly, we apply the same analysis above for claim 13, step (e) regarding this 22. f) (claim 34) a session server providing a session service between said first device and said session server over said plurality of networks, wherein said 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. This claim term parallels that of claim 13, step (f), which recites a session

35 server providing a session service between said first device and said session server over said network, wherein said 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. Accordingly, we apply the same analysis above for claim 13, step (f) regarding this 23. Conclusion For the foregoing reasons, the challenged claims for transferring user sessions between networked devices are anticipated by or obvious over the published work of the Thomas Phan group at UCLA. Petitioner respectfully requests that inter partes review be instituted against the challenged patent. /Steven Yu/ Steven Yu Reg. No. 58,776 Lead Counsel for Petitioner IRON DOME LLC PO Box Gaithersburg, MD Tel:

36 Listing of the Claims in Patent No. 7,191, 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. 2. The method according to claim 1, further comprising: pushing said session to said second device in response to said discontinuing; and resuming said session in response to an activation of said second device. 3. The method according to claim 1, further comprising: pushing a notification to said second device in response to said discontinuing. 4. The method according to claim 1, further comprising: accessing a device profile of said second device; and restructuring said session data to conform with said device profile of said second device. 5. The method according to claim 4, wherein: said restructured session data conforms to a data format of said second device. 6. The method according to claim 4, wherein: said restructured session data conforms to a modality of said second device. 7. The method according to claim 4, further comprising: blocking messages of said session originally intended for said first device; storing said messages of said session originally intended for said first device; reformatting said messages of said session to conform with said device profile of said second device; and

37 transmitting reformatted messages in response to said activation of said second device. 8. The method according to claim 1, further comprising: reformatting said session history of said session to conform with said device profile of said second device; and transmitting reformatted session history of said session in response to said activation of said second device. 9. The method according to claim 1, further comprising: accessing said session history of said session; reformatting said session history of said session to conform to said device profile of said second device; and transmitting reformatted session history of said session in response to said activation of said second device. 10. The method according to claim 9, wherein: said formatted session history conforms to a data format of said second device. 11. The method according to claim 9, wherein: said formatted session history conforms to a modality of said second device. 12. 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; resuming said session on said second device; pushing said session to said first device in response to one of a non-activation and a timeout in said activation of said second device; and resuming said session on said first device in response to a reactivation of said first device. 13. A system for transferring a session, comprising: a network;

38 a session transfer module; a first device to transmit a session history of said first device to said session transfer module after said session is discontinued on said first device; a second device to receive said session history; and a session server providing a session service between said first device and said session server over said network, wherein said 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. 14. The system for transferring a session according to claim 13, wherein: said session server is configured to push said session to said second device in response to an activation of said second device. 15. The system for transferring a session according to claim 13, further comprising: a device database configured to store a profile for each device registered to a user, wherein said session server is configured to access a second device profile from said device database and to restructure said session to conform with said second device profile. 16. The system for transferring a session according to claim 13, wherein: said session server is configured to block messages of said session intended for said first device and to store said messages of said session. 17. The system for transferring a session according to claim 13, further comprising: a data handler server configured to reformat said messages of said session to conform with said second device profile and to transmit reformatted messages of said session in response to said activation of said second device. 18. The system for transferring a session according to claim 17, wherein: said session server is configured to receive said session history of said session from said device and to reformat said session history of said session to conform with said second device profile.