Patent Publication Number: US-2003226116-A1

Title: Method and system for implementing a historical buffer

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS  
     [0001] This application claims the benefit of priority from U.S. Provisional Application 60/362,834 filed Mar. 8, 2002. 
    
    
     
       BACKGROUND OF THE INVENTION  
       [0002] This invention pertains generally to resource management in a session-based embedded web server system, and more particularly to a method and system for implementing a pointer-based historical buffer mechanism in a session-based embedded web server system.  
       [0003] When users edit documents or groups of documents in an embedded server environment, their changes are typically saved in a historical or undo buffer so that a user can back out of a previous change and restore the content of a document. However, embedded servers generally have limited memory and storage resources. Implementing a historical or undo buffer requires saving a plurality of changes, which generally requires a large buffer storage space to store data and generally consumes significant processing time to transfer edited contents to and from the historical or undo buffer. When document data is in raster image format, as when a controller of a digital imaging device (“DID”) functions as an embedded server, the storage requirement for an undo buffer is particularly large and the negative impact on server processing performance is even more severe than when document data is in non-raster image format. This is due to the fact that raster image files are large files that require significant storage space. Consequently, the implementation of image manipulation undo functionality requires a large historical or undo buffer.  
       [0004] Digital imaging devices (“DID”) are complex machines that often perform a plurality of functions. DIDs suitably include devices such as printers, fax machines, scanners, copiers, multi-functional peripherals (“MFPs”), and other like peripheral devices. DIDs are suitably connected to a network or directly to computer. In addition, DIDs are also suitably servers, with all the necessary hardware and software to ensure proper operation of the server as will be appreciated by one skilled in the art. A DID server is also suitably a server of any type, including a web server, an embedded server, a database server, etc. as will be appreciated by one skilled in the art.  
       [0005] Because multiple users have access to an embedded server and because each user can run concurrent multiple sessions with the embedded server, such as a DID, a separate historical or undo buffer is generally created for each session and each user. Consequently, transferring documents to storage in multiple historical or undo buffers requires significant processing time and storage space. In particular, when an embedded server is a controller on a DID, this additional storage space and server time required to implement a plurality of historical or undo buffers decreases the efficiency of the DID because the processing time and storage space required to implement the historical or undo buffers cannot be used for document processing and printing.  
       [0006] There are a variety of methods known in the art for improving processor performance in servers, especially servers with multiple processors. For example, symmetric multi-processing (“SMP”) has become the de facto standard for multi-processor hardware architectures. Several highly popular operating systems (“OS”) incorporate support for SMP. The basic abstraction of an SMP system is a Multi-Threaded Environment (“MTE”), which is provided by the OS without regard to the actual number of processors running. Therefore, when software is written to make use of a MTE, one can achieve a performance improvement whether or not the SMP hardware platform contains multiple processors.  
       [0007] However, even though improved processor performance can be achieved through the use of SMP, it is always preferable to decrease required resources, both in processing and storage. Therefore, it would be preferable if there were an improved method of providing a historical buffer that uses fewer resources.  
       SUMMARY OF THE INVENTION  
       [0008] In accordance with the present invention, there is provided a method and system for implementing an historical buffer that uses fewer resources.  
       [0009] Further, in accordance with the present invention, there is provided a method and system for maintaining a pointer-based historical buffer for edits made to a document.  
       [0010] Still further, in accordance with the present invention there is provided a method and system for implementing a pointer based historical buffer. The method and system comprises the steps of and the means adapted for storing of data representative of an editable, electronic document in a selected storage area; communicating data for generating a display of the electronic document to an associated display device; receiving document modification data representative of a desired modification operation to be performed on the electronic document; storing pointer information associated with received modification data in a pointer memory; incrementing a point value storage area of pointer information in accordance with each received modification data; performing an edit to the electronic document in accordance with received document modification data; associating each received document modification data with a pointer value associated therewith; and storing at least a portion of the electronic document in a form prior to the most recent modification thereof in a historical document storage area.  
       [0011] In another embodiment, the method and system further comprise the steps of and the means adapted for receiving an undo command to selectively undo at least one previous edit; and selectively reversing edits to the electronic document by accessing the electronic documents stored in the historical data storage means in accordance with an associated pointer value.  
       [0012] These and other aspects of the present invention will be understood by one of ordinary skill in the art upon reading and understanding the specification. 
     
    
    
     DESCRIPTION OF THE FIGURES  
     [0013]FIG. 1 is a flow chart representing the general process for creating the elements for maintaining a historical buffer according to the present invention;  
     [0014]FIG. 2 is a flow chart representing the general procedure for storing selected information upon an edit to a document according to the present invention;  
     [0015]FIG. 3 is a flow chart representing the procedure for executing an undo command according to the present invention; and  
     [0016]FIG. 4 is a system diagram illustrating a system for maintaining a historical undo buffer in a network environment in accordance with the present invention.  
    
    
     DETAILED DESCRIPTION OF THE INVENTION  
     [0017] Turning now to FIG. 1, a flowchart flow chart representing the general process for creating the elements for maintaining a historical buffer according to the present invention is provided. The general flow  100  commences at start block  102  and continues to process block  104 . At process block  104 , a session is initiated, preferably by a user. Progression then flows to process block  106  wherein the server creates a temporary directory for storage of historical buffer information. Preferably, the temporary directory is session-based storage such that when the session ends, the directory and its contents are deleted. Flow continues to process block  108  wherein a document is opened for editing. Flow progresses to process block  110  where a copy of at least one file comprising information about the opened document is copied to the temporary directory. Progression then continues to process block  112  where a plurality of files are created and stored in the temporary directory. Preferably, the created files comprise at least the following: a document information file, at least one page information file, and a file list file. Flow then continues to termination block  114 .  
     [0018] Turning now to FIG. 2, a flowchart is provided representing the general procedure for storing historical information in response to an edit to a document according to the present invention. The general flow  200  commences at start block  202  and continues to process block  204  wherein an edit is made to a document. The edit is suitably made through any known means, such as by a user or by automation procedures. At process block  206 , a listing corresponding to the edit made to the document at process block  204  is added to the operation list file. Flow continues to process block  208  where the counter in the operation counter file is incremented. Flow progresses to process block  210  where a new file list file is created corresponding to the incremented counter and pointing to a location in the temporary directory wherein the copies of the edited image (page) files are stored. Progression then continues to decision block  212  where a determination is made whether there are any additional edits to be made.  
     [0019] A positive determination at decision block  212  causes progression to flow back to process block  204  wherein another edit is made to the document. A negative determination at decision block  212  causes progression to process block  214  wherein the temporary directory and files stored therein are removed from the server. Flow then continues to termination block  216 .  
     [0020] Turning now to FIG. 3, a flow chart is provided representing the procedure for executing an undo command according to the present invention. The general flow  300  commences at start block  302  and continues to process block  304 . At process block  304 , an undo command is executed. The undo command is suitably executed by a user, such as by selecting “undo” from a menu. The command is also suitably executed through automation. Progression then flows to process block  306  wherein a counter in the operation counter file is decremented. Flow continues to process block  308  where image files are loaded. The locations from which the image files are loaded are preferably referenced in the file list file. In other words the file list file corresponding to the decremented counter points to the locations of the image files. Flow then progresses to decision block  310  where a determination is made whether there are any additional edits to be made.  
     [0021] A positive determination at decision block  310  causes progression to flow back to process block  304  wherein another edit is made to the document. A negative determination at decision block  310  causes progression to process block  312  wherein the temporary directory and files stored therein are removed from the server. Flow then continues to termination block  314 .  
     [0022] Turning now to FIG. 4, an illustration of a system for maintaining an historical buffer in a network environment in accordance with the present invention is provided. The network  400  is illustrative of a LAN or WAN environment in which a preferred embodiment is provided, such as a packet-switched TCP/IP-based global communication network. Connected to network  400  are a computer  402  and a server  408 . The network  400  is suitably any network and is suitably comprised of physical and transport layers such as illustrated by a myriad of conventional data transport mechanisms like Ethernet, Token-Ring™, 802.11(b), or other wire-based or wireless data communication mechanisms as will be apparent to one of ordinary skill in the art. The server  408  is in data communication with a data transport system  401  through a network interface  410 . The data transport system  401  is also placed in data communication with the computer  402  through network interface  406 . Thus, a data path between the server  408  is in shared data communication with computer  402 .  
     [0023] The computer  402  is suitably any type of computer, but is preferably a PC running any operating system, such as Windows NT, Windows 2000, Windows XP, Unix, Linux, Macintosh or other operating system. The computer  402  is preferably configured to interact with Server  408  as will be appreciated by one who is skilled in the art. It should be noted that the computer  402  is suitably a thick client or a thin client, additional server(s), personal digital assistant (“PDA”), or any equipment capable of interacting with server  402  to send and receive data. Preferably, the computer  402  is equipped with a browser software program  404 , such as Netscape or Internet Explorer, and a network interface  406 .  
     [0024] The server  408  is suitably any device that is capable of providing shared access to files as will be appreciated to one of ordinary skill in the art. As such, the server  408  suitably runs on any operating system as will be appreciated by those skilled in the art. Preferably, the server  408  is a networked MFP, or an MFP connected to a computer. The server  408  suitably comprises a network interface  410 , and controller  412 . The controller  412  suitably comprises file storage  414  and temporary storage  416 . The server  412  storage  414  and  416  preferably comprises at least one hard disk and random access memory (“RAM”). Stored in file storage  414  is at least one document  432  and at least one image (page) file  434 . Also suitably stored in file storage  414  is at least one information file  436  comprising information about the at least one document  432  and the at least one image file  434 . The controller  412  preferably acts as a fully functional server with the necessary hardware and software that ensure proper operation of the server  408  as will be appreciated by one skilled in the art. In the presently preferred embodiment, the computer  402  and server  408  form an embedded web server system.  
     [0025] In the presently preferred embodiment, a user begins a session. Each session is suitably a lasting connection between a user at a computer  402  and the server  408 , usually involving the exchange of many packets between the computer  402  and the server  408 . A session is typically implemented as a layer in a network protocol (e.g. telnet, FTP). The user suitably has an ID, which is unique to each user, for identification and authentication. In addition, each session suitably has a session ID, which is unique to each session. A user suitably initiates a session through network interface  406 , across data transport network  400 , through network interface  410  and to the controller  412 . When a session is started, the controller  412  preferably creates temporary storage  416 , which is preferably a temporary directory  416 . The name of temporary directory  416  is preferably associated with at least one of the session ID and/or user ID.  
     [0026] A user suitably opens a document  432  that is preferably stored in file storage  414  on the server  412  or on storage external storage accessible by both the server  408  and the computer  402  via data transport system  400 . Upon opening the document  432 , a copy of the document  418  is suitably stored in temporary file storage. The copy of document is suitably stored in the temporary directory  416  or in other temporary storage. In the presently preferred embodiment, the document  432  is an image document or file comprising images, which suitably is comprised of a plurality of pages. Preferably, each page of the document  432  is also stored on file storage  414  as an image file  434 .  
     [0027] When a document  432  is opened, at least one information file  436  is suitably copied from file storage  414  to the temporary directory  416 . In the presently preferred embodiment, a document information file  436 ,  422  comprising information about the opened document is copied to the temporary directory  416 . It should be noted that information file  422  is also suitably created, rather than copied, when the copy of document  418  is stored in the temporary directory. The information stored in document information file  422  suitably comprises property information such as document type, name, location of the corresponding document  432  on file storage  414 , file format, and the number of pages in the document  432 . In the presently preferred embodiment, the document information file  422  is an markup language based document, and is preferably an extensible markup language (“XML”) file, but any suitable file format is contemplated for information storage, such as text files, flat files, database files, etc. as will be appreciated by one who is skilled in the art. The format of the document information file  422  of the presently preferred embodiment is illustrated below:  
                                                  &lt;?xml version=‘1.0’ encoding=‘UTF-8’?&gt;           &lt;!--DOCTYPE docinfo SYSTEM “docinfo.dtd”--&gt;           &lt;docinfo&gt;           &lt;doc&gt;                         &lt;name&gt;readme tac&lt;/name&gt;           &lt;path&gt;/pbfolder/public&lt;/path&gt;           &lt;format&gt;PNG&lt;/format&gt;           &lt;totalpage&gt;5&lt;/totalpage&gt;                      
 
     [0028] In addition, at least one page information file  424  comprising information about an image file  434  representing a page of the document  432  is suitably copied to the temporary directory  416 . Again, it should be noted that page information file  424  is also suitably created, rather than copied, when the copy of document  418  is stored in the temporary directory. The information stored in document information file  422  suitably comprises property information such as the page number, file format, filename, and file location. Preferably, a page information file  424  exists for each page of the document  432 . Therefore, for a five-page document  432 , there will preferably be five image files  434  stored on file storage  414  and five page information files  424  stored in temporary storage  416 . In the presently preferred embodiment, the page information file  424  is also an “XML” document. The format of the page information file  424  of the presently preferred embodiment is illustrated below:  
                                                  &lt;?xml version=‘1.0’ encoding=‘UTF-8’ ?&gt;           &lt;!--DOCTYPE docinfo SYSTEM “docinfo.dtd”--&gt;           &lt;pageinfo&gt;                         &lt;page number=“1”&gt;           &lt;pageformat&gt;PNG&lt;/pageformat&gt;           &lt;filename&gt;readme_1.png&lt;/filename&gt;           &lt;path&gt;/pbfolder/public&lt;/path&gt;                      
 
     [0029] Also, a file list file  426  is created when document  432  is opened and stored as document  418  on temporary storage  416 . The file list file  426  preferably points to the locations of the image files  434 , but also suitably points to the locations of edited copies of image files  420  for the document  432 . The first file list file  426  created when document  432  is opened preferably points to at least one image file  434  on file storage  414 , and points only to image files  434  on file storage  414 . Preferably, the file list file  426  is a text file, although other types of files for storing information are suitably used as will be appreciated by one who is skilled in the art. The format of the file list file  426  of the presently preferred embodiment is illustrated below:  
                                                  /pbfolder/public/readme_1.png           /pbfolder/public/readme_2.png           /pbfolder/public/readme_3.png           /pbfolder/public/readme_4.png           /pbfolder/public/readme_5.png                      
 
     [0030] Once a document  432  is opened, copied, and stored as document  418  on temporary storage  416 , the document  418  is suitably edited. When an edit is made, either by a user or through some automated process, the controller  412  suitably stores a copy of the edited page (image file) in temporary storage as image file  420 . In addition, the controller  412  suitably generates an operation list file  428  comprising information about the edits made to the document  418 ; and an operation counter file  430  comprising a numerical value that is incremented each time an edit is made to the document  418 . In the presently preferred embodiment, the operation list file  428  and the operation counter file  430  are suitably text files, although other types of files for storing information are suitably used as will be appreciated by one who is skilled in the art.  
     [0031] For example, if a user selects page 2 and page 3 of document  418  from a browser  404  and edits the pages to create an image shift, the operation list file  428  will suitably comprise information related to the particular edit made, and might suitably read:  
     [0032] Shift 2, 3.  
     [0033] It will be understood that the particular message format is not limiting. Any suitable indicator for a given operation is suitably used. For example, the word “shift” might correspond to an image shift of one-half inch to the right while “-shift” might correspond to an image shift of one-half inch to the left. Any code is suitably used to represent edits to a document wherein such code depends on the possible types of edits that can be made to a document and wherein the code is capable of specifically and uniquely identifying a change made to a document.  
     [0034] Assuming that the image shift was the first edit made to document  418 , the operation counter file  430  might read:  
     [0035] 1.  
     [0036] In order to properly track the locations of the edited images, another file list file  426  is suitably created. The second file list file might suitably read:  
                                                  /pbfolder/public/readme_1.png           /temp /public/readme_2.png           /temp /public/readme_3.png           /pbfolder/public/readme_4 png           /pbfolder/public/readme_5.png                      
 
     [0037] If a user were to again edit document  418  without undoing the first edit such that an invert function is performed on page  5 , the operation list file  428  might then suitably read:  
     [0038] Shift 2, 3  
     [0039] Invert 5  
     [0040] In addition, the operation counter file  430  would suitably read:  
     [0041] 2.  
     [0042] Furthermore, the third file list file  426  might suitably read:  
                                                  /pbfolder/public/readme_1.png           /pbtemp/sessionlD; 6ofyk97uwl/public/readme_4_2 .png           /pbtemp/sessionlD; 6ofyk97uwl/public/readme_4_3.png           /pbfolder/public/readme_4.png           /pbtemp/sessionID; 6ofyk97uw1/public/readme_5_5.png                      
 
     [0043] Because pages 1 and 4 have not been edited, the file list file points to the image files  434  for pages 1 and 4 on file storage  432 , but points to copies of image files  420  for pages 2, 3 and 5 stored in temporary storage  416 .  
     [0044] It is important to note that each consecutive file list file preferably does not overwrite the previous file list file  426 . Also, each version of the file list file  426  is suitably correlated with the counter value of the operation counter file  430 . This is suitably accomplished by including the counter value from the operation counter file  430  in the name of the file list file  426 . In addition, a database, lookup tables, arrays, or the like are suitably used to properly correlate the file list files  426  with counter values as will be appreciated by one skilled in the art.  
     [0045] In order to execute an undo of an edit made to document  418 , a user suitably executes an undo command, such as by selecting “undo” from a browser  404 . In addition, the undo command is suitably received through automation means. The command is suitably sent through network interface  406 , across data transport system  400  and to server  408  through network interface  410 . Upon receipt of an “undo” command, the controller  412  suitably accesses the operation counter file  430  and decrements the counter value. After decrementing the counter value in the operation counter file  430 , the controller  412  suitably accesses the file list file  426  that corresponds to the decremented counter value. From the file list file  426 , the server suitably determines the location of the image files  434  and  420  at a time before which the counter was last incremented. Since the counter is incremented upon making an edit to the document  432 , the files pointed to by the file list file  426  corresponding to the decremented counter represent the state of the document  418  prior to the last change made, effectively undoing the last change.  
     [0046] The temporary folder  416  and files stored therein therefore act as a historical buffer wherein edits to a document  432  can be undone. When the user ends the session, the temporary folder  416  and all files stored in the temporary folder  416  are preferably deleted, after which point a user could no longer undo changes made before ending the session.  
     [0047] All of the functionality of the present invention is suitably embodied in the system described, as well as in computer readable code on a computer readable medium for interfacing with files stored in file storage  414  and temporary storage  416 . The computer readable code on a computer readable medium is preferably any code, embodied in software or hardware, for providing the functionality described in terms of the description of the present invention.  
     [0048] In the presently preferred embodiment, the computer readable code on a computer readable medium is at least one software component (“SC”)  438  stored in file storage  414 , although the SC is also suitably stored in any storage accessible by the computer  402  and the controller  412 . A “user” suitably invokes the functionality of at least one SC  438  to perform the functions described. It should be noted that the term “user” should be limited to a human user. A user is suitably anything capable of triggering a call to a SC, such as a computer-readable code used during automation. The at least one SC  438  then preferably interacts with the files stored in file storage  414  and temporary storage  416  to perform the functions described above.  
     [0049] The SC  414  is suitably computer-readable code written in any language. The SC  414  is preferably compiled, pre-written code that defines at least one interface that is callable to provide the functionality that the SC  414  encapsulates. SCs are typically packaged in “industry standard” ways such that they are callable from multiple languages, or from multiple environments. The computer-readable code, in the case of SCs is suitably a unit of independent deployment that has no persistent state. As such, it provides seamless integration with existing development tools, such Forte for Java or Microsoft Visual Studio. SCs are suitably used out-of-the-box, or extended and specialized by developers as desired. It should be noted that the SCs of the present invention are suitably designed for any language binding, such as Common Object Request Broker Architecture (“CORBA”), NET, COM, DCOM, C++, ActiveX, etc., as will be appreciated by those skilled in the art. In the presently preferred embodiment, the SC  414  is a C++ SC that is callable from multiple languages, or from multiple environments, or operating systems.  
     [0050] Although the preferred embodiment has been described in detail, it should be understood that various changes, substitutions, and alterations can be made therein without departing from the spirit and scope of the invention as defined by the appended claims. It will be appreciated that various changes in the details, materials and arrangements of parts, which have been herein described and illustrated in order to explain the nature of the invention, may be made by those skilled in the area within the principle and scope of the invention as will be expressed in the appended claims.