METHODS AI\D APPARATUSES FOR FILE SYNCHRONIZATION
`A}TD UPDATING USING A SIGNATURE LIST
`
`fnventor:
`
`Peter Dickinson
`
`cRoss-REFERENcE To RELATED APPLICATIO{I\'A ila1 3, l.t,rt,
`This Application is related to the following Applicatioq which isf,ledrcf'cve+da+e
`n
`
`hereuitb.and is incorporated herein by reference:
`
`"Methods and Apparatuses for Single Connection File Synchronization and
`Ayp/t't.^Ji -7
`Workgroup File Update",
`$evl*l Nn>bev oe/io+)eqq:@
`A
`BACKGROUND OF TI{E INVENTION
`
`'\ ,l
`\NV--
`l,/ . ', .',
`llli{
`
`Pr
`
`rT{.1
`
`l,.t
`
`.fi:
`
`Li! a
`
`L-I
`till
`
`{5
`
`I.
`
`FIELD OF TI{E INVENTION
`
`The present invention relates to the field of personal computers which access files on
`network drives and which utilize electronic mail systems. Specifically, the present invention
`
`involves the synchronization ofthe local copies of files on user's client computer hard disk to the
`
`current versions of the files on a network drive.
`
`2. DISCUSSION OF TIIE RELATED ART
`As more and more business information moves from analog to digital formats, the
`relatively neurfound ability to create, amend, and revise information spontaneously and frequently
`
`has brought with it challenges for corporate users. Revenue results can now be easily aggregated
`
`and updated in near real time, sales presentations can be amended regularly, and changes made
`
`to business documents. However, causing these changes to effectively trickle down through the
`organization without causing a digital flood is a challenge.
`
`Companies have responded to the threat by carefulty creating structures for organizing,
`
`storing, and sharing these electronic files. Organizations have moved from file servers to intranet
`sites to combinations of both to meet the need of the corporate user. While these structures are
`clearly effective means of storing, sharing, and organizing information, they do not address the
`
`SYIvIA-1042 MCF/SES
`ses/syma/1M21PA.001
`
`4li"\)'
`
`

`

`fact that users have very individual information needs. They atso do not resolve the obstacle users
`face who do not have the time to spend looking for changes. An effective paradigm for
`addressing the problem ofindividual needs and delivering changes to documents ean be found in
`the emerging category of ',push Technology."
`As its simplest definition, push is the process of automatically delivering user-requested
`information electronically. It is not an application, but merely a function or feature in a product.
`There are clear distinctions between the three different categories of push-based application:
`content, software, and document.
`
`Content push is the first mover. Conventional products focus on delivering breaking news
`and information to user desktops automatically. Instead of the user constantly surfing multiple
`Web sites for stock quotes, news, weather, etc., conventional products aggregate and broadcast
`information automatically according to individual user preferences. Many companies incorporate
`"push" functionality into their products.
`Following acceptance by hundreds of thousands of early adopters, many push-based
`applications started the move into the corporate world. For IS Managers, ..push-based
`technologies" were seen as an uncontrollable avenue for terabytes of graphics and IITML to
`come through the corporate firewall and networlg filling local hard drives.
`Microsoft and Netscape entered the fray with their own "push" clients — IE 4.0
`Active Desktop and Communicator's Netcaster, respectively. Rather than spurring the growth
`of content delivery however, the effect ofthe push entries has been to call into question the value
`of delivering Web content to user hard drives. The value is questioned not only in terms of
`relevancg but also its effects and load on corporate networks. The automated information flow
`becomes a flood through the Internet gate-ways of corporations threatening the stability and
`reliability of the network infrastructure itself.
`Within the corporate world, the future of content push remains in limbo. Uncertainty over
`standards and overall value have caused the market to tnp on the initial momentum and slow to
`a crawl. However, what is questioned here is not the value of automating delivery or '.push,,, but
`rather the value ofwhat is being pushed.
`Software Push is another important objective. Mcrosoft and Marimba, arnong others,
`have recognized the importance and potential of "Electronic Software Distributionl, (ESL) or
`"software push" as a way of addressing the need to seamlessly deliver software updates across
`
`10
`
`irti
`
`i.,i
`
`E6
`it::ii
`
`E
`
`r:'
`m
`
`30
`
`SYI{A.1042 MCF/SES
`seVsyma/I042/PA.00l
`
`5
`
`

`

`the network with the goal of directly impacting the total cost of ownership. The requirements
`for software distribution are dramatically different from content distribution. For one, the
`"content" in software delivery is, by its very nature, deemed critical. To reduce the impact of
`supporting multiple versions of products across the corporate network, near-simultaneous
`5 deployment is imperative. Companies that do not use some form of software push technologies
`require dedicated individuals to make the rounds updarti.ng software by reinstalling or applylng
`patches for each personal computer and laptop.
`
`Rather than aggregating and displaying information, software push transparently delivers
`one specific piece of information and applies it to user systems or applications. Files tend to be
`very large and the delivery of these files must be well-managed. Incremental downloading
`becomes important to reduce frustration and bandwidth associated with broken and lost
`connections Management of software updating also needs to be centralized and MlS-controlled.
`In addition, the primary value of the application is to IS personnel and only indirectly to for the
`end-users.
`
`A good example of software push is l\{arimba's Castanet, which allows Java applications
`to be distributed and updated searnlessly and automatically without user intervention. This same
`approach to Java programming can be, and is being, applied to CJanguage programs as well. The
`case of content push vs. software push makes it clear that the importance lies in the distinction
`between the data being delivered — and not the delivery mechanism itself.
`The Next Phase is Electronic Document Delivery. The final frontier in digital push is
`"electronic document deliveqy''orEDD. It deals with delivering changes or "updates" to the same
`physical files (like software push), but the files themselves are highly personalized (like content
`push). Different from content pustq these files exist in the form of sales presentations
`(PowerPoint), spreadsheets @xcel and Lotus 1,2,3), and reports and plans (Word or
`WordPerfect). These are the types of documents for which companies currently invest millions
`of dollars in file servers and intranet technologies in order to share among respective workgroups.
`The importanf distinction here between content and document push is the fact that EDD delivers
`data that currently exists in its native format within corporations and whose value is clearly
`understood by the company, MIS, and the end-user. With the recognaed features, the willingness
`to invest in infrastructure is more likely.
`Within conventional environments, users have access to files and can download or copy
`
`l0
`
`iiiii
`,*o
`
`I ;!rd
`
`ii"Jl
`
`r!i
`
`ni
`ii ;ti
`f#rii*il
`{-\)
`
`25
`
`30
`
`rII
`
`!
`
`SYlv{A-1042 MCF/SES
`seVsyrna/10421PA.001
`
`

`

`them on-demand, whenever they are aware that the network file document changes. File servers
`and intranet servers act as document repositories waiting passively to be accessed. The reality
`is that these files change erratically and the user can never really know when a file has changed.
`As a result, those who need to have the most current documents are required to perform
`hit-and-miss network browsing and checking which is time-consuming, unproductive, and
`frustrating. Even if the changes are scheduled, the ruer is still required to manually access,
`retrieve and manage those changes.
`
`For mobile users, the problem of knowing about and accessing changes to network-based
`files is compounded by infrequent access to the corporate network. In addition, when remote
`from the office, users need to establish connections to the network via dial-up networking
`technologieg then search and browse the network over an often slow, unreliable connection. The
`productivity losses and frustrations are simply multiplied.
`As is apparent from the above discussioq a need exists for an efficient and effective
`mechanism for allowing a computer user to have copies of the current versions of network files
`on his client computer.
`
`l0
`
`iii:i
`
`$-3
`
`ir; I
`
`rfI
`
`SYlv{A-1042 MCF/SES
`seVsyma/I042/PA.00l
`
`

`

`SUMMARY OF TIIE INVENTION
`Conventionally, those who need to have the most current versions of computer files are
`required to perform hit-and-miss network browsing and checking which is time-consuming,
`unproductive, and frustrating. An object of the present invention is to provide a mechanism by
`which a user can be automatically provided with a current version of a file to which he subscribes.
`Another object of the present invention is to communicate the current version of the file in an
`efficient manner. According to the present invention, a server computer monitors network files
`and folders stored on the network for changes and then sends the user email notifications and
`updates when monitored items change.
`According to the present invention, a server computer generates an update file for
`transmission to a client computer that permits the client computer to generate a copy of a current
`version of a subscription file from a copy of an earlier version of the subscription file. The server
`computer periodically reads the subscription file from the network drive and divides the
`subscription file into variable-length segments based upon a segment delimiter. The server
`computer computes a signature for each segment and stores the segment signature along with the
`beginning position and length of each segment in a current version of the signature list. The
`server computer also maintains the earlier version of the signature list.
`For each segment of the current version of the subscription file, the server computer
`searches an earlier version of a signature list for an old segment signature which matches a new
`segment signature corresponding to the segment. When a match is detected, the server computer
`writes a command in the update file for the client computer to copy an old segment of the client
`computer's copy ofthe earlier version of the subscription file into the client computer's copy of
`the current version ofthe zubscription file, where the old segment corresponds to the segment for
`which a match was detected. The command need only specify the location within the earlier
`version ofthe file where the old segment is stored, rather than the actual data that is stored at this
`position' This information is found in the signature list in the beginning location and size fields.
`The beginning location field is preferably expressed as a number of bytes from the beginning of
`the file. At the client computeq whenthis location information is combined with the offset of the
`beginning ofthe client computer's copy of the earlier version of the subscription file, the correct
`old segment can be copied into the client computer's copy of the current version of the
`subscription file. The size of the copy command is negligible in comparison to the size of the
`
`10
`
`f,"i
`
`+.i.il
`
`!iii:
`
`'!$
`
`i:! i
`
`riiiir
`
`a i
`
`r I
`
`20
`
`25
`
`30
`
`SYlv[A-1042 MCF/SES
`seVsyma/l0421PA.001
`
`( f ;
`Y-
`
`

`

`segment to which it pertains. This savings reduces the size of the update file, and thus reduces
`the connection time in communicating the update file to the client computer'
`When no match is detected in the earlier version of the signature trist, the server computer
`writes a command into the update file for the client computer to insert a new segment of the
`current version of the subscription file into the client computer's copy of the current version of
`the subscription file, where the new segment of the cyrrent version of the subscription file is
`written into the update file. Because the new segment of the current version of the subscription
`file contains the actual data of the ne\il segment, the new segment of the current version of the
`subscription file may be compressed to reduce the size, encrypted for security, or both' by the
`server computer before being written into the update file'
`When the update file is completed, the server computer transmits the update file to the
`client computer as an executable attachment via electronic mail. The update file is only generated
`when the seryer computer determines that the subsctiption file has changed. The server computer
`periodically monitors the subsoiptionfile to determine if it has been altered before generating an
`update file. The user determines the periodicity of the checks to determine if the file has been
`altered, and if so, to generate the update file and send it as an electronic mail.
`These and other featgres of the present invention are apparent from the Drawings which
`are described in narrative form in the Detailed Description of the Invention.
`
`10
`
`L-i
`
`iitu,t
`'r ?
`liitii
`
`ll I ::.
`
`ii
`
`L."i
`
`lri
`
`rr,i-il
`
`SYtvIA-iO42 MCF/SES
`ses/svma/1042/PA.001
`
`6
`
`.J
`
`

`

`BRIEF DESCRIPTION OF TI{E DRAWINGS
`
`Figure 1 illustrates a general purpose computer architecture suitable for implementing the
`methods according to the present invention.
`Figure 2 illustrates a network of computers suitable for implementing the methods
`according to the present invention.
`
`Figure 3 illustrates an earlier version of a subsciiption file broken into six segments and
`the signatures corresponding to the six segments suitable for use with the methods according to
`the present invention.
`
`Figure 4 illustrates an earlier version of a signature list according to the present invention
`corresponding to the earlier version of the subscription file shown in Figure 3.
`
`l0
`
`*5
`
`t:
`I F-{
`
`iL*t
`ilb
`
`'Hsr
`
`25
`
`Figure 5 is a flow chart illustrating a method according to the present invention of building
`a signature list corresponding to a subscription file.
`
`Figure 6 illustrates a current version ofthe subscription file shown in Figure 3 broken into
`
`seven segments and the signatures corresponding to the seven segments suitable for use with the
`methods according to the present invention.
`
`Figure 7 illustrates a current version of a signature list according to the present invention
`corresponding to the current version of the subscription file shown in Figure 6.
`Frgure 8 illustrates the correspondence of the current version of the subscription file to
`the earlier version ofthe subscripion file and the segments which are communicated to the client
`computer from the server computer in an update file according to the present invention.
`Figure 9 illustrates the creation of a current copy on the client computer of the current
`subscription file from a copy of the earlier version of the subscription file on the client computer
`using the update file.
`Figure l0 is a flow chart illustrating a method according to the present invention of
`generating an update file from the current version of the subscription file and the current and
`earlier versions of the signature list.
`Figure 11 illustrates an update file generated by the method according to the present
`invention illustrated in Figure 10 applied to the earlier and current versions of the signature list
`illustrated in Figures 4 and 7, respectively.
`
`30
`
`Figure 12 illustrates a large and diverse network of computers suitable for implementing
`the methods according to the present invention.
`
`SYMA-1042 MCF/SES
`seVsyma/10421PA.001
`
`\(/l
`
`it/
`
`

`

`The Figures are more thoroughly described in narrative form in the Detailed Description
`of the Invention.
`
`ii"Fr
`
`j!#i-
`ilr:'
`
`SYMA.1O42 MCF/SES
`seVsyma/I042/PA.00l
`
`

`

`DETAILED DESCRIPTION OF TIIE II\WENTION
`Although intranets are growing in popularity, they are not likely to replace file servers any
`time soon. File servers are one of the primary ways to store and share data on corporare
`networks due to their sheer simplicity for posting and retrieving files. Users have grown
`accustomed to working with network drives, even to the extent where in which data is actually
`stored directly on the network, rather than on their orJ hard drives. The intrane! on the other
`hand, requires that documents be "posted" or "uploaded" to a web server, usually by a select
`group ofindividuals. Thus, making documents available to others goes from the simple task of
`copying a file onto a network directory to submitting a file to be processed by others. On the
`recipient end, it involves activating a browser, going to the appropriate IJRL or IP address,
`finding the document on a page and downloading it (as opposed to a simple drag-and-drop file
`copy to the hard drive)
`In spite of the varylng degrees of complexity, there is value in both methods of file
`sharing. Since virtually all Intranet documents are converted forms of some other type of
`document filg the most current information is often found in native files on the LAN, rather than
`information posted to a web page. In addition, not all changing files used in rhe day-to-day life
`ofthe mobile professional are found on the intranet, whereas all intranet-based files can typically
`be found onthe network. Thus, browser-access alone is not always adequate to serve the needs
`of document delivery.
`
`According to researclq the most popular method of connecting to the corporate network
`is through electronic mail. Not surprisingly, electronic mail is treated as a mission critical
`application. For remote or mobile professionals, it is the one connection they do make to the
`network on a recurrent basis. This familiar, reliable qystem is well-suited for electronic document
`delivery (EDD). So well-suited, in fact, that many departments and users currently rely on
`electronic mail as a primary way to send documents to other users. Even with existing network
`and Intranet infrastructures, a typical response to the suggestiorq "It's now posted on the site, you
`can download it" is "I know, but could you send it to me by email? It's easier". The simplicity
`of using electronic mail as a single connection to a wide variety of information sources is very
`compelling to both users and corporations, with the caveat that the files being sent must not
`impede the networlg the mail server, or the end-user's experience. This means, for truly effective
`document push, file size has to be addressed. first and foremost.
`
`10
`
`iL.*!
`
`iLtit
`
`!: I
`
`25
`
`30
`
`SYMA-I042 MCF/SES
`ses/syrna/l042PA.001
`
`9
`
`(,
`
`

`

`Electronic Doctrment Delivery involves more thanjust the physical process of sending out
`
`documents automatically. The indiscriminate sending or downloading of full-size files places a
`
`heavy burden on network bandwidth, IS, and the mobile professional. Intelligence needs to be
`
`built into the entire process of delivery to be truly effective and valuable to both MIS and users.
`For truly effective Document Delivery server-b4psd intelligence is required. It is needed
`for detecting and sending changed fileg but also as well as for detecting what changes have been
`made and packaging only those changes as efficiently as possible. If only 50 cells of 5000 have
`changed in a spread-sheet, it does not make sense to send the entire file again. If only a single
`slide in a SO-slide presentation changes, it does not make sense to re-send the entire 2 MB file.
`Symantec Mobile Updateru (Symantec Mobile Update is a trademark of Syrnantec
`Corporation and its subsidiaries) according to the present invention, through a combination of
`server-based "delta technologl/' and client-based "update agent technology", adds "intelligence"
`to document delivery by automatically offering a seamless way of receiving changes to corporate
`
`documents. The next section discusses the technology used by Mobile Update according to the
`
`present invention to bring "intelligence" to document delivery.
`Mobile Update according to the present invention is designed primarily to serve the
`mobile professional as the target user, who relies on copies of the most up-to-date documents to
`
`be effective, but who is not always connected to the network to access changes. In addition, the
`mobile user is challenged wi-th both slow connection speeds to the network ltypicallV 28.8 Kb/sec
`modem), as well as the hassles of getting and staying connected. The Mobile Update solution
`according to the present invention is comprised of a server portion (for tracking files on the
`network and processing changes) and a client portion (for managing document "subscriptions"
`and for incorporating changes into existing documents).
`
`The Mobile Update Client portion is used to create and manage subscriptions to network
`documents. The process of selecting files to be monitored is referred to as "subscribing". IJsers
`browse to the network directory where the desired files are stored and select either individual files
`or folders (excluding sub-folders). Once selected, the user then determines the polling or
`monitoring interval for the server to check for changes and also what to do when changes occur,
`i.e., package and send file changes or simple notification. Once the subscription is set up, the
`information is passed to the server and stored in its database.
`The Mobile Update Server according to the present invention acts as an "electronic
`
`l0
`
`t-_l
`#l
`l,,ii
`
`56i:i:i
`
`UH
`
`fr
`ii
`
`i-_l
`fforFnS
`
`, iFii
`
`30
`
`SYIvIA-1042 MCF/SES
`seVsyma/l0421PA.001
`
`1lt\
`
`

`

`assistant" on the network, tracking documents for changes. It polls files or subfolders at either
`user-defined intervals for any changes to date, time stamps. When it detects a change, it checks
`the integrity of the file, then decides whether it needs to deliver the actual changes or simply
`noti$ send notice of a file change.
`Figure I illustrates a general pu{pose computer slrstem 100 suitable for implementing the
`methods according to the present invention. The general purpose computer system 100 includes
`at least a microprocessor 104. The general pu{pose computer may also include random access
`memory 102, ROMmemory 103, akeyboard 107, and a modem 108. All of the elements of the
`general purpose computer 100 are optionally tied together by a common bus 101 for transporting
`
`data between the various elements. The bus 101 typically includes data, address, and control
`signals. Althoughthe general purpose computer 100 illustrated in Figure I includes a single data
`bus l0l which ties together all of the elements of the general purpose computer 100, there is no
`requirement that there be a single communication bus l0l which connects the various elements
`of the general purpose computer 100. For example, the microprocessor 104, RAI\{ IO2, and
`ROM 103, are alternatively tied together with a data bus while the hard disk 105, modem 108,
`keyboard 107, display monitor 106, and network interface 109 are connected together with a
`second data bus (not shown). In this case, the first data bus 101 and the second data bus (not
`shown) are linked by a bidirectional bus interface (not shown). Alternatively, some of the
`elements, zuch as the microprocessor 102 andRAM I02 are connected to both the first data bus
`l0l and the second data bus (not shown), and communication between the first and second data
`bus occurs ttrough the microprocessor 102 and RAM 102. The network interface 109 provides
`
`communication capability to a local area network LAII{ using an ethernet connection, for example.
`The modem 108 allows the computer 100 to communicate through the telephone system. The
`methods of the present invention are executable on any general purpose computer system such
`as the 100 illustrated in Figure 1, but there is clearly no limitation that this computer system is the
`only one which can execute the methods of the present invention.
`Figure 2 illustrates a network of computers suitable for implementing the methods
`according to the present invention. A client computer 201 is connected to a network dive 202
`through link 205. A server computer 203 is connected to a network dive202 through a link 206.
`The client computer 207 and server computer 2,03 are logically connected by a link 207 for
`communication between them. The server computer 203 is logically connected to an electronic
`
`10
`
`l:i
`, !{ll
`
`ii,,:
`tii $
`,i*5
`ii ii
`
`no,
`i rFii
`
`Inlww
`
`. ifr:
`
`25
`
`30
`
`SYlvfA-1042 MCF/SES
`seVsyma/1042/PA.00l
`
`ll
`
`f^ltltlIII
`
`I./
`
`

`

`mail facility 204 through link 209. Chent computer 201 is logically connected to the electronic
`
`mail facility 204 through link 20S. The logicat connections 207,208, and 209 arc not necessarily
`physical connections. For example, the client computer 201 is alternatively a remote computer
`which periodically connects to the network dive 202 through a modem. In this event, the
`modem (not shown) provides the physical connectionthrough which the logical connections 205,
`207, and 208 are implemented.
`
`Figure 2 illustrates the interaction between client, server> and network according to the
`present invention. The user browses the network through link 205 from his client computer 201
`to determine the files to which he wishes to subscribe. The client computer 201 sends the
`subscription information to the server computer 203 through logical link 207. The server
`computer 203 polls the network 202 tfuough link 206 for changes to the subscription files. The
`
`seryer sends update files to the client computer 201 tlrough the email facility 204 through logical
`link 209. The client computer receives update files through the logical link 20S.
`Symantec's Delta Technology according to the present invention has been optimized to
`detect and process changes quicHy and efficiently, while concurrently maintaining the integrity
`of the file. When a usel first "subscribed' to a file, the server takes a "digital snapshot" that forms
`the basis for determining changes made to the file in the future. The server reads the file from the
`network and determines the most efficient "delimiter" or "dividing point" to break the file into
`segments as shown in Figure 3. A digital 'snapshot' is comprised of a series of segments which
`define the overall contents and structure of a file. A file can be segmented into hundreds, if not
`thousands, of segments depending on the file size and type.
`
`Frgure 3 illustrates an earlier version of a subscription file broken into six segments and
`the signatures coresponding to the six segments suitable for use with the methods according to
`the present invention. Segments Al tkough ,4.6 represent variable length portions of the earlier
`version of the subscription file. The ends of each of the segments (Al through 46) are
`determined by segment delimiters 301 through 306. The segment delimiters 301 through 306 are
`specific portions of dat4 perhaps bytes, that arc statistically determined to be an optimal, or at
`least acceptable, division point for the variable length segments A1 through 46 for the earlier
`version of the zubscription file. Signatures 311 through 316 are fixed length values derived from
`the variable length segments Al through A6. The signatures 311 through 316 may be determined
`by any one of a variety of hashing methods or signature algorithms. In the presently preferred
`
`l0
`
`'li;
`
`55
`
`tjlt
`f'fr
`
`6i
`
`L-i
`{ti
`
`120
`
`25
`
`SYtfA-I042 MCF/SES
`seVsyma/l042/PA.001
`
`12
`
`,4
`
`

`

`embodiment, the signatures Al through ,4'6 are computed using the cyclic redundancy check
`(CRC). However, any srgnature algorithms maybe used according to the present invention. For
`example, MD5 can be used to derive a fixed length digital signature from the variable length
`
`segments.
`
`Figure 4 illustrates an earlier version of a signaturo list according to the present invention
`corresponding to the earlierversion of the subscription file shown in Figure 3. The signature list
`400 shown in Figure 4 further includes the starting locations 401 through 406 of each of the
`segments Al through .{6 shown in Figure 3. The starting locations 401 through 406 are
`preferably represented as byte address locations relative to the beginning of the earlier version of
`the subscription file. Thus, an offset representing the location of the beginning of the earlier
`version of the subscription list is combined with each of tho segment location values 401 through
`406to determine the address of the beginning of each of the segments within the address space
`within which the segments Al through A6 are stored. The signature list 400 also includes a
`segment size field which stores the size of each of the variable length segments Al through A6
`as a number of bytes within the variable length segment to which it corresponds. The segment
`location and segment size allow the addresses of all of the data within the segment to be
`computed. Howeveq it should be noted that the information necessary to compute the addresses
`ofthe pieces ofdatawithin each segment could be represented in some alternative manner. For
`example, instead of atraching the segment size within the signature list, the ending location of
`each segment could alternatively be stored according to the present invention.
`Figure 5 is a flowchart illustrating a method according to the present invention of building
`a signature list corresponding to a subscription file. The method starts at step 501. At step 502,
`the subscription file is read from the network dive 202. If the subscription file read from the
`network drive is a new zubscription file, test 503 delivers the method to step 504 where the most
`efficient segment delimiter is determined for that new subscription file. Thus, the byte value
`which represents the segment delimiters 301 through 306 shown in Figure 3 are computed at step
`504 the first time that the subscription file is read. If the subscription file read from the network
`drive in step 502 is not a new subscription filg then the task 503 detvers the message to step 505,
`where the delimiter corresponding to the subscription file is retrieved from a table (not showri)
`which stores the values of the segment delimiters which correspond to each of the subscription
`files that the server computer 203 monitors. After the segment delimiter corresponding to the
`
`IO
`
`fF,i
`
`!"1
`rfs
`
`i:Iii
`
`iosl
`r20
`
`25
`
`30
`
`SYIyIA-1042 MCF/SES
`seVsrma/l0421PA.001
`
`l3
`
`,t\\lIr
`
`

`

`subscription file is retrieved at step 505, the method scans the file from the beginning for the
`delimiter in order to determine the first variable length segment corresponding to that subscription
`file. If the end of the file is reached before the delimiter is found, then step 506 marks that as a
`segment, and that will be the last segment corresponding to the subscription file. Thus, the
`segment delimiter 306, which pertains to the last segment .{6, is the last byte in the file, and is not
`necessarily the same value as the other segment delimiters 301 through 305. At step 507, the
`signature for the variable length segment is computed. ,{t step 508, the signature is added to the
`signature list along with the beginning location and segment size corresponding to the segment.
`Test 509 determines u'hether or not the segment ends with the delimiter. If the segment ends
`with the delimiter, then it is not the last segment in the zubscription file, and therefore the test 509
`returns the message to step 506 so that the next variable length segment can be determined. If
`the segment does not end with the delimiter, then it is assumed that it is the end of the file, and
`the method 500 is completed. At this point, the signature list corresponding to the subscription
`file has been computed and stored.
`
`When the server 203 polls the subscription file at a future time and detects a change, a
`second "snapshot" is generated using the same process as the first snapshot as shown in Figure
`7. As shown in Figure 8, the new or changed segments are accompanied by unchanged segments,
`depending on the number and severity of the changes made to the file. The Delta Engine
`according to the present invention then compares the two sets of segments to determine which
`segments have been altered, which ones are new and which ones have remained unchanged, as
`illustrated in Figure 8.
`
`Figure 6 illustrates a current version ofthe subscription file shown in Figure 3 broken into
`seven segments and the signatures corresponding to the seven segments suitable for use with the
`methods according to the present invention. Segment delimiters 601 through60T represent byte
`codes which were determined for this subscription file to indicate the end of each of the segments
`B 1 throug