Detailed Action
Applicant amended claims 11 and 15 and presented claims 1-27 for reconsideration on 11/24/2025.
Examiner's Notes
The Examiner cites particular sections in the references as applied to the claims below for the convenience of the applicant(s). Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant(s) fully consider the references in their entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 102 that forms the basis for all the rejections under this section made in this Office Action:
A person shall be entitled to a patent unless—
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-3, 10-15, 17, 19-22 and 24-27 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by IDS provided reference, Sutter, Patent No.: US 6,446,092 B1 (Sutter).
Sutter teaches:
Claim 1. A method comprising:
using a computer processor to execute a data architecture modeling software program that defines and maintain a first data architecture model stored in a computer memory; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11, an IDDB database is a software for defining and maintain a first data architecture which is “a structure for relationships between sites collaborating on common activities, i.e. activity groups, and in particular how to propagate changes efficiently between the members of the activity group” and wherein each site includes a physical data model diagrams for each site specific database: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”)
wherein the data architecture modeling software program is configured to architect one or more datasets; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11, an activity and activity parts in a project include one or more datasets: “the application database 34 comprises a collection of activities and the associated information…An activity is a basic unit of collaboration and comprises a connected and rooted set of related data which will be of interest to a subset of sites (i.e. users who will want to read or update the data). An activity part comprises a subset of an activity which may be independently used by different sites and users, in other words, not each site that uses an activity part may use the entire activity. An activity table comprises a table wherein each unique record defines an activity…an activity is defined by one database record, termed the root activity record, and the activity comprises: (a) the root record; and (b) all (or a subset) of records that are related to the activity record. The related records are specified using path relationships of one-to-one, or one-to-many…”)
wherein the first data architecture model includes a first plurality of physical data model diagrams, which include first, second and third physical data model diagrams; (15:51-61, 36: 54-37:31, 40:37-48, 57:5-11, 59:5-11, 61:30-37, each site is associated with a corresponding first, second, third, etc., physical data model diagram, e.g., data definition for defining tables, data fields, etc., used in each site: “A first requirement is that the application designer for the IDDB be able to declare a unique database name”, “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”)
and further comprising:
adding a data table representation to the first physical data model diagram to form a first data table representation of the first physical data model diagram; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the first physical model diagram, has a first table name and contains a first plurality of data table columns; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the first physical data model diagram contains a first unique key comprised of one or more of the first plurality of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70: 43-48, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; “In a database system, a key for a record is the unique identification for the record. The key for a fragment is, in turn, the record key with a sequential vertical fragment number denoting the part of the record that the fragment represents”)
and further comprising: adding a data table representation to the second physical data model diagram to form a first data table representation of the second physical data model diagram; (15:51-61, 36: 54-37:31, 61:30-37, data definition for a particular site includes a table defining data fields for the particular site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the second physical data model diagram, has the first data table name and contains the first plurality of data table columns; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the second physical data model diagram contains the first unique key comprised of one or more of the first plurality of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70: 43-48, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
and further comprising: adding a data table representation to the third physical data model diagram to form a first data table representation of the third physical data model diagram; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the third physical data model diagram, has the first data table name and contains the first plurality of data table columns; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the third physical data model diagram contains the first unique key comprised of one or more of the first plurality of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70: 43-48, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
and further comprising:
adding a first peer key constraint to the first data architecture stored in the computer memory; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70:43-73:16, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities; the assigned key constrains sites to shared common data)
wherein the first peer key constraint constrains the first unique key of the first data table representation of the first physical data model diagram, the first unique key of the first data table representation of the second physical data model diagram, and the first unique key of the first data table representation of the third physical data model diagram; (7: 41-52, 9: 12-20, 36: 54-37:31, 58:59-67, 60:58-61:26, 70:43-73:16, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities; the assigned key constrains sites to shared common data. For example, a first site comprises an activity including data fields whereas a second site and a third site comprises a subset of data fields in which they are interested in)
and further comprising removing redundant data table columns from the first data architecture model before the one or more datasets are instantiated by:
deleting any nonidentifying data table columns from the first data table representation of the second physical data model diagram to form a first peer dataset connector representation; and deleting any nonidentifying data table columns from the first data table representation of the third physical data model diagram to form a first copy of the first dataset connector representation; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 50:65-51-20, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment/columns of a dataset in a distributed database as specified in design time is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site and deleted/not synchronized with the site: 36: 26-37:31, “ an activity is defined by one database record, termed the root activity record, and the activity comprises: (a) the root record; and (b) all (or a subset) of records that are related to the activity record. The related records are specified using path relationships of one-to-one, or one-to-many (but not many-to-one or many-to-many). It will be appreciated that the group of records is connected because there is a path to every such record that includes only records that are also part of the same activity. In the description of the application database 34, direction for the database schema is defined as “up” for the direction of the “one” end of all one-to-many relationships and “down” as the direction of the “many” end. Accordingly, an activity comprises the activity record and some or all related records beneath it (i.e. “down”) in the schema. It will also be understood that if one record in a table is an activity record, then all records in that table are activity records, and the table itself is known as an activity table…. Accordingly, distribution/replication rules will apply to the “kind” of activity, and advantageously the distribution/replication rules can be specified at design time and considered as part of the database schema”; 50:65-51-20, “The dTranslation table 128b belongs to the Design-Time tables 128 (FIG. 12). The dTranslation table 128b is populated at design time and records every tablename/fieldname…The translation utility for the IDDBMS uses this information (and other information) at runtime to manage all translation for all applications”; 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein each of the second physical data model diagram and the third physical data model diagram is dependent on the first physical data model diagram, after the step of deleting the nonidentifying data table columns from the first data table representations of the second and third physical data models; and (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment/columns of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site: 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the first physical data model diagram is configured to be used by the data architecture modeling software program to architect a first independent dataset that functions as a single shared source of unique data content records for a group of two or more dependent datasets; (15:51-61, 36: 39:36-65, 40:37-48, 54-37:31, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data related to each site and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and sites with a synchronized fragment of the record are considered as dependents)
wherein each of the second physical data model diagram and the third physical data model diagram is architected to prevent redundant data instances in the first data architecture model; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site: 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the second physical data model diagram is configured to be used by the data architecture modeling software program to architect a first dependent dataset; (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data related to each site and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and a site with a synchronized fragment of the record is considered as dependent)
wherein the third physical data model diagram is configured to be used by the data architecture modeling software program to architect a second dependent dataset; and (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data related to each site and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and a site with a synchronized fragment of the record is considered as dependent)
wherein each of the first independent, the first dependent, and the second dependent datasets is architected to prevent redundant data in the first and second dependent datasets. (6: 57-63, 7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-48, 58:34-67, 59:5-11, 60:1-5, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a redundant fragment for the site and is not synchronized: 6: 57-63, “A record fragment according to the present invention is a piece of an individual record, and comprises a subset of columns in a record”; 36: 26-37:31, “An activity part comprises a subset of an activity which may be independently used by different sites and users, in other words, not each site that uses an activity part may use the entire activity” 40: 37-48, “the activity parts were described in terms of entire tables, but activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables. For example, there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”; 60:1-5, “tables under an activity, the default distribution rule is to replicate the appropriate subset of its contents to every site participating in the shared activity. If an activity part is specified for the table, then the particular activity part is also replicated”; 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
Claim 2. The method of claim 1
wherein the first data table representation of the first physical data model diagram is designated a first peer data registry representation in the computer memory using the data architecture modeling program for the first peer key constraint of the first data architecture model; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70:46-73:16, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities; the assigned key based on an agreement is a registration for constraining each site to shared common data)
wherein the first peer data registry representation is architected as a single source of data content records for the first peer key constraint of the first data architecture model; (7:41-52, 3:13-32, 4:22-33, 9:12-20, 58:59-67, 60:58-61:26, 70:46-73:16, registering a source as a single source of data content records depends on the need of a site for “selected information” to be synchronized with another site: “Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the first peer data registry representation is architected to contain a first set of unique data instances in the first physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first data table representation of the second physical data model diagram is architected to contain a first subset of the first set of unique data instances; and (Sutter, 40: 37-48, each site is interested in a subset of records)
wherein the first data table representation of the third physical data model diagram is architected to contain a second subset of the first set of unique data instances. (Sutter, 40: 37-48, each site is interested in a subset of records)
Claim 3. The method of claim 2
wherein the first plurality of physical data model diagrams of the first data architecture model includes a fourth physical data model diagram; (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared data in each site is a first, second, third, fourth, etc., physical data model of common activities)
and further comprising:
adding a data table representation to the fourth physical data model diagram to form a first data table representation of the fourth physical data model diagram; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the forth physical model diagram contains a second plurality of data table columns; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the forth physical data model diagram contains a first unique key comprised of one or more of the second plurality of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein the first peer key constraint of the first data architecture model constrains the first unique key of the first data table representation of the fourth physical data model diagram; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first data table representation of the fourth physical data model diagram is architected to contain a third subset of the first set of unique data instances. (Sutter, 40: 37-48, each site is interested in a subset of records)
Claim 10. The method of claim 2 further comprising:
using a computer processor to execute a database management system program to dataset instantiate a first database schema based on the first physical data model diagram, a second database schema based on the second physical data model diagram and a third database schema based on the third physical data model diagram; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 a database schema based on the defined table, data fields, etc., is used for creation of a database for each site, sharing certain data fields as defined and performing database operations: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”).
wherein a first database table with a first unique key index is included in the first database schema based on the first data table representation architected in the first physical data model diagram; (57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
wherein a first database table with a first unique key index is included in the second database schema based on the first data table representation architected in the second physical data model diagram; (57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
wherein a first database table with a first unique key index is included in the third database schema based on the first data table representation architected in the third physical data model diagram; (57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
and further comprising:
adding software programmed to enforce peer dataset content commonality such that the first database table of the second database schema may only contain data content records that already exist in the first database table of the first database schema. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
adding software programmed to enforce peer dataset content commonality such that the first database table of the third database schema may only contain data content records that already exist in the first database table of the first database schema. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
Claim 11. A method comprising:
using a computer processor to execute a data architecture modeling software program that defines and maintains a first data architecture model stored in a computer memory; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11, an IDDB database is a software for defining and maintain a first data architecture which is “a structure for relationships between sites collaborating on common activities, i.e. activity groups, and in particular how to propagate changes efficiently between the members of the activity group” and wherein each site includes a physical data model diagrams for each site specific database: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”)
wherein the first data architecture model includes a first independent physical data model diagram and a first dependent physical data model diagram; (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data related to each site and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and a site with a synchronized fragment of the record is considered as dependent)
wherein each of the first independent physical data model diagram and the first dependent physical data model diagram is architected to prevent redundant data instances in the first data architecture model; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, wherein redundancy is prevented by only synchronizing shared fragment of a dataset in a site with other sites while a fragment in which a site is not interested by other site remains unsynchronized: 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the first independent physical data model diagram is configured to be used by the data architecture modeling software program to architect a first independent database schema that functions as a single shared source of unique data content records for a first dependent database schema architected in the first dependent physical data model diagram; (7:41-52, 3:13-32, 4:22-33, 9:12-20, 58:59-67, 60:58-61:26, 70:46-73:16, using a source as a single source of data content records/record fragments depends on the need of a site for “selected information” to be synchronized with another site and wherein only shared fragment/columns of a dataset in a distributed database are synchronized as specified in design time, e.g., prior to dataset instantiation: 10:20-33, 91: 30-40, “Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites” 36: 26-37:31, “an activity is defined by one database record, termed the root activity record, and the activity comprises: (a) the root record; and (b) all (or a subset) of records that are related to the activity record. The related records are specified using path relationships of one-to-one, or one-to-many (but not many-to-one or many-to-many). It will be appreciated that the group of records is connected because there is a path to every such record that includes only records that are also part of the same activity. In the description of the application database 34, direction for the database schema is defined as “up” for the direction of the “one” end of all one-to-many relationships and “down” as the direction of the “many” end. Accordingly, an activity comprises the activity record and some or all related records beneath it (i.e. “down”) in the schema. It will also be understood that if one record in a table is an activity record, then all records in that table are activity records, and the table itself is known as an activity table…. Accordingly, distribution/replication rules will apply to the “kind” of activity, and advantageously the distribution/replication rules can be specified at design time and considered as part of the database schema”; 39: 36-51, 40:37-48: “For simplicity, the activity parts were described in terms of entire tables, but activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables. For example, there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabelled as part of the core activity”; 50:65-51-20, “The dTranslation table 128b belongs to the Design-Time tables 128 (FIG. 12). The dTranslation table 128b is populated at design time and records every tablename/fieldname…The translation utility for the IDDBMS uses this information (and other information) at runtime to manage all translation for all applications”; 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein, upon execution of forward-engineered dataset instantiation instructions from the first data architecture model, the first independent physical data model diagram forms the first independent database schema, and the first dependent physical data model diagram forms the first dependent database schema; (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data related to each site and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and a site with a synchronized fragment of the record is considered as dependent; a forward-engineered dataset instantiation is used because each specific site is populated according to the declared activities by a designer: 41:50-59, “The tables shown below include the minimum necessary fields, and other fields may be added as needed by the IDDBMS implementor based on the understanding of the present invention. In the following description it is to be understood that tables designated as "Design Time” refer to tables in which the content is preset by the database designer and therefore are considered to be part of the database structure which means that these tables are not to be modified at runtime”; 58:34-38, “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”)
wherein the first dependent database schema is dependent on the first independent database schema before these database schemas are populated with data records; (59: 59-60-19, distribution rules define dependency before data population: “The IDDB provides the application designer with the capability to declare distribution rules for each table… for activity tables the distribution rules are predefined and may not be overridden. For tables not under any activity, the default distribution rule is to replicate the complete contents globally to each site. For tables under an activity, the default distribution rule is to replicate the appropriate subset of its contents to every site participating in the shared activity. If an activity part is specified for the table, then the particular activity part is also replicated. Preferably, the application designer is able to override the default replication for the latter two cases by specifying that a table's contents be replicated ‘as needed'”)
and further comprising:
adding a first data table representation to the first independent physical data model diagram; (10:20-33, 5:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, 91: 30-401 data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the first independent physical data model diagram contains a first set of data table columns and a first unique key comprised of a first subset of one or more uniquely identifying data table columns of the first set of data table columns; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data table representation of the first independent physical data model diagram is architected to contain a first plurality of unique data instances, prior to any execution of forward-engineered dataset instantiation instructions for the first data table representation of the first independent physical data model diagram into the first dataset; and further comprising: (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 91:21-43, all sites, i.e. nodes, are peers includes their unique data instances in addition to shared common activities based on an agreement and assigned keys for replicating/synchronizing the common activities as specified at design time: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 91:21-43 , “Sites sharing the same data synchronize their changes periodically …changes made at one site become visible to all the other interested sites”)
adding a first peer dataset connector representation to the first dependent physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as specified at design time as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first peer dataset connector representation of the first dependent physical data model contains a first unique key comprised of a first copy of the first subset of one or more uniquely identifying data table columns of the first set of data table columns; and further comprising: (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
adding a first peer key constraint to the first data architecture model architected to constrain the first unique key of the first peer dataset connector representation of the first dependent physical data model diagram by the first unique key of the first data table representation of the first independent physical data model diagram, prior to any execution of forward-engineered dataset instantiation instructions of the first peer key constraint; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities as specified at design time: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein, upon execution of forward-engineered dataset instantiation instructions, the first peer key constraint forms a first data access path between the first independent database schema and the first dependent database schema; and (15:51-61, 36: 54-37:31, 61:30-37, shared data in each site is a common activity as specified at design time and 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, wherein only data identified as common activities, a subset of data, is selected as dataset connector for replication/synchronization as in 78: 78: 27-62 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein, after data records have been populated into the first independent database schema and into the first dependent database schema, the first data access path is configured to allow for directly joining and retrieving data records combined from the first independent database schema with data records from the first dependent database schema. (15:51-61, 36: 54-37:31, 61:30-37, shared data in each site is a common activity as specified at design time and 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, wherein only data identified as common activities, a subset of data, is selected as dataset connector for replication/synchronization directly as in 6:14-56, 78: 27-62, “The independent database according to the present invention also features the capability to replicate updates, so that any change made in an activity at a site becomes visible to all sites belonging to the activity group in that application network… updates are propagated. To do this efficiently, two sites must be able to agree on the “age' of each piece of data in the database, so that newer versions correctly update older ones without introducing unnecessary updates when both sites already have the same version of the data. Accordingly, the present invention includes mechanisms to allow fragment age agreement and accommodation of relative clock drift between sites, and the means for providing consistent local time stamping when there are several, and possibly inconsistent, local clocks at the same site”)
Claim 12. The method of claim 11
wherein the first data architecture model includes a second dependent physical data model diagram; (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site sharing a subset of data fields is associated with a first, second, third, etc., dependent physical model diagram)
wherein the second dependent physical data model diagram includes a second peer dataset connector representation with a first unique key; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first unique key of the second peer dataset connector representation is comprised of a second copy of the first subset of one or more uniquely identifying data table columns of the first set of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
and further comprising;
adding the second peer dataset connector representation to the first peer key constraint that constrains the first unique key of the second peer dataset connector representation of the second dependent physical data model diagram by the first unique key of the first data table representation of the first independent physical data model diagram; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the second peer dataset connector representation of the second dependent physical data model diagram is architected to contain a second subset of the first plurality of unique data instances of the first unique key of the first data table representation of the first independent physical data model diagram. (15:51-61, 36: 54-37:31, 61:30-37, shared data in each site is a common activity and 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, wherein only data identified as common activities, a subset of data, is selected as dataset connector for replication /synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
Claim 13. The method of claim 12
wherein the first data table representation of the first independent physical data model diagram is designated a first peer data registry representation in the computer memory using the data architecture modeling program for the first peer key constraint of the first data architecture model; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 70:46-73:16, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities; the assigned key based on an agreement is a registration for constraining each site to shared common data)
wherein the first peer data registry representation is architected as a single source of peer data content records for the first peer key constraint of the first data architecture model; (7:41-52, 3:13-32, 4:22-33, 9:12-20, 58:59-67, 60:58-61:26, 70:46-73:16, being a source as a single source of data content records depends on the need of a site for “selected information” to be synchronized with another site: “Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the first peer data registry representation is architected to enforce external referential data integrity for the first peer key constraint of the first data architecture model; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, wherein external referential data integrity is enforced because only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-41 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first dataset connector representation of the first dependent physical data model diagram is constrained by the first peer data registry of the first independent physical data model diagram; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the second dataset connector representation of the second dependent physical data model diagram is constrained by the first peer data registry of the first independent physical data model diagram. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
Claim 14. The method of claim 12
wherein the first data table representation of the first independent physical data model diagram includes a first primary key comprised of a second subset of one or more uniquely identifying data table columns of the first set of data table columns; (57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, keys are unique and sites connect for transmitting data based on the assigned primary/foreign keys)
wherein the first peer dataset connector representation of the first dependent physical data model diagram includes a second primary key comprised of a first copy of the second subset of one or more uniquely identifying data table columns of the first set of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
and further comprising;
adding a second data table representation to the first independent physical data model diagram that includes a first foreign key that inherits the data table columns of the first primary key of the first data table representation of the first independent physical data model diagram; (57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65 and 92:8-14, wherein multiple tables are related through primary/foreign keys)
wherein the first primary key of the first data table representation of the first independent physical data model diagram is architected to constrain the first foreign key of the second data table representation of the first independent physical data model diagram; (57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, keys are unique and sites connect for transmitting data based on the assigned primary/foreign keys and 92:8-14, wherein multiple tables are related through primary/foreign keys)
adding a third data table representation to the first dependent physical data model diagram that includes a first foreign key that inherits the data table columns of the second primary key of the first peer dataset connector representation; and (57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, keys are unique and sites connect for transmitting data based on the assigned primary/foreign keys and 92:8-14, wherein multiple tables are related through primary/foreign keys)
wherein the second primary key of the first peer dataset connector representation of the first dependent physical data model diagram is architected to constrain the first foreign key of the third data table representation of the first dependent physical data model diagram. (57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, keys are unique and sites connect for transmitting data based on the assigned primary/foreign keys and 92:8-14, wherein multiple tables are related through primary/foreign keys)
Claim 15. The method of claim 14
wherein the second peer dataset connector representation of the second dependent physical data model diagram includes a third primary key comprised of a second copy of the second subset of one or more uniquely identifying data table columns of the first set of data table columns; (Sutter, a first, second, third, etc., data connectors are all based on set of data fields of interest related through primary/foreign key relationship as in 57: 5-11; 58:34-59-11; 60:57-61:28, 76:4-36, 92: 3-14, wherein keys are unique and sites connect for transmitting data based on the assigned primary/foreign keys)
and further comprising;
modifying the first peer key constraint to constrain the second primary key coupled with the first unique key of the first peer dataset connector representation of the first dependent physical data model diagram and the third primary key coupled with the first unique key of the second peer dataset connector representation of the second dependent physical data model diagram with the first primary key coupled with the first unique key of the first data table representation of the first independent physical data model diagram; (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key)
wherein the first peer dataset connector representation of the first dependent physical data model diagram is architected to contain a subset of the data instances of the first primary key coupled with the first unique key of the first data table representation of the first independent physical data model diagram; and (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key in all sites, 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 76:20-36, sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
wherein the second peer dataset connector representation of the second dependent physical data model diagram is architected to contain a subset of the data instances of the first primary key coupled with the first unique key of the first data table representation of the first independent physical data model diagram. (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key in all sites, 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 76:20-36, sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
Claim 17. The method of claim 12
wherein the first data architecture model includes a second independent physical data model diagram; (15:51-61, 36: 54-37:31, 40:37-48, 59:5-11, 61:30-37, each site is associated with a physical data model diagram including independent model, e.g., data not shared and dependent model, e.g., data shared with other sites: “the application database 100 for the construction company comprises a collection of tables…each branch of the construction company maintains its own list of suppliers, and each project maintains its own internal estimates and purchase orders, and users may collaborate these…”; 93: 41-56, wherein in a related data configuration, a site with a complete set of records is considered as independent and a site with a synchronized fragment of the record is considered as dependent)
and further comprising;
adding a second data table representation to the second independent physical data model diagram containing a second set of data table columns; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the second data table representation of the second independent physical data model diagram contains a first primary key comprised of a first subset of one or more uniquely identifying data table columns of the second set of data table columns; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
adding a third peer dataset connector representation to the first dependent physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the third peer dataset connector representation of the first dependent physical data model diagram contains a second primary key comprised of a first copy of the first subset of one or more uniquely identifying data table columns of the second set of data table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
adding a second peer key constraint that constrains the second primary key of the third peer dataset connector representation of the first dependent physical data model diagram by the first primary key of the second peer data table representation of the second independent physical data model diagram; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein the third peer dataset connector representation of the first dependent physical data model diagram is architected to contain a first subset of a plurality of unique data instances of the first primary key of the second data table representation of the second independent physical data model diagram. (15:51-61, 36: 54-37:31, 61:30-37, shared data in each site is a common activity and 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, wherein only data identified as common activities, a subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
Claim 19. A method comprising:
using a computer processor to execute a first database management system program which forms and maintains a first data architecture schema stored in a computer memory; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, a database schema based on the defined table, data fields, etc., includes data fields used with each site and data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first data architecture schema includes a first independent database schema and a first dependent database schema related by a first peer dataset access path, prior to storing any data content in the first independent database schema and the first dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, a database schema based on the defined table, data fields, etc., includes data fields used with each site and data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first independent database schema includes a first database table that contains a first set of database table columns; 15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first database table contains a first unique key index comprised of a first subset of one or more uniquely identifying database table columns from the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers including their unique data instances in addition to shared common activities based on an agreement and assigned keys for replicating/ synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein the first dependent database schema includes an instantiated first peer dataset connector that contains a first copy of the first subset of one or more uniquely identifying database table columns from the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers including their unique data instances in addition to shared common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein the instantiated first peer dataset connector of the first dependent database schema contains a first unique key index comprised of the first copy of the first subset of one or more uniquely identifying database table columns from the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers including their unique data instances in addition to shared common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
and further comprising:
adding computer software to the computer memory, wherein the computer software, as executed by the computer processor, is configured to form the first peer dataset access path, prior to storing data content in the first independent database schema and the first dependent database schema in the computer memory by constraining the first unique key index of the first peer dataset connector of the first dependent database schema to contain a subset of a plurality of data content records of the first unique key index of the first database table of the first independent database schema before any of the plurality of data content records are stored in the first peer dataset connector of the first dependent database schema; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers including their unique data instances in addition to shared common activities based on an agreement and assigned keys for replicating/synchronizing the common activities as specified in design time: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields” 36: 26-37:31, “ an activity is defined by one database record, termed the root activity record, and the activity comprises: (a) the root record; and (b) all (or a subset) of records that are related to the activity record. The related records are specified using path relationships of one-to-one, or one-to-many (but not many-to-one or many-to-many). It will be appreciated that the group of records is connected because there is a path to every such record that includes only records that are also part of the same activity. In the description of the application database 34, direction for the database schema is defined as “up” for the direction of the “one” end of all one-to-many relationships and “down” as the direction of the “many” end. Accordingly, an activity comprises the activity record and some or all related records beneath it (i.e. “down”) in the schema. It will also be understood that if one record in a table is an activity record, then all records in that table are activity records, and the table itself is known as an activity table…. Accordingly, distribution/replication rules will apply to the “kind” of activity, and advantageously the distribution/replication rules can be specified at design time and considered as part of the database schema”; 50:65-51-20, “The dTranslation table 128b belongs to the Design-Time tables 128 (FIG. 12). The dTranslation table 128b is populated at design time and records every tablename/fieldname…The translation utility for the IDDBMS uses this information (and other information) at runtime to manage all translation for all applications”; 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the first dependent database schema is dependent on the first independent database schema; and (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, a shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site, 22: 51-61, “the IDDB 1 comprises a database which is distributed or spread over the sites belonging to the application network, and each site works independently on its own data…the IDDB includes a procedure for updating changes to fragments at different sites in the activity group…a fragment is a piece of an individual record and comprises a subset of columns in a record”, 40: 37-39, “activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables…there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”)
wherein the instantiated first peer dataset connector of the first dependent database schema is prevented from storing data redundant to that stored in the non-identifying database table columns of the first set of database table columns of the first database table of the first independent database schema. (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site: 91:26-40, “All sites in the IDDB, i.e. nodes, are peers…sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
Claim 20. The method of claim 19
wherein the first data architecture schema includes a second dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database is a first, second, third…dependent dataset to be replicated and synchronized with other sites)
wherein the second dependent database schema includes a first copy of the first peer dataset connector that contains a second copy of the first subset of one or more uniquely identifying database table columns from the first set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database is a first, second, third…dependent dataset to be replicated/copied and synchronized with other sites)
wherein the first copy of the first peer dataset connector of the second dependent database schema contains a first unique key index comprised of the second copy of the first subset of one or more uniquely identifying database table columns from the first set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database is a first, second, third…dependent dataset to be replicated/copied and synchronized with other sites; 40: 37-39, “activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables…there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”)
and further comprising:
adding computer software to the computer memory, wherein the computer software, as executed by the computer processor, is configured to add to the first peer dataset access path in the computer memory by constraining the first unique key index of the first copy of the first peer dataset connector of the second dependent database schema to contain a subset of the data content records of the first unique key index of the first database table of the first independent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database is a first, second, third…dependent dataset to be replicated/copied and synchronized with other sites; only defined subset data is accessed for replication and synchronization)
wherein the second dependent database schema is dependent on the first independent database schema. (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site, 22: 51-61, “the IDDB 1 comprises a database which is distributed or spread over the sites belonging to the application network, and each site works independently on its own data…the IDDB includes a procedure for updating changes to fragments at different sites in the activity group…a fragment is a piece of an individual record and comprises a subset of columns in a record”, 40: 37-39, “activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables…there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”)
Claim 21. The method of claim 20 and further comprising:
adding a first plurality of unique data content records to the first database table of the first independent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site and wherein only defined shared fragment can be modified and synchronized with other site: 74:4-67, “If the same fragment is updated at two different and possibly distant sites, the IDDB preferably includes procedures for determining which fragment should take precedence, and procedures for attempting to detect and log collisions”)
adding a first subset of the first plurality of unique data content records to the first peer dataset connector of the first dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site and wherein only defined shared fragment can be modified and synchronized with other site: 74:4-67, “If the same fragment is updated at two different and possibly distant sites, the IDDB preferably includes procedures for determining which fragment should take precedence, and procedures for attempting to detect and log collisions”)
wherein the first database table of the first independent database schema functions as a single source of non-identifying database table columns of the first set of database table columns for reference by the first peer dataset connector of the first dependent database schema using the first peer dataset access path; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site: 91:26-40, “All Sites in the IDDB, i.e. nodes, are peers…Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
and further comprising:
adding a second subset of the first plurality of unique data content records to the first copy of the first dataset connector of the second dependent database schema; and (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site and wherein only defined shared fragment can be modified and synchronized with other site: 74:4-67, “If the same fragment is updated at two different and possibly distant sites, the IDDB preferably includes procedures for determining which fragment should take precedence, and procedures for attempting to detect and log collisions”)
wherein the first database table of the first independent database schema functions as a single source of non-identifying database table columns of the first set of database table columns for reference by the first copy of the first peer dataset connector of the second dependent database schema using the first peer dataset access path. (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while a fragment in which a site is not interested in is a non-identifying fragment for the site: 91:26-40, “All Sites in the IDDB, i.e. nodes, are peers…Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
Claim 22. The method of claim 20
wherein the first data architecture schema includes a second independent database schema and a second peer dataset access path relating the second independent database schema to the first dependent database schema and to the second dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, each site in a distributed database is an independent site with defined table, data fields, etc., including data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the second independent database schema includes a second database table that contains a second set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, each site in a distributed database is an independent site with defined table, data fields, etc., including data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the second database table contains a second unique key index comprised of a first subset of one or more uniquely identifying database table columns from the second set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, each site in a distributed database is an independent site with defined table, data fields, etc., including data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
and further comprising:
adding a second peer dataset connector to the first dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56 40: 37-39, in a distributed database system any site can be connected to a site for replicating and synchronizing a required fragment: 40: 37-39, “activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables…there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”)
wherein the second peer dataset connector of the first dependent database schema contains a second unique key index comprised of a first copy of the first subset of one or more uniquely identifying database table columns from the second set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database including certain data fields to be replicated and synchronized with other sites; only defined subset data is accessed for replication and synchronization)
adding a first copy of the second peer dataset connector to the second dependent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database including certain data fields to be replicated and synchronized with other sites; only defined subset data is accessed for replication and synchronization)
wherein the first copy of the second peer dataset connector of the second dependent database schema contains a second unique key index comprised of a second copy of the first subset of one or more uniquely identifying database table columns from the second set of database table columns; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, any defined fragment of a dataset in a distributed database includes certain data fields to be replicated and synchronized with other sites; all sites, i.e. nodes, are peers sharing common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: 58:34-67, “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
and further comprising:
adding computer software to the computer memory, wherein the computer software, as executed by the computer processor, is configured to form the second peer dataset access path in the computer memory by constraining the second unique key index of the second peer dataset connector of the first dependent database schema to contain a subset of the data content records of the second unique key index of the second database table of the second independent database schema; (7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56 40: 37-39, in a distributed database system any site can be connected to a site for replicating and synchronizing a required fragment: 40: 37-39, “activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables…there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabeled as part of the core activity”)
wherein the first dependent database schema is dependent on the second independent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site and wherein only defined shared fragment can be modified and synchronized with other site: 74:4-67, “If the same fragment is updated at two different and possibly distant sites, the IDDB preferably includes procedures for determining which fragment should take precedence, and procedures for attempting to detect and log collisions”)
adding computer software to the computer memory, wherein the computer software, as executed by the computer processor, is configured to add to the second peer dataset access path in the computer memory by constraining the second unique key index of the first copy of the second peer dataset connector of the second dependent database schema to contain a subset of the data content records of the second unique key index of the second database table of the second independent database schema; (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 91:26-40, 93: 41-56, only shared fragment of a dataset in a distributed database is synchronized with other sites while: 91:26-40, “All Sites in the IDDB, i.e. nodes, are peers…Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”)
wherein the second dependent database schema is dependent on the second independent database schema. (7: 41-52, 9:12-20, 15:51-61, 22: 51-61, 36: 26-37:31, 40: 37-39, 58:34-67, 59:5-11, 60:58-61:26, 74:4-67, 93: 41-56, any shared fragment of a dataset in a distributed database is a dependent of the dataset in each independent site and wherein only defined shared fragment can be modified and synchronized with other site: 74:4-67, “If the same fragment is updated at two different and possibly distant sites, the IDDB preferably includes procedures for determining which fragment should take precedence, and procedures for attempting to detect and log collisions”)
Claim 24. The method of claim 20
wherein each of the first independent database schema, the first dependent database schema, and the second dependent database schema has a database schema name that is unique within the first data architecture schema; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first database table of the first independent database schema includes a first database table name that is a unique database table name within the first independent database schema; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first peer dataset connector of the first dependent database schema has a second database table name that is a unique database table name within the first dependent database schema; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first copy of the first peer dataset connector of the second dependent database schema has a third database table name that is a unique database table name within the second dependent database schema; and(15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first database table name, the second database table name, and the third database table name are the same. (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 57:4-60:65, 59:5-11, 61:30-37, data definition includes a table name and fields name for each first, second, third…site, sharing common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
Claim 25. The method of claim 20 further comprising
adding a first primary key index to the first database table of the first independent database schema comprised of a second subset of one or more uniquely identifying database table columns of the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
adding a second database table to the first independent database schema with a second set of database table columns that includes a first copy of the second subset of one or more uniquely identifying database table columns of the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
wherein the first copy of the second subset of one or more uniquely identifying database table columns of the first set of database table columns is a first foreign key index of the second database table; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
wherein a first foreign key constraint of the first independent database schema constrains the first foreign key index of the second database table with the first primary key index of the first database table; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
and further comprising;
adding a third database table to the first dependent database schema comprised of a third set of database table columns that includes a second copy of the first subset of one or more uniquely identifying database table columns of the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
wherein the second copy of the first subset of one or more uniquely identifying database table columns of the first set of database table columns is a first foreign key index of the third database table of the first dependent database schema; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
wherein a first foreign key constraint of the first dependent database schema constrains the first foreign key index of the third database table with the first unique key index of the first peer dataset connector. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
Claim 26. The method of claim 25 further comprising
adding a first primary key index to the first peer dataset connector of the first dependent database schema comprised of a first copy of the second subset of one or more uniquely identifying database table columns of the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
adding a first primary key index to the first copy of the peer dataset connector of the second dependent database schema comprised of a second copy of the second subset of one or more uniquely identifying database table columns of the first set of database table columns; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”)
and further comprising:
modifying the first peer dataset access path by constraining the first primary key index coupled with the first unique key index of the first peer dataset connector of the first dependent database schema to contain a subset of the data content records of the first primary key index coupled with the first unique key index of the first database table of the first dependent database schema; and (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”; 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key)
modifying the first peer dataset access path by constraining the first primary key index coupled with the first unique key index of the first copy of the first peer dataset connector of the second dependent database schema to contain a subset of the data content records of the first primary key index coupled with the first unique key index of the first database table of the first dependent database schema. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”, 92:8-14, “the term “related” is used in the context of multiple tables or multiple records means by a foreign-key relationship. “Directly related tables/records” means tables/records related directly by a single foreign key relationship. “Indirectly related tables/records” means tables/records related directly by traversing multiple foreign key relationships and the corresponding intervening tables/records”; 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key)
Claim 27. The method of claim 19
using a computer processor to execute a second database management system program which accesses the first data architecture schema stored in computer memory; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11, a first data architecture model is “a structure for relationships between sites collaborating on common activities, i.e. activity groups, and in particular how to propagate changes efficiently between the members of the activity group” and wherein each site includes a physical data model diagrams for each site specific database: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”)
wherein the first data architecture schema includes a second independent database schema and a second dependent database schema related by a second peer dataset access path; (15:51-61, 36: 54-37:31, 61:30-37, data definition includes a table defining data fields in each site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the second dependent database schema includes a first copy of the first peer dataset connector; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first independent database schema and the first dependent database schema are managed by the first database management system; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
wherein the second independent database schema and a second dependent database schema are managed by the second database management system; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
and further comprises:
modifying the first peer dataset access path to relate the first independent database schema to the second dependent database schema; and (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
wherein the second dependent database schema is dependent on the first independent database schema and the second independent database schema. and (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 7:41-52, “the IDDB according to the present invention provides a means for operating inherently incompatible commercially available Database Management Systems (DBMS). According to this aspect of the invention, the IDDB utilizes a DBMS-independent channel, for example, ODBC (Open Database Connectivity), for accessing the database product, and the IDDB separates the distribution and Security controls from the physical database. This feature allows existing database management Systems (DBMSs), such as, ORACLETM, INGRESTM, SYBASETM, PARADOXTM and ACCESSTM products, to be used together transparently at different sites on the same application network in the IDDB”, 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4-9, 16 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable over Sutter in view of IDS provided reference Scanzano et al., Pub. No.: US 2003/0046272 A1 (Scanzano).
Claim 4. Sutter teaches:
The method of claim 1
wherein the first data architecture model includes a first logical entity relationship; (15:51-61, 58:34-38, 36: 54-37:31, 61:30-37, tables relationships and path relationships of one-to-one, or one-to-many shows logical relationship between entities)
wherein the first logical entity relationship contains a first plurality of data entities; (15:51-61, 36: 54-37:31, 61:30-37, path relationships of one-to-one, or one-to-many shows relationship between entities, 37: 16-31, “an activity is easy to describe because every activity is rooted, i.e., utilizing the sense of direction described above, the paths from the single activity record (the root of the activity) to the connected records (i.e. one-to-one and one-to-many) are easily navigated”)
wherein the first plurality of data entities includes a first data entity; (15:51-61, 36: 54-37:31, 61:30-37, path relationships of one-to-one, or one-to-many shows relationship between entities, 37: 16-31, “an activity is easy to describe because every activity is rooted, i.e., utilizing the sense of direction described above, the paths from the single activity record (the root of the activity) to the connected records (i.e. one-to-one and one-to-many) are easily navigated”)
wherein the first data entity of the first logical entity relationship contains a first plurality of data attributes; (15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data entity of the first logical entity relationship contains a first unique key comprised of one or more of the first plurality of data attributes; and (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
wherein each of the first data table representation of the first physical data model diagram and the first data table representation of the second physical data model diagram, and the first data table representation of the third physical model diagram is an analog derived from the first data entity of the first logical entity relationship. (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
Sutter did not specifically teach the logical entity relationship as logical entity relationship diagram.
Scanzano teaches logical entity relationship as logical entity relationship diagram. (Scanzano, ¶ 9, “In database design, it may be desirable to create multiple relationships. A multiple relationship is one where entries in a given table may have a one-to-many relationship to entries in several other tables. Such a relationship can be designed using conventional database schema design methods, as illustrated by the entity relationship diagrams in FIGS. 2A and 2B. The ERDs in FIG. 2A illustrate a multiple one-to-many relationship and in FIG. 2B illustrate a multiple many-to-many”)
Sutter discloses that a database designer is able to use utilities provided by IDDBMS for declaring each database table, including its relationship with other tables, primary keys, distribution rules, etc., as in Sutter, 58: 34-38, 59:6-11, 60: 57-65, 61:30-37. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing logical entity relationship as logical entity relationship diagram because doing so would further increase usability of Sutter by explicitly providing for a database designer to use “entity relationship diagrams” for achieving the same predictable result of declaring each database table, including its relationship with other tables, primary keys, etc.
Claim 5. The method of claim 4
wherein each data entity of the first plurality of data entities includes a data entity name that is a unique data entity name within the first logical entity relationship diagram; (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
wherein the first data entity of the first logical entity relationship diagram includes a first unique data entity name; (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
wherein the first data table representation of the first physical data model diagram has a first data table name that is a unique data table name within the first physical data model diagram; (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
wherein the first data table representation of the second physical data model diagram has a first data table name that is a unique data table name within the second physical data model diagram; and ; (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
wherein the first data table representation of the third physical data model diagram has a first data table name that is a unique data table name within the third physical data model diagram; and (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
wherein each of the first data table name of the first data table representation of the first physical data model diagram and the first data table name of the first data table representation of the second physical data model diagram, and the first data table name of the first data table representation of the third physical data model diagram is an analog derived from the first data entity name of the first data entity of the first logical entity relationship diagram. (Sutter, 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 and wherein shared activity data is uniquely identifiable in each site; Scanzano, ¶ 9)
Claim 6. The method of claim 5
wherein the data entity name of the first data entity of the first logical entity relationship diagram and the first data table name of the first data table representation of the first physical data model diagram, the first data table name of the first data table representation of the second physical data model diagram, and the first data table name of the first data table representation of the third physical data model diagram have the same name. (Sutter, 5:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes in each site as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 that can be synchronized as in 6:30-41; Scanzano, ¶ 9)
Claim 7. The method of claim 4
wherein each of the first plurality of data table columns of the first data table representation of the first physical data model diagram and each of the second plurality of data table columns of the first data table representation of the second physical data model diagram is an analog derived from the first plurality of data attributes of the first data entity of the first logical entity relationship diagram; and (Sutter, 5:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes in each site as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 that can be synchronized as in 6:30-41; Scanzano, ¶ 9)
wherein each of the first unique key of the first data table representation of the first physical data model diagram, the first unique key of the first data table representation of the second data model diagram, and the first unique key of the first data table representation of the third data model diagram is an analog derived from the first unique key of the first data entity of the first logical entity representation diagram. (Sutter, 5:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes in each site as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30 that can be synchronized as in 6:30-41; Scanzano, ¶ 9)
Claim 8. The method of claim 4
wherein the first data table representation of the first physical data model diagram contains a primary key comprised of one or more of the first plurality of data table columns; (Sutter, 57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
and further comprising:
adding a second data table representation to the first physical data model diagram; (Sutter, 57: 5-11; 58:34-59-11; 60:57-61:28, 92: 3-14, tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in 70:42-65)
wherein the second data table representation inherits a copy of the data table columns of the primary key of the first data table representation of the first physical data model diagram as a first foreign key of the second data table representation; (Sutter, 92:3-14, multiple tables are related through primary/foreign keys)
adding a first foreign key constraint to the first physical data model diagram that constrains the foreign key of the second data table representation of the first physical data model diagram with the primary key of the first data table representation of the first physical data model diagram. (Sutter, 92:3-14, multiple tables are related through primary/foreign keys and data from multiple tables are shared based on the sites interested in the common activities as in Sutter, 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26)
Claim 9. The method of claim 8
wherein the first data table representation of the second physical data model diagram contains a primary key comprised of one or more of the second plurality of data table columns; (Sutter, 72: 45-73:7, 76:20-36, a table generated in sites sharing data has multiple unique keys)
and further comprising:
modifying the first peer key constraint of the first data architecture model to form a first coupled peer key constraint; (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key for each site)
wherein the first data table representation of the third physical data model diagram contains a primary key comprised of one or more of the first plurality of data table columns; (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key for each site)
wherein the primary key coupled with the first unique key of the first data table representation of the first physical data model diagram constrains the primary key coupled with the first unique key of the first data table representation of the second physical data model diagram; and (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key for each site, 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 76:20-36, sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
wherein the primary key coupled with the first unique key of the first data table representation of the first physical data model diagram constrains the primary key coupled with the first unique key of the first data table representation of the third physical data model diagram. (Sutter, 72: 45-73:7, a concatenation of parent keys or a key associated with unique information is a unique coupled key for each site, 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, 76:20-36, sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities)
Claim 16. Sutter teaches:
The method of claim 12
wherein the first data architecture model includes a first logical entity relationship; (15:51-61, 58:34-38, 36: 54-37:31, 61:30-37, tables relationships and path relationships of one-to-one, or one-to-many shows logical relationship between entities)
wherein the first logical entity relationship contains a first plurality of data entities; (15:51-61, 36: 54-37:31, 61:30-37, path relationships of one-to-one, or one-to-many shows relationship between entities, 37: 16-31, “an activity is easy to describe because every activity is rooted, i.e., utilizing the sense of direction described above, the paths from the single activity record (the root of the activity) to the connected records (i.e. one-to-one and one-to-many) are easily navigated”)
wherein the first plurality of data entities includes a first data entity; (15:51-61, 36: 54-37:31, 61:30-37, path relationships of one-to-one, or one-to-many shows relationship between entities, 37: 16-31, “an activity is easy to describe because every activity is rooted, i.e., utilizing the sense of direction described above, the paths from the single activity record (the root of the activity) to the connected records (i.e. one-to-one and one-to-many) are easily navigated”)
wherein the first data entity includes a first data entity name that is a unique data entity name within the first plurality of data entities of the first logical entity relationship; 15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data entity of the first logical entity relationship contains a first plurality of data attributes; (15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first data entity of the first logical entity relationship contains a first unique key comprised of one or more of the first plurality of data attributes; and (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
wherein each of the first data table representation of the first independent physical data model diagram, the first peer dataset connector representation of the first dependent physical data model diagram, and the second peer dataset connector representation of the second dependent physical data model diagram are analogs derived from the first data entity of the first logical entity relationship; (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65 )
wherein each of the first data table representation, the first peer dataset connector representation, and the second peer dataset connector representation have the same data table name which is an analog derived from the data entity name of the first data entity of the first logical entity relationship; (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65 )
wherein the data table name of the first data table representation is a unique data table name within the first independent physical data model diagram; (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
wherein the data table name of the first peer dataset connector representation is a unique data table name within the first dependent physical data model diagram; and (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
wherein the data table name of the second dependent representation is a unique data table name within the second dependent physical data model diagram. (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
Sutter did not specifically teach the logical entity relationship as logical entity relationship diagram.
Scanzano teaches logical entity relationship as logical entity relationship diagram. (¶ 9, “In database design, it may be desirable to create multiple relationships. A multiple relationship is one where entries in a given table may have a one-to-many relationship to entries in several other tables. Such a relationship can be designed using conventional database schema design methods, as illustrated by the entity relationship diagrams in FIGS. 2A and 2B. The ERDs in FIG. 2A illustrate a multiple one-to-many relationship and in FIG. 2B illustrate a multiple many-to-many”)
Sutter discloses that a database designer is able to use utilities provided by IDDBMS for declaring each database table, including its relationship with other tables, primary keys, distribution rules, etc., as in Sutter, 58: 34-38, 59:6-11, 60: 57-65, 61:30-37. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing logical entity relationship as logical entity relationship diagram because doing so would further increase usability of Sutter by explicitly providing for a database designer to use “entity relationship diagrams” for achieving the same predictable result of declaring each database table, including its relationship with other tables, primary keys, etc.
Claim 23. Sutter teaches:
The method of claim 22 further comprising:
using a computer processor to execute a data architecture modeling program that accesses a first data architecture model stored in a computer memory; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11, a first data architecture model is “a structure for relationships between sites collaborating on common activities, i.e. activity groups, and in particular how to propagate changes efficiently between the members of the activity group” and wherein each site includes a physical data model diagrams for each site specific database: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”)
wherein the first data architecture model includes a first logical entity relationship; (15:51-61, 58:34-38, 36: 54-37:31, 61:30-37, tables relationships and path relationships of one-to-one, or one-to-many shows logical relationship between entities)
wherein the first logical entity relationship contains a first data entity; (15:51-61, 36: 54-37:31, 61:30-37, path relationships of one-to-one, or one-to-many shows relationship between entities, 37: 16-31, “an activity is easy to describe because every activity is rooted, i.e., utilizing the sense of direction described above, the paths from the single activity record (the root of the activity) to the connected records (i.e. one-to-one and one-to-many) are easily navigated”)
wherein the first data entity contains a first plurality of data attributes and a first unique key comprised of one or more identifying data attributes of the first plurality of data attributes; (15:51-61, 36: 54-37:31, 61:30-37, shared common activities included in tables having names and columns/data attributes as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
and further comprising:
adding a first physical data model diagram to the first data architecture model that contains a first data table representation that is a derived analog of the first data entity of the first logical entity relationship; (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
wherein the first database table of the first independent database schema is a derived analog of the first data table representation of the first physical data model diagram; (59:26-60:16, 69:56-70:52, 76: 32-36, shared activity data is uniquely identifiable in each site; tables, primary/foreign keys are defined for each site and a created key is unique across the entire database as in Sutter, 70:42-65)
adding a second physical data model diagram to the first data architecture model that contains a first peer dataset connector representation that is a derived analog of the first data entity of the first logical entity relationship; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first peer dataset connector of the first dependent database schema is a derived analog of the first peer dataset connector representation of the second physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
adding a third physical data model diagram to the first data architecture model that contains a first copy of the first dataset connector representation that is a derived analog of the first data entity of the first logical entity relationship; (15:51-61, 36: 54-37:31, 37:56-38:22, 40:37-48, 59:5-11, 61:30-37, data definition includes a table defining data fields in each first, second, third…site, shared common activities included in tables having names and columns as in 42:45-60, 51:5-20, 59:26-59, 60:58-65, 64:25-32, 76:20-30)
wherein the first copy of the first peer dataset connector of the second dependent database schema is a derived analog of the first copy of the peer dataset connector representation of the third physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
adding a first peer key constraint to the first data architecture diagram that constrains the first peer dataset connector of the second physical data model diagram and the first copy of the first peer dataset connector of the third physical data model diagram by the first data table representation of the first physical data model diagram; (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, all sites, i.e. nodes, are peers; sites/peers share common activities based on an agreement and assigned keys for replicating/synchronizing the common activities: “The IDDB provides the application designer with the facility to declare each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
wherein the first peer dataset access path of the first data architecture schema is a derived analog of the first peer key constraint of the first data architecture model. (7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities, a unique subset of data, is selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
Sutter did not specifically teach the logical entity relationship as logical entity relationship diagram.
Scanzano teaches logical entity relationship as logical entity relationship diagram. (Scanzano, ¶ 9, “In database design, it may be desirable to create multiple relationships. A multiple relationship is one where entries in a given table may have a one-to-many relationship to entries in several other tables. Such a relationship can be designed using conventional database schema design methods, as illustrated by the entity relationship diagrams in FIGS. 2A and 2B. The ERDs in FIG. 2A illustrate a multiple one-to-many relationship and in FIG. 2B illustrate a multiple many-to-many”)
Sutter discloses that a database designer is able to use utilities provided by IDDBMS for declaring each database table, including its relationship with other tables, primary keys, distribution rules, etc., as in Sutter, 58: 34-38, 59:6-11, 60: 57-65, 61:30-37. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for disclosing logical entity relationship as logical entity relationship diagram because doing so would further increase usability of Sutter by explicitly providing for a database designer to use “entity relationship diagrams” for achieving the same predictable result of declaring each database table, including its relationship with other tables, primary keys, etc.
Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over Sutter in view of Zečević et al, “Model driven development of hybrid databases using lightweight metamodel extensions” (Zečević).
Claim 18. Sutter teaches:
The method of claim 12
wherein a first physical data environment specification is added to the first independent physical data model diagram that specifies a first database schema into which contents of the first independent physical data model diagram is configured to be dataset instantiated; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”; 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
wherein a second physical data environment specification is added to the first dependent physical data model diagram that specifies a second database schema into which contents of the first dependent physical data model is configured to be dataset instantiated; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”; 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
wherein a third physical data environment specification is added to the second dependent physical data model diagram that specifies a third database schema into which contents of the second dependent physical data model diagram is configured to be dataset instantiated; (7: 41-52, 15:51-61, 36: 26-37:31, 58:34-38, 59:5-11 each site database schema is within provided architecture for “an independent distributed database…IDDB” as in 10:16-50, based on the defined table, data fields, etc., sharing certain data fields as defined and performing database operations: 59:5-11: “The IDDB provides the application designer with the capability to declare the activities, i.e. activity tables and each activity's activity parts (and the interrelationships between tables if one activity is under another activity). Each activity part is defined by some subset of the tables that are part of the same activity”; 11:10-27, “The IDDB application network 20 comprises a head office 22, branch offices 24 and individual office workstations 26 or mobile users 28. Head office 22…running a DB2M database, or the like, which contains the entire database for the organization…Branch offices 24… running an Oracle data base or the like. The individual workstations 26…run Paradox database or the like… the global activity contains user and site database information, global user permissions… The information in a global activity is used at all sites”)
and further comprising:
using the data architecture modeling program to forward-engineer a first set of description of contents of the first independent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
using the data architecture modeling program to forward-engineer a second set of description of contents of the first dependent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
using the data architecture modeling program to forward-engineer a third set of description of contents of the second dependent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”)
and further comprising:
using a database management program and the first set of SQL DDL to dataset instantiate a first database schema containing a first database table that contains a first set of database table columns and the first unique key index; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first database table is a derived analog of the first data table representation contained in the first independent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
using the database management program and the second set of SQL DDL to dataset instantiate a second database schema containing a first peer dataset connector that contains one or more uniquely identifying database table columns and a first unique key index; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56) 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the first peer dataset connector is a derived analog of the first peer dataset connector representation contained in the first dependent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
using the database management program and the third set of SQL DDL to dataset instantiate a third database schema containing a second peer dataset connector that contains one or more uniquely identifying database table columns and a first unique key index; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
wherein the second peer dataset connector is a derived analog of the second peer dataset connector representation contained in the second dependent physical data model diagram; (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
and further comprising:
adding computer software configured to ensure that each of the first unique key index of the first peer dataset connector of the second database schema and the first unique key index of the second peer dataset connector of the third database schema contains a subset of the data content records of the first unique key index of the first database table of the first database schema. (54:45-59:11, wherein description of contents of each sites is forwarded by through DC Language for generating databases accordingly: “the distribution control (DC) information is treated as part of the database schema… the DC information includes a description of the tables for the database and the relationships between the tables; the allocated ID's the IDDBMS will use as keys, and which tables use the keys, the activities and activity parts, along with the basic permissions that apply to each activity or activity part; the distribution rules for each table; and selective encryption rules for specific columns of the database”; wherein DC Language is used for declaring “a unique database name…each database table, including its relationships with other tables, primary keys, distribution rules, activity participation including basic permissions if it is an activity table, and encryption rules for sensitive fields”; 7: 41-52, 9: 12-20, 58:59-67, 60:58-61:26, only data identified as common activities are selected as dataset connector for replication/synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56)
Sutter did not disclose but Zečević discloses generating Standard Query Language Data Definition Language (SQL DDL) script at p. 1224 in order to create a database schema.
Sutter discloses that a database designer is able to use utilities provided by IDDBMS for declaring each database table, including its relationship with other tables, primary keys, distribution rules, etc., as in Sutter, 58: 34-38, 59:6-11, 60: 57-65, 61:30-37. It would have been obvious before the effective filling date of the claimed invention to a person having ordinary skill in the art to combine the applied references for generating Standard Query Language Data Definition Language (SQL DDL) script for creating a database schema as an alternative for achieving the same predictable result of “declaring each database table, including its relationship with other tables, primary keys, distribution rules” in Sutter.
Response to Amendment and Arguments
Applicant’s arguments have been considered but are not persuasive for at least the following reasons.
With respect to claim 1, Applicant argues: “Claim 1 of the present application specifies in part "removing redundant data table columns". In the example above, one might remove the "column" "Email" if for some reason it is redundant. There is no suggestion anywhere in Sutter of removing a "column" from a "data architecture model" "before one or more datasets are instantiated". There is no suggestion anywhere in Sutter of " deleting any nonidentifying data table columns from the first data table representation of the second physical data model diagram". There is no suggestion anywhere in Sutter of "deleting any nonidentifying data table columns from the first data table representation of the third physical data model diagram". There is no suggestion anywhere in Sutter of performing various steps "after the step of deleting the nonidentifying data table columns from the first data table representations of the second and third physical data models". In fact, Sutter expressly states: " ... sites in the IDBB operate as though the database in not fragmented at all, because for each site its local copy of a table is the whole table.” (Sutter, col. 5, Ins. 36-38)”… Sutter, over and over again, discloses "deletion" of records… Sutter never discloses deleting a "column" of a "data architecture model" "before one or more datasets are instantiated". So for example, Sutter's teaching would never lead one skilled in the art to delete the "column" 'Email" (or any other column) in a "data architecture model".” Remarks, 31-33.
In response: a data record, a fragment of a data record, and a table, all comprise data fields, e.g. columns: Sutter 6: 57-63, “A record fragment according to the present invention is a piece of an individual record, and comprises a subset of columns in a record”. Sutter 40:37-48, “For simplicity, the activity parts were described in terms of entire tables, but activity parts can also be defined as a subset of the columns (specifically, one or more complete fragments) from one or more tables. For example, there may exist a table under the Project activity 104 in which the first fragment of every record is of interest only to estimators, the second fragment is of interest to both estimators and purchasers, and all users need the third fragment. The first fragment is labelled as part of the ESTIMATING activity part, the second fragment is labelled as part of both the ESTIMATING and PURCHASING parts, and the third fragment is left unlabelled as part of the core activity”.
As applicant noted, “if for some reason” a column is redundant then it is removed. Evidently, each site includes a needed fragment, meaning redundant columns are not included in a fragment: Sutter 5:36-41: “Each site…will by definition have some fragment of the database, defined by the information its users need”.
Apparently, Applicant interpreted “sites in the IDBB operate as though the database in not fragmented at all, because for each site its local copy of a table is the whole table” in Sutter 5:36-41 such that there exist some redundant columns in “the whole table”. However, it is explicitly disclosed that each site includes only columns/fragment it needs: Sutter, 4:22-33, “Each site stores “all and only” the data it needs…Sites sharing the same data synchronize their changes periodically in the background and changes made at one site become visible to all the other interested sites”; 91:21-43, “All Sites in the IDDB, i.e. nodes, are peers…Each site stores “all and only” the data it needs…”. 22: 51-61, “the IDDB 1 comprises a database which is distributed or spread over the sites belonging to the application network, and each site works independently on its own data. To propagate changes made to the database, the IDDB includes a procedure for updating changes to fragments at different sites in the activity group. In the context of the present invention, a fragment is a piece of an individual record and comprises a subset of columns in a record”.
Furthermore, only shared fragment/columns of a dataset in a distributed database as specified in design time is synchronized with other sites, meaning a fragment comprising certain columns in which a site is not interested in is a non-identifying fragment for that site and therefore is not included e.g., removed from the site and not synchronized with the site: Sutter, 36: 26-37:31, “ an activity is defined by one database record, termed the root activity record, and the activity comprises: (a) the root record; and (b) all (or a subset) of records that are related to the activity record. The related records are specified using path relationships of one-to-one, or one-to-many (but not many-to-one or many-to-many). It will be appreciated that the group of records is connected because there is a path to every such record that includes only records that are also part of the same activity. In the description of the application database 34, direction for the database schema is defined as “up” for the direction of the “one” end of all one-to-many relationships and “down” as the direction of the “many” end. Accordingly, an activity comprises the activity record and some or all related records beneath it (i.e. “down”) in the schema. It will also be understood that if one record in a table is an activity record, then all records in that table are activity records, and the table itself is known as an activity table…. Accordingly, distribution/replication rules will apply to the “kind” of activity, and advantageously the distribution/replication rules can be specified at design time and considered as part of the database schema”; Sutter, 50:65-51-20, “The dTranslation table 128b belongs to the Design-Time tables 128 (FIG. 12). The dTranslation table 128b is populated at design time and records every tablename/fieldname…The translation utility for the IDDBMS uses this information (and other information) at runtime to manage all translation for all applications”.
With respect to claim 1, Applicant argues “Neither the Sutter reference, nor the Scanzano reference, nor the Zecevic et al. reference, nor any other reference disclose limitations of present claim 11 specifying in detail how various structures of a database are architected "prior to any execution of forward-engineered dataset instantiation instructions". Remarks, 40.
In response, Applicant's arguments fail to comply with 37 CFR 1.111 (b) because they amount to a general allegation that the amended claims define a patentable invention without specifically pointing out how the language of the claims patentably distinguishes them from the references. As shown above, the applied references teach all limitations as recited in claims 1-27, including claim 11.
With respect to claim 19, Applicant argues: “Claim 19 specifies in part, "wherein the first dependent database schema is dependent on the first independent database schema". The present application discloses in one embodiment, "independent peer database schema 730" (present application, pg. 44, second paragraph, last sentence) and "dependent peer database schemas 760 and 780" (present application, pg. 45, fourth line). The present application also states: "Likewise, instantiated dependent peer database schemas are usually dependent on several different instantiated independent peer database schemas", present application pg. 111, last paragraph). Sutter, in contrast states expressly: " Autonomy. According to the present invention, the sites are fully independent of each other and also independent of the communications link. (Sutter, col. 5, Ins. 24-26)”. Remarks, 43.
In response, being an independent site in view of a user of the site for dealing with only the needed local data fields/columns is not in contrast with sharing certain columns of the site with a second site, e.g. a dependent site because the second site is interested in the shared columns as in Sutter, 3: 12-32, 4: 21-32, 7: 41-52, 9:12-20, 15:51-61, 36: 26-37:31, 58:34-67, 59:5-11, 60:58-61:26, 93: 41-56, wherein a database schema based on the defined table, data fields, etc., includes data fields used with each site and data fields/activity parts shared with other sites for being accessed for data replication and synchronization; only data identified as common activities is selected as dataset connector for replication /synchronization as in 78: 33-35 and sites connections are based on their interest of common activities to be synchronized as in 16: 39-56.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohsen Almani whose telephone number is (571)270-7722. The examiner can normally be reached on M-F, 9 AM-5 PM, ET.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Ann J. Lo can be reached on 571-272-9767. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHSEN ALMANI/Primary Examiner, Art Unit 2159