SFDC 1008
`SFDC 1008
`
`
`
`

`
`Chart
`
`Claim Chart of Kathleen A. Peters, “The Design of a Change Notification Server for Clients of a
`Passive Object-Oriented Database Management System” (July 1992) (“Peters”)
`
`as prior art to
`
`Asserted Claims of U.S. Patent No. 7,356,482 (“the ‘482 Patent”)
`
`
`
`‘482 Patent
`Claim 1
`A system for providing a
`dynamically generated
`application having one or
`more functions and one or
`more user interface
`elements; comprising:
`
`PETERS THESIS
`
`To the extent that this preamble is construed to be limiting, Peters
`discloses a system for providing a dynamically generated
`application having one or more functions and one or more user
`interface element. See, e.g.:
`
`Peters at Abstract:
`
`“The major contributions of this thesis are its focus on object-
`oriented (as opposed to relational) data change, the design of a
`change notification server, and the description of a language used
`by clients to specify conditions of interest to monitor for change.
`Further, we present a model of version management, and describe
`how our notification server can complement an application where
`clients are versioning data.”
`
`Peters at § 4.2 (“Railway Network Application”):
`
`“This application is the less-than-real-time operation of a simple
`railway monitoring and control system. Given a database
`containing a description of the railway network (e.g., I stations,
`track segments connecting stations), train schedules (e.g., routes
`through the network), and active train information (e.g., location,
`speed), various DB client processes monitor and offer control
`options for the movement of trains in the network.”
`
`Peters at § 4.3 (“Document Co-Authoring Application”):
`
`“When a user is updating the text of an existing paragraph
`(generally, a long-term update), the DB object cannot be write-
`locked as this would delay concurrent reads. To allow concurrent
`reads and inform other users that the text is changing, the client
`process wanting to change a paragraph first performs a short-term
`update to set the specific paragraph’s ‘text-under-mod’ variable to
`true. The notification server is informed by the client who
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`[a] a server computer;
`
`
`PETERS THESIS
`performed the change that a committed update to ‘text-undermod’
`took place. This information is passed on to interested clients
`(those who have issued the condition specification [I] above).
`When the updated text is committed some time later, interested
`clients are informed (again via [I] above). If the ‘text-under-mod’
`variable is now false, then another client may begin a long-term
`text update; otherwise, the first client still has exclusive update
`access, but has chosen to let others see an intermediate result. , A
`non-conflicting concurrent update is allowed when a client is
`updating the text of a paragraph and another client wishes to
`change the ‘next-p’ variable of that paragraph (inserting a new
`paragraph, or rearranging paragraph order). The change to ‘next-p’
`is a short-term update. The update- counter variable is used by the
`client process doing the long-term update to determine that a
`change has occurred to ‘next-p’ if notification does not reach it
`before the text update is committed.”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses a server computer. See, e.g.:
`
`Peters at Abstract:
`
`“This thesis presents a comprehensive design specification for an
`object-oriented database management system (OODBMS) change
`notification server. Objectstore is used as the example underlying
`OODBMS.
`
`The major contributions of this thesis are its focus on object-
`oriented (as opposed to relational) data change, the design of a
`change notification server, and the description of a language used
`by clients to specify conditions of interest to monitor for change.
`Further, we present a model of version management, and describe
`how our notification server can complement an application where
`clients are versioning data.”
`
`Peters at § 5.2:
`
`“All message passing between DB client processes and the
`notification server is done asynchronously.”
`
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`[b] one or more client
`computers connected to the
`server computer over a
`computer network;
`
`PETERS THESIS
`Peters at § 8.3 (including Figure 8-9):
`
`“To review, clients send one or more condition specifications to
`the notification server to indicate what DB changes they wish to
`be notified of, and they send a DB update event message to the
`notification server for each change made to application data after
`the change has been committed to the OODBMS. The notification
`server sends an acknowledge message to clients for each condition
`specification it receives, and the server sends a notification
`message to clients for each change they have indicated an interest
`in.”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses one or more client computers connected to the
`server computer over a computer network. See, e.g.:
`
`Peters at Abstract:
`
`“One way to aid database clients in detecting change to shared
`data is to provide a notification mechanism which informs clients
`when the data they have an interest in has changed. Previous
`research has focused primarily on embedding change notification
`schemes in a database management system (DBMS).
`
` .
`
` . .
`
`
`The major contributions of this thesis are its focus on object-
`oriented (as opposed to relational) data change, the design of a
`change notification server, and the description of a language used
`by clients to specify conditions of interest to monitor for change.
`Further, we present a model of version management, and describe
`how our notification server can complement an application where
`clients are versioning data.”
`
`Peters at § 4.2 (“Railway Network Application”):
`
`“The client processes for this application are graphic user
`interfaces (GUIs) for train operators and station operators. There is
`one train operator GUI process for each active train. Each train
`operator GUI provides the following functions:
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`- display up-to-date train information (speed limit, current speed,
`current location, schedule)
`- ask for, and receive, permission to enter or leave a station
`- update current speed and/or location of the train. There are three
`station operator GUI processes: a master process which monitors
`the entire railway network and controls train schedules, and two
`region processes (west and east) which monitor subsections of the
`network and control the tracks and trains within their field of
`view. A station GUI provides some or all of the following
`functions (depending on whether the GUI is a master or a regional
`process):
`- display up-to-date network information (network diagram; train
`speed, location and direction of travel for each train)
`- receive requests, and grant permission, for trains to enter or leave
`a station
`- update train schedule
`- update train speed limit
`- update track segment status (open, closed)”
`
`Peters at § 4.3 (“Document Co-Authoring Application”):
`
`“When a user is updating the text of an existing paragraph
`(generally, a long-term update), the DB object cannot be write-
`locked as this would delay concurrent reads. To allow concurrent
`reads and inform other users that the text is changing, the client
`process wanting to change a paragraph first performs a short-term
`update to set the specific paragraph’s ‘text-under-mod’ variable to
`true. The notification server is informed by the client who
`performed the change that a committed update to ‘text-undermod’
`took place. This information is passed on to interested clients
`(those who have issued the condition specification [I] above).
`When the updated text is committed some time later, interested
`clients are informed (again via [I] above). If the ‘text-under-mod’
`variable is now false, then another client may begin a long-term
`text update; otherwise, the first client still has exclusive update
`access, but has chosen to let others see an intermediate result. , A
`non-conflicting concurrent update is allowed when a client is
`updating the text of a paragraph and another client wishes to
`change the ‘next-p’ variable of that paragraph (inserting a new
`paragraph, or rearranging paragraph order). The change to ‘next-p’
`is a short-term update. The update- counter variable is used by the
`client process doing the long-term update to determine that a
`change has occurred to ‘next-p’ if notification does not reach it
`before the text update is committed.”
`
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`
`Peters at § 5.2:
`
`“All message passing between DB client processes and the
`notification server is done asynchronously.”
`
`Peters at § 8.3 (including Figure 8-9):
`
`“To review, clients send one or more condition specifications to
`the notification server to indicate what DB changes they wish to
`be notified of, and they send a DB update event message to the
`notification server for each change made to application data after
`the change has been committed to the OODBMS. The notification
`server sends an acknowledge message to clients for each condition
`specification it receives, and the server sends a notification
`message to clients for each change they have indicated an interest
`in.”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses a first layer associated with the server computer
`containing information about the unique aspects of a particular
`application. See, e.g.:
`
`Peters at § 4.2 (“Railway Network Application”):
`
`“The client processes for this application are graphic user
`interfaces (GUIs) for train operators and station operators. There is
`one train operator GUI process for each active train. Each train
`operator GUI provides the following functions:
`- display up-to-date train information (speed limit, current speed,
`current location, schedule)
`- ask for, and receive, permission to enter or leave a station
`- update current speed and/or location of the train. There are three
`station operator GUI processes: a master process which monitors
`the entire railway network and controls train schedules, and two
`region processes (west and east) which monitor subsections of the
`network and control the tracks and trains within their field of
`view. A station GUI provides some or all of the following
`functions (depending on whether the GUI is a master or a regional
`process):
`- display up-to-date network information (network diagram; train
`
`[c] a first layer associated
`with the server computer
`containing information
`about the unique aspects of
`a particular application;
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`speed, location and direction of travel for each train)
`- receive requests, and grant permission, for trains to enter or leave
`a station
`- update train schedule
`- update train speed limit
`- update track segment status (open, closed)”
`
`Peters at § 4.3 (“Document Co-Authoring Application”):
`
`“The client processes for this application are graphic user
`interfaces (GUIs) that allow users
`to display and edit documents.”
`
` .
`
` . .
`
`
`“When a user is updating the text of an existing paragraph
`(generally, a long-term update), the DB object cannot be write-
`locked as this would delay concurrent reads. To allow concurrent
`reads and inform other users that the text is changing, the client
`process wanting to change a paragraph first performs a short-term
`update to set the specific paragraph’s ‘text-under-mod’ variable to
`true. The notification server is informed by the client who
`performed the change that a committed update to ‘text-undermod’
`took place. This information is passed on to interested clients
`(those who have issued the condition specification [I] above).
`When the updated text is committed some time later, interested
`clients are informed (again via [I] above). If the ‘text-under-mod’
`variable is now false, then another client may begin a long-term
`text update; otherwise, the first client still has exclusive update
`access, but has chosen to let others see an intermediate result. , A
`non-conflicting concurrent update is allowed when a client is
`updating the text of a paragraph and another client wishes to
`change the ‘next-p’ variable of that paragraph (inserting a new
`paragraph, or rearranging paragraph order). The change to ‘next-p’
`is a short-term update. The update- counter variable is used by the
`client process doing the long-term update to determine that a
`change has occurred to ‘next-p’ if notification does not reach it
`before the text update is committed.”
`
`Peters at § 9.1 (“Conclusions”), e.g.:
`
`“The major contributions of this thesis are as follows:
`
`(1) examination of object-oriented (as opposed to relational)
`change notification.
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`
`
`In fact, we have examined relational change notification because
`its requirements are a subset of the requirements for object-
`oriented change notification. Relational DBMSs have tables
`whose data changes through row insert, update, and delete,
`while OODBMSs have classes whose data changes through
`instance insert, update, and delete. Whether DB update events,
`condition specification, and change notification are focused on
`tables or classes, our basic design remains the same.
`
`However, OODBMSs differ significantly from relational DBMSs
`in that OODBMSs must support complex inheritance hierarchies
`and aggregation hierarchies. This work makes an important
`contribution by examining, in detail, condition specification and
`change notification for these hierarchies.
`
`(2) description of a flexible and sufficient language for specifying
`conditions of interest to monitor for change in an OODBMS.
`We have combined aspects of both active queries and imperative
`rules so that DB clients can specify exactly what kinds of changes
`they are interested in. We have designed the language so that
`clients can easily specify an entire inheritance or aggregation
`hierarchy with one condition specification.
`We have allowed application-oriented functions to be a part of the
`language definition so that condition specification can be tailored
`to the needs of particular applications.
`
`(3) design of a change notification server which is informed of
`committed data change by DB clients (i.e., the server does not
`have to intervene between clients and the OODBMS to detect
`change), and then notifies clients who have registered their interest
`in the change.
`
`(4) presentation of a version management model, and a detailed
`examination of how our server design can be extended to handle
`notification of change to versioned data.
`
`We have added a second set of DB update event, condition
`specification, and notification messages to the design to address
`version-level change. The basic design, which addresses data-
`object-level change, is essentially the same for both versioned and
`non-versioned DB schema.
`
`We have grouped clients within a version unit by requiring them
`to focus on one branch of the version graph at a time. Then, the
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`[d] a second layer
`associated with the server
`computer containing
`information about the user
`interface and functions
`common to a variety of
`applications,
`
`PETERS THESIS
`condition specifications a client sends to the notification server do
`not have to specify which work in progress (WIP) version to
`monitor for change. The WIP version is given by a client’s
`current group membership, and if that group membership is
`changed, the server can automatically adjust the focus of a client’s
`active condition specifications.
`
`We have shown that a centralized OODBMS change notification
`server is possible, that the interface between DB clients and the
`notification server can be simple but effective (i.e., there are a
`small number of messages, and message content is relatively
`simple to generate and interpret), and that condition specification
`can be dynamic (i.e., clients can issue and cancel condition
`specifications at any time).”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses a second layer associated with the server
`computer containing information about the user interface and
`functions common to a variety of applications. See, e.g.:
`
`Peters at § 4.2 (“Railway Network Application”), e.g.:
`
`“The client processes for this application are graphic user
`interfaces (GUIs) for train operators and station operators. There is
`one train operator GUI process for each active train. Each train
`operator GUI provides the following functions:
`- display up-to-date train information (speed limit, current speed,
`current location, schedule)
`- ask for, and receive, permission to enter or leave a station
`- update current speed and/or location of the train. There are three
`station operator GUI processes: a master process which monitors
`the entire railway network and controls train schedules, and two
`region processes (west and east) which monitor subsections of the
`network and control the tracks and trains within their field of
`view. A station GUI provides some or all of the following
`functions (depending on whether the GUI is a master or a regional
`process):
`- display up-to-date network information (network diagram; train
`speed, location and direction of travel for each train)
`- receive requests, and grant permission, for trains to enter or leave
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`
`a station
`- update train schedule
`- update train speed limit
`- update track segment status (open, closed)”
`
`Peters at § 4.3 (“Document Co-Authoring Application”), e.g.:
`
`“The client processes for this application are graphic user
`interfaces (GUIs) that allow users
`to display and edit documents.”
`
`Peters at § 4.3 (“Document Co-Authoring Application”):
`
`“When a user is updating the text of an existing paragraph
`(generally, a long-term update), the DB object cannot be write-
`locked as this would delay concurrent reads. To allow concurrent
`reads and inform other users that the text is changing, the client
`process wanting to change a paragraph first performs a short-term
`update to set the specific paragraph’s ‘text-under-mod’ variable to
`true. The notification server is informed by the client who
`performed the change that a committed update to ‘text-undermod’
`took place. This information is passed on to interested clients
`(those who have issued the condition specification [I] above).
`When the updated text is committed some time later, interested
`clients are informed (again via [I] above). If the ‘text-under-mod’
`variable is now false, then another client may begin a long-term
`text update; otherwise, the first client still has exclusive update
`access, but has chosen to let others see an intermediate result. , A
`non-conflicting concurrent update is allowed when a client is
`updating the text of a paragraph and another client wishes to
`change the ‘next-p’ variable of that paragraph (inserting a new
`paragraph, or rearranging paragraph order). The change to ‘next-p’
`is a short-term update. The update- counter variable is used by the
`client process doing the long-term update to determine that a
`change has occurred to ‘next-p’ if notification does not reach it
`before the text update is committed.”
`
`Peters at § 9.1 (“Conclusions”), e.g.:
`
`“The major contributions of this thesis are as follows:
`
`(1) examination of object-oriented (as opposed to relational)
`change notification.
`
`In fact, we have examined relational change notification because
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`its requirements are a subset of the requirements for object-
`oriented change notification. Relational DBMSs have tables
`whose data changes through row insert, update, and delete,
`while OODBMSs have classes whose data changes through
`instance insert, update, and delete. Whether DB update events,
`condition specification, and change notification are focused on
`tables or classes, our basic design remains the same.
`
`However, OODBMSs differ significantly from relational DBMSs
`in that OODBMSs must support complex inheritance hierarchies
`and aggregation hierarchies. This work makes an important
`contribution by examining, in detail, condition specification and
`change notification for these hierarchies.
`
`(2) description of a flexible and sufficient language for specifying
`conditions of interest to monitor for change in an OODBMS.
`We have combined aspects of both active queries and imperative
`rules so that DB clients can specify exactly what kinds of changes
`they are interested in. We have designed the language so that
`clients can easily specify an entire inheritance or aggregation
`hierarchy with one condition specification.
`We have allowed application-oriented functions to be a part of the
`language definition so that condition specification can be tailored
`to the needs of particular applications.
`
`(3) design of a change notification server which is informed of
`committed data change by DB clients (i.e., the server does not
`have to intervene between clients and the OODBMS to detect
`change), and then notifies clients who have registered their interest
`in the change.
`
`(4) presentation of a version management model, and a detailed
`examination of how our server design can be extended to handle
`notification of change to versioned data.
`
`We have added a second set of DB update event, condition
`specification, and notification messages to the design to address
`version-level change. The basic design, which addresses data-
`object-level change, is essentially the same for both versioned and
`non-versioned DB schema.
`
`We have grouped clients within a version unit by requiring them
`to focus on one branch of the version graph at a time. Then, the
`condition specifications a client sends to the notification server do
`not have to specify which work in progress (WIP) version to
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`[e] a particular application
`being generated based on
`the data in both the first and
`second layers;
`
`PETERS THESIS
`monitor for change. The WIP version is given by a client’s
`current group membership, and if that group membership is
`changed, the server can automatically adjust the focus of a client’s
`active condition specifications.
`
`We have shown that a centralized OODBMS change notification
`server is possible, that the interface between DB clients and the
`notification server can be simple but effective (i.e., there are a
`small number of messages, and message content is relatively
`simple to generate and interpret), and that condition specification
`can be dynamic (i.e., clients can issue and cancel condition
`specifications at any time).”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses a particular application being generated based on
`the data in both the first and second layers. See, e.g.:
`
`Peters at § 4.2 (“Railway Network Application”):
`
`“The client processes for this application are graphic user
`interfaces (GUIs) for train operators and station operators. There is
`one train operator GUI process for each active train. Each train
`operator GUI provides the following functions:
`- display up-to-date train information (speed limit, current speed,
`current location, schedule)
`- ask for, and receive, permission to enter or leave a station
`- update current speed and/or location of the train. There are three
`station operator GUI processes: a master process which monitors
`the entire railway network and controls train schedules, and two
`region processes (west and east) which monitor subsections of the
`network and control the tracks and trains within their field of
`view. A station GUI provides some or all of the following
`functions (depending on whether the GUI is a master or a regional
`process):
`- display up-to-date network information (network diagram; train
`speed, location and direction of travel for each train)
`- receive requests, and grant permission, for trains to enter or leave
`a station
`- update train schedule
`- update train speed limit
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`- update track segment status (open, closed)”
`
`Peters at § 9.1 (“Conclusions”), e.g.:
`
`“The major contributions of this thesis are as follows:
`
`(1) examination of object-oriented (as opposed to relational)
`change notification.
`
`In fact, we have examined relational change notification because
`its requirements are a subset of the requirements for object-
`oriented change notification. Relational DBMSs have tables
`whose data changes through row insert, update, and delete,
`while OODBMSs have classes whose data changes through
`instance insert, update, and delete. Whether DB update events,
`condition specification, and change notification are focused on
`tables or classes, our basic design remains the same.
`
`However, OODBMSs differ significantly from relational DBMSs
`in that OODBMSs must support complex inheritance hierarchies
`and aggregation hierarchies. This work makes an important
`contribution by examining, in detail, condition specification and
`change notification for these hierarchies.
`
`(2) description of a flexible and sufficient language for specifying
`conditions of interest to monitor for change in an OODBMS.
`We have combined aspects of both active queries and imperative
`rules so that DB clients can specify exactly what kinds of changes
`they are interested in. We have designed the language so that
`clients can easily specify an entire inheritance or aggregation
`hierarchy with one condition specification.
`We have allowed application-oriented functions to be a part of the
`language definition so that condition specification can be tailored
`to the needs of particular applications.
`
`(3) design of a change notification server which is informed of
`committed data change by DB clients (i.e., the server does not
`have to intervene between clients and the OODBMS to detect
`change), and then notifies clients who have registered their interest
`in the change.
`
`(4) presentation of a version management model, and a detailed
`examination of how our server design can be extended to handle
`notification of change to versioned data.
`
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`[f] a third layer associated
`with the server computer
`that retrieves the data in the
`first and second layers in
`order to generate the
`functionality and user
`interface elements of the
`application; and
`
`PETERS THESIS
`We have added a second set of DB update event, condition
`specification, and notification messages to the design to address
`version-level change. The basic design, which addresses data-
`object-level change, is essentially the same for both versioned and
`non-versioned DB schema.
`
`We have grouped clients within a version unit by requiring them
`to focus on one branch of the version graph at a time. Then, the
`condition specifications a client sends to the notification server do
`not have to specify which work in progress (WIP) version to
`monitor for change. The WIP version is given by a client’s
`current group membership, and if that group membership is
`changed, the server can automatically adjust the focus of a client’s
`active condition specifications.
`
`We have shown that a centralized OODBMS change notification
`server is possible, that the interface between DB clients and the
`notification server can be simple but effective (i.e., there are a
`small number of messages, and message content is relatively
`simple to generate and interpret), and that condition specification
`can be dynamic (i.e., clients can issue and cancel condition
`specifications at any time).”
`
`To the extent this reference does not teach this claim element, this
`reference in combination with the knowledge of one of ordinary
`skill in the art and the disclosures of each of the prior art
`references provided in Salesforce’s Petitions related to the ‘482
`and ‘111 Patents renders this claim element obvious.
`Peters discloses a third layer associated with the server computer
`that retrieves the data in the first and second layers in order to
`generate the functionality and user interface elements of the
`application. See, e.g.:
`
`Peters at § 2.3:
`
`“The following is a brief description of Object Design’s
`OODBMS, ObjectStore. For a more detailed description, see
`[LOW91]. ObjectStore’s DBMS functionality is divided between
`two processes: the ObjectStore Server which stores and retrieves
`pages of data (with no knowledge of the contents of the page), and
`a Cache Manager which handles query and DBMS processing.
`There is one ObjectStore Server running on each workstation
`where disk storage is maintained, and there is one Cache Manager
`running on each workstation where client processes exist that
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`access ObjectStore data.”
`
`Peters at § 4.2 (“Railway Network Application”):
`
`“The client processes for this application are graphic user
`interfaces (GUIs) for train operators and station operators. There is
`one train operator GUI process for each active train. Each train
`operator GUI provides the following functions:
`- display up-to-date train information (speed limit, current speed,
`current location, schedule)
`- ask for, and receive, permission to enter or leave a station
`- update current speed and/or location of the train. There are three
`station operator GUI processes: a master process which monitors
`the entire railway network and controls train schedules, and two
`region processes (west and east) which monitor subsections of the
`network and control the tracks and trains within their field of
`view. A station GUI provides some or all of the following
`functions (depending on whether the GUI is a master or a regional
`process):
`- display up-to-date network information (network diagram; train
`speed, location and direction of travel for each train)
`- receive requests, and grant permission, for trains to enter or leave
`a station
`- update train schedule
`- update train speed limit
`- update track segment status (open, closed)”
`
`Peters at § 8.3 (including Figure 8-9):
`
`“To review, clients send one or more condition specifications to
`the notification server to indicate what DB changes they wish to
`be notified of, and they send a DB update event message to the
`notification server for each change made to application data after
`the change has been committed to the OODBMS. The notification
`server sends an acknowledge message to clients for each condition
`specification it receives, and the server sends a notification
`message to clients for each change they have indicated an interest
`in.”
`
`Peters at § 9.1 (“Conclusions”), e.g.:
`
`“The major contributions of this thesis are as follows:
`
`(1) examination of object-oriented (as opposed to relational)
`change notification.
`
`SFDC 1008
`
`

`
`‘482 Patent
`
`PETERS THESIS
`
`
`In fact, we have examined relational change notification because
`its requirements are a subset of the requirements for object-
`oriented change notification. Relational DBMSs have tables
`whose data changes through row insert, update, and delete,
`while OODBMSs have classes whose data changes through
`instance insert, update, a