コミュニケーション提供システム、コミュニケーション提供方法、サーバ装置、及び端末装置
【課題】無線伝搬環境のよくない場所であっても、発信がタイムアウトするまでユーザを待たせることなく、簡潔な操作でコミュニケーション発呼を可能とする。
【解決手段】端末装置１では、コミュニケーション発呼部１０でユーザによる発呼操作が検出されると、単位時間毎のユーザによる発呼操作の回数をサーバ３に送信する。このとき、送信が成功した場合には、蓄積されている発呼操作の回数をクリアし、送信が失敗した場合には、蓄積されている発呼操作の回数を記憶する。サーバ３は、端末装置１からのリクエストに応じて、同じグループに属する他の端末装置の単位時間毎の発呼の回数を返信する。端末装置１では、リクエストに応じてサーバ３から返信される、同じグループに属する他の端末装置の単位時間毎の発呼の回数を受信し、表示部１７に表示する。
【解決手段】端末装置１では、コミュニケーション発呼部１０でユーザによる発呼操作が検出されると、単位時間毎のユーザによる発呼操作の回数をサーバ３に送信する。このとき、送信が成功した場合には、蓄積されている発呼操作の回数をクリアし、送信が失敗した場合には、蓄積されている発呼操作の回数を記憶する。サーバ３は、端末装置１からのリクエストに応じて、同じグループに属する他の端末装置の単位時間毎の発呼の回数を返信する。端末装置１では、リクエストに応じてサーバ３から返信される、同じグループに属する他の端末装置の単位時間毎の発呼の回数を受信し、表示部１７に表示する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、コミュニケーション提供システム、コミュニケーション提供方法、サーバ装置、及び端末装置に関する。
【背景技術】
【０００２】
現在、様々なコミュニケーション手段が提供されている。コミュニケーション手段の利用者は、シチュエーションや、そのときの欲求度合い等に合わせて、様々なコミュニケーション手段のうちからいずれかを選んでコミュニケーションを行っている。コミュニケーションを行うコミュニティに属する利用者の間で、最も多くの情報をやり取りできるコミュニケーション手段は、直接会って話すことである。直接会って話す場合、表情や、間合いなど、言葉以上の情報によって、聞く側は、発話者の意図を理解することができる。
【０００３】
ただし、コミュニケーションを行うために、常に直接会って話すことは難しい場合がある。例えば、コミュニティに属する利用者が、互いに離れた遠隔地にいる場合、常に直接会って話すことは難しいことがある。このような場合、別のコミュニケーション手段を用いてコミュニケーションを行っている。例えば、電話によって音声を介してコミュニケーションを図る、電子メールによって文字を介してコミュニケーションを図る、などが行われる。
【０００４】
ところで、日本では、携帯電話インフラが充実してきており、携帯メールなど、場所や、時間を選ばないコミュニケーション手段によりコミュニケーションを図りやすい環境が整ってきた。コミュニケーション手段のうち、携帯電話を用いたメールなどは、携帯電話の文字入力インタフェースのみによるコミュニケーション手段であり、直接会って話すコミュニケーションと異なる。例えば、携帯メールなどのコミュニケーション手段は、表情や、間合いなど、言葉以上の情報を得ることができない。しかし、比較的短い文字の情報を伝えるコミュニケーションを図る場合においては、時間や場所などのシチュエーションを選ばない手軽さがメリットとなる。
【０００５】
携帯メールなどを発信する携帯電話などにおいて、メールサービスが実現されるシーケンスの例として非特許文献１に記載されたシーケンスがある。非特許文献１に記載されているように、携帯メールなどを実行する携帯電話システムにおける独自の動作は、低レイヤに留まり、上位レイヤのアプリケーション、及びトランスポートレイヤは、ＨＴＴＰ、及びＴＣＰ／ＩＰに則って行われる（非特許文献１の図６）。すなわち、パケット発信処理までは、携帯電話ネットワークのシーケンスで、それ以降の処理は、上位レイヤの一般的なインターネット上のシーケンスで、端末からのＨＴＴＰリクエストに対してＴＣＰコネクションを張って通信を行い、そのセッションの完了までを見届けてから通信を完了する。
【０００６】
メールサービスは、送信者が何か伝えたいことがあるときに、送信用、及び受信用のメールサーバを介して送信者から受信者に情報を伝えることによってコミュニケーションが成立する。メールサービスは、アプリケーションレイヤから見て、送信者が情報を送信するタイミングと、受信者が当該情報を受信するタイミングとが異なり、非同期のコミュニケーションである。しかし、送信者が情報を送信するタイミングにおいて、送信者の操作する端末と、メールサーバとの間の通信は、ＴＣＰに則って端末が、サーバとの通信完了までを確認して終了する処理を行う同期通信である。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＮＴＴ ＤｏＣｏＭｏ テクニカル・ジャーナル Ｖｏｌ．７ Ｎｏ．２ ｐ．１６−２１
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、現実には、携帯電話を用いたメールよりも、さらに場所や、時間を限定せずにコミュニケーション発呼を発することによる簡便な意思表現が望まれる状況も想定される。すなわち、コミュニケーション発呼に要するアクションは、できるだけ簡潔に短時間で済ませる使い方が望まれる。
【０００９】
このような状況では、アクションの簡潔さが求められており、アクションを起こした当該セッションの間に時間をかけてでも意思表現の送達する確率を上げることより、意思表現の送達ができなかったときには、早々に不達と判断して処理を終えることが望ましい。メール等の一般的なデータ通信と違い、送信するデータの中身ではなく、コミュニティの他のメンバーは、「いつ」、「誰から」、「発呼のアクションの有無」が分かればよく、また１回のアクションも洩らすことなく、時間をかけて確実に伝えることよりは、アクションの簡潔さが優先される。
【００１０】
しかしながら、上述した従来技術によるメールサービスのような、インターネット上のアプリケーションの場合には、端末からコミュニケーション発呼を検出したとき、サーバとの通信が完了するまで、ＴＣＰで設定したタイムアウト時間だけリトライを繰り返し、サーバまでの送達の完了、又は失敗の情報が端末に返される。
すなわち、１回のセッションで、送りたい情報を伝えるための処理を繰り返して送達確率を上げる手法をとっている。そのため、例えば、無線伝搬環境の良くない環境で発信された場合、ユーザは、タイムアウトするまでしばらく待たされることになるという問題がある。
【００１１】
本発明は、このような事情を考慮してなされたものであり、その目的は、無線伝搬環境のよくない場所であっても、発信がタイムアウトするまでユーザを待たせることなく、簡潔な操作により入力した情報を送信するコミュニケーション提供システム、コミュニケーション提供方法、サーバ装置、及び端末装置を提供することにある。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムであって、前記端末装置は、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積し、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信し、送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている前記回数をクリアし、前記サーバ装置は、前記端末装置から受信した前記回数を蓄積し、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信することを特徴とするコミュニケーション提供システムである。
【００１３】
本発明は、上記の発明において、前記端末装置は、前記サーバ装置への前記回数の送信処理を強制的に停止させる送信停止手段を更に備え、前記送信停止手段により前記回数の送信処理が強制的に停止させられると、前記蓄積されている前記回数のクリアを行わないことを特徴とする。
【００１４】
本発明は、上記の発明において、前記端末装置は、前記サーバ装置へリクエストを送信するとき、最後にサーバ装置へのアクセスが成功した時刻から現在時刻までの期間示す情報を付加してリクエストを送信し、前記サーバ装置は、前記リクエストに付加されている情報が示す期間における、単位時間それぞれの前記回数を返信することを特徴とする。
【００１５】
本発明は、上記の発明において、前記サーバ装置は、前記端末装置毎にアクセスキーを生成し、更に、各端末装置のサーバ装置へのアクセス回数をカウントし、前記端末装置から所定の回数のアクセスがあると、新たにアクセスキーを生成し、所定の回数のアクセスをした前記端末装置のアクセスに対するリクエストとして送信し、前記端末装置は、前記蓄積されている前記回数を前記サーバ装置に送信する際に、前記回数とともに、前記サーバ装置から受け渡されたアクセスキーを送信し、前記サーバ装置は、前記端末装置が送信してきたアクセスキーと、当該サーバで管理するアクセスキーとが同じ場合、該アクセスキーを送信した前記端末装置にアクセスを許可することを特徴とする。
【００１６】
本発明は、上記の発明において、前記サーバ装置は、現在有効なアクセスキー以外に、各端末装置が最後に当該サーバ装置へのアクセスが成功したときのアクセスキーを予備のアクセスキーとして保存し、前記端末装置から前記予備のアクセスキーでのアクセスがあった場合には、正しいアクセスと判定してアクセスを許可し、そのレスポンスとして更新したアクセスキーを前記端末装置に返信することを特徴とする。
【００１７】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供方法であって、前記端末装置が、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積するステップと、前記端末装置が、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信するステップと、前記端末装置が、前記サーバ装置から当該情報を受信したことを示す応答信号を受信した場合、前記蓄積されている前記回数をクリアするステップと、前記サーバ装置が、前記端末装置から受信した前記回数を蓄積するステップと、前記サーバ装置が、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信するステップとを含むことを特徴とするコミュニケーション提供方法である
【００１８】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおける端末装置であって、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出する検出手段と、前記検出手段が前記入力操作を検出した単位時間毎の回数を蓄積する記憶手段と、前記検出手段が前記入力操作を検出すると、前記記憶手段に記憶されている前記回数を前記サーバ装置に送信する送信手段と、前記送信手段が送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記記憶手段に蓄積されている前記回数をクリアする記憶制御手段と、自端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記サーバ装置に送信する問い合わせ手段と、前記問い合わせ手段により送信されたリクエストに対して前記サーバ装置から返信される他の端末装置の単位時間毎の前記回数を受信する受信手段とを備えることを特徴とする端末装置である。
【００１９】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおけるサーバ装置であって、予め定められた入力操作による発呼を検出した回数を単位時間毎に蓄積し、発呼を検出すると前記蓄積されている発呼の回数を前記サーバ装置に送信し、送信した発呼の回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている発呼の回数をクリアする端末装置から受信した発呼の回数を蓄積し、前記端末装置から該端末装置の属するグループと同じグループに属する他の端末装置から受信した発呼の回数を要求するリクエストを受信すると、蓄積している発呼の回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する発呼の回数を該リクエストを送信した前記端末装置に返信することを特徴とするサーバ装置である。
【発明の効果】
【００２０】
この発明によれば、無線伝搬環境のよくない場所であっても、ユーザを待たせることなく、簡潔な操作により入力した情報を送信することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明によるコミュニケーション手段が適用される範囲を説明するための概念図である。
【図２】本発明の実施形態による基本的なシステム構成を示す概念図である。
【図３】本第１実施形態による端末装置１とサーバ３の構成例を示すブロック図である。
【図４】本第１実施形態の端末装置による、送信キュー１４への蓄積方法を説明するための概念図である。
【図５】本第１実施形態によるサーバ３の意思情報ＤＢのデータ構成例を示す概念図である。
【図６】本第１実施形態において、サーバ３の送信データ生成部３４による、端末装置へ送信する送信データの抽出方法の一例を示す概念図である。
【図７】本第１実施形態による端末装置１の表示部１７での受信した情報の表示例を示す概念図である。
【図８】本第１実施形態において、端末装置１がサーバ３に蓄積された情報をリクエストして取得する際の動作を説明するための概念図である。
【図９】本第１実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。
【図１０】本第１実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。
【図１１】本第１実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。
【図１２】本第１実施形態による、問い合わせトリガ発生時の端末装置１の動作を説明するためのフローチャートである。
【図１３】本第１実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。
【図１４】本第２実施形態による端末装置１とサーバ３との構成例を示すブロック図である。
【図１５】本第２実施形態による、アクセスキーＤＢ３７にて管理する情報の例を示す概念図である。
【図１６】本第２実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。
【図１７】本第２実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。
【図１８】本第２実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。
【図１９】本第２実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の一実施形態を、図面を参照して説明する。
【００２３】
図１は、本発明によるコミュニケーション手段が適用される範囲を説明するための概念図である。図１に示すように、直接会って話すことは、コミュニケーションするコミュニティに属する人の間で、最も多くの情報のやり取りができるコミュニケーション手段である。そのとき、表情や、間合いなど、言葉以外の情報によって、聞く側は、発話者の意図を理解することができる。ただし、コミュニケーションをとるためには、直接会う必要があり、コミュニケーションのしやすさという点では他のコミュニケーション手段に比べて行いにくい。
【００２４】
次に、電話による音声通話や、テレビ電話による映像と音声通話によるコミュニケーション手段は、直接会うことに比べれば情報量が少ないが、より手軽にコミュニケーションを図ることができる。同様に、携帯電話による音声通話は、時間や、場所に限定されず（特定の場所（例えば、電車内、病院施設内）では使用できないが）、更に、手軽にコミュニケーションを図ることができる。
そして、ＰＣ（パーソナルコンピュータ）や、携帯電話を用いた、電子メールや、携帯メールは、時間や、場所に限定されず、文字を介してコミュニケーションを図るという点で、１回のコミュニケーションにより伝達される報量は少ないが、手軽にコミュニケーションを図ることができる。
【００２５】
本発明では、従来の携帯メールに比べて、伝えられる情報は、文字による情報より少ない情報になるが、携帯メールより、更にいつでもどこでも伝えられる、更に簡易なインタフェースによるコミュニケーション手段を提供することを想定している。提供するコミュニケーション手段によって、非同期にコミュニケーション発呼の情報だけを、継続的にコミュニティ内に発し合うことによって、ミュニティの中で常に繋がっている感を実現することを目的とする。そして、コミュニティ内の互いの状況を推察し、相互理解を更に深めようとするものである。
【００２６】
図２は、本発明の実施形態による基本的なシステム構成を示す概念図である。本発明では、図２に示すように、複数のユーザが携帯する無線通信機能を有する端末装置１、２を、コミュニケーションを行うコミュニティ単位でグループとしてサーバ３で記憶する。各端末装置１、２は、ユーザがコミュニティに対してコミュニケーションの意思を示す情報を入力したことを検出する機能を有する。例えば、端末装置１が、ボタンを押すなどの操作をトリガとし、ボタンが押下されたことを検出すると、「そのユーザがボタンを押下した事実」を示す情報がサーバ３に伝わる。そして、サーバ３に「あのユーザが○○時○○分にボタンを押した」ことを示す情報が蓄積される。さらに、サーバ３から、当該コミュニティの他のユーザの端末装置２に、その情報が配信され、「あの人が今ボタンを押した」という情報が表示される。
【００２７】
このように、本発明のシステムは、コミュニティの間で、あの人がいつボタンを押した／押していない、という情報を共有するコミュニケーション手段である。ボタンの押下等で完結する最小限のアクションで伝えられるコミュニケーションで、文字にもならない、相手のことをノックするようなコミュニケーションを実現する。ボタンを押して伝えたいことの意味は、予めコミュニティの中で共有させておいてもよいし、コミュニケーションを続ける中で互いに暗黙の使い方をしてもよい。
また、ボタンの押下の回数毎に異なる意味を予め対応付けておき、当該対応の情報を共有するようにしてもよい。
【００２８】
端末装置１、２は、単位時間毎の発呼（コミュニケーション発呼）の回数を蓄積するキューを備え、ユーザによる発呼を検出すると、キューに蓄積されている発呼の回数を加算した後、キューに蓄積されたデータをサーバ３に送信し、サーバ３への送信が成功した場合には、キューをクリアし、サーバ３への送信が失敗した場合には、キューに蓄積されたデータをそのまま保存する。
【００２９】
サーバ装置３は、端末装置１、２から受信した単位時間毎の発呼（コミュニケーション発呼）の回数を蓄積し、端末装置１、２からのリクエストに応じて、該端末装置１、２と同じグループに属する端末装置から受信した単位時間毎の発呼の回数を返信する。
【００３０】
本発明によれば、ユーザを待たせることなく、簡潔な操作で「コミュニケーション発呼」を行うことができる。無線伝搬環境が良くない等の理由で送信できなかった「コミュニケーション発呼」を、後からまとめて迅速に送信することができる。
【００３１】
以下に、本発明のポイントを説明する。
（１）端末装置１、２の機能として、コミュニケーション発呼を検出する機能だけでなく、送信停止を検出する機能を有する。端末装置１、２は、予め決めておいた現在時刻からの単位時間毎の送信キューを有する。送信キューは、「現在時刻から１０分前から２０分前までの１０分の間に発せされたコミュニケーション発呼」といったものになる。また、コミュニケーション発呼を検出することより、送信が開始されて、送信が終わらないうちに、送信停止を検出したときには、送信キューに蓄積される。
【００３２】
送信キューは、時刻の変化によってシフトされていく。コミュニケーション発呼したタイミングにサーバ３に接続して送信するときには、送信キュー情報を送信する。送信後、送信キューは、クリアされる。
【００３３】
端末装置１、２が本方式を具備することによって、端末装置１、２を携帯するユーザが待たされることなく、簡潔にコミュニケーション発呼することを短時間で完結することが可能になる。更に、無線伝搬環境の良くない場所で発呼する際には、キューキングして送信することによって、送信できなかったコミュニケーション発呼を可能にしながら、単位時間の発呼回数というように、キューイング情報をまとめることによって、送信する情報量を少なくし、キュー情報送信時も迅速な送信が可能になる。
【００３４】
（２）サーバ３は、各コミュニティのグループ、その中のグループメンバのコミュニケーション発呼のログ（履歴）を、予め決めておいた単位時間毎の発呼回数として蓄積する。
サーバ３が本方式を具備することによって、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況を、アクションを発した大まかな時刻とともに小容量のデータで迅速に送信することができる。
【００３５】
（３）端末装置１、２の機能として、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況を、サーバ３に問い合わせる機能を持つ。問い合わせのリクエストパラメータとして、自分が最後にサーバ３へのアクセスが成功した時刻を、端末装置１、２内に記憶しておいて、その時刻から現在時刻までの間をパラメータとして、サーバ３は、リクエストに含まれる期間の単位時間分の発呼回数の集合をレスポンスする。
【００３６】
端末装置１、２とサーバ３とが本機能を具備することによって、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況について、端末装置１、２が必要とする分だけの情報を、簡易なインタフェースで問い合わせて、少ない情報量でレスポンスすることができ、効率的に軽量な通信が可能となる。
【００３７】
（４）上記（１）〜（３）の端末装置１、２とサーバ３との通信で、クローズドなコミュニティ内で、セキュアでありながら、コミュニケーション発呼の簡潔さを損なわない通信を行う方法として、以下の機能を持つ。
サーバ３は、端末装置毎にアクセスキーを生成する機能を持ち、各端末装置１、２のサーバ３へのアクセス回数をカウントする機能を持ち、予め決めておいた一定回数のアクセスがあったら、新たにアクセスキーを生成して、端末装置１、２のアクセスに対するリクエストとして、端末装置１、２に送信する機能を持つ。
【００３８】
端末装置１、２は、サーバ３から受け渡されたアクセスキーとともにコミュニケーション発呼を示す情報をサーバ３に送信する。サーバ３は、端末装置１、２の送信してきたアクセスキーとサーバ３で管理するアクセスキーとが同一である場合に、正しいアクセスと判断して処理を行う。また、サーバ３では、現アクセスキー以外に、各端末装置１、２が最後にサーバ３へのアクセスが成功したアクセスキーを、予備のアクセスキーとして保存する。端末装置１、２から予備のアクセスキーでのアクセスがあった場合には、アクセスを許可する処理を行い、そのレスポンスとして、更新したアクセスキーを端末装置１、２に返信する。
【００３９】
本機能を具備することによって、端末装置１、２からのアクセスに対して、インクリメントするキーを用いることによってなりすます不正アクセスを困難にする。さらに、前回成功したアクセスキーを予備アクセスキーとして保管することによって、無線伝搬環境の良くない場所で、端末装置１、２がサーバ３に対して、端末装置１、２が途中で送信停止の入力を検出して送信を停止させ、端末装置１、２とサーバ３との間で、現アクセスキーに不整合が起こったときも、端末装置１、２のアクセス不可になることを回避することが可能になる。
【００４０】
Ａ．第１実施形態
まず、本発明の第１実施形態について説明する。なお、以下の説明において、端末装置１とサーバ３とについて説明するが、サーバ３で管理されるすべての端末装置（例えば、端末装置２）は、端末装置１と同じ構成を有する。
【００４１】
図３は、本第１実施形態による端末装置１とサーバ３の構成例を示すブロック図である。図３において、端末装置１は、携帯電話や、ＰＤＡ等のユーザが携帯して利用する無線通信機能を備える端末からなる。端末装置１は、コミュニケーション発呼部１０、送信部１１、送信停止部１２、キュー制御部１３、送信キュー１４、受信部１５、データ保存部１６、表示部１７、意思情報データ１８、最終受信時刻１９、及び問い合わせ部２０を備えている。
【００４２】
コミュニケーション発呼部１０は、端末装置１のユーザが、予め登録してあるコミュニティのメンバーに対して、当該ユーザが何らかコミュニケーションの意思を示す情報を入力する手段であり、ユーザインタフェースとして普段の端末装置１の利用からできるだけ簡単にアクセスできることが望ましい。例えば、携帯電話上で常時動作するアプリケーションで端末機能を実現し、携帯電話が備える、あるボタンをコミュニケーション発呼部１０に割り当て、当該ボタンが押下されることにより、コミュニケーションの意思を示す情報が入力されたことを検出する。以下、コミュニケーション発呼部１０が、ユーザのコミュニケーションの意思を示す情報を入力することをコミュニケーション発呼という。
【００４３】
送信部１１は、コミュニケーション発呼部１０によりコミュニケーション発呼が行われると（ユーザが端末装置１上のボタンを押下すると）、後述のキュー制御を一旦行ってから、送信キュー１４を介して、サーバ３に当該ユーザがコミュニケーション発呼を行ったことを通知する。
【００４４】
送信停止部１２は、送信部１１によるサーバ３への送信処理中に、ユーザ操作に応じて、サーバ３への送信を中止する。送信停止部１２は、端末装置１上のボタンに紐づけて、ボタン押下時に機能する等によって実現する。送信停止部１２は、無線通信の伝搬環境が良くないときなど、端末装置１がサーバ３への通信するために時間を要する場合に、端末装置１側から直ちに送信処理を停止するための機能である。送信停止部１２が機能したとき、送信中であったデータは、キュー制御部１３によって送信キュー１４に蓄積される。キュー制御部１３は、送信キュー１４に対して、コミュニケーション発呼部１０での発呼動作、送信部１１でのサーバ３への送信動作、送信停止動作において、送信キュー１４への送信情報の保存、読み出し、クリアなどを制御する。
【００４５】
受信部１５は、サーバ３から送信されるデータを受信する。データ保存部１６は、受信部１５による受信データを、意思情報データ１８として保存し、保存しているサーバ３からの最終受信時刻１９を更新する。表示部１７は、上記受信データ、又は意思情報データ１８に従って、所属するグループのメンバーのコミュニケーション発呼に関する情報を表示する。最終受信時刻１９は、最後にサーバ３からデータを受信した時刻を記憶する記憶部である。問い合わせ部２０は、最終受信時刻１９に記憶されている時刻を示す情報を参照して、予め定めた周期、ボタン押下、携帯オープン等を検出して、サーバ３上のデータ取得のリクエストをサーバ３に発する。
【００４６】
サーバ３は、受信部３０、蓄積データ更新・生成部３１、意思情報ＤＢ３２、リクエスト受信部３３、送信データ生成部３４、及び送信部３５を備えている。受信部３０は、端末装置１が送信したコミュニケーション発呼の情報を受信する。蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を意思情報ＤＢ３２に蓄積する。
【００４７】
リクエスト受信部３３は、端末装置１からのリクエストを受信し、該リクエストの内容を解析する。該リクエストには、当該端末装置１の所属するグループのユーザのコミュニケーション発呼に対して、「過去のどれだけの時間のデータが必要か」が記述されている。送信データ生成部３４は、端末装置１からコミュニケーション発呼の情報や、リクエストが要求されたことを検出すると、端末装置１に送信する送信データを生成する。送信部３５は、上記送信データを端末装置１に送信する。
【００４８】
図４は、本第１実施形態の端末装置１による、送信キュー１４へのコミュニケーション発呼した回数を示す情報の蓄積方法を説明するための概念図である。図において、現在時刻を「現在時」、現在時の次に訪れる単位時間の正時時刻を「現在正時」として定義している。また、時間軸上の黒点が発呼を示している。
【００４９】
現在時から遡って予め定めた単位時間当たりのコミュニケーション発呼した回数を、単位時間毎にカウントする。図示の例では、単位時間を１０分とし、現在時（現在時刻）が１１：２６付近であるとすると、現在時刻を含む単位時間である１１：２０〜１１：３０までの発呼回数が１回で、その前の１１：１０〜１１：２０までの発呼回数が３回で、その前の１１：００〜１１：１０までの発呼回数が２回、それ以前は０回であることを指している。
【００５０】
システム内で用いる単位時間は、サーバ３と端末装置１との間で共有されており、端末装置１からサーバ３に送信する情報は、「キューを形成する単位時間の数（図示の例では５個）」、「各キューに蓄積された発呼回数」の情報だけを送信すれば、サーバ３側は、当該ユーザが単位時間当たりに何回発呼したかという情報として、ユーザのコミュニケーション発呼の意思を認識することができる。送信キュー１４には、サーバ３への送信が最後に成功してから検出したコミュニケーション発呼した回数を示す情報だけを記憶し、サーバ３への送信が成功すると、送信キュー１４内は、クリアされる。
【００５１】
端末装置１からサーバ３への送信キュー１４内の情報の送信タイミングは、コミュニケーション発呼したタイミングでもよいし、端末装置１で一定時間蓄積した後、まとめて送信するようにしてもよい。
端末装置１が、送信停止部１２の機能と、コミュニケーション発呼したことを送信キュー１４に蓄積する機能とを組み合わせて具備することによって、ユーザは、無線通信の伝搬環境が良くないなどによってサーバ３への送信に時間がかかる場合に、コミュニケーション発呼したことをサーバ３に送信することを簡単に取りやめることができる。
また、そのコミュニケーション発呼したことを蓄積して、無線通信の伝播環境が改善した際に、サーバ３に送信することが可能となる。また、送信する情報を単位時間当たりのコミュニケーション発呼した回数として送信キュー１４に蓄積することによって、サーバ３に送信するデータを小さくし、データ送信に要する時間を短くすることを可能にしている。
【００５２】
図５は、本第１実施形態によるサーバ３の意思情報ＤＢ３２のデータ構成例を示す概念図である。意思情報ＤＢ３２は、複数のコミュニケーションをとりあうコミュニティの情報をグループＩＤ毎に管理し、各グループに所属するユーザの情報を管理する。各ユーザがコミュニケーション発呼を行った際に端末装置１から送信されてくる情報は、単位時間当たりの当該ユーザの当該グループに対する発呼回数として蓄積される。
【００５３】
図５に示す例では、単位時間を１０分として、現在時刻から１０分単位に、各ユーザが何回発呼したかを蓄積した例である。例えば、グループＩＤ「０００１」に所属するユーザＩＤ「０００２」の端末装置の場合には、２時間前から１時間前までの１時間に発生した１０分毎の発呼回数は、古い順に、０回、３回、１回、０回、１回、１回となる。単位時間は、本システムを用いるサービスに即した間隔で設定すればよい。
【００５４】
例えば、サークル内のメンバーの緩やかなコミュニケーション発呼を表示するツールとして用いるなら、コミュニケーション発呼の時間の正確さにシビアな要求はなく、例に示すように、１０分間に何回発呼があったかという情報で十分である。該蓄積方法によれば、すべてのコミュニケーション発呼について、「グループＩＤ」、「ユーザＩＤ」、「発呼時刻」の組み合わせで蓄積するよりも、少量のデータを蓄積すればよく、また、蓄積したデータを端末装置１に送信する際に必要なデータを抽出する際にも、アクセスしやすい形態をとることができる。
【００５５】
本第１実施形態において、送信キュー１４のために規定する単位時間は、端末装置１で設定できるパラメータとし、サーバ３への送信情報の中に当該端末装置１で設定している単位時間情報を重畳させて送信し、サーバ３がその情報を認識する機能を具備することによって、当該端末装置１を用いるユーザが求めるコミュニケーション発呼の間隔の粒度を定義することが可能となる。
【００５６】
図６は、本第１実施形態において、サーバ３の送信データ生成部３４による、端末装置１へ送信する送信データの抽出方法の一例を示す概念図である。送信データ生成部３４は、例えば、グループＩＤ「０００１」のメンバーのいずれかに送信するためのデータを意思情報ＤＢ３２から抽出するには、該当するグループＩＤを持つユーザのレコードを抽出し、送信に必要な分のコミュニケーション発呼のデータを抽出すればよい。
【００５７】
図示の例では、端末装置１に送信するための情報として、現在時から遡った３時間分のデータを抽出している。意思情報ＤＢ３２に蓄積した情報から、必要な情報を切り出すイメージとなる。本第１実施形態で実現するコミュニケーションは、非同期なコミュニケーションであるため、サーバ３から端末装置１にデータを送信するトリガは、端末装置１からの送信を契機、又は、端末装置１からのリクエストを契機、又は、サーバ３から定期的な送信等のいずれの場合も考えられる。
【００５８】
図７は、本第１実施形態による端末装置１の表示部１７での受信した情報の表示例を示す概念図である。図示の例では、当該端末装置１を利用しているユーザが所属するグループには、３人のメンバーが所属し、端末装置１は、それらのメンバーの過去３時間のコミュニケーション発呼の情報を、サーバ３から取得したとする。
【００５９】
表示部１７には、取得したグループのメンバーのコミュニケーション発呼の情報を時系列的なグラフとして可視化されている。すなわち、表示部１７の画面上、縦方向に奥行きを持って時間経過が示されており、円柱の高さが発呼回数を示している。例えば、ＩＤ０００４のＣさんは、３時間のうち、直近の１０分間に１回のアクセスがあったことを示している。
【００６０】
コミュニティがサークル内の緩やかなコミュニケーションの手段として用いられているならば、当該ユーザがＣさんであるとすると、Ｂ君がしばらくの間、継続的にコミュニケーション発呼の形跡である履歴を示す情報があるところから、今、Ｂ君が電話や、メールなどのコミュニケーションをとりやすい状況にあることが予想される、といった利用シーンが考えられる。
【００６１】
図８は、本第１実施形態において、グループＩＤ「０００１」に所属しているユーザＩＤが割り当てられている端末装置１が、サーバ３に蓄積された情報をリクエストして取得する際の動作を説明するための概念図である。端末装置１の問い合わせ部２０は、予め定めた周期、ボタン押下、携帯オープンする操作等を検出して、サーバ３上のデータ取得のリクエストをサーバ３に発する。
【００６２】
図示の例では、端末装置１から「当該グループのコミュニケーション発呼のデータについて、過去１時間分の要求」がリクエストされた場合を示しており、サーバ３は、該リクエストに対して、グループＩＤ「０００１」に所属するユーザＩＤ「０００１」、「０００２」、「０００４」に関する、現在から遡って１時間分のコミュニケーション発呼のデータを抽出し、端末装置１への送信データを生成する。
【００６３】
次に、本第１実施形態の動作について説明する。
図９は、本第１実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、コミュニケーション発呼部１０は、コミュニケーション発呼（所定のボタンの押下）を検出したか否かを判定し（ステップＳ１）、コミュニケーション発呼が検出されない場合には、ステップＳ１を繰り返す。一方、コミュニケーション発呼が検出された場合には、キュー制御部１３は、コミュニケーション発呼の回数として１回分を送信キュー１４に蓄積する（ステップＳ２）。次に、送信部１１は、当該コミュニケーション発呼の情報（「キューを形成する単位時間の数」及び「各キューに蓄積された発呼回数」それぞれを示す情報）を送信する（ステップＳ３）。
【００６４】
次に、送信部１１は、サーバ３からリクエスト「ＯＫ」を受信したか否かを判定し（ステップＳ４）、サーバ３からリクエスト「ＯＫ」を受信した場合には、コミュニケーション発呼の情報の送信が成功したことを示すので、キュー制御部１３は、送信キュー１４内をクリアする（ステップＳ５）。
ここで、リクエスト「ＯＫ」は、サーバ３が端末装置１からコミュニケーション発呼の情報を受信したことを示す応答の信号であって、サーバ３が端末装置１に送信する信号である。
【００６５】
一方、ステップＳ４において、サーバ３からリクエスト「ＯＫ」を受信しなかった場合には、送信部１１は、リクエストがタイムアウトしたか否かを判定し（ステップＳ６）、タイムアウトした場合には、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する（ステップＳ８）。
【００６６】
一方、ステップＳ４においてサーバ３からリクエスト「ＯＫ」を受信せず、かつ、ステップＳ６においてタイムアウトでもない場合には、送信停止部１２は、ユーザによる送信停止のアクションを検出したか否かを判定し（ステップ７）、ユーザによる送信停止のアクションを検出した場合には、上記ステップＳ８へ進み、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する。
【００６７】
また、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもなく、送信停止のアクションも検出しない場合には、ステップＳ４に戻り、上述した動作を繰り返す。
【００６８】
図１０は、本第１実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、受信部３０は、端末装置１から送信されるコミュニケーション発呼の情報を受信し（ステップＳ１０）、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ１１）。
【００６９】
図１１は、本第１実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、受信部１５は、サーバ３からの送信データを受信し（ステップＳ２０）、表示部１７は、サーバ３からの受信データを、図７に示すように表示（更新）し（ステップＳ２１）、受信部１５は、最終受信時刻１９を更新し（ステップＳ２２）、データ保存部１６は、受信データを意思情報データ１８に保存する（ステップＳ２３）。
なお、ここでは、ステップＳ２１〜Ｓ２３を並列に行う場合を示したが、ステップＳ２１〜Ｓ２３を順次行うようにしてもよい。
【００７０】
図１２は、本第１実施形態による、問い合わせトリガ発生時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、他の端末装置１におけるコミュニケーション発呼に関する情報を要求する問い合わせトリガが検出されると（ステップＳ３０）、問い合わせ部２０は、最終受信時刻１９を参照し（ステップＳ３１）、サーバ３にリクエスト（「当該グループのコミュニケーション発呼のデータについて、最終受信時刻１９から現在正時までの期間に対応するコミュニケーション発呼のデータの要求」、例えば、当該グループのコミュニケーション発呼のデータについて、過去１時間分のデータの要求）を送信する（ステップＳ３２）。
なお、問い合わせトリガは、例えば、問い合わせトリガを入力するボタンが押下されることや、加速度センサを具備している端末装置１においてユーザが端末装置１を振るといった所定の操作である。すなわち、予め定められたユーザの操作が問い合わせトリガになる。
また、予め定めた期間が経過する毎に、問い合わせ部２０にステップＳ３１の動作を行わせるようにしてもよい。
【００７１】
図１３は、本第１実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、リクエスト受信部３３が端末装置１からリクエストを受信すると（ステップＳ４０）、送信データ生成部３４は、送信データを生成し（ステップＳ４１）、送信部３５は、生成した送信データを端末装置１に送信する（ステップＳ４２）。
【００７２】
図８に示す例では、サーバ３が、グループＩＤ「０００１」に所属しているユーザＩＤが割り当てられている端末装置１から、ユーザＩＤ（例えば、ユーザＩＤ「０００１」）を含むリクエストを受信し、グループＩＤ「０００１」に関して過去１時間分の要求があったとしている。そのとき、サーバ３の送信データ生成部３４は、図８に示す送信データ生成と同様の手法で、過去１時間分の当該グループの情報を送信データとして抽出する。端末装置１で保存するサーバ３からの最終受信時刻１９を参照する等によって、端末装置１が必要とする過去の時間を指定してリクエストを送信する機能を具備することによって、サーバ３から端末装置１に送信するコミュニケーション発呼の情報を、各端末装置１が必要分に即した情報量にすることにより、効率的な端末装置１へのデータ送信を可能にしている。
【００７３】
上記のように、端末装置１は、予め定められた入力操作によるコミュニケーション発呼を検出した回数を単位時間毎に送信キュー１４に蓄積し、コミュニケーション発呼を検出すると送信キュー１４に蓄積されているコミュニケーション発呼の回数をサーバ３に送信し、サーバ３から当該情報を受信したことを示す応答信号であるリクエスト「ＯＫ」を受信した場合、前記蓄積されている発呼の回数をクリアするようにした。
これにより、コミュニケーション発呼の回数をサーバ３に送信せずに、送信キュー１４に記憶させておくことができるので、無線伝搬環境のよくない状況においてコミュニケーション発呼の回数を再送せずに送信を停止して無線伝搬環境の状況が良くなった際に、送信キュー１４に記憶されているコミュニケーション発呼の回数をサーバ３に送信することができる。その結果、無線伝搬環境のよくない状況では、再送を繰り返したり、タイムアウトを待ったりすることなく送信を停止させることができ、ユーザを待たせることなく、簡潔な操作によりコミュニケーション発呼を入力させることができる。
また、無線伝搬環境がよくないなどの理由で送信できなかったコミュニケーション発呼の回数を後からまとめて迅速に送信することができる。
【００７４】
端末装置１は、更に、コミュニケーション発呼の回数をサーバ３に送信する処理を強制的に停止させる送信停止部１２を備え、送信停止部１２によりサーバ３への送信を停止させた際には、送信キュー１４のクリアを行わずに、記憶させたままにするようにした。
これにより、無線伝搬環境の状況がよくない場合、コミュニケーション発呼の回数をサーバ３に送信する処理を停止させることにより、コミュニケーション発呼の回数をサーバ３に送信する際に生じる再送や、タイムアウトの判定などのためにユーザを待たせることを防ぐことができる。
【００７５】
Ｂ．第２実施形態
次に、本発明の第２実施形態について説明する。
図１４は、本第２実施形態による端末装置１とサーバ３との構成例を示すブロック図である。本第２実施形態では、上述した本発明のポイント（４）の機能を付加したことを特徴とする。なお、図３に対応する部分には同一の符号を付けて説明を省略する。
【００７６】
端末装置１は、図３に示す構成に対して、更に、アクセスキー管理部２１、及びアクセスキー記憶部２２を備えている。アクセスキー管理部２１は、受信部１５がサーバ３からアクセスキー更新の信号を受信すると、アクセスキー記憶部２２に記憶されているアクセスキーを更新し、次回サーバ３へのアクセス時から新しいアクセスキーを、コミュニケーション発呼の情報や、リクエストに付与して送信する。
【００７７】
サーバ３は、図３に示す構成に対して、更に、アクセスキー管理・生成部３６、及びアクセスキーＤＢ３７を備えている。アクセスキー管理・生成部３６は、端末装置毎のアクセスキーを管理する。アクセスキーとは、各端末装置において、端末装置１からサーバ３に送信するデータや、リクエストに付与する情報である。サーバ３は、端末装置１からのアクセスに対し、アクセスキー管理・生成部３６において、当該端末装置のＩＤと受信データ内アクセスキーとを照合し、整合がとれたと判断した場合に、蓄積データ更新・生成部３１の処理を行う。
ここで、アクセスキーの照合とは、例えば、端末装置１を識別するＩＤと、当該端末装置から受信したデータ内アクセスキーとの組み合わせが、アクセスキーＤＢ３７に記憶されている当該端末とアクセスキーとの組み合わせに一致するか否かを判定することであり、一致した場合に整合がとれた場合、正しいアクセスであると判定する。
【００７８】
図１５は、本第２実施形態による、アクセスキーＤＢ３７にて管理する情報の例を示す概念図である。アクセスキーは、現在キーと予備キーとの２種が存在する。現在キーは、サーバ３が管理し、アクセスキーＤＢ３７に記憶されている現在のアクセスキーで、予備キーは、端末装置１がサーバ３へのアクセスが最後に成功したときに用いたアクセスキーである。前述の端末装置１のアクセスに対するアクセスキーの正否の判断は、現在キーとの照合を行い、もし現在キーと不整合であれば、予備キーとの整合を判断する。予備キーとの整合に成功した場合には、アクセスキーの照合は、正しいと判断し、正常の処理を行い、同時に端末装置１に新しいアクセスキーを再び送信する。
【００７９】
このように、アクセスキーＤＢ３７が、予備キーを記憶しておくことにより、サーバ３と、端末装置１との間でアクセスキーの不整合が発生しても、整合に成功した実績のある予備キーを用いることにより通信を継続して行うことができる。
例えば、無線伝搬環境がよくない状況において、アクセスキーの更新を行っている最中に通信が途切れるなどして、端末装置1が記憶するアクセスキーが更新されずに、サーバ３のみにおいてアクセスキーが更新されてしまう可能性がある。このような場合でも、サーバ３は、整合に成功した実績のある予備キーを使うことにより、受信したリクエストが登録されたユーザからのリクエストであるか否かを判定して、端末装置１との間の通信を行うことができる。
【００８０】
アクセスキーＤＢ３７には、端末装置毎に、現在キーでアクセスした回数をカウントし、アクセス回数として保存している。当該アクセス回数が予め定めた回数以上に達した端末装置１があると、現在キーを更新し、当該端末装置１に新しいアクセスキーを送信する。送信するタイミングは、アクセスキー更新用の情報の送信でもよいし、端末装置１からのリクエストに対する返信でもよい。
【００８１】
次に、本第２実施形態の動作について説明する。
図１６は、本第２実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、コミュニケーション発呼部１０は、コミュニケーション発呼（所定のボタンの押下）を検出したか否かを判定し（ステップＳ５０）、コミュニケーション発呼が検出されない場合には、ステップＳ５０を繰り返す。一方、コミュニケーション発呼が検出された場合には、キュー制御部１３は、コミュニケーション発呼の回数として１回分を蓄積する（ステップＳ５１）。
【００８２】
次に、アクセスキー管理部２１は、アクセスキー記憶部２２からアクセスキーを読み出し（ステップＳ５２）、送信部１１は、コミュニケーション発呼の情報に読み出したアクセスキーを付与し（ステップＳ５３）、当該コミュニケーション発呼の情報（「キューを形成する単位時間の数」、「各キューに蓄積された発呼回数」、「アクセスキー」）を送信する（ステップＳ５４）。
【００８３】
次に、送信部１１は、サーバ３からリクエスト「ＯＫ」を受信したか否かを判定し（ステップＳ５５）、サーバ３からリクエスト「ＯＫ」を受信した場合には、コミュニケーション発呼の情報の送信が成功したことを示すので、キュー制御部１３は、送信キュー１４内をクリアする（ステップＳ５６）。
【００８４】
一方、サーバ３からリクエスト「ＯＫ」を受信しなかった場合には、送信部１１は、リクエストがタイムアウトしたか否かを判定し（ステップＳ５７）、タイムアウトした場合には、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する（ステップＳ５９）。
【００８５】
一方、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもない場合には、送信停止部１２は、ユーザによる送信停止のアクションを検出したか否かを判定し（ステップ５８）、ユーザによる送信停止のアクションを検出した場合には、上記ステップＳ５９へ進み、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する。
【００８６】
また、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもなく、送信停止のアクションも検出しない場合には、ステップＳ５５に戻り、上述した動作を繰り返す。
【００８７】
図１７は、本第２実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、受信部１５は、サーバ３からの送信データを受信する（ステップＳ７０）。次に、アクセスキー管理部２１は、新しいアクセスキーを受信したか否かを判定し（ステップＳ７１）、サーバ３から新しいアクセスキーを受信した場合には、アクセスキー管理部２１は、アクセスキー記憶部２２に記憶されているアクセスキーを更新する（ステップＳ７２）。次に、表示部１７は、サーバ３からの受信データを、図７に示すように表示（更新）し（ステップＳ７３）、受信部１５は、最終受信時刻１９を更新し（ステップＳ７４）、データ保存部１６は、受信データを意思情報データ１８に保存する（ステップＳ７５）。
なお、ここでは、ステップＳ７３〜Ｓ７５を並列に行う場合を示したが、ステップＳ７３〜Ｓ７５を順次行うようにしてもよい。
【００８８】
図１８は、本第２実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、受信部３０が、端末装置１から送信されるコミュニケーション発呼の情報を受信すると（ステップＳ８０）、アクセスキー管理・生成部３６は、コミュニケーション発呼の情報に付加されているアクセスキーと現在キーとを照合し、双方が整合するか否かを判定する（ステップＳ８１）。
【００８９】
そして、アクセスキーと現在キーとが整合した場合には、アクセスキー管理・生成部３６は、現在キーの更新タイミングであるか否かを判定する（ステップＳ８２）。ここで、現在キーの更新タイミングでない場合には、アクセスキー管理・生成部３６は、アクセスキーＤＢ３７を参照し（ステップＳ８３）、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ８５）。
【００９０】
一方、ステップＳ８２において、現在キーの更新タイミングである場合には、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存する（ステップＳ８４）。次に、上記ステップＳ８５に進み、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ８５）。
【００９１】
一方、ステップＳ８１において、アクセスキーと現在キーとが整合しなかった場合には、アクセスキー管理・生成部３６は、アクセスキーと予備キーとを照合し、双方が整合するか否かを判定する（ステップＳ８６）。そして、アクセスキーと予備キーとが整合した場合には、上記ステップＳ８４に進み、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存し、ステップＳ８５で、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する。
【００９２】
また、ステップＳ８１においてアクセスキーと現在キーとが整合せず、かつ、ステップＳ８６においてアクセスキーと予備キーとも整合しなかった場合には、送信部３５は、端末装置１にアクセスキー不整合を通知する（ステップＳ８７）。
【００９３】
図１９は、本第２実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、リクエスト受信部３３が端末装置１からリクエストを受信すると（ステップＳ９０）、アクセスキー管理・生成部３６は、リクエストに付加されているアクセスキーと現在キーとを照合し、双方が整合するか否かを判定する（ステップＳ９１）。
【００９４】
そして、アクセスキーと現在キーとが整合した場合には、アクセスキー管理・生成部３６は、現在キーの更新タイミングであるか否かを判定する（ステップＳ９２）。ここで、現在キーの更新タイミングでない場合には、アクセスキー管理・生成部３６は、アクセスキーＤＢ３７を参照し（ステップＳ９３）、送信データ生成部３４は、送信データを生成し（ステップＳ９５）、送信部３５は、生成した送信データを端末装置１に送信する（ステップＳ９６）。
【００９５】
一方、ステップＳ９２において、現在キーの更新タイミングである場合には、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存する（ステップＳ９４）。次に、上記ステップＳ９５に進み、送信データ生成部３４は、送信データを生成し、上記ステップＳ９６で、送信部３５は、生成した送信データを端末装置１に送信する。
【００９６】
一方、ステップＳ９１において、アクセスキーと現在キーとが整合しなかった場合には、アクセスキー管理・生成部３６は、アクセスキーと予備キーとを照合し、双方が整合するか否かを判定する（ステップＳ９７）。そして、アクセスキーと予備キーとが整合した場合には、上記ステップＳ９４に進み、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存し、上記ステップＳ９５に進み、送信データ生成部３４は、送信データを生成し、上記ステップＳ９６で、送信部３５は、生成した送信データと更新した現在キーとを端末装置１に送信する。
【００９７】
また、ステップＳ９１においてアクセスキーと現在キーとが整合せず、かつ、ステップＳ９７においてアクセスキーと予備キーとも整合しなかった場合には、送信部３５は、端末装置１にアクセスキー不整合を通知する（ステップＳ９８）。
【００９８】
上述した第２実施形態によれば、一定の頻度で更新するアクセスキーによって、端末装置１をなりすましてサーバ３にアクセスすることを困難にしながら、無線伝搬環境が良くないシチュエーションでの通信によって、端末装置１とサーバ３とが管理するアクセスキーに不整合が起こった場合のために、成功したアクセスキーを予備キーとして保存することによって、不整合時のアクセスを回避することができ、予備キーでのアクセスが行われた時には、即座にアクセスキーを更新することによって、予備キー有効期間を極力短くしている。
【００９９】
なお、上述した第１、又は第２実施形態においては、サーバ３へのグループの登録は、ウェブサイトなどを経由して、代表者が各ユーザの携帯電話のメールアドレスを登録し、サーバ３から配信されたメールに記載されたサーバ３のＵＲＬにアクセスする等によって予め登録すればよい。
【０１００】
また、上述した第１、又は第２実施形態においては、端末装置１によるコミュニケーション発呼の検出は、１パターンを想定しているが、複数のボタンに異なる発呼に対応させて、複数の種類の情報を伝達するようにしてもよい。
【０１０１】
また、上述した第１、又は第２実施形態においては、端末装置１を携帯するユーザは、１つのグループに所属することを想定しているが、一人のユーザが複数のグループに所属することも可能である。この場合には、端末装置１における予めなされた設定に基づいて、１回のコミュニケーション発呼を、指定したグループ向けの情報として割り当てることになる。その際の端末装置１からサーバ３への送信情報には、当該情報が含まれ、サーバ３では、受信した情報がどのユーザのどのグループ向けのものかを、端末装置１において予めなされた設定に基づいて、認識する機能を有することとなる。
【０１０２】
また、上述した第１、又は第２実施形態において、コミュニケーション発呼の検出は、予め定められたボタンを押下することを例にして説明したが、例えば、特定の局番に対する発呼（発信）としてもよい。この場合、端末装置１は、予め定められた局番に対する発呼の回数を記憶し、当該局番に対する発呼の回数を示す情報をサーバ３に送信するようにしてもよい。
【符号の説明】
【０１０３】
１、２ 端末装置
３ サーバ
１０ コミュニケーション発呼部
１１ 送信部
１２ 送信停止部
１３ キュー制御部
１４ 送信キュー
１５ 受信部
１６ データ保存部
１７ 表示部
１８ 意思情報データ
１９ 最終受信時刻
２０ 問い合わせ部
２１ アクセスキー管理部
２２ アクセスキー記憶部
３０ 受信部
３１ 蓄積データ更新・生成部
３２ 意思情報ＤＢ
３３ リクエスト受信部
３４ 送信データ生成部
３５ 送信部
３６ アクセスキー管理・生成部
３７ アクセスキーＤＢ
【技術分野】
【０００１】
本発明は、コミュニケーション提供システム、コミュニケーション提供方法、サーバ装置、及び端末装置に関する。
【背景技術】
【０００２】
現在、様々なコミュニケーション手段が提供されている。コミュニケーション手段の利用者は、シチュエーションや、そのときの欲求度合い等に合わせて、様々なコミュニケーション手段のうちからいずれかを選んでコミュニケーションを行っている。コミュニケーションを行うコミュニティに属する利用者の間で、最も多くの情報をやり取りできるコミュニケーション手段は、直接会って話すことである。直接会って話す場合、表情や、間合いなど、言葉以上の情報によって、聞く側は、発話者の意図を理解することができる。
【０００３】
ただし、コミュニケーションを行うために、常に直接会って話すことは難しい場合がある。例えば、コミュニティに属する利用者が、互いに離れた遠隔地にいる場合、常に直接会って話すことは難しいことがある。このような場合、別のコミュニケーション手段を用いてコミュニケーションを行っている。例えば、電話によって音声を介してコミュニケーションを図る、電子メールによって文字を介してコミュニケーションを図る、などが行われる。
【０００４】
ところで、日本では、携帯電話インフラが充実してきており、携帯メールなど、場所や、時間を選ばないコミュニケーション手段によりコミュニケーションを図りやすい環境が整ってきた。コミュニケーション手段のうち、携帯電話を用いたメールなどは、携帯電話の文字入力インタフェースのみによるコミュニケーション手段であり、直接会って話すコミュニケーションと異なる。例えば、携帯メールなどのコミュニケーション手段は、表情や、間合いなど、言葉以上の情報を得ることができない。しかし、比較的短い文字の情報を伝えるコミュニケーションを図る場合においては、時間や場所などのシチュエーションを選ばない手軽さがメリットとなる。
【０００５】
携帯メールなどを発信する携帯電話などにおいて、メールサービスが実現されるシーケンスの例として非特許文献１に記載されたシーケンスがある。非特許文献１に記載されているように、携帯メールなどを実行する携帯電話システムにおける独自の動作は、低レイヤに留まり、上位レイヤのアプリケーション、及びトランスポートレイヤは、ＨＴＴＰ、及びＴＣＰ／ＩＰに則って行われる（非特許文献１の図６）。すなわち、パケット発信処理までは、携帯電話ネットワークのシーケンスで、それ以降の処理は、上位レイヤの一般的なインターネット上のシーケンスで、端末からのＨＴＴＰリクエストに対してＴＣＰコネクションを張って通信を行い、そのセッションの完了までを見届けてから通信を完了する。
【０００６】
メールサービスは、送信者が何か伝えたいことがあるときに、送信用、及び受信用のメールサーバを介して送信者から受信者に情報を伝えることによってコミュニケーションが成立する。メールサービスは、アプリケーションレイヤから見て、送信者が情報を送信するタイミングと、受信者が当該情報を受信するタイミングとが異なり、非同期のコミュニケーションである。しかし、送信者が情報を送信するタイミングにおいて、送信者の操作する端末と、メールサーバとの間の通信は、ＴＣＰに則って端末が、サーバとの通信完了までを確認して終了する処理を行う同期通信である。
【先行技術文献】
【非特許文献】
【０００７】
【非特許文献１】ＮＴＴ ＤｏＣｏＭｏ テクニカル・ジャーナル Ｖｏｌ．７ Ｎｏ．２ ｐ．１６−２１
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、現実には、携帯電話を用いたメールよりも、さらに場所や、時間を限定せずにコミュニケーション発呼を発することによる簡便な意思表現が望まれる状況も想定される。すなわち、コミュニケーション発呼に要するアクションは、できるだけ簡潔に短時間で済ませる使い方が望まれる。
【０００９】
このような状況では、アクションの簡潔さが求められており、アクションを起こした当該セッションの間に時間をかけてでも意思表現の送達する確率を上げることより、意思表現の送達ができなかったときには、早々に不達と判断して処理を終えることが望ましい。メール等の一般的なデータ通信と違い、送信するデータの中身ではなく、コミュニティの他のメンバーは、「いつ」、「誰から」、「発呼のアクションの有無」が分かればよく、また１回のアクションも洩らすことなく、時間をかけて確実に伝えることよりは、アクションの簡潔さが優先される。
【００１０】
しかしながら、上述した従来技術によるメールサービスのような、インターネット上のアプリケーションの場合には、端末からコミュニケーション発呼を検出したとき、サーバとの通信が完了するまで、ＴＣＰで設定したタイムアウト時間だけリトライを繰り返し、サーバまでの送達の完了、又は失敗の情報が端末に返される。
すなわち、１回のセッションで、送りたい情報を伝えるための処理を繰り返して送達確率を上げる手法をとっている。そのため、例えば、無線伝搬環境の良くない環境で発信された場合、ユーザは、タイムアウトするまでしばらく待たされることになるという問題がある。
【００１１】
本発明は、このような事情を考慮してなされたものであり、その目的は、無線伝搬環境のよくない場所であっても、発信がタイムアウトするまでユーザを待たせることなく、簡潔な操作により入力した情報を送信するコミュニケーション提供システム、コミュニケーション提供方法、サーバ装置、及び端末装置を提供することにある。
【課題を解決するための手段】
【００１２】
上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムであって、前記端末装置は、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積し、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信し、送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている前記回数をクリアし、前記サーバ装置は、前記端末装置から受信した前記回数を蓄積し、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信することを特徴とするコミュニケーション提供システムである。
【００１３】
本発明は、上記の発明において、前記端末装置は、前記サーバ装置への前記回数の送信処理を強制的に停止させる送信停止手段を更に備え、前記送信停止手段により前記回数の送信処理が強制的に停止させられると、前記蓄積されている前記回数のクリアを行わないことを特徴とする。
【００１４】
本発明は、上記の発明において、前記端末装置は、前記サーバ装置へリクエストを送信するとき、最後にサーバ装置へのアクセスが成功した時刻から現在時刻までの期間示す情報を付加してリクエストを送信し、前記サーバ装置は、前記リクエストに付加されている情報が示す期間における、単位時間それぞれの前記回数を返信することを特徴とする。
【００１５】
本発明は、上記の発明において、前記サーバ装置は、前記端末装置毎にアクセスキーを生成し、更に、各端末装置のサーバ装置へのアクセス回数をカウントし、前記端末装置から所定の回数のアクセスがあると、新たにアクセスキーを生成し、所定の回数のアクセスをした前記端末装置のアクセスに対するリクエストとして送信し、前記端末装置は、前記蓄積されている前記回数を前記サーバ装置に送信する際に、前記回数とともに、前記サーバ装置から受け渡されたアクセスキーを送信し、前記サーバ装置は、前記端末装置が送信してきたアクセスキーと、当該サーバで管理するアクセスキーとが同じ場合、該アクセスキーを送信した前記端末装置にアクセスを許可することを特徴とする。
【００１６】
本発明は、上記の発明において、前記サーバ装置は、現在有効なアクセスキー以外に、各端末装置が最後に当該サーバ装置へのアクセスが成功したときのアクセスキーを予備のアクセスキーとして保存し、前記端末装置から前記予備のアクセスキーでのアクセスがあった場合には、正しいアクセスと判定してアクセスを許可し、そのレスポンスとして更新したアクセスキーを前記端末装置に返信することを特徴とする。
【００１７】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供方法であって、前記端末装置が、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積するステップと、前記端末装置が、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信するステップと、前記端末装置が、前記サーバ装置から当該情報を受信したことを示す応答信号を受信した場合、前記蓄積されている前記回数をクリアするステップと、前記サーバ装置が、前記端末装置から受信した前記回数を蓄積するステップと、前記サーバ装置が、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信するステップとを含むことを特徴とするコミュニケーション提供方法である
【００１８】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおける端末装置であって、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出する検出手段と、前記検出手段が前記入力操作を検出した単位時間毎の回数を蓄積する記憶手段と、前記検出手段が前記入力操作を検出すると、前記記憶手段に記憶されている前記回数を前記サーバ装置に送信する送信手段と、前記送信手段が送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記記憶手段に蓄積されている前記回数をクリアする記憶制御手段と、自端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記サーバ装置に送信する問い合わせ手段と、前記問い合わせ手段により送信されたリクエストに対して前記サーバ装置から返信される他の端末装置の単位時間毎の前記回数を受信する受信手段とを備えることを特徴とする端末装置である。
【００１９】
また、上述した課題を解決するために、本発明は、サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおけるサーバ装置であって、予め定められた入力操作による発呼を検出した回数を単位時間毎に蓄積し、発呼を検出すると前記蓄積されている発呼の回数を前記サーバ装置に送信し、送信した発呼の回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている発呼の回数をクリアする端末装置から受信した発呼の回数を蓄積し、前記端末装置から該端末装置の属するグループと同じグループに属する他の端末装置から受信した発呼の回数を要求するリクエストを受信すると、蓄積している発呼の回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する発呼の回数を該リクエストを送信した前記端末装置に返信することを特徴とするサーバ装置である。
【発明の効果】
【００２０】
この発明によれば、無線伝搬環境のよくない場所であっても、ユーザを待たせることなく、簡潔な操作により入力した情報を送信することができる。
【図面の簡単な説明】
【００２１】
【図１】本発明によるコミュニケーション手段が適用される範囲を説明するための概念図である。
【図２】本発明の実施形態による基本的なシステム構成を示す概念図である。
【図３】本第１実施形態による端末装置１とサーバ３の構成例を示すブロック図である。
【図４】本第１実施形態の端末装置による、送信キュー１４への蓄積方法を説明するための概念図である。
【図５】本第１実施形態によるサーバ３の意思情報ＤＢのデータ構成例を示す概念図である。
【図６】本第１実施形態において、サーバ３の送信データ生成部３４による、端末装置へ送信する送信データの抽出方法の一例を示す概念図である。
【図７】本第１実施形態による端末装置１の表示部１７での受信した情報の表示例を示す概念図である。
【図８】本第１実施形態において、端末装置１がサーバ３に蓄積された情報をリクエストして取得する際の動作を説明するための概念図である。
【図９】本第１実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。
【図１０】本第１実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。
【図１１】本第１実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。
【図１２】本第１実施形態による、問い合わせトリガ発生時の端末装置１の動作を説明するためのフローチャートである。
【図１３】本第１実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。
【図１４】本第２実施形態による端末装置１とサーバ３との構成例を示すブロック図である。
【図１５】本第２実施形態による、アクセスキーＤＢ３７にて管理する情報の例を示す概念図である。
【図１６】本第２実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。
【図１７】本第２実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。
【図１８】本第２実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。
【図１９】本第２実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。
【発明を実施するための形態】
【００２２】
以下、本発明の一実施形態を、図面を参照して説明する。
【００２３】
図１は、本発明によるコミュニケーション手段が適用される範囲を説明するための概念図である。図１に示すように、直接会って話すことは、コミュニケーションするコミュニティに属する人の間で、最も多くの情報のやり取りができるコミュニケーション手段である。そのとき、表情や、間合いなど、言葉以外の情報によって、聞く側は、発話者の意図を理解することができる。ただし、コミュニケーションをとるためには、直接会う必要があり、コミュニケーションのしやすさという点では他のコミュニケーション手段に比べて行いにくい。
【００２４】
次に、電話による音声通話や、テレビ電話による映像と音声通話によるコミュニケーション手段は、直接会うことに比べれば情報量が少ないが、より手軽にコミュニケーションを図ることができる。同様に、携帯電話による音声通話は、時間や、場所に限定されず（特定の場所（例えば、電車内、病院施設内）では使用できないが）、更に、手軽にコミュニケーションを図ることができる。
そして、ＰＣ（パーソナルコンピュータ）や、携帯電話を用いた、電子メールや、携帯メールは、時間や、場所に限定されず、文字を介してコミュニケーションを図るという点で、１回のコミュニケーションにより伝達される報量は少ないが、手軽にコミュニケーションを図ることができる。
【００２５】
本発明では、従来の携帯メールに比べて、伝えられる情報は、文字による情報より少ない情報になるが、携帯メールより、更にいつでもどこでも伝えられる、更に簡易なインタフェースによるコミュニケーション手段を提供することを想定している。提供するコミュニケーション手段によって、非同期にコミュニケーション発呼の情報だけを、継続的にコミュニティ内に発し合うことによって、ミュニティの中で常に繋がっている感を実現することを目的とする。そして、コミュニティ内の互いの状況を推察し、相互理解を更に深めようとするものである。
【００２６】
図２は、本発明の実施形態による基本的なシステム構成を示す概念図である。本発明では、図２に示すように、複数のユーザが携帯する無線通信機能を有する端末装置１、２を、コミュニケーションを行うコミュニティ単位でグループとしてサーバ３で記憶する。各端末装置１、２は、ユーザがコミュニティに対してコミュニケーションの意思を示す情報を入力したことを検出する機能を有する。例えば、端末装置１が、ボタンを押すなどの操作をトリガとし、ボタンが押下されたことを検出すると、「そのユーザがボタンを押下した事実」を示す情報がサーバ３に伝わる。そして、サーバ３に「あのユーザが○○時○○分にボタンを押した」ことを示す情報が蓄積される。さらに、サーバ３から、当該コミュニティの他のユーザの端末装置２に、その情報が配信され、「あの人が今ボタンを押した」という情報が表示される。
【００２７】
このように、本発明のシステムは、コミュニティの間で、あの人がいつボタンを押した／押していない、という情報を共有するコミュニケーション手段である。ボタンの押下等で完結する最小限のアクションで伝えられるコミュニケーションで、文字にもならない、相手のことをノックするようなコミュニケーションを実現する。ボタンを押して伝えたいことの意味は、予めコミュニティの中で共有させておいてもよいし、コミュニケーションを続ける中で互いに暗黙の使い方をしてもよい。
また、ボタンの押下の回数毎に異なる意味を予め対応付けておき、当該対応の情報を共有するようにしてもよい。
【００２８】
端末装置１、２は、単位時間毎の発呼（コミュニケーション発呼）の回数を蓄積するキューを備え、ユーザによる発呼を検出すると、キューに蓄積されている発呼の回数を加算した後、キューに蓄積されたデータをサーバ３に送信し、サーバ３への送信が成功した場合には、キューをクリアし、サーバ３への送信が失敗した場合には、キューに蓄積されたデータをそのまま保存する。
【００２９】
サーバ装置３は、端末装置１、２から受信した単位時間毎の発呼（コミュニケーション発呼）の回数を蓄積し、端末装置１、２からのリクエストに応じて、該端末装置１、２と同じグループに属する端末装置から受信した単位時間毎の発呼の回数を返信する。
【００３０】
本発明によれば、ユーザを待たせることなく、簡潔な操作で「コミュニケーション発呼」を行うことができる。無線伝搬環境が良くない等の理由で送信できなかった「コミュニケーション発呼」を、後からまとめて迅速に送信することができる。
【００３１】
以下に、本発明のポイントを説明する。
（１）端末装置１、２の機能として、コミュニケーション発呼を検出する機能だけでなく、送信停止を検出する機能を有する。端末装置１、２は、予め決めておいた現在時刻からの単位時間毎の送信キューを有する。送信キューは、「現在時刻から１０分前から２０分前までの１０分の間に発せされたコミュニケーション発呼」といったものになる。また、コミュニケーション発呼を検出することより、送信が開始されて、送信が終わらないうちに、送信停止を検出したときには、送信キューに蓄積される。
【００３２】
送信キューは、時刻の変化によってシフトされていく。コミュニケーション発呼したタイミングにサーバ３に接続して送信するときには、送信キュー情報を送信する。送信後、送信キューは、クリアされる。
【００３３】
端末装置１、２が本方式を具備することによって、端末装置１、２を携帯するユーザが待たされることなく、簡潔にコミュニケーション発呼することを短時間で完結することが可能になる。更に、無線伝搬環境の良くない場所で発呼する際には、キューキングして送信することによって、送信できなかったコミュニケーション発呼を可能にしながら、単位時間の発呼回数というように、キューイング情報をまとめることによって、送信する情報量を少なくし、キュー情報送信時も迅速な送信が可能になる。
【００３４】
（２）サーバ３は、各コミュニティのグループ、その中のグループメンバのコミュニケーション発呼のログ（履歴）を、予め決めておいた単位時間毎の発呼回数として蓄積する。
サーバ３が本方式を具備することによって、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況を、アクションを発した大まかな時刻とともに小容量のデータで迅速に送信することができる。
【００３５】
（３）端末装置１、２の機能として、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況を、サーバ３に問い合わせる機能を持つ。問い合わせのリクエストパラメータとして、自分が最後にサーバ３へのアクセスが成功した時刻を、端末装置１、２内に記憶しておいて、その時刻から現在時刻までの間をパラメータとして、サーバ３は、リクエストに含まれる期間の単位時間分の発呼回数の集合をレスポンスする。
【００３６】
端末装置１、２とサーバ３とが本機能を具備することによって、所属するコミュニティの他のメンバーのコミュニケーション発呼の状況について、端末装置１、２が必要とする分だけの情報を、簡易なインタフェースで問い合わせて、少ない情報量でレスポンスすることができ、効率的に軽量な通信が可能となる。
【００３７】
（４）上記（１）〜（３）の端末装置１、２とサーバ３との通信で、クローズドなコミュニティ内で、セキュアでありながら、コミュニケーション発呼の簡潔さを損なわない通信を行う方法として、以下の機能を持つ。
サーバ３は、端末装置毎にアクセスキーを生成する機能を持ち、各端末装置１、２のサーバ３へのアクセス回数をカウントする機能を持ち、予め決めておいた一定回数のアクセスがあったら、新たにアクセスキーを生成して、端末装置１、２のアクセスに対するリクエストとして、端末装置１、２に送信する機能を持つ。
【００３８】
端末装置１、２は、サーバ３から受け渡されたアクセスキーとともにコミュニケーション発呼を示す情報をサーバ３に送信する。サーバ３は、端末装置１、２の送信してきたアクセスキーとサーバ３で管理するアクセスキーとが同一である場合に、正しいアクセスと判断して処理を行う。また、サーバ３では、現アクセスキー以外に、各端末装置１、２が最後にサーバ３へのアクセスが成功したアクセスキーを、予備のアクセスキーとして保存する。端末装置１、２から予備のアクセスキーでのアクセスがあった場合には、アクセスを許可する処理を行い、そのレスポンスとして、更新したアクセスキーを端末装置１、２に返信する。
【００３９】
本機能を具備することによって、端末装置１、２からのアクセスに対して、インクリメントするキーを用いることによってなりすます不正アクセスを困難にする。さらに、前回成功したアクセスキーを予備アクセスキーとして保管することによって、無線伝搬環境の良くない場所で、端末装置１、２がサーバ３に対して、端末装置１、２が途中で送信停止の入力を検出して送信を停止させ、端末装置１、２とサーバ３との間で、現アクセスキーに不整合が起こったときも、端末装置１、２のアクセス不可になることを回避することが可能になる。
【００４０】
Ａ．第１実施形態
まず、本発明の第１実施形態について説明する。なお、以下の説明において、端末装置１とサーバ３とについて説明するが、サーバ３で管理されるすべての端末装置（例えば、端末装置２）は、端末装置１と同じ構成を有する。
【００４１】
図３は、本第１実施形態による端末装置１とサーバ３の構成例を示すブロック図である。図３において、端末装置１は、携帯電話や、ＰＤＡ等のユーザが携帯して利用する無線通信機能を備える端末からなる。端末装置１は、コミュニケーション発呼部１０、送信部１１、送信停止部１２、キュー制御部１３、送信キュー１４、受信部１５、データ保存部１６、表示部１７、意思情報データ１８、最終受信時刻１９、及び問い合わせ部２０を備えている。
【００４２】
コミュニケーション発呼部１０は、端末装置１のユーザが、予め登録してあるコミュニティのメンバーに対して、当該ユーザが何らかコミュニケーションの意思を示す情報を入力する手段であり、ユーザインタフェースとして普段の端末装置１の利用からできるだけ簡単にアクセスできることが望ましい。例えば、携帯電話上で常時動作するアプリケーションで端末機能を実現し、携帯電話が備える、あるボタンをコミュニケーション発呼部１０に割り当て、当該ボタンが押下されることにより、コミュニケーションの意思を示す情報が入力されたことを検出する。以下、コミュニケーション発呼部１０が、ユーザのコミュニケーションの意思を示す情報を入力することをコミュニケーション発呼という。
【００４３】
送信部１１は、コミュニケーション発呼部１０によりコミュニケーション発呼が行われると（ユーザが端末装置１上のボタンを押下すると）、後述のキュー制御を一旦行ってから、送信キュー１４を介して、サーバ３に当該ユーザがコミュニケーション発呼を行ったことを通知する。
【００４４】
送信停止部１２は、送信部１１によるサーバ３への送信処理中に、ユーザ操作に応じて、サーバ３への送信を中止する。送信停止部１２は、端末装置１上のボタンに紐づけて、ボタン押下時に機能する等によって実現する。送信停止部１２は、無線通信の伝搬環境が良くないときなど、端末装置１がサーバ３への通信するために時間を要する場合に、端末装置１側から直ちに送信処理を停止するための機能である。送信停止部１２が機能したとき、送信中であったデータは、キュー制御部１３によって送信キュー１４に蓄積される。キュー制御部１３は、送信キュー１４に対して、コミュニケーション発呼部１０での発呼動作、送信部１１でのサーバ３への送信動作、送信停止動作において、送信キュー１４への送信情報の保存、読み出し、クリアなどを制御する。
【００４５】
受信部１５は、サーバ３から送信されるデータを受信する。データ保存部１６は、受信部１５による受信データを、意思情報データ１８として保存し、保存しているサーバ３からの最終受信時刻１９を更新する。表示部１７は、上記受信データ、又は意思情報データ１８に従って、所属するグループのメンバーのコミュニケーション発呼に関する情報を表示する。最終受信時刻１９は、最後にサーバ３からデータを受信した時刻を記憶する記憶部である。問い合わせ部２０は、最終受信時刻１９に記憶されている時刻を示す情報を参照して、予め定めた周期、ボタン押下、携帯オープン等を検出して、サーバ３上のデータ取得のリクエストをサーバ３に発する。
【００４６】
サーバ３は、受信部３０、蓄積データ更新・生成部３１、意思情報ＤＢ３２、リクエスト受信部３３、送信データ生成部３４、及び送信部３５を備えている。受信部３０は、端末装置１が送信したコミュニケーション発呼の情報を受信する。蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を意思情報ＤＢ３２に蓄積する。
【００４７】
リクエスト受信部３３は、端末装置１からのリクエストを受信し、該リクエストの内容を解析する。該リクエストには、当該端末装置１の所属するグループのユーザのコミュニケーション発呼に対して、「過去のどれだけの時間のデータが必要か」が記述されている。送信データ生成部３４は、端末装置１からコミュニケーション発呼の情報や、リクエストが要求されたことを検出すると、端末装置１に送信する送信データを生成する。送信部３５は、上記送信データを端末装置１に送信する。
【００４８】
図４は、本第１実施形態の端末装置１による、送信キュー１４へのコミュニケーション発呼した回数を示す情報の蓄積方法を説明するための概念図である。図において、現在時刻を「現在時」、現在時の次に訪れる単位時間の正時時刻を「現在正時」として定義している。また、時間軸上の黒点が発呼を示している。
【００４９】
現在時から遡って予め定めた単位時間当たりのコミュニケーション発呼した回数を、単位時間毎にカウントする。図示の例では、単位時間を１０分とし、現在時（現在時刻）が１１：２６付近であるとすると、現在時刻を含む単位時間である１１：２０〜１１：３０までの発呼回数が１回で、その前の１１：１０〜１１：２０までの発呼回数が３回で、その前の１１：００〜１１：１０までの発呼回数が２回、それ以前は０回であることを指している。
【００５０】
システム内で用いる単位時間は、サーバ３と端末装置１との間で共有されており、端末装置１からサーバ３に送信する情報は、「キューを形成する単位時間の数（図示の例では５個）」、「各キューに蓄積された発呼回数」の情報だけを送信すれば、サーバ３側は、当該ユーザが単位時間当たりに何回発呼したかという情報として、ユーザのコミュニケーション発呼の意思を認識することができる。送信キュー１４には、サーバ３への送信が最後に成功してから検出したコミュニケーション発呼した回数を示す情報だけを記憶し、サーバ３への送信が成功すると、送信キュー１４内は、クリアされる。
【００５１】
端末装置１からサーバ３への送信キュー１４内の情報の送信タイミングは、コミュニケーション発呼したタイミングでもよいし、端末装置１で一定時間蓄積した後、まとめて送信するようにしてもよい。
端末装置１が、送信停止部１２の機能と、コミュニケーション発呼したことを送信キュー１４に蓄積する機能とを組み合わせて具備することによって、ユーザは、無線通信の伝搬環境が良くないなどによってサーバ３への送信に時間がかかる場合に、コミュニケーション発呼したことをサーバ３に送信することを簡単に取りやめることができる。
また、そのコミュニケーション発呼したことを蓄積して、無線通信の伝播環境が改善した際に、サーバ３に送信することが可能となる。また、送信する情報を単位時間当たりのコミュニケーション発呼した回数として送信キュー１４に蓄積することによって、サーバ３に送信するデータを小さくし、データ送信に要する時間を短くすることを可能にしている。
【００５２】
図５は、本第１実施形態によるサーバ３の意思情報ＤＢ３２のデータ構成例を示す概念図である。意思情報ＤＢ３２は、複数のコミュニケーションをとりあうコミュニティの情報をグループＩＤ毎に管理し、各グループに所属するユーザの情報を管理する。各ユーザがコミュニケーション発呼を行った際に端末装置１から送信されてくる情報は、単位時間当たりの当該ユーザの当該グループに対する発呼回数として蓄積される。
【００５３】
図５に示す例では、単位時間を１０分として、現在時刻から１０分単位に、各ユーザが何回発呼したかを蓄積した例である。例えば、グループＩＤ「０００１」に所属するユーザＩＤ「０００２」の端末装置の場合には、２時間前から１時間前までの１時間に発生した１０分毎の発呼回数は、古い順に、０回、３回、１回、０回、１回、１回となる。単位時間は、本システムを用いるサービスに即した間隔で設定すればよい。
【００５４】
例えば、サークル内のメンバーの緩やかなコミュニケーション発呼を表示するツールとして用いるなら、コミュニケーション発呼の時間の正確さにシビアな要求はなく、例に示すように、１０分間に何回発呼があったかという情報で十分である。該蓄積方法によれば、すべてのコミュニケーション発呼について、「グループＩＤ」、「ユーザＩＤ」、「発呼時刻」の組み合わせで蓄積するよりも、少量のデータを蓄積すればよく、また、蓄積したデータを端末装置１に送信する際に必要なデータを抽出する際にも、アクセスしやすい形態をとることができる。
【００５５】
本第１実施形態において、送信キュー１４のために規定する単位時間は、端末装置１で設定できるパラメータとし、サーバ３への送信情報の中に当該端末装置１で設定している単位時間情報を重畳させて送信し、サーバ３がその情報を認識する機能を具備することによって、当該端末装置１を用いるユーザが求めるコミュニケーション発呼の間隔の粒度を定義することが可能となる。
【００５６】
図６は、本第１実施形態において、サーバ３の送信データ生成部３４による、端末装置１へ送信する送信データの抽出方法の一例を示す概念図である。送信データ生成部３４は、例えば、グループＩＤ「０００１」のメンバーのいずれかに送信するためのデータを意思情報ＤＢ３２から抽出するには、該当するグループＩＤを持つユーザのレコードを抽出し、送信に必要な分のコミュニケーション発呼のデータを抽出すればよい。
【００５７】
図示の例では、端末装置１に送信するための情報として、現在時から遡った３時間分のデータを抽出している。意思情報ＤＢ３２に蓄積した情報から、必要な情報を切り出すイメージとなる。本第１実施形態で実現するコミュニケーションは、非同期なコミュニケーションであるため、サーバ３から端末装置１にデータを送信するトリガは、端末装置１からの送信を契機、又は、端末装置１からのリクエストを契機、又は、サーバ３から定期的な送信等のいずれの場合も考えられる。
【００５８】
図７は、本第１実施形態による端末装置１の表示部１７での受信した情報の表示例を示す概念図である。図示の例では、当該端末装置１を利用しているユーザが所属するグループには、３人のメンバーが所属し、端末装置１は、それらのメンバーの過去３時間のコミュニケーション発呼の情報を、サーバ３から取得したとする。
【００５９】
表示部１７には、取得したグループのメンバーのコミュニケーション発呼の情報を時系列的なグラフとして可視化されている。すなわち、表示部１７の画面上、縦方向に奥行きを持って時間経過が示されており、円柱の高さが発呼回数を示している。例えば、ＩＤ０００４のＣさんは、３時間のうち、直近の１０分間に１回のアクセスがあったことを示している。
【００６０】
コミュニティがサークル内の緩やかなコミュニケーションの手段として用いられているならば、当該ユーザがＣさんであるとすると、Ｂ君がしばらくの間、継続的にコミュニケーション発呼の形跡である履歴を示す情報があるところから、今、Ｂ君が電話や、メールなどのコミュニケーションをとりやすい状況にあることが予想される、といった利用シーンが考えられる。
【００６１】
図８は、本第１実施形態において、グループＩＤ「０００１」に所属しているユーザＩＤが割り当てられている端末装置１が、サーバ３に蓄積された情報をリクエストして取得する際の動作を説明するための概念図である。端末装置１の問い合わせ部２０は、予め定めた周期、ボタン押下、携帯オープンする操作等を検出して、サーバ３上のデータ取得のリクエストをサーバ３に発する。
【００６２】
図示の例では、端末装置１から「当該グループのコミュニケーション発呼のデータについて、過去１時間分の要求」がリクエストされた場合を示しており、サーバ３は、該リクエストに対して、グループＩＤ「０００１」に所属するユーザＩＤ「０００１」、「０００２」、「０００４」に関する、現在から遡って１時間分のコミュニケーション発呼のデータを抽出し、端末装置１への送信データを生成する。
【００６３】
次に、本第１実施形態の動作について説明する。
図９は、本第１実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、コミュニケーション発呼部１０は、コミュニケーション発呼（所定のボタンの押下）を検出したか否かを判定し（ステップＳ１）、コミュニケーション発呼が検出されない場合には、ステップＳ１を繰り返す。一方、コミュニケーション発呼が検出された場合には、キュー制御部１３は、コミュニケーション発呼の回数として１回分を送信キュー１４に蓄積する（ステップＳ２）。次に、送信部１１は、当該コミュニケーション発呼の情報（「キューを形成する単位時間の数」及び「各キューに蓄積された発呼回数」それぞれを示す情報）を送信する（ステップＳ３）。
【００６４】
次に、送信部１１は、サーバ３からリクエスト「ＯＫ」を受信したか否かを判定し（ステップＳ４）、サーバ３からリクエスト「ＯＫ」を受信した場合には、コミュニケーション発呼の情報の送信が成功したことを示すので、キュー制御部１３は、送信キュー１４内をクリアする（ステップＳ５）。
ここで、リクエスト「ＯＫ」は、サーバ３が端末装置１からコミュニケーション発呼の情報を受信したことを示す応答の信号であって、サーバ３が端末装置１に送信する信号である。
【００６５】
一方、ステップＳ４において、サーバ３からリクエスト「ＯＫ」を受信しなかった場合には、送信部１１は、リクエストがタイムアウトしたか否かを判定し（ステップＳ６）、タイムアウトした場合には、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する（ステップＳ８）。
【００６６】
一方、ステップＳ４においてサーバ３からリクエスト「ＯＫ」を受信せず、かつ、ステップＳ６においてタイムアウトでもない場合には、送信停止部１２は、ユーザによる送信停止のアクションを検出したか否かを判定し（ステップ７）、ユーザによる送信停止のアクションを検出した場合には、上記ステップＳ８へ進み、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する。
【００６７】
また、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもなく、送信停止のアクションも検出しない場合には、ステップＳ４に戻り、上述した動作を繰り返す。
【００６８】
図１０は、本第１実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、受信部３０は、端末装置１から送信されるコミュニケーション発呼の情報を受信し（ステップＳ１０）、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ１１）。
【００６９】
図１１は、本第１実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、受信部１５は、サーバ３からの送信データを受信し（ステップＳ２０）、表示部１７は、サーバ３からの受信データを、図７に示すように表示（更新）し（ステップＳ２１）、受信部１５は、最終受信時刻１９を更新し（ステップＳ２２）、データ保存部１６は、受信データを意思情報データ１８に保存する（ステップＳ２３）。
なお、ここでは、ステップＳ２１〜Ｓ２３を並列に行う場合を示したが、ステップＳ２１〜Ｓ２３を順次行うようにしてもよい。
【００７０】
図１２は、本第１実施形態による、問い合わせトリガ発生時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、他の端末装置１におけるコミュニケーション発呼に関する情報を要求する問い合わせトリガが検出されると（ステップＳ３０）、問い合わせ部２０は、最終受信時刻１９を参照し（ステップＳ３１）、サーバ３にリクエスト（「当該グループのコミュニケーション発呼のデータについて、最終受信時刻１９から現在正時までの期間に対応するコミュニケーション発呼のデータの要求」、例えば、当該グループのコミュニケーション発呼のデータについて、過去１時間分のデータの要求）を送信する（ステップＳ３２）。
なお、問い合わせトリガは、例えば、問い合わせトリガを入力するボタンが押下されることや、加速度センサを具備している端末装置１においてユーザが端末装置１を振るといった所定の操作である。すなわち、予め定められたユーザの操作が問い合わせトリガになる。
また、予め定めた期間が経過する毎に、問い合わせ部２０にステップＳ３１の動作を行わせるようにしてもよい。
【００７１】
図１３は、本第１実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、リクエスト受信部３３が端末装置１からリクエストを受信すると（ステップＳ４０）、送信データ生成部３４は、送信データを生成し（ステップＳ４１）、送信部３５は、生成した送信データを端末装置１に送信する（ステップＳ４２）。
【００７２】
図８に示す例では、サーバ３が、グループＩＤ「０００１」に所属しているユーザＩＤが割り当てられている端末装置１から、ユーザＩＤ（例えば、ユーザＩＤ「０００１」）を含むリクエストを受信し、グループＩＤ「０００１」に関して過去１時間分の要求があったとしている。そのとき、サーバ３の送信データ生成部３４は、図８に示す送信データ生成と同様の手法で、過去１時間分の当該グループの情報を送信データとして抽出する。端末装置１で保存するサーバ３からの最終受信時刻１９を参照する等によって、端末装置１が必要とする過去の時間を指定してリクエストを送信する機能を具備することによって、サーバ３から端末装置１に送信するコミュニケーション発呼の情報を、各端末装置１が必要分に即した情報量にすることにより、効率的な端末装置１へのデータ送信を可能にしている。
【００７３】
上記のように、端末装置１は、予め定められた入力操作によるコミュニケーション発呼を検出した回数を単位時間毎に送信キュー１４に蓄積し、コミュニケーション発呼を検出すると送信キュー１４に蓄積されているコミュニケーション発呼の回数をサーバ３に送信し、サーバ３から当該情報を受信したことを示す応答信号であるリクエスト「ＯＫ」を受信した場合、前記蓄積されている発呼の回数をクリアするようにした。
これにより、コミュニケーション発呼の回数をサーバ３に送信せずに、送信キュー１４に記憶させておくことができるので、無線伝搬環境のよくない状況においてコミュニケーション発呼の回数を再送せずに送信を停止して無線伝搬環境の状況が良くなった際に、送信キュー１４に記憶されているコミュニケーション発呼の回数をサーバ３に送信することができる。その結果、無線伝搬環境のよくない状況では、再送を繰り返したり、タイムアウトを待ったりすることなく送信を停止させることができ、ユーザを待たせることなく、簡潔な操作によりコミュニケーション発呼を入力させることができる。
また、無線伝搬環境がよくないなどの理由で送信できなかったコミュニケーション発呼の回数を後からまとめて迅速に送信することができる。
【００７４】
端末装置１は、更に、コミュニケーション発呼の回数をサーバ３に送信する処理を強制的に停止させる送信停止部１２を備え、送信停止部１２によりサーバ３への送信を停止させた際には、送信キュー１４のクリアを行わずに、記憶させたままにするようにした。
これにより、無線伝搬環境の状況がよくない場合、コミュニケーション発呼の回数をサーバ３に送信する処理を停止させることにより、コミュニケーション発呼の回数をサーバ３に送信する際に生じる再送や、タイムアウトの判定などのためにユーザを待たせることを防ぐことができる。
【００７５】
Ｂ．第２実施形態
次に、本発明の第２実施形態について説明する。
図１４は、本第２実施形態による端末装置１とサーバ３との構成例を示すブロック図である。本第２実施形態では、上述した本発明のポイント（４）の機能を付加したことを特徴とする。なお、図３に対応する部分には同一の符号を付けて説明を省略する。
【００７６】
端末装置１は、図３に示す構成に対して、更に、アクセスキー管理部２１、及びアクセスキー記憶部２２を備えている。アクセスキー管理部２１は、受信部１５がサーバ３からアクセスキー更新の信号を受信すると、アクセスキー記憶部２２に記憶されているアクセスキーを更新し、次回サーバ３へのアクセス時から新しいアクセスキーを、コミュニケーション発呼の情報や、リクエストに付与して送信する。
【００７７】
サーバ３は、図３に示す構成に対して、更に、アクセスキー管理・生成部３６、及びアクセスキーＤＢ３７を備えている。アクセスキー管理・生成部３６は、端末装置毎のアクセスキーを管理する。アクセスキーとは、各端末装置において、端末装置１からサーバ３に送信するデータや、リクエストに付与する情報である。サーバ３は、端末装置１からのアクセスに対し、アクセスキー管理・生成部３６において、当該端末装置のＩＤと受信データ内アクセスキーとを照合し、整合がとれたと判断した場合に、蓄積データ更新・生成部３１の処理を行う。
ここで、アクセスキーの照合とは、例えば、端末装置１を識別するＩＤと、当該端末装置から受信したデータ内アクセスキーとの組み合わせが、アクセスキーＤＢ３７に記憶されている当該端末とアクセスキーとの組み合わせに一致するか否かを判定することであり、一致した場合に整合がとれた場合、正しいアクセスであると判定する。
【００７８】
図１５は、本第２実施形態による、アクセスキーＤＢ３７にて管理する情報の例を示す概念図である。アクセスキーは、現在キーと予備キーとの２種が存在する。現在キーは、サーバ３が管理し、アクセスキーＤＢ３７に記憶されている現在のアクセスキーで、予備キーは、端末装置１がサーバ３へのアクセスが最後に成功したときに用いたアクセスキーである。前述の端末装置１のアクセスに対するアクセスキーの正否の判断は、現在キーとの照合を行い、もし現在キーと不整合であれば、予備キーとの整合を判断する。予備キーとの整合に成功した場合には、アクセスキーの照合は、正しいと判断し、正常の処理を行い、同時に端末装置１に新しいアクセスキーを再び送信する。
【００７９】
このように、アクセスキーＤＢ３７が、予備キーを記憶しておくことにより、サーバ３と、端末装置１との間でアクセスキーの不整合が発生しても、整合に成功した実績のある予備キーを用いることにより通信を継続して行うことができる。
例えば、無線伝搬環境がよくない状況において、アクセスキーの更新を行っている最中に通信が途切れるなどして、端末装置1が記憶するアクセスキーが更新されずに、サーバ３のみにおいてアクセスキーが更新されてしまう可能性がある。このような場合でも、サーバ３は、整合に成功した実績のある予備キーを使うことにより、受信したリクエストが登録されたユーザからのリクエストであるか否かを判定して、端末装置１との間の通信を行うことができる。
【００８０】
アクセスキーＤＢ３７には、端末装置毎に、現在キーでアクセスした回数をカウントし、アクセス回数として保存している。当該アクセス回数が予め定めた回数以上に達した端末装置１があると、現在キーを更新し、当該端末装置１に新しいアクセスキーを送信する。送信するタイミングは、アクセスキー更新用の情報の送信でもよいし、端末装置１からのリクエストに対する返信でもよい。
【００８１】
次に、本第２実施形態の動作について説明する。
図１６は、本第２実施形態による、コミュニケーション発呼時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、コミュニケーション発呼部１０は、コミュニケーション発呼（所定のボタンの押下）を検出したか否かを判定し（ステップＳ５０）、コミュニケーション発呼が検出されない場合には、ステップＳ５０を繰り返す。一方、コミュニケーション発呼が検出された場合には、キュー制御部１３は、コミュニケーション発呼の回数として１回分を蓄積する（ステップＳ５１）。
【００８２】
次に、アクセスキー管理部２１は、アクセスキー記憶部２２からアクセスキーを読み出し（ステップＳ５２）、送信部１１は、コミュニケーション発呼の情報に読み出したアクセスキーを付与し（ステップＳ５３）、当該コミュニケーション発呼の情報（「キューを形成する単位時間の数」、「各キューに蓄積された発呼回数」、「アクセスキー」）を送信する（ステップＳ５４）。
【００８３】
次に、送信部１１は、サーバ３からリクエスト「ＯＫ」を受信したか否かを判定し（ステップＳ５５）、サーバ３からリクエスト「ＯＫ」を受信した場合には、コミュニケーション発呼の情報の送信が成功したことを示すので、キュー制御部１３は、送信キュー１４内をクリアする（ステップＳ５６）。
【００８４】
一方、サーバ３からリクエスト「ＯＫ」を受信しなかった場合には、送信部１１は、リクエストがタイムアウトしたか否かを判定し（ステップＳ５７）、タイムアウトした場合には、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する（ステップＳ５９）。
【００８５】
一方、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもない場合には、送信停止部１２は、ユーザによる送信停止のアクションを検出したか否かを判定し（ステップ５８）、ユーザによる送信停止のアクションを検出した場合には、上記ステップＳ５９へ進み、キュー制御部１３は、送信しようとしていたコミュニケーション発呼の情報を送信キュー１４に保存する。
【００８６】
また、サーバ３からリクエスト「ＯＫ」を受信せず、かつ、タイムアウトでもなく、送信停止のアクションも検出しない場合には、ステップＳ５５に戻り、上述した動作を繰り返す。
【００８７】
図１７は、本第２実施形態による、サーバ３からデータ受信時の端末装置１の動作を説明するためのフローチャートである。端末装置１において、受信部１５は、サーバ３からの送信データを受信する（ステップＳ７０）。次に、アクセスキー管理部２１は、新しいアクセスキーを受信したか否かを判定し（ステップＳ７１）、サーバ３から新しいアクセスキーを受信した場合には、アクセスキー管理部２１は、アクセスキー記憶部２２に記憶されているアクセスキーを更新する（ステップＳ７２）。次に、表示部１７は、サーバ３からの受信データを、図７に示すように表示（更新）し（ステップＳ７３）、受信部１５は、最終受信時刻１９を更新し（ステップＳ７４）、データ保存部１６は、受信データを意思情報データ１８に保存する（ステップＳ７５）。
なお、ここでは、ステップＳ７３〜Ｓ７５を並列に行う場合を示したが、ステップＳ７３〜Ｓ７５を順次行うようにしてもよい。
【００８８】
図１８は、本第２実施形態による、端末装置１からのデータ受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、受信部３０が、端末装置１から送信されるコミュニケーション発呼の情報を受信すると（ステップＳ８０）、アクセスキー管理・生成部３６は、コミュニケーション発呼の情報に付加されているアクセスキーと現在キーとを照合し、双方が整合するか否かを判定する（ステップＳ８１）。
【００８９】
そして、アクセスキーと現在キーとが整合した場合には、アクセスキー管理・生成部３６は、現在キーの更新タイミングであるか否かを判定する（ステップＳ８２）。ここで、現在キーの更新タイミングでない場合には、アクセスキー管理・生成部３６は、アクセスキーＤＢ３７を参照し（ステップＳ８３）、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ８５）。
【００９０】
一方、ステップＳ８２において、現在キーの更新タイミングである場合には、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存する（ステップＳ８４）。次に、上記ステップＳ８５に進み、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する（ステップＳ８５）。
【００９１】
一方、ステップＳ８１において、アクセスキーと現在キーとが整合しなかった場合には、アクセスキー管理・生成部３６は、アクセスキーと予備キーとを照合し、双方が整合するか否かを判定する（ステップＳ８６）。そして、アクセスキーと予備キーとが整合した場合には、上記ステップＳ８４に進み、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存し、ステップＳ８５で、蓄積データ更新・生成部３１は、受信したコミュニケーション発呼の情報を、意思情報ＤＢ３２に蓄積する。
【００９２】
また、ステップＳ８１においてアクセスキーと現在キーとが整合せず、かつ、ステップＳ８６においてアクセスキーと予備キーとも整合しなかった場合には、送信部３５は、端末装置１にアクセスキー不整合を通知する（ステップＳ８７）。
【００９３】
図１９は、本第２実施形態による、端末装置１からのリクエスト受信時のサーバ３の動作を説明するためのフローチャートである。サーバ３において、リクエスト受信部３３が端末装置１からリクエストを受信すると（ステップＳ９０）、アクセスキー管理・生成部３６は、リクエストに付加されているアクセスキーと現在キーとを照合し、双方が整合するか否かを判定する（ステップＳ９１）。
【００９４】
そして、アクセスキーと現在キーとが整合した場合には、アクセスキー管理・生成部３６は、現在キーの更新タイミングであるか否かを判定する（ステップＳ９２）。ここで、現在キーの更新タイミングでない場合には、アクセスキー管理・生成部３６は、アクセスキーＤＢ３７を参照し（ステップＳ９３）、送信データ生成部３４は、送信データを生成し（ステップＳ９５）、送信部３５は、生成した送信データを端末装置１に送信する（ステップＳ９６）。
【００９５】
一方、ステップＳ９２において、現在キーの更新タイミングである場合には、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存する（ステップＳ９４）。次に、上記ステップＳ９５に進み、送信データ生成部３４は、送信データを生成し、上記ステップＳ９６で、送信部３５は、生成した送信データを端末装置１に送信する。
【００９６】
一方、ステップＳ９１において、アクセスキーと現在キーとが整合しなかった場合には、アクセスキー管理・生成部３６は、アクセスキーと予備キーとを照合し、双方が整合するか否かを判定する（ステップＳ９７）。そして、アクセスキーと予備キーとが整合した場合には、上記ステップＳ９４に進み、アクセスキー管理・生成部３６は、現在キーを更新し、アクセスキーＤＢ３７に保存し、上記ステップＳ９５に進み、送信データ生成部３４は、送信データを生成し、上記ステップＳ９６で、送信部３５は、生成した送信データと更新した現在キーとを端末装置１に送信する。
【００９７】
また、ステップＳ９１においてアクセスキーと現在キーとが整合せず、かつ、ステップＳ９７においてアクセスキーと予備キーとも整合しなかった場合には、送信部３５は、端末装置１にアクセスキー不整合を通知する（ステップＳ９８）。
【００９８】
上述した第２実施形態によれば、一定の頻度で更新するアクセスキーによって、端末装置１をなりすましてサーバ３にアクセスすることを困難にしながら、無線伝搬環境が良くないシチュエーションでの通信によって、端末装置１とサーバ３とが管理するアクセスキーに不整合が起こった場合のために、成功したアクセスキーを予備キーとして保存することによって、不整合時のアクセスを回避することができ、予備キーでのアクセスが行われた時には、即座にアクセスキーを更新することによって、予備キー有効期間を極力短くしている。
【００９９】
なお、上述した第１、又は第２実施形態においては、サーバ３へのグループの登録は、ウェブサイトなどを経由して、代表者が各ユーザの携帯電話のメールアドレスを登録し、サーバ３から配信されたメールに記載されたサーバ３のＵＲＬにアクセスする等によって予め登録すればよい。
【０１００】
また、上述した第１、又は第２実施形態においては、端末装置１によるコミュニケーション発呼の検出は、１パターンを想定しているが、複数のボタンに異なる発呼に対応させて、複数の種類の情報を伝達するようにしてもよい。
【０１０１】
また、上述した第１、又は第２実施形態においては、端末装置１を携帯するユーザは、１つのグループに所属することを想定しているが、一人のユーザが複数のグループに所属することも可能である。この場合には、端末装置１における予めなされた設定に基づいて、１回のコミュニケーション発呼を、指定したグループ向けの情報として割り当てることになる。その際の端末装置１からサーバ３への送信情報には、当該情報が含まれ、サーバ３では、受信した情報がどのユーザのどのグループ向けのものかを、端末装置１において予めなされた設定に基づいて、認識する機能を有することとなる。
【０１０２】
また、上述した第１、又は第２実施形態において、コミュニケーション発呼の検出は、予め定められたボタンを押下することを例にして説明したが、例えば、特定の局番に対する発呼（発信）としてもよい。この場合、端末装置１は、予め定められた局番に対する発呼の回数を記憶し、当該局番に対する発呼の回数を示す情報をサーバ３に送信するようにしてもよい。
【符号の説明】
【０１０３】
１、２ 端末装置
３ サーバ
１０ コミュニケーション発呼部
１１ 送信部
１２ 送信停止部
１３ キュー制御部
１４ 送信キュー
１５ 受信部
１６ データ保存部
１７ 表示部
１８ 意思情報データ
１９ 最終受信時刻
２０ 問い合わせ部
２１ アクセスキー管理部
２２ アクセスキー記憶部
３０ 受信部
３１ 蓄積データ更新・生成部
３２ 意思情報ＤＢ
３３ リクエスト受信部
３４ 送信データ生成部
３５ 送信部
３６ アクセスキー管理・生成部
３７ アクセスキーＤＢ
【特許請求の範囲】
【請求項１】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムであって、
前記端末装置は、
他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積し、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信し、送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている前記回数をクリアし、
前記サーバ装置は、
前記端末装置から受信した前記回数を蓄積し、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信する
ことを特徴とするコミュニケーション提供システム。
【請求項２】
前記端末装置は、
前記サーバ装置への前記回数の送信処理を強制的に停止させる送信停止手段を更に備え、前記送信停止手段により前記回数の送信処理が強制的に停止させられると、前記蓄積されている前記回数のクリアを行わない
ことを特徴とする請求項１に記載のコミュニケーション提供システム。
【請求項３】
前記端末装置は、
前記サーバ装置へリクエストを送信するとき、最後にサーバ装置へのアクセスが成功した時刻から現在時刻までの期間示す情報を付加してリクエストを送信し、
前記サーバ装置は、
前記リクエストに付加されている情報が示す期間における、単位時間それぞれの前記回数を返信する
ことを特徴とする請求項１又は請求項２のいずれかに記載のコミュニケーション提供システム。
【請求項４】
前記サーバ装置は、
前記端末装置毎にアクセスキーを生成し、更に、各端末装置のサーバ装置へのアクセス回数をカウントし、前記端末装置から所定の回数のアクセスがあると、新たにアクセスキーを生成し、所定の回数のアクセスをした前記端末装置のアクセスに対するリクエストとして送信し、
前記端末装置は、
前記蓄積されている前記回数を前記サーバ装置に送信する際に、前記回数とともに、前記サーバ装置から受け渡されたアクセスキーを送信し、
前記サーバ装置は、
前記端末装置が送信してきたアクセスキーと、当該サーバで管理するアクセスキーとが同じ場合、該アクセスキーを送信した前記端末装置にアクセスを許可する
ことを特徴とする請求項１から請求項３のいずれか１項に記載のコミュニケーション提供システム。
【請求項５】
前記サーバ装置は、
現在有効なアクセスキー以外に、各端末装置が最後に当該サーバ装置へのアクセスが成功したときのアクセスキーを予備のアクセスキーとして保存し、前記端末装置から前記予備のアクセスキーでのアクセスがあった場合には、正しいアクセスと判定してアクセスを許可し、そのレスポンスとして更新したアクセスキーを前記端末装置に返信する
ことを特徴とする請求項４に記載のコミュニケーション提供システム。
【請求項６】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供方法であって、
前記端末装置が、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積するステップと、
前記端末装置が、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信するステップと、
前記端末装置が、前記サーバ装置から当該情報を受信したことを示す応答信号を受信した場合、前記蓄積されている前記回数をクリアするステップと、
前記サーバ装置が、前記端末装置から受信した前記回数を蓄積するステップと、
前記サーバ装置が、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信するステップと
を含むことを特徴とするコミュニケーション提供方法。
【請求項７】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおける端末装置であって、
他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出する検出手段と、
前記検出手段が前記入力操作を検出した単位時間毎の回数を蓄積する記憶手段と、
前記検出手段が前記入力操作を検出すると、前記記憶手段に記憶されている前記回数を前記サーバ装置に送信する送信手段と、
前記送信手段が送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記記憶手段に蓄積されている前記回数をクリアする記憶制御手段と、
自端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記サーバ装置に送信する問い合わせ手段と、
前記問い合わせ手段により送信されたリクエストに対して前記サーバ装置から返信される他の端末装置の単位時間毎の前記回数を受信する受信手段と
を備えることを特徴とする端末装置。
【請求項８】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおけるサーバ装置であって、
予め定められた入力操作による発呼を検出した回数を単位時間毎に蓄積し、発呼を検出すると前記蓄積されている発呼の回数を前記サーバ装置に送信し、送信した発呼の回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている発呼の回数をクリアする端末装置から受信した発呼の回数を蓄積し、
前記端末装置から該端末装置の属するグループと同じグループに属する他の端末装置から受信した発呼の回数を要求するリクエストを受信すると、蓄積している発呼の回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する発呼の回数を該リクエストを送信した前記端末装置に返信する
ことを特徴とするサーバ装置。
【請求項１】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムであって、
前記端末装置は、
他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積し、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信し、送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている前記回数をクリアし、
前記サーバ装置は、
前記端末装置から受信した前記回数を蓄積し、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信する
ことを特徴とするコミュニケーション提供システム。
【請求項２】
前記端末装置は、
前記サーバ装置への前記回数の送信処理を強制的に停止させる送信停止手段を更に備え、前記送信停止手段により前記回数の送信処理が強制的に停止させられると、前記蓄積されている前記回数のクリアを行わない
ことを特徴とする請求項１に記載のコミュニケーション提供システム。
【請求項３】
前記端末装置は、
前記サーバ装置へリクエストを送信するとき、最後にサーバ装置へのアクセスが成功した時刻から現在時刻までの期間示す情報を付加してリクエストを送信し、
前記サーバ装置は、
前記リクエストに付加されている情報が示す期間における、単位時間それぞれの前記回数を返信する
ことを特徴とする請求項１又は請求項２のいずれかに記載のコミュニケーション提供システム。
【請求項４】
前記サーバ装置は、
前記端末装置毎にアクセスキーを生成し、更に、各端末装置のサーバ装置へのアクセス回数をカウントし、前記端末装置から所定の回数のアクセスがあると、新たにアクセスキーを生成し、所定の回数のアクセスをした前記端末装置のアクセスに対するリクエストとして送信し、
前記端末装置は、
前記蓄積されている前記回数を前記サーバ装置に送信する際に、前記回数とともに、前記サーバ装置から受け渡されたアクセスキーを送信し、
前記サーバ装置は、
前記端末装置が送信してきたアクセスキーと、当該サーバで管理するアクセスキーとが同じ場合、該アクセスキーを送信した前記端末装置にアクセスを許可する
ことを特徴とする請求項１から請求項３のいずれか１項に記載のコミュニケーション提供システム。
【請求項５】
前記サーバ装置は、
現在有効なアクセスキー以外に、各端末装置が最後に当該サーバ装置へのアクセスが成功したときのアクセスキーを予備のアクセスキーとして保存し、前記端末装置から前記予備のアクセスキーでのアクセスがあった場合には、正しいアクセスと判定してアクセスを許可し、そのレスポンスとして更新したアクセスキーを前記端末装置に返信する
ことを特徴とする請求項４に記載のコミュニケーション提供システム。
【請求項６】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供方法であって、
前記端末装置が、他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出した単位時間毎の回数を蓄積するステップと、
前記端末装置が、前記入力操作を検出すると前記蓄積されている前記回数を前記サーバ装置に送信するステップと、
前記端末装置が、前記サーバ装置から当該情報を受信したことを示す応答信号を受信した場合、前記蓄積されている前記回数をクリアするステップと、
前記サーバ装置が、前記端末装置から受信した前記回数を蓄積するステップと、
前記サーバ装置が、前記端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記端末装置から受信すると、蓄積している前記回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する前記回数を該リクエストを送信した前記端末装置に返信するステップと
を含むことを特徴とするコミュニケーション提供方法。
【請求項７】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおける端末装置であって、
他の端末装置に対してコミュニケーションをしたいことを示す入力操作を検出する検出手段と、
前記検出手段が前記入力操作を検出した単位時間毎の回数を蓄積する記憶手段と、
前記検出手段が前記入力操作を検出すると、前記記憶手段に記憶されている前記回数を前記サーバ装置に送信する送信手段と、
前記送信手段が送信した前記回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記記憶手段に蓄積されている前記回数をクリアする記憶制御手段と、
自端末装置の属するグループに属する他の端末装置から受信した前記回数を要求するリクエストを前記サーバ装置に送信する問い合わせ手段と、
前記問い合わせ手段により送信されたリクエストに対して前記サーバ装置から返信される他の端末装置の単位時間毎の前記回数を受信する受信手段と
を備えることを特徴とする端末装置。
【請求項８】
サーバ装置を介して予め定められた同じグループに属する端末装置間で情報を伝達するコミュニケーション提供システムにおけるサーバ装置であって、
予め定められた入力操作による発呼を検出した回数を単位時間毎に蓄積し、発呼を検出すると前記蓄積されている発呼の回数を前記サーバ装置に送信し、送信した発呼の回数を受信したことを示す応答信号を前記サーバ装置から受信した場合、前記蓄積されている発呼の回数をクリアする端末装置から受信した発呼の回数を蓄積し、
前記端末装置から該端末装置の属するグループと同じグループに属する他の端末装置から受信した発呼の回数を要求するリクエストを受信すると、蓄積している発呼の回数のうちリクエストを送信した前記端末装置と同じグループに属する他の端末装置に対応する発呼の回数を該リクエストを送信した前記端末装置に返信する
ことを特徴とするサーバ装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【公開番号】特開２０１１−２５０００１（Ｐ２０１１−２５０００１Ａ）
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願番号】特願２０１０−１１９４１３（Ｐ２０１０−１１９４１３）
【出願日】平成２２年５月２５日（２０１０．５．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願日】平成２２年５月２５日（２０１０．５．２５）
【出願人】（０００００４２２６）日本電信電話株式会社 (13,992)
【Ｆターム（参考）】
[ Back to top ]