JP2008276461A - メッセージ送受信システム、サーバ装置、サーバ処理プログラム、及び情報提供方法 - Google Patents

Abstract

【課題】相手のユーザがインスタントメッセージの交換が困難な状態であって、また相手の電子メールアドレスを知らなくても、相手が移動通信端末を用いて対話できるようにする。
【解決手段】メッセンジャー機能を有する複数の端末装置と、前記端末装置におけるユーザの現在の状態情報をユーザ毎に管理し、ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を他のユーザの端末装置に送信し、また、電子メールアドレスをユーザ毎に判別可能に記憶するサーバ装置とからなるメッセージ送受信システムである。前記端末装置は、前記サーバ装置から送信されてきた状態情報を受信し、電子メールの受付対象となっている他の前記端末装置のユーザに対して、メッセージを送信すると、サーバ装置は、端末装置から送信されてきたメッセージに基づき電子メールを生成し、当該他の端末装置のユーザの電子メールアドレス宛てに送信する。
【選択図】図１０

Description

本発明は、ネットワークを通じて端末装置間で、メッセージの送受信を行うことが可能なメッセージ送受信システム等の技術分野に関する。

従来から、インターネットやイントラネット等のネットワークを通じてパーソナルコンピュータ等の端末装置間で、テキストメッセージ（一般にインスタントメッセージと呼ばれる）の交換ができるインスタントメッセンジャー（ＩＭクライアントとも呼ばれ、端末装置にインストールされるコミュニケーション用アプリケーションソフト）が普及している（例えば、特許文献１参照）。

このようなインスタントメッセンジャーにおいては、インスタントメッセージの交換相手となるユーザ（後述する友録メンバー）の現在の状態（例えば、オンラインやオフライン）を示すプレゼンス情報を端末装置上に表示させることができるようになっている。
特開２００３−４４４１８号公報

ところで、従来のインスタントメッセンジャーにおいては、ユーザは、相手のユーザが端末装置から離れ（例えば、食事中、或いは帰宅中）、例えばオフラインの状態にある場合、インスタントメッセージの交換を行うことができないという不都合があった。かかる場合に、ユーザは、相手のユーザが所持している携帯電話機等の移動通信端末に対して電話をかけるか、或いは当該移動通信端末に対して電子メールを送信する方法が考えられるが、相手のユーザの移動通信端末の電話番号や電子メールアドレスを知らない場合には、当該相手のユーザと対話（例えば、音声又は文字等で）することができない。

本発明は、このような点に鑑みてなされたものであり、その課題の一例は、相手のユーザがインスタントメッセージの交換を行うことが困難な状態にあって、相手のユーザの電子メールアドレスを知らない場合であっても、相手のユーザが移動通信端末を用いて対話することが可能なメッセージ送受信システム、サーバ装置、サーバ処理プログラム、及び情報提供方法を提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置と、夫々の前記端末装置におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信する状態情報送信手段と、電子メールアドレスを前記ユーザ毎に判別可能に記憶する記憶手段と、を有するサーバ装置と、を備えるメッセージ送受信システムであって、前記端末装置は、前記サーバ装置から送信されてきた前記状態情報を受信する状態情報受信手段と、前記状態情報が電子メールの受付対象とする特定の状態を示す他の前記端末装置のユーザに対してメッセージを送信する場合には、当該メッセージを前記第２のサーバ装置に送信するメッセージ送信手段と、を備え、前記サーバ装置は、前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信する電子メール送信手段を備えることを特徴とする。

この発明によれば、サーバ装置は、電子メールアドレスをユーザ毎に判別可能に記憶しておき、端末装置から送信されてきたメッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、他の端末装置のユーザの電子メールアドレス宛てに送信するように構成したので、端末装置のユーザは、相手のユーザ（他の端末装置のユーザ）が、例えばメッセージの交換を行うことが困難な状態にあって、相手のユーザの電子メールアドレスを知らない場合であっても、電子メールを利用したメッセージの交換により対話を行うことができる。

請求項２に記載の発明は、ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置夫々におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信する状態情報送信手段を備えたサーバ装置において、電子メールアドレスを前記ユーザ毎に判別可能に記憶する記憶手段と、前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信する電子メール送信手段と、を備えることを特徴とする。

請求項３に記載の発明は、請求項２に記載のサーバ装置において、当該サーバ装置は、第１のサーバ装置と第２のサーバ装置とにより構成され、当該第１のサーバ装置と当該第２のサーバ装置とはネットワークを介して接続されており、前記第１のサーバ装置は、前記状態情報送信手段を備え、前記第２のサーバ装置は、前記記憶手段と、前記電子メール送信手段を備えることを特徴とする。

請求項４に記載の発明は、請求項３に記載のサーバ装置において、前記第２のサーバ装置は、前記他の端末装置のユーザが有する機器から前記電子メールに対して返信された電子メールを受信した場合には、当該電子メールを保存すると共に、当該電子メールを受信したことを示す電子メール受信情報を前記第１のサーバ装置に送信し、前記第１のサーバ装置は、前記第２のサーバ装置からの前記電子メール受信情報を受信した場合には、当該電子メール受信情報を前記メッセージ送信元の端末装置に対して送信し、前記端末装置は、前記第１のサーバ装置からの前記電子メール受信情報を受信した場合には、前記第２のサーバ装置に対してメッセージの要求を示す情報を送信し、前記第２のサーバ装置は、前記端末装置からの前記メッセージの要求を示す情報を受信した場合には、前記保存した電子メールに基づきメッセージを生成し、当該メッセージを端末装置に送信することを特徴とする。

この発明によれば、端末装置は、上記携帯メールで返信されたメッセージを迅速に第２のサーバ装置から取得することができる。

請求項５に記載の発明は、請求項２乃至４の何れか一項に記載のサーバ装置として機能させることを特徴とする。

請求項６に記載の発明は、ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置夫々におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信するサーバ装置における情報提供方法であって、電子メールアドレスを前記ユーザ毎に判別可能に記憶し、前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信することを特徴とする。

本発明によれば、サーバ装置は、電子メールアドレスをユーザ毎に判別可能に記憶しておき、端末装置から送信されてきたメッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、他の端末装置のユーザの電子メールアドレス宛てに送信するように構成したので、端末装置のユーザは、相手のユーザ（他の端末装置のユーザ）が、例えばメッセージの交換を行うことが困難な状態にあって、相手のユーザの電子メールアドレスを知らない場合であっても、電子メールを利用したメッセージの交換により対話を行うことができる。

以下、図面を参照して本発明の最良の実施形態について詳細に説明する。なお、以下に説明する実施の形態は、メッセージ送受信システムに対して本発明を適用した場合の実施形態である。

［１．メッセージ送受信システムの構成及び機能］
先ず、本実施形態に係るメッセージ送受信システムＳの構成及び機能について、図１等を用いて説明する。

図１は、本実施形態に係るメッセージ送受信システムＳの概要構成例を示す図である。

図１に示すように、メッセージ送受信システムＳは、ＩＭ（インスタントメッセンジャー）サービス提供サーバＳＡ、連携サーバＲＳ、ユーザ端末（端末装置の一例）ＵＴｍ（ｍ＝１，２・・・ｋ）、移動通信端末ＭＴｍ（ｍ＝１，２・・・ｋ）、ゲートウェイサーバＧＳ、及びメールサーバＭＳ等を備えて構成されている。

なお、ＩＭサービス提供サーバＳＡ及び連係サーバＲＳは、本発明のサーバ装置を構成する。

ＩＭサービス提供サーバＳＡは、ネットワークＮＷを通じてユーザ端末ＵＴｍ間で行われるインスタントメッセージ（以下、単に、「メッセージ」という）の送受信（交換）をサポートするサーバであり、インターネットやイントラネット等のネットワークＮＷ（通信回線及びルーター等の中継機器等により構成される）に接続され、固有のＩＰ（Internet Protocol）アドレス（グローバルＩＰアドレス）が割り当てられている。なお、上記メッセージの送受信は、公知のＳＩＰ（Session Initiation Protocol）やJabberプロトコルに基づく。

また、図１に示す例では、一つのＩＭサービス提供サーバＳＡを示しているが、当該ＩＭサービス提供サーバＳＡは、複数のサーバ群（例えば、アプリケーションサーバ、プロキシサーバ、リダイレクトサーバ、レジストラ、及びロケーションサーバ等）から構成されるものであっても良い。

なお、ＩＭサービス提供サーバＳＡとユーザ端末ＵＴｍ間のデータの送受信はＳＩＰやJabberプロトコルに基づいて行われる。

連携サーバＲＳは、ユーザ端末ＵＴｍと移動通信端末ＭＴｍとの間で行われるメッセージの送受信をサポートするサーバであり、ネットワークＮＷに接続され、固有のＩＰアドレスが割り当てられている。

なお、連携サーバＲＳ（Ｗｅｂサーバ）とユーザ端末ＵＴｍ間のデータの送受信はＨＴＴＰＳ（Hypertext Transfer Protocol Security）に基づいて行われる。

ユーザ端末ＵＴｍは、例えばインターネットサービスプロバイダのサーバを通じてネットワークＮＷに接続可能になっており、当該ネットワークＮＷに接続する際、固有のＩＰ（Internet Protocol）アドレス（例えばグローバルＩＰアドレス）が割り当てられるようになっている。そして、ユーザ端末ＵＴｍは、ネットワークＮＷを通じてサービス提供サーバＳＡ及び連携サーバＲＳに接続し通信を行うことが可能になっている。

また、ユーザ端末ＵＴｍは、例えば各ユーザの自宅や職場に設置され、メッセンジャー機能及びブラウザ機能を有する（このメッセンジャー機能及びブラウザ機能に係るアプリケーションソフトは、各ユーザ端末ＵＴｍにインストールされている）。

なお、本明細書において、メッセンジャー機能とは、メッセージの交換相手のユーザの現在の状態を示すプレゼンス情報を表示でき、なおかつ該メッセージの交換相手のユーザのユーザ端末ＵＴｍとの間でネットワークＮＷを通じて上記メッセージ（インスタントメッセージ）の送受信を行うことができる機能をいう。

移動通信端末ＭＴｍは、例えば携帯電話機やＰＨＳ（Personal Handyphone System）等の移動体（移動局）であり、基地局ＢＴｎ（ｎ＝１，２・・・ｊ）及びパケット通信サービスを提供するための移動体通信網ＭＷ等を通じて他の移動通信端末ＭＴｍや図示しない固定電話機との間で音声通話を行うことが可能になっている。なお、基地局ＢＴｎは、パケット通信サービスエリア内に所定の間隔で多数設置され、各々の無線セルに在圏する移動通信端末ＭＴｍと無線通信を行う。

また、移動通信端末ＭＴｍは、メールサーバＭＳ等を介して他の移動通信端末ＭＴｍ等との間で電子メール（以下、「携帯メール」という）の送受信を行うためのメールクライアントの機能を有する。なお、各移動通信端末ＭＴｍは、ユーザ端末ＵＴｍの各ユーザにより携帯所持される。また、各ユーザは、移動通信端末ＭＴｍに係る電子メールアドレス（以下、「携帯メールアドレス」という）を有している。

ゲートウェイサーバＧＳは、移動体通信網ＭＷとネットワークＮＷとを相互接続する移動パケット関門中継交換局に設けられたサーバであり、通信プロトコルを変換して移動体通信網ＭＷとネットワークＮＷとの間における通信を中継（本実施形態においては、携帯メールを中継）するようになっている。

メールサーバＭＳは、移動通信端末ＭＴｍのユーザの携帯メールアドレス宛てに送信される携帯メールを格納するメールボックスとしての記憶部（例えばハードディスク）を備えており、携帯メールの授受を中継するサーバである。より具体的には、メールサーバＭＳは、ユーザの携帯メールアドレス宛ての携帯メールを受信すると、当該携帯メールを、メールボックスにおける当該ユーザに対して割り当てられたメモリに一旦格納し、当該ユーザの移動通信端末ＭＴｍからの取得要求に応じて当該携帯メールを移動体通信網ＭＷを通じて移動通信端末ＭＴｍに送信するようになっている。

以上のように構成されたメッセージ送受信システムＳにおいて、連携サーバＲＳは、例えばユーザ端末ＵＴ２から送信されてきたユーザ端末ＵＴ１のユーザに対するメッセージ（ＨＴＴＰＳに基づくメッセージ（以下、「ＨＴＴＰＳメッセージ」という）を受信すると、当該メッセージに基づき携帯メール（ＳＭＴＰ（Simple Mail Transfer Protocol）に基づく携帯メール）を生成して、当該携帯メールを当該ユーザ端末ＵＴ１のユーザの携帯メールアドレス宛てに送信、つまり、当該携帯メールをネットワークＮＷ及びゲートウェイサーバＧＳを介してメールサーバＭＳに送信するようになっている。

そして、ゲートウェイサーバＧＳは、連携サーバＲＳからの上記携帯メールを受信すると、当該携帯メールの通信プロトコルを変換（例えば、ＳＭＴＰから、移動体通信網ＭＷの通信プロトコル（例えば、ＴＣＰ／ＩＰを当該移動体通信網ＭＷに合わせたプロトコル等）に変換）し、メールサーバＭＳに送信する。

こうして、メールサーバＭＳに送信されメールボックスに格納された携帯メールは、ユーザ端末ＵＴ１のユーザが所持する移動通信端末ＭＴ１により取得され、当該ユーザは移動通信端末ＭＴ１により例えばユーザ端末ＵＴ２からのメッセージの内容を携帯メールで確認することができる。

［１−１．ＩＭサービス提供サーバＳＡの構成及び機能等］
次に、ＩＭサービス提供サーバＳＡの構成及び機能の詳細について、図２等を用いて説明する。

図２は、ＩＭサービス提供サーバＳＡの概要構成の一例を示すブロック図である。

図２に示すように、ＩＭサービス提供サーバＳＡは、操作部１、表示部２、通信部３、ドライブ部４、記憶手段としての記憶部５、入出力インタフェース部６、及びシステム制御部７等を備えており、システム制御部７と入出力インタフェース部６とは、システムバス８を介して接続されている。

操作部１は、例えば、キーボード及びマウス等からなり、管理者等からの操作指示を受け付け、その指示内容を指示信号としてシステム制御部７に出力する。

表示部２は、例えば、ＣＲＴ（Cathode Ray Tube）ディスプレイ、液晶ディスプレイ等からなり、文字や画像等の情報を表示する。

通信部３は、ネットワークＮＷに接続してユーザ端末ＵＴｍ及びゲートウェイサーバＧＳ等との通信状態を制御する。

ドライブ部４は、例えば、フレキシブルディスク、ＣＤ（Compact Disc）、ＤＶＤ（Digital Versatile Disc）等のディスクＤＫ（記録媒体）からデータ等を読み出す一方、当該ディスクＤＫに対してデータ等を記録する。

入出力インタフェース部６は、操作部１乃至記憶部５とシステム制御部７との間のインタフェース処理を行う。

記憶部５は、例えば、ハードディスクドライブ等からなり、オペレーティングシステム（Ｏ／Ｓ），各種プログラム（本発明のサーバ処理プログラムを含む）及びデータ（ユーザ端末ＵＴｍに提供するデータを含む）等を記憶する。なお、本発明のサーバ処理プログラム等は、例えば、他のサーバ等からネットワークＮＷを介してダウンロードされるようにしても良いし、ＣＤ−ＲＯＭ等のディスクＤＫに記録されてドライブ部４を介して読み込まれるようにしても良い。

また、記憶部５には、ユーザ端末ＵＴｍのユーザに関する情報を登録するためのユーザ情報データベース５１が構築されている。

図３は、ユーザ情報データベース５１における登録情報例を示す図である。

ユーザ情報データベース５１には、図３に示すように、アドレス情報、ユーザＩＤ、携帯メールアドレス、パスワード、ニックネーム（スクリーンネームともいう、以下、「ＮＮ」と称する）、友だち登録しているメンバー（以下、「友録メンバー」という）のＮＮ、夫々の友録メンバーに対して提示されるユーザの現在の状態を示すプレゼンス情報（状態情報）、携帯メールの受付設定を示す携帯メール受付設定情報、携帯メールの受付対象とする特定の状態を示す特定状態情報、及び携帯メールの受付可能時間を示す受付可能時間情報等が互いに対応付けられて登録されている。

ここで、ユーザ情報データベース５１における各登録情報について説明する。

ユーザＩＤ、パスワード、携帯メールアドレス、及びＮＮは、例えば各ユーザがユーザ端末ＵＴｍを操作してＩＭサービス提供サーバＳＡに接続し、当該システムＳを利用するための手続処理を経て登録される。また、ユーザＩＤ及びＮＮは、当該システムＳにおいてユーザ毎に一意に与えられるものであり、他のユーザと重複しないように登録される。

また、アドレス情報には、例えば、ネットワークＮＷへのユーザ端末ＵＴｍの接続時に割り当てられたＩＰアドレス（現在のＩＰアドレス）が含まれている。例えば、メッセンジャーが起動したユーザ端末ＵＴｍからのログイン（サインイン）要求（ユーザＩＤ及びパスワードを含む）に応じて認証処理が実行され、ログインが許可された場合（つまり、ユーザＩＤ及びパスワードがユーザ情報データベース５１に登録されている場合）、当該ユーザ端末のアドレス情報がユーザ情報データベース５１に登録される。

また、友録メンバーは、メッセージを交換する相手として互いに許可しあったユーザであり、例えば他のユーザ端末ＵＴｍからの友だち登録要求に応じて友録メンバーとなるユーザのＮＮ（当該ユーザのユーザＩＤであっても良い）がユーザ情報データベース５１に登録される。友録メンバーとして許可しあったユーザ同士の間では、お互いのプレゼンス情報を公開するようにすることができる。

また、各プレゼンス情報は、友録メンバー毎に登録（例えば、ユーザのログインの際、若しくはユーザの状態の変更があった際に登録）されるようになっており、図３の例では、ＮＮ「ａａａａａ」であるユーザのプレゼンス情報に示される状態は、当該ユーザの全ての友録メンバー（つまり、ＮＮ「ｂｂｂｂｂ」、ＮＮ「ｃｃｃｃｃ」、ＮＮ「ｄｄｄｄｄ」、ＮＮ「ｅｅｅｅｅ」、及びＮＮ「ｇｇｇｇｇ」の夫々のユーザ）に対して「オフライン」となっている（これにより、全ての友録メンバーに対して「オフライン」の状態が提示（通知）されることになる）。

なお、当該プレゼンス情報を、友録メンバー毎に異なるように個別設定することも可能である（例えば、ＮＮ「ｇｇｇｇｇ」であるユーザに対してのみ常に「オフライン」とする設定等）。また、例えば、ＮＮ「ａａａａａ」であるユーザがログインした場合には、当該ユーザのプレゼンス情報として、例えば「オンライン」を示すプレゼンス情報がユーザ情報データベース５１に登録（変更登録）されることになる。

また、携帯メール受付設定情報は、友録メンバーのユーザ端末ＵＴｍからのメッセージを携帯メールで受け付けるか否かの設定を示す情報である。また、携帯メールの受付対象とする特定の状態には、ユーザがメッセージの入力指示を行うことが困難又は不可能な状態が該当し、例えば、「オフライン」、「取り込み中」、「退席中」、「チャット困難」、及び「席を外しています」等の状態が一例として挙げられる。かかる複数種類の状態の中からどれを特定の状態とするかはユーザにより任意に指定可能となっている。

携帯メールの受付設定が「ＯＮ」の場合、当該ユーザの現在の状態が、特定状態情報（図３）に示される状態のときに、友録メンバーのユーザ端末ＵＴｍからのメッセージを携帯メールで受付可能となる。この場合、上述したように、ユーザ端末ＵＴｍからのメッセージが携帯メールに変換され、当該携帯メールが当該ユーザの携帯メールアドレス宛てに送信されることになる。また、受付可能時間情報は、携帯メールの受付設定が「ＯＮ」の場合において、当該ユーザの状態が特定状態情報に示される状態のときに、上記メッセージを携帯メールで受け付け可能とする時間（時間制限）を示している。

図３の例では、ＮＮ「ａａａａａ」であるユーザの携帯メールの受付設定は、「ＯＮ」として登録されており、携帯メールの受付対象とする特定の状態は、「退席中」及び「オフライン」として登録されており、更に、携帯メールの受付可能時間は、「2007年2月1日10時まで」として登録されているので、当該ＮＮ「ａａａａａ」であるユーザは、自己の現在の状態が「退席中」又は「オフライン」である場合、「2007年2月1日10時」に達するまでは友録メンバーのユーザ端末ＵＴｍからのメッセージを携帯メールで受け付け（つまり、メールサーバＭＳ等を介して当該携帯メールを移動通信端末ＭＴ１により受信）可能であることを示し、この時間経過後はメッセージを携帯メールで受け付けないことを示している。

また、図３の例において、携帯メールの受付設定が「ＯＮ」として登録された、ＮＮ「ｂｂｂｂｂ」であるユーザは、携帯メールの受付可能時間として登録された「状態変更（オフラインへの状態変更）から３時間以内」（オフラインになった時、当該時から３時間経過時の日時が登録される）は上記メッセージを携帯メールで受け付け可能であることを示している。

また、図３の例において、携帯メールの受付設定が「ＯＮ」として登録された、ＮＮ「ｄｄｄｄｄ」であるユーザの携帯メールの受付可能時間は、「制限無し」として登録されているので、当該ユーザは、自己の状態が「退席中」になった場合、制限無くいつでも上記メッセージを携帯メールで受け付け可能であることを示している。

更に、図３の例において、ＮＮ「ｃｃｃｃｃ」であるユーザの携帯メールの受付設定は、「ＯＦＦ」として登録されているので、上記メッセージを携帯メールで受け付け可能でないことを示しているが、特定状態情報及び受付可能時間情報は登録されており、この後、携帯メールの受付設定が「ＯＮ」として登録された場合、当該ユーザは、自己の現在の状態が「オフライン」となれば、制限無くいつでも上記メッセージを携帯メールで受け付け可能となる。

なお、携帯メールの受付設定、携帯メールの受付対象とする特定の状態、及び携帯メールの受付可能時間は、例えば各ユーザ端末ＵＴｍにおいてユーザにより指定可能になっており、当該指定された携帯メールの受付設定を示す携帯メール受付設定情報、携帯メールの受付対象とする特定の状態を示す特定状態情報、及び携帯メールの受付可能時間を示す受付可能時間情報は、当該ユーザ端末ＵＴｍから送信され、システム制御部７によりユーザ情報データベース５１に登録（記憶）されることになる。

次に、システム制御部７は、ＣＰＵ（Central Processing Unit）７ａ，ＲＯＭ（Read Only Memory）７ｂ，及びＲＡＭ（Random Access Memory）７ｃ等を備えＩＭサービス提供サーバＳＡ全体を統括制御するようになっている。そして、システム制御部７は、ＣＰＵ７ａが、ＲＯＭ７ｂや記憶部５に記憶された各種プログラムを読み出し実行することにより、ユーザ端末ＵＴｍからのログイン要求に応じて認証処理等を実行すると共に、本発明における状態情報送信手段等として機能し、後述する処理を行うようになっている。

また、システム制御部７は、ユーザ端末ＵＴｍからのメッセンジャー機能に係るログイン要求に応じて当該ログインを許可した際に、当該ユーザ端末ＵＴｍのユーザの友録メンバーのプレゼンス情報（ユーザ情報データベース５１に登録されているプレゼンス情報であり、例えば、当該メンバーがログインしているのであれば「オンライン」、当該メンバーがログインしていないのであれば「オフライン」を示す情報）を（当該友録メンバーのＮＮ等と共に）、通信部３及びネットワークＮＷ等を介して当該ユーザ端末ＵＴｍに送信（ＰＵＳＨ型配信）する。また、このとき、システム制御部７は、当該ログインしたユーザのプレゼンス情報（例えば、「オンライン」を示す情報）を、当該ユーザの全ての友録メンバーのＮＮに対応付けてユーザ情報データベース５１に登録すると共に、当該ユーザの友録メンバーのうちログインしている友録メンバーのユーザ端末ＵＴｍに対して送信（通知）する（当該ユーザの友録メンバーのうちログインしていない友録メンバーのユーザ端末ＵＴｍに対しては、当該友録メンバーがログインしたときに送信する）ようになっている（当該ユーザ端末ＵＴｍが定期的にＩＭサービス提供サーバＳＡから上記ログインしたユーザのプレゼンス情報を取得するものであっても良い）。

これにより、友録メンバーのプレゼンス情報が当該ユーザに対して、後述するメッセンジャー機能に係るメイン画面上で提示される。

また、システム制御部７は、ユーザ情報データベース５１を用いて夫々のユーザのプレゼンス情報を管理しており、何れかのユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示すプレゼンス情報を、ユーザ情報データベース５１に変更登録すると共に、当該ユーザの友録メンバーのうちログインしている友録メンバーのユーザ端末ＵＴｍに対して、通信部３及びネットワークＮＷ等を介して送信（ＰＵＳＨ型配信）する（当該ユーザの友録メンバーのうちログインしていない友録メンバーのユーザ端末ＵＴｍに対しては、当該友録メンバーがログインしたときに送信する）ようになっている。

ここで、ユーザの現在の状態の変更は、ログイン要求、ログアウト要求、又は状態変更要求が、ユーザ端末ＵＴｍからＩＭサービス提供サーバＳＡになされた場合に検知される。例えば、ログイン要求がなされた場合、「オフライン」から「オンライン」への状態の変更が検知され、ログアウト要求がなされた場合、「オンライン」（又は「退席中」）から「オフライン」への状態の変更が検知される。また、ユーザが一定時間（例えば、３分間）ユーザ端末ＵＴｍの操作部を操作しなかった場合、或いは、ユーザがユーザ端末ＵＴｍの操作部を操作して自己のプレゼンス情報を「退席中」等に設定変更した場合、「退席中」への状態変更要求がユーザ端末ＵＴｍからＩＭサービス提供サーバＳＡになされ、これにより、「退席中」等への状態の変更が検知される。

更に、システム制御部７は、何れかのユーザの現在の状態の変更を検知したとき、当該ユーザの携帯メールの受付設定が「ＯＮ」であり、当該変更後の状態が当該ユーザに対応する上記特定状態情報に示される特定の状態（例えば、オフライン）である場合には、当該ユーザの変更後の状態を示すプレゼンス情報と共に、当該ユーザが携帯メールでメッセージを受付可能であることを示すメール受付可能情報を（また、例えば、当該ユーザの携帯メールの受付可能時間が「制限無し」でない場合、その受付可能時間を示す受付可能時間情報も一緒に）、当該ユーザの友録メンバーのうちログインしている友録メンバーのユーザ端末ＵＴｍに対して、通信部３及びネットワークＮＷ等を介して送信（ＰＵＳＨ型配信）する（当該ユーザの友録メンバーのうちログインしていない友録メンバーのユーザ端末ＵＴｍに対しては、当該友録メンバーがログインしたときに送信する）ようになっている。

なお、当該ユーザの携帯メールの受付可能時間が「制限無し」でなく、当該受付可能時間に基づく受付終了時間（例えば、１０時）に達した場合、システム制御部７は、当該ユーザの携帯メールの受付設定を「ＯＦＦ」としてユーザ情報データベース５１に登録すると共に、当該メール受付解除を示すメール受付解除情報を、当該ユーザの友録メンバーのうちログインしている友録メンバーのユーザ端末ＵＴｍに対して、通信部３及びネットワークＮＷ等を介して送信（ＰＵＳＨ型配信）することになる。

［１−２．連携サーバＲＳの構成及び機能等］
次に、連携サーバＲＳの構成及び機能の詳細について説明する。

図４は、連携サーバＲＳの概要構成の一例を示すブロック図である。

図４に示すように、連携サーバＲＳは、操作部２１、表示部２２、通信部２３、ドライブ部２４、記憶部２５、入出力インタフェース部２６、及びシステム制御部２７等を備えており、Ｗｅｂサーバ（ＨＴＴＰサーバ）の機能と、メールサーバの機能を有している。なお、操作部２１、表示部２２、通信部２３、ドライブ部２４、記憶部２５、及び入出力インタフェース部２６の構成は、上述したＩＭサービス提供サーバＳＡにおける操作部１、表示部２２、通信部２３、ドライブ部２４、記憶部２５、及び入出力インタフェース部２６の構成と同様である。

記憶部２５には、ユーザ端末ＵＴｍのユーザに関する情報を登録するためのユーザ情報データベースが構築されており、これには、少なくとも、上述したアドレス情報、ユーザＩＤ、携帯メールアドレス、パスワード、及びニックネーム等が互いに対応付けられて登録されている。

なお、上記ユーザ情報データベース５１を、ＩＭサービス提供サーバＳＡと連携サーバＲＳとで共用できるように、データベースサーバに備えさせるように構成しても良い。この場合、連携サーバＲＳは、データベースサーバを介してユーザ情報データベース５１に登録された情報を取得することになる。

そして、システム制御部２７は、ＣＰＵ２７ａが、ＲＯＭ２７ｃや記憶部２５に記憶された各種プログラム（本発明のサーバ処理プログラムを含む）を読み出し実行することにより、本発明における電子メール送信手段等として機能し、ユーザ端末ＵＴｍと移動通信端末ＭＴｍとの間で行われるメッセージの交換をサポートする処理を行うようになっている。なお、本発明のサーバ処理プログラム等は、例えば、他のサーバ等からネットワークＮＷを介してダウンロードされるようにしても良いし、ＣＤ−ＲＯＭ等のディスクＤＫに記録されてドライブ部２４を介して読み込まれるようにしても良い。

具体的には、システム制御部２７は、例えばユーザ端末ＵＴ２から送信されてきたユーザ端末ＵＴ１のユーザに対するＨＴＴＰＳメッセージを受信すると、当該ＨＴＴＰＳメッセージに基づき携帯メールを生成（例えば、当該メッセージの内容をボディに記述し、ユーザ端末ＵＴ１のユーザの携帯メールアドレス（ユーザ情報データベースから取得）を宛先としてヘッダに記述して携帯メールを生成）する（ＨＴＴＰＳメッセージから携帯メールへの変換）。そして、システム制御部２７は、生成した携帯メールを、その携帯メールアドレス宛てに送信する。こうして送信された携帯メールは、ネットワークＮＷ及びゲートウェイサーバＧＳを介してメールサーバＭＳにて受信、保存され、移動通信端末ＭＴ１により取得されることになる。

一方、移動通信端末ＭＴ１から返信された携帯メールは、メールサーバＭＳ及びゲートウェイサーバＧＳを介して連携サーバＲＳに送られ保存されるようになっており、システム制御部２７は、例えばユーザ端末ＵＴ２からの、後述するチャットウインドウ更新要求に応じて、保存された携帯メールに基づきＨＴＴＰＳメッセージを生成（例えば、当該携帯メールのボディに記述されたメッセージ本文をＨＴＴＰＳメッセージ中に記述して生成）し、生成したＨＴＴＰＳメッセージをユーザ端末ＵＴ２に送信するようになっている。

ここで、移動通信端末ＭＴ１から携帯メールが返信された際、システム制御部２７は、当該携帯メールの返信先のユーザを特定するための情報（例えば、ＮＮやユーザＩＤ）を含む携帯メール受信通知をＩＭサービス提供サーバＳＡに送ると良い。当該携帯メール受信通知を受けたＩＭサービス提供サーバＳＡは、ユーザ端末ＵＴ２に対して携帯メール受信通知を行うことになる。これにより、当該ユーザ端末ＵＴ２は、連携サーバＲＳからＨＴＴＰＳメッセージを取得することができる。

［１−３．ユーザ端末ＵＴｍの構成及び機能等］
次に、ユーザ端末ＵＴｍの構成及び機能の詳細について、図５等を用いて説明する。

図５は、ユーザ端末ＵＴｍの概要構成の一例を示すブロック図である。

図５に示すように、ユーザ端末ＵＴｍは、操作部１１、表示部１２、通信部１３、ドライブ部１４、記憶部１５、入出力インタフェース部１６、システム制御部１７、及びマイク付きヘッドホン１８等を備えており、システム制御部１７と入出力インタフェース部１６とは、システムバス１９を介して接続されている。なお、操作部１１、表示部１２、通信部１３、ドライブ部１４、記憶部１５、及び入出力インタフェース部１６の構成は、上述したＩＭサービス提供サーバＳＡにおける操作部１、表示部２、通信部３、ドライブ部４、記憶部５、及び入出力インタフェース部６の構成と同様である。

システム制御部１７は、ＣＰＵ１７ａが、ＲＯＭ１７ｃや記憶部１５に記憶された各種プログラム（本発明の端末処理プログラムを含む）を読み出し実行することにより、メッセンジャー機能を起動させ、本発明における状態情報受信手段及び状態情報表示手段等として機能するようになっている。

図６は、ユーザ端末ＵＴ２のメッセンジャー機能により表示された、表示部１２における表示画面例を示す図である。

例えばユーザ端末ＵＴ２（その他のユーザ端末ＵＴｍでも同様）においてメッセンジャーが起動しログインした後、メッセンジャーが起動していることを示す例えばアイコンが表示部１２上におけるツールバー１０１に表示（図示せず）されると共に、図６（Ａ）に示すようなメイン画面１００が表示部１２上に表示され（開き）、更に、ＩＭサービス提供サーバＳＡから送信された友録メンバーのプレゼンス情報（或いは、プレゼンス情報と共にメール受付可能情報及び受付可能時間情報）及び友録メンバーのＮＮ等が通信部１３を介して受信される。

そして、図６（Ａ）に示すようにメイン画面１００における例えば状態表示部１００ａには、夫々の友録メンバーの状態を示すプレゼンス情報（図６（Ａ）の例では、マーク１００ａａと文字１００ａｂ）が当該友録メンバーのＮＮに対応付けられて表示される。更に、ＩＭサービス提供サーバＳＡからのメール受付可能情報が受信された場合、対応する友録メンバー（この例では、ＮＮ「ａａａａａ」である友録メンバー）のプレゼンス情報を示すマークに代えて、当該友録メンバーが携帯メールでメッセージを受付可能であることを示すメール受付可能マーク１００ｐが表示されることになる。これにより、ユーザ端末ＵＴ２のユーザは、自己の友録メンバーがユーザ端末ＵＴｍ上でメッセージの入力指示を行うことが困難又は不可能な状態であることを把握することができると共に、携帯メールでメッセージを受付可能（つまり、移動通信端末ＭＴｍによりメッセージの交換可能）であること把握することができる。

更に、ＩＭサービス提供サーバＳＡから、受付可能時間情報も受信された場合、対応する友録メンバーのメール受付可能マーク１００ｐの近傍に、携帯メールの受付可能時間１００ｏが表示されることになる。

このように状態表示部１００ａに表示されているプレゼンス情報は、ＩＭサービス提供サーバＳＡから、後から受信された最新のプレゼンス情報に表示変更（書き換え）されるようになっている。このとき、最新のプレゼンス情報と共にメール受付可能情報も受信された場合には、最新のプレゼンス情報に表示変更されると共にこれに対応する友録メンバーのメール受付可能マークも表示（受付可能時間情報も受信された場合、受付可能時間も表示）されることになる。図６（Ｂ）の例では、ＮＮ「ｄｄｄｄｄ」である友録メンバーの最新のプレゼンス情報及びメール受付可能情報が受信されることによって、当該友録メンバーの状態が「オンライン」から「退席中」に表示変更されると共に、メール受付可能マーク１００ｑが表示されている。

また、例えばメール受付可能マーク１００ｐが表示されている場合において、当該友録メンバーの最新のプレゼンス情報が受信されたときに、メール受付可能情報が一緒に受信されなかった場合、当該メール受付可能マーク１００ｐの表示消去（携帯メールの受付可能時間１００ｏも表示されていた場合、これについても表示消去）がなされることになる。また、ＩＭサービス提供サーバＳＡから、メール受付解除情報が受信された場合も、これに対応する友録メンバーのメール受付可能マーク１００ｐの表示消去（携帯メールの受付可能時間１００ｏも表示されていた場合、これについても表示消去）がなされることになる。

また、図６（Ａ）に示すメイン画面１００には、「設定」ボタン１００ｃ、「新規メンバーの登録」ボタン１００ｄ、初期画面１００を閉じるための「×」（閉じる）ボタン１００ｅ、ログアウトするための「ログアウト」ボタン１００ｆ、「チャット開始」ボタン１００ｇ、「通話開始」ボタン１００ｈ、及び「携帯メールチャットＯＮ」ボタン１００ｋが、ユーザにより選択可能に設けられている。

このような表示状態において、ユーザ端末ＵＴ２のユーザが操作部１１を操作して「設定」ボタン１００ｃを指定（例えば、マウスによりクリック）すると、各種設定項目のリスト（図示せず）がプルダウン表示され、当該ユーザがその中から所望の設定項目を例えばマウスにより選択すると、当該選択された設定項目に対応する設定画面（図示せず）が表示される。

例えば図６（Ｂ）に示すように、設定画面の一つである、携帯メールの受付設定画面１０２が表示される。

かかる携帯メールの受付設定画面１０２には、受付対象指定部１０２ａ、受付可能時間指定部１０２ｂ、及び「登録」ボタン１０２ｃが設けられている。

受付対象指定部１０２ａでは、携帯メールの受付対象とする特定の状態を指定することができる。図６（Ｂ）の例では、ユーザは受付対象指定部１０２ａにおけるチェックボックスを指定（例えばマウスによりクリック）することで、当該特定の状態を指定する（複数指定可能）。図６（Ｂ）の例では、「取り込み中」、「退席中」、及び「オフライン」が特定の状態の候補として表示されているが、その他にもユーザにより入力された「席を外しています」等の状態を指定できるように構成しても良い。

また、受付可能時間指定部１０２ｂでは、携帯メールの受付可能時間を指定することができる。図６（Ｂ）の例では、ユーザは受付可能時間指定部１０２ｂにおけるラジオボタンを指定（例えばマウスによりクリック）して、状態変更（上記特定の状態への変更）を起点とした終了時間（例えば、３時間）をキーボードにより入力したり、或いは、受付可能の終了時刻をキーボードにより入力することで、当該受付可能時間を指定する。また、受付可能時間指定部１０２ｂにおいて「制限無し」に対応するラジオボタンを指定することもできる。

このように、ユーザが、携帯メールの受付対象とする特定の状態及び携帯メールの受付可能時間を指定した後、操作部１１を操作して「登録」ボタン１０２ｃを指定（例えばマウスによりクリック）すると、当該指定された上記特定の状態を示す特定状態情報及び当該指定された受付可能時間を示す受付可能時間情報が当該ユーザ端末ＵＴ２からＩＭサービス提供サーバＳＡに送信されることになる。これにより、図６（Ｂ）に示す「携帯メールチャットＯＦＦ」ボタン１００ｋが、「携帯メールチャットＯＮ」に切り替わる。また、ＩＭサービス提供サーバＳＡにおいては、特定状態情報及び受付可能時間情報を受信すると、当該ユーザの携帯メールの受付設定が「ＯＮ」としてユーザ情報データベース５１に登録されると共に、受信された特定状態情報及び受付可能時間情報がユーザ情報データベース５１に登録されることになる。

なお、図６（Ｂ）に示す携帯メールの受付設定画面１０２に、例えば、受信可能な曜日及び時間帯の指定部を設け、定期的な受信可能時間を設定可能としても良い。

また、当該ユーザが操作部１１を操作して「携帯メールチャットＯＮ」ボタンを指定（例えば、マウスによりクリック）すると、当該ボタンは「携帯メールチャットＯＦＦ」に切り替わると共に、携帯メール受付設定ＯＦＦ登録要求を示す受付設定ＯＦＦ登録要求情報が当該ユーザ端末ＵＴ２からＩＭサービス提供サーバＳＡに送信され、当該ユーザの携帯メールの受付設定が「ＯＦＦ」としてユーザ情報データベース５１に登録されることになる。更に、当該ユーザが「携帯メールチャットＯＦＦ」ボタンを指定（例えば、マウスによりクリック）すると、当該ボタンは「携帯メールチャットＯＮ」に切り替わると共に、携帯メール受付設定ＯＮ登録要求を示す受付設定ＯＮ登録要求情報が当該ユーザ端末ＵＴ２からＩＭサービス提供サーバＳＡに送信され、当該ユーザの携帯メールの受付設定が「ＯＮ」としてユーザ情報データベース５１に登録されることになる。このようにユーザによる１回の指定で携帯メールのＯＮ／ＯＦＦ設定を切り替えることができる。

また、当該ユーザが操作部１１を操作して「新規メンバーの登録」ボタン１００ｄを指定（例えば、マウスによりクリック）すると、新たに友だち登録するための新規メンバー登録画面（図示せず）が表示される。かかる新規メンバー登録画面において、当該ユーザは、操作部１１を操作して新たに友だち登録したいユーザのＮＮ等を指定してそのユーザのユーザ端末ＵＴｍ（ＩＰアドレス宛）、或いは電子メールアドレス宛にメッセージを交換する相手（友だち）に誘う旨の情報を送信することができ、これが送信先のユーザに許可された場合には、当該友だち登録を許可したユーザのＮＮ等が記憶部１５に保存され、且つ、当該友だち登録を許可したユーザのＮＮ等を含む友だち登録要求がＩＭサービス提供サーバＳＡに送信されて、当該友だち登録要求をしたユーザ端末ＵＴ２のユーザのユーザＩＤに対応付けられてユーザ情報データベース５１に登録（友だち登録）されることになる。

このように友だち登録することで、ユーザ端末ＵＴ２のユーザの友録メンバーが追加され、当該友録メンバーの状態が、当該ユーザ端末ＵＴ２の初期画面１００における状態表示部１００ａに表示されることになる（逆に、当該友録メンバー側においても、ユーザ端末ＵＴ２のユーザが友録メンバーとして登録されることになる）。

そして、当該ユーザが、自己の友録メンバーとメッセージの交換を行いたい場合、操作部１１を操作してメッセージの交換を行いたいオンラインの状態にある友録メンバーのＮＮを状態表示部１００ａにて指定し、「チャット開始」ボタン１００ｇを指定（例えば、マウスによりクリック、或いは、状態表示部１００ａにおける友録メンバーのＮＮをマウスによりダブルクリック）すると、チャットウインドウ画面が表示部１２上に表示される。かかるチャットウインドウ画面により、当該ユーザは、友録メンバーであるユーザとメッセージの交換（例えばＳＩＰに基づくピアツーピアでのメッセージ交換）を行うことができる。この場合のメッセージの送受信方法については公知であるのでこれ以上の詳しい説明を省略する。

なお、当該ユーザが、自己の友録メンバーと通話を行いたい場合、操作部１１を操作して通話したいオンラインの状態にある友録メンバーのＮＮを状態表示部１００ａにて指定し、「通話開始」ボタン（Click to call機能ボタン）１００ｈを指定（例えば、マウスによりクリック）すると、ユーザ端末ＵＴ２のユーザは、ユーザ端末ＵＴ２に接続したマイク付きのヘッドホン１８を用いて、友録メンバーであるユーザと通話（例えばＳＩＰに基づくＩＰ電話）を行うことができる。

そして、当該ユーザが、例えばメール受付可能マーク１００ｐが表示されている友録メンバーのＮＮ（ａａａａａ）を指定し、「チャット開始」ボタン１００ｇを指定（例えば、マウスによりクリック、或いは、当該友録メンバーのＮＮをマウスによりダブルクリック）すると、ブラウザが起動しチャットウインドウＩＤ発行要求が連携サーバＲＳに送信される。これに応じて連携サーバＲＳからチャットウインドウ（ルーム）ＩＤが発行、ユーザ端末ＵＴ２に通知され、ブラウザによりチャットウインドウ画面が表示部１２上に表示される。当該チャットウンドウ画面により、当該ユーザは、オフライン中のＮＮ「ａａａａａ」である友録メンバーとメッセージの交換を行うことができる。

なお、連携サーバＲＳから発行されるチャットウインドウＩＤは、当該チャットウインドウ画面に対して一意に付与される識別子であり、該チャットウインドウＩＤには、当該チャットウインドウ画面にてメッセージ交換を行うユーザの例えばＮＮ（「ａａａａａ」と「ｂｂｂｂｂ」。ユーザＩＤでも良い）が連携サーバＲＳにおいて紐付けられるようになっている。また、当該チャットウインドウ画面にて３人以上のユーザがメッセージ交換を行うことも可能であり、この場合も、チャットウインドウＩＤには、夫々のユーザの例えばＮＮが紐付けられる。

図７は、ユーザ端末ＵＴ２のユーザが、ユーザ端末ＵＴ１のユーザとメッセージの交換をする際の概念図である。

図７に示すように、ユーザ端末ＵＴ２の表示部１２には、チャットウインドウ画面１０３が表示されている。かかるチャットウンドウ画面１０３は、ユーザ端末ＵＴ２のユーザが、ＮＮ「ａａａａａ」であるユーザ（友録メンバー）とメッセージの交換を行うための画面であり、当該チャットウインドウ画面１０３には、送信メッセージ入力欄１０３ａ、「送信」ボタン１０３ｂ、メッセージ出力欄１０３ｃ、及びチャットウインドウ画面１０３を閉じるための「×」（閉じる）ボタン１０３ｄ等が設けられている。

このような表示状態において、ユーザ端末ＵＴ２のユーザが操作部１１を操作して送信メッセージ入力欄１０３ａに所望のメッセージの内容（例えば比較的短い文書）を入力（例えば、キーボードにより入力）して、「送信」ボタン１０３ｂを指定（例えば、マウスによりクリック）すると、当該入力されたメッセージの内容（図６の例では、「今どこにいるの？」）がメッセージ出力欄１０３ｃに表示されると共に、当該入力されたメッセージ内容を含むＨＴＴＰＳメッセージが、ユーザ端末ＵＴ２から連携サーバＲＳに送信される。

そして、図７に示すように、連携サーバＲＳに送信されたＨＴＴＰＳメッセージが携帯メールに変換される。当該携帯メールのボディには、ＨＴＴＰＳメッセージの内容が記述され、ヘッダの宛先（Ｔｏ：）にはユーザ端末ＵＴ１のユーザの携帯メールアドレスが記述され、ヘッダの送信元（Ｆｒｏｍ：）には上記チャットウインドウ画面に固有の携帯メールアドレス（例えば、チャットウインドウＩＤを暗号化したデータ＠ドメイン名）が記述される。そして、当該携帯メールが、ゲートウェイサーバＧＳ及びメールサーバＭＳ（図７では図示せず）等を介して、ＮＮ「ａａａａａ」であるユーザの移動通信端末ＭＴ１に送信される。これにより、当該移動通信端末ＭＴ１のユーザは、移動通信端末ＭＴ１により受信した携帯メールで上記メッセージの内容を確認することができる。

そして、当該ＮＮ「ａａａａａ」であるユーザが、移動通信端末ＭＴ１の操作部を操作して返信メッセージの内容（図７の例では、「渋谷駅にいるよ！」）を入力し送信ボタンを押下すると、当該内容を含む携帯メール（ヘッダの宛先（Ｔｏ：）には上記チャットウインドウ画面に固有の携帯メールアドレスが記述、ヘッダの送信元（Ｆｒｏｍ：）には移動通信端末ＭＴ１のユーザの携帯メールアドレスが記述される）が、ゲートウェイサーバＧＳ（図７では図示せず）等を介して、連携サーバＲＳに送信される。そして、当該返信された携帯メールは、例えばユーザ端末ＵＴ２からのチャットウインドウ更新要求に応じて連携サーバＲＳによりＨＴＴＰＳメッセージに変換され、当該ＨＴＴＰＳメッセージがユーザ端末ＵＴ２に送信され、その内容がチャットウンドウ画面１０３におけるメッセージ出力欄１０３ｃに表示される。

こうして、例えば、ユーザ端末ＵＴ２のユーザと、移動通信端末ＭＴ１のユーザ（ユーザ端末ＵＴ１のユーザでもある）との間でメッセージ交換（携帯チャット）を行うことができる。

［２．メッセージ送受信システムの動作］
次に、本実施形態に係るメッセージ送受信システムＳの動作について説明する。

（ＩＭサービス提供サーバＳＡにおける処理）
先ず、ＩＭサービス提供サーバＳＡのシステム制御部７における処理について図８を参照して説明する。

図８は、ＩＭサービス提供サーバＳＡのシステム制御部７における処理を示すフローチャートである。なお、当該処理は、ＩＭサービス提供サーバＳＡのシステム制御部７において、常時実行（メンテナンス以外）されている。また、上述したユーザ情報データベース５１に登録された情報は、適宜、システム制御部７により読み込まれ（ＲＡＭの所定領域に記憶）参照されることになる。

図８に示す処理において、ＩＭサービス提供サーバＳＡのシステム制御部７は、何れかのユーザの現在の状態の変更を検知したか否かを判別し（ステップＳ１）、何れかのユーザの現在の状態の変更を検知した場合には（ステップＳ１：ＹＥＳ）、当該ユーザのユーザＩＤ（又はＮＮ）を特定し、当該ユーザの変更後の状態を示すプレゼンス情報を、当該ユーザのユーザＩＤ（又はＮＮ）に対応付けてユーザ情報データベース５１に変更登録（上書）し（ステップＳ２）、ステップＳ３に進む。

なお、ユーザの現在の状態の変更は、上述したように、ユーザ端末ＵＴｍから送信された、ログイン要求、ログアウト要求、又は状態変更要求等（これらの要求には当該ユーザを特定するためのユーザＩＤ（又はＮＮ）が付加されている）がＩＭサービス提供サーバＳＡにより受信された場合に検知される。また、当該ユーザの変更後の状態は、上記要求の種類によって特定されることになる。

一方、何れかのユーザの現在の状態の変更が検知されない場合には（ステップＳ１：ＮＯ）、ステップＳ９へ進む。

ステップＳ３では、システム制御部７は、上記ユーザＩＤ（又はＮＮ）が特定されたユーザの携帯メールの受付設定が「ＯＮ」であるか否かを、ユーザ情報データベース５１に登録された携帯メール受付設定情報を参照することにより判別し、当該ユーザの携帯メールの受付設定が「ＯＮ」でない場合には（ステップＳ３：ＮＯ）、ステップＳ４に進み、当該ユーザの携帯メールの受付設定が「ＯＮ」である場合には（ステップＳ３：ＹＥＳ）、ステップＳ５に進む。

ステップＳ４では、システム制御部７は、当該ユーザ（つまり、上記ユーザＩＤ（又はＮＮ）が特定されたユーザ）の友録メンバーのうちログイン中にある（例えば、オフラインでない）友録メンバーのアドレス情報をユーザ情報データベース５１から特定し、当該友録メンバーのユーザ端末ＵＴｍに対して（当該友録メンバーのアドレス情報にしたがって）、当該ユーザの変更後の状態を示すプレゼンス情報（当該ユーザの上記特定されたユーザＩＤ（又はＮＮ）が付加される）を通信部３及びネットワークＮＷ等を介して送信し、ステップＳ９に進む。

ステップＳ５では、システム制御部７は、当該ユーザの変更後の状態が、当該ユーザのユーザＩＤ（又はＮＮ）に対応付けられている特定状態情報（ユーザ情報データベース５１に登録されている特定状態情報）に示される特定の状態であるか否かを判別し、特定の状態でない場合には（ステップＳ５：ＮＯ）、ステップＳ４に移行して上記と同様の処理を行い、特定の状態である場合には（ステップＳ５：ＹＥＳ）、ステップＳ６に進む。

ステップＳ６では、システム制御部７は、当該ユーザのユーザＩＤ（又はＮＮ）に対応付けられている受付可能時間情報（ユーザ情報データベース５１に登録されている受付可能時間情報）に示される携帯メールの受付可能時間は制限無しか否かを判別し、制限無しである場合には（ステップＳ６：ＹＥＳ）、ステップＳ７に進み、制限無しでない（すなわち、制限がある）場合には（ステップＳ６：ＮＯ）、ステップＳ８に進む。

ステップＳ７では、システム制御部７は、当該ユーザの友録メンバーのうちログイン中にある（例えば、オフラインでない）友録メンバーのアドレス情報をユーザ情報データベース５１から特定し、当該友録メンバーのユーザ端末ＵＴｍに対して（当該友録メンバーのアドレス情報にしたがって）、当該ユーザの変更後の状態を示すプレゼンス情報（当該ユーザの上記特定されたユーザＩＤ（又はＮＮ）が付加される）、及び上記メール受付可能情報を通信部３及びネットワークＮＷ等を介して送信し、ステップＳ９に進む。

ステップＳ８では、システム制御部７は、当該ユーザの友録メンバーのうちログイン中にある（例えば、オフラインでない）友録メンバーのアドレス情報をユーザ情報データベース５１から特定し、当該友録メンバーのユーザ端末ＵＴｍに対して（当該友録メンバーのアドレス情報にしたがって）、当該ユーザの変更後の状態を示すプレゼンス情報（当該ユーザの上記特定されたユーザＩＤ（又はＮＮ）が付加される）、上記メール受付可能情報、及び当該ユーザのユーザＩＤに対応付けられている受付可能時間情報（ユーザ情報データベース５１に登録されている受付可能時間情報）を通信部３及びネットワークＮＷ等を介して送信し、ステップＳ９に進む。

ステップＳ９では、システム制御部７は、現在時刻が、携帯メールの受付終了時間（上述した受付可能時間情報により定まる）に達したユーザがあるか否かを、例えばユーザ情報データベース５１に登録された受付可能時間情報を参照して判別し、携帯メールの受付終了時間に達した（受付を終了する時間となった）ユーザがある場合には（ステップＳ９：ＹＥＳ）、ステップＳ１０に進み、携帯メールの受付可能時間に達したユーザがない場合には（ステップＳ９：ＮＯ）、ステップＳ１２に進む。

ステップＳ１０では、システム制御部７は、携帯メールの受付終了時間に達したユーザの携帯メールの受付設定（携帯メール受付設定情報に示される設定）を「ＯＦＦ」としてユーザ情報データベース５１に登録（「ＯＮ」から「ＯＦＦ」へ変更登録）する。続いて、システム制御部７は、当該携帯メールの受付終了時間に達したユーザの友録メンバーのうちログイン中にある（例えば、オフラインでない）友録メンバーのアドレス情報をユーザ情報データベース５１から特定し、当該友録メンバーのユーザ端末ＵＴｍに対して（当該友録メンバーのアドレス情報にしたがって）、上記メール受付解除情報（当該携帯メールの受付設定が「ＯＦＦ」になったユーザのユーザＩＤ（又はＮＮ）が付加される）を通信部３及びネットワークＮＷ等を介して送信し（ステップＳ１１）、ステップＳ１２に進む。

ステップＳ１２では、システム制御部７は、何れかのユーザ端末ＵＴｍから特定状態情報及び受付可能時間情報を受信したか否かを判別する。この特定状態情報及び受付可能時間情報は、ユーザ端末ＵＴｍにおいて指定（例えば、図６（Ｂ）の携帯メールの受付設定画面１０２上で指定）された特定の状態（例えば、オフライン）を示す特定状態情報及び当該指定された受付可能時間を示す受付可能時間情報である。

そして、当該特定状態情報等（つまり、特定状態情報及び受付可能時間情報）を受信した場合には（ステップＳ１２：ＹＥＳ）、ステップＳ１３に進み、当該特定状態情報等を受信していない場合には（ステップＳ１２：ＮＯ）、ステップＳ１５に進む。

ステップＳ１３では、システム制御部７は、上記受信された特定状態情報に付加されているユーザＩＤ（又はＮＮ）に対応する携帯メールの受付設定（携帯メール受付設定情報に示される設定）を「ＯＮ」としてユーザ情報データベース５１に登録（既に「ＯＮ」であればそのまま）する。続いて、システム制御部７は、上記受信された特定状態情報及び受付可能時間情報を、当該特定状態情報等に付加されているユーザＩＤ（又はＮＮ）に対応付けてユーザ情報データベース５１に変更登録（上書）し（ステップＳ１４）、ステップＳ１５に進む。

ステップＳ１５では、システム制御部７は、何れかのユーザ端末ＵＴｍから上述した受付設定ＯＦＦ登録要求情報を受信したか否かを判別し、当該受付設定ＯＦＦ登録要求情報を受信した場合には（ステップＳ１５：ＹＥＳ）、ステップＳ１６に進み、当該受付設定ＯＦＦ登録要求情報を受信していない場合には（ステップＳ１５：ＮＯ）、ステップＳ１７に進む。

ステップＳ１６では、システム制御部７は、上記受信された受付設定ＯＦＦ登録要求情報に付加されているユーザＩＤ（又はＮＮ）に対応する携帯メールの受付設定（携帯メール受付設定情報に示される設定）を「ＯＦＦ」としてユーザ情報データベース５１に登録し、ステップＳ１７に進む。

ステップＳ１７では、システム制御部７は、何れかのユーザ端末ＵＴｍから上述した受付設定ＯＮ登録要求情報を受信したか否かを判別し、当該受付設定ＯＮ登録要求情報を受信した場合には（ステップＳ１７：ＹＥＳ）、ステップＳ１８に進み、当該受付設定ＯＮ登録要求情報を受信していない場合には（ステップＳ１７：ＮＯ）、ステップＳ１９に進む。

ステップＳ１８では、システム制御部７は、上記受信された受付設定ＯＮ登録要求情報に付加されているユーザＩＤ（又はＮＮ）に対応する携帯メールの受付設定（携帯メール受付設定情報に示される設定）を「ＯＮ」としてユーザ情報データベース５１に登録し、ステップＳ１９に進む。

ステップＳ１９では、システム制御部７は、連携サーバＲＳから携帯メール受信通知（例えば、ＨＴＴＰＳ ＰＯＳＴ）を受信したか否かを判別し、当該携帯メール受信通知を受信した場合には（ステップＳ１９：ＹＥＳ）、ステップＳ２０に進み、当該携帯メール受信通知を受信していない場合には（ステップＳ１９：ＮＯ）、ステップＳ２１に進む。この携帯メール受信通知は、移動通信端末ＭＴｍから返信された携帯メールを連携サーバＲＳが受信した際に送信されるものであり、当該携帯メール受信通知には、メッセージ送信元のユーザ端末ＵＴｍのユーザのユーザＩＤ（又はＮＮ）及びチャットウインドウＩＤが含まれている。

ステップＳ２０では、システム制御部７は、携帯メール受信通知に含まれるユーザＩＤ（又はＮＮ）に対応するアドレス情報をユーザ情報データベース５１から特定し、ユーザ端末ＵＴｍに対して、携帯メール受信通知（チャットウインドウＩＤを含む、例えば、ＳＩＰに基づくメッセージ）を通信部３及びネットワークＮＷ等を介して送信（ＰＵＳＨ型配信）し、ステップＳ２１に進む。なお、当該携帯メール受信通知を受けたユーザ端末ＵＴｍの処理は後述する。

ステップＳ２１におけるその他の処理では、例えば、各ユーザ端末ＵＴｍからのログイン要求、ログアウト要求、又は状態変更要求等に応じた処理が行われるが、詳しい説明は省略する。

（ユーザ端末ＵＴｍにおける処理）
次に、ユーザ端末ＵＴｍのシステム制御部１７における処理について図９を参照して説明する。

図９は、ユーザ端末ＵＴｍのシステム制御部１７におけるメッセンジャーに係る処理を示すフローチャートである。

あるユーザ端末ＵＴｍ（例えば、ユーザ端末ＵＴ２）においてメッセンジャーが起動すると、図９に示す処理が開始され、先ず、システム制御部１７は、自動的に又はユーザの指示によりログイン処理を実行する（ステップＳ３１）。かかるログイン処理においては、上述したように、ユーザ端末ＵＴｍがネットワークＮＷを介してＩＭサービス提供サーバＳＡに接続し（セッション確立）、当該ＩＭサービス提供サーバＳＡに対してログイン要求（メッセンジャーの起動時にユーザにより入力されたユーザＩＤ及びパスワード、或いは、以前に入力され記憶部１５に保存されていたユーザＩＤ及びパスワードを含む）を行い、ＩＭサービス提供サーバＳＡにおける認証処理（上記ステップＳ２１で行われる）によりログインが許可された場合、当該ユーザ端末ＵＴｍのアドレス情報及び当該ユーザ端末ＵＴｍのユーザのプレゼンス情報（例えば、「オンライン」を示すプレゼンス情報）等が、ＩＭサービス提供サーバＳＡにより、当該ユーザのユーザＩＤに対応付けられてユーザ情報データベース５１に登録（友録メンバー毎に登録）される。また、ＩＭサービス提供サーバＳＡから当該ログインが許可されたユーザの友録メンバーのプレゼンス情報（当該友録メンバーのユーザＩＤ（又はＮＮ）が付加されている）が当該ユーザ端末ＵＴｍに送信される。

次いで、システム制御部１７は、図６（Ａ）に示すようなメイン画面１００を表示部１２上に表示する（ステップＳ３２）。

次いで、システム制御部１７は、ＩＭサービス提供サーバＳＡから送信（上記ステップＳ４、Ｓ７、又はＳ８で送信）されたプレゼンス情報を受信したか否かを判別し（ステップＳ３３）、当該プレゼンス情報を受信した場合には（ステップＳ３３：ＹＥＳ）、ステップＳ３４に進み、当該プレゼンス情報を受信していない場合には（ステップＳ３３：ＮＯ）、ステップＳ３９に進む。なお、ステップＳ３３で受信されるプレゼンス情報は、ステップＳ３２の処理で友録メンバー全員のプレセンス情報が表示された後、何れかの友録メンバーの状態が変更されたときに送信されてくるものである。

ステップＳ３４では、システム制御部１７は、上記プレゼンス情報と共にメール受付可能情報を受信したか否かを判別し、当該メール受付可能情報を受信していない場合には（ステップＳ３４：ＮＯ）、ステップＳ３５に進み、当該メール受付可能情報を受信した場合には（ステップＳ３４：ＹＥＳ）、ステップＳ３６に進む。

ステップＳ３５では、システム制御部１７は、メイン画面１００に表示されている友録メンバーのプレゼンス情報のうち、上記受信されたプレゼンス情報に付加されたユーザＩＤ（又はＮＮ）に対応する友録メンバーのプレゼンス情報を、上記受信されたプレゼンス情報に表示更新（例えば、オフラインからオンラインへ変更）し、ステップＳ３９に進む。

ステップＳ３６では、システム制御部１７は、上記プレゼンス情報及びメール受付可能情報と共に受付可能時間情報を受信したか否かを判別し、当該受付可能時間情報を受信していない場合には（ステップＳ３６：ＮＯ）、ステップＳ３７に進み、当該受付可能時間情報を受信した場合には（ステップＳ３６：ＹＥＳ）、ステップＳ３８に進む。

ステップＳ３７では、システム制御部１７は、プレゼンス情報の表示更新する（ステップＳ３５と同様）と共に、上述したように、プレゼンス情報を示すマークに代えて当該友録メンバーのメール受付可能マークを表示し、ステップＳ３９に進む。

一方、ステップＳ３８は、システム制御部１７は、プレゼンス情報の表示更新する（ステップＳ３５と同様）と共に、上述したように、当該プレゼンス情報を示すマークに代えて当該友録メンバーのメール受付可能マーク及び受付可能時間を表示し、ステップＳ３９に進む。

ステップＳ３９では、ＩＭサービス提供サーバＳＡから送信（上記ステップＳ１１で送信）されたメール受付解除情報を受信したか否かを判別し、当該メール受付解除情報を受信した場合には（ステップＳ３９：ＹＥＳ）、当該メール受付解除情報に付加されたユーザＩＤ（又はＮＮ）に対応する友録メンバーのメール受付可能マークを表示消去（受付可能時間も表示されていた場合、これについても表示消去）（ステップＳ４０）しプレゼンス情報を示すマークを表示し、当該メール受付解除情報を受信していない場合には（ステップＳ３９：ＮＯ）、ステップＳ４１に進む。

ステップＳ４１では、携帯メールの受付設定に係る登録指示があったか否かを判別しており、例えば図６（Ｂ）に示すような携帯メールの受付設定画面１０２が表示されている状態で、ユーザが、上述したように、携帯メールの受付対象とする特定の状態及び携帯メールの受付可能時間を指定した後、操作部１１を操作して「登録」ボタン１０２ｃを指定（例えばマウスによりクリック）すると、システム制御部１７は、当該携帯メールの受付設定に係る登録指示があったと判別し（ステップＳ４１：ＹＥＳ）、当該指定された上記特定の状態を示す特定状態情報及び当該指定された受付可能時間を示す受付可能時間情報（当該ユーザのユーザＩＤ（又はＮＮ）が付加される）を、通信部１３及びネットワークＮＷ等を介してＩＭサービス提供サーバＳＡに送信し（ステップＳ４２）、ステップＳ４３に進む。なお、当該登録指示がない場合（ステップＳ４１：ＮＯ）、ステップＳ４３に移行される。

ステップＳ４３では、システム制御部１７は、携帯メール受付設定ＯＦＦ指示があったか否かを判別しており、例えば図６（Ａ）に示すようなメニュー画面１００に「携帯メールチャットＯＮ」ボタンが表示されている状態で、ユーザが、操作部１１を操作して当該「携帯メールチャットＯＮ」ボタンを指定（例えばマウスによりクリック）すると、システム制御部１７は、携帯メール受付設定ＯＦＦ指示があったと判別し（ステップＳ４３：ＹＥＳ）、受付設定ＯＦＦ登録要求情報（当該ユーザのユーザＩＤ（又はＮＮ）が付加される）を、通信部１３及びネットワークＮＷ等を介してＩＭサービス提供サーバＳＡに送信し（ステップＳ４４）、ステップＳ４５に進む。なお、当該携帯メール受付設定ＯＦＦ指示がない場合（ステップＳ４３：ＮＯ）、ステップＳ４５に移行される。

ステップＳ４５では、システム制御部１７は、携帯メール受付設定ＯＮ指示があったか否かを判別しており、例えば図６（Ａ）に示すようなメニュー画面１００に「携帯メールチャットＯＦＦ」が表示されている状態で、ユーザが、操作部１１を操作して当該「携帯メールチャットＯＦＦ」ボタンを指定（例えばマウスによりクリック）すると、システム制御部１７は、携帯メール受付設定ＯＮ指示があったと判別し（ステップＳ４５：ＹＥＳ）、受付設定ＯＮ登録要求情報（当該ユーザのユーザＩＤ（又はＮＮ）が付加される）を、通信部１３及びネットワークＮＷ等を介してＩＭサービス提供サーバＳＡに送信し（ステップＳ４６）、ステップＳ４７に進む。なお、当該携帯メール受付設定ＯＮ指示がない場合（ステップＳ４５：ＮＯ）、ステップＳ４７に移行される。

ステップＳ４７における携帯チャット（ユーザ端末ＵＴｍと移動通信端末ＭＴｍの間のメッセージ交換）処理は、例えば図６（Ａ）に示すようなメニュー画面１００上にメール受付可能マーク１００ｐが表示されている友録メンバーのＮＮを指定すると開始される。

なお、携帯チャット処理の詳細については後述する。

ステップＳ４８におけるその他の処理では、友録メンバーであるユーザとの間のメッセージ交換処理（例えば、図６（Ａ）に示すようなメニュー画面１００上にメール受付可能マーク１００ｐが表示されていない友録メンバーのＮＮが指定されることにより実行される例えばＳＩＰに基づくピアツーピアでのメッセージ交換処理）、各種設定処理、又は状態変更要求処理等が実行されるが、詳しい説明は省略する。

ステップＳ４９では、システム制御部１７は、ログアウト指示があったか否かを判別しており、例えば図６（Ａ）に示すようなメニュー画面１００が表示されている状態で、ユーザが、操作部１１を操作して当該「ログアウト」ボタン１００ｆを指定（例えばマウスによりクリック）すると、システム制御部１７は、ログアウト指示があったと判別し（ステップＳ４９：ＹＥＳ）、ログアウト要求（当該ユーザのユーザＩＤ（又はＮＮ）が付加される）を、通信部１３及びネットワークＮＷ等を介してＩＭサービス提供サーバＳＡに送信し、当該処理を終了（メニュー画面１００も閉じる）する。なお、当該ログアウト指示がない場合（ステップＳ４９：ＮＯ）、ステップＳ３３に戻り、処理が継続される。

（携帯チャット時における動作）
次に、携帯チャット時における動作について図１０及び図１１を参照して説明する。

図１０は、携帯チャット時における各端末及びサーバにおける処理及び情報のやり取りを示すシーケンス図であり、図１１は、ユーザ端末ＵＴ２と連携サーバＲＳで送受信されるＨＴＴＰＳに基づくデータの形式及び内容を示す概念図である。

例えばユーザ端末ＵＴ２の上記ステップＳ４７の処理において、メール受付可能マーク１００ｐが表示されている友録メンバーのＮＮ（例えば、ａａａａａ）が指定されることにより携帯チャット処理が開始されると、ブラウザが起動され（ステップＳ１０１）、当該ブラウザにより、予め設定された連携サーバＲＳのＵＲＬが指定されることによりチャットウインドウＩＤ発行要求が連携サーバＲＳに送信される（ステップＳ１０２）。

このチャットウインドウＩＤ発行要求に係るデータには、図１１（Ａ）に示すように、携帯チャット開設者（この例では、携帯チャット処理を開始させたユーザ端末ＵＴ２のユーザ）のＮＮ（ユーザＩＤでも良い）、携帯チャット参加者（この例では、メッセージ交換相手となる移動通信端末ＭＴ１のユーザ）のＮＮ（ユーザＩＤでも良い）、ローカルタイム（ユーザ端末ＵＴ２における時計機能による時刻）スタンプ、処理内容（この例では、チャットウインドウオープン）、及び暗号／復号に使用する情報が含まれている。

なお、携帯チャット開設者のＮＮ、携帯チャット参加者のＮＮ、及びローカルタイムスタンプは、ユーザ端末ＵＴ２側でＳＳＬ（Secure Socket Layer）により暗号化され、連携サーバＲＳ側で復号されるようになっている。

こうして送信されたチャットウインドウＩＤ発行要求が連携サーバＲＳにて受信されると、連携サーバＲＳは、当該チャットウインドウＩＤ発行要求に含まれる処理内容（この例では、チャットウインドウオープン）に対応するプログラムを実行し、チャットウインドウＩＤが発行（過去に発行されたＩＤとは重複しないＩＤを作成）する（ステップＳ１０３）。なお、発行されたチャットウインドウＩＤは、携帯チャット開設者のＮＮ、携帯チャット参加者のＮＮ、及びローカルタイムスタンプと共に互いに対応付けられ、連携サーバＲＳに記憶される。

そして、発行されたチャットウインドウＩＤ通知が、連携サーバＲＳからユーザ端末ＵＴ２に送信される（ステップＳ１０４）。

このチャットウインドウＩＤ通知に係るデータには、図１１（Ｂ）に示すように、リターンコード（ここでは、正常、他に有効期限切れ等のエラーがある）及び上記発行されたチャットウインドウＩＤが含まれている。

こうして送信されたチャットウインドウＩＤ通知がユーザ端末ＵＴ２にて受信されると、ブラウザにより例えば図７に示すようなチャットウインドウ画面が表示部１２上に表示される（ステップＳ１０５）。なお、送信されたチャットウインドウＩＤは、チャットウインドウ画面に関連付けられて記憶される。

そして、表示されたチャットウインドウ画面上における送信メッセージ入力欄１０３ａに、ユーザ端末ＵＴ２のユーザが操作部１１を操作して所望のメッセージの内容を入力（ステップＳ１０６）して、「送信」ボタン１０３ｂを指定すると、ブラウザにより、メッセージ送信要求が連携サーバＲＳに送信される（ステップＳ１０７）。

このメッセージ送信要求に係るデータ（上述したＨＴＴＰＳメッセージに相当）には、図１１（Ｃ）に示すように、チャットウインドウＩＤ、メッセージ送信者（この例では、メッセージを入力したユーザ端末ＵＴ２のユーザ）のＮＮ、ローカルタイムスタンプ、メッセージの内容、処理内容（この例では、コントリビュート）、及び暗号／復号に使用する情報が含まれている。

なお、チャットウインドウＩＤ、メッセージ送信者のＮＮ、ローカルタイムスタンプ、及びメッセージの内容は、ユーザ端末ＵＴ２側でＳＳＬにより暗号化され、連携サーバＲＳ側で復号されるようになっている。

こうして送信されたメッセージ送信要求が連携サーバＲＳにて受信されると、これに含まれるメッセージ送信者のＮＮ、ローカルタイムスタンプ、及びメッセージの内容がチャットウインドウＩＤに対応付けられて記憶、保存される（ステップＳ１０８）。

そして、連携サーバＲＳは、メッセージ送信要求に含まれる処理内容（この例では、コントリビュート）に対応するプログラムを実行し、携帯メールを生成する（ステップＳ１０９）。具体的には、当該メッセージ送信要求に含まれるチャットウインドウＩＤを暗号化したデータを含む携帯メールアドレスがヘッダの送信元（Ｆｒｏｍ：）に記述され、当該メッセージ送信要求に含まれるチャットウインドウＩＤに対応付けられて記憶されている携帯チャット参加者のＮＮに対応付けられた携帯メールアドレス（ユーザ情報データベースから取得される）が宛先（Ｔｏ：）に記述され、当該メッセージ送信要求に含まれるメッセージの内容がボディに記述されて携帯メールが生成される。

そして、生成された携帯メールが、連携サーバＲＳからゲートウェイサーバＧＳ（図１０では図示せず）を介してメールサーバＭＳに送信され（ステップＳ１１０）、当該メールサーバＭＳにおけるメールボックスに保存される（ステップＳ１１１）。

こうして保存された携帯メールは、宛先の携帯メールアドレスに対応する移動通信端末ＭＴ１からの取得要求に応じて当該移動通信端末ＭＴ１に送信される（ステップＳ１１２）。

そして、移動通信端末ＭＴ１のユーザは携帯メールに対する返信メッセージの内容を入力し（ステップＳ１１３）、送信ボタンを押下すると、当該返信メッセージの内容を含む携帯メール（ヘッダの宛先（Ｔｏ：）には上記チャットウインドウＩＤを暗号化したデータを含む携帯メールアドレスが記述、ヘッダの送信元（Ｆｒｏｍ：）には移動通信端末ＭＴ１のユーザの携帯メールアドレスが記述）が、ゲートウェイサーバＧＳ等を介して、連携サーバＲＳに送信される（ステップＳ１１４）。そして、連携サーバＲＳによって、当該携帯メールの宛先として記述された携帯メールアドレスからチャットウインドウＩＤが抽出（携帯メールアドレスにおける＠の前のデータを復号することにより）され、当該チャットウインドウＩＤに対応付けられて当該携帯メールが保存される（ステップＳ１１５）。

続いて、連携サーバＲＳは、当該抽出したチャットウインドウＩＤと、これに対応付けられて記憶されている携帯チャット開設者（この例では、ユーザ端末ＵＴ２のユーザ）のＮＮ（ユーザＩＤでも良い）とを含む携帯メール受信通知を、ＩＭサービス提供サーバＳＡに送信する（ステップＳ１１６）。

こうして送信された携帯メール受信通知がＩＭサービス提供サーバＳＡにて受信されると、上述したステップＳ２０の処理を経て、携帯メール受信通知（チャットウインドウＩＤを含む）が、ＩＭサービス提供サーバＳＡからユーザ端末ＵＴ２に送信される（ステップＳ１１７）。

こうして送信された携帯メール受信通知がユーザ端末ＵＴ２にて受信されると、メッセンジャーにより携帯メール受信通知に含まれるチャットウインドウＩＤが抽出され、これがブラウザに渡され、当該ブラウザにより、当該チャットウインドウＩＤを含むチャットウインドウ更新要求が連携サーバＲＳに送信される（ステップＳ１１８）。

なお、携帯メール受信通知によりチャットウインドウ更新要求が連携サーバＲＳに送信される他の例として、携帯メール受信通知がなくともブラウザにより定期的に（例えば、５分毎に）チャットウインドウ更新要求が連携サーバＲＳに送信される（メッセージを定期的にリロード）ように構成しても良い。

このチャットウインドウ更新要求に係るデータには、図１１（Ｄ）に示すように、チャットウインドウＩＤ、チャットウインドウ更新者（この例では、ユーザ端末ＵＴ２のユーザ）のＮＮ、ローカルタイムスタンプ、処理内容（この例では、アップデート）、及び暗号／復号に使用する情報が含まれている。

こうして送信されたチャットウインドウ更新要求が連携サーバＲＳにて受信されると、連携サーバＲＳは、メッセージ送信要求に含まれる処理内容（この例では、アップデート）に対応するプログラムを実行し、ＨＴＴＰＳメッセージを生成する（ステップＳ１１９）。具体的には、チャットウインドウ更新要求に含まれるチャットウインドウＩＤに対応付けられて保存されている携帯メールが取得され、そのボディに記述されたメッセージの内容を含むＨＴＴＰＳメッセージが生成される。

こうして生成されたＨＴＴＰＳメッセージは、メッセージ通知として連携サーバＲＳからユーザ端末ＵＴ２に送信される（ステップＳ１２０）。

このメッセージ通知に係るデータには、図１１（Ｅ）に示すように、リターンコード、チャットウインドウＩＤ、メッセージの内容、及びリードフラグが含まれている。

こうして送信されたメッセージ通知がユーザ端末ＵＴ２にて受信されると、メッセージ通知に含まれるメッセージの内容が、ブラウザにより、チャットウインドウ画面上におけるメッセージ出力欄１０３ｃに表示される（ステップＳ１２１）。

以上のステップＳ１０６〜ステップＳ１２１までの処理は、ユーザ端末ＵＴ２においてチャットウインドウ画面が閉じる（表示解除される）まで、繰り返し行うことが可能になっている。なお、勿論、連続してユーザ端末ＵＴ２がメッセージを送信する場合には、ステップＳ１０６〜ステップＳ１１２までの処理が連続して行われることになるし、連続して移動通信端末ＭＴ１がメッセージを送信する場合には、ステップＳ１１３〜ステップＳ１２１までの処理が連続して行われることになる。そして、ユーザ端末ＵＴ２においてチャットウインドウ画面が閉じられた場合には、チャットウインドウＩＤ等を含む携帯チャット終了通知が、当該ユーザ端末ＵＴ２から連携サーバＲＳに送信され、これに応じて連携サーバＲＳからメールサーバＭＳを介して移動通信端末ＭＴ１に対して（携帯メールアドレス宛に）携帯チャット終了を示す携帯メールが送信される。その後、移動通信端末ＭＴ１から携帯メールの返信があった場合、連携サーバＲＳは当該携帯メールを保存せず、メールサーバＭＳを介して移動通信端末ＭＴ１に対して携帯チャット終了を示す携帯メールを返信する。或いは、連携サーバＲＳは当該携帯メールを保存しておき、後に、ユーザ端末ＵＴ２に対してＨＴＴＰＳメッセージとして送信するように構成しても構わない。

以上説明したように、上記実施形態によれば、ＩＭサービス提供サーバＳＡが何れかのユーザの現在の状態の変更を検知したとき、当該ユーザの携帯メールの受付設定が「ＯＮ」であり、当該変更後の状態が当該ユーザに対応する上記特定状態情報に示される特定の状態（例えば、オフライン）である場合には、当該ユーザの変更後の状態を示すプレゼンス情報と共に、当該ユーザが携帯メールでメッセージを受付可能であることを示すメール受付可能情報を、当該ユーザの友録メンバーのユーザ端末ＵＴｍに対して送信し、当該プレゼンス情報及びメール受付可能情報を受信したユーザ端末ＵＴｍが、上記ユーザのプレゼンス情報と共に、メール受付可能マークを表示するように構成したので、ユーザ端末ＵＴｍのユーザは、相手のユーザ（友録メンバー）が、例えばメッセージの交換を行うことが困難又は不可能な状態（例えば、オンラインや退席中）にあっても、当該相手のユーザが携帯メールでメッセージを受付可能であり、対話しても良い状態にあるかどうかを事前に把握することができる。更に、上記メール受付可能情報と共に受付可能時間情報をユーザ端末ＵＴｍに送信する構成によれば、ユーザ端末ＵＴｍのユーザは、相手のユーザが携帯メールでメッセージを、何時まで受付可能であるかをも事前に把握することができる。

また、ＩＭサービス提供サーバＳＡの他に、Ｗｅｂサーバ及びメールサーバとして機能する連携サーバＲＳを設置し、各ユーザの携帯メールアドレスは、連携サーバＲＳにより取得されるようにし、連携サーバＲＳが、ＨＴＴＰＳメッセージを受信した場合、これを携帯メールに変換し、当該携帯メールを、当該メッセージの宛先のユーザの携帯メールアドレス宛てに送信し、また、当該ユーザから返信された携帯メールをＨＴＴＰＳメッセージに変換し、メッセージの送信元のユーザのユーザ端末ＵＴｍに送信するように構成したので、ユーザ端末ＵＴｍのユーザは、相手のユーザがメッセージの交換を行うことが困難又は不可能な状態にあり、しかも、当該相手のユーザの携帯メールアドレスを知らなくても、携帯メールを利用したメッセージの交換により相手のユーザと対話を行うことができる。また、各ユーザは、自己の携帯メールアドレスを相手のユーザに教えず秘密にすることができる。更に、既存のＷｅｂサーバ、メールサーバ、及びＩＭサービス提供サーバを効率良く活用できコスト低減を図ることができる。

また、移動通信端末ＭＴｍから返信された携帯メールを受信した連携サーバＲＳが、携帯メール受信通知をＩＭサービス提供サーバＳＡに送信し、これを受けたＩＭサービス提供サーバＳＡがユーザ端末ＵＴｍに対して携帯メール受信通知を送信（ＰＵＳＨ型配信）するように構成したので、当該ユーザ端末ＵＴｍは、上記携帯メールで返信されたメッセージを迅速に連携サーバＲＳから取得することができる。これは、ユーザ端末ＵＴｍが定期的に連携サーバＲＳに対して更新を要求する場合に比べて、無駄な更新要求を削減することができるので、サーバの負荷を低減することができる。

また、各ユーザは、図６（Ｂ）に示すような受付設定画面１０２上で、携帯メールの受付対象とする所望の特定の状態及び携帯メールの所望の受付可能時間を設定できるように構成したので、各ユーザ毎に特有の受付状態及び受付時間を設定することができ、利便性を向上させることができる。

なお、上記実施形態においては、ユーザは、図６（Ｂ）に示すような受付設定画面１０２上で、携帯メールの受付対象とする特定の状態及び携帯メールの受付可能時間を設定可能としたが、別の例として、例えばユーザからログアウト指示（上記ステップＳ４９）があった際に、図６（Ｂ）に示すような受付設定画面１０２が表示され、当該ユーザにより上記特定の状態及び受付可能時間が指定された場合、上記特定状態情報及び受付可能時間情報がＩＭサービス提供サーバＳＡに送信され、当該ユーザの携帯メールの受付設定が「ＯＮ」としてユーザ情報データベース５１に登録されると共に、当該特定状態情報及び受付可能時間情報がユーザ情報データベース５１に登録されるように構成しても良い。この構成によれば、ユーザは忘れずに、携帯メールの受付設定「ＯＮ」、特定状態情報及び受付可能時間情報を登録することができる。

また、上記実施形態において、各ユーザが、上記特定の状態及び受付可能時間を移動通信端末ＭＴｍから入力し、当該移動通信端末ＭＴｍが、入力された特定状態情報及び受付可能時間情報（ユーザＩＤを付加）を含む携帯メールを連携サーバＲＳに対して送信することにより、その情報がＩＭサービス提供サーバＳＡに送信され、当該ユーザの携帯メールの受付設定が「ＯＮ」としてユーザ情報データベース５１に登録されると共に、当該特定状態情報及び受付可能時間情報がユーザ情報データベース５１に登録されるように構成しても良い。この構成によれば、ユーザは、後から、自己の移動通信端末ＭＴｍを用いて、携帯メールの受付設定「ＯＮ」、特定状態情報及び受付可能時間情報を登録することができる。

また、上記実施形態において、図６（Ｂ）に示すような受付設定画面１０２上に、携帯メールアドレスを入力する欄を設け、当該携帯メールアドレスが入力された後、ユーザが登録ボタン１０２ｃを指定した場合に、入力された携帯メールアドレスが、ＩＭサービス提供サーバＳＡに送信され、ユーザ情報データベース５１に登録されると共に、連携サーバＲＳのユーザ情報データベースにも登録されるように構成しても良い。この構成によれば、ユーザは上記特定の状態のときにメッセージを受け付ける携帯メールアドレスを簡単に変更することができる。

また、上記実施形態においては、２人のユーザ（ＮＮが「ａａａａａ」であるユーザと「ｂｂｂｂｂ」であるユーザ）がメッセージ交換を行う場合を例にとって説明したが、３人以上のユーザがメッセージ交換を行う場合にも適用できる。例えば３人のユーザがメッセージ交換を行う場合を以下に説明する。

例えば、上記ステップＳ１０１〜Ｓ１０５の処理を経て、ユーザ端末ＵＴ２において図７に示すようなチャットウインドウ画面１０３が表示された後、当該ユーザ端末ＵＴ２のユーザによるルームへの招待指示によりＮＮ「ｃｃｃｃｃ」であるユーザ（ユーザ端末ＵＴ３及び移動通信端末ＭＴ３のユーザ）が当該チャットルームに招待された場合、ｉ）招待されたユーザのＮＮ（又はユーザＩＤ）、ｉｉ）当該ユーザがメッセージを携帯メールで受付可能であるか否かを示す携帯メール受付可否情報、及びｉｉｉ）チャットウインドウＩＤが含まれるユーザ追加情報Ｉが連携サーバＲＳに送信される。

このユーザ追加情報Ｉを受信した連携サーバＲＳは、これに含まれる、上記招待されたユーザのＮＮ（「ｃｃｃｃｃ」）及び携帯メール受付可否情報を、既に記憶されていたチャットウインドウＩＤに対応付けて追加記憶する。

次いで、連携サーバＲＳは、上記招待されたユーザが、メッセージを携帯メールで受付可能であるか否かを、上記携帯メール受付可否情報に基づき判断し、受付可能でない場合には、ｉ）招待されたユーザのＮＮ（例えばｃｃｃｃｃ）、ｉｉ）携帯チャット開設者のＮＮ（例えばｂｂｂｂｂ）、ｉｉｉ）携帯チャット参加者のＮＮ（例えばａａａａａ）、及びｉＶ）チャットウインドウＩＤが含まれるユーザ追加情報IIを、ＩＭサービス提供サーバＳＡに送信する。

このユーザ追加情報IIを受信したＩＭサービス提供サーバＳＡは、これに含まれる、上記招待されたユーザのＮＮ（例えばｃｃｃｃｃ）のプレゼンス情報をユーザ情報データベース５１から参照し、例えば「オンライン」の状態である場合には、当該招待されたユーザのユーザ端末ＵＴ３に、上記ユーザ追加情報IIを転送する（「オンライン」でなければ、例えば「オンライン」になったときに転送）。

このユーザ追加情報IIを受信したユーザ端末ＵＴ３は、上記ステップＳ１０１と同様、ブラウザ起動により図７に示すようなチャットウインドウ画面１０３を表示する。そして、例えば、ユーザ端末ＵＴ２から送信され、連携サーバＲＳに保存（上記ステップＳ１０８）されたメッセージの内容は、ユーザ端末ＵＴ３からのチャットウインドウ更新要求（定期的に、或いは、連携サーバＲＳからＩＭサービス提供サーバＳＡを経由してメッセージ保存通知があったときに）に応じて、メッセージ通知に含まれて連携サーバＲＳからユーザ端末ＵＴ３に送信され、チャットウインドウ画面上に表示（ＮＮと共にこれに対応付けられて表示）される。この場合のメッセージ通知に係るデータには、図１１（Ｅ）に示す内容に加え、当該メッセージの送信元のユーザのＮＮ（例えばｂｂｂｂｂ）が含まれることになる。一方、例えば移動体通信端末ＭＴ１から返信された返信メールに含まれるメッセージの内容は、上記ステップＳ１１５〜ステップＳ１２０と同様の処理により、メッセージ通知に含まれて連携サーバＲＳからユーザ端末ＵＴ３に送信され、チャットウインドウ画面上に表示されることになる。この場合のメッセージ通知に係るデータにも、図１１（Ｅ）に示す内容に加え、当該携帯メールの送信元のユーザのＮＮ（例えばａａａａａ）が含まれることになる。

他方、連携サーバＲＳが、上記ユーザ追加情報Ｉを受信し、上記招待されたユーザが、メッセージを携帯メールで受付可能である場合、つまり、上記招待されたユーザが特定の状態（例えば、「オフライン」の状態）にある場合には、上記ユーザ追加情報IIはＩＭサービス提供サーバＳＡには送信されない。この場合、例えば、ユーザ端末ＵＴ２から送信され、連携サーバＲＳに保存（上記ステップＳ１０８）されたメッセージの内容は、上記ステップＳ１０６〜ステップＳ１１２と同様の処理により、携帯メールに含まれて移動通信端末ＭＴ３に送信される（つまり、当該携帯メールは、移動通信端末ＭＴ１及びＭＴ３の複数に送信されることになる）。一方、例えば移動体通信端末ＭＴ１から返信された返信メールは、移動通信端末ＭＴ３に転送（つまり、上記招待されたユーザの携帯メールアドレス宛てに転送）される（このとき、上記ステップＳ１１５〜ステップＳ１２０の処理も行われるのはいうまでもない）。

以上のとおり、３人以上（４人、５人と増えても３人のときと同様に処理される）のユーザがメッセージ交換を行う場合においても、上記２人の場合と同様の効果を奏することができ、加えて、より利便性を向上させることができる。

また、上記実施形態においては、移動通信端末ＭＴｍとして、例えば携帯電話機やＰＨＳを適用することが望ましいが、その他、例えばＰＤＡ（Personal Digital Assistant）や携帯型パーソナルコンピュータ等を適用しても構わない。また、移動通信端末ＭＴｍとして例えば携帯型パーソナルコンピュータを適用する場合、無線ＬＡＮ（Local Area Network）によりネットワークＮＷに接続することができ、この場合、ゲートウェイサーバＧＳは不要となる。

また、上記実施形態においては、連携サーバＲＳがＷｅｂサーバ及びメールサーバとして機能し、ユーザ端末ＵＴｍからのＨＴＴＰＳメッセージを受信してこれを携帯メールに変換して携帯メールアドレス宛に送信するように構成したが、別の例として、連携サーバＲＳがメールサーバのみとして機能し、ユーザ端末ＵＴｍからは例えばＳＩＰに基づくメッセージが、ＩＭサービス提供サーバＳＡに送信され当該ＩＭサービス提供サーバＳＡから連携サーバＲＳに転送されるように構成し、当該連携サーバＲＳが、受信したメッセージを携帯メールに変換して上記携帯メールアドレス宛に送信するように構成しても良い。

本実施形態に係るメッセージ送受信システムＳの概要構成例を示す図である。 ＩＭサービス提供サーバＳＡの概要構成の一例を示すブロック図である。 ユーザ情報データベース５１における登録情報例を示す図である。 連携サーバＲＳの概要構成の一例を示すブロック図である。 ユーザ端末ＵＴｍの概要構成の一例を示すブロック図である。 ユーザ端末ＵＴ２のメッセンジャー機能により表示された、表示部１２における表示画面例を示す図である。 ユーザ端末ＵＴ２のユーザが、ユーザ端末ＵＴ１のユーザとメッセージの交換をする際の概念図である。 ＩＭサービス提供サーバＳＡのシステム制御部７における処理を示すフローチャートである。 ユーザ端末ＵＴｍのシステム制御部１７におけるメッセンジャーに係る処理を示すフローチャートである。 携帯チャット時における各端末及びサーバにおける処理及び情報のやり取りを示すシーケンス図である。 ユーザ端末ＵＴ２と連携サーバＲＳで送受信されるＨＴＴＰＳに基づくデータの形式及び内容を示す概念図である。

符号の説明

１，１１，２１ 操作部
２，１２，２２ 表示部
３，１３，２３ 通信部
４，１４，２４ ドライブ部
５，１５，２５ 記憶部
６，１６，２６ 入出力インタフェース部
７，１７，２７ システム制御部
７ａ，１７ａ，２７ａ ＣＰＵ
７ｂ，１７ｂ，２７ｂ ＲＯＭ
７ｃ，１７ｃ，２７ｃ ＲＡＭ
８，１９，２８ システムバス
１８ マイク付きヘッドホン
５１ ユーザ情報データベース
ＳＡ ＩＭサービス提供サーバ
ＲＳ 連携サーバ
ＧＳ ゲートウェイサーバ
ＭＳ メールサーバ
ＵＴｍ ユーザ端末
ＭＴｍ 移動通信端末
Ｓ メッセージ送受信システム
ＮＷ ネットワーク
ＭＷ 移動体通信網

Claims (6)

1. ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置と、
   夫々の前記端末装置におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信する状態情報送信手段と、電子メールアドレスを前記ユーザ毎に判別可能に記憶する記憶手段と、を有するサーバ装置と、
   を備えるメッセージ送受信システムであって、
   前記端末装置は、
   前記サーバ装置から送信されてきた前記状態情報を受信する状態情報受信手段と、
   前記状態情報が電子メールの受付対象とする特定の状態を示す他の前記端末装置のユーザに対してメッセージを送信する場合には、当該メッセージを前記第２のサーバ装置に送信するメッセージ送信手段と、
   を備え、
   前記サーバ装置は、
   前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信する電子メール送信手段を備えることを特徴とするメッセージ送受信システム。
2. ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置夫々におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信する状態情報送信手段を備えたサーバ装置において、
   電子メールアドレスを前記ユーザ毎に判別可能に記憶する記憶手段と、
   前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信する電子メール送信手段と、
   を備えることを特徴とするサーバ装置。
3. 請求項２に記載のサーバ装置において、
   当該サーバ装置は、第１のサーバ装置と第２のサーバ装置とにより構成され、当該第１のサーバ装置と当該第２のサーバ装置とはネットワークを介して接続されており、
   前記第１のサーバ装置は、前記状態情報送信手段を備え、
   前記第２のサーバ装置は、前記記憶手段と、前記電子メール送信手段を備えることを特徴とするサーバ装置。
4. 請求項３に記載のサーバ装置において、
   前記第２のサーバ装置は、前記他の端末装置のユーザが有する機器から前記電子メールに対して返信された電子メールを受信した場合には、当該電子メールを保存すると共に、当該電子メールを受信したことを示す電子メール受信情報を前記第１のサーバ装置に送信し、
   前記第１のサーバ装置は、前記第２のサーバ装置からの前記電子メール受信情報を受信した場合には、当該電子メール受信情報を前記メッセージ送信元の端末装置に対して送信し、
   前記端末装置は、前記第１のサーバ装置からの前記電子メール受信情報を受信した場合には、前記第２のサーバ装置に対してメッセージの要求を示す情報を送信し、
   前記第２のサーバ装置は、前記端末装置からの前記メッセージの要求を示す情報を受信した場合には、前記保存した電子メールに基づきメッセージを生成し、当該メッセージを端末装置に送信することを特徴とするサーバ装置。
5. 請求項２乃至４の何れか一項に記載のサーバ装置として機能させることを特徴とするサーバ処理プログラム。
6. ネットワークを通じて他の端末装置との間で、ユーザから指示されたメッセージの送受信を行うことが可能なメッセンジャー機能を有する複数の端末装置夫々におけるユーザの現在の状態を示す状態情報を当該ユーザ毎に管理し、少なくとも、前記ユーザの現在の状態の変更を検知したとき、当該ユーザの変更後の状態を示す状態情報を前記他のユーザの端末装置に送信するサーバ装置における情報提供方法であって、
   電子メールアドレスを前記ユーザ毎に判別可能に記憶し、
   前記端末装置から送信されてきた前記メッセージを受信したとき、当該受信したメッセージに基づき電子メールを生成し、当該電子メールを、当該他の端末装置のユーザの電子メールアドレス宛てに送信することを特徴とする情報提供方法。

Images