JP2004341986A - 情報保管システム及び情報保管サービス方法 - Google Patents
情報保管システム及び情報保管サービス方法 Download PDFInfo
- Publication number
- JP2004341986A JP2004341986A JP2003140093A JP2003140093A JP2004341986A JP 2004341986 A JP2004341986 A JP 2004341986A JP 2003140093 A JP2003140093 A JP 2003140093A JP 2003140093 A JP2003140093 A JP 2003140093A JP 2004341986 A JP2004341986 A JP 2004341986A
- Authority
- JP
- Japan
- Prior art keywords
- user
- storage
- unit
- data
- 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.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 41
- 230000004308 accommodation Effects 0.000 claims abstract description 106
- 238000013500 data storage Methods 0.000 claims abstract description 44
- 230000005540 biological transmission Effects 0.000 claims abstract description 15
- 238000007726 management method Methods 0.000 claims description 63
- 238000012546 transfer Methods 0.000 claims description 54
- 238000004891 communication Methods 0.000 claims description 32
- 238000012545 processing Methods 0.000 claims description 24
- 238000006243 chemical reaction Methods 0.000 claims description 22
- 238000007689 inspection Methods 0.000 claims description 18
- 238000009825 accumulation Methods 0.000 claims description 2
- 230000001052 transient effect Effects 0.000 claims 2
- 230000007704 transition Effects 0.000 claims 2
- 230000006870 function Effects 0.000 description 22
- 230000008569 process Effects 0.000 description 13
- 101000911772 Homo sapiens Hsc70-interacting protein Proteins 0.000 description 12
- 101001139126 Homo sapiens Krueppel-like factor 6 Proteins 0.000 description 8
- 125000002066 L-histidyl group Chemical group [H]N1C([H])=NC(C([H])([H])[C@](C(=O)[*])([H])N([H])[H])=C1[H] 0.000 description 5
- 230000008520 organization Effects 0.000 description 5
- 230000004044 response Effects 0.000 description 5
- 101001094649 Homo sapiens Popeye domain-containing protein 3 Proteins 0.000 description 4
- 101000608234 Homo sapiens Pyrin domain-containing protein 5 Proteins 0.000 description 4
- 101000578693 Homo sapiens Target of rapamycin complex subunit LST8 Proteins 0.000 description 4
- 102100027802 Target of rapamycin complex subunit LST8 Human genes 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 4
- 102100024412 GTPase IMAP family member 4 Human genes 0.000 description 3
- 101000833375 Homo sapiens GTPase IMAP family member 4 Proteins 0.000 description 3
- 230000008859 change Effects 0.000 description 3
- 230000010365 information processing Effects 0.000 description 3
- 239000000470 constituent Substances 0.000 description 2
- 238000012217 deletion Methods 0.000 description 2
- 230000037430 deletion Effects 0.000 description 2
- 238000001514 detection method Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000002411 adverse Effects 0.000 description 1
- 238000004140 cleaning Methods 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 108020001568 subdomains Proteins 0.000 description 1
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
【課題】利便性とセキュリティ性を高める。
【解決手段】ネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を設ける情報保管システムであって、宛先ユーザを収容する収容施設側に配置される収容施設側システムを有し、収容施設側システムは、宛先ユーザを収容施設に収容しているか否かを管理する収容管理部を備え、リモート保管サーバは、個別ユーザ用データ保管部を、宛先ユーザに対応付けて管理するための保管管理部を備え、リモート保管サーバは、収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行するユーザ名発行部を有する。
【選択図】 図１
【解決手段】ネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を設ける情報保管システムであって、宛先ユーザを収容する収容施設側に配置される収容施設側システムを有し、収容施設側システムは、宛先ユーザを収容施設に収容しているか否かを管理する収容管理部を備え、リモート保管サーバは、個別ユーザ用データ保管部を、宛先ユーザに対応付けて管理するための保管管理部を備え、リモート保管サーバは、収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行するユーザ名発行部を有する。
【選択図】 図１
Description
【０００１】
【発明の属する技術分野】
本発明は情報保管システム及び情報保管サービス方法に関し、例えば、宿泊施設や公共交通機関の利用中、電子メールの送受を行う場合などに適用して好適なものである。
【０００２】
【従来の技術】
ホテルなどでは、外部から宿泊者へ情報を届けるための通信手段としてファクシミリが用いられることが多い。このケースでは、宿泊者にファクシミリが届いた場合、ホテルの従業員がそのファクシミリを管理しておき、フロントなどを介して宿泊者へ渡す形になる。
【０００３】
また、ホテルの客室内にインターネット接続用のコネクタなどを用意しておき、客室に泊まった宿泊者のパーソナルコンピュータなどを当該コネクタに接続することで、インターネットアクセスが行えるようにしてあることも少なくない。その場合、宿泊者は、自宅などからインターネットアクセスするときと同様、自身が契約しているＩＳＰ（インターネットサービスプロバイダ）のメールサーバに確保した自身のメールボックスにアクセスすることにより、当該メールボックスに着信している自身宛ての電子メールを受信して閲覧したり、反対に当該メールサーバ経由で電子メールを送信したりすること等も可能である。また当該パーソナルコンピュータを用いれば、イントラネット（例えば、当該宿泊者が勤務している会社のＬＡＮ（ローカルエリアネットワーク））へ、インターネット経由または公衆電話網経由でリモートアクセス（例えば、ＶＰＮ（バーチャルプライベートネットワーク）などを利用したリモートアクセス）することも可能である。
【０００４】
さらに、当該宿泊者がオンラインストレージサービスの契約を行っている場合には、当該インターネット接続用のコネクタにパーソナルコンピュータなどを接続することで、インターネット上のストレージサーバに保管されているファイルを受信することもできる。これにより、ファイルを保管した者と宿泊者のあいだでメッセージ交換を行うこと等も可能である。
【０００５】
なお、ホテルの内部にはビジネスセンタを設け、当該ビジネスセンタ内に設置したパーソナルコンピュータやプリンタを、多くの宿泊者が共用できるようにしてあることも多い。このケースでは、個々の宿泊者は、宿泊時に自身のパーソナルコンピュータを携帯していなくても、ビジネスセンタ内のパーソナルコンピュータを用いてインターネットアクセス（電子メールの送受、前記ストレージサーバへのアクセス、リモートアクセスを含む）を行ったり、インターネットアクセスにより当該パーソナルコンピュータに受信したファイルの内容をプリンタを介して印刷出力したりすることが可能である。
【０００６】
【発明が解決しようとする課題】
ところで、上述したファクシミリを用いるケースでは、ファクシミリで受信され印刷出力された紙の文書の管理が適切に行われるか否かは、ホテル側の管理体制やホテルの従業員のセキュリティ意識に依存する。したがって、管理体制や従業員のセキュリティ意識などに問題がある場合、その文書が機密性の高いものであっても、機密が維持できない可能性もある。
【０００７】
また、宿泊者が自身のパーソナルコンピュータを客室のインターネット接続用コネクタに接続するケースでは、携帯電話機などに比べるとサイズも重量も大きいパーソナルコンピュータ（例えば、ノート型のパーソナルコンピュータ）を携帯し、ホテルに持ち込まなければならない点で不便である。携帯電話機などにもメーラを搭載し、電子メールの送受、閲覧が可能なものもあるが、携帯電話ネットワークを運営する携帯電話事業者により、添付ファイルの受信はできない旨の制約が課されていることが少なくない。また、たとえ当該制約がないケースであっても、携帯電話機の画面は小さく、キー操作は煩雑であるため、電子メール閲覧時の利便性に欠け、電子メールを印刷出力することは困難である。
【０００８】
なお、宿泊者自身のパーソナルコンピュータには、通常、ホテルのビジネスセンタなどに設置されたプリンタに対応するプリンタドライバがインストールされていないため、電子メールや添付ファイルの内容を印刷出力するには、プリンタドライバのインストールを行うか、あるいは、すでにプリンタドライバがインストールされている前記ビジネスセンタ内のパーソナルコンピュータを利用する必要がある。
【０００９】
プリンタドライバのインストールを行うことは宿泊者にとって煩わしいし、ビジネスセンタ内のパーソナルコンピュータを利用する場合には、次に述べるように、宿泊者自身のパーソナルコンピュータを用いず、最初からビジネスセンタ内のパーソナルコンピュータを利用する場合と同様な問題が発生する。
【００１０】
ホテルのビジネスセンタに設置されているパーソナルコンピュータを利用するケースでは、当該パーソナルコンピュータは、所有権がホテル側にあり、多数の宿泊者に共用されるものである点などで、宿泊者から見た場合、セキュリティ性に不安が残る。
【００１１】
例えば、前記ストレージサーバがパスワードを用いたユーザ認証を行うものであるケースや、ＶＰＮによるリモートアクセスを行うケースなどでは、パスワードなどの機密性の高い情報をパーソナルコンピュータに入力する必要があるため、ユーザ自身に所有権がなく、なおかつ共用される当該パーソナルコンピュータを介して機密性の高い情報が漏洩する可能性があるからである。もちろん、受信または送信した電子メールや添付ファイルの内容が漏洩する可能性もある。これらの情報の漏洩は、宿泊者が削除することを忘れたり、削除は行っても（論理的にはメーラなどのアプリケーションにより、削除したものとして扱われていても）一般的なパーソナルコンピュータの機構上、削除したファイルの内容が物理的にはハードディスクなどに残存すること等に起因して発生し得る。
【００１２】
なお、ストレージサーバを利用しないケースや、リモートアクセスを行わないケースでも、電子メールや添付ファイルの内容が漏洩する可能性がある点は同じである。
【００１３】
【課題を解決するための手段】
かかる課題を解決するために、第１の本発明では、送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバ（例えば、仮想プリントサーバ２０など）に、送信元ユーザ（例えば、ユーザＵ１など）から宛先ユーザ（例えば、ユーザＵ２など）へ送信した保管対象データ（例えば、電子メールＭＥ１やその添付ファイルＦ１など）を保管するための個別ユーザ用データ保管部（例えば、メールボックス部６４など）を設ける情報保管システムであって、前記宛先ユーザを収容する収容施設（例えば、ホテルＨＴ１，ＨＴ２など）側に配置される収容施設側システム（例えば、ホテルサーバ２４など）を有し、当該収容施設側システムは、前記宛先ユーザを当該収容施設に収容しているか否かを管理する収容管理部（例えば、宿泊管理部４３など）を備え、前記リモート保管サーバは、前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理するための保管管理部（例えば、メールボックス管理部６３など）を備え、前記収容施設側システムまたはリモート保管サーバは、前記収容施設が宛先ユーザを収容している期間に対応する有効期間（例えば、サービス期間ＳＴ１，ＳＴ２など）のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名（例えば、ＡＣ２１など）を発行するユーザ名発行部（例えば、アカウント発行部５５など）を有することを特徴とする。
【００１４】
また、第２の本発明では、送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を用いる情報保管サービス方法であって、前記宛先ユーザを収容する収容施設側に配置される収容施設側システムが、収容管理部を用いて、前記宛先ユーザを当該収容施設に収容しているか否かを管理し、前記リモート保管サーバでは、保管管理部が、前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理し、前記収容施設側システムまたはリモート保管サーバに設けられたユーザ名発行部が、前記収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行することを特徴とする。
【００１５】
これにより、前記有効期間のあいだ期間限定ユーザ名を用いて宛先ユーザと個別ユーザ用データ保管部を関連付けることができ、宛先ユーザに宛てた保管対象データの送信が可能となる。
【００１６】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる情報保管システム及び情報保管サービス方法を、インターネット上に配置された仮想プリントサーバを含む通信システムに適用した場合を例に、実施形態について説明する。
【００１７】
（Ａ−１）実施形態の構成
本実施形態の通信システム１０の全体構成例を図１に示す。
【００１８】
図１において、当該通信システム１０は、インターネット１１と、ＬＡＮ（ローカルエリアネットワーク）１２，１３と、前記仮想プリントサーバ２０と、ＭＭＫ（マルチメディアキオスク）端末２１と、パソコン（パーソナルコンピュータ）２２、２８，２９と、フロント端末２３と、ホテルサーバ２４と、テレビ端末２５と、電話端末２６と、プリント端末２７とを備えている。
【００１９】
このうちＬＡＮ１２は、ホテルＨＴ１の内部に構築されたＬＡＮであり、ＬＡＮ１３は、ＨＴ１とは別のホテルＨＴ２の内部に構築されたＬＡＮである。図１上でＬＡＮ１２に接続するように図示した構成要素２３〜２７は、ＬＡＮ１２内に含まれる構成要素である。本実施形態において、ユーザＵ２はホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとする。ただしユーザＵ２は、ホテルＨＴ１などの宿泊客となる以前に仮想プリントサーバ２０の会員であり、仮想プリントサーバ２０にその個人情報を申告した上で会員登録を行っている。ただしユーザＵ２は、一般的な仮想プリントサービスの提供を受けるために登録している会員とは別個に、本実施形態で述べるサービスだけを受けることを目的として会員登録を行っている者であってもよい。
【００２０】
図１上は省略しているが、ホテルＨＴ２側のＬＡＮ１３にも、構成要素２３〜２７と同様な構成要素が含まれる。なお、ＬＡＮ１２，１３には、図示しないファイアウオール、ルータ、ＤＮＳサーバなどが含まれていてよいことは当然である。
【００２１】
ＬＡＮ１２内の構成要素２３〜２７のうち、フロント端末２３は、ホテルＨＴ１のフロント業務に従事する従業員ＣＬ１などに操作される情報処理装置で、ユーザＵ２の宿泊の予約、チェックイン、チェックアウトなどの宿泊管理は、このフロント端末２３を介して入力される情報に基づいて実行される。
【００２２】
フロント端末２３は、例えば、図４に示す内部構成を有するものであってよい。
【００２３】
なお、フロント端末２３以外の構成要素２１，２２，２５〜２７の内部構成も、図示したレベルの詳細さでみる限り、図４と同じであってよい。
【００２４】
（Ａ−１−１）フロント端末の内部構成例
図４において、当該フロント端末２３は、通信部３０と、制御部３１と、操作部３２と、表示部３３と、記憶部３４とを備えている。
【００２５】
このうち通信部３０はＬＡＮ１２を経由した通信のために機能する部分である。通信部３０の主な通信相手はホテルサーバ２４なので、ＬＡＮ１２内の通信だけを行うもので足りるが、必要に応じて、インターネット１１経由の通信を行えるようにしてもよい。
【００２６】
操作部３２は、ホテルＨＴ１の従業員ＣＬ１が操作してフロント端末２３に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。ただし図４にテレビ端末２５を示したものとみる場合には、操作部３２にはテレビ端末２５を操作するためのリモコン送信機などが該当する。同様に、電話端末２６を示したものとみる場合には電話端末２６上に配列されたボタンが、プリント端末（プリンタ）２７を示したものとみる場合には、プリント端末２７上に配列されたボタンが、当該操作部３２に該当し得る。
【００２７】
また、図４にパソコン２２を示したものとみる場合には、操作部３２を操作するのはユーザＵ１（または、ユーザＵ２）であり、ＭＭＫ端末２１，テレビ端末２５，電話端末２６，またはプリント端末２７を示したものとみる場合には、操作部３２を操作するのは、通常、ユーザＵ２である。ここで、ユーザＵ１は、ホテルＨＴ１に宿泊するユーザＵ２に宛てて電子メールＭＥ１を送信するユーザを示している。当該電子メールＭＥ１には添付ファイルＦ１が添付されているものであってよい。
【００２８】
表示部３３は、フロント端末２３が搭載するアプリケーションソフト（例えば、メーラやＷｅｂブラウザなど）の機能に応じて画面表示を行うディスプレイ装置に対応する部分である。図４にフロント端末２３以外の構成要素２１，２２，２５〜２７を示したものとみる場合、表示部３３の具体的な構成や、表示を目視する主体が変化し得る点は、前記操作部３２の場合と同様であるのは当然である。
【００２９】
制御部３１は、ハードウエア的には当該フロント端末２３のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）、前記メーラ、Ｗｅｂブラウザなどの各種プログラムに相当する部分である。
【００３０】
記憶部３４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記メーラやＷｅｂブラウザなどのプログラムファイルもこのようなファイルの一つであるから、メーラやＷｅｂブラウザなども、その物理的な実体は、この記憶部３４に位置する。
【００３１】
なお、本実施形態の構成上、ユーザＵ２がホテル（例えば、ＨＴ１）に宿泊する際には、ユーザ認証を行って、なりすましを検知、防止できることが望ましい。なりすましの検知のためには、対面で身分証明書（例えば、運転免許証など）の提示を求めること等も考えられるが、例えば、次のような方法を用いることも簡便である。
【００３２】
すなわち、フロント端末２３側へ予め仮想プリントサーバ２０の会員（当然、Ｕ２も含む）の公開鍵（ここでは、ユーザＵ２の公開鍵をＰＫ２とする）を配送しておき、ユーザＵ２がホテルＨＴ１の宿泊を予約するときには、その旨の電子メール（この電子メールは、例えば、Ｗｅｂアクセスなどに置換可能）を前記公開鍵ＰＫ２に対応する自身の秘密鍵（ここでは、ＶＫ２とする）で暗号化した上で送信する構成とする。秘密鍵ＶＫ２を使用できるのはユーザＵ２のみであるから、予約のための当該電子メールを公開鍵ＰＫ２を用いて正しく復号できれば、その電子メールを送信した者が、ユーザＵ２自身であることをフロント端末２３側で検証することができる。
【００３３】
さらに、当該検証の結果がＯＫであれば、固有の文字列（宿泊用パスワードＳＪ２）を記述した電子メールを公開鍵ＰＫ２で暗号化した上でフロント端末２３（または、仮想プリントサーバ２０）側からユーザＵ２へ返送するようにすれば、その電子メールを受信したユーザＵ２は前記秘密鍵ＶＫ２でこの電子メールを復号して当該宿泊用パスワードＳＪ２を取得することができるから、宿泊のため実際にホテルＨＴ１のフロントへ出向いたときには、従業員ＣＬ１に、自身の氏名などとともに当該宿泊用パスワードＳＪ２を申告するようにする。
【００３４】
その後、宿泊期間中に外出先から戻ったユーザＵ２がホテルＨＴ１における自身の客室の鍵をフロントから受け取るとき等にも、適宜、前記宿泊用パスワードＳＪ２を申告させて、ユーザ認証を行うようにしてもよい。
【００３５】
ただし従業員ＣＬ１に口頭で申告する替わりに、自動的に当該宿泊用パスワードＳＪ２の申告を行うことができる機構（例えば、いわゆるＩＣタグなど）を利用するようにしてもよい。これにより従業員ＣＬ１を介して宿泊用パスワードＳＪ２の漏洩などが起きる危険性も排除できる。
【００３６】
当該宿泊用パスワードＳＪ２は、１つの宿泊期間中のみ有効な一種のワンタイムパスワードとすることが望ましい。
【００３７】
ユーザＵ２に関するパスワードとしては、仮想プリントサーバ（仮想プリントサービス）２０の会員としてのパスワード（ここでは、ＰＷ２とする）もあるが、仮想プリントサービスの会員としてのパスワードＰＷ２は基本的に恒久的なパスワードであるため、宿泊用パスワードＳＪ２をワンタイムパスワードとして、パスワードＰＷ２と使い分けることで、いっそう強固なセキュリティ性を確保することも可能になる。
【００３８】
例えば、テレビ端末２５，電話端末２６，プリント端末２７を使用するときには、事前に各構成要素２５〜２７に対し、当該宿泊用パスワードＳＪ２を入力させてユーザ認証を行うようにするとよい。
【００３９】
ここで、テレビ端末２５は、基本的に通常のテレビ受像機としての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容（後述するように、データ形式は変換する）を画面表示する必要がある。必要に応じて、例えば、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を処理する機能を当該テレビ端末２５に搭載してもよい。
【００４０】
ユーザＵ２がテレビ端末２５に電子メールＭＥ１や添付ファイルＦ１の内容（必要に応じて、メールヘッダの情報（例えば、送信元のメールアドレスなど）も含む）を画面表示させるには、その画面表示のもとになるデータを保管しているサーバ（仮想プリントサーバ２０でもよいが、本実施形態ではホテルサーバ２４とする）に対し、アカウントを送信する必要があるが、アカウントは秘密の情報ではないし、ホテルの客室は、ユーザＵ２の不在のときに、例えば、清掃作業員が入室したり、ホテルの従業員が入室する可能性もあるため、確実に、ユーザＵ２以外の者が電子メールＭＥ１や添付ファイルＦ１の内容を知ることができないようにするには、アカウントのほかに秘密の情報を利用してユーザ認証を行う構成とすることが望ましい。この秘密の情報として、上述した宿泊用パスワードＳＪ２を用いることが考えられる。
【００４１】
テレビ端末２５の所有権はホテルＨＴ１側にある点や、ユーザＵ２のあとには他の宿泊客が当該テレビ端末２５を利用する点などを考慮すると、当該テレビ端末２５はセキュリティ上、上述したビジネスセンタ内に設置されているパーソナルコンピュータに類似した位置づけになるとみることができるから、恒久的なパスワードＰＷ２を当該テレビ部端末２５に入力することは好ましくないといえるが、ワンタイムパスワードとしての宿泊用パスワードＳＪ２を入力するなら、そのような弊害は軽減または解消される。
【００４２】
また、前記電話端末２６は基本的に通常の電話機としての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容を音声出力してユーザＵ２に聴取させる必要がある。ただし通常の電話端末は公衆電話網に接続されるものであるため、図示したようにＬＡＮ１２に直接、接続するには、ＬＡＮ１２内の通信プロトコルとしてＯＳＩ参照モデルのネットワーク層ではＩＰプロトコルを用い、なおかつ、当該電話端末２６をＶｏＩＰ対応のＩＰ電話機などとする必要がある。もちろん、ＶｏＩＰゲートウエイやＩＰ−ＰＢＸを経由すれば、ＶｏＩＰ非対応の通常の電話端末をＬＡＮに接続することも可能である。
【００４３】
アカウントや宿泊用パスワードＳＪ２が、数字以外の文字を含む文字列である場合、電話端末２６を介して当該アカウントや宿泊用パスワードＳＪ２を入力することは容易ではないと考えられるが、例えば、合成音声などによるガイダンスを利用すれば必ずしも不可能ではない。
【００４４】
また、電話端末２６は必ずしもホテルＨＴ１の客室内に設置されたものである必要はないので、前記ビジネスセンタ内に設置された電話端末や、ホテルＨＴ１の外に設置された電話端末を利用することも可能である。
【００４５】
なお、電話端末２６がＩＰ電話機の場合、その外観は必ずしも一般的な電話機に類似したものとは限らず、例えば、通常のパーソナルコンピュータにＩＰ電話用のソフトウエアを搭載することによってＩＰ電話機の機能が実現されること等も少なくない。そのようなケースでは、ユーザＵ２がアカウントや宿泊用パスワードＳＪ２を入力するためのユーザインタフェース（例えば、キーボード、マウス、画面など）は十分に用意することができるから、入力の困難性は緩和することが可能である。
【００４６】
前記プリント端末２７は、基本的に通常のプリンタとしての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容を印刷出力する必要がある。プリント端末２７は一般的に、アカウントや宿泊用パスワードＳＪ２を入力するためのユーザインタフェースに乏しい点で、前記電話端末２６と類似しているが、ホテルＨＴ２内でユーザＵ２が利用するプリント端末２７は、ビジネスセンタ内に設置されたものであるため、その近傍にはパーソナルコンピュータも存在する。したがって、当該パーソナルコンピュータとプリント端末２７を連携させ、パーソナルコンピュータのユーザインタフェースを用いてアカウントや宿泊用パスワードＳＪ２を入力させることにより、プリント端末２７から電子メールＭＥ１や添付ファイルＦ１の内容の印刷出力を行う構成としてもよい。ただし当該プリント端末２７が、情報をタッチパネル等から入力でき、サーバと通信を行うことができ、印刷機とのインタフェースを持つ情報端末機能付きのＭＦＰ（複合機）をはじめとする情報処理装置である場合には、このような連携は必要ない。
【００４７】
なお、仮想プリントサーバ２０は、多様なプリンタに対応する多様なプリンタドライバを搭載しているため、当該プリント端末２７が、どのような機種のプリンタ製品であっても、それに適合するデータ形式に電子メールＭＥ１やその添付ファイルＦ１を変換することができる。
【００４８】
また、パソコン２８は、ホテルＨＴ１のビジネスセンタなどに設置されたパーソナルコンピュータであり、パソコン２９は、ホテルＨＴ１の客室からＬＡＮ１２に接続するパーソナルコンピュータである。本実施形態の構成上、基本的に、当該パソコン２９は存在しなくてもよいが、ユーザＵ２がノート型パソコンなどを客室に持ち込んで使用するケースや、ホテルＨＴ１が客室にパソコンを設置してあるケースなどに、当該パソコン２９が存在する。
【００４９】
パソコン２８や２９を使用すれば、ユーザＵ２は、後述するステップＳ３２やＳ３５などでデータ形式を変換するまえの電子メールＭＥ１やその添付ファイルＦ１を取り扱い、閲覧し、必要ならば編集なども行うことができるので、利便性が高まる。
【００５０】
前記ＭＭＫ端末２１は、コンビニエンスストアや駅など、多くの人が集まる街中の随所に設置される情報処理装置で、ユーザ（例えば、Ｕ２）の操作に応じて仮想プリントサーバ２０に対し該当文書（例えば、電子メールＭＥ１，添付ファイルＦ１など）を転送するように要求し、転送されてきた文書を一時的に記憶して印刷出力するために利用される。印刷出力を行うための印刷機能は、ＭＭＫ端末２１自体が搭載している場合と、ＭＭＫ端末２１の近傍に設置された外部のプリンタ装置の印刷機能を利用する場合がある。
【００５１】
したがって、ＭＭＫ端末２１は、前記プリント端末２７とほぼ同等な装置であるとみることができるが、プリント端末２７がホテルＨＴ１のビジネスセンタの内部に設置されたものであるのに対し、ＭＭＫ端末２１は、ホテルＨＴ１の外部に設定されている点が異なる。
【００５２】
一方、当該フロント端末２３とＬＡＮ１２経由で通信するホテルサーバ２４は、例えば、図３に示す内部構成を有するものであってよい。
【００５３】
（Ａ−１−２）ホテルサーバの内部構成例
図３において、当該ホテルサーバ２４は、通信部４０と、制御部４１と、記憶部４２と、宿泊管理部４３と、データ格納部４４とを備えている。
【００５４】
このうち通信部４０は前記通信部３０に対応し、制御部４１は前記制御部３１に対応し、記憶部４２は前記記憶部３４に対応するので、その詳しい説明は省略する。
【００５５】
ただし制御部４１は、前記フロント端末２３の制御部３１と異なり、必要が生じたときに、通信部４０を介して前記仮想プリントサーバ２０と通信する機能を備えている。
【００５６】
前記宿泊管理部４３は、ホテルＨＴ１の客（例えば、ユーザＵ２）による宿泊の予約、チェックイン、チェックアウトなどに関する情報（宿泊管理情報）を管理する部分で、必要に応じて、これらの宿泊管理情報を仮想プリントサーバ２０へ通知する。宿泊管理部４３内で、当該宿泊管理情報は、予約データベースＤＢ２にまとめられて管理される。当該宿泊管理部４３の機能は、ホテルの予約を管理するホテル予約システムに対応する。
【００５７】
本実施形態は、仮想プリントサーバ２０内に一時的なメールボックスを用意し、当該メールボックスを介した電子メールの送受信（主として、受信）、および受信した電子メールやその添付ファイルの内容を、データ形式を変換して、宿泊客（ここでは、ユーザＵ２）に提供することを内容とするサービスに特徴を有し、このサービスが行われる期間（サービス期間）は、基本的に、仮想プリントサーバ２０のある会員（例えば、ユーザＵ２）が、あるホテル（例えば、ＨＴ１）に宿泊している期間（チェックインからチェックアウトまで）であり、この期間を基本サービス期間とする。
【００５８】
ただしここでは、ユーザＵ２がホテルに対して宿泊の予約を行う場合には、予約の受付が行われてからチェックインが行われるまでの期間（第１拡張期間）も包含するように、当該サービス期間を拡張するものとする。同様に、チェックアウトが行われたあと所定の期間（第２拡張期間）も包含するように、当該サービス期間を拡張するものとする。チェックイン前やチェックアウト後にも、当該ユーザＵ２宛ての電子メールが届く可能性があるからである。
【００５９】
したがって、サービス期間をＳＴ１とし、そのサービス期間に含まれる第１拡張期間をＳＴ１１、基本サービス期間をＳＴ１２，第２拡張期間をＳＴ１３とすると、次の式（１）の関係が成立する。
【００６０】
ＳＴ１＝ＳＴ１１＋ＳＴ１２＋ＳＴ１３ …（１）
また、ここでは、ユーザＵ２がホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとしているが、当該ホテルＨＴ２に関するサービス期間ＳＴ２に関しても、第１拡張期間をＳＴ２１、基本サービス期間をＳＴ２２，第２拡張期間をＳＴ２３とすると、次の式（２）の関係が成立する。
【００６１】
ＳＴ２＝ＳＴ２１＋ＳＴ２２＋ＳＴ２３ …（２）
ホテルＨＴ１に対する第２拡張期間ＳＴ１３とホテルＨＴ２に対する第１拡張期間ＳＴ２１（または、基本サービス期間ＳＴ２２）を連続的に結合することができる。
【００６２】
なお、ユーザＵ２が予約をすることなくホテル（ＨＴ１またはＨＴ２）に宿泊することもあり得るが、その場合には、前記第１拡張期間ＳＴ１１，ＳＴ２１は存在しないことは当然である。さらに、基本サービス期間ＳＴ１２，ＳＴ２２は、ユーザＵ２のそのホテルに対する宿泊日数に対応して動的に変化することは当然である。
【００６３】
第１拡張期間ＳＴ１１、ＳＴ２１や第２拡張期間ＳＴ１３，ＳＴ２３も動的に変化させてもよいが、ここでは、一定の固定期間を設定するものとする。第１拡張期間（例えば、ＳＴ１１）を示す固定期間は、予約の受付が行われた日時から第１拡張期間ＳＴ１１が開始するケースで最大値となるが、予約の受付からチェックインまでの期間が長い場合などには、必ずしも予約の受付が行われた日時から開始させず、チェックインが予定されている日時の所定期間前（例えば、２週間前）から第１拡張期間ＳＴ１１が開始させるようにしてもよい。
【００６４】
また、第１拡張期間を示す固定期間は、すべてのホテルに関して統一してもよく、ホテルごとに相違させてもよい。
【００６５】
第２拡張期間ＳＴ１３，ＳＴ２３を示す固定期間のほうには第１拡張期間ＳＴ１１，ＳＴ２１のような制約はないため、どのように設定することも基本的に自由であるが、一例としては、１週間程度であってよい。ユーザＵ２がホテルＨＴ１，ＨＴ２に連続して宿泊する場合、通常は、ホテルＨＴ１をチェックアウトした当日、またはその翌日には、ホテルＨＴ２にチェックインするものと考えられるので、第２拡張期間ＳＴ１３が１週間程度あれば、確実に、次の基本サービス期間ＳＴ２２（または第１拡張期間ＳＴ２１）と連続的に結合することができる。
【００６６】
同じユーザ（ここでは、Ｕ２）に対する第２拡張期間ＳＴ１３が終了する前に、次の第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が開始した場合には、その時点で、当該第２拡張期間ＳＴ１３は終了し、第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が優先されるようにするとよい。すでにチェックアウトしたホテル（例えば、ＨＴ１）に関する第２拡張期間ＳＴ１３よりも、現に宿泊しているホテル（例えば、ＨＴ２）に関する基本サービス期間ＳＴ２２（または第１拡張期間ＳＴ２１）を優先したほうが、電子メールの宛先であるユーザＵ２にとっても、電子メールの送信元であるユーザ（例えば、Ｕ１）にとっても、有利であると考えられるからである。
【００６７】
なお、宿泊スケジュールにも依存するが、２つのホテルＨＴ１，ＨＴ２に連続的に宿泊する場合、最初のホテルＨＴ１に関する基本サービス期間ＳＴ１２が終了すると同時、またはそれ以前に、次のホテルＨＴ２に対する第１拡張期間ＳＴ２１が開始することが多いものと考えられるが、そのようなケースでは、最初のホテルＨＴ１に関する第２拡張期間ＳＴ１３は存在せず、基本サービス期間ＳＴ１２の終了後ただちに、次のホテルＨＴ２に関する第１拡張期間ＳＴ２１が開始する形になる。この場合にはまた、最初のホテルＨＴ１に関する基本サービス期間ＳＴ１２と次のホテルＨＴ２に関する第１拡張期間ＳＴ２１が重複することも多いが、重複した場合には、重複している期間に関して、最初のホテルＨＴ１に関する基本サービス期間ＳＴ２２を優先するほうが望ましい。
【００６８】
このような期間のあいだ前記サービスを提供するために使用されるメールボックスの本体は一貫して仮想プリントサーバ２０側に存在するため、前記宿泊管理部４３が管理している宿泊管理情報（例えば、予約の受付が行われた日時、予約の内容、実際にチェックインが行われた日時、チェックアウトが行われた日時など）を、ホテルサーバ２４から、仮想プリントサーバ２０へ通知する必要がある。各ホテル（例えば、ＨＴ１，ＨＴ２）から届く当該宿泊管理情報に応じて、仮想プリントサーバ２０は、メールボックスの生成や削除、転送先の変更などの制御を実行することになる。
【００６９】
ホテルサーバ２４から仮想プリントサーバ２０へ宿泊管理情報を届けるための通信プロトコルとしては様々なものを利用することができるが、例えば、ＦＴＰプロトコルやＨＴＴＰプロトコルを利用することができる。また、ＳＯＡＰプロトコルを用いるＷｅｂサービスを活用してもよい。
【００７０】
前記データ格納部４４は主として、後述するように、電子メールＭＥ１やその添付ファイルＦ１からデータ形式を変換して得られたデータ（出力用データ）を格納する部分で、メールボックス部６４（図２参照）と同様、（期限付きアカウント名（メールボックスＩＤ）で区別して）各ユーザ（例えば、Ｕ２）ごとに設けられ、その物理的な実体は、記憶部４２上に確保された記憶領域のうちの１つであり、論理的には、フォルダ（ディレクトリ）の１つである。ここで、電子メールＭＥ１をテレビ端末２５のためのデータ形式に変換して得られる出力用データをＯＭ１とし、添付ファイルＦ１をテレビ端末２５のためのデータ形式に変換して得られる出力用データをＯＦ１とする。
【００７１】
同様に、電子メールＭＥ１を電話端末２６のためのデータ形式に変換して得られる出力用データをＯＭ２とし、添付ファイルＦ１を電話端末２６のためのデータ形式に変換して得られる出力用データをＯＦ２とし、電子メールＭＥ１をプリント端末２７のためのデータ形式（ＭＭＫ端末２１のためのデータ形式も同じであってよい）に変換して得られる出力用データをＯＭ３とし、添付ファイルＦ１をプリント端末２７のためのデータ形式に変換して得られる出力用データをＯＦ３とする。
【００７２】
ここで、メールボックスＩＤとは、個々の前記メールボックス部（例えば、６４）を一意に識別するために付与される識別情報である。前記期限付きアカウント名と当該メールボックスＩＤは、１対１の対応関係さえ確保されていれば必ずしも同じ値である必要はないが、管理の効率化のためには同じ値とすることも望ましい。
【００７３】
なお、前記パソコン２８や２９を使用するケースに備え、データ形式を変換するまえの電子メールＭＥ１やその添付ファイルＦ１も、当該データ格納部４４に格納しておくとよい。
【００７４】
前記仮想プリントサーバ２０は例えば図２に示す内部構成を備えたものであってよい。
【００７５】
（Ａ−１−３）仮想プリントサーバの内部構成例
図２において、当該仮想プリントサーバ２０は、通信部５０と、制御部５１と、記憶部５２と、メールサーバ部５３と、ユーザ管理部５４と、アカウント発行部５５と、アカウント蓄積部５６と、アカウント比較部５７と、宿泊スケジュール管理部５８と、データ変換部５９と、転送アドレス登録部６０と、転送制御部６１と、通知メール生成部６２と、メールボックス管理部６３と、メールボックス部６４とを備えている。
【００７６】
このうち通信部５０は前記通信部４０に対応し、制御部５１は前記制御部４１に対応し、記憶部５２は前記記憶部４２に対応するので、その詳しい説明は省略する。
【００７７】
ただし構成要素５３〜６４の多くは、機能上は、当該制御部５１に含まれ、物理的な実体は、記憶部５２に存在するものである。
【００７８】
構成要素５３〜６４のうちメールボックス部６４は、仮想プリントサーバ２０内に一時的に用意される上述したメールボックスに対応する部分である。図２上では記憶部５２の外に図示しているが、当該メールボックス部６４の物理的な実体は、記憶部５２上に確保された記憶領域のうちの１つであり、論理的には、フォルダ（ディレクトリ）の１つである。
【００７９】
前記サービス期間（必要に応じて、第１拡張期間なども含む）の開始にともなって、個々のユーザ（ここでは、Ｕ２）のためのメールボックス部６４が生成され、サービス期間（最後の第２拡張期間なども含む）の終了にともなって当該ユーザＵ２のためのメールボックス部６４が削除される。このような生成や削除を行うのは、前記メールボックス管理部６３である。一般的なメールボックスの管理は、メールサーバ部５３の役割であるが、本実施形態では、当該メールボックス管理部６３が、ホテルサーバ２４から供給される前記宿泊管理情報に応じて、メールボックス部６４の生成や削除を行う。
【００８０】
メールサーバ部５３は、メールサーバ機能に対応する部分である。本実施形態で電子メールＭＥ１はインターネット１１上を転送されるため、メール配送用のプロトコルはＳＭＴＰである。着信した電子メール（例えば、ＭＥ１）を当該メールボックス部６４から取り出すためのプロトコルとしては、ＰＯＰ３やＩＭＡＰ４を利用するのが一般的であるが、本実施形態の構成上、ユーザＵ２が直接、仮想プリントサーバ２０にログインして当該メールボックス部６４から電子メールなどを取り出すことは基本的に行わず、電子メールや添付ファイルは出力用データに変換されたあと、ホテルサーバ２４のデータ格納部４４で保存され、ユーザＵ２が電子メールや添付ファイルの内容を知りたいときには、前記テレビ端末２５などを介して当該データ格納部４４から出力用データを取り出す手順となる。このときの取り出しでは、後述する期限付きアカウント名などを用いてユーザ認証を行うため、必要に応じて、ＰＯＰ３やＩＭＡＰ４に対応したプロトコルを利用することもできる。
【００８１】
ただし、ユーザＵ２がホテルの外部に設置されているＭＭＫ端末２１から前記出力データの出力（印刷出力や画面表示出力）を行う場合には、ホテルサーバ２４などを経由せずに、ユーザＵ２が直接、仮想プリントサーバ２０にログインして当該メールボックス部６４から電子メールなど（例えば、前記出力用データＯＭ３，ＯＦ３）を取り出す形になる。この取り出しでは、ＰＯＰ３やＩＭＡＰ４などを利用することが可能である。
【００８２】
したがって、当該メールサーバ部５３は、ＳＭＴＰサーバやＰＯＰサーバなどに相当する機能を備えることになる。
【００８３】
すなわち、電子メールＭＥ１（およびその添付ファイルＦ１）はＳＭＴＰプロトコルにしたがってインターネット１１上を配送されてきて、ユーザＵ２のための前記メールボックス部６４に着信し、出力時（例えば、ＭＭＫ端末２１からの印刷出力や画面表示出力などの際）には、ＰＯＰ３などの取り出し用プロトコルにしたがって、メールＭＥ１や添付ファイルＦ１のデータ形式を変換した後のデータが、前記ホテルサーバ２４などへ転送される手順となる。
【００８４】
ユーザ管理部５４は、当該仮想プリントサーバ２０の会員（ユーザＵ２もその一人）に関する会員情報を管理する部分である。
【００８５】
仮想プリントサーバ２０からみた会員は大きく２つに分けることができる。その１つは、ホテルＨＴ１やＨＴ２のようなホテル会員であり、もう１つは、ユーザＵ２のような個人会員である。個人会員に関して当該ユーザ管理部５４が管理する会員情報は、いわゆる個人情報である。当該個人情報には様々なものがあり得るが、例えば、個人会員の住所、氏名、ユーザＩＤ、パスワード（前記ＰＷ２）、電子メールアドレスなどが含まれ得る。そのユーザに対し、すでに期限付きアカウント名を発行している場合には、その期限付きアカウント名も、当該個人情報の一部としてユーザ管理部５４で管理するようにしておくとよい。また、各ホテルサーバ２４などから供給される前記宿泊管理情報も、個人会員ごとに整理されて当該ユーザ管理部５４に格納するものであってよい。
【００８６】
ホテル会員の会員情報も基本的に個人会員の会員情報と同じであってよく、ホテルの名称、所在地、ホテルＩＤ（ユーザＩＤに対応）などが、ユーザ管理部５４で管理される。ホテル会員に関するこれらの会員情報は、ユーザ管理部５４に搭載されるホテルデータベースＤＢ１に格納されるものとする。前記サービス期間ＳＴ１，ＳＴ２の具体値なども、ホテルごとに整理して当該ホテルデータベースＤＢ１に格納しておくことができる。
【００８７】
このうちユーザＩＤは、仮想プリントサーバ２０内において各個人会員を一意に識別するための識別情報であり、ホテルＩＤは、各ホテル会員を一意に識別するための識別情報である。
【００８８】
また、パスワードは、仮想プリントサーバ２０内に保管されたデータ（例えば、前記電子メールＭＥ１，添付ファイルＦ１や、その出力用データ）をＭＭＫ端末２１などから出力する際に各個人会員に入力させる情報である。
【００８９】
また、電子メールアドレスは、仮想プリントサーバ２０が提供する仮想プリントサービス以外でも使用される各個人会員の電子メールアドレスのことである。
【００９０】
ここで、前記ユーザＵ２の電子メールアドレスは、ＡＤ２とする。
【００９１】
ユーザＵ２の氏名が例えば「山田太郎」である場合、当該電子メールアドレスＡＤ２の具体的な値は、「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｎｅ．ｊｐ」などであってよい。
【００９２】
この電子メールアドレスの値のうち、＠マークより左側に記述される文字列をアカウント名と呼び、＠より右側に記述される文字列をドメイン名と呼ぶ。ドメイン名は階層構造を持っており、この例では、「ｊｐ」が最も上位（ただし階層構造の最上位にあたる根には名前が付与されていない。この「ｊｐ」は、根の下位に位置するいくつかのドメインのなかの１つである）の階層に属するトップレベルドメイン（ＴＬＤ（この例では、ｃｃＴＬＤ））であり、「ｎｅ」は当該「ｊｐ」に包含され（すなわち、当該「ｊｐ」の下位にあたる）、「ｄｄｄ」は当該「ｎｅ」に包含される関係となる。ここで、「ｎｅ」は組織の分類を示し、「ｄｄｄ」はその分類に属する具体的な組織の名称（組織名）を示している。必要ならば、組織名の下位にさらに階層を追加することで、１つの組織内に複数のサブドメインを設定することもできる。階層の数に制約はないため、追加する階層の数は複数であってもよく、サブドメインのなかにさらに複数のサブドメインを設定することもできる。
【００９３】
アカウント名は通常、ＩＳＰ（あるいは、企業内のイントラネットの管理者）などが自ドメイン内で電子メールユーザ（ここでは、ユーザＵ２）を識別するために用いる文字列であり、どのような文字列を許すかは、基本的に、電子メールユーザとＩＳＰなどの関係において決まり、通常、ＩＳＰなどは、そのドメイン（ここでは、「ｄｄｄ．ｎｅ．ｊｐ」）の内部で、当該電子メールユーザを一意に識別することができるアカウント名でさえあれば、ユーザＵ２が希望した文字列をそのユーザのアカウント名として登録する。当該アカウント名は、ユーザＵ２がＩＳＰのメールサーバなどに確保された自身のメールボックスに着信した電子メールを取り出す際などに利用される。
【００９４】
したがって、アカウント名自体に、ドメインと同様な階層構造を持たせることも、ＩＳＰなどの自由であるが、一般的にはそのようなことは行われていない。
【００９５】
ＲＦＣの規格（ＲＦＣ８２１）により、＠マークの左右（すなわち、アカウント名とドメイン名）の文字数は、最大、６４文字に制限されているが、メールサーバ側のＯＳの種類などにより、実際のＩＳＰなどでは、当該６４文字よりはるかに少ない文字数に制限（例えば、アカウント名を８文字以内に制限）することもある。ログインの際の文字数などは、ＯＳの仕様によって決まっているからである。
【００９６】
アカウント発行部５５は、ユーザ管理部５４に登録されている当該電子メールアドレスＡＤ２をもとに、仮想プリントサーバ２０の内部においてユーザ（例えば、Ｕ２）がいずれかのホテル会員に宿泊（予約なども含む）を行っている期間にのみ使用する一時的なアカウント名（期限付きアカウント名）を発行する部分である。期限付きアカウント名の発行は、仮想プリントサーバ２０に会員登録する際に行ってもよく、すでに会員登録を行ったユーザが発行を要求したときに行うようにしてもよい。なお、アカウントという用語には課金の意味が含まれているが、ここでは必ずしも、期限付きアカウント名を利用してユーザＵ２に課金を行う必要はなく、本実施形態で説明するサービスは無料奉仕として提供するものであってよい。
【００９７】
この期限付きアカウント名には、ユーザＵ２自身やユーザＵ２宛てに電子メール（例えば、ＭＥ１）を送信するユーザ（例えば、Ｕ１）が記憶しやすい文字列であることが求められる。
【００９８】
記憶しやすい文字列とするには、ユーザＵ２自身や、ユーザＵ２に何回も電子メールを送信したことのあるユーザ（例えば、Ｕ１）が慣れている前記電子メールアドレスＡＤ２をもとに、当該期限付きアカウント名の文字列を決めることが有効である。例えば、前記電子メールアドレスＡＤ２の＠マークを、単なる区切り記号として使用されるドット（すなわち、「．」）に置換した文字列である「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」を、当該期限付きアカウント名として利用することも望ましい。必要に応じて、＠マークをドットと置換するのではなく、単に除去して得られる文字列（「ｔａｒｏｕ．ｙａｍａｄａｄｄｄ．ｎｅ．ｊｐ」）などを期限付きアカウント名として利用してもよい。
【００９９】
ここでは、他の記号に置換したり、単に除去したりして電子メールアドレスＡＤ２内の＠マークを除いているが、送信元のメールサーバ（図示せず）などは、＠マークから右側の文字列をドメイン名と解釈してＤＮＳサーバに対する問い合わせを行い、通信相手となるメールサーバ（例えば、仮想プリントサーバ２０またはメールサーバ部５３）を指定するためのＩＰアドレスを取得するが、もし＠マークを残したまま、電子メールアドレスＡＤ２を期限付きアカウント名として利用すれば、当該期限付きアカウント名を含む新たな電子メールアドレスＡＤ２１内には、＠マークが２つ含まれることとなり、ＤＮＳサーバへの問い合わせ等が正常に行えず、送信元のユーザ（例えば、Ｕ１）へエラーメールの返送などが行われる可能性があるからである。
【０１００】
前記仮想プリントサーバ２０のドメイン名が例えば「ｖｉｒｔｕａｌｐ．ｃｏｍ」であるとすると、前記期限付きアカウント名を含む電子メールアドレスＡＤ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ＠ｖｉｒｔｕａｌｐ．ｃｏｍ」となる。
【０１０１】
このようにして、アカウント発行部５５は、ユーザＵ２やＵ１に記憶しやすい期限付きアカウント名を発行することができるが、この方法では、期限付きアカウント名の文字列の文字数が多くなる傾向がある。
【０１０２】
現実的に、前記６４文字の制限を越えることは、ほとんどあり得ないとしても、期限付きアカウント名の文字数が多いと、期限付きアカウント名を各種の装置に入力する必要のあるユーザＵ２やＵ１にとって、入力時の操作負担が大きくなって不便である。この操作負担は例えば次のような方法によって期限付きアカウント名の文字数を削減することにより、軽減することができる。
【０１０３】
すなわち、アカウント蓄積部５６に、これまで発行したすべての期限付きアカウント名（過去に発行し、現時点では利用されていない期限付きアカウント名も含む）を蓄積しておき、電子メールアドレスＡＤ２を仮想プリントサーバ２０に登録したユーザＵ２に期限付きアカウント名を発行する際には、その電子メールアドレスＡＤ２の＠マークをドットで置換した文字列（例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」）を、アカウント蓄積部５６に蓄積されている各期限付きアカウント名と比較する。
【０１０４】
この比較は、当該文字列の下位の階層から順番に行い、すでに蓄積されているいずれの期限付きアカウント名とも一致しなくなるところで停止する。
【０１０５】
当該文字列は、グローバルな範囲で一意な電子メールアドレスＡＤ２の＠マークをドットで置換して得られたものであるから、当然、グローバルな範囲で一意である。したがって、最上位の階層（例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」の場合ならば、「ｊｐ」）まで比較すれば、必ず一致しないことが保証されている。なお、ここで一致とは、相互に比較される２つの文字列が、全文字について完全に一致していることであり、文字数が相違するために一部だけ一致しているようなケースは、一致しないものとみなす。例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」と「ｔａｒｏｕ」を比較する場合、一致しないとの比較結果が得られる。
【０１０６】
なお、上述したサブドメインを設定し、「ｖｉｒｔｕａｌｐ」の下位に例えばホテルごとのサブドメインを設定した場合（例えば、ホテルＨＴ１とＨＴ２を異なるサブドメイン（例えば、「ｈｔ１」、「ｈｔ２」など）に対応付ける場合など）には、比較対象となるすでに発行されている期限付きアカウント名の探索範囲は、そのサブドメインの内部だけとしても、そのサブドメイン内における期限付きアカウント名の一意性は確保できる。
【０１０７】
ただし、探索範囲をサブドメイン内に限定すると、発行した期限付きアカウント名の一意性はそのサブドメインのなかでしか確認されていないため、ここで取り上げているように、一人のユーザＵ２が複数のホテルに宿泊するケースでは、同じユーザ（例えば、Ｕ２）でも、宿泊するホテルが変われば使用する期限付きアカウント名も変更しなければならないことが起こり得、利便性が犠牲になる。また、電子メールの送信元のユーザ（例えば、Ｕ１）の立場からすると、電子メールの宛先メールアドレスの記述に、サブドメイン（個々のホテル）まで指定しなければならず、ユーザＵ２の宿泊スケジュールを知っていなければ、電子メールを送信できない不便がある。したがってここでは、サブドメインの設定は行わないものとし、送信元ユーザＵ１は宛先のユーザＵ２が宿泊しているホテルを特定しないまま、電子メール（例えば、ＭＥ１）を送信できるものとする。
【０１０８】
この場合にはまた、最初に発行する時点の比較で、各期限付きアカウント名は、ドメイン名「ｖｉｒｔｕａｌｐ」に属する全範囲（この範囲には、ホテルＨＴ１，ＨＴ２など、仮想プリントサーバ２０の全ホテル会員が含まれる）における一意性が確認されることになる。なお、ユーザＵ１，Ｕ２にサブドメインの存在を意識させない限り、システム内部でこのようなサブドメインを設定して処理に活用することは自由である。
【０１０９】
以上のような比較によれば、ユーザＵ２に対して期限付きアカウント名を発行する時点で、前記アカウント蓄積部５６に、例えば、「ｔａｒｏｕ」が蓄積されていなければ、当該「ｔａｒｏｕ」が、ユーザＵ２の期限付きアカウント名として発行される。また、「ｔａｒｏｕ」は蓄積されているものの「ｔａｒｏｕ．ｙａｍａｄａ」が蓄積されていなければ、当該「ｔａｒｏｕ．ｙａｍａｄａ」が、ユーザＵ２の期限付きアカウント名として発行される。
【０１１０】
同様に、「ｔａｒｏｕ」と「ｔａｒｏｕ．ｙａｍａｄａ」はすでに蓄積されているものの、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ」が蓄積されていなければ、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ」が、ユーザＵ２の期限付きアカウント名として発行される。
【０１１１】
電子メールアドレスＡＤ２などのアカウントには通常、階層構造は存在しないが、ここでは、左側ほど下位の階層に属するものとしている。また、必ずしもこのように比較する文字列をドット単位で増加させていく必要はなく、１文字単位で増加させるようにしてもよい。ただし電子メールアドレスにおけるドットは、意味の区切りを示すために利用されることが多く、ドット単位で増加させることによって、人間にとっての可読性の高さ（理解しやすさ）を維持することができる。
【０１１２】
なお、過去に発行され、現時点では利用されていない期限付きアカウント名でも、アカウント蓄積部５６に蓄積されている限り当該比較の対象とするのは、同じユーザ（例えば、Ｕ２）がホテルに宿泊する際には、同じ期限付きアカウント名を再利用させる構成とするためである。同じ期限付きアカウント名を他のユーザに発行することを許すと、本来、そのユーザに宛てたものではない電子メールがそのユーザに読まれる等の不都合が生じる可能性が高まるからである。ただし、ある期限付きアカウント名の発行を受けていたユーザ（例えば、Ｕ２）が仮想プリントサービスの会員でなくなった場合などには、十分な期間を置いた後、当該期限付きアカウント名を他の個人ユーザに発行することも可能である。
【０１１３】
このような比較を実行するのは、前記アカウント比較部５７である。
【０１１４】
データ変換部５９は、メールボックス部６４に着信した電子メール（例えば、ＭＥ１）やその添付ファイル（例えば、Ｆ１）のデータ形式を、前記テレビ端末２５，電話端末２６，またはプリント端末２７に適合するデータ形式の前記出力用データＯＭ１〜ＯＭ３やＯＦ１〜ＯＦ３に変換する部分である。
【０１１５】
変換後に得られる出力用データは、各ユーザ（例えば、Ｕ２）のメールボックス部（例えば、６４）とは別個に設けた記憶領域に格納するようにしてもよいが、ここでは、メールボックス部（例えば、６４）に格納するものとする。
【０１１６】
宿泊スケジュール管理部５８は、仮想プリントサーバ２０の各個人会員（例えば、Ｕ２）の宿泊スケジュールを管理する部分である。この宿泊スケジュールには、個々のホテル（例えば、ＨＴ１）における宿泊スケジュールだけでなく、複数のホテルにまたがる宿泊スケジュール（例えば、ホテルＨＴ１に宿泊したあと、何月何日からホテルＨＴ２に宿泊する等）も含まれ得る。当該宿泊スケジュールは、前記メールボックスＩＤ別に構成されたスケジュールファイルＦ１１に格納される。当該スケジュールファイルＦ１１に、実際の宿泊管理情報の内容を格納するようにしてもよい。
【０１１７】
転送制御部６１は、メールボックス部６４に着信した電子メールおよびその添付ファイルの転送を制御する部分である。本実施形態では、あるホテル（例えば、ＨＴ１）に対し、あるユーザ（例えば、Ｕ２）のチェックインが行われたとき、メールボックス部６４内に保存されていた電子メールおよびその添付ファイルのデータ形式を変換したあとの出力用データ（例えば、ＯＭ１〜ＯＭ３，ＯＦ１〜ＯＦ３）を、ホテルサーバ２４の前記データ格納部４４へ転送する。この場合の転送先のアドレスはホテルごとに一定（もちろん、ユーザごとの区別は必要）であってよいので、予めホテルごとに転送アドレス登録部６０に登録しておくことができる。ユーザＵ２がホテルＨＴ１の次に宿泊するホテルＨＴ２のホテルサーバ（２４に対応）のデータ格納部（４４に対応）へ転送する場合も、これと同様である。
【０１１８】
仮想プリントサーバ２０側では、各ユーザ（例えば、Ｕ２）の宿泊スケジュールと各ユーザに発行した期限付きアカウント名が分かっているため、ユーザＵ２が宿泊する予定のホテル（例えば、ＨＴ１）に出力用データを転送するホテルに出力用データを転送する際、そのユーザＵ２の期限付きアカウント名をホテルサーバ２４に伝えることができ、ホテルサーバ２４では、前記メールボックス部６４と同様、期限付きアカウント名ごとに区別して出力用データを該当するデータ格納部（例えば、４４）に格納しておくことができる。
【０１１９】
なお、上述したサービス期間（例えば、ＳＴ２）が終了した時点で、メールボックス部（例えば、６４）に未読の電子メールやその添付ファイルが残っている場合や、チェックアウト後の前記第２の拡張期間内に着信した電子メールが存在する場合などには、個々のユーザ（例えば、Ｕ２）が個別に指定した転送先へ転送するようにしてもよい。その場合、転送のための通信アプリケーションとして電子メールを用いるなら、前記出力用データへデータ形式を変換する前の電子メールや添付ファイルもメールボックス部６４内に残しておき、その電子メールや添付ファイルを転送するようにするのが効率的である。
【０１２０】
この場合にはまた、転送先の電子メールアドレスとして、ユーザＵ２自身の前記電子メールアドレスＡＤ２などをそのまま利用することができるが、ＡＤ２以外の宛先への転送を希望する場合などには、動的にユーザＵ２が転送先のアドレスを指定できるようにしてもよい。
【０１２１】
いずれにしても転送先のアドレスは転送アドレス登録部６０に登録されており、転送制御部６１は、当該転送アドレス登録部６０に登録されている転送先アドレスへデータ（例えば、データ形式変換前の電子メールや添付ファイル）を転送する。
【０１２２】
通知メール生成部６２は、前記第２の拡張期間内に電子メールが届いた場合、その電子メールの送信元に対して送信するための所定の通知メールを生成する部分である。この通知メールは、すでに当該ユーザ（例えば、Ｕ２）は、ホテル（例えば、ＨＴ２）に宿泊していない（サービス期間（例えば、前記ＳＴ２）が経過した）ので、これ以上、電子メールを送らないように依頼する内容の電子メールであってよい。通知メール生成部６２により自動的に生成された当該通知メールは、当該送信元の電子メールアドレスに宛てて、自動的に送信される。
【０１２３】
以下、上記のような構成を有する本実施形態の動作について、図５〜図１１のフローチャートを参照しながら説明する。
【０１２４】
図５のフローチャートはＳ１１〜Ｓ２１の各ステップから構成されており、図６のフローチャートはＳ１１〜Ｓ２２の各ステップから構成されており、図７のフローチャートはＳ３０〜Ｓ３８の各ステップから構成されており、図８のフローチャートはＳ４０〜Ｓ４５の各ステップから構成されており、図９のフローチャートはＳ３０〜Ｓ５８の各ステップから構成されており、図１０のフローチャートはＳ６０〜Ｓ６６の各ステップから構成されており、図１１のフローチャートはＳ７０〜Ｓ７３の各ステップから構成されている。
【０１２５】
（Ａ−２）実施形態の動作
仮想プリントサーバ２０に対するホテル会員であるホテルＨＴ１，ＨＴ２の会員登録、および個人会員であるユーザＵ２の会員登録はすでに完了しているものとし、上述したように、ユーザＵ２が、ホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとする。
【０１２６】
予約なく宿泊することもあり得るが、図５の例では、ユーザＵ２はホテルＨＴ１に宿泊する前に、ホテルＨＴ１に宿泊の予約を行い（Ｓ１１）、その予約に関する情報が前記フロント端末２３に入力され、予約の受付・登録が行われる（Ｓ１２）。予約の情報は、前記宿泊管理情報の一部であるから、ホテルサーバ２４の宿泊管理部４３に管理され、ホテル会員としてのホテルＨＴ１のホテルＩＤ、予約者の氏名（ユーザＵ２の氏名）などとともに、ホテルサーバ２４を介して前記仮想プリントサーバ２０に通知される（Ｓ１３，Ｓ１４）。この通知は、仮想プリントサーバ２０に対し、メールボックス部６４の生成を依頼する意味をも有する。
【０１２７】
この通知を受信すると、仮想プリントサーバ２０は、通知の送信元のホテルサーバ２４の認証を行い、認証結果がＯＫであると（Ｓ１５）、前記期限付きアカウント名を発行する（Ｓ１６）。この認証は、予め前記ホテルデータベースＤＢ１に格納されている情報をもとに実行する。当該認証のために必要ならば、ホテルごとに異なる暗号鍵、パスワード、ハッシュ関数などの情報を、前記ホテルデータベースＤＢ１に格納しておくとよい。
【０１２８】
期限付きアカウント名を発行するステップＳ１６の詳細は、例えば、図１１のフローチャートに示す通りであってよい。
【０１２９】
上述したように、期限付きアカウント名の発行時点には様々なものがあり得るが、図１１では、仮想プリントサーバ２０が、いずれかのホテル会員のホテルサーバ（例えば、２４）から送信された宿泊管理情報を受信した時点で、期限付きアカウント名を発行している（Ｓ７０，Ｓ７１）。
【０１３０】
また、期限付きアカウント名を構成する具体的な値を決定する際には、前記アカウント比較部５７の機能を利用して、できるだけ短い文字列からなる期限付きアカウント名を発行することも望ましいが、ステップＳ７１では、単純に、ユーザＵ２の電子メールアドレスＡＤ２で、＠マークをドットに置き換えた文字列をそのまま、当該ユーザＵ２の期限付きアカウント名ＡＣ２１としている。
【０１３１】
この場合、上述したように、電子メールアドレスＡＤ２の具体的な値が「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｎｅ．ｊｐ」であり、前記仮想プリントサーバ２０のドメイン名が「ｖｉｒｔｕａｌｐ．ｃｏｍ」であるとすると、当該期限付きアカウント名ＡＣ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」となり、期限付きアカウント名ＡＣ２１を含む電子メールアドレスＡＤ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ＠ｖｉｒｔｕａｌｐ．ｃｏｍ」となる。
【０１３２】
なお、上述したように、同じユーザ（ここでは、Ｕ２）に関して同じ期限付きアカウント名（例えば、ＡＣ２１）を再利用する構成を取る場合、アカウント蓄積部５６にすでに当該ユーザＵ２に発行済みの期限付きアカウント名が蓄積されていれば、電子メールアドレスＡＤ２の＠マークをドットに置き換える等の処理を行うことなく、蓄積されている期限付きアカウント名をそのまま再発行すればよい。
【０１３３】
発行（または再発行）した期限付きアカウント名ＡＣ２１をユーザＵ２に通知する手段としては様々な方法が考えられるが、ステップＳ７２，Ｓ７３では、電子メールを用いて通知している。なお、ステップＳ７２で発行しているパスワードは、ユーザＵ２が前記電子メールＭＥ１や添付ファイルＦ１の内容を知るために、ホテルサーバ２４にログインするためのパスワードであるが、例えば、前記宿泊用パスワードＳＪ２と同じものであってよい。
【０１３４】
当該パスワードは、発行した期限付きアカウント名ＡＣ２１とともに電子メールを用いてユーザＵ２に通知される。この電子メールには暗号化や電子署名などのセキュリティ対策を施したほうがよいことは当然である。
【０１３５】
当該期限付きアカウント名ＡＣ２１の発行や通知を行ったあと、図５のステップＳ１７では、前記ステップＳ１４，Ｓ１５で受信した宿泊管理情報をもとに、ユーザＵ２のスケジュールを作成し、前記スケジュールファイルＦ１１に収容して保存する。このスケジュールは、単一のホテル（例えば、ＨＴ１）だけでなく、複数のホテル（ここでは、ＨＴ１，ＨＴ２）にまたがる宿泊のスケジュールである。
【０１３６】
次に、ステップＳ１８では、ユーザＵ２のための前記メールボックス部６４を生成（開設）している。
【０１３７】
なお、ステップＳ１８につづくステップＳ１９では、メールボックスＩＤ（期限付きアカウント名）であるＡＣ２１をホテルサーバ２４へ通知している。上述したように、ユーザＵ２に対しては、すでに図１１に示すステップＳ７３で通知済みであるが、ホテルサーバ２４に対しては、このステップＳ１９で期限付きアカウント名ＡＣ２１が通知される。この通知には、ホテルサーバ２４側で予約者（ここでは、ユーザＵ２）と期限付きアカウント名ＡＣ２１の対応関係が分かるように、当該期限付きアカウント名ＡＣ２１とともに、当該ユーザＵ２の個人情報（例えば、住所、氏名や、前記電子メールアドレスＡＤ２など）が含まれる。
【０１３８】
この通知を受けると、ホテルサーバ２４は、宿泊管理部４３の予約データベースＤＢ２に含まれているユーザＵ２の個人情報と対応付けて、当該期限付きアカウント名ＡＣ２１を予約データベースＤＢ２に格納する。
【０１３９】
なお、ステップＳ２１では、メールボックスＩＤ（期限付きアカウント名）ＡＣ２１を予約者（ここでは、ユーザＵ２）も受信しているが、ユーザＵ２に対して図１１に示すステップＳ７３で通知する場合には、当該ステップＳ２１は省略可能である。
【０１４０】
また、前記ステップＳ１６〜Ｓ１９の順番は必ずしも図示した通りである必要はない。例えば、上述したように、予約の受付からチェックインまでの期間が長く、チェックインが予定されている日時の所定期間前（例えば、２週間前）から第１拡張期間が開始するケースなどでは、ステップＳ１８はＳ１９のあとで実行されてもよい。
【０１４１】
なお、図６のフローチャートは、ホテルがＷｅｂサーバを公開しており、ユーザＵ２が当該Ｗｅｂサーバにアクセスすることによって予約などを行うケースを示しているが、実質的な処理の内容は図６とほぼ同様である。前記ホテルサーバ２４がＷｅｂサーバの機能を備え、ホテルＨＴ１のＬＡＮ１２において例えば前記ファイアウオールのＤＭＺ（Ｄｅｍｉｌｉｔａｒｉｚｅｄ Ｚｏｎｅ）などに設置され、公開されている場合などが、これに該当する。
【０１４２】
図６において、図５と同じ符号Ｓ１１〜Ｓ２１を付与した各ステップの処理は図５と同じなので、その詳しい説明は省略する。
【０１４３】
ただし図６ではＷｅｂアクセスが用いられるため、ステップＳ１２〜Ｓ１４でユーザＵ２からホテルＨＴ１へ供給される宿泊管理情報は、Ｗｅｂサーバとしてのホテルサーバ２４が提供するＷｅｂページ上に（フォームの仕組みを利用して用意される）各種入力欄などにユーザＵ２が必要事項を入力することによって、ホテルサーバ２４側に収集されることになる。
【０１４４】
また、図６のステップＳ１６などで発行される前記期限付きアカウント名ＡＣ２１やパスワードは、図６の場合でも、電子メールを用いて通知することも可能であるが、ＨＴＴＰレスポンスメッセージとして、ユーザＵ２側へ通知する構成とすることができる。
【０１４５】
なお、図６のステップＳ２２では、前記宿泊管理情報に対応する情報を前記ホテルサーバ２４の宿泊管理部４３に対応するホテル予約システムに供給し、前記予約データベースＤＢ２に格納しているが、このような処理は、例えば、ＣＧＩプログラムなどを利用して実現可能である。
【０１４６】
図７のフローチャートは、ユーザＵ２が宿泊の予約を行ってから、チェックインを実行するまでの期間（前記第１拡張期間に対応）の処理を示している。
【０１４７】
図７において、期限付きアカウント名ＡＣ２１を含む新たな電子メールアドレスＡＤ２１に宛てて電子メール（例えば、ＭＥ１）を送信すると（Ｓ３０）、当該電子メールＭＥ１は、受信されて、仮想プリントサーバ２０内の前記メールボックス部６４に着信する（Ｓ３１）。
【０１４８】
なお、図１の例では、ユーザＵ２とは異なるユーザＵ１が、ユーザＵ２宛ての当該電子メールＭＥ１を送信しているが、ユーザＵ２自身が当該電子メールＭＥ１を送信してもよいことは当然である。例えば、ユーザＵ２が自身のパソコン（２２）に保存しているファイルの内容を、ホテルＨＴ１（またはＨＴ２）に宿泊している時間を利用して閲覧したいと希望することもあり得、そのようなケースでは当該ファイルを添付ファイルＦ１とした電子メールＭＥ１を送信することになるからである。
【０１４９】
ステップＳ３１につづくステップＳ３２〜Ｓ３７の各処理では、電子メールＭＥ１や添付ファイルＦ１から上述した出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）を得るためのデータ形式の変換を実行している。所望のデータ形式の出力用データさえ得られれば、必ずしも図示した通りの順番で、図示した通りの処理を実行する必要はないが、図示の例では、前記出力用データＯＭ２，ＯＦ２を得るため、電子メールＭＥ１の内容を音声出力用のデータＯＭ２に変換し（Ｓ３２）、当該出力データＯＭ２をファイルに収容している（Ｓ３３）。これにより、電子メールＭＥ１や添付ファイルＦ１に含まれる自然言語などの文字列は、合成音声などによる音声出力が可能な状態となる。
【０１５０】
また、前記出力用データＯＭ１やＯＦ１を得るためには、添付ファイルＦ１を展開し（Ｓ３４）当該添付ファイルＦ１の内容に応じた画面イメージを作成したあと（Ｓ３５）、電子メールＭＥ１の本文部分や、必要に応じてメールヘッダの各フィールドの情報などを画面イメージに合成してテレビ出力用の当該出力用データＯＭ１やＯＦ１を生成している。
【０１５１】
さらに、出力用データＯＭ３やＯＦ３を得るためには、前記ステップＳ３５で生成した画面イメージ（画像データ）を用いて、添付ファイルＦ１の内容に対応する印刷出力用の出力用データＯＦ３としている。もちろん、前記ステップＳ３６で生成した画面イメージを用いて、電子メールＭＥ１の本文部分や、メールヘッダの各フィールドの情報などの内容に対応した印刷出力用のデータＯＭ３を生成してもよいことは当然である。
【０１５２】
これらステップＳ３２〜Ｓ３７は、電子メールＭＥ１の本文部分に有効な記述が存在し、添付ファイルＦ１が画像データ（静止画像データ）であるケースに対応する処理であるが、一般的には、例えば、添付ファイルＦ１のデータが静止画像データでないこともあり得る。添付ファイルＦ１のデータが、例えば、音声データや動画像データである場合には、処理は図示したものとは異なるものになる。
【０１５３】
音声データに対応する音声出力は、通常、プリント端末２７から印刷出力することはできず、テレビ端末２５から画面表示出力することもできないからである。したがって、前記ステップＳ３２やＳ３４の中で、元の添付ファイルＦ１のデータ形式（例えば、ＭＩＭＥタイプ）を判定し、その判定結果に応じて、実行するデータ形式変換処理（この変換処理では、さらに詳細なレベルでのデータ形式の整合性を獲得するため、例えば、ＭＩＭＥのサブタイプを一致させるような変換処理を実行する）の内容を決めたり、そのデータ形式変換処理を実行するか否かを決めたりすることも望ましい。
【０１５４】
なお、元の添付ファイルＦ１のデータが例えば音声データであっても、音声認識などの技術を利用して、当該音声データに対応する文字列を生成し、その文字列を示す画像データを生成する場合には、音声データに対応する当該画像データをもとに、プリント端末２７から印刷出力を行ったり、テレビ端末２５から画面表示出力を行うこと等も可能となる。
【０１５５】
また、元の添付ファイルＦ１のデータが動画像データである場合、テレビ端末２５からは、そのまま当該動画像データに対応する動画を画面表示出力することが可能である。プリント端末２７では通常、動画像データに応じた動画をそのまま印刷出力することはできないが、動画像データを複数の画像データ（静止画像データ）に分解すれば、各静止画像データに応じた印刷出力を行うことが可能である。
【０１５６】
この点からも明らかなように、電子メールＭＥ１の状態（有効な本文部分の有無）や添付ファイルＦ１のデータのデータ形式、およびステップＳ３２〜Ｓ３７で実行する処理の内容などの条件によっては、必ずしも、出力用データＯＭ１〜ＯＭ３，およびＯＦ１〜ＯＦ３の全種類が得られるとは限らないが、これらの出力用データが１種類でも得られた場合には、得られた出力用データは、メールボックス部６４に格納される（Ｓ３８）。
【０１５７】
なお、上述した転送などに備えるため、出力用データＯＭ１〜ＯＭ３，およびＯＦ１〜ＯＦ３に変換する前の元の電子メールＭＥ１や添付ファイルＦ１も、当該メールボックス部６４に残しておくことが望ましい。
【０１５８】
次に、図８のフローチャートを用いてユーザＵ２がチェックインしたときの処理について説明する。
【０１５９】
ユーザＵ２がホテルＨＴ１に宿泊するために、ノート型パソコンなどを携帯することなく当該ホテルＨＴ１のフロントまで出向いてチェックインを行う。この場合、ホテルＨＴ１の従業員ＣＬ１の操作などに応じて、前記フロント端末２３がユーザＵ２のチェックインを検知すると（Ｓ４０）、ホテルサーバ２４は、ユーザＵ２の氏名（宿泊用パスワードＳＪ２等でも可）などを検索キーとして、前記ステップＳ２０で予約データベースＤＢ２に格納した期限付きアカウント名ＡＣ２１を抽出することができるので（Ｓ４１）、当該期限付きアカウント名ＡＣ２１を通知して仮想プリントサーバ２０へユーザＵ２のチェックインが行われたことを示す宿泊管理情報を伝えることができる（Ｓ４２）。
【０１６０】
このステップＳ４０の実行時に、ユーザＵ２は自身の氏名などとともに、前記ワンタイムパスワードとしての宿泊用パスワードＳＪ２を、フロントの従業員ＣＬ１に告げるようにしてもよい。この場合、ホテルサーバ２４または仮想プリントサーバ２２などで、発行済みの宿泊用パスワードと照合することによりユーザ認証を行うことができるから、なりすましを検知、防止することが可能となり、ユーザＵ２宛ての電子メールＭＥ１やその添付ファイルＦ１の内容を、第３者に知られることを防止できる。
【０１６１】
ステップＳ４２につづくステップＳ４３では、仮想プリントサーバ２０が、前記期限付きアカウント名ＡＣ２１を用いて、当該ユーザＵ２のために確保された前記メールボックス部６４を特定し、当該メールボックス部６４に保管されている前記出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）をホテルサーバ２４へ送信する。
【０１６２】
これを受信したホテルサーバ２４は、ユーザＵ２のために設けた前記データ格納部４４に、当該出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）を格納する（Ｓ４４）。なお、データ形式を変換する前の電子メールＭＥ１やその添付ファイルＦ１ではなく、当該出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）、すなわちＦ３１を格納するのは、電子メールＭＥ１や添付ファイルＦ１のままでは、通常、テレビ端末２５，電話端末２６，プリント端末２７などによる各種出力を行うことができず、ノート型パソコンなどを携帯していないユーザＵ２が電子メールや添付ファイルの内容を知ることができないからである。
【０１６３】
有効な出力用データ（例えば、ＯＭ１など）が、データ格納部４４に格納されると、ユーザＵ２には電子メールが届いている旨が通知される（Ｓ４５）。この通知は、チェックインが行われたあと、ユーザＵ２の宿泊している客室などに電話などをかけること等によって知らせるようにしてもよいが、仮想プリントサーバ２０側のメールボックス部６４に着信している電子メールの存否だけを予め確認し確認結果をフロント端末２３などに表示できるようにしておけば、着信している電子メールがあることは、チェックインの時点に従業員ＣＬ１からユーザＵ２へ告げることが可能である。
【０１６４】
チェックインによりホテルＨＴ１の宿泊者となったユーザＵ２は、前記テレビ端末２５，電話端末２６，プリント端末２７のうちの所望の端末を利用して当該出力用データの出力を行わせ、電子メールＭＥ１や添付ファイルＦ１の内容を知ることができる。その際、ユーザＵ２は、前記テレビ端末２５，電話端末２６，プリント端末２７などに、前記宿泊用パスワードＳＪ２を入力してホテルサーバ２４にログインし、データ格納部４４に格納されている出力用データ（例えば、ＯＭ１など）を取り出すことになる。
【０１６５】
ここで、ステップＳ４３によって出力用データ（例えば、ＯＭ１など）がインターネット１１上を送信されるときや、出力用データがデータ格納部４４に格納されているときには、当該出力用データは暗号化された状態にあり、前記テレビ端末２５などから出力する際に復号することが望ましい。インターネット１１上を送信されるときに暗号化しておくのは、インターネット１１上で情報盗聴されることを防止するためであり、データ格納部４４に格納されているときに暗号化しておくのは、ホテルＨＴ１側のシステム管理者などによって、データ格納部４４に格納されている出力用データの内容が知られることを防止するためである。システム管理者には制限のないアクセス権限が与えられ、ホテルサーバ２４内の各種資源（データ格納部４４も含む）に自由にアクセスすることができるのが普通であり、暗号化を施しておかなければ、出力用データの内容もシステム管理者に知られる可能性があるからである。
【０１６６】
同様な理由で、仮想プリントサーバ２０側のメールボックス部６４に格納されているときにも、電子メールやその添付ファイル、および出力用データを暗号化しておくことが望ましい。
【０１６７】
なお、ユーザＵ２がチェックインを行ったことは、ホテルサーバ２４などを経由して仮想プリントサーバ２０に伝えられ、前記ユーザ管理部５４に格納されるため、制御部５１はいつでも、当該ユーザ管理部５４や宿泊スケジュール管理部５８に格納されているユーザＵ２に対応する宿泊管理情報を検査することにより、ユーザＵ２がホテルＨＴ１にチェックインを行ったことを検知することができる。
【０１６８】
図９のフローチャートは、主として、ユーザＵ２がホテルＨＴ１でチェックインを行ったあとの処理を示す。
【０１６９】
図９において、図７と同じ符号を付与したステップＳ３０，Ｓ３１の処理は、図７に対応するので、その詳しい説明は省略する。
【０１７０】
また、ステップＳ３１につづいて実行されるステップＳ５０の処理の詳細は、すでに説明した図７のステップＳ３２〜Ｓ３８と同じである。したがって、ステップＳ５０が終了した時点で、メールボックス部６４に着信している電子メールやその添付ファイルとそれらに対応する出力用データは、すでにメールボックス部６４に保存されている。
【０１７１】
ユーザＵ２のためのメールボックス部６４に電子メール（例えば、ＭＥ１）が着信しその添付ファイル（例えば、Ｆ１）なども含むデータのデータ形式変換処理が完了すると（Ｓ５０）、仮想プリントサーバ２０の制御部５１は、ユーザＵ２がホテルＨＴ１にチェックインしたか否かなどの宿泊状況を、ユーザ管理部５４に格納されているユーザＵ２に関する前記宿泊管理情報をもとに検査する（Ｓ５１）。このステップＳ５１の検査は、新たな電子メールおよびその添付ファイルがメールボックス部６４に着信するたびに繰り返し実行されるものであってよい。
【０１７２】
この検査の結果には、次の３通りがある。すなわち、まだチェックイン（ＣＩ）を行っておらず、なおかつ、チェックアウト（ＣＯ）を行っていないとの検査結果（ＣＩ未、ＣＯ未）と、チェックインを行っており、なおかつ、チェックアウトを行っていないとの検査結果（ＣＩ済み、ＣＯ未）と、チェックインを行っており、なおかつ、チェックアウトも行っているとの検査結果（ＣＩ済み、ＣＯ済み）の３通りである。
【０１７３】
このうち検査結果（ＣＩ未、ＣＯ未）は、前記第１拡張期間（ここでは、ＳＴ１１）に対応し、検査結果（ＣＩ済み、ＣＯ未）は、前記基本サービス期間（ここでは、ＳＴ１２）に対応し、検査結果（ＣＩ済み、ＣＯ済み）は、前記第２拡張期間（ここでは、ＳＴ１３）に対応する。
【０１７４】
検査結果（ＣＩ未、ＣＯ未）の分岐につづくステップＳ５８では、すでにステップＳ５０で実行されたように、メールボックス部６４へ出力用データを保存した状態を維持するだけである。
【０１７５】
検査結果（ＣＩ済み、ＣＯ未）の分岐につづくステップＳ５５では、メールボックス部６４にユーザＵ２宛ての電子メールが着信したことを、前記ホテルサーバ２４へ通知している。このあと、ステップＳ５６，Ｓ５７およびそれ以降のステップで実行される処理は、すでに図８に示したステップＳ４３以降の処理と実質的に同じである。
【０１７６】
すなわち、ステップＳ５６で出力用データの収容した保管ファイルをメールボックス部６４から引き出すことを指示すると、仮想プリントサーバ２０側で前記ステップＳ４３に対応する処理などが実行され、出力用データが、ホテルサーバ２４側のデータ格納部４４に格納されて、前記ステップＳ４５と同様に、ユーザＵ２に対しメールが届いていることが通知される（Ｓ５７）。
【０１７７】
この通知は、宿泊中のユーザＵ２がフロントに訪れたときに従業員ＣＬ１などが伝えてもよく、ユーザＵ２が宿泊している客室に電話をかけること等によって伝えてもよいことは、前記ステップＳ４５の場合と同様である。また、この通知を受けてユーザＵ２が行う対応や各部の処理も、ステップＳ４５以降と同様であり、ユーザＵ２は、前記宿泊用パスワードＳＪ２を入力してホテルサーバ２４にログインし、データ格納部４４に格納されている出力用データ（例えば、ＯＭ１など）を取り出して、前記テレビ端末２５，電話端末２６，プリント端末２７などから当該出力用データの出力を行わせることになる。
【０１７８】
なお、前記検査結果（ＣＩ済み、ＣＯ済み）の分岐につづくステップＳ５２では、仮想プリントサーバ２０側の転送制御部６１が、前記メールボックス部６４のなかに保存しておいた出力用データに変換する前の電子メールやその添付ファイルを、転送アドレス登録部６０に登録されている転送先のアドレスへ転送する。
【０１７９】
そして、このように前記第２拡張期間内に届いた電子メールの送信元（メール送信者）に対しては、前記通知メール生成部６２が生成した通知メールを送信する。この通知メールを読んだ当該メール送信者は、それ以後、当該電子メールアドレスＡＤ２１に宛てた電子メールの送信を控えることになる。なお、転送制御部６１が前記転送アドレス登録部６０に登録されている転送先のアドレスに宛てて電子メールを送信しても送達することができず、エラーメールなどが戻ってくることがあり得るが、そのようなケースでは、第２拡張期間内にメールボックス部６４に着信した電子メールを、その送信元メールアドレスをもとに、メール送信者へ転送するようにしてもよい。
【０１８０】
転送先のアドレスに当該電子メールが転送できた場合（Ｓ５４）、ユーザＵ２は、その電子メールや添付ファイルを閲覧することができる。ここでは、転送のための通信アプリケーションとして電子メールを用いる場合を示している。ユーザＵ２が転送先のアドレスとして例えば前記電子メールアドレスＡＤ２などを指定してある場合には、例えば、自宅に設置したパソコンなどを用いて当該電子メールを閲覧することができる。
【０１８１】
ここで説明したステップＳ５２〜Ｓ５４の処理と一部重複するが、チェックアウト時の処理の詳細は、図１０に示したフローチャートのようになる。
【０１８２】
ホテルＨＴ１のフロント端末２３で、ユーザＵ２がホテルＨＴ１からチェックアウトしたことを検知すると（Ｓ６０）、その検知は、所定の検索キー（ユーザＵ２の氏名や宿泊用パスワードＳＪ２など）とともにホテルサーバ２４へ伝えられ、ホテルサーバ２４では、当該検索キーを用いて予約データベースＤＢ２を検索することでユーザＵ２の期限付きアカウント名ＡＣ２１を特定し（Ｓ６１）、仮想プリントサーバ２０へ通知する（Ｓ６２）。
【０１８３】
また、前記ステップＳ６０におけるチェックアウトの検知を受けてホテルサーバ２４では、データ格納部４４に格納されている各出力用データを収容したファイルＦ３１を削除する（Ｓ６６）。なお、ここでは、ファイルの削除ではなく、フォルダ（ディレクトリ）の１つとしてユーザＵ２のために生成された当該データ格納部６４そのものを削除するようにしてもよい。
【０１８４】
一方、前記ステップＳ６２の通知を受けた仮想プリントサーバ２０では、前記宿泊スケジュール管理部５８内のスケジュールファイルＦ１１またはユーザ管理部５４に格納されている宿泊管理情報の内容を変更する（Ｓ６３）。
【０１８５】
次のステップＳ６４は、前記ステップＳ５２に対応する転送処理であり、転送処理の実行後も、メールボックス部６４において、一定期間、出力用データまたは、電子メールやその添付ファイルを収容したファイルの保管を継続している（Ｓ６４）。
【０１８６】
ホテルＨＴ１につづいてユーザＵ２が宿泊するホテルＨＴ２に関しても、以上と同様な処理が実行され得るが、ホテルＨＴ２も、ホテルＨＴ１と同様、仮想プリントサーバ２０のホテル会員である場合には、上述したように最初のホテルＨＴ１における前記第２拡張期間ＳＴ１３は存在せず、ホテルＨＴ１に関する基本サービス期間ＳＴ１２の終了後ただちに、次のホテルＨＴ２に関する第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が開始する。
【０１８７】
これは、最初のホテルＨＴ１に関する処理では、図９に示したステップＳ５１の検査結果（ＣＩ済み、ＣＯ済み）に対応する分岐が存在しないことを意味するから、最初のホテルＨＴ１に関しては、ステップＳ５２〜Ｓ５４に対応する処理も実行されない。
【０１８８】
（Ａ−２）実施形態の効果
本実施形態によれば、宿泊時にノート型パソコンや携帯電話機などを携帯していないユーザ（Ｕ２）でも、ホテル（ＨＴ１，ＨＴ２）に関する前記サービス期間内などに届いた電子メールや添付ファイルの内容を知ることができるため、利便性が高い。
【０１８９】
また、この際、プリンタドライバのインストールなどの煩わしい作業を行う必要がない点も、利便性の向上に寄与してる。
【０１９０】
さらに、前記期限付きアカウント名（ＡＣ２１）として、記憶しやすいアカウント名や短いアカウント名を利用することができる点も、利便性の向上に寄与する。
【０１９１】
また本実施形態は、基本的に恒久的なパスワード（例えば、ＰＷ２）などの機密性の高い情報を、ビジネスセンタの装置（例えば、パソコンなど）等に入力する必要がない構成であるため、セキュリティ性が高い。
【０１９２】
（Ｂ）他の実施形態
上記実施形態では、一人のユーザ（例えば、Ｕ２）のために設けるフォルダ（ディレクトリ）の数を１つとしたが、一人のユーザのためのデータ格納部４４として複数のフォルダ（ディレクトリ）を用意してもよいことは当然である。この点、前記メールボックス部６４も同様である。
【０１９３】
また、上記実施形態では、ホテルに宿泊するユーザＵ２が電子メールを受信する場合を例に説明したが、ホテルに宿泊中のユーザＵ２から電子メールを送信することも可能である。例えば、テレビ端末２５などに、電子メールの本文部分の内容などを編集する機能を設ければ、編集し作成した電子メール（あるいは、その内容）を、上述した電子メールＭＥ１を受信しその内容をユーザＵ２が知るための経路を反対方向に転送させ、転送中の各過程で必要な処理を施すことによって、電子メールを送信することができるからである。
【０１９４】
なお、上記実施形態では、「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｃｏ．ｊｐ」などの電子メールアドレスを前提としたが、すべての電子メールシステムにおいて、このような電子メールアドレスが用いられるとは限らない。例えば、アカウント名とドメイン名のあいだに、＠マークではなく、！マークを配置する場合や、ドメインの階層構造のうち上位のものほど左側に記述する場合などもあり得、本発明は、そのような電子メールアドレスを用いるケースにも適用可能である。
【０１９５】
また、前記インターネット１１はその他のネットワークに置換可能である。例えば、特定の通信事業者が提供するＩＰ網や、ＩＰ−ＶＰＮ網などに置換可能である。
【０１９６】
さらに、上記実施形態にかかわらず、テレビ端末２５，電話端末２６，プリント端末２７は、必ずしもこれら３種類すべてを用意する必要はない。また、３種類の一部または全部を他の種類の出力装置と置換してもかまわない。
【０１９７】
なお、上記実施形態で仮想プリントサーバ２０に搭載した多数の機能（構成要素５３〜６４などの機能）は、複数のサーバに分散して配置してもよいことは当然である。
【０１９８】
また、上記実施形態では、ユーザＵ２が２つのホテルＨＴ１，ＨＴ２に連続的に宿泊するケースを例に説明したが、連続的に宿泊するホテルの数は３つ以上であってもよい。また、１つのホテルだけに宿泊するケースにも本発明は適用可能である。
【０１９９】
以上の説明にかかわらず、前記ホテルはホテル以外の宿泊施設に置換可能である。また、宿泊施設にも限定せず、新幹線、飛行機、船など、予めその利用を予約するか、予約しないとしても、利用する際に何らかの個人情報を登録する必要のある公共交通機関などにも置換可能である。
【０２００】
また、一連のスケジュールのなかに異種の宿泊施設や異種の公共交通機関が混在しているケースにも、本発明は適用可能である。
【０２０１】
さらに上記実施形態では、電子メール（ＭＥ１など）を前提として説明したが、本発明は電子メール以外の通信手段にも適用可能である。例えば、ＦＴＰプロトコルによるファイル転送などにも本発明は適用することができる。この場合、前記仮想プリントサーバ２０には、ＦＴＰサーバとしての機能を搭載することになる。
【０２０２】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０２０３】
【発明の効果】
以上に説明したように、本発明によれば、利便性が高く、セキュリティ性に優れた情報保管システム及び情報保管サービス方法を提供することができる。
【図面の簡単な説明】
【図１】実施形態に係る通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用する仮想プリントサーバの主要部の構成例を示す概略図である。
【図３】実施形態で使用するホテルサーバの主要部の構成例を示す概略図である。
【図４】実施形態で使用するフロント端末等の主要部の構成例を示す概略図である。
【図５】実施形態の動作例を示すフローチャートである。
【図６】実施形態の動作例を示すフローチャートである。
【図７】実施形態の動作例を示すフローチャートである。
【図８】実施形態の動作例を示すフローチャートである。
【図９】実施形態の動作例を示すフローチャートである。
【図１０】実施形態の動作例を示すフローチャートである。
【図１１】実施形態の動作例を示すフローチャートである。
【符号の説明】
１０…通信システム、１１…インターネット、１２，１３…ＬＡＮ、２１…ＭＭＫ端末、２２…パソコン、２３…フロント端末、２４…ホテルサーバ、２５…テレビ端末、２６…電話端末、２７…プリント端末、３０，４０、５０…通信部、３１，４１、５１…制御部、３２…操作部、３３…表示部、３４，４２、５２…記憶部、４３…宿泊管理部、４４…データ格納部、５４…ユーザ管理部、５５…アカウント発行部、５６…アカウント蓄積部、５７…アカウント比較部、５８…宿泊スケジュール管理部、５９…データ変換部、６０…転送アドレス登録部、６１…転送制御部、６２…通知メール生成部、６３…メールボックス管理部、６４…メールボックス部、ＡＣ２１…期限付きアカウント名、ＭＥ１…電子メール、Ｆ１…添付ファイル、ＯＭ１〜ＯＭ３，ＯＦ１〜ＯＦ３…出力用データ。
【発明の属する技術分野】
本発明は情報保管システム及び情報保管サービス方法に関し、例えば、宿泊施設や公共交通機関の利用中、電子メールの送受を行う場合などに適用して好適なものである。
【０００２】
【従来の技術】
ホテルなどでは、外部から宿泊者へ情報を届けるための通信手段としてファクシミリが用いられることが多い。このケースでは、宿泊者にファクシミリが届いた場合、ホテルの従業員がそのファクシミリを管理しておき、フロントなどを介して宿泊者へ渡す形になる。
【０００３】
また、ホテルの客室内にインターネット接続用のコネクタなどを用意しておき、客室に泊まった宿泊者のパーソナルコンピュータなどを当該コネクタに接続することで、インターネットアクセスが行えるようにしてあることも少なくない。その場合、宿泊者は、自宅などからインターネットアクセスするときと同様、自身が契約しているＩＳＰ（インターネットサービスプロバイダ）のメールサーバに確保した自身のメールボックスにアクセスすることにより、当該メールボックスに着信している自身宛ての電子メールを受信して閲覧したり、反対に当該メールサーバ経由で電子メールを送信したりすること等も可能である。また当該パーソナルコンピュータを用いれば、イントラネット（例えば、当該宿泊者が勤務している会社のＬＡＮ（ローカルエリアネットワーク））へ、インターネット経由または公衆電話網経由でリモートアクセス（例えば、ＶＰＮ（バーチャルプライベートネットワーク）などを利用したリモートアクセス）することも可能である。
【０００４】
さらに、当該宿泊者がオンラインストレージサービスの契約を行っている場合には、当該インターネット接続用のコネクタにパーソナルコンピュータなどを接続することで、インターネット上のストレージサーバに保管されているファイルを受信することもできる。これにより、ファイルを保管した者と宿泊者のあいだでメッセージ交換を行うこと等も可能である。
【０００５】
なお、ホテルの内部にはビジネスセンタを設け、当該ビジネスセンタ内に設置したパーソナルコンピュータやプリンタを、多くの宿泊者が共用できるようにしてあることも多い。このケースでは、個々の宿泊者は、宿泊時に自身のパーソナルコンピュータを携帯していなくても、ビジネスセンタ内のパーソナルコンピュータを用いてインターネットアクセス（電子メールの送受、前記ストレージサーバへのアクセス、リモートアクセスを含む）を行ったり、インターネットアクセスにより当該パーソナルコンピュータに受信したファイルの内容をプリンタを介して印刷出力したりすることが可能である。
【０００６】
【発明が解決しようとする課題】
ところで、上述したファクシミリを用いるケースでは、ファクシミリで受信され印刷出力された紙の文書の管理が適切に行われるか否かは、ホテル側の管理体制やホテルの従業員のセキュリティ意識に依存する。したがって、管理体制や従業員のセキュリティ意識などに問題がある場合、その文書が機密性の高いものであっても、機密が維持できない可能性もある。
【０００７】
また、宿泊者が自身のパーソナルコンピュータを客室のインターネット接続用コネクタに接続するケースでは、携帯電話機などに比べるとサイズも重量も大きいパーソナルコンピュータ（例えば、ノート型のパーソナルコンピュータ）を携帯し、ホテルに持ち込まなければならない点で不便である。携帯電話機などにもメーラを搭載し、電子メールの送受、閲覧が可能なものもあるが、携帯電話ネットワークを運営する携帯電話事業者により、添付ファイルの受信はできない旨の制約が課されていることが少なくない。また、たとえ当該制約がないケースであっても、携帯電話機の画面は小さく、キー操作は煩雑であるため、電子メール閲覧時の利便性に欠け、電子メールを印刷出力することは困難である。
【０００８】
なお、宿泊者自身のパーソナルコンピュータには、通常、ホテルのビジネスセンタなどに設置されたプリンタに対応するプリンタドライバがインストールされていないため、電子メールや添付ファイルの内容を印刷出力するには、プリンタドライバのインストールを行うか、あるいは、すでにプリンタドライバがインストールされている前記ビジネスセンタ内のパーソナルコンピュータを利用する必要がある。
【０００９】
プリンタドライバのインストールを行うことは宿泊者にとって煩わしいし、ビジネスセンタ内のパーソナルコンピュータを利用する場合には、次に述べるように、宿泊者自身のパーソナルコンピュータを用いず、最初からビジネスセンタ内のパーソナルコンピュータを利用する場合と同様な問題が発生する。
【００１０】
ホテルのビジネスセンタに設置されているパーソナルコンピュータを利用するケースでは、当該パーソナルコンピュータは、所有権がホテル側にあり、多数の宿泊者に共用されるものである点などで、宿泊者から見た場合、セキュリティ性に不安が残る。
【００１１】
例えば、前記ストレージサーバがパスワードを用いたユーザ認証を行うものであるケースや、ＶＰＮによるリモートアクセスを行うケースなどでは、パスワードなどの機密性の高い情報をパーソナルコンピュータに入力する必要があるため、ユーザ自身に所有権がなく、なおかつ共用される当該パーソナルコンピュータを介して機密性の高い情報が漏洩する可能性があるからである。もちろん、受信または送信した電子メールや添付ファイルの内容が漏洩する可能性もある。これらの情報の漏洩は、宿泊者が削除することを忘れたり、削除は行っても（論理的にはメーラなどのアプリケーションにより、削除したものとして扱われていても）一般的なパーソナルコンピュータの機構上、削除したファイルの内容が物理的にはハードディスクなどに残存すること等に起因して発生し得る。
【００１２】
なお、ストレージサーバを利用しないケースや、リモートアクセスを行わないケースでも、電子メールや添付ファイルの内容が漏洩する可能性がある点は同じである。
【００１３】
【課題を解決するための手段】
かかる課題を解決するために、第１の本発明では、送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバ（例えば、仮想プリントサーバ２０など）に、送信元ユーザ（例えば、ユーザＵ１など）から宛先ユーザ（例えば、ユーザＵ２など）へ送信した保管対象データ（例えば、電子メールＭＥ１やその添付ファイルＦ１など）を保管するための個別ユーザ用データ保管部（例えば、メールボックス部６４など）を設ける情報保管システムであって、前記宛先ユーザを収容する収容施設（例えば、ホテルＨＴ１，ＨＴ２など）側に配置される収容施設側システム（例えば、ホテルサーバ２４など）を有し、当該収容施設側システムは、前記宛先ユーザを当該収容施設に収容しているか否かを管理する収容管理部（例えば、宿泊管理部４３など）を備え、前記リモート保管サーバは、前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理するための保管管理部（例えば、メールボックス管理部６３など）を備え、前記収容施設側システムまたはリモート保管サーバは、前記収容施設が宛先ユーザを収容している期間に対応する有効期間（例えば、サービス期間ＳＴ１，ＳＴ２など）のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名（例えば、ＡＣ２１など）を発行するユーザ名発行部（例えば、アカウント発行部５５など）を有することを特徴とする。
【００１４】
また、第２の本発明では、送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を用いる情報保管サービス方法であって、前記宛先ユーザを収容する収容施設側に配置される収容施設側システムが、収容管理部を用いて、前記宛先ユーザを当該収容施設に収容しているか否かを管理し、前記リモート保管サーバでは、保管管理部が、前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理し、前記収容施設側システムまたはリモート保管サーバに設けられたユーザ名発行部が、前記収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行することを特徴とする。
【００１５】
これにより、前記有効期間のあいだ期間限定ユーザ名を用いて宛先ユーザと個別ユーザ用データ保管部を関連付けることができ、宛先ユーザに宛てた保管対象データの送信が可能となる。
【００１６】
【発明の実施の形態】
（Ａ）実施形態
以下、本発明にかかる情報保管システム及び情報保管サービス方法を、インターネット上に配置された仮想プリントサーバを含む通信システムに適用した場合を例に、実施形態について説明する。
【００１７】
（Ａ−１）実施形態の構成
本実施形態の通信システム１０の全体構成例を図１に示す。
【００１８】
図１において、当該通信システム１０は、インターネット１１と、ＬＡＮ（ローカルエリアネットワーク）１２，１３と、前記仮想プリントサーバ２０と、ＭＭＫ（マルチメディアキオスク）端末２１と、パソコン（パーソナルコンピュータ）２２、２８，２９と、フロント端末２３と、ホテルサーバ２４と、テレビ端末２５と、電話端末２６と、プリント端末２７とを備えている。
【００１９】
このうちＬＡＮ１２は、ホテルＨＴ１の内部に構築されたＬＡＮであり、ＬＡＮ１３は、ＨＴ１とは別のホテルＨＴ２の内部に構築されたＬＡＮである。図１上でＬＡＮ１２に接続するように図示した構成要素２３〜２７は、ＬＡＮ１２内に含まれる構成要素である。本実施形態において、ユーザＵ２はホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとする。ただしユーザＵ２は、ホテルＨＴ１などの宿泊客となる以前に仮想プリントサーバ２０の会員であり、仮想プリントサーバ２０にその個人情報を申告した上で会員登録を行っている。ただしユーザＵ２は、一般的な仮想プリントサービスの提供を受けるために登録している会員とは別個に、本実施形態で述べるサービスだけを受けることを目的として会員登録を行っている者であってもよい。
【００２０】
図１上は省略しているが、ホテルＨＴ２側のＬＡＮ１３にも、構成要素２３〜２７と同様な構成要素が含まれる。なお、ＬＡＮ１２，１３には、図示しないファイアウオール、ルータ、ＤＮＳサーバなどが含まれていてよいことは当然である。
【００２１】
ＬＡＮ１２内の構成要素２３〜２７のうち、フロント端末２３は、ホテルＨＴ１のフロント業務に従事する従業員ＣＬ１などに操作される情報処理装置で、ユーザＵ２の宿泊の予約、チェックイン、チェックアウトなどの宿泊管理は、このフロント端末２３を介して入力される情報に基づいて実行される。
【００２２】
フロント端末２３は、例えば、図４に示す内部構成を有するものであってよい。
【００２３】
なお、フロント端末２３以外の構成要素２１，２２，２５〜２７の内部構成も、図示したレベルの詳細さでみる限り、図４と同じであってよい。
【００２４】
（Ａ−１−１）フロント端末の内部構成例
図４において、当該フロント端末２３は、通信部３０と、制御部３１と、操作部３２と、表示部３３と、記憶部３４とを備えている。
【００２５】
このうち通信部３０はＬＡＮ１２を経由した通信のために機能する部分である。通信部３０の主な通信相手はホテルサーバ２４なので、ＬＡＮ１２内の通信だけを行うもので足りるが、必要に応じて、インターネット１１経由の通信を行えるようにしてもよい。
【００２６】
操作部３２は、ホテルＨＴ１の従業員ＣＬ１が操作してフロント端末２３に指示を伝える部分で、例えば、マウスなどのポインティングデバイスやキーボードなどを有する。ただし図４にテレビ端末２５を示したものとみる場合には、操作部３２にはテレビ端末２５を操作するためのリモコン送信機などが該当する。同様に、電話端末２６を示したものとみる場合には電話端末２６上に配列されたボタンが、プリント端末（プリンタ）２７を示したものとみる場合には、プリント端末２７上に配列されたボタンが、当該操作部３２に該当し得る。
【００２７】
また、図４にパソコン２２を示したものとみる場合には、操作部３２を操作するのはユーザＵ１（または、ユーザＵ２）であり、ＭＭＫ端末２１，テレビ端末２５，電話端末２６，またはプリント端末２７を示したものとみる場合には、操作部３２を操作するのは、通常、ユーザＵ２である。ここで、ユーザＵ１は、ホテルＨＴ１に宿泊するユーザＵ２に宛てて電子メールＭＥ１を送信するユーザを示している。当該電子メールＭＥ１には添付ファイルＦ１が添付されているものであってよい。
【００２８】
表示部３３は、フロント端末２３が搭載するアプリケーションソフト（例えば、メーラやＷｅｂブラウザなど）の機能に応じて画面表示を行うディスプレイ装置に対応する部分である。図４にフロント端末２３以外の構成要素２１，２２，２５〜２７を示したものとみる場合、表示部３３の具体的な構成や、表示を目視する主体が変化し得る点は、前記操作部３２の場合と同様であるのは当然である。
【００２９】
制御部３１は、ハードウエア的には当該フロント端末２３のＣＰＵ（中央処理装置）に相当し、ソフトウエア的にはＯＳ（オペレーティングシステム）、前記メーラ、Ｗｅｂブラウザなどの各種プログラムに相当する部分である。
【００３０】
記憶部３４はハードウエア的には、ＲＡＭ（ランダムアクセスメモリ）や、ハードディスクなどによって構成される記憶資源であり、ソフトウエア的には、各種のファイルがこの部分に含まれ得る。前記メーラやＷｅｂブラウザなどのプログラムファイルもこのようなファイルの一つであるから、メーラやＷｅｂブラウザなども、その物理的な実体は、この記憶部３４に位置する。
【００３１】
なお、本実施形態の構成上、ユーザＵ２がホテル（例えば、ＨＴ１）に宿泊する際には、ユーザ認証を行って、なりすましを検知、防止できることが望ましい。なりすましの検知のためには、対面で身分証明書（例えば、運転免許証など）の提示を求めること等も考えられるが、例えば、次のような方法を用いることも簡便である。
【００３２】
すなわち、フロント端末２３側へ予め仮想プリントサーバ２０の会員（当然、Ｕ２も含む）の公開鍵（ここでは、ユーザＵ２の公開鍵をＰＫ２とする）を配送しておき、ユーザＵ２がホテルＨＴ１の宿泊を予約するときには、その旨の電子メール（この電子メールは、例えば、Ｗｅｂアクセスなどに置換可能）を前記公開鍵ＰＫ２に対応する自身の秘密鍵（ここでは、ＶＫ２とする）で暗号化した上で送信する構成とする。秘密鍵ＶＫ２を使用できるのはユーザＵ２のみであるから、予約のための当該電子メールを公開鍵ＰＫ２を用いて正しく復号できれば、その電子メールを送信した者が、ユーザＵ２自身であることをフロント端末２３側で検証することができる。
【００３３】
さらに、当該検証の結果がＯＫであれば、固有の文字列（宿泊用パスワードＳＪ２）を記述した電子メールを公開鍵ＰＫ２で暗号化した上でフロント端末２３（または、仮想プリントサーバ２０）側からユーザＵ２へ返送するようにすれば、その電子メールを受信したユーザＵ２は前記秘密鍵ＶＫ２でこの電子メールを復号して当該宿泊用パスワードＳＪ２を取得することができるから、宿泊のため実際にホテルＨＴ１のフロントへ出向いたときには、従業員ＣＬ１に、自身の氏名などとともに当該宿泊用パスワードＳＪ２を申告するようにする。
【００３４】
その後、宿泊期間中に外出先から戻ったユーザＵ２がホテルＨＴ１における自身の客室の鍵をフロントから受け取るとき等にも、適宜、前記宿泊用パスワードＳＪ２を申告させて、ユーザ認証を行うようにしてもよい。
【００３５】
ただし従業員ＣＬ１に口頭で申告する替わりに、自動的に当該宿泊用パスワードＳＪ２の申告を行うことができる機構（例えば、いわゆるＩＣタグなど）を利用するようにしてもよい。これにより従業員ＣＬ１を介して宿泊用パスワードＳＪ２の漏洩などが起きる危険性も排除できる。
【００３６】
当該宿泊用パスワードＳＪ２は、１つの宿泊期間中のみ有効な一種のワンタイムパスワードとすることが望ましい。
【００３７】
ユーザＵ２に関するパスワードとしては、仮想プリントサーバ（仮想プリントサービス）２０の会員としてのパスワード（ここでは、ＰＷ２とする）もあるが、仮想プリントサービスの会員としてのパスワードＰＷ２は基本的に恒久的なパスワードであるため、宿泊用パスワードＳＪ２をワンタイムパスワードとして、パスワードＰＷ２と使い分けることで、いっそう強固なセキュリティ性を確保することも可能になる。
【００３８】
例えば、テレビ端末２５，電話端末２６，プリント端末２７を使用するときには、事前に各構成要素２５〜２７に対し、当該宿泊用パスワードＳＪ２を入力させてユーザ認証を行うようにするとよい。
【００３９】
ここで、テレビ端末２５は、基本的に通常のテレビ受像機としての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容（後述するように、データ形式は変換する）を画面表示する必要がある。必要に応じて、例えば、ＢＭＬ（Ｂｒｏａｄｃａｓｔ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）を処理する機能を当該テレビ端末２５に搭載してもよい。
【００４０】
ユーザＵ２がテレビ端末２５に電子メールＭＥ１や添付ファイルＦ１の内容（必要に応じて、メールヘッダの情報（例えば、送信元のメールアドレスなど）も含む）を画面表示させるには、その画面表示のもとになるデータを保管しているサーバ（仮想プリントサーバ２０でもよいが、本実施形態ではホテルサーバ２４とする）に対し、アカウントを送信する必要があるが、アカウントは秘密の情報ではないし、ホテルの客室は、ユーザＵ２の不在のときに、例えば、清掃作業員が入室したり、ホテルの従業員が入室する可能性もあるため、確実に、ユーザＵ２以外の者が電子メールＭＥ１や添付ファイルＦ１の内容を知ることができないようにするには、アカウントのほかに秘密の情報を利用してユーザ認証を行う構成とすることが望ましい。この秘密の情報として、上述した宿泊用パスワードＳＪ２を用いることが考えられる。
【００４１】
テレビ端末２５の所有権はホテルＨＴ１側にある点や、ユーザＵ２のあとには他の宿泊客が当該テレビ端末２５を利用する点などを考慮すると、当該テレビ端末２５はセキュリティ上、上述したビジネスセンタ内に設置されているパーソナルコンピュータに類似した位置づけになるとみることができるから、恒久的なパスワードＰＷ２を当該テレビ部端末２５に入力することは好ましくないといえるが、ワンタイムパスワードとしての宿泊用パスワードＳＪ２を入力するなら、そのような弊害は軽減または解消される。
【００４２】
また、前記電話端末２６は基本的に通常の電話機としての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容を音声出力してユーザＵ２に聴取させる必要がある。ただし通常の電話端末は公衆電話網に接続されるものであるため、図示したようにＬＡＮ１２に直接、接続するには、ＬＡＮ１２内の通信プロトコルとしてＯＳＩ参照モデルのネットワーク層ではＩＰプロトコルを用い、なおかつ、当該電話端末２６をＶｏＩＰ対応のＩＰ電話機などとする必要がある。もちろん、ＶｏＩＰゲートウエイやＩＰ−ＰＢＸを経由すれば、ＶｏＩＰ非対応の通常の電話端末をＬＡＮに接続することも可能である。
【００４３】
アカウントや宿泊用パスワードＳＪ２が、数字以外の文字を含む文字列である場合、電話端末２６を介して当該アカウントや宿泊用パスワードＳＪ２を入力することは容易ではないと考えられるが、例えば、合成音声などによるガイダンスを利用すれば必ずしも不可能ではない。
【００４４】
また、電話端末２６は必ずしもホテルＨＴ１の客室内に設置されたものである必要はないので、前記ビジネスセンタ内に設置された電話端末や、ホテルＨＴ１の外に設置された電話端末を利用することも可能である。
【００４５】
なお、電話端末２６がＩＰ電話機の場合、その外観は必ずしも一般的な電話機に類似したものとは限らず、例えば、通常のパーソナルコンピュータにＩＰ電話用のソフトウエアを搭載することによってＩＰ電話機の機能が実現されること等も少なくない。そのようなケースでは、ユーザＵ２がアカウントや宿泊用パスワードＳＪ２を入力するためのユーザインタフェース（例えば、キーボード、マウス、画面など）は十分に用意することができるから、入力の困難性は緩和することが可能である。
【００４６】
前記プリント端末２７は、基本的に通常のプリンタとしての機能を持つものであってよいが、電子メールＭＥ１や添付ファイルＦ１の内容を印刷出力する必要がある。プリント端末２７は一般的に、アカウントや宿泊用パスワードＳＪ２を入力するためのユーザインタフェースに乏しい点で、前記電話端末２６と類似しているが、ホテルＨＴ２内でユーザＵ２が利用するプリント端末２７は、ビジネスセンタ内に設置されたものであるため、その近傍にはパーソナルコンピュータも存在する。したがって、当該パーソナルコンピュータとプリント端末２７を連携させ、パーソナルコンピュータのユーザインタフェースを用いてアカウントや宿泊用パスワードＳＪ２を入力させることにより、プリント端末２７から電子メールＭＥ１や添付ファイルＦ１の内容の印刷出力を行う構成としてもよい。ただし当該プリント端末２７が、情報をタッチパネル等から入力でき、サーバと通信を行うことができ、印刷機とのインタフェースを持つ情報端末機能付きのＭＦＰ（複合機）をはじめとする情報処理装置である場合には、このような連携は必要ない。
【００４７】
なお、仮想プリントサーバ２０は、多様なプリンタに対応する多様なプリンタドライバを搭載しているため、当該プリント端末２７が、どのような機種のプリンタ製品であっても、それに適合するデータ形式に電子メールＭＥ１やその添付ファイルＦ１を変換することができる。
【００４８】
また、パソコン２８は、ホテルＨＴ１のビジネスセンタなどに設置されたパーソナルコンピュータであり、パソコン２９は、ホテルＨＴ１の客室からＬＡＮ１２に接続するパーソナルコンピュータである。本実施形態の構成上、基本的に、当該パソコン２９は存在しなくてもよいが、ユーザＵ２がノート型パソコンなどを客室に持ち込んで使用するケースや、ホテルＨＴ１が客室にパソコンを設置してあるケースなどに、当該パソコン２９が存在する。
【００４９】
パソコン２８や２９を使用すれば、ユーザＵ２は、後述するステップＳ３２やＳ３５などでデータ形式を変換するまえの電子メールＭＥ１やその添付ファイルＦ１を取り扱い、閲覧し、必要ならば編集なども行うことができるので、利便性が高まる。
【００５０】
前記ＭＭＫ端末２１は、コンビニエンスストアや駅など、多くの人が集まる街中の随所に設置される情報処理装置で、ユーザ（例えば、Ｕ２）の操作に応じて仮想プリントサーバ２０に対し該当文書（例えば、電子メールＭＥ１，添付ファイルＦ１など）を転送するように要求し、転送されてきた文書を一時的に記憶して印刷出力するために利用される。印刷出力を行うための印刷機能は、ＭＭＫ端末２１自体が搭載している場合と、ＭＭＫ端末２１の近傍に設置された外部のプリンタ装置の印刷機能を利用する場合がある。
【００５１】
したがって、ＭＭＫ端末２１は、前記プリント端末２７とほぼ同等な装置であるとみることができるが、プリント端末２７がホテルＨＴ１のビジネスセンタの内部に設置されたものであるのに対し、ＭＭＫ端末２１は、ホテルＨＴ１の外部に設定されている点が異なる。
【００５２】
一方、当該フロント端末２３とＬＡＮ１２経由で通信するホテルサーバ２４は、例えば、図３に示す内部構成を有するものであってよい。
【００５３】
（Ａ−１−２）ホテルサーバの内部構成例
図３において、当該ホテルサーバ２４は、通信部４０と、制御部４１と、記憶部４２と、宿泊管理部４３と、データ格納部４４とを備えている。
【００５４】
このうち通信部４０は前記通信部３０に対応し、制御部４１は前記制御部３１に対応し、記憶部４２は前記記憶部３４に対応するので、その詳しい説明は省略する。
【００５５】
ただし制御部４１は、前記フロント端末２３の制御部３１と異なり、必要が生じたときに、通信部４０を介して前記仮想プリントサーバ２０と通信する機能を備えている。
【００５６】
前記宿泊管理部４３は、ホテルＨＴ１の客（例えば、ユーザＵ２）による宿泊の予約、チェックイン、チェックアウトなどに関する情報（宿泊管理情報）を管理する部分で、必要に応じて、これらの宿泊管理情報を仮想プリントサーバ２０へ通知する。宿泊管理部４３内で、当該宿泊管理情報は、予約データベースＤＢ２にまとめられて管理される。当該宿泊管理部４３の機能は、ホテルの予約を管理するホテル予約システムに対応する。
【００５７】
本実施形態は、仮想プリントサーバ２０内に一時的なメールボックスを用意し、当該メールボックスを介した電子メールの送受信（主として、受信）、および受信した電子メールやその添付ファイルの内容を、データ形式を変換して、宿泊客（ここでは、ユーザＵ２）に提供することを内容とするサービスに特徴を有し、このサービスが行われる期間（サービス期間）は、基本的に、仮想プリントサーバ２０のある会員（例えば、ユーザＵ２）が、あるホテル（例えば、ＨＴ１）に宿泊している期間（チェックインからチェックアウトまで）であり、この期間を基本サービス期間とする。
【００５８】
ただしここでは、ユーザＵ２がホテルに対して宿泊の予約を行う場合には、予約の受付が行われてからチェックインが行われるまでの期間（第１拡張期間）も包含するように、当該サービス期間を拡張するものとする。同様に、チェックアウトが行われたあと所定の期間（第２拡張期間）も包含するように、当該サービス期間を拡張するものとする。チェックイン前やチェックアウト後にも、当該ユーザＵ２宛ての電子メールが届く可能性があるからである。
【００５９】
したがって、サービス期間をＳＴ１とし、そのサービス期間に含まれる第１拡張期間をＳＴ１１、基本サービス期間をＳＴ１２，第２拡張期間をＳＴ１３とすると、次の式（１）の関係が成立する。
【００６０】
ＳＴ１＝ＳＴ１１＋ＳＴ１２＋ＳＴ１３ …（１）
また、ここでは、ユーザＵ２がホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとしているが、当該ホテルＨＴ２に関するサービス期間ＳＴ２に関しても、第１拡張期間をＳＴ２１、基本サービス期間をＳＴ２２，第２拡張期間をＳＴ２３とすると、次の式（２）の関係が成立する。
【００６１】
ＳＴ２＝ＳＴ２１＋ＳＴ２２＋ＳＴ２３ …（２）
ホテルＨＴ１に対する第２拡張期間ＳＴ１３とホテルＨＴ２に対する第１拡張期間ＳＴ２１（または、基本サービス期間ＳＴ２２）を連続的に結合することができる。
【００６２】
なお、ユーザＵ２が予約をすることなくホテル（ＨＴ１またはＨＴ２）に宿泊することもあり得るが、その場合には、前記第１拡張期間ＳＴ１１，ＳＴ２１は存在しないことは当然である。さらに、基本サービス期間ＳＴ１２，ＳＴ２２は、ユーザＵ２のそのホテルに対する宿泊日数に対応して動的に変化することは当然である。
【００６３】
第１拡張期間ＳＴ１１、ＳＴ２１や第２拡張期間ＳＴ１３，ＳＴ２３も動的に変化させてもよいが、ここでは、一定の固定期間を設定するものとする。第１拡張期間（例えば、ＳＴ１１）を示す固定期間は、予約の受付が行われた日時から第１拡張期間ＳＴ１１が開始するケースで最大値となるが、予約の受付からチェックインまでの期間が長い場合などには、必ずしも予約の受付が行われた日時から開始させず、チェックインが予定されている日時の所定期間前（例えば、２週間前）から第１拡張期間ＳＴ１１が開始させるようにしてもよい。
【００６４】
また、第１拡張期間を示す固定期間は、すべてのホテルに関して統一してもよく、ホテルごとに相違させてもよい。
【００６５】
第２拡張期間ＳＴ１３，ＳＴ２３を示す固定期間のほうには第１拡張期間ＳＴ１１，ＳＴ２１のような制約はないため、どのように設定することも基本的に自由であるが、一例としては、１週間程度であってよい。ユーザＵ２がホテルＨＴ１，ＨＴ２に連続して宿泊する場合、通常は、ホテルＨＴ１をチェックアウトした当日、またはその翌日には、ホテルＨＴ２にチェックインするものと考えられるので、第２拡張期間ＳＴ１３が１週間程度あれば、確実に、次の基本サービス期間ＳＴ２２（または第１拡張期間ＳＴ２１）と連続的に結合することができる。
【００６６】
同じユーザ（ここでは、Ｕ２）に対する第２拡張期間ＳＴ１３が終了する前に、次の第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が開始した場合には、その時点で、当該第２拡張期間ＳＴ１３は終了し、第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が優先されるようにするとよい。すでにチェックアウトしたホテル（例えば、ＨＴ１）に関する第２拡張期間ＳＴ１３よりも、現に宿泊しているホテル（例えば、ＨＴ２）に関する基本サービス期間ＳＴ２２（または第１拡張期間ＳＴ２１）を優先したほうが、電子メールの宛先であるユーザＵ２にとっても、電子メールの送信元であるユーザ（例えば、Ｕ１）にとっても、有利であると考えられるからである。
【００６７】
なお、宿泊スケジュールにも依存するが、２つのホテルＨＴ１，ＨＴ２に連続的に宿泊する場合、最初のホテルＨＴ１に関する基本サービス期間ＳＴ１２が終了すると同時、またはそれ以前に、次のホテルＨＴ２に対する第１拡張期間ＳＴ２１が開始することが多いものと考えられるが、そのようなケースでは、最初のホテルＨＴ１に関する第２拡張期間ＳＴ１３は存在せず、基本サービス期間ＳＴ１２の終了後ただちに、次のホテルＨＴ２に関する第１拡張期間ＳＴ２１が開始する形になる。この場合にはまた、最初のホテルＨＴ１に関する基本サービス期間ＳＴ１２と次のホテルＨＴ２に関する第１拡張期間ＳＴ２１が重複することも多いが、重複した場合には、重複している期間に関して、最初のホテルＨＴ１に関する基本サービス期間ＳＴ２２を優先するほうが望ましい。
【００６８】
このような期間のあいだ前記サービスを提供するために使用されるメールボックスの本体は一貫して仮想プリントサーバ２０側に存在するため、前記宿泊管理部４３が管理している宿泊管理情報（例えば、予約の受付が行われた日時、予約の内容、実際にチェックインが行われた日時、チェックアウトが行われた日時など）を、ホテルサーバ２４から、仮想プリントサーバ２０へ通知する必要がある。各ホテル（例えば、ＨＴ１，ＨＴ２）から届く当該宿泊管理情報に応じて、仮想プリントサーバ２０は、メールボックスの生成や削除、転送先の変更などの制御を実行することになる。
【００６９】
ホテルサーバ２４から仮想プリントサーバ２０へ宿泊管理情報を届けるための通信プロトコルとしては様々なものを利用することができるが、例えば、ＦＴＰプロトコルやＨＴＴＰプロトコルを利用することができる。また、ＳＯＡＰプロトコルを用いるＷｅｂサービスを活用してもよい。
【００７０】
前記データ格納部４４は主として、後述するように、電子メールＭＥ１やその添付ファイルＦ１からデータ形式を変換して得られたデータ（出力用データ）を格納する部分で、メールボックス部６４（図２参照）と同様、（期限付きアカウント名（メールボックスＩＤ）で区別して）各ユーザ（例えば、Ｕ２）ごとに設けられ、その物理的な実体は、記憶部４２上に確保された記憶領域のうちの１つであり、論理的には、フォルダ（ディレクトリ）の１つである。ここで、電子メールＭＥ１をテレビ端末２５のためのデータ形式に変換して得られる出力用データをＯＭ１とし、添付ファイルＦ１をテレビ端末２５のためのデータ形式に変換して得られる出力用データをＯＦ１とする。
【００７１】
同様に、電子メールＭＥ１を電話端末２６のためのデータ形式に変換して得られる出力用データをＯＭ２とし、添付ファイルＦ１を電話端末２６のためのデータ形式に変換して得られる出力用データをＯＦ２とし、電子メールＭＥ１をプリント端末２７のためのデータ形式（ＭＭＫ端末２１のためのデータ形式も同じであってよい）に変換して得られる出力用データをＯＭ３とし、添付ファイルＦ１をプリント端末２７のためのデータ形式に変換して得られる出力用データをＯＦ３とする。
【００７２】
ここで、メールボックスＩＤとは、個々の前記メールボックス部（例えば、６４）を一意に識別するために付与される識別情報である。前記期限付きアカウント名と当該メールボックスＩＤは、１対１の対応関係さえ確保されていれば必ずしも同じ値である必要はないが、管理の効率化のためには同じ値とすることも望ましい。
【００７３】
なお、前記パソコン２８や２９を使用するケースに備え、データ形式を変換するまえの電子メールＭＥ１やその添付ファイルＦ１も、当該データ格納部４４に格納しておくとよい。
【００７４】
前記仮想プリントサーバ２０は例えば図２に示す内部構成を備えたものであってよい。
【００７５】
（Ａ−１−３）仮想プリントサーバの内部構成例
図２において、当該仮想プリントサーバ２０は、通信部５０と、制御部５１と、記憶部５２と、メールサーバ部５３と、ユーザ管理部５４と、アカウント発行部５５と、アカウント蓄積部５６と、アカウント比較部５７と、宿泊スケジュール管理部５８と、データ変換部５９と、転送アドレス登録部６０と、転送制御部６１と、通知メール生成部６２と、メールボックス管理部６３と、メールボックス部６４とを備えている。
【００７６】
このうち通信部５０は前記通信部４０に対応し、制御部５１は前記制御部４１に対応し、記憶部５２は前記記憶部４２に対応するので、その詳しい説明は省略する。
【００７７】
ただし構成要素５３〜６４の多くは、機能上は、当該制御部５１に含まれ、物理的な実体は、記憶部５２に存在するものである。
【００７８】
構成要素５３〜６４のうちメールボックス部６４は、仮想プリントサーバ２０内に一時的に用意される上述したメールボックスに対応する部分である。図２上では記憶部５２の外に図示しているが、当該メールボックス部６４の物理的な実体は、記憶部５２上に確保された記憶領域のうちの１つであり、論理的には、フォルダ（ディレクトリ）の１つである。
【００７９】
前記サービス期間（必要に応じて、第１拡張期間なども含む）の開始にともなって、個々のユーザ（ここでは、Ｕ２）のためのメールボックス部６４が生成され、サービス期間（最後の第２拡張期間なども含む）の終了にともなって当該ユーザＵ２のためのメールボックス部６４が削除される。このような生成や削除を行うのは、前記メールボックス管理部６３である。一般的なメールボックスの管理は、メールサーバ部５３の役割であるが、本実施形態では、当該メールボックス管理部６３が、ホテルサーバ２４から供給される前記宿泊管理情報に応じて、メールボックス部６４の生成や削除を行う。
【００８０】
メールサーバ部５３は、メールサーバ機能に対応する部分である。本実施形態で電子メールＭＥ１はインターネット１１上を転送されるため、メール配送用のプロトコルはＳＭＴＰである。着信した電子メール（例えば、ＭＥ１）を当該メールボックス部６４から取り出すためのプロトコルとしては、ＰＯＰ３やＩＭＡＰ４を利用するのが一般的であるが、本実施形態の構成上、ユーザＵ２が直接、仮想プリントサーバ２０にログインして当該メールボックス部６４から電子メールなどを取り出すことは基本的に行わず、電子メールや添付ファイルは出力用データに変換されたあと、ホテルサーバ２４のデータ格納部４４で保存され、ユーザＵ２が電子メールや添付ファイルの内容を知りたいときには、前記テレビ端末２５などを介して当該データ格納部４４から出力用データを取り出す手順となる。このときの取り出しでは、後述する期限付きアカウント名などを用いてユーザ認証を行うため、必要に応じて、ＰＯＰ３やＩＭＡＰ４に対応したプロトコルを利用することもできる。
【００８１】
ただし、ユーザＵ２がホテルの外部に設置されているＭＭＫ端末２１から前記出力データの出力（印刷出力や画面表示出力）を行う場合には、ホテルサーバ２４などを経由せずに、ユーザＵ２が直接、仮想プリントサーバ２０にログインして当該メールボックス部６４から電子メールなど（例えば、前記出力用データＯＭ３，ＯＦ３）を取り出す形になる。この取り出しでは、ＰＯＰ３やＩＭＡＰ４などを利用することが可能である。
【００８２】
したがって、当該メールサーバ部５３は、ＳＭＴＰサーバやＰＯＰサーバなどに相当する機能を備えることになる。
【００８３】
すなわち、電子メールＭＥ１（およびその添付ファイルＦ１）はＳＭＴＰプロトコルにしたがってインターネット１１上を配送されてきて、ユーザＵ２のための前記メールボックス部６４に着信し、出力時（例えば、ＭＭＫ端末２１からの印刷出力や画面表示出力などの際）には、ＰＯＰ３などの取り出し用プロトコルにしたがって、メールＭＥ１や添付ファイルＦ１のデータ形式を変換した後のデータが、前記ホテルサーバ２４などへ転送される手順となる。
【００８４】
ユーザ管理部５４は、当該仮想プリントサーバ２０の会員（ユーザＵ２もその一人）に関する会員情報を管理する部分である。
【００８５】
仮想プリントサーバ２０からみた会員は大きく２つに分けることができる。その１つは、ホテルＨＴ１やＨＴ２のようなホテル会員であり、もう１つは、ユーザＵ２のような個人会員である。個人会員に関して当該ユーザ管理部５４が管理する会員情報は、いわゆる個人情報である。当該個人情報には様々なものがあり得るが、例えば、個人会員の住所、氏名、ユーザＩＤ、パスワード（前記ＰＷ２）、電子メールアドレスなどが含まれ得る。そのユーザに対し、すでに期限付きアカウント名を発行している場合には、その期限付きアカウント名も、当該個人情報の一部としてユーザ管理部５４で管理するようにしておくとよい。また、各ホテルサーバ２４などから供給される前記宿泊管理情報も、個人会員ごとに整理されて当該ユーザ管理部５４に格納するものであってよい。
【００８６】
ホテル会員の会員情報も基本的に個人会員の会員情報と同じであってよく、ホテルの名称、所在地、ホテルＩＤ（ユーザＩＤに対応）などが、ユーザ管理部５４で管理される。ホテル会員に関するこれらの会員情報は、ユーザ管理部５４に搭載されるホテルデータベースＤＢ１に格納されるものとする。前記サービス期間ＳＴ１，ＳＴ２の具体値なども、ホテルごとに整理して当該ホテルデータベースＤＢ１に格納しておくことができる。
【００８７】
このうちユーザＩＤは、仮想プリントサーバ２０内において各個人会員を一意に識別するための識別情報であり、ホテルＩＤは、各ホテル会員を一意に識別するための識別情報である。
【００８８】
また、パスワードは、仮想プリントサーバ２０内に保管されたデータ（例えば、前記電子メールＭＥ１，添付ファイルＦ１や、その出力用データ）をＭＭＫ端末２１などから出力する際に各個人会員に入力させる情報である。
【００８９】
また、電子メールアドレスは、仮想プリントサーバ２０が提供する仮想プリントサービス以外でも使用される各個人会員の電子メールアドレスのことである。
【００９０】
ここで、前記ユーザＵ２の電子メールアドレスは、ＡＤ２とする。
【００９１】
ユーザＵ２の氏名が例えば「山田太郎」である場合、当該電子メールアドレスＡＤ２の具体的な値は、「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｎｅ．ｊｐ」などであってよい。
【００９２】
この電子メールアドレスの値のうち、＠マークより左側に記述される文字列をアカウント名と呼び、＠より右側に記述される文字列をドメイン名と呼ぶ。ドメイン名は階層構造を持っており、この例では、「ｊｐ」が最も上位（ただし階層構造の最上位にあたる根には名前が付与されていない。この「ｊｐ」は、根の下位に位置するいくつかのドメインのなかの１つである）の階層に属するトップレベルドメイン（ＴＬＤ（この例では、ｃｃＴＬＤ））であり、「ｎｅ」は当該「ｊｐ」に包含され（すなわち、当該「ｊｐ」の下位にあたる）、「ｄｄｄ」は当該「ｎｅ」に包含される関係となる。ここで、「ｎｅ」は組織の分類を示し、「ｄｄｄ」はその分類に属する具体的な組織の名称（組織名）を示している。必要ならば、組織名の下位にさらに階層を追加することで、１つの組織内に複数のサブドメインを設定することもできる。階層の数に制約はないため、追加する階層の数は複数であってもよく、サブドメインのなかにさらに複数のサブドメインを設定することもできる。
【００９３】
アカウント名は通常、ＩＳＰ（あるいは、企業内のイントラネットの管理者）などが自ドメイン内で電子メールユーザ（ここでは、ユーザＵ２）を識別するために用いる文字列であり、どのような文字列を許すかは、基本的に、電子メールユーザとＩＳＰなどの関係において決まり、通常、ＩＳＰなどは、そのドメイン（ここでは、「ｄｄｄ．ｎｅ．ｊｐ」）の内部で、当該電子メールユーザを一意に識別することができるアカウント名でさえあれば、ユーザＵ２が希望した文字列をそのユーザのアカウント名として登録する。当該アカウント名は、ユーザＵ２がＩＳＰのメールサーバなどに確保された自身のメールボックスに着信した電子メールを取り出す際などに利用される。
【００９４】
したがって、アカウント名自体に、ドメインと同様な階層構造を持たせることも、ＩＳＰなどの自由であるが、一般的にはそのようなことは行われていない。
【００９５】
ＲＦＣの規格（ＲＦＣ８２１）により、＠マークの左右（すなわち、アカウント名とドメイン名）の文字数は、最大、６４文字に制限されているが、メールサーバ側のＯＳの種類などにより、実際のＩＳＰなどでは、当該６４文字よりはるかに少ない文字数に制限（例えば、アカウント名を８文字以内に制限）することもある。ログインの際の文字数などは、ＯＳの仕様によって決まっているからである。
【００９６】
アカウント発行部５５は、ユーザ管理部５４に登録されている当該電子メールアドレスＡＤ２をもとに、仮想プリントサーバ２０の内部においてユーザ（例えば、Ｕ２）がいずれかのホテル会員に宿泊（予約なども含む）を行っている期間にのみ使用する一時的なアカウント名（期限付きアカウント名）を発行する部分である。期限付きアカウント名の発行は、仮想プリントサーバ２０に会員登録する際に行ってもよく、すでに会員登録を行ったユーザが発行を要求したときに行うようにしてもよい。なお、アカウントという用語には課金の意味が含まれているが、ここでは必ずしも、期限付きアカウント名を利用してユーザＵ２に課金を行う必要はなく、本実施形態で説明するサービスは無料奉仕として提供するものであってよい。
【００９７】
この期限付きアカウント名には、ユーザＵ２自身やユーザＵ２宛てに電子メール（例えば、ＭＥ１）を送信するユーザ（例えば、Ｕ１）が記憶しやすい文字列であることが求められる。
【００９８】
記憶しやすい文字列とするには、ユーザＵ２自身や、ユーザＵ２に何回も電子メールを送信したことのあるユーザ（例えば、Ｕ１）が慣れている前記電子メールアドレスＡＤ２をもとに、当該期限付きアカウント名の文字列を決めることが有効である。例えば、前記電子メールアドレスＡＤ２の＠マークを、単なる区切り記号として使用されるドット（すなわち、「．」）に置換した文字列である「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」を、当該期限付きアカウント名として利用することも望ましい。必要に応じて、＠マークをドットと置換するのではなく、単に除去して得られる文字列（「ｔａｒｏｕ．ｙａｍａｄａｄｄｄ．ｎｅ．ｊｐ」）などを期限付きアカウント名として利用してもよい。
【００９９】
ここでは、他の記号に置換したり、単に除去したりして電子メールアドレスＡＤ２内の＠マークを除いているが、送信元のメールサーバ（図示せず）などは、＠マークから右側の文字列をドメイン名と解釈してＤＮＳサーバに対する問い合わせを行い、通信相手となるメールサーバ（例えば、仮想プリントサーバ２０またはメールサーバ部５３）を指定するためのＩＰアドレスを取得するが、もし＠マークを残したまま、電子メールアドレスＡＤ２を期限付きアカウント名として利用すれば、当該期限付きアカウント名を含む新たな電子メールアドレスＡＤ２１内には、＠マークが２つ含まれることとなり、ＤＮＳサーバへの問い合わせ等が正常に行えず、送信元のユーザ（例えば、Ｕ１）へエラーメールの返送などが行われる可能性があるからである。
【０１００】
前記仮想プリントサーバ２０のドメイン名が例えば「ｖｉｒｔｕａｌｐ．ｃｏｍ」であるとすると、前記期限付きアカウント名を含む電子メールアドレスＡＤ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ＠ｖｉｒｔｕａｌｐ．ｃｏｍ」となる。
【０１０１】
このようにして、アカウント発行部５５は、ユーザＵ２やＵ１に記憶しやすい期限付きアカウント名を発行することができるが、この方法では、期限付きアカウント名の文字列の文字数が多くなる傾向がある。
【０１０２】
現実的に、前記６４文字の制限を越えることは、ほとんどあり得ないとしても、期限付きアカウント名の文字数が多いと、期限付きアカウント名を各種の装置に入力する必要のあるユーザＵ２やＵ１にとって、入力時の操作負担が大きくなって不便である。この操作負担は例えば次のような方法によって期限付きアカウント名の文字数を削減することにより、軽減することができる。
【０１０３】
すなわち、アカウント蓄積部５６に、これまで発行したすべての期限付きアカウント名（過去に発行し、現時点では利用されていない期限付きアカウント名も含む）を蓄積しておき、電子メールアドレスＡＤ２を仮想プリントサーバ２０に登録したユーザＵ２に期限付きアカウント名を発行する際には、その電子メールアドレスＡＤ２の＠マークをドットで置換した文字列（例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」）を、アカウント蓄積部５６に蓄積されている各期限付きアカウント名と比較する。
【０１０４】
この比較は、当該文字列の下位の階層から順番に行い、すでに蓄積されているいずれの期限付きアカウント名とも一致しなくなるところで停止する。
【０１０５】
当該文字列は、グローバルな範囲で一意な電子メールアドレスＡＤ２の＠マークをドットで置換して得られたものであるから、当然、グローバルな範囲で一意である。したがって、最上位の階層（例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」の場合ならば、「ｊｐ」）まで比較すれば、必ず一致しないことが保証されている。なお、ここで一致とは、相互に比較される２つの文字列が、全文字について完全に一致していることであり、文字数が相違するために一部だけ一致しているようなケースは、一致しないものとみなす。例えば、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」と「ｔａｒｏｕ」を比較する場合、一致しないとの比較結果が得られる。
【０１０６】
なお、上述したサブドメインを設定し、「ｖｉｒｔｕａｌｐ」の下位に例えばホテルごとのサブドメインを設定した場合（例えば、ホテルＨＴ１とＨＴ２を異なるサブドメイン（例えば、「ｈｔ１」、「ｈｔ２」など）に対応付ける場合など）には、比較対象となるすでに発行されている期限付きアカウント名の探索範囲は、そのサブドメインの内部だけとしても、そのサブドメイン内における期限付きアカウント名の一意性は確保できる。
【０１０７】
ただし、探索範囲をサブドメイン内に限定すると、発行した期限付きアカウント名の一意性はそのサブドメインのなかでしか確認されていないため、ここで取り上げているように、一人のユーザＵ２が複数のホテルに宿泊するケースでは、同じユーザ（例えば、Ｕ２）でも、宿泊するホテルが変われば使用する期限付きアカウント名も変更しなければならないことが起こり得、利便性が犠牲になる。また、電子メールの送信元のユーザ（例えば、Ｕ１）の立場からすると、電子メールの宛先メールアドレスの記述に、サブドメイン（個々のホテル）まで指定しなければならず、ユーザＵ２の宿泊スケジュールを知っていなければ、電子メールを送信できない不便がある。したがってここでは、サブドメインの設定は行わないものとし、送信元ユーザＵ１は宛先のユーザＵ２が宿泊しているホテルを特定しないまま、電子メール（例えば、ＭＥ１）を送信できるものとする。
【０１０８】
この場合にはまた、最初に発行する時点の比較で、各期限付きアカウント名は、ドメイン名「ｖｉｒｔｕａｌｐ」に属する全範囲（この範囲には、ホテルＨＴ１，ＨＴ２など、仮想プリントサーバ２０の全ホテル会員が含まれる）における一意性が確認されることになる。なお、ユーザＵ１，Ｕ２にサブドメインの存在を意識させない限り、システム内部でこのようなサブドメインを設定して処理に活用することは自由である。
【０１０９】
以上のような比較によれば、ユーザＵ２に対して期限付きアカウント名を発行する時点で、前記アカウント蓄積部５６に、例えば、「ｔａｒｏｕ」が蓄積されていなければ、当該「ｔａｒｏｕ」が、ユーザＵ２の期限付きアカウント名として発行される。また、「ｔａｒｏｕ」は蓄積されているものの「ｔａｒｏｕ．ｙａｍａｄａ」が蓄積されていなければ、当該「ｔａｒｏｕ．ｙａｍａｄａ」が、ユーザＵ２の期限付きアカウント名として発行される。
【０１１０】
同様に、「ｔａｒｏｕ」と「ｔａｒｏｕ．ｙａｍａｄａ」はすでに蓄積されているものの、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ」が蓄積されていなければ、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ」が、ユーザＵ２の期限付きアカウント名として発行される。
【０１１１】
電子メールアドレスＡＤ２などのアカウントには通常、階層構造は存在しないが、ここでは、左側ほど下位の階層に属するものとしている。また、必ずしもこのように比較する文字列をドット単位で増加させていく必要はなく、１文字単位で増加させるようにしてもよい。ただし電子メールアドレスにおけるドットは、意味の区切りを示すために利用されることが多く、ドット単位で増加させることによって、人間にとっての可読性の高さ（理解しやすさ）を維持することができる。
【０１１２】
なお、過去に発行され、現時点では利用されていない期限付きアカウント名でも、アカウント蓄積部５６に蓄積されている限り当該比較の対象とするのは、同じユーザ（例えば、Ｕ２）がホテルに宿泊する際には、同じ期限付きアカウント名を再利用させる構成とするためである。同じ期限付きアカウント名を他のユーザに発行することを許すと、本来、そのユーザに宛てたものではない電子メールがそのユーザに読まれる等の不都合が生じる可能性が高まるからである。ただし、ある期限付きアカウント名の発行を受けていたユーザ（例えば、Ｕ２）が仮想プリントサービスの会員でなくなった場合などには、十分な期間を置いた後、当該期限付きアカウント名を他の個人ユーザに発行することも可能である。
【０１１３】
このような比較を実行するのは、前記アカウント比較部５７である。
【０１１４】
データ変換部５９は、メールボックス部６４に着信した電子メール（例えば、ＭＥ１）やその添付ファイル（例えば、Ｆ１）のデータ形式を、前記テレビ端末２５，電話端末２６，またはプリント端末２７に適合するデータ形式の前記出力用データＯＭ１〜ＯＭ３やＯＦ１〜ＯＦ３に変換する部分である。
【０１１５】
変換後に得られる出力用データは、各ユーザ（例えば、Ｕ２）のメールボックス部（例えば、６４）とは別個に設けた記憶領域に格納するようにしてもよいが、ここでは、メールボックス部（例えば、６４）に格納するものとする。
【０１１６】
宿泊スケジュール管理部５８は、仮想プリントサーバ２０の各個人会員（例えば、Ｕ２）の宿泊スケジュールを管理する部分である。この宿泊スケジュールには、個々のホテル（例えば、ＨＴ１）における宿泊スケジュールだけでなく、複数のホテルにまたがる宿泊スケジュール（例えば、ホテルＨＴ１に宿泊したあと、何月何日からホテルＨＴ２に宿泊する等）も含まれ得る。当該宿泊スケジュールは、前記メールボックスＩＤ別に構成されたスケジュールファイルＦ１１に格納される。当該スケジュールファイルＦ１１に、実際の宿泊管理情報の内容を格納するようにしてもよい。
【０１１７】
転送制御部６１は、メールボックス部６４に着信した電子メールおよびその添付ファイルの転送を制御する部分である。本実施形態では、あるホテル（例えば、ＨＴ１）に対し、あるユーザ（例えば、Ｕ２）のチェックインが行われたとき、メールボックス部６４内に保存されていた電子メールおよびその添付ファイルのデータ形式を変換したあとの出力用データ（例えば、ＯＭ１〜ＯＭ３，ＯＦ１〜ＯＦ３）を、ホテルサーバ２４の前記データ格納部４４へ転送する。この場合の転送先のアドレスはホテルごとに一定（もちろん、ユーザごとの区別は必要）であってよいので、予めホテルごとに転送アドレス登録部６０に登録しておくことができる。ユーザＵ２がホテルＨＴ１の次に宿泊するホテルＨＴ２のホテルサーバ（２４に対応）のデータ格納部（４４に対応）へ転送する場合も、これと同様である。
【０１１８】
仮想プリントサーバ２０側では、各ユーザ（例えば、Ｕ２）の宿泊スケジュールと各ユーザに発行した期限付きアカウント名が分かっているため、ユーザＵ２が宿泊する予定のホテル（例えば、ＨＴ１）に出力用データを転送するホテルに出力用データを転送する際、そのユーザＵ２の期限付きアカウント名をホテルサーバ２４に伝えることができ、ホテルサーバ２４では、前記メールボックス部６４と同様、期限付きアカウント名ごとに区別して出力用データを該当するデータ格納部（例えば、４４）に格納しておくことができる。
【０１１９】
なお、上述したサービス期間（例えば、ＳＴ２）が終了した時点で、メールボックス部（例えば、６４）に未読の電子メールやその添付ファイルが残っている場合や、チェックアウト後の前記第２の拡張期間内に着信した電子メールが存在する場合などには、個々のユーザ（例えば、Ｕ２）が個別に指定した転送先へ転送するようにしてもよい。その場合、転送のための通信アプリケーションとして電子メールを用いるなら、前記出力用データへデータ形式を変換する前の電子メールや添付ファイルもメールボックス部６４内に残しておき、その電子メールや添付ファイルを転送するようにするのが効率的である。
【０１２０】
この場合にはまた、転送先の電子メールアドレスとして、ユーザＵ２自身の前記電子メールアドレスＡＤ２などをそのまま利用することができるが、ＡＤ２以外の宛先への転送を希望する場合などには、動的にユーザＵ２が転送先のアドレスを指定できるようにしてもよい。
【０１２１】
いずれにしても転送先のアドレスは転送アドレス登録部６０に登録されており、転送制御部６１は、当該転送アドレス登録部６０に登録されている転送先アドレスへデータ（例えば、データ形式変換前の電子メールや添付ファイル）を転送する。
【０１２２】
通知メール生成部６２は、前記第２の拡張期間内に電子メールが届いた場合、その電子メールの送信元に対して送信するための所定の通知メールを生成する部分である。この通知メールは、すでに当該ユーザ（例えば、Ｕ２）は、ホテル（例えば、ＨＴ２）に宿泊していない（サービス期間（例えば、前記ＳＴ２）が経過した）ので、これ以上、電子メールを送らないように依頼する内容の電子メールであってよい。通知メール生成部６２により自動的に生成された当該通知メールは、当該送信元の電子メールアドレスに宛てて、自動的に送信される。
【０１２３】
以下、上記のような構成を有する本実施形態の動作について、図５〜図１１のフローチャートを参照しながら説明する。
【０１２４】
図５のフローチャートはＳ１１〜Ｓ２１の各ステップから構成されており、図６のフローチャートはＳ１１〜Ｓ２２の各ステップから構成されており、図７のフローチャートはＳ３０〜Ｓ３８の各ステップから構成されており、図８のフローチャートはＳ４０〜Ｓ４５の各ステップから構成されており、図９のフローチャートはＳ３０〜Ｓ５８の各ステップから構成されており、図１０のフローチャートはＳ６０〜Ｓ６６の各ステップから構成されており、図１１のフローチャートはＳ７０〜Ｓ７３の各ステップから構成されている。
【０１２５】
（Ａ−２）実施形態の動作
仮想プリントサーバ２０に対するホテル会員であるホテルＨＴ１，ＨＴ２の会員登録、および個人会員であるユーザＵ２の会員登録はすでに完了しているものとし、上述したように、ユーザＵ２が、ホテルＨＴ１に宿泊したあと、ホテルＨＴ２に宿泊するものとする。
【０１２６】
予約なく宿泊することもあり得るが、図５の例では、ユーザＵ２はホテルＨＴ１に宿泊する前に、ホテルＨＴ１に宿泊の予約を行い（Ｓ１１）、その予約に関する情報が前記フロント端末２３に入力され、予約の受付・登録が行われる（Ｓ１２）。予約の情報は、前記宿泊管理情報の一部であるから、ホテルサーバ２４の宿泊管理部４３に管理され、ホテル会員としてのホテルＨＴ１のホテルＩＤ、予約者の氏名（ユーザＵ２の氏名）などとともに、ホテルサーバ２４を介して前記仮想プリントサーバ２０に通知される（Ｓ１３，Ｓ１４）。この通知は、仮想プリントサーバ２０に対し、メールボックス部６４の生成を依頼する意味をも有する。
【０１２７】
この通知を受信すると、仮想プリントサーバ２０は、通知の送信元のホテルサーバ２４の認証を行い、認証結果がＯＫであると（Ｓ１５）、前記期限付きアカウント名を発行する（Ｓ１６）。この認証は、予め前記ホテルデータベースＤＢ１に格納されている情報をもとに実行する。当該認証のために必要ならば、ホテルごとに異なる暗号鍵、パスワード、ハッシュ関数などの情報を、前記ホテルデータベースＤＢ１に格納しておくとよい。
【０１２８】
期限付きアカウント名を発行するステップＳ１６の詳細は、例えば、図１１のフローチャートに示す通りであってよい。
【０１２９】
上述したように、期限付きアカウント名の発行時点には様々なものがあり得るが、図１１では、仮想プリントサーバ２０が、いずれかのホテル会員のホテルサーバ（例えば、２４）から送信された宿泊管理情報を受信した時点で、期限付きアカウント名を発行している（Ｓ７０，Ｓ７１）。
【０１３０】
また、期限付きアカウント名を構成する具体的な値を決定する際には、前記アカウント比較部５７の機能を利用して、できるだけ短い文字列からなる期限付きアカウント名を発行することも望ましいが、ステップＳ７１では、単純に、ユーザＵ２の電子メールアドレスＡＤ２で、＠マークをドットに置き換えた文字列をそのまま、当該ユーザＵ２の期限付きアカウント名ＡＣ２１としている。
【０１３１】
この場合、上述したように、電子メールアドレスＡＤ２の具体的な値が「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｎｅ．ｊｐ」であり、前記仮想プリントサーバ２０のドメイン名が「ｖｉｒｔｕａｌｐ．ｃｏｍ」であるとすると、当該期限付きアカウント名ＡＣ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ」となり、期限付きアカウント名ＡＣ２１を含む電子メールアドレスＡＤ２１は、「ｔａｒｏｕ．ｙａｍａｄａ．ｄｄｄ．ｎｅ．ｊｐ＠ｖｉｒｔｕａｌｐ．ｃｏｍ」となる。
【０１３２】
なお、上述したように、同じユーザ（ここでは、Ｕ２）に関して同じ期限付きアカウント名（例えば、ＡＣ２１）を再利用する構成を取る場合、アカウント蓄積部５６にすでに当該ユーザＵ２に発行済みの期限付きアカウント名が蓄積されていれば、電子メールアドレスＡＤ２の＠マークをドットに置き換える等の処理を行うことなく、蓄積されている期限付きアカウント名をそのまま再発行すればよい。
【０１３３】
発行（または再発行）した期限付きアカウント名ＡＣ２１をユーザＵ２に通知する手段としては様々な方法が考えられるが、ステップＳ７２，Ｓ７３では、電子メールを用いて通知している。なお、ステップＳ７２で発行しているパスワードは、ユーザＵ２が前記電子メールＭＥ１や添付ファイルＦ１の内容を知るために、ホテルサーバ２４にログインするためのパスワードであるが、例えば、前記宿泊用パスワードＳＪ２と同じものであってよい。
【０１３４】
当該パスワードは、発行した期限付きアカウント名ＡＣ２１とともに電子メールを用いてユーザＵ２に通知される。この電子メールには暗号化や電子署名などのセキュリティ対策を施したほうがよいことは当然である。
【０１３５】
当該期限付きアカウント名ＡＣ２１の発行や通知を行ったあと、図５のステップＳ１７では、前記ステップＳ１４，Ｓ１５で受信した宿泊管理情報をもとに、ユーザＵ２のスケジュールを作成し、前記スケジュールファイルＦ１１に収容して保存する。このスケジュールは、単一のホテル（例えば、ＨＴ１）だけでなく、複数のホテル（ここでは、ＨＴ１，ＨＴ２）にまたがる宿泊のスケジュールである。
【０１３６】
次に、ステップＳ１８では、ユーザＵ２のための前記メールボックス部６４を生成（開設）している。
【０１３７】
なお、ステップＳ１８につづくステップＳ１９では、メールボックスＩＤ（期限付きアカウント名）であるＡＣ２１をホテルサーバ２４へ通知している。上述したように、ユーザＵ２に対しては、すでに図１１に示すステップＳ７３で通知済みであるが、ホテルサーバ２４に対しては、このステップＳ１９で期限付きアカウント名ＡＣ２１が通知される。この通知には、ホテルサーバ２４側で予約者（ここでは、ユーザＵ２）と期限付きアカウント名ＡＣ２１の対応関係が分かるように、当該期限付きアカウント名ＡＣ２１とともに、当該ユーザＵ２の個人情報（例えば、住所、氏名や、前記電子メールアドレスＡＤ２など）が含まれる。
【０１３８】
この通知を受けると、ホテルサーバ２４は、宿泊管理部４３の予約データベースＤＢ２に含まれているユーザＵ２の個人情報と対応付けて、当該期限付きアカウント名ＡＣ２１を予約データベースＤＢ２に格納する。
【０１３９】
なお、ステップＳ２１では、メールボックスＩＤ（期限付きアカウント名）ＡＣ２１を予約者（ここでは、ユーザＵ２）も受信しているが、ユーザＵ２に対して図１１に示すステップＳ７３で通知する場合には、当該ステップＳ２１は省略可能である。
【０１４０】
また、前記ステップＳ１６〜Ｓ１９の順番は必ずしも図示した通りである必要はない。例えば、上述したように、予約の受付からチェックインまでの期間が長く、チェックインが予定されている日時の所定期間前（例えば、２週間前）から第１拡張期間が開始するケースなどでは、ステップＳ１８はＳ１９のあとで実行されてもよい。
【０１４１】
なお、図６のフローチャートは、ホテルがＷｅｂサーバを公開しており、ユーザＵ２が当該Ｗｅｂサーバにアクセスすることによって予約などを行うケースを示しているが、実質的な処理の内容は図６とほぼ同様である。前記ホテルサーバ２４がＷｅｂサーバの機能を備え、ホテルＨＴ１のＬＡＮ１２において例えば前記ファイアウオールのＤＭＺ（Ｄｅｍｉｌｉｔａｒｉｚｅｄ Ｚｏｎｅ）などに設置され、公開されている場合などが、これに該当する。
【０１４２】
図６において、図５と同じ符号Ｓ１１〜Ｓ２１を付与した各ステップの処理は図５と同じなので、その詳しい説明は省略する。
【０１４３】
ただし図６ではＷｅｂアクセスが用いられるため、ステップＳ１２〜Ｓ１４でユーザＵ２からホテルＨＴ１へ供給される宿泊管理情報は、Ｗｅｂサーバとしてのホテルサーバ２４が提供するＷｅｂページ上に（フォームの仕組みを利用して用意される）各種入力欄などにユーザＵ２が必要事項を入力することによって、ホテルサーバ２４側に収集されることになる。
【０１４４】
また、図６のステップＳ１６などで発行される前記期限付きアカウント名ＡＣ２１やパスワードは、図６の場合でも、電子メールを用いて通知することも可能であるが、ＨＴＴＰレスポンスメッセージとして、ユーザＵ２側へ通知する構成とすることができる。
【０１４５】
なお、図６のステップＳ２２では、前記宿泊管理情報に対応する情報を前記ホテルサーバ２４の宿泊管理部４３に対応するホテル予約システムに供給し、前記予約データベースＤＢ２に格納しているが、このような処理は、例えば、ＣＧＩプログラムなどを利用して実現可能である。
【０１４６】
図７のフローチャートは、ユーザＵ２が宿泊の予約を行ってから、チェックインを実行するまでの期間（前記第１拡張期間に対応）の処理を示している。
【０１４７】
図７において、期限付きアカウント名ＡＣ２１を含む新たな電子メールアドレスＡＤ２１に宛てて電子メール（例えば、ＭＥ１）を送信すると（Ｓ３０）、当該電子メールＭＥ１は、受信されて、仮想プリントサーバ２０内の前記メールボックス部６４に着信する（Ｓ３１）。
【０１４８】
なお、図１の例では、ユーザＵ２とは異なるユーザＵ１が、ユーザＵ２宛ての当該電子メールＭＥ１を送信しているが、ユーザＵ２自身が当該電子メールＭＥ１を送信してもよいことは当然である。例えば、ユーザＵ２が自身のパソコン（２２）に保存しているファイルの内容を、ホテルＨＴ１（またはＨＴ２）に宿泊している時間を利用して閲覧したいと希望することもあり得、そのようなケースでは当該ファイルを添付ファイルＦ１とした電子メールＭＥ１を送信することになるからである。
【０１４９】
ステップＳ３１につづくステップＳ３２〜Ｓ３７の各処理では、電子メールＭＥ１や添付ファイルＦ１から上述した出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）を得るためのデータ形式の変換を実行している。所望のデータ形式の出力用データさえ得られれば、必ずしも図示した通りの順番で、図示した通りの処理を実行する必要はないが、図示の例では、前記出力用データＯＭ２，ＯＦ２を得るため、電子メールＭＥ１の内容を音声出力用のデータＯＭ２に変換し（Ｓ３２）、当該出力データＯＭ２をファイルに収容している（Ｓ３３）。これにより、電子メールＭＥ１や添付ファイルＦ１に含まれる自然言語などの文字列は、合成音声などによる音声出力が可能な状態となる。
【０１５０】
また、前記出力用データＯＭ１やＯＦ１を得るためには、添付ファイルＦ１を展開し（Ｓ３４）当該添付ファイルＦ１の内容に応じた画面イメージを作成したあと（Ｓ３５）、電子メールＭＥ１の本文部分や、必要に応じてメールヘッダの各フィールドの情報などを画面イメージに合成してテレビ出力用の当該出力用データＯＭ１やＯＦ１を生成している。
【０１５１】
さらに、出力用データＯＭ３やＯＦ３を得るためには、前記ステップＳ３５で生成した画面イメージ（画像データ）を用いて、添付ファイルＦ１の内容に対応する印刷出力用の出力用データＯＦ３としている。もちろん、前記ステップＳ３６で生成した画面イメージを用いて、電子メールＭＥ１の本文部分や、メールヘッダの各フィールドの情報などの内容に対応した印刷出力用のデータＯＭ３を生成してもよいことは当然である。
【０１５２】
これらステップＳ３２〜Ｓ３７は、電子メールＭＥ１の本文部分に有効な記述が存在し、添付ファイルＦ１が画像データ（静止画像データ）であるケースに対応する処理であるが、一般的には、例えば、添付ファイルＦ１のデータが静止画像データでないこともあり得る。添付ファイルＦ１のデータが、例えば、音声データや動画像データである場合には、処理は図示したものとは異なるものになる。
【０１５３】
音声データに対応する音声出力は、通常、プリント端末２７から印刷出力することはできず、テレビ端末２５から画面表示出力することもできないからである。したがって、前記ステップＳ３２やＳ３４の中で、元の添付ファイルＦ１のデータ形式（例えば、ＭＩＭＥタイプ）を判定し、その判定結果に応じて、実行するデータ形式変換処理（この変換処理では、さらに詳細なレベルでのデータ形式の整合性を獲得するため、例えば、ＭＩＭＥのサブタイプを一致させるような変換処理を実行する）の内容を決めたり、そのデータ形式変換処理を実行するか否かを決めたりすることも望ましい。
【０１５４】
なお、元の添付ファイルＦ１のデータが例えば音声データであっても、音声認識などの技術を利用して、当該音声データに対応する文字列を生成し、その文字列を示す画像データを生成する場合には、音声データに対応する当該画像データをもとに、プリント端末２７から印刷出力を行ったり、テレビ端末２５から画面表示出力を行うこと等も可能となる。
【０１５５】
また、元の添付ファイルＦ１のデータが動画像データである場合、テレビ端末２５からは、そのまま当該動画像データに対応する動画を画面表示出力することが可能である。プリント端末２７では通常、動画像データに応じた動画をそのまま印刷出力することはできないが、動画像データを複数の画像データ（静止画像データ）に分解すれば、各静止画像データに応じた印刷出力を行うことが可能である。
【０１５６】
この点からも明らかなように、電子メールＭＥ１の状態（有効な本文部分の有無）や添付ファイルＦ１のデータのデータ形式、およびステップＳ３２〜Ｓ３７で実行する処理の内容などの条件によっては、必ずしも、出力用データＯＭ１〜ＯＭ３，およびＯＦ１〜ＯＦ３の全種類が得られるとは限らないが、これらの出力用データが１種類でも得られた場合には、得られた出力用データは、メールボックス部６４に格納される（Ｓ３８）。
【０１５７】
なお、上述した転送などに備えるため、出力用データＯＭ１〜ＯＭ３，およびＯＦ１〜ＯＦ３に変換する前の元の電子メールＭＥ１や添付ファイルＦ１も、当該メールボックス部６４に残しておくことが望ましい。
【０１５８】
次に、図８のフローチャートを用いてユーザＵ２がチェックインしたときの処理について説明する。
【０１５９】
ユーザＵ２がホテルＨＴ１に宿泊するために、ノート型パソコンなどを携帯することなく当該ホテルＨＴ１のフロントまで出向いてチェックインを行う。この場合、ホテルＨＴ１の従業員ＣＬ１の操作などに応じて、前記フロント端末２３がユーザＵ２のチェックインを検知すると（Ｓ４０）、ホテルサーバ２４は、ユーザＵ２の氏名（宿泊用パスワードＳＪ２等でも可）などを検索キーとして、前記ステップＳ２０で予約データベースＤＢ２に格納した期限付きアカウント名ＡＣ２１を抽出することができるので（Ｓ４１）、当該期限付きアカウント名ＡＣ２１を通知して仮想プリントサーバ２０へユーザＵ２のチェックインが行われたことを示す宿泊管理情報を伝えることができる（Ｓ４２）。
【０１６０】
このステップＳ４０の実行時に、ユーザＵ２は自身の氏名などとともに、前記ワンタイムパスワードとしての宿泊用パスワードＳＪ２を、フロントの従業員ＣＬ１に告げるようにしてもよい。この場合、ホテルサーバ２４または仮想プリントサーバ２２などで、発行済みの宿泊用パスワードと照合することによりユーザ認証を行うことができるから、なりすましを検知、防止することが可能となり、ユーザＵ２宛ての電子メールＭＥ１やその添付ファイルＦ１の内容を、第３者に知られることを防止できる。
【０１６１】
ステップＳ４２につづくステップＳ４３では、仮想プリントサーバ２０が、前記期限付きアカウント名ＡＣ２１を用いて、当該ユーザＵ２のために確保された前記メールボックス部６４を特定し、当該メールボックス部６４に保管されている前記出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）をホテルサーバ２４へ送信する。
【０１６２】
これを受信したホテルサーバ２４は、ユーザＵ２のために設けた前記データ格納部４４に、当該出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）を格納する（Ｓ４４）。なお、データ形式を変換する前の電子メールＭＥ１やその添付ファイルＦ１ではなく、当該出力用データＯＭ１〜ＯＭ３（ＯＦ１〜ＯＦ３）、すなわちＦ３１を格納するのは、電子メールＭＥ１や添付ファイルＦ１のままでは、通常、テレビ端末２５，電話端末２６，プリント端末２７などによる各種出力を行うことができず、ノート型パソコンなどを携帯していないユーザＵ２が電子メールや添付ファイルの内容を知ることができないからである。
【０１６３】
有効な出力用データ（例えば、ＯＭ１など）が、データ格納部４４に格納されると、ユーザＵ２には電子メールが届いている旨が通知される（Ｓ４５）。この通知は、チェックインが行われたあと、ユーザＵ２の宿泊している客室などに電話などをかけること等によって知らせるようにしてもよいが、仮想プリントサーバ２０側のメールボックス部６４に着信している電子メールの存否だけを予め確認し確認結果をフロント端末２３などに表示できるようにしておけば、着信している電子メールがあることは、チェックインの時点に従業員ＣＬ１からユーザＵ２へ告げることが可能である。
【０１６４】
チェックインによりホテルＨＴ１の宿泊者となったユーザＵ２は、前記テレビ端末２５，電話端末２６，プリント端末２７のうちの所望の端末を利用して当該出力用データの出力を行わせ、電子メールＭＥ１や添付ファイルＦ１の内容を知ることができる。その際、ユーザＵ２は、前記テレビ端末２５，電話端末２６，プリント端末２７などに、前記宿泊用パスワードＳＪ２を入力してホテルサーバ２４にログインし、データ格納部４４に格納されている出力用データ（例えば、ＯＭ１など）を取り出すことになる。
【０１６５】
ここで、ステップＳ４３によって出力用データ（例えば、ＯＭ１など）がインターネット１１上を送信されるときや、出力用データがデータ格納部４４に格納されているときには、当該出力用データは暗号化された状態にあり、前記テレビ端末２５などから出力する際に復号することが望ましい。インターネット１１上を送信されるときに暗号化しておくのは、インターネット１１上で情報盗聴されることを防止するためであり、データ格納部４４に格納されているときに暗号化しておくのは、ホテルＨＴ１側のシステム管理者などによって、データ格納部４４に格納されている出力用データの内容が知られることを防止するためである。システム管理者には制限のないアクセス権限が与えられ、ホテルサーバ２４内の各種資源（データ格納部４４も含む）に自由にアクセスすることができるのが普通であり、暗号化を施しておかなければ、出力用データの内容もシステム管理者に知られる可能性があるからである。
【０１６６】
同様な理由で、仮想プリントサーバ２０側のメールボックス部６４に格納されているときにも、電子メールやその添付ファイル、および出力用データを暗号化しておくことが望ましい。
【０１６７】
なお、ユーザＵ２がチェックインを行ったことは、ホテルサーバ２４などを経由して仮想プリントサーバ２０に伝えられ、前記ユーザ管理部５４に格納されるため、制御部５１はいつでも、当該ユーザ管理部５４や宿泊スケジュール管理部５８に格納されているユーザＵ２に対応する宿泊管理情報を検査することにより、ユーザＵ２がホテルＨＴ１にチェックインを行ったことを検知することができる。
【０１６８】
図９のフローチャートは、主として、ユーザＵ２がホテルＨＴ１でチェックインを行ったあとの処理を示す。
【０１６９】
図９において、図７と同じ符号を付与したステップＳ３０，Ｓ３１の処理は、図７に対応するので、その詳しい説明は省略する。
【０１７０】
また、ステップＳ３１につづいて実行されるステップＳ５０の処理の詳細は、すでに説明した図７のステップＳ３２〜Ｓ３８と同じである。したがって、ステップＳ５０が終了した時点で、メールボックス部６４に着信している電子メールやその添付ファイルとそれらに対応する出力用データは、すでにメールボックス部６４に保存されている。
【０１７１】
ユーザＵ２のためのメールボックス部６４に電子メール（例えば、ＭＥ１）が着信しその添付ファイル（例えば、Ｆ１）なども含むデータのデータ形式変換処理が完了すると（Ｓ５０）、仮想プリントサーバ２０の制御部５１は、ユーザＵ２がホテルＨＴ１にチェックインしたか否かなどの宿泊状況を、ユーザ管理部５４に格納されているユーザＵ２に関する前記宿泊管理情報をもとに検査する（Ｓ５１）。このステップＳ５１の検査は、新たな電子メールおよびその添付ファイルがメールボックス部６４に着信するたびに繰り返し実行されるものであってよい。
【０１７２】
この検査の結果には、次の３通りがある。すなわち、まだチェックイン（ＣＩ）を行っておらず、なおかつ、チェックアウト（ＣＯ）を行っていないとの検査結果（ＣＩ未、ＣＯ未）と、チェックインを行っており、なおかつ、チェックアウトを行っていないとの検査結果（ＣＩ済み、ＣＯ未）と、チェックインを行っており、なおかつ、チェックアウトも行っているとの検査結果（ＣＩ済み、ＣＯ済み）の３通りである。
【０１７３】
このうち検査結果（ＣＩ未、ＣＯ未）は、前記第１拡張期間（ここでは、ＳＴ１１）に対応し、検査結果（ＣＩ済み、ＣＯ未）は、前記基本サービス期間（ここでは、ＳＴ１２）に対応し、検査結果（ＣＩ済み、ＣＯ済み）は、前記第２拡張期間（ここでは、ＳＴ１３）に対応する。
【０１７４】
検査結果（ＣＩ未、ＣＯ未）の分岐につづくステップＳ５８では、すでにステップＳ５０で実行されたように、メールボックス部６４へ出力用データを保存した状態を維持するだけである。
【０１７５】
検査結果（ＣＩ済み、ＣＯ未）の分岐につづくステップＳ５５では、メールボックス部６４にユーザＵ２宛ての電子メールが着信したことを、前記ホテルサーバ２４へ通知している。このあと、ステップＳ５６，Ｓ５７およびそれ以降のステップで実行される処理は、すでに図８に示したステップＳ４３以降の処理と実質的に同じである。
【０１７６】
すなわち、ステップＳ５６で出力用データの収容した保管ファイルをメールボックス部６４から引き出すことを指示すると、仮想プリントサーバ２０側で前記ステップＳ４３に対応する処理などが実行され、出力用データが、ホテルサーバ２４側のデータ格納部４４に格納されて、前記ステップＳ４５と同様に、ユーザＵ２に対しメールが届いていることが通知される（Ｓ５７）。
【０１７７】
この通知は、宿泊中のユーザＵ２がフロントに訪れたときに従業員ＣＬ１などが伝えてもよく、ユーザＵ２が宿泊している客室に電話をかけること等によって伝えてもよいことは、前記ステップＳ４５の場合と同様である。また、この通知を受けてユーザＵ２が行う対応や各部の処理も、ステップＳ４５以降と同様であり、ユーザＵ２は、前記宿泊用パスワードＳＪ２を入力してホテルサーバ２４にログインし、データ格納部４４に格納されている出力用データ（例えば、ＯＭ１など）を取り出して、前記テレビ端末２５，電話端末２６，プリント端末２７などから当該出力用データの出力を行わせることになる。
【０１７８】
なお、前記検査結果（ＣＩ済み、ＣＯ済み）の分岐につづくステップＳ５２では、仮想プリントサーバ２０側の転送制御部６１が、前記メールボックス部６４のなかに保存しておいた出力用データに変換する前の電子メールやその添付ファイルを、転送アドレス登録部６０に登録されている転送先のアドレスへ転送する。
【０１７９】
そして、このように前記第２拡張期間内に届いた電子メールの送信元（メール送信者）に対しては、前記通知メール生成部６２が生成した通知メールを送信する。この通知メールを読んだ当該メール送信者は、それ以後、当該電子メールアドレスＡＤ２１に宛てた電子メールの送信を控えることになる。なお、転送制御部６１が前記転送アドレス登録部６０に登録されている転送先のアドレスに宛てて電子メールを送信しても送達することができず、エラーメールなどが戻ってくることがあり得るが、そのようなケースでは、第２拡張期間内にメールボックス部６４に着信した電子メールを、その送信元メールアドレスをもとに、メール送信者へ転送するようにしてもよい。
【０１８０】
転送先のアドレスに当該電子メールが転送できた場合（Ｓ５４）、ユーザＵ２は、その電子メールや添付ファイルを閲覧することができる。ここでは、転送のための通信アプリケーションとして電子メールを用いる場合を示している。ユーザＵ２が転送先のアドレスとして例えば前記電子メールアドレスＡＤ２などを指定してある場合には、例えば、自宅に設置したパソコンなどを用いて当該電子メールを閲覧することができる。
【０１８１】
ここで説明したステップＳ５２〜Ｓ５４の処理と一部重複するが、チェックアウト時の処理の詳細は、図１０に示したフローチャートのようになる。
【０１８２】
ホテルＨＴ１のフロント端末２３で、ユーザＵ２がホテルＨＴ１からチェックアウトしたことを検知すると（Ｓ６０）、その検知は、所定の検索キー（ユーザＵ２の氏名や宿泊用パスワードＳＪ２など）とともにホテルサーバ２４へ伝えられ、ホテルサーバ２４では、当該検索キーを用いて予約データベースＤＢ２を検索することでユーザＵ２の期限付きアカウント名ＡＣ２１を特定し（Ｓ６１）、仮想プリントサーバ２０へ通知する（Ｓ６２）。
【０１８３】
また、前記ステップＳ６０におけるチェックアウトの検知を受けてホテルサーバ２４では、データ格納部４４に格納されている各出力用データを収容したファイルＦ３１を削除する（Ｓ６６）。なお、ここでは、ファイルの削除ではなく、フォルダ（ディレクトリ）の１つとしてユーザＵ２のために生成された当該データ格納部６４そのものを削除するようにしてもよい。
【０１８４】
一方、前記ステップＳ６２の通知を受けた仮想プリントサーバ２０では、前記宿泊スケジュール管理部５８内のスケジュールファイルＦ１１またはユーザ管理部５４に格納されている宿泊管理情報の内容を変更する（Ｓ６３）。
【０１８５】
次のステップＳ６４は、前記ステップＳ５２に対応する転送処理であり、転送処理の実行後も、メールボックス部６４において、一定期間、出力用データまたは、電子メールやその添付ファイルを収容したファイルの保管を継続している（Ｓ６４）。
【０１８６】
ホテルＨＴ１につづいてユーザＵ２が宿泊するホテルＨＴ２に関しても、以上と同様な処理が実行され得るが、ホテルＨＴ２も、ホテルＨＴ１と同様、仮想プリントサーバ２０のホテル会員である場合には、上述したように最初のホテルＨＴ１における前記第２拡張期間ＳＴ１３は存在せず、ホテルＨＴ１に関する基本サービス期間ＳＴ１２の終了後ただちに、次のホテルＨＴ２に関する第１拡張期間ＳＴ２１（または基本サービス期間ＳＴ２２）が開始する。
【０１８７】
これは、最初のホテルＨＴ１に関する処理では、図９に示したステップＳ５１の検査結果（ＣＩ済み、ＣＯ済み）に対応する分岐が存在しないことを意味するから、最初のホテルＨＴ１に関しては、ステップＳ５２〜Ｓ５４に対応する処理も実行されない。
【０１８８】
（Ａ−２）実施形態の効果
本実施形態によれば、宿泊時にノート型パソコンや携帯電話機などを携帯していないユーザ（Ｕ２）でも、ホテル（ＨＴ１，ＨＴ２）に関する前記サービス期間内などに届いた電子メールや添付ファイルの内容を知ることができるため、利便性が高い。
【０１８９】
また、この際、プリンタドライバのインストールなどの煩わしい作業を行う必要がない点も、利便性の向上に寄与してる。
【０１９０】
さらに、前記期限付きアカウント名（ＡＣ２１）として、記憶しやすいアカウント名や短いアカウント名を利用することができる点も、利便性の向上に寄与する。
【０１９１】
また本実施形態は、基本的に恒久的なパスワード（例えば、ＰＷ２）などの機密性の高い情報を、ビジネスセンタの装置（例えば、パソコンなど）等に入力する必要がない構成であるため、セキュリティ性が高い。
【０１９２】
（Ｂ）他の実施形態
上記実施形態では、一人のユーザ（例えば、Ｕ２）のために設けるフォルダ（ディレクトリ）の数を１つとしたが、一人のユーザのためのデータ格納部４４として複数のフォルダ（ディレクトリ）を用意してもよいことは当然である。この点、前記メールボックス部６４も同様である。
【０１９３】
また、上記実施形態では、ホテルに宿泊するユーザＵ２が電子メールを受信する場合を例に説明したが、ホテルに宿泊中のユーザＵ２から電子メールを送信することも可能である。例えば、テレビ端末２５などに、電子メールの本文部分の内容などを編集する機能を設ければ、編集し作成した電子メール（あるいは、その内容）を、上述した電子メールＭＥ１を受信しその内容をユーザＵ２が知るための経路を反対方向に転送させ、転送中の各過程で必要な処理を施すことによって、電子メールを送信することができるからである。
【０１９４】
なお、上記実施形態では、「ｔａｒｏｕ．ｙａｍａｄａ＠ｄｄｄ．ｃｏ．ｊｐ」などの電子メールアドレスを前提としたが、すべての電子メールシステムにおいて、このような電子メールアドレスが用いられるとは限らない。例えば、アカウント名とドメイン名のあいだに、＠マークではなく、！マークを配置する場合や、ドメインの階層構造のうち上位のものほど左側に記述する場合などもあり得、本発明は、そのような電子メールアドレスを用いるケースにも適用可能である。
【０１９５】
また、前記インターネット１１はその他のネットワークに置換可能である。例えば、特定の通信事業者が提供するＩＰ網や、ＩＰ−ＶＰＮ網などに置換可能である。
【０１９６】
さらに、上記実施形態にかかわらず、テレビ端末２５，電話端末２６，プリント端末２７は、必ずしもこれら３種類すべてを用意する必要はない。また、３種類の一部または全部を他の種類の出力装置と置換してもかまわない。
【０１９７】
なお、上記実施形態で仮想プリントサーバ２０に搭載した多数の機能（構成要素５３〜６４などの機能）は、複数のサーバに分散して配置してもよいことは当然である。
【０１９８】
また、上記実施形態では、ユーザＵ２が２つのホテルＨＴ１，ＨＴ２に連続的に宿泊するケースを例に説明したが、連続的に宿泊するホテルの数は３つ以上であってもよい。また、１つのホテルだけに宿泊するケースにも本発明は適用可能である。
【０１９９】
以上の説明にかかわらず、前記ホテルはホテル以外の宿泊施設に置換可能である。また、宿泊施設にも限定せず、新幹線、飛行機、船など、予めその利用を予約するか、予約しないとしても、利用する際に何らかの個人情報を登録する必要のある公共交通機関などにも置換可能である。
【０２００】
また、一連のスケジュールのなかに異種の宿泊施設や異種の公共交通機関が混在しているケースにも、本発明は適用可能である。
【０２０１】
さらに上記実施形態では、電子メール（ＭＥ１など）を前提として説明したが、本発明は電子メール以外の通信手段にも適用可能である。例えば、ＦＴＰプロトコルによるファイル転送などにも本発明は適用することができる。この場合、前記仮想プリントサーバ２０には、ＦＴＰサーバとしての機能を搭載することになる。
【０２０２】
以上の説明では主としてハードウエア的に本発明を実現したが、本発明はソフトウエア的に実現することも可能である。
【０２０３】
【発明の効果】
以上に説明したように、本発明によれば、利便性が高く、セキュリティ性に優れた情報保管システム及び情報保管サービス方法を提供することができる。
【図面の簡単な説明】
【図１】実施形態に係る通信システムの全体構成例を示す概略図である。
【図２】実施形態で使用する仮想プリントサーバの主要部の構成例を示す概略図である。
【図３】実施形態で使用するホテルサーバの主要部の構成例を示す概略図である。
【図４】実施形態で使用するフロント端末等の主要部の構成例を示す概略図である。
【図５】実施形態の動作例を示すフローチャートである。
【図６】実施形態の動作例を示すフローチャートである。
【図７】実施形態の動作例を示すフローチャートである。
【図８】実施形態の動作例を示すフローチャートである。
【図９】実施形態の動作例を示すフローチャートである。
【図１０】実施形態の動作例を示すフローチャートである。
【図１１】実施形態の動作例を示すフローチャートである。
【符号の説明】
１０…通信システム、１１…インターネット、１２，１３…ＬＡＮ、２１…ＭＭＫ端末、２２…パソコン、２３…フロント端末、２４…ホテルサーバ、２５…テレビ端末、２６…電話端末、２７…プリント端末、３０，４０、５０…通信部、３１，４１、５１…制御部、３２…操作部、３３…表示部、３４，４２、５２…記憶部、４３…宿泊管理部、４４…データ格納部、５４…ユーザ管理部、５５…アカウント発行部、５６…アカウント蓄積部、５７…アカウント比較部、５８…宿泊スケジュール管理部、５９…データ変換部、６０…転送アドレス登録部、６１…転送制御部、６２…通知メール生成部、６３…メールボックス管理部、６４…メールボックス部、ＡＣ２１…期限付きアカウント名、ＭＥ１…電子メール、Ｆ１…添付ファイル、ＯＭ１〜ＯＭ３，ＯＦ１〜ＯＦ３…出力用データ。
Claims (16)
- 送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を設ける情報保管システムであって、
前記宛先ユーザを収容する収容施設側に配置される収容施設側システムを有し、
当該収容施設側システムは、
前記宛先ユーザを当該収容施設に収容しているか否かを管理する収容管理部を備え、
前記リモート保管サーバは、
前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理するための保管管理部を備え、
前記収容施設側システムまたはリモート保管サーバは、
前記収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行するユーザ名発行部を有することを特徴とする情報保管システム。 - 請求項１の情報保管システムにおいて、
前記保管対象データが、電子メールまたはその添付ファイルである場合、
前記期間限定ユーザ名は電子メールアドレスのアカウントに対応する部分であり、なおかつ、前記宛先ユーザが通常使用している自身の電子メールアドレスに対応する文字列をドメイン名まで含めて使用したものであることを特徴とする情報保管システム。 - 請求項１の情報保管システムにおいて、
前記保管対象データが、電子メールまたはその添付ファイルである場合、
前記ユーザ名発行部は、
既発行の前記期間限定ユーザ名を、その有効期間の経過後も蓄積し続ける期間限定ユーザ名蓄積部と、
前記宛先ユーザが通常使用している自身の電子メールアドレスに対応する文字列から、アカウントとドメインを区切るための所定の区切り記号を除去、または他の区切り記号と置換した階層構造を有する文字列を、最下位の階層から順番に、当該期間限定ユーザ名蓄積部から得られた既発行の期間限定ユーザ名のいずれかと一致するか否かを検査し、最下位の階層から、一致しないとの検査結果が得られた階層までの文字列を、期間限定ユーザ名として該当する宛先ユーザに発行する発行制御部とを備えたことを特徴とする情報保管システム。 - 請求項１の情報保管システムにおいて、
前記リモート保管サーバは、
前記宛先ユーザが複数の収容施設に順次、収容される間のスケジュールを管理する収容スケジュール管理部を備え、
同一の宛先ユーザが異なる収容施設に収容されたときにも、同一の個別ユーザ用データ保管部を提供することを特徴とする情報保管システム。 - 請求項１の情報保管システムにおいて、
前記リモート保管サーバは、
前記宛先ユーザに宛てた保管対象データが届くと、当該保管対象データを、電話による音声出力、テレビ受像機による画面表示出力、または、印刷装置による印刷出力のためのデータ形式に変換するデータ形式変換部を備え、
データ形式変換後の保管対象データを、前記個別ユーザ用データ保管部に保管することを特徴とする情報保管システム。 - 請求項１の情報保管システムにおいて、
前記リモート保管サーバは、
前記宛先ユーザに宛てた保管対象データが届くと、当該保管対象データを個別ユーザ用データ保管部に保管したあと、そのデータ形式を変換することなく、前記収容施設側システムへ転送することを特徴とする情報保管システム。 - 請求項５の情報保管システムにおいて、
前記リモート保管サーバは、
前記保管対象データが、電子メールまたはその添付ファイルである場合、保管対象データの転送先のアドレスを予め登録しておく転送先登録部と、
前記データ形式変換部による変換前の保管対象データを、変換後の保管対象データとともに、前記個別ユーザ用データ保管部に保管させる保管制御部と、
前記収容施設側システム内の収容管理部が、前記宛先ユーザを収容しなくなったことを伝えてきたとき所定の転送条件が満たされるか否かを検査し、転送条件が満たされたことを示す検査結果が得られると、前記変換前の保管対象データを、前記転送先のアドレスに宛てて転送する転送処理制御部とを備えたことを特徴とする情報保管システム。 - 請求項７の情報保管システムにおいて、
前記リモート保管サーバは、
前記転送条件が満たされたことを示す検査結果が得られた後、その宛先ユーザに宛てた保管対象データが届いた場合、所定の過渡期間のあいだは、その保管対象データを、前記転送先のアドレスに宛てて転送すると共に、当該保管対象データを送信した送信元ユーザに宛てて、該当する個別ユーザ用データ保管部が閉鎖されたことを伝える電子メールを送信する過渡状態対応部を備えたことを特徴とする情報保管システム。 - 送信元または宛先となる各ユーザが各通信装置からアクセスし得るネットワーク上のリモート保管サーバに、送信元ユーザから宛先ユーザへ送信した保管対象データを保管するための個別ユーザ用データ保管部を用いる情報保管サービス方法であって、
前記宛先ユーザを収容する収容施設側に配置される収容施設側システムが、収容管理部を用いて、前記宛先ユーザを当該収容施設に収容しているか否かを管理し、
前記リモート保管サーバでは、
保管管理部が、前記個別ユーザ用データ保管部を、前記宛先ユーザに対応付けて管理し、
前記収容施設側システムまたはリモート保管サーバに設けられたユーザ名発行部が、前記収容施設が宛先ユーザを収容している期間に対応する有効期間のあいだ有効で、少なくとも当該収容施設側システムの内部において宛先ユーザを一意に指定する機能を持つ期間限定ユーザ名を発行することを特徴とする情報保管サービス方法。 - 請求項９の情報保管サービス方法において、
前記保管対象データが、電子メールまたはその添付ファイルである場合、
前記期間限定ユーザ名は電子メールアドレスのアカウントに対応する部分であり、なおかつ、前記宛先ユーザが通常使用している自身の電子メールアドレスに対応する文字列をドメイン名まで含めて使用したものであることを特徴とする情報保管サービス方法。 - 請求項９の情報保管サービス方法において、
前記保管対象データが、電子メールまたはその添付ファイルである場合、
前記ユーザ名発行部では、
期間限定ユーザ名蓄積部が、既発行の前記期間限定ユーザ名を、その有効期間の経過後も蓄積し続け、
発行制御部が、前記宛先ユーザが通常使用している自身の電子メールアドレスに対応する文字列から、アカウントとドメインを区切るための所定の区切り記号を除いた階層構造を有する文字列を、最下位の階層から順番に、当該期間限定ユーザ名蓄積部から得られた既発行の期間限定ユーザ名のいずれかと一致するか否かを検査し、最下位の階層から、一致しないとの検査結果が得られた階層までの文字列を、期間限定ユーザ名として該当する宛先ユーザに発行することを特徴とする情報保管サービス方法。 - 請求項９の情報保管サービス方法において、
前記リモート保管サーバでは、
収容スケジュール管理部が、前記宛先ユーザが複数の収容施設に順次、収容される間のスケジュールを管理し、
同一の宛先ユーザが異なる収容施設に収容されたときにも、同一の個別ユーザ用データ保管部を提供することを特徴とする情報保管サービス方法。 - 請求項９の情報保管サービス方法において、
前記リモート保管サーバでは、
前記宛先ユーザに宛てた保管対象データが届くと、当該保管対象データを、データ形式変換部が、電話による音声出力、テレビ受像機による画面表示出力、または、印刷装置による印刷出力のためのデータ形式に変換し、
データ形式変換後の保管対象データを、前記個別ユーザ用データ保管部に保管することを特徴とする情報保管サービス方法。 - 請求項９の情報保管サービス方法において、
前記リモート保管サーバは、
前記宛先ユーザに宛てた保管対象データが届くと、当該保管対象データを個別ユーザ用データ保管部に保管したあと、そのデータ形式を変換することなく、前記収容施設側システムへ転送することを特徴とする情報保管サービス方法。 - 請求項１４の情報保管サービス方法において、
前記リモート保管サーバでは、
前記保管対象データが、電子メールまたはその添付ファイルである場合、転送先登録部に、保管対象データの転送先のアドレスを予め登録しておき、
保管制御部が、前記データ形式変換部による変換前の保管対象データを、変換後の保管対象データとともに前記個別ユーザ用データ保管部に保管させ、
前記収容施設側システム内の収容管理部が、前記宛先ユーザを収容しなくなったことを伝えてきたとき、当該リモート保管サーバ内の転送処理制御部が、所定の転送条件が満たされるか否かを検査し、転送条件が満たされたことを示す検査結果が得られると、前記変換前の保管対象データを、前記転送先のアドレスに宛てて転送することを特徴とする情報保管サービス方法。 - 請求項１５の情報保管サービス方法において、
前記リモート保管サーバ内の過渡状態対応部は、
前記転送条件が満たされたことを示す検査結果が得られた後、その宛先ユーザに宛てた保管対象データが届いた場合、所定の過渡期間のあいだは、その保管対象データを、前記転送先のアドレスに宛てて転送すると共に、当該保管対象データを送信した送信元ユーザに宛てて、該当する個別ユーザ用データ保管部が閉鎖されたことを伝える電子メールを送信することを特徴とする情報保管サービス方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003140093A JP2004341986A (ja) | 2003-05-19 | 2003-05-19 | 情報保管システム及び情報保管サービス方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2003140093A JP2004341986A (ja) | 2003-05-19 | 2003-05-19 | 情報保管システム及び情報保管サービス方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2004341986A true JP2004341986A (ja) | 2004-12-02 |
Family
ID=33528916
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003140093A Abandoned JP2004341986A (ja) | 2003-05-19 | 2003-05-19 | 情報保管システム及び情報保管サービス方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2004341986A (ja) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007200224A (ja) * | 2006-01-30 | 2007-08-09 | Toshiba Plant Systems & Services Corp | 入退情報配信システム |
| JP2009251873A (ja) * | 2008-04-04 | 2009-10-29 | Murata Mach Ltd | 電子メール受信装置 |
| JP2012125950A (ja) * | 2010-12-13 | 2012-07-05 | Kyocera Document Solutions Inc | 画像形成装置 |
| WO2013190736A1 (ja) | 2012-06-18 | 2013-12-27 | Ｎｅｃカシオモバイルコミュニケーションズ株式会社 | 携帯端末、プログラム、及び制御方法 |
-
2003
- 2003-05-19 JP JP2003140093A patent/JP2004341986A/ja not_active Abandoned
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2007200224A (ja) * | 2006-01-30 | 2007-08-09 | Toshiba Plant Systems & Services Corp | 入退情報配信システム |
| JP2009251873A (ja) * | 2008-04-04 | 2009-10-29 | Murata Mach Ltd | 電子メール受信装置 |
| JP4640433B2 (ja) * | 2008-04-04 | 2011-03-02 | 村田機械株式会社 | 電子メール受信装置 |
| US8819147B2 (en) | 2008-04-04 | 2014-08-26 | Murata Machinery, Ltd. | Electronic mail receiving apparatus |
| JP2012125950A (ja) * | 2010-12-13 | 2012-07-05 | Kyocera Document Solutions Inc | 画像形成装置 |
| WO2013190736A1 (ja) | 2012-06-18 | 2013-12-27 | Ｎｅｃカシオモバイルコミュニケーションズ株式会社 | 携帯端末、プログラム、及び制御方法 |
| US9450965B2 (en) | 2012-06-18 | 2016-09-20 | Nec Corporation | Mobile device, program, and control method |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR101224745B1 (ko) | 전자 명함 교환 시스템 및 방법 | |
| US6515988B1 (en) | Token-based document transactions | |
| US20050108520A1 (en) | Authentication apparatus and method, network system, recording medium and computer program | |
| GB2418112A (en) | Device providing encryption services for Internet fax machines | |
| US20050114520A1 (en) | Access to foreign network resources | |
| WO2006043495A1 (ja) | 電子メール送信システム | |
| CN101945095A (zh) | 用户信息提供系统 | |
| US20050198291A1 (en) | Remote access system and method | |
| JP4470384B2 (ja) | 情報処理装置、ジョブ処理装置、指示データ作成装置及び署名プロキシ装置 | |
| JP4712196B2 (ja) | 認証装置及び方法、ネットワークシステム、記録媒体、コンピュータプログラム | |
| JP2009020785A (ja) | 画像形成装置、画像形成システム及びプログラム | |
| JP2010177845A (ja) | 画像読取装置、サーバ装置およびシステム | |
| JP2004088648A (ja) | 電子メール配信システム、中継装置、プログラムおよび記録媒体 | |
| US10638000B2 (en) | System for providing image data via a server, image processing apparatus, server, method for providing image data via a server, and non-transitory recording medium storing computer readable program | |
| AU764551B2 (en) | System and method for secure transmission of data clients | |
| JP2004341986A (ja) | 情報保管システム及び情報保管サービス方法 | |
| EP1347616A2 (en) | Secure communication via a web server | |
| KR101906429B1 (ko) | 이메일 계정을 발급하는 방법 및 그 장치 | |
| JP2002158827A (ja) | ネットワークファクシミリ送信管理装置 | |
| JP2002063138A (ja) | インターネット接続装置、インターネット接続方法、及びインターネット接続プログラムを記録した記録媒体 | |
| JP4035410B2 (ja) | セキュアな社内ネットワークを拡張するためのサーバ及び方法 | |
| JP3652230B2 (ja) | レポート管理装置および方法 | |
| JPH11266279A (ja) | 電子メール管理システム | |
| JP2004080134A (ja) | 電子メール処理装置、電子メール処理方法及びプログラム | |
| JP4892163B2 (ja) | 電子私書箱システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060413 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20081008 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20081021 |
|
| A762 | Written abandonment of application |
Free format text: JAPANESE INTERMEDIATE CODE: A762 Effective date: 20081105 |