IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`In the Inter Partes Review of:
`
`U.S. Patent No. RE40,520
`Filed: June 14, 2005
`Issued: September 23, 2008
`Inventor(s): Doktor, Karol
`Assignee: Financial Systems
`Technology (Intellectual Property) Pty.
`Ltd.
`Title: EASILY EXPANDABLE DATA
`PROCESSING SYSTEM AND
`METHOD
`Mail Stop Inter Partes Review
`Commissions for Patents
`P.O. Box 1450
`Alexandria, VA 22313-1450
`
`
`Trial Number: To Be Assigned
`
`
`Attorney Docket No:
`
`
`
`Panel: To Be Assigned
`
`
`
`PETITION FOR INTER PARTES REVIEW UNDER 37 C.F.R. § 42.100
`
`
`
`

`
`
`
`TABLE OF CONTENTS
`
`I.
`
`MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8(a)(1) ............ 1
`
`A.
`
`B.
`
`C.
`
`37 C.F.R. § 42.8(b)(1): Real Party-In-Interest ...................................... 1
`
`37 C.F.R. § 42.8(b)(2): Related Matters ............................................... 1
`
`37 C.F.R. § 42.8(b)(3): Lead and Back-Up Counsel ............................ 1
`
`II.
`
`PAYMENT OF FEES PURSUANT TO 37 C.F.R. § 42.103 ......................... 2
`
`III. GROUNDS FOR STANDING PURSUANT TO 37 C.F.R.
`§ 42.104(a) ....................................................................................................... 2
`
`IV.
`
`IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R.
`§ 42.104(b) ....................................................................................................... 3
`
`A.
`
`B.
`
`C.
`
`D.
`
`E.
`
`37 C.F.R. § 42.104(b)(1): Claims for Which Inter Partes
`Review Is Requested ............................................................................. 3
`
`37 C.F.R. § 42.104(b)(2): The Specific Art and Statutory
`Ground(s) on Which the Challenge Is Based ........................................ 3
`
`37 C.F.R. § 42.104(b)(3): How the Challenged Claim(s) Are to
`Be Construed ......................................................................................... 5
`
`37 C.F.R. § 42.104(b)(4): How the Construed Claim is
`Unpatentable Under the Statutory Grounds Identified ......................... 8
`
`37 C.F.R. § 42.104(b)(5): Evidence Supporting Petitioner’s
`Challenge ............................................................................................... 9
`
`V.
`
`THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST
`ONE OF CLAIMS 10–13 OR 15–16 OF THE ’520 PATENT IS
`UNPATENTABLE .......................................................................................... 9
`
`A. Description of the Alleged Invention of the ’520 Patent ...................... 9
`
`B.
`
`C.
`
`D.
`
`Summary of the Prosecution History of the ’520 Patent .................... 13
`
`Summary of Invalidity Arguments ...................................................... 16
`
`Identification of the References as Prior Art ....................................... 16
`
`i
`
`

`
`
`
`E.
`
`Claim-By-Claim Explanation of Grounds for Unpatentability
`and Claim Charts ................................................................................. 17
`
`James P. Davis, et. al., EDICT – An Enhanced
`Ground 1:
`Relational Data Dictionary: Architecture and Example,
`Invalidates Claims 10–13 and 15–16. ....................................... 17
`
`Ground 2: Stephanie Cammarata, et. al., Extending a
`Relational Database with Deferred Referential Integrity
`Checking and Intelligent Joins, Invalidates Claims 10–13
`and 15–16. ................................................................................. 31
`
`Ground 3: U.S. Patent No. 4,868,733 to Fujisawa, et. al.,
`Invalidates Claims 10–13 and 15–16. ....................................... 44
`
`VI. CONCLUSION .............................................................................................. 58
`
`
`
`
`
`
`ii
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`On behalf of International Business Machines Corporation (“IBM”) and in
`
`accordance with 35 U.S.C. § 311 and 37 C.F.R. § 42.100, inter partes review is
`
`respectfully requested for claims 10–13 and 15–16 of U.S. Patent No. RE40,520
`
`(“the ’520 Patent”), attached hereto as Exhibit 1005.
`
`I. MANDATORY NOTICES PURSUANT TO 37 C.F.R. § 42.8(a)(1)
`Pursuant to 37 C.F.R. § 42.8(a)(1), the mandatory notices identified in 37
`
`C.F.R. § 42.8(b) are provided below as part of this Petition.
`
`37 C.F.R. § 42.8(b)(1): Real Party-In-Interest
`
`A.
`IBM is the real party-in-interest for Petitioner.
`B.
`The ’520 Patent is currently the subject of a patent infringement lawsuit
`
`37 C.F.R. § 42.8(b)(2): Related Matters
`
`brought by the assignee of the ’520 Patent, Financial Systems Technology
`
`(Intellectual Property) Pty. Ltd. (“FST”), and its wholly-owned subsidiary and
`
`exclusive licensee to the ’520 Patent, Financial Systems Technology Pty. Ltd.,
`
`against IBM, captioned Financial Systems Technology (Intellectual Property) Pty.
`
`Ltd. et. al. v. International Business Machines Corp., U.S. District Court for the
`
`Northern District of Illinois, Case No. 1:11-cv-08729 (“FST v. IBM”). This
`
`judicial matter may affect, or be affected by, decisions made in this proceeding.
`
`37 C.F.R. § 42.8(b)(3): Lead and Back-Up Counsel
`
`C.
`IBM provides the following designation of counsel:
`
`
`
`1
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Lead Counsel
`Kenneth R. Adamo (Reg. No. 27299)
`kenneth.adamo@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`Pursuant to 37 C.F.R. § 42.10(b), a Power of Attorney accompanies this
`
`Back-up Counsel
`Joel R. Merkin (Reg. No. 58600)
`joel.merkin@kirkland.com
`Postal and Hand-Delivery Address:
`KIRKLAND & ELLIS LLP
`300 North LaSalle Street
`Chicago, Illinois 60654
`Telephone: (312) 862-2000
`Fax: (312) 862-2200
`
`Petition. Please address all correspondence to lead and back-up counsel at the
`
`address above. IBM also consents to electronic service by email at the email
`
`addresses listed above.
`
`II.
`
`PAYMENT OF FEES PURSUANT TO 37 C.F.R. § 42.103
`
`The undersigned authorizes the Office to charge $27,200 to Deposit Account
`
`No. 220440 for the fee set forth in 37 C.F.R. § 42.15(a) for this Petition for Inter
`
`Partes Review. Six (6) claims are being reviewed, so no excess claim fees are
`
`required. The undersigned further authorizes payment for any additional fees that
`
`might be due in connection with this Petition to be charged to the above-referenced
`
`Deposit Account.
`
`III. GROUNDS FOR STANDING PURSUANT TO 37 C.F.R. § 42.104(A)
`IBM hereby certifies that the ’520 Patent is available for inter partes review
`
`and that IBM is not barred or estopped from requesting inter partes review
`
`challenging the claims of the ’520 Patent on the grounds identified herein.
`
`
`
`2
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Specifically, IBM certifies that (1) IBM is not the owner of the ’520 Patent; (2)
`
`IBM has not filed a civil action challenging the validity of a claim of the ’520
`
`Patent; (3) this Petition is filed less than one year after the date on which IBM or a
`
`privy of IBM was served with a complaint alleging infringement of the ’520
`
`Patent; (4) the estoppel provisions of 35 U.S.C. § 315(e)(1) do not prohibit this
`
`inter partes review; and (5) this Petition is filed after the later of (a) the date that is
`
`nine months after the date of the grant of the ’520 Patent or (b) the date of
`
`termination of any post-grant review of the ’520 Patent.
`
`IV.
`
`IDENTIFICATION OF CHALLENGE PURSUANT TO 37 C.F.R.
`§ 42.104(B)
`
`The precise relief IBM requests is that claims 10–13 and 15–16 of the ’520
`
`Patent are found unpatentable.
`
`A.
`
`37 C.F.R. § 42.104(b)(1): Claims for Which Inter Partes Review Is
`Requested
`IBM requests inter partes review of claims 10–13 and 15–16 of the ’520
`
`Patent.
`
`B.
`
`37 C.F.R. § 42.104(b)(2): The Specific Art and Statutory
`Ground(s) on Which the Challenge Is Based
`Inter partes review of the ’520 Patent is requested in view of the following
`
`references: (1) James P. Davis, et. al., EDICT - An Enhanced Relational Data
`
`Dictionary: Architecture and Example (“Davis”) (Ex. 1006); (2) Stephanie
`
`Cammarata, et. al., Extending a Relational Database with Deferred Referential
`
`
`
`3
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Integrity Checking and Intelligent Joins (“Cammarata”) (Ex. 1007); (3) U.S. Patent
`
`No. 4,868,733 to Fujisawa, et. al. (“Fujisawa”) (Ex. 1008); and (4) U.S. Patent No.
`
`5,206,951 to Khoyi, et. al. (“Khoyi”) (Ex. 1009). The particular reference that
`
`renders each claim of the ’520 Patent unpatentable, and the statutory basis for
`
`finding that the reference renders the claim unpatentable, is as follows:
`
`Claim No.
`10
`10
`10
`11
`11
`11
`12
`
`12
`
`12
`
`13
`13
`13
`15
`15
`15
`
`16
`16
`16
`
`
`
`Proposed Statutory Rejections for the ’520 Patent
`Claim 10 is obvious under 35 U.S.C. § 103(a) by Davis
`Claim 10 is obvious under 35 U.S.C. § 103(a) by Cammarata
`Claim 10 is obvious under 35 U.S.C. § 103(a) by Fujisawa
`Claim 11 is obvious under 35 U.S.C. § 103(a) by Davis
`Claim 11 is obvious under 35 U.S.C. § 103(a) by Cammarata
`Claim 11 is obvious under 35 U.S.C. § 103(a) by Fujisawa
`Claim 12 is obvious under 35 U.S.C. § 103(a) by Davis in view of
`Khoyi
`Claim 12 is obvious under 35 U.S.C. § 103(a) by Cammarata in view of
`Khoyi
`Claim 12 is obvious under 35 U.S.C. § 103(a) by Fujisawa in view of
`Khoyi
`Claim 13 is obvious under 35 U.S.C. § 103(a) by Davis
`Claim 13 is obvious under 35 U.S.C. § 103(a) by Cammarata
`Claim 13 is obvious under 35 U.S.C. § 103(a) by Fujisawa
`Claim 15 is obvious under 35 U.S.C. § 103(a) by Davis
`Claim 15 is obvious under 35 U.S.C. § 103(a) by Cammarata
`Claim 15 is obvious under 35 U.S.C. § 103(a) by Fujisawa in view of
`Davis
`Claim 16 is obvious under 35 U.S.C. § 103(a) by Davis
`Claim 16 is obvious under 35 U.S.C. § 103(a) by Cammarata
`Claim 16 is obvious under 35 U.S.C. § 103(a) by Fujisawa in view of
`Davis
`
`
`
`4
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`C.
`
`37 C.F.R. § 42.104(b)(3): How the Challenged Claim(s) Are to Be
`Construed
`
`An unexpired claim subject to inter partes review “shall be given its
`
`broadest reasonable construction in light of the specification of the patent in which
`
`it appears.” 37 C.F.R. § 42.100(b). However, the ’520 Patent expired on May 21,
`
`2010. Therefore, consistent with MPEP § 2217 regarding the claim construction
`
`standard to be applied when reexamining an expired patent, IBM provides
`
`information about how the claims are to be construed based upon the standard set
`
`forth in Phillips v. AWH Corp., 415 F.3d 1303, 1316 (Fed. Cir. 2005). Evidence
`
`supporting these constructions includes the positions taken by the patent owner,
`
`FST, in its Federal court litigation against IBM.1 35 U.S.C. § 301(a)(2); 37 C.F.R.
`
`§ 1.501. For purposes of this IPR only, IBM is using those constructions proposed
`
`by FST in FST v. IBM.2 Attached as Exhibit 1003 is IBM’s Submission Pursuant
`
`to 35 U.S.C. § 301 and 37 C.F.R. § 1.501 in support of this Petition.
`
`
`1 FST also took a position on the scope of the claims of the ’520 Patent in a prior
`litigation against Oracle Corporation (“Oracle”) in the Eastern District of Texas,
`Case No. 2:08-cv-371, which was settled prior to receiving a claim construction
`decision. (See Ex. 1011, Ex. A.) Under the construction of these claim terms
`proposed by FST in that litigation, which are broader than those presented here,
`the grounds for invalidating claims 10–13 and 15–16 of the ’520 Patent are
`even stronger.
`2 IBM does not agree that these constructions are the proper constructions for the
`district court action.
`
`
`
`5
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Entity Definition Table: In FST v. IBM, FST proposes that this term be
`
`construed to mean “relational database table that defines one or more entity types
`
`and stores one or more entity type records.” (Ex. 1010, Ex A.) Claim 10 of the
`
`’520 Patent states that the “entity definition table contain[s] a first entity type
`
`record defining a first entity type.” (Ex. 1005 at claim 10.)
`
`Entity Type Record: In FST v. IBM, FST proposes that this term be
`
`construed to mean “record in an entity definition table, said record containing, as
`
`two separate attributes, an entity type and a table identifier of an entity instance
`
`table.” (Ex. 1010, Ex A.) The specification states that the entity definition table
`
`(in which the entity type records are stored) stores “the name of an allowed entity
`
`type (class) and the name of a single other table ... where instances of the allowed
`
`entity type may be stored.” (Ex. 1005 at 6:64–7:2.) This is also consistent with
`
`statements FST made during reexamination of the ’520 Patent that the “entity type
`
`record” should include both an “entity type” and an associated “specified entity
`
`instance table.” (Ex. 1025, 6/4/09 Applicant Resp. at 054–055.)
`
`Relation Definition Table: In FST v. IBM, FST proposes that this term be
`
`construed to mean “relational database table that defines one or more relation types
`
`and stores one or more relation type records.” (Ex. 1010, Ex A.) Claim 10 of the
`
`’520 Patent states that the relation definition table contains “a first relation type
`
`record defining a provided relation type.” (Ex. 1005 at claim 10.)
`
`
`
`6
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Relation Type Record: In FST v. IBM, FST proposes that this term be
`
`construed to mean “record in a relation definition table, said record containing, as
`
`two separate attributes, a relation type and a table identifier of a relation instance
`
`table.” (Ex. 1010, Ex A.) The specification illustrates that a row in the Relation
`
`Definition Table (a relation type record) contains at least the name of a relation
`
`type and the name of a table in which instances of that relation type are stored.
`
`(Ex. 1005 at Fig. 6A; see also id. at 7:2–10.)
`
`Entity Instance Table and Entity Instance Record: In FST v. IBM, FST
`
`proposes that “entity instance table” be construed to mean “relational database
`
`table that stores one or more entity instance records,” and “entity instance record”
`
`be construed to mean “record in an entity instance table, said record constituting an
`
`instance of an entity type.” (Ex. 1010, Ex A.) Claim 10 states that the entity
`
`instance table has “a plurality of entity instance records stored in” it. (Ex. 1005 at
`
`claim 10.) Figure 7-2 includes an entity instance table T.Companies, the rows of
`
`which are instances of the entity type Companies. (Id. at Fig. 7–2.)
`
`Relation Instance Table and Relation Instance Record: In FST v. IBM, FST
`
`proposes that “relation instance table” be construed to mean “relational database
`
`table that stores one or more relation instance records.” (Ex. 1010, Ex A.) It
`
`further proposes that “relation instance record” be construed to mean “record in a
`
`relation instance table, said record constituting an instance of a relation type, said
`
`
`
`7
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`instance containing, as two separate attributes, an identifier of a first entity and an
`
`identifier of a second entity, and where said first and second entities are stored in
`
`tables separate from the relation instance table.” (Id.) The specification states that
`
`the relation instance table stores records that define “[r]elationships between
`
`instances of a primary entity and a secondary entity.” (Ex. 1005 at 7:19–21; see
`
`also id. at 7:10–17 (“Each row of the Relation-instances Table (RiT) is provided
`
`with at least one primary pointer which points to the storage location of a first
`
`instance of the primary entity type and at least one secondary pointer which points
`
`to the storage location of a corresponding first instance of the secondary entity
`
`type.”).)
`
`Other Claim Terms: To the extent construction of any of these terms is
`
`necessary for this Petition, FST has also proposed that:
`
`• an “entity” is “anything about which information can be stored in a database
`
`record.” (Ex. 1010, Ex A.)
`
`• a “relation” is “a logical link between entities.” (Id.)
`
`• a “record” is “a set of data stored in a single row of a table.” (Id.)
`
`D.
`
`37 C.F.R. § 42.104(b)(4): How the Construed Claim is
`Unpatentable Under the Statutory Grounds Identified
`
`A detailed explanation of how construed claims 10–13 and 15–16 of the
`
`’520 Patent are unpatentable, including the identification of where each element of
`
`the claim is found in the prior art relied upon, is provided below in Section V.
`
`
`
`8
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Claim charts comparing the challenged claims of the ’520 Patent to the prior art
`
`may be found in Section V.E.
`
`E.
`
`37 C.F.R. § 42.104(b)(5): Evidence Supporting Petitioner’s
`Challenge
`
`An Appendix of Exhibits identifying all exhibits supporting this Petition,
`
`and assigning them exhibit numbers, is attached. Additionally, the relevance of the
`
`evidence to the challenge raised, including identifying specific portions of the
`
`evidence that support the challenge, may be found in Section V, below. Finally,
`
`IBM submits a declaration of Dr. Stanley B. Zdonik in support of this Petition in
`
`accordance with 37 C.F.R. § 1.68. (Ex. 1001.)
`
`V. THERE IS A REASONABLE LIKELIHOOD THAT AT LEAST ONE
`OF CLAIMS 10–13 OR 15–16 OF THE ’520 PATENT IS
`UNPATENTABLE
`A. Description of the Alleged Invention of the ’520 Patent
`The ’520 Patent describes a relational database framework where the
`
`relationships between different Entity Types (e.g., “Customer,” “Address,”
`
`“Account”) are defined by Relation Types (“’s business,” “’s owner,” “’s statement
`
`mailing”). This framework uses certain defined tables, including an Entity
`
`Definition Table, Relation Definition Table, Entity Instance Tables and Relation
`
`Instance Tables. (Ex. 1005 at claim 10; see also id. at Figs. 5 and 6A.) The ’520
`
`Patent explains that in prior art systems, “implied” relations between entities could
`
`not be discerned by simply inspecting data in a table, because the relationship
`
`
`
`9
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`could be one of an infinite set of possibilities. (Id. at 5:46–56.) In contrast, the
`
`invention of the ’520 Patent makes the relations between entities “explicit.” (Id. at
`
`27:50–52.)
`
`Claim 10 of the ’520 Patent, the only independent claim at issue in this
`
`Petition, recites a relational database processing system that has the following
`
`elements:
`
`[a] an entity definition table containing a first entity type
`record defining a first entity type;
`
`[b] a first entity instance table associated with said first
`entity type;
`
`[c] a plurality of entity instance records stored in said
`first entity instance table;
`
`[d] a relation definition table containing a first relation
`type record defining a provided relation type;
`
`[e] a first relation instance table associated with said
`provided relation type; and
`
`[f] a first relation instance record of said provided
`relation type, said first relation instance record relating a
`desired entity in one of said entity instance records to a
`provided entity.
`
`Elements [a] and [d] refer to the “definition” tables of the invention, which
`
`are illustrated in Figures 5 (Entity Definition (ENT.DEF) Table ) and 6A (Relation
`
`Definition (REL.DEF) Table) of the ’520 Patent:
`
`
`
`10
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Entity Definition Table
`
`Entity Type Record
`
`Entity Type Name
`Entity Instance
`Table Name
`
`Relation Definition Table
`Relation Type Record Relation Type Name
`Relation Instance
`Table Name
`
`
`
`
`
`The Entity Definition Table contains Entity Type Records, which define an Entity
`
`Type. The Relation Definition Table contains Relation Type Records that define a
`
`Relation Type.
`
`Elements [b] and [e] refer to the “instance” tables of the invention, which are
`
`illustrated in Figures 7-2 (Entity Instance (ENT.INT or T.[name of entity]) Tables)
`
`and 7-1 (Relation Instance (REL.INT or T.-REL) Table) of the ’520 Patent:
`
`
`
`11
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Entity Instance Tables
`
`Relation Instance Table
`
`
`
`
`
`
`
`An Entity Instance Table contains records of entity instances. Figure 7-2
`
`shows two Entity Instance Tables: T.Companies and T. Addresses. A row in each
`
`Entity Instance Table is an instance of an entity. A Relation Instance Table
`
`contains records that explicitly define relationships between instances of a primary
`
`entity (i.e., Head Entity Instance (“Ei”)) and secondary entity (i.e., Tail Ei).
`
`These tables are used to process retrieval requests from a database. One
`
`example, using the figures above, would be to retrieve the name of company(s) for
`
`whom “555 Transistor Lane” is a “Business Address.” First, the Relation
`
`Definition Table is searched to identify the Relation Type Record that corresponds
`
`to Business Address: the “’s Business” Relation Type. The Relation Instance
`
`Table for Relation Type “’s Business” is then searched to find the Relation
`
`Instance Records that match “555 Transistor Lane.” The Relation Instance
`
`
`
`12
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Records that match “555 Transistor Lane” each point to an Entity Instance Record
`
`of the “Customer” Entity Type. The “Customer” Entity Instance Table is then
`
`searched to locate the Entity Instance Records that correspond to the retrieved
`
`Relation Instance Records. The located Entity Instance Records are then provided
`
`as the final results of the retrieval request: in this example, “Expert Electronics.”
`
`Summary of the Prosecution History of the ’520 Patent
`
`B.
`FST filed U.S. Patent Appl. No. 08/862,176 (“the ’176 Application”) on
`
`May 22, 1997. (Ex. 1012.) The ’176 Application claimed priority to U.S. Patent
`
`Appl. No. 07/526,424, filed on May 21, 1990. (Id.) The originally filed claims of
`
`the ’176 Application were allowed without any rejections by the Examiner, who
`
`stated that the prior art of record did not disclose “retrieving a specific relation
`
`instance record defining a relation of said provided relation type between said
`
`provided entity and said desired entity from a relation instance table” and
`
`“retrieving a desired entity type record containing said desired entity type from an
`
`entity definition table.” (See Ex. 1013, 3/5/98 Notice of Allowability, at 003, ¶ 1.)
`
`Those elements only appear in independent method claim 1, however, not in
`
`independent system claim 10 of the ’520 Patent. Thus the Examiner’s statement
`
`does not provide a basis for allowing claims 10–13 and 15–16 of the ’520 Patent at
`
`issue in this Petition. The ’176 Application issued as U.S. Patent No. 5,826,259
`
`(“the ’259 Patent”) on October 20, 1998. (Ex. 1014.)
`
`
`
`13
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`On June 14, 2005, FST filed U.S. Reissue Appl. No. 11/152,835 (“the ’835
`
`Reissue Application”), an application for reissue of the ’259 Patent due to a
`
`defective specification. (Ex. 1015.) Oracle filed Reexamination Request No.
`
`90/007,707 (“the ’707 Reexamination”), a third party request for ex parte
`
`reexamination of the ’259 Patent, on September 1, 2005. (Ex. 1016.) The ’707
`
`Reexamination request was granted, and the ’835 Reissue Application and ’707
`
`Reexamination were merged on December 5, 2005. (Ex. 1017; Ex. 1018.) The
`
`’259 Patent reissued as the ’520 Patent on September 23, 2008. (Ex. 1005.)
`
`During the ’707 Reexamination, the Examiner found that the Tsichritzis and
`
`Munz references submitted with the request raised a substantial new question of
`
`patentability. To distinguish the claims of the ’520 Patent over Tsichritzis and
`
`Munz, FST argued that the references did not disclose tables that can be
`
`dynamically changed by modifying the Entity Definition Table and Relation
`
`Definition Table, without needing to make any changes to, or recompile, the
`
`application software. (See Ex. 1019, 6/1/06 Interview Summary.) While the
`
`Examiner appreciated these distinctions, the Examiner pointed out that such
`
`distinctions were not reflected in the claims. (See id.) Ultimately, the Examiner
`
`allowed the claims over the closest prior art of record, Munz, after finding that
`
`Munz was very similar to the claimed invention, but would not qualify as a
`
`“relational database.” (See Ex. 1020, 2/20/08 Notice of Allowability at 009, ¶ 10.)
`
`
`
`14
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Oracle filed a second request for ex parte reexamination of the ’259 Patent
`
`on May 9, 2007, Reexamination Request No. 90/008,648
`
`(“the
`
`’648
`
`Reexamination”), which was given a filing date of June 11, 2007. (Ex. 1021; Ex.
`
`1031.) This request was granted on July 19, 2007, and a reexamination certificate
`
`issued on January 5, 2010. (Ex. 1022; Ex. 1027.) In the ’648 Reexamination, FST
`
`again attempted to distinguish the claims of the ’520 Patent over the prior art of
`
`record by arguing that the entity and relation definitions of the prior art systems are
`
`static and cannot be changed without reprogramming at the source or assembly
`
`level, whereas the claims of the ’520 Patent all require tables of an active relational
`
`database. (See Ex. 1023, 2/11/09 Amendment at 016.) Once again, the Examiner
`
`rejected these distinctions as not being claimed. (See Ex. 1024, 3/5/09 Office
`
`Action at 015.) FST repeated its argument, submitting an expert declaration
`
`stating that the Entity Definition and Relation Definition Tables must be construed
`
`as dynamically expandable, which the Examiner accepted as distinguishing one of
`
`the prior art references. (See Ex. 1026, 9/18/09 Notice of Intent to Issue a
`
`Reexamination Certificate at 004–005.) In allowing the claims, the Examiner
`
`stated that the prior of record did “not explicitly teach a relational database
`
`processing system comprising an entity definition table containing a first entity
`
`type record defining a first entity type, a first entity instance table associated with
`
`said first entity type, and a relation definition table containing a first relation type
`
`
`
`15
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`record defining a provided relation type, in combination with the remaining
`
`elements or features of the claimed invention.” (See id. at 006–007.)
`
`Summary of Invalidity Arguments
`
`C.
`The Davis, Cammarata and Fujisawa prior art references submitted and
`
`discussed herein were not of record in the file of the ’520 Patent. IBM respectfully
`
`submits that these references are more relevant than the prior art previously
`
`considered by the Patent Office, and invalidate claims 10–13 and 15–16 of the
`
`’520 Patent under 35 U.S.C. § 103.
`
`Davis discloses a relational database having an Entity Definition Table,
`
`Relation Definition Table, Entity Instance Tables, and Relation Instance Tables
`
`that are almost exactly the same as those described and claimed in claims 10–13
`
`and 15–16 of the ’520 Patent. The only difference, a trivial one, is that Davis
`
`identifies type names and table names in the same attribute, as opposed to separate
`
`attributes.
`
`Cammarata and Fujisawa also disclose relational databases having tables
`
`with extensive similarities to those described and claimed in the ’520 Patent.
`
`These references render the claims obvious to one of ordinary skill in the art.
`
`Identification of the References as Prior Art
`
`D.
`Inter partes review of the ’520 Patent is requested in view of the following
`
`references, which are prior art for the following reasons:
`
`
`
`16
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`• James P. Davis, et. al., EDICT - An Enhanced Relational Data Dictionary:
`Architecture and Example (“Davis”). Davis was published in February 1988,
`and is thus prior art under 35 U.S.C. § 102(b). (Ex. 1006.)
`• Stephanie Cammarata, et. al., Extending a Relational Database with Deferred
`Referential Integrity Checking and Intelligent Joins (“Cammarata”).
`Cammarata was published in June 1989, and is thus prior art under 35 U.S.C.
`§ 102(a). (Ex. 1007.)
`• U.S. Patent No. 4,868,733 to Fujisawa, et. al. (“Fujisawa”). Fujisawa was filed
`on March 26, 1986, and is thus prior art under 35 U.S.C. § 102(e). (Ex. 1008.)
`• U.S. Patent No. 5,206,951 to Khoyi, et. al. (“Khoyi”). Khoyi is a continuation
`of U.S. Patent Appl. No. 88,622, filed August 21, 1987, and is thus prior art
`under 35 U.S.C. § 102(e). (Ex. 1009.)
`E. Claim-By-Claim Explanation of Grounds for Unpatentability and
`Claim Charts
`
`Claims 10–13 and 15–16 are unpatentable based on the Grounds described
`
`below.
`
`Ground 1: James P. Davis, et. al., EDICT – An Enhanced Relational Data
`Dictionary: Architecture and Example, Invalidates Claims 10–13 and 15–16.
`
`Davis is a printed publication that describes EDICT, “a multilayered
`
`architecture for facilitating the development and management of information in a
`
`relational DBMS [database management system].” (Ex. 1006 at 185.) EDICT
`
`defines enhancements to existing relational data dictionaries “through the
`
`definition of additional schemata which are integrated into the dictionary proper.”
`
`
`
`17
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`(Id. at 186.) The schemata, called the enterprise schema, “exists as data in the
`
`enterprise meta-schema tables of the supporting relational DBMS.” (Id.)
`
`Davis discloses an “ENTITY_SETS” table that stores records, each record
`
`having two attributes: “eset_name” and “eset_type.” (Id. at 189.) The first record
`
`in the “ENTITY_SETS” table contains an “eset_name” of “suppliers” with an
`
`“eset_type” of “regular entity set.” (Id.)
`
`
`The second and third records depicted in the “ENTITY_SETS” table similarly
`
`define “items” and “members” as “regular entity set[s].” (Id.) The value in the
`
`“eset_name” column of each record also identifies the name of a table that stores
`
`records of the entity set; for example, the first record depicted in the
`
`“ENTITY_SETS” table is given the name of “suppliers.” Specific instances of the
`
`“suppliers” set can be found in the “SUPPLIERS” table, described below.
`
`A separate “SUPPLIERS” table contains multiple records. (Id. at 188.)
`
`Each record in the “SUPPLIERS” table identifies a supplier name and
`
`corresponding supplier address. (Id.)
`
`
`
`18
`
`
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`Similarly, there are separate “ITEMS” and “MEMBERS” tables, each containing
`
`multiple records. (Id.) Each record in the “ITEMS” table identifies an item name,
`
`while each record in the “MEMBERS” table identifies multiple attributes,
`
`including member name, address, balance and spouse name. (Id.)
`
`The schema also stores “relationships and behavior of data in the
`
`enterprise.” (Id. at 185.) The “BINARY_RELATIONSHIP” table stores such
`
`relationships. (Id. at 189.) Each record in the “BINARY_RELATIONSHIP” table
`
`has a relationship name (“rset_name”). (Id.)
`
`
`The value in the “rset_name” column of each record also identifies the name of a
`
`table that stores records of the relationship set; for example, the first record
`
`depicted in the “BINARY_RELATIONSHIP” table is given the name of “deliver.”
`
`The “deliver” record defines a relationship between the entity set “suppliers” and
`
`the entity set “items.” (Id.) Specific relationships between “suppliers” and “items”
`
`can be found in the “DELIVER” table, described below.
`
`A separate “DELIVER” table contains multiple relationship records. Each
`
`record in the “DELIVER” table relates an instance of the entity set suppliers
`
`(column: “sname”) with an instance of the entity set items (column: “iname”), as
`
`
`
`19
`
`

`
`Petition for Inter Partes Review of U.S. Patent No. RE40,520
`
`defined in the “deliver” record in the “BINARY_RELATIONSHIP” table. (Id. at
`
`188.)
`
`
`
`For example, the first record shown in the “DELIVER” table relates supplier
`
`“Sunshine Produce” with item “granola.” (Id.) Davis explains that the “sname”
`
`and “iname” attributes in the “DELIVER” table are keys. The details of each
`
`entity identified under “sname” or “iname” columns are stored in “SUPPLIERS”
`
`and “ITEMS” tables, respectively. (Id.)
`
`Davis discloses a single architecture “facilitating the development and
`
`management of