(57)【特許請求の範囲】
【請求項１】
ユーザの端末から、検索クエリ及び検索範囲を検索条件として取得する検索条件取得部と、
前記検索範囲に友達検索が指定されている場合に、前記ユーザの友達情報を取得する友達情報取得部と、
前記ユーザ及び友達の所持する定期券情報を取得する定期券情報取得部と、
前記検索範囲にある駅を、前記ユーザの所持する前記定期券情報を解析して特定する検索条件解析部と、
前記検索条件解析部によって特定された駅の周辺の店舗／施設を検索する検索実行部と、
前記検索の結果として表示された店舗／施設が選択された際に、前記選択された店舗／施設の情報と共に、前記友達の定期券情報を表示する検索結果表示部と、
を備えることを特徴とする検索サーバ。
【請求項２】
前記定期券情報は、定期券の区間外であるが前記ユーザが前記定期券を活用してよく出かける区間である定期券区間外情報を含み、前記検索の結果に表示される友達の定期券情報には、当該定期券を利用してもプラスで発生する交通費を表示することを特徴とする請求項１に記載の検索サーバ。
【請求項３】
前記友達情報取得部又は前記定期券情報取得部は、前記ユーザが登録したＳＮＳサイトから、前記友達情報及び／又は前記定期券情報を取得することを特徴とする請求項１又は２に記載の検索サーバ。
【請求項４】
前記ユーザから前記検索の結果に表示された友達に、前記検索された店舗／施設に一緒に出かけることを依頼する参加依頼のメッセージを送信し、前記参加依頼を承諾した友達の参加当日の移動履歴を改札口の乗降記録から取得する友達参加依頼部をさらに備えることで前記ユーザに前記移動履歴に基づく参加状況を伝達可能とすることを特徴とする請求項１から３までのいずれか一項に記載の検索サーバ。
【請求項５】
前記検索条件解析部は、前記検索クエリから日時情報、場所情報、店舗／施設情報、目的情報を抽出し、検索画面に表示することを特徴とする請求項１から３までのいずれか一項に記載の検索サーバ。
【請求項６】
前記検索条件解析部は、前記検索条件に目的情報が含まれていることを判定した場合に、前記店舗／施設を前記目的情報と前記ユーザのプロフィールに応じて推定することを特徴とする請求項１から５までのいずれか一項に記載の検索サーバ。
【請求項７】
前記プロフィールは、ユーザの生年月日の情報を含み、前記生年月日を参照して、前記生年月日又は年齢に関連する店舗／施設の検索を実行することを特徴とする請求項６に記載の検索サーバ。
【請求項８】
前記検索のためにユーザ独自のエリアを定義させ、前記エリアに含まれる駅を登録させるエリア登録部を更に備え、
前記検索実行部は、更に、前記エリアに含まれる駅の周辺の店舗／施設を検索することを特徴とする請求項１から７までのいずれか一項に記載の検索サーバ。
【請求項９】
ユーザの端末から、検索クエリ及び検索範囲の駅を検索条件として取得するステップと、
前記検索範囲に友達検索が指定されている場合に、前記ユーザの友達情報を取得するステップと、
前記ユーザ及び友達の所持する定期券情報を取得するステップと、
前記検索範囲の駅を前記ユーザの所持する定期券情報を解析して特定するステップと、
前記特定するステップによって特定された駅の周辺の店舗／施設の検索を実行するステップと、
前記検索の結果として表示された店舗／施設が選択された際に、前記選択された店舗／施設の情報と共に、前記友達の定期券情報を表示するステップと、
を有することを特徴とする、コンピュータにより実行される検索方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、検索システム及び検索方法に関し、特に定期券情報を加味（プラス）した検索システム及び検索方法に関する。
【背景技術】
【０００２】
従来から、ユーザの求める情報をネット上で検索する検索システムが広く知られている。最近では、ユーザのよりきめ細かな要求に応えるため、特にユーザの場所や移動に関連する検索や探索を行うシステムが多数提案されている。
【０００３】
例えば、特許文献１には、個々のユーザ行動計画にあった検索結果を提示し、情報を活用してもらう機会の増加を図るための検索支援システムが提案されている。具体的には、検索目的として、ユーザから入力される飲み会、旅行などのユーザ行動計画に沿ったタスクを、個人情報ＤＢに予め登録されている個人情報とスケジュールＤＢに予め登録されているスケジュール情報とに基づいて抽出し、抽出されたタスクとそのタスクに関連する検索サイトとを対応付ける。そして、対応付けられた検索サイトに向けて送信されて検索結果を取得するためのクエリを作成し、取得された検索結果に基づいて、検索サイトに送信すべきクエリを更に作成する検索支援システムが開示されている。
【０００４】
また、特許文献２には、利用し得る各種の移動手段又は移動手段の組み合わせごとの推奨経路を探索し、それらの推奨経路を比較対照できるように提示するシステムが提案されている。具体的には、予め設定された所定の移動手段および予め設定された所定の異なる複数の移動手段の組み合わせごとに、出発地から目的地までの経路を探索する終電探索モードを有し、終電探索モードが選択された場合、所定の移動手段および所定の異なる複数の移動手段の組み合わせごとに、始発移動手段を含む経路の出発時刻以前に出発地を出発して目的地に到達する経路のうち、出発地を出発する時刻が最も遅い最遅経路を探索し、設定されたソート順に従って、所定の移動手段および所定の異なる複数の移動手段の組み合わせごとの最遅経路をソートし、各最遅経路の出発時刻、所要時間、所要料金等と共に案内する経路探索サーバ等が開示されている。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００８−２６９４８０号公報
【特許文献２】特開２０１０−２１０５６１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
ところで移動に関して、ユーザは、通勤や通学のため定期券を持っていても普段は乗車駅、降車駅、乗換駅しか利用せず、その途中の駅で遊んだり食事をしたりすることはほどんどなかった。そのため、定期券を活用して移動できる範囲でショッピング、映画館、飲食店等の検索を行なおうとした場合、定期券区間内又は定期券区間外でよく利用する区間で１つ１つ駅名を入力して検索しないといけなかった。
【０００７】
また、駅名だけでなく、エリアで指定できる検索サイトもあるが、エリアの区分が予め決められているため、ユーザが検索したいエリアとは一致しないことも多い。例えば、通勤経路である新宿駅−四谷駅間で目的の店舗を探そうとしても、新宿駅と四谷駅の区間だけを含むエリアの区分がないため、「丸の内線沿線」、「中央線沿線」というような、より大きなエリアで検索せざるを得なかった。
【０００８】
したがって、ユーザは定期券を最大限に活用できず、結果として大きな駅だけに行きがちとなる。また、電子定期券が普及している現在では、定期券のＩＣカードに登録されている情報を何かに活用することも可能である。しかし、定期券情報を活用した検索システムとしては、特許文献２に記載の経路探索システムのように、交通機関での移動の際の所要時間や所要料金の計算に利用するものが主であった。ユーザにとって店舗や施設の検索は、移動時間や移動料金だけでなく、目的とする店舗等をいかに効率的に探せるかが重要である。また、特に女性は、友達等と連れ立って店舗等に行きたい場合も多いが、その場合、自分だけの都合でなく、友達等の都合も加味することも必要である。
【０００９】
したがって、本発明では、上記のような課題に鑑み、ユーザ自身はもちろん、友達等の定期券情報を加味した検索システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するため、本発明の検索システムは、以下のような解決手段を提供する。
【００１１】
請求項１は、検索サーバの発明であって、ユーザの端末から、検索クエリ及び検索範囲を検索条件として取得する検索条件取得部と、前記検索範囲に友達検索が指定されている場合に、前記ユーザの友達情報を取得する友達情報取得部と、前記ユーザ及び友達の所持する定期券情報を取得する定期券情報取得部と、前記検索範囲にある駅を、前記定期券情報を解析して特定する検索条件解析部と、前記検索条件解析部によって特定された駅の周辺の店舗／施設を検索する検索実行部と、前記検索の結果として表示された店舗／施設が選択された際に、前記選択された店舗／施設の情報と共に、前記友達の定期券情報を表示する検索結果表示部と、を備えることを特徴とする。
【００１２】
また、請求項２に係る発明は、請求項１の検索サーバにおいて、前記検索条件解析部は、前記ユーザ及び前記取得された友達の中から選択された特定の者の定期券情報を解析して駅を特定することを特徴とする。
【００１３】
また、請求項３に係る発明は、請求項１又は２の検索サーバにおいて、前記定期券情報は、定期券の区間外であるが前記ユーザ又は前記友達が前記定期券を活用してよく出かける区間である定期券区間外情報を含み、前記検索の結果に表示される友達の定期券情報には、当該定期券を利用してもプラスで発生する交通費を表示することを特徴とする。
【００１４】
また、請求項４に係る発明は、請求項１から３までのいずれか一項に記載の検索サーバにおいて、前記友達情報取得部又は前記定期券情報取得部は、前記ユーザが登録したＳＮＳサイトから、前記友達情報及び／又は前記定期券情報を取得することを特徴とする。
【００１５】
また、請求項５に係る発明は、請求項１から４までのいずれか一項に検索サーバにおいて、前記ユーザから前記検索の結果に表示された友達に、前記検索された店舗／施設に一緒に出かけることを依頼する参加依頼のメッセージを送信し、前記参加依頼を承諾した友達の参加当日の移動履歴を改札口の乗降記録から取得する友達参加依頼部をさらに備えることを特徴とする。
【００１６】
また、請求項６に係る発明は、請求項１から５までのいずれか一項に記載の検索サーバにおいて、前記検索条件解析部は、前記検索クエリから日時情報、場所情報、店舗／施設情報、目的情報を抽出し、検索画面に表示することを特徴とする。
【００１７】
また、請求項７に係る発明は、請求項１から６までのいずれか一項に記載の検索サーバにおいて、前記検索条件解析部は、前記検索条件に目的情報が含まれていることを判定した場合に、前記店舗／施設を前記目的情報と前記ユーザのプロフィールに応じて推定することを特徴とする。
【００１８】
また、請求項８に係る発明は、請求項７の検索サーバにおいて、前記プロフィールは、ユーザの生年月日の情報を含み、前記生年月日を参照して、前記生年月日又は年齢に関連する店舗／施設の検索を実行することを特徴とする。
【００１９】
また、請求項９に係る発明は、請求項１から８までのいずれか一項に記載の検索サーバにおいて、前記検索のためにユーザ独自のエリアを定義させ、前記エリアに含まれる駅を登録させるエリア登録部を更に備えることを特徴とする。
【００２０】
また、請求項１０に係る発明は、検索方法の発明であって、ユーザの端末から、検索クエリ及び検索範囲の駅を検索条件として取得するステップと、前記検索範囲に友達検索が指定されている場合に、前記ユーザの友達情報を取得するステップと、前記ユーザ及び友達の所持する定期券情報を取得するステップと、前記検索範囲の駅を前記ユーザの所持する定期券情報を解析して特定するステップと、前記特定するステップによって特定された駅の周辺の店舗／施設の検索を実行するステップと、前記検索の結果として表示された店舗／施設が選択された際に、前記選択された店舗／施設の情報と共に、前記友達の定期券情報を表示するステップと、を有することを特徴とする。
【発明の効果】
【００２１】
本発明によれば、ユーザ自身及び友達等の定期券情報を加味した検索システムを提供することができる。
【図面の簡単な説明】
【００２２】
【図１】本発明の実施形態に係る検索システムの基本概念を示す図である。
【図２】本発明の実施形態に係る検索システムの機能構成の一例を示す図である。
【図３】本発明の実施形態に係るユーザ情報データベース（ＤＢ）に格納されるデータの構成例を示す図である。
【図４】本発明の実施形態に係る路線情報データベース（ＤＢ）に格納されるデータの構成例を示す図である。
【図５】本発明の実施形態に係る店舗／施設情報データベース（ＤＢ）に格納されるデータの構成例を示す図である。
【図６Ａ】本発明の実施形態に係る検索処理フローを示す図である。
【図６Ｂ】本発明の実施形態に係る検索処理フロー（続）を示す図である。
【図７】本発明の実施形態に係る検索画面及び検索結果表示画面の一例を示す図である。
【図８】本発明の実施形態に係る参加候補者ヘの通知画面の一例を示す図である。
【図９】本発明の実施形態に係る参加者の現在状況を示す画面の一例を示す図である。
【図１０】本発明の実施形態に係る検索画面及び検索結果表示画面の別の一例を示す図である。
【図１１】本発明の実施形態に係る検索画面及び検索結果表示画面のさらに別の一例を示す図である。
【発明を実施するための形態】
【００２３】
以下、添付図面を参照して、本発明を実施するための形態（以下、実施形態）について詳細に説明する。以降の図においては、実施形態の説明の全体を通して同じ要素には同じ番号又は符号を付している。
【００２４】
（基本概念）
図１は、本発明の実施形態に係る検索システム（以下、本検索システムという）の基本構成の概念（イメージ）を示す図である。
【００２５】
本検索システムのユーザは、図示するような検索画面から検索キーワード（検索クエリとも呼ぶ）を入力すると共に、検索クエリとは別に、検索範囲として、「定期券区間内」、「定期券区間外」、「駅名」、「エリア」、「友達も検索」の各欄についてＯＮ／ＯＦＦの指定を行う。例えば、図の例では、「定期券区間内」及び「定期券区間外」をＯＮにしており、ユーザが保持する定期券の区間内にある駅（定期券区間内駅と呼ぶ）と、定期券の区間外ではあるが、定期券を利用してユーザが休日等によく行く区間の駅（定期券区間外駅と呼ぶ）を検索範囲に指定していることを示している。
【００２６】
例えば、ユーザＡさんが東京タワーの近辺に居住しているとし、五反田の勤務先に通うために都営浅草線の「大門−五反田」間の通勤定期を所持しているとすると、定期券区間内の大門−五反田間のすべての駅の周辺が検索範囲となる（図の網掛けで示す）。また、Ａさんは、定期券の区間外ではあるが定期券を活用して、新宿駅若しくは渋谷駅方面又は新橋駅若しくは品川駅方面に休日等に出かけることがよくあるとすると、山手線の新宿−新橋間のすべての駅が定期券区間外として検索対象に加わる（図の一点鎖線で示す）。ただし、ユーザは、自分の定期券区間内の駅と定期券区間外の駅の範囲を予め本検索システムに登録しているものとする。
【００２７】
定期券の区間内及び区間外を検索範囲として指定する以外にも、駅やエリアを特定して検索したいときは、「駅名」又は「エリア」の欄をＯＮにして、検索クエリにその駅名やエリア名を入力してもよい。ここでいう「エリア」は、「新宿」、「渋谷」、「新橋・浜松町・田町」といった検索サイトによって固定された区分ではなく、複数の路線の複数の駅をまとめてひとつのエリアとして登録可能である。この場合、駅名、エリア名は検索クエリに複数入力してもよいし、路線や駅は必ずしも繋がっていなくともよい。例えば、上記のＡさんの場合は、定期券区間の大門−五反田に加え、定期券区間外の新宿、渋谷、品川、新橋等を一つのエリアとして自分専用に登録してもよい。
【００２８】
また、本検索システムでは、図示するように、「友達も検索」の欄をＯＮにすることで、一緒に出かけたい友達等の情報の検索も同時に行うことができる。図の例では、Ａさんが検索クエリに「週末  ショピング」と入力したとすると、週末（土日）にショッピングに一緒に出掛けてくれそうな友達を検索する。友達は、本検索システムに予め登録してもよいし、本検索システムと連携するＳＮＳ（Social  Networking  Service)サイトの「友達リスト」を利用することもできる。
【００２９】
友達情報を検索する（「友達検索」と呼ぶ）場合、Ａさんの友達（Ｂさん、Ｃさんとする）も本検索システムのユーザであり、定期券区間内や定期券区間外の情報を本検索システムに登録していれば、図１の左下の検索結果の画面に示すように、検索範囲のお店の情報が表示されるだけでなく、そのお店に行く場合、各自の定期券をそれぞれ利用したとしても、プラスして必要となる交通費（これを「＋交通費」と呼ぶことにする）が表示される。図の例では、Ｂさんの定期券区間が「渋谷−五反田」であり、Ｃさんの定期券区間が「新橋−大崎」であるとすると、Ａさん、Ｂさん、Ｃさんがすべて定期券の範囲で行ける駅はないものの、「＋交通費」が比較的安い大崎駅、五反田駅、品川駅周辺のお店が検索結果の上位に表示される。
【００３０】
しかし、Ａさんが勤務先近くの大崎駅、五反田駅、品川駅でなく、よく行く渋谷駅の近くにあるお店（例えば図のマル４のお店）を検索画面上でタッチすると、Ｂさん、Ｃさんの定期券区間内の駅から渋谷駅までの「＋交通費」がそれぞれ表示される。目的地までの交通費だけでなく乗換駅や所要時間も表示するようにしてもよいし、定期券に含まれるその他の情報を表示してもよい。また、Ａさんが検索結果画面で別のお店をタッチすると、図の「お友達の検索結果」の「＋交通費」等の表示も変わることになる。図の例の場合は、Ｂさんが渋谷−五反田間の定期を持っているため「＋交通費」がゼロであることが分かり、ＡさんはＢさんを気兼ねなく誘うことができる。このように本検索システムは、ユーザの定期券情報を最大限に活用した検索を行うことができる。
【００３１】
（機能構成）
図２は、本検索システムの機能構成を示す図である。本検索システムは、典型的には、検索サーバ１００を中心に、ユーザ端末２００と、ＳＮＳサイト３００と、外部検索サイト４００とから構成される。この図における機能ブロック間の矢印は、データの流れる方向、又は処理の流れる方向を表すものとする。
【００３２】
検索サーバ１００は一般的なサーバコンピュータであるが、図２に示すように、機能処理部として、ユーザ情報登録部１０、ユーザ移動情報取得部１１、友達情報取得部１２ａ、定期券情報取得部１２ｂ、検索条件取得部１３、検索条件解析部１４、検索実行部１５（検索エンジン）、外部検索サイト連携部１６、検索結果表示部１７、友達参加依頼部１８及びエリア登録部１９を備えている。また、データベース（ＤＢ）として、ユーザ情報ＤＢ２０、路線情報ＤＢ２１、店舗／施設情報ＤＢ２２、エリア別店舗／施設情報ＤＢ２３を備えている。各機能ブロックについて詳しくは後述する。
【００３３】
ユーザ端末２００は、検索サーバ１００に対してユーザの情報を予め登録し、検索条件を入力して検索結果を表示させるための端末で、例えば、携帯電話機、スマートフォン、タブレット端末、パーソナルコンピュータ等である。ここでユーザから登録される情報は、ユーザ端末２００からの入力だけでなく、定期券が電子カードである場合は、ユーザ端末２００にＩＣカードリーダ機能をもたせて、定期券から、定期券区間、乗換駅、保有者の住所氏名、年齢などは半自動的に読込むようにしてもよい。
【００３４】
ＳＮＳサイト３００は、Ｆａｃｅｂｏｏｋ（登録商標）やＴｗｉｔｔｅｒ（登録商標）等のソーシャルネットワークサービスを提供するサイトであり、必須ではないが、ユーザが登録した友達等の情報を検索し取得するのに好都合であるため、検索サーバ１００と連携していることが望ましい。
【００３５】
外部検索サイト４００は、検索サーバ１００の検索機能を補うため、既存の各種の専門検索サイトの総称であり、検索サーバ１００と連携しているものとする。外部検索サイト４００には、交通機関の乗換案内を専門とする乗換案内検索サイト４０１、飲食店の検索を専門に行う飲食店検索サイト４０２、ネット店舗でなく実店舗の検索を専門に行うＧｏｏｇｌｅ（登録商標）ローカルショッピング等の実店舗検索サイト４０３、映画館や劇場などの娯楽施設を専門に検索する娯楽施設検索サイト４０４、ホテルや旅館等の宿泊施設を専門に検索する宿泊施設検索サイト４０５等がある。
【００３６】
以下、検索サーバ１００の機能の処理部について順に説明する。なお、「路線」とは、鉄道の路線及びバス路線を意味し、「駅」とは、鉄道の駅及びバス停を意味するものとする。
【００３７】
検索サーバ１００のユーザ情報登録部１０は、ユーザ端末２００や電子定期券から、ユーザの情報を取得し、登録させる手段を提供する。また、ユーザ移動情報取得部１１は、ユーザが実際に定期券を利用して移動した際に、その移動情報を駅の改札機等から取得する機能を有する。加えて、ユーザ端末２００の位置情報をＧＰＳ(Global  Positioning  System)等から取得する機能を備えていてもよい。したがって、ユーザ移動情報取得部１１は、ユーザが許諾していることを条件に、ユーザが定期券を利用して駅の改札口を通過した日時（改札履歴）や、必要であればユーザの現在位置を随時又は定期的に取得することができる。
【００３８】
友達情報取得部１２ａは、ユーザ情報登録部１０又は外部のＳＮＳサイト３００からユーザの友達情報を取得して、ユーザ情報ＤＢ２０に格納する。定期券情報取得部１２ｂは、同様に、ユーザ情報登録部１０又は外部のＳＮＳサイト３００からユーザの定期券情報を取得して、ユーザ情報ＤＢ２０に格納する。ＳＮＳに登録した情報に友達情報や定期券情報が含まれている場合は、それを有効利用することで、ユーザは本システムに情報を入力する手間を少なくすることができる。ＳＮＳサイト３００から友達情報や定期券情報を取得する場合は、例えば、本検索システムのログインをＳＮＳサイト３００のログインＩＤを使っても行えるようにする。このことにより、ユーザの登録情報や友達リストがＳＮＳからも容易に取得できるようになる。
【００３９】
検索条件取得部１３は、ユーザが入力した検索クエリとその際に指定した検索範囲を取得する。以降では、「検索クエリ」とそのとき指定した「検索範囲」を合わせて「検索条件」ということにする。検索条件取得部１３が取得した検索条件は、検索条件解析部１４に受け渡され、検索条件解析部１４は、検索条件の内容を解析する。具体的には、検索条件のキーワードから、検索の目的情報、場所情報、日時情報を抽出する。例えば、検索クエリが「週末  ショッピング」であれば、ユーザの登録情報を参照して、日時情報が直近の土日であり、目的情報がショッピングであることを特定する。更に、ユーザの年齢、性別、職業などの登録情報があれば、ショッピングの対象となるような店舗等の範囲を推定するようにしてもよい。友達検索が指定されていれば、その登録情報も参照して、ショッピングの帰り等の飲食店等も推定することができる。
【００４０】
また、検索条件解析部１４は、検索範囲に指定された駅を特定する。例えば、図１で示したように、「定期券区間内」と「定期券区間外」の両方が指定されている場合は、ユーザの定期券区間と、定期券区間外でよく行く駅の登録情報から、検索範囲となる路線名、駅名を抽出する。また、検索範囲が「エリア」で指定されている場合は、ユーザが後述のエリア登録部１９によって登録したエリア情報からそのエリア内の駅名、路線名を抽出する。また、検索条件解析部１４は、友達検索が同時に指定されているときは、友達リストをユーザ情報ＤＢ２０又はＳＮＳサイト３００から取得し、その友達の定期券区間内の情報、定期券区間外の情報、その他取得可能な情報も取得しておく。
【００４１】
検索実行部１５は、検索条件解析部１４が解析した検索条件に基づいて、検索を実行する。検索は、検索サーバ１００内の検索エンジンだけでなく、目的情報によっては、外部の専門の検索サイトを利用するようにしてもよい。このとき検索実行部１５は、外部検索サイト連携部１６を介して、外部検索サイト４００に検索を依頼する。ただし、外部の検索サイトが受け付ける検索条件はそれぞれ異なるので、外部検索サイト４００に適合するように、外部検索サイト連携部１６には、検索クエリと検索範囲を調整するための外部検索サイトごとの特性テーブル（図示せず）を有していることが望ましい。検索の実行時には、後述の路線情報ＤＢ２１、店舗／施設情報ＤＢ２２、エリア別店舗／施設情報ＤＢ２３を参照する。
【００４２】
検索結果表示部１７は、本検索システム内部の検索エンジン及び外部検索サイト４００の検索結果を分析し、検索結果を順位付けし、ユーザ端末２００に表示させる機能を有している。このとき、検索条件に友達検索が指定されているときは、取得した友達リストの友達ごとの定期券区間内情報や定期券区間外情報に基づいて、検索結果の場所（店舗、施設等）ごとに、その場所に移動するための各人の交通移動情報（「＋交通費」、所要時間等）を算出する。このとき、乗換案内検索サイト４０１が利用される。
【００４３】
検索結果表示部１７は、上記分析後の内容を検索結果としてユーザ端末に表示する。友達検索が指定されている場合は、ユーザが検索結果の場所のうちの一つを選択すると、それに合わせて、友達検索結果の交通情報も変更する。また、ユーザが検索条件を変更して再検索を行なうことを指示した場合は、検索条件取得部１３に処理を戻す。そして検索条件取得部１３は、新たな検索条件を取得し、同様の検索処理を、検索条件解析部１４、検索実行部１５に再び処理させる。
【００４４】
友達参加依頼部１８は、検索結果表示画面からユーザが友達を誘う手段を有している。具体的には、検索された店舗／施設に一緒に出かけたい友達が表示されている場合、その友達を検索結果の画面から選択して、参加依頼のメッセージを送信する機能を有している。また、参加依頼のメッセージを受信した友達がその依頼を受託した場合は、お出かけ当日の際のその友達の移動履歴を取得する機能を有する。当日の友達の集まり具合をユーザが把握するためである。
【００４５】
エリア登録部１９は、ユーザが複数の路線の複数の駅を自分専用の「エリア」として登録できる手段を提供する。登録するエリアには任意の名称を付けることができ、複数のエリアを登録してもよい。例えば、「新宿大門」という名称のエリアに、山手線の新宿−五反田間、及び都営浅草線の五反田−大門間の間の全ての駅を含ませてもよいし、その区間の主な駅だけを含ませてもよい。或いは周辺の路線の一部の駅を含ませてもよい。登録したエリアは、エリア名とそこに含まれる駅と共にユーザ情報ＤＢ２０に記録され、さらに登録したエリアごとに店舗／施設を紐付けるエリア別店舗／施設情報ＤＢ２３の作成に用いられる。このようにすることで、ユーザは自分専用のエリアを定義し、駅名を１つずつ入力する手間が省けるので検索の効率をあげることができる。
【００４６】
続いてデータベース（ＤＢ）として、ユーザ情報ＤＢ２０、路線情報ＤＢ２１、店舗／施設情報ＤＢ２２、エリア別店舗／施設情報ＤＢ２３を順に説明する。
【００４７】
図３は、本発明の実施形態に係るユーザ情報ＤＢ２０に格納されるデータの構成例を示す図である。ユーザ情報ＤＢ２０には、図示するように、大きく分けて、個人登録情報、定期券情報、移動履歴情報、及び友達情報が含まれる。図の例ではこれらの情報がすべてユーザ情報ＤＢ２０に格納されているものとしているが、それぞれ別のデータベースに格納されるように構成してもちろんよい。
【００４８】
個人登録情報は、ユーザが登録した氏名、生年月日、性別、職業、住所、電話番号、メールアドレス等の個人情報である。個人登録情報には、上記の他、自宅の最寄駅、勤務先住所、勤務先最寄駅、通勤定期券区間、乗換駅等の情報が含まれる。これらの情報は、ユーザが手入力してもよいし、電子定期券を所持している場合は、定期券カードを読込ませて個人情報の一部を入力するようにしてもよい。もちろん、ユーザ端末２００に電子定期券を内蔵する場合は、その情報をユーザ端末２００から直接送信するようにしてもよい。また、個人登録情報には、ユーザが日頃使っているＳＮＳサイトやよく使う検索サイトを登録しておくことが望ましい。ここで登録されたサイトの情報は、前述した友達情報取得部１２ａ、定期券情報取得部１２ｂ、及び外部検索サイト連携部１６で参照される。
【００４９】
ユーザ情報ＤＢ２０の定期券情報は、上記の個人登録情報から定期券に関連する情報を抜き出した定期券区間内情報（符号２０ａの部分）、勤務日（又は通学日）、休日の情報、及び定期券区間外の情報（休日等によく出かける区間の情報）が登録される。定期券区間外情報の路線、駅は複数であってもよいし、定期券区間内とは離れた場所にあってもよい。定期券情報は、ユーザ情報登録部１０から入力してもよいし、ＳＮＳサイト３００に個人情報の一部として登録している場合は、ＳＮＳサイト３００から取得してもよい。
【００５０】
ユーザ情報ＤＢ２０の移動履歴情報は、既に述べたように、定期券が改札機を通過したときの情報（改札履歴）を元に、ユーザが実際に利用した乗降駅とその日時を記録した情報である。また、ＧＰＳ等で取得したユーザ端末２００の位置情報を日時と共に記録してもよい。このようなユーザの移動履歴は、ユーザの許諾の元に、ユーザの行動分析のために利用してもよいし、後述するように、友達等と一緒にお出かけをする際の集まり状況を把握するためにも用いられる。
【００５１】
ユーザ情報ＤＢ２０の友達情報は、ユーザが登録した「友達」の情報（友達情報）が格納される。友達情報は、ＳＮＳサイト３００の友達リスト等から取得してもよいし、新たにユーザ情報登録部１０から入力してもよい。
【００５２】
図４は、本発明の実施形態に係る路線情報ＤＢ２１に格納されるデータの構成例を示す図である。路線情報ＤＢ２１は、路線ごとに駅（駅名、駅ＩＤ）の情報を格納したデータベースである。同じ駅名であっても路線が異なれば別の駅ＩＤが振られるのは言うまでもない。駅の情報には、その駅の時刻表の他、改札口の名称、ＩＤや位置情報が含まれる。また、特に図示していないが、出口の名称、ＩＤやその位置情報も含まれる。路線情報ＤＢ２１は、交通機関のサイトや乗換案内検索サイト４０１からデータを取得することによって随時更新される。
【００５３】
図５は、本発明の実施形態に係る店舗／施設情報ＤＢ２２に格納されるデータの例を示す図である。店舗／施設情報ＤＢ２２は、路線、駅ごとに店舗や施設の情報を集積したデータベースである。店舗／施設情報ＤＢ２２は、複数の外部のサイトからデータを取得することによって随時更新される。
【００５４】
なお、エリア別店舗／施設情報ＤＢ２３については、詳細は省略するが、ユーザが登録したエリアごとに、上記の店舗／施設情報ＤＢ２２に格納された店舗や施設の情報を分類したデータが格納される。
【００５５】
上記の本システムの機能構成は、あくまで一例であり、一つの機能ブロック（データベース及び機能処理部）を分割したり、複数の機能ブロックをまとめて一つの機能ブロックとして構成したりしてもよい。各機能処理部は、サーバ装置に内蔵されたＣＰＵ（Central  Processing  Unit）が、ＲＯＭ（Read  Only  Memory）、フラッシュメモリ、ＳＳＤ(Solid  State  Drive)、ハードディスク等の記憶装置に格納されたコンピュータ・プログラムを読み出し、ＣＰＵにより実行されたコンピュータ・プログラムによって実現される。すなわち、各機能処理部は、このコンピュータ・プログラムが、記憶装置に格納されたデータベース（ＤＢ;Data  Base)やメモリ上の記憶領域からテーブル等の必要なデータを読み書きし、場合によっては、関連するハードウェア（例えば、入出力装置、表示装置、通信インターフェース装置）を制御することによって実現される。また、本発明の実施形態におけるデータベース（ＤＢ）は、商用データベースであってよいが、単なるテーブルやファイルの集合体をも意味し、データベースの内部構造自体は問わないものとする。
【００５６】
（処理フロー）
図６Ａ，６Ｂは、本発明の実施形態に係る検索処理フローを示す図である。以下の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。
【００５７】
検索処理では、まず、検索サーバ１００の検索条件取得部１３が、ユーザ端末２００から検索条件（検索クエリと検索範囲）を取得する（ステップＳ１０）。そして、検索条件解析部１４が、検索条件の中に日時情報があるかを判定する（ステップＳ１１）。日時情報とは、何日何時という明確なものでなくともよく、「週末」、「今度の休み」、「年明けに」とかいったものでもよい。日時情報が検索条件にある場合は、その日時が特定されているかを判定し（ステップＳ１２）、特定されていなければ、その範囲内の日時を推定する（ステップＳ１３）。例えば、「週末の夜」であれば、ユーザの個人登録情報を参照して、直近の土日の１８時以降であると推定する。
【００５８】
次に、日時情報がある場合もない場合もステップＳ１４に進み、今度は場所情報が検索条件にあるかを判定する。場所情報がない場合は、検索者（ユーザ）の現在位置をＧＰＳ等で取得し、現在地周辺の駅リストを作成する（ステップＳ１５）。駅リストとは、検索対象とする駅をすべて含んだリストのことである。場所情報がある場合は、その場所情報が路線又は駅を指定しているかどうかを判定する（ステップＳ１６）。路線又は駅を指定している場合は、指定された範囲内の駅を抽出し、駅リストを作成する（ステップＳ１７）。
【００５９】
ステップＳ１６において、路線又は駅を指定していない場合は、エリアが指定されているかどうかを判定する（ステップＳ１８）。既に述べたように、エリアはユーザが独自に定義可能であるが、ユーザがエリアを特に定義していない場合は、デフォルトの定義が用いられる。例えば、エリアを単に「渋谷」と指定した場合は、各路線の渋谷駅全体又は渋谷区にある駅がすべて検索対象となる。エリアが検索条件に指定されている場合は、そのエリア内の駅を、ユーザのエリアの定義に基づいて抽出し、駅リストを作成する（ステップＳ１９）。ステップＳ１８でエリアが指定されていないと判定した場合は、場所情報が指定されていないことになるので、ステップＳ１５に移り、現在地周辺の駅を検索対象とする。
【００６０】
場所情報の処理（ステップＳ１４〜Ｓ１９）が終わると、ステップＳ２０に移り、今度は店舗／施設情報が検索条件にあるかを判定する。店舗／施設情報がない場合は、目的情報があるかを判定する（ステップＳ２１）。目的情報とは、日時情報、場所情報以外で、検索の目的を判定できる情報のことである。例えば、店や施設を指定していなくとも、「飲み会」、「女子会」、「歓迎会」、「忘年会」、「新年会」、「誕生会」、「ぶらり歩き」、「デート」等が目的情報となる。
【００６１】
ステップＳ２１において、目的情報もないと判定された場合は、検索対象が不明と判断し、検索条件の再入力を要求し（ステップＳ２２）、ステップＳ１０に戻る。ステップＳ２１で目的情報があると判定された場合は、その目的情報に応じて店舗／施設を推定する（ステップＳ２３）。
【００６２】
例えば、目的が「飲み会」であれば、居酒屋、料理店、バーなどが推定されるが、ユーザの個人登録情報のプロフィールを参照して、ユーザの予算に合いそうな店舗を中心に検索するようにしてもよい。また、友達検索が指定されていれば、その友達のプロフィールをさらに参照してもよい。そして、推定された店舗／施設に応じて、必要であれば外部の検索サイトを決定する（ステップＳ２４）。ステップＳ２０において、店舗／施設情報があると判定された場合は、指定された店舗／施設に応じて、必要であれば外部の検索サイトを決定する（ステップＳ２５）。
【００６３】
検索実行部１５は、上記で決定された検索サイト又は自らの検索エンジンによって店舗／施設の検索を実行し、その検索結果を取得する（ステップＳ２６）。この検索においては、路線情報ＤＢ２１、店舗／施設情報ＤＢ２２、エリア別店舗／施設情報ＤＢ２３を参照する。また、外部の検索サイトを利用するときは、外部検索サイト連携部１６が外部検索サイトの特性に応じて検索クエリを作成し、検索を実行させる。そして検索実行部１５は、上記のステップＳ２０〜Ｓ２６を、駅リストの全駅について実行したかを判定し（ステップＳ２７）、全駅について終了していなければ検索する駅のＩＤを変更し（ステップＳ２８）、ステップＳ２０に戻る。全駅について処理を完了していれば、図６ＢのステップＳ３０に移る。
【００６４】
次に検索結果表示部１７は、図６ＢのステップＳ３０では、友達検索の指定があるかどうかを判定する。友達検索の指定があれば、登録ＳＮＳサイト又はユーザ情報ＤＢ２０から、友達の情報を取得し（ステップＳ３１）、ステップＳ４１にスキップする。
【００６５】
ステップＳ３０で友達検索の指定がないと判定される場合は、ステップＳ３２に移り、目的情報が検索条件の中にあるかを判定する。目的情報が宴会の場合（ステップＳ３３：Ｙ）、その宴会の種類に応じて、登録ＳＮＳ等からその宴会にふさわしいと考えられるメンバを抽出し、参加候補者に指定する（ステップＳ３４〜Ｓ３９）。例えば、歓送会であれば同僚を、同窓会であれば同窓会メンバを、女子会であれば女性の友達を抽出して参加候補者に指定する。図示していないが、歓送会、同窓会、女子会以外の宴会についても、ステップＳ３４〜Ｓ３９と同様の処理が続く。
【００６６】
そして、参加候補者にユーザ自身（検索実行者）も指定する（ステップＳ４０）。参加候補者の指定が終わると、ステップＳ４１に進む。なお、図のフローでは、目的情報が宴会でない場合は、参加候補者を抽出していないが、目的情報によって参加候補者を抽出できる場合は、その目的に応じて参加候補者を抽出するようにしてもよい。
【００６７】
次に検索結果表示部１７は、ステップＳ４１では定期券区間の指定があるかを判定する。定期券区間の指定がなければステップＳ４４にスキップする。定期券区間の指定がある場合は、参加候補者が定期券情報を登録していれば、その定期券情報を取得し（ステップＳ４２）、参加候補者の交通費（定期券情報を登録している参加候補者の場合は「＋交通費」）を算出する（ステップＳ４３）。
【００６８】
そして、算出された交通費を含む参加候補者の情報を検索結果に表示する（ステップＳ４４）。また、友達参加依頼部１８は、次にステップＳ４５で、参加候補者にメッセージ（ＳＭＳ又はメール）を送る指定があるかどうかを判定し、指定があれば参加候補者を検索結果の中からユーザに選択させ、参加依頼や参加者募集のメッセージを送信する（ステップＳ４６）。その後、友達参加依頼部１８は、参加者の集まり具合を検出する機能を有するが、これについては後述の画面で説明することにする。以上で、検索サーバ１００が行う主な処理が終了する。
【００６９】
（画面例）
図７は、本発明の実施形態に係る検索画面及び検索結果表示画面の一例を示す図である。図７の検索画面５００は、定期券の情報を検索にプラスする、付加価値を検索にプラスする、という意味を込め、「検索！定期券＋＋」と命名している。
【００７０】
ユーザは、図示するような検索クエリ５０１の領域に、キー入力又は音声入力によって検索キーワード又は自然言語を入力する。このとき、既に述べたように、符号５０２で示す検索範囲の指定で、「定期券区間内」、「定期券区間外」、「駅名」、「エリア」、「参加候補者も検索」の各項目に対してＯＮ／ＯＦＦを指定する。
【００７１】
検索結果画面５１０には、お店候補５１１が表示される。また、「参加候補者も検索」（友達検索）がＯＮのときは、参加候補者５１２が表示される。ユーザが検索結果に表示されたお店候補５１１の店を選択すると、参加候補者の名前と定期券情報と共に、「＋交通費」が図示するように表示される。「＋交通費」が余分にかかる参加候補者は斜線で示されている。
【００７２】
なお、特に図示してないが、友達検索を利用する場面としては、定期券情報から友達の誕生日の情報を取得して誕生会を企画し、さらにバースデーサービスのあるお店を検索するようにしてもよい。また、友達のプロフィール自体を検索条件としてもよい。例えば、「○○１００周年記念」のような宴会があったとすると、年齢の合計が１００歳になる友達の組合せを検索して記念品を送るなどしてもよい。このように、定期券情報等から得られる友達の生年月日の情報を参照して、誕生日や年齢に関連する店舗／施設の検索を実行することができる。
【００７３】
ユーザが検索条件を変えたいときは、「条件を変えて再検索」ボタン５１３を押すと、検索画面５００に戻る。また、ユーザが表示された検索結果から店を決定し、参加者を選択して、「参加候補者にメッセージを送る」ボタン５１４を押すと、選択された参加者へ通知メッセージが送信される。このときマイクボタン５１５を押すと、直接メッセージを音声入力できる。
【００７４】
図８は、本発明の実施形態に係る参加候補者ヘの通知画面の一例を示す図である。図示する参加者通知画面５２０には、ユーザ（ハルヨさん）が参加を依頼する友達のフユコさんに対して送ったメッセージが表示されている。この例の通知メッセージエリア５２１には、ハルヨさんからのメッセージと共に、日時、場所、詳細情報へのリンクが表示されている。
【００７５】
また、この画面の移動交通情報５２２には、フユコさんの推奨移動ルートと所要時間、「＋交通費」が表示され、同時にフユコさんの定期券情報５２３（定期券区間内と定期券区間外でよく行く区間）と共に表示される。もちろん、フユコさんは、この画面から参加の承諾又は不参加の意思表示をすることができる。
【００７６】
図９は、本発明の実施形態に係る参加者の現在状況を示す画面の一例を示す図である。図示する集まり状況通知画面５３０は、検索者（ハルヨさん）が、自らが招集した女子会が始まる時刻の直前に、参加者の集まり状況を確認するために表示した画面である。図で示すように、ナツヨさんは、休日によく行く渋谷にまだ居ること、アキコさんは、現在お店に向かっていること、フユコさんは、約束を忘れていそうなことが一目で確認できる。この画面を見たハルヨさんは、ナツヨさんとフユコさんにここから電話をかけることもできる。
【００７７】
図１０は、本発明の実施形態に係る検索画面及び検索結果表示画面の別の一例を示す図である。図示する検索画面５００Ａは、検索サーバ１００が検索クエリ５０１Ａで必要とする日時情報、場所情報、店舗／施設情報、目的情報を明示的に選択して指定できるようにした画面である。それぞれの情報の項目は、ポップアップから選択、キー入力、音声入力のいずれで行ってもよい。
【００７８】
また、この画面の例では、検索範囲５０２Ａのうち、「参加候補者も検索」以外の項目のＯＮ／ＯＦＦの状況によって、検索クエリ５０１Ａの場所情報で選択できるポップアップメニューが変更されるようになっている。例えば、図では「エリア」がＯＮになっているので、場所情報欄には、ユーザが登録したエリアの駅が選択肢として表示される。ただし、ここではユーザが「品川―五反田」間の駅を１つのエリアと登録しているものとしている。複数のエリアを登録しているときは場所情報の選択肢も複数になる。
【００７９】
また、参加候補者５１２Ａでは、図７の場合と異なり、検索クエリで目的情報が「送別会」と指定されているので、参加候補者には、登録ＳＮＳ等から同僚が抽出されている。
【００８０】
図１１は、本発明の実施形態に係る検索画面及び検索結果表示画面のさらに別の一例を示す図である。図示する検索画面５００Ｂは、検索サーバ１００が検索クエリ５０１Ｂに入力された内容から日時情報、場所情報、店舗／施設情報、目的情報を抽出して表示した画面である。
【００８１】
図１０の検索画面５００Ａの場合は、日時情報や場所情報等をすべてユーザが明示的に指定するものとしたが、図１１の検索画面５００Ｂ場合は、逆に検索クエリから日時情報や場所情報等を抽出する。すなわち、図１１の例では、検索クエリ５０１Ｂの中の「Ｔさんの誕生会」というキーワードから、日時情報がＴさんの誕生日である１２月１２日であると自動的に判定し、さらに目的情報が誕生会であると判定する。また「渋谷−新宿間」というキーワードから、検索範囲の駅名を判定し、「イタリアン」というキーワードから、店舗の種類が判定できる。ユーザは、抽出結果５０２Ｂの内容を見て、システムが正しく検索クエリを認識していることを確認する。ユーザは、検索クエリから抽出できなかった情報がある場合にのみ、抽出結果５０２Ｂの項目を入力すればよい。
【００８２】
また、図１１の例では、検索結果画面５１０Ｂの参加候補者欄５１２Ｂに、各参加者の年齢も表示されている。この結果を見た検索者であるＳさんは、参加候補者の年齢の合計が１０９歳であることに気がつき、誕生会の記念に渋谷１０９で買物もしようという企画を思いついた様子が示されている。もちろん、この企画を参加候補者にも参加依頼メッセージとしてこの画面から送信できる。このように本検索システムは、単に検索を行うだけでなく、検索結果からさらに新たなアイデアが生まれるように手助けとなることもできる。
【００８３】
（実施形態の効果）
本検索システムによれば、通常の店舗／施設の検索結果と共に、定期券情報を活用して、一緒にお出かけをしたい友達も同時に検索することができ、ユーザ自身及び友達等の定期券情報を加味した新しい検索システムを提供することができる。
【００８４】
また、定期券情報には、定期券の区間内の駅だけでなく、定期券を活用してよく出かける区間外の駅も含ませることができるので、ユーザの行動範囲の中で、より広い範囲を検索対象とすることができる。また、このとき検索で選択された店舗／施設に友達が行く際に定期券を利用してもプラスで発生する交通費を表示するので、友達を誘うときの参考にできる。
【００８５】
また、検索結果の画面から一緒にお出かけをしたい友達に参加を依頼することができ、また参加依頼に対する承諾を受信することができる。また、参加依頼を承諾した友達の参加当日の移動履歴を改札口の乗降記録から取得することができる。
【００８６】
また、検索クエリから日時情報、場所情報、店舗／施設情報、目的情報を自動的に抽出し、検索画面に表示するので、ユーザは検索クエリが正しく認識されているかどうかを確認することができる。検索クエリを自然言語で入力したような場合には特に有用である。
【００８７】
また、検索条件に目的情報が含まれているかどうかを判定し、目的情報が含まれている場合は、その目的とユーザのプロフィールに合った店舗／施設を推定し、検索することができる。
【００８８】
また、友達情報や定期券情報は、本システムに新た登録してもよいが、ＳＮＳサイトに既に登録されている場合は、その情報を取得することで、新たな登録入力の手間が減少する。
【００８９】
また、友達の定期券情報等から得られるプロフィールに、生年月日が含まれる場合は、誕生日や年齢に関連する会（誕生会や記念会等）をユーザが企画する手助けになることができ、そのための店舗／施設も同時に検索することができる。
【００９０】
また、検索のためにユーザ独自の「エリア」を定義することで、そのエリア名を指定するだけで駅の検索を効率よく行うことができる。
【００９１】
以上、実施形態を用いて本発明を説明したが、本発明の技術的範囲は上記実施形態に記載の範囲に限定されないことは言うまでもない。上記実施形態に、多様な変更又は改良を加えることが可能であることが当業者に明らかである。またその様な変更又は改良を加えた形態も本発明の技術的範囲に含まれ得ることが、特許請求の範囲の記載から明らかである。なお、上記の実施形態では、本発明を物の発明として検索システムを説明したが、本発明は、方法の発明（検索方法）としても捉えることもできる。
【符号の説明】
【００９２】
１０  ユーザ情報登録部
１１  ユーザ移動情報取得部
１２ａ  友達情報取得部
１２ｂ  定期券情報取得部
１３  検索条件取得部
１４  検索条件解析部
１５  検索実行部
１６  外部検索サイト連携部
１７  検索結果表示部
１８  友達参加依頼部
１９  エリア登録部
２０  ユーザ情報ＤＢ
２１  路線情報ＤＢ
２２  店舗／施設情報ＤＢ
２３  エリア別店舗／施設情報ＤＢ
１００  検索サーバ
２００  ユーザ端末
３００  ＳＮＳサイト
４００  外部検索サイト
４０１  乗換案内検索サイト
４０２  飲食店検索サイト
４０３  実店舗検索サイト
４０４  娯楽施設検索サイト
４０５  宿泊施設検索サイト
５００，５００Ａ，５００Ｂ  検索画面
５１０，５１０Ａ，５１０Ｂ  検索結果画面
５２０  参加者通知画面
５２１  メッセージエリア
５２２  移動交通情報
５２３  定期券情報
５３０  集まり状況通知画面
【図１】
0006427008.tif 000002
【図２】
0006427008.tif 000003
【図３】
0006427008.tif 000004
【図４】
0006427008.tif 000005
【図５】
0006427008.tif 000006
【図６Ａ】
0006427008.tif 000007
【図６Ｂ】
0006427008.tif 000008
【図７】
0006427008.tif 000009
【図８】
0006427008.tif 000010
【図９】
0006427008.tif 000011
【図１０】
0006427008.tif 000012
【図１１】
0006427008.tif 000013