Axure Software Solutions Inc v. iRISE

1. Case Identification

• Case #: CBM2015-00084
• Patent #: 7,349,837
• Filed: February 20, 2015
• Petitioner(s): Axure Software Solutions, Inc.
• Patent Owner(s): iRise, Inc.
• Challenged Claims: 30-34, 37-39

2. Patent Overview

• Title: System and Method for Programming an Application Simulation
• Brief Description: The ’837 patent discloses a programming environment for creating simulations of computer applications. The system displays a programming area containing graphical "primitives" (e.g., buttons, images) alongside a "requirements area" containing text statements, allowing a user to arrange the primitives and visually associate them with their corresponding requirements.

3. Grounds for Unpatentability

Ground 1: Obviousness over Okita and Barskiy - Claims 30-31, 34, 37-39 are obvious over Okita in view of Barskiy.

• Prior Art Relied Upon: Okita (6,225,998) and Barskiy (6,205,412).
• Core Argument for this Ground:
  • Prior Art Mapping: Petitioner argued that Okita taught the core elements of independent claim 30. Okita disclosed a visual programming system with a graphical workflow editor ("programming area") containing visual primitives (icons) that a user can arrange via control indications (e.g., drag-and-drop). Crucially, Okita taught displaying additional text describing the primitive's function directly below the icon, with both displayed simultaneously in the same window, satisfying the "requirements area" limitation. Okita also disclosed storing the resulting workflow diagrams, meeting the "storing associations" limitation. Petitioner asserted that while Okita taught a visual programming environment, Barskiy explicitly taught using such an environment for the simulation of computer telephony applications, thus supplying the "simulation" aspect of the claims.
  • Motivation to Combine: A POSITA would combine these references because they operate in the same technical field of computer telephony applications. Petitioner argued that Barskiy expressly suggested the need for simulation to test and debug the very type of telephony applications that are designed using Okita's visual programming methods. A POSITA would have found it obvious to use Barskiy's simulation framework to test the applications created in Okita's development environment.
  • Expectation of Success: The combination would predictably result in a system that allows for both the visual development and subsequent simulation of an application, which was a desirable and expected outcome.

Ground 2: Obviousness over Okita, Barskiy, and Robbins - Claims 32 and 33 are obvious over Okita and Barskiy, further in view of Robbins.

• Prior Art Relied Upon: Okita (6,225,998), Barskiy (6,205,412), and Robbins (a 1999 dissertation titled "Cognitive Support Features for Software Development Tools").

• Core Argument for this Ground:

  • Prior Art Mapping: Petitioner argued that the base combination of Okita and Barskiy provided the core programming and simulation environment, as described in Ground 1. Robbins was introduced to teach the specific user interface features of dependent claims 32 and 33. For claim 32 ("highlighting one or more primitives associated with the selected statement"), Robbins disclosed a "to do list" feature where selecting a text-based list item (a statement) automatically highlights the associated graphical design element (primitive) in the main diagram. For claim 33 ("removing...statements from display that are not associated with the selected primitive"), Robbins disclosed a "Context Sensitive Checklist" that dynamically displays only those checklist items (statements) that are relevant to the currently selected design element, thereby removing non-associated statements from the display.
  • Motivation to Combine: A POSITA would combine Robbins with the Okita/Barskiy system to improve software developer performance and user experience. Robbins explicitly addressed the "cognitive needs of software designers" by introducing features like highlighting and context-sensitive help. Petitioner contended it was a known design principle to incorporate such features into development tools to make them more intuitive and efficient.
  • Expectation of Success: Adding well-understood UI enhancements from Robbins to the established programming environment of Okita/Barskiy would have been a straightforward integration with a high expectation of achieving the predictable result of a more user-friendly system.

• Additional Grounds: Petitioner asserted additional challenges for claims 30-34 and 37-39 under 35 U.S.C. § 101 for being directed to the abstract idea of associating text with a graphical design, and under 35 U.S.C. § 112 for indefiniteness of means-plus-function limitations.

4. Key Claim Construction Positions

• "simulation" (claim 30): Petitioner proposed the construction "a representation." This was argued to be the broadest reasonable interpretation, contrasting with a narrower district court construction of "an interactive representation." Petitioner's rationale was that a related patent from the same family explicitly claimed an "interactive simulation," implying that the term "simulation" by itself does not inherently require interactivity.
• "requirement" (claims 30-31): Petitioner argued the term should be construed according to its explicit definition in the specification: "a statement or portion of a statement regarding the desired or necessary behavior of a prospective or subject computer implemented software application." This construction was critical for mapping text descriptions in the prior art to this claim limitation.

5. Key Technical Contentions (Beyond Claim Construction)

• Indefiniteness of "means for associating": A central technical argument was that the "means for associating" limitation in claim 30 was indefinite under §112. Petitioner contended that while other means-plus-function terms in the claim could be performed by a general-purpose computer under the Katz exception, the function of "associating" required special programming. The petition argued that the specification failed to disclose a sufficient algorithm or step-by-step procedure for a computer to perform this association function, instead only describing how a user could perform the steps. This lack of corresponding algorithmic structure, Petitioner argued, rendered the claim indefinite.

6. Arguments Regarding Discretionary Denial

• As a CBM petition, Petitioner argued the ’837 patent was eligible for review because its claims were directed to a financial product or service and did not fall under the "technological invention" exception. Petitioner asserted that the patent's disclosed embodiments related to e-commerce and stock charting, and that the problems it purported to solve—such as poor documentation and communication gaps in project management—were business problems, not technical ones. It was argued the claims recited only generic computer components and did not offer a novel technological solution to a technical problem.

7. Relief Requested

• Petitioner requests institution of a Covered Business Method Review and cancellation of claims 30-34 and 37-39 as unpatentable.