キャラクタデータに対するタグ検索方法および検索サーバ
【課題】複数のユーザの端末と通信ネットワークを介して接続されたサーバが、複数のユーザが作成するキャラクタデータを検索する方法を提供すること。
【解決手段】ネットワーク環境において利用されるキャラクタデータに対して複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、この複数のタグを、キャラクタデータと関連づけて格納するタグ・テ−ブルに記憶するステップと、前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、検索した結果を送信するステップと、を含むことを特徴とする方法を提供する。タグは、キャラクタ全体、キャラクタを構成するアイテム、アイテムの属性、それぞれに対して付加し、検索の際の重み付けを指定することも可能とする。
【解決手段】ネットワーク環境において利用されるキャラクタデータに対して複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、この複数のタグを、キャラクタデータと関連づけて格納するタグ・テ−ブルに記憶するステップと、前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、検索した結果を送信するステップと、を含むことを特徴とする方法を提供する。タグは、キャラクタ全体、キャラクタを構成するアイテム、アイテムの属性、それぞれに対して付加し、検索の際の重み付けを指定することも可能とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、キャラクタデータにタギングして検索する方法、検索サーバに関する。特に、通信ネットワークに接続された端末から入力したユーザのキャラクタデータにタグ付けをし、それらのデータを検索する方法、検索サーバおよびプログラムに関する。
【背景技術】
【０００２】
インターネットの社会への普及に伴い、ネットワーク上で情報を閲覧したり、検索したり、あるいは商品を購入したり、といった受身のユーザのみならず、ユーザ自らが情報の発信者としてＷｅｂ上で擬似的な日記（いわゆるブログ）を公開したり、嗜好の一致する者同士でコミュニティを構成したり、といった積極的な行動をとるユーザが急速に増加している。
【０００３】
特に、ブログがこの数年で急速に普及した背景には、インターネットの初心者でも簡単にホームページに文章や写真を登録して発信できるブログエディターの果たした貢献が大きいものと考えられる。
【０００４】
そして、こうしたブログの社会への普及は、単に通信ネットワークに接続できる端末によって情報を閲覧していた時代には考えられなかったネットワーク上の社会（いわゆるネットワークコミュニティ）が現実の社会とは別にもう一つ出現し、急速に発展しつつあることを示している。
【０００５】
こうした状況において、ネットワーク上でユーザ自身を表すシンボルとして、「アバター」を活用するユーザが増加している。「分身」を意味するアバターは、具体的には画像データ、動画データ、音声データ等で表現されたいわゆるキャラクタであるが、現実の社会とは別に存在するネットワークコミュニティにおいて自分自身を表現し、他のユーザと対話し、共感し、議論し、同好の友人関係を広げる、といった様々な活動において、擬似的な行動主体としてその存在意義を高めている。
【０００６】
具体的には、例えば、ブログを公表する際に、アバターを画面の中で活用することにより、ユーザの書き込みによる文書とは別にユーザ自身をキャラクタデータにより直感的に表現することができるので、それを見る人にあたかもネットワーク上に自分の分身が存在するかのような感覚を抱かせ、ネットワークコミュニティにおけるコミュニケーションを強力にサポートすることができる。
【０００７】
実際に、このアバターの髪型、服装、アクセサリ、小物、背景などのアイテムをコーディネートすること自体がネットワークコミュニティにおいてユーザ自身のセンスや嗜好をアピールするために重要な活動の一つとなっている。このため、ユーザはこのようなアイテムを有償で購入したり、友人にプレゼントしたりしており、アバターのコーディネートは経済活動の対象ともなっている。
【０００８】
したがって、現実社会において洋服を購入したり、アクセサリや小物をコーディネートしたりすることと同様に、アバターのコーディネート活動はネットワーク上でユーザの嗜好を判断したり、ネットワークコミュニティにおける流行や変化を捉えたりする上で重要な分析対象ともなっている。
【０００９】
こうした状況において、通常は、ユーザが予め用意されたアイテムの中から自由に選択することにより、好みのアバターを生成するという方法がとられるが、アバター管理装置（サーバ）によって自動的にアバターを生成・更新する方法も提案されている。
【００１０】
例えば、特許文献１には、ユーザに心理テストを実行させることにより当該ユーザの属性を決定し、決定された属性のアクセサリ（アイテム）画像を用いて基本画像に対して変更を行い、アバター画像を生成する方法が開示されている。
【特許文献１】特開２００５−３３２０９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、こうした特許文献１の技術では、アバターを生成・更新する画像作成のための技術的手法については開示されているものの、ユーザ自身が目的とするイメージに合ったアバターを生成しようとした場合に、それをサポートするような方法については開示されていない。通常、ユーザは、自分が作成しようとするアバターを構成するイメージに合ったアイテムを予めシステムで用意されたアイテム一覧表から選択する。しかしこのような方法では、アイテムの数が増えていくにしたがってユーザの選択作業は大きな負荷となる。ユーザは、自分自身の分身となるアバターを作成する場合、アイテム一覧表から試行錯誤的にアイテムを選択するのではなく、目的イメージにあったより効率的な作成方法を望むと考えられる。したがって、ユーザがキャラクタデータを作成するためには、ユーザのイメージに合うアイテムを多数のアイテムの中から効率的に検索できるような方法を提供することが望ましい。
【００１２】
本発明は、上記課題を解決し、ユーザがキャラクタデータを作成する際に、目的とするキャラクタのイメージにあったアイテムを簡単に検索できるようにする方法を提供することを目的とする。また、一致するキャラクタを容易に検索する方法も提供する。
【課題を解決するための手段】
【００１３】
上記目的のため、具体的には、以下のようなものを提供する。
【００１４】
（１） 複数のユーザの端末と通信ネットワークを介して接続されたサーバが、前記複数のユーザが作成するキャラクタデータを検索する方法であって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを、前記キャラクタデータと関連づけてタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を含むことを特徴とする方法。
【００１５】
このような構成とすることで、キャラクタデータ（例えば、アバターおよびその構成要素であるアイテムに関連するデータ）に対して、複数のユーザが入力した任意の文字列からなる複数のタグを受信し、そのタグを、前記キャラクタデータと関連づけて格納するタグ・テーブル（例えば、後述のアバタータグ・テーブル、アイテムタグ・テーブル、属性タグ・テーブルなど）に記憶し、タグを検索することでユーザの要求に応じたキャラクタデータ（例えば、アバター全体、アバターを構成するアイテム、そのアイテムの属性）を検索し、検索したそれぞれの結果を前記ユーザの端末に送信することができ、検索の精度や柔軟性を高める、という作用効果を奏する。
【００１６】
ここでキャラクタデータとは、例えば、キャラクタをアバターとした場合、アバターそのもの、アバターを構成するアイテム（例えば、「顔」、「服装」、「履物」、「ペット」、「背景」など）、そのアイテムの属性（「色」、「模様」、「材質」、「季節感」、「国柄」、「大きさ」などアイテムによって様々なものが考えられる）のそれぞれをコンピュータ上で表現するためのデータの集まりを示すものとする。ここでタグはアバターやアイテムの作成者に限られず、このシステムのユーザ全てが任意の文字列からなるタグを付けることができる。
【００１７】
したがって、このような構成では一つのキャラクタデータに複数のタグが付けられることになるが、ユーザ数が多くなればなるほどキャラクタを特徴付けるタグが自然と生成されると考えられ、逆に検索に役立たないタグは自然淘汰され得ると考えられる。このように、様々な要素からなるキャラクタデータをその要素または全体にユーザが任意に入力したタグを付加することによって、検索の効率（ヒット率）を高めることができる。
【００１８】
（２）前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、（１）に記載の方法。
【００１９】
このような構成とすることで、ユーザが作成したキャラクタ全体に対してタグを付加し、キャラクタ全体として検索することができる。これは最も単純なタグ付けであり、キャラクタ全体のイメージを重視する検索の場合などにこのタグを用いることができる。
【００２０】
（３）前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、（１）または（２）に記載の方法。
【００２１】
このような構成とすることで、キャラクタを構成する様々なアイテムをタグによって検索することができる。つまり、そのタグが付けられた全てのアイテムを検索することができる。例えば、タグに「中華風」、「イタリア風」などの用語を用いて、「中華風」、「イタリア風」などのイメージを持つアイテムをその分類項目（アイテムをその種類で分類する項目）に関わらずに網羅的に検索することができる。
【００２２】
（４）前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、（１）〜（３）に記載の方法。
【００２３】
このような構成とすることで、キャラクタを構成する個々のアイテムそのものだけでなく、各アイテムが持つ各種の属性（例えばアイテムが服装の場合は、「色」、「季節」、「国柄」など）にタグ付けし更に細かく検索することで、その属性タグによって検索の精度を高めることができる。このような属性による検索は、アバター全体やアイテム個々のタグによる検索だけでは不十分な場合に有用である。例えば、アバター全体のタグ（アバタータグ）を「湘南ギャル」とし、水着のアイテムのタグ（アイテムタグ）を「セパレーツ」に、それぞれタグ付けされている場合、この２つのタグに加えて水着アイテムの一つの属性として「色」について更に「パステルカラー」のようなタグを付加する。これによって単に色を「水色」とか「ピンク」とタグ付けするよりもよりイメージに近いタグを付加できる。
【００２４】
（５） 前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、（１）〜（４）に記載の方法。
【００２５】
このような構成とすることで、ユーザが検索したいタグと文字列が完全に一致しなくとも類義語辞書などを用いて類似のタグを検索できる。例えば、「赤」、「赤色」、「レッド」、「Ｒｅｄ」などは、類義語であるが、同一タグとみなしたほうがより目的とする検索ができる。
【００２６】
（６）前記タグの検索は、検索されるタグに対して所定の重み付けを行う、（１）〜（５）に記載の方法。
【００２７】
このような構成とすることで、（２）〜（４）で述べたタグの３つの種類に対して検索の際の重み付けを指定することができる。この重み付け順位はユーザに指定させるようにすることが望ましい。例えば、同じ「チャイナ風」でも全体イメージを重視したければ、アバター全体に対する重み付けを上げておき、逆に、小物のイメージを重視したければ、アイテムに対する重み付けを上げておく。検索結果に対してこの重み付け順位を加味してその順位の高い順に検索結果を表示するようにしてもよい。あるいは、重み付け順位の高い順に検索を行ったり、重み付けの最も高いタグの種類にのみ検索を行うようにしてもよい。
【００２８】
（７） 前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、（６）に記載の方法。
【００２９】
このような構成とすることで、（６）に述べた重み付け方法を更にアイテムの分類項目の構造に従って行うことができる。通常、アイテムは、「顔」、「服装」、「履物」、「持ち物」、「ペット」、「背景」などの大分類にまず分類され、それぞれの大分類毎に更に中分類、小分類に項目分けされる。例えば、大分類が「服装」の場合、中分類は、「トップス」、「ボトムス」などに分類され、更に「ボトムス」は、「ズボン」、「スカート」などに小分類される。このようにアイテムの分類項目は、一般的にはツリー構造をなしている。通常は、重み付けを固定付けとしてもよいが、ユーザの指定により、どの分類を重視するかで検索の効率を高めることができる。また、この所定の重み付けは、ツリー構造で定義されたアイテムの分類項目の上位項目からに下位項目の順に従って重み付けを行うようにすること（重み付けの順を大分類、中分類、小分類以下とする）により広い分類項目から順に検索することができるので、一般的には検索効率を高めることができる。
【００３０】
（８） 前記所定の重み付けは、前記ユーザから指定されたアイテムの分類項目に基づいて行う、（７）に記載の方法。
【００３１】
このような構成とすることで、ユーザは予め定義されたアイテムの分類項目対して検索の対象とする範囲を指定することができる。例えば、あるタグに関して検索対象を「服装」としたり、より狭い範囲にしたければ「上着」とすることができる。
【００３２】
（９） 複数のユーザの端末と通信ネットワークを介して接続され、前記複数のユーザが作成するキャラクタデータを検索するサーバであって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するタグ受信部と、
前記受信したタグを、前記キャラクタデータと関連づけてタグ・テーブルに記憶するタグ付加部と、
ユーザの端末の要求に応じて前記タグが付加されたキャラクタデータを検索するタグ検索部と、
前記検索した結果を送信する検索結果送信部と、
を備えることを特徴とするサーバ。
【００３３】
このような構成とすることで、当該サーバを運用することにより、（１）と同様の効果が得られる。
【００３４】
（１０）前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、（９）に記載のサーバ。
【００３５】
このような構成とすることで、当該サーバを運用することにより、（２）と同様の効果が得られる。
【００３６】
（１１） 前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、（９）または（１０）に記載のサーバ。
【００３７】
このような構成とすることで、当該サーバを運用することにより、（３）と同様の効果が得られる。
【００３８】
（１２） 前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、（９）〜（１１）に記載のサーバ。
【００３９】
このような構成とすることで、当該サーバを運用することにより、（４）と同様の効果が得られる。
【００４０】
（１３） 前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、（９）〜（１２）に記載のサーバ。
【００４１】
このような構成とすることで、当該サーバを運用することにより、（５）と同様の効果が得られる。
【００４２】
（１４） 前記タグの検索は、検索されるタグに対して所定の重み付けを行う、（９）〜（１３）に記載のサーバ。
【００４３】
このような構成とすることで、当該サーバを運用することにより、（６）と同様の効果が得られる。
【００４４】
（１５） 前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、（１４）に記載のサーバ。
【００４５】
このような構成とすることで、当該サーバを運用することにより、（７）と同様の効果が得られる。
【００４６】
（１６） 前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、（１５）に記載のサーバ。
【００４７】
このような構成とすることで、当該サーバを運用することにより、（８）と同様の効果が得られる。
【００４８】
（１７） 複数のユーザの端末と通信ネットワークを介して接続されたサーバにおいて、前記複数のユーザが作成するキャラクタデータを検索するプログラムであって、
前記サーバに、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを前記キャラクタデータに関連づけて格納するタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を実行させることを特徴とするプログラム。
【００４９】
このような構成とすることで、このプログラムを当該サーバ上で実行することにより、（１）と同様の効果が得られる。
【発明の効果】
【００５０】
本発明によれば、ユーザが、アバターを作成する場合、アイテム一覧表から試行錯誤的にアイテムを選択するのではなく、目的イメージにあったより効率的な作成方法を望むと考えられる。したがって、ユーザがアバターを作成するためには、ユーザのイメージに合うアイテムを多数のアイテムの中から効率的に検索できる。
【発明を実施するための最良の形態】
【００５１】
本発明に係る好適な実施形態の一例について、図面に基づいて以下に説明する。以下、キャラクタの代表例として、特にアバターを中心に説明するがキャラクタは同様な特徴を有するキャラクタデータであれば、特にアバターに限定されるものではない。アバターの代表的なものは画像データであるが、これに限られず、ＭＰＥＧ、ＦＬＡＳＨ（登録商標）等の動画データであってもよい。また、場合によってはＷＡＶ、ＭＰ３、３ＧＰ等の音声データを含んでもよい。
【００５２】
［システムの全体構成］
図１は、本発明の好適な実施形態の一例に係るコンピュータ・システム１の全体構成およびサーバ１０の機能構成を表すブロック図である。このシステム１では、一般的にサーバ１０とそのユーザの端末２０とが通信ネットワーク３０を介して接続される。ここで、サーバ１０の数には制限はなく、必要に応じて１または複数のサーバで構成してよい。また、サーバ１０は、必要に応じてＷｅｂサーバ、ＤＢサーバ、アプリケーションサーバを含んで構成してよく、１台のサーバで構成してもそれぞれ別のサーバで構成してもよい。
【００５３】
サーバ１０は、少なくともアバターとしての様々なキャラクタデータを管理するアバター管理装置として構成し、サーバ１０の記憶部２００は、アバターＤＢ２０１、アイテムＤＢ２０２、ユーザＤＢ２０５、タグＤＢ２２１を含んでいる。これらのＤＢは、複数のＤＢで構成しても一つのＤＢで構成してもよい。
【００５４】
サーバ１０の制御部１００は、サーバ１０全体を制御し、アバターＤＢ２０１からアバターテーブルを読出すアバターテーブル読出し部１２０、アイテムＤＢ２０２からアイテムテーブルを読出すアイテムテーブル読出し部１２１、ユーザの端末２０またはユーザＤＢ２０５からユーザが入力したタグを受信するタグ受信部１２２、そのタグをタグＤＢの各種テーブルに付加するタグ付加部１２３、この各種テーブルからタグを検索するタグ検索部１２４、および検索結果送信部１２５を備える。これらの各部の働きについての詳細は後述の説明により明らかにする。
【００５５】
［アバターテーブル］
図２は、本発明の好適な実施形態の一例に係るアバターＤＢ２０１を構成するアバターテーブルを示す図である。図に示すように、アバターテーブルは、ユーザＩＤ２０１１をキーとして、「顔」、「髪型」、「服装」、「靴」、といった分類に従ってアイテムＩＤ２０１２を記憶している。
【００５６】
例えば、図２では簡略化して示してあるが、ユーザＩＤ２０１１が「ＡＢＣ１２」のユーザに関しては、アバターテーブルは、「顔」について「Ｄ６７８」を、「髪型」について「Ｂ８９８」を、「服装」について「Ｃ１１２０」を、「靴」について「Ａ１７８」を、それぞれユーザＩＤ「ＡＢＣ１２」に関連づけて記憶している。
【００５７】
［アイテムテーブル］
図３は、本発明の好適な実施形態の一例に係るアイテムＤＢ２０２を構成するアイテムテーブルを示す図である。アイテムテーブルは、アイテムＩＤ２０１２をキーとして、アイテム実体データ２０２２、大分類２０２３ａ、小分類２０２３ｂ、属性１（２０２４ａ）、属性２（２０２４ｂ）、前記ユーザに選択された回数を利用数２０２５として記憶している。
【００５８】
例えば、アイテムＩＤ２０１２が「Ｃ１１２０」であるアイテムは、アイテム実体データ２０２２は「Ｓｕｉｔ１．ＧＩＦ」という画像データであり、大分類２０２３ａは「服装」で、小分類２０２３ｂは「スーツ」であり、属性１（２０２４ａ）は「春」、属性２（２０２４ｂ）は「グレー」、利用数２０２５は１，０００回あったことを読み取ることができる。
【００５９】
ここで、アイテム実体データ２０２２は上述の例では画像データであるが、これに限られず、ＭＰＥＧ、ＦＬＡＳＨ（登録商標）、３ＧＰ等の動画データであってもよいし、ＷＡＶ、ＭＰ３等の音声データであってもよい。本発明においては、最終的にユーザの端末２０に送信するアバターの一部を構成するデータとして取り扱うことが可能なものが全て含まれる。
【００６０】
また、既に述べたように、分類はツリー構造によって表現されてもよい。ここでは、「服装」が大分類で、「スーツ」が「服装」の下位の小分類である。更に下位の分類も存在し得る。このようなツリー構造は、図のように項目別にテーブルのエントリで定義してもよいし、あるいはアイテムＩＤによって識別されるようにしてもよい。例えば、「服装」のアイテムＩＤは、「Ａ」で始まるＩＤを付けるようにし、「服装」に含まれる下位分類であることを表現するために、「ボトムス」は「Ａ」の後に更に「Ｂ」を付加し「ＡＢ」で始まるＩＤを付けるようにしてもよい。
【００６１】
また、別の形態では、データベースの構築において、このアイテムテーブル自体をツリー構造にしてもよい。アイテムテーブルは、前述のサーバ１０の制御部１００のアイテムテーブル読出し部１２１によって読込まれ、タグによる検索を行うための基礎となるデータである。
【００６２】
図４は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する一つのテーブルであるアバタータグ・テーブルを示す図である。本テーブルは、システムに一つ存在するようにしても、ユーザ毎に別に存在するようにしてもよい。単一のユーザが複数のアバターをアルバムに保存することがあるからである。図４では、ユーザＩＤ「ＡＢＣ１２」に複数のアバターＩＤ４０として、「ＡＢＣ１２−１」、「ＡＢＣ１２−２」、「ＡＢＣ１２−３」、「ＡＢＣ１２−４」等が登録されている場合を示している。
【００６３】
また、本テーブルには、アバタータグ４１として、例えば、「日本風」、「チャイナ風」、「イタリア風」等、ユーザが指定した任意のアバタータグが格納されている（タグ名が何も付けられてないアバターＩＤのエントリにはブランクが格納される）。ここで、タグを付けるのはこのアバターを作成したユーザであっても、別のユーザであってもよい。一つのアバターに同じタグ名を別のユーザが付けた場合は、テーブルに同じタグ名を記憶するのではなく、特に図示していないが、タグ毎のカウント値のみを記憶する。こうすることでテーブルサイズを小さくすることができる。
【００６４】
図５は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルであるアイテムタグ・テーブルを示す図である。本テーブルには、システムが用意する全てのアイテムＩＤ５０がエントリとして含まれる。各エントリには、分類５１（複数の分類項目を含んでよい）、複数のユーザが付加した任意のアイテムタグ５２を含んでいる。例えば、アイテムＩＤ「Ｃ１１２０」は、「ドレス」に分類され、様々なユーザが付けたタグ名、「日本風」、「和式」、「Ｊａｐａｎ」などが格納されている（タグ名が何も付けられてないアイテムＩＤのエントリにはブランクが格納される）。このタグ名を付けるのはどのユーザであってもよい。一つのアイテムに同じタグ名を別のユーザが付けた場合は、テーブルに同じタグ名を記憶するのではなく、カウント値のみを記憶するのはアバタータグの場合と同様である。
【００６５】
なお、本テーブルには、システム側で一意に定めた、「アイテム名称」を含めてもよい。例えば、「和服花柄デザインＡ・提供者○○○」等である。また、ユーザが各アイテムに任意に付けるタグ名は任意であるので、アイテムのイメージから外れたタグが多数登録される可能性はあるが、一定期間使用も参照もされない「カウント数１」のタグは自動的に本テーブルから削除するようにしてもよい。
【００６６】
図６は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルである属性タグ・テーブルを示す図である。属性タグ・テーブルには、予めアイテム毎に（あるいは分類毎に）定められた属性名６０が存在する。例えば、「色」、「国柄」、「季節」、「柄」などである。この属性名６０に対して、システムがアイテム登録時に定めた属性値６１が存在する。例えば、前記の各属性名６０に対して、「赤」、「中国」、「春」、「花」などが対応する。この各属性値に対して、ユーザが任意の属性タグ６２を付加することができる。例えば、属性値「赤」に対して、「赤系」、「ＲＥＤ」、「レッド」、「真紅」などが付加されることが考えられる（タグ名が何も付けられてない属性名のエントリにはブランクが格納される）。
【００６７】
以上、図４〜図６で３種類のタグを格納するテーブルの一例を示した。どの種類のタグにおいても共通であるが、このようなタグを全てシステム側で用意するのは不可能であるし、その必要もない。ユーザがあるアバターやアイテム、およびその属性を「見て感じた」イメージをタグ名として付加してもらうほうが有用である。このようなタグは、後述するように検索に役立つものである。また、タグ名のカウントが多い順にならべて、アイテムの人気コンテストにも利用することもできる。
【００６８】
［メイン処理］
図７は、本発明の好適な実施形態の一例に係るメイン処理の流れを示すフローチャートである。まず、ステップＳ１１で、サーバ１０の制御部１００を構成するアバターテーブル読出し部１２０が、図２で説明したアバターテーブルを読出す。次に、ステップＳ１２で、アイテムテーブル読出し部１２１が、図３で説明したアイテムテーブルを読出す。更にステップＳ１３で、タグ受信部１２２が、ユーザが入力した任意の文字列からなるタグを受信する。このときユーザＤＢ２０５を参照してもよい。受信したタグが新たなタグでデータベースに付加するものである場合は（ステップＳ１４：Ｙｅｓ）、タグ付加部１２３によってタグが前述した必要なテーブルに付加される。受信したタグがタグをデータベースに付加するものでない場合は（ステップＳ１４：Ｎｏ）、直ちにタグ検索部１２４によって、そのタグをキーとして、アバター、アイテム、アイテム属性の各テーブルが検索される（ステップＳ１６）。なお、図ではステップＳ１５の後、通常は処理を終了するが、続けてステップＳ１６が処理されるようにしてもよい。
【００６９】
［タグの付加処理］
図８は、本発明の好適な実施形態の一例に係るタグの付加処理の流れを示すフローチャートである。まず、ステップＳ２１において、受信したタグの種類を識別する。タグの種類は、ユーザに明示的に指定させて識別してもよいし、指定がない場合は全てのタグの種類が指定されたものとしてもよい。タグの種類が、アバターである場合はステップＳ２２へ、アイテムである場合は、ステップＳ２３へ、属性である場合はステップＳ２４へ処理を渡し、それぞれに適したテーブルを選択する。次にそれぞれのテーブルをサーチし、受信したタグ名と同じタグ名が既に存在するかどうかを見つける（ステップＳ２５）。同じタグ名が存在する場合は（ステップＳ２５：Ｙｅｓ）、ステップＳ２６で、そのタグ名に対応するカウントを１増やして処理を終了する。同じタグ名が存在しない場合は（ステップＳ２５：Ｎｏ）、ステップＳ２７でテーブルがオーバフローしないかどうかを調べ、オーバフローしない場合は（ステップＳ２７：Ｎｏ）、そのタグ名を選択されたテーブルに加える（ステップＳ２８）。オーバフローした場合は（ステップＳ２７：Ｙｅｓ）、エラーメッセージを出力して処理を終了する（ステップＳ２９）。
【００７０】
［タグの検索処理］
図９は、本発明の好適な実施形態の一例に係るタグの検索処理の流れを示すフローチャートである。まず、ステップＳ３１において、受信したタグの種類を識別する。タグの種類は、ユーザに明示的に指定させて識別してもよいし、指定がない場合は全てのタグの種類が指定されたものとしてもよい。タグの種類が、アバターである場合はステップＳ３２へ、アイテムである場合は、ステップＳ３３へ、属性である場合はステップＳ３４へ処理を渡し、それぞれに適したテーブルを選択する。次にそれぞれのテーブルをサーチし、受信したタグ名と同じタグ名が存在するかどうかを見つける（ステップＳ３５）。同じタグ名が存在する場合は（ステップＳ３５：Ｙｅｓ）、ステップＳ３６で、そのタグ名に対応するアバターデータを検索結果に加える。同じタグ名が存在しない場合は（ステップＳ３５：Ｎｏ）、ステップＳ３７で、テーブル内の全てのタグに対して検索を終了するまでＳ３５、Ｓ３６の処理を繰り返す。最後にステップＳ３８で、検索結果をユーザの端末２０へ送信する。
【００７１】
［検索結果画面１］
図１０は、本発明の好適な実施形態の一例に係るアバタータグの検索結果を示す画面の一例である。符号７０で示されるエリアには、ユーザＩＤ「ＡＢＣ１２」のユーザが現在コーディネートしているアバターが表示されている。このユーザが検索すべきタグ名として符号７１で示される入力領域に、例えば、「チャイナ風」と入力すると、サーバ１０はこの文字列を受信し、同一または類似のタグ名を持つ公開されている全てのアバターのデータ（７３〜７７など）を表示する。また、同時に検索されたアバター数や、現在表示中のページ、ページの操作ボタンなどが表示される。この検索において、アバター全体のタグのみを検索してもよいが、アバターに含まれるアイテムのタグ名や属性のタグ名を参照してもよい。どの種類のタグを検索に用いるかは、８４〜８６のチェックボックスからユーザが指定できるようにするのが望ましい。また、このとき、既に述べたように、検索順序は、更にユーザが指定した重み付けに従い行ってもよい（図示せず）。
【００７２】
［検索結果画面２］
図１１は、本発明の好適な実施形態の一例に係るアイテムタグの検索結果を示す画面の一例である。あるユーザが現在コーディネートしているアバター（符号７０で示す）が表示されている点、検索すべきタグ名の入力領域７１、検索開始ボタン７２、結果表示エリア（７８、７９）とページ操作ボタン８０などは前図と同様である。異なるのは、検索対象がアバター全体ではなくアイテム全体である点である。また、別の異なる点は、リストボックス８１に、検索すべきアイテムの分類を指定するようにした点である。例えば、全アイテムを検索対象とするか、特定の分類項目、例えば、「顔」とか「髪型」だけを検索対象とすることができる。検索されたアイテムは表８２のような形式でアイテム毎に表示される。ユーザは、好みのアイテムが検索結果の中に見つかった場合、直ちに各アイテムの欄にある試着ボタンを押して自分のイメージに近いコーディネートを素早く行うことができる。コーディネートしたアバターはアルバム保存ボタン８３を押下することによって保存することができる。
【００７３】
［検索結果画面３］
図１２は、本発明の好適な実施形態の一例に係る属性タグの検索結果を示す画面の一例である。この図では、特に重要でない表示エリアや操作ボタン（検索ボタン９８以外）は省略してある。ここでは、図の左側に示すユーザＩＤ「ＡＢＣ１２」さん（現在コーディネート中のアバターは符号９０）が、アバタータグ９２に「湘南ギャル」を入力し、アイテムタグ９３に「水着セパレーツ」を入力して検索したが、最初は何も検索されなかったとする。そこでＡＢＣ１２さんは、色属性９４に「赤」と入力した。色違いの水着で同じイメージのアバターがないか検索しようとしたのである。その結果、ユーザＩＤ「ＣＦＧ３０」さんのアバター９１が表示された。これは、ＣＦＧ３０さんが入力したアバタータグ９５「ミーちゃん」が検索用語としては適当でなく、かつアイテムタグ９６にも何も入力されていなかったために検索エンジンによって同一語としても類義語としても検出できなかったためである。しかし、ＡＢＣ１２さんが入力した水着の色属性９４「赤」とアイテムタグ９３の「水着セパレーツ」が、たまたまＣＦＧ３０さんが入力していた「赤セパレーツ」にヒットしてＡＢＣ１２さんの目的とするイメージのアバターを検出できたのである。この例は、タグの分類を超えて検索を行わせたものであるが、場合によっては、ユーザの指定によりタグの分類内で検索を限定させるようにしてもよい。
【００７４】
このようにタグ付けは、効率的な検索に便利な機能であるが、アバターの検索にこれを応用した場合、タグは任意の文字列であるがゆえに、ユーザが視覚的にイメージしたタグとして付けた名称が必ずしも一般的なイメージにフィットしたものとは限らないし検索に適した用語でない場合も多い。また、アバターには、画像のような視覚によって認識可能なもの以外にも、今後は音声など聴覚を利用したものも増加してくると予想される。音声の場合には、例えば、アイテムタグとして「挨拶」に対して、アイテム属性として「女性の声」、「子供の声」、「日本語」、「朝」、「おやすみ」などのような文字列をタグとして利用することが考えられる。音声を含んだアバターのような場合、単にアバター全体や、アイテム全体だけのタグでなく上記のような属性タグを用いることがあり得る。このようにアイテムの属性というタグを利用することによって、単に画像を中心としたアバターの利用だけでなく、動画や音声を含むアバターの利用においても更に検索の精度を高めることができる可能性がある。
【００７５】
［サーバのハードウェア構成］
図１３は、本発明の好適な実施形態の一例に係るサーバ１０のハードウェア構成の一例を示す図である。サーバ１０は、制御部１００を構成するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０（マルチプロセッサ構成ではＣＰＵ１０１２など複数のＣＰＵが追加されてもよい）、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、ＵＳＢポート１０９０、Ｉ／Ｏコントローラ１０７０、ならびにキーボードおよびマウス１１００等の入力手段や表示装置１０２２を備える。
【００７６】
Ｉ／Ｏコントローラ１０７０には、テープドライブ１０７２、ハードディスク１０７４、光ディスクドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。
【００７７】
ＢＩＯＳ１０６０は、サーバ１０の起動時にＣＰＵ１０１０が実行するブートプログラムや、サーバ１０のハードウェアに依存するプログラム等を格納する。
【００７８】
記憶部２００を構成するハードディスク１０７４は、サーバ１０がサーバとして機能するための各種プログラムおよび本発明の機能を実行するプログラムを記憶しており、更に必要に応じて各種データベースを構成可能である。
【００７９】
光ディスクドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この場合は各ドライブに対応した光ディスク１０７７を使用する。光ディスク１０７７から光ディスクドライブ１０７６によりプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハードディスク１０７４に提供することもできる。また、同様にテープドライブ１０７２に対応したテープメディア１０７１を主としてバックアップのために使用することもできる。
【００８０】
サーバ１０に提供されるプログラムは、ハードディスク１０７４、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて提供される。このプログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、サーバ１０にインストールされ実行されてもよい。
【００８１】
前述のプログラムは、内部または外部の記憶媒体に格納されてもよい。ここで、記憶部２００を構成する記憶媒体としては、ハードディスク１０７４、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープメディア１０７１を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハードディスク１０７４または光ディスクライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してプログラムをサーバ１０に提供してもよい。
【００８２】
ここで、表示装置１０２２は、サーバ管理者にデータの入力を受け付ける画面を表示したり、サーバ１０による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。
【００８３】
ここで、入力手段は、サーバ管理者による入力の受付を行うものであり、キーボードおよびマウス１１００等により構成してよい。
【００８４】
また、通信Ｉ／Ｆ１０４０は、サーバ１０を専用ネットワークまたは公共ネットワークを介して端末と接続できるようにするためのネットワーク・アダプタである。通信Ｉ／Ｆ１０４０は、モデム、ケーブル・モデムおよびイーサネット（登録商標）・アダプタを含んでよい。
【００８５】
以上の例は、サーバ１０について主に説明したが、コンピュータに、プログラムをインストールして、そのコンピュータをサーバ装置として動作させることにより上記で説明した機能を実現することもできる。したがって、本発明において一実施形態として説明したサーバにより実現される機能は、上述の方法を当該コンピュータにより実行することにより、あるいは、上述のプログラムを当該コンピュータに導入して実行することによっても実現可能である。
【００８６】
［端末のハードウェア構成］
端末２０も、上述のサーバ１０と同様な構成を持つ。また、上述の例ではいわゆるコンピュータで実現した例について説明したが、更に、本発明の原理が適用可能である限り、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ａｓｓｉｓｔａｎｔ）、ゲーム機等の様々な端末で実現してよい。
【００８７】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。
【図面の簡単な説明】
【００８８】
【図１】図１は、本発明の好適な実施形態の一例に係るコンピュータ・システム１の全体構成およびサーバ１０の機能構成を表すブロック図である。
【図２】本発明の好適な実施形態の一例に係るアバターＤＢ２０１を構成するアバターテーブルを示す図である。
【図３】本発明の好適な実施形態の一例に係るアイテムＤＢ２０２を構成するアイテムテーブルを示す図である。
【図４】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する一つのテーブルであるアバタータグ・テーブルを示す図である。
【図５】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルであるアイテムタグ・テーブルを示す図である。
【図６】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルである属性タグ・テーブルを示す図である。
【図７】本発明の好適な実施形態の一例に係るメイン処理の流れを示すフローチャートである。
【図８】本発明の好適な実施形態の一例に係るタグの付加処理の流れを示すフローチャートである。
【図９】本発明の好適な実施形態の一例に係るタグの検索処理の流れを示すフローチャートである。
【図１０】本発明の好適な実施形態の一例に係るアバタータグの検索結果を示す画面の一例である。
【図１１】本発明の好適な実施形態の一例に係るアイテムタグの検索結果を示す画面の一例である。
【図１２】本発明の好適な実施形態の一例に係る属性タグの検索結果を示す画面の一例である。
【図１３】本発明の好適な実施形態の一例に係るサーバ１０のハードウェア構成の一例を示す図である。
【符号の説明】
【００８９】
１ システム
１０ サーバ
２０ 端末
３０ 通信ネットワーク
１００ 制御部
１２０ アバターテーブル読出し部
１２１ アイテムテーブル読出し部
１２２ タグ受信部
１２３ タグ付加部
１２４ タグ検索部
１２５ 検索結果送信部
２００ 記憶部
２０１ アバターＤＢ
２０２ アイテムＤＢ
２０５ ユーザＤＢ
２２１ タグＤＢ
【技術分野】
【０００１】
本発明は、キャラクタデータにタギングして検索する方法、検索サーバに関する。特に、通信ネットワークに接続された端末から入力したユーザのキャラクタデータにタグ付けをし、それらのデータを検索する方法、検索サーバおよびプログラムに関する。
【背景技術】
【０００２】
インターネットの社会への普及に伴い、ネットワーク上で情報を閲覧したり、検索したり、あるいは商品を購入したり、といった受身のユーザのみならず、ユーザ自らが情報の発信者としてＷｅｂ上で擬似的な日記（いわゆるブログ）を公開したり、嗜好の一致する者同士でコミュニティを構成したり、といった積極的な行動をとるユーザが急速に増加している。
【０００３】
特に、ブログがこの数年で急速に普及した背景には、インターネットの初心者でも簡単にホームページに文章や写真を登録して発信できるブログエディターの果たした貢献が大きいものと考えられる。
【０００４】
そして、こうしたブログの社会への普及は、単に通信ネットワークに接続できる端末によって情報を閲覧していた時代には考えられなかったネットワーク上の社会（いわゆるネットワークコミュニティ）が現実の社会とは別にもう一つ出現し、急速に発展しつつあることを示している。
【０００５】
こうした状況において、ネットワーク上でユーザ自身を表すシンボルとして、「アバター」を活用するユーザが増加している。「分身」を意味するアバターは、具体的には画像データ、動画データ、音声データ等で表現されたいわゆるキャラクタであるが、現実の社会とは別に存在するネットワークコミュニティにおいて自分自身を表現し、他のユーザと対話し、共感し、議論し、同好の友人関係を広げる、といった様々な活動において、擬似的な行動主体としてその存在意義を高めている。
【０００６】
具体的には、例えば、ブログを公表する際に、アバターを画面の中で活用することにより、ユーザの書き込みによる文書とは別にユーザ自身をキャラクタデータにより直感的に表現することができるので、それを見る人にあたかもネットワーク上に自分の分身が存在するかのような感覚を抱かせ、ネットワークコミュニティにおけるコミュニケーションを強力にサポートすることができる。
【０００７】
実際に、このアバターの髪型、服装、アクセサリ、小物、背景などのアイテムをコーディネートすること自体がネットワークコミュニティにおいてユーザ自身のセンスや嗜好をアピールするために重要な活動の一つとなっている。このため、ユーザはこのようなアイテムを有償で購入したり、友人にプレゼントしたりしており、アバターのコーディネートは経済活動の対象ともなっている。
【０００８】
したがって、現実社会において洋服を購入したり、アクセサリや小物をコーディネートしたりすることと同様に、アバターのコーディネート活動はネットワーク上でユーザの嗜好を判断したり、ネットワークコミュニティにおける流行や変化を捉えたりする上で重要な分析対象ともなっている。
【０００９】
こうした状況において、通常は、ユーザが予め用意されたアイテムの中から自由に選択することにより、好みのアバターを生成するという方法がとられるが、アバター管理装置（サーバ）によって自動的にアバターを生成・更新する方法も提案されている。
【００１０】
例えば、特許文献１には、ユーザに心理テストを実行させることにより当該ユーザの属性を決定し、決定された属性のアクセサリ（アイテム）画像を用いて基本画像に対して変更を行い、アバター画像を生成する方法が開示されている。
【特許文献１】特開２００５−３３２０９１号公報
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、こうした特許文献１の技術では、アバターを生成・更新する画像作成のための技術的手法については開示されているものの、ユーザ自身が目的とするイメージに合ったアバターを生成しようとした場合に、それをサポートするような方法については開示されていない。通常、ユーザは、自分が作成しようとするアバターを構成するイメージに合ったアイテムを予めシステムで用意されたアイテム一覧表から選択する。しかしこのような方法では、アイテムの数が増えていくにしたがってユーザの選択作業は大きな負荷となる。ユーザは、自分自身の分身となるアバターを作成する場合、アイテム一覧表から試行錯誤的にアイテムを選択するのではなく、目的イメージにあったより効率的な作成方法を望むと考えられる。したがって、ユーザがキャラクタデータを作成するためには、ユーザのイメージに合うアイテムを多数のアイテムの中から効率的に検索できるような方法を提供することが望ましい。
【００１２】
本発明は、上記課題を解決し、ユーザがキャラクタデータを作成する際に、目的とするキャラクタのイメージにあったアイテムを簡単に検索できるようにする方法を提供することを目的とする。また、一致するキャラクタを容易に検索する方法も提供する。
【課題を解決するための手段】
【００１３】
上記目的のため、具体的には、以下のようなものを提供する。
【００１４】
（１） 複数のユーザの端末と通信ネットワークを介して接続されたサーバが、前記複数のユーザが作成するキャラクタデータを検索する方法であって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを、前記キャラクタデータと関連づけてタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を含むことを特徴とする方法。
【００１５】
このような構成とすることで、キャラクタデータ（例えば、アバターおよびその構成要素であるアイテムに関連するデータ）に対して、複数のユーザが入力した任意の文字列からなる複数のタグを受信し、そのタグを、前記キャラクタデータと関連づけて格納するタグ・テーブル（例えば、後述のアバタータグ・テーブル、アイテムタグ・テーブル、属性タグ・テーブルなど）に記憶し、タグを検索することでユーザの要求に応じたキャラクタデータ（例えば、アバター全体、アバターを構成するアイテム、そのアイテムの属性）を検索し、検索したそれぞれの結果を前記ユーザの端末に送信することができ、検索の精度や柔軟性を高める、という作用効果を奏する。
【００１６】
ここでキャラクタデータとは、例えば、キャラクタをアバターとした場合、アバターそのもの、アバターを構成するアイテム（例えば、「顔」、「服装」、「履物」、「ペット」、「背景」など）、そのアイテムの属性（「色」、「模様」、「材質」、「季節感」、「国柄」、「大きさ」などアイテムによって様々なものが考えられる）のそれぞれをコンピュータ上で表現するためのデータの集まりを示すものとする。ここでタグはアバターやアイテムの作成者に限られず、このシステムのユーザ全てが任意の文字列からなるタグを付けることができる。
【００１７】
したがって、このような構成では一つのキャラクタデータに複数のタグが付けられることになるが、ユーザ数が多くなればなるほどキャラクタを特徴付けるタグが自然と生成されると考えられ、逆に検索に役立たないタグは自然淘汰され得ると考えられる。このように、様々な要素からなるキャラクタデータをその要素または全体にユーザが任意に入力したタグを付加することによって、検索の効率（ヒット率）を高めることができる。
【００１８】
（２）前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、（１）に記載の方法。
【００１９】
このような構成とすることで、ユーザが作成したキャラクタ全体に対してタグを付加し、キャラクタ全体として検索することができる。これは最も単純なタグ付けであり、キャラクタ全体のイメージを重視する検索の場合などにこのタグを用いることができる。
【００２０】
（３）前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、（１）または（２）に記載の方法。
【００２１】
このような構成とすることで、キャラクタを構成する様々なアイテムをタグによって検索することができる。つまり、そのタグが付けられた全てのアイテムを検索することができる。例えば、タグに「中華風」、「イタリア風」などの用語を用いて、「中華風」、「イタリア風」などのイメージを持つアイテムをその分類項目（アイテムをその種類で分類する項目）に関わらずに網羅的に検索することができる。
【００２２】
（４）前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、（１）〜（３）に記載の方法。
【００２３】
このような構成とすることで、キャラクタを構成する個々のアイテムそのものだけでなく、各アイテムが持つ各種の属性（例えばアイテムが服装の場合は、「色」、「季節」、「国柄」など）にタグ付けし更に細かく検索することで、その属性タグによって検索の精度を高めることができる。このような属性による検索は、アバター全体やアイテム個々のタグによる検索だけでは不十分な場合に有用である。例えば、アバター全体のタグ（アバタータグ）を「湘南ギャル」とし、水着のアイテムのタグ（アイテムタグ）を「セパレーツ」に、それぞれタグ付けされている場合、この２つのタグに加えて水着アイテムの一つの属性として「色」について更に「パステルカラー」のようなタグを付加する。これによって単に色を「水色」とか「ピンク」とタグ付けするよりもよりイメージに近いタグを付加できる。
【００２４】
（５） 前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、（１）〜（４）に記載の方法。
【００２５】
このような構成とすることで、ユーザが検索したいタグと文字列が完全に一致しなくとも類義語辞書などを用いて類似のタグを検索できる。例えば、「赤」、「赤色」、「レッド」、「Ｒｅｄ」などは、類義語であるが、同一タグとみなしたほうがより目的とする検索ができる。
【００２６】
（６）前記タグの検索は、検索されるタグに対して所定の重み付けを行う、（１）〜（５）に記載の方法。
【００２７】
このような構成とすることで、（２）〜（４）で述べたタグの３つの種類に対して検索の際の重み付けを指定することができる。この重み付け順位はユーザに指定させるようにすることが望ましい。例えば、同じ「チャイナ風」でも全体イメージを重視したければ、アバター全体に対する重み付けを上げておき、逆に、小物のイメージを重視したければ、アイテムに対する重み付けを上げておく。検索結果に対してこの重み付け順位を加味してその順位の高い順に検索結果を表示するようにしてもよい。あるいは、重み付け順位の高い順に検索を行ったり、重み付けの最も高いタグの種類にのみ検索を行うようにしてもよい。
【００２８】
（７） 前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、（６）に記載の方法。
【００２９】
このような構成とすることで、（６）に述べた重み付け方法を更にアイテムの分類項目の構造に従って行うことができる。通常、アイテムは、「顔」、「服装」、「履物」、「持ち物」、「ペット」、「背景」などの大分類にまず分類され、それぞれの大分類毎に更に中分類、小分類に項目分けされる。例えば、大分類が「服装」の場合、中分類は、「トップス」、「ボトムス」などに分類され、更に「ボトムス」は、「ズボン」、「スカート」などに小分類される。このようにアイテムの分類項目は、一般的にはツリー構造をなしている。通常は、重み付けを固定付けとしてもよいが、ユーザの指定により、どの分類を重視するかで検索の効率を高めることができる。また、この所定の重み付けは、ツリー構造で定義されたアイテムの分類項目の上位項目からに下位項目の順に従って重み付けを行うようにすること（重み付けの順を大分類、中分類、小分類以下とする）により広い分類項目から順に検索することができるので、一般的には検索効率を高めることができる。
【００３０】
（８） 前記所定の重み付けは、前記ユーザから指定されたアイテムの分類項目に基づいて行う、（７）に記載の方法。
【００３１】
このような構成とすることで、ユーザは予め定義されたアイテムの分類項目対して検索の対象とする範囲を指定することができる。例えば、あるタグに関して検索対象を「服装」としたり、より狭い範囲にしたければ「上着」とすることができる。
【００３２】
（９） 複数のユーザの端末と通信ネットワークを介して接続され、前記複数のユーザが作成するキャラクタデータを検索するサーバであって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するタグ受信部と、
前記受信したタグを、前記キャラクタデータと関連づけてタグ・テーブルに記憶するタグ付加部と、
ユーザの端末の要求に応じて前記タグが付加されたキャラクタデータを検索するタグ検索部と、
前記検索した結果を送信する検索結果送信部と、
を備えることを特徴とするサーバ。
【００３３】
このような構成とすることで、当該サーバを運用することにより、（１）と同様の効果が得られる。
【００３４】
（１０）前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、（９）に記載のサーバ。
【００３５】
このような構成とすることで、当該サーバを運用することにより、（２）と同様の効果が得られる。
【００３６】
（１１） 前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、（９）または（１０）に記載のサーバ。
【００３７】
このような構成とすることで、当該サーバを運用することにより、（３）と同様の効果が得られる。
【００３８】
（１２） 前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、（９）〜（１１）に記載のサーバ。
【００３９】
このような構成とすることで、当該サーバを運用することにより、（４）と同様の効果が得られる。
【００４０】
（１３） 前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、（９）〜（１２）に記載のサーバ。
【００４１】
このような構成とすることで、当該サーバを運用することにより、（５）と同様の効果が得られる。
【００４２】
（１４） 前記タグの検索は、検索されるタグに対して所定の重み付けを行う、（９）〜（１３）に記載のサーバ。
【００４３】
このような構成とすることで、当該サーバを運用することにより、（６）と同様の効果が得られる。
【００４４】
（１５） 前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、（１４）に記載のサーバ。
【００４５】
このような構成とすることで、当該サーバを運用することにより、（７）と同様の効果が得られる。
【００４６】
（１６） 前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、（１５）に記載のサーバ。
【００４７】
このような構成とすることで、当該サーバを運用することにより、（８）と同様の効果が得られる。
【００４８】
（１７） 複数のユーザの端末と通信ネットワークを介して接続されたサーバにおいて、前記複数のユーザが作成するキャラクタデータを検索するプログラムであって、
前記サーバに、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを前記キャラクタデータに関連づけて格納するタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を実行させることを特徴とするプログラム。
【００４９】
このような構成とすることで、このプログラムを当該サーバ上で実行することにより、（１）と同様の効果が得られる。
【発明の効果】
【００５０】
本発明によれば、ユーザが、アバターを作成する場合、アイテム一覧表から試行錯誤的にアイテムを選択するのではなく、目的イメージにあったより効率的な作成方法を望むと考えられる。したがって、ユーザがアバターを作成するためには、ユーザのイメージに合うアイテムを多数のアイテムの中から効率的に検索できる。
【発明を実施するための最良の形態】
【００５１】
本発明に係る好適な実施形態の一例について、図面に基づいて以下に説明する。以下、キャラクタの代表例として、特にアバターを中心に説明するがキャラクタは同様な特徴を有するキャラクタデータであれば、特にアバターに限定されるものではない。アバターの代表的なものは画像データであるが、これに限られず、ＭＰＥＧ、ＦＬＡＳＨ（登録商標）等の動画データであってもよい。また、場合によってはＷＡＶ、ＭＰ３、３ＧＰ等の音声データを含んでもよい。
【００５２】
［システムの全体構成］
図１は、本発明の好適な実施形態の一例に係るコンピュータ・システム１の全体構成およびサーバ１０の機能構成を表すブロック図である。このシステム１では、一般的にサーバ１０とそのユーザの端末２０とが通信ネットワーク３０を介して接続される。ここで、サーバ１０の数には制限はなく、必要に応じて１または複数のサーバで構成してよい。また、サーバ１０は、必要に応じてＷｅｂサーバ、ＤＢサーバ、アプリケーションサーバを含んで構成してよく、１台のサーバで構成してもそれぞれ別のサーバで構成してもよい。
【００５３】
サーバ１０は、少なくともアバターとしての様々なキャラクタデータを管理するアバター管理装置として構成し、サーバ１０の記憶部２００は、アバターＤＢ２０１、アイテムＤＢ２０２、ユーザＤＢ２０５、タグＤＢ２２１を含んでいる。これらのＤＢは、複数のＤＢで構成しても一つのＤＢで構成してもよい。
【００５４】
サーバ１０の制御部１００は、サーバ１０全体を制御し、アバターＤＢ２０１からアバターテーブルを読出すアバターテーブル読出し部１２０、アイテムＤＢ２０２からアイテムテーブルを読出すアイテムテーブル読出し部１２１、ユーザの端末２０またはユーザＤＢ２０５からユーザが入力したタグを受信するタグ受信部１２２、そのタグをタグＤＢの各種テーブルに付加するタグ付加部１２３、この各種テーブルからタグを検索するタグ検索部１２４、および検索結果送信部１２５を備える。これらの各部の働きについての詳細は後述の説明により明らかにする。
【００５５】
［アバターテーブル］
図２は、本発明の好適な実施形態の一例に係るアバターＤＢ２０１を構成するアバターテーブルを示す図である。図に示すように、アバターテーブルは、ユーザＩＤ２０１１をキーとして、「顔」、「髪型」、「服装」、「靴」、といった分類に従ってアイテムＩＤ２０１２を記憶している。
【００５６】
例えば、図２では簡略化して示してあるが、ユーザＩＤ２０１１が「ＡＢＣ１２」のユーザに関しては、アバターテーブルは、「顔」について「Ｄ６７８」を、「髪型」について「Ｂ８９８」を、「服装」について「Ｃ１１２０」を、「靴」について「Ａ１７８」を、それぞれユーザＩＤ「ＡＢＣ１２」に関連づけて記憶している。
【００５７】
［アイテムテーブル］
図３は、本発明の好適な実施形態の一例に係るアイテムＤＢ２０２を構成するアイテムテーブルを示す図である。アイテムテーブルは、アイテムＩＤ２０１２をキーとして、アイテム実体データ２０２２、大分類２０２３ａ、小分類２０２３ｂ、属性１（２０２４ａ）、属性２（２０２４ｂ）、前記ユーザに選択された回数を利用数２０２５として記憶している。
【００５８】
例えば、アイテムＩＤ２０１２が「Ｃ１１２０」であるアイテムは、アイテム実体データ２０２２は「Ｓｕｉｔ１．ＧＩＦ」という画像データであり、大分類２０２３ａは「服装」で、小分類２０２３ｂは「スーツ」であり、属性１（２０２４ａ）は「春」、属性２（２０２４ｂ）は「グレー」、利用数２０２５は１，０００回あったことを読み取ることができる。
【００５９】
ここで、アイテム実体データ２０２２は上述の例では画像データであるが、これに限られず、ＭＰＥＧ、ＦＬＡＳＨ（登録商標）、３ＧＰ等の動画データであってもよいし、ＷＡＶ、ＭＰ３等の音声データであってもよい。本発明においては、最終的にユーザの端末２０に送信するアバターの一部を構成するデータとして取り扱うことが可能なものが全て含まれる。
【００６０】
また、既に述べたように、分類はツリー構造によって表現されてもよい。ここでは、「服装」が大分類で、「スーツ」が「服装」の下位の小分類である。更に下位の分類も存在し得る。このようなツリー構造は、図のように項目別にテーブルのエントリで定義してもよいし、あるいはアイテムＩＤによって識別されるようにしてもよい。例えば、「服装」のアイテムＩＤは、「Ａ」で始まるＩＤを付けるようにし、「服装」に含まれる下位分類であることを表現するために、「ボトムス」は「Ａ」の後に更に「Ｂ」を付加し「ＡＢ」で始まるＩＤを付けるようにしてもよい。
【００６１】
また、別の形態では、データベースの構築において、このアイテムテーブル自体をツリー構造にしてもよい。アイテムテーブルは、前述のサーバ１０の制御部１００のアイテムテーブル読出し部１２１によって読込まれ、タグによる検索を行うための基礎となるデータである。
【００６２】
図４は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する一つのテーブルであるアバタータグ・テーブルを示す図である。本テーブルは、システムに一つ存在するようにしても、ユーザ毎に別に存在するようにしてもよい。単一のユーザが複数のアバターをアルバムに保存することがあるからである。図４では、ユーザＩＤ「ＡＢＣ１２」に複数のアバターＩＤ４０として、「ＡＢＣ１２−１」、「ＡＢＣ１２−２」、「ＡＢＣ１２−３」、「ＡＢＣ１２−４」等が登録されている場合を示している。
【００６３】
また、本テーブルには、アバタータグ４１として、例えば、「日本風」、「チャイナ風」、「イタリア風」等、ユーザが指定した任意のアバタータグが格納されている（タグ名が何も付けられてないアバターＩＤのエントリにはブランクが格納される）。ここで、タグを付けるのはこのアバターを作成したユーザであっても、別のユーザであってもよい。一つのアバターに同じタグ名を別のユーザが付けた場合は、テーブルに同じタグ名を記憶するのではなく、特に図示していないが、タグ毎のカウント値のみを記憶する。こうすることでテーブルサイズを小さくすることができる。
【００６４】
図５は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルであるアイテムタグ・テーブルを示す図である。本テーブルには、システムが用意する全てのアイテムＩＤ５０がエントリとして含まれる。各エントリには、分類５１（複数の分類項目を含んでよい）、複数のユーザが付加した任意のアイテムタグ５２を含んでいる。例えば、アイテムＩＤ「Ｃ１１２０」は、「ドレス」に分類され、様々なユーザが付けたタグ名、「日本風」、「和式」、「Ｊａｐａｎ」などが格納されている（タグ名が何も付けられてないアイテムＩＤのエントリにはブランクが格納される）。このタグ名を付けるのはどのユーザであってもよい。一つのアイテムに同じタグ名を別のユーザが付けた場合は、テーブルに同じタグ名を記憶するのではなく、カウント値のみを記憶するのはアバタータグの場合と同様である。
【００６５】
なお、本テーブルには、システム側で一意に定めた、「アイテム名称」を含めてもよい。例えば、「和服花柄デザインＡ・提供者○○○」等である。また、ユーザが各アイテムに任意に付けるタグ名は任意であるので、アイテムのイメージから外れたタグが多数登録される可能性はあるが、一定期間使用も参照もされない「カウント数１」のタグは自動的に本テーブルから削除するようにしてもよい。
【００６６】
図６は、本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルである属性タグ・テーブルを示す図である。属性タグ・テーブルには、予めアイテム毎に（あるいは分類毎に）定められた属性名６０が存在する。例えば、「色」、「国柄」、「季節」、「柄」などである。この属性名６０に対して、システムがアイテム登録時に定めた属性値６１が存在する。例えば、前記の各属性名６０に対して、「赤」、「中国」、「春」、「花」などが対応する。この各属性値に対して、ユーザが任意の属性タグ６２を付加することができる。例えば、属性値「赤」に対して、「赤系」、「ＲＥＤ」、「レッド」、「真紅」などが付加されることが考えられる（タグ名が何も付けられてない属性名のエントリにはブランクが格納される）。
【００６７】
以上、図４〜図６で３種類のタグを格納するテーブルの一例を示した。どの種類のタグにおいても共通であるが、このようなタグを全てシステム側で用意するのは不可能であるし、その必要もない。ユーザがあるアバターやアイテム、およびその属性を「見て感じた」イメージをタグ名として付加してもらうほうが有用である。このようなタグは、後述するように検索に役立つものである。また、タグ名のカウントが多い順にならべて、アイテムの人気コンテストにも利用することもできる。
【００６８】
［メイン処理］
図７は、本発明の好適な実施形態の一例に係るメイン処理の流れを示すフローチャートである。まず、ステップＳ１１で、サーバ１０の制御部１００を構成するアバターテーブル読出し部１２０が、図２で説明したアバターテーブルを読出す。次に、ステップＳ１２で、アイテムテーブル読出し部１２１が、図３で説明したアイテムテーブルを読出す。更にステップＳ１３で、タグ受信部１２２が、ユーザが入力した任意の文字列からなるタグを受信する。このときユーザＤＢ２０５を参照してもよい。受信したタグが新たなタグでデータベースに付加するものである場合は（ステップＳ１４：Ｙｅｓ）、タグ付加部１２３によってタグが前述した必要なテーブルに付加される。受信したタグがタグをデータベースに付加するものでない場合は（ステップＳ１４：Ｎｏ）、直ちにタグ検索部１２４によって、そのタグをキーとして、アバター、アイテム、アイテム属性の各テーブルが検索される（ステップＳ１６）。なお、図ではステップＳ１５の後、通常は処理を終了するが、続けてステップＳ１６が処理されるようにしてもよい。
【００６９】
［タグの付加処理］
図８は、本発明の好適な実施形態の一例に係るタグの付加処理の流れを示すフローチャートである。まず、ステップＳ２１において、受信したタグの種類を識別する。タグの種類は、ユーザに明示的に指定させて識別してもよいし、指定がない場合は全てのタグの種類が指定されたものとしてもよい。タグの種類が、アバターである場合はステップＳ２２へ、アイテムである場合は、ステップＳ２３へ、属性である場合はステップＳ２４へ処理を渡し、それぞれに適したテーブルを選択する。次にそれぞれのテーブルをサーチし、受信したタグ名と同じタグ名が既に存在するかどうかを見つける（ステップＳ２５）。同じタグ名が存在する場合は（ステップＳ２５：Ｙｅｓ）、ステップＳ２６で、そのタグ名に対応するカウントを１増やして処理を終了する。同じタグ名が存在しない場合は（ステップＳ２５：Ｎｏ）、ステップＳ２７でテーブルがオーバフローしないかどうかを調べ、オーバフローしない場合は（ステップＳ２７：Ｎｏ）、そのタグ名を選択されたテーブルに加える（ステップＳ２８）。オーバフローした場合は（ステップＳ２７：Ｙｅｓ）、エラーメッセージを出力して処理を終了する（ステップＳ２９）。
【００７０】
［タグの検索処理］
図９は、本発明の好適な実施形態の一例に係るタグの検索処理の流れを示すフローチャートである。まず、ステップＳ３１において、受信したタグの種類を識別する。タグの種類は、ユーザに明示的に指定させて識別してもよいし、指定がない場合は全てのタグの種類が指定されたものとしてもよい。タグの種類が、アバターである場合はステップＳ３２へ、アイテムである場合は、ステップＳ３３へ、属性である場合はステップＳ３４へ処理を渡し、それぞれに適したテーブルを選択する。次にそれぞれのテーブルをサーチし、受信したタグ名と同じタグ名が存在するかどうかを見つける（ステップＳ３５）。同じタグ名が存在する場合は（ステップＳ３５：Ｙｅｓ）、ステップＳ３６で、そのタグ名に対応するアバターデータを検索結果に加える。同じタグ名が存在しない場合は（ステップＳ３５：Ｎｏ）、ステップＳ３７で、テーブル内の全てのタグに対して検索を終了するまでＳ３５、Ｓ３６の処理を繰り返す。最後にステップＳ３８で、検索結果をユーザの端末２０へ送信する。
【００７１】
［検索結果画面１］
図１０は、本発明の好適な実施形態の一例に係るアバタータグの検索結果を示す画面の一例である。符号７０で示されるエリアには、ユーザＩＤ「ＡＢＣ１２」のユーザが現在コーディネートしているアバターが表示されている。このユーザが検索すべきタグ名として符号７１で示される入力領域に、例えば、「チャイナ風」と入力すると、サーバ１０はこの文字列を受信し、同一または類似のタグ名を持つ公開されている全てのアバターのデータ（７３〜７７など）を表示する。また、同時に検索されたアバター数や、現在表示中のページ、ページの操作ボタンなどが表示される。この検索において、アバター全体のタグのみを検索してもよいが、アバターに含まれるアイテムのタグ名や属性のタグ名を参照してもよい。どの種類のタグを検索に用いるかは、８４〜８６のチェックボックスからユーザが指定できるようにするのが望ましい。また、このとき、既に述べたように、検索順序は、更にユーザが指定した重み付けに従い行ってもよい（図示せず）。
【００７２】
［検索結果画面２］
図１１は、本発明の好適な実施形態の一例に係るアイテムタグの検索結果を示す画面の一例である。あるユーザが現在コーディネートしているアバター（符号７０で示す）が表示されている点、検索すべきタグ名の入力領域７１、検索開始ボタン７２、結果表示エリア（７８、７９）とページ操作ボタン８０などは前図と同様である。異なるのは、検索対象がアバター全体ではなくアイテム全体である点である。また、別の異なる点は、リストボックス８１に、検索すべきアイテムの分類を指定するようにした点である。例えば、全アイテムを検索対象とするか、特定の分類項目、例えば、「顔」とか「髪型」だけを検索対象とすることができる。検索されたアイテムは表８２のような形式でアイテム毎に表示される。ユーザは、好みのアイテムが検索結果の中に見つかった場合、直ちに各アイテムの欄にある試着ボタンを押して自分のイメージに近いコーディネートを素早く行うことができる。コーディネートしたアバターはアルバム保存ボタン８３を押下することによって保存することができる。
【００７３】
［検索結果画面３］
図１２は、本発明の好適な実施形態の一例に係る属性タグの検索結果を示す画面の一例である。この図では、特に重要でない表示エリアや操作ボタン（検索ボタン９８以外）は省略してある。ここでは、図の左側に示すユーザＩＤ「ＡＢＣ１２」さん（現在コーディネート中のアバターは符号９０）が、アバタータグ９２に「湘南ギャル」を入力し、アイテムタグ９３に「水着セパレーツ」を入力して検索したが、最初は何も検索されなかったとする。そこでＡＢＣ１２さんは、色属性９４に「赤」と入力した。色違いの水着で同じイメージのアバターがないか検索しようとしたのである。その結果、ユーザＩＤ「ＣＦＧ３０」さんのアバター９１が表示された。これは、ＣＦＧ３０さんが入力したアバタータグ９５「ミーちゃん」が検索用語としては適当でなく、かつアイテムタグ９６にも何も入力されていなかったために検索エンジンによって同一語としても類義語としても検出できなかったためである。しかし、ＡＢＣ１２さんが入力した水着の色属性９４「赤」とアイテムタグ９３の「水着セパレーツ」が、たまたまＣＦＧ３０さんが入力していた「赤セパレーツ」にヒットしてＡＢＣ１２さんの目的とするイメージのアバターを検出できたのである。この例は、タグの分類を超えて検索を行わせたものであるが、場合によっては、ユーザの指定によりタグの分類内で検索を限定させるようにしてもよい。
【００７４】
このようにタグ付けは、効率的な検索に便利な機能であるが、アバターの検索にこれを応用した場合、タグは任意の文字列であるがゆえに、ユーザが視覚的にイメージしたタグとして付けた名称が必ずしも一般的なイメージにフィットしたものとは限らないし検索に適した用語でない場合も多い。また、アバターには、画像のような視覚によって認識可能なもの以外にも、今後は音声など聴覚を利用したものも増加してくると予想される。音声の場合には、例えば、アイテムタグとして「挨拶」に対して、アイテム属性として「女性の声」、「子供の声」、「日本語」、「朝」、「おやすみ」などのような文字列をタグとして利用することが考えられる。音声を含んだアバターのような場合、単にアバター全体や、アイテム全体だけのタグでなく上記のような属性タグを用いることがあり得る。このようにアイテムの属性というタグを利用することによって、単に画像を中心としたアバターの利用だけでなく、動画や音声を含むアバターの利用においても更に検索の精度を高めることができる可能性がある。
【００７５】
［サーバのハードウェア構成］
図１３は、本発明の好適な実施形態の一例に係るサーバ１０のハードウェア構成の一例を示す図である。サーバ１０は、制御部１００を構成するＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１０１０（マルチプロセッサ構成ではＣＰＵ１０１２など複数のＣＰＵが追加されてもよい）、バスライン１００５、通信Ｉ／Ｆ１０４０、メインメモリ１０５０、ＢＩＯＳ（Ｂａｓｉｃ Ｉｎｐｕｔ Ｏｕｔｐｕｔ Ｓｙｓｔｅｍ）１０６０、ＵＳＢポート１０９０、Ｉ／Ｏコントローラ１０７０、ならびにキーボードおよびマウス１１００等の入力手段や表示装置１０２２を備える。
【００７６】
Ｉ／Ｏコントローラ１０７０には、テープドライブ１０７２、ハードディスク１０７４、光ディスクドライブ１０７６、半導体メモリ１０７８、等の記憶手段を接続することができる。
【００７７】
ＢＩＯＳ１０６０は、サーバ１０の起動時にＣＰＵ１０１０が実行するブートプログラムや、サーバ１０のハードウェアに依存するプログラム等を格納する。
【００７８】
記憶部２００を構成するハードディスク１０７４は、サーバ１０がサーバとして機能するための各種プログラムおよび本発明の機能を実行するプログラムを記憶しており、更に必要に応じて各種データベースを構成可能である。
【００７９】
光ディスクドライブ１０７６としては、例えば、ＤＶＤ−ＲＯＭドライブ、ＣＤ−ＲＯＭドライブ、ＤＶＤ−ＲＡＭドライブ、ＣＤ−ＲＡＭドライブを使用することができる。この場合は各ドライブに対応した光ディスク１０７７を使用する。光ディスク１０７７から光ディスクドライブ１０７６によりプログラムまたはデータを読み取り、Ｉ／Ｏコントローラ１０７０を介してメインメモリ１０５０またはハードディスク１０７４に提供することもできる。また、同様にテープドライブ１０７２に対応したテープメディア１０７１を主としてバックアップのために使用することもできる。
【００８０】
サーバ１０に提供されるプログラムは、ハードディスク１０７４、光ディスク１０７７、またはメモリーカード等の記録媒体に格納されて提供される。このプログラムは、Ｉ／Ｏコントローラ１０７０を介して、記録媒体から読み出され、または通信Ｉ／Ｆ１０４０を介してダウンロードされることによって、サーバ１０にインストールされ実行されてもよい。
【００８１】
前述のプログラムは、内部または外部の記憶媒体に格納されてもよい。ここで、記憶部２００を構成する記憶媒体としては、ハードディスク１０７４、光ディスク１０７７、またはメモリーカードの他に、ＭＤ等の光磁気記録媒体、テープメディア１０７１を用いることができる。また、専用通信回線やインターネットに接続されたサーバシステムに設けたハードディスク１０７４または光ディスクライブラリ等の記憶装置を記録媒体として使用し、通信回線を介してプログラムをサーバ１０に提供してもよい。
【００８２】
ここで、表示装置１０２２は、サーバ管理者にデータの入力を受け付ける画面を表示したり、サーバ１０による演算処理結果の画面を表示したりするものであり、ブラウン管表示装置（ＣＲＴ）、液晶表示装置（ＬＣＤ）等のディスプレイ装置を含む。
【００８３】
ここで、入力手段は、サーバ管理者による入力の受付を行うものであり、キーボードおよびマウス１１００等により構成してよい。
【００８４】
また、通信Ｉ／Ｆ１０４０は、サーバ１０を専用ネットワークまたは公共ネットワークを介して端末と接続できるようにするためのネットワーク・アダプタである。通信Ｉ／Ｆ１０４０は、モデム、ケーブル・モデムおよびイーサネット（登録商標）・アダプタを含んでよい。
【００８５】
以上の例は、サーバ１０について主に説明したが、コンピュータに、プログラムをインストールして、そのコンピュータをサーバ装置として動作させることにより上記で説明した機能を実現することもできる。したがって、本発明において一実施形態として説明したサーバにより実現される機能は、上述の方法を当該コンピュータにより実行することにより、あるいは、上述のプログラムを当該コンピュータに導入して実行することによっても実現可能である。
【００８６】
［端末のハードウェア構成］
端末２０も、上述のサーバ１０と同様な構成を持つ。また、上述の例ではいわゆるコンピュータで実現した例について説明したが、更に、本発明の原理が適用可能である限り、携帯電話、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄａｔａ Ａｓｓｉｓｔａｎｔ）、ゲーム機等の様々な端末で実現してよい。
【００８７】
以上、本発明の実施形態について説明したが、本発明は上述した実施形態に限るものではない。また、本発明の実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本発明の実施例に記載されたものに限定されるものではない。
【図面の簡単な説明】
【００８８】
【図１】図１は、本発明の好適な実施形態の一例に係るコンピュータ・システム１の全体構成およびサーバ１０の機能構成を表すブロック図である。
【図２】本発明の好適な実施形態の一例に係るアバターＤＢ２０１を構成するアバターテーブルを示す図である。
【図３】本発明の好適な実施形態の一例に係るアイテムＤＢ２０２を構成するアイテムテーブルを示す図である。
【図４】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する一つのテーブルであるアバタータグ・テーブルを示す図である。
【図５】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルであるアイテムタグ・テーブルを示す図である。
【図６】本発明の好適な実施形態の一例に係るタグＤＢ２２１を構成する他の一つのテーブルである属性タグ・テーブルを示す図である。
【図７】本発明の好適な実施形態の一例に係るメイン処理の流れを示すフローチャートである。
【図８】本発明の好適な実施形態の一例に係るタグの付加処理の流れを示すフローチャートである。
【図９】本発明の好適な実施形態の一例に係るタグの検索処理の流れを示すフローチャートである。
【図１０】本発明の好適な実施形態の一例に係るアバタータグの検索結果を示す画面の一例である。
【図１１】本発明の好適な実施形態の一例に係るアイテムタグの検索結果を示す画面の一例である。
【図１２】本発明の好適な実施形態の一例に係る属性タグの検索結果を示す画面の一例である。
【図１３】本発明の好適な実施形態の一例に係るサーバ１０のハードウェア構成の一例を示す図である。
【符号の説明】
【００８９】
１ システム
１０ サーバ
２０ 端末
３０ 通信ネットワーク
１００ 制御部
１２０ アバターテーブル読出し部
１２１ アイテムテーブル読出し部
１２２ タグ受信部
１２３ タグ付加部
１２４ タグ検索部
１２５ 検索結果送信部
２００ 記憶部
２０１ アバターＤＢ
２０２ アイテムＤＢ
２０５ ユーザＤＢ
２２１ タグＤＢ
【特許請求の範囲】
【請求項１】
複数のユーザの端末と通信ネットワークを介して接続されたサーバが、前記複数のユーザが作成するキャラクタデータを検索する方法であって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを、前記キャラクタデータと関連づけてタグ・テ−ブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を含むことを特徴とする方法。
【請求項２】
前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、請求項１に記載の方法。
【請求項３】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、請求項１または請求項２に記載の方法。
【請求項４】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、請求項１乃至請求項３に記載の方法。
【請求項５】
前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、請求項１乃至請求項４に記載の方法。
【請求項６】
前記タグの検索は、検索されるタグに対して所定の重み付けを行う、請求項１乃至請求項５に記載の方法。
【請求項７】
前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、請求項６に記載の方法。
【請求項８】
前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、請求項７に記載の方法。
【請求項９】
複数のユーザの端末と通信ネットワークを介して接続され、前記複数のユーザが作成するキャラクタデータを検索するサーバであって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するタグ受信部と、
前記受信したタグを、前記キャラクタデータと関連づけてタグ・テ−ブルに記憶するタグ付加部と、
ユーザの端末の要求に応じて前記タグが付加されたキャラクタデータを検索するタグ検索部と、
前記検索した結果を送信する検索結果送信部と、
を備えることを特徴とするサーバ。
【請求項１０】
前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、請求項９に記載のサーバ。
【請求項１１】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、請求項９または請求項１０に記載のサーバ。
【請求項１２】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、請求項９乃至請求項１１に記載のサーバ。
【請求項１３】
前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、請求項９乃至請求項１２に記載のサーバ。
【請求項１４】
前記タグの検索は、検索されるタグに対して所定の重み付けを行う、請求項９乃至請求項１３に記載のサーバ。
【請求項１５】
前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、請求項１４に記載のサーバ。
【請求項１６】
前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、請求項１５に記載のサーバ。
【請求項１７】
複数のユーザの端末と通信ネットワークを介して接続されたサーバにおいて、前記複数のユーザが作成するキャラクタデータを検索するプログラムであって、
前記サーバに、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを前記キャラクタデータに関連づけて格納するタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を実行させることを特徴とするプログラム。
【請求項１】
複数のユーザの端末と通信ネットワークを介して接続されたサーバが、前記複数のユーザが作成するキャラクタデータを検索する方法であって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを、前記キャラクタデータと関連づけてタグ・テ−ブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を含むことを特徴とする方法。
【請求項２】
前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、請求項１に記載の方法。
【請求項３】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、請求項１または請求項２に記載の方法。
【請求項４】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、請求項１乃至請求項３に記載の方法。
【請求項５】
前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、請求項１乃至請求項４に記載の方法。
【請求項６】
前記タグの検索は、検索されるタグに対して所定の重み付けを行う、請求項１乃至請求項５に記載の方法。
【請求項７】
前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、請求項６に記載の方法。
【請求項８】
前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、請求項７に記載の方法。
【請求項９】
複数のユーザの端末と通信ネットワークを介して接続され、前記複数のユーザが作成するキャラクタデータを検索するサーバであって、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するタグ受信部と、
前記受信したタグを、前記キャラクタデータと関連づけてタグ・テ−ブルに記憶するタグ付加部と、
ユーザの端末の要求に応じて前記タグが付加されたキャラクタデータを検索するタグ検索部と、
前記検索した結果を送信する検索結果送信部と、
を備えることを特徴とするサーバ。
【請求項１０】
前記キャラクタデータに対する前記タグの付加は、ユーザＩＤに関連づけられたキャラクタに対して行う、請求項９に記載のサーバ。
【請求項１１】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムに対して行う、請求項９または請求項１０に記載のサーバ。
【請求項１２】
前記キャラクタデータに対する前記タグの付加は、前記キャラクタを構成するアイテムの各属性に対して行う、請求項９乃至請求項１１に記載のサーバ。
【請求項１３】
前記タグの検索は、前記ユーザが指定したタグと類似する類似タグについても検索対象とする、請求項９乃至請求項１２に記載のサーバ。
【請求項１４】
前記タグの検索は、検索されるタグに対して所定の重み付けを行う、請求項９乃至請求項１３に記載のサーバ。
【請求項１５】
前記所定の重み付けは、ツリー構造で定義されたアイテムの分類項目に基づいて行う、請求項１４に記載のサーバ。
【請求項１６】
前記所定の重み付けは、前記ユーザから指定された前記アイテムの分類項目に基づいて行う、請求項１５に記載のサーバ。
【請求項１７】
複数のユーザの端末と通信ネットワークを介して接続されたサーバにおいて、前記複数のユーザが作成するキャラクタデータを検索するプログラムであって、
前記サーバに、
前記キャラクタデータに対して前記複数のユーザが入力した任意の文字列からなる複数のタグを受信するステップと、
前記タグを前記キャラクタデータに関連づけて格納するタグ・テーブルに記憶するステップと、
前記タグを検索することでユーザの要求に応じたキャラクタデータを検索するステップと、
前記検索した結果を送信するステップと、
を実行させることを特徴とするプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００７−３２８７００（Ｐ２００７−３２８７００Ａ）
【公開日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願番号】特願２００６−１６１０９７（Ｐ２００６−１６１０９７）
【出願日】平成１８年６月９日（２００６．６．９）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
【公開日】平成１９年１２月２０日（２００７．１２．２０）
【国際特許分類】
【出願日】平成１８年６月９日（２００６．６．９）
【出願人】（５００２５７３００）ヤフー株式会社 (1,128)
【Ｆターム（参考）】
[ Back to top ]