(57)【要約】【課題】メッセージ受信側から明示的な状態通知がなくても無用な再試行を抑制することのできるユニファイド・コミュニケーションシステム及びそのメッセージ伝達方法を提供する。【解決手段】ユニファイド・コミュニケーションシステム１は、メッセージ受信側の利用状況を把握する把握部２と、把握部２により把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する算出部３と、算出部３により算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する選択部４と、選択部４により選択されたメッセージメディアを使用してメッセージ伝達を行う伝達部５とを備える。【選択図】図１
2015156545.tif 000002
【特許請求の範囲】
【請求項１】
メッセージ受信側の利用状況を把握する把握部と、
前記把握部により把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する算出部と、
前記算出部により算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する選択部と、
前記選択部により選択されたメッセージメディアを使用してメッセージ伝達を行う伝達部と
を備えることを特徴とするユニファイド・コミュニケーションシステム。
【請求項２】
前記算出部は、メッセージメディアに対応する通信回線が通信中かどうかにより利用者のプレゼンスを推定し、その推定結果に基づいて前記選択優先度を算出することを特徴とする請求項１記載のユニファイド・コミュニケーションシステム。
【請求項３】
前記算出部は、メッセージメディアに対応する通信回線が通信中である場合は、その通信状況により利用者のプレゼンスを推定し、その推定結果に基づいて前記選択優先度を算出することを特徴とする請求項２記載のユニファイド・コミュニケーションシステム。
【請求項４】
前記選択部は、利用者から指定された選択優先度と、前記算出部により算出された選択優先度とに基づいて、メッセージ伝達に使用するメッセージメディアを選択することを特徴とする請求項１から３のいずれか１項に記載のユニファイド・コミュニケーションシステム。
【請求項５】
メッセージ受信側の利用状況を把握する把握ステップと、
前記把握ステップにおいて把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する算出ステップと、
前記算出ステップにおいて算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する選択ステップと、
前記選択ステップにおいて選択されたメッセージメディアを使用してメッセージ伝達を行う伝達ステップと
を備えることを特徴とするユニファイド・コミュニケーションシステムのメッセージ伝達方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアを受信端末に適したものに変換してメッセージ伝達を行うユニファイド・コミュニケーションシステム及びそのメッセージ伝達方法に関する。
【背景技術】
【０００２】
通信には、発信者と受信者の間に直接の通信経路を確保して行う同期通信と、直接の通信経路を確保せず、中間の情報蓄積機能を経由した蓄積転送により情報伝達を行う非同期通信とがある。ユニファイド・コミュニケーションは、メディアを受信端末に適したものに変換してメッセージ伝達を行うものである。例えば、蓄積転送可能なメッセージ情報を安否情報伝達に利用する災害用伝言板などのＷｅｂサービスでは、特定人物に対して確実にメッセージ伝達を行うことが重要である。そこで、非同期通信によるユニファイド・コミュニケーションシステムを適用することにより、このような災害用伝言板などのＷｅｂサービスでやりとりしているメッセージデータを電話系通信データに変換して情報通知することが考えられる。
【０００３】
ただし、通常の非同期通信では、情報の伝達を受ける側の利用者の能動的動作により通信が実行されるので、この能動的動作の完了と同時に情報の確実な伝達が確認できたこととなる。一方、非同期通信データを電話系通信データに変換して、電話やＦＡＸなどの電話系サービスを同期通信で転送する場合、非同期のＷｅｂサービスとは通信特性が異なるため、確実なメッセージ伝達を行うためには、利用者に成り代わり追加の通信処理手続きが必要となることがある。このような伝達を受ける側の状態を確認する補完機能としてプレゼンスなどの利用が考えられる。
【０００４】
また、この種のシステムとして、特許文献１のクラウドサービス提供システムがある。特許文献１には、オールＩＰネットワークにおいて、ＩＭＳ（IP Multimedia Subsystem）やサービス提供基盤ＳＤＰ（Service Delivery Platform）とユーザ端末ＵＥとを連携させて効率的にクラウドサービスを提供することが開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１１−１８２０３１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来、非同期通信によるユニファイド・コミュニケーションを電話系サービスにより実現する場合、メッセージが受信側の利用者により確認されたことをシステムレベルで確認する手段はなく、受信側の利用者が別途の方法で受信確認を行っていた。このため、利用者レベルでの受信確認が遅れると、メッセージの送達が確認できていないものとして再試行がなされることも多く、網に無用な負荷を与える可能性があった。
【０００７】
本発明は、上記の問題点に着目してなされたもので、メッセージ受信側から明示的な状態通知がなくても無用な再試行を抑制することのできるユニファイド・コミュニケーションシステム及びそのメッセージ伝達方法を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記目的を達成するため、第１の態様に係る発明は、ユニファイド・コミュニケーションシステムであって、メッセージ受信側の利用状況を把握する把握部と、前記把握部により把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する算出部と、前記算出部により算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する選択部と、前記選択部により選択されたメッセージメディアを使用してメッセージ伝達を行う伝達部とを備えることを要旨とする。
【０００９】
第２の態様に係る発明は、第１の態様に係る発明において、前記算出部が、メッセージメディアに対応する通信回線が通信中かどうかにより利用者のプレゼンスを推定し、その推定結果に基づいて前記選択優先度を算出することを要旨とする。
【００１０】
第３の態様に係る発明は、第２の態様に係る発明において、前記算出部が、メッセージメディアに対応する通信回線が通信中である場合は、その通信状況により利用者のプレゼンスを推定し、その推定結果に基づいて前記選択優先度を算出することを要旨とする。
【００１１】
第４の態様に係る発明は、第１から第３のいずれかの態様に係る発明において、前記選択部が、利用者から指定された選択優先度と、前記算出部により算出された選択優先度とに基づいて、メッセージ伝達に使用するメッセージメディアを選択することを要旨とする。
【００１２】
また、上記目的を達成するため、第５の態様に係る発明は、ユニファイド・コミュニケーションシステムのメッセージ伝達方法であって、メッセージ受信側の利用状況を把握する把握ステップと、前記把握ステップにおいて把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する算出ステップと、前記算出ステップにおいて算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する選択ステップと、前記選択ステップにおいて選択されたメッセージメディアを使用してメッセージ伝達を行う伝達ステップとを備えることを要旨とする。
【発明の効果】
【００１３】
本発明によれば、メッセージ受信側から明示的な状態通知がなくても無用な再試行を抑制することのできるユニファイド・コミュニケーションシステム及びそのメッセージ伝達方法を提供することができる。
【図面の簡単な説明】
【００１４】
【図１】本発明の実施の形態におけるユニファイド・コミュニケーションシステムの構成例を示す図である。
【図２】本発明の実施の形態におけるユニファイド・コミュニケーションシステムの動作例を示すフローチャートである。
【図３】本発明の実施の形態におけるユニファイド・コミュニケーションシステムの具体例を示す図である。
【図４】比較例及び実施例にかかるメッセージ伝達要求の受付処理を示すフローチャートである。
【図５】比較例にかかるメディア選択処理を示すフローチャートである。
【図６】実施例にかかるメディア選択処理を示すフローチャートである。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態について図面を参照して詳細に説明する。
【００１６】
（ユニファイド・コミュニケーションシステム）
図１は、本発明の実施の形態におけるユニファイド・コミュニケーションシステム１の構成例を示す図である。このユニファイド・コミュニケーションシステム１は、機能的には、把握部２と、算出部３と、選択部４と、伝達部５とを備える。把握部２は、メッセージ受信側の利用状況を把握する。ここでいう“メッセージ受信側の利用状況”とは、メッセージ受信側の各種情報であり、メッセージ受信側やその他の通信網から観測可能なあらゆる情報を含む（後述する）。算出部３は、把握部２により把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する。選択部４は、算出部３により算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する。伝達部５は、選択部４により選択されたメッセージメディアを使用してメッセージ伝達を行う。これにより、メッセージ受信側の利用状況に基づいてメッセージ受信側の利用者に適したメッセージメディアが選択されるため、メッセージ受信側から明示的な状態通知がなくても無用な再試行を抑制することができる。その結果、ユニファイド・コミュニケーションのメッセージ伝達率を向上させることが可能となる。
【００１７】
具体的には、算出部３は、メッセージメディアに対応する通信回線が通信中かどうかにより利用者のプレゼンスを推定し、その推定結果に基づいて選択優先度を算出してもよい。これにより、メッセージメディアに対応する通信回線が通信中かどうかに基づいて選択優先度が算出されるため、より適切なメッセージメディアを選択することができる。
【００１８】
また、算出部３は、メッセージメディアに対応する通信回線が通信中である場合は、その通信状況により利用者のプレゼンスを推定し、その推定結果に基づいて選択優先度を算出してもよい。これにより、メッセージメディアに対応する通信回線が通信中である場合は、その通信状況に基づいて選択優先度が算出されるため、より適切なメッセージメディアを選択することができる。
【００１９】
また、選択部４は、利用者から指定された選択優先度と、算出部３により算出された選択優先度とに基づいて、メッセージ伝達に使用するメッセージメディアを選択してもよい。これにより、利用者から指定された選択優先度を考慮してメッセージメディアが選択されるため、より適切なメッセージメディアを選択することができる。
【００２０】
（メッセージ伝達方法）
図２は、本発明の実施の形態におけるユニファイド・コミュニケーションシステム１の動作例を示すフローチャートである。
【００２１】
まず、把握部２は、メッセージ受信側の利用状況を把握する（ステップＳ１）。例えば、ユニファイド・コミュニケーションでメッセージの受信者となる個々の利用者ごとに、この利用者が利用する可能性のある端末の利用状況や、当該端末宛てにメッセージ伝達を行う際に利用する網内リソースの利用状況をリアルタイムで把握し、利用者ごとにデータベース化する。
【００２２】
次いで、算出部３は、潜在的メッセージ受信者宛てのメッセージ伝達要求があった場合（ステップＳ２：ＹＥＳ）、把握ステップＳ１において把握された利用状況に基づいて、メッセージ伝達に使用するメッセージメディアの選択肢について選択優先度を算出する（ステップＳ２）。例えば、データベースにアクセスして、当該メッセージ受信者に関連付けられた端末の利用状況などを取得し、この端末の利用状況などに基づいて選択優先度を算出する。
【００２３】
次いで、選択部４は、算出ステップＳ３において算出された選択優先度に基づいて、メッセージ伝達に使用するメッセージメディアを選択する（ステップＳ４）。ただし、利用者から選択優先度が指定されている場合は、利用者から指定された選択優先度と、算出ステップＳ３において算出された選択優先度とに基づいて、メッセージ伝達に使用するメッセージメディアを選択する。例えば、固定電話を家族で共用する場合、この固定電話は利用者本人に使用されるとは限らないため、利用者から指定された選択優先度を考慮するのが妥当である。
【００２４】
最後に、伝達部５は、選択ステップＳ４において選択されたメッセージメディアを使用してメッセージ伝達を行う（ステップＳ５）。具体的には、選択ステップＳ４において選択されたメディアフォーマットへメッセージ変換を行い、そのメッセージメディアに対応する端末に送信する。
【００２５】
（具体例）
図３は、本発明の実施の形態におけるユニファイド・コミュニケーションシステム１の具体例を示す図である。ここでは、メッセージ受信側を電話系サービス（電話網２２）、メッセージ送信側をＷｅｂサービス（インターネット網２１）により実現する場合を例示している。
【００２６】
図３に示すように、ユニファイド・コミュニケーションシステム１は、外部システムやユーザによる送信リクエストを受け付けるＷｅｂサーバ１１と、ユーザの通信手続きを代行するＷｅｂ−ＡＰサーバ１２と、通信手続きに関わるデータなどを保持するＷｅｂ−ＤＢサーバ１３と、電話系サービスの機能処理を受け持つＰＦ−ＡＰサーバ（プラットフォームサーバ）１４と、メディア変換処理を受け持つメディアサーバ１５とを備える。ＰＦ−ＡＰは、Ｐａｒｌａｙ−ＸのＡＰＩを有するＳＤＰ（service delivery platform）をベースとして構成される。ただし、テキスト・音声変換機能、音声・テキスト変換機能、テキスト・画像変換機能などのＰａｒｌａｙ−Ｘで規定されていないインターフェースについては拡張して実装する。
【００２７】
以下、このようなユニファイド・コミュニケーションシステム１がユーザによる送信リクエストを受け付けた場合の動作について説明する。まず、Ｗｅｂサーバ１１は、インターネット網２１を介してユーザから送信されたメッセージ（テキスト、音声、画像など）をＨＴＴＰリクエストとして受け付けると、そのデータをＷｅｂ−ＡＰサーバ１２へ転送する。これにより、Ｗｅｂ−ＡＰサーバ１２は、Ｗｅｂ−ＤＢサーバ１３にアクセスして各種のユーザデータ（サービス登録、事前宛先登録、再送回数設定など）や通信データ（網状態、通信状態、通信回数など）を参照し、通信タスク処理を実施する。通信タスク処理のフローは次の通りである。
【００２８】
・各種のユーザデータや通信データに基づいて通知先を選択する。
【００２９】
・選択した通知先に適したメディア変換を実施する。
【００３０】
・変換されたデータを用いて通知する。
【００３１】
ここでは、通知先端末として多種の電話系端末を例示している。Ｗｅｂ−ＡＰサーバ１２は、電話網２２の状態により通知先端末に通知ができなかった場合（不出、話中、輻輳、故障/障害中など）、そのレスポンス結果を網状態情報として管理し、通知制限、通知先端末変更、再送などの処理を実行する。通知制限のレベル例としては、（１）無制限通知、（２）保留呼時間制限（音声・ＦＡＸデータを短い時間に制限）、（３）テキスト制限（ＳＭＳ通知）などがある。
【００３２】
このようなユニファイド・コミュニケーションシステム１によれば、電話系通信の網リソースなどの周辺条件に応じて通知内容や通知先端末などを包括的に管理し、制御することができる。言い換えると、通信状態に変化がある状況でも、利用者に適した通知内容・時間・端末を自動調整して、サービスを提供することが可能である。
【００３３】
図３では、「電話中状態」「ＤＴＭＦ発信状態」など、電話網２２から取得した情報を通信選択の判断に活用する場合を想定しているが、本発明はこれに限定されるものではない。すなわち、電話網２２以外（外部システム）からの情報を通信選択の判断に活用することもできる。例えば、インターネット網２１からの情報をＷｅｂ−ＡＰサーバ１２が取得するようにしてもよい。このようにすれば、通信会社や気象庁の災害情報サイトで提供しているＷｅｂＡＰＩ（ＡＰＩ：アプリケーションインターフェース）などからシステムの障害情報や罹災情報を取得し、通信選択の判断に活用することも可能である。
【００３４】
（メディア選択処理）
次に、メッセージ伝達に使用するメディアを選択する処理について詳細に説明する。
【００３５】
−  比較例  −
図４および図５は、比較例にかかるメディア選択処理を示すフローチャートである。この比較例では、前もって定めておいた選択優先度に従って、選択候補となる各メディアに変換してメッセージの伝達を試みる。
【００３６】
例えば、Ｗｅｂ−ＡＰサーバ１２は、図４に示すように、メッセージ伝達要求を受け取ると、メッセージメディアの選択制御を行うための通信処理テーブルにカウンタ値を設定する（ステップＳ１１→Ｓ１２）。このカウンタは、選択候補となる各メディアの選択優先度に応じて伝達を試みる周期を制御するためのものである。一方、図５に示すように、通信処理テーブルを一定周期で参照し、各カウンタ値を１ずつ減算し、カウンタ値が１となる選択肢があれば、当該選択肢でのメッセージ伝達を試みる（ステップＳ２１→Ｓ２２→Ｓ２３→Ｓ２４）。メッセージ伝達が完了しなかった場合はカウンタをリセットし、次の試行実施に備える（ステップＳ２５→Ｓ２６）。
【００３７】
このような非同期通信のユニファイド・コミュニケーションでは、例えば、受信者を呼び出して音声メッセージを伝達しようとしても、メッセージを伝達すべき相手が電話機の周辺に不在でメッセージの伝達が完了しない場合がある。このような受信側利用者の状態についてプレゼンス機能が提供されていれば、これを利用することも考えられるが、プレゼンス機能は一部で実用化されているだけで、一般に広く使われているわけではない。そのため、システム機能としてメッセージ伝達の確認機能を提供せずに、実際にメッセージを受け取った利用者自身が個別にメッセージ内容の確認を連絡するのを待つという方法に頼らなければならない。
【００３８】
−  実施例  −
図４および図６は、実施例にかかるメディア選択処理を示すフローチャートである。この実施例は、伝達の候補となるメディアに変換したメッセージを利用者に伝達するのに使用する網内リソースの使用状況を把握して、確実にメッセージ伝達が期待できる最適なメッセージメディアを選択するものである。図４に示されるメッセージ伝達要求の受付処理は比較例と同じであるため、ここでは詳しい説明を省略する。
【００３９】
例えば、Ｗｅｂ−ＡＰサーバ１２は、図６に示すように、通信処理テーブルを一定周期で参照する際、まず、各メディアに対応する受信者回線が、その時点で通信に使用されているかどうかを確認する（ステップＳ３１→Ｓ３２）。そして、通信に使用されている場合は、メッセージを伝達すべき受信者が回線を使用している可能性が高いと判断し、当該通信の終了を待って、直ちにメッセージ伝達を実行する（ステップＳ３２→Ｓ３４→Ｓ３７）。一方、通信に使用されていない場合は、当該回線が故障あるいは輻輳でないことを確認して、各カウンタ値を１ずつ減算し、カウンタ値が１となる選択肢があれば、当該選択肢でのメッセージ伝達を試みる（ステップＳ３２→Ｓ３３→Ｓ３５→Ｓ３６→Ｓ３７）。メッセージ伝達が完了しなかった場合はカウンタをリセットし、次の試行実施に備える（ステップＳ３８→Ｓ３９）。当該回線が故障あるいは輻輳の場合は、カウンタの減算処理を行わず、次の試行実施に備える（ステップＳ３３）。
【００４０】
この実施例によれば、例えば、特定のメッセージメディアの伝達に使用する回線を受信者が使用中である場合、その通信の直後にも、目的の受信者が対応する端末の周辺にいることが期待でき、より確実なメッセージ伝達が期待できる。また、特定のメディアによるメッセージ伝達トラヒックが集中し、確実な配送が期待できない場合、当該メッセージメディアによる伝達を避け、より確実な他のメッセージメディアを選択することができる。
【００４１】
なお、この実施例では、選択候補となるメッセージメディアに対応する通信回線が通信中かどうかにより利用者のプレゼンスを推定しているが、より詳細な通信状況を把握すれば、より精密なプレゼンスを推定することができる。例えば、同じ通信中の状態であっても、着呼により通信中である場合はＦＡＸ等の自動応答機能により通信が行われている可能性もあるため、当該利用者から発呼された場合の方が着呼により通信中である場合に比べて利用者が端末周辺にいる可能性が高いと推定される。また、通信中の利用者トラヒックのボリュームが上下均等の場合は、トラヒックボリュームが一方に偏っている場合に比べて実時間会話型通信が実施されている可能性が高く、利用者が端末周辺にいる可能性が高いと推定される。特に、トラヒックボリュームがメッセージ送信先の利用者方向に偏っている場合、受信側がマシンによる自動受信である可能性が高く、通信終了後にメッセージ伝達を試みてもメッセージ伝達が完了しないことも考えられる。また、通信中にＤＴＭＦ信号を受信する等の利用者の積極動作を推測させる事象が観測報告された場合、利用者のプレゼンスが強く期待できるので、より積極的な対応を行うことも考えられる。このようなプレゼンスの推定結果に基づいて選択優先度を算出すれば、より適切なメッセージメディアを選択することが可能となる。
【００４２】
＜その他のプレゼンス推定例＞
以下に説明するプレゼンス推定結果を適宜組み合わせて選択優先度を算出してもよい。
【００４３】
まず、第１のプレゼンス推定例について説明する。通知先として登録されている電話回線の電話発信情報が得られると、その時間帯にその電話機近辺に人物が居ることがわかる。このような情報を利用すれば、通知先へ音声メッセージを発信すると繋がる（そして情報通知できる）可能性が非常に高い。
【００４４】
次に、第２のプレゼンス推定例について説明する。通知先として登録されている電話回線の電話着呼、通話および切断情報が得られると、その時間帯にその電話機近辺に人物が居ることがわかる。このような情報を利用すれば、通知先へ音声メッセージを発信すると繋がる（そして情報通知できる）可能性が高い。ただし、留守番電話などの自動応答機能があるため、第１のプレゼンス推定例よりは確実性が低い。
【００４５】
次に、第３のプレゼンス推定例について説明する。通知先として登録されている電話回線（携帯電話、スマートフォン）のＳＭＳ発信情報が得られると、その時間帯にその電話機（携帯電話、スマートフォン）近辺に人物が居ることがわかる。このような情報を利用すれば、通知先へ音声メッセージ、ショートメッセージを発信すると繋がる（そして情報通知できる）可能性が非常に高い。
【００４６】
次に、第４のプレゼンス推定例について説明する。通知先として登録されている電話回線（電話機、ＦＡＸ機、携帯電話、スマートフォン）の回線故障情報が得られると、その回線による通知が不能であることがわかる。このような情報を利用すれば、メッセージ伝達時に通知不能な回線を除外することで情報通知の確実性が高い回線を選択することができる。
【００４７】
次に、第５のプレゼンス推定例について説明する。通知先として登録されている電話回線（電話機、ＦＡＸ機、携帯電話、スマートフォン）の回線輻輳情報が得られると、その回線による通知がすぐには実施できないことがわかる。このような情報を利用すれば、メッセージ伝達時に即時の通知ができない回線を除外することで情報通知の確実性が高い回線を選択することができる。
【００４８】
次に、第６のプレゼンス推定例について説明する。通知先として登録されている電話回線からのＤＴＭＦ情報が得られると、その回線から能動的にＤＴＭＦ信号が発信されており、その電話機（携帯電話、スマートフォン）近辺に人物が居ることがわかる。このような情報を利用すれば、通知先へ音声メッセージ、ショートメッセージを発信すると繋がる（そして情報通知できる）可能性が非常に高い。
【００４９】
最後に、第７のプレゼンス推定例について説明する。通知先として登録されている電話回線（電話機、ＦＡＸ機、携帯電話、スマートフォン）の話中情報が得られると、その回線による通知が不能であることがわかる。更に、話中情報が得られた後に話中解除されたことがわかると、その直後には人物がいる可能性が高いことがわかる。このような情報を利用すれば、話中時にメッセージ伝達を行わず、話中解除後を見計らい通知先へ音声メッセージ、ショートメッセージを発信すると繋がる（そして情報通知できる）可能性が非常に高い。
【００５０】
以上説明したように、本発明の実施の形態におけるユニファイド・コミュニケーションシステム１によれば、メッセージ受信側の利用状況に基づいてメッセージ受信側の利用者に適したメッセージメディアが選択されるため、メッセージ受信側から明示的な状態通知がなくても無用な再試行を抑制することができる。その結果、ユニファイド・コミュニケーションのメッセージ伝達率を向上させることが可能となる。
【００５１】
以上のように、本発明の実施の形態を記載したが、この開示の一部をなす論述および図面は例示的なものであり、この発明を限定するものであると理解すべきではない。この開示から当業者には様々な代替実施の形態、実施例および運用技術が明らかとなろう。このように、本発明は、ここでは記載していない様々な実施の形態などを含む。
【符号の説明】
【００５２】
１…ユニファイド・コミュニケーションシステム
２…把握部
３…算出部
４…選択部
５…伝達部
【図１】
2015156545.tif 000003
【図２】
2015156545.tif 000004
【図３】
2015156545.tif 000005
【図４】
2015156545.tif 000006
【図５】
2015156545.tif 000007
【図６】
2015156545.tif 000008