`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________________
`
`
`APPLE INC.
`Petitioner,
`
`v.
`
`PAPST LICENSING GMBH & CO. KG
`Patent Owner
`
`___________________
`
`Case IPR2016-01864
`Patent 6,470,399
`___________________
`
`
`
`
`DECLARATION OF EREZ ZADOK, PH.D.
`IN SUPPORT OF REPLY TO PATENT OWNER’S RESPONSE
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Apple 1054
`IPR2016-01864
`
`
`
`Table of Contents
`
`I.
`II.
`
`Introduction .................................................................................................... 1
`The combination of Pucci, Schmidt, and Kepley discloses the disputed
`features of claims 1, 11, and 14. ..................................................................... 2
`A. The combination discloses the inquiry response recited in claims 1, 11,
`and 14. .................................................................................................... 2
`B. The combination discloses the driver limitation of claims 1, 11, and
`14..........................................................................................................10
`C. A POSITA would have been motivated to combine Pucci and
`Schmidt. ...............................................................................................16
`Conclusion ....................................................................................................20
`
`
`III.
`
`
`
`
`
`
`- ii -
`
`
`
`I.
`
`Introduction
`
`I, Dr. Erez Zadok, declare as follows:
`
`1.
`
`I submit this declaration in support of Apple Inc.’s (“Petitioner”)
`
`Reply to the Patent Owner Response to the Petition for Inter Partes Review of
`
`U.S. Patent No. 6,470,399 (“the ’399 patent”) titled “Flexible Interface for
`
`Communication Between a Host and an Analog I/O Device Connected to the
`
`Interface Regardless the Type of the I/O Device” by Michael Tasler, and that the
`
`’399 patent is currently assigned to Papst Licensing GmbH & Co. KG.
`
`2.
`
`This declaration supplements my October 11, 2016 declaration
`
`submitted as Exhibit 1003 in the above-referenced proceeding and is in response to
`
`Patent Owner’s Response to Petition for Inter Partes Review (“Response”) dated
`
`June 26, 2017, and the Declaration of Thomas A. Gafford, submitted as Exhibit
`
`2002 and dated June 26, 2017. I understand that my curriculum vitae has been
`
`submitted into the record of this proceeding as Exhibit 1004.
`
`3.
`
`In preparing this declaration, in addition to my knowledge and
`
`experience, I have reviewed and am familiar with the following references:
`
`Configurable Data Manipulation in an Attached
`Multiprocessor, by Marc F. Pucci (“Pucci”) (Ex. 1041.)
`
`The SCSI Bus and IDE Interface—Protocols,
`Applications and Programming by Friedhelm Schmidt
`(“Schmidt”) (Ex. 1007);
`
`
`
`
`- 1 -
`
`
`
`U.S. Patent No. 4,790,003, to Kepley et al., titled
`“Message Service System Network.” (Ex. 1042.)
`
`Board’s Decision to Institute Trial (Paper 10);
`
`Patent Owner’s Response to Petition for Inter Partes
`Review (Paper 16);
`
`Declaration of Thomas A. Gafford (Exhibit 2002); and
`
`1st and 2nd Deposition Transcripts of Mr. Gafford (“1st
`Gafford Depo.” and “2nd Gafford Depo.”) (Exhibits 1055
`and 1056).
`
`4.
`
`I have also considered all other materials cited herein.
`
`II. The combination of Pucci, Schmidt, and Kepley discloses the disputed
`features of claims 1, 11, and 14.
`A. The combination discloses the inquiry response recited in claims
`1, 11, and 14.
`
`5.
`
`I understand that Patent Owner argues that: (1) Pucci alone does not
`
`explicitly disclose how it responds to a SCSI INQUIRY (POR, p. 16); (2) Schmidt
`
`does not disclose identifying a device “as something other than what is actually is”
`
`(POR, p. 17); and (3) it would have been “illogical” for Pucci’s ION Node to
`
`identify itself as a disk drive (POR, pp. 17–18). I disagree with all three of these
`
`arguments.
`
`6. With regard to (1) and (2), these positions are without merit because
`
`they ignore the disclosures in Pucci that would have informed a POSITA exactly
`
`
`
`
`- 2 -
`
`
`
`how Pucci utilizes the SCSI standard protocol, ignore that Pucci specifically cites
`
`to the ANSI 3.131 SCSI standard document, and ignore a POSITA’s understanding
`
`of the standard SCSI protocol including its mandatory commands such as
`
`INQUIRY as it is described in Schmidt.
`
`7.
`
`Specifically, Pucci explains that “[s]oftware running within the ION
`
`system mimics the behavior of a conventional device,” (Ex. 1041, Pucci, p. 220,
`
`(emphasis added)). This concept of mimicry, or emulation, was well known to a
`
`POSITA at the time of the ’399 patent. As I explained in my original declaration,
`
`emulation allowed a host computer to interact with peripheral devices using
`
`existing drivers, (Ex. 1003, Zadok Decl., ¶ 36), which is consistent with Pucci’s
`
`goal of “providing the workstation with a peripheral that it knows how to deal
`
`with” (Pucci, p. 220).
`
`8.
`
`A POSITA would understand that this mimicry of a “conventional
`
`device” could be accomplished by “exactly simulat[ing] the characteristics and
`
`responses of the normal computer hardware which it replaces.” (Zadok Decl., ¶ 36,
`
`citing Maclean (Ex. 1010), 4:49–53 (emphasis added).) Accordingly, a POSITA
`
`would reasonably understand that the ION system “mimics the behavior of a
`
`conventional device” by providing the characteristics and responses of the
`
`conventional device to the host workstation.
`
`
`
`
`- 3 -
`
`
`
`9.
`
`Further, Pucci discloses that the ION system mimics a “conventional
`
`[SCSI] disk drive.” (Pucci, p. 220 (“Each workstation views its ION connection as
`
`though it were a large conventional disk drive”), p. 220 (“A workstation sees ION
`
`as though it were physically a local disk drive (an ION drive) with a data capacity
`
`of 2 terabytes (the SCSI limit).”) Because the workstation views the ION system as
`
`a SCSI device (i.e., mimics a SCSI device), a POSITA would reasonably
`
`understand that the ION system provides the appropriate SCSI signaling to the
`
`workstation to accomplish this subterfuge. Schmidt describes the SCSI signaling
`
`that would enable to a host to recognize a device as a disk drive.
`
`10. As one example, the INQUIRY command is a command used to
`
`identify useful information, such as a peripheral’s device class, that is returned
`
`within an INQUIRY response. (Ex. 1007, Schmidt, pp. 138–39 (displaying
`
`INQUIRY data format and identifying it as a [M]andatory command).) A device
`
`identifying as a disk drive would respond with INQUIRY data indicating a device
`
`class of ‘00h’ corresponding to the disk drive class. (See Schmidt, p. 133, Table
`
`12.1; see also p. 140 (discussing the Peripheral device type portion of the
`
`INQUIRY data).) Thus, in the combination of Pucci and Schmidt, where Pucci’s
`
`ION identifies as a hard disk, it would respond to a SCSI INQUIRY command
`
`with INQUIRY data identifying it as a type of disk drive.
`
`
`
`
`- 4 -
`
`
`
`11. Pucci provides no indication that the ION Node would be “unable to
`
`return the requested inquiry data” per the conventional procedures of the
`
`INQUIRY command. (Schmidt, p. 138.) Indeed, while Pucci does not specifically
`
`disclose the use of an INQUIRY command, Pucci’s description of the SCSI
`
`implementation for his invention is consistent with Schmidt’s descriptions above.
`
`Specifically, Pucci explains that “an initiator (usually the host processor) starts an
`
`operation by arbitrating for the SCSI bus and selecting a target device (such as a
`
`disk drive) to respond to its request.” (Pucci, p. 239, (emphasis added).)
`
`12. Mr. Gafford further opines that “it is not mandatory for a SCSI target
`
`such as the ION to respond with inquiry data or with particular inquiry data” but
`
`can instead return a “simple CHECK CONDITION message1.” (Ex. 2002, Gafford
`
`Decl., ¶ 58.) Mr. Gafford’s explanation of the CHECK CONDITION command is
`
`incomplete and misleading because it leaves out important details and makes
`
`assumptions counter to Pucci’s disclosures.
`
`
`1 I note that CHECK CONDITION is a status not a message. (Compare
`
`Schmidt, p. 137 (listing status bytes), with Schmidt, p. 119 (listing the SCSI
`
`message codes).)
`
`
`
`
`
`
`- 5 -
`
`
`
`13. Schmidt makes clear that “INQUIRY will only return CHECK
`
`CONDITION if the target is unable to return the requested inquiry data.”
`
`(Schmidt, p. 138, (emphasis added).) In other words, a response to an INQUIRY
`
`command is required––either INQUIRY data or a CHECK CONDITION status.
`
`(Schmidt, p. 88 (describing that, in response to setting to zero the EVPD bit in the
`
`INQUIRY command, “the target shall return the standard INQUIRY data” and
`
`when the bit is set to 1, then a CHECK CONDITION status is returned) (emphasis
`
`added).) In normal operating conditions, the target peripheral device will return the
`
`requested INQUIRY data.
`
`14. A CHECK CONDITION status is a type of error condition and is only
`
`returned in response to an INQUIRY “if the target is unable to return the requested
`
`inquiry data.” (Schmidt, pp. 88, 138.) In the limited circumstances when a CHECK
`
`CONDITION status is returned, the host will follow up with a REQUEST SENSE
`
`command. (Schmidt, pp. 137, 142–43.) The REQUEST SENSE command is used
`
`by the initiator “to determine just exactly what has occurred.” (Schmidt, p. 133.) In
`
`response to the REQUEST SENSE command, the target would provide “in more
`
`detail the nature of the problem.” (Schmidt, p. 138.)
`
`15. Mr. Gafford’s comment that “a target device may be configured to
`
`respond with a simple CHECK CONDITION message,” (Gafford Decl., ¶ 58,
`
`(emphasis added)), is therefore misleading because all devices that implement the
`
`
`
`
`- 6 -
`
`
`
`SCSI protocol are configured to provide a CHECK CONDITION status.
`
`Specifically, all devices that implement the SCSI standard are configured to
`
`provide the CHECK CONDITION status when appropriate (i.e., when an error
`
`happens). (Schmidt, p. 137 (“All Commands end with a status phase” and Table
`
`12.9 provides one example of a status is CHECK CONDITION.).)
`
`16. Mr. Gafford’s comment that a CHECK CONDITION may be returned
`
`in the ION system is further misleading because, if true, it would have made the
`
`ION system inoperable—essentially always returning an error condition and never
`
`succeeding in reading any data. A POSITA would therefore have understood that
`
`no operable SCSI device would always return a CHECK CONDITION in response
`
`to an INQUIRY command. Yet nothing in Pucci suggests that it explicitly deviated
`
`from the standard SCSI protocol but rather followed it closely in order to benefit
`
`from that protocol’s standardization and existing software drivers (Pucci, pp. 219–
`
`20 (“The low level connection between these components is the ... (SCSI) disk
`
`interface, ANSI X3.131. ... ION using its local disk system, which is a stable, well-
`
`defined interface, there is no need to change vendor supplied host system
`
`software,” pp. 238–40 (an appendix providing some SCSI details)). To the
`
`contrary, Pucci discloses that the ION system indeed was implemented and
`
`operated as a “prototype programmable telephone switch system called GARDEN”
`
`(Pucci, p. 231).
`
`
`
`
`- 7 -
`
`
`
`17. Moreover, a POSITA would have understood that the ION system
`
`would not simply return a CHECK CONDITION status to the host workstation.
`
`“The command REQUEST SENSE is always used in response to a CHECK
`
`CONDITION in order to read the sense data.” (Schmidt, p. 142.) Sense data is an
`
`important part of this process because it “gives information concerning the reason
`
`why the preceding command ended abnormally.” (Schmidt, p. 142.) Sense data
`
`includes a sense key. (Schmidt, p. 143.) Examples of sense keys include error
`
`messages such as NOT READY (the addressed LUN is not ready to be accessed),
`
`MEDIUM ERROR (the target detected a data error on the medium), and DATA
`
`PROTECT (access to the data is blocked). (Schmidt, p. 144 (Table 12.18).)
`
`18. Because sense data is returned in response to a CHECK CONDITION
`
`status, CHECK CONDITION is used providing diagnostic information when
`
`something has gone wrong. In the context of an INQUIRY command and contrary
`
`to Mr. Gafford’s allegation, CHECK CONDITION is not a message but an
`
`indication to the target device that the INQUIRY command was not properly
`
`executed. When executed properly by the ION system, an INQUIRY command
`
`from the host computer would result in the ION system returning an indication that
`
`it is a conventional SCSI disk drive using the appropriate SCSI signaling.
`
`19. With regard to (3), Patent Owner argues against the combination,
`
`stating that “[i]f the ION Node were to respond to an inquiry from a workstation
`
`
`
`
`- 8 -
`
`
`
`that it was a disk drive without proper ION software installed and operating on the
`
`workstation, the workstation would most reasonably attempt to access the ION
`
`Node and/or reconfigure the ION Node in an unpredictable and potentially
`
`destructive manner.” I disagree.
`
`20. Pucci describes the ION Node as utilizing a Small Computer Systems
`
`Interface (SCSI) interface to connect to the ION workstation. (Pucci, p. 217 (“The
`
`ION Data Engine… is a back-end system, connecting to a workstation via the
`
`Small Computer Systems Interface (SCSI) disk interface”).) As Pucci explains and
`
`as would be readily known to a POSITA, “SCSI… is a protocol definition for
`
`connecting processors, disk drives, printers and other devices.” (Pucci, p. 238.) A
`
`person looking to implement Pucci’s system based on the SCSI protocol would
`
`have looked to the prior art and/or well-known knowledge for possible techniques
`
`for how to implement Pucci’s ION Node. That person would have arrived at
`
`Schmidt, which supplements Pucci with explicit disclosures of the SCSI protocol.
`
`As I previously explained, SCSI is a standardized interface and protocol that
`
`utilizes standardized commands (Zadok Decl., ¶¶ 37, 45, 46, 49, 101, 120, 136),
`
`which includes the mandatory INQUIRY command. (Id., ¶ 104.) Mr. Gafford
`
`confirms this explanation. (Ex. 1055, 1st Gafford Depo., 19:21–20:9 ((“Q. So this
`
`portion of the ’399 sentence––patent says it issues, “an instruction known by those
`
`skilled in the art as the inquiry instruction.” So I’m trying to understand why that
`
`
`
`
`- 9 -
`
`
`
`was a type of instruction that would’ve been known by those skilled in the art at
`
`the time of the ’399 patent? A. It’s part of the SCSI spec, and it’s described in the
`
`SCSI spec as the way in which a host can determine what type of device it’s
`
`talking to over the multipurpose SCSI interface.”).)
`
`B.
`
`The combination discloses the driver limitation of claims 1, 11,
`and 14.
`21. Claim 1 further recites “whereupon the host device communicates
`
`with the interface device by means of the driver for the input/output device
`
`customary in a host device,” (Ex. 1001, ’399 patent, 13:5–8), and claims 11 and 14
`
`contain similar limitations. (See ’399 patent, 14:12–15; 14:55–57.) I understand
`
`that Patent Owner argues that the prior art does not disclose this limitation
`
`“because the ION Node communicates with the host device by means of
`
`specialized software that is not a ‘driver for an input/output device customary in a
`
`host device.’” (POR, p. 19, (emphasis added).) In particular, Mr. Gafford states
`
`that “[t]here would have been no benefit… to have the ION misrepresent itself to a
`
`workstation without user intervention, given the requirement of having to modify
`
`the workstation first with ION custom application software for the system to
`
`work.” (Gafford Decl., ¶ 0051 (emphasis added).) Accordingly, I understand that
`
`Papst is characterizing Pucci’s alleged specialized software as “application
`
`software.”
`
`
`
`
`- 10 -
`
`
`
`22.
`
`I note that the claims require a “driver” and not “application
`
`software.” Indeed, application software is distinct from driver software in that
`
`application software uses the driver software to communicate with a host device.
`
`For example, as shown in the figures below, the well-known MS-DOS and UNIX
`
`operating systems separate applications/user software from driver software.
`
`Application
`
`Drivers
`
`
`
`User software
`(applications)
`
`Drivers
`
`
`
`(Ex. 1013, Silberschatz, pp. 77–78 (annotated).) Silberschatz also discusses other
`
`
`
`designs, such as the Venus layer structure, where user programs sit at layer 6, and
`
`
`
`
`- 11 -
`
`
`
`device drivers sit at layer 5, as illustrated below. In such a system, the user
`
`programs must use the device drivers to communicate with the hardware devices.
`
`(See Silberschatz, p. 80 (“a layer can use only those layers that are at a lower
`
`level”).)
`
`Communication
`flows to hardware
`
`
`
`(Ex. 1013, Silberschatz, p. 81 (annotated).)
`
`23.
`
` A POSITA would understand, based on these guiding principles of
`
`operating systems, that Pucci’s use of an application—specialized or not—would
`
`obviate the need for a specialized or custom driver to facilitate the communication
`
`between such an application and the underlying hardware of Pucci’s ION Node.
`
`Pucci’s disclosures support this understanding. For example, Pucci discloses that
`
`its workstation communicates with the ION drive “in terms of standard disk read
`
`and write accesses.” (Pucci, p. 221; see Petition, p. 38.) The application therefore
`
`uses a standard disk driver, enabling “the application [to] remain[] portable across
`
`workstation changes, operating system releases, and to a large degree, complete
`
`
`
`
`- 12 -
`
`
`
`operating system changes.” (Pucci, p. 221; see Petition, p. 38.) If Pucci used a
`
`custom driver, the application would not be portable because the system would
`
`need to update the custom driver for every new operating system release (e.g., a
`
`new version of MS-DOS) and every change in operating system (e.g., changing
`
`between MS-DOS and UNIX), directly contradicting Pucci.
`
`24.
`
` I also understand that Papst argues that “Pucci’s disclosure of a
`
`controlling program/application that must be loaded… is contrary to the ’399
`
`Patent’s explicit teachings of an interface device that requires no specialized
`
`software to be loaded on the host computer by a user.” (POR, pp. 20–21.) I see no
`
`requirement, based on the claim language—“interface device by means of the
`
`driver for the input/output device customary in a host device”—that the claims
`
`prohibit a user from installing any software onto Pucci’s workstation, but only
`
`require that the host device communicate with the interface device using the driver
`
`for the customary I/O device. As I explained in my prior declaration, because the
`
`ION Node identifies itself as a disk drive, the host device would use the standard
`
`SCSI disk drive device driver to communicate with it. (Zadok Decl., ¶¶ 112–13).)
`
`25.
`
`I also understand that Papst further argues that “installation of the
`
`controlling program/application on the ION Workstation is required for the ION
`
`Workstation to communicate with the ION Data Engine/Node so that it knows
`
`which block addresses to access.” (POR, pp. 21–22.) I disagree, as it was widely
`
`
`
`
`- 13 -
`
`
`
`known that application software communicates with peripherals via device drivers,
`
`as I described above, and the existence of an application on Pucci’s workstation
`
`does not mitigate the use of a standard device driver to communicate with the ION
`
`Node.
`
`26. Moreover, regardless of whether the ION Workstation “knows which
`
`block addresses to access” (POR, p. 22), it communicates with the ION Node via a
`
`standard SCSI hard disk device driver. I refer back to Pucci’s statement that
`
`“[s]oftware running within the ION system mimics the behavior of a conventional
`
`device.” (Pucci, p. 220.) A POSITA would understand that the workstation would
`
`be able to communicate with the ION system as if it were a conventional device,
`
`such as a conventional disk drive. This understanding is consistent with Pucci’s
`
`stated goal of “providing the workstation with a peripheral that it knows how to
`
`deal with” (Pucci, p. 220) and that “there is no need to change vendor supplied host
`
`system software.” (Pucci, pp. 219–20.)
`
`27.
`
`Indeed, in the context of an analog-to-digital conversion system, Pucci
`
`acknowledges the benefits of using a customary device driver. “Additionally, since
`
`the hardware dependent A-to-D code remains within ION, no driver changes to the
`
`host’s operating system are necessary upon workstation upgrade.” (Pucci, p. 231
`
`(emphasis added).) Although not directly related to its SCSI implementation, this
`
`statement clearly demonstrates Pucci’s understanding of the benefits of including
`
`
`
`
`- 14 -
`
`
`
`the software within the peripheral device itself. With respect to Pucci’s ION
`
`system including software for mimicking the behavior of a conventional device, a
`
`POSITA would understand that no driver changes to the host computer would be
`
`necessary in order to communicate with the ION system. (Pucci, pp. 219–20.)
`
`28.
`
`I also understand that Papst argues that Pucci necessarily has loaded
`
`software on the workstation because the ION needs to know “where” (e.g., which
`
`data blocks), to read from the ION. (See POR, p. 28.) However, this argument
`
`ignores Pucci’s implementation of the standard SCSI protocol, Pucci’s stated goal
`
`of having the ION system mimic a conventional disk drive, and Schmidt’s
`
`disclosures of the conventional SCSI signals that allow for a host to communicate
`
`with a peripheral device.
`
`29. This understanding of Pucci’s “software” within the ION system is
`
`consistent with Mr. Gafford’s explanation that user-loaded software was
`
`unnecessary for the SCSI embodiment disclosed in the ’399 patent. Mr. Gafford
`
`explains that the booting routine was performed through existing SCSI drivers in
`
`the operating system (Ex. 1056, 2nd Gafford Depo., 29:24–30:5 (“Q. And then for
`
`Windows and UNIX, the operating system, it would rely on BIOS routines for the
`
`SCSI driver? A. Yeah. No need for the user to do anything. They would just notice
`
`that the device was there and reconfigure it to make it usable”), and in the context
`
`of DOS, this routine also did not need user-loaded software because the routine ran
`
`
`
`
`- 15 -
`
`
`
`on the existing BIOS. (See 2nd Gafford Depo., 29:5–29:18 (“So for the DOS
`
`operating system, it would rely on BIOS routines for the SCSI driver? A. Sure.”) ;
`
`see also 2nd Gafford Depo., 21:15–22:10 (“A. Well, a SCSI type of interface
`
`embodies what’s described here as a multipurpose interface, and the software that
`
`runs the SCSI interface would either be a BIOS resident or OS resident driver for–
`
`–made for use with that interface. Q. And so it would be SCSI driver either
`
`resident in the BIOS or the operating system? A. Yes”).) This software would treat
`
`the peripheral device as a hard disk, and once the software identified the peripheral
`
`device as a hard disk, the software would gather the hard disk parameters, such as
`
`size and maximum block size. (See 1st Gafford Depo., 18:4–15 (“A. Typically, in
`
`the world of SCSI software, it would inquire as to specific parameters of the device
`
`to try to understand what capabilities––let’s see. Actually, given that these were
`
`general purpose SCSI hard disk drivers… the software would treat the attached
`
`device in Figure 1 [of the ’399 Patent] as a hard disk, and once it knows it’s hard
`
`disk, it would gather the hard disk parameters, such as size, maximum block
`
`size”).) This implementation is similar to what is described in Pucci and is
`
`consistent with a POSITA’s understanding of the SCSI protocol.
`
`C. A POSITA would have been motivated to combine Pucci and
`Schmidt.
`
`30.
`
`I understand that Papst argues against combining Pucci and Schmidt
`
`because “it would have been illogical for a POSITA to configure an ION device to
`
`
`
`
`- 16 -
`
`
`
`transfer data to and from an ION workstation without the proper communication
`
`software installed to work with the ION Node….” (POR, p. 27.) For reasons I’ve
`
`discussed above, this argument focuses on application software and does not have
`
`any foundation within the claim language, which merely recite a “driver.”
`
`31.
`
`I also understand that Papst argues that the combination “would
`
`render the Pucci invention operable if the interface device of Pucci responded to an
`
`Inquiry in the context of the SCSI standard by saying the device at that ID is a hard
`
`drive because the device at that ID would be incapable of performing the functions
`
`of a hard drive.” (POR, p. 28.) Papst alleges that “[t]his situation would lead to
`
`unpredictable results.” (POR, p. 27.) I disagree.
`
`32. Patent Owner’s speculation that somehow an INQUIRY response
`
`would cause the workstation to begin accessing and reconfiguring the ION in an
`
`unpredictable manner is contrary to Pucci’s teachings and a POSITA’s
`
`understanding of the well-known principles of SCSI. The INQUIRY command is a
`
`command used to identify useful information, such as a peripheral’s device class,
`
`that is returned within an INQUIRY response. (Schmidt, pp. 138–39 (displaying
`
`INQUIRY data format and identifying it as a [M]andatory command).) Each
`
`device class has its own command set. (Schmidt, p. 132 (“For each device class
`
`SCSI defines a model, a command set and parameter pages for configuring the
`
`device.”).) To obtain this command set, a SCSI initiator, such as Pucci’s
`
`
`
`
`- 17 -
`
`
`
`workstation, utilizes the INQUIRY command to identify the device class. (Id.)
`
`Implementing these standard procedures of SCSI, the initiator (e.g., the
`
`workstation) knows how to “deal with” the target. (Pucci, p. 220.) But the
`
`workstation does not simply start writing to or re-configuring the peripheral device
`
`right after identifying the device class. And, because Pucci’s ION Node is designed
`
`to mimic a local hard drive, it would be able to support the standard SCSI protocol
`
`messages that typically follow the INQUIRY data.
`
`33. Pucci’s ION system would still operate properly, even if the
`
`workstation attempted to improperly access the ION Node (e.g., accessing a
`
`portion of the ION “disk” that did not correspond to a known ION command). For
`
`reasons I discussed above with regard to the CHECK CONDITION status, the
`
`SCSI protocol provides functionality for an initiator and target to handle
`
`unexpected and/or error conditions. For example, SCSI provides a mechanism
`
`using the CHECK CONDITION status and a subsequent message including the
`
`DATA PROTECT sense key to inform the workstation that it cannot read or write
`
`to a portion of the disk because that portion of the disk is currently protected. (See
`
`Schmidt, pp. 142–44; see also Pucci, p. 221 (explaining that an advantage of Pucci
`
`is “its robustness in the face of application failure” and that the “worst case
`
`scenario” merely places the ION into an off-line condition).)
`
`
`
`
`- 18 -
`
`
`
`34.
`
`In the proposed combination, the ION responds to the INQUIRY
`
`command by identifying the device class as a disk drive (i.e., with code 00h).
`
`(Schmidt, pp. 132–33 (illustrating a list of device classes); see also 2nd Gafford
`
`Depo., 83:5–11 (“But you would agree that the ION node could be implemented to
`
`identify itself as a disk drive in response to an inquiry command? … A. Nothing in
`
`the ION spec suggests or prevents doing so.”).) Such a response provides the exact
`
`results that Pucci discloses because Pucci is used to mimic a local disk drive. That
`
`is, the INQUIRY response identifying the ION Node as a disk drive (despite the
`
`ION not being an actual disk drive) does not result in a destructive reconfiguration
`
`or an inoperable system because it actually achieves Pucci’s stated goal of having
`
`“[s]oftware running within the ION system [that] mimics the behavior of a
`
`conventional device, providing the workstation with a peripheral that it knows how
`
`to deal with.” (Pucci, p. 220.) And a POSITA would not have encountered
`
`unpredictable results because, as I outlined above, emulation within the context of
`
`SCSI was possible. Indeed, the proposed combination is how the system in the
`
`’399 patent operates. (See 1st Gafford Depo., 21:6–22:25, 72:7–22, 73:9–19
`
`(explaining that the preferred embodiment responds to the INQUIRY command by
`
`identifying a peripheral as a hard drive, albeit the peripheral not being an actual
`
`hard drive).)
`
`
`
`
`- 19 -
`
`
`
`III. Conclusion
`In signing this declaration, I recognize that the declaration will be
`35.
`
`filed as evidence in a contested case before the Patent Trial and Appeal Board of
`
`the United States Patent and Trademark Office. I also recognize that I may be
`
`subject to cross-examination in the case and that cross-examination will take place
`
`within the United States. If cross-examination is required of me, I will appear for
`
`cross-examination within the United States during the time allotted for cross-
`
`examination.
`
`
`
`
`
`
`- 20 -
`
`
`
`I hereby declare that all statements made herein of my own knowledge are
`
`true and that all statements made on information and belief are believed to be true;
`
`and further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under Section 1001 of Title 18 of the United States Code.
`
`Executed this 23rd day of October, 2017.
`
`Respectfully submitted,
`
`
`
`
`
`______________________________
`Erez Zadok
`
`
`
`
`- 21 -
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
