PTAB
IPR2016-00059
Xilinx Inc v. QuickcoMPIle IP LLC
Key Events
Petition
Table of Contents
petition
1. Case Identification
- Case #: IPR2016-00059
- Patent #: 7,073,158
- Filed: October 20, 2015
- Petitioner(s): Xilinx, Inc.
- Patent Owner(s): QuickCompile IP, LLC and Pixel Velocity Incorporated
- Challenged Claims: 1-20
2. Patent Overview
- Title: FPGA-Based Image Processing Platform
- Brief Description: The ’158 patent describes a Field-Programmable Gate Array (FPGA)-based image processing architecture. The system is designed to automatically convert user-defined algorithms, specified in a high-level source code, into a programmed FPGA configuration to accelerate their execution.
3. Grounds for Unpatentability
Ground 1: Obviousness over Banerjee and Benkrid - Claims 1-2, 4, 9, 16, and 18-20 are obvious over Banerjee in view of Benkrid.
- Prior Art Relied Upon: Banerjee (A MATLAB Compiler For Distributed, Heterogeneous, Reconfigurable Computing Systems, 2000 IEEE Symposium) and Benkrid (High Level Programming for FPGA Based Image and Video Processing Using Hardware Skeletons, 2001 IEEE Symposium).
- Core Argument for this Ground:
- Prior Art Mapping: Petitioner argued that Banerjee taught the core elements of independent claim 1. Banerjee’s MATCH Compiler system accepts a user-defined algorithm in MATLAB source code, a high-level language designed to process data vectors. The compiler then analyzes (parses) the code to identify vector operations, maps those operations onto hardware components (pre-designed functions in RTL VHDL), and generates a configuration bitstream to program a target FPGA. This process directly maps to the claimed steps of accepting, analyzing, mapping, and programming.
- Motivation to Combine: A Person of Ordinary Skill in the Art (POSITA) would combine the teachings of Banerjee and Benkrid because both references address the same problem: compiling high-level code for image processing on Xilinx FPGAs. Benkrid discloses a framework using a "Hardware Skeleton Library" with pre-designed, optimized physical operator blocks to improve performance and provide users with implementation choices. Petitioner contended a POSITA would have been motivated to integrate Benkrid’s known library technique into Banerjee’s compiler system to predictably improve its performance and flexibility without requiring detailed hardware description skills from the user.
- Expectation of Success: A POSITA would have a reasonable expectation of success because the combination involves applying a known optimization and organization technique (Benkrid’s hardware skeleton library) to a similar system (Banerjee’s compiler) to achieve the predictable result of a more efficient and versatile compilation process.
Ground 2: Obviousness over Banerjee, Benkrid, and Haldar - Claims 3, 5, 7, and 8 are obvious over Banerjee and Benkrid in view of Haldar.
Prior Art Relied Upon: Banerjee, Benkrid, and Haldar (Scheduling Algorithms for Automated Synthesis of Pipelined Designs on FPGAs for Applications described in MATLAB, 2000 International Conference).
Core Argument for this Ground:
- Prior Art Mapping: This ground builds on the combination in Ground 1, with Haldar providing additional implementation details for the MATCH compiler (Haldar and Banerjee are co-authors describing the same system). For claim 3 (accepting C++ code), Haldar taught that C++ was a popular and well-known language for synthesizing hardware. For claim 5 (determining relative timing), Haldar taught constructing a data flow graph to determine the timing and scheduling of operations. For claims 7 and 8 (identifying operator types, operands, orders, and dependencies), Haldar explicitly disclosed performing dependency analysis on an Abstract Syntax Tree to infer control and data dependencies, thereby revealing the order of operations.
- Motivation to Combine: A POSITA would consult Haldar because it describes implementation details of the same MATCH compiler system discussed in Banerjee. Regarding claim 3, the motivation to adapt Banerjee’s compiler to also accept C++ (as taught by Haldar) was to create a more versatile, efficient, and desirable compiler. This would allow for the reuse of existing C++ algorithms and leverage C++ as a flexible and cheap alternative to MATLAB.
- Expectation of Success: A POSITA would expect success in adapting the compiler for C++ given that most prior work in the field had been done with C++. The combination represented using known techniques (C++ compilation and dataflow analysis) to improve a known system for predictable results.
Additional Grounds: Petitioner asserted further obviousness challenges for the remaining claims. Ground III added Hammes to teach dataflow graph generation for claim 6. Ground IV added Applicants Admitted Prior Art (AAPA) to teach using rule sets for FPGA constraints for claims 10-13 and 17. Ground V added Grant to teach serpentine vector flow path mapping for claims 14 and 15.
4. Key Claim Construction Positions
- “analyzing”: Petitioner proposed that the term "analyzing" in claim 1 should be construed to mean "compiling and parsing." This construction was asserted to be consistent with the ’158 patent’s disclosure, which describes using "standard compiler technology to parse the language of the source code." Petitioner argued this construction is critical because the prior art, particularly Banerjee, explicitly teaches compiling and parsing MATLAB source code as the first step in its process, directly mapping to this key claim limitation under the proposed construction.
5. Relief Requested
- Petitioner requested the institution of an inter partes review and the cancellation of claims 1-20 of the ’158 patent as unpatentable under 35 U.S.C. §103.
Analysis metadata