(57)【要約】【課題】使い勝手の良いデータ送信サービスを実現可能とする。【解決手段】システムのドメイン名とは異なるドメイン名を記憶しておき、送信元から受け取ったデータをこのドメイン名に属するＵＲＬに対応付けて記憶する。また、そのＵＲＬを送信元または送信先に通知する。ＵＲＬに用いたドメイン名がデータ送信システムのＩＰアドレスに対応付けられていることに起因して、そのＵＲＬに基づくリクエストが到達すると、リクエストを受信してデータをリクエストの送信先に送信する。こうすれば、システムのドメイン名とは異なるドメイン名に属するＵＲＬを用いることができるので、送信相手に信頼される適切なドメイン名をＵＲＬに用いることが可能となる。その結果、ＵＲＬのドメイン名に起因して送信相手がデータの取得を躊躇してしまう虞が少ない使い勝手のよいデータ送信サービスを実現することが可能となる。【選択図】図１０
2012063891.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続され、該インターネットを介して送信元から受け取ったデータを、該インターネットを介して送信先に送信するデータ送信システムであって、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶手段と、
前記送信元から受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶手段と、
前記対応付けられたＵＲＬを前記送信元または前記送信先に通知するＵＲＬ通知手段と、
前記異なるドメイン名と前記ＩＰアドレスとが予め対応付けられていることに起因して前記ＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信手段と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信手段と
を備えるデータ送信システム。
【請求項２】
請求項１に記載のデータ送信システムであって、
前記データの送信の完了を検出すると、該データを消去するデータ消去手段と、
前記ＵＲＬに基づくリクエストの送信元から文字列を受信し、該文字列を前記ＵＲＬに対応付けて記憶する文字列記憶手段と、
前記文字列記憶手段により文字列が受信されたことを条件として、前記データ消去手段によるデータの消去を停止するデータ消去停止手段と、
前記文字列が対応付けられた前記ＵＲＬに基づく新たなリクエストを受信すると、該リクエストの送信元から文字列を受信するとともに、該受信した文字列と、該ＵＲＬに対応付けて記憶した該文字列をと照合する文字列照合手段と
を備え、
前記データ送信手段は、前記新たなリクエストを受信すると、前記文字列照合手段による照合が合致することを条件として、前記データを送信する手段であるデータ送信システム
【請求項３】
請求項１に記載のデータ送信システムであって、
前記データ記憶手段は、前記送信元から受け取ったデータを暗号化するとともに、該暗号化されたデータを記憶する手段であり、
前記データ送信手段は、前記暗号化されたデータを復号するとともに、該復号されたデータを送信する手段であり、
前記暗号化の完了を検出すると、前記送信元から受け取った該暗号化前のデータを消去する未暗号化データ消去手段と、
前記送信の完了を検出すると、前記復号されたデータを消去する復号済データ消去手段と
を備えるデータ送信システム。
【請求項４】
請求項３に記載のデータ送信システムであって、
前記データ記憶手段は、暗号キーを用いて前記暗号化を行う手段であり、
前記暗号化されたデータを復号可能な復号キーを取得するとともに、該復号キーを暗号化した状態で記憶する復号キー記憶手段と、
前記ＵＲＬに基づくリクエストを受信すると、前記復号キーと照合する照合キーを該リクエストの送信元から受信する照合キー受信手段と、
前記受信した照合キーを暗号化するとともに、該暗号化した状態の照合キーと、前記暗号化した状態で記憶した復号キーとを照合する復号キー照合手段と
を備え、
前記データ送信手段は、前記照合が合致すると、前記照合キーを用いて、前記暗号化されたデータを復号する手段であるデータ送信システム。
【請求項５】
請求項３または請求項４に記載のデータ送信システムであって、
前記データの送信の完了を検出すると、前記暗号化された前記データを消去するデータ消去手段を備え、
前記ＵＲＬに基づくリクエストの送信元から文字列を受信する文字列受信手段と、
前記文字列受信手段により受信された文字列を暗号化するとともに、該暗号化された文字列を前記ＵＲＬに対応付けて記憶する文字列記憶手段と、
前記文字列受信手段により文字列が受信されたことを条件として、前記データ消去手段によるデータの消去を停止するデータ消去停止手段と、
前記文字列が対応付けられた前記ＵＲＬに基づく新たなリクエストを受信すると、該リクエストの送信元から文字列を受信して該文字列を暗号化し、該暗号化された状態の文字列と、該ＵＲＬに対応付けて記憶された文字列をと照合する文字列照合手段と
を備え、
前記データ送信手段は、前記新たなリクエストを受信すると、前記文字列照合手段による照合が合致することを条件として、前記復号されたデータを送信する手段であるデータ送信システム。
【請求項６】
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたサーバー装置を用いて、インターネットを介して送信元から受け取ったデータを、インターネットを介して送信先に送信するサービスを提供するデータ送信サービス提供方法あって、
前記ドメイン名とは異なる複数のドメイン名を記憶しておくドメイン名記憶工程と、
前記異なるドメイン名と前記ＩＰアドレスとを対応付けたＤＮＳレコードを、前記インターネットに接続されたＤＮＳサーバーに設定するＤＮＳレコード設定工程と、
前記ユーザーから受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶工程と、
前記送信先に関する情報たる送信先情報を受信する送信先情報受信工程と、
前記送信先情報に基づいて、前記対応付けられたＵＲＬを前記送信先または前記送信元に通知するＵＲＬ通知工程と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信工程と
を備えるデータ送信サービス提供方法。
【請求項７】
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたコンピューターを用いて、該インターネットを介して送信元から受け取ったデータを、該インターネットを介して送信先に送信するデータ送信方法を実現するためのプログラムであって、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶機能と、
前記送信元から受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶機能と、
前記対応付けられたＵＲＬを前記送信先または前記送信元に通知するＵＲＬ通知機能と、
前記異なるドメイン名と前記ＩＰアドレスとが予め対応付けられていることに起因して前記ＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信機能と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信機能と
をコンピューターを用いて実現させるプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ネットワーク回線を介してデータを送信する技術に関する。
【背景技術】
【０００２】
コンピューター関連技術の進歩により、今日では、ネットワーク回線に接続されたコンピューターの間でデータを簡便に送受信することが可能となっている。たとえば、いわゆる電子メールを用いれば、文章データを簡単に送信したり、あるいは、電子メールに各種のデータファイルを添付して送信することが可能である（例えば、特許文献１）。また、こうしたネットワーク回線に誰でも簡単に接続できるようになってきたことに伴い、ネットワーク回線上に置いたサーバー装置を用いてユーザーに各種のサービスを提供するアプリケーションサービスも普及しつつある。
【０００３】
こうしたアプリケーションサービスの一態様として、サーバー装置を介してデータファイルを相手に送付可能とするサービスが展開されている。このサービスでは、データファイルの送信元からサーバー装置にデータファイルを預かり、送信先の相手にサーバー装置からデータファイルをダウンロードさせることにより、送信元から送信先にデータファイルを送付する。こうすることにより、電子メールでは送信できないような大容量のデータファイルであっても送信先に届けることが可能となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−１２５８５０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、こうした送信相手にデータファイルをダウンロードさせるアプリケーションサービスは、十分に使い勝手が良いものではないという問題があった。例えば、データファイルの送信先の相手が、コンピューターウィルスが流入するのを危惧してダウンロードの実行を躊躇してしまったり、あるいは、送信相手がそうした理由からデータファイルをダウンロードしてくれないのではないかとの不安を送信者が覚えて、データファイルを送信するのをためらうことがあった。
【０００６】
この発明は、上述した課題を解決するためになされたものであり、データファイルを送信するアプリケーションサービスの使い勝手を向上可能とする技術の提供を目的とする。
【課題を解決するための手段】
【０００７】
上述した課題の少なくとも一部を解決するために、本発明のデータ送信システムは次の構成を採用した。すなわち、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続され、該インターネットを介して送信元から受け取ったデータを、該インターネットを介して送信先に送信するデータ送信システムであって、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶手段と、
前記送信元から受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶手段と、
前記対応付けられたＵＲＬを前記送信元または前記送信先に通知するＵＲＬ通知手段と、
前記異なるドメイン名と前記ＩＰアドレスとが予め対応付けられていることに起因して前記ＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信手段と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信手段と
を備えることを要旨とする。
【０００８】
かかる本発明のデータ送信システムでは、システムのドメイン名とは異なるドメイン名を記憶しており、送信元からデータを受け取ると、受け取ったデータをこのドメイン名に属するＵＲＬに対応付けた状態で記憶する。また、データを対応付けたＵＲＬを送信元または送信先に通知する。そして、ＵＲＬに用いたドメイン名がデータ送信システムのＩＰアドレスに対応付けられていることに起因して、そのＵＲＬに基づくリクエストが到達すると、そのリクエストを受信するとともに、記憶していたデータをリクエストの送信元に送信する。
【０００９】
本発明では、ＵＲＬに用いられているドメイン名が、データ送信システムのドメイン名と異なるドメイン名であっても、そのＵＲＬに基づくリクエストがデータ送信システムに送られてきた際には、そのリクエストを受信する。例えば、インターネット上に設置されたＤＮＳサーバーによってそのドメイン名がデータ送信システムのＩＰアドレスに対応付けられていると、こうしたリクエストが送信されてくるので、これを受信する。こうすると、データ送信システムのドメイン名とは異なるドメイン名に属するＵＲＬを用いた場合であっても、データ送信システムにリクエストを送信してデータ送信システムからデータを取得することが可能となる。したがって、送信相手に信頼される適切なドメイン名をＵＲＬに用いることが可能となる。こうしたＵＲＬを用いて送信相手にデータ送信システムからデータを取得させれば、ＵＲＬのドメイン名に起因して送信相手が不安を抱いてしまう虞を回避することができる。これにより、送信相手がデータの取得を躊躇してしまう虞が少ない使い勝手のよいデータ送信システムを実現することが可能となる。
【００１０】
なお、本発明において「ドメイン名に属するＵＲＬ」とは、そのドメイン下のリソースを指し示すＵＲＬのことを意味する。たとえば、ＵＲＬ「ｈｔｔｐ：／／〇〇〇／□□□」（「〇〇〇」「□□□」はそれぞれ任意の文字列を意味する）は、ドメイン「〇〇〇」下のリソース「□□□」を指し示しているので、ドメイン名「〇〇〇」に属するＵＲＬに該当する。
【００１１】
また、本発明において「異なるドメイン名」とは、いわゆるトップレベルドメインが異なるドメイン名に限るものではなく、対比する２つのドメイン名のいずれもが、他方のドメイン名が有さない文字列を有していれば良い。例えば、ドメイン名「〇〇〇．△△△」とドメイン名「□□□．△△△」とは、何れもトップレベルドメインが「△△△」であってトップレベルドメインは共通しているが、ドメイン名「〇〇〇．△△△」は他方のドメイン名「□□□．△△△」にはない文字列「〇〇〇」を含んでおり、かつ、ドメイン名「□□□．△△△」は他方のドメイン名「〇〇〇．△△△」にはない文字列「□□□」を含んでいるので、これら２つのドメイン名（「〇〇〇．△△△」「□□□．△△△」）は異なるドメイン名に該当する。
【００１２】
また、ＵＲＬを通知する先は、データの送信元と送信先とのいずれでもよい。ＵＲＬをデータの送信先に通知した場合には、送信先はそのＵＲＬに基づいてデータ送信システムにリクエストを送信することが可能となる。一方、ＵＲＬをデータの送信元に通知した場合には、送信元がそのＵＲＬをデータの送信先に通知することにより、データの送信先はそのＵＲＬを使ってデータ送信システムにリクエストを送信することが可能となる。
【００１３】
ここで、ＵＲＬを送信先に通知する場合には、次のような構成を採用することも可能である。すなわち、
前記送信先に関する情報たる送信先情報を前記送信元から受信する送信先情報受信手段を備え、
前記ＵＲＬ通知手段は、前記送信先情報に基づいて、前記対応付けられたＵＲＬを前記送信先に通知する手段であるデータ送信システム。
【００１４】
こうすれば、データの送信先の情報を送信元から取得することができるので、送信先の情報を予め取得しておかなくても（例えば、送信先が自己の情報をデータ送信システムに予め登録しておかなくても）、送信先にデータを送信することが可能となって好適である。
【００１５】
また、上述した本発明のデータ送信システムでは、次の構成を採用するものとしてもよい。すなわち、
前記ドメイン名記憶手段は、複数のドメイン名を記憶しておく手段であり、
前記複数のドメイン名の中から一のドメイン名を選択するドメイン名選択手段を備え、
前記データ記憶手段は、前記送信元から受け取った前記データを、前記選択されたドメイン名に属するＵＲＬに対応付けた状態で記憶する手段であるデータ送信システム。
【００１６】
本発明のデータ送信システムを用いて複数のユーザーにサービスを提供する場合、ＵＲＬに使用したいドメイン名がユーザーごとに異なる場合がある。そこで、複数のドメイン名を記憶しておき、その中からドメイン名を選択してＵＲＬに用いるものとすれば、こうした場合であっても適切なドメイン名のＵＲＬを用いることが可能となる。その結果、複数のユーザーにサービスを提供する場合であっても、送信相手がデータを取得するのを躊躇してしまう虞を回避することが可能となる。また、複数のドメイン名を記憶しておくだけで複数のユーザーに対応可能なので、複数のユーザーに対してもサービスを容易に提供することが可能となる。また、ユーザーを追加する場合であっても、ドメイン名を記憶するだけでよいので、容易に対応することが可能となる。
【００１７】
また、上述した本発明のデータ送信システムでは、データの送信が完了するとデータを消去するものとしてもよい。もっとも、リクエストの送信元から文字列を受け取った場合には、データの送信が完了してもデータを消去しないでおく。そして、再びリクエストを受信した際には、リクエストの送信元から文字列を受信するとともに、その文字列を、先に記憶していた文字列と照合して、照合が合致した場合にデータを送信する。
【００１８】
送信相手がデータを取得した後にデータを消去するものとしておけば、その後に他の者がデータ送信システム上からデータを取得してしまう事態を回避することができるので、データの機密性をより向上させることが可能となる。ここで、送信相手から文字列を受信した場合には、データを送信した後もデータ送信システムからデータを消去しないでおく。こうすると、送信相手はデータを一度取得した後も再びデータを取得することが可能となるので、データ送信システムの利便性を向上させることが可能となる。また、データを再び取得する際には先の文字列と合致する文字列が必要なものとしておけば、データ送信システム上からデータが消去されない場合であっても、データの機密性が低下してしまう事態を回避可能である。これにより、データの機密性を保ちながらも、データを複数回にわたって取得可能としてデータ送信システムの利便性を向上させることが可能となる。
【００１９】
加えて、こうした場合には、万が一、送信先以外の者にデータを取得されてしまった場合には、そのことを検知することができることから、利用者の安心感をより高めることが可能となる。すなわち、送信相手よりも先に他者がデータを取得した場合、その他者が文字列を送信せずにデータを取得すれば、データが消去される。したがって、データが消去されていることに基づいて、送信相手はデータを他者に取得されたことを認識できる。一方、他者が文字列を送信してデータを取得した場合には、送信相手はその文字列を送信しなければデータを取得することができない。したがって、この場合には、データを取得できないことに基づいて、他者にデータを取得されたことを認識可能である。
【００２０】
このことを逆に捉えれば、送信相手がデータを取得できた場合には、他者がデータを取得していないことを意味する。このため、送信相手は、データを取得した際にはデータの機密性が保たれていることを確信することが可能である。このように、データを消去することや文字列を記憶することによって、データが取得されたか否かを判断することも可能となり、その結果、利用者により安心感を与えることが可能となる。これにより、より使い勝手の良いデータ送信システムが実現可能となる。
【００２１】
なお、データを消去する際には、結果的にデータが消去されるのであれば、どのような態様でデータを消去してもよい。例えば、データ全体を送信し終わってからデータを消去するものとしてもよいし、あるいは、データの送信が完了した部分ごとに順次消去するものとしてもよい。
【００２２】
また、上述した本発明のデータ送信システムでは、送信元から受け取ったデータを暗号化した状態で記憶し、データを送信する際には、暗号化したデータを復号して送信するものとしてもよい。このとき、暗号化の完了を検出すると暗号化前のデータを消去するものとし、また、データの送信の完了を検出すると、復号されたデータを消去するものとしてもよい。
【００２３】
こうすれば、復号された状態のデータがデータ送信システム上に記憶されることがないので、データに記載された情報をデータ送信システムから取得されてしまう虞を回避することが可能となる。こうして送信するデータの機密性を高めることにより、ユーザーはより安心してデータを送信することができるので、データ送信システムの使いやすさをより向上させることが可能となる。
【００２４】
また、上述した本発明のデータ送信システムでは、暗号化したデータを復号するための復号キーを暗号化した状態で記憶しておくものとしてもよい。また、リクエストの送信元から照合キーを受信すると、受信した照合キーを暗号化した上で、先に暗号化した状態で記憶していた復号キーと暗号化した照合キーとを照合する。そして、照合が合致した場合には、リクエストの送信元から受信した照合キーを用いて、データを復号するものとしてもよい。
【００２５】
暗号化された状態の復号キーと、暗号化された状態の照合キーとが合致することは、暗号化前の復号キーと、暗号化前の照合キーとが一致することを意味する。したがって、こうすれば、暗号化されたデータを復号できる正しい復号キーを送信してきた相手にのみ、復号されたデータを送信することができるので、データの機密性をより向上させることが可能となる。
【００２６】
なお、復号キーを暗号化する際には、その復号キー自身を暗号キーに用いて暗号化を行い、照合キーを暗号化する際には、その照合キー自身を暗号キーに用いて暗号化を行ってもよい。こうすれば、復号キーや照合キーを暗号化するための暗号キーを別途用意しておかなくてもよいので、より好適である。
【００２７】
また、上述した本発明のデータ送信システムでは、リクエストの送信元から文字列を受け取った場合には、データの送信が完了してもデータを消去しないものとしてもよい。このとき、文字列を暗号化した状態で記憶しておく。そして、再びリクエストを受信した際には、リクエストの送信元から文字列を受信するとともにその文字列を暗号化し、暗号化された状態の文字列を、先に記憶していた文字列（暗号化された状態の文字列）と照合して、照合が合致した場合にデータを送信する。
【００２８】
こうすると、送信相手はデータを取得する際に文字列を送信しておけば、データを取得した後もデータ送信システムからデータが消去されないので、その後もデータを取得することが可能となる。また、データを取得した後にデータ送信システム上からデータが消去されないものの、文字列を入力しなければ、そのデータを再び取得することはできないので、データの機密性が低下してしまう事態を回避可能である。これにより、データの機密性を保ちながらも、データを複数回にわたって取得可能としてデータ送信システムの利便性を向上させることが可能となる。加えて、データを再度取得する際に必要となる文字列を暗号化した状態で記憶しておけば、その文字列を他者に取得されてしまう虞を回避することも可能となる。
【００２９】
また、こうした場合も、万が一、送信先以外の者にデータを取得されてしまった場合には、そのことを検知することができることから、利用者の安心感をより高めることが可能となる。すなわち、送信相手よりも先に他者がデータを取得した場合、その他者が文字列を送信せずにデータを取得すれば、データが消去される。したがって、データが消去されていることに基づいて、送信相手はデータを他者に取得されたことを認識できる。一方、他者が文字列を送信してデータを取得した場合には、送信相手はその文字列を送信しなければデータを取得することができない。したがって、この場合には、データを取得できないことに基づいて、他者にデータを取得されたことを認識可能である。
【００３０】
そして、前述したように、このことを逆に捉えれば、送信相手がデータを取得できた場合には、他者がデータを取得していないことを意味する。このため、送信相手は、データを取得した際にはデータの機密性が保たれていることを確信することが可能である。このように、データを消去することや文字列を記憶することによって、データが取得されたか否かを判断することも可能となり、その結果、利用者により安心感を与えることが可能となる。これにより、より使い勝手の良いデータ送信システムが実現可能となる。
【００３１】
なお、暗号化されたデータを消去する際には、暗号化されたデータが結果的に消去されるのであれば、どのような態様で消去してもよい。例えば、データ全体を送信し終わってからデータを消去するものとしてもよいし、あるいは、データの送信が完了した部分ごとに順次消去するものとしてもよい。
【００３２】
また、上述した本発明は、データの送信を行うことに鑑みると次のようなデータ送信方法として把握することも可能である。すなわち、本発明のデータ送信方法は、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたサーバー装置を用いて、該インターネットを介して送信元から受け取ったデータを、該インターネットを介して送信先に送信するデータ送信方法であって、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶工程と、
前記送信元から受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶工程と、
前記対応付けられたＵＲＬを前記送信元または前記送信先に通知するＵＲＬ通知工程と、
前記異なるドメイン名と前記ＩＰアドレスとが予め対応付けられていることに起因して前記ＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信工程と、
前記ＵＲＬに基づく前記リクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信工程と
を備えることを要旨とする。
【００３３】
更に本発明は、上述したデータ送信方法を実現するためのプログラムをコンピューターに読み込ませ、所定の機能を実行させることにより、コンピューターを用いて実現することも可能である。従って、本発明は次のようなプログラム、あるいは該プログラムを記録した記録媒体としての態様も含んでいる。すなわち、上述したデータ送信方法に対応する本発明のプログラムは、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたコンピューターを用いて、該インターネットを介して送信元から受け取ったデータを、該インターネットを介して送信先に送信するデータ送信方法を実現するためのプログラムであって、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶機能と、
前記送信元から受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶機能と、
前記対応付けられたＵＲＬを前記送信先または前記送信元に通知するＵＲＬ通知機能と、
前記異なるドメイン名と前記ＩＰアドレスとが予め対応付けられていることに起因して前記ＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信機能と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信機能と
をコンピューターを用いて実現することを要旨とする。
【００３４】
こうしたプログラムをコンピューターに読み込ませて各機能を発揮させれば、上述したように、使い勝手のよいデータ送信システムを実現することが可能となる。
【００３５】
更に、本発明を用いれば、使い勝手のよいデータ送信サービスを実現可能なことから、次のようなデータ送信サービス方法として把握することも可能である。すなわち、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたサーバー装置を用いて、インターネットを介して送信元から受け取ったデータを、インターネットを介して送信先に送信するサービスを提供するデータ送信サービス提供方法あって、
前記ドメイン名とは異なる複数のドメイン名を記憶しておくドメイン名記憶工程と、
前記異なるドメイン名と前記ＩＰアドレスとを対応付けたＤＮＳレコードを、前記インターネットに接続されたＤＮＳサーバーに設定するＤＮＳレコード設定工程と、
前記ユーザーから受け取ったデータを、前記異なるドメイン名に属するＵＲＬに対応付けた状態で記憶するデータ記憶工程と、
前記対応付けられたＵＲＬを前記送信先または前記送信元に通知するＵＲＬ通知工程と、
前記ＵＲＬに基づくリクエストを受信すると、該ＵＲＬに対応付けて記憶した前記データを、該リクエストの送信元に送信するデータ送信工程と
を備えることを要旨とする。
【００３６】
こうした本発明の方法を用いれば、上述した理由から、使い勝手のよいサービスを提供することが可能となる。
【００３７】
なお、前述したように、ＵＲＬを通知する先は、データの送信元と送信先とのいずれでもよい。また、ＵＲＬを送信先に通知する場合には、次の構成を採用することも可能である。すなわち、
前記送信先に関する情報たる送信先情報を前記送信元から受信する送信先情報受信工程を備え、
前記ＵＲＬ通知工程は、前記送信先情報に基づいて、前記ＵＲＬを前記送信先に通知する手段であるデータ送信システム。
【００３８】
こうすれば、データの送信先の情報を送信元から取得することができるので、送信先の情報を予め取得しておかなくても送信先にデータを送信することが可能となるので、好適である。
【図面の簡単な説明】
【００３９】
【図１】本実施例のデータファイル送信システムの構成を示した説明図である。
【図２】本実施例のデータファイル送信システム１００が実行するデータファイル受信処理の流れを示した説明図である。
【図３】ユーザーＩＤおよびパスワードをユーザーが入力しそれらをデータファイル送信システム１００が受信する様子を示した説明図である。
【図４】送信するデータファイルおよび送信先のメールアドレスとデータファイルを暗号化する際に用いる暗号キーとをユーザーから受信する様子を示した説明図である。
【図５】ユーザーＩＤとドメイン名とが対応付けられた対応テーブルを例示した説明図である。
【図６】データファイルのファイル名とＵＲＬとを対応付けた対応テーブルを例示した説明図である。
【図７】データファイルをダウンロードするためのＵＲＬ（ダウンロードＵＲＬ）が記載されたｅメールがデータファイルの送信先のユーザー（受信者）の端末８００に配信された様子を例示した説明図である。
【図８】ダウンロードＵＲＬに基づくリクエストをデータファイル送信システム１００が受信可能とするために用いられるＤＮＳレコードを例示した説明図である。
【図９】本実施例のデータファイル送信処理の流れを示した説明図である。
【図１０】データファイルの送信先のユーザー（受信者）から暗号キーを受信する様子を例示した説明図である。
【図１１】複数のドメイン名が使われる場合のＤＮＳレコードの設定例を示した説明図である。
【図１２】複数のＩＰアドレスの各々に各ドメイン名を対応付ける第１変形例のデータファイル送信システム１００に用いられるＤＮＳレコードを例示した説明図である。
【図１３】ダウンロードＵＲＬに用いるドメイン名をＩＰアドレスに直接対応付ける第２変形例のＤＮＳレコードを例示した説明図である。
【図１４】データファイルを複数回にわたってダウンロード可能とするために送信先のユーザーにロックキーを入力させる第３変形例のデータファイル送信システム１００を例示した説明図である。
【図１５】入力された暗号キーが正しいか否かを判断する仕組みを概念的に示した説明図である。
【図１６】ダウンロードキーに情報を保持させる様子を概念的に示した説明図である。
【図１７】送信元のユーザーがダウンロードＵＲＬに用いるドメイン名を用いてデータファイル送信システム１００にアクセスする様子を例示した説明図である。
【図１８】データファイルをダウンロードする際に表示される画面を送信元のユーザーが選択する様子を示した説明図である。
【図１９】送信元のユーザーが選択したダウンロードページが送信先のユーザーの端末８００に表示された様子を例示した説明図である。
【図２０】ダウンロードＵＲＬに用いるドメイン名の一部を送信元のユーザーが選択する様子を示した説明図である。
【図２１】ダウンロードＵＲＬに用いる各サブドメインをデータファイル送信システム１００のＩＰアドレスに対応付けたＤＮＳレコードを例示した説明図である。
【図２２】サーバー装置のドメイン名とは異なるドメイン名を用いてサービスを提供するアプリケーションサービスの構成を概念的に示した説明図である。
【発明を実施するための形態】
【００４０】
以下では、上述した本願発明の内容を明確にするために、次のような順序に従って実施例を説明する。
Ａ．システムの全体構成：
Ｂ．データファイル受信処理：
Ｃ．ダウンロードリクエストの受信方法：
Ｄ．データファイル送信処理：
Ｅ．変形例：
Ｅ−１．第１変形例：
Ｅ−２．第２変形例：
Ｅ−３．第３変形例：
Ｅ−４．第４変形例：
Ｅ−５．第５変形例：
Ｅ−６．第６変形例：
Ｅ−７．第７変形例：
Ｅ−８．第８変形例：
Ｅ−９．第９変形例：
Ｅ−１０．第１０変形例：
【００４１】
Ａ．システムの全体構成  ：
図１は、本実施例のデータファイル送信システムの構成を示した説明図である。図示されているように、データファイル送信システム１００は、ＣＰＵやＲＯＭやＲＡＭなどから構成されたサーバー装置１０２と、サーバー装置１０２に接続されたディスク装置１０４などから構成されている。
【００４２】
このデータファイル送信システム１００は、図示されているように、サーバー装置１０２のネットワークインターフェース回路（ＮＩＣ）を介してインターネット回線に接続されており、インターネット回線を介して外部のコンピューターと接続することが可能である。また、インターネット回線に接続された携帯電話の基地局や公衆無線ＬＡＮ基地局などの無線基地局を介して、携帯電話などの携帯式通信機器と接続することも可能である。
【００４３】
一般に、こうしたインターネットに接続されたコンピューターには、各コンピューターを識別するためのＩＰアドレスが割り当てられている。例えば、図１に示されている例では、本実施例のデータファイル送信システム１００のサーバー装置１０２に対して、ＩＰアドレス「２４ｘ．１５ｘ．４９ｘ．１」が割り当てられている。こうしたＩＰアドレスにより、インターネットに接続された各コンピューターが識別されるので、コンピューター同士が通信を行う際には、接続相手のＩＰアドレスを指定することによって目的のコンピューターと通信を行うことが可能となる。
【００４４】
また、ＩＰアドレスは単なる数字なので、ＩＰアドレスを見ただけでは、そのＩＰアドレスが割り当てられたコンピューター（ホスト）がどのようなコンピューターなのかを推測することは困難である（例えば、ＩＰアドレスを見ても、どの組織に所属するコンピューターなのかを推測することは困難である）。こうした点に鑑みて、ＩＰアドレスには名前を対応付けることが可能となっており、この名前は「ドメイン名」と呼ばれている。ドメイン名にはアルファベットや数字などを用いることができるので、コンピューターを所有する組織の名称などをドメイン名として用いることが可能である。こうすることにより、そのコンピューターを管理する組織をドメイン名に基づいて容易に知ることが可能となっている。
【００４５】
図１に示されているように、本実施例では、データファイル送信システム１００のサーバー装置１０２には、ドメイン名「〇〇〇.〇〇〇」が対応付けられている。こうしたドメイン名はインターネット上に設置されたドメイン・ネーム・サーバー（ＤＮＳサーバー）に記憶されており、ＤＮＳサーバーに問い合わせると、ドメイン名に対応付けられたＩＰアドレスを取得することができる。インターネットに接続された各コンピューターは、こうしてドメイン名に対応するＩＰアドレスを取得し、そのＩＰアドレスが対応付けられたコンピューターに接続することにより、目的のコンピューターと通信を行うことが可能となる。こうした仕組みにより、インターネットに接続された各コンピューターの間では、インターネットを介して互いにデータを受け渡しすることが可能となっている。
【００４６】
近年では、こうしたインターネット回線が広く普及しており、企業や官公庁、更には一般家庭においても、インターネット回線に接続できることが一般的になってきた。こうした状況にともなって、インターネット上に設置したサーバー装置を用いて各種の機能をインターネットを介してユーザーに提供するサービスが展開されるようになってきた。この種のサービスの一態様として、ユーザーからデータファイルを受け取ってサーバー装置に記憶し、そのデータファイルを、別の相手にサーバー装置からダウンロードさせることによって、ユーザーから別のユーザーへとデータファイルを確実に送信可能とするサービスが展開されている。
【００４７】
もっとも、こうしたデータファイル送信サービスでは、前述したように、データファイルの送付相手がデータファイルをダウンロードするのを躊躇してしまうことがあるなど、十分に使い勝手が良いものではなかった。そこで、本実施例のデータファイル送信システム１００では、以下の方法を用いることにより、より使い勝手の良いデータファイル送信サービスを実現可能としている。
【００４８】
Ｂ．データファイル受信処理  ：
図２は、本実施例のデータファイル送信システム１００が実行するデータファイル受信処理の流れを示した説明図である。かかる処理は、ユーザーがデータファイルを相手に送信すべく、インターネットを介して本実施例のデータファイル送信システム１００にアクセスすると、これを受けてデータファイル送信システム１００のサーバー装置１０２において実行される処理である。図示されているように、処理を開始すると、まず、ユーザーからユーザーＩＤとパスワードとを受信してユーザー認証を実行する処理を行う（ステップＳ１００）。
【００４９】
図３は、ユーザーＩＤおよびパスワードをユーザーが入力し、それらをデータファイル送信システム１００が受信する様子を示した説明図である。図示されているように、ユーザーはインターネットに接続されたコンピューター２００上でＷｅｂブラウザを起動し、本実施例のデータファイル送信システム１００のサーバー装置１０２にアクセスする。これを受けてデータファイル送信システム１００のサーバー装置１０２は、ユーザーＩＤおよびパスワードの入力を促す画面をコンピューター２００に送信する。ユーザーは表示画面２１０に表示される指示に従ってユーザーＩＤおよびパスワードを入力することにより、ユーザーＩＤおよびパスワードをデータファイル送信システム１００のサーバー装置１０２に送信する。なお、ユーザーＩＤは、ユーザーを識別できる情報であれば、どのような情報であってもよい。例えば、ユーザーの氏名であってもよいし、あるいは、社員番号や学生番号などのようにユーザーごとに割り振られた番号であってもよい。
【００５０】
一方、サーバー装置１０２には、データファイル送信システム１００の使用権限が与えられたユーザーのユーザーＩＤ及びパスワードを予め記憶しておく。そして、ユーザーから受信したユーザーＩＤ及びパスワードと、記憶しているユーザーＩＤ及びパスワードとを照合することにより、アクセスしてきたユーザーがデータファイル送信システム１００の使用権限が与えられたユーザーか否かを判断する。受信したユーザーＩＤ及びパスワードが、使用権限が与えられたユーザーのものでない場合には、ユーザーが認証されなかったことから、それ以上の処理は行わずにファイル受信処理を終了すればよい。こうすることにより、データファイル送信システム１００の使用料を支払うなどして使用権限が与えられたユーザーのみに、データファイル送信システム１００を使用させることが可能となる。
【００５１】
ユーザーＩＤおよびパスワードを受信して、利用権限が与えられたユーザーであることを確認したら、次いで、データファイルの送信相手のメールアドレスをユーザーから受信するとともに（図２：ステップＳ１０２）、送信相手に送信するデータファイルを受信する（ステップＳ１０４）。ここで、本実施例では、データファイルを送信可能とするだけでなく、データファイルに記憶されたデータを送信相手以外の者に知られてしまう虞を回避可能とするために（機密性を確保可能とするために）、データファイルを暗号化した状態でデータファイル送信システム１００のサーバー装置１０２に記録する。
【００５２】
一般に、こうした暗号化の際には、暗号キーと呼ばれる文字列（あるいはビット列）を用いて暗号化が行われる。この暗号キーには種々の文字列やビット列を用いることが可能であるが、本実施例では、ユーザーが決めた任意の文字列を暗号キーとして用いる。このことに対応して、本実施例のデータファイル受信処理では、送信相手のメールアドレスや送信するデータファイルに加えて、暗号キーに用いる文字列もユーザーから受信する（ステップＳ１０４）。
【００５３】
図４は、送信するデータファイルおよび送信先のメールアドレスと、データファイルを暗号化する際に用いる暗号キーとをユーザーから受信する様子を示した説明図である。図示されているように、サーバー装置１０２は、送信先のメールアドレスや送信するデータファイルや暗号キーなどの入力を促す画面を、インターネットを介してユーザーのコンピューター２００に送信する。これを受けてユーザーは、送信相手のメールアドレスや送信するデータファイルや暗号キーを入力する。図４に示されている例では、ファイル名が「ｄａｔａ１．ｄａｔ」であるデータファイルを送信するデータファイルに指定しており、また、このデータファイルを暗号化するための暗号キーに、文字列「ｐａｓｓ」を指定している。こうしてユーザーが送信相手のメールアドレスや送信するデータファイルや暗号キーを入力したら、サーバー装置１０２はインターネットを介してこれらを取得する。
【００５４】
送信相手のメールアドレスやデータファイルなどを受信したら（図２：ステップＳ１０２、ステップＳ１０４）、次いで、受信した暗号キーを用いてデータファイルを暗号化する処理を行う（ステップＳ１０６）。暗号化を行う際には各種の暗号アルゴリズムを用いることが可能であるが、本実施例では、暗号化の際に用いる暗号キーと、暗号化されたデータを復号する際に用いる暗号キーとが共通である共通鍵方式のアルゴリズムを用いて暗号化を行うものとする。一般に、こうした共通鍵暗号方式のアルゴリズムとしては各種のアルゴリズムが知られているが、いずれのアルゴリズムを用いてもよい。
【００５５】
データファイルを暗号化したら、暗号化前のデータファイルや暗号キーはもう必要ないので、サーバー装置１０２のＲＡＭやディスク装置１０４から消去する（ステップＳ１０８）。こうして暗号化前のデータファイルや暗号キーを消去してデータファイル送信システム１００上に残さないようにすれば、データファイルに記載された情報を送信先のユーザー以外の者に取得されてしまう虞を回避してデータファイルの機密性をより高めることができるので、より好適である。
【００５６】
データファイルおよび暗号キーを暗号化したら、次いで、後述する「データ送信処理」の際に用いるドメイン名を決定する処理を行う。なお、本実施例のデータファイル送信システム１００では、適切なドメインを用いて送付相手にデータを送信することにより、送信相手がデータファイルを受信するのを躊躇してしまう事態を回避してデータファイル送信システム１００の使い勝手を向上させている。この点については後で詳しく説明する。
【００５７】
ドメイン名を決定する際には、種々の方法を用いることが可能である。例えば、予め複数のドメイン名を記憶しておき、その中から使用するドメイン名をユーザーが選択するものとしてもよい。ドメイン名を決定する際にはどのような方法を用いてもよいが、本実施例では、次のような方法を用いるものとして説明する。すなわち、後述するようにユーザーは自己が所有するドメイン名や自己が所属する組織のドメイン名を使用することを望む傾向がある。したがって、使用するドメイン名はユーザーごとに予め定まっていると考えることが可能である。そこで、ユーザーＩＤとドメイン名とを予め対応付けて記憶しておき、ユーザーＩＤに対応付けられたドメイン名を用いるものとする。
【００５８】
図５は、ユーザーＩＤとドメイン名とが対応付けられた対応テーブルを例示した説明図である。図示されているように、対応テーブルには、各ユーザーのユーザーＩＤとドメイン名とが対応付けられている。こうした対応テーブルをサーバー装置１０２に予め記憶しておくことにより、ユーザーＩＤに基づいてドメイン名を容易に決定することが可能となる。なお、データファイル送信システム１００はインターネットに接続されていることから、こうした対応テーブルをサーバー装置１０２に記憶しておくのではなく、インターネットに接続された他のコンピューターに記憶しておき、インターネットを介してそのコンピューターから取得するものとしてもよい。もちろんインターネットに限らず、ＬＡＮ回線などの他の種類の回線を介して取得してもよい。また、図５の例では、ドメイン名の一部に文字列「ｘｘｘ」あるいは「ｙｙｙ」が用いられているが、この部分はどのような文字列を用いてもよい。
【００５９】
こうしてデータファイルを送信する際に用いるドメイン名を取得したら（図２：ステップＳ１１２）、先に暗号化したデータファイルを、取得したドメイン名に属するリソースを示すＵＲＬ（ＵＲＬの一部分にそのドメイン名を含むＵＲＬ）に対応付けた状態で記憶する（ステップＳ１１２）。
【００６０】
図６は、データファイルのファイル名とＵＲＬとを対応付けた対応テーブルを例示した説明図である。図示されているように、対応テーブルには、先に取得したドメイン名（図５および図６の例では「ｘｘｘ．△△△．△△△」）を有するＵＲＬと、データファイルのファイル名とが対応付けられている。また、このＵＲＬには、データファイルごとに異なる文字列を持たせておく（図中に「Ａ」と示された部分を参照）。こうすることにより、データファイルとＵＲＬとを対応付けておくことが可能となる。
【００６１】
ここで、この文字列はデータファイルを特定することが可能であれば、どのような文字列でもよいが、本実施例では、ランダムな文字列を生成して生成した文字列を用いるものとする。このようなランダムな文字列を用いれば、送付先のユーザー以外の者がデータファイルを取得してしまう虞をより確実に回避することが可能となる。この点については後で説明する。
【００６２】
暗号化したデータファイルを記憶する際には、こうした対応テーブルを生成することにより、データファイルとＵＲＬとを対応付けた状態にしておく。なお、後述するように本実施例のデータファイル送信システム１００では、データファイルの送信先のユーザーにこのＵＲＬを用いてデータファイルをダウンロードさせることから、本実施例では、このＵＲＬを「ダウンロードＵＲＬ」と呼ぶものとする。また、ダウンロードＵＲＬに付随させた文字列（図中に「Ａ」と示された部分を参照）を、「ダウンロードキー」と呼ぶものとする。
【００６３】
データファイルをダウンロードＵＲＬに対応付けて記憶したら（図２：ステップＳ１１２）、今度は、送付先のユーザーにデータファイルをダウンロードさせるべく、ダウンロードＵＲＬを記載したｅメールを、送付相手のメールアドレスに送付する（ステップＳ１１４）。ｅメールを送信する際にはどのような方法で送信してもよく、例えばデータファイル送信システム１００にメールサーバー機能を持たせておき、そのメールサーバー機能を用いてｅメールを送信してもよいし、あるいはデータファイル送信システム１００とは別のシステムを介して送信してもよい。
【００６４】
なお、ダウンロードＵＲＬは、送信先のユーザーに通知可能であれば、どのような方法で通知してもよい。例えば、ダウンロードＵＲＬを記載したｅメールを送信先のユーザーに送付するのではなく送信元のユーザーに送付するものとし、送信元のユーザーがそのダウンロードＵＲＬを送信先のユーザーに通知するものとしてもよい。こうした場合、送信元のユーザーは、送信先のｅメールアドレスをデータファイル送信システム１００に入力する際と（図２のステップＳ１０２を参照）、ダウンロードＵＲＬを相手に送付する際との２回にわたって、送信相手を確認する機会を持つことになる。このため、ユーザーが誤った相手にデータファイルを送信してしまうといったヒューマンエラーが生じる虞を低減することが可能となる。
【００６５】
図７は、データファイルをダウンロードするためのＵＲＬ（ダウンロードＵＲＬ）が記載されたｅメールが、データファイルの送信先のユーザー（受信者）の端末８００に配信された様子を例示した説明図である。受信者はこのｅメールに記載されているダウンロードＵＲＬを用いて、送信元のユーザーが送信したデータファイルをダウンロードする。
【００６６】
ここで、本実施例のデータファイル送信システム１００では、前述したようにダウンロードＵＲＬのドメイン名を、送信元のユーザーに応じて決定している。このドメイン名には、送信者の所属する会社などの組織のドメイン名や、あるいは送信者自身が所有するドメイン名などを用いることが可能である。すると、このドメイン名はデータファイル送信システム１００のドメイン名「○○○．○○○」とは異なるドメイン名であるから、通常では、このダウンロードＵＲＬを用いて、データファイルが記憶されたデータファイル送信システム１００にアクセスすることはできない（データファイル送信システム１００がダウンロードＵＲＬに基づくリクエストを受信することができない）。そこで本実施例では、データファイル送信システム１００のドメイン名とは異なるドメイン名のＵＲＬを使った場合であっても、データファイル送信システム１００がこのＵＲＬに基づくリクエストを受信可能とするために、次の方法を用いる。
【００６７】
Ｃ．ダウンロードリクエストの受信方法  ：
図８は、ダウンロードＵＲＬに基づくリクエストをデータファイル送信システム１００が受信可能とするために用いられるＤＮＳレコードを例示した説明図である。理解を容易にするために、まず、一般的なＤＮＳレコードについて説明する。図８（ａ）には、ドメイン名「△△△．△△△」に関連するＤＮＳレコードが示されている。図中に「Ｂ」と示された行（ＤＮＳレコード）には、ドメイン名「△△△．△△△」に対してＩＰアドレス「１３ｘ．２５ｘ．７６ｘ．１」が対応付けられている。このようにドメイン名（あるいはホスト名）とＩＰアドレスとの対応関係を記憶しておくのがＤＮＳレコードの基本的な役割である。こうしたＤＮＳレコードがインターネット上のＤＮＳサーバーに記憶されていることにより、ドメイン名からＩＰアドレスを取得することができ、そのＩＰアドレスに基づいて、目的のコンピューター（ホスト）に接続することが可能となる。例えば、Ｗｅｂブラウザの接続先ＵＲＬ欄に「△△△．△△△」と入力すると、ホスト「△△△．△△△」に対応付けられたＩＰアドレス（図８（ａ）に「Ｂ」と示されたＤＮＳレコードを参照）がインターネット上のＤＮＳサーバーから取得され、そのＩＰアドレスを有するコンピューター（ホスト）に接続することにより、ホスト「△△△．△△△」に接続することが可能となる。なお、このようにドメイン名とＩＰアドレスとを対応付けたＤＮＳレコードは「Ａレコード」と呼ばれる。
【００６８】
また、ＤＮＳサーバーには、「ＣＮＡＭＥレコード」と呼ばれるタイプのＤＮＳレコードを設定することも可能である。このＣＮＡＭＥレコードを設定すると、ホストに別名を付けることが可能である。例えば、図８（ａ）に「Ｃ」と示されたＤＮＳレコードでは、ホスト名「ｗｗｗ．△△△．△△△」」に対して「△△△．△△△」が対応付けられている。こうしたＤＮＳレコードをＤＮＳサーバーに設定しておくと、Ｗｅｂブラウザの接続先ＵＲＬ欄に「ｗｗｗ．△△△．△△△」と入力した場合には、ＤＮＳサーバーにより、まず「ｗｗｗ．△△△．△△△」は「△△△．△△△」の別名である旨が返答され、ついで「△△△．△△△」に対応するＩＰアドレスを再びＤＮＳサーバーに問い合わせることにより（図８（ａ）に「Ｂ」と示したＤＮＳレコードを参照）、ＩＰアドレス「１３ｘ．２５ｘ．７６ｘ．１」を取得することができる。その結果、ＷｅｂブラウザのＵＲＬに「ｗｗｗ．△△△．△△△」と入力した場合も、「△△△．△△△」と入力した場合と同じホストに接続することが可能となる。
【００６９】
ここで、本実施例では、ダウンロードＵＲＬに使用するドメイン（本実施例の例では「ｘｘｘ．△△△．△△△」（図７を参照）と、データファイル送信システム１００のドメイン名「○○○．○○○」（図１を参照）のサブドメイン名である「ｘｘｘ．○○○．○○○」とを対応付けたＣＮＡＭＥレコードを設定しておく（図８（ａ）に「Ｄ」と示されたＣＮＡＭＥレコードを参照）。こうすると、ダウンロードＵＲＬ「ｘｘｘ．△△△．△△△／ａｔ２ｘｇ３ｋ」に基づくリクエストに対して、ＤＮＳサーバーは「ｘｘｘ．△△△．△△△」は「ｚｚｚ．○○○．○○○」の別名である旨を返答し、その結果、今度はデータファイル送信システム１００のドメイン名である「○○○．○○○」に関連するＤＮＳレコードを、ＤＮＳサーバーに問い合わせることになる。なお、図８の例においてドメイン名の一部に文字列「ｚｚｚ」を用いているが、この部分にはどのような文字列を使用してもよい。
【００７０】
図８（ｂ）には、ドメイン名「○○○．○○○」に関連するＤＮＳレコードが示されている。前述したように、「ｚｚｚ．○○○．○○○」についての問い合わせが発生するので、この「ｚｚｚ．○○○．○○○」に関するリクエストをデータファイル送信システム１００が受信できるようにすべく、「ｚｚｚ．○○○．○○○」を「○○○．○○○」に対応付けたＣＮＡＭＥレコードをＤＮＳサーバーに設定しておく（図８（ｂ）に「Ｅ」と示されたＣＮＡＭＥレコードを参照）。こうすると、「ｘｘｘ．△△△．△△△」についての問い合わせは、最終的にデータファイル送信システム１００のドメイン名「○○○．○○○」についての問い合わせとなり、その結果、データファイル送信システム１００のＩＰアドレス「２４ｘ．１５ｘ．４９ｘ．１」が、送信先のユーザーの端末８００に返答される。これにより、ユーザーの端末８００はダウンロードＵＲＬに基づいてデータファイル送信システム１００にアクセスすることとなり、結果として、データファイル送信システム１００は、ダウンロードＵＲＬに基づく受信者からのリクエストを受信することが可能となる。
【００７１】
このように、本実施例のデータファイル送信システム１００では、ＤＮＳレコードを適切に設定しておくことにより、データファイル送信システム１００のドメイン名とは異なるドメイン名のＵＲＬに基づくリクエストであっても、データファイル送信システム１００が受信可能としている。こうしてダウンロードＵＲＬに基づくリクエスト（アクセス）をデータファイル送信システム１００が受信したら、次に説明するデータファイル送信処理を行って受信者にデータファイルを送信する。
【００７２】
Ｄ．データファイル送信処理  ：
図９は、本実施例のデータファイル送信処理の流れを示した説明図である。図示されているように、データファイル送信システム１００はダウンロードＵＲＬに基づくアクセスを受けると、まず、そのＵＲＬを取得してＵＲＬに対応付けられたデータファイルを特定する（ステップＳ２００）。一般に、インターネットに接続されたサーバー装置は、アクセスを受けた際にそのアクセスに用いられたＵＲＬを種々の方法で取得することが可能である。ここでは、いずれの方法を用いてもよい。こうしてダウンロードＵＲＬを取得すると、データファイル送信システム１００はデータファイルのファイル名とダウンロードＵＲＬとを対応付けて記憶していることから（図２のステップＳ１１４および図６を参照）、ダウンロードＵＲＬに基づいてデータファイルを特定することが可能となる。データファイルを特定したら、次いで、データファイルを復号するべく、復号に用いる暗号キーを受信する処理を行う（ステップＳ２０２）。
【００７３】
図１０は、データファイルの送信先のユーザー（受信者）から暗号キーを受信する様子を例示した説明図である。図示されているように、データファイル送信システム１００は暗号キーの入力を促す画面を受信者の端末８００に送信し、これを受けて、受信者が暗号キーを入力する。ここで、暗号キーは、送信元のユーザーから送信先のユーザーに予め通知しておく。例えば、送信元のユーザーと送信先のユーザーとの間で予め暗号キーを取り決めておいてもよいし、あるいは、送信元のユーザーがデータファイルをデータファイル送信システム１００に送信した後に、送信元のユーザーから送信先のユーザーに通知するものとしてもよい。送信先のユーザーが暗号キーを入力したら、データファイル送信システム１００は、インターネットを介して暗号キーを取得する。
【００７４】
暗号キーを取得したら、その暗号キーを用いて、先に暗号化したデータファイル（図２：ステップＳ１０６を参照）を復号すればよい。前述したように、本実施例では暗号化の際に用いる暗号キーと復号の際に用いる暗号キーとが同一である共通鍵暗号方式のアルゴリズムを用いているので、この暗号キーが、先に暗号化を行った際に用いた暗号キーと同じ暗号キーであれば、データファイルを正しく復号することが可能である。暗号キーは送信元のユーザーから通知を受けた送信先のユーザーしか知りえないので、こうすることにより、送信先のユーザー以外の者がデータファイルに記録された情報を取得してしまう虞を回避することが可能である。
【００７５】
暗号化されたデータファイルを復号したら（図９：ステップＳ２０４）、復号したデータファイルを送信先のユーザーの端末に送信すればよい（ステップＳ２０６）。こうしてデータファイルを送信した後は、暗号化されたデータファイルおよび暗号化された暗号キーを、データファイル送信システム１００のＲＡＭやディスク装置１０４などの記憶装置から消去する（ステップＳ２０８）。このように送信が完了したデータファイルや暗号キーをデータファイル送信システム１００から消去しておけば、データファイルや暗号キーが送付先のユーザー以外の者に取得されてしまう虞をより確実に回避することが可能となる。
【００７６】
なお、データファイルを復号する際や復号したデータファイルを送信する際には、どのような方法を用いてもよいが、次のような方法を用いるとより好適である。まず、暗号化したデータファイルをサーバー装置１０２のＲＡＭ上に読み込む。次いで、ＲＡＭ上でデータファイルを復号する。そして、復号して得られたデータを、バイナリデータとして送信先のユーザーの端末に送信する。こうすることにより、復号されたデータファイルがディスク装置１０４などの不揮発性の記憶装置に記憶されることを回避することができ、その結果、データファイルを送信先のユーザー以外の者に取得されてしまう事態をより確実に回避することが可能となる。
【００７７】
また、データファイルを復号した後は、復号後に所定の時間が経過したか否かを判断し、所定の時間が経過した場合には、復号して得られたデータファイル（暗号化されていないデータファイル）を消去するものとしてもよい。一般に、インターネットなどのネットワーク回線を用いる場合、ネットワーク回線に支障が生じてネットワーク接続が切断される場合が起こりえるが、こうすれば、ネットワーク接続が切断されてデータファイルを送付相手に送信できない場合であっても、復号後のデータファイル（暗号化されていないデータファイル）がデータファイル送信システム１００上に残ってしまってデータファイルの機密性が損なわれてしまう事態を回避することが可能である。
【００７８】
以上に説明したように、本実施例のデータファイル送信システム１００では、データファイル送信システム１００のドメイン名（本実施例では「〇〇〇．〇〇〇」）ではなく、送信元のユーザーに応じて決定した別のドメイン名を用いて、データファイル送信システム１００からデータファイルをダウンロードさせる。こうすることにより、送信先のユーザーがダウンロードを躊躇してしまう虞の少ない使い勝手の良いデータファイル送信サービスを実現することが可能となる。この点について説明する。
【００７９】
一般に、インターネットを使用するユーザーがインターネットからデータファイルをダウンロードする際には、コンピューターウィルスなどの有害なデータファイルをダウンロードしてしまうのではないかといった不安を覚えることがある。特に、見慣れないドメイン名や素性が分からないドメイン名のＵＲＬからデータファイルをダウンロードする際には、ダウンロード先のコンピューター（ホスト）の素性が分からないことから、こうした不安を強く感じる傾向がある。
【００８０】
この点、本実施例のデータファイル送信システム１００では、前述したように、ダウンロードＵＲＬのドメイン名に、送信元のユーザー（送信者）が使用したいドメイン名を使用することが可能である。このドメイン名としては、例えば、送信者が所属する会社等の組織のドメイン名や、あるいは送信者自身が所有するドメイン名などを用いることが可能である。こうした場合、データファイルをダウンロードしようとするユーザーは、ダウンロードＵＲＬのドメイン名が送信者に関連があるドメイン名（例えば、送信者が所属する組織のドメイン名など）であることから、ダウンロード先のホストが信頼できるホストであることを認識することが可能である。その結果、素性が分からないホストからデータファイルをダウンロードするという不安を払拭して、安心してデータファイルをダウンロードすることが可能となる。
【００８１】
また、このように送信先のユーザーが安心してダウンロードできることから、送信元のユーザーにとっても、送信先のユーザーがデータファイルをダウンロードしてくれないのではないかといった懸念を払拭することができるので、安心してデータファイルを送信することが可能である。このように、送信元のユーザーにとっても送信先のユーザーにとっても、安心して使用できる使い勝手のよいデータファイル送信サービスを提供することが可能となる。
【００８２】
なお、送信元のユーザーが所属する組織のコンピューターからデータファイルをダウンロードさせるのであれば、そのコンピューターにはその組織のドメイン名が付されていることから、上述したような不安を送信先のユーザーが覚えることを回避することができると考えられる。とはいえ、ユーザーのコンピューターとは異なるコンピューターを用いてこうした機能を提供する場合（いわゆるアプリケーションサービスの形態やクラウドサービスの形態として提供する場合）、こうしたことを実現することは容易ではない。すなわち、送信元のユーザーからのデータファイルを記憶するコンピューターは、送信元のユーザーが所属する組織のコンピューターではないので、その組織のドメイン名を有していない。このため、通常はその組織のドメイン名のＵＲＬを使ってデータファイルをダウンロードさせることはできない。かといって、ユーザーごとに専用のコンピューターを用意して、ユーザーの組織のドメイン名をコンピューターに付すべくユーザーの組織にそのコンピューターを管理させたのでは、コンピューターを用意したり管理することなく各種の機能を容易に使用できるというアプリケーションサービスやクラウドサービスの利点が失われてしまう。
【００８３】
この点、本実施例のデータファイル送信システム１００では、ダウンロードＵＲＬに用いるドメイン名と、データファイル送信システム１００のＩＰアドレスとをＤＮＳレコードにより対応付けることにより、こうしたことを容易に実現可能としている。すなわち、ＤＮＳレコードを設定するだけであれば、使用するドメイン名ごとにコンピューターを用意したり、そのコンピューターをユーザーの組織に管理させる必要がない。もちろん、ドメイン名を管理する権限をユーザーから委譲してもらう等の煩雑な手続きをおこなう必要もない。これにより、信頼できるドメイン名のＵＲＬを使ってデータファイルをダウンロード可能なサービスを、アプリケーションサービスやクラウドサービスの利点を失うことなく提供することが可能となる。
【００８４】
また、本実施例のデータファイル送信システム１００では、ダウンロードＵＲＬに用いることができるドメイン名は１つではなく、複数のドメイン名を使い分けることが可能である。このため、使用するドメイン名がそれぞれ異なる複数の組織や複数のユーザーにサービスを提供する場合であっても、ドメイン名ごとにサーバー装置を用意する必要がなく、サービスを容易に提供可能である。例えば、図５に示されている例では、ドメイン名「ｘｘｘ．△△△．△△△」と、ドメイン名「ｙｙｙ．□□□．□□□」との２種類のドメイン名をユーザーに応じて使い分けるが、このように複数のドメイン名を使い分ける場合には、次の図１１のようにＤＮＳレコードを設定しておけばよい。
【００８５】
図１１は、複数のドメイン名が使われる場合のＤＮＳレコードの設定例を示した説明図である。図１１では、図５に示された２種類のドメイン名「ｘｘｘ．△△△．△△△」および「ｙｙｙ．□□□．□□□」が使われる場合のＤＮＳレコードの設定例が示されている。まず、図１１（ａ）および図１１（ｂ）に示されているように、使用するそれぞれのドメイン名を、データファイル送信システム１００のサブドメイン名に対応付けておく（図１１（ａ）に「Ｆ」と示されたＤＮＳレコード及び図１１（ｂ）に「Ｇ」と示されたＤＮＳレコードを参照）。そして、それぞれのサブドメイン名を、データファイル送信システム１００のドメイン名を介してデータファイル送信システム１００のＩＰアドレスに対応付ける（図１１（ｃ）に「Ｈ」と示されたＤＮＳレコードおよび「Ｉ」と示されたＤＮＳレコードを参照）。こうすれば、いずれのドメイン名を用いたＵＲＬであっても、そのＵＲＬを使ったリクエストをデータファイル送信システム１００のサーバー装置１０２で受信することが可能となる。
【００８６】
このように、ダウンロードＵＲＬに使用されるドメイン名が１つではなく複数存在する場合であっても、それぞれのドメイン名のダウンロードＵＲＬに基づくリクエストを１つのサーバー装置１０２で受信することが可能であり、ドメイン名ごとにサーバー装置を設ける必要がない。このため、使用するドメイン名がそれぞれ異なる複数のユーザーや複数の組織にサービスを提供する場合であっても、ユーザーや組織ごとにサーバー装置を設ける必要がなく、サービスを容易に提供可能である。
【００８７】
加えて、本実施例のデータファイル送信システム１００では、送信先のユーザーからのリクエストをデータファイル送信システム１００が直接受信することが可能であり、ダウンロードＵＲＬのドメイン名を有するコンピューターから、ダウンロードＵＲＬに基づくリクエストを転送してもらう必要がない。このため、リクエストがインターネット上を何度も行き来することに起因してレスポンスが遅くなってしまう虞を回避して、送信先のユーザーはデータファイル送信システム１００に迅速に接続することが可能である。この点からも、データファイル送信システム１００の使い易さを向上させることが可能となっている。
【００８８】
また、上述したように本実施例のデータファイル送信システム１００では、データファイルを暗号化した状態で、データファイル送信システム１００上に記憶している。このため、データファイル送信システム１００のＲＡＭやディスク装置１０４からたとえデータを自由に取得可能であっても、データファイルに記述された情報を取得することは実際上は不可能である。したがって、データファイル送信システム１００の管理者等にデータファイルの内容を取得されてしまう虞を回避することが可能である。このように、データファイルの機密性を高めた状態でデータファイルを記憶するので、ユーザーは安心してデータファイルを送信することが可能となり、その結果、より使い勝手のよいサービスを実現することが可能となる。
【００８９】
加えて、本実施例では、データファイルがダウンロードされるとデータファイルを消去することから、万が一、送信先のユーザー以外の者にデータファイルをダウンロードされてしまった場合には、そのことを検知することが可能である。すなわち、送信先のユーザーがダウンロードＵＲＬを用いてデータファイルをダウンロードしようとした際に、他の者がデータファイルを既にダウンロードしている場合には、データファイルが消去されていることからデータファイルをダウンロードすることができない。したがって、データファイルをダウンロードできないことから、送信先のユーザー以外の者がデータファイルをダウンロードしたことを知ることが可能である。このように他者にデータファイルをダウンロードされてしまった場合にはそのことを検知できるので、気が付かないうちに他者にデータファイルを取得されているのではないかとの不安を払拭することが可能である。
【００９０】
また、このことを逆に捉えれば、送信先のユーザーがデータファイルをダウンロードできたということは、他者にデータファイルをダウンロードされていないことを意味しており、このため、送信先のユーザーがデータファイルをダウンロードした際には、データファイルの機密性が保たれていることを確信することが可能である。このようにデータファイルがダウンロードされるとデータファイルを消去することにより、ユーザーの安心感を高めて本実施例のデータファイル送信システム１００の使い勝手を向上させることが可能となる。
【００９１】
なお、上述した実施例では、暗号化の際と復号の際とに同一の暗号キーを用いるアルゴリズムを用いる場合について説明したが、暗号化の際と復号の際とで異なる暗号キーを使う暗号化アルゴリズムを用いるものとしてもよい。この場合には、暗号化の際に用いた暗号キーに対応する復号キーを、送付相手のユーザーに通知すればよい。例えば、サーバー装置１０２が暗号キー及びその暗号キーに対応する復号キーを生成し、暗号キーを用いてデータファイルを暗号化するとともに、復号キーをデータファイルの送信元のユーザーに送信する。データファイルの送信元ユーザーは、この復号キーを送付相手に伝える。こうすれば、送信相手はその復号キーをデータファイル送信システム１００に送信し、データファイル送信システム１００がその復号キーを用いてデータファイルを復号することにより、復号されたデータファイルを送付相手にダウンロードさせることが可能となる。
【００９２】
また、上述した実施例では、ランダムな文字列をダウンロードＵＲＬのダウンロードキーに用いている（図６に「Ａ」と示された文字列を参照）。こうすると、データファイルを送付相手以外の者に取得されてしまう虞をより確実に回避することが可能となる。すなわち、ダウンロードＵＲＬに含まれるダウンロードキーをランダムな文字列（推測不可能な文字列）にしておけば、このダウンロードＵＲＬの通知を受けた者（送信先のユーザー）以外は、このダウンロードＵＲＬを推測することはほとんど不可能である。データファイル送信システム１００はダウンロードＵＲＬに対応するデータファイルを送信することから、こうすれば、データファイルの送信先のユーザー以外の者がデータファイルをダウンロードしてしまう虞をより確実に回避することが可能である。加えて、データファイルをダウンロードするためには、暗号キーに加えてダウンロードキーが必要なことから、たとえ暗号キーを送信相手以外の者に知られてしまった場合であっても、データファイルの機密性を保つことが可能となる。
【００９３】
なお、このように推測不可能な文字列をダウンロードキーに用いる場合、送信元のユーザーは、送信相手ごとに暗号キーを変えずに、複数の送信相手に対して同一の暗号キーを用いることも可能である。例えば、送信元のユーザーは、ＡとＢの２人の相手に対してそれぞれ異なるデータファイルを送信したが、いずれの相手に対しても同一の暗号キーを用いたとする。このとき、Ａに対して送信したデータファイルのダウンロードＵＲＬをＡにだけ通知すれば、Ｂはたとえ暗号キーを知っていても、送信元のユーザーがＡに送信したデータファイルを取得することは不可能である。このように、複数の送信相手に対して同一の暗号キーを用いる場合、データファイルの送信相手の他にも暗号キーを知っている者が存在することになるが、ダウンロードＵＲＬの通知を受けなければ、そのデータファイルを取得することは不可能である。このため、複数の送信相手に対して同一の暗号キーを用いることも可能であり、こうすれば、送信元のユーザーが暗号キーを送信相手ごとに変更したり送信の度に変更する手間を省くことが可能となって、データファイル送信システムの利便性をより向上させることが可能となる。
【００９４】
Ｅ．変形例  ：
Ｅ−１．第１変形例  ：
前述した実施例では、データファイル送信システム１００に対して１つのＩＰアドレスが対応付けられており、ダウンロードＵＲＬに用いる各ドメイン名を、この１つのＩＰアドレスに対応付けておくものとして説明した（図１１を参照）。しかし、複数のＩＰアドレスをデータファイル送信システム１００に対応付けておき、ダウンロードＵＲＬに用いる各ドメイン名をこれらの各ＩＰアドレスにそれぞれ対応付けるものとしてもよい。
【００９５】
図１２は、複数のＩＰアドレスの各々に各ドメイン名を対応付ける第１変形例のデータファイル送信システム１００に用いられるＤＮＳレコードを例示した説明図である。図１２（ａ）および図１２（ｂ）には、ダウンロードＵＲＬに用いるドメイン名をデータファイル送信システム１００のサブドメイン名に対応付けたＤＮＳレコードが例示されている（図１２（ａ）の例ではドメイン名「ｘｘｘ．△△△．△△△」をサブドメイン名「ｚｚｚ．○○○．○○○」に対応付けており、図１２（ｂ）の例ではドメイン名「ｙｙｙ．□□□．□□□」をサブドメイン名「ａａａ．○○○．○○○」に対応付けている）。第１変形例においても前述した実施例と同様に、このようにダウンロードＵＲＬに用いるドメイン名をデータファイル送信システム１００のサブドメイン名に対応付けておくことにより、ダウンロードＵＲＬに用いるドメイン名についての問い合わせが、データファイル送信システム１００のサブドメイン名についての問い合わせに変換される。
【００９６】
ここで、前述した実施例では、こうして対応付けたサブドメイン名をデータファイル送信システム１００のドメイン名に対応付けていたが（図１１（ｂ）に「Ｈ」と示されたＤＮＳレコードおよび「Ｉ」と示されたＤＮＳレコードを参照）、第１変形例では、図１２（ｃ）に示されているように、これらのサブドメインを、データファイル送信システム１００のＩＰアドレスに対応付けておく（図１２（ｃ）に「Ｊ」と示されたＤＮＳレコードおよび「Ｋ」と示されたＤＮＳレコードを参照）。こうすると、ダウンロードＵＲＬのドメイン名についての問い合わせがデータファイル送信システム１００のサブドメイン名についての問い合わせに変換され、最終的にはデータファイル送信システム１００のＩＰアドレスがＤＮＳサーバーによって返答される。その結果、前述した実施例と同様に、ダウンロードＵＲＬに基づくリクエストをデータファイル送信システム１００が受信することが可能となる。
【００９７】
ここで、データファイル送信システム１００が複数のＩＰアドレスを有している場合、ダウンロードＵＲＬに用いる各ドメイン名にして互いに異なるＩＰアドレスを対応付けておくことが可能であり、こうすると、送付先のユーザーがダウンロードを躊躇してしまう虞をいっそう確実に回避可能となる。すなわち、前述したように、インターネットではドメイン名に対応するＩＰアドレスを調べることが可能である。このため、送信先のユーザーがダウンロードＵＲＬのドメイン名からＩＰアドレスを調べれば、そのＩＰアドレスが他のドメイン名（ダウンロードＵＲＬに使われる他のドメイン名やデータファイル送信システム１００のドメイン名）にも対応付けられているか否かを調べることが原理的には可能である。この点、第１変形例では、ＩＰアドレスとドメイン名とを一対一に対応付けることができるので、たとえＩＰアドレスに対応付けられたドメイン名をユーザーが調べたとしても、ダウンロードＵＲＬに対応するＩＰアドレスが他のドメイン名にも対応付けられていることに起因してユーザーがそのＩＰアドレスに疑念を抱いてしまう虞を回避することができる。その結果、ダウンロードＵＲＬに対応するＩＰアドレスが他のドメイン名にも対応付けられていることに起因してユーザーがそのＩＰアドレスへのアクセスを躊躇してしまう事態を確実に回避することが可能となる。
【００９８】
Ｅ−２．第２変形例  ：
前述した実施例および第１変形例では、ダウンロードＵＲＬに用いるドメイン名を、データファイル送信システム１００のサブドメイン名を介してデータファイル送信システム１００のＩＰアドレスに対応付けるものとして説明した（図１１または図１２を参照）。しかし、ダウンロードＵＲＬに用いるドメイン名を最終的にデータファイル送信システム１００のＩＰアドレスに対応付ければ良いことに鑑みれば、サブドメイン名を介さずにデータファイル送信システム１００のＩＰアドレスに直接対応付けることも可能である。
【００９９】
図１３は、ダウンロードＵＲＬに用いるドメイン名をＩＰアドレスに直接対応付ける第２変形例のＤＮＳレコードを例示した説明図である。この図では、ダウンロードＵＲＬにドメイン名「ｘｘｘ．△△△．△△△」を用いる場合について示されている。図示されているように、このドメイン名をデータファイル送信システム１００のＩＰアドレス「２４ｘ．１５ｘ．５２ｘ．３」に対応付けたＤＮＳレコードを設定しておく。こうした場合も、ダウンロードＵＲＬのドメイン名に対してデータファイル送信システム１００のＩＰアドレスをＤＮＳサーバーから取得することができるので、ダウンロードＵＲＬを用いたアクセスをデータファイル送信システム１００が受信することが可能となり、その結果、送信先のユーザーにダウンロードＵＲＬを用いてデータファイルをダウンロードさせることが可能となる。
【０１００】
Ｅ−３．第３変形例  ：
前述した実施例のデータファイル送信システム１００では、送信先のユーザーがデータファイルをダウンロードすると、データファイル送信システム１００は記憶していたデータファイルを消去するものとして説明した（図９：ステップＳ２０８を参照）。もっとも、データファイルを消去せずにデータファイル送信システム１００上に残しておくものとしてもよく、こうすれば、送信先のユーザーは複数回にわたってデータファイルをダウンロードすることができるので、データファイル送信システム１００の利便性をより高めることが可能となる。例えば、仕事場のコンピューターで一度ダウンロードしたデータファイルを、自宅のコンピューターでもダウンロードすることが可能となる。ここで、データファイルをデータファイル送信システム１００から消去せずに残しておく場合、次のような方法を用いると好適である。
【０１０１】
図１４は、データファイルを複数回にわたってダウンロード可能とするために、送信先のユーザーにロックキーを入力させる第３変形例のデータファイル送信システム１００を例示した説明図である。図示されているように、第３変形例のデータファイル送信システム１００では、送信先のユーザーがダウンロードＵＲＬを用いてアクセスしてきた際に、暗号キーだけでなく、「ロックキー」を入力させる。ここで、ロックキーは暗号キーと同様に文字列であり、ユーザーは任意の文字列をロックキーに指定することが可能である。データファイル送信システム１００は、ロックキーが入力されると、入力されたロックキーを暗号化するとともに、暗号化したロックキーをデータファイルに対応付けた状態で記憶する。また、送信先のユーザーにデータファイルを送信した後も、データファイル（暗号化されたデータファイル）を消去せずに、そのまま保持する。
【０１０２】
その後、データファイルの送信先のユーザーがデータファイルを再びダウンロードすべくアクセスしてきた際には、暗号キーに加えてロックキーを入力させる（図１４を参照）。このとき入力されたロックキーが、先にデータファイルに対応付けて記憶していたロックキーと同一であれば、データファイルを送信すればよい。他方、ロックキーが同一でなければ、データファイルを送信しない。ロックキーが同一か否かは、入力されたロックキーを、先にロックキーを暗号化した際と同様の方法で暗号化し、先に記憶しておいたロックキー（暗号化されたロックキー）と比較することにより可能である。
【０１０３】
データファイルを消去せずにデータファイル送信システム１００に残しておく場合、データファイルを消去する場合に比べるとデータファイルが長い時間に渡ってデータファイル送信システム１００上に存在することから、データファイルを送信先のユーザー以外の者にダウンロードされるのではないかとの危惧をユーザーが抱く場合も考えられる。この点、このようにロックキーを設けておけば、暗号キーとロックキーとの両方を他者に取得されなければデータファイルをダウンロードされることがないので、データファイルが送信先のユーザー以外の者にダウンロードされてしまうのではないかとの不安を軽減することが可能となる。加えて、ロックキーはそのロックキーを設定した者だけが知っていればよく、他者に通知する必要がないものなので、通常は機密性が損なわれる虞はほとんど無い。このため、ユーザーは十分に安心してデータファイル送信システム１００を使用することが可能である。
【０１０４】
また、こうした場合、データファイルがダウンロードされた後にデータファイルを消去しないにもかかわらず、前述した実施例と同様に、送信先のユーザー以外の者にデータファイルをダウンロードされた場合には、そのことを検知することが可能である。すなわち、送信先のユーザーよりも先に他者がデータファイルをダウンロードした場合、その他者がロックキーを入力せずにデータファイルをダウンロードすれば、データファイルが消去されることから、送信先のユーザーはデータファイルをダウンロードできなくなる。このため、前述した実施例と同様に、データファイルをダウンロードできないことによって、他者にデータファイルをダウンロードされたことを認識することが可能である。他方、他者がロックキーを入力してデータファイルをダウンロードした場合には、送信先のユーザーは、そのロックキーを入力しなければデータファイルをダウンロードすることができない。したがって、この場合も、データファイルをダウンロードできないことによって、他者にデータファイルをダウンロードされてしまったことを認識可能である。
【０１０５】
このように、データファイルを消去しない場合であっても、前述した実施例と同様に、万が一、他者にデータファイルをダウンロードされてしまった場合には、そのことを検知可能であることから、気付かないうちに他者にデータファイルを取得されているのではないかとの不安をユーザーが抱く虞を回避することが可能である。また、前述した実施例と同様に、このことを逆に捉えれば、送信先のユーザーがデータファイルをダウンロードできたということは、他者がデータファイルをダウンロードしていないことを意味している。このため、送信先のユーザーがデータファイルをダウンロードした際には、データファイルの機密性が保たれていることを確信することが可能である。このように、ダウンロード後にデータファイルを消去しない場合であっても、ユーザーの安心感を高めることが依然として可能であり、その結果、ユーザーの安心感を高めながらも、複数回にわたってデータファイルをダウンロード可能としてデータファイル送信システム１００の利便性を向上させることが可能となる。
【０１０６】
Ｅ−４．第４変形例  ：
前述した実施例のデータファイル送信システム１００では、送信先のユーザーから暗号キーを受信すると、その暗号キーを使ってデータファイルを直ちに復号するものとして説明した（図９：ステップＳ２０２を参照）。もっとも、送信元のユーザーから暗号キーを知らされた送付先のユーザーであっても、暗号キーを入力する際に入力を誤ってしまう場合も起こり得る。こうした点に鑑みると、入力した暗号キーが正しいか否かを判断して、正しい場合にのみデータファイルを復号するものとしてもよい。このとき、暗号キーが正しいか否かを次の方法によって判断すると好適である。
【０１０７】
図１５は、入力された暗号キーが正しいか否かを判断する仕組みを概念的に示した説明図である。まず、送信元のユーザーから暗号キーを受信したら（図２：ステップＳ１０４を参照）、受信した暗号キーを、その暗号キーを用いて暗号化する（図１５に「暗号化」と示された白抜きの矢印を参照）。そして、暗号化前の暗号キーをデータファイル送信システム１００から消去する一方で、暗号化された暗号キーをデータファイル送信システム１００に記憶する。
【０１０８】
その後、送信先のユーザーがデータファイルをダウンロードすべくデータファイル送信システム１００にアクセスしてきたら、このユーザーから暗号キーを受信するとともに（図９：ステップＳ２０２を参照）、今度はこの暗号キーを暗号化する。そして、図１５に示されているように、先に記憶しておいた暗号化済みの暗号キー（送信元のユーザーから受信した暗号キーを暗号化したもの）と、今回の暗号キー（送信先のユーザーから受信した暗号キーを暗号化したもの）とを照合する。送信元のユーザーから受信した暗号キーと、送信先のユーザーから受信した暗号キーとが同一であれば、その暗号キーをその暗号キー自身を用いて暗号化したものも同一になるので、このように暗号化した暗号キー同士を照合することにより、送信元のユーザーから受信した暗号キーと、送信先のユーザーから受信した暗号キーとが同一か否かを判断することが可能である。
【０１０９】
このように、暗号キーをその暗号キー自身で暗号化したものを記憶しておけば、送信先のユーザーから受信した暗号キーが正しい暗号キーか否かを判断することが可能となる。また、こうした場合、暗号キーをデータファイル送信システム１００上に記憶しておくものの、暗号キーは暗号化された状態で記憶されるので、暗号キーの機密性を保つことが可能である。このため、暗号キーを記憶しておくことにより暗号キーが正しいか否かを判断可能としながらも、暗号キーを他者に取得されてしまう虞を回避することが可能となる。その結果、暗号キーが正しい場合にのみデータファイルを復号することによってデータファイル送信システム１００の利便性を高めながらも、データファイルの機密性を依然として高く保つことが可能となる。
【０１１０】
Ｅ−５．第５変形例  ：
前述した実施例では、ダウンロードＵＲＬに付随する文字列（ダウンロードキー）は、データファイルを特定するために用いられるものとして説明した。しかし、ダウンロードキーを、データファイルを特定する目的だけでなく、各種の情報を保持する目的に用いることも可能である。
【０１１１】
図１６は、ダウンロードキーに情報を保持させる様子を概念的に示した説明図である。ダウンロードキーには各種の情報を保持させることが可能であるが、ここでは、図示されているように、「送信元ユーザーのユーザーＩＤ」「ダウンロードの有効期限」「送信先ユーザーのメールアドレス」「サーバーに予め設定した文字列」の各情報を保持させる場合を例にとって説明する。
【０１１２】
まず、これらの各情報を暗号化することによって、ダウンロードキーを生成する（図１６に「暗号化」と示された白抜きの矢印を参照）。例えば、これらの各情報を所定のバイト列に格納し、そのバイト列を暗号化することによって暗号化されたバイト列を取得し、そのバイト列を文字列に変換することによって、ダウンロードキーを生成する。こうして各情報に基づいてダウンロードキーを生成しておけば、送信先のユーザーがこのダウンロードキーを含むダウンロードＵＲＬを用いてデータファイル送信システム１００にアクセスしてきた際には、ダウンロードキーから各情報を取得することが可能となる。すなわち、ダウンロードＵＲＬからダウンロードキーを取得し、取得したダウンロードキーを復号することにより、元の各情報（図１６の例では「送信元ユーザーのユーザーＩＤ」「ダウンロードの有効期限」「送信先ユーザーのメールアドレス」「サーバーに予め設定した文字列」）を取得することが可能となる。
【０１１３】
このように、各種の情報に基づいてダウンロードキーを生成すれば、そのダウンロードキーに各種の情報を保持させることが可能である。こうすると、ダウンロードキーに保持させた情報を、ダウンロードキーに基づいて取得することができるので、データファイル送信システム１００では、それらの情報を記憶しておく必要がない。例えば、図１６の例では、ダウンロードの有効期限をダウンロードキーに保持させており、こうすれば、データファイル送信システム１００ではダウンロードの有効期限（送信先のユーザーがデータファイルをダウンロード可能な期限）を記憶しておかなくても、有効期限を過ぎているか否かを判断することが可能となる。
【０１１４】
なお、上述したように、ダウンロードキーには各種の情報を保持させることが可能であるが、図１６の例に示されているように、データファイル送信システム１００のサーバー装置１０２に予め設定しておいた文字列をダウンロードキーに保持させると、より好適である。すなわち、こうした場合、データファイル送信システム１００がダウンロードＵＲＬを使ったアクセスを受信した際には、そのダウンロードＵＲＬが、データファイル送信システム１００が生成したダウンロードＵＲＬか否かを、ダウンロードキーに保持させた文字列に基づいて判断することが可能である。こうしてデータファイル送信システム１００が生成したダウンロードＵＲＬか否かを確認すれば、ダウンロードＵＲＬが偽造されてデータファイルが不正に取得されてしまう事態をより確実に回避することが可能となる。
【０１１５】
Ｅ−６．第６変形例  ：
前述した実施例では、予めユーザーＩＤに対応付けて記憶しておいたドメイン名を、ダウンロードＵＲＬに用いるものとして説明した（図２：ステップＳ１１０および図５を参照）。しかし、ダウンロードＵＲＬに用いるドメイン名を決定する方法は、こうした方法に限らず、他の方法を用いることが可能である。
【０１１６】
例えば、ユーザーＩＤにドメイン名を含む文字列を使いておき、その文字列に含まれるドメイン名を使用するものとしてもよい。こうした例としては、ユーザーのｅメールアドレスをユーザーＩＤに用いることが考えられる。ｅメールアドレスにはドメイン名が含まれているので、ｅメールアドレスからドメイン名を取得してそのドメイン名を使用することが可能である。一般に、ｅメールアドレスのドメイン名は、そのユーザーの所属する組織のドメイン名であることが多いので、こうしたドメイン名をダウンロードＵＲＬに用いれば、そのドメイン名が信頼できる組織のドメイン名であることから、送信先のユーザーは、安心してデータファイルをダウンロードすることが可能となる。
【０１１７】
また、このようにユーザーＩＤにドメイン名を含む文字列を用いた場合には、ドメイン名とユーザーＩＤとを対応付けたテーブルを備えなくてもよいので、データファイル送信システム１００の記憶容量を節約することが可能となる。加えて、テーブルを参照しなくてもよいことから、サーバー装置１０２の処理負担を軽減させることも可能となる。
【０１１８】
また、ダウンロードＵＲＬに用いるドメイン名をユーザーごとに決めておくのではなく、ユーザーがデータファイルを送信する際にドメイン名を決めるものとしてもよい。こうした場合、ユーザーは、データファイルの送信相手に応じて、その送信相手が信用する適切なドメイン名を選択することができる。こうすれば、送信相手により確実にデータファイルをダウンロードさせることが可能となる。
【０１１９】
これに対して、ダウンロードＵＲＬに用いるドメイン名をユーザーごとに決めておく場合には、そのユーザーに必ずそのドメイン名を使用させることができることから、データファイル送信システム１００の使用権限が流用されてしまう事態を回避することが可能である。例えば、企業などの組織がデータファイル送信システム１００の使用権限を取得した場合には、その企業に所属するユーザーにその企業のドメイン名を対応付けておくことにより、そのユーザーはその企業のドメイン名をダウンロードＵＲＬに用いるものとしておく。こうすれば、その企業に所属するユーザーが、その企業のドメイン名以外のドメイン名をダウンロードＵＲＬに使用するのを防止することができるので、その企業が取得したデータファイル送信システム１００の使用権限を、別の企業の用途や個人の用途などに流用されてしまう事態を回避することが可能となる。
【０１２０】
Ｅ−７．第７変形例  ：
上述した実施例および変形例のデータファイル送信システム１００では、データファイルの送信元のユーザーがデータファイル送信システム１００にアクセスしてデータファイルをアップロードする際にも、そのユーザーがダウンロードＵＲＬに使用するドメイン名を用いることが可能である。すなわち、ダウンロードＵＲＬに用いるドメイン名はＤＮＳレコードによってデータファイル送信システム１００のＩＰアドレスに対応付けられているので、データファイルをアップロードする際にもこのドメイン名を使ってデータファイル送信システム１００にアクセスすることが可能である。
【０１２１】
図１７は、送信元のユーザーが、ダウンロードＵＲＬに用いるドメイン名を用いてデータファイル送信システム１００にアクセスする様子を例示した説明図である。図示されているように、送信元のユーザーは、Ｗｅｂブラウザの接続先に、データファイル送信システム１００のドメイン名「〇〇〇．〇〇〇」とは異なるドメイン名「ｘｘｘ．△△△．△△△」を指定している。すると、このドメイン名「ｘｘｘ．△△△．△△△」はデータファイル送信システム１００のＩＰアドレスに対応付けられていることから、送信元のユーザーは、このドメイン名「ｘｘｘ．△△△．△△△」を用いてデータファイル送信システム１００にアクセスすることが可能である。
【０１２２】
このように、データファイルの送信元のユーザーがデータファイルを送信する際にも、そのユーザーがダウンロードＵＲＬに用いるドメイン名（図１７の例では「ｘｘｘ．△△△．△△△」）を使用することが可能である。こうすれば、送信元のユーザーがデータファイルを送信する際に、データファイルを素性の分からないホストに送信しなければならないという不安を覚える虞を回避することも可能となるので、より好適である。
【０１２３】
なお、送信元のユーザーがデータファイル送信システム１００にアクセスする際のドメイン名と、ダウンロードＵＲＬに用いるドメイン名とを、異なるドメイン名にすることも可能である。すなわち、送信元のユーザーがデータファイル送信システム１００にアクセスする際のドメイン名と、ダウンロードＵＲＬのドメイン名とのいずれもデータファイル送信システム１００のＩＰアドレスに対応付けておけば、いずれのドメイン名を使ってもデータファイル送信システム１００にアクセスすることが可能である。
【０１２４】
また、一般に、送信元のユーザーがデータファイル送信システム１００にアクセスする際には、そのユーザーが所属する組織のドメイン名などの信頼できるドメイン名を使用したいと考える傾向がある。すると、こうしたドメイン名は、送信先のユーザーにとっても信頼できるドメイン名であることが通常である。したがって、送信元のユーザーがアクセスしてきたＵＲＬのドメイン名（図１７の例では「ｘｘｘ．△△△．△△△」）を、そのままダウンロードＵＲＬのドメイン名に用いてやれば、送信先のユーザーが安心してデータファイルをダウンロードできる適切なダウンロードＵＲＬを生成することが可能となる。加えて、こうすれば、ダウンロードＵＲＬに用いるドメイン名をユーザーごとに記憶しておいたり、ユーザーにドメイン名を選択させる処理を行う必要がないので、データファイル送信システム１００の記憶容量を節約したり、サーバー装置１０２の処理負担を軽減することが可能となって好適である。
【０１２５】
Ｅ−８．第８変形例  ：
データファイル送信システム１００では、送信先のユーザーがデータファイルをダウンロードする際の画面の表示態様を、送信元のユーザーが選択するものとしてもよい。
【０１２６】
図１８は、データファイルをダウンロードする際に表示される画面を、送信元のユーザーが選択する様子を示した説明図である。図示されているように、送信元のユーザーの表示画面２１０には、ダウンロード時に表示するページ（ダウンロードページ）を選択する画面が表示されている。データファイル送信システム１００は、送信元のユーザーからデータファイルを受信する際にこうした選択画面を表示することにより、ダウンロード時に表示するページを送信元のユーザーに選択させる。ユーザーに選択させるダウンロードページは、予めデータファイル送信システム１００に記憶しておいてもよいし、データファイルを送信する前に、ユーザーが作成するものとしてもよい。
【０１２７】
送信元のユーザーがダウンロードページを選択したら、データファイル送信システム１００は、選択されたダウンロードページをダウンロードＵＲＬに対応付けて記憶する。そして、送信先のユーザーがダウンロードＵＲＬを使ってデータファイル送信システム１００にアクセスしてきたら、そのダウンロードＵＲＬに対応付けられたダウンロードページを表示する。例えば、図１８の例では、送信元のユーザーは「Ａ社様用ダウンロードページ」を選択しているので、このダウンロードページが選択された旨をダウンロードＵＲＬに対応付けておき、そのダウンロードＵＲＬを用いてデータファイル送信システム１００にアクセスがあったら、ダウンロードＵＲＬに対応付けられたダウンロードページを特定して、そのダウンロードページを送信する。
【０１２８】
図１９は、送信元のユーザーが選択したダウンロードページが送信先のユーザーの端末８００に表示された様子を例示した説明図である。図示されている例では、送信元のユーザーが「Ａ社様用ダウンロードページ」を選択したことに対応して、送信先のユーザーの端末８００には「Ａ社様用ダウンロードページ」が表示される。こうして、送信先のユーザーがデータファイルをダウンロードする際の画面を選択可能としておけば、ダウンロードページによって送信先のユーザーに安心感を与えることが可能となり、延いては、送信先のユーザーがデータファイルをダウンロードするのを躊躇してしまう事態をより確実に回避することが可能となる。例えば、図１８に示されている例のように、送信先の組織ごとにダウンロードページを用意するとともに、それぞれのダウンロードページには、組織の名称などの組織を特定できる情報をそれぞれ記載しておく。そして、データファイルを送信する際には、送信相手の組織用のダウンロードページを選択する。こうすれば、送信先のユーザーは、表示されたダウンロードページから、そのデータファイルが自分宛てのデータファイルである旨を再確認することができるので、より安心した上でデータファイルをダウンロードすることが可能となる。もちろん、送信先の組織の名称ではなく、送信先のユーザーの氏名などを用いた場合も同様である。
【０１２９】
また、送信先のユーザーの組織名やユーザーの氏名などの送信先のユーザーに関する情報を表示するのではなく、送信元のユーザーに関する情報を表示するものとしてもよい。例えば、送信元のユーザーの氏名やユーザーが所属する組織名などを表示するものとしてもよい。こうした場合、送信先のユーザーは送信元のユーザーに関する情報が得られることから、より安心してデータファイルをダウンロードすることが可能となる。
【０１３０】
このように、送信先のユーザーがデータファイルをダウンロードする際に、送信相手に応じて適切な画面（ダウンロードページ）を表示してやれば、表示画面を用いて送信先のユーザーに安心感を与えることが可能となる。その結果、送信先のユーザーがデータファイルをダウンロードするのを躊躇してしまう事態をより確実に回避することが可能となる。
【０１３１】
Ｅ−９．第９変形例  ：
また、データファイル送信システム１００では、ダウンロードＵＲＬに用いるドメイン名の一部を、送信相手に応じて選択可能とすることも可能である。
【０１３２】
図２０は、ダウンロードＵＲＬに用いるドメイン名の一部を、送信元のユーザーが選択する様子を示した説明図である。図示されているように、送信元のユーザーの表示画面２１０には、ダウンロードＵＲＬに用いるドメイン名の候補が表示されており、これらの候補の中から使用するドメイン名を選択することが可能である。ここで、これらのドメイン名にはいずれも文字列「△△△．△△△」が使われているが、各ドメイン名の一部にはそれぞれ異なる文字列が使われている。すなわち、これらのドメイン名はいずれもドメイン名「△△△．△△△」のサブドメインになっている。こうした候補の中から、送信元のユーザーは、使用するドメイン名（サブドメイン名）を送信相手に応じて選択する。
【０１３３】
こうすると、送信相手に応じて適切なサブドメイン名を使用できることから、送信相手がデータファイルをダウンロードするのを躊躇してしまう事態をより確実に回避することが可能となる。すなわち、まず、送信先の組織に関連する語句を使用したサブドメイン名を、送信先の組織ごとに用意しておく。図２０の例では、データファイルの送信先がＡ社であることを示す語句「ａ−ｉｎｃ」を用いたサブドメイン名「ａ−ｉｎｃ．△△△．△△△」や、送信先がＢ社であることを示す語句「ｂ−ｉｎｃ」を用いたサブドメイン名「ｂ−ｉｎｃ．△△△．△△△」を用意している。その上で、こうしたサブドメイン名の中から、ダウンロードＵＲＬに用いるサブドメイン名を送信相手に応じて選択する。こうすれば、送信先のユーザーは、ダウンロードＵＲＬのサブドメイン名から、そのデータファイルが自分に宛てて送信された旨を確認することができるので、安心してデータファイルをダウンロードすることができる。また、ダウンロードＵＲＬのサブドメイン名は、送信元のユーザーやユーザーが所属する組織に関連するドメイン名（図２０の例では「△△△．△△△」）のサブドメインであるから、元のドメイン名と同じ文字列（図２０の例では「△△△．△△△」）を有している。このため、送信元のユーザーの素性を把握することも可能である。これにより、より安心してデータファイルをダウンロードすることが可能である。
【０１３４】
このように、共通のドメイン名のサブドメイン名を選択するものとすれば、送信元のユーザーに関連するドメイン名を共通のドメイン名として使用しながらも、送信相手ごとに異なるサブドメインを用いることができる。こうすれば、送信元に関連する文字列（図２０の例では「△△△．△△△」））と、送信先に関連する文字列（図２０の例では「ａ−ｉｎｃ」および「ｂ−ｉｎｃ」）との両方を使用することが容易に可能となり、その結果、送信先のユーザーにより確実に安心感を与えることが可能となる。また、共通して使用するドメイン名（図２０の例では「△△△．△△△」））については、データファイルを送信する相手に応じて選択する必要はなく、使用するドメイン名を予め決めておくことが可能である。したがって、前述した実施例と同様に、このドメイン名を送信元のユーザーごとに予め定めておくことも可能であり、こうすることによって、送信元のユーザーに関連するドメイン名を確実に使用させて、送信先のユーザーにより確実に安心感を与えることが可能となる。
【０１３５】
なお、このように複数のサブドメイン名の中から選択したサブドメイン名をダウンロードＵＲＬに用いる場合であっても、それぞれのサブドメイン名をデータファイル送信システム１００のＩＰアドレスに対応付けておくことにより、それぞれのダウンロードＵＲＬに基づくアクセスをデータファイル送信システム１００が受信することが可能となる。例えば、図２０に例示した２つのドメイン名「ａ−ｉｎｃ．△△△．△△△」および「ｂ−ｉｎｃ．△△△．△△△」を用いる場合には、図２１（ａ）および図２１（ｂ）に示されているように、これらの２つのドメイン名を、ＤＮＳレコードを介してデータファイル送信システム１００のＩＰアドレスに対応付けておく。こうすることにより、それぞれのサブドメイン名が用いられたダウンロードＵＲＬを用いて、データファイル送信システム１００にアクセスしてデータファイルをダウンロードすることが可能となる。
【０１３６】
Ｅ−１０．第１０変形例  ：
以上に説明したように、上述の実施例および変形例の方法を用いれば、サービスを提供するサーバー装置のドメイン名とは異なるドメイン名を用いて、そのサーバー装置上で稼動するサービスを提供することが可能である。こうした点に鑑みると、上述した実施例や変形例の方法は、データファイルを送信するサービスに限らず、ネットワーク上に設置したサーバー装置を用いて各種のサービスを提供するアプリケーションサービスやクラウドサービス全般に適用することも可能である。
【０１３７】
図２２は、サーバー装置のドメイン名とは異なるドメイン名を用いてサービスを提供するアプリケーションサービスの構成を概念的に示した説明図である。図示されているように、各種のアプリケーションプログラムを実際に実行するサーバー装置１０２には、ドメイン名「〇〇〇．〇〇〇」が対応付けられている。ここで、上述した実施例や変形例の方法を用いれば、ユーザーがサーバー装置１０２上でアプリケーションプログラムを実行する際に、サーバー装置１０２のドメイン名とは異なるドメイン名のＵＲＬ（図示されている例では「ｘｘｘ．△△△．△△△」）を用いてサーバー装置１０２にアクセスすることが可能である。このとき、アクセスに用いるドメイン名には、ユーザーが保有しているドメイン名や、ユーザーが所属する組織のドメイン名などを用いることが可能であり、そのようなドメイン名を用いれば、ドメイン名に起因してユーザーがアプリケーションサービスの使用を躊躇してしまう事態を回避することが可能となる。延いては、ユーザーにサービスをより使い易いと感じさせることも可能となる。
【０１３８】
例えば、ユーザーの所属する組織のドメイン名を用いてサービスを提供する場合には、ユーザーはそのドメイン名が自己の所属する組織のドメイン名であることから、安心してそのサービスを使用することが可能である。加えて、会社等の組織がそのサービスを導入した場合には、組織のメンバーがそのサービスを安心して使用できることから、サービスの利用率を向上させることも可能となる。
【０１３９】
もちろん、上述した実施例や変形例の方法をこうしたアプリケーションサービスやクラウドサービスに適用する場合にも、前述したように、ユーザーごとにサーバー装置を用意してそのサーバー装置の管理をユーザーに行わせたり、サーバー装置をユーザーに譲渡する必要がないので、サーバー装置を管理することなく手軽にサービスを利用できるというアプリケーションサービスやクラウドサービスの利点を損なうことはない。これにより、アプリケーションサービスやクラウドサービスの利点を生かしながらも、より使い易いサービスを提供することが可能となる。
【０１４０】
なお、こうしたサービス提供方法は、次のように把握することが可能である。すなわち、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたサーバー装置上で、該インターネットに接続されたコンピューターからの指示に応じてプログラムを動作させるとともに、該プログラムの出力を該サーバー装置から該コンピューターに送信するサービスを提供するサービス提供方法であって、
前記サーバー装置のドメイン名とは異なるドメイン名が前記ＩＰアドレスに対応付けられていることに起因して、該異なるドメイン名に属するＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信工程と、
前記受信したリクエストに基づいて、前記プログラムを前記サーバー装置上で実行するプログラム実行工程と、
前記実行結果を前記コンピューターに送信する結果送信工程と
を備えることを要旨とする。
【０１４１】
また、上述したサービス提供方法に対応するサービス提供システムは、
ＩＰアドレスおよびドメイン名が対応付けられた状態でインターネットに接続されたサーバー装置上で、該インターネットに接続されたコンピューターからの指示に応じてプログラムを動作させるとともに、該プログラムの出力を該サーバー装置から該コンピューターに送信するサービスを提供するサービス提供システムであって、
前記サーバー装置のドメイン名とは異なるドメイン名が前記ＩＰアドレスに対応付けられていることに起因して、該異なるドメイン名に属するＵＲＬに基づくリクエストが到達すると、該リクエストを受信するリクエスト受信手段と、
前記受信したリクエストに基づいて、前記プログラムを前記サーバー装置上で実行するプログラム実行手段と、
前記実行結果を前記コンピューターに送信する結果送信手段と
を備えることを要旨とする。
【０１４２】
かかるサービス提供方法およびサービス提供システムでは、では、サーバー装置のドメイン名とは異なるドメイン名がデータ送信システムのＩＰアドレスに対応付けられていることに起因して、そのドメイン名に属するＵＲＬに基づくリクエストが到達すると、そのリクエストを受信する。そして、リクエストに基づいてサーバー装置上でプログラムを実行し、実行結果をリクエストの送信先に送信する。
【０１４３】
こうすると、サーバー装置のドメイン名とは異なるドメイン名に属するＵＲＬを用いた場合であっても、サーバー装置にリクエストを受信させてサーバー装置上でプログラムを実行させることが可能となる。したがって、利用者に信頼される適切なドメイン名をＵＲＬに用いることが可能である。こうしたＵＲＬを用いれば、ＵＲＬのドメイン名に起因して利用者が不安を抱いてしまう虞を回避することができる。これにより、利用者が利用を躊躇してしまう虞が少ない使い勝手のよいサービスを実現することが可能となる。
【０１４４】
また、上述したサービス提供方法では、次の構成を採用してもよい。すなわち、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶工程と、
前記リクエストが到達すると、該リクエストのＵＲＬからドメイン名を取得するとともに、該ドメイン名と前記記憶していたドメイン名とを照合するドメイン名照合工程と
を備え、
前記リクエスト受信手段は、前記照合が合致した場合に、前記リクエストを受信する工程であるサービス提供方法。
【０１４５】
また、上述したサービス提供システムでは、次の構成を採用してもよい。すなわち、
前記ドメイン名とは異なるドメイン名を記憶しておくドメイン名記憶手段と、
前記リクエストが到達すると、該リクエストのＵＲＬからドメイン名を取得するとともに、該ドメイン名と前記記憶していたドメイン名とを照合するドメイン名照合手段と
を備え、
前記リクエスト受信手段は、前記照合が合致した場合に、前記リクエストを受信する手段であるサービス提供システム。
【０１４６】
かかるサービス提供方法およびサービス提供システムでは、ドメイン名を予め記憶しておき、リクエストのＵＲＬのドメインと、記憶しているドメイン名とを照合する。そして、照合が合致した場合に、リクエストを受け入れる。
【０１４７】
こうすれば、予め記憶しておいたドメイン名のＵＲＬに基づくリクエストについてのみ、リクエストを受け入れてプログラムを実行することが確実に可能となるので、ＵＲＬに使用するドメイン名の数をサービスの利用者が限度無く増やしてしまう虞を回避することが可能となる。また、ＵＲＬに使用するドメイン名を追加する際には、追加するドメイン名を記憶するだけで対応することが可能なので、好適である。
【０１４８】
以上、本実施例および変形例のデータファイル送信システムについて説明したが、本発明は、上述した実施例および変形例の容器に限られず、その趣旨を逸脱しない範囲において、種々の態様で実施することが可能である。
【符号の説明】
【０１４９】
１００…データファイル送信システム、    １０２…サーバー装置、
１０４…ディスク装置、    ２００…コンピューター、    ２１０…表示画面
【図１】
2012063891.tif 000003
【図２】
2012063891.tif 000004
【図３】
2012063891.tif 000005
【図４】
2012063891.tif 000006
【図５】
2012063891.tif 000007
【図６】
2012063891.tif 000008
【図７】
2012063891.tif 000009
【図８】
2012063891.tif 000010
【図９】
2012063891.tif 000011
【図１０】
2012063891.tif 000012
【図１１】
2012063891.tif 000013
【図１２】
2012063891.tif 000014
【図１３】
2012063891.tif 000015
【図１４】
2012063891.tif 000016
【図１５】
2012063891.tif 000017
【図１６】
2012063891.tif 000018
【図１７】
2012063891.tif 000019
【図１８】
2012063891.tif 000020
【図１９】
2012063891.tif 000021
【図２０】
2012063891.tif 000022
【図２１】
2012063891.tif 000023
【図２２】
2012063891.tif 000024