Docket No.: 341142US91RX
`
`COMMISSIONER FOR PATENTS
`ALEXANDRIA, VIRGINIA 22313
`
`OBLON
`SPIVAK
`
`ATIORNEYS AT LAW
`
`90/008,648
`RE: Control No.:
`Applicants: Karol DOKTOR
`June 11, 2007
`Filing Date:
`For: EASILY EXPANDABLE DATA PROCESSING SYSTEM AND
`METHOD
`Group Art Unit: 3992
`Examiner: Alexander J. Kosowski
`
`SIR:
`
`Attached hereto for filing are the following papers:
`STATEMENT UNDER 37 C.F.R. § 1.560 W/EXHIBITS A-C
`RESPONSE IN EX PARTE REEXAMINATION OF U.S. PATENT NO. 5,826,259 (RE 40,520)
`RELATED CASE STATEMENT
`CERTIFICATE OF SERVICE
`Credit card payment is being made online (if electronically filed), or is attached hereto (if paper filed), in
`the amount of $0.00 to cover any required fees.
`In the event any variance exists between the amount
`enclosed and the Patent Office charges for filing the above-noted documents, please charge or credit the
`difference to Deposit Account No. 15-0030.
`
`Respectfully submitted,
`
`OBLON, SPIVAK, McCLELLAND,
`MAIER & NEUSTADT, P.C.
`/.//~
`
`Customer Number
`22850
`
`(703) 413-3000 (phone)
`(703) 413-2220 (fax)
`(OSMMN 02/09)
`
`OBLON, SPIVAK, MCCLELLAND, MAIER & NEUSTADT, P.C.
`1940 DUKE STREET. ALEXANDRIA, VIRGINIA 22314. U.S.A.
`TELEPHONE: 703-413-3000. FACSIMILE: 703-413-2220. WWW.OBLON.COM
`
`001
`
`

`

`DOCKET NO: 34II42USRX
`
`IN THE UNITED STATES PATENT & TRADEMARK OFFICE
`
`IN RE EX PARTE REEXAMINATION OF
`
`U.S. PATENT 5,826,259 (RE 40,520)
`
`KAROL DOKTOR
`
`EXAMINER: ALEXANDER J. KOSOWSKI
`
`SERIAL NO: 90/008,648
`
`FILED: JUNE 11,2007
`
`FOR: EASILY EXPANDABLE DATA
`PROCESSING SYSTEM & METHOD
`
`GROUP ART UNIT: 3992
`
`STATEMENT UNDER 37 C.F.R. § 1.560
`
`COMMISSIONER FOR PATENTS
`ALEXANDRIA, VIRGINIA 22313
`
`SIR:
`
`An interview was conducted on May 14, 2009 with reference to the above-
`
`identified ex parte reexamination. Patent Holder's representative Scott McKeown
`
`attended the interview along with Mr. Robert Foster, a software/technical consultant
`
`to Financial Systems Technology (FST) (Patent Holder). For the Office, Examiner
`
`Kosowski participated along with two conferees of the Central Reexamination Unit
`
`(Examiners Ferris and Keasel). Next, a summary in accordance with 37 C.F.R. §
`
`1.560 follows in conformance with MPEP § 713.04.
`
`(A) A brief description of the nature of any exhibit shown or any
`demonstration conducted;
`
`002
`
`

`

`Satement under 37 C.F.R. § 1.560
`Control No. 90/008,648
`Docket No. 341142US91X
`-Figures of the '259 Patentl were enlarged and presented on poster boards for
`
`ease of presentation. Copies of the specific drawings exist in the file as exhibits to the
`
`Examiner Interview Summary of May 14, 2009.
`
`(B) Identification of the claims discussed;
`
`-Reissued claims 1 and 10 were discussed.
`
`(C) Identification of specific prior art discussed;
`
`- The conceptual design described by the Teorey reference, and the static
`
`dictionary table of Kumpati were discussed relative to the restructurable and
`
`updatable tables of query processing claim 1, and physical database claim 10.
`
`(D) Identification of the principal proposed amendments of a substantive
`nature discussed, unless these are already described on the Interview Summary form
`completed by the examiner;
`
`-No specific amendments were discussed or contemplated.
`
`(E) The general thrust of the principal arguments of the applicant and the
`examiner should also be identified, even where the interview is initiated by the
`examiner. The identification of arguments need not be lengthy or elaborate. A
`verbatim or highly detailed description of the arguments is not required. The
`identification of the arguments is sufficient if the general nature or thrust of the
`principal arguments can be understood in the context of the application file. Of
`course, the applicant may desire to emphasize and fully describe those arguments
`which he or she feels were or might be persuasive to the examiner;
`
`- Mr. Foster discussed the background of the invention as described in Fig IA
`
`of the '259 Patent, and the inability of prior art systems to dynamically restructure
`
`either the data storage organization and/or database schema. Fig 8 was contrasted to
`
`this prior art illustration.
`
`Next, Mr. Foster described the operation of the entity definition table and
`
`relation definition table as claimed and as described by the accompanying
`
`specification of the '259 Patent. Mr. Foster noted the meaning of these terms as one
`
`I '''259 Patent" is used herein to refer to Reissued Patent (40,520), the subject to this ex parte
`reexamination (originally U.S. Patent 5,826,259).
`
`2
`
`003
`
`

`

`Satement under 37 C.F.R. § 1.560
`Control No. 90/008,648
`Docket No. 341142US91X
`
`skilled in the art, in view of the specification (including exhibit Figures 4A, 5, 7-1, 7-
`
`2, 9-1 and 9-2) and distinguished their operation from static tables of the general
`
`design process described by Teorey. Finally, Mr. Foster noted the entity type and
`
`entity instance table attributes of the claims, explaining their meaning as one skilled
`
`in the art, in view of the specification, noting their absence (as claimed) from all art of
`
`record.
`
`Mr. McKeown then discussed that the broadest reasonable interpretation of
`
`certain claim terms such as entity definition table and relation definition table, when
`
`viewed from the perspective of one skilled in the art, in light of the specification,
`
`required different interpretation than that accorded these terms by the Office.
`
`Additionally, the entity type and specified entity instance table attributes of the claims
`
`were discussed and it was noted that none of the art of record describe these features,
`
`alone, or in combination.
`
`Mr. McKeown then distributed two declarations to be submitted under 37
`
`C.F.R. §1.132, together with a formal response. The first declaration (Exhibit A,
`
`submitted herewith) provides the understanding of Dr. Ramez A. Elmasri, Ph.D, one
`
`skilled in the art, with respect to the generic, conceptual and logical design features of
`
`the Teorey reference. Exhibit A notes that the tables identified by the Office as
`
`corresponding to the physical implementation of the '259 Patent claims, are in fact,
`
`transitory design tools. The second declaration (Exhibit B, submitted herewith)
`
`provides the broadest reasonable interpretation of the claimed entity definition table
`
`and relation definition table in view of the specification, as determined by Dr.
`
`Elmasri. Finally, it was noted that a third declaration (Exhibit C, submitted herewith)
`
`was being prepared with Dr. Elmasri on the broadest reasonable interpretation of the
`
`claimed entity type and specified entity instance table attributes of the claims.
`
`3
`
`004
`
`

`

`Satement under 37 C.F.R. § 1.560
`Control No. 90/008,648
`Docket No. 341142US9lX
`
`(F) a general indication of any other pertinent matters discussed;
`
`-The interview commenced with a discussion of the business ofFST, provided
`
`by Mr. Foster. Mr. Foster briefly explained the history of FST to date.
`
`(0) if appropriate, the general results or outcome of the interview.
`
`- The Examiners indicated that the presented discussion was helpful in
`
`focusing the outstanding issues and indicated that the formal response would be
`
`considered in this light upon filing. Mr. McKeown and Mr. Foster thanked the
`
`examiners for their time and efforts, concluding the interview.
`
`Respectfully submitted,
`
`OBLON, SPIVAK, McCLELLAND,
`MAIER & NEUSTADT, P.C.
`~~?
`.~~AKeown
`Attorney of Record
`Registration No. 42,866
`
`Customer Number
`22850
`
`Tel: (703) 413-3000
`Fax: (703)413-2220
`(OSMMN 08/07)
`
`4
`
`005
`
`

`

`EXHIBIT A
`EXHIBIT A
`
`006
`
`

`

`DOCKET NO: 341142USRX
`
`IN THE UNITED STATES PATENT & TRADEMARK OFFICE
`
`IN RE EX PARTE REEXAMINAnON OF
`U.S. PATENT 5,826,259 (RE 40,520)
`
`EXAMINER: ALEXANDER J. KOSOWSKI
`
`SERIAL NO: 90/008,648
`
`FILED: JUNE 1], 2007
`
`GROUP ART UNIT: 3992
`
`FOR: EASILY EXPANDABLE DATA
`PROCESSING SYSTEM & METHOD
`
`DECLARATION UNDER 37 C.F.R. § 1.132
`
`COMMISSIONER FOR PATENTS
`ALEXANDRIA, VIRGINIA 22313
`
`Sir:
`
`Dr. Ramez A. Elmasri, Ph.D declares:
`
`].
`
`That I received my Doctor of Philosophy in Computer Science from Stanford
`
`University in 1980, with a thesis in the area of database design and integration. I received my
`
`Master of Science degree in Computer Science from Stanford University, and my Bachelor of
`
`Science degree in Electrical Engineering from Alexandria University in Egypt.
`
`2.
`
`That my current position is a professor in the Department of Computer
`
`Science and Engineering at the University of Texas at Arlington, 300 Nedderman Hall, 416
`
`Yates, Box 19015, Arlington, 76019.
`
`I am a senior professor and an expert in the field of
`
`databases as set forth in the attached Curriculum Vitae. I have worked in this field since my
`
`dissertation research started at Stanford University in 1978.
`
`3.
`
`That I have authored and coauthored over 100 research papers, articles, and
`
`book chapters related to the database field. I am also the lead coauthor of the leading database
`
`textbook "Fundamentals of Database Systems", now in its Fifth Edition (Addison-Wesley,
`
`007
`
`

`

`2007). My book has been used as the required textbook in hundreds of universities
`
`worldwide since the first edition was published in 1989, and has been translated into
`
`approximately a dozen languages. I have supervised 12 dissertations and over 100 MS theses.
`
`I served on numerous program committees of national and international database and
`
`computer science conferences, including as program chair of the International Conference on
`
`Conceptual Modeling, and program vice chair ofthe IEEE International Conference on Data
`
`Engineering. I have been a consultant to several companies on database technologies,
`
`including Bell Communications Research, Action Technologies, Digital Equipment
`
`Corporation, and Honeywell Inc. I have also been principal investigator on several research
`
`grants by the National Science Foundation, NASA, the State of Texas Advanced Research
`
`Program, and the Automation and Robotics Research Institute. I have served as funding
`
`panelist for various scientific agencies, including NSF and the National Institute of Health.
`
`4.
`
`That I regularly teach introductory and advanced courses in the field of
`
`databases, and have given tutorials at various international conferences including a tutorial on
`
`Object-Oriented Databases at the International Conference on Very Large Data Bases as well
`
`as on Distributed Databases, Temporal Databases, Database Modeling, and Relational
`
`Databases at other international conferences.
`
`5.
`
`That I have been retained on behalf of Financial Systems Technology, the
`
`assignee of U.S. Patent No. 5,826,259 reissued as RE 40,520 (hereinafter the '259 Patent")
`
`and currently subject to Ex Parte Reexamination as Control No: 90/008,648.
`
`6.
`
`That I have thoroughly reviewed the '259 Patent, including the claims of that
`
`patent in view of the specification, and the Official Actions in Ex Parte reexamination dated
`
`December 12, 2008 and March 5. 2009.
`
`7.
`
`That I have thoroughly reviewed the art applied in the reexamination, namely:
`
`2
`
`008
`
`

`

`• The publication identified as Teorey, et aI., entitled A Logical Design
`
`Methodology for Relational Databases. ...(hereinafter "Teorey").
`
`• U.S. Patent 4,774,661, (hereinafter "Kumpati").
`
`• U.S. Patent 4,918,593, (hereinafter "Huber)."
`
`• The publication identified as M. M. Zloof, entitled Query-by-Example:
`
`A Data Base Language (hereinafter "Zloof')
`
`8.
`
`That based upon my review of these materials and my background and
`
`experience in the field of database design and implementation, I am of the following
`
`opinions:
`
`9.
`
`That Teorey describes a database design methodology. It is understood by
`
`database designers that the conceptual design phase precedes, and is independent from the
`
`implementation phase, known as physical database design. The conceptual design phase does
`
`not include implementation concepts or query processing considerations. In particular Figure
`
`3 is a diagrammatic expression of design concepts, known as an ER (Entity Relationship)
`
`diagram. Teorey cites my work in this area at Pages 199 and 201 (Elmasri et al.) Fig. lOis a
`
`logical relationship diagram (ternary) for designing relationships which are not binary.
`
`Likewise, Figure 13 shows how the ER design can be transformed to logical tables, but these
`
`tables are not data structures nor does Teorey describe any implementation considerations.
`
`10.
`
`That conceptual database design commonly integrates several conceptual
`
`designs to a single design prior to moving into the implementation phase. Indeed, Teorey
`
`refers to my work (Elmasri and Wiederhold; Elmasri et al.) in this area at page 206, column
`
`2. The conceptual diagrams of Teorey, such as Figure 10, are meant to show constraints on
`
`the data content, rather than any data structuring or query processing aspects of an
`
`implementation.
`
`3
`
`009
`
`

`

`11.
`
`That I disagree with the conclusion of the Official Action of March 5, 2009 at
`
`page 12 which asserts "[I]t is well known that a database created by the methods of Teorey
`
`would have the programmed functionality to be actually implemented in a physical database
`
`system." Database design and implementation includes three phases, a conceptual phase, a
`
`logical phase and a physical design and implementation phase. The conceptual and logical
`
`phases are closely related, but the physical design and implementation phase is typically
`
`completed at a later stage and is the most complex phase. Implementations of any generic,
`
`conceptual design can vary greatly depending upon the desired queries, efficiencies and
`
`update operations. Although Teorey describes a conceptual and logical design phase for
`
`relational databases, it is incorrect to contend that this document provides any of the specific
`
`query processing of the claims ofthe '259 Patent. In fact, Teorey explicitly points this out at
`
`Page 199 stating: Processing efficiency for query, update, and maintenance ofintegrity
`
`constraints is considered to be part ofphysical design and is not discussed here.
`
`12.
`
`That
`
`it is incorrect to assume that the implementation of any specific query
`
`processing naturally flows from a generic design process such as Teorey.
`
`In the time frame
`
`of the '259 patent filing it was not uncommon for simple relation database queries to take on
`
`the order of many minutes ifnot hours (See column I lines 55-60 of the '259 Patent). As
`
`such, the physical design and implementation of query processing was key to the widespread
`
`emergence of this technology.
`
`13.
`
`That I respectfully disagree with the conclusions ofthe United States Patent &
`
`Trademark Office (hereinafter 'Office") as outlined at pages 3-4 ofthe Official Action of
`
`March 5, 2009 (hereinafter "Action"). Specifically, the Office asserts at page 3 of the Action
`
`that page 198 column 1-2 and page 205, step 1.3, describes the claimed "retrieving a specific
`
`relation type record defining said provided relation type from a relation definition table" of
`
`claim 1. Page 198 column 1-2 in fact describe an introduction to general database design
`
`4
`
`010
`
`

`

`concepts and methodologies and do not refer to retrieving any relation type record or relation
`
`definition table as claimed. Moreover, step 1.3 of page 205 of Teorey describes how to
`
`specify relationship types during conceptual database design and how to differentiate
`
`between redundant and ternary relationships. As stated above, Teorey does not describe any
`
`data structuring or query processing. Accordingly one of skill in the art would not identify
`
`the claimed query processing of claim 1, including a specific relation type record or relation
`
`definition table as being described by Teorey.
`
`14.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 3-4 of the Action. Specifically, the Office asserts at page 3 of the Action that Figures 3
`
`and 10, as well as page 210 Section 3.1.3 describe the claimed "retrieving a specific relation
`
`instance record defining a relation ojsaidprovided relation type between said provided
`
`entity and said desired entity from a relation instance table corresponding to said specific
`
`relation type record" of claim 1. As noted above, Figure 3 is a diagrammatic expression of
`
`design concepts, known as an ER (Entity Relationship) diagram. Figure 10 is a logical
`
`relationship diagram (ternary) for designing relationships which are not binary. The example
`
`data shown in Figure 10 are purely to illustrate data under different constraints, and do not
`
`refer to any query processing techniques. Likewise, page 210 Section 3.1.3 describes various
`
`constraints on n-ary relationship data, including ternary relationships. As stated above,
`
`Teorey does not describe any data structuring or query processing. Accordingly one of skill
`
`in the art would not identify the claimed query processing of claim 1, including a relation
`
`instance table or specific relation instance record as being described by Teorey.
`
`15.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 3-4 of the Action. Specifically, the Office asserts at page 3 of the Action that Figures
`
`13 and Table 1, as well as page 217 Section 3.2 describe the claimed retrieving a desired
`
`entity type record containing said desired entity type from an entity definition table, wherein
`
`5
`
`011
`
`

`

`said desired entity type record specifies a desired entity instance table associated with said
`
`desired entity type of claim). As noted above, Figure 13 (including Table I) shows how the
`
`ER design can be transformed to logical tables, but these tables are not data structures nor
`
`does Teorey describe any implementation considerations. Page 2) 7 step 3.2 describes
`
`constraints on the data known as primary key and foreign key constraints. These are well
`
`known constraints specified during conceptual and logical design. The primary key and
`
`foreign key constraints shown in Step 3.2 cannot be considered an entity definition table as
`
`claimed because the specifying of constraints in the design phase establishes initial data
`
`requirements of the database design. The collection of data requirements by Teorey, would
`
`never be queried, or even exist in a relational database data structure. The dictionary of
`
`Teorey is an intermediate component of a design process, not a data structure accessed by
`
`query processing as claimed. As stated above, Teorey does not describe any data structuring
`
`or query processing. Accordingly one of skill in the art would not identifY the claimed query
`
`processing of claim I, including a desired entity type record, entity instance table, or entity
`
`definition table as being described by Teorey.
`
`16.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 3-4 of the Action. Specifically, the Office asserts at page 3 of the Action that Page
`
`198, column), page 205, Step 1.2 and page 208, Section 3.1 describe the claimed retrieving
`
`said desired entity from said desired entity instance table of claim 1. Page 198 column 1 in
`
`fact describe an introduction to general database design concepts and methodologies and does
`
`not refer to retrieving any desired entity or desired entity instance table as claimed. Page 205
`
`Step 1.2 describes a design phase process for identifYing generalization and subset
`
`hierarchies. Page 208 Section 3.1 describes transforming the EER Model to a logical
`
`relational design. As stated above, Teorey does not describe any data structuring or query
`
`processing. Accordingly one of skill in the art would not identifY the claimed query
`
`6
`
`012
`
`

`

`processing of claim 1, including a desired entity or desired entity instance table as being
`
`described by Teorey.
`
`17.
`
`That the Office has identified Kumpati as describing aspects ofthe '259 Patent
`
`(column 5 Hnes 51-67 and column 8 lines 35-59). Specifically, the Office has asserted that
`
`Kumpati describes "that definitions of relation types of entity sets are stored in a data
`
`dictionary" at page 3 of the Action, in rejecting claim 1. The Office asserts that combining
`
`these aspects with the dictionary ofTeorey would have been obvious to one of skill in the art
`
`for arriving at the claimed entity definition table. The passive (i.e., part of design phase)
`
`dictionary ofTeorey, as noted above, is an intermediate collection of data requirements. The
`
`collection of data requirements by Teorey, would never be queried, or even exist in a
`
`relational database data structure. The passive dictionary ofTeorey is an intermediate, static
`
`component ofa design process, not a data structure accessed by query processing as claimed.
`
`The active data dictionary of Kumpati is very different from the passive dictionary referred to
`
`in Teorey. In Teorey the term "dictionary" is used to refer to a collection of data
`
`requirements of a design phase. In Kumpati the term "dictionary" refers to an active
`
`component of a database system. There would be no known reason to combine features of a
`
`passive and active dictionary as their role in design and database implementation are separate
`
`concerns.
`
`18.
`
`That claim 10 of the '259 Patent recites a relational database processing
`
`system. Based upon my understanding ofthe '259 Patent specification, the relational
`
`database processing system is reasonably interpreted as a relational database with an active
`
`data dictionary, having multiple tables. The relational database system of claim 10 includes
`
`the entity and relation type definition tables and the entity and relationship instance tables.
`
`19.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 5 of the Action that page
`
`7
`
`013
`
`

`

`204, Section 2.1, describes the claimed "an entity definition table containing afirst entity
`
`type record defining afirst entity type" of claim 1O. Page 204, Section 2.1 describes
`
`formulation of the EER (Extended-Entity Relationship) modeling. Page 204 does not refer to
`
`a definition table containing a first entity type as claimed. As stated above, Teorey does not
`
`describe any physical data structuring of a relational database. Accordingly one of skill in the
`
`art would not identify the claimed entity definition table of claim 10, including afirst entity
`
`type as being described by Teorey.
`
`20.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 5 of the Action that Figures
`
`13 (including Table 1) describe the claimed "afirst entity instance table associated with said
`
`first entity type of claim 1O. As noted above, Figure 13 (including Table I) shows how the
`
`ER design can be transformed to logical tables, but these tables are not data structures nor
`
`does Teorey describe any implementation considerations. As stated above, Teorey does not
`
`describe any physical data structuring of a relational database. Accordingly one of skill in the
`
`art would not identify the claimed first entity instance table associated with saidfirst entity
`
`type of claim 1, as being described by Teorey.
`
`21.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 5 of the Action that Page
`
`208, Section 3.1 and Page 205 Step 1.2 describe the claimed a plurality ofentity instance
`
`records stored in saidfirst entity instance table of claim 10. Page 205 Step 1.2 describes a
`
`design phase process for identifying generalization and subset hierarchies. Page 208 Section
`
`3.1 describes transforming the EER Model to a logical relational design. As stated above,
`
`Teorey does not describe any physical data structuring of a relational database. Accordingly
`
`one of skill in the art would not identify the claimed plurality ofentity instance records
`
`stored in saidfirst entity instance table of claim 10, as being described by Teorey.
`
`8
`
`014
`
`

`

`22.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 5 of the Action that Page
`
`205, Section 2.1, Step 1.3 and Page 217 and Page 205, Step 3.2 describe the claimed a
`
`relation definition table containing a first relation type record defining a provided relation
`
`type of claim 10. Page 205 Step 1.2-1.3 describes a design phase process for identifying
`
`generalization and subset hierarchies. Page 217 step 3.2 describes constraints on the data
`
`known as primary key and foreign key constraints. These are well known constraints
`
`specified during conceptual and logical design. The primary key and foreign key constraints
`
`shown in Step 3.2 cannot be considered a relation definition table as claimed because the
`
`specifying of constraints in the design phase establishes initial data requirements ofthe
`
`database design. The collection ofdata requirements by Teorey, would never be queried, or
`
`even exist in a relational database data structure. The dictionary of Teorey is an intermediate
`
`component of a design process, not a physical data structure ofa relational database. As
`
`stated above, Teorey does not describe any physical data structuring of a relational database.
`
`Accordingly one of skill in the art would not identify the claimed relation definition table of
`
`claim 10, as being described by Teorey.
`
`23.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 6 of the Action that Figure 10
`
`describes the claimed a first relation instance table associated with saidprOVided relation
`
`type of claim 10. Figure lOis a logical relationship diagram (ternary) for designing
`
`relationships which are not binary. The example data shown in Figure 10 are purely to
`
`illustrate data under different constraints, as illustrations of a conceptual design process. As
`
`stated above, Teorey does not describe any physical data structuring of a relational database.
`
`Accordingly one of skill in the art would not identify the claimedfirst relation instance table
`
`associated with said provided relation type ofclaim 10, as being described by Teorey.
`
`9
`
`015
`
`

`

`24.
`
`That I respectfully disagree with the conclusions of the Office as outlined at
`
`pages 5-6 of the Action. Specifically, the Office asserts at page 6 of the Action that Page
`
`203, Figure 4 and Section 3.1.3 describe the claimed afirst relation instance record ofsaid
`
`provided relation type, saidfirst relation instance record relating a desired entity in one of
`
`said entity instance records to a provided entity of claim 10. Page 203 and Figure 4 describe
`
`ternary relationships of conceptual EER constructs. Likewise, Section 3.1.3 describes
`
`various constraints on n-ary relationship data, including ternary relationships. As stated
`
`above, Teorey does not describe any physical data structuring of a relational database.
`
`Accordingly one of skill in the art would not identify the claimed first relation instance
`
`record ofsaidprovided relation type, saidfirst relation instance record relating a desired
`
`entity in one ofsaid entity instance records to a provided entity of claim 10 as being
`
`described by Teorey.
`
`25.
`
`That the Office has identified Kumpati as describing aspects of the '259 Patent
`
`(column 5 lines 51-67 and column 8 lines 35-59). Specifically, the Office has asserted that
`
`Kumpati describes "that definitions of relation types of entity sets are stored in a data
`
`dictionary" at page 6 ofthe Action, in rejecting claim 10. The Office asserts that combining
`
`these aspects with the dictionary ofTeorey would have been obvious to one of skill in the art
`
`for arriving at the claimed entity definition table. The passive (Le., part of design phase)
`
`dictionary of Teorey, as noted above, is an intermediate collection of data requirements. The
`
`collection of data requirements by Teorey, would never be queried, or even exist in a
`
`relational database data structure. The passive dictionary ofTeorey is an intermediate, static
`
`component of a design process, not a data structure accessed by query processing as claimed.
`
`The active data dictionary of Kumpati is very different from the passive dictionary referred to
`
`in Teorey. In Teorey the term "dictionary" is used to refer to a collection of data
`
`requirements of a design phase. In Kumpati the term "dictionary" refers to an active
`
`10
`
`016
`
`

`

`component of a database system. There would be no known reason to combine features of a
`
`passive and active dictionary as their role in design and database implementation are separate
`
`concerns.
`
`26.
`
`I declare that all statement made herein of my own knowledge are true and
`
`that all statements made on infonnation and belief are believed to be true; and further that
`
`these statements were made with the knowledge that willful false statements and the like so
`
`made are punishable by fine or imprisonment, or both, under Section 1001 of Title 18 of the
`
`United States Code and that such willful false statements may jeopardize the validity of this
`
`reexamined patent and any corresponding reexamination certificate.
`
`Dr.Ra~.D
`
`Date
`
`11
`
`017
`
`

`

`RAMEZ A. ELMASRI
`Curriculum Vitae (February 2009)
`
`Professor, Department of Computer Science and Engineering
`The University of Texas at Arlington, 107 GACB
`300 Nedderman Hall, 416 Yates Street
`Box 19015
`Arlington, Texas 76019
`
`Office Phone: (817) 272 - 2348
`Fax: (817) 272 - 3784
`Mobile Phone: (817) 228 - 0209
`Home Phone: (817) 468 - 3578
`email: elmasri@cse.uta.edu
`
`RESEARCH AREAS
`
`Current Research Interests - Sensor Networks (Querying, Indexing, Energy Efficient Data Collection,
`Integration with RFID, Sensor Architectures), RFID, Bioinformatics Databases (Data Sources Integration,
`Mediators, Conceptual Modeling, Ontologies), Web Services Ontologies and Integration, XML (Keyword(cid:173)
`based Querying, Indexing, Distributed XML, Caching).
`Other Research Experience - Databases (XML, Conceptual Modeling, Temporal Databases, Indexing,
`Query Languages, Object Databases, DBMS Implementation Techniques, Schema Integration), Semantic
`Web Modeling and Ontologies, Operating Systems, Distributed Systems, Systems Integration, Object(cid:173)
`Oriented Software Development, Networked Information Systems, Programming Languages.
`
`FORMAL EDUCATION
`
`Stanford University - Stanford, California
`Ph.D. in Computer Science, 1980
`M.S. in Computer Science, 1980
`Alexandria University - Alexandria, Egypt
`B.S. in Electrical Engineering, 1972
`
`PROFESSIONAL EXPERIENCE
`
`9/1990 - current
`
`9/1982 - 8/1990
`
`6/1980 - 8/1982
`
`2003 - current
`
`1991 -1999
`
`Faculty Member - The University of Texas at Arlington, Arlington, Texas
`• Professor 1994 - current
`• Associate Professor (tenured) 1990 - 1994
`
`Faculty Member - The University of Houston, Houston, Texas
`• Associate Professor (tenured) 1987 - 1990
`• Assistant Professor 1982 - 1987
`
`Principal Research Scientist - Honeywell Inc., Corporate Technology Center,
`Bloomington, Minnesota
`• Worked on the design and implementation of the DDTS (Distributed Database
`Testbed System)
`
`Consultant - Various Law Firms
`• Consulted on patent analysis and patent violation cases
`• Consulted on software copyright infringement cases
`
`Faculty Associate - Automation and Robotics Research Institute (ARRI), The
`University of Texas at Arlington, Fort Worth, Texas
`• Conducted research on systems integration, object oriented software
`• Conducted research on concurrent engineering, agile manufacturing
`
`Summer 1991
`
`Visiting Professor - University of Zurich, Zurich, Switzerland
`• Conducted research on active and object-oriented databases
`
`018
`
`

`

`Summer 1990
`
`Summer 1989
`
`Consultant - Bell Communications Research, Morristown, New Jersey
`• Conducted research on enhancing capabilities of the Datacycle Architecture
`
`Consultant - Bell Communications Research, Piscataway, New Jersey
`• Conducted research on data models, query languages, and indexing techniques
`for temporal databases
`
`Summer 1987
`
`Summer Research Fellow - Rome Air Development Center, Rome, New York
`• Conducted research on incorporating databases into distributed real-time systems
`
`Summer 1984, 1985
`
`Faculty Member - IFRICS (Institute for Retraining in Computer Science),
`Clarkson University, Potsdam, New York
`• Taught the database course at the institute
`
`1982 -1987
`
`9/1974 - 5/1980
`
`Consultant - Honeywell Computer Sciences Center, Golden Valley, Minnesota
`• Consulted on the DDTS (Distributed Database Testbed System) project
`• Consulted on development of tools for schema integration in multi-database
`systems
`
`Research and Teaching Assistant - Department of Computer Science, Stanford
`University, Stanford, California
`• Worked on several research projects, including the compiler for the CHIRON
`programming language, a machine instruction simulator f