UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO.

Transcription

1 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) Fax: (202) UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD PETITION FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,470,399 Mail Stop PATENT BOARD Patent Trial and Appeal Board U.S. Patent & Trademark Office P.O. Box 1450 Alexandria, VA

2 TABLE OF CONTENTS Petition for Inter Partes Review of I. Mandatory notices (37 C.F.R. 42.8(a)(1)) II. Grounds for standing (37 C.F.R (a)) III. Identification of challenge (37 C.F.R (b)) A. Citation of Prior Art... 4 B. Statutory grounds for the challenge IV. The 399 patent A. Overview of the 399 patent B. The challenged claims of the 399 patent are not entitled to priority benefit of the March 1997 German Application C. Summary of the prosecution history D. Level of ordinary skill in the art E. Claim construction data transmit/receive device [claims 1, 3, 11, 14]...18 V. Ground 1: The combination of Ard, Schmidt, and Webb renders claims 1, 3, 5, 11, and 14 obvious A. Overview of Ard B. Overview of Schmidt C. Overview of Webb D. The combination of Ard, Schmidt, and Webb renders claims 1, 11, and 14 obvious The combination of Ard, Schmidt, and Webb discloses the preamble of independent claims 1, 11, and a) The combination of Ard, Schmidt, and Webb discloses an interface device and a method for communication between a host device and a data transmit/receive device b) The combination of Ard, Schmidt, and Webb discloses the host device limitations of the preamble c) The combination of Ard, Schmidt, and Webb discloses the data transmit/receive device architecture limitation of the preamble The combination of Ard, Schmidt, and Webb discloses the architectural elements of the interface device i -

3 a) The combination of Ard, Schmidt, and Webb discloses that the interface devices comprise a processor and a memory b) The combination of Ard, Schmidt, and Webb discloses the first connecting device limitations c) The combination of Ard, Schmidt, and Webb suggests the second connecting device limitations The combination of Ard, Schmidt, and Webb discloses the recognition limitations of the independent claims a) The combination of Ard, Schmidt, and Webb discloses the inquiry and response elements of the recognition limitations b) The combination of Ard, Schmidt, and Webb teaches whereupon the host device communicates with the interface device by means of the [driver] The combination of Ard, Schmidt, and Webb discloses the transfer limitations of the independent claims a) The combination of Ard, Schmidt, and Webb teaches a data request command from the host device to the type of input/output device b) The combination of Ard, Schmidt, and Webb teaches that a second command interpreter interpret[s] [the] data request command as a data transfer command for initiating a transfer of the digital data to the host device E. The combination of Ard, Schmidt, and Webb renders claim 3 obvious VI. The combination of Ard, Schmidt, Webb, and Johnson renders claim 5 obvious. 57 A. Overview of Johnson B. The combination of Ard, Schmidt, Webb, and Johnson discloses that the processor is a digital signal processor as recited in claim VII. Conclusion ii -

4 TABLE OF AUTHORITIES Petition for Inter Partes Review of Cases: In re Cuozzo Speed Techs., LLC, 778 F.3d 1271 (Fed. Cir. 2015) In re Papst Licensing Digital Camera Patent Litigation, 778 F.3d 1255 (Fed. Cir. 2015) In re Translogic Tech., Inc., 504 F.3d 1249 (Fed. Cir. 2007) Martin v. Mayer, 823 F.2d 500 (Fed. Cir. 1987) Phillips v. AWH Corp., 415 F.3d 1303 (Fed. Cir. 2005)... 17, 19 PowerOasis, Inc. v. T-Mobile USA, Inc., 522 F.3d 1299 (Fed. Cir. 2008) Vas-Cath Inc. v. Mahurkar, 935 F.2d 1555 (Fed. Cir. 1991) York Prod. Inc. v. Central Tractor Farm & Family Center, 99 F.3d 1568 (Fed. Cir. 1996) Statutes: 35 U.S.C. 102(a)... 4, 5 35 U.S.C. 102(b)... 4, 5 35 U.S.C. 102(e)... 4, 5 35 U.S.C , 18, U.S.C U.S.C. 365(c) iii -

5 Regulations: 37 C.F.R , 3 37 C.F.R C.F.R , 4 - iv -

6 EXHIBIT LIST Petition for Inter Partes Review of Ex. No. Description 1001 U.S. Patent 6,470,399 to Tasler 1002 File History for U.S. Patent 6,470, Declaration of Dr. Erez Zadok in Support of Petition for Inter Partes Review of 1004 Curriculum Vitae of Dr. Erez Zadok 1005 Intentionally left blank 1006 Intentionally left blank 1007 The SCSI Bus and IDE Interface Protocols, Applications and Programming, by Schmidt, First Edition, Addison-Wesley, 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 X , American National Standard for Information Systems (ANSI) Operating System Concepts, by Silberschatz et al., Fourth Edition Microsoft Computer Dictionary, Third Edition, Microsoft Press, Intentionally left blank 1016 In re Papst Licensing Digital Camera Patent Litigation, 778 F.3d 1255 (Fed. Cir. 2015) The Art of Electronics, by Horowitz et al., First Edition, Cambridge University Press, The IEEE Standard Dictionary of Electrical and Electronics Terms, Sixth Edition, Webster s Encyclopedic Unabridged Dictionary of the English Language, Random House, Papst Licensing GmbH & Co., KG v. Apple Inc., Case No cv (E.D. Tex.), Complaint filed November 30, Principles of Data Acquisition and Conversion, Burr-Brown Application Bulletin, Principles of Data Acquisition and Conversion, Intersil Application Note, October Sample-and-Hold Amplifiers, Analog Devices MT-090 Tutorial, Declaration of Scott Bennett - v -

7 Ex. No. Description 1025 Discrete-Time Signal Processing, by Oppenheim et al., First Edition, Prentice-Hall, Intentionally left blank 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 Intentionally left blank 1046 U.S. Patent No. 5,915,106 to Ard, titled Method and System for Operating a Scanner Which Emulates a Disk Drive 1047 U.S. Patent No. 5,303,064 to Johnson et al., titled Image Scanner with Calibration Mechanism to Obtain Full Dynamic Range and Compensated Linear Output 1048 U.S. Patent No. 5,489,772 to Webb et al., titled Variable Optical Sampling Rate Dependent on Requested Scan Resolution German Application (DE ) German Application Translated (DE ) 1051 Foley, Computer Graphics: Principles and Practice, 2d Edition, vi -

8 - 1 - Petition for Inter Partes Review of Apple Inc. petitions for inter partes review of claims 1, 3, 5, 11, and 14 of United States Patent No. 6,470,399 to Tasler, titled Flexible Interface for Communication Between a Host and an Analog I/O Device Connected to the Interface Regardless the Type of the I/O Device (hereinafter the ʼ399 patent ). The 399 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 399 patent is the March 3, 1998 filing date of the PCT application. In the present petition, Apple Inc. presents an intervening reference, U.S. Patent 5,915,106 to Ard ( Ard ) filed after the March 1997 German application date but before the March 3, 1998 PCT application date. Apple demonstrates below that none of the challenged claims are patentable in view of the intervening Ard reference. The purported novelty of the 399 patent is that, when attached to a host computer, the interface identifies itself as an input/output device customary in a host device, such as a hard disk drive, thereby allowing the host device to communicate with the interface device by means of the driver for the input/output device customary in a host device. ( 399 patent, 13:4 8.) This technique is commonly referred to as emulation. The 399 patent, however, was not the first disclosure of hard disk emulation for interfacing to I/O devices. A U.S. patent to Ricoh Corp., filed nearly a year

9 - 2 - Petition for Inter Partes Review of before the 399 priority date, described an image scanner that appears to a host computer as a disk drive, providing the same benefits as the 399 patent. The scanner interfaces with the workstation using the well-known multi-purpose SCSI interface. The 399 patent merely claims an obvious variation of hard disk emulation previously disclosed by the Ricoh patent, in addition to many others. Accordingly, Apple respectfully requests that the Board institute trial on the grounds set forth herein. 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 ). actions. RELATED MATTERS: The 399 patent is the subject of the following civil Papst Licensing GmbH & Co., KG v. Apple Inc., Case No cv (E.D. Tex.); Papst Licensing GmbH & Co., KG v. LG Electronics, Inc. et al., Case No cv (E.D. Tex.); Papst Licensing GmbH & Co., KG v. ZTE Corporation et al., Case No cv (E.D. Tex.); Papst Licensing GmbH & Co., KG v. Samsung Electronics Co Ltd. et al., Case No. 6:15-cv (E.D. Tex.); Papst Licensing GmbH & Co., KG v. Lenovo (United States) Inc. et al., Case No cv (E.D. Tex.); Papst Licensing GmbH & Co., KG v. Huawei

10 - 3 - Petition for Inter Partes Review of Technologies Co., Ltd. et al., Case No cv (E.D. Tex.) and In Re Papst Licensing GmbH & Co., KG Patent Litigation, MDL No (Misc. Action No ) 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. U.S. Application No. 14/859,266, filed on September 19, 2015, claims the benefit of the 399 patent. Finally, Petitioner is filing concurrent petitions against the 399 patent. No other matters related to the 399 patent are known to the Petitioner. 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, all at the address: STERNE, KESSLER, GOLDSTEIN & FOX, 1100 New York Avenue, N.W., Washington, D.C., 20005, phone number (202) and facsimile (202) SERVICE INFORMATION: Petitioner consents to electronic service by at the addresses: lgordon-ptab@skgf.com, and speters-ptab@skgf.com. II. Grounds for standing (37 C.F.R (a)). The undersigned and Apple certify that the ʼ399 patent is available for inter partes review. Apple certifies that it is not barred or estopped from requesting this inter partes review on the grounds identified herein. The assignee of the 399 patent, Papst, filed a complaint against Apple alleging infringement of the 399 patent on

11 November 30, (Ex ) The present petition is being filed within one year of service of Petitioner. III. Identification of challenge (37 C.F.R (b)). A. Citation of Prior Art The 399 patent is the national stage of international application PCT/EP98/01187, filed on March 3, The 399 patent further claims priority to a German application, filed on March 4, In support of the grounds of unpatentability cited above, Apple cites the following prior art references: U.S. Patent No. 5,915,106 to Ard, titled Method and System for Operating a Scanner Which Emulates a Disk Drive (Ex. 1046), is prior art under at least 35 U.S.C. 102(e) because it was filed on March 20, 1997, before the March 3, 1998 priority date of the 399 patent. The SCSI Bus and IDE Interface Protocols, Applications and Programming, by Friedhelm Schmidt (Ex. 1007), is prior art under at least 35 U.S.C. 102(a) and 102(b) because it was published in 1995, more than one year before the earliest possible priority date of the 399 patent. (See Ex ) U.S. Patent No. 5,489,772 to Webb et al., titled Variable Optical Sampling Rate Dependent on Requested Scan Resolution (Ex. 1048), is prior art under at 1 Apple does not acquiesce that the 399 patent is entitled to priority benefit of the 1997 German application

12 least 35 U.S.C. 102(a), 102(b), and 102(e) because it was filed on November 14, 1994, and issued February 6, 1996, more than one year before the March 3, 1998 priority date of the 399 patent. U.S. Patent No. 5,303,064 to Johnson et al., titled Image Scanner with Calibration Mechanism to Obtain Full Dynamic Range and Compensated Linear Output (Ex. 1047), is prior art under at least 35 U.S.C. 102(a), 102(b), and 102(e) because it was filed on February 20, 1991, and issued April 12, 1994, more than one year before the March 3, 1998 priority date of the 399 patent. B. Statutory grounds for the challenge. Apple requests review of claims 1, 3, 5, 11, and 14 on the following grounds: References Basis Claims Challenged Ard, Schmidt, and Webb 103 1, 3, 11, 14 Ard, Schmidt, Webb, and Johnson

13 IV. The 399 patent. A. Overview of the 399 patent. The 399 patent describes an interface device that enables communication between a host device and a data transmit/receive device from which data is acquired. (Ex. 1001, 399 patent, 1:10 14.) The patent acknowledges that such interface devices were known prior to earliest possible priority date of the 399 patent. However, the patent alleges that these existing interfaces had limitations specifically, a tradeoff between high data transfer rates and host-device independence. (Id., 3:24 27.) 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. ( 399 patent, 1:65 to 2:7.) 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:22 30.) The 399 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. ( 399 patent, 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. ( 399 patent, 5:48 50.) The 399 patent states that [t]he first connecting device - 6 -

14 is attached both to a digital signal processor 13 and to a memory means 14, which in turn are attached to a second connecting device. ( 399 patent, 5:50 56.) In some embodiments, the second connecting device is attached by means of an output line 16 to a data transmit/receive device from which data is to be read, i.e. acquired, and transferred to the host device. ( 399 patent, 5:56 60.) The 399 patent discloses techniques to make the interface device appear[] to the host device as a hard disk. ( 399 patent, 6:58 59.) Specifically, the 399 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:17 23, 4:11 13.) When the - 7 -

15 - 8 - Petition for Inter Partes Review of interface device receives the inquiry instruction, the interface device identifies itself, regardless of the type of attached data transmit/receive device, as a customary input/output device to the host device. (See 399 patent, 4:65 to 5:6.) This response is handled by a first command interpreter. ( 399 patent, 6:52 53.) The host can, in addition, send an instruction, known by those skilled in the art as Test Unit Ready, to the interface device to require more precise details. ( 399 patent, 6:16 19.) Both the INQUIRY and Test Unit Ready commands were well known as part of the small computer system interface (SCSI) which was widely popular at the time of invention. (Ex. 1003, Zadok Decl., 33, 50, 51 (citing Schmidt, p. 165 (describing conventional read and write commands for hard disk drives); see also 399 patent, 4:40 44.) During operation, the interface device simulates a hard disk with a root directory whose entries are virtual files which can be created for the most varied functions. ( 399 patent, 6:1 3.) When a user wishes to read data from the data transmit/receive device via the line 16, the host device sends a command, for example read file xy, to the interface device. ( 399 patent, 6:55 58.) The second command interpreter then begins to transfer data from the data transmit/receive device via the second connecting device to the first connecting device and via the line 11 to the host device. ( 399 patent, 6:64 67.) This operation emulates a realtime input file [that] then appears as a file whose length corresponds to the

16 anticipated volume of data contained in a configuration file. ( 399 patent, 7:5 7; see also 7:1 5.) B. The challenged claims of the 399 patent are not entitled to priority benefit of the March 1997 German Application. The 399 patent is the national stage of international application PCT/EP98/01187, filed on March 3, The 399 patent further claims priority to a German application, filed on March 4, 1997, referred to herein as the 399 German application (Ex. 1049). A certified translation of the German application is provided as Ex An international application designating the United States is entitled to the right of priority based on 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 that 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 399 patent are not entitled to priority benefit of the 399 German application because the 399 German application does not provide written description support for the challenged claims. Each of the challenged claims requires that the host device comprises a multi-purpose interface. (See 399 patent, claim 1). Independent claim 1 further specifies that the claimed interface device includes a first connecting device for - 9 -

17 interfacing the host device with the interface device via the multi-purpose interface of the host device. The 399 German application fails to provide written description support for the claimed multi-purpose interface of the host device. To satisfy the written description requirement, the disclosure of the 399 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, (Fed. Cir. 1991). To satisfy the written description requirement, 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 that Mr. Tasler understood the invention to include a multi-purpose interface of the host device and its associated drivers. Nor is the inclusion of a multi-purpose interface and its associated drivers necessarily present in the 399 German application. See Martin v. Mayer, 823 F.2d 500, 505 (Fed. Cir. 1987)(holding that the written description requirement is not a question of whether one skilled in the art might be able to construct the patentee s device from the teachings of the disclosure. Rather, it is a question whether the application necessarily discloses that particular device ) (emphasis in original)

18 Indeed, the chart below highlights that the concept of a multi-purpose interface and its associated drivers was specifically added as a new embodiment, after the filing of the 399 German application. 399 Patent Application As Filed Corresponding Disclosure in 399 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. 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.) (Ex. 1002, p. 18.) 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 However, it is obvious for experts that the interface device 10 is not necessarily registered when switching

19 up 399 Patent Application As Filed Corresponding Disclosure in 399 German Application on the computer 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. 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.) (Ex. 1002, p. 21.) 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 or BIOS system manufacturer, or by using driver programs which are normally optimized and included by the manufacturers of multi-purpose 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, for exchanging data. (Ex. 1050, p. 5.)

20 399 Patent Application As Filed Corresponding Disclosure in 399 German Application interfaces. (Ex. 1002, p. 22.) The inventor also did not recognize BIOS routines implementing SCSI commands as a multi-purpose interface. (Zadok Decl., 134.) Rather, the inventor understood such BIOS routines as providing a classical input/output interface. For example, the 399 patent includes the following disclosure not found in the 399 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 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

21 ( 399 patent, 4:44 56 (emphasis added).) Thus, the inventor understood multi-purpose interfaces as a replacement for BIOS routines integrating classical input/output interfaces. As such, the 399 German application does not explicitly or inherently disclose a multi-purpose interface. Because the 399 German application does not actually or inherently disclose the multi-purpose interface limitations such that one skilled in the art would recognize such a disclosure, the challenged claims are not entitled to priority benefit of the 399 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. Summary of the prosecution history. The national stage application that matured into the 399 patent was filed with a set of sixteen claims. The U.S. Patent Office initially rejected each of the sixteen originally-filed claims as obvious over the combination of applicant-admitted prior art (AAPA) and U.S. Patent No. 5,499,378 to McNeill et al. (Ex. 1002, p. 244.) The Examiner relied on McNeill primarily for its teaching of the response to a SCSI inquiry command allowing the host device [to] communicate[] with the interface device by means of the driver for the I/O device customary in a host device. (Ex. 1002, p. 245.)

22 Petition for Inter Partes Review of In response to the Office Action, the Applicant amended the independent claims to add three limitations: (1) the data transmit/receive devices is arranged for providing analog data; (2) a sampling circuit to convert the analog data into a digital form; and (3) first and second command interpreters (claims 1 and 12). (Ex. 1002, pp ) To distinguish these amended claims over the cited rejection, Applicant argued that McNeill provide[s] access to a non-scsi device a magnetic disk via a SCSI bus and therefore does not disclose that the data transmit/receive device is arranged for providing analog data. (Ex. 1002, p. 255.) Applicant also argued that McNeill does not include a first command interpreter that lies to the host computer as to the real nature of the data transmit/receive device. (Ex. 1002, p. 256.) Based on these arguments, the Examiner subsequently allowed the claims. (Ex. 1002, p. 262.) D. Level of ordinary skill in the art. Based on the disclosure of the 399 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 experience in studying or developing computer interfaces or peripherals and storage related software. (Zadok Decl., 29.) A person of ordinary skill in the art would also be familiar with operating systems (e.g., MS-DOS, Windows, Unix), their associated file systems (e.g., FAT, UFS,

23 FFS), device drivers for computer components and peripherals (e.g., mass storage device drivers), and communication interfaces (e.g., SCSI, USB, PCMCIA). (Zadok Decl., 29.) E. Claim construction. In an inter partes review, claim terms in an unexpired patent are interpreted according to their broadest reasonable construction in light of the specification of the patent in which they appear. 37 C.F.R (b); In re Cuozzo Speed Techs., LLC, 778 F.3d 1271, 1281 (Fed. Cir. 2015). Accordingly, claim terms are given their ordinary and customary meaning, as would be understood by one of ordinary skill in the art in the context of the entire disclosure. In re Translogic Tech., Inc., 504 F.3d 1249, 1257 (Fed. Cir. 2007). Except for the exemplary terms set forth herein, construed under the broadest reasonable interpretation standard, 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 Claim construction of certain terms of the 399 patent was a subject of Appeal to the Court of Appeals for the Federal Circuit from the United States Court for the District of Columbia in No. 1:07-mc RMC. In re Papst 2 Petitioner reserves the right to present different constructions in another forum where a different claim construction standard applies

24 Licensing Digital Camera Patent Litigation, 778 F.3d 1255 (Fed. Cir. 2015). The Federal Circuit construed the following terms under the Phillips standard: Claim term District Court Construction CAFC Ruling interface device may not be a permanent part of either the data transmit/receive device or the host device/computer. (Ex. 1016, p. 8.) is not limited to a device that is physically separate and apart from, and not permanently attached to, a data device (or a host computer). (Ex. 1016, p. 8.) second connecting device a physical plug or socket for permitting a user readily to attach and detach the interface device with a plurality of dissimilar data transmit/receive devices. (Ex. 1016, p. 10.) does not require a physical plug, socket, or other structure that permits a user to readily attach and detach something else. (Ex. 1016, p. 11.) 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.) virtual files files that appear to be but are not physically stored; rather they are constructed or derived from existing data when their contents are requested by an application program so that they appear to not limited to a file whose content is stored off the interface device, though it includes such files. (Ex. 1016, p. 14.)

25 Claim term District Court Construction CAFC Ruling exist as files from the point of view of the host device. (Ex. 1016, p. 13.) input/output device customary in a host device data input/output device that was normally present within the chassis of most commercially available computers at the time of the invention. (Ex. 1016, p. 16.) not limited to a device normally present within the chassis of a computer. (Ex. 1016, p. 16 (emphasis in original).) Of these five terms, Petitioner proposes 3 to construe the term data transmit/receive device under the broadest reasonable interpretation standard employed by the Board for unexpired patents. The term virtual files does not appear in any of the claims challenged in this Petition. For the purposes of this proceeding, explicit construction of second connecting device or other terms in the challenged claims is not necessary at this time. data transmit/receive device [claims 1, 3, 11, 14] Apple proposes to construe the term data transmit/receive device as a device capable of transmitting or receiving data. This construction clarifies that 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

26 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 / indicates alternatives. (See Ex. 1019, Websters, p (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. ( 399 patent, 5:56 60.) 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, 3, 5, 11, and 14 obvious. 4 A. Overview of Ard. 4 A complete listing of challenged claims is provided as Appendix A. For ease of discussion, labels have been added to individual claim limitations

27 By at least 1997, Mark Ard of Ricoh Corporation identified the same problem that the 399 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 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

28 (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., 68.) 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 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

29 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 that 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. As the back cover of Schmidt confirms, as of its 1995 publication date, [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 sends SCSI commands over a SCSI bus to a disk drive. (Schmidt, p. 80.)

30 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.) In response, a 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.)

31 C. Overview of Webb. Webb discloses details of the conversion of light to a digital signal in an optical scanner. (Zadok Decl., 73.) Webb states that 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 that 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.) Webb states that [t]he sequentially arranged charges from the CCD cells may then be converted, one-byone, 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: )

32 D. The combination of Ard, Schmidt, and Webb renders claims 1, 11, and 14 obvious. 1. The combination of Ard, Schmidt, and Webb discloses the preamble of independent claims 1, 11, and 14. The preamble of independent claims 1, 11, and 14 sets forth three separate components: (1) an interface device, (2) the architecture of the host device, and (3) the architecture of the data transmit/receive device. The following table highlights the similarity between the preambles of each claim. Claim 1 Claim 11 Claim 14 [1P.1/11P.1] An interface device for communication between a host device [see [1P.2/11P.2] and a data transmit/receive device [14P.1] A method for communication between a host device [see [14P.2]] and a data transmit/receive

33 Claim 1 Claim 11 Claim 14 device [see [14P.3.] ] via an interface device [1P.2] which comprises drivers for input/ output devices customary in a host device and a multipurpose interface [11P.2] which comprises a multipurpose interface and a specific driver for this interface [14P.2] which comprises drivers for input/output devices customary in a host device and a multi-purpose interface [1P.3/11P.3/14P.3] the data transmit/receive device being arranged for providing analog data, As set forth below, the combination of Ard, Schmidt, and Webb teaches or suggests each of the preamble limitations. a) The combination of Ard, Schmidt, and Webb discloses an interface device and a method for communication between a host device and a data transmit/receive device. Ard discloses a disk drive emulating scanner 6 connected via a small computer system interface (SCSI) bus 4 to a computer 2. (Zadok Decl., 75.) The following annotated figure below combines Figure 1 of Webb with Ard s Figure 3 illustrating the components of computer 2 and Figure 5 illustrating the components of the disk drive emulating scanner to depict the combined system. (Zadok Decl., 76; Ard, Figures 3 and 5; Webb Figure 1.)

34 (Webb, Figure 1.) Ard s disk drive emulating scanner 6 includes an interface device. 5 The interface device within Ard s disk drive emulating scanner 6 comprises disk drive emulator 41, O/S switch 29, scanner control block 43, and memory 47. (Zadok Decl., 77; Ard, Figure 5.) Ard s interface device is for communication between the general purpose computer 2 ( host device ) and the CCD ( data transmit/receive device ) contained in scanner optics 45. (Zadok Decl., 77.) For example, disk drive emulator 41 receives Open File or Save File commands sent from the general purpose computer 2 over the SCSI bus 4. (Ard, 5:55 57 (emphasis added).) Ard further specifies that upon receiving a File Open command directed toward the opening of 5 As discussed above in the claim construction section, the Federal Circuit found that the interface device in claims 1, 11, and 14 is not limited to stand-alone devices detachable from the data transmit/receive device. (Ex. 1016, p. 8.)

35 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 (emphasis added); see also 6:49 59.) Webb discloses a schematic circuit for converting the analog image data transmitted by a CCD to digital image data. (Webb, Figure 1.) The CCD therefore constitutes a data transmit/receive device as recited in claims 1, 11, and 14. (Zadok Decl., 77 (citing Ex. 1046, Ard, 3:19 30, 6:54 59).) b) The combination of Ard, Schmidt, and Webb discloses the host device limitations of the preamble. Independent claims 1 and 14 each require that the host comprise drivers for input/output devices customary in a host device and a multi-purpose interface [1P.2/14P.2] and independent claim 11 requires a multi-purpose interface and a specific driver for this interface [11P.2]. The combination of Ard, Schmidt, and Webb discloses each of these limitations. A hard disk is an input/output devices customary in a host device. Dependent claim 2 and 15 confirm that the 399 patent considers a hard disk to be an input/output device customary in a host device: wherein the drivers for input/output drivers customary in a host device comprise a hard disk driver, and the signal indicates to the host device that the host device is communicating with a hard

36 Petition for Inter Partes Review of disk (claim 2) and wherein the drivers for input/output devices customary in a host device comprise a driver for a storage device and in particular for a hard disk drive (claim 15). The general purpose computer 2 ( host device ) includes a SCSI card 17 ( multi-purpose interface ) and a SCSI driver 13 ( a specific driver for this interface ). (Zadok Decl., 79; see Ard, Figure 3.) Schmidt explains that [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.) Thus, the SCSI card 17 of Ard constitutes a multi-purpose interface. (Zadok Decl., 79.) Inclusion of a SCSI interface to connect with a hard disk on a host workstation such as Ard s general purpose computer was well known and a normal part of commercially available computer systems prior to even the earliest possible priority date of the 399 patent. (Zadok Decl., 70, 80 (citing Schmidt, Back Cover ( Almost all modern computers including PCs, workstations and mainframes are equipped with a SCSI interface )).) Schmidt, for example, discloses that [a] computer system is connected to the SCSI bus through a host adapter. (Schmidt, p. 79.) Such adapters often reside directly on the mother board of workstations and modern personal computers, in which case they are referred to as embedded host adapters. (Schmidt, p. 79.) Figure 9.1 of Schmidt illustrates [a] simple SCSI configuration where a host adapter communicates with a disk drive using a SCSI

37 bus. (Schmidt, p. 80; Zadok Decl., 80.) Thus, the combination of Ard, Schmidt, and Webb teaches a driver[] for input/output devices customary in a host device. (Zadok Decl., 81.) Thus, the general purpose computer 2 of Ard includes drivers for input/output devices [hard disks] customary in a host device and a multi-purpose interface [SCSI] as recited in claims 1 and 14 and a multi-purpose interface [SCSI] and a specific driver for this interface [SCSI driver 13]. (Zadok Decl., 78.) c) The combination of Ard, Schmidt, and Webb discloses the data transmit/receive device architecture limitation of the preamble. The scanner optics 45 includes a Charge Coupled Device (CCD). (Ard, 6:7 10.) A person of ordinary skill in the art would have understood that a CCD is arranged for providing analog data. (Zadok Decl., 82.) Figure 1 of Webb, annotated below, illustrates a schematic diagram of a data sampling and conversion circuit for a CCD. (Webb, 3:56 58.)

38 Webb describes the well-known structure of a CCD: As is well-known, CCD 14 includes n charge transfer buckets Q 1, Q 2, Q 3, through Q n, which sequentially transfer the charges that were simultaneously collected from each of the individual pixels in the CCD. A chargeto-voltage converter 18 connected to the last charge transfer bucket Q 1 of CCD 14 converts the charge stored in the last bucket Q 1 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.) Since the input of the A/D converter 22 is analog, a person of ordinary skill in the art would have recognized that the CCD provid[es] analog data as recited in the 399 patent. (Zadok Decl., 82.) Thus, the combination of

39 Ard, Schmidt, and Webb discloses the data transmit/receive device being arranged for providing analog data. 2. The combination of Ard, Schmidt, and Webb discloses the architectural elements of the interface device. Independent claims 1 and 11 each recite four identical architectural components of the interface device: (1) a processor [1A/11A], (2) a memory [1B/11B], (3) a first connecting device [1C/11C], and (4) a second connecting device [1D/11D]. Independent method claim 14 also recites a first connecting device and a second connecting device. The following table highlights the similarity between the architectural components of each claim. [1A/11A] a processor; [1B/11B] a memory; Claims 1 and 11 Claim 14 [1C/11C] a first connecting device for interfacing the host device with the interface device via the multi-purpose interface of the host device; and [1D/11D] a second connecting device for interfacing the interface device with the data transmit/receive device, [14A] interfacing of the host device with a first connecting device of the interface device via the multi-purpose interface of the host device; [14B] interfacing of the data transmit/receive device with a second connecting device of the interface device, [1E/11E/14C] the second connecting device including a sampling circuit for

40 Claims 1 and 11 Claim 14 sampling the analog data provided by the data transmit/receive device and [1F/11F/14D] an analog-to-digital converter for converting data sampled by the sampling circuit into digital data, [1G/11G] where[in] the interface device is configured [by/using] the processor and the memory to include a first command interpreter and a second command interpreter As set forth below, the combination of Ard, Schmidt, and Webb discloses each of these architectural components. 6 a) The combination of Ard, Schmidt, and Webb discloses that the interface devices comprise a processor and a memory. Ard s disk drive emulator 41 receives and processes commands from computer 2, and therefore constitutes the processor recited in claims 1 and 11. (Zadok Decl., ) 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 6 Claim limitations [1G]/[11G] are addressed in Section 3 below

41 Petition for Inter Partes Review of 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 also 5:66 to 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. As shown in Figure 5 (reproduced above), Ard s scanner 6 includes a memory 47 with 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.) In addition, memory 47 stores image data files resulting from operating scanner 6. (Zadok Decl., 86.)

42 For example, in Ard, image data resulting from operation of the disk drive emulating scanner 6 is directed to and saved as a file and that the file resides in the memory 47. (Ard, 7:55 57, 7:62 64; Zadok Decl., 86.) Accordingly, memory 47, 47A, and 47B constitute the recited memory. (Zadok Decl., 86.) b) The combination of Ard, Schmidt, and Webb discloses the first connecting device limitations. Independent claims 1 and 11 recite a first connecting device for interfacing the host device with the interface device via the multi-purpose interface of the host device. Similarly, independent claim 14 recites interfacing of the host device with a first connecting device of the interface device via the multi-purpose interface of the host device. Ard discloses these first connecting device limitations. The disk drive emulator 41 communicates with the general purpose computer 2 over the SCSI bus 4. (Ard, Figure 5; see also 5:56 57.) For this communication, general purpose computer 2 couples to SCSI bus 4 via a SCSI card 17 acting as a multi-purpose interface of the host computer. (Ard, Figure 3.) Figure 3, reproduced below, illustrates this configuration

43 (Ard, Figure 3.) Ard does not explicitly identify the components of the disk drive emulating scanner 6 that interface with the SCSI bus. (Zadok Decl., 88.) However, Schmidt discloses that a SCSI controller takes this role in SCSI peripheral devices. (Zadok Decl., 88; Schmidt, pp ( A computer system is connected to the SCSI bus through a host adapter. For a peripheral device the corresponding role is played by a controller. ).) Schmidt states that SCSI controllers are usually embedded in the drive electronics of disk drives. (Schmidt, p. 79.) It therefore would have been obvious to a person of ordinary skill in the art to include Schmidt s SCSI controller as part of Ard s SCSI-based scanner as a first connecting device for interfacing the

44 host device with the interface device via the multi-purpose interface of the host device. (Zadok Decl., 89.) This combination would result in nothing more than the use of a known device (a SCSI controller) for its known purpose (interfacing to a SCSI bus). (Zadok Decl., 89.) Petitioner illustrates the combined system in the below annotation of portions of Ard s Figures 3 and 5. The SCSI controller in the disk drive emulator 41 interfac[es] the host device with the interface device because it allows communication between the scanner and the general purpose computer via the SCSI card 17 ( multi-purpose interface ). (Zadok Decl., 89.) Ard further teaches that the interface is a SCSI interface: the interface between the host computer and disk drive emulator is a SCSI interface. (Ard, 3:13 15.) Accordingly, the combination of Ard, Schmidt, and Webb discloses a first connecting device for interfacing the host device with the interface device via the multi-purpose interface of the host device [1C]/[11C] and interfacing of the host

45 device with a first connecting device of the interface device via the multi-purpose interface of the host device [14A]. c) The combination of Ard, Schmidt, and Webb suggests the second connecting device limitations. Ard teaches that its scanner optics 45 include a Charge Coupling Device (CCD). (Ard, 6:7 10.) As shown above relative to the preambles, Webb illustrates a CCD array 14 connected to an analog-to-digital (A/D) converter 22. The figure below combines Figure 5 of Ard with Figure 1 of Webb to include the CCD and A/D circuitry as part of scanner optics 45. (Ard, Figure 5 and Webb, Figure (combined and annotated).) It would have been obvious to a person of ordinary skill in the art to include an A/D converter as part of scanner optics 45 because Ard s scanner operates on digital image data, and a CCD generates an analog signal. (Zadok Decl., 92.) The

46 Petition for Inter Partes Review of inclusion of an A/D converter as part of Ard s scanner optics would have been nothing more than the use of a known device (an A/D converter) for its known purpose (converting an analog signal from a CCD to a digital signal). (Zadok Decl., 92.) Such an A/D converter would have been included for interfacing the interface device with the data transmit/receive device because it would convert the analog signal generated by the CCD elements into a digital form suitable for handling by the interface device. (Zadok Decl., 92.) This image data, as Ard refers to it, can then be transfer[red] to the general purpose computer 2 via the SCSI bus 4. (Ard, 6:57 59.) Webb describes Figure 1 as a data sampling and conversion circuit. (Webb, 3:57 59.) A person of ordinary skill in the art would have understood that A/D converters typically included a sampling circuit such as a sample and hold circuit. (Zadok Decl., 93 (citing Ex. 1025, Oppenheim, p. 114); see also Ex. 1021, p. 1 ( The basic components required for the acquisition and conversion of analog signals into equivalent digital form are 2. Sample/Hold Amplifier ); Ex. 1022, p. 1, Figure 1 (illustrating a SAMPLE HOLD component coupled to the A/D converter).) The sampling circuit could be internal or external to the A/D converter. (Zadok Decl., 94 (citing Ex ( When the SHA is used with an ADC (either externally or internally). ) (further describing a famous PCM patent of 1939 where the sampling function was incorporated into the [pulse width modulator] ).)

47 Petition for Inter Partes Review of Webb s circuit includes a hold circuit 20 that act[s] as a buffer in the event data are shifted out of the last bucket Q1 faster than they can be converted into digital signals by the A/D converter 22. (Webb, 4:19 22.) A sampling circuit is beneficial because the conversion of an analog voltage to a quantized binary code does not take place instantaneously the sampling circuit holds the voltage at a single value for a short time period to allow conversion to complete before converting the next value. (Zadok Decl., 94 (citing Oppenheim, p. 114); see also Ex. 1021, p. 2 ( The need for a sample/hold becomes readily apparent when data frequencies of 10Hz or higher are sampled ).) The well-known 1980 book The Art of Electronics illustrates [a] 12-bit 16-channel successiveapproximation A/D converter system that includes a sample/hold circuit and an A/D converter. (Ex. 1017, Horowitz, p. 421, Figure 9.47; see also pp , ) Thus, it would have been obvious to a person of ordinary skill in the art to include an A/D converter and a sampling circuit, as taught by Webb, as part of Ard s disclosure of a CCD in the scanner optics. (Zadok Decl., 95.) This combination would have resulted in nothing more than the use of known devices (a sampling circuit and A/D converter) for their known purpose (sampling and converting an analog CCD signal to digital). (Zadok Decl., 95.) Accordingly, the combination of Ard, Webb, and Schmidt suggests to a person of ordinary skill in the

48 art the second connecting device including a sampling circuit for sampling the analog data provided by the data transmit/receive device [1E]/[11E]/[14C]. 3. The combination of Ard, Schmidt, and Webb discloses the recognition limitations of the independent claims. Claims 1 and 11 further require that the interface device is configured by the processor and the memory to include a first command interpreter [1G]/[11G]. These claims then recite actions by the first command interpreter related to receiving and responding to an inquiry from the host device (referred to generally as the recognition limitations). Method claim 14 recites similar recognition limitations but without specifying a first command interpreter. The following table highlights the similarity of the independent claims for the recognition limitations. Claim 1 Claim 11 Claim 14 [1H] wherein the first command interpreter is configured in such a way that the command interpreter, [11H] wherein the first command interpreter is configured in such a way that the interface device, [1I.1]/[11I.1] when receiving an inquiry from the host device as to a type of a device attached to the multipurpose interface of the host device [14E.1] inquiring by the host device at the interface device as to the type of device to which the multipurpose interface of the

49 Claim 1 Claim 11 Claim 14 host device is attached [1I.2]/[11I.2] sends a signal, regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device, to the host device which signals to the host device that it is an input/output device customary in a host device, [14E.2] regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device, responding to the inquiry from the host device by the interface device in such a way that it is an input/output device customary in a host device, whereupon the host device communicates with the interface device by means of the driver for the input/output device customary in a host device whereupon the host device communicates with the interface device by means of the specific driver for the multi-purpose interface whereupon the host device communicates with the interface device by means of the usual driver for the input/output device As set forth below, the combination of Ard, Schmidt, and Webb teaches or suggests each of these recognition limitations

50 a) The combination of Ard, Schmidt, and Webb discloses the inquiry and response elements of the recognition limitations. The combination of Ard, Schmidt, and Webb teaches or suggests an inquiry or inquiring as to a type of a device [attached to] the multi-purpose interface of the host device as required by independent claims 1, 11, and 14. The scanner of Ard emulates a hard disk: [w]hen attached to a 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; see also Ard s Title: Method and System for Operating a Scanner which Emulates a Disk Drive. ) A person of ordinary skill in the art would have recognized that the electronic signals identical to those of a standard disk drive provided by Ard s scanner would include a response to a SCSI INQUIRY command issued from the general purpose computer. (Zadok Decl., 98.) Schmidt explains that the 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.) Specifically, a computer system is connected to the SCSI bus through a host adapter and [f]or a peripheral device the corresponding role is played by a controller. (Schmidt, p. 79.) The SCSI standard supports a variety of device types, from disk drives to printers to scanners. (Schmidt, p. 132.)

51 Petition for Inter Partes Review of 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.) Among these mandatory commands is the inquiry command. (See Schmidt, p. 138, Table (showing the INQUIRY command as Type M ); p. 137, Table 12.8 (showing 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 ) Therefore, part of Ard s process of identifying the scanner as a hard disk would be to receive a SCSI INQUIRY from the general purpose computer, constituting an inquiry from the host device as to a type of a device attached to the multi-purpose interface of the host device. (Zadok Decl., 98.) Schmidt supports this understanding, explaining that the host SCSI adapter sends SCSI commands to devices such as Ard s general purpose computer 2. (See Schmidt, p. 80, Figure 9.1.) Schmidt provides detail about a device s response to the INQUIRY command. (Schmidt, pp ) In response to an INQUIRY command, a SCSI device provides a response including a five-bit device class or peripheral device type. (Schmidt, pp ; see also p. 132 ( Table 12.1 shows an example of the data returned from an INQUIRY command ).) One supported device class in SCSI is the hard disk class. (Schmidt, p. 133, Table 12.1.) Ard discloses that its scanner

52 Petition for Inter Partes Review of 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 person of ordinary skill in the art that, in response to an INQUIRY command, the scanner of Ard would respond as a hard disk, misidentifying itself as a member of the hard disk device class even though the scanner is not itself a hard disk. (Zadok Decl., 99.) Ard specifically motivates this combination with its disclosure that the scanner emulates a hard disk, interfaces with the workstation using SCSI, and sends electronic signals identical to those of a disk drive. (Zadok Decl., 99.) A hard disk is an input/output device customary in a host device. Indeed, dependent claim 2 of the 399 patent recognizes that a hard disk is a device type that is customary: the signal indicates to the host device that the host device is communicating with a hard disk. ( 399 patent, 13:13 17; see also claim 15, 14:62 65.) The combination of Ard, Schmidt, and Webb therefore teaches or suggests that the scanner is configured in such a way that when receiving an inquiry from the host device as to a type of a device attached to the multi-purpose interface of the host device, sends a signal to the host device which signals to the host device that it is an input/output device customary in a host device [1I.2]/[11I.2] and respond[s] to the inquiry from the host device by the interface device in such a way that it is an input/output device customary in a host device [14E.2].

53 And, this responsive signal is sent by the scanner in the combined system of Ard, Schmidt, and Webb regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device. (Zadok Decl., 101.) 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 below in Figure 12.1 of Schmidt. (Zadok Decl., 101.) (Schmidt, Table 12.1 (annotated).) Ard further states that [a] disk drive emulator is a device that has primary functions other than storing data, but would be identified by an attached computer as a conventional disk drive. (Ard, 9:1 3.) Schmidt also stresses that the SCSI interface is a device independent I/O bus that makes it possible to write device drivers for a device without knowing device specific details. (Schmidt, p. 79 (emphasis added).) Thus, given the disclosures of Schmidt and Ard, a person of ordinary skill in the art would

54 understand that the inquiry and response signal would be independent of the type of data transmit/receive device attached to the second connecting device of the interface device. (Zadok Decl., 103.) Ard s scanner includes a disk drive emulator [that] provides signals such that the general purpose computer identifies the scanner as a disk drive. (Ard, Abstract.) However, Ard does not explicitly disclose that the disk drive emulator acts as a command interpreter that handles an inquiry from the host device. Schmidt discloses that SCSI devices such as the scanner of Ard must be able to receive, understand, and respond to a SCSI INQUIRY command. (Schmidt, p. 138, Table (showing the INQUIRY command as Type M ); p. 137, Table 12.8 (showing Type M commands as Mandatory commands that must be implemented ).) Notably, the 399 patent does not assign any structure to the first command interpreter, instead merely describing its functions and stating that it may be part of the processor. (See 399 patent, 6:48 52; Zadok Decl., 105.) It therefore would have been obvious to a person of ordinary skill in the art, as suggested by these prior art disclosures, to implement a command interpreter to interpret and respond to the INQUIRY command in the manner described above. (Zadok Decl., 105.) Thus, the combination of Ard, Schmidt, and Webb suggests the recited first command interpreter

55 Petition for Inter Partes Review of Furthermore, it would have been obvious for the interface device to be configured by the processor and the memory to include the first command interpreter. As shown above, Ard s disk drive emulator constitutes the disclosed processor and also provides signals such that the general purpose computer identifies the scanner as a disk drive. (Ard, Abstract.) And as shown in Figure 5, the disk drive emulator is coupled to and interacts with the memory when emulating a hard disk. (See, Ard, 6:31 41; Zadok Decl., 106.) Accordingly, it would have been obvious to a person of ordinary skill in the art that any commands to the scanner would be processed as configured by the processor and memory. (Zadok Decl., 107.) b) The combination of Ard, Schmidt, and Webb teaches whereupon the host device communicates with the interface device by means of the [driver]. Ard discloses that [b]oth the scanner parameters setup program 11 and the graphics application 9 communicate with the disk drive emulating scanner 6 via the SCSI driver 13. (Ard, 5:25 30.) As Figure 5 shows, the communication is handled by the disk drive emulator, which is part of the interface device as Apple previously established. Thus, the general purpose computer ( host device ) communicates with the scanner ( interface device ) by means of the SCSI driver 13 ( driver. ) (Zadok Decl., 109.) As discussed above in the preamble section, the SCSI driver is specific for SCSI card 17 and usual for a disk drive, which is

56 customary in the host device. (Zadok Decl., 109, 100.) And, as discussed above, the SCSI card of the general purpose computer is a multi-purpose interface. Therefore, the combination discloses the host device communicates with the interface device by means of the specific driver for the multi-purpose interface as recited in claim 11. For the same reasons, the SCSI driver also constitutes a driver for the input/output device customary in a host device and usual for the input/output device as recited in claims 1 and 14 respectively. (Zadok Decl., 110; see, 399 patent, claims 2 and 15.) The driver is a part of the external host computer and therefore allows the host device [to] communicate[] with the interface device. (Zadok Decl., 111.) 4. The combination of Ard, Schmidt, and Webb discloses the transfer limitations of the independent claims. Claims 1 and 11 further require that the interface device is configured by the processor and the memory to include a second command interpreter [1G]/[11G]. These claims then recite actions by the second command interpreter related to receiving and responding to a data request command from the host device (referred to generally as the transfer limitations). Method claim 14 recites similar transfer limitations but without specifying a second command interpreter. The following table highlights the similarity of the independent claims for the recognition limitations

57 Claim 1 Claim 11 Claim 14 wherein the second command interpreter is configured to interpret a data request command from the host device to the type of input/output device signaled by the first command interpreter as a data transfer command for initiating a transfer of the digital data to the host device. interpreting a data request command from the host device to the type of input/output device customary in the host device as a data transfer command for initiating a transfer of the digital data to the host device. As set forth below, the combination of Ard, Schmidt, and Webb teaches or suggests each of the transfer limitations. a) The combination of Ard, Schmidt, and Webb teaches a data request command from the host device to the type of input/output device. The combination of Ard, Schmidt, and Webb teaches a data request command. In Ard, the disk drive emulator receiv[es] a File Open command directed toward the opening of a file. (Ard, 6:43 45.) As would be appreciated by a POSITA, the combined system of Ard and Schmidt would implement the File Open command with a SCSI Read command. (Zadok Decl., 117.) Schmidt describes a number of commands for reading data from a hard drive provided in the SCSI

58 standard. (Zadok Decl., ) As shown in Table 13.2 of Schmidt, reproduced below, these commands include READ(6), READ(10), READ BUFFER, and READ LONG. (Schmidt, p. 164, Table 13.2.) Schmidt discloses that support for the READ(6) and READ(10) commands is mandatory in the SCSI standard. (Zadok Decl., 117 (citing Schmidt, p. 164, Table (showing the READ(6) and READ(10) commands as Type M )); p. 137,

59 Petition for Inter Partes Review of Table 12.8 (showing Type M commands as Mandatory commands that must be implemented ).) It would have been obvious to a person of ordinary skill in the art to implement Ard s File Open command using a SCSI READ command because the general purpose computer communicates with the scanner using the SCSI bus. (Zadok Decl., 117; see Ard, 6:49 52.) For both the READ(6) and READ(10), [t]he READ command requests a certain number of logical blocks from a target and therefore constitutes the recited data request command. (Schmidt, p. 165; Zadok Decl., 117.) Furthermore, the SCSI READ command in the combined system is from the host device. (Zadok Decl., 118.) Ard states that the disk drive emulator 41 receives a File Open command from the SCSI bus 4, suggesting that the command is sent from the general purpose computer connected to the disk drive emulating scanner via SCSI bus 4. (Ard, 5:54 57; Zadok Decl., 118; see also Ard, Figures 3 and 5.) Moreover, Schmidt discloses that the host SCSI adapter (e.g., the SCSI card of Ard s general purpose computer) sends SCSI commands to peripheral devices. (See Schmidt, p. 80, Figure 9.1; Zadok Decl., 118.) The READ command is to the type of input/output device signaled by the first command interpreter as required by claims 1 and 11 and to the type of input/output device customary in the host device as required by claim 14 because, as Schmidt discloses in Table 13.2, the read request is a hard disk command in the SCSI specification and is therefore targeted

60 for the hard disk class signaled by Ard s scanner as discussed above. (Schmidt, p. 164.) b) The combination of Ard, Schmidt, and Webb teaches that a second command interpreter interpret[s] [the] data request command as a data transfer command for initiating a transfer of the digital data to the host device. Ard s scanner includes a disk drive emulator [that] provides signals such that the general purpose computer identifies the scanner as a disk drive. (Ard, Abstract.) However, Ard does not explicitly disclose that the disk drive emulator acts as a command interpreter that interpret[s] a data request command as a data transfer command for initiating a transfer of the digital data to the host device. Notably, the 399 patent does not assign any structure to the first command interpreter, instead merely describing its functions and stating that it may be part of the processor. (See 399 patent, 6:48 52; Zadok Decl., 119.) Schmidt discloses that SCSI hard disks must be able to receive, understand, and respond to a SCSI READ command. (Schmidt, p. 164, Table (showing the READ(6) and READ(10) commands as Type M ); p. 137, Table 12.8 (showing Type M commands as Mandatory commands that must be implemented ).) It therefore would have been obvious, based on these teachings of the prior art, to a person of ordinary skill in the art to implement a command interpreter to interpret and respond to the READ command in the manner described above. (Zadok Decl., 121.)

61 Ard further explains that 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:41 47.) Thus, it would have been obvious to a person of ordinary skill in the art for Ard s scanner to interpret a SCSI READ command as a data transfer command for initiating a transfer of the digital data to the host device. (Zadok Decl., 122.) This combination would result from the application of a known technique (interpreting a SCSI READ command as a request for data transfer) to a known device (Ard s disk drive-emulating SCSI scanner) for a known purpose (transferring data). (Zadok Decl., 122.) Furthermore, it would have been obvious for the interface device to be configured by the processor and the memory to include the second command interpreter. As shown above, Ard s disk drive emulator constitutes the disclosed processor and also provides signals such that the general purpose computer identifies the scanner as a disk drive. (Ard, Abstract.) And as shown in Figure 5, the disk drive emulator is coupled to and interacts with the memory when emulating a hard disk. (See, e.g., Ard, 6:31 41; Zadok Decl., 123.) Accordingly, it would have been obvious to a person of ordinary skill in the art that any commands to the

62 scanner would be processed as configured by the processor and memory. (Zadok Decl., 123.) Accordingly, the combination of Ard, Schmidt, and Webb teaches or suggests wherein the interface device is configured by the processor and the memory to include a second command interpreter wherein the second command interpreter is configured to interpret a data request command from the host device to the type of input/output device signaled by the first command interpreter as a data transfer command for initiating a transfer of the digital data to the host device as recited in independent claims 1 and 11 and interpreting a data request command from the host device to the type of input/output device customary in the host device as a data transfer command for initiating a transfer of the digital data to the host device as recited in independent claim 14. (Zadok Decl., 124.)

63 E. The combination of Ard, Schmidt, and Webb renders claim 3 obvious. Claim 3 depends from claim 1 and further recites wherein the memory means 7 comprises a buffer to buffer data to be transferred between the data transmit/receive device and the host device. A buffer was a well-known component prior to the earliest possible priority date of the 399 patent: [a] device in which data are stored temporarily, in the course of transmission from one point to another; used to compensate for a difference in the flow of data, or time of occurrence of events, when transmitting data from one device to another. (Ex. 1018, IEEE Dictionary, p. 113.) Ard discloses that image data resulting from operation of the disk drive emulating scanner 6 is directed to and saved as a file. (Ard, 7:55 57.) Specifically, the image data is directed to a file in the memory 47. (Ard, 7:62 64.) Once saved as a file, the image data is accessible to any application capable of reading image data. At step 109, an application reads the stored image data. (Ard, 7:57 59.) 7 For purposes of this proceeding, Apple assumes the term refers to the recited memory of claim 1. Additionally, although the term uses means, the term does not invoke 35 U.S.C. 112, sixth paragraph, because the limitation does not link the recited means to a specific function. See York Prod. Inc. v. Central Tractor Farm & Family Center, 99 F.3d 1568, 1574 (Fed. Cir. 1996)

64 Because the image data is stored in memory 47 before being transferred to the computer 2, a person of ordinary skill in the art would have recognized that Ard s memory 47 acts as a buffer to buffer data to be transferred between the data transmit/receive device and the host device. (Zadok Decl., ) VI. The combination of Ard, Schmidt, Webb, and Johnson renders claim 5 obvious. A. Overview of Johnson. Johnson is directed to a calibrated sensor board with a Charge Coupled Device (CCD) having two output signals. (Ex. 1047, Johnson, Abstract.) Johnson describes [a] number of difficulties [that] are associated with image scanner technology, including the transformation of an analog signal of the image into a digital signal of the image. (Johnson, 1:14 17.) Such problems include external factors which affect the quality of the resultant digital data as well as noise and saturation. (Johnson, 1:17 25.) Addressing these problems requires a great deal of processing power. (Johnson, 1:26 27.) Johnson discloses a scanner 20 that includes a Digital Signal Processing (DSP) board 104. (Johnson, 3:39 41.) The DSP board preferably includes a Motorola DSP digital signal processor that performs a variety of operations in real-time on the pixel data coming from the sensor board. (Johnson, 3:62 66.) Such operations include gamma correction, light source compensation, and image resizing. (Johnson, ) Thus, Johnson teaches a person of ordinary skill in the

65 art to use a digital signal processor for processing operations in a scanner. (Zadok Decl., 128.) B. The combination of Ard, Schmidt, Webb, and Johnson discloses that the processor is a digital signal processor as recited in claim 5. Claim 5 depends from claim 1 and further recites wherein the processor is a digital signal processor. A digital signal processor was also a well-known component prior to the earliest possible priority date of the 399 patent: [a]n integrated circuit designed for high-speed data manipulation and used in audio, communications, image manipulation, and other data acquisition and data control applications. (Ex. 1014, Microsoft Dictionary, p. 145 (emphasis added).) Ard does not explicitly disclose that its disk drive emulator is a digital signal processor. However, the use of the digital signal processor of Johnson in the system of Ard, Schmidt, and Webb would have been obvious to a person of ordinary skill in the art. (Zadok Decl., 130.) Ard s disk emulating scanner 6 stores a number of operational parameters, including Pixel Depth, Resolution, Brightness, Contrast, Gamma, Filter, [and] Page Size. (Ard, 3:31 35.) Ard discloses that the disk drive emulator 41 saves the scanner parameters 33 to a file in the memory 47. (Ard, 6:41 43.) When performing a scan, the disk drive emulating scanner performs a scan in accordance

66 with the saved parameters and transfers image data resulting therefrom to the general purpose computer. (Ard, 6:42 47.) A person of ordinary skill would have recognized that the processing corresponding to the Gamma parameter, for example, could be performed by a digital signal processor. (Zadok Decl., 131.) The Gamma parameter corresponds to the well-known technique of gamma correction. (Zadok Decl., 131 (citing Ex. 1051, Foley, pp ).) Johnson discloses that its digital signal processor performs a variety of operations in real-time on the pixel data coming from the sensor board 74, including gamma correction, light source compensation, and image resizing. (Johnson, 3:64 67.) It would have been obvious to a person of ordinary skill in the art to implement the known technique of gamma correction using a known DSP for its known purpose in Ard s scanner according to the Gamma parameter. (Zadok Decl., 131.) Digital signal processors were well known at the time of invention to be optimized for processing digital signals using programmable hardware. (Zadok Decl., 131.) Therefore, a person of ordinary skill in the art would have found it obvious to try a digital signal processing algorithm such as gamma correction disclosed in Johnson in the disk drive emulating scanner of Ard. (Zadok Decl., 131.) Accordingly, the combination of Ard, Schmidt, Webb, and Johnson renders claim 5 obvious

67 VII. Conclusion. For the reasons provided above, inter partes review of claims 1, 3, 5, 11, and 14 of is requested. Respectfully submitted, STERNE, KESSLER, GOLDSTEIN & Fox P.L.L.C. Date: October 11, 2016 Lei A. AGoo Registration No. 50,633 Attorney for Petitioner 1100 New York Avenue, N.W Washington, D.C (202)

68 APPENDIX A - LISTING OF CHALLENGED CLAIMS 1. I1PI An interface device for communication between a host device...and a data transmit/receive device I1P.21 which comprises drivers for input/output devices customary in a host device and a multi-purpose interface, I11.31 the data transmit/receive device being arranged for providing analog data, comprising: [la] a processor; [111I a memory; I1C1I a first connecting device for interfacing the host device with the interface device via the multi-purpose interface of the host device; and [1D] a second connecting device for interfacing the interface device with the data transmit/receive device, [1E] the second connecting device including a sampling circuit for sampling the analog data provided by the data transmit/receive device and [if] an analog-to-digital converter for converting data sampled by the sampling circuit into digital data, [1G] wherein the interface device is configured by the processor and the memory to include a first command interpreter and a second command interpreter,

69 [ihi wherein the first command interpreter is configured in such a way that the command interpreter, [11.1] when receiving an inquiry from the host device as to a type of a device attached to the multi-purpose interface of the host device, [11.2] sends a signal, regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device, to the host device which signals to the host device that it is an input/output device customary in a host device, [1.1.3] whereupon the host device communicates with the interface device by means of the driver for the input/output device customary in a host device, and Fiji wherein the second command interpreter is configured to interpret a data request command from the host device to the type of input/output device signaled by the first command interpreter as a data transfer command for initiating a transfer of the digital data to the host device. 3. An interface device according to claim 1, wherein the memory means comprises a buffer to buffer data to be transferred between the data transmit/receive device and the host device. 5. An interface device according to claim 1, wherein the processor is a digital signal processor.

70 Petition for Inter Panes Review of P.11 An interface device for communication between a host device,... and a data transmit/receive device, II11 P.2 11 which comprises a multi-purpose interface and a specific driver for this interface, 11 1P.31 the data transmit/receive device being arranged for providing analog [h Al comprising: a processor; I11BII a memory; [11C] a first connecting device for interfacing the host device with the interface device via the multi-purpose interface of the host device; and [ 11DJ a second connecting device for interfacing the interface device with the data transmit/receive device, [11E] the second connecting device including a sampling circuit for sampling the analog data provided by the data transmit/receive device and [11 F1 an analog-to-digital converter for converting data sampled by the sampling circuit into digital data, [11 GI where the interface device is configured using the processor and the memory to include a first command interpreter and a second command interpreter, [11H] wherein the first command interpreter is configured in such a way that the interface device,

71 [111.1] when receiving an inquiry from the host device as to the type of a device attached at the multi-purpose interface of the host device, [111.2] sends a signal, regardless of the type of the data transmit/receive device attached to the second connecting device of the interface device, to the host device which signals to the host device that it is an input/output device customary in a host device, [111.3] whereupon the host device communicates with the interface device by means of the specific driver for the multi-purpose interface, and [11J] wherein the second command interpreter is configured to interpret a data request command from the host device to the type of input/output device signaled by the first command interpreter as a data transfer command for initiating a transfer of the digital data to the host device. 14. [14P] A method of communication between a host device,.., and a data transmit/receive device... via an interface device, [14P.2] which comprises drivers for input/output devices customary in a host device and a multi-purpose interface, 114P.3] the data transmit/receive device being arranged for providing analog data, comprising: [14A] interfacing of the host device with a first connecting device of the interface device via the multi-purpose interface of the host device;

72 11 14B11 interfacing of the data transmit/receive device with a second connecting device of the interface device, 114CJ the second connecting device including a sampling circuit for sampling the analog data provided by the data/transmit/receive device and [14D] an analog-to-digital converter for converting data sampled by the sampling circuit into digital data; 114E.11 inquiring by the host device at the interface device as to the type of device to which the multi-purpose interface of the host device is attached; [14E.21 regardless of the type of the data transmit/receive data attached to the second connecting device of the interface device, responding to the inquiry from the host device by the interface device in such a way that it is an input/output device customary in a host device, 114E.31 whereupon the host device communicates with the interface device by means of the usual driver for the input/output device, [14F] and interpreting a data request command from the host device to the type of input/output device customary in the host device as a data transfer command for initiating a transfer of the digital data to the host device.

73 CERTIFICATION OF SERVICE (37 C.F.R. 42.6(e), (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. 6,470,399, the accompanying Power of Attorney, and all associated exhibits were served in their entireties on the following parties via FedExfi: Marshall, Gerstein & Borun LLP 233 South Wacker Drive 6300 Willis Tower Chicago, IL PAIR Correspondence Address for US.P.N. 6,470,399 Christopher V. Goodpastor Andrew G. DiNovo DiNovo Price Ellwanger & Hardy LLP 7000 N. MoPac Expressway, Suite 350 Austin, Texas Date: October 11, New York Avenue, N.W. Washington, D.C (202) STERNE, KESSLER, GOLDSTEIN & Fox P.L.L.C. eul ~~ Lori A. Gordon, Reg. No. 50,633 Attorney for Petitioner

74 CERTIFICATE OF COMPLIANCE WITH TYPE-VOLUME LIMITATION, TYPEFACE REQUIREMENTS, AND TYPE STYLE REQUIREMENTS I. This Petition complies with the type-volume limitation of 14,000 words, comprising 11,634 words, excluding the parts exempted by 37 C.F.R (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, STERNE, KESSLER, GOLDSTEIN & Fox P.L.L.C. Gordon Registration No. 50,633 Attorney for Petitioner