throbber

`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`
`
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`
`
`
`
`
`
`
`
`
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`REALTIME DATA LLC,
`Patent Owner.
`
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2016-01737
`Patent 8,880,862
`
`
`
`
`
`
`
`
`
`
`PETITIONER’S SUPPLEMENTAL BRIEF IN OPPOSITION TO
`PATENT OWNER’S MOTION TO AMEND
`
`
`

`

`I. 
`
`II. 
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`TABLE OF CONTENTS
`Sukegawa and Dye, Further Combined with either of Esfahani or Kroeker,
`Render Obvious the Substitute Claims ........................... 1 
`Settsu, Both Alone and in Combination with Zwiegincew, Renders Obvious
`the Substitute Claims ...................................................... 8 
`III.  Conclusion .................................................................... 12 
`
`
`
`
`
`
`
`i
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`UPDATED EXHIBIT LIST
`
`APPLE-1001
`
`U.S. Patent No. 8,880,862 to Fallon, et al. (“the ’862 patent”)
`
`APPLE-1002
`
`Excerpts from the Prosecution History of the ’862 Patent (“the
`Prosecution History”)
`
`APPLE-1003
`
`Declaration of Dr. Charles J. Neuhauser (“Dec.”)
`
`APPLE-1004
`
`Curriculum Vitae of Dr. Charles J. Neuhauser
`
`APPLE-1005
`
`U.S. Patent No. 5,860,083 (“Sukegawa”)
`
`APPLE-1006
`
`U.S. Patent No. 6,374,353 (“Settsu”)
`
`APPLE-1007
`
`Burrows et al., “On-line Data Compression in a Log-structured
`File System” (1992) (“Burrows”)
`
`APPLE-1008
`
`U.S. Patent No. 6,145,069 (“Dye”)
`
`APPLE-1009
`
`U.S. Patent No. 7,190,284 (“Dye ’284”)
`
`APPLE-1010
`
`U.S. Patent No. 6,317,818 (“Zwiegincew”)
`
`APPLE-1011
`
`Jeff Prosise, DOS 6 – The Ultimate Software Bundle?, PC
`MAGAZINE, Apr. 13, 1993 (“Prosise”)
`
`APPLE-1012
`
`Excerpts from John L. Hennessey & David A. Patterson,
`Computer Architecture a Quantitative Approach (1st ed. 1990)
`(“Hennessey”)
`
`APPLE-1013
`
`(RESERVED)
`
`APPLE-1014
`
`File, Microsoft Press Computer Dictionary (3d ed. 1997)
`
`APPLE-1015
`
`Excerpts from Tom Shanley & Don Anderson, PCI System
`Architecture, (4th ed. 1999) (“Shanley”)
`
`
`
`ii
`
`

`

`APPLE-1016
`
`APPLE-1017
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Jacob Ziv & Abraham Lempel, A Universal Algorithm for
`Sequential Data Compression, IT-23 No. 3 IEEE
`TRANSACTIONS ON INFORMATION THEORY 337 (1977)(“Ziv”)
`
`James A. Storer & Thomas G. Szymanski, Data Compression
`via Textual Substitution, 19 No. 4 JOURNAL OF THE
`ASSOCIATION FOR COMPUTING MACHINERY (1982)(“Storer”)
`
`APPLE-1018
`
`Program File, Microsoft Press Computer Dictionary (3d ed.
`1997)
`
`APPLE-1019
`
`Direct Memory Access, Microsoft Press Computer Dictionary
`(3d ed. 1997)
`
`APPLE-1020
`
`RAM and RAM Cache, Microsoft Press Computer Dictionary
`(3d ed. 1997)
`
`APPLE-1021
`
`Decoder, Microsoft Press Computer Dictionary (3d ed. 1997)
`
`APPLE-1022
`
`(RESERVED)
`
`APPLE-1023
`
`Excerpts from Kyle Loudon, Mastering Algorithms with C
`(1999) (“Loudon”)
`
`APPLE-1024
`
`Excerpts from Michael Barr, Programming Embedded Systems
`in C and C++ (1999) (“Barr”)
`
`APPLE-1025
`
`Excerpts from Eric Pearce, Windows NT in a Nutshell (1999)
`(“Pearce”)
`
`APPLE-1026
`
`Excerpts from Tim O’Reilly, Troy Mott, and Walter Glenn,
`Windows NT in a Nutshell (1999) (“O’Reilly”)
`
`APPLE-1027
`
`Cache, Microsoft Press Computer Dictionary (3d ed. 1997)
`
`APPLE-1028
`
`Declaration of Michael Bittner in support of Petitioner's Motion
`for Pro Hac Vice Admission
`
`
`
`iii
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`
`APPLE-1029
`
`RESERVED
`
`APPLE-1030
`
`Second Declaration of Dr. Charles Neuhauser
`
`APPLE-1031
`APPLE-1032
`APPLE-1033
`APPLE-1034
`
`U.S. Patent No. 6,117,187 (“Staelin”)
`U.S. Patent No. 5,625,809 (“Dysart”)
`U.S. Patent No. 5,590,331 (“Lewis”)
`Directory, The Dictionary of Computing & Digital Media
`(1999)
`
`APPLE-1035
`
`Directory, Prentice Hall’s Illustrated Dictionary of Computing
`(Third Edition, 1998)
`
`APPLE-1036
`
`U.S. Patent No. 5,915,252 (“Misheski”)
`
`APPLE-1037
`
`U.S. Patent No. 5,809,295 (“Straub”)
`
`APPLE-1038
`
`U.S. Patent No. 6,633,968 (“Zwiegincew ’968”)
`
`APPLE-1039
`
`Defendant Apple Inc.’s Invalidity Contentions, Case No. 4:16-
`cv-02595-JD (N.D. Cal.)
`
`APPLE-1040
`APPLE-1041
`
`Transcript of June 20, 2017 Deposition of Dr. Back
`Encoder, Microsoft Press Computer Dictionary (5th ed. 2002)
`
`APPLE-1042
`
`Encoder, The Computer Desktop Encyclopedia (2nd ed. 1999)
`
`APPLE-1043
`
`Third Declaration of Dr. Charles Neuhauser
`
`
`
`
`
`
`
`iv
`
`

`

`I.
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Sukegawa and Dye, Further Combined with either of Esfahani or
`Kroeker, Render Obvious the Substitute Claims
`As explained in Petitioner’s Opposition, a POSITA would have been aware
`
`of the high cost as well as the capacity constraints of the non-volatile flash memory
`
`discussed in Sukegawa. Dec. of Dr. Charles J. Neuhauser (“Ex. 1043”), ¶11. Indeed,
`
`seeking to minimize reliance on this expensive and limited memory, a POSITA
`
`would have found it obvious to use less costly volatile memory (RAM) when
`
`preloading boot data in a manner consistent with Sukegawa. Id. Beyond reducing
`
`costs, a POSITA would expect this approach to enhance efficiency. Id.
`
`As explained below and in Ex. 1043, Esfahani and Kroeker each provide
`
`teachings that further motivate and support such an implementation of Sukegawa’s
`
`system – an implementation which meets the amended claims. Id., ¶12.
`
`The teachings of Esfahani and Kroeker would not contradict the application
`
`of Sukegawa, Dye, and the other references, as discussed in the Petition for Grounds
`
`1-5. Indeed, alongside modifications of Sukegawa motivated by Esfahani and
`
`Kroeker, a POSITA would have maintained use of the features of Sukegawa, Dye,
`
`and the other references as applied in the Petition to the challenged claims. Id., ¶26.
`
`For instance, a POSITA would have maintained usage of boot data lists (as described
`
`by Sukegawa, Settsu, and Zwiegincew) to manage preloading of boot data among
`
`non-volatile and volatile memories. Id., ¶51. And, a POSITA would have
`
`maintained the use of compression on preloaded data (as described by Dye, Settsu,
`
`
`
`1
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Burrows, and Zwiegincew) to achieve the size and speed benefits discussed
`
`throughout the Petition. Id. To these points, Realtime’s amendments are
`
`“contingent on the outcome of this trial,” and the proposed substitute claims are only
`
`relevant “in the event the Board finds independent claims 1, 6, and 13 unpatentable.”
`
`MTA, 1. It follows that, for purposes of the MTA, the alleged patentability of the
`
`proposed substitute claims therefore rests squarely in the amended limitations.
`
`Esfahani – Recognizing that RAM and disk space are “inexpensive” and
`
`“fast” compared to ROM, Esfahani proposes distributing OS code across boot ROM
`
`and disk, with code in disk being maintained in compressed format. Esfahani, 2:54-
`
`61. Upon power-up/reset “the code in the boot ROM is executed to read the
`
`compressed [data] into RAM,” and that data is thereafter “decompressed and
`
`executed as part of the boot sequence.” Id., 2:63-67. By preloading into both ROM
`
`and RAM, Esfahani reduces costs. Id., 4:38-5:21; Ex. 1043, ¶46.
`
`With this background, a POSITA would have been motivated to arrive at the
`
`modification of Sukegawa proposed in Petitioner’s Opposition. Ex. 1043, ¶50. For
`
`instance, a POSITA would have found Esfahani’s benefits directly applicable to
`
`Sukegawa’s system, and would therefore have been motivated to modify Sukegawa
`
`to preload OS data into both non-volatile and volatile memories, as discussed in
`
`Esfahani, so as “to reduce time to market, development costs, and manufacturing
`
`costs for computer systems.” Esfahani, 2:1-3; Ex. 1043, ¶47.
`
`
`
`2
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`To achieve Esfahani’s cost benefits, a POSITA would have limited the
`
`amount of Sukegawa’s flash used for boot data, and would have followed Esfahani’s
`
`approach of preloading into flash only portions of the OS that are expected to be
`
`needed soon after power-on. Ex. 1043, ¶48; Esfahani, Abs, 2:6-28, 2:54-67.
`
`Consistent with Esfahani, a POSITA would have maintained portions expected to be
`
`requested later in the boot process as compressed data on Sukegawa’s HDD 2, and
`
`would have preloaded those portions into volatile memory. Ex. 1043, ¶48.
`
`In implementing these modifications, a POSITA would have been guided by
`
`Esfahani’s suggestion to preload compressed OS data into RAM “during start-up,”
`
`and to thereafter decompress the same to allow execution consistent with requests
`
`that would subsequently be received in a typical boot process. Esfahani, 5:41-53,
`
`10:28-41; FIGS. 6A-7D (illustrating Esfahani’s boot process). Indeed, Esfahani
`
`explains that its data is preloaded into RAM because it “supports any hardware that
`
`is expected (or likely) to be used.” Id., 5:65-6:6; 7:25-65. In this way, Esfahani
`
`transfers data into RAM that is expected to be requested similarly to how the ’862
`
`Patent preloads “expected data requests.” Id.; ’862, 21:43-48; Ex. 1043, ¶¶49, 63.
`
`For the reasons discussed above, a POSITA would have been motivated by
`
`Esfahani to modify Sukegawa to preload OS data into both non-volatile flash
`
`memory and volatile RAM. Ex. 1043, ¶46. As explained, to reduce costs, a POSITA
`
`would have been motivated to limit the amount of flash memory used by preloading
`
`
`
`3
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`into flash memory only a portion of OS data requested shortly after power-on. Id.,
`
`¶50; Esfahani, Abs, 2:1-28, 2:54-67. In keeping with this approach, a POSITA
`
`would have been motivated to store other OS data on disk and to preload that data
`
`into RAM, making it available for use later in the boot process. Ex. 1043, ¶50;
`
`Esfahani, Abs, 2:1-28, 2:54-67. With this approach, the POSITA would have
`
`utilized a modified Sukegawa system that preloads OS data needed after power-on
`
`(expected data) by transferring that OS data into volatile memory during the same
`
`boot sequence in which its boot device controller receives a command over a
`
`computer bus to load the boot data. Ex. 1043, ¶50; Sukegawa, 5:10-6:58; Esfahani,
`
`Abs, 2:1-28, 2:54-67.
`
`In addition, to identify OS data expected (or likely) to be used next in the boot
`
`process, a POSITA would have found it obvious to leverage and manage
`
`Sukegawa’s boot data lists in the manner described in the Petition. Ex. 1043, ¶51;
`
`Sukegawa, 5:10-6:58. And,
`
`a POSITA would have
`
`still
`
`employed
`
`compression/decompression on the OS data preloaded in RAM to achieve the
`
`benefits of compression/decompression set forth in the Petition. Ex. 1043, ¶51; Dye,
`
`Abs, 2:32-39, 3:3-28, 4:44-55, 7:31-58, 17:19-38. Indeed, Esfahani itself uses
`
`compression/decompression on OS data preloaded into RAM. Esfahani, Abs, 5:41-
`
`53. In this regard, the analysis presented in this section demonstrates how Esfahani
`
`combines with Sukegawa to render obvious the new claim language, and does not
`
`
`
`4
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`contradict the Petition’s application of Sukegawa, Dye, and other references to the
`
`unamended claim language. Ex. 1043, ¶¶44-61.
`
`Kroeker – Kroeker also suggests reducing Sukegawa’s flash by preloading
`
`boot data into volatile memory. In fact, Kroeker recognizes the same problem as the
`
`’862 Patent and proposes the same solution as the amended claims – preloading boot
`
`data associated with a boot data list by transferring data into volatile memory during
`
`the same boot sequence in which a boot device controller receives a command over
`
`a computer bus to load the boot data. Kroeker, Abs, 2:29-47; Ex. 1043, ¶15.
`
`Kroeker explains that, “[w]hen a computer undergoes a hardware reset (i.e., a
`
`power-on or reset), the computer” and its “hard disk drive” execute “power on/reset
`
`procedures.” Kroeker, 1:14-29. Kroeker recognized that computers wait for these
`
`procedures to complete before “request[ing] data from the disk” to initialize an OS.
`
`Id. Seeking to speed the boot process, Kroeker proposed to take advantage of unused
`
`time “before the host computer is ready for program transfer.” Id., 1:55-64. In
`
`particular, “before the host computer is ready for a data request but after the disk
`
`drive has completed its reset routine,” Kroeker uses a “prefetch table” to access OS
`
`data from the disk and “cop[y] it onto the cache of the disk drive, from where it is
`
`transferred to the host computer.” Id., Abs. This approach allows Kroeker to speed
`
`data transmission to the host computer, yielding “increas[ed] boot speed of a host
`
`computer” consistent with preloading. Id., Abs, 1:9-12.
`
`
`
`5
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`In more detail, Kroeker preloads OS data from data storage disks 16 of hard
`
`disk drive 12 into cache 18 using a process (FIG. 3) that begins “immediately after
`
`the hard disk drive 12 has completed its power-on/reset…routine.” Id., 4:63-67.
`
`Kroeker preloads data “represented by [a] prefetch table” “from the disks 16 into the
`
`RAM cache 18.” Id., 4:63-5:21. Thereafter, a read command (command to load) is
`
`received by the controller “indicating that the host computer 14…is requesting [OS]
`
`data records,” and the requested records are transferred “from cache 18 to the host
`
`computer 14.” Id., 5:41-6:13. Kroeker’s process repeats until “all records designated
`
`in the prefetch table have been loaded into cache and thereafter requested and
`
`correspondingly transferred to the host computer 14.” Id., 6:14-36.
`
`A POSITA would have been motivated by Kroeker to update Sukegawa’s
`
`system to take advantage of the period “before the host computer is ready for data
`
`but after the disk drive has completed its reset routine” to further “increas[e] boot
`
`speed of a host computer” by “shortening the load time.” Id., Abs, 1:9-12; 1:55-
`
`2:14; Ex. 1043, ¶22. Indeed, a POSITA would have found it obvious for at least
`
`some portion of the operating system to be stored on Sukegawa’s HDD 2 given
`
`capacity/cost issues for flash memory. Ex. 1043, ¶22. For that portion, a POSITA
`
`would have been motivated to apply Kroeker’s preloading techniques to shorten the
`
`load time from the hard disk and, thereby, increase boot speed. Id.; Kroeker, Abs,
`
`1:9-12; 1:55-2:14. As Dr. Neuhauser explains, a POSITA would have been
`
`
`
`6
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`motivated to add Kroeker’s volatile cache to Sukegawa’s HDD 2. Ex. 1043, ¶22.
`
`Indeed, a POSITA would have been motivated by Kroeker to transfer some portion
`
`of OS boot data stored on Sukegawa’s HDD 2 into Kroeker’s volatile cache “before
`
`the host computer is ready for data but after the disk drive has completed its reset
`
`routine.” Id.; Kroeker, Abs. In fact, a POSITA would have found leveraging RAM
`
`during the period when the disk drive is ready, but the host computer is not, to be an
`
`“easy to use and cost-effective” solution “for increasing boot speed” that reduces the
`
`amount of flash memory used. Ex. 1043, ¶23; Kroeker, Abs, 1:9-2:14.
`
`To facilitate this preloading, a POSITA would have found it obvious to use
`
`Sukegawa’s management information table 3A and/or Kroeker’s prefetch table as a
`
`boot data list. Ex. 1043, ¶22. Indeed, Sukegawa’s table 3A is used to determine
`
`whether data “to be accessed” during boot “is stored in the flash memory unit 1,”
`
`and a POSITA would have found it obvious to use table 3A to determine that data
`
`to be accessed during boot is not stored in flash memory and, consequently, should
`
`be preloaded into RAM. Sukegawa, 5:1-61, 6:32-58; Ex. 1043, ¶¶32-35. Similarly,
`
`a POSITA also would have found it obvious to leverage Kroeker’s prefetch table,
`
`which is a boot data list that includes “a listing of the disk locations and lengths of
`
`data records that were requested by the host computer 14 in the immediately previous
`
`power-on/reset.” Kroeker, 5:3-7. And, a POSITA would have still employed
`
`compression/decompression on the OS data preloaded in RAM to achieve the
`
`
`
`7
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`benefits of compression/decompression set forth in the Petition. Ex. 1043, ¶40; Dye,
`
`Abs, 2:32-39, 3:3-28, 4:44-55, 7:31-58, 17:19-38. In this regard, the analysis
`
`presented in this section demonstrates how Kroeker combines with Sukegawa to
`
`render obvious the new claim language, and does not contradict the Petition’s
`
`application of Sukegawa, Dye, and other references to the unamended claim
`
`language. Ex. 1043, ¶¶15-43.
`
`II.
`
`Settsu, Both Alone and in Combination with Zwiegincew, Renders
`Obvious the Substitute Claims
`As explained in Petitioner’s Opposition, Settsu, both alone and in view of
`
`Zwiegincew, renders obvious every feature of the substitute claims. Opposition, 9-
`
`25; APPLE-1030, ¶17. Below is further discussion of: (1) how Settsu and
`
`Zwiegincew render obvious the preloading features of the substitute claims and (2)
`
`why a POSITA would have been motivated to combine Settsu and Zwiegincew.
`
`Preloading – The substitute claims recite “preloading” and they specify its
`
`timing – preloading must occur “during the same boot sequence in which a boot
`
`device controller receives a command over a computer bus to load the portion of
`
`boot data,” but preloading need not occur before receipt of any command.
`
`Consistently, the ’862 Patent specification describes preloading as loading data
`
`associated with an expected data request, and confirms that preloading is triggered
`
`by a command to load, which may be received over a computer bus during the
`
`same boot sequence. ’862, Abs, 3:41-52, 6:40-7:8, 7:59-67, 21:24-22:11; see also
`
`
`
`8
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`IPR2016-01365, Ex. 2008, ¶¶47-55 (construing “preloading” as “transferring data
`
`in anticipation of immediate or near-in-time use” without reference to a command).
`
`Indeed, the ’862 Patent describes preloading as occurring both
`
`simultaneously with booting (after computer bus initialization) and responsive to a
`
`command. According to the ’862 Patent, “depending on the resources of the given
`
`system (e.g., memory, etc.)…the preloading process may be…continued after the
`
`boot process begins (in which case booting and preloading are performed
`
`simultaneously).” ’862, 21:43-22:4. Also, the ’862 Patent describes that, to “read
`
`disk data,” a “DMA transfer is setup from the disk interface 14 to the onboard
`
`cache memory 13,” and that, “[t]o initiate a transfer from the disk 11 to the cache
`
`13,” the “DMA transfer is setup via specifying the appropriate command (read
`
`disk).” ’862, 4:36-37, 6:54-7:8.
`
`
`
`Thus, under BRI, a POSITA would have understood that preloading is broad
`
`enough to include transfer of data from disk into memory based on a command to
`
`load that is received by the controller over a computer bus. Ex. 1043, ¶¶63-71.
`
`Settsu performs the claimed preloading. For instance, in response to a
`
`command received over a computer bus, Settsu loads boot data associated with an
`
`expected data request, prior to the expected data request being received, and, thus,
`
`performs “preloading” as claimed. Id., ¶72; Opposition, 11-20. In more detail,
`
`Settsu describes an OS “main body module” that is “divided into a plurality of
`
`
`
`9
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`functional modules” that “are separately stored as compressed files” in “file system
`
`5 of boot device 3.” Settsu, 1:67-2:3, 2:5-67, 7:65-8:23, 13:55-65, FIG. 12. In a
`
`series of operations that begin “[w]hen the information processing apparatus is
`
`powered on,” Settsu’s mini OS module 7 preloads the OS main body module’s
`
`plurality of compressed files by transferring those files from boot device 3 into
`
`memory 2 prior to data in those files being needed. Id., Abs, 8:21-35, 8:66-9:11,
`
`11:7-9; APPLE-1030, ¶41.
`
`Notably, Settsu describes that “load processing and the OS initialization
`
`processing can be performed in parallel with each other after any one of the
`
`plurality of functional modules of the OS main body is loaded into memory.”
`
`Settsu, 12:6-16; 15:62-16:4. With parallel processing, Settsu loads one functional
`
`module while another is being initialized, so “the CPU does not idle.” Ex. 1043,
`
`¶73. In this way, while a first functional module is being initialized, a second
`
`functional module is preloaded prior to its initialization and, thus, before it is
`
`needed. Id. Through this parallel loading, Settsu further describes preloading
`
`during the same boot sequence in which a boot device controller receives a
`
`command over a computer bus to load the portion of boot data. Id. Indeed,
`
`Settsu’s simultaneous initializing and loading aligns closely with Sukegawa’s
`
`simultaneous booting and preloading. Id.; ’862, 21:43-22:4.
`
`
`
`10
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Additionally, as discussed in the Opposition, Zwiegincew’s prefetching
`
`clearly meets the preloading set forth in the substitute claims. Opposition, 15-16.
`
`And, as discussed in the Opposition and below, a POSITA would have found it
`
`obvious to apply Zwiegincew’s prefetching in Settsu. Id., Ex. 1043, ¶74.
`
`Combination – As discussed in the Opposition, a POSITA would have
`
`understood that Settsu’s system would have benefited from Zwiegincew’s
`
`preloading techniques, even with those techniques leveraging virtual memory.
`
`Opposition, 14; Settsu, 8:51-52, 9:56-66, 16:7-17:62, 16:26-31, 17:5-20, FIGS.
`
`14(ST185), 20(ST213). Indeed, Settsu itself describes that “any one” of the OS
`
`“functional modules 16 to 22” may be loaded “first.” Settsu, 11:31-33, 14:26-28.
`
`From this, a POSITA would have found it obvious to load Settsu’s virtual memory
`
`module 22 first, to enable Zwiegincew’s preloading techniques during the
`
`remainder of boot and achieve Zwiegincew’s benefits of avoiding detrimental hard
`
`page faults. Id.; Ex. 1043, ¶75; Zwiegincew, 1:45-51, 2:12-15, 5:50-51.
`
`Additionally, Settsu describes use of a function definition file to load and
`
`enable one OS module included within Settsu’s OS main body (e.g., module 22)
`
`prior to the others, so as to allow for specific processes to occur faster during boot.
`
`Settsu, 16:7-17:62, FIGS. 17-20. Settsu explains that “an application module 70”
`
`can “run on the OS when booting up the information processing apparatus,” and
`
`that the “application module 70 includes a function definition file 71…listing…OS
`
`
`
`11
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`functional modules, such as some of the plurality of OS functional modules 16 to
`
`22, required for the application…to run.” Id., 16:23-30. During boot, Settsu’s
`
`mini OS module loads each listed module into memory, and then starts the
`
`application module 70. Settsu, 17:1-20. As Dr. Neuhauser explains, a POSITA
`
`seeking to use Zwiegincew’s techniques in Settsu’s system would have used a
`
`function definition file 71 to ensure that Settsu’s virtual memory processing
`
`module 22 is preloaded and enabled prior to other modules. Ex. 1043, ¶¶76-77. A
`
`POSITA would have been motivated to employ Settsu’s function definition file in
`
`this manner to achieve Zwiegincew’s benefits of using virtual memory prefetching
`
`to avoid hard page faults that otherwise might slow the boot process. Id., ¶77.
`
`Zwiegincew, moreover, mentions the benefit of reducing “hard page faults”
`
`during “boot,” confirming the ability to use virtual memory pages during “boot.”
`
`Zwiegincew, 2:12-15. Indeed, in a CIP, Zwiegincew himself explicitly and
`
`unequivocally described that his prefetching of scenario files was operational and
`
`useful during OS boot. Ex. 1038, Abs, 2:65-3:16, 11:59-12:4, 14:20-43. These
`
`teachings from Zwiegincew corroborate Dr. Neuhauser’s opinion that
`
`Zwiegincew’s virtual memory prefetching would have been suitable and desirable
`
`to use in Settsu’s boot process. Ex. 1043, ¶78.
`
`III. Conclusion
`Petitioner submits that Realtime’s Motion to Amend should be denied.
`
`
`
`12
`
`

`

`
`
`
`Date: November 10, 2017
`
`
`
`
`
`
`
`
`
`Date: November 10, 2017
`
`
`
`
`
`
`
`
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Respectfully submitted,
`
`
`
`
`
`/W. Karl Renner/
`W. Karl Renner, Reg. No. 41,265
`Jeremy Monaldo, Reg. No. 58,680
`Fish & Richardson P.C.
`3200 RBC Plaza
`60 South Sixth Street
`Minneapolis, MN 55402
`T: 202-783-5070
`F: 877-769-7945
`
`/Jeremy J. Monaldo/
`W. Karl Renner, Reg. No. 41,265
`Jeremy Monaldo, Reg. No. 58,680
`Fish & Richardson P.C.
`3200 RBC Plaza
`60 South Sixth Street
`Minneapolis, MN 55402
`T: 202-783-5070
`F: 877-769-7945
`
`Attorneys for Petitioner
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`13
`
`

`

`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`
`
`
`CERTIFICATE OF SERVICE
`
`Pursuant to 37 CFR §§ 42.6(e)(1) and 42.6(e)(4)(iii), the undersigned
`
`certifies that on November 10, 2017, a complete and entire copy of this Petitioner’s
`
`Supplemental Brief in Opposition to Patent Owner’s Motion to Amend and Exhibit
`
`1043 were provided via email to the Patent Owner by serving the email
`
`correspondence addresses of record as follows:
`
`Joseph F. Edell, Richard Z. Zhang, Desmond S. Jui (pro hac vice)
`Fisch Sigler LLP
`5301 Wisconsin Avenue NW, Fourth Floor
`Washington, DC 20015
`
`William P. Rothwell, Kayvan B. Noroozi (pro hac vice)
`Noroozi PC
`2245 Texas Drive, Suite 300
`Sugar Land, TX 77479
`
`Email: Joe.Edell.IPR@fischllp.com
`Richard.Zhang.IPR@fischllp.com
`Desmond.Jui.IPR@fischllp.com
`William@nooozipc.com
`Kayvan@noroozipc.com
`
`/Diana Bradley/
`
`Diana Bradley
`Fish & Richardson P.C.
`60 South Sixth Street, Suite 3200
`Minneapolis, MN 55402
`(858) 678-5667
`
`
`
`
`
`
`
`
`
`
`
`
`
`

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

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

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

throbber

A few More Minutes ... Still Working

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

Thank you for your continued patience.

This document could not be displayed.

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

Your account does not support viewing this document.

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

Your account does not support viewing this document.

Set your membership status to view this document.

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

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

Become a Member

One Moment Please

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

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

Your document is on its way!

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

Sealed Document

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

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


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket