(57)【特許請求の範囲】
【請求項１】
対象受信側に宛てたメッセージ信号を受信しかつ格納し、前記メッセージ信号をコンピュータに中継するシステムであって、
公衆電話交換網から着信呼を受信する電話インターフェースであって、前記着信呼が前記メッセージ信号を含む、電話インターフェースと、
前記電話インターフェースから前記メッセージ信号を受信し、前記メッセージ信号を記憶媒体に格納する中央プロセッサと、
前記コンピュータからの前記メッセージ信号に対する要求を受信し、該要求をネットワーク・サーバに転送するハイパーテキスト転送プロトコル・デーモンであって、前記コンピュータからの要求がハイパーテキスト転送プロトコルでフォーマットされる、ハイパーテキスト転送プロトコル・デーモンと、
前記ハイパーテキスト転送プロトコル・デーモンからの前記要求を受信したことに応答して、前記メッセージ信号の少なくとも一部分を前記ハイパーテキスト転送プロトコル・デーモンに転送する前記ネットワーク・サーバと、
を備え、
前記ハイパーテキスト転送プロトコル・デーモンが前記メッセージ信号の少なくとも一部分を前記コンピュータに送信し、
前記メッセージ信号は、前記対象受信側に対しアドレスされ、前記コンピュータは前記対象受信側に関連し、
前記ハイパーテキスト転送プロトコル・デーモンはさらに、前記コンピュータ上で実行するハイパーテキスト・ブラウザからのアクセス要求を前記ハイパーテキスト転送プロトコルに従いパケット交換データ・ネットワークを介して受け、
前記アクセス要求は、前記ネットワーク・サーバと関連したアプリケーション・レイヤ・アドレスを含み、
前記アクセス要求は、前記対象受信側に関連した前記記憶媒体のユーザ特定のメッセージ記憶領域へのアクセスを獲得するための前記対象受信側による要求を表し、前記アクセス要求は、所望のサーチについて少なくとも１つのサーチ・パラメータを指定するサーチ・クエリを含み、前記ハイパーテキスト転送プロトコル・デーモンは前記サーチ・クエリを前記ネットワーク・サーバに転送し、該ネットワーク・サーバは、前記少なくとも１つのサーチ・パラメータを満足する全てのメッセージ信号を識別することによって前記所望のサーチを実行し、前記ハイパーテキスト転送プロトコル・デーモンは前記所望のサーチの結果を前記コンピュータに送り、
前記メッセージ信号は、前記ユーザ特定のメッセージ記憶領域に格納され、
前記コンピュータは、エンドユーザのクライアント・コンピュータである、
システム。
【請求項２】
請求項１記載のシステムにおいて、前記ネットワーク・サーバが、前記メッセージ信号を第１ファイル・フォーマットから、標準的な一般化マークアップ言語に変換する、システム。
【請求項３】
請求項１記載のシステムにおいて、前記中央プロセッサが、前記メッセージ信号を第１ファイル・フォーマットから、標準的な一般化マークアップ言語に変換する、システム。
【請求項４】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記メッセージをハイパーテキスト・マークアップ言語で送信する、システム。
【請求項５】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記メッセージをハンドヘルド・デバイス・マークアップ言語で送信する、システム。
【請求項６】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記メッセージを拡張可能マークアップ言語で送信する、システム。
【請求項７】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記メッセージを仮想現実マークアップ言語で送信する、システム。
【請求項８】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記コンピュータからの前記要求をインターネットを通じて受信する、システム。
【請求項９】
請求項１記載のシステムにおいて、前記ハイパーテキスト転送プロトコル・デーモンが、前記コンピュータからの前記要求をイントラネットを通じて受信する、システム。
【請求項１０】
請求項１記載のシステムにおいて、前記電話インターフェースが、前記着信呼の一部としてアドレス信号を受信し、前記中央プロセッサが前記メッセージ信号を、当該アドレス信号に関連するディレクトリに格納する、システム。
【請求項１１】
請求項１記載のシステムにおいて、前記メッセージ信号がファクシミリ送信を含む、システム。
【請求項１２】
請求項１記載のシステムにおいて、前記メッセージ信号がボイス・メッセージを含む、システム。
【請求項１３】
請求項１記載のシステムにおいて、前記メッセージ信号がデータ・ファイルを含む、システム。
【請求項１４】
請求項１記載のシステムにおいて、前記中央プロセッサが、各メッセージ信号毎にデータ・エントリを格納する、システム。
【請求項１５】
請求項１４記載のシステムにおいて、前記データ・エントリが、前記メッセージ信号を識別するための複数のフィールドを含む、システム。
【請求項１６】
請求項１４記載のシステムにおいて、前記中央プロセッサが、前記データ・エントリをリレーショナル・データベースに格納する、システム。
【請求項１７】
請求項１記載のシステムにおいて、前記中央プロセッサが、前記所望のサーチ内に含まれている全てのメッセージ信号のリストを、前記ハイパーテキスト転送プロトコル・デーモンに返送し、該ハイパーテキスト転送プロトコル・デーモンが前記リストをコンピュータに送る、システム。
【請求項１８】
対象受信側に宛てたメッセージ信号を受信しかつ格納し、前記メッセージ信号をコンピュータに中継する方法であって、
公衆電話交換網から着信呼を受信するステップであって、該着信呼が前記メッセージ信号を含む、ステップと、
前記メッセージ信号を記憶媒体に格納するステップと、
ハイパーテキスト転送プロトコル・デーモンにおいて、前記コンピュータからの前記メッセージ信号に対する要求を受信し、該要求をネットワーク・サーバに転送するステップと、
前記メッセージ信号の少なくとも一部分を前記ネットワーク・サーバから前記ハイパーテキスト転送プロトコル・デーモンに転送するステップと、
前記メッセージ信号の少なくとも一部分を前記ハイパーテキスト転送プロトコル・デーモンから前記コンピュータに送信するステップと、
を含み、
前記メッセージ信号は、前記対象受信側に対しアドレスされ、前記コンピュータは前記対象受信側に関連し、
前記ハイパーテキスト転送プロトコル・デーモンはさらに、前記コンピュータ上で実行するハイパーテキスト・ブラウザからのアクセス要求を前記ハイパーテキスト転送プロトコルに従いパケット交換データ・ネットワークを介して受け、
前記アクセス要求は、前記ネットワーク・サーバと関連したアプリケーション・レイヤ・アドレスを含み、
前記アクセス要求は、前記対象受信側に関連した前記記憶媒体のユーザ特定のメッセージ記憶領域へのアクセスを獲得するための前記対象受信側による要求を表し、前記アクセス要求は、所望のサーチについて少なくとも１つのサーチ・パラメータを指定するサーチ・クエリを含み、前記方法は更に、前記ハイパーテキスト転送プロトコル・デーモンが前記サーチ・クエリを前記ネットワーク・サーバに転送し、該ネットワーク・サーバが、前記少なくとも１つのサーチ・パラメータを満足する全てのメッセージ信号を識別することによって前記所望のサーチを実行し、前記ハイパーテキスト転送プロトコル・デーモンが前記所望のサーチの結果を前記コンピュータに送ること、を含み、
前記メッセージ信号は、前記ユーザ特定のメッセージ記憶領域に格納され、
前記コンピュータは、エンドユーザのクライアント・コンピュータである、
方法。
【請求項１９】
請求項１８記載の方法であって、更に、前記要求を第１ファイル・フォーマットから標準的な一般化マークアップ言語に変換するステップを含む、方法。
【請求項２０】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求を標準的な一般化マークアップ言語で受信するステップを含む、方法。
【請求項２１】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求をハイパーテキスト・マークアップ言語で受信するステップを含む、方法。
【請求項２２】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求をハンドヘルド・マークアップ言語で受信するステップを含む、方法。
【請求項２３】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求を拡張可能マークアップ言語で受信するステップを含む、方法。
【請求項２４】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求を仮想現実マークアップ言語で受信するステップを含む、方法。
【請求項２５】
請求項１８記載の方法において、前記呼を受信する前記ステップが、ファクシミリ送信を受信するステップを含む、方法。
【請求項２６】
請求項１８記載の方法において、前記呼を受信する前記ステップが、ボイス・メッセージを受信するステップを含む、方法。
【請求項２７】
請求項１８記載の方法において、前記呼を受信する前記ステップが、データ・ファイルを受信するステップを含む、方法。
【請求項２８】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求をインターネットを通じて受信するステップを含む、方法。
【請求項２９】
請求項１８記載の方法において、前記要求を受信する前記ステップが、前記要求をイントラネットを通じて受信するステップを含む、方法。
【請求項３０】
請求項１８記載の方法であって、更に、前記記憶媒体に、受信した各メッセージ信号毎にデータ・エントリを格納するステップを含む、方法。
【請求項３１】
請求項１８記載の方法において、前記結果を返送する前記ステップが、前記所望のサーチ内に含まれる全てのメッセージ信号のリストを返送するステップを含む、方法。
【請求項３２】
請求項１８記載の方法であって、更に、前記所望のサーチの結果を前記記憶媒体にセーブするステップを含む、方法。
【請求項３３】
メッセージ信号を格納し配信する方法を実行するのに用いるソフトウエアを格納したコンピュータ読み取り可能媒体であって、前記方法が、
公衆電話交換網から着信呼を受信するステップであって、該着信呼が前記メッセージ信号を含む、ステップと、
前記メッセージ信号を記憶媒体に格納するステップと、
ハイパーテキスト転送プロトコル・デーモンにおいて、前記コンピュータからの前記メッセージ信号に対する要求を受信し、該要求をネットワーク・サーバに転送するステップと、
前記メッセージ信号の少なくとも一部分を前記ネットワーク・サーバから前記ハイパーテキスト転送プロトコル・デーモンに転送するステップと、
前記メッセージ信号の少なくとも一部分を、前記ハイパーテキスト転送プロトコル・デーモンから前記コンピュータに送信するステップと、
を含み、
前記メッセージ信号は、前記対象受信側に対しアドレスされ、前記コンピュータは前記対象受信側に関連し、
前記ハイパーテキスト転送プロトコル・デーモンはさらに、前記コンピュータ上で実行するハイパーテキスト・ブラウザからのアクセス要求を前記ハイパーテキスト転送プロトコルに従いパケット交換データ・ネットワークを介して受け、
前記アクセス要求は、前記ネットワーク・サーバと関連したアプリケーション・レイヤ・アドレスを含み、
前記アクセス要求は、前記対象受信側に関連した前記記憶媒体のユーザ特定のメッセージ記憶領域へのアクセスを獲得するための前記対象受信側による要求を表し、前記アクセス要求は、所望のサーチについて少なくとも１つのサーチ・パラメータを指定するサーチ・クエリを含み、前記方法は更に、前記ハイパーテキスト転送プロトコル・デーモンが前記サーチ・クエリを前記ネットワーク・サーバに転送し、該ネットワーク・サーバが、前記少なくとも１つのサーチ・パラメータを満足する全てのメッセージ信号を識別することによって前記所望のサーチを実行し、前記ハイパーテキスト転送プロトコル・デーモンが前記所望のサーチの結果を前記コンピュータに送ること、を含み、
前記メッセージ信号は、前記ユーザ特定のメッセージ記憶領域に格納され、
前記コンピュータは、エンドユーザのクライアント・コンピュータである、
コンピュータ読み取り可能媒体。
【発明の詳細な説明】
【０００１】
（発明の分野）
本発明は、メッセージを格納し配信するシステム（複数のシステム）および方法（複数の方法）に関し、更に特定すれば、メッセージを格納し、インターネットのようなネットワーク、または電話回線を通じて対象受信者宛てにメッセージを配信するシステム（複数のシステム）および方法（複数の方法）に関するものである。
（発明の背景）
ファクシミリ機械は、あらゆる規模の会社によって重宝に用いられており、標準的なオフィス機器の１つと急速になりつつあるが、多くの会社または家庭ではファクシミリ機械の恩恵を受けることはできない。生憎、小規模な会社または個人の家庭では、ファクシミリ機械はどちらかというと高価な機器の１つである。ファクシミリ機械を購入する費用に加えて、ファクシミリ機械は、トナー、用紙、保守を必要とするだけでなく、修理の可能性もある。これらの出費はかなり大きいため、多くの小規模な会社や確実に多くの家庭は、ファクシミリ機械が提供可能なサービスを受けることを躊躇することもあろう。また、常に移動している者やオフィスを有さない者にとっては、ファクシミリ機械を有することは非実用的であろう。実際、Atlanta Business Chronicle（アトランタ・ビジネス・クロニクル紙）は、小規模な会社の３０％はファクシミリ機械を全く所有していないと推定している。したがって、多くの会社および家庭は、ファクシミリ機械にアクセスすることができないので、不利益を被っている。
【０００２】
ファクシミリ機械は、会社にとっては資産と言うこともでき、文書を素早く送信および受信するのに重宝に用いられているので、機械はファクシミリ・メッセージを常時受信するために利用することができないという問題がある。時として、ファクシミリ機械は他のメッセージを受信するために使用中である場合もあり、あるいは機械がそれ自体のメッセージを送信している場合もある。このような時間中、人は、所望のファクシミリ機械との通信が確立されるまで、周期的にメッセージを送ろうとする。このようにファクシミリ機械と接続できないと、いらいらしたり、人の時間をかなり浪費し人がより生産的な作業を行うことを妨げることになり得る。進んだ機能を有するファクシミリ機械の中にはある回数通信を確立しようとするものもあるが、人はファクシミリ機械をチェックして、メッセージが送信されたか、またはメッセージの送信を再度開始したか確かめることに変わりはない。
【０００３】
労務コストおよびオフィス効率の低下に加えて、ファクシミリ機械によって、容易には算出されないコストが会社にかかる場合もある。これらのコストには、ファクシミリ機械が別のファクシミリ機械によってアクセスできない場合に生ずる、仕事を逃したりまたは好意を失うことが含まれる。これらのコストは、種々の理由で発生し得るものであり、ファクシミリ機械に紙がない場合や、機械に修理が必要な場合や、ファクシミリ機械が別のメッセージで使用中の場合等が挙げられる。これらのコストは、規模が小さい程会社程発生が多い。また、これらの多くは電話機の子機およびファクシミリ機械に対して電話回線を１本しか有さず、この単一回線が使用中の場合、通話およびファクシミリ・メッセージ双方の逸失を甘んじて受けるので、これらの出費が発生する可能性が低いとも言える。実際、Atlanta Business Chronicleは、２台以上のファクシミリ機械を有するのは小規模の会社では５％未満であると推定した。大会社の多くは、２台以上のファクシミリ機械を有することにより、そしてこれらの機械の１台が使用中の場合他の機械に呼を切り替えることにより、これらの損失を減少させることができる。しかしながら、これらの損失は完全には解消することはできない。何故なら、これらの機械は相変わらずそれらの能力を超えた要求を受ける場合があるからである。
【０００４】
ファクシミリ機械の主要な利点、即ち、文書の迅速な転送は、文書を対象受信者に迅速に導出する（route）ことを必ずしも意味する訳ではない。比較的長い時間期間が経過するまで、ファクシミリ機械が放置されていたり、受信したファクシミリ・メッセージに気が付かないこともある。更に、これらの機械を常に監視していても、オフィス内で確立されるルーティング手順が文書の配信を送らせる場合もある。したがって、多くのオフィスでは、ファクシミリ・メッセージを対象受信者に迅速に導出するという課題がある。
【０００５】
また、ファクシミリ機械では、その性質上、対象受信者への機密メッセージは、オフィス内の他の人々が傍受し読んでしまう可能性があるので、他の人々に露見せずに対象受信者が機密メッセージを受信することが困難である。メッセージが送られていることに対象受信者が気が付かない場合、それが配信されている間に、またはメッセージが機械に隣接して残っている間に、他の人々がメッセージを見る場合もある。対象受信者に、機密メッセージを送信中であるという通知を与えると、対象受信者は、ファクシミリ機械が受信するまで、機械の近くで待っていなければならない。したがって、ファクシミリ・メッセージの内容を極秘に維持することは困難であった。
【０００６】
多数の従業員がいるオフィスでは、ファクシミリ・メッセージをどこに導出するのかについて単純に判定することが困難な場合もある。この困難のために、ファクシミリ・メッセージをその対象受信者に自動的に導出するシステムがいくつか開発されている。Okada（オカダ）の米国特許第5,257,112号に開示されているシステムのように、あるタイプのシステムは、メッセージの発信元が電話機のプッシュ・ボタンを用いて入力したコードに基づいて、着信呼を特定のファクシミリ機械に導出することができる。Burgess et al.（バーゲスその他）の米国特許第5,115,326号、またはBaran（バラン）の米国特許第5,247,591号に開示されているシステムのように、別のタイプのシステムは、特別にフォーマットしたカバー・ページを用いるように発信元に要求し、これをシステムが読み取るようにしたものがある。しかしながら、このタイプのシステムでは、クライアントまたはカストマである可能性が非常に高い発信元に、特殊なステップまたは追加ステップを実行しファクシミリ・メッセージを送信するように要求することにより、発信元に負担を強いるものである。したがって、これらのシステムは、非常に有効でもなければ、望ましいものでもない。
【０００７】
他のタイプのルーティング・システムに、ファクシミリ機械をオフィス内のローカル・エリア・ネットワーク（ＬＡＮ）にリンクするものがある。例えば、BaranおよびBurgess et al.の特許に開示されているシステムでは、システムがカバー・シートを読み取り、ファクシミリ・メッセージの対象受信者を判定した後、ファクシミリ機械を受信者のコンピュータに接続するローカル・ネットワークを通じてシステムがＥ−メールを受信者に送る。Silverberg（シルバーバーグ）の米国特許第5,091,790号およびGiler et al.の米国特許第5,291,546号におけるような別のオフィス・システムは、オフィスのボイス・メール・システムにリンクしてあり、ファクシミリ・メッセージを受信した旨のメッセージを対象受信者に残すことができる。Misholi et al.（ミショリその他）の米国特許5,317,628号およびBoaz et al.（ボーズその他）の米国特許第5,333,266号におけるシステムのように、更に進んだシステムの中には、オフィスのローカル・ネットワークに接続され、ボイス・メッセージ、Ｅ−メール・メッセージ、およびファクシミリ・メッセージを統合して制御するものがある。
【０００８】
ファクシミリ・メッセージを導出するための種々のシステム、および恐らくはオフィス内で受信される別のタイプのメッセージは、非常に精巧で高価なシステムである。これらのオフィス・システムは、オフィスにおいてメッセージをその対象受信者に効果的に導出できることが望ましいが、これらのシステムは極めて高価であり、多数の従業員を有する会社でなければ、システムのコストを、当該システムが会社にもたらす利益と相殺することはできない。したがって、殆どの会社では、対象受信者に効果的かつ迅速にメッセージを導出するということが、課題であることに変わりはない。また、殆どの会社にとっては、メッセージの機密性を確保できるようにメッセージを導出するということも、課題であり続けている。
【０００９】
メッセージ・ルーティング・システムを有する会社や、特にこのようなシステムを全く所有していない会社にとっても、人がオフィスから外出している間は、ファクシミリ・メッセージを引き出すことは困難である。典型的に、会社にいない人は、オフィスに電話を入れ、オフィス内の誰かに、受信されているファクシミリ・メッセージについて通知を受けなければならない。したがって、オフィス内に誰かがいる通常の業務時間中にオフィスに電話をかけなければならず、したがってファクシミリ・メッセージ内の情報を中継できる時間が限定されることになる。
【００１０】
会社にいない人がファクシミリ・メッセージを見たい場合、オフィスにいる誰かが、その当人がアクセス可能なファクシミリ機械にメッセージを再送しなければならない。このアクセス可能な機械は多くの場合、他社のファクシミリ機械かまたは当人が滞在しているホテルのファクシミリ機械であるので、その内容を公にする危険を冒すことなく、ファクシミリ・メッセージを当人が受信することは困難である。更に、当人のオフィスにおいて誰かがメッセージを送ることを覚えていなければならず、しかもアクセス可能なファクシミリ機械において誰かが、オフィスにいない当人にメッセージを導出しなければならないので、当人は、ファクシミリ・メッセージの全てを受信できない場合や、メッセージを受信するために待っていなければならない場合もある。
【００１１】
ファクシミリ・メッセージやボイス・メール・メッセージの検索は、オフィスから離れている間は、コストがかからない訳ではない。第１に、オフィスに電話してメッセージをチェックし、オフィス内の誰かにメッセージを他のファクシミリに送らせる場合、長距離電話料金がかかるはずである。次に、メッセージをファックス・ビューロー（fax bureau）またはホテルのデスクに送信する費用、およびその機器を使用するための受信先自体での料金がかかる。これらの料金は確かにたいしたことはないが、これらの料金は、当人がオフィスにいない間にかかる費用である。
【００１２】
総体的に、ファクシミリ機械は、多くの会社にとって欠くことができない機器の１つであるが、ファクシミリ機械は多くの課題即ちコストをかかえている。多くの会社または家庭は、ファクシミリ機械の恩恵にあずかることができないので、不利である。ファクシミリ機械を所有する会社では、ファクシミリ機械または複数のファクシミリ機械がメッセージを受信できない時にかかり得るコストに加えて、ファクシミリ機械の通常の運転コストがかかるはずである。更に、ファクシミリ・メッセージは、効率的または信頼性高く対象受信者に導出されない場合があり、導出プロセスの間にその内容が暴露されてしまう虞れもある。ファクシミリ・メッセージのルーティングにおけるコストおよび問題は、対象受信者がオフィスから離れている場合に一層深刻化する。
【００１３】
ファクシミリ・メッセージに伴う問題の多くは、単にファクシミリ・メッセージだけに固有な訳ではなく、ボイス・メール・メッセージやデータ・メッセージにも関連がある。ボイス・メッセージに関しては、多くの会社はボイス・メール・システムを所有しておらず、メッセージを転記しなければならない。したがって、オフィスから離れている人は、誰が呼び出したのか発見するために、通常の就業時間内に電話しなければならない。これらのメッセージ内にある情報は、通常、呼び出した人、その番号、そして恐らくは当該呼の性質に関する何らかの指示だけに限定される。ボイス・メールを所有する会社では、オフィスにいない人は電話をかけなければならず、頻繁に長距離通話料金がかかる。したがって、常時簡単かつ安価にアクセス可能なボイス・メッセージ格納および配信システムが求められている。
【００１４】
データ・メッセージに関しては、当該メッセージの送信は、多くの場合、発信元および受信側間で何らかの調整が必要となる。例えば、受信側のコンピュータをオンにしてメッセージを受信しなければならない。これは、一般には、通常の就業時間中に誰かがいる場合にしか行われない。したがって、受信側のコンピュータは、通常の就業時間中は、常にデータ・メッセージを受信することしかできない。多くの家庭や会社でさえも、専用のデータ回線を有していない可能性が高く、電話機、コンピュータ、およびファクシミリ間で回線を切り替えなければならない。このような状況では、発信元は受信側に電話して、回線をコンピュータに切り替えるように連絡しなければならず、更に受信側がメッセージを受信できるようになるまで待っていなければならない。誰かがオフィスから外出している場合のように、データ・メッセージを別の場所に再送するのは、単に配信を複雑化するだけである。したがって、データ・メッセージを送信および受信するのが困難な場合が多く、更に後になってメッセージを別の場所に中継することも困難である。
【００１５】
多くの会社の標準的な業務の習慣では、会社自体と他のエンティティとの間の通信文の記録は全て保管することになっている。従来より、追跡し記録した通信文は、ある会社から他のエンティティにまたはその逆に送った手紙またはその他の同様の印刷物を含む。印刷物の通信を追跡することは比較的容易であるが、ファクシミリ・メッセージ、ｅ−メール・メッセージ、ボイス・メッセージ、またはデータ・メッセージのような新たな通信文では、追跡や記録はとても困難である。
【００１６】
例えば、ファクシミリ・メッセージは、感熱紙上に受信することが多く、時間が経つに連れて印刷が薄くなるという欠点があるので、このようなメッセージを追跡し記録することが困難な場合がある。また、ファクシミリ・メッセージの正確な追跡も困難である。何故なら、ファクシミリ・メッセージはファクシミリ機械において部分的に印刷されるだけであったり、メッセージが失われたり、部分的にしか対象受信側に配信されない場合もあり得るからである。また、ファクシミリ・メッセージは、通常の郵便とは異なるチャネルを通じた機関の内部で配信される場合が多く、したがって会社の通常の記録保持手順から簡単に洩れてしまう（fall outside）ので、難しい点がある。
【００１７】
また、ボイス・メール・メッセージも追跡や記録が困難である。ボイス・メッセージはセーブすることができるが、多くのボイス・メール・サーバはある時間期間の後、メッセージを自動的に削除する。ボイス・メッセージの永続的な記録を維持するためには、ボイス・メッセージを転記し、メッセージを印刷したコピーを記録に保持すればよい。しかしながら、このようにボイス・メッセージを転記したコピーは、元のボイス・メッセージよりも信頼性が低くしたがって望ましいものではない。何故なら、転記したコピーは素材を変更している場合があり、あるいはメッセージのある部分を省略している場合もあるからである。
【００１８】
ファクシミリおよびボイス・メール・メッセージに加えて、データ・メッセージも追跡や記録が困難である。ファイルのダウンロードまたはアップロードは、ファイル自体の存在によってのみ証拠となり得る。通常、ファイル転送手順は、何のファイルを転送したのか、ダイアルした電話番号、ファイルを受信したコンピュータの電話番号、時刻、または転送のデータの永続的記録には全く役に立たない。したがって、それ自体および他のエンティティ間のデータ転送全ての正確な記録を維持することは困難である。
（発明の概要）
本発明の目的は、メッセージを対象受信側に信頼性高くかつ効率的に導出することである。
【００１９】
本発明の別の目的は、メッセージの内容を極秘に保ったまま、メッセージを対象受信側に導出することである。
【００２０】
本発明の別の目的は、対象受信側が、最小のコストでメッセージに容易にアクセス可能とすることである。
【００２１】
本発明の更に別の目的は、対象受信者に代わって、２つ以上のメッセージの同時受信を可能にすることである。
【００２２】
本発明の更に別の目的は、メッセージの対象受信側が、事実上世界中のあらゆる場所でもメッセージに常時アクセスできるようにすることである。
【００２３】
本発明の更にまた別の目的は、メッセージの対象受信側が、受信したメッセージ全てを閲覧できるようにすることである。
【００２４】
本発明の更にまた別の目的は、対象受信側に、メッセージを受信したことを迅速に通知することである。
【００２５】
本発明の更に別の目的は、種々のタイプのメッセージを受信することである。
本発明の別の目的は、対象受信側の優先度に応じて、メッセージを配信することである。
【００２６】
本発明の更に別の目的は、ファクシミリ・メッセージ、ボイス・メール・メッセージおよびデータ転送のような通信を記録し追跡することである。
【００２７】
本発明の追加の目的、利点および新規な特徴は、以下の説明に明記してあり、この説明を読むことによって、または発明を実施することによって、当業者には明白となろう。本発明の目的および利点は、添付した請求の範囲から、理解し習得することができよう。
【００２８】
前述のそしてその他の目的を達成するために、本発明によれば、ここに具体化し広義に記載するように、メッセージを格納し配信するシステムおよび方法は、着信呼を受信し、この着信呼に付随するアドレス信号を検出することを含み、アドレス信号は、メッセージ格納および配信システムのユーザに関連がある。次に、アドレス信号に伴うメッセージを受信し、第１ファイル・フォーマットから第２ファイル・フォーマットに変換する。メッセージは、記憶領域に第２ファイル・フォーマットで格納し、ユーザから要求を受信した後に検索する。次に、混合メディア・ページ・レイアウト言語である第１ファイル・フォーマットを用いて、ネットワークを通じてメッセージの少なくとも一部をユーザに送信する。
【００２９】
別の態様では、ネットワーク・メッセージ格納および配信システムは、着信呼を受信し、着信呼上でアドレス信号を検出し、着信呼上でメッセージを検出し、このメッセージを記憶領域に置く中央プロセッサを備えている。着信呼上のアドレス信号は、ネットワーク・メッセージ格納および配信システムのユーザと関連がある。ネットワーク・サーバが、記憶領域からメッセージを受信し、このメッセージを混合メディア・ページ・レイアウト言語に変換し、メッセージを記憶領域に置く。ネットワーク・サーバがネットワークを通じてユーザからの要求を受信した場合、ネットワーク・サーバはメッセージの少なくとも一部をネットワークを通じてユーザに送信する。
【００３０】
好ましくは、ネットワーク格納および配信システムは、ファクシミリ・メッセージ、データ・メッセージ、またはボイス・メッセージを受信することができ、前述のネットワークはインターネットである。メッセージを標準的な一般化マークアップ言語に変換し、メッセージが到着したことをＥ−メールまたはページング・システムによってユーザに通知する。ファクシミリ・メッセージのリストは、数種類のフォーマットの１つで、ユーザに送ることができる。これらのフォーマットは、テキストのみのリスト、または各メッセージの第１ページの原寸大または縮小版画像を伴うリストを含む。あるいは、リスト内のメッセージの各ページの原寸大または縮小版画像をユーザに提示することもできる。
【００３１】
更に別の態様によれば、本発明は、ファイルまたはメッセージを管理するシステムおよび方法に関し、メッセージ信号をストレージに格納し、ユーザからのサーチ要求を受信することを含む。サーチは、ユーザによって完成し、システム内のハイパーテキスト転送プロトコル・デーモン（ＨＴＴＰＤ）に供給するサーチ・クエリを備えることが好ましい。ＨＴＴＰＤは共通ゲートウエイ・インターフェース（ＣＧＩ）を介して要求をアプリケーション・プログラムに転送し、アプリケーション・プログラムがサーチを実行する。サーチの結果は、ＨＴＴＰＤを介して、サーチ・パラメータを満足する全てのメッセージまたはファイルのリストという形状で、コンピュータに返送することが好ましい。次いで、ユーザは、掲示されているメッセージまたはファイルから１つ以上を選択し、後に参照するためにこのサーチをセーブすることもできる。
（図面の簡単な説明）
本明細書に組み込まれその一部をなす添付図面は、本発明の一実施形態を示し、以下の説明と共に、本発明の原理を説明する役割を果たすものである。
（好適な実施形態の詳細な説明）
これより本発明の好適な実施形態を説明しその例を添付図面に示す。
【００３２】
図１を参照すると、少なくとも１つの直接インワード・ダイアリング（ＤＩＤ：direct inward dialing trunk）トランク１５を介して、電話会社の中央局２０に、メッセージ格納および配信システム（ＭＳＤＳ）１０を接続してある。ＤＩＤトランク１５上での各呼毎に、着呼側の電話番号を示すアドレス信号をＭＳＤＳ１０に供給する。ＤＩＤトランク１５は、多数の電話番号またはアドレスを搬送することができる。好ましくは、ＤＩＤトランク１５は、中央局２０とＭＳＤＳ１０との間に並列に接続してある多数のＤＩＤトランク１５を備え、ＭＳＤＳ１０は２つ以上の呼を同時に受信することができ、更に単一の電話番号またはアドレスに対する２つ以上の呼を同時に受信することができる。
【００３３】
中央局２０は、多数の第三者に接続してある。例えば、中央局２０は、ファクシミリ機械２４、電話機２６、およびコンピュータ２８に接続し、各接続を別個の電話回線で行うことができる。図には単一のコンピュータ２８を示すが、この単一のコンピュータ２８は、実際には、ＭＳＤＳ１０に中央局２０を介して接続してあるローカル・エリア・ネットワークを表わすものとすることができる。ファクシミリ機械２４、電話機２６、およびコンピュータ２８を別個の回線上に示したが、１つ以上のこれらのデバイスが単一の回線を共有可能であることは理解されよう。
【００３４】
ＭＳＤＳ１０は、ネットワーク、好ましくはインターネットのワールド・ワイド・ウェブ３０にも接続してある。インターネット３０は単一のエンティティとして示してあるが、インターネット３０は実際にはコンピュータ・ネットワークの集合体であり、常に発展し変化し続ける構造であることは理解されよう。したがって、ＭＳＤＳ１０は、インターネット３０の現構造または形態に限定される訳でなく、インターネット３０に対する今後のあらゆる変更や追加も包含するものとする。更に、ＭＳＤＳ１０は、それ自体のノードまたはポータルを介してというように、インターネット３０に直接接続してあるものとして示す。しかしながら、ＭＳＤＳ１０は、中間のインターネット・アクセス・プロバイダを介してというように、インターネット３０への適切な接続であれば、そのいずれによっても実施可能である。
【００３５】
本発明の動作全体を示す図２を参照すると、ＭＳＤＳ１０が担当する番号に向けた電話呼（telephone call）がステップ４０において第三者によって、例えば、ファクシミリ機械２４、電話機２６，またはコンピュータ２８を介して開始される。着信する電話呼は、したがって、ファクシミリ・メッセージ、ボイス・メッセージ、またはデータ・メッセージを搬送している可能性がある。ステップ４２において、中央局２０を介して、発した呼に関連するアドレス信号をＤＩＤトランク１５を通じてＭＳＤＳ１０に導出する。
【００３６】
呼がＭＳＤＳ１０に到達すると、ＭＳＤＳ１０内において呼のルーティングを行う。その態様については、図１３を参照して以下で更に詳しく説明する。ステップ４６において、ＭＳＤＳ１０は電話呼に答え、ＤＩＤトランク１５からアドレス信号を受信する。次に、ステップ４８において、ＭＳＤＳ１０と第三者との間に呼を確立し、ステップ５０において、ＭＳＤＳ１０は電話回線を通じて送信されたメッセージを受信する。ステップ５２においてメッセージを格納し、ステップ５４においてＭＳＤＳ１０内部のデータベースを更新し、そしてステップ５６においてメッセージの対象受信側に通知する。メッセージの対象受信側は、ＭＳＤＳ１０が提供するサービスを用い、以後ユーザと呼ぶことにする。ステップ５８において、メッセージをハイパーテキスト・マークアップ言語（ＨＴＭＬ）に変換する。
【００３７】
ＭＳＤＳ１０がそのユーザの一人に対するメッセージを受信した後、当該ユーザはいつでもそしていかなる場所においても、インターネットのワールド・ワイド・ウェブ３０に接続しＭＳＤＳ１０内に格納されているメッセージを検索することによって、ＭＳＤＳ１０と通信することができる。図３を参照すると、ステップ６０において、ユーザは最初にいずれかの適切な方法で、インターネット３０に接続可能なパーソナル・コンピュータ３２を介してというように、インターネット３０に接続する。適切な方法とは、それ自体のポータルまたはノードを介して、あるいは何らかの中間アクセス・プロバイダを通じてとうようなものである。パーソナル・コンピュータ３２は、単一のコンピュータに限定される訳でなく、代わりに、オフィス内のローカル・エリア・ネットワークのようなネットワーク化したコンピュータ群としてもよい。
【００３８】
一旦インターネット３０に接続したならば、ステップ６２において、ユーザは、ハイパーテキスト・ブラウザを用いて、彼または彼女のＭＳＤＳ１０メールボックスに関連するユニバーサル・リソース・ロケータ（ＵＲＬ）にアクセスする。コンピュータ３２は、Netscapeのような適切なハイパーテキスト・ブラウザであれば、いずれを用いてメールボックスにアクセスしてもよい。ステップ６４において、ＭＳＤＳ１０内部のハイパーテキスト転送プロトコル・デーモン（ＨＴＴＰＤ）がＵＲＬ要求を受信し、ステップ６６においてユーザ認証を要求する。すると、ステップ６８においてユーザは彼または彼女のＩＤおよびパスワードを供給し、ステップ７０において有効であることがわかったならば、ステップ７２においてＭＳＤＳ１０はコンピュータ３２にメールボックスへのアクセスを与える。ＩＤおよびパスワードが無効であるとステップ７０において判定した場合、ステップ７４においてＨＴＴＰＤはコンピュータ３２に認証失敗メッセージを送る。
【００３９】
ユーザがステップ７２においてメールボックスへのアクセスを獲得した後、ユーザは、ＭＳＤＳ１０内に格納してある情報を要求することができる。ＭＳＤＳ１０は、ステップ７６において要求を受信し、ステップ７８において情報が存在するか否かについて判定を行う。一般的な慣行であるが、ＭＳＤＳ１０はステップ７８において要求の有効性についても判定を行う。ユーザからの要求は、当該ユーザのメールボックス番号、メッセージ識別子、表示の好み、そしてメッセージがファクシミリ・メッセージである場合、ページ識別子を含む。ハッカーが特権情報へのアクセスを獲得しようとしている場合のように、何らかの理由で要求を無効とする場合、情報に対する要求を終了させる。
【００４０】
要求された情報が入手可能である場合、ステップ８０においてこの情報をインターネット３０を通じてユーザのコンピュータ３２に送信する。一方、情報が存在しない場合、ステップ８２においてＭＳＤＳ１０は、要求された情報を生成し、次いでステップ８０においてこの情報をインターネット３０を通じてユーザのコンピュータに送る。
【００４１】
ステップ７２においてメールボックスへのアクセスを獲得する前に、ユーザには、挨拶ページ、またはユーザにＭＳＤＳ１０が提供するサービスについて習得させ、ＭＳＤＳ１０によってアカウントを開かせ、またはアカウントへのアクセスを獲得させるようなタイプの情報を送ることが好ましい。一旦ステップ７２においてアクセスが得られたなら、ユーザには、ＭＳＤＳ１０内部にある彼または彼女のメールボックス内に格納してあるメッセージ全数を示す情報を提供する。好ましくは、ＭＳＤＳ１０が送る情報は、メッセージのタイプ毎にメッセージの全数を示し、更に、既に提供したメッセージの全数および新たなメッセージの総数を示す。
【００４２】
また、このステップにおいて、ユーザには、アカウント情報を変更するオプションを与えることが好ましい。アカウント情報は、ユーザのＥ−メール・アドレス、メッセージを検討する方法、ユーザのページャ情報、およびその他のユーザの好みを含むことができる。表示オプションおよびその他のユーザの好みについては、以下で更に詳しく論ずることにする。
【００４３】
異なるメッセージの全数を示す一般情報ＨＴＭＬファイルには、多数のアンカーを備えている。アンカーは、リンクまたはリファレンスとも呼ぶ。一般に、アンカーとは、コンピュータ３２上のユーザに、アンカー・ファイル上にある情報を検索させるものである。例えば、ファクシミリ・メッセージのリストへのアンカーを、メッセージ総数の表示上に備える。ユーザがファクシミリ・ファイルのアンカーを選択すると、ＭＳＤＳ１０は、ファイル「faxlist.html」のようなファクシミリのリストを収容したファイルを検索して表示する。ボイス・メッセージやデータ・メッセージのような別のタイプのメッセージも、一般情報ページ上に、それぞれのＨＴＭＬリスト・ファイルに結び付く同様のアンカーを有する。
【００４４】
図２のステップ５４において新たなメッセージを受信すると、ユーザのメールボックスを更新して、メッセージの全数およびタイプを表示する。また、ＭＳＤＳ１０は、メッセージの全リストに加えて、他のファイルを更新することもできる。加えて、この時点で、ＭＳＤＳ１０はＥ−メール・メッセージをユーザのコンピュータ３２に送り、ユーザに新たに到着したメッセージを通知する。また、ＭＳＤＳ１０は、ページング・システムを介してユーザに通知を送り、ユーザは、メッセージを受信したという通知を殆ど瞬時に受信するようにすることも可能である。
【００４５】
また、ＭＳＤＳ１０は、ユーザの好みに応じて追加の情報を生成する。ユーザのためにＭＳＤＳ１０をどのように構成するかについての好みは、どのようにメッセージを検討するかについてのオプションを含む。ファクシミリ・メッセージの場合、例えば、ユーザは、適切なオプションを選択することによって、ファクシミリ・メッセージのリストに供給する情報の量またはタイプを変更することができる。他のオプションも利用可能であるので、ユーザは、ユーザ自身のコンピュータ３２または自身の個人的な好みにＭＳＤＳ１０を個々に合わせることができる。
【００４６】
例えば、ファクシミリ・メッセージを受信すると、ＭＳＤＳ１０はステップ５４において全メッセージの全体リストを更新し、新たに受信したメッセージを示し、更にユーザの好みに応じて、新たに受信したファクシミリ・メッセージのＨＴＭＬファイルを生成することもできる。後にユーザがステップ７６においてメッセージについての情報を要求した場合、ＨＴＭＬ情報を既に生成しており、ＭＳＤＳ１０はステップ８０において要求された情報をユーザに直接送ることができる。一方、ユーザが別のオプションの１つにしたがってメッセージを見ることを望む場合、ＭＳＤＳ１０はステップ８２において要求の時点で当該別のオプションにしたがってＨＴＭＬファイルを生成する。
【００４７】
ファクシミリ・メッセージを見るためにユーザが利用可能な第１のオプションは、メッセージのテキストのみのリストである。テキスト・リスト上の情報は、ＭＳＤＳ１０においてメッセージを受信した日時、メッセージを送信した電話番号、ページ数、ページ・サイズ、およびバイト単位でのメッセージ・サイズを含むことが好ましい。これらのメッセージは、勿論、他のタイプの情報と共にリストに纏めることも可能である。ユーザがリスト上のファクシミリ・メッセージの１つを選択すると、ＭＳＤＳ１０内で要求がＨＴＴＰＤに送られ、そのメッセージがインターネット３０を通じてユーザのコンピュータ３２にダウンロードされる。一旦コンピュータ３２がメッセージを受信したなら、そのメッセージを表示、印刷、またはセーブし、更に検討することができる。
【００４８】
第２ないし第５のオプションは、ユーザが、ＭＳＤＳ１０からインターネット３０を通じてコンピュータ３２にメッセージをダウンロードする前に、ファクシミリ・メッセージの画像を予め見ることを可能にするものである。第２オプションは、リスト上の各見出しに続くカバー・ページの縮小版画像で、ユーザがメッセージのリストを見ることを可能にする。ユーザがリスト上のメッセージの１つを選択すると、選択されたファクシミリ・メッセージがインターネット３０を通じてコンピュータ３２に送信される。また、ユーザは、メッセージの全てを一度にコンピュータ３２上に表示することができない場合、リスト全体をスクロールすることも可能である。
【００４９】
第３オプションは、ユーザに各ファクシミリ・メッセージのカバー・ページの原寸大の図を提供する。ユーザは、メッセージ全体をコンピュータ３２にダウンロードすることなく、各メッセージのカバー・ページ全てを素早くスクロールすることができる。カバー・ページの原寸大の図によって、ユーザは、カバー・ページ上にあるいずれのコメントでも明確に識別することができる。これは、第２オプションによって得られるカバー・ページの縮小画像では不可能であろう。
【００５０】
第４オプションは、ユーザに各ページの縮小版画像を提供し、ユーザにメッセージ全体をスクロールさせる。したがって、ユーザは、メッセージをコンピュータ３２上にダウンロードする前に、画面上でファクシミリ・メッセージ全体を読むことができる。このオプションにより、ユーザは、ファクシミリ・メッセージのページ全てを通読することができ、更に次のメッセージまたは前のメッセージに飛ぶこともできる。加えて、ユーザは、ページを原寸大に拡大するオプションも有する。別のオプションと同様に、メッセージの１つを選択すると、ＭＳＤＳ１０内のＨＴＴＰＤは、インターネット３０を通じてユーザのコンピュータ３２にそのファクシミリ・レターを送信させる。
【００５１】
第５オプションを用いると、各ページの原寸大画像をユーザのコンピュータ３２に送信する。ユーザは、このファクシミリ・メッセージのページ全体をスクロールし、各ページの内容を容易に読むことができる。ユーザがメッセージをコンピュータ３２にダウンロードしたい場合、ユーザはメッセージを選択し、ＭＳＤＳ１０内のＨＴＴＰＤはインターネット３０を通じてメッセージをユーザのコンピュータ３２に送信する。
【００５２】
先に論じたように、ステップ５４においてデータベースを更新した後、ＭＳＤＳ１０は、ファクシミリ・メッセージを表示するために選択したオプションに基づいて、追加の情報を生成する。即ち、図４（Ａ）に示すように、第１オプションを選択したとステップ１００で判定した場合、ステップ１０２において、ＭＳＤＳ１０は、それぞれのファクシミリ・ファイルに対するアンカー即ちリファレンスを有する、ファクシミリ・メッセージのテキスト・リストを生成する。次いで、ステップ１０４においてＨＴＭＬファイルをインターネット・サーバに移動させる。
【００５３】
第１オプションを選択しない場合、ＭＳＤＳ１０は次にステップ１０６において第２オプションを選択したか否かについて判定を行う。第２オプションでは、ファクシミリ・メッセージは、カバー・ページの縮小版画像と共にリスト化する。この情報を生成するために、ステップ１０８においてファクシミリ・ファイルからカバー・ページを抽出し、ステップ１１０においてカバー・ページの縮小版ＨＴＭＬ画像を作成する。ステップ１１２において、ファクシミリ・メッセージのリストを生成し、各カバー・ページのサムネイル・ビューをその各ファクシミリ・ファイルにリンクする。次いで、ステップ１０４において、生成したＨＴＭＬファイルをインターネット・サーバに送る。
【００５４】
第３オプションを選択したとステップ１１４において判定した場合、カバー・ページの原寸大画像をコンピュータ３２に送る。カバー・ページの原寸大画像を生成するには、最初にステップ１１６においてファクシミリ・ファイルからカバー・ページを抽出する。次に、ステップ１１８において、カバー・ページを原寸大のＨＴＭＬ画像に変換し、ステップ１２０においてファクシミリ・ファイルにリンクしてある埋め込みカバー・ページを有するリストを生成する。
【００５５】
ステップ１２２において、第４オプションを選択したと判定した場合、各ページの縮小版画像をユーザに供給し、ページの内容を一層明確に見るためにページを拡大するオプションを添付する。図４（Ｂ）を参照すると、第３オプションに必要な情報を生成するには、ステップ１２４において、ファクシミリ・メッセージの第１ページを抽出する。ステップ１２６において縮小版ＨＴＭＬ画像を作成し、次いでステップ１２８において原寸大のＨＴＭＬ画像を作成する。ステップ１３０において、原寸大画像へのリンクを有する、ページの埋め込みサムネイル画像を有するリストを生成する。このページが最後のページでないとステップ１４０において判定した場合、ステップ１４２において次のページを抽出し、ステップ１２６ないし１３０を繰り返し、ファクシミリ・メッセージのその他のページのＨＴＭＬファイルを生成する。第３オプションにしたがって最後のページをＨＴＭＬファイルに変換した後、ステップ１０４においてファイルをインターネット・サーバに移動する。
【００５６】
ステップ１４４において、ＭＳＤＳ１０は、第５オプションを選択したか否かについて判定を行う。第５オプションは、ユーザに、ファクシミリ・メッセージの各ページの原寸大画像を供給する。５つのオプションについてのみ論ずるが、本発明は追加のオプションを用いても実施可能である。したがって、追加のオプションがあって第４オプションを選択しないと、ＭＳＤＳ１０は追加オプションの１つを選択したと判定する。しかしながら、オプションを５つだけ有する本発明の好適な実施形態では、ＭＳＤＳ１０は、最初の４つのオプションを選択していないことが判明した場合、第５オプションを選択したと仮定する。
【００５７】
第５オプションにしたがってファクシミリ・メッセージのページを表示するために必要な情報を生成するには、まずステップ１４６においてファクシミリ・メッセージの第１ページを抽出する。ステップ１４８において、当該ページの原寸大ＨＴＭＬ画像を作成し、ステップ１５０において、埋め込み画像および前後のページへのリンクを有するリストを生成する。このページが最後のページでないとステップ１５２で判定した場合、ＭＳＤＳ１０は次のページを抽出し、当該ページのＨＴＭＬファイルを生成する。第４オプションにしたがって全てのページをＨＴＭＬファイルに変換した後、ステップ１０４においてファイルをインターネット・サーバに送る。
【００５８】
図４（Ａ）および図４（Ｂ）は、メッセージを受信する時点におけるＭＳＤＳ１０の動作を記述するが、図５は、ユーザが、ユーザの好むメッセージ表示オプション以外の表示フォーマットで情報のページを要求した場合の、ＭＳＤＳ１０の動作の全体的なフローチャートを示す。したがって、図５は、図３のステップ８２においてＭＳＤＳ１０がどのようにして必要な情報を生成するのかについての更に詳細な説明である。
【００５９】
概略的には、図５に示すように、ＭＳＤＳ１０は、最初にステップ８２ａにおいて必要な画像のタイプを判定する。例えば、このステップにおいて、ＭＳＤＳ１０は、画像が不要か、カバー・ページの画像のみが必要か、各ページの画像が必要か、そして画像は原寸、縮小版、または原寸および縮小版画像双方にする必要があるか否かについて判定を行う。ステップ８２ｂにおいて、ＭＳＤＳ１０は、画像を既に作成したか否かについて判定を行う。画像を未だ作成していない場合、ステップ８２ｃにおいて、ＭＳＤＳ１０はベースのファクシミリ・ファイルからページを抽出し、ステップ８２ｄにおいて必要なＨＴＭＬ画像を生成する。先に論じたように、必要なページは、カバー・ページだけ、またはページ全てという場合があり、更に当該ページの原寸大画像および／または縮小版画像という場合もある。ステップ８２ｅにおいて、他のＨＴＭＬファイルへのリンク即ちアンカーと共に画像を埋め込む。これらのリンク即ちアンカーは、次のページおよび前のページへのリファレンス、更に次のファクシミリ・メッセージおよび前のファクシミリ・メッセージのリファレンスとすることができる。最後に、図３のステップ８０において、埋め込み画像およびリンクを有するＨＴＭＬファイルをユーザに送る。
【００６０】
第５オプションにしたがってファクシミリ・メッセージをＨＴＭＬファイルに変換するプロセスについて、図６を参照しながら説明する。このプロセスは、メッセージを受信したとき、および第５オプションがメッセージを表示する際にユーザが好むオプションであるときに、ステップ５４において実行する。ユーザがファクシミリ・メッセージを検索しており、第５オプションがユーザの好むオプションではないときに、ユーザが第５オプションによる情報のページを要求した場合にも、同様のタイプのプロセスを実行することは理解されよう。他のオプションによる変換プロセスは、当業者には明白であろうから、これ以上詳細に論じないことにする。
【００６１】
図６を参照すると、ファクシミリ・メッセージを受信した場合、メッセージは、タグ付き画像ファイル・フォーマット／ファクシミリ（ＴＩＦＦ／Ｆ）となっており、ファクシミリ・メッセージの各ページは、別個のファイルに分割されている。次に、ファクシミリ・メッセージの各ページをＴＩＦＦ／Ｆフォーマットから移植可能画素マップ（ＰＰＭ：Portable Pixel Map）フォーマットに変換する。次に、ＰＰＭファイルを別個のグラフィック相互交換フォーマット（ＧＩＦ）ファイルに変換し、次いで別個のＨＴＭＬファイルに変換する。このように、ファクシミリ・メッセージの各ページを別個のＨＴＭＬファイルに変換する。ＴＩＦＦ／Ｆファイルは、「ＬＩＢＴＩＦＦ」称する入手可能なソフトウエア・パッケージを用いてＰＰＭに変換することができ、ＰＰＭファイルは、「Portable Pixel Map Tool」（移植可能画素マップ・ツール）内にある使用可能なソフトウエア・パッケージを用いてＧＩＦフォーマットに変換することができる。
【００６２】
本発明は、前述の通りの変換プロセスにも、変換プロセスにおいて用いられる特定のソフトウエア・パッケージにも限定されるものではない。例えば、ＴＩＦＦ／Ｆファイルは、他のあらゆるタイプの中間フォーマットを介して、別の移植可能なファイル・フォーマットにも変換可能であり、あるいは直接ＧＩＦフォーマットに変換することも可能である。更に、ＧＩＦの代わりに、ファクシミリ・メッセージをＪＰＥＧ、ＢＭＰ、ＰＸＣ、ＰＩＦ、ＰＮＧ、またはその他の適切なタイプのファイル・フォーマットであればいずれにでも変換可能である。
【００６３】
ファイルは、いずれかの適切なファイル名によって識別すればよい。好適な実施形態では、各ユーザ毎のファイルを、その一人のユーザだけに割り当てた別個のディレクトリに格納する。何故なら、所与のユーザのディレクトリ全体を保護するのは、個々のファイルよりも簡単であるからである。
【００６４】
しかしながら、メモリは別の方法で編成してもよく、単一のユーザに対するファイルを異なるディレクトリに格納する。ファイル名の最初の部分は、好ましくは当該ユーザにメッセージが到着する順番にしたがって順次決定した番号である。ファイル名を終了するための好適な命名規則を図６に示す。ファクシミリ・メッセージの各ページは、別個のファイルとしてセーブし、ファイルのフォーマットによって拡張子を定義する。したがって、個々のファイルのフォーマットにしたがって、ファイルには、「ＴＩＦＦ」、「ＰＰＭ」、「ＧＩＦ」または「ＨＴＭＬ」という拡張子を末尾に付ける。図示の例では、別個のページは、それぞれのページ番号を末尾に付けたファイル名を有する。例えば、最初のページには「１」が末尾に付く。しかしながら、ファイルは、ページの順序を示すためには、１つの文字または多数の文字を末尾に付けることが好ましい。例えば、ページ１は「aa」という末尾を有するとよく、ページ２は「ab」という末尾を有するとよい等である。しかしながら、本発明は、ここに開示する命名規則に限定される訳ではなく、当業者には明白な他の規則も念頭に入れている。
【００６５】
図６に示すように、ファクシミリ・メッセージのページを表わすＧＩＦファイルに加えて、ＨＴＭＬファイルは、多数のアンカー即ちリファレンスを含む。図示の例では、最初のＨＴＭＬファイルは、「Next Page」（次のページ）に対するアンカーを有する。アンカーａは、a=<A HREF="2.html'>Next Page</a>として定義し、したがってユーザが「Next Page」を選択した場合、２番目のＨＴＭＬファイルを参照する。２番目のＨＴＭＬファイルは、「Previous Page」（前のページ）に対するアンカーｂ、および「Next Page」に対するアンカーｃを有し、３番目のＨＴＭＬファイルは、「Previous Page」に対するアンカーｄを有する。これら個々のＨＴＭＬファイルによって、ユーザはファクシミリ・メッセージの各ページをスクロールし、ページの原寸大画像を視認することができる。
【００６６】
各ＨＴＭＬファイルは、「Next Page」および「Previous Page」に関係するもの以外にも、アンカーを含むことが好ましい。例えば、各ＨＴＭＬファイルは、次のファクシミリ・メッセージに対するアンカー、直前のファクシミリ・メッセージに対するアンカー、およびファクシミリ・リストに戻るためのアンカーを含むとよい。ＨＴＭＬファイルは、「Save」（セーブ）および「Delete」（削除）に関係するアンカーを含むことが好ましい。「Save」アンカーを選択した場合、ユーザは当該メッセージについてより記述的な名称で、そのメッセージをセーブすることができる。「Delete」アンカーには、ユーザが確かにメッセージを削除したいのかについての問い合わせを後ろに付けることが好ましい。全体リストへのアンカーのような、その他のアンカーは、当業者には明白であり、備えることも可能である。
【００６７】
図７は、図６に示したファクシミリ・メッセージの第１ページに対する、第５オプションによる表示の一例を示す。表示のヘッディングは、メッセージを送った電話番号についての情報、ＭＳＤＳ１０においてメッセージを受信した日時、および表示しているメッセージのページの指示を備えている。表示の主要部分は、ページの原寸大画像である。表示の下側部分には、「Next Page」へのアンカーまたはリンクを備え、更に「Return to Fax Listing」（ファックス・リストに戻る）への別のアンカーを備えている。表示上には、ＭＳＤＳ１０を運営している会社へのリンクというような、追加の情報を与えることも可能である。
【００６８】
図７に示す表示を生成する「1.html」ファイルの一例を、以下の表１に示す。
【００６９】
【表１】
0004230661.tif 000002
【００７０】
表１のリストから明らかなように、第１ページの画像ファイル「1.GIF」をＨＴＭＬファイル「1.html」に埋め込む。また、このリストから明らかなことは、「Next Page」に対するアンカーは、ＭＳＤＳ１０を、ファイル名「2.html」を有するファクシミリ・メッセージの第２ページに進ませ、更に「Return to Fax Listing」に対するアンカーは、ＭＳＤＳ１０を、ファクシミリ・メッセージのリストを含むファイル名「faxlist.html」に進ませることである。
【００７１】
ボイス・メッセージをＨＴＭＬファイルに変換するプロセスを図８に示す。ボイス・メッセージは、元来ＶＯＸフォーマットまたはＡＤ／ＰＣＭフォーマットで格納しており、ステップ１７０において検索する。次に、ユーザの好みにしたがって、ＡＵフォーマットまたはＷＡＶフォーマットのいずれかにボイス・メッセージを変換し、メモリに格納する。メッセージは元来ＡＤ／ＰＣＭフォーマットであり、ＷＡＶに変換することが好ましいが、ボイス・ファイルは、代わりに、格納して、ＲｅａｌＡｕｄｉｏ（ＲＡ）のような、開示したもの以外のファイル・フォーマットに変換してもよい。
【００７２】
ステップ１７４において、全ボイス・メッセージのリストを更新し、新たに受信したボイス・メールのリスト、および当該ボイス・メールへのアンカーを含むようにする。例えば、元のボイス・メッセージは、「1.vox」というファイル名で格納し、ＷＡＶに変換し、そしてファイル名「1.wav」で格納することができる。すると、全てのボイス・メールのリストを収容するＨＴＭＬファイル「voicelist.html」は、このボイス・メッセージを受信したときというような、このボイス・メッセージの識別情報と共に、ファイル名「1.wav」へのアンカーを有する。
【００７３】
ボイス・メッセージのリストは、追加のアンカー即ちリファレンスを有することも可能である。例えば、各ボイス・メッセージは、メッセージの短いサンプリングを含むファイルに、ＭＳＤＳ１０を進ませるアンカーを有することができる。したがって、ユーザがこのアンカーを選択すると、ユーザは、メッセージの最初の５秒、またはそれ以外のいずれかの既定秒数を受信することができる。ファクシミリ・メッセージのリストの場合と同様、ボイス・メッセージのリストも、「Save」および「Delete」へのアンカーを有することが好ましい。
【００７４】
図９は、データ・メッセージをＨＴＭＬに変換するプロセスを示す。ステップ１８０において、データベースからデータ・ファイルを検索し、ステップ１８２においてデータ・メッセージのリストを収容するＨＴＭＬファイルを更新し、新たに受信したメッセージのリストを、識別情報と共に含ませる。例えば、リスト「datalist.html」のＨＴＭＬファイルであれば、データ・ファイル「file.1」へのアンカーを含むように更新し、データを送信した日時、データ・ファイルのサイズ、および追加の識別情報というような情報を有する。
【００７５】
ＭＳＤＳ１０は、ファクシミリ・メッセージ、ボイス・メッセージまたはデータ・メッセージというような種々のタイプのメッセージを受信することができるので、ＭＳＤＳ１０は、ＤＩＤトランク１５を介して送られてくるメッセージのタイプを判定できなければならない。図１０を参照すると、着信呼を受信したとき、ＭＳＤＳ１０はステップ２００においてオフ・フック状態となり、呼び出し音を発生し始める。ステップ２０２において、ファクシミリ・コーリング・トーンを検出した場合、ステップ２０４において呼び出し音を停止し、ステップ２０６においてメッセージをファクシミリ・メッセージとして受信する。同様に、ステップ２０８においてデータ・モデム・コーリング・トーンを検出した場合、ステップ２１０において呼び出し音を停止し、ステップ２１２においてメッセージをデータ・メッセージとして識別する。
【００７６】
ステップ２１４においてＭＳＤＳ１０がＤＴＭＦディジットを検出した場合、ステップ２１６において呼び出し音を停止し、次いでＭＳＤＳ１０は、どのディジットが押されたのかについて判定を行う。ディジットが「1」であるとステップ２１８で判定した場合、メッセージをファクシミリ・メッセージとして識別する。その後、ＭＳＤＳ１０は、図２を参照して先に説明したように、ファクシミリ・メッセージを受信し格納する。ステップ２２０においてディジットを「０」として識別した場合、この呼を所有者の呼として識別し、図１２を参照して以下に述べるように処理する。明らかであろうが、他のディジットもＭＳＤＳ１０に追加のステップを実行させることができる。ステップ２２４において他のいずれかのＤＴＭＦディジットが押された場合、ＭＳＤＳ１０はボイス・コール・システムを活性化する。これについては、図１１を参照しながら以下で更に詳しく説明する。
【００７７】
ステップ２２６によって、ＭＳＤＳ１０は、ファクシミリ・コーリング・トーン、データ・モデム・コーリング・トーン、またはＤＴＭＦディジットを連続的にチェックするループに入る。ｎ回の呼び出しの後、これらのトーンまたはディジットのいずれも検出しなかった場合、ステップ２２８において呼び出し音を停止し、ステップ２２４においてボイス・コール・システムを活性化する。
【００７８】
図１１を参照すると、ファックス・コーリング・トーンまたはモデム・コーリング・トーンを検出しない場合、ステップ２３０において、音声の挨拶を開始することによって、ボイス・コール・システムを開始する。挨拶がＤＴＭＦディジットによって中断されなかったとステップ２３２において判定した場合、ステップ２３４において発呼側にボイス・メッセージを催促し、ステップ２３６においてボイス・メッセージを記録しメモリに格納する。ステップ２３８において、メッセージの聴取、メッセージのセーブ、またはメッセージの再記録というような、多数のオプションで発呼側を催促する。ＤＴＭＦディジットによるこれらのオプションの選択は当業者には明白であるので、このサブルーチンまたはサブルーチン群の詳細については、これ以上説明しない。発呼側がメッセージを記録することを望んでいるとステップ２４０で判定した場合、ステップ２３４において発呼側に再度メッセージを催促する。発呼側がメッセージを再度記録したくない場合、ステップ２４２において呼を終了する。
【００７９】
ＤＴＭＦディジットによって音声の挨拶が中断されたとステップ２３２で判定した場合、ＭＳＤＳ１０は、どのディジットが押されたのか確認する。ステップ２４４において、そのディジットが「0」である場合、ＭＳＤＳ１０は、呼が所有者の呼であることを検出する。ディジットが「1」である場合、ステップ２０６においてＭＳＤＳ１０は、呼がファクシミリ・メッセージを搬送することを通知する。図１０を参照しながら先に論じたように、その他のＤＴＭＦディジットも、ＭＳＤＳ１０に追加のステップを実行させることができる。無効のディジットが押された場合、ステップ２４８においてデフォルトとして、ルーチンはステップ２３４に戻り、発呼側にメッセージを催促する。
【００８０】
本発明は、図１１を参照しながら説明した具体的な双方向処理ボイス応答システムに限定される訳ではないことは理解されよう。先に論じたように、本発明は、「0」および「1」以外のＤＴＭＦディジットにも応答可能である。更に別の変様および変形も当業者には明白であろう。
【００８１】
図１２を参照すると、呼を所有者の呼と見なした場合、ステップ２５０において最初に発呼側にパスワードを催促する。ステップ２５２においてパスワードを受け取り、ステップ２５４において正しいことがわかったならば、１組のアナウンスを所有者に向けて再生する。これらのアナウンスは、受信した新たなメッセージの数、セーブしたメッセージの数、ファクシミリ・メッセージの数、データ・メッセージの数、およびボイス・メッセージの数を、所有者に通知することが好ましい。勿論、別のアナウンスもこの時点で作成可能である。
【００８２】
ステップ２５８において、次に所有者は、各オプションに適切なＤＴＭＦディジットを備えた、所有者のメニューの記録を受け取る。例えば、ＤＴＭＦディジット「1」はメッセージの再生と関連付けることができ、ＤＴＭＦディジット「2」はオプション・メニューと関連付けることができ、ＤＴＭＦディジット「*」は以前のメニューに戻ること、または以前のメニューが存在しない場合には、呼を終了することに関連付けることができる。
【００８３】
ステップ２６０においてＤＴＭＦディジットを検出し、受け取ったディジットに基づいて適切なアクションを実行する。つまり、ステップ２６４においてディジットが「1」であると判定した場合、所有者はステップ２６６においてメッセージを再生することができる。ステップ２６６において、新たなメッセージ、セーブしてあるメッセージ、ファクシミリ・メッセージ、データ・メッセージまたはボイス・メッセージを再生またはダウンロードするオプションを所有者に与えるメニューで、所有者を迎えることが好ましい。当業者には明白であろうが、所有者はステップ２６６において１つ以上のメニューを受け取ることもでき、更に所有者は１つ以上のＤＴＭＦディジットを入力し、特定のメッセージを再生またはダウンロードすることもできる。
【００８４】
代わりに、ステップ２６８において、ディジットが「2」あると判定した場合、ステップ２７０において所有者はオプション・メニューを受け取る。このオプション・メニューによって、所有者はＭＳＤＳ１０のある種のパラメータを入力または変更することができる。例えば、所有者は彼または彼女のパスワードを変更することができ、所有者はファクシミリ・メッセージをコンピュータ３２上に表示する方法を変更することができ、所有者は画像ファイル・フォーマットをＧＩＦから別のフォーマットに変更することができ、所有者はボイス・メッセージのファイル・フォーマットを選択することができ、更にその他のオプションも可能である。
【００８５】
「*」ＤＴＭＦディジットを受け取ったとステップ２７２で判定した場合、以前のメニューを所有者に戻す。「*」ディジットは、所有者が初期メニューに戻ったときに呼を終了するためにも用いることができる。したがって、「*」ディジットは、以前のメニューに戻るためのコマンドとして、種々のメニュー全体を通じて、ＭＳＤＳ１０によって例外なく認識される。
【００８６】
ＭＳＤＳ１０が用いていないＤＴＭＦディジットを所有者が入力した場合、ステップ２７６において所有者は、キーが無効であることの指示を受け取り、ステップ２５８において所有者に再度所有者のメニューが与えられる。所有者のメニューが表示されている間に所有者がＤＴＭＦディジットを入力しないとステップ２６０において判定した場合、メニューをｎ回表示する。一旦メニューをｎ回再生したとステップ２６２で判定したなら、ステップ２７８において呼を終了する。
【００８７】
パスワードが正しくないとステップ２５４において判定した場合、ＭＳＤＳ１０は、ステップ２８０において、ユーザが「ｎ」回を超えて試したか否かについてチェックを行う。「ｎ」回の試行を行っていない場合、ステップ２８２においてパスワード誤りメッセージをユーザに表示し、ステップ２５０においてユーザに再度パスワードを催促する。ユーザが正しいパスワードを入力する試行を「ｎ」回行った場合、ＭＳＤＳ１０はステップ２８４において失敗メッセージをユーザに再生し、次いでステップ２８６において呼を終了する。具体的な数値「ｎ」を３とすれば、３回試行が失敗した後、呼を終了することになる。
【００８８】
所有者のメニューは、ＤＴＭＦディジットの追加数に応答することができ、別の方法で構成することもできる。例えば、別個のＤＴＭＦディジットが、ファクシミリ・メッセージ、データ・メッセージ、またはボイス・メッセージのような、それぞれのタイプのメッセージに、所有者進ませることも可能である。また、別個のＤＴＭＦディジットが所有者を、新たなメッセージの記録、またはセーブしてあるメッセージの記録に進ませることも可能である。他の変形も当業者には明白であろう。
【００８９】
ＭＳＤＳ１０の更に詳細な図を図１３に示す。この図に示すように、複数のＤＩＤトランク１５を入出力デバイス１７によって受信し、次いで中央プロセッサ３に送る。ＤＩＤトランク１５の数は、ＭＳＤＳ１０に対して行われ得る電話呼の予想回数に対処するのに必要な適当な数であれば、いずれにでも変更可能である。入出力デバイス１７は、ＤＩＤトランク１５の１つにおける呼を、中央プロセッサ３のオープン・ポートに導出する。好ましくは、これをＥｘａｃｏｍ社が製造するＤＩＤインターフェース・ボックスとする。
【００９０】
中央プロセッサ３は、ＤＩＤトランク１５上の呼を受信し、ソフトウエア７にしたがってメッセージをストレージ１１に格納する。好ましくは、ストレージ１１内において、別個のディレクトリを、ＭＳＤＳ１０上にアカウントを有する各ユーザ毎に作成し、単一のユーザ宛てのメッセージ全てを同じディレクトリ内に格納するようにする。中央プロセッサ３内部にあるプロセッサの数は、ＤＩＤトランク１５の数によって異なることは理解されよう。より多くの電話呼を処理可能なＤＩＤトランク１５の数が多い程、中央プロセッサ３は実際には多数のコンピュータを備えることもできる。したがって、入出力デバイス１７は、着信呼を中央プロセッサ３内にある使用可能なコンピュータに導出するように機能する。
【００９１】
プロセッサ３の更に詳細な図を図１４に示す。中央プロセッサ３は、各ＤＩＤトランク１５毎に電話回線インターフェース２１を備えている。電話インターフェース２１は、呼び出し音を発生し、電話回線とのその他の通信インターフェース処理を備えている。電話インターフェース２１からの信号は、パルス／トーン・デコーダ２３、およびディジタル信号プロセッサ（ＤＳＰ）２５に導出する。パルス／トーン・デコーダ２３は、着信呼からアドレス信号を検出し、このアドレス信号をバス２９上でマイクロプロセッサ２７に送る。ＤＳＰは着信呼に対して必要な信号処理を実行し、処理した信号をマイクロプロセッサ２７に導出する。
【００９２】
次に、マイクロプロセッサ２７は、パルス／トーン・デコーダ２３からアドレス信号を読み出し、ＤＳＰ２５からのメッセージをストレージ１１内の適切なディレクトリに格納する。先に論じたように、中央プロセッサ３は、多数のコンピュータ、即ち、より正確には多数のマイクロプロセッサ２７を備え、各マイクロプロセッサ２７が、４つというようなある数のＤＩＤトランク１５からの呼を処理する。マイクロプロセッサ２７は、適切なマイクロプロセッサであればいずれでも構成可能であるが、少なくとも４８６ＰＣが好ましい。
【００９３】
着信呼を処理し、メッセージをストレージ１１に格納することに加えて、中央プロセッサ３はＭＳＤＳ１０の双方向処理ボイス応答システムの調整も行う。ソフトウエア７は、図３に示したメッセージを受信する動作、図１０に示した着信呼上のメッセージ・タイプを検出する動作、図１１に示したボイス・メッセージを受信する動作、および図１２に示した所有者の呼を受信する動作のフローチャートを１つに纏めたものである。先に参照したフローチャートおよびそれぞれの説明に基づけば、ソフトウエア７の生産は当業者の能力範囲内のことであり、これ以上詳しくは説明しない。
【００９４】
インターネット・サーバ５は、ローカル・エリア・ネットワークを通じてというようにして、中央プロセッサ３に接続してあり、更にストレージ１１にもアクセス可能である。インターネット・サーバ５は、ソフトウエア９に応じて多数の機能を実行する。例えば、インターネット・サーバ５は、中央コンピュータ３によってストレージ１１に格納したデータ・ファイルを検索し、ファイルを適切なＨＴＭＬファイルに変換する。次に、変換したＨＴＭＬファイルをストレージ１１に格納し、インターネット３０を通じてコンピュータ３２にダウンロードすることができる。また、インターネット・サーバ５は、コンピュータ３２からの要求も処理する。これらの要求を処理する場合、ストレージ１１からのファイルの検索、そして恐らくは追加のＨＴＭＬファイルの生成を必要とする。
【００９５】
したがって、インターネット・サーバ５のソフトウエア９は、図４に示したユーザの好みにしたがってＨＴＭＬファイルを生成する動作、図５に示したユーザから要求された情報を生成する動作、図６に示したファクシミリ・メッセージをＨＴＭＬに変換する動作、図８に示したボイス・メッセージをＨＴＭＬに変換する動作、および図９に示したデータ・メッセージをＨＴＭＬに変換する動作のフローチャートを１つに纏めたものと言えよう。先に参照したフローチャートおよびそれぞれの説明に基づけば、ソフトウエア９の生産は当業者の能力範囲内のことであり、これ以上詳しく説明する必要はない。
【００９６】
しかしながら、インターネット・サーバ５の更に詳細なブロック図を図１５に示す。インターネット・サーバ５は、好ましくはWindows NTである、適切なオペレーティング・システム（ＯＳ）３９上で走る。インターネット・サーバ５は、先に論じたフローチャートに示したプログラムのように、中央プロセッサ３と通信するため、およびストレージ１１やメモリ３３からのデータにアクセスするための、多数のアプリケーション・プログラム３１を有する。
【００９７】
とりわけ、メモリ３３は、各ユーザの好みを示すデータを収容する。したがって、例えば、ＴＩＦＦ／Ｆフォーマットのファクシミリ・メッセージをインターネット・サーバ５が検索する場合、インターネット・サーバ５はメモリ３３内のデータから、ファクシミリ・メッセージを表示する際の好みのオプションを確認し、適切なＨＴＭＬファイルを生成する。
【００９８】
インターネット３０とのインターフェース処理は全て、ＨＴＴＰＤ３７によって行う。好適な実施形態では、ＨＴＴＰＤ３７は、NetScape Communicaitons Corp.（ネットスケープ・コミュニケーションズ社）からの「Enterprise Server」である。ファイル要求のようなユーザからのあらゆる要求でも、ＨＴＴＰＤ３７が処理し、ＣＧＩ３５を介して転送し、次いでアプリケーション・プログラムが受け取る。次に、アプリケーション・プログラム３１は、要求されたファイルをＣＧＩ３５を介してＨＴＴＰＤ３７に転送し、次いでインターネット３０を通じてユーザのコンピュータ３２に転送するというように、要求にしたがって適切なアクションを実行する。
【００９９】
インターネット・サーバ５は、ページング・システム１３に接続することもできる。新たなメッセージの到着時に、インターネット・サーバ１３はページング・システム１３を活性化し、ページャ１５を活性化することも可能である。このように、ユーザは殆ど瞬時にメッセージが到着したことの通知を受信することができる。
【０１００】
ページング・システム１３は、英数字を送信し、メッセージをユーザのページャ１５に中継可能とすることが好ましい。したがって、インターネット・サーバ５は、ページング・システム１３が認識する信号を発生する信号プロセッサ４１、および電話インターフェース４３を備えている。信号プロセッサ４１は、アプリケーション・プログラム３１からの情報を受け取り、ＸＩＯ／ＴＡＰのようなページング・ファイル・フォーマットでページング・メッセージを生成する。電話インターフェース４３は、モデム、自動ダイアラ、およびページング・システム１３と通信するのに適したその他の構成部品を含む。
【０１０１】
アプリケーション・プログラム３１からの情報は、単にユーザにメッセージを通知するだけでよく、あるいは更に詳細な情報を提供してもよい。例えば、ファクシミリ・メッセージでは、アプリケーション・プログラム３１からの情報は、発信元の電話番号を識別するＣＳＩ情報を含むとよい。したがって、ユーザは、ページャ１５上で、指定された電話番号からファクシミリ・メッセージを受信したことをユーザに通知するメッセージを受信する。ページャ１５上でユーザに送ることができる情報の量およびタイプは、ページング・システム１３の能力によって様々であり、提示した例よりも多い量の情報を提供することも、少ない量の情報を提供することもあり得る。
【０１０２】
インターネット・サーバ５は、図１５に示す構造に限定される訳ではなく、追加の構成部品を備えることも可能である。例えば、ＨＴＴＰＤ３７は、モデムまたはルータのような、何らかのタイプのインターフェースを介してインターネット３０にリンクする。インターネット・サーバ５は、通常の電話回線、ＩＳＤＮ回線、Ｔ１回路、Ｔ３回路を通じて、または当業者には明白なその他の技術による別の方法で、インターネット３０に接続することができる。
【０１０３】
更に、インターネット・サーバ５は、インターネット３０に接続する必要はなく、他のタイプのネットワークに接続することも可能である。例えば、インターネット・サーバ５、またはより一般的にネットワーク・サーバ５は、大会社のために構築したネットワークのような、大規模な私的ネットワークに接続することも可能である。ネットワーク・サーバ５は、メッセージをＨＴＭＬファイルに変換し、ネットワーク上でユーザからの情報要求を受信し、そして情報をユーザに送信することにより、同様に動作する。
【０１０４】
また、少なくとも１つのインターフェース回路をインターネット・サーバ５と中央プロセッサ３との間に配置すれば、インターネット・サーバ５と中央プロセッサ３との間に通信機能が得られる。このネットワーク・インターフェースは、インターネット・サーバ５および中央プロセッサ３双方の内部、またはインターネット・サーバ５または中央プロセッサ３の一方のみの内部に備えることも可能である。
【０１０５】
インターネット・サーバ５のソフトウエア・レイヤの例を図１６（Ａ）および図１６（Ｂ）に示す。図１６（Ａ）は非同期通信モードにおけるインターネット・サーバ５を表わし、図１６（Ｂ）は同期通信モードにおけるインターネット５を表わす。これらの図に示すように、インターネット・サーバ５のソフトウエア９は、ＨＴＴＰＤ３７を走らせるためのインターネット・デーモンを追加的に備えることができる。また、インターネット・サーバ５のソフトウエア９は、ＴＣＰ／ＩＰまたはその他のトランスポート・レイヤも含む。更に、ＨＴＴＰＤ３７を介して認証を行うが、ユーザのパスワードおよびＩＤの認証は、別の認証方法で補充したり、または置き換えることも可能である。
【０１０６】
同期という用語は、可能な全てのメッセージ用ＨＴＭＬファイルをメッセージの受信時に生成する、ＭＳＤＳ１０の動作モードを意味する。ＨＴＭＬファイルは、中央プロセッサ３によってまたはアプリケーション・プログラム３１によって生成することができる。後にＨＴＴＰＤ３７が情報要求を受信したときに、情報は既に生成されており、ＨＴＴＰＤ３７は単にストレージ１１から情報を検索し、この情報をユーザのコンピュータ３２に送信するだけでよい。同期動作モードであれば、ＣＧＩ３５は不要である。
【０１０７】
ＭＳＤＳ１０は、非同期動作モードで動作することが好ましい。非同期動作モードでは、ユーザが要求する情報が得られない場合や、要求の後に生成しなければならない場合がある。非同期動作モードが好ましいのは、生成するファイル数が少なく、これによってストレージ１１の要求量が減少するからである。ユーザが要求する情報が得られない場合があるので、アンカーの中には「2.html」のように、ファイル名を指定できないものもあるが、代わりに当該ファイルのためのコマンドを含む。例えば、アンカーは、
<AHREF = "/faxweb/users/2496801/viewpage.cgi?FAX＿NUM = I&PAGE = 1&VIEW＿MODE = FULL">
として定義し、ＣＧＩ３５にビューページ・プログラム（viewpage program）を走らせ、ファクシミリ・メッセージ１のページ１を原寸大画像で表示するようにすることができる。ＣＧＩ３５は、要求された情報が生成されていないときに、その情報を生成し、それ以外の場合には、ＣＧＩ３５は情報を検索し、その情報をＨＴＴＰＤ３７に中継してユーザに送信する。
【０１０８】
本発明では、ＭＳＤＳ１０は、信頼性高くボイス、ファクシミリ、およびデータ・メッセージを複数のユーザのために受信し、一度に一人のユーザのために２つ以上のメッセージを受信することができる。メッセージは、ＭＳＤＳ１０に格納し、インターネット３０に接続することによって、いつでもユーザの都合に合わせて受信することができる。インターネットのワールド・ワイド・ウェブ３０は、常に拡大しているネットワークであり、ユーザに事実上世界中のあらゆる場所でもメッセージを検索することを可能にする。ユーザはインターネット３０に接続するためには市内料金を負担するだけでよいので、ユーザは比較的低コストでメッセージを検索または調べることができる。
【０１０９】
オフィスまたは家庭にいるユーザにとっても、ＭＳＤＳ１０は多数の恩恵を与える。ユーザは、ファクシミリ機械、ボイス・メール・システム、データ・メッセージを受信するための専用機械も不要である。また、ユーザは、メッセージの一部が失われることや、メッセージの機密性が犯されることを心配する必要もない。勿論、ユーザはファクシミリ機械やデータ・メッセージ専用コンピュータを有することが可能なことに変わりはない。しかしながら、ＭＳＤＳ１０は、ユーザが電話会社の「呼転送」機能を使用することを許すので、ユーザがオフィスにいないときというように、ユーザの都合に合わせてメッセージをＭＳＤＳ１０に転送することができる。
【０１１０】
ソフトウエア７およびソフトウエア９は、図示したフローチャートのままの形態に限定される訳ではなく、本発明によって具体化される特定のハードウエアに合わせて様々に変更可能である。ソフトウエアは、図示しない追加のプロセスを備えることもでき、または１つ以上の図示したプロセスを単一プロセスに組み合わせてもよい。更に、ソフトウエア７および９は、Silicon Graphics Workstationのような単一のコンピュータで実行することも可能であり、あるいは多数のコンピュータによって実行することも可能である。
【０１１１】
ファクシミリ・メッセージに信号処理を施し、ファクシミリ・メッセージの画像を、白黒のツートン画像から、可変グレー・スケール画像に変換することが好ましい。当技術分野では公知であるが、ファクシミリ・メッセージのグレー・スケール画像は、メッセージの単なる白黒画像よりも優れた画像を与える。この信号処理は、アンチ・エリアスまたはスムージング・フィルタのような、標準的なコントラスト曲線処理方法であればいずれでも備えることができる。信号処理は、ＴＩＦＦ／ＦからＧＩＦへの変換と同時に行うことができ、ファクシミリ画像の原寸大画像および縮小版画像双方について実行することが好ましい。
【０１１２】
更に、メッセージを表示または検索する際にユーザに与えるオプション数は、前述よりも多くても少なくともよい。オプションは、提示した形態そのものに限定される訳ではなく、ユーザがメッセージを他のフォーマットで検討または検索できるようにしてもよい。また、オプションは、ユーザが２つ以上のメッセージを単一のメッセージに結合したり、メッセージの一部分を削除したり、それ以外の方法でメッセージの内容を変更することを可能にするようにしてもよい。また、電話を通じてユーザに与える種々のメニューは、更に多くの数のオプションを有することも可能であり、ＭＳＤＳ１０は、単に１つのＤＴＭＦディジット以上を伴う応答を受け入れることも可能である。
【０１１３】
種々のメニューに開示した具体的なＤＴＭＦは、単なる例に過ぎず、当業者には明らかであろうが、他のディジットを代わりに用いることも可能である。例えば、「9」を「*」の代わりに用いてメニューを終了させる、即ち、前のメニューに戻ることも可能である。また、ＤＴＭＦディジットは、ユーザの個人的な規則にしたがって変更することも可能である。ユーザが以前のボイス・メール・システムを有する場合、ユーザはコマンドをカスタム化して、以前のシステムにおいて用いていたコマンドと対応付けることにより、ＭＳＤＳ１０に難なく移行することが可能である。
【０１１４】
ＭＳＤＳ１０は、ユーザをあるタイプのメッセージのみに制限することも可能である。例えば、ユーザは、ＭＳＤＳ１０がファクシミリ・メッセージのみを格納し、ＭＳＤＳ１０のコストを削減したいという場合もある。このような状況では、ＭＳＤＳ１０は、ユーザのために受信したメッセージのタイプが、ＭＳＤＳ１０がユーザの代わりに受信することを許可されたメッセージ・タイプであることをチェックする追加のステップを実行する。メッセージが許可されていないメッセージ・タイプの場合、ＭＳＤＳ１０は、そのメッセージを完全に無視するか、あるいはＭＳＤＳ１０は、誰かがＭＳＤＳ１０にメッセージをユーザに送ろうとしたことを、ユーザに通知することも可能である。
【０１１５】
更に、ＭＳＤＳ１０は、着信呼を処理する中央プロセッサ３、およびインターネット３０とインターフェースするインターネット・サーバ１０を有するものとして記載した。本発明は、２つの別個のプロセッサ以外にも、種々の方法で実施可能である。例えば、中央プロセッサ３およびインターネット・サーバ５は、着信呼を処理しインターネット３０とインターフェースするために単一のコンピュータまたはワークステーションで構成することも可能である。ＭＳＤＳ１０は、メッセージを格納する前に、ＨＴＭＬファイルに変換することができる。また、中央プロセッサ３は、インターネット・サーバ５の代わりに、ページング・システム１３と通信することも可能である。加えて、先に論じたように、中央プロセッサ３は多数のマイクロプロセッサ２７を備え、多数のＤＩＤトランクを処理することも可能である。
【０１１６】
本発明は、メッセージをＨＴＭＬに変換し、ＨＴＭＬファイルをインターネット３０を通じてコンピュータ３２に送信するものとして記載した。しかしながら、ＨＴＭＬフォーマットは、インターネット３０上で情報を交換するために現在では好ましいフォーマットであるに過ぎず、実際には、標準的な一般化したマークアップ言語の一形式に過ぎない。したがって、本発明はＨＴＭＬフォーマットには限定されず、インターネット３０上で情報を交換するために使用可能な、あらゆるタイプの混合メディア・ページ・レイアウト言語を用いても実施することが可能である。
【０１１７】
ＳＧＭＬは、いずれの特定規格にも限定されず、多数の派生語（dialects）および変形語も包含する。ＳＧＭＬ派生言語の一例は、仮想実現マークアップ言語（ＶＲＭＬ）であり、インターネットを通じて三次元画像を配信するために用いる。別の例として、インターネット３０を通じてＭＳＤＳ１０にアクセスするコンピュータ３２は、ハンドヘルド・デバイスで構成してもよい。ハンドヘルド・デバイスは、一般に、小型ディスプレイ・サイズ、入力能力の制約、帯域幅の制約、そしてメモリ、処理パワーおよび永続的な記憶量の制約というような、資源の制約を特徴とする。これら能力の制約を考慮して、インターネット３０に簡単にアクセスするために、ハンドヘルド・デバイス・マークアップ言語（ＨＤＭＬ）がハンドヘルド・デバイスのために提案されている。ＭＳＤＳ１０によってコンピュータ３２に送信するＳＧＭＬ情報は、したがって、ハンドヘルド・デバイスに適したＨＤＭＬ情報から成るものでも、ＶＲＭＬから成るものでも可能である。
【０１１８】
別の例として、拡張可能マークアップ言語（ＸＭＬ）は、ＳＧＭＬの省略版であり、文書タイプの定義を簡略化し、プログラマがこれらを処理するプログラムをより簡単に書くことができるようにするものである。ＸＭＬは、標準的なＳＧＭＬの複雑で使用頻度が少ない部分の一部を省略し、その代わりに、容易に理解し、ウェブ上での配信および相互処理性に対する適合度を高めたアプリケーションを容易に書くことができるという利点をもたらす。しかしながら、ＸＭＬはＳＧＭＬの派生言語であるので、したがって、ＭＳＤＳ１０は、ファクシミリ、ボイス、およびデータ・メッセージの、全ての派生言語や変種を含む、ＸＭＬへの変換、これらのメッセージのインターネット３０を通じてのコンピュータ３２への配信も念頭に入れている。
【０１１９】
別の例として、ＭＳＤＳ１０は「ダイナミックＨＴＭＬ」の使用も念頭に入れている。「ダイナミックＨＴＭＬ」とは、ＨＴＭＬ、スタイル・シート、および文書を動画化（animate）するスクリプトの組み合わせを記述するために用いられている用語である。文書オブジェクト・モデル（ＤＯＭ）は、プラットフォーム中立かつ言語中立のインターフェースであり、文書のコンテンツ、構造および様式の動的なアクセスおよび更新を可能にする。したがって、ＭＳＤＳ１０は、ＤＯＭの使用およびダイナミックＨＴＭＬを含み、動的なコンテンツをインターネット３０を通じてコンピュータ３２に配信することができる。
【０１２０】
また、ＭＳＤＳ１０は、ＨＴＴＰのいずれの特定バージョンや規格にも限定されず、したがっていずれの特定のハイパーテキスト転送プロトコル・デーモン３７にも限定されない。一般に、ＨＴＴＰは、ＴＣＰ上で走るデータ・アクセス・プロトコルであり、ワールド・ワイド・ウェブの基本である。ＨＴＴＰは、文書交換や管理から検索およびフォームの処理までの範囲に及ぶ種々の用途に対処するために設計された、汎用要求応答プロトコルとして始められた。ＨＴＴＰの発展によって、ＨＴＴＰに対する拡張および新たな機構に対する要求が続出した。その拡張は、キャッシュ処理、分散オーサリングおよびコンテンツ・ネゴシエーション（content negotiation）から、種々の遠隔プロシージャ・コール機構までの範囲にわたる。モジュール化アーキテクチャを有さないことにより、新たな機構の代償として、過度に複雑化し無限のプロトコルとなってしまった。例えば、プロトコル拡張プロトコル（ＰＥＰ）は、私的同意と公的仕様との間のテンション（tension）に対応し、かつＨＴＴＰクライアントおよびサーバのソフトウエア部品による拡張に対処するために設計されたＨＴＴＰの拡張メカニズムである。多重化プロトコル（ＭＵＸ）は、ＨＴＴＰより低いレイヤにおいて非同期メッセージングへの対応を導入する別の拡張である。これらＨＴＴＰの欠点の結果、新たなバージョンのＨＴＴＰ、即ち、ＨＴＴＰ−ＮＧが提案された。その目的は、簡単で拡張可能な分散型オブジェクト指向モデルに基づく、ＨＴＴＰプロトコルに新たなアーキテクチャを与えることである。例えば、ＨＴＴＰ−ＮＧは、オンラインでの支払のためのセキュリティおよび対応強化を含む商取引を支援する。別のバージョンのＨＴＴＰ、即ち、Ｓ−ＨＴＴＰは、安全なメッセージングを提供する。ＭＳＤＳ１０およびＨＴＴＰＤ３７は、ＨＴＴＰのこれらのバージョンまたはその他のバージョンも組み込むことができる。
【０１２１】
異なるバージョンのＨＴＴＰに加えて、ＭＳＤＳ１０のＨＴＴＰＤ３７は、ＨＴＴＰの他の実施態様とも動作可能である。例えば、Ｗ３Ｃは「Ｊｉｇｓａｗ」と呼ばれるＨＴＴＰの一実施態様を有する。Ｊｉｇｓａｗは、全体的にＪａｖａで書かれたＨＴＴＰサーバであり、移植性、拡張性、および効率に関して効果がある。ＭＳＤＳ１０は、ＪｉｇｓａｗまたはＨＴＴＰの別の実施態様を採用することも可能である。
【０１２２】
メッセージをユーザのコンピュータ３２に送信することに関して、ＭＳＤＳ１０にメッセージ全体をコンピュータ３２に送信することを要求することなく、ＭＳＤＳ１０は、ユーザがボイス・メッセージをサンプリングしたり、あるいはファクシミリ・メッセージをプレビューすることを可能にする。このサンプリング機能は、大きな利点である。何故なら、メッセージ全体の送信は、かなり長い時間期間にわたってコンピュータ３２を拘束することが多いからである。このように、ユーザは、プレビューまたはサンプル機構により、ユーザがメッセージをコンピュータ３２に送信する必要があるか否かについて判定することができる。
【０１２３】
前述のように、ユーザがメッセージ全体を送信する必要があると判断した場合、ユーザのコンピュータ３２は、比較的長い時間期間にわたってメッセージを受信している可能性が高い。メッセージ全体を受信し終えた後、ユーザは、メッセージを視認、聴取、検索またはセーブするオプションを有する。代案の１つとして、ユーザのコンピュータは、代わりに、メッセージを受信しつつ、ユーザにメッセージの内容を示すことも可能である。
【０１２４】
例えば、ボイス・メッセージでは、ユーザのコンピュータ３２は、メッセージを受信しながら、メッセージをオーディオ・スピーカに送ることができる。このように、メッセージをリアル・タイムで再生し、ユーザは、メッセージ全体が受信されるまで待って、その後にメッセージを聴取するという必要はなくなる。リアル・タイムでメッセージを再生するためには、メッセージはＲｅａｌＡｕｄｉｏ（ＲＡ）フォーマットであることが好ましい。ユーザは、これをボイス・メッセージに好ましいファイル・フォーマットとして選択することができる。
【０１２５】
動作において、ＭＳＤＳ１０は、ＲＡファイルを含むＨＴＭＬファイルを送信する。ユーザがコンピュータ３２上でブラウザを用いてＲＡファイルを選択した場合、ブラウザはＲＡファイルと共に用いるプログラムを活性化する。このプログラムの動作および機能は、当業者には明らかであり、別個のソフトウエア・パッケージとして入手可能であるか、あるいはブラウザ・プログラム内に組み込まれている。ＲＡプログラムは、メッセージを含むＲＡデータ・ファイルを、ＭＳＤＳ１０から要求し、ＲＡファイルをコンピュータ３２において受信しながら、このプログラムはメッセージをリアル・タイムで再生する。
【０１２６】
また、ＭＳＤＳ１０およびユーザのコンピュータ３２は、ファクシミリ・メッセージをコンピュータ３２が受信しながら、ファクシミリ・メッセージの各ページまたはライン毎でも表示することができる。更に、データ・メッセージの送信は、ボイスまたはファクシミリ・メッセージと比較して、比較的高速であるが、コンピュータ３２は、データ・メッセージを受信しながら、データ・メッセージに対するアクセスを許可するようにプログラムすることも可能である。
【０１２７】
本発明は、ボイス・メッセージの格納および送信を行うものとして記載した。ボイス・メッセージは、大抵の場合、ＭＳＤＳ１０に格納されている、最も頻繁に用いられるオーディオ・メッセージのタイプであろう。しかしながら、本発明は、あらゆるタイプのオーディオ・メッセージでも使用可能であり、単にボイス・メッセージのみに限定されるのではない。
【０１２８】
本発明の別の態様によれば、ＭＳＤＳ１０は、特定のユーザまたはユーザ・グループのためにアーカイブとして供する、ファイル・レポジトリとしても使用可能である。前述のように、ＭＳＤＳ１０は、特定のユーザ毎に全メッセージのリストを維持することができ、ユーザが彼または彼女のメールボックスにアクセスしたときに、これをユーザに表示する。ＭＳＤＳ１０は、全てのメッセージを、それらがボイス、ファクシミリ、またはデータであっても、ユーザのためにデータベース内に種類を問わずに格納する。したがって、ユーザは、メッセージの認証、および特定のメッセージの有無を確定する際に、ＭＳＤＳ１０をその拠り所とすることができる。したがって、ＭＳＤＳ１０を通じて、ユーザは、受信したｅメール・メッセージ、ファクシミリ・メッセージ、およびデータ転送の全ての正確な記録を維持することができる。
【０１２９】
ファイル・デポジトリとして供することに加えて、ＭＳＤＳ１０は、文書管理ツールとしても機能することができる。図２を参照しながら先に説明したように、ＭＳＤＳ１０がメッセージを受信すると、ＭＳＤＳ１０はメッセージ上の情報を用いてデータベースを更新する。この情報は、メッセージのタイプ、それがファクシミリ・メッセージか、ボイス・メッセージか、またはデータ・メッセージか、メッセージを受信した日時、バイト単位等でのファイルのサイズ、メッセージを残した発呼側の電話番号、およびファクシミリ・メッセージのページ数というようなその他の情報を含む。着呼側の電話番号は各ユーザに唯一であるので、この情報はメッセージの対象受信側も含む。
【０１３０】
ストレージ１１内にあるメッセージ用データ・エントリ３００の一例を図１７に示す。データ・エントリ３００は、単一のメッセージのみのエントリを表わし、各メッセージは別個のデータ・エントリ３００を有する。好ましくは、データ・エントリ３００は、リレーショナル・データベースに格納し、構造化クエリ言語（ＳＱＬ）によってサーチ可能とするとよい。
【０１３１】
図１７に示すように、メッセージのデータ・フィールド３００は、メッセージを記述する多数のデータ・フィールドで構成することができる。これらのデータ・フィールドの１つは、メッセージを受信する人の名前を示すフィールド３０１とするとよい。当業者には認められるであろうが、人を識別するには、人の名前の一部、または一意の番号によるというように、多数の方法で行うことができる。データ・エントリ３００内の別のフィールド３０２は、文書がファクシミリ・メッセージか、ボイス・メッセージか、またはデータ転送かというような、文書のタイプを示し、フィールド３０３および３０４は、それぞれ、ＭＳＤＳ１０がメッセージを受信した日付および時刻を示す。発呼側の電話番号をフィールド３０５に示し、バイト単位で測定することができるメッセージ・サイズをフィールド３０６に示し、メッセージのページ数をフィールド３０７に示す。メッセージを一意に識別する文書番号をフィールド３０８に示す。先に論じたように、特定のユーザのために受信したファイルまたはメッセージは、ＭＳＤＳ１０がこれらを受信した順序で順次付番していけばよい。しかしながら、ファイルおよびメッセージは、メッセージを受信した日付についての識別子と番号との組み合わせによる等、別の方法で付番または識別することも可能である。また、文書番号または識別子は、ユーザに宛てられる各ファイルまたはメッセージ毎に一意であるとよいが、代わりに、複数のユーザに宛てられる各ファイルまたはメッセージ毎に一意としてもよい。これは、ＭＳＤＳ１０がある会社全体または別のデータ・グループの文書を追跡する場合に有利である。
【０１３２】
フィールド３０１ないし３０８に加えて、メッセージまたはファイル用データ・エントリ３００は、メッセージまたはファイルの記述または文書化を行うための備考フィールド３０９を有することもできる。例えば、備考フィールド３０９は、メッセージを受け取るべきストレージのタイプを特定するために用いることができる。メッセージまたはファイルは、自動的に消去される前にメッセージを格納しておく時間長を別々にすることも可能である。メッセージのテキスト全体を格納するか否かというような、格納の形式も、フィールド３０９によって示すことができる。備考フィールド３０９内に含むことができる特性（trait）の別の例は、セキュリティである。時として、ユーザはＭＳＤＳ１０が会社全体の文書を追跡する場合等、他の人のメールボックスへのアクセスを望んだり、付与されることもある。フィールド３０９内にメッセージまたはファイルを秘密と指定することにより、ユーザは、他のユーザによる当該メッセージまたはファイルへのアクセスを制限または否定することができる。また、備考フィールド３０９は、ユーザが彼または彼女自身の望みに応じてＭＳＤＳ１０をカスタム化するために用いることもできる。例えば、ユーザが会社である場合、この会社は、１つのコードをマーケティングに、１つを営業に、１つの設計に、そして１つを法務にというように、メッセージが宛てられる部署に応じてメッセージを分類したい場合があろう。
【０１３３】
備考フィールド３０９の１つに対する別の使用例として、ユーザは備考フィールド３０９内に注釈を入力することができる。ユーザが最初にデータ・エントリ３００を受信するとき、エントリ３００は、例えば、空白のままになっているフィールド３０９を除いて、全てのフィールド３０１ないし３０８にはデータを含んでいる場合がある。したがって、ユーザは備考フィールドに彼または彼女の注釈を入力することができる。初期データ・エントリ３００は、発呼側の電話番号のフィールド３０５を含み、発呼番号の数字を収容する。しかしながら、ユーザは、フィールド３０５内にリストされている電話番号を単に読むだけでは、発呼側を容易に認識することができない場合もある。より明確に発呼側を示すために、ユーザはフィールド３０９に注釈を入力し、発呼側の名称を特定することができる。あるいは、フィールド３０９内のノートは、メッセージ内容の一部または全部を反映することができる。ユーザは、大きな文書またはメッセージを受信する場合があり、フィールド３０９内に当該文書またはメッセージの短い記述を入力することができる。別の例として、メッセージの受信側は、メッセージまたは文書を読んで、ある種の文書またはある量の商品の配達の要求というように、発呼側が受信側からの何らかのサービスまたは商品を要求していることを発見する場合もある。受信側は、文書またはメッセージを読み、フィールド３０９に何らかの注釈を書き込んで、取るべきアフター・サービスまたは処置の種類を示すことができる。そして、受信側のアシスタントは、フィールド３０９内のノートを見て、適切な処置を取り、要求されたサービスまたは商品を確実に配達するようにすることができる。データ・エントリにセキュリティ保護をかける場合、先に論じたように、備考フィールド３０９の１つが、アシスタントに、フィールド３０９だけに対して限定したアクセスを付与することができ、あるいはもっと広い範囲のアクセスを付与することによって、アシスタントがフィールド３０１ないし３０９や、実際の文書またはメッセージも視認できるようにする。フィールド３０９は、その他にも種々の目的に供することができるが、当業者には明白であろう。
【０１３４】
図１８は、文書管理の目的でＭＳＤＳ１０を用いる際のプロセス３２０を示す。図１８を参照すると、ステップ３２１において、ユーザは特定の文書または１組の文書のサーチ要求をＭＳＤＳ１０に送る。ユーザは、コンピュータ３２を用いてこの要求を発行する際、「Search Document」（文書サーチ）へのリンクのような、リンク上でクリックすればよい。「Search Document」へのリンクは、図３に示したステップ７２において、ユーザに彼または彼女のメールボックスへのアクセスを付与した後、ＭＳＤＳ１０がユーザに提示することができる。ＭＳＤＳ１０は、ユーザがステップ６２において最初にメールボックスにアクセスしようとするとき、またはコンピュータ３２からＨＴＴＰＤ３７が受信したＵＲＬが文書アーカイブを指し示すときというように、別の時点にユーザに文書アーカイブを探索するオプションを提示することができる。
【０１３５】
この要求に応答して、ＨＴＴＰＤ３７は、ステップ３２２において、ユーザにサーチ・クエリ・フォームを送り、ユーザに所望のサーチを定義させる。サーチ・クエリ・フォームの一例を図１９に示す。サーチ・クエリ・フォームは、データ・エントリ３００内のデータ・フィールド３０１ないし３０９の各々に１つのエントリを含むことができる。例えば、ユーザは、受信側に１つ以上の名称を入力し、ＭＳＤＳ１０にこれらの受信側に宛てられたメッセージまたは文書全てを探索させることができる。また、ユーザは、文書がファクシミリ、ボイス・メッセージまたはデータ・フィールドのどれであるかというように、文書のタイプを示すこともできる。また、サーチ・クエリ・フォームは、時間および日付の範囲を受け入れることが好ましい日付および時刻のためのエントリ、発呼側のＭＳＤＳ１０に対する電話番号のエントリも有する。また、サーチ・クエリ・フォームは、ファイル・サイズまたはページ数のエントリも含むことができ、これはメッセージがファクシミリ・メッセージである場合に関係がある。また、サーチ・クエリ・フォームは、文書番号の範囲を受け入れることができる文書番号のエントリ、および備考フィールドのエントリも含むことができる。
【０１３６】
ステップ３２３において、ユーザはコンピュータ３２を用いてサーチ・クエリ・フォームにサーチ・パラメータを入力し、インターネット３０を通じて情報をＭＳＤＳ１０に返す。ユーザは、いずれの１データ・フィールドに関するサーチでも定義することができ、あるいは２つ以上のデータ・フィールドの組み合わせに関するサーチも定義することができる。例えば、図２０に示す完成したサーチ・クエリ・フォームに反映されるように、ユーザは、文書タイプをファクシミリに指定し、発呼番号を（４０４）２４９−６８０１と指定することによって、サーチを定義することができる。一旦ユーザがサーチを定義し終えたなら、ユーザは次に画面の下側に示す「SEARCH」リンクを選択することにより、ユーザのコンピュータ３２は、完成したサーチ・クエリ・フォームをインターネット３０を通じてＭＳＤＳ１０のＨＴＴＰＤ３７に送る。
【０１３７】
ステップ３２４において、ＨＴＴＰＤ３７は、完成したサーチ・クエリ・フォームを受信し、ＣＧＩ３５を介して、１つ以上のアプリケーション・プログラム３１を呼び出して所望のサーチを実行し、サーチのパラメータに該当するあらゆるファイルまたはメッセージを求める。サーチの結果は、アプリケーション・プログラム３１からＣＧＩ３５を介してＨＴＴＰＤ３７に渡され、ステップ３２５においてインターネット３７を通じてユーザに返送する。好ましくは、ＭＳＤＳ１０は、サーチ・パラメータ内に含まれる全てのファイルまたはメッセージのリストの形態でサーチ結果を返送するが、ＭＳＤＳ１０は他の方法で結果を返送することも可能である。
【０１３８】
図２０に示すクエリのサーチ結果の一例を図２１に示す。先に論じたように、サーチのパラメータは、電話番号（４０４）２４９−６０８１からの全てのファクシミリ・メッセージであった。図２１を参照すると、このクエリの結果、３つのメッセージが発見された。最初の文書は、文書番号１１であり、指定した電話番号からJane Doe（ジェーン・デュー）への１９９５年５月３１日付けのファクシミリであると記述してあり、３ページから成るものである。この最初に掲示されている文書は、図７に示すファクシミリの一例である。他の２つの文書は、それぞれ文書番号２４３および１，００２に対応し、これらも指定された電話番号からのものである。
【０１３９】
ステップ３２６において、ユーザは、メッセージおよびファイルのリストから所望のファイルまたはメッセージを選択する。例えば、最初に掲示されている文書、即ち、文書番号１１上でクリックすることによって、コンピュータ３２は、ＭＳＤＳ１０に当該文書を視認する要求を送り、これに応答して、ＭＳＤＳ１０は、ユーザが定義した好みに応じて文書の視覚化（viewing）を行う。前述のように、ユーザは第１ページの縮小版画像、第１ページの原寸大画像、全ページの縮小版画像、またはファクシミリ・メッセージの全ページの原寸大画像を受信することができる。したがって、ユーザが、第４の表示オプションを、ユーザが定義した好みとして選択した場合、ＭＳＤＳ１０は、図７に示したように、ファクシミリの第１ページの画像を返送する。
【０１４０】
ステップ３２６において、ユーザはＭＳＤＳ１０にサーチ結果をセーブさせることも可能である。例えば、図２１に示すように、ユーザは「CHARLES R. BOBO FACSIMILES」（チャールズ Ｒ. ボボ ファクシミリ）の名称を、サーチの名称として入力することができる。「SAVE SEARCH AS」（サーチをセーブ）リンク上でクリックすることによって、サーチの名称をコンピュータ３２からＭＳＤＳ１０に供給する。ＭＳＤＳ１０においては、ＨＴＴＰＤ３７がコンピュータ３２からのこの情報をＣＧＩ３５に転送し、ＣＧＩ３５はアプリケーション・プログラム３１を呼び出して、指定された名称の下で、ストレージ１１にサーチ結果を格納する。呼び出したアプリケーション・プログラム３１は、全てのメッセージの内容を格納するのではなく、むしろサーチ結果のリストをストレージ１１に格納することが好ましい。
【０１４１】
サーチの結果は、閉じたサーチ（closed search）または開いたサーチ（open search）のいずれかとしてストレージ１１に格納することができる。ＭＳＤＳ１０がサーチの結果を開いたサーチとしてセーブすると、この名称を指定したサーチにおけるファイルまたはメッセージを、サーチの特定のサーチ・パラメータに該当する最新のファイルまたはメッセージによって更新することができる。一方、閉じたサーチとは、名称を指定したサーチにおけるファイルまたはメッセージを、サーチ時点において存在するものに限定するものである。例えば、ＭＳＤＳ１０が図２１に示すサーチ結果を閉じたサーチとしてセーブすると、「CHARLES R. BOBO FACSIMILES」のいずれの検索でも、リストにある３つの文書が得られるだけである。一方、「CHARLES R. BOBO FACSIMILES」と名称を指定したサーチをＭＳＤＳ１０によって開いたサーチとしてセーブすると、ＭＳＤＳ１０は、コンピュータ３２による要求に応答して、当該サーチのために、図２０に示すサーチ・クエリを再度活性化し、当該特定の電話番号からのファクシミリ・メッセージを全て獲得する。この中には、サーチ結果を最初にセーブした後に受信したものが含まれる。
【０１４２】
図１９を参照すると、新たなサーチを定義する代わりに、ユーザは、「STORED SEARCHES」（格納済みサーチ）リンク上でクリックすれば、以前に行ったサーチの結果を受信することができる。例えば、このリンク上でクリックすることによって、ＭＳＤＳ１０は、図２２に示すサーチのように、この特定のユーザのために格納してあるサーチのリストを返送することができる。この図に示すように、格納してあるサーチのリストの中には、「CHARLES R. BOBO FACSIMILES」が含まれている。次に、ユーザが「CHARLES R. BOBO FACSIMILES」のサーチを選択すると、ユーザには、図２１に示すファクシミリのリストを提示することができ、恐らくサーチ・グループに最新の追加が含まれている。
【０１４３】
図１９を参照すると、ステップ３２２において、ＭＳＤＳ１０はユーザに「RECENT FILES」（最新ファイル）へのリンクを与えることもできる。このリンクを選択することによって、ＭＳＤＳ１０は、最後の１か月というような、特定の時間期間に受信した全てのファクシミリ、ボイス、およびデータ・メッセージのリストを返送ことができる。「STORED SEARCH」のリストの代わりに、サーチ・クエリ・フォーム上に「RECENT FILES」リンクを置くことにより、ユーザは最新のファイルおよびメッセージに素早く移ることができる。このサーチ・クエリ・フォームは、ユーザに代わってＭＳＤＳ１０が行った最後のサーチへのリンク等、このようなアクセスが容易な別のリンクを含むことができる。
【０１４４】
ＭＳＤＳ１０が受信するメッセージまたはファイルは、第三者から到着する必要はない。言い換えると、ＭＳＤＳ１０は、ファイル・レポジトリとして、またはユーザ自身が発生した文書のファイル・マネージャとして用いることも可能である。ユーザは、指定した電話番号に発呼して、メッセージを受信し、ボイス・メッセージ、データ・メッセージ、またはファクシミリ・メッセージを送信することができ、更にＭＳＤＳ１０にこれらのメッセージの受信および内容を文書化させることができる。ユーザは、容易にファクシミリ機械をスキャナとして用い、文書をＭＳＤＳ１０のストレージ１１に入力することができる。
【０１４５】
ＭＳＤＳ１０は、メッセージ配信装置、ファイル・レポジトリ、およびファイル・マネージャとして供することに関して、先に論じた用途以外にも、用途があると考えられる。例えば、ＭＳＤＳ１０は、着信呼をユーザに転送する前に、これらに何らかの追加処理を行うことができる。ボイス・メッセージでは、このプロセスは、メッセージを転記し、転記したメッセージをユーザに返送することを含むことができる。したがって、ＭＳＤＳ１０は、秘書としての補助を提供するものとみなすことができ、これは秘書を雇う余裕のない小さな会社や個人、またはどちらかと言えば過剰な補助を必要とする大会社にとっても非常に貴重であろう。転記は、世界のあらゆる場所にいる個人によっても行うことができ、あるいはＩＢＭからのＶｏｉｃｅＴｙｐｅのような、音声テキスト認識ソフトウエアによって自動的に行うことも可能である。
【０１４６】
ＭＳＤＳ１０が提供可能な別のタイプの処理は、翻訳サービスであろう。着信呼が音声、ファクシミリ、またはデータ・メッセージであっても、これをＳＧＭＬに変換し、次いで最初にトランスレータに転送することができる。インターネットに到達すれば、トランスレータは事実上世界中のどこにでも配置することができ、翻訳した文書をインターネットを通じてＭＳＤＳ１０に返送することができる。ＭＳＤＳ１０は、翻訳が完了したことを、ｅメール、ボイス・メール、ページャ、ファクシミリ、またはその他の方法でユーザに通知することができる。次いで、ユーザは、インターネットに接続して、翻訳した文書を検索することができる。ＭＳＤＳ１０の翻訳サービスは、音声テキスト認識ソフトウエアを用いてというようにして、メッセージの転記を行うことも可能である。
【０１４７】
前述の本発明の好適な実施形態の説明は、例示および記載の目的のためにのみ提示したに過ぎないものである。開示した正確な形態が全てであり、本発明をこれに限定することを意図する訳ではない。前述の教示に沿って多くの変更や変形が可能である。
【０１４８】
前述の実施形態は、本発明の原理およびその実用的用途を説明し、他の当業者が本発明および種々の実施形態を、考えられる個々の使用に適した変形と共に、利用可能とするために選択し、説明したのである。本発明の範囲は、添付した請求の範囲によってのみ限定されることを意図するものである。
【図面の簡単な説明】
【図１】  メッセージ格納および配信システムＭＳＤＳの接続を示すブロック図である。
【図２】  図１のＭＳＤＳにメッセージを送信する動作の全体的フローチャートである。
【図３】  図１のＭＳＤＳにおいて格納したメッセージを受信する動作の全体的フローチャートである。
【図４（Ａ）】  ユーザの優先度に応じてＨＴＭＬファイルを生成する動作のフローチャートである。
【図４（Ｂ）】  ユーザの優先度に応じてＨＴＭＬファイルを生成する動作のフローチャートである。
【図５】  要求された情報を発生する動作のフローチャートである。
【図６】  ファクシミリ・メッセージをＨＴＭＬファイルに変換する動作のフローチャートである。
【図７】  第４の表示選択肢によるファクシミリ・メッセージに第１ページの表示例である。
【図８】  ボイス・メッセージをＨＴＭＬファイルに変換する動作のフローチャートである。
【図９】  データ・メッセージをＨＴＭＬファイルに変換する動作のフローチャートである。
【図１０】  ＭＳＤＳ１０において受信した呼のタイプを検出する動作のフローチャートである。
【図１１】  ボイス・メッセージを受信する動作のフローチャートである。
【図１２】  所有者の呼との双方向処理を行うための動作のフローチャートである。
【図１３】  ＭＳＤＳ１０の更に詳細なブロック図である。
【図１４】  図１３における中央プロセッサのブロック図である。
【図１５】  図１３のインターネット・サーバのブロック図である。
【図１６（Ａ）】  図１３のインターネット・サーバに可能なソフトウエア・レイヤを示す図である。
【図１６（Ｂ）】  図１３のインターネット・サーバに可能なソフトウエア・レイヤを示す図である。
【図１７】  メッセージ信号に対するデータ入力の図である。
【図１８】  サーチ・クエリを送り、サーチを行い、サーチ結果をインターネットを通じてコンピュータに返送するプロセスのフローチャートである。
【図１９】  所望のサーチを定義するサーチ・クエリ・フォームの一例である。
【図２０】  完成したサーチ・クエリの一例である。
【図２１】  図２０のサーチ・クエリに応答してコンピュータに戻された１組のサーチ結果の一例である。
【図２２】  格納したサーチのリストの一例である。
【図１】
0004230661.tif 000003
【図２】
0004230661.tif 000004
【図３】
0004230661.tif 000005
【図４】
0004230661.tif 000006
0004230661.tif 000007
【図５】
0004230661.tif 000008
【図６】
0004230661.tif 000009
【図７】
0004230661.tif 000010
【図８】
0004230661.tif 000011
【図９】
0004230661.tif 000012
【図１０】
0004230661.tif 000013
【図１１】
0004230661.tif 000014
【図１２】
0004230661.tif 000015
【図１３】
0004230661.tif 000016
【図１４】
0004230661.tif 000017
【図１５】
0004230661.tif 000018
【図１６】
0004230661.tif 000019
0004230661.tif 000020
【図１７】
0004230661.tif 000021
【図１８】
0004230661.tif 000022
【図１９】
0004230661.tif 000023
【図２０】
0004230661.tif 000024
【図２１】
0004230661.tif 000025
【図２２】
0004230661.tif 000026