JP4648412B2 - ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム - Google Patents

ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム Download PDF

Info

Publication number
JP4648412B2
JP4648412B2 JP2008016805A JP2008016805A JP4648412B2 JP 4648412 B2 JP4648412 B2 JP 4648412B2 JP 2008016805 A JP2008016805 A JP 2008016805A JP 2008016805 A JP2008016805 A JP 2008016805A JP 4648412 B2 JP4648412 B2 JP 4648412B2
Authority
JP
Japan
Prior art keywords
file
server
user terminal
container
archive
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2008016805A
Other languages
English (en)
Other versions
JP2009176247A (ja
Inventor
裕文 阿部
真樹 谷川
重彦 牛島
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nippon Telegraph and Telephone Corp
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to JP2008016805A priority Critical patent/JP4648412B2/ja
Publication of JP2009176247A publication Critical patent/JP2009176247A/ja
Application granted granted Critical
Publication of JP4648412B2 publication Critical patent/JP4648412B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Information Transfer Between Computers (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Storage Device Security (AREA)

Description

この発明は、Webブラウザを利用するWeb利用者端末を収容するアプリケーションサーバ装置と、アプリケーションサーバ装置や他の利用者端末から送信された暗号化されたファイルを受信して格納するファイルサーバ装置とから構成されるファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラムに関する。
従来より、端末装置間で電子データ(ファイル)などを送受信するファイル転送システムが利用されている。このファイル転送システムの送受信形態の一つとして、アプリケーション型クライアントから送信したファイルをWebブラウザ(以下単にブラウザという)で受信する手法が多く利用されている。
例えば、非特許文献1では、セキュアに大容量ファイルを流通させる大規模セキュアファイル流通基盤システム(SSS:Scalable Secure file Sharing system)が開示されている。
具体的には、図10に示すように、この大規模セキュアファイル流通基盤システムは、SSS専用のアプリケーションがインストールされた専用アプリユーザ端末と、ファイル転送サービスを提供するSSSサーバと、一般的なWebブラウザを使用するWebブラウザユーザ端末と、SSSサーバとWebブラウザユーザ端末との間に介在してWebブラウザユーザ端末を収容するAPサーバとから構成される。
このような構成において、各ユーザ端末がSSSサーバにデータを送信(アップロード)する場合、専用アプリユーザ端末は、図11に示すように、SSSサーバに格納したいファイル(データ)を圧縮(コンテナ化)して暗号化、チェックサム計算を行い、受信者端末を指定してSSSサーバに直接送信し、SSSサーバは、この受信したコンテナを格納する。一方、専用アプリがインストールされていないWebブラウザユーザ端末は、SSSサーバに格納したいファイルと受信者端末を指定してAPサーバに送信し、APサーバは、図12に示すように、専用アプリユーザ端末と同様の処理であるコンテナ化、暗号化、チェックサム計算を行ってSSSサーバに送信する。そして、SSSサーバは、この受信したコンテナを格納する。
そして、このようにして、SSSサーバに格納されたファイル(コンテナ)を各受信者端末が受信(ダウンロード)する場合について説明する。まず、受信者端末が専用アプリユーザ端末である場合、受信者端末は、SSSサーバに対してファイル取得要求を直接送信し、SSSサーバは、この要求に応じて該当するファイルを受信者端末に送信する。そして、受信者端末は、受信したファイルに対して、チェックサム計算、復号化およびコンテナ解凍を行うことで、当該ファイルを得ることができる。次に、受信者端末がWebブラウザユーザ端末である場合、受信者端末は、APサーバに対してSSSサーバに格納されるファイルの取得要求を送信し、APサーバは、図13に示すように、バッチ処理などによってSSSサーバから定期的に受信したコンテナに対してチェックサム計算、復号化およびコンテナ解凍を行って蓄積しておき、蓄積されるファイルから当該取得要求に対応するファイルを受信者端末に送信する。
このようにすることで、専用アプリユーザ端末間、Webブラウザユーザ端末間、専用アプリユーザ端末とWebブラウザユーザ端末間とにおいて、電子メールに添付できないような大容量のファイル(データ)を送受信させることができる。
"大規模セキュアファイル流通基盤システム(SSS)"、NTT技術ジャーナル8月号、2006.8、p36〜p39
しかしながら、上記した従来の技術は、専用アプリを持たない受信者端末にとっては、複数のファイルをまとめてダウンロードすることができず、利便性が悪いという課題があった。
具体的には、受信者端末が専用アプリユーザ端末である場合、受信者端末は、ファイルを複数選択してドラック&ドロップすることにより、多数のファイルをコンテナとして一度でSSSサーバにアップロードし、また同様に、SSSサーバから複数のコンテナを一度にダウンロードすることができる。一方で、受信者端末が専用アプリを持たないWebブラウザユーザ端末である場合、受信者端末は、ファイルを複数選択してドラック&ドロップすることができない一般的なWebブラウザを用いて、複数のファイルをコンテナとして一度でWebサーバを介してSSSサーバにアップロードする必要があり、また、SSSサーバに格納される複数のコンテナをAPサーバを介してダウンロードする際には、1コンテナずつWebブラウザを用いてAPサーバからファイルをダウンロードする必要がある。
例えば、送信者端末が専用アプリユーザ端末である場合に、SSSサーバを介して10ファイル(10コンテナ)をWebブラウザユーザ端末である受信者端末に送信する場合について説明する。この場合、送信者端末は、ドラック&ドロップすることにより、10ファイルを10コンテナとしてSSSサーバにアップロードしたとする。その後、SSSサーバは、格納した10コンテナをAPサーバにバッチ処理で送信する。そして、受信者端末は、送信者端末がSSSサーバにアップロードした後にAPサーバに送信された10コンテナを、Webブラウザを用いて1コンテナずつの計10回、APサーバからファイルをダウンロードするため、Webブラウザユーザ端末にとっては、利便性が非常に悪い。なお、専用アプリユーザ端末の場合は、10コンテナを指定することにより、1回でダウンロードすることができる。
そこで、この発明は、上述した従来技術の課題を解決するためになされたものであり、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することが可能であるファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラムを提供することを目的とする。
上述した課題を解決し、目的を達成するため、請求項1に係る発明は、Webブラウザを利用するWeb利用者端末と、前記Web利用者端末を収容するアプリケーションサーバ装置と、ファイル転送用の専用アプリケーションがインストールされた専用利用者端末と、前記アプリケーションサーバ装置や前記専用利用者端末から受信した暗号化されたファイルを格納し、ファイルの転送サービスを提供するファイルサーバ装置とから構成されるファイル転送システムであって、前記アプリケーションサーバ装置は、前記ファイルを受信する受信者端末がWeb利用者端末である場合に、前記ファイルサーバ装置から所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化する復号化手段と、前記復号化手段により復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成するアーカイブ処理手段と、を備えることを特徴とする。
また、請求項に係る発明は、上記の発明において、前記アプリケーションサーバ装置は、前記アーカイブ処理手段により生成されたアーカイブファイルを暗号化して、所定の記憶部に格納する再暗号化手段と、前記再暗号化手段により暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を前記受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するファイル応答手段と、を備え、前記ファイルサーバ装置は、前記ファイルを受信する受信者端末が専用利用者端末である場合に、当該専用利用者端末に対して前記専用アプリケーションで要求された複数のファイルを同時に送信する送信手段、を備えることを特徴とする。
また、請求項に係る発明は、上記の発明において、前記復号化手段は、前記受信者端末からファイルの取得要求を受信した場合に、当該要求に対応するファイルを前記ファイルサーバ装置から取得して復号化し、前記アーカイブ処理手段は、前記復号化手段により復号化されたファイルを同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、前記ファイル応答手段は、前記アーカイブ処理手段により同一の受信者端末ごとにアーカイブ化されたアーカイブファイルを、当該受信者端末に応答することを特徴とする。
また、請求項に係る発明は、請求項1又は2に記載のファイル転送システムで用いられるアプリケーションサーバ装置であることを特徴とする。
また、請求項に係る発明は、Webブラウザを利用するWeb利用者端末と、前記Web利用者端末を収容するアプリケーションサーバ装置と、ファイル転送用の専用アプリケーションがインストールされた専用利用者端末と、前記アプリケーションサーバ装置や他の利用者端末から送信された暗号化されたファイルを受信して格納し、ファイルの転送サービスを提供するファイルサーバ装置とから構成されるファイル転送システムに適したファイル転送方法であって、前記アプリケーションサーバ装置が、前記ファイルを受信する受信者端末がWeb利用者端末である場合に、前記ファイルサーバ装置から所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化する復号化工程と、前記復号化工程により復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成するアーカイブ処理工程と、前記アーカイブ処理工程により生成されたアーカイブファイルを暗号化して、所定の記憶部に格納する再暗号化工程と、前記再暗号化工程により暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を前記受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するファイル応答工程と、を含み前記ファイルサーバ装置が、前記ファイルを受信する受信者端末が専用利用者端末である場合に、当該専用利用者端末に対して前記専用アプリケーションで要求された複数のファイルを同時に送信する送信工程、を含むことを特徴とする。
また、請求項に係る発明は、請求項3に記載のアプリケーションサーバ装置としてコンピュータに実行させるためのファイル転送プログラムであることを特徴とする。
請求項1、の発明によれば、ファイルサーバ装置から所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化し、復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、同一の受信者端末ごとにアーカイブ化されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するので、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することが可能である。
例えば、複数のファイルをアーカイブ化して1つのファイルにまとめることにより、多数のファイルが一度に送信されたWebブラウザを利用する受信者端末であっても、1回のダウンロードでファイルを受信することができる。
また、請求項1、3、4、5の発明によれば、生成されたアーカイブファイルを暗号化して、所定の記憶部に格納し、暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するので、セキュリティを高くファイル転送を行うことが可能である。
例えば、従来行われていたように、アプリケーションサーバ(APサーバ)は、ファイルサーバ(SSSサーバ)から受信したファイルを平文のまま一度保存し、その後に、受信者端末の要求に応じて、平文で保存するファイルを応答する場合に比べて、アーカイブ化されたアーカイブファイルを暗号化して保存し、受信者端末の要求に応じて、暗号化されたアーカイブファイルを復号化して受信者端末に応答することができる結果、アプリケーションサーバ自体の盗難、サーバへの不正侵入に対しても、機密情報を守ることができる。
また、請求項の発明によれば、受信者端末からファイルの取得要求を受信した場合に、当該要求に対応するファイルをファイルサーバ装置から取得して復号化し、復号化されたファイルを同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、当該受信者端末に応答するので、リアルタイムに復号しながら、ファイルを転送することができる結果、機密情報を強固に守ることができる。
以下に添付図面を参照して、この発明に係るファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラムの実施例を詳細に説明する。なお、以下では、本実施例で用いる主要な用語、本実施例に係るファイル転送システムの概要および特徴、ファイル転送システムの構成および処理の流れを順に説明し、最後に本実施例に対する種々の変形例を説明する。
[用語の説明]
まず最初に、本実施例で用いる主要な用語を説明する。本実施例で用いるファイル転送システムは、一般的なWebブラウザのJava(登録商標)APIであるサーブレットを用いてファイルを送受信するWeb利用者端末(特許請求の範囲に記載の「Web利用者端末」または「受信者端末」に対応する)と、Webブラウザ端末からファイルを受信してコンテナ化、暗号化、チェックサム計算を行ってSSSサーバに送信するAPサーバ(特許請求の範囲に記載の「アプリケーションサーバ装置」に対応する)と、専用アプリケーションを用いてファイルをコンテナ化、暗号化、チェックサム計算を行ってSSSサーバに直接送信する専用利用者端末(特許請求の範囲に記載の「他の利用者端末」または「受信者端末」に対応する)と、APサーバや専用利用者端末から受信したコンテナを格納して他の端末に転送するSSSサーバ(特許請求の範囲に記載の「ファイルサーバ装置」に対応する)とから構成される。なお、SSSサーバに格納されるコンテナとは、APサーバまたは専用利用者端末から送信されたファイルのことを示す、つまり、複数のファイルが同時に送信された場合、当該複数のファイルが1コンテナとなる。
そして、このファイル転送システムでは、Web利用者端末や専用利用者端末は、受信者端末となるWeb利用者端末や専用利用者端末を指定して、送信したい複数のファイルをコンテナとしてSSSサーバにアップロードするため、SSSサーバに格納されているコンテナは、送信時に指定された受信者端末に限りダウンロードすることができる。また、SSSサーバは、当該ファイル転送システムを利用する利用者端末のIPアドレスなど、利用者端末を一意に識別する情報を記憶しており、同様に、APサーバも、当該ファイル転送システムを利用するWeb利用者端末のIPアドレスなど、利用者端末を一意に識別する情報を記憶している。
また、APサーバおよび専用利用者端末は、共通鍵暗号方式や公開鍵暗号方式、またそれらを組み合わせた手法など一般的な暗号化方式を用いて、ファイルをコンテナ化および暗号化してSSSサーバに送信し、各利用者端末間でファイルの転送を行う。例えば、APサーバまたは専用利用者端末は、予め記憶している受信者端末の公開鍵で暗号化したコンテナをSSSサーバに送信し、受信者端末(専用利用者端末)は、SSSサーバから受信した暗号化されたコンテナを自身の秘密鍵で復号化することで、コンテナ化されたファイルを取得する。また別の手法としては、APサーバまたは専用利用者端末は、受信者端末(専用利用者端末)との共通鍵でコンテナを暗号化し、暗号化したコンテナを受信者端末の公開鍵で暗号化してSSSサーバに送信する。そして、受信者端末(専用利用者端末)は、SSSサーバから受信した暗号化されたコンテナと共通鍵とを自身の秘密鍵で復号化して共通鍵を取得し、取得した共通鍵でコンテナを復号化することで、コンテナ化されたファイルを得ることができる。ここで、共通鍵や受信者端末の公開鍵などは、一般的な手法を用いて、予めセキュアな状態で取得しているものとする。
なお、Web利用者端末がAPサーバを介してコンテナをSSSサーバに送信する手法や専用利用者端末同士がSSSサーバを介してコンテナを送受信する手法については、図8〜図11と同様の手法を用いるので、ここでは、その詳細な説明は省略する。また、専用利用者端末についても、必ず専用アプリを用いたファイル転送を行う必要はなくWebブラウザを用いてファイル転送を行ってもよい。その場合、専用利用者端末は、APサーバにアクセスして、APサーバを介してSSSサーバにファイルを送信したり、SSSサーバからファイルを受信したりするので、Web利用者端末と同じ手法を用いることになる。
[ファイル転送システムの概要および特徴]
次に、図1を用いて、実施例1に係るファイル転送システムの概要および特徴を説明する。図1は、実施例1に係るファイル転送システムの概要と特徴を説明するための図である。
図1に示すように、このファイル転送システムは、ユーザA〜ユーザCなどが利用する複数のWeb利用者端末と、APサーバと、専用アプリを利用する複数の専用利用者端末と、SSSサーバとから構成される。そして、SSSサーバは、APサーバや専用利用者端末から受信した暗号化されたコンテナを受信して記憶している。
このような構成において、実施例1に係るファイル転送システムは、上記したように、SSSサーバを介して、専用利用者端末間、Web利用者端末間、専用利用者端末とWeb利用者端末間とにおいて、電子メールに添付できないような大容量のファイル(データ)を送受信させることを概要とするものであり、特に、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することが可能であることに主たる特徴がある。
この主たる特徴を具体的に説明すると、APサーバは、SSSサーバから所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化し、そして、復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成する(図1の(1)と(2)参照)。
具体的に例を挙げると、APサーバは、定期的にバッチ処理などにより、SSSサーバから受信者端末(当該コンテナを受信するWeb利用者端末であり、例えば、ユーザAが利用するWeb利用者端末)との共通鍵で暗号化されたコンテナと受信者端末の公開鍵で暗号化された共通鍵を受信する。そして、APサーバは、受信した暗号化されているコンテナに対して、公開鍵を予め登録する際に作成した受信者端末の秘密鍵を用いて、受信した受信者端末の公開鍵で暗号化された共通鍵を復号化する。続いて、APサーバは、復号化した共通鍵を用いて、SSSサーバから受信した暗号化されているコンテナそれぞれを復号化する。その後、APサーバは、このようにして復号化されたコンテナにそれぞれ指定されている受信者が同一であるコンテナを抽出し、抽出した同一の受信者端末であるコンテナをJava(登録商標)のAPIを用いてZIP化するとともに、それぞれの受信者端末ごとに共通鍵を作成する。
続いて、APサーバは、生成されたアーカイブファイルを暗号化して所定の記憶部に格納する(図1の(3)参照)。上記した例で具体的に説明すると、APサーバは、上記で生成されたZIP化されたファイル群(アーカイブファイル)に対して、作成した共通鍵で暗号化するとともに、使用した共通鍵を受信者の公開鍵で暗号化してアーカイブファイルDBに格納する。
その後、APサーバは、暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該取得要求に対応するアーカイブファイルを復号化して、当該受信者端末に応答する(図1の(4)と(5)を参照)。上記した例で具体的に説明すると、APサーバは、受信者端末であるユーザAが利用するWeb利用者端末からファイル(またはコンテナ)の取得要求を受信する。すると、APサーバは、ユーザAが利用する端末のIPアドレスなどからユーザAが受信者端末となっているアーカイブファイルをアーカイブファイルDBから特定するとともに、ユーザAの秘密鍵を用いて共通鍵を復号化する。そして、APサーバは、復号化した共通鍵を用いて、特定したアーカイブファイルをアーカイブファイルDBから取得して復号化し、復号化したアーカイブファイルを受信者端末でありユーザAが利用する端末に送信する。
このように、実施例1に係るファイル転送システムは、受信者端末が一致する複数のファイルをアーカイブ化して、専用アプリケーションを持たないWeb利用者端末であっても、一度で複数のファイルをダウンロードさせることができる結果、上記した主たる特徴のごとく、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することが可能である。
[ファイル転送システムの構成]
次に、図2を用いて、図1に示したファイル転送システムの構成を説明する。ここでは、本実施例におけるファイル転送システムに密接に関連するAPサーバについて具体的に説明し、その他の装置については、詳細な説明は省略する。図2は、実施例1に係るファイル転送システムにおけるAPサーバの構成を示すブロック図である。
図2に示すように、このAPサーバ10は、通信制御I/F部11と、ファイル受信部12と、送信用データDB13と、送信用構造化処理部20と、コンテナ送信部24と、コンテナ受信部31と、応答用データDB32と、アーカイブDB33と、応答用構造化処理部40と、ファイル応答部46とから構成される。
通信制御I/F部11は、SSSサーバやWeb利用者端末との間でやり取りする各種情報に関する通信を制御する。具体的に例を挙げれば、通信制御I/F部11は、ファイル受信部12とコンテナ送信部24とコンテナ受信部31とファイル応答部46とにそれぞれ接続され、Web利用者端末からファイルを受信したり、Web利用者端末から受信したファイルをコンテナとしてSSSサーバに送信したり、SSSサーバからコンテナを受信したり、Web利用者端末に対してファイルを応答する各種制御を行う。
ファイル受信部12は、Web利用者端末からファイルを受信する。具体的に例を挙げると、ファイル受信部12は、コンテナ生成部21に接続され、Web利用者端末から要求に応じて、ファイルをSSSサーバに送信するためのWeb画面などを当該Web利用者端末に応答する。そして、ファイル受信部12は、応答したWeb画面のJava(登録商標)APIであるサーブレットから、SSSサーバに送信したいファイルと当該ファイルの受信者装置などの指定を受け付けて、当該ファイルをコンテナ生成部21に出力する。なお、ここで、ファイル受信部12は、送信元の端末装置を識別するための情報(例えば、IPアドレスやユーザIDなど)を取得する。
送信用データDB13は、送信用構造化処理部20で使用される各種暗号鍵を記憶したり、送信用構造化処理部20により生成されたコンテナを記憶したりする。具体的に例を挙げると、送信用データDB13は、コンテナ送信部24やチェックサム計算部23とに接続され、当該ファイル転送システムを利用するWeb利用者端末を識別する識別子(例えば、IPアドレスやユーザIDなど)に対応付けて共通鍵や公開鍵を記憶し、また、後述する送信用構造化処理部20により生成されたコンテナを記憶する。
送信用構造化処理部20は、SSSサーバに送信するコンテナを生成する制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、特に本発明に密接に関連するものとしては、コンテナ生成部21と、暗号化部22と、チェックサム計算部23とを備え、これらによって種々の処理を実行する。
コンテナ生成部21は、Web利用者端末から取得されたファイルをコンテナ化する。具体的に例を挙げれば、コンテナ生成部21は、ファイル受信部12や暗号化部22にそれぞれ接続され、通信制御I/F部11を介してファイル受信部12により受信されたファイルを取得し、当該ファイルを圧縮(アーカイブ化)してコンテナを生成し、生成したコンテナを後述する暗号化部22に出力する。
暗号化部22は、コンテナ生成部21により生成されたコンテナを暗号化する。具体的に例を挙げれば、暗号化部22は、コンテナ生成部21とチェックサム計算部23とにそれぞれ接続され、コンテナ生成部21から取得したコンテナの受信者端末を判別し、当該判別した受信者端末に対応する共通鍵を送信用データDB13から取得して、当該コンテナを暗号化する。そして、暗号化部22は、当該受信者端末の公開鍵を送信用データDB13から取得して、コンテナの暗号化に使用した共通鍵を、当該公開鍵を用いて暗号化する。その後、暗号化部22は、暗号化したコンテナと共通鍵とを新たなコンテナとしてチェックサム計算部23に出力する。
チェックサム計算部23は、SSSサーバに送信するコンテナごとにチェックサムを計算する。具体的に例を挙げれば、チェックサム計算部23は、暗号化部22と送信用データDB13とにそれぞれ接続され、暗号化部22から取得した暗号化された新たなコンテナに対して、チェックサムを計算して付加し、同様に取得された暗号化された共通鍵とともに、送信用データDB13に格納する。
コンテナ送信部24は、生成されたコンテナをSSSサーバに送信する。具体的に例を挙げれば、コンテナ送信部24は、通信制御I/F部11と送信用データDB13とにそれぞれ接続され、送信用データDB13に記憶される暗号化されたコンテナと共通鍵とから構成される新たなコンテナを取得し、当該新たなコンテナを通信制御I/F部11を介して、SSSサーバに送信する。
コンテナ受信部31は、SSSサーバからコンテナを受信する。具体的に例を挙げれば、コンテナ受信部31は、SSSサーバに格納されるコンテナの新着・状態を確認する新着・状態確認処理と、SSSサーバから受信したコンテナをライブラリ化するクライアントライブラリと、SSSサーバからコンテナを受信する受信処理とをそれぞれ実施する。また、コンテナ受信部31は、通信制御I/F部11と復号化部41とにそれぞれ接続され、バッチ処理などにより定期的にSSSサーバに格納されている複数のコンテナ(上記した新たなコンテナ)を受信して、後述する復号化部41に出力する。
応答用データDB32は、応答用構造化処理部40で使用される各種暗号鍵を記憶したり、応答用構造化処理部40により生成されたコンテナを一時的に記憶したりする。具体的に例を挙げると、応答用データDB32は、受信者端末を識別する識別子に対応付けて公開鍵や、公開鍵を予め登録する際に作成した受信者端末ごとの秘密鍵や、応答用構造化処理部40により生成された受信者端末ごとに共通鍵などを記憶したり、後述するコンテナ解凍部43により解凍されたコンテナやファイルを一時的に記憶したりする。
アーカイブDB33は、生成されたアーカイブを記憶する。具体的に例を挙げれば、アーカイブDB33は、ファイル応答部46と再暗号化部45とにそれぞれ接続され、再暗号化部45により生成されて格納されたアーカイブファイルを記憶する。
応答用構造化処理部40は、受信者端末に送信するファイルを生成する制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有するとともに、特に本発明に密接に関連するものとしては、復号化部41と、チェックサム計算部42と、コンテナ解凍部43と、アーカイブ処理部44と、再暗号化部45とを備え、これらによって種々の処理を実行する。
復号化部41は、SSSサーバから所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化する。上記した例で説明すると、復号化部41は、コンテナ受信部31とチェックサム計算部42とにそれぞれ接続され、コンテナ受信部31から取得した暗号化されたコンテナそれぞれと共通鍵とから構成される新たなコンテナそれぞれに対して、当該コンテナの受信者端末に対応する秘密鍵を応答用データDB32から取得し、当該秘密鍵を用いて、SSSサーバに送信される際に暗号化部22により受信者端末の公開鍵で暗号化された共通鍵それぞれを復号化する。続いて、復号化部41は、復号化した共通鍵を用いて、SSSサーバから受信された暗号化されている新たなコンテナを復号化する。そして、復号化部41は、復号化したコンテナそれぞれをチェックサム計算部42に出力する。なお、受信されたコンテナそれぞれの応答先となる受信者端末の判定には、当該ファイルに付加される(一般的に付加されているパケットのヘッダなど)を示す識別子(例えば、IPアドレスやユーザID)などを用いることで判別することができる。
チェックサム計算部42は、チェックサムを計算して、受信されたコンテナに誤りがないかを判定する。具体的に例を挙げれば、チェックサム計算部42は、復号化部41と応答用データDB32とコンテナ解凍部43とにそれぞれ接続され、復号化部41から取得したコンテナそれぞれのチェックサムを計算し、当該コンテナに誤りがないかを判定する。そして、チェックサム計算部42は、誤りがないと判定したコンテナを応答用データDB32に格納し、誤りがあると判定したコンテナに対しては、その旨をSSSサーバに送信する。
コンテナ解凍部43は、受信されたコンテナを解凍する。具体的に例を挙げれば、コンテナ解凍部43は、応答用データDB32とチェックサム計算部42とアーカイブ処理部44とにそれぞれ接続され、チェックサム計算部42により格納されたコンテナそれぞれを応答用データDB32から取得し、当該コンテナを解凍して応答用データDB32に格納する。
アーカイブ処理部44は、復号化部41により復号されたコンテナそれぞれに対して、同一の受信者端末ごとに、当該コンテナをZIP化(アーカイブ化)してアーカイブファイルを生成する。上記した例で具体的に説明すると、アーカイブ処理部44は、応答用データDB32と再暗号化部45とコンテナ解凍部43とにそれぞれ接続され、応答用データDB32に記憶される解凍されたコンテナに対して、同一の受信者端末ごとに、当該コンテナをアーカイブ化してアーカイブファイルを生成する。そして、アーカイブ処理部44は、それぞれの受信者端末ごとに共通鍵を作成して、受信者端末に対応付けて共通鍵を応答用データDB32に格納する。なお、受信されたコンテナに対して、同一の受信者端末を判定するには、コンテナ送信時にコンテナ送信部24により当該コンテナに付加される(例えば、一般的に付加されているパケットのヘッダなど)受信者端末を示す識別子(例えば、IPアドレスやユーザID)などを用いることで判別することができる。
再暗号化部45は、アーカイブ処理部44により生成されたアーカイブファイルを暗号化して所定の記憶部に格納する。上記した例で具体的に説明すると、再暗号化部45は、アーカイブ処理部44により生成されたZIP化されたアーカイブファイルに対して、それぞれのアーカイブファイルの受信者端末それぞれに対応付けて記憶されるアーカイブ処理部44により作成された共通鍵それぞれを、応答用データDB32から取得する。そして、再暗号化部45は、取得したそれぞれの共通鍵を用いてそれぞれのアーカイブファイルを暗号化するとともに、当該アーカイブファイルの受信者端末に対応付けて記憶されるそれぞれの公開鍵を、応答用データDB32から取得し、取得したそれぞれの公開鍵を用いて、それぞれのアーカイブファイルの暗号化に使用した共通鍵を暗号化してアーカイブDB33に格納する。なお、ここでは、アーカイブDB33には、受信者端末と、共通鍵で暗号化されたアーカイブファイルと、公開鍵で暗号化された共通鍵とが対応付けて記憶されることとなる。
ファイル応答部46は、再暗号化部45により暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答する。上記した例で具体的に説明すると、ファイル応答部46は、受信者端末からファイルの取得要求を受信すると、当該端末のIPアドレスなどから受信者端末を特定する。そして、ファイル応答部46は、特定した受信者端末に対応するアーカイブファイルをアーカイブDB33から特定する。さらに、ファイル応答部46は、当該受信者端末に対応付けて記憶される秘密鍵を応答用データDB32から取得して、特定したアーカイブファイルに対応付けてアーカイブDB33に記憶される共通鍵を復号化する。そして、ファイル応答部46は、復号化した共通鍵を用いて、特定したアーカイブファイルをアーカイブDB33から取得して復号化し、復号化したアーカイブファイルを受信者端末に送信する。
[ファイル転送システムによる処理]
次に、図3〜7を用いて、ファイル転送システムによる処理を説明する。ここでは、図3と図4とを用いて、実施例1に係るファイル転送システムにおけるAPサーバで実施される処理の概要を説明し、図5〜図7を用いて、その詳細を説明する。
(APサーバによるSSSサーバへのファイル送信処理)
まず、図3を用いて、APサーバによるSSSサーバへのファイル送信処理について説明する。図3は、実施例1に係るAPサーバによるSSSサーバへのファイル送信処理の流れを示すフローチャートである。
図3に示すように、Web利用者端末から受信者端末が指定されているファイルを受信した場合に(ステップS101肯定)、APサーバ10は、当該ファイルを圧縮したコンテナを生成し、生成したコンテナを暗号化し、暗号化したコンテナのチェックサムを計算してコンテナに付加し、当該チェックサムが付加されたコンテナをSSSサーバに送信する(ステップS102〜ステップS105)。
具体的に例を挙げると、APサーバ10は、当該ファイルを圧縮したコンテナを生成し、受信者端末との共通鍵を用いて生成したコンテナを暗号化し、受信者端末に対応する公開鍵を送信用データDB13から取得して、取得した公開鍵で暗号化に用いた共通鍵を暗号化する。そして、APサーバ10は、共通鍵で暗号化したコンテナと公開鍵で暗号化した共通鍵とを新たなコンテナとして生成し、当該共通鍵で暗号化したコンテナのチェックサムを計算してコンテナに付加し、当該チェックサムが付加された新たなコンテナをSSSサーバに送信する
(APサーバによる受信者端末へのファイル応答処理)
次に、図4を用いて、APサーバによる受信者端末へのファイル応答処理について説明する。図4は、実施例1に係るAPサーバによる受信者端末へのファイル応答処理の流れを示すフローチャートである。
図4に示すように、SSSサーバから定期的にコンテナを受信した場合(ステップS201肯定)、APサーバ10は、受信したコンテナそれぞれ復号化し、復号化したコンテナそれぞれのチェックサムをそれぞれ計算する(ステップS202とステップS203)。
具体的に例を挙げると、APサーバ10は、SSSサーバから受信した共通鍵で暗号化したコンテナと公開鍵で暗号化した共通鍵とから構成される複数の新たなコンテナそれぞれに対して、当該コンテナの受信者端末に対応する秘密鍵を応答用データDB32から取得し、当該秘密鍵を用いて、受信者端末の公開鍵で暗号化された共通鍵を復号化する。そして、APサーバ10は、復号化した共通鍵を用いて、SSSサーバから受信された暗号化されている新たなコンテナをそれぞれ復号化する。その後、APサーバ10は、復号化して得られたコンテナのチェックサムを計算する。
そして、チェックサムの計算により誤りがないコンテナそれぞれに対して、APサーバ10は、コンテナそれぞれを解凍して、同一の受信者端末ごとにコンテナをアーカイブ化し、アーカイブ化された複数のアーカイブファイルをそれぞれ暗号化する(ステップS204〜ステップS206)。
具体的に例を挙げると、APサーバ10は、チェックサムの計算により誤りがないコンテナを解凍して、同一の受信者端末ごとにアーカイブ化する。そして、APサーバ10は、アーカイブ化されたアーカイブファイルごとに、当該アーカイブファイルの受信者端末に対応する共通鍵を用いて、それぞれのアーカイブファイルを暗号化する。さらに、APサーバ10は、当該アーカイブファイルの受信者端末に対応付けて記憶されるそれぞれの公開鍵を用いて、それぞれのアーカイブファイルの暗号化に使用した共通鍵を暗号化してアーカイブDB33に格納する。
その後、Web利用者端末である受信者端末からアーカイブファイル取得要求を受信すると(ステップS207肯定)、APサーバ10は、受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答する(ステップS208)。
具体的に例を挙げると、APサーバ10は、Web利用者端末である受信者端末からアーカイブファイル取得要求を受信すると、当該受信者端末に対応する秘密鍵を用いて、アーカイブファイルの暗号化に使用した共通鍵を暗号化する。続いて、APサーバ10は、復号化した共通鍵を用いて、アーカイブDB33に記憶される特定したアーカイブファイルを復号化して当該受信者端末に応答する。
(APサーバからSSSサーバへのアップロード)
次に、図5を用いて、APサーバからSSSサーバへのアップロードについて詳細に説明する。図5は、実施例1に係るAPサーバからSSSサーバへのアップロードの流れを示すシーケンス図である。
図5に示すように、APサーバ10のファイル受信部12のサーブレットは、Web利用者端末からファイルアップロードを受け付ける(ステップS301)。すると、サーブレットは、APサーバ10のFileSystemに対して、一時ファイルを作成してファイルを格納し(ステップS302)、作成した一時ファイルに格納されたファイルからファイル情報を取得する(ステップS303とステップS304)。
そして、サーブレットは、送信用構造化処理部20に対して圧縮(コンテナ化)/暗号化スレッドを起動する一方で(ステップS305)、ファイルアップロードを行ったWeb利用者端末に対してアップロード完了画面を表示する(ステップS306)。その後、送信用構造化処理部20は、圧縮/暗号化/チェックサム計算を行って(ステップS307)、コンテナファイルをFileSystemに作成(一時格納)して(ステップS308)、コンテナ送信部24に対してコンテナ送信スレッドを起動する(ステップS309)。そして、コンテナ送信部24は、当該コンテナをSSSサーバに送信し(ステップS310とステップS311)、送信用構造化処理部20は、作成した一時ファイルを削除する(ステップS312)。
上記した処理を具体的に説明すると、Web利用者端末によりAPサーバにアクセスがされると、APサーバ10は、コンテナ送信メインメニュー(Web画面)をWeb利用者端末に表示し、Web利用者端末から「コンテナ送信ボタン」が押下されると、当該セッションからログイン情報、VNetworkIF以外の情報を破棄する。そして、APサーバ10は、当該セッションより配達証明可否フラグと暗号送受信禁止モードフラグを取得する。すると、APサーバ10は、取得した配達証明可否フラグと暗号送受信禁止モードフラグとによりコンテナ送信画面表示情報を、当該アクセスされているブラウザに返却することで、Web利用者端末に対して「コンテンツ送信画面」を表示する。
Web利用者端末により「コンテンツ送信画面」の各入力項目(例えば、配達証明可否フラグやファイル受領確認情報や配達証明付きなどの付加オプションなど)が入力されて、「送信ボタン」が押下されると、Web利用者端末からAPサーバにコンテナ送信要求が送信される。すると、APサーバ10は、当該Web利用者端末とのセッションから、配達証明可否フラグとアップロード制限値と、Web利用者端末により「コンテンツ送信画面」に入力されたファイル暗号化可否の値とを取得する。そして、APサーバ10は、取得した配達証明可否フラグとアップロード制限値と、Web利用者端末により「コンテンツ送信画面」に入力された各値とのチェックを行う。
このチェックに問題(不都合、誤り)がなければ、APサーバ10は、FileSystemよりファイル保存ディレクトリを取得し、取得したファイル保存ディレクトリから各ファイルを保存するディレクトリを作成し、Web利用者端末によりアップロードされたファイルを保存する。そして、APサーバ10は、FileSystemの別の領域に、アップロードされたコンテナ情報を登録し、コンテナ送信完了画面表示情報をブラウザに返却することで、Web利用者端末にアップロード完了画面が表示される。
その後、APサーバ10は、SSSサーバに対して、エイリアスアドレスを通知するためのアドレス展開要求を行って、アドレス数のチェックを行い、展開したアドレスを自装置のFileSystemに登録する。そして、APサーバ10は、Vcontオブジェクトを作成し、上記で取得したファイル暗号化可否の値が「可」であり、かつ、展開されたアドレスの受信者の公開鍵が取得できた場合、ファイルをZIP化(アーカイブ化)した上で暗号化する。なお、暗号化可否の値が「否」または受信者の公開鍵が取得できなかった場合は、暗号化なしや予め定めた暗号化手法を用いた暗号化送信を実行する。
続いて、APサーバ10は、作成された暗号化ファイルのサイズをアップロード制限値よりチェックし、制限値を超える場合には、ファイルサイズ超過による暗号送信失敗として、履歴情報に格納する。
そして、作成された暗号化ファイルのサイズがアップロード制限値よりも小さい場合、APサーバ10は、ファイル受領確認情報や配達証明付きなどの付加オプションの情報を取得してメタデータを生成する。その後、APサーバ10は、作成したコンテナをSSSサーバに送信し、送信完了後に、コンテナID、送信日時、コンテナファイルサイズを用いて、上記で格納したコンテナ情報を更新し、自装置に格納したアーカイブ前のファイル、メタデータファイル、アーカイブ後のファイルを削除する。なお、ファイル受領確認情報や配達証明付きなどの付加オプションがあった場合には、APサーバ10は、送信完了後に、Web利用者端末に対してファイル受領確認や配達証明などを応答する。
(APサーバにおけるSSSサーバからのコンテナ定期受信)
次に、図6を用いて、APサーバにおけるSSSサーバからのコンテナ定期受信処理について詳細に説明する。図6は、実施例1に係るAPサーバにおけるSSSサーバからのコンテナ定期受信処理の流れを示すシーケンス図である。
図6に示すように、APサーバ10のコンテナ受信部31のクライアントライブラリは、新着コンテナが届いているかどうかをSSSサーバに問い合わせ、設定された周期でコマンド「get Contsinfo」を実行して、コンテナ情報を取得し、コンテナ到着イベントを新着・状態確認処理に通知する(ステップS401〜ステップS404)。
すると、コンテナ受信部31は、新着・状態確認処理において、新着コンテナが有り、自動受信が有効であるのと、暗号送受信禁止モードとダウンロード制限値とを取得する(ステップS405〜ステップS408)。そして、暗号送受信禁止モードとダウンロード制限値とのそれぞれに違反しない場合、コンテナ受信部31は、新着・状態確認処理において、受信処理に対して、全てのコンテナの受信を依頼し、コンテナ受信部31は、受信処理において、SSSサーバから全てのコンテナを受信して、新着・状態確認処理にダウンロードしたことを通知する(ステップS409〜ステップS412)。
その後、コンテナ受信部31は、新着・状態確認処理において、ダウンロードサイズを確認してダウンロードを行い、ダウンロードしたコンテナを復号化してクライアントライブライに格納するとともに、当該コンテナをZIP化して、ZIP化したコンテナを再暗号化する(ステップS413〜ステップS417)。なお、暗号送受信禁止モードが「暗号禁止」の場合やダウンロードサイズがダウンロード制限値を超える場合、暗号化コンテナ受信失敗となる。
上記した処理を具体的に説明すると、コンテナ到着イベントが通知されたAPサーバ10は、SSSサーバから暗号送受信禁止モードとダウンロード制限値とファイル読み込みパラメータとを取得して、暗号化されたコンテナをSSSサーバから受信する。そして、APサーバ10は、暗号化コンテナ受信後、公開鍵登録時に作成した受信者端末の秘密鍵を応答用データDB32から取得する。続いて、APサーバ10は、受信したコンテナのファイルサイズを取得するとともに、受信者の公開鍵で暗号化された共通鍵を、取得した受信者端末の秘密鍵を用いて復号化する。
その後、APサーバ10は、復号化して得られた共通鍵を用いて、受信したコンテナを復号し、クライアントライブラリで解凍する。なお、サーバの状態が暗号送受信禁止モードや取得したコンテナのサイズが制限値以上である場合、APサーバ10は、受信したファイルを削除し、ユーザ状態定義により状態変更を実行する。
そして、APサーバ10は、解凍したコンテナからZIPエンコーディングタイプを取得して、取得したいZIPエンコーディングタイプから文字コードを指定し、Java(登録商標)のAPIを用いて、当該コンテナをZIP化する。続いて、APサーバ10は、ZIP化したコンテナを復号化して得られた共通鍵を用いて暗号化し、使用した共通鍵を受信者の公開鍵で暗号化して記憶する。そして、APサーバ10は、ダウンロード可能状態をSSSサーバに通知し、各コンテナの状態を更新する。
(APサーバからWeb利用者端末へのファイル送信)
次に、図7を用いて、APサーバからWeb利用者端末へのファイル送信処理について詳細に説明する。図7は、実施例1に係るAPサーバからWeb利用者端末へのファイル送信処理の流れを示すシーケンス図である。
図7に示すように、Web利用者端末に表示されるブラウザの「ファイル名リンク」が利用者によりクリックされると、Web利用者端末からAPサーバ10に対してファイルダウンロード要求が送信される(ステップS501とステップS502)。すると、APサーバ10のファイル応答部46は、Web要求処理機能において、ファイルの受領を「済」に更新し、ダウンロード画面をWeb利用者端末に表示する(ステップS503とステップS506)。
その後、Web利用者端末に表示される「ダウンロード画面」のダウンロード開始ボタンがクリックされて、ダウンロード要求がAPサーバ10に送信されると、ファイル応答部46は、Web要求処理機能において、ファイル受信機能にコンテナファイルアクセスインクリメント要求を送信し、ファイル受信機能において、アーカイブDB33のコンテナファイルアクセス数がインクリメントされてダウンロード要求がWeb要求処理機能に送信される(ステップS507〜ステップS511)。
すると、ファイル応答部46は、Web要求処理機能において、ダウンロード開始指示がファイル受信機能に通知され、ファイル受信機能において、該当するファイルがアーカイブDB33から取得されて復号化され、処理結果(成功または失敗)がWeb要求処理機能に通知される(ステップS512〜ステップS516)。そして、ファイル応答部46は、Web要求処理機能において、ファイルダウンロード更新(済)をファイル受信機能に通知し、ファイル受信機能において、アーカイブDB33からダウンロードされたファイルのダウンロードフラグを「済」に更新し、その結果を受けて、Web利用者端末に接続されているブラウザを介してファイルを応答する(ステップS517〜ステップS522)。
その後、ファイル応答部46は、Web要求処理機能において、アーカイブDB33においてダウンロードしたコンテナのコンテナファイルアクセス数をデクリメントし、ダウンロード完了処理要求を受信すると、ファイル受信機能に対してダウンロード完了処理機能の実行要求を送信し、ダウンロード完了処理結果がファイル受信機能より通知されることで、ダウンロード処理を終了する(ステップS523〜ステップS527)。
上記した処理を具体的に説明すると、Web利用者端末は、利用者の操作により、ファイル受信画面(受信コンテナ詳細画面)のファイル一覧からダウンロードを行うファイル名のリンクがクリックされると、APサーバ10に対してダウンロード要求を送信する。すると、APサーバ10は、Web利用者端末の利用者により選択されたファイルの受領を「済」に更新する。そして、APサーバ10は、ブラウザ上でWeb利用者端末に対してダウンロード用画面を表示し、ダウンロード要求を受け付ける。
その後、APサーバ10は、利用者による「ダウンロード画面」のダウンロード開始ボタンがクリックされて、ダウンロード要求を受け付けると、コンテナファイルアクセス数をインクリメントする。また、APサーバ10は、受信者の秘密鍵を使用して共通鍵を復号化し、復号化した共通鍵を用いて、読み込み対象ファイルを復号化して、ネットワークへの書き込みを開始する。
ネットワークへの書き込みが終了すると、APサーバ10は、ダウンロードフラグをダウンロード「済」に更新し、コンテナファイルのアクセス数をデクリメントする。その後、APサーバ10は、コンテナの未ダウンロードファイル数から、当該コンテナがダウンロード完了かどうかを判断する。ここで、ダウンロード完了でない場合、APサーバ10は、処理を終了する。
当該コンテナがダウンロード完了である場合、APサーバ10は、受信側状態を「DOWNLOADED」に更新して、ダウンロードメール通知処理を行って、SSSサーバへ「DOWNLOADED」を通知し、「DOWNLOADED」の通知フラグを「通知済」に更新して、処理を終了する。
[実施例1による効果]
このように、実施例1によれば、SSSサーバから所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化し、復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、同一の受信者端末ごとにアーカイブ化されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するので、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することが可能である。
例えば、複数のファイルをアーカイブ化して1つのファイルにまとめることにより、多数のファイルが一度に送信されたWebブラウザを利用する受信者端末であっても、1回のダウンロードでファイルを受信することができる。
具体的に例を挙げると、図8に示すように、送信者AがWeb利用者端末の利用者Bに対してコンテナ1(ファイル1とファイル2)とコンテナ2(ファイル3とファイル4)とを送信した場合について説明する。この場合、APサーバ10は、これらのコンテナをSSSサーバを介して受信すると、これらのコンテナの受信者端末が利用者Bであることより、コンテナ1とコンテナ2とをアーカイブ化したZIPファイルを新たに作成する。そして、APサーバ10は、Web利用者端末(利用者B)から取得要求を受け付けると、作成した新たなZIPファイルを応答する。
また、図9に示すように、送信者AがWeb利用者端末の利用者Bに対してコンテナ1(ファイル1とファイル2)を送信し、同様に、送信者Bがコンテナ2(ファイル3とファイル4)をWeb利用者端末(利用者B)に送信した場合について説明する。この場合、APサーバ10は、これらのコンテナをSSSサーバを介して受信すると、これらのコンテナの送信者が異なっていても受信者端末が同じ利用者Bであることより、コンテナ1とコンテナ2とをアーカイブ化したZIPファイルを新たに作成する。そして、APサーバ10は、Web利用者端末(利用者B)から取得要求を受け付けると、作成した新たなZIPファイルを応答する。
このようにすることで、複数のファイルをアーカイブ化して1つのファイルにまとめることにより、多数のファイルが一度に送信されたWebブラウザを利用する受信者端末であっても、1回のダウンロードでファイルを受信することができる。また、本実施例では、APサーバ10は、コンテナをSSSサーバから受信して、コンテナごとに同じ受信者端末にアーカイブ化する場合について説明したが、本発明はこれに限定されるものではなく、1ファイルごとにSSSサーバから受信して同じ受信者端末にアーカイブ化することもできる。
また、実施例1によれば、生成されたアーカイブファイルを暗号化して、所定の記憶部に格納し、暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するので、セキュリティを高くファイル転送を行うことが可能である。
例えば、従来行われていたように、APサーバは、SSSサーバから受信したファイルを平文のまま一度保存し、その後に、受信者端末の要求に応じて、平文で保存するファイルを応答する場合に比べて、アーカイブ化されたアーカイブファイルを暗号化して保存し、受信者端末の要求に応じて、暗号化されたアーカイブファイルを復号化して受信者端末に応答することができる結果、APサーバ自体の盗難、サーバへの不正侵入に対しても、機密情報を守ることができる。
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下に示すように、(1)ダウンロード手法、(2)サーバ構成、(3)システム構成等、(4)プログラムにそれぞれ区分けして異なる実施例を説明する。
(1)ダウンロード手法
例えば、実施例1では、APサーバは、SSSサーバから一度コンテナを受信して、アーカイブ化した後に再度暗号化して記憶しておき、利用者端末からの要求に応じて、自装置に記憶するアーカイブファイルを応答する場合を説明したが、本発明はこれに限定されるものではなく、APサーバは、利用者端末からの要求に応じて、SSSサーバからファイルを取得してアーカイブ化して応答するようなリアルタイム復号送信を行うようにしてもよい。
このようにすることで、受信者端末からファイルの取得要求を受信した場合に、当該要求に対応するファイルをファイルサーバ装置から取得して復号化し、復号化されたファイルを同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、当該受信者端末に応答するので、リアルタイムに復号しながら、ファイルを転送することができる結果、機密情報を強固に守ることができる。
(2)サーバ構成
また、実施例1では、APサーバとSSSサーバとから別の筺体である場合について説明したが、本発明はこれに限定されるものではなく、APサーバとSSSサーバとが同じ筺体である一つのサーバ装置であってもよく、実施例1で説明した処理を実施することができる。また、APサーバとSSSサーバとを、さらに細かい筺体に分けたとしても、実施例1で説明した処理を実施することができる。
(3)システム構成等
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理(例えば、コンテナ送信のバッチ処理など)の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理(例えば、利用者端末における利用者の操作によるファイル取得要求の送信など)の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。
また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合(例えば、チェックサム計算部とコンテナ解凍部とを統合するなど)して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、CPUおよび当該CPUにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
(4)プログラム
なお、本実施例で説明したファイル転送方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク(FD)、CD−ROM、MO、DVDなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。
以上のように、本発明に係るファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラムは、Webブラウザを利用するWeb利用者端末を収容するアプリケーションサーバ装置と、アプリケーションサーバ装置や他の利用者端末から送信された暗号化されたファイルを受信して格納するファイルサーバ装置とから構成されるファイル転送システムにおいて、ファイルを送受信することに有用であり、特に、専用アプリを持たないユーザ端末であっても、利便性よくファイルを送受信することに適する。
実施例1に係るファイル転送システムの概要と特徴を説明するための図である。 実施例1に係るファイル転送システムにおけるAPサーバの構成を示すブロック図である。 実施例1に係るAPサーバによるSSSサーバへのファイル送信処理の流れを示すフローチャートである。 実施例1に係るAPサーバによる受信者端末へのファイル応答処理の流れを示すフローチャートである。 実施例1に係るAPサーバからSSSサーバへのアップロードの流れを示すシーケンス図である。 実施例1に係るAPサーバにおけるSSSサーバからのコンテナ定期受信処理の流れを示すシーケンス図である。 実施例1に係るAPサーバからWeb利用者端末へのファイル送信処理の流れを示すシーケンス図である。 複数のコンテナを受信者端末ごとにアーカイブ化して応答する例を示す図である。 複数のコンテナを受信者端末ごとにアーカイブ化して応答する例を示す図である。 従来技術を説明するための図である。 従来技術を説明するための図である。 従来技術を説明するための図である。 従来技術を説明するための図である。
符号の説明
10 APサーバ
11 通信制御I/F部
12 ファイル受信部
13 送信用データDB
20 送信用構造化処理部
21 コンテナ生成部
22 暗号化部
23 チェックサム計算部
24 コンテナ送信部
31 コンテナ受信部
32 応答用データDB
33 アーカイブDB
40 応答用構造化処理部
41 復号化部
42 チェックサム計算部
43 コンテナ解凍部
44 アーカイブ処理部
45 再暗号化部
46 ファイル応答部

Claims (5)

  1. Webブラウザを利用するWeb利用者端末と、前記Web利用者端末を収容するアプリケーションサーバ装置と、ファイル転送用の専用アプリケーションがインストールされた専用利用者端末と、前記アプリケーションサーバ装置や前記専用利用者端末から受信した暗号化されたファイルを格納し、ファイルの転送サービスを提供するファイルサーバ装置とから構成されるファイル転送システムであって、
    前記アプリケーションサーバ装置は、
    前記ファイルを受信する受信者端末がWeb利用者端末である場合に、前記ファイルサーバ装置から所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化する復号化手段と、
    前記復号化手段により復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成するアーカイブ処理手段と、
    前記アーカイブ処理手段により生成されたアーカイブファイルを暗号化して、所定の記憶部に格納する再暗号化手段と、
    前記再暗号化手段により暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を前記受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するファイル応答手段と、
    を備え、
    前記ファイルサーバ装置は、
    前記ファイルを受信する受信者端末が専用利用者端末である場合に、当該専用利用者端末に対して前記専用アプリケーションで要求された複数のファイルを同時に送信する送信手段、
    を備えたことを特徴とするファイル転送システム。
  2. 前記復号化手段は、前記受信者端末からファイルの取得要求を受信した場合に、当該要求に対応するファイルを前記ファイルサーバ装置から取得して復号化し、
    前記アーカイブ処理手段は、前記復号化手段により復号化されたファイルを同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成し、
    前記ファイル応答手段は、前記アーカイブ処理手段により同一の受信者端末ごとにアーカイブ化されたアーカイブファイルを、当該受信者端末に応答することを特徴とする請求項1に記載のファイル転送システム。
  3. 請求項1又は2に記載のファイル転送システムで用いられるアプリケーションサーバ装置。
  4. Webブラウザを利用するWeb利用者端末と、前記Web利用者端末を収容するアプリケーションサーバ装置と、ファイル転送用の専用アプリケーションがインストールされた専用利用者端末と、前記アプリケーションサーバ装置や他の利用者端末から送信された暗号化されたファイルを受信して格納し、ファイルの転送サービスを提供するファイルサーバ装置とから構成されるファイル転送システムに適したファイル転送方法であって、
    前記アプリケーションサーバ装置が、
    前記ファイルを受信する受信者端末がWeb利用者端末である場合に、前記ファイルサーバ装置から所定の間隔で暗号化されたファイルを受信し、受信したファイルを復号化する復号化工程と、
    前記復号化工程により復号されたファイルに対して、同一の受信者端末ごとに、当該ファイルをアーカイブ化してアーカイブファイルを生成するアーカイブ処理工程と、
    前記アーカイブ処理工程により生成されたアーカイブファイルを暗号化して、所定の記憶部に格納する再暗号化工程と、
    前記再暗号化工程により暗号化されて所定の記憶部に格納されたアーカイブファイルの取得要求を前記受信者端末から受信した場合に、当該受信者端末に対応するアーカイブファイルを復号化して、当該受信者端末に応答するファイル応答工程と、
    を含み
    前記ファイルサーバ装置が、
    前記ファイルを受信する受信者端末が専用利用者端末である場合に、当該専用利用者端末に対して前記専用アプリケーションで要求された複数のファイルを同時に送信する送信工程、
    を含んだことを特徴とするファイル転送方法。
  5. 請求項3に記載のアプリケーションサーバ装置としてコンピュータに実行させるためのファイル転送プログラム。
JP2008016805A 2008-01-28 2008-01-28 ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム Active JP4648412B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2008016805A JP4648412B2 (ja) 2008-01-28 2008-01-28 ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2008016805A JP4648412B2 (ja) 2008-01-28 2008-01-28 ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム

Publications (2)

Publication Number Publication Date
JP2009176247A JP2009176247A (ja) 2009-08-06
JP4648412B2 true JP4648412B2 (ja) 2011-03-09

Family

ID=41031224

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008016805A Active JP4648412B2 (ja) 2008-01-28 2008-01-28 ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム

Country Status (1)

Country Link
JP (1) JP4648412B2 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5565857B2 (ja) * 2010-04-02 2014-08-06 株式会社明電舎 電子ファイル管理システムおよび管理方法
JP2014174721A (ja) * 2013-03-08 2014-09-22 Genetec Corp 情報共有システム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002123496A (ja) * 2000-10-17 2002-04-26 Sony Corp コンテンツ受信装置及びコンテンツ受信方法、記憶媒体、並びにサーバ
JP2002342593A (ja) * 2001-05-16 2002-11-29 Nippon Yunishisu Kk データ交換装置、データ交換方法及びデータ交換プログラム
JP2003530746A (ja) * 2000-04-10 2003-10-14 ハネウェル・インターナショナル・インコーポレーテッド 機内電子メール・システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003530746A (ja) * 2000-04-10 2003-10-14 ハネウェル・インターナショナル・インコーポレーテッド 機内電子メール・システム
JP2002123496A (ja) * 2000-10-17 2002-04-26 Sony Corp コンテンツ受信装置及びコンテンツ受信方法、記憶媒体、並びにサーバ
JP2002342593A (ja) * 2001-05-16 2002-11-29 Nippon Yunishisu Kk データ交換装置、データ交換方法及びデータ交換プログラム

Also Published As

Publication number Publication date
JP2009176247A (ja) 2009-08-06

Similar Documents

Publication Publication Date Title
US20130283060A1 (en) Seamless Remote Synchronization and Sharing of Uniformly Encrypted Data for Diverse Platforms and Devices
US9686243B1 (en) Encrypted universal resource identifier (URI) based messaging
US9137225B2 (en) Seamless remote storage of uniformly encrypted data for diverse platforms and devices
CN1522516B (zh) 多内容电子邮件的安全标题信息
JP4148979B2 (ja) 電子メールシステム、電子メール中継装置、電子メール中継方法及び電子メール中継プログラム
KR100667820B1 (ko) 보안 방법 및 시스템, 그 방법을 기록한 컴퓨터 판독가능한 기록매체
US10020940B2 (en) Identity-based encryption for securing access to stored messages
JP2013235465A (ja) ファイル処理システム
JP2001237872A (ja) メール装置
JP2007281622A (ja) 電子メールシステム、電子メール中継装置、電子メール中継方法及び電子メール中継プログラム
JPWO2016132547A1 (ja) データ保管装置及びデータ更新システム及びデータ処理方法及びデータ処理プログラム
CN1783853B (zh) 密码邮件服务器设备
JP2007142504A (ja) 情報処理システム
GB2423679A (en) E-mail server with encryption / decryption and signing / verification capability
TW201317823A (zh) 一種雲端安全儲存系統
JP4648412B2 (ja) ファイル転送システム、アプリケーションサーバ装置、ファイル転送方法およびファイル転送プログラム
JP5185176B2 (ja) ドキュメント提供装置,方法,およびプログラム
JP2014086835A (ja) 情報処理装置、情報処理システム、情報処理方法、プログラム
JP2007128131A (ja) サーバ、ファイル転送方法およびファイル転送プログラム
JP2009104327A (ja) ファイル管理システム及びファイル管理プログラム
JP5162396B2 (ja) ストレージサービスシステム及びファイル保護プログラム
CN110611674B (zh) 不同计算机系统之间的协议交互方法、系统及存储介质
JP6216673B2 (ja) データ管理方法及びデータ管理システム
JP7014994B2 (ja) メール監視装置およびメール監視プログラム
JP2011193319A (ja) ファイル転送システム、ファイル転送方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20100621

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20100831

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20101029

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20101207

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20101209

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131217

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4648412

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350