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