Case No. 83145 REX2
`
`COMMISSIONER FOR PATENTS
`
`P.O. BOX 1450
`
`ALEXANDRIA, VA 22313-1450
`
`in re Reexamination
`Application of:
`
`DOKTOR, US. Patent 5,826,259
`(Now RE40,520)
`
`Control No.:
`
`90/008,648
`
`Filed:
`
`For:
`
`Sir:
`
`June 11, 2007
`
`EASILY EXPANDABLE DATA PROCESSING SYSTEMS AND METHOD
`
`Transmitted herewith is an amendment in the above—identified application.
`
`[X]
`
`[X]
`
`[X]
`
`No additional fee is required.
`
`The Commissioner is hereby authorized to charge or credit any discrepancies in fee
`amounts to Deposit Account No. 01-0484.
`
`PLEASE ADDRESS ALL CORRESPONDENCE TO ATTORNEY OF RECORD:
`CHRIS I OFFIER F. REGAN
`
`[X]
`
`Please associate this application with Customer No. 27975.
`
`February 11, 2009
`DATE
`
` Umlmfix
`
`
`
`HN F. V\-/OODSON, ll
`G. NO. 45,236
`
`IBM EX. 1023
`
`001
`
`001
`
`
`
`COMMISSIONER FOR PATENTS
`
`P.O. BOX 1450
`
`ALEXANDRIA, VA 22313-1450
`
`in re Reexamination
`Application of:
`
`DOKTOR, US. Patent 5,826,259
`(Now RE40,520)
`
`Control No.:
`
`90/008,648
`
`Filed:
`
`For:
`
`Sir:
`
`June 11, 2007
`
`EASILY EXPANDABLE DATA PROCESSING SYSTEMS AND METHOD
`
`Transmitted herewith is an amendment in the above—identified application.
`
`[X]
`
`[X]
`
`[X]
`
`No additional fee is required.
`
`The Commissioner is hereby authorized to charge or credit any discrepancies in fee
`amounts to Deposit Account No. 01-0484.
`
`PLEASE ADDRESS ALL CORRESPONDENCE TO ATTORNEY OF RECORD:
`CHRIS I OFFIER F. REGAN
`
`[X]
`
`Please associate this application with Customer No. 27975.
`
`February 11, 2009
`DATE
`
` Umlmfix
`
`
`
`HN F. V\-/OODSON, ll
`G. NO. 45,236
`
`IBM EX. 1023
`
`001
`
`001
`
`
`
`IN THE UNITED STATES PATENT AND TRADEMARK OFFICE
`
`ATTY DOCKET NO.
`
`83145_3EX2
`
`) ) ) ) ) ) ) ) >
`
`) )
`
`Reexamination of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259“
`
`(Now RE40,520)
`
`Control No. 90/008,648
`
`Filing Date:
`
`JUNE 11, 2007
`
`For: EASILY EXPANDABLE DATA PROCESSING
`
`SYSTEM AND MTHOD
`
`RESPONSE TO OFFICE ACTION
`
`Commissioner for Patents
`
`P.O. Box 1450
`
`Alexandria, VA 22313-1450
`
`Sir:
`
`This is in response to the Examiner's Non—Final Office
`
`Action dated December 12, 2008.
`
`002
`
`002
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`In the Claims:
`
`1.
`
`(Original) A method for retrieving a desired entity
`
`of a desired entity type from a relational database, wherein said
`
`desired entity is related to a provided entity by a provided
`
`relation type associating an entity type of said provided entity
`
`with said desired entity type, said method comprising:
`
`retrieving a specific relation type record defining
`
`said provided relation type from a relation definition table;
`
`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
`
`corresponding to said specific relation type record;
`
`retrieving a desired entity type record containing said
`
`desired entity type from an entity definition table, wherein said
`
`desired entity type record specifies a desired entity instance
`
`table associated with said desired entity type; and
`
`retrieving said desired entity from said desired entity
`
`instance table.
`
`2.
`
`(Original) The method of claim 1, wherein said
`
`relation instance record specifies said desired entity by said
`
`desired entity type and a desired record identifier.
`
`003
`
`003
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`3.
`
`(Original) The method of claim 2, wherein said
`
`desired entity is identified by said desired record identifier in
`
`said desired entity instance table.
`
`4.
`
`(Original) The method of claim 1, wherein said
`
`retrieving a specific relation instance record comprises:
`
`retrieving a table identifier for said relation
`
`instance table from said specific relation type record; and
`
`retrieving said specific relation instance record from
`
`said relation instance table based on said specific relation type
`
`record and said provided entity.
`
`5.
`
`(Original) The method of claim 1, further comprising
`
`retrieving data specifying said provided relation type from an
`
`inquiry table.
`
`6.
`
`(Original) The method of claim 1, further comprising
`
`retrieving data specifying said provided entity from an inquiry
`
`table.
`
`7.
`
`(Original) The method of claim 1, further comprising
`
`retrieving a second desired entity type record containing a
`
`second desired entity type from said entity definition table,
`
`
`
`wherein said second desired entity type record specifies a second
`
`desired entity instance table associated with said second desired
`
`entity type.
`
`004
`
`004
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`8.
`
`(Original) The method of claim 7, further comprising
`
`retrieving a third desired entity type record containing a third
`
`desired entity type from said entity definition table, wherein
`
`said third desired entity type record specifies a third desired
`
`entity instance table associated with said third desired entity
`
`type.
`
`9.
`
`(Original) The method of claim 1, further comprising
`
`retrieving a second specific relation instance record defining a
`
`relation of a second provided relation type between said provided
`
`entity and said desired entity from a second relation instance
`
`table corresponding to said second provided specific relation
`
`type.
`
`10.
`
`(Original) 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;
`
`a plurality of entity instance records stored in said
`
`first entity instance table;
`
`a relation definition table containing a first relation
`
`type record defining a provided relation type;
`
`005
`
`005
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`a first relation instance table associated with said
`
`provided relation type; and
`
`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.
`
`11.
`
`(Original) The relational database processing
`
`system of claim 10, wherein each of said entity instance records
`
`is identified by a record identifier.
`
`l2.
`
`(Original) The relational database processing
`
`system of claim l0, wherein said first relation instance record
`
`contains a desired record identifier and a desired entity type
`
`corresponding to a desired entity instance record containing said
`
`desired entity.
`
`13.
`
`(Original) The relational database processing
`
`system of claim 10, wherein said first relation type record
`
`comprises a table identifier identifying said first relation
`
`instance table.
`
`14.
`
`(Original) The relational database processing
`
`system of claim 10, further comprising an inquiry table
`
`containing an inquiry record, wherein said inquiry record
`
`specifies said provided relation type and said provided entity.
`
`006
`
`006
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`15.
`
`(Original) The relational database processing
`
`system of claim 10 further comprising:
`
`a second entity instance table associated with a second
`
`entity type; and
`
`wherein said entity definition table contains a second
`
`entity type record containing said second entity type and
`
`associating said second entity instance table with said second
`
`entity type.
`
`l6.
`
`(Original) The relational database processing
`
`system of claim 15 further comprising:
`
`a third entity instance table associated with a third
`
`entity type; and
`
`wherein said entity definition table contains a third
`
`entity type record containing said third entity type and
`
`associating said third entity instance table with said third
`
`entity type.
`
`17.
`
`(Original) The relational database processing
`
`system of claim 10 further comprising:
`
`a second relation instance table associated with a
`
`second relation type; and
`
`wherein said relation definition table contains a
`
`second relation type record containing said second relation type
`
`007
`
`007
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`and associating said second relation instance table with said
`
`second relation type.
`
`18.
`
`(Original) The relational database processing
`
`system of claim 17 further comprising:
`
`a third relation instance table associated with a third
`
`relation type; and
`
`wherein said relation definition table contains a third
`
`relation type record containing said third relation type and
`
`associating said third relation instance table with said third
`
`relation type.
`
`008
`
`008
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`REMARKS
`
`Claims 1-18 remain in the application. Claims 1-18
`
`stand rejected.
`
`In View of the arguments presented in detail
`
`below, it is submitted that all of the claims are patentable.
`
`I. Patent Owner's Statement of the Interview
`
`Patent Owner wishes to thank Examiners Kosowski,
`
`Keasel, and Ferris for the courtesies extended to the undersigned
`
`attorney during the personal interview on February 3, 2009.
`
`Initially,
`
`the amendments entered in the prior merged
`
`reissue/reexamination proceeding for the ‘259 patent (Serial No.
`
`11/152,835; Control No. 90/007,707) and reflected in the
`
`resulting RE40,52O patent were discussed. As helpfully clarified
`
`by Examiner Kosowski
`
`in the Ex Parte Reexamination Interview
`
`Summary mailed February 3, 2009,
`
`the amendments made to the
`
`specification and claims in the RE40,52O patent are effective and
`
`of record in the present reexamination. Accordingly, reference
`
`herein to the specification and drawings will be to the
`
`specification and drawings as set forth in the RE40,52O patent.
`
`With regard to the substantive rejections of the claims
`
`based upon Teorey, Huber, and Kumpati,
`
`the undersigned attorney
`
`argued that these references,
`
`taken individually or in
`
`combination, fail to properly provide all of the recitations of
`
`independent Claims 1 and 10 and,
`
`thus, of their respective
`
`dependent claims as well. More particularly, it was argued that
`
`these references, at a minimum, fail to properly provide the
`
`009
`
`009
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`claimed relation definition, relation instance, and entity
`
`definition tables within a relational database and the associated
`
`interrelation therebetween, and that favorable action is
`
`therefore warranted. These arguments are set forth in greater
`
`detail below.
`
`II. Summary of the Claimed Subject Matter
`
`The present invention is directed to relational
`
`database systems and related relational database retrieval
`
`methods. Referring to the example provided in FIGS. 5-7 of the
`
`RE40,52O patent,
`
`independent Claim.1 recites a method for
`
`retrieving a desired entity of a desired entity type (see, e.g.,
`
`entity instance tables 710, 720 in FIG. 7-2)
`
`from a relational
`
`database. The desired entity is related to a provided entity by a
`
`provided relation type (see, e.g., REQUEST in FIG. 7~l)
`
`associating an entity type of the provided entity with the
`
`desired entity type.
`
`The method includes retrieving a specific relation type
`
`record defining the provided relation type from a relation
`
`definition table (see, e.g., REL.DEF in FIGS. 6A, 6B, and 7~l),
`
`and retrieving a specific relation instance record defining a
`
`relation of the provided relation type between the provided
`
`entity and the desired entity from a relation instance table
`
`(see, e.g., RiT 730 (T.REL—l)
`
`in FIG. 7-1) corresponding to the
`
`specific relation type record. The method further includes
`
`retrieving a desired entity type record containing the desired
`
`010
`
`010
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`entity type from an entity definition table (see, e.g., ENT.DEF
`
`500.1, 500.2 in FIG. 7—l and FIG. 5), wherein the desired entity ‘
`
`type record specifies a desired entity instance table (again,
`
`see, e.g., entity instance tables 710, 720 in FIG. 7~2)
`
`associated with the desired entity type, and retrieving the
`
`desired entity from the desired entity instance table. FIGS.
`
`7—l
`
`and 7-2 are reproduced together below for convenience of
`
`reference.
`
`lO
`
`011
`
`011
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`-E'n1ity-
`g
`I
`n
`
`~RaIaliun.- Level
`.
`d
`-
`
`
`
`
`
`
`
`7‘!-752
`2.rr.2= y'»
`
`flmmfifi :_.._.._.....-_....—-———.____.___._..—-...-__..........—'n
`
`FIG.
`
`'/'--2
`
`012
`
`
`,9? *3,€§¥F!'?‘2F§
`»$chema
`
`Exwatving ‘
`the mlalinnshxpz
`.gu.
`mm
`,Lm&1 i
`
`
`Hegd
`Rel Tanfli}
`enfi Bm_j
`
`
`
`
`
`v
`
`012
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`Independent Claim 10 is directed to a related
`
`relational database processing system, which includes an entity
`
`definition table (see, e.g., ENT.DEF 500.1, 500.2 in FIG. 7~l and
`
`FIG. 5) containing a first entity type record defining a first
`
`entity type, a first entity instance table (see, e.g., entity
`
`instance tables 710, 720 in FIG. 7~2) associated with the first
`
`entity type, and a plurality of entity instance records stored in
`
`the first entity instance table. Moreover, a relation definition
`
`table (see, e.g., REL.DEF in FIGS. 6A, 6B, and 7—l) contains a
`
`first relation type record defining a provided relation type, and
`
`a first relation instance table (see, e.g., RiT 730 (T.REL—l)
`
`in
`
`FIG. 7-1)
`
`is associated with the provided relation type. The
`
`system further includes a first relation instance record of the
`
`provided relation type, and the first relation instance record
`
`relates a desired entity in one of the entity instance records to
`
`a provided entity (see, e.g., REQUEST in FIG. 7~l).
`
`III. Procedural Background
`
`By way of background, U.S. Patent No. 5,826,259 (the
`
`'259 patent) has been involved in the following litigations:
`
`(a)
`
`Oracle Corporation v. QPSX, Ltd. et al.
`
`in the United States
`
`District Court for the Northern District of California, Case No.
`
`3:O4cv5ll6 (the “California Litigation”) and (b) Financial
`
`Systems Technology (Intellectual Property) Pty.Ltd et al. v.
`
`Oracle Corporation, filed October 12, 2004,
`
`in the U.S. District
`
`12
`
`013
`
`013
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`Court for the Eastern District of Texas, Case No. 2:04cv358 (the
`
`"Texas Litigation"). The California Litigation was dismissed
`
`without prejudice pursuant to a Stipulated Motion for Dismissal
`
`dated February 25, 2005, and the Texas Litigation was dismissed
`
`without prejudice pursuant to an Order Granting Joint Motion to
`
`Dismiss Without Prejudice dated July 25, 2005.1
`
`Patent Owner filed a reissue application of the ‘259
`
`patent on June 14, 2005, which was assigned Serial No.
`
`ll/152,835,
`
`to correct certain errors in the priority information
`
`listed on the face of the ‘259 patent. Oracle Corp. filed a first
`
`Request for Ex Parte Reexamination on September 1, 2005 for the
`
`‘259 patent, which was assigned Reexamination No. 90/007,707, and
`
`which was granted on September 30, 2005 and merged with the
`
`above—noted reissue (the “merged proceeding”). A Notice of
`
`Allowance was mailed in the merged proceeding on February 20,
`
`2008, and Applicant paid the issue fee for the reissue
`
`application on March 6, 2008.
`
`Oracle Corp. filed a second request for reexamination
`
`of the ‘259 patent on June ll, 2007, which resulted in the
`
`present Reexamination No. 90/008,648. The art presented by the
`
`second reexamination request had been considered by the Examiner
`
`(except for the entirety of a book in German,
`
`translated portions
`
`of which were considered)
`
`in the merged proceeding. The claims in
`
`1 The analysis herein is based upon giving the claims their appropriate scope, as reflected in the Preliminary
`Infringement Contentions filed by Patent Owner, which Oracle Corp. attached to its Request for Ex Parte
`Reexamination as Exhibit PAT—A2. In the Preliminary Infringement Contentions, the ‘259 claims are read on
`Oracle’s relational database system, and the analysis set forth herein is consistent with the Preliminary Infringement
`Contentions.
`
`l3
`
`014
`
`014
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`the merged reissue/reexamination have now been allowed over that
`prior art. The merged reissue/reexamination claims have been
`
`entered in the present reexamination, as noted above.
`
`The prior art forming the basis for the finding of a
`
`substantial new question of patentability in the present
`
`reexamination was the Teorey Computer Surveys article (1986) and
`
`U.S. Patent No. 4,774,661 to Huber, which the Examiner noted were
`
`not considered in the original prosecution of the '259 patent.
`
`That is,
`
`this determination was based upon the '259 patent as
`
`originally issued, and did not take into account the merged
`
`proceeding, or that the Teorey and Huber references were already
`
`of record and fully considered in the merged proceeding.
`
`IV. Arguments
`
`A. Introduction
`
`As discussed in the Background of the RE40,52O patent
`
`at col. 6,
`
`lines 26-28, prior art relational database systems
`
`tended to suffer from expandability and restructuring problems.
`
`The Kumpati patent cited by the Examiner speaks to this
`
`difficulty at col. 1,
`
`line 59 through col. 2,
`
`line 11, which is
`
`reproduced below:
`
`“Each database management system has its own
`architecture which relates to the physical
`
`structure and organization of the memory devices
`
`which are controlled by the database management
`
`system. The architecture also defines the logical
`
`14
`
`015
`
`015
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`interconnection and interrelation of the various
`
`record segments and schemas
`files, records,
`within the common database. This architecture is
`defined at the time the database is created and
`
`is reflected in an entity contained in each
`
`database management system called the data
`dictionary.
`
`The data dictionary is a software structure
`that contains a list of all the application
`
`program databases contained in the common
`database and their associated schemas. The data
`
`dictionary also contains a definition of each
`schema and the various types of data elements
`
`which are stored in memory along with data
`
`security information. The difficulty with
`existing data dictionaries is that they are
`static and cannot be changed except by the
`
`database administrator, who must recompile the
`
`database system and the data dictionary with each
`change that is made to these elements.” (Emphasis
`added).
`
`Accordingly, with such a static data dictionary, high-
`
`level relationship and entity definitions are defined by a
`
`database designer or administrator and compiled into a fixed
`
`object code program which cannot be updated or restructured
`
`without reprogramming at the source or object code level. That
`
`is,
`
`these entity and relationship definitions of the prior art
`
`are essentially “set in stone” once the database is compiled, and
`
`can only be changed through subsequent reprogramming and
`
`recompilation of the database. See, e.g., col. 6,
`
`lines 45-55 and
`
`col. 7,
`
`line 25-28 of the RE40,52O patent.
`
`l5
`
`016
`
`016
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`As will be discussed in greater detail below, all of
`
`the prior art references relied upon by the Examiner employ a
`
`static data dictionary type of configuration in the active
`
`database for storing high~level definition and instance
`
`information, which would again require reprogramming at the
`
`source or assembly level for restructuring thereof.
`
`In stark
`
`contrast,
`
`the present claims all recite relational database
`
`retrieval methods and relational database processing systems in
`
`which relation definition type, entity definition type, and
`
`relation instance type records are stored in tables of the active
`
`relational database. See, e.g., col. 22,
`
`lines 21-39 and col. 27,
`
`line 65 through col. 28,
`
`line 15, of the RE40,52O patent, which
`
`are reproduced below for convenience of reference.
`
`“The REL.DEF table 600 can be updated
`
`indefinitely by adding new rows to its bottom so
`
`as to encompass a great number of further
`relation classes. There is no need to physically
`order the data describing each of the relational
`classes and thus descriptions of new classes can
`be added to the bottom or other empty slots of
`the REL.DEF table 600 sporadically as the need
`arises over time. Relation classes which become
`
`obsolete can be deleted to leave behind an empty
`
`slot. Similarly,
`there is no need to order the
`entity classes defined by the ENT.DEF table 500.
`
`The ENT.DEF table can be updated by arbitrarily
`
`adding new entity class describing rows to its
`
`bottom or other empty slots or by deleting
`obsolete entries as the need arises. Accordingly,
`
`when demands on the database system of the
`
`invention change over time, new relation classes
`
`l6
`
`017
`
`017
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`may be defined in combination with new head and
`tail entity classes. The schema of the invention‘
`can be continuously restructured as the need
`
`arises simply by updating the REL.DEF and ENT.DEF
`tables, 600 and 500.” RE40,520, col. 22,
`lines
`21-39.
`
`“Since the REL.DEF and ENT.DEF tables may be
`
`expanded as desired by adding new entries to
`empty middle or bottom slots found within them, a
`lay user can create new entities, new relation
`classes and restructure the schema of explicitly-
`
`defined relationships and entities forever
`
`without having to reprogram the database system
`800 at the source or object code level. Instead,
`
`the lay user supplies schema restructuring
`commands,
`in an appropriate structured language,
`as indicated at 870 for restructuring the schema
`
`whenever needed. The screen control program 820d
`
`of the retrieval machine 815 may remain fixed
`
`while the entity-to~explicit—relationship schema
`of region 130-RP is forever changed. Accordingly,
`
`object—code compilation 814 needs to occur only
`once. The source code listing 812 of this access
`
`control program needs to be developed and
`debugged only once. Substantial cost savings are~
`realized, especially as time progresses and new
`entity—relationship schemas are required.”
`RE40,520, col. 27,
`line 65 through col. 28,
`15.
`
`line
`
`One of ordinary skill in the art will therefore
`
`appreciate that the relation definition, entity definition, and
`
`relation instance tables recited in the claims are within an
`
`active relational database that is deployed and in use, and which
`
`can be updated or restructured with the use of an appropriate
`
`17
`
`018
`
`018
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`structured database language (e.g., Structured Query Language
`
`(SQL)
`
`languages) query. Accordingly,
`
`the claims are patentable
`
`and favorable action is therefore warranted.
`
`B. Rejections Under 35 U.S.C. §lO2(b) Based Upon Teorey
`
`1.
`
`Independent Claim 1
`
`The Examiner rejected Claims 1-3 and 7-12 under 35
`
`U.S.C. 102(b), based upon an article by Teorey et al. entitled “A
`
`Logical Design Methodology for Relational Databases Using the
`
`Extended Entity—Relationship Model” (herein “Teorey”). Teorey
`
`discloses a method for designing large relational databases. The
`
`data requirements are conceptualized using an extended entity-
`
`relationship (EER) model, with the extensions being additional
`
`semantics, such as ternary relationships, optional relationships,
`
`and the generalization abstraction. The EER model is then
`
`decomposed according to a set of basic entity~relationship
`constructs, which are transformed into candidate relations. A set
`
`of basic transformations is used for three types of relations:
`
`entity relations, extended entity relations, and relationship
`
`relations. Candidate relations are further analyzed and modified
`
`to attain a desired degree of normalization.
`
`As an initial matter,
`
`there is an important distinction
`
`between what is done during the initial database design phase by
`
`database developers or programmers, and what is done on a day—to—
`
`day basis within an active database once the database is put into
`
`18
`
`019
`
`019
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`service (i.e.,
`
`is in use by users). During the database design
`
`phase, developers perform a data modeling exercise and then
`
`manually transform and/or normalize the model into table
`
`definitions. On the other hand, once a database design is
`
`completed, it is deployed or activated so that it is available
`
`for everyday use. Within the active database users perform
`
`queries against the resultant database tables,
`
`typically through
`
`an SQL query.
`
`As its title reveals, Teorey is concerned with database
`
`design. Moreover, Teorey states in its conclusion on page 220
`
`that “[w]e have shown that a practical step—by—step methodology
`
`for relational database design can be derived using a variety of
`
`extensions to the ER conceptual model.” In particular, Teorey
`
`provides this summary of the logical relational database design
`
`steps set forth therein:
`
`“l. Extended ER (EER) modeling of requirements
`
`1.1 Identify entities and attach attributes to each.
`
`1.2 Identify generalization and subset hierarchies.
`
`1.3 Define relationships.
`
`1.4 Integrate multiple views of entities, attributes,
`
`and relationships.
`
`2. Transformation of the EER model to relations
`
`2.l Transform every entity into one relation with the
`
`key and nonkey attributes of the entity.
`
`19
`
`020
`
`020
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`2.2 Transform every many—to*many binary (or unary)
`
`relationship into a relationship relation.
`
`2.3 Transform every ternary (or higher n~ary)
`
`relationship into a relationship relation.
`
`3. Normalization of relations
`
`3.1 Derive the primary FDs from the EER diagram.
`
`3.2 Examine all the candidate relations for MVDS and
`
`Asecondary FDs.
`
`3.3 Normalize all candidate relations to the highest
`
`degree desired, eliminating any redundancies that
`
`occur in the normalized relations.” Teorey, page
`
`220.
`
`Indeed, all of the steps 1 to 3 are directed to initial database
`
`design, not to usage of the active or compiled database and
`
`processing of database retrieval queries.
`
`In stark contrast, Claim 1 recites retrieval of
`
`relation type records from a relation definition table, retrieval
`
`of relation instance records from a relation instance table, and
`
`retrieval of desired entity type records from an entity
`
`definition table. That is,
`
`the relation definition table,
`
`relation instance table, and entity definition table are tables
`
`in an active relational database that are used during processing
`
`of user queries (i.e., record retrieval), which can similarly be
`
`updated through queries to delete, change, or add relation type
`
`20
`
`021
`
`021
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`records, relation instance records, and entity type records, as
`
`discussed in Section IV.A above.
`
`The Examiner points to Step 3, “Normalization of
`
`Relations”, on page 199 and Step 1.3 on pages 205—206 of Teorey,
`
`contending that these passages teach the claimed recitation of
`
`retrieving a specific relation type record defining the provided
`
`relation type from a relation definition table. However,
`
`these
`
`passages both deal with database normalization. Normalization is
`
`merely a design optimization step in which the database schema is
`
`organized to reduce redundant data storage, etc.
`
`In this context,
`
`the passage quoted at pages 205-206 of
`
`Teorey discusses the undesirable characteristics to be removed
`
`during the normalization phase of database design, namely
`
`reducing redundant relationships and ternary relationship
`
`definitions. Again, Teorey is merely discussing relationship
`
`selection and definition during the design phase of database
`
`creation. Nowhere do these nor any other passages of Teorey teach
`
`retrieval of relation type records from a relation definition
`
`table, retrieval of relation instance records from a relation
`
`instance table, or retrieval of desired entity type records from
`
`an entity definition table of a relational database. Stated
`
`alternately, Teorey does not teach that any of the noted
`
`relationships are to be saved in an active relational database
`
`table(s) from which they can be retrieved (or updated), i.e., by
`
`a query,
`
`for example. Rather,
`
`in Teorey, such information is
`
`stored in a static data dictionary, as discussed below.
`
`2l
`
`022
`
`022
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`The Examiner points to Figure 13 and Table 1
`
`(page 216)
`
`and Section 3.2 (page 217) of Teorey as support for providing the
`
`claimed recitation of retrieving a desired entity type record
`
`containing the desired entity type from an entity definition
`
`table, wherein the desired entity type record specifies a desired
`
`entity instance table associated with the desired entity type.
`
`In
`
`particular,
`
`the Examiner notes the passing reference to a “data
`
`dictionary” in Step 3.2. Yet,
`
`this is the only reference made to
`
`such a data dictionary in Teorey, and this reference fails to
`
`specify any further information about it.
`
`Indeed,
`
`the Examiner
`
`even acknowledges that “Teorey does not define the specifics of
`
`the use of a data dictionary for storing definitions of relation
`
`types.” Office Action, page l2.
`
`There is simply no indication that the data dictionary
`
`noted in passing in Teorey is anything other than a static data
`
`dictionary, as discussed above in Section IV.A. Accordingly,
`
`Teorey fails to teach retrieving a desired entity type record
`
`containing the desired entity type from an active relational
`
`database entity definition table.
`
`Teorey provides neither an entity definition table, a
`
`relation definition table, nor a relation instance table because
`
`Teorey has no purpose for storing entity types and relation types
`
`as data in tables of the relational database that can be
`
`retrieved. Instead, Teorey considers entity types and relation
`
`types as part of a conceptualization or abstraction phase
`
`22
`
`023
`
`023
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`separate from the active relational database. See, e.g., Teorey
`
`page 198, which provides as follows:
`
`"The entity—relationship (ER) model has been most
`successful as a tool for communication between
`the designer and the end user during the
`requirements analysis and conceptual design
`phases because of its ease of understanding and
`its convenience in representation [Chen 1976].
`One of the reasons for its effectiveness is that
`
`it is a top—down approach using the concept of
`abstraction."
`
`As noted at col. 22,
`
`lines 33-39 of the RE40,52O
`
`patent, by providing entity type and relation type retrieval from
`
`tables in the active relational database, rather than mere
`
`conceptualization or abstraction of entity and relation types
`
`during the database design phase, as demands on the database
`
`system change over time, new relation classes may be defined, for
`example. This advantageously provides a schema that may be
`
`restructured as the need arises through updating the tables using
`
`traditional queries, rather than requiring a reversion to the
`
`design phase and a potential reprogramming and compilation at the
`
`source or assembly level.
`
`Thus, Teorey fails to teach all of the recitations of
`
`independent Claim 1, and the rejection of this claim under 35
`
`U.S.C. §lO2(b)
`
`is therefore in error and should be withdrawn.
`
`23
`
`024
`
`024
`
`
`
`Reexam of Patent Application of:
`DOKTOR, U.S. PATENT 5,826,259
`
`(Now RE40,520)
`
`Control No. 90/008,648
`Filed:
`JUNE 11, 2007
`
`2. Claim 2
`
`The Examiner further contends that Teorey also teaches
`
`that the relation instance record specifies the desired entity by
`
`the desired entity type and a desired record identifier, as
`
`recited in Claim 2. As an initial matter, Teorey fails to teach
`
`all of the recitations of independent Claim 1,
`
`from which Claim 2
`
`depends, and the rejection of Claim 2 under §lO2(b) based upon
`
`Teorey therefore also is in error for the reasons set forth above
`
`with respect to Claim 1.
`
`Nonetheless, as support for the Examiner's contention
`
`with respect to Claim 2,
`
`the Examiner points to FIG.
`
`4 on page
`
`203 of Teorey, and Step 1.l(5) on page 204 of Teorey. Yet, far
`
`from teaching using relation type, relation instance, and entity
`
`type records from active relational database tables to locate the
`
`desired entity instance record, Teorey teaches that such an
`
`approach should
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
