`
`
`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 8,504,746
`
`
`
`
`
`
`
`
`
`
`
`
`
`Apple 1003
`IPR2016-01862
`U.S. Pat. 8,504,746
`
`

`

`
`I.
`II.
`III.
`IV.
`V.
`VI.
`VII.
`
`VIII.
`IX.
`
`Table of Contents
`
`Introduction. ................................................................................................. 1
`Qualifications. .............................................................................................. 2
`My understanding of claim construction. .................................................... 8
`My understanding of obviousness. .............................................................. 9
`Level of ordinary skill in the art. ............................................................... 10
`Overview of the ’746 Patent ...................................................................... 11
`Background of the technologies disclosed in the ’746 patent. .................. 14
`A. Device emulation. .......................................................................................14
`B. Hard disk interface technologies. ...............................................................20
`C. Operating systems and file systems. ..........................................................26
`Claim construction. .................................................................................... 30
`Ground 1: The combination of Ard, Schmidt, and Webb renders claims 1,
`6, 7, 8, 14, 20, 21, 30, and 34 obvious. ...................................................... 31
`A. Overview of Ard .........................................................................................31
`B. Overview of Schmidt .................................................................................33
`C. Overview of Webb .....................................................................................34
`D. The combination renders claim 1 obvious. ................................................35
`1. The combination discloses the “analog data acquisition device”
`recited in the preamble of claim 1 [1P]. ..............................................35
`a) “analog data acquisition device” ..................................................36
`b) computer architecture/operation component ................................37
`2. The combination discloses the analog data acquisition device
`architectural limitations. ......................................................................42
`a) “a program memory” [1A] ............................................................42
`b) “an analog signal acquisition channel for receiving a signal from
`an analog source” [1B] .................................................................43
`the “processor” limitation [1C] ....................................................45
`c)
`3. The combination discloses the “data generation process” of claim
`element [1D]. .......................................................................................50
`a) “data generation process” [1D.1] ..................................................51
`
`
`
`
`- ii -
`
`

`

`b) “analog data is processed and digitized” [1D.2] ...........................51
`c) “file system” [1D.3] ......................................................................52
`4. The combination discloses claim limitation [1E]. ..............................53
`a) “parameter indicative of the class of devices” [1E.2] ..................53
`b) “the processor executes at least one instruction set” [1E.1] .........56
`c) “not within the class of devices” [1E.3]. ......................................58
`5. The combination discloses claim element [1F]. ..................................58
`a) file transfer process [1F.2] ............................................................59
`b) “at least one other instruction set” [1F.1]. ....................................60
`c) appearance of the device as part of the class of devices [1F.3] ....61
`6. The combination discloses claim limitation [1G]. ..............................61
`E. The combination renders claim 6 obvious. ................................................66
`F. The combination renders claim 7 obvious. ................................................67
`G. The combination renders claim 8 obvious. ................................................68
`H. The combination renders claim 14 obvious. ..............................................69
`I. The combination renders claim 20 obvious. ..............................................70
`J. The combination renders claim 21 obvious. ..............................................74
`K. The combination renders claim 30 obvious. ..............................................75
`L. The combination renders claim 34 obvious. ..............................................77
`1. The combination discloses “[a] method for analog data acquisition
`and interfacing to a host device wherein the host device includes a
`device driver” as recited in the preamble of claim 34 [34P]. ..............77
`2. The combination discloses the “interfacing” step of claim 34 [34A]. 78
`3. The combination discloses the “acquiring” step of claim 34 [34B]. ..79
`4. The combination discloses the “sending” step of claim 34 [34C]. .....80
`5. The combination discloses the “transferring” step of claim 34 [34D].
` .............................................................................................................81
`Ground 2: The combination of Ard, Schmidt, and Araghi renders claims 4
`and 11 obvious. .......................................................................................... 83
`A. The combination renders claim 4 obvious. ................................................83
`B. The combination renders claim 11 obvious. ..............................................84
`
`- iii -
`
`X.
`
`
`
`
`

`

`XI.
`
`Ground 3: The combination of Ard, Schmidt, Webb, and Steinle renders
`claims 10 and 35 obvious. ......................................................................... 87
`A. The combination renders claim 10 obvious. ..............................................87
`B. The combination renders claim 35 obvious. ..............................................90
`XII.
`Ground 4: The combination of Ard, Schmidt, Webb, and Reisch renders
`claim 23 obvious. ....................................................................................... 91
`XIII. Adequacy of the German priority application. .......................................... 96
`XIV. Conclusion. .............................................................................................. 102
`
`
`
`
`
`
`
`
`
`- iv -
`
`

`

`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. 8,504,746 (“the ’746 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
`
`’746 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 ’746 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.” (’746 patent, 4:14–17.) I am
`
`familiar with the technology described in the ’746 patent as of its September 27,
`
`2010 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 ’746 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 ’746 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 File systems and Storage Lab (FSL) 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 have 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.
`I understand that during an inter partes review, claims of an unexpired
`22.
`
`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.
`I understand that a patent claim is invalid if the claimed invention
`23.
`
`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) whether 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 ’746 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 of 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. Overview of the ’746 Patent
`
`30. The ’746 patent discloses “[a]n interface device [that] provides fast
`
`data communication between a host device with input/output interfaces and a data
`
`transmit/receive device.” (’746 patent, Abstract.) Figure 1, reproduced below,
`
`illustrates the basic block diagram of the interface device.
`
`
`
`- 11 -
`
`

`

`
`The interface device 10 includes “[a] first connecting device 12… attached to a
`
`host device (not shown) via a host line 11.” (’746 patent, 4:60–62.) The ’746 patent
`
`states that “[t]he first connecting device is attached to a digital signal processor 13
`
`and to a memory means 14,” which in turn are “attached to a second connecting
`
`device.” (’746 patent, 4:62–67.) In some embodiments, the second connecting
`
`device is “attached by means of an output line 16 to a data transmit/receive
`
`device… from which data is to be read, i.e. acquired, and transferred to the host
`
`device.” (’746 patent, 4:67 to 5:4.) The “Field of Invention” section summarizes in
`
`the above disclosures by describing that “the present invention relates to the
`
`transfer of data and in particular to interface devices for communication between a
`
`
`
`- 12 -
`
`

`

`computer or host device and a data transmit/receive device from which data is to
`
`be acquired.” (’746 patent, 1:20–24.)
`
`31. The ’746 patent discloses embodiments to make “the interface device
`
`appear[] to the host device as a hard disk.” (’746 patent, 6:2–3.) The ’746 patent
`
`recites that “[w]hen the host device… is booted…, usual BIOS routines or multi-
`
`purpose interface programs issue an instruction, known by those skilled in the art
`
`as the INQUIRY instruction, to the input/output interfaces in the host device.”
`
`(’746 patent, 5:14–20.) The interface device receives the signal and responds with
`
`a signal that “indicates to the host device that, for example, a hard disk drive is
`
`attached at the interface to which the INQUIRY instruction was sent.” (’746
`
`patent, 5:21–27.) This response is handled by a “first command interpreter.” (’746
`
`patent, 5:63–64.) The host can, in addition, “can send an instruction, known by
`
`those skilled in the art as ‘Test Unit Ready’, to the interface device to require more
`
`precise details.” (’746 patent, 5:27–30.) Both the INQUIRY and Test Unit Ready
`
`commands were well known as part of the small computer system interface (SCSI)
`
`which was widely popular at the time of invention. (Schmidt, p. 165 (describing
`
`conventional read and write commands for hard disk drives).) Aside from the use
`
`of these conventional commands, the ’746 patent does not provide any other
`
`description for making “the interface device appear[] to the host device as a hard
`
`disk.” (’746 patent, 6:2–3.)
`
`
`
`- 13 -
`
`

`

`32. During operation, the interface device “simulates a hard disk with a
`
`root directory whose entries are ‘virtual’ files which can be created for the most
`
`varied functions.” (’746 patent, 5:11–14.) When a user “wishes to read data from
`
`the data transmit/receive device via the line 16, the host device sends a command,
`
`for example ‘read file xy’, to the interface device.” (’746 patent, 5:66 to 6:2.) The
`
`second command interpreter then “begins to transfer data from the data
`
`transmit/receive device via the second connecting device to the first connecting
`
`device and via the line 11 to the host device.” (’746 patent, 6:3–10.) This operation
`
`emulates a “‘real-time input’ file [that] appears as a file whose length corresponds
`
`to the anticipated volume of data” contained in a configuration file. (’746 patent,
`
`6:15–17; see also 6:11–15.)
`
`VII. Background of the technologies disclosed in the ’746 patent.
`33. The ’746 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 ’746 patent
`
`over the prior art.
`
`A. Device emulation.
`34. The ’746 patent recites that “[t]he interface device according to the
`
`present invention… simulates, both in terms of hardware and software, the way in
`
`
`
`- 14 -
`
`

`

`which a conventional input/output device functions, preferably that of a hard disk
`
`drive.” (’746 patent, 4:14–17 (emphasis added).)
`
`35. The concept of “simulation” as it is described in the ’746 patent—
`
`where one device simulates another device—was also known in the art as
`
`“emulation” prior to the earliest effective priority date of the ’746 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.)
`
`
`
`- 15 -
`
`

`

`36. 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.)
`
`37. 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
`
`
`
`- 16 -
`
`

`

`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.)
`
`38. 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.)
`
`
`
`- 17 -
`
`

`

`39. 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.)
`
`40. Another example of a universal interface known at the time of the
`
`earliest effective priority date of the ’746 patent is plug-and-play ("PnP"). P