IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 株式会社帝国データバンクの特許一覧

特許7588989住所コード生成システム、企業構成情報管理システム及びプログラム
<>
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図1
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図2
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図3
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図4
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図5
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図6
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図7
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図8
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図9
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図10
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図11
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図12
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図13
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図14
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図15
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図16
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図17
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図18
  • 特許-住所コード生成システム、企業構成情報管理システム及びプログラム 図19
< >
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-11-15
(45)【発行日】2024-11-25
(54)【発明の名称】住所コード生成システム、企業構成情報管理システム及びプログラム
(51)【国際特許分類】
   G06F 16/21 20190101AFI20241118BHJP
   G06Q 50/10 20120101ALI20241118BHJP
【FI】
G06F16/21
G06Q50/10
【請求項の数】 10
(21)【出願番号】P 2020142383
(22)【出願日】2020-08-26
(65)【公開番号】P2021057021
(43)【公開日】2021-04-08
【審査請求日】2023-07-24
(31)【優先権主張番号】P 2019176583
(32)【優先日】2019-09-27
(33)【優先権主張国・地域又は機関】JP
【新規性喪失の例外の表示】特許法第30条第2項適用 出願人が提出した提案先リストに記載の通り、2019年(令和1年)12月19日~2020年(令和2年)8月24日の間における、複数の顧客に対する提案により公開
(73)【特許権者】
【識別番号】399009239
【氏名又は名称】株式会社帝国データバンク
(74)【代理人】
【識別番号】100096002
【弁理士】
【氏名又は名称】奥田 弘之
(74)【代理人】
【識別番号】100091650
【弁理士】
【氏名又は名称】奥田 規之
(72)【発明者】
【氏名】安江 直芳
【審査官】齊藤 貴孝
(56)【参考文献】
【文献】特開平11-316802(JP,A)
【文献】特開2017-102878(JP,A)
【文献】特許第6532620(JP,B1)
【文献】特開2002-329122(JP,A)
【文献】特開2016-151894(JP,A)
【文献】特開2003-173345(JP,A)
【文献】特開2008-065494(JP,A)
【文献】特開2015-109027(JP,A)
【文献】特開2016-099914(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
G06F 16/00-16/958
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
都道府県レベルから市区郡町村レベル、大字・通称レベル、字・丁目レベルまでの住所表記と、一定桁数の町字コードとの対応関係を定義した住所辞書情報を格納しておく記憶手段と、
住所を表す文字列が入力された際に、文字列中に含まれる建物名称部分を分離する手段と、
上記住所辞書情報を参照して、残された文字列の一部について町字コードを割り当てる手段と、
残された文字列中に街区番号に相当する数字が存在する場合にはこれを抽出し、所定の符号を必要数補うことによって予め設定された桁数の番地コードを生成すると共に、街区番号に相当する数字が存在しない場合には所定の符号を予め設定された桁数分並べた番地コードを生成する手段と、
残された文字列中に住居番号に相当する数字が存在する場合にはこれを抽出し、所定の符号を必要数補うことによって予め設定された桁数の号コードを生成すると共に、住居番号に相当する数字が存在しない場合には所定の符号を予め設定された桁数分並べた号コードを生成する手段と、
上記町字コード、番地コード及び号コードを連結して、桁数の揃った住所コードを生成する手段と、
当該住所コードを出力する手段と、
を備えたことを特徴とする住所コード生成システム。
【請求項2】
各企業の保有する事業所や不動産、施設よりなる、住所を伴う各種機能に関して、少なくともその住所、機能分類、機能名、企業名、企業コードを、機能コードに関連付けて格納しておく企業機能情報記憶手段と、
上記住所を、一定桁数の住所コードに変換する住所コード生成手段と、
上記住所コードに企業コードを付加した拠点コードを生成する手段と、
上記機能コード、拠点コード、機能分類、機能名、住所を備えた機能レイヤ情報を生成し、機能レイヤ情報記憶手段に格納する手段と、
都道府県レベルから市区郡町村レベル、大字・通称レベル、字・丁目レベルまでの住所表記と、一定桁数の町字コードとの対応関係を定義した住所辞書情報を格納しておく記憶手段とを備え、
上記住所コード生成手段は、住所を表す文字列中に含まれる建物名称部分を分離する処理と、
上記住所辞書情報を参照して、残された文字列の一部について町字コードを割り当てる処理と、
残された文字列中に街区番号に相当する数字が存在する場合にはこれを抽出し、所定の符号を必要数補うことによって予め設定された桁数の番地コードを生成すると共に、街区番号に相当する数字が存在しない場合には所定の符号を予め設定された桁数分並べた番地コードを生成する処理と、
残された文字列中に住居番号に相当する数字が存在する場合にはこれを抽出し、所定の符号を必要数補うことによって予め設定された桁数の号コードを生成すると共に、住居番号に相当する数字が存在しない場合には所定の符号を予め設定された桁数分並べた号コードを生成する処理と、
上記町字コード、番地コード及び号コードを連結して、桁数の揃った住所コードを生成する処理と、
を実行することを特徴とする企業構成情報管理システム。
【請求項3】
上記機能レイヤ情報記憶手段に格納された各機能レイヤ情報を、それぞれの拠点コードに基づいて集約させた拠点レイヤ情報を生成し、拠点レイヤ情報記憶手段に格納する手段を備え、
上記拠点レイヤ情報は、少なくとも拠点コード、企業コード、住所、機能分類を備えていることを特徴とする請求項2に記載の企業構成情報管理システム。
【請求項4】
個々の機能について、少なくとも有効か無効かの状態を表す情報を格納する機能状態情報記憶手段と、
定期的に上記機能状態情報記憶手段を参照し、新たに無効化された機能の存在を検知した場合には、対応する機能レイヤ情報について、機能の無効を表すフラグを設定すると共に、新たに有効化された機能の存在を検知した場合には、対応する機能レイヤ情報について、機能の有効を表すフラグを設定する手段と、
を備えたことを特徴とする請求項2または3に記載の企業構成情報管理システム。
【請求項5】
定期的に上記企業機能情報記憶手段を参照し、住所が変更された機能の存在を検知した場合には、従来の機能コード及び新しい住所に対応した住所コードを含む拠点コードを備え、機能の有効を表すフラグが設定された機能レイヤ情報を新設し、上記機能レイヤ情報記憶手段に追加する手段と、
従来の機能レイヤ情報について、機能の無効を表すフラグを設定すると共に、新設された上記機能レイヤ情報の拠点コードを付加する手段と、
を備えたことを特徴とする請求項4に記載の企業構成情報管理システム。
【請求項6】
ユーザの操作する端末装置から、特定の企業を指定する検索リクエストが送信された際に、当該企業の企業コードを含む機能レイヤ情報を上記機能レイヤ情報記憶手段から抽出する手段と、
各機能レイヤ情報を、拠点コードに基づいて整列させた検索結果リストを生成する手段と、
この検索結果リストを上記端末装置に送信する手段と、
を備えたことを特徴とする請求項2~5の何れかに記載の企業構成情報管理システム。
【請求項7】
ユーザの操作する端末装置から、特定の機能分類及び住所の少なくとも一部を指定する検索リクエストが送信された際に、該当の機能分類及び住所コードを備えた機能レイヤ情報を上記機能レイヤ情報記憶手段から抽出する手段と、
各機能レイヤ情報に係る企業名、機能名及び住所が列記されたリストを生成する手段と、
このリストを上記端末装置に送信する手段と、
を備えたことを特徴とする請求項2~6の何れかに記載の企業構成情報管理システム。
【請求項8】
複数の企業の特定情報と、各企業の各種属性情報との対応関係を定義した企業情報を格納しておく記憶手段と、
複数の取引先に関する複数の照合対象データを取得する手段と、
各照合対象データの特定の1または複数のデータ項目に格納された値と、上記企業情報の対応データ項目の値を比較し、各照合対象データに係る企業名を特定する手段と、
各照合対象データの特定の1または複数のデータ項目に格納された値と、上記機能レイヤ情報の対応データ項目の値を比較し、各照合対象データに係る機能名及び拠点コードを特定する手段と、
特定された企業名、機能名及び拠点コードを上記照合対象データに追加した照合結果データを生成する手段と、
各照合結果データを照合結果ファイルとして出力する手段と、
を備えたことを特徴とする請求項2~7に記載の企業構成情報管理システム。
【請求項9】
上記企業名の特定が、上記企業情報における合致すべきデータ項目の組合せパターンを複数定義した企業マッチパターンを参照することによりなされ、
複数の企業名が特定された場合には、1の企業名が上記照合結果データに追加され、残りの企業名は企業候補データとして別ファイルに出力され、
上記機能名の特定が、上記企業情報における合致すべきデータ項目の組合せパターンを複数定義した拠点マッチパターンを参照することによりなされ、
複数の機能名が特定された場合には、1の機能名が上記照合結果データに追加され、残りの機能名は拠点候補データとして別ファイルに出力されることを特徴とする請求項8に記載の企業構成情報管理システム。
【請求項10】
コンピュータを、請求項1~9の何れかに記載のシステムとして機能させることを特徴とするプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
この発明は、住所コード生成システム、企業構成情報管理システム及びプログラムに係り、特に、桁数の揃った住所コードに基づいて、多数の企業の多様な構成要素(機能)を、企業横断的かつ統一的に管理する技術に関する。
【背景技術】
【0002】
現在でも、各企業の企業名(商号)及び主たる住所(本店所在地)等については統一的な法人番号が付与され、データベースで管理されている。
例えば、以下の国税庁法人番号公表サイトにおいて特定の企業名を検索窓に入力すれば、当該企業の法人番号や本店所在地等の情報を入手することができる。
【文献】国税庁法人番号公表サイト インターネットURL:https://www.houjin-bangou.nta.go.jp/ 検索日:令和元年8月27日
【0003】
しかしながら、企業は本店以外にも各地に多数の営業所や工場、研究所、保養所等の施設や活動拠点を有しているのが通常であり、このような企業の実体(全体像)を構造的に認識することは困難な状況にあった。
もちろん、企業のホームページにアクセスし、会社組織図を参照することにより、企業の構成についてある程度把握することができるが、その内容はまちまちであり、全体としては大雑把な開示レベルにとどまることが多い。自社のホームページ上で組織図を公開していない企業もある。
【0004】
このような状況にあるため、例えば、横浜市内に研究開発部門を設けている企業に対して広く営業活動を展開したいと考えた場合に、対象となる企業の網羅的なリストを入手することは容易でなく、結局はインターネットの検索サイトでキーワード検索するか、職業別電話帳等からピックアップするしかなかった。
【0005】
また、あるオフィスビルに入居している企業の社名や事業所名をリストアップする必要がある場合にも、インターネットの検索サイトでビル名を入力し、ヒットした企業名や事業所名を個別に拾っていくか、目的のビルに出向いてフロアガイドをチェックするしかなかった。
【0006】
また、多数の企業の活動拠点に関する情報リストを入手できたとしても、それぞれの住所表記の方式や粒度、精度が揃っていないため、所在地をキーワードとした検索の信頼性が低いという問題もあった。
【0007】
さらに、各企業は自社の取引先に関するデータベースを保有しているが、取引先としての「企業名」が正確に入力されているとは限らず、企業名の代わりに事業所名や略称が入力されている場合も多く、データの照合処理(名寄処理)を行う際の障害となっていた。
【発明の開示】
【発明が解決しようとする課題】
【0008】
この発明は、このような現状を打開するために案出されたものであり、多数の企業に係る多様な構成要素(事業所、工場、不動産等)について、それぞれの所在地に基づいて構造的に定義し、企業横断的に検索可能とする技術の実現を目的としている。
また、企業に係るデータベースの照合処理を高精度で実現可能とする技術の実現を目的としている。
【課題を解決するための手段】
【0009】
上記の目的を達成するため、請求項1に記載した住所コード生成システムは、都道府県名レベルから字名・丁目名レベルまでの住所表記と、町字コードとの対応関係を定義した住所辞書情報を格納しておく記憶手段と、住所を表す文字列が入力された際に、上記住所辞書情報を参照して、文字列の一部について町字コードを割り当てる手段と、残された文字列から街区番号を抽出し、これに基づいて一定桁数の番地コードを生成する手段と、残された文字列から住居番号を抽出し、これに基づいて一定桁数の号コードを生成する手段と、上記町字コード、番地コード及び号コードを連結して、桁数の揃った住所コードを生成する手段と、当該住所コードを出力する手段と、を備えたことを特徴としている。
【0010】
また、請求項2に記載した企業構成情報管理システムは、各企業の保有する事業所や不動産、施設等、住所を伴う各種機能に関して、少なくともその住所、機能分類、機能名、企業名、企業コードを、機能コードに関連付けて格納しておく企業機能情報記憶手段と、上記機能の住所を、一定桁数の住所コードに変換する住所コード生成手段と、上記住所コードに企業コードを付加した拠点コードを生成する手段と、上記機能コード、拠点コード、機能分類、機能名、住所を備えた機能レイヤ情報を生成し、機能レイヤ情報記憶手段に格納する手段と、都道府県名レベルから字名・丁目名レベルまでの住所表記と、町字コードとの対応関係を定義した住所辞書情報を格納しておく記憶手段とを備え、上記住所コード生成手段は、上記住所辞書情報を参照して、上記機能の住所の一部について町字コードを割り当てる処理と、残された文字列から街区番号を抽出し、これに基づいて一定桁数の番地コードを生成する処理と、残された文字列から住居番号を抽出し、これに基づいて一定桁数の号コードを生成する処理と、上記町字コード、番地コード及び号コードを連結して、桁数の揃った住所コードを生成する処理と、を実行することを特徴としている。
【0011】
請求項3に記載した企業構成情報管理システムは、請求項2のシステムであって、さらに、上記機能レイヤ記憶手段に格納された各機能レイヤ情報を、それぞれの拠点コードに基づいて集約させた拠点レイヤ情報を生成し、拠点レイヤ情報記憶手段に格納する手段を備え、上記拠点レイヤ情報は、少なくとも拠点コード、企業コード、住所、当該拠点に属する機能分類を備えていることを特徴としている。
【0012】
請求項4に記載した企業構成情報管理システムは、請求項2または3のシステムであって、さらに、個々の機能について、少なくとも有効か無効かの状態を表す情報を格納する機能状態情報記憶手段と、定期的に上記機能状態情報記憶手段を参照し、新たに無効化された機能の存在を検知した場合には、対応する機能レイヤ情報について、機能の無効を表すフラグを設定すると共に、新たに有効化された機能の存在を検知した場合には、対応する機能レイヤ情報について、機能の有効を表すフラグを設定する手段と、を備えたことを特徴としている。
【0013】
請求項5に記載した企業構成情報管理システムは、請求項4のシステムであって、さらに、定期的に上記企業機能情報記憶手段を参照し、住所が変更された機能の存在を検知した場合には、従来の機能コード及び新しい住所に対応した住所コードを含む拠点コードを備え、機能の有効を表すフラグが設定された機能レイヤ情報を新設し、上記機能レイヤ情報記憶手段に追加する手段と、従来の機能レイヤ情報について、機能の無効を表すフラグを設定すると共に、新設された上記機能レイヤ情報の拠点コードを付加する手段と、を備えたことを特徴としている。
【0014】
請求項6に記載した企業構成情報管理システムは、請求項2~5のシステムであって、さらに、ユーザの操作する端末装置から、特定の企業を指定する検索リクエストが送信された際に、当該企業の企業コードを含む機能レイヤ情報を上記機能レイヤ情報記憶手段から抽出する手段と、各機能レイヤ情報を、拠点コードに基づいて整列させた検索結果リストを生成する手段と、この検索結果リストを上記端末装置に送信する手段と、を備えたことを特徴としている。
【0015】
請求項7に記載した企業構成情報管理システムは、請求項2~6のシステムであって、さらに、ユーザの操作する端末装置から、特定の機能分類及び住所の少なくとも一部を指定する検索リクエストが送信された際に、該当の機能分類及び住所コードを備えた機能レイヤ情報を上記機能レイヤ情報記憶手段から抽出する手段と、各機能レイヤ情報に係る企業名、機能名及び住所が列記されたリストを生成する手段と、このリストを上記端末装置に送信する手段と、を備えたことを特徴としている。
【0016】
請求項8に記載した企業構成情報管理システムは、請求項2~7のシステムであって、複数の企業の特定情報と、各企業の各種属性情報との対応関係を定義した企業情報を格納しておく記憶手段と、複数の取引先に関する複数の照合対象データを取得する手段と、各照合対象データの特定の1または複数のデータ項目に格納された値と、上記企業情報の対応データ項目の値を比較し、各照合対象データに係る企業名を特定する手段と、各照合対象データの特定の1または複数のデータ項目に格納された値と、上記機能レイヤ情報の対応データ項目の値を比較し、各照合対象データに係る機能名及び拠点コードを特定する手段と、特定された企業名、機能名及び拠点コードを上記照合対象データに追加した照合結果データを生成する手段と、各照合結果データを照合結果ファイルとして出力する手段と、を備えたことを特徴としている。
【0017】
請求項9に記載した企業構成情報管理システムは、請求項8のシステムであって、上記企業名の特定が、上記企業情報における合致すべきデータ項目の組合せパターンを複数定義した企業マッチパターンを参照することによりなされ、複数の企業名が特定された場合には、1の企業名が上記照合結果データに追加され、残りの企業名は企業候補データとして別ファイルに出力され、上記拠点名の特定が、上記企業構成情報における合致すべきデータ項目の組合せパターンを複数定義した拠点マッチパターンを参照することによりなされ、複数の拠点名が特定された場合には、1の拠点名が上記照合結果データに追加され、残りの拠点名は拠点候補データとして別ファイルに出力されることを特徴としている。
【0018】
請求項10に記載したプログラムは、コンピュータを、請求項1~7に記載したシステムとして機能させることを特徴としている。
【発明の効果】
【0019】
請求項1に記載した住所コード生成システムによれば、様々なバリエーションで表記された住所に対して、桁数の揃った住所コードを付与することができる。
これまで、住所表記の上位レベル(都道府県、市区郡町村、大字・通称、字・丁目)については、桁数の揃った統一的な町字コードに変換する仕組みが存在していたが、住所の下位レベル(番地、号以下)については表示方式が千差万別であることなどから、桁数の揃った統一的なコードを付与することがなされてこなかった。
これに対し、この発明の場合には、街区番号部分及び住居番号部分から数字を抽出すると共に、所定のルールに従ってこれらの桁を強制的に揃えることにより、下位レベル(番地、号レベル)の住所表示についてのコード化を実現している。
この結果、企業の有する各種機能を、コンピュータによる処理に適した「住所コード」を軸にして、統一的に管理することが可能となる。
住所の下位レベルまで桁数の揃った住所コードを各機能に付与することにより、表記方法が不統一な文字列ベースの住所に基づいて機能を検索する場合に比べて、処理の高精度化や効率化が実現できることは当然である。
なお、この住所コード生成システムは、企業構成情報の管理を効率化する目的で案出されたものではあるが、個人情報の管理目的にも適用可能である。
【0020】
請求項2に記載した企業構成情報管理システムの場合、企業の事業所(支社・支店、営業所、工場等)や保有不動産、施設等の構成要素を企業の「機能」とみなし、各機能に機能分類と桁数の揃った統一的な住所コードを割り振った機能レイヤ情報を生成する仕組みを備えているため、機能分類や住所コードを起点として各企業の個々の構成要素について容易にアクセスすることが可能となる。
【0021】
請求項3に記載した企業構成情報管理システムの場合、拠点コードを同じくする複数の機能レイヤ情報を予め拠点レイヤ情報として集約させる仕組みを備えているため、各企業の拠点の構成をより効率的に参照可能となる利点を備えている。
【0022】
請求項4及び5に記載した企業構成情報管理システムによれば、各機能の現状に応じて機能レイヤ情報をアップデートすることが可能となり、その信頼性を維持することができる。
【0023】
請求項6に記載した企業構成情報管理システムによれば、ユーザは特定の企業について、当該企業を構成している拠点の数や所在地域、各拠点に属する機能を網羅的に把握することができ、当該企業の全体構造を容易に把握することが可能となる。
【0024】
請求項7に記載した企業構成情報管理システムによれば、特定の地域に存する特定の機能分類を備えた企業の機能を企業横断的に抽出することが可能となり、営業活動等に際しての有力な資料を提供可能となる。
【0025】
請求項8に記載した企業構成情報管理システムによれば、取引先として企業名や事業所名が混在している照合対象データに対しても、企業名と拠点名及び拠点コードを正確に付与することができ、取引先を管理するデータベースの粒度を揃えることが可能となる。
【0026】
請求項9に記載した企業構成情報管理システムの場合、照合結果ファイルから漏れた候補企業名や候補機能名が別個の候補ファイルに格納される仕組みを備えているため、照合結果についてユーザ自ら確認ないし検証を行うことが可能となる。
【発明を実施するための最良の形態】
【0027】
図1は、この発明に係る企業構成情報管理システム10の全体構成を示すブロック図であり、企業構成情報生成部12と、検索処理部14と、メンテナンス処理部16と、企業基本情報記憶部18と、企業機能情報記憶部20と、住所辞書マスタ24と、企業構成情報記憶部26とを備えている。
【0028】
企業構成情報生成部12、検索処理部14及びメンテナンス処理部16は、コンピュータのCPUが、OS及び専用のアプリケーションプログラムに従って動作することにより、実現される。
また、企業基本情報記憶部18、企業機能情報記憶部20、住所辞書マスタ24及び企業構成情報記憶部26は、同コンピュータの記憶装置内に設けられている。
【0029】
図2は、企業基本情報記憶部18に格納された企業基本情報の構造を示すものであり、企業コード、法人番号、企業名(商号)、本店住所、代表者、電話番号、企業状態フラグ、企業状態コード、継承先企業コード等のデータ項目を備えている。
「企業状態フラグ」には、例えばアクティブ(活動中)またはインアクティブ(活動停止中)を示すフラグ(1または0)が設定される。設定されるフラグの種類は2つに限定されるものではなく、他の「不明」など他の状態を示すフラグを設定することもできる。
「企業状態コード」には、企業の継続、倒産、解散、休業、廃業、被合併(吸収合併による消滅)等の状態を識別する符号が設定される。
「継承先企業コード」には、当該企業が被合併された場合における、吸収した側の企業コードが格納される。
【0030】
図3は、企業機能情報記憶部20に格納された企業機能情報の構造を示すものであり、機能コード、機能分類(カテゴリ)、機能名、企業コード、企業名、郵便番号、住所、電話番号、機能状態フラグ、機能状態コード等のデータ項目を備えている。
「機能分類」には、企業が抱える各機能のカテゴリが設定されており、「機能名」には具体的な機能名が格納されている。
「機能状態フラグ」には、例えばアクティブ(有効)またはインアクティブ(無効)を示すフラグ(1または0)が設定される。設定されるフラグの種類は2つに限定されるものではなく、「不明」など他の状態を示すフラグを設定することもできる。
「機能状態コード」には、機能の継続、廃止、移転等の状態を識別する符号が設定される。
【0031】
図4に、機能分類及び機能名の一例を示す。
ここで企業の「機能」とは、名称を問わず企業の構成要素を意味しており、本社や本店、オフィス、営業所、工場、研究所、賃貸ビルなど、住所(所在地)に関連付けて把握され得る存在を広く含む概念である。
【0032】
企業機能情報は、様々な情報源から収集される。例えば、全国に派遣された多数の調査員が個別に企業を訪問し、取材を通じて集めた調査情報に基づいて生成される。あるいは、市販の電話帳データから必要な項目を抽出することにより、企業機能情報を生成することもできる。
企業機能情報の「機能コード」は、各情報源において採番されていたコードに対して、それぞれの情報源を識別するための符号を付加することによって形成されている。
【0033】
住所辞書マスタ24には、例えば日本国内の全ての地点について、住所の一部と町字(まちあざ)コードとの対応関係が多数格納されている。町字コードについては、後に説明する。
企業構成情報記憶部26には、企業構成情報生成部12によって生成された機能レイヤ情報28及び拠点レイヤ情報30が格納される(詳細は後述)。
【0034】
つぎに、図5のフローチャートに従い、機能レイヤ情報28及び拠点レイヤ情報30の生成手順について説明する。
まず企業構成情報生成部12は、企業機能情報記憶部20から企業機能情報を定期的(例えば毎月)に読み込み(S12)、新規に登録された各企業機能情報の「住所」に格納された文字列に基づいて、住所コードを生成する(S14)。
住所コードは、図6に示すように、11桁の町字コードと、6桁の番地コード及び6桁の号コードを繋げた、住所を一意に特定するために必要かつ十分な23桁の数字よりなる。
町字コードは、先頭2桁の都道府県コードと、これに続く3桁の市区郡町村コード、3桁の大字・通称コード、3桁の字・丁目コードに区分される。
【0035】
つぎに、図7のフローチャートに従い、住所コードの生成手順について説明する。
この場合、企業構成情報生成部12は企業機能情報から住所の文字列を取得した後(S30)、全角数字や漢数字を半角数字に変換したり、空白を削除したりする正規化処理を施す(S31)。
つぎに企業構成情報生成部12は、住所の文字列中に含まれる建物名称部分を分離する(S32)。
【0036】
例えば、図8(a)に示すように、「東京都港区南青山2丁目5番地20号 帝国マンション303号」という住所が与えられた場合、企業構成情報生成部12は「帝国マンション303号」の部分を分離する。
具体的には、図8(b)に示すように、まず(1)「5番地20号帝国マンション303号」という文字列から、「番地」や「番」、「号」、「-」といった住所表記に頻出する文字列を除去し、(2)「520帝国マンション303」とする。
つぎに、一般的に住所を構成する可能性の高い文字列(数字等)を「1」に置き換えると共に、それ以外の文字列を「2」に置き換え、(3)「1112222222111」とする。
つぎに企業構成情報生成部12は、最初に「2」が出現した箇所を建物名称の先頭と認定し、それ以降の文字列「帝国マンション303号」を分離する。
【0037】
なお、様々な建物名称のバリエーションを備えた建物名称辞書を別途用意しておき、企業構成情報生成部12がこれを参照することによって住所に含まれる建物名称を検出し、それ以降の記述を分離するように構成してもよい。
【0038】
つぎに企業構成情報生成部12は、残された住所の文字列を「MeCab」等の形態素解析ライブラリを用いて都道府県、市区郡町村、大字・通称、字・丁目単位に分解した後(S33)、住所辞書マスタ24を参照して、分解された各文字列に対応のコードを割り当てる(S34)。
【0039】
すなわち、住所辞書マスタ24には、都道府県レベルの住所表記と都道府県コードの対応関係、市区郡町村レベルの住所表記と市区郡町村コードの対応関係、大字・通称レベルの住所表記と大字・通称コードとの対応関係、字・丁目レベルの住所表記と字・丁目コードとの対応関係が多数定義されている。
このため企業構成情報生成部12は、住所辞書マスタ24に格納された住所表記と、形態素に分解された文字列の組合せをマッチングすることにより、対応の都道府県コード(2桁)、市区郡町村コード(3桁)、大字・通称コード(3桁)、字・丁目コード(3桁)を特定する。
【0040】
つぎに企業構成情報生成部12は、残された「5番地」の街区番号部分から「5」の数字を取り出すと共に、その前に5桁の「00000」を補うことにより、6桁の番地コード「000005」を生成する(S35)。
また、「20号」の住居番号部分から「20」の数字を取り出すと共に、その前に4桁の「0000」を補うことにより、6桁の号コード「000020」を生成する(S36)。
【0041】
企業構成情報生成部12は、街区番号及び住居番号部分が、例えば「5-20」、「5の20」、「5~20」、「5ノ20」のように常套的な簡略表記がなされている場合や、「5番地ト-20」のように余計な文字列が混入している場合であっても、これらから正しく「000005」の番地コードと「000020」の号コードを生成できる。
また、地域によっては街区番号や住居番号に相当する数字が存在しない住所もあるが、このような場合、企業構成情報生成部12は「000000」の番地コードと「000000」の号コードを生成する。
【0042】
企業構成情報生成部12は、上記の町字コード、番地コード及び号コードを連結することにより、最終的に「13103562454000005000020」の23桁の住所コードを生成する(S37)。
【0043】
桁数を揃えるために補う符号は「0」に限定されるものではなく、他の符号を用いてもよい。
また、番地コード及び号コードは、6桁に限定されるものではない。
なお、住所の文字列を入力すると、これに対応する町字コードを返すシステムはすでに存在しているため、これら既存のシステムを利用することにより、S31~S34の処理を省略することもできる。
あるいは、既存のシステムでは対応できずエラーが返ってきた場合に限り、S31~S34の処理を施して町字コードを割り振るように運用することもできる。
【0044】
つぎに企業構成情報生成部12は、23桁の住所コードに対して9桁の企業コードを付加することによって拠点コードを生成する(図5のS16)。
【0045】
つぎに企業構成情報生成部12は、企業基本情報記憶部18及び企業機能情報記憶部20を参照して当該企業に係る必要な情報を抽出し、これに上記拠点コードを関連付けることにより、機能レイヤ情報28を生成する(S18)。
【0046】
図9は、この機能レイヤ情報28を例示するものであり、機能コード、企業コード、継承先企業コード、法人番号、企業名、拠点コード、継承先拠点コード、住所、郵便番号、町字コード、機能分類、機能名、電話番号、機能収録年月、機能変更年月、企業状態フラグ、企業状態コード、機能状態フラグ、機能状態コードのデータ項目が設定されている。
【0047】
因みに、同図に示された3件のレコードは、それぞれ同じ企業コード、拠点コードを備えており、同一企業の同一拠点に存在する3つの異なる機能(工場、倉庫、社員寮)に関するものである。
これらの機能レイヤ情報28は、企業構成情報記憶部26に格納される(S20)。
【0048】
つぎに企業構成情報生成部12は、企業構成情報記憶部26に格納された各機能レイヤ情報28を拠点コードに基づいて集計することにより、拠点レイヤ情報30を生成し(S22)、企業構成情報記憶部26に格納する(S24)。
【0049】
図10は、この拠点レイヤ情報30を例示するものであり、拠点コード、企業コード、継承先企業コード、法人番号、企業名、住所、郵便番号、町字コード、機能名、機能分類、保有機能数、拠点収録年月、拠点変更年月等のデータ項目が設定されている。
「機能名」のデータ項目には、当該拠点に含まれる各機能の中の一つの機能名が代表的に格納される。また、「機能分類」に関しては、システム内に用意された全ての機能分類に対応したデータ項目が設けられており、当該拠点に存する機能分類について「1」が、存しない機能分類については「0」のフラグが設定される。
因みに、同図に示されたレコードは、図9に示された3件の機能レイヤ情報28に基づいて生成されたものであり、機能名には「工場」が記録されると共に、「生産施設」、「保管物流施設」、「法人福利施設」の各機能分類について「1」が設定され、保有機能数は「3」と記録されている。
【0050】
企業構成情報記憶部26に格納された機能レイヤ情報28及び拠点レイヤ情報30は、検索処理部14を介して多数のユーザによる検索の用に供される。
例えば、ユーザがPC等の検索端末32から特定の法人番号を入力すると、検索処理部14は機能レイヤ情報28または拠点レイヤ情報30を参照し、当該法人番号に関連付けられたレコードを抽出し、拠点コード単位に整列させた機能レイヤリストを検索端末32に返す。
この結果ユーザは、当該企業を構成している拠点の数や所在地域、各拠点に属する機能を網羅的に把握することが可能となる。
図11は、機能レイヤリストの閲覧によって認識できる企業の全体像を模式的に示したイメージ図であり、個々の企業を企業レイヤ、拠点レイヤ、機能レイヤの三層からなる階層構造で捉えることが可能となる。
【0051】
またユーザは、検索キーワードを工夫することにより、検索処理部14を介して様々な企業情報を引き出すことができる。
例えば、ある大規模なオフィスビルの住所を検索キーワードとして入力すると、検索処理部14はこの住所を上記と同様の手順で住所コードに変換した後、当該住所コードを備えた機能レイヤ情報28または拠点レイヤ情報30を企業構成情報記憶部26から抽出し、企業名及び機能名のリストを検索端末32に返す。
この結果ユーザは、当該オフィスビルに入居している企業名及びその機能名をまとめて入手することも可能となる。
【0052】
またユーザが、当該オフィスビルの住所及び機能分類としての「保有不動産」を検索条件として指定すると、検索処理部14は当該住所に対応した住所コードを含む拠点コードを備え、かつ機能分類として保有不動産を備えた機能レイヤ情報28または拠点レイヤ情報30を抽出し、その企業名を検索端末32に返す。
この結果ユーザは、当該オフィスビルのオーナー企業を特定することも可能となる。
【0053】
またユーザが、地域として「横浜市磯子区」を、機能分類として「開発研究施設」を検索条件として指定すると、検索処理部14は「横浜市磯子区」に対応する住所コードを備え、かつ「開発研究施設」の機能分類を備えた機能レイヤ情報28または拠点レイヤ情報30を抽出し、それぞれの企業名、機能名、住所、電話番号等が列記されたリストを検索端末32に返す。
この結果ユーザは、特定の地域における特定の機能分類を備えた企業をまとめて把握することができ、効率的な営業活動を展開することが可能となる。
【0054】
ところで、企業の状態は不変ではなく、倒産や解散、休業、廃業、被合併等の変化が絶えず生じ得る。また、各企業が保有している機能についても、廃止や売却、移転等の変化に晒されている。
このため、一旦登録された機能レイヤ情報28や拠点レイヤ情報30であっても、これらの変化に対応して適時アップデートして鮮度を維持していくことが不可欠となる。
【0055】
まず、倒産や解散、休業、廃業、被合併によって企業活動が停止した場合、オペレータは管理端末36を介して、企業基本情報の「企業状態フラグ」を「アクティブ(1)」から「インアクティブ(0)」に変更する。設定されるフラグの種類は2つに限定されるものではなく、「不明」など他の状態を示すフラグを設定することもできる。
被合併の場合にはさらに、「継承先企業コード」に吸収した側の企業コードが記録される。
もちろん、企業の本店住所や代表者等の一般的な項目について変更があった場合にも、該当項目の値について必要な修正が施される。
【0056】
企業の機能についても、拠点の移転や廃止等が生じた場合、オペレータは管理端末36を介して、企業機能情報の「機能状態フラグ」を例えば「アクティブ(1)」から「インアクティブ(0)」に変更する。設定されるフラグの種類は2つに限定されるものではなく、「不明」など他の状態を示すフラグを設定することもできる。
【0057】
これに対しメンテナンス処理部16は、定期的(例えば月に一度)に企業基本情報記憶部18及び企業機能情報記憶部20をチェックし、前回更新時から変化のあった企業基本情報及び企業機能情報に基づき、企業構成情報記憶部26に格納された機能レイヤ情報28に必要な修正を施す。
【0058】
例えば、企業基本情報をチェックした結果、ある企業が倒産した事実をメンテナンス処理部16が探知した場合、当該企業の企業コードを有する全ての機能レイヤ情報28について、「企業状態フラグ」がアクティブ(1)からインアクティブ(0)に変更されると共に、「企業状態コード」に倒産を意味するコードが挿入される。
【0059】
また、ある企業に被合併が生じた場合、当該企業の企業コードを有する全ての機能レイヤ情報28について、「企業状態フラグ」がアクティブ(1)からインアクティブ(0)に変更される。同時に、「企業状態コード」に被合併を意味するコードが挿入されると共に、「継承先企業コード」に吸収した側の企業コードが挿入される。
【0060】
また、ある企業のある機能(例えば倉庫)が廃止された場合、該当の機能レイヤ情報28の「機能状態フラグ」がアクティブ(1)からインアクティブ(0)に変更されると共に、「機能状態コード」に廃止を意味するコードが挿入される。
このようにして、機能レイヤ情報28に修正が加えられた以上、拠点レイヤ情報30にも対応の修正が施される。
例えば、機能の移転が生じた場合、拠点レイヤ情報の対応する機能分類について「0」がセットされる。
【0061】
つぎに、図12に従い、企業状態の表現パターンについて説明する。
まず、図12(a)に示すように、A社、B社、C社が独立して存在している場合、機能レイヤ情報28の継承先企業コードには各社の企業コードが格納されると共に、企業状態フラグにはアクティブ(1)が設定される。
【0062】
これに対し、図12(b)に示すように、D社がE社に吸収された場合、D社の継承先企業コードにはE社の企業コードが格納されると共に、D社の企業状態フラグはインアクティブ(0)に書き換えられる。
【0063】
また、図12(c)に示すように、G社及びH社が共にI社に吸収された場合には、G社及びH社の継承先企業コードにはI社の企業コードが格納されると共に、G社及びH社の企業状態フラグがインアクティブ(0)に書き換えられる。
【0064】
あるいは図12(d)に示すように、J社が活動を休止すると共に、L社がK社に吸収された場合には、J社の継承先企業コードがJ社の企業コードのまま、企業状態フラグがインアクティブ(0)に書き換えられる。同時に、L社の継承先企業コードにK社の企業コードが格納されると共に、その企業状態フラグがインアクティブ(0)に書き換えられる。
【0065】
つぎに、図13に従い、機能状態の変遷パターンについて説明する。
まず、図13(a)に示すように、N月においてある企業の機能αが拠点Xにおいて有効に存在していた場合、機能レイヤ情報28の拠点コード及び継承先拠点コードにそれぞれXの拠点コードが格納されると共に、機能状態フラグにはアクティブ(1)が設定されている。
【0066】
その後、N+1月(一月後)において、図13(b)に示すように、機能αが拠点Xから拠点Yに移転した場合、元のレコードの継承先拠点コードにYの拠点コードが格納されると共に、その機能状態フラグはインアクティブ(0)に書き換えられる。
同時に、機能コードαで、拠点Yの拠点コードを備えた新たなレコードが生成され、その機能状態にアクティブ(1)が設定される。
【0067】
さらにN+2月において、図13(c)に示すように、機能αが拠点Yから拠点Zに移転した場合、最初のレコード及び2番目のレコードの継承先拠点コードにZが格納されると共に、それぞれの機能状態フラグはインアクティブ(0)に書き換えられる。
同時に、拠点Zの拠点コードを備えた新たなレコードが生成され、その機能状態にアクティブ(1)が設定される。
【0068】
つぎに、N+3月において機能αが拠点ZからYに戻った場合、図13(d)に示すように、3件のレコードの継承先拠点コードにYの拠点コードが格納されると共に、最初のレコード及び最後のレコードの機能状態フラグがインアクティブ(0)に書き換えられる。
同時に、拠点Yの機能状態にアクティブ(1)が設定される。
【0069】
上記のように、機能に移転が生じた場合、元のレコードが上書されるのではなく、同じ機能コード及び新しい拠点コードを備えたレコードを追加していく方式を採用しているため、後で機能の変遷を辿ることが容易となる。
【0070】
上記においては、企業構成情報管理システム10の企業構成情報生成部12が、「住所コード生成システム」としての機能を担う例を示したが、この発明はこれに限定されるものではない。
すなわち、住所表記の上位レベル(都道府県、市区郡町村、大字・通称、字・丁目)に止まらず、住所の下位レベル(番地、号以下)まで含んだ住所全体について、桁数の揃った統一的なコードを付与することは、企業のみならず個人の情報管理にも有効に適用できる。
【0071】
企業構成情報記憶部26に格納された機能レイヤ情報28を照合処理(名寄せ処理)に応用することにより、照合の精度を向上させることができる。
図14は、企業構成情報管理システム10を照合処理に適用する際の実施形態を示すものであり、図1に示した検索処理部14の代わりに照合処理部40を設けると共に、辞書情報記憶部42及び照合結果記憶部44を追加した点に特徴を有する。
上記実施形態と共通する構成要素については同一の符号を用いると共に、重複の説明を省略する。
なお、検索処理部14と照合処理部40を併存させた形で企業構成情報管理システム10を構成することも当然に可能である。
【0072】
照合処理部40は、コンピュータのCPUが、OS及び専用のアプリケーションプログラムに従って動作することにより、実現される。
また、辞書情報記憶部42及び照合結果記憶部44は、同コンピュータの記憶装置内に設けられている。
辞書情報記憶部42には、企業コードとURLやメールドメインとの対応関係を定義した企業情報の辞書ファイルや、法人番号と証券コードとの対応関係を定義した企業情報の辞書ファイルなど、辞書ファイルが多数登録されている。
照合結果記憶部44には、照合処理部40によって生成された照合結果ファイル46、企業候補ファイル48及び拠点候補ファイル50が格納される(詳細は後述)。
【0073】
この照合処理に際し、ユーザは照合端末52を介して照合処理部40にアクセスし、照合条件を設定すると共に、照合対象データ(例えばCSVファイル)をアップロードする。
照合条件としては、例えば以下のものが挙げられる。
■照合対象データのクレンジング設定(特定文字列の置換、削除等の指定)
■マッチング精度(高/中/低等)の指定
■自社の業種の特定
■出力対象項目の指定
また、照合対象データとしては、例えば図15(a)に示すように、自社の財務部門が管理している顧客の債権管理データが該当する。
【0074】
以下、図16のフローチャートに従い、照合処理の手順について説明する。
まず照合処理部40は、ユーザが設定した照合条件を取得すると共に(S40)、ユーザがアップロードした照合対象データを取得する(S41)。
【0075】
つぎに照合処理部40は、照合対象データに対して所定のクレンジング処理を実行する(S42)。
すなわち、ユーザが事前に指定した文字列の置換や削除等が実行される。
また、システム独自のクレンジングロジックに則り、新旧漢字変換や郵便番号の表記統一、全角/半角変換等の処理が実行される。
【0076】
つぎに照合処理部40は、照合対象データに含まれる住所表記に基づいて、各照合対象データに町字コードを割り当てる(S43)。
【0077】
つぎに照合処理部40は、町字コードが割り当てられた各照合対象データの値と、企業構成情報、企業基本情報、辞書情報中の値を比較し、照合対象データの企業名を特定する(S44)。
この企業名の特定に際し、照合処理部40は企業マッチパターンを参照する。
【0078】
図17は、この「企業マッチパターン」を例示するものであり、複数のパターン名毎に、マッチすべきデータ項目の組合わせが定義されている。
例えば、ある照合対象データ中に法人番号が記載されており、これと同一の法人番号を備えた企業構成情報が企業構成情報記憶部26中に存在している場合には、「ML011」のマッチパターンに該当することとなり、当該企業構成情報の「企業名」が照合対象データの企業名と認定される。
この「ML011」のマッチパターンにはマッチング精度として「高」が設定されているため、法人番号の一致に基づく企業名の認定は、比較的高い精度であることを意味している。
【0079】
これに対し、ある照合対象データ中に代表者名のみが記載されており、これと同一の代表者名を備えた辞書データが辞書情報記憶部42中に存在している場合には、「ML901」のマッチパターンに該当することとなり、当該辞書データの「企業名」が照合対象データの企業名と認定される。
この「ML901」のマッチパターンにはマッチング精度として「低」が設定されているため、代表者の一致に基づく企業名の認定は、比較的低い精度であることを意味している。
図示は省略したが、他のマッチパターンに関しても、マッチすべき1または複数のデータ項目について○等が設定されている。
【0080】
つぎに照合処理部40は、各照合対象データの値と、企業構成情報中の値を比較し、照合対象データの拠点名を特定する(S45)。
因みに、ここで「拠点名」というのは上記した「機能名」に該当する。
この拠点名の特定に際し、照合処理部40は拠点マッチパターンを参照する。
【0081】
図18は、この「拠点マッチパターン」を例示するものであり、複数のマッチパターン毎に、マッチすべきデータ項目が定義されている。
例えば、ある照合対象データの町字コード及び電話番号に該当する町字コード及び電話番号を備えた企業構成情報が企業構成情報記憶部26中に存在している場合には、「KP040」のマッチパターンに該当することとなり、当該企業構成情報の「機能名」が当該照合対象データの「拠点名」として認定される。
図示は省略したが、他のマッチパターンに関しても、マッチすべき1または複数のデータ項目について○等が設定されている。
【0082】
つぎに照合処理部40は、企業名及び拠点名が特定された照合対象データ毎に、企業構成情報及び企業基本情報から必要なデータ項目の値を抽出し、これらの値を照合対象データに追加し、あるいはこれらの値で照合対象データの値を置換することによって照合結果ファイル46を生成し、照合結果記憶部44に格納する(S47)。
また照合処理部40は、照合結果ファイル46の生成に際し、派生データとしての企業候補ファイル48及び拠点候補ファイル50をも生成し、同じく照合結果記憶部44に格納する。
この結果ユーザは、照合端末52を介して照合処理部40にアクセスし、照合結果ファイル46や企業候補ファイル48、拠点候補ファイル50をダウンロードすることが可能となる。
【0083】
図15(b)は、照合結果ファイル46に含まれる照合結果データを例示するものであり、顧客コード、企業名、拠点名、拠点コード、拠点住所、拠点電話番号、担当者、債権額等のデータ項目を備えている。
元々の照合対象データでは、「取引先名」として「〇×△商事」、「〇×△」、「マルバツサンカク 札幌」のように企業名が不正確に表記されたり、企業名と支店名が混在した状態で表記されたりしていたとしても、それぞれに正しい企業名、拠点名、拠点コード等が付与されたことにより、3件の照合対象データが同一企業((株)〇×△商事)に係る異なる拠点(機能)についてのデータであったことが判然とする。
【0084】
照合結果データは、図15(b)に示されたデータ項目以外にも多数のデータ項目を備えている。
図19はその一部を例示するものであり、各照合対象データに対して一意に付与される行番号や、業種コード、企業マッチパターン、企業候補数、マッチング精度、拠点マッチパターン、拠点候補数等のデータ項目を備えている。
【0085】
ここで「企業候補数」とは、企業名を絞り込む過程で候補に挙がった企業の数を意味しており、これが「1」の場合には照合結果ファイル46に挙げられた企業名で確定であり、他に候補がなかったことを意味している。
これに対し、「企業候補数」に「2」以上の数値が記載されている場合には、マッチングの過程で企業マッチパターンに該当する他の企業名候補が存在したことを意味している。
【0086】
この場合ユーザは、企業候補ファイル48を参照し、他の企業名候補を個別に確認する。
企業候補ファイル48には、図示は省略したが、同じ行番号を備えたレコードの組が行番号順に格納されているため、ユーザは行番号を手掛かりに企業名候補同士を比較し、最も確からしい企業名を個別に特定することができる。
【0087】
同様に、「拠点候補数」とは、拠点名を絞り込む過程で候補に挙がった拠点数を意味しており、これが「1」の場合には照合結果ファイル46に挙げられた拠点名で確定であるが、ここに「2」以上の数値が記載されている場合には、マッチングの過程で拠点マッチパターンに該当する他の拠点名候補が存在したことを意味している。
【0088】
この場合もユーザは、拠点候補ファイル50を参照し、他の拠点名候補を個別に確認する。
拠点候補ファイル50には、図示は省略したが、同じ行番号を備えたレコードの組が行番号順に格納されているため、ユーザは行番号を手掛かりに拠点名候補同士を比較し、最も確からしい拠点名を個別に特定することができる。
【図面の簡単な説明】
【0089】
図1】この発明に係る企業構成情報管理システムの全体構成を示すブロック図である。
図2】企業基本情報のデータ構造を示す図である。
図3】企業機能情報のデータ構造を示す図である。
図4】機能分類と機能名との対応関係を例示する図である。
図5】機能レイヤ情報及び拠点レイヤ情報の生成手順を示すフローチャートである。
図6】拠点コードの構造を示す図である。
図7】住所コードを生成する手順を示すフローチャートである。
図8】住所コードを生成する手順を説明する模式図である。
図9】機能レイヤ情報のデータ構造を示す図である。
図10】拠点レイヤ情報のデータ構造を示す図である。
図11】機能レイヤリストの閲覧によって認識できる企業の全体像を模式的に示したイメージ図である。
図12】企業状態の表現パターンを説明する模式図である。
図13】機能状態の変遷パターンを説明する模式図である。
図14】この発明に係る企業構成情報管理システムを照合処理に適用する際の全体構成を示すブロック図である。
図15】照合対象データ及び照合結果データを例示する図である。
図16】照合処理の手順を示すフローチャートである。
図17】企業マッチパターンを例示する図である。
図18】拠点マッチパターンを例示する図である。
図19】照合結果ファイルのデータ項目を例示する図である。
【符号の説明】
【0090】
10 企業構成情報管理システム
12 企業構成情報生成部
14 検索処理部
16 メンテナンス処理部
18 企業基本情報記憶部
20 企業機能情報記憶部
24 住所辞書マスタ
26 企業構成情報記憶部
28 機能レイヤ情報
30 拠点レイヤ情報
32 検索端末
36 管理端末
40 照合処理部
42 辞書情報記憶部
44 照合結果記憶部
46 照合結果ファイル
48 企業候補ファイル
50 拠点候補ファイル
52 照合端末
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19