BACKGROUND

[0001] spreadsheet ai>plicatioiis are cononoiily used programs that provide a
convouent, simple and intaitive way to enter, cnganize, m«iage view, stme, and seardi for data. One drawfoadc of conventional spreadsheet ilicatioos is that they typically do not allow multiple usos to collaborate on a single spreadslMeC file simultaneously. Ra&or, in conventional spreadsheets, when one user opens a file, diat file bea>mes ''lodced" sudi that any other uso: who attonpts to open the file can only do so in a read-only fiohion, meaning any edits will not be saved to the original file.

[0002] 'Thae are many reasons that usos may need io edit a file
simultaneously. A Sineadshe is oftm used as a data-entry itication, and someone, for example, may s iq[> a sineadsbe file to collect all of the financial results fixnn all the different dq>artmaits in a company. Files often have nndtiple au&or and those authors would like to edit the spreaddieet at will wi&out having to wait fa: the ofha author to release a lock.

[0003] In additicm to the desire to allow multq>le users to collalxnate on a
single spreadsheet file, fiure is also a desire to allow muhle different types of clients to collaborate. Such clioits may include both "rich" clients and Inowsa" clioits. A rich client (which may also be referred to as a thick client or fiit client) is a clioit fliat typically provides a greater selection of features and is typically cQMMe of poforming UKne data processing operations itsdi and does not necessarily need to idy on a server. Thae are a number of circumstances in whicb, howevo-, the rich client tmy choose to allow the saver to perform various operations. A thin client is a dient that typically jnovides a reduced selection of features and tfut typically relies on the resourees of a host or saver ocmqmta-. The variance in features and other difference between ridi taoA thin clients often make it difiScult for users at sudi diffiaent clients to collab(»ate. SUMMARY

[0004] Tedmiqiws for collaborating (m a speadeet file by client
computers in real time are disclosed herein. In particukBT, a revision manager module is preferably provided with a host machine which recdves idittes fiom the client amqniters, imxesses such updates, and then applies them to the q«eadsheet file. Thereafter, the currmt version of file spreaddieet file is availd)Ie to all dients by polling file reviaon manager. The revision nmager sends those updates to eadi diei not previous recdved so that all clients may have the spreadsheet file dilayed wifii a curroit statiut (toing the collaboration.

[0005] Additionally, a technique is described f(»- handling iQ)dates soit to the
reviaon manager by dients simultaneously or mar ramultaiMCNisly. In Ais case, the revision manager determines whether the vKistes to HOB SfxeaddMet file are transfimnable or able to be merged. If so, the iqxlates are combined inio fb» spnadatuBet file and implied thereto. If the updates are not transformable, the revision manager confirms that all clients have received all previous vtpdaltes before applying fbi non-tnmsformable update to ihe spreadsheet file. This provides the ability to include more ftmctionality in a collabts in a
simplified form that are fiirther described below in the Detailed Description. This summary is not intended to identify key features or essoitial features of datmed subject matter, nor is it intended to be used as an aid in determining the scope of the daimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The illustrative anbodimeots will be bettor umlastood after reading
the following detailed descriion with refermce to tiie appended drawings, in which:

[0008] Fig. 1 is a block diagram of an exoniary computing device.

[0009] Fig. 2 is a system diagram deleting a phoatity of client computars
collaborating on a spreaddieet file, \ere a host madune indudes a revision manager module for managing simultaneous iq)dates to a spreadsheet file.

[0010] Fig. 3 is a diagrammatic view of a pair of partial views of a
spreadsheet file fiom two of the client computers shown in Fig. 2 mik die revision manager module;

[0011] Fig. 4 is a diagrammatic view of the pm of partial views of the
sinread file for the clioit computers and revisicm mamiBr module dqncted in Fig. 3, where simultaneous idates have been made;

[0012] Fig. S is a diagrammatic view of the pair of partial views of the
spreadsheet file for the client computers and the revision manager module dq)icted in Figs. 3 and 4, where the revision manager module has merged the simultaneous updates of Fig. 4 in the spreadsheet file; and,

[0013] Fig. 6 is a flow diagram of a process fx merging simultaneous
updates made to a sprea»irtk«i by a {rfnrafity of cHoit computers.

DETAILED DESCRIPTION

[0014] The inventive sid>ject matter is described with spoddty to meet
statutory requiremeats. However, the descriptioo itself is not innded to limit Ae scope of this patoit. Radio:, it is cxnitemplated that die clamud whject matta mi also be onbodied in other ways, to include different stq)s or cmnMnations of steps similar to the ones described in this document, in conjunction with otho* imsent or future teduu>logies

[0015] Fig. 1 illustrates an example of a Stable computing system
environment 100 in which the subject matter described above may be implemented. The computing syston environment 100 is only one exane of a suitable ccnnputing environment and is not intended to suggest any limiteticHi as to the scope of use or functionality of the subject matter described above. Neidier uld the cranputing environment 100 be interpreted as having any depemkncy at requirement relating to any one or combination of components illustrated in the memplary q>erating environmoit 100.

[0016] With reference to Fig. 1, conqnitiag system mvironment 100
includes a goioral purpose onnputing device in the form of a ocmqmter 110. Components of ccnnputer 110 may indude, but are not limited to, a processing unit 120, a syan memory 130, and a system bus 121 diat coiles various syrtem components including the system memory to the x)cessmg unit 120. The system bus 121 may be any of several types of bus structures including a mem(»y bus or memory ooolnrfter, a paAjheal bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, sudi ardiitectures include Industry Standard Arcbitectme (ISA) bus. Micro Channel Architecture (MCA) bus. Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Poipheral Componeot bterccmnect (PCI) bus (also known as Mezzanine bus).

[0017] Conqmter 110 typically indudes a vwatty of compute readable
media. Computer readable media can be any available me diat can be accessed by computer 110 and includes both volatile and nonvolatile media, removable and non¬removable media. By way of example, and not limitatimi, ocmqivrter readable media may cominise computer storage media and communication nmSa. Cmnputo* storage media include both volatile and nonvolatile, removable and non-removdjle media implemented in any mediod or tedinology for storage of infinnurtkm nidi as ccniiiiter ieadd>le instructions, data striKtures, progran modules <»* odier , is typically stored in ROM 131. RAM 132 typically omtmns data and/or program modules fhaX are immediately accessible to aod/cv in«saitly being cqierated on by processing unit 120. By way of example, and not limitation. Fig. 1 illustrates operating system 134, q[)plication programs 135, other program modules 136, and program data 137.

[0019] The txnnputer 110 may also inchide other ronovable/ium-removable,
volatile/nonvolatile conwter storage media. By way of exaiiq>le only. Fig. 1 ilhntiates a hard disk drive 141 that reads from or writes to nonremovable, nonvolatile magnetic media, a magnetic disk drive 151 tfiat reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156, sudi as a CD-RW, DVD-RW or other optical media. Other removable/non-removabl volatile/nonvolatile conqniter stcoage media tiiat can be used in die exemplary operating environment incliule, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM and the like. The hard disk drive 141 is typically connected to the system bus 121 through a noa-iemovable memory interface sudi as interface 140» and magnetic disk drive 151 and optical didc drive 155 are typicaUy connected to the system bus 121 by a removable memory intoface, such as interface 150.

[0020] The drives and their associated computo* storage media discussed
above and illustrated in Fig. 1 provide sttmige of otmuter readable instructicMis, data structures, program modules and other data for the conitfer 110. ID Fig. 1, lor example, hard disk drive 141 is ilhirated as storing operating system 144, iiplication programs 145, otho: program module 146 and program data 147. Note ttutt tiiese ccnnponents can dHhec be the same as or differoit finm operating system 134, iUcation inograms 135, other program modules 136 and program data 137. Operating system 144, q»plication {nograms 145, other program modules 146 and program data 147 are given different numbos here to illustrate that, at a minimum, they are different copies. A user may oiter commands and * information into the ccmuter 110 through input devices sudi as a keyboard 162 and pointing device 161, such as a mous tradd>all or toudi pad. Other iiqnit devices (not own) may inchide a microphone, joystick, game pad, siddUte di scanner, <»: the Uke. These and other input devices are often connected to &e pocessing unit 120 through a uso* input inter&ce 160 that is coiled to the system bus 121, but may be connected by othor inter&ce and bus structures, such as a parallel port, game port or a univosal serial bus (USB). A gnhics interfiice 182 may also be connected to the aem bus 121. One or more graphics processing units (CPUs) 184 may communicate with 9:qcs interface 182. A monitor 191 or other type of display device is also connected to flie system bus 121 via an inter&ce, sudi as a video into&ce 190, which may in tun coBomamcato vnHk video memory 186. In addition to monitor 191, coiiq>uters may also include other periphoal output devices such as speakers 197 and printer 196, whidi may be connected through an output periphoal interfiice 195.

{0021] The computer 110 may operate in a networked or diribirted
environment using logical connections to one or more remote oonqniters, sudi as a remote computer 180. The ronote compute-190 may be a personal omqniter, a server, a routor, a network PC, a peer device CH- oHia oommoa netw(nk iK>de, mi Qically iiKsludes many or all of the elements described above rehitive to the computer 110, although only a memory storage device 181 has been illustrated in Fig. 1. The logical connections dqncted in Fig. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include otho- netwoiks/buses. Such networidng mviroimieats are commorlace in homes, ofBces, oiterinise-wide computer netw(»ks, intrutets and the MaaneL

[0022] When used in a LAN networking enviroomei the conqrater 110 is
connected to the LAN 171 through a network inter&ce or adiq>ter 170. When used in a WAN networking environment, the computer 110 typically indwks a modem 172 or othor means for establishing oommunications over the WAN 173, sudi as the Internet The modem 172, which may be intonal or extonal, may be ccMmected to Ae system bus 121 via tile user inmt interftce 160, or ofha qjpropriate nwdunism. ID a netw(»ked envinmmait, inogram modules dei»cted relative to tiie conapiter 110, or pcatkms thereof may be stxxred in the remote memory storage device. By way of example, and not limitatirai. Fig, 1 illustrates remote application programs 185 as residing cm memory device 181. It will be appreciated ihat the netwoik connections shown are eKemphuy and otiia- means of establishing a communications link between the conq>utos may be used.

[0023] It will be appreciated fix>m FigT 2 that a plurality of computing
systons 200,210, and 220 like that described above, also known as clioits, client computers or uso may desire to collaborate in real time on a commm Sie, such as a spreadsheet file 230. Such clients include for example, a "thick" client qmadieet a{lication or a tiiin client spreadsheet applicatiim. The spreadeet apphceom oa computing systems 200, 210, and 220 may employ a "coUaborative" mode of editing where eadi usor or client can see dianges made by any otiier usors or clients who are editing ti» file 230 at tiiat time. As wn, this may be accomplidied via a sarate host madi 240, such as a sav«, whidi contains the version of sfneadsheet file 230 that will be saved. It will be understood, however, that any of the client computers may be utilized as tiie host madiine for tiie collaboration so long as it has tiie aqubility and tiie otimr dieiit ocmqmters are property networked therewith. This collaborative mode therefore differs fixnn normal qneadsheet operation in which a client opois a spreadsheet file witii exchinve access and all dianges are pushed directiy into the file witii no other client editing tiM file while tills is happexaag.

[0024] In tiie typical collaborative arnmgement, eadi dient conqputer will
pass messages or data iqdates (as dq>icted by arrows 2) via oonqiuta-executdile instnutions to tiie host madiine 240. It will be appredated rt eadi edit or diange made by a client is packaged as a revision record by tiie client witii details indicating what tiie diange was, where it happened, who made the change, eta Host madiine 240 preferably includes a module 310 included tiierewitii known hordn aa a revision manar iiliidi recdves updates fix)m the clients and process sudi dumges or incoming data. The revision record fit)m the climt is soit to the revision manage module 310, where it is recdved and processed. Upon completion of sudi inocessti and iqpdatii of !>readsheet file 230, and by request or polling of tiie host madiine 240 by tiie individual dient computers (represented by arrows 265), revision manager module 310 sends i;Q)dates (as depicted by arrows 270) via computer-executable instructions to the clioit computo:. In this

way, the state of spreadsheet file 230 for the client computer makmg the request is updated with the cmrent veraon of spreadsheet file 230 wUdi mdudes vtpdatm fiom all client computers received during die oollabomtioiL ItwillbeuiideeBloodtiiatdiangesniadetotfae spreadsheet file 230 by the host machine 240 will pceferaUy be available to client computes within milliseconds. It is also possible M the host machine 240 to push the updates automatically to the client computers. The revisicm mana* module 310 recognizes which clioit in the collaboration makes an vtpdt request, notes the last update that client has seen, ai sends a revision record for all updates ance that time. The clioit thai applies that revisicm record and is now curroit with aU iqtdates made By all climts.

[0025] CNnoally, revision records may be processed by the revision
manager module 310 in tin (uder in whidi they are recdved. Howevo-, if two dients send revision records involving ti» same cells or objects in tiie qmadsfaeet file simultaneously or near simultaneously or the records oveilt during pt0(xsang» tluxe is potentid finr omflict between the changes. Revisicm records will also be out ofdatoiftfaeseocmd client was not iq> to date during record oiination, or if the revisi(»i manager module 310 has received any other updates befcve receiving die second client's record, iicii must allow for time fiir die second client to sutmiit die record (which is not necessarily imn»diatdy), transit tim and soiding/receiving ovohead. It will be undorstood that some revidons may be resolved and merged (known herein as **transformable" dumgesX veieas odier reviskms cannot be merged (known herdn as 'ncm-transformable" changes).

[0026] An example of how two conflicting changes m be moged is
depicted in Figs. 3-5. As seen in Fig. 3, a partial view of a simadshed: 300 fbr a first client md a partial view of a iireadsheet 305 for a second dient b provided along with reviaon manager module 310. R will be noted that the views of sixeadsheets 300 and 305 are identical at this point of die collaboration, widi die vahies of 5 and 6 being located at cells Al and A2, respectivdy. In Fig. 4, it will be seen diat die first dient has added a formula (i.e., A2 + 2) to cell B2 in spreadsheet 300 which involves the value widun odl A2. At or near the same time, the secmkl client has inserted a row above cell A2 in qmadsheet 305. Each of these changes are sent to revision mana moduto 310, as depicted by arrows 315 and 320, which must rectmdle die conflict hi order to so, revision manager nxxhile 310 processes bodi up&ites aid makes the qypropriate tramfofmaiknis in Fig. 5. .ooidingjy, revision manager module 310 sends a messi 325 to die first dient (user A) &at ft needs to insert a row betweoi rows 1 and 2 in spreadslrad 300, widi the first cheat hailing die formula update in cell Bl (i.e., A3 + 2). Concurrendy, revision manager module 310 sends a message 330 to the second client (user B) that it needs to add a new fomnila to cell Bl in spreadsheet 305, vilMte the added fonnula has been adjusted to acoount fx tibe inserted row. Thus, by making the impropriate tiansfoiniatioiis ooiraspoiidiiig to iqxiates 315 and 320, spreadsheets 300 and 305 reflect the intended changes fiom eat cUent and are identical.

0027] It will be qipreciated that revisise revision records &at the revinon manager module 310 knows how to mage toge&er. All othar revision records are ccmsidered ncMHnonfinmable, whidi the revision manier module 310 recognizes as having no p(»s%le way of meig such revision record with other records waiting to be applied. In this instance, revision manager module 310 first makes sure that all clients have received all other {ffevious iqxlates so tiiat all clients are currmtly at tlw same state. This may happm by having eh client poll the revion manager for iq>dates like it normally does, and the dioit retving a message indicating that the revision manager is about to poform a noih-traiafinmable operation and to prevent usos fixnn making any fiolfaer edits. In other W(»ds, to enmre that all cliats have received all other previous idates, each client may be {oeventod fixmi making new updates so that the revision managor can proceed to apply tto ncBirtraninnable opendon. After all clients of the collaboration are in sync, then revision manager module 310 appUes the non-transformable record and updates all die clients accortfiy.

[0029] la order to better understand tiie procras tluit takes place, the steps
undotaken are set out in the flow diagram of Fig. 6. As seen tli«em, revision mana module 310 essentially controls the lode on spreadsheet file 230 and &erefore operates to establish connection between the clients and HM host madime 240 (represented by box 600). While changes or updates to spreaddiect file 230 mi be oonmnmiatted by any number of clients to the host machine 240, it will be seen that first and second clients send updates to the revision manager module 310 are reflected (boxes 605 and 610, respectively).

When revision manager module 310 receives the updates from tbe first and second clients, it deteimines whedier bodi updates to spreadsheet file 230 ate tnmsfoimable (decisioa box 615).

[0030] If both iqxiates are considered to be tianslbnnable (i.e., the revision
records diereof are recognized as able to be mogedX then reviaon manager module 310 combines the iq)dates into the spreadshe file (box 620) and dien qiplied such updates to the spreadsheet file 230 (box 625). If both updates are not considered to be transfonnable, then revision manager module 310 first confirms that all dients have received all previous updates to the spreadsheet file 230 (box 630) and then lies the non-transformable iqxiate to the spreadsheet file 230 (box 635).

[0031] In either case, it will be understood thirt eadi dient preferably mu
poll revision manager module 310 for updates to the iveaddieet file 230 (box 640), whoein revision manager module 310 will provide all idates to spreadsheet file 230 not previously received by tibe polling client computer (box 645). The dioit dim epphea the revision record siqyplied by revision manager module 310 OMX 650) so that a cuiraxt version of [nreadsheet file 230 is displayed.

[0032] As should be apfxedalted, tlw clioits may include acklitional client-
side merge logic to apply records recdved fiom the revisioii manftger/'sorver. Without this additicmal client-side meige logic, a ridi client may be lecpiiied to blodc during die eitfire polling and iqpdate process to prevoit die user fix)m initiating my changes until the latest updates have been appUed. Ridi clients may include a veenon of die revision manager mei; oigine to be responsive. It sKmld also be qiredi diat real-time synduonizatimi may not be a requirai»nt for a fiilly-transformile aofartion. While contimious synduxmizadon may jnovide a bettor user expaieoce, p«t of the value of a fiilly transformable solution is that it can be temporarily taken offliM to provide better remote usability and provide robustness against network proUems. FB:dierm.

[0033] Aldiough die subject matter has been described in language spedfic
to die structural features and/or mediodological ads, it is to be understood dut die subject matter defined in die appended claims is not necessarily limited to the sped&c features or
cts described above. Rather, the specific features or acts described above are disclosed as example forms of implementing the claims.

I/WE CLAIM:

1. A computer-readable medium having stored thereon computer-executable instructions for performing a process comprising:
receiving a first update to a spreadsheet file (230) from a first spreadsheet client
(200);
receiving a second update to the spreadsheet file (230) from a second spreadsheet client (210);
determining whether or not the first update and the second update are transformable' such that both updates are combinable and applicable to the spreadsheet file (230);
if the first update and the second update are transformable, then combining the first update and the second update and applying them to the spreadsheet file (230) and computing reciprocal updates to send back to the first and second spreadsheet clients; and,
if at least one of the first update and the second update are non- transformable, then processing the updates according to a policy for non-transformable changes.

2. The computer-readable medium of claim 1, wherein the first and second spreadsheet client (210)s are both rich clients.

3. The computer-readable medium of claim 1, wherein the first spreadsheet client (200) is a rich client and the second spreadsheet client (210) is a browser client

4. The computer-readable medium of claim 1, wherein the process is performed in a real-time collaborative environment.

5. The computer-readable medium of claim 1, wherein the policy includes:
confirming that all spreadsheet clients have received all previous updates;
and,
applying the non-transformable update to the spreadsheet file (230).

6. The computer-readable medium of claim 1, wherein the first and second updates are received near simultaneously.

7. The computer-readable medium of claim 1, the process further comprising:
receiving a request for updates to the spreadsheet file (230) from a spreadsheet client; and,
sending a revision record including all updates not previously received for the spreadsheet file (230) by the spreadsheet client.

8. A method for spreadsheet collaboration, comprising the following steps: receiving a first change to a spreadsheet file (230) from a first spreadsheet client
' (200);
receiving a second change to the spreadsheet file (230) from a second spreadsheet client (210);
determining whether or not the first change and the second change are transformable such that both changes are combinable and applicable to the spreadsheet file (230);
if the first change and the second change are transformable, then combining the first change and the second change and applying them to the spreadsheet file (230) and computing reciprocal updates to send back to the first and second spreadsheet clients; and
if the first change and the second change are non-transformable, then processing the changes according to a policy for non-transformable changes.

9. The method of claim 8, wherein the first and second spreadsheet client (210)s are both rich clients.

10. The method of claim 8, wherein the first spreadsheet client (200) is a rich client and the second spreadsheet client (210) is a browser client

11. The method of claim 8, wherein the method is performed in a real-time collaborative environment.

12. The method of claim 8, further comprising the following steps:
confirming that all spreadsheet clients have received all previous updates;
and,
applying the non-transformable update to the spreadsheet file (230).

13. The method of claim 8, wherein the first and second updates are received near simultaneously.

14. The method of claim 8, further comprising the following steps:
receiving a request for updates to the spreadsheet file (230) fiom a spreadsheet client; and,
sending a revision record including all updates not previously received for
the spreadsheet file (230) by the spreadsheet client.

15. A system for spreadsheet collaboration, comprising:
a processor operative to execute computer-executable instructions; and memory having stored therein computer-executable instructions for performing a process comprising:
receiving a first change to a spreadsheet file (230) from a first spreadsheet
client (200);
receiving a second change to the spreadsheet file (230) from a second spreadsheet client (210);
determining whether or not the first change and the second change are transformable such that both changes are combinable and applicable to the spreadsheet file (230);
if the first change and the second change are transformable, then combining the first change and the second change and applying them to the spreadsheet file (230); and
if the first change and the second change are non-transformable, then processing the changes according to a policy for non-transformable changes.

16. The system of claim 15, wherein the process is performed by a revision manager.

17. The system of claim 15, wherein the first client is a rich client and the second client is a browser client

18. The system of claim 15, wherein the process is performed in a real-time
collaborative environment

19. The system of claim 15, wherein the policy includes:
confirming that all spreadsheet clients have received all previous updates;
and,
applying the non-transformable update to the spreadsheet file (230).

20. The computer-readable medium of claim 1, wherein the first and second updates are received at the same time.