(57)【要約】  ユーザ及びコンテンツの売り主の利便性をより向上させることを可能にする。互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置を提供する。
2016035424.tif 000002
【特許請求の範囲】
【請求項１】
互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、  共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、  を備える、情報処理装置。
【請求項２】
前記共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、前記コンテンツの販売戦略を決定する販売戦略決定部、を更に備え、  前記推薦部は、前記販売戦略決定部によって決定された販売戦略に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、  請求項１に記載の情報処理装置。
【請求項３】
前記コンテンツは、販売期間及び販売数の少なくともいずれかが限定されている定量商材であり、  前記販売戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝戦略を含む、  請求項２に記載の情報処理装置。
【請求項４】
前記宣伝戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝量、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝時期、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝を行うユーザの属性、及び前記販売期間及び前記販売数に応じた前記コンテンツの宣伝の費用対効果、の少なくともいずれかを含む、  請求項３に記載の情報処理装置。
【請求項５】
前記販売戦略決定部によって決定された販売戦略を前記コンテンツの売り主に提示するとともに、提示された前記販売戦略に基づいて前記売り主が前記推薦部による決定処理に用いられる販売戦略を指定可能なインターフェースを提供する、提示制御部、を更に備える、  請求項２に記載の情報処理装置。
【請求項６】
前記推薦部は、提示制御部によって提供されるインターフェースを介して前記コンテンツの売り主によって指定される販売戦略に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、  請求項５に記載の情報処理装置。
【請求項７】
前記推薦部は、ユーザのコンテンツ購入時の行動傾向を表す行動傾向情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、  請求項１に記載の情報処理装置。
【請求項８】
前記推薦部は、前記複数の管理システムのいずれかに登録されている会員を、コンテンツを推薦するユーザとして決定する、  請求項１に記載の情報処理装置。
【請求項９】
前記スキーマ変換部は、前記推薦部によって決定されたコンテンツについての共通化コンテンツメタ情報を、前記推薦部によって決定されたユーザが会員として登録されている管理システムにおいて販売可能なスキーマに変換する、  請求項８に記載の情報処理装置。
【請求項１０】
前記推薦部は、メディア上でのユーザの行動を表す行動履歴情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、  請求項１に記載の情報処理装置。
【請求項１１】
前記行動履歴情報は、Ｗｅｂサイトを閲覧した旨の情報、Ｗｅｂサイト上のリンクを選択した旨の情報、及びＷｅｂサイト上でのコンバージョンについての情報、の少なくともいずれかを含む、  請求項１０に記載の情報処理装置。
【請求項１２】
前記推薦部は、前記行動履歴情報が取得されたユーザであって、前記複数の管理システムのいずれかに登録されている会員でないユーザを、コンテンツを推薦するユーザとして決定する、  請求項１０又は１１に記載の情報処理装置。
【請求項１３】
前記コンテンツは、席数が限定されているイベントである、  請求項１〜１２のいずれか１項に記載の情報処理装置。
【請求項１４】
プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、  共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、  を含む、情報処理方法。
【請求項１５】
コンピュータのプロセッサに、  互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、  共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、  を実現させるためのプログラム。 
【発明の詳細な説明】
【技術分野】
【０００１】  本開示は、情報処理装置、情報処理方法及びプログラムに関する。
【背景技術】
【０００２】  一般的に、各種のコンテンツ（例えば、コンサート、演劇、映画等のイベント）をユーザに対して推薦する技術が開発されている。例えば、特許文献１には、ユーザが所持する移動通信端末から位置情報を受信し、イベントの開催場所から所定の範囲内にあり、かつ位置情報の取得日時がイベントの実行日時より前である移動通信端末に対して、当該イベントのイベント情報を配信する技術が開示されている。【０００３】  また、コンサート等の座席が存在するイベントでは、ユーザが、座席を選択して当該イベントのチケットを購入することが一般的に行われている。特許文献２には、イベントのチケットを電子化し、会場のゲートでのユーザの誘導を円滑に実施できるようにする技術が開示されている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００９−７１４９９号公報
【特許文献１】特開２００２−１９７２２４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】  ここで、興行主や主催者（以下、簡単のため、まとめて主催者と総称する。）が存在する興行イベント（例えば、コンサート、演劇、スポーツの試合、映画、講演会等）では、主催者ごとに独自のイベント管理システムやチケット販売システムを有している場合が多い。また、ユーザのチケットの購入履歴等の情報も主催者ごとに管理されることが一般的である。特許文献１、２に記載の技術では、このような、コンテンツが互いに異なる管理システムによって管理されている場合については十分に考慮されていなかった。【０００６】  上記事情に鑑みれば、ユーザに対してコンテンツを推薦するシステムや、ユーザに対してコンテンツを販売するシステムを、ユーザ及びコンテンツの売り主にとってより利便性の高いものに改良できる余地がある。そこで、本開示では、ユーザ及びコンテンツの売り主の利便性をより向上させることが可能な、新規かつ改良された情報処理装置、情報処理方法及びプログラムを提案する。
【課題を解決するための手段】
【０００７】  本開示によれば、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置が提供される。【０００８】  また、本開示によれば、プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、を含む、情報処理方法が提供される。【０００９】  また、本開示によれば、コンピュータのプロセッサに、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、を実現させるためのプログラム。【００１０】  本開示によれば、互いに異なる管理システムによって管理されるイベントメタ情報が、共通のスキーマに変換される。従って、各管理システムにおけるコンテンツの購入履歴情報を、共通のスキーマで総合的に扱うことが可能となる。よって、各管理システムにおけるコンテンツの購入履歴情報を総合的に用いて、推薦するコンテンツとユーザの組み合わせを決定することができるため、より適切な組み合わせが決定され、ユーザによる購入行動がより促進される。
【発明の効果】
【００１１】  以上説明したように本開示によれば、ユーザ及びコンテンツの売り主の利便性をより向上させることが可能となる。なお、上記の効果は必ずしも限定的なものではなく、上記の効果とともに、又は上記の効果に代えて、本明細書に示されたいずれかの効果、又は本明細書から把握され得る他の効果が奏されてもよい。
【図面の簡単な説明】
【００１２】
【図１】一般的なシステムの概要について説明するための説明図である。
【図２】本開示の第１の実施形態に係るシステムの概要について説明するための説明図である。
【図３】第１の実施形態に係るシステムの一構成例を示すブロック図である。
【図４】図３に示す推薦部の機能構成の一例を示す機能ブロック図である。
【図５】ユーザの行動傾向情報に基づく販売戦略の決定処理について説明するための説明図である。
【図６】第１の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。
【図７】主催者によって各種の情報が入力される情報入力画面の一表示例を示す図である。
【図８】各管理システムに予測エンジンが設けられる変形例に係るシステムの概要を示す図である。
【図９】一般的なターゲティング広告に係るシステムについて説明するための説明図である。
【図１０】第２の実施形態に係るシステムの概要について説明するための説明図である。
【図１１】第２の実施形態に係るシステムの一構成例を示すブロック図である。
【図１２】図１１に示す推薦部の機能構成の一例を示す機能ブロック図である。
【図１３】行動履歴情報の取得方法について説明するための説明図である。
【図１４】行動履歴情報の取得方法について説明するための説明図である。
【図１５】第２の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。
【図１６】第１及び第２の実施形態に係る情報処理装置のハードウェア構成の一例を示す機能ブロック図である。
【発明を実施するための形態】
【００１３】  以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００１４】  なお、説明は以下の順序で行うものとする。  １．一般的なシステムについて  ２．第１の実施形態    ２−１．システムの概要    ２−２．システムの構成    ２−３．情報処理方法    ２−４．表示例    ２−５．変形例  ３．第２の実施形態    ３−１．ターゲティング広告について    ３−２．システムの概要    ３−３．システムの構成    ３−４．行動履歴情報の取得方法の具体例    ３−５．情報処理方法  ４．ハードウェア構成  ５．補足
【００１５】  ここで、本開示の第１及び第２の実施形態では、ユーザに対してコンテンツを推薦するシステムについて説明する。以下の説明において、単にシステムといった場合には、特に記載のない限り、このような推薦システムを指すものとする。
【００１６】  第１及び第２の実施形態において扱われるコンテンツは、例えば映像、音楽、書籍、生活用品（食料品や飲料、衣服、電化製品等）等、一般的にユーザによって購入され得るあらゆるコンテンツであり得る。ただし、第１及び第２の実施形態では、例えばコンサート、演劇、映画、ツアー旅行等の席数（定員）が限定されているイベントが、好適にコンテンツとして扱われる。席数が限定されているイベントでは、そのチケットの販売期間や販売数が制限されるとともに、開催日時が近付くにつれて又残り席数が減るにつれて、当該販売期間や当該販売数も随時変化する。本明細書では、このような販売期間及び販売数の少なくともいずれかが制限されており、販売期間及び販売数が随時変化し得るコンテンツのことを、定量商材とも呼称する。なお、上述した以外のその他の定量商材としては、例えばフラッシュマーケティングにおいて扱われるクーポンや商品等が挙げられる。
【００１７】  第１及び第２の実施形態は、このような定量商材をユーザに対して推薦する際に、より大きな効果を奏するものである。従って、以下の説明では、システムによって推薦されるコンテンツが、定量商材として扱われるイベントである場合を例に挙げて説明を行う。以下の説明において、単にイベントといった場合には、特に記載のない限り、このような定量商材として扱われるイベントを指すものとする。ただし、上述したように、第１及び第２の実施形態において扱われるコンテンツはかかる例に限定されず、第１及び第２の実施形態では、あらゆるコンテンツがユーザに対して推薦されてよい。
【００１８】  （１．一般的なシステムについて）  まず、本開示の第１及び第２の実施形態について説明するに先立ち、本開示をより明確なものとするために、図１を参照して一般的なシステムについて説明する。図１は、一般的なシステムの概要について説明するための説明図である。
【００１９】  一般的に、イベントは、当該イベントの主催者（以下、イベンター、興行主等とも呼称する。）によって管理されている。図１に示すシステム４では、イベントＸ、イベントＹ、イベントＺが、それぞれ、イベンターＸのイベント管理システムであるイベント管理システムＸ２１０、イベンターＹのイベント管理システムであるイベント管理システムＹ２２０及びイベンターＺのイベント管理システムであるイベント管理システムＺ２３０によって管理されている。なお、以下の説明では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０を特に区別しない場合には、これらを、単に管理システムとも呼称する。
【００２０】  イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、それぞれが会員を有する。例えば、イベント管理システムＸ２１０の会員（Ｘ会員）は、イベント管理システムＸ２１０に自身のプロファイル情報を登録したユーザであり、イベント管理システムＸ２１０が管理するイベントのチケットを、当該イベント管理システムＸ２１０を介して購入することが可能である。同様に、イベント管理システムＹ２２０の会員（Ｙ会員）及びイベント管理システムＺ２３０の会員（Ｚ会員）も、それぞれ、イベント管理システムＹ２２０及びイベント管理システムＺ２３０に自身のプロファイル情報を登録しており、自身が会員となっている管理システムが管理するイベントのチケットを、各管理システムを介して購入することができる。
【００２１】  ここで、イベントの管理には、イベントのチケットの販売の管理、イベントメタ情報（イベントについての各種のメタ情報）の管理、会員のプロファイル情報の管理、当該会員のチケットの購入履歴情報の管理及びイベントの推薦の管理等が含まれ得る。イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、各自に登録されているイベントについて、上記のような各種の管理を行う。
【００２２】  なお、実際の業態としては、イベントの主催者と、当該イベントの管理者とが異なる場合も存在し得る。例えば、イベントの主催者が、チケットの販売を請け負う業者に対して、当該イベントのチケット販売の管理を委託する場合もあり得る。図１に示すイベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、上述したような各種のイベントの管理を総合的に行う管理システムを概略的に図示するものであり、各管理システムの内部は、複数の業者による複数のより小規模なシステムによって構成されていてもよい。
【００２３】  イベント管理システムＸ２１０は、自身の会員であるＸ会員に対するお薦めのイベントを予測する予測エンジン２１７と、Ｘ会員の購入履歴情報が蓄積されたログ２１８を有する。イベント管理システムＸ２１０は、当該予測エンジン２１７を用いて、Ｘ会員が興味を持ちそうなイベントを、Ｘ会員ごとに予測し、予測されたイベントを各Ｘ会員に対して推薦する機能を有する。なお、予測エンジン２１７は、一般的な推薦システムにおいて用いられる予測エンジンであってよい。例えば、予測エンジン２１７は、ログ２１８を参照することにより、推薦対象であるＸ会員の過去のイベントの購入傾向や、購入傾向の似た他のＸ会員の購入履歴等を参照することにより、当該Ｘ会員に対して推薦するイベントを予測することができる。
【００２４】  同様に、イベント管理システムＹ２２０及びイベント管理システムＺ２３０も、それぞれ、予測エンジン２２７、２３７及びログ２２８、２３８を有し、自身の会員に対して、イベントを推薦する機能を有する。
【００２５】  ここで、上述したように、イベントのチケットの販売、推薦においては、イベントの主催者と、当該イベントの管理者とが異なる場合も存在し得る。従って、例えば、同一のイベントが、互いに異なる複数のチケット販売業者に委託されることもある。また、同一のユーザが、互いに異なる複数の管理システムの会員となることもあり得る。このように、実際には、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、同一のイベントを管理している場合もあり得る。また、Ｘ会員、Ｙ会員及びＺ会員の中に、同一のユーザが含まれる可能性もある。
【００２６】  しかしながら、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、互いに連携しておらず、他の管理システムが管理するイベント及び会員に関与することはできない。例えば、システム４においては、イベントＸのチケットは、イベント管理システムＸ２１０を介してＸ会員によってのみ購入可能であり、Ｙ会員がイベント管理システムＹ２２０を介して又はＺ会員がイベント管理システムＺ２３０を介して、イベントＸのチケットを購入することはできない。また、例えば、会員へのイベントの推薦においても、イベント管理システムＸ２１０は、イベント管理システムＸ２１０に設けられた予測エンジン２１７が、イベント管理システムＸ２１０において蓄積されたログ２１８を用いて予測した結果に基づいて、イベント管理システムＸ２１０が管理するイベントＸを、Ｘ会員に対して推薦することしかできない。このように、システム４では、予測エンジン２１７が、他の管理システムのログ２２８、２３８を予測処理に用いたり、イベント管理システムＸ２１０が他の管理システムが管理するイベントをＸ会員に推薦したりすることはできない。
【００２７】  また、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０におけるイベントや会員に関する各種の情報の管理手法が、互いに異なっていることが多い。例えば、イベント管理システムＸ２１０とイベント管理システムＹ２２０とでは、イベントメタ情報を登録する際のスキーマが異なる可能性がある。従って、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、ただ単に、イベントメタ情報や会員プロファイル情報を互いに共有したとしても、各管理システムに登録されているイベントや会員が同一のイベントやユーザを指しているのかどうかを判断することができない。
【００２８】  以上説明したように、一般的なシステム４では、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０が、それぞれ独自に、イベント及び会員を管理していた。従って、同一のイベントや同一のユーザが、互いに異なる管理システムに登録されている場合であっても、そのことをシステム４が認識することができず、ユーザに対するイベントの推薦の精度や、ユーザによるチケット購入における利便性が、必ずしも最適化されているとは言えなかった。
【００２９】  本発明者らは、上記事情に鑑みて、ユーザの利便性をより向上させることが可能な技術について鋭意検討した結果、以下に示す本開示の好適な実施形態に想到した。以下では、本発明者らが想到した、本開示の好適な実施形態について詳細に説明する。
【００３０】  （２．第１の実施形態）  （２−１．システムの概要）  図２を参照して、本開示の第１の実施形態に係るシステムの概要について説明する。図２は、本開示の第１の実施形態に係るシステムの概要について説明するための説明図である。なお、第１の実施形態に係るシステムのより詳細な構成については、下記（２−２．システムの構成）で改めて詳しく説明する。
【００３１】  図２を参照すると、第１の実施形態に係るシステム１では、イベント管理システムＸ２１０によってイベントＸが管理され、イベント管理システムＹ２２０によってイベントＹが管理され、イベント管理システムＺ２３０によってイベントＺが管理されている。また、イベント管理システムＸ２１０は、Ｘ会員の購入履歴情報が蓄積されたログ２１８を有し、イベント管理システムＹ２２０は、Ｙ会員の購入履歴情報が蓄積されたログ２２８を有し、イベント管理システムＺ２３０は、Ｚ会員の購入履歴情報が蓄積されたログ２３８を有している。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０、並びに、ログ２１８、２２８、２３８は、図１に示すこれらの構成と同様の機能を有するものであるため、詳細な説明は省略する。
【００３２】  システム１は、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換された、共通化イベントメタ情報を保持している。各イベントのイベントメタ情報が、共通化イベントメタ情報として同一のスキーマで管理されることにより、システム１では、元々は各管理システムによってそれぞれ管理されていたイベントを、一括して管理することが可能となる。従って、システム１では、元々異なる管理システムで管理されていたイベントが同一のイベントかどうかを判断することが可能となる。
【００３３】  なお、図示は省略しているが、システム１では、同様に、各管理システムによって管理されている会員プロファイル情報が、共通のスキーマに変換され、共通化会員プロファイル情報として保持される。また、システム１では、同様に、各管理システムによって管理されている空席情報（イベントの残席、すなわちチケットの販売状況を表す情報）が、共通のスキーマに変換され、共通化空席情報として保持される。
【００３４】  システム１では、共通化会員プロファイル情報が保持されることにより、各管理システムによって管理されている会員プロファイル情報（例えばユーザＩＤ）が共有されることとなる。ただし、各管理システムにおけるユーザＩＤが共有化されたとしても、当該ユーザＩＤは各管理システムにおいて互いに異なるものであるため、第１の実施形態では、それらのユーザＩＤが示す会員が同一のユーザかどうかまでは判断することができない。
【００３５】  また、システム１では、共通化空席情報が保持されることにより、各イベントの空席情報が共有されることとなる。以下では、共通化イベントメタ情報、共通化会員プロファイル情報及び共通化空席情報等、共通のスキーマに変換された各種の情報のことを、共通化情報とも総称する。
【００３６】  ここで、システム１では、各管理システムがそれぞれ独自に予測エンジンを有するのではなく、各管理システムに横断的にアクセス可能な共通予測エンジン１５０が設けられる。共通予測エンジン１５０は、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０並びにログ２１８、２２８、２３８にアクセス可能であるとともに、共通化情報にもアクセス可能に構成される。共通予測エンジン１５０は、共通化情報及びログ２１８、２２８、２３８内の購入履歴情報に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能を有する。
【００３７】  ここで、共通予測エンジン１５０は、共通化イベントメタ情報にアクセスすることにより、各管理システムによって管理されている各イベントを、共通のスキーマで一括して扱うことができる。また、共通予測エンジン１５０は、共通化会員プロファイル情報にアクセスすることにより、各管理システムによって管理されている各会員を、共通のスキーマで一括して扱うことができる。このように、共通予測エンジン１５０は、元来は各管理システムによってそれぞれ独自に管理されていたイベント及び会員を、総合的に扱うことができる。
【００３８】  従って、共通予測エンジン１５０は、ログ２１８、２２８、２３８を参照して、推薦するコンテンツとユーザの組み合わせを決定する際に、ログ２１８、２２８、２３８内の購入履歴情報における同一のイベントを同定することができ、これらの購入履歴情報を統合して利用することが可能となる。従って、共通予測エンジン１５０は、より多くの購入履歴情報に基づいて推薦するコンテンツとユーザの組み合わせを決定することができるため、ユーザの興味や関心がより高精度に予測され、ユーザが興味を示しているイベントが、より的確に、当該ユーザに対して推薦されることとなる。
【００３９】  また、共通予測エンジン１５０は、共通化イベントメタ情報及び共通化会員プロファイル情報を用いることにより、ある管理システムによって管理されているイベントを、他の管理システムの会員に対しても推薦することができる。例えば、共通予測エンジン１５０は、イベント管理システムＸ２１０によって管理されているイベントＸを推薦すべきユーザとして、イベント管理システムＹ２２０によって管理されているＹ会員を選択することができる。このように、システム１では、一般的なシステム４に比べて、イベントを推薦する対象が拡大されるため、より多くのユーザに対してイベントの購入を促すことが可能となる、
【００４０】  更に、システム１では、共通化イベントメタ情報を、各管理システムでのスキーマに再度変換することができる。これにより、各管理システムにおけるチケット販売システムを横断的に利用することが可能となる。例えば、元々イベント管理システムＸによって管理されていたイベントＸの共通化イベントメタ情報を、イベント管理システムＹ２２０のスキーマに再度変換することにより、イベントＸの管理をイベント管理システムＹ２２０によっても行えるようにする。これにより、Ｙ会員に対してイベント管理システムＸ２１０が管理しているイベントＸが推薦された場合であっても、Ｙ会員は、わざわざイベント管理システムＸ２１０に会員として登録する必要はない。Ｙ会員は、イベント管理システムＹ２２０を介して、イベントＸのチケットを購入することができる。このように、第１の実施形態によれば、より自由度が高く、ユーザにとってより利便性の高いチケットの販売方法が実現される。
【００４１】  以上、図２を参照して、第１の実施形態に係るシステム１の概要について説明した。以上説明したように、第１の実施形態では、共通化イベントメタ情報を用いることにより、互いに異なる複数の管理システムによってそれぞれ管理されているイベントが、共通のスキーマで管理される。従って、各管理システムで管理されているイベントを一括して扱うことができ、イベントの推薦の精度の向上や、ユーザにとってより利便性の高いチケットの購入方法が実現される。
【００４２】  （２−２．システムの構成）  図３及び図４を参照して、以上説明した第１の実施形態に係るシステム１の構成についてより詳細に説明する。図３は、第１の実施形態に係るシステム１の一構成例を示すブロック図である。図４は、図３に示す推薦部１３０の機能構成の一例を示す機能ブロック図である。
【００４３】  図３を参照すると、第１の実施形態に係るシステム１は、情報処理装置１０と、イベント管理システムＸ２１０と、イベント管理システムＹ２２０と、イベント管理システムＺ２３０と、主催者プロファイル情報ＤＢ１４０と、入出力部１６０と、を備える。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０は、それぞれ、図２に示すイベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０に対応するものである。
【００４４】  なお、図３では、一例として、イベント管理システムＸ２１０の会員であるユーザが、イベント管理システムＸ２１０を介してイベントを推薦され、イベント管理システムＸ２１０を介してイベントのチケットを購入する場合について説明する。ただし、第１の実施形態はかかる例に限定されず、イベント管理システムＹ２２０においても、イベント管理システムＹ２２０の会員に対して同様の処理が行われ得るし、イベント管理システムＺ２３０においても、イベント管理システムＺ２３０の会員に対して同様の処理が行われ得る。また、システム１を構成するイベント管理システムの数も図示する例に限定されず、任意の数のイベント管理システムによってシステム１が構成されてよい。
【００４５】  （入出力部１６０）  入出力部１６０は、システム１とイベントの主催者との間の入出力インターフェースである。主催者は、入出力部１６０を介して、システム１に対して各種の情報を入力することができる。また、システム１は、入出力部１６０を介して、主催者に対して各種の情報を出力（提示）することができる。入出力部１６０は、例えばＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）や、スマートフォン、タブレット端末等、主催者が所有する、情報の入出力機能を有するデバイスであってよい。
【００４６】  例えば、主催者は、入出力部１６０を介して、後述する主催者プロファイル情報を入力する。入力された主催者プロファイル情報は、主催者プロファイル情報ＤＢ１４０に格納される。また、例えば、主催者は、入出力部１６０を介して、イベントメタ情報をイベント管理システムＸ２１０に入力する。入力されたイベントメタ情報は、後述するイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に格納される。なお、入出力部１６０におけるイベントメタ情報の入力画面の一例については、下記（２−４．表示例）で詳しく説明する。
【００４７】  また、入出力部１６０は、主催者に対して、イベントのチケットの販売状況、過去のチケットの販売実績の分析データ、チケットの販売戦略等の各種の情報を提示することができる。なお、入出力部１６０の情報提示機能は、後述する情報処理装置１０の提示制御部１７０によって制御され得る。
【００４８】  なお、入出力部１６０は、必ずしも情報処理装置１０と別個の装置によって構成されなくてもよく、情報処理装置１０と一体的に設けられてもよい。その場合、入出力部１６０は、情報処理装置１０に設けられる入力装置（例えば、マウス、キーボード、タッチパネル等）及び出力装置（ディスプレイ、スピーカ等）によって構成され得る。
【００４９】  （主催者プロファイル情報ＤＢ１４０）  主催者プロファイル情報ＤＢ１４０は、イベントの主催者についての情報である主催者プロファイル情報が格納されたデータベース（ＤＢ）である。例えば、主催者プロファイル情報は、主催者等を識別するための主催者ＩＤ、イベントＩＤ、各イベントに対する主催者の販売戦略を示す販売戦略情報、及び、各イベントの出演者のスケジュールや出来事を示す情報を含む。ここで、販売戦略情報は、例えば、各イベントの宣伝（プロモーション）の有無、宣伝の方法、宣伝の時期、チケットの料金の割引の有無及び割引率、イベントの参加者への特典の有無及び特典の内容等の情報を含む。なお、チケットの料金の割引の有無及び割引率は、チケット販売期間の残り期間とチケットの残り枚数に応じて変化するように設定されてもよい。また、特典の内容としては、例えば、握手券、サイン会の参加券、関連グッズのプレゼント、楽屋訪問、ＡＲ（Ａｕｇｍｅｎｔｅｄ  Ｒｅａｌｉｔｙ）を使ったプレミアムコンテンツのダウンロードの権利等が想定される。
【００５０】  主催者プロファイル情報は、主催者によって、イベントごとに主催者プロファイル情報ＤＢ１４０に登録される。なお、第１の実施形態では、後述する推薦部１３０によって、共通化イベントメタ情報等に基づいて、販売戦略が決定され得る。主催者は、推薦部１３０によって決定された販売戦略情報を適宜修正することにより、主催者プロファイル情報ＤＢ１４０に登録する販売戦略情報を作成することができる。
【００５１】  ここで、後述するように、システム１の情報処理装置１０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する機能を有し得る。第１の実施形態では、情報処理装置１０によって決定された販売戦略が、入出力部１６０を介して、主催者に対して提示されてよい。主催者は、提示された内容を参考にして、入出力部１６０を介して、販売戦略情報を入力することができる。情報処理装置１０による販売戦略の決定機能については、図４を参照して後で詳しく説明する。
【００５２】  なお、主催者プロファイル情報ＤＢ１４０、並びに後述するイベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４、購入履歴情報ＤＢ２１５、共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３は、例えばＨＤＤ（Ｈａｒｄ  Ｄｉｓｋ  Ｄｒｉｖｅ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス又は光磁気記憶デバイス等の各種の記憶デバイスによって構成される、各種の情報を記憶する記憶部の一形態である。
【００５３】  （イベント管理システムＸ２１０）  イベント管理システムＸ２１０は、その機能として、チケット販売システム２１１と、イベントメタ情報ＤＢ２１２と、空席情報ＤＢ２１３と、会員プロファイル情報ＤＢ２１４と、購入履歴情報ＤＢ２１５と、推薦イベント提示部２１６と、を有する。なお、イベント管理システムＸ２１０は、一般的に用いられている、各種の公知の管理システムと同様の構成であってよい。
【００５４】  チケット販売システム２１１は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を用いて、イベントのチケットの販売や予約の管理を行う。イベント管理システムＸ２１０の会員であるユーザは、チケット販売システム２１１を介して、所望のイベントのチケットを購入することができる。
【００５５】  例えば、チケット販売システム２１１は、Ｗｅｂサイト等を通じた電子的なチケットの販売に対応している。例えば、チケット販売システム２１１は、チケット販売店やコンビニエンスストア等の店頭に置かれる端末や、各ユーザのＰＣ、スマートフォン等の端末に、チケット販売用の画面やＷｅｂサイトを表示させて、チケットの販売サービスを提供する。
【００５６】  チケット販売システム２１１は、イベントメタ情報ＤＢ２１２に格納されているイベントメタ情報に基づいて、イベント名や当該イベントの開催日時、会場、料金等をユーザに対して提示する。その際、チケット販売システム２１１は、空席情報ＤＢ２１３に格納されている空席情報を参照して、チケットの残り枚数や、席の指定が可能なイベントであれば会場内の空席の位置を、ユーザに対して併せて提示することができる。
【００５７】  チケット販売システム２１１は、会員プロファイル情報ＤＢ２１４に格納されている会員プロファイル情報を参照することにより、自身に紐付けられているユーザ（図３に示す例であれば、イベント管理システムＸ２１０のＸ会員）に対して、チケットの販売を行う。チケットを購入したユーザは、ユーザＩＤによって管理され得る。
【００５８】  チケット販売システム２１１は、チケットの販売状況等に応じて、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４及び購入履歴情報ＤＢ２１５の情報を逐次更新する。例えば、購入履歴情報ＤＢ２１５では、チケットが購入されたイベントのイベントメタ情報と、当該チケットを購入したユーザＩＤとが関連付けられて格納される。
【００５９】  なお、チケット販売システム２１１としては、一般的に用いられている、各種の公知のシステムが適用されてよい。
【００６０】  イベントメタ情報ＤＢ２１２は、チケット販売システム２１１が取り扱うイベントについての各種のメタ情報を格納する。例えば、イベントメタ情報は、イベントの名称、イベントを識別するためのイベントＩＤ、開催日時、会場、イベントの内容、出演者、料金等の情報を含む。また、イベントメタ情報は、イベント開催情報の公開開始日時、チケットの予約開始及び終了日時、チケットの販売開始及び終了日時等の情報を含んでもよい。イベントメタ情報には、その他、一般的にチケット販売システムにおいてイベントに関する情報として用いられ得る、あらゆる各種の情報が含まれ得る。なお、イベントメタ情報ＤＢ２１２内のイベントメタ情報は、イベントの主催者によって、イベントごとに、入出力部１６０を介して、イベント管理システムＸ２１０に登録される。
【００６１】  以下、イベントメタ情報に含まれ得る情報について具体的に例示する。
【００６２】  例えば、イベントメタ情報は、イベントの内容についての情報として、タイムテーブル、出演者の出演順や出演予定時刻、セットリスト、照明やセットの動き等の各イベントの進行や演出等に関する情報を含む。
【００６３】  また、例えば、イベントメタ情報は、イベントの会場についての会場情報として、会場の種類、大きさ、席の配置、席の種類（Ｓ席、Ａ席、立見席、禁煙席、喫煙席等）、席の間隔、席の仕様（例えば、形、大きさ、材質等）、席の周囲の環境（例えば、出入口、通路、空調設備の位置等）等の情報を含む。また、会場情報は、例えば、会場内でイベントが行われる領域（イベント領域）、セット、楽器、講演台、司会台、照明、音響設備、機材の位置や仕様等の各イベント会場の設備やセッティングに関する情報を含む。更に、会場情報は、例えば、会場のセッティングが時系列で変化する場合には、当該セッティングの変化についての情報も含む。
【００６４】  また、例えば、イベントが、当該イベントを撮影した映像が各ユーザに対して配信されるような、ユーザが直接会場に出向かないイベントである場合には、イベントメタ情報は、ユーザの仮想的な席と、配信する映像内のイベント領域の見え方との関係等、イベントを配信する際に必要となる各種の情報を含む。
【００６５】  更に、イベントメタ情報は、例えば、出演者についての情報として、イベントの出演者の身体的特徴（例えば、身長、体型等）、動きやパフォーマンスの特徴、出演者の衣装等の情報を含む。
【００６６】  なお、本明細書において、出演者は、イベントにおいて見られる対象となる人及び動物等を含むものとする。例えば、スポーツの選手、サーカスの動物等も出演者に含まれる。
【００６７】  また、例えば、昼夜２公演のイベントや同じ会場で連日行われるイベント等、同様のイベントが同じ会場で続けて行われる場合、イベント情報は各回のイベント毎に作成され、保持される。また、例えば、ライブビューイング等の複数の会場で分散して行われるイベントについては、会場毎に会場情報が作成され、保持される。
【００６８】  空席情報ＤＢ２１３は、チケット販売システム２１１が取り扱うイベントの空席についての空席情報を格納する。例えば、空席情報には、会場を表す会場ＩＤ、当該会場での座席を表す座席ＩＤ、当該座席ＩＤが表す座席の会場内での位置についての情報等が含まれる。空席情報は、チケット販売システム２１１によって、イベントメタ情報に基づいて生成され、また、チケットの販売状況に応じてその内容が更新される。空席情報は、チケットの販売状況を表す情報であるとも言える。空席情報には、その他、一般的にチケット販売システムにおいてイベントでの空席を表す情報として用いられ得る、あらゆる各種の情報が含まれ得る。
【００６９】  会員プロファイル情報ＤＢ２１４は、チケット販売システム２１１に登録されている会員についての会員プロファイル情報を格納する。例えば、会員プロファイル情報には、ユーザを表すユーザＩＤや、当該ユーザの性別、年齢、国籍、住所、職業、クレジットカード番号についての情報等が含まれる。
【００７０】  また、会員プロファイル情報は、例えば、身長、座高、体型、視力、車椅子の使用の有無等の、ユーザの身体的特徴を含む。
【００７１】  更に、会員プロファイル情報は、例えば、ユーザの嗜好に関する嗜好情報を含む。例えば、嗜好情報は、ユーザが好きなアーティスト、好きなグループのメンバー、好きなチーム、好きな選手、好きなイベントの種類、好きなジャンル、好き又は得意な楽器、好きなステージセット等の、ユーザのイベント（出演者を含む）に対する嗜好情報を含む。また、例えば、嗜好情報は、好きな会場、好きな席の位置、好きなイベント領域を見る角度、好きな席の種類、好きな席の仕様等のユーザの会場や席に対する嗜好情報を含む。
【００７２】  また、会員プロファイル情報は、例えば、ユーザがチケットを購入する際の行動傾向に関する行動傾向情報を含む。ユーザの行動傾向とは、例えば、チケットの発売が開始された直後にチケットを買う傾向が強い（事前購入派）、又は、イベントの開催日直前にチケットを買う傾向が強い（直前購入派）等の、ユーザのチケット購入時の行動傾向である。なお、ユーザの行動傾向については、図５を参照して後で詳しく説明する。
【００７３】  なお、上述した嗜好情報や行動傾向情報は、例えば購入履歴情報を分析することによって得ることができる。当該分析処理は、チケット販売システム２１１によって行われてもよいし、その他の構成（例えば後述する情報処理装置１０の推薦部１３０）によって行われてもよい。
【００７４】  また、会員プロファイル情報は、例えば、ユーザのイベントの見方の特徴を示す見方特徴情報を含む。見方特徴情報は、例えば、騒ぐ、歌う、踊る、動きが激しい、笑う、泣く、手を叩く、静かに見る、座って見る、立って見る、寝る、声援を送る、奇声を上げる、ヤジを飛ばす、つぶやく、周囲と話す、コスプレをする、応援用のグッズを使う、貧乏ゆすりをする、アルコールを飲む、よく席を外す、遅れて参加する、途中で帰る等の情報を含む。
【００７５】  なお、見方特徴情報は、ユーザの実際の特徴だけではなく、騒ぎたい、歌いたい、踊りたい等のユーザの希望を含んでいてもよい。また、イベントの種類や出演者ごとにユーザのイベントの見方が異なることを考慮して、イベントの種類や出演者毎に各ユーザの見方特徴情報を分けて持つようにしてもよい。
【００７６】  なお、見方特徴情報は、例えば、各ユーザからのアンケートの回答に基づいて作成したり、イベント中の各ユーザの席付近の映像、画像、音声の解析結果に基づいて作成したりすることが可能である。また、例えば、ユーザ自身及びユーザの周囲の席の観客のイベントに関するソーシャルメディアへの投稿などをテキスト解析することにより、そのユーザの見方の特徴に関する情報を抽出し、見方特徴情報に反映させることも可能である。
【００７７】  会員プロファイル情報には、その他、一般的にチケット販売システムにおいて会員についての情報として用いられ得る、あらゆる各種の情報が含まれ得る。
【００７８】  購入履歴情報ＤＢ２１５は、チケット販売システム２１１に登録されている会員ごとの購入履歴情報を格納する。例えば、購入履歴情報ＤＢ２１５には、購入履歴情報として、ユーザＩＤ、購入回数、購入したイベントの会場、席種及び席の位置、イベントの種類（例えば、映画、演劇、コンサート、スポーツ等）、イベントの出演者等の情報が、互いに関連付けられて格納される。また、購入履歴情報は、例えば、同種のイベント（例えば、同じアーティストのコンサート等）のチケットを繰り返し購入する、幅広いジャンルのチケットを購入する、滅多に購入しない等の各ユーザの購入パターンを示す情報を含んでもよい。また、購入履歴情報は、ユーザに対して推薦したイベントと、当該イベントに対するユーザの行動（当該イベントのチケットを買ったか否か）についての情報を含んでもよい。更に、購入履歴情報は、販売期間内におけるチケットの購入時期についての情報を含んでもよい。なお、チケットの購入だけでなく、例えば、各ユーザがイベントに関する情報を閲覧したり、チケットの購入を検討するためにブックマーク等を付加した等の履歴も購入履歴情報に含めるようにしてもよい。
【００７９】  購入履歴情報に含まれるこれらの情報に基づいて、上述した嗜好情報や行動傾向情報が抽出され得る。このように、購入履歴情報に基づいて会員プロファイル情報が更新されてよい。なお、購入履歴情報ＤＢ２１５に格納される情報はかかる例に限定されず、購入履歴情報ＤＢ２１５は、一般的にチケット販売システムにおいて会員の購入履歴情報として格納され得るあらゆる各種の情報を記憶してもよい。
【００８０】  推薦イベント提示部２１６は、後述する情報処理装置１０の推薦部１３０によって決定されたユーザ（図３に示す例であればイベント管理システムＸの会員）に対して、推薦すべきイベントを提示することにより、当該ユーザに対して当該イベントの宣伝を行う。例えば、推薦イベント提示部２１６は、イベントの広告を、チケット販売システム２１１のチケット販売画面等に、ユーザへのお薦めのイベントとして表示する。また、例えば、推薦イベント提示部２１６は、イベントについての情報を、ユーザへのお薦めのイベントとして、電子メール等によって当該ユーザに対して配信する。なお、推薦イベント提示部２１６は、例えばＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）やＤＳＰ（Ｄｉｇｉｔａｌ  Ｓｉｇｎａｌ  Ｐｏｃｅｓｓｏｒ）等の各種のプロセッサによって構成され、推薦イベント提示部２１６の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。
【００８１】  （情報処理装置１０）  情報処理装置１０は、その機能として、スキーマ変換部１１０と、共通化イベントメタ情報ＤＢ１２１と、共通化空席情報ＤＢ１２２と、共通化会員プロファイル情報ＤＢ１２３と、推薦部１３０と、提示制御部１７０と、を有する。なお、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０は、例えばＣＰＵやＤＳＰ等の各種のプロセッサによって構成され、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。
【００８２】  提示制御部１７０は、主催者がシステム１に対して各種の情報の入出力を行うインターフェースである入出力部１６０における情報の提示を制御する。提示制御部１７０は、入出力部１６０に各種の情報を表示させることにより、当該情報を主催者に対して提示する。例えば、提示制御部１７０は、推薦部１３０によって決定されるイベントの販売戦略についての情報を、入出力部１６０を介して主催者に対して提示する。提示制御部１７０は、その他にも、イベントのチケットの販売状況、過去のチケットの販売実績の分析データ等、主催者が所望する各種の情報を、入出力部１６０を介して主催者に提示してもよい。
【００８３】  スキーマ変換部１１０は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を、共通のスキーマに変換する。具体的には、スキーマ変換部１１０は、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報を、共通のＩＤ体系で管理できるように変換する。上記（１．一般的なシステムについて）で説明したように、一般的に、イベントを管理する管理システムが異なれば、管理される情報のスキーマが異なる。第１の実施形態では、スキーマ変換部１１０によって、互いに異なる管理システムで管理されている情報が、共通のスキーマに変換されることにより、これらの情報を一括して管理することが可能となるのである。
【００８４】  スキーマ変換部１１０によってスキーマ変換された、イベントメタ情報ＤＢ２１２内のイベントメタ情報は、共通化イベントメタ情報として共通化イベントメタ情報ＤＢ１２１に格納される。スキーマ変換部１１０によってスキーマ変換された、空席情報ＤＢ２１３内の空席情報は、共通化空席情報として共通化空席情報ＤＢ１２２に格納される。スキーマ変換部１１０によってスキーマ変換された、会員プロファイル情報ＤＢ２１４内の会員プロファイル情報は、共通化会員プロファイル情報として共通化会員プロファイル情報ＤＢ１２３に格納される。
【００８５】  共通化イベントメタ情報ＤＢ１２１は、共通のスキーマに変換されたイベントメタ情報（共通化イベントメタ情報）を格納する。例えば、共通化イベントメタ情報は、イベントの名称、イベントの出演者、イベントのジャンル、イベントが開催される会場、イベントに関する日時（開催日時、イベント開催情報の公開開始日時、予約開始及び終了日時、チケット販売開始及び終了日時等）、チケットの料金（チケット価格、入場料等）、イベントの内容（概要文、イベント紹介用の画像又は動画、出演者やイベントに対するレビュー、イベントの詳細情報を掲載したＷｅｂサイトのＵＲＬ等）等の項目についての情報の一部又は全てを含む。ここで、例えば出演者についての情報、イベントのジャンルについての情報及びイベントが開催される会場についての情報は、それぞれ、共通のＩＤ（共通化出演者ＩＤ、共通化ジャンルＩＤ、共通化会場ＩＤ）によって管理されている。また、その他の情報も、共通のフォーマットで管理されている。このように、共通化イベントメタ情報ＤＢ１２１には、元々は互いに異なる管理システムにおいて互いに異なるスキーマで登録されていたイベントメタ情報が、共通のスキーマで格納される。
【００８６】  共通化空席情報ＤＢ１２２は、共通のスキーマに変換された空席情報（共通化空席情報）を格納する。例えば、共通化空席情報は、イベントの空席情報（例えば残っている席の座席区分、座席番号、価格等についての情報）を含む。
【００８７】  共通化会員プロファイル情報ＤＢ１２３は、共通のスキーマに変換された会員プロファイル情報（共通化会員プロファイル情報）を格納する。共通化会員プロファイル情報は、例えば、ユーザＩＤについての情報を含む。これにより、各管理システムによって管理されていたユーザＩＤが共有されることとなる。ただし、各管理システムにおけるユーザＩＤが共通化されたとしても、当該ユーザＩＤは各管理システムにおいて互いに異なるものであるため、第１の実施形態では、それらのユーザＩＤが示す会員が同一のユーザかどうかまでは判断することができない。また、共通化会員プロファイル情報は、上述した嗜好情報、傾向情報、見方特徴情報を含んでもよい。
【００８８】  推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する。換言すれば、推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントを推薦すべきユーザを選択したり、ユーザに対して推薦すべきイベントを選択したりする。推薦部１３０は、図２に示す共通予測エンジン１５０に対応する機能を有する。
【００８９】  具体的には、推薦部１３０は、各管理システムの購入履歴情報ＤＢ２１５内の購入履歴情報を、共通化イベントメタ情報に紐付けることにより、各管理システムの購入履歴情報を総合的に利用して、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。そして、推薦部１３０は、生成した予測モデルに基づいて、推薦するイベントとユーザの組み合わせを決定する。
【００９０】  推薦部１３０は、決定されたユーザが会員として登録されている管理システムの推薦イベント提示部に対して、決定したイベントとユーザとの組み合わせについての情報を送信する。図３に示す例では、決定されたユーザがイベント管理システムＸ２１０の会員であり、イベント管理システムＸ２１０の推薦イベント提示部２１６に対して決定したイベントとユーザとの組み合わせについての情報が送信される場合について図示している。
【００９１】  推薦イベント提示部２１６は、選択されたユーザに対して、選択されたイベントを提示する。例えば、推薦イベント提示部２１６は、選択されたユーザに紐付けられたチケット購入画面（例えば、当該ユーザがログインした状態でのチケット購入画面等）のお薦め欄や広告欄に、選択されたイベントについての情報を表示させる。
【００９２】  ここで、推薦部１３０によって決定されるイベントとユーザとの組み合わせは、例えば、共通化イベントメタ情報と共通化されたユーザＩＤとで表現されている。従って、イベントとユーザとの組み合わせについての情報が、推薦部１３０から推薦イベント提示部２１６に送信される際には、これらの情報は、スキーマ変換部１１０を介して、提示する対象である管理システム（図３に示す例であればイベント管理システムＸ２１０）のスキーマに変換される。これにより、イベント管理システムＸ２１０の推薦イベント提示部２１６では、元々のイベント管理システムＸ２１０のスキーマで、イベントメタ情報及びユーザＩＤを扱うことが可能となる。
【００９３】  なお、第１の実施形態では、イベント管理システムＸ２１０の会員に提示されるイベントは、必ずしも、イベント管理システムＸ２１０によって管理されているイベントでなくてもよい。このように、第１の実施形態では、イベントメタ情報が、共通化イベントメタ情報として一括して管理されることにより、一の管理システムによって管理されているイベントを他の管理システムの会員に対して提示することも可能である。
【００９４】  また、推薦部１３０は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する機能を更に有してもよい。決定された販売戦略についての情報は提示制御部１７０に提供され、提示制御部１７０によって、入出力部１６０を介して主催者に対して提示される。
【００９５】  ここで、図４を参照して、推薦部１３０の機能構成についてより詳細に説明する。図４を参照すると、推薦部１３０は、その機能として、主催者プロファイル情報取得部１３１と、共通化情報取得部１３２と、購入履歴情報取得部１３３と、予測モデル生成部１３４と、イベント−ユーザ決定部１３５と、販売戦略決定部１３６と、を有する。ここで、図４では、説明のため、推薦部１３０と情報をやり取りする構成として、主催者プロファイル情報ＤＢ１４０、共通化情報ＤＢ１２０、購入履歴情報ＤＢ２１５、スキーマ変換部１１０及び提示制御部１７０を併せて図示している。なお、共通化情報ＤＢ１２０は、図面が煩雑になることを避けるために、図３に示す共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３を併せて１つのブロックとして図示したものである。
【００９６】  主催者プロファイル情報取得部１３１は、主催者プロファイル情報ＤＢ１４０から主催者プロファイル情報を取得する。主催者プロファイル情報取得部１３１は、取得した主催者プロファイル情報を、予測モデル生成部１３４、イベント−ユーザ決定部１３５及び販売戦略決定部１３６に提供する。
【００９７】  共通化情報取得部１３２は、共通化情報ＤＢ１２０から共通化情報を取得する。共通化情報取得部１３２は、取得した共通化情報を、予測モデル生成部１３４、イベント−ユーザ決定部１３５及び販売戦略決定部１３６に提供する。
【００９８】  購入履歴情報取得部１３３は、購入履歴情報ＤＢ２１５から購入履歴情報を取得する。購入履歴情報取得部１３３は、取得した購入履歴情報を、予測モデル生成部１３４、イベント−ユーザ決定部１３５及び販売戦略決定部１３６に提供する。なお、図４では、一の購入履歴情報ＤＢ２１５（例えば図３に示すイベント管理システムＸ２１０の購入履歴情報ＤＢ２１５）しか図示していないが、購入履歴情報取得部１３３は、イベント管理システムＹ２２０及びイベント管理システムＺ２３０の購入履歴情報ＤＢ２１５からも、同様に、購入履歴情報を取得する。
【００９９】  販売戦略決定部１３６は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、に基づいて、イベントの販売戦略を決定する。販売戦略決定部１３６によって決定される販売戦略には、上記で主催者プロファイル情報ＤＢ１４０について説明した際に言及した各種の項目が含まれてよい。
【０１００】  ここで、第１の実施形態では、販売戦略決定部１３６は、好適に、チケットの販売期間及び販売数に応じた宣伝戦略（広告戦略）を決定する。当該宣伝戦略には、例えば、販売期間及び販売数に応じたイベントの宣伝量、販売期間及び販売数に応じたイベントの宣伝時期、販売期間及び販売数に応じたイベントの宣伝を行うユーザの属性、販売期間及び販売数に応じたイベントの宣伝の費用対効果についての情報等が含まれる。定量商材であるイベントでは、チケットの販売期間及び販売数が制限されているため、このような、販売期間や販売数に応じた細やかな宣伝戦略が設定されることにより、より的確な宣伝が可能にある。
【０１０１】  例えば、販売戦略決定部１３６は、共通化イベントメタ情報に含まれるイベントの種類についての情報や、購入履歴情報に含まれる過去のチケットの販売実績についての情報等に基づいて、上述したような宣伝戦略を決定することができる。例えば、音楽系のイベントは、単発又は公演数が少ないものが多く、事前にチケットが売り切れるものが多い。従って、音楽系イベントについては、チケット発売日時に近い時期により多くの宣伝が行われることが好ましい。一方、演劇系のイベントは、所定の期間内に繰り返し開催されることが多く、開催直前でもチケットが残っていることが多い。そのため、演劇系イベントについては、チケット発売日時に近い時期及びイベントの開催日時に近い時期の、両方の時期により多くの宣伝が行われることが好ましい。このように、イベントの種類に応じて、チケットが購入される時期に明確な傾向が現れる場合には、当該傾向を考慮して宣伝の時期等が決定され得る。
【０１０２】  また、例えば、販売戦略決定部１３６は、チケットの発売開始日時に近い時期にはより多くのユーザに対して宣伝を行い、チケットの発売終了日時が近付くにつれて、よりそのイベントに興味を抱いていることが推測されるユーザに対して宣伝を行うように、宣伝戦略を決定してもよい。チケットの発売終了日時が近い時期には、チケットの売れ残りを極力少なくするために、チケットを購入する可能性がより高いユーザに対してピンポイントで宣伝を行うことが効果的であると考えられるからである。
【０１０３】  また、例えば、販売戦略決定部１３６は、チケットの販売期間の残り期間、チケットの残り枚数、及びそのイベントに興味を抱いていることが推測されるユーザの数やその興味の度合い等に基づいて、宣伝を行うことによってチケットが購入される確率を計算し、宣伝の費用対効果を計算してもよい。費用対効果が主催者に対して示されることにより、主催者が宣伝を行う時期や宣伝量を決定する際の指針となり得る。
【０１０４】  また、例えば、販売戦略決定部１３６は、共通化会員プロファイル情報に含まれるユーザの行動傾向情報に更に基づいて、宣伝戦略を決定してもよい。
【０１０５】  ここで、図５を参照して、このような、ユーザの行動傾向情報に基づく販売戦略の決定処理について詳しく説明する。図５は、ユーザの行動傾向情報に基づく販売戦略の決定処理について説明するための説明図である。
【０１０６】  図５では、横軸に時間を取り、縦軸にユーザがチケットを購入する確率を取り、ユーザの購入確率の時間的な変化を概略的に図示している。なお、図５に示すような購入確率分布は、ユーザのチケット購入の実績をヒストグラムとして表し、当該ヒストグラムに基づいて、ガウス分布等の当該ヒストグラムの性質に応じた適切な確率分布を推定することにより得ることができる。
【０１０７】  図５（ａ）は、事前購入派のユーザ１の購入確率分布の一例を図示している。ユーザ１は、チケットの発売開始日時の直後にチケットを購入する確率が高い。従って、ユーザ１は、チケットの発売開始前から、興味のあるイベントの情報をチェックしている可能性が高い。よって、販売戦略決定部１３６は、ユーザ１に対しては、チケット発売開始前からイベントの宣伝を行うような販売戦略を好適に決定する。
【０１０８】  一方、図５（ｂ）は、直前購入派のユーザ２の購入確率分布の一例を図示している。ユーザ２は、イベントの開催日直前にチケットを購入する確率が高い。従って、ユーザ２に対して、チケットの発売開始前からイベントの宣伝をしてもその効果は小さいと考えられる。よって、販売戦略決定部１３６は、ユーザ２に対しては、チケット発売開始日からしばらく経過した後にイベントの宣伝を行うような販売戦略を好適に決定する。
【０１０９】  このように、ユーザの行動傾向情報に基づいて販売戦略が決定されることにより、より適切なタイミングでイベントの宣伝を行うことが可能となる。
【０１１０】  販売戦略決定部１３６は、決定した販売戦略についての情報を、提示制御部１７０に提供する。当該販売戦略についての情報は、提示制御部１７０によって主催者に対して提示される。主催者は、提示された情報を参考にして、最終的な販売戦略を決定し、主催者プロファイル情報として、主催者プロファイル情報ＤＢ１４０に入力することができる。提示制御部１７０は、例えば、販売戦略決定部１３６によって決定された販売戦略を、主催者がより容易に、より直感的に修正できるような設定画面を、入出力部１６０に表示させてもよい。
【０１１１】  なお、販売戦略決定部１３６は、複数の販売戦略を決定してもよく、それら複数の販売戦略が、提示制御部１７０によって主催者に対して提示されてもよい。この場合、主催者は、提示された販売戦略の候補の中から、自身の意図に最も沿った販売戦略を選択することができる。
【０１１２】  予測モデル生成部１３４は、共通化イベントメタ情報と、購入履歴情報と、に基づいて、推薦するイベントとユーザとの組み合わせを選択するための予測モデルを生成する。具体的には、予測モデル生成部１３４は、各管理システムの購入履歴情報ＤＢ２１５内の購入履歴情報を、共通化イベントメタ情報に紐付ける。当該紐付け処理により、互いに異なる複数の管理システムにおける購入履歴情報が、共通化イベントメタ情報と関連付けられて一括して扱えるようになる。推薦部１３０は、共通化イベントメタ情報と関連付けられた購入履歴情報に基づいて、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。当該予測モデルは、互いに異なる複数の管理システムにおける購入履歴情報を総合的に利用して生成されるものであるため、一の管理システムの購入履歴情報を用いて生成される予測モデルよりも、予測の精度が優れていると言える。
【０１１３】  ここで、予測モデルとしては、公知の各種の予測モデルが用いられてよい。例えば、予測モデルは、協調フィルタモデルであってよい。協調フィルタモデルでは、嗜好が類似する他のユーザの購入履歴情報を用いて、対象とするユーザが興味を有していると思われるイベントが予測される。予測モデルが協調フィルタモデルである場合、購入履歴情報に関連付けられた共通化イベントメタ情報を用いて、協調度を表す特徴量が算出され得る。
【０１１４】  また、例えば、予測モデルでは、ベクトルマッチングを用いた手法が適用されてもよい。当該手法では、ユーザの購入履歴情報に含まれる共通化イベントメタ情報をベクトル化し、特徴量ごとに頻度を重ねる。これにより、ユーザの興味の対象を示すユーザベクトルが生成され得る。そして、あるイベントの共通化イベントメタ情報から求められた、当該イベントの特徴量を示すベクトルと、ユーザの購入履歴情報から得られたユーザベクトルとの間でベクトルマッチングを行い、その距離を、コサイン距離、ユークリッド距離等で算出する。当該距離が近いユーザほど、当該イベントに対して興味を抱いているユーザであると言える。
【０１１５】  また、予測モデル生成部１３４は、共通化会員プロファイル情報に含まれる行動傾向情報や嗜好情報、見方特徴情報に更に基づいて予測モデルを生成してもよい。これにより、よりユーザの性向が反映された予測モデルを生成することが可能となる。また、予測モデル生成部１３４は、主催者プロファイル情報に含まれる販売戦略情報に更に基づいて予測モデルを生成してもよい。当該販売戦略情報は、販売戦略決定部１３６によって決定され、主催者によって修正されたものであり得る。これにより、イベントの種類や過去の販売実績を踏まえつつ、より主催者のチケット販売の意図が反映された予測モデルを生成することが可能となる。なお、主催者からの明示的な販売戦略の指示がなかった場合には、予測モデル生成部１３４は、販売戦略決定部１３６によって決定された販売戦略に基づいて予測モデルを生成してもよい。
【０１１６】  また、予測モデル生成部１３４は、行動傾向情報と販売戦略情報とを組み合わせて、予測モデルを生成してもよい。例えば、図５（ａ）に示すような事前購入派であるユーザに対しては、販売戦略として発売開始直後に多くのチケットを売ろうとしているイベントを推薦することにより、当該イベントのチケットの購入をより促すことができると考えられる。従って、予測モデル生成部１３４は、当該ユーザに対しては、チケットの発売開始日に近い時期に多くのチケットを販売するような販売戦略が設定されているイベントを推薦するような予測モデルを好適に生成することができる。一方、図５（ｂ）に示すような直前購入派であるユーザに対しては、販売戦略としてイベントの開催直前に多くのチケットを売ろうとしているイベントを推薦することにより、当該イベントのチケットの購入をより促すことができると考えられる。従って、予測モデル生成部１３４は、当該ユーザに対しては、開催日の直前に多くのチケットを販売するような販売戦略が設定されているイベントを推薦するような予測モデルを好適に生成することができる。
【０１１７】  予測モデル生成部１３４は、生成した予測モデルを、イベント−ユーザ決定部１３５に提供する。
【０１１８】  イベント−ユーザ決定部１３５は、予測モデルを用いて、推薦するイベントとユーザの組み合わせを決定する。具体的には、イベント−ユーザ決定部１３５は、予測モデルを用いてイベントとユーザとのマッチングを行い、推薦対象であるイベントに興味を抱いていると思われるユーザを選択する（あるいは、逆に、推薦対象であるユーザが興味を抱いていると思われるイベントを選択する）。共通化情報として、共通化イベントメタ情報及び共通化会員プロファイル情報が取得されているため、イベント−ユーザ決定部１３５は、各イベント管理システムによってそれぞれ管理されているイベント及び会員を総合して、横断的にイベントとユーザとのマッチングを行うことができる。
【０１１９】  なお、イベント−ユーザ決定部１３５は、共通化空席情報に基づいて、席まで考慮して、イベントとユーザとのマッチングを行ってもよい。例えば、購入履歴情報や、共通化会員プロファイル情報に含まれる嗜好情報に基づいて、ユーザが好んで座る席が分かる場合には、イベント−ユーザ決定部１３５は、予測モデルを用いるとともに、ユーザが好んで座る席に近い席が空席であるイベントを、当該ユーザに対して推薦すべきイベントとして選択してもよい。
【０１２０】  また、イベント−ユーザ決定部１３５は、共通化会員プロファイル情報に含まれるその他の嗜好情報や、見方特徴情報、ユーザの身体的特徴を示す情報等に基づいて、ユーザに適したイベントを選択することもできる。
【０１２１】  また、イベント−ユーザ決定部１３５は、主催者プロファイル情報に含まれる主催者ＩＤ（すなわち管理システムを表すＩＤ）に基づいて、所定の主催者ＩＤの管理システムの会員のみをマッチングの対象としてもよい。このように、第１の実施形態では、イベントを提示する対象となるユーザを、いずれかの管理システムの会員のみに制限することができる。当該設定は、主催者プロファイル情報を登録する際に、主催者によって行われてよい。
【０１２２】  イベント−ユーザ決定部１３５は、決定したイベント及びユーザの組み合わせについての情報を、スキーマ変換部１１０に提供する。
【０１２３】  ここで、イベント−ユーザ決定部１３５によって決定されるイベントとユーザとの組み合わせは、例えば、共通化イベントメタ情報と共通化されたユーザＩＤとで表現されている。スキーマ変換部１１０は、決定されたイベント及びユーザの組み合わせについての情報に基づいて、当該イベントの共通化イベントメタ情報及び当該ユーザを表す共通化されたユーザＩＤを、それぞれ、提示の対象としているイベント管理システムのスキーマに変換し直す。ここで、提示の対象としているイベント管理システムは、決定されたユーザが会員として登録されている管理システムである。スキーマ変換が再度行われることにより、イベント及びユーザを、各イベント管理システムのスキーマで扱うことが可能となる。各イベント管理システムでは、例えば図３に示す推薦イベント提示部２１６により、選択されたイベントの宣伝を、選択されたユーザに対して提示することができる。また、各イベント管理システムでは、ユーザの操作に応じて、ユーザに対して提示されたイベントのチケットを販売することもできる。
【０１２４】  ここで、第１の実施形態では、イベント−ユーザ決定部１３５は、ある管理システムにおいて管理されているイベントを推薦するユーザとして、他の管理システムの会員を選択することができる。例えば、イベント管理システムＹ２２０で管理されているイベントＹを推薦するユーザとして、イベント管理システムＸ２１０の会員であるユーザが選択され得る。この場合には、イベントＹのイベントメタ情報は、共通化イベントメタ情報に変換された後、イベント管理システムＸ２１０で管理可能なスキーマに再変換される。これにより、イベントＹをイベント管理システムＸ２１０で扱うことが可能となる。第１の実施形態では、イベントメタ情報及び会員プロファイル情報が共通化され、情報処理装置１０によって総合的に管理され得ることにより、このような、異なる管理システム間での、ユーザとイベントとのマッチングが可能となるのである。
【０１２５】  また、第１の実施形態では、一の管理システムで管理しているイベントを、スキーマ変換によって他の管理システムのＤＢに格納することにより、当該イベントのチケットの販売を当該他の管理システムが行うことも可能である。例えば、上記の例であれば、元々イベント管理システムＹ２２０で管理されていたイベントＹを、イベント管理システムＸ２１０を介して推薦された、イベント管理システムＸ２１０の会員であるユーザは、イベント管理システムＸ２１０を介して、当該イベントＹのチケットの購入を行うことができる。この際、当該ユーザは、異なるイベント管理システムで管理されているイベントであることを意識することなく、イベントの宣伝の視聴や、チケットの購入を行うことができる。このように、第１の実施形態によれば、より自由度が高く、ユーザにとって利便性の高い、イベントの推薦やチケットの購入が実現され得る。
【０１２６】  以上、図３及び図４を参照して、第１の実施形態に係るシステム１の構成について説明した。以上説明したように、第１の実施形態によれば、互いに異なる複数の管理システムによって管理されているイベントメタ情報が共通のスキーマに変換されることにより、これらのイベントメタ情報を総合的に扱うことが可能となる。従って、当該複数の管理システムの購入履歴情報も総合的に扱うことができ、予測エンジンの精度を向上させることができる。よって、より適切に、推薦するイベントとユーザとのマッチングが行われることとなる。また、イベントメタ情報が共通化されることにより、イベントメタ情報をイベントのチケットの購入がより促進され、チケットの売り主である主催者の利便性が向上する。
【０１２７】  また、共通化されたイベントメタ情報を、各管理システムのスキーマに変換し直すことにより、元々は一の管理システムによって管理されていたイベントを、他の管理システムにおいても扱うことが可能となる。すなわち、管理システム間でイベントメタ情報を相互に利用することができる。従って、イベントの推薦のマッチングの対象であるユーザが、全ての管理システムの会員に拡張されるため、チケットの購入層が広がり、チケットの購入が更に促進される。
【０１２８】  また、上記のように、各管理システム間でイベントメタ情報が相互に利用可能となることにより、イベントのチケットの販売を、いずれの管理システムでも行うことが可能となるため、会員であるユーザの利便性が向上する。
【０１２９】  なお、情報処理装置１０の装置構成は、図３及び図４に示す例に限定されない。例えば、図３及び図４に示す情報処理装置１０の各機能は、必ずしも１つの装置に一体的に搭載されなくてもよい。図３及び図４に示す情報処理装置１０に搭載される各機能が、複数の装置に分散されて搭載され、当該複数の装置が通信可能に接続されることにより、情報処理装置１０が構成されてもよい。例えば、各ＤＢは、情報処理装置１０とは異なる外部の機器として備えられてもよく、情報処理装置１０が、外部機器であるこれらＤＢと通信を行いながら、上述した各種の処理を実行してもよい。
【０１３０】  また、上述のような第１の実施形態に係る情報処理装置１０の機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
【０１３１】  （２−３．情報処理方法）  図６を参照して、図３に示すシステム１において実行される、第１の実施形態に係る情報処理方法について説明する。図６は、第１の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。なお、以下では、図３に示すシステム１において、イベント管理システムＸ２１０によって管理されているイベントＳがユーザ（イベント管理システムＸ２１０の会員）に対して推薦される場合を例に挙げて、情報処理方法についての説明を行う。
【０１３２】  図６を参照すると、第１の実施形態に係る情報処理方法では、まず、主催者によって、イベントＳのイベントメタ情報及び主催者プロファイル情報が登録される（ステップＳ１０１）。具体的には、ステップＳ１０１に示す処理では、イベントＳのイベントメタ情報及び主催者プロファイル情報が、入出力部１６０を介して、それぞれ、イベントメタ情報ＤＢ２１２及び主催者プロファイル情報ＤＢ１４０に格納される。
【０１３３】  次に、イベントＳのイベントメタ情報及び空席情報と、イベント管理システムＸ２１０の会員プロファイル情報と、が、共通のスキーマに変換される（ステップＳ１０３）。具体的には、ステップＳ１０３に示す処理では、イベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３及び会員プロファイル情報ＤＢ２１４に格納されている情報が、共通のスキーマに変換され、共通化情報（すなわち、共通化イベントメタ情報、共通化空席情報及び共通化会員プロファイル情報）が生成される。同様に、他の管理システムのイベントメタ情報、空席情報及び会員プロファイル情報も、共通のスキーマに変換される。ステップＳ１０３に示す処理は、例えば図３に示すスキーマ変換部１１０によって行われる処理に対応している。
【０１３４】  次に、共通化イベントメタ情報及び購入履歴情報に基づいて、販売戦略が決定される（ステップＳ１０４）。当該販売戦略は、例えば、イベントの種類や、過去の同種のイベントの販売実績等に基づいて決定され得る。図示は省略するが、決定された販売戦略は主催者に対して提示され、主催者によって最終的な販売戦略が決定される。ステップＳ１０４に示す処理は、例えば図４に示す販売戦略決定部１３６によって行われる処理に対応している。
【０１３５】  次に、共通化イベントメタ情報及び購入履歴情報に基づいて、予測モデルが生成される（ステップＳ１０５）。当該予測モデルは、例えば、イベントの種類や、ユーザの購入履歴等を考慮して、イベントＳを推薦すべきユーザを予測するためのモデルである。ステップＳ１０５に示す処理は、例えば図４に示す予測モデル生成部１３４によって行われる処理に対応している。
【０１３６】  次に、生成された予測モデルに基づいて、イベントＳにマッチするユーザが選択される（ステップＳ１０７）。ステップＳ１０７に示す処理は、例えば図４に示すイベント−ユーザ決定部１３５によって行われる処理に対応している。ここでは、例えば、イベント管理システムＸ２１０の会員であるユーザが選択されたとする。
【０１３７】  次に、イベントＳと選択されたユーザについての情報が、当該ユーザが登録されているイベント管理システムＸ２１０に送信される（ステップＳ１０９）。なお、ステップＳ１０９に示す処理では、送信される情報は、送信先のイベント管理システムＸ２１０に対応したスキーマに変換される。ステップＳ１０７に示すスキーマ変換処理は、例えば図３に示すスキーマ変換部１１０によって実行され得る。
【０１３８】  次に、選択されたユーザに対して、イベントＳが提示される（ステップＳ１１１）。ステップＳ１１１に示す処理は、例えば図３に示す推薦イベント提示部２１６によって行われる処理に対応している。例えば、ユーザに対して表示されるチケット購入画面等においてお薦めのイベントとしてイベントＳの情報が表示されたり、当該チケット購入画面内の広告領域にイベントＳの情報が表示されたりしてよい。
【０１３９】  次に、ユーザの購入行動に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の購入履歴情報が更新される（ステップＳ１１３）。なお、ステップＳ１１３に示す処理では、ユーザが、ステップＳ１１１に示す処理において提示されたイベントＳの広告を見て当該イベントＳのチケットを購入した場合はもちろんのこと、他のユーザの購入行動も、空席情報ＤＢ２１３内の空席情報及び購入履歴情報ＤＢ２１５内の購入履歴情報に反映され得る。
【０１４０】  次に、オフラインでの購入実績に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の購入履歴情報が更新される（ステップＳ１１５）。ここで、オフラインでの購入実績とは、例えば会場の窓口でのチケットの購入実績等、システム１では直接検知できない購入実績である。ステップＳ１１５に示す処理は、例えば、オフラインでのチケットの売り上げを把握し得る主催者等によって行われる。
【０１４１】  なお、図６では、便宜的に、ステップＳ１１３に示す処理及びステップＳ１１５に示す処理をこの順序で図示しているが、これらの処理は、システム１において随時実行される処理であるため、その順序は任意であってよい。
【０１４２】  ステップＳ１１５に示す処理が終了すると、ステップＳ１０３に戻り、更新された空席情報及び購入履歴情報に基づいて、ステップＳ１０３以降の処理が繰り返し実行される。なお、図６に示すフロー図では明示していないが、実際には、例えば売り上げ実績に応じた主催者プロファイル情報内の販売戦略情報の変更や、新規会員の登録及び既存会員の退会等による会員プロファイル情報の変更、イベント内容の変更に伴うイベントメタ情報の変更等も随時行われ得る。図６に示すフローにおいては、このような主催者プロファイル情報、イベントメタ情報及び会員プロファイル情報の変更も適宜実行されてよい。その場合、変更されたこれらの情報に基づいて、各ステップに示す処理が実行され得る。また、ステップＳ１０５に示す予測モデルの生成処理は、図６に示す一連の処理が実行される際に、毎回行われなくてもよい。例えば、１週間に１度、あるいは一定量の購入履歴情報が更新されたタイミングで、ステップＳ１０５に示す処理が行われ、予測モデルが更新されてもよい。
【０１４３】  以上、図６を参照して、第１の実施形態に係る情報処理方法について説明した。
【０１４４】  （２−４．表示例）  図３を参照して説明したように、第１の実施形態に係るシステム１では、主催者は、入出力部１６０を介してイベントメタ情報や主催者プロファイル情報等を入力することができる。このような、本システム１に必要な情報を一括して入力可能な入出力インターフェースを提供することにより、主催者の利便性を向上させることができる。
【０１４５】  図７を参照して、当該入出力部１６０における一表示例について説明する。図７は、主催者によって各種の情報が入力される情報入力画面の一表示例を示す図である。
【０１４６】  図７に示す表示画面３１０は、例えば図３に示す入出力部１６０の表示画面に対応している。主催者は、当該表示画面３１０を介して各種の情報をシステム１に入力することができる。なお、図７に示す表示画面３１０は、主催者に提供される情報入力画面のあくまで一例であり、当該情報入力画面は他の構成を有していてもよい。
【０１４７】  図７を参照すると、表示画面３１０は、主にイベント情報が登録される領域３１１、主にチケットの販売サイトについての情報が登録される領域３１２及びユーザに提示されるイベントの広告についての情報が登録される領域３１３に分割される。
【０１４８】  領域３１１では、例えば、イベントの名称（タイトル）、イベントの出演者（アーティスト）、イベントの会場、イベントの開催日時等の情報を、ドロップダウンリスト形式で入力することができる。これらの情報は、イベントメタ情報として、例えば図３に示すイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に登録される。なお、領域３１１及び後述する他の領域３１２、３１３において、情報の入力形式はドロップダウンリスト形式に限定されず、各種の情報は直接テキストで入力されてもよい。また、領域３１１では、例示する項目以外にも、イベントに関する各種の情報が入力されてよい。
【０１４９】  領域３１２では、例えば、チケットの販売サイト名、各販売サイトでのチケット販売開始日時、各販売サイトでのチケット販売終了日時、各販売サイトでのチケット販売地域、各販売サイトでのチケット販売枚数、各販売サイトでのチケット販売戦略等の情報を、プルダウン形式で入力することができる。チケットの販売開始日時、販売終了日時、販売地域、販売枚数についての情報は、イベントメタ情報として、例えば図３に示すイベント管理システムＸ２１０のイベントメタ情報ＤＢ２１２に登録される。また、チケットの販売戦略についての情報は、主催者プロファイル情報として、例えば図３に示す主催者プロファイル情報ＤＢ１４０に登録される。なお、領域３１２では、例示する項目以外にも、販売サイトごとに設定可能な各種の情報が入力されてよい。
【０１５０】  また、領域３１２には、図４に示す販売戦略決定部１３６によって決定された販売戦略についての情報が表示されてもよい。主催者は、当該表示された情報を参考にして、販売戦略情報を入力することができる。また、領域３１２において、表示された販売戦略決定部１３６によって決定された販売戦略を修正することが可能なＧＵＩ（Ｇｒａｐｈｉｃａｌ  Ｕｓｅｒ  Ｉｎｔｅｒｆａｃｅ）が提供されてもよい。
【０１５１】  領域３１３では、例えば、ユーザに対してイベントを提示する際の、広告のレイアウトや、当該レイアウトの変更権を入力することができる。なお、領域３１３では、例示する項目以外にも、イベントの広告に関する各種の情報が入力されてよい。
【０１５２】  以上、図７を参照して、主催者によって各種の情報が入力される情報入力画面の一表示例について説明した。
【０１５３】  （２−５．変形例）  次に、第１の実施形態の一変形例について説明する。上記（２−１．システムの概要）で説明したように、第１の実施形態に係るシステム１は、共通予測エンジン１５０が設けられ、各管理システムにおいてユーザに推薦されるイベントを、当該共通予測エンジン１５０が決定していた。ただし、第１の実施形態に係るシステム１は、かかる例に限定されず、他の構成を取ってもよい。例えば、各管理システムの予測エンジンが、それぞれ、共通予測エンジン１５０として振る舞ってもよい。
【０１５４】  図８を参照して、第１の実施形態の一変形例として、各管理システムに予測エンジンが設けられる変形例について説明する。図８は、各管理システムに予測エンジンが設けられる変形例に係るシステムの概要を示す図である。なお、本変形例に係るシステムは、第１の実施形態に係るシステム１に対して、予測エンジンの構成が変更されたものに対応し、その他の部材の構成及び機能はシステム１と同様である。従って、以下の本変形例についての説明では、第１の実施形態に係るシステム１と重複する事項についてはその詳細な説明を省略し、システム１との相違点について主に説明することとする。
【０１５５】  図８を参照すると、本変形例に係るシステム２では、イベント管理システムＸ２１０によってイベントＸが管理され、イベント管理システムＹ２２０によってイベントＹが管理され、イベント管理システムＺ２３０によってイベントＺが管理されている。また、イベント管理システムＸ２１０は、自身の会員であるＸ会員に対するお薦めのイベントを予測する予測エンジン２６７と、Ｘ会員の購入履歴情報が蓄積されたログ２１８と、を有している。また、イベント管理システムＹ２２０は、自身の会員であるＹ会員に対するお薦めのイベントを予測する予測エンジン２７７と、Ｙ会員の購入履歴情報が蓄積されたログ２２８と、を有している。また、イベント管理システムＺ２３０は、自身の会員であるＺ会員に対するお薦めのイベントを予測する予測エンジン２８７と、Ｚ会員の購入履歴情報が蓄積されたログ２３８と、を有している。ここで、イベント管理システムＸ２１０、イベント管理システムＹ２２０及びイベント管理システムＺ２３０、並びに、ログ２１８、２２８、２３８は、図１に示すこれらの構成と同様の機能を有するものであるため、詳細な説明は省略する。
【０１５６】  システム２は、第１の実施形態に係るシステム１と同様に、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換された、共通化イベントメタ情報を保持している。これにより、各管理システムによって管理されているイベントが、共通化イベントメタ情報として同一のスキーマで管理されることになる。なお、図８では図示を省略しているが、システム２においても、システム１と同様に、イベントメタ情報だけでなく、会員プロファイル情報や空席情報も共通スキーマに変換される。
【０１５７】  ここで、システム１では、各管理システムに横断的にアクセス可能な共通予測エンジン１５０が設けられていた。これに対して、本変形例では、共通予測エンジン１５０は設けられず、各管理システムの予測エンジン２６７、２７７、２８７のそれぞれが、共通予測エンジン１５０と同様の機能を有している。
【０１５８】  具体的には、イベント管理システムＸ２１０の予測エンジン２６７は、ネットワーク２５０を介して他の管理システムのログ２２８、２３８にアクセス可能に構成されている。また、予測エンジン２６７は、共通化イベントメタ情報（及び他の共通化情報）にアクセス可能に構成される。予測エンジン２６７は、図２に示す共通予測エンジン１５０と同様の機能を有しており、共通化イベントメタ情報と、各管理システムのログ２１８、２２８、２３８（すなわち購入履歴情報）に基づいて、推薦するイベントとユーザの組み合わせを決定することができる。詳細な説明は省略するが、他の予測エンジン２７７、２８７も、予測エンジン２６７と同様の機能を有する。
【０１５９】  システム２においても、システム１と同様の効果を得ることができる。すなわち、図１に示す一般的なシステム４では、予測エンジン２１７、２２７、２３７は、イベント管理システムＸ２１０が管理するイベントしか、ユーザに対して推薦することができなかった。しかし、本変形例では、イベントメタ情報が共通のスキーマで一括的に管理されることにより、予測エンジン２６７は、他の管理システムであるイベント管理システムＹ２２０及びイベント管理システムＺ２３０が管理しているイベントも、ユーザに対して推薦すべきイベントとして選択することが可能となる。
【０１６０】  更に、一般的なシステム４では、予測エンジン２１７、２２７、２３７は、自身が設けられた管理システムが管理するログ２１８、２２８、２３８にしかアクセスすることができず、いずれかの管理システムのログ２１８、２２８、２３８に格納された情報に基づいて推薦するイベントとユーザの組み合わせが決定されていた。しかし、本変形例では、予測エンジン２６７、２７７、２８７が、他の管理システムのログ２１８、２２８、２３８に横断的にアクセス可能に構成される。また、予測エンジン２６７、２７７、２８７は、共通化イベントメタ情報を用いることにより、他の管理システムによって管理されているイベントを把握することができる。従って、予測エンジン２６７、２７７、２８７は、他の管理システムのログ２１８、２２８、２３８を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。よって、予測の精度がより向上し、より的確なイベントの推薦が可能となる。
【０１６１】  以上、図８を参照して、第１の実施形態の一変形例として、各管理システムに予測エンジンが設けられる変形例について説明した。以上説明したように、本変形例によれば、各管理システムに設けられた予測エンジンが、共通予測エンジンと同様の役割を果たすことにより、上述したシステム１とは異なる構成によって、システム１と同様の機能を実現することが可能となる。なお、システムの設計者は、例えば各管理システムの構成等に応じて、より簡易にシステムを構成することが可能なように、システム１とシステム２のいずれかの構成を適宜選択することができる。
【０１６２】  （３．第２の実施形態）  次に、第２の実施形態について説明する。上述した第１の実施形態では、共通予測エンジン１５０による処理結果に基づいて、各管理システムにおける会員に対してイベントが推薦されていた。このように、第１の実施形態では、イベントが推薦されるユーザは、いずれかの管理システムの会員に限定されていた。また、共通予測エンジン１５０が予測モデルを生成するために参照する情報も、各管理システムにおけるログ（購入履歴情報）に限定されていた。
【０１６３】  そこで、第２の実施形態では、管理システムの会員に限られない、より多数のユーザに対してイベントを提示するシステムを提案する。また、管理システムの会員に限られないより多数のユーザの行動履歴に基づいて予測モデルを生成可能なシステムを提案する。
【０１６４】  ここで、一般的に、ユーザの行動履歴に基づいて当該ユーザの興味や関心を推測し、ターゲットを絞ってインターネット等を介したデジタル広告を配信する手法（いわゆるターゲティング広告）が知られている。第２の実施形態は、概略的には、第１の実施形態で説明した技術を、当該ターゲティング広告に適用したものに対応する。そこで、以下の第２の実施形態についての説明では、まず、一般的なターゲティング広告に係るシステムについて説明するとともに、第１の実施形態に係るシステム１が、当該システムにおいてどのように適用され得るかについて説明する。その後、ターゲティング広告に係るシステムと第１の実施形態に係るシステム１とが組み合わされて構成される、第２の実施形態に係るシステムの詳細について説明することとする。
【０１６５】  （３−１．ターゲティング広告について）  図９を参照して、一般的なターゲティング広告に係るシステムについて説明する。図９は、一般的なターゲティング広告に係るシステムについて説明するための説明図である。
【０１６６】  図９に示すシステム５において、オーディエンス４５０（ユーザ４５０）は、一般のネットユーザである。ターゲティング広告では、例えば、ユーザ４５０が、メディア４６０（例えばＷｅｂページ等）を訪問する際に、当該メディア４６０内の広告表示領域（広告枠）に、当該ユーザの興味や関心に沿った広告が表示される。
【０１６７】  図９に示す例では、メディア４６０の広告枠に広告を配信する事業者の一例として、アフィリエイト事業者４３１及びＤＳＰ（Ｄｅｍａｎｄ  Ｓｉｄｅ  Ｐｌａｔｆｏｒｍ）事業者４４２を図示している。アフィリエイト事業者４３１及びＤＳＰ事業者４４２には、広告主４１０から、コンテンツ（例えばイベント）の広告データが提供（出稿）されており、アフィリエイト事業者４３１及びＤＳＰ事業者４４２は、当該広告データをメディア４６０の広告枠に配信する。なお、広告データの作成や広告データの出稿は、広告代理店４２０等を介して行われてもよい。また、例えばコンテンツがイベントである場合には、広告主４１０は、当該イベントの主催者であり得る。
【０１６８】  アフィリエイトシステム４３０は、ユーザ４５０が、広告枠に配信された広告を介して、広告主４１０の管理するシステムにおいて会員登録をしたり、広告主４１０の商品を購入したりすることにより、メディア４６０の管理者に報酬が支払われるシステムである。また、ＤＳＰ事業者４４２が属するＲＴＢ（Ｒｅａｌ  Ｔｉｍｅ  Ｂｉｄｄｉｎｇ）システム４４０は、広告主とメディア４６０の管理者との間での広告枠の売買を支援するシステムである。具体的には、ＲＴＢシステム４４０では、メディア４６０の管理者から広告枠を預かり売りに出すＳＳＰ（Ｓｕｐｐｌｙ  Ｓｉｄｅ  Ｐｌａｔｆｏｒｍ）事業者４４１と、広告主４１０から広告データを預かり管理するＤＳＰ事業者４４２との間で、リアルタイムのオークション形式で広告枠の売買が行われ、広告枠を競り落としたＤＳＰ事業者４４２の広告データが当該広告枠に掲載される。アフィリエイト事業者４３１は、より多くのユーザ４５０が配信された広告を介して広告主４１０にアクセスするように、また、ＤＳＰ事業者４４２は、入札価格に比してより効果的な宣伝ができるように、ユーザ４５０の行動傾向や嗜好を考慮したターゲティング広告を好適に行う。
【０１６９】  一般的には、ユーザ４５０のメディア４６０上での行動（例えばＷｅｂサイト上での閲覧、選択（クリック）、コンバージョン（購入や会員登録）等）の履歴が、Ｃｏｏｋｉｅを通じて、ＣｏｏｋｉｅＩＤごとに把握され得る。これは、メディア４６０（Ｗｅｂページ）に、例えばＤＳＰ事業者４４２が、タグ（ＤＳＰタグ４６１）を設置し、当該タグによりＣｏｏｋｉｅＩＤを介してユーザ４５０を同定することにより実現され得る。当該手法はＣｏｏｋｉｅ−Ｓｙｎｃと呼称される。また、広告主４１０が管理しているシステム（例えば図２に示すイベント管理システムＸ２１０）における会員の購入履歴が、Ｐｒｉｖａｔｅ  ＤＭＰ（Ｄａｔａ  Ｍａｎａｇｅｍｅｎｔ  Ｐｌａｔｆｏｒｍ）４７１やＰｕｂｌｉｃ  ＤＭＰ４７２として管理されている。予測エンジン４７０は、ユーザ４５０のメディア４６０上での行動履歴、Ｐｒｉｖａｔｅ  ＤＭＰ４７１内の情報及び／又はＰｕｂｌｉｃ  ＤＭＰ４７２内の情報を用いて、推薦するイベントとユーザの組み合わせを決定することができる。
【０１７０】  予測エンジン４７０は、決定したイベントとユーザの組み合わせについての情報を、ＤＳＰ事業者４４２及び／又はアフィリエイト事業者４３１に提供する。これにより、ＤＳＰ事業者４４２及び／又はアフィリエイト事業者４３１によって、よりユーザ４５０の嗜好に合った、適切なイベントの広告が配信されることとなる。また、予測エンジン４７０は、決定したイベントとユーザの組み合わせについての情報を、ＳＳＰ事業者４４１に提供してもよい。これにより、ＳＳＰ事業者４４１は、より高い入札価格で広告枠が購入されるように広告枠を設置するＷｅｂサイトを選定する等、広告枠を売却する戦略を立てることができる。
【０１７１】  以上、一般的なターゲティング広告に係るシステム５について説明した。
【０１７２】  ここで、上述したように、本開示の第２の実施形態では、第１の実施形態に係るシステム１を、図９に示すシステム５に適用するものである。第１の実施形態で説明したログ２１８、２２８、２３８及び購入履歴情報ＤＢ２１５は、図９に示すＰｒｉｖａｔｅ  ＤＭＰ４７１に対応し得るものである。また、広告主４１０は、イベントの主催者に対応し得る。一方、第１の実施形態では、イベントメタ情報を共通化し、互いに異なる管理システムによって管理されているログ２１８、２２８、２３８を総合的に用いることにより、予測エンジンの予測精度を向上させることができた。従って、本開示の第２の実施形態では、第１の実施形態に係るシステム１を、図９に示すシステム５に適用することにより、互いに異なる管理システムによって管理されているログ２１８、２２８、２３８（すなわちＰｒｉｖａｔｅ  ＤＭＰ４７１）と、ユーザ４５０のメディア４６０上での行動履歴と、を総合的に用いた、更に高精度な予測エンジンを提供することができる。また、第２の実施形態では、イベントの広告が配信されるユーザが、管理システムの会員に限定されず、広告の配信の対象を一般のネットユーザにまで拡張することが可能となる。
【０１７３】  以下では、このような第２の実施形態に係るシステムについて詳細に説明する。なお、以下の第２の実施形態についての説明では、予測エンジンの処理結果に基づいて、ＤＳＰ事業者によって広告が配信される場合について説明する。ただし、第２の実施形態はかかる例に限定されず、広告を配信する業者は、例えば上述したアフィリエイト事業者のような、他の業者であってもよい。
【０１７４】  （３−２．システムの概要）  図１０を参照して、第２の実施形態に係るシステムの概要について説明する。図１０は、第２の実施形態に係るシステムの概要について説明するための説明図である。なお、第２の実施形態に係るシステムのより詳細な構成については、下記（３−３．システムの構成）で詳しく説明する。なお、以下の第２の実施形態についての説明では、第１の実施形態と実質的に同様の構成についてはその詳細な説明を省略し、第１の実施形態との相違点について主に説明することとする。
【０１７５】  図１０を参照すると、第２の実施形態に係るシステム３では、イベント管理システムＸ６１０によってイベントＸが管理され、イベント管理システムＹ６２０によってイベントＹが管理され、イベント管理システムＺ６３０によってイベントＺが管理されている。また、イベント管理システムＸ６１０は、自身の会員であるＸ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ  ＤＭＰ６１８を有している。また、イベント管理システムＹ６２０は、自身の会員であるＹ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ  ＤＭＰ６２８を有している。また、イベント管理システムＺ６３０は、自身の会員であるＺ会員の購入履歴情報が蓄積されたＰｒｉｖａｔｅ  ＤＭＰ６３８と、を有している。ここで、Ｐｒｉｖａｔｅ  ＤＭＰ６１８、６２８、６３８は、図３に示すログ２１８、２２８、２３８と略同様の機能を有するものである。
【０１７６】  システム３においても、第１の実施形態に係るシステム１と同様に、イベントＸのイベントメタ情報、イベントＹのイベントメタ情報及びイベントＺのイベントメタ情報が、共通のスキーマに変換され、共通化イベントメタ情報が保持される。これにより、各管理システムによって管理されているイベントが、共通化イベントメタ情報として同一のスキーマで管理されることになる。なお、図１０では図示を省略しているが、システム３においても、システム１と同様に、イベントメタ情報だけでなく、会員プロファイル情報や空席情報も共通スキーマに変換される。
【０１７７】  また、システム３は、Ａｄ  Ｌｏｇ  ＤＢ５６０を備える。Ａｄ  Ｌｏｇ  ＤＢ５６０は、Ｗｅｂサイト上でのユーザの行動履歴情報が蓄積されるデータベースである。Ａｄ  Ｌｏｇ  ＤＢ５６０では、ユーザがＣｏｏｋｉｅＩＤによって管理されている。
【０１７８】  共通予測エンジン５７０は、各管理システムによってそれぞれ管理されているＰｒｉｖａｔｅ  ＤＭＰ６１８、６２８、６３８に横断的にアクセス可能であるとともに、上述した共通化イベントメタ情報と、Ａｄ  Ｌｏｇ  ＤＢ５６０と、にアクセス可能に構成される。共通予測エンジン５７０は、Ｐｒｉｖａｔｅ  ＤＭＰ６１８、６２８、６３８内の購入履歴情報、共通化イベントメタ情報、及びＡｄ  Ｌｏｇ  ＤＢ５６０内のユーザの行動履歴情報に基づいて、推薦するイベントとユーザの組み合わせを決定する。
【０１７９】  第１の実施形態と同様に、第２の実施形態においても、共通化イベントメタ情報を用いることにより、共通予測エンジン５７０が、他の管理システムのＰｒｉｖａｔｅ  ＤＭＰ６１８、６２８、６３８を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。従って、共通予測エンジン５７０による予測処理の精度がより向上し、より的確なイベント及びユーザのマッチングが可能となる。ただし、第２の実施形態では、Ａｄ  Ｌｏｇ  ＤＢ５６０内のユーザの行動履歴情報も、更に、共通予測エンジン５７０による予測処理に用いられる。
【０１８０】  ここで、各管理システムにおいては、ユーザは、各管理システムに登録された会員として、ユーザＩＤによって管理されている。一方、上述したように、Ａｄ  Ｌｏｇ  ＤＢ５６０では、ユーザは、ＣｏｏｋｉｅＩＤによって管理されている。従って、第２の実施形態では、各会員のＣｏｏｋｉｅＩＤを同定し、ユーザをＣｏｏｋｉｅＩＤによって一括して管理する。これにより、ユーザの管理システム上での行動（チケット購入等）と、Ｗｅｂサイト上での行動（Ｗｅｂサイトの閲覧やリンクの選択等）とが、ＣｏｏｋｉｅＩＤによって結び付けられることとなる。このように、第２の実施形態では、ユーザは、好適にＣｏｏｋｉｅＩＤによって管理され得る。第１の実施形態におけるユーザＩＤは、第２の実施形態では、ＣｏｏｋｉｅＩＤに読み替えることができる。
【０１８１】  上記のような会員のＣｏｏｋｉｅＩＤの同定は、例えばＣｏｏｋｉｅ−Ｓｙｎｃと呼ばれる手法を用いて実現され得る。Ｃｏｏｋｉｅ−Ｓｙｎｃでは、例えば、同定を行う主体が、Ｗｅｂサイトにタグを埋め込むことにより、当該Ｗｅｂサイトを訪問したユーザのブラウザに対して所定のＣｏｏｋｉｅが設定される。設定されたＣｏｏｋｉｅを介して、例えば当該ユーザが他のＷｅｂサイトを訪問した場合であっても、当該ユーザが一意に特定されることとなる。
【０１８２】  なお、Ｃｏｏｋｉｅ−Ｓｙｎｃは、一般的に広く用いられている手法である。例えば、上記（３−１．ターゲティング広告について）で説明したように、ターゲティング広告を行うために、ＤＳＰ業者がＷｅｂサイトにタグを埋め込み、Ｃｏｏｋｉｅ−Ｓｙｎｃを用いてユーザを特定し、当該ユーザの行動履歴から、その興味や関心を推定することが一般的に行われている。例えば、第２の実施形態では、ＤＳＰ業者が設置したタグを用いて、Ｃｏｏｋｉｅ−Ｓｙｎｃを行うことにより、会員のＣｏｏｋｉｅＩＤを同定することができる。このように、既存のタグを利用することにより、タグを新たに設置する必要がなくなり、より低コストでシステム３を構築することが可能となる。なお、上記のように、Ｃｏｏｋｉｅ−Ｓｙｎｃは、一般的に広く用いられている手法であるため、ここでは、Ｃｏｏｋｉｅ−Ｓｙｎｃについての詳細な説明は割愛する。
【０１８３】  例えば、Ｘ会員が、イベント管理システムＸ６１０を利用して、あるイベントのチケットを購入したとする。すると、当該Ｘ会員のＣｏｏｋｉｅＩＤが、Ｃｏｏｋｉｅ−Ｓｙｎｃを用いて同定される。これにより、Ｗｅｂサイト上でのＸ会員（図中ユーザ５９０ａ）の行動履歴が特定され得る。
【０１８４】  同様にして、他のユーザの管理システム上での行動及びＷｅｂサイト上での行動も、ＣｏｏｋｉｅＩＤによって結び付けられて把握される。例えば、ユーザ５９０ａとは異なるユーザ５９０ｂが、イベント管理システムＸ６１０を利用して、あるイベントのチケットを購入したとする。当該ユーザ５９０ｂのチケットの購入履歴情報は、Ｐｒｉｖａｔｅ  ＤＭＰ６１８に格納される。また、当該ユーザ５９０ｂのＷｅｂサイト上での行動履歴情報は、Ａｄ  Ｌｏｇ  ＤＢ５６０に格納される。同様に、イベント管理システムＹ６２０を利用してあるイベントのチケットを購入したユーザ５９０ｃのチケットの購入履歴情報がＰｒｉｖａｔｅ  ＤＭＰ６２８に格納されるとともに、当該ユーザ５９０ｃのＷｅｂサイト上での行動履歴情報がＡｄ  Ｌｏｇ  ＤＢ５６０に格納される。また、イベント管理システムＺ６３０を利用してあるイベントのチケットを購入したユーザ５９０ｄのチケットの購入履歴情報がＰｒｉｖａｔｅ  ＤＭＰ６３８に格納されるとともに、当該ユーザ５９０ｄのＷｅｂサイト上での行動履歴情報がＡｄ  Ｌｏｇ  ＤＢ５６０に格納される。
【０１８５】  従って、共通予測エンジン５７０は、Ｐｒｉｖａｔｅ  ＤＭＰ６１８、６２８、６３８に格納されている管理システム上での購入履歴情報と、Ａｄ  Ｌｏｇ  ＤＢ５６０に格納されているＷｅｂサイト上での行動履歴情報と、を参照することにより、あるユーザの購入履歴情報及び行動履歴情報を総合的に用いて、推薦するイベントとユーザの組み合わせを決定することができる。よって、共通予測エンジン５７０による予測処理の精度が更に向上するのである。
【０１８６】  共通予測エンジン５７０によって決定されたイベントとユーザの組み合わせに基づいて、当該ユーザに対して当該イベントが提示される。ここで、第２の実施形態では、Ａｄ  Ｌｏｇ  ＤＢ５６０内の行動履歴情報も用いてイベントを推薦するユーザが決定されるため、当該ユーザは、必ずしもいずれかの管理システムの会員とは限らない。例えば、共通予測エンジン５７０が、あるイベントを推薦すべきユーザを選択した結果、行動履歴情報に基づいて、非会員であるユーザの中から、当該イベントに興味を抱いていることが推測されるユーザが抽出される可能性もある。このように、第２の実施形態では、管理システムの会員でないユーザにまで、イベントを推薦する対象を拡張することができ、商材の購入を更に促すことが可能となる。
【０１８７】  ここで、第１の実施形態では、各管理システムにおけるユーザＩＤによってユーザを管理していたため、同一のユーザが互いに異なる管理システムの会員として登録され、複数のユーザＩＤを有している場合には、当該ユーザは、ユーザＩＤごとに別人として扱われる。しかしながら、第２の実施形態では、ＣｏｏｋｉｅＩＤによってユーザが管理されるため、同一のユーザが互いに異なる管理システムの会員として登録されている場合であっても、当該ユーザが一意に同定され得る。従って、推薦するイベントとユーザとのマッチングを行う際に、同一のユーザを複数回マッチングしてしまう事態が回避され、より効率的な広告の配信が実現され得る。
【０１８８】  以上、図１０を参照して、第２の実施形態に係るシステム３の概要について説明した。以上説明したように、第２の実施形態によれば、各管理システムにおけるＰｒｉｖａｔｅ  ＤＭＰ（購入履歴情報）だけでなく、Ｗｅｂサイト上での行動履歴情報まで参照して、推薦するイベントとユーザの組み合わせが決定される。その際、例えば管理システムにおけるユーザ（会員）と、Ｗｅｂサイトを利用しているユーザとが、例えばＣｏｏｋｉｅＩＤを介して結び付けられているため、共通予測エンジン５７０は、当該購入履歴情報と当該行動履歴情報とを総合的に用いて、当該ユーザの嗜好を解析し、イベントとのマッチングを行うことができる。従って、より精度の高いマッチングが実現され得る。
【０１８９】  また、第２の実施形態では、管理システムの会員でないユーザも、イベントの推薦対象として選択され得る。従って、イベントが推薦される対象を拡張することができ、当該イベントのチケットの販売をより促すことができる。
【０１９０】  （３−３．システムの構成）  図１１及び図１２を参照して、以上説明した第２の実施形態に係るシステム３の構成についてより詳細に説明する。図１１は、第２の実施形態に係るシステム３の一構成例を示すブロック図である。図１２は、図１１に示す推薦部５３０の機能構成の一例を示す機能ブロック図である。
【０１９１】  図１１を参照すると、第２の実施形態に係るシステム３は、情報処理装置５０と、イベント管理システムＸ６１０と、イベント管理システムＹ６２０と、イベント管理システムＺ６３０と、主催者プロファイル情報ＤＢ１４０と、入出力部１６０と、Ａｄ  Ｌｏｇ  ＤＢ５６０と、を備える。ここで、イベント管理システムＸ６１０、イベント管理システムＹ６２０及びイベント管理システムＺ６３０は、それぞれ、図１０に示すイベント管理システムＸ６１０、イベント管理システムＹ６２０及びイベント管理システムＺ６３０に対応するものである。また、Ａｄ  Ｌｏｇ  ＤＢ５６０は、図１０に示すＡｄ  Ｌｏｇ  ＤＢ５６０に対応据えるものである。なお、主催者プロファイル情報ＤＢ１４０及び入出力部１６０は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
【０１９２】  なお、図１１では、一例として、イベント管理システムＸ６１０の構成を詳細に図示しているが、他の管理システムであるイベント管理システムＹ６２０及びイベント管理システムＺ６３０も同様の構成であり得る。また、以下では、イベント管理システムＸ６１０における処理について説明するために、イベント管理システムＸ６１０の会員であるユーザとイベント管理システムＸ６１０との間で実行される処理について説明するが、イベント管理システムＹ６２０とイベント管理システムＹ６２０の会員との間においても同様の処理が実行され得るし、イベント管理システムＺ６３０とイベント管理システムＺ６３０の会員との間においても同様の処理が実行され得る。
【０１９３】  （Ａｄ  Ｌｏｇ  ＤＢ５６０）  Ａｄ  Ｌｏｇ  ＤＢ５６０は、Ｗｅｂサイト上でのユーザの行動履歴情報を格納する。行動履歴情報には、メディア（例えばＷｅｂサイト）上でユーザが行ったあらゆる行動についての情報が含まれる。例えば、行動履歴情報には、ユーザが閲覧したＷｅｂサイトについての情報、ユーザがＷｅｂサイト上で選択したリンクについての情報、ユーザのＷｅｂサイト上でのコンバージョン（例えば商品の購入、会員登録等）についての情報等が含まれる。Ａｄ  Ｌｏｇ  ＤＢ５６０では、行動履歴情報は、ＣｏｏｋｉｅＩＤによって管理されている。なお、行動履歴情報を取得する具体的な方法については、下記（３−４．行動履歴情報の取得方法の具体例）で改めて詳しく説明する。
【０１９４】  （イベント管理システムＸ６１０）  イベント管理システムＸ６１０は、その機能として、チケット販売システム２１１と、イベントメタ情報ＤＢ２１２と、空席情報ＤＢ２１３と、会員プロファイル情報ＤＢ２１４と、購入履歴情報ＤＢ２１５と、を有する。購入履歴情報ＤＢ２１５は、図１０に示すＰｒｉｖａｔｅ  ＤＭＰ６１８に対応するものである。なお、チケット販売システム２１１、イベントメタ情報ＤＢ２１２、空席情報ＤＢ２１３、会員プロファイル情報ＤＢ２１４及び購入履歴情報ＤＢ２１５は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
【０１９５】  （情報処理装置５０）  情報処理装置５０は、その機能として、スキーマ変換部１１０と、共通化イベントメタ情報ＤＢ１２１と、共通化空席情報ＤＢ１２２と、共通化会員プロファイル情報ＤＢ１２３と、推薦部５３０と、提示制御部１７０と、を有する。なお、スキーマ変換部１１０、推薦部５３０及び提示制御部１７０は、例えばＣＰＵやＤＳＰ等の各種のプロセッサによって構成され、スキーマ変換部１１０、推薦部１３０及び提示制御部１７０の機能は、当該プロセッサが所定のプログラムに従って動作することによって実現され得る。また、スキーマ変換部１１０、提示制御部１７０、共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３は、図３に示すこれらの構成と、それぞれ同様の機能を有するものであるため、その詳細な説明は省略する。
【０１９６】  推薦部５３０は、共通化イベントメタ情報と、購入履歴情報と、行動履歴情報と、に基づいて、推薦するイベントとユーザの組み合わせを決定する。推薦部５３０は、図１０に示す共通予測エンジン５７０に対応する機能を有する。
【０１９７】  推薦部５３０における、共通化情報及び購入履歴情報の利用方法は、第１の実施形態における推薦部１３０と同様である。すなわち、推薦部５３０は、購入履歴情報ＤＢ２１５内の購入履歴情報を共通化イベントメタ情報に紐付けることにより、各管理システムの購入履歴情報を総合的に利用して、推薦するイベントとユーザの組み合わせを選択するための予測モデルを生成する。更に、第２の実施形態では、推薦部５３０は、購入履歴情報に含まれるユーザＩＤと、Ａｄ  Ｌｏｇ  ＤＢ５６０内の行動履歴情報に含まれるＣｏｏｋｉｅＩＤとを、例えばＣｏｏｋｉｅ−Ｓｙｎｃ等の手法により紐付けることにより、同一のユーザの購入履歴情報と行動履歴情報とを結び付けることが可能となる。従って、推薦部５３０は、例えばあるイベントのチケットを購入したユーザが、Ｗｅｂサイト上ではどのような行動をとっているかを把握することが可能となる。推薦部５３０は、このようにユーザが同定された購入履歴情報及び行動履歴情報の双方を用いて、推薦するイベントとユーザの組み合わせを決定する。よって、より高精度な推薦処理が実現される。
【０１９８】  また、推薦部５３０は、第１の実施形態における推薦部１３０と同様に、販売戦略を決定する機能を有する。ただし、推薦部５３０は、共通化イベントメタ情報及び購入履歴情報だけでなく、行動履歴情報を更に用いて販売戦略を決定することができる。従って、より的確な販売戦略が決定され得る。
【０１９９】  推薦部５３０によって選択されたイベント及びユーザについての情報は、ＤＳＰ事業者５５０に提供される。ＤＳＰ事業者５５０は、図９に示すＤＳＰ事業者４４２に対応する。選択されたユーザのブラウザもＣｏｏｋｉｅＩＤで特定され得るため、ＤＳＰ事業者４４２は、選択されたユーザが使用しているＷｅｂブラウザ上に設けられた広告枠をＲＴＢによって競り落とし、落札した広告枠に選択されたイベントの広告を表示させる。このように、第２の実施形態では、不特定多数のネットユーザに対して、イベントを提示することができる。従って、イベントが推薦される対象範囲がより拡大され、チケットの購入が促進される。
【０２００】  ここで、図１２を参照して、推薦部５３０の機能構成についてより詳細に説明する。図１２を参照すると、推薦部５３０は、その機能として、主催者プロファイル情報取得部１３１と、共通化情報取得部１３２と、購入履歴情報取得部１３３と、行動履歴情報取得部５３６と、予測モデル生成部５３４と、イベント−ユーザ決定部５３５と、販売戦略決定部５３７と、を有する。ここで、図１２では、説明のため、推薦部５３０と情報をやり取りする構成として、主催者プロファイル情報ＤＢ１４０、共通化情報ＤＢ１２０、購入履歴情報ＤＢ２１５、Ａｄ  Ｌｏｇ  ＤＢ５６０及び提示制御部１７０を併せて図示している。なお、図４と同様に、共通化情報ＤＢ１２０は、図１１に示す共通化イベントメタ情報ＤＢ１２１、共通化空席情報ＤＢ１２２及び共通化会員プロファイル情報ＤＢ１２３を併せて１つのブロックとして図示したものである。また、推薦部５３０の機能のうち、主催者プロファイル情報取得部１３１、共通化情報取得部１３２及び購入履歴情報取得部１３３の機能は、図４に示すこれらの構成の機能と同様であるため、その詳細な説明は省略する。
【０２０１】  行動履歴情報取得部５３６は、Ａｄ  Ｌｏｇ  ＤＢ５６０から行動履歴情報を取得する。行動履歴情報取得部５３６は、取得した行動履歴情報を、予測モデル生成部５３４、イベント−ユーザ決定部５３５及び販売戦略決定部５３７に提供する。
【０２０２】  販売戦略決定部５３７は、共通化イベントメタ情報と、各管理システムにおける購入履歴情報と、行動情報と、に基づいて、イベントの販売戦略を決定する。第２の実施形態では、各管理システムの購入履歴情報ＤＢ２１５の購入履歴情報がイベントメタ情報によって紐付けられ、購入履歴情報に含まれるユーザＩＤと、Ａｄ  Ｌｏｇ  ＤＢ５６０内の行動履歴情報に含まれるＣｏｏｋｉｅＩＤとが、例えばＣｏｏｋｉｅ−Ｓｙｎｃ等の手法により紐付けられる。従って、販売戦略決定部５３７は、各管理システムにおける購入履歴情報及び行動履歴情報を総合的に用いて、販売戦略を決定することができる。なお、販売戦略決定部５３７の機能は、行動履歴情報を更に用いること以外は、第１の実施形態における販売戦略決定部１３６の機能と同様であるため、その詳細な説明は省略する。
【０２０３】  第１の実施形態と同様に、販売戦略決定部５３７は、決定した販売戦略についての情報を、提示制御部１７０に提供する。当該販売戦略についての情報は、提示制御部１７０によって、入出力部１６０を介して主催者に対して提示される。主催者は、提示された情報を参考にして、最終的な販売戦略を決定し、主催者プロファイル情報として、主催者プロファイル情報ＤＢ１４０に入力することができる。
【０２０４】  予測モデル生成部５３４は、共通化イベントメタ情報と、購入履歴情報と、行動履歴情報と、に基づいて、推薦するイベントとユーザとの組み合わせを選択するための予測モデルを生成する。上述したように、各管理システムにおける購入履歴情報及び行動履歴情報が、互いに紐付けられているため、予測モデル生成部５３４は、これらの情報を総合的に用いて予測モデルを生成することができる。
【０２０５】  なお、予測モデル生成部５３４の機能は、行動履歴情報を更に用いること以外は、第１の実施形態における予測モデル生成部１３４の機能と同様であるため、その詳細な説明は省略する。予測モデル生成部５３４が生成する予測モデルの種類は、図４に示す予測モデル生成部１３４が生成する予測モデルと同様であってよい。また、予測モデル生成部５３４も、図４に示す予測モデル生成部１３４と同様に、販売履歴情報や、ユーザの行動傾向情報等に更に基づいて、予測モデルを生成することができる。予測モデル生成部５３４は、生成した予測モデルを、イベント−ユーザ決定部５３５に提供する。
【０２０６】  イベント−ユーザ決定部５３５は、生成された予測モデルに基づいて、推薦するイベントとユーザの組み合わせを決定する。イベント−ユーザ決定部５３５が行う処理は、図４に示す予測モデル生成部１３４と略同様であるため、その詳細な説明は省略する。ただし、第２の実施形態では、イベント−ユーザ決定部５３５は、管理システムの会員だけでなく、行動履歴情報が取得されている不特定多数のユーザまで候補に含めて、イベントを推薦するユーザを選択することができる。
【０２０７】  イベント−ユーザ決定部５３５は、選択したイベント及びユーザの組み合わせについての情報を、ＤＳＰ事業者５５０に提供する。ＤＳＰ事業者５５０によって、例えば選択されたユーザのＷｅｂブラウザ上の広告枠に、選択されたイベントの広告が表示される。
【０２０８】  以上、図１１及び図１２を参照して、第２の実施形態に係るシステム３の構成について説明した。以上説明したように、第２の実施形態によれば、第１の実施形態の構成に加えて、更に、メディア上でのユーザの行動を表す行動履歴情報が取得される。購入履歴情報に含まれるユーザＩＤと、行動履歴情報に含まれるＣｏｏｋｉｅＩＤとは、例えばＣｏｏｋｉｅ−Ｓｙｎｃ等の手法により紐付けることができるため、同一のユーザの購入履歴情報と行動履歴情報とを結び付けることが可能となる。従って、第２の実施形態では、各管理システムの購入履歴情報と行動履歴情報とを総合的に扱うことができ、予測エンジンの精度を更に向上させることができる。また、イベントを推薦する対象が、管理システムの会員だけでなく、行動履歴情報が取得されている不特定多数のユーザにまで拡張されるため、より多くのユーザに対して広告を配信することが可能となる。従って、イベントのチケットの売り上げがより促進され、主催者にとって利便性の高いシステムが実現され得る。また、ユーザにとっても、より自身の嗜好に合ったイベントが推薦されることとなり、ユーザの利便性も向上される。
【０２０９】  なお、情報処理装置５０の装置構成は、図１１及び図１２に示す例に限定されない。例えば、図１１及び図１２に示す情報処理装置５０の各機能は、必ずしも１つの装置に一体的に搭載されなくてもよい。図１１及び図１２に示す情報処理装置５０に搭載される各機能が、複数の装置に分散されて搭載され、当該複数の装置が通信可能に接続されることにより、情報処理装置５０が構成されてもよい。例えば、各ＤＢは、情報処理装置５０とは異なる外部の機器として備えられてもよく、情報処理装置５０が、外部機器であるこれらＤＢと通信を行いながら、上述した各種の処理を実行してもよい。
【０２１０】  また、上述のような第２の実施形態に係る情報処理装置５０の機能を実現するためのコンピュータプログラムを作製し、パーソナルコンピュータ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリなどである。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信してもよい。
【０２１１】  （３−４．行動履歴情報の取得方法の具体例）  上述したように、第２の実施形態では、Ｗｅｂサイト上でのユーザの行動が、行動履歴情報として取得される。図１３及び図１４を参照して、このような、Ｗｅｂサイト上での行動履歴情報の取得方法の一例について説明する。図１３及び図１４は、行動履歴情報の取得方法について説明するための説明図である。
【０２１２】  図１３には、ユーザが閲覧しているＷｅｂサイト３２０の一例が図示されている。例えば、Ｗｅｂサイト３２０は、あるライブイベントのチケット販売のメインページである。例えば、当該ライブイベントのチケット販売のメインページを閲覧した旨の情報が、行動履歴情報として取得され得る。
【０２１３】  また、Ｗｅｂサイト３２０には、イベントの出演者の画像や、イベントの情報とともに、チケットの販売サイトへのリンク（図中、「販売サイトＸ」、「販売サイトＹ」及び「販売サイトＺ」）が表示されている。ユーザは、実際にチケットを購入する場合には、いずれかの販売サイトのリンクを選択し、対応する販売サイトに移動してからチケットを購入することになる。例えば、ユーザがどの販売サイトのリンクを選択したかについての情報も、行動履歴情報として取得され得る。
【０２１４】  図１４は、チケット販売のメインページとリンク先の販売サイトとの関係を、より概略的に図示するものである。図１４を参照すると、Ｗｅｂサイト３３０は、図１３に示すＷｅｂサイト３２０と同様に、イベントのチケット販売のメインページである。
【０２１５】  Ｗｅｂサイト３３０には、例えば、チケット販売サイトへのリンクとして、自社サイトへのリンク３３１、他の販売サイトＸへのリンク３３２及び更に他の販売サイトＹへのリンク３３３が表示されている。また、Ｗｅｂサイト３３０には、タグ３３４（例えばＤＳＰタグ）が設定されている。ユーザがＷｅｂサイト３３０を閲覧したことや、ユーザがＷｅｂサイト３３０においてリンク３３１、３３２、３３３のいずれかを選択したことは、当該タグ３３４によってＡｄ  Ｌｏｇ  ＤＢ５６０に蓄積される。
【０２１６】  ユーザがリンク３３２を選択した場合には、販売サイトＸのＷｅｂサイト３４０が表示される。Ｗｅｂサイト３４０にも、同様に、タグ３４４が設定されており、当該Ｗｅｂサイト３４０上でのユーザの行動は、当該タグ３４４によってＡｄ  Ｌｏｇ  ＤＢ５６０に蓄積される。
【０２１７】  また、ユーザがリンク３３３を選択した場合には、販売サイトＹのＷｅｂサイト３５０が表示される。Ｗｅｂサイト３５０にも、同様に、タグ３５４が設定されており、当該Ｗｅｂサイト３５０上でのユーザの行動は、当該タグ３５４によってＡｄ  Ｌｏｇ  ＤＢ５６０に蓄積される。
【０２１８】  このように、チケット販売のメインページだけでなく、各チケット販売サイトにタグを設定することにより、ユーザがチケットを購入したという情報だけでなく、ユーザがどの販売サイトでチケットを購入したかまで追跡し、行動履歴情報として取得することが可能となる。このように、リンク先のＷｅｂサイトにまでタグを設定することにより、より詳細な行動履歴情報を取得することが可能となる。
【０２１９】  以上、図１３及び図１４を参照して、Ｗｅｂサイト上での行動履歴情報の取得方法の一例について説明した。なお、上記の例では、チケット販売のメインページ又は各販売サイトにタグが埋め込まれ、当該タグに基づいて、当該チケット販売のメインページ又は当該各販売サイトにおけるユーザの行動情報が取得される場合について説明したが、第２の実施形態はかかる例に限定されない。例えば、あるＷｅｂページへのタグの設置により、当該Ｗｅｂページに移動する前のＷｅｂページ情報（いわゆるリファラーＵＲＬ）を取得することが可能である。第２の実施形態では、タグが設置されたＷｅｂページだけでなく、このような当該Ｗｅｂページに移動する前のＷｅｂページ情報も、ユーザの閲覧履歴情報の一つとして取得されてもよい。また、タグが設置されるＷｅｂページは、広告枠のないＷｅｂページであってもよい。広告枠のないＷｅｂページにタグを設置することにより、より一般的に、幅広く、Ｗｅｂページについてのユーザの閲覧履歴情報を取得することが可能となる。第２の実施形態では、このような、タグが直接設置されていないＷｅｂページについての閲覧履歴情報や、広告枠のないＷｅｂページについての閲覧履歴情報も、ユーザの行動履歴情報として取得され、予測モデルに反映されてもよい。これにより、より高精度にユーザの嗜好を捉えた予測モデルを生成することが可能となる。
【０２２０】  （３−５．情報処理方法）  図１５を参照して、図１１に示すシステム３において実行される、第２の実施形態に係る情報処理方法について説明する。図１５は、第２の実施形態に係る情報処理方法の処理手順の一例を示すフロー図である。なお、以下では、図１１に示すシステム３において、イベント管理システムＸ６１０によって管理されているイベントＳがユーザに対して推薦される場合を例に挙げて、情報処理方法についての説明を行う。
【０２２１】  図１５を参照すると、第２の実施形態に係る情報処理方法では、まず、主催者によって、イベントＳのイベントメタ情報及び主催者プロファイル情報が登録される（ステップＳ２０１）。次に、イベントＳのイベントメタ情報及び空席情報と、管理システムの会員プロファイル情報と、が、共通のスキーマに変換される（ステップＳ２０３）。なお、ステップＳ２０１に示す処理及びステップＳ２０３に示す処理は、図６に示す第１の実施形態に係る情報処理方法のステップＳ１０１に示す処理及びステップＳ１０３に示す処理と、それぞれ同様の処理であるため、その詳細な説明は省略する。
【０２２２】  次に、共通化イベントメタ情報、購入履歴情報及び行動履歴情報に基づいて、販売戦略が決定される（ステップＳ２０４）。当該販売戦略は、例えば、イベントの種類や、過去の同種のイベントの販売実績、イベントＳに関連するＷｅｂページへのユーザの行動等に基づいて決定され得る。ステップＳ２０４に示す処理は、例えば図１１に示す販売戦略決定部５３７によって行われる処理に対応している。
【０２２３】  次に、共通化イベントメタ情報、購入履歴情報及び行動履歴情報に基づいて、予測モデルが生成される（ステップＳ２０５）。当該予測モデルは、例えば、イベントの種類や、ユーザの購入履歴等を考慮して、イベントＳを推薦すべきユーザを予測するためのモデルである。ステップＳ２０５に示す処理は、例えば図１１に示す予測モデル生成部５３４によって行われる処理に対応している。
【０２２４】  次に、生成された予測モデルに基づいて、イベントＳにマッチするユーザが選択される（ステップＳ２０７）。ステップＳ２０７に示す処理は、例えば図１１に示すイベント−ユーザ決定部５３５によって行われる処理に対応している。なお、ステップＳ２０７に示す処理において選択されるユーザは、いずれかの管理システムの会員に限定されず、行動履歴情報が取得されている不特定多数のユーザであり得る。
【０２２５】  次に、イベントＳと選択されたユーザについての情報が、ＤＳＰ事業者５５０に提供される（ステップＳ２０９）。そして、選択されたユーザが広告枠の存在するＷｅｂサイトに訪れた際に、ＤＳＰ事業者５５０によってＲＴＢが実施される（ステップＳ２１１）。
【０２２６】  広告枠を落札できた場合には、ＤＳＰ事業者５５０は、当該広告枠にイベントＳの広告を表示させる（ステップＳ２１３）。これにより、選択されたユーザに対して、推薦すべきイベントＳが提示されることになる。
【０２２７】  次に、ユーザのＷｅｂサイト上での行動が、当該Ｗｅｂサイトに設定されたタグによって、Ａｄ  Ｌｏｇ  ＤＢ５６０に送信される（ステップＳ２１５）。これにより、Ａｄ  Ｌｏｇ  ＤＢ５６０に行動履歴情報が蓄積され、また、Ａｄ  Ｌｏｇ  ＤＢ５６０内の行動履歴情報が更新される。例えば、当該Ｗｅｂサイト上での行動は、表示されたイベントＳの広告に対する行動である。ただし、ステップＳ２１５に示す処理では、選択されたユーザの当該イベントＳの広告に対する行動だけでなく、Ｗｅｂサイト上でのあらゆるユーザのあらゆる行動が、行動履歴情報として取得され得る。
【０２２８】  次に、ユーザの購入行動に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の当該ユーザの購入履歴情報が更新される（ステップＳ２１７）。なお、ステップＳ２１７に示す処理では、ユーザが、提示されたイベントＳの広告を見てイベントＳのチケットを購入した場合はもちろんのこと、ユーザの他の購入行動も、空席情報ＤＢ２１３内の空席情報及び購入履歴情報ＤＢ２１５内の購入履歴情報に反映され得る。
【０２２９】  次に、オフラインでの購入実績に応じて、空席情報ＤＢ２１３内のイベントＳの空席情報、及び購入履歴情報ＤＢ２１５内の当該ユーザの購入履歴情報が更新される（ステップＳ２１９）。ステップＳ２１９に示す処理は、図６に示す第１の実施形態に係る情報処理方法のステップＳ１１５に示す処理と同様の処理であるため、その詳細な説明は省略する。
【０２３０】  なお、図１５では、便宜的に、ステップＳ２１５に示す処理、ステップＳ２１７に示す処理及びステップＳ２１９に示す処理をこの順序で図示しているが、これらの処理は、システム３において随時実行される処理であるため、その順序は任意であってよい。
【０２３１】  ステップＳ２１９に示す処理が終了すると、ステップＳ２０３に戻り、更新された空席情報、購入履歴情報及び行動履歴情報に基づいて、ステップＳ２０３以降の処理が繰り返し実行される。なお、図１５に示すフロー図では明示していないが、実際には、例えば売り上げ実績に応じた主催者プロファイル情報内の販売戦略情報の変更や、新規会員の登録及び既存会員の退会等による会員プロファイル情報の変更、イベント内容の変更に伴うイベントメタ情報の変更等も随時行われ得る。図１５に示すフローにおいては、このような主催者プロファイル情報、イベントメタ情報及び会員プロファイル情報の変更も適宜実行されてよい。その場合、変更されたこれらの情報に基づいて、各ステップに示す処理が実行され得る。また、第１の実施形態と同様に、ステップＳ２０５に示す予測モデルの生成処理は、図１５に示す一連の処理が実行される際に、毎回行われなくてもよい。例えば、１週間に１度、あるいは一定量の購入履歴情報が更新されたタイミングで、ステップＳ２０５に示す処理が行われ、予測モデルが更新されてもよい。
【０２３２】  以上、図１５を参照して、第２の実施形態に係る情報処理方法について説明した。
【０２３３】  （４．ハードウェア構成）  次に、図１６を参照して、第１及び第２の実施形態に係る情報処理装置のハードウェア構成について説明する。図１６は、第１及び第２の実施形態に係る情報処理装置のハードウェア構成の一例を示す機能ブロック図である。なお、図１６に示す情報処理装置９００は、例えば、図３及び図１１に示す情報処理装置１０、５０を実現し得る。
【０２３４】  情報処理装置９００は、ＣＰＵ９０１、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）９０３及びＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）９０５を備える。また、情報処理装置９００は、ホストバス９０７、ブリッジ９０９、外部バス９１１、インターフェース９１３、入力装置９１５、出力装置９１７、ストレージ装置９１９、通信装置９２１、ドライブ９２３及び接続ポート９２５を備えてもよい。情報処理装置９００は、ＣＰＵ９０１に代えて、又はこれとともに、ＤＳＰ若しくはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ  Ｓｐｅｃｉｆｉｃ  Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）と呼ばれるような処理回路を有してもよい。
【０２３５】  ＣＰＵ９０１は、演算処理装置及び制御装置として機能し、ＲＯＭ９０３、ＲＡＭ９０５、ストレージ装置９１９又はリムーバブル記録媒体９２９に記録された各種のプログラムに従って、情報処理装置９００内の動作全般又はその一部を制御する。ＲＯＭ９０３は、ＣＰＵ９０１が使用するプログラムや演算パラメータ等を記憶する。ＲＡＭ９０５は、ＣＰＵ９０１の実行において使用するプログラムや、その実行時のパラメータ等を一次記憶する。ＣＰＵ９０１、ＲＯＭ９０３及びＲＡＭ９０５は、ＣＰＵバス等の内部バスにより構成されるホストバス９０７により相互に接続されている。更に、ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス９１１に接続されている。ＣＰＵ９０１は、例えば、上述した第１及び第２の実施形態におけるスキーマ変換部１１０、推薦部１３０、５３０及び提示制御部１７０を構成し得る。
【０２３６】  ホストバス９０７は、ブリッジ９０９を介して、ＰＣＩ（Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔ／Ｉｎｔｅｒｆａｃｅ）バス等の外部バス９１１に接続されている。
【０２３７】  入力装置９１５は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ及びレバー等、ユーザによって操作される装置によって構成される。また、入力装置９１５は、例えば、赤外線やその他の電波を利用したリモートコントロール装置（いわゆる、リモコン）であってもよいし、情報処理装置９００の操作に対応した携帯電話やＰＤＡ等の外部接続機器９３１であってもよい。更に、入力装置９１５は、例えば、上記の操作手段を用いてユーザにより入力された情報に基づいて入力信号を生成し、ＣＰＵ９０１に出力する入力制御回路などから構成されている。情報処理装置９００のユーザは、この入力装置９１５を操作することにより、情報処理装置９００に対して各種のデータを入力したり処理動作を指示したりすることができる。第１及び第２の実施形態では、入力装置９１５を介して、情報処理装置１０、５０によって処理される各種の情報が入力されてよい。なお、図３及び図１１に示す入出力部１６０が、情報処理装置１０、５０と一体的に構成される場合には、当該入出力部１６０は、入力装置９１５によって構成され得る。
【０２３８】  出力装置９１７は、取得した情報をユーザに対して視覚的又は聴覚的に通知することが可能な装置で構成される。このような装置として、ＣＲＴディスプレイ装置、液晶ディスプレイ装置、プラズマディスプレイ装置、ＥＬディスプレイ装置及びランプ等の表示装置や、スピーカ及びヘッドホン等の音声出力装置や、プリンタ装置等がある。出力装置９１７は、例えば、情報処理装置９００が行った各種処理により得られた結果を出力する。具体的には、表示装置は、情報処理装置９００が行った各種処理により得られた結果を、テキスト、イメージ、表、グラフ等、様々な形式で視覚的に表示する。他方、音声出力装置は、再生された音声データや音響データ等からなるオーディオ信号をアナログ信号に変換して聴覚的に出力する。本実施形態では、出力装置９１７を介して、情報処理装置１０、５０によって処理される各種の情報が出力されてよい。なお、図３及び図１１に示す入出力部１６０が、情報処理装置１０、５０と一体的に構成される場合には、当該入出力部１６０は、出力装置９１７によって構成され得る。
【０２３９】  ストレージ装置９１９は、情報処理装置９００の記憶部の一例として構成されたデータ格納用の装置である。ストレージ装置９１９は、例えば、ＨＤＤ等の磁気記憶部デバイス、半導体記憶デバイス、光記憶デバイス又は光磁気記憶デバイス等により構成される。このストレージ装置９１９は、ＣＰＵ９０１が実行するプログラムや各種データ及び外部から取得した各種のデータ等を格納する。ストレージ装置９１９は、例えば、上述した第１及び第２の実施形態に係る情報処理装置１０、５０に設けられる各種のＤＢを構成し得る。
【０２４０】  通信装置９２１は、例えば、通信網（ネットワーク）９２７に接続するための通信デバイス等で構成された通信インターフェースである。通信装置９２１は、例えば、有線若しくは無線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）又はＷＵＳＢ（Ｗｉｒｅｌｅｓｓ  ＵＳＢ）用の通信カード等である。また、通信装置９２１は、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ  Ｄｉｇｉｔａｌ  Ｓｕｂｓｃｒｉｂｅｒ  Ｌｉｎｅ）用のルータ又は各種通信用のモデム等であってもよい。この通信装置９２１は、例えば、インターネットや他の通信機器との間で、例えばＴＣＰ／ＩＰ等の所定のプロトコルに則して信号等を送受信することができる。また、通信装置９２１に接続されるネットワーク９２７は、有線又は無線によって接続されたネットワーク等により構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、ラジオ波通信又は衛星通信等であってもよい。上述した第１及び第２の実施形態では、例えば、情報処理装置１０、５０と他の各種の構成（例えば管理システム、入出力部１６０、主催者プロファイル情報ＤＢ１４０、Ａｄ  Ｌｏｇ  ＤＢ５６０等）との間の通信が、通信装置９２１によってネットワーク９２７を介して実行されてよい。
【０２４１】  ドライブ９２３は、記録媒体用リーダライタであり、情報処理装置９００に内蔵、あるいは外付けされる。ドライブ９２３は、装着されている磁気ディスク、光ディスク、光磁気ディスク又は半導体メモリ等のリムーバブル記録媒体９２９に記録されている情報を読み出して、ＲＡＭ９０５に出力する。また、ドライブ９２３は、装着されている磁気ディスク、光ディスク、光磁気ディスク又は半導体メモリ等のリムーバブル記録媒体９２９に情報を書き込むことも可能である。リムーバブル記録媒体９２９は、例えば、ＤＶＤメディア、ＨＤ−ＤＶＤメディア、Ｂｌｕ−ｒａｙ（登録商標）メディア等である。また、リムーバブル記録媒体９２９は、コンパクトフラッシュ（登録商標）（ＣｏｍｐａｃｔＦｌａｓｈ：ＣＦ）、フラッシュメモリ又はＳＤメモリカード（Ｓｅｃｕｒｅ  Ｄｉｇｉｔａｌ  ｍｅｍｏｒｙ  ｃａｒｄ）等であってもよい。また、リムーバブル記録媒体９２９は、例えば、非接触型ＩＣチップを搭載したＩＣカード（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ  ｃａｒｄ）又は電子機器等であってもよい。第１及び第２の実施形態では、例えば情報処理装置１０、５０によって処理される各種の情報が、ドライブ９２３によってリムーバブル記録媒体９２９から読み出されたり、リムーバブル記録媒体９２９に書き込まれたりしてもよい。
【０２４２】  接続ポート９２５は、機器を情報処理装置９００に直接接続するためのポートである。接続ポート９２５の一例として、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ  Ｓｅｒｉａｌ  Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート及びＳＣＳＩ（Ｓｍａｌｌ  Ｃｏｍｐｕｔｅｒ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｆａｃｅ）ポート等がある。接続ポート９２５の別の例として、ＲＳ−２３２Ｃポート、光オーディオ端子及びＨＤＭＩ（登録商標）（Ｈｉｇｈ−Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）ポート等がある。この接続ポート９２５に外部接続機器９３１を接続することで、情報処理装置９００は、外部接続機器９３１から直接各種のデータを取得したり、外部接続機器９３１に各種のデータを提供したりする。第１及び第２の実施形態では、例えば情報処理装置１０、５０によって処理される各種の情報が、接続ポート９２５を介して外部接続機器９３１から取得されたり、外部接続機器９３１に出力されたりしてもよい。
【０２４３】  以上、本実施形態に係る情報処理装置９００の機能を実現可能なハードウェア構成の一例を示した。上記の各構成要素は、汎用的な部材を用いて構成されていてもよいし、各構成要素の機能に特化したハードウェアにより構成されていてもよい。従って、本実施形態を実施する時々の技術レベルに応じて、適宜、利用するハードウェア構成を変更することが可能である。
【０２４４】  なお、上述のような本実施形態に係る情報処理装置９００の各機能を実現するためのコンピュータプログラムを作製し、ＰＣ等に実装することが可能である。また、このようなコンピュータプログラムが格納された、コンピュータで読み取り可能な記録媒体も提供することができる。記録媒体は、例えば、磁気ディスク、光ディスク、光磁気ディスク、フラッシュメモリ等である。また、上記のコンピュータプログラムは、記録媒体を用いずに、例えばネットワークを介して配信されてもよい。
【０２４５】  （５．補足）  以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本開示の技術的範囲はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。
【０２４６】  また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。
【０２４７】  例えば、上記第２の実施形態では、推薦部５３０によって決定されたイベントをユーザに対して提示するＷｅｂサイトの種類は特に限定されていなかったが、本技術はかかる例に限定されない。例えば、推薦するイベントに関連するＷｅｂサイトのＵＲＬが予め定義されており、推薦部５３０は、イベントを推薦する対象であるユーザが、当該Ｗｅｂサイトに訪れたタイミングでＲＴＢを実施し、当該イベントの広告を表示させてもよい。これにより、イベントが提示される媒体も、ユーザの嗜好に合った適切なものが選択されることとなり、広告の誘引力がより増強される。
【０２４８】  また、冒頭で説明したように、上述した第１及び第２の実施形態において扱われるコンテンツは、イベントに限定されず、あらゆるコンテンツであり得る。例えば、当該コンテンツは、オークションにおける出品物や、個人的な転売品等であってもよい。この場合、広告主は事業としてコンテンツの販売を行っている業者ではなく、当該オークションや転売での売り主である個人であり得る。このように、本技術は、個人的にコンテンツを売買するシステムに対しても好適に適用され得る。
【０２４９】  なお、以下のような構成も本開示の技術的範囲に属する。（１）互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換するスキーマ変換部と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する推薦部と、を備える、情報処理装置。（２）前記共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、前記コンテンツの販売戦略を決定する販売戦略決定部、を更に備え、前記推薦部は、前記販売戦略決定部によって決定された販売戦略に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）に記載の情報処理装置。（３）前記コンテンツは、販売期間及び販売数の少なくともいずれかが限定されている定量商材であり、前記販売戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝戦略を含む、前記（２）に記載の情報処理装置。（４）前記宣伝戦略は、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝量、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝時期、前記販売期間及び前記販売数に応じた前記コンテンツの宣伝を行うユーザの属性、及び前記販売期間及び前記販売数に応じた前記コンテンツの宣伝の費用対効果、の少なくともいずれかを含む、前記（３）に記載の情報処理装置。（５）前記販売戦略決定部によって決定された販売戦略を前記コンテンツの売り主に提示するとともに、提示された前記販売戦略に基づいて前記売り主が前記推薦部による決定処理に用いられる販売戦略を指定可能なインターフェースを提供する、提示制御部、を更に備える、前記（２）〜（４）のいずれか１項に記載の情報処理装置。（６）前記推薦部は、提示制御部によって提供されるインターフェースを介して前記コンテンツの売り主によって指定される販売戦略に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（５）に記載の情報処理装置。（７）前記推薦部は、ユーザのコンテンツ購入時の行動傾向を表す行動傾向情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）〜（６）のいずれか１項に記載の情報処理装置。（８）前記推薦部は、前記複数の管理システムのいずれかに登録されている会員を、コンテンツを推薦するユーザとして決定する、前記（１）〜（７）のいずれか１項に記載の情報処理装置。（９）前記スキーマ変換部は、前記推薦部によって決定されたコンテンツについての共通化コンテンツメタ情報を、前記推薦部によって決定されたユーザが会員として登録されている管理システムにおいて販売可能なスキーマに変換する、前記（１）〜（８）のいずれか１項に記載の情報処理装置。（１０）前記推薦部は、メディア上でのユーザの行動を表す行動履歴情報に更に基づいて、推薦するコンテンツとユーザの組み合わせを決定する、前記（１）〜（９）のいずれか１項に記載の情報処理装置。（１１）前記行動履歴情報は、Ｗｅｂサイトを閲覧した旨の情報、Ｗｅｂサイト上のリンクを選択した旨の情報、及びＷｅｂサイト上でのコンバージョン���ついての情報、の少なくともいずれかを含む、前記（１０）に記載の情報処理装置。（１２）前記推薦部は、前記行動履歴情報が取得されたユーザであって、前記複数の管理システムのいずれかに登録されている会員でないユーザを、コンテンツを推薦するユーザとして決定する、前記（１０）又は（１１）に記載の情報処理装置。（１３）前記コンテンツは、席数が限定されているイベントである、前記（１）〜（１２）のいずれか１項に記載の情報処理装置。（１４）プロセッサが、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換することと、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定することと、を含む、情報処理方法。（１５）コンピュータのプロセッサに、互いに異なる複数の管理システムによって管理されているコンテンツメタ情報を、共通のスキーマに変換する機能と、共通のスキーマに変換された共通化コンテンツメタ情報と、各管理システムにおけるコンテンツの購入履歴情報と、に基づいて、推薦するコンテンツとユーザの組み合わせを決定する機能と、を実現させるためのプログラム。
【符号の説明】
【０２５０】  １、２、３    システム  １０、５０    情報処理装置  １１０    スキーマ変換部  １２０    共通化情報ＤＢ  １２１    共通化イベントメタ情報ＤＢ  １２２    共通化空席情報ＤＢ  １２３    共通化会員プロファイル情報ＤＢ  １３０、５３０    推薦部  １３１    主催者プロファイル情報取得部  １３２    共通化情報取得部  １３３    購入履歴情報取得部  １３４、５３４    予測モデル生成部  １３５、５３５    イベント−ユーザ決定部  １３６、５３７    販売戦略決定部  １４０    主催者プロファイル情報ＤＢ  １５０    予測エンジン  １６０    入出力部  １７０    提示制御部  ２１０    イベント管理システムＸ  ２１１    チケット販売システム  ２１２    イベントメタ情報ＤＢ  ２１３    空席情報ＤＢ  ２１４    会員プロファイル情報ＤＢ  ２１５    購入履歴情報ＤＢ  ２１６    推薦イベント提示部  ２２０    イベント管理システムＹ  ２３０    イベント管理システムＺ  ５３６    行動履歴情報取得部  ５６０    ＡＤ  Ｌｏｇ  ＤＢ 
【図１】
2016035424.tif 000003
【図２】
2016035424.tif 000004
【図３】
2016035424.tif 000005
【図４】
2016035424.tif 000006
【図５】
2016035424.tif 000007
【図６】
2016035424.tif 000008
【図７】
2016035424.tif 000009
【図８】
2016035424.tif 000010
【図９】
2016035424.tif 000011
【図１０】
2016035424.tif 000012
【図１１】
2016035424.tif 000013
【図１２】
2016035424.tif 000014
【図１３】
2016035424.tif 000015
【図１４】
2016035424.tif 000016
【図１５】
2016035424.tif 000017
【図１６】
2016035424.tif 000018
【国際調査報告】
2016035424.tif 000019
2016035424.tif 000020
2016035424.tif 000021
2016035424.tif 000022