WILLIAM H. ORRICK, District Judge.
The parties ask the Court to construe 19 terms from the seven patents asserted in this case. As explained by plaintiff Thought's expert, Hosagrahar Jagadish, Ph.D., the patents in suit are aimed at facilitating the transfer of information between two popular schemes for organizing information in a computer: the relational model and the object model. Declaration of Hosagrahar Jagadish in Response (Jagadish Resp. Decl.; Docket No. 76-1) ¶ 11. The relational model is frequently used in database systems, while the object model is used in most programming languages and software applications. Id. Generally speaking, the technology at issue teach methods to allow ordinary users to make object (software) applications and relational databases work together, despite the differences in the ways software applications and database systems organize data.
More specifically, the `197 Patent (Patent Number 5,857,197, issued January 5, 1999), "System and Method for Accessing Data Stores as Objects," teaches the use of an adapter abstraction layer using two adapters (interfaces). The novelty, according to Thought, is the fact that the two adapters or interfaces are used at runtime and one specializes in the object model and the other specializes in the relational database model. Thought argues that the `197 Patent teaches the innovative "basic persistence architecture" of the method (which was incorporated into Thought's "CocoBase" product), and advanced features related to development, modeling, and caching for CocoBase were claimed in the following patents.
The `600 Patent (Patent Number 7,103,600, issued September 5, 2006) is titled "Displayable Presentation Page and SQL Searchable Relational Data Source Implementation of a System, Method and Software for Creating or Maintaining Distributed Transparent Persistence of Complex Data Objects and Their Data Relationship." The `862 Patent (Patent Number 7,167,62, issued January 23, 2007) is titled, "Session Bean Implementation of a System, Method and Software for Creating or Maintaining Distributed Transparent Persistence of Complex Data Objects and Their Data Relationships." These two patents teach how to maintain persistence (to save or to store) for objects and their relationships.
The `481 Patent (7,043,481, issued May 9, 2006), "System, Method and Software for Creating, Maintaining, Navigating or Manipulating Complex Data Objects and Their Data Relationships," discloses a Complex Data Object Graph (CDOG) model to capture the "web" of relationships between objects, also called a "graph." The patent teaches how to represent, manage, an access the graph effectively.
The `956 Patent (6,999,956, issued February 14, 2006), "Dynamic Object-Driven Database Manipulation and Mapping System," teaches how to map data between the object and relational programs using metadata in a library. Jagadish Resp. Decl. ¶ 14.
The `730 Patent (7,149,730, issued December 12, 2006), "Dynamic Class Inheritance and Distributed Caching with Object Relational Mapping and Cartesian Model Support in a Database Manipulation and Mapping System," teaches how to work with multiple data stores that contain information organized differently.
The `912 Patent (6,985,912, issued January 10, 2006), "Dynamic Object-Driven Database Manipulation and Mapping System Having a Simple Global Interface and an Optional Multiple User Need Only Caching System With Disable and Notify Features," addresses the problem of user manipulation of stored data, teaching how to keep copies of data synchronized.
The 19 claim terms in dispute on this motion can be broken down into three categories, discussed below.
Claim construction is a matter of law. See Markman v. Westview Instruments, Inc., 517 U.S. 370, 372 (1996); Vitronics Corp. v. Conceptronic, Inc., 90 F.3d 1576, 1582 (Fed. Cir. 1996). Terms contained in claims are "generally given their ordinary and customary meaning." Vitronics, 90 F.3d at 1582. In determining the proper construction of a claim, a court begins with the intrinsic evidence of record, consisting of the claim language, the patent specification, and, if in evidence, the prosecution history. Phillips v. AWH Corp., 415 F.3d 1303, 1313 (Fed. Cir. 2005); see also Vitronics, 90 F.3d at 1582. "A claim term used in multiple claims should be construed consistently. . . ." Inverness Med. Switzerland GmbH v. Princeton Biomeditech Corp., 309 F.3d 1365, 1371 (Fed. Cir. 2002).
"The appropriate starting point [ ] is always with the language of the asserted claim itself." Comark Commc'ns, Inc. v. Harris Corp., 156 F.3d 1182, 1186 (Fed. Cir. 1998). "[T]he ordinary and customary meaning of a claim term is the meaning that the term would have to a person of ordinary skill in the art in question at the time of the invention, i.e., as of the effective filing date of the patent application." Phillips, 415 F.3d at 1312. "There are only two exceptions to this general rule: 1) when a patentee sets out a definition and acts as his own lexicographer, or 2) when the patentee disavows the full scope of a claim term either in the specification or during prosecution." Thorner v. Sony Computer Entm't Am. LLC, 669 F.3d 1362, 1365 (Fed. Cir. 2012).
"Importantly, the person of ordinary skill in the art is deemed to read the claim term not only in the context of the particular claim in which the disputed term appears, but in the context of the entire patent, including the specification." Phillips, 415 F.3d at 1313. "Claims speak to those skilled in the art," but "[w]hen the meaning of words in a claim is in dispute, the specification and prosecution history can provide relevant information about the scope and meaning of the claim." Electro Med. Sys., S.A. v. Cooper Life Scis., Inc., 34 F.3d 1048, 1054 (Fed. Cir. 1994) (citations omitted). "[T]he specification is always highly relevant to the claim construction analysis. Usually, it is dispositive; it is the single best guide to the meaning of a disputed term." Vitronics, 90 F.3d at 1582. "However, claims are not to be interpreted by adding limitations appearing only in the specification." Id. "Thus, although the specifications may well indicate that certain embodiments are preferred, particular embodiments appearing in a specification will not be read into the claims when the claim language is broader than such embodiments." Id. Conversely, "where [ ] the claim language is unambiguous, [the Federal Circuit has] construed the claims to exclude all disclosed embodiments." Lucent Techs., Inc. v. Gateway, Inc., 525 F.3d 1200, 1215-16 (Fed. Cir. 2008). "[T]he description may act as a sort of dictionary, which explains the invention and may define terms used in the claims," and the "patentee is free to be his own lexicographer," but "any special definition given to a word must be clearly defined in the specification." Markman, 517 U.S. at 989-90.
On the other hand, it is a fundamental rule that "claims must be construed so as to be consistent with the specification." Phillips, 415 F.3d at 1316. "The construction that stays true to the claim language and most naturally aligns with the patent's description of the invention will be, in the end, the correct construction." Renishaw PLC v. Marposs Societa' per Azioni, 158 F.3d 1243, 1250 (Fed. Cir. 1998).
Finally, the court may consider the prosecution history of the patent, if in evidence. Markman, 52 F.3d at 980. The prosecution history may "inform the meaning of the claim language by demonstrating how the inventor understood the invention and whether the inventor limited the invention in the course of prosecution, making the claim scope narrower than it would otherwise be." Phillips, 415 F.3d at 1317 (citing Vitronics, 90 F.3d at 1582-83); see also Chimie v. PPG Indus., Inc., 402 F.3d 1371, 1384 (Fed. Cir. 2005) ("The purpose of consulting the prosecution history in construing a claim is to exclude any interpretation that was disclaimed during prosecution.") (internal quotations omitted).
In most situations, analysis of this intrinsic evidence alone will resolve claim construction disputes. Vitronics, 90 F.3d at 1583. However, "it is entirely appropriate. . . for a court to consult trustworthy extrinsic evidence to ensure that the claim construction it is tending to from the patent file is not inconsistent with clearly expressed, plainly apposite, and widely held understandings in the pertinent technical field." Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1309 (Fed. Cir. 1999). Extrinsic evidence "consists of all evidence external to the patent and prosecution history, including expert and inventor testimony, dictionaries, and learned treatises." Markman, 52 F.3d at 980. All extrinsic evidence should be evaluated in light of the intrinsic evidence, Phillips, 415 F.3d at 1319, and courts should not rely on extrinsic evidence in claim construction to contradict the meaning of claims discernible from examination of the claims, the written description, and the prosecution history, Pitney Bowes, 182 F.3d at 1308 (citing Vitronics, 90 F.3d at 1583). While extrinsic evidence may guide the meaning of a claim term, such evidence is less reliable than intrinsic evidence. Phillips, 415 F.3d at 1318-19.
As an initial matter, the parties agree to following constructions, with respect to terms used in the `197 patent.
An example of how "packing" is used in the `197 patent is demonstrated in Claim 1:
The parties agree the purpose of packing data is to make data suitable for communication. Oracle's definition, however, seeks to incorporate two additional concepts: translating and network. There is no support for incorporating translating into the definition of packing. As an initial matter, translation is a term that arguably requires its own definition. While Oracle argues that "packing" must do something to the data and that simply "placing" the data as suggested by Thought is too ambiguous, Oracle's proposal to use "translating" itself imports further ambiguities. See Jagadish Resp. Decl., ¶ 25 ("Dr. Hosking provides a very cursory analysis of the term `unpacking' in his declaration, and does not explain into what format or formats the data is translated."). Moreover, data does not necessarily need to be "translated" for communication. It could, instead, be compacted, reordered, or otherwise manipulated for various purposes. As Dr. Jagadish notes, there are many purposes persons ordinarily skilled in the art would recognize as being served by packing data, including for storage in place, transport, orderliness or compaction. See, e.g., Jagadish Resp. Decl., ¶¶ 16, 18. Oracle does not demonstrate that "translation" of data is necessary to achieve the agreed-to purpose here — communication — much less any of the other functions packing serves that are also identified in the specification, such as compression and data de-duplication.
With respect to network, Oracle relies on examples in the specification of data being packed prior to being communicated across a network. See `197 Patent at 7:39-54 ("The communication medium 630 between the first adapter 400 and the second adapter 500 may comprise an Internet connection"); at 10:5-12 ("the subject invention reduces network latency (which is essential to reduce over the Internet and other io-bound and high latency networks) and increases the performance and scalability of the involved clients and servers"). Oracle argues these descriptions of the invention make it clear that the "purpose" of the invention is to improve the performance of distributed client-systems. See Hosking Decl., ¶ 112.
However, there are other examples described in the specification showing implementation of the invention in a non-networked, two tier environment. Specifically, the `197 Patent 4:16-21 (emphasis added) explains:
See also `197 Patent4:49-52 ("One embodiment of the subject invention is implemented using the adapter technology and is therefore capable of being deployed as either a 2-tier or as a 3-tier environment transparently.").
Oracle is correct that one claimed benefit from a networked implementation of the invention — as described in the specification — is network efficiency (`197 Patent at 10:5-12; 10:17-24). But Oracle has not shown that the claim language or other parts of the specification require implementation in a networked system. Reducing network latency is a significant benefit of the invention, depending on the embodiment being used, but mentioning that significant benefit did limit the scope of the invention itself. But see Verizon Servs. Corp. v. Vonage Holdings Corp., 503 F.3d 1295, 1308 (Fed. Cir. 2007) ("When a patent thus describes the features of the `present invention' as a whole, this description limits the scope of the invention." (emphasis added)). Moreover, as described in the Summary, the purpose of the invention was not simply reducing network latency, but also solving the object-relations impedance mismatch; a significantly different problem. `197 Patent 3:29-36.
Finally, while Oracle argues that the "logical division" (Fig. 1 at 650) separating the first interface/adapter from the second interface/adapter must be a network division, Oracle points to nothing in the claim language or specification that defines a "logical" division. The term "logical" is significantly distinct from the "physical" division proposed by Oracle. Jagadish Resp. Decl. ¶ 15. To a person of ordinary skill in the art a logical division simply means that software on one side of a logical divide can be programmed independent of the actions of the software on the other side. Id. ¶¶ 15-16. There is nothing in the language of the claims, or in the specification, that requires packed data to be communicated across a network and I will not incorporate that limitation into the definition of packing.
Therefore,
Both proposals flow from the parties' definitions of "packing." While Oracle argues that Thought's "packed data structure" incorporates a new term that itself must be defined, I find that packed data structure is readily understandable and logically flows from the adopted definition of packing. As such,
For example, as used in Claim 1:
Oracle is attempting to incorporate the limitations that the interface communicates between distributed software systems. Thought responds that there are no justifications to import those limitations into the definition of interface. As discussed above with respect to networks and the logical division, while there is some support for Oracle from the discussion of preferred embodiments in the specification that the invention is capable of communicating across distributed systems, there is no reason for me to limit the claims to distributed systems. The specification itself discloses that "the subject invention is capable of accessing objects distributed over a three tier environment using exactly the same application program interface ("API") 700 as the local two-tier environment. This is accomplished by using access "adaptive technology comprising the adapter abstraction layer 600." `197 Patent 4:16-22. The interface contemplated is used in the two tier (local) and three tier (distributed) systems.
Oracle also argues that the common understanding of interface is that an interface is usually used to describe a template for interactions between software components and not a component itself. Hosking Decl. ¶¶ 131-132, 134. However, in support of its position that interface should be defined as a "software component," Oracle argues that Thought specifically defined interface to be the same as an "adapter," which both parties agree is a software component. Oracle relies on language from claim 2 of the `197 Patent where Thought claims "A system according to claim 1 wherein the first interface comprises a first adapter and the second interface comprises a second adapter." `197 Patent 35:23-25.
Neither Thought nor its expert addresses this argument, except to point to other language in claims 1 and 7 explaining that the interfaces are part of the adapter abstraction layer. `197 Patent claim 1 35:7-17 ("an adapter abstraction layer having a first interface . . . and a second interface in communication. . . ."); claim 7 36:66-67 ("an adapter abstraction layer having a first interface and a second interface"). At the claim construction hearing, Thought asserted that claim 2 simply makes it clear where the "adapters" are located (in the adapter abstraction layer, with the first and second interfaces for the first and second adapters respectively) and that, for example, claim 3 clarifies the purpose of the abstraction adapter layer and its use of adapters. See also Jagadish Resp. Decl. ¶ 47 ("In the case of the `197 patent, the first adapter implements the first interface, and the second adapter implements the second interface.").
I find that while claim 2 could be read as using the terms interface and adapters interchangeably ("wherein said first interface comprises a first adapter and the second interface comprises a second adapter"), it can also be read as identifying where the adapters are located (as argued by Thought) and as adding more functionality to the invention. As the Court is required to give effect to a patent's use of different terms, unless contrary to the express claim language, Thought's proposed construction is more appropriate.
As Thought's expert explains, interfaces are commonly understood by persons ordinarily skilled in the art as "part of an adapter abstraction layer that facilitates interaction between software components." Jagadish Resp. Decl. ¶ 27. This is supported by the specification which explains a distinction between the adapters and interfaces: in the present invention, because the adapters in the adapter abstraction layer "implement the same API [interface] 700, they are interchangeable in the object application 101, providing new and useful functionality. . . ." `197 Patent at 9:38-42.
Therefore,
For example, as used in Claim 3:
The parties agree that the adapters are interchangeable, part of the abstraction layer, and facilitate communication. Oracle, again, seeks to incorporate the limitation that the components are communicating between two distributed software systems. For same reasons as discussed above, I find no support for Oracle's proposed "two distributed systems" limitation. See also Hosking Deposition, Vol II, 150:4-22 (acknowledging that invention of `197 Patent will function even if there is no physical separation, but just a logical separation between the first and second adapters).
Thought's definition includes that the adapters are interchangeable at "runtime." There is significant support for Thought's position. The specification repeatedly refers to the invention as incorporating "runtime" adapters. See, e.g., `197 Patent at 2:46-49 ("Accordingly, there is a need to dynamically build the code for accessing the data store at runtime. . . ."); 4: 66-67 ("The subject invention uses the adapter technology to dynamically load data store access code at runtime."); 9:34-47 ("The present invention comprises the adapter abstraction layer 600 comprising a set of runtime adapters (e.g. the first adapter 400, the second adapter 500, the n-th adapter 4XX, 5XX), which can be transparently interchanged by the object application 101. . . . Because all adapters implement the same API 700, they are interchangeable in the object application 101, providing new and useful functionality, even beyond the subject implementation, without requiring object application 101 modification. Object application 101 runtime flags can instantiate entirely new adapters which might interface with radically different data store(s) 302 without modification to object application 101."); 10:25-33 ("New adapters . . . may be added to the adapter abstraction layer 600 dynamically, even at runtime, as long as they comply with the API.")
As Oracle points out, "runtime" is not used in the claim language. Dr. Jagadish explains that runtime adapters are "inherent in the adapters of the invention claimed in the `197 patent." Jagadish Resp. Decl. ¶ 41. He describes the importance of runtime changeable adapters and runtime flags that signal their use, in that that "runtime flags as mentioned in the `197 patent specification allow different runtime interchangeable adapters to be used without having to recompile the application. In other words, there is no need to reenter the compile time phase in order to effect interchanging the runtime interchangeable adapters of the `197 patent." Id. ¶ 44. He says that "[s]ignificant time and costs are often associated with modifying an application's source code and subsequently recompiling the application. The ability to use or substitute various runtime interchangeable adapters without having to recompile the application provides greater flexibility with respect to data sources while reducing the time and cost required to maintain the application." Id. at 45.
Therefore,
For example, as used in Claim 1:
As used in Claim 7:
Both sides agree that the interfaces are provided by the adapters and, as discussed above, that adapters are interchangeable. At the claim construction hearing, Thought agreed that Oracle's proposed definition would be appropriate if the Court adopted Thought's proposed definition of adapter.
Therefore,
As used:
Oracle and its expert spend much time explaining why its proposed construction is consistent with the understanding a person of ordinary skill in art had about "weakly" and "strongly" consistent synchronization, and how "fully" is most likely synonymous with "strongly." Hosking Decl. ¶ 168. However, the claim language itself defines the scope and purpose of the "fully synchronized caching system," namely that the system:
`956 Patent at 51:6-10, 25-29.
This intrinsic explanation of the caching system is more significant than Oracle's extrinsic discussion of what a person ordinarily skilled in the art understands about weakly or strongly consistent caching.
Therefore,
Oracle argues that five claim terms are impermissibly indefinite and, therefore, invalid. The parties dispute whether Oracle's indefiniteness challenge is appropriate resolved on claim construction (as opposed to on a motion for summary judgment) and what the burden is on Oracle to demonstrate indefiniteness at this juncture.
Indefiniteness is a part of 35 U.S.C. § 112, therefore, the mandates of 35 U.S.C. § 282 apply. See 35 U.S.C. § 282(b)(2). Under 35 U.S.C. § 282(a), the burden of establishing invalidity for indefiniteness falls squarely on Oracle, the party asserting invalidity. Microsoft Corp. v. i4i Ltd. P'ship, 131 S.Ct. 2238, 2242, 2011 U.S. LEXIS 4376, * 7 (2011) (invalidity defenses must be proved by "clear and convincing evidence"); see also Nautilus, Inc. v. Biosig Instruments, Inc., 134 S.Ct. 2120, 2014 U.S. LEXIS 3818, * 24 fn.10 (June 2, 2014).
As the Supreme Court recently explained "a patent is invalid for indefiniteness if its claims, read in light of the specification delineating the patent, and the prosecution history, fail to inform, with reasonable certainty, those skilled in the art about the scope of the invention." Nautilus, Inc. v. Biosig Instruments, Inc., 2014 U.S. LEXIS 3818, * 6. To evaluate an indefiniteness claim I must: (i) evaluate the claim from the perspective of someone skilled in the relevant art; (ii) read the claim in light of the patent's specification and prosecution history; and (iii) measure definiteness from the viewpoint of a person skilled in the art at the time the patent was filed. Id., 2014 U.S. LEXIS 3818 at *17-18. The claim language must be "precise enough to afford clear notice of what is claimed, thereby "`appris[ing] the public of what is still open to them.'" Id. (quoting Markman v. Westview Instruments, 517 U.S. 370, 373 (1996) (internal quotation omitted); see also Carnegie Steel Co. v. Cambria Iron Co., 185 U.S. 403, 437 (1902) ("any description which is sufficient to apprise [steel manufacturers] in the language of the art of the definite feature of the invention, and to serve as a warning to others of what the patent claims as a monopoly, is sufficiently definite to sustain the patent").
For example, as used in Claim1:
Oracle argues "extensive knowledge" is indefinite because it is not and cannot be accurately defined by a person ordinarily skilled in the art. Thought contends that "extensive knowledge" is not indefinite because "because the environment dictates the necessary preciseness of the terms." Power-One, Inc. v. Artesyn Techs., Inc., 599 F.3d 1343, 1348 (Fed. Cir. 2010) (rejecting claim that "near" and "adapted to" are indefinite because of clarity provided by remaining claim language). Here, Thought contends that "extensive knowledge" is clarified by the language following the term: "extensive knowledge of a particular relational database as a source of the data, or extensive knowledge about how to directly access that relational database." `956 Patent 49:52-54. It is also clarified by the description of an embodiment which explains its purpose is to manage database access code "requiring only an understanding of the data store 302 and the data store schema 300, instead of requiring object programming knowledge within the modem working environment." `956 Patent 11:30-35; see also id., 10:32-35 (allows engineers to "concentrate on applications code without concern for or need to learn SQL or any other native access code 205 of the data store."); id. 26:50-54 ("translation system . . . provides an entire set of tools to simplify and improve an operators ability to manipulate maps without requiring a high level of programming knowledge or database query language familiarity. . . .").
Dr. Jagadish explains that in order to use a database, after gaining access through a password or other code, a user would have to know the schema and query language of the database in order to edit and retrieve data. Jagadish Resp. Decl. ¶ 66. He declares that "person of ordinary skill in the art would understand the term `extensive knowledge'" of a particular relational database or how to directly access that relational database, to mean "`knowledge of the schema and query language sufficient to save or retrieve data' in the context of the `956 patent." Id. ¶ 61. Oracle's expert, Dr. Hosking disputes that assertion, arguing instead that knowledge of "access" could also mean the technicalities of figuring out a database location on the network or any credentials necessary to access the database. Hosking Decl. ¶ 189. However, when viewed in the context of the claim language and specification, Dr. Jagadish's position is more persuasive.
I find that "extensive knowledge" is not indefinite when considered with the remaining claim language and the descriptions of the invention/embodiments in the specification. When read in light of these, a person ordinarily skilled in the art would understand that extensive knowledge means that the user can perform certain tasks — as explained in the patent, including editing or creating tables, fields, or maps — without requiring the user to have extensive knowledge of a relational database or how to directly access that database. Jagadish Decl. ¶ 64.
The case on which Oracle relies is inapposite. In Datamize, LLC v. Plumtree Software, Inc., 417 F.3d 1342, 1345 (Fed. Cir. 2005), the court concluded that claim language regarding displays of electronic information on kiosks "in conformity with a desired uniform and aesthetically pleasing look and feel for said interface screens on all kiosks of said kiosk system," was indefinite. The court found that "Datamize has offered no objective definition identifying a standard for determining when an interface screen is `aesthetically pleasing.' In the absence of a workable objective standard, `aesthetically pleasing' does not just include a subjective element, it is completely dependent on a person's subjective opinion." Id. at 1350. Because "[t]he scope of claim language cannot depend solely on the unrestrained, subjective opinion of a particular individual purportedly practicing the invention," the court found the term "aesthetically pleasing" indefinite. Id. Here, however, the specification and description of the invention give persons skilled in the art an objective standard to determine the knowledge required to practice the invention. Unlike in Datamize, the scope of the language does not depend on the subjective opinion of the person practicing the invention and the patent is not indefinite.
Moreover, while "extensive" knowledge is a word of degree, words of degree are not indefinite where the "environment," meaning the remaining claim language and specification, "dictates the necessary preciseness of the terms." Power-One, Inc., 599 F.3d at 1348; see also Interval Licensing LLC v. AOL, Inc., 2014 U.S. App. LEXIS 17459 (Fed. Cir. Sept. 10, 2014) ("Claim language employing terms of degree has long been found definite where it provided enough certainty to one of skill in the art when read in the context of the invention."); Seattle Box Co. v. Indus. Crating & Packing, Inc., 731 F.2d 818, 826 (Fed. Cir. 1984) ("when a word of degree is used the district court must determine whether the patent's specification provides some standard for measuring that degree."). That is exactly what the specification does in this case; it indicates that a user need not have extensive knowledge of the structure and contents of a relational database that would otherwise be necessary to access and change the information in that relational database.
However, to add additional clarity for purposes of claim construction,
As used in Claim 1 of the `956 Patent:
Oracle argues that the "thing" being provided to a system user is missing and, therefore, indefinite. Oracle claims that Thought's definition is an impermissible attempt to correct an incomplete phrase or drafting error in patent. As the Federal Circuit has explained, a district court can act to correct an error "in a patent by interpretation of the patent where no certificate of correction has been issued," but can only do so "if (1) the correction is not subject to reasonable debate based on consideration of the claim language and the specification and (2) the prosecution history does not suggest a different interpretation of the claims." Novo Indus., L.P. v. Micro Molds Corp., 350 F.3d 1348, 1354 (Fed. Cir. 2003); see also Hoffer v. Microsoft Corp., 405 F.3d 1326, 1331 (Fed. Cir. 2005) (where PTO erred in failing to change reference to a specific antecedent claim number, court held that where "the error was apparent from the face of the patent, and that view is not contradicted by the prosecution history.").
Thought responds that it is not seeking to correct an error, but to interpret the claim language consistently with the remaining claims and the specification by clarifying that what is provided to the system user is the ability to do the items listed in the claim language. `956 Patent 49:43-45 ("to make data changes related to a particular object and to promulgate the changes to that object"); `730 Patent 53:16-18("to make data changes related to a particular object and to promulgate the changes to that object"); see also Jagadish Resp. Decl. ¶¶ 77-78 ("if the claim limitation is considered based on the specifications of the `956 and `730 patents, then it is clear that the claim limitation already recites what is being provided to the system user, namely the ability or capability `to make data changes related to a particular object and to promulgate the changes to that object as either local or global changes on the computer system.' . . . It is only logical that the claim limitation would recite this capability of the mapping system as what is being provided to the system user, and a person of ordinary skill in the art would have no difficulty understanding the meaning of the claim limitation.").
When the claim language is read in full, I agree with Thought that the claim is conferring "the ability" of a user to do the things listed in the claim; make data changes related to a particular object, etc. This is not, as Oracle argues, a correction of an "error." It is instead a construction clarifying the awkward language of the claim and a construction that flows directly from the text of the claims themselves.
Therefore,
Class is specifically defined in the `600 and `862 Patents as:
Class is specifically defined in the `730 Patent as:
Oracle argues the express definition of object provided in `600 and `862 Patents should be adopted. The Patents define "object" as follows: "`Object' as used in the context of this document is a general term referring to a logic unit in a computer application or a computer software program. . . . The term `object' may be used interchangeably with the term `class' as a template or as an instance depending on the context." `600 Patent 4:1-7; see also `862 Patent 3:63-4:2. However, Oracle argues that this definition is itself ambiguous — because it conflates the normally distinct concepts of "object" and "class" — and therefore, the term is indefinite in each case. See, e.g., Hosking Decl. ¶ 197.
Thought's proposed construction is narrower than the broad definition adopted in the patent specifications, because the specification-definition allows "object" to be used as both a "class" and instance of a class depending on the context of use. Because Thought has acted as its own lexicographer, I adopt Thought's own definition. Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005) ("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."). Therefore, for the `600 and `862 Patents,
I disagree with Oracle's argument that the definition is inherently ambiguous. Both the definitions in the `600 and `862 Patents expressly rely on the context of each use of object in the Patents to inform a person skilled in the art whether in that case object is being used as an instance or as a template. Oracle points to no examples from the claim language or specification where the context does not provide adequate precision for a skilled person to be able to understand how object is being used.
Oracle argues the explicit definition used in the `730 Patent at 17:60-65 should be adopted, and does not challenge that definition as indefinite. Oracle Response Br. at 23. In Reply, Thought does not object to that definition. Reply at 16:13-14. Therefore, for the `730 Patent,
"Model" is also expressly defined in the patents as follows:
Oracle argues that the patents disavow the normal use of the term, and instead adopt an idiosyncratic one that, like object, depends upon its context. See, e.g., `600 Patent 5:17-26 ("Ordinarily computer engineers refer to the model as an abstraction rather than a specific possibility or instance of the model as applied. However, in this document for the ease of communication abstractions of the model, possible implementations of the model and instances of the model are all referred to generally as application model or model. From the context of its use the term will be clear."). Oracle contends that the definition of model as used in the patents is insolubly ambiguous and indefinite because the patents provide no guidance on what the context should be or how it is applied to each use of model in the terms (abstractions, implementations, and instances). However, Dr. Jagadish explains that the context of the use of model adequately informs a person skilled in the art about the particular meaning of model. See Jagadish Resp. Decl. ¶¶ 69, 72 ("The `600 and `862 patents describe various types of models by adding specific qualifiers to the word "model," such as object model, object graph model, complex data object graph model, CDOG model, and navigation model. The qualifiers make it clear what specific type of model it is in each instance."). Oracle's expert does not dispute this or point to any actual uses of "model" in the claims or specifications that do not provide adequate context.
Thought's proposed definition is based on, but is not a verbatim adoption of, the express definition provided in the Claims. Thought proposes that model be defined as a "logical or abstract representation or description," where the Patents define "`Application model' or `model' are essentially interchangeable terms employed herein as abstractions to logically convey a collective description or other representation for a set of complex data objects and a corresponding description or other representation of their relationships."`600 Patent 5:16-22. Other than arguing that the Patents' use of "model" is indefinite, Oracle does not dispute or challenge the proposed, narrower definition suggested by Thought.
I find that
This term is used twice, as exemplified in Claim 1:
Oracle argues first that Thought's proposed construction is illogical because, a "CDOG is `an abstraction to logically represent a set of complex data objects and a set of their corresponding relationships'" (`481 Patent 5:5-8), and a model is "a representation of relationships among classes." When these two terms are used together, "the plausible understanding is that the higher level of abstraction applies, and that a `CDOG model' is a representation of relationships among classes, the instances of which may be related in a CDOG." Hosking Decl., ¶ 211. As such, according to Dr. Hosking and contrary to Thought's proposal, "neither a CDO nor its relationships are part of a CDOG model, because a CDOG model represents classes and their relationships and not objects and their relationships." Id. ¶ 212.
Oracle also argues that something is missing from the claim language itself (presumably because of a mistake by the patent drafter) and that Thought's proposed definition is an impermissible attempt to make a correction to otherwise unintelligible language. See, e.g., Novo Indus., L.P. v. Micro Molds Corp., 350 F.3d 1348, 1354 (Fed. Cir. 2003). Oracle contends that Thought's attempted correction is impermissible because there is more than one way the language could reasonably be corrected. Dr. Hosking explains, this term could be rewritten as either (i) "changes to a CDO, or its relationships, or a CDOG model" or (ii) "changes to a CDO or its relationships to a CDOG model." Hosking Decl. ¶¶ 214-15. Because there are different options as to how to redefine the language of the claim, and those different options have a different scope and different implications, Thought can only seek a clarification from the PTO to correct the error with the language.
As to the first point, Thought argues that Dr. Hosking ignores that "model" is explicitly defined as not only an "abstraction," but also as an implementation and instance of the model, depending on the context. `481 Patent, 5:29-33. As explained in the summary of the invention, "An object of the present invention is to provide a system for creating, maintaining, accessing, navigating and persisting complex data objects as a complex data object graph (CDOG) model." `481 Patent 5:53-56. Therefore, as used in this patent, model is not simply a representation of classes and their relationships as Dr. Hosking contends but can also encompass "a representation of objects and their relationships," Jagadish Resp. Decl. ¶ 81.
As to the second, Thought argues that its proposal is not an attempt to correct an error but instead a construction that clarifies — based on the express definitions of CDO, CDOG and model in the specification — what is otherwise awkward language. Id. ¶ 82.
Looking to the claim language and specification, I agree with Thought that the phrase "changes to a CDO or its relationship of a CDOG model" is not indefinite. Instead, reviewing how the phrases CDO, CDOG and CDOG model are actually used in the specification, Thought's clarifying construction is appropriate. Therefore,
As used in Claim 12:
Oracle argues that this phrase is indefinite, relying on the fact that in a prior claim chart, Thought itself identified the "information of (a)" as the information listed in claim 7(a). Hosking Decl. ¶ 220. Dr. Hosking says reliance on 7(a) to provide the "information" for 12(b) makes sense because claim 12 depends from claim 7 and claim 7(a) explicitly cites "information" (e.g., information sufficient to construct a CDOG model) whereas 12(a) does not expressly cite information (e.g., reading a source programming object logic model or database definition file in various formats). Hosking Decl. ¶¶ 218, 221. But he argues because 12(a) cites "implicit" information, and 7(a) also has 7(a)(II) and 7(a)(III) subparts that likewise contain "implicit information," what the 12(b) claim is actually referring to "as the information of (a)" is insolubly ambiguous. Id. ¶¶ 217, 222.
Thought responds that its prior reliance on 7(a) as the source of 12(b)'s "information of (a)" was a typographical error in its prior claim chart. Thought Reply Br. at 19, n.72. When arguing this issue on the merits, Thought asserts it has been consistent that "the information of (a)" refers to the information in 12(a), which immediately precedes the language in 12(b), which is logical and supported by the specification.
Reviewing the claim language and specification, I agree with Thought. Not only does 12(a) immediately precede 12(b), but the description of the invention in the specification supports that construction. See `481 Patent 6:54-63 ("A further object of the present invention is to a software tool capable of reading a source programming object logic model or a database file in a format selected from the group consisting of a UML data file, m [sic] a XMI data file, and a XML file and converting the information into a target member selected from the group consisting of a database definition XML file, a database mapping definition file, and a CDOG definition file. In a preferred object, the software can automatically generate a persistence layer that corresponds to the object model information of the source file."); see also `481 Patent 9:16-29. As Dr. Jagadish explains, this section of the specification tracks the language of 12(a) and (b) but does not refer to any of the explicit or implicit information recited in Claim 7 that Dr. Hosking relies on. Jagadish Resp. Decl. ¶ 86.
Therefore,
As used:
Oracle argues that because "repository maps" and "navigational models" or "navigations schemas" play no defined role in furthering the purpose of the claim or the invention, and because "repository maps has no generally understood meaning in the art," the terms are indefinite. Hosking Decl. ¶¶ 231, 233, 234. Oracle also argues that repository maps and a navigational model are distinct, but the claim language fails to explain how they work together. As Dr. Hosking states, even accepting the definitions of the discrete terms used in other parts of the claim language and specification, "it is still the case that the patent gives no guidance to one of ordinary skill in the art as to how to organize one thing (in this case, `repository maps') according to a model of another thing (`in this case object relationships as represented in a "navigational model or schema"`)." Hosking Decl. ¶ 237.
Thought responds that repository maps are maps in the "mapping repository" which is part of the "mapping system," and the specification describes exactly how repository maps can be imported into or exported from the mapping repository. See Jagadish Resp. Decl. ¶ 88 ("That is, they are the rules governing how data are mapped between two or more data sources. Without these maps in the mapping repository (i.e., the repository maps), the mapping system would not be able to perform its functions."); see also `730 Patent at Figure 2 (illustrating use of repository maps). Dr. Jagadish explains that "mapping" is "a term of art and it means the identification of correspondences between data items in two different representations." Id. ¶ 89. He opines that "term `repository maps,' when analyzed in the context of Claim 1 and the specification of the `730 patent, obviously refers to the maps in a mapping repository, which in turn is part of the mapping system. The maps in the mapping repository, which are referred to as `repository maps' at times, are essentially rules that govern how data from one data source should be correlated with and/or translated into data from another data source. The specification of the `730 patent describes in detail how the repository maps can be imported into or exported from the mapping repository as well as how the repository maps are managed." Id. ¶ 90; see also 18:31-41 (defining "repository").
Given the descriptions of repository maps (as well as the definition of repository and the well-known meaning of mapping), I disagree with Oracle and find that the purpose and role of repository maps are adequately defined and explained in the specification. See, e.g., `481 Patent 4:9-10; 4:25-36; 19:5-25.
With respect to "navigational model or schema," Thought notes that model has been previously defined and schema is readily understood and not disputed. For the particular use of "navigations model," Thought relies on the definitions of navigational model found in the related `481 and `600 patents. `481 patent at 5:41-45; `600 patent at 5:35-39 ("`Navigation model'" as used herein is a special type of application model that is applied specifically to a description (or other representation) of how objects can relate to each other and what might be the expected behavior when a CDOG is navigated for a certain purpose."). Dr. Jagadish declares that in light of these definitions, "organizing the repository maps according to a navigation model or schema" means that the "repository maps are organized according to how objects are related to each other and what may be expected when navigating a complex data object graph. Since a user often accesses objects based on their relationships as specified in a navigation model or schema, organizing the repository maps according to the navigation model or schema may help improve the performance of the mapping system." Id. ¶ 94. Applying the definition of "navigation model" as used in the `481 and `600 patent (in absence of any argument by Oracle as to why those definitions would not apply similarly in the context of the `730 Patent), I conclude that organizing repository maps according to a navigational model or schema is adequately defined for a person skilled in the art and not indefinite.
Therefore,
Oracle contends that six terms are indefinite under 35 U.S.C. § 112(f) as means-plus-function claims that lack disclosure of an adequate structure in the patent specifications. I must first determine whether each disputed term is appropriately considered means-plus-function and, if so, whether the required structure is disclosed in the relevant specifications.
As with the § 112(b) challenge discussed above, Oracle bears burden of demonstrating that the claims are means-plus-function and lack the required structure by a preponderance of the evidence. Apple Inc. v. Motorola, Inc., 757 F.3d 1286, 1298 (Fed. Cir. 2014). Whether claim language invokes Section 112(f) is a question of law. Id. at 1296. § 112(f) provides:
"The overall means-plus-function analysis is a two-step process. . . . In the first step, we must determine if the claim limitation is drafted in means-plus-function format. As part of this step, we must construe the claim limitation to decide if it connotes `sufficiently definite structure' to a person of ordinary skill in the art, which requires us to consider the specification (among other evidence). In the second step, if the limitation is in means-plus-function format, we must specifically review the specification for `corresponding structure.' Thus, while these two `structure' inquiries are inherently related, they are distinct." Id. at 1296; see also id. at 1296-97 (noting that prosecution history and relevant extrinsic evidence can inform the first step).
Importantly, "when a claim limitation lacks the term `means,' it creates a rebuttable presumption that Section 112[f] does not apply." Id. at 1297. The presumption is "strong" and "not readily overcome." Id. However, the presumption may be overcome if the claim fails to recite "sufficiently definite structure" or merely recites a "function without reciting sufficient structure for performing that function." Id.
As the Federal Circuit recently explained, "`[s]tructure' to a person of ordinary skill in the art of computer-implemented inventions may differ from more traditional, mechanical structure. For example, looking for traditional `physical structure' in a computer software claim is fruitless because software does not contain physical structures. Indeed, the typical physical structure that implements software, a computer, cannot be relied upon to provide sufficiently definite structure for a software claim lacking `means.' Rather, to one of skill in the art, the `structure' of computer software is understood through, for example, an outline of an algorithm, a flowchart, or a specific set of instructions or rules." Apple Inc. v. Motorola, Inc., at 1298.
Moreover, "[a] limitation has sufficient structure when it recites a claim term with a structural definition that is either provided in the specification or generally known in the art." Id. at 1299. "Structure may also be provided by describing the claim limitation's operation, such as its input, output, or connections. The limitation's operation is more than just its function; it is how the function is achieved in the context of the invention." Id. Therefore, "if a limitation recites a term with a known structural meaning, or recites either a known or generic term with a sufficient description of its operation, the presumption against means-plus-function claiming remains intact." Id. at 1300. However, "if the claim merely recites a generic nonce word and the remaining claim language, specification, prosecution history, and relevant external evidence provide no further structural description to a person of ordinary skill in the art, then the presumption against means-plus-function claiming is rebutted." Id.
As explained in Apple v. Motorola, the question is if this term has a known structural meaning or whether the claim language contains a sufficient description of its operation that person skilled in the art would know what to do. Here, "computer logic" is not a known structural meaning; it is simply a process. The claim language does not explain how the logic works, but simply its function: to persist objects.
This term is unlike the term reviewed in Apple Inc. v. Motorola, Inc, where the Federal Circuit reversed the trial court's conclusion that the term "heuristics" was a means-plus-function description without disclosure of sufficient structure. There, the patent claimed a device with "programs" including:
Id. 757 F.3d at 1295. The Federal Circuit held that the concept of heuristics not only had a known meaning by persons ordinarily skilled in the art
Therefore, I find that, even reviewing the specification in order to properly construe this term, "computer logic" invokes means-plus-function claiming. See, e.g., Visual Networks Operations, Inc. v. Paradyne Corp., 2005 WL 1411578 (D. Md. June 15, 2005) ("`Logic for determining at least one dedicated time slot(s)' describes only a function, not a structure. Any number of different algorithms, in the form of either computer code or hard-wired circuit logic, could perform the recited function."); ABB Automation Inc. v. Schlumberger Res. Mgmt. Svcs., Inc., 2003 U.S. Dist. LEXIS 5002 (D.Del. Mar. 27, 2003) ("The court finds that `logic' does not recite sufficient structure to avoid means-plus-function analysis."); see also Transperfect Global, Inc. v. MotionPoint Corp., C 10-2590 CW, 2013 WL 2299621 (N.D. Cal. May 24, 2013) ("Here, the patents' claims recite function without reciting any definite structure. The relevant claims do not identify any specific hardware or software for performing the functions listed in each claim. Instead, they refer simply to an `apparatus . . . comprising: a module for' performing those functions. These generic references do not recite a sufficiently definite structure.").
The parties agree that the function at issue is "persisting an indicated object or sets of objects." In its briefing, Thought relied on various portions of the specification to disclose the structure, including discussions of object implementation through persistence software, which is disclosed in the bottom block of Figure 3 in the `600 Patent, 10:25-26. The bottom block of Figure 3, however, simply discloses a "Persistence Library or API for Persisting Objects, Links, Object Data, and/or an Object Model." This "black box" does not disclose an algorithm or otherwise instructions for accomplishing the function. See, e.g., Blackboard, Inc. v. Desire2Learn, Inc., 574 F.3d 1371, 1383 (Fed. Cir. 2009). ("The ACM is essentially a black box that performs a recited function. But how it does so is left undisclosed.").
Thought also relies on a preferred embodiment discussed in the Specification that, according to Thought, "disclose[s] extremely specific examples of the algorithm" by disclosing use of Thought's CocoBase product, including CocoNavigator API. `600 Patent 12:19-29; 14:4-17-34; 15:13-20:52. Similarly, at the Claim Construction hearing, Thought argued that the specification discloses a sufficient structure by referring to the Java Data Base Connectivity (JBDC) application programming interface (API).
Oracle does not dispute that the JBCD and CocoBase software programs are disclosed in the patents. Oracle does not dispute that these programs are sufficiently "linked" to the claimed function, and Oracle does not dispute (and its expert admits) that CocoBase and JBDC can perform the claimed function.
Oracle relies on Noah Sys. Inc. v. Intuit Inc., 675 F.3d 1302 (Fed. Cir. 2012). However, that case did not reject the idea that software products specifically identified in the specification could not satisfy the disclosed structure requirement. Instead, in that case, the patentee relied on the specification's mention of "off the shelf software" from a part of the specification dealing with a different claim and then asserted "individuals of ordinary skill in the art would understand how to accomplish the function described with the assistance of such off the shelf software." Id. at 1317. The Federal Circuit rejected the patentee's arguments because the disclosure itself must identify the method for performing the function "whether or not a skilled artisan might otherwise be able to glean such a method from other sources or from his own understanding," and concluded that the patentee's "efforts to find structure in the portion of a specification linked to a different claim element or in the common ken of a skilled computer artisan does not allow it to `avoid providing [the] specificity as to structure' required by § 112 ¶ 6." Id. The other cases relied on by Oracle are also inapposite as the claim language, at most, identified "software" or a "computer" to perform the requisite function. See Fujifilm Corp. v. Motorola Mobility LLC, 12-CV-03587-WHO, 2013 WL 6185254 (N.D. Cal. Nov. 18, 2013 (finding insufficient structure where reference was to a "CPU [] `programmed to calculate' its function, without adequately disclosing the structure or method for performing such a calculation or such programming, effectively leaving the CPU a general purpose computer."); Encyclopaedia Britannica, Inc. v. Alpine Electronics of Am., Inc., 2008 WL 7328271 (W.D. Tex. Sept. 30, 2008) aff'd sub nom. Encyclopaedia Britannica, Inc. v. Alpine Electronics, Inc., 355 F. App'x 389 (Fed. Cir. 2009) ("A general reference to `software' is not sufficient to disclose structure," rejecting claim that software not disclosed in the specification was an adequately disclosed algorithm); Touchcom, Inc. v. Dresser, Inc., 427 F.Supp.2d 730, 736 (E.D. Tex. 2005) (rejecting patentee's argument that a branded device mentioned in the patent in conjunction with its publicly available software drivers could perform the recited function because "[t]hese drivers are not sufficiently disclosed and referenced in the specification to supply the corresponding structure for controlling the input means.").
At the Claim Construction hearing, Thought relied exclusively on the disclosure of JBDC, arguing that Dr. Hosking himself testified in his deposition that JDBC alone is a sufficient structure to persist an object. Hosking Depo. at 18:03:04. In his Supplemental Declaration — submitted at the Claim Construction hearing — Dr. Hosking admits that JBDC can be "used" to persist objects, but that a programmer would still need to develop and sequence the specific commands that JBDC uses to transmit to the database. Hosking Supplemental Declaration (Docket No. 105), ¶¶ 12-13. Therefore, according to Dr. Hosking, different programmers can "use" JBDC in different ways to accomplish the persisting function and can also use the JBDC without knowing how a particular JBDC driver (created by database developers to provide a JBDC interface for their databases) is implemented. Id. ¶¶ 13-14. Dr. Hosking does not explain the significance of the fact that programmers could use different sequences of commands to use JBDC to persist data, and he does not otherwise challenge Thought's position that a person skilled in the art could use the disclosed JBDC to "persist" data as required by the claim language. Instead, based on his belief that an "algorithm" is required by Federal Circuit precedent to satisfy means-plus-function structure, he simply notes that the "bare reference" to "use JBDC" does not disclose an algorithm for implementing the data persisting function. Id. ¶ 15.
Relying on Dr. Jagadish's undisputed position that a person skilled in the art could use the disclosed CocoBase program and API, as well as Dr. Hosking's agreement that the disclosed JBDC could also be used to persist data as required by the claim, and in light of persuasive Federal Circuit authority allowing the "algorithm" requirement to be satisfied by a disclosed piece of software, I find that that "computer logic" has been sufficiently described.
As with "computer logic," "logic for assessing" is not a known structural meaning; it is a process. Despite the lack of the term "means," construing the claim language in light of the specification, I find the term "logic for assessing" invokes means-plus-function claiming.
The parties agree that the function as issue is logic for "accessing each schema corresponding to a different data source accessible to the mapping system."
Oracle and its expert do not dispute that disclosure of CocoBase and JBDC is made repeatedly in the specification for the `730 Patent and "linked" to the function to be performed. Instead, Oracle argues that the disclosure of those software programs is insufficient because there still is no "algorithm" provided that explains in the text of the specification how the steps for accessing the schemas of the different databases take place. Oracle Response Brief at 36. Dr. Hosking states that the portion of the specification discussing CocoBase does not mention "accessing schemas," Hosking Decl. ¶ 266, but acknowledges that JBDC could be used to access "each schema corresponding to a different data source accessible to the mapping system." Hosking Supp. Decl. ¶ 10. He argues, as above, that even though JDBC could be used to perform the accessing at issue, because there might be different command sequences to do so and because "use of JDBC" indicated in the specification does not disclose how to use the program to perform the access or how JDBC operates to perform the accessing, it cannot satisfy the algorithm requirement. Id. ¶¶ 12-15.
Similar to the prior claim, Dr. Hosking does not explain the significance of the fact that programmers could use different sequences of commands to use JBDC to access the schemas, and he does not otherwise challenge Thought's position that a person skilled in the art readily knows how to perform this basic concept, and could do so using JBDC. Relying on the undisputed fact that use of CocoBase and JBDC were disclosed in the specification and adequately linked to accessing the database schemas, I find that the structure of "logic for assessing" is adequately disclosed.
The logic at issue in this term, as an initial matter, is far more complex that simply "persisting" or "assessing." The logic here must perform complex functions — maintaining all or simply a portion of data, in a data source having the same or a different schema. The claim language, even when considered with the remaining claim language and the specification, does not describe sufficient operation — e.g. how the logic achieves its end — to avoid treatment as a mean-plus-function term. I find, therefore, that this term invokes mean-plus-function claiming.
The parties agree that the function here is for "creating or maintaining all or a portion of such data in at least one second data source having the same or a different data structural schema." Thought contends that the structure is disclosed by references to CocoBase, specific code examples that implement the claim, as well as reference to a Java application. Thought Opening Br. at 36; Reply at 23; see also `730 Patent 32:44-66 (disclosing Thought.CocoBase.SynchPlugin); Jagadish Decl. ¶ 144.
In response, Dr. Hosking argues that disclosures based on Java are insufficient because the specification fails to disclose how a Java application could be created or how it would access the relevant data. Hosking Decl. ¶ 286. He also argues that the CocoBase reference and code examples are insufficient because they do not encompass how the whole system covered by the `730 Patent. See, e.g., Hosking Decl. ¶ 277 (no elaboration on how data is actually transmitted or how mismatches are handled and resolved) ¶ 278 (fails to disclose how the second database is identified and connected to). However, as Dr. Jagadish points out, Java was a well-known program in 2003, and there is no dispute that Java could perform the "creating and maintaining" function. Jagadish Resp. Decl. ¶ 125. As to the functions Dr. Hosking claims are not explicitly addressed in the specification, Dr. Jagadish argues those functions go beyond the "creating and maintaining" feature, which is all that needs to be disclosed and is disclosed in the specification with respect to this claim. Id. ¶ 126.
At the Claim Construction hearing, Thought again relied exclusively on JBDC because JBDC is disclosed in the specification and at his deposition Dr. Hosking admitted that JBDC could perform "creating and maintaining" feature. Hosking Supp. Decl. ¶ 15. Dr. Hosking's response in his Supplemental Declaration submitted at the hearing was the same; because there might be different command sequences to do so and because "use of JDBC" indicated in the specification does not disclose how to use the program to perform the "creating and maintaining" function or how JDBC operates to perform the "creating and maintaining," it cannot satisfy the algorithm requirement. Id. ¶¶ 12-15.
Similar to the prior claims, Dr. Hosking does not explain the significance of the fact that programmers could use different sequences of commands to use JBDC to "create and maintain" as contemplated, and he does not otherwise challenge Thought's position that a person skilled in the art readily knows how to perform this function, and could do so using Java, CocoBase or JBDC. Relying on the undisputed fact that use of Java, CocoBase, and JBDC was disclosed in the specification and adequately linked to creating and maintaining data in a second data source having a different structure, I find that the structure of "creating and maintaining" is adequately disclosed.
A sub-routine or sub-module, is not a known structural meaning. Nor is the "for comparing" paired with a sufficient description of its operation. The challenged limitation reads in more detail:
Claim 7, `481 Patent 39:5-14 (emphasis added). This language states the purposes of the comparing and updating but does not, even when read with the remaining claim language and the specification, disclose how the routine or module operates to avoid treatment as a mean-plus-function term. I find, therefore, that this term invokes mean-plus-function claiming.
Thought argues that the "comparing" function refers to a sub-component of an API, which is disclosed as CocoNavigator API in the specification, and that the specification also provides an example of using Java method "equals" to perform the comparison. Jagadish Decl. ¶ 149.
As to the Java equals disclosure, I find Dr. Jagadish's position more persuasive. Dr. Jagadish explains that Dr. Hosking's overstates the complexity of the specific comparison required by the claim — comparing CDOG and CDOG models — and that Java equals can perform that basic comparison without significant modification. Jagadish Resp. Decl. ¶ 129 (distinguishing the situation where "the objects to be compared include external links to other objects, or have type differences" that might require modification or enhancement of Java equals method, to the type of comparison at issue; "we have two database schemas, represented as graphs. It is straightforward to say whether they are equal, and to identify differences between them to the extent they are not, and the Java method equals is adequate to perform this computer operation.").
Thought has totally failed to address what the disclosed structure is for the updating function that is part of the claim language to be construed. The issue was raised by Oracle in its briefs (see Oracle Resp. Br. at 38), but never responded to by Thought in its briefing or by Dr. Jagadish. Because the Java equals method cannot perform the whole of the claimed function (comparing and updating), sufficient structure has not been disclosed and this claim is indefinite.
The "feature" here is likewise not a known structural meaning. Nor does a feature that can edit a CDOG model or definition or representation thereof, even when read with the remaining claim language and the specification, disclose the operation of the feature. It is instead simply a description of the interface's multiple functions. I find, therefore, that this term invokes mean-plus-function claiming.
The parties agree that the function is "providing an interface for editing a CDOG model or for editing a definition or other representation thereof." Thought argues the structure is disclosed in the specification by: (i) identifying the "interface" as "an editing interface for editing the CDOG model, or has an editable input or source, such as a file, that can be modified to implement changes to the complex data object model." `481 Patent 6:37-41; (ii) the specification described a preferred embodiment where this interface is a "point and click graphical user interface" familiar to Java developers and used in the CocoBase product, `481 Patent 6:42-43; and (iii) the `481 specification identifies CocoNavigator API as an interface can allows users to manipulate the CDOG model. `481 Patent 9:10-13; Jagadish Decl. at ¶¶ 152-153. Thought also argues that code, incorporated into the `481 Patent (36:56-62), likewise disclosed the readily known, used, and available NavDemo.java that could be used to build the graphical user interface for editing the CDOG model. Thought Reply at 24; see also Jagadish Resp. Decl. ¶¶ 132-33.
Oracle does not respond specifically to Thought's argument to dispute that the specification's express reference to a graphical user interface, when combined with disclosed use of CocoNavigator API or the NavDemo.java code, would be sufficient structure to disclose the method for the editing at issue. Oracle ignores this argument in its Sur-Reply and Dr. Hosking does not address it. At the Claim Construction hearing Oracle relied on an edited portion of Dr. Jagadish's deposition, where he affirmed that in his declaration he cited to code that would "inform one skilled in the art how to build a graphical user interface to edit a CDOG model," but admitted that the codes does not disclose an "algorithm for this specific function explicitly culled out . . ." Jagadish Depo. at 136:20-137:6. However, Dr. Jagadish's point remains that one skilled in the art could readily use the admittedly disclosed interface solutions and underlying code to implement an interface for editing a CDOG model or definition or representation thereof. See, e.g., Typhoon Touch Techs., Inc. v. Dell, Inc., 659 F.3d 1376, 1385 (Fed. Cir. 2011) ("the patent need only disclose sufficient structure for a person of skill in the field to provide an operative software program for the specified function."). I find that the structure of "an interface for editing" is adequately disclosed.
As above, this feature is not a known structure. Nor does the claim language, even when read in conjunction with the remaining language and the specification, disclose the operation of the feature. The claim language simply describes this interface's multiple functions. I find, therefore, that this term invokes mean-plus-function claiming.
The parties agree that the function is an interface for editing input or source files to implement changes to a CDO or the relationships of a CDOG model. Thought argues that the specification clearly links editable source files as XML, XMI, and UML — which are data source files — to database files, database mapping definition files, and CDOG definition files. `481 Patent 9:16-30. And that a specific example of a CDOG API (which can complete this function) is provided as CocoNavigator API. Id. at 11:7-13:60. Dr. Jagadish explains that "XML, XMI, and UML, are straightforward and numerous commercially available and freeware tools are readily available to edit the content of each type of file and would be readily known to those of skill in the art as of the effective filing date of the `481 patent. The identification of the file types represents a sufficiently definite technique for editing the content in view of the ready availability and ease of use of the editing tools." Jagadish Resp. Decl. ¶ 136.
Oracle responds that the specification never explains how to actually do the XML/XMI/UML editing function, and Dr. Hosking argues that the specification fails to disclose how to provide an interface for the XML/XMI/UML files or how the edits are actually accomplished. Hosking Resp. Decl. ¶ 309. But Dr. Jagadish's point that a person skilled in the art would readily be able to edit and implement changes to those files using the disclosed editing tools stands unrebutted. That the "inner workings" of the readily available editing tools are not disclosed, does not defeat the sufficiency of the disclosure considering that a person skilled in the art is familiar would be familiar with those inner workings and could readily put those tools to use to perform the function at issue. I find that the structure of "interface for an editable input or source" is adequately disclosed.
The claims, therefore, are construed as follows:
I also reject Oracle's indefinite challenges, except for "A computer programming sub-routine or sub-module for comparing . . . and updating" which I find is indefinite for failure to adequately disclose sufficient structure to perform the claimed updating function.
A Case Management Conference will be held at 2:00 p.m. on November 19, 2014 in Courtroom 2. The parties shall file a Joint Case Management Statement on or before November 13, 2014 that proposes a case schedule through trial (jointly if possible, separately if not).
