UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________________
`
`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
`IPR2016-01842
`U.S. Pat. 9,189,437
`
`
`
`
`
`
`

`
`TABLE OF CONTENTS
`
`
`Introduction. ................................................................................................ - 1 -
`I.
`II. Qualifications. ............................................................................................. - 2 -
`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. ................................................................................... - 26 -
`VIII. Ground 1: The combination of Pucci, Kepley, and Schmidt renders claims 1,
`4–6, 9–12, 14, 15, 30, and 34 obvious. ..................................................... - 27 -
`A. The combination of Pucci, Kepley, and Schmidt renders claim 1
`obvious. ............................................................................................. - 28 -
`1. An analog data generating and processing device (ADGPD),
`comprising [1P]: ......................................................................... - 28 -
`2. The combination of Pucci, Kepley, and Schmidt discloses the
`ADGPD architecture elements. .................................................. - 30 -
`a) an input/output (i/o) port; ..................................................... - 31 -
`b) a program memory [1B]; ..................................................... - 32 -
`c) a data storage memory [1C]; ................................................ - 32 -
`d) a processor operatively interfaced with the I/O port, the
`program memory and the data storage memory [1D]; ......... - 33 -
`3. The combination of Pucci, Kepley, and Schmidt teaches the
`acquisition and processing limitations of independent claim 1. - 36 -
`a) Pucci teaches the acquisition limitation [1E.1]. ................... - 36 -
`b) The combination of Pucci and Kepley teaches the data
`processing limitation [1E.2]. ................................................ - 47 -
`4. The combination of Pucci, Kepley, and Schmidt teaches the
`automatic recognition limitation of independent claim 1. ......... - 51 -
`
`
`
`- i -
`
`
`
`

`
`a) The combination of Pucci, Kepley, and Schmidt discloses the
`claimed automatic recognition operation [1F.1]. ................. - 52 -
`b) The combination of Pucci, Kepley, and Schmidt teaches the end
`user requirements. ................................................................ - 62 -
`c) The combination of Pucci, Kepley, and Schmidt teaches the
`automatic recognition data element requirements. .............. - 67 -
`5. The combination of Pucci, Kepley, and Schmidt teaches the file
`transfer limitation of independent claim 1. ................................ - 70 -
`a) The combination of Pucci, Kepley, and Schmidt teaches the
`recited automatic file transfer process. ................................ - 71 -
`b) The combination of Pucci, Kepley, and Schmidt discloses the
`emulation and user requirement component of the file transfer
`limitation. ............................................................................. - 77 -
`B. The combination of Pucci, Kepley, and Schmidt renders claim 4
`obvious. ............................................................................................. - 78 -
`C. The combination of Pucci, Kepley, and Schmidt renders claim 5
`obvious .............................................................................................. - 80 -
`D. The combination of Pucci, Kepley, and Schmidt renders claim 6
`obvious. ............................................................................................. - 81 -
`E. The combination of Pucci, Kepley, and Schmidt renders claim 9
`obvious. ............................................................................................. - 81 -
`F. The combination of Pucci, Kepley, and Schmidt renders claim 10
`obvious. ............................................................................................. - 84 -
`G. The combination of Pucci, Kepley, and Schmidt renders claim 11
`obvious. ............................................................................................. - 84 -
`H. The combination of Pucci, Kepley, and Schmidt renders claim 12
`obvious. ............................................................................................. - 87 -
`I. The combination of Pucci, Kepley, and Schmidt renders claim 14
`obvious. ............................................................................................. - 89 -
`J. The combination of Pucci, Kepley, and Schmidt renders claim 15
`obvious. ............................................................................................. - 90 -
`K. The combination of Pucci, Kepley, and Schmidt renders claim 30
`obvious. ............................................................................................. - 91 -
`L. The combination of Pucci, Kepley, and Schmidt renders claim 34
`obvious. ............................................................................................. - 93 -
`- ii -
`
`
`
`
`
`

`
`IX. Ground 2: The combination of Pucci, Kepley, Schmidt, and Shinosky
`renders claim 16 obvious. ......................................................................... - 94 -
`X. Ground 3: The combination of Pucci, Kepley, Schmidt, and Campbell
`renders claims 13 and 18 obvious. ........................................................... - 98 -
`A. The combination of Pucci, Kepley, Schmidt and Campbell renders
`claim 13 obvious. .............................................................................. - 99 -
`B. The combination of Pucci, Kepley, Schmidt, and Campbell renders
`claim 18 obvious ............................................................................. - 103 -
`XI. Ground 4: The combination of Pucci, Kepley, Schmidt, and Wilson renders
`claim 32 obvious. .................................................................................... - 103 -
`XII. Ground 5: The combination of Pucci and Schmidt renders claim 43 obvious.
`
`- 105 -
`A. An analog data generating and processing method for acquiring analog
`data and for communicating with a host computer comprising [43P]: ... -
`105 -
`B. The combination of Pucci and Schmidt discloses the architecture
`elements of claim 43. ...................................................................... - 106 -
`1. The combination of Pucci, Kepley, and Schmidt teaches the
`acquisition and processing limitations [43B]. .......................... - 109 -
`a) Pucci teaches the acquisition limitation of independent claim
`43. ....................................................................................... - 109 -
`b) The combination of Pucci and Schmidt teaches the processing
`limitation of independent claim 43. ................................... - 109 -
`2. The combination of Pucci and Schmidt teaches the automatic
`recognition limitation of independent claim 43. ...................... - 111 -
`3. The combination of Pucci and Schmidt teaches the transferring
`limitation of independent claim 43. .......................................... - 115 -
`4. The combination of Pucci and Schmidt teaches “wherein the
`identification parameter is consistent with the ADGPD being
`responsive to commands issued from a customary device driver.” .. -
`117 -
`XIII. Ground 6: The combination of Pucci, Schmidt, and Campbell renders claim
`45 obvious. .............................................................................................. - 118 -
`XIV. Adequacy of the German Priority Application ....................................... - 118 -
`XV. Conclusion. ............................................................................................. - 122 -
`
`- iii -
`
`
`
`

`
`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 six 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 Ex. 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 have 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 Ex. 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 could 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” prior to the earliest possible priority 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 of the
`
`earliest possible priority 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
`
`- 15 -
`
`

`
`to work with 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. 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.
`
`39. 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
`
`(explaining that software drivers are “relatively slow” compared to hardware-based
`
`solutions for converting “appropriate commands for interfacing with [an] optical
`
`disk drive”).)
`
`40.
`
`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
`
`- 16 -
`
`

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