`
`___________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________________
`
`
`
`DECLARATION OF EREZ ZADOK, PH.D.
`IN SUPPORT OF PETITION FOR INTER PARTES REVIEW OF
`U.S. PATENT 9,189,437
`
`
`
`
`
`
`
`Apple 1003
`IPR2017-00156
`U.S. Pat. 9,189,437
`
`
`
`
`
`
`
`Table of Contents
`
`
`Introduction. ........................................................................................................................ 1
`I.
`Qualifications. ..................................................................................................................... 2
`II.
`III. My understanding of claim construction. ........................................................................... 8
`IV. My understanding of obviousness. ..................................................................................... 9
`V.
`Level of ordinary skill in the art. ...................................................................................... 10
`VI.
`Background of the technologies disclosed in the ’437 patent. ......................................... 11
`A. Device emulation. ......................................................................................................... 11
`B. Hard disk interface technologies. ................................................................................. 17
`C. Operating systems and file systems. ............................................................................. 22
`VII. Claim construction. ........................................................................................................... 27
`VIII. Ground 1: The combined system of Moriyasu and Ousley renders claims 1, 5, 6, 9, 11,
`12–16, 30, 32, and 34 obvious. ......................................................................................... 27
`A. Overview of Moriyasu and Ousley .............................................................................. 27
`B. The combined system of Moriyasu and Ousley renders independent claim 1 obvious.
` 31
`1. The combined system of Moriyasu and Ousley teaches the preamble: “an analog
`data generating and processing device (ADGPD).” ................................................. 31
`2. The combined system of Moriyasu and Ousley teaches the ADGPD architecture
`elements. .................................................................................................................... 32
`a) The combined system of Moriyasu and Ousley teaches “an input/output (i/o)
`port.” ..................................................................................................................... 33
`b) The combined system of Moriyasu and Ousley teaches “a program memory.” .. 33
`c) The combined system of Moriyasu and Ousley teaches “a data storage memory.”
` 34
`d) The combined system of Moriyasu and Ousley teaches “a processor operatively
`interfaced with the I/O port, the program memory and the data storage memory.”
` 35
`3. The combined system of Moriyasu and Ousley teaches the acquisition and
`processing limitations of independent claim 1. ......................................................... 38
`a) The combined system of Moriyasu and Ousley teaches the acquisition limitation
`[1E.1]. ................................................................................................................... 39
`b) The combined system of Moriyasu and Ousley teaches the processing limitation
`[1E.2]. ................................................................................................................... 43
`4. The combined system of Moriyasu and Ousley teaches the automatic recognition
`limitation of independent claim 1. ............................................................................. 45
`
`
`
`
`- ii -
`
`
`
`a) The combined system of Moriyasu and Ousley teaches the automatic recognition
`operation [1F.1]..................................................................................................... 46
`b) The combined system of Moriyasu and Ousley teaches the end user requirements
`[1F.2]. .................................................................................................................... 54
`c) The combined system of Moriyasu and Ousley teaches the automatic recognition
`data element requirements [1F.3]. ........................................................................ 58
`5. The combined system of Moriyasu and Ousley teaches the file transfer limitation of
`independent claim 1. .................................................................................................. 63
`a) The combined system of Moriyasu and Ousley teaches the recited automatic file
`transfer process [1G.1, 1G.2]. ............................................................................... 64
`b) The combined system of Moriyasu and Ousley teaches the emulation and user
`requirement component of the file transfer limitation [1G.3, 1G.4]. .................... 69
`C. The combined system of Moriyasu and Ousley renders claim 5 obvious. ................... 70
`D. The combined system of Moriyasu and Ousley renders claim 6 obvious. ................... 71
`E. The combined system of Moriyasu and Ousley renders claim 9 obvious. ................... 72
`F. The combined system of Moriyasu and Ousley renders claim 11 obvious. ................. 74
`G. The combined system of Moriyasu and Ousley renders claim 12 obvious. ................. 77
`H. The combined system of Moriyasu and Ousley renders claim 13 obvious. ................. 78
`I. The combined system of Moriyasu and Ousley renders claim 14 obvious. ................. 80
`J. The combined system of Moriyasu and Ousley renders claim 15 obvious. ................. 83
`K. The combined system of Moriyasu and Ousley renders claim 16 obvious. ................. 84
`L. The combined system of Moriyasu and Ousley renders claim 18 obvious. ................. 84
`M. The combined system of Moriyasu and Ousley renders claim 30 obvious. ................. 85
`N. The combined system of Moriyasu and Ousley renders claim 32 obvious. ................. 87
`O. The combined system of Moriyasu and Ousley renders claim 34 obvious. ................. 89
`Ground 2: The combination of Moriyasu, Ousley, and Williams renders claims 4 and 10
`obvious. ............................................................................................................................. 90
`A. The combination of Moriyasu, Ousley, and Williams renders claim 4 obvious. ......... 90
`B. The combination of Moriyasu, Ousley, and Williams renders claim 10 obvious. ....... 92
`X.
`The challenged claims of the ’437 patent are not entitled to priority benefit as a
`continuation to the abandoned March 2005 application. .................................................. 93
`Conclusion. ....................................................................................................................... 95
`
`
`
`
`
`- iii -
`
`IX.
`
`XI.
`
`
`
`
`
`
`
`I.
`
`Introduction.
`
`I, Dr. Erez Zadok, declare as follows:
`
`1.
`
`I have been retained on behalf of Apple Inc. for the above-captioned
`
`inter partes review proceeding. I understand that this proceeding involves U.S.
`
`Patent No. 9,189,437 (“the ’437 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
`
`’437 patent is currently assigned to Papst Licensing GmbH & Co. KG.
`
`2.
`
`In preparing this declaration, I have reviewed and am familiar with all
`
`the references cited herein.
`
`3.
`
`The ’437 patent describes an interface device that “simulates, both in
`
`terms of hardware and software, the way in which a conventional input/output
`
`device functions, preferably that of a hard disk drive.” (Ex. 1001, ’437 patent,
`
`4:16–20.) I am familiar with the technology described in the ’437 patent as of its
`
`August 24, 2006 filing date and its claimed March 4, 1997 priority date.
`
`4.
`
`I have been asked to provide my independent technical review,
`
`analysis, insights, and opinions regarding the ’437 patent and the references that
`
`form the basis for the four grounds of rejection set forth in the Petition for Inter
`
`Partes Review of the ’437 patent.
`
`
`
`- 1 -
`
`
`
`II. Qualifications.
`As indicated in my curriculum vitae, attached as Exhibit 1004, I am a
`5.
`
`Professor in the Computer Science Department at Stony Brook University (part of
`
`the State University of New York (“SUNY”) system). I direct the File Systems and
`
`Storage Lab (FSL) at Stony Brook’s Computer Science Department. My research
`
`interests include file systems and storage systems, operating systems, energy
`
`efficiency, performance and benchmarking, information technology and system
`
`administration, security, networking, compilers, and software engineering.
`
`6.
`
`I studied at a professional high school in Israel, focusing on electrical
`
`engineering (“EE”), and graduated in 1982; for my final high-school EE project, I
`
`developed a system and custom protocol to exchange data between a Commodore
`
`CBM-9000 6502-processsor-based personal-computer and a custom-built Intel
`
`8080 processor based embedded system. I spent one more year at the high school’s
`
`college division, receiving a special Certified Technician’s degree in electrical
`
`engineering. I then went on to serve in the Israeli Defense Forces for three years
`
`(1983–1986). I received my Bachelor of Science degree in computer science
`
`(“CS”) in 1991, my Master’s degree in CS in 1994, and my Ph.D. in CS in 2001—
`
`all from Columbia University in New York.
`
`7.
`
`In 1981, while still in high school studying electrical engineering, I
`
`became the lab manager for a newly established computer lab. During that time, I
`
`
`
`- 2 -
`
`
`
`also worked as a support technician for Commodore Computers in Israel. During
`
`my army service, I was trained and then supported electronic and computerized
`
`subsystems (including HP-IB based measurement equipment and oscilloscopes).
`
`After being honorably discharged, I served as an instructor, teaching computer
`
`programming to K–12 students for one year.
`
`8. When I began my undergraduate studies at Columbia University, I
`
`also started working as a student assistant in the various campus-wide computer
`
`labs, eventually becoming assistant to the lab manager, who was managing all
`
`public computer labs on campus. During that time, I also became more involved
`
`with research within the CS Department at Columbia University, conducting
`
`research on operating systems, file and storage systems, and other topics. I also
`
`assisted
`
`the CS department’s computer administrators
`
`in managing
`
`the
`
`department’s computers, which included storage related duties.
`
`9.
`
`In 1991, I joined Columbia University’s CS department as a full-time
`
`systems administrator, studying towards my MS degree part-time. My MS thesis
`
`topic related to file system reliability, fault tolerance, replication, and failover. My
`
`main duties as a systems administrator involved installing, configuring, and
`
`managing many servers and desktops running several operating systems. My duties
`
`also included ensuring reliable, convenient, high-speed data storage management
`
`and backups using various backup/restore systems and software. I have studied and
`
`
`
`- 3 -
`
`
`
`mastered an assortment of storage devices (e.g., floppy, hard disk, optical
`
`jukeboxes) and protocols (e.g., SCSI, ATA/IDE).
`
`10.
`
`In 1994, I left my systems administrator position to pursue my
`
`doctoral studies at Columbia University. My Ph.D. thesis topic was on versatile file
`
`system development, with examples in the fields of security and encryption,
`
`efficiency, reliability, and failover. I continued to work part-time as a systems
`
`administrator at the CS department, and eventually I was asked to serve as
`
`manager to the entire information technology (“IT”) staff. From 1991 to 2001, I
`
`was a member of the faculty-level Facilities Committee which oversaw all IT
`
`operations at the CS department.
`
`11. From 1990 to 1998, I consulted for SOS Corporation and HydraWEB
`
`Technologies, as a systems administrator and programmer, often managing data
`
`storage use and backup/restore duties. From 1994 to 2000, I led projects at
`
`HydraWEB Technologies, and
`
`then became
`
`the Director of Software
`
`Development—overseeing the development of several products and appliances
`
`such as firewalls and load-balancers. Since 2009, I have consulted for Packet
`
`General Networks, a startup specializing in secure storage and applications’ data
`
`security.
`
`12.
`
`In 2001, I joined the faculty of Stony Brook University, a position I
`
`have held since. In 2002, I joined the Operations Committee, which oversees the
`
`
`
`- 4 -
`
`
`
`IT operations of the CS department at Stony Brook University. From 2006 to 2010,
`
`I was the Director of IT Operations of the CS department; my day-to-day duties
`
`include setting policies regarding computing, hiring and training new staff,
`
`assisting any staff with topics of my specialty, defining requirements for new
`
`software/hardware, and purchasing. From 2010 to 2015, I have served as the Co-
`
`Chair to the Operations Committee. As of 2016, I oversee the IT Operations as the
`
`Chair of the Operations Committee.
`
`13. Since 1995, I have taught courses on operating systems, storage and
`
`file systems, advanced systems programming in Unix/C, systems administration,
`
`data structures, and more. My courses often use storage, file systems, and security
`
`as key teaching principles and practical examples for assignments and projects. I
`
`have taught storage hardware concepts and techniques to my students, both to my
`
`direct advisees as well as in my graduate Storage Systems course.
`
`14. My research often investigates computer systems from many angles:
`
`security, efficiency, energy use, scalability, reliability, portability, survivability,
`
`usability, ease-of-use, versatility, flexibility, and more. My research gives special
`
`attention to balancing five often-conflicting aspects of computer systems:
`
`performance, reliability, energy use, security, and ease-of-use. Since joining Stony
`
`Brook University in 2001, my group in the Filesystems and Storage Lab has
`
`developed many file systems and operating system extensions; examples include a
`
`
`
`- 5 -
`
`
`
`highly-secure cryptographic file system, a portable copy-on-write (COW)
`
`versioning file system, a tracing file system useful to detect intrusions, a replaying
`
`file system useful for forensics, a snapshotting and sandboxing file system, a
`
`namespace unification file system (that uses stackable, file-based COW), an anti-
`
`virus file system, an integrity-checking file system, a load balancing and
`
`replication/mirroring file system, a compiler to convert user-level C code to in-
`
`kernel efficient yet safe code, GCC plugins, stackable file system templates, and a
`
`Web-based backup system. I continue to maintain and release newer versions of
`
`some of these file systems and software to date. Many of the storage and file
`
`systems I’ve developed and published use various forms of virtualization: they
`
`emulate one type of storage or file system while using another internally.
`
`15.
`
`I have published over 110 refereed publications (in ACM, IEEE,
`
`USENIX, and more). To date, my publications had been cited more than 4,700
`
`times (as per Google Scholar). My papers cover a wide range of related
`
`technologies such
`
`file systems, storage systems, security, performance
`
`benchmarking and optimization, energy efficiency, and more. I also published a
`
`book entitled “Linux NFS and Automounter Administration” (Sybex, 2001),
`
`covering systems administration topics related to network storage.
`
`16. Some of my research has led to public software releases that have
`
`been used world-wide. I have publicly maintained the Amd Berkeley Automounter
`
`
`
`- 6 -
`
`
`
`in a package called “am-utils” since 1992; this software helps administrators
`
`manage the multitude of file system mounts on dozens of different Unix systems.
`
`Since 1997, I have maintained and released several stackable file system software
`
`projects for Linux, FreeBSD, and Solaris, in a package called FiST. One of my
`
`stackable file system encryption projects, called Cryptfs, became the basis for
`
`IBM’s public release of eCryptfs, now part of Linux. Another encryption file
`
`system called Ncryptfs was licensed by Packet General Networks, for whom I have
`
`provided consulting services since 2009. Another popular file system released in
`
`2003, called Unionfs, offers namespace unification, transparent shadow copying
`
`(a.k.a., copy-on-write or COW), file system snapshotting, and the ability to save
`
`disk space by sharing a read-only copy of data among several computers, among
`
`other features.
`
`17. My research has been supported by many federal and state grants,
`
`including an NSF CAREER award, two IBM Faculty awards, two NetApp Faculty
`
`awards, a Western Digital award, EMC awards, and several equipment gifts. I was
`
`the winner of the 2004 Computer Science Department bi-annual Graduate
`
`Teaching Award, the winner of the 2006 Computer Science Department bi-annual
`
`Research Excellence Award, and a recipient of the 2008 SUNY Chancellor’s
`
`Excellence in Teaching award (an award that can be given only once a lifetime).
`
`
`
`- 7 -
`
`
`
`18.
`
`I am a named inventor on three patents, two titled “Systems and
`
`Methods for Detection of New Malicious Executables” (U.S. Patent No. 7,979,907,
`
`issued July 12, 2011; and U.S. Patent No. 7,487,544, issued February 3, 2009); and
`
`one titled “Multi-Tier Caching,” (U.S. Patent 9,355,109, issued May 31, 2016).
`
`19.
`
`I have been disclosed as a testifying expert in six cases in the past four
`
`years. I have been deposed four times and testified in trial twice.
`
`20. A complete copy of my curriculum vitae, which includes a list of my
`
`publications, and contains further details on my education, experience,
`
`publications, patents, and other qualifications to render an expert opinion, is
`
`attached as Exhibit 1004.
`
`21. The compensation I receive through my consulting company, Zadoks
`
`Consulting, LLC, is $450 per hour for my time, plus out-of-pocket expenses. This
`
`compensation is not dependent in any way on the contents of this declaration, the
`
`substance of any testimony I may provide, or the outcome of this proceeding.
`
`III. My understanding of claim construction.
`
`22.
`
`I understand that during an inter partes review, claims of an unexpired
`
`patent are to be given their broadest reasonable construction in light of the
`
`specification as would be read by a person of ordinary skill in the relevant art
`
`(“POSITA”).
`
`
`
`- 8 -
`
`
`
`IV. My understanding of obviousness.
`
`23.
`
`I understand that a patent claim is invalid if the claimed invention
`
`would have been obvious to a POSITA at the time the application was filed. This
`
`means that even if all of the requirements of the claim cannot be found in a single
`
`prior art reference that would anticipate the claim, the claim can still be invalid.
`
`24. As part of this inquiry, I have been asked to consider the level of
`
`ordinary skill in the field that someone would have had at the time the claimed
`
`invention was made. In deciding the level of ordinary skill, I considered the
`
`following:
`
`• the levels of education and experience of persons working in the field;
`
`• the types of problems encountered in the field; and
`
`• the sophistication of the technology.
`
`25. To obtain a patent, a claimed invention must have, as of the priority
`
`date, been nonobvious in view of the prior art in the field. I understand that an
`
`invention is obvious when the differences between the subject matter sought to be
`
`patented and the prior art are such that the subject matter as a whole would have
`
`been obvious at the time the invention was made to a POSITA.
`
`26.
`
`I understand that to prove that prior art, or a combination of prior art,
`
`renders a patent obvious, it is necessary to: (1) identify the particular references
`
`that singly, or in combination, make the patent obvious; (2) specifically identify
`
`
`
`- 9 -
`
`
`
`which elements of the patent claim appear in each of the asserted references; and
`
`(3) explain how the prior art references would have been combined in order to
`
`create the inventions claimed in the asserted claim.
`
`27.
`
`I understand that certain objective indicia can be important evidence
`
`regarding whether a patent is obvious or nonobvious. Such indicia include: (1)
`
`commercial success of products covered by the patent claims; (2) a long-felt need
`
`for the invention; (3) failed attempts by others to make the invention; (4) copying
`
`of the invention by others in the field; (5) unexpected results achieved by the
`
`invention as compared to the closest prior art; (6) praise of the invention by the
`
`infringer or others in the field; (7) the taking of licenses under the patent by others;
`
`(8) expressions of surprise by experts and those skilled in the art at the making of
`
`the invention; and (9) the patentee proceeded contrary to the accepted wisdom of
`
`the prior art.
`
`V. Level of ordinary skill in the art.
`I understand that claims must be interpreted by the POSITA at the
`28.
`
`time of invention. For the purpose of this proceeding, I have been informed to
`
`evaluate the level of ordinary skill in the art as of March 4, 1997. Based on the
`
`disclosure of the ’437 patent, a POSITA at the relevant time, would have had at
`
`least a four-year undergraduate degree in electrical engineering, computer science,
`
`computer engineering, or related field of study, or equivalent experience, and at
`
`
`
`- 10 -
`
`
`
`least two years’ experience in studying or developing computer interfaces or
`
`peripherals and storage related software. In my opinion, a POSITA would also be
`
`familiar with operating systems (e.g., MS-DOS, Windows, Unix), their associated
`
`file systems (e.g., FAT, UFS, FFS), device drivers for computer components and
`
`peripherals (e.g., mass storage device drivers), and communication interfaces (e.g.,
`
`SCSI, USB, PCMCIA). This description is approximate, and a higher level of
`
`education or skill might make up for less experience, and vice-versa.
`
`29. Based on my experience I have an understanding of the capabilities of
`
`a POSITA. Furthermore, I possessed those capabilities myself at least as of the
`
`time the patent was filed.
`
`VI. Background of the technologies disclosed in the ’437 patent.
`
`30. The ’437 patent adds minor details to a known approach (hard disk or
`
`mass storage device emulation) to interfacing between a host computer and a data
`
`transmit/receive device. In this section, I provide a background discussion of
`
`aspects of the claimed system, including the purported novelty of the ’437 patent
`
`over the prior art.
`
`A. Device emulation.
`31. The ’437 patent recites that “[t]he interface device according to the
`
`present invention… simulates, both in terms of hardware and software, the way in
`
`
`
`- 11 -
`
`
`
`which a conventional input/output device functions, preferably that of a hard disk
`
`drive.” (’437 patent, 4:16–20 (emphasis added).)
`
`32. The concept of “simulation” as it is described in the ’437 patent—
`
`where one device simulates another device—was also known in the art as
`
`“emulation” as of the filing date of the ’437 patent. For example, U.S. Patent No.
`
`4,727,512 to Birkner et al., filed on December 6, 1984, was known in the art to
`
`utilize a “universal interface device” to emulate magnetic tape drives in the context
`
`of connecting “a computer system having an industry standard magnetic tape drive
`
`interface and peripheral image acquisition processing system.” (Ex. 1009, Birkner,
`
`1:7–12; 1:27–31.) This interface device provides “compatibility between magnetic
`
`tape drives and the peripheral image acquisition processing system” (Birkner, 1:7–
`
`12), by receiving “magnetic tape data and controls signals” at the interface bus of
`
`the interface bus, and “convert[ing] them into digital data and control signals.”
`
`(Birkner, 41–44.) These converted “digital data and control signals are sent to a
`
`data bus [] where they are available for general access” by another computer
`
`system, such as a peripheral image acquisition processing system. (Birkner, 2:44–
`
`51.) Thus, the interface device allows a host computer, such as the peripheral
`
`image acquisition processing system, to use “existing industry standard interfaces”
`
`to access data stored on magnetic tape drives. (Birkner, 1:27–31.)
`
`
`
`- 12 -
`
`
`
`33. However, one of ordinary skill in the art would understand that
`
`emulation was not merely limited to interface devices for magnetic tape drives. For
`
`example, as early as 1983, interface devices such as storage controller emulators
`
`were known in the art for providing “transparent resource sharing” to mass storage
`
`devices such as floppy disk drives. (See Ex. 1010, Maclean, 1:6–11; 3:17–26.) U.S.
`
`Patent No. 4,792,896 to Maclean (“Maclean”), filed on November 29, 1983, for
`
`example, is titled “Storage Controller Emulator Providing Transparent Resource
`
`Sharing in a Computer System.” (See Maclean, Face.) In this patent, storage
`
`controller emulators operate by simulating “the characteristics and responses of a
`
`mass storage device… by processing commands sent by the microprocessor.”
`
`(Maclean, 3:45–49.) One of ordinary skill in the art would have understood that the
`
`practice of emulation solved an important problem in the context of sharing
`
`network resources to a host computer from different devices, such as storage
`
`devices, that are provided by different manufacturers. (See, e.g., Maclean, 1:14–
`
`20.) Different manufacturers may “replac[e] the existing device drivers with their
`
`own” “in order to install their hardware into the computers.” (Maclean, 2:25–30.)
`
`Device drivers translate the protocols of the device so that it may be understood by
`
`the host computer. (See Maclean, 1:57–66.)
`
`34. As one of ordinary skill in the art would have recognized, at least as
`
`early as 1983, this approach—where different devices require different device
`
`
`
`- 13 -
`
`
`
`drivers in order to communicate with the host computer—can cause compatibility
`
`problems. For example, changes to the operating system of the host computer, such
`
`as updates or new releases, may cause the operating system to be incompatible
`
`with the existing devices. (See Maclean, 2:30–34.) Accordingly, manufacturers
`
`would have to update and reinstall new device drivers for their devices (or provide
`
`“patches”) in order to continue communication with the host computer. (See
`
`Maclean, 2:34–40.) There may also be incompatibility caused by original device
`
`drivers provided by the operating system and device drivers provided by the device
`
`manufacturer. (See Maclean, 2:37–40.) Finally, users depended on manufacturers
`
`to provide device drivers for different operating systems before installing new
`
`software or devices on their host computers. (See Maclean, 2:40–42.)
`
`35. Based on these problems associated with device drivers, it was
`
`desirable “to provide the capability of resource and information sharing from a
`
`network system… while at the same time avoiding the problem of the need to
`
`modify the software package for the operating system to run on and accommodate
`
`the network system.” (Maclean, 2:60–65.) In other words, it was desirable to use
`
`the same drivers that were known to the operating system (and the host computer),
`
`rather than requiring different device drivers from each device manufacturer. (See
`
`Maclean, 3:6–14.)
`
`
`
`- 14 -
`
`
`
`36. At least as early as 1983, one of ordinary skill in the art would have
`
`been aware of at least one way to accomplish these goals: emulating a host
`
`computer device so that existing drivers within the operating system may be
`
`utilized. Such emulation may be performed by “exactly simulat[ing] the
`
`characteristics and responses of the normal computer hardware which it replaces.”
`
`(Maclean, 4:49–53.) Examples of host computer devices that may be emulated
`
`include mass storage devices, floppy disks, and printers. (Maclean, 5:24–28; 6:32–
`
`34.) The benefits of this approach were well known to one of ordinary skill in the
`
`art and
`
`included eliminating
`
`the need for device drivers from device
`
`manufacturers, reusing existing device drivers already present in the operating
`
`system, and ensuring communications compatibility between devices and the host
`
`computer across past, existing, and future operating systems. (See Maclean, 3:54–
`
`68.) As another example, when an interface device emulates a floppy disk, “any
`
`that is designed to be used on an IBM PC with disk drives (whether hardware or
`
`software) can still be used [and] [t]herefore, local hard disks are possible as are
`
`RAM disks, communication devices, and even other networks from other
`
`manufacturers.” (Maclean, 7:60–66.)
`
`37. Another example of a universal interface known at the time as of the
`
`filing date of the ’437 patent is plug-and-play (“PnP”). PnP refers to a set of
`
`specifications “that allows a PC to configure itself automatically to work with
`
`
`
`- 15 -
`
`
`
`peripherals such as monitors, modems, and printers.” (Ex. 1014, Microsoft
`
`Computer Dictionary, p. 370.) As explained by the Plug-and-Play SCSI
`
`Specification, Version 1.0, dated March 30, 1994, PnP essentially extend existing
`
`standards, such as Small Computer System Interface (“SCSI”) to enable automated
`
`identification and configuration of peripherals. (Ex. 1031, PnP SCSI, p. 5.)
`
`38. Another example of a universal interface known as of the filing date
`
`of the ’437 patent is universal serial bus (“USB”). USB is designed “for connecting
`
`peripherals to a microcomputer” and “supports hot plugging and multiple data
`
`streams.” (Microsoft Computer Dictionary, p. 487.) Hot plugging is “[a] feature
`
`that allows equipment to be connected to an active device, such as a computer,
`
`while the device is powered on.” (Microsoft Computer Dictionary, p. 237.)
`
`39. There were several different uses for device emulation as I described
`
`above. One such application allows storage devices to appear as if they are local to
`
`the host computer when, in actuality, they are separated from the host computer by
`
`a network. (See Maclean, 7:45–53.) In other words, interface devices that emulated
`
`disk drives essentially “lie” to or trick the host computer into using its known
`
`device drivers to communicate with a wider variety of devices.
`
`40. There is another benefit to avoiding the use of device drivers: they are
`
`simply slower than interface devices for translating commands between the host
`
`computer devices and the host computer. (See Ex. 1011, Jorgensen, p. 5
`
`
`
`- 16 -
`
`
`
`(explaining that software drivers are “relatively slow” compared to hardware-based
`
`solutions for converting “appropriate commands for interfacing with [an] optical
`
`disk drive”).)
`
`41.
`
`In the prosecution history of the ’437 patent, the applicant argued that
`
`“all the claims require the processor of the ADGPD to automatically send an
`
`identifying parameter which misrepresents what the ADGPD is to the host
`
`computer in a host computer automatic recognition process.” (Ex. 1002, p. 702
`
`(Reply Brief, September 25, 2012) (emphasis added).) From the above discussion,
`
`it is readily apparent that such “misrepresentation”—emulation in technical
`
`terms—is not a novel feature of the ’437 patent.
`
`B. Hard disk interface technologies.
`In this section, I provide a background discussion of hard disk drive
`42.
`
`technologies as of the filing date of the ’437 patent. The ’437 patent recites
`
`causing:
`
`at least one parameter identifying the analog data generating
`and processing device, independent of analog data source, as a
`digital storage device instead of as an analog data generating
`and processing device to be automatically sent through the i/o
`port and to the multi-purpose interface of the computer.
`
`(’437 patent, 12:64 to 13:5 (emphasis added).)
`
`
`
`
`- 17 -
`
`
`
`43. The “identifying” clause of the claim implies device emulation
`
`discussed above in the previous section. The remainder of the quoted portion
`
`(“which signals…”) describes the concept of identifying devices, such as hard disk
`
`drives, within a computer.
`
`44.
`
`It was well known at the time prior to the earliest priority date of the
`
`’437 patent that when a host computer detects that a device has been connected to
`
`it, the host inquires as to what type of device it is and