`
`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 OPPOSITION TO
`PATENT OWNER’S MOTION TO AMEND
`PURSUANT TO 37 C.F.R. § 42.23
`
`
`
`
`I.
`II.
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`TABLE OF CONTENTS
`Introduction ...................................................................................................... 1
`Realtime Failed to Meet its Burden of Demonstrating the Patentability of the
`Proposed Substitute Claims ............................................................................. 1
`A. Precedent Establishes that Realtime Bears the Burden of Demonstrating
`Patentability of Substitute Claims ............................................................ 1
`B. Realtime Has Failed to Demonstrate Patentability ................................... 2
` Realtime Failed to Sufficiently Address Known Prior Art
` ……………………………………………………………..2
` Realtime Failed to Properly Assess Obviousness By
`Addressing References Individually ………………………..5
` Realtime Has Failed to Demonstrate Patentability Over the
`Prior Art at Issue in this Proceeding …………………6
`Prior Art of Record Renders Obvious the Proposed Substitute Claims .......... 9
`A. Settsu, Alone and in Combination with Zwiegincew, Renders Obvious
`the Substitute Independent Claims ......................................................... 10
`B. Settsu, Alone and in Combination with Zwiegincew, Renders Obvious
`the Substitute Dependent Claims ............................................................ 23
`IV. Conclusion ..................................................................................................... 25
`
`
`
`III.
`
`
`
`i
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`
`I.
`
`Introduction
`Patent Owner’s Motion to Amend (“MTA”) should be denied for at least two
`
`reasons. First, Patent Owner (Realtime) failed to meet its burden of proof under 37
`
`C.F.R. § 42.20(c), by failing to demonstrate novelty and non-obviousness of the
`
`proposed substitute claims. See MTA, 18-24. Second, and as demonstrated in detail
`
`below, prior art of record renders the substitute claims obvious.
`
`II. Realtime Failed to Meet its Burden of Demonstrating the Patentability
`of the Proposed Substitute Claims
`A.
`Precedent Establishes that Realtime Bears the Burden of
`Demonstrating Patentability of Substitute Claims
`Realtime asserts that “the Board may not sua sponte question the patentability
`
`of the proposed amended claims” and that Realtime “should not bear the burden of
`
`either persuasion or production regarding the patentability of the amended claims as
`
`a condition of allowance…” MTA, 1.
`
`Yet, the Federal Circuit’s precedent has consistently upheld the Board’s
`
`approach of allocating the burden of demonstrating patentability to patent owners
`
`seeking amendments. See, e.g., Microsoft Corp. v. Proxyconn, Inc., 789 F.3d 1292,
`
`1307-08 (Fed. Cir. 2015), In Nike, Inc. v. Adidas AG, 812 F.3d 1326 (Fed. Cir. 2016).
`
`Indeed, and as the Board has recognized, Section 42.20(c) “places the burden
`
`on the patent owner to show a patentable distinction of each proposed substitute
`
`claim over the prior art.” Idle Free Sys., Inc. v. Bergstrom, Inc., IPR2012-00027 at
`
`7 (PTAB June 11, 2013)(Paper 26).
`
`
`
`1
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`B. Realtime Has Failed to Demonstrate Patentability
`Realtime has failed to meet the burden imposed by § 42.20(c), at least because
`
`it has failed to sufficiently address known prior art, failed to properly assess
`
`obviousness of the substitute claims, and failed to adequately explain why the
`
`proposed substitute claims are patentable over the prior art of record, and to
`
`demonstrate the same by evidence. Indeed, the arguments offered by Realtime in
`
`support of its proposed substitute claims are highly conclusory, and misrepresent
`
`what is disclosed and suggested by that art. See MTA, 18-25. Further, Dr. Back’s
`
`declaration submitted in support of the MTA repeats Realtime’s arguments nearly
`
`verbatim, and without additional support. See REALTIME-2022, ¶¶56-71.
`
`
`Realtime Failed to Sufficiently Address Known Prior Art
`In the MTA, Realtime limited its analysis to five prior art references cited in
`
`this IPR and four prior art references discussed in the prosecution history of the
`
`’862 patent. With this limited treatment, as discussed below, Realtime failed to
`
`properly address known prior art from the prosecution of the ’862 patent and
`
`related applications, failed to address known prior art raised in the related
`
`litigation, and failed to address knowledge of the inventors and POSITAs.
`
`a)
`
`Realtime Has Failed to Demonstrate Patentability Over
`the Prior Art at Issue During Prosecution
`With respect to the prior art at issue during prosecution, Realtime and its
`
`expert restrict their treatment to four conclusory paragraphs regarding each of four
`
`
`
`2
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`references that they characterize as “material.” MTA, 24; REALTIME-2022, ¶66-
`
`71. Realtime neglects to mention that the ’862 patent features a listing of cited
`
`references that spans twenty-nine pages, listing literally hundreds of references.
`
`APPLE-1001, 1-29. Realtime submitted these references as material during
`
`prosecution, placing the burden on the USPTO to consider these references so as to
`
`gain a presumption of validity over them. Yet, when Realtime has the burden to
`
`prove patentability, as it does here, it addresses only a handful references in
`
`conclusory manner. Realtime simply cannot ignore large swaths of prior art itself
`
`submitted as material to the ’862 patent and still meet its burden of proving
`
`patentability. Notably, Realtime also failed to consider references raised and
`
`discussed during prosecution of applications related to the ’862 patent. This
`
`treatment is insufficient to prove patentability.
`
`b)
`
`Realtime Has Failed to Demonstrate Patentability Over
`the Prior Art at Issue in Related Matters
`Realtime also neglects to address prior art at issue in related matters. In
`
`related litigation, Apple submitted invalidity contentions mapping a variety of
`
`references to claims of the ’862 patent, and of related U.S. Patent Nos. 7,181,608
`
`and 8,090,936. APPLE-1039. Notably, Apple’s detailed mappings applied these
`
`references to claim features that are similar to those presented by Realtime in the
`
`amendments at issue in this proceeding. See, e.g., APPLE-1039, 27 (listing
`
`references said to disclose “preloading boot data, including loading into a cache and
`
`
`
`3
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`loading prior to completion of initialization of the processor”). Yet, Realtime makes
`
`no mention of the majority of these references, instead representing that its MTA
`
`“discusses the known art closest to the features highlighted above” and that
`
`“Realtime is not aware of any other prior art material to the claimed elements or the
`
`system as a whole.” MTA, 18. Realtime, however, was certainly aware of Apple’s
`
`contentions, but chose to ignore them. Realtime should not be rewarded for ignoring
`
`invalidity contentions and cannot proven patentability without analyzing them.
`
`c)
`
`Realtime Failed to Consider Prior Art Known to the
`Inventors and the State of the Art
`Realtime failed to provide any evidence of prior art known by the inventors
`
`or evidence that the amended features would have been deemed patentable by the
`
`inventors. Realtime also failed to properly assess the state of the art or adequately
`
`explain why the amended claims features would not have been within the grasp of
`
`those of skill, particularly when the original claims are found unpatentable.
`
`In proving nonobviousness, Realtime may not limit its consideration of prior
`
`art to only those pre-existing in the record of the involved cases. While it is true that
`
`Realtime cannot be expected to account for the entire body of prior art in existence,
`
`Realtime is required to account for that prior art which its inventors are aware or is
`
`otherwise known to Realtime, including prior art provided to Realtime during
`
`litigation and prior art Realtime submitted as material. Realtime’s focus upon only
`
`selected prior art reflects a misunderstanding it’s burden of proof. Indeed, Dr.
`
`
`
`4
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Back’s testimony is based only on selected prior art of record and Realtime has not
`
`pointed to any representation by Dr. Back that he analyzed all prior art known to
`
`Realtime, or considered what would have been obvious to a POSITA given the state
`
`of the art. With limited analysis, Realtime lacks evidence needed to meet its burden.
`
`
`
`Realtime Failed to Properly Assess Obviousness By
`Addressing References Individually
`In its treatment of the prior art that it chooses to acknowledge, Realtime
`
`attacks references individually, and without proper consideration of obviousness.
`
`See MTA, 18-25. For example, Realtime separately addresses the art at issue in this
`
`proceeding and the art that was at issue during prosecution, but does not consider
`
`the art from these two categories together, or how that art might combine to render
`
`the proposed substitute claims obvious. Id. Instead, in attacking the references,
`
`Realtime picks disparate features that are said to be lacking in each reference, but
`
`does not present a unifying amended feature missing from each reference. Id.
`
`In
`
`fact,
`
`the only
`
`feature
`
`listed
`
`for
`
`the Esfahani
`
`reference,
`
`is
`
`“decompressing…”, a feature that is necessarily found in the art at issue in this
`
`proceeding should Realtime’s contingent motion to amend even be considered.
`
`MTA, 25. By relying on this feature alone, Realtime tacitly admits that Esfahani
`
`discloses the amended claim features. With this posture, Realtime’s failure to
`
`consider the obviousness of Esfahani in view of Sukegawa, Dye, Settsu, Burrows,
`
`and/or Zwiegincew necessarily makes Realtime’s motion to amend deficient.
`
`
`
`5
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Stated differently, by focusing on different features across the prior art
`
`references, Realtime’s MTA suggests existence of all claim features in those prior
`
`art references, but does not provide sufficient discussion for why a POSITA would
`
`not have combined the references and, thus, has not met its burden of showing why
`
`the substitute claims are non-obvious. See In re Keller, 642 F.2d 413 (CCPA 1981);
`
`In re Merck & Co., Inc., 800 F.2d 1091 (Fed. Cir. 1986).
`
`
`
`Realtime Has Failed to Demonstrate Patentability Over the
`Prior Art at Issue in this Proceeding
`Realtime submits its amendments “contingent on the outcome of this trial,”
`
`and requests that the Board grant the MTA and issue the proposed substitute claims
`
`only “in the event the Board finds independent claims 1, 6, and 13 unpatentable…”
`
`MTA, 1. It follows that, for purposes of the Board’s decision regarding the MTA,
`
`the alleged patentability of the proposed substitute claims rests solely in the amended
`
`limitations themselves. Those limitations are directed toward trivial features that a
`
`POSITA would have considered obvious over the prior art of record, including prior
`
`art at issue in this proceeding. See Section III., APPLE-1030, ¶17; MTA, 2-3.
`
`Realtime nevertheless suggests that these amendments distinguish the
`
`proposed substitute claims over Sukegawa because “Sukegawa is expressly directed
`
`to using a non-volatile memory to permanently store data needed for system startup,
`
`rather than using a volatile cache” (emphasis in original). MTA, 20.
`
`
`
`6
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Realtime neglects to address, however, Sukegawa’s disclosure of main
`
`memory 23, which Sukegawa describes as “storing the AP and OS of the host
`
`system,” and which Sukegawa describes as being used in conjunction with
`
`Sukegawa’s non-volatile flash memory. APPLE-1005, 1:5-49, 4:38-46, 7:66-8:33,
`
`FIG. 2. In more detail, Sukegawa’s background section establishes that it was
`
`known to cache frequently used data, including AP and OS data, in volatile main
`
`memory, because the relatively low access speed of a hard disk otherwise elongates
`
`the time needed to start these programs, which is a “serious problem.” Id., 1:5-49.
`
`From this description, a POSITA would have understood that Sukegawa’s main
`
`memory 23 is volatile memory, and would have further understood that caching AP
`
`and OS data in main memory 23 is preferable to storing that data on disk. See id.
`
`Sukegawa also proposes supplementing its main memory with high speed
`
`non-volatile flash memory, and provides disclosure of preloading boot data into that
`
`non-volatile flash memory, to ensure at least some data is readily available upon
`
`power-on. APPLE-1005, 1:5-49, 4:38-46, 5:10-6:58, 7:66-8:33, FIGS. 1-2. Petition
`
`7-17; APPLE-1003, ¶33, 113-126. Yet, a POSITA would have been aware that non-
`
`volatile flash memory was both expensive and not of unlimited capacity, and would
`
`have been faced with design choices of how to best preload in a situation where cost
`
`precludes preloading all of the boot data into non-volatile flash memory. In this
`
`situation, the POSITA would have still been motivated by Sukegawa to preload boot
`
`
`
`7
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`data that does not fit into the flash memory as quickly as possible after power-on.
`
`Indeed, Sukegawa seeks to preload data as soon as possible and, to the extent the
`
`non-volatile flash memory lacks capacity to store all OS/AP control information
`
`(e.g., all OS/AP control information selected by a user), a POSITA would have
`
`found it obvious to preload as much information into flash memory as possible and
`
`then preload any remaining data into volatile memory upon power-on.
`
`In this regard, a POSITA would have looked to Sukegawa’s description of
`
`main memory used for caching AP and OS data, and would have found it obvious to
`
`transfer boot data expected to be needed most quickly after power-on into the non-
`
`volatile flash memory, and to preload the remaining boot data into main memory
`
`upon power-on. See APPLE-1005, 1:5-49, 4:38-46, 5:10-6:58, 7:66-8:33, FIGS. 1-
`
`2. Indeed, a POSITA would have viewed this solution as advantageous for reducing
`
`the cost associated with Sukegawa’s non-volatile memory, without necessarily
`
`slowing Sukegawa’s boot process, as it leverages the time needed to start the boot
`
`process to preload additional boot data that would otherwise just be waiting on disk.
`
`Thus, and further in view of the mappings of Sukegawa and other references
`
`to the original claims in the Petition, Petitioner submits that the proposed substitute
`
`claims are obvious over the same combinations of references discussed in Grounds
`
`1-5, and that Realtime has failed to meet its burden to demonstrate the opposite.
`
`
`
`8
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`Moreover, and as will be established in Section III, Settsu, both alone and in
`
`combination with Zwiegincew, renders obvious every feature of the substitute
`
`claims proposed by Realtime, including the specific amendments upon which
`
`Realtime’s patentability arguments rest. See also APPLE-1030, ¶17.
`
`Realtime offers only two paragraphs of argument specifically addressed to
`
`Settsu, and the declaration by Dr. Back that was offered by Realtime in support of
`
`the MTA repeats those two paragraphs nearly verbatim. See MTA, 21-22;
`
`REALTIME-2022, ¶¶61, 65. These two paragraphs suggest that Settsu “only
`
`teaches loading boot data when it is accessed or requested ahead of time,” and that
`
`Settsu therefore does not disclose or suggest “preloading,” as recited in the proposed
`
`substitute claims. Yet, Realtime neglects to explain why “loading boot data when it
`
`is … requested ahead of time” fails to meet the recited claim language, and also
`
`neglects to address Settsu’s rich disclosure with respect to preloading. See Section
`
`III, infra. Further, Realtime and its expert implicitly acknowledge that Settsu’s
`
`memory 2, into which Settsu’s boot data is preloaded, could be volatile memory, as
`
`featured in the amended claims. See MTA, 22; REALTIME-2022, ¶61.
`
`III. Prior Art of Record Renders Obvious the Proposed Substitute Claims
`Petitioner submits that proposed substitute claims 118-173 are obvious over
`
`Settsu and are also obvious over a combination of Settsu with Zwiegincew.
`
`Indeed, and as discussed in more detail below, Settsu teaches increasing boot speed
`
`
`
`9
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`by preloading compressed boot data into memory during a boot sequence, and
`
`Zwiegincew complements Settsu’s teachings with additional disclosure of
`
`preloading boot data into volatile memory, and of updating a boot data list in the
`
`same context. APPLE-1030, ¶36. Accordingly, Zwiegincew would have provided
`
`a POSITA additional motivation to preload boot data into volatile memory and to
`
`update boot data lists in Settsu’s system. Id.
`
`A.
`
`Settsu, Alone and in Combination with Zwiegincew, Renders
`Obvious the Substitute Independent Claims
`118.0: A method for providing accelerated loading of an operating system in a
`computer system, the method comprising:
`Settsu describes “an information processing apparatus capable of reducing
`
`the time required for booting itself when it is powered on, and a method of booting
`
`an information processing apparatus at a high speed.” APPLE-1006, 1:8-12;
`
`Abstract, 1:43-2:25, 3:6-25, 10:43-12:16, 13:49-15:4.1 Settsu’s “information
`
`
`1 Settsu describes multiple “preferred embodiments,” but sometimes omits
`
`description of like elements between embodiments. See APPLE-1006, 10:43-51,
`
`13:49-55. Settsu is nevertheless clear that functionality ascribed to elements from
`
`one embodiment applies equally to similar elements of other embodiments.
`
`APPLE-1030, ¶23. Thus, a POSITA would have understood and found it obvious
`
`that the description of elements provided by Settsu with respect to one embodiment
`
`applies equally to similar elements of other embodiments. APPLE-1030, ¶23.
`
`
`
`10
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`processing apparatus” is a computer system. Id. Settsu, alone or in combination
`
`with Zwiegincew, renders obvious 118.0. APPLE-1030, ¶21.
`
`118.1: preloading a portion of boot data in a compressed form into a volatile
`memory, the portion of boot data in the compressed form being associated
`that is with a portion of a boot data list for booting the computer system into a
`memory,
`Settsu describes “a method of booting” by “loading an operating system into
`
`the memory.” APPLE-1006, 1:67-2:3. Settsu’s system includes a “memory 2” and
`
`a “boot device 3.” Id., 7:65-8:23. As Settsu’s FIG. 12 (below) depicts, Settsu’s
`
`boot device 3 stores a “mini OS module 7,” and includes a “file system 5,” which
`
`stores an “OS main body module” “with OS functions.” Id., 7:65-8:23, 13:49-65.
`
`The OS “main body module” is “divided into a plurality of functional modules”
`
`that “are separately stored as compressed files” in “file system 5 of boot device 3.”
`
`Id., 2:5-67, 13:55-65.
`
`APPLE-1006, FIG. 12 (excerpt, annotated).
`
`
`
`In a series of operations starting from “[w]hen the information processing
`
`apparatus is powered on,” the mini OS module 7 preloads the OS main body
`11
`
`
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`module’s plurality of compressed files into memory 2. Id., Abstract, 8:21-35,
`
`8:66-9:11, 11:7-9. The plurality of compressed files preloaded into memory 2 are
`
`then decompressed to facilitate a computer system’s boot process. Id., Abstract
`
`1:1-4, 1:51-57, 3:6-9, 13:49-15:5.
`
`By using compression/decompression, Settsu explains that “the time
`
`required for I/O processing can be reduced,” which “further reduce[s] the time
`
`required for booting up.” Id., 14:58-15:5. Because Settsu’s OS main body module
`
`8 is loaded when the information processing apparatus is powered on and
`
`represents the operating system data needed to boot the information processing
`
`apparatus, Settsu’s OS main body module 8 includes “data associated with data
`
`requests expected to result from a system power-on/reset” and, thus, meets the
`
`claimed boot data. APPLE-1030, ¶26. In this regard, through description of
`
`transferring the OS main body module 8 from boot device 3 into memory 2 as a
`
`plurality of compressed files, Settsu discloses preloading a portion of boot data in a
`
`compressed form into memory.
`
`Settsu further renders obvious that preloading a portion of boot data in a
`
`compressed form into a volatile memory. APPLE-1030, ¶¶27-28. In more detail,
`
`and as Dr. Neuhauser explains, a POSITA would have understood that Settsu’s
`
`memory 2 could be either volatile or non-volatile. Id. Indeed, a POSITA would
`
`have understood that Settsu’s method of reducing the time required for an
`
`
`
`12
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`information processing apparatus to boot itself, which involves a series of
`
`operations starting from “[w]hen the information processing apparatus is powered
`
`on,” could work with either volatile or non-volatile memory, but that relatively fast
`
`volatile memory would be preferable for use in Settsu’s system. APPLE-1030,
`
`¶¶27-28. For at least this reason, a POSITA would have found it obvious to
`
`implement Settsu’s memory 2 as volatile memory. Id.
`
`Thus, a POSITA would have found it obvious that Settsu preloads a portion
`
`of boot data in a compressed form into a volatile memory. Id., ¶29.
`
`Settsu also describes that the portion of boot data in the compressed form is
`
`associated with a portion of a boot data list for booting the computer system.
`
`APPLE-1030, ¶30. Indeed, Settsu discloses multiple forms of boot data lists that
`
`are associated with stored boot data. Id. Two examples are provided: (1) lists of
`
`boot data that are stored within the OS functional module files themselves; and (2)
`
`lists of boot data that are referenced by mini OS module 7 when booting the OS.
`
`APPLE-1030, ¶30; APPLE-1006, 13:55-65, 16:7-17:62, FIGS. 12, 20(ST213).
`
`With respect to the first example, Settsu discloses that the OS main body
`
`module is divided into “a plurality of functional modules” that “are separately
`
`stored as compressed files” in “file system 5 of boot device 3.” APPLE-1006,
`
`7:65-8:23, 13:55-65, FIG. 12. Because each electronic file includes a list of data
`
`stored within the file, a POSITA would have understood that an OS functional
`
`
`
`13
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`module file stored on boot device 3 and preloaded into memory 2 includes a list of
`
`data necessary for starting the OS – a boot data list as described by the ’862 Patent.
`
`APPLE-1030, ¶31 (citing “file,” Microsoft Press Computer Dictionary); APPLE-
`
`1031, 5:16-20; APPLE-1032, 10:57-60, 12:16-21; APPLE-1033, Abstract.
`
`Thus, through description of storing compressed OS functional module files
`
`on boot device 3 and preloading the same into memory 2, Settsu discloses boot
`
`data in a compressed form associated with a portion of a boot data list for booting
`
`the computer system. APPLE-1030, ¶32.
`
`With respect to the second example, Settsu describes that mini OS module 7
`
`includes an “OS loading and decompression processing module 50” for, among
`
`other functions, “loading the OS main body module 8 from the boot device 3 into
`
`the memory 2…” APPLE-1006, 8:28-35, 13:66-14:12, FIG. 13.
`
`As part of the process of loading the OS main body module 8 from the boot
`
`device 3 into the memory 2, the OS loading and decompression processing module
`
`50 “checks whether or not the whole of the main body of the OS has been loaded,
`
`that is, whether or not all the functional modules 16 to 22 have been loaded into the
`
`memory 2.” Id., 14:44-52, FIG. 14.
`
`A POSITA would have found it obvious that, in performing this check, the
`
`mini OS module 7 references a list of data that identifies the OS functional
`
`modules. APPLE-1030, ¶33. Settsu provides two types of such lists: (1) a list of
`
`
`
`14
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`modules included in the OS main body module 8, and (2) a “function definition file
`
`71” that lists OS functional modules required for a particular application to run.
`
`APPLE-1006, 8:51-52, 9:56-66, 16:7-17:62, 16:26-31, 17:5-20, FIGS. 14(ST185),
`
`20(ST213). Thus, Settsu renders obvious 118.1. APPLE-1030, ¶¶33-35.
`
`Zwiegincew recognizes problems of slow boot that result when hard page
`
`faults occur during the boot process of computer system. APPLE-1010, 1:45-51,
`
`2:12-15, 5:50-51. To improve boot speed of a computer system such as that
`
`illustrated by Zwiegincew’s FIG. 1 (reproduced below), Zwiegincew proposes
`
`“pre-fetching”, from a hard disk into RAM (volatile memory), pages that are
`
`expected to be requested during the boot process, thereby reducing occurrence of
`
`hard page faults. Id., Abstract, 1:5-3:63, 4:31-6:4. “Copies of, or references to,
`
`the…pages are stored in a scenario file” and, “[w]hen a hard page fault scenario is
`
`detected, a corresponding scenario file is fetched from disk storage and the
`
`determined pages, or copies thereof, are transferred into RAM.” Id., Abstract.
`
`Zwiegincew also recognizes benefits of compressing pre-fetched page data.
`
`For instance, Zwiegincew’s system includes “a disk compressor/decompressor,”
`
`which employs “compression algorithms” on pre-fetched data to achieve pre-fetch
`
`time improvements. Id., 8:66-9:13, FIGS. 1-2.
`
`
`
`15
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`
`APPLE-1010, FIG. 1 (annotated).
`
`
`
`A POSITA would have recognized that Zwiegincew’s scenario file used in
`
`preventing hard page faults during boot is a boot data list because the scenario file
`
`includes copies of, or references to, data used during the boot process. APPLE-
`
`1030, ¶38; APPLE-1010, Abstract, 2:43-3:49. Accordingly, Zwiegincew would
`
`have further motivated a POSITA to associate compressed boot data for booting
`
`Settsu’s system with a boot data list, and to preload the compressed boot data from
`
`boot device 3 into memory 2 (implemented as volatile memory) using the boot data
`
`list. APPLE-1030, ¶¶36-40; APPLE-1010, Abstract, 1:5-3:55, 5:50-51, 8:66-9:13.
`
`Thus, Settsu and Zwiegincew render obvious 118.1.
`
`118.2: wherein the preloading comprises transferring the portion of boot data
`in the compressed form into the volatile memory,
`
`
`
`
`16
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`As explained at 118.0-118.1, Settsu describes a “a method of booting” by
`
`“loading an operating system into the memory.” APPLE-1006, 1:67-2:3. In more
`
`detail, Settsu’s system includes a “memory 2” and a “boot device 3.” Id., 7:65-
`
`8:23. Settsu’s boot device 3 stores a “mini OS module 7,” and includes a “file
`
`system 5,” which stores an “OS main body module” “with OS functions.” Id.,
`
`7:65-8:23, 13:49-65, FIG. 12. The OS “main body module” is “divided into a
`
`plurality of functional modules” that “are separately stored as compressed files” in
`
`“file system 5 of boot device 3.” Id., 2:5-67, 13:55-65.
`
`In a series of operations starting from “[w]hen the information processing
`
`apparatus is powered on,” the 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. Id., Abstract, 8:21-35, 8:66-9:11, 11:7-9; APPLE-1030, ¶41.
`
`The plurality of compressed files preloaded into memory 2 are then decompressed
`
`to facilitate a computer system’s boot process. APPLE-1006, Abstract 1:1-4, 1:51-
`
`57, 3:6-9, 13:49-15:5. Thus, Settsu, alone and in combination with Zwiegincew,
`
`renders obvious 118.2. APPLE-1030, ¶41.
`
`118.3: and wherein the preloading occurs 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;
`
`
`As explained at 118.0-118.2, Settsu describes “a method of booting” by
`
`“loading an operating system into the memory.” APPLE-1006, 1:67-2:3.
`
`
`
`17
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`As Dr. Neuhauser explains, a POSITA would have understood that Settsu’s
`
`mini OS module 7, which controls the preloading of boot data from boot device 3
`
`into memory 2 during Settsu’s boot process, is a “boot device controller” that
`
`receives a command over a computer bus to load portions of boot data into
`
`memory 2, and that this command is received during the same boot sequence in
`
`which the preloading occurs. APPLE-1030, ¶42; APPLE-1006, Abstract, 1:1-4,
`
`1:51-57, 3:6-9, 5:2-8, 8:21-46, 8:66-9:11, 11:7-9, 13:49-15:5, 27:23-35, FIGS. 1, 2.
`
`In more detail, Settsu describes that mini OS module 7, which is itself stored
`
`in the boot block of boot device 3, includes “a mini kernel module 9 which is a
`
`basic part of the OS, a boot device driver module 10 for performing I/O
`
`[Input/Output] operations on the boot device 3, and an OS loading and
`
`initialization processing module 11 for loading the OS main body module 8 from
`
`the boot device 3 into the memory 2 and for executing the initialization of the OS
`
`main body module 8.” APPLE-1006, 8:24-46, 2:8-13, FIG. 2.
`
`By this and related description, a POSITA would have understood that mini
`
`OS module 7 is a “boot device controller” that both sends and receives commands
`
`over a computer bus. APPLE-1030, ¶¶42-45; APPLE-1006, Abstract, 1:1-4, 1:51-
`
`57, 3:6-9, 8:21-46, 8:66-9:11, 11:7-9, 13:49-15:5, FIG. 2.
`
`Indeed, Settsu’s mini OS module 7 preloads the OS main body module’s
`
`plurality of compressed files from boot device 3 into memory 2, in a series of
`
`
`
`18
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`operations starting from “[w]hen the information processing apparatus is powered
`
`on.” Id., Abstract, 8:21-35, 8:66-9:11, 11:7-9. Before mini OS module 7 can
`
`begin preloading, however, it must itself first be loaded into memory by a “F/W
`
`code module” 6 that is located on a separate component of Settsu’s system: ROM
`
`1. APPLE-1006, 1:51-65, FIG. 1. Mini OS module 7 then “receives control from
`
`the F/W code module,” and completes the preloading process. APPLE-1006,
`
`27:23-35.
`
`From this description, a POSITA would have understood that Settsu’s mini
`
`OS module 7 receives a command over a computer bus to load portions of boot
`
`data into memory 2, and that this command is received during the same boot
`
`sequence in which the preloading occurs. APPLE-1030, ¶¶42-45; APPLE-1006,
`
`Abstract, 1:1-4, 1:51-57, 3:6-9, 8:21-46, 8:66-9:11, 11:7-9, 13:49-15:5, FIG. 2.
`
`Moreover, as alleged support for 118.3, Dr. Back cites to passages from the
`
`application to which the ’862 patent claims priority, which describe a “controller”
`
`that is functionally similar to Settsu’s mini OS module 7. See REALTIME-2022,
`
`¶26; APPLE-1030, ¶¶42-43 Thus, Settsu, alone and in combination with
`
`Zwiegincew, renders obvious 118.3. APPLE-1030, ¶¶42-47.
`
`118.4: accessing the preloaded portion of the boot data in the compressed
`form from the volatile memory;
`
`
`As explained at 118.1-118.3, Settsu preloads OS files from a boot device’s
`
`file system “into [a] memory 2 as compressed data,” and then decompressing the
`19
`
`
`
`
`
`Proceeding No.: IPR2016-01737
`Attorney Docket: 39521-0025IP1
`OS files to facilitate a computer system’s boot process. APPLE-1006, Abstract,
`
`1:1-57, 3:6-9, 13:49-15:5. In decompressing preloaded boot data “so as to convert
`
`it into executable code and data,” Settsu’s mini OS module 7 accesses compressed
`
`boot data that it has preloaded into memory 2. APPLE-1006, 3:6-3:25, 13:49-15:4.
`
`A POSITA would have understood that, to decompress the compressed boot data
`
`preloaded into memory 2, mini OS module 7 would first access the compressed
`
`data from memory 2.