JP6718552B1 - 営業支援用情報処理装置 - Google Patents

Abstract

【課題】法人情報の変化を検知して、新たなビジネスニーズをとらえる情報処理装置を提供する。【解決手段】法人の情報の変化を取得する手段と、当該法人の情報の変化を基に、該当する可能性のある法人の一覧を抽出する手段と、優先順位判定テーブルを基に、前記一覧から最も優先順位の高い法人を抽出する手段と、前記最も優先順位の高い法人の属性情報を基に、事例データベースから過去の事例を検索する手段とを備えることを特徴とする情報処理装置。【選択図】図４

Description

本発明は、営業を支援するための情報処理システムに関するものであり、特に、新たな法人情報を検知して、営業を支援するための情報処理システムに関するものである。

営業を支援するためのデータは散在しているケースが多い。特に、外部データ（自社内では不足している情報）は蓄積する環境すらないこともある。散在するデータをマーケティングＤＢに蓄積するケースも見られるが、有機的な連携ができているとは言い難い。ここで、マーケティングＤＢには、口座取引データ、決算書データなどが含まれている。

例えば、公共事業の場合、自治体が、ある施工業者を落札業者として選定し、当該業者が、落札の連絡を受けると、下請け業者に対して、必要な資材等を発注するという流れが一般的である。落札業者は、受注後、施行をして納品まで済ませた後に、売上金を計上することができ、決算書上で売上の変化が生じる。従来は、金融機関の担当者は、売り上げを大きく伸ばした顧客法人の決算書を読んでから、融資の必要性があったことを知ることになっていた。

このような事情を改善するために、従来から、様々な態様で、営業を支援するためのシステムが提案されてきている。

例えば、特許文献１は、上司の助言を得るために、情報を所属店で適格に共有する旨を挙げている。

特開２０１４−１９１６２３号公開公報（特許第５４１６８５２号）

新人や経験年数の少ない営業担当者は、どのような事情（法人の情報の変化などの新たな法人の情報）が生じたときに、どのような顧客ニーズが生じるので、どのような行動をすべきという予測をすることができない。つまり、新人や経験年数の浅い担当者が、コンピュータから助言だけの支援を受けても、その意味が理解できなければ、何のための営業なのかを理解できず、結果として良い成果が得られない可能性がある。すなわち、助言の裏に隠された意味を知ることができて初めて自らの経験不足を補うことができ、営業経験が長い担当者と同程度の行動をとって良い成果が得られる可能性がでてくる。そのためには、助言の根拠となるような、事情に応じた過去の成功事例や失敗事例なども知る必要がある。

本発明の一態様によると、法人の新たな情報を検知して、新たなビジネスニーズなるような過去の事例に関する情報を抽出して、当該抽出された情報を提供することで、営業を支援する情報処理装置を提供することを目的のひとつとする。

本発明の一態様によると、
法人の情報を取得する手段と、
前記法人の新たな情報の影響を受ける可能性のある法人の一覧を抽出する手段と、
優先順位判定テーブルを基に、前記一覧から最も優先順位の高い法人を抽出する手段と、
前記最も優先順位の高い法人の属性情報を基に、事例データベースから過去の事例を抽出する手段と、
を備えることを特徴とする情報処理装置を提供する。

本発明の一態様によれば、法人の新たな情報を検知して、新たなビジネスニーズをとらえることにより、仕入れ販売や下請け等に関する取引先情報変化や資金移動が発生する前に予測することができる。

また、新たな法人の情報は、鮮度が高いので、従来よりも早く且つ価値のあるニーズを予測することができるようになる。

本発明の別の一態様によれば、過去の成功事例を通じて、発生しうるニーズ情報が予測できる。

本発明の更に別の一態様によれば、配信対象顧客の数を絞って法人情報を担当者に配信することも、新たな顧客を発見することができる。

本発明の他の目的、特徴及び利点は添付図面に関する以下の本発明の実施例の記載から明らかになるであろう。

本発明の一実施例による情報処理装置の概略の一例を示す図である。 本発明の一実施例による情報処理装置を利用したシステムの一例を示す図である。 本発明の一実施例によるデータベース生成に関する情報処理の概略の一例を示す図である。 本発明の一実施例による過去事例抽出に関する情報処理の概略の一例を示す図である。 本発明の別の実施例にＭＣＩＦ共同化システムの一例を示す 顧客ニーズの判定の情報処理の一例を示す 本発明の一実施例による優先順位判定テーブルである。 本発明の一実施例による法人番号情報のテーブルである。 本発明の一実施例による受注情報テーブルである。 本発明の一実施例による自行保有情報・非公開外部情報テーブルである。 本発明の一実施例による図７Ａから図７Ｄのテーブルで判定されたデータを整理したテーブルである。 本発明の一実施例による配信すべき過去事例を決定するためのテーブルである。 本発明の一実施例による過去事例判定テーブルを示す。 成功事例一覧表、失敗事例一覧表、他社事例一覧表を示す。 本実施例の有機的連携により構成されたテーブルの一例を示す。 法人抽出のための情報処理の一例を示す。

図１は、本発明の一実施例による情報処理装置１０００の概略の一例を示す図である。

本実施例の情報処理装置１０００は、画面表示部１１１０、入力部１１２０、法人情報取得部１１３０、法人一覧取得部１１４０、法人抽出部１１５０、過去事例検索部１１６０、ニーズ検索部１１７０、内部法人情報ＤＢ１２１０、外部法人情報ＤＢ１２２０、優先順位ＤＢ１２３０、判定テーブルＤＢ１２４０、過去事例ＤＢ１２５０、ニーズ事例ＤＢ１２６０、制御部１３１０、インターフェイス部１３２０から構成される。なお、本実施例において、ＤＢは、Ｄａｔａｂａｓｅ（データベース）を意味するが、物理的／仮想的にデータを記憶できる手段であれば、どのような態様の記憶手段でもよい。

画面表示部１１１０は、ユーザ等へ必要な情報をディスプレイなどの表示手段により提示する。

入力部１１２０は、ユーザによって入力されたデータ等を受信して、当該データを必要とする各ユニット（各部）へ送信する。入力部１１２０は、タッチパネルのような画面表示部１１１０の機能を兼ね備えてもよい。

外部法人情報取得部１１３０は、法人情報が掲載されている外部のホームページなどにアクセスして、落札に関する情報を取得する。

法人一覧取得部１１４０は、所定の条件下で該当する可能性のある法人の一覧を取得する。

法人抽出部１１５０は、法人の一覧から、最も該当性の高い法人を抽出する。

過去事例検索部１１６０は、落札情報などの過去の事例を検索する。
また、落札した法人、または当該落札した法人と関連する情報も検索する。

内部法人情報ＤＢ１２１０は、情報処理装置内部に備えられたＤＢであり、法人の現在または過去の属性情報や財務情報を記憶する。法人の属性情報とは、商号、住所、その他（業種、所在地、事業所数、従業員数、設立年数など）である。また、法人の財務情報とは、売上高、当期利益、流動資産、固定資産、借入金、資本金、キャッシュフロー、与信などである。また、法人の取引情報を記憶してもよい。

外部法人情報ＤＢ１２２０は、過去の外部情報を記憶する。ここで、外部情報とは、例えば、外部情報が落札情報の場合であれば、落札日、落札金額、工事場所、工事内容、契約者名、契約者住所、法人番号などである。

優先順位ＤＢ１２３０は、法人の一覧から、最も該当性の高い法人を抽出する際に、その判定基準となる優先順位を記憶する。

判定テーブルＤＢ１２４０は、必要な情報を判定するためのテーブルを記憶する。配信情報の判定テーブルの一例を図７Ａに示す。

過去事例ＤＢ１２５０は、過去の落札などの過去事例を、分類分けして記憶する。分類（ニーズ）の一例は、融資（運転資金、設備資金等）、預金・資産運用（預金、公共債、保険、投資信託等）、決済取引（総合振込、給与振込、外国送金等）、その他ソリューション取引（市場誘導業務（上場）、ビジネスマッチング、Ｍ＆Ａ、事業承継、職域取引、土地活用、人材紹介、ＶＣ投資などの資本政策、キャッシュレス導入支援、業務効率化に資するシステム導入支援などのデジタル化支援、ＥＳＧ投融資、ＳＤＧｓ達成に向けた取組みの支援）などである。分類分けは、事例の内容に記載さえたキーワードに基づいて自動的に行ってもよいし、手動でもよい。

制御部１３１０は、情報処理装置１０００内の各部を制御する。１つまたは複数のプロセッサから構成されてもよい。

インターフェイス部１３２０は、情報処理装置１０００の内外のデータを送受信する。

本実施例では、外部法人情報が落札情報である場合について説明する。

図２は、本発明の一実施例による情報処理装置１０００を利用した情報処理システム２０００の一例を示す図である。

情報処理システム２０００は、情報処理装置１０００（図１参照）と、落札情報掲載サイト２００と、法人情報ＤＢ３００と、顧客端末４００とがネットワーク５００を介して接続されている。

落札情報掲載サイト２００は、落札情報が電子的に掲載されているＷｅｂサイトなどである。

法人情報ＤＢ３００は、法人情報が記憶されているデータベースであり、情報処理装置１０００の外部に設置されている。ここで、法人情報とは、一般に公開されている法人情報と、一般には公開されていない法人情報がある。一般に公開されている法人情報とは、法人番号、商号、住所などである。一般には公開されていない法人情報とは、主要販売（取引）先、信用度、格付などの法人情報であり、これは、いわゆる有償データベースから取得できる情報である。

なお、法人情報ＤＢ３００は、本実施例の情報処理装置１０００の内部法人情報ＤＢ１２１０と、外部法人情報ＤＢ１２２０と対応関係にあるが、情報更新の頻度や情報取得方法が異なるので、両者の情報は同一ではない可能性がある。情報処理装置１０００は、情報の鮮度、信用度、更新頻度、優先順位などを考慮して、任意に法人情報ＤＢ３００から必要な情報を取得できるように構成されてもよい。

顧客端末４００は、顧客端末は、情報処理装置を有する金融機関の顧客が有している端末であり、いわゆる携帯電話、スマートフォン、パソコンなどである。

ネットワーク５００は、装置や端末などの間で信号を送受信できれば、どのような方式でもよい。

図３は、本発明の一実施例によるデータベース生成に関する情報処理の概略の一例を示す図である。

Ｓ３０１０では、過去の法人情報を取得する。ここで、過去の法人情報とは、ある法人の落札情報などが挙げられる。この他にも、例えば、支店を出した、社長が交代した等などの情報などでもよい。

Ｓ３０２０では、過去の自行保有情報を取得する。

Ｓ３０３０では、トリガとなる過去の法人情報と自行情報とを突き合わせる。

Ｓ３０４０では、パラメータや区分を取得する。

Ｓ３０５０では、過去の事例データを取得する。

Ｓ３０６０では、パラメータや区分と事例の対応表を生成する。対応表の一例については、例えば、図１１のテーブルを参照されたい。

図４は、本発明の一実施例による過去事例抽出に関する情報処理の概略の一例を示す図である。

Ｓ４０１０では、最新の法人情報を取得する。本実施例における最新の情報は、例えば、官公庁に掲示された落札情報である。落札情報には、落札した法人名（商号）だけが記載されている場合もあるし、落札した法人名に関する情報（法人番号、本店所在地など）もあわせて記載されている場合もある。

Ｓ４０２０では、最新の自行保有情報を取得する。本実施例における最新の自行保有情報は、過去の落札情報である。ここで、最新の自行保有情報は、既知の情報に基づいて取得する。例えば、落札した法人の法人名のみが既知の場合は、（正式名称、略称を含めて）当該法人名が一致する法人の全てをリストアップする。

Ｓ４０３０では、トリガとなる最新の法人情報と自行保有情報とを突き合わせる。自行情報と比較して、法人の最新情報の変化を確認する。当該法人の最新情報の変化があった場合とは、本実施例においては、新たな落札情報が追加された場合である。なお、自行保有情報との突き合わせについては、例えば、図７Ａの優先順位判定テーブルも参照されたい。

Ｓ４０４０では、パラメータや区分を取得する。パラメータや区分については、例えば、図９の過去事例判定の表も参照されたい。

Ｓ４０５０では、Ｓ３０６０で生成したパラメータ区分と事例の対応表に基づいて、生成済みの対応表に、今回のパラメータ区分を当てはめて、対応する過去事例データを抽出する。過去事例データについては、例えば、図１０の各事例一覧表をされたい。なお、抽出される過去事例データは、複数でもよく、例えば、成功事例と失敗事例とが混在してもよい。

Ｓ４０６０では、抽出された過去事例に関するデータを該当顧客に送信する。更に、抽出された過去事例を、新たな情報としてデータベースに追加して、当該過去事例に基づく実際の営業等の事例を更新（追加・修正・削除）してもよい。
更に、トリガとなるような新たな情報により、影響を受ける可能性のある法人の一覧を抽出する。ここで、「新たな情報」とは、法人の属性情報の変化（商号の変更、本店所在地の移転）でもよく、商取引上の情報（新規受注など）でもよく、決算情報（売上増、営業利益増など）でも、登記上の変更（法人の設立、合併、解散など）でもよい。また、「影響を受ける可能性」とは、新たな商取引が発生するという一次的な可能性でもよいし、当該商取引の発生によって、売上が上がる可能性があるという二次的な可能性でもよい。「影響を受ける可能性のある法人」とは、法人の名称（商号）から想定できる法人であり、例えば、トリガとなった法人自身でもよいし、トリガとなった法人と取引関係にある法人でもよいし、任意のデータベースに記憶されている法人でもよい。「法人の名称（商号）から想定できる法人」とは、特に、法人番号（および顧客番号）が特定できる法人であれば、当該特定できる法人のみであるが、法人番号が特定できない法人であれば、後述する優先順位テーブルにより抽出される法人（複数可）である。

取引の有無は、例えば、金融取引に関する取引履歴を参照することにより判定することができ、例えば、所定期間内に所定金額以上の取引があれば、取引があったと判定してもよい。
任意のデータベースに記憶されている法人を抽出する際には、複数のデータベースを参照してもよく、例えば、新たな情報の内容に基づいて、参照するデータベース（図示せず）を変えてもよい。例えば、住所等の法人の属性情報に変化があった場合と、新たな業務を受注（落札）したなどの（将来的な）取引関係に変化があった場合とでは、異なるデータベースを参照してもよい。

このように、最新の法人情報と自己保有情報の突き合わせることで、発生しうる参考事例情報を選定することで、営業支援に資する情報を得ることができる。

本来受注していない法人を誤って、自行保有情報と突き合わせてしまうと、自行に、複数口座を保有している場合は、取引実績のある方に情報配信をしたい。本実施例では、法人番号情報により、公共事業発注体（自治体）が属する都道府県およびその近隣地域において、重複のない唯一の商号においては、上記課題が発生する可能性が極めて低い。すなわち、唯一商号リストにある法人名について、受注情報と自己保有情報とを突き合わせる。なお、同一法人が複数口座を保有するケースについても、商流情報等を基にした優先順に従って、情報配信をする口座（顧客番号）を選定する。

類似の工事を過去にも行っていて、受注後にビジネスにつながった実績がある場合は、当該ビジネスの内容を「前回情報」として配信する。

類似の工事でない場合や、受注後にビジネスにつながった実績がない場合は、過去の他社事例を参考情報（成功事例）として配信する。

同一顧客が過去に類似の工事を行っていて、受注後にビジネス（融資など）につながった実績がある場合には、当該ビジネスの内容を「前回情報（成功事例）」として配信する。

同一顧客が過去に類似の工事を行っていて、受注後にビジネス（融資など）につながらなかった実績がある場合は、当該ビジネスの内容を「前回情報（失敗事例）」として配信する。

類似の工事で無い場合や、受注後にビジネスに繋がった実績がない場合は、過去の他社事例を参考情報として配信する。

所内外のデータを用いて作成したＥＢＭ情報（見込顧客リスト）に、過去の営業データ（提案内容）および顧客管理データ（成約内容）を用いて、具体的なアプローチ方法と顧客のニーズに関する、過去の成功事例と失敗事例とを付加する。

これは、当該顧客の過去実績でも、類似イベントが発生した他の顧客の過去実績でもよい。

さらに、今回の営業データ（提案内容）および顧客管理データ（成約内容）をＤＢに還元することで、次回のＥＢＭ情報への付加情報とすることができるようになる。

図７Ａは、本発明の一実施例による優先順位判定テーブルの一例である。法人番号が特定できる場合には、当該法人番号に基づいて、一意に法人を特定することができる。しかし、同一の商号を使用している法人は複数ある場合は、法人の商号だけでは実際の法人を特定することはできない。法人番号が特定できない場合には、後述する優先順位テーブル等を用いることにより、同一商号を有する法人の中から、該当性が一番高い法人を抽出することができる。

まず、外部情報と自行保有情報との突き合わせについて説明する。本実施例の優先順位判定テーブルは、法人番号情報と、当該法人番号と顧客番号との紐づけに関する情報とを基に優先順位が決定できるように構成されており、法人番号が不明で、紐づけがない場合には、自行取引または外部情報からの取引情報に基づいて、優先順位が決定できるように構成されている。図７Ａ内の数字は、優先順位が昇順に割り振られている。すなわち、「１」が最も優先順位が高い。一方で、法人情報番号が既知で顧客番号情報と紐付けられていれば、新たな情報を有している法人が一意に特定できるので、本実施例の優先順位判定テーブルを使用せずに、次の処理（例えば、過去事例検索）にすすんでよい。

本来受注していない法人を誤って自行保有情報との突き合わせをしてしまうことがある。自行に複数の口座を保有している場合は、取引実績のあるほうに情報配信をしたい。このような問題点も、本実施例の優先順位判定テーブルを用いることによって、解消することができる。

本実施例では、法人番号情報より、公共事業発注者（自治体）が属する都道府県よびその近隣地域において、重複のない唯一の商号においては、上記課題が発生する可能性が極めて低い。よって、唯一商号リストにある法人名について、受注情報と自行保有情報とを突き合わせる。

なお、同一法人が複数の口座を保有するケースについても、商流情報等を基にした優先順位に従って、情報配信する口座（顧客番号）を選定する。

図７Ｂは、法人番号情報のテーブルを示し、法人番号、商号、商号重複有無の項目から構成される。法人番号は、法人を特定する一意の番号であり、通し番号でも法人番号でもよい。商号は、法人の名称等である。商号重複有無は、他の法人番号と重複した商号があるか否かを示しており、例えば、図７Ｂにおいては、法人番号１と法人番号４の商号が同一であるので、両者の商号重複は「あり」になる。

図７Ｃは、受注情報テーブルの一例を示しており、受注者名とリピート有無の項目から構成される。受注者名は、商号（法人等の名称）であり、リピートは、過去に同一受注者が同規模の案件を受注しているかを示す。

図７Ｄは、自行保有情報・非公開外部情報テーブルの一例を示しており、顧客番号、商号、公金入金、自治体取引から構成される。顧客番号は、顧客を特定する一意の識別子である。商号は、法人の名称である。公金入金は、公金の入金実績が過去にあれば「あり」になる。自治体取引は、自治体取引の実績が過去にあれば「あり」になる。

図７Ｅは、図７Ａから図７Ｄのテーブルで判定されたデータを整理したテーブルであり、自行保有情報（商号）、顧客番号、受注情報、商号重複、公金入金、自治体取引、優先順位、配信、備考から構成される。配信は、配信実績があれば、配信の旨が記録される。備考は、任意に記載できる項目である。

図８は、配信すべき過去事例を決定するためのテーブルの一例を示す。本実施例において、配信する事例は、過去成功事例、過去失敗事例、過去他社事例である。判定の一例として、まず、自行取引があるか否かを確認する。自行取引がある場合は、過去に融資などの取引実績があるかを確認する。更に、過去に受注があったか（リピートありか）を確認する。リピートがある場合は、工事内容が類似しているかを確認する。例えば、自行取引あり、取引実績あり、リピートあり、工事内容類似の場合は、過去成功事例を配信する。また、自行取引あり、取引実績なし、リピートあり、工事内容類似の場合は、過去失敗事例および過去他社事例を配信する。

図９は、過去事例判定テーブルの一例を示す。

過去事例判定テーブルは、カテゴリ、パラメータ、区分から構成されており、過去の事例それぞれを評価するために使われる。

図９におけるカテゴリの一例は、受注判定、決算書情報、属性情報、自行口座情報などである。カテゴリ毎に、１つ以上のパラメータがある。例えば、受注判定のカテゴリには、リピート有無、受注金額、工事内容、工事場所などのパラメータがある。更に、各パラメータには、区分がある。区分は、ＹＥＳ／ＮＯのようなフラグによる評価と、レベル１から５のような数値による評価がある。例えば、受注判定のカテゴリにおける、リピート有無のパラメータでは、ある事例において、同規模の業務が受注している場合には、ＹＥＳのフラグをたてる。同規模であるか否かの判定は、例えば、事業者が同一（名称のゆらぎを考慮）であるか、受注金額が同程度（所定の範囲内の金額）であるかなど、少なくとも２つの要素によって判定されてもよい。また、受注金額のパラメータにおいては、例えば、受注金額が一千万円未満であればレベル１、１千万円以上５千万円未満であればレベル２、・・・などのような任意の閾値を設けて区分を判定する。

過去事例の判定例を図９の右欄に示す。ここで、ＹＥＳ／ＮＯは、それぞれ１／２に置き換えてもよい。ある事例に対する判定の並びに近い事例があれば、その近い事例が、ある事例に類似している事例であることがわかる。ここで、近い事例の判定方法は、種々の手法を用いてよいが、例えば、個々の要素の差異の合計が一番小さいものを選定してもよい。例えば、図９の受注判定のカテゴリにおいては、判定例が上から順番に「ＹＥＳ、１、３、４」になっている。判定したい事例が「ＮＯ、２、４、４」と「ＹＥＳ、１、３、１」だと仮定すると、「ＹＥＳ、１、３、１」の方が、個々の要素の一致する数が多いので、近い事例であると判定してもよい。これ以外の手法で判定してもよい。

図１０は、成功事例一覧表、失敗事例一覧表、他社事例一覧表を示す。

図１０（ａ）の成功事例一覧表は、事業区分コード、ニーズ、事例（成功事例）から構成される。事業区分コードは、ニーズと成功事例とを紐付けた識別子である。ニーズは、融資、下請け、土地活用、事業主計、外為などの予め決められたカテゴリに分類分けされた名称が記録されている。事例は、対応するニーズに対応する成功事例が入力されている。

図１０（ｂ）の失敗事例一覧表は、事業区分コード、ニーズ、事例（失敗事例）から構成される。事業区分コードは、ニーズと失敗事例とを紐付けた識別子である。ニーズは、融資、下請け、土地活用、事業主計、外為などの予め決められたカテゴリに分類分けされた名称が記録されている。事例は、対応するニーズに対応する失敗事例が入力されている。

図１０（ｃ）の他社事例一覧表は、事業区分コード、ニーズ、事例（他社事例）から構成される。事業区分コードは、ニーズと失敗事例とを紐付けた識別子である。ニーズは、融資、下請け、土地活用、事業主計、外為などの予め決められたカテゴリに分類分けされた名称が記録されている。事例は、対応するニーズに対応する他社（参考）事例が入力されている。

図１１は、本実施例の有機的連携により構成されたテーブルの一例を示す。

図１１（ａ）は、トリガ、顧客番号、事業区分コードから構成される。トリガは、本実施例の過去事例抽出の情報処理が開始するきっかけをつくった要因を示す。顧客番号は、過去事例を抽出する対象の法人等の法人を識別するための識別子であり、顧客番号以外にも、法人名や法人番号でもよい。事業区分コードは、ニーズと事例から構成せれる図１０に示すようなテーブルを参照している。

図１１（ｂ）は、図１１（ａ）の変形例であり、トリガ、顧客番号１、顧客番号２、ニーズ、事例から構成される。トリガは、本実施例の過去事例を抽出するための情報処理が開始するきっかけをつくった要因を示す。顧客番号１は、過去事例を抽出する対象の法人等の法人を識別するための識別子であり、顧客番号以外にも、法人名や法人番号でもよい。顧客番号２は、過去事例が抽出された法人と（取引や事業承継などの）事業上の関係があった法人を示す。もし、顧客番号１と事業上の関係があった法人が複数ある場合は、顧客番号２に加えて、顧客番号３、４・・・のように項目を追加してもよい。ニーズは、過去事例が抽出された法人のニーズを示している。事例は、事例データベースに記録されている成功事例、失敗事例、他社参考事例を示す。

本実施例では、複数の法人外部情報を用いた事例について説明する。採用情報である場合について説明する。なお、実施例１と重複する内容については適宜省略する。

例えば、求人専門のウェブサイトや、法人のウェブサイト内の採用のページにおいて、「新規事業」「新規事業開発責任者」などのキーワードがある場合、法人が、何らかの新規事業の立ち上げを計画している可能性がある。

また、早期審査請求制度を利用して特許権が取得されている案件や、商標出願の出願公開公報で、新規の商品や役務の区分で出願されている商標出願がなされている案件でも、何らかの新規事業の立ち上げを計画している可能性が考えられる。

なお、上述した実施例で使用した法人外部情報以外の様々な法人外部情報に適用可能である。例えば、特許公報、採用情報、有価証券報告書、コスモス商流情報、自治体（学校や病院を含む）が発行する名簿、取引先格付情報などである。

各実施例で示したブロック図は一例にすぎず、いわゆるコンピュータの五大装置（制御装置、演算装置、記憶装置、入力装置、出力装置）のハードウェア資源にソフトウェアを協働させることによって実現することも可能である。

別の実施例として、取引先相手方に情報配信するような装置を構成することができる。

例えば、過去の類似工事の際に、受注法人から資材仕入れ法人・下請け法人がわかるため、それら法人に対しても、今後商流が発生する可能性がある旨を情報配信できる。すなわち、情報鮮度が極めて高い。

同様にして、受注法人で働く従業員（給与振込情報から判定）への臨時賞与や追加雇用発生を推測することができるので、当該従業員に対しても、定期預金などの金融商品を紹介することができる。

更に別の実施例として、失注した情報を発信するような装置を構成することができる。

例えば、過去サイクル（半年ごと、毎年、隔年など）に同様の受注（随意契約を含む）している法人が、今回受注しなかった場合、資材仕入れ法人、下請け法人、従業員について、資金が滞る・給与が下がるなどの、業況が悪化する可能性を捉えることができる。本実施例においては、定期的にトリガが発生するような案件を、任意のデータベースにいれておき、所定の期間内に、案件が発生しなかったことをトリガとすることにより構成することができる。

更に別の実施例として、法人抽出のための情報処理の一例を図１２を参照して詳細に説明する。本情報処理を、例えば、Ｓ３０１０やＳ４０１０で示したような外部情報の取得で得られた法人を特定する精度を更に向上させることもできるし、Ｓ４０６０などで示したような、参考事例を顧客に配信することができる。

Ｓ１２０１０では、法人情報ＤＢ１２１０から法人別に現在の法人の属性情報を抽出する。なお、本実施例では、法人の属性情報を抽出したが、別の実施例として、決算情報などを抽出してもよい。

Ｓ１２０２０では、法人情報ＤＢ１２１０から法人別に過去の法人の属性情報を抽出する。ここで、過去の法人の属性情報とは、現在の法人の属性情報よりも以前に登録されている法人の属性情報を抽出している。ここで、以前の登録とは、所定期間前の登録でもよく、Ｓ１２０２０が過去に実施された時の登録でもよい。

Ｓ１２０３０では、法人別に、Ｓ１２０１０で抽出した現在の法人の属性情報と、Ｓ１２０２０で抽出した過去の法人の属性情報とを比較する。

Ｓ１２０４０では、Ｓ１２０３０で比較した結果、現在の法人の属性情報と過去の法人の属性情報とが異なる、すなわち属性情報に変化のあった法人を抽出する。例えば、法人名が変更になった法人でもよいし、本店所在地が変更になった法人でもよい。

この法人は自社と既に取引のある場合でもよく、まだ取引のない場合でもよい。取引のない場合は、Ｓ３０１０やＳ４０１０で示したような外部情報の取得で得られた法人名を特定する精度を更に向上させることもできる。

Ｓ１２０５０では、抽出した対象法人に関し、所定のところへ法人名等の情報を送信し、更に必要に応じて、例えば変化のあった法人の属性情報等や、Ｓ４０６０などで示したような、参考事例も送信する。

更に別の実施例として、顧客ニーズ判定のための情報処理の一例を図６を参照して詳細に説明する。本情報処理を、例えば、Ｓ３０２０やＳ４０２０で示したような自行保有情報の取得で得られた法人を特定する精度を更に向上させることもできるし、Ｓ４０６０などで示したような、参考事例を顧客に配信することができる。

Ｓ６０１０では、法人情報ＤＢ１２１０から、法人別に、過去にニーズが顕在化（たとえば「融資」の申込）した時点またはその直前の所定期間内での過去の法人の取引データ（たとえば預金口座の入出金履歴や残高の推移、振込の履歴など）を取得する。

Ｓ６０２０では、Ｓ６０３０で取得した複数の取引データのパターン（複数の取引データ（値）の組み合わせ）から（第１の）取引傾向データを算出する。算出した取引傾向データは、当該法人にニーズが顕在化した時点における当該法人の取引データ状況の傾向を示している。

Ｓ６０３０では、当該法人または別の法人における最新時点の取引データを取得する。また、取得する取引データは、Ｓ６０２０で取得した取引データと対応させて同じ種類の取引データを取得する。比較対象となる取引データの種類を一致させるためである。

Ｓ６０４０では、Ｓ６０３０で取得した取引データのパターン（取引データ（値）の組み合わせ）から（第２の）取引傾向データを算出する。算出した（第２の）取引傾向データは、当該法人または別の法人の最新時点における取引データ状況を示している。

Ｓ６０５０では、（第１の）取引傾向データと（第２の）取引傾向データとの関連判定処理を実行する。

過去にニーズ顕在化の経験がある法人については、当該法人自身における最新時点の取引データの（第２の）取引傾向データと、当該法人自身における過去のニーズ顕在化時における取引データの（第１の）取引傾向データとの関連度を算出し、算出した関連度に基づいて、関連の有無を判定する。なお、取引傾向データの関連の有無の判定は、Ｓ３０４０、Ｓ４０４０で示したように、取引傾向におけるパターン区分を作成して紐付けに用いてもよい。

過去にニーズ顕在化の経験がない法人については、当該法人における最新時点の取引データの（第２の）取引傾向データと、過去のニーズ顕在化の経験のある別の法人における取引データの（第１の）取引傾向データとの関連度を算出し、算出した関連度に基づいて、関連の有無を判定する。なお、取引傾向データの関連の有無の判定は、Ｓ３０４０、Ｓ４０４０で示したように、取引傾向におけるパターン区分を作成して紐付けに用いてもよい。

Ｓ６０７０では、抽出した対象法人に関し、所定のところへ法人名等の情報を送信し、更に必要に応じて、例えば顕在化が見込まれるニーズ情報や、Ｓ４０６０などで示したような、参考事例も送信する。

図５は、本発明の別の実施例にＭＣＩＦ共同化システムの一例を示す。なお、上述の実施例の図１、２と同じ参照符号は、同じ機能を有するものを指し示すので、説明を省略する。

本実施例のＭＣＩＦ共同化システムとは、特定の情報（ＭＣＩＦ）を複数の金融機関などで共同管理するためのシステムを意味する。ここで、ＭＣＩＦとは、Ｍａｒｋｅｔｉｎｇ Ｃｕｓｔｏｍｅｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｆｉｌｅの略称であり、マーケティング用の顧客情報のファイルを意味する。本実施例によれば、共有サーバを設けて、所定の情報を共有することにより、互いの情報を組み合わせて所望の情報を自動的に構築することができるようになる。

本実施例のＭＣＩＦ共同化システムは、各銀行の情報処理装置１０００と、コンソーシアムシステム５０００と、ネットワーク５００とから構成される。コンソーシアムシステム５０００は、各銀行から送信されたデータをデータベースに保存したり、各銀行の情報処理装置からの要求に応じて処理したデータを返したりする。

本実施例のＭＣＩＦ共同化システムのコンソーシアムシステム（サーバ）５０００は、管理サーバ４１０と、過去事例検索部１１６０と、複数の銀行用過去事例ＤＢ１２５０とを備える。ここで、複数の銀行用過去事例ＤＢ１２５０は、銀行毎に個別に用意されており、定期的または任意のタイミングで、銀行毎に設置されている情報処理装置からデータが送信されて、互いに同期をとるように構成されている。

管理サーバ４１０は、各金融機関の情報処理装置１０００とデータを送受信したり（インターフェイスの機能を有する）、コンソーシアムシステム５０００内部の各部を制御したりする。

本実施例で説明をした落札以外に適用可能であり、例えば、ネット情報をテキストマイニングできるものでも適用可能である。例えば、有価証券報告書や法人ＨＰ（会社概要）などの財務情報や、役員一覧などでもよい。また、特許公開情報などの新たな技術をもって、ビジネスを拡大する見込み（ビジネスマッチングなども含む）が予想されると想定されるものでもよい。

また、事例データベースについては、成功事例のほかに、失敗事例（望まれない事例（例えば、融資はよいが、従業員給与振込は別の金融機関が決めているなど））も合わせて付加する。

以上のように本発明の実施態様について説明したが、上述の説明に基づいて当業者にとって種々の代替例、修正又は変形が可能であり、本発明はその趣旨を逸脱しない範囲で前述の種々の代替例、修正又は変形を包含するものである。

情報処理装置１０００、画面表示部１１１０、入力部１１２０、公開法人情報取得部１１３０、法人一覧取得部１１４０、法人抽出部１１５０、過去事例検索部１１６０、内部法人情報ＤＢ１２１０、公開外部法人情報ＤＢ１２２０、優先順位ＤＢ１２３０、判定テーブルＤＢ１２４０、過去事例ＤＢ１２５０、制御部１３１０、インターフェイス部１３２０、情報処理システム２０００、コンソーシアムシステム５０００、
落札情報掲載サイト２００、法人情報ＤＢ３００、顧客端末４００、管理サーバ４１０、ネットワーク５００

Claims (7)

1. 法人の新たな情報を取得する手段と、
   前記法人の新たな情報により影響を受ける可能性のある法人の一覧を、法人の属性情報や財務情報を記憶する法人情報データベースから抽出する手段と、
   優先順位判定テーブルを基に、前記一覧から最も優先順位の高い法人を抽出する手段と、
   前記最も優先順位の高い法人の属性情報を基に、事例データベースから過去の事例を抽出する手段と、
   を備え、
   前記法人の新たな情報とは、前記法人の属性情報の変化および財務情報の変化の少なくとも１つであり、
   前記優先順位判定テーブルは、法人番号の情報と、当該法人番号と顧客番号との紐づけに関する情報とを基に優先順位が決定できるように構成されており、
   前記紐づけがない場合には、自行取引または外部情報からの取引情報に基づいて優先順位が決定できるように構成されていることを特徴とすることを特徴とする情報処理装置。
2. 前記法人の前記新たな情報の影響受ける可能性のある法人は、前記新たな情報により、取引の実績を基に、一次的な影響を受ける可能性のある法人または前記一次的可能性に基づく二次的な影響を受ける可能性のある法人であることが判定されることを特徴とする、請求項１に記載の情報処理装置。
3. 前記属性情報の変化および前記財務情報の変化の少なくとも１つとは、前記法人の属性情報の変化、商取引上の情報、決算情報、および登記上の変更の少なくとも１つであることを特徴とする、請求項１に記載の情報処理装置。
4. 前記最も優先順位の高い法人の属性情報に加えて、取引の実績、取引のリピートおよび取引内容の類似性を基に、事例データベースから過去の事例を検索することを特徴とする、請求項１に記載の情報処理装置。
5. 前記情報処理装置は、過去の事例および当該事例に基づく営業の結果を追加、修正および削除することにより、事例データベースを更新する手段を更に備えることを特徴とする、請求項１に記載の情報処理装置。
6. コンピュータを、
   法人の情報を取得する手段と、
   前記法人の新たな情報の影響を受ける可能性のある法人の一覧を、法人の属性情報や財務情報を記憶する法人情報データベースから抽出する手段と、
   優先順位判定テーブルを基に、前記一覧から最も優先順位の高い法人を抽出する手段と、
   前記最も優先順位の高い法人の属性情報を基に、事例データベースから過去の事例を検索する手段と、
   として機能させるためのプログラムであって、
   前記法人の新たな情報とは、前記法人の属性情報の変化および財務情報の変化の少なくとも１つであり、
   前記優先順位判定テーブルは、法人番号の情報と、当該法人番号と顧客番号との紐づけに関する情報とを基に優先順位が決定できるように構成されており、
   前記紐づけがない場合には、自行取引または外部情報からの取引情報に基づいて優先順位が決定できるように構成されていることを特徴とするプログラム。
7. 複数の情報処理装置とサーバとからなる情報処理システムにおいて、
   前記複数の情報処理装置のそれぞれは、
   法人の情報を取得する手段と、
   前記法人の新たな情報の影響を受ける可能性のある法人の一覧を、法人の属性情報や財務情報を記憶する法人情報データベースから抽出する手段と、
   優先順位判定テーブルを基に、前記一覧から最も優先順位の高い法人を抽出する手段と、
   を備え、
   前記サーバは、
   前記最も優先順位の高い法人の属性情報を基に、事例データベースから過去の事例を検索する手段と、
   を備え、
   前記法人の新たな情報とは、前記法人の属性情報の変化および財務情報の変化の少なくとも１つであり、
   前記優先順位判定テーブルは、法人番号の情報と、当該法人番号と顧客番号との紐づけに関する情報とを基に優先順位が決定できるように構成されており、
   前記紐づけがない場合には、自行取引または外部情報からの取引情報に基づいて優先順位が決定できるように構成されていることを特徴とすることを特徴とする、情報処理システム。