JP2008103779A - イベント発行サーバ - Google Patents

Abstract

【課題】情報を送信する送信側が受信側を意識することなく、情報を送信可能とする技術を提供することを課題とする。
【解決手段】イベントサーバ２、通信端末３、４は、ＳＩＰサーバ１に対して登録（ＲＥＧＩＳＴＥＲ）を行う。通信端末３、４は、イベントの種別を指定した上で、イベントサーバ２に対してイベントの発行要求（ＳＵＢＳＣＲＩＢＥ）を行う。携帯情報端末５が、電子メールをイベントサーバ２に送信すると、イベントサーバ２は、電子メールに含まれるキーワードを抽出し、イベントテーブル２３を参照して、イベント種別を特定する。そして、当該イベント種別を指定したイベント発行要求を行っている通信端末に対してイベントを発行する。
【選択図】図１

Description

本発明は、情報提供端末から送信されたメッセージなどの情報を、通信端末に配信する技術に関する。

電子メール、インスタントメッセンジャーなどのメッセージ送信ツールが存在する。これらのツールを利用することで、ＬＡＮの中で、あるいはインターネットを介してメッセージを交換することができる。

電子メールや、インスタントメッセンジャーでは、宛先のアカウントを指定することによって、相手に対してメッセージが送信される。たとえば、電子メールであれば、ユーザが、電子メールソフトを利用し、宛先欄に宛先アカウントを指定することで、電子メールが送信されることになる。

また、登録された複数のメンバーにメッセージを送信する場合がある。たとえば、アドレス帳にグループメンバリストを登録しておけば、宛先として、そのグループを指定することで、複数のメンバーに一斉にメッセージが送信されるのである。

特開２００２−２１７９３８号公報

上述したように、電子メールやインスタントメッセンジャーでは、宛先のアカウントを指定することで、指定した相手にメッセージが送信される。つまり、送信側が受信側を意識してメッセージ送信を行う形態である。

このような形態は、特定の宛先にメッセージを送る場合には必要な仕組みである。しかし、宛先を指定する必要がない場合、あるいは宛先を指定することが煩雑であるようなケースが存在する。たとえば、受信者が事前に特定されないようなケースあるいは受信者が多数であるケースであって、その受信者リストが頻繁に変更されるようなケースである。

そこで、送信側と受信側との間に、メッセージ交換を制御する中間的な存在を設ける方法が考えられる。つまり、メッセージの送信先を、送信側において制御する必要性が排除できれば、利便性の高いシステムが構築できると考えられる。

一般的に端末間の通信において、中間的な存在を利用する技術は存在する。特許文献１は、インターネットを越えて、異なるＬＡＮに接続された通信端末同士が通信を行うことを可能としている。この技術では、異なるＬＡＮに接続されている異なる通信端末が、それぞれゲートウェイを経由してインターネットに接続された中継サーバに対してログインし、中継サーバとの間でそれぞれ通信経路を確立するようにしている。そして、この通信経路を利用して、通信端末間でインターネットを越えて通信することを可能としている。この技術は、通信経路を確保するために中間的な装置を利用しているが、送信側は、やはり、受信側の端末を特定して通信を行うことになる。

そこで、本発明は前記問題点に鑑み、情報を送信する送信側が受信側を意識することなく、情報を送信可能とする技術を提供することを目的とする。

上記課題を解決するため、請求項１記載の発明は、アカウント情報を通信管理サーバに登録する手段と、前記通信管理サーバに登録されている通信端末から、前記通信管理サーバを介してイベント種別を指定したイベント発行要求を受信する手段と、情報提供端末から通知情報を受信する手段と、識別情報とイベント種別とを対応付けたイベントテーブルを参照し、受信した通知情報に含まれる識別情報に基づいて発行するイベント種別を特定し、当該イベント種別を指定したイベント発行要求を行っている通信端末に対して、対応するイベントを発行する手段と、を備えることを特徴とする。

請求項２記載の発明は、請求項１に記載のイベント発行サーバにおいて、さらに、通信端末に対して対応するイベントを発行した後、前記情報提供端末にイベント発行先情報を通知する手段、を備えることを特徴とする。

請求項３記載の発明は、請求項１または請求項２に記載のイベント発行サーバにおいて、さらに、識別情報に基づいて発行するイベント種別を特定したが、当該イベント種別を指定したイベント発行要求を行っている通信端末が存在しない場合には、その旨を前記情報提供端末に通知する手段、を備えることを特徴とする。

請求項４記載の発明は、請求項１ないし請求項３のいずれかに記載のイベント発行サーバにおいて、さらに、前記情報提供端末からの要求に応じて前記イベントテーブルの情報を前記情報提供端末に送信する手段、を備えることを特徴とする。

請求項５記載の発明は、請求項１ないし請求項４のいずれかに記載のイベント発行サーバにおいて、さらに、前記情報提供端末から受信した識別情報とイベント種別との対応の更新情報を前記イベントテーブルに反映させる手段、を備えることを特徴とする。

本発明のイベント発行サーバは、情報提供端末から通知情報を受信すると、通知情報に含まれる識別情報に基づいて発行するイベント種別を特定し、当該イベント種別を指定したイベント発行要求を行っている通信端末に対して、対応するイベントを発行する。これにより、情報を送信する情報提供端末においては、受信端末を意識する必要はない。情報の受信を希望する者が、希望する場所、希望するタイミングで、通信端末を利用してイベントの発行要求を行っておけば、自動的に、情報が通信端末に配信される。

また、イベント発行サーバは、通信端末に対してイベントを発行した後、情報提供端末にイベント発行先情報を通知するので、情報提供端末により情報を送信した者は、イベントの発行先を知ることができる。

また、イベントの発行先が存在しない場合には、その旨を情報提供端末に通知するので、情報提供端末により情報を送信した者は、自身が送信した情報により、イベントがいずれの端末にも発行されなかったことを知ることができる。

また、情報提供端末からの要求に応じてイベントテーブルの情報を返信し、あるいは、イベントテーブルの更新を行う。これにより、情報提供端末からイベントの配信ルールなどを管理することが可能である。

以下、図面を参照しつつ本発明の実施の形態について説明する。図１は、本実施の形態に係る通信システムの全体図である。この通信システムは、ネットワーク６に接続されたＳＩＰサーバ１、イベントサーバ２、通信端末３，４、携帯情報端末５とから構成されている。図では、ネットワーク６を単一のネットワークのように示しているが、このネットワーク６は単一のネットワークであってもよいし、複数のネットワークが接続されて構成されていてもよい。たとえば、通信端末３や通信端末４が、ＳＩＰサーバ１やイベントサーバ２とは離れた場所にある異なるネットワークに接続されていてもよい。

ＳＩＰサーバ１は、イベントサーバ２および通信端末３，４がＳＩＰ（Session Initiation Protocol）を利用した通信を行うときに、ＳＩＰメソッドやレスポンスなどを中継するプロキシーサーバとしての機能や、イベントサーバ２および通信端末３，４のアカウントを登録するＳＩＰレジストラサーバとしての機能を備えている。つまり、ＳＩＰサーバ１は、この通信システムの通信管理サーバとしての機能を備えている。

イベントサーバ２は、携帯情報端末５から電子メールなどのメッセージを受信し、メッセージに含まれるキーワードに応じて、通信端末３や通信端末４にイベントを発行するサーバである。

図２は、イベントサーバ２の機能ブロック図である。イベントサーバ２は、通信制御部２１とイベント発行部２２とイベントテーブル２３とを備えている。

通信制御部２１は、携帯情報端末５から電子メールやインスタントメッセージなどのメッセージを受信する機能を備える。また、通信制御部２１は、ＳＩＰサーバ１に対してアカウント登録を行うための登録要求（ＲＥＧＩＳＴＥＲ）を送信する機能を備える。

イベント発行部２２は、携帯情報端末５から受信した電子メールやインスタントメッセージなどのメッセージを解析し、そのメッセージからイベントテーブル２３に登録されているキーワードを抽出する機能を備える。さらに、イベント発行部２２は、イベントテーブル２３の登録内容に従い、キーワードと対応しているイベントを通信端末３や通信端末４に対して発行する機能を備えている。

イベントテーブル２３には、キーワードと発行するイベントの対応関係が記録されている。図３は、イベントテーブル２３の登録例を示す図である。このように、複数のキーワード（Keyword1〜Keyword4）が登録され、それぞれのキーワードにイベント（Event1〜Event4）が対応付けられて登録されている。

図４は、イベントテーブル２３の登録例のさらに具体的な例を示す図である。このイベントテーブル２３には、たとえば、「MESSAGE」、「REPORT」、「UPDATE」という３つのキーワードが登録されている。そして、「MESSAGE」というキーワードに対しては、電子メールの送信元のメールアドレス（つまり、情報発信者のメールアドレス）と、電子メールのメッセージの内容を通信端末（ＳＵＢＳＣＲＩＢＥＲ）に通知する、というイベントが対応付けられている。また、「REPORT」というキーワードに対しては、添付ファイルを通信端末に送信する、というイベントが対応付けられている。また、「UPDATE」というキーワードに対しては、UPDATEコマンドを通信端末に送信するというイベントが対応付けられている。

イベント発行部２２は、イベントサーバ２に対してイベントの発行要求を行っている通信端末に対してイベントを発行する。各通信端末３，４は、ＳＩＰのＳＵＢＳＣＲＩＢＥメソッドを利用することで、イベントサーバ２に対してイベントの発行要求を行うのである。この発行要求を行うと、ＳＵＢＳＣＲＩＢＥメソッドが有効となっている期間中、継続してイベントサーバ２から通信端末３，４に対してイベントが発行されるのである。

また、各通信端末３，４がイベントサーバ２に対して行うイベントの発行要求（ＳＵＢＳＣＲＩＢＥ）には、要求するイベントの種別が指定される。イベントサーバ２は、携帯情報端末５からメッセージを受信し、そのメッセージからキーワードを抽出することにより、対応するイベントを特定する。そして、イベントサーバ２は、特定されたイベントについて発行要求を行っている通信端末に対してイベントを発行するのである。

イベント発行部２２は、通信端末に対してイベントを発行すると、発行先の通信端末の情報を携帯情報端末５に送信する機能を備える。これにより、携帯情報端末５のユーザは、自身が送信したメッセージによって、どの通信端末にイベントが発行されたかを知ることができる。

また、イベント発行部２２は、携帯情報端末５から受信したメッセージにより特定されたイベントの発行先がない場合には、その旨を携帯情報端末５に送信する。つまり、イベントサーバ２は、抽出されたキーワードから対応するイベントを特定するが、その特定されたイベントを指定したイベント発行要求を行っている通信端末が現在存在しない場合には、その旨の通知を携帯情報端末５に送信するのである。これにより、携帯情報端末５のユーザは、自身が送信したメッセージにより、いずれの通信端末にもイベントが発行されなかったことを知ることができる。

イベント発行部２２は、また、携帯情報端末５からイベントテーブル２３の参照要求（クエリーメッセージ）を受信すると、これに応答して、イベントテーブル２３の情報を携帯情報端末５に送信する機能を備える。携帯情報端末５のユーザは、返信された情報を参照することで、キーワードと発行されるイベントとの対応関係を知ることができる。

また、イベント発行部２２は、携帯情報端末５から、登録要求（コンフィグメッセージ）を受信すると、この登録要求の内容に従い、イベントテーブル２３の情報を更新する機能を備える。たとえば、携帯情報端末５は、新しいキーワードとイベントの対応を追加指示することや、あるキーワードとイベントの対応を削除する指示を行うことができる。このように、携帯情報端末５からイベントテーブル２３の参照や、更新を行い、イベントテーブル２３を管理することが可能となっている。

図５は、ＳＩＰサーバ１の機能ブロック図である。ＳＩＰサーバ１は、図に示すように、通信制御部１１、アカウント情報データベース１２を備えている。

通信制御部１１の１つの機能は、ネットワーク６に接続されているイベントサーバ２や通信端末３，４から、アカウントの登録要求（ＲＥＧＩＳＴＥＲ）を受信し、これらサーバ、端末のアカウント情報をアカウント情報データベース１２に登録することである。たとえば、ＳＩＰサーバ１は、イベントサーバ２からアカウントの登録要求（ＲＥＧＩＳＴＥＲ）を受信し、イベントサーバ２のアカウント情報をアカウント情報データベース１２に登録する。

通信制御部１１は、他にも、イベントサーバ２や通信端末３，４から送信された様々なＳＩＰメソッドやレスポンスなどの通信データを他方のサーバや端末に中継する機能を備える。

以上の通り構成された通信システムにおける通信処理の流れについて、図６および図７の処理シーケンス図を参照しながら説明する。なお、図６は、ステップＳ１からステップＳ６までのシーケンスを示し、それに続くステップＳ７からステップＳ８までのシーケンスを示すのが図７である。

まず、イベントサーバ２が、ＳＩＰサーバ１に対してアカウントの登録要求（ＲＥＧＩＳＴＥＲ）を送信する（ステップＳ１）。図に示すように、ここでは、イベントサーバ２が、自身のアカウント（SIP:server@sip.srv）の登録要求を行う。ＳＩＰサーバ１は、ＯＫレスポンスをイベントサーバ２に返信し、イベントサーバ２のアカウントとイベントサーバ２のＩＰアドレスとを対応付けてアカウント情報データベース１２に登録する。

続いて、通信端末３が、ＳＩＰサーバ１に対してアカウントの登録要求（ＲＥＧＩＳＴＥＲ）を送信する（ステップＳ２）。図に示すように、ここでは、通信端末３が、自身のアカウント（SIP:subscriber1@sip.srv）の登録要求を行う。ＳＩＰサーバ１は、ＯＫレスポンスを通信端末３に返信し、通信端末３のアカウントとＩＰアドレスとを対応付けてアカウント情報データベース１２に登録する。

同様に、通信端末４が、ＳＩＰサーバ１に対してアカウント（SIP:subscriber2@sip.srv）の登録要求（ＲＥＧＩＳＴＥＲ）を送信する（ステップＳ３）。ＳＩＰサーバ１は、通信端末４のアカウントを登録する。

以上の処理により、イベントサーバ２、通信端末３、通信端末４がそれぞれＳＩＰサーバ１に対するアカウントの登録が完了する。これにより、これらサーバ、端末間で、ＳＩＰを利用した通信処理が可能となる。

次に、通信端末３が、ＳＩＰサーバ１を介してイベントサーバ２に対してＳＵＢＳＣＲＩＢＥメソッドを発行し、イベントの発行要求を行う（ステップＳ４）。このイベント要求には、イベントの種別も指定される。図の例では、通信端末３は、２つのイベント（Event1,Event2）を指定している。つまり、通信端末３は、指定した２つのイベント（Event1，Event2）が発生した場合に、その通知を要求するのである。なお、これらイベントは、図３で示したイベントテーブル２３の内容に対応している。ＳＩＰサーバ１は、イベントの発行要求の受領通知（ＡＣＣＥＰＴ）を送信する。

同様に、通信端末４が、ＳＩＰサーバ１を介してイベントサーバ２に対してＳＵＢＳＣＲＩＢＥメソッドを発行し、イベントの発行要求を行う（ステップＳ５）。通信端末４は、２つのイベント（Event2,Event3）を指定したイベントの発行要求を行っている。

次に、あるタイミングで、携帯情報端末５（Messaging-Client）からイベントサーバ２に対して電子メールあるいはインスタントメッセンジャーなどのツールを利用して、メッセージが送信される（ステップＳ６）。このメッセージには、Keyword1が含まれている。なお、キーワードは、Ｓｕｂｊｅｃｔに埋め込むようにしてもよいし、メッセージの本文やヘッダに埋め込むようにしてもよい。

イベントサーバ２は、Keyword1を含むメッセージを受信すると、イベント発行部２２が、イベントテーブル２３を参照して対応するイベントを特定する。図３に示すように、keyword1には、Event1が対応付けられているので、ここでは、イベント発行部２２によりEvent1が特定される。そして、ステップＳ４の発行要求で、通信端末３は、Event1を指定しているので、イベントサーバ２は、ＮＯＴＩＦＹメソッドにより、Event1を通信端末３に対して発行するのである（ステップＳ６．１）。たとえば、メッセージが通信端末３に送信される。あるいは、添付ファイルが通信端末３に送信される。

なお、通信端末４は、ステップＳ５でイベントの発行要求を行っているが、Event1は指定していないので、ここでは、通信端末４に対しては、イベントは発行されない。

イベントサーバ２は、通信端末３からＮＯＴＩＦＩＹメソッドに対するＯＫレスポンスを受け取ると、続いて、携帯情報端末５に対して、発行先情報のメッセージを送信する。つまり、どの通信端末にイベントを発行したかを携帯情報端末５に通知するのである。ここでは、図に示すように、通信端末３のアカウント（subscriber1@sip.srv）を指定したメッセージが送信されるのである。これにより、携帯情報端末５のユーザは、発信した情報により、どの通信端末にイベントが発行されたのかを即座に知ることができるのである。

また、別のあるタイミングで、携帯情報端末５からイベントサーバ２に対して電子メールあるいはインスタントメッセンジャーなどのツールを利用して、メッセージが送信される（ステップＳ７）。このメッセージには、Keyword2が含まれている。

イベントサーバ２は、イベントテーブル２３を参照し、Keyword2から対応するEvent2を特定する。そして、ステップＳ４およびステップＳ５の発行要求により、通信端末３および通信端末４は、Event2を指定しているので、イベントサーバ２は、ＮＯＴＩＦＹメソッドにより、Event2を通信端末３および通信端末４に対して発行するのである（ステップＳ７．１、ステップＳ７．２）。

イベントサーバ２は、通信端末３および通信端末４からＮＯＴＩＦＩＹメソッドに対するＯＫレスポンスを受け取ると、携帯情報端末５に対して、発行先情報のメッセージを送信する。ここでは、図に示すように、通信端末３のアカウント（subscriber1@sip.srv）と通信端末４のアカウント（subscriber2@sip.srv）とを指定したメッセージが送信されるのである。

さらに、別のあるタイミングで、携帯情報端末５からイベントサーバ２に対して、メッセージが送信される（ステップＳ８）。このメッセージには、Keyword4が含まれている。

イベントサーバ２は、Keyword4から対応するEvent4を特定する。ステップＳ４およびステップＳ５の発行要求において、通信端末３および通信端末４は、いずれもEvent4を指定していない。つまり、現在、Event4の発行要求を行っている通信端末が存在しない。したがって、イベントサーバ２は、携帯情報端末５に対して、発行先が存在しない旨のメッセージ（Not Found）を送信する。これにより、携帯情報端末５のユーザは、発信した情報により、イベントが発行されなかったことを即座に知ることができる。

このように、本発明によれば、情報を発信する携帯情報端末５においては、発信する情報をどの端末に送信するかを指定する必要はない。送信側である携帯情報端末５と、受信側である通信端末３，４との間にＳＩＰサーバ１およびイベントサーバ２が介在し、イベントサーバ２によって、情報の配信先が決定されるのである。したがって、携帯情報端末５においては、必要な情報を発信することだけを行えばよい。その情報を取得したいユーザは、通信端末を利用して、ＳＩＰサーバ１に対して登録要求を行い、イベントサーバ２に対してイベントの発行要求を行っておけばよいのである。

また、情報の取得を希望するユーザは、いずれの場所にいてもよい。情報を取得したい場所において、通信端末を利用してＳＩＰサーバ１に登録を行い、あわせてイベントサーバ２に対してイベントの発行要求を行っておけばよいのである。これにより、希望するときに、希望する場所で情報を得ることができ、利便性がよい。

さらに、従来のイベント通知手段では、相手が不在であるか、未読であるかなどを検知することはできなかったが、本発明のイベント発行サーバは、イベントの発行先情報を、情報の発信元に通知する。これにより、情報の発信者は、発信した情報が誰に利用されたかを知ることができる。

このように、受信端末がどの場所にいるかを送信側は意識する必要はない。たとえば、複数のユーザに定期連絡などを一斉送信する場合など、従来であれば、アカウントリストのメンテナンスが必要であった。本発明のシステムであれば、送信側は、アカウントリストを管理する必要はない。発信したい情報をイベントサーバ２にアップするだけでよいのである。後は、イベントサーバ２が、発行要求を行っている複数のユーザに対して自動的に、イベントを発行してくれるのである。

本実施の形態に係る通信システムのネットワーク構成図である。 イベントサーバの機能ブロック図である。 イベントテーブルの登録例を示す図である。 イベントテーブルの具体的な登録例を示す図である。 ＳＩＰサーバの機能ブロック図である。 通信処理のシーケンス図である。 通信処理のシーケンス図である。

符号の説明

１ ＳＩＰサーバ
２ イベントサーバ
３ 通信端末
４ 通信端末
５ 携帯情報端末
２３ イベントテーブル

Claims (5)

1. アカウント情報を通信管理サーバに登録する手段と、
   前記通信管理サーバに登録されている通信端末から、前記通信管理サーバを介してイベント種別を指定したイベント発行要求を受信する手段と、
   情報提供端末から通知情報を受信する手段と、
   識別情報とイベント種別とを対応付けたイベントテーブルを参照し、受信した通知情報に含まれる識別情報に基づいて発行するイベント種別を特定し、当該イベント種別を指定したイベント発行要求を行っている通信端末に対して、対応するイベントを発行する手段と、
   を備えることを特徴とするイベント発行サーバ。
2. 請求項１に記載のイベント発行サーバにおいて、さらに、
   通信端末に対して対応するイベントを発行した後、前記情報提供端末にイベント発行先情報を通知する手段、
   を備えることを特徴とするイベント発行サーバ。
3. 請求項１または請求項２に記載のイベント発行サーバにおいて、さらに、
   識別情報に基づいて発行するイベント種別を特定したが、当該イベント種別を指定したイベント発行要求を行っている通信端末が存在しない場合には、その旨を前記情報提供端末に通知する手段、
   を備えることを特徴とするイベント発行サーバ。
4. 請求項１ないし請求項３のいずれかに記載のイベント発行サーバにおいて、さらに、
   前記情報提供端末からの要求に応じて前記イベントテーブルの情報を前記情報提供端末に送信する手段、
   を備えることを特徴とするイベント発行サーバ。
5. 請求項１ないし請求項４のいずれかに記載のイベント発行サーバにおいて、さらに、
   前記情報提供端末から受信した識別情報とイベント種別との対応の更新情報を前記イベントテーブルに反映させる手段、
   を備えることを特徴とするイベント発行サーバ。

Images