(57)【要約】【課題】インターネットへのアクセスが所定のハイパーテキスト転送プロトコルの使用に制限される環境のホストでも、ＰＯＰ等のメール転送プロトコルを使用して各種のメール処理を簡易に実現可能なホームゲートウェイおよびホームゲートウェイ制御プログラムを得る。【解決手段】ホームゲートウェイ２０５のＨＴＴＰサーバ部２１３は、ＬＡＮ２０４側のＨＴＴＰクライアントの要求を処理し、メール・ウエブメール変換部２１５へメールの受信や送信の要求を行う。メールクライアント部２１４は、メール・ウエブメール変換部２１５からの要求に応じて、ＷＡＮ２０６側のメールサーバとの間でメールの送受信を行う。メール・ウエブメール変換部２１５は、ＨＴＴＰサーバ部２１３からの要求の内容を解析して、メールクライアント部２１４にメール送受信の要求を行う。メールサーバ側の応答も同様に処理される。【選択図】図２
2008078774.tif 000002
【特許請求の範囲】
【請求項１】
ハイパーテキスト転送プロトコルを使用して所定の通信端末との間でパケットの送受信を行うハイパーテキスト転送プロトコル用通信手段と、
所定のメール転送プロトコルを使用してインターネットに接続されたメールサーバとの間でパケットの送受信を行うメール転送プロトコル用通信手段と、
前記所定の通信端末から前記ハイパーテキスト転送プロトコル用通信手段を用いてメールの処理の要求があったときその処理の内容を解析する処理内容解析手段と、
この処理内容解析手段の解析結果に応じて前記メールサーバ宛の対応するメール操作要求に変換するメール操作要求変換手段と、
このメール操作要求変換手段の変換したメール操作要求を前記メール転送プロトコル用通信手段を用いて前記メールサーバに送信するメールサーバ送信手段
とを具備することを特徴とするホームゲートウェイ。
【請求項２】
前記メールサーバを用いたメールとウエブメールとの変換を行うメール・ウエブメール変換手段を備え、前記処理内容解析手段の解析結果がメール受信要求であるとき、前記メールサーバ送信手段はメールの受信要求を前記メールサーバに送信することを特徴とする請求項１記載のホームゲートウェイ。
【請求項３】
前記メール転送プロトコル用通信手段は、メール転送プロトコルとしてＰＯＰ（Post Office Protocol）あるいはＩＭＡＰ（Internet Messages Access Protocol）を使用することを特徴とする請求項２記載のホームゲートウェイ。
【請求項４】
前記メールサーバを用いたメールとウエブメールとの変換を行うメール・ウエブメール変換手段を備え、前記処理内容解析手段の解析結果がメール送信要求であるとき、前記メールサーバ送信手段はメールの送信要求を前記メールサーバに送信することを特徴とする請求項１記載のホームゲートウェイ。
【請求項５】
前記メール転送プロトコル用通信手段は、メール転送プロトコルとしてＳＭＴＰ（Simple Mail Transfer Protocol）を使用することを特徴とする請求項４記載のホームゲートウェイ。
【請求項６】
前記ハイパーテキスト転送プロトコルはＨＴＴＰ（Hyper Text Transfer Protocol）またはＨＴＴＰＳ（Secure Hyper Text Transfer Protocol）であることを特徴とする請求項１または請求項２記載のホームゲートウェイ。
【請求項７】
前記処理内容解析手段は、ＵＲＬ（Uniform Resource Locator）によって処理の内容を解析することを特徴とする請求項１記載のホームゲートウェイ。
【請求項８】
ホームゲートウェイのコンピュータが、
ハイパーテキスト転送プロトコルを使用して通信を行う所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析する処理内容解析処理と、
この処理内容解析処理の解析結果を前記メールサーバ宛の対応するメール操作要求に変換するメール操作要求変換処理と、
このメール操作要求変換処理で変換したメール操作要求がメール受信要求であるとき、メール転送プロトコルとしてＰＯＰ（Post Office Protocol）あるいはＩＭＡＰ（Internet Messages Access Protocol）を使用して前記メールサーバにメール受信要求を送信するメール受信要求送信処理
とを実行することを特徴とするホームゲートウェイ制御プログラム。
【請求項９】
ホームゲートウェイのコンピュータが、
ハイパーテキスト転送プロトコルを使用して通信を行う所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析する処理内容解析処理と、
この処理内容解析処理の解析結果を前記メールサーバ宛の対応するメール操作要求に変換するメール操作要求変換処理と、
このメール操作要求変換処理で変換したメール操作要求がメール送信要求であるとき、メール転送プロトコルとしてＳＭＴＰ（Simple Mail Transfer Protocol）を使用して前記メールサーバにメール送信要求を送信するメール送信要求送信処理
とを実行することを特徴とするホームゲートウェイ制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホームゲートウェイおよびホームゲートウェイ制御プログラムに関する。
【背景技術】
【０００２】
家庭内の各種の電子機器や電気製品をネットワークで接続したホームネットワークが進展している。たとえば、従来から電話回線に接続された電話、ファクシミリといった通信機器や、インターネットに接続されたパーソナルコンピュータといった電子機器の他に、テレビジョンやＤＶＤ（Digital Versatile Disc）レコーダ等のＡＶ（Audio Video）製品や、冷蔵庫、エアーコンディショナといった白物家電およびドアホンが家庭内でのサービスの多様化と共に相互接続する必要性が生まれている。ホームゲートウェイは、これらの各種の装置を、アドレス変換やデータの載せ換えにより相互接続するようになっている。ホームゲートウェイは、これらの装置をインターネットに接続する橋渡しの役割も担っている。
【０００３】
図１１は、ホームゲートウェイを使用した従来のメールシステムを表わしたものである。このメールシステム１００で、インターネット１０１にはメールサーバ１０２と携帯電話機等のモバイル端末１０３が接続されている。更に、第１のパーソナルコンピュータ（ＰＣ）１０４はＬＡＮ（Local Area Network）１０５によってホームゲートウェイ１０６に接続されている。このホームゲートウェイ１０６はＷＡＮ（Wide Area Network）１０７によってインターネット１０１に接続されている。また、第２のパーソナルコンピュータ１０８はファイアウォール１０９という不正アクセスを防止するゲートウェイを介してインターネット１０１に接続されている。
【０００４】
ここで、メールサーバ１０２は、ＰＯＰ（Post Office Protocol）およびＳＭＴＰ（Simple Mail Transfer Protocol）の２つのメール転送プロトコルを用いて、メールの送受信サービスを行うようになっている。たとえば、第１のパーソナルコンピュータ１０４は、メールの送受信をホームゲートウェイ１０６を介して行うようになっている。
【０００５】
ところで、ＰＯＰあるいはＳＭＴＰでのみメールのサービスを行うメールサーバ１０２は、当然ながら、これらのメール転送プロトコルを使用できないネットワークからは利用することができない。たとえば、第２のパーソナルコンピュータ１０８に接続されたファイアウォール１０９が、これらのメール転送プロトコルに対応したアプリケーション・レイヤ・フィルタを備えていない場合には、メールサーバ１０２との間でＰＯＰあるいはＳＭＴＰを使用したメールの送受信が不可能である。そこで、この例の場合には、図示しないアプリケーション・レイヤ・フィルタを通過するメール転送プロトコルを使用したメールの送受信サービスを行う必要がある。
【０００６】
また、メールサーバ１０２は、ＩＳＰ（Internet Service Provider）網以外からＰＯＰやＳＭＴＰを使用できないといった接続制限を行っている場合が多い。このような場合、携帯電話機等のモバイル端末１０３は、インターネット１０１の接続業者を使用していないということでＰＯＰやＳＭＴＰを用いたメールの送受信サービスを利用することができない。
【０００７】
以上説明したように、モバイル端末１０３や第２のパーソナルコンピュータ１０８は、ＨＴＴＰ（Hyper Text Transfer Protocol）を使用してインターネット１０１にアクセスして各種のホームページを閲覧することができるものの、インターネット１０１上でのＰＯＰに対応したメールサーバ１０２におけるメール閲覧や、ＳＭＴＰに対応したメールサーバ１０２におけるメールの送信ができないという問題があった。
【０００８】
そこで、プロキシサーバを用いることでモバイル端末がＰＯＰあるいはＳＭＴＰを使用したメールの送受信を可能にするメールシステムが提案されている（たとえば特許文献２参照）。
【０００９】
図１２は、この提案のメールシステムの概要を表わしたものである。図１２で図１１と同一部分には同一の符号を付しており、これらの説明を適宜省略する。この提案のメールシステム１２０では、インターネット１０１に専用線１２１を介してＩＳＰ１２２が接続されている。携帯電話機等のモバイル端末１０３は、ホームゲートウェイ１２３を介してＩＳＰ１２２に接続されている。ホームゲートウェイ１２３は、プロキシサーバ格納部１２４とプロキシサービス部１２５を備えている。ここで、プロキシサーバ格納部１２４は複数のプロキシサーバを格納しており、モバイル端末１０３からの要求に応じて選択的に起動するようになっている。また、プロキシサービス部１２５は、モバイル端末１０３等のクライアントからの要求に応じて、インターネット１０１へ代理でアクセスし、これらから取得した情報をクライアントへ提供するようになっている。
【００１０】
図１３は、プロキシサービス部の処理の内容を表わしたものである。プロキシサービス部１２５は、モバイル端末１０３からインターネット接続の指示があると、ホームゲートウェイ１２３とインターネット１０１との接続を確立する（ステップＳ１４１）。次にプロキシサービス部１２５は、図示しない記憶手段に設定されたプロキシサーバ選択情報を参照して（ステップＳ１４２）、モバイル端末１０３の表示能力に適合したデータ加工処理を行うプロキシサーバを選択し起動させる（ステップＳ１４３）。次にモバイル端末１０３からの要求に応じて、インターネット１０１へ代理でアクセスし（ステップＳ１４４）、これらから取得した情報をモバイル端末１０３に提供する。
【００１１】
プロキシサービス部１２５は、モバイル端末１０３から切断要求があったか否かを判定し（ステップＳ１４５）、切断要求があるまで（Ｎ）、ステップＳ１４４の処理を繰り返す。切断要求があれば（ステップＳ１４５：Ｙ）、選択されたプロキシサーバを終了させて（ステップＳ１４６）、インターネット１０１との接続を切断する（ステップＳ１４７）。
【特許文献１】特開２００２−０６３１１６号公報（第００４９段落、第００５０段落、図１）
【発明の開示】
【発明が解決しようとする課題】
【００１２】
一般に、プロキシサーバが携帯電話機等のモバイル端末１０３の代理でメールサーバ１０２に接続し、ＰＯＰあるいはＳＭＴＰによるメールの授受を行うことは可能である。ところが、図１２の例と異なるが、インターネット１０１上にプロキシサーバを配置することは、個人レベルで手軽に行えるものではなく、その実現が困難である。
【００１３】
そこで、図１２および図１３で説明したように自宅内等のホームゲートウェイ１２３にプロキシサーバを用意することが提案されるに至っている。ところが、プロキシサーバをたとえばホームゲートウェイ１２３内に配置するようにすると、このプロキシサーバを実現するためのコンピュータを常に起動した状態に維持しておく必要がある。また、モバイル端末１０３等のリモートホストがプロキシサーバに接続できるように、ホームゲートウェイに特殊な設定が必要とされた。
【００１４】
そこで本発明の目的は、インターネットへのアクセスが所定のハイパーテキスト転送プロトコルの使用に制限される環境のホストでも、ＰＯＰ等のメール転送プロトコルを使用して各種のメール処理を簡易に実現可能なホームゲートウェイおよびホームゲートウェイ制御プログラムを提供することにある。
【課題を解決するための手段】
【００１５】
請求項１記載の発明では、（イ）ハイパーテキスト転送プロトコルを使用して所定の通信端末との間でパケットの送受信を行うハイパーテキスト転送プロトコル用通信手段と、（ロ）所定のメール転送プロトコルを使用してインターネットに接続されたメールサーバとの間でパケットの送受信を行うメール転送プロトコル用通信手段と、（ハ）前記した所定の通信端末からハイパーテキスト転送プロトコル用通信手段を用いてメールの処理の要求があったときその処理の内容を解析する処理内容解析手段と、（ニ）この処理内容解析手段の解析結果に応じてメールサーバ宛の対応するメール操作要求に変換するメール操作要求変換手段と、（ホ）このメール操作要求変換手段の変換したメール操作要求をメール転送プロトコル用通信手段を用いてメールサーバに送信するメールサーバ送信手段とをホームゲートウェイに具備させる。
【００１６】
すなわち本発明では、ハイパーテキスト転送プロトコル用通信手段によって通信する携帯電話機等の所定の通信端末がインターネット上のメールサーバを用いてメール処理を行おうとしたとき、ホームゲートウェイ側でこの通信端末から送られてくる処理の内容を解析して、メール操作要求変換手段が解析結果に応じてメールサーバ宛の対応するメール操作要求に変換することにしている。変換後のメール操作要求は、メール転送プロトコル用通信手段を用いてメールサーバに送信されることになる。これにより、通信端末はメールサーバを用いてメールの送信や受信といった各種処理が可能になる。
【００１７】
請求項８記載の発明では、ホームゲートウェイのコンピュータが、ホームゲートウェイ制御プログラムとして、（イ）ハイパーテキスト転送プロトコルを使用して通信を行う所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析する処理内容解析処理と、（ロ）この処理内容解析処理の解析結果をメールサーバ宛の対応するメール操作要求に変換するメール操作要求変換処理と、（ハ）このメール操作要求変換処理で変換したメール操作要求がメール受信要求であるとき、メール転送プロトコルとしてＰＯＰあるいはＩＭＡＰを使用してメールサーバにメール受信要求を送信するメール受信要求送信処理とを実行することを特徴としている。
【００１８】
すなわち本発明では、ホームゲートウェイのコンピュータが、ハイパーテキスト転送プロトコルを使用して通信を行う所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析し、この解析結果をメールサーバ宛の対応するメール操作要求に変換し、この変換したメール操作要求がメール受信要求であるとき、メール転送プロトコルとしてＰＯＰあるいはＩＭＡＰを使用してメールサーバにメール受信要求を送信する処理を実行するようにしている。これにより、通信端末はＰＯＰあるいはＩＭＡＰを使用するメールサーバを用いてメールの受信に関する処理が可能になる。
【００１９】
請求項９記載の発明では、ホームゲートウェイのコンピュータが、ホームゲートウェイ制御プログラムとして、（イ）ハイパーテキスト転送プロトコルを使用して通信を行う所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析する処理内容解析処理と、（ロ）この処理内容解析処理の解析結果をメールサーバ宛の対応するメール操作要求に変換するメール操作要求変換処理と、（ハ）このメール操作要求変換処理で変換したメール操作要求がメール送信要求であるとき、メール転送プロトコルとしてＳＭＴＰを使用してメールサーバにメール送信要求を送信するメール送信要求送信処理とを実行することを特徴としている。
【００２０】
すなわち本発明では、ホームゲートウェイのコンピュータが、ハイパーテキスト転送プロトコルを使用して通信を行うる携帯電話機等の所定の通信端末からインターネット上のメールサーバにおけるメールの処理の要求があったときその処理の内容を解析し、この解析結果をメールサーバ宛の対応するメール操作要求に変換し、この変換したメール操作要求がメール送信要求であるとき、メール転送プロトコルとしてＳＭＴＰを使用してメールサーバにメール送信要求を送信するようにしている。これにより、通信端末はＳＭＴＰを使用してメールの送信に関する処理が可能になる。
【発明の効果】
【００２１】
以上説明したように、本発明によればホームゲートウェイを介して、携帯電話機等の所定の通信端末がメールサーバと通信が可能なので、インターネット上に特別のプロキシサーバを用意する必要なく、ＨＴＴＰアクセス環境しかないリモートホストであっても、メールの閲覧、送信を実現することができ、また、メールの閲覧や削除等のメールに関する各種の操作を実現することができる。しかも、ホームゲートウェイは家庭ネットワークなので、メールを使用する時間にホームゲートウェイが起動していればよく、プロキシサーバと異なり、メール処理のためにホームゲートウェイ側のコンピュータを常に起動しておく必要がないという利点もある。
【発明を実施するための最良の形態】
【００２２】
以下実施例につき本発明を詳細に説明する。
【実施例１】
【００２３】
図１は、本発明の一実施例におけるホームゲートウェイを使用したメールシステムの概要を表わしたものである。このメールシステム２００で、インターネット２０１にはメールサーバ２０２が接続されている。このメールサーバ２０２を用いてメールの送受信を行うパーソナルコンピュータ等のリモートホスト２０３は、ＬＡＮ２０４を介してホームゲートウェイ２０５に接続されており、ホームゲートウェイ２０５はＷＡＮ２０６を介してインターネット２０１に接続されている。メールサーバ２０２は、ＰＯＰおよびＳＭＴＰの２つのメール転送プロトコルを用いて、メールの送受信サービスを行うようになっている。
【００２４】
図２は、本実施例のホームゲートウェイの構成の概容を表わしたものである。ホームゲートウェイ２０５は、ＬＡＮ２０４およびＷＡＮ２０６と接続されたＮＡＴ（Network Address Translation）処理部２１１を備えている。ＮＡＴ処理部２１１は、ＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）処理を行うＩＰ（Internet Protocol）ホスト部２１２とも接続されており、パケットのアドレス変換を行うようになっている。
【００２５】
ＩＰホスト部２１２は、ＨＴＴＰサーバ部２１３およびメールクライアント部２１４と接続されており、ホームゲートウェイ２０５で動作するアプリケーションとリモートアプリケーションの間の通信を、ＴＣＰ／ＩＰ標準に則り制御するようになっている。ＨＴＴＰサーバ部２１３とメールクライアント部２１４は、メール・ウエブメール変換部２１５とも接続されている。ここで、ＨＴＴＰサーバ部２１３は、ＬＡＮ２０４側に存在するリモートホスト２０３（図１）からの要求に対する処理を行い、また、メール・ウエブメール変換部２１５へメールの受信や送信の要求を行うようになっている。また、ＨＴＴＰサーバ部２１３は、メール・ウエブメール変換部２１５からの応答内容をＩＰホスト部２１２を介して、ＨＴＴＰアクセス環境しかないリモートホスト２０３に送出するようになっている。
【００２６】
メールクライアント部２１４は、メール・ウエブメール変換部２１５からの要求に応じて、メールサーバ２０２（図１）との間でメールの送受信を行う。また、メールサーバ２０２からの応答内容をメール・ウエブメール変換部２１５へ送出するようになっている。
【００２７】
メール・ウエブメール変換部２１５は、ＨＴＴＰサーバ部２１３からの要求の内容を解析して、メールクライアント部２１４にメールの送受信の要求を行う。また、メール・ウエブメール変換部２１５はメールクライアント部２１４からの受信結果を解析して、応答結果としてＨＴＴＰサーバ部２１３に送出するようになっている。
【００２８】
なお、このようなホームゲートウェイ２０５は、図示しないがＣＰＵ（Central Processing Unit）、メモリならびに通信回路等のハードウェアを備えた通常のコンピュータによって構成されている。そして、メモリに格納された制御プログラムをＣＰＵが実行することによって、図２に示した各部の少なくとも一部をソフトウェア的に実現するようになっている。
【００２９】
図１に示したメールシステム２００では、図２に示したホームゲートウェイ２０５を用いて、リモートホスト２０３へウエブメール等のウエブサービスを行いながら、ＰＯＰおよびＳＭＴＰの２つのメール転送プロトコルを用いて、メールサーバ２０２との通信を行うようになっている。これにより、メールサーバ２０２とＰＯＰあるいはＳＭＴＰによる通信を直接行うことのできないリモートホスト２０３からであっても、ホームゲートウェイ２０５を介してＰＯＰあるいはＳＭＴＰによるメールの送受信ができるようになる。
【００３０】
図３は、ホームゲートウェイの要部を具体的に示したものである。図３では、図２に示したホームゲートウェイ２０５のうちのＩＰホスト部２１２、ＨＴＴＰサーバ部２１３、メールクライアント部２１４およびメール・ウエブメール変換部２１５の構成を表わしている。ただし、ＩＰホスト部２１２は本発明独自の回路部分ではないので、その具体的な構成および説明は省略する。
【００３１】
ＨＴＴＰサーバ部２１３は、ＨＴＴＰプロトコル処理部２２１とＣＧＩ（Common Gateway Interface）制御部２２２で構成されている。メール・ウエブメール変換部２１５は、ＩＮＣ（incorporate）処理部２２４とＰＯＳＴ処理部２２５で構成されている。メールクライアント部２１４は、ＰＯＰクライアント部２２７とＳＭＴＰクライアント部２２８から構成されている。
【００３２】
ここでＨＴＴＰサーバ部２１３のＨＴＴＰプロトコル処理部２２１は、図１に示したリモートホスト２０３に代表されるＨＴＴＰクライアントとの通信処理を、ＨＴＴＰ標準に則り制御して、ＣＧＩ制御部２２２に受信データを引き渡し、その実行結果をＨＴＴＰクライアントへ送出するためにＩＰホスト部へ送信するようになっている。ＨＴＴＰプロトコル処理部２２１は、ＵＲＬがスタティックＨＴＭＬファイルで構成される場合は、そのファイルのＨＴＴＰクライアントへ応答するようになっている。
【００３３】
ＣＧＩ制御部２２２は、ＨＴＴＰプロトコル処理部２２１から供給されたデータを解析するようになっている。そして、ＨＴＴＰクライアントからの要求内容をメール・ウエブメール変換部２１５のＩＮＣ処理部２２４およびＰＯＳＴ処理部２２５に引き渡す。また、メール・ウエブメール変換部２１５からの応答を解析して、ＨＴＴＰプロトコル処理部２２１へ引き渡すようになっている。
【００３４】
メール・ウエブメール変換部２１５のＩＮＣ処理部２２４は、ＣＧＩ制御部２２２からの要求内容を解釈して、メールクライアント部２１４のＰＯＰクライアント部２２７に要求内容に応じたメール操作要求を行うようになっている。また、ＩＮＣ処理部２２４は、ＰＯＰクライアント部２２７からのメール操作結果を解析して、ＣＧＩ制御部２２２に応答するようになっている。
【００３５】
ＰＯＳＴ処理部２２５は、ＨＴＴＰサーバ部２１３のＣＧＩ制御部２２２からの要求内容を解釈して、メールクライアント部２１４のＳＭＴＰクライアント部２２８に要求内容に応じたメール送信要求を行うようになっている。また、ＳＭＴＰクライアント部２２８からのメール送信結果を解析して、ＣＧＩ制御部２２２に応答するようになっている。
【００３６】
メールクライアント部２１４内のＰＯＰクライアント部２２７は、メール・ウエブメール変換部２１５のＩＮＣ処理部２２４からの要求内容を受け取り、ＰＯＰプロトコルを使用して、ＩＰホスト部２１２を通じて、図１に示したメールサーバ２０２に対してメールの受信を要求する。また、メールサーバ２０２からの要求内容の実行結果や受信メールを、ＩＮＣ処理部２２４へ引き渡すようになっている。
【００３７】
ＳＭＴＰクライアント部２２８は、メール・ウエブメール変換部２１５のＰＯＳＴ処理部２２５からの送信要求内容を受け取り、ＳＭＴＰプロトコルを使用して、ＩＰホスト部２１２を通じてメールサーバ２０２に対してメールを送信する。また、メールサーバ２０２からの送信結果をＰＯＳＴ処理部２２５へ引き渡すようになっている。
【００３８】
次に、各部の動作を具体的に説明する。ここでは、図１に示したようにホームゲートウェイ２０５がＨＴＴＰクライアントとしてのリモートホスト２０３に接続されており、メールサーバ２０２を用いてメールの送受信を行う場合について説明する。
【００３９】
まず、ＨＴＴＰプロトコル処理部２２１の動作を説明する。図１に示したリモートホスト２０３でＨＴＴＰリクエストが発生すると、ホームゲートウェイ２０５のＮＡＴ処理部２１１がプライベートアドレスをグローバルＩＰアドレスに変換し、受信したパケットをＩＰホスト部２１２を経由してＨＴＴＰプロトコル処理部２２１に送出する。ＨＴＴＰプロトコル処理部２２１は、ＨＴＴＰリクエストのリクエストＵＲＬを解析する。そして、これがスタティックＨＴＭＬへのリクエストであれば、用意されているＨＴＭＬファイルをＨＴＴＰプロトコルを使用してリモートホスト２０３へ応答として送出する。また、これがＣＧＩ処理を行うべきＵＲＬであれば受信したデータをＣＧＩ制御部２２２に供給する。そして、ＣＧＩ制御部２２２から応答が得られたら、その応答内容をリモートホスト２０３へ応答として送出するようになっている。
【００４０】
図４は、ＨＴＴＰプロトコル処理部からコールがあった場合のＣＧＩ制御部の処理の様子を表わしたものである。図３と共に説明する。ＣＧＩ制御部２２２は、ＨＴＴＰプロトコル処理部２２１からコールされデータを供給されると、その受信データがメールリスト表示用ＵＲＬであるかどうかを判別する（ステップＳ３０１）。そうであれば（Ｙ）、リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）の領域（図示せず）にメールリスト表示用であることを示すリスト（ＬＳＴ）をセットして、ＩＮＣ処理部２２４にこれをコールする（ステップＳ３０２）。そして、ＩＮＣ処理部２２４から、これに対する応答を待って、その応答内容をリモートホスト２０３で表示可能なＨＴＭＬに整形する（ステップＳ３０３）。次に、これを図３に示すＨＴＴＰプロトコル処理部２２１に応答として送出することになる（ステップＳ３０４）。前記したようにＨＴＴＰプロトコル処理部２２１はこれをリモートホスト２０３へ送出する。
【００４１】
一方、ＣＧＩ制御部２２２は、ステップＳ３０１でメールリスト表示用ＵＲＬでないと判別した場合には（Ｎ）、その受信データがメール閲覧用ＵＲＬであるかどうかを判別する（ステップＳ３０５）。そうであれば（Ｙ）、リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）の領域にメール閲覧用であることを示すリードデータ（ＲＤ）をセットして、閲覧するメール番号を受信データから解析・取得して、ＩＮＣ処理部２２４にこれをコールする（ステップＳ３０６）。そして、ＩＮＣ処理部２２４から、これに対する応答を待って、その応答内容をリモートホスト２０３で表示可能なＨＴＭＬに整形する（ステップＳ３０７）。次に、これを図３に示すＨＴＴＰプロトコル処理部２２１に応答として送出することになる（ステップＳ３０４）。前記したようにＨＴＴＰプロトコル処理部２２１はこれをリモートホスト２０３へ送出する。
【００４２】
ＣＧＩ制御部２２２は、ステップＳ３０５でメール閲覧ＵＲＬでないと判別した場合には（Ｎ）、その受信データがメール削除用ＵＲＬであるかどうかを判別する（ステップＳ３０８）。そうであれば（Ｙ）、リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）の領域にメール削除用であることを示すデリート（ＤＬＴ）をセットして、削除するメール番号を受信データから解析・取得して、ＩＮＣ処理部２２４にこれをコールする（ステップＳ３０９）。そして、ＩＮＣ処理部２２４から、これに対する応答を待って、その応答内容をリモートホスト２０３の表示可能なＨＴＭＬに整形する（ステップＳ３１０）。次に、これを図３に示すＨＴＴＰプロトコル処理部２２１に応答として送出することになる（ステップＳ３０４）。前記したようにＨＴＴＰプロトコル処理部２２１はこれをリモートホスト２０３へ送出する。
【００４３】
以上と異なり、ＣＧＩ制御部２２２が、ステップＳ３０８でその受信データがメール削除用ＵＲＬでなく、メール送信用ＵＲＬであると判別した場合（Ｎ）、宛先および、送信内容を解析・取得する。そしてこれを図３に示したＰＯＳＴ処理部２２５にコールする（ステップＳ３１１）。そして、ＰＯＳＴ処理部２２５の応答を待って、その応答内容をリモートホスト２０３で表示可能なＨＴＭＬに整形する（ステップＳ３１２）。次に、これを図３に示すＨＴＴＰプロトコル処理部２２１に応答として送出することになる（ステップＳ３０４）。前記したようにＨＴＴＰプロトコル処理部２２１はこれをリモートホスト２０３へ送出する。
【００４４】
図５は、ＣＧＩ制御部からコールがあった場合のＩＮＣ処理部の処理の様子を表わしたものである。図３に示したＩＮＣ処理部２２４は、ＣＧＩ制御部２２２からコールされデータを供給されると、その受信データを読み出して、リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）がリスト（ＬＳＴ）であるかどうかを判別する（ステップＳ３２１）。リスト（ＬＳＴ）である場合には（Ｙ）、図３に示すＰＯＰクライアント部２２７にメールリストを要求して、結果を取得する（ステップＳ３２２）。そして、取得した結果からメール番号の全リストを作成する（ステップＳ３２３）。この後、メール番号リストに残りがある間は（ステップＳ３２４：Ｙ）、ＰＯＰクライアント部２２７に、ＲＥＴＲ（retrieve）命令とともに、リストされたメール番号を順に供給する（ステップＳ３２５）。これにより、ＰＯＰクライアント部２２７はメール内容、削除結果、メールリストを、ＩＮＣ処理部２２４に応答することになる。
【００４５】
一方、リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）がリスト（ＬＳＴ）でない場合には（ステップＳ３２１：Ｎ）、リードデータ（ＲＤ）であるかどうかが判別される（ステップＳ３２６）。リードデータ（ＲＤ）である場合には（ステップＳ３２６：Ｙ）、ＰＯＰクライアント部２２７に対して、メールの読み出しを行うＲＥＴＲ命令とともに、供給されたメール番号を送出する。そして、その結果としての該当するメールを受信することになる（ステップＳ３２７）。
【００４６】
また、ステップＳ３２６でリクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）がリードデータ（ＲＤ）でなく、メール削除（ＤＬＴ）であった場合には（Ｎ）、削除するメール番号を指定して、ＰＯＰクライアント部２２７に削除（ＤＥＬＥ）要求を行って、その結果を取得することになる（ステップＳ３２８）。
【００４７】
図６は、ＣＧＩ制御部からコールがあった場合のＰＯＳＴ処理部の処理の様子を表わしたものである。図３に示したＰＯＳＴ処理部２２５は、この図に示すＣＧＩ制御部２２２からコールされデータを供給されると、そのデータを読み出して、指定された宛先および送信するメール内容を図３に示すＳＭＴＰクライアント部２２８に供給し、メールの送信依頼を行う（ステップＳ３４１）。図１に示すメールサーバ２０２によるメールの送信が行われると、ＰＯＳＴ処理部２２５は、ＳＭＴＰクライアント部２２８から送信結果を受領して（ステップＳ３４２）、ＣＧＩ制御部２２２にその送信結果を返送する（ステップＳ３４３）。
【００４８】
図７は、ＩＮＣ処理部から発行された命令とメール番号を供給された場合のＰＯＰクライアント部の処理の様子を表わしたものである。図３に示したＰＯＰクライアント部２２７は、この図に示すＩＮＣ処理部２２４から発行された命令とメール番号を供給されると、ＩＰホスト部２１２、ＮＡＴ処理部２１１（図２）を経由してメールサーバに接続する（ステップＳ３６１）。そして、供給された命令がＲＥＴＲ命令であれば（ステップＳ３６２：Ｙ）、供給されたメール番号に対してＲＥＴＲ命令を実行する（ステップＳ３６３）。そして、受信したメールを含む実行結果を、ＩＮＣ処理部２２４へ送出する（ステップＳ３６４）。
【００４９】
ステップＳ３６２で、供給された命令がＲＥＴＲ命令ではなく（Ｎ）、削除（ＤＥＬＥ）命令であった場合には（ステップＳ３６５：Ｙ）、供給されたメール番号に対して、削除（ＤＥＬＥ）命令を実行する（ステップＳ３６６）。そして、ステップＳ３６４に進むことになる。ステップＳ３６５で、供給された命令が削除（ＤＥＬＥ）命令ではなく（Ｎ）、リスト（ＬＳＴ）命令であった場合には（ステップＳ３６７：Ｙ）、このリスト（ＬＳＴ）命令を実行する（ステップＳ３６８）。そして、ステップＳ３６４に進むことになる。ステップＳ３６７で、供給された命令がリスト（ＬＳＴ）命令でもなかった場合には（Ｎ）、エラー処理等の他の処理が実行されることになる。なお、ＰＯＰメッセージの具体的な通信方法については、標準化された仕様によるものであり、周知の技術内容であるため、その説明を省略する。
【００５０】
図８は、ＳＭＴＰクライアント部の処理を表わしたものである。図３に示したＳＭＴＰクライアント部２２８は、同図に示すＰＯＳＴ処理部２２５から宛先とメール内容を示すデータを受信すると（ステップＳ３８１：Ｙ）、図３に示すＩＰホスト部２１２、図２に示すＮＡＴ処理部２１１を経由して同じく図２に示すメールサーバに接続する（ステップＳ３８２）。そして、示された宛先にそのメールの内容を送信することになる（ステップＳ３８３）。なお、ＳＭＴＰメッセージの具体的な通信方法については、標準化された仕様によるものであり、周知の技術内容であるため、その説明を省略する。
【００５１】
以上説明したように、本実施例のメールシステム２００では、ホームゲートウェイ２０５がメールクライアント機能を備えているので、これを介することでリモートホスト２０３がＰＯＰおよびＳＭＴＰの２つのメール転送プロトコルを用いるメールサーバ２０２と通信が可能になり、メールの送受信を行うことができる。
【００５２】
また、実施例のホームゲートウェイ２０５はメールクライアント機能の他にＨＴＴＰサーバ機能を具備しているので、リモートホスト２０３のようなＨＴＴＰクライアントからメールの読み書きが可能である。更に、実施例ではホームゲートウェイ２０５がメールクライアント機能を備えているので、複数のメールサーバとの通信が可能であり、これにより複数のメールアカウントのメールの読み書きを統一した操作で行うことができる。
【００５３】
＜発明の変形例＞
図９は、本発明の変形例におけるホームゲートウェイの要部を具体的に示したものである。実施例の図３と同一部分には同一の符号を付しており、これらの説明を適宜省略する。この変形例では、メール・ウエブメール変換部２１５ＡのＩＮＣ処理部２２４Ａが受信データ加工部４０１を備えている。受信データ加工部４０１は、受信したメールデータの加工を行うようになっている。ＩＮＣ処理部２２４Ａとデータの授受を行うＨＴＴＰサーバ部２１３Ａ内のＣＧＩ制御部２２２Ａは、メール閲覧用ＵＲＬの場合、ＨＴＴＰプロトコル処理部２２１から供給されたデータを解析して、閲覧するメール番号の他にメール内容を加工するかどうかのフラグを取得するようになっている。ＣＧＩ制御部２２２Ａは、これらを受信するとメール加工フラグとメール番号情報をＩＮＣ処理部２２４Ａに供給する。そして、ＩＮＣ処理部２２４Ａから応答があると、その応答内容をＨＴＴＰプロトコル処理部２２１に送出するようになっている。
【００５４】
図１０は、この変形例におけるＩＮＣ処理部の動作を表わしたものであり、実施例の図５に対応するものである。図１０で、図５と対応する部分には同一のステップ番号を付しており、これらの説明を適宜省略する。
【００５５】
リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）がリスト（ＬＳＴ）でない場合には（ステップＳ３２１：Ｎ）、リードデータ（ＲＤ）であるかどうかが判別される（ステップＳ３２６）。リクエスト・タイプ（Ｒｅｑ  Ｔｙｐｅ）がリードデータ（ＲＤ）であると判別された場合には（ステップＳ３２６：Ｙ）、ＰＯＰクライアント部２２７に対して、メールの読み出しを行うＲＥＴＲ命令とともに、供給されたメール番号を送出する。そして、その結果としての該当するメールを受信する（ステップＳ３２７）。この状態でＩＮＣ処理部２２４Ａはメール加工フラグが「加工する」ことになっているかどうかを判別し（ステップＳ５０１）、「加工する」ことになっている場合には（Ｙ）、メール取得結果を加工する。そして、たとえばそのメールのサマリ（要約）を作成することになる。ＩＮＣ処理部２２４Ａは、この加工した内容を、メールサーバ２０２から送られてきたメールを加工して得られた受信メールとする（ステップＳ５０２）。そして、この結果を応答することになる（ステップＳ５０３）。
【００５６】
このように、この変形例では受信したメールを加工することができるので、ＨＴＴＰクライアントとしてのリモートホスト２０３に、たとえば受信メールのサマリのみを表示するといった加工処理が可能になる。
【００５７】
なお、実施例および変形例と異なり、ＰＯＰクライアントの代わりに、ＩＭＡＰ（Internet Messages Access Protocol）を使用するＩＭＡＰクライアントがメールの受信機能を実行してもよい。
【００５８】
また、実施例ではＨＴＴＰプロトコル処理部２２１がＨＴＴＰプロトコルを処理することにしたが、この代わりにＨＴＴＰＳ（Secure HTTP）プロトコルを処理するものであってもよい。後者の場合には、認証・暗号機能を用いることにより、ＰＯＰおよびＳＭＴＰよりもセキュアなリモートアクセスを容易に実現することができる。
【００５９】
更に実施例では、メールサーバ２０２がＰＯＰとＳＭＴＰの２種類のプロトコルに対応するものとしたが、ＰＯＰ専用とＳＭＴＰ専用の２種類のメールサーバを有するメールシステムにも本発明を同様に適用することができる。
【図面の簡単な説明】
【００６０】
【図１】本発明の一実施例におけるメールシステムの概要を表わしたシステム構成図である。
【図２】本実施例のホームゲートウェイの構成の概容を表わしたブロック図である。
【図３】本実施例のホームゲートウェイの要部を具体的に示したブロック図である。
【図４】本実施例でＨＴＴＰプロトコル処理部からコールがあった場合のＣＧＩ制御部の処理の様子を表わした流れ図である。
【図５】本実施例でＣＧＩ制御部からコールがあった場合のＩＮＣ処理部の処理の様子を表わした流れ図である。
【図６】本実施例でＣＧＩ制御部からコールがあった場合のＰＯＳＴ処理部の処理の様子を表わした流れ図である。
【図７】本実施例でＩＮＣ処理部から発行された命令とメール番号を供給された場合のＰＯＰクライアント部の処理の様子を表わした流れ図である。
【図８】本実施例でＳＭＴＰクライアント部の処理を表わした流れ図である。
【図９】本発明の変形例におけるホームゲートウェイの要部を具体的に示したブロック図である。
【図１０】変形例におけるＩＮＣ処理部の動作を表わした流れ図である。
【図１１】ホームゲートウェイを使用した従来のメールシステムを表わしたシステム構成図である。
【図１２】プロキシサーバを用いた従来提案されたメールシステムを表わしたシステム構成図である。
【図１３】従来提案されたメールシステムでのプロキシサービス部の処理の内容を表わした流れ図である。
【符号の説明】
【００６１】
２００  メールシステム
２０１  インターネット
２０２  メールサーバ
２０３  リモートホスト
２０５  ホームゲートウェイ
２１２  ＩＰホスト部
２１３、２１３Ａ  ＨＴＴＰサーバ部
２１４  メールクライアント部
２１５、２１５Ａ  メール・ウエブメール変換部
２２１  ＨＴＴＰプロトコル処理部
２２２、２２２Ａ  ＣＧＩ制御部
２２４、２２４Ａ  ＩＮＣ処理部
２２５  ＰＯＳＴ処理部
２２７  ＰＯＰクライアント部
２２８  ＳＭＴＰクライアント部
【図１】
2008078774.tif 000003
【図２】
2008078774.tif 000004
【図３】
2008078774.tif 000005
【図４】
2008078774.tif 000006
【図５】
2008078774.tif 000007
【図６】
2008078774.tif 000008
【図７】
2008078774.tif 000009
【図８】
2008078774.tif 000010
【図９】
2008078774.tif 000011
【図１０】
2008078774.tif 000012
【図１１】
2008078774.tif 000013
【図１２】
2008078774.tif 000014
【図１３】
2008078774.tif 000015