`Tel: 571-272-7822
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Paper 23
`Entered: April 18, 2013
`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`_____________
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`ABB, INC.
`Petitioner
`
`v.
`
`ROY-G-BIV CORPORATION
`Patent Owner
`____________
`
`Case IPR2013-00062
`Patent 6,516,236 B1
`____________
`
`
`Before THOMAS L. GIANNETTI, BRYAN F. MOORE, and
`JENNIFER S. BISK, Administrative Patent Judges.
`
`BISK, Administrative Patent Judge.
`
`
`
`DECISION
`Institution of Inter Partes Review
`37 C.F.R. § 42.108
`
`
`
`
`Page 1 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`I.
`
`INTRODUCTION
`
`A. Background
`
`
`
`
`
`ABB, Inc. (“Petitioner”) filed a petition to institute an inter partes review of
`
`claims 1-10 (the “challenged claims”) of U.S. Patent 6,516,236 B1 (the “’236
`
`patent”). 35 U.S.C. § 311. For the reasons described below, we institute an inter
`
`partes review of claims 1-4 and 8-10 on only one of the proposed grounds—
`
`obviousness over the combination of Gertz, Stewart, and Morrow.
`
`ABB contends that the challenged claims are unpatentable under 35 U.S.C.
`
`§§102 and/or 103 based on the following prior art references:
`
`1. Gertz, Matthew W., A Visual Programming Environment for Real-Time
`
`Control Systems. Ph.D. dissertation, Carnegie Mellon University, Nov. 22,
`
`1994 (Ex. 1002) (“Gertz”);
`
`2. Microsoft Corporation, WOSA (Windows Open Services Architecture)
`
`Extensions for Financial Services, Revision 1.1, April 14, 1994 (Ex. 1003)
`
`(“WOSA/XFS”);
`
`3. Stewart, David B., Real-Time Software Design and Analysis of
`
`Reconfigurable Multi-Sensor Based Systems. Ph.D. dissertation, Carnegie
`
`Mellon University, April 1, 1994 (Ex. 1004) (“Stewart”);
`
`4. Morrow, J. Dan; Nelson, Bradley J.; and Khosla, Pradeep, Vision and Force
`
`Driven Sensorimotor Primitives for Robotic Assembly Skills. Institute for
`
`Software Research, paper 574, January 1, 1995 (Ex. 1005) (“Morrow”);
`
`5. Microsoft Press, MS Windows 3.1 Device Driver Adaption Guide, Chs. 1-2,
`
`4, 10-12 (1991) (Ex. 1006) (“DDAG”);
`
`6. Hall, Marty and Mayfield, James, Improving the Performance of AI
`
`Software: Payoffs and Pitfalls in Using Automatic Memoization,
`
`Proceedings of Sixth International Symposium on Artificial Intelligence,
`
`2
`
`
`Page 2 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`
`Monterrey, Mexico, September 1993 (Ex. 1007) (“Hall”);
`
`
`
`7. Michael Wright et al., U.S. Patent No. 5,453,933 (Ex. 1010) (“Wright”).
`
`The specific grounds asserted in the Petition (Pet. 17-49) are detailed below.
`
`Reference[s]
`
`Gertz
`
`WOSA/XFS
`
`Gertz, Stewart, and Morrow
`
`Gertz and DDAG
`
`Gertz, DDAG, and Hall
`
`WOSA/XFS and DDAG
`
`WOSA/XFS, DDAG, and Hall
`
`WOSA/SFX, Gertz, and Wright
`
`Basis
`
`§ 102
`
`§ 102
`
`§ 103
`
`§ 103
`
`§ 103
`
`§ 103
`
`§ 103
`
`§ 103
`
`Claims challenged
`
`1-10
`
`1-3, 7-10
`
`1-10
`
`1-10
`
`1-10
`
`1-4 and 7-10
`
`1-10
`
`1-10
`
`The ’236 patent is involved in concurrent district court litigation. On
`
`November 15, 2011, ROY-G-BIV filed an infringement complaint against ABB.
`
`ROY-G-BIV v. ABB et al., 11-cv-00622 (E.D. Tex.). That proceeding has not been
`
`stayed. Id. The ’236 patent was also involved in prior litigation dismissed with
`
`prejudice on November 20, 2009. ROY-G-BIV Corp. v. Fanuc Ltd et al, 2:07-cv-
`
`00418 (E.D. Tex.). A claim construction order was issued in that case. Id. at Dkt.
`
`No. 194 (Aug. 25, 2009) (Ex. 2002) (“Markman Order”).
`
`B. The Invention
`
`The ’236 patent relates generally to a system that facilitates the creation of
`
`hardware-independent motion control software. ’236 patent, col. 1, ll. 12-16. In
`
`particular, the patent describes a high-level motion control application
`
`programming interface (“API”) made up of functions that are correlated with
`
`driver functions associated with controlling a mechanical system that generates
`
`movement based on a control signal. See generally, id. at col. 1, ll. 5-50. The
`
`3
`
`
`Page 3 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`object of the invention is to isolate the application programmer from the
`
`
`
`complexity of hardware devices, which often have a manufacturer-specific motion
`
`control command language and functionality that is highly hardware-dependent.
`
`See generally, id. at col. 3, ll. 24-42. At the same time, the API should allow the
`
`programmer to access base motion operations of the hardware device. Id.
`
`As described in the ’236 patent, the prior art includes a number of low-level
`
`software programs for directly programming individual motion control devices or
`
`for aiding in the development of systems containing a number of motion control
`
`devices. Id. at col. 1, l.55 - col. 2, l. 35. While providing complete control over
`
`the hardware, these low-level programs are highly hardware-dependent. Id. The
`
`’236 patent also describes an existing software model, referred to as “WOSA,” that
`
`isolates application programmers from the complexities of programming to
`
`different service providers by providing an application programming interface
`
`layer that is hardware-independent. Id. at col. 2, ll. 55-65. However, “[t]he
`
`WOSA model has no relation to motion control devices.” Id. at col. 2, ll. 66-67.
`
`Finally, the ’236 patent distinguishes the disclosed invention from the existing
`
`software driver model that allows the user to select a driver associated with a
`
`specific hardware device, for example, a printer. Id. at col. 3, ll. 1-6. The
`
`difference being that the software driver model does not allow the application
`
`programmer the “ability to control the hardware in base incremental steps.” Id. at
`
`col. 3, ll. 7-17. In other words, the existing model would not allow the
`
`programmer to access base motion operations, an object of the disclosed invention.
`
`For example, the software driver model would not allow the programmer to control
`
`each stepper motor in the printer.
`
`In describing the invention, the ’236 patent discloses a programming
`
`interface consisting of “component functions” containing code that relates to driver
`
`4
`
`
`Page 4 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`functions, which in turn are associated with, or contain code for, implementing the
`
`
`
`motion steps on a given motion control device. Id. at col. 3, ll. 56-67. The
`
`component functions support both core driver functions—those functions which
`
`must be supported by all software drivers—and extended driver functions—
`
`functions which may or may not be supported by a particular software driver. Id.
`
`at col. 4, ll. 3-13. When feasible, component functions can emulate extended
`
`driver functions not supported by a particular device by using a combination of
`
`core driver functions. Id. at col. 3, ll. 25-45.
`
`Claim 1, the only independent claim, is reproduced below with emphasis
`
`added:
`
`1. 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:
`
`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 a non-primitive operation that does not
`meet the definition of a primitive operation;
`
`a core set of core driver functions, where each core driver function is
`associated with one of the primitive operations;
`
`an extended set of extended driver functions, where each extended driver
`function is associated with one of the non-primitive operations;
`
`a set of component functions;
`
`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;
`
`a set of software drivers, where
`
` each software driver is associated with one motion control device
`in the group of supported motion control devices,
`
`5
`
`
`Page 5 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`
`each software driver comprises driver code for implementing the
`motion control operations associated with at least some of the
`driver functions, and
`
`
`
`
`
`
`
`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;
`
`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
`
`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.
`
`C. Claim Construction
`
`As a step in our analysis for determining whether to institute a trial, we
`
`determine the meaning of the claims. Consistent with the statute and the
`
`legislative history of the AIA, the Board will interpret claims using the broadest
`
`reasonable construction. See Office Patent Trial Practice Guide, 77 Fed. Reg.
`
`48756, 48766 (Aug. 14, 2012); 37 CFR § 100(b). ABB submits proposed
`
`interpretations for several claim terms. Pet. 17-32.
`
`Patent Owner specifically addresses only the proposed interpretations of the
`
`terms “primitive operations” and “core driver functions.” Prelim. Resp. 14-17.
`
`Except for those two terms, Petitioner’s proposed interpretations do not appear
`
`unreasonable at this stage of the proceeding. Because these positions are not
`
`challenged by Patent Owner, we adopt them for the purposes of this decision.
`
`1. Primitive Operations
`
`Petitioner concedes that the ’236 patent defines a primitive operation as one,
`
`“the implementation of which is required to operate motion control devices and
`
`6
`
`
`Page 6 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`cannot be simulated using other motion control operations.” Pet. 18. However,
`
`
`
`Petitioner asserts that “neither the claim language nor the specification provide an
`
`adequate explanation for the term ‘primitive’” because the specification states that
`
`“motion control operations are not specifically related to any particular motion
`
`control device hardware configuration, but are instead abstract operations that all
`
`motion control device hardware configurations must perform in order to function.”
`
`Pet. 18-19 (quoting ’236 patent, col. 7, ll. 20-27). Therefore, according to
`
`Petitioner, “motion control operations exist in the abstract” and “can always be
`
`further decomposed into increasingly lower level constituent operations.” Pet. 19.
`
`Because of this alleged “vagueness,” Petitioner asserts that the claim term
`
`“primitive operation” includes “an abstract motion control operation corresponding
`
`to a driver function which is not represented as the combination of other driver
`
`functions.” Id.
`
`Patent Owner responds that Petitioner’s proposed interpretation is
`
`unreasonably broad because it does not account for the explicit definition in the
`
`specification or the claim language surrounding the term. Prelim. Resp. 14-16.
`
`According to Patent Owner, Petitioner’s definition of “primitive operation” would
`
`encompass operations unnecessary for motion control and those that could be
`
`simulated from other motion control operations in direct contradiction to the
`
`language in the specification in the claim. Id.
`
`We agree with the Patent Owner. We are not persuaded that the explicit
`
`definition of “primitive operation” recited in both the specification and recited in
`
`the only independent claim of the ’236 patent is so vague as to require
`
`supplementing. Petitioner cites as support for its position language in the ’236
`
`patent providing, as an example of a primitive operation, the “move relative”
`
`operation. Pet. 19 (citing ’236 patent, col. 7, ll.31-34 (“Examples of primitive
`
`7
`
`
`Page 7 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`operations include GET POSITION and MOVE RELATIVE, which are necessary
`
`
`
`for motion control and cannot be emulated using other motion control
`
`operations.”). According to Petitioner, however, “move relative” could be
`
`emulated using “constituent operations” such as “starting a motor and controlling
`
`the acceleration, slew speed and deceleration of the motor,” which are each “more
`
`‘primitive’ than the ‘move relative.’” Id. (citing Jacob Tal, Step by Step Design of
`
`Motion Control Systems 98-99, Galil Motion Control, Inc., 1994 (“Tal”)). We are
`
`not persuaded by this argument.
`
`The ’236 patent has an explicit definition of the term “primitive operation,”
`
`which also is repeated in the actual claim language. This definition is controlling,
`
`even in the event that it differs from the meaning it would otherwise possess.
`
`Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) (en banc) (“[O]ur
`
`cases recognize that the specification may reveal a special definition given to a
`
`claim term by the patentee that differs from the meaning it would otherwise
`
`possess. In such cases, the inventor’s lexicography governs.”). Petitioner’s
`
`reliance on extrinsic evidence to assert that the inventor-assigned definition is
`
`inadequate is unavailing. Extrinsic evidence “may be used only to assist in the
`
`proper understanding of the disputed limitation; it may not be used to vary,
`
`contradict, expand, or limit the claim language from how it is defined, even by
`
`implication, in the specification or file history.” Bell Atl. Network Servs., Inc. v.
`
`Covad Commc’ns Grp., Inc., 262 F.3d 1258, 1269 (Fed. Cir. 2001); accord,
`
`Helmsderfer v. Bobrick Washroom Equip., Inc., 527 F.3d 1379, 1382 (Fed. Cir.
`
`2008) (“A court may look to extrinsic evidence so long as the extrinsic evidence
`
`does not contradict the meaning otherwise apparent from the intrinsic record.”).
`
`We find that the ’236 patent clearly defines a primitive operation with an
`
`explicit definition—an operation necessary for motion control and cannot be
`
`8
`
`
`Page 8 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`simulated using a combination of other motion control operations. ’236 patent,
`
`
`
`col. 7, ll. 31-34. In turn, the specification explains that “motion control operations
`
`are not specifically related to any hardware configuration, but are instead abstract
`
`operations that all motion control device hardware configurations must perform in
`
`order to function.” Id. at ll. 22-26. In other words, a motion operation is not a
`
`defined instruction used by a specific piece of hardware, but is instead an abstract
`
`notion such as move relative.
`
`Thus, for purposes of this decision, we construe the claim term “primitive
`
`operation” to be an operation necessary for motion control and that cannot be
`
`simulated using a combination of other motion control operations.
`
`2. Core Driver Functions
`
`Petitioner asserts that the broadest reasonable interpretation of the claim
`
`term “core driver function” is “software that helps implement primitive
`
`operations.” Pet. 21. Patent Owner argues that with this proposed interpretation,
`
`Petitioner once again ignores the explicit definition in the claim language itself.
`
`Prelim. Resp. 16-17. Indeed, independent claim 1 recites “a core set of core driver
`
`functions, where each core driver function is associated with one of the primitive
`
`operations.” ’236 patent claim 1 (emphases added).
`
`To support its proposed interpretation, Petitioner cites to language in the
`
`specification stating: “Given the set of motion control operations as defined above,
`
`the software system designer next defines a service provider interface (SPI)
`
`comprising a number of driver functions. . . . basically, the driver functions define
`
`parameters necessary to implement motion control operations in a generic sense,
`
`but do not attach specific values or the like to these parameters.” Pet. 21 (quoting
`
`’236 patent, col. 7, ll. 40-53). However, nothing in this language requires the
`
`definition of “core driver functions” to include anything more than the definition
`
`9
`
`
`Page 9 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`laid out in the claim itself. In fact, the section of text replaced by Petitioner with
`
`
`
`ellipses in this very citation contains language virtually identical to that used in the
`
`claim: “Driver functions may be either core driver functions or extended driver
`
`functions. Core driver functions are associated with primitive operations, while
`
`extended driver functions are associated with non-primitive operations.” ’236
`
`patent, col. 7, ll. 44-46 (emphasis added). Moreover, it is not clear from
`
`Petitioner’s briefing what the language “helps implement” actually means.
`
`Petitioner does not point to any place in the specification that uses that particular
`
`phrase. See Pet. 21.
`
`Thus, for purposes of this decision, we construe the claim term “core driver
`
`function” to be software associated with one of the primitive operations.
`
`3. Motion Control Device
`
`Neither party explicitly addresses an interpretation of the claim term
`
`“motion control device.” However, Patent Owner argues that motion control
`
`devices “perform operations relating to, among other things, positioning, velocity,
`
`and acceleration.” Prelim. Resp. 30. Patent Owner provides several exemplary
`
`motion control functions implying that motion control devices do not include
`
`extensions related to opening and closing the shutter of an ATM machine. Id.
`
`(citing ’236 patent Exhibit B). We are not persuaded that the interpretation of
`
`motion control devices should be so limited. Patent Owner does not point to any
`
`language in the ’236 patent that restricts the broadest reasonable interpretation of
`
`the term to exclude the movement of an ATM shutter.
`
`The specification explicitly states that the basic components of a motion
`
`control device are “a controller and a mechanical system” where “[t]he mechanical
`
`system translates signals generated by the controller into movement of an object.”
`
`’236 patent, col. 1, ll. 18-22. This definition reasonably comports with the plain
`
`10
`
`
`Page 10 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`and ordinary meaning of a motion control device. Thus, for purposes of this
`
`
`
`decision, we construe the claim term “motion control device” to include any
`
`hardware device with a controller and a mechanical system that translates signals
`
`generated by the controller into the movement of an object.
`
`II. ANALYSIS
`
`A. Overview
`
`For the reasons described below, we institute inter partes review on claims
`
`1-4 and 8-10 only for the ground of obviousness over the combination of Gertz,
`
`Stewart, and Morrow.
`
`B. Priority Date for the ’236 Patent Claims
`
`On its face, the ’236 patent claims priority to application No. 08/454,736,
`
`filed May 30, 1995, now U.S. Patent 5,691,897 (the “’897 patent”). Petitioner
`
`asserts that the challenged claims are not eligible for the filing date of the ’897
`
`patent because they are supported only by material in section IX of the ’236 patent
`
`added on May 30, 1996 with the filing of application No. 08/656,421, now U.S.
`
`Patent 5,867,385, a continuation-in-part of the application that became the ’897
`
`patent. Pet. 9. Patent Owner does not address this argument. See generally,
`
`Prelim. Resp.
`
`The prior art asserted by Petitioner have the following dates: Gertz is dated
`
`November 22, 1994; WOSA/XFS is dated April 14, 1994; Stewart is dated April 1,
`
`1994; Morrow is dated January 1, 1995; DDAG has a copyright date of 1987-1992;
`
`Hall is dated September 1993; and Wright was filed September 8, 1993. All of
`
`these references, therefore, have dates prior to the earliest possible priority date of
`
`May 30, 1995. Thus, it is unclear, and Petitioner does not explain, why the priority
`
`date is relevant to the issue at hand—whether there is a reasonable likelihood that
`
`11
`
`
`Page 11 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`
`at least one of the challenged claims is unpatentable. We therefore need not and do
`
`not consider whether the challenged claims of the ’236 patent properly are
`
`accorded benefit of May 30, 1995.
`
`C. Gertz
`
`Gertz is a Ph.D. dissertation that presents a visual programming
`
`environment—a graphical front-end—for a real-time control system, such as robot
`
`manipulators, called Onika. Gertz 27, § 1.1. Onika presents each task of a real-
`
`time operating system using an icon to allow users who actually control the
`
`equipment, but who are not highly trained in programming real-time control
`
`systems, to be involved in the programming process. Id. at 27-29, §§ 1.1-1.2. The
`
`resulting programs are also device-independent. Id. at 30, § 1.3 Gertz
`
`distinguishes Onika from previous textual languages used for programming robots.
`
`“These languages introduced ‘built-in’ commands to operate the robot, eliminating
`
`(for instance) the need to develop code for motion primitives,” but resulted in
`
`programs that were difficult to read and were “robot-specific.” Id. at 33, § 2.2.
`
`Gertz describes the implementation of Onika starting with the lowest level of
`
`code, called a “control module.” Id. at 41-43, § 3.2.1. A “control task” consists of
`
`a control module and a file containing various task parameters—task-specific
`
`information. Id. Control tasks are assigned an icon and perform an operation such
`
`as “read data from trackball” or “perform forward kinematics.” Id. at 48, § 3.3.
`
`Control tasks are combined to form “configurations,” which can be assigned a
`
`picture and “can perform any real-time or not-real-time function, including motion
`
`control” (such as “move to x” where move to is a job and x is a target). Id. at 41-
`
`49 §§ 3.2-3.3. Jobs and targets can then be combined into “actions.” Id. at 49, §
`
`3.3. Actions are assembled sequentially to form “control subsystems,” which in
`
`turn can be operated in parallel forming an “application.” Id.
`
`12
`
`
`Page 12 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`1. Gertz is Cumulative
`
`
`
`
`
`Patent Owner argues that Gertz is the same or substantially the same as the
`
`references considered during the original prosecution, and the Inter Partes
`
`Reexamination of the ’236 patent. Prelim. Resp. 26-28. Patent Owner bases this
`
`assertion on the fact that a reference teaching Chimera, the real-time operating
`
`system which Onika uses (see, e.g., Gertz 67, § 4.4.4) previously was considered
`
`during the reexamination. Prelim. Resp. 27 (citing ’236 Inter Partes
`
`Reexamination Certificate, page 5, col. 1) (“Stewart: Schmitz, Khosla;
`
`‘Implementing Real-Time Robotic Systems using Chimera II”). Patent Owner
`
`does not point to any other evidence that Stewart was considered during the
`
`reexamination or why the challenged claims were allowed despite Stewart’s
`
`disclosure.
`
`“In determining whether to institute or order a proceeding . . . the Director
`
`may take into account whether, and reject the petition or request because, the same
`
`or substantially the same prior art or arguments previously were presented to the
`
`Office.” 35 U.S.C. § 325(d) (emphasis added). While we are cognizant of the
`
`burden on the patent owner and Office to rehear the same or substantially the same
`
`prior art or arguments that were considered by the Office in a prior proceeding, we
`
`decline to reject the petition solely on the ground that Stewart, a reference related
`
`to the operating system upon which Gertz’s system is based, is a member of an
`
`eight-page list of references on the ’236 patent reexamination certificate.
`
`2. Anticipation
`
`Petitioner asserts that Gertz discloses each and every element of all the
`
`challenged claims. Pet. 2, 17-32. Patent Owner responds that Gertz does not
`
`disclose “primitive operations” or “core driver functions” as required by all the
`
`claims. Prelim. Resp. 21-26.
`
`13
`
`
`Page 13 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`
`Petitioner contends that a motion control operation performed by one of
`
`
`
`Gertz’s control tasks is a primitive operation, as interpreted by Petitioner, because
`
`“it is the lowest level motion operation Onika recognizes.” Pet. 20. In a claim
`
`chart, Petitioner further explains that “[t]he desired motion sequence can comprise
`
`primitive operations (those associated with ‘lower level routines’).” Pet. 50 (citing
`
`Gertz, § 5.11). Patent Owner argues that control tasks of Onika are not primitives
`
`as required by the claims because they do not implement an operation that is
`
`required to operate the motion control device and that cannot be simulated using
`
`other motion control operations. Prelim. Resp. 21-22. To support this assertion,
`
`Patent Owner points to Gertz’s disclosure that control tasks implement operations
`
`such as “read data from trackball” or “perform forward kinematics.” Id. at 22.
`
`According to Patent Owner, these operations are more complex than the recited
`
`primitive operations. Id.
`
`While “perform forward kinematics” appears to be an operation related to
`
`motion control, we agree with Patent Owner that Petitioner has not pointed to
`
`persuasive evidence that this operation (or any other operation performed by a
`
`control task) is required for motion control and cannot be simulated from other
`
`motion control operations as required by all the challenged claims. Petitioner does
`
`not point to any explicit language in Gertz that discloses these requirements. See
`
`Pet. 17-22. Nor does Petitioner assert that these requirements are inherent in
`
`Gertz. Id. As explained above, we are not persuaded that these requirements can
`
`be read out of the claim.
`
`Petitioner further asserts that the control tasks of Gertz are core driver
`
`functions “because they help implement primitive operations.” Pet. 21, see also
`
`Pet. 51. Because we are not persuaded that Petitioner sufficiently has shown that
`
`the operations performed by control tasks are primitive operations, we are also not
`
`14
`
`
`Page 14 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`persuaded that Petitioner has shown that control tasks are “associated with one of
`
`
`
`the primitive operations.”
`
`Thus, we are not persuaded that there is a reasonable likelihood that
`
`Petitioner would prevail on a challenged of anticipation over Gertz and we decline
`
`to institute inter partes review based on this ground.
`
`3. Obviousness over Gertz, Stewart, and Morrow
`
`Petitioner asserts that all the challenged claims would have been obvious
`
`over the combination of Gertz, Stewart, and Morrow. Pet. 42-44. Stewart is a
`
`Ph.D. dissertation describing the “design and analysis of reconfigurable real-time
`
`software . . . based on modelling software modules as dynamically reconfigurable
`
`port-based objects.” Stewart 11. Morrow is a paper describing a “sensorimotor
`
`command layer” for integrating sensors into robot systems. Morrow Abstract. It
`
`discloses “trajectory primitives” that “encapsulate[] . . . robot trajectory
`
`specifications” including “movedx.” Id. at § 2.
`
`Petitioner relies on Stewart as describing the provision of device drivers for
`
`use with a motion control system and Morrow for the use of motion primitives and
`
`their combination to create complex trajectories. Pet. 42. We agree with Petitioner
`
`that Morrow’s description of the implementation of three trajectory primitives:
`
`movedx that “applies a Cartesian velocity over time to achieve the specified
`
`Cartesian differential motion”, ldither that “implements a linear sinusoidal velocity
`
`signal at the specified frequency for the specified number of cycles”, and rdither
`
`that “implements a rotary sinusoidal velocity signal at the specified frequency for
`
`the specified number of cycles” implies that these operations are required to
`
`operate the relevant motion control device and they cannot be simulated using
`
`other motion control operations. Morrow § 2. Moreover, Morrow describes non-
`
`primitive operations–“[c]omplex trajectories” that “can be specified by combining
`
`15
`
`
`Page 15 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`trajectory primitives” for example “to implement an ‘exploration’ of an area.” Id.
`
`
`
`Thus, Morrow’s trajectory primitives qualify as the recited primitive operations.
`
`Patent Owner responds that neither Morrow nor Stewart discloses core
`
`driver functions because they rely on “port based objects,” which are not actually
`
`functions because they rely on shared memory for communication. Prelim. Resp.
`
`42, see also Prelim. Resp. 24-26. This argument is not persuasive. Petitioner
`
`relies on Morrow only for the disclosure of motion primitives. Petitioner relies on
`
`Gertz for the disclosure of core driver functions. As described above, we found
`
`that Petitioner had not shown that Gertz disclosed primitive operations as claimed.
`
`However, we are persuaded that there is a reasonable likelihood that the
`
`combination of Morrow’s trajectory primitives and Gertz’s disclosure of functions
`
`that are associated with motion operations would have made the claimed “primitive
`
`operations” and “core driver functions” obvious to a person of ordinary skill. We
`
`also find Petitioner’s reasoning that the remaining limitations of the challenged
`
`claims are disclosed by Gertz and Stewart reasonable. See Pet. 17-37, 49-60.
`
`Petitioner asserts that a person of ordinary skill would have combined the
`
`three references in order to reduce the cost of motion control applications. Pet. 44.
`
`In addition, the three references were written at the same research center at about
`
`the same time. Id. Patent Owner does not argue that a person of ordinary skill
`
`would not have looked to combine the three references, but argues instead that
`
`Gertz teaches away from primitive operations because it operates at a much higher
`
`level than that of primitives. Prelim. Resp. 43 (citing Gertz § 2.2). We are not
`
`persuaded by this argument. First, we are not persuaded that Gertz is at a “much
`
`higher level” than the recited primitives. Gertz describes many different levels that
`
`build upon each other—some of these levels are described as low level. While, as
`
`discussed above, we have not been directed to language in Gertz disclosing that the
`
`16
`
`
`Page 16 of 25
`
`
`
`IPR2013-00062
`Patent 6,216,236 B1
`
`
`operations performed by control tasks are necessarily primitive operations as
`
`
`
`claimed, it does not follow that Gertz is at a “much higher level.” Patent Owner
`
`points to language in Gertz that describes prior art textual languages as introducing
`
`“built-in” commands that “eliminate[] the need to develop code for motion
`
`primitives.” Prelim. Resp. 20 (quoting Gertz § 2.2). However, this language in
`
`Gertz does not support Patent Owner’s contention that Gertz is at a much higher
`
`level than motion primitives. Instead, the context of that language makes it clear
`
`that Gertz was distinguishing itself from the prior art textual languages in that
`
`programs created with Gertz’s system are not difficult to read and are not robot-
`
`specific like the prior art. See Gertz § 2.2. Nothing in that cited section of Gertz
`
`leads to a conclusion that the system described by Gertz does not have a need to
`
`develop code for motion primitives. Thus, we are not persuaded that Gertz teaches
`
`away from using primitive operations as claimed.
`
`In addition to all the limitations recited by independent claim 1, dependent
`
`claims 5 and 6 include the further limitations that “an extended function pointer
`
`table that maps the non-supported extended driver functions to the combination of
`
`core driver functions employed to emulate the non-supported extended function”
`
`and “the motion control component generates the control commands further based
`
`on the contents of the extended function pointer table.” Petitioner relies solely on
`
`the following language from Gertz as disclosing both limitations: “Furthermore, a
`
`combination of tasks on the canvas can be saved at any point for later recall.”1 Pet.
`
`57 (citing Gertz § 4.2.1); see also 42-44. It is not clear how this