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 6,470,399
`
`
`
`
`
`
`
`Apple 1003
`IPR2016-01843
`U.S. Pat. 6,470,399
`
`

`
`TABLE OF CONTENTS
`Introduction ...................................................................................................... 1
`I.
`II. Qualifications ................................................................................................... 3
`III. My Understanding of Claim Construction ...................................................... 9
`IV. My Understanding of Obviousness ................................................................. 9
`V.
`Level of Ordinary Skill in the Art .................................................................11
`VI. The ’399 Patent ..............................................................................................12
`A. Overview ........................................................................................................12
`B. Claims 1, 11, and 14 ......................................................................................16
`C. Claims 3 and 5 ...............................................................................................16
`VII. Background of the Technologies Disclosed in the ’399 Patent ....................16
`A. Device Emulation ..........................................................................................17
`B. Hard Disk Interface Technologies .................................................................22
`C. Operating Systems and File Systems ............................................................27
`VIII. Claim Construction ........................................................................................31
`IX. Ground 1: The Combination of Ard, Schmidt, and Webb Renders Claims 1,
`3, 5, 11, and 14 Obvious ................................................................................32
`A. Overview of Ard ............................................................................................32
`B. Overview of Schmidt .....................................................................................34
`C. Overview of Webb .........................................................................................35
`D. The Combination of Ard, Schmidt, and Webb Renders Claims 1, 11, and 14
`Obvious ..........................................................................................................36
`1. The Combination of Ard, Schmidt, and Webb Discloses the Preamble of
`Independent Claims 1, 11, and 14 .............................................................36
`a) The Combination of Ard, Schmidt, and Webb Discloses an Interface
`Device and a Method “for communication between a host device, … and
`a data transmit/receive device” ...............................................................38
`b) The Combination of Ard, Schmidt, and Webb Discloses the Host Device
`Limitations of the Preamble ....................................................................40
`c) The Combination of Ard, Schmidt, and Webb Discloses the Data
`Transmit/Receive Device Limitations of the Preamble ..........................42
`
`
`
`
`- ii -
`
`

`
`2. The Combination of Ard, Schmidt, and Webb Discloses the Architectural
`Elements of the Interface Device ...............................................................44
`a) The Combination of Ard, Schmidt, and Webb Discloses the Interface
`Devices comprises “a processor” and “a memory” ................................45
`b) The Combination of Ard, Schmidt, and Webb Discloses the “first
`connecting device” Limitations ...............................................................47
`c) The Combination of Ard, Schmidt, and Webb Teaches the “second
`connecting device” Limitations Including the Sample-and-Hold Circuit
`and Analog-to-Digital Converter ............................................................49
`3. The Combination of Ard, Schmidt, and Webb Discloses the Recognition
`Limitations of the Independent Claims .....................................................54
`a) The Combination of Ard, Schmidt, and Webb Discloses the Command
`Interpreter, and the Inquiry and Response Elements of the Recognition
`Limitations of Claims 1, 11, and 14 ........................................................56
`b) The Combination of Ard, Schmidt, and Webb Teaches “whereupon the
`host device communicates with the interface device by means of the
`[driver]” ...................................................................................................63
`4. The Combination of Ard, Schmidt, and Webb Discloses the Transfer
`Limitations of the Independent Claims .....................................................66
`E. The Combination of Ard, Schmidt, and Webb Renders Claim 3 Obvious ...73
`X. Ground 2: The Combination of Ard, Schmidt, and Johnson Renders Claim 5
`Obvious ..........................................................................................................74
`A. Overview of Johnson .....................................................................................74
`B. The Combination of Ard, Schmidt, and Johnson Discloses that “the
`processor is a digital signal processor” as Recited in Claim 5 ....................75
`XI. Adequacy of the German Priority Application ..............................................77
`XII. Conclusion .....................................................................................................79
`
`
`
`
`- 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. 6,470,399 (“the ’399 patent”)
`
`titled “Flexible Interface for
`
`Communication Between a Host and an Analog I/O Device Connected to the
`
`Interface Regardless the Type of the I/O Device” by Michael Tasler, and that the
`
`’399 patent is currently assigned to Papst Licensing GmbH & Co. KG.
`
`2.
`
`
`In preparing this declaration, I have reviewed and am familiar with the
`
`following references:
`
`• U.S. Patent No. 5,915,106 to Ard (“Ard”), titled “Method and System
`
`for Operating a Scanner Which Emulates a Disk Drive,” provided as Ex. 1046 is
`
`prior art under at least 35 U.S.C. §§102(e) because it was filed on March 20, 1997,
`
`before the March 3, 1998 priority date of the ’399 patent.
`
`• The SCSI Bus and IDE Interface—Protocols, Applications and
`
`Programming by Friedhelm Schmidt (“Schmidt”), and published in 1995. I
`
`understand that Schmidt is prior art to the ’399 patent and has been provided as Ex.
`
`1007. (See Ex. 1024.)
`
`• U.S. Patent No. 5,489,772 to Webb et al. (“Webb”), titled “Variable
`
`Optical Sampling Rate Dependent on Requested Scan Resolution” (Ex. 1048), is
`
`
`
`
`- 1 -
`
`

`
`prior art under at least 35 U.S.C. §§ 102(a), 102(b), and 102(e) because it was filed
`
`on November 14, 1994, and issued February 6, 1996, more than one year before the
`
`March 3, 1998 priority date of the ’399 patent.
`
`• U.S. Patent No. 5,303,064 to Johnson et al. (“Johnson”), titled “Image
`
`Scanner with Calibration Mechanism to Obtain Full Dynamic Range and
`
`Compensated Linear Output,” provided as Ex. 1047, is prior art under at least 35
`
`U.S.C. §§102(a), 102(b), and 102(e) because it was filed on February 20, 1991, and
`
`issued April 12, 1994, more than one year before the March 3, 1998 priority date of
`
`the ’399 patent.
`
`3.
`
`
`4.
`
`
`I have also considered all other materials cited herein.
`
`The ’399 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, ’399 patent, 5:6–
`
`9.) I am familiar with the technology described in the ’399 patent as of its March 3,
`
`1998 filing date and its claimed March 4, 1997 priority date.
`
`5.
`
`
`I have been asked to provide my independent technical review,
`
`analysis, insights, and opinions regarding the ’399 patent and the references that
`
`form the basis for the two grounds of rejection set forth in the Petition for Inter
`
`Partes Review of the ’399 patent.
`
`
`
`
`- 2 -
`
`

`
`II. Qualifications
`As indicated in my curriculum vitae, attached as Ex. 1004, I am a
`6.
`
`
`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.
`
`7.
`
`
`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.
`
`8.
`
`
`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
`
`
`
`
`- 3 -
`
`

`
`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.
`
`
`
` When I began my undergraduate studies at Columbia University, I 9.
`
`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.
`
`10.
`
`
`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
`
`
`
`
`- 4 -
`
`

`
`mastered an assortment of storage devices (e.g., floppy, hard disk, optical
`
`jukeboxes) and protocols (e.g., SCSI, ATA/IDE).
`
`11.
`
`
`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.
`
`
`
` From 1990 to 1998, I consulted for SOS Corporation and HydraWEB 12.
`
`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.
`
`13.
`
`
`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
`
`
`
`
`- 5 -
`
`

`
`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 and my day-to-day duties
`
`included 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 served as the Co-Chair to
`
`the Operations Committee. As of 2016, I oversee the IT Operations as the Chair of
`
`the Operations Committee.
`
`
`
` Since 1995, I have taught courses on operating systems, storage and 14.
`
`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.
`
`
`
` My research often investigates computer systems from many angles: 15.
`
`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
`
`
`
`
`- 6 -
`
`

`
`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.
`
`16.
`
`
`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.
`
`
`
` Some of my research has led to public software releases that have 17.
`
`been used world-wide. I have publicly maintained the Amd Berkeley Automounter
`
`
`
`
`- 7 -
`
`

`
`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.
`
`
`
` My research has been supported by many federal and state grants, 18.
`
`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).
`
`19.
`
`
`I am a named inventor on three patents, two titled “Systems and
`
`
`
`
`- 8 -
`
`

`
`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).
`
`20.
`
`
`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.
`
`
`
` A complete copy of my curriculum vitae, which includes a list of my 21.
`
`publications, and contains further details on my education, experience,
`
`publications, patents, and other qualifications to render an expert opinion, is
`
`attached as Ex. 1004.
`
`
`
` The compensation I receive through my consulting company, Zadoks 22.
`
`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
`23.
`
`
`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.
`
`IV. My Understanding of Obviousness
`I understand that a patent claim is invalid if the claimed invention
`24.
`
`
`would have been obvious to a person of ordinary skill in the field at the time the
`
`
`
`
`- 9 -
`
`

`
`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.
`
`
`
` As part of this inquiry, I have been asked to consider the level of 25.
`
`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.
`
`
`
` To obtain a patent, a claimed invention must have, as of the priority 26.
`
`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 person having ordinary skill
`
`in the art.
`
`27.
`
`
`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
`
`which elements of the patent claim appear in each of the asserted references; and
`
`
`
`
`- 10 -
`
`

`
`(3) explain how the prior art references could have been combined in order to
`
`create the inventions claimed in the asserted claim.
`
`28.
`
`
`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 the person of ordinary skill in the art is viewed at the
`29.
`
`
`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 ’399 patent, one of ordinary skill in the art would be a person of
`
`ordinary skill in the field, 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 least two
`
`
`
`
`- 11 -
`
`

`
`years’ experience in studying or developing computer interfaces or peripherals and
`
`storage related software. In my opinion, a person of ordinary skill 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.
`
`
`
` Based on my experience I have an understanding of the capabilities of 30.
`
`a person of ordinary skill in the relevant field. Furthermore, I possessed those
`
`capabilities myself at least as of the time the patent was filed.
`
`VI. The ’399 Patent
`A. Overview
` The ’399 patent discloses “[a]n interface device [that] provides fast 31.
`
`
`data communication between a host device with input/output interfaces and a data
`
`transmit/receive device.” (’399 patent, Abstract.) Figure 1, reproduced below,
`
`illustrates the basic block diagram of the interface device.
`
`
`
`
`- 12 -
`
`

`
`
`
`
` The interface device 10 includes “[a] first connecting device 12… 32.
`
`attached to a host device (not shown) via a host line 11.” (’399 patent, 5:48–50.)
`
`The ’399 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.” (’399 patent, 5:50–56.) 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.” (’399 patent, 5:56–60.) 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 computer or host device and a data transmit/receive
`- 13 -
`
`
`
`
`

`
`device from which data is to be acquired.” (’399 patent, 1:10–13.)
`
`
`
` The ’399 patent discloses embodiments to make “the interface device 33.
`
`appear[] to the host device as a hard disk.” (’399 patent, 6:58–59.) The ’399 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.”
`
`(’399 patent, 6:3–10.) 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.” (’399
`
`patent, 6:14–16.) This response is handled by a “first command interpreter.” (’399
`
`patent, 6:52–53.) 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.” (’399 patent, 6:16–19.) 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); see also ’399 patent,
`
`4:40–44.) Aside from the use of these conventional commands, the ’399 patent
`
`does not provide any other description for making “the interface device appear[] to
`
`the host device as a hard disk.” (’399 patent, 6:58–59.)
`
`
`
` During operation, the interface device “simulates a hard disk with a 34.
`
`
`
`
`- 14 -
`
`

`
`root directory whose entries are ‘virtual’ files which can be created for the most
`
`varied functions.” (’399 patent, 6:1–3.) 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.” (’399 patent, 6:55–58.) 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.” (’399 patent, 6:64–67.) 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. (’399 patent, 7:5–7;
`
`see also 7:1–5.)
`
`
`
` The ’399 patent does not provide any further written description of the 35.
`
`structure of the first and second command interpreters, which are mentioned in
`
`only a single paragraph of the written description. (See ’399 patent, 6:48–67.) In
`
`the “preferred embodiment,” the first and second command interpreters are simply
`
`software modules that respond to an inquiry and a read command, respectively.
`
`(’399 patent, 6:48–52.) For example, the ’399 patent states that “the digital signal
`
`processor 13, which… may be any other kind of microprocessor, comprises a first
`
`and a second command interpreter.” (’399 patent, 6:48–52.) The first command
`
`interpreter receives and responds to an inquiry from the host device as to the
`
`device type of the interface device. (See ’399 patent, 12:64 to 13:8.) The second
`
`
`
`
`- 15 -
`
`

`
`command interpreter “interprets the read command of the host processor as a data
`
`transfer command.” (’399 patent, 6:59–67.) Interpreting and responding to such
`
`commands was mandatory for any SCSI device, as would have been known by a
`
`person of ordinary skill in the art and as discussed further below. (See, e.g., SCSI
`
`Specification, p. 7 (“The model [for the device type] establishes the framework for
`
`interpreting the commands for the device type.”).)
`
`B. Claims 1, 11, and 14
` The independent claims at issue in this proceeding are claims 1, 11, 36.
`
`
`and 14. Claims 1 and 11 are directed to “[a]n interface device” and are nearly
`
`identical in scope. Claim 14 recites “[a] method of communication between a host
`
`device… and a data transmit/receive device” and largely overlaps with the
`
`functionality provided by the interface devices recited in claims 1 and 11.
`
`Accordingly, I analyze claims 1, 11, and 14 together. I will point out where the
`
`claims overlap and where they differ.
`
`C. Claims 3 and 5
` Claims 3 and 5 depend from independent claim 1. Claim 3 specifies 37.
`
`
`that the memory in claim 1 is a buffer for data transferred between the
`
`transmit/receive device and the host, and claim 5 specifies that the processor is a
`
`digital signal processor.
`
`VII. Background of the Technologies Disclosed in the ’399 Patent
` The ’399 patent adds minor details to a known approach (hard disk or 38.
`
`- 16 -
`
`
`
`
`

`
`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 ’399 patent
`
`over the prior art.
`
`A. Device Emulation
` The ’399 patent recites that “[t]he interface device according to the 39.
`
`
`present invention… 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.” (’399 patent, 4:16–20 (emphasis added).)
`
`
`
` The concept of “simulation” as it is described in the ’399 patent—40.
`
`where one device simulates another device—was also known in the art as
`
`“emulation” at least at the time of the earliest possible priority date of the ’399
`
`patent. For example, U.S. Patent No. 4,727,512 to Birkner et al., filed on Dec. 6,
`
`1984, illustrates that it 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,
`
`
`
`
`- 17 -
`
`

`
`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.)
`
`
`
` However, one of ordinary skill in the art would understand that 41.
`
`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 Nov. 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
`
`
`
`
`- 18 -
`
`

`
`devices, that are provided by different manufacturers. (See, 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.)
`
`
`
` As one of ordinary skill would have recognized, at least as early as 42.
`
`1983, that this approach—where different devices require different device 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 e