Fax: (202) 371-2540 UNITED STATES PATENT AND TRADEMARK ... · 1255 (Fed. Cir. 2015). 1017–1018 Intentionally Left Blank 1019 Webster’s Encyclopedic Unabridged Dictionary of the

Filed on behalf of Apple Inc. By: Lori A. Gordon Sterne, Kessler, Goldstein & Fox PLLC 1100 New York Avenue, NW Washington, D.C. Tel: (202) 371-2600 Fax: (202) 371-2540

UNITED STATES PATENT AND TRADEMARK OFFICE

BEFORE THE PATENT TRIAL AND APPEAL BOARD

PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 8,504,746

Mail Stop PATENT BOARD Patent Trial and Appeal Board U.S. Patent & Trademark Office P.O. Box 1450 Alexandria, VA 22313-1450

Petition for Inter Partes Review of U.S. Patent No. 8,504,746

- i -

TABLE OF CONTENTS I. Mandatory notices (37 C.F.R. § 42.8(a)(1)). ................................................. 2

II. Grounds for standing (37 C.F.R. § 42.104(a))............................................... 4

III. Identification of challenge (37 C.F.R. § 42.104(b)). ..................................... 4

A. Citation of prior art. ....................................................................................... 4

B. Statutory grounds for the challenge. .............................................................. 6

IV. The ’746 patent. ............................................................................................. 7

A. Overview. ....................................................................................................... 7

B. The challenged claims of the ’746 patent are not entitled to priority benefit of the March 1997 German application. ........................................................ 9

C. Level of ordinary skill in the art. ................................................................. 15

D. Claim construction. ...................................................................................... 16

V. Ground 1: The combination of Ard, Schmidt, and Webb renders claims 1, 6–8, 14, 20, 21, 30, and 34 obvious. ............................................................ 18

A. Overview of Ard. ......................................................................................... 18

B. Overview of Schmidt. .................................................................................. 21

C. Overview of Webb. ...................................................................................... 23

D. The combination renders claim 1 obvious. .................................................. 24

1. The combination discloses the “analog data acquisition device” recited in the preamble of claim 1 [1P]. .......................................................... 24

a) “analog data acquisition device” ................................................... 25

b) Computer architecture/operation component ................................. 26

2. The combination discloses the analog data acquisition device architectural limitations. ...................................................................... 30

a) “program memory” [1A] ................................................................ 30

b) “an analog signal acquisition channel for receiving a signal from an analog source” [1B] ........................................................................ 31

c) The “processor” limitation [1C] .................................................... 33

3. The combination discloses the “data generation process” limitations [1D]. ..................................................................................................... 36


- ii -

a) “data generation process” [1D.1] ................................................... 37

b) “analog data is processed and digitized” [1D.2] ............................ 38

c) “file system” [1D.3] ....................................................................... 38

4. The combination discloses claim limitation [1E]. .............................. 39

a) “parameter indicative of the class of devices” [1E.2] .................... 39

b) “the processor executes at least one instruction set” [1E.1] .......... 43

c) “not within the class of devices” [1E.3]. ........................................ 43

5. The combination discloses claim element [1F]. .................................. 44

a) file transfer process [1F.2] ............................................................. 44

b) “at least one other instruction set” [1F.1] ...................................... 46

c) appearance of the device as part of the class of devices [1F.3] ..... 46

6. The combination discloses claim limitation [1G]. .............................. 47

E. The combination renders claim 6 obvious. .................................................. 49

F. The combination renders claim 7 obvious. .................................................. 49

G. The combination renders claim 8 obvious. .................................................. 50

H. The combination renders claim 14 obvious. ................................................ 51

I. The combination renders claim 20 obvious. ................................................ 52

J. The combination renders claim 21 obvious. ................................................ 55

K. The combination renders claim 30 obvious. ................................................ 56

L. The combination renders independent claim 34 obvious. ........................... 58

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]. ......................... 59

2. The combination discloses the “interfacing” step of claim 34 [34A]. 59

3. The combination discloses the “acquiring” step of claim 34 [34B]. .. 60

4. The combination discloses the “sending” step of claim 34 [34C]. ..... 61

5. The combination discloses the “transferring” step of claim 34 [34D].62

VI. Ground 2: The combination of Ard, Schmidt, Webb, and Araghi renders claims 4 and 11 obvious. ............................................................................. 64

A. The combination renders claim 4 obvious. .................................................. 64


- iii -

B. The combination renders claim 11 obvious. ................................................ 65

VII. Ground 3: The combination of Ard, Schmidt, Webb, and Steinle renders claims 10 and 35 obvious. ........................................................................... 67

A. The combination renders claim 10 obvious. ................................................ 67

B. The combination renders claim 35 obvious. ................................................ 70

VIII. Ground 4: The combination of Ard, Schmidt, Webb, and Reisch renders claim 23 obvious. ......................................................................................... 72

IX. Conclusion. .................................................................................................. 73


- iv -

TABLE OF AUTHORITIES

Cases: In re Papst Licensing Digital Camera Patent Litigation, 778 F.3d 1255 (Fed. Cir. 2015) ................................................................................ 16 Martin v. Mayer, 823 F.2d 500 (Fed. Cir. 1987) .................................................................................. 10 Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) ................................................................................ 18 PowerOasis, Inc. v. T-Mobile USA, Inc., 522 F.3d 1299 (Fed. Cir. 2008) ................................................................................ 10 Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555 (Fed. Cir. 1991) ................................................................................ 10 Statutes: 35 U.S.C. § 102(a) ................................................................................................. 5, 6 35 U.S.C. § 102(b) ................................................................................................. 5, 6 35 U.S.C. § 102(e) ................................................................................................. 5, 6


- v -

EXHIBIT LIST

Ex. No. Description 1001 U.S. Patent 8,504,746 to Tasler 1002 Excerpts of File History of U.S. Patent 8,504,746 to Tasler 1003 Declaration of Dr. Erez Zadok in Support of Petition for Inter Partes

Review of U.S. Patent No. 8,504,746 1004 Curriculum Vitae of Dr. Erez Zadok

1005–1006 Intentionally Left Blank 1007 The SCSI Bus and IDE Interface Protocols, Applications and

Programming, by Schmidt, First Edition, Addison-Wesley, 1995 1008 Intentionally Left Blank 1009 U.S. Patent No. 4,727,512 to Birkner 1010 U.S. Patent No. 4,792,896 to Maclean 1011 International Publication Number WO 92/21224 to Jorgensen 1012 Small Computer System Interface-2 (SCSI-2), ANSI X3.131-1994,

American National Standard for Information Systems (ANSI). 1013 Operating System Concepts, by Silberschatz et al., Fourth Edition. 1014 Microsoft Computer Dictionary, Third Edition, Microsoft Press,

1997. 1015 Intentionally Left Blank 1016 In re Papst Licensing Digital Camera Patent Litigation, 778 F.3d

1255 (Fed. Cir. 2015). 1017–1018 Intentionally Left Blank

1019 Webster’s Encyclopedic Unabridged Dictionary of the English Language, Random House, 1996.

1020 Papst Licensing GmbH & Co., KG v. Apple Inc., Case No. 6-15-cv-01095 (E.D. Tex.), Complaint filed November 30, 2015

1021–1023 Intentionally Left Blank 1024 Declaration of Scott Bennett 1025 Intentionally Left Blank 1026 U.S. Patent No. 4,698,131 to Araghi et al. 1027 Intentionally Left Blank 1028 U.S. Patent No. 5,706,216 to Reisch

1029-1030 Intentionally Left Blank


- vi -

Ex. No. Description 1031 Plug-and-Play SCSI Specification, Version 1.0, dated March 30,

1994 (“PNP SCSI”) 1032 Intentionally Left Blank 1033 U.S. Patent No. 4,970,605 to Fogaroli et al. 1034 U.S. Patent No. 5,623,556 to Murayama et al. 1035 U.S. Patent No. 5,196,946 to Balkanski et al.

1036-1045 Intentionally Left Blank 1046 U.S. Patent No. 5,915,106 to Ard 1047 Intentionally Left Blank 1048 U.S. Patent No. 5,489,772 to Webb et al. 1049 German Patent Application DE 197 08 755 A1 to Tasler 1050 German Patent Application DE 197 08 755 A1 to Tasler (English

Translation) 1051-1053 Intentionally Left Blank

1054 Livingston, Brian “Windows 3.1 Secrets” (1992) 1055 RFC 1314, “A File Format for the Exchange of Images in the

Internet,” published April 1992, https://tools.ietf.org/pdf/rfc1314.pdf 1056 U.S. Patent No. 5,300,767 to Steinle et al. 1057 MacPaint Manual


- 1 -

Apple Inc. petitions for inter partes review of claims 1, 4, 6–8, 10, 11, 14, 20,

21, 23, 30, 34, and 35 of United States Patent No. 8,504,746 to Tasler (“the ʼ746

patent”). The ’746 patent claims priority benefit to a March 1997 German

application. However, the challenged claims recite limitations having no written

description support in the German application. Therefore, the earliest possible

priority date of the ’746 patent is the March 1998 filing date of the PCT application.

In the present petition, Apple presents an intervening reference, U.S. Patent

5,915,106 to Ard (“Ard”) filed after the German application date but before the

PCT application date. Apple demonstrates herein that a reasonable likelihood exists

that the challenged claims are unpatentable in view of the intervening Ard

reference.

The challenged claims recite an analog data acquisition device and associated

method. The device performs well-known tasks such as acquiring analog data,

digitizing the analog data, storing the digitized data in memory, and allowing

transfer of the digitized data to a host computer. The purported novelty of the ’746

patent is that, when attached to a host computer, the analog data acquisition device

identifies itself as “automatically caus[ing] at least one parameter indicative of the

class of devices” of which the device is not a member, such that for file transfer, the

“analog data acquisition device appears to the computer as if it were a device of the


- 2 -

class of devices.” (Ex. 1001, ’746 patent, claim 1.) This technique is commonly

referred to as emulation.

Devices that emulated a digital storage device (e.g., hard disk drives) and

used the existing storage device’s driver for communication with a host computer

were well known before the March 3, 1998 filing date of the PCT application to

which the’746 patent claims priority (“the PCT application.”). For example, Ard,

filed more than a year before the filing date of the PCT application, disclosed a

scanner that emulates a disk drive such that a “general purpose computer identifies

the scanner as a disk drive” and controls the scanner “via standard operating system

disk drive commands without utilizing a specifically developed device driver.”

(Ard, Abstract, 1:15–16.)

I. Mandatory notices (37 C.F.R. § 42.8(a)(1)).

REAL PARTY IN INTEREST: The real party-in-interest of Petitioner is Apple

Inc. (“Apple”).

RELATED MATTERS: The ’746 patent is the subject of the following civil

actions.

Papst Licensing GmbH & Co., KG v. Apple Inc., Case No. 6-15-cv-01095

(E.D. Tex.); Papst Licensing GmbH & Co., KG v. LG Electronics, Inc. et al., Case

No. 6-15-cv-01099 (E.D. Tex.); Papst Licensing GmbH & Co., KG v. ZTE


- 3 -

Corporation et al., Case No. 6-15-cv-01100 (E.D. Tex.); Papst Licensing GmbH &

Co., KG v. Samsung Electronics Co Ltd. et al., Case No. 6:15-cv-01102 (E.D. Tex.);

Papst Licensing GmbH & Co., KG v. Lenovo (United States) Inc. et al., Case No. 6-

15-cv-01111 (E.D. Tex.); Papst Licensing GmbH & Co., KG v. Huawei

Technologies Co., Ltd. et al, Case No. 6:15-cv-01115 (E.D. Tex.); and In Re Papst

Licensing GmbH & Co., KG Patent Litigation, MDL No. 1880 (Misc. Action No.

07-493) relating to Nos. 07-cv-1118, 07-cv-1222, 07-cv-2086, 07-cv-2088, 08-cv-

865, 08-cv-985, 08-cv-1406, and 09-cv-530.

The ’746 patent is also the subject of the following Inter Partes Review

proceedings: Inter Partes Review by Canon Inc., IPR2016-01211 filed June 17,

2016; Inter Partes Review by Canon Inc., IPR2016-01224 filed June 17, 2016; Inter

Partes Review by JVC Kenwood Corporation, IPR2016-01213 filed June 17, 2016;

Inter Partes Review by Panasonic Corporation, IPR2016-01223 filed June 17, 2016;

Inter Partes Review by Olympus Corporation., IPR2016-01206 filed June 16, 2016;

and Inter Partes Review by Fujifilm Corporation, IPR2016-01200 filed June 14,

2016.

Additionally, Apple is filing additional petitions against claims of the ’746

patent.

No other matters related to the ’746 patent are known to the Petitioner.


- 4 -

LEAD AND BACKUP COUNSEL: Pursuant to 37 C.F.R. § 42.8(b)(3) and

42.10(a), Petitioner appoints Lori A. Gordon (Reg. No. 50,633) as its lead counsel

and Steven W. Peters (Reg. No. 73,193) as its back-up counsel, and Yasser

Mourtada (Reg. No. 61,056) as its additional back-up counsel, all at the address:

STERNE, KESSLER, GOLDSTEIN & FOX, 1100 New York Avenue, N.W., Washington,

D.C., 20005, phone number (202) 371-2600 and facsimile (202) 371-2540.

SERVICE INFORMATION: Petitioner consents to electronic service by email at

the email addresses: [email protected], [email protected], and

[email protected].

II. Grounds for standing (37 C.F.R. § 42.104(a)).

The undersigned and Apple certify the ʼ746 patent is available for inter partes

review. Apple certifies it is not barred or estopped from requesting this inter partes

review on the grounds identified herein. The assignee of the ’746 patent, Papst, filed

a complaint against Apple alleging infringement of the ’746 patent on November 30,

2015. (Ex. 1020.) The present petition is being filed within one year of service of

Petitioner.

III. Identification of challenge (37 C.F.R. § 42.104(b)).

A. Citation of prior art.

The ’746 patent claims priority through a series of applications to U.S. Patent

No. 6,470,399 which is the national stage of international application

mailto:[email protected]


- 5 -

PCT/EP98/01187, filed on March 3, 1998. The ’746 patent further claims priority to

a German application, filed on March 4, 1997. Apple demonstrates in Section IV.B

that none of the challenged claims are entitled to priority benefit of the German

application.1

Each of the following prior art documents applied in the grounds of

unpatentability were published prior to the PCT application date.

U.S. Patent No. 5,915,106 to Ard (Ex. 1046) is prior art under at least 35

U.S.C. §102(e) because it was filed on March 20, 1997.

The SCSI Bus and IDE Interface—Protocols, Applications and

Programming, by Friedhelm Schmidt (Ex. 1007), is prior art under at least 35

U.S.C. §§ 102(a) and 102(b) because it was published in 1995. (See Ex. 1024.)

U.S. Patent No. 5,489,772 to Webb et al. (Ex. 1048), is 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.

1 Apple does not acquiesce that the ’746 patent is entitled to benefit of the

PCT application or any earlier filed continuation or divisional applications.

However, these priority determinations are not necessary for the purposes of the

present petition.


- 6 -

U.S. Patent No. 4,698,131 to Araghi et al. (Ex. 1026) is prior art under at

least 35 U.S.C. §§ 102(a), 102(b), and 102(e) because it issued on October 6, 1987.

U.S. Patent No. 5,300,767 to Steinle et al. (Ex. 1056) is prior art under at

least 35 U.S.C. §§102(a), 102(b), and 102(e) because it issued on April 5, 1994.

U.S. Patent No. 5,706,216 to Reisch (Ex. 1028) is prior art under at least 35

U.S.C. §§ 102(a) and 102(e) because it was filed on July 28, 1995.

B. Statutory grounds for the challenge.

Apple requests review of claims 1, 4, 6–8, 10, 11, 14, 20, 21, 23, 30, 34, and

35 on the following grounds:

References Basis Claims Challenged

Ard, Schmidt, and Webb § 103 1, 6–8, 14, 20, 21, 30, 34

Ard, Schmidt, Webb, and Araghi § 103 4, 11

Ard, Schmidt, Webb, and Steinle § 103 10, 35

Ard, Schmidt, Webb, and Reisch § 103 23


- 7 -

IV. The ’746 patent.

A. Overview.

The ’746 patent describes an interface device that enables communication

between a host device and a data transmit/receive device from which data is

acquired. (See ’746 patent, 1:20–24.) The patent acknowledges that such interface

devices were known. However, the patent alleges that these existing interfaces

traded high data transfer rates for host-device independence. (Id., 3:28–31.) For

example, in existing interfaces devices, high data transfer rates could be achieved

using host-specific interface devices; but, these interfaces were not suitable for use

with other types of host systems. (Id., 2:6–15.) In other alternative devices, host-

device independence was achieved through the use of standard interfaces; but these

interfaces required specific driver software that in turn, resulted in reduced data

transfer speed. (Id., 1:33–40.)

The ’746 patent discloses an interface device that purportedly overcomes

these limitations and “provides fast data communication between a host device with

input/output interfaces and a data transmit/receive device.” (Id., Abstract.) As

illustrated in Figure 1 reproduced below, the interface device 10 includes “[a] first

connecting device 12…attached to a host device (not shown) via a host line 11.”

(Id., 4:59–62.) The ’746 patent states “[t]he first connecting device is attached both

to a digital signal processor 13 and to a memory means 14” which, in turn, are


- 8 -

“attached to a second connecting device.” (Id., 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.” (Id., 4:67 to 5:4.)

The ’746 patent discloses techniques to make “the interface device appear[] to

the host device as a hard disk.” (Id., 6:2–3.) Specifically, the ’746 patent relies on a

known host system identification process: when a host device is booted, an inquiry

instruction as to devices attached to the host device is issued to the input/output

interfaces of the host device. (Id., 5:14–20.) When the interface device receives the

inquiry instruction, the interface device identifies itself, regardless of the type of


- 9 -

attached data transmit/receive device, as a customary input/output device to the host

device. (See id., 4:5–13.) Thus, the host device uses its customary driver for the

identified input/output device or a corresponding driver for a multi-purpose interface

to communicate with the interface device. (Id., 3:49–55.)

B. The challenged claims of the ’746 patent are not entitled to priority benefit of the March 1997 German application.

The ’746 patent is the national stage of international application

PCT/EP98/01187 filed on March 3, 1998. The ’746 patent further claims priority to

a German application filed on March 4, 1997. (Exhibit 1049). A certified translation

of the German application is provided as Exhibit 1050.

An international application designating the United States is entitled to

priority of a prior national application provided that the conditions of 35 U.S.C. §

120 are met. See 35 U.S.C. § 365(c). Section 120, in turn, requires the claims meet

the written description and enablement requirements of 35 U.S.C. § 112 in order to

obtain benefit of the earlier filing date. See 35 U.S.C. §§ 112 and 120. The

challenged claims of the ’746 patent are not entitled to priority benefit of the

German application because the German application does not provide written

description support for the challenged claims.

Each of the challenged claims requires the computer comprises “a

multipurpose interface.” (See ’746 patent, claim 1). Independent claim 1 further


- 10 -

specifies that the claimed analog data acquisition device is “operatively connectable

to a computer through a multipurpose interface of the computer.” Claim 1 also

recites “the processed and digitized analog data is stored in a file system of the data

storage memory as at least one file of digitized analog data.” The German

application fails to provide written description support for the claimed “multi-

purpose interface” of the computer and “stor[age] in a file system of the data

storage memory” of the analog data acquisition device.

To satisfy the written description requirement, the disclosure of the German

application must “convey with reasonable clarity to those skilled in the art that, as of

the filing date sought, [the inventor] was in possession of the invention.” Vas-Cath

Inc. v. Mahurkar, 935 F.2d 1555, 1563–64 (Fed. Cir. 1991). Accordingly, the

written description must actually or inherently disclose the claim element.

PowerOasis, Inc. v. T-Mobile USA, Inc., 522 F.3d 1299, 1306 (Fed. Cir. 2008).

Here, there is not a single reference in the written description of the German

application which suggests the inventor understood the invention to include a

“multipurpose interface” of the computer. Nor is the inclusion of a multipurpose

interface necessarily present in the German application. See Martin v. Mayer, 823

F.2d 500, 505 (Fed. Cir. 1987) (holding the written description requirement is “not a

question of whether one skilled in the art might be able to construct the patentee’s


- 11 -

device from the teachings of the disclosure…. Rather, it is a question whether the

application necessarily discloses that particular device”) (emphasis in original).

The chart below compares language from the German application and the

’746 application as filed (Exhibit 1002, pp. 223–245.) highlighting the concept of a

multipurpose interface and its associated drivers was specifically added as a new

embodiment, after the filing of the German application.

’746 Application As Filed German Application

“When the host device system with

which the interface device according to

the present invention is connected is

booted and a data transmit/receive

device is also attached to the interface

device 10,

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.”

(Ex. 1002, p. 231, ¶23.)

“If the host device system with which

the interface device as per the present

invention is connected for which a data

sending/receiving unit is also linked to

the interface device 10, is booted,

normal BIOS routines output a

command

to each input/output interface available

in the host device

that is recognized among experts as an

“‘INQUIRY’ command.”

(Ex. 1050, p. 3.)


- 12 -

’746 Application As Filed German Application

“For persons skilled in the art it is

however obvious that the interface

device 10 is not necessarily signed on

when the computer system is powered

up

but that a special BIOS routine or a

driver for a multi-purpose interface

can also be started on the host device

during current operation of the

computer system in order to sign on or

mount the interface device 10 as an

additional hard disk.”

(Ex. 1002, p. 235, ¶32.)

“However, it is obvious for experts that

the interface device 10 is not

necessarily registered when switching

on the computer

rather than a special BIOS routine

can be started on the host device also

while the computer runs in order to

connect or “mount” the interface

device 10 as an additional hard disk.”

(Ex. 1050, p. 4.)

An important advantage of the

interface device 10 of the present

invention is that it also permits

extremely high data transfer rates by

using,

for data interchange,

the host device-own BIOS routines

which are optimized for each host

device by the host device manufacturer

“A significant advantage of the

interface device 10 of this invention

also consists of it enabling extremely

high data transfer rates and this already

by using

the host unit’s own BIOS routines,

which the manufacturer of the host unit

or BIOS system has optimized for each

host unit,


- 13 -

’746 Application As Filed German Application or BIOS system manufacturer, or by

using driver programs which are

normally optimized and included by

the manufacturers of multi-purpose

interfaces.

(Ex. 1002, p. 236, ¶34.)

for exchanging data.”

(Ex. 1050, p. 5.)

The inventor also did not recognize BIOS routines implementing SCSI

commands as a multi-purpose interface. (Zadok Decl., ¶171.) Rather, the inventor

understood such BIOS routines as providing a “classical input/output interface.” For

example, the ’746 patent includes the following disclosure not found in the German

application:

Multi-purpose interfaces comprise both an interface card

and specific driver software for the interface card. The

driver software can be designed so that it can replace the

basic input/output system (BIOS) driver routines.

Communication between the host device and the devices

attached to the multi-purpose interface then essentially

takes place by means of the specific driver software for the

multi-purpose interface and no longer primarily by

means of BIOS routines of the host device. Recently

however drivers for multi-purpose interfaces can also


- 14 -

already be integrated in the BIOS system of the host

device, as alongside classical input/output interfaces,

multi-purpose interfaces are becoming increasingly

common in host device.

(’746 patent, 3:53–65 (emphasis added).)

Thus, the inventor understood multi-purpose interfaces as a replacement for

BIOS routines integrating classical input/output interfaces. As such, the German

application does not explicitly or inherently disclose a multi-purpose interface.

Further, the ’German application fails to provide written description support

for storing the processed and digitized analog data in a file system of the data

storage memory. The German application (and the ’746 patent itself) includes no

mention whatsoever of any file system on the interface device. Instead, “the

interface device according to the present invention simulates a hard disk with a root

directory whose entries are ‘virtual’ files,” not actual files stored in an actual file

system. (’746 patent, 5:11–14; Ex. 1050, p. 3.) The German application also

mentions a file allocation table (FAT) but distinguishes an “actual drive” which

could include a FAT, from the interface device which merely simulates one. (See

’746 patent, 5:34–58; Ex. 1050, p. 3.) For example, for “communication between a

processor and a hard disk…, the processor transfer[s] to the hard disk the numbers

of the blocks or clusters or sectors whose contents it wishes to read.” (’746 patent,


- 15 -

6:17–21; Ex. 1050, p. 4.) Conversely, in the ’746 system, “communication between

the host device and the interface device…consists of the very fast transfer of block

numbers and preferably block number ranges because a virtual ‘real-time input’ file

will not be fragmented.” (’746 patent, 6:22–27; Ex. 1050, p. 4.) Thereafter, “[i]f the

host device now wants to read the ‘real-time input’ file, it transfers a range of block

numbers to the interface device, whereupon data commences to be received via the

second connecting device and data commences to be sent to the host device via the

first connecting device.” (’746 patent, 6:27–32; Ex. 1050, p. 4.) Thus, the data is

never stored as a file in a file system on the interface device.

Because the German application does not actually or inherently disclose the

“multipurpose interface” or “file system” limitations such that one skilled in the art

would recognize such a disclosure, the challenged claims are not entitled to priority

benefit of the ’746 German application. Accordingly, the earliest possible priority

date for purposes of this inter partes review proceeding is the March 3, 1998 PCT

application date.

C. Level of ordinary skill in the art.

Based on the disclosure of the ’746 patent, a person having ordinary skill in

the art at the relevant time, would have had at least a four-year degree in electrical

engineering, computer science, computer engineering, or related field of study, or

equivalent experience, and at least two years of experience in studying or


- 16 -

developing computer interfaces or peripherals and storage related software. (Zadok

Decl., ¶28.) 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). (Id.)

D. Claim construction.

Except for the exemplary terms set forth herein, the terms are to be given their

plain and ordinary meaning as understood by a person of ordinary skill in the art and

consistent with the disclosure. 2 Papst asserted patents in the family of the ’746

patent in several district court litigations. In addition, claim construction of certain

terms in related U.S. patent 6,470,399 was the subject of an appeal to the Federal

Circuit. In re Papst Licensing Digital Camera Patent Litigation, 778 F.3d 1255

(Fed. Cir. 2015). The Federal Circuit addressed the construction of five terms:

interface device, second connecting device, data transmit/receive device, virtual

files, and input/output device customary in a host device. Of these five terms,

2 Petitioner reserves the right to present different constructions in another

forum where a different claim construction standard applies.


- 17 -

Petitioner proposes3 to construe the term “data transmit/receive device.” The other

terms do not appear in any of the claims challenged in this Petition. The District

Court and Federal Circuit's claim construction analysis for this term is provided

below.

Claim term District Court CAFC

“data transmit/receive device”

“a device that is capable of either (a) transmitting data to or (b) transmitting data to and receiving data from the host device when connected to the host device by the interface device.” (Ex. 1016, p. 11.)

“need not be capable of communicating ‘when connected to the host device by the interface device.’” (Ex. 1016, p. 12.)

“data transmit/receive device” [claim 7]

Apple proposes to construe the term “data transmit/receive device” as “a

device capable of transmitting or receiving data.” This construction clarifies the

term is not limited to devices that both transmit and receive data—only one is

necessary under the broadest reasonable interpretation. This construction is

consistent with the plain and ordinary meaning of the term because the use of the “/”

3 Petitioner’s proposed claim constructions do not constitute an admission that

the claims are valid under 35 U.S.C. §112, and Petitioner reserves the right to

challenge the validity of the claims under §112 in other venues.


- 18 -

indicates alternatives. (See Ex. 1019, Websters, p. 2125 (defining “virgule” as “a

short oblique stroke (/) between two words indicating that whichever is appropriate

may be chosen to complete the sense of the text in which they occur”).) The

construction is also consistent with the specification, which discloses “a data

transmit/receive device which is to receive data from the host device or from which

data is to be read, i.e. acquired, and transferred to the host device.” (’746 patent,

5:2–4.) Moreover, the portion of the district court’s interpretation under Phillips v.

AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005) that the device “is capable of either (a)

transmitting data to or (b) transmitting data to and receiving data from the host

device” still stands after the Federal Circuit’s decision. (Ex. 1016, p. 11 (“the

parties’ dispute focuses on the ‘when connected’ portion of the court’s

construction”)).

V. Ground 1: The combination of Ard, Schmidt, and Webb renders claims 1, 6–8, 14, 20, 21, 30, and 34 obvious.4

A. Overview of Ard.

Ard identifies the same problem the ’746 patent purports to address:

“Typically, because peripherals are not standardized as to an interface protocol

between the peripheral and a host computer, one of the related software packages

4 A complete listing of challenged claims, including labels, is provided as

Appendix A.


- 19 -

that must be installed with a new peripheral device is a device driver.” (Ex. 1046,

Ard, 1:29–33.) Ard states that although “the installation of device drivers for a

specific peripheral device is not a particularly difficult problem, it is complicated by

a multitude of available peripheral devices, several available computer platforms

and related operating systems.” (Ard, 1:48–52.) To solve this problem, Ard

developed “a disk drive emulator attached to a peripheral device such that the

peripheral may be operated from a host computer as a disk drive without the need of

a device driver.” (Ard, 2:48–51.)

Ard discusses an image scanner as an example to illustrate its disk drive

emulator. (See Ard, 3:13–15.) Figure 5 of Ard (reproduced below) depicts this

illustrative disk drive emulating scanner. The disk drive emulating scanner couples

to a computer via a SCSI bus 4.


- 20 -

(Ard, Figure 5.) Ard’s scanner includes optics (e.g., CCD image sensor) that

acquires and generates analog signals from a plurality of independent imaging

pixels. (Ard, 6:7–10; Zadok Decl., ¶65.) The scanner digitizes the analog signals

resulting from the operation of the optics and stores the digitized signals as a file in

an image memory of the scanner. (Ard, 7:40–44.) The general purpose computer

interacts via SCSI bus 4 with the scanner “as if it is a disk drive” using “standard

disk drive commands” to read the file. (Ard, 2:60–61, 5:19–30, Figure 3.)

The system of Ard simplifies the installation of a peripheral device. The

installation process only requires a user to attach the disk drive emulating scanner to

the bus, turn the scanner on, and turn the computer on. (Ard, Figure 10, 8:51–54.)

Without any action by the user, the scanner automatically identifies itself as a disk


- 21 -

drive to the computer: “[w]hen attached to [the] SCSI bus... the disk drive emulating

scanner will be identified by [the] host computer as a disk drive, because the disk

drive emulator 41 provides electronic signals identical to those of a standard disk

drive.” (Ard, 8:54–58.) No additional steps are required to locate and install an

appropriate device driver on the computer. (Ard, 8:63–67.) Ard stresses its

installation “is far simpler than installation of a current industry standard peripheral

such as scanner 5 because additional steps are required for the current industry

standard including the location and installation of an appropriate device driver.”

(Ard, 8:63–67.)

B. Overview of Schmidt.

Schmidt provides details of the SCSI bus discussed in Ard “[a]lmost all

modern computers including PCs, workstations and mainframes are equipped with a

SCSI interface.” (Ex. 1007, Schmidt, End Cover.) Figure 9.1 of Schmidt,

reproduced below, illustrates “[a] simple SCSI configuration” where a host adapter

in a computer sends SCSI commands over a SCSI bus to a disk drive. (Schmidt, p.

80.)


- 22 -

One of the set of mandatory commands supported by a SCSI device is an

INQUIRY command that “requests that information regarding parameters of the

target and its attached peripheral device(s) be sent to the initiator.” (Schmidt, p. 88;

Zadok Decl., ¶68.) In response, a SCSI device provides, among other parameters, its

device class, which can include the disk drive class. (See Schmidt, p. 133, Table

12.1; see also p. 132.)


- 23 -

C. Overview of Webb.

Webb discloses details of the conversion of light to a digital signal in an

optical scanner such as the disk driver emulating scanner of Ard. (Zadok Decl., ¶

69.) Webb recognizes “various types of photosensor devices may be used in optical

scanners, [but] a commonly used sensor is the charge coupled device or CCD.” (Ex.

1048, Webb, 1:38–40.) Webb describes the operation of a CCD as “well known,”

stating “a CCD may comprise a large number of individual cells or ‘pixels,’ each of

which collects or builds-up an electrical charge in response to exposure to light.”

(Webb, 1:40–43.) The “CCD also includes an analog shift register to convert the

simultaneous or parallel data from the CCD cells into a sequential or serial data

stream.” (Webb, 1:51–55.) In Webb, “[t]he sequentially arranged charges from the

CCD cells may then be converted, one-by-one, into a digital signal by a suitable

analog-to-digital converter.” (Webb, 1:64–67.) Webb illustrates this “data sampling

and conversion circuit” in Figure 1 (reproduced below). (Webb, 3:57–59.)


- 24 -

D. The combination renders claim 1 obvious.

1. The combination discloses the “analog data acquisition device” recited in the preamble of claim 1 [1P].

The preamble of independent claim 1 recites the following two components:

[1P.1] An analog data acquisition device operatively

connectable to a computer through a multipurpose

interface of the computer,

[1P.2] the computer having [a] an operating system

programmed so that, when the computer [b] receives a

signal from the device through said multipurpose interface

of the computer indicative of a class of devices, the

computer [c] automatically activates a device driver

corresponding to the class of devices for allowing the


- 25 -

transfer of data between the device and the operating

system of the computer.

As set forth below, the combination of Ard, Schmidt, and Webb teaches or

suggests each of these components.

a) “analog data acquisition device”

Ard’s disk drive emulating scanner 6 is “[a]n analog data acquisition

device.” Scanner 6 acquires analog data via its “scanner optics 45, which includes,

for example, a Charge Coupled Device (CCD).” (Ard, 6:7–10; Zadok Decl., ¶71.)

Figure 3 of Ard has been annotated to highlight the mapping of the claim limitations

to the system. (Zadok Decl., ¶¶71–72.)


- 26 -

Ard’s scanner 6 is “operatively connectable to a computer” (general purpose

computer 2) through the SCSI card 17 via the SCSI bus 4. (Zadok Decl., ¶73.) Ard

does not describe the details of the SCSI bus or SCSI interface. Schmidt provides an

in-depth discussion of SCSI. A SCSI interface such as SCSI card 17 in the computer

of Ard is a “multi-purpose interface” because it is designed for use with multiple

devices that can have different functions from each other: “[t]he SCSI interface is a

device independent I/O bus, allowing a variety of devices to be linked to a computer

system using a single bus.” (Schmidt, p. 79; Zadok Decl., ¶73.) Thus, the

combination of Ard, Schmidt and Webb teaches an “analog data acquisition device

operatively connectable to a computer through a multipurpose interface of the

computer.”

b) Computer architecture/operation component

As Ard annotated Figure 3 illustrates, the general purpose computer 2

includes an operating system 7, thereby disclosing “the computer having an

operating system” [1P.2a]. (See Ard, 5:31–25; Zadok Decl., ¶74.)

The combination of Ard, Schmidt, and Webb teaches “the computer receives

a signal from the device through said multipurpose interface of the computer

indicative of a class of devices.” In Ard, “[w]hen attached to a SCSI bus…the disk

drive emulating scanner will be identified by a host computer as a disk drive,

because the disk drive emulator 41 provides electronic signals identical to those of a


- 27 -

standard disk drive.” (Ard, 8:54–58.) These signals communicated from the scanner

are “indicative of a class of devices”—the class of disk drives. (Zadok Decl., ¶74.)

Schmidt provides details of the signals used by SCSI disk drives, such as

Ard’s disk drive emulating scanner, to identify themselves as disk drives. In SCSI,

“[t]here are a number of commands that are common to all device types” and the

implementation of these commands “is mandatory.” (Schmidt, p. 138.) “INQUIRY”

is among these mandatory commands. (See Schmidt, p. 138, Table 12.10 (INQUIRY

command as Type “M”); p. 137, Table 12.8 (Type M commands as “Mandatory”

commands that “must be implemented”).) The SCSI INQUIRY command “can be

used to learn…the device type,” which is also called the “device class” or

“peripheral device type.” (Schmidt, p. 138; see also Table 12.12, pp. 139–40.)

Therefore, Ard’s process of misidentifying the scanner as a hard disk includes

receiving a SCSI INQUIRY from the general purpose computer.

Schmidt describes a device’s response to the INQUIRY command. (Schmidt,

pp. 139–41.) In response to an INQUIRY command, a SCSI device provides a

response including a five-bit “device class” or “peripheral device type.” (Schmidt,

pp. 139–40; see also p. 132 (“Table 12.1 shows an example of the data returned

from an INQUIRY command”).) As shown in Table 12.1, reproduced below, one

supported device class in SCSI is the “hard disk” class. (Schmidt, p. 133, Table

12.1.)


- 28 -

Ard’s scanner “emulates a disk drive” (Ard, Title) and “provides electronic

signals identical to those of a standard disk drive.” (Ard, 8:54–58.) Accordingly, it

would have been obvious to a POSITA that the general purpose computer 2 (“the

computer”) would receive a response to a SCSI INQUIRY command from the

scanner 6 indicating it is part of the disk drive class. (Zadok Decl., ¶77.) And, this

response would be provided over the SCSI bus through SCSI interface 17 (the

“multi-purpose interface”) of the general purpose computer. This response

constitutes the claimed “signal from the device through said multipurpose interface

of the computer indicative of a class of devices” [1P.2b]. (Id.)

The combination of Ard, Schmidt, and Webb also teaches or suggests that

when the general purpose computer receives the signal “the computer automatically

activates a device driver corresponding to the class of devices for allowing the

transfer of data between the device and the operating system of the computer.” As a


- 29 -

result of receiving the electronic signals provided by the scanner, the Ard disk drive

emulating scanner “will be identified by a host computer as a disk drive.” (Ard,

8:54–58.)

As a result of this identification, a POSITA would recognize the host

“automatically activates a device driver corresponding to the class of devices” (hard

disks). Ard stresses its installation process “is far simpler than installation of a

current industry standard peripheral. (Ard, 8:63–67.) The result of the installation

process of Ard is the activation of the SCSI device driver for the hard disk class.

(Zadok Decl., ¶79.) Ard uses the SCSI driver to “allow[] the transfer of data”:

“image data resulting from operation of the scanner optics 45 is directed by disk

drive emulator 41 to the memory 47 where the image data is stored as a file

accessible to the general purpose computer 2.” (Ard, 7:36–44.) Ard’s scanner

transfers the image filed to the computer: “Once saved as a file, the image data is

accessible to any application capable of reading image data.” (Ard, 7:57–58.)

Specifically, the image data is read by “opening [the] file” using “standard disk

drive commands” like “Open File.” (Ard, Figure 8, step 109, 5:25–30.) “The Open

File command directs the operating system to read a file stored on a storage device

and provide the data contained therein to the software application invoking the

command.” (Ard, 5:34–37.) And, this transfer is between the scanner and the

operating system of the general purpose computer: “the scanner parameters setup


- 30 -

program 11 and the graphics application 9 communicate with the disk drive

emulating scanner 6 via the SCSI driver 13, the operating system 7….” (Ard, 5:25–

31.)

2. The combination discloses the analog data acquisition device architectural limitations.

Independent claim 1 recites three architectural elements of the analog data

acquisition device: [1A] (1) a program memory, [1B] (2) an analog signal

acquisition channel for receiving a signal from an analog source, and [1C] (3) a

processor operatively interfaced with the multipurpose interface of the computer,

the program memory and a data storage memory when the analog data acquisition

device is operational. The combination teaches or suggests each of these

architectural elements.

a) “program memory” [1A]

As shown in Figure 5 (reproduced below), the disk driver scanner includes a

memory 47 having a setup program storage area 47A and a firmware storage area

47B. Setup program storage area 47A stores a “scanners parameters setup program”

through which scanner parameters and scanner commands can be entered. (Ard,

5:41–46, 5:58–59.) Firmware storage area 47B stores “a set of firmware

instructions” used in operating the scanner optics 45 of scanner 6. (Ard, 6:10–14.)

Thus, both storage areas 47A and 47B store “programs” and correspond to the


- 31 -

recited “program memory.” (Zadok Decl., ¶83.)

b) “an analog signal acquisition channel for receiving a signal from an analog source” [1B]

The scanner optics of Ard’s scanner include “a Charge Coupled Device

(CCD).” (Ard, 6:7–10.) A POSITA would have understood a CCD is an “analog

source.” (Zadok Decl., ¶85.) Figure 1 of Webb, annotated below, illustrates “a

schematic diagram of a data sampling and conversion circuit for…a CCD” such as

included in Ard’s scanner optics. (Webb, 3:56–58.)


- 32 -

Webb describes the “well-known” structure of a CCD:

As is well-known, CCD 14 includes n charge transfer

buckets Q1, Q2, Q3, through Qn, which sequentially

transfer the charges that were simultaneously collected

from each of the individual pixels in the CCD. A charge-

to-voltage converter 18 connected to the last charge

transfer bucket Q1 of CCD 14 converts the charge stored in

the last bucket Q1 into a voltage, which voltage is then

converted into a digital signal by an analog to digital

(A/D) converter 22.

(Webb, 4:6–14.) Because the input of the A/D converter 22 is analog, a POSITA

would have recognized the CCD is an “analog source.” (Zadok Decl., ¶85.) A

POSITA would further understand the path between the row of the CCD array 14


- 33 -

and the A/D converter 22 is “an analog signal acquisition channel for receiving a

signal from an analog source” because the analog data from the row of the CCD

array traverses this path before being received by the A/D converter which produces

the digital image data. (Id.)

c) The “processor” limitation [1C]

The combination of Ard, Schmidt, and Webb teaches or suggests the analog

data acquisition device includes “a processor operatively interfaced with the

multipurpose interface of the computer, the program memory, and a data storage

memory when the analog data acquisition device is operational” as recited in claim

1.

Ard’s disk drive emulator 41 receives and processes commands from

computer 2, and therefore constitutes the “processor.” In a first example, disk drive

emulator 41 processes an Open File command for the scanner parameters setup

program by performing a retrieval and a transfer: “the disk drive emulator 41

retrieves the scanner parameters setup program 11 from setup program storage area

47A and transfers the scanner parameters setup program 11 via the SCSI bus 4 to

the general purpose computer 2 for execution.” (Ard, 5:60–66.) In another example,

in response to a “Save File” from computer 2, the disk drive emulator 41 “saves the

scanner parameters 33 to a file in the memory 47” by retrieving the scanner

parameters 33 from the scanner parameters setup program 11. (Ard, 6:42–43; see


- 34 -

also 5:66–6:3.) Then, upon receiving “a File Open command from the SCSI bus 4

directed toward opening [the] file stored in the memory 47 containing the scanner

parameters 33,” the disk drive emulator 41 performs that process of “retriev[ing] the

file, and transfer[ing] the scanner parameters 33 contained therein to the scanner

control block 43.” (Ard, 6:49–54.) The scanner is operated in accordance with the

scanner parameters 33, and “the image data resulting from operation of the scanner

optics 45 is directed by disk drive emulator 41 to the memory 47 where the image

data is stored as a file accessible to the general purpose computer 2.” (Ard, 6:54–56,

7:41–44.) Thus, disk drive emulator 41 is a “processor” of disk drive emulating

scanner 6.

Figure 5 illustrates disk drive emulator 41 (“processor”) operatively

interfaces with the SCSI card 17 (“multipurpose interface of the computer”), storage

areas 47A and 47B (“program memory”), and the file storage area of memory 47

(“data storage memory”).


- 35 -

For example, the “disk drive emulator 41 receives Open File or Save File

commands sent from the general purpose computer 2 over the SCSI bus 4” which

connects scanner 6 to the SCSI card 17 of computer 2 (“multipurpose interface of

the computer”). Also, disk drive emulator 41 operatively interfaces with storage area

47A to retrieve the scanner parameters setup program 11, and with memory 47 to

store image data as a file in memory 47. (Zadok Decl., ¶91.)

In addition to storing “programs” in storage areas 47A and 47B, memory 47

stores image data files resulting from operating scanner 6. For example, Ard

discloses “image data resulting from operation of the disk drive emulating scanner 6

is directed to and saved as a file” residing “in the memory 47.” (Ard, 7:55–57, 7:62–

64.) Accordingly, memory 47 includes the recited “data storage memory.” (Zadok


- 36 -

Decl., ¶92.) And, Ard’s processor is “operatively interfaced with…a data storage

memory.” (Id.)

It would have been obvious to a POSITA the processor of Ard is “operatively

interfaced…when the analog data acquisition device is operational” because such

interfacing—which allows the acquisition, processing, saving, and transferring of

data—is part of what makes the measurement device operational. (Zadok Decl.,

¶93.) Indeed, the installation process of Ard requires the scanner and computer be

attached to the SCSI bus and turned on. (Ard, Figure 10.) Ard never discloses—or

has any reason to disclose—non-operational configurations. (Zadok Decl., ¶93; see,

e.g., Ard, 7:19–22 (“the disk drive emulator 41 operates the disk drive emulating

scanner 6 based on the parameters written to disk drive emulator 41 and

corresponding to the File Open command”) (emphasis added).)

3. The combination discloses the “data generation process” limitations [1D].

Independent claim 1 includes three data generation and processing [1D]

components:

[1D.1] wherein the processor is configured and

programmed to implement a data generation process by

which analog data is acquired from the analog signal

acquisition channel,

[1D.2] the analog data is processed and digitized, and


- 37 -

[1D.3] the processed and digitized analog data is stored in

a file system of the data storage memory as at least one

file of digitized analog data.

The combination teaches or suggests each of these data generation and

processing components.

a) “data generation process” [1D.1]

Ard discloses a “data generation process by which analog data is acquired

from the analog signal acquisition channel.” As established above, the combination

of Ard, Schmidt, and Webb discloses the scanner acquires analog image data from

the analog-to-digital converter via an “analog signal acquisition channel.” (Zadok

Decl., ¶95.) The process of scanning an image therefore constitutes the recited “data

generation process.” (Id.)

Ard teaches that “the disk drive emulator 41 operates the disk drive emulating

scanner 6 based on the parameters written to disk drive emulator 41 and

corresponding to the File Open command in step 67.” (Ard, 7:19–22.) The

parameters therefore “configure[]” the disk drive emulator 41 to implement the

scanning process. (Zadok Decl., ¶96.) Moreover, based on Ard’s disclosure the disk

drive emulator 41 “operates the…scanner,” and the understanding that the disk drive

emulator is a processor, it would have been obvious to a POSITA the disk drive

emulator 41 (“processor”) is “configured and programmed to implement” the


- 38 -

scanning process (“data generation process”). (Id.)

b) “analog data is processed and digitized” [1D.2]

The combination of Ard, Schmidt, and Webb teaches the “analog data is

processed and digitized” in the data acquisition process. Specifically, the analog

image data is collected into “charge transfer buckets…which sequentially transfer

the charges that were simultaneously collected from each of the individual pixels in

the CCD.” (Webb, 4:6–9.) The signal is then converted from a charge to a voltage

by “charge-to-voltage converter 18.” (Webb, 4:9–12.) The resulting analog voltage

signal passed through a hold circuit 20 “to act as a buffer.” (See Webb, 4:19–22.)

Accordingly, the “analog data is processed.”

The analog data obtained from the CCD is then passed to the A-to-D

converter for digitization. (See Webb, Figure 1, 4:12–14.) This converter would

digitize the analog data according to its conventional purposes. (Zadok Decl., ¶97.)

Thus, the “analog data is processed and digitized.”

c) “file system” [1D.3]

Image data corresponding to digitized analog data results from the scanning

operation. (Ard, 7:22–23.) Specifically, Ard states “image data resulting from

operation of the scanner optics 45 is directed by disk drive emulator 41 to the

memory 47 where the image data is stored as a file accessible to the general purpose

computer 2.” (Ard, 7:41–44.) It would have been obvious to a POSITA to store the


- 39 -

resulting file “in a file system” because file storage and retrieval was the main

purpose of file systems. (Zadok Decl., ¶98.) Furthermore, memory 47 constitutes

“data storage memory,” as shown above in Section 2, because it stores data. (See

Ard, 7:41–44.)

4. The combination discloses claim limitation [1E].

Independent claim 1 further includes three device recognition limitations:

e) [1E.1] wherein when the analog acquisition device is

operatively interfaced with the multipurpose interface of

the computer, the processor executes at least one

instruction set stored in the program memory and

[1E.2] thereby automatically causes at least one

parameter indicative of the class of devices to be sent to

the computer through the multipurpose interface of the

computer,

[1E.3] independent of the analog source, wherein the

analog data acquisition device is not within the class of

devices.

The combination teaches or suggests each of these device recognition limitations.

a) “parameter indicative of the class of devices” [1E.2]

The combination of Ard and Schmidt teaches or suggests that when the

scanner of Ard is operatively interfaced with the SCSI card 17 of the computer, the

disk drive emulator (“processor”) “automatically causes at least one parameter


- 40 -

indicative of the class of devices to be sent to the computer.” The system of Ard

simplifies the installation of a peripheral device. Specifically, as illustrated in Figure

10 below, the installation process only requires three actions by the user: attaching

the scanner 6 to computer 2 via SCSI bus 4, turning on the scanner 6, and turning on

computer 2. (Ard, Figure 10, 8:51–54.) The attaching of scanner 6 to computer 2 via

SCSU bus 4 operatively interfaces the scanner (“analog acquisition device”) with

the SCSI card 17 (“multipurpose interface of the computer”).

As discussed above relative to the preamble, Ard discloses that, “[w]hen

attached to a SCSI bus…the disk drive emulating scanner will be identified by a

host computer as a disk drive, because the disk drive emulator 41 provides

electronic signals identical to those of a standard disk drive.” (Ard, 8:54–58.) A

POSITA would recognize the electronic signals of Ard include “at least one


- 41 -

parameter indicative of the class of devices”—the class of disk drives. (Zadok Decl.,

¶101.)

Schmidt discloses the signals used by SCSI disk drives to identify themselves

as disk drives. In SCSI, “[t]here are a number of commands that are common to all

device types” and the implementation of these commands “is mandatory.” (Schmidt,

p. 138.) “INQUIRY” is among these mandatory commands. (See Schmidt, p. 138,

Table 12.10 (INQUIRY command as Type “M”); p. 137, Table 12.8 (Type M

commands as “Mandatory” commands that “must be implemented”).) The SCSI

INQUIRY command “can be used to learn…the device type,” which is also called

the “device class” or “peripheral device type.” (Schmidt, p. 138; see also Table

12.12, pp. 139–40.) Therefore, part of Ard’s process of misidentifying the scanner

as a hard disk would be to receive a SCSI INQUIRY from the general purpose

computer. (Zadok Decl., ¶102.) Schmidt supports this understanding, explaining that

the host SCSI adapter sends SCSI commands to devices such as Ard’s scanner. (See

Schmidt, p. 80, Figure 9.1.)

Schmidt provides detail about a device’s response to the INQUIRY

command. (Schmidt, pp. 139–41.) In response to an INQUIRY command, a SCSI

device provides a response including a five-bit “device class” or “peripheral device

type.” (Schmidt, pp. 139–40; see also p. 132 (“Table 12.1 shows an example of the

data returned from an INQUIRY command”).) Table 12.1, reproduced below,


- 42 -

shows one supported device class in SCSI is the “hard disk” class. (Schmidt, p. 133,

Table 12.1.)

Ard discloses that its scanner “emulates a disk drive” (Ard, Title) and

“provides electronic signals identical to those of a standard disk drive.” (Ard, 8:54–

58.) Accordingly, it would have been obvious to a POSITA that the scanner would

send a response to a SCSI INQUIRY command from the scanner 6 indicating the

scanner 6 is part of the disk drive class. (Zadok Decl., ¶104.) And, as discussed

above, the disk drive emulator would include a SCSI controller to interface with the

general purpose computer using SCSI commands. (See Ard, Figure 5; Schmidt,

Figure 9.1.) Thus, the disk drive emulator would “automatically cause” the response

to the SCSI INQUIRY command indicating the class of devices, and therefore

“automatically causes at least one parameter indicative of the class of devices to be


- 43 -

sent to the computer through the multipurpose interface of the computer.” (Zadok

Decl., ¶104.)

b) “the processor executes at least one instruction set” [1E.1]

As noted above, the disk drive emulator 41 (“the processor”) of scanner 6 is

involved in the process that “automatically causes at least one parameter indicative

of the class of devices to be sent to the computer.” Specifically, disk drive emulator

sends the “electronic signals identical to those of a standard disk drive.” (Ard, 8:57–

58.) Ard does not explicitly disclose “the processor executes at least one instruction

set stored in the program memory” to cause the “at least one parameter” to be sent

from scanner 6 to computer 2 during Ard’s installation process. However, a

POSITA would have appreciated that disk drive emulator 41 “executes at least one

instruction set” to cause the electronic signals to be sent to the host computer.

(Zadok Decl., ¶105.) Additionally, a POSITA would have further found it obvious

to store the “at least one instruction” in “program memory” such as setup program

storage area 47A or firmware storage area 47B because storing processor

instructions in a memory was a well-known implementation as of the PCT date.

(Zadok Decl., ¶105.)

c) “not within the class of devices” [1E.3].

In the combination, Ard’s scanner identifies itself as a hard disk despite the

inclusion of a specific SCSI device class for scanners, as shown above in Figure


- 44 -

12.1 of Schmidt. Accordingly, the “parameter” sent by the combination of Ard and

Schmidt would be “independent of the analog source.” Additionally, the scanner

(“analog acquisition device”) “is not within the class of devices” (hard disk drives).


5. The combination discloses claim element [1F].

Independent claim 1 further includes three file transfer limitations

[1F.1] wherein the processor is further configured and

programmed to execute at least one other instruction set

stored in the program memory to

[1F.2] thereby allow the at least one file of digitized

analog data acquired from the analog signal acquisition

channel to be transferred to the computer using the device

driver corresponding to said class of devices

[1F.3] so that the analog data acquisition device appears

to the computer as if it were a device of the class of

devices.

The combination teaches or suggests each of these device recognition limitations.

a) file transfer process [1F.2]

Ard discloses a file transfer process in which “at least one file of digitized

analog data acquired from the analog acquisition channel [is] transferred to the

computer using the device driver corresponding to said class of devices.” As


- 45 -

discussed above, scanner 6 sends electronic signals misidentifying itself as a hard

disk to computer 2 during installation. (Ard, 8:54–58.)

Subsequently, scanner 6 can be operated to scan an image and generate image

data, which is saved as a file in memory 47 of Ard’s scanner: “image data resulting

from operation of the scanner optics 45 is directed by disk drive emulator 41 to the

memory 47 where the image data is stored as a file accessible to the general purpose

computer 2.” (Ard, 7:36–44.) Ard’s scanner transfers the image file to the computer

“using the device driver corresponding to said class of devices”: “Once saved as a

file, the image data is accessible to any application capable of reading image data.”

(Ard, 7:57–58.) Specifically, the image data is read by “opening [the] file” using

“standard disk drive commands” like “Open File.” (Ard, Figure 8, step 109, 5:25–

30.) “The Open File command directs the operating system to read a file stored on a

storage device and provide the data contained therein to the software application

invoking the command.” (Ard, 5:34–37.) This command is received and handled by

the disk drive emulator (the recited “processor”). (Ard, 2:64–67 (“The disk drive

emulator translates Open File and Save File commands received from the host

computer”).) Thus, Ard discloses “the processor is further configured…to thereby

allow the at least one file of digitized analog data acquired from the analog signal

acquisition channel to be transferred to the computer.” (Zadok Decl., ¶110.)

Furthermore, the transfer is performed “using the device driver corresponding to


- 46 -

said class of devices”—the SCSI driver 13. (Ard, 5:25–30 (“the graphics application

9 communicate[s] with the disk drive emulating scanner 6 via the SCSI driver

13…”); see also Figure 3.)

b) “at least one other instruction set” [1F.1]

Ard does not explicitly disclose “the processor is…programmed to execute at

least one other instruction set stored in the program memory” to allow the file

transfer. As shown above, a POSITA would have appreciated that disk drive

emulator 41 “executes at least one instruction set stored in the program memory” to

cause the file transfer to the host computer. (Zadok Decl., ¶111.) A POSITA would

have further found it obvious to store the “at least one instruction” in “program

memory” such as setup program storage area 47A or firmware storage area 47B

because storing processor instructions in a memory was a well-known

implementation as of the ’746 PCT application date. (Id.)

c) appearance of the device as part of the class of devices [1F.3]

The file transfer process discussed in the previous section results in “the

analog data acquisition device appear[ing] to the computer as if it were a device of

the class of devices.” (Zadok Decl., ¶112.) Specifically, the operation of disk drive

emulator 41 makes the disk drive emulating scanner 6 appear as a disk drive

“because the disk drive emulator 41 provides electronic signals identical to those of

a standard disk drive.” (Ard, 8:54–58; Zadok Decl., ¶112; see also Ard, Figure 5,


- 47 -

2:59–61 (“Because the peripheral device has an attached disk drive emulator, the

host computer interacts with the peripheral device as if it is a disk drive”).)

6. The combination discloses claim limitation [1G].

Claim 1 requires that the processor causes the file transfer to occur “without

requiring any user-loaded file transfer enabling software to be loaded on or

installed in the computer at any time” [1G.4]. To transfer a file from Ard’s disk

drive emulating scanner 6, computer 2 uses the standard “Open File” disk drive

command. (Ard, Figure 8, step 109, 5:25–30, 5:31–37; Zadok Decl., ¶113.) “The

Open File command directs the operating system to read a file stored on a storage

device and provide the data contained therein to the software application invoking

the command.” (Ard, 5:34–37.)

Further, “any application capable of reading image data” can access the file

stored on scanner 6 using the “Open File” command. (Ard, 7:57–59, Figure 8.) As

of the ’746 PCT application date (March 1998), Ard disclosed “[a]ny application

capable of reading image data” included applications that did not require installation

on the computer of any “user-loaded file transfer enabling software.” (Zadok Decl.,

¶114.) Indeed, from at least the 1980s, computer systems shipped with

manufacturer-installed graphics applications. (Id.) These applications supported the

“Open File” command described in Ard. (Id.) For example, the Microsoft Paint

graphics program was included with Microsoft Windows in the 1980s. (Id.)


- 48 -

Similarly, MacPaint was included with Apple O/S from 1988. (Id, ¶¶114–115; see

also Ex. 1057.) Both Microsoft Paint and MacPaint supported the “Open File”

command. (Zadok Decl., ¶¶114–115.) Thus, the file transfer operation in Ard does

not require “any user-loaded file transfer enabling software to be loaded on or

installed in the computer at any time.” (Id., ¶116.)

Further, Ard discloses that files on scanner 6 can be accessed “via a link to an

icon displayed on a Program Manager.” (Ard, 6:67–7:1.) Program Manager is the

name of the graphical user interface shell of Windows 3.x operating systems.

(Zadok Decl., ¶¶117–118.) Thus, in Ard, the “Open File” command can be invoked

from a software application as well as directly from operating system software. (Id.,

¶119.) It would have been obvious to a POSITA, in light of Ard’s teachings, to use

an operating system program like Program Manager to access the data image file on

scanner 6 because Ard teaches that the scanner setup parameters program, another

file stored in scanner 6, can be accessed in this fashion. (Id.) The Program Manager

was conventionally used to access files stored on storage devices. (Id., ¶¶117–119.)

Under this additional file access approach, file transfer from scanner 6 also does not

require “any user-loaded file transfer enabling software to be loaded on or installed

in the computer at any time.” (Id., ¶119.)


- 49 -

E. The combination renders claim 6 obvious.

Ard teaches or suggests “the processor is adapted to be interfaced with the

multipurpose interface of an external computing device by means of a cable.” Ard’s

scanner 6 interfaces with SCSI card 17 (“multipurpose interface”) of computer 2

(“an external computing device”) via a SCSI bus 4. (Ard, Figure 3.) Ard discloses

that connection of scanner 6 to computer 2 occurs by means of a “connecting cable.”

(Ard 4:33–35; Zadok Decl., ¶120.) Further, cables were a conventional means for

connecting SCSI peripherals such as Ard’s scanner to a host computer. (Zadok

Decl., ¶120.) For example, the cover of Schmidt, which is titled “The SCSI Bus and

IDE Interface,” illustrates a number of cables. (Schmidt, Cover.)

Figure 5 of Ard further illustrates the SCSI bus 4 interacts directly with the

disk drive emulator 41 (“processor”). (Ard, Figure 5.) Thus, the combination of

Ard, Schmidt, and Webb teaches or suggests “the processor is adapted to be

interfaced with the multipurpose interface of an external computing device by means

of a cable.” (Zadok Decl., ¶120.)

F. The combination renders claim 7 obvious.

The combination teaches or suggests “the analog source comprises a data

transmit/receive device.” Ard’s CCD (“analog source”) comprises a data

transmit/receive device because it is a device that transmits data. (Zadok Decl.,

¶121.) Ard does not provide details of its CCD. Webb provides these details.


- 50 -

Describing the “well-known” operation of a CCD, Webb states that “charge transfer

buckets…sequentially transfer the charges that were simultaneously collected from

each of the individual pixels in the CCD,” the charge is converted to a voltage which

“is then converted into a digital signal by an analog to digital (A/D) converter.”

(Webb, 4:6–14.) It therefore would have been obvious to a POSITA that a CCD

“comprises a data transmit/receive device.” (Zadok Decl., ¶121.)

G. The combination renders claim 8 obvious.

The combination teaches or suggests “the analog source is designed for one

of one-way and two-way communication with the host device.”

Ard’s CCD (“analog source”) is designed for one-way communication.

(Zadok Decl., ¶123.) Webb discloses it “is well-known[] [that] CCD 14 includes n

charge transfer buckets Q1, Q2, Q3, through Qn, which sequentially transfer the

charges that were simultaneously collected from each of the individual pixels in the

CCD.” (Webb, 4:6–9.) After converting the charge to a voltage, the “voltage is then

converted into a digital signal by an analog to digital (A/D) converter 22.” (Webb,

4:9–14.) That is, the flow of analog data is from the CCD to the A/D converter in

Figure 1, reproduced below. (Zadok Decl., ¶123.)


- 51 -

H. The combination renders claim 14 obvious.

The combination teaches or suggests “the analog source includes at least first

and second transducers both of which are designed to transmit data.” Ard discloses

that scanner optics 45 includes a CCD, as shown above for claims 1, 7, and 8. A

POSITA would have understood that, “[a]s is well-known, a CCD may comprise a

large number of individual cells or ‘pixels,’ each of which collects or builds-up an

electrical charge in response to exposure to light.” (Webb, 1:40–43.) Each CCD

pixel constitutes a transducer designed to transmit analog data to its corresponding

transfer buckets. (Zadok Decl., ¶124 (citing Webb, 4:6–9) (“As is well-known, CCD

14 includes 11 charge transfer buckets Q1, Q2, Q3, through Q, which sequentially

transfer the charges that were simultaneously collected from each of the individual


- 52 -

pixels in the CCD.”).) Thus, it would have been obvious to a POSITA that Ard’s

CCD would include multiple CCD pixels (“at least first and second transducers”)

that “are designed to transmit data” to an transfer bucket and then to an A/D

converter. (Zadok Decl., ¶124.)

I. The combination renders claim 20 obvious.

The combination teaches or suggests “the processor is configured to initiate a

process by which the at least one file of digitized analog data is directly transferred

to an input/output device.” As shown above for claim 1, the combination of Ard,

Schmidt, and Webb discloses “wherein the processor is configured and

programmed to implement a data generation process by which analog data is

acquired from the analog signal acquisition channel, the analog data is processed

and digitized, and the processed and digitized analog data is stored in a file system

of the data storage memory as at least one file of digitized analog data.” Ard

discloses its memory 47 “may be implemented using any desired semiconductor

memory and/or as a disk drive.” (Ard, 7:38–40.) A disk drive is an “input/output

device” as recited in claim 20 of the ’746 patent. (Zadok Decl., ¶126.) Accordingly,

Ard discloses “a process by which the at least one file of digitized analog data is

directly transferred to an input/output device.” (Id.)

Claim 20 does not require the memory and input/output device be distinct

components of the analog data acquisition device. Nevertheless, even if it had such a


- 53 -

requirement, the claim would be obvious over the combination of Ard and Schmidt.

Ard discloses “image data resulting from operation of the disk drive emulating

scanner 6 is directed to and saved as a file.” (Ard, 7:55–57.) In one embodiment,

“the image data is directed to a file on the disk drive 23.” (Ard, 7:60–62.) This

embodiment is illustrated in Figure 7, which illustrates “a disk drive 23 [that] is

utilized to store image data generated from scan operations of the disk drive

emulating scanner 6.” (Ard, 7:26–28.) The disk drive 23 can also be “housed within

the disk drive emulating scanner 6.” (Ard, 7:33–35.)


- 54 -

The above analysis for claim 1 relied on Ard’s “alternative embodiment”

where the file is stored in a large memory to save storage files. (Ard, 7:62–64.) It

would have been obvious to a POSITA to combine that embodiment with the hard

disk embodiment illustrated in Figure 7 to provide the advantages of both

embodiments: large storage for files stored in the hard drive and faster access for

files stored in the memory. (Zadok Decl., ¶128.) Ard expressly shows the scanner

includes memory 47 even in the hard drive embodiment. (Ard, Figure 7.) Ard states

image data can be stored in memory 47 if there is “enough storage in memory 47.”

(Ard, 7:36–40.) It therefore would have been obvious to a POSITA to store image

data files in memory 47 until there was no longer “enough storage in memory 47”

(Ard, 7:36–40), at which point older image data files in memory 47 would be moved

to hard disk 23 for longer term storage. (Zadok Decl., ¶128.) Such a combination

discloses “a process by which the at least one file of digitized analog data is directly

transferred to an input/output device.” (Id.) Note that “the at least one file of

digitized analog data” must be “stored in a file system of the data storage memory”

per claim 1, and thus such storage cannot be precluded by the “directly transferred”

limitation of claim 20.

In either embodiment—whether the memory 47 is implemented as a hard

disk, or hard disk 23 is provided in addition to memory 47—it would have been

obvious to a POSITA for “the processor [to be] configured to initiate [the] process”


- 55 -

described above. (Zadok Decl., ¶129.) For the first embodiment, Ard teaches “image

data resulting from operation of the scanner optics 45 is directed by disk drive

emulator 41 to the memory 47 where the image data is stored as a file accessible to

the general purpose computer 2.” (Ard, 7:40–44.) Ard provides a nearly identical

disclosure for the second embodiment: “image data resulting from that operation is

directed by the disk drive emulator 41 to the disk drive 23 for storage in a file.”

(Ard, 7:28–31.) In either case, the disk drive emulator 41 (the recited “processor”)

directs the image data to storage. (Zadok Decl., ¶129.)

J. The combination renders claim 21 obvious.

The combination teaches or suggests that “the processor is configured to

allow a mode of operation of the analog data acquisition device other than the

transfer of at least some of the at least one file of digitized analog data to the

multipurpose interface to be controlled by means of an external personal computer.”

Ard discloses that the general purpose computer 2 (i.e., “an external personal

computer”) can control an upgrade of the contents of setup program storage area

47A. (See Ard, 6:21–25.) Specifically, “the setup program storage area 47A is

constructed from flash memory.” (Ard, 6:20–21.) Such a design allows “the contents

of the memory (i.e., the scanner parameters setup program 11, or applicable API)

[to] be upgraded via the general purpose computer 2.” (Ard, 6:21–25.) This upgrade

is “a mode of operation of the analog data acquisition device other than the transfer


- 56 -

of at least some of the at least one file of digitized analog data to the multipurpose

interface” because no portion of the digitized analog data file would be transferred

during such an upgrade. (Zadok Decl., ¶130.) It would have been obvious to a

POSITA that “the processor is configured to allow” this mode of operation because

the disk drive emulator (the recited “processor”) is situated between the SCSI

interface to the computer and the memory. (See Ard, Figure 5.)

K. The combination renders claim 30 obvious.

The combination teaches or suggests that “the device driver is installed with

the operating system such that communication between the computer and the analog

data acquisition device takes place by means of a device driver program which is

matched to the multi-purpose interface of the computer rendering the analog data

acquisition device host device independent.” The SCSI driver 13 of computer 2 is a

component of operating system 7. (See Ard, Figure 3 below.)


- 57 -

Ard suggests that the SCSI driver is “installed with the operating system.” (Zadok

Decl., ¶¶131–133.) As discussed above, Ard’s installation process merely requires a

user to attach the scanner to the SCSI bus and turn on the computer and scanner. No

additional user actions are required. And, Ard specifically eschews installation of a

driver, stating that its system “solves the problem in the prior art relating to locating

and installing an appropriate driver for a peripheral device.” (Ard, 5:19–21.)

In Ard, “the scanner parameters setup program 11 and the graphics

application 9 communicate with the disk drive emulating scanner 6 via the SCSI

driver 13…using standard disk drive commands Open File and Save File” (Ard,


- 58 -

5:25–30 (emphasis added)) and therefore “communication between the computer

and the analog data acquisition device takes place by means of” SCSI driver 13.

(Zadok Decl., ¶134.) To the extent that the recited “device driver program” is

construed to be distinct from the driver itself, the ’746 patent teaches that “driver

programs [] are normally optimized and included by the manufacturers of multi-

purpose interfaces” (’746 patent, 7:56–58), and therefore it would have been

obvious to include such a program along with SCSI driver 13 and the SCSI

interface. (Zadok Decl., ¶134.) Moreover, the SCSI driver 13 and associated “driver

program” would be “matched to the multi-purpose interface of the computer”

because they provide an interface and controller for SCSI card 17. (Id.) Because

“[b]oth Open File and Save File commands are standardized commands that can be

invoked by software applications executing in a computer environment based on any

standardized operating system” (Ard, 5:31–34), the configuration “render[s] the

analog data acquisition device host device independent.” (Zadok Decl., ¶134 (citing

Schmidt, p. 84 (“the goal of a device independent software interface was reached

with SCSI-2”).)

L. The combination renders independent claim 34 obvious.

Independent claim 34 shares overlapping claim limitations with independent

claim 1. The following section highlights differences between the independent


- 59 -

claims and demonstrates that the combination renders independent claim 34

obvious.

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].

As shown above for claim limitations [1P] and [1D], the combination of Ard

and Schmidt teaches “[a]n analog data acquisition device operatively connectable

to a computer through a multipurpose interface of the computer” where the analog

data acquisition device implements a “process by which analog data is acquired,”

thus also teaching a “method for analog data acquisition and interfacing to a host

device” [34P]. (See Ard, 6:7–10, 7:19–22; Schmidt p. 79.) Further, as discussed

above for limitation [1P] that requires “the computer automatically actives a device

driver,” Ard’s computer includes a SCSI driver (“device driver”). (Ard, 8:54–58.)

Thus, the combination also teaches the “host device includes a device driver.”

2. The combination discloses the “interfacing” step of claim 34 [34A].

Claim 34 further recites the following architectural limitation:

[34A] operatively interfacing a data acquisition device,

including a processor and a memory, with a multi-purpose

interface of the host device.


- 60 -

This limitation is substantially similar to a portion of limitation [1P] that recites “an

analog data acquisition device operatively connectable to a computer through a

multipurpose interface of the computer.” Thus, for the reasons discussed in Section

V(D)(1), the combination also teaches “operatively interfacing a data acquisition

device…with a multi-purpose interface of the host device” [34A]. (See Ard, Figure

3; Schmidt, p. 79.) And, as established above for claim limitations [1A] and [1C],

the analog acquisition device comprises “a program memory” and “a processor.”

(See Ard, Figure 5.) Accordingly, the combination of Ard, Schmidt, and Webb

discloses “operatively interfacing a data acquisition device, including a processor

and a memory, with a multi-purpose interface of the host device.”

3. The combination discloses the “acquiring” step of claim 34 [34B].

Claim 34 further recites the following acquisition and processing limitation:

[34B] acquiring analog data from an analog source,

processing and digitizing the analog data, and storing the

processed and digitized analog data in the memory as

digitized analog data under control of the processor.

The acquisition and processing limitation of claim 34 is substantially the

same as limitation [1D] that recites: “wherein the processor is configured and

programmed to implement a data generation process by which analog data is

acquired from the analog signal acquisition channel, the analog data is processed


- 61 -

and digitized, and the processed and digitized analog data is stored in a file system

of the data storage memory as at least one file of digitized analog data.” For the

reasons discussed in Section V(D)(3), the combination of Ard, Schmidt, and Webb

also teaches or suggests “acquiring analog data from an analog source, processing

and digitizing the analog data, and storing the processed and digitized analog data

in the memory as digitized analog data under control of the processor.” (See Webb,

Figure 1, 4:6–22; Ard, Figure 5.)

4. The combination discloses the “sending” step of claim 34 [34C].

Although worded slightly differently, the subject matter of claim limitation

[34C] is substantively similar to limitation [1E], discussed above in Section

V(D)(4). The following table highlights the similarities between the claims:

Claim limitation [1E] Claim limitation [34C]

…the processor executes at least one

instruction set stored in the program

memory and thereby automatically

causes at least one parameter

indicative of the class of devices to be

sent to the computer through the

multipurpose interface of the

computer, independent of the analog

source, wherein the analog data

automatically sending under control of

the processor at least one parameter to

the multi-purpose interface of the host

device, the at least one parameter

identifying the analog data acquisition

device as a digital device instead of as an

analog data acquisition device,

regardless of the analog source


- 62 -

acquisition device is not within the class

of devices

As explained above in relation to claim 1, the combination automatically sends a

response to an INQUIRY command indicative of and identifying itself as the hard

disk class in the SCSI standard. A POSITA would have understood that hard disks

are “digital device[s].” Accordingly, the combination of Ard, Schmidt, and Webb

teaches or suggests claim limitation [34C]. (Zadok Decl., ¶142.)

5. The combination discloses the “transferring” step of claim 34 [34D].

Although worded slightly differently, the subject matter of claim limitation

[34D] is substantively similar to limitation [1F], discussed above in Section

V(D)(5). The following table highlights the similarities between the claims:

Claim limitations [1F] and [1G] Claim limitation [34D]

wherein the processor is further

configured and programmed to execute

at least one other instruction set stored in

the program memory to thereby allow

the at least one file of digitized analog

data acquired from the analog signal

acquisition channel to be transferred

to the computer using the device

driver corresponding to said class of

devices so that the analog data

automatically transferring data from

the analog source to the host device in

response to a digital data read command

from the host device, in a manner that

causes the analog data acquisition device

to appear to be a digital device instead of

as an analog data acquisition device,

while using the device driver to perform

the automatic transfer of the acquired

digitized analog data to the host device


- 63 -

acquisition device appears to the

computer as if it were a device of the

class of devices;

whereby there is no requirement for any

user-loaded file transfer enabling

software to be loaded on or installed in

the computer in addition to the operating

system

without requiring any user-loaded file

transfer enabling software to be loaded

on or installed in the host device

Limitation [34D] differs from [1F] in that the data in [34D] is not limited to a file,

but the data transfer is automatic. However, [34D] does not preclude a data file, and

therefore the above analysis [1F] applies to [34D]. Furthermore, as explained for

limitation [1F], Ard discloses that “the processor is further configured…to thereby

allow the at least one file of digitized analog data acquired from the analog signal

acquisition channel to be transferred to the computer.” This transfer is

“automatic[]…in response to a digital data read command from the host device” as

recited in limitation [34D]: “upon receiving a File Open command directed toward

the opening of a file thus saved, the disk drive emulating scanner performs a scan in

accordance with the saved parameters and transfers image data resulting therefrom

to the general purpose computer as if the file were being opened.” (Ard, 6:43–48.)

Accordingly, the combination of Ard, Schmidt, and Webb teaches or suggests claim

limitation [34D]. (Zadok Decl., ¶143.)


- 64 -

VI. Ground 2: The combination of Ard, Schmidt, Webb, and Araghi renders claims 4 and 11 obvious.

A. The combination renders claim 4 obvious.

The combination teaches or suggests that “the analog data acquisition device

is designed so that the analog source is detachable.” As discussed in above, Ard’s

scanner 6 includes a CCD image sensor (“analog source”). The CCD image sensor

is part of scanner optics 45 of scanner 20 and is thus “attached” to components of

scanner 6. (Ard, Figure 5, 6:7–8; Zadok Decl., ¶146.)

Ard does not explicitly disclose that scanner 6 is configured such that the

CCD image sensor, or a portion thereof, is “detachable” from scanner 6. However,

in a related field of endeavor, Araghi teaches a CCD image sensor array “composed

of a plurality of small sensor arrays…butted together end to end.” (Araghi, 2:45–48;

see also 1:13–20, 1:38–42.) The small arrays “comprise Charge Coupled Device or

CCD or NMOS type arrays.” (Araghi, 2:55–60.) The arrays “are fabricated…for

easy repairability.” (Araghi, 2:55–60.) Specifically, an array can be detached by

applying “local heating…to the array to free the defective array from surface 8 of

substrate 7 and from neighboring arrays 5b and 5d.” (Araghi, 4:54–61.)

A POSITA would have found it obvious to implement the sensor array in

Ard’s CCD image sensor using the same fabrication techniques disclosed by Araghi


- 65 -

so that the sensor array can be easily detached and replaced when defective,

increasing the useful lifetime of Ard’s scanner 6. (Zadok Decl., ¶148.)

B. The combination renders claim 11 obvious.

The combination teaches or suggests that “the processor allows for a plurality

of different data transmit devices to be attached thereto and detached therefrom.”

Figure 7 of Ard below illustrates an embodiment where the disk drive emulator 41

connects to a disk drive 23 via SCSI bus 4.

Disk drive 23 is a “data transmit receive device” because it both transmits and

receives data to the disk drive emulator as illustrated by the bidirectional arrow

between the disk drive 23 and the disk drive emulator 41. (Zadok Decl., ¶150.) For


- 66 -

example, “[w]hen the scanner optics 45 are operated in accordance with the scanner

parameters 33, image data resulting from that operation is directed by the disk drive

emulator 41 to the disk drive 23 for storage in a file.” (Ard, 7:28–31.) In that case,

the disk drive receives image data from disk drive emulator 41. (Zadok Decl., ¶150.)

Conversely, “the image data can be read from the disk drive 23 like any other file

stored on a disk drive” (Ard, 7:32–33), in which case the disk drive transmits image

data to the disk drive emulator 41. (Zadok Decl., ¶150.)

It would have been obvious to a POSITA that disk drive 23 could be attached

or detached. (Zadok Decl., ¶151.) As shown above for claim 6, the use of cables to

connect SCSI devices was conventional before the earliest possible priority date of

the ’746 patent. Schmidt discloses that “[t]he SCSI bus is from 8 to 32 bits wide”

and that “[a] simple 50-pin ribbon cable can be used for the 8-bit bus.” (Schmidt, p.

80.) Even the cover of Schmidt, which is titled “The SCSI Bus and IDE Interface,”

illustrates a number of cables. (Schmidt, Cover.) A POSITA would have understood

that a SCSI cable allows for a peripheral to be attached or detached from the bus.

(Zadok Decl., ¶151.) Accordingly, the disk drive emulator 41 allows the disk drive

23 (a “data transmit device[]”) “to be attached thereto and detached therefrom.”


Disk drive emulator 41 is also connected to scanner optics 45, which include

the CCD elements. (See Ard, Figure 7; Zadok Decl., ¶152.) As shown above relative


- 67 -

to claim 4, the combination discloses that “the analog data acquisition device is

designed so that the analog source is detachable” because Araghi discloses

detachable CCD elements. Moreover, the discussion relative to claim 7

demonstrates that Ard’s CCD is a data transmit device. Accordingly, the disk drive

emulator 41 allows the CCD “to be attached thereto and detached therefrom.”


Because both disk drive 23 and the CCD are “data transmit devices” that are

connected to the disk drive emulator 41, the combination of Ard, Schmidt, Webb,

and Araghi discloses “wherein the processor allows for a plurality of different data

transmit devices to be attached thereto and detached therefrom” as recited in claim

11, and this claim is therefore obvious in view of this combination.

VII. Ground 3: The combination of Ard, Schmidt, Webb, and Steinle renders claims 10 and 35 obvious.

A. The combination renders claim 10 obvious.

The combination teaches or suggests “a plurality of independent analog

signal acquisition channels, each of the plurality of channels operatively coupled to

the processor for operatively coupling to one of a plurality of analog sources such

that analog data is simultaneously acquired from at least two of the plurality of

channels, is digitized and is coupled into the processor and is processed by the

processor.”


- 68 -

As discussed above relative to claims 1, 7, and 8, Ard’s scanner optics

include a CCD, which a POSITA would understand to include an “analog signal

acquisition channel for receiving a signal from an analog source.” (Zadok Decl.,

¶155.)

The combination of Ard and Webb does not disclose the details of the CCD

or that a CCD can have multiple CCD arrays. Steinle discloses that a scanner can

comprise multiple CCD arrays to produce different color measurements in a color

scanner. (Zadok Decl., ¶¶155–156.) Steinle states, in its background section, that

“[o]ptical scanners operate by imaging an object and then separating the imaging

light into its spectral components, typically red, green, and blue.” (Ex. 1056,

Steinle, 1:15–17.) The “[s]eparate color component images are sensed by different

optical sensor arrays which each generate a signal representative of the associated

color component image which is sensed.” (Steinle, 1:17–20.) Specifically, “[t]hree-

line CCD units which have different color filters deposited directly on the linear

CCD arrays are known in the art and are commercially available.” (Steinle, 2:22–

24.) Based on these disclosures, it would have been obvious to a POSITA to

implement the CCD of the combined system of Ard and Webb as a three-line CCD

unit, each capturing light from a separate portion of the visible light spectrum (e.g.,

red, green, blue). (Zadok Decl., ¶156.) Because Webb discloses that a CCD line is

paired with an A/D converter (see Webb, Figure 1), it would have been obvious to


- 69 -

design the combined system such that signals from a three-line CCD would be

processed separately through different A/D circuits. (Id.) In such a system, the

channels connecting the arrays to the A/D circuits constitute “a plurality of

independent analog signal acquisition channels” as recited in claim 10. (Id.)

Steinle further discloses that “a three-line CCD (charge coupled device)

photosensor unit [] is used to simultaneously sense red, green and blue imaging

light from the scanned object.” (Steinle, 1:47–50.) It would have been obvious,

therefore, that in the combined system the signals from the multiple lines would be

“simultaneously acquired from…the plurality of channels.” (Zadok Decl., ¶157.)

In the combination of Ard, Schmidt, Webb, and Steinle, the plurality of

channels are part of the scanner optics, which are “operatively coupled to the” disk

drive emulator 41 via scanner control block. This combination is illustrated in the

annotated figure below, which combines Ard Figure 5 with Webb Figure 1 and

Steinle Figure 2.


- 70 -

(Zadok Decl., ¶¶157–158.) This coupling is “for cooperatively coupling to one of a

plurality of analog sources”—the three CCD arrays because the data from the

CCDs is “digitized” into image data, which “is transferred from the scanner via the

disk drive emulator” (Ard, Abstract), and therefore “is coupled into the processor

and is processed by the processor” as recited in claim 10. (Zadok Decl., ¶158.)

B. The combination renders claim 35 obvious.

Claim 35 is substantively similar to claim 10, discussed above in the previous

section. The following table highlights the similarities between the claims:

Claim 10 Claim 35


- 71 -

The analog data acquisition device of

claim 1 further comprising a plurality of

independent analog signal acquisition

channels, each of the plurality of

channels operatively coupled to the

processor for operatively coupling to one

of a plurality of analog sources such that

analog data is simultaneously acquired

from at least two of the plurality of

channels, is digitized and is coupled

into the processor and is processed by

the processor.

The method of claim 34, further

comprising simultaneously acquiring the

analog data from each respective analog

channel of a plurality of respective

independent acquisition channels under

control of the processor and acquiring

analog data from the analog source time

independent of transferring the acquired

analog data to the host device.

As shown above for claim 10, the combination teaches or suggests “a plurality of

independent analog signal acquisition channels” and that “analog data is

simultaneously acquired from at least two of the plurality of channels.” Thus, the

combination also teaches or suggests “simultaneously acquiring the analog data

from each respective analog channel of a plurality of respective independent

acquisition channels.” (Zadok Decl., ¶160.) As discussed in Section V(D)(3) for

limitation [1D], the combination of Ard, Schmidt, and Webb teaches or suggests

that “the processor is configured and programmed to implement a data generation

process by which analog data is acquired from the analog signal acquisition


- 72 -

channel,” and therefore it would have been obvious for the acquisition in claim 35

to be “under control of the processor.” (Id., ¶161.)

Ard further discloses “acquiring analog data from the analog source time

independent of transferring the acquired analog data to the host device” because, as

shown above for limitation [1D], the disk drive emulating scanner 6 creates a file

from the image data and stores it until it receives a request to read the file from the

general purpose computer 2. (See Ard, Figure 8, 7:55–59.)

VIII. Ground 4: The combination of Ard, Schmidt, Webb, and Reisch renders claim 23 obvious.

The combination teaches or suggests that “the analog data is processed by

being subject to a fast Fourier transform.” Neither Ard, Schmidt, nor Webb

explicitly discloses that a Fast Fourier Transform (FFT) is applied onto the digital

image file resulting from operating scanner 6 (“the digitized analog data”).

However, in a related field of endeavor, Reisch discloses that “[i]mage processing

can occur in either the spatial domain or the frequency domain.” (Ex. 1028, Reisch,

1:14–15.) “Spatial image data points may be transformed to frequency space using

transformations such as Fourier transform or discrete cosine transforms (DCT).”

(Reisch, 1:38–40.) Further, such transformations can be used for image compression

like JPEG. (See, e.g., Reisch, 1:58–67.)


- 73 -

A POSITA would have found it obvious to modify Ard, Schmidt, and Webb

according to Reisch to allow for frequency domain image processing techniques,

including image compression, to be performed on Ard’s digital image file. (Zadok

Decl., ¶167.) For example, the techniques can be applied to provide the digital

image file in different image formats, such as JPEG as taught by Reisch or TIF as

taught by Ard. (Reisch, 1:58–67; Zadok Decl., ¶¶164–168.) A POSITA would also

have found it obvious to provide an FFT implementation in Ard’s scanner 20 to

support frequency domain image processing techniques. (Zadok Decl., ¶167.) As

noted by Reisch, “[s]patial image data points may be transformed to frequency

space using transformations such as Fourier transform or discrete cosine transforms

(DCT).” (Reisch, 1:38–40.) The DCT is a reduced version of a Discrete Fourier

Transform (DFT) that includes only the real components of the DFT. (Zadok Decl.,

¶166.) Thus, an FFT can be used to derive both a DFT and a DCT. (Id., ¶¶163, 166)

Accordingly, by implementing an FFT, both a DFT and a DCT transformation can

be performed efficiently using the same algorithm/circuitry. (Id., ¶¶166–168.) A

POSITA would have been motivated to employ such an implementation to support

the frequency domain processing techniques. (Id., ¶168.)

IX. Conclusion.

For the reasons provided above, inter partes review of the challenged claims

is requested.


Respectfully submitted,

STERNE, KESSLER, GOLDSTEIN & Fox P.L.L.C.

Lori A. Gordon Registration No. 50,633 Attorney for Petitioner

Date: October 11, 2016

1100 New York Avenue, N. W. Washington, D.C. 20005-3934 (202) 371-2600

-74-


APPENDIX A - LISTING OF CHALLENGED CLAIMS

1. [1P.1] An analog data acquisition device operatively connectable to a

computer through a multipurpose interface of the computer,

[1P.2] the computer having

I1P.2a1 an operating system programmed so that, when the computer

I1P.2b1 receives a signal from the device through said multipurpose interface

of the computer indicative of a class of devices,

[1P.2c] the computer automatically activates a device driver corresponding to

the class of devices for allowing the transfer of data between the device and the

operating system of the computer,

[1P.3] the analog data acquisition device comprising:

[A] a) a program memory;

[I BI b) an analog signal acquisition channel for receiving a signal from an

analog source;

[1C] c) a processor operatively interfaced with the multipurpose interface of

the computer, the program memory, and a data storage memory when the analog

data acquisition device is operational;

[11).11 d) wherein the processor is configured and programmed to implement

a data generation process by which analog data is acquired from the analog signal

acquisition channel,


[1D.21 the analog data is processed and digitized, and

[1D.31 the processed and digitized analog data is stored in a file system of the

data storage memory as at least one file of digitized analog data;

[1E.1] e) wherein when the analog acquisition device is operatively interfaced

with the multipurpose interface of the computer, the processor executes at least one

instruction set stored in the program memory and

[1E.21 thereby automatically causes at least one parameter indicative of the

class of devices to be sent to the computer through the multipurpose interface of the

computer,

[1E.31 independent of the analog source, wherein the analog data acquisition

device is not within the class of devices; and

[1F.1] f) wherein the processor is further configured and programmed to

execute at least one other instruction set stored in the program memory to

[1F.21 thereby allow the at least one file of digitized analog data acquired

from the analog signal acquisition channel to be transferred to the computer using

the device driver corresponding to said class of devices

[1F.31 so that the analog data acquisition device appears to the computer as if

it were a device of the class of devices;

Petition for Inter Panes Review of U.S. Patent No. 8,504,746

II 1 F.4 1 whereby there is no requirement for any user-loaded file transfer

enabling software to be loaded on or installed in the computer in addition to the

operating system.

4. The analog data acquisition device of claim 1, wherein the analog data

acquisition device is designed so that the analog source is detachable.

6. The analog data acquisition device of claim 1, wherein the processor is

adapted to be interfaced with the multi-purpose interface of an external computing

device by means of a cable.

7. The analog data acquisition device of claim 1, wherein the analog source

comprises a data transmit/receive device.

8. The analog data acquisition device of claim 7, wherein the analog source is

designed for one of one-way and two-way communication with the host device.

10. The analog data acquisition device of claim 1 further comprising a

plurality of independent analog signal acquisition channels, each of the plurality of

channels operatively coupled to the processor for operatively coupling to one of a

plurality of analog sources such that analog data is simultaneously acquired from at

least two of the plurality of channels, is digitized and is coupled into the processor

and is processed by the processor.


11. The analog data acquisition device of claim 1, wherein the processor

allows for a plurality of different data transmit devices to be attached thereto and

detached therefrom.

14. The analog data acquisition device of claim 1, wherein the analog source

includes at least first and second transducers both of which are designed to transmit

data.


configured to initiate a process by which the at least one file of digitized analog data

is directly transferred to an input/output device.


configured to allow a mode of operation of the analog data acquisition device other

than the transfer of at least some of the at least one file of digitized analog data to

the multipurpose interface to be controlled by means of an external personal

computer.

23. The analog data acquisition device of claim 1, wherein the analog data is

processed by being subject to a fast Fourier transform.

30. The analog data acquisition device of claim 1 wherein the device driver is

installed with the operating system such that communication between the computer

and the analog data acquisition device takes place by means of a device driver


program which is matched to the multi-purpose interface of the computer rendering

the analog data acquisition device host device independent.

34. [34P] A method for analog data acquisition and interfacing to a host

device wherein the host device includes a device driver, comprising:

1134A1 operatively interfacing a data acquisition device, including a processor

and a memory, with a multi-purpose interface of the host device;

[34B] acquiring analog data from an analog source, processing and digitizing

the analog data, and storing the processed and digitized analog data in the memory

as digitized analog data under control of the processor;

134CJ automatically sending under control of the processor at least one

parameter to the multi-purpose interface of the host device, the at least one

parameter identifying the analog data acquisition device as a digital device instead

of as an analog data acquisition device, regardless of the analog source; and

134D1 automatically transferring data from the analog source to the host

device in response to a digital data read command from the host device, in a manner

that causes the analog data acquisition device to appear to be a digital device instead

of as an analog data acquisition device, while using the device driver to perform the

automatic transfer of the acquired digitized analog data to the host device

[34D.11 without requiring any user-loaded file transfer enabling software to

be loaded on or installed in the host device.


35. The method of claim 34, further comprising simultaneously acquiring the

analog data from each respective analog channel of a plurality of respective

independent acquisition channels under control of the processor and acquiring

analog data from the analog source time independent of transferring the acquired

analog data to the host device.


CERTIFICATION OF SERVICE (37 C.F.R. 42.6(e), 42.105(a))

The undersigned hereby certifies that on October 11, 2016, true and correct

copies of the foregoing PETITION FOR INTER PARTES REVIEW OF U.S.

PATENT NO. 8,504,746, the accompanying Power of Attorney, and all associated

exhibits were served in their entirety on the following parties via FedExfi:

Schmeister, Olsen & Watts 2500 Westchester Avenue, Suite 210

Purchase, NY 10577 PAIR Correspondence Address for US.P.N. 8,504, 746

Christopher V. Goodpastor Andrew G. DiNovo

DiNovo Price Eliwanger & Hardy LLP 7000 N. MoPac Expressway, Suite 350

Austin, Texas 78731


L 1 A. Gor on, Reg. No. 50,633 Attorney for Petitioner

Date: October 11, 2016

1100 New York Avenue, N. W. Washington, D.C.20005-3934 (202) 371-2600

Petition for Inter Panes Review of U.S. Patent No. 8,504,746

CERTIFICATE OF COMPLIANCE WITH TYPE-VOLUME LIMITATION, TYPEFACE REQUIREMENTS, AND TYPE STYLE REQUIREMENTS

1. This Petition complies with the type-volume limitation of 14,000

words, comprising 13,961 words, excluding the parts exempted by 37 C.F.R.

§ 42.24(a).

2. This Petition complies with the general format requirements of 37

C.F.R. § 42.6(a) and has been prepared using Microsoftfi Word 2010 in 14 point

Times New Roman.

Respectfully submitted,


LJ4 i A. Gor n Registration No. 50,633 Attorney for Petitioner

Documents

Fax: (202) 371-2540 UNITED STATES PATENT AND TRADEMARK ... · 1255 (Fed. Cir. 2015). 1017–1018 Intentionally Left Blank 1019 Webster’s Encyclopedic Unabridged Dictionary of the