(57)【特許請求の範囲】
【請求項１】
複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューをユーザが用いる端末に表示させるメニュー生成サーバであって、
前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成する生成部と、
前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付ける受付部と、
受け付けた通知情報を前記共通表示メニューに対して追加する追加部と、
前記通知情報を追加した前記共通表示メニューを前記端末に対して提供する提供部と、
前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数する計数部と、
前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定する設定部と、
を備えるメニュー生成サーバ。
【請求項２】
前記計数部は、前記一のサービスから遷移したサービス毎に当該一のサービスからの前記流出数を計数するとともに、前記一のサービスに遷移したサービス毎に当該一のサービスに対する流入数を計数し、
前記設定部は、前記サービスの夫々に対して計数した、遷移先のサービス毎の流出数に基づいて、前記登録条件又は前記通知態様を設定する、
請求項１に記載のメニュー生成サーバ。
【請求項３】
前記設定部は、第１所定期間に通知する前記通知情報の前記登録条件又は当該第１所定期間の前記通知情報の前記通知態様を、当該第１所定期間よりも前の第２所定期間における前記流出数及び前記流入数に基づいて設定する、
請求項１又は２に記載のメニュー生成サーバ。
【請求項４】
前記設定部は、前記流出数が多い又は前記流入数に対する前記流出数の割合が高い所定数の前記サービスパートナーに対して第１登録条件又は第１通知態様を設定し、前記流出数が少ない又は前記割合が低い所定数の前記サービスパートナーに対して前記第１登録条件又は前記第１通知態様とは異なる第２登録条件又は第２通知態様を設定する、
請求項１から３の何れか１項に記載のメニュー生成サーバ。
【請求項５】
前記追加部は、ユーザが現在提供を受けているサービスの前記流出数又は前記流入数に対する前記流出数の割合に基づいて、前記共通表示メニューに対して前記通知情報を追加するか否かを判定する、
請求項１から４の何れか１項に記載のメニュー生成サーバ。
【請求項６】
前記追加部は、前記流出数又は前記流入数に対する前記流出数の割合が第１閾値を満たさないサービスの提供を受けているユーザから前記要求を受けると、受け付けた前記通知情報のうち、前記流出数又は前記割合が第２閾値を超えるサービスを提供するサービスパートナーの通知情報を、前記共通表示メニューに対して追加する、
請求項１から５の何れか１項に記載のメニュー生成サーバ。
【請求項７】
前記計数部の計数結果に基づいて、前記複数のサービスの夫々を、第１サービス及び当該第１サービスを遷移元とした場合の前記流入数又は当該サービスにおける総流入数に対する前記第１サービスを遷移元とした場合の前記流入数の割合が第３閾値を超える第２サービスを含む第１サービスグループと、前記第１サービスグループに含まれるサービスを遷移元とした場合の前記流入数又は当該サービスにおける総流入数に対する前記第１サービスグループに含まれるサービスを遷移元とした場合の前記流入数の割合が第４閾値を満たさない第３サービスを含む第２サービスグループと、に分類する分類部、を更に備え、
前記追加部は、前記第２サービスグループに含まれるサービスの提供を受けているユーザから前記要求を受けると、受け付けた前記通知情報のうち、前記第１サービスグループに含まれるサービスを提供するサービスパートナーの通知情報を、前記共通表示メニューに対して追加する、
請求項１から６の何れか１項に記載のメニュー生成サーバ。
【請求項８】
ユーザが用いる端末と、複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューを当該端末に表示させるメニュー生成サーバとを備えるメニュー表示システムであって、
前記端末は、
前記端末に組み込まれた共通メニュー表示モジュールにより表示される前記複数のサービスに共通して表示され、前記サービスと異なるサービスへのリンクを含む共通表示メニューを前記メニュー生成サーバから取得して表示部に表示させる表示制御部を有し、
前記メニュー生成サーバは、
前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成する生成部と、
前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付ける受付部と、
受け付けた通知情報を前記共通表示メニューに対して追加する追加部と、
前記通知情報を追加した前記共通表示メニューを前記端末に対して提供する提供部と、
前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数する計数部と、
前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定する設定部と、
を備えるメニュー表示システム。
【請求項９】
複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューをユーザが用いる端末に表示させるメニュー生成方法であって、
前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成するステップと、
前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付けるステップと、
受け付けた通知情報を前記共通表示メニューに対して追加するステップと、
前記通知情報を追加した前記共通表示メニューを前記端末に対して提供するステップと、
前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数するステップと、
前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定するステップと、
を含み、
前記通知情報を受け付ける前記ステップは、設定した前記登録条件又は通知態様に応じて前記サービスパートナーから前記通知情報の登録を受け付ける、
メニュー生成方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メニュー生成サーバ、メニュー表示システム及びメニュー生成方法に関する。
【背景技術】
【０００２】
従来、ウェブページやアプリケーションにより提供されるサービスには、当該サービスを構成するコンテンツを選択するためのメニューが設けられている（例えば、特許文献１参照）。充実したメニューを設けることにより、サービスを利用するユーザが利用したいコンテンツを容易に選択することができ、サービスの利便性が向上する。利便性の向上に伴いサービスの評価が高くなると、サービスを利用するユーザの紹介により集客効果が高まることが期待できる。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００７−１５７０９３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
しかしながら、サービスを利用しているユーザの数が少ない場合、利便性が高まったとしても紹介による集客効果が小さく、ユーザ数を大幅に増加させることが困難であるという問題があった。
この点、本出願人は、特願2014-91195号に示すように、複数の異なるサービスに対して共通する共通表示メニューを設け、当該共通表示メニューを用いて複数のサービス間を遷移可能にする仕組みを開発している。このような仕組みでは、サービスを利用しているユーザの総数を、個々のサービスを利用するユーザ数の和とすることができるため、集客効果を効率的に高めることができる。
【０００５】
ここで、共通表示メニューに参加するサービスの管理者（以下では、「サービスパートナー」と呼ぶことがある）にとってみれば、自身のサービスを利用するユーザ数が増加することを望む。この点、共通表示メニューに参加するサービスの利用率は、ユーザが共通表示メニューを用いる時間に応じて上昇することが想定されるため、共通表示メニューの管理者には、共通表示メニューの利用時間を増加させる新たな仕組みが求められる。
【０００６】
本発明は、このような要望に鑑みてなされたものであり、複数のサービスに共通する共通表示メニューに対するユーザの利用時間を増加させるメニュー生成サーバ、メニュー表示システム及びメニュー生成方法を提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明の第１の態様においては、複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューをユーザが用いる端末に表示させるメニュー生成サーバであって、前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成する生成部と、前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付ける受付部と、受け付けた通知情報を前記共通表示メニューに対して追加する追加部と、前記通知情報を追加した前記共通表示メニューを前記端末に対して提供する提供部と、前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数する計数部と、前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定する設定部と、を備えるメニュー生成サーバを提供する。
【０００８】
また、前記計数部は、前記一のサービスから遷移したサービス毎に当該一のサービスからの前記流出数を計数するとともに、前記一のサービスに遷移したサービス毎に当該一のサービスに対する流入数を計数し、前記設定部は、前記サービスの夫々に対して計数した、遷移先のサービス毎の流出数に基づいて、前記登録条件又は前記通知態様を設定することとしてもよい。
【０００９】
また、前記設定部は、第１所定期間に通知する前記通知情報の前記登録条件又は当該第１所定期間の前記通知情報の前記通知態様を、当該第１所定期間よりも前の第２所定期間における前記流出数及び前記流入数に基づいて設定することとしてもよい。
【００１０】
また、前記設定部は、前記流出数が多い又は前記流入数に対する前記流出数の割合が高い所定数の前記サービスパートナーに対して第１登録条件又は第１通知態様を設定し、前記流出数が少ない又は前記割合が低い所定数の前記サービスパートナーに対して前記第１登録条件又は前記第１通知態様とは異なる第２登録条件又は第２通知態様を設定することとしてもよい。
【００１１】
また、前記追加部は、ユーザが現在提供を受けているサービスの前記流出数又は前記流入数に対する前記流出数の割合に基づいて、前記共通表示メニューに対して前記通知情報を追加するか否かを判定することとしてもよい。
【００１２】
また、前記追加部は、前記流出数又は前記流入数に対する前記流出数の割合が第１閾値を満たさないサービスの提供を受けているユーザから前記要求を受けると、受け付けた前記通知情報のうち、前記流出数又は前記割合が第２閾値を超えるサービスを提供するサービスパートナーの通知情報を、前記共通表示メニューに対して追加することとしてもよい。
【００１３】
また、前記計数部の計数結果に基づいて、前記複数のサービスの夫々を、第１サービス及び当該第１サービスを遷移元とした場合の前記流入数又は当該サービスにおける総流入数に対する前記第１サービスを遷移元とした場合の前記流入数の割合が第３閾値を超える第２サービスを含む第１サービスグループと、前記第１サービスグループに含まれるサービスを遷移元とした場合の前記流入数又は当該サービスにおける総流入数に対する前記第１サービスグループに含まれるサービスを遷移元とした場合の前記流入数の割合が第４閾値を満たさない第３サービスを含む第２サービスグループと、に分類する分類部、を更に備え、前記追加部は、前記第２サービスグループに含まれるサービスの提供を受けているユーザから前記要求を受けると、受け付けた前記通知情報のうち、前記第１サービスグループに含まれるサービスを提供するサービスパートナーの通知情報を、前記共通表示メニューに対して追加することとしてもよい。
【００１４】
本発明の第２の態様においては、ユーザが用いる端末と、複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューを当該端末に表示させるメニュー生成サーバとを備えるメニュー表示システムであって、前記端末は、前記端末に組み込まれた共通メニュー表示モジュールにより表示される前記複数のサービスに共通して表示され、前記サービスと異なるサービスへのリンクを含む共通表示メニューを前記メニュー生成サーバから取得して表示部に表示させる表示制御部を有し、前記メニュー生成サーバは、前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成する生成部と、前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付ける受付部と、受け付けた通知情報を前記共通表示メニューに対して追加する追加部と、前記通知情報を追加した前記共通表示メニューを前記端末に対して提供する提供部と、前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数する計数部と、前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定する設定部と、を備えるメニュー表示システムを提供する。
【００１５】
本発明の第３の態様においては、複数のサービスパートナーが提供する複数のサービスに共通する共通表示メニューをユーザが用いる端末に表示させるメニュー生成方法であって、前記端末からの要求に応じて、前記複数のサービスの夫々に遷移可能な前記共通表示メニューを生成するステップと、前記サービスパートナーから自身のサービスを紹介する通知情報の登録を受け付けるステップと、受け付けた通知情報を前記共通表示メニューに対して追加するステップと、前記通知情報を追加した前記共通表示メニューを前記端末に対して提供するステップと、前記ユーザが、前記複数のサービスのうちの一のサービスの提供を受けている間に、前記共通表示メニューを介して他のサービスに遷移した数を示す流出数、及び前記他のサービスの提供を受けている間に、前記共通表示メニューを介して前記一のサービスに遷移した数を示す流入数を、前記複数のサービスの夫々に対して計数するステップと、前記サービスの夫々に対して計数した前記流出数と前記流入数との関係に基づいて、当該サービスを提供する前記サービスパートナーが前記通知情報を登録するための登録条件又は前記通知情報の通知態様のうちの少なくとも一方を、前記サービスパートナーの夫々に対して設定するステップと、を含み、前記通知情報を受け付ける前記ステップは、設定した前記登録条件又は通知態様に応じて前記サービスパートナーから前記通知情報の登録を受け付けるメニュー生成方法を提供する。
【発明の効果】
【００１６】
本発明によれば、複数のサービスに共通する共通表示メニューに対するユーザの利用時間を増加させることができる。
【図面の簡単な説明】
【００１７】
【図１】メニュー表示システムの構成例を示す図である。
【図２】端末の表示部にサービスが表示された例を示す図である。
【図３】端末の表示部にサービスのメニュー画面が表示された例を示す図である。
【図４】メニュー画面の全体構成の例を示す図である。
【図５】第１実施形態に係る端末及びメニュー生成サーバの機能構成を示す図である。
【図６】メニュー登録機能を発揮する際のメニュー生成サーバの機能構成を示す図である。
【図７】サービスパートナー情報記憶部に記憶される情報の一例を示す図である。
【図８】通知情報記憶部に記憶される情報の一例を示す図である。
【図９】設定内容記憶部に記憶される情報の一例を示す図である。
【図１０】流出数及び流入数の計数結果の一例を示す図である。
【図１１】メニュー提供機能を発揮する際のメニュー生成サーバの機能構成を示す図である。
【図１２】共通表示メニューを表示するまでの処理の流れを示す図である。
【図１３】別実施形態におけるメニュー提供機能を発揮する際のメニュー生成サーバの機能構成を示す図である。
【図１４】夫々のサービスと追加する通知情報との関係の一例を示す図である。
【図１５】共通表示メニューに通知情報を追加する際の処理の流れを示す図である。
【発明を実施するための形態】
【００１８】
［メニュー表示システムの概要］
初めに、図１から図４を参照して、本発明のメニュー表示システムＳの概要について説明する。図１は、メニュー表示システムＳの構成例を示す図である。
メニュー表示システムＳは、複数のサービスの夫々に共通して用いられる共通表示メニューを用いた共通表示メニューサービスを提供するためのシステムである。メニュー表示システムＳは、端末１と、共通表示メニューを生成するメニュー生成サーバ２と、サービスを構成するコンテンツを提供する複数のコンテンツサーバ３とを含んで構成される。端末１と、メニュー生成サーバ２と、複数のコンテンツサーバ３とは、所定の通信ネットワーク４を介して通信可能に接続されている。
【００１９】
コンテンツサーバ３は、共通表示メニューサービスを利用する複数のサービスパートナーの夫々が管理するサーバである。
端末１は、例えば、スマートフォン等の携帯端末である。端末１は、複数のコンテンツサーバ３にアクセスしてコンテンツを受信し、当該コンテンツを端末１が備える表示部１２に表示する。図２は、端末１の表示部１２の表示例であり、レシピサービスを構成するコンテンツの一例を示す。図２に示すように、表示部１２にはレシピサイトに関するコンテンツが表示されているとともに、タブ１１１が表示されている。
【００２０】
端末１のユーザがタブ１１１にタッチすると、コンテンツの表示画面に代わって、利用中のサービスのメニュー画面が表示される。図３は、端末１の表示部１２の表示例であり、レシピサービスのメニュー画面の一例を示す。また、図４は、レシピサービスで用いられるメニュー画面の全体構成を示す図である。以下、利用中のサービスのメニュー画面を、単にメニュー画面という。
【００２１】
図４（Ａ）に示すように、メニュー画面には、広告枠と、サイトサービスメニューと、共通表示メニューと、タブ１１２とが含まれており、図３に示すように、端末１の表示部１２には、メニュー画面の少なくとも一部が表示される。広告枠は、例えば、コンテンツサーバ３が取得した広告情報を表示するための枠である。なお、広告情報は、コンテンツサーバ３が取得するものとしたが、これに限らず、端末１がメニュー画面を表示する際に、広告サーバ（不図示）から取得するようにしてもよい。
【００２２】
サイトサービスメニューは、メニュー画面が表示される直前に表示されていたサービスのメニューであり、コンテンツサーバ３によって提供される。例えば、図３には、レシピサイトのメニューが表示されている。
【００２３】
共通表示メニューは、共通表示メニューサービスに参加するサービスパートナーのサービスに遷移するためのメニューであり、メニュー生成サーバ２によって提供される。共通表示メニューには、ニュースやショッピングといった複数のカテゴリが表示されており、これらのカテゴリの夫々には、共通表示メニューサービスに参加する複数のサービスパートナーのサービスに遷移するためのアドレス情報（リンク）が関連付けられている。
【００２４】
タブ１１２は、共通表示メニューの表示を止め、共通表示メニューを表示する前に利用していたサービスの表示画面に遷移するための画像である。例えば、図３に示す状態において、端末１のユーザによってタブ１１２がタッチされると、図２に示すレシピサービスの表示画面が再表示される。
【００２５】
ここで、共通表示メニューに表示されるサービスの中には、時間に応じて利用者に提供したい情報が変化するサービスがある。例えば、ニュースサイトでは、ニュースの速報が掲載されたウェブページを利用者に優先的に提供することを望むことがあり、また、ショッピングサイトでは、タイムセールに関する情報が掲載されたウェブページを利用者に優先的に提供することを望むことがある。そこで、本実施形態に係るメニュー表示システムＳでは、共通表示メニューに、サービスパートナーが指定した通知情報を追加可能にしている。
【００２６】
図４（Ｂ）は、通知情報が追加された共通表示メニューの全体構成を示す図である。図４（Ｂ）に示す例では、共通表示メニューに表示されているＤニュースのリンクに対して、「鉄道運行情報」という通知情報が追加表示されているとともに、Ａショッピングのリンクに対して、「タイムセール実施中」という通知情報が追加表示されていることが確認できる。
【００２７】
以上のようなメニュー表示システムＳでは、端末１のユーザが、共通表示メニューに表示されているカテゴリ名にタッチすると、当該カテゴリに対応するアドレス情報に基づいて、サービスパートナーのサービスに遷移する。これにより、メニュー表示システムＳに参加するサービスパートナーは、自社の顧客だけでなく、他のサービスパートナーのサービスを利用している他社の顧客から自社のサービスへのアクセスを受けることができるので、集客効果の向上が期待できる。
【００２８】
特に、メニュー表示システムＳでは、共通表示メニューに対して通知情報を追加することで、通知情報に対応するサービスへのアクセスを促すため、ユーザは、共通表示メニューサービスで提供される複数のサービスの間を回遊することになる。その結果、共通表示メニューの利用時間の増加が期待でき、更にはサービスパートナーのサービスへのアクセス率の上昇が期待できる。
以下、図面を参照して、メニュー表示システムＳの詳細について説明する。
【００２９】
［第１実施形態］
初めに、メニュー表示システムＳの好適な一実施形態を、図５から図１２を参照して説明する。
図５は、第１実施形態のメニュー表示システムＳを構成する端末１及びメニュー生成サーバ２の機能構成図である。
【００３０】
［端末１の構成例］
図５に示すように、端末１は、入力部１１と、表示部１２と、無線部１３と、記憶部１４と、制御部１５とを備える。
【００３１】
入力部１１は、例えば、ボタンや、表示部１２に重畳して配置される接触センサ等により構成されており、端末１のユーザから操作入力を受け付ける。
表示部１２は、例えば、液晶ディスプレイや有機ＥＬ（Electro-Luminescence）ディスプレイ等により構成される。表示部１２は、制御部１５の制御に応じて文字や図形等を表示する。
【００３２】
無線部１３は、制御部１５から出力された信号を変調してＲＦ（Radio Frequency）信号を生成し、アンテナ（不図示）を介して当該ＲＦ信号を基地局（不図示）又は無線ＬＡＮ等のアクセスポイント（不図示）に無線送信する。無線部１３は、アンテナを介して基地局又はアクセスポイントから受信したＲＦ信号を復調し、復調により得られた信号を制御部１５に出力する。以下の説明において、端末１は、無線部１３を介してメニュー生成サーバ２及びコンテンツサーバ３と通信を行うものとする。
【００３３】
記憶部１４は、例えば、ＲＯＭ及びＲＡＭ等により構成される。記憶部１４は、端末１を機能させるための各種プログラムを記憶する。例えば、記憶部１４は、端末１の制御部１５を、後述する端末送信部１５１、端末受信部１５２、表示制御部１５３として機能させるためのプログラムを記憶する。記憶部１４は、外部メモリ等の記憶媒体に記憶されたプログラムを読み取って記憶してもよく、通信ネットワーク４を介して外部機器からダウンロードされたプログラムを記憶してもよい。
【００３４】
制御部１５は、例えば、ＣＰＵにより構成される。制御部１５は、記憶部１４に記憶されている各種プログラムを実行することにより、端末１に係る機能を統括的に制御する。制御部１５は、端末送信部１５１と、端末受信部１５２と、表示制御部１５３とを備える。
【００３５】
端末送信部１５１は、利用中のサービスを構成するコンテンツの取得操作を入力部１１が受け付けたことに応じて、当該サービスを管理するコンテンツサーバ３に対して、コンテンツの取得リクエストを送信する。
端末受信部１５２は、コンテンツサーバ３から、当該取得リクエストに対応するコンテンツを受信するとともに、当該コンテンツに対応するサービスのサイトサービスメニューを受信する。
【００３６】
表示制御部１５３は、図２に示すように、コンテンツサーバ３から受信したコンテンツ、及びメニュー画面を表示させるためのタブ１１１を表示部１２に表示する。ここで、端末受信部１５２が受信したサイトサービスメニューは、タブ１１１がタッチされるまで表示されず、表示待ち状態となる。そのため、サイトサービスメニューは、端末受信部１５２によって、記憶部１４に一時的に記憶される。
【００３７】
その後、入力部１１によってタブ１１１を選択する操作を受け付けると、表示制御部１５３は、表示部１２にメニュー画面を表示し、当該メニュー画面に記憶部１４に一時的に記憶されているサイトサービスメニューを表示する。
このとき、メニュー画面のソースコードには、共通表示メニューをメニュー生成サーバ２から取得するためのスクリプト（例えば、Ａｊａｘ）が含まれており、端末送信部１５１は、当該スクリプトに基づいて、メニュー生成サーバ２に共通表示メニューの取得リクエストを送信する。この取得リクエストに応じて、端末受信部１５２が共通表示メニューをメニュー生成サーバ２から受信すると、表示制御部１５３は、受信した共通表示メニューをサイトサービスメニューに追加することで、表示部１２にメニュー画面を表示する。
【００３８】
［メニュー生成サーバ２の構成例］
続いて、メニュー生成サーバ２の機能構成について説明する。メニュー生成サーバ２は、記憶部２１と、制御部２２とを備える。
【００３９】
記憶部２１は、例えば、ＲＯＭ及びＲＡＭ等により構成される。記憶部２１は、メニュー生成サーバ２を機能させるための各種プログラムを記憶する。例えば、記憶部２１は、メニュー生成サーバ２の制御部２２がメニュー登録機能２３及びメニュー提供機能２４を発揮するためのプログラムを記憶する。記憶部２１は、外部メモリ等の記憶媒体に記憶されたプログラムを読み取って記憶してもよく、通信ネットワーク４を介して外部機器からダウンロードされたプログラムを記憶してもよい。
【００４０】
制御部２２は、例えば、ＣＰＵにより構成される。制御部２２は、記憶部２１に記憶されている各種プログラムを実行することにより、メニュー登録機能２３及びメニュー提供機能２４を発揮する。
【００４１】
メニュー登録機能２３は、共通表示メニューサービスに参加する複数のサービスパートナーの夫々から、当該サービスパートナーが提供するサービス、及び共通表示メニューに追加する通知情報の登録を受け付ける機能である。このとき、メニュー登録機能２３は、複数のサービスパートナーの夫々に対して通知情報の登録条件及び／又は登録された通知情報の通知態様を異ならせて設定する。
【００４２】
なお、通知情報の登録条件とは、例えば、通知情報を登録可能な回数、通知情報を共通表示メニューに追加する時間、又は通知情報を登録するのに必要な費用等である。例えば、登録条件が有利なサービスパートナーは、通知態様が不利なサービスパートナーよりも、通知情報を多く登録することができ、また、通知情報を長い時間追加することができ、また、通知情報を安く登録することができる。
また、通知情報の通知態様とは、例えば、共通表示メニューに通知情報を追加表示する際の表示の態様である。例えば、通知態様が有利なサービスパートナーは、通知態様が不利なサービスパートナーよりも派手で目立つ態様で通知情報を追加表示することができる。
【００４３】
メニュー提供機能２４は、端末１からの取得リクエスト（タブ１１１の選択）に応じて共通表示メニューを生成し、当該端末１に対して提供する機能である。具体的には、メニュー提供機能２４は、メニュー登録機能２３が受け付けた登録内容に応じて、サービスパートナーから受け付けたサービスに遷移可能な共通表示メニューを生成するとともに、登録された通知情報を共通表示メニューに追加して、端末１に対して提供する。
以下、制御部２２のメニュー登録機能２３及びメニュー提供機能２４の詳細について説明する。
【００４４】
［メニュー登録機能２３の詳細］
図６は、メニュー登録機能２３が発揮される場合の記憶部２１及び制御部２２の構成を示す図である。
図６に示すように、メニュー登録機能２３が発揮される場合、記憶部２１は、サービスパートナー情報記憶部２１１と、通知情報記憶部２１２と、設定内容記憶部２１３と、を含んで構成される。
【００４５】
図７は、サービスパートナー情報記憶部２１１に記憶されている情報の一例を示す図である。図７に示すように、サービスパートナー情報記憶部２１１は、サービスパートナーのサービスを識別するサービスＩＤに対応付けて、サービスの名称、サービスを呼び出すアドレス情報及び当該サービスが属するカテゴリを記憶する。
なお、サービスを呼び出すアドレス情報は、例えばウェブページを読み出すためのＵＲＬであってもよいし、アプリケーション起動指示を含むように記述されたＵＲＬスキームであってもよい。この場合には、端末１に指示されたアプリケーションがインストールされている場合には、指示されたアプリケーションが起動する一方で、指示されたアプリケーションがインストールされていない場合には、アプリケーションをインストールするためのストアサイトに遷移させることとしてもよい。
【００４６】
図８は、通知情報記憶部２１２に記憶されている情報の一例を示す図である。図８に示すように、通知情報記憶部２１２は、サービスＩＤに対応付けて、通知情報の内容、通知情報を呼び出すアドレス情報、及び共通表示メニューに通知情報を追加表示する期間を記憶する。
【００４７】
図９は、設定内容記憶部２１３に記憶されている情報の一例を示す図である。図９に示すように、設定内容記憶部２１３は、サービスＩＤに対応付けて、登録条件及び／又は通知態様を記憶する。登録条件は、サービスＩＤに対応するサービスを提供するサービスパートナーが通知情報を登録するための条件であり、通知態様は、共通表示メニューに通知情報を追加表示する際の態様を示す情報である。
通知情報が共通表示メニューに追加表示されることで、通知情報が示すサービスに対するアクセスが促されるため、通知情報を登録することは、自身のサービスへのアクセス率を上昇させることに繋がる。本実施形態では、通知情報の登録条件及び通知態様のうちの少なくとも一方をサービス毎に設定することで、任意のサービスを他のサービスに対して優遇する。
【００４８】
登録条件としては、図９に一例として示すように、１ヶ月間に通知情報を登録可能な回数である登録可能数、１ヶ月間に通知情報を登録可能な時間である登録可能時間、通知情報を登録するために必要な料金である登録料金、及び共通表示メニューに通知情報を追加表示する際の単位時間である表示時間等を用いることができる。登録条件として、これら登録可能数、登録可能時間、登録料金及び表示時間等のうちの一の条件のみを用いることとしてもよく、複数の条件を併せて用いることとしてもよい。
【００４９】
登録可能数が多いほど、又は登録可能時間が長いほど、通知情報による利益を享受する機会が多くなり有利である。なお、登録可能数及び登録可能時間は、ＡＮＤ条件で設定することとしてもよく、また、ＯＲ条件で設定することとしてもよい。また、登録料金が安いほど、通知情報を登録し易く有利であり、また、単位時間が短いほど、通知情報の追加をタイムリーに行うことができ有利である。
【００５０】
また、通知態様は、共通表示メニューに追加表示した際の把握のし易さを異ならせるために用いられる。図９に示す例では、通知態様として黒文字、カラー及びカラー＋点滅の３パターンを例示しているが、その他の通知態様を用いることとしてもよい。
例えば、通知情報をカラーで点滅する態様で追加表示することで、視認性が高まりユーザが当該通知情報を確実に把握することが期待でき、単に黒文字で追加表示する場合よりも有利であることが想定される。なお、有利な通知態様が設定されているサービスパートナーは、不利な通知態様を選択することができることとしてもよい。
【００５１】
図６に戻り、メニュー登録機能２３が発揮される場合、制御部２２は、受付部２３１と、計数部２３２と、設定部２３３と、を含んで構成される。
【００５２】
受付部２３１は、複数のサービスパートナーの管理端末（不図示）の夫々から、自身のサービスに関する登録リクエストを受け付ける。具体的には、受付部２３１は、サービスパートナーの管理端末の夫々から、共通表示メニューに表示するサービスに関する情報（サービスＩＤ，アドレス情報等）、及び共通表示メニューに追加表示する通知情報に関する情報（通知情報、アドレス情報、期間等）についての登録リクエストを受け付ける。受付部２３１が受け付けた情報は、サービスパートナー情報記憶部２１１及び通知情報記憶部２１２に記憶される。
【００５３】
計数部２３２は、複数のサービスの夫々に対して流出数及び流入数を計数する。流出数は、ユーザが共通表示メニューサービスに参加する複数のサービスのうちの一のサービスの提供を受けている間に、共通表示メニューを介して当該一のサービスから他のサービスに遷移した数を示し、流入数は、ユーザが他のサービスの提供を受けている間に、共通表示メニューを介して当該一のサービスに遷移した数を示す。例えば、「Ａショッピング」を利用しているユーザが、共通表示メニューを介して「Ｂラジオ」に遷移した場合、計数部２３２は、「Ａショッピング」の流出数に「１」加算し、「Ｂラジオ」の流入数に「１」加算する。
【００５４】
なお、ユーザが共通表示メニューを介してサービスを遷移したことを、メニュー生成サーバ２において検知する方法は任意である。例えば、端末１は、設定されたアドレス情報に従い遷移先のサービスに応じたコンテンツサーバ３にアクセスすることになるが、コンテンツサーバ３からメニュー生成サーバ２に対して所定の通知を行うことで、メニュー生成サーバ２においてサービスの遷移を検知することとしてもよい。また、共通表示メニューに、サービスを遷移する際にメニュー生成サーバ２に対して所定の通知を行うためのスクリプト（例えば、Ａｊａｘ）を含めておくこととしてもよい。このような方法によれば、ユーザが共通表示メニューを介してサービスを遷移すると、端末１からメニュー生成サーバ２に対して通知が行われるため、メニュー生成サーバ２において端末１におけるサービスの遷移を検知することができる。
【００５５】
なお、計数部２３２は、一のサービスに対して計数する流出数及び流入数を、遷移先の他のサービス及び遷移元の他のサービス毎に計数することとしてもよい。具体的には、上述の例の場合、計数部２３２は、「Ａショッピング」の流出数のうち、遷移先を「Ｂラジオ」とする流出数に「１」加算し、「Ｂラジオ」の流入数のうち、遷移元を「Ａショッピング」とする流入数に「１」加算する。
【００５６】
ここで、計数部２３２が計数した流出数及び流入数の一例を、図１０（Ａ）に示す。共通表示メニューの利用時間を増加するという側面から見ると、流出数及び流入数から利用時間増加に対する各サービスの貢献度合いを把握することができる。例えば、流出数が多いサービスは、共通表示メニューサービスに参加する他のサービスに対してユーザを多く誘導しているため、貢献度が高いサービスといえ、反対に、流出数が少ないサービスは、貢献度が低いサービスといえる。
【００５７】
もちろん、貢献度は、流出数及び流入数ではなく、流入数に対する流出数の割合を用いて把握することもできる。例えば、流入数に対して流出数の割合が高いサービスは、図１０（Ｂ）に示すように、複数のサービスの間を回遊する際の起点となるサービス（以下、「ハブサービス」と呼ぶことがある）であり貢献度が高い。反対に、流入数に対して流出数の割合が低いサービスは、ユーザが共通表示メニューサービスの利用を止めてしまうサービス（以下、「エンドサービス」と呼ぶことがある）であり、貢献度が低い。
図１０（Ａ）に示す計数結果の場合、サービスＩＤ「ＣＣＣＣ」の「Ｃカレンダー」は、流入数に対する流出数の割合が高く、ハブサービスといえる。他方、サービスＩＤ「ＤＤＤＤ」の「Ｄニュース」は、流入数に対して流出数が著しく低く、エンドサービスといえる。
【００５８】
また、計数部２３２の計数結果からは、共通表示メニューサービスを利用するユーザが複数のサービス間を遷移する順序も把握することができる。図１０（Ａ）に示す計数結果の場合、例えば、図１０（Ｃ）に示すように、ユーザは、サービスＩＤ「ＣＣＣＣ」のサービスから、サービスＩＤ「ＤＤＤＤ」のサービスを介してサービスＩＤ「ＢＢＢＢ」のサービスに遷移することが把握できるとともに、サービスＩＤ「ＣＣＣＣ」のサービスから、サービスＩＤ「ＡＡＡＡ」のサービスを介してサービスＩＤ「ＤＤＤＤ」のサービスに遷移することが把握できる。
なお、図１０に示す例では、一のサービスと他のサービスという２つのサービス間での遷移の結果に基づいて、サービス間を遷移する順序を把握することとしているが、３つ以上のサービス間での遷移の結果を計数することで、サービス間を遷移する順序を把握することとしてもよい。
【００５９】
図６に戻り、設定部２３３は、サービスの夫々に対して計数した流出数と流入数との関係に基づいて、当該サービスを提供するサービスパートナーの夫々に対して、通知情報の登録条件及び通知態様のうちの少なくとも一方を設定する。また、設定部２３３は、第１所定期間に通知する通知情報の登録条件及び／又は通知態様を、当該第１所定期間よりも前の第２所定期間における流出数と流入数との関係に基づいて設定する。一例として、設定部２３３は、来月の登録条件等を、今月の流出数及び流出数の計数結果に基づいて設定する。
設定部２３３は、サービスパートナーの夫々に対して登録条件等を設定すると、設定した内容を設定内容記憶部２１３に記憶する。
【００６０】
ここで、設定部２３３は、通知情報の登録条件等を任意の方法により設定することができる。例えば、設定部２３３は、流出数又は流入数に対する流出数の割合に基づいて、登録条件等を設定することができる。具体的には、設定部２３３は、複数のサービスパートナーを、流出数又は流入数に対する流出数の割合に基づいて、流出数が多い又は割合が高い所定数のサービスパートナーと、流出数が少ない又は割合が低い所定数のサービスパートナーと、に分類し、夫々に対して異なる登録条件等を設定する。
【００６１】
図１０（Ａ）に示す例の場合、流入数に対する流出数の割合が高いサービスパートナーとしては、サービスＩＤ「ＤＤＤＤ」や「ＡＡＡＡ」のサービスを提供するサービスパートナーが該当し、流入数に対する流出数の割合が低いサービスパートナーとしては、サービスＩＤ「ＣＣＣＣ」や「ＢＢＢＢ」のサービスを提供するサービスパートナーが該当する。一例として、設定部２３３は、サービスＩＤ「ＤＤＤＤ」や「ＡＡＡＡ」のサービスを提供するサービスパートナーに対して、サービスＩＤ「ＣＣＣＣ」や「ＢＢＢＢ」のサービスを提供するサービスパートナーよりも有利な登録条件等を設定する。
【００６２】
上述したように、流入数に対する流出数の割合が高いサービス（ハブサービス）は、共通表示メニューサービスに参加する他のサービスに対してユーザを多く誘導する。そこで、このようなサービスを提供するサービスパートナーに対して有利な登録条件等を設定することで、ハブサービスに多くのユーザが誘導されることになり、結果、他のサービスにも多くのユーザが誘導されることになる。
これにより、ユーザは、共通表示メニューサービスに参加するサービス間で回遊することになり、共通表示メニューの利用時間が増加することが期待できる。
【００６３】
また、設定部２３３は、サービスの夫々に対して計数した、遷移先のサービス毎の流出数に基づいて、登録条件等を設定することとしてもよい。一例として、遷移先をハブサービスとする流出数が多いサービスが存在する場合、当該サービスに対してユーザを誘導すると、結果としてユーザがハブサービスに遷移することになる。そこで、設定部２３３は、このようなサービスを提供するサービスパートナーに対して有利な登録条件等を設定することとしてもよい。
なお、遷移先のサービス毎の流出数は、あるサービスに対して計数した特定のサービスを遷移先とする流出数自体であってもよく、また、当該あるサービスに対して計数した全流出数に対する特定のサービスを遷移先とする流出数の割合であってもよく、また、当該あるサービスに対して計数した全流入数に対する特定のサービスを遷移先とする流出数の割合であってもよい。
【００６４】
また、複数のサービス間を遷移する順序に一定の関係性がみられる場合には、設定部２３３は、当該順序に基づいて登録条件等を設定することとしてもよい。例えば、設定部２３３は、複数のサービスのうち、遷移する順序が早いサービスを提供するサービスパートナーに対して、遷移する順序が遅いサービスを提供するサービスパートナーよりも有利な登録条件等を設定することとしてもよい。
【００６５】
［メニュー提供機能２４の詳細］
以上、メニュー登録機能２３について説明した。続いて、図１１を参照して、メニュー提供機能２４が発揮される場合の記憶部２１及び制御部２２の構成について説明する。
図１１に示すように、メニュー提供機能２４が発揮される場合、記憶部２１は、サービスパートナー情報記憶部２１１と、通知情報記憶部２１２と、設定内容記憶部２１３と、を含んで構成され、また、制御部２２は、サーバ受信部２４１と、生成部２４２と、追加部２４３と、提供部２４４と、を含んで構成される。
【００６６】
サーバ受信部２４１は、端末１から、共通表示メニューの取得リクエストを受信する。なお、共通表示メニューの取得リクエストは、上述したように、端末１においてタブ１１１（図２参照）が選択されることで、端末１からメニュー生成サーバ２に送信される。
【００６７】
生成部２４２は、端末１から取得リクエストを受信すると、複数のサービスの夫々に遷移可能な共通表示メニューを生成する。具体的には、生成部２４２は、サービスパートナー情報記憶部２１１を参照して共通表示メニューのカテゴリに対応するサービスのアドレス情報を特定し、カテゴリと当該アドレス情報とを関連付けて、アドレス情報に対応するサービスに遷移可能な共通表示メニューを生成する。
【００６８】
ここで、共通表示メニューに表示されるカテゴリは、予め定められているものとする。このとき、一のカテゴリに対して一のサービスのみが対応付けられている場合には、生成部２４２は、当該サービスのアドレス情報を特定し、一のカテゴリに対して複数のサービスが対応付けられている場合には、生成部２４２は、当該複数のサービスのうちの任意の一のサービスのアドレス情報を特定する。
もちろん、一のカテゴリに対して複数のサービスが対応付けられている場合に、生成部２４２は、当該複数のサービスのうちの二以上のサービスのアドレス情報を特定することとしてもよい。なお、一のカテゴリに対して複数のサービスのアドレス情報を特定した場合には、生成部２４２は、当該一のカテゴリが選択されたことに応じて、当該カテゴリに関連する複数のサービスを選択可能に表示するように共通表示メニューを生成することとしてもよい。
【００６９】
また、生成部２４２は、共通表示メニューにおいて、カテゴリ、サービス名、サービスに対応するアイコンの少なくとも何れかを表示させてもよい。例えば、生成部２４２は、共通表示メニューにおいて、カテゴリとサービス名とを併記したり、カテゴリの代わりにサービス名を表示させたりしてもよい。
【００７０】
なお、共通表示メニューを構成するサービスは、ウェブページである場合もあれば、アプリケーションである場合もある。そこで、生成部２４２は、種別（ウェブページ、アプリケーション等）に応じて異なる態様でリンクを表示する共通表示メニューを生成することとしてもよい。例えば、サービスがウェブページである場合に記号等を表示せず、アプリケーションである場合に所定のアプリケーションに切り替わる旨を示す記号等を表示することとしてもよい。このようにすることで、端末１のユーザは、サービスを選択した際に他のウェブページに遷移するのか、他のアプリケーションが実行されるのかを把握することができる。
【００７１】
追加部２４３は、端末１から取得リクエストを受信した時点で、サービスパートナーの管理端末から通知情報の登録リクエストを受け付けている場合に、受け付けた通知情報を共通表示メニューに対して追加する。具体的には、追加部２４３は、通知情報記憶部２１２を参照して共通表示メニューの取得リクエストを受信したタイミングに通知することを望む通知情報が登録されているか否かを判定し、当該通知情報が登録されている場合に、登録された通知情報及びアドレス情報を通知情報記憶部２１２から読み出し、共通表示メニューに追加する。
例えば、図８に示すように、サービスＩＤ「ＤＤＤＤ」に対応付けて「鉄道運行情報」という通知情報を所定の期間に追加するという登録リクエストを受け付けており、当該所定の期間内に端末１から取得リクエストを受信した場合、追加部２４３は、共通表示メニューに表示されるＤニュースに対して通知情報「鉄道運行情報」を関連付けた共通表示メニュー（図４（Ｂ）参照）を生成する。
【００７２】
このとき、追加部２４３は、追加する通知情報を、設定内容記憶部２１３に登録された通知態様で表示させることとしてもよい。
また、追加部２４３は、生成部２４２が生成した共通表示メニューにおけるアドレス情報と、通知情報のアドレス情報とが異なる場合には、共通表示メニューにおけるアドレス情報を通知情報のアドレス情報に変換することとしてもよい。例えば、図７に示すサービスパートナー情報記憶部２１１を参照すると、サービスＩＤ「ＡＡＡＡ」のアドレス情報として「aaashop.com」が登録されている一方で、図８に示す通知情報記憶部２１２を参照すると、サービスＩＤ「ＡＡＡＡ」の通知情報「タイムセール実施中」のアドレス情報として「aaashop.com/timesale.html」が登録されている。この場合、追加部２４３は、共通表示メニューのＡショッピングに対応付けるアドレス情報を「aaashop.com」から、「aaashop.com/timesale.html」に変換する。
【００７３】
提供部２４４は、生成部２４２が生成した共通表示メニュー、又は、追加部２４３が通知情報を追加した共通表示メニューを、取得リクエストを送信した端末１に対して送信する。
【００７４】
［メニュー表示システムＳの処理］
以上、メニュー表示システムＳの構成について説明した。続いて、図１２を参照して、メニュー表示システムＳの処理の流れについて説明する。
【００７５】
初めに、ステップＳ１０において、共通表示メニューサービスに参加するサービスパートナーの夫々が用いる管理端末から登録リクエストを受け付けると、メニュー生成サーバ２の受付部２３１は、当該登録リクエストに応じて各種情報をサービスパートナー情報記憶部２１１及び通知情報記憶部２１２に登録する。
【００７６】
続いて、端末１の端末送信部１５１がコンテンツサーバ３にコンテンツの取得リクエストを送信すると、ステップＳ２０において、コンテンツサーバ３は、自身の記憶部に記憶されているコンテンツ及びサイトサービスメニューを取得し、端末１に送信する。
【００７７】
続いて、端末受信部１５２が、コンテンツサーバ３からコンテンツ及びサイトサービスメニューを受信すると、ステップＳ３０において、表示制御部１５３は、当該コンテンツと、メニュー画面を呼び出すためのタブ１１１とを表示部１２に表示する。また、端末受信部１５２は、受信したサイトサービスメニューを記憶部１４に一時的に記憶する。
【００７８】
続いて、ステップＳ４０において、表示制御部１５３は、タブ１１１が選択されたか否かを判定する。タブ１１１が選択された場合、ステップＳ５０において、表示制御部１５３は、記憶部１４からサイトサービスメニューを読み出し、メニュー画面として表示部１２に表示する。このとき、端末送信部１５１は、メニュー画面に含まれている、共通表示メニューをメニュー生成サーバ２から取得するためのスクリプトに基づいて、メニュー生成サーバ２に共通表示メニューの取得リクエストを送信する。
【００７９】
続いて、サーバ受信部２４１が、端末１から共通表示メニューの取得リクエストを受信すると、ステップＳ６０において、生成部２４２は、サービスパートナー情報記憶部２１１を参照し、共通表示メニューのカテゴリに対応するサービスのアドレス情報を特定する。
【００８０】
続いて、ステップＳ７０において、生成部２４２は、カテゴリとアドレス情報とを関連付けて、アドレス情報に対応するサービスに遷移可能な共通表示メニューを生成する。このとき、共通表示メニューに表示するサービスに対して通知情報が登録されている場合、追加部２４３は、生成した共通表示メニューに対して通知情報を追加する。続いて、提供部２４４は、生成された共通表示メニューを端末１に送信する。
【００８１】
続いて、端末受信部１５２が、メニュー生成サーバ２から共通表示メニューを受信すると、ステップＳ８０において、表示制御部１５３は、当該共通表示メニューを含むメニュー画面を表示部１２に表示する。
なお、共通表示メニューに設定するリンク先に現在表示しているサービスが含まれる場合には、当該サービスに該当する部分を異なる配色にしてもよいし、また、選択無効にするように制御してもよい。また、サイトサービスメニューは、タブ１１１が選択されたことに応じてメニュー画面に表示されるものとしたが、これに限らない。例えば、サイトサービスメニューの表示は、コンテンツの表示と同時に行われてもよい。そして、タブ１１１が選択されたことに応じて、共通表示メニューのみ表示してもよい。
【００８２】
続いて、端末１において、共通表示メニューに対する操作が行われた場合、端末１からメニュー生成サーバ２に対して、当該操作の内容を示す操作情報が送信される。操作情報は、例えば、現在表示しているサービスから他のサービスに遷移することを示す情報であり、操作情報を受信すると、ステップＳ９０において、メニュー生成サーバ２の計数部２３２は、サービス毎に流入数及び流出数を計数する。続いて、ステップＳ１００において、設定部２３３は、所定期間（例えば、１ヶ月間）の計数結果をもとに、サービスパートナーの夫々に対して、通知情報の登録条件及び／又は通知情報の通知態様を設定する。
【００８３】
［メニュー表示システムＳの効果］
以上、メニュー表示システムＳの好適な一実施形態について説明した。メニュー表示システムＳでは、複数のサービスに共通する共通表示メニューを端末１に提供する際に、サービスパートナーが自身のサービスを紹介する通知情報を追加するため、共通表示メニューサービスに参加する他のサービスへの遷移を、共通表示メニューを介して促すことができる。その結果、ユーザは、共通表示メニューサービスで提供される複数のサービスの間を回遊することになり、共通表示メニューの利用時間の増加が期待できる。
【００８４】
このとき、メニュー表示システムＳでは、サービス毎に流出数及び流入数を計数し、流出数と流入数との関係に基づいて、夫々のサービスに対して、通知情報を登録するための登録条件や通知情報の通知態様を設定する。一例として、複数のサービスの間を回遊する際の起点となるハブサービスに対して、ユーザが共通表示メニューサービスの利用を止めてしまうエンドサービスよりも有利な登録条件や通知態様を設定することで、ハブサービスに対してユーザを強く誘導することができるため、共通表示メニューの利用時間の増加が期待できる。
【００８５】
また、流出数及び流入数を遷移するサービス間の関係性とともに計数することで、あるサービスの提供を受けているユーザが次に遷移する可能性の高い他のサービスを特定することができる。その結果、例えば、ハブサービスに遷移する可能性の高いサービスに対して有利な登録条件や通知態様を設定することもでき、この場合であっても、ハブサービスに対してユーザを強く誘導することができるため、共通表示メニューの利用時間の増加が期待できる。
【００８６】
［第２実施形態］
続いて、メニュー表示システムＳの別実施形態を、図１３から図１５を参照して説明する。
第１実施形態では、複数のサービスの夫々に対して計数した流出数及び流入数に基づいて、通知情報の登録条件等の有利さをサービスパートナーの夫々で異ならせることとしている。この点、第２実施形態では、流出数及び流入数に基づいて、登録した通知情報を追加するか否かを異ならせることとしている。
【００８７】
共通表示メニューに通知情報を追加すると、通知情報に対応するサービスにユーザが誘導される結果、当該サービスへのアクセス率が上昇する。ここで、ハブサービスのように流入数に対する流出数の割合が高いサービスの提供を受けている場合、ユーザは、通知情報を追加しなくても共通表示メニューを介して他のサービスに遷移することが期待できる。反対に、エンドサービスのように流入数に対する流出数の割合が低いサービスの提供を受けている場合、通知情報を追加し他のサービスに誘導しなければ、ユーザは、共通表示メニューサービスの利用を止めてしまう可能性が高い。
そこで、第２実施形態では、ユーザが現在提供を受けているサービスに応じて、通知情報を追加することで、共通表示メニューの利用時間の増加をはかっている。
【００８８】
［メニュー生成サーバ２の構成例］
図１３は、第２実施形態のメニュー生成サーバ２がメニュー提供機能２４を発揮する場合の記憶部２１及び制御部２２の構成を示す図である。なお、メニュー生成サーバ２がメニュー登録機能２３を発揮する場合の構成は第１実施形態と同一であるため、説明を省略する。また、メニュー提供機能２４についても、第１実施形態と同一の構成については、詳細な説明を省略する。
【００８９】
図１３に示すように、メニュー提供機能２４が発揮される場合、制御部２２は、第１実施形態の構成に加え分類部２４５を更に含む。
分類部２４５は、計数部２３２が計数した流出数及び流入数に基づいて、複数のサービスの夫々を、一又は複数のサービスから構成されるサービスグループに分類する。一例として、分類部２４５は、一のサービスと、当該一のサービスから遷移し易い他のサービスとを同一のサービスグループに分類する。
【００９０】
具体的には、分類部２４５は、一のサービス及び当該一のサービスを遷移元とした場合の流入数が所定数よりも多い他のサービスを同一のサービスグループとして分類する。また、このサービスグループに含まれるサービスを遷移元とした場合の流入数が特定数（所定数と同じであってもよく、異なっていてもよい）よりも少ないサービスを他のサービスグループに分類し、当該サービスを遷移元とした場合の流入数が所定数よりも多いサービスを、当該他のサービスグループに分類する。
なお、分類部２４５は、あるサービスを遷移元とした場合の流入数ではなく、当該サービスにおける総流入数に対する当該あるサービスを遷移元とした場合の流入数の割合に基づいてサービスグループを分類することとしてもよい。
【００９１】
図１０（Ａ）に示す例の場合、サービスＩＤ「ＡＡＡＡ」「ＢＢＢＢ」「ＣＣＣＣ」「ＤＤＤＤ」は、互いに遷移し易く同一のサービスグループに属するといえる。また、サービスＩＤ「ＥＥＥＥ」「ＦＦＦＦ」も、互いに遷移し易く同一のサービスグループに属するといえる。なお、分類するサービスグループは、２つに限るものではなく、３つ以上のサービスグループに分類することとしてもよい。また、一のサービスは、一のサービスグループのみに属することとしてもよく、複数のサービスグループに属することとしてもよい。
【００９２】
追加部２４３は、ユーザが現在提供を受けているサービスに対する計数部２３２の計数結果に基づいて、通知情報を追加するか否かを判定し、追加すると判定した場合に、共通表示メニューに対して通知情報を追加する。
【００９３】
一例として、追加部２４３は、ユーザが現在提供を受けているサービスに対して計数した流出数又は流入数に対する流出数の割合に基づいて、共通表示メニューに対して通知情報を追加するか否かを判定する。
流出数が多い又は流入数に対する流出数の割合が高いサービスは、共通表示メニューを介して他のサービスに遷移することが期待できる一方で、流出数が少ない又は流入数に対する流出数の割合が低いサービスは、共通表示メニューを介して他のサービスに遷移することが期待できない。そこで、図１４（Ａ）に示すように、追加部２４３は、流出数が多い又は流入数に対する流出数の割合が高いハブサービスに対しては、通知情報を追加しないと判定し、流出数が少ない又は流入数に対する流出数の割合が低いエンドサービスに対して、通知情報を追加すると判定する。
【００９４】
これにより、ユーザが、共通表示メニューサービスの利用を止めてしまう可能性の高いエンドサービスの提供を受けている場合に通知情報を追加することになるため、共通表示メニューサービスの利用を止める前にユーザを他のサービスに誘導することができ、その結果、共通表示メニューの利用時間が増加することが期待できる。
なお、追加部２４３は、サービスに応じて通知情報を追加するか否か判定するのではなく、サービスに応じて通知情報を追加する頻度を異ならせることとしてもよい。例えば、ハブサービスに対しては通知情報を追加する頻度を低くし、エンドサービスに対しては通知情報を追加する頻度を高くすることとしてもよい。
【００９５】
このとき、追加する通知情報は、流出数が多い又は流入数に対する流出数の割合が高いサービスについての通知情報であることが好ましい。即ち、追加部２４３は、流出数又は流入数に対する流出数の割合が第１閾値を満たさないサービスの提供を受けているユーザから共通表示メニューの取得リクエストを受けると、サービスパートナーから受け付けた通知情報のうち、流出数又は流入数に対する流出数の割合が第２閾値（第１閾値と同じであってもよく、第１閾値よりも高い閾値であってもよい）を超えるサービスを提供するサービスパートナーの通知情報を、共通表示メニューに対して追加する。
【００９６】
これにより、例えば、ユーザがエンドサービスの提供を受けている場合に、ハブサービスのように他のサービスに遷移し易いサービスに誘導することができるため、その後、共通表示メニューサービスに参加するサービス内を回遊することが期待でき、共通表示メニューの利用時間が増加することが期待できる。
【００９７】
また、追加部２４３は、登録された通知情報のうちの何れの通知情報を追加するかを、ユーザが現在提供を受けているサービスに対する計数部２３２の計数結果に基づいて判定することとしてもよい。
一例として、追加部２４３は、ユーザが現在提供を受けているサービスが属するサービスグループとは異なる他のサービスグループに含まれるサービスを提供するサービスパートナーの通知情報を、共通表示メニューに追加する通知情報として決定する。
【００９８】
本実施形態の場合、図１４（Ｂ）に示すように、共通表示メニューサービスに参加するサービスを、サービスＩＤ「ＡＡＡＡ」「ＢＢＢＢ」「ＣＣＣＣ」「ＤＤＤＤ」のサービスが属するサービスグループと、サービスＩＤ「ＥＥＥＥ」「ＦＦＦＦ」のサービスが属するサービスグループとに分類することができる。そこで、追加部２４３は、ユーザがサービスＩＤ「ＡＡＡＡ」「ＢＢＢＢ」「ＣＣＣＣ」「ＤＤＤＤ」のうちの何れかのサービスの提供を受けている場合、他のサービスグループに属するサービスＩＤ「ＥＥＥＥ」「ＦＦＦＦ」のサービスについての通知情報を共通表示メニューに対して追加し、ユーザがサービスＩＤ「ＥＥＥＥ」「ＦＦＦＦ」のうちの何れかのサービスの提供を受けている場合、サービスＩＤ「ＡＡＡＡ」「ＢＢＢＢ」「ＣＣＣＣ」「ＤＤＤＤ」のサービスについての通知情報を共通表示メニューに対して追加する。
【００９９】
これにより、互いに遷移し難いサービスが存在する場合であっても、通知情報により当該サービス間の遷移を促すことができる。そして、サービスを遷移した後は、遷移後のサービスが属するサービスグループ間での遷移が期待できるため、その後の共通表示メニューサービスに参加するサービス内の回遊が期待でき、共通表示メニューの利用時間が増加することが期待できる。
【０１００】
［メニュー表示システムＳの処理］
以上、第２実施形態のメニュー表示システムＳの構成について説明した。続いて、図１５を参照して、第２実施形態のメニュー表示システムＳの処理の流れについて説明する。なお、図１５に示す処理は、第１実施形態のステップＳ６０，Ｓ７０の処理の代わりに行われる処理の一例である。
【０１０１】
サーバ受信部２４１が、端末１から共通表示メニューの取得リクエストを受信すると、ステップＳ１１０において、生成部２４２は、サービスパートナー情報記憶部２１１を参照し、共通表示メニューのカテゴリに対応するサービスのアドレス情報を特定する。続いて、ステップＳ１２０において、生成部２４２は、カテゴリとアドレス情報とを関連付けて、アドレス情報に対応するサービスに遷移可能な共通表示メニューを生成する。
【０１０２】
続いて、ステップＳ１３０において、追加部２４３は、通知情報が登録されているか否かを判定し、登録されている場合には、ステップＳ１４０において、追加判定を行う。ステップＳ１４０の追加判定では、一例として、追加部２４３は、ユーザが現在提供を受けているサービスが、流出数が少ない又は流入数に対する流出数の割合が低いサービスである場合に、通知情報を追加すると判定する。また、追加部２４３は、ユーザが現在提供を受けているサービスが属するサービスグループとは異なる他のサービスグループに含まれるサービスを提供するサービスパートナーの通知情報が登録されている場合に、通知情報を追加すると判定する。
【０１０３】
ステップＳ１４０において、通知情報を追加すると判定すると、続いて、ステップＳ１５０において、追加部２４３は、ステップＳ１２０で生成した共通表示メニューに対して通知情報を追加する。続いて、ステップＳ１６０において、提供部２４４は、生成した共通表示メニューを端末１に送信する。
【０１０４】
［メニュー表示システムＳの効果］
以上、メニュー表示システムＳの別実施形態について説明した。第２実施形態のメニュー表示システムＳでは、追加部２４３は、ユーザが現在提供を受けているサービスの流出数又は流入数に対する流出数の割合に基づいて、共通表示メニューに対して通知情報を追加するか否かを判定する。
例えば、流出数や流入数に対する流出数の割合が閾値を満たさないサービスである場合に、通知情報を追加することで、共通表示メニューサービスを止めてしまう可能性の高いユーザを共通表示メニューサービス内の他のサービスに誘導することができる。特に、追加する通知情報を、流出数や流入数に対する流出数の割合が閾値を超えるサービスの通知情報とすることで、他のサービスに遷移した後にユーザが共通表示メニューサービス内のサービスを回遊することも期待でき、共通表示メニューの利用時間の増加が期待できる。
【０１０５】
また、共通表示メニューサービスに参加するサービスの夫々に対して計数した流出数及び流入数から、ユーザが遷移し易いサービス間の関係性を把握することができ、この関係性に基づき、複数のサービスをユーザが遷移し易いサービスにより構成されるサービスグループに分類することができる。第２実施形態のメニュー表示システムＳでは、ユーザが一のサービスグループに属するサービスの提供を受けているときに、他のサービスグループに属するサービスの通知情報を追加するため、通常であれば遷移し難いサービス間の遷移を促すことができる。そして、サービスを遷移した後は、遷移後のサービスが属するサービスグループ間での遷移が期待できるため、その後の共通表示メニューサービスに参加するサービス内の回遊が期待でき、共通表示メニューの利用時間の増加が期待できる。
【０１０６】
以上、本発明を実施の形態を用いて説明したが、本発明の技術的範囲は上記実施の形態に記載の範囲には限定されない。上記実施の形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。特に、装置の分散・統合の具体的な実施形態は以上に図示するものに限られず、その全部又は一部について、種々の付加等に応じて、又は、機能負荷に応じて、任意の単位で機能的又は物理的に分散・統合して構成することができる。
例えば、上記実施形態のサービスパートナー情報記憶部２１１、通知情報記憶部２１２、及び設定内容記憶部２１３の夫々は、メニュー生成サーバ２とは異なる他のサーバが備えるようにしてもよい。
【０１０７】
また、上記実施形態では、端末１にメニュー画面を表示する場合、端末１に一時的に記憶されているサイトサービスメニューを読み出すとともに、通信ネットワーク４を介してメニュー生成サーバ２にアクセスすることで共通表示メニューを取得することとしている。この点、例えば、端末１に基地局から発信される電波が届かず通信できない場合であっても、共通表示メニューを含むメニュー画面を表示可能とするために、共通表示メニューを示す情報を端末１の記憶部１４に一時的に記憶させるようにしてもよい。
【０１０８】
具体的には、記憶部１４を、取得した共通表示メニューを示す情報を一時的に記憶するメニュー記憶部として機能させる。そして、表示制御部１５３は、共通表示メニューの取得リクエストをメニュー生成サーバ２に送信してから所定時間経過しても、メニュー生成サーバ２から共通表示メニューを取得できない場合、記憶部１４に一時的に記憶されている共通表示メニュー（即ち、過去の通信可能であったタイミングで取得していた共通表示メニュー）を表示してもよい。このようにすることで、端末１は、通信ができない状態であってもエラー画面とせずに、共通表示メニューを表示させることができる。また、表示制御部１５３は、記憶部１４に共通表示メニューを示す情報と、当該情報を記憶した時刻とを記憶しておき、当該時刻から所定時間経過する前に共通表示メニューを表示させる場合に、記憶部１４に記憶されている共通表示メニューを取得して表示させてもよい。
【０１０９】
また、端末１において共通表示メニューに含まれているカテゴリを選択した場合の表示態様は任意である。例えば、表示制御部１５３は、当該カテゴリに対応するサービスに対応付けられたアドレス情報に基づくコンテンツを表示することとしてもよく、当該コンテンツではなく、サービスのメニュー画面を表示することとしてもよい。サービスのメニュー画面を先ず表示することで、サービスの遷移時に連続してメニュー画面が表示されるので、自然な流れでサービス間を遷移させることができる。また、表示制御部１５３は、最初に当該サービスのメニュー画面を表示し、所定時間経過した後にアドレス情報に基づくコンテンツの表示画面を表示することとしてもよい。
【符号の説明】
【０１１０】
１・・・端末、１１・・・入力部、１２・・・表示部、１３・・・無線部、１４・・・記憶部、１５・・・制御部、１５１・・・端末送信部、１５２・・・端末受信部、１５３・・・表示制御部、２・・・メニュー生成サーバ、２１・・・記憶部、２１１・・・サービスパートナー情報記憶部、２１２・・・通知情報記憶部、２１３・・・設定内容記憶部、２２・・・制御部、２３・・・メニュー登録機能、２３１・・・受付部、２３２・・・計数部、２３３・・・設定部、２４・・・メニュー提供機能、２４１・・・サーバ受信部、２４２・・・生成部、２４３・・・追加部、２４４・・・提供部、２４５・・・分類部、３・・・コンテンツサーバ、４・・・通信ネットワーク、Ｓ・・・メニュー表示システム
【図１】
0006440504.tif 000002
【図２】
0006440504.tif 000003
【図３】
0006440504.tif 000004
【図４】
0006440504.tif 000005
【図５】
0006440504.tif 000006
【図６】
0006440504.tif 000007
【図７】
0006440504.tif 000008
【図８】
0006440504.tif 000009
【図９】
0006440504.tif 000010
【図１０】
0006440504.tif 000011
【図１１】
0006440504.tif 000012
【図１２】
0006440504.tif 000013
【図１３】
0006440504.tif 000014
【図１４】
0006440504.tif 000015
【図１５】
0006440504.tif 000016