專利名稱：電子文件發(fā)送方法
技術領域：
本發(fā)明一般地涉 及電子文件的發(fā)送方法，特別涉及被加密后的電子文件的發(fā)送 方法。
背景技術：
為了通過互聯(lián)網等的通信網絡發(fā)送電子文件，通常，采用在電子郵件中粘貼附 件的電子文件發(fā)送的手法。如果采用了這個手法，構成電子郵件的全部數(shù)據(jù)，將殘留在 轉發(fā)電子郵件的服務器等中，容易被第三者盜看。作為防御這種問題的手法，眾所周知，是對添加到電子郵件的電子文件加密的 手法(專利文獻1)。如果采用加密手法，則第三者盜看被加密的電子文件內容將變得困難。[專利文獻1]日本專利公開2007-306261號公報

發(fā)明內容
在采用了加密電子文件的手法的情況下，電子郵件的發(fā)送者需要對電子郵件的 接收者傳達對加密的電子文件解碼所必需的口令。在專利文獻1所公開的手法中，一方 面由個人電腦發(fā)送添加了被加密的電子文件的郵件，同時，通過手機發(fā)送被加密的電子 文件的解碼必需的口令。由于口令被手機網絡原狀發(fā)送，存在被第三者獲取的可能性。 因此，專利文獻1公開的手法不能安全地對接收者傳達口令。其次，如果經過特別長期地連續(xù)性地采用上述手法，則發(fā)送者及接收者雙方必 須進行口令管理。并且，口令通常是由人決定的，所以，有設定成容易被破解的口令(比如，短 的文字/數(shù)字列和有意義的字符串等)的傾向。在必須對口令進行如上所述的發(fā)送者及 接收者的兩者的管理的狀態(tài)下，這種傾向變得尤其顯著。因此，鑒于以上的問題點，本發(fā)明的目的在于提供能夠安全且簡單地對接收者 發(fā)送電子文件的電子文件發(fā)送方法。本發(fā)明涉及的電子文件發(fā)送方法的特征在于包括發(fā)送裝置發(fā)送包含被加密的 電子文件的電子郵件的步驟；上述發(fā)送裝置，將上述被加密的電子文件的解碼所必需的 口令加密，并對服務器發(fā)送加密后的口令的發(fā)送的步驟；接收裝置接收被上述發(fā)送裝置 發(fā)送的上述電子郵件的步驟；上述服務器從上述發(fā)送裝置接收上述加密的口令并通過解 碼獲得到上述解碼所必需的口令的步驟；以及上述服務器將上述解碼所必需的口令進行 加密，對上述接收裝置發(fā)送被加密后的口令的步驟。進一步，本發(fā)明涉及的電子文件發(fā)送方法的特征在于包括接收裝置接收由發(fā) 送裝置發(fā)送的、且包含被加密的電子文件的電子郵件的步驟；上述接收裝置從服務器接 收上述加密的電子文件的解碼所必需的口令的步驟；上述接收裝置從上述服務器接收表 示對上述電子文件許可或禁止的可否信息的步驟；上述接收裝置使用上述口令，通過解碼上述被加密的電子文件，生成電子文件的步驟；上述接收裝置根據(jù)上述可否信息執(zhí)行 對所生成的上述電子文件的處理。


圖1是表示本發(fā)明的第一實施方式所涉及的通信系統(tǒng)的一個結構例的方塊圖；圖2是表示發(fā)送裝置110的內部結構的一個例子的方塊圖；圖3是表示管理服務器130的內部結構的一個例子的方塊圖；圖4是表示接收裝置120的內部結成的一個例子的方塊圖；圖5是表示在本發(fā)明的第一實施方式涉及的電子文件發(fā)送方法中，在發(fā)送裝置 和管理服務器及郵件服務器之間進行的動作的模式圖；圖6是表示在本發(fā)明的第一實施方式所涉及的電子文件發(fā)送方法中，在接收裝 置和管理服務器及郵件服務器之間進行的動作的模式圖；圖7是表示本發(fā)明的第一實施方式所涉及的電子文件發(fā)送方法中，在接收裝置 和管理服務器及郵件服務器之間進行的動作的模式圖；圖8是表示在本發(fā)明的第二實施方式所涉及的電子文件發(fā)送方法中的動作的模 式圖；圖9是表示由一般的應用軟件進行的文件讀入處理的模式圖；圖10是為了說明動態(tài)鏈路的概念的模式圖；圖11是用于說明API鉤子的概念的模式圖；圖12是著眼于API鉤子表示在本發(fā)明的第二實施方式所涉及的電子文件發(fā)送方 法的步驟D8 DlO中進行的動作的流程圖；圖13是表示為了在本發(fā)明的第二實施方式所涉及的電子文件發(fā)送方法中限制接 收者對電子文件的剪貼板操作的動作的流程圖。附圖標記說明100 通信系統(tǒng)；110 發(fā)送裝置；120 接收裝置；130 管理服務器；140 郵件服務器；150:通信網；220，310，410 控制/處理部；230，330，420 存儲 部；240，320，430 通信部；250，440 顯示部；330a 數(shù)據(jù)庫；806 查看器(專用 的應用軟件)；807:特定的應用軟件；809:固有的鉤模塊(鉤模塊)。
具體實施例方式以下，參照附圖詳細說明本發(fā)明。同時，對于附圖中的共通的結構要素附加同 樣的參照符號。(第一實施方式)圖1是表示與本發(fā)明的第一實施方式有關的通信系統(tǒng)的結構的一個例子的方塊 圖。如圖1所示，通信系統(tǒng)100，主要包含發(fā)送裝置110、接收裝置120、管理服務器 130、以及郵件服務器140。這些裝置及服務器，能夠由包括互聯(lián)網等的通信網150連 接。另外，該通信網150，可包含固定網絡及移動通信網。發(fā)送裝置110，比如，相當于個人電腦、手機和個人數(shù)字助理等。發(fā)送裝置110 通過通信網150對接收裝置120發(fā)送添加了被加密后的電子文件的電子郵件。
接收裝置120也相當于個人電腦、手機或個人數(shù)字助理等。接收裝置120，通過 通信網150接收由發(fā)送裝置110發(fā)送的電子郵件。郵件服務器140，通過通信網150接收發(fā)送裝置110發(fā)送的電子郵件，通過通信 網150將這個電子郵件發(fā)送到接收裝置120。管理服務器130，通過通信網150，將對被發(fā)送裝置100加密的電子文件解碼所 必需的口令，從發(fā)送裝置Iio發(fā)送至接收裝置120。<各裝置及管理服務器的內部結構>[發(fā)送裝置110的內部結構]
圖2是表示發(fā)送裝置110的內部結構的一個例子的方塊圖。發(fā)送裝置110，主要 包含控制/處理部220、存儲部230、通信部240和顯示部250。存儲部230存儲包括為了實現(xiàn)本實施方式涉及的電子文件發(fā)送方法所使用的應 用程序、管理服務器130 (或接收裝置120)的公鑰、應該發(fā)送給接收裝置120的電子文件 等的各種各樣的信息。通信部240，接收控制/處理部220的控制，執(zhí)行對接收裝置120的電子郵件的 發(fā)送，對管理服務器130的口令的發(fā)送等。顯示部250，接收該控制/處理部220的控制，對發(fā)送裝置110用戶(發(fā)送者) 顯示由控制/處理部220進行的處理的結果。控制/處理部220控制存儲部230、通信部240及顯示部250，進行本實施方式 涉及的電子文件發(fā)送方法的執(zhí)行所必需的動作。具體地說，控制/處理部220，通過執(zhí)行被存儲部230存儲的應用程序，控制存 儲部230、通信部240及顯示部250，進行本實施方式涉及的電子文件發(fā)送方法的執(zhí)行所 必需的動作(比如，電子文件的加密、添加了被加密后的電子文件的電子郵件的發(fā)送、 解碼被加密后的電子文件所必需的口令的發(fā)送等動作)。[管理服務器130的內部結構]圖3，是表示管理服務器130內部結構的一個例子的方塊圖。管理服務器130， 主要包含控制/處理部310、通信部320和存儲部330。存儲部330存儲包括為了實現(xiàn)本實施方式的電子文件發(fā)送方法所使用的應用程 序、從發(fā)送裝置110接收的口令、能夠一對一地識別從發(fā)送裝置110向接收裝置發(fā)送的電 子文件的識別符等的各種各樣的信息。通信部320，接受控制/處理部310的控制，執(zhí)行與發(fā)送裝置110的通信(接收 來自發(fā)送裝置110的口令等)及與接收裝置120的通信(對接收裝置120的電子郵件的發(fā) 送\、來自接收裝置120的公鑰的接收、及針對接收裝置120的口令的發(fā)送等)?？刂?處理部310，控制通信部320及存儲部330，進行在執(zhí)行本實施方式的電 子文件發(fā)送方法時所必要的動作。具體地說，控制/處理部310，通過執(zhí)行被存儲部330 存儲的應用程序，控制存儲部330及通信部320，進行在本實施方式涉及的電子文件發(fā)送 方法的執(zhí)行中所必需的動作(比如，來自發(fā)送裝置110的口令等的接收，對接收裝置120 的口令的發(fā)送等)。[接收裝置120的內部結構]圖4是表示接收裝置120內部結構的一個例子的方塊圖。
接收裝置120，主要包含控制/處理部410、存儲部420、通信部430和顯示部 440。存儲部420，存儲包含為實現(xiàn)本實施方式的電子文件發(fā)送方法所使用的應用程 序、接收裝置120密鑰等的各種各樣的信息。通信部430，受到控制/處理部410的控制，執(zhí)行來自發(fā)送裝置110的電子郵件 的接收、來自管理服務器130的電子郵件的接收、來自管理服務器130的口令的接收等。顯示部440，受到控制/處理部410的控制，對接收裝置120的用戶(接收者) 顯示由該控制/處理部410完成的處理結果。控制/處理部410控制存儲部420、通信部430及顯示部440，進行在執(zhí)行本實施 方式的電子文件發(fā)送方法時所必需的處理。具體地說，控制/處理部410通過執(zhí)行被存 儲部420存儲的應用程序，來控制存儲部420、通信部430及顯示部440，進行在執(zhí)行本 實施方式的電子文件發(fā)送方法時必要的動作(比如，接收來自發(fā)送裝置110的電子郵件， 對管理服務器130發(fā)送公鑰，接收來自管理服務器130的口令等)。<電子文件發(fā)送方法的流程>其次，說明本實施方式涉及的通信系統(tǒng)進行的電子文件發(fā)送方法的整體性的動作。[在發(fā)送裝置110和管理服務器130及郵件服務器140之間的動作]圖5是表示在本發(fā)明的第一實施方式的電子文件發(fā)送方法中，在發(fā)送裝置110和 管理服務器130及郵件服務器140之間進行的動作的模式圖。在步驟Al中，發(fā)送裝置110被預先安裝了專用應用軟件。在步驟A2中，作為發(fā)送裝置110用戶的發(fā)送者X，利用Office(注冊商標)等的 應用軟件，制作應該發(fā)送給作為接收裝置120用戶的接收者Y的電子文件。作為所制作 的電子文件的一個例子，圖5給出了 Word(注冊商標)文件501。在步驟A3中，在專用應用軟件上，發(fā)送者X指定電子文件501，作為想安全發(fā) 送的電子文件。具體地說，在發(fā)送裝置Iio的顯示部250，由專用應用軟件顯示窗502。 在該狀態(tài)中，發(fā)送者X，通過將電子文件501托曳到窗502里面的字段503中，指定電子 文件501為發(fā)送對象文件。在步驟A4中，發(fā)送者X，在專用應用軟件上指定被準許打開文件的接收者(在 這里是接收者Y)的電子郵件地址。具體地說，發(fā)送者X，在"公開處"字段504輸入接 收者Y的電子郵件地址。然后，發(fā)送者X，在專用應用軟件上指定接收者Y對電子文件501的許可或禁止 的操作。具體地說，比如，發(fā)送者X，在準許對于電子文件501的全部操作的情況下， 在"閱覽限制"字段505不進行勾選。反過來，發(fā)送者X，如果對電子文件501付加某種 限制，則在"閱覽限制"字段 505進行勾選。該情況，在對電子文件501的閱覽次數(shù)付加限制時，發(fā)送者X在"閱覽 次數(shù)"字段506進行勾選的同時，對字段507輸入可能閱覽次數(shù)。如果禁止電子文件501 的印刷，則發(fā)送者X，在"印刷"字段508進行勾選。同樣，在禁止對電子文件501的 剪貼板操作時，發(fā)送者X在"剪貼板操作"字段509進行勾選。這樣，發(fā)送者X輸入的信息被作為"閱覽可否信息“而保存。這個閱覽可否信息，是為了由發(fā)送者X控制(許可及/或禁止)接收者Y對電子文件501執(zhí)行可能的處理(操作)所使用的。關于為了實現(xiàn)它的具體的手法，將在后述的第二實施方式中說明。在步驟A5中，發(fā)送者X，將對電子文件501解碼所必需的口令(以下稱〃解碼 用口令")輸入"確認口令"字段510。或者，專用應用軟件，不讓發(fā)送者X輸入解碼 用口令，也能把隨機生成的口令作為解碼用口令。以此，能夠把所使用的口令的密碼方 式的最大長度的通用鑰作為解碼用口令。在步驟A6中，專用應用軟件使用在步驟A5中輸入或生成的解碼用口令，加 密作為發(fā)送對象文件而被指定的電子文件501。并且，專用應用軟件也能壓縮電子文件 501。并且，專用應用軟件生成能夠一對一識別這樣被加密(及被壓縮)后的電子文件 511的文件識別符。進一步，專用應用軟件用管理服務器130公鑰加密解碼用口令。再者，也可以用接收裝置120公鑰替換管理服務器130公鑰。之后，專用應用軟件對管理服務器130發(fā)送接收者Y的電子郵件地址、閱覽可否 信息、文件識別符、及被加密的解碼用口令。在步驟A6中由發(fā)送裝置110對管理服務器130發(fā)送的信息，通過通信網150被 管理服務器130接收。并且，被加密的解碼用口令，用管理服務器130密鑰(與發(fā)送裝 置110用的公鑰相對應的密鑰)解碼，這樣，得到解碼用口令。之后，在步驟A7中，讓接收者Y的電子郵件地址、文件識別符、閱覽可否信息 及解碼用口令互相對應存儲在作為存儲部330的一部分的數(shù)據(jù)庫330a中。具體地說，將 文件識別符作為鑰匙，并與其對應地，在數(shù)據(jù)庫330a存儲接收者Y的電子郵件地址(公 開處地址)、閱覽可否信息及解碼用口令。另一方面，再次參照發(fā)送裝置110的話，在步驟A8中，專用應用軟件發(fā)送添加 了被加密的電子文件511的電子郵件512。這個電子郵件512，通過郵件服務器140發(fā)送 給接收裝置120。[接收裝置120和管理服務器130及郵件服務器140之間的動作(用戶登錄前)]管理服務器130，在上述步驟A6中接收來自發(fā)送裝置110的接收者Y的電子郵 件地址的時刻，確認接收者Y是否被管理服務器130作了用戶登記。在這里，設接收者 Y為沒有進行用戶登記。圖6是表示在本發(fā)明的第一實施方式涉及的電子文件發(fā)送方法中，接收裝置120 和管理服務器130及郵件服務器140之間的動作的模式圖。在步驟Bl中，管理服務器130，由隨機的信息構成的權標(數(shù)據(jù)列，Data Sequence)生成比如由郵件正文記載的電子郵件601。并且，該電子郵件601的比如郵件 正文中記載了提供專用應用軟件(查看器)的安裝程序的網站的URL。本實施方式中， 作為一個例子將這個URL設定為是管理服務器130的URL。管理服務器130，將該電子 郵件601發(fā)送給接收裝置120。在步驟B2中，接收裝置120通過郵件服務器140接收被發(fā)送裝置110(在步驟 A8中)發(fā)送的電子郵件512。在這個時刻中，因為接收裝置120沒有解碼用口令，所以 不能打開接收到的電子郵件512中添加的被加密的電子文件511。在步驟B3中，接收裝置120接收由管理服務器130 (在步驟Bl中)發(fā)送的電子郵件601。在該電子郵件601的郵件正文中，記載了如上所述的權標及URL。在步驟B4中，通過接收者Y對郵件正文所記載的URL進行點擊操作，接收裝 置120根據(jù)這個URL訪問管理服務器130，從這個管理服務器130下載專用應用軟件(查 看器)的安裝程序602。之后，接收裝置120通過執(zhí)行已下載的安裝程序602，安裝專用 應用軟件(查看器)。在安裝時，如步驟B5所示，安裝程序602生成不對稱鑰的雙鑰，S卩，生成密鑰 603和與這個對應的公鑰604。將生成的密鑰603隱秘保存。并且，在安裝時，如步驟B6所示，安裝程序對接收者Y顯示對話框605 (顯示 部440)，要求輸入電子郵件601的郵件正文記載的權標。
如果專用應用軟件(查看器)的安裝結束的話，在步驟B7中，所啟動的專用應 用軟件，將在步驟B5中生成的公鑰604發(fā)送給管理服務器130，并用在步驟B5中生成的 密鑰603加密在步驟B6中輸入的權標后發(fā)送給管理服務器130。不過，專用應用軟件也 可以不對在步驟B6中被輸入的權標加密而發(fā)送給管理服務器130。在步驟B8中，管理服務器130接收由接收裝置120發(fā)送的公鑰及被加密的權 標。管理服務器130，根據(jù)公鑰對從接收裝置120接收到的被加密的權標進行解碼。管理 服務器130，在通過解碼得到的權標與管理服務器130在步驟Bl中發(fā)送的權標相符時， 判斷為接收者Y是正當?shù)挠脩舻怯浫?，用戶登記接收者Y。具體地說，管理服務器130， 將接收者Y的電子郵件地址和公鑰對應保存在數(shù)據(jù)庫330a中。S卩，認為接收到的公鑰 為接收者Y的正當?shù)墓€，而與接收者Y的電子郵件地址對應起來被保存在數(shù)據(jù)庫330a 中。以此，接收者Y的用戶登記完成。再者，在上述步驟B5，雖然通過安裝程序生成密鑰及公鑰，不過，可以用被安 裝程序安裝后的專用應用軟件(查看器)生成。并且，在上述步驟B6，針對接收者Y的權標輸入，還可由安裝程序要求，不 過，也可以通過被安裝程序安裝的專用應用軟件，比如，在這個應用軟件的第一回啟動 時或在使用開始前要求。[接收裝置120和管理服務器130及郵件服務器140之間的動作(用戶登記完畢)]如上所述，管理服務器130，在上述步驟A6中，在從發(fā)送裝置110接收了接收 者Y的電子郵件地址的時刻，確認接收者Y是否已被管理服務器130做過用戶登記。在 這里，假設接收者Y為已經被用戶登記的用戶。圖7，是表示本發(fā)明的第一實施方式所涉及的電子文件發(fā)送方法中接收裝置120 和管理服務器130及郵件服務器140之間的動作的模式圖。因為接收者Y的用戶登記已經完成，所以如步驟Cl所示，接收裝置120保存密 鑰603，與密鑰603對應的公鑰604被管理服務器130保存到數(shù)據(jù)庫330a。在步驟C2中，在接收裝置120中啟動專用應用軟件(查看器)。接收者Y，進 行用查看器打開由郵件512接收的被加密的電子文件511的操作。在步驟C3中，查看器對管理服務器130發(fā)送用于識別接收者Y的電子郵件地址 (即接收者Y的電子郵件地址)，及從被加密的電子文件511提取的文件識別符。在步驟C4中，管理服務器130，把從接收裝置120接收了的文件識別符作為鑰 匙，取出與這個文件識別符對應(在上述步驟A7中)保存的公開處地址，在取出的公開處地址中，檢索是否存在從接收裝置120接收的接收者Y的電子郵件地址。S卩，對于通 過從接收裝置120接收的文件識別符一對一特別指定的電子文件，由管理服務器130判斷 接收者Y是否被發(fā)送者X指定為可對其公開該電子文件的正當?shù)慕邮照摺Ｔ谂袛喑鼋邮照遈是公開可能的接收者的情況下，在步驟C5中，管理服務器 130從數(shù)據(jù)庫330a抽出與其文件識別符對應(在上述步驟A7中)而保存的解碼用口令 701。并且，管理服務器130從數(shù)據(jù)庫330a抽出與接收者Y對應(在上述步驟B8中) 而保存的接收裝置120的公鑰604。并且，管理服務器130，還由公鑰604將解碼用口令 701加密，將被加密得到的口令702發(fā)送給接收裝置120。在步驟C6中，接收裝置120，接收被加密的口令702。在接收裝置120啟動的 查看器使用被這個接收裝置120保存的密鑰603解碼被加密的口令702，從而得到解碼用 □令 701。在步驟C7中，查看器通過用解碼用口令701將電子郵件512添加的被加密的電 子文件511解碼，得到電子文件501。
從以上的步驟C2 C7可以明確，接收者為了解碼被加密的電子文件，需要預 先使查看器啟動。并且，查看器為了進行對加密的電子文件的解碼，每回，必須為取得 解碼所必要的口令而訪問管理服務器。因而，在接收者解碼被加密的電子文件的時候， 為了取得口令訪問管理服務器130時，管理服務器130，還可采用與文件識別符對應地保 留接收者及時刻等的記錄的結構。因為接收者為了進行電子文件的解碼，必需訪問管理 服務器130，所以，根據(jù)這個結構，發(fā)送者通過參照管理服務器130留下的記錄，能夠追 蹤接收者什么時候打開了文件。如以上說明，根據(jù)本發(fā)明，因為電子文件實體被高度強化加密，因此，即使第 三者得到也不能打開。對被加密的電子文件的解碼所必需的口令，不是在網絡上原樣傳輸，而是被管 理服務器的公鑰或者被按照發(fā)送者的意圖設置的接收者的公鑰加密后傳送。這樣，即使 第三者知道這個口令，但是只要沒有密鑰，也不能解碼。假設，即使是在管理服務器不能被信賴的情況下，也能因為管理服務器只是管 理著對加密的電子文件的解碼所必需的口令，完全不管理電子文件主體，而能夠防止發(fā) 生第三者對被加密的電子文件的解碼。管理服務器，從其電子文件的發(fā)送者接收并管理識別電子文件的信息(比如文 件識別符)和識別與此對應的正當?shù)慕邮照叩男畔?比如接收者的電子郵件地址)。接收 者通過對管理服務器發(fā)送識別希望解碼的電子文件的信息(文件識別符)和識別自己本身 的信息(電子郵件地址)，對管理服務器要求被加密的口令。接受了要求的管理服務器， 比較從發(fā)送者及接收者的兩者接收的文件識別符及電子郵件地址，可以確實且自動地判 斷正當?shù)慕邮照呤欠裣胍獯a恰當?shù)慕邮瘴募?。因而，根?jù)發(fā)送者的意圖的恰當?shù)碾娮?文件，只能根據(jù)發(fā)送者的意圖被正當?shù)慕邮照叽_實取得。從發(fā)送裝置對接收裝置借助管理服務器的口令的傳達，因為由各裝置安裝的應 用程序來執(zhí)行，所以，發(fā)送者及接收者既不需要意識到口令，也不需要管理口令。因此，根據(jù)本發(fā)明，能夠安全且確實地對正當?shù)慕邮照邆魉碗娮游募?。另外，在本實施方式中，作為?yōu)選的實施方式，說明了在發(fā)送裝置110和管理服務器130之間，及管理服務器130與接收裝置120之間，對電子文件的解碼所需的口 令，通過由公鑰加密的與這個公鑰對應的密鑰進行解碼的情況，即，對電子文件的解碼 所需的口令使用了不對稱密碼方式進行加密及解碼。然而，本發(fā)明，也可以適用于對電 子文件的解碼所必需的口令進行使用了密鑰密碼方式的加密及解碼的情況。
當采用密鑰密碼方式時，具體地說，發(fā)送裝置110和管理服務器130的關系為， 在步驟A6中，發(fā)送裝置110用第一密鑰加密電子文件501，用第二密鑰加密第一密鑰， 向管理服務器130發(fā)送被第二密鑰加密的第一密鑰。管理服務器130通過第二密鑰將被 加密的第一密鑰解碼，而得到第一密鑰。在步驟A7中，這個第一密鑰作為解碼用口令被 管理服務器130保存。因而，發(fā)送裝置110及管理服務器130，需要預先保持第二密鑰。
另一方面，接收裝置120和管理服務器130的關系中，在步驟B7中，不是用公 鑰，而是用密鑰(在這里，為了敘述上的方便，稱之為"第三密鑰")及另外的密鑰(“ 第四密鑰")。即，接收裝置120向管理服務器130發(fā)送被第四密鑰加密的第三密鑰和被 第三密鑰或者第四密鑰加密的權標。在步驟B8中，管理服務器130通過用第四密鑰將被 加密后的第三密鑰進行解碼而得到第三密鑰，由第三密鑰或者第四密鑰將被加密后的權 標解碼而得到權標。并且，在步驟C5中，管理服務器130用第三密鑰加密解碼用口令并 發(fā)送至接收裝置120，在步驟C6中，接收裝置120用第三密鑰將被加密后的解碼用口令 解碼，得到解碼用口令。因而，接收裝置120及管理服務器130，需要預先保持第四密 鑰。
(第二實施方式)
本實施方式中，說明在第一實施方式中說明過的電子文件發(fā)送方法中的，由電 子文件的發(fā)送者控制(許可及/或禁止)對這個電子文件可由接收者執(zhí)行處理(操作)的 方法。
以下，需要注意的是，對本實施方式中與上述第一實施方式相同之處的詳細說 明被省略。
圖8是表示在本發(fā)明的第二實施方式的電子文件發(fā)送方法中進行的動作的模式 圖。另外，設接收者Y為已經被管理服務器130注冊的用戶。
在步驟Dl中，發(fā)送者X與上述步驟A3同樣，在專用應用軟件上指定Word(注 冊商標)文件501為發(fā)送對象文件。在步驟D2中，發(fā)送者X，與上述步驟A4同樣，指 定被準許打開文件的接收者(在這里為接收者Y)的電子郵件地址。進一步，和上述步驟 A4同樣，發(fā)送者X對接收者Y指定對電子文件501許可或禁止的操作。
在步驟D3中，專用應用軟件，和上述步驟A6同樣，使用在上述步驟A5中輸 入或者生成的解碼用口令，將被指定為發(fā)送對象文件的電子文件501進行加密(進一步壓 縮)。之后，和上述步驟A6同樣，專用應用軟件，對管理服務器130發(fā)送接收者Y的 電子郵件地址、閱覽可否信息、文件識別符、及被加密的解碼用口令。在管理服務器130 中對這些的信息所做的處理，與上述步驟A6及以A7中已經說明過的一樣。
在該步驟D3中，專用應用軟件，能夠將被加密的電子文件801文件名設定成與 電子文件501的文件名相同。S卩，把被加密的電子文件801文件名設定成與電子文件501 文件名(Important.doc)同名。
在該被加密的電子文件801的頁眉(header)部分802中，記載了文件識別符80沈。并且，在這個頁眉部分802中，附加了表示這個電子文件801為固有形式的頁眉 80&。同時，也能將上位數(shù)據(jù)(metadata) 80 附加到頁眉部分802。上位數(shù)據(jù)80 ，比 如，能夠包含表示電子文件501的著作權和編輯履歷的信息等。該上位數(shù)據(jù)80 ，可以 和原來的文件的內容803同樣被加密。
在步驟D4中，和上述步驟A8同樣，專用應用軟件發(fā)送添加了被加密的電子文 件801的電子郵件804。這個電子郵件804，通過郵件服務器104，被接收裝置120接收。
在步驟D5中，和上述步驟C2同樣，在接收裝置120中啟動有專用應用軟件(查 看器)。接收者Y，進行對由郵件804接收的被加密的電子文件801用查看器打開的操作。
在步驟D6中，雖然被加密的電子文件801文件名與電子文件501文件名相同， 不過，因為這個被加密的電子文件801是固有形式的文件，不能原樣打開。然而，在本 發(fā)明中，無需讓用戶意識到這個事實，而是像下面一樣，由操作系統(tǒng)(OS)805執(zhí)行電子 文件801的打開操作。
在步驟D7中，查看器806的結構為監(jiān)視著OS805啟動應用軟件的動作，如果 識別到由OS805通過打開被加密的電子文件801而啟動了預想的特定應用軟件(這里是 Word(注冊商標))807的話，則將由被特定的應用軟件807調用的API模塊808進行的處 理，轉換成為通過API鉤子由固有的鉤子模塊809的處理。這樣，OS805如果按照電子 文件801擴展名(.doc)啟動Word(注冊商標)的話，查看器806則識別作為特定的應用 軟件807的Word(注冊商標)已被OS805啟動，由API鉤子調用固有的鉤子模塊809。
為了在步驟D8中，所啟動的特定的應用軟件807為了訪問文件的內容，調用 (呼出)由OS805準備的API模塊?？墒牵诓襟ED9，由于被調用的API模塊的處理實 際上不被執(zhí)行，而執(zhí)行被API鉤子調用的由固有的鉤子模塊809進行的處理。固有的鉤 子模塊809，關于對被加密的電子文件801的訪問，確認是否在該電子文件801頁眉部分 802(在上述步驟D3中被附加的)上附加有頁眉80&。
固有的鉤子模塊809，在對頁眉部分802沒有附加有頁眉80 的情況下，判斷該 電子文件801不是固有形式的(即判斷是通常的Word(注冊商標)文件)，由OS805執(zhí)行 通常的處理(即，在步驟D9被調用的API模塊的處理)。
另一方面，固有的鉤子模塊809，在頁眉部分802附加有頁眉80 的情況下，判 斷這個電子文件801是固有形式的，執(zhí)行下面的步驟DlO以后的處理。
在步驟DlO中，和上述步驟C3同樣，查看器806(固有的鉤子模塊809)對管理 服務器130發(fā)送接收者Y的電子郵件地址及文件識別符。
該結果，通過由管理服務器130執(zhí)行上述步驟C4及以C5說明過的處理，接收 裝置120從管理服務器130接收被加密的口令702。這樣，查看器806(固有的鉤子模塊 809)，得到與上述步驟C6同樣的解碼用口令701，和上述步驟C7同樣，使用解碼用口令 701,將被加密的電子文件801解碼，而得到電子文件501。
再者，當接收者Y沒被管理服務器130做用戶登記時，參照圖6執(zhí)行上述的步驟 Bl B8。
在這里，特別著眼于API鉤子而進一步具體地說明在上述步驟D8 DlO中的動作。
[API鉤子的概念]
首先，就API鉤子的概念加以說明。
(1)所謂的API (Application Programbiterface)是指在OS內，開發(fā)應用軟件的時候能夠使用的OS的功能的集合。應用軟件組合OS準備的API模塊，并使OS執(zhí)行該應 用軟件具有的功能。
比如，以在Windows(注冊商標)上讀取文件的應用軟件(比如Word(注冊商 標))為例，這個應用軟件，通常，進行圖9所示的處理。圖9是表示一般的應用軟件進 行的文件的讀入處理的模式圖。
在步驟910中，應用軟件901指定文件名，并調用CreateFile API，打開文件。 在步驟920中，應用軟件901，指定打開了的文件的識別符(HANDLE)并調用ReadFile API而取得內容。在步驟930中，應用軟件901，用CloseHandleAPI釋放讀完的文件。
這樣，OS902管理設備和資源，在利用OS的功能的時候，應用軟件901必定進 行某種API的調用。S卩，應用軟件901，通過被公開的API委托OS902進行處理，通過 這樣的方法，對設備和資源進行訪問。
( 應用程序使用的API，作為一覽記述在其程序的執(zhí)行文件。在其程序的啟動 的時候，OS在存儲器上配置其程序必需的API的實體，將其API的存儲器上的地址(門 牌)，與程序上被記述的API的調用建立連接。這樣，如圖10所示，程序有"調用叫做 CreateFile這個名稱的API"的記述的情況下，CreateFile的實體被配置在存儲器上之后， 執(zhí)行像〃調用OxefffOOaO上的函數(shù)〃的實際的處理那樣地，改寫存儲器。
(3)在這里，如圖11所示，能夠使固有的程序片(模塊)插入程序的執(zhí)行存 儲器空間，通過改寫API的名稱和實際地址的相關聯(lián)的信息，執(zhí)行與本來應該被調用的 CreateFileAPI的實體不同的處理，把這個稱作為〃 API鉤子〃。以此，在應用軟件打算 作為OS的功能調用CreateFile API的時候，能夠執(zhí)行從外部插入的鉤子模塊的固有的處 理。鉤子模塊，因為認識本來的CreateFile API存在于存儲器上的哪里，所以，如果必 要，能夠對本來的CreateFile API轉送處理。
以上，說明了關于API鉤子的概念。
[在步驟D8 DlO的動作的詳細]
圖12是著眼于API鉤子表示在步驟D8 DlO中進行的動作的流程圖。與圖 12—起參照圖8，在步驟D8中，假設特定的應用軟件807為了訪問文件的內容指定文件 名，而打算調用CreateFile API。可是，實際上，在步驟D9中，執(zhí)行由API鉤子調用的固 有的鉤子模塊809的處理。具體地說，固有的鉤子模塊809，在步驟D9-1中，指定文件 名，調用CreateFile API，打開電子文件801。在步驟D9-2中，固有的鉤子模塊809，指 定所打開的文件801的識別符，調用ReadFile API，取得其內容。固有的鉤子模塊809， 在通過讀取電子文件801頁眉部分802，識別出該電子文件是固有形式的文件的情況下， 在步驟DlO中，對管理服務器130發(fā)送接收者Y的電子郵件地址及文件識別符。這樣， 固有的鉤子模塊809，從管理服務器130取得被加密的口令702。
之后，固有的鉤子模塊809，在存儲器中，將被加密的電子文件801解碼，得到 電子文件501內容。得到的電子文件501內容，在存儲器(暫存區(qū)域)上被展開及保持， 如步驟D10-1所示，在存儲器中，被返回至特定的應用軟件807。14
以上，對步驟D8 DlO進行了說明。
其次，在步驟Dll中，固有的鉤子模塊809，也從管理服務器130接收與文件識 別符對應(在上述步驟A7中)存儲的閱覽可否信息。該閱覽可否信息相當于在上述步驟 D2(即步驟A4)中由發(fā)送者X輸入的信息。
固有的鉤子模塊809，基于接收到的閱覽可否信息，能夠按照發(fā)送者X的意圖， 許可及/或限制由接收者Y對電子文件501的處理(比如編輯、印刷、剪貼板操作等)。 圖13表示其具體的實現(xiàn)手法。圖13是表示在本發(fā)明的第二實施方式涉及的文件發(fā)送方 法中，限制由接收者對電子文件的剪貼板操作的動作的流程圖。
如上所述，因為啟動了特定的應用軟件807，所以根據(jù)這個應用軟件被調用的 API模塊進行的處理，被API鉤子轉換成由固有的鉤子模塊809進行的處理。
在這種狀態(tài)中，接收者Y為了進行剪貼板操作，在步驟El中，如果進 行按壓〃 Ctri"鍵及〃 C"鍵的操作的話，則應用軟件807，在步驟E2中，調用 ktClipBoardDataAPI?？墒?，實際上，因為在步驟E3中，固有的鉤子模塊809返回〃失 敗"，所以，應用軟件807，在步驟E4中對接收者Y表示錯誤信息等。
因此，由接收者Y對電子文件501的剪貼板操作受到限制。
同樣，在印刷電子文件501的時候，因為，當將名為GetDC的API、電子文件 501 用別名保存時，CreateFile]、WriteFile> CloseHandle —系列的 API，被應用軟件 807 調用，所以即使對這些API的調用也能夠根據(jù)API鉤子，由固有的鉤子模塊809執(zhí)行固有 的處理，得以限制對電子文件501的印刷或別名保存。
再者，在準許由接收者Y對電子文件501的特定操作的情況下，固有的鉤子模塊 809，只需在與特定的操作對應的API模塊被應用軟件807調用的時候，將該調用轉送至 API模塊即可。在這種情況下，該API模塊的執(zhí)行結果，在存儲器中，被固有的鉤子模 塊809返回給應用軟件807。
再次參照圖8的話，固有的鉤子模塊809通過監(jiān)視由特定的應用軟件807的各 API調用，比如能夠監(jiān)測出接收者Y進行特定的操作(調用特定的API)并將該事實對管 理服務器130發(fā)送。具體地說，固有的鉤子模塊809，如步驟D12所示，能夠向管理服 務器130發(fā)送電子文件的識別符及表示特定的操作的操作內容信息(與進行其操作的時間 一起)。管理服務器130，與電子文件的識別符對應地把操作內容信息(操作記錄)保 存到數(shù)據(jù)庫330a。并且，發(fā)送者X通過發(fā)送裝置110對管理服務器130訪問，能夠如步 驟D13所示，查看接收者Y對于自己發(fā)送的電子文件進行了怎樣的操作。以此，發(fā)送者 X，能夠追蹤接收者Y對發(fā)送的電子文件在幾點鐘進行了怎樣的操作。
并且，發(fā)送者X，還能如步驟D14所示，利用發(fā)送裝置110，對管理服務器130 訪問，隨時變更與識別符對應保存在管理服務器130中的閱覽可否信息。
上述的第一實施方式中，雖然只有根據(jù)發(fā)送者的意圖的正當?shù)慕邮照卟趴梢越?收恰當?shù)碾娮游募⒋蜷_，不過，仍然殘存一種可能性，即這個正當?shù)慕邮照邔⑷〉玫?電子文件傳送給違背發(fā)送者的意圖的第三者。
本實施方式，在接收裝置中，不是將通過解碼而獲得的電子文件作為文件而輸 出，而是通過在讀取被加密的電子文件的時候，鉤鏈API，由固有的鉤子模塊，在存儲器 (暫存區(qū)域)上進行這個電子文件的解碼，所以通過解碼得到的電子文件的內容，不作為可從外部讀取形式的文件而保留，即，在存儲器上展開的電子文件的內容，不在硬盤等 的固定存儲區(qū)域中展開。
并且，關于所謂的能成為使電子文件的內容外部流出的主要原因的操作，比如 文件的寫出、印刷、剪貼板操作等，能夠在存儲器上鉤鏈為了實現(xiàn)這些操作的API，得以 控制對這些操作的許可及/或限制(禁止)。這樣，能夠防止電子文件的內容向外部流出ο
并且，在接收裝置中，根據(jù)API鉤子，由固有的鉤子模塊監(jiān)視特定的應用軟件 的各API的調用，并通知管理服務器，管理服務器能夠記錄下由哪個接收者在幾點鐘做 哪些操作。根據(jù)這個，訪問了管理服務器的發(fā)送者，能容易且切實地跟蹤由接收者對電 子文件的操作內容(比如，文件打開，閱覽，印刷以及剪貼板操作等任意的操作內容)。
權利要求
1.一種電子文件發(fā)送方法，其特征在于，包括發(fā)送裝置發(fā)送包含被加密后的電子文件的電子郵件的步驟；所述發(fā)送裝置將所述被加密后的電子文件的解碼所需口令進行加密，并對服務器發(fā) 送被加密的口令的步驟；接收裝置接收由所述發(fā)送裝置發(fā)送的所述電子郵件的步驟；所述服務器從所述發(fā)送裝置接收所述被加密的口令后，通過解碼，獲得所述解碼所 需口令的步驟；所述服務器，將所述解碼所需口令加密，對所述接收裝置發(fā)送被加密的口令的步馬聚o
2.根據(jù)權利要求1所述的電子文件發(fā)送方法，所述發(fā)送裝置對服務器發(fā)送所述被加密的口令的步驟，包含該發(fā)送裝置用公鑰對所 述被加密的電子文件的解碼所需口令進行加密；所述服務器得到所述解碼所需口令的步驟，包含該服務器用與所述公鑰對應的密鑰 解碼所述被加密的口令；所述服務器對所述接收裝置發(fā)送所述被加密的口令的步驟，包含該服務器用所述接 收裝置的公鑰加密所述解碼所需口令。
3.根據(jù)權利要求2所述的電子文件發(fā)送方法，包括所述服務器將識別所述被加密的電子文件的文件識別信息和識別該電子文件的正當 接收者的接收者識別信息相互對應存儲的步驟；對被所述接收者識別信息特別指定的接收者發(fā)送數(shù)據(jù)列的步驟； 所述服務器從接收裝置接收被與該接收裝置的公鑰對應的密鑰加密的數(shù)據(jù)列和該公 鑰的步驟；所述服務器在通過所述公鑰解碼所述被加密的數(shù)據(jù)列而得到的數(shù)據(jù)列與對所述接收 者發(fā)送后的數(shù)據(jù)列一致時，與所述接收者識別信息相對應，存儲所述公鑰的步驟。
4.根據(jù)權利要求1至3任何一項所述的電子文件發(fā)送方法，包括所述服務器從該接收裝置接收用于識別被所述接收裝置接收的被加密的文件的接收 文件識別信息與用于識別該接收裝置的用戶的用戶識別信息的步驟；所述服務器根據(jù)用于識別所述被加密的電子文件的文件識別信息、與該文件識別信 息對應的用于識別該電子文件正當?shù)慕邮照叩慕邮照咦R別信息、以及所述接收文件識別 信息及所述用戶識別信息來確定所述接收裝置的用戶是否是所述被加密的文件的正當接 收者的步驟；所述服務器，只在確定了所述接收裝置的用戶是所述正當?shù)慕邮照叩那闆r下，才對 所述接收裝置發(fā)送所述被加密后的口令。
5.根據(jù)權利要求1至4任何一項所述的電子文件發(fā)送方法，包括所述接收裝置在打開所述電子郵件中包含的所述被加密的電子文件的時候，向所述 服務器發(fā)送要求對該被加密的電子文件解碼所必需的口令的請求信號的步驟； 所述接收裝置，從所述服務器接收所述解碼所需口令的步驟； 所述接收裝置，使用所述解碼所需口令，將所述被加密的電子文件解碼的步驟； 所述服務器對所述接收裝置發(fā)送所述被加密的口令的步驟，通過所述服務器從所述接收裝置接收所述請求信號而執(zhí)行。
6.一種服務器，是對從用于發(fā)送包含被加密后的電子文件的電子郵件的發(fā)送裝置接 收該電子郵件的接收裝置，轉送將該被加密的文件解碼所必需的口令的服務器，其特征 在于，包括接收單元，從所述發(fā)送裝置接收對所述被加密的電子文件解碼所必需、且被加密的 口令；解碼單元，通過將所述加密的口令解碼，得到對所述被加密的電子文件的解碼所必 需的口令； 發(fā)送單元，將所述解碼所需口令加密后，發(fā)送給該接收裝置。
7.—種發(fā)送裝置，其特征在于，具有，郵件發(fā)送單元，發(fā)送包含被加密的電子文件的電子郵件；口令發(fā)送單元，對服務器發(fā)送對所述被加密的電子文件的解碼所必需，且被加密的 口令；其中，對所述服務器發(fā)送的口令，由該服務器通過解碼，而作為對所述被加密的電子文件 的解碼所必需的口令保存；并且，被所述服務器保存的所述口令，被該服務器加密后，對接收裝置發(fā)送。
8.—種接收裝置，是接收包含被加密的電子文件、且由發(fā)送裝置發(fā)送的電子郵件的 接收裝置，其特征在于，具有郵件接收單元，接收所述電子郵件；口令接收單元，從保存所述被加密后的電子文件的解碼所必需的口令的服務器接收 所述被加密的電子文件的解碼所必需、且被加密后的口令；被所述服務器保存的所述解碼所需口令，是通過所述服務器將被所述發(fā)送裝置加密 后的口令進行解碼而得到的。
9.一種接收裝置，是接收包含被加密的電子文件、且由發(fā)送裝置發(fā)送的電子郵件， 可通過將該被加密的電子文件解碼而生成電子文件的接收裝置，其特征在于，具有郵件接收單元，接收所述電子郵件；口令接收單元，從服務器接收對所述被加密的電子文件進行解碼所必需的口令；可否信息接收單元，從所述服務器接收表示對所述電子文件許可或禁止的處理的可 否信息；解碼單元，使用所述口令，通過對所述被加密的文件進行解碼，而在暫存區(qū)域展開 所述電子文件；執(zhí)行單元，按照所述可否信息執(zhí)行針對在所述暫存區(qū)域被展開的所述電子文件的處理。
10.根據(jù)權利要求9所述的接收裝置，所述解碼單元，由特定的應用軟件調用為了讀入所述被加密的電子文件的API模塊 的時候，由API鉤子(API HOOK)調用固有的鉤子模塊；該固有的鉤子模塊，在暫存區(qū)域中，通過對所述被加密的電子文件進行解碼展開所 述電子文件，對所述特定的應用軟件返回該電子文件的內容。
11.根據(jù)權利要求10所述的接收裝置，所述固有的鉤子模塊，不在固定存儲區(qū)域生成所述電子文件的內容，而是在暫存區(qū) 域中對所述特定的應用軟件返回所述電子文件的內容。
12.根據(jù)權利要求9所述的接收裝置，所述執(zhí)行單元，在特定的應用軟件啟動的時候，由API鉤子調用固有的鉤子模塊。
13.根據(jù)權利要求12所述的接收裝置，所述固有的鉤子模塊，當對實現(xiàn)在所述可否信息中被禁止的處理的API模塊的調用 由所述特定的應用軟件進行的時候，對該特定的應用軟件返回失敗。
14.根據(jù)權利要求12所述的接收裝置，所述固有的鉤子模塊，在對用于實現(xiàn)在所述可否信息中被許可的處理的API模塊的 調用由所述特定的應用軟件進行的時候，對該API模塊轉送其調用，對所述特定的應用 軟件返回該API模塊的執(zhí)行結果。
15.根據(jù)權利要求9至14任何一項所述的接收裝置，還具有，發(fā)送單元，對所述服務器發(fā)送表示由所述執(zhí)行單元執(zhí)行對在所述暫存區(qū)域被展開的 所述電子文件的操作的內容的操作內容信息。
16.根據(jù)權利要求15所述的接收裝置，由所述發(fā)送單元發(fā)送的所述操作內容信息，被所述服務器存儲， 被該服務器存儲的所述操作內容信息，能夠通過所述發(fā)送裝置閱覽。
17.根據(jù)權利要求9至16任何一項所述的接收裝置，其中， 所述服務器存儲所述可否信息，被該服務器存儲的所述可否信息，是被所述發(fā)送裝置設定的。
18.根據(jù)權利要求9至17任何一項所述的接收裝置，所述可否信息接收單元，在進行讀入所述被加密的電子文件的操作時，從所述服務 器接收所述可否信息；所述執(zhí)行單元，按照所述可否信息執(zhí)行對在所述暫存區(qū)域被展開的所述電子文件的處理。
19.一種電子文件發(fā)送方法，其特征在于，包括接收裝置接收含有被加密的電子文件，且由發(fā)送裝置發(fā)送的電子郵件的步驟； 所述接收裝置從服務器接收對所述被加密的電子文件解碼所必需的口令的步驟； 所述接收裝置從所述服務器接收表示對所述電子文件許可或禁止的處理的可否信息 的步驟；所述接收裝置通過使用所述口令，對所述被加密的電子文件進行解碼，在暫存區(qū)域 展開所述電子文件的步驟；以及所述接收裝置按照所述可否信息執(zhí)行對在所述暫存區(qū)域被展開的所述電子文件的處 理的步驟。
全文摘要
本發(fā)明提供一種能安全且簡單地對接收者發(fā)送電子文件的電子文件發(fā)送方法。接收裝置(120)從發(fā)送裝置(110)接收包含被加密的電子文件(511)的電子郵件(512)。發(fā)送裝置(110)用管理服務器(130)公鑰對被加密的電子文件(511)的解碼所必需的解碼用口令加密并發(fā)送給管理服務器(130)。管理服務器(130)保存與電子文件(511)文件識別符對應的解碼用口令和作為正當?shù)慕邮照叩慕邮昭b置(120)的接收者Y的電子郵件地址。接收裝置(120)對管理服務器(130)發(fā)送電子文件(511)文件識別符和接收者Y的電子郵件地址。管理服務器(130)，向接收裝置(120)發(fā)送用接收裝置(120)公鑰加密后的口令。
文檔編號H04L29/06GK102027719SQ200980117018
公開日2011年4月20日 申請日期2009年10月7日 優(yōu)先權日2008年12月26日
發(fā)明者菅野秀昭, 西江實, 道具登志夫, 高橋則行 申請人:電子技巧股份有限公司