IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD. HULU, LLC, NETFLIX, INC., and SPOTIFY USA INC.

Transcription

1 IN THE UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD HULU, LLC, NETFLIX, INC., and SPOTIFY USA INC. Petitioners v. CRFD RESEARCH, INC. Patent Owner U.S. Patent No. 7,191,233 PETITION FOR INTER PARTES REVIEW

2 TABLE OF CONTENTS I. MANDATORY NOTICES PURSUANT TO 37 C.F.R. 42.8(a)(1)... 1 II. PAYMENT OF FEES PURSUANT TO 37 C.F.R III. GROUNDS FOR STANDING PURSUANT TO 37 C.F.R (a)... 2 IV. IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R (b), STATEMENT OF RELIEF REQUESTED, AND GROUNDS FOR UNPATENTABILITY... 2 A. 37 C.F.R (b)(1): Claims for Which IPR is Requested... 2 B. 37 C.F.R (b)(2): The Specific Art and Statutory Grounds on Which the Challenge is Based... 3 C. 37 C.F.R (b)(3): Claim Construction... 4 D. 37 C.F.R (b)(4): How the Claims are Unpatentable... 7 E. 37 C.F.R (b)(5): Evidence Supporting the Challenge... 8 F. Level of Ordinary Skill in the Art... 8 V. OVERVIEW OF THE 233 PATENT AND ITS FILE HISTORY... 8 A. Description of the Alleged Invention of the 233 Patent... 8 B. Summary of the Prosecution History of the 233 Patent Regarding the Challenged Claims VI. CLAIM-BY-CLAIM EXPLANATION OF GROUNDS, SHOWING IT IS MORE LIKELY THAN NOT THAT THE CHALLENGED CLAIMS ARE UNPATENTABLE A. Ground 1: Claims 1-3, 23 and 24 are Anticipated by Bates Brief Summary of Bates Bates Anticipates Claims 1 and a. Bates discloses the method described in the preamble of claim 1 and the computer readable storage medium described by the preamble of claim b. Bates discloses the first element, conducting a session with a first device c. Bates discloses the second element, specifying a second device ii

3 d. Bates discloses the third element, discontinuing said session on said first device e. Bates discloses the fourth element, 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 f. Bates discloses the fifth and final element, resuming said session on said second device with said session history Bates Anticipates Claims 2 and Bates Anticipates Claim B. Ground 2: Claims 1-3, 23 and 24 are Obvious in View of Bates C. Ground 3: Claims 1-6, 8-11, and are Obvious Over Bates in View of Chan Brief Summary of Chan It Would Have Been Obvious to Combine Bates and Chan Bates and Chan Render Claims 1 and 23 Obvious Bates and Chan Render Claims 2, 3 and 24 Obvious Bates and Chan Render Claims 4 and 25 Obvious Bates and Chan Render Claims 5 and 6 Obvious Bates and Chan Render Claims 8 and 29 Obvious Bates and Chan Render Claim 9 Obvious Bates and Chan Render Claims 10, 11, 30 and 31 Obvious D. Ground 4: Claims 13, 14, 34 and 35 are Obvious Over Bates in View of Zou Brief Summary of Zou It Would Have Been Obvious to Combine Bates and Zou Bates and Zou Render Claims 13 and 34 Obvious a. Bates and Zou disclose a system for transferring a session described in the preambles of claims 13 and b. Bates discloses the first element, a network of claim 13 and a plurality of networks of claim iii

4 c. Bates and Zou disclose the second element, a session transfer module d. Bates discloses the third element, 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. Bates discloses the fourth element, a second device to receive said session history f. Bates and Zou together disclose the fifth element, a session server providing a session service between said first device and said [network / plurality of networks], wherein said session server is configured to transfer said session from said first device to said second device in response to a redirect command from said first device Bates and Zou Render Claims 14 and 35 Obvious E. Ground 5: Claims 15, 17-20, 36, are Obvious Over Bates in View of Zou, in Further View of Chan It Would Have Been Obvious to Combine Bates, Zou and Chan Bates, Zou and Chan Render Claims 15 and 36 Obvious Bates, Zou and Chan Render Claims 17 and 38 Obvious Bates, Zou and Chan Render Claims 18 and 39 Obvious Bates, Zou and Chan Render Claims 19 and 40 Obvious Bates, Zou and Chan Render Claims 20 and 41 Obvious VII. CONCLUSION iv

5

6 On behalf of Hulu, LLC, Netflix, Inc. and Spotify USA Inc. (collectively, Petitioners ) and in accordance with 35 U.S.C and 37 C.F.R. 42, inter partes review ( IPR ) of claims 1-6, 8-11, 13-15, 17-20, 23-25, 29-31, and (the Challenged Claims ) of U.S. Patent No. 7,191,233 ( the 233 patent ) is respectfully requested. The 233 patent relates generally to session transfer between two communication devices, via a session transfer module. However, as of the priority date (September 17, 2001), the specific systems and methods claimed in the Challenged Claims for achieving session transfer were not new. The references discussed herein represent just a few examples of publications which render these claims invalid as anticipated and/or obvious. I. MANDATORY NOTICES PURSUANT TO 37 C.F.R. 42.8(a)(1) 37 C.F.R. 42.8(b)(1): Petitioners are the real parties-in-interest. 37 C.F.R. 42.8(b)(2): The 233 patent is being asserted in pending cases by Patent Owner CRFD Research, Inc. ( Patent Owner ) against Hulu, LLC, Case No. 1:14-cv (D. Del.); Netflix, Inc., Case No. 1:14-cv (D. Del.); Spotify USA Inc., Case No. 1:14-cv (D. Del.); and DISH Network Corp., Case No. 1:14-cv (D. Del.). Claims 1-6, 8-11, 13-15, 17, 18, 20 and 34 are being challenged in IPR and claims 1-6, 8-11, 13-15, 23-25, and 34 are being challenged in IPR The present Petition relies on different 1

7 references and arguments than both of these IPRs, and is not cumulative. These cases may affect or be affected by a decision in this proceeding. 37 C.F.R. 42.8(b)(3) and (4): Petitioners designate Francis E. Morris (Reg. No. 24,615) as Lead Counsel and David G. Lindenbaum (Reg. No. 51,951) as Back-Up Counsel, both at WARD & ZINNA, LLC, 382 Springfield Ave., Ste. 300, Summit, NJ 07901, (telephone), and (facsimile). Please address all service information to Lead Counsel at this address. Petitioners consent to electronic service by at: fmorris-ptab@wardzinna.com. II. PAYMENT OF FEES PURSUANT TO 37 C.F.R The Office is authorized to charge the fee set forth in 37 C.F.R (a), as well as any other fees that may be due in connection with this Petition, to Deposit Account No , Ref. No IPR. III. GROUNDS FOR STANDING PURSUANT TO 37 C.F.R (a) Petitioners certify that the 233 patent is eligible for IPR and that Petitioners are not estopped or barred from requesting IPR of the Challenged Claims on the grounds identified herein. IV. IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R (b), STATEMENT OF RELIEF REQUESTED, AND GROUNDS FOR UNPATENTABILITY A. 37 C.F.R (b)(1): Claims for Which IPR is Requested Petitioners request IPR of the Challenged Claims, claims 1-6, 8-11, 13-15, 2

8 17-20, 23-25, 29-31, and B. 37 C.F.R (b)(2): The Specific Art and Statutory Grounds on Which the Challenge is Based This Petition contains non-limiting examples of how the prior art enumerated below teaches each claim element against which it is being used. Additional examples are set forth elsewhere in the prior art. This Petition assumes for purposes of this Petition only, that the 233 patent is entitled to a priority date of September 17, 2001, the date on which it was filed. In support of the grounds of unpatentability identified below, Petitioners cite the following art, none of which was cited during prosecution of the 233 patent: Bates: U.S. Patent No. 6,963,901 to Bates et al. ( Bates ; Ex. 1004). Bates is prior art under at least 35 U.S.C. 102(e) because it was filed on July 24, 2000 and issued into a U.S. patent on November 8, Chan: Chan, Mun Choon et al., Next-Generation Wireless Data Services: Architecture and Experience, IEEE Personal Communications, Feb ( Chan ; Ex. 1005). Chan is prior art under at least 35 U.S.C. 102(b) because it was published in February Zou: Zou, Bo, Mobile ID Protocol: A Badge-Activated Application Level Handoff of a Multimedia Streaming to Support User Mobility, Master s Thesis, Univ. of Ill. at Urbana-Champaign, August 2000 ( Zou ; Ex. 1006). Zou is prior art under at least 35 U.S.C. 102(a) because it was publicly available at least as 3

9

10 includes an application services network 105, an application server 140 and clients 120 and 125. Id. at 4:4-11, 5:21-33, FIG. 1. The application services network provide services to the clients for data exchange including session-based services such as instant messaging, database querying, and other similar services. Id. at 5: The application server in turn provides the supporting applications. Id. at 5: Each of the application services exists between two points in time. Ex. 1003, 65; Ex. 1009, p. 3. This definition is consistent with the way session is used in the 233 patent as understood by one of ordinary skill in the art. Ex. 1003, (2) A device should be construed as a computing apparatus. This construction is supported by the 233 patent. The 233 patent provides several examples of devices, all of which are capable of computing: laptop computers, wireless pagers, enhanced text pagers, wireless handheld devices, personal digital assistants, wireless mobile phones with integrated displays, etc. Ex at 1: This construction is also consistent with the 233 patent s Technical Field, which states that the invention generally relates to session management in a distributed computer network. Ex. 1001, 1:7-8. (3) Discontinuing should be construed as terminating or otherwise stopping, with the ability to be resumed. The fundamental purpose of the 233 patent is to enable the transfer of an on-going software based session from one 5

11 device to another. Ex. 1001, 1:9-11, 2:3-5. The 233 patent allegedly accomplishes this transfer by discontinuing a session on the first device and then resuming the session on a second device. Id. at 2:6-8. When the session is discontinued, it is terminated or otherwise stopped, but in the context of the 233 patent, it must possess the ability to be resumed on the second device, or the goal of the alleged invention could not be realized. Ex. 1003, Thus, this definition is consistent with the plain meaning of discontinuing in the context of the 233 patent and is supported by the 233 patent. Id. at 73. (4) A session history should be construed as a record generated about a session. It is well understood that a history consists of a record generated about an activity or event. Ex. 1003, 76; Ex. 1008, p. 4. Here, the term session qualifies history, and thus a session history is a record generated about a session. Ex. 1003, This definition is consistent with the way this term is used in the 233 patent as understood by one of ordinary skill in the art. Id. For example, during session transfer, the session transfer module may transmit the reformatted session history the redirected device such that the user is able reconstruct the session on the redirected device. Ex. 1001, 3:43-4:3. (5) A session transfer module should be construed as hardware and/or software that participates in the transfer of the session. As its name implies and as the specification makes clear, the session transfer module may be configured to 6

12 perform a variety of functions in support of session transfer between devices. Ex. 1001, 3:6-4:3. However, although the session transfer module is mentioned 52 times in the 233 patent, the 233 patent does not provide any details about its specific components or how it may be configured to perform any function. A person of ordinary skill would understand that in the context of the 233 patent, the broadest reasonable construction of session transfer module includes hardware, software residing on hardware, or a combination of the two, and that it must participate in session transfer. Ex. 1003, (6) After should be construed as later in time. This term does not appear in the 233 patent, and was added to the claims at the Examiner s prompting to overcome the prior art of record. Ex. 1002, p The broadest reasonable construction of after is later in time. Ex. 1003, 85-88; Ex. 1008, p. 3. D. 37 C.F.R (b)(4): How the Claims are Unpatentable Petitioners request that the Challenged Claims be found unpatentable on each ground enumerated herein, based on the detailed explanation provided herein, including Petitioners identification of where each element is found in the prior art, as shown in Section VI. Unless otherwise noted, all emphasis has been added. For non-patent references, the page numbers refer to the numbers on the lower-right hand corner of the exhibit appearing as Ex. XXXX - Page X of XX. 7

13 E. 37 C.F.R (b)(5): Evidence Supporting the Challenge An Appendix of Exhibits is provided above at page (v). The relevance of the evidence, including the identification of specific portions of the evidence that support the challenge, may be found in Section VI. Additional explanation and support for each ground are set forth in Ex. 1003, Declaration of Dr. Mark Claypool. F. Level of Ordinary Skill in the Art A person of ordinary skill in the art would have a Bachelor of Science in Computer Science, Computer Engineering, Electrical Engineering, or an equivalent field as well as at least two years of academic or industry experience in the software field. Ex. 1003, V. OVERVIEW OF THE 233 PATENT AND ITS FILE HISTORY A. Description of the Alleged Invention of the 233 Patent The 233 patent is directed to a system and method for session management in a distributed computer network. Ex. 1001, 1:7-8. More particularly, the invention relates to a user-directed transfer of an on-going software-based session from one device to another device. Id. at 1:8-11. The alleged invention can supposedly be utilized in any session-oriented environments. Id. at 2: The main objective of the alleged invention is to allow a user of a computing apparatus to engage in an activity on that apparatus (such as browsing the Internet or instant 8

14 messaging on a desktop) and then transfer information about the computing session to a second computing apparatus (such as a laptop), so that the user can pick up the session where he or she left off. In order effect this transfer, the 233 patent discloses a session history, which moves from the first device to the second device via a session transfer module. The 233 patent operates over a conventional client-server infrastructure that was well known in the art at the time the application that led to the 233 patent was filed. Ex. 1003, 25. Figure 1 of the 233 patent below depicts an illustrative communication network 100 that has several components, including wireless and wired client devices 120 and 125, respectively, and a session server

15 According to the 233 patent, the clients may include conventional communication-enabled devices such as desktop and laptop computers, personal digital assistants, enhanced text pagers, wireless mobile phones, and wireless handheld devices. Ex. 1001, 1: As depicted in Figure 2 below, the session server 145 consists of several components, including a series of modules, and most significantly a session transfer module 220. The primary function of the session transfer module is to participate in the transfer of an on-going session from a first device to a second device. It also may be configured to perform a variety of tasks. Id. at 3:17-4:1. The 233 patent, however, does not provide any details of how the session transfer module is actually configured to perform any task. As demonstrated herein, all features of the Challenged Claims were well known at the time the application leading to the 233 patent was filed. 10

16 B. Summary of the Prosecution History of the 233 Patent Regarding the Challenged Claims The application leading to the 233 patent was filed on September 17, 2001 with 45 claims. The Patent Office issued a first Office Action on March 28, 2005, rejecting claims 1-3, 5-14, 16-25, and under 35 U.S.C. 102(e) as being anticipated by U.S. Pat. App. Pub. No. 2002/ to Belfiore et al. ( Belfiore ; Ex. 1010). Ex. 1002, p. 66. Among these rejected claims were all four independent claims, claims 1, 13, 24 and 35. Independent claim 1 as originally filed is representative of the rejected independent claims: Id. at 21. 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 resuming said session on said second device. In an August 8, 2005 Amendment, the Applicant amended the four rejected independent claims as well as certain dependent claims, and canceled claims 22 and 44. Id. at 74. This Amendment introduced a session history into each of the independent claims. Importantly, the Applicant also added the limitation that the session history should move from the first device to the session transfer module during a transition of said session. The Applicant s two amendments to 11

17 claim 1 are representative in this regard: transmitting a session history of said first device from said first device to a session transfer module during a transition of said session from said first device to said second device and resuming said session on said second device with said session history. Id. at 75. The timing of the handoff of the session history from the first device to the session transfer module was crucial to the Applicant s argument over Belfiore. The Applicant argued that none of the rejected claims as amended were anticipated by Belfiore because Belfiore failed to disclose transmitting a session history during the transition of a session from the first device. Id. at (underline in original). The Patent Office was not persuaded, and issued a second rejection on November 2, Claims 1-3, 5-14, 16-21, 23-25, 27-36, and 45 were again rejected under 35 U.S.C. 102(e) as being anticipated by Belfiore. Id. at 95. The Patent Office found that Belfiore disclosed the amended claims, including the new requirement that the transfer of the session history take place during the transition of the session. Id. The Patent Office noted that Belfiore discloses transmitt[ing] the session history during transition of said session, i.e., the session history is transmitted to the server up to the point the session is to be transferred thereby ensuring a current and seamless session transfer. Id. at 99. In a response dated January 27, 2006, the Applicant regurgitated its 12

18 argument that Belfiore failed to teach the transmission of a session history during a transition of a session. Id. at The Patent Office remained unconvinced. A third Office Action was issued on July 3, 2006, again finding that Belfiore discloses transmitting a session history during a transition of a session. Id. at 140. Although Applicant had not advanced an alternative argument, the Office Action noted that: It appears the applicant believes the claim language requires the session to transition after the session on the first device is discontinued. However, the claim language is clear that the transition occurs prior to discontinuing the session on the first device. Id. at 145 (emphasis in original). Taking a cue from the Patent Office, the Applicant amended the rejected claims to include the limitation that the transmission of the session history from the first device to the session transfer module occurred after discontinuation of the session on the first device. The amendment to independent claim 1 is representative, and reads as follows: 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 during a transition of said session from said first device to said second device. Id. at 151. The Applicant emphasized this amendment in its argument over Belfiore, 13

19 stating that, to more clearly distinguish over Belfiore, the Applicant s claims are amended herein to recite a session history that is transmitted after a session is discontinued on a first device. The Examiner acknowledged that Belfiore discloses a session history that is transmitted during the session... and not after a session is discontinued on the first device[.] Id. at (emphasis and ellipsis in original). A Notice of Allowance was mailed on January 17, Id. at 172. It is clear from the prosecution history that the purported novelty of issued independent claims 1, 13, 23 and 34 and their dependents is merely that the session history is transmitted from the first device to the session transfer module after the session is discontinued on the first device. However, the timing of this transfer (along with all of the other features of all Challenged Claims) was not novel. Every feature of the Challenged Claims is clearly disclosed in the prior art. VI. CLAIM-BY-CLAIM EXPLANATION OF GROUNDS, SHOWING IT IS MORE LIKELY THAN NOT THAT THE CHALLENGED CLAIMS ARE UNPATENTABLE The 233 patent discloses nothing more than what was well known in the art prior to the filing of the application which led to 233 patent. None of the prior art discussed below was considered by the Patent Office during prosecution of the 233 patent. These prior art references are directed to the same field as the 233 patent (session transfer); operate using the same architecture as the 233 patent 14

20 (client-server); and are designed to solve the same problem as the 233 patent (allowing session transfer between computers to enable a user to begin a session on one computer and continue the session on another computer). The reference(s) in each ground disclose all elements of the Challenged Claims enumerated in that ground, arranged in the prior art as in the claims. Secondary considerations do not support a finding of nonobviousness. There is no evidence that the Patent Owner will be able to show any secondary consideration. Ex. 1003, Should the Patent Owner put forth any allegations regarding secondary considerations, Petitioners respectfully request an opportunity to respond. A. Ground 1: Claims 1-3, 23 and 24 are Anticipated by Bates 1. Brief Summary of Bates Bates teaches a system and method for cooperative web browsing between computers in which a web browsing session is transferred from a first computer to a second computer via one or more servers (such as network server 108 and server 102) using browser information. Ex. 1004, 3:4-7, 9:24-30, 10:51-11:8, FIG

21 The browser information includes information generated during a browsing session on the first client computer and may be limited to the information generated during a particular session. Id. at 4:61-63, 6:11-13, 7: Bates also discloses a step-by-step session transfer process. First, a user conducts a web browsing session on a first client computer, such as reading messages posted on a bulletin board, inputting data into a web page or performing some other task during a browsing session. Id. at 10: Second, a user selects another computer on which the user will ultimately resume the session: [a] user may input to the field 302 an address for a computer (e.g., a remote client computer 106) to which the browser information contained in the sending computer s buffer 242 will be sent. Id. at 5: Third, when the user chooses to switch computers for example, because the user wants to continue the session the user terminates the session on the first 16

22 computer: prior to completing the task, the user may be required to terminate a browsing session. Id. at 10: Fourth, [i]n such an event, the necessary information may be collected and transmitted to a remote computer containing another browser program. Id. at 10: The browser information is transmitted to the remote client computer via the network 104 [including network servers 108] and the server 108 (FIG. 1). Id. at 9: For example, the browser information may be transmitted via (using protocols such as the Simple Mail Message Protocol (SMTP) or the Post Office Protocol (POP)) or via the File Transfer Protocol (FTP). Id. at 3: Each of these protocols utilizes a client-server model to enable the browser information to be transferred from a first client computer to a second client computer via a server. Ex. 1003, 99, The server necessarily includes both hardware and software to perform the required functions. Id. at 99. Fifth, [t]he browser information is then used to reconfigure the browser program of the remote computer and restore the user to where he or she left off during the terminated browsing session. Ex. 1004, 10:65-11:1. Thus, in the case of a user reading a message board, the browser displays the message which was being read when the browsing session was terminated. Id. at 11:1-4. In the case of inputting data to a web page, the web page is rendered with the data that was input prior to the termination of the session contained therein. Id. at 11:4-6. In 17

23 effect, the present invention preserves the current status of a browsing session to be resumed at another location. Id. at 11: Bates Anticipates Claims 1 and 23 Independent claim 1 is a method claim. Independent claim 23 is its Beauregard counterpart. These claims are substantively identical except for their preambles, and each of the five elements of each claim is taught by Bates. a. Bates discloses the method described in the preamble of claim 1 and the computer readable storage medium described by the preamble of claim 23 The preamble of claim 1 recites [a] method for redirecting an on-going, software based session. The preamble of claim 23 recites a computer readable storage medium, used for the purpose of implementing a method for redirecting a session. It reads, [a] computer readable storage medium on which is embedded one or more computer programs, said one or more computer programs implementing a method for redirecting a session, said one or more computer programs comprising a set of instructions for. Bates teaches a method for re-directing a software-based session as required by claim 1. Specifically, Bates discloses a method, apparatus and article of manufacture configured to support sharing of browser information between at least two browser applications in which a session is started on one computer and continued on another. Id. at 1:63-66, 3:4-7, 10:51-11:8. 18

24 Bates also teaches a computer readable storage medium used to redirect a software-based session, as required by claim 23. Bates states, one embodiment of the invention is implemented as a program product for use with a computer system The program(s) of the program product can be contained on a variety of signal/bearing media Such signal-bearing media, when carrying computer readable instructions that direct the functions of the present invention, represent embodiments of the present invention. Id. at 5: b. Bates discloses the first element, conducting a session with a first device Bates teaches conducting a browsing session (i.e., a session) on a first client computer (i.e., a first device), such as a local client computer or a sending client computer. Ex. 1004, 8:55-57, 4:58-5:6, FIG. 7. c. Bates discloses the second element, specifying a second device Bates teaches that [a] user may input to the field 302 an address for a computer (e.g., a remote client computer 106) to which the browser information contained in the sending computer s buffer 242 will be sent. Id. at 5:52-56, FIG. 3. One of ordinary skill in the art would understand that identifying the address for the second computer is specifying a second computer because the user selects the computer to send the browser information. Ex. 1003, 122 [1b/23b]. 19

25 d. Bates discloses the third element, discontinuing said session on said first device The broadest reasonable construction of discontinuing is terminating or otherwise stopping, with the ability to be resumed. Bates provides several examples of this. In one instance, Bates discloses a user performing tasks during a browsing session executing on a first client computer. Ex. 1004, 10: Bates states: Prior to completing the task, the user may be required to terminate the browsing session. In such an event, the necessary browser information may be collected and transmitted to a remote computer containing another browser program. The browser computer is then used to reconfigure the browser program of the remote computer and restore the user to where he or she left off during the terminated session. Id. at 10:61-11:1. The browsing session is discontinued because it is terminated on the first computer and can be restored (resumed) on the remote computer. Ex. 1003, 122 [1c/23c]. Bates also discusses sending browser information to a second device when the user shuts down a first client computer, or when the session on the first computer goes into an idle period. Ex. 1004, 7:66-8:5. Each of these actions is indicative of a session stopping or being suspended because the session is no longer active or running. Ex. 1003, 122 [1c/23c]. And in these instances, Bates 20

26 preserves the current status of a browsing session to be resumed at another location. Ex. 1004, 11:7-8. Because Bates discloses browsing sessions that have been suspended on a first client but may be resumed on a second client, Bates discloses discontinuing said session on said first device. Ex. 1003, 122 [1c/23c]. e. Bates discloses the fourth element, 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 There are three components of this element that have not been introduced previously in claims 1 and 23: (1) the existence of a session history; (2) transmitting the session history to a session transfer module; and (3) doing so after the session is discontinued on the first device. Each of these components warrants its own analysis, and each can be found in Bates. (1) Bates discloses a session history. The broadest reasonable interpretation of session history is a record generated about a session. The browser information disclosed in Bates is a session history because it includes information generated during a browsing session. Ex. 1004, 4: In particular, Bates browser information is an account of actions taken by the user (i.e., a record) which may include: cache information (e.g., URLs to sites visited, cookies, etc.), keystroke actions, bookmarks, history list information (i.e., a 21

27 listing of network addresses visited during the browsing session), browser configurations (e.g., font, color, background, screen sizing, display attributes and other user-configurable settings) and the like. Id. at 4:67-5:6. Furthermore, the browser information may be limited to information generated during a single browsing session. Id. at 6:11-13, 7: One of ordinary skill in the art would consider this browser information to constitute a record generated about a session because it is an account of actions taken by the user during a session. Ex. 1003, 122 [1d/23d]. (2) Bates discloses transmitting a session history to a session transfer module. Figure 4 of Bates illustrates that a user at a first client computer may select what to share, which may include all browser information. Ex. 1004, 6:8-11, FIG. 4. Selection of the checkboxes 402a k determines what browser information will be sent/received between two or more client computers 106. Id. at 5:

28 Bates also discloses that the browser information in the buffer 242 [of the first client computer] is transmitted to the remote client computer via the network 104 and the server 108 (FIG. 1). Id. at 9: The network 104 includes network servers n. Id. at 3:40-43, FIG. 1. The transmission of the browser information may occur via SMTP, POP, or any method or system (e.g., file transfer protocol (FTP)) adapted to support the information processing described herein. Id. at 3:51-53, 3:57-61, 3: These protocols facilitate information transfer and rely on a client-server architecture, such as the network and servers, through which information is communicated. Ex. 1003, 99, The disclosed and network servers themselves, the software running the protocols, or the combination of the two meet the broadest reasonable construction of a session transfer module because they are hardware and/or software that participates in the transfer of the session. Id. at 122 [1d/23d]. (3) Bates discloses that the session history is transmitted after said session is discontinued on said first device. As shown below in Figure 5, Bates discloses that a user may choose when to send the browser information (i.e., the session history), including upon user request, at shutdown or at idle period : 23

29 These time periods either necessarily would be, or could be, after discontinuation of the session on the first computer. At shutdown on the first computer, the session would be discontinued because it would be stopped, but could be resumed. Ex. 1003, 122 [1d/23d]. If the session had idled on the first computer, it would also be discontinued because it would be stopped, but could be resumed. Id. Finally, since Bates does not put any time restriction on when the user can request that the browser information be transferred upon user request, Bates allows for browser information transmission at any number of user-selected times. One of ordinary skill in the art would appreciate that one of those times could be after the session is discontinued on the first device. Id. f. Bates discloses the fifth and final element, resuming said session on said second device with said session history Bates teaches resuming or restoring the browsing session on the second client computer with the browsing information. Bates provides that [t]he browser information is then used to reconfigure the browser program of the remote 24

30 computer and restore the user to where he or she left off during the terminated browsing session In effect, the present invention preserves the current status of a browsing session to be resumed at another location. Ex. 1004, 10:65-11:8, FIG Bates Anticipates Claims 2 and 24 Dependent claims 2 and 24 each add the same two limitations to claims 1 and 23, respectively. These limitations are disclosed in Bates. First, these claims call for pushing said session to said second device in response to said discontinuing. In short, this element calls for the discontinuation of the session on the first device to be the catalyst for the session being sent to the second device. Bates discloses that the browser information may be sent in response to shut down or idling of the first device. Supra, pp ; Ex. 1004, 5:50-8:1, FIG. 5. Bates discloses push protocols that are used to communicate browser information between computers. Ex. 1004, 3:20-67; Ex. 1003, Bates states that a user may be required to terminate a browsing session. In such an event, the necessary browser information may be collected and transmitted to a remote computer containing another browser program. The browser information is then used to reconfigure the browser program of the remote computer and restore the user to where he or she left off during the terminated browsing session. Ex. 1004, 10:61-11:1. Thus, the shut down (i.e., discontinuing) of the session on the first device is 25

31 the catalyst for sending the session to the second device. Ex. 1003, 123 [2a/24a]. The shut down results in pushing the session to the second device via the server by sending of the browser information. Id. Second, these claims call for resuming said session in response to an activation of said second device. Figure 6 of Bates illustrates that a user can select receiving preferences for receiving the browser information about the session on the second client computer, including at boot up and upon user request. Ex. 1004, 8:31-54, FIG. 6. When a user selects the at boot up option, it causes the browser program of the second client computer to be reconfigured and the session to be resumed when the second device is activated. Id. at 8:31-38, 10:65-11:8. 4. Bates Anticipates Claim 3 Dependent claim 3 adds to claim 1 the step of pushing a notification to said second device in response to said discontinuing. Bates teaches that the local client computer (i.e., the first device) can be configured to send browser information in 26

32 response to an event, such as discontinuing the session on the first device, using a push protocol. Id. at 9:24-25; Ex. 1003, 124 [3a]. This information can be sent in the form of an message, i.e., a notification, to a receiving client computer (i.e., the second device). Ex. 1004, 9:30-57, 5:51-63, FIG. 3. An message is a notification, and sending the to the second device constitutes pushing a notification to the second device. Ex. 1003, 124 [3a]. B. Ground 2: Claims 1-3, 23 and 24 are Obvious in View of Bates Assuming arguendo that Bates does not explicitly or inherently disclose one or more elements of the above-referenced claims and is therefore not anticipatory, Bates still renders each of these claims invalid as obvious. For example, it would have been obvious that the server(s) running the various protocols in Bates constitute a session transfer module. Ex. 1003, 126. Servers are hardware that operate software programs to perform certain functions. Id. Bates discloses that one function is to provide session transfer using browsing information (i.e., session history). Bates further teaches the use of various protocols to facilitate this transfer. One of ordinary skill in the art would understand that the protocols running on the servers would provide the necessary functionality to transfer the browser information. Id. It would also have been obvious that in Bates, the browser information can be transferred after discontinuation of the session on the first device; Bates 27

33 explicitly discloses that transfer can occur at a variety of user-chosen times, which could include after discontinuation. Id. at 127. The goal of Bates is to preserve the session from one computer to a next. Ex. 1004, 10:55-11:8. Transferring the browser information after discontinuation would accomplish the goal by ensuring that the entire session is transferred. Ex. 1003, 128. Nothing more would be happening with the session on the first device at the time of transfer; the session would have already been discontinued there. Id. Similarly, it would have been obvious that the push protocols disclosed in Bates could be utilized to push the session or a notification to the second device in response to the discontinuing. Id. at 129. It would have been beneficial to push the session itself to the second device in order to continue the session on the second device. Id. It would likewise have been beneficial to push a notification to the second device to inform the second device that the session was discontinued on the first device. Id. This would enable, among other things, seamless transition amongst the devices. Id. C. Ground 3: Claims 1-6, 8-11, and are Obvious Over Bates in View of Chan 1. Brief Summary of Chan Chan discloses a client-server architecture in which an application session [may] persist across network and device handoffs. Ex. 1005, p. 4, FIGs Such devices could include an office desktop computer, a handheld personal computer 28

34 or a personal digital assistant. Id. at 2-3. Chan also envisions that a session transfer module will take part in the transfer process. As shown in Figure 4 below, Chan utilizes a server including a series of modules interposed between clients that facilitate session transfer. Id. at 6-7, FIG. 4. Among other things, the server modules receive the state information (including session states ) from the first device and transfer it to the second device. Id. at 6-7. The transferred state information / session state constitutes a session history, as it may include bookmarks, history, and cookies [which] should be preserved when the user migrates to different devices; cache objects can migrate from server to device or vice versa, depending on the environment. Id. at 7. 29

35 2. It Would Have Been Obvious to Combine Bates and Chan Both Bates and Chan disclose a client-server architecture for transferring sessions between clients. Bates primarily focuses on the client side. Bates discloses the use of servers, as well as certain protocols and FTP. Ex. 1004, 3:20-67, 9:27-30, FIG. 1. One of ordinary skill in the art would appreciate that these servers in conjunction with the disclosed protocols include both hardware and software that enable session transfer. Supra, pp , 27; Ex. 1003, 99. Bates also addresses the need to reformat session data such that sessions may be transferred between different clients running different browsers and the session may be continued. Ex. 1004, 11: Bates highlights that [i]t is understood that formatting processes may be performed regardless of compatibility between browser types. Id. at 11: Bates notes that [i]nterfacing two or more applications is well-known in the art. Accordingly, a detailed discussion of interfacing methods and apparatus is not necessary. Id. at 11: One of ordinary skill in the art would be motivated to seek out art that concentrates on server-side implementation of session transfer between computers and that describes ways to reformat session data to aid session transfer amongst heterogeneous devices. Ex. 1003, One such reference is Chan. One of ordinary skill in the art would have been motivated to combine it with Bates. Id. at

36 Both Bates and Chan include disclosure of the same field: session transfer. Id. at 131. Both seek to solve the same problem: enabling a user to begin a session on one client and continue the session on another client. Id. Both provide examples of web browsing sessions. Id. One of ordinary skill in the art could have combined the server and data formatting functionality of Chan with the system of Bates via known methods. Id. at 135. The results of the combination would have been predictable to one of ordinary skill in the art. Id. 3. Bates and Chan Render Claims 1 and 23 Obvious To the extent the Board finds that Bates does not disclose a session transfer module, it is disclosed by Chan. Chan discloses multiple modules, including a service module and a statement management module which participate in and facilitate session transfer between devices. Ex. 1005, pp The service module performs session information processing and also serves as the pass through for the session state (i.e., session history) which includes bookmarks, history, cookies, etc. when the user migrates devices. Id.; see also FIG. 4. The state management module carries out the application transfer functions including [p]ackaging of selected state information for transfer and [t]ransfer of state information from the source to the destination device. Id. at 6. Because each of these modules participates in and facilitates session transfer between devices, the modules constitute a session transfer module both alone 31

37 and in combination. Ex. 1003, 136 [1d/23d]. 4. Bates and Chan Render Claims 2, 3 and 24 Obvious Bates renders dependent claims 2, 3 and 24 obvious. Supra, pp To the extent that the Board finds that Bates does not disclose the pushing step of these claims, Chan explicitly discloses a push model in which the source device initiates the transfer. Ex. 1005, p. 4. It would have been obvious to use this push model to push the session itself or a notification to the second device upon discontinuation so that the session could be transferred and resumed on the second device. Ex. 1003, 137 [2a/24a], 138 [3a]. 5. Bates and Chan Render Claims 4 and 25 Obvious Dependent claims 4 and 25 are substantially similar. Claim 4 requires accessing a device profile of said second device; and restructuring said session data to conform with said device profile of said second device. Claim 25 omits the word data, but is otherwise the same. Chan discloses these limitations. The main objective of these claims is the restructuring of the session (or the session data) so that it is compatible with the second computer. Chan teaches such restructuring via an adaptation layer. Ex. 1005, p. 6; Ex. 1003, 139 [4a/25a]. The primary goal of adaption is to allow an application to run efficiently over the resources that are currently available to it. Ex. 1005, p. 6. [A]daptation can be used to mitigate the effect of network and/or device handoffs. Id. The upper 32

38 adaptation layer provides support for an application to manage its features, performance, and data formatting. Device-or media-specific processing such as transcoding is performed in this layer. Id. The server includes a data component and multiple modules that work together to adapt or transcode session information. The data component is organized per user The per-user data component contains a device profile, a network profile, a state profile and an object store. Id. The dispatch module makes three major decisions: which servers to invoke, what kind of adaptation to perform, if needed, and to which network to send the message. Id. (italics in original). The service module then adapts the content to the new device. Id. at 7. When a user changes devices, Chan discloses that the system adapts the session to the new device. Id. at 6-7. It would have been obvious that in order to adapt or transcode (i.e., restructure) the session data or session to conform with a particular device profile, the device profile must first be accessed. Ex. 1003, 139 [4a/25a]. 6. Bates and Chan Render Claims 5 and 6 Obvious Dependent claims 5 and 6 both depend from claim 4, and respectively require that said restructured session data conforms to a data format of said second device and said restructured session data conforms to a modality of said second device. Chan discloses these elements. 33

39 Chan discloses adapting session data to a new data format or modality. Chan states, [t]he upper adaptation layer provides support for an application to manage its features, performance, and data formatting in response to resource changes of a new client. Ex. 1005, p. 6. Chan further teaches that when switching devices, the service module needs to perform adaptation for a number of reasons, including change in client display, change in client processing or memory characteristics, and change in network bandwidth (Table 1). Id. at 7. An important form of adaptation is transcoding. There are two basic transcoding mechanism[s]: changing information content and changing media format. Id. Changing format is required because of either incompatible media formats (e.g., a Postscript file and a plain text file) or incompatible media types (e.g., text and speech). Id. 7. Bates and Chan Render Claims 8 and 29 Obvious Dependent claim 8 adds two steps to claim 1: 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. Claim 29 is substantively identical to claim 8, except that claim 29 calls for an activation instead of said activation. The reformatting step: Both Bates and Chan disclose reformatting session histories. Bates teaches that the browser information (i.e., session history) 34

40 may be reformatted: [i]n one embodiment the interfacing software 250 operates to standardize the format of the buffer contents. Thus, steps 716 and 718 may include steps to convert browser information to a predetermined format recognizable to a receiving client computer irrespective of the sending or receiver browsing type. Ex. 1004, 11: Bates does not specifically disclose that the reformatting of the session history is done to conform with said device profile of said second device as required by claims 8 and 29. However, Chan discloses adapting or transcoding information, such as the state information. Ex. 1005, pp Chan further discloses that such adaptation or transcoding may occur using a device profile of a second device. Id. at 6; Ex. 1003, 141 [8a/29a]. The transmitting step: Bates and Chan disclose the transmitting step. Bates discloses transmitting reformatted browser information to a second client computer. Ex. 1004, 11: Bates further teaches sending the browser information in response to any number of user-selected events, including at boot up, upon user request and after idle period of the second client computer. Id. at 6:31-54, FIG. 6. These actions constitute transmitting in response to said activation of said second device because they each signify the second device has been activated. Ex. 1003, 141 [8b/29b]. Chan also discloses this step. According to Chan, when a user wants to switch to a second device, [h]e pulls out and powers on his HPC [handheld personal computer], waits for it to lock on the office 35

41 wireless LAN, then presses a key to transfer the conference states to it. Ex. 1005, p Bates and Chan Render Claim 9 Obvious Dependent claim 9 adds the step of accessing said session history of said session before the reformatting and transmitting steps of claim 8. Both Bates and Chan disclose this step. Bates teaches that the browser information is then used to reconfigure the browser program of the remote computer and restore the user to where he or she left off during the terminated browsing session. Ex. 1004, 10:65-11:1. Chan teaches when a client moves from one device to another, there is a [t]ransfer of state information from the source to the destination device. Ex. 1005, p. 6. In both situations, the session history (i.e., Bates browser information and Chan s state information ) must first be accessed before it may be reformatted or transmitted. Ex. 1003, 142 [9a]. 9. Bates and Chan Render Claims 10, 11, 30 and 31 Obvious Dependent claims 10, 11, 30 and 31 are similar to claims 5 and 6 in that they concern themselves with conforming to the data format and modality of the second device. However, rather than covering restructured session data, these claims cover formatted session history (claims 10-11) and reformatted session history (claims 30-31). Claim 10 requires that said formatted session history conforms to a data format of said second device. Claim 11 states that said formatted session 36