Caching infrastructure

- Microsoft

Example systems and methods are directed at maintaining and retrieving presence metadata. One example method includes receiving a request from a first client to edit a document file, and sending short-term check out metadata to the first client to begin an editing session. The method also includes writing the transition ID to a transition table stored in a cache, wherein the presence of another transition ID in the cache indicates that a document has switched from a single-client mode to a multi-client mode. An example system includes a processing unit operative to receive a document, the document including short-term check out metadata indicating an editing session has begun, ping a cache to determine if another transition ID is stored in the cache, and send a transition ID to a transition table stored in a cache to switch from a single-client mode to a multi-client mode.

Skip to: Description  ·  Claims  ·  References Cited  · Patent History  ·  Patent History
Description
BACKGROUND

In a collaborative environment, some computer applications allow multiple clients to simultaneously edit a document. As multiple clients are editing the document, a server may maintain a copy of the document. The server may need to continually update the copy of the document to reflect the current state of the document. This can lead to inefficiencies.

For example, even with only a single client editing the document, the client's application may need to continuously update the server to allow the transition to multi-party editing when it occurs. This can increase server load, thereby causing a degradation in performance.

SUMMARY

Example systems and methods described herein relate to a caching infrastructure.

According to one aspect, an example method for retrieval of presence metadata includes: receiving a request from a first client to edit a document file; sending short-term check out metadata to the first client to begin an editing session; and writing the transition ID to a transition table stored in a cache, wherein the presence of another transition ID in the cache indicates that a document has switched from a single-client mode to a multi-client mode.

According to another aspect, an example system includes a cache infrastructure for retrieval of presence metadata. The system includes a memory storage unit, and a processing unit coupled to the memory storage unit, wherein the processing unit is operative to receive short-term check out metadata from a first client to begin an editing session, add a transition ID to the short-term check out metadata, write the transition ID to a transition table stored in a cache, and switch from a single-client mode to a multi-client mode. Switching from the single-client mode to the multi-client mode comprises the processing unit being operative to notice when the first client attempts to take another short-term lock on the document and seeing that that a second client has already received the document. The processing unit is operative to determine if the multi-client mode is in progress by checking a database, receive a ping from the first client to determine if the transition ID is in the cache, and when the transition ID is not in the cache, receive pings from the first client at regular intervals, and save the document to the server a plurality of times without incurring any reads/writes to the database, and, when the transition ID is in the cache, receive a ping from the first client to collect a lock table from the database to identify the second client, and receive the second client's lock information by receiving pings that do not carry lock information.

According to yet another aspect, an example client computer for retrieval of metadata relating to a multi-client editing session includes a memory unit, and a processing unit operative to receive a document from a storage device, the document comprising short-term check out metadata indicating an editing session has begun, ping a cache to determine if another transition ID is stored in the cache, and send a transition ID to a transition table stored in a cache when the another transition ID is not stored in the cache to switch from a single-client mode to a multi-client mode when the another transition ID is stored in the cache.

This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter. Nor is this Summary intended to be used to limit the claimed subject matter's scope.

DESCRIPTION OF THE DRAWINGS

Non-limiting and non-exhaustive embodiments are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.

FIG. 1 is a schematic block diagram illustrating an example authoring system;

FIG. 2 is a schematic block diagram illustrating the authoring system of FIG. 1 in which a document stored on first computing device can include content and metadata;

FIG. 3 is a schematic block diagram of an example lock table;

FIG. 4 is a schematic block diagram of an example authoring environment including a first computing device on which a master copy of a document to be authored is to be stored;

FIG. 5 is a schematic block diagram of an example client computing system configured to implement an authoring environment;

FIG. 6 is a flowchart illustrating an example caching process implemented by an authoring application to recognizes a single or multiple clients editing a document; and

FIG. 7 is a flowchart of an example subroutine used in the method of FIG. 6 for writing a transition ID to a transition table.

 DETAILED DESCRIPTION

In the following detailed description, references are made to the accompanying drawings that form a part hereof, and in which are shown by way of illustrations specific embodiments or examples. While the disclosure will be described in the general context of program modules that execute in conjunction with an application program that runs on an operating system on a computer system, those skilled in the art will recognize that the disclosure also may be implemented in combination with other program modules. The embodiments described herein may be combined and other embodiments may be utilized without departing from the spirit or scope of the present disclosure. The following detailed description is therefore not to be taken in a limiting sense, and the scope of the disclosure is defined by the appended claims and their equivalents.

Embodiments of the present disclosure provide an environment in which multiple clients can collaboratively author a document while consuming minimal server resources. In example embodiments, when a coauthoring capable application is editing a document, the application adds coauthoring metadata to the document and keeps a server copy of the file updated with the latest metadata. The coauthoring metadata and server copy allows seamlessly transitions from a single client to a multi-client editing state and vice versa. To keep conflicts to a minimum, the coauthoring metadata is uploaded to the server. When a new client opens the document, the client is notified of the areas of the document where other clients are working.

FIG. 1 illustrates an example authoring system 100 having features that illustrate examples aspects of the disclosure. The authoring system 100 includes a storage device 120 storing a master copy of a document 150. In one embodiment, the storage device 120 may include, but not limited to, a server, a client computer, or other computing device. In another embodiment, the storage device 120 can include one or more storage devices (e.g., a network of computing devices).

The authoring system 100 also includes at least one client computing device 110 that is communicatively coupled to the storage device 120. Each of the client computing devices 110 can edit the document 150 by creating a client copy 155 of the document 150 and editing the client copy 155. The client copies 155 of the document 150 are synchronized when the client computing devices 110 periodically send to the storage device 120 updates to be shared with the other client computing devices and periodically obtain from the storage device 120 updates from other client computing devices.

As the term is used herein, a client computing device 110 includes any computing device that obtains a client copy of a document to be authored from a master copy of the document. The client computing device 110 can be different from the storage device 120 or can include a different client account implemented on the storage device 120. In one embodiment, a computing device that acts as a storage device 120 for one document may act as a client computing device 110 for a different document and vice versa.

In the example shown, four client computing devices 110A, 110B, 110C, and 110D are communicatively coupled to the storage device 120. In other embodiments, however, any number of computing devices 110 may be coupled to the storage device 120. In the example shown, each client computing device 110A, 110B, 110C, 110D can send to the storage device 120 updates generated by the client of the client computing device and can request from the storage device 120 updates generated by the clients of the other client computing devices. In one embodiment, the storage device 120 can be a server computing device and the client computing devices 110A, 110B, 110C, 110D can be client computing devices. Other system configurations are possible. For example, in an alternative embodiment, multiple server computing devices can be used.

As shown in FIG. 2, the document 150 stored on the storage device 120 can include content 152 and metadata 154. Authoring applications 130 on the client computing devices 110 process and manipulate the content and metadata of the client copies 155 of the document 150. In some embodiments, metadata 154 can be stored separately from content 152. For example, content 152 can be stored in the document 150 and metadata 154 can be stored in a table (see FIG. 3) separate from the document 150. In other embodiments, however, the metadata 154 can be stored within the document 150.

In general, the client computing devices 110 can synchronize updates to the content 152 separately from updates to the metadata 154. In general, metadata updates 154 are automatically synchronized among the storage device 120 and client computing devices 110, whereas content updates 152 from each client computing device 110 are synchronized at the request of the respective client.

Referring to FIG. 3, lock metadata can be stored in a variety of different formats. For example, the lock metadata of FIG. 3 is stored in a table format 300. The lock table 300 of FIG. 3 includes a list of clients, each of whom is identified with a client identifier (e.g., an identification number) that is uniquely assigned to the client. Data units to be locked are identified with unit identifiers (e.g., identification numbers) that are uniquely assigned to each data unit within a document. The lock table 300 associates the unit identifiers of the one or more data units to be locked with the client identifiers of the clients who own the locks.

For example, in the lock table 300, data units 312 and 314 are associated with a first client 310. Other clients, therefore, are inhibited from editing data units 312 and 314. Data unit 322 is associated with client 320. Other clients, including the first client 310, therefore, are inhibited from editing data unit 322. The fourth client 340 has not locked any portion of the document and so is not associated with any unit identifiers. In other embodiments, however, lock metadata can be stored in a different format or within the document. For example, the lock table 300 can be arranged by unit identifier instead of by client identifier.

Presence metadata also can be stored in a variety of formats. For example, presence metadata can be stored in the lock table 300 of FIG. 3. In another embodiment, however, presence metadata can be stored in a separate table or in a different format. Presence metadata includes the client identifier of each client that is currently accessing the document or that has staked a claim (e.g., generated a content lock) on a data unit of the document. For example, a metadata table, such as the lock table 300, can store the client identifier of each client having a claim to at least one data unit of the document. Like lock metadata, presence metadata can be synchronized automatically.

FIGS. 4 and 5 provide greater detail in how coauthoring between the client copy and the master copy of the document is implemented by a client computing device. FIG. 4 is a schematic block diagram of an authoring system 400 including a storage device 420 on which a master copy of a document to be authored is to be stored. The authoring system 400 also includes at least one client computing device 410 communicatively coupled to the storage device 420.

The client computing device 410 includes an authoring application 412 configured to provide an authoring environment in which a client can create and/or manipulate a document to be authored. The client computing device 410 also includes a cache 414, a layer object (“LO”) 416, and a synchronization manager (“sync manager”) 418. The cache 414 stores a client copy of the document to be authored. The cache 414 also stores the metadata, including lock and presence metadata, associated with the document. Updates to the content and metadata of the document also can be stored in the cache 414.

The layer object 416 provides an interface between the authoring application 412 and the cache 414. The layer object 416 also provides an interface between the authoring application 412 and the sync manager 418. The sync manager 418 communicates with the storage device 420 and provides an interface between the storage device 420 and the cache 414. For example, the sync manager 418 can send updates to and obtain updates from the storage device 420 and the cache 414.

In general, an authoring environment having features that are examples of aspects in accordance with the principles of the disclosure can be implemented on a client computing device (e.g., a personal computer, a server computer, a notebook computer, a PDA, a Smartphone, or any other such computing device). A non-limiting embodiment of a client computing system 500 configured to implement an authoring environment is described herein with reference to FIG. 5.

In FIG. 5, the exemplary computing system 500 for implementing the principles of the disclosure includes a client computing device, such as client computing device 510. In a basic configuration, the client computing device 510 typically includes at least one processing unit 515 for executing applications and programs stored in system memory 520. Depending on the exact configuration and type of computing device 510, the system memory 520 may include, but is not limited to, RAM, ROM, EEPROM, flash memory, CD-ROM, digital versatile disks (DVD) or other optical storage devices, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other memory technology.

System memory 520 typically stores an operating system 522, such as the WINDOWS® operating systems from Microsoft Corporation of Redmond, Washington, suitable for controlling the operation of the computing device 510. System memory 520 also may include a document cache 526 in which a client copy 527 of a document can be stored. Metadata 529 of the document also can be stored within the client cache 526.

The system memory 520 also may store one or more software applications, such as authoring applications 524 for creating and editing documents. One non-limiting example of an authoring application 524 suitable for authoring documents in accordance with the principles of the present disclosure is Word word processing software from Microsoft Corporation. Other non-limiting examples of authoring applications include POWERPOINT® presentation software and VISIO® drawing and diagraming software, both also from Microsoft Corporation. Other software applications can also be used.

Computing device 510 also may have input device(s) 530, such as a keyboard, mouse, pen, voice input device, touch input device, etc., for entering and manipulating data. Output device(s) 535, such as a display screen, speakers, printer, etc., also may be included. These output devices 535 are well known in the art and need not be discussed at length herein.

The computing device 510 also may contain communication connections 540 that allow the device 510 to communicate with other computing devices, for example, the storage device 420 of FIG. 4, over a network in a distributed computing environment (e.g., an intranet or the Internet). By way of example, and not limitation, communication device media 540 includes wired media such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared and other wireless media.

Turning now to FIG. 6 is a flow chart setting forth the general stages involved in a method 600 consistent with an embodiment of the disclosure for retrieving presence metadata. Method 600 may be implemented using a computing device 510 as described in above with respect to FIG. 5. Ways to implement the stages of method 600 will be described in greater detail below. Method 600 may begin at starting block 605 and proceed to stage 610 where computing device 510 may receive metadata 529. For example, a client using computing device 510 (e.g. a client computer) may open a document (e.g. 150). Opening the document may cause computing device 510 to receive short-term check out metadata for the document.

From stage 610, where computing device 510 received metadata 529, method 600 may advance to stage 620 where computing device 510 may add a transition ID to the metadata 529.

Once computing device 510 adds the transition ID to metadata 529 in stage 620, method 600 may continue to subroutine 630 where computing device 510 may write the transition ID to a transition table stored in cache 526. For example, writing the transition ID to metadata 529 may indicate more than one client is editing the document (i.e. switching from a single-client mode to a multi-client mode) as show in FIG. 7.

In one example, the transition ID is a unique number, such as a Globally Unique Identifier (GUID—i.e., a pseudo-random 128—bit number). The transition table is a list of the transition IDs. The transition table can also include an expiration date for each transition ID. The expiration date can be used to clear a transition ID when a client forces creation of a transition ID and thereupon abandon editing of the document without notification. Other configurations are possible.

From subroutine stage 630, where computing device 510 may write the transition ID to a transition table stored in cache 526, method 600 may advance to stage 640 where computing device 510 may ping storage device 120 (e.g. a server) to determine if the transition ID is in cache 526.

When the transition ID is not in the cache, computing device 510 may ping the server at regular intervals, and save the document to the server a plurality of times without incurring any reads/writes to a database that stores presence information.

When the transition ID is in the cache, computing device 510 may ping the server to collect a lock table from a database to identify a new client, and in a separate web service request, submitting the client's lock information. Computing device 510 may then delete the transition ID from the transition table.

Computing device 510 may also submit a client's lock information. Submitting the client's lock information may include pinging the server. For example, the computing device can submit “am I alone” pings to the server, wherein the “am I alone” pings do not carry lock information. An “am I alone” ping is simply a ping to the server or other storage device wherein computing device 510 is requesting information to determine if the document is being edit by another client or if another client had begun editing the document after the client began editing the document.

Every time each client downloads presence metadata, the number of clients in an editing session and the last time each client updated their presence information (e.g., transition ID, transition table, database, etc.) may be checked (among other things), at regular intervals. If the presence information has not been updated by any client in a configurable window of time, it is considered a violent exit from the session. Any client who first observes this exit can delete the client from the presence information. Further, the delete operation should be a graceful merge so that any other client who also made the same observation can re-request the omissions which results in a no-op in the server.

If the presence information reflects only one client (which should be the examining client, i.e., computing device 510), the following actions may be done to minimize problems associated with the timing of the change of state of the document: 1) clear-up the presence table so it reflects the state as a single client mode; 2) delete the transition ID to the transition table; and 3) start the “am I alone” pings at regular intervals.

The transition ID in the transition table indicates another user has joined the coauthoring session and is in transition back to multi-user authoring. When the system transitions back to one client editing, that client starts sending the “am I alone” pings. The “am I alone” pings returned to the client indicate the client is alone until another client puts the transition ID back in the transition table.

Once computing device 510 pings storage device 120 in stage 640, method 600 may continue to stage 650 where computing device 510 may refresh cache 526.

For example, computing device 510 may refresh cache 526 by updating the transition table stored in cache 526. For instance updating the transition table may include pinging cache 526 to check for the presence of the transition ID in cache 526. When the transition ID is not present in cache 526, a determination may be made to see if cache 526 has been refreshed within a predetermined time interval. When cache 526 has been refreshed within the predetermined time interval, a response to the ping may be sent from cache 526. When cache 526 has not been refreshed within the predetermined time interval, the transition table corresponding to the document's content database may be fetched. Once computing device 510 has refresh cache 526 in stage 650, method 600 may then end at stage 660.

FIG. 7 is a flow chart showing example stages of subroutine 630. Subroutine 630 begins at starting block 705 and proceeds to stage 710 where computing device 510 may determine if the document is already being used in the multi-client mode. For example, computing device 510 may determine if the document is in multi-client mode by checking a database. If computing device 510 determines the document is not in multi-client mode in stage 710, subroutine 630 may proceed to stage 715 where computing device 510 switch from a single-client mode to a multi-client mode.

For example, switching from single-client mode to multi-client mode may be initiated by a second client attempting to take another short-term lock on the document and seeing that that the client has already received the document. Switching to multi-client mode may include computing device 510 receiving the document and transition ID at cache 526. In this instance computing device 510 may actually be a second client computing device. After receiving the transition ID, computing device 510 may write the transition ID to the transition table, and write to the database information indicating the second client has joined the editing session and is now working on the document.

If computing device 510 determines the document is in multi-client mode in stage 710, subroutine 630 may continue to stage 720 where computing device 510 may adds the client as the “nth” client. For example, adding the “nth” client may include computing device 510 receiving the document and transition ID, and writing to the database information indicating the “nth” client has joined the editing session.

From stage 715 where computing device 510 switches from single-client mode to multi-client mode or stage 720 where computing device 510 adds the “nth” client, subroutine 630 may advance to stage 730 where computing device 510 may return to stage 640 (FIG. 6).

Reference may be made throughout this specification to “one embodiment,” “an embodiment,” “embodiments,” “an aspect,” or “aspects” meaning that a particular described feature, structure, or characteristic may be included in at least one embodiment of the present disclosure. Thus, usage of such phrases may refer to more than just one embodiment or aspect. In addition, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments or aspects. Furthermore, reference to a single item may mean a single item or a plurality of items, just as reference to a plurality of items may mean a single item. Moreover, use of the term “and” when incorporated into a list is intended to imply that all the elements of the list, a single item of the list, or any combination of items in the list has been contemplated.

Embodiments of the disclosure may be implemented as a computer process (method), a computing system, or as an article of manufacture, such as a computer program product or computer readable media. The processes (programs) can be implemented in any number of ways, including the structures described in this document. One such way is by machine operations, of devices of the type described in this document. Another optional way is for one or more of the individual operations of the methods to be performed on a computing device in conjunction with one or more human operators performing some of the operations. These human operators need not be collocated with each other, but each can be only with a machine that performs a portion of the program.

The computer program product may be a computer storage media readable by a computer system and encoding a computer program of instructions for executing a computer process. The computer program product may also be a propagated signal on a carrier readable by a computing system and encoding a computer program of instructions for executing a computer process. The term computer readable media as used herein includes both storage media and communication media.

Those skilled in the art will appreciate that the disclosure may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like. The disclosure may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform particular tasks or implement particular abstract data types.

Claims

1. A method for retrieval of presence metadata, the method comprising:

receiving a request from a first client to edit a document file;
sending short-term check out metadata to the first client to begin an editing session; and
writing a transition ID to a transition table stored in a cache, wherein the presence of another transition ID in the cache indicates that a document has switched from a single-client mode to a multi-client mode.

2. The method of claim 1, further comprising receiving a ping from the first client to determine if the transition ID is in the cache.

3. The method of claim 2, further comprising:

if the transition ID is not in the cache, receiving a plurality of pings from the first client at regular intervals, and saving the document to a server a plurality of times without incurring reads/writes to a database, and
if the transition ID is in the cache, receiving a plurality of pings from the first client to collect a lock table from a database to identify a second client, and in a separate web service request, receiving the second client's lock information.

4. The method of claim 3, wherein receiving the second client's lock information comprises receiving a ping from the second client.

5. The method of claim 1, wherein switching from the single-client mode to the multi-client mode including a second client further comprises:

attempting to take another short-term lock on the document and seeing that the second client has already received the document;
determining if the multi-client mode is in progress by checking a database.

6. The method of claim 5, further comprising:

if the multi-client mode is not in progress, sending the document and transition ID to the second client, writing another transition ID to the transition table, and writing to the database information indicating the second client has joined the editing session; and
if the multi-client mode is in progress, sending the document and transition ID to other clients who are part of the editing session, and writing to the database information indicating the second client has joined the editing session.

7. The method of claim 1 further comprising refreshing the cache by updating the transition table.

8. The method of claim 7, wherein updating the transition table comprises:

pinging the cache to check for the presence of transition ID in the cache; and
if the transition ID is not present in the cache, determining if the cache has been refreshed within a predetermined time interval; when the cache has been refreshed within the predetermined time interval, respond to the ping from the cache, and when the cache has not been refreshed within the predetermined time interval, fetch the transition table corresponding to the document's content database.

9. A system including a cache infrastructure for retrieval of presence metadata,the system comprising:

a memory storage unit; and
a processing unit coupled to the memory storage unit, wherein the processing unit is operative to: receive short-term check out metadata from a first client to begin an editing session for a document; add a transition ID to the short-term check out metadata; write the transition ID to a transition table stored in a cache, switch from a single-client mode to a multi-client mode, wherein switching from the single-client mode to the multi-client mode comprises the processing unit being operative to notice when the first client attempts to take another short-term lock on the document and seeing that that a second client has already received the document; determine if the multi-client mode is in progress by checking a database; receive a ping from the first client to determine if the transition ID is in the cache; if the transition ID is not in the cache, receive pings from the first client at regular intervals, and save the document to a server a plurality of times without incurring any reads/writes to the database, and if the transition ID is in the cache, receive a ping from the first client to collect a lock table from the database to identify the second client, and receive the second client's lock information by receiving pings that do not carry lock information.

10. The system of claim 9, further comprising the processing unit being operative to:

if the multi-client mode is not in progress, send the document and transition ID to the second client, write the transition ID to the transition table, and write to the database information indicating the second client has joined the editing session; and
if the multi-client mode is in progress, send the document and transition ID to other clients that are part of the editing session, and write to the database information indicating the second client has joined the editing session.

11. The system of claim 9, further comprising the processing unit being operative to refresh the cache by updating the transition table.

12. The system of claim 11, wherein updating the transition table comprises the processing unit being operative to:

receive a ping from the first client to check for the presence of transition ID in the cache; and
if the transition ID is not present in the cache, determine if the cache has been refreshed within a predetermined time interval; if the cache has been refreshed within the predetermined time interval, respond to the ping from the cache, and if the cache has not been refreshed within the predetermined time interval, fetch the transition table corresponding to the document's content database.

13. A client computer for retrieval of metadata relating to a multi-client editing session, the client computer comprising:

a memory unit; and
a processing unit operative to: receive a document from a storage device, the document comprising short-term check out metadata indicating an editing session has begun; ping a cache to determine if another transition ID is stored in the cache; and send a transition ID to a transition table stored in a cache if the another transition ID is not stored in the cache to switch from a single-client mode to a multi-client mode.

14. The client computer of claim 13, wherein, if the transition ID is not in the cache the processing unit is further operative to:

ping the storage device at regular intervals, and
save the document to the storage device a plurality of times without incurring any reads/writes to a database.

15. The client computer of claim 13, wherein if the another transition ID is in the cache the processing unit is further operative to:

ping the storage device to collect a lock table from a database to identify a first client; and
submit the client's lock information in a separate service request.

16. The client computer of claim 15, wherein submitting the first client's lock information comprises the processing unit being further operative to submit pings to the storage device.

17. The client computer of claim 13, wherein switching from the single-client mode to the multi-client mode comprising the processing unit being further operative to:

attempt to take another short-term lock on the document; and
see that that a first client has already received the document.

18. The client computer of claim 13, further comprising the processing unit being operative to determine if more than one another transition ID is in the cache, and, if more than one another transition ID is in the cache, the processing unit is further operative to write to a database information indicating a second client has joined the editing session.

19. The client computer of claim 18, further comprising the processing unit being operative to refresh the cache by updating the transition table.

20. The client computer of claim 19, wherein updating the transition table comprises the processing unit being operative to:

ping the cache to check for the presence of another transition ID in the cache; and
if the another transition ID is not present in the cache, determine if the cache has been refreshed within a predetermined time interval; when the cache has been refreshed within the predetermined time interval, respond to the ping from the cache, and if the cache has not been refreshed within the predetermined time interval, fetch the transition table corresponding to the document's content database.
Referenced Cited
U.S. Patent Documents
4855580 August 8, 1989 Van Maanen, Jr.
5107443 April 21, 1992 Smith et al.
5142619 August 25, 1992 Webster, III
5313394 May 17, 1994 Clapp
5339389 August 16, 1994 Bates et al.
5486686 January 23, 1996 Zdybel
5535332 July 9, 1996 Ishida
5568640 October 22, 1996 Nishiyama et al.
5623659 April 22, 1997 Shi et al.
5630138 May 13, 1997 Raman
5664186 September 2, 1997 Bennett et al.
5671428 September 23, 1997 Muranaga et al.
5692178 November 25, 1997 Shaughnessy
5729734 March 17, 1998 Parker
5751958 May 12, 1998 Zweben
5781732 July 14, 1998 Adams
5781908 July 14, 1998 Williams et al.
5787262 July 28, 1998 Shakib et al.
5835950 November 10, 1998 Cho et al.
5963931 October 5, 1999 Fagg
6000945 December 14, 1999 Sanchez-Lazer
6006239 December 21, 1999 Bhansali et al.
6026461 February 15, 2000 Baxter et al.
6055546 April 25, 2000 Pongracz et al.
6065026 May 16, 2000 Cornelia
6067551 May 23, 2000 Brown et al.
6073161 June 6, 2000 DeBoskey et al.
6088702 July 11, 2000 Plantz
6202085 March 13, 2001 Benson et al.
6209010 March 27, 2001 Gauthier
6209128 March 27, 2001 Gerard et al.
6240414 May 29, 2001 Beizer et al.
6275935 August 14, 2001 Barlow
6317777 November 13, 2001 Skarbo et al.
6327584 December 4, 2001 Xian et al.
6327611 December 4, 2001 Everingham
6341291 January 22, 2002 Bentley et al.
6342906 January 29, 2002 Kumar et al.
6363352 March 26, 2002 Dailey et al.
6411965 June 25, 2002 Klug
6438548 August 20, 2002 Grim, III et al.
6446093 September 3, 2002 Tabuchi
6529905 March 4, 2003 Bray et al.
6560614 May 6, 2003 Barboy et al.
6560620 May 6, 2003 Ching
6574377 June 3, 2003 Cahill
6662209 December 9, 2003 Potts, Jr. et al.
6681382 January 20, 2004 Kakumani
6687878 February 3, 2004 Eintracht et al.
6711718 March 23, 2004 Pfeil et al.
6751618 June 15, 2004 Germscheid et al.
6757678 June 29, 2004 Myllymaki
6757871 June 29, 2004 Sato et al.
6760840 July 6, 2004 Shimbo et al.
6772165 August 3, 2004 O'Carroll
6854087 February 8, 2005 Takeo et al.
6983416 January 3, 2006 Bae
7007235 February 28, 2006 Hussein et al.
7039679 May 2, 2006 Mendez et al.
7047407 May 16, 2006 Itoh et al.
7058663 June 6, 2006 Johnston et al.
7065633 June 20, 2006 Yates et al.
7069505 June 27, 2006 Tamano
7110936 September 19, 2006 Hiew
7111237 September 19, 2006 Chan
7127501 October 24, 2006 Beir et al.
7149776 December 12, 2006 Roy et al.
7185277 February 27, 2007 Bernstein et al.
7200668 April 3, 2007 Mak
7209948 April 24, 2007 Srinivasa
7225189 May 29, 2007 McCormack et al.
7249314 July 24, 2007 Walker
7310657 December 18, 2007 Nakamura
7328243 February 5, 2008 Yeager et al.
7346705 March 18, 2008 Hullot et al.
7401291 July 15, 2008 Ramaley et al.
7496577 February 24, 2009 Williamson
7536641 May 19, 2009 Rosenstein et al.
7577906 August 18, 2009 Friedrichowitz
7594163 September 22, 2009 Slack-Smith
7603357 October 13, 2009 Gourdol
7610287 October 27, 2009 Dean et al.
7647292 January 12, 2010 Hayashi
7650336 January 19, 2010 Herrmann et al.
7664750 February 16, 2010 Frees et al.
7694217 April 6, 2010 Croft
7714222 May 11, 2010 Taub
7761784 July 20, 2010 Parks et al.
7788326 August 31, 2010 Buchheit et al.
7792788 September 7, 2010 Melmon et al.
7839532 November 23, 2010 Brawn et al.
7912811 March 22, 2011 Hodel-Widmer
7941399 May 10, 2011 Bailor et al.
8028229 September 27, 2011 Bailor et al.
20010018697 August 30, 2001 Kunitake et al.
20020007287 January 17, 2002 Straube et al.
20020065848 May 30, 2002 Walker et al.
20030028600 February 6, 2003 Parker
20030093760 May 15, 2003 Suzuki et al.
20030097410 May 22, 2003 Atkins
20030097638 May 22, 2003 Tamano
20030115481 June 19, 2003 Baird
20030140067 July 24, 2003 Sesek et al.
20030159105 August 21, 2003 Hiebert
20030167281 September 4, 2003 Cohen et al.
20030172113 September 11, 2003 Cameron et al.
20030208534 November 6, 2003 Carmichael
20040039829 February 26, 2004 Bucher
20040068505 April 8, 2004 Lee et al.
20040107224 June 3, 2004 Bera
20040122870 June 24, 2004 Park
20040122898 June 24, 2004 Srinivasa
20040133858 July 8, 2004 Barnett
20040143630 July 22, 2004 Kaufmann et al.
20040172395 September 2, 2004 Edelstein et al.
20040177343 September 9, 2004 McVoy et al.
20040199550 October 7, 2004 Ito et al.
20040205539 October 14, 2004 Mak et al.
20040205653 October 14, 2004 Hadfield et al.
20040230903 November 18, 2004 Elza et al.
20040239700 December 2, 2004 Baschy
20050004990 January 6, 2005 Durazo
20050071386 March 31, 2005 Wolfgang
20050097440 May 5, 2005 Lusk et al.
20050198132 September 8, 2005 Vellante et al.
20050210392 September 22, 2005 Koide
20050223066 October 6, 2005 Buchheit et al.
20050234943 October 20, 2005 Clarke
20050240858 October 27, 2005 Croft et al.
20050262203 November 24, 2005 Buchheit et al.
20050289512 December 29, 2005 Matsusaka
20060015811 January 19, 2006 Tanaka et al.
20060020360 January 26, 2006 Wu
20060053194 March 9, 2006 Schneider
20060053195 March 9, 2006 Schneider et al.
20060080432 April 13, 2006 Spataro et al.
20060085402 April 20, 2006 Brown et al.
20060101328 May 11, 2006 Albornoz
20060123033 June 8, 2006 Livshits
20060136511 June 22, 2006 Ngo
20060136809 June 22, 2006 Fernstrom
20060200755 September 7, 2006 Melmon et al.
20060218476 September 28, 2006 Gombert
20060242549 October 26, 2006 Schwier et al.
20060248038 November 2, 2006 Kaplan
20060259524 November 16, 2006 Horton
20070066293 March 22, 2007 Peng
20070118598 May 24, 2007 Bedi et al.
20070130334 June 7, 2007 Carley
20070186157 August 9, 2007 Walker et al.
20070186171 August 9, 2007 Junuzovic et al.
20070198952 August 23, 2007 Pittenger
20070203917 August 30, 2007 Du et al.
20070226320 September 27, 2007 Hager et al.
20070226604 September 27, 2007 Chalasani et al.
20070271502 November 22, 2007 Bedi et al.
20070283321 December 6, 2007 Hegde
20080028300 January 31, 2008 Krieger et al.
20080059539 March 6, 2008 Chin
20080072141 March 20, 2008 Hodel-Widmer
20080086718 April 10, 2008 Bostic et al.
20080097993 April 24, 2008 Nanba
20080098294 April 24, 2008 Le
20080114740 May 15, 2008 Vergottini
20080126953 May 29, 2008 Davidson et al.
20080147590 June 19, 2008 Bechtel et al.
20080177782 July 24, 2008 Poston
20080195800 August 14, 2008 Lee
20080235579 September 25, 2008 Champion et al.
20080256113 October 16, 2008 Rasmussen et al.
20080256114 October 16, 2008 Rasmussen et al.
20080270386 October 30, 2008 Ohi et al.
20080294895 November 27, 2008 Bodner
20090006936 January 1, 2009 Parker
20090006948 January 1, 2009 Parker
20090063489 March 5, 2009 Neumann et al.
20090094242 April 9, 2009 Lo et al.
20090157811 June 18, 2009 Bailor et al.
20090171987 July 2, 2009 Coppinger et al.
20090193331 July 30, 2009 Croft et al.
20090228473 September 10, 2009 Kannan et al.
20090235158 September 17, 2009 Rosenstein et al.
20090271696 October 29, 2009 Bailor et al.
20090282462 November 12, 2009 Skaria
20090327294 December 31, 2009 Bailor
20100070464 March 18, 2010 Aymeloglu et al.
20100088676 April 8, 2010 Yuan
20100131836 May 27, 2010 Dukhon et al.
20110184906 July 28, 2011 Bailor et al.
Foreign Patent Documents
19844071 April 1999 DE
1290575 June 2005 EP
1681652 July 2006 EP
10-0331685 April 2002 KR
200424868 November 2004 TW
200627259 August 2006 TW
WO 01/33362 May 2001 WO
WO 02/033575 April 2002 WO
WO 2005/114467 December 2005 WO
WO 2007/034858 March 2007 WO
WO 2007/062949 June 2007 WO
WO 2009/061638 May 2009 WO
WO 2009/076010 June 2009 WO
WO 2009/079116 June 2009 WO
WO 2009/134548 November 2009 WO
WO 2009/154842 December 2009 WO
WO2009/158108 December 2009 WO
Other references
  • International Search Report and Written Opinion for PCT/US2008/081456 / MS 321449.02 mailed Mar. 31, 2009.
  • US Office Action (Non-Final) for U.S. Appl. No. 11/938,082, mailed Dec. 28, 2009.
  • Adkins et al.; GSS Collaboration in Document Development: Using Group Writer to Improve the Process, Proceedings of the 32nd Hawaii International Conference on System Sciences, Copyright © 1999 IEEE, 11 pages.
  • International Search Report and Written Opinion for PCT/US2009/039316, mailed Jan. 18, 2010, 11 pages.
  • International Search Report and Written Opinion for PCT/US2008/083862 / MS 321998.02 mailed Mar. 31, 2009, 11 pages.
  • Synchronous Collaborative Text Document Editing Online: MoonEdit, reviewed Sep. 13, 2007, pp. 104, http://www.masternewmedia.org/news/2005/02/20/synchronous—collaborative—text—document-editing.htm.
  • US Office Action (Non-Final) for U.S. Appl. No. 11/957,010, mailed Mar. 18, 2010, 32 pages.
  • “File Locks-GNU Emacs Lisp Reference Manual”; www.gnu.org/software/emacs/elisp/html—node/File-Locks.html; Mar. 28, 2006; 2 pages.
  • Miller et al.; “Interactive Simultaneous Editing of Multiple Text Regions”; www.co-ode.org/resources/papers/k-cap2007-seidenberg.pdf; Jun. 2001; 15 pages.
  • Seidenberg et al; “A Methodology for Asynchronous MultiUser Editing of Semantic Web Ontologies”; www.xmpp.org/extensions/xep-0058.html; Mar. 28, 2006; 8 pages.
  • Shchepin; “XEP-0058: Multi-User Text Editing”; http://groups.csail.mit.edu/uid/projects/simuledit/usenix01.pdf; Oct. 9, 2007; 5 pages.
  • “Codeville,” http://codeville.org/, 2 pages (Date Retrieved Oct. 9, 2007).
  • “Google, Google Docs & Spreadsheets Tour” downloaded from http://www.google.com/google-d-s/intl/en/tour2.html on Nov. 9, 2007 (1 page).
  • “Status of Software Reuse 577,” http://www.plex86.org/Computer—Folklore/Status-of-Software-Reuse-577.html, 2 pages (Date Retrieved Oct. 9, 2007).
  • Adler et al., “Evaluating and Implementing a Collaborative Office Document System,” 2005, pp. 1-18, http://www.sce.carleton.ca/faculty/adler/publications/2005/adler-nash-noel-2005-Collab-Office.pdf.
  • Citro et al., “Conflict Management for Real-Time Collaborative Editing in Mobile Replicated Architectures,” School of Computer Science and Information Technology, RMIT University, Melbourne, Victoria, Australia, Australian Computer Society, Inc. © 2007, pp. 1-10, http://www.crpit.com/confpapers/CRPITV62Citro.pdf.
  • Galli, R., “Journal File Systems in Linux,” http://bulma.net/impresion.phtml?nIdNoticia=1154, 15 pages. (Jan. 24, 2002).
  • Green, Bob, “Converting Qedit to the Client/Server Model”, http://www.robelle.com/library/papers/client-server/, 14 pages (Copyright 2004).
  • Haake et al., “Collaborative Authoring of Hypermedia Documents,” Machine Translation Today, Translating and the Compute 15, pp. 41-58, Aslib:London 1993, pp. 1-18, http://www.pi6.fernuni-hagen.de/publ/MT-93.pdf.
  • Hebsgarrd, Poul J; Process Driven Document Management198 , Version 6.1, Feb. 2007, pp. 1-13, http://www.brain-technology.com/upload/file—vk306c6tr779p9gntgho—16467.pdf.
  • Ignat et al., “Extending Real-Time Collaborative Editing Systems with Asynchronous Communication,” Institute for Information Systems, ETH Zurich, (at least as early as Oct. 4, 2007) pp. 1-6, http://www.inf.ethz.ch/personal/ignat/Publications/cscwd—04.pdf.
  • Koch, Michael, “Design Issues and Model for a Distributed Multi-User Editor” (pp. 1-21), from Computer Supported Cooperative Work, An International Journal, 3(3-4), 19995, pp. 359-378.
  • La Fontaine, Robin, Monsell EDM Ltd., Merging XMLFiles: a new approach providing intelligent merge of XML data sets, Presented at XML Europe 2002, 21 pages, http://www.deltaxml.com/dxml/93/version/default/part/AttachmentData/data/merging-xml-files.pdf.
  • Microsoft Corporation, Compare and Merge Mechanisms, © 2007, 1 page, http://msdn2.microsoft.com/en-us/library/ek8hk7e2(VS.80,d=printer).aspx.
  • Pacull et al., “Duplex: A Distributed Collaborative Editing Environment in Large Scale” Proceedings of the Conference on Computer Supported Cooperative Work, Oct. 22-26, 1994, Chapel Hill, NC, USA. ACM, 1994; pp. 165-173.
  • Preston et al., “Synchronous Editing via Web Services: Combining Heterogeneous Client and Server Technologies,” Department of Computer Science, Georgia State University, Atlanta, Georgia, CSCW 2006, Nov. 4-8, 2006, Banff, Alberta, Canada, pp. 1-2. http://cims.clayton.edu/jpreston/PhD/Research/Preston%20-%20CSCW%20Demo%20Extended%20Abstract.pdf.
  • Synchronous Collaborative Text Document Editing Online: MoonEdit, reviewed Sep. 13, 2007, pp. 1-4, http://www.masternewmedia.org/news/2005/02/20/synchronous—collaborative—text—document—editing.htm.
  • Tichy, Walter F., RCS—A System for Version Control, Jan. 3, 1991, 20 pages, http://www.svlug.org/teams/rcs.pdf.
  • U.S. Appl. No. 11/938,082, filed Nov. 9, 2007, Confirmation No. 3133.
  • U.S. Appl. No. 11/951,973, filed Dec. 6, 2007, Confirmation No. 9364.
  • U.S. Appl. No. 11/957,010, filed Dec. 14, 2007, Confirmation No. 8535.
  • U.S. Appl. No. 12/044,744, filed Mar. 7, 2008, Confirmation No. 7862.
  • U.S. Appl. No. 12/111,174, filed Apr. 28, 2008, Confirmation No. 6839.
  • U.S. Appl. No. 12/117,040, filed May 8, 2008, Confirmation No. 8262.
  • Wilde, Erik, “Multi-User Multimedia Editing with the MultimETH System,” Swiss Federal Institute of Technology, CH 8092, Zurich, (at least as early as Oct. 10, 2007) pp. 1-9, http://dret.net/netdret/docs/wilde-tikrep18.pdf.
  • Google, “Share and Collaborate in Real Time,” 2008, 1 page, http://www.google.com/google-d-s/intl/en/tour2.html.
  • McKechan et al., “Design Considerations for Creditor: A Collaborative Report Writing Editor,” 10 pages, accessed May 16, 2008, http://userpages.umbc.edu/˜jcampbel/Group01/McKechan—paper—iwces3.pdf.
  • U.S. Appl. No. 12/145,536, filed Jun. 25, 2008, Bailor et al., Confirmation No. 3462, 20 pages.
  • US Non-Final Office Action for U.S. Appl. No. 12/044,744 mailed Jul. 26, 2010.
  • US Non-Final Office Action for U.S. Appl. No. 11/951,973 mailed Jan. 19, 2011.
  • Ohst et al., Difference Tools for Analysis and Design Documents, IEEE 2003, pp. 1-10.
  • Lu et al., Merging Retrieval Results in Hierarchical Peer-to-Peer Networks, ACM 2004, pp. 472-473.
  • Heckel, A Technique for Isolating Differences between Files, ACM 1978, pp. 264-268.
  • US Final Office Action for U.S. Appl. No. 11/957,010 mailed Aug. 18, 2010.
  • International Preliminary Report and Written Opinion for PCT/US/2008/083069/MS 321999.02 mailed Jun. 24, 2010, 6 pages.
  • US Final Office Action for U.S. Appl. No. 11/938,082, mailed Jun. 29, 2010, 28 pages.
  • US Final Office Action for U.S. Appl. No. 11/957,010, mailed Aug. 18, 2010, 25 pages.
  • US Final Office Action for U.S. Appl. No. 12/044,744 mailed Nov. 22, 2010, 14 pages.
  • US Non-Final Office Action for U.S. Appl. No. 12/145,536 mailed Nov. 8, 2010, 27 pages.
  • US Notice of Allowance for U.S. Appl. No. 11/938,082, mailed Jan. 4, 2011, 23 pgs.
  • US Final Office Action for U.S. Appl. No. 12/145,536, mailed Apr. 26, 2011, 34 pgs.
  • US Non-Final Office Action for U.S. Appl. No. 12/111,174, mailed Jun. 8, 2011, 35 pgs.
  • Wilde, Erik, “Multi-User Multimedia Editing with the MultimETH System,” Swiss Federal Institute of Technology, CH 8092, Zurich, (at least as early as Oct. 10, 2007) pp. 1-9, http://dret.net/netdret/docs/wilde-tikrep18.pdf.
  • International Search Report and Written Opinion for PCT/US2009/037920 mailed Nov. 30, 2009, 11 pages.
  • International Search Report and Written Opinion for PCT/US2009/045558 mailed Nov. 30, 2009, 11 pages.
  • U.S. Appl. No. 12/145,536, Amendment and Response filed Feb. 8, 2011. 18 pgs.
  • U.S. Appl. No. 12/145,536, Amendment and Response filed Jul. 26, 2011, 19 pgs.
  • U.S. Appl. No. 12/145,536, Office Action mailed Aug. 1, 2011, 37 pgs.
  • U.S. Appl. No. 11/938,082, Amendment and Response filed Mar. 25. 2010, 15 pgs.
  • U.S. Appl. No. 11/938,082, Amendment and Response filed Aug. 4, 2010. 14 pgs.
  • U.S. Appl. No. 11/951,973, Amendment and Response filed Apr. 13, 2011, 11 pgs.
  • U.S. Appl. No. 11/957,010 Amendment and Response filed Jun. 2, 2010, 12 pgs.
  • U.S. Appl. No. 11/957,010 Amendment and Response filed Nov. 17, 2010, 11 pgs.
  • U.S. Appl. No. 12/044,744 Amendment and Response filed Oct. 26, 2010, 11 pgs.
  • U.S. Appl. No. 12/044,744 Amendment and Response filed Feb. 22, 2011. 11 pgs.
  • U.S. Appl. No. 12/044,744 Amendment and Response filed Jun. 24, 2011, 11 pgs.
  • Bellagio, David et al., “Software Configuration Management Strategies and IBM Rational ClearCase A Practical Introduction, Second Edition” in: “Software Configuration Management Strategies and IBM Rational ClearCase A Practical Introduction, Second Edition”, May 23, 2005 , IBM Press, XP55009093, ISBN: 978-0-32-120019-8 pp. 173-178.
  • Chinese Office Action in Application 200880115943.1, mailed Oct. 25, 2011, 13 pgs.
  • European Extended Search Report in EP Application 09739350.8, mailed Nov. 9, 2011, 10 pgs.
  • U.S. Appl. No. 12/111,174, Office Action mailed Nov. 21, 2011, 20 pgs.
  • U.S. Appl. No. 11/957,010, Amendment and Response filed Nov. 16, 2011, 12 pgs.
  • U.S. Appl. No. 12/044,744, Amendment and Response filed Nov. 30, 2011, 12 pgs.
  • U.S. Appl. No. 12/145,536, Amendment and Response filed Nov. 30, 2011, 20 pgs.
  • Appleton, Brad, “ClearView: Associating Attributes and Notes With a View”, ClearCase International User's Group Conference, Sep. 1996, 16 pgs.
  • Byfield, Bruce, “Ooo Off the Wall: That's Your Version—Document Control in Ooo Writer”, published on Linux Journal, Mar. 7, 2006, 6 pgs.
  • lmmedius, Inc., “S1000Dmanager v 3.0”, Comprehensive S1000D Project Setup and Management Support, found online on Aug. 22, 2008 at: http://www.immediuss1000d.com/c—manager/S1Dmanager—overview.html, 6 pgs.
  • PCT International Search Report for PCT/US2009/062364 dated May 31, 2010, 11 pgs.
  • Samiei et al., “EzMail: Using Information Vizualization Techniques to Help Manage Email”, Proceedings of the 8th National Conference on Information Vizualization, 2004, 6 pgs.
  • U.S. Appl. No. 11/951,973, Notice of Allowance mailed Jun. 21, 2011, 9 pgs.
  • U.S. Appl. No. 11/957,010, Office Action mailed Aug. 17, 2011, 26 pgs.
  • U.S. Appl. No. 12/044,744, Final Office Action mailed Aug. 30, 2011, 17 pgs.
  • U.S. Appl. No. 12/111,174, Amendment and Response mailed Sep. 8, 2011, 11 pgs.
  • U.S. Appl. No. 12/117,040, Office Action mailed Oct. 4, 2011, 15 pgs.
  • U.S. Appl. No. 12/276,874, Amendment and Response filed Jun. 22, 2011, 17 pgs.
  • U.S. Appl. No. 12/276,874, Final Office Action mailed Aug. 3, 2011, 15 pgs.
  • U.S. Appl. No. 12/276,874, Office Action mailed Feb. 22, 2011, 15 pgs.
  • U.S. Appl. No.12/276,874, Office Action mailed Oct. 26, 2011, 18 pgs.
  • Venolia, Gina et al., “Understanding Sequence and Reply Relationships Within Email Conversations: A Mixed-Model Vizualization”, Apr. 2003, Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, Ft. Lauderdale, FL, USA, Apr. 5-10, 2003, 8 pgs.
  • Williams, Tim, “Version Control on the Cheap: A User-Friendly, Cost-Effective Revision Control System for SAS”, 10 pgs.
  • Zend Corporation, the PHP Company, “Team Development With Zend Studio for Eclipse”, White Paper, Jan. 2008, 17 pgs.
  • U.S. Appl. No. 13/079,605, Office Action mailed Dec. 5, 2011, 31 pgs.
  • U.S. Appl. No. 12/044,744, Office Action mailed Dec. 30, 2011, 17 pgs.
  • U.S. Appl. No. 11/957,010, Office Action mailed Jan. 27, 2012, 25 pgs.
  • U.S. Appl. No. 12/117,040, Amendment and Response filed Jan. 4, 2012, 12 pgs.
  • U.S. Appl. No. 12/276,874, Amendment and Response filed Jan. 26, 2012, 13 pgs.
  • Chinese Office Action in Application 200880119647.9, mailed Nov. 24, 2011, 7 pgs.
  • Chinese 1st Office Action in Application 200880121295.0, mailed Jan. 18, 2012, 6 pgs.
  • U.S. Appl. No. 12/111,174, Amendment and Response filed Feb. 21, 2012, 9 pgs.
  • Chinese Response filed Mar. 23, 2012, in Application No. 200880119647 (24 pgs).
  • Taiwan Search Report for Taiwan Invention Patent Application No. 097142418, researched on Feb. 14, 2012 (5 pgs).
  • United States Final Office Action mailed Mar. 12, 2012, in U.S. Appl. No. 12/145,536 (51 pgs).
  • United States Amendment and Response to Non-Final Office Action mailed Apr. 4, 2011, in U.S. Appl. No. 13/079,605, filed Feb. 28, 2012 (12 pgs).
Patent History
Patent number: 8176005
Type: Grant
Filed: May 8, 2008
Date of Patent: May 8, 2012
Patent Publication Number: 20090282041
Assignee: Microsoft Corporation (Redmond, WA)
Inventors: Simon Skaria (Sammamish, WA), Naresh Kannan (Seattle, WA), Simon Peter Clarke (Seattle, WA), Miko Arnab Sakhya Singha Bose (Seattle, WA), Christopher J. Antos (Bellevue, WA), Mark Rolland Knight (Bellevue, WA), Andrew G. Carlson (Redmond, WA), Don Adam Hedgpeth (Redmond, WA), Mitesh Pankaj Patel (Seattle, WA), Andrew Sean Watson (Seattle, WA), Jonathan B. Bailor (Bellevue, WA), Elena Petrova (Redmond, WA)
Primary Examiner: Don Wong
Assistant Examiner: Merilyn P Nguyen
Attorney: Merchant & Gould P.C.
Application Number: 12/117,025
Classifications
Current U.S. Class: Collaborative Document Database And Workflow (707/608); Concurrent Read/write Management Using Locks (707/704); File Systems (707/822)
International Classification: G06F 7/00 (20060101); G06F 17/30 (20060101); G06F 17/00 (20060101); G06F 12/00 (20060101);