Searching over 5,500,000 cases.


searching
Buy This Entire Record For $7.95

Download the entire decision to receive the complete text, official citation,
docket number, dissents and concurrences, and footnotes for this case.

Learn more about what you receive with purchase of this case.

Typemock, Ltd. v. Telerik Inc.

United States District Court, D. Massachusetts

August 31, 2018

TYPEMOCK, LTD.
v.
TELERIK, INC.

          MEMORANDUM AND ORDER ON CLAIM CONSTRUCTION

          RICHARD G. STEARNS UNITED STATES DISTRICT JUDGE

         Plaintiff Typemock, Ltd., accuses defendant Telerik, Inc., of infringing United States Patents Nos. 8, 352, 923 (the '923 patent), and 9, 251, 041 (the '041 patent). Before the court are the parties' briefs on claim construction. The court received technical tutorials and heard argument, pursuant to Markman v. Westview Instruments, Inc., 517 U.S. 370 (1996), on August 30, 2018.

         THE ASSERTED PATENTS

         Both the '923 and the '041 patents are entitled “method and system for isolating software components, ” and list Eli Lopian as the sole inventor.[1] The '923 patent was issued on January 8, 2013. The '041 patent, issued on February 2, 2016, is a continuation of the '923 patent, and shares the same specification.

         The asserted patents are directed to improvements in the field of software validation.

Validating software is a complex problem that grows exponentially as the complexity of the software grows. Even a small mistake in the software can cause a large financial cost. In order to cut down on these costs, software companies test each software component as they are developed or during interim stages of development.

'923 patent, col. 1, ll. 32-37. At the time of the invention of the asserted patents, methods existed to validate software by isolating and testing individual software components.

In order to isolate the components, there is a need to design the program that utilizes the software components in such a way that the components can be changed. This is part of a pattern called Inversion of Control or Dependency Injection. For example when validating that software behaves correctly on the 29th of February, there is a need to change the computer system's date before running the test. This is not always possible (due to security means) or wanted (it may disturb other applications). The method used today to verify this is by wrapping the system call to get the current date with a new class. This class may have the ability to return a fake date when required. This may allow injecting the fake date into the code being tested for, and enable validating the code under the required conditions. There are many cases where isolating the code base and injecting fake data are required.

Id. col. 1, ll. 52-63.

         In more complex cases, validation may require “faking a complete set of API's [(application programming interface)] (for example: faking sending an email).” Id. col. 2, l. 6. To do so, there is a need to build a framework that enables isolating the complete API set. This means that the code may now have to support creating and calling two different components. One way to do this is to use the Abstract Factory Pattern. Using this pattern, the production code should never create the object (that needs to be faked for tests). Instead of creating the object, the Factory is asked to create the object, and the code calls the methods of the object that the factory created. The factory can then choose what object to create: a real one or a fake one. This requires using an interface that both clients (real and fake) need to implement. It also requires creating a complex mechanism that may allow the factory to choose what object to create and how to do so. This is done mainly through configuration files although it can be done in code too.

Id. col. 2, ll. 7-21.

         To utilize these methods for validation, code must be designed to be testable. Legacy code may not be designed to permit the insertion of fake objects, and rewriting legacy code may be too costly or time-consuming. Designing code to be testable may also add constraints to the code that are not compatible with production code. “For example, the code may be required to implement hooks that enable changing the actual object to a fake one. This hook can lead to misuse and hard-to-debug code, as it is intended for testing but it is in the production code.” Id. col. 2, ll. 46-49.

         The asserted patents disclose systems and methods of software validation that, through the use of a mock framework, do not require the design for testability.

A mock framework 110 may dynamically create a fake object that implements the same interface of the real object (the same interface that is created using the Abstract Factory), and has the ability to define the behavior of the object and to validate the arguments passed to the object.

Id. col. 2, ll. 30-35.

[C]ertain embodiments of the invention add code that is inserted or weaved 107 into the production code base 106 (FIG. 1) that is being tested. The added code may enable hooking fake or mock objects into the production code by calling the [m]ock framework 110. This framework can decide to return a fake object. The framework may also be able to validate and change the arguments passed into the method.

Id. col. 2, ll. 58-64.

         Claim 1 of the '923 patent is a representative system claim.

         1. A software testing system operative to test a software application comprising a plurality of software components, at least some of which are coupled in a utilizing-utilized relationship the system comprising:

         a processor and memory;

computational apparatus for at least partially isolating, from within the software application, at least one coupled software component which performs a given function by introducing, prior to execution, code elements for runtime access of application points associated with the at least one coupled software component, wherein at least one code element associated with the at least one coupled software component provides access control between utilizing-utilized software components; computational apparatus for testing the software application by imposing a fake behavior on the at least one coupled software component, wherein imposing includes removing or replacing an expected behavior of the at least one coupled software component during runtime; and wherein the at least one code element is operative to query said computational apparatus for testing.

         Claim 9 of the '041 patent is a representative method claim.

         9. A software testing method for testing a software application comprising a plurality of software components, at least some of which are coupled, said method comprising:

at least partially isolating from within the software application, by use of a computational apparatus running a testing application, during runtime, at least one coupled software component which performs a given function by introducing into the software application, prior to execution of the software application, code elements for runtime access of application points associated with the at least one coupled software component, such that at least one of the introduced code elements provides the testing application access between utilizing-utilized software components during runtime; and
testing, by use of the computational apparatus running the testing application, the software application by imposing a fake behavior on the at least one coupled software component, wherein imposing behavior includes removing or replacing an expected behavior of the at least one coupled software component, during runtime, by use of the access provided by the at least one of the introduced code elements.

         Typemock alleges infringement of claims 4, 9, 11, 14, 24-26, 28, 34, 39, 41, 44, and 48 of the '923 patent, and claims 4 and 16 of the '041 patent. Having considered the submitted record, the court adopts the parties' agreement (as reflected by the stipulation filed on August 29, 2018 (Dkt # 90), and statements made during the Markman hearing), that the terms “coupled, ” “utilizing-utilized relationship/software component, ” “an associated behavior inducing message, ” “expected behavior, ” “software component, ” “impose[ing] a fake behavior, ” “during runtime, ”[2] and “at least one expectation is generating by recording an actual call” are to be given their plain and ordinary meaning. For reasons that will be stated, the court rejects the parties' proposed construction of “said set.” In addition, the following claim terms remain in dispute:

• “computational apparatus . . .”/“apparatus . . .” (claims 1, 30, 32, 48 of the '923 patent, claim 9 of the '041 patent)
• “first processor . . .”/ “second processor . . .” (claim 1 of the '041 patent)
• “code elements” (claims 1, 30 of the '923 patent, claim 9 of the '041 patent)
• “access controlling code external of the software application” (claims 9, 39 of the '923 patent)
• “at least partially isolate/ing” (claims 1, 18, 30 of the '923 patent, claims 1, 9 of the '041 patent)
• “application points” (claims 1, 30 of the '923 patent, claims 1, 9 of the '041 patent)
• “introducing, prior to execution” / introducing into the software application, prior to execution of the software application” (claims 1, 30 of the '923 patent, claims 1, 9 of the '041 patent)
• “without dependency injection” (claim 30 of the ...

Buy This Entire Record For $7.95

Download the entire decision to receive the complete text, official citation,
docket number, dissents and concurrences, and footnotes for this case.

Learn more about what you receive with purchase of this case.