JP2010086163A - 情報処理装置、プログラム及び通信システム - Google Patents

Abstract

【課題】通信状況又はアバタの設定情報等に基づいてアバタの属性データを変換するカスタマイズの可否を判断する情報処理装置を提供すること。
【解決手段】情報処理装置は、複数の端末とネットワークを経由して接続され、端末から送信されたアバタ変換リクエストを受信するリクエスト情報受信部１１１と、アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御部１３１と、アバタの属性データを管理するコンテンツ管理部１１２と、アバタ変換制御部により対象アバタの属性データの変換が可能と判断された場合対象アバタの属性データを変換するアバタ変換部１１３と、アバタ変換部により属性データが変換された対象アバタを端末に送信するレスポンス送信部１１５と、を備えている。
【選択図】図１０

Description

本発明は、仮想空間においてアバタを制御する情報処理装置、プログラム及び通信システムに関する。

近年、オンラインゲーム及びメタバース等の仮想空間でのコミュニケーションを行う通信形態が増加している。仮想空間ではアバタと呼ばれるユーザの分身として活動可能なようにプログラムされたキャラクタを操作して、仮想空間内をユーザ自身が動いている感覚を得ることができると共に、アバタを介して、ユーザ同士でチャット及び音声通信等のコミュニケーションを行うこともできる。また、自身のアバタをユーザの好みに応じて変化させることができ、仮想空間への感情移入度を高めることのできる通信システムが実現されている（例えば、特許文献１）。

また、仮想空間をビジネスに活用する一例として、バーチャルオフィス等のテレワークシステムが考案されている。ネットワークを利用して異なる場所から同一空間で行われる会議に参加しているかのように出席者アバタを画面上に表示するシステムが実用化されている（例えば、特許文献２）。

図１は仮想空間でのコミュニケーションを行う通信システム１０に係るシステム構成図を示している。通信システム１０は、仮想空間を提供する通信サーバ１１、コンピュータのネットワーク１２、及び複数の通信端末１３ａ等から構成される。

通信システム１０は、例えば通信サーバ１１によって構築される会議室等の仮想空間で、パソコン等の通信機能を有する通信端末１３ａを使用して操作可能な自身アバタ（以下、自アバタとする）を介して、ユーザ同士がコミュニケーションを行うことができるシステムである。

図２は自アバタの属性データの変換機能を備えた従来の通信サーバ１１の機能構成を説明する図である。図２に示すように、通信サーバ１１は、ユーザが通信端末１３から送信するリクエスト情報(通信端末使用者が閲覧したいコンテンツの要求、自アバタの制御指示情報)をリクエスト情報受信部２１で受信する。受信したリクエスト情報のうち必要なデータ(テキストや画像等)をコンテンツ管理部２２から入手し、コンテンツ決定部２４に送信する。ここで、自アバタ属性データの変更をする場合には、自アバタ変換部２３で自アバタの属性データを変更し、変更後の自アバタ属性データをコンテンツ決定部２４に送信する。このようにして、コンテンツ決定部２４にユーザが要求したデータ(テキストなど他者アバタに関係しないデータと変更後自アバタデータ)がそろえられてレスポンス送信部２５からネットワーク１２を介して通信端末１３へ送信される。

図３は、自アバタ変換部２３の機能構成を説明する図である。図３に示すように、変換対象アバタ及び変換指示情報受信部３１は、ユーザがどのアバタをどのように変換したいのかという指示情報（アバタ変換データ）から変換対象アバタＩＤ（通信端末利用者ＩＤ）を変換対象アバタ情報取得部３２に送信し、変換対象アバタ情報取得部３２は受信した情報に基づいて、コンテンツ管理部２２から、アバタの属性データ（画像等）を取得して、そのデータをアバタ変換実行部３４に送信する。一方、ユーザの指示情報のうちアバタの属性データの変換指示情報をアバタ変換情報記憶部３３が受信し、変換項目に該当する画像等のデータをアバタ変換実行部３４に送信する。
ここで、ユーザによるリクエスト情報について説明する。

図４及び図５はユーザが自アバタの属性データをカスタマイズする際に送信するアバタ変換データの一例を示している。自アバタのカスタマイズに必要なアバタ変換データは、通信端末利用者ＩＤ、変換対象アバタＩＤ及び変換情報である。通信端末利用者ＩＤは、通信端末を利用するユーザを認識するためのＩＤであり、変換対象アバタＩＤは、ユーザが操作可能なアバタを認識するためのＩＤである。ユーザである通信端末利用者は、通信端末利用者ＩＤと自アバタのアバタＩＤとを異なるように設定することも可能であるが、ここでは、通信端末利用者と該通信端末利用者の自アバタのアバタＩＤとを同一とする。また、一ユーザが複数のアバタを管理することも可能である。

アバタの属性データの変換情報は、表情、体形、髪型、服装、キャラクタ変換、登場音楽、照明及び匂いの８項目を設定し、各項目の選択肢の例を図５に示している。このように設定した変換情報について図４のように変換指示を出した場合には、ユーザの自アバタに、表情は笑顔、体形は太っている、髪形は長髪、服装は礼服、キャラクタ変換はなし、登場音楽は童謡、照明は赤色、匂いは温泉というような変換が施されることになる。

続いて、アバタ変換実行部３４は、変換対象アバタ情報取得部３２及びアバタ変換情報記憶部３３から送信されたデータを画像構成等の手段を用いてユーザの指示情報が反映された変換アバタを作成する。変換アバタの属性データは、アバタ情報送信部３５からコンテンツ決定部２４に送信され、最終的に通信端末１３に送信され、映像は通信端末のディスプレイで、登場音楽はスピーカー又はヘッドホン等の音出力機器で、匂いはアロマポットで出力されることとなる。また、変換アバタの属性データは、アバタ情報記憶部３６に保存され、新たにユーザによるアバタの変換指示がなされない限り、アバタ情報記憶部３６に保存されたアバタ情報に基づいて通信端末１３に送信されることになる。
特開２００２−２５９３１８号公報 特開２００２−３６０９３６号公報

しかし、ユーザのイメージする仮想空間となるようにアバタの属性データを変換することは、通信サーバにとって処理負荷が大きく、且つネットワークの通信負荷を高めるため、仮想空間における通信のリアルタイム性及び音質等を低下させるという問題がある。また、ユーザが仮想空間でのチャット及び会話等のコミュニケーションを行っている際にもユーザのイメージする仮想空間に近づけたいとアバタの属性データの変換にこだわりすぎてしまい、コミュニケーションが不足するという事態に陥るという問題がある。また、テレワークシステムにおける会議等では、複数の出席者に同一のアバタが用いられている事があり、他ユーザと該他ユーザが操作するアバタ（以下、他アバタとする）とのイメージが異なるあまり、見分けがつかないことに加え、コミュニケーションが悪くなるという問題がある。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、アバタの属性データを変換するカスタマイズは、通信状況又はアバタの設定情報等に基づいてアバタの属性データを変換するカスタマイズの可否を判断する通信サーバを提供することにある。

上記課題を解決するために、本発明のある観点によれば、複数の端末とネットワークを経由して接続され、端末から送信されたアバタ変換リクエストを受信するリクエスト情報受信部と、アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御部と、アバタの属性データを管理するコンテンツ管理部と、アバタ変換制御部により対象アバタの属性データの変換が可能と判断された場合、対象アバタの属性データを変換するアバタ変換部と、アバタ変換部により属性データが変換された対象アバタを端末に送信するレスポンス送信部と、を備える情報処理装置が提供される。

かかる構成によれば、アバタを表現する属性データの変換に伴う、通信サーバの処理負荷及びネットワークの通信負荷を軽減することができるため、仮想空間における通信のリアルタイム性及び音質等を低下させる要因を排除することができる。また、ユーザのイメージする仮想空間となるようにアバタのカスタマイズにこだわりすぎることを防止できるため、円滑なコミュニケーションを図ることができる。

また、アバタ変換制御部は、端末利用者が通信中か否かを判定する通信状況取得部を有し、該通信状況取得部によりアバタの属性データの変換の可否を判断してもよい。
また、通信状況取得部は、端末利用者が送信した通信パケットに含まれるポート番号により端末利用者がコミュニケーション中か否かを判断してもよい。

また、アバタ変換制御部は、サーバ負荷情報を判定するサーバ負荷監視部及びネットワークの負荷情報を判定するネットワーク負荷監視部の少なくとも一方を有し、対象アバタを表現する属性データの変換の可否を判断してもよい。

また、アバタの属性データは、端末利用者の変換許可情報及び地位情報を含み、該変換許可情報又は該地位情報に基づいて対象アバタの変換の可否を判断してもよい。

また、対象アバタの属性データ及びアバタ変換部により変換された属性データを記憶するアバタ情報記憶部をさらに備えてもよい。
また、対象アバタは、他アバタであってもよい。

また、上記課題を解決するために、本発明の他の態様によれば、複数の端末とネットワークを経由して接続され、端末から送信されたアバタ変換リクエストを受信するリクエスト情報受信処理と、通信信号の負荷状況に基づき、アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御処理と、アバタの属性データを管理するコンテンツ管理処理と、アバタ変換制御処理により対象アバタの属性データの変換が可能と判断された場合、対象アバタの属性データを変換するアバタ変換処理と、アバタ変換処理により属性データが変換された対象アバタを端末に送信するレスポンス送信処理と、をコンピュータに実行させるプログラムが提供される。

また、上記課題を解決するために、本発明の他の態様によれば、複数の端末がネットワークを経由して接続された通信システムであって、複数の端末のうちのいずれかがアバタ変換リクエストを送信し、複数の端末のうちの他のいずれかは、送信されたアバタ変換リクエストを受信するリクエスト情報受信部と、通信信号の負荷状況に基づき、アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御部と、アバタの属性データを管理するコンテンツ管理部と、アバタ変換制御部により対象アバタの属性データの変換が可能と判断された場合、対象アバタの属性データを変換するアバタ変換部と、アバタ変換部により属性データが変換された対象アバタを、アバタ変換をリクエストした端末に送信するレスポンス送信部と、を有する通信システムが提供される。

通信システムはテレビ会議システムであって、該テレビ会議システムに参加する所与の端末利用者のみの操作に応じて、アバタ変換リクエストに対して対象アバタの属性を変換してもよい。

以上説明したように本発明によれば、アバタの属性データは、通信状況又はアバタの設定情報等に基づいてアバタの属性データの変換可否を判断する情報処理装置、プログラム及び通信システムを提供することができる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、以下に示す項目順序に従って当該「発明を実施するための最良の形態」を説明する。
第１の実施形態
（１−１）他アバタ変換機能
（１−２）他アバタ変換機能を備えた通信サーバ
（１−３）他アバタの変換指示情報
（１−４）アバタ情報記憶部
（１−５）アバタ変換制御部
（１−６）第１の実施形態に係るアバタ変換制御部の構成
（１−７）第１の実施形態に係る通信サーバの処理
第２の実施形態
（２−１）第２の実施形態に係るアバタ変換制御部の構成
（２−２）第２の実施形態に係る通信サーバの処理
第３の実施形態
（３−１）第３の実施形態に係るアバタ変換制御部の構成
（３−２）第３の実施形態に係る通信サーバの処理

（第１の実施形態）
本発明に係る第１の実施形態は、通信システムにおける従来の自アバタの変換機能を他アバタの変換機能に利用し、アバタの属性データの変換の可否をコミュニケーション信号により判断する制御部を設けることを特徴とする通信システムである。

（１−１）他アバタ変換機能
従来の通信システムでは、自アバタの属性データを変換する機能を有するものは存在していたが、他アバタの属性データを変換する機能を有するものは存在しなかった。しかしながら、テレワークシステムにおける会議等では、複数の出席者が同一の仮想空間に出席することが考えられる。その際、参加ユーザによる自アバタのカスタマイズがなされていないアバタは、初期に与えられた同一のアバタであることが想定されるため、参加ユーザの見分けがつかなくなり、コミュニケーションに問題が生じることが考えられる。従って、テレワークシステムにおける会議等の参加ユーザが限られた仮想空間においては、他アバタをカスタマイズできることは業務の遂行に都合が良い。このため、本実施形態は、他アバタをユーザのイメージする仮想空間にふさわしくするために、他アバタの属性データを変換する機能を有すると共に、自アバタ及び他アバタの属性データ変換における変換可否を判断するアバタ変換制御部を有する通信システムを提供するものである。なお、他アバタのカスタマイズは、業務の遂行の目的のみに適用されても良い。

（１−２）他アバタ変換機能を備えた通信サーバ
以下、他アバタの属性データを変換する機能を備えた通信サーバについて説明する。
図６は他アバタの属性データを変換する機能を備えた通信サーバ１０１の機能構成を含む通信システムＳｙｓの全体構成図である。仮想空間でのコミュニケーションを行う通信システムＳｙｓは、通信サーバ１０１、ネットワーク１０２及び通信端末１０３からなり、従来と同一である。通信端末１０３は、パソコン、携帯電話、ゲーム機等の通信機能を持つものであればよい。

他アバタの属性データを変換する機能を備えた通信サーバ１０１は、自アバタの属性データを変換する通信サーバ１１の自アバタ変換部２３（図２）に換えてアバタ変換部１１３を設け、自アバタのみならず他アバタを指定してその外観等を変えることができる。

図６に示すように、通信サーバ１０１は、ユーザが通信端末１０３から送信するリクエスト情報(通信端末使用者が閲覧したいコンテンツの要求、自アバタ及び他アバタの制御指示情報)をリクエスト情報受信部１１１で受信する。受信したリクエスト情報のうち必要なデータ(テキストや画像等)をコンテンツ管理部１１２から入手し、コンテンツ決定部１１４に送信する。ここで、自アバタ及び他アバタの属性データの変更を実行する場合には、アバタ変換部１１３でアバタの属性データを変更し、変更後の属性データをコンテンツ決定部１１４に送信する。このようにして、コンテンツ決定部１１４にユーザが要求したデータがそろえられてレスポンス送信部１１５からネットワーク１０２を介して通信端末１０３へ送信する。

また、図７は、アバタ変換部１１３の機能構成を説明する図である。図７に示すように、変換対象アバタ及び変換指示情報受信部１２１は、ユーザがどのアバタをどのように変換したいのかという指示情報（アバタ変換データ）から変換対象アバタＩＤ（通信端末利用者ＩＤ）を変換対象アバタ情報取得部１２２に送信し、変換対象アバタ情報取得部１２２は受信した情報に基づいて、コンテンツ管理部１１２から、アバタの属性データ（画像等）を取得して、そのデータをアバタ変換実行部１２４に送信する。一方、ユーザの指示情報のうちアバタの属性データの変換指示情報をアバタ変換情報記憶部１２３が受信し、変換項目に該当する画像等のデータをアバタ変換実行部１２４に送信する。

続いて、アバタ変換実行部１２４は、変換対象アバタ情報取得部１２２及びアバタ変換情報記憶部１２３から送信されたデータを画像構成等の手段を用いて属性データが変換された変換アバタを作成する。変換アバタの属性データは、アバタ情報送信部１２５からコンテンツ決定部１１４に送信され、最終的に通信端末１０３に送信され、映像は通信端末のディスプレイで、登場音楽はスピーカーやヘッドホンなどの音出力機器で、匂いはアロマポットで出力されることとなる。また、変換アバタの属性データは、アバタ情報記憶部１２６に保存され、新たなアバタ変換指示がなされない限り、アバタ情報記憶部１２６に保存されたアバタ情報に基づいて通信端末１０３に送信されることになる。

なお、アバタ情報記憶部１２６は本技術の実施には必ずしも必要ではないが、同じ変換処理を無意味に繰り返すなどの重複処理を削減させることで通信サーバの負荷を軽減させるという効果を期待することができる。このアバタ情報記憶部１２６の機能については後述する。

（１−３）他アバタの変換指示情報
以下、他アバタの変換指示について説明する。
図８は、ユーザによる他アバタの変換指示情報であり、ユーザが他アバタをカスタマイズする際に送信するアバタ変換データの一例を示している。通信端末利用者ＩＤは、通信端末を利用するユーザを認識するためのＩＤであり、変換対象アバタＩＤは、ユーザがイメージする仮想空間に近づけるためにカスタマイズする他アバタを認識するためのＩＤである。

変換対象となる他アバタは、例えば、ユーザが、通信端末のディスプレイ等に表示されている映像の中に変換を行いたいと思うアバタをクリックすること、又は、ログイン中の利用者一覧から選択することなどにより決定され、自動的に変換対象アバタＩＤを入手することができる。

例えば、通信端末利用者ＩＤが０１２３４であるユーザが、仮想空間内に同一の映像で示された複数の他アバタを発見した場合に、変換対象アバタＩＤが９８７６５である他アバタを図８に示すような変換情報となるように変換指示をする。変換情報に従い、変換対象アバタＩＤが９８７６５である他アバタには、表情は笑顔、体形は痩せている、髪形はオールバック、服装はスーツ、キャラクタ変換はなし、登場音楽はクラシック、照明は青色、匂いは花というような変換が施されることになり、複数の他アバタと区別をすることが可能となる。

なお、通信端末利用者ＩＤ及び変換対象アバタＩＤを具体的に５桁の数字で表現しているが、この表現に限定されることはない。変換情報の項目、各変換項目のデータ構成及び選択肢は一例であり、図８、図５等に示したものに限定されないことは言うまでもなく、通信サーバと利用者間、及び各機能ブロック間で必要なデータをやり取りすることができるならば、どのような構成であってもよい。また、図８の変換対象アバタＩＤに自アバタＩＤを設定すれば、従来通り自アバタの変換も可能である。

（１−４）アバタ情報記憶部
図９（ａ）及び図９（ｂ）は、アバタ情報記憶部１２６を説明する図である。
図９（ａ）はユーザ毎に各アバタＩＤによって、アバタを変換した情報（アバタの属性データ）を管理している。アバタ情報記憶部１２６には、自アバタを含むアバタＩＤに対応して、属性データを変換したアバタについては変換後のアバタ情報が記憶され、属性データを変換していないアバタについては、初期設定のアバタ情報が記憶される。すなわち、アバタ情報記憶部１２６には、仮想空間に参加するユーザが操作する全てのアバタの属性データが通信端末利用者毎に記憶されている。具体的には、通信端末利用者ＩＤが０１２３４であるユーザは、アバタＩＤが０１２３４である自アバタをアバタ情報Ａのように変換したとする。また、アバタＩＤ９８７６５については、アバタ情報Ａ１、アバタＩＤ１３５７９については、アバタ情報Ａ２というように、変換している。一方、通信端末利用者ＩＤが９８７６５であるユーザは、アバタＩＤが０１２３４については、アバタ情報Ｂ１、アバタＩＤ９８７６５の自アバタはアバタ情報Ｂ、アバタＩＤ１３５７９については、アバタ情報Ｂ２に、変換している。仮想空間に存在する一アバタは、仮想空間に参加する通信端末利用者ぞれぞれのイメージに対応するものとして記憶される。このように、ユーザ毎に自アバタを含む他アバタのアバタ情報が管理されれば、仮想空間で遭遇する他アバタのイメージは、常にユーザのイメージと一致するように記憶されるため、ユーザのイメージする仮想空間を維持することが容易である。

また、図９（ｂ）は、ユーザにより変更された自アバタのアバタ情報のみが記憶されており、一アバタの属性データは、仮想空間に参加する全ユーザで共通の情報となる。すなわち、ユーザが他アバタをどのように変換したとしても、仮想空間で再度他アバタと遭遇するときは、他アバタを操作するユーザが変換する属性データに基づく変換がなされた他アバタで登場することになる。よって、他アバタは、他アバタを操作するユーザ好みのイメージが維持されることになる。なお、図９（ｂ）に示した、それぞれの自アバタの情報のみが記憶される場合は、コンテンツ管理部に記憶されていても良い。

（１−５）アバタ変換制御部
前述したように従来より、ユーザがイメージする仮想空間となるように自アバタを変換することが行われている。さらに、本実施形態では、参加ユーザが限られた仮想空間においては、業務の遂行に支障をきたさないようにするために他ユーザが操作するアバタの変換をユーザの操作範囲内のみですることができる。しかしながら、アバタの属性データの変換は通信サーバにとって処理負荷が大きく、且つネットワークの通信負荷を高める可能性がある。そのため、本実施形態では図６に示したアバタ変換部（自アバタ及び他アバタ変換機能）に加えて、アバタの属性データの変換可否を判断するアバタ変換制御部を設けた通信サーバを含む通信システムＳｙｓを提供する。

そこで、次に、本実施形態に係るアバタ変換制御部を設けた通信サーバについて説明する。
図１０は、アバタ変換制御部を設けた通信サーバの機能構成を説明する図である。図１０に示すように、アバタ変換制御部１３１は、通信サーバ１０１内のリクエスト情報受信部１１１とコンテンツ管理部１１２との間に設けられている。

アバタ変換制御部１３１は、ユーザが通信端末１０３から送信するリクエスト情報（アバタ変換リクエストに相当）のうちリクエスト情報受信部１１１を介して、アバタ変換に関する指示情報を受信し、リクエスト情報を解析すると共に、通信状況を監視して、アバタの属性データの変換可否を判断する。

第１の実施形態におけるアバタ変換制御部１３１は、チャット又は会話のセッションが有効となっているか否かに基づいて、アバタの属性データの変換の可否を判断する。

（１−６）第１の実施形態に係るアバタ変換制御部の構成
図１１は第１の実施形態に係るアバタ変換制御部１３１の機能構成を説明する図である。図１１に示すように、アバタ変換制御部１３１は、変換対象アバタ識別部１３３、通信状況取得部１３５、アバタ変換決定部１３７及びアバタ変換可否情報送信部１３９を有する。

アバタ変換制御部１３１は、ユーザが送信したアバタ変換に関する指示情報を解析して、変換対象アバタ識別部１３３から対象アバタ信号を送信し、通信状況取得部１３５からコミュニケーション信号を送信する。対象アバタ信号及びコミュニケーション信号を受信したアバタ変換決定部１３７は、変換可否信号をアバタ変換可否情報送信部１３９に送信する。

変換対象アバタ識別部１３３から送信される対象アバタ信号は、ユーザが変換したいアバタが自アバタであるか又は他アバタであるかを識別する信号である。また、通信状況取得部１３５から送信されるコミュニケーション信号は、ユーザの変換したいアバタがチャット又は会話等のコミュニケーション中であるか否かを識別する信号である。

図１２は変換対象アバタ識別部１３３の機能構成を説明する図である。
図１２に示すように、リクエスト情報取得部１４１で、ユーザである通信端末利用者が送信したリクエスト情報を参照し、通信端末利用者ＩＤと変換対象アバタＩＤとを取得する。本実施形態においては、通信端末利用者ＩＤは、通信端末利用者の自アバタＩＤと一致するとする。次に、アバタＩＤ照合部１４３で通信端末利用者ＩＤと変換対象アバタＩＤとを比較し、両者が一致するか否かを判定する。通信端末利用者ＩＤと変換対象アバタＩＤとが一致したら、変換対象は自アバタであり、通信端末利用者ＩＤと変換対象アバタＩＤとが一致しない場合は、変換対象が他アバタであると判定する。判定結果は、対象アバタ信号送信部１４５が受信し、対象アバタ信号送信部１４５から、対象アバタ信号がアバタ変換決定部１３７に送信される。対象アバタ信号は、例えば、変換対象が自アバタであれば０、変換対象が他アバタであれば１とするが、これに限定されるものではなく、変換対象が自アバタであるか又は他アバタであるかが判断できれば、どのような構成でもよい。

図１３は通信状況取得部１３５の機能構成を説明する図である。
通信状況取得部１３５は、通信パケットのヘッダーに含まれるポート番号を参照する等により、端末利用者すなわち変換対象アバタを操作するユーザがチャット又は会話等のコミュニケーション中であるか否かの状況を調査する。なお、変換対象アバタを操作するユーザがコミュニケーション中であるか否かは、ポート番号を参照する以外の方法でも調査できるが、ここでは、ポート番号によりコミュニケーション状況を判断することとする。

図１３に示すように、ポート番号取得部１５１は変換対象アバタの通信パケットに含まれるポート番号を取得し、ポート番号参照部１５３に送信する。ポート番号参照部１５３は、取得したポート番号をポート番号データベース１５５に照合して、コミュニケーションに用いるアプリケーションか否かを判定する。ポート番号データベース１５５は、コミュニケーションに用いるアプリケーション、例えばチャットプログラム等のポート番号が記録されている。取得したポート番号がポート番号データベース１５５に一致する場合コミュニケーション中であり、一致しない場合コミュニケーション中ではないと判定する。判定結果は、コミュニケーション信号送信部１５７が受信し、コミュニケーション信号送信部１５７からコミュニケーション信号としてアバタ変換決定部１３７に送信される。コミュニケーション信号は、例えば、変換対象アバタがコミュニケーション中でなければ０、コミュニケーション中であれば１とするが、これに限定されるものではなく、コミュニケーション中であるか否かが判断できれば、どのような構成でもよい。

このようにして、変換対象アバタ識別部１３３及び通信状況取得部１３５のそれぞれから送信される対象アバタ信号及びコミュニケーション信号に基づいて、アバタ変換決定部１３７は、変換対称アバタの属性データの変換の可否を決定し、変換可否信号としてアバタ変換可否情報送信部１３９に送信する。変換可否信号は、例えば、変換対称アバタの属性データの変換を許可するのであれば０、属性データの変換を許可しないのであれば１とするが、これに限定されるものではない。

図１４は、変換対称アバタの変換可否信号を決定するためのテーブルである。
図１４に示すように、変換可否信号は、変換対称アバタを操作する端末利用者がコミュニケーション中でない（コミュニケーション信号が０）の場合、アバタの属性データの変換が可能（変換可否信号が０）であり、変換対称アバタを操作する端末利用者がコミュニケーション中（コミュニケーション信号が１）の場合、アバタの属性データの変換を不可能（交換可否信号が１）としている。ここでは、コミュニケーション信号に基づいて、アバタの属性データの変換の可否を決定しているが、この判定方法に限定されるものではなく、自アバタであれば、コミュニケーション中であったとしてもアバタの属性データの変換は可能であると設定しても良い。

このようにして決定した変換可否信号に基づいて、アバタ変換可否情報送信部１３９から、アバタの属性データの変換が許可された場合は、図１０のアバタ変換部１１３に通信端末利用者のリクエスト情報が送信され、アバタの属性データの変換処理が実行される。一方、アバタの属性データの変換が許可されない場合は、図１０に示すように、アバタ変換制御部１３１からレスポンス送信部１１５にアバタ変換不可能の信号が送信され、最終的に、通信端末１０３にアバタ変換が不可能である旨が通知される。

以上説明したように、第１の実施形態に係る通信サーバ１０１は、アバタを操作する通信端末利用者のコミュニケーション状況に基づいてアバタの属性データの変換の可否を決定するアバタ変換制御部１３１を設けたことにより、変換対象アバタがコミュニケーション中か否かによりアバタの属性データの変換の可否を判断することができる。このため、アバタの属性データの変換による通信サーバ及びネットワークの負荷を低減できるので、通信のリアルタイム性及び音質の低下を防止することができる。また、アバタの属性データの変換を必要以上にこだわるために、コミュニケーションが不足するという事態を回避することもできる。以上の作用及び効果は、自アバタの属性データを変換する場合だけでなく、本実施形態で可能な他アバタの属性データを変換する場合にも有効である。

以上説明した各機能は、通信サーバを構成する図示しないＣＰＵ、ＲＯＭ、ＲＡＭ等により実現される。具体的には、以上に説明した各機能は、専用の制御デバイスあるいは、プログラムを実行するプロセッサ（ＣＰＵ）と、そのプロセッサで実行するプログラムとデータを記憶するＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶デバイスを含むハードウェア資源で実現される。なお、ここで説明した構成は、機能別に説明したものであり、実現するハードウェアの物理構成は、機能毎に明確に分離され、独立に用意される必要はない。次に、第１の実施形態に係る通信サーバ１０１の動作について説明する。

（１−７）第１の実施形態に係る通信サーバの処理
図１５は、第１の実施形態に係るアバタ変換可否判定処理の流れを示している。
図１５に示すように、ユーザが通信端末１０３からユーザのイメージする仮想空間に近づけるために、属性データを変換するアバタを決定することにより通信サーバ１０１によるアバタの変換がスタートする（Ｓ１６０）。ユーザの指示情報から変換対象アバタＩＤ及び通信端末利用者ＩＤを取得する（Ｓ１６１）。取得した変換対象アバタＩＤと通信端末利用者ＩＤとを照合して、変換対象アバタがユーザの自アバタか他アバタかを判定し（Ｓ１６２）、その結果を送信する（Ｓ１６３）。一方、変換対称アバタの通信状況を通信パケットに含まれるポート番号等から取得する（Ｓ１６４）。取得したポート番号から、変換対象アバタがコミュニケーション中か否かを判定し（Ｓ１６５）、その結果をコミュニケーション信号として送信する（Ｓ１６６）。コミュニケーション信号に基づき変換対象アバタがコミュニケーション中であるか否かを判定し（Ｓ１６７）、変換対象アバタがコミュニケーション中でなければ変換対象アバタの変換可否信号を変換可（図１４では０）と設定し（Ｓ１６８）、変換対象アバタがコミュニケーション中であれば変換対称アバタの変換可否信号を変換不可（図１４では１）と設定する（Ｓ１６９）。変換可否信号が送信され（Ｓ１７０）、本処理を終了する（Ｓ１７１）。これにより、ユーザは、変換可否信号により、変換対象アバタの変換後の外観等アバタの属性データ変換可否の旨を知ることができる。

なお、Ｓ１６１〜Ｓ１６３とＳ１６４〜Ｓ１６６との実行順序は、図１５に示す順に代えて、Ｓ１６４〜Ｓ１６６を先に実行してもよく、Ｓ１６１〜Ｓ１６３とＳ１６４〜Ｓ１６６とを並列で同時に実行してもよい。

以上のアバタ変換制御の流れにより、変換対象アバタがコミュニケーション中にはアバタの属性データの変換を実施することができない。このため、アバタの属性データの変換による通信サーバ及びネットワークの負荷を低減できるので、通信のリアルタイム性及び音質の低下を防止することができる。

（第２の実施形態）
本発明に係る第２の実施形態は、自アバタ及び他アバタの属性データの変換の可否をサーバの負荷情報又はネットワークの負荷情報により判断する制御部を設けることを特徴とする通信システムである。

複数のユーザが同時に一サーバを利用した状況下で、アバタの属性データを変換する等の処理は通信サーバにとって処理負荷が大きく、且つネットワークの通信負荷を高める可能性がある。このような処理が行われると、仮想空間における通信のリアルタイム性及び音質等を低下させるに止まらず、最悪の場合には、通信サーバの機能停止という事態に至る危険性がある。従って、サーバの負荷情報及びネットワークの負荷情報を監視し、サーバの負荷情報又はネットワークの負荷情報に応じてアバタの属性データの変換の可否を判断することが重要となる。なお、本実施形態に係る通信システムＳｙｓ及び通信サーバ１０１の構成は、図１０に示し、第１の実施形態にて説明した構成と同じであるため、ここでは説明を省略する。

（２−１）第２の実施形態に係るアバタ変換制御部の構成
図１６は第２の実施形態に係るアバタ変換制御部１３１の機能構成を説明する図である。図１６に示すように、アバタ変換制御部１３１は、サーバ負荷監視部２０１、ネットワーク（ＮＷ）負荷監視部２０３、アバタ変換決定部２０５及びアバタ変換可否情報送信部２０７を有する。

サーバ負荷監視部２０１からサーバ負荷情報に基づいたサーバ負荷信号と、ネットワーク負荷監視部２０３からネットワーク負荷情報に基づいたネットワーク負荷信号とがアバタ変換決定部２０５に送信され、アバタ変換決定部２０５は、変換可否信号をアバタ変換可否情報送信部２０７に送信する。アバタ変換可否情報送信部２０７から送信された変換可否信号に基づいてアバタの属性データの変換可否が決定される。

図１７はサーバ負荷監視部２０１の機能構成を説明する図である。サーバ負荷監視部２０１はサーバ負荷情報としてサーバの統計情報であるロードアベレージ(ＣＰＵの平均負荷)を取得することを想定している。

サーバ負荷監視部２０１は、サーバ負荷情報取得部２１１、サーバ統計情報記録部２１３、サーバ負荷判定部２１５及びサーバ負荷信号送信部２１７を有する。サーバ負荷情報取得部２１１は、ロードアベレージ又はメモリ使用量等のサーバの統計情報が格納されているサーバ統計情報記録部２１３に問い合わせて、ロードアベレージを取得する。なお、サーバ統計情報記録部２１３はサーバ内のデータファイルという形式でサーバ上に存在する。ＯＳによって格納位置は異なるが、ＯＳがLinuxの場合、「/proc/cpuinfo」内に格納されているから、これを参照すればよい。取得したロードアベレージは、サーバ負荷判定部２１５に送信し、所定の閾値と比較して、閾値よりも小さければ、サーバ負荷は小さいと判定し、閾値よりも大きければ、サーバ負荷は大きいと判定する。サーバ負荷信号は、例えば、図１９に示したように、サーバ負荷が小さいなら０、サーバ負荷が大きいなら１とするが、これに限定されるものではない。

なお、閾値の設定は、サーバに使用されているＣＰＵ数とするのが一般的である。例えば、サーバに搭載されているＣＰＵが４つであれば、閾値を４に設定し、ロードアベレージが４未満ならばサーバ負荷が小さく、４以上ならばサーバ負荷が大きいと判定する。ロードアベレージの閾値の設定にサーバに使用されたＣＰＵ数を用いることは一例であり、他の基準を用いてもよい。

また、サーバの統計情報として、ロードアベレージを用いているが、ロードアベレージに換えて、例えばメモリ使用量等の情報を用いても良い。さらに、サーバ負荷情報とメモリ使用量との組み合わせ等、複数の統計情報を用いて判定しても良い。
こうして判定されたサーバ負荷信号は、サーバ負荷信号送信部２１７から、アバタ変換決定部２０５に送信される。

図１８は、ネットワーク負荷監視部２０３の機能構成を説明する図である。ネットワーク負荷監視部２０３はネットワーク負荷情報としてパケット損失率を用いることを想定している。

ネットワーク負荷監視部２０３は、ネットワーク負荷情報取得部２２１、ネットワーク統計情報記録部２２３、ネットワーク負荷判定部２２５及びネットワーク負荷信号送信部２２７を有する。ネットワーク負荷情報取得部２２１は、ネットワーク統計情報が記録されているネットワーク統計情報記録部２２３に問い合わせて、受信したパケット数と破棄された受信パケット数とを取得する。なお、ネットワーク統計情報記録部２２３はサーバ内のデータファイルという形式でサーバ上に存在する。ＯＳによって格納位置は異なるが、ＯＳがLinuxの場合、「/proc/net/snmp」内に格納されているから、これを参照すればよい。ネットワーク統計情報記録部２２３から取得した、受信したパケット数と破棄された受信パケット数とをネットワーク負荷判定部２２５に送信し、ネットワーク負荷判定部２２５においてパケット損失率(＝破棄された受信パケット÷受信したパケット数×１００)を計算する。パケット損失率を所定の閾値と比較して、閾値よりも小さければネットワーク負荷が小さいと判定し、閾値よりも大きければネットワーク負荷が大きいと判定する。ネットワーク負荷信号は、例えば図１９に示したように、ネットワーク負荷が小さいなら０、ネットワーク負荷が大きいなら１とするが、これに限定されるものではない。なお、第２の実施形態においては、ネットワーク負荷の閾値を１％に設定するが、この値には一例であり、他の値を用いてもよい。

また、ネットワーク負荷情報として、パケット損失率を用いているが、パケット損失率に換えて他の情報を用いても良い。
こうして判定されたネットワーク負荷信号は、ネットワーク負荷信号送信部２２７から、アバタ変換決定部２０５に送信される。

このようにして、サーバ負荷監視部２０１及びネットワーク負荷監視部２０３のそれぞれから送信されるサーバ負荷信号及びネットワーク負荷信号に基づいて、アバタ変換決定部２０５は、変換対称アバタの属性データの変換の可否を決定し、変換可否信号としてアバタ変換可否情報送信部２０７に送信する。変換可否信号は、例えば、変換対称アバタの属性データの変換を許可するであれば０、属性データの変換を許可しないのであれば１とするが、これに限定されるものではない。

具体的に、図１９のアバタの属性データの変換可否信号を決定するためのテーブルを参照しながら、変換可否信号の設定手順を説明する。

変換可否信号は、サーバ負荷信号及びネットワーク負荷信号のいずれもが所定の閾値よりも小さい（サーバ負荷信号及びネットワーク負荷信号いずれも０）の場合、通信信号の負荷が小さいと判定して変換可否信号が０に設定される。一方、サーバ負荷信号及びネットワーク負荷信号の少なくとも一方が所定の閾値よりも大きい場合、通信信号の負荷が大きいと判定して、変換可否信号が１に設定される。第２の実施形態においてはサーバ及びネットワークのいずれも負荷が小さい場合のみアバタの属性データの変換を可能としているが、この判断方法に限定するものではない。例えば、サーバの負荷信号のみからアバタの属性データの変換の可否を決定してもよい。サーバ負荷信号及びネットワーク負荷信号がともに大きい場合にのみアバタの属性データの交換を不可能としても良い。

このようにして決定した変換可否信号に基づいて、アバタの属性データの変換がなされるが、第１の実施形態と同一であるため、説明を省略する。

以上説明したように、第２の実施形態に係る通信サーバ１０１は、サーバ及びネットワークの負荷状況に基づいてアバタの属性データの変換の可否を決定するアバタ変換制御部１３１を設けた。これにより、サーバ又はネットワークの少なくとも一方の負荷が大きい状況下でアバタの属性データの変換をすることは許可されない。このため、アバタの属性データの変換による通信サーバ及びネットワークへの負荷がかかることを抑制することができるため、通信のリアルタイム性及び音質が低下することを防止することができる。次に、第２実施形態に係る通信サーバ１０１の動作について説明する。

（２−２）第２の実施形態に係る通信サーバの処理
図２０は、第２の実施形態に係るアバタ変換可否判定処理の流れを示している。
図２０に示すように、ユーザが通信端末１０３からユーザのイメージする仮想空間に近づけるために、属性データを変換するアバタを決定することにより通信サーバ１０１によるアバタの変換がスタートする（Ｓ２３０）。サーバの負荷情報をサーバの統計情報等から取得する（Ｓ２３１）。取得したサーバの負荷情報からサーバの負荷状況を判定し（Ｓ２３２）、その結果をサーバ負荷信号として送信する（Ｓ２３３）。一方、ネットワークの負荷情報をネットワーク統計情報等から取得する（Ｓ２３４）。取得したネットワーク統計情報からネットワークの負荷状況を判定し（Ｓ２３５）、その結果をネットワーク負荷信号として送信する（Ｓ２３６）。通信サーバ及びネットワークの負荷状況に基づいて、アバタの属性データの変換が可能か否かを判定する（Ｓ２３７）。アバタの属性データの変換が可能であればアバタの変換可否信号を変換可（図１９では０）と設定し（Ｓ２３８）、アバタの属性データの変換が不可能であれば変換対称アバタの変換可否信号を変換不可（図１９では１）と設定する（Ｓ２３９）。変換可否信号が送信され（Ｓ２４０）、本処理を終了する（Ｓ２４１）。これにより、変換可否信号により、変換対象アバタの変換後の外観等アバタの属性データの変換可否の旨がユーザに知らされる。

なお、Ｓ２３１〜Ｓ２３３とＳ２３４〜Ｓ２３６との実行順序は、図２０に示す順に代えて、Ｓ２３４〜Ｓ２３６を先に実行してもよく、Ｓ２３１〜Ｓ２３３とＳ２３４〜Ｓ２３６とを並列で同時に実行してもよい。

以上のアバタ変換制御の流れにより、本実施形態では、通信サーバ又はネットワークの負荷が大きいときにはアバタの属性データの変換を実施することは許可されない。このため、アバタの属性データの変換に基づく通信サーバ及びネットワークの負荷を抑制することができるので、通信のリアルタイム性及び音質の低下を防止することができる。

（第３の実施形態）
本発明に係る第３の実施形態はアバタの属性データの変換の可否は、アバタを操作するユーザにより設定されたアバタの情報に基づいて属性データの変換が可能か否かを判断する制御部を設けることを特徴とする通信システムである。

テレワークシステムにおける会議等では、複数のユーザが同一の仮想空間に出席することが考えられ、参加ユーザのそれぞれが操作するアバタを特徴付けるためにアバタの属性データの変換が盛んに行われることが考えられる。しかしながら、本来業務を円滑にするために行う他アバタの属性データの変換が興味本位に行われる等して、業務の遂行を阻害することになりかねない。また、アバタによって表現される階級差が希薄になり、業務の遂行及びコミュニケーション等に問題が生じることが考えられる。また、参加ユーザが自アバタのみならず他アバタを変換する場合、他ユーザの通信端末にのみ表現される範囲であっても、自分のアバタを勝手にカスタマイズされることが気になり、コミュニケーションに支障をきたす危険性がある。従って、アバタを操作するユーザから他ユーザによるアバタの属性データを変換する許可又はユーザの実社会での地位等の情報に基づいて、アバタの属性データの変換の可否を、判断することが重要となる。なお、本実施形態に係る通信システムＳｙｓ及び通信サーバ１０１の構成は、図１０に示し、第１の実施形態にて説明した構成と同じであるため、ここでは説明を省略する。

（３−１）第３の実施形態に係るアバタ変換制御部の構成
図２１は第３の実施形態に係るアバタ変換制御部１３１の機能構成を説明する図である。図２１に示すように、アバタ変換制御部１３１は、許可情報取得部３０１、地位情報取得部３０３、アバタ変換決定部３０５及びアバタ変換可否情報送信部３０７を有する。アバタ変換制御部１３１及び許可情報取得部３０１はアバタ変換制御部１３１の外部に設けられたコンテンツ管理部１１２に情報を取得するための問い合わせを行う。

許可情報取得部３０１は許可情報要求信号を、地位情報取得部３０３は地位情報要求信号をそれぞれコンテンツ管理部１１２に送信する。許可情報要求信号を受信したコンテンツ管理部１１２からは許可情報応答信号が許可情報取得部３０１に送信され、地位情報要求信号を受信したコンテンツ管理部１１２からは地位情報応答信号が地位情報取得部３０３に送信される。なお、許可情報には、ユーザが操作するアバタの属性データを他ユーザにより変換されることを許可しているか否かが含まれ、地位情報には、ユーザの属する実社会等での役職等の情報が含まれている。

許可情報取得部３０１は許可情報応答信号から、アバタの属性データを変換することが許可されているかどうかを判定し、変換許可情報信号としてアバタ変換決定部３０５に送信する。一方で、地位情報取得部３０３は地位情報応答信号からユーザが属する実社会等での役職情報を取得して、地位情報信号としてアバタ変換決定部３０５に送信する。アバタ変換決定部３０５は、変換許可情報信号又は地位情報信号に基づいてアバタの属性データの変換の可否を決定し、変換可否信号としてアバタ変換可否情報送信部３０７に送信する。変換可否信号は、例えば、変換対称アバタの属性データの変換を許可するであれば０、属性データの変換を許可しないのであれば１とするが、これに限定されるものではない。

図２２は、アバタ変換制御部１３１からコンテンツ管理部１１２にアバタの情報を要求する要求信号及びコンテンツ管理部１１２からの応答信号の例を示す図である。具体的に、アバタＩＤ８６２３０の属性データの変換が可能かどうかについて説明する。

ユーザが変換対象アバタを決定すると、アバタ変換制御部１３１から、変換対象アバタＩＤ、許可情報要求信号及び地位情報要求信号がコンテンツ管理部１１２に送信される。アバタ変換制御部１３１は許可情報及び地位情報を保持していないため、初期値が例えば３２７６７が格納される。許可情報要求信号及び地位情報要求信号を受信したコンテンツ管理部１１２は、変換対象アバタの許可情報と地位情報とを検索し、その結果を送信する。コンテンツ管理部１１２は、許可情報については他ユーザによるアバタの属性データの変換を許可する場合には変換許可情報信号が０、許可しないならば変換許可情報信号が１である。地位情報については一般社員ならば地位情報信号を０、課長ならば地位情報信号を１、部長以上ならば地位情報信号を２とするが、この構成に限定されるものではない。ここでは、アバタＩＤが８６２３０のユーザは、他ユーザによるアバタの変換を許可していない（変換許可情報信号が１）部長以上の役職（地位情報信号が２）である。従って、アバタＩＤが８６２３０のアバタは、他ユーザが属性データを変換することが不可能である。仮想空間に参加する全ユーザは、アバタＩＤが８６２３０のアバタを操作するユーザが表現した同一のアバタとして認識することになる。

なお、コンテンツ管理部１１２には、各ユーザのアバタの属性データ、他ユーザによるアバタの変換許可情報及び地位情報等が図９（ｂ）のように管理されている。

具体的に、図２３のアバタの属性データの変換可否信号を決定するためのテーブルを参照しながら、変換可否信号の設定手順を説明する。ここでは、部長以上（地位情報信号２）が操作するアバタの属性データの変換は、許可されないものとする。すなわち、ユーザが他ユーザによる自アバタの属性データの変換を許可しており（変換許可情報信号が０）、且つ、部長以上の役職でない（地位情報信号０又は１）ユーザのアバタは、他ユーザによるアバタの属性データの変換が許可されるが、他ユーザによる自アバタの属性データの変換を許可していない（変換許可情報信号が１）か、又は部長以上の役職であるユーザのアバタは他ユーザによるアバタの属性データの変換が許可されない。例えば、アバタＩＤが０１２３４のアバタは、他ユーザによる自アバタの属性データの変換を許可しており、役職は課長である。従って他ユーザによるアバタの属性データの変換が可能である。一方アバタＩＤが９８７６５のアバタは、他ユーザによる自アバタの変換を許可していないため、役職にかかわらず、他ユーザによるアバタの属性データの変換が不可能である。第３の実施形態で、変換可否信号を決定した変換許可情報及び地位情報は一例であり、他のユーザの情報を用いても良い。

以上説明したように、第３の実施形態に係る通信サーバ１０１は、ユーザにより設定されたアバタの属性データの変換の可否は、アバタを操作するユーザの情報に基づいて、判断するアバタ変換制御部１３１を設けたことにより、他ユーザの通信端末のみに表現される範囲であっても、アバタを操作するユーザにより設定されて許可の可否を決定することができる。このため、業務の遂行及びコミュニケーションに支障をきたす問題の発生を抑制することができる。次に、第３の実施形態に係る通信サーバ１０１の動作について説明する。

（３−２）第３の実施形態に係る通信サーバの処理
図２４は、第３の実施形態に係るアバタの変換可否処理の流れを示している。
図２４に示すように、ユーザが通信端末１０３からユーザのイメージする仮想空間に近づけるために、属性データを変換するアバタを決定することにより通信サーバ１０１によるアバタの変換がスタートする（Ｓ３１０）。属性データを変換する変換対象アバタＩＤを取得する（Ｓ３１１）。変換対象アバタＩＤから、変換対象アバタの許可情報を取得し（Ｓ３１２）、取得した情報を変換許可情報信号として送信する（Ｓ３１３）。一方、変換対象アバタＩＤから、変換対象アバタの地位情報を取得し（Ｓ３１４）、取得した情報を地位情報信号として送信する（Ｓ３１５）。変換許可情報信号及び地位情報信号に基づいて、アバタの属性データの変換が可能か否かを判定する（Ｓ３１６）。アバタの属性データの変換が可能であればアバタの変換可否信号を変換可（図２３では０）と設定し（Ｓ３１７）、アバタの属性データの変換が不可能であれば変換対称アバタの変換可否信号を変換不可（図２３では１）と設定する（Ｓ３１８）。変換可否信号が送信され（Ｓ３１９）、本処理を終了する（Ｓ３２０）。変換可否信号により、変換対象アバタの変換後の外観等アバタの属性データの変換可否の旨がユーザに知らされる。

なお、Ｓ３１２〜Ｓ３１３とＳ３１４〜Ｓ３１５との実行順序は、図２４に示す順に代えて、Ｓ３１４〜Ｓ３１５を先に実行してもよく、Ｓ３１２〜Ｓ３１３とＳ３１４〜Ｓ３１５とを並列で同時に実行してもよい。

以上のアバタ変換制御の流れにより、アバタを操作するユーザの設定した情報に基づいてアバタの変換の可否が決定される、このため、業務の遂行及びコミュニケーションに支障をきたす問題の発生を抑制することができると共に、快適に業務を遂行することを維持できることになる。

第３の実施形態で、変換可否信号の決定に用いて変換許可情報及び地位情報は一例であり、他のユーザの情報を用いても良いことはいうまでもない。また、社内データである社員スケジュール表等の情報を利用して変換可否信号の決定を行っても良い。例えば、会議中は、全てのアバタの属性データの変換が許可されないが、休憩時間であれば、アバタの属性データの変換を許可する、休憩時間であれば役職にかかわらずアバタの属性データの変換を許可するなど、設定を変更することができる。

以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。

例えば、上記実施形態では、クライアント・サーバ型の通信システムを例に挙げて、通信サーバが、クライアント端末側からのリクエストに応じて、一極集中してアバタ変換処理を実行したが、本発明はかかる例に限定されない。例えば、本発明は、ピアツーピア（Ｐｅｅｒ ｔｏ Ｐｅｅr）型の通信システムに応用することができる。すなわち、ネットワークを経由して接続されたＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）等のいずれかの端末からのリクエストに応じて、他のいずれかの端末（情報処理装置）がアバタ変更処理を実行するようにしてもよい。

従来の通信システムに係るシステム構成図である。 従来の通信サーバの機能構成を説明する図である。 従来の自アバタ変換部の機能構成を説明する図である。 自アバタの属性データをカスタマイズする際に送信するアバタ変換データである。 自アバタの属性データをカスタマイズする際に送信するアバタ変換データの交換情報を示す図である。 第１の実施形態に係る通信システムＳｙｓの全体構成図である。 第１の実施形態に係るアバタ変換部の機能構成を説明する図である。 第１の実施形態に係るユーザによる他アバタの変換指示情報である。 （ａ）及び（ｂ）は、第１の実施形態に係るアバタ情報記憶部を説明する図である。 第１の実施形態に係るアバタ変換制御部を設けた通信サーバの機能構成を説明する図である。 第１の実施形態に係るアバタ変換制御部の機能構成を説明する図である。 第１の実施形態に係る変換対象アバタ識別部の機能構成を説明する図である。 第１の実施形態に係る通信状況取得部の機能構成を説明する図である。 第１の実施形態に係る変換対称アバタの変換可否信号を決定するためのテーブルである。 第１の実施形態に係るアバタ変換可否判定処理の流れを示す図である。 第２の実施形態に係るアバタ変換制御部の機能構成を説明する図である。 第２の実施形態に係るサーバ負荷監視部の機能構成を説明する図である。 第２の実施形態に係るネットワーク負荷監視部の機能構成を説明する図である。 第２の実施形態に係るアバタの属性データの変換可否信号を決定するためのテーブルである。 第２の実施形態に係るアバタ変換可否判定処理の流れを示す図である。 第３の実施形態に係るアバタ変換制御部の機能構成を説明する図である。 第３の実施形態に要求信号及び応答信号の例を示す図である。 第３の実施形態に係るアバタの属性データの変換可否信号を決定するためのテーブルである。 第３の実施形態に係るアバタの変換可否処理の流れを示す図である。

符号の説明

１０１ 通信サーバ
１０２ ネットワーク
１０３ 通信端末
１１１ リクエスト情報受信部
１１２ コンテンツ管理部
１１３ アバタ変換部
１１４ コンテンツ決定部
１１５ レスポンス送信部
１２１ 変換対象アバタ及び変換指示情報受信部
１２２ 変換対象アバタ情報取得部
１２３ アバタ変換情報記憶部
１２４ アバタ変換実行部
１２５ アバタ情報送信部
１２６ アバタ情報記憶部
１３１ アバタ変換制御部
１３３ 変換対象アバタ識別部
１３５ 通信状況取得部
１３７ アバタ変換決定部
１３９ アバタ変換可否情報送信部
１４１ リクエスト情報取得部
１４３ アバタＩＤ照合部
１４５ 対象アバタ信号送信部
１５１ ポート番号取得部
１５３ ポート番号参照部
１５５ ポート番号データベース
１５７ コミュニケーション信号送信部
２０１ サーバ負荷監視部
２０３ ネットワーク負荷監視部
２０５ アバタ変換決定部
２０７ アバタ変換可否情報送信部
２１１ サーバ負荷情報取得部
２１３ サーバ統計情報記録部
２１５ サーバ負荷判定部
２１７ サーバ負荷信号送信部
２２１ ネットワーク負荷情報取得部
２２３ ネットワーク統計情報記録部
２２５ ネットワーク負荷判定部
２２７ ネットワーク負荷信号送信部
３０１ 許可情報取得部
３０３ 地位情報取得部
３０５ アバタ変換決定部
３０７ アバタ変換可否情報送信部

Claims (10)

1. 複数の端末とネットワークを経由して接続され、端末から送信されたアバタ変換リクエストを受信するリクエスト情報受信部と、
   前記アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御部と、
   アバタの属性データを管理するコンテンツ管理部と、
   前記アバタ変換制御部により前記対象アバタの属性データの変換が可能と判断された場合、前記対象アバタの属性データを変換するアバタ変換部と、
   前記アバタ変換部により属性データが変換された前記対象アバタを前記端末に送信するレスポンス送信部と、
   を備える情報処理装置。
2. 前記アバタ変換制御部は、端末利用者が通信中か否かを判定する通信状況取得部を有し、該通信状況取得部によりアバタの属性データの変換の可否を判断する請求項１に記載の情報処理装置。
3. 前記通信状況取得部は、前記端末利用者が送信した通信パケットに含まれるポート番号により、前記端末利用者が通信中か否かを判断する請求項２に記載の情報処理装置。
4. 前記アバタ変換制御部は、サーバ負荷情報を判定するサーバ負荷監視部及びネットワークの負荷情報を判定するネットワーク負荷監視部の少なくとも一方を有し、前記サーバ負荷監視部及びネットワーク負荷監視部の少なくとも一方により、前記対象アバタの属性データの変換の可否を判断する請求項１〜３のいずれか１項に記載の情報処理装置。
5. 前記アバタの属性データは、前記端末利用者の変換許可情報及び地位情報を含み、該変換許可情報又は該地位情報に基づいて前記対象アバタの変換の可否を判断する請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記対象アバタの属性データ及び前記アバタ変換部により変換された属性データを記憶するアバタ情報記憶部をさらに備える請求項１〜５のいずれか１項に記載の情報処理装置。
7. 前記対象アバタは、他アバタである請求項１〜６のいずれか１項に記載の情報処理装置。
8. 複数の端末とネットワークを経由して接続され、端末から送信されたアバタ変換リクエストを受信するリクエスト情報受信処理と、
   通信信号の負荷状況に基づき、前記アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御処理と、
   アバタの属性データを管理するコンテンツ管理処理と、
   前記アバタ変換制御処理により前記対象アバタの属性データの変換が可能と判断された場合、前記対象アバタの属性データを変換するアバタ変換処理と、
   前記アバタ変換処理により属性データが変換された前記対象アバタを前記端末に送信するレスポンス送信処理と、
   をコンピュータに実行させるプログラム。
9. 複数の端末がネットワークを経由して接続された通信システムであって、
   前記複数の端末のうちのいずれかがアバタ変換リクエストを送信し、
   前記複数の端末のうちの他のいずれかは、
   前記送信されたアバタ変換リクエストを受信するリクエスト情報受信部と、
   通信信号の負荷状況に基づき、前記アバタ変換リクエストに係る対象アバタの属性データの変換の可否を判断するアバタ変換制御部と、
   アバタの属性データを管理するコンテンツ管理部と、
   前記アバタ変換制御部により前記対象アバタ属性データの変換が可能と判断された場合、前記対象アバタ属性データを変換するアバタ変換部と、
   前記アバタ変換部により属性データが変換された前記対象アバタを、前記アバタ変換をリクエストした端末に送信するレスポンス送信部と、を有する通信システム。
10. 前記通信システムはテレビ会議システムであって、該テレビ会議システムに参加する所与の端末利用者のみの操作に応じて、前記アバタ変換リクエストに対して前記対象アバタの属性を変換する請求項９に記載の通信システム。

Images