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 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.

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