(57)【要約】      （修正有）【課題】旅行の地域や時期を気学により定めて、その時期および地域の宿泊施設を検索するに旅行用検索システムにおいて、利用者の目的に応じた柔軟な検索を簡易に行う。【解決手段】気学に基づいて旅行の地域又は時期を検索する気学検索手段７と、宿泊施設を検索する施設検索手段８とを備え、気学検索手段７によって検索された旅行の地域又は時期に基づいて宿泊施設を検索する旅行用検索システムであって、旅行したい地域を入力させる地域入力機能と、旅行したい時期を入力させる時期入力機能との少なくとも２つの機能を有し、旅行したい時期が入力されている場合には、利用者の生年月日から判明する本命星に基づいて、上記入力された時期に吉方となる地域を検索する。旅行したい地域が入力されている場合には、上記本命星に基づいて、上記入力された地域が吉方となる時期を検索するように前記気学検索手段７を構成する。【選択図】図１
2012123701.tif 000002
【特許請求の範囲】
【請求項１】
情報の入力を行う入力手段（２）と、気学に基づいて旅行の地域又は時期を検索する気学検索手段（７）と、記憶装置（１６）に記憶されている宿泊施設の情報から利用者が旅行する際の宿泊施設を検索する施設検索手段（８）とを備え、気学検索手段（７）によって検索された旅行の地域又は時期に基づいて宿泊施設を検索するように前記施設検索手段（８）を構成した旅行用検索システムであって、入力手段（２）が、旅行したい地域を入力させる地域入力機能と、旅行したい時期を入力させる時期入力機能との少なくとも２つの機能を有し、旅行したい時期が入力されている場合には、上記利用者の生年月日から判明する本命星に基づいて、上記入力された時期に吉方となる地域を検索するとともに、旅行したい地域が入力されている場合には、上記本命星に基づいて、上記入力された地域が吉方となる時期を検索するように前記気学検索手段（７）を構成した旅行用検索システム。
【請求項２】
入力手段（２）が、向上させたい運気の種類を入力させる運気入力機能を有し、前記気学検索手段（７）は、運気の種類が入力されている場合には該運気の種類に応じた方位に位置する地域を検索する請求項１に記載の旅行用検索システム。
【請求項３】
旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合には、向上させたい運気の種類よりも旅行したい地域を優先し、旅行したい地域よりも旅行したい時期を優先し、優先した項目に基づいて検索を行うように気学検索手段（７）を構成した請求項２に記載の旅行用検索システム。
【請求項４】
旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合に、何れかの項目に基づいて旅行の地域又は時期を検索するかを選択させるように気学検索手段（７）を構成した請求項２に記載の旅行用検索システム。
【請求項５】
複数の利用者が一緒に旅行するために、上記旅行したい時期に吉方となる地域を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる地域を共通地域として検索し、利用者全てが吉方となる地域が無い場合には、前記複数の利用者全てが天道の方位となる地域を共通地域として検索するように前記気学検索手段（７）を構成した請求項１乃至４に記載の旅行用検索システム。
【請求項６】
利用者全てが天道の方位となる地域が無い場合には、複数の利用者の何れかが吉方となる地域を選択肢として表示し、該選択肢中から旅行の地域を選択できるように前記気学検索手段（７）を構成した請求項５に記載の旅行用検索システム。
【請求項７】
複数の利用者が一緒に旅行するために、上記旅行したい地域が吉方となる時期を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる時期を共通時期として検索し、利用者全てが吉方となる時期が無い場合には、該旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期を共通時期として検索するように前記気学検索手段（７）を構成した請求項１乃至６に記載の旅行用検索システム。
【請求項８】
前記旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期が無い場合には、複数の利用者の何れかが吉方となる時期を選択肢として表示し、該選択肢中から旅行の時期を選択できるように前記気学検索手段（７）を構成した請求項７に記載の旅行用検索システム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、旅行用検索システムに関する。
【背景技術】
【０００２】
情報の入力を行う入力手段と、記憶装置に記憶されている宿泊施設の情報から利用者が旅行する際の宿泊施設を検索する施設検索手段とを備え、入力手段を介して入力された旅行の時期や地域情報から宿泊施設を検索する旅行用検索システムが従来公知である。
【０００３】
また、さらにこれを改良したものとして、気学に基づいて旅行の地域又は期間を検索する気学検索手段を設け、気学検索手段によって検索された旅行先の地域又は期間に基づいて宿泊施設を検索するように前記施設検索手段を構成し、縁起の良い旅行を容易に計画することが可能な特許文献１に示す旅行用検索システムが公知になっている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００７−１８３８７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、上記特許文献の旅行用検索システムは、検索画面に表示された入力項目の全てに情報を入力することが必須であり、仮に異なる目的で検索を行う場合には、別の検索画面を用いる必要があるため、目的に応じて、柔軟な検索を簡易的に行うことが難しいという問題がある。
本発明は、旅行の地域や時期を気学により定めて、その時期および地域の宿泊施設を検索するに旅行用検索システムにおいて、利用者の目的に応じた柔軟な検索を簡易に行うことが可能な旅行用検索システムを提供することを課題とする。
【課題を解決するための手段】
【０００６】
上記課題を解決するため、第１に、情報の入力を行う入力手段２と、気学に基づいて旅行の地域又は時期を検索する気学検索手段７と、記憶装置１６に記憶されている宿泊施設の情報から利用者が旅行する際の宿泊施設を検索する施設検索手段８とを備え、気学検索手段７によって検索された旅行の地域又は時期に基づいて宿泊施設を検索するように前記施設検索手段８を構成した旅行用検索システムであって、入力手段２が、旅行したい地域を入力させる地域入力機能と、旅行したい時期を入力させる時期入力機能との少なくとも２つの機能を有し、旅行したい時期が入力されている場合には、上記利用者の生年月日から判明する本命星に基づいて、上記入力された時期に吉方となる地域を検索するとともに、旅行したい地域が入力されている場合には、上記本命星に基づいて、上記入力された地域が吉方となる時期を検索するように前記気学検索手段７を構成したことを特徴としている。
【０００７】
第２に、入力手段２が、向上させたい運気の種類を入力させる運気入力機能を有し、前記気学検索手段７は、運気の種類が入力されている場合には該運気の種類に応じた方位に位置する地域を検索することを特徴としている。
【０００８】
第３に、旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合には、向上させたい運気の種類よりも旅行したい地域を優先し、旅行したい地域よりも旅行したい時期を優先し、優先した項目に基づいて検索を行うように気学検索手段７を構成したことを特徴としている。
【０００９】
第４に、旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合に、何れかの項目に基づいて旅行の地域又は時期を検索するかを選択させるように気学検索手段７を構成したことを特徴としている。
【００１０】
第５に、複数の利用者が一緒に旅行するために、上記旅行したい時期に吉方となる地域を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる地域を共通地域として検索し、利用者全てが吉方となる地域が無い場合には、前記複数の利用者全てが天道の方位となる地域を共通地域として検索するように前記気学検索手段７を構成したことを特徴としている。
【００１１】
第６に、利用者全てが天道の方位となる地域が無い場合には、複数の利用者の何れかが吉方となる地域を選択肢として表示し、該選択肢中から旅行の地域を選択できるように前記気学検索手段７を構成したことを特徴としている。
【００１２】
第７に、複数の利用者が一緒に旅行するために、上記旅行したい地域が吉方となる時期を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる時期を共通時期として検索し、利用者全てが吉方となる時期が無い場合には、該旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期を共通時期として検索するように前記気学検索手段７を構成したことを特徴としている。
【００１３】
第８に、前記旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期が無い場合には、複数の利用者の何れかが吉方となる時期を選択肢として表示し、該選択肢中から旅行の時期を選択できるように前記気学検索手段７を構成したことを特徴としている。
【発明の効果】
【００１４】
上記構成によれば、旅行したい時期が入力されている場合には該時期に吉方となる地域が検索される一方で、旅行したい地域が入力されている場合には該地域が吉方となる時期を検索される。このため、旅行時期が既に決まっている状態で、旅行の地域を求めたい場合と、旅行地域が既に決まっている状態で、旅行の時期を求めたい場合との両方に、１つの検索画面で対応することが可能であり、利用者の目的に応じた柔軟な検索を簡易に行うことが可能になる。
【００１５】
また、入力手段が、向上させたい運気の種類を入力させる運気入力機能を有し、前記気学検索手段は、運気の種類が入力されている場合には該運気の種類に応じた方位に位置する地域を検索することにより、特定の種類の運気を向上させる目的の旅行にも対応可能になるため、さらに利便性が向上する。
【００１６】
また、旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合には、向上させたい運気の種類よりも旅行したい地域を優先し、旅行したい地域よりも旅行したい時期を優先し、優先した項目に基づいて検索を行うように気学検索手段を構成するか、又は、旅行したい時期と、旅行したい地域と、向上させたい運気の種類との内、２つ以上の項目が入力手段を介して入力された場合に、何れかの項目に基づいて旅行の地域又は時期を検索するかを選択させるように気学検索手段を構成すれば、必要以上の情報が入力された場合にも対応可能になるため、より柔軟な検索が可能になる。
【００１７】
さらに、複数の利用者が一緒に旅行するために、上記旅行したい時期に吉方となる地域を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる地域を共通地域として検索し、利用者全てが吉方となる地域が無い場合には、前記複数の利用者全てが天道の方位となる地域を共通地域として検索するように前記気学検索手段を構成し、利用者全てが天道の方位となる地域が無い場合には、複数の利用者の何れかが吉方となる地域を選択肢として表示し、該選択肢中から旅行の地域を選択できるように前記気学検索手段を構成すれば、旅行したい時期が定まっているケースにおいて、利用者が複数の場合にも対応可能になるため、汎用性がさらに向上する。
【００１８】
なお、複数の利用者が一緒に旅行するために、上記旅行したい地域が吉方となる時期を検索するにあたっては、各人の本命星に基づいて前記複数の利用者全てが吉方となる時期を共通時期として検索し、利用者全てが吉方となる時期が無い場合には、該旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期を共通時期として検索するように前記気学検索手段を構成し、前記旅行したい地域が前記複数の利用者全てに対して天道の方位となる時期が無い場合には、複数の利用者の何れかが吉方となる時期を選択肢として表示し、該選択肢中から旅行の時期を選択できるように前記気学検索手段を構成すれば、旅行したい地域が定まっているケースにおいて、利用者が複数の場合にも対応可能になるため、汎用性がさらに向上する。
【図面の簡単な説明】
【００１９】
【図１】本発明を適用した旅行用検索・予約システムのブロック図である。
【図２】本発明を適用した旅行用検索・予約システムの処理の流れを示す説明図である。
【図３】本旅行用検索・予約システムを搭載したコンピュータの構成図である。
【図４】会員データベース及び施設データベースのデータ構造を示す概念図である。
【図５】（Ａ）は、方位盤の構成を示すものであり、（Ｂ）は、方位盤における九星の配置構成を示す概念図であり、（Ｃ）は、（Ｂ）の具体例である。
【図６】九星気学により吉方位を求める手順を示したフロー図である。
【図７】（Ａ）は、相生五行の関係を示す概念図であり、（Ｂ）は相克五行の関係を示す概念図である。
【図８】認証手段の処理フロー図である。
【図９】気学検索手段の処理フロー図である。
【図１０】単独検索のサブルーチンの処理フロー図である。
【図１１】複数人検索のサブルーチンの処理フロー図である。
【図１２】施設検索手段の処理フロー図である。
【図１３】予約手段の処理フロー図である。
【発明を実施するための形態】
【００２０】
図１は、本発明を適用した旅行用検索・予約システムのブロック図である。同図に示す通り、旅行用検索・予約システム１は、利用者が使用する利用者側端末Ａに対して情報のやり取りを行う入出力手段（入力手段）２と、利用者の会員登録および会員登録した利用者のユーザ認証を行う認証手段３と、会員登録した利用者の情報が記憶された会員データベース４と、宿泊施設及び観光施設の情報が記憶された施設データベース５と、宿泊施設側端末Ｂ１及び観光施設側端末Ｂ２から上記施設データベースにアクセスするためのアクセス手段６と、気学に基づいて旅行の地域又は時期を検索する気学検出手段７と、該気学検出手段７によって検索された旅行の時期及び地域に基づいて施設データベース５から宿泊施設を検索する施設検索手段８と、施設検索手段８によって検索された宿泊施設の内から予約を行う予約手段９と、予め定められた所定の時期に各種連絡を行う連絡手段１１とを備えている。
【００２１】
上記利用者側端末Ａ、宿泊施設側端末Ｂ１及び観光施設側端末Ｂ２は、それぞれホームページを閲覧可能なパソコンやスマートフォン等の情報端末であって、この内、利用者側端末Ａは旅行を希望する利用者が使用する情報端末であり、宿泊施設側端末Ｂ１はホテルや旅館等の宿泊施設の担当者が使用する情報端末であり、観光施設側端末Ｂ２はレジャー施設等の観光施設の担当者が使用する情報端末である。
【００２２】
上記会員データベース４及び施設データベース５は、ＳＱＬ（登録商標）やＯｒａｃｌｅ（登録商標）等のリレーショナブルデータベースにより実現され、従来公知のデータ構造を有している。
【００２３】
上記入出力手段２は、ウェブサーバ機能を有しており、利用者側端末Ａは、この入出力手段によって提供されるホームページを介して、本旅行用検索・予約システム１にアクセス可能になる。
【００２４】
上記アクセス手段６は、外部から施設データベース５にアクセスすることを可能にする機能を有し、ウェブサーバ等によって実現される。このアクセス手段６を介して、宿泊施設側端末Ｂ１又は観光施設側端末Ｂ２から、自身の施設情報の追記や編集を行うことが可能になる。この他、アクセス手段６にウェブサーバが実装されていない場合には、宿泊施設側端末Ｂ１及び観光施設側端末Ｂ２に、アクセス手段６に接続するための専用のアプリケーションをインストールする必要がある。ちなみに、宿泊施設側端末Ｂ１や観光施設側端末Ｂ２からアクセス手段への接続の際には、ユーザ認証等を行っても良いし、通信の暗号化等を行ってもよい。
【００２５】
上記認証手段３は、入出力手段に接続された利用者側端末Ａの利用者に対して、会員データベース４に登録されているユーザ情報（具体的には、ログインＩＤ及びログインパスワード）に基づいてユーザ認証を行う他、該利用者の新規の会員登録情報を会員データベース４に記憶するように構成されている。
【００２６】
上記気学検索手段７、施設検索手段８及び予約手段９は、認証手段３によるユーザの認証がＯＫである（認証処理が完了した）場合に、利用可能になり、一又は複数の利用者に対して、気学検索手段７による旅行地域及び時期の選定→施設検索手段８による宿泊施設の選定→予約手段９による宿泊施設の予約の処理を、順次行う。それぞれの処理内容については、後述する。
【００２７】
図２は、本発明を適用した旅行用検索・予約システムの処理の流れを示す説明図である。認証手段３による認証処理が完了した利用者側端末Ａは、まず、希望する旅行の地域と、希望する旅行の時期と、向上させたい運気の種類との３つの入力項目の内、少なくとも１つ以上の項目を入力し、気学検索手段７により、縁起の良い旅行の地域及び時期を検索し、その中から、旅行の地域及び時期を選定し、この選定された旅行地域及び旅行時期を施設検索手段８に渡す。
【００２８】
すなわち、入出力手段２は、希望の旅行地域を入力する欄をホームページの検索画面に表示することにより旅行したい地域を入力させる地域入力機能と、希望の旅行時期を入力する欄をホームページの検索画面に表示することにより旅行したい時期を入力させる時期入力機能と、旅行に際して向上させたい運気の種類を入力する欄をホームページの検索画面に表示することにより向上させたい運気の種類を入力させる運気入力機能と、を有している。
【００２９】
施設検索手段８は、選定された旅行地域及び宿泊施設の情報を受取ることにより、処理を開始し、選定された旅行地域及び宿泊施設の情報に基づいて、施設データベース５に記憶された宿泊施設のなかから、条件に合致する宿泊施設を検索し、その結果を、検索を行っている利用側端末Ａのホームページの検索結果画面に表示する。
【００３０】
利用者は、利用側端末Ａのホームページの検索結果画面を見て、一又は複数回の再検索を行うか、または検索結果画面の宿泊施設一覧から一の宿泊施設を選択して予約を行う。
【００３１】
再検索にあたっては、気学検索手段７を介して選定した旅行の地域及び時期に反しない範囲で、宿泊人数、大人と子供や男性と女性の構成、地域のさらなる絞込みやその変更、時期のさらなる絞込みやその変更、希望宿泊料金の設定・変更等の再検索条件の入力し、施設検索手段８を用いて、再検索を行う。再検索が行われると、その検索結果が、再度、ホームページの検索結果画面に表示される。
【００３２】
このようにして、ホームページの検索結果画面に表示された宿泊施設の一覧から、一の宿泊施設を選択すると、予約手段９の処理が開始される。
【００３３】
予約手段９は、利用者側端末Ａのホームページに表示された予約画面に、必要事項を入力し、予約を行われると、予約処理を実行し、該予約情報を施設データベース５に記憶し、予約を実行した会員の電子メールアドレス宛に予約完了メールを送信するとともに、予約した宿泊施設の電子メールアドレス宛に予約受付メールを送信し、一連の処理を完了する。
【００３４】
図３は、本旅行用検索・予約システムを搭載したコンピュータの構成図である。同図に示す通り、上記旅行用検索・予約システム１を搭載するコンピュータ１２は、従来公知のコンピュータと同様に、ＣＰＵ１３と、ＲＡＭメモリ１４と、ハードディスクやフラッシュメモリ等からなる記憶装置１６と、マウスやキーボードやタッチパネル等からなるユーザーインターフェース１７と、ＴＣＰ／ＩＰ等をサポートしたネットワークインターフェース１８とを備え、ＲＡＭメモリ１４又は記憶装置１６のスワップ領域上でオペレータティングシステム１９が起動されている。
【００３５】
このオペレータティング１９上には、ウェブサーバ２１や、データベースサーバ２２や、ＳＭＴＰサーバ２３や、ＣＲＯＮ等のデーモンプロセス２４等が、サービスとして常住し、バックグランドで実行されている。
【００３６】
データベースサーバ２２には、会員データベース４及び施設データベース５が実装されており、ウェブサーバ２１には、認証手段３を実行する認証アプリケーション２６と、気学検索手段７を実行する気学検索アプリケーション２７と、施設検索手段８を実行する施設検索アプリケーション２８と、予約手段９を実行する予約アプリケーション２９とが、ＣＧＩやＪａｖａ（登録商標）ｓｃｒｉｐｔや通常のＨＴＭＬ言語等によって、実装されている。
【００３７】
ウェブサーバ２１は、データベースサーバ２２にアクセス可能に構成されるとともに、ＳＭＴＰサーバ２３を介して電子メールを送信可能に構成されており、これによって、認証アプリケーション２６又は気学検索アプリケーション２７実行時の会員データベース４へのアクセスや、施設検索アプリケーション２８又は予約アプリケーション２９実行時の施設データベース５へのアクセスや、予約アプリケーション２８実行時の電子メール送信が可能になる。
【００３８】
ＣＲＯＮ等のデーモンプロセス２４によって、上記連絡手段１１を実行する連絡アプリケーションが所定間隔毎に実行される。この連絡手段１１は、データベースサーバ２２から情報を取得可能であるとともに、ＳＭＴＰサーバ２３を介して電子メールを送信可能に構成されている。これによって、会員データベース４に登録された各会員に、縁起のよい旅行時期及び地域等が記載されたメルマガ等を、電子メールで、定期的に送信することが可能になるとともに、予約手段９を介して宿泊施設を予約した会員に対して、旅行時期の直前（例えば、旅行に行く日の３日前）に、リマインダの電子メールを送ることも可能になる。ちなみに、このリマインダには、予約内容とともに、予約した宿泊施設がある地域の観光施設等、利用者にとって有益な情報を併記してもよい。
【００３９】
図４は、会員データベース及び施設データベースのデータ構造を示す概念図である。同図に示す通り、会員データベース４は、会員テーブル３１を有している。会員テーブル３１は、プライマリＩＤとして「会員ＩＤ」を有し、その他、会員の「氏名」、「生年月日」、「住所（居所）」、「ｅ−ｍａｉｌ」、「ＴＥＬ」、「ＦＡＸ」、「ログインＩＤ」及び「ログインパスワード」をフィールドとして有しており、このログインＩＤとログインパスワードとを利用して、認証手段３による認証処理を行う。
【００４０】
施設データベース５は、地域テーブル３２と、宿泊施設テーブル３３と、観光施設テーブル３４と、予約者テーブル３６と、プランテーブル３７と、ルームテーブル３８と、予約テーブル３９と、請求テーブル４１とを有している。
【００４１】
地域テーブル３２は、プライマリＩＤとして「地域ＩＤ」を有し、その他「地域名」と、地域の写真データのリンク情報や文字情報等である「地域情報」をフィールドとして有している。
【００４２】
宿泊施設テーブル３３は、プライマリＩＤである「宿泊施設ＩＤ」と、「施設名」と、施設の「ｅ−ｍａｉｌ」と、宿泊施設の写真データのリンク情報や文字情報等である「施設情報」と、上述した「地域ＩＤ」とを、フィールドとして有している。これによって、地域テーブル３２と宿泊施設テーブル３３は、一対多のリレーションシップが行われている。このリレーションシップによって、ある地域にある宿泊施設という関係が、データ構造で再現できる。
【００４３】
観光施設テーブル３４は、プライマリＩＤである「観光施設ＩＤ」と、「施設名」と、観光施設の写真データのリンク情報や文字情報等である「施設情報」との他、「地域ＩＤ」をフィールドとして有している。これによって、地域テーブル３３と観光施設テーブル３４は、一対多のリレーションシップが行われている。このリレーションシップによって、ある地域にある観光施設という関係が、データ構造で再現できる。
【００４４】
予約者テーブル３６は、プライマリＩＤである「予約者ＩＤ」と、予約者の「氏名」と、予約者の「ｅ−ｍａｉｌ」と、「予約者情報」と、上述した「施設ＩＤ」とを、フィールドとして有している。これによって、宿泊施設テーブル３３と予約者テーブル３６は、一対多のリレーションシップが行われている。このリレーションシップによって、ある宿泊施設に泊まる人という関係が、データ構造で再現できる。
【００４５】
プランテーブル３７は、プライマリＩＤである「プランＩＤ」と、「プラン名」と、「プラン内容」と、上述した「施設ＩＤ」とを、フィールドとして有している。これによって、宿泊施設テーブル３３とプランテーブル３７は、一対多のリレーションシップが行われている。このリレーションシップによって、ある宿泊施設のある宿泊プランという関係が、データ構造で再現できる。
【００４６】
ルームテーブル３８は、プライマリＩＤである「ルームＩＤ」と、ルーム番号やルーム名である「ルーム名」と、その部屋の写真データのリンク情報や文字情報等である「ルーム情報」と、上述した「施設ＩＤ」とを、フィールドとして有している。これによって、宿泊施設テーブル３３とルームテーブル３８は、一対多のリレーションシップが行われている。このリレーションシップによって、ある宿泊施設にあるある部屋という関係が、データ構造で再現できる。
【００４７】
予約テーブル３９は、プライマリＩＤである「予約ＩＤ」と、チェックインの日である「チェックＩｎ」と、チェックアウトの日である「チェックＯｕｔ」と、一緒に宿泊する宿泊者を年齢別や男女別に示した「同伴者情報」と、上述した「予約者ＩＤ」と、上述した「プランＩＤ」と、上述した「ルームＩＤ」とを、フィールドとして有している。これによって、予約者テーブル３６と予約テーブル３９との間、プランテーブル３７と予約テーブル３９との関、ルームテーブル３８と予約テーブル３９との関で、それぞれ一対多のリレーションシップが行われ、予約テーブル３９自体に、予約者の情報や、プラン内容や、部屋情報等を保持させる必要が無くなる。
【００４８】
請求テーブル４１は、プライマリＩＤである「請求ＩＤ」と、請求書の「宛名」と、請求金額等の詳細情報である「請求情報」と、上述した「予約ＩＤ」とを、フィールドとして有している。これによって、予約テーブル３９と、請求テーブル４１は、リレーションシップが行われ、予約内容から請求金額を容易に算出可能になっている。
【００４９】
以上のようなデータベース構造を採用することによって、予約した宿泊施設の地域にある観光施設等も容易に検索可能になる他、宿泊施設も、プラン設定や、部屋の分類等を柔軟に設定可能になる。
【００５０】
なお、上述の例では、旅行用検索・予約システム１を、１台のコンピュータによって実現する構成について説明したが、これを利用側システム１Ａと、施設側システム１Ｂとで分けて２台のコンピュータ１２Ａ，１２Ｂで実現してもよい。
【００５１】
具体的には、２つのコンピュータ１２Ａ，１２Ｂのハードウェア構成は同一で、オペレータティングシステム１９を起動させる点も共通であり、施設側システム１Ｂを搭載するコンピュータである施設側コンピュータ１２Ｂに、施設データベース５と、アクセス手段６とを実装させる一方で、その他のものは、利用者側システム１Ａを搭載するコンピュータである利用者側コンピュータ１２Ａに実装させる。
【００５２】
このため、施設側コンピュータ１２Ｂのオペレーティングシステム１９上において、データベースサーバ２２及びウェブサーバ２１のサービスを常住させ、バックグランドで実行させる。ちなみに、１台のコンピュータ１２上に旅行用検索・予約システムを搭載する場合、施設検索手段８、予約手段９及び連絡手段１１は、施設データベース５に直接アクセス可能であるが、上記のように２台のコンピュータ１２Ａ，１２Ｂを用いる場合には、アクセス手段６を介することにより、施設データベース５にアクセス可能に構成する。また、２台のコンピュータ１２Ａ，１２Ｂ同士は、ピアトゥピアの接続構成を採用してもよいが、インターネット等のグローバルネットワークＮ等を介して接続させてもよい。この際には、該グローバルネットワークＮに、利用者側端末Ａや宿泊施設側端末Ｂ１や観光施設側端末Ｂ２を接続させてもよい。
【００５３】
このように、２台のコンピュータ１２Ａ，１２Ｂを用意した場合、施設側コンピュータ１２Ｂ（施設側システム１Ｂ）の構成は、従来公知の構成と略同一であるため、既存の施設側コンピュータ１２Ｂに、利用者側コンピュータ１２Ａを後から設け、本旅行用検索・予約システム１を構築することが可能であるため、実用性が高く、システム導入時のコストも安く抑えることが可能になる。
【００５４】
次に、図５乃至８に基づき、気学によって縁起の良い旅行地域や旅行時期を求める手段について、概略を簡単に説明する。ちなみに該手段は、従来公知であるため、その説明は、最小限に留める。
気学（さらに具体的には九星気学）では、九星によって吉報位（以下、単に「吉方」）を求める手法と、運気の種類によって吉方を求める手法と、天道によって吉方を求める手段等が存在している。
【００５５】
最初に九星によって吉方を求める手法を説明する。
九星には、一白水星（以下、「一」）と、ニ黒土星（以下、「ニ」）と、三碧木星（以下、「三」）と、四緑木星（以下、「四」）と、五黄土星（以下、「五」）と、六白金星（以下、「六」）と、七赤金星（以下、「七」）と、八白土星（以下、「八」）と、九紫火星（以下、「九」）との９種類があり、この九星が、それぞれ日毎、月毎、年毎に、九→八→七→六→五→四→三→ニ→一→九→八→・・・と循環している。
【００５６】
さらに、干支も利用する。干支には、子と、丑と、寅と、卯と、辰と、巳と、午と、未と、申と、酉と、戌と、亥とがあり、子→丑→寅→卯→辰→巳→午→未→申→酉→戌→亥→子→・・・と循環している。
【００５７】
年の本命星では、例えば、昭和５２年は、本命星が五黄土星で、干支が巳になり、以下、昭和５３年→昭和５４年→昭和５５年→昭和５６年→昭和５７年→・・・と進むと、本命星は四→三→ニ→一→九→・・・と年毎に移り変り、干支は午→未→申→酉→戌→・・・と年毎に移り変わる。なお、気学では、旧暦を基準としているため、翌年の２月３日（閏年は２月４日）までその年が続くため、例えば、１９７７年は正確には１９７７年２月４日〜１９７８年２月３日までになる。
【００５８】
また、月の本命星（月命星）では、例えば、２０１０年１０月は、本命星が三碧木星で、干支が戌になり、以下、月が同年１１月→１２月→翌年１月→２月→・・・と進むと、月命星は、ニ→一→九→八→・・・と月毎に移り変り、干支は、亥→子→丑→寅→・・・と月毎に移り変わる。
【００５９】
さらに、日の本命星（日命星）では、例えば、２０１０月１１月１２日の日命星が四緑木星で、干支が寅になり、以下、日が同月１３日→１４日→１５日→１６日→・・・と進むと、日命星は、三→ニ→一→九→・・・と日毎に移り変わり、干支は、卯→辰→巳→午→・・・と日毎に移り変わる。
【００６０】
図５（Ａ）は、方位盤の構成を示すものであり、（Ｂ）は、方位盤における九星の配置構成を示す概念図であり、（Ｃ）は、（Ｂ）の具体例である。同図（Ａ）に示す通り、気学で用いる方位盤（気学盤）は、中心を「中宮」として、南の方向に３０度の範囲が「離宮」、西南の方向に６０度の範囲が「坤宮」、西の方向に３０度の範囲が「兌宮」、西北の方向に６０度の範囲が「乾宮」、北の方向に３０度の範囲が「坎宮」、東北の方向に６０度の範囲が「艮宮」、東の方向に３０度の範囲が「震宮」、東南の方向に６０度の範囲が「巽宮」となる。この他、気学盤では、南の方向に３０度の範囲が「午」、南南西の方向に３０度の範囲が「未」、西南西の方向に３０度の範囲が「申」、西の方向に３０度の範囲が「酉」、西北西の方向に３０度の範囲が「戌」、北北西の方向に３０度の範囲が「亥」、北の方向に３０度の範囲が「子」、北北東の方向に３０度の範囲が「丑」、東北東の方向に３０度の範囲が「寅」、東の方向に３０度の範囲が「卯」、東南東の方向に３０度の範囲が「辰」、南南東の方向に３０度の範囲が「巳」になる。
【００６１】
そして、これらは、同図（Ｂ）に示す通り、中宮→乾宮→兌宮→艮宮→離宮→坎宮→坤宮→震宮→巽宮の順序で、九星が順番に回座する。例えば、同図（Ｃ）に示す通り、宮中に五黄土星が位置する場合、乾宮、兌宮、艮宮、離宮、坎宮、坤宮、震宮、巽宮には六、七、八、九、一、ニ、三、四が、それぞれ位置する。さらに、図には示していないが、中宮に七赤金星が位置する場合、乾宮、兌宮、艮宮、離宮、坎宮、坤宮、震宮、巽宮には八、九、一、ニ、三、四、五、六が、それぞれ位置する。
【００６２】
この気学盤には、日盤と、月盤と、年盤との３種類があり、日盤として用いる場合、対象となる日の日命星を上記気学盤の中宮に位置させ、月盤として用いる場合、対象となる月の月命星を上記気学盤の中宮に位置させ、年盤として用いる場合、対象となる年の本命星を上記気学盤の中宮に位置させる。
【００６３】
図６は、九星気学により吉方位を求める手順を示したフロー図である。同図に示す通り、吉方を求める場合、まず、利用者の本命星を求め、次に、吉方を求める際に使用する気学盤を決定し、続いて、凶殺判定を行った後、相生・相克判定を行い、吉方を求める。
【００６４】
利用者の本命星は、利用者の生年月日から求めることが可能である。例えば、１９７７年６月１１日に生れていれば、利用者の生れた年は、旧暦でも１９７７年になり、この年の本命星は五黄土星であるため、利用者の本命星は五黄土星になる。
【００６５】
気学盤の決定では、まず、日盤と、月盤と、年盤の何れを用いるかを定める。どの気学盤を用いるかは、旅行期間と、旅行地域までの距離等とによって決定する。例えば、利用者の住所（居所）から旅行地域への距離が長くなるに従い、気学盤を、日盤→月盤→年盤と使い分けるとともに、旅行の期間が長くなるに従い、気学盤を、日盤→月盤→年盤と使い分ける。どの程度の旅行期間又は距離で、使い分けを行うかについては、適宜設定変更される事項であるが、例えば、自宅から近い地域に一泊や二泊で旅行する場合には、日盤を使用し、自宅からある程度距離がある地域に三泊〜一週間程度で、旅行する場合には、月盤を用い、海外に１ヶ月以上旅行する場合には、年盤を用いる。
【００６６】
続いて、旅行時期から、気学盤の中宮に位置する本命星を求める。日盤の場合には、旅行日又は旅行が複数日に亘る際には何れかの旅行日の日命星になり、月盤の場合には、旅行月又は旅行が複数月に亘る際には何れかの旅行月の月命星になり、年盤の場合には、旅行年又は旅行が複数年に亘る際には何れかの旅行年の本命星になる。このようにして、宮中に回座する九星が定まれば、図５に示す通り、気学盤が求まる。
【００６７】
続いて、凶殺判定を行う。どこまでを凶殺とするかは、適宜設置変更される事項であるが、代表的なものとしては、六大凶殺を用いる。六大凶札には、五黄殺、暗剣殺、本命殺、本命的殺、歳破及び月破がある。五黄殺とは、気学盤において、五黄土星が位置する方位であり、暗剣殺とは、気学盤において、五黄土星の位置する方位の反対の方位であり、本命殺とは、自分の本命星が位置する方位であり、本命的殺とは、自分の本命星が位置する方位と反対側の方位であり、歳破とは、年盤を使用する最にその年の干支が位置する方位の反対側の方位であり、月破とは、月盤を使用する際にその月の干支が位置する方位の反対側の方位である。気学盤から、これらの方位が除外する凶殺判定を行った結果、残った方位が、吉方の候補となる。なお、六大凶殺に、常位対冲と、小児殺とを加えて、凶殺判定を行っても良い。
【００６８】
図７（Ａ）は、相生五行の関係を示す概念図であり、（Ｂ）は相克五行の関係を示す概念図である。続いて、相生・相克判定を行う。同図（Ａ）に示す通り、三碧木星又は四緑木星と、九紫火星とは、互いに吉となり、九紫火星と、三碧木星又は四緑木星又はニ黒土星とは、互いに吉となり、三碧木星又は四緑木星又はニ黒土星と、六白金星又は七赤金星とは、互いに吉となり、六白金星又は七赤金星と、一白水星とは、互いに吉となり、一白水星は、三碧木星又は四緑木星とは、互いに吉となる。
【００６９】
また、同図（Ｂ）に示す通り、三碧木星又は四緑木星と、ニ黒土星又は五黄土星又は八白土星とは、互いに凶となり、ニ黒土星又は五黄土星又は八白土星と、一白水星とは、互いに凶となり、一白水星と、九紫火星とは、互いに凶となり、九紫火星と、六白金星又は七赤金星とは、互いに凶となり、六白金星又は七赤金星と、三碧木星又は四緑木星とは、互いに凶となる。
【００７０】
上記候補となっている方位に回座する九星と、利用者の本命星との間で、相生及び相克を判定し、本命星に対して凶となる方位を吉方候補から消し、吉となっている方位を吉方とし、これによって、吉方となる方位である吉方位を求める。なお、さらに、利用者の生れた月の月命星の考慮して、吉方を判定してもよい。
【００７１】
例えば、平成１４年の年盤を用いて、本命星がニ黒土星の利用者の吉方を求める場合、年盤の中宮には、その年の本命星である七赤金星が回座し、南にはニ黒土星、西南には四緑木星、西には九紫火星、西北には八白土星、北には三碧木星、東北には一白水星、東には五黄土星、東南には六白金星がそれぞれ回座する。このため、五黄殺は東の方位となり、暗剣殺は西の方位となり、本命殺は南の方位となり、本命的殺は北の方となり、歳破は、平成１４年の干支である午が位置する南と反対側の北の方位となり、月破は年盤を用いているため考慮する必要が無い。さらに、吉方の候補として残った西南、西北、東北、東南の内、本命星であるニ黒土星との関係で凶の関係になる四緑木星及び一白水星が回座する西南と東北とを除外する。そして、残った西北に回座する八白土星は、本命星であるニ黒土星と同じ土星であるため、吉となる一方、残った東南に回座する六白金星も、本命星との関係で吉となるため、吉となる。以上によって、西北及び東南が、平成１４年において、ニ黒土星の利用者の吉方となる。
【００７２】
そして、利用者の居所に対して、吉方となる方位に位置する地域が、上述した旅行先の候補地域となる。ちなみに、この際の方位は、磁石のＮ極が示す方向と、北極点と南極点と結んだ子牛線上の真北には、誤差があり、この誤差も考慮して、吉方となる地域を求める。ちなみに、この誤差は地域によって異なり、その算出方法は、従来公知であるため、ここでの説明は割愛する。
【００７３】
なお、上記吉方の判定手段により、旅行の地域が定まっている場合には、利用者の住所から、上記地域の方位を算出し、その方位が吉方となる時期を、上述の手段を用いて、逆算する。すなわち、旅行の時期が決まっていれば、そこから、縁起の良い、旅行の地域を求めることができるし、逆に、旅行の地域が決まっていても、そこから、縁起の良い、旅行の時期を逆算できる。この原理を、上述の気学検索アプリケーション２７に適用し、上記したような検索を行う。
【００７４】
二番目に運気の種類によって吉方を求める手法を説明する。
気学では、運気の種類が定まっていれば、吉方となる方位を、時期や利用者の本命星に関係無く、求めることが可能である。例えば、運気の種類として、金運、恋愛運、仕事運、健康運、子供運、発展運、結婚運、契約運、勝負運、不動産運、変化運、ビューティー運等がある。そして、南が方位で運気がアップするのはビーティー運であり、西南の方位で運気がアップするのは仕事運であり、西の方位で運気がアップするのは金運及び恋愛運であり、西北の方位で運気がアップするのは勝負運であり、北の方位で運気がアップするのは健康運及び子供運であり、東北の方位で運気がアップするのは不動産運及び変化運であり、東の方位で運気がアップするのは発展運であり、東南の方位で運気がアップするのは結婚運及び契約運である。
【００７５】
以上により、気学検索アプリケーション２７では、運気の種類が選択された場合、その選択された運気がアップする方位を、吉方の方位として、判定する。ちなみに、この方位は、上述の場合と同様に、真北との誤差が考慮される。
【００７６】
三番目（最後）に天道によって吉方を求める手法を説明する。
天道とは、ある月又はある年において、万人に吉方とされる方位であり、月の天道を用いる場合は、その月の干支によって定まり、年の天道を用いる場合は、その年の干支によって定まり、とちらを用いるかは、上述の例と同様に、旅行の時間や距離によって適宜定める。
【００７７】
天道は、南の方に１５度の範囲を午とし、午から時計回りに１５度の範囲毎に、丁→未→坤（西南）→申→庚→酉（西）→辛→戌→乾（西北）→亥→壬→子（北）→癸→丑→艮（北東）→寅→甲→卯（東）→乙→辰→巽（南東）→巳→丙とした場合に、この２４種類の方位の何れかに定まり、具体的には、以下の表１に示す通りである。
【００７８】
【表１】
2012123701.tif 000003
【００７９】
以上により、気学検索アプリケーション２７では、旅行の時期が定まっている場合には、その時期の天道を判定し、利用者の住所から見て天道の方位となる地域を旅行地域の候補とする一方で、旅行の地域が定まっている場合には、利用者の住所から、上記地域の方位を算出し、その方位が天道の方位となる時期を、逆算し、その時期を旅行時期の候補とする。ちなみに、この方位は、上述の場合と同様に、真北との誤差が考慮される。
【００８０】
このようにして、気学検索アプリケーション２７により、気学に基づいて、縁起の良い旅行時期及び旅行地域を検索するが、本発明はこれらの手法に限定されるものでは無く、さらに種々の要素を取入れてもよいし、一部の要素を削除・変更等してもよい。
【００８１】
次に、図８乃至１３に基づき、認証手段、気学検索手段、施設検索手段および予約手段の構成を説明する。
図８は、認証手段の処理フロー図である。同図に示す通り、利用者側端末Ａから本旅行用検索・予約システム１にアクセスし、利用者側端末Ａに、入出力手段２から提供されるホームページにログイン画面が表示されると、認証手段３は、ステップＳ１から処理が開始される。
【００８２】
ステップＳ１では、ログイン画面上において、新規登録画面への切換が行われたか否かを検出し、切換が行われていれば（新規登録画面へのリンクがクリックされていれば）、ステップＳ２に進む。ステップＳ２では、ホームページに新規登録画面を表示し、ステップＳ３に進む。ステップＳ３では、新規登録が行われているか否か（具体的には、新規登録画面で新規登録のボタンがクリックされているか否か）が検出され、新規登録が行われている場合された場合にはステップＳ４に進み、新規登録が行われていない場合にはステップＳ３に処理を戻す。
【００８３】
ステップＳ４では、会員テーブル３１の会員ＩＤを除く各フィールドの項目が正しく入力されているか否かをチェックし、ＯＫであればステップＳ５に進み、ＯＫでなければステップＳ３に処理を戻す。ステップＳ５では、会員ＩＤを自動的に割当てるとともに、入力された各種情報を、会員テーブル３１の各フィードルに書込んで、処理を終了させる。
【００８４】
ステップＳ１において、上記切換が行われていない場合には、ステップＳ６に進む。ステップＳ６では、ログインＩＤ及びログインパスワードを入力してログインボタンをクリックするログイン操作が行われているか否かを検出し、ログイン操作が行われていれば、ステップＳ７に進む一方で、ログイン操作が行われていなければ、ステップＳ１に処理を戻す。
【００８５】
ステップＳ７では、ログインＩＤ及びログインパスワードが正しいか否かを、会員テーブル３１の情報によって確認し、正しければステップＳ８に進む一方で、間違っていればステップＳ１に処理を戻す。ステップＳ８では、認証処理を行い、利用者側端末Ａに表示されているホームページに上述の検索画面を表示し、処理を終了させる。
【００８６】
図９は、気学検索手段の処理フロー図である。気学検索手段７は、ホームページ上の上記検索画面に必要情報を入力され且つ検索ボタンがクリックされた場合に、その処理を開始し、ステップＳ１１に進む。なお、検索画面には、希望の旅行地域を一又は複数入力する欄が１つと、希望の旅行時期を一又は複数入力する欄が１つと、向上させたい運気の種類を入力する欄が１つ用意され、上述した通り、利用者も複数入入力可能であり、会員以外の利用者に対しては、生年月日や住居（又は居所）を入力する欄も別途設けられ、これらが必須の入力項目となる。
【００８７】
ステップＳ１１では、検索画面の入力欄に複数人の入力があるか否かを検出し、一人のみ入力されていれば、ステップＳ１２に進む一方で、複数人の入力があれば、ステップＳ１３に進む。ステップＳ１２では、単独検索のサブルーチンを実行した後、処理を終了させ、ステップＳ１３では、複数人検索のサブルーチンを実行した後、処理を終了させる。
【００８８】
図１０は、単独検索のサブルーチンの処理フロー図である。単独検索のサブルーチンの処理が開始されると、ステップＳ２１から処理が開始される。ステップＳ２１では、希望の旅行時期を入力する欄に、一又は複数の旅行時期が入力されているか否かをチェックし、入力されていればステップＳ２２に進む。
【００８９】
ステップＳ２２では、会員データベース４に記憶された会員情報又は検索画面に入力された入力情報に基づいて、利用者の生年月日から、本命星判定を求め、ステップＳ２３に進む。ステップＳ２３では、前述した九星によって吉方を求める手法により本命星から吉方判定を行い、入力された旅行時期毎に、一又は複数の吉方位を求め、ステップＳ２４に進む。ステップＳ２４では、利用者の住んでいる所（住所又は居所）から見て、吉方となる地域を一又は複数算出し、ステップＳ２５に進む。ちなみに、吉方位から地域を算出する際には、上述したように真北との誤差も加味する他、ステップＳ２４に処理によって、旅行の時期毎に、吉方位となる地域が、希望の旅行時期と関連付けされて、一又は複数求まり、これを旅行候補として扱う。
【００９０】
ステップＳ２５では、一の旅行時期に対して該時期に吉方位となる一の旅行地域が対応付けられたものを旅行の一候補とし、上記旅行候補の全てが一覧表示された候補一覧画面が利用者側端末Ａのホームページ画面に表示させ、ステップＳ２６に進む。
【００９１】
ステップＳ２６では、候補一覧画面から、一の旅行候補が選択されているか否かをチェックし、一の旅行候補が選択されている場合には、縁起の良い旅行時期及び旅行地域が１つに絞られたものとして、このサブルーチンの処理を終了させ、図９に示すメインルーチンに処理を戻す一方で、一の旅行地域がまだ選択されていない場合には、ステップＳ２６の処理を繰返す。
【００９２】
ステップＳ２１において、希望の旅行時期を入力する欄に、旅行時期が入力されていない場合には、ステップＳ２７に進む。ステップＳ２７では、希望の旅行地域を入力する欄に、一又は複数の旅行地域が入力されているか否かをチェックし、希望の旅行地域が入力されていれば、ステップＳ２８に進む。
【００９３】
ステップＳ２８では、会員データベース４に記憶された会員情報又は検索画面に入力された入力情報に基づいて、利用者の生年月日から、本命星判定を求め、ステップＳ２９に進む。ステップＳ２９では、上記入力された希望の旅行地域毎に、利用者の住居又は居所から見て、その地域がどの方位に位置するかを算出し、ステップＳ３０に処理を進める。ちなみに、この際には、上述した例と同様、真北との誤差も加味する。ステップＳ３０では、予め定められた所定期間内において、前記算出された一又は複数の方位が、それぞれ吉方となる時期を、一又は複数求める吉日判定を行い、求まった吉日を、上述の場合と同様に、該当する時期と関連付けして旅行候補として扱い、ステップＳ２５に処理を進める。ちなみに、ステップＳ３０→ステップＳ２５の場合でも、一の旅行時期に対して該時期に吉方位となる一の旅行地域が対応付けられたものを旅行の一候補として、一覧表示することが可能であり、その後の処理は同様であるため、説明は割愛する。
【００９４】
ステップＳ２７において、希望の旅行地域を入力する欄に、旅行地域が入力されていない場合には、ステップＳ３１に進む。ステップＳ３１では、旅行に際して向上させたい運気の種類を入力する欄に、運気の種類が入力されているか否かをチェックし、入力されていれば、ステップＳ３２に進む。ステップＳ３２では、上述した運気の種類によって吉方を求める手法によって、吉方判定を行い、その選択された運気に応じた吉方位を求め、ステップＳ３３に進む。ステップＳ３３では、ステップＳ３２において求まった吉方位から、利用者の住所又は居所から見て、吉方となる地域を一又は複数算出する。ちなみに、吉方位から地域を算出する際には、上述したように真北との誤差も加味する。さらに、運気の種類によって吉方を求める手法では、本命星や時期に関わり無く、吉方位が求まるため、検索時以降において予め定めされた期間内の所定の時期毎（例えば、検索日から３０日経過後から６０経過前までの間の２日毎）に、算出された地域を関連付けし、これを旅行候補として扱い、ステップＳ２５に処理を進める。以下の処理は上述した場合と同様であるため、説明を割愛する。
【００９５】
ステップＳ３１において、旅行に際して向上させたい運気の種類を入力する欄に、運気の種類が入力されていない場合には、ステップＳ３４に進む。ステップＳ３４では、会員データベース４に記憶された会員情報又は検索画面に入力された入力情報に基づいて、利用者の生年月日から、本命星判定を求め、ステップＳ３５に進む。
【００９６】
ステップＳ３５では、検索時点を基準とし、それ以降の予め定めされた期間内における一又は複数の時期を、希望する一又は複数の旅行時期とみなし、この旅行時期毎に、ステップＳ２３と同様の処理を行い、それぞれについて、吉方を求め、ステップＳ３６に進む。ステップＳ３６では、利用者の住所から見て、ステップＳ３６により求めた吉方にある地域を算出し、これらを該所定時期と関連付けして、旅行候補とし、ステップＳ２５に進む。すなわち、ステップＳ３５の処理では、検索時以降の予め定められた時期を、希望の旅行時期とみなして、旅行候補を絞る吉方・吉日判定を行う。
【００９７】
以上によって、ステップＳ２１と、ステップＳ２７と、ステップＳ３１との処理によって、旅行したい時期が入力されている場合には、旅行したい時期に吉方となる地域を検索し、旅行したい地域が入力されている場合には、旅行したい地域が吉方となる時期を検索し、旅行に際して向上させたい運気の種類が入力されている場合には、選択された種類の運気が向上する方位に位置する地域を検索し、何れの項目も入力されていない場合には、検索時以降の予め定められた時期を希望の旅行時期とみなし、該旅行の時期に吉方となる地域を検索するように気学検索手段７が構成されている。このため、入力項目に応じた、柔軟な検索を簡易且つ迅速に行うことが可能になる。
【００９８】
また、旅行したい時期と、旅行したい地域と、旅行に際して向上させたい運気の種類との３項目の内、２つ以上の項目が入力されている場合には、ステップＳ２７→ステップＳ３１の処理により、向上させたい運気の種類が入力された場合の検索より、旅行したい地域が入力された場合の検索が優先され、ステップＳ２１→ステップＳ２７の処理により、旅行したい地域が入力された場合の検索より、旅行したい時期が入力された場合の検索が優先される。
【００９９】
なお、図１０に仮想線で示す通り、単独検索のサブルーチンが開始された際に、ステップＳ４１から処理が開始されるように気学検索手段７を構成してもよい。ステップＳ４１では、旅行したい時期と、旅行したい地域と、旅行に際して向上させたい運気の種類との３項目の内、２つ以上の項目が入力されているか否かをチェックし、２以上の項目が入力されている場合には、ステップＳ４２に進み、そうでない場合には、ステップＳ２１に進む。ステップ４２では、入力された項目の何れを用いて検索するかを選択させる選択画面を、利用者側端末Ａのホームページに表示させ、ステップＳ４３に進む。ステップＳ４３では、上記入力項目の内の何れか一が選択されたか否かをチェックし、選択されていなければステップＳ４３の処理を繰返す。
【０１００】
一方、ステップＳ４３において、旅行したい時期と、旅行したい地域と、旅行に際して向上させたい運気の種類との３項目の何れかであって且つ入力されている項目から、何れか一の項目が選択されている場合には、その項目のみが入力（指定）されているものとみなして、ステップＳ２１に処理を進める。すなわち、ステップＳ４１〜ステップＳ４３によって、何れかの入力項目によって、旅行の地域や時期を検索するかを選択する選択機能を実現している。言換えると、３つの入力項目に優先順位をつけず、２以上の項目が入力されている場合には、その中から、入力項目を選択させるように上述の気学検索手段７を構成してもよい。
【０１０１】
図１１は、複数人検索のサブルーチンの処理フロー図である。複数人検索のサブルーチンの処理が開始されると、ステップＳ５１から処理が開始される。ステップＳ５１では、希望の旅行時期を入力する欄に、一又は複数の旅行時期が入力されているか否かをチェックし、入力されていればステップＳ５２に進む。
【０１０２】
ステップＳ５２では、複数の各利用者に対してステップＳ２２の処理を行い、ステップＳ５３に進む。ステップＳ５３では、複数の各利用者に対して、ステップＳ２３と同様の処理を行いステップＳ５４に進む。ステップＳ５４では、複数の各利用者に対して、ステップＳ２４と同様の処理を行い、ステップＳ５５に進む。
【０１０３】
ステップＳ５３→ステップＳ５４の処理では、自身の住んでいる地域（具体的には、住居）から見て、上記希望した一又は複数の旅行時期に吉方となる地域である吉方地域が、利用者毎に求まる。ステップＳ５５では、この全ての吉方地域のなかから、同一時期において、利用者全てに共通する地域があるか否かをチェックし、ある場合には、それを共通地域として選定し、ステップＳ５６に進む。ステップＳ５６では、一又は複数の共通地域及びそのそれぞれに関連する上記同一時期を、旅行候補として扱い、ステップＳ２５と同様の処理を行い、ステップＳ５７に処理を進める。
【０１０４】
ステップＳ５５において、複数の利用者全てに共通する吉方地域が同一時期において見当たらない場合には、ステップＳ５８に進む。ステップＳ５８では、旅行時期に属する月又は年の天道を求める天道判定を行い、ステップＳ５９に処理を進める。ステップＳ５９では、各利用者に対して、自身の住所から見て天道の方位となる地域を天道地域として算出し、ステップＳ６０に処理を進める。ちなみに、この際も、上述の場合と同様、真北との誤差を考慮し、月の天道と、年の天道の何れかを用いるかは、旅行の期間等によって定める。
【０１０５】
ステップＳ６０では、ステップＳ５９の処理によって求めた全ての天道地域から、同一時期において、複数人の利用者全てに共通の天道地域があるか否かのチェックを行い、そのような天道地域がある場合には、該天道地域を、共通地域として識別し、ステップＳ５６に処理を進める。このようにして、一又は複数の共通地域を、該当する時期と関連付けして、旅行候補として扱い、ステップＳ５６に処理を進める。
【０１０６】
ちなみに、天道は、全ての人に共通の方位であるため、対象となっている利用者が全て同一地域に住んでいる場合、ステップＳ５９において、必ず共通地域が求まるようになっているが、複数の利用者のなかで、一人でも異なる地域に住んでいる場合には、このように同一時期における共通の天道地域が見当たらないことがあり、このような場合はステップＳ６１に処理を進める。
【０１０７】
ステップＳ６１では、ステップＳ５３→ステップＳ５４の処理で求めた全ての吉方地域を、それぞれの旅行時期と関連付けして１つの選択肢とし、これを一覧にした選択一覧画面を、利用者側端末Ａのホームページに表示し、ステップＳ５７に処理を進める。ちなみに、複数の利用者の誰が吉方地域となっているかが分かるように、選択一覧画面を構成している。このようにすることによって、利用者が複数いる場合で、共通地域が無い場合、誰を重視して、縁起の良い旅行時期及び旅行地域を求めるかを、選択することが容易になる。
【０１０８】
ステップＳ５７では、候補一覧画面又は選択一覧画面から、旅行時期及びその旅行時期に対応した旅行地域が１つ選択されたか否かをチェックを行い、１つが選択されている場合には、縁起の良い旅行時期及び旅行地域が１つに絞られたものとして、このサブルーチンの処理を終了させ、図９に示すメインルーチンに処理を戻す一方で、１つが選択されていない場合には、ステップＳ５７の処理を繰返す。
【０１０９】
ステップＳ５１において、希望の旅行時期を入力する欄に、旅行時期が入力されていない場合には、ステップＳ６２に進む。ステップＳ６２では、希望の旅行地域を入力する欄に、旅行地域が入力されているか否かのチェックを行い、旅行地域が入力されていれば、ステップＳ６３に処理を進める。
【０１１０】
ステップＳ６３では、複数の各利用者に対してステップＳ２８の処理を行い、ステップＳ６４に進む。ステップＳ６４では、複数の各利用者に対して、ステップＳ２９と同様の処理を行いステップＳ６５に進む。ステップＳ６５では、複数の各利用者に対して、ステップＳ３０と同様の処理を行い、ステップＳ６６に進む。
【０１１１】
ステップＳ６４→ステップＳ６５の処理によって、上記希望した一又は複数の旅行地域が自身の住居又は居所から見て吉方となる時期が、利用者毎に吉日として求まる。ステップＳ６６では、この全ての吉日のなかから、同一地域において、複数の利用者全てに共通する吉日があるか否かをチェックし、ある場合には、それを共通時期として識別し、ステップＳ６７に進む。ステップＳ６７では、希望の旅行地域と関連付けされた一又は複数の共通時期を、旅行候補として扱い、ステップＳ２５と同様の処理を行い、ステップＳ５７に処理を進める。
【０１１２】
ステップＳ６６において、同一地域において複数の利用者全てに共通する吉日がない場合には、ステップＳ６８に進む。ステップＳ６８では、上記希望した一又は複数の旅行地域が、自身の住所から見て、月又は年の天道の方位となる時期である天道時期を求める天道判定を行い、ステップＳ６９に処理を進める。ちなみに、月の天道を用いるか、年の天道を用いるかは、住んでいる場所から指定された旅行地域までの距離等によって決定する。
【０１１３】
ステップＳ６９では、ステップＳ６８で求めた全ての天道時期のなかで、同一地域において、複数の利用者全てに共通する天道時期があるか否かをチェックし、ある場合には、これを共通時期として、ステップＳ６７に進む。ちなみに、天道は、全ての人に共通の方位であるため、対象となっている利用者が全て同一地域に住んでいる場合、ステップＳ６９において、必ず共通時期が求まるようになっているが、複数の利用者のなかで、一人でも異なる地域に住んでいる場合には、共通時期がない場合があり、この場合には、ステップＳ７０に処理を進める。
【０１１４】
ステップＳ７０では、ステップＳ６４→ステップＳ６５で求めた全ての吉日を、その地域と関連付けし、それぞれ１つの選択肢として、それを一覧に並べた選択一覧画面を、利用者側端末Ａのホームページに表示し、ステップＳ５７に処理を進める。ちなみに、複数の利用者の誰にとって、吉日となっているかも、分かるように、選択一覧画面を構成している。このようにすることによって、利用者が複数いる場合で、共通地域が無い場合、誰を重視して、縁起の良い旅行時期及び旅行地域を求めるかを、選択することが容易になる。
【０１１５】
ステップＳ６２において、希望の旅行地域を入力する欄に、旅行地域が入力されていない場合には、ステップＳ７１に処理を進める。ステップＳ７１では、旅行に際して向上させたい運気の種類を入力する欄に、運気の種類が入力されているか否かをチェックし、入力されていれば、ステップＳ７２に進む。
【０１１６】
ステップＳ７２では、上述した運気の種類によって吉方を求める手法によって、吉方判定を行い、その選択された運気に応じた吉方を求め、ステップＳ７３に進む。ステップＳ７３では、ステップＳ７２において求まった吉方から、利用者の住所又は居所から見て吉方となる地域である吉方地域を、複数の利用者それぞれについて算出し、ステップＳ７４に処理を進める。吉方となる地域を算出する際には、上述したように真北との誤差も加味する。ちなみに、運気の種類によって吉方を求める手法では、本命星や時期に関わり無く、吉方が求まるため、ステップＳ７３の処理時、検索時以降において予め定めされた期間内の所定の時期毎に、算出された吉方地域との関連付けを行う。
【０１１７】
ステップＳ７４では、ステップＳ７３で求めた吉方地域のなかから、複数の利用者全てに共通の地域があるか否かをチェックし、ある場合には、それを共通地域とし、ステップＳ７５に処理を進める。ステップＳ７５では、上述のようにして、該当する時期毎に関連付けされた共通地域を、旅行候補として扱い、ステップＳ２５と同様の処理を行い、ステップＳ５７に進む。
【０１１８】
一方、ステップＳ７４において、同一時期において、複数の利用者全てに共通する吉方地域が無い場合、ステップＳ７６に処理を進める。ステップＳ７６では、上記ステップＳ７３において、算出された全ての吉方地域を、上記所定期間と関連付けし、それぞれ１つの選択肢とし、これを一覧に並べた選択一覧画面を、利用者側端末Ａのホームページに表示し、ステップＳ５７に処理を進める。
【０１１９】
ステップＳ７１において、旅行に際して向上させたい運気の種類を入力する欄に、運気の種類が入力されていない場合には、ステップＳ７７に進む。ステップＳ７７では、複数の各利用者に対して、ステップＳ３４と同一の処理を行い、ステップＳ７８に進む。ステップＳ７８では、複数の各利用者に対して、ステップＳ３５と同一の処理を行い、ステップＳ８０に進む。ステップＳ８０では、ステップＳ５５と同一の処理を行い、同一時期において複数の利用者全ての共通する地域である共通地域があれば、ステップＳ８１に進む一方で、共通地域がなければ、ステップＳ８２に進む。ステップＳ８１では、ステップＳ５６の同様の処理を行い、ステップＳ５７に進み、ステップＳ８２では、ステップＳ６１と同様の処理を行い、ステップＳ５７に進む。
【０１２０】
以上により、一緒に旅行すべく、利用者が複数人いる場合においても、ステップＳ５１と、ステップＳ６２と、ステップＳ７１との処理によって、旅行したい時期が入力されている場合には、旅行したい時期に吉方となる地域を検索し、旅行したい地域が入力されている場合には、旅行したい地域が吉方となる時期を検索し、旅行に際して向上させたい運気の種類が入力されている場合には、選択された種類の運気が向上する方位に位置する地域を検索し、何れの項目も入力されていない場合には、検索時以降の予め定められた時期を希望の旅行時期とみなし、該旅行の時期に吉方となる地域を検索するように気学検索手段７が構成されている。
【０１２１】
また、それぞれについても、各人の本命星から共通の旅行時期及び地域が求まる場合には、それを旅行候補として認定し、共通の旅行時期及び地域が求まらない場合には、天道を利用し、それでもだめな場合には、選択一覧画面を表示して選択させることにより、状況に応じた柔軟な検索を行うことが可能になっている。
【０１２２】
さらに、旅行したい時期と、旅行したい地域と、旅行に際して向上させたい運気の種類との３項目の内、２つ以上の項目が入力されている場合には、ステップＳ６２→ステップＳ７１の処理により、向上させたい運気の種類が入力された場合の検索より、旅行したい地域が入力された場合の検索が優先され、ステップＳ５１→ステップＳ６２の処理により、旅行したい地域が入力された場合の検索より、旅行したい時期が入力された場合の検索が優先される。
【０１２３】
なお、図１０の場合と同様に、ステップＳ５１の処理の前に、ステップＳ４１〜ステップＳ４３の処理を実行し、選択画面を表示させ、旅行したい時期と、旅行したい地域と、旅行に際して向上させたい運気の種類との３項目に、優先順位を設けず、予め何れかを選択するように気学検索手段７を構成してもよい。
【０１２４】
図１２は、施設検索手段の処理フロー図である。気学検索手段７によって縁起の良い旅行時期と旅行地域の組合せが一組検索・選定されると、施設検索手段８の処理が開始され、ステップＳ９１に進む。ステップＳ９１では、施設データベース５に記憶された宿泊施設のなかから、気学検索手段７によって決定された旅行地域にある宿泊施設を検索し、ステップＳ９２に進む。ステップＳ９２では、ステップＳ９１の処理によって検索された宿泊施設のなかから、気学検索手段７によって決定された旅行時期に空室のある宿泊施設が絞込まれ、ステップＳ９３に進む。
【０１２５】
ステップＳ９３では、ステップＳ９２の処理により絞込まれた宿泊施設が一覧表示された検索結果画面を、利用者側端末Ａのホームページに表示し、ステップＳ９４に進む。ステップＳ９４では、検索結果画面に表示された情報に基づいて、再検索条件を入力して再検索ボタンをクリックする再検索が行われているか否かをチェックし、再検索が行われていない場合には、ステップＳ９５に処理を進める一方で、再検索が行われている場合には、ステップＳ９６に処理を進める。
【０１２６】
ステップＳ９５では、検索結果画面の施設一覧から、予約を行う一の宿泊施設が選択（例えば、施設一覧から一の施設のリンク先をクリック）されたか否かをチェックし、一の宿泊施設が選択されていれば、処理を終了させる一方で、一の宿泊施設が選択されていなければ、ステップＳ９４に処理を戻す。また、ステップＳ９６では、入力された再検索条件に基づいて、再検索を行い、再び、ステップ９３に進み、その検索結果を、施設一覧として上記検索結果画面に表示させる。
【０１２７】
図１３は、予約手段の処理フロー図である。前述したステップＳ９５の処理において、一の宿泊施設が選択されて施設検索手段８の処理が終了すると、予約手段９の処理が開始され、ステップＳ１０１に処理が進む。ステップＳ１０１では、選択した宿泊施設に対応した予約画面を、利用者側端末Ａのホームページに表示し、ステプＳ１０２に進む。Ｓ１０２では、会員テーブル３１の情報や上記決定された旅行時期の情報等を利用して、予約テーブル３９及び予約者テーブル３６に対応した情報を入力した後、申込ボタンをクリックする、申込み処理が行われているか否かをチェックし、申込み処理が行われている場合には、ステップＳ１０３に進み、行われていない場合には再度、ステップＳ１０２の処理を繰返す。
【０１２８】
ステップＳ１０３では、予約情報が記載が適切か否かのチェックを行い、適切な場合には、ステップＳ１０４に進み、適切でない場合には、ステップＳ１０５に進む。ステップＳ１０５では、適切でない箇所を併記したエラー画面を表示し、ステップＳ１０１に処理を戻す。
【０１２９】
ステップＳ１０４では、予約画面に入力された情報等を、施設データベース５に、対応箇所に記憶する予約処理を行い、ステップＳ１０６に進む。ステップＳ１０６では、予約を実行した会員の電子メールアドレス宛に予約完了メールを送信するとともに、予約した宿泊施設の電子メールアドレス宛に予約受付メールを送信する通知処理を行い、処理を終了させる。
【符号の説明】
【０１３０】
２  入出力手段（入力手段）
７  気学検索手段
１６  記憶装置
１８  施設検索手段
【図１】
2012123701.tif 000004
【図２】
2012123701.tif 000005
【図３】
2012123701.tif 000006
【図４】
2012123701.tif 000007
【図５】
2012123701.tif 000008
【図６】
2012123701.tif 000009
【図７】
2012123701.tif 000010
【図８】
2012123701.tif 000011
【図９】
2012123701.tif 000012
【図１０】
2012123701.tif 000013
【図１１】
2012123701.tif 000014
【図１２】
2012123701.tif 000015
【図１３】
2012123701.tif 000016