(57)【要約】  本発明のメッセージ配信システムはサーバ（１０）と複数の端末（２０）とからなる。端末（２０）は、登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部（２２）と、任意の場所を指定して指定場所とし、指定場所に入る登録グループのメンバにメッセージを配信するようにサーバに依頼するメッセージアタッチ機能部（２４）とを有する。サーバ（１０）は、指定場所に登録グループのメンバが入っているか否かを監視する在圏監視機能部と、指定場所に最初に入ったグループのメンバに対して、メッセージを配信し、当該メンバがメッセージの受諾を拒否した場合、次に指定エリアに入った登録グループの他のメンバに対して、メッセージを配信するメッセージ配信機能部とを有する。
2009019790.tif 000002
【特許請求の範囲】
【請求項１】
登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、
任意の場所を指定して指定場所とし、該指定場所に入る前記登録グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部と
を有する複数の端末と、
前記指定場所に前記登録グループのメンバが入っているか否かを監視する在圏監視機能部と、
前記指定場所に最初に入った前記登録グループのメンバに対して、前記メッセージを配信し、当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部と
を有するサーバと、
を備えることを特徴とするメッセージ配信システム。
【請求項２】
前記端末のメッセージ配信依頼機能部は、前記登録グループのメンバに前記メッセージを配信する期間を指定することを特徴とする請求項１に記載のメッセージ配信システム。
【請求項３】
前記端末は、グループを作成して、作成されたグループの登録を前記サーバに依頼するグループ作成登録依頼機能部を備え、前記サーバは、前記グループ作成登録依頼機能部からの依頼により、前記作成されたグループの登録を受け付けるグループ登録受付手段を備えることを特徴とする請求項１または２に記載のメッセージ配信システム。
【請求項４】
前記メッセージが配信されたメンバは、メッセージを受諾した後も、該メッセージの受諾を拒否することができるように構成されることを特徴とする請求項１〜３のいずれか１項に記載のメッセージ配信システム。
【請求項５】
前記メッセージが配信されたメンバがメッセージの受諾を拒否した後、他のメンバが当該メッセージを受諾していない期間であれば、前記メッセージの受諾を拒否したメンバは当該メッセージを受諾することができるように構成された請求項１〜４のいずれか１項に記載のメッセージ配信システム。
【請求項６】
前記グループ内メンバからのみメッセージ配信依頼を行えるように構成されていることを特徴とする請求項１〜５のいずれか１項に記載のメッセージ配信システム。
【請求項７】
前記メッセージ配信依頼時には、本人認証を必要とするように構成されていることを特徴とする請求項１〜６のいずれか１項に記載のメッセージ送信システム。
【請求項８】
前記グループの所定メンバは、前記メッセージ配信依頼機能部により配信依頼されたメッセージを配信前に閲覧できるように構成されていることを特徴とする請求項１〜７のいずれか１項に記載のメッセージ配信システム。
【請求項９】
指定場所に登録グループのメンバが入っているか否かを監視し、
前記指定場所に最初に入った前記指定グループのメンバに対して、メッセージを配信し、
当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信する
ことを特徴とするメッセージ配信方法。
【請求項１０】
前記メッセージは、指定された期間に前記指定グループのメンバに配信することを特徴とする請求項９に記載のメッセージ配信方法。
【請求項１１】
前記メッセージが配信されたメンバは、メッセージを一旦受諾した後であっても、該メッセージの受諾を拒否することができることを特徴とする請求項９または１０に記載のメッセージ配信方法。
【請求項１２】
前記メッセージが配信されたメンバが前記メッセージの受諾を拒否した場合、他のメンバが当該メッセージを受諾していない期間であれば、前記メッセージの受諾を拒否したメンバは当該メッセージを受諾することができる請求項９〜１１のいずれか１項に記載のメッセージ配信方法。
【請求項１３】
登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、
任意の場所を指定して指定場所とし、該指定場所に入る前記登録グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部と
を有することを特徴とする端末。
【請求項１４】
前記メッセージ配信依頼機能部は、前記グループのメンバに前記メッセージを配信する期間を指定することを特徴とする請求項１３に記載の端末。
【請求項１５】
グループを作成して、作成されたグループの登録を前記サーバに依頼するグループ作成登録依頼機能部を備えることを特徴とする請求項１３または１４に記載の端末。
【請求項１６】
指定場所に登録グループのメンバが入っているか否かを監視する在圏監視機能部と、
前記指定場所に最初に入った前記登録グループのメンバに対して、メッセージを配信し、当該メンバが前記メッセージを差し戻した場合、次に前記監視エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部と
を有することを特徴とするサーバ。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メッセージ送受信システムに関し、特に移動体通信を用いるメッセージ送受信システムに関する。
【背景技術】
【０００２】
PDC (Personal Digital Cellular)、GSM（Global System for Mobile communications）あるいはWCDMA (Wideband Code Division Multiple Access)やCDMA20001X （Code Division Multiple Access 2000X）などの３G（3rd Generation）に代表される移動体通信システムにおいても、電子メールは重要な通信手段である。【０００３】
電子メールに関するプロトコルであるTCP/IP（Transmission Control Protocol / Internet Protocol）上の仕様では、ユニークな単一アドレスに対して単一のユーザをバインドして、メールアドレスとしている。また、ユニークな単一アドレスに対して複数のユーザのアドレスをバインドして、ユニークな単一アドレスを代表アドレスとするメーリングリストを作成することもできる。【０００４】
メールアドレスをもつ場合、メッセージ送信者はそのアドレス宛てにメッセージを送信することのより、所望の相手、正確にはメッセージ受信者がアカウントを持つPOPサーバに、メッセージを送り届けることができる。さらに、送信時に複数のアドレスを指定する事で複数の相手に同時メールを送信する事ができる。【０００５】
メーリングリストが作成されている場合、メーリングリストに与えられた代表アドレスにメッセージを送信するだけで、メーリングリストのメンバ全員にメッセージを送り届けることができる。メールアドレスあるいはメーリングリストに対する電子メールの機能は、OS（Operation System）を搭載したコンピュータあるいはPDA（Personal Digital Assistant）のみならず、携帯電話にも一機能として具備されており、ユーザは時間・場所を選ばずに電子メールによるメッセージの送信が可能となっている。【０００６】
例えば携帯電話を利用し、かつメーリングリストを利用すれば、時間や場所を選ばずに複数の人間に対して比較的効率的にメッセージを送信することができる。また、メーリングリストに含まれるメンバーを抽出する条件を入力する事により、限定されたメンバーにメッセージを送信することもできる。【０００７】
しかし、複数のメンバーに対して、メンバーのだれか一人あるいは数人がしてくれればよいという仕事を依頼したい場合、メーリングリストがあってもうまくいかないことがある。【０００８】
例えば、ユーザＸを含む家族全員がメーリングリストのメンバであるとする。このとき、家にいるユーザＸが、最寄の駅から帰宅する予定の家族内の誰か、すなわちメーリングリストのメンバのうちの一人に対して、最寄りの駅から家までのある経路中に存在する商店で買い物をしてきてもらいたいということがある。このとき、メーリングリストで全員に周知すると、誰が買うのかを決定するために、全員の意思の疎通が必要になる。また、意思疎通が不十分であると買い物が重複することもある。さらに、譲りあって誰も買って来ないということもありうる。さらに、メーリングリスト中の買い物の実行が確実に不可能なメンバにもメールを送信しなければいけないということもあり、無駄なトラヒックが発生することがある。このような無駄なトラヒックの発生を避けるために、メーリングリストを使用しないで、一人ひとりにメッセージを送信することも可能であるが、非効率である。【０００９】
この例から分るように、複数人のうち誰か一人が用件を受諾すればよい場合、用件を一つのメッセージ送信で済ませるのは、現状の仕組みでは不可能である。【００１０】
なお、電子掲示板の存在や自己宛のメッセージの存在に気がつかずに通りすぎてしまうことのないように、所定エリアに進入した利用者を特定して、この利用者に所定のアクションを行って、自己宛のメッセージの存在に気がつかせるコミュニケーション装置が公知であるが、本発明が問題とする課題および課題解決手段についてはなんら記載されていない（特許文献１参照）。【００１１】
【特許文献１】特開２００５−２５３００６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は、上記の問題に鑑み、グループの誰かが実行すればよい用件の受諾を各メンバの予定や意思による決定に委ね、メンバ間の調整をせずに依頼された用件を処理できるメッセージ配信システムおよび方法を提供すること、さらにはサーバと端末を提供することを目的とする。
【課題を解決するための手段】
【００１３】
上記課題を解決するために、本発明の第1の態様であるメッセージ配信システムは、登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、任意の場所を指定して指定場所とし、該指定場所に入る前記登録グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部とを有する複数の端末と、前記指定場所に前記登録グループのメンバが入っているか否かを監視する在圏監視機能部と、前記指定場所に最初に入った前記登録グループのメンバに対して、前記メッセージを配信し、当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部とを有するサーバと、を備えることを特徴とする。【００１４】
前記端末のメッセージ配信依頼機能部は、前記登録グループのメンバに前記メッセージを配信する期間を指定することができる。【００１５】
前記端末は、グループを作成して、作成されたグループの登録を前記サーバに依頼するグループ作成登録依頼機能部を備え、前記サーバは、前記グループ作成登録依頼機能部からの依頼により、前記作成されたグループの登録を受け付けるグループ登録受付手段を備えることができる。【００１６】
本発明の第２の態様であるメッセージ配信方法は、指定場所に登録グループのメンバが入っているか否かを監視し、前記指定場所に最初に入った前記指定グループのメンバに対して、メッセージを配信し、当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信することを特徴とする。【００１７】
また、前記メッセージが配信されたメンバは、メッセージを一旦受諾した後であっても、該メッセージの受諾を拒否することができるようにしてもよい。【００１８】
さらに、前記メッセージが配信されたメンバが前記メッセージの受諾を拒否した場合、他のメンバが当該メッセージを受諾していない期間であれば、前記メッセージの受諾を拒否したメンバは当該メッセージを受諾することができるようにしてもよい。【００１９】
本発明の第３の態様である端末は、グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、任意の場所を指定して指定場所とし、該指定場所に入る前記グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部とを有することを特徴とする。【００２０】
本発明の第３の態様であるサーバは、指定場所に登録グループのメンバが入っているか否かを監視する在圏監視機能部と、前記指定場所に最初に入った前記登録グループのメンバに対して、前記メッセージを配信し、当該メンバが前記メッセージの受諾を拒否した場合、次に前記監視エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部と、を有することを特徴とする。
【発明の効果】
【００２１】
本発明によれば、グループの誰かが実行すればよい用件の受諾を各メンバの予定や意思による決定に委ね、メンバ間の調整をせずに依頼された用件を処理できる。
【図面の簡単な説明】
【００２２】
【図１】本実施形態によるサーバと複数の通信端末を含むメッセージアタッチサービスシステムを示す図である。
【図２】本実施形態のサーバの状態遷移を示す図である。
【図３】本実施形態によるグループ登録を実行するフローを示す図である。
【図４】メッセージアタッチ後に監視状態に遷移する本実施形態の動作フローを示す図である。
【図５】監視エリアに存在が確認されたユーザにメッセージを配信する本実施形態の動作フローを示す図である。
【図６】メッセージを受信したユーザが当該メッセージの受諾を拒否する場合の本実施形態の動作フローを示す図である。
【図７】メッセージを受信したユーザが当該メッセージを受諾する場合の本実施形態の動作フローを示す図である。
【図８】一旦メッセージの受諾を拒否した後に、当該メッセージを受諾する場合であって、サーバが監視状態にある場合の本実施形態の動作フローを示す図である。
【図９】一旦メッセージの受諾を拒否した後に、当該メッセージを受諾する場合であって、サーバがメッセージ配信状態にある場合の本実施形態の動作フローを示す図である。
【図１０】一旦メッセージを受諾した後に、当該メッセージの受諾を拒否する場合の本実施形態の動作フローを示す図である。
【発明を実施するための最良の形態】
【００２３】
以下、図面を参照して本発明の実施の形態を説明する。図１に示すように、本実施形態のメッセージ送受信システムは、携帯電話、ＰＤＡあるいはパーソナルコンピュータなどの電子メール機能を有する複数の端末（以下、「通信端末」という。）２０と、複数の通信端末２０と通信可能で本実施形態によるサービスを行うサーバ１０とを含む。図１では、３台の通信端末２０を示すが、通信端末の個数は任意であり、サーバ１０は、任意の個数の通信端末に対応可能である。【００２４】
本実施形態の通信端末２０は、通信端末２０のユーザが登録されているグループに対するメッセージを、受信する場所を指定して送信することができるメッセージアタッチモジュール２１を備えている。メッセージアタッチの用語は、本実施形態によるメッセージが指定された場所でのみ受信されることから、指定された場所にメッセージが付与すなわちアタッチされることを表現している。メッセージアタッチモジュール２１は、通信端末２０上で動作するソフトウェアであるメッセージアタッチアプリケーションにより実現される。メッセージアタッチアプリケーションは、通信端末２０のメモリ（図示せず）に読み込まれ、通信端末２０のＣＰＵ（Central Processor Unit）（図示せず）を動作させる。メッセージアタッチモジュール２１の動作については、後に説明する。【００２５】
メッセージアタッチモジュール２１は、メッセージを作成する機能を有するメッセージ作成機能部２２と、グループを作成して、サーバに登録する機能を有するグループ作成・登録機能部２３と、メッセージを指定したエリアに付与するメッセージアタッチ機能を有するメッセージアタッチ機能部２４と、サーバ１０から配送されるメッセージを受信して返信するなどのメッセージ制御機能を有するメッセージ制御部２５を備えている。【００２６】
また、サーバ１０は、通信端末２０からの要求に従って行うメッセージサービスを実行管理するメッセージ管理モジュール１１を備えている。以下、メッセージ管理モジュール１１が行うメッセージサービスをメッセージアタッチメントサービスという。メッセージ管理モジュール１１は、サーバ用アプリケーションであるメッセージ管理アプリケーションにより実現される。メッセージ管理部１１は、サーバ１０のメモリ（図示せず）に読み込まれ、サーバ１０のＣＰＵ（Central Processor Unit）（図示せず）を動作させる。メッセージ管理モジュール１１の動作については、後に説明する。【００２７】
メッセージ管理モジュール１１は常時起動され、通信端末２０のメッセージアタッチモジュール２１が要求するサービスを提供可能である。メッセージ管理モジュール１１は、指定場所あるいは指定エリアに入るメンバの通信端末２０にメッセージを配送する機能を有するメッセージ配送機能部１２と、通信端末２０のグループ作成・登録機能部２３により作成・登録されるグループの登録を受け付ける機能を有するグループ登録受付機能部１３と、登録されたグループとそのメンバを管理する機能を有する登録グループ管理機能部１４と、指定エリア内にグループのメンバの通信端末２０が入っているか否かを監視する機能を有する端末在圏監視機能部１５とを備える。【００２８】
図２は、サーバの状態の遷移を示す図である。サーバ１０の状態としては、通信端末２０からのサービスの依頼を待つ依頼待ち状態３１、通信端末からのグループの登録を受け付ける登録受付状態３２、通信端末の在圏監視を行う監視状態３３、通信端末にメッセージを配信する配信状態３４がある。【００２９】
以下、サーバが、１つの状態から他の状態へ遷移する主要な場合を説明する。依頼待ち状態３１は、通信端末２０からの依頼を待っている状態で、通信端末２０からのグループ登録依頼があれば、登録受付状態３２に遷移する。登録受付状態３２は、サーバによる登録受付処理が終了すると、依頼待ち状態３１に遷移する。【００３０】
また、登録受付状態３１にあるサーバが、通信端末２０からある場所を指定してグループに対するメッセージ配信の依頼を受けると、指定された場所にグループのメンバが立ち入ることを監視する監視状態３３に遷移する。監視状態３３は、指定された場所にグループのメンバが立ち入ったことを確認して、メッセージ配信状態３４に遷移する。なお、監視状態３３から依頼待ち状態３１に遷移する場合は、メッセージを一旦差し戻したメンバがその後当該メッセージを受諾するような場合である。【００３１】
メッセージ配信状態３４にあるサーバ１０は、指定場所に立ち入ったメンバにメッセージを配信して、当該メッセージを受信したメンバがメッセージを受諾した場合に、依頼待ち状態３１に遷移する。当該メッセージを受信したメンバがメッセージを差し戻した場合には、さらに監視を続行する必要があるので、監視状態３３に遷移する。【００３２】
次に、図３〜１０を参照して、本実施形態の動作を説明するが、図においてユーザＡ〜Ｅは、本実施形態の通信端末２０をもつユーザを示す。【００３３】
（グループ作成、登録）
図３は、ユーザがグループを作成してグループ登録依頼を行ってから登録するまでの動作を示す図である。図３では、グループ作成者はユーザＡとする。ユーザＡは、グループ登録依頼をする前に、ユーザＡの通信端末２０のグループ作成・登録機能部２３を用いて、メッセージを送る対象であるグループを作成する。グループとしては、例えば家族、会社の部課、スポーツクラブの会員、ボランティアのグループなどを含め任意のグループを作成することができる。【００３４】
本実施形態では、グループあるいはグループのメンバのセキュリティを確保するために、作成するグループに対して属性を設定することができる。属性としては、例えば次ぎの（１）〜（３）のような属性がある。
（１）グループに対しては、グループ内メンバからのみメッセージを送信可能とする。
（２）メッセージを指定エリアにアタッチする時、あるいはメンバ情報を閲覧する時にはユーザ認証を必要とする。
（３）グループの代表者、責任者あるいはグループ作成者は、そのグループに宛てたメッセージを事前に閲覧でき、そのメッセージをグループに送信させる前に破棄することができる。【００３５】
グループ作成時に、項目（１）の属性を設定した場合、グループに属さないユーザからのメッセージアタッチを拒否することができる。項目（１）の属性を設定しない場合は、メンバではないグループ外のユーザであっても、メッセージアタッチメントサービスに加入していれば、このグループに対してメッセージアタッチメントサービスを利用できることになる。【００３６】
グループ作成時に、項目（２）の属性を設定した場合、ユーザが指定エリアにメッセージをアタッチしようとする時に、サーバからパスワードを要求される。パスワードはサーバからのグループメンバ登録確認受信時に、ユーザの通信端末のメッセージアタッチ部のメッセージ制御機能部を用いて設定することができる。ユーザ認証は、このパスワードを用いて行われる。ユーザ認証に成功すると、ユーザはメッセージをアタッチできる。言い換えれば、サーバはメッセージアタッチを受け付ける。【００３７】
また、サーバに格納されているグループメンバの情報を閲覧するためには、ユーザは、メッセージアタッチモジュール２１のメッセージ制御機能部２５を用いて、グループメンバの情報の閲覧をサーバ１０に依頼する。なお、グループメンバの情報の閲覧は、サーバ１０がどのような状態であっても可能である。ここで、項目（２）の属性を設定している場合は、グループメンバ情報閲覧依頼を受信したサーバ１０は、依頼元ユーザにパスワードを要求し本人認証を実行する。依頼元ユーザの本人認証に成功すると、サーバはグループメンバ情報であるグループ全メンバのアドレスとそのＩＤを依頼元ユーザに送信する。【００３８】
グループ作成時に、項目（３）の属性を設定した場合、メッセージが指定エリアにアタッチされた後、サーバはアタッチされたメッセージをグループの代表者に送信する。グループの代表者は、グループの代表者の通信端末２０が有するメッセージアタッチモジュール２１のメッセージ制御機能部２５によりこれを確認し、可否の判断をする。グループの代表者によって拒否された場合、メッセージは破棄され、サーバはメッセージ送信者にその旨を通知する。この場合、サーバ１０は依頼待ち状態から遷移しない。グループの代表者から許可が下りると、サーバはメッセージアタッチメントサービスの処理を始める。【００３９】
これらの項目は、個別に選択することができる。グループ作成者は、グループを作成する際に、選択した項目を属性として設定することができる。なお、グループに対して設定される属性は、これらに限定されることはない。必要であれば、他の属性を設定可能とすることもできる。【００４０】
図３のユーザＡは、自分の通信端末２０のグループ作成・登録機能部２３により、まず所望のメンバを選択してグループを作成する。例えばユーザＡは、既知のアドレスを集めることによって、グループを作成できる。次に、ユーザＡは、グループの登録依頼をサーバ１０へ送信する（Ｓ１１）。サーバ１０では、メッセージサービス提供者がメッセージ管理モジュールを予め起動しているので、サーバ１０はすでに、依頼待ち状態３１に遷移している。サーバ１０がユーザＡからグループ作成依頼を受信すると、別のプロセスあるいは子プロセスを立ち上げて登録受付状態３２に遷移する（Ｓ１２）。なお、本実施形態では、サーバ１０の親プロセスは常に依頼待ち状態にあり、他の状態に遷移する場合は別プロセスを起動するようになっている。【００４１】
サーバ１０が登録受付状態３２に遷移すると、サーバ１０のグループ登録受付機能部１３により、登録が依頼されているグループのメンバとして参加が期待されているユーザＢ〜Ｄに対して、グループの登録依頼があったこととそのグループの属性を知らせるメッセージを配信する（Ｓ１３）。【００４２】
ユーザＢ〜Ｄは、各ユーザの通信端末２０のメッセージ制御機能部２５により、グループの登録依頼のメッセージを受信する。次いで、ユーザＢ〜Ｄは、作成されるグループのメンバ、グループの属性などを考慮して、クループへの参加可否を判断してサーバに返信することにより、登録確認を行う（Ｓ１４）。【００４３】
グループへの参加を拒否すれば、そのユーザはグループのメンバにはならない。グループのメンバとして登録を容認する場合、自分のＩＤ（Identification Data）を設定してサーバに返信する。ＩＤは、登録されたメンバのアドレスに対してバインドされる有一のバインド情報である。メンバとなるユーザが、他のメンバにアドレスの保有者であることを知らせたい場合などには、ＩＤに名前やニックネームを設定することができる。【００４４】
グループのメンバとして期待される全ユーザの登録確認が完了した後、登録結果がグループ作成者に送信される（Ｓ１５）。グループは、二人以上がメンバとなる事を認めることによって成立する。サーバは、登録されたグループおよびそのメンバを管理する登録グループ管理機能部１４を用いて、独自のデータベース内にグループとそのメンバを登録する（Ｓ１６）。登録が終了すれば、サーバは、別起動した登録受付のためのプロセスを終了し、登録受付状態３２から依頼待ち状態３１に遷移する（Ｓ１７）。【００４５】
（グループに対するメッセージの作成と指定場所へのアタッチ）
図４は、メッセージの作成と指定場所へのメッセージのアタッチメントの動作を説明する図である。グループがサーバに登録されると、グループに対してメッセージを送信することが可能になる。前記の属性（１）（２）を設定していると、グループに対してメッセージを送信できるのは、グループ内メンバに限定することができる。また、メッセージを送信する際に本人認証を必要とするようにができる。図４では、一例としてグループの一員であるユーザＢがメッセージ送信者であるとする。メッセージ送信者であるユーザＢは、ユーザＢの通信端末２０に備わるメッセージアタッチモジュール２１のメッセージ作成機能部２２を用いてメッセージを作成する（Ｓ２１）。メッセージは、Mpeg4やAVIなどの動画、jpeg、pngなどの静止画、音声、テキストいずれのメディアであってもよい。メッセージ作成機能部２２を用いて、任意のメディアを変換して一つのメッセージにまとめることができる。【００４６】
ユーザＢは、次いでメッセージアタッチ機能部２４を用いて、作成したメッセージを指定場所あるいは指定エリアにアタッチすなわち付与する。ここで、メッセージアタッチ機能は、当該メッセージに対してグループと場所あるいはエリアとを指定して、指定場所に最初に入ったグループのメンバに当該メッセージを配信するものである。例えば、指定場所を駅とすると、その駅に最初に到着したメンバにメッセージを配信して何らかの依頼を行うことができる。また、指定場所をある地域とすると、その地域に最初に入ったメンバに何らかの依頼を行うことができる。なお、指定場所にすでにグループのメンバが複数いる場合、あるいは同時に複数のメンバが指定場所に入ったような場合は、そのうちの一人のメンバに対してメッセージが配信される。この場合のメッセージを配信するメンバの選択は、ランダムに行ってもよいし、予め順番を指定しておいてその順番に従って行ってもよい。【００４７】
メッセージをアタッチする場所は、メッセージのアタッチを希望するユーザＢの通信端末２０の表示画面に表示される地図のイメージより選択することができる。例えば、地図上の任意の位置を任意の入力手段でマーキングして、マーキングポイントを設定することにより指定場所を選択することができる。また、地図から選択することに代えて、ユーザＢの通信端末２０で住所を直接入力することによっても指定することができる。通信端末２０の表示画面上に表示される地図のイメージには、現在地がデフォルトで表示される。したがって、現在地をアタッチ場所として特定する場合には、デフォルトのままアタッチ指定することにより現在地をアタッチする場所として指定することができる。現在地以外の他の場所を指定する場合は、他の場所を表示する地図を通信端末の画面に表示させて行う。メッセージをアタッチする場所の指定とともに、アタッチする期間、すなわちアタッチされたメッセージを配信開始する日時と配信終了する日時を送信許容時間として指定することもできる。送信許容時間を指定することにより、指定期間に指定場所に入るグループのメンバに対してのみメッセージを配信することができる。また、アタッチされたメッセージを配信する複数のメンバをグループのメンバから選択して指定することもできる。メッセージを配信するメンバを指定した場合には、グループの他のメンバが指定場所に入ったとしても、指定されていないメンバにはメッセージは配信されない。【００４８】
ユーザＢがメッセージアタッチ機能部２４を用いて、メッセージの指定場所へのアタッチを実行すると、メッセージの送信先グループあるいはグループの指定されたメンバ、メッセージ送信が可能となる送信許容時間、メッセージ本体及びメッセージがアタッチされる指定場所の位置情報がサーバ１０に送られる（Ｓ７）。サーバ１０は、それらの情報を受信すると、最初にメッセージ送信許容時間をチェックする。【００４９】
メッセージ送信開始時間になっていない場合は、サーバ１０はそのまま依頼待ち状態を続ける。メッセージ送信開始時間になったら、あるいはアタッチ依頼時にすでに開始時間になっていると、サーバ１０は在圏監視のためのコプロセスあるいは別プロセスを起動して、監視状態３３に遷移する（Ｓ２２）。ここで、前記の属性（３）を設定して、サーバ１０は、配信依頼されたメッセージを当該グループの代表者に閲覧させることができ、代表者の許可を得て監視状態に遷移するようにもできる。これにより、指定場所内にグループのメンバが存在するか否かを監視する在圏監視が動作して、指定された位置情報と一致する場所あるいはエリアを監視する。なお、通常は指定場所あるいは指定エリアは監視エリアと等しい。しかし、監視エリアを指定エリアより広くすることも可能である。【００５０】
（指定場所に入ったメンバへのメッセージの配信）
図５は、サーバが在圏監視状態からメッセージ配信状態に遷移して、メッセージを配信する動作を説明する図である。サーバは、メッセージ送信許容時間内に監視中の指定場所あるいは指定エリアに最初に指定されたグループのメンバが入ったことを確認する（Ｓ３１）。図５では、監視中の指定エリアに最初に入ったメンバは、ユーザＡである。指定エリアにメンバを確認すると、サーバはメッセージ配信状態３４に遷移する（Ｓ３２）。そして、サーバ１０のメッセージ配送機能部により、指定エリア内に入ったメンバであるユーザＡに対して、送信者からのメッセージとメッセージ送信許容時間を配信する（Ｓ３２）。メッセージ送信許容期間をユーザＡに知らせるのは、メッセージ送信許容期間を過ぎれば、メッセージアタッチメントサービスが終了し、メッセージを受けたメンバが返信することができなくなるからである。なお、後に説明するように、一旦受諾されたメッセージが差し戻された場合もサーバが在圏監視状態に遷移している。この場合も、メッセージが差し戻された後最初にメンバが入ったことを確認すると、メッセージ配信状態に遷移して、このメンバにメッセージを送信する。【００５１】
ユーザＡは、ユーザＡの通信端末２０のメッセージ制御機能部２５を用いてメッセージを受信する。この時、送信メッセージが複数のメディアで構成されている場合、通信端末のアプリケーションのメッセージ制御機能部２５を用いてメディアの選択受信をすることもできる。【００５２】
図６は、指定エリア内でメッセージを受信したメンバがメッセージの受諾を拒否する場合の動作を説明する図である。指定エリア内でメッセージを受信したメンバは、メッセージ内容を吟味して、当該メッセージを受諾するかどうかを判断することができる。図６は、メッセージを受諾しない場合のプロセスを示す。【００５３】
指定エリア内でメッセージを受信したユーザＡは、メッセージ内容と送信許容時間を確認し、メッセージ内容を吟味する（Ｓ３３）。その結果、メッセージの受諾を拒否する場合は、メッセージの差し戻し通知をメッセージ配信状態にあるサーバ１０へ送信する（Ｓ３４）。このときユーザＡは、受諾ができない理由などを記載した返信メッセージを添付することができる。本実施形態では、メッセージを差し戻してもユーザＡの端末２０には、当該メッセージが保存される。ユーザＡは、その後の事情により差し戻したメッセージを受諾することができる。【００５４】
サーバは、ユーザＡがメッセージを差し戻したことをデータベースに格納する（Ｓ３５）。次いで、サーバ１０は、メッセージ配送機能部１２と登録グループ管理機能部１４とを用いて、当該メッセージの送信者であるユーザＢに対して、メッセージ送信結果としてメッセージの受諾が拒否されたことを通知する（Ｓ３６）。差し戻し通知に返信メッセージが添付されていた場合は、ユーザＢに返信メッセージも通知する。サーバはメッセージ送信許容時間をチェックし、時間内の場合は再び監視状態に遷移する（Ｓ３７）。【００５５】
監視状態にあるサーバ１０は、図５に示す在圏監視を行う。したがって、次に指定されたエリアに到達したメンバがいれば、サーバ１０により指定エリア内にいることが確認される。確認されたメンバは、メッセージを受信することになる。なお、一度メッセージを差し戻したメンバに対しては、時間内に再度監視エリアに入ってもメッセージは送信されない。メッセージ送信許容時間が終了している場合は、サーバは監視プロセスを終わらせて、依頼待ち状態３１に遷移する。【００５６】
図７は、指定エリア内でメッセージを受信したメンバがメッセージを受諾した場合の動作を説明する図である。【００５７】
メッセージを受信したユーザＡがメッセージの内容を吟味した（Ｓ３３）後、例えばメッセージで依頼された用事を引き受けることができれば、そのメッセージを受諾する場合、メッセージ配信状態にあるサーバ１０に対して、受諾通知を送信する（Ｓ４１）、サーバ１０は、どのメンバに受諾されたかをデータベースに格納する（Ｓ４２）。次いで、サーバ１０はメッセージ配送機能部１２とグループ管理機能部１４を動作させて、メッセージが受諾されたことをメッセージ送信者であるユーザＢに通知する（Ｓ４３）。さらに、メッセージを差し戻したメンバがいた場合には、メッセージを差し戻したメンバにもメッセージが受領したことを通知する（図示せず）。メッセージ送信者には、受領したメンバから返信メッセージとして受領メッセージが送付されていた場合、受領メッセージも通知する。その後、メッセージ配信状態を終了して、依頼待ち状態３１に遷移する（Ｓ４４）。【００５８】
（差し戻し後のメッセージの受諾）
図８、９は、メッセージの受諾を拒否して差し戻したメンバが、その後メッセージを受諾する場合の動作を説明する図である。
メッセージの受諾を拒否して差し戻したメンバは、当該メッセージが他メンバに受諾されてない場合に限り、メッセージを受諾することができる。なお、本実施形態では、メッセージ差し戻し後の受諾を行うと、その後差し戻しはできない。【００５９】
メッセージ差し戻し後の受諾である差し戻し後受諾の手続きは、メッセージの差し戻し後受諾が、メッセージを差し戻したメンバからサーバに送信されることから開始するが、そのときのサーバの状態によって動作がわかれる。図８は、サーバが、当該エリアへのメンバの立ち入りを監視する在圏監視状態だった場合の動作を示す。【００６０】
一旦メッセージの受諾を拒否して差し戻したユーザＡがメッセージを受諾することができる（Ｓ５１）状態になれば、ユーザＡの通信端末２０のメッセージ制御機能部部２５によって、メッセージの差し戻し後受諾をサーバに通知する（Ｓ５２）。【００６１】
メッセージの差し戻し後受諾を受信したサーバ１０は、ユーザＡが、メッセージの差し戻し後に受諾したことをデータベースに格納する（Ｓ５３）。次いで、サーバ１０は、メッセージ配送機能部１２とグループ管理機能部１４を動作させて、メッセージ送信者であるユーザＢにメッセージの差し戻し後にメッセージの受諾があったことを通知する（Ｓ５４）。さらに、サーバは、ユーザＡに対して受諾通知を行って、差し戻し後受諾を確認する（Ｓ５５）。また、それまでにメッセージを差し戻したメンバがいれば、そのメンバにはメッセージの受諾通知を行って周知する。【００６２】
サーバは、当該エリアへのメンバの立ち入りを監視する監視状態３３であるので、その後、サーバは監視プロセスを終わらせて依頼待ち状態３１に遷移する（Ｓ５６）。【００６３】
図９は、サーバが、メッセージ配信状態である場合に、メッセージの受諾を拒否して差し戻したユーザが、その後メッセージを受諾する場合の動作を説明する図である。【００６４】
まず、サーバ１０が、在圏監視状態にあるときに、ユーザＣが監視エリアすなわちユーザＢが指定した指定エリア内に入ったことを確認（Ｓ６１）すると、メッセージ配信状態に遷移する（Ｓ６２）。そして、サーバ１０はメッセージをユーザＣに配信する（Ｓ６３）。ユーザＣは、メッセージ内容を吟味して（Ｓ６４）、メッセージを受諾するか否かを判断する。【００６５】
ユーザＡは、メッセージを差し戻した後、事情の変更等により当該メッセージを受諾することができる状態になっている（Ｓ６５）。そして、ユーザＣが、メッセージ内容を吟味しているときに、メッセージ配信状態にあるサーバには、一旦メッセージの受諾を拒否して差し戻したユーザＡから、メッセージを受諾する差し戻し後受諾が通知される。当該メッセージは、まだユーザＣに受諾された状態になっていない。したがって、ユーザＡの差し戻し後受諾は有効であり、サーバ１０は、メッセージ配信処理を停止する（Ｓ６７）。【００６６】
メッセージ配信処理を停止した後、サーバ１０は、メッセージを配信したユーザＣに当該メッセージは他のユーザに受諾されたことを通知する（Ｓ６８）。すなわち、ユーザＣは、メッセージ内容を吟味中に、他のメンバが当該メッセージを受諾した旨の連絡を受け取る。ユーザＣは、この連絡により、メッセージが他のメンバに受領されたことを知り、当該メッセージに関する処理を終了する（Ｓ６９）。さらに、サーバ１０は、メッセージをアタッチしたメッセージ送信者であるユーザＢに対して、ユーザＡが差し戻し後受諾したことを通知する（Ｓ７０）。サーバ１０は処理を終わらせてから、メッセージ配信状態３４から依頼待ち状態３１に遷移する（Ｓ７１）。【００６７】
以上のように、サーバ１０が、指定エリアに入ったメンバにメッセージを配信する配信状態である場合には、メッセージの差し戻し後受諾が起きた場合は、メンバへのメッセージ配信処理をストップして、メッセージを配信したメンバにメッセージが受諾された旨を受諾通知として伝える。なお、サーバの差し戻し後受諾の受信タイミングは、現在メッセージを送信しているメンバからの受諾通知をサーバが受信するよりも早くなければならない。【００６８】
（メッセージ受諾後の差し戻し）
図１０は、メッセージを受諾した後に当該メッセージの受諾を差し戻す場合の動作を示す図である。【００６９】
図１０では、一旦ユーザＢからのメッセージを受諾したユーザＡが、その後何らかの事情で当該メッセージを差し戻す場合を示す図である。ユーザＡが、メッセージ受諾後に当該メッセージを差し戻す処理である受諾後差し戻しを実行するためには、ユーザＡの通信端末２０のメッセージ制御機能部２５を使用する。ユーザＡは、メッセージ制御機能部２５を起動して、受諾したメッセージの差し戻し依頼を実行する（Ｓ８１）。なお、受諾後の差し戻し依頼は、メッセージ送信の許容時間内でのみ可能である。【００７０】
サーバ１０が受諾後差し戻し依頼を受信すると、ユーザＡがメッセージの受諾後差し戻しを行ったことをデータベースに格納する（Ｓ８２）。その後、サーバ１０は、メッセージ配送機能部１２とグループ管理機能部１４を用いて、メッセージ送信者であるユーザＢに受諾後差し戻しがあったことを通知する（Ｓ８３）。また、ユーザＡによるメッセージの受諾前にメッセージを差し戻したユーザなど、これまでにメッセージ受諾通知を受信した他のメンバがいれば、当該他のメンバにも受諾後差し戻しを通知する。本実施形態では、ユーザＣが、以前にメッセージ受諾通知を受けていたので、受諾後差し戻しがあったことが通知される（Ｓ８４）。ユーザＡから返信メッセージとして差し戻しメッセージが添付されていた場合は、受諾後差し戻し通知には差し戻しメッセージも送付して通知する。なお、メッセージを受諾後に差し戻しをした後、再度受諾することはできない。依頼待ち状態３１のすべての処理が終了すると、指定エリアに入るメンバを監視する監視状態３３に遷移する（Ｓ５５）。監視状態３３では、メッセージ配信許容期間が過ぎるまで、指定エリアに入るメンバが発見されれば、メッセージを配信することになる。【００７１】
本実施形態では、メンバの在圏監視は、通常メッセージがアタッチされた指定場所をカバーしている基地局により行うことができる。さらに、用件を実行するポイントが決められているような場合、該当するグループのユーザが当該基地局のカバーエリア内に入ってきたら、ユーザの希望に応じて制御をGPSに切り替えて、メッセージを受諾したユーザをGPSにより用件実行ポイントに誘導することもできる。【００７２】
例えば、該当するグループのメンバが指定エリアに進入したタイミングにて、近辺にメッセージの用件が実行されるポイントがあることを伝え、サーバはメッセージを配信する。メッセージを受諾するメンバが、用件実行ポイントの場所を厳密に知りたい場合に、GPSによるナビゲーションを行うことができる。【００７３】
以上説明したように、本実施形態では、指定されたエリアに入ってくるメンバの順に用件の受諾の可否を問うことにより、用件の受諾を各メンバの予定や意思による決定に委ねることができる。さらに、用件の依頼を受けたメンバが拒否するまで他のメンバにはその用件は隠蔽されているので、メンバ間の調整は必要がなく、結局、グループ内のメンバ間の調整を行うことなく、依頼された用件を処理することができる。特に、突発的に発生する用件をグループのメンバの誰かに依頼するような場合に特に有効である。【００７４】
従来のメーリングリストによるメンバ全員への同報では、どのメンバが用件を受けるかの調整のためにマルチキャストトラックが発生していたが、本実施形態では、マルチキャストトラックを大幅に軽減でき、ネットワークリソースを有効利用できる。【００７５】
さらに、メッセージ受諾後のキャンセルや、メッセージ差し戻し後の再受諾を許容する事により、メンバ個人の予定変更等に柔軟に対応できる。【００７６】
なお、本実施形態では、グループの一人だけが依頼を受諾すればよい用件について説明したが、これに限らず、グループのうちの数名のメンバが依頼に応ずる必要がある用件でもよい。この場合、グループのうちの任意の数名が依頼のあった用件を受諾するまで本実施形態を繰り返して適用すればよい。
【図１】
2009019790.tif 000003
【図２】
2009019790.tif 000004
【図３】
2009019790.tif 000005
【図４】
2009019790.tif 000006
【図５】
2009019790.tif 000007
【図６】
2009019790.tif 000008
【図７】
2009019790.tif 000009
【図８】
2009019790.tif 000010
【図９】
2009019790.tif 000011
【図１０】
2009019790.tif 000012
【手続補正書】
【提出日】平成21年12月28日(2009.12.28)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、
任意の場所を指定して指定場所とし、該指定場所に入る前記登録グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部と
を有する複数の端末と、
前記指定場所に前記登録グループのメンバが入っているか否かを監視する在圏監視機能部と、
前記指定場所に最初に入った前記登録グループのメンバに対して、前記メッセージを配信し、当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部と
を有するサーバと、
を備えることを特徴とするメッセージ配信システム。
【請求項２】
前記端末のメッセージ配信依頼機能部は、前記登録グループのメンバに前記メッセージを配信する期間を指定することを特徴とする請求項１に記載のメッセージ配信システム。
【請求項３】
前記端末は、グループを作成して、作成されたグループの登録を前記サーバに依頼するグループ作成登録依頼機能部を備え、前記サーバは、前記グループ作成登録依頼機能部からの依頼により、前記作成されたグループの登録を受け付けるグループ登録受付手段を備えることを特徴とする請求項１または２に記載のメッセージ配信システム。
【請求項４】
指定場所に登録グループのメンバが入っているか否かを監視し、
前記指定場所に最初に入った前記指定グループのメンバに対して、メッセージを配信し、
当該メンバが前記メッセージの受諾を拒否した場合、次に前記指定エリアに入った前記グループの他のメンバに対して、前記メッセージを配信する
ことを特徴とするメッセージ配信方法。
【請求項５】
前記メッセージが配信されたメンバは、メッセージを一旦受諾した後であっても、該メッセージの受諾を拒否することができることを特徴とする請求項４に記載のメッセージ配信方法。
【請求項６】
前記メッセージが配信されたメンバが前記メッセージの受諾を拒否した場合、他のメンバが当該メッセージを受諾していない期間であれば、前記メッセージの受諾を拒否したメンバは当該メッセージを受諾することができる請求項４または５に記載のメッセージ配信方法。
【請求項７】
登録グループの任意のメンバに対するメッセージを作成するメッセージ作成機能部と、
任意の場所を指定して指定場所とし、該指定場所に入る前記登録グループのメンバに前記メッセージを配信するようにサーバに依頼するメッセージ配信依頼機能部と
を有することを特徴とする端末。
【請求項８】
指定場所に登録グループのメンバが入っているか否かを監視する在圏監視機能部と、
前記指定場所に最初に入った前記登録グループのメンバに対して、メッセージを配信し、当該メンバが前記メッセージを差し戻した場合、次に前記監視エリアに入った前記グループの他のメンバに対して、前記メッセージを配信するメッセージ配信機能部と
を有することを特徴とするサーバ。
【国際調査報告】
2009019790.tif 000013
2009019790.tif 000014