(57)【特許請求の範囲】
【請求項１】
データ通信路により接続された送信装置と受信装置との間で、プッシュ、ノーティファイ、またはプル方式のいずれかの通信方式で情報の通信を行う場合の前記送信装置が実行する通信方法であって、
前記情報が更新された場合、前記送信装置の状態情報と、前記受信装置から提供された前記受信装置の状態情報とに基づいて、前記情報の通信方式を決定し、
決定した通信方式がプッシュ方式の場合、前記更新された情報を前記受信装置に送信し、
決定した通信方式がノーティファイ方式の場合、更新通知を前記受信装置に送信し、
決定した通信方式がノーティファイ方式またはプル方式の場合、前記受信装置からの情報取得要求に基づき、前記更新された情報を前記受信装置に送信する通信方法。
【請求項２】
データ通信路により接続された送信装置と受信装置との間で、プッシュ、ノーティファイ、またはプル方式のいずれかの通信方式で情報の通信を行う通信システムに用いられる送信装置であって、
前記情報が更新された場合、前記送信装置の状態情報と、前記受信装置から提供された前記受信装置の状態情報とに基づいて、前記情報の通信方式を決定する方式決定部と、
決定した通信方式がプッシュ方式の場合、前記更新された情報を前記受信装置に送信し、  決定した通信方式がノーティファイ方式の場合、更新通知を前記受信装置に送信し、決定した通信方式がノーティファイ方式またはプル方式の場合、前記受信装置からの情報取得要求に基づき、前記更新された情報を前記受信装置に送信する情報送信部と、
を備える送信装置。
【請求項３】
前記方式決定部は、決定した通信方式を記録しておく履歴保存部と、
前記履歴保存部に記録されている前回の通信方式と前記決定した通信方式とが異なる場合に、前記決定した通信方式を前記受信装置に通知する決定方式通知部と、
をさらに備える請求項２に記載の送信装置。
【請求項４】
前記送信装置の状態情報は、送信装置の能力、送信装置の負荷状況、または前記情報の更新頻度を示す情報のうちの少なくともいずれかを含み、
前記受信装置の状態情報は、前記受信装置の能力、前記受信装置の負荷状況、前記情報の参照頻度、前記受信装置にて設定された通信方式を示す情報のうちの少なくともいずれかを含む、請求項２〜３に記載の送信装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、データ通信路により接続された機器間でデータ通信を行うための通信方式の決定方法に関する。
【０００２】
本発明では、情報とは、複数の機器で共有される各種形式のファイルやユーザ状態、ニュース、メッセージ等を含む。通信側及び受信側機器は、論理的に同じ情報を共有する。但し、受信側機器の情報と送信側機器の情報とでは、情報の所有形態が異なっていてもよい。例えば、送信側機器では、テキストデータそのものをハードディスク上に持っているが、受信側機器では、対応するイメージを画面上に表示しているだけでもよい。また、受信側機器の情報は、送信側機器の情報全てを持つ必要もない。
【０００３】
データ通信路は、パケット通信のような仮想的な通信路であっても良く、常時接続されている必要もない。また、データ通信路の途中に中継機器が存在していてもよい。
【０００４】
通信側機器と受信側機器とは、固定的な役割を持つ必要はない。例えば、ある場合には送信側である機器が、別の場合には受信側であってもよい。同一の機器が同時に送信側と受信側の役割を果たしていてもよい。
【０００５】
【従来の技術】
近年、社会全体のネットワーク化が進み、ユーザ間のコミュニケーションやニュース配信、広告配信等が、コンピューターネットワークや電話回線等のデータ通信路を用いて行われるようになっている。これらネットワーク通信では、データ通信路に接続された複数の情報機器上の情報を同期させることが、一般的に行われている。
【０００６】
複数の機器間で情報を同期させるには、情報機器間で最新の情報を送受信したり、最新情報をサーバから端末機器に配信する。データ通信路で接続された機器間で情報を送受信するための通信方式には、大別して以下の方式が存在する。
【０００７】
（１）プッシュ方式
受信側機器は送信側機器に予め登録されている。送信側機器の情報が更新されると、送信側機器はデータ通信路を介して更新情報を受信側機器に送信する。受信側機器は、更新情報を受信すると、自身が蓄積している情報を更新する。なお、送信側機器は、送信側の情報更新後直ちに通信情報の送信を行わずに、複数の更新情報をまとめて受信側機器に送信することもある。
【０００８】
この方式の利点及び欠点は、以下の通りである。
【０００９】
利点：受信側の情報は常に速やかに情報の更新を反映しており、ユーザが情報を参照するときに情報を取得するための通信が必要無く、したがって参照時の待ち時間が短い。
【００１０】
欠点：更新頻度が参照頻度よりも大きい場合、無駄な通信が生じる。そのため、通信路の負荷が高くなったり、通信側及び受信側機器の負荷が高くなったり、通信料金が高くなったりする。
【００１１】
（２）プル方式
まず、送信側機器の情報が更新される。その後、受信側機器が、ユーザの指示や時間の経過等のイベントによって、プル要求を送信側機器に送信する。送信側機器は、プル要求を受けると、更新情報を受信側機器に送信する。受信側機器は、更新情報を受信し、自身が蓄積している情報を更新する。送信側機器での情報の更新は、受信側機器に更新情報が送信されるまでに、複数回実行される場合がある。本発明では、受信側機器が定期的にプル要求を出す方式もプル方式に分類する。
【００１２】
この方式の利点及び欠点は、以下の通りである。
【００１３】
利点：情報を参照するときに初めてプル要求を出す方式では、更新頻度が参照頻度よりも大きい場合に無駄な通信が生じにくい。そのため、通信路の負荷が低くなり、送信側及び受信側機器の負荷が低くなり、通信料金が安くなる。
【００１４】
欠点：情報を参照するときに初めてプル要求を出す方式では、参照時に通信を行って更新情報を取得するため、待ち時間が長くなる。また、更新頻度が参照頻度よりも小さい場合、無駄な通信が生じる。そのため、通信路の負荷や送信側及び受信側機器の負荷が高くなったり、通信料金が高くなったりする。また、情報が更新されたことを速やかにユーザに通知することができない。定期的にプル要求を出す場合には、過剰なプル要求が必要になる場合が一般的であり、無駄な通信が生じ易い。
【００１５】
（３）ノーティファイ方式
受信側機器は、送信側機器に予め登録されている。送信側機器の情報が更新されると、送信側機器は更新通知を受信側機器に送信する。更新通知は、更新された情報そのものではなく、情報が更新されたという事実やその更新情報の識別子等である。受信側機器は、更新通知を受信すると、情報が更新されたことを示す更新印を該当の情報に付ける。その後、受信側機器において、ユーザの指示や時間の経過等のイベントによって情報の更新が行われる。
【００１６】
情報更新は次のように行う。受信側機器は、更新印のあるものについてのみプル要求を送信する。送信側機器では、更新情報を受信側機器に送信する。受信側機器は、受信した更新情報に基づいて、更新印のある情報を更新し、更新印を消去する。なお、更新印等を使用せずに、更新通知を受信すると直ちにプル要求を送信する方法も有る。また、送信側機器で情報を更新するたびに更新通知を行わず、複数の情報の更新をまとめた後、受信側機器に更新通知を送信する場合もある。
【００１７】
この方式は、プッシュ方式及びプル方式の中間的な利点及び欠点を持つ。
【００１８】
また、以上に述べた各種通信方式の長所及び欠点の他に、通信環境等によってはプッシュ方式が利用できない場合がある。例えば、インターネットでは、ファイヤーウォールの外側から内側にはプッシュ方式で情報を送ることができない場合が多い。さらに、上記の通信方式の組合せや細部を変更した通信方式が存在する。
【００１９】
【発明が解決しようとする課題】
従来、ユーザやシステム管理者の設定によって、ニーズに応じた通信方式が機器に設定されている。ある情報や利用者、受信側機器と、通信方式との組合せは、機器の起動時や設定の変更時に決定される。
【００２０】
しかし、前述の各通信方式の利点や欠点の関係や度合いは様々な要因で変化する。例えば、参照頻度が更新頻度よりも大きい場合は、プッシュ方式を用いる方が通信料金が安い。逆に、参照頻度が更新頻度が小さい場合、プル方式を用いた方が通信料金が安くなる。また、通信時間が短い場合には、プル方式の待ち時間が長いという欠点が小さくなる。これらの要因は、動的に変化するものも多いが、従来、設定した通信方式は状況に応じて変更されないので、前記要因の変化に応じた最適な通信が難しい。そのため、例えば以下のような問題が生じる。
【００２１】
（１）ある情報の項目を参照頻度が高いと考えてプッシュ方式を設定したが、実際にはあまり参照しない。そのため、必要もない通信料金が掛かってしまう。
【００２２】
（２）ある情報項目を参照頻度が高いと考えてプッシュ方式を設定したが、参照していない情報の量が大きかったので、無駄な通信料金を要してしまった。
【００２３】
（３）通信速度が十分に速いと考えてノーティファイ方式を設定したが、たまたま通信路が混雑していて時間がかかってしまった。
【００２４】
（４）更新頻度が小さいと考えてプッシュ方式を設定したが、ある期間だけ更新頻度が高くなっていて通信料金が高くなってしまった。
【００２５】
以上のような問題点に加え、通信方式を設定しておくだけでは動的に変化する様々な要因に対処した柔軟な動作を行うことができない。例えば、１）普段は参照時間を優先でプッシュ方式を用い、通信料金がかさんでくるとノーティファイ方式とする、２）普段はプッシュ方式で通信を行うが、サーバの負荷が高まってくるとノーティファイ方式にする、といった状況に応じた通信方式の切り替えが難しい。
【００２６】
本発明は、前述の課題を解決し、データ通信路の利用効率を向上し、データ通信路の負担及びコストを削減すると共に、利用者端末の負担及びコストを削減し、ユーザの利便性を高めることを目的とする。
【００２７】
【課題を解決するための手段】
前記課題を解決するために、本願第１発明は、データ通信路により接続された送信装置と受信装置との間で、プッシュ、ノーティファイ、またはプル方式のいずれかの通信方式で情報の通信を行う場合の前記送信装置が実行する通信方法であって、
・前記情報が更新された場合、前記送信装置の状態情報と、前記受信装置から提供された前記受信装置の状態情報とに基づいて、前記情報の通信方式を決定し、
・決定した通信方式がプッシュ方式の場合、前記更新された情報を前記受信装置に送信し、
・決定した通信方式がノーティファイ方式の場合、更新通知を前記受信装置に送信し、
・決定した通信方式がノーティファイ方式またはプル方式の場合、前記受信装置からの情報取得要求に基づき、前記更新された情報を前記受信装置に送信する、
通信方法を提供する。
【００２８】
本願第２発明は、データ通信路により接続された送信装置と受信装置との間で、プッシュ、ノーティファイ、またはプル方式のいずれかの通信方式で情報の通信を行う通信システムに用いられる送信装置であって、
・前記情報が更新された場合、前記送信装置の状態情報と、前記受信装置から提供された前記受信装置の状態情報とに基づいて、前記情報の通信方式を決定する方式決定部と、
・決定した通信方式がプッシュ方式の場合、前記更新された情報を前記受信装置に送信し、  決定した通信方式がノーティファイ方式の場合、更新通知を前記受信装置に送信し、決定した通信方式がノーティファイ方式またはプル方式の場合、前記受信装置からの情報取得要求に基づき、前記更新された情報を前記受信装置に送信する情報送信部と、
を備える送信装置。を提供する。
【００２９】
本願第３発明は、前記第２発明において、
・前記方式決定部は、決定した通信方式を記録しておく履歴保存部と、
・前記履歴保存部に記録されている前回の通信方式と前記決定した通信方式とが異なる場合に、前記決定した通信方式を前記受信装置に通知する決定方式通知部と、
をさらに備える送信装置を提供する。
【００３０】
本願第４発明は、前記第２または３発明において、
・前記送信装置の状態情報は、送信装置の能力、送信装置の負荷状況、または前記情報の更新頻度を示す情報のうちの少なくともいずれかを含み、
・前記受信装置の状態情報は、前記受信装置の能力、前記受信装置の負荷状況、前記情報の参照頻度、前記受信装置にて設定された通信方式を示す情報のうちの少なくともいずれかを含む送信装置を提供する。
【００３１】
【発明の実施の形態】
＜発明の概要＞
本発明は、動的に変化する様々な要因に応じて、通信方式を最適なものに切り替える。これにより、ネットワーク及びコンピュータ資源の有効利用を図り、通信費用のコストを削減し、ユーザの利便性を高めることが可能となる。最適な通信方式は、たいていの場合、送信側機器と受信側機器とで異なる。この場合、システム全体にとって最適と考えられる通信方式を決定したり、送信側または受信側のどちらかの決定を優先させることにより、双方で用いる通信方式を最終的に決定する。
【００３２】
以下の第１及び第２実施形態例では、送信側機器の優先度を高めて通信方式を決定する例を説明する。第３実施形態例では、受信側機器の優先度を高めて通信方式を決定する例を説明する。
【００３３】
＜第１実施形態例＞
［構成］
次に、本発明の通信方式切換方法をアウェアネスシステムに適応した場合を例に挙げて具体的に説明する。図１は、第１実施形態例に係るアウェアネスシステムの全体構成である。このシステムは、アウェアネスサーバ１とクライアント２とが、ネットワーク３を介して接続されて構成されている。図では、クライアント２を１つしか示していないが、通常は複数のクライアントがネットワーク３に接続されている。
【００３４】
アウェアネスサーバ１は、ネットワーク３上のユーザのアウェアネス情報を管理し、クライアント２に他のユーザのアウェアネス情報を配信している。アウェアネス情報とは、ユーザ状態、ユーザがどの通信手段を使用可能か否か、住所、電話番号、メールアドレスなどのユーザの個人情報全般である。本例では、アウェアネスサーバ１が管理するアウェアネス情報のいずれかが更新された場合に、その更新された情報とクライアント２上のアウェアネス情報との同期をとるための通信方式の切り替えについて、例を挙げて説明する。
【００３５】
（１）アウェアネスサーバ
アウェアネスサーバ１は、アウェアネスサービスモジュール１１、方式決定モジュール１２、ユーザＤＢ１３、設定ＤＢ１４及び方式ＤＢ１５を有している。アウェアネスサービスモジュール１１は、クライアントからアウェアネス情報の更新を受け付け、ユーザＤＢ１３に格納する。また、アウェアネスサービスモジュール１１は、どのユーザは誰のアウェアネス情報を参照しているか、すなわち各ユーザのバディリストを、ユーザＤＢ１３に格納している。さらに、アウェアネスサービスモジュール１１は、ユーザＤＢ１３内のアウェアネス情報が更新された場合、更新されたアウェアネス情報を参照しているユーザに対し、更新された情報を配信する。方式決定モジュール１２は、サーバの負荷やネットワーク３の負荷、情報の更新頻度など、動的に変化する要因と、クライアント２が指定した通信方式とに基づいて、サーバ１とクライアント２との通信方式を動的に切り替える。
【００３６】
図２は、ユーザＤＢ１３に蓄積されるアウェアネス情報の概念説明図である。この例ではアウェアネス情報として、「利用者ＩＤ」、利用者の「状態」、「メッセージ」を受信可能か否か、「電話」に出れるか否か、「電子メール」を受信可能か否かが、ユーザ毎に蓄積されている。また、ユーザＤＢ１３には、各ユーザのバディリストが蓄積されている（図示せず）。このバディリストは、誰が誰のアウェアネス上を参照しているかを定めている。
【００３７】
図３は、アウェアネスサーバ１の設定ＤＢ１４に蓄積される情報の概念説明図である。この設定ＤＢ１４には、（ａ）管理者設定データテーブル、（ｂ）利用者設定データテーブル及び（ｃ）参照データテーブルが蓄積されている。図（ａ）は管理者設定データテーブル（ａ）の概念説明図である。このテーブルには、サーバの優先事項としてスループット優先か、レスポンスタイム優先かが設定される。この設定は、アウェアネスサーバ１の管理者により行われる。
【００３８】
図（ｂ）は、利用者設定データテーブル（ｂ）の概念説明図である。このテーブルには、「利用者ＩＤ」、「優先事項」及び「料金目標」が蓄積されている。即ちこのテーブルは、参照時間を優先するか、通信料金を優先するかや、１月の通信料金の目標額が、利用者毎に蓄積される。この設定は、利用者によりなされる。
【００３９】
図（ｃ）は、参照データテーブルの概念説明図である。このテーブルには、各ユーザのバディリストの内容が記述される。具体的には、「利用者ＩＤ」、「バディＩＤ」、「参照項目」及び「通知項目」が蓄積されている。「利用者ＩＤ」とはバディリストの所有者であり、「バディＩＤ」とは各利用者のバディリストに参照先として登録されている利用者のＩＤである。「参照項目」には、利用者が参照するアウェアネス情報の項目が記憶される。「通知項目」は、参照したいアウェアネス情報のうち、速やかに知らせて欲しい情報である。
【００４０】
図４及び図５は、アウェアネスサーバ１の方式ＤＢ１５に蓄積される情報の概念説明図である。方式ＤＢ１５には、（ａ）通信履歴テーブル、（ｂ）クライアント能力テーブル、（ｃ）参照情報データテーブル、（ｄ）過去方式テーブル及び（ｅ）サーバ能力テーブルが蓄積されている。図４（ａ）は通信履歴テーブル（ａ）の概念説明図である。このテーブルには、「利用者ＩＤ」、「通信量」、「通信時間（秒）」及び「料金（円）」が蓄積されている。すなわち、このテーブルには、過去の通信履歴が利用者毎に蓄積されている。
【００４１】
図４（ｂ）はクライアント能力テーブル（ｂ）に蓄積される概念説明図である。このテーブルには、「通信路負荷」、「クライアント能力」及び「通信路能力」が、利用者ＩＤ毎に蓄積されている。クライアントの能力は、例えば処理速度やメモリ容量等から決定される。通信路能力は、例えば通信容量や通信速度から決定される。
【００４２】
図４（ｃ）は、参照情報データテーブル（ｃ）に蓄積される情報の概念説明図である。この図には、「情報項目」、「更新頻度（回／時）」及び「情報量(Bytes)」が、利用者ＩＤ毎に蓄積されている。情報項目にはアウェアネス情報の項目が記述され、各利用者のアウェアネス情報項目毎に、更新頻度と情報量とが記憶されている。
【００４３】
図５（ｄ）は、過去方式テーブル（ｄ）に蓄積される情報の概念説明図である。このテーブルは、アウェアネスサーバ１からクライアント２にアウェアネス情報を送信するために使用された過去の通信方式を、アウェアネス情報の各項目毎に記憶している。具体的には、このテーブルは、「バディＩＤ」、「情報項目」、「クライアント側の決定方式」、「理由」及び「前回方式」を、「利用者ＩＤ」ごとに記憶している。利用者とはバディリストの持ち主である。クライアント側の決定方式とは、利用者のクライアント２が決定した通信方式である。前回方式とは、アウェアネスサーバ１と前記利用者のクライアント２との前回の通信に用いられた通信方式である。
【００４４】
図５（ｅ）は、サーバ能力テーブル（ｅ）に蓄積される情報の概念説明図である。このテーブルには、アウェアネスサーバの負荷及びサーバの能力が記録されている。サーバ能力は、前記クライアント能力と同様に判断される。
【００４５】
（２）クライアント
クライアント２は、アウェアネスクライアントモジュール２１、方式指定モジュール２２、設定ＤＢ２３及び方式ＤＢ２４を有している。アウェアネスクライアントモジュール２１は、ユーザからアウェアネス情報の設定及び更新を受け付け、アウェアネスサーバ１に送信する。また、アウェアネスクライアントモジュール２１は、バディリストの設定や更新を受付、アウェアネスサーバ１に登録する。さらに、アウェアネスクライアントモジュール２１は、所定のイベントの発生に応じ、バディリストに登録されている他のユーザのアウェアネス情報を、アウェアネスサーバ１から取得する。所定のイベントとは、例えばユーザの操作や所定時間毎、アウェアネス情報の更新などである。
【００４６】
方式指定モジュール２２は、クライアント２の負荷やネットワーク負荷等の動的に変化する要因に基づいて、クライアント２に最適な通信方式を決定する。
【００４７】
図６は、クライアント２の設定ＤＢ２３に蓄積される情報の概念説明図である。この設定ＤＢ２３には、（ａ）利用者設定データテーブル及び（ｂ）参照設定テーブルが蓄積されている。
【００４８】
図（ａ）は、利用者設定データテーブルである。このテーブルには、「優先事項」及び「料金目標」が蓄積されている。このテーブルに設定された内容が、前記サーバ側設定ＤＢ１４の利用者設定データテーブル（ｂ）に登録される。
【００４９】
図（ｂ）は、参照設定テーブルに蓄積される情報の概念説明図である。このテーブルには、ユーザがバディリストに登録している他のユーザ、すなわちバディのＩＤと、「参照項目」と「通知項目」とが蓄積されている。このテーブルに設定された内容が、前記アウェアネスサーバ１の設定ＤＢ１４の参照データテーブル（ｃ）に蓄積される。
【００５０】
図７は、クライアント２の方式ＤＢ２４に蓄積される情報の概念説明図である。この方式ＤＢには、（ａ）通信履歴テーブル、（ｂ）能力テーブル及び（ｃ）参照情報テーブルが蓄積されている。
【００５１】
図（ａ）は、通信履歴テーブルに蓄積される情報の概念説明図である。このテーブルには、クライアント２の通信履歴、具体的には「通信量(Kbytes/分)」、「通信時間（秒）」及び「料金（円）」が対応付けられて蓄積されている。このテーブルに蓄積された内容が前記アウェアネスサーバ１の方式ＤＢ１５内の通信履歴テーブル（ａ）に登録される。
【００５２】
図（ｂ）は、能力テーブルに蓄積される情報の概念説明図である。このテーブルには、「通信路負荷」、「クライアント負荷」、「クライアント能力」及び「通信路能力」が蓄積されている。このテーブルの内容は、前記方式ＤＢ１５のクライアント能力テーブル（ｂ）に登録される。
【００５３】
図（ｃ）は、参照情報テーブルに蓄積される情報の概念説明図である。このテーブルには、ユーザがバディリストに登録しているバディについて、参照する情報項目毎に、「参照頻度（回/度）」、「決定方式」及び通信方式を決定した「決定理由」が記憶されている。
【００５４】
［処理の流れ］
次に、アウェアネスサーバ１の方式決定モジュール１２及びクライアント２の方式指定モジュール２２が行う処理の流れについて具体的に説明する。今、説明を容易にするために、ユーザＤＢ１３に蓄積されているアウェアネス情報が更新された場合に、その更新された情報を参照するユーザに新たな更新情報を通知する通信方式を、どのように決定するかについて説明する（（１）通信方式の決定）。従って、アウェアネスサーバ１が送信側、クライアント２が受信側機器となる。次いで、通信方式の決定に応じて、アウェアネスサーバ１及びクライアント２が通信方式を切り替える処理について、説明する（（２）通信処理）。
【００５５】
（１）通信方式の決定
本例では、まずクライアント２が、クライアント２に都合の良い通信方式を指定する。アウェアネスサーバ１は、クライアント２が指定した通信方式と全体的な通信状況とに基づいて、通信方式を決定する。通信方式は、簡単のため、プッシュ、プル、ノーティファイのいずれかから決定する。
【００５６】
（１−１）アウェアネスサーバ側の処理の流れ
（１−１−１）サーバ側決定処理
アウェアネスサーバ１は、方式決定モジュール１２により以下の処理を行い、クライアント２との通信方式を決定する。アウェアネスサーバ１は、ユーザＤＢ１３内のアウェアネス情報が更新されると、以下の処理を開始する。
【００５７】
ステップＳ１、Ｓ２、Ｓ３：アウェアネスサーバ１は、サーバ側方式ＤＢ１５の参照情報データテーブル（ｃ）を参照し、更新されたアウェアネス情報を参照しているクライアント２が、通信方式を指定しているか否かを判断する（Ｓ１）。既に指定された通信方式がある場合、アウェアネスサーバ１は、プッシュ、プル、ノーティファイの３つの方式のうち、クライアント２が指定している方式に１００ポイントを加算する。指定方式がない場合、後述する加算サブルーチンを実行する（Ｓ３）。
【００５８】
ステップＳ４、Ｓ５、Ｓ６：アウェアネスサーバ１は、クライアント２の指定方式がプッシュ方式であって、かつサーバ１の負荷が高い場合（Ｓ４）、ノーティファイ方式に１００ポイントを加算する（Ｓ５）。そうでない場合には、クライアント２の指定方式に、さらに３０ポイントを加算する（Ｓ６）。
【００５９】
ステップＳ７、Ｓ８、Ｓ９：アウェアネスサーバ１は、更新されたアウェアネス情報が通知項目であるか否かを判断し、通知項目の場合はプッシュまたはノーティファイのうちポイントの高い方を用いて通信することに決定する（Ｓ８）。通知項目でない場合、３つの方式のうち最もポイントの高い方式を用いて通信することに決定する（Ｓ９）。
【００６０】
ステップＳ１０、Ｓ１１：アウェアネスサーバ１は、決定した通信方式を、クライアント２に通知する必要があるか否かを判断する（Ｓ１０）。必要がある場合とは、前回がプッシュまたはノーティファイで、今回がプルの場合である。今回の通信方式がプッシュまたはノーティファイの場合、更新情報または更新通知がクライアント２に送信されるので、通知の必要はない。また、前回及び今回もプルの場合、通信方式の変更がないので通知の必要はない。必要があると判断すると、アウェアネスサーバ１は、クライアント２に対し、新たな通信方式を通知する（Ｓ１１）。この通知を受け取ったクライアント２は、新たな通信方式をアウェアネスサーバ１との間に設定する。
【００６１】
この処理により、クライアント２及びシステム全体の状況をふまえた通信方式を、動的に変化する状況に応じて設定することができる。
【００６２】
（１−１−２）加算処理
図９及び図１０は、前記ステップＳ３に移行した場合に、アウェアネスサーバ１が方式決定モジュール１２により行う、加算処理サブルーチンの処理の流れを示すフローチャートである。この処理では、アウェアネスサーバ１は、自身の負荷やクライアントの負荷、ネットワークの負荷などシステム全体の状況に基づいて、最適な通信方式を決定する。
【００６３】
ステップＳ４０１：アウェアネスサーバ１は、更新されたアウェアネス情報を配信するクライアント２との間で、過去にプッシュ方式を用いているか否かを判断する（Ｓ４０１）。この判断は、サーバ側方式ＤＢ１５の過去方式テーブル（ｄ）を参照することにより行う。
【００６４】
“Ｙｅｓ”と判断すると、アウェアネスサーバ１は、現在までの通信料金ＣＣと料金目標ＣＤとを用い、次のようにプル方式及びノーティファイ方式にポイントを加える。通信料金ＣＣ及び料金目標ＣＤは、それぞれサーバ側方式ＤＢ１５及び設定ＤＢ１４から読み出す。
Ｔ＝（ＣＤ−ＣＣ）／ＣＤとして、Ｔ＜０の場合、プル方式に２００ポイントを、ノーティファイ方式に１００ポイントを加算する（Ｓ４０３）。Ｔ≧０の場合、プル方式に（Ｔ×２００）ポイントを、ノーティファイ方式に（Ｔ×１００）ポイントを、それぞれ加算する（Ｓ４０４）。
【００６５】
ステップＳ４０５：アウェアネスサーバ１は、通信すべき量が１０Kbytes以上で、かつ通信路の能力が中以下の場合、ステップＳ４０６に移行する。そうでない場合、後述するステップＳ４０９に移行する。
【００６６】
ステップＳ４０６、Ｓ４０７、Ｓ４０８：アウェアネスサーバ１は、サーバ側設定ＤＢ１４の利用者設定データテーブル（ｂ）を参照し、配信先クライアント２が参照時間と通信料金とのどちらを優先しているかを判断する（Ｓ４０６）。参照時間を優先している場合、プッシュ方式に３０ポイントを加算する（Ｓ４０７）。通信料金を優先している場合、プル方式に５０ポイントを、ノーティファイ方式に３０ポイントを、それぞれ加算する（Ｓ４０８）。
【００６７】
ステップＳ４０９、Ｓ４１０：アウェアネスサーバ１は、サーバの負荷が高く、かつ通信すべき量が１０Kbytes以上の場合（Ｓ４０９）、プル方式に５０ポイントを、ノーティファイ方式に３０ポイントを、それぞれ加算する（Ｓ４１０）。そうでない場合、図１０のＳ４１１に移行する。
【００６８】
ステップＳ４１１、Ｓ４１２：アウェアネスサーバ１は、クライアントの能力が低く、かつ通信すべき量が１０Kbytes以上あるか否かを、サーバ側方式ＤＢ１５に基づいて判断する（Ｓ４１１）。“Ｙｅｓ”と判断すると、プル方式に５０ポイントを、ノーティファイ方式に３０ポイントを、それぞれ加算する（Ｓ４１２）。
【００６９】
ステップＳ４１３、Ｓ４１４：アウェアネスサーバ１は、通信路の負荷が高く、かつアウェアネス情報の更新頻度が所定以上か否かを判断する（Ｓ４１３）。更新頻度のレベルは、サーバ側方式ＤＢ１５の参照情報データテーブル（ｃ）に基づいて行う。“Ｙｅｓ”と判断すると、ノーティファイ方式に３０ポイント加算する（Ｓ４１４）。その他の場合、ステップ４１５に移行する。
【００７０】
ステップＳ４１５、Ｓ４１６：アウェアネスサーバ１は、通信路の能力が低く、かつ配信先クライアント２の優先事項が参照時間であれば（Ｓ４１５）、プッシュ方式に３０ポイントを加算する（Ｓ４１６）。
【００７１】
ステップＳ４１７，Ｓ４１８：アウェアネスサーバ１は、更新した情報が重要な情報の場合、プッシュ方式に５０ポイントを加算し（Ｓ４１７）、前記決定処理に戻る。そうでない場合にはそのまま前記決定処理に戻る。
【００７２】
（１−２）クライアント側の方式指定処理
図１１は、クライアント２が行う通信方式指定処理の流れを示すフローチャートである。クライアント２は、以下の処理により、自身にとって最適な通信方式を決定し、アウェアネスサーバ１に通知する。この通知を受け取ったアウェアネスサーバ１が、前述の方法により、通信方式を最終決定する。
【００７３】
ステップＳ２１：クライアント２の方式指定モジュール２２は、所定イベントの発生を待機し、所定イベントが発生するとステップＳ２２に移行する。所定イベントとは、ユーザからのバディのアウェアネス情報の取得指示、所定時間の経過、クライアント２の状況変化などである。
【００７４】
ステップＳ２２、Ｓ２３：クライアント２は、ユーザにより通信方式が設定されているかどうかを判断する（Ｓ２２）。設定されている場合にはその方式を指定することを決定する（Ｓ２３）。設定していない場合には、後述するステップＳ２６に移行する。
【００７５】
ステップＳ２４、Ｓ２５、Ｓ２６：クライアント２は、指定する通信方式が今までの指定通信方式を変更するものであるかどうかを判断し（Ｓ２４）、“変更”と判断すると新たな指定方式をアウェアネスサーバ１に通知する必要があるか否かを判断する（Ｓ２５）。必要がある場合とは、プッシュやノーティファイ方式からプル方式に変更した場合や、その逆の場合である。“変更なし”と判断すると、再びステップＳ２１に戻り、次のイベントの発生を待機する。
【００７６】
ステップＳ２５で“通知の必要あり”と判断すると、クライアント２は指定方式をアウェアネスサーバ１に通知する。“必要なし”と判断すると、再びステップＳ２１に戻り、次のイベントの発生を待機する。
【００７７】
ステップＳ２７：ユーザが通信方式を設定していない場合、クライアント２は、方式ＤＢ２４に基づいて、バディのアウェアネス情報を参照する頻度が所定以上の場合（Ｓ２７）、プッシュ方式を指定する（Ｓ２８）。そうでない場合には、クライアント２の負荷が高いか否かを方式ＤＢ２４に基づいて判断し（Ｓ２９）、クライアント２の負荷が高ければノーティファイ方式を（Ｓ２１０）、クライアント２の負荷が高くなければアウェアネスサーバ１の決定方式を、指定する（Ｓ２１１）。
【００７８】
（２）通信処理
（２−１）アウェアネスサーバ側通信処理
図１２は、アウェアネスサーバ１が、方式決定モジュール１２により行う通信処理の流れを示すフローチャートである。この処理により、アウェアネスサーバ１は、クライアント２との通信方式を前記決定されたものに切り替える。アウェアネスサーバ１は、アウェアネス情報が更新されることにより、以下の処理を開始する。
【００７９】
ステップＳ３１、Ｓ３２：アウェアネスサーバ１は、通信方式がプッシュ方式である場合（Ｓ３１）、更新されたアウェアネス情報（以下、更新情報という）を配信先クライアント２に送信する（Ｓ３２）。
【００８０】
ステップＳ３３、Ｓ３４：アウェアネスサーバ１は、通信方式がノーティファイ方式である場合（Ｓ３３）、配信先クライアント２に更新通知を送信する（Ｓ３４）。
【００８１】
ステップＳ３５、Ｓ３６、Ｓ３７：アウェアネスサーバ１は、通信方式がプル方式である場合、配信先クライアント２からのプル要求を待機し（Ｓ３６）、これを待って更新情報を送信する（Ｓ３７）。
【００８２】
（２−２）クライアント側通信処理
図１３は、クライアント２が方式指定モジュール２２により行う通信処理の流れを示すフローチャートである。この処理により、クライアント２は、アウェアネスサーバ１との通信方式を、前記決定されたものに切り替える。クライアント２は、ユーザからのアウェアネス情報の参照指示により、以下の処理を開始する。
【００８３】
ステップＳ４１、Ｓ４２、Ｓ４３、Ｓ４４：クライアント２は、通信方式がプル方式の場合（Ｓ４１）、アウェアネスサーバ１にプル要求を送信する（Ｓ４２）。次いで、サーバ１からの更新情報を待機し（Ｓ４３）、これを受信すると古いアウェアネス情報を更新する（Ｓ４４）。
【００８４】
ステップＳ４５、Ｓ４６、Ｓ４７、Ｓ４８、Ｓ４９：クライアント２は、通信方式がプル方式以外である場合、バディのアウェアネス情報に更新印があるか否かを判断し（Ｓ４５）、ない場合にはそれが最新の情報であるのでそのまま処理を終了する。ある場合には、前記ステップＳ４２〜Ｓ４４と同様の処理を行い（Ｓ４６〜４８）、更新されたアウェアネス情報の更新印を削除する（Ｓ４９）。
【００８５】
以上のようにして、切り替えられた通信方式を用い、アウェアネスサーバ１とクライアント２とが通信を行う。
【００８６】
＜第２実施形態例＞
［構成］
次に、ニュースをネットワーク上で配信するニュースシステムに本発明の方法を適用した場合について説明する。図１４は、第２実施形態例に係るニュースシステムの全体構成図である。ニュースシステムは、ニュースサーバ１０とクライアント２０とがネットワーク３０により接続されて構成されている。
【００８７】
ニュースサーバ１０は、ユーザＤＢ１３に代えてニュースＤＢ１０３を、アウェアネスサービスモジュール１１に代えてニュース配信モジュール１０１を有している。その他の構成要素は、前記アウェアネスサーバ１と同様である。ニュース配信モジュール１０１は、サーバ側ニュースＤＢ１０３に蓄積されたニュースが更新されると、クライアント２に配信する。どのクライアントに何のニュースを配信するかは、予めユーザにより設定されたテーブルを参照して判断する。
【００８８】
クライアント２０は、アウェアネスクライアントモジュール２１に代えて、ニュースを受信する受信モジュール２０１を有している。さらに、受信したニュースを蓄積するニュースＤＢ２０５を有している。その他の構成要素は、第１実施形態例と同様である。
【００８９】
図１５は、サーバ側設定ＤＢ１０４に蓄積される情報の概念説明図である。第１実施形態例と同様に、設定ＤＢ１０４には、（ａ）管理者設定データテーブル、（ｂ）利用者設定データテーブル及び（ｃ）参照データテーブルが蓄積されている。管理者設定データテーブル（ａ）及び利用者設定データテーブル（ｂ）に蓄積される情報は、第１実施形態例と同様である。
【００９０】
参照データテーブル（ｃ）に蓄積される内容は、「バディＩＤ」及び「参照項目」に代えて「参照ニュース」が、また「通知項目」に代えて「通知ニュース」が蓄積されている。
【００９１】
図１６及び図１７は、ニュースサーバ１０の方式ＤＢ１０５に蓄積される情報の概念説明図である。このＤＢには、（ａ）通信履歴テーブル、（ｂ）クライアント能力テーブル、（ｃ）参照情報データテーブル、（ｄ）過去方式テーブル及び（ｅ）サーバ能力テーブルが蓄積されている。参照情報データテーブル（ｃ）及び過去方式テーブル（ｄ）を除き、前記第１実施形態例と同様の情報が蓄積されている。
【００９２】
参照情報データテーブル（ｃ）においては、「利用者ＩＤ」及び「情報項目」に代えて「ニュース」が蓄積されている点を除き、第１実施形態例と同様の情報が蓄積されている。
【００９３】
過去方式テーブル（ｄ）においては、「バディＩＤ」及び「情報項目」に代えて「ニュース」が蓄積されている点を除き、第１実施形態例と同様の情報が蓄積されている。
【００９４】
図１８は、クライアント２０のニュースＤＢ２０５に蓄積される情報の概念説明図である。このＤＢには、ユーザが指定した「ニュース」の分類と、その「内容」とが記憶される。
【００９５】
図１９は、クライアント２０の設定ＤＢ２０３に蓄積される情報の概念説明図である。このＤＢには、（ａ）利用者設定データテーブル及び（ｂ）参照設定データテーブルが蓄積されている。利用者設定データテーブル（ａ）には、前記第１実施形態例と同様の情報が蓄積されている。参照設定テーブル（ｂ）には、「バディＩＤ」及び「参照項目」に代えて「参照ニュース」が、「通知項目」に代えて「通知ニュース」が記憶されている点を除き、前記第１実施形態例と同様の情報が蓄積されている。
【００９６】
図２０は、クライアント２０の方式ＤＢ２０４に蓄積される情報の概念説明図である。このＤＢには、（ａ）通信履歴テーブル、（ｂ）能力テーブル及び（ｃ）参照情報テーブルが蓄積されている。通信履歴テーブル（ａ）及び能力テーブル（ｂ）に蓄積される情報は、前記第１実施形態例と同様である。参照情報テーブルに蓄積される情報は、「バディＩＤ」及び「情報項目」に代えて「参照ニュース」が記述されている他は、前記第１実施形態例と同様の情報が蓄積されている。
【００９７】
［処理の流れ］
本実施形態例において、ニュースサーバ１０及びクライアント２０が、方式決定モジュール１０２及び方式指定モジュール２０２により行う処理は、前記第１実施形態例と同様である。
【００９８】
＜第３実施形態例＞
前記第１及び第２実施形態例では、送信側及び受信側機器が通信する方式を、送信側を優先に決定している。しかし、以下のように、受信側を優先して決定することも可能である。
【００９９】
［構成］
図２１は、第３実施形態例に係るアウェアネスシステムの構成図である。このシステムは、複数のアウェアネスクライアント１２０ａ，ｂ・・・がネットワーク１３０に接続されて構成される。このシステムでは、ユーザのアウェアネス情報は、一時的にそのユーザのクライアントに保持される。その上で、そのユーザをバディに指定している他のユーザのクライアントとアウェアネス情報の同期をとる。
【０１００】
今、説明を容易にするため、ユーザＡとユーザＢとは、それぞれのバディリストに相手を登録しているものとする。クライアント１２０ａはユーザＡのクライアントを、クライアント１２０ｂはユーザＢのクライアントを指すものとする。また、クライアント１２０ａが送信側に、クライアント１２０ｂが受信側になる場合について説明する。但し、送信側のクライアントにも受信側の機能やデータベースが設けられており、逆も同様である。
【０１０１】
送信側クライアント１２０ａと受信側クライアント１２０ｂとは、共にアウェアネスクライアントモジュール１２１、設定ＤＢ１２３、方式ＤＢ１２４を有している。この他に、送信側クライアント１２０ａは、方式指定モジュール１２６と利用者情報ＤＢ１２５を有し、受信側クライアント１２０ｂは方式決定モジュール１２２を有している。方式指定モジュール１２６は、送信側クライアント１２０ａに最適な通信方式を指定し、受信側クライアント１２０ｂに通知する。方式決定モジュール１２２は、送信側の指定方式と、受信側クライアント１２０ｂの都合とに基づいて、通信方式を決定する。
【０１０２】
図２２は、送信側クライアント１２０ａの利用者情報ＤＢ１２５に蓄積された、ユーザＡ自身のアウェアネス情報の概念説明図である。このＤＢの情報が、受信側クライアント１２０ｂに送信される。本例では、このＤＢには、「ユーザ状態」、「メッセージ」を受信可能か否か、「電話」を受けられるか否か、及び「電子メール」を受信可能か否かが記憶されている。「ユーザ状態」としては、会議中、在席、不在、多忙など、ユーザの状態を表すデータが記憶される。
【０１０３】
図２３は、送信側クライアント１２０ａの設定ＤＢ１２３に蓄積される情報の概念説明図である。このＤＢには、送信側ユーザＡをバディに登録しているユーザＢ，Ｃ・・・に、ユーザＡのどのアウェアネス情報を配信するかが記憶されている。これらの情報は、予め受信側クライアント１２０ｂから送られているものとする。
【０１０４】
ここでは、設定ＤＢは、「参照者のＩＤ」、「参照項目」及び「通知項目」を記憶している。参照者ＩＤは、送信側ユーザＡのアウェアネス情報を参照するユーザのＩＤである。参照項目には、参照者が参照するアウェアネス情報の項目が記憶されている。通知項目には、参照項目の中でも迅速に通知して欲しいアウェアネス情報が記憶されている。
【０１０５】
図２４は、送信側クライアント１２０ａの方式ＤＢ１２４に記憶される情報の概念説明図である。このＤＢには、（ａ）通信履歴テーブル、（ｂ）参照情報データテーブル、（ｃ）過去方式テーブル、及び（ｄ）通信情報テーブルが蓄積されている。このうち通信履歴テーブル（ａ）は図４の通信履歴テーブルに、参照情報データテーブル（ｂ）は図４の参照情報データテーブルに、過去方式テーブル（ｃ）は図５の過去方式テーブルに相当する。
【０１０６】
但し、通信履歴テーブル（ａ）には、ユーザＡをバディに登録しているユーザについての情報だけが記憶されている。また、参照情報データテーブル（ｂ）には、ユーザＡに関する情報だけが記憶されている。さらに、過去方式テーブル（ｃ）は、ユーザＡをバディに登録している他のユーザについての情報のみを記憶している。
【０１０７】
通信情報テーブル（ｄ）には、通信路の負荷、通信側クライアントの負荷及び能力、通信路能力が記憶されている。
【０１０８】
図２５は、受信側クライアント１２０ｂの設定ＤＢ１２３に記憶されている情報の概念説明図である。このＤＢには、（ａ）利用者設定データテーブル及び（ｂ）参照設定テーブルが記憶されている。これらのテーブルは、前記図６の利用者設定データテーブル及び参照設定データテーブルと同様の内容を記憶している。
【０１０９】
図２６は、受信側クライアント１２０ｂの方式ＤＢ１２４に記憶される情報の概念説明図である。このＤＢには、（ａ）通信履歴テーブル、（ｂ）能力テーブル、（ｃ）参照情報テーブルが蓄積されている。これらのテーブルは、前記図７のクライアント側方式ＤＢに蓄積されている各テーブルと同様の内容を記憶している。
【０１１０】
［処理の流れ］
次に、本実施形態例において通信方式を決定する処理を説明する。前述したように、このシステムでは送信側機器が通信方式を指定し、受信側機器が実際に通信を行う方式を決定する。その後、決定した通信方式に基づいて通信する処理は、前述の通信処理と同様である。以下では、（１）送信側クライアントが行う通信方式指定方式、（２）受信側クライアントが行う通信方式決定処理について説明する。
【０１１１】
（１）通信方式指定処理（送信側）
図２７及び図２８は、送信側クライアントが行う通信方式指定処理の流れを示すフローチャートである。送信側クライアント１２０ａは、方式指定モジュール１２６を用い、以下の処理を行う。送信側クライアント１２０ａは、ユーザのアウェアネス情報が更新されることにより以下の処理を開始する。
【０１１２】
ステップＳ５１、Ｓ５２：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、クライアント１２０ｂとの前回の通信量が１００バイト／分未満ならば（Ｓ５１）、プッシュ方式に２０ポイントを加える（Ｓ５２）。
【０１１３】
ステップＳ５３、Ｓ５４：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、クライアント１２０ｂとの前回の通信時間が平均２秒未満ならば（Ｓ５３）、プッシュ方式に１０ポイントを加える（Ｓ５４）。
【０１１４】
ステップＳ５５、Ｓ５６：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、通信すべき量が１０Kbytes以上で、かつ通信路の能力が中以下の場合（Ｓ５５）、プッシュ方式に１０ポイントを加える（Ｓ５６）。
【０１１５】
ステップＳ５７、Ｓ５８：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、送信側の負荷が高くかつ通信すべき量が１０Kbytes以上の場合（Ｓ５７）、プル方式に２０ポイントを、ノーティファイ方式に１０ポイントを、それぞれ加える（Ｓ５８）。
【０１１６】
ステップＳ５９、Ｓ５１０：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、自身の能力が低く、かつ通信すべき量が１０Kbytes以上の場合（Ｓ５９）、プル方式に２０ポイントを、ノーティファイ方式に１０ポイントをそれぞれ加算する（Ｓ５１０）。
【０１１７】
ステップＳ５１１、Ｓ５１２：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、通信路の負荷が高く、かつ送信するアウェアネス情報の更新頻度が所定以上であるか否かを判断する。ここでは、更新頻度が１時間当たり１００回以上であれば（Ｓ５１１）、ノーティファイ方式に３０ポイントを加算する（Ｓ５１２）。
【０１１８】
ステップＳ５１３，Ｓ５１４：送信側クライアント１２０ａは、更新されたユーザＡのアウェアネス情報が重要な情報の場合（Ｓ５１３）、プッシュ方式に３０ポイントを加算する（Ｓ５１４）。
【０１１９】
ステップＳ５１５、Ｓ５１６、Ｓ５１７：送信側クライアント１２０ａは、更新されたアウェアネス情報が、受信側ユーザＢの通知項目に指定されているか否かを判断する（Ｓ５１５）。通知項目の場合、送信側クライアント１２０ａは、プッシュ方式またはノーティファイ方式のうちポイントが高い方を指定方式とする（Ｓ５１６）。通知項目でない場合には、プッシュ、ノーティファイ、プル方式のうち最もポイントの高いものを指定方式とする（Ｓ５１７）。
【０１２０】
ステップＳ５１８，Ｓ５１９：送信側クライアント１２０ａは、方式ＤＢ１２４を参照し、指定方式またはその決定理由が前回と異なるか否かを判断する（Ｓ５１８）。異なる場合、受信側クライアント１２０ｂに問い合わせを送信する（Ｓ５１９）。この問い合わせには、送信側クライアント１２０ａの指定する通信方式が記述されている。
【０１２１】
ステップＳ５２０、Ｓ５２１：送信側クライアント１２０ａは、受信側クライアント１２０ｂからの通信方式の回答を待機し（Ｓ５２０）、回答により通知された通信方式を最終的な通信方式として決定する（Ｓ５２１）。
【０１２２】
（２）通信方式決定処理
図２９及び図３０は、受信側クライアントが行う通信方式決定処理の流れを示すフローチャートである。受信側クライアント１２０ｂは、方式決定モジュール１２２を用い、送信側クライアント１２０ａが指定する通信方式と自身の状況とに基づいて、通信方式を決定する。受信側クライアント１２０ｂは、所定のイベントが生じた場合に、以下の処理を開始する。所定のイベントとは、送信側クライアント１２０ａからの通信方式の問い合わせがあった場合や、所定時間毎、自身の状況が変化した場合などである。
【０１２３】
ステップＳ６１、Ｓ６２：受信側クライアント１２０ｂは、送信側クライアント１２０ａの指定方式があるか否かを判断し（Ｓ６１）、ある場合にはその通信方式に１００ポイントを加算する（Ｓ６２）。
【０１２４】
ステップＳ６３：受信側クライアント１２０ｂは、送信側クライアント１２０ａが指定して来た通信方式に５０ポイントを加算する。
【０１２５】
ステップＳ６４、Ｓ６５、Ｓ６６：受信側クライアント１２０ｂは、送信側クライアント１２０ａとの間での前回の通信がプッシュ方式か否かを判断する（Ｓ６４）。プッシュ方式の場合、Ｔ＜０か否かにより、以下の処理を行う（Ｓ６５）。ここで、Ｔとは、現在までの通信料金ＣＣと料金目標ＣＤを用いて、以下のように表される。通信料金ＣＣ及び料金目標ＣＤは、設定ＤＢ１２３及び方式ＤＢ１２４から読み出される。
【０１２６】
Ｔ＝（ＣＤ−ＣＣ）／ＣＤ
Ｔ＜０の場合、受信側クライアント１２０ｂは、プル方式に２００ポイントを、ノーティファイ方式に１００ポイントをそれぞれ加算する（Ｓ６６）。Ｔ≧０の場合、受信側クライアント１２０ｂは、プル方式に（Ｔ×２００）ポイントを、ノーティファイ方式に（Ｔ×１００）ポイントをそれぞれ加算する（Ｓ６７）。
【０１２７】
ステップＳ６８、Ｓ６９、Ｓ６１０：受信側クライアント１２０ｂは、設定ＤＢ１２３を参照し、参照時間が優先か否かを判断する（Ｓ６８）。参照時間優先の場合、受信側クライアント１２０ｂは、プッシュ方式に３０ポイントを加算する（Ｓ６９）。そうでない場合には、プル方式に５０ポイントを、ノーティファイ方式に３０ポイントをそれぞれ加算する（Ｓ６１０）。
【０１２８】
ステップＳ６１１、Ｓ６１２：受信側クライアント１２０ｂは、方式ＤＢ１２４を参照し、自身の負荷が高いか否かを判断する（Ｓ６１１）。負荷が高い場合、プル方式に２０ポイントを、ノーティファイ方式に１０ポイントをそれぞれ加算する（Ｓ６１２）。
【０１２９】
ステップＳ６１３、Ｓ６１４：受信側クライアント１２０ｂは、方式ＤＢ１２４を参照し、自身の能力が低いか否かを判断する（Ｓ６１３）。能力が低い場合、プル方式に１０ポイントを、ノーティファイ方式に５ポイントをそれぞれ加算する（Ｓ６１４）。
【０１３０】
ステップＳ６１５、Ｓ６１６：受信側クライアント１２０ｂは、方式ＤＢ１２４を参照し、ユーザＡのアウェアネス情報を参照する参照頻度が所定以上、例えば２０（回／時）以上か否かを判断する（Ｓ６１５）。所定以上の場合、受信側クライアント１２０ｂは、プッシュ方式に３０ポイントを、ノーティファイ方式に２０ポイントをそれぞれ加算する（Ｓ６１６）。
【０１３１】
ステップＳ６１７、Ｓ６１８：受信側クライアント１２０ｂは、方式ＤＢ１２４及び設定ＤＢ１２３を参照し、通信路の能力が低く、かつ受信側ユーザＢが参照時間を優先しているか否かを判断する（Ｓ６１７）。そうであれば、受信側クライアント１２０ｂは、プッシュ方式に１０ポイントを加算する（Ｓ６１８）。
【０１３２】
ステップＳ６１９、Ｓ６２０、Ｓ６２１：受信側クライアント１２０ｂは、設定ＤＢ１２３に基づいて、更新されたユーザＡのアウェアネス情報を、ユーザＢが通知項目に指定しているか否かを判断する（Ｓ６１９）。通知項目の場合、受信側クライアント１２０ｂは、プッシュ方式またはノーティファイ方式のうちポイントの高い方を最終的な通信方式として決定する（Ｓ６２０）。通知項目でない場合、プッシュ方式、ノーティファイ方式またはプル方式のいずれかのうち最もポイントの高いものを最終的な通信方式として決定する（Ｓ６２１）。
【０１３３】
ステップＳ６２２：受信側クライアント１２０ｂは、決定した最終的な通信方式を送信側クライアント１２０ａに通知し、処理を終了する。
【０１３４】
以上のようにして通信方式が決定された後、受信側クライアント１２０ｂと送信側クライアント１２０ａとは、決定された方式に通信方式を切り替える。この処理については、前記第１実施形態例のサーバ側及びクライアント側における通信処理と同様である。
【０１３５】
＜その他の実施形態例＞
（Ａ）前述の実施形態例に述べた以外にも、通信に影響を与える要因は様々に存在する。それらを考慮し、前述の決定処理を変形することにより、様々な通信方式の決定方法が可能である。
【０１３６】
（Ｂ）前述した本発明の方法を実行するプログラムを記録した記録媒体は、本発明に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフロッピーディスク、ハードディスク、半導体メモリ、CD-ROM、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。
【０１３７】
＜付記＞
（付記１）
データ通信路により接続された複数の機器間で情報を送受信するための通信方式の切替方法であって、
第１の機器において所定のイベントが発生した場合に、第１の機器の通信環境に基づいて第１通信方式を動的に決定し、
第２の機器において所定のイベントが発生した場合に、第２の機器の通信環境に基づいて第２通信方式を動的に決定し、
一方の機器から他方の機器へ情報を送信する通信方式を、前記第１通信方式または第２通信方式のいずれかに切り替える、
通信方式の切替方法。
【０１３８】
（付記２）
第１の機器が情報の送信側である場合、一方の機器から他方の機器へ情報を送信する通信方式を、第１の機器で決定した通信方式に切り替える、付記１に記載の通信方式の切替方法。
【０１３９】
この方法では、送信側の決定を優先する。ただし、送信側がサーバの場合のように、送信側は受信側の通信環境もある程度考慮して通信方式を決定可能な場合もある。
【０１４０】
（付記３）
第１の機器が情報の受信側である場合、一方の機器から他方の機器へ情報を送信する通信方式を、第１の機器で決定した通信方式に切り替える、付記１に記載の通信方式の切替方法。
【０１４１】
この方法では、受信側の決定を優先する。例えば、サーバレスシステムにおいては、クライアント間での通信が行われるため、受信側の決定を優先する場合が考えられる。
【０１４２】
（付記４）
前記第１及び第２の機器は、プッシュ、ノーティファイまたはプル方式のいずれかの通信方式の中から、前記第１及び第２通信方式を決定する、付記１に記載の通信方式の切替方法。
【０１４３】
（付記５）
データ通信路により接続された複数の機器間で情報を送受信するための通信方式の切替方法であって、
第１の機器は、所定のイベントが発生した場合、所定の第２の機器と通信するための第１通信方式を、第１の機器の通信環境に基づいて動的に決定し、
前記第１の機器は、決定した第１通信方式を、前記第２の機器に通知し、
前記第２の機器は、所定のイベントが発生した場合、第２の機器の通信環境及び前記第１通信方式に基づいて、前記第１の機器と通信するための第２通信方式を決定し、
一方の機器から他方の機器へ情報を送信する通信方式を、前記第２通信方式に切り替える、
通信方式の切替方法。
【０１４４】
（付記６）
データ通信路に接続され、第１機器と情報を送受信する第２機器に用いられる通信方式の切替装置であって、
前記第２機器において所定のイベントが発生した場合、第２機器の通信環境に基づいて通信方式を動的に決定する手段と、
第１機器との通信方式を、第１機器と交渉して決定する手段と、
第１機器との交渉の結果に従い、第１機器と通信を行う通信方式を切り替える手段と、
を備える通信方式の切替装置。
【０１４５】
（付記７）
データ通信路に接続され、第１機器と情報を送受信する第２機器に用いられる通信方式の切替装置であって、
前記第１機器において所定のイベントが発生した場合、前記第１機器の通信環境に基づいて前記第１機器が決定した第１通信方式の通知を受信する手段と、
前記第１機器との通信方式を、前記第２の機器の通信環境及び前記第１通信方式に基づいて決定する手段と、
前記決定に従い、前記第１機器と通信を行う通信方式を切り替える手段と、
を備える通信方式の切替装置。
【０１４６】
【発明の効果】
本発明を用いれば、様々な要因の変化に応じて通信方式を動的に切り替え、ネットワーク及びコンピュータ資源を有効利用し、通信コストを削減することができる。
【図面の簡単な説明】
【図１】第１実施形態例に係るアウェアネスシステムの全体構成。
【図２】ユーザＤＢに蓄積される情報の概念説明図。
【図３】サーバ側設定ＤＢに蓄積される情報の概念説明図。
【図４】サーバ側方式ＤＢに蓄積される情報の概念説明図（１）。
【図５】サーバ側方式ＤＢに蓄積される情報の概念説明図（２）。
【図６】クライアント側設定ＤＢに蓄積される情報の概念説明図。
【図７】クライアント側方式ＤＢに蓄積される情報の概念説明図。
【図８】決定処理（サーバ側）の流れを示すフローチャート。
【図９】加算処理（サーバ側）の流れを示すフローチャート（１）。
【図１０】加算処理（サーバ側）の流れを示すフローチャート（２）。
【図１１】指定処理（クライアント側）の流れを示すフローチャート。
【図１２】通信処理（サーバ側）の流れを示すフローチャート。
【図１３】通信処理（クライアント側）の流れを示すフローチャート。
【図１４】第２実施形態例に係るアウェアネスシステムの全体構成。
【図１５】サーバ側設定ＤＢに蓄積される情報の概念説明図。
【図１６】サーバ側方式ＤＢに蓄積される情報の概念説明図（１）。
【図１７】サーバ側方式ＤＢに蓄積される情報の概念説明図（２）。
【図１８】クライアント側ニュースＤＢに蓄積される情報の概念説明図。
【図１９】クライアント側設定ＤＢに蓄積される情報の概念説明図。
【図２０】クライアント側方式ＤＢに蓄積される情報の概念説明図。
【図２１】第３実施形態例に係るアウェアネスシステムの全体構成。
【図２２】送信側の利用者情報ＤＢに蓄積される情報の概念説明図。
【図２３】送信側設定ＤＢに蓄積される情報の概念説明図。
【図２４】送信側方式ＤＢに蓄積される情報の概念説明図。
【図２５】受信側設定ＤＢに蓄積される情報の概念説明図。
【図２６】受信側方式ＤＢに蓄積される情報の概念説明図。
【図２７】指定処理（送信側）の流れを示すフローチャート（１）。
【図２８】指定処理（送信側）の流れを示すフローチャート（２）。
【図２９】決定処理（受信側）の流れを示すフローチャート（１）。
【図３０】決定処理（受信側）の流れを示すフローチャート（２）。
【符号の説明】
１；アウェアネスサーバ
２；クライアント
３；ネットワーク
【図１】
0004577803.tif 000002
【図２】
0004577803.tif 000003
【図３】
0004577803.tif 000004
【図４】
0004577803.tif 000005
【図５】
0004577803.tif 000006
【図６】
0004577803.tif 000007
【図７】
0004577803.tif 000008
【図８】
0004577803.tif 000009
【図９】
0004577803.tif 000010
【図１０】
0004577803.tif 000011
【図１１】
0004577803.tif 000012
【図１２】
0004577803.tif 000013
【図１３】
0004577803.tif 000014
【図１４】
0004577803.tif 000015
【図１５】
0004577803.tif 000016
【図１６】
0004577803.tif 000017
【図１７】
0004577803.tif 000018
【図１８】
0004577803.tif 000019
【図１９】
0004577803.tif 000020
【図２０】
0004577803.tif 000021
【図２１】
0004577803.tif 000022
【図２２】
0004577803.tif 000023
【図２３】
0004577803.tif 000024
【図２４】
0004577803.tif 000025
【図２５】
0004577803.tif 000026
【図２６】
0004577803.tif 000027
【図２７】
0004577803.tif 000028
【図２８】
0004577803.tif 000029
【図２９】
0004577803.tif 000030
【図３０】
0004577803.tif 000031