blacr@foster.com
`
`Registration No.: 40514
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________
`
`ABB, INC.
`
`Petitioner
`
`v.
`
`ROY-G-BIV CORPORATION
`
`Patent Owner
`
`_____________________________
`
`Trial No.: IPR2013-00062
`
`U.S. Patent No. 6,516,236
`
`MOTION CONTROL SYSTEMS
`
`_____________________________
`
`
`
`DECLARATION UNDER 37 CFR § 42.53
`BY DAVID B. STEWART, Ph.D.
`
`
`
`Registration No.: 40514
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________
`
`ABB, INC.
`
`Petitioner
`
`v.
`
`ROY-G-BIV CORPORATION
`
`Patent Owner
`
`_____________________________
`
`Trial No.: IPR2013-00062
`
`U.S. Patent No. 6,516,236
`
`MOTION CONTROL SYSTEMS
`
`_____________________________
`
`
`
`DECLARATION UNDER 37 CFR § 42.53
`BY DAVID B. STEWART, Ph.D.
`
`
`
`TABLE OF CONTENTS
`
`I. PERSONAL BACKGROUND
`
`II. THE ASSERTED REFERENCES GENERALLY
`
`A. Stewart
`
`B. Gertz
`
`C. Morrow
`
`1
`
`4
`
`4
`
`10
`
`13
`
`D. The Petitions Seriously Misstate the Teachings of the Stewart and Gertz
`References
`15
`
`III. SEVERAL CLAIM LIMITATIONS ARE MISSING FROM THE
`REFERENCES
`
`A. Primitive Operations
`
`B. Core Driver Functions
`
`C. Driver Functions/Component Functions
`
`D. Component Code
`
`IV. NO REASONABLE JUSTIFICATION EXISTS FOR COMBINING
`THE GERTZ & MORROW REFERENCES
`
`
`16
`
`18
`
`19
`
`20
`
`22
`
`23
`
`
`
`
`
`I.
`
`Personal Background
`1. My name is David Bernard Stewart. I have personal knowledge of the
`
`facts contained in this Declaration, am of legal age, and am otherwise competent to
`
`testify.
`
`2.
`
`I am the author of the Stewart reference relied upon in the Petitions
`
`for Inter Partes Reviews of U.S. Patent Nos. 6,516,236B1, the ’236 Patent
`
`(IPR2013-00062) and 8,073,557, the ’557 Patent (IPR2013-00074) (hereafter the
`
`“Patents” and the “Petitions”). I have also co-authored publications with
`
`Dr. Matthew Wayne Gertz, the author of the Gertz reference relied upon in the
`
`Petitions.
`
`3.
`
`All of the opinions I express in this Declaration have been made from
`
`the standpoint of a person of ordinary skill in the motion control field, who I have
`
`assumed would have a bachelor’s degree (or equivalent) in electrical, mechanical,
`
`or computer science/engineering and at least one or two years’ experience
`
`developing software for motion control systems.
`
`4.
`
`I have over 25 years of diverse professional experience. I am
`
`currently the lead software architect for the next generation of defibrillator and
`
`vital sign monitoring devices being developed by Physio-Control that are used in
`
`ambulances and hospitals. My main areas of expertise are within the general area
`
`
`-- 1 --
`
`
`
`
`
`of embedded systems (i.e., computer systems with a dedicated function within a
`
`larger mechanical or electrical system), and more specifically within the areas of
`
`embedded system hardware and software architecture, real-time operating systems
`
`and executives, low-level kernel and device driver programming, hardware-
`
`software co-design, component-based software engineering, real-time design,
`
`performance analysis, power optimization, debugging techniques, and hardware
`
`and software verification and validation. I have significant experience in numerous
`
`market segments,
`
`including mobile computing, wireless sensor networks,
`
`aerospace,
`
`industrial control, consumer electronics,
`
`transportation, medical
`
`devices, robotics, and environmental monitoring. I am an expert in the low-level
`
`operating system and device driver aspects of motion control systems, and a person
`
`of ordinary skill in the application levels of such systems.
`
`5.
`
`I earned my Ph.D. in computer engineering from Carnegie Mellon
`
`University in 1994. My Ph.D. dissertation is in fact the “Stewart” reference at
`
`issue in this proceeding. From 1994 through 2000, I was a computer engineering
`
`faculty member at University of Maryland. Between 2000 and 2006, I was Chief
`
`Technology Officer at an embedded systems startup firm. Then from 2006 through
`
`2012, I was Director of Software Engineering at an embedded systems electronics
`
`firm. During the span from 1994 through present, I have often worked as a
`
`
`-- 2 --
`
`
`
`
`
`consultant for numerous companies, and have been regularly invited to present
`
`lectures at the Embedded Systems Conferences held two to three times per year in
`
`the US. My CV is attached.
`
`6.
`
`I have been retained as an expert by Roy-G-Biv Corporation (“Patent
`
`Owner”) in connection with Inter Partes Reviews IPR2013-00062 and IPR2013-
`
`00074 of the Patents (hereafter IPR’s). In connection with my analysis, I have
`
`reviewed the following: (1) the Patents, including their claims; (2) the Petitions; (3)
`
`the Board’s Decisions relating to the Petitions; (4) the following references relied
`
`on in the Petitions: (a) M.W. Gertz, A Visual Programming Environment for Real-
`
`Time Control Systems (“The Gertz Reference” or “Gertz”); (b) D.B. Stewart, Real-
`
`Time Software Design and Analysis of Reconfigurable Multi-Sensor Based
`
`Systems (“The Stewart Reference” or “Stewart”); and (c) J. Dan Morrow, Vision
`
`and Force Driven Sensorimotor Primitives for Robotic Assembly Skills (“The
`
`Morrow Reference” or “Morrow”) (collectively, “the References”); and (5) the
`
`Second Amended Joint Claim Construction and Prehearing Statement and its
`
`Exhibits (previously submitted in these IPR’s as Exhibit 2009 in IPR2013-00062
`
`and as Exhibit 2012 in IPR2013-00074, hereafter “JCCS”). I have read the claim
`
`constructions presented in the JCCS.
`
`
`
`-- 3 --
`
`
`
`
`
`7.
`
`I am thoroughly familiar with the Stewart Reference because it is the
`
`Ph.D. thesis I authored. I am also very familiar with the Gertz Reference because I
`
`know its author personally, worked together with him while we overlapped at
`
`Carnegie Mellon University, read his dissertation (i.e., the Gertz Reference) years
`
`ago and re-read it again recently, and have co-authored at least a half-dozen other
`
`publications
`
`with
`
`him
`
`in
`
`the
`
`past
`
`(see
`
`http://www.cs.cmu.edu/afs/cs/user/mwgertz/www/publish.html), including on the
`
`topics specifically covered by the Gertz and Stewart References. See Gertz, p. 24.
`
`A discussion of the relevant sections of these references based upon my analysis
`
`appears below.
`
`II. The Asserted References Generally
`8.
`Based upon my review of the Petitions, it relies upon the Gertz
`
`Reference, the Stewart Reference, and the Morrow Reference. Although the
`
`primary reference is the Gertz Reference, I will describe the Stewart Reference
`
`first because Gertz’s work built on my work and thus logically it makes sense to
`
`describe mine first.
`
`A.
`9.
`
`Stewart
`
`In the early 1990s, robotics research had solved the problems of robot
`
`movement, but there was tremendous difficulty in creating more sophisticated
`
`
`
`-- 4 --
`
`
`
`
`
`systems that included many sensors to provide feedback on the surrounding
`
`environment, and multiple robots that would coordinate with each other. At this
`
`time, commercial real-time operating systems (RTOS) such as VxWorks and QNX
`
`began to emerge. Prior to my Ph.D. work, I had done research in RTOS, and had
`
`created Chimera as part of my Master’s Thesis work [Reference 67 in Stewart
`
`points to journal article describing this thesis work]. The Stewart Reference
`
`represents the Ph.D. work, which was an extension to my Chimera RTOS designed
`
`to improve the programmability of robotic systems that had many sensors and
`
`multiple robots that needed to be integrated. The union of this new framework
`
`layer and the prior underlying RTOS work was called “Chimera 3.” The focus of
`
`my work was primarily defining an architecture for decomposing a sensor-based
`
`system into multiple modules, and providing the “glue” to integrate those modules
`
`in a flexible manner within a real-time system. The Stewart Reference used the
`
`term “dynamically reconfigurable” to represent that the actual collection of
`
`software components executing at any one time could change dynamically, and in
`
`real-time, without having to rebuild or reload the software onto the target system.
`
`The Stewart Reference focused completely on operating system functionality, and
`
`was intentionally designed to be independent of any robotic application. Any
`
`robotic, motion control, or sensor applications described in the Stewart Reference
`
`
`-- 5 --
`
`
`
`
`
`are examples, and not my direct contributions. As with commercial RTOS,
`
`Chimera and its extensions described in the Stewart Reference can be used with
`
`any real-time system, and are not limited to robotics or multi-sensor systems.
`
`10. The Stewart Reference discloses the port-based object, which is an
`
`architectural concept that was achieved by a practical aspect of software design,
`
`which is the use of objects, with a formal method that had previously been used in
`
`concurrent system design called the port automata theory. The issue that was
`
`addressed with this combination is that in the growing field of object-based and
`
`object-oriented design, each larger object was dependent on underlying objects, in
`
`order to build a large system out of smaller pieces. While this was a successful
`
`strategy for many software systems, it was a problem for the target robotic and
`
`multi-sensor systems, because it was too static (changing objects required
`
`rebuilding the code) and it did not address the real-time requirements of the target
`
`systems. The port automata theory, on the other hand, included formal proofs of
`
`being able to build concurrent systems out of independently executing processes,
`
`with any exchange of information being limited to “ports.” While this was a
`
`proven theory, it had not yet been applied in practice, at least not in the realm of
`
`robotics and sensor control applications. The combination of these two led to the
`
`port-based object model.
`
`
`
`-- 6 --
`
`
`
`
`
`11. The port-based object is not simply a collection of data and functions,
`
`as is typically associated with an “object” in computer programming. Rather, it
`
`defined an entire framework that constrained how any individual software
`
`component can be built. Although this may seem restrictive at first glance, the
`
`reason is that such constraints were deemed necessary in order to have the ability
`
`to dynamically integrate and reconfigure components, and to maintain the real-time
`
`requirements of the system. The Stewart Reference at Figure 3.10 best summarizes
`
`the internal construction of a port-based object. The main components were the
`
`ports and the functions. The ports were for exchanging data with other objects,
`
`using an interprocess communication (IPC) mechanism. The functions represented
`
`the encapsulation of code that needed to be executed at specific times, and had
`
`very specific names, namely, init, reinit, kill, on, off, cycle, sync, clear, and error.
`
`The names of those functions are listed here to explicitly highlight that they are
`
`both application independent and device independent functions. It is for that reason
`
`that the port-based object is a general enough concept to use in any real-time
`
`system, even though the Stewart Reference developed this motivated primarily by
`
`the robotic and multi-sensor application needs.
`
`12. Stewart discloses control modules and control tasks. A control module
`
`is the source code (or compiled binary code) of the functions needed by the port-
`
`
`-- 7 --
`
`
`
`
`
`based object, and specification of its input and output ports. A control task is a
`
`Chimera thread that is coupled to the control module; it executes the framework
`
`shown in Stewart Figure 3.10, and calls the functions of the control modules at the
`
`appropriate times. Thus the term “control task” is used by Stewart to represent “a
`
`control module executing on the target platform.”
`
`13. Stewart discloses software assembly as a means to create a complete
`
`system from the control module building blocks, without the need to create any
`
`additional “glue” code. The systems engineer (i.e. NOT a software engineer)
`
`selects the subset of control modules needed from a control module library, then
`
`specifies the data flow by binding output ports to input ports, and defines other
`
`parameters such as task frequency, so that control tasks can be made of each one.
`
`Stewart discloses a “subsystem” as a collection of control modules that are
`
`complete, in the sense that when the input and output ports are bound together,
`
`there is no input port that does not have a suitable output produced by one of the
`
`other modules. Stewart discloses a “subsystem definition file” which is a textual
`
`representation of the software assembly diagrams that would have been created by
`
`the systems engineer.
`
`14. Stewart discloses a mechanism called Global State Variable
`
`Communication (abbreviated SVAR) as the means for control tasks to exchange
`
`
`-- 8 --
`
`
`
`
`
`data in a real-time environment, via their input and output ports. The mechanism
`
`allows for the data paths to change dynamically in real-time, something that is not
`
`possible if using a more traditional approach of passing data through arguments to
`
`functions. SVARs are based on shared memory, but include additional structure to
`
`be used in a multiprocessor environment and to ensure the integrity of shared data
`
`if multiple control tasks could be reading or writing the data simultaneously.
`
`15. Stewart discloses real-time scheduling algorithms as a means to
`
`execute control tasks on the target system. Which code executes when depends on
`
`the scheduling algorithm, and could include either a previously known real-time
`
`scheduling algorithm, such as the rate monotonic algorithm, or a more
`
`sophisticated algorithm as developed by Stewart such as the maximum urgency
`
`first algorithm. The flow of execution is managed by this scheduler, and not by the
`
`application code as would typically occur in more traditional control-flow
`
`architecture systems. Stewart also discloses timing failure detection and handling,
`
`as a means for detecting timing errors that could occur within an executing system
`
`if there are insufficient processor resources to execute all of the selected control
`
`tasks.
`
`16. To summarize, Stewart discloses a programming environment that has
`
`the port-based object model at its core and that targets the implementation of
`
`
`-- 9 --
`
`
`
`
`
`dynamic and real-time multi-sensor and multi-actuator systems in a multiprocessor
`
`environment. The model enforces a data flow architecture to enable the creation of
`
`a subsystem and to change subsystems dynamically and in real-time by selecting
`
`and integrating components without having to change or rebuild the software. The
`
`work described in the Stewart Reference is independent of the application, and
`
`even though it has primarily been applied to robotics control systems, there is
`
`nothing defined within the architecture that is robotics specific.
`
`B. Gertz
`17.
`In the early 1990s, the computing world was transitioning from
`
`command line programming (e.g., MS-DOS command line prompt) to visual
`
`programming (e.g., MS Windows). For example, rather than running Microsoft
`
`Word from the command line in the 1980s—something which can still be done
`
`today using a “run” command at the MS-DOS prompt command line—one now
`
`conventionally double-clicks on the Microsoft Word icon located in Windows.
`
`The Gertz Reference was an attempt to bring that same type of visual programming
`
`to the port-based object system I had developed, which prior to the Gertz
`
`Reference had operated at a command line much like the MS-DOS command line
`
`prompt.
`
`
`
`-- 10 --
`
`
`
`
`
`18. The Gertz Reference describes a “visual programming environment”
`
`called Onika. Onika enabled users, particularly those users who lacked the
`
`programming skills necessary to use my Chimera system, to program the control
`
`modules described in the Stewart Reference. As a reminder, those control modules
`
`were programmed using a conventional programming language, specifically the C
`
`programming language. As described further below, the Onika system made
`
`available to users a library of such control modules. The Onika user did not, and in
`
`fact could not, create new control modules. Instead, the Onika user was limited to
`
`the control modules present in the library. In the Gertz Reference, each control
`
`module was associated with a file containing various parameters, and this
`
`combination was referred to as a “control task.” The Gertz Reference describes
`
`exemplary control tasks as “read trackball data” or “perform forward kinematics.”
`
`A control task was the most basic building block available to the user of Onika.
`
`19. The Gertz Reference discloses graphical representations of control
`
`tasks based on Chimera’s port-based objects, rules that can be used within the
`
`graphical environment to determine when such control tasks can be combined
`
`(based on their inputs and outputs), definitions of icons to encapsulate a grouping
`
`of tasks, and a theoretical analysis of the icon’s grammatical syntax using formal
`
`theoretical software verification techniques.
`
`
`-- 11 --
`
`
`
`
`
`20. Using two different visual programming levels, Onika enabled users
`
`to combine different control tasks to provide increasingly complex functionality.
`
`First, using the lower programming level, control tasks could be combined with
`
`one another
`
`to yield “Configurations.”
`
` Configurations were really
`
`just
`
`combinations of control tasks. Once a Configuration was associated with a
`
`graphical icon, it was referred to as a “Job.” The Gertz Reference refers to the icon
`
`associated with a Job as an ONIKON.
`
`21. Second, using the upper programming interface in Onika, users could
`
`graphically combine ONIKONs to create “Actions”, “Flows” and “Applications.”
`
`An action is used to define the desired endpoint of a particular job. Multiple
`
`actions are combined to produce a control subsystem, which can be either a single
`
`“flow” or could consist of a multiplicity of flows that would execute in parallel.
`
`However, none of this execution would occur in Onika. Instead, after allowing
`
`users to create more complex Configurations, Jobs, Actions, Flows and
`
`Applications from less complex control modules, the final product of Onika was
`
`simply an Application-level configuration
`
`file.
`
` This Application-level
`
`configuration file was then required to be downloaded from the Onika
`
`development computer to a computer system running the Chimera real-time
`
`operating system.
`
`
`
`-- 12 --
`
`
`
`
`
`22. To summarize, Onika was a visual programming environment
`
`executing on the developer’s computer that enabled users to create a complex
`
`configuration file from a library of pre-existing control modules on the target
`
`motion control computer. When that complex configuration file was used on the
`
`target motion control computer, the only code executing on that computer was the
`
`code in the pre-existing control modules.
`
`C. Morrow
`23.
`In the early 1990s, robotics research had solved the problems of robot
`
`movement, while integration of sensors was largely task specific and not very
`
`flexible. At the time, there were few languages or programming environments
`
`targeted towards sensor-based robotics control, and those that existed had the
`
`constraints of needing every sensor operation and action to be hard-coded. Morrow
`
`created a command layer to improve the flexibility of integrating sensing and
`
`action within a particular application domain, allowing for better reuse of the code
`
`used for sensing or actions. Morrow leverages the Stewart work which provided
`
`the underlying RTOS and port-based object framework in an application-
`
`independent manner. Morrow added application-specific capability for the robotics
`
`domain.
`
`
`
`-- 13 --
`
`
`
`
`
`24. Morrow discloses trajectory primitives as a means to more generically
`
`encapsulate pre-programmed trajectories into a reusable building block. More
`
`complex
`
`trajectories can be built by combining previously encapsulated
`
`trajectories. Morrow discloses sensorimotor primitives as encapsulations of
`
`combining input from a sensor and output to an actuator, to define sensing and
`
`action building blocks. The sensing inputs considered by Morrow are a simpler
`
`force sensor and a more complex vision recognition system. The actions included
`
`movement of robots as well as activation of attached items such as grippers or
`
`fingers. The main goal of the sensorimotor primitives are to combine sensing and
`
`action, to produce a more complex building block such as “insert peg in hole”
`
`which requires simultaneous sensing of position (via vision) and force (feel) while
`
`managing robot movement and gripper actuation.
`
`25. Morrow discloses an embodiment of the command layer that uses a
`
`finite state machine approach to define the strategy for integrating sensing and
`
`action. Each lower-level operation by Morrow is implemented as a control task
`
`using Stewart’s Chimera system. Integration follows the software assembly
`
`method as defined by Stewart, but adds in the finite state machine strategies of the
`
`sensorimotor command layer to manage the dynamic reconfigurations to produce
`
`the more complex functions.
`
`
`
`-- 14 --
`
`
`
`
`
`D. The Petitions Seriously Misstate the Teachings of the Stewart and
`Gertz References
`
`26.
`
`I understand that, from a patentability perspective, a proper analysis
`
`compares the claims of the Patents to the teachings of the alleged prior art
`
`reference. The Petitions misstate many aspects of the Gertz and Stewart references
`
`that are not, strictly speaking, directly related to a limitation in the claims of the
`
`Patents. Several of the misstatements are discussed below. For example, “actions”
`
`are not “functions.” However, there are several additional misstatements regarding
`
`Gertz beyond those relating to the elements on which the Petition relied. For
`
`example,
`
`the following
`
`two misstatements, although not exhaustive, are
`
`noteworthy. To be clear, the fact that I do not comment on some characterization
`
`in the Petitions should not be interpreted as reflecting my agreement with it.
`
`27. According to the Petitions, Onika can “execute the application.”
`
`Petitions at 24 and 26. This is incorrect. Onika is not an execution environment
`
`but rather only a “visual programming environment.” Onika provided a graphical
`
`means for generating a configuration file that would need to be exported
`
`(downloaded) to a system running the Chimera real time operating system.
`
`28. According to the Petitions, “[w]hile Gertz discloses networking
`
`capabilities, the Onika/Chimera system can also be run on a single personal
`
`
`
`-- 15 --
`
`
`
`
`
`computer system.” Petitions at 18. This is false. Onika did not and could not run
`
`on the Chimera real time operating system. Instead, Onika ran in an X-Windows
`
`environment on a UNIX operating system. This is the reason that configuration
`
`data (e.g., applications, actions, and configurations) created in Onika as a “visual
`
`programming environment” were required to be downloaded to an “execution
`
`environment” running the Chimera real time operating system. Thus, the Petitions
`
`are completely incorrect when they state that Chimera was “the operation system
`
`used by Onika.” Petitions at 10.
`
`III. Several Claim Limitations Are Missing from the References
`29. The References, whether considered individually or together, do not
`
`disclose or teach the inventions defined in claims 1-4 and 8-10 of the ‘236 Patent
`
`or claims 16-25, 27 and 28 of the ‘557 Patent. Although various claim limitations
`
`in the Patents are not disclosed or taught by the References, I will focus on four in
`
`particular that are all located in all the independent claims at issue in these IPR’s
`
`(e.g., claim 1): (1) component function; (2) core driver function; (3) extended
`
`driver function; and (4) component code. I will also explain why I do not believe
`
`the Gertz Reference discloses primitive operations, which are also required by all
`
`the independent claims at issue in these IPR’s. I reference only the ‘236 Patent
`
`below, but similar cites may be found in the ‘557 Patent.
`
`
`-- 16 --
`
`
`
`
`
`30. The Patents teach that motion control operations are categorized as
`
`primitive operations and non-primitive operations: “Motion control operations may
`
`either be primitive operations or non-primitive operations. Primitive operations are
`
`operations that are necessary for motion control and cannot be simulated using a
`
`combination of other motion control operations. . . . Non-primitive operations are
`
`motion control operations that do not meet the definition of a primitive
`
`operations.” ’236 Patent at 7:27-36.
`
`31. These operations are implemented in the claimed motion control
`
`system using software “functions”—namely, “component functions” and “driver
`
`functions.” I understand that Patent Owner and Petitioner agree that a “component
`
`function” is a “hardware independent function that corresponds to a motion control
`
`operation”. In the specifications of the Patents, an “application program” calls a
`
`component function that is exposed (i.e., made available) by a layer referred to in
`
`the Patents as the “motion control component.” The motion control component
`
`contains “component code” that associates component functions with “driver
`
`functions” located in software “drivers.”
`
`32. The Patents teach that driver functions are categorized as core driver
`
`functions and extended driver functions: “Driver functions may be either core
`
`driver functions or extended driver functions. Core driver functions are associated
`
`
`-- 17 --
`
`
`
`
`
`with primitive operations, while extended driver functions are associated with non-
`
`primitive operations.” ’236 Patent at 7:42:45. The driver functions in turn have
`
`“driver code” associated with them that generate “control commands” to
`
`implement desired motion control operations.
`
`A.
`Primitive Operations
`33. The Petitions assert that “a motion control operation performed by one
`
`of Gertz’s control tasks is a ‘primitive operation’ because it is the lowest level
`
`motion operation Onika recognizes.” Petitions at 20 (emphasis added). The
`
`Petitions are correct that a “control task” is the lowest level operation Onika
`
`recognizes. However, this does not mean that a “control task” is a primitive
`
`operation as claimed in the Patents.
`
`34. According to the definition provided in the Patents, “[p]rimitive
`
`operations are operations that are necessary for motion control and cannot be
`
`simulated using a combination of other motion control operations.” ’236 Patent at
`
`7:28-31.
`
`35. The operation performed by a control task in the Gertz Reference is
`
`not a “primitive operation,” as argued by the Petitions. The Gertz Reference does
`
`not disclose that any control task is necessary for motion control or cannot be
`
`simulated using a combination of other motion control operations. They are simple
`
`
`-- 18 --
`
`
`
`
`
`software building blocks that are used to piece together functionality. As the Gertz
`
`Reference explains, “The control tasks, which execute in parallel, are combined
`
`(using their icons) to form configurations, which perform some real-time control
`
`function (such as ‘move to x’).” Gertz §3.3, at 22. The organization of “control
`
`tasks” and higher-level constructs in the Gertz Reference has no relationship to the
`
`level of complexity of any motion control operations that may be performed by
`
`those constructs.
`
`36. Pages 10-12 of the Petitions use the term “low level” out of context.
`
`The term “low-level” in the Gertz Reference is relative, and a way to state that
`
`Onika has two levels and that in certain places it is referring to the lower one. But,
`
`both what the Gertz Reference calls high and low level still only refer to user-
`
`interface levels within the Onika programming environment. The “low-level” has
`
`each visual block associated with control task. The “high-level” is a grouping of
`
`“low-level” blocks to provide a visual that represents that grouping.
`
`B. Core Driver Functions
`37. The Petitions assert that “control tasks” are “core driver functions.”
`
`As described above, the “control tasks” are Chimera threads that are coupled to
`
`control modules. The port-based object is a framework that constrains how an
`
`individual software component (i.e., the control module) can be built. The control
`
`
`-- 19 --
`
`
`
`
`
`tasks consist of a combination of a finite state machine, port communication
`
`operations, synchronization events, and calls to the functions of the control module
`
`at very specific times. The calls to the control module functions are both hardware
`
`independent and application independent. They are self-contained within an
`
`independent thread. Thus, control tasks are not “functions” as used in the Patents,
`
`and the functions contained within a control task are not “associated with one of
`
`the primitive operations” and cannot be “core driver functions” as required by the
`
`claims.
`
`38.
`
`In any event, however, control tasks are also not core driver functions
`
`as required by the claims because they do not correspond to primitive operations.
`
`For the reasons already given, Gertz does not disclose that any control task or any
`
`operation performed by a control task is necessary for motion control or cannot be
`
`simulated using a combination of other motion control operations.
`
`C. Driver Functions/Component Functions
`39. The Petitions assert that (1) Gertz’s Actions are “component
`
`functions” and (2) Gertz’s Configurations and Control Tasks are driver functions.
`
`I disagree.
`
`40. As
`
`I discussed above, Gertz’s Actions are
`
`represented by
`
`configuration files that abstract a grouping of control tasks within the Chimera
`
`
`-- 20 --
`
`
`
`
`
`system. Refer to Gertz Appendix A for examples of these configuration files. To a
`
`person of ordinary skill in the art, these configuration files are clearly not
`
`“functions” in the sense of that term in software engineering or in the Patents, and
`
`they do not contain executable code. Rather, actions are used by Onika to
`
`configure the grouping of control tasks that were pre-existing within the Chimera
`
`system on the target platform. Because Gertz’s actions consist only of
`
`configuration information, they cannot be viewed as a “hardware independent
`
`function that corresponds to a motion control operation.”
`
`41. Neither Configurations nor Control Tasks are “driver functions.” I
`
`understand that RGB contends that “driver functions” are “hardware independent
`
`abstract functions that are separate and distinct from the component functions.”
`
`JCCS Ex. B at 3. As I explained above, Configurations are merely configuration
`
`information and are not executable. They cannot be “functions.”
`
`42. As I also explained above, control tasks are not simply “functions”,
`
`and the functions contained within a control task are not “associated with one of
`
`the primitive operations” and cannot be “core driver functions” as required by the
`
`claims.
`
`
`
`-- 21 --
`
`
`
`
`
`D. Component Code
`43. Even if one incorrectly concluded that “actions” were “component
`
`functions” and “configurations”/“tasks” were driver functions, there is no code in
`
`Onika that “relates” those to each other. I understand that RGB contends that
`
`“component code” in the claims means “software code in the motion control
`
`component that associates at least some of the component functions with at least
`
`some of the driver functions.” JCCS Ex. B at 3. I also understand that ABB, Inc.
`
`agreed to that construction in the district court litigation.
`
`44. According to the Petitions, “Gertz discloses that Onika (and its two
`
`level interface in particular) is a software system which contains the code that
`
`relates the component functions (‘actions’) to driver functions (‘configurations’
`
`and/or ‘tasks’).” Petitions at 25. I disagree. As explained above, the “actions” in
`
`the Gertz Reference are not “component functions” and the “configurations” and
`
`“tasks” are not driver functions. However, even if they were, there is no “code” in
`
`Onika relating “actions” to “configurations” and “control tasks.” As I explained
`
`above, Onika only produces configuration information. The configuration
`
`information cannot be characterized as “software code.” Therefore, the Gertz
`
`Reference does not disclose component code as required by the claims.
`
`
`
`-- 22 --
`
`
`
`
`
`IV. No Reasonable Justification Exists for Combining the Gertz & Morrow
`References
`45. Gertz and Morrow both worked with my Chimera system. However,
`
`neither of them would have worked with each other. Not only would it not have
`
`been obvious, it would not even make sense.
`
`46. As I explained above, the
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
