`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`Canon Inc. et al.,
`
`Petitioners
`
`v.
`
`Papst Licensing GmbH & Co., KG,
`
`Patent Owner
`
`
`
`
`
`
`
`CASE: Unassigned
`Patent No. 8,504,746
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`DECLARATION OF DR. PAUL F. REYNOLDS, Ph.D.
`IN SUPPORT OF
`PETITION FOR INTER PARTES REVIEW
`
`
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 1/98
`
`
`
`I, Dr. Paul F. Reynolds, Ph.D., declare as follows:
`
`
`I.
`
`BACKGROUND AND QUALIFICATIONS
`
`1.
`
`From 1980 until August 2012, I was a Professor of Computer Science
`
`at the University of Virginia’s School of Engineering and Applied Science.
`
`2.
`
`I have also served, and in some cases continue to serve, as an expert
`
`consultant on distributed system matters for MITRE, Aerospace Corporation, the
`
`Institute for Defense Analyses, Vanguard Research and currently for the U.S.
`
`Army National Ground Intelligence Center.
`
`3.
`
`I have a Bachelor of Arts degree in Psychology from Ohio Northern
`
`University that I obtained in 1970, a Master’s of Science in Computer Science
`
`from the University of Texas at Austin, obtained in 1975, and a Doctor of
`
`Philosophy in Computer Science from the University of Texas at Austin, obtained
`
`in 1979. Both my Masters and Ph.D. focused on parallel and distributed systems
`
`and networking topics.
`
`4.
`
`During my time as a Professor, I was awarded over 60 grants, and
`
`conducted research sponsored by DARPA, the National Science Foundation,
`
`DUSA (OR), the National Institute for Science and Technology, the Defense
`
`Modeling and Simulation Office, Virginia Center for Innovative Technology and
`
`numerous industries.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 2/98
`
`
`
`5.
`
`I taught many Ph.D. level classes on topics relating to distributed
`
`computing and high performance networking. I have advised, to completion, 65
`
`graduate degrees. The majority of my students, including my 16 Ph.D. students,
`
`conducted research in distributed computing and networking. I published on many
`
`of these topics.
`
`6.
`
`Since the mid-1970s, almost half of my research has been in the field
`
`of parallel and distributed systems and networking.
`
`7.
`
`In particular, much of my research in the 1980’s and 1990’s was
`
`focused on efficient time management of distributed simulations. I published
`
`widely on the topic, and was actively involved in the deployment of related
`
`technologies within the Department of Defense (DoD) modeling and simulation
`
`communities.
`
`8.
`
`Specifically, I was one of the originators of the DoD High Level
`
`Architecture for distributed simulations (IEEE standard 1516). I was also an
`
`organizer and overseer for the DoD Joint National Test Facility (having a focus on
`
`distributed simulation) in Colorado Springs.
`
`9.
`
`Because of my experience, I was selected to be the program chair for
`
`the IEEE Parallel and Distributed Simulation Conference on two different
`
`occasions.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 3/98
`
`
`
`10.
`
`I am also the co-architect of Isotach Networks, a system which
`
`guarantees message delivery order in distributed systems without employing real
`
`time clocks and supports very efficient management of consistency in concurrent
`
`caches. Isotach Networks was supported by both the National Science Foundation
`
`and the Defense Advanced Research Projects Agency and became subject material
`
`in four of the Ph.D. dissertations I supervised.
`
`11.
`
`Below is a partial list of my publications:
`
` Spiegel, M., Reynolds, P.F., "Lock-Free Multiway Search Trees,"
`ACM/IEEE International Conference on Parallel Processing, Sept., 2010.
`
` Highley, T.J., Reynolds, P.F., and Vellanki, V. “Marginal Cost-Benefit
`Analysis for Predictive File Prefetching,” ACM Southeast Conference,
`March, 2003
`
` Srinivasa, R., Reynolds, P.F., and Williams, C., “A New Look at Time-
`Stamp Ordering Concurrency Control,” 12th International Conference on
`Database and Expert Systems Applications - DEXA 2001, Sept., 2001.
`
` Williams, C., Reynolds, P.F., and de Supinski, B.R. “Delta Coherence
`Protocols,” IEEE Concurrency, Spring, 2000.
`
` Srinivasa, R., Reynolds, P.F., and Williams, C. “IsoRule: Parallel Execution
`of Rule-based Systems,” 1999 Int’l Conference on Parallel Processing, June
`1999.
`
` Srinivasan S., and Reynolds, P.F. “Elastic Time,” ACM Trans on Modeling
`and Computer Simulation, 1998.
`
` Srinivasan, S., Lyell, M., Wehrwein, J., Reynolds, P.F., “Fast Reductions on
`a Network of Workstations,” 1997 International Conference on High
`Performance Computing (HiPC97), Bangalore, India, Dec., 1997.
`
` Williams, C., and Reynolds, P.F. “Isotach Networks,” IEEE Transactions on
`Parallel and Distributed Systems, 1997.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 4/98
`
`
`
` Williams, C., and Reynolds, P.F., "Combining Atomic Actions," Journal of
`Parallel and Distributed Computing, pp. 152-163, Feb., 1995.
`
` Srinivasan, S. and Reynolds, P.F., "Non-Interfering GVT Computation via
`Asynchronous Global Reductions," Proceedings of ACM Winter Simulation
`Conference, pp. 740-749, Dec., 1993.
`
` Reynolds, P.F., Pancerella, C., and Srinivasan, S., "Design and Performance
`Analysis of Hardware Support for Parallel Simulation," Journal of Parallel
`and Distributed Computing, pp. 435-453, Aug., 1993.
`
` Pancerella, C. and Reynolds, P.F., "Disseminating Critical Target-Specific
`Synchronization Information in Parallel Discrete Event Simulations,"
`Proceedings of the 7th Workshop on Parallel and Distributed Simulation, pp.
`52-59, May, 1993, San Diego, CA.
`
` Williams, C., and Reynolds, P.F., "Network-Based Coordination of
`Asynchronously Executing Processes with Caches," Workshop on Fine-
`Grain Massively Parallel Coordination, 4 pages, May, 1993, San Diego, CA.
`
` Reynolds, P.F., Pancerella, C. and Srinivasan, S. "Making Parallel
`Simulations Go Fast," Proceedings of the 1992 ACM Winter Simulation
`Conference, pp. 646-656, Dec., 1992.
`
` Reynolds, P.F., "An Efficient Framework for Parallel Simulation,"
`International Journal on Computer Simulation, 2, 4, pp. 427-445 (1992).
`
` Nicol, D.M., and Reynolds, P.F., "Optimal Dynamic Remapping of Parallel
`Computations," IEEE Transactions on Computer Systems, pp. 206-219
`(Feb., 1990).
`
` Reynolds, P.F., "Heterogeneous Distributed Simulation," Proceedings of the
`1988 ACM Winter Simulation Conference, pp. 206-209, Dec., 1988, San
`Diego, CA.
`
` Reynolds, P.F., "A Spectrum of Options for Parallel Simulation,"
`Proceedings of the 1988 ACM Winter Simulation Conference, pp. 325-332,
`Dec., 1988, San Diego, CA.
`
` Carson, S.D. and Reynolds, P.F., "The Geometry of Semaphore Programs,"
`ACM Transactions on Programming Languages and Systems, 9, 1, pp. 25-53
`(Jan., 1987).
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 5/98
`
`
`
` O’Hallaron, D.R. and Reynolds, P.F., "A Generalized Deadlock Predicate,"
`Information Processing Letters, pp. 181-188 (Nov., 1986).
`
` Nicol, D.M., and Reynolds, P.F., "An Optimal Repartitioning Decision
`Policy," Proceedings of The ACM Winter Simulation Conference, pp. 493-
`497, Nov., 1985, San Francisco, CA.
`
` Nicol, D.M. and Reynolds, P.F., "A Statistical Approach to Dynamic
`Partitioning," Proceedings of the SCS Winter Multi-Conference, pp. 53-56,
`Jan. 24-26, 1985, San Diego, CA.
`
` Reynolds, P.F., "A Shared Resource Algorithm for Distributed Simulation,"
`Proceedings of The 9th International Symposium on Computer Architecture,
`pp. 259-266, April, 1982, Austin, TX.
`
` Chandy, K.M., and Reynolds, P.F., "Scheduling Partially Ordered Tasks
`with Probabilistic Execution Times," Proceedings of Fifth SIGOPS, pp. 169-
`177, March, 1975, Austin, TX.
`
`12.
`
`A copy of my curriculum vitae, which describes in further detail my
`
`qualifications, responsibilities, employment history, honors, awards, professional
`
`associations, invited presentations, and publications is attached to this declaration
`
`as Appendix A-1.
`
`13.
`
`I have reviewed United States Patent No. 8,504,7461 (“the ’746
`
`patent”) to Michael L. Tasler as well as the applications referenced in the section
`
`of the ’746 patent entitled “Related U.S. Application Data.” I have also reviewed
`
`1 Michael L. Tasler, “Analog Data Generating and Processing Device for Use With
`a Personal Computer” U.S. Patent No. 8,504,746, filed September 27, 2010,
`claiming priority to a continuation application filed June 14, 1999. (Ex. 1201.)
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 6/98
`
`
`
`the publications cited in the footnotes of this declaration and referenced in the inter
`
`partes review petition submitted herewith.
`
`For my efforts in connection with the preparation of this declaration I have been
`
`compensated at my standard hourly rate of $425/hour. My compensation is in no
`
`way contingent on the results of these or any other proceedings relating to the
`
`above-captioned patent.
`
`INFORMATION PROVIDED TO ME
`
`II.
`14.
`
`In proceedings before the USPTO, I understand that the claims of an
`
`unexpired patent are to be given their broadest reasonable interpretation in view of
`
`the specification from the perspective of one skilled in the field. I have been
`
`informed that the ’746 patent has not expired. In comparing the claims of the ’746
`
`patent to the known prior art, I have carefully considered the ’746 patent, and the
`
`’746 patent’s file history using my experience and knowledge in the relevant field.
`
`15.
`
`I am informed that the ’746 patent was filed on September 27, 2010,
`
`but that it claims to be related to a chain of applications going back to a German
`
`application alleged to have been filed March 4, 1997. I am informed that this
`
`German application does not contain all of the disclosure of the ’746 patent.
`
`Nevertheless, for purposes of this declaration only, I have assumed a priority date
`
`of March 4, 1997 in determining whether a reference constitutes prior art.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 7/98
`
`
`
`16.
`
`I understand that a claim is invalid if its subject matter is anticipated
`
`or obvious. I further understand that anticipation of a claim requires that every
`
`element of a claim be disclosed expressly or inherently in a single prior art
`
`reference, in combination, as claimed.
`
`17.
`
`I further understand that obviousness of a claim requires that the claim
`
`be obvious from the perspective of a person having ordinary skill in the relevant art
`
`at the time the alleged invention was made. I further understand that a patent claim
`
`can be found unpatentable as obvious where 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 relevant field. I understand that an obviousness
`
`analysis involves a consideration of (1) the scope and content of the prior art,
`
`(2) the differences between the claimed invention and the prior art, and (3) the
`
`level of ordinary skill in the pertinent field.
`
`18.
`
`I further understand that certain factors may support or rebut the
`
`obviousness of a claim. I understand that such secondary considerations include,
`
`among other things, commercial success of the patented invention, skepticism of
`
`those having ordinary skill in the art at the time of invention, unexpected results of
`
`the invention, any long-felt but unsolved need in the art that was satisfied by the
`
`alleged invention, the failure of others to make the alleged invention, praise of the
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 8/98
`
`
`
`alleged invention by those having ordinary skill in the art, and copying of the
`
`alleged invention by others in the field. I understand that there must be a nexus—a
`
`connection—between any such secondary considerations and the alleged invention.
`
`I also understand that contemporaneous and independent invention by others is a
`
`secondary consideration tending to show obviousness.
`
`19.
`
`I further understand that a claim is obvious if it unites old elements
`
`with no change to their respective functions, or alters prior art by mere substitution
`
`of one element for another known in the field and that combination yields
`
`predictable results. While it may be helpful to identify a reason for this
`
`combination, common sense should guide and no rigid requirement of finding a
`
`teaching, suggestion or motivation to combine is required. When a product is
`
`available, design incentives and other market forces can prompt variations of it,
`
`either in the same field or different one. If a person having ordinary skill in the
`
`relevant art can implement a predictable variation, obviousness likely bars its
`
`patentability. For the same reason, if a technique has been used to improve one
`
`device and a person having ordinary skill in the art would recognize that it would
`
`improve similar devices in the same way, using the technique is obvious. I
`
`understand that a claim may be obvious if common sense directs one to combine
`
`multiple prior art references or add missing features to reproduce the alleged
`
`invention recited in the claims.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 9/98
`
`
`
`20.
`
`I have been asked to consider various prior art references. I have also
`
`been asked to consider whether the techniques and procedures discussed in the
`
`those references, read on each limitation of independent claims 1, 31 and 34 and
`
`dependent claims 2-30, 34-35 (the “Challenged Claims”) of the ’746 Patent. My
`
`conclusion is that the Challenged Claims of U.S. Patent No. 8,504,746 are invalid
`
`as obvious over those references.
`
`III. THE ’746 PATENT
`The ’746 patent generally relates to interface devices for transfer of
`21.
`
`data between a data transmitter (a.k.a. “analog source” or “analog signal
`
`acquisition channel”) and a host (a.k.a. “host computer” or “host device”) (Ex.
`
`1201 at 1:18-22).
`
`22.
`
`Tasler’s ’746 patent presents “randomly chosen” exemplars (Ex. 1201
`
`at 1:61) in support of his statement that “Existing data acquisition systems for
`
`computers are very limited in their areas of application.” (Ex. 1201 at 1:26-27.)
`
`His first example describes interface devices that “generally require very
`
`sophisticated drivers which are prone to malfunction.” (Ex. 1201 at 1:35-36.) No
`
`concrete examples are offered in support his statement regarding “prone to
`
`malfunction.”
`
`23.
`
`A second example presents a diagnostic radiology system that is
`
`reporting a fault. A responding service technician with a laptop is characterized as
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 10/98
`
`
`
`needing “fast data transfer and rapid data analysis.” (Ex. 1201 at 1:46-53.) A third
`
`example involves a multimeter as an input source, and a need “for the interface
`
`device to support a high data transfer rate.” (Ex. 1201 at 1:54-60.)
`
`24.
`
`From these examples Tasler concludes that: 1) “an interface may be
`
`put to totally different uses”; 2) it should “be sufficiently flexible to permit
`
`attachment of very different electrical or electronic systems to a host device by
`
`means of the interface”; and 3) “a universal method of operating the interface be
`
`provided for a large number of applications.” (Ex. 1201 at 1:61-2:3.)
`
`25.
`
`Tasler finds disadvantage in interface devices that must be installed
`
`inside a host computer: “such types of interface have the disadvantage that they
`
`must be installed inside the computer casing to achieve maximum data transfer
`
`rates.” (Ex. 1201 at 2:13-15.)
`
`26.
`
`Tasler discusses PCMCIA (Personal Computer Memory Card
`
`Association) interface technology, which was extant at the priority date of the
`
`patent. He states that PCMCIA is “A solution to this problem” regarding the need
`
`to install an interface device inside a computer’s casing. The PCMCIA interface
`
`allowed “interface devices [to be] connected by means of a plug-in card”. (Ex.
`
`1201 at 2:20-27) One type of PCMCIA card provided a special printer interface to
`
`a host computer by converting the PCMCIA interface to an established parallel
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 11/98
`
`
`
`standard interface (IEEE 1284). Tasler goes on to say about the PCMCIA
`
`technology:
`
`The known interface device generally consists of a driver
`component, a digital signal processor, a buffer and a hardware
`module which terminates in a connector to which the device whose
`data is to be acquired is attached. The driver component is attached
`directly to the enhanced printer interface thus permitting the known
`interface device to establish a connection between a computer and
`the device whose data is to be acquired.
`
`(Ex. 1201 at 2:33-41.)
`
`27.
`
`About PCMCIA, Tasler states “an interface-specific driver must be
`
`installed on the host device…” (Ex. 1201 at 2:42-45.) Tasler goes on to state: “if
`
`the driver is a general driver which is as flexible as possible and which can be used
`
`on many host devices, compromises must be accepted with regard to the data
`
`transfer rate.” (Ex. 1201 at 2:49-52.) No substantiation is offered regarding the
`
`claimed compromises.
`
`28.
`
`Tasler addresses the potential conflict for resources that may occur
`
`among tasks, including those that support data acquisition. He states that
`
`competing tasks may “result in a system crash.” (Ex. 1201 at 2:53-67). Tasler’s
`
`discussion of competing tasks is not associated with any particular host, operating
`
`system, driver technology or interface device technology.
`
`29.
`
`Tasler discusses an interface device that connects to a bus. The
`
`interface device can communicate with multiple peripheral devices. Control logic
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 12/98
`
`
`
`in the interface device is implemented using finite states machines, one for each
`
`peripheral. Tasler states “This known interface device provides optimal matching
`
`between a host device and a specific peripheral device.” (Ex. 1201 at 3:1-9.)
`
`30.
`
`Finally, Tasler discusses an interface device that communicates with
`
`its host via its floppy drive interface, and permits attachment of a peripheral
`
`device. Tasler notes there is “no information as to how communication should be
`
`possible if the interface is connected to a multipurpose interface instead of to a
`
`floppy disk drive controller.” (Ex. 1201 at 3:10-25.)
`
`31.
`
`The purported object of the ’746 patent interface device is to “provide
`
`an interface device...whose use is host device-independent and which delivers a
`
`high data transfer rate.” (Ex. 1201 at 3:29-32.) The interface device is meant to
`
`“simulate[s], both in terms of hardware and software, the way in which a
`
`conventional input/output device functions, preferably that of a hard disk.” (Ex.
`
`1201 at 4:17-20). I have read the following CAFC statement (as stated by the
`
`Court of Appeals for the Federal Circuit in a decision relating to the construction
`
`of claim terms in two related patents (U.S. Patent Nos. 6,895,449 and 6,470,399))
`
`regarding host and device communications. My opinion is consistent with this
`
`CAFC statement:
`
`The patents describe an interface device intended to overcome those
`limitations. It is common ground between the parties that, when a
`host computer detects that a new device has been connected to it, a
`normal course of action is this: the host asks the new device what
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 13/98
`
`
`
`type of device it is; the connected device responds; the host
`determines whether it already possesses drivers for (instructions for
`communicating with) the identified type of device; and if it does not,
`the host must obtain device-specific drivers (from somewhere) before
`it can engage in the full intended communication with the new device.
`In the patents at issue, when the interface device of the invention is
`connected to a host, it responds to the host’s request for
`identification by stating that it is a type of device, such as a hard
`drive, for which the host system already has a working driver. By
`answering in that manner, the interface device induces the host to
`treat it—and, indirectly, data devices on the other side of the
`interface device, no matter what type of devices they are—like the
`device that is already familiar to the host. Thereafter, when the host
`communicates with the interface device to request data from or
`control the operation of the data device, the host translates the
`communications into a form understandable by the connected data
`device.
`
`App. A-2, CAFC Opinion, 4-5.
`
`32.
`
`The ’746 patent describes an interface device capable of delivering the
`
`output of a data transmit/receive device to a host computer in a customary form on
`
`a multipurpose interface. The interface device can be viewed as a multi-step
`
`device that 1) receives data from an analog source (Ex. 1201 at independent claims
`
`1, 31, 34), 2) buffers digitized analog data in an internal memory (Ex. 1201 at
`
`independent claims 1, 31, 34), and then 3) delivers the buffered data to a host,
`
`presenting itself as a customary device via a multi-purpose interface, e.g., a hard
`
`drive, via a SCSI interface in the preferred embodiment (Ex. 1201 at 3:51-56).
`
`33.
`
`The ’746 Patent describes that the interface device contains a
`
`processor, which may be a digital signal processor (DSP), as well as memory, such
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 14/98
`
`
`
`as data storage memory and a program memory. (Ex. 1201 at Claims 1, 31, 34.)
`
`In the ’746 patent’s preferred embodiment in the form of a SCSI interface device,
`
`upon receiving an INQUIRY from the host, the interface device responds to the
`
`host, indicating that it is communicating with an i/o device. (Ex. 1201 Abstract,
`
`4:8-16.) Also, the interface device represents itself to the host as a customary i/o
`
`device. (Ex. 1201 at 4:16-20.) In this preferred embodiment the interface device
`
`manages “virtual files” (Ex. 1201 at 5:14-17) in support of simulating a
`
`conventional input/output device, “preferably as a virtual hard disk…” (Ex. 1201 at
`
`10:42-45.)
`
`34.
`
`Communication between the interface device and the host computer
`
`takes place using a program in the host present in commercially available computer
`
`systems. The ’746 Patent admits that “usual BIOS routines . . . issue an
`
`instruction, known by those skilled in the art as an INQUIRY instruction.” (Ex.
`
`1201 at 5:17-30.) In one embodiment of the ’746 patent as a SCSI interface
`
`device, communications between the host device and its multi-purpose interface
`
`are described as follows:
`
`communication between the host device and the multi-purpose
`interface can take place not only via drivers for input/output device
`customary in a host device which reside in the BIOS system of the
`host device but also via specific interface drivers which, in the case of
`SCSI interfaces, are known as multi-purpose interface ASPI
`(advanced SCSI programming interface) drivers.
`(Ex. 1201 at 10:23-29.)
`
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 15/98
`
`
`
`35.
`
`The ’746 patent states about the ASPI driver: “this multi-purpose
`
`interface driver has the task of moving precisely specified SCSI commands from
`
`the host program to the host system SCSI adapter.” (Ex. 1201 at 10:33-36.)
`
`36.
`
`The ’746 patent uses configuration files in order to provide
`
`instructions concerning operations a user may wish to perform on data from an
`
`analog input. For example, users can provide configuration files to the interface
`
`device that specify how long a measurement from the analog input is to last. (Ex.
`
`1201 at 6:11-15). “[T]he user can also create a configuration file, whose entries
`
`automatically set and control various functions” on the interface device. (Ex. 1201
`
`at 6:47-49.) “These settings can be, for example, gain, multiplex or sampling rate
`
`setting.” (Ex. 1201 at 6:51-52). Thus, the interface device requires a user to
`
`provide a configuration file specifying his/her measurements to capture data from
`
`the data device.
`
`A. Automatic Recognition Process (ARP) and Identification
`Information
`
`37.
`
`The Tasler ’746 patent introduces the concept of an “automatic
`
`recognition process” in independent claims 1, 31 and 34. In each of these claims,
`
`sending of “at least one parameter” “indicative of the class of devices” or
`
`“identifying the analog data acquisition device as a digital [mass storage] device”
`
`from the interface device to the host is presented as part of an automatic
`
`recognition process. A parameter “indicative of the class of devices” or
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 16/98
`
`
`
`“identifying the analog data acquisition device as a digital [mass storage] device”
`
`is not defined in the ’746 patent specification. Acquisition of device identification
`
`information over a SCSI interface is discussed in ¶¶ 64-73, infra.
`
`B.
`38.
`
`File System Information
`
`The Tasler ’746 patent references the sending of “acquired analog
`
`data file system information” from the analog data acquisition device to a host in
`
`dependent claim 17 (dependent from claim 1). Dependent claim 18 (dependent
`
`from claim 17) further requires the “file system information” to include “an
`
`indication of a file system type that is used to store the digitized analog data.”
`
`Tasler’s use of “file system information” is independent of the operating system
`
`used on the interface device as explained next. Tasler’s characterization of file
`
`system information as including “the drive type, the starting position and the length
`
`of the file allocation table (FAT), the number of sectors, etc., known to those
`
`skilled in the art.” (Ex. 1201 at 5:41-47) is largely specific to Microsoft FAT-
`
`based file systems. One skilled in the art would understand that file system
`
`information returned by a UNIX operating system for example, would not return
`
`FAT information, but would return sufficient information for a host to determine
`
`the same critical file system information that can be learned from file system
`
`information representing a Microsoft FAT-based file system. The contents of “file
`
`system information” needed to enable determination of critical information such as
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 17/98
`
`
`
`the type of file system in use, the number of sectors on the disk drive, and the
`
`location and extent of the file directory, among others.
`
`IV. THE LEVEL OF ORDINARY SKILL IN THE ART
`I have been informed that the level of skill in the art is evidenced by
`39.
`
`the prior art references. The prior art discussed herein demonstrates that a person
`
`of ordinary skill in the field, at the relevant time (1996-1998) would have had at
`
`least a four-year degree in electrical engineering, computer science, or related field
`
`of study, or equivalent experience, and at least two years’ experience in studying or
`
`developing computer interfaces or peripherals. In my opinion, a person of ordinary
`
`skill would also be familiar with operating systems (e.g., MS-DOS, Windows,
`
`Unix) and their associated file systems (e.g., a FAT file system), device drivers for
`
`computer components and peripherals (e.g., mass storage device drivers), and
`
`communication interfaces (e.g., SCSI and PCMCIA interfaces).
`
`40.
`
`Based on my experience I have an understanding of the capabilities of
`
`a person of ordinary skill in the relevant field. I have supervised and directed
`
`many such persons over the course of my career. Further, I had those capabilities
`
`myself at the time the patent was filed.
`
`V. THE PRIOR ART
`A. Kawaguchi’s ‘853 Application
`Kawaguchi’s ‘853 application (Ex. 1207) describes an interface
`41.
`
`device, called a “SCSI device converter,” (“SDC”) which operates between a
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 18/98
`
`
`
`collection of analog devices and a host computer (a.k.a. “engineering
`
`workstation”2 or “EWS”), communicating with the EWS via a SCSI interface (Ex.
`
`1207, p. 2). The Kawaguchi patent discloses various uses and capabilities of the
`
`SDC interface device. Of particular importance to my opinion is the use of the
`
`SDC as an interface device between analog peripheral devices and a host computer
`
`wherein the SDC appears to the host computer as a disk drive over their SCSI
`
`communication interface.
`
`2 In early 1997 an engineering workstation was a computer designed for engineering design,
`analysis, data acquisition and control. These computers often had high performance CPU’s,
`extra memory, high capacity disk drives, extra cooling and provisions for connecting multiple
`data input and output devices, including analog sensors, measuring equipment (e.g. multimeters)
`and plotters.
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 19/98
`
`
`
`
`
`42.
`
`In its preferred embodiment shown above, the SDC (3) communicates
`
`through its SCSI interface with attached SCSI I/O port (7) with the host (1)
`
`through the host’s SCSI I/O port and SCSI interface (2). (“a SCSI interface
`
`connected to a SCSI interface in an engineering workstation (EWS)” (Ex. 1207 at
`
`p. 2.) The EWS and SDC are characterized and depicted as separate devices (Ex.
`
`1207 at p. 2, Figure 1). Each has its own SCSI interface, depicted in Kawaguchi’s
`
`Figure 1 as being on the periphery of the respective devices. The EWS and the
`
`SDC would necessarily have I/O ports, associated with their SCSI interfaces, in the
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 20/98
`
`
`
`form of connectors in order to support being “connected to.” They would be
`
`connected by a SCSI cable since each of them has a SCSI interface (with attached
`
`I/O port).
`
`43.
`
`The SDC communicates with peripheral devices by way of their own
`
`interfaces, such as RS-232, VME, etc. and possibly including SCSI. According to
`
`Figure 1 in the ‘853 application, the SDC can “easily connect a device such as a
`
`PC peripheral device or a sequencer” (Ex. 1207, p. 2), while communicating by
`
`way of a SCSI interface with the EWS on behalf of these devices. Examples of
`
`candidate attached devices, as depicted in Figure 1, include a CD-ROM 5, a plotter
`
`4 and a sequencer 6. Nothing would prevent attachment of other analog devices
`
`such as scanners and printers. Also, Kawaguchi proposes an analog to digital
`
`converter in the SDC, which could be connected to arbitrary analog sensors. (Ex.
`
`1207 at p. 5.)
`
`44.
`
`In its preferred embodiment, the SDC comprises the kinds of
`
`components that constitute a general purpose computer. It includes “a SCSI
`
`interface (7) for connecting to the EWS (1), and includes personal computer I/O
`
`bus interfaces (8) (9) and an interface for a bi-directional parallel bus interface
`
`(10)” It also includes a “microcomputer, ROM and RAM” (Ex. 1207 at p. 5).
`
`45.
`
`In the SDC, implementation of internal components 11 through 17 is
`
`done by the microcomputer, ROM and RAM: “The SCSI device converter (3) also
`
`Canon Exhibit 1204
`
`HUAWEI EX. 1204 - 21/98
`
`
`
`implements a data writing unit (11), a data reading unit (12), a control data writing
`
`unit (13), an interrupt data reading unit (14), a code converting unit (15), a control
`
`unit (16) and an interrupt control unit (17) by using a microcomputer, ROM and
`
`RAM.” (Ex. 1207 at p. 5.) Some of these components are operatively connected
`
`to I/O interfaces, either the SCSI interface or the interfaces for the peripheral
`
`devices: “The codeconverting (sic) unit (15) and the control unit (16) are located
`
`between each of the data writing units and reading units (11) (12) (13) (14) and the
`
`device interfaces (8) (9) (10)” (Ex. 1207 at p. 5). Altogether, these components,
`
`(11) through (16), perform functions that manage, translate and transfer the data
`
`flowing into and out of the SDC, both to/from the EWS and the peripheral devices.
`
`46.
`
`“The control unit (16) controls the data transmission/reception
`
`between the EWS and the peripheral devices” (Ex. 1207 at p. 5). “The control unit
`
`(16) controls the input and output of data to the peripheral devices (4) (5) (6) via
`
`the device interfaces (8) (9) (10).” (Ex. 1207 at p. 5.) The SDC also implements a
`
`“code converting unit”, that is “interposed between the data writing unit, the
`
`reading unit, and the device interface for converting data between the SCSI format
`
`and the peripheral device bus format” (Ex. 1207 at pp. 4-5.)
`
`47.
`
`The SDC emulates four disk drives on its SCSI connection to the
`
`EWS, where for each of them “the apparatus in the present invention operates in a
`
`manner emulating the hard disk.” (Ex. 1207 at p. 7.) All four emulated disk drives
`
`C