JP5855072B2 - 融資システム、信用情報生成装置、融資判定装置、融資条件判定方法、信用情報生成プログラム及び融資条件判定プログラム - Google Patents

Description

本発明は、融資システム、信用情報生成装置、融資判定装置、融資条件判定方法、信用情報生成プログラム及び融資条件判定プログラムの技術に関する。

従来、事業者向けの融資可能枠を情報処理によって導出する技術として、当該事業者の事業実績に加え、売掛債権を適切に評価して追加与信額を算定する技術（例えば、特許文献１参照）や、借入希望者に対する第三者の評価を債権情報として公開し投資家から融資可能額を入札形式で募る技術（例えば、特許文献２参照）が知られている。

特開２００７−１７２１４１号公報 特開２０１０−２３１２６８号公報

しかしながら、上記特許文献に記載される技術において、売掛債権の評価や事業者に対する第三者評価は、事業者の決算書（例えば、財務諸表や損益計算書等）に基づくものである。即ち、「中長期的」な評価軸・評価基準により、融資条件（融資枠）の算出を行う技術であるため、「短期的」な融資条件を精度よく算出するには適さないという問題があった。

例えば、前年度の決算書の結果が思わしくなかった事業者であったとしても、つい最近になって業績が急上昇中の事業者に対しては、前年度のみならず、むしろ直近の業績を考慮の上、融資条件の算出を行うことが望ましい。

また、融資条件を算出するにあたっては、決算書の内容（財務上の業績）のみならず、それ以外の評価軸、例えば、販促活動、事業者の話題性、Ｗｅｂマーケティング活動なども考慮されることで、その事業者に対して、より精度よく融資枠を算出可能である。しかしこれら評価軸は、短期的な流動性が高く、融資条件の算出に利用するのは困難であった。

本発明は、上記の点に鑑み提案されたものであり、直近の短期的・多面的な評価軸により、精度よく、事業者の融資条件を算出するための評価を行う融資システム等を提供することにある。

上記の課題を解決するため、本発明に係る融資システムは、融資条件を判定する融資判定装置と、前記融資判定装置に対し融資を希望する店舗の信用情報を提供する信用情報生成装置と含む融資システムであって、前記信用情報生成装置は、店舗運営の実績データを記憶した記憶手段と、所定期間内の前記実績データに基づいて、店舗のスコアデータを生成するスコアデータ生成手段と、前記スコアデータに基づいて、店舗の信用情報を生成する信用情報生成手段と、を有し、前記融資判定装置は、前記店舗の信用情報を取得する信用情報取得手段と、前記店舗の信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段とを有する。

本発明の実施の形態によれば、直近の短期的・多面的な評価軸により、精度よく、事業者の融資条件を算出するための評価を行うことができる。

融資の枠組みを説明する全体図である。 機能構成例を示す図である。 信用情報生成サーバ１５０のハードウェア構成例を示す図である。 店舗基本データの一例を示す。 予約実績データの一例を示す。 クーポン実績データの一例を示す。 売上実績データの一例を示す。 顧客履歴データの一例を示す。 Ｗｅｂ管理データの一例を示す。 スコアデータの一例を示す。 信用情報の一例を示す。 スコアデータ生成処理を示すフローチャート図である。 信用情報生成処理を示すフローチャート図である。 融資条件判定処理を示すフローチャート図である。 融資条件表示画面例を示す。 融資条件表示画面例を示す。 融資条件表示画面例を示す。 融資条件表示画面例を示す。

以下、本発明の好適な実施形態につき説明する。

[構成]
＜融資の枠組み＞
図１は、本実施形態に係る融資の枠組みを説明する全体図である。本実施形態では、図に示されるように、店舗ソリューションサービス提供事業者１、店舗ソリューションサービス利用店舗（群）２、金融業者３が存在する。

店舗ソリューションサービス提供事業者１（以下、単に提供事業者１という）は、店舗ソリューションサービス利用店舗２に対し、様々な店舗運営関係のシステムを、店舗ソリューションサービスとして提供する事業者である。

店舗ソリューションサービスとは、従来、店舗側が自前で用意する必要のあった店舗運営に関するシステムを、外部の事業者にアウトソースする形で提供されるもので、ネットワークを介したＡＳＰ（Application Service Provider）型の店舗運営に関するシステムである。例えば、ＡＳＰ型の予約システム、ＣＲＭ（Customer Relationship Management）ツール、ＰＯＳ（Point of Sale）システム、売上管理システムなどがある。また、近年、インターネットが普及に伴い、Ｗｅｂサイトの構築や運営、ネット広告など、インターネットサービスなどもある。

店舗ソリューションサービス利用店舗２（以下、単に店舗２という）は、店舗を構え、提供事業者１により提供される各種の店舗ソリューションサービスを利用しながら、商業活動を営む店舗事業者である。店舗ソリューションサービスは、例えば、店舗側の店舗端末（例えば、ＰＣ等）のＷｅｂブラウザや専用アプリケーションを介して提供されうる。店舗側は、店舗端末のＷｅｂブラウザ等から、提供事業者１の店舗ソリューション提供サーバ等にアクセスし、ユーザ・ログインを行うと、各種の店舗ソリューションサービスを利用することができる。

なお、店舗自体は、仮想的な店舗（インターネット上の店舗）であってもよい。店舗自体は物理的に存在しなくとも、商業活動を行う以上、少なくとも上記何れかの店舗ソリューションサービスを利用しうるためである。但し、本実施形態においては、説明を容易にするため、店舗２は、リアルな店舗（例えば、レストラン、小売店等）を想定するものとする。

金融業者３は、店舗２を営む事業者に対し、事業資金等の融資（貸付）を行う金融業者である。金融業者３は、店舗２の事業者から、融資の申し出（申し込み）があると、融資判定用の端末を用い、提供事業者１に対し、融資の申し出を行った店舗２に関する信用情報の照会を行う。金融業者３は、提供事業者１から、信用情報の提供を受けると、端末を用い、融資審査の上、融資条件（融資枠）を判定し、判定された融資条件を参考に、実際の融資を行う。なお、本明細書でいう融資条件は、例えば、融資金額、融資期間、融資金利がある。

＜店舗ソリューションサービス＞
店舗ソリューションサービスは、上述したように、提供事業者１が店舗２に対して提供する店舗運営に関するシステムである。例えば、予約システム、ＣＲＭツール、ＰＯＳシステム、売上管理システムなどがある。また、Ｗｅｂサイトの構築や運営、ネット広告の提供などの、インターネットサービスなどもある。

予約システムは、インターネット上から、顧客の予約を受け付けて、予約状況を管理するためのシステムである。また、店舗に対し電話予約などで予約が入った場合には、店舗側が予約システムにアクセスし、その予約を入力することで、予約全体を管理することもできる。予約システムは、現在の予約や、過去の予約、キャンセルの有無など、多面的な予約データを有する。このため、予約データを用いて、店舗側に対し、表や統計等の形で、各種予約分析データを提供することも可能となっている。

ＣＲＭツールは、顧客名簿、会員名簿、購買履歴など、顧客管理を行う。また、近年のＣＲＭでは、クーポンの発行・回収など、クーポン管理（効果分析等も含む）なども行う。ＣＲＭツールは、顧客の来店データ、購買履歴など、多面的な顧客管理データを有する。このため、顧客管理データを用いて、店舗側に対し、客層やリピート率など、各種顧客分析データを提供することも可能となっている。特に、クーポン管理に関しては、クーポン発行の時期、枚数、種類などと、クーポン回収枚数との関係に基づいて、効果分析を行うことも可能である。

ＰＯＳ（Point of Sale）システムは、店舗で商品や飲食物を販売するごとに、商品の販売情報を記録・集計する。集計結果は、売上管理、在庫管理や仕入管理などに利用する。
ＰＯＳシステムは、商品の販売情報、日時刻など、多面的な販売管理データを有する。このため、販売管理データを用いて、店舗側に対し、売れ筋商品など、各種販管分析データを提供することも可能となっている。

売上管理システムは、ＰＯＳシステムやレジシステムと連携し、売上管理、売掛金管理などを行う。また、決済内訳（例えば、現金又はカード等）、売上内訳（例えば、飲食、物販等）など、売上分析データを提供することも可能となっている。

また、インターネットサービスは、店舗Ｗｅｂサイトをレンタルサーバに設置する他、サイトのアクセス数、検索回数、検索ワード、口コミ投稿数、口コミ内容など、Ｗｅｂ管理データを提供する。また、広告媒体に対し、インターネット広告の配信の他、配信広告に対する効果分析を行うことも可能である。

＜システム構成＞
（機能）
図２は、本実施形態に係る機能構成例を示す図である。提供事業者１は、店舗ソリューション提供サーバ１１０、店舗ソリューションＤＢ１２０、Ｗｅｂソリューション提供サーバ１３０、ＷｅｂソリューションＤＢ１４０、信用情報生成サーバ１５０を有している。また、金融業者３は、融資判定端末３１０を有している。

店舗ソリューション提供サーバ１１０は、店舗２に対し、店舗ソリューションサービスを提供する。このとき、店舗ソリューション提供サーバ１１０は、各種の店舗ソリューションサービスに用いられる各種の情報を店舗ソリューションＤＢ１２０に格納する。

例えば、レストランである店舗２に対して、予約システムを提供する場合、店舗ソリューションＤＢ１２０は、店舗ＩＤ毎に、予約日時、人数、コース内容などの予約データを管理し格納する。また例えば、小売店である店舗２に対して、ＣＲＭツールを提供する場合、店舗ソリューションＤＢ１２０は、店舗ＩＤ毎に、顧客名簿（会員名簿）、購買履歴などの顧客データを管理し、格納・蓄積する。

Ｗｅｂソリューション提供サーバ１３０は、店舗２に対し、Ｗｅｂソリューションサービスを提供する。このとき、Ｗｅｂソリューション提供サーバ１３０は、各種のＷｅｂソリューションサービスに用いられる各種の情報をＷｅｂソリューションＤＢ１４０に格納する。

例えば、店舗２に対して、店舗Ｗｅｂサイトを提供する場合、ＷｅｂソリューションＤＢ１４０は、店舗ＩＤ毎に、サイトのアクセス数、検索回数、検索ワード、口コミ投稿数、口コミ内容などＷｅｂ管理データを管理し、格納・蓄積する。

信用情報生成サーバ１５０は、スコアデータ生成部１５１、記憶部１５２、信用情報生成部１５３を有している。

スコアデータ生成部１５１は、店舗ソリューションＤＢ１２０に格納・蓄積されているログデータ（店舗運営の店舗実績データ）、ＷｅｂソリューションＤＢ１４０に格納・蓄積されているログデータ（店舗のＷｅｂ管理データ）を取得し、取得したログデータを用いて、各店舗のスコアデータを生成する。このスコアデータは、融資条件の判定・決定に利用される信用情報の元となるものである。また、スコアデータ生成部１５１は、スコアデータの生成と共に、取得したログデータを用いて、スコアデータに付帯させるための付帯情報を生成する。

なお、スコアデータに付帯される付帯情報は、具体的には、店舗ソリューションＤＢ１２０に格納・蓄積されている店舗実績データ、ＷｅｂソリューションＤＢ１４０に格納・蓄積されているＷｅｂ管理データである。つまり、スコアデータ生成部１５１がスコアデータを生成したときに使用した店舗実績データ及びＷｅｂ管理データのＲＡＷデータ（生データ）である。付帯情報は、融資判定端末３１０側で、再度、スコアデータの再生成を行う場合に用いられる。

また、スコアデータ生成部１５１は、店舗ソリューションＤＢ１２０及びＷｅｂソリューションＤＢ１４０にアクセスし、定期的にログデータを取得の上、各店舗のスコアデータ及び付帯情報を生成し、生成した各店舗のスコアデータ及び付帯情報を、記憶部１５２に保存する。

信用情報生成部１５３は、信用情報生成サーバ１５０が金融業者３の融資判定端末３１０から店舗２に関する信用情報の照会を受信すると、記憶部１５２から生成済みの店舗２のスコアデータ、併せて付帯情報を取得する。そして、取得したスコアデータに基づいて、最終的に金融業者３に対し提供される信用情報を生成する。

信用情報が生成されると、信用情報生成サーバ１５０は、信用情報生成部１５３により生成された信用情報を、記憶部１５２から併せて取得した付帯情報を付して、融資判定端末３１０に送信する。

次に、融資判定端末３１０は、信用情報取得部３１１、融資条件判定部３１２を有している。

信用情報取得部３１１は、信用情報生成サーバ１５０に対し、融資希望の店舗２に関する信用情報の照会を行うことにより、店舗２の信用情報を取得する。また、併せて付帯情報を取得する。

融資条件判定部３１２は、店舗２の信用情報に基づいて、店舗２に対する融資条件（融資金額、融資期間、融資金利等）を判定する。金融業者３は、判定結果の融資条件に従って、店舗２に対し実際の融資を行うことができる。

なお、信用情報生成サーバ１５０の有する機能部は、装置を構成するコンピュータのＣＰＵ、ＲＯＭ、ＲＡＭ等のハードウェア資源上で実行されるコンピュータプログラムによって実現されるものである。但し、これらの機能部は、「手段」、「モジュール」、「ユニット」、又は「回路」に読替えてもよい。

また、信用情報生成サーバ１５０の有する機能部は、単一のコンピュータ上に配置される必要はなく、必要に応じて分散される形態であってもよい。

また、例えば、店舗ソリューションＤＢ１２０やＷｅｂソリューションＤＢ１４０は、店舗ソリューション提供サーバ１１０やＷｅｂソリューション提供サーバ１３０と一体して構築してもよい。また、店舗ソリューションサーバ１１０とＷｅｂソリューション提供サーバ１３０についても、１台のサーバとして、一体の構成としてもよい。

（ハードウェア構成）
図３は、本実施形態に係る信用情報生成サーバ１５０のハードウェア構成例を示す図である。信用情報生成サーバ１５０は、主要な構成として、ＣＰＵ（Central Processing Unit）１１、ＲＯＭ（Read Only Memory）１２、ＲＡＭ（Random Access Memory）１３、入力装置１４、表示装置１５、通信装置１６、ＨＤＤ１７などを備える。

ＣＰＵ１１は、マイクロプロセッサ及びその周辺回路から構成され、サーバ全体を制御する回路である。また、ＲＯＭ１２は、ＣＰＵ１１で実行される所定の制御プログラム（ソフトウェア部品）を格納するメモリであり、ＲＡＭ１３は、ＣＰＵ１１がＲＯＭ１２に格納された所定の制御プログラム（ソフトウェア部品）を実行して各種の制御を行うときの作業エリア（ワーク領域）として使用するメモリである。

入力装置１４は、ユーザ（管理者）が各種入力操作を行うための装置である。入力装置１４は、マウス、キーボードなどを含む。表示装置１５は、表示画面を表示する装置である。例えば、ＬＣＤ(Liquid Crystal Display)、ＣＴＲ(Cathode Ray Tube)などから構成される。

通信装置１６は、ネットワークを介して他装置との通信を行う装置である。有線ネットワークや無線ネットワークなど含む各種ネットワーク形態に応じた通信をサポートする。

ＨＤＤ１７は、汎用のＯＳ（Operating System）、広告に係る各種ＤＢ、本発明に係るプログラムなどを格納する装置であり、不揮発性の記憶装置であるＨＤＤ（Hard Disk Drive）などが用いられる。なお、上記各種情報は、ＨＤＤ１７以外にも、ＣＤ−ＲＯＭ（Compact Disk - ROM）やＤＶＤ（Digital Versatile Disk）などの記憶媒体やその他のメディアを記憶されてもよく、これらの記憶媒体に格納された各種情報は、記憶媒体読取装置などのドライブ装置を介して読み取ることが可能である。よって、必要に応じて記録媒体を記憶媒体読取装置にセットすることで、各種情報が得られる。

なお、融資判定端末３１０については、ＰＣ（Personal Computer）、スマートフォン、携帯電話、タブレット端末、ＰＤＡ（Personal Digital Assistants）等の情報処理機器から構成されればよく、融資判定端末３１０に関し特段の図示は省略する（非図示）。

＜店舗ソリューションＤＢ１２０＞
上述したように、店舗ソリューション提供サーバ１１０は、店舗２に対し、店舗ソリューションサービスを提供する。このため、店舗ソリューション提供サーバ１１０は、各種の店舗ソリューションサービスに用いられる各種の情報を店舗ソリューションＤＢ１２０に格納する。以下、店舗ソリューションＤＢ１２０に格納される情報例として、店舗基本データ、予約実績データ、クーポン実績データ、売上実績データ、顧客履歴データの例を示す。

（店舗基本データ）
図４は、本実施形態に係る店舗基本データの一例を示す。店舗基本データは、店舗ソリューションサービスの提供先である店舗２の基本データである。具体的に、店舗基本データは、「店舗ＩＤ」、「店舗名」、「代表者」、「業種」、「所在地」、「電話」、「座席数」、「従業員数」、「開店日」、「サービス導入日」などのデータ項目を有する。

これら情報は、店舗２が店舗ソリューションサービスへの加入時等、店舗２より申告される情報等に基づいて登録される。なお、登録時、店舗を識別する固有の識別子である「店舗ＩＤ」が、店舗毎に１つづつ発行され付番される。

（予約実績データ）
図５は、本実施形態に係る予約実績データの一例を示す。予約実績データは、店舗ソリューションサービスの一つである予約システムで用いられ、集計される。予約実績データは、店舗毎に、例えば１日単位で集計される。

具体的に、予約実績データは、「店舗ＩＤ」、「年月日」、「予約組数」、「予約客数」、「予約件数（Ｔｅｌ／Ｗｅｂ）」、「クーポン利用件数」、「キャンセル数」、「売上金額（予約分）」などのデータ項目を有する。
「店舗ＩＤ」は、店舗基本データの「店舗ＩＤ」に対応し、店舗を識別する識別子である。
「年月日」は、予約実績データの年月日を示す。
「予約組数」は、予約を入れた客の組数を示す。
「予約客数」は、予約を入れた客の数を示す。
「予約件数（Ｔｅｌ／Ｗｅｂ）」は、予約を入れた予約件数を示す。また、Ｔｅｌによる予約、Ｗｅｂ経由による予約方法の内訳も含む。なお、「予約件数」が多いほど、また毎日一定の予約件数が確保できているほど、店舗の将来性は大きいと判断しうる。
「クーポン利用件数」は、予約を入れた客（又は組）のうち、クーポン利用の件数を示す。なお、「クーポン利用件数」が多いほど、クーポン効果が大きいと判断しうる。
「キャンセル数」は、予約を入れた「予約件数」のうち、キャンセルの数を示す。なお、「キャンセル数」が少ないほど、店舗の将来性は大きいと判断しうる。
「売上金額（予約分）」は、予約分から発生した売上金額を示す。

（クーポン実績データ）
図６は、本実施形態に係るクーポン実績データの一例を示す。クーポン実績データは、店舗ソリューションサービスの一つであるＣＲＭツールで用いられ、集計される。クーポン実績データは、店舗毎に、例えば１日単位で集計される。

具体的に、クーポン実績データは、「店舗ＩＤ」、「年月日」、「発行枚数」、「回収枚数」などのデータ項目を有する。
「店舗ＩＤ」は、店舗基本データの「店舗ＩＤ」に対応し、店舗を識別する識別子である。
「年月日」は、クーポン実績データの年月日を示す。
「発行枚数」は、クーポンを発行した枚数を示す。発行枚数は、クーポンの種類毎にカウントされ管理される。なお、「発行枚数」が多いほど、店舗の販促活動は積極的である、ひいては、店舗の将来性は大きいと判断しうる。
「回収枚数」クーポンを回収した枚数を示す。回収枚数は、クーポン種類毎にカウントされ管理される。なお、「回収枚数」が多いほど、又は回収率（＝「回収枚数」／「発行枚数」）が高いほど、クーポン効果が大きいと判断しうる。

（売上実績データ）
図７は、本実施形態に係る売上実績データの一例を示す。売上実績データは、店舗ソリューションサービスの一つであるＰＯＳシステムや売上管理システムで用いられ、集計される。売上実績データは、店舗毎に、例えば１日単位で集計される。

具体的に、売上実績データは、「店舗ＩＤ」、「年月日」、「総売上」、「売上内訳」、「決済方法内訳」などのデータ項目を有する。
「店舗ＩＤ」は、店舗基本データの「店舗ＩＤ」に対応し、店舗を識別する識別子である。
「年月日」は、クーポン実績データの年月日を示す。
「総売上」は、売上の全て、つまり総売上の金額を示す。
「売上内訳」は、「総売上」のうち、その内訳毎の金額を示す。例えば、飲食店の場合、店舗で提供される「飲食」の売上と、お土産などの「物販」の売上とがある。
「決済方法内訳」は、「総売上」のうち、支払い時の決済方法内訳毎の金額を示す。例えば、飲食店の場合、レジでは、現金支払い、カード支払いによる決済方法がある。また、カード決済の場合、Ａというクレジットカード、Ｂというクレジットカード、Ｃという電子マネーカードという決済方法がある。

（顧客履歴データ）
図８は、本実施形態に係る顧客履歴データの一例を示す。顧客履歴データ（来店実績データ）は、店舗ソリューションサービスの一つであるＣＲＭツールで用いられ、集計される。顧客履歴データは、店舗毎に、顧客単位で集計される。

具体的に、顧客履歴データは、「店舗ＩＤ」、「年月日」、「時刻」、「会員Ｎｏ」、「氏名」、「性別」、「年齢」、「職業」などのデータ項目を有する。
「店舗ＩＤ」は、店舗基本データの「店舗ＩＤ」に対応し、店舗を識別する識別子である。
「年月日」は、顧客の来店、施設の利用、又は商品の購買等の年月日を示す。
「時刻」は、顧客の来店、施設の利用、又は商品の購買等の時刻を示す。
「会員Ｎｏ」は、顧客を識別する識別子である。店舗毎に固有の会員Ｎｏを用いて顧客を管理する。
「氏名」、「性別」、「年齢」、「職業」は、顧客情報（顧客属性）である。

これら顧客情報は、顧客が店舗への会員登録時等、顧客により申告される情報等に基づいて登録される。なお、顧客情報を含む顧客履歴データは、客層分析に用いられうる。また、履歴数等に基づいて、リピート率が高いと判断しうる。

＜ＷｅｂソリューションＤＢ１４０＞
上述したように、Ｗｅｂソリューション提供サーバ１３０は、店舗２に対し、Ｗｅｂソリューションサービスを提供する。このため、Ｗｅｂソリューション提供サーバ１３０は、各種のＷｅｂソリューションサービスに用いられる各種の情報をＷｅｂソリューションＤＢ１４０に格納する。以下、ＷｅｂソリューションＤＢ１４０に格納される情報例として、Ｗｅｂ管理データの例を示す。

（Ｗｅｂ管理データ）
図９は、本実施形態に係るＷｅｂ管理データの一例を示す。Ｗｅｂ管理データは、店舗ソリューションサービスの一つであるインターネットサービスで用いられ、集計される。Ｗｅｂ管理データは、店舗ＩＤ毎に、累計値又は一定期間間隔単位で集計される。

具体的に、Ｗｅｂ管理データは、「店舗ＩＤ」、「アクセス数」、「検索数」、「検索クエリ」、「広告数」、「ＣＴＲ」、「口コミ投稿数」、「口コミ評価」、「ネット上の注目度」などのデータ項目を有する。

「店舗ＩＤ」は、店舗基本データの「店舗ＩＤ」に対応し、店舗を識別する識別子である。

「アクセス数」は、店舗Ｗｅｂサイトへの訪問者数、つまりアクセス数である。アクセスカウンタ等によりカウントされる。「アクセス数」が多いほど、また毎日一定の「アクセス数」が確保できているほど、店舗に対するネット上の評価は大きいと判断しうる。

なお、「アクセス数」として、ユニークユーザのアクセス数をカウントしてもよい。ユニークユーザとは、店舗Ｗｅｂサイトを特定に期間のうちに訪れた人の内、ユニークな訪問者である。よって、ユニークユーザのアクセス数は、延べ訪問数ではなく、複数回訪問した同一訪問者についてはまとめて１人とカウントする。これにより、単純なアクセス数のカウントに比べ、店舗に対し興味を示している人がどれくらいいるのかを、より正確に判断できる。ユニークユーザの判別は、例えば、個別のユーザＩＤを特定できるアクセスの場合には、そのユーザIDを用いて判定することができる。また、ユーザＩＤを特定できない場合には、ブラウザに対応するＣｏｏｋｉｅ情報を用いて判定してもよい。また、無線ＷＡＮ／ＬＡＮ介した端末装置からのアクセスである場合には、端末装置固有のＩＤ（例えば、ＭＡＣアドレスなど）を用いて判定してもよい。

「検索数」は、検索エンジン等により、当該店舗（店舗Ｗｅｂサイト）が検索された回数を示す。例えば、店舗名又は店舗に関連するワードが検索ワードとして検索された場合、カウントされる。「検索数」が多いほど、また毎日一定の「検索数」が確保できているほど、店舗に対するネット上の評価は大きいと判断しうる。

「検索クエリ」は、検索エンジン等により、当該店舗（店舗Ｗｅｂサイト）が検索された場合、検索クエリ（検索ワード）に基づいて算出した評価値である。例えば、「店舗名」、「○○」という具合に、店舗名と他の検索クエリといった複数の検索クエリで検索された場合、１つの検索クエリ時よりも重い重みを付ける。また、さらに、複数クエリの内容が、例えば、「予約」、「場所」、「行き方」、「道順」、「メニュー」など、店舗評価に対しポジティブな検索クエリに対しては、さらに重い重みを付けることもできる。「検索クエリ」が高いほど、店舗に対する評価は大きいと判断しうる。

「広告数」は、店舗Ｗｅｂサイトが、例えば、インターネット広告などの広告出稿数を示す。「広告数」が多いほど、露出機会は増大するので、店舗に対するネット上の評価は大きいと判断しうる。

「ＣＴＲ」は、広告効果を測る指標の一つで、例えば、バナー広告の場合、そのクリック率を示す。よって、「ＣＴＲ」の値が高いほど、高い広告効果が得られたことになる。「ＣＴＲ」の値が高いほど、高い広告効果が得られた、ひいては店舗に対するネット上の評価は大きいと判断しうる。

「口コミ投稿数」は、店舗に関する口コミが投稿された回数を示す。口コミとは、口コミサイトなどで書き込まれた店舗に対する評価（評価値）、感想、意見等である。「口コミ投稿数」が多いほど、少なくとも、世間ユーザの店舗への関心や注目度は大きいと判断しうる。

「口コミ評価」は、口コミサイトなどで書き込まれた店舗に対する評価（評価値）の集計値（例えば、平均値）である。「口コミ評価」が高いほど、店舗に対する評価は大きいと判断しうる。

「ネット上の注目度」は、Ｗｅｂ上の店舗に対する注目度を示す。例えば、掲示板やニュース、記事、その他のＷｅｂコンテンツで、店舗に関する話題が取り上げられた場合、その内容、量、頻度等に基づいて、集計される。「ネット上の注目度」が高いほど、店舗に対する関心や注目度、ひいては評価は大きいと判断しうる。

＜スコアデータ＞
上述したように、信用情報生成サーバ１５０のスコアデータ生成部１５１は、店舗ソリューションＤＢ１２０に格納・蓄積されているログデータ（店舗運営の店舗実績データ）、ＷｅｂソリューションＤＢ１４０に格納・蓄積されているログデータ（店舗のＷｅｂ管理データ）を取得し、取得したログデータを用いて、各店舗のスコアデータを生成する。

図１０は、本実施形態に係るスコアデータの一例を示す。スコアデータは、店舗ソリューションサービスの提供先である各店舗２について、融資条件（融資金額、融資期間、融資金利等）の判定に利用される信用情報の元となるものである。このため、スコアは、融資枠を評価するための観点から見た評価軸（評価基準）のスコア値である。具体的に、スコアデータは、「財務上の評価」、「将来性の評価」、「ネット上の評価」などの評価軸（評価基準）と、それぞれのスコア値とを有する。

「財務上の評価」は、店舗２の財務上の健全性に関する評価値である。例えば、キャッシュフロー、売掛金、負債（金融業者等からの借入金、未払いの買掛金等）など、様々な観点から財務状態の健全性が評価されることにより算出される。評価が高いほど、高いスコアとなる。なお、「財務上の評価」のスコアは、主に店舗ソリューションＤＢ１２０に格納・蓄積されているログデータ（店舗運営の店舗実績データ）に基づいて、所定の評価アルゴリズム（例えば、所定の評価関数Ａ）により算出される。また、直近の店舗ソリューションＤＢ１２０に格納・蓄積されているログデータ（店舗運営の店舗実績データ）が用いられるので、つい直近の財務状態を含めた評価値が算出される。

「将来性の評価」は、店舗２の将来性に関する評価値である。例えば、クーポン発行数や回収数、予約数や予約数推移、顧客のリピート率など、財務上以外の観点から、店舗の将来性（発展可能性ともいえる）が評価されることにより算出されるスコアである。評価が高いほど、高いスコアとなる。なお、「将来性の評価」のスコアは、主に店舗ソリューションＤＢ１２０に格納・蓄積されているログデータ（店舗運営の店舗実績データ）に基づいて、所定の評価アルゴリズム（例えば、所定の評価関数Ｂ）により算出される。

「ネット上の評価」は、店舗２の話題性に関する評価値である。例えば、店舗Ｗｅｂサイトへのアクセス数、検索数、検索クエリ、広告数、ＣＴＲ、口コミ回数、口コミ評価、ネット上の注目度など、Ｗｅｂマーケティングの観点から、店舗のネット上、話題にのぼったり、注目されたりすることにより算出されるスコアである。評価が高いほど、高いスコアとなる。なお、「ネット上の評価」のスコアは、主にＷｅｂソリューションＤＢ１４０に格納・蓄積されているログデータ（店舗のＷｅｂ管理データ）に基づいて、所定の評価アルゴリズム（例えば、所定の評価関数Ｃ）により算出される。

なお、上述の「財務上の評価」、「将来性の評価」、「ネット上の評価」などの評価軸（評価基準）はあくまで一例である。スコアデータは、この外にも、融資条件を評価するための評価軸（評価基準）を含むことが可能である。

＜信用情報＞
上述したように、信用情報生成サーバ１５０の信用情報生成サーバ１５０が金融業者３の融資判定端末３１０から店舗２に関する信用情報の照会を受信すると、記憶部１５２から生成済みの店舗２のスコアデータを取得する。そして、取得したスコアデータに基づいて、最終的に金融業者３に対し提供される信用情報を生成する。

図１１は、本実施形態に係る信用情報の一例を示す。信用情報は、店舗ソリューションサービスの提供先である各店舗２に対する融資条件判定に利用される。具体的に、信用情報は、「店舗基本データ」、「スコアデータ」「倒産可能性評価」などのデータ項目を有する。

「店舗基本データ」は、店舗の基本データである。例えば、店舗ソリューションＤＢ１２０の店舗基本データ（例えば、図４）から、「店舗ＩＤ」をキーとして、「店舗基本データ」を取得の上、信用情報内に入力されうる。

「スコアデータ」は、記憶部１５２から生成済みの店舗２のスコアデータが取得されたものである（図１０）。例えば、「財務上の評価」、「将来性の評価」、「ネット上の評価」を含む。

「倒産可能性評価」は、店舗の倒産可能性を評価した評価値である。評価は、例えば、Ａ〜Ｅ等の評価値される。Ｅの場合、最も倒産可能性は低いことを示す。即ち、高評価を意味する。「倒産可能性評価」は、「スコアデータ」に基づいて、所定の評価アルゴリズム（例えば、所定の評価関数Ｄ）により算出される。

なお、上述の「店舗基本データ」、「スコアデータ」「倒産可能性評価」などのデータ項目はあくまで一例である。この外にも、融資条件を評価するためのデータ項目を含むことが可能である。

信用情報は、信用情報生成サーバ１５０により、記憶部１５２から併せて取得した付帯情報と共に融資判定端末３１０に送信される。

[信用情報生成サーバ１５０の情報処理]
（スコアデータ生成処理）
図１２は、本実施形態に係る信用情報生成サーバ１５０のスコアデータ生成処理を示すフローチャート図である。以下、図面を参照しながら説明する。

Ｓ１：スコアデータ生成部１５１は、スコアデータ生成のタイミングになったか否かを判定する。スコアデータ生成のタイミングは、予め管理者により、例えば、一日一回、所定の時刻など、規定値が定められる。一日数回、または数日に一回としてもよい。また、店舗ソリューションＤＢ１２０及びＷｅｂソリューションＤＢ１４０の更新タイミングに合わせてもよい。

Ｓ２：スコアデータ生成部１５１は、スコアデータ生成のタイミングになると、店舗ソリューションＤＢ１２０にアクセスし、可能な限り、全店舗の店舗実績データを取得する。店舗実績データは、例えば、予約実績データ（図５）、クーポン実績データ（図６）、売上実績データ（図７）、顧客履歴データ（図７）を含む。また、全店舗とは、店舗ソリューションの提供を受ける全ての店舗の実績データを取得する。全店舗分のスコアデータを生成しておくためである。また、可能な限りとは、店舗が未提供のサービスについての店舗実績データは、存在しないため、その分の店舗実績データは取得しない（取得できない）。

Ｓ３：スコアデータ生成部１５１は、続いて、ＷｅｂソリューションＤＢ１４０にアクセスし、全店舗のＷｅｂ管理データ（図９）を取得する。店舗実績データと同様、全ての店舗のＷｅｂ管理データを取得する。但し、Ｗｅｂ管理データが存在しない場合、その店舗分のＷｅｂ管理データは取得しない（取得できない）。

Ｓ４：スコアデータ生成部１５１は、取得した店舗実績データ、Ｗｅｂ管理データを用いて、各店舗のスコアデータを生成する。上述したように、スコアデータは、例えば、「財務上の評価」、「将来性の評価」、「ネット上の評価」を含む（図１０）。

このうち、「財務上の評価」は、主に店舗ソリューションＤＢ１２０に格納・蓄積されている店舗運営の店舗実績データを入力値として、所定の評価アルゴリズム（例えば、所定の評価関数Ａ）により算出される。また、「将来性の評価」のスコアは、主に店舗ソリューションＤＢ１２０に格納・蓄積されている店舗運営の店舗実績データを入力値として、所定の評価アルゴリズム（例えば、所定の評価関数Ｂ）により算出される。また、「ネット上の評価」のスコアは、主にＷｅｂソリューションＤＢ１４０に格納・蓄積されている店舗のＷｅｂ管理データを入力値として、所定の評価アルゴリズム（例えば、所定の評価関数Ｃ）により算出される。

Ｓ５：スコアデータ生成部１５１は、取得した店舗実績データ、Ｗｅｂ管理データを用いて、各店舗の付帯情報を生成する。付帯情報は、後述のＳ２４で、信用情報と共に融資判定端末３１０に送信されるものである。

Ｓ６：スコアデータ生成部１５１は、例えば、店舗毎（店舗ＩＤ毎）に、生成した信用情報と付帯情報とを対応付けて、記憶部１５２に保存する。なお、記憶部１５２に保存される信用情報及び付帯情報は、更新の度に過去の信用情報及び付帯情報に上書き更新してもよい。また、過去の信用情報及び付帯情報は、一定期間は保存しておき、一定期間経過後、削除するようにしてもよい。

（信用情報生成処理）
図１３は、本実施形態に係る信用情報生成サーバ１５０の信用情報生成処理を示すフローチャート図である。

Ｓ２１：信用情報生成部１５３は、金融業者３の融資判定端末３１０から店舗２に関する信用情報の照会（照会要求）を受信したか否かを判定する。なお、信用情報の照会（照会要求）は、対象となる店舗２を特定するための情報として、例えば、店舗ＩＤを含む。

Ｓ２２：信用情報生成部１５３は、店舗ＩＤをキーとして、記憶部１５２から、照会対象店舗の信用情報及び付帯情報を取得する。

Ｓ２３：信用情報生成部１５３は、取得したスコアデータに基づいて、信用情報を生成する（図１１）。

Ｓ２４：信用情報生成部１５３は、信用情報を生成すると、生成した信用情報と、記憶部１５２から併せて取得した付帯情報とを、融資判定端末３１０に送信する。

[融資判定端末３１０の情報処理]
（融資条件判定処理）
図１４は、本実施形態に係る融資判定端末３１０の融資条件判定処理を示すフローチャート図である。

Ｓ３１：融資条件判定部３１２は、金融業者３により対象店舗を指定する情報（例えば、店舗ＩＤ）と共に照会操作が入力されると、信用情報生成サーバ１５０に対し、信用情報の照会（照会要求）を送信する。

Ｓ３２：信用情報生成部１５３は、照会（照会要求）の応答として、対象店舗に対する信用情報及び付帯情報の照会（照会要求）を受信したか否かを判定する。なお、信用情報生成部１５３は、少なくとも、信用情報を一定時間の間に受信しない場合、表示画面等にエラーを出力する（Ｓ３５）。

Ｓ３３：融資条件判定部３１２は、店舗２の信用情報に基づいて、店舗２に対する融資条件を判定する。「融資条件」は、スコアデータに基づいて、所定の判定アルゴリズム（例えば、所定の判定関数Ｅ）により判定される。

本実施形態に係るスコアデータは、「財務上の評価」、「将来性の評価」、「ネット上の評価」を有する。このため、「融資条件」は、これらスコアデータ及び融資希望条件（店舗希望の融資条件）を入力値として、所定の判定アルゴリズムにより算出される。

Ｓ３４：融資条件判定部３１２は、判定結果として、店舗２に対する融資条件（融資枠）を、表示画面等に出力する。

[融資条件の出力画面例]
図１５は、本実施形態に係る融資判定端末３１０の融資条件表示画面例を示す。画面１５００は、信用情報欄１５０１、希望条件欄１５０２、可能融資条件欄１５０３を有する。

信用情報欄１５０１は、信用情報生成サーバ１５０から受信した店舗の信用情報が表示される欄である。金融業者３は、「修正」１５０１−２により、信用情報の内容を修正できる。なお、原則的には、信用情報の内容は修正されることはない。しかしながら、融資条件は、この信用情報に応じて判定される。このため、金融業者３は、信用情報生成サーバ１５０から受信した店舗の信用情報の内容を修正できるようにすることで、金融業者３の特別な事情等を加味した上で、融資条件を判定することができる。

希望条件欄１５０２は、店舗が希望する融資の希望条件が表示される欄である。希望条件は、金融業者３により入力される。金融業者３は、「修正」１５０２−２により、希望条件の内容を修正できる。また、金融業者３が希望条件を仮変更することで、その仮希望条件を前提とした融資条件をシミュレーション判定することができる。

可能融資条件欄１５０３は、店舗２の信用情報に基づいて判定された融資条件が表示される欄である。上述のＳ３３の判定結果が表示される。金融業者３は、最終的にこの融資条件を参照し、実際に対象店舗に対し、融資を行うか否かを判断する。また、融資を行う場合、具体的にどのような融資条件で融資を行うのかを判断する。

なお、言うまでもなく、可能融資条件欄１５０３に表示される融資条件は、あくまで一つの判断材料である。金融業者３は、必ずしもこの融資条件に拘束されるものではない。このため、金融業者３は、可能融資条件欄１５０３に表示される融資条件の他、別途、金融業者３側で用意している店舗の決算書やその他の諸事情等を参考にし、最終的な融資条件を判断することができる。

ただ、可能融資条件欄１５０３に表示される融資条件は、上述してきたように、店舗実績データやＷｅｂ管理データに基づくスコアデータを用いて判定された融資条件であるので、いわば従来の決算書等のみからでは、判定しえない融資条件である。このため、金融業者３は、可能融資条件欄１５０３に表示される融資条件を一定以上は考慮に入れることが望ましい。これにより、金融業者３は、最終的な融資条件の判断に、直近の短期的・多面的な評価軸を取りいれることができるため、より精度よく、最終的な融資条件を判断することが可能となる。

また、融資判定端末３１０は、スコアデータと共に、付帯情報を受信している。ここで、上述したように、スコアデータに付帯される付帯情報は、具体的には、スコアデータ生成部１５１がスコアデータを生成したときに使用した店舗実績データ及びＷｅｂ管理データのＲＡＷデータ（生データ）である。よって、融資判定端末３１０は、店舗実績データ及びＷｅｂ管理データのＲＡＷデータをそのまま、又は見易いように加工の上、融資判定端末３１０上から参照できるようにしてもよい。金融業者３は、店舗実績データ及びＷｅｂ管理データを参照することで、最終的な融資条件の判断の参考にすることができる。

また、後述するように、融業者３は、画面１５００中、「カスタマイズ」１５４０を押下し、後述する設定を行った上、「再判定」１５０５を押下することにより、融資条件を再判定することができる。

[判定パラメータのカスタマイズ]
図１６〜１８は、本実施形態に係る融資判定端末３１０の融資条件表示画面例を示す。画面１６００は、カスタマイズ項目１６０１、調整バー１６０２、調整ツマミ１６０３を有する。

カスタマイズ項目１６０１は、融資条件の判定に用いられるパラメータ項目である。調整バー１６０２は、カスタマイズ項目１６０１毎に設置され、調整可能な重み値の範囲を示す。調整ツマミ１６０３は、ユーザにより操作されるもので、重み値を適用値まで調整するツマミである。標準値（デフォルト値）を示すツマミの標準位置は、調整バー１６０２の中心である。

通常の場合、受信した信用情報に応じて、可能融資条件が判定される。しかしながら、金融業者３は、判定パラメータを調整・変更することにより、店舗に対して特別な事情等を加味することができる。判定パラメータが調整された場合、融資条件は、調整・変更されたパラメータの重み値が加味されて判定されることになる。

例えば、金融業者３が店舗に融資を行う場合に、特に「予約推移」を標準程度よりも重視して融資したい場合がある。この場合、金融業者３は、「予約推移」１６０の調整ツマミ１６０３を、右方向に移動させる。右方向に行くほど、「予約推移」を重視する程度を強くすることができる。

これに対し、「予約推移」を、標準程度よりも軽視して融資したい場合、金融業者３は、「予約推移」１６０の調整ツマミ１６０３を、左方向に移動させる。左方向に行くほど、「予約推移」を重視しない程度を強くすることができる。

このような要領で、金融業者３は、例えば、以下の判定パラメータの重み付けを調整可能である（図１６〜１８）。
「予約」：「予約推移」、「キャンセルの少なさ」
「クーポン」：「発行数」、「回収率」
「売上内訳」：「サービスと物販の売上比率」、「担保」
「決済方法」：「現金とクレジットカードの決済比率」、「カード○○（カード種類選択）での決済」
「顧客層」：「男女比」、「年齢層比」、「リピート率」
「Ｗｅｂ実績」：「アクセス数」、「検索数」、「検索クエリ」、「広告数」、「ＣＴＲ」、「口コミ投稿回数」、「口コミ評価」
金融業者３は、判定パラメータを調整・変更を終了させると、「再判定」１５０５を押下することにより、融資条件が再判定される。これにより、信用情報欄１５０１には、再計算された信用情報が、可能融資条件欄１５０３には、再判定された融資条件が再表示される。

なお、図１６に示される「担保」とは、融資条件の融資金額を判定する際、売上額、又はカード決済額のうち、担保として組み入れる割合を示す。例えば、売上ｘ（円）に対し、「担保」が５％（標準）の場合、ｘ×１．０５（円）分が、自動的に担保として組み入れられる（確保される）。この分、融資条件の融資金額において、最低限、担保分の金額は確保される。例えばこの場合、融資条件の融資金額は、少なくとも、ｘ×１．０５（円）以上の融資金額が判定される。

（判定パラメータの扱い）
融資判定端末３１０の融資条件判定部３１２は、信用情報生成サーバ１５０と同様、スコアデータ生成時に用いられた所定のアルゴリズム（例えば、所定の評価関数Ａ、Ｂ、Ｃ、Ｄ）を有する。このため、融資条件判定部３１２は、判定パラメータを調整・変更された場合、まず、調整・変更された判定パラメータと付帯情報とを用いて、スコアデータを再生成する。

ここで、上述したように、スコアデータに付帯される付帯情報は、具体的には、スコアデータ生成部１５１がスコアデータを生成したときに使用した店舗実績データ及びＷｅｂ管理データのＲＡＷデータ（生データ）である。

そして、そもそも、信用情報生成サーバ１５０でのスコアデータ生成時には、カスタマイズ項目１６０１に示されるパラメータが加味されているが、このとき、パラメータが加味される程度は、調整バー１６０２の中心に位置する標準値である。

従って、今回、融資条件判定部３１２は、判定パラメータを調整・変更された場合、調整・変更された判定パラメータを用いて（及び付帯情報を用いて）、スコアデータを再生成する。これにより、調整・変更された判定パラメータが反映されたスコアデータが再生成される。

そして、融資条件判定部３１２は、スコアデータに基づいて信用情報のスコアデータの部分を修正する。なお、修正された信用情報は、信用情報欄１５０１に自動的に反映される（図１５）。この修正は、金融業者３が「修正」１５０１−２により、手動で信用情報の内容を修正した場合と同様に反映される。

金融業者３により「再判定」１５０５が押下されると、融資条件判定部３１２は、店舗２の修正後の信用情報に基づいて、店舗２に対する融資条件（融資枠）を判定する。なお、「融資条件」は、修正後のスコアデータに基づいて、所定の判定アルゴリズム（例えば、所定の判定関数Ｅ）により判定される。つまり、ここで判定された融資条件は、調整・変更された判定パラメータが加味された融資条件である。

例えば、「予約推移」１６０の調整ツマミ１６０３により、「予約推移」をより重視するとされた場合、予約実績データ（図５）において、予約推移が堅調に増加傾向にある店舗に対しては、例えば、スコアデータのうち、「将来性の評価」のスコアが高く算出される（図１５の１５０１）。これは、「将来性の評価」のスコアを算出する所定の評価アルゴリズム（例えば、所定の評価関数Ｂ）において、「予約推移」に関する重み係数の値を大きくした結果である。その結果、判定パラメータ調整・変更前よりも、好条件の融資条件が判定されうる（図１５の１５０３）。具体的に、融資金額が増加したり、融資期間が長くなったり、融資金利が低下する。

なお、変形例として、付帯情報を用いないで、調整・変更された判定パラメータが反映された融資条件を判定することも可能である。この場合、融資条件判定部３１２は、判定パラメータを調整・変更された場合、調整・変更された判定パラメータを用いて、既判定済みの融資条件を直接修正する。

例えば、「予約推移」１６０の調整ツマミ１６０３により、「予約推移」をより重視するとされた場合、融資条件のうち、融資金額を一定分上乗せ修正したり、融資期間を一定期間上乗せ修正したり、融資金利を一定率下方へ修正することができる。

[総括]
以上のように、本実施形態に係る融資条件は、従来の決算書等のみから判定される融資条件とは異なり、リアルタイムに蓄積・更新される店舗実績データやＷｅｂ管理データに基づいて用いて判定される融資条件である。これにより、金融業者３は、最終的な融資条件の判断に、直近の短期的・多面的な評価軸を取りいれることができるため、より精度よく、最終的な融資条件を判断することが可能となる。

以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。

例えば、提供事業者１及び金融業者３を別主体として説明した。しかしながら、提供事業者１及び金融業者３を同一主体として、本発明を適用することもできる。この場合、提供事業者１は、金融業者３を兼ねる店舗ソリューション提供事業者である。提供事業者１は、店舗ソリューション提供先の店舗２からの融資申し出を受けて、融資条件の判定を行い、店舗２に対し、実際の融資を行う。

１ 店舗ソリューションサービス提供事業者
２ 店舗ソリューションサービス利用店舗
３ 金融業者
１１０ 店舗ソリューション提供サーバ
１２０ 店舗ソリューションＤＢ
１３０ Ｗｅｂソリューション提供サーバ
１４０ ＷｅｂソリューションＤＢ
１５０ 信用情報生成サーバ
１５１ スコアデータ生成部
１５２ 記憶部
１５３ 信用情報生成部
３１０ 融資判定端末
３１１ 信用情報取得部
３１２ 融資条件判定部

Claims (9)

1. 融資条件を判定する融資判定装置と、前記融資判定装置に対し融資を希望する店舗の信用情報を提供する信用情報生成装置と含む融資システムであって、
   前記信用情報生成装置は、
   店舗情報の検索数又は検索クエリを含むＷｅｂ管理データを記憶する記憶手段と、
   所定期間内の前記Ｗｅｂ管理データに基づいて、店舗のスコアデータを生成するスコアデータ生成手段と、
   前記スコアデータに基づいて、店舗の信用情報を生成する信用情報生成手段と、
   を有し、
   前記融資判定装置は、
   前記店舗の信用情報を取得する信用情報取得手段と、
   前記店舗の信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段と、
   を有することを特徴とする融資システム。
2. 前記融資条件判定手段は、前記Ｗｅｂ管理データに対応して付与された重み値に基づいて、前記融資条件を再判定すること、
   を特徴とする請求項１記載の融資システム。
3. 融資条件を判定する融資判定装置と、前記融資判定装置に対し融資を希望する店舗の信用情報を提供する信用情報生成装置と含む融資システムの融資条件判定方法であって、
   前記信用情報生成装置が、
   店舗情報の検索数又は検索クエリを含むＷｅｂ管理データを記憶する手順と、
   所定期間内の前記Ｗｅｂ管理データに基づいて、店舗のスコアデータを生成する手順と、
   前記スコアデータに基づいて、店舗の信用情報を生成する手順と、
   を実行し、
   前記融資判定装置が、
   前記店舗の信用情報を取得する手順と、
   前記店舗の信用情報に基づいて、店舗に対する融資条件を判定する手順と、
   を実行することを特徴とする融資条件判定方法。
4. 融資を希望する店舗の信用情報を生成する信用情報生成装置であって、
   店舗情報の検索数又は検索クエリを含むＷｅｂ管理データを記憶する記憶手段と、
   所定期間内の前記Ｗｅｂ管理データに基づいて、店舗のスコアデータを生成するスコアデータ生成手段と、
   前記スコアデータに基づいて、店舗の信用情報を生成する信用情報生成手段と、
   を有することを特徴とする信用情報生成装置。
5. 融資を希望する店舗の融資条件を判定する融資判定装置であって、
   信用情報生成装置により、所定期間内の店舗情報の検索数又は検索クエリを含むＷｅｂ管理データに基づいて生成された店舗の信用情報を取得する信用情報取得手段と、
   前記信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段と、
   を有することを特徴とする融資判定装置。
6. コンピュータを、
   店舗情報の検索数又は検索クエリを含むＷｅｂ管理データを記憶する記憶手段と、
   所定期間内の前記Ｗｅｂ管理データに基づいて、店舗のスコアデータを生成するスコアデータ生成手段と、
   前記スコアデータに基づいて、店舗の信用情報を生成する信用情報生成手段として機能させるための信用情報生成プログラム。
7. コンピュータを、
   信用情報生成装置により、所定期間内の店舗情報の検索数又は検索クエリを含むＷｅｂ管理データに基づいて生成された店舗の信用情報を取得する信用情報取得手段と、
   前記信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段として機能させるための融資条件判定プログラム。
8. 融資を希望する店舗の融資条件を判定する融資判定装置であって、
   信用情報生成装置により、所定期間内の店舗運営の予約実績データ又は発行クーポン実績データを含む実績データに基づいて生成された店舗の信用情報を取得する信用情報取得手段と、
   前記信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段と、
   を有することを特徴とする融資判定装置。
9. コンピュータを、
   信用情報生成装置により、所定期間内の店舗運営の予約実績データ又は発行クーポン実績データを含む実績データに基づいて生成された店舗の信用情報を取得する信用情報取得手段と、
   前記信用情報に基づいて、店舗に対する融資条件を判定する融資条件判定手段として機能させるための融資条件判定プログラム。

Images