專利名稱：：一種電子合同管理系統(tǒng)及其實(shí)現(xiàn)方法
技術(shù)領(lǐng)域：
：本發(fā)明涉及互聯(lián)網(wǎng)通信技術(shù)應(yīng)用領(lǐng)域，尤其涉及一種電子合同管理系統(tǒng)及其實(shí)現(xiàn)方法。
背景技術(shù)：
：隨著互聯(lián)網(wǎng)技術(shù)的發(fā)展，尤其是寬帶技術(shù)的興起，網(wǎng)絡(luò)數(shù)字傳媒產(chǎn)業(yè)也得到了高速發(fā)展。當(dāng)前，隨著互聯(lián)網(wǎng)應(yīng)用的曰益普及，除了網(wǎng)絡(luò)購(gòu)物之外，許多傳統(tǒng)的媒體行業(yè)，如電影、電視、新聞、出版業(yè)等的業(yè)務(wù)以及辦公自動(dòng)化等計(jì)算機(jī)應(yīng)用技術(shù)也越來(lái)越向網(wǎng)絡(luò)化方向發(fā)展，與此相關(guān)的業(yè)務(wù)在互聯(lián)網(wǎng)上進(jìn)行交易也變得越來(lái)越頻繁，但是，由于互聯(lián)網(wǎng)的開放性，網(wǎng)上交易的規(guī)范性、真實(shí)性等得不到有效的安全保障，導(dǎo)致即使合法的網(wǎng)上交易雙方的權(quán)利與義務(wù)也往往很難落實(shí)，這就容易給交易雙方造成經(jīng)濟(jì)上的損失，如果這種網(wǎng)上交易存在網(wǎng)絡(luò)安全缺陷被非法利用，這種損失將是難以估量的。目前許多國(guó)家已通過(guò)了電子簽名法，隨著《中華人民共和國(guó)電子簽名法》的實(shí)施，也拉開了我國(guó)電子合同應(yīng)用的序幕，使得電子商務(wù)活動(dòng)從此有章可循。然而，電子簽名并非書面簽名的數(shù)字圖像化，而是一種電子代碼，利用它，收件人可以輕松驗(yàn)證發(fā)件人的身份和簽名，以實(shí)現(xiàn)信息傳輸?shù)谋Ｃ苄?、?shù)據(jù)交換信息的完整性、所發(fā)送信息的不可否認(rèn)性、交易者身份的確定性，即實(shí)現(xiàn)電子商務(wù)網(wǎng)絡(luò)安全的四大要素。電子簽名的實(shí)現(xiàn)方式有很多種，如基于公鑰基礎(chǔ)設(shè)施(PKI,PublicKeyInfrastructure)的數(shù)字簽名就是其中一種電子簽名的實(shí)現(xiàn)形式，而其中最有實(shí)際意義的只有公鑰密碼理論。電子簽名雖然具備技術(shù)中立性，使用電子簽名也能夠滿足網(wǎng)上交易的安全性要求，但在實(shí)際網(wǎng)絡(luò)應(yīng)用環(huán)境下，單純依賴電子簽名并不能滿足電子合同更高的安全性、可靠性要求。
發(fā)明內(nèi)容有鑒于此，本發(fā)明的主要目的在于提供一種電子合同管理系統(tǒng)，能夠滿足網(wǎng)上電子商務(wù)交易的安全平臺(tái)的要求。本發(fā)明的另一目的在于提供一種電子合同管理系統(tǒng)的實(shí)現(xiàn)方法，以進(jìn)一步提高網(wǎng)上電子商務(wù)交易的安全性、可靠性。為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的一種電子合同管理系統(tǒng)，包括外部通信接口、數(shù)據(jù)接口以及數(shù)據(jù)庫(kù)，該系統(tǒng)還包括合同生成模塊、合同分發(fā)模塊、交易信息收發(fā)模塊、合同查詢模塊；其中，外部通信接口，用于接受來(lái)自外部的訪問(wèn)請(qǐng)求以及向請(qǐng)求者返回電子合同管理系統(tǒng)的反饋信息；數(shù)據(jù)接口，用于連接和訪問(wèn)電子合同管理系統(tǒng)內(nèi)部數(shù)據(jù)庫(kù)的資源；數(shù)據(jù)庫(kù)，用于存放電子合同內(nèi)容、電子合同交易信息以及合同交易雙方的其他相關(guān)信息；合同生成模塊，用于接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息，并生成電子合同；合同分發(fā)模塊，用于將所生成的電子合同發(fā)送給電子合同簽約的買賣雙方；交易信息收發(fā)模塊，用于接收并記錄提供方與接受方之間的交易信息，并將交易成功的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心；合同查詢模塊，用于接收查詢請(qǐng)求，并根據(jù)查詢請(qǐng)求返回電子合同中的相關(guān)信息。一種電子合同管理系統(tǒng)的實(shí)現(xiàn)方法，該方法包括a、電子合同管理系統(tǒng)通過(guò)接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息，生成電子合同；b、將所生成的電子合同內(nèi)容信息加密后傳遞給所述接受方及提供方；c、交互控制所述接受方或提供方與所述合同管理系統(tǒng)間進(jìn)行加密的電子合同交易信息的傳遞；d、當(dāng)收到所述接受方和提供方的交易上報(bào)信息后，進(jìn)行解密，并進(jìn)行MD5驗(yàn)證，并根據(jù)驗(yàn)證結(jié)果，修改電子合同的當(dāng)前狀態(tài)。較佳地，該方法進(jìn)一步包括一種電子合同的查詢方法所述電子合同管理系統(tǒng)接收到查詢請(qǐng)求，依據(jù)查詢類型對(duì)存儲(chǔ)于數(shù)據(jù)庫(kù)內(nèi)的電子合同的各項(xiàng)內(nèi)容進(jìn)行查閱，并生成查詢結(jié)果。所述電子合同管理系統(tǒng)的實(shí)現(xiàn)方法，步驟d之后進(jìn)一步包括e、將所述電子合同管理系統(tǒng)成功交易的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心，或?qū)⒔灰缀蟮碾娮雍贤畔l(fā)送給網(wǎng)絡(luò)交易的監(jiān)管方。其中，步驟a所述接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息為提供方注冊(cè)到互聯(lián)網(wǎng)上的服務(wù)器頁(yè)面前端所提供的商品信息。步驟a所述電子合同的信息為XML格式的文件，所述信息內(nèi)容至少包括合同號(hào)、提供方身份標(biāo)識(shí)ID、商品ID、提供方網(wǎng)關(guān)綁定信息、接受方身份標(biāo)識(shí)ID。步驟b所述將生成的電子合同內(nèi)容信息加密后傳遞給所述接受方及提供方為bl、合同分發(fā)模塊周期性地檢查已生成電子合同內(nèi)容信息(實(shí)際為合同狀態(tài))，并根據(jù)合同狀態(tài)識(shí)別新生成電子合同以及未發(fā)送成功的電子合同；b2、將所述新產(chǎn)生的電子合同及未發(fā)送成功的電子合同加密后，發(fā)送給合同履行的接受方、提供方作為交易依據(jù)。步驟c所述交互控制所述接受方或提供方與所述合同管理系統(tǒng)間進(jìn)行加密的電子合同交易信息的傳遞，該過(guò)程為cl、所述接受方或提供方將交易上報(bào)信息發(fā)送給電子合同管理系統(tǒng)；c2、電子合同管理系統(tǒng)對(duì)其進(jìn)行解密，并判斷所述交易上報(bào)信息有無(wú)錯(cuò)誤，若有錯(cuò)誤，則丟棄該交易上報(bào)信息數(shù)據(jù)，并提示出錯(cuò)信息；否則，通過(guò)交易信息收發(fā)模塊向提供方或接受方發(fā)送Response消息；c3、電子合同管理系統(tǒng)偵聽所述接受方或提供方返回的ACK消息，若偵聽到ACK消息，則更改所述電子合同的狀態(tài)，否則結(jié)東本次交易過(guò)程。所述加密電子合同內(nèi)容信息或電子合同交易信息的過(guò)程為將所要發(fā)送的電子合同內(nèi)容信息或電子合同交易信息先計(jì)算出MD5摘要，附加到所述電子合同內(nèi)容信息或電子合同交易信息中，生成對(duì)稱密鑰并用對(duì)稱密鑰對(duì)附加了MD5的數(shù)據(jù)內(nèi)容進(jìn)行對(duì)稱加密，然后用所述電子合同管理系統(tǒng)的私鑰對(duì)對(duì)稱密鑰進(jìn)行第一次RSA加密，再用對(duì)方公鑰進(jìn)行第二次RSA加密，最后將加密后的信息和對(duì)稱加密后的信息進(jìn)行組合。所述電子合同管理系統(tǒng)在收到接受方或提供方上報(bào)的交易信息后，解密并進(jìn)行MD5驗(yàn)證，并修改電子合同的當(dāng)前狀態(tài)的過(guò)程為當(dāng)接受方或提供方接收到加密后的電子合同信息后，提供方首先計(jì)算出數(shù)字媒體資源的MD5摘要，發(fā)送給電子合同管理系統(tǒng)；接受方在收到數(shù)字媒體資源后，計(jì)算出媒體資源的MD5摘要，并發(fā)送給電子合同管理系統(tǒng)；當(dāng)電子合同管理系統(tǒng)收到交易雙方上報(bào)的交易成功的信息后，對(duì)交易雙方傳來(lái)的MD5摘要進(jìn)行比較，若兩者內(nèi)容相同，通過(guò)交易信息收發(fā)模塊向接受方發(fā)送該媒體資源的解密密鑰，接受方接收到密鑰后使用密鑰解密所收到的數(shù)字媒體資源，并向電子合同管理系統(tǒng)發(fā)送ACK消息，電子合同管理系統(tǒng)收到ACK消息后，修改所述電子合同的狀態(tài)。本發(fā)明所提供的電子合同管理系統(tǒng)及其實(shí)現(xiàn)方法，具有以下優(yōu)點(diǎn)本發(fā)明對(duì)網(wǎng)上電子商務(wù)交易所生成的電子合同的內(nèi)容進(jìn)行加密。即用隨機(jī)生成的密鑰DES加密合同信息，再對(duì)隨機(jī)密鑰使用對(duì)方的公鑰進(jìn)行RSA加密。然后將加密后的電子合同發(fā)送給接受方及提供方。當(dāng)接受方收到電子合同交易信息時(shí)，使用私鑰解密出加密的密鑰，然后再解密所攜帶的電子合同交易信息的內(nèi)容。通過(guò)這種加密傳送電子合同內(nèi)容及電子合同交易信息的技術(shù)，保證了網(wǎng)上電子商務(wù)交易的安全性、可靠性。圖1為本發(fā)明實(shí)施例中電子合同管理系統(tǒng)的功能框圖；圖2為本發(fā)明實(shí)施例中電子合同管理系統(tǒng)與接受方、提供方、網(wǎng)絡(luò)交易的監(jiān)管方及計(jì)費(fèi)中心之間的關(guān)系示意圖3為本發(fā)明實(shí)施例中合同生成模塊的信息處理流程圖；圖4為本發(fā)明實(shí)施例中合同分發(fā)模塊的信息處理流程圖；圖5為本發(fā)明實(shí)施例中交易信息收發(fā)模塊的信息處理流程圖圖6為本發(fā)明實(shí)施例中合同查詢模塊的信息處理流程圖。具體實(shí)施例方式下面結(jié)合附圖及本發(fā)明的實(shí)施例對(duì)本發(fā)明的方法作進(jìn)一步詳細(xì)的說(shuō)明。本發(fā)明以電子商務(wù)活動(dòng)中數(shù)字媒體內(nèi)容商之間的交易過(guò)程為例，對(duì)本發(fā)明實(shí)施例中電子合同管理系統(tǒng)的合同生成、合同分發(fā)、合同交易信息收發(fā)、電子合同查詢模塊及電子合同管理系統(tǒng)的實(shí)現(xiàn)方法進(jìn)行詳細(xì)描述。以下是對(duì)實(shí)現(xiàn)本發(fā)明電子合同管理系統(tǒng)及其實(shí)現(xiàn)方法所涉及的計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)，網(wǎng)絡(luò)安全要求以及數(shù)據(jù)傳輸安全三方面的簡(jiǎn)要介紹首先，本發(fā)明所涉及的計(jì)算機(jī)網(wǎng)絡(luò)技術(shù)。數(shù)字媒體的內(nèi)容接受方，即買方通過(guò)瀏覽數(shù)字媒體內(nèi)容提供方，即賣方發(fā)布在互聯(lián)網(wǎng)上的媒體資源信息并達(dá)成購(gòu)買意向，前提是必須提供發(fā)布數(shù)字媒體內(nèi)容銷售和求購(gòu)信息以及達(dá)成交易意向的平臺(tái)。這一交易平臺(tái)可以通過(guò)JAVA技術(shù)來(lái)實(shí)現(xiàn)，也可以通過(guò)其他技術(shù)來(lái)實(shí)現(xiàn)，本發(fā)明以基于Spring+Struts+Hibemate技術(shù)為基礎(chǔ)來(lái)實(shí)現(xiàn)本發(fā)明方案的。這里，所述Spring是一個(gè)開源的項(xiàng)目，它具有下列優(yōu)點(diǎn)基于反向控制(IoC，InversionofControl)和面向切面的程序設(shè)計(jì)(AOP)構(gòu)架的多層J2EE系統(tǒng)的框架，但它不要求在每一層中必須使用Spring,由于它的模塊化性能很好，允許根據(jù)自身的需要選擇使用它的某一個(gè)模塊；實(shí)現(xiàn)了很優(yōu)雅的模型可視控制(MVC,Model-View-Controller)，對(duì)不同的數(shù)據(jù)訪問(wèn)技術(shù)提供了統(tǒng)一的接口，釆用IoC可以很容易實(shí)現(xiàn)Bean的裝配，提供了簡(jiǎn)潔的AOP并據(jù)此實(shí)現(xiàn)事務(wù)管理(TransactionManagement)。所述Struts與Tomcat、Turbine等諸多Apache項(xiàng)目一樣，屬于開源軟件。它可使開發(fā)者能更深入地了解其內(nèi)部實(shí)現(xiàn)機(jī)制，Struts開放源碼框架的創(chuàng)建能夠使開發(fā)者在構(gòu)建基于JavaServlet和JSP(JavaServerPages)技術(shù)的Web應(yīng)用時(shí)更加容易。所述Hibernate是一個(gè)開放源代碼的對(duì)象關(guān)系映射框架，它對(duì)JAVA數(shù)據(jù)庫(kù)連接(JDBC)進(jìn)行了輕量級(jí)的對(duì)象封裝，使得JAVA程序員可以隨心所欲地使用對(duì)象編程思維來(lái)操縱數(shù)據(jù)庫(kù)。其次，本發(fā)明所涉及的網(wǎng)絡(luò)安全方面的技術(shù)要求，即實(shí)現(xiàn)數(shù)據(jù)加密、完整性、防偽造和抗抵賴的要求。所述對(duì)數(shù)據(jù)進(jìn)行加密是保護(hù)信息免受非法攻擊和竊取的有效手段。由于網(wǎng)絡(luò)環(huán)境的開放性和復(fù)雜性，對(duì)于重要數(shù)據(jù)的保護(hù)相應(yīng)提出的要求會(huì)更高。電子合同管理系統(tǒng)與其他系統(tǒng)的數(shù)據(jù)傳輸均處于開放的互聯(lián)網(wǎng)環(huán)境中，因此需要加密效果更好的加密算法。RSA算法是目前最常用的非對(duì)稱加密算法，具有很好的安全性，并經(jīng)過(guò)了長(zhǎng)期的考驗(yàn)，但在加密大量數(shù)據(jù)時(shí)運(yùn)行速度比較慢。對(duì)稱加密算法DES加密計(jì)算速度快，但是密鑰傳遞困難。本系統(tǒng)采用RSA與DES結(jié)合的加密算法，使用DES算法加密數(shù)據(jù)內(nèi)容，使用RSA算法對(duì)數(shù)據(jù)量極小的DES密鑰進(jìn)行加密，這樣既保證了數(shù)據(jù)的安全性，又加快計(jì)算速度。所述完整性要求是確保信息不被修改，對(duì)于網(wǎng)絡(luò)信息來(lái)說(shuō)，完整性是針對(duì)信息流的服務(wù)，它需要確保接收的信息和發(fā)送的信息是一樣的，沒(méi)有被篡改、插入、重排序或者延遲。在合同管理系統(tǒng)中，對(duì)加密前的數(shù)據(jù)計(jì)算MD5(Message-DigestAlgorithm5)摘要，并將MD5摘要附在要傳輸?shù)臄?shù)據(jù)后面。由于附帶MD5摘要的數(shù)據(jù)被加密過(guò)，所以數(shù)據(jù)的完整性可以在解密和在MD5摘要對(duì)比中發(fā)現(xiàn)，本系統(tǒng)不提供防止數(shù)據(jù)完整性被破壞的機(jī)制，但可以通過(guò)以上的措施偵測(cè)到數(shù)據(jù)完整性被破壞的數(shù)據(jù)，這樣的數(shù)據(jù)將被丟棄，并被要求重傳，這樣也可以保證數(shù)據(jù)的正常傳輸。所述防偽造和抗抵賴也是合同管理系統(tǒng)必須具備的要求。如果系統(tǒng)不能辨別偽造，將生成無(wú)效的合同并給非偽造的另一方帶來(lái)?yè)p失，另外抵賴行為也會(huì)給合同的一方帶來(lái)?yè)p失。由于RSA技術(shù)本身也有身份認(rèn)證的作用，合同管理系統(tǒng)將RSA和MD5結(jié)合起來(lái)，既使用RSA的身份認(rèn)證，也對(duì)合同雙方對(duì)同一數(shù)據(jù)計(jì)算的MD5摘要進(jìn)行對(duì)比，將兩者結(jié)合起來(lái)實(shí)現(xiàn)防偽造和抗抵賴功能。最后，介紹與數(shù)據(jù)傳輸相關(guān)的技術(shù)。本電子合同管理系統(tǒng)所生成的合同要發(fā)送到簽訂合同的雙方，同一時(shí)刻可能與幾千甚至上萬(wàn)的內(nèi)容商進(jìn)行數(shù)據(jù)傳輸，如果使用TCP連接去傳輸數(shù)據(jù)，對(duì)合同管理系統(tǒng)來(lái)說(shuō)，需要同時(shí)維護(hù)很多的TCP連接，這樣不僅占用很多資源，同時(shí)也增加了維護(hù)的困難。結(jié)合合同管理系統(tǒng)本身數(shù)據(jù)傳輸?shù)奶攸c(diǎn)，本系統(tǒng)使用用戶數(shù)據(jù)報(bào)協(xié)議(UDP)與數(shù)字媒體內(nèi)容商進(jìn)行數(shù)據(jù)傳輸。但UDP的無(wú)連接性會(huì)使得發(fā)送過(guò)程無(wú)法確定對(duì)方是否收到發(fā)送給它的信息。為了解決這個(gè)問(wèn)題，本系統(tǒng)對(duì)網(wǎng)絡(luò)通信中傳統(tǒng)的三次握手機(jī)制進(jìn)行了改造，來(lái)保證信息收發(fā)的完成。與傳統(tǒng)的三次握手不同的是，每次握手均包含了有效的信息。這樣，通過(guò)多次握手將與數(shù)據(jù)完整性、防偽造和防抵賴的信息包含進(jìn)來(lái)，既完成了信息收發(fā)，又提高了系統(tǒng)的效率和穩(wěn)定性。圖1為本發(fā)明實(shí)施例中電子合同管理系統(tǒng)的功能框圖，如圖l所示，該電子合同管理系統(tǒng)包括合同生成模塊101、合同分發(fā)模塊102、交易信息收發(fā)模塊103、合同查詢模塊104、外部通信接口105、數(shù)據(jù)接口106以及數(shù)據(jù)庫(kù)107;其中，合同生成模塊101，用于接收來(lái)自數(shù)字媒體內(nèi)容提供方與數(shù)字媒體內(nèi)容接受方之間達(dá)成的買賣合同信息，并生成電子合同。合同分發(fā)模塊102，用于將所生成的電子合同發(fā)送給電子合同簽約的買賣雙方。交易信息收發(fā)模塊103,用于接收并記錄提供方和接受方上報(bào)的交易信息，并將交易成功的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心。合同查詢模塊104,用于接收查詢請(qǐng)求，并根據(jù)查詢請(qǐng)求返回電子合同中的相關(guān)信息。外部通信接口105,用于接受來(lái)自外部的訪問(wèn)請(qǐng)求以及向請(qǐng)求者返回電子合同管理系統(tǒng)的反饋信息。所述外部的訪問(wèn)請(qǐng)求，是指包括來(lái)自互聯(lián)網(wǎng)的系統(tǒng)注冊(cè)用戶的信息瀏覽、查詢、網(wǎng)絡(luò)交易等信息請(qǐng)求。數(shù)據(jù)接口106，用于連接和訪問(wèn)電子合同管理系統(tǒng)內(nèi)部數(shù)據(jù)庫(kù)107的資源。數(shù)據(jù)庫(kù)107，用于存放電子合同內(nèi)容、電子合同交易信息以及合同交易雙方的其他相關(guān)信息，如曰志文件等。圖2為本發(fā)明實(shí)施例中電子合同管理系統(tǒng)與接受方、提供方、網(wǎng)絡(luò)交易的監(jiān)管方及計(jì)費(fèi)中心之間的關(guān)系示意圖。如圖2所示電子合同管理系統(tǒng)負(fù)責(zé)向交易的接受方和提供方發(fā)送電子合同，并負(fù)責(zé)處理接受方和提供方上報(bào)的交易信息。在交易完成后，將交易成功的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心，并將交易完成后的相關(guān)合同信息提供給網(wǎng)絡(luò)交易的監(jiān)管方。電子合同管理系統(tǒng)將所生成的電子合同發(fā)送給需要交易的買賣雙方的網(wǎng)關(guān)，并接收提供方網(wǎng)關(guān)A和接受方網(wǎng)關(guān)B所發(fā)的確認(rèn)信息，此外，還接收提供方網(wǎng)關(guān)A所傳遞的與媒體資源內(nèi)容相關(guān)的其他信息，這些信息包括交易雙方的標(biāo)識(shí)、媒體資源的解密密鑰、媒體資源的內(nèi)容摘要等。電子合同管理系統(tǒng)是通過(guò)交易雙方的網(wǎng)關(guān)進(jìn)行交易的中介，負(fù)責(zé)生成電子合同并監(jiān)督所述電子合同的傳輸全程以及執(zhí)行情況。所述電子合同管理系統(tǒng)根據(jù)雙方的交易意向生成合同并發(fā)往簽訂合同的雙方。所述雙方是指提供方網(wǎng)關(guān)A以及接受方網(wǎng)關(guān)B。所述提供方網(wǎng)關(guān)A在接收到電子合同后，將要交易的媒體資源進(jìn)行加密，并將所加密媒體資源的MD5摘要以及加密密鑰發(fā)送給電子合同管理系統(tǒng)。所述接受方網(wǎng)關(guān)B收到電子合同后，連接發(fā)送方網(wǎng)關(guān)A并接收加密的數(shù)字媒體資源。當(dāng)提供方網(wǎng)關(guān)A將媒體資源發(fā)送到接受方網(wǎng)關(guān)B后，接受方網(wǎng)關(guān)B將所接收的數(shù)字媒體資源的MD5摘要計(jì)算出來(lái)，發(fā)送給電子合同管理系統(tǒng)；電子合同管理系統(tǒng)對(duì)雙方的MD5摘要進(jìn)行對(duì)比，如果兩者內(nèi)容相同，則發(fā)送密鑰給接受方網(wǎng)關(guān)B。接受方網(wǎng)關(guān)B接收到密鑰后，用密鑰解密所收到的數(shù)字媒體資源。在一次交易過(guò)程中，電子合同管理系統(tǒng)與網(wǎng)關(guān)A、網(wǎng)關(guān)B分別有多次消息交互，分別發(fā)生在合同分發(fā)的過(guò)程與上報(bào)交易信息的過(guò)程中。電子合同管理系統(tǒng)與網(wǎng)關(guān)A、網(wǎng)關(guān)B之間所有的交互消息均釆用UDP方式傳輸，消息內(nèi)容以雙重加密的方式封裝成UDP消息即先使用隨機(jī)生成的密鑰DES加密消息內(nèi)容，并對(duì)隨機(jī)密鑰進(jìn)行RSA加密，然后將兩者拼接，在頭部標(biāo)出UDP消息包的總長(zhǎng)度，以及對(duì)密鑰RSA加密后的長(zhǎng)度。所述電子合同管理系統(tǒng)與網(wǎng)關(guān)A、網(wǎng)關(guān)B之間的UDP消息包的信息格式，如下表一所示表一<table>tableseeoriginaldocumentpage13</column></row><table>當(dāng)所述網(wǎng)關(guān)接收到該數(shù)據(jù)包時(shí)，先用私鑰對(duì)密鑰解密，然后再使用密鑰解出消息內(nèi)容。電子合同管理系統(tǒng)與交易雙方網(wǎng)關(guān)的交互過(guò)程中，若提供方提供給電子合同管理系統(tǒng)的MD5摘要不正確，則當(dāng)數(shù)字媒體資源發(fā)送到接受方網(wǎng)關(guān)B后，接受方網(wǎng)關(guān)B所提供的MD5摘要將不能與提供方網(wǎng)關(guān)A所提供的摘要內(nèi)容匹配，此時(shí)交易就不能正常進(jìn)行，所以提供方網(wǎng)關(guān)A如果故意或無(wú)意提供錯(cuò)誤的MD5摘要將無(wú)法受益；若提供方所提供的MD5摘要正確而加密密鑰不正確，則接受方網(wǎng)關(guān)B就不能解密該數(shù)字商品，同時(shí)提供方也不能強(qiáng)行認(rèn)定密鑰是正確的，因?yàn)樗峁┑腗D5摘要可以證明，這樣，此次的交易就會(huì)失敗，因而提供方網(wǎng)關(guān)A無(wú)論無(wú)意或故意提供錯(cuò)誤的加密密鑰也不能從虛假合同中受益。另一方面，若接受方網(wǎng)關(guān)B收到加密后的數(shù)字媒體資源后，如果不提供正確的MD5摘要就不能收到加密密鑰，仍然是無(wú)法解開數(shù)據(jù)進(jìn)行查看的，因此對(duì)于接受方網(wǎng)關(guān)B來(lái)說(shuō)這樣做就亳無(wú)意義了。但是，如果雙方都提供了正確的MD5摘要、接收到正確的密鑰后，就無(wú)法再抵賴，因?yàn)樗峁┑腗D5摘要可以保證它所得到的密鑰是正確的、也是唯一的。這樣，電子合同管理系統(tǒng)作為中介，既保證了網(wǎng)上交易活動(dòng)的正常進(jìn)行，同時(shí)也避免了雙方中的任意一方無(wú)理抵賴的情況。另外，作為監(jiān)管網(wǎng)上交易活動(dòng)的第三方，規(guī)定其具有查看電子合同信息的權(quán)限，同時(shí)還可以監(jiān)管該電子合同的執(zhí)行情況。此外，在每次交易完成后，需要將交易成功的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心，進(jìn)行相關(guān)費(fèi)用的本發(fā)明實(shí)施例的電子合同管理系統(tǒng)的整體工作流程，是合同生成模塊101接收網(wǎng)絡(luò)交易的買賣雙方需求信息生成電子合同模板，然后由合同分發(fā)模塊102將合同內(nèi)容信息分別發(fā)送給交易的雙方，再由合同交易信息收發(fā)模塊103對(duì)分發(fā)后的合同交易情況進(jìn)行處理；為了便于了解當(dāng)前電子合同在處理流程中的狀態(tài)，可以通過(guò)合同查詢模塊104對(duì)電子合同所處在各個(gè)流程中的詳細(xì)情況進(jìn)行查看。以下是對(duì)本發(fā)明實(shí)施例的電子合同管理系統(tǒng)中各功能模塊的工作流程進(jìn)行分別描述。圖3為本發(fā)明實(shí)施例中合同生成模塊的信息處理流程圖，如圖3所示，該方法包括步驟301:合同生成模塊接收購(gòu)買或銷售信息。這里，所述合同生成模塊接受購(gòu)買或銷售信息，是指接入互聯(lián)網(wǎng)絡(luò)的計(jì)算機(jī)或其他能夠?yàn)g覽Web頁(yè)面的通信終端訪問(wèn)提供網(wǎng)絡(luò)購(gòu)物的網(wǎng)站即注冊(cè)服務(wù)器，通過(guò)網(wǎng)絡(luò)選擇所需媒體資源后，提交所選的媒體資源信息給合同生成模塊的過(guò)程。所述信息，至少包括數(shù)字媒體資源的名稱、數(shù)字媒體的描述摘要、交易方式、交易金額等項(xiàng)內(nèi)容。所述數(shù)字媒體資源，為一種特殊的商品，如音頻文件，如樂(lè)曲、歌曲等，或者視頻文件，如電影、電視劇、視頻片段等。此外還可以是文字、圖片等可以通過(guò)互聯(lián)網(wǎng)進(jìn)行傳遞的數(shù)據(jù)信息。步驟302:判斷是否超出合同生成模塊的當(dāng)前處理能力，如果超出，則執(zhí)行步驟303;否則，執(zhí)行步驟304。這里，所述判斷合同生成模塊的當(dāng)前處理能力，是指電子合同管理系統(tǒng)同一時(shí)刻能夠處理的購(gòu)買或銷售信息的數(shù)目。步驟303:將購(gòu)買或銷售信息存儲(chǔ)在系統(tǒng)的緩存區(qū)內(nèi)，然后返回步驟302。這里，所述購(gòu)買或銷售信息在處理能力允許的情況下可取出后進(jìn)行處理。步驟304:判斷正在處理的信息中是否有內(nèi)容相同的重復(fù)信息，如果有，則執(zhí)行步驟307;否則，執(zhí)行步驟305。這里，所述判斷是否有內(nèi)容相同的重復(fù)信息，是為了避免這些內(nèi)容相同的多條信息形成多個(gè)重復(fù)的電子合同造成資源浪費(fèi)。步驟305:檢查當(dāng)前待處理的購(gòu)買或銷售信息的格式。這里，所述檢查信息的格式，是指檢查該信息是否為XML格式進(jìn)行組織的，例如a、數(shù)字媒體內(nèi)容接受方發(fā)來(lái)的信息格式為<xmlversion="1.0"encoding="UTF-8"><xs:schemaxmlns:xs="http:〃www.w3.org/2001/XMLSchema"><xs:elementname="agreement"><xs:complexType><xs:s6qu6nc6>〈xs:elementname="sequenceID"type="xs:long"/><xs:elementname="ReceiverID"type="xs:long"/>〈xs:elementname="ReceiverName"type="xs:string7><xs:elementname="ReceiverGate"type="xs:string"/><xs:elementname="ReceiverCertificate"type="xs:string"/><xs:elementname="ProviderInfo"minOccurs="1"maxOccurs="unbounded"><xs:complexType><xs:ssqu6nc6>〈xs:elementname="ProviderID"type="xs:long"/>〈xs:elementname="ProviderName"type="xs:string'7>〈xs:elementname="ProviderGate"type="xs:string"/><xs:elementname="ProviderCertificate"type="xs:string"/>〈xs:elementname="ResInfo"minOccurs="1"maxOccurs="unbounded"><xs:complexType><xs:ssqucnc6>〈xs:elementname="ResID"type="xs:long'7><xs:elementname="ResName"type="xs:string7><xs:elementname="Abstract"type="xs:string'7>〈xs:elementname="PurchaseMode"type="xs:string7〉<xs:elementname="purchaseMoney"type="xs:decimal7><xs:elementname="ratio"type="xs:decimar/><xs:elementname="AccessAuthor"type="xs:string'7>〈xs:elementname="Punish"type="xs:string7></xs:ssqu6ncs></xs:complexType></xs:element></xs:s6qu6ncc></xs:complexType></xs:element></xs:sequence></xs:complexType></xs:element></xs:schema>b、媒體內(nèi)容提供方發(fā)來(lái)的信息格式為<xmlversion="1.0"encoding="UTF-8">〈xs:schemaxmlns:xs="http:〃www.w3.org/200l/XMLSchema">〈xs:elementname="agreement"><xs:complexType><xs:ssqucnc6>〈xs:elementname="sequenceID"type="xs:long"/><xs:elementname="ProviderID"type="xs:long"/><xs:elementname="ProviderName"type="xs:string"/>〈xs:elementname="ProviderGate"type="xs:string'V>〈xs:elementname="ProviderCertificate"type="xs:string"/>〈xs:elementname="RecdverInfo"minOccurs="1"maxOccurs="unbounded"><xs:complexType><xs:S6qu6nc6><xs:elementname="ReceiverID"type="xs:long'7><xs:elementname="ReceiverName"type="xs:string"/>〈xs:elementname="ReceiverGate"type="xs:string'V><xs:elementname="ReceiverCertificate"type="xs:string"/><xs:elementname=''HesInfo"minOccurs="1"maxOccurs="unbounded"><xs:complexType><xs:SGquence>〈xs:elementname="ResID"type="xs:long"/><xs:elementname="ResName"type="xs:string"/><xs:elementname="Abstract"type="xs:string"/>〈xs:elementname="PurchaseMode"type="xs:string"/>〈xs:elementname="purchaseMoney"type="xs:decimal"/><xs:elementname="ratio"type="xs:decimar/><xs:elementname-"AccessAuthor"type="xs:string'V>〈xs:elementname="Punish"type="xs:string"/></xs:sequence></xs:complexType></xs:elem6nt></xs:sequ6nc6></xs:complexType></xs:element></xs:ssqu6nc6></xs:complexType></xs:elsm6nt></xs:schema>步驟306:判斷所述信息的格式是否符合要求，如果不符合格式要求，則執(zhí)行步驟309;否則，執(zhí)行步驟310。這里，所述信息的格式是否符合要求，是指提供方、接受方的交互信息是否符合步驟305中所述的XML格式。步驟307:對(duì)電子合同的生成情況進(jìn)行檢査。這里，所述檢查電子合同生成情況，是指依據(jù)所述信息系統(tǒng)中是否已經(jīng)為該內(nèi)容重復(fù)的購(gòu)買或銷售信息生成了電子合同。步驟308:判斷內(nèi)容重復(fù)的信息是否已經(jīng)生成了電子合同，如果沒(méi)有生成電子合同，則執(zhí)行步驟309;否則，執(zhí)行步驟311。步驟309:向接受方或提供方返回出錯(cuò)信息。這里，所述出錯(cuò)信息，是指能夠指示當(dāng)前的錯(cuò)誤類型、錯(cuò)誤號(hào)的信息。步驟310:生成電子合同，并加以存儲(chǔ)。這里，所述電子合同內(nèi)容的條目包括合同號(hào)、流水號(hào)、提供方ID等內(nèi)容，如表二所示。表二<table>tableseeoriginaldocumentpage18</column></row><table>其他費(fèi)用OtherSum買金額為總費(fèi)用，其他費(fèi)用為0，為出租則，前者為底金，后者為分成比例使用權(quán)限AccessA她or描述購(gòu)買者對(duì)購(gòu)買的數(shù)字媒體資源的具體使用權(quán)限違規(guī)處理Punish描述合同雙方中一方違約的處理規(guī)定提供方網(wǎng)關(guān)綁定信息ProviderGate描述提供方網(wǎng)關(guān)的LP和端口接受方網(wǎng)關(guān)綁定信息ReceiverGate描述接受方M關(guān)的IP和端口提供方公鑰ProviderPublickey記錄提供方的公鑰接受方公鑰ReceiverPublickey記錄接受方的公鑰合同狀態(tài)AgreementState記錄合同的狀態(tài)提供方交易信息ProDeallnfo提供方上報(bào)的交易信息接受方交易信息RecDeallnfo接受方1-.報(bào)的交易信息媒體資源密鑰R6sourccKcy交易的媒體資源的加密密鑰合同MD5AgrMD5交易的媒體資源的MD5摘要備注信息dssc其他備注信息步驟311:給接受方或提供方返回電子合同成功生成的提示信息。圖4為本發(fā)明實(shí)施例中合同分發(fā)模塊的信息處理流程圖，如圖4所示，該方法包括步驟401:周期性地檢查已生成的合同數(shù)據(jù)。這里，所述周期性地檢查已生成的合同數(shù)據(jù)，是定時(shí)接收由合同生成模塊生成的有效合同，包括新生成的電子合同以及本次檢查之前生成的、還未發(fā)送的電子合同或合同只成功發(fā)送給其中的一方而另一方?jīng)]有發(fā)送成功。步驟402:判斷是否有新生成的電子合同或未發(fā)送成功的電子合同，如果有，則執(zhí)行步驟403;否則，執(zhí)行步驟408。這里，所述判斷是否有新生成的電子合同或未發(fā)送成功的電子合同，是根據(jù)電子合同的狀態(tài)進(jìn)行識(shí)別。步驟403:逐個(gè)發(fā)送新生成的電子合同或前次未發(fā)送成功的電子合同及其電子合同信息。這里，如果需要發(fā)送的是新生成的電子合同，則均需要向接受方、提供方發(fā)送電子合同；若處理的是前次未發(fā)送成功的電子合同，則首先檢查是否已經(jīng)向接受方發(fā)送過(guò)合同，若沒(méi)有發(fā)送過(guò)，則啟動(dòng)一個(gè)線程向接受方發(fā)送一次合同；若已發(fā)送過(guò)，則不向接受方重復(fù)發(fā)送合同；此時(shí)，再檢查系統(tǒng)是否已經(jīng)向提供方發(fā)送過(guò)合同，如果沒(méi)有發(fā)送過(guò)，則啟動(dòng)一個(gè)線程向提供方發(fā)送合同；若已發(fā)送過(guò)，則不再單獨(dú)向提供方發(fā)送合同。以上所述過(guò)程，無(wú)論是啟動(dòng)線程向接受方發(fā)送，還是向提供方發(fā)送，發(fā)送過(guò)程基本一致。發(fā)送和接收的信息都是經(jīng)過(guò)加密的，要發(fā)送的數(shù)據(jù)先計(jì)算出MD5摘要附加到后面，然后隨即生成的密鑰并用密鑰對(duì)附加了MD5的數(shù)據(jù)進(jìn)行對(duì)稱加密，然后使用合同管理系統(tǒng)的私鑰對(duì)密鑰進(jìn)行RSA加密，再用對(duì)方公鑰進(jìn)行第二次RSA加密，將加密后的密鑰信息和對(duì)稱加密后的信息組合在一起形成要發(fā)送的信息。所述電子合同信息，包括交易雙方ID、數(shù)字媒體資源ID、交易雙方IP等。步驟404:判斷是否收到響應(yīng)(Response)消息，如果沒(méi)有收到，則執(zhí)行步驟408;否則，執(zhí)行步驟405。這里，所述判斷是否收到Response,是本發(fā)明的電子合同管理系統(tǒng)將加密后的合同數(shù)據(jù)向接受方或提供方發(fā)送，同時(shí)偵聽Response消息。步驟405:檢查Response消息是否正確，若正確，則執(zhí)行步驟406;否則，返回步驟404。這里，如果系統(tǒng)收到Response消息，則對(duì)Response消息進(jìn)行檢查，檢查的過(guò)程如下對(duì)所收到信息的前部進(jìn)行兩次解密，如果能成功解密，則認(rèn)為所收到的Response消息是正確的；否則，丟棄該信息并繼續(xù)偵聽，直到超時(shí)仍沒(méi)有收到Response消息則終止。步驟406:向接受方或提供方發(fā)送確認(rèn)(ACK)消息，然后執(zhí)行步驟407。這里，所述接受方、提供方若收到正確的Response信息，則生成ACK信息并發(fā)送給對(duì)方，同時(shí)更改電子合同當(dāng)前的狀態(tài)。步驟407:提供方或接受方收到ACK消息后，檢查本周期內(nèi)的電子合同是否全部發(fā)送完畢，若未發(fā)送完，則返回步驟403;否則，返回步驟401進(jìn)行下一個(gè)檢查周期的電子合同的處理過(guò)程。步驟408:結(jié)東本模塊的處理過(guò)程。圖5為本發(fā)明實(shí)施例中交易信息收發(fā)模塊的信息處理流程圖，如圖5所示,該方法包括步驟501:接收到接受方、提供方的交易上報(bào)信息。步驟502:判斷系統(tǒng)對(duì)交易上報(bào)信息的處理能力是否超負(fù)荷，如果是，則執(zhí)行步驟503;否則，執(zhí)行步驟504。步驟503:存儲(chǔ)交易信息，并將交易信息的狀態(tài)設(shè)置為允許再次取出后進(jìn)行處理，然后返回步驟502。步驟504:解密接受方、提供方上報(bào)的交易信息。這里，對(duì)接收到接受方、提供方的交易上報(bào)信息進(jìn)行解密，如果解密失敗，則丟棄該交易上報(bào)信息。解密后的信息進(jìn)行檢查，即完整性檢查。所述交易信息的完整性是指電子合同中的關(guān)鍵項(xiàng)的內(nèi)容，至少包括合同ID、所上報(bào)信息的提供方或接受方的標(biāo)識(shí)、交易是否成功的標(biāo)識(shí)、媒體資源的MD5摘要等信息。步驟505:判斷對(duì)所述交易上報(bào)信息是否解密成功，如果成功，則執(zhí)行步驟507;否則執(zhí)行步驟506。這里，所述判斷交易信息是否有錯(cuò)誤，是指交易信息是否完整。步驟506:丟棄該交易上報(bào)信息。步驟507:發(fā)送Response消息。這里，所述發(fā)送Response消息是指交易信息收發(fā)模塊返回給接受方或提供方的確認(rèn)信息以及包含密鑰的信息。具體為如果接受方提交的是"交易失敗"消息，則交易信息收發(fā)模塊返回確認(rèn)信息；如果接受方提交的是"交易成功"消息，則交易信息收發(fā)模塊則將從交易的數(shù)字媒體資源中提取MD5摘要與提供方提供的MD5摘要進(jìn)行對(duì)比，若兩者相同，則把數(shù)字媒體資源的解密密鑰附加在所返回的確認(rèn)信息中返回給接受方；若不相同，則只給接受方返回確認(rèn)信息。步驟508:判斷是否偵聽到提供方或接受方發(fā)回的ACK消息，如果有，則執(zhí)行步驟509;如果沒(méi)有，則重復(fù)執(zhí)行507，直到收到ACK為止。這里，所述ACK消息為接受方或提供方返回給交易信息收發(fā)模塊的消息。無(wú)論是接受方還是提供方，收到Response信息后，都會(huì)給合同管理系統(tǒng)的交易信息收發(fā)模塊返回一個(gè)ACK消息。步驟509:對(duì)ACK消息進(jìn)行處理，并更改合同的狀態(tài)。步驟510:將交易成功的合同中的賬務(wù)信息發(fā)送到計(jì)費(fèi)中心。這里，所述向計(jì)費(fèi)中心發(fā)送的合同賬務(wù)信息，可按照以下示例格式進(jìn)行<xmlversion="1.0"><contract><datasource><contact—id>2</contact_id><provider—id>3</provider—id><user—id>4</user_id><media_id>l8</media_id><media—name〉集結(jié)號(hào)</media—name><purchase—manner>2</purchase_manner〉<rate>0.40</rate><money>500</money></datasource></contract>其中，各個(gè)標(biāo)簽的含義如下<contact—id>:合同號(hào)；<provider_id>:提供方ID;<user—id>:內(nèi)容接受方即接受方ID;<media—id>:媒體資源ID;<media—name>:媒體資源名稱；<purchase—manner>:接受方式包括一次性付清，用"1"表示；出租，用"2"表示；<rate>:提成比例，出租方式中，用戶每次購(gòu)買媒體資源，內(nèi)容接受方需要給提供方的提成比例，如"0.40"則表示內(nèi)容接受方需要將用戶購(gòu)買費(fèi)用的40%給提供方，如果是一次性付清的方式，則為O;<m0ney>:如果是一次性付清方式，則表示一次性付清的價(jià)格；如果是出租方式，則表示底金。計(jì)費(fèi)中心返回給合同管理系統(tǒng)的信息格式如下<xmlversion-"1.0"><contract><datasource><contact—id>2</contact—id><state>successftil</state></datasource></contract>其中，各個(gè)標(biāo)簽含義<contact_id>:返回收到的電子合同的合同號(hào)；<state>:接收成功還是失??；以上合同交易信息傳輸?shù)倪^(guò)程中，所收發(fā)的交易信息的加密和解密過(guò)程與合同分發(fā)模塊的過(guò)程完全相同，因此不再贅述。圖6為本發(fā)明實(shí)施例中合同查詢模塊的信息處理流程圖，如圖6所示，該過(guò)程包括步驟601:合同查詢模塊接收查詢請(qǐng)求。這里，所述查詢請(qǐng)求，可以是來(lái)自交易雙方的，也可以是來(lái)自網(wǎng)絡(luò)交易活動(dòng)的監(jiān)管方。步驟602:分析査詢類型。所述分析查詢類型，具體為系統(tǒng)依據(jù)查詢請(qǐng)求的具體指令，對(duì)存儲(chǔ)于數(shù)據(jù)庫(kù)內(nèi)的電子合同的各項(xiàng)內(nèi)容進(jìn)行查看。步驟603:執(zhí)行査詢過(guò)程，按照查詢類型及參數(shù)對(duì)電子合同管理系統(tǒng)所涉及的內(nèi)容進(jìn)行査看。步驟604:生成查詢結(jié)果并返回。以上所述，僅為本發(fā)明的較佳實(shí)施例而已，并非用于限定本發(fā)明的保護(hù)范圍。權(quán)利要求1、一種電子合同管理系統(tǒng)，包括外部通信接口、數(shù)據(jù)接口以及數(shù)據(jù)庫(kù)，其特征在于，該系統(tǒng)還包括合同生成模塊、合同分發(fā)模塊、交易信息收發(fā)模塊、合同查詢模塊；其中，外部通信接口，用于接受來(lái)自外部的訪問(wèn)請(qǐng)求以及向請(qǐng)求者返回電子合同管理系統(tǒng)的反饋信息；數(shù)據(jù)接口，用于連接和訪問(wèn)電子合同管理系統(tǒng)內(nèi)部數(shù)據(jù)庫(kù)的資源；數(shù)據(jù)庫(kù)，用于存放電子合同內(nèi)容、電子合同交易信息以及合同交易雙方的其他相關(guān)信息；合同生成模塊，用于接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息，并生成電子合同；合同分發(fā)模塊，用于將所生成的電子合同發(fā)送給電子合同簽約的買賣雙方；交易信息收發(fā)模塊，用于接收并記錄提供方與接受方之間的交易信息，并將交易成功的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心；合同查詢模塊，用于接收查詢請(qǐng)求，并根據(jù)查詢請(qǐng)求返回電子合同中的相關(guān)信息。2、一種電子合同管理系統(tǒng)的實(shí)現(xiàn)方法，其特征在于，該方法包括a、電子合同管理系統(tǒng)通過(guò)接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息，生成電子合同；b、將所生成的電子合同內(nèi)容信息加密后傳遞給所述接受方及提供方；c、交互控制所述接受方或提供方與所述合同管理系統(tǒng)間進(jìn)行加密的電子合同交易信息的傳遞；d、當(dāng)收到所述接受方和提供方的交易上報(bào)信息后，進(jìn)行解密，并進(jìn)行MD5驗(yàn)證，并根據(jù)驗(yàn)證結(jié)果，修改電子合同的當(dāng)前狀態(tài)。3、根據(jù)權(quán)利要求2所述的方法，其特征在于，該方法進(jìn)一步包括一種電子合同的查詢方法所述電子合同管理系統(tǒng)接收到查詢請(qǐng)求，依據(jù)查詢類型對(duì)存儲(chǔ)于數(shù)據(jù)庫(kù)內(nèi)的電子合同的各項(xiàng)內(nèi)容進(jìn)行查閱，并生成查詢結(jié)果。4、根據(jù)權(quán)利要求2所述的方法，其特征在于，該方法所述步驟d之后進(jìn)一步包括e、將所述電子合同管理系統(tǒng)成功交易的電子合同中的計(jì)費(fèi)相關(guān)信息發(fā)送到計(jì)費(fèi)中心，或?qū)⒔灰缀蟮碾娮雍贤畔l(fā)送給網(wǎng)絡(luò)交易的監(jiān)管方。5、根據(jù)權(quán)利要求2所述的方法，其特征在于，步驟a所述接收來(lái)自提供方與接受方之間達(dá)成的買賣合同信息為提供方注冊(cè)到互聯(lián)網(wǎng)上的服務(wù)器頁(yè)面前端所提供的商品信息。6、根據(jù)權(quán)利要求2所述的方法，其特征在于，步驟a所述電子合同的信息為XML格式的文件，所述信息內(nèi)容至少包括合同號(hào)、提供方身份標(biāo)識(shí)ID、商品ID、提供方網(wǎng)關(guān)綁定信息、接受方身份標(biāo)識(shí)ID。7、根據(jù)權(quán)利要求2所述的方法，其特征在于，步驟b所述將生成的電子合同內(nèi)容信息加密后傳遞給所述接受方及提供方為bl、合同分發(fā)模塊周期性地檢查已生成電子合同內(nèi)容信息(實(shí)際為合同狀b2、將所述新產(chǎn)生的電子合同及未發(fā)送成功的電子合同加密后，發(fā)送給合同履行的接受方、提供方作為交易依據(jù)。8、根據(jù)權(quán)利要求2所述的方法，其特征在于，步驟c所述交互控制所述接受方或提供方與所述合同管理系統(tǒng)間進(jìn)行加密的電子合同交易信息的傳遞，該過(guò)程為cl、所述接受方或提供方將交易上報(bào)信息發(fā)送給電子合同管理系統(tǒng)；c2、電子合同管理系統(tǒng)對(duì)其進(jìn)行解密，并判斷所述交易上報(bào)信息有無(wú)錯(cuò)誤，若有錯(cuò)誤，則丟棄該交易上報(bào)信息數(shù)據(jù)，并提示出錯(cuò)信息；否則，通過(guò)交易信息收發(fā)模塊向提供方或接受方發(fā)送Response消息；c3、電子合同管理系統(tǒng)偵聽所述接受方或提供方返回的ACK消息，若偵聽到ACK消息，則更改所述電子合同的狀態(tài)，否則結(jié)束本次交易過(guò)程。9、根據(jù)權(quán)利要求7或8所述的方法，其特征在于，所述加密電子合同內(nèi)容信息或電子合同交易信息的過(guò)程為將所要發(fā)送的電子合同內(nèi)容信息或電子合同交易信息先計(jì)算出MD5摘要，附加到所述電子合同內(nèi)容信息或電子合同交易信息中，生成對(duì)稱密鑰并用對(duì)稱密鑰對(duì)附加了MD5的數(shù)據(jù)內(nèi)容進(jìn)行對(duì)稱加密，然后用所述電子合同管理系統(tǒng)的私鑰對(duì)對(duì)稱密鑰進(jìn)行第一次RSA加密，再用對(duì)方公鑰進(jìn)行第二次RSA加密，最后將加密后的信息和對(duì)稱加密后的信息進(jìn)行組合。10、根據(jù)權(quán)利要求2或8所述的方法，其特征在于，所述電子合同管理系統(tǒng)在收到接受方或提供方上報(bào)的交易信息后，解密并進(jìn)行MD5驗(yàn)證，并修改電子合同的當(dāng)前狀態(tài)的過(guò)程為當(dāng)接受方或提供方接收到加密后的電子合同信息后，提供方首先計(jì)算出數(shù)字媒體資源的MD5摘要，發(fā)送給電子合同管理系統(tǒng)；接受方在收到數(shù)字媒體資源后，計(jì)算出媒體資源的MD5摘要，并發(fā)送給電子合同管理系統(tǒng)；當(dāng)電子合同管理系統(tǒng)收到交易雙方上報(bào)的交易成功的信息后，對(duì)交易雙方傳來(lái)的MD5摘要進(jìn)行比較，若兩者內(nèi)容相同，通過(guò)交易信息收發(fā)模塊向接受方發(fā)送該媒體資源的解密密鑰，接受方接收到密鑰后使用密鑰解密所收到的數(shù)字媒體資源，并向電子合同管理系統(tǒng)發(fā)送ACK消息，電子合同管理系統(tǒng)收到ACK消息后，修改所述電子合同的狀態(tài)。全文摘要本發(fā)明公開了一種電子合同管理系統(tǒng)，屬于互聯(lián)網(wǎng)通信技術(shù)應(yīng)用領(lǐng)域。所述系統(tǒng)包括外部通信接口、數(shù)據(jù)接口、數(shù)據(jù)庫(kù)、合同生成模塊、合同分發(fā)模塊、交易信息收發(fā)模塊、合同查詢模塊。本發(fā)明同時(shí)還公開了一種電子合同管理系統(tǒng)的實(shí)現(xiàn)方法，合同生成模塊通過(guò)接收接受方或提供方的合同意向信息生成電子合同，然后由合同分發(fā)模塊將所述電子合同加密分發(fā)給合同簽訂的雙方，并解密所述接受方及提供方返回的合同收到確認(rèn)信息后，再通過(guò)交易信息收發(fā)模塊對(duì)交易雙方上報(bào)的交易信息進(jìn)行分析，并根據(jù)分析結(jié)果對(duì)電子合同的狀態(tài)進(jìn)行修改。使用本發(fā)明提供的電子合同管理系統(tǒng)及其實(shí)現(xiàn)方法，可以提高網(wǎng)上電子商務(wù)交易的安全性、可靠性。文檔編號(hào)H04L1/16GK101593332SQ20081011324公開日2009年12月2日申請(qǐng)日期2008年5月28日優(yōu)先權(quán)日2008年5月28日發(fā)明者孟祥武,宮云戰(zhàn),張玉潔,陳俊亮,黃永生申請(qǐng)人:北京郵電大學(xué)