throbber
Paper 9
`
`
`
`
`
`
`Trials@uspto.gov
` Entered: August 30, 2019
`
`
`
`571-272-7822
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`KINGSTON TECHNOLOGY COMPANY, INC.,
`Petitioner,
`v.
`MEMORY TECHNOLOGIES, LLC,
`Patent Owner.
`____________
`
`Case IPR2019-00651
`Patent 7,739,487 B2
`____________
`
`
`
`Before JAMESON LEE, J. JOHN LEE,
`and JASON M. REPKO, Administrative Patent Judges.
`
`LEE, JAMESON, Administrative Patent Judge.
`
`
`
`
`
`
`
`
`DECISION
`Institution of Inter Partes Review
`35 U.S.C. § 314
`
`
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`I.
`
`INTRODUCTION
`
`A. Background
`On January 31, 2019, Petitioner filed a Petition to institute inter partes
`review of claims 6, 7, 13, 20, 21, 26, 42, and 52 (“the challenged claims”) of
`U.S. Patent No. 7,739,487 B2 (Ex. 1001, “the ’487 patent”). Paper 1
`(“Pet.”). Patent Owner filed a Preliminary Response. Paper 6 (“Prelim.
`Resp.”).
`To institute an inter partes review, we must determine that the
`information presented in the Petition shows “that there is a reasonable
`likelihood that the petitioner would prevail with respect to at least 1 of the
`claims challenged in the petition.” 35 U.S.C. § 314(a). Having considered
`all submissions of both parties, we determine that Petitioner has not
`demonstrated a reasonable likelihood that it would prevail in establishing the
`unpatentability of any of the challenged claims.
`Accordingly, we do not institute review of any of claims 6, 7, 13, 20,
`21, 26, 42, and 52 on any alleged grounds of unpatentability asserted in the
`Petition.
`
`B.
`
`Related Matters
`The parties identify a civil action involving the ’487 patent: Memory
`Techs., LLC v. Kingston Tech. Corp., No. 8-18-cv-00171 (C.D. Cal.). Pet. 2;
`Paper 4, 1. Petitioner has filed other Petitions for inter partes review of
`other patents involved in that civil action: IPR2019-00638, IPR2019-00642,
`IPR2019-00643, IPR2019-00644, IPR2019-00645, IPR2019-00648, and
`IPR2019-00654.
`
`Patent Owner further identifies the following terminated litigation
`involving the ’487 patent: Memory Techs., LLC v. SanDisk LLC, No. 8-16-
`
`2
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`cv-02163 (C.D. Cal.). Paper 3, 1. Patent Owner additionally identifies
`another petition for inter partes review of claims in the ’487 patent:
`IPR2017-00978 (terminated prior to institution decision). Id. The petitioner
`in IPR2017-00978 is not the petitioner in this proceeding.
`C.
`The ’487 Patent
`The ’487 patent is directed to a system and method for booting a host
`device from a peripheral device via a MultiMediaCard (“MMC”) or Secure
`Digital (“SD”) interface. Ex. 1001, Abstract, 2:35–37. The ’487 patent
`discloses a conventional MMC/SD interface that comprises four terminals:
`a power terminal, a data (DAT) terminal, a clock (CLK) terminal, and a
`command (CMD) terminal. Id. at 2:29–40. Figure 5 of the ’487 patent is
`reproduced below.
`
`
`Figure 5 shows a peripheral device that has a conventional MMC/SD
`interface and is coupled to a host device. Id. at 14:5–7. The host device
`includes a processing unit, i.e., a CPU, and a MMC/SD interface controller.
`Id. at 15:62–65. The MMC/SD interface of Figure 5 shows CMD, CLK, and
`DAT terminals. Id. at 15:65–67. The peripheral device (also termed
`memory module or MMC/SD memory card) includes a peripheral device
`
`3
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`controller that serves “as a mediator between the interface and the memory
`module and serves to control all procedures to be performed between [the]
`MMC/SD interface and [the] memory module.” Id. at 15:67 through 16:4.
`The ’487 patent omits other details, such as the aforementioned power
`terminal, to avoid overcomplicating Figure 5. Id.
`The ’487 patent discloses a boot procedure that uses the MMC/SD
`interface to indicate to a memory component that it should fetch its first data
`sector during the power-up process of a host device. Id. at 3:45–50, 5:45–
`52, 5:63–67. Importantly, the disclosed methods may be performed with
`memory cards that have a conventional MMC/SD interface. Id. 2:16–25; see
`also, e.g., id. at 6:40–43, 17:23–26; 2:19–34. The boot procedure does not
`require modifications to either the electrical interface or form factor used in
`the conventional MMC/SD interface. Id. Because the disclosed
`embodiments of the boot procedure use the pin configuration already used in
`an MMC/SD interface, the described methods do not require the addition of
`separate pins in order to indicate to a memory component that it should fetch
`a data sector during the power-up process of a host device. Id. In this
`manner, the boot procedure is compatible with existing MMC and SD cards
`and does not require changes to their interface. Id. at 2:22–25.
`The ’487 patent discloses three embodiments of the boot procedure,
`all of which involve the peripheral device detecting an “unexpected” signal
`at the CMD terminal, which in turn causes the peripheral device to transmit
`boot data to the host device in order to boot up the host device. Id. at 3:51–
`56, 5:53–59. Two embodiments consist of receiving from the host device a
`low signal via the CMD terminal at the peripheral device (id. at Figs. 1–2,
`3:45–50, 3:63 through 4:2), and one embodiment consists of receiving from
`
`4
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`the host device an argument via the CMD terminal at the peripheral device
`(id. at Fig. 3, 5:45–52). Figure 1 of the ’487 patent is reproduced below.
`
`
`
`Figure 1 is a flowchart that shows the actions performed at the host
`device and the peripheral device, according to one aspect of the invention.
`Id. at 14:23–27, 14:37–38. The flowchart on the left depicts those actions
`that occur at the host device. Id. at 14:23–27. The flowchart portion on the
`right depicts those actions that take place at the peripheral device having an
`MMC/SD interface. Id. The middle portion depicts the direction of signal
`transmissions (i.e., from host device to the peripheral device or vice versa)
`and the form of the transmitted signals at the corresponding terminal of the
`MMC/SD interface. Id. at Fig. 1.
`The flowchart begins with the host device providing power to the
`power terminal of the MMC/SD interface, and thus the peripheral device
`receives said power signal at the MMC/SD interface. Id. at 14:41–45.
`Simultaneously or subsequently, the host device provides a low signal at the
`CMD terminal of the MMC/SD interface. Id. at 14:46–47. The peripheral
`device detects this low signal as an “unexpected” signal and interprets it as a
`boot request. Id. at 14:47–55. As a result, the peripheral device then
`retrieves boot data from a dedicated file or memory area and sends the boot
`data via the DAT terminal to the host device. Id. at 14:54–59. Accordingly,
`
`5
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`the flowchart ends with the host device monitoring the DAT terminal for the
`signals corresponding to the boot data. Id. at 60–61.
`Figure 2 of the ’487 patent is reproduced below.
`
`
`Figure 2 shows an alternative embodiment of the method disclosed in
`
`Figure 1. Id. at 15:1–2. Here, in addition to the low signal at the CMD
`terminal, the host device provides a clock signal at the CLK terminal for at
`least 74 cycles or until the peripheral device transfers all of the boot data to
`the host device. Id. at 15:4–7. This clock signal enables the peripheral
`device to distinguish between a CMD terminal failure—e.g., a failure that
`would cause the CMD terminal to adopt a logical low value—and a boot
`request consisting of two different signal components—i.e., the low signal at
`the CMD terminal and the clock signal at the CLK terminal. Id. at 8–11.
`
`6
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`
`Figure 3 of the ’487 patent is reproduced below.
`
`
`Figure 3 shows another embodiment of the boot procedure. Id. at
`15:25. In this embodiment, instead of a low signal at the CMD terminal, the
`host device sends during an initialization procedure an “unexpected” CMD0
`signal having an argument 01H. Id. at 15:30–33. The CMD0 command in
`this embodiment would be “unexpected” to the peripheral device because a
`conventional initialization procedure comprises a CMD command with an
`argument 00H. Id. at 15:28–30.
`The peripheral device receives this CMD0 signal at the MMC/SD
`interface and recognizes it as an incoming boot request. Id. at 15:30–36.
`Thus, the peripheral device is able to recognize boot requests before the
`MMC/SD interface reaches an initialized state. Id. Upon recognizing the
`boot request, the peripheral device retrieves the boot data and sends it to the
`host device via the data bus. Id. at Fig. 3.
`The host device may send the CMD0 signal by itself or in conjunction
`with a clock signal at the CLK terminal, as described in the embodiment
`corresponding to Figure 2. Id. at 15:37–38.
`Claims 6 and 13 are independent and reproduced below.
`6.
`A method for booting from a peripheral device having an
`MMC/SD-interface, via said MMC/SD interface with power
`terminals, a data bus with data bus terminals, a clock line with a
`7
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`clock terminal and a command line with command terminal, said
`method comprising:
`receiving power at said power terminals of said
`MMC/SD-interface,
`receiving a low signal at the command terminal
`before or during power up, and
`sending the first data of a predefined storage area
`via data bus, starting with a start bit of the first data
`frame.
`Id. at 18:4–14.
`13.
` A method for booting a host device from a
`peripheral device having an MMC/SD-interface with
`power terminals, a data bus with data bus terminals, a
`clock line with a clock terminal and a command line with
`command terminal, said method comprising:
`receiving during an initialization procedure of the
`peripheral device an argument for a boot request
`from said host device at said MMC/SD-interface
`of the peripheral device,
`receiving a clock signal at the clock terminal, and
`sending data starting with a start bit of a data
`transmission
`to said host device via said
`MMC/SD-interface, if and when boot data are
`stored in said peripheral device.
`Id. at 18:55–65.
`D.
`Evidence Relied Upon
`Petitioner relies on the following references as prior art:1
`
`
`1 The ’487 patent issued from Application 11/333,799, filed Jan. 17, 2006.
`Ex. 1001, [22].
`
`8
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`
`References
`
`Date
`
`Exhibit
`
`Toombs
`
`McClain
`
`Kozakai
`
`Kurakata
`
`U.S. Patent No. 6,279,114 B1 August 21, 2001 Ex. 1005
`
`U.S. Patent No. 7,058,779 B1
`
`June 6, 2006.
`Filed March 5,
`2002.
`
`Ex. 1006
`
`U.S. Patent No. 7,012,845 B2 March 14, 2006.
`Filed February
`9, 2005.
`
`Ex. 1007
`
`U.S. Patent No. 7,188,265 B2 March 6, 2007.
`Filed November
`20, 2003.
`
`Ex. 1008
`
`Petitioner also relies on the Declaration of Dr. R. Jacob Baker (Ex.
`1003).
`
`The Asserted Grounds of Unpatentability
`
`Claims Challenged
`
`E.
`
`6, 7, 20, and 21
`
`6, 7, 20, and 21
`
`13, 26, 42, and 52
`
`Basis2
`§ 103
`
`§ 103
`
`§ 103
`
`References
`Toombs and McClain
`Toombs, McClain, and
`Kozakai
`Toombs, McClain, and
`Kurakata
`
`
`2 The Leahy-Smith America Invents Act (“AIA”), Pub. L. No. 112–29, 125
`Stat. 284, 287–88 (2011), revised 35 U.S.C. § 103 effective March 16, 2013.
`Because the challenged patent was filed before March 16, 2013, we refer to
`the pre-AIA version of § 103.
`
`9
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`A.
`
`II. ANALYSIS
`The Law on Obviousness
`The question of obviousness is resolved on the basis of underlying
`factual determinations including: (1) the scope and content of the prior art;
`(2) any differences between the claimed subject matter and the prior art;
`(3) the level of ordinary skill in the art; and (4) when in evidence, objective
`indicia of nonobviousness. Graham v. John Deere Co., 383 U.S. 1, 17–18
`(1966). One seeking to establish obviousness based on more than one
`reference also must articulate sufficient reasoning with rational
`underpinnings to combine teachings. See KSR Int’l Co. v. Teleflex, Inc.,
`550 U.S. 398, 418 (2007).
`
`B.
`
`The Level of Ordinary Skill in the Art
`Petitioner asserts that the level of ordinary skill in the art corresponds
`to “a person with a bachelor’s degree in electrical engineering or a closely
`related field, and two or three years of experience in the field of memory
`device circuit design.” Pet. 20. Patent Owner has not articulated a different
`level of ordinary skill and also has not disputed Petitioner’s statement of the
`level of ordinary skill. In this circumstance, we adopt the level of ordinary
`skill as articulated by Petitioner.
`
`C.
`
`Claim Construction
`For petitions filed on or after November 13, 2018, a claim shall be
`construed using the same claim construction standard that would be used to
`construe the claim in a civil action under 35 U.S.C. § 282(b), including
`construing the claim in accordance with the ordinary and customary
`meaning of such claim as understood by one of ordinary skill in the art and
`the prosecution history pertaining to the patent. Changes to the Claim
`
`10
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`Construction Standard for Interpreting Claims in Trial Proceedings Before
`the Patent Trial and Appeal Board, 83 Fed. Reg. 51,340 (Oct. 11, 2018)
`(codified at 37 C.F.R. §42.100 (2019)). Petitioner filed its Petition on
`January 31, 2019. Paper 1. Thus, we apply the claim construction standard
`as set forth in Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) (en
`banc) (“the Phillips standard”).
`Claim terms are generally given their ordinary and customary
`meaning as would be understood by one with ordinary skill in the art in the
`context of the specification, the prosecution history, other claims, and even
`extrinsic evidence including expert and inventor testimony, dictionaries, and
`learned treatises, although extrinsic evidence is less significant than the
`intrinsic record. Phillips, 415 F.3d at 1312–1317. Usually, the specification
`is dispositive, and it is the single best guide to the meaning of a disputed
`term. Id. at 1315.
`The specification may reveal a special definition given to a claim term
`by the patentee, or the specification may reveal an intentional disclaimer or
`disavowal of claim scope by the inventor. Id. at 1316. If an inventor acts as
`his or her own lexicographer, the definition must be set forth in the
`specification with reasonable clarity, deliberateness, and precision.
`Renishaw PLC v. Marposs Societa’ per Azioni, 158 F.3d 1243, 1249 (Fed.
`Cir. 1998). The disavowal, if any, can be effectuated by language in the
`specification or the prosecution history. Poly-America, L.P. v. API Indus.,
`Inc., 839 F.3d 1131, 1136 (Fed. Cir. 2016). “In either case, the standard for
`disavowal is exacting, requiring clear and unequivocal evidence that the
`claimed invention includes or does not include a particular feature.” Id.
`
`11
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`Only those claim terms that are in controversy need to be construed,
`and only to the extent necessary to resolve the controversy. Nidec Motor
`Corp. v. Zhongshan Broad Ocean Motor Co. Ltd., 868 F.3d 1013, 1017
`(Fed. Cir. 2017); Wellman, Inc. v. Eastman Chem. Co., 642 F.3d 1355, 1361
`(Fed. Cir. 2011); Vivid Techs., Inc. v. Am. Sci. & Eng’g, Inc., 200 F.3d 795,
`803 (Fed. Cir. 1999).
`Petitioner proposes a construction for the term “data frame” as
`meaning “data transmission.” Pet. 20. Patent Owner has not proposed a
`construction for any claim term, and has not disputed the proposed
`construction by Petitioner for “data frame.” See generally Prelim. Resp.
`We determine that it is unnecessary to provide an express construction
`for any claim term. The positions of the parties as presented before us do
`not lead to different results based on a dispute as to the meaning of any
`claim term or phrase.
`Patent Owner argues that the Petition does not comply with 37 C.F.R.
`§ 42.104(b)(3)–(5) because Petitioner fails to propose a construction for the
`claim term “during power up.” Prelim. Resp. 23–26. Patent Owner notes
`that, instead, the Petition includes only a footnote stating that the parties
`agreed in a related litigation matter that the terms “during power up” and
`“during power up process” should be construed as “during the power up
`process of the peripheral device.” Id. at 24–25. (citing Pet. 35, n.3). The
`argument is without merit.
`Petitioner’s stating what construction the parties have agreed to in
`related district court litigation, coupled with an explanation as to how the
`“during power up” limitation is met by the applied prior art, consistent with
`that previously agreed upon construction, is sufficient explanation, in the
`
`12
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`context here, to meet the requirement of proposing a claim construction
`under 37 C.F.R. § 42.104(b)(3)-(5).
`D. Alleged Unpatentability of Claims 6, 7, 20, and 21
`as Obvious over Toombs and McClain
`1.
`Overview of Toombs
`Toombs describes an MMC system for communicating between a host
`device and memory cards connected to the host. Ex. 1005, 1:45–48. It
`further describes a method for negotiating and determining a common
`operation voltage range for the MMC system. Id. at 1:53–56.
`In a preferred embodiment, Toombs’s MMC system supports
`communications between the host device and the memory cards via three
`signals and their corresponding channels: a clock (CLK) signal, a command
`(CMD) signal, and a data (DAT) signal. Id. at 6:18–38. For each cycle of
`the CLK signal, the MMC system transfers one bit on each of the CMD and
`DAT channels. Id. at 6:21–23. The MMC system uses the bidirectional
`CMD channel to initialize the cards and transfer data corresponding to
`commands and response messages. Id. at 6:23–26. That is, the CMD
`channel carries commands from the host to the cards, and it carries response
`data from the cards to the host. Id. at 6:27–33, 6:18–38. The bidirectional
`DAT channel carries data between the host and the cards. Id. at 6:33–38.
`To enable these communications, Toombs discloses the architecture
`of an MMC bus which requires all memory cards to be connectable to the
`same set of signal lines. Id. at 7:26–29. The MMC bus includes lines
`divided into three groups: power supply, communications (including both
`CMD, and DAT), and clock. Id. 7:32–34.
`
`13
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`Figure 14 of Toombs is reproduced below.
`
`
`Figure 14 shows the architecture of an MMC card. Ex. 1005, 2:43–
`45. It discloses the location of the CLK, CMD, and DAT terminals in the
`MMC card. Ex. 1005, Fig. 14 (labeling three terminals as “CLK,” “CMD,”
`and “DAT”). And it also discloses the location of the terminals that carry
`voltages VDD and VPP. Id.
`Toombs also describes that the power-up procedure of the MMC bus
`is handled locally in each card and in the bus master of the host. Id. at
`17:34–36. After a memory card receives power, it enters an idle state during
`which the card ignores all bus transactions until it receives a CMD1
`command from the host. Id. at 17:39–41. The memory card responds to the
`CMD1 command by setting a bit to either a busy-flag state, which indicates
`that the card is still working on its power-up procedure and is not ready, or
`by clearing this bit. Id. at 17:43–53. When the host receives the bit from the
`memory card in its busy-flag state, the host waits and continues polling the
`
`14
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`card with the CMD1 command until the bit is cleared. Id. In the preferred
`embodiment, the bus master of the host is responsible for getting the MMC
`system, including the host and all the cards, out of their idle state. Id. at
`17:54–56. The host, thus, must confirm that the power reaches the desired
`operating level before it transmits the CMD1 command. Id. at 17:56–62.
`2.
`Overview of McClain
`McClain describes a computer system including a non-volatile
`memory that shares a common interface with a synchronous dynamic
`random access memory (“SDRAM”). Ex. 1006, 2:5–7. The non-volatile
`memory features an interface that is styled like an SDRAM memory
`interface. Id. at 7–10. The non-volatile memory uses this SDRAM style
`interface to provide initialization (boot) code to the computer system. Id. at
`2:7–10.
`The invention addresses a disadvantage inherent in traditional systems
`that require separate interfaces for the SDRAM and non-volatile memory.
`Id. at 1:55–58. It also eliminates the need for an additional random access
`non-volatile memory that provides boot code to the computer. Id. at 2:10–
`12. The invention, thus, reduces the number of interface lines and non-
`volatile memory devices in the system. Id. at 2:3–5.
`
`15
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`Figure 1 of McClain is reproduced below.
`
`
`Figure 1 shows a computer system that includes among other elements
`CPU 14, volatile sequential access memory embodied by SDRAM 18, and
`non-volatile memory 20 embodied by a Flash memory. Id. at Fig. 1, 3:19–
`26, 3:35–36. Non-volatile memory 20 and SDRAM 18 share the same
`interface. Id. at Fig. 1, 3:31–33. Non-volatile memory 20 stores boot code
`for initializing the SDRAM interface logic, internal logic of the SDRAM,
`and rest of the system. Id. at 3:34–37.
`
`16
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`Figure 2 of McClain is reproduced below.
`
`
`Figure 2 shows a more detailed diagram of the computer system. Id.
`
`3:14–15. Figure 2 includes CPU 14, non-volatile memory 20 with an
`SDRAM interface, System Control Logic ASIC 68, and ROM/Flash
`Controller 62.
`With reference to Figure 2, McClain describes a power-up or reset-
`time procedure in which non-volatile memory 20 pre-reads the first row of
`the memory array and has it ready for read by the end of the reset-time
`procedure. Id. at 3:38–43. McClain equates a system reset-time procedure
`with a system power-up procedure. Id. (“Referring to FIG. 2, during power-
`up (reset time)”). CPU 14 then starts the system initialization process by
`issuing reads to the address range of non-volatile memory 20. Id. at 53–55.
`
`17
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`In response, System Control Logic 68 and ROM/Flash Controller 62
`together transmit control signals to non-volatile memory 20. Id. at 3:55–63.
`These control signals comprise, among others, chip select (CS#) signal 64
`and read enable (RE#) signal 66. Id. CS# signal 64 is used to initiate a
`memory read operation at the first location in the first accessed memory row.
`Id. at Fig. 2, 3:43–47. RE# signal 66 is used indicate when the non-volatile
`memory is to deliver read data to the system data bus. Id. at Fig. 2, 3:47–49.
`When ROM/Flash Controller 62 deasserts RE# signal 66, non-volatile
`memory 20 increments the internal address to select the next location in the
`first memory row.
`During initialization, System Control Logic ASIC 68 and ROM/Flash
`Controller 62 use these control signals to cause non-volatile memory 20 to
`deliver sequential words to the data bus. Id. at 3:55–63. These first
`delivered words consist of boot code that is constructed to perform the basic
`configuration of the SDRAM interface. Id. at 3:63–67. CPU 14, thus,
`fetches the boot code and initializes the SDRAM interface for normal
`operation. Id. at 3:63–68, 4:15–18. Thus, McClain describes a power-up
`procedure in which the peripheral device sends boot code to the host device.
`Id.
`
`McClain explains that for the proper function of the power-up or
`reset-time procedure, non-volatile memory 20 must be able to recognize
`when a system reset event occurs in order to access the initial code
`sequence. Id. at 4:32–34. McClain proposes three different methods of
`implementing this reset recognition. Id. at 4:32–38, 4:52–55.
`
`18
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`First, McClain describes that in one embodiment, non-volatile
`memory 20 could recognize a system reset through a separate reset
`(RESET#) signal pin. Id. at 4:34–38.
`Second, McClain describes that in another embodiment, non-volatile
`memory 20 could instead recognize a system reset through the assertion of
`an unusual combination of standard SDRAM interface pins, such as the
`simultaneous assertion of the CS#, RAS#, CAS#, and WE# signals. Id.
`And third, McClain describes that in yet another embodiment, a boot
`(Boot#) pin performs various functions, including the indicating of a system
`reset. Id. at 52–59. In this embodiment, non-volatile memory 20 detects a
`system reset when the Boot# signal is asserted for several clock cycles. Id.
`After non-volatile memory 20 completes its internal reset, non-volatile
`memory 20 delivers data onto the bus when it detects that the Boot# signal is
`asserted. Id. Finally, when the Boot# signal is deasserted, non-volatile
`memory 20 increments its internal address to select the next sequential data
`word. Id.
`According to McClain, the control signals needed to implement the
`system initialization and the system reset recognition3 would require either
`(1) no additional control lines or (2) at most one additional control line. Id.
`at 4:59–64. That is, a system reset recognition that relies on the
`simultaneous assertion of CS#, RAS#, CAS#, and WE# signals, requires no
`additional control lines even if it requires an unusual combination of
`standard SDRAM interface pins. Id.; see also id. at Fig. 2, 4:34–38. On the
`
`
`3 McClain refers to a system reset and a system power-up interchangeably,
`and thus a system reset recognition is also a system power-up recognition.
`Ex. 1006, 3:38–43 (reciting, “during power-up (reset time)”).
`19
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`other hand, a system reset recognition that relies on either a separate
`RESET# pin or a separate Boot# pin requires at most one additional separate
`control line beyond those already included as standard SDRAM interface
`pins. Id. at 59–64; see also id. at Fig. 2, 4:34–38, 52–59.
`
`3.
`Independent Claims 6 and 20
`Independent claim 6 requires the receiving of a low signal at a
`command terminal of an MMC/SD interface before or during power up, and
`independent claim 20 also requires the receiving of a low signal at a
`command terminal of an MMC/SD interface during power up. Ex. 1001,
`18:4–8, 18:11–12, 19:59–65. As discussed below, we determine that the
`Petition fails to make an adequate showing as to how the combination of
`Toombs and McClain accounts for the step of receiving a low signal at a
`command terminal of an MMC/SD interface before or during power up.
`In relevant part, independent claim 6 recites the following: “A
`method for booting form a peripheral device having an MMC/SD-interface,
`via said MMC/SD interface with . . . a command line with command
`terminal, said method comprising: . . . receiving a low signal at the
`command terminal before or during power up” (“the limitation at issue”).
`Id. at 18:4–8, 18:11–12.
`Petitioner notes that Toombs describes systems that include an MMC
`interface with a command terminal. Pet. 35. The Petition refers to Toombs
`as describing an MMC bus that includes these MMC bus lines: power
`supply, communications (including both CMD and DAT), and clock. Id. at
`31 (citing Ex. 1005, 7:32–34). Petitioner also cites Figure 14 of Toombs and
`notes that it shows “an MMC card with command, clock, data, and power
`
`20
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`terminals that are connected to the MMC bus lines.” Id. at 32 (emphasis
`added).
`Petitioner acknowledges, however, that Toombs does not describe a
`method for booting a host device from the non-volatile, flash memory
`device. Id. at 25. Thus, Petitioner relies on McClain’s description of a
`method for booting a host device from a non-volatile flash memory. Id.
`(citing Ex. 1006, 2:25–32). McClain describes “several different options for
`indicating boot at power up.” Id. at 35–36 (citing Ex. 1003, ¶ 125).
`Petitioner argues that McClain describes “indicating boot by asserting an
`unused state during power-up without the addition of a special purpose boot
`line. Id. (citing Ex. 1006, 32–[3]8, 3:38–43; Ex. 1003 ¶ 125) (emphasis
`added). Particularly, Petitioner explains that McClain describes a boot
`indication through “an unusual combination of standard SDRAM interface
`pins, such as the simultaneous assertion of CS#, RAS#, CAS#, and WE#.”
`Id. (citing Ex. 1006, 3:38–43). And Petitioner further asserts that the “CS,
`RAS, CAS, and WE lines were well-known to be control lines for a standard
`SDRAM interface.” Id. (citing Ex. 1003 ¶ 125).
`Petitioner then asserts that “McClain further discloses that a single
`line can be used to indicate boot without the addition of a special purpose
`boot line.” Id. (citing Ex. 1006, 4:32–38, 4:52–64) (emphasis added). In
`light of McClain’s teachings, Petitioner concludes that an ordinarily skilled
`artisan “would understand from this disclosure that without the addition of a
`special purpose boot line, a single line could be used to indicate boot using
`an unused state during power-up.” Pet. 36–37 (citing Ex. 1003 ¶ 125)
`(emphasis added).
`
`21
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`
`In its obviousness analysis, having discussed how McClain allegedly
`describes a boot indication that uses a single line, without the addition of a
`special purpose line, Petitioner explains why an ordinarily skilled artisan
`would have (1) selected the command line of an MMC interface to indicate
`boot by (2) setting it to a low value. Pet. 37–38. According to Petitioner, an
`ordinarily skilled artisan would have selected the command line based on the
`limited number of lines already available in an MMC/SD interface: power,
`clock, data, and command. Id. (citing Ex. 1005, 6:18–38). Because the
`other lines are already used for other purposes during initialization,
`Petitioner argues that an ordinarily skilled artisan would have selected the
`command line as “the most logical choice” for indicating boot. Id. Finally,
`because the command line is ordinarily held high during initialization,
`Petitioner argues that an ordinarily skilled artisan would have been
`motivated to set the command line to a low value in order to indicate boot.
`Id. at 37–38.
`Patent Owner notes that the Petition relies heavily on the purported
`teaching of a booting method that does not require the addition of a special
`purpose boot line and does not add another control signal. Prelim. Resp. 10.
`Patent Owner argues that in doing so, the Petition mischaracterizes
`McClain’s booting mechanism. Id. at 11. According to Patent Owner,
`McClain contemplates adding an additional control line to the MMC
`interface in the embodiments relied on by the Petition. Id. at 12 (citing
`Ex. 1006, 4:52–64). Patent Owner, thus, argues that contrary to Petitioner’s
`contentions, McClain does not describe using only a single signal for a
`system reset without adding a special purpose boot line or using an unused
`
`22
`
`

`

`IPR2019-00651
`Patent 7,739,487 B2
`
`state of a signal to indicate boot without the addition of a special purpose
`boot line. Id. at 12 (citing Pet. 29–30).
`We agree with Patent Owner that Petitioner mischaracterizes the
`teachings of McClain and that the mischaracterization of McClain renders
`Petitioner’s obviousness analysis unsupportable. We are not persuaded that
`McClain describes an embodiment in which “a single line can be used to
`indicate boot without the addition of a special purpose boot line,” as
`Petitioner asserts. Id. at 36 (citing Ex. 1006, 4:32–38, 4:52–64) (emphasis
`added). We are further not persuaded that one of ordinary skill in the art
`“would understand from [McClain] that without the addition of a special
`purpose boot line, a single line could be used to indicate boot using an
`unused state during power-up,” as Petitioner argues. Id. at 36–37 (citing
`Ex. 1003 ¶ 125).
`Petitioner cites column 4, lines 32–38 and lines 52–64 of McClain, as
`support for its proposition that McClain describes a single line that can be
`used to indicate boot without the addition of a special purpose boot line.
`Pet. 36. Those cited portions of McClain are reproduced below:
`It will be appreciated that a non-vo

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