專利名稱：一種建立復合文檔的方法、裝置及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及即時通訊技術領域，尤其涉及基于即時通訊軟件和復合文檔 技術的一種建立復合文檔的方法、裝置及系統(tǒng)。
背景技術：
在工程管理項目設計中，項目的結構框架、模塊劃分及業(yè)務流程是在該 項目設計中需要進行討論的重要內容。在討論過程中，將討論部分的圖示直 接展現(xiàn)在每個參與該項目設計的相關人員面前，能夠使討論的過程更加直 觀，并且可以根據(jù)實時討論的結果，對討論部分的內容不斷的修改完善，最 終獲得的滿意的結-論。
在工程管理項目設計中的文檔撰寫過程中， 一般將文檔分成多個模塊， 每個模塊的文檔描述分別由不同的人來完成，最終將多人完成的文檔描述內 容匯總。在匯總的過程中由于文檔是由不同人員完成的，所以需要管理者不 斷的與完成該文檔的多個人進行溝通，以調整各部分的文檔格式，并且針對 每個文檔的描述內容是否滿足要求，需要在管理者與相關人員之間進行溝通 后，才能得到所述文檔的最終版本。
綜合上述需求，工程管理項目設計中需要一種在對設計內容進行討論 時，能夠直觀地將需要討論的內容展現(xiàn)在參與該項目的相關人員之間，并且 每個人都能對討論內容進行實時修改的多人協(xié)作系統(tǒng)，來滿足這個需求。
目前，現(xiàn)有技術Google docs系統(tǒng)能夠提供一種在線的復合文檔編輯服 務，它是基于服務器的一種能夠取代桌面office套件的完備服務系統(tǒng)，基于 ajax (創(chuàng)建交互式網(wǎng)頁應用的網(wǎng)頁開發(fā)技術)、javascript (腳本語言)和open document (開》文性文檔)的。主要包4舌word、 presentation和電子表才各等。
雖然該系統(tǒng)可以提供強大的在線編輯服務，能夠提供完備的復合文檔標 準。但應用在工程管理項目中代價太大。因為在工程管理項目設計中不會出 現(xiàn)大量的復雜信息，并且信息交互量不大。
其次，在google docs中的多人協(xié)作是基于分享來實現(xiàn)的，不能對權限進 行劃分。也就是說，對于每個使用者，使用權限是平等的；但在工程管理項 目應用中，通常是由管理者總體把握每個用戶的權限，只有當某些內容需要 和參與該項目設計的其他人討論時，才進行交互；例如讓某個人修改某個
部分，設定權限后這個人只能對這部分內容進行修改、討論和管理，而不能 參與其他部分的修改或討論過程。
此外，google docs的應用是基于瀏覽器的，這樣就限制了其擴展性和效
率，并且需要大量高性能服務器的支撐。

發(fā)明內容
本發(fā)明要解決的技術問題是提供一種建立多人協(xié)作系統(tǒng)的方法、裝置 及系統(tǒng)，實現(xiàn)了在工程管理設計過程中的多人協(xié)作平臺。
本發(fā)明的提供了 一種建立多人協(xié)作系統(tǒng)的方法，該方法包括
根據(jù)復合文檔生成至少一個任務，并通過即時通訊的方式發(fā)送給所述任 務對應的至少一個用戶；
接收所述用戶通過即時通訊的方式發(fā)送的修改請求消息后，向所述用戶 發(fā)送允許修改的通知，并鎖定該任務；
接收所述用戶發(fā)送的針對該任務修改后的內容，并更新所述任務。
進一步的，所述接收用戶端通過即時通訊的方式發(fā)送的4奮改請求消息 后，該方法還包4舌
判斷所述任務的狀態(tài)，當所述任務的狀態(tài)為空閑時，向發(fā)送所述修改請求消息的用戶發(fā)送允許修改的通知，并鎖定該任務的狀態(tài)；當所述任務的狀
態(tài)被鎖定時，向其他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息。
進一步的，更新所述任務的具體過程包括
當接收到所述任務修改后的內容時，將該任務的狀態(tài)由鎖定設置為空 閑，并對所述修改后的內容進行審核，當確定修改時，用所述修改后的內容 更新所述任務；否則，不對所述任務進行更新，并向所述用戶發(fā)送修改失敗 消息。
進一步的，用所述修改后的內容更新所述任務的過程中還包括在更新 后的任務中添加本次^修改所述任務的用戶簽名。 進一步的，該方法還包括
中包含所述任務的內容及對應的管理;f又限信息，以指派所述任務代理用戶對 所述任務的修改及更新過程進行管理；
接收所述任務代理用戶發(fā)送的對該任務的更新結果，并審核，確定接受 時，保存該任務的更新結果。
本發(fā)明提供了 一種多人協(xié)作系統(tǒng)中的管理裝置，該裝置包括
任務管理模塊，用于根據(jù)復合文檔生成至少一個任務，并通過即時通訊 的方式發(fā)送給所述任務對應的至少 一個用戶；
消息處理模塊，用于在所述任務管理模塊將所述任務發(fā)送給該任務對應 的用戶后，接收用戶通過即時通訊的方式發(fā)送的修改請求消息，向用戶發(fā)送 允許修改的通知，并鎖定該任務；以及用于在接收所述用戶發(fā)送的針對該任 務修改后的內容后，更新所述任務。
優(yōu)選的，所述消息處理模塊具體包括
消息接收單元，用于接收用戶通過即時通訊的方式發(fā)送的修改請求消 息；以及接收所述用戶發(fā)送的針對該任務修改后的內容；消息執(zhí)行單元，用于在所述消息接收單元接收到所述修改請求消息時， 對所述任務的狀態(tài)進行判斷，當所述任務的狀態(tài)為空閑時，向所述用戶發(fā)送
允許修改的通知，并鎖定該任務的狀態(tài)；當所述任務的狀態(tài)被鎖定時，向其 他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息；以及，用于在所述消息接收 單元接收到針對所述任務修改后的內容時，將該任務的狀態(tài)由鎖定設置為空 閑，并對所述修改后的內容進行審核，當確定修改時，用所述修改后的內容 更新所述任務；否則，不對所述任務進行更新，并向所述用戶發(fā)送修改失敗 消息。
優(yōu)選的，所述裝置還包括
指派任務發(fā)送模塊，用于將所述任務管理模塊生成的所述任務，發(fā)送給 該任務對應的用戶中已選定的任務代理用戶，以指派所述任務代理用戶對該 任務的修改及更新過程進行管理；
果，并審核，確定接受時，保存所述更新結果。 優(yōu)選的，所述裝置還包括
務修改后的內容；還用于在當前所述任務的版本發(fā)生錯誤或針對所述任務進 行修改后的內容不滿足修改要求時，將當前所述任務的版本回溯到上一個版 本，以重新對所述任務進行管理。 優(yōu)選的，所述裝置還包括
一致性保障模塊，用于對生成的至少一個任務根據(jù)所述任務的完成時間 進行順序性及獨立性的管理。
本發(fā)明還提供了 一種建立多人協(xié)作系統(tǒng)的方法，該方法包括 通過即時通訊的方式接收管理服務器發(fā)來的根據(jù)復合文檔生成的至少一
個任務；當確定需要對該任務進行修改時，通過即時通訊的方式向所述管理服務 器發(fā)送修改請求消息，以請求所述管理服務器確定是否允許修改；
當接收到所述管理服務器發(fā)送的允許修改的通知后，將針對該任務修改 后的內容發(fā)送給所述管理服務器。
進一步的，所述方法還包括
接收所述管理服務器發(fā)送的任務指派消息，所述任務指派消息中包含所 述任務的內容及對該任務的管理權限，以對被指派的所述任務的修改及更新 過程進行管理；
接收其他用戶發(fā)送的與所述任務對應的修改后的內容，根據(jù)所述消息中 的管理權限對所述任務的更新進行管理，將更新結果發(fā)送給所述管理服務 器，以對所述更新結果進行審核。
本發(fā)明還提供了 一種多人協(xié)作系統(tǒng)中的用戶端裝置，該裝置包括 接收模塊，用于接收管理服務器通過實時通訊的方式，發(fā)來的根據(jù)復合
文檔生成的至少一個任務；以及用于接收所述管理服務器發(fā)送的允許修改的
通知；
發(fā)送模塊，用于在確定對該任務進行修改時，向管理服務器發(fā)送修改請 求消息，以請求管理服務器是否允許對所述任務進行修改；以及用于當所述 接收模塊接收到所述允許修改的通知后，將針對該任務修改后的內容發(fā)送給 所述管理服務器。
優(yōu)選的，所述裝置還包括
指派任務處理模塊，用于接收所述管理服務器發(fā)送的任務指派消息，所 述任務指派消息中包含所述任務的內容及對應的管理權限；接收其他用戶的 針對所述任務修改后的內容，并將所述內容發(fā)送給所述管理服務器，以對所 述內容進行審核。
優(yōu)選的，所述指派任務處理模塊具體包括指派任務接收單元，用于接收所述管理服務器發(fā)送的任務指派消息，所 述任務指派消息中包含所述任務的內容及對所述任務的管理權限，以對被指 派的所述任務的修改及更新過程進行管理；
改后的內容，根據(jù)所述消息中的管理權限對所述任務的更新進行管理，將更 新結果發(fā)送給所述管理服務器，以對所述任務的管理結果進行審核。
本發(fā)明提供了一種多人協(xié)作系統(tǒng)，該系統(tǒng)包括
多人協(xié)作系統(tǒng)中的管理裝置，用于根據(jù)復合文檔生成至少一個任務，并 通過即時通訊的方式發(fā)送給所述任務對應的至少一個用戶；當接收所述用戶 通過即時通訊的方式發(fā)送的修改請求消息后，向用戶發(fā)送允許修改的通知， 并鎖定該任務；當接收所述用戶發(fā)送的針對該任務修改后的內容信息，并更 新所述任務；
多人協(xié)作系統(tǒng)中的用戶端裝置，用于接收管理服務器發(fā)來的根據(jù)復合文 檔生成的至少一個任務；以及用于接收所述管理服務器發(fā)送的允許修改的通 知；當確定需要對該任務進行修改時，向管理服務器發(fā)送修改請求消息，以 請求管理服務器確定是否允許對所述任務進行修改；以及當接收到所述允許 修改的通知后，將針對該任務修改后的內容信息發(fā)送給所述管理服務器。
本發(fā)明的有益效果
本發(fā)明利用實時通訊軟件中客戶端的優(yōu)勢，實現(xiàn)了多人協(xié)作平臺，在應 用過程中，比現(xiàn)有4支術google docs系統(tǒng)更加高效、簡潔；
本發(fā)明實現(xiàn)了由管理服務器對該項目設計總體把握，可以給參與該項目 的用戶劃分修改權限，然后對修改后的內容，進行最終審核的功能；解決了 現(xiàn)有技術每個用戶的權限都是平等的，不能進行權限劃分的問題；
本發(fā)明是基于即時通訊軟件來實現(xiàn)的，比現(xiàn)有技術google docs系統(tǒng)，更加便于擴展，并且不需要象現(xiàn)有技術那樣，需要大量的高性能的服務器的支 持，節(jié)約了成本。


圖1為本發(fā)明實施例——種建立多人協(xié)作系統(tǒng)的方法簡化流程圖2為本發(fā)明實施例二一種多人協(xié)作系統(tǒng)中的管理裝置簡化結構示意圖3為本發(fā)明實施例三一種建立多人協(xié)作系統(tǒng)的方法簡化流程圖4為本發(fā)明實施例四 一種多人協(xié)作系統(tǒng)中的用戶端裝置簡化結構示意
圖5為本發(fā)明實施例五一種多人協(xié)作系統(tǒng)的結構示意圖。
具體實施例方式
下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行 清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而 不是全部的實施例。基于本發(fā)明中的實施例，本領域普通技術人員在沒有作 出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
本發(fā)明實施例提出了 一種基于即時通訊軟件建立多人協(xié)作系統(tǒng)的方法， 能夠在工程管理設計中，通過即時通訊的方式在項目設計人員之間傳遞復合 文檔，完成對該項目設計的修改過程。復合文檔技術是指在一個文件中支持 多種用不同格式對象，包括對象的顯示、編輯、存儲、創(chuàng)建和管理等，例如 常用的微軟office套件就是基于復合文檔在word中能夠處理表格、圖片等， 而且可以處理visio、 excel、 originlab等軟件所支持的對象。
在本發(fā)明實施例的技術方案中，通過管理服務器對整個項目的設計過程 以及參與該項目設計的用戶進行總體管理，將該項目設計中需要進行討論的內容建立成任務，在管理服務器與該任務相關的用戶之間通過即時通訊的方 式進行討論后，來完成對該任務的修改。并且管理服務器能夠對參與該任務 的用戶設置管理權限，當存在多個任務時，管理服務器可以在與該項目相關 的用戶中指定該任務的任務代理用戶，對該任務的修改和更新過程進行管 理。管理服務器對任務代理用戶的管理結果進行最終審核，以完成對該任務 的修改完善。
為了便于更好的理解本發(fā)明所述的技術方案，下面通過優(yōu)選實施例進一 步說明。
實施例一
如圖1所示，本發(fā)明實施例——種建立多人協(xié)作系統(tǒng)的方法，該方法可以 包括
步驟S101:根據(jù)復合文檔生成至少一個任務，并通過即時通訊的方式發(fā) 送給所述任務對應的至少一個用戶；
在實施例一中，所述任務的生成方式可以包括
由管理服務器通過復合文檔編輯器在項目設計文檔中選擇需要修改的內 容，將需要修改的內容部分定義成一個任務，管理服務器對整個任務的完成 過程進行操作；
所述復合文檔編輯器，是根據(jù)Open Document國際標準的，支持少數(shù)幾 個基本對象的復合文檔編輯器，實現(xiàn)復合文檔的顯示、編輯及存儲功能。
管理服務器將所述任務發(fā)送給該任務對應的用戶時可以采用一對一或一 對多的消息傳遞模式，這樣參與該任務的所有用戶都會接收到包含所述任務 的消息。
在任務建立后，管理服務器邀請參與該任務設計的相關用戶加入所述任 當用戶收到所述消息后向管理服務器發(fā)送回應消息，確定自己在線，并加入該任務中。
步驟S102:接收所述用戶通過即時通訊的方式發(fā)送的修改請求消息后， 向所述用戶發(fā)送允許修改的通知，并鎖定該任務；
步驟S103:接收所述用戶發(fā)送的針對該任務修改后的內容，并更新所述 任務。
具體地說，接收所述用戶通過即時通訊的方式發(fā)送的修改請求消息后， 該方法還可以包4舌
步驟S102':判斷所述任務的狀態(tài)，當所述任務的狀態(tài)為空閑時，向發(fā)送 所述修改請求消息的用戶發(fā)送允許修改通知，并鎖定該任務的狀態(tài)；當所述 任務的狀態(tài)^皮鎖定時，向其他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息。
本發(fā)明優(yōu)選實施例一中，可以通過將所述任務的狀態(tài)由空閑設置為忙 碌，來對所述任務進行鎖定。
管理服務器與加入該任務的用戶進行修改內容部分的討論，以討論如何 完成所述任務；當用戶A希望修改所述任務時，向管理服務器提交修改申請 (即修改請求消息)，這時管理服務器就要對該任務的狀態(tài)是否被鎖定進行 判斷。例如用戶A要在文檔的某個對象中添加一個矩形，那么在從畫一條邊 開始，到用戶完成修改并提交所述修改內容的過程中間，不能有其他用戶來 從中途對這個對象進行操作，來干擾用戶A的修改過程，所以為了保證每個用 戶在修改任務時內容的完整性，在用戶A發(fā)出修改請求時，管理服務器要判斷 該任務的狀態(tài)是否空閑，當空閑時，接收用戶A的修改請求，并發(fā)出允許修改 通知消息，并將該任務的狀態(tài)鎖定，即到用戶遞交完成修改的內容之前，其 他用戶向管理服務器發(fā)送修改請求消息，都會被拒絕，其他用戶對所述任務 只有讀的權限。
具體地說，所述接收所述用戶發(fā)送的針對該任務修改后的內容的具體過 程可以包4舌步驟S103':當接收到所述該任務修改后的內容時，將該任務的狀態(tài)由鎖 定設置為空閑，并對所述修改后的內容進行判斷，當確定修改時，用所述修 改后的內容更新所述任務；否則，對所述任務不進行更新，向所述用戶發(fā)送 修改失敗消息。
本發(fā)明優(yōu)選實施例中，在管理服務器接收到用戶提交的針對所述任務修 改后的內容時，將鎖定的任務解鎖，即將所述任務的狀態(tài)由鎖定設置為空
討論，因為當所述用戶修改完畢后，會提交自己對該任務修改后的內容，可 以通過一對一或一對多消息發(fā)送模式進行提交，這樣包括管理服務器在內的 所有參與該項目的用戶，都可以看到修改的內容，這樣管理服務器會與每個 用戶通過即時通訊的方式進行討論，當討論結果確定接收所述修改后的內容 時，用該內容更新所述任務；否則，將修改后的內容丟棄；當有其他用戶發(fā) 送修改請求時，發(fā)送允許修改消息。
括在用所述修改后的內容更新所述任務時，在所述更新后的任務中添加對 所述任務進行修改的用戶簽名。
說明在更新后的內容中添加用戶簽名，用于管理服務器在每次更新 后，保證本次修改的用戶與本次修改內容的一致性，避免用戶與修改內容的 不一致。
具體地說，本發(fā)明實施例中所述方法還可以包括向所述任務對應的用 戶中的任務代理用戶發(fā)送任務指派消息，所述消息中包含所述任務的內容及 對應的管理權限信息，以指派所述任務代理用戶對所述任務的修改及更新過 程進行管理；接收所述任務代理用戶發(fā)送的對該任務的更新結果，并審核， 確定接受時，保存該任務的更新結果。
說明管理服務器可以對參與該任務的用戶設置管理權限，當有多個任務產(chǎn)生時，可以在參與該任務的用戶中指定一個任務代理用戶，發(fā)送任務指 派消息，以對所述任務的修改及更新過程進行管理，當任務代理用戶將所述 任務更新完畢后，將更新結果發(fā)送給管理服務器進行最終審核，當確認接受
時，將當前任務的更新結果保存；否則，放棄當前任務的更新結果，將所述
任務的版本回溯到上一個版本。 實施例二
如圖2所示，本發(fā)明實施例一種多人協(xié)作系統(tǒng)中的管理裝置，該裝置可以 包括
任務管理模塊S11，用于根據(jù)復合文檔生成至少一個任務，并通過即時通 訊的方式發(fā)送給所述任務對應的至少 一個用戶；
其中，本發(fā)明實施例二中任務的生成過程與實施例一中相似，不再贅
述；
所述任務管理模塊可以通過一對一或一對多的消息傳遞模式將生成的所 述任務發(fā)送給與該任務對應的所述用戶。
消息處理模塊S12，用于在所述任務管理模塊將所述任務發(fā)送給該任務對 應的所述用戶后，接收用戶通過即時通訊的方式發(fā)送的修改請求消息，向用 戶發(fā)送允許修改的通知，并鎖定該任務；以及用于在接收所述用戶發(fā)送的針 對該任務修改后的內容時，更新所述任務。
本實施例中所述消息處理模塊在對所述任務的狀態(tài)進行判斷后，向發(fā)出 修改請求的用戶發(fā)送允許修改通知時，對該任務鎖定的過程，與實施例一中 相似，不再贅述。
優(yōu)選的，本發(fā)明實施例二所述消息處理模塊具體可以包括
消息接收單元S121,用于接收所述用戶通過即時通訊的方式發(fā)送的修改 請求消息；以及接收所述用戶發(fā)送的針對該任務修改后的內容；
消息執(zhí)行單元S122，用于在所述消息接收單元接收到所述修改請求消息時，對所述任務的狀態(tài)進行判斷，當所述任務狀態(tài)為空閑時，向所述用戶發(fā) 送允許修改的通知，并鎖定該任務的狀態(tài)；當所述任務的狀態(tài)被鎖定時，向
其他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息；以及，用于在所述消息接 收單元接收到所述針對該任務修改后的內容時，將該任務的狀態(tài)由鎖定設置 為空閑，并對所述修改后的內容進行審核，當確定修改時，用所述修改后的 內容更新所述任務；否則，不對所述任務進行更新，并向所述用戶發(fā)送修改 失敗消息。
優(yōu)選的，本發(fā)明實施例所述裝置還可以包括
指派任務發(fā)送模塊S13,用于將所述任務管理模塊生成的所述任務，發(fā)送 給該任務對應的用戶中已選定的任務代理用戶，以指派所述任務代理用戶對 該任務的修改及更新過程進行管理；
任務審核模塊S14，用于接收所述任務代理用戶發(fā)送的對該任務更新后的 結果，并審核，確定接受時，保存所述更新結果。
具體地說，管理服務器可以在與所述任務相關的用戶中選擇一個用戶作 為任務代理用戶來管理所述任務的處理過程；例如當管理服務器根據(jù)復合 文檔生成了多個任務時，管理服務器將文檔中需要和某些人討論修改的"系 統(tǒng)框架圖，，建立成一個任務，所述管理服務器可以將這個任務指派給與該任 務相關的用戶A作為任務代理用戶來管理所述任務，管理服務器可以將整個任 務修改及更新的過程交付給任務代理用戶管理，將更新的最終結果發(fā)送給管 理服務器，進行最終審核，由管理服務器來確認是否接收對所述任務的更新 結果。
本發(fā)明實施例二中為了保證所述任務更新內容的可回溯性，所述裝置中 還可以包4舌
任務修改后的內容；還用于在當前所述任務的版本發(fā)生錯誤或針對所述任務進行修改后的內容不滿足修改要求時，將當前所述任務的版本回溯到上一個 版本，以重新對所述任務進行管理。
也可以用于復合文檔的版本控制，即當前版本不滿意時，直接清空所述 任務，打開前一個文檔，重新開始。
本發(fā)明實施例二為了保證管理服務器建立的每個任務的一致性，例如 當存在多個任務時，要保證每個任務之間的互斥和同步，尤其對于某個任務 是要在另一個任務完成后才能開始的，必須要保證這種順序性，所以所述裝
置中還可以包括
一致性保障模塊S16，用于對生成的至少一個任務根據(jù)所述任務的完成時
間進行順序性及獨立性的管理。 實施例三
如圖3所示，本發(fā)明一種建立多人協(xié)作系統(tǒng)的方法，該方法可以包括
步驟S201:通過即時通訊的方式接收管理服務器發(fā)來的根據(jù)復合文檔生 成的至少一個任務；
步驟S202:當確定需要對該任務進行修改時，通過即時通訊的方式向所 述管理服務器發(fā)送修改請求消息，以請求管理服務器確定是否允許修改；
步驟S203:當接收到管理服務器發(fā)送的允許修改的通知后，將針對該任 務修改后的內容發(fā)送給所述管理服務器。
本發(fā)明實施例中，對所述任務進行修改是通過復合文檔編輯器來實現(xiàn) 的，所述復合編輯器是根據(jù)Open Document國際標準的，支持少數(shù)幾個基本 對象的復合文檔編輯器，實現(xiàn)復合文檔的顯示、編輯及存儲功能。
本發(fā)明實施例中所述用戶通過一對一或一對多的消息傳遞模式，將針對 所述任務修改后的內容發(fā)送給包含管理服務器在內的，與該任務相關的用 戶，所有參與該任務的成員都可以參照修改內容，進行討論。
具體地i兌，本發(fā)明實施例所述方法還可以包才舌步驟S201':接收所述管理服務器發(fā)送的任務指派消息，所述任務指派消 息中包含所述任務的內容及對該任務的管理權限，以對被指派的所述任務的 修改及更新過程進行管理；
據(jù)所述消息中的管理權限對所述任務的更新進行管理，將更新結果發(fā)送給所 述管理服務器，以對所述更新結果進行審核。
當有用戶發(fā)送修改請求消息時，判斷所述任務的狀態(tài)是否被鎖定，當允許修 改時，向發(fā)出修改請求的用戶發(fā)送允許修改通知，并接收其他用戶發(fā)送的針 對所述任務修改后的內容，然后對所述內容進行審核，確定更新，將更新結 果發(fā)送給管理服務器進行最終審核。
實施例四
如圖4所示，本發(fā)明實施例一種多人協(xié)作系統(tǒng)中的用戶端裝置，該裝置可 以包括
接收模塊S21,用于接收管理服務器通過實時通訊的方式，發(fā)來的根據(jù)復 合文檔建立的至少一個任務；以及用于接收所述管理服務器發(fā)送的允許修改 的通知；
發(fā)送模塊S22，用于在確定對該任務進行修改時，向管理服務器發(fā)送修改 請求消息，以請求管理服務器是否允許對所述任務進行修改；以及用于當所 述接收模塊接收到所述允許修改的通知后，將針對該任務修改后的內容信息 發(fā)送給所述管理服務器。
具體地說，本發(fā)明實施例所述裝置還可以包括
指派任務處理模塊S23，用于接收所述管理服務器發(fā)送的任務指派消息， 所述任務指派消息中包含所述任務的內容及對應的管理權限；接收其他用戶 的針對所述任務修改后的內容，并將所述內容發(fā)送給所述管理服務器，以對所述內容進行審核。
更具體的說，所述指派任務處理模塊具體可以包括
指派任務接收單元S231,用于接收所述管理服務器發(fā)送的任務指派消
息，所述任務指派消息中包含所述任務的內容及對所述任務的管理權限，以
對被指派的所述任務的修改及更新過程進行管理；
務修改后的內容，根據(jù)所述消息中的管理權限對所述任務的更新進行管理， 將更新結果發(fā)送給所述管理服務器，以對所述任務的管理結果進行審核。
本實施例中用戶接收指定任務以及對所述指定任務修改過程進行管理的 具體過程，與實施例三中所述的過程一致，不再詳細贅述。
實施例五
如圖5所示，本發(fā)明實施例一種多人協(xié)作系統(tǒng)，包括
如實施例二中所述多人協(xié)作系統(tǒng)中的管理裝置S51,用于根據(jù)復合文檔生 成至少一個任務，并通過即時通訊的方式發(fā)送給所述任務對應的至少一個用 戶；當接收用戶通過即時通訊的方式發(fā)送的修改請求消息后，向用戶發(fā)送允 許修改的通知，并鎖定該任務；當接收所述用戶發(fā)送的針對該任務修改后的 內容信息，并更新所述任務；
如實施例四中所述多人協(xié)作系統(tǒng)中的用戶端裝置S52，用于接收管理服務 器發(fā)來的根據(jù)復合文檔建立的至少一個任務；以及用于接收所述管理服務器 發(fā)送的允許修改的通知；
當確定需要對該任務進行修改時，向管理服務器發(fā)送修改請求消息，以 請求管理服務器是否允許對所述任務進行修改；以及在接收到所述允許修改 的通知后，將針對該任務修改后的內容發(fā)送給所述管理服務器。
本發(fā)明實施例五中，包含了所述實施例二和實施例四中技術方案的內 容，將所述多人協(xié)作系統(tǒng)中的管理裝置和多人協(xié)作系統(tǒng)中的用戶端裝置組合在一起，實現(xiàn)了多人協(xié)作系統(tǒng)，具體內容在上述實施例二及實施例四中已經(jīng) 具體闡述過，在此不再贅述。
以上所述，僅為本發(fā)明較佳的具體實施方式
，但本發(fā)明的保護范圍并不 局限于此，任何熟悉本技術領域的技術人員在本發(fā)明揭露的技術范圍內，可 輕易想到的變化或替換，都應涵蓋在本發(fā)明的保護范圍之內。因此，本發(fā)明 的保護范圍應該以權利要求的保護范圍為準。
權利要求
1、一種建立多人協(xié)作系統(tǒng)的方法，其特征在于，包括根據(jù)復合文檔生成至少一個任務，并通過即時通訊的方式發(fā)送給所述任務對應的至少一個用戶；接收所述用戶通過即時通訊的方式發(fā)送的修改請求消息后，向所述用戶發(fā)送允許修改的通知，并鎖定該任務；接收所述用戶發(fā)送的針對該任務修改后的內容，并更新所述任務。
2、 根據(jù)權利要求1所述的方法，其特征在于，所述接收用戶端通過即時 通訊的方式發(fā)送的i奮改請求消息后，該方法還包括判斷所述任務的狀態(tài)，當所述任務的狀態(tài)為空閑時，向發(fā)送所述修改請 求消息的用戶發(fā)送允許修改的通知，并鎖定該任務的狀態(tài)；當所述任務的狀 態(tài)被鎖定時，向其他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息。
3、 根據(jù)權利要求1所述的方法，其特征在于，更新所述任務的具體過程 包括當接收到所述任務修改后的內容時，將該任務的狀態(tài)由鎖定設置為空 閑，并對所述修改后的內容進行審核，當確定修改時，用所述修改后的內容 更新所述任務；否則，不對所述任務進行更新，并向所述用戶發(fā)送修改失敗 消息。
4、 根據(jù)權利要求3所述的方法，其特征在于，用所述修改后的內容更新 所述任務的過程中還包括在更新后的任務中添加本次修改所述任務的用戶簽名。
5、 根據(jù)權利要求1所述的方法，其特征在于，該方法還包括中包含所述任務的內容及對應的管理權限信息，以指派所述任務代理用戶對所述任務的修改及更新過程進行管理；接收所述任務代理用戶發(fā)送的對該任務的更新結果，并審核，確定接受 時，保存該任務的更新結果。
6、 一種多人協(xié)作系統(tǒng)中的管理裝置，其特征在于，包括 任務管理模塊，用于根據(jù)復合文檔生成至少一個任務，并通過即時通訊的方式發(fā)送給所述任務對應的至少一個用戶；消息處理模塊，用于在所述任務管理模塊將所述任務發(fā)送給該任務對應 的用戶后，接收用戶通過即時通訊的方式發(fā)送的修改請求消息，向用戶發(fā)送 允許修改的通知，并鎖定該任務；以及用于在接收所述用戶發(fā)送的針對該任 務修改后的內容后，更新所述任務。
7、 根據(jù)權利要求6所述的裝置，其特征在于，所述消息處理模塊具體包括消息接收單元，用于接收用戶通過即時通訊的方式發(fā)送的修改請求消 息；以及接收所述用戶發(fā)送的針對該任務修改后的內容；消息執(zhí)行單元，用于在所述消息接收單元接收到所述修改請求消息時， 對所述任務的狀態(tài)進行判斷，當所述任務的狀態(tài)為空閑時，向所述用戶發(fā)送 允許修改的通知，并鎖定該任務的狀態(tài)；當所述任務的狀態(tài)被鎖定時，向其 他發(fā)送修改請求消息的用戶發(fā)送請求失敗消息；以及，用于在所述消息接收 單元接收到針對所述任務修改后的內容時，將該任務的狀態(tài)由鎖定設置為空 閑，并對所述修改后的內容進行審核，當確定修改時，用所述修改后的內容 更新所述任務；否則，不對所述任務進行更新，并向所述用戶發(fā)送^f奮改失敗 消息。
8、 根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括指派任務發(fā)送模塊，用于將所述任務管理模塊生成的所述任務，發(fā)送給 該任務對應的用戶中已選定的任務代理用戶，以指派所述任務代理用戶對該任務的修改及更新過程進行管理；果，并審核，確定接受時，保存所述更新結果。
9、 根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括務修改后的內容；還用于在當前所述任務的版本發(fā)生錯誤或針對所述任務進 行修改后的內容不滿足修改要求時，將當前所述任務的版本回溯到上一個版 本，以重新對所述任務進行管理。
10、 根據(jù)權利要求6所述的裝置，其特征在于，所述裝置還包括 一致性保障模塊，用于對生成的至少一個任務根據(jù)所述任務的完成時間進行順序性及獨立性的管理。
11、 一種建立多人協(xié)作系統(tǒng)的方法，其特征在于，包括通過即時通訊的方式接收管理服務器發(fā)來的根據(jù)復合文檔生成的至少一個任務；當確定需要對該任務進行修改時，通過即時通訊的方式向所述管理服務 器發(fā)送修改請求消息，以請求所述管理服務器確定是否允許修改；當接收到所述管理服務器發(fā)送的允許修改的通知后，將針對該任務修改 后的內容發(fā)送給所述管理服務器。
12、 根據(jù)權利要求11所述的方法，其特征在于，所述方法還包括 接收所述管理服務器發(fā)送的任務指派消息，所述任務指派消息中包含所述任務的內容及對該任務的管理權限，以對被指派的所述任務的修改及更新 過程進行管理；消息中的管理權限對所述任務的更新進行管理，將更新結果發(fā)送給所述管理 服務器，以對所述更新結果進行審核。
13、 一種多人協(xié)作系統(tǒng)中的用戶端裝置，其特征在于，包括 接收模塊，用于接收管理服務器通過實時通訊的方式，發(fā)來的根據(jù)復合文檔生成的至少一個任務；以及用于接收所述管理服務器發(fā)送的允許修改的 通知；發(fā)送模塊，用于在確定對該任務進行修改時，向管理服務器發(fā)送修改請 求消息，以請求管理服務器是否允許對所述任務進行修改；以及用于當所述 接收模塊接收到所述允許修改的通知后，將針對該任務修改后的內容發(fā)送給 所述管理服務器。
14、 根據(jù)權利要求13所述的裝置，其特征在于，所述裝置還包括 指派任務處理模塊，用于接收所述管理服務器發(fā)送的任務指派消息，所述任務指派消息中包含所述任務的內容及對應的管理權限；接收其他用戶的 針對所述任務修改后的內容，并將所述內容發(fā)送給所述管理服務器，以對所 述內容進行審核。
15、 根據(jù)權利要求14所述的裝置，其特征在于，所述指派任務處理模塊 具體包括指派任務接收單元，用于接收所述管理服務器發(fā)送的任務指派消息，所 述任務指派消息中包含所述任務的內容及對所述任務的管理權限，以對被指 派的所述任務的修改及更新過程進行管理；改后的內容，根據(jù)所述消息中的管理權限對所述任務的更新進行管理，將更 新結果發(fā)送給所述管理服務器，以對所述任務的管理結果進行審核。
16, —種多人協(xié)作系統(tǒng)，其特征在于，包括如權利要求6、 7、 8、 9或10所述多人協(xié)作系統(tǒng)中的管理裝置，用于根據(jù) 復合文檔生成至少一個任務，并通過即時通訊的方式發(fā)送給所述任務對應的 至少一個用戶；當接收所述用戶通過即時通訊的方式發(fā)送的^f'務改請求消息 后，向用戶發(fā)送允許修改的通知，并鎖定該任務；當接收所述用戶發(fā)送的針 對該任務修改后的內容信息，并更新所述任務；如權利要求13、 14或15所述多人協(xié)作系統(tǒng)中的用戶端裝置，用于接收管 理服務器發(fā)來的根據(jù)復合文檔生成的至少一個任務；以及用于接收所述管理 服務器發(fā)送的允許修改的通知；當確定需要對該任務進行修改時，向管理服務器發(fā)送修改請求消息，以 請求管理服務器確定是否允許對所述任務進行修改；以及當接收到所述允許 修改的通知后，將針對該任務修改后的內容信息發(fā)送給所述管理服務器。
全文摘要
本發(fā)明公開了一種建立多人協(xié)作系統(tǒng)的方法，該方法包括根據(jù)復合文檔生成至少一個任務，并通過即時通訊的方式發(fā)送給所述任務對應的至少一個用戶；接收所述用戶在收到通過即時通訊的方式發(fā)送的修改請求消息后，向用戶發(fā)送允許修改的通知，并鎖定該任務；接收所述用戶發(fā)送的針對該任務修改后的內容，并更新所述任務。本發(fā)明還提供了一種多人協(xié)作系統(tǒng)及裝置。采用本發(fā)明所述技術方案，實現(xiàn)了在工程管理設計過程中的多人協(xié)作平臺，便于項目設計中管理者與設計人員通過實時溝通，以對需要討論的復合文檔的內容進行不斷的修改及完善。
文檔編號G06Q10/00GK101477658SQ20091007794
公開日2009年7月8日 申請日期2009年2月4日 優(yōu)先權日2009年2月4日
發(fā)明者周曉波 申請人:騰訊科技(深圳)有限公司