Patent No. 6,516,236
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_______________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________
`
`ROCKWELL AUTOMATION, INC.
`ROCKWELL AUTOMATION TECHNOLOGIES, INC.
`
`Petitioners
`
`v.
`
`AUTOMATION MIDDLEWARE SOLUTIONS, INC.
`Patent Owner
`
`Patent No. 6,516,236
`Issue Date: February 4, 2003
`Title: MOTION CONTROL SYSTEMS
`
`_______________
`
`Inter Partes Review No. 2017-00048
`
`____________________________________________________________
`
`DECLARATION OF WILLIAM RIZZI IN SUPPORT OF PETITION FOR
`INTER PARTES REVIEW OF U.S. PAT. NO. 6,516,236
`
`4831-7417-0426.3
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`TABLE OF CONTENTS
`
`I.
`
`PROFESSIONAL BACKGROUND AND TECHNICAL
`EXPERTISE .................................................................................................... 1
`
`II. MATERIALS CONSIDERED ........................................................................ 7
`
`III. LEGAL PRINCIPLES ..................................................................................... 7
`
`A. Motivations to Combine ......................................................................10
`
`B.
`
`Secondary Considerations ...................................................................12
`
`IV. THE ’236 PATENT .......................................................................................13
`
`V.
`
`LEVEL OF ORDINARY SKILL IN THE ART ...........................................19
`
`VI. CLAIM CONSTRUCTION ..........................................................................20
`
`VII. TECHNICAL BACKGROUND AND INTRODUCTION OF
`APPLIED PRIOR ART REFERENCES .......................................................23
`
`A. Device Drivers and Hardware Independence Were Well Known
`Long Before the ’236 Invention. .........................................................23
`
`1.
`
`Device Drivers and Hardware Independence in
`Microsoft’s Prior Art Operating Systems .................................23
`
`2. Windows Open Service Architecture (“WOSA”) and the
`Open Database Connectivity (“ODBC”) Interface ...................25
`
`Programmable Motion Control and Hardware-Independent
`Motion Control Operations Long Predated the Supposed ’236
`Invention ..............................................................................................26
`
`RGB’s Development of XMC Shows that the ’236 Inventors
`Merely Combined Known Technologies in a Predictable Way ..........36
`
`B.
`
`C.
`
`VIII. EXPLANATION OF THE GROUNDS FOR UNPATENTABILITY.........41
`
`A. Obviousness: Content of the Applied Prior Art References ...............41
`
`1. WOSA – Cashin and ODBC Programmer’s Guide ..................42
`
`4831-7417-0426.3
`
`i
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`2. Motion Control References – GML and Motion Toolbox .......46
`
`a.
`
`Graphical Motion Control Language (“GML”) .............46
`
`b. Motion Toolbox ..............................................................50
`
`B.
`
`C.
`
`Obviousness: Motivations to Combine Cashin with ODBC
`Programmer’s Guide and either of the Motion Control
`References (GML or Motion Toolbox) ...............................................52
`
`Ground 1: Claims 1-3 Are Unpatentable as Obvious under 35
`U.S.C. § 103 over Cashin in View of ODBC Programmer’s
`Guide and the GML References ..........................................................61
`
`1.
`
`Claim 1 ......................................................................................61
`
`a.
`
`Cashin alone or in combination with the ODBC
`Programmer’s Guide discloses every limitation of
`elements 1(a), 1(d), 1(e), 1(g)-1(i), and 1(k) of
`claim 1 ............................................................................61
`
`(i)
`
`(ii)
`
`(iii)
`
`(iv)
`
`[1a] “A system for generating a sequence of
`control commands for controlling a selected
`motion control device selected from a group
`of supported motion control devices,
`comprising:” .........................................................61
`
`[1d] “a core set of core driver functions,
`where each core driver function is associated
`with one of the primitive operations” ...................62
`
`[1e] “an extended set of extended driver
`functions, where each extended driver
`function is associated with one of the non-
`primitive operations” ............................................68
`
`[1g] “component code associated with each
`of the component functions, where the
`component code associates at least some of
`the component functions with at least some
`of the driver functions” ........................................69
`
`4831-7417-0426.3
`
`ii
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`(v)
`
`(vi)
`
`(vii)
`
`[1h] “a set of software drivers, where each
`software driver is associated with one
`motion control device in the group of
`supported motion control devices, each
`software driver comprises driver code for
`implementing the motion control operation
`with at least some of the driver functions,
`and”.......................................................................72
`
`[1i] “one of the software drivers in the set of
`software drivers is a selected software
`driver, where the selected software driver is
`the software driver associated with the
`selected motion control device” ...........................78
`
`[1k] “a motion control component for
`generating the sequence of control
`commands for controlling the selected
`motion control device based on the
`component functions of the application
`program, the component code associated
`with the component functions, and the driver
`code associated with the selected software
`driver.” ..................................................................79
`
`b.
`
`It would have been obvious to combine Cashin and
`the ODBC Programmer’s Guide with the GML
`reference to achieve elements (b), (c), (f), and (j)
`of claim 1 ........................................................................81
`
`(i)
`
`[1b] “a set of motion control operations,
`where each motion control operation is
`either a primitive operation the
`implementation of which is required to
`operate motion control devices and cannot
`be simulated using other motion control
`operations or” .......................................................81
`
`(ii)
`
`[1c] “a non-primitive operation that does not
`meet the definition of a primitive operation” .......82
`
`4831-7417-0426.3
`
`iii
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`(i)
`
`(ii)
`
`[1f] “a set of component functions” .....................83
`
`[1j] “an application program comprising a
`series of component functions, where the
`application program defines the steps for
`operating motion control devices in a
`desired manner; and” ............................................86
`
`2.
`
`Claim 2 ......................................................................................87
`
`a.
`
`b.
`
`[2a] “A system as recited in claim 1, in which:” ............87
`
`[2b] “the software drivers comprise driver code for
`implementing all of the core driver functions” ..............87
`
`3.
`
`Claim 3 ......................................................................................88
`
`a.
`
`b.
`
`[3a] “A system as recited in claim 1, in which” .............88
`
`[3b] “the software drivers comprise driver code for
`implementing at least some of the extended driver
`functions” ........................................................................88
`
`D. Ground 2: Claims 1-3 Are Unpatentable as Obvious under 35
`U.S.C. § 103 over Cashin in View of ODBC Programmer’s
`Guide and Motion Toolbox .................................................................89
`
`1.
`
`Claim 1 ......................................................................................89
`
`a.
`
`b.
`
`Cashin by itself or in combination with the ODBC
`Programmer’s Guide discloses every limitation of
`elements 1(a), 1(d), 1(e), 1(g)-1(i), and 1(k) of
`claim 1 ............................................................................89
`
`It would have been obvious to combine Cashin and
`the ODBC Programmer’s Guide with Motion
`Toolbox to achieve elements (b), (c), (f), and (j) of
`claim 1 ............................................................................90
`
`(i)
`
`[1b] “a set of motion control operations,
`where each motion control operation is
`either a primitive operation the
`implementation of which is required to
`iv
`
`4831-7417-0426.3
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`operate motion control devices and cannot
`be simulated using other motion control
`operations or” .......................................................90
`
`(ii)
`
`[1c] “non-primitive operations that may be
`simulated using a combination of primitive
`operations” ............................................................91
`
`(iii)
`
`[1f] “a set of component functions” .....................92
`
`(iv)
`
`[1j] “an application program comprising a
`series of component functions, where the
`application program defines the steps for
`operating motion control devices in a
`desired manner; and” ............................................93
`
`2.
`
`3.
`
`Claim 2 ......................................................................................94
`
`Claim 3 ......................................................................................94
`
`IX. SIGNATURE .................................................................................................95
`
`
`
`
`
`4831-7417-0426.3
`
`v
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`1.
`
`I, William Rizzi, have been retained by Foley & Lardner LLP, counsel for
`
`Rockwell Automation, Inc. and Rockwell Automation Technologies, Inc.
`
`(collectively, “Rockwell”). I understand that Rockwell has petitioned for inter
`
`partes review (“IPR”) of U.S. Patent No. 6,516,236 (the “’236 Patent”) and request
`
`that the United States Patent and Trademark Office cancel Claims 1-3 of the ’236
`
`Patent as unpatentable. The following discussion and analyses address the bases
`
`for Rockwell’s petition.
`
`I.
`
`PROFESSIONAL BACKGROUND AND TECHNICAL EXPERTISE
`
`2. A detailed list of my educational and professional experience, honors, and
`
`publications is found in my curriculum vitae attached and submitted as Exhibit A
`
`to this declaration.
`
`3.
`
`I received a Bachelor’s Degree in Electrical Engineering and Computer
`
`Science from the Massachusetts Institute of Technology and a Bachelor’s degree in
`
`Management Science from the MIT Sloan School of Management, both in 1977.
`
`4. After graduation, I started my career as a software engineer and have been
`
`developing software for almost 40 years in a wide variety of languages and
`
`technologies for a wide variety of applications. My software development work
`
`over the years has been on either a consulting basis or as an employee for such
`
`companies as Motion Engineering, Inc., Texas Instruments, Unisys, Sandpiper
`
`Networks, Santa Barbara Automation, and Digital Instruments/Veeco/Bruker.
`1
`
`4831-7417-0426.3
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`5. A significant portion of my experience over the years has been software
`
`development in motion control contexts. The following paragraphs describe a few
`
`such examples.
`
`6. For example, I designed and developed software on two different
`
`occasions for a company in the motion control space named Motion Engineering,
`
`Inc. (“MEI”). In 1992, MEI’s motion control library was an API of C functions
`
`designed for use on the MS-DOS operating system. Users could use this API to
`
`perform motion operations using MEI’s motion controller which was named the
`
`“PC/DSP.” This API is briefly discussed in the IPR petition in §VI.B and is
`
`included as Ex. 1025. I converted this MS-DOS API of C functions so that the
`
`motion control library could be used on the LynxOS operating system. LynxOS is
`
`a real-time UNIX-like operating system that ran on 80x86 personal computers.
`
`7. MEI engaged me again in 1996 on a long-term project to design and
`
`develop a new object-oriented “C” language motion control software library for
`
`their upcoming high performance motion controller called the XMP. The XMP
`
`controller had a PCI (Peripheral Component Interconnect) bus that allowed it to
`
`reside in an internal PCI bus slot in most personal computers of that era. The XMP
`
`used a high-performance Digital Signal Processor (DSP) chip to run real-time
`
`motion control firmware, i.e., a software program that was “permanently” persisted
`
`on the XMP board’s EEPROM (Electrically Erasable Programmable Read Only
`
`4831-7417-0426.3
`
`2
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`Memory). The board firmware could be updated by running a special internally
`
`available program. The XMP board’s main memory could be mapped via the PCI
`
`bus to be directly accessible for read/write by an application running on a PC.
`
`8. For this project, I first spent a couple of months working on and
`
`understanding the PC/DSP “C” language software library described above in order
`
`to become familiar with relatively simple motion control in general as well as with
`
`the software interface used by PC/DSP controller customers. I then began the
`
`design and development of the motion control software library for the new XMP
`
`motion controller; it was called the Motion Programming Interface (“MPI”). The
`
`software product manager and I had worked together in 1984 at a previous
`
`company where we both learned how to write portable real-time object-oriented
`
`code in the “C” language. We were taught by Robert Frankel, who ultimately
`
`became one of only 40 Texas Instrument Fellows. I worked with him again at a
`
`company he helped found (Spectron Microsystems) where in 1989 we developed a
`
`DSP (Digital Signal Processor) operating system that was purchased by Texas
`
`Instruments and became what is now their DSP-BIOS product. Regarding the
`
`MPI, based on our shared experience with Bob Frankel, I had the full confidence
`
`of my manager to design and implement the MPI interface and library from scratch
`
`as I saw fit. There was a requirement that the MPI be platform-independent, i.e.,
`
`4831-7417-0426.3
`
`3
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`that it had to be able to run on virtually any operating system and be built with any
`
`C compiler.
`
`9.
`
`I had the opportunity to work directly and almost daily with a founder of
`
`MEI, Robert Steele. Bob was responsible for writing the XMP firmware where all
`
`the low-level motion control was handled; he would also produce custom XMP
`
`firmware for large volume customers when required. I did not necessarily have to
`
`understand all the details of what Bob was doing – I simply had to express in the
`
`MPI library the necessary parameters for the various types of motion and hardware
`
`(e.g., analog and digital I/O) supported by the firmware.
`
`10. I was free to make design decisions in the development of the MPI library.
`
`I could have produced a library specific to the XMP but it occurred to me that I
`
`might be able to build a library that could work for both the XMP and PC/DSP
`
`controllers. In the case of the PC/DSP, it would mean simply translating from new
`
`MPI library functions to existing PC/DSP library functions, though not all MPI
`
`functions would be available on the PC/DSP.
`
`11. This then led me to consider whether it might be possible to translate from
`
`MPI library functions to motion control libraries from other motion controller
`
`manufacturers. While MEI was currently only interested in MPI supporting MEI
`
`motion controllers, I remained convinced that making the MPI as generic as
`
`possible was a good design decision nonetheless.
`
`4831-7417-0426.3
`
`4
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`12. The design I came up with had three software layers from top to bottom:
`
`MPI, MEI and XMP. The topmost MPI software layer provided a generic motion
`
`control interface. The design concept for the middle layer was that it would be
`
`manufacturer-specific and contain whatever was common to all of a particular
`
`manufacturer’s controllers. The middle layer for Motion Engineering was called
`
`MEI but at release it supported only the XMP motion controller. Finally the
`
`bottom layer would be motion controller-specific; for MEI this layer was called
`
`XMP. Thus, the generic MPI layer made calls into the manufacturer-specific MEI
`
`layer which made calls
`
`into
`
`the controller-specific XMP
`
`layer which
`
`communicated directly with the XMP motion controller via shared memory and
`
`interrupts.
`
`13. Development of the initial version of the MPI library was completed in
`
`mid-1997. MPI-based motion applications can operate in complex real-time,
`
`multi-threaded client-server environments. Platforms supported include Windows
`
`2000, NT, 95, RTSS (a real-time Windows NT subsystem), PharLap ETS,
`
`VxWorks, LynxOS, and QNX. Where relevant, I have provided additional details
`
`regarding the design and development of MPI below.
`
`14. I also designed and developed motion control software for Veeco (formerly
`
`Digital Instruments and now owned by Bruker) from 2002 - 2008. Digital
`
`Instruments productized an atomic force microscope invented by its founder while
`
`4831-7417-0426.3
`
`5
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`a professor at UCSB (University of California Santa Barbara) – it became known
`
`as the NanoScope V atomic force microscope. While with Veeco, I worked on a
`
`number of different software projects including software for the Windows platform
`
`that could be used to control and interact with Veeco’s microscopes. As one
`
`exemplary software project, I designed and implemented a generic motion control
`
`library to operate a variety of multi-axis stages of the microscopes, each of which
`
`uses different motion controller hardware and software.
`
`15. As another example, I designed and developed software relating to motion
`
`control for Agile Systems, Inc. in 2001. For Agile, I ported the MaxLib C++
`
`motion library to the PharLap real-time operating system. I also designed and
`
`developed an IEEE1394 interface for MaxLib and participated in the design of a
`
`FireWire-based daughter card for the Max3040 motion controller which included
`
`modifications to and extension of the Max motion control protocol. I additionally
`
`designed and built a socket-based client/server interface for MaxLib which allowed
`
`remote control of a Max motion controller running on a real-time operating system
`
`by a Windows-based graphical user interface.
`
`16. I also did significant motion control work for Calient Technologies in 2007
`
`– 2008. Calient makes optical fiber network switches that use movable mirrors in
`
`the tips of the connecting fiber cables. Maintenance of the optical switch
`
`connection is done using a digital signal processor (“DSP”). I designed and
`
`4831-7417-0426.3
`
`6
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`developed software for the both the DSP and a Linux management application.
`
`The Linux management application was designed to be remote from the DSP and
`
`could setup and maintain the switch connection using the DSP. The developed
`
`software involved a significant amount of motion control programming in that the
`
`mirrors of the cables needed to be moved appropriately to maintain the optical
`
`connection between fibers based on environmental changes in the cables due to
`
`external factors such as expansion/contraction due to temperature change. The
`
`Linux application controlled the DSP using remote procedure calls.
`
`17. I am a named inventor on two patents relating to user interfaces for
`
`telemedicine devices.
`
`II. MATERIALS CONSIDERED
`18. Attached as Exhibit B is a listing of the documents that I have considered
`
`and reviewed in connection with providing this report.
`
`III.
`
`LEGAL PRINCIPLES
`
`19. I am not a patent attorney nor am I an expert on patent law. I understand
`
`that 35 U.S.C. § 103 governs the determination of obviousness. According to 35
`
`U.S.C. § 103:
`
`A patent may not be obtained though the invention is not identically
`disclosed or described as set forth in section 102 of this title, if the
`differences between the subject matter sought to be patented and the
`prior art are such that the subject matter as a whole would have been
`
`4831-7417-0426.3
`
`7
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`obvious at the time the invention was made to a person of ordinary
`skill in the art to which the subject matter pertains.
`
`20. I further understand that the four factors to be considered in an obviousness
`
`inquiry are: (1) the scope and content of the prior art; (2) the differences between
`
`the prior art and the claims; (3) the level of ordinary skill in the pertinent art; and
`
`(4) secondary considerations including long-felt need, commercial success, and
`
`unexpected results to the extent they exist.
`
`21. I understand that whether there are any relevant differences, between the
`
`prior art and the claimed invention, is to be analyzed from the view of a person of
`
`ordinary skill in the art at the time of the invention. A person of ordinary skill in
`
`the art (“POSA”) is a hypothetical person who is presumed to be aware of all of the
`
`relevant art at the time of the invention. The person of ordinary skill is not an
`
`automaton, and may be able to fit together the teachings of multiple patents
`
`employing ordinary creativity and the common sense that familiar items may have
`
`obvious uses in another context or beyond their primary purposes.
`
`22. In analyzing the relevance of the differences between the claimed
`
`invention and the prior art, I understand that I must consider the impact, if any, of
`
`such differences on the obviousness or non-obviousness of the invention as a
`
`whole, not merely some portion of it. The person of ordinary skill faced with a
`
`4831-7417-0426.3
`
`8
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`problem is able to apply his or her experience and ability to solve the problem and
`
`look to any available prior art to help solve the problem.
`
`23. An invention is obvious if a person of ordinary skill in the art, facing the
`
`wide range of needs created by developments in the field, would have seen an
`
`obvious benefit to the solutions tried by the applicant. When there is a design need
`
`or market pressure to solve a problem and there are a finite number of identified,
`
`predictable solutions, it would be obvious to a person of ordinary skill to try the
`
`known options. If a technique has been used to improve one device, and a person
`
`of ordinary skill in the art would recognize that it would improve similar devices in
`
`the same way, using the technique would have been obvious.
`
`24. I understand that I do not need to look for precise teaching in the prior art
`
`directed to the subject matter of the claimed invention. I understand that I may take
`
`into account the inferences and creative steps that a person of ordinary skill in the
`
`art would have employed in reviewing the prior art at the time of the invention. For
`
`example, if the claimed invention combined elements known in the prior art and
`
`the combination yielded results that were predictable to a person of ordinary skill
`
`in the art at the time of the invention, then this evidence would make it more likely
`
`that the claim was obvious. On the other hand, if the combination of known
`
`elements yielded unexpected or unpredictable results, or if the prior art teaches
`
`4831-7417-0426.3
`
`9
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`away from combining the known elements, then this evidence would make it more
`
`likely that the claim that successfully combined those elements was not obvious.
`
`25. In determining whether a claimed invention is invalid for obviousness, one
`
`should consider the scope and content of the prior art, the level of ordinary skill in
`
`the relevant art, the differences between the claimed invention and the prior art,
`
`and whether the claimed invention would have been obvious to one of ordinary
`
`skill in the art in light of those differences. I understand that hindsight must not be
`
`used when comparing the prior art to the invention for obviousness.
`
`A. Motivations to Combine
`26. I understand that a claimed invention may be obvious if some teaching,
`
`suggestion or motivation that would have led a person of ordinary skill in the art to
`
`combine the invalidating references exists. I further understand that this suggestion
`
`or motivation may come from such sources such as explicit statements in the prior
`
`art, or from the knowledge of one of ordinary skill in the art. Alternatively, any
`
`need or problem known in the field at the time and addressed by the patent may
`
`provide a reason for combining elements of the prior art. I also understand that
`
`when there is a design need or market pressure, and there are a finite number of
`
`predictable solutions, a person of ordinary skill may be motivated to apply both his
`
`skill and common sense in trying to combine the known options in order to solve
`
`the problem.
`
`4831-7417-0426.3
`
`10
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`27. I understand that obviousness may also be shown by demonstrating that it
`
`would have been obvious to modify what is taught in a single piece of prior art to
`
`create the patented invention. Obviousness may be shown by showing that it would
`
`have been obvious to combine the teachings of more than one item of prior art. In
`
`determining whether a piece of prior art could have been combined with other prior
`
`art or with other information within the knowledge of one of ordinary skill in the
`
`art, I understand that the following are examples of approaches and rationales that
`
`have been provided by the PTO for consideration in evaluating obviousness:
`
`• “Combining prior art elements according to known methods to yield
`
`predictable results” (Rationale A);
`
`• “Simple substitution of one known element for another to obtain
`
`predictable results” (Rationale B);
`
`• “Use of a known technique to improve similar devices (methods, or
`
`products) in the same way” (Rationale C);
`
`• “Applying a known technique to a known device (method, or product)
`
`ready for improvement to yield predictable results” (Rationale D);
`
`• Applying a technique or approach that would have been “‘obvious to try’
`
`– (choosing from a finite number of identified, predictable solutions, with
`
`a reasonable expectation of success)” (Rationale E);
`
`4831-7417-0426.3
`
`11
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`• “Known work in one field of endeavor may prompt variations of it for
`
`use in either the same field or a different one based on design incentives
`
`or other market forces if the variations would have been predictable to
`
`one of ordinary skill in the art” (Rationale F); or
`
`• “Some teaching, suggestion, or motivation in the prior art that would
`
`have led one of ordinary skill to modify the prior art reference or to
`
`combine prior art reference teachings to arrive at the claimed invention.”
`
`(Rationale G).
`
`I understand that these rationales and explanatory examples are set forth in MPEP
`
`§ 2143, which I have reviewed for background.
`
`Secondary Considerations
`
`B.
`28. I understand that certain objective factors, sometimes known as “secondary
`
`considerations,” may also be taken into account in determining whether a claimed
`
`invention would have been obvious. In most instances, these secondary
`
`considerations of non-obviousness are raised by the patentee. In that context, the
`
`patentee argues an invention would not have been obvious in view of these
`
`considerations, which include: (a) commercial success of a product due to the
`
`merits of the claimed invention; (b) a long-felt, but unsatisfied need for the
`
`invention; (c) failure of others to find the solution provided by the claimed
`
`invention; (d) deliberate copying of the invention by others; (e) unexpected results
`
`4831-7417-0426.3
`
`12
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`achieved by the invention; (f) praise of the invention by others skilled in the art; (g)
`
`lack of independent simultaneous invention within a comparatively short space of
`
`time; (h) teaching away from the invention in the prior art. I also understand that
`
`these objective indications are only relevant to obviousness if there is a connection,
`
`or nexus, between them and the invention covered by the patent claims.
`
`29. I understand that certain “secondary considerations,” such as independent
`
`invention by others within a comparatively short space of time, indicates
`
`obviousness.
`
`30. I also understand that secondary considerations of nonobviousness are
`
`inadequate to overcome a strong showing on the primary considerations of
`
`obviousness. For example, where the inventions represented no more than the
`
`predictable use of prior art elements according to their established functions, the
`
`secondary considerations are inadequate to establish nonobviousness.
`
`IV. THE ’236 PATENT
`31. I have read the entirety of the ’236 Patent. I understand the ’236 Patent
`
`was filed Dec. 10, 2001 but alleges priority, through other applications and patents,
`
`to May 30, 1995.
`
`32. The ’236 Patent describes “interface software that facilitates the creation of
`
`hardware independent motion control software” for moving objects. (‘236 Patent
`
`at 1:13-15; 3:58.) The system runs on a personal computer and is connected to
`
`4831-7417-0426.3
`
`13
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`motion control devices – described as hardware controllers combined with
`
`mechanical systems – via a hardware bus. (Id. at 6:6-29.)
`
`33. The general architecture of the ’236 Patent’s software system is depicted in
`
`Figure 1 of the patent. An annotated version of Figure 1 combining Figures 1A-1F
`
`is shown below:
`
`(Id. at FIGS. 1A-1F.) As shown in this Figure, the disclosed system can generally
`
`be broken down into six components: (1) the application program (boxed in red);
`14
`
`4831-7417-0426.3
`
`
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`(2) the DDE server (boxed in yellow); (3) the motion control component and
`
`motion control driver stub (boxed in orange); (4) the software drivers (boxed in
`
`green); (5) the stream transport layer (boxed in purple); and (6) the motion control
`
`devices (boxed in blue).
`
`34. The ’236 Patent states that the disclosed software system allows
`
`programmers to create applications that move and control motion control devices.
`
`(Id. at 5:35-38.) The system as described allows the application programmers to
`
`create these motion control applications without extensive knowledge of the
`
`requirements of or control language used by any specific motion control device.
`
`(Id. at 6:53-67; 7:1-4.) Instead, the disclosed system proposes a theoretical set of
`
`“abstract” motion operations. (Id. at 7:20-27.) These motion operations are
`
`abstract in the sense that they are general physical actions to be performed by a
`
`motion control device but the actions are not tied to a particular make and model of
`
`motion control device. (Id.) These operations would thus generally be said in the
`
`art to be “hardware-independent.”
`
`35. The described software system then allows application programmers to
`
`utilize this theoretical set of abstract motion operations to design a hardware-
`
`independent motion program that is not tied to a particular motion hardware
`
`configuration – the “application program” boxed in red in Figure 1 above.
`
`4831-7417-0426.3
`
`15
`
`RA v. AMS
`Ex. 1002
`
`

`
`Patent No. 6,516,236
`
`36. These application programs utilize this theoretical abstract set of motion
`
`operations by using an application programming interface or “API.” (Id. at 7:54-
`
`65.) This API is taught as containing the definition of a set of “component
`
`functions” that application programmers could include or “call” in their application
`
`programs to cause motion in the targeted devices. (Id. at 7:54-65; 8:26-35.) The
`
`component functions defined by the ’236 Patent would be comprised of the
`
`theoretical abstract set of motion operations. (Id.)
`
`37. The software system of the ’236 Patent also includes a service provider
`
`interface (“SPI”), component code, and software drivers containing driver code.
`
`(Id. at 7:39-67; 8:1-14.) The component code of the disclosed system implements
`
`the component functions of the API and this component code is included in the
`
`motion control component boxed in orange in Figure 1 above.
`
`38. The disclosed system includes a DDE server boxed in yellow in Figure 1
`
`above. I understand “DDE” stands for “Dynamic Data Exchange” an