Synchronizing/updating local client notes with annotations previously made by other clients in a notes database6687878Abstract A system for collaborative document annotation whereby notes (i.e. annotations) associated with a document, such as an image or text document, are stored in a notes database on a central notes server. The documents and associated annotations are treated independently from each other whereby separate data structures are created for the documents and for the associated annotations. A web server application on the server side functions to capture requests from one or more note client applications for creating, storing, editing and retrieving annotations related to specific documents stored on the notes server. On the client side, the notes client functions to display the document that the user wishes to annotate and provides the tools necessary to permit the user to create, edit, delete, retrieve and store notes. A synchronization process transmits the annotations generated by the user from the notes client to the notes server. In response, the notes server transmits back an acknowledgement along with any new notes that other notes clients may have posted since the last synchronization was performed thus enabling multiple notes clients to annotate a document asynchronously with respect to each other. When annotations are posted to the notes server by a notes client, the state of the annotation database is synchronized such that all other notes clients can retrieve the current, up to date annotations associated with a document. Claims What is claimed is: Description FIELD OF THE INVENTION
Term Definition
GMT Greenwich Mean Time
HTML Hypertext Text Markup Language
HTTP Hypertext Transport Protocol
IIS Internet Information Server
IP Internet Protocol
ISAPI Internet Server Application Programming Interface
LAN Local Area Network
MIME Multipurpose Internet Mail Extension
NFS Network File System
PDF Portable Document Format
RAM Random Access Memory
RGB Red Green Blue
SMTP Simple Mail Transport Protocol
SQL Structured Query Language
TCP Transport Control Protocol
TIFF Tag Image File Format
URL Universal Resource Locator
WAN Wide Area Network
WWW World Wide Web
The following terminology and definitions apply throughout this document.
Term Definition
Annotation A portion of text or a graphical drawing that is associated
(Note) with a specific location in a document.
Annotation The time period during which a user creates, edits,
Session retrieves and stores one or more notes associated with
a document.
Note Alarms Notifications that the Notes Server received a Note
Event.
Note Anchor The specific location in a document associated with a
note.
Note Client The application that displays the annotated document
and allows for annotation sessions.
Note Contents The text or graphical information contained in the note.
Note Identifier for documents and sets of aggregated
Document ID documents organized under the same logical structure.
Note Event A message related to a note that did not exist at the time
of the last synchronization with the Notes Server, or a
note that was modified or deleted since that time.
Note Identifier used to differentiate between notes generated
Owner ID by various users.
Note Mechanism whereby the Notes Clients saves the Note
Persistence Events to the local file system, allowing for
synchronization at a later time.
Note Serial A number uniquely identifying a note.
Number
Note Server The application that provides the centralized
role of document and note management.
Note The update activity whereby one or more Note Events
Synchroniza- are exchanged between the Notes Server and
tion the Notes Client.
Note Time The time stamp saved on the Notes Server, stored
Stamp using time zone of the Notes Server.
Notes The database maintained by the Notes Server holding
Database all note related information.
Notes Log A transactional history of Notes Events.
General Description The present invention is a system for collaborative document annotation whereby notes or annotations associated with a document are stored on a web server. Examples of documents include, but are not limited to, images, text documents or documents expressed in a page description language such as Postscript or Adobe PDF. In addition, each document may contain more than one page, wherein each page is annotated independently of the other. The documents and associated annotations are treated independently from each other. Separate data structures are created for the documents and for the associated annotations thus permitting their independent management. The invention can be implemented as software, a portion of which executes on the server side and a portion executes on the client side. The server side may comprise a plurality of software applications running in parallel that in combination provide the server functionality of the invention. A web server application on the server side functions to capture special request from one or more client applications for creating, storing, editing and retrieving annotations related to specific documents located in the server. A notes server functions to log all annotation activities along with information about the corresponding clients that create, edit and retrieve them. Illustrations of an example image displayed with and without multiple annotations displayed thereon are shown in FIGS. 1A, 1B and 1C. The system of the present invention is suitable for use with a variety of document types, including text and image based documents. For illustrative purposes, the following description uses an image type document to illustrate the principles of the invention. This is not meant to limit the scope of the invention. One skilled in the computer and software arts can apply the system the invention to other document types as well without departing from the spirit and scope of the present invention. In FIG. 1A, the display 10 is shown comprising a single document window 12 in which an image is displayed. No annotations are displayed in this view. In FIG. 1B, the display 10 is shown comprising a single document window 14 in which an image is displayed with a plurality of annotations 16. The annotations 16 are displayed over the image but are not a part of the image itself. In FIG. 1C, the display 10 is shown comprising two portions: the image window 18 and a Note List window 20. The image window 18 displays the image with the plurality of annotations 16 on top of the image. The Note List window 20 displays a list of all the annotations associated with the image shown in window 18. The user can optionally sort the Note List by Note Owner ID, Note Time Stamp, Note color label and Note Contents. The display may include Note Event description, Note Owner ID, user name, path, originator IP address, time and Note Contents. When a note is selected on the Note List, its counterpart icon in the document window frame is highlighted. An illustration of an example annotation is shown in FIG. 2. The annotation, generally referenced 30, comprises a window having a title portion 32 and text portion 34. The window contains a note label (Sam), Note Owner ID or login name (Acme) and the data and time of the most recent synchronization. A block diagram illustrating the collaborative document annotation system of the present invention is shown in FIG. 3. The annotation system, generally referenced 40, comprises one or more standard web browsers 42 labeled web browser #1 through web browser #N. Each web browser comprises a Note Plug-In component 44 that loads into the browser. The web browser 42 may comprise any suitable browser such as Netscape Navigator or Microsoft Internet Explorer. Each web browser in combination with the Note Plug-In is referred to as a Notes Client 41 and is the tool used for browsing the documents located on the server side. The Note Plug-In is invoked each time the browser gets a response from the Web Server 54 with a particular Multipurpose Internet Mail Extension (MIME) identifier. The communication protocol between Notes Clients and Notes Server is standard Hyper Text Transport Protocol (HTTP). The web browsers are adapted to communicate over a global TCP/IP network such as the Internet 46. The web browsers 42 and the Notes Server 58 communicate with the web server 54 via the HTTP protocol. The server portion of the system 40 comprises a web server 54 with integrated Note Agent 56, Notes Server 58 coupled to a Notes Database 60, a Document File Server 62 and a messaging system 52, a Notes Administrator 50 and a Notes Viewer 48. The Notes Server communicates with the Notes Database via any suitable database language/protocol such as SQL. The Notes Server communicates with the messaging system via standard SMTP. Annotation (Note) An annotation or note is a portion of text or a graphical drawing that is associated with a specific location in a document. The terms annotation and note are intended to mean the same thing and are used interchangeably throughout this document. The location associated with a note in the document is called a Note Anchor and is kept separate from the annotation data itself. Once a note is created, its anchor point can be changed by the user. The note anchor is expressed in terms of (X, Y) coordinates in the annotated page of a document. A note anchor may be set to a coordinate value of (0, 0) if the document associated with the note is a logical folder. Note that the annotation can be displayed within its own window or can be layered on top of the displayed document. The first option is used in the case of text only annotations. The second option is used for mixed text and graphical annotations. Notes Client The application that displays the annotated document and allows for annotation sessions is called the Note Client and comprises the web browser 42 and Note Plug-In 44. In order to differentiate between notes generated by various users, each user chooses a unique user ID that forms a Note Owner identifier. The Note Owner ID is formed from a combination of the chosen user name and user login name used when logging on to the annotation system. The unique Note Owner ID is displayed in the note window title bar 32 (FIG. 2) or when the Note Client application shows note properties for a graphical note, i.e., a note not within a window. Notes are associated with specific documents that are stored on the server side. A note can belong to one document or to a set of documents aggregated under the same logical structure. Documents are document aggregations are identified by their Note Document ID. The Note Document ID is a unique Universal Resource Locator (URL) on the World Wide Web. It is important to note that the client portion of the annotation system of the present invention is not limited to implementation via a web browser and associated plug in. The invention can be implemented using any suitable means including, but not limited to, stand alone clients that implement the same functionality without the use of a web browser and/or plug-in software component. Notes Server The Notes Server 58 functions to provide the central document and note management features. Normally the Notes Server functions in conjunction with a web server 54. It may access documents that reside in its own file system or that reside on remote file servers 62 located within the local area network. In addition, the Notes Server 58 may access these file servers and file systems by means of network file system protocols (represented by arrow 70). Once accessed, their contents are transmitted to the Notes Client Applications via TCP/IP protocols over communication means such as LAN, WAN or the Internet 46. Note that the invention may be implemented to operate over an Intranet, e.g., LAN, or Extranet, e.g., WAN or the Internet. An Annotation Session starts when a user logs onto the Web Server 54 by supplying a user name (user ID) and password. The Notes Server 58 requests this information when the user browsers to a protected URL, which is the URL of a document to be viewed and/or annotated. The Notes Server 58 associates the user name and password with the IP address of the request for identification purposes later in the Annotation Session. A session terminates when no activity is sensed by the Notes Server 58 for more than a predetermined period of time. Note that no special logout procedure is required to end an Annotation Session. The document protection mechanism can be set in combination with the web server security and the document file system security. The Notes Server assigns a unique Note Serial Number upon the creation of each note. This number serves to uniquely identify each note in the system. A Note Event is defined as a message related to a note that did not exist at the time of the last synchronization with the Notes Server or a note that was modified or deleted since that time. Note that, at the client side, the user is permitted to create new notes, modify the contents of notes, modify the anchor points of notes and delete notes. Only users with sufficient privileges, however, can modify notes. The system can be configured such that users without sufficient privileges are not permitted to view specific notes or to change them. It is important to note that the server portion of the annotation system of the present invention is not limited to implementation using a web server. The invention can be implemented using any suitable means including, but not limited to, a stand-alone HTTP server that implements the same functionality without the use of a web server. In addition, the invention is not limited to any specific client/server protocol implementation, e.g., HTTP. Notes Synchronization Note Events are exchanged between the server and the clients. Notes Clients forward to the Notes Server requests to view, modify, create or delete notes. In response, the Notes Server Updates the clients with an up to date note list per document. This updating activity is termed Note Synchronization. The synchronization process is performed asynchronously and is always initiated by the Notes Client in response to the user, i.e., it is user driven. Alternatively, the synchronization process can be initiated by the Notes Client in a periodic manner, i.e., polling, or by the Notes Server when the exchange protocol in use allows for it. In the former case, the client would continuously poll the server. Utilizing Java in the server, rather than HTTP, permits the server to trigger the client and update the client display, if permitted to, since it is not practical for the server to poll clients. The server pushes new notes to selected clients by triggering them to pull new notes from the server. This serves to simulate a user pressing a synchronization button. This service can be provided for those clients that request it. Note that although the description contained herein refers to the user driven synchronization process, the scope of the invention is intended to include other processes as well, such as server polling and server initiated synchronization via protocol means. If the user elects to exit the display and annotation application or chooses to display and annotate another document without synchronization the previous one, the Notes Client application saves the Note Events to the local file system. The next time the user browses to the same URL using the Notes Client application, these events can be synchronized. Thus, the system allows for Note Persistence on the client side. The Notes Server can be implemented as a process running on the web server computer. Alternatively, it is a process running on a separate computer that communicates with the web server. In either case, its functionality is the same. It is responsible for processing note events and maintaining the Notes Database and the Notes Log. The protocol the Notes Server utilizes is based on the well-known HTTP protocol. The Notes Server generates two independent HTTP streams: the first stream is for the displayed image and the second stream is for the annotations. Note again that alternatively, the invention can use any TCP/IP based protocol such as Java rather than HTTP. The time of modification (in local client time) is stored as part of the Note Event. The Notes Server ignores the locally generated time stamp and records the time (in server time) of arrival for the event in the Notes Database and the Notes Log. The time stamp is termed the Note Time Stamp. The Notes Server calculates the difference between its own clock and the client clock to obtain the time zone of the client each time a Notes Synchronization is initiated at the client side. The time the Notes Client displays to the user for each event is the Note Time Stamp that was saved in the Notes Server adjusted to the local time zone of the client. The administrator or other users (i.e. clients) of the Notes Server may elect to be notified each time a Note Event is received by the Notes Server. The notification can be made using any suitable means of notification including, but not limited to visual alarms, audible alarms and/or automatic e-mail messaging sent to the administrator or the user of the system. These notification alerts are termed Note Alarms and are useful for document management workflow. Alarm notifications can be generated in accordance with various criteria including the type of Note Event, type of document. In addition, filtering may be performed on a user basis or on a document basis. Notes Server and Notes Database On the Web Server 54, special address aliasing is provided by means of the Note Agent 56. The Note Agent 56 may be implemented as a Web Server Internet Server Application Programming Interface (ISAPI) filter or as a Web Server extension, both techniques being well known in the computer networking arts. All requests to aliased URLs are processed by the Note Agent 56 that in turn transfers the requests to the Notes Server 58. The Notes Server 58 may reside in the same computer as the Web Server 54 computer or may reside in another computer located on the Local Area Network (LAN). The Notes Server 58 functions to receive modified URLs from the Note Agent 56 and provide in return individual documents and their associated annotations. If a document holds more than one page, the server may provide one page at a time to the client. Note that the documents may reside in the same file system as the Notes Server or in another file server 62 necessed over the local area network. The Notes Server 58 accesses the Document File Server 62 by means of stand Network File System (NFS) protocols. The Notes Server 58 functions to keep track of all annotation activity in the Notes Database 60. The Notes Database 60 can be implemented in numerous ways. A convenient implementation is to use a standard SQL relational database. A Notes Table (not shown) in the Notes Database 60 is used to reflect the current state of the annotated documents. Transaction history is handled by a Notes Log Table (not shown) also stored in the Notes Database 60 which is implemented as a transaction log. All creation, modification and deletion events are logged on the Notes Log Table. The database is a useful tool for tracking all annotation and other activities on a per use or a per document basis. In addition, a viewer application such as Note Viewer 48 can optionally be used to generate reports on the history of annotations on a per user or a per document basis that occurred over a period of time. Each record in the Notes Table of the Notes Database 60 utilizes the unique Note Serial Number for the key index. Each record in the database comprises the following information: Note Document ID, Note Contents (text or graphical information), Note Anchor coordinates, Note Time Stamp and Note Owner ID. This information is extracted from the Note Event data structure, which is described in more detail hereinbelow. To simplify the implementation of the Notes Database 60, the Note Contents can be limited to a specific size. For example, the text of a note may be limited to a specific number of bytes or characters, or the graphic drawing can be limited to a specific number of control points. Creating limits on the size of the note allows the record size to be predicted in advance. In some systems this may be important. The size limitation can be checked by the Notes Client or by the Notes Server when processing the Note Event transaction. The Notes Server may be configured to utilize external messaging system 52, such as an electronic mail server, for generating alert notifications to specific users. The users receiving the alert notifications may or may not be clients of the annotation system. The alert notifications may comprise any portion of the notes themselves along with additional information about the annotated document and the severity and/or uregency of the message. The management of the Notes Server 58 and the Note Agent 56 in the Web Server 54 may be performed by a Notes Administration tool 50. One of the main functions of the Notes Administration tool is to provide the URL aliases needed for controlling access to specific documents. Security and URL Aliases Access permissions to the Notes Server 58 are defined on a per client user basis. As part of the task of administering the system 40, a directory is created for the user in the annotation root folder under the root directory of the web server 54. The Note Agent 56 maintains two translation tables: a Document Location Table (Table 1) and a Client Access Key Table (Table 2). Both tables are present below.
TABLE 1
Document Location Table
Alias Actual Path
Archive D:.backslash.Arc
In order to access the system, a client needs to provide the Note Agent Trigger Token as part of the URL. In the example presented herein, this is the token `annotate.` This Trigger Token is used by the Web Server 54, e.g., Microsoft Internet information Server (IIS), to invoke the filter in the Note Agent 56 to translate the document path specified in the remainder of the URL. The requested URL is as follows below. Requested URL=http//domain_name/annotate/Acme_Docs/Subfolder/document.name where domain name=`domain_name` Note Agent Trigger token=`annotate`p1 Customer Access key=`Acme_Docs` In accordance with the above described aliaisng mechanism, the system 40 may ask users to type in their unique user name and password in order to obtain permission to browse particular locations or file systems in the local area network on the server side. In this manner, users can access their private documents for display and annotation purposes while not violating the privacy and security of other users of the system. For example, assuming a Microsoft IIS Web Server 54 that defines `C:.backslash.Inetpub.backslash.wwwroot` as the base document root, the NOtes Server 58 will utilize a sub folder called for example, `annotate.` This specific name `annotate` would trigger the Note Agent ISAPI filter 56 in the Web Server 54 to translate the URL as specified below. If `Acme` is a name of a user of the system, a folder named `Acme_Docs` will be created under the `C:.backslash.Inetpub.backslash.wwwroot` directory. This folder is the Client Protocol Folder. Using the operating system security flags, only a user named `Acme` would be given rights to browse this folder. Client Protected Folder-`C.backslash.Inetpub.backslash.wwwroot.backslash.annotate.backslash .Acme` The Note Agent 56 functions to provide mechanisms for translating URL addresses under the `Acme_Docs` folder in such a way that logical names can point to physical folders on the same computer or on other computers located in the network. In connection with the example presented above, the Client Document Root physical path is as follows. Client Document Root physical path=`d:.backslash.Arc.backslash.Acme_files` The Client Document Root physical path is translated to the following URL. Translated UTL_`http://domain_name/annotate/Acme_Docs` As a result, the `Acme` client is granted permission to access any document under her/his Document Root folder. Note that neither the Document Location Table (Table 1) nor the Document Access Key Table (Table 2) is limited in length. Thus, a client may have more than one access key. In addition, there may be more than one alias associated with the same physical folder; each alias providing protection for a different client. Annotation Session: Initialization The following describes the initialization portion of an Annotation Session in more detail. A flow diagram illustrating the initialization portion of a general Annotation Session is shown in FIG. 4. Note that the client/server protocol used throughout the session is the HTTP protocol. The Session starts when the user launches a web browser and provides a URL in the form that was described above and in FIG. 3. This URL refers to a directory or to a specific document. The document may contain one or more pages. An example for a single page document is a TIFF file format image. An example of a multi-page document is an Adobe Portable Document Format (PDF) document. Initially, the user launches her/his web browser (step 80). To initiate the initial request, the client, via her/his web browser, provides a URL (step 82) which is transmitted to the server (step 84). The server verifies whether the client was already authenticated (step 86). If the client was not previously authenticated, the server requests authentication from the user in response (step 88). To authenticate a user, the browser first displays a dialog to the user, asking for a user name and password. The browser then transmits the user-supplied information to the server (step 90). The web server then checks the credentials submitted against those defined for the requested URL (step 92). The construction of the URL and associated aliases was described previously in the section entitled Security and URL Aliases. If the user name and password provided by the user are not correct (step 94), an error message is displayed (step 98) and the authentication portion is repeated (step 88). The user is then queried again for the correct user name and password. If the user name and password provided by the user are correct (step 94), the server responds with the directory listing of the URL requested by the user or with the contents of a document if the URL was referring to a specific document (step 96). The client then displays the directory listing in a window within the web browser (step 98). It is likely that the directory contains documents that the user may wish to annotate at some point in time. Note that the list of documents sent by the server when browsing is first filtered by the Notes Server 58 (FIG. 3) to display only those documents with file types that the Note Server knows how to interpret. A message flow diagram illustrating the transaction sequence between client and server during initialization is shown in FIG. 5. As described above, the first request (referenced 100) is made by the client with the requested URL to be displayed. The server first verifies the authentication of the user. If not user name or password was submitted, the server responds with an authentication request (referenced 102). Once received by the client, the user is queried for a user name and password. The user-supplied input is sent as another request to the server (referenced 104). The server attempts to verify the authentication and if it passes, the server first filters and then sends the directory listing associated with the requested URL to the client (referenced 106). Upon receiving the directory listing, the client displays its contents in window in the web browser. Annotation Session: Browsing The following describes the browsing portion of an Annotation Session in more detail. A flow diagram illustrating the document browsing portion of a general Annotation Session is shown in FIG. 6. Note that the client/server protocol used throughout the session is the HTTP protocol. The client first issues a request to the server to view a particular document by selecting its corresponding document URL (step 110). Before the server responds with the requested data, it needs to validate the user's credentials once again since this request to view a document is considered a new connection to the sever (step 112). Assuming the user's name and password were supplied previously, the web browser provides the information automatically, thus avoiding an error message response from the server. If the user is not authenticated (step 114), an error message is returned and displayed on the client browser (step 116). The document is not transmitted to the user until the user is authenticated. The mechanics of user name and password authentication by the server was described in detail previously in the Initialization section. Once authenticated, the server then responds by sending the document data, i.e., image data in this example, to the client with the proper MIME type (step 118). The MIME type sent to the client in response to the request is unique and is the name for all document types. In response to receiving the MIME type, the web browser at the client, loads the Note Plug-In (44 (FIG. 3) on the client (step 120). The Note Plug-In client functions to take control of the browser display window and begin displaying the image (step 122). Immediately thereafter, the client issues a request to retrieve the notes associated with the image, if there are any, from the server (step 124). The URL that is supplied to the server to retrieve the notes is the same UL corresponds to the underlying document (image) but having a suffix of `.backslash.notes` appended to it. Upon receiving the appended URL, the server searches the Notes Database 60 (FIG. 3) for the specified document using the URL as the key for searching (step 126). Once found, the server filters the notes so as to supply only those notes that the requesting client has permission to view (step 128). The server subsequently serializes the notes after filtering and stores them in a response buffer (step 130). The notes buffer is then sent as a response to the client (step 132). The response buffer data structure is described in more detail hereinbelow. Upon receipt of the notes buffer, the client updates its locally stored Notes Database (step 134) and then displays the contents of the notes buffer in a window within the web browser (step 136). If the user has selected to view the annotations overlying the document, i.e., the image, then the client displays the notes similarly to that shown in FIG. 1B. The user then can process one or more notes, i.e., create new notes, edit existing ones and/or delete one or more notes (step 138). The client is now ready to display notes and accept modifications to them. The Notes Server has supplied the number of notes in the Server Annotation Response Data Response Structure (FIG. 12). If the number of notes is not equal to zero, the client checks the state of the viewing condition flag in the web browser Note Plug-In application. This variable may have the following values; show document only (corresponding to FIG. 1A), show document in addition to notes (corresponding to FIG. 1B), show document and notes in one web browser frame and a list of notes in another web browser frame (corresponding to FIG. 1C). In case the third option is selected, another web browser frame is created and the document is redrawn in the right frame and the list of notes is drawn in the left frame. The notes displayed in the list in the left frame can be sorted and filtered using criteria such as, for example, time of creation, Note Owner ID, Note Contents, noted shape type, and note color. In accordance with the invention, the client is capable of displaying the notes as they arrive from the server regardless of the state of the document image stream display. This allows the user to begin manipulating the annotations when large image documents are still in the midst of being transmitting from the server. A message flow diagram illustrating the transaction sequence between client and server during a document browsing general Annotation Session is shown in FIG. 7. As described previously, the client initiates a document browsing session by sending the document URL request to the server (reference 140). The server then validates the user permissions including user name and password. Once the user is authenticated, the server responds to the client with the document MIME type and the corresponding document data (image data in this example) (referenced 142). The client checks the MIME type and, in response, loads the Note Plug-In into the web browser. Once loaded, the image is displayed in a window in the browser. Then, the annotations associated with the image are requested from the server by sending the URL corresponding to the document with the test `/notes` appended to it (referenced 144). The server searches the Notes Database and filters the notes for those corresponding to the image that the user has permissions for. The resulting groups of notes are serialized and placed in a notes buffer. The buffer is then transmitted to the client (referenced 146). The client receives the buffer, updates the local note database, displays the notes in a window in the browser and gets updates to one or more notes from the user. In accordance with the invention, the Note Plug-In running on the client web browser provides the user with the capability to perform several operations on notes. In particular, the notes client permits a user to perform the following. Notes can be created by selecting an annotation tool on the screen and placing the cursor in the area of the image where it is desired to place a note. A box is created and the user can enter text. Once entered, the text appears in the form of a `stick` note that appears on top of the image. The Note Anchor is created at the location the user placed the note. Notes can be viewed by double clicking, for example, on a note icon. Note icons are displayed on the screen when the viewing option is set to display both notes and the image. A note can be closed after viewing by clicking on the box in the upper left-hand corner of the title bar 32 (FIG. 2). Note that alternatively, graphics can be entered into a note rather than test. In this case, a graphics tool or marker is used to place graphics in the note. A note can be moved to a new location by grabbing a note icon and dragging it to a new location on the image. The Note Anchor is changed to correspond to the new location. Other features include printing the document with the notes attached; scrolling to another section of the document with the notes scrolling with the document; zooming in or out within the displayed document; deleting a note; resizing a note that contains either test or a graphic drawing; changing the default note color, dimensions and associated default marker. Further, notes can be synchronized with the Notes Server, which is described in more detail hereinbelow. It is important to note that a user may create as many notes as she/he desires. Existing notes can be modified even if other users created them. The server, however, will not permit any changes that the user is not authorized to make. In accordance with the invention, all changes made to notes are saved in a local note database on the client. The database is managed within the RAM of the computer and is backed up on the local computer mass storage device, i.e., hard disk drive. This backup of the database also functions to provide a recovery mechanism in case the user exits the application or requests a different URL without synchronizing with the server beforehand. The database is kept for a limited period of time before being erased. The time period is set by the user is typically on the order of a few days. While the database is saved, the user retains the option of synchronizing any unsaved notes the next time she/he browses to the same document URL. The structure of the local note client database is similar to that of the server note database with the exception that no authentication checks are performed on the client. Thus, for example, the note database on the client does not contain a Note Owner password field. Annotation Session: Synchronization The following describes the synchronization portion of an Annotation Session in more detail. A flow diagram illustrating the note synchronization portion of a general Annotation Session is shown in FIG. 8. The process of synchronizing notes is initiated and driven by the user. The user initiates the synchronization process, for example, by pressing a button in the browser application called `Sync` (step 150) The Notes Client, in response to the button press, functions to prepare a note buffer to send to the Notes Server (step 152). The note buffer contains only the notes that were changed since the time of the previous synchronization event. The time of the previous synchronization event is taken as either the time of the initial request to retrieve the current document or the actual time the user previously pressed the `sync` button in the Notes Client application. The time of the last synchronization event is always known and stored by the Notes Client application. This time is also transmitted by the Notes Server in the Server Annotation Response Data Structure. The client then serializes the notes within the note buffer (step 154). After serialization of the note data, the client users the data in the buffer to construct a Client Annotation Event Data Structure (FIG. 10) and POSTs it to the Notes Server using the original URL provided by the user to retrieve the notes previously (step 156). The server validates the user name and password (step 158) and merges the note event information with the Notes Database 60 (FIG. 3) (step 160). The merge process includes checking whether or not the user has the required permission level to modify notes. Those notes, i.e. Note Events, that the user is not authorized to perform are ignored. Any new notes to be created, as indicated by a zero in the Note Serial Number field, are assigned a unique Note Serial Number. A new record is created in the Notes Database and the new note is placed in the record (step 162). A new record is also created in the Notes Table. The transaction is also recorded in the Notes Log Table (step 164). Next, the Notes Server prepares a Server Annotation Response Data Structure filled with the new list of notes and their content (step 166). An important aspect of the invention is that the list of notes includes changes made by all concurrently active clients that have previously synchronized their notes with the Notes Server. In this fashion, the annotations associated with a particular document made by all other clients are replicated to each client at the time they perform note synchronization. The Notes Server responds to the synchronizing client by transmitting the Server Annotation Response Data Structure to the client (step 168). Once received, the client merges the notes list with its local notes database (step 170). The display is then refreshed and the Notes Client is ready to receive and process input from the user once again (step 172). A message flow diagram illustrating the transaction sequence between client and server during note synchronization is shown in FIG. 9. As described previously, the synchronization process is initiated and driven by the user. Once initiated by the user, the client prepares a notes buffer with the notes to be processed by the Notes Server and POSTs. i.e., transmits, the buffer to the server (referenced 180). The notes are sent in the form of a Client Annotation Event Data Structure. The Notes Server, in response, update its Notes Database after authenticating the user. Any actions requested by the user that are not authorized due to lack of permissions, are ignored. The actions are processed by the server and a response buffer is created. The buffer is sent to the client as a Server Annotation Response Data Structure (referenced 182). The client, upon receipt of the notes list, updates its local notes database, displays the notes in a frame in the web browser and inputs one or more notes commands from the user. The process is repeated while the user continues to create, edit and delete notes. Client Annotation Event Data Structure A diagram illustrating the Client Annotation Event Data Structure in more detail is shown in FIG. 10. The data structure, generally referenced 190, comprises a plurality of fields for conveying note data from the Notes Client to the Notes Server. The data structure 190 comprises a Document ID field 192 which comprises the URL of the annotated document the notes are associated with, local time 191 of the client along with the time zone of the client, the Note Owner ID 196 which uniquely identifies the user and the number of notes 198 contained in the message. Following the number of notes is a buffer containing one or more notes labeled note #1200 through note #N 202. A diagram illustrating the note data structure of the Client Annotation Event Data Structure of FIG. 10 in more detail is shown in FIG. 1. The data structure, generally referenced 210, comprises a plurality of fields that are used by the client to represent each note. Each note comprises a Note Serial Number 212 field uniquely identifying the note. The Note Serial number is set to zero for a new note and set to a non-zero value for an existing note. An action field 214 represents the action to be taken on the note. The following values are valid actions.
0 No action
1 Add a note
2 Modify a note
3 Delete a note
4 Add a comment
5 Update status
A note Anchor field 216 stores the coordinates of the position of the note in the document. The note status field 218 can have the following values.
0 Ignore
1 To be performed
2 Done
The note color field 220 represents the color the note is to be displayed in. The note color represents a RGB value. The text length of the note 222 represents the number of bytes or characters of the next note itself. The note test field 224 represents a buffer with the actual text of the note. The note shape field 226 can have the following values.
0 No shape
1 Polygon
2 Spline
3 Rectange
4 Ellipse
5 Marker
A note shape line cap field 228 can have the following values.
0 None
1 Right arrow
2 Left arrow
3 Both arrows
4 Round
5 Square
The note shape line width field 230 represents the width of the shape line in millimeters. The note marker type field 232 represents the type of marker and can have the following values.
0 No marker
1 Star
2 Circle
3 `Approved` sign
4 `Rejected` sign
5 `Correct` sign
6 `Remove` sign
The number of shape vertices field 234 represents the number of points in the shape and the shape vertices 236 comprise a plurality of N (x, y) coordinates. Server Annotation Response Data Structure A diagram illustrating the Server Annotation Response Data Structure in more detail is shown in FIG. 12. The data structure, generally referenced 240, comprises a plurality of fields for conveying the note data from the Notes Server to the Notes Client. The data structure 240 comprises a Document ID field 242 which comprises the URL of the annotated document the notes are associated with, local server time 244, the dimensions of the document 246 including the width and height in millimeters and the resolution of the width and height in pixels per millimeter and the number of notes 248 contained in the message. Following the number of notes in a buffer containing one or more notes labeled note #1250 through not #N 252. A diagram illustrating the note data structure of the Server Annotation Response Data Structure of FIG. 12 in more detail is shown in FIG. 13. The data structure, generally referenced 260, comprises a plurality of fields that are used by the server to represent each note. Each note comprises a Note Serial Number 262 field uniquely identifying the note. The Note Serial number is set to zero for a new note and set to a non-zero value for an existing note. The note Time Stamp field 264 represents the time (in server time) of the update for this particular note. An action field 266 represents the action to be taken on the note. The following values are valid actions.
0 No action
1 Add a note
2 Modify a note
3 Delete a note
4 Add a comment
5 Update status
A Note Anchor field 268 stores the coordinates of the position of the note in the document. The note status field 270 can have the following values.
0 Ignore
1 To be performed
2 Done
The note color field 272 represents the color the note is to be displayed in. The note color represents a RGB value. The test length of the note 274 represents the number of bytes or characters of the text note itself. The note test field 276 represents a buffer with the actual text of the note. The note shape field 278 can have the following values.
0 No shape
1 Polygon
2 Spline
3 Rectangle
4 Ellipse
5 Marker
A note shape line cap field 280 can have the following values.
0 None
1 Right arrow
2 Left arrow
3 Both arrows
4 Round
5 Square
The note shape line width field 282 represents the width of the shape line in millimeters. The note marker type field 284 represents the type of marker and can have the following values.
0 No marker
1 Star
2 Circle
3 `Approved` sign
4 `Rejected` sign
5 `Correct` sign
6 `Remove` sign
The number of shape vertices field 286 represents the number of points in the shape and the shape vertices 288 comprise a plurality of N (X, Y) coordinates. While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.
|
Same subclass Same class Consider this |
||||||||||