JP2016192019A - 情報処理システムおよびデータ構造 - Google Patents

情報処理システムおよびデータ構造 Download PDF

Info

Publication number
JP2016192019A
JP2016192019A JP2015070763A JP2015070763A JP2016192019A JP 2016192019 A JP2016192019 A JP 2016192019A JP 2015070763 A JP2015070763 A JP 2015070763A JP 2015070763 A JP2015070763 A JP 2015070763A JP 2016192019 A JP2016192019 A JP 2016192019A
Authority
JP
Japan
Prior art keywords
customer
name
address
household
data
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2015070763A
Other languages
English (en)
Inventor
淳志 樫村
Atsushi Kashimura
淳志 樫村
研二 岩田
Kenji Iwata
研二 岩田
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zenrin Co Ltd
Original Assignee
Zenrin Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zenrin Co Ltd filed Critical Zenrin Co Ltd
Priority to JP2015070763A priority Critical patent/JP2016192019A/ja
Publication of JP2016192019A publication Critical patent/JP2016192019A/ja
Pending legal-status Critical Current

Links

Images

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】顧客を、同居世帯の有無および同居世帯との関係性に応じて容易に分類する。【解決手段】情報処理システムは、顧客の氏または氏名からなる第1名称と顧客の住所を示す情報とを含む顧客データを記録する顧客データベースと、住所を示す情報と該住所に関連付けられた人物の氏または氏名からなる第2名称とを含む情報である居住者データを記録する居住者データベースと、顧客データベースに記録された顧客の住所を示す情報と居住者データベースに記録された顧客の住所を示す情報とから前記顧客データと居住者データとを対応づけ、対応づけられた該顧客データの第1名称と該居住者データの第2名称とにおける氏が一部において一致する場合、顧客は異なる人物と同居している同居世帯に属すると推定する同居人推定部と、を備える。【選択図】図1

Description

本発明は、複数の顧客を分類する技術に関する。
インターネット等のネットワークの発達に伴い、顧客と金融機関との間において、振込み手続き、投資信託の購入、各種ローンの申し込みといった金融取引がネットワークを介して広く行われている。このようなネットワークを介した金融取引を行う顧客に対して、住宅ローン、投資信託、および各種保険等の新たな金融商品の販売促進のために、顧客ごとの嗜好やニーズに合った情報を提供したいという要請がある。かかる要請に応じるため、特許文献1の情報提供システムは、不動産取得に関連する有益な情報を提供すると共に、かかる情報へのアクセスログを解析して顧客を分類し、分類された顧客のニーズに合った情報を電子メールで提供する。
特開2001−350906号広報
特許文献1の情報提供システムでは、あくまでも顧客本人のニーズに基づき顧客を分類しているに過ぎず、顧客と同じ住所に住む同居世帯の有無や、その同居世帯と顧客との関係性や、その同居世帯も含めた世帯全体での保有資産状況に基づき顧客を分類していない。このため、顧客と同居世帯との関係性に基づく潜在的なニーズ、例えば、高齢の親の世帯とその子供の世帯との2世帯が同居しているケースではかかる親子の関係から潜在する相続税対策のニーズに合った商品や、顧客および同居世帯の保有資産状況に合った商品の営業活動を行うことができないという問題があった。また、一般に、ネットワークを介した金融取引を行なう顧客数は膨大なため、同居世帯の有無、顧客と同居世帯との関係性、および保有資産状況などの特定を目的として各顧客を訪問することは、容易ではない。このため、顧客を、同居世帯の有無および同居世帯(同居人)との関係性に応じて容易に分類する技術が望まれていた。また、顧客を、同居世帯も含めた世帯全体での保有資産状況に応じて容易に分類する技術が望まれていた。
上述の課題は、金融取引に限らず、ネットワークを介して行なわれ得る任意の商取引において共通するものであった。また、従来の情報処理システムでは、上述の課題のほか、使い勝手の向上、処理速度の向上、小型化、低コスト化等が望まれていた。
本発明は、上述の課題の少なくとも一部を解決するためになされたものであり、以下の形態又は適用例として実現することが可能である。
(1)本発明の一形態によれば、情報処理システムが提供される。この情報処理システムは:顧客の氏または氏名からなる第1名称と、該顧客の住所を示す情報と、を含む情報である顧客データを記録する顧客データベースと;住所を示す情報と、該住所に関連付けられた人物の氏または氏名からなる第2名称と、を含む情報である居住者データを記録する居住者データベースと;前記顧客データベースに記録された前記顧客データにおける前記顧客の住所を示す情報と前記居住者データベースに記録された前記居住者データにおける前記人物の住所を示す情報とから前記顧客データと前記居住者データとを対応づけ、対応づけられた該顧客データの前記第1名称と該居住者データの前記第2名称とにおける前記氏が一部において一致する場合、前記顧客は異なる人物と同居している同居世帯に属すると推定する同居人推定部と;を備える。この形態の情報処理システムによれば、顧客データベースに記録されている顧客の住所を示す情報と居住者データにおける人物の住所を示す情報とから顧客データと居住者データとが対応付けられ、対応づけられた顧客データの第1名称と居住者データの第2名称とにおける氏が一部において一致する場合、顧客は異なる人物と同居している同居世帯に属すると推定されるので、各住所における同居世帯(同居人)の有無、および顧客と同居世帯(同居人)との関係性に応じて適切に顧客を分類できる。
(2)上記形態の情報処理システムにおいて、前記同居人推定部は、前記顧客データに対して前記居住者データの前記第2名称が複数対応付けられる場合、前記顧客は異なる人物と同居している同居世帯に属すると推定してもよい。この形態の情報処理システムによれば、顧客データに対して居住者データの第2名称が複数対応付けられる場合、顧客は異なる人物と同居している同居世帯に属すると推定される。顧客データに対して居住者データの第2名称が複数対応付けられる場合とは、すなわち、住所に顧客とは異なる他の人物が居住している等により関連付けられている可能性が高いため、本形態の情報処理システムによれば、顧客が同居世帯に属することを精度良く推定できる。
(3)上記形態の情報処理システムにおいて、前記顧客データベースは、前記顧客による商取引における取引額を、更に記録しており;前記居住者データベースは、前記住所に存在する建物の面積を示す情報を、更に記録しており;前記顧客データベースに記録された前記取引額が所定額以上である前記顧客と、前記取引額が前記所定額未満の前記顧客であって該顧客に対応づけられた前記居住者データの住所に存在する建物の面積が所定面積以上の顧客と、を裕福な世帯を表す裕福層世帯であると推定してもよい。取引額が所定額以上である顧客と、取引額が所定額未満の顧客であって該顧客に対応づけられた居住者データの住所に存在する建物の面積が所定面積以上の顧客と、は、裕福な世帯である可能性が高い。したがって、本形態の情報処理システムによれば、裕福層世帯を精度良く推定できる。
(4)上記形態の情報処理システムにおいて、前記同居人推定部および前記裕福層推定部の両方で推定された顧客をターゲット顧客として特定するターゲット顧客特定部を備えてもよい。この形態の情報処理システムによれば、同居世帯であり且つ裕福層世帯である世帯に属する顧客を、ターゲット顧客として精度良く特定できる。
(5)上記形態の情報処理システムにおいて、前記顧客データベースは、互いに異なる前記顧客に関する複数の前記顧客データをそれぞれ記録しており;前記居住者データベースは、複数の前記居住者データをそれぞれ記録しており;前記同居人推定部により同居世帯に属すると推定された複数の前記顧客のうち、前記第1名称と前記第2名称とが少なくとも一部において一致する顧客と、前記第1名称と前記第2名称とが全く一致しない顧客とを、互いに異なるグループに分類する顧客分類部を備えてもよい。この形態の情報処理システムによれば、同一住所における顧客と同居世帯(同居人)との関係を考慮して顧客を分類できる。すなわち、同一住所における顧客と同居世帯との関係が類似すると推定される顧客を同一のグループに分類し、かかる関係が類似しないと推定される顧客を互いに異なるグループに分類できる。第1名称と第2名称とが少なくとも一部において一致する顧客は、同じ氏の家族、例えば、親家族と長男家族といった複数世代の家族が同居している可能性が高いグループに分類できる。また、例えば、第1名称と第2名称とが全く一致しない顧客は、異なる氏の家族、例えば、親家族と娘婿家族とが同居している可能性が高いグループに分類できる。
(6)上記形態の情報処理システムにおいて、前記第1名称は、一人の人物の氏または氏名からなり;前記第2名称は、複数の人物の氏または氏名からなり;前記顧客データベースは、前記第2名称として、前記複数の人物の氏または氏名を、それぞれに予め設定されている優先順位が明らかになるように記録しており;前記顧客分類部は、前記第1名称と前記第2名称とが少なくとも一部において一致する顧客において、該第2名称を構成する前記複数の人物の氏または氏名のうち、該第1名称と少なくとも一部において一致する人物の氏または氏名に予め設定されている前記優先順位が互いに一致する顧客を同一のグループに分類し、該優先順位が互いに異なる顧客を互いに異なるグループに分類してもよい。この形態の情報処理システムによれば、第1名称と少なくとも一部において一致する人物の氏または氏名に予め設定されている優先順位が互いに一致する顧客を同一のグループに分類し、優先順位が互いに異なる顧客を互いに異なるグループに分類するので、当該住所に居住する人物のうちの優先順位が高い人物(例えば親)が当該住所における世帯主である可能性が高い顧客と、当該住所に居住する人物のうちの優先順位が低い人物(例えば子)が当該住所における世帯主である可能性が高い顧客とを、互いに異なるグループに分類できる。
(7)上記形態の情報処理システムにおいて、前記居住者データベースと前記顧客分類部による分類結果とに基づき、前記分類結果を示す情報を含む地図を示す地図データを生成する地図データ生成部と;前記地図データに基づき、前記地図を表示する表示部と;を更に備えてもよい。この形態の情報処理システムによれば、顧客の分類結果を示す情報を含む地図が表示されるので、地図上において、各顧客の世帯構成や、顧客と同居世帯(同居人)との関係等を、容易に特定できる。
(8)上記形態の情報処理システムにおいて、前記第2名称は、住所に存在する表札に記載されている氏または氏名であってもよい。この形態の情報処理システムによれば、第2名称は住所に存在する表札に記載されている氏または氏名であるので、当該住所に居住する人物の氏または氏名を正確に特定することができる。このため、顧客の分類を、精度良く行なうことができる。
(9)本発明の他の形態によれば、データ構造が提供される。このデータ構造は、顧客が異なる人物と同居している同居世帯に属するか否かを示す情報と、該顧客と該異なる人物との関係性と、のうちの少なくとも一方に応じた該顧客の分類結果を示す情報と、該顧客の氏または氏名と、を備え、前記分類結果は:前記顧客の氏または氏名からなる第1名称と、該顧客の住所を示す情報と、を含む情報である顧客データと;住所を示す情報と、該住所に関連付けられた人物の氏または氏名からなる第2名称と、を含む情報である居住者データと;の両方のデータに基づき、複数のグループのうちのいずれかのグループに分類されて得られた結果である。この形態のデータ構造によれば、顧客の氏または氏名からなる第1名称と該顧客の住所を示す情報とを含む情報である顧客データと、住所を示す情報と該住所に関連付けられた人物の氏または氏名からなる第2名称とを含む居住者データと、の両方のデータに基づき、複数のグループのうちのいずれかのグループに分類されて得られた分類結果と、顧客の氏または氏名と、を備えるので、かかるデータ構造を用いることにより、顧客について、同居世帯(同居人)の有無、および同居世帯(同居人)と顧客との関係性を容易に特定できる。
本発明は、情報処理システムおよびデータ構造以外の種々の形態で実現することも可能である。例えば、顧客管理システム、営業支援システム、地図表示システム、顧客分類装置、営業ターゲット抽出装置、顧客分類方法、データ構造の調整方法、および地図表示方法等の形態で実現することができる。
本発明の一実施形態としての情報処理システムの構成を示す説明図である。 図1に示す住宅地図属性データベース21aに設定されている情報の一例を示す説明図。 図1に示す金融機関顧客データベース122に設定されている情報の一例を示す説明図。 本実施形態の顧客分類処理の手順を示すフローチャート。 顧客資産判定処理の手順を示すフローチャート。 本実施形態における同居世帯判定処理の手順を示す第1のフローチャート。 本実施形態における同居世帯判定処理の手順を示す第2のフローチャート。 本実施形態における同居世帯判定処理の手順を示す第3のフローチャート。 本実施形態における同居世帯判定処理の手順を示す第4のフローチャート。 本実施形態における地図表示処理の手順を示すフローチャート。 ステップS320によりスマートフォン200に表示される地図の一例を示す説明図。 変形例における営業時期判定処理の手順を示すフローチャート。
A.実施形態:
A−1.システム構成:
図1は、本発明の一実施形態としての情報処理システムの構成を示す説明図である。本実施形態の情報処理システム10は、情報処理装置100と、端末装置としてのスマートフォン200とを備え、金融取引を行なう顧客を管理する。情報処理装置100とスマートフォン200とは、インターネットINTおよびインターネットINTに接続されている通信事業者のネットワークを介して互いに接続されている。なお、図1では、通信事業者のネットワークの一部である基地局BSを図示している。情報処理装置100は、金融機関のサーバ室等に設置され、スマートフォン200は、金融機関の社員、例えば営業担当者に保有される。情報処理装置100は、後述する顧客分類処理を実行して複数の顧客を分類し、また、後述する地図表示処理を実行して地図データを生成してスマートフォン200に送信する。詳細には後述するが、かかる地図データには、顧客の分類結果が反映されており、スマートフォン200は、かかる地図データに基づき地図250を表示する。したがって、金融機関の社員は、スマートフォン200に表示された地図250を参考にして、営業活動を行なうことができる。
情報処理装置100は、サーバ装置により構成されており、制御部110と、記憶部120と、通信部130とを備える。制御部110は、図示しないCPU(Central Processing Unit)、ROM(Read Only Memory)、RAM(Random Access Memory)を有しており、CPUは、ROMに記憶されている制御プログラムを実行することにより、顧客分類部111および地図データ生成部115として機能する。顧客分類部111は、顧客資産判定部112および同居世帯判定部113を備え、後述する顧客分類処理を実行する。顧客資産判定部112および同居世帯判定部113が実行する詳細な処理内容については、後述する顧客分類処理において説明する。なお、顧客資産判定部112は、請求項における裕福層推定部の下位概念に相当する。また、同居世帯判定部113は、請求項における同居人推定部の下位概念に相当する。地図データ生成部115は、スマートフォン200からの要求に応じて、地図データを生成してスマートフォン200に送信する。
記憶部120は、ハードディスクにより構成されており、住宅地図データベース121と、金融機関顧客データベース122と、路線価データベース123とを、予め記憶している。住宅地図データベース121は、住宅地図属性データベース21aと、地物データを格納する地物データベース21bを予め記憶している。地物データは、地物(道路や建物等)を描画するためのポリゴンデータであり、ポリゴンの頂点の座標に加えて、名称(地名や建物の名称等)や、色等の各種属性データを含む。なお、建物を描画するためのポリゴンデータには住宅地図属性データが関連付けられている。なお、ハードディスクに代えて、フラッシュメモリやEEPROMなど、他の任意の記憶装置により記憶部120を構成してもよい。
図2は、図1に示す住宅地図属性データベース21aに設定されている情報の一例を示す説明図である。住宅地図属性データベース21aには、番号、表札名称、住所名称、および建物面積のフィールドの合計4つのフィールドが設定されている。番号フィールドは、住宅地図属性データベース21aにおけるレコードの識別番号を示す。図2では、第1レコード(No.1)から第9レコード(No.9)までの合計9つのレコードが例示されている。なお、住宅地図属性データベース21aには、9つに限らず、2つ以上の任意の数のレコードが記録されていてもよい。また、住宅地図属性データベース21aには住所名称の代わりに、住所名称があらわす座標が設定されていてもよい。この場合、住所名称があらわす座標は例えば住所名称に対応する建物を描画するためのポリゴンデータの中心座標とする。
表札名称フィールドは、住所名称フィールドの示す住所に存在する表札に記載されている氏または氏名を示す。かかる情報は、例えば、予め各住所を訪問して取得することができる。表札に記載される名称は、その住所に居住する世帯構成や、表札作成者の意図により様々である。例えば、対象となる住所に居住する世帯が一世帯である場合には、かかる世帯の世帯主の氏や、かかる世帯の世帯主の氏名が記載される場合がある。その例としては、例えば、第1レコードの住所Aにおける「氏AAA」や、第2レコードの住所Bにおける「氏BBB 名bb1」などが該当する。また、対象となる住所に居住する世帯が2世帯である場合には、それぞれの世帯の世帯主の氏または氏名が併記される場合がある。その例としては、例えば、第3レコードの住所Cにおける「氏CCC 名cc1」と、第4レコードの住所Cにおける「氏CCC 名cc2」とが該当する。この第3,4レコードからも理解できるように、住宅地図属性データベース21aでは、表札に記載されている氏または氏名ごとに、レコードが登録されている。対象となる住所に居住する世帯が複数世帯である場合には、各レコードに同居人が存在することを示す同居人フラグが設定されていてもよい。なお、本実施形態では、同じ住所の表札に複数の氏または氏名が記載されている場合には、優先度がより高いと推定される氏または氏名のレコードを、より先の番号のレコードとして登録し、優先度がより低いと推定される氏または氏名のレコードを、より後の番号のレコードとして登録することにより、これら2つのレコード間の優先度の高低が明らかになるように記録している。例えば、住所Cに存在する表札に記載されている2つの名称「氏CCC 名cc1」および「氏CCC 名cc2」のうち、名称「氏CCC 名cc1」のレコードがより先の番号であるので、かかる名称が、優先度がより高いことを意味する。優先度の高い例と低い例としては、2つの氏または氏名が表札に記載されている場合、親の氏または氏名は優先度がより高く、子の氏または氏名は優先度がより低い、という例を挙げることができる。このような優先度は、例えば、表札における氏または氏名の文字の大きさ、記載位置、記載順序などにより推定される。具体的には、表札において、より大きな字で記載されている氏または氏名、より左端に記載されている氏または氏名、より上方に記載されている氏または氏名を、優先度が高いと特定してもよい。また、優先度を特定できる情報を外部から取得して優先度を特定してもよい。また、オペレータが優先度を設定してもよい。住宅地図属性データベース21aにおいて表札名称フィールドに設定されている氏または氏名は、請求項における第2名称の下位概念に相当する。なお、同一の住所に対応付けられている複数の氏または氏名も第2名称の下位概念に相当する。例えば、住所Cに対応付けられている「氏CCC 名cc1」および「氏CCC 名cc2」の合計2つの氏名は、請求項における第2名称の下位概念に相当する。
住所名称フィールドは、住所の名称、例えば、「●●県●●市●●町●丁目●番」などを示す。建物面積フィールドは、該当する住所に存在する建物の面積を示す。具体的には、建物の面積は各レコードに関連付けられた建物を描画するためのポリゴンの面積を示す。なお、住宅地図属性データには図示しない建物階数データを含むものとしてもよく、かかる場合建物を描画するためのポリゴンの面積に建物階数を乗じた値を建物面積としてもよい。なお、図2では、説明の便宜上、表札名称および住所名称として、模式的な名称を用いている。住宅地図属性データベース21aの各レコードは、管理者等により予め設定されている。なお、住宅地図属性データベース21aは、請求項における居住者データベースの下位概念に相当する。また、本実施形態において、建物面積は予め住宅地図属性データベース21aの建物面積フィールドに記憶されていたが、後述する顧客資産判定部112が地物データベース21bの建物を描画するためのポリゴンデータを参照し、建物面積を算出してもよい。
図3は、図1に示す金融機関顧客データベース122に設定されている情報の一例を示す説明図である。金融機関顧客データベース122には、番号、顧客氏名、住所名称、年齢、および取引額の合計5つのフィールドが設定されている。番号フィールドは、金融機関顧客データベース122におけるレコードの識別番号を示す。図3では、第1レコード(No.1)から第6レコード(No.6)までの合計6つのレコードが例示されている。なお、金融機関顧客データベース122には、6つに限らず、2つ以上の任意の数のレコードが記録されていてもよい。
顧客氏名フィールドは、金融機関の顧客の氏名を示す。住所名称フィールドは、顧客の住所の名称を示す。年齢フィールドは、顧客の年齢を示す。取引額フィールドは、顧客の金融取引の合計額を示す。情報処理装置100では、顧客が金融取引を新たに申し込んだ場合に、金融機関顧客データベース122に新たなレコードが追加される。このとき、取引の申し込みの際に顧客が金融機関に届け出た、顧客の氏名、住所、年齢が、新たに追加されたレコードに登録される。一般的には、同じ住所に住む世帯のうち一人のみが金融取引を行なうものと推定される。したがって、図3に示すように、同じ住所には、一種類の顧客氏名のみが登録され得る。また、取引の申し込みの際には、顧客の氏のみならず名前も求められる。したがって、図2に示す住宅地図属性データベース21aの表札名称フィールドとは異なり、金融機関顧客データベース122の顧客氏名フィールドには、氏と名との両方が登録される。取引額フィールドの値は、金融取引が実行されるたびに上書きされる。なお、顧客氏名フィールドに登録される氏名は、請求項における第1名称の下位概念に相当する。なお、住所名称フィールドは、顧客の住所の名称の代わりに顧客の住所名称があらわす座標が設定されていてもよい。この場合、顧客の住所名称があらわす座標は例えば金融機関が所有する地図データベースにて特定してもよい。
図1に示す通信部130は、インターネットINTと、基地局BSを含む図示しない通信事業者のネットワークを介して、スマートフォン200と通信を行なう。
スマートフォン200は、制御部210と、GPS(Global Positioning System)ユニット201と、無線通信部220と、通話制御部222と、表示部224と、マイク226と、スピーカ228とを備える。
制御部210は、CPU、EEPROM(Electrically Erasable Programmable ROM)およびRAMを備えたコンピュータとして構成されており、スマートフォン200全体を制御する。制御部210が有するCPUがEEPROMに記憶されている制御プログラムを実行することにより、メニュー制御部212、地図取得部214、および地図表示制御部216として機能する。メニュー制御部212は、表示部224に表示される各種操作メニューの表示制御を行なう。地図取得部214は、ユーザ操作に応じて情報処理装置100に対して地図データを要求し、また、取得した地図データを制御部210が有する図示しないEEPROMに格納する。地図表示制御部216は、取得された地図データに基づき、表示部224に地図250を表示させる。
GPSユニット201は、GPSを構成する人工衛星から受信する電波に基づき、スマートフォン200の現在位置を測位する。無線通信部220は、基地局BSとの間で無線によるデータ通信もしくは音声通信を行うための回路である。制御部210は、無線通信部220を制御することにより、基地局BSおよび図示しない交換機や伝送装置を含む通信事業者のネットワークを介して、情報処理装置100等のインターネットINT上の装置と通信する。通話制御部222は、音声通話のための着信や呼出、音声信号と電気信号の変換などを行う。表示部224は、液晶ディスプレイとこれを駆動する駆動回路とタッチパネル駆動部とを含む。制御部210は、表示部224を制御することで、地図、現在位置、各種メニュー画面等を液晶ディスプレイに表示させる。また、制御部210は、表示部224へのタッチによる入力情報を受信する。なお、表示部224に用いられている液晶ディスプレイを、有機ELディスプレイなど、種々の表示デバイスに代替してもよい。マイク226は、音声通信時やメニュー選択時においてユーザから発せられた音声を取得する。スピーカ228は、メニュー案内のための音声、および音声通信時における通話相手から受信した音声等を出力する。
上述した構成を有する情報処理システム10では、後述する顧客分類処理を実行することにより、金融機関の顧客を、同居世帯の有無、顧客と同居世帯との関係性、および同居世帯を含めた世帯全体での保有資産等に応じて顧客を容易に分類できる。
A−2.顧客分類処理:
図4は、本実施形態の顧客分類処理の手順を示すフローチャートである。顧客分類処理は、金融機関の複数の顧客を複数のグループに分類する処理であり、情報処理システム10の管理者等が情報処理装置100を操作して顧客分類のためのメニューを選択して実行すると、情報処理装置100において実行される。図4に示すように、顧客管理処理では、先ず顧客資産判定処理が実行され(ステップS10)、その後、同居世帯判定処理が実行される(ステップS20)。顧客資産判定処理とは、顧客およびその同居世帯の推定される保有資産の多少に基づき、顧客を分類する処理である。同居世帯判定処理は、同居世帯の有無および顧客と同居世帯との関係性に基づき、顧客を分類する処理である。
図5は、顧客資産判定処理の手順を示すフローチャートである。顧客資産判定部112は、金融機関顧客データベース122に記録されている顧客を、金融機関顧客データベース122における番号順に一人ずつ選択して対象顧客として設定し、かかる対象顧客について、金融機関顧客データベース122を参照して、取引額が所定額以上であるか否かを判定する(ステップS105)。取引額が所定額以上であると判定された場合(ステップS105:YES)、顧客資産判定部112は、対象顧客を裕福層顧客として抽出する(ステップS110)。取引額が所定額以上である場合、かかる顧客の保有資産が多いと推定される。そこで、この場合、対象顧客を裕福層であると推定して分類する。上述の「裕福層顧客として抽出する」とは、本実施形態では、裕福層顧客のリストとして、裕福層顧客として抽出された顧客を識別する情報、例えば、金融機関顧客データベース122における番号やかかる番号および顧客氏名等を記録したリストを生成して、記憶部120に格納することを意味する。なお、上述のリストに記録することに代えて、金融機関顧客データベース122に「裕福層フラグ」のフィールドを追加し、裕福層顧客と特定された顧客のレコードにおける裕福層フラグフィールドに、裕福層顧客であることを示すフラグを記録してもよい。ステップS110の実行後、顧客資産判定部112は、すべての顧客の分類が完了したか否かを判定する(ステップS130)。すべての顧客の分類が完了していないと判定されると(ステップS130:NO)、上述のステップS105に戻る。このとき、対象顧客を、次の順序の顧客に変更して、ステップS105以降の処理が実行される。これに対して、すべての顧客の分類が完了したと判定されると(ステップS130:YES)、顧客資産判定処理は終了する。
上述のステップS105において、対象顧客の取引額が所定額未満であると判定された場合(ステップS105:NO)、顧客資産判定部112は、対象顧客の居住する住所に存在する建物の面積が所定面積以上であるか否かを判定する(ステップS115)。具体的には、顧客資産判定部112は、先ず、金融機関顧客データベース122を参照して対象顧客の住所名称を特定し、かかる住所名称と同じ住所名称が登録されている住宅地図属性データベース21aのレコードを特定する。なお、顧客資産判定部112は、金融機関顧客データベース122を参照して対象顧客の座標を特定し、かかる座標に最も近い値の座標が登録されている住宅地図属性データベース21aのレコードを特定してもよい。次に、顧客資産判定部112は、特定された住宅地図属性データベース21aのレコードに記録されている建物面積を特定し、この建物面積が所定面積以上であるか否かを判定する。
建物面積が所定面積未満であると判定されると(ステップS115:NO)、顧客資産判定部112は、対象顧客を非裕福層顧客として抽出する(ステップS125)。取引額が所定額未満であり、建物面積が所定面積未満である場合、対象顧客の保有資産は少ないと推定される。そこで、この場合、対象顧客を非裕福層であると推定して分類する。「対象顧客を非裕福層顧客として抽出する」とは、上述した「対象顧客を裕福層顧客として抽出する」と同様な意味を有するので、その詳細な説明を省略する。ステップS125の実行後、上述のステップS130が実行される。
上述のステップS115において、対象顧客の居住する住所に存在する建物の面積が所定面積以上であると判定されると(ステップS115:YES)、顧客資産判定部112は、路線価データベース123を参照して、対象顧客の住所に関連する路線価を特定し、かかる路線価が所定額以上であるか否かを判定する(ステップS120)。「住所に関連する路線価」とは、当該住所に接する道路に対して設定されている路線価を意味する。路線価が所定額以上であると判定された場合(ステップS120:YES)、上述のステップS110が実行され、対象顧客は裕福層顧客として抽出される。取引額が所定額未満であっても、路線価が比較的高い地域に比較的広い建物を有する場合、かかる顧客の保有資産が多いと推定される。そこで、この場合、対象顧客を裕福層であると推定して分類する。これに対して、路線価が所定額未満であると判定された場合(ステップS120:NO)、上述のステップS125が実行され、対象顧客は非裕福層顧客として抽出される。取引額が所定額未満であり且つ比較的広い建物を有していても、その地域が、路線価が比較的安い地域である場合、対象顧客の保有資産は少ないと推定される。そこで、この場合、対象顧客を非裕福層であると推定して分類する。このように、顧客資産判定処理では、金融機関顧客データベース122に記録されている顧客の取引額のみならず、住宅地図属性データベース21aに記録されている建物面積や、路線価データベース123に記録されている路線価等に基づき顧客を分類するので、顧客およびその同居世帯の保有資産に応じて精度良く顧客を分類できる。
図6は、本実施形態における同居世帯判定処理の手順を示す第1のフローチャートである。図7は、本実施形態における同居世帯判定処理の手順を示す第2のフローチャートである。図8は、本実施形態における同居世帯判定処理の手順を示す第3のフローチャートである。図9は、本実施形態における同居世帯判定処理の手順を示す第4のフローチャートである。図6〜図9は、いずれも単一の同居世帯判定処理におけるフローチャートをそれぞれ部分的に示している。なお、図6〜図9では、理解を助けるために、表札名称を破線で囲んで示している。
図6に示すように、同居世帯判定部113は、金融機関顧客データベース122に記録されている顧客を、金融機関顧客データベース122における番号順に一人ずつ選択して対象顧客として設定し、かかる対象顧客について、上述の顧客資産判定処理において裕福層顧客として抽出されたか否かを判定する(ステップS200)。裕福層顧客として抽出されていない、すなわち、非裕福層顧客として抽出されたと判定された場合(ステップS200:NO)、同居世帯判定部113は、全ての顧客について、同居世帯判定処理による分類が完了したか否かを判定する(ステップS216)。全ての顧客について分類が完了したと判定されると(ステップS216:YES)、同居世帯判定処理は終了する。これに対して、全ての顧客について分類が完了していないと判定されると(ステップS216:NO)、上述のステップS200に戻る。このとき、対象顧客を、次の順序の顧客に変更して、ステップS200以降の処理が実行される。したがって、非裕福層顧客については、「非裕福層顧客」とのグループのみに分類され、さらに細かなサブグループには分類されない。
対象顧客が裕福層顧客として抽出されたと判定された場合(ステップS200:YES)、同居世帯判定部113は、住宅地図属性データベース21aおよび金融機関顧客データベース122を参照して、対象顧客の住所における世帯構成が、多世帯構成(2以上の世帯が同居している構成)であるか否かを判定する(ステップS202)。具体的には、同居世帯判定部113は、先ず、金融機関顧客データベース122を参照して対象顧客の住所名称を特定し、かかる住所名称と同じ住所名称が登録されている住宅地図属性データベース21aのレコードを特定する。次に、同居世帯判定部113は、特定された住宅地図属性データベース21aのレコード数が複数であるか否かを判定し、レコード数が複数であれば、対象顧客の住所における世帯構成が多世帯構成であると判定し、レコード数が1つであれば、対象顧客の住所における世帯構成が単世帯構成であると判定する。なお、住宅地図属性データベース21aに同居人フラグが設定されている構成においては、同居世帯判定部113は、特定されたレコードに設定されている同居人フラグに基づき、対象顧客の住所における世帯構成が多世帯構成であると判定してもよい。多世帯構成であれば、表札に各世帯の世帯主の氏または氏名が記載される可能性が高い。したがって、住宅地図属性データベース21aには同一の住所名称が設定され且つ互いに異なる表札名称が設定された複数のレコードが存在する可能性が高い。これに対して、単世帯構成であれば、表札に唯一の世帯主の氏または氏名が記載される可能性が高い。したがって、住宅地図属性データベース21aには同一の住所名称のレコードが1つのみ登録される可能性が高い。図2および図3の例では、住所Cに住む顧客、すなわち、図3における第3レコードの顧客と、住所Dに住む顧客、すなわち、図3における第4レコードの顧客と、住所Gに住む顧客、すなわち、図3における第6レコードの顧客とについては、ステップS202において多世帯構成であると判定される。これに対して、住所Aに住む顧客、すなわち、図3における第1レコードの顧客と、住所Bに住む顧客、すなわち、図3における第2レコードの顧客と、住所Fに住む顧客、すなわち、図3における第5レコードの顧客とについては、ステップS202において単世帯構成であると判定される。
同居世帯判定部113は、ステップS202において多世帯構成であると判定されると(ステップS202:YES)、対象顧客に対応する複数の表札名称の氏が互いに一致するか否かを判定する(ステップS204)。例えば、住所Cに住む顧客に対応する表札名称は、図2における第3レコードの表札名称である「氏CCC 名cc1」と、図2における第4レコードの表札名称である「氏CCC 名cc2」とが該当し、これら2つの表札名称の氏は互いに一致する。これに対して、例えば、住所Dに住む顧客に対応する表札名称は、図2における第5レコードの表札名称である「氏DDD」と、図2における第6レコードの表札名称である「氏EEE」とが該当し、これら2つの表札名称の氏は互いに一致しない。
同居世帯判定部113は、対象顧客に対応する複数の表札名称の氏が互いに一致すると判定されると(ステップS204:YES)、対象顧客の顧客氏名が対応する複数の表札名称のいずれかと一致するか否かを判定する(ステップS206)。住所Cに住む顧客の顧客氏名は、図3に示すように「氏CCC 名cc1」である。したがって、かかる顧客に対応する複数の表札名称である「氏CCC 名cc1」および「氏CCC 名cc2」のうちの前者と一致する。
同居世帯判定部113は、対象顧客の顧客氏名が対応する複数の表札名称のいずれかと一致すると判定されると(ステップS206:YES)、かかる顧客氏名が、複数の表札名称のうち、最も優先度の高い名称(以下、「優先名称」と呼ぶ)と一致するか否かを判定する(ステップS208)。同居世帯判定部113は、対象顧客の顧客氏名が優先名称と一致すると判定されると(ステップS208:YES)、対象顧客を第1類顧客に分類する(ステップS210)。この第1類顧客に分類される顧客は、「顧客が子世帯と同居している」「顧客は親である」「多世帯における世帯主は親である」といった特徴を有する可能性が高い。複数の表札名称の氏が一致することから親世帯と息子世帯の同居が想定され、親の氏または氏名であると推定される優先名称と顧客氏名とが一致するので、顧客が親である可能性が高い。また、顧客が親である可能性が高いことから、多世帯における世帯主は親である可能性が高い。なお、上述の「世帯主」とは、多世帯における各世帯の世帯主という意味ではなく、多世帯全体での経済的な中心人物といった意味を有する。上述のステップS210における「対象顧客を第1類顧客に分類する」とは、本実施形態では、第1類顧客のリストとして、第1類顧客に分類された顧客を識別する情報(例えば、金融機関顧客データベース122における番号や、かかる番号および顧客氏名など)を記録したリストを生成して、記憶部120に格納することを意味する。なお、後述するステップS212,S214,S228,S230,S232,S246,S248,S250,S266,S270における「分類する」も、上述したステップS210における「分類する」と同様な処理を意味する。ステップS210の実行後、上述のステップS216が実行される。
上述のステップS208において、対象顧客の顧客氏名が優先名称と一致しないと判定されると(ステップS208:NO)、同居世帯判定部113は、対象顧客を第2類顧客に分類する(ステップS212)。この第2類顧客に分類される顧客は、「顧客が実親世帯と同居している」「顧客は子である」「多世帯における世帯主は子である」といった特徴を有する可能性が高い。なお、この世帯主とは、ステップS210に関して上述した世帯主と同じ意味を有する。複数の表札名称の氏が一致することから親世帯と息子世帯の同居が想定され、息子の氏または氏名と推定される名称と顧客氏名とが一致するので、顧客が息子である可能性が高い。また、顧客が息子である可能性が高いことから、多世帯における世帯主は息子である可能性が高い。
上述のステップS206において、対象顧客の顧客氏名が対応する複数の表札名称のいずれとも一致しないと判定されると(ステップS206:NO)、同居世帯判定部113は、対象顧客を第3類顧客に分類する(ステップS214)。この第3類顧客に分類される顧客は、「顧客と同居する世帯有り」「3世帯以上の同居の可能性有り」といった特徴を有する可能性が高い。なお、上述した第1および第2類顧客とは異なり、顧客が親世帯と同居しているのか子世帯と同居しているのかは不明である。また、顧客が親であるのか子であるのかも不明である。また、多世帯における世帯主が親であるのか子であるのかも不明である。換言すると、第3類顧客は、これらの不明点を有するという特徴を有する。
上述のステップS204において、対象顧客に対応する複数の表札名称の氏が互いに一致しないと判定されると(ステップS204:NO)、同居世帯判定部113は、図7に示すように、表札名称として氏と名とをいずれも記載されている否かを判定する(ステップS222)。図6に示すようにステップS204においてNOと判定される表札名称としては、本実施形態では、「氏DDD」および「氏EEE」と、「氏GGG 名gg1」および「氏HHH 名hh1」とが該当する。これら2つの組み合わせのうち、「氏GGG 名gg1」および「氏HHH 名hh1」については、氏と名とが両方記載されている。これに対して、「氏DDD」および「氏EEE」については、氏のみが記載されている。
表札名称として氏と名とをいずれも記載されていると判定されると(ステップS222:YES)、同居世帯判定部113は、対象顧客の顧客氏名が対応する複数の表札名称のいずれかと一致するか否かを判定する(ステップS224)。このステップS224は、上述した図6におけるステップS206と同じ処理であるので、その詳細な説明を省略する。上述の「氏GGG 名gg1」および「氏HHH 名hh1」のうち、「氏GGG 名gg1」については、図3に示すように、住所Gに住む顧客の氏名と一致する。
同居世帯判定部113は、対象顧客の顧客氏名が対応する複数の表札名称のいずれかと一致すると判定されると(ステップS224:YES)、かかる顧客氏名が、優先名称と一致するか否かを判定する(ステップS226)。このステップS226は、上述した図6におけるステップS208と同じ処理であるので、その詳細な説明を省略する。顧客氏名「氏GGG 名gg1」は、上述の「氏GGG 名gg1」および「氏HHH 名hh1」のうち、優先名称である「氏GGG 名gg1」と一致する。
同居世帯判定部113は、対象顧客の顧客氏名が優先名称と一致すると判定されると(ステップS208:YES)、対象顧客を上述の第1類顧客に分類する(ステップS228)。このステップS228は、上述のステップS210と同様である。但し、ステップS228が実行される場合、上述のステップS210が実行される場合とは若干世帯構成が異なる可能性が高い。すなわち、ステップS228が実行される場合、顧客は親であり、娘世帯(氏が異なる世帯)と同居しており、多世帯における世帯主が親である可能性が高い。
上述のステップS226において、対象顧客の顧客氏名が優先名称と一致しないと判定されると(ステップS226:NO)、同居世帯判定部113は、対象顧客を第2類顧客に分類する(ステップS230)。このステップS230は、上述のステップS212と同様である。但し、ステップS230が実行される場合、上述のステップS212とは若干世帯構成が異なる可能性が高い。すなわち、ステップS230が実行される場合、顧客は、義理の親(妻の親)と同居しており、顧客は娘の夫であり、かかる娘の夫が世帯主である可能性が高い。
上述のステップS224において、対象顧客の顧客氏名が対応する複数の表札名称のいずれとも一致しないと判定されると(ステップS224:NO)、同居世帯判定部113は、対象顧客を第3類顧客に分類する(ステップS232)。このステップS232は、上述のステップS214と同じであるので、詳細な説明を省略する。上述のステップS228,S230,S232の実行後、ステップS234が実行される。このステップS234は、上述した図6に示すステップS216と同じであるので、その詳細な説明を省略する。
上述のステップS222において、表札名称として氏と名との両方ともを記載されていない、換言すると、表札名称として氏のみ記載されていると判定されると(ステップS222:NO)、同居世帯判定部113は、図8に示すように、同居世帯判定部113は、対象顧客の顧客氏名の氏が対応する複数の表札名称のいずれかの氏と一致するか否かを判定する(ステップS242)。このステップS242は、上述した図6におけるステップS206と同様な処理であるので、その詳細な説明を省略する。図7に示すように、ステップS222においてNOと判定される表札名称としては、本実施形態では、「氏DDD」および「氏EEE」が該当する。また、これら2つの「氏DDD」および「氏EEE」のうち、「氏EEE」については、住所Dに住む顧客の氏名「氏EEE 名ee1」のうちの「氏EEE」と一致する。
同居世帯判定部113は、対象顧客の顧客氏名の氏は、対応する複数の表札名称のいずれかの氏と一致すると判定されると(ステップS242:YES)、対象顧客の顧客氏名の氏が、優先名称の氏と一致するか否かを判定する(ステップS244)。このステップS244は、上述した図6におけるステップS208と同様の処理であるので、その詳細な説明を省略する。
同居世帯判定部113は、対象顧客の顧客氏名の氏が優先名称の氏と一致すると判定されると(ステップS244:YES)、対象顧客を上述の第1類顧客に分類する(ステップS246)。このステップS246は、上述のステップS210およびS228と同様である。但し、ステップS246が実行される場合、上述のステップS210およびS228が実行される場合とは若干世帯構成が異なる可能性が高い。すなわち、ステップS246が実行される場合、顧客が娘世帯と同居している可能性が高い。他方、顧客が親と娘(または娘の夫)とのいずれであるのか、また、多世帯における世帯主が親であるのか娘(または娘の夫)のいずれであるのかという点が不明であるという特徴を有する。
上述のステップS244において、対象顧客の顧客氏名の氏が優先名称の氏と一致しないと判定されると(ステップS244:NO)、同居世帯判定部113は、対象顧客を第2類顧客に分類する(ステップS248)。住所Dの顧客(金融機関顧客データベース122の第4レコードの顧客)の顧客氏名の氏「EEE」は、優先名称の氏である「DDD」とは異なる。このため、かかる顧客は、第2類顧客に分類される。ステップS248は、上述のステップS212およびS230と同様である。但し、ステップS248が実行される場合、上述のステップS212およびS230が実行される場合とは若干世帯構成が異なる可能性が高い。すなわち、ステップS248が実行される場合、顧客が義理の親の世帯と同居している可能性が高い。他方、顧客が親と娘(または娘の夫)とのいずれであるのか、また、多世帯における世帯主が親であるのか娘(または娘の夫)のいずれであるのかという点が不明であるという特徴を有する。
上述のステップS242において、対象顧客の顧客氏名の氏が対応する複数の表札名称の氏のいずれとも一致しないと判定されると(ステップS242:NO)、同居世帯判定部113は、対象顧客を第3類顧客に分類する(ステップS250)。このステップS250は、上述のステップS214およびS232と同様である。但し、ステップS250が実行される場合、上述のステップS214およびS232が実行される場合とは若干世帯構成が異なる可能性が高い。すなわち、「3世帯以上の同居の可能性有り」という特徴を有する一方、顧客と同居する世帯が有るか否かは不明であるという特徴を有する。上述のステップS246,S248,S250の実行後、ステップS252が実行される。このステップS252は、上述した図6に示すステップS216と同じであるので、その詳細な説明を省略する。
図6に示す上述のステップS202において、対象顧客の住所における世帯構成が、多世帯構成でないと判定されると(ステップS202:NO)、同居世帯判定部113は、図9に示すように、表札名称として氏と名とをいずれも記載されている否かを判定する(ステップS262)。このステップS262は、上述した図7に示すステップS222と同じであるので、その詳細な説明を省略する。なお、ステップS202においてNOと判定される表札名称としては、本実施形態では、「氏AAA」、「氏BBB 名bb1」、および「氏FFF」が該当する。
表札名称として氏と名とをいずれも記載されていると判定されると(ステップS262:YES)、同居世帯判定部113は、対象顧客の顧客氏名が表札名称と一致するか否かを判定する(ステップS264)。対象顧客の顧客氏名が表札名称と一致しないと判定されると(ステップS264:NO)、同居世帯判定部113は、対象顧客を第4類顧客に分類する(ステップS266)。この第4類顧客に分類される顧客は、「2世帯が同居している可能性が高い」という特徴を有する可能性が高い。表札に1つの名称のみが記載されているものの、かかる名称と顧客氏名とが一致しない場合には、多世帯構成であり、その多世帯における世帯主と、顧客氏名とが一致していない可能性がある。例えば、親世帯と子世帯との2世帯構成において、表札は親の氏名のままであるものの、親の高齢化に伴ってかかる2世帯における世帯主が親から子に代わり、子が顧客として登録されているケースなどが想定される。
上述のステップS264において、対象顧客の顧客氏名が表札名称と一致すると判定されると(ステップS264:YES)、同居世帯判定部113は、対象顧客を第5類顧客に分類する(ステップS270)。この第5類顧客に分類される顧客は、「同居世帯無し」という特徴を有する可能性が高い。
上述のステップS262において、表札名称として氏と名との両方ともを記載されていない、換言すると、表札名称として氏のみ記載されていると判定されると(ステップS262:NO)、同居世帯判定部113は、表札名称の氏と対象顧客の顧客氏名の氏とが一致するか否かを判定する(ステップS268)。表札名称の氏と対象顧客の顧客氏名の氏とが一致すると判定されると(ステップS268:YES)、上述のステップS270が実行され、対象顧客は、上述の第5類顧客に分類される。これに対して、表札名称の氏と対象顧客の顧客氏名の氏とが一致しないと判定されると(ステップS268:NO)、上述のステップS266が実行され、対象顧客は、上述の第4類顧客に分類される。例えば、表札名称「氏FFF」の氏「FFF」と、顧客氏名「氏XXX 名xx1」の氏「XXX」とは一致しないため、顧客氏名「氏XXX 名xx1」の顧客は、第4類顧客に分類される。上述のステップS266およびS270の実行後、ステップS272が実行される。このステップS272は、上述した図6に示すステップS216と同じであるので、その詳細な説明を省略する。
ここで、上述のステップS268における「一致」とは、完全一致を意味し、一部における一致を含まない。「一部における一致」とは、表札氏名の氏がアルファベットで記載されており、対象顧客の顧客氏名の氏が漢字で登録されている場合、および表札氏名の氏が旧字体で記載されており、対象顧客の顧客氏名の氏が常用漢字で登録されている場合を含む広い意味を有する。そして、このような「一部において一致」する場合には、上述のステップS268において、表札名称の氏と対象顧客の顧客氏名の氏とが一致しないと判定されるため、ステップS266が実行され、対象顧客は、上述の第4類顧客に分類される。
上述のように、同居世帯判定処理では、金融機関顧客データベース122に記録されている顧客の氏名のみならず、住宅地図属性データベース21aに記録されている表札名称に基づき顧客を分類するので、各顧客についての同居世帯の有無、および顧客と同居世帯との関係性に応じて顧客を分類できる。
A−3.地図表示処理:
図10は、本実施形態における地図表示処理の手順を示すフローチャートである。図10において、左側はスマートフォン200における処理手順を示し、右側は情報処理装置100における処理手順を示す。スマートフォン200では、電源がオンすると、地図表示処理が開始される。同様に、情報処理装置100では、電源がオンすると、地図表示処理が開始される。なお、地図表示処理が実行される前に、上述の顧客分類処理が既に実行されているものとする。
スマートフォン200において、メニュー制御部212は、ユーザによって地図表示メニューが選択されたか否かを判定する(ステップS305)。この地図表示メニューでは、ユーザは、顧客グループを指定する。顧客グループとは、上述した顧客分類処理により分類された顧客のグループを意味する。具体的には、上述した第1ないし第5類顧客の合計5つのグループと、非裕福層のグループとの合計6つのグループを意味する。例えば、スマートフォン200のユーザである金融機関の社員が、保険商品等の相続税対策の金融商品の営業活動を行なおうとする場合、第2類顧客グループを指定して地図表示メニューを選択してもよい。
地図表示メニューが選択されたと判定されると(ステップS305:YES)、地図取得部214は、GPSユニット201を制御して、スマートフォン200の現在位置の座標を特定する(ステップS310)。なお、上述のステップS305は、地図表示メニューが選択されるまで繰り返し実行される。
地図取得部214は、ステップS310で特定された現在位置の座標と、ステップS305において指定された顧客グループを示す識別子とを含む地図データ要求コマンドを、無線通信部220を制御して、情報処理装置100に送信する(ステップS315)。
情報処理装置100では、スマートフォン200から地図データ要求コマンドを受信するまで待機しており(ステップS405)。地図データ要求コマンドを受信すると(ステップS405:YES)、地図データ生成部115は、受信したコマンドに含まれている現在位置座標に基づき、現在位置を中心とする所定範囲の地図を示すデータを、記憶部120に記憶されている住宅地図データベース121に基づき生成する(ステップS410)。また、地図データ生成部115は、受信したコマンドに含まれている顧客グループ識別子に基づき、指定されたグループの顧客を特定し、かかる顧客の住所に所定の印を示す情報を地図上に重畳させ、表示用地図データを生成する。なお、地図上に重畳させる所定の印とはアイコンであってもよいし、建物を描画するためのポリゴンを所定の色で塗りつぶすことであってもよい。また、分類された顧客ごとに異なるアイコンを重畳させたり、異なる色で塗りつぶしてもよい。上述のように、顧客分類処理の結果、記憶部120には、各顧客グループに属する顧客の識別子が記録されたリストが記憶されている。したがって、かかる識別子に基づき、金融機関顧客データベース122を参照することにより、指定されたグループに属する顧客の住所を特定できる。
地図データ生成部115は、ステップS410で生成された表示用地図データを、通信部130を制御してスマートフォン200に送信する(ステップS415)。情報処理装置100では、ステップS415が完了すると、上述のステップS405に戻る。
スマートフォン200において、地図表示制御部216は、情報処理装置100から受信した表示用地図データに基づき、地図を表示部224に表示させる(ステップS320)。スマートフォン200では、ステップS320が完了すると、上述のステップS305に戻る。
図11は、ステップS320によりスマートフォン200に表示される地図の一例を示す説明図である。図11に示すように、スマートフォン200の表示部224には、地図250が表示されている。また、表示部224には、地図250にオーバーラップして、ユーザが指定した顧客グループの識別子である「第2類顧客」との文字列が表示されている。地図250には、道路に加えて、矩形の印260が表示されている。この印260は、第2類顧客の住所内の所定位置(例えば、該当する住所の中心位置)に表示されている。したがって、ユーザは、かかる地図を見ることにより、どの位置に営業活動のターゲットする第2類顧客が住んでいるかを容易に把握することができる。
以上説明した実施形態の情報処理システム10によれば、同居世帯判定処理が実行されることにより、同一住所に関連付けられている住宅地図属性データベース21aの表札名称および金融機関顧客データベース122の顧客氏名に基づいて顧客が分類されるので、同居世帯の有無および同居世帯と顧客との関係性に応じた適切なグループに顧客を分類できる。
また、顧客氏名と表札氏名とが一致する顧客と一致しない顧客とを、互いに異なるグループに分類するので、顧客と同居世帯との関係性が類似すると推定される複数の顧客を同一のグループに分類し、かかる関連性が互いに類似しないと推定される複数の顧客を互いに異なるグループに分類できる。また、顧客氏名の氏と表札氏名の氏とが一致する顧客と一致しない顧客とを、互いに異なるグループに分類するので、同様な効果を奏する。
また、顧客氏名と表札氏名とが一致する顧客のうち、顧客氏名と優先名称とが一致する顧客と一致しない顧客とを互いに異なるグループに分類するので、当該住所に居住する人物内において優先順位が高い人物(例えば親)が当該住所における世帯主である可能性が高い顧客同士を同じグループに分類できると共に、当該住所における世帯主が当該住所に居住する人物内において優先順位が低い人物(例えば子)が当該住所における世帯主である可能性が高い顧客同士を同じグループに分類できる。
また、以下に示す3つのケース(第1ないし第3ケース)において、対象顧客は対象顧客の世帯とは異なる世帯と同居している、或いは同居している可能性が高い顧客が属する顧客グループに分類される。第1のケースは、1つの顧客氏名に対して複数の表札氏名が対応付けられており、その複数の表札氏名のうちの1つの氏名の氏が、該当する顧客氏名の氏と一致する場合である。第2のケースは、顧客氏名の氏と表札名称とが一致する場合である。第3のケースは、顧客氏名の氏と表札名称の氏とが一部において一致する場合である。第1のケース例としては、例えば、顧客氏名「氏GGG 名gg1」と、かかる顧客氏名と住所名称が共通する表札名称である表札名称「氏GGG 名gg1」および「氏HHH 名hh1」のうちの一部である表札名称「氏GGG 名gg1」とが一致した場合が該当する。第2のケース例としては、例えば、顧客氏名「氏EEE 名ee1」と、かかる顧客氏名と住所名称が共通する表札名称である表札名称「氏DDD」および「氏EEE」とのうちの「氏EEE」が、顧客氏名「氏EEE 名ee1」の氏と一致する場合が該当する。第3のケース例としては、例えば、上述したステップS268において、表札名称の氏と対象顧客の顧客氏名の氏とが一部において一致するに過ぎず、完全一致していないために、表札名称の氏と対象顧客の顧客氏名の氏とが一致しないと判定された場合(ステップS268:NO)が該当する。上記3つのケースは、いずれも「顧客氏名と表札氏名とにおける氏が一部において一致する」ケースに相当する。これらのケースでは、対象顧客は対象顧客の世帯とは異なる世帯と同居している、或いは同居している可能性が高いため、顧客を適切な顧客グループに分類することができる。
また、住宅地図属性データベース21aにおいて住所名称に対応付けられている氏または氏名は、該当する住所に存在する表札に記載されている氏または氏名であるので、該当する住所に居住する人物内における代表人物(例えば、親)の氏または氏名を正確に特定することができる。このため、顧客の分類を、精度良く行なうことができる。
また、地図表示処理が実行されることにより、ユーザが指定したグループに属する顧客の住所に所定の印260が表示された地図250が、スマートフォン200において表示されるので、ユーザは、かかる地図を見ることにより、指定したグループに属する顧客がどこに住んでいるかを容易に把握することができる。また、現在位置と顧客との位置関係を容易に把握できる。したがって、かかるグループの顧客のみを対象とする営業活動を、容易に行なうことができる。
また、顧客資産判定処理により、取引額が所定額以上であり、保有資産が多いと推定される顧客と、取引額が少なく且つ建物面積が所定面積未満であり、保有資産が少ないと推定される顧客とを、互いに異なるグループに分類できる。したがって、かかる分類結果に基づき、例えば、裕福層顧客のみを対象とする販売促進等の営業活動を効率的に行なうことができる。
また、顧客資産判定処理により、取引額が所定額未満であり且つ建物面積が所定面積以上の顧客について、住所の路線価が所定額以上の顧客を裕福層顧客として抽出し、住所の路線価が所定額未満の顧客を非裕福層顧客として抽出するので、取引額だけでは分からない潜在的な裕福層の顧客を、裕福層顧客として精度良く抽出できると共に、建物面積だけでは分からない潜在的な非裕福層の顧客を、非裕福層顧客として精度良く抽出できる。
B.変形例:
B1.変形例1:
上記実施形態では、顧客分類処理が実行されて得られた分類結果は、地図表示処理において活用されていたが、本発明はこれに限定されない。顧客分類処理が実行されて得られた分類結果である各グループのリストを、リストデータとして記録媒体に出力したり、プリントアウトしたり、情報処理装置100に接続されている図示しない表示装置上に表示してもよい。このような構成においては、スマートフォン200を省略してもよい。また、分類結果に基づき、各顧客について営業時期を判定する処理を追加して実行してもよい。
図12は、変形例における営業時期判定処理の手順を示すフローチャートである。図12(a)は、第1類顧客について実行される営業時期判定処理の手順を示す。また、図12(b)は第2類顧客について実行される営業時期判定処理の手順を、図12(c)は第3類顧客について実行される営業時期判定処理の手順を、図12(d)は第4類顧客について実行される営業時期判定処理の手順を、それぞれ示す。図12に示す営業時期判定処理は、相続税対策の金融商品の営業活動の時期を判定する処理である。
図12(a)に示すように、第1類顧客として分類された各顧客について、顧客の年齢が70代以上であるか否かが判定される(ステップS305)。顧客の年齢が70代以上であると判定されると(ステップS305:YES)、営業時期は、Aランク時期と特定される(ステップS310)。これに対して、顧客の年齢が70代以上でないと判定されると(ステップS305:NO)、営業時期は、Eランク時期と特定される。
本変形例では、営業時期は、Aランク時期からEランク時期までの合計5つの時期に分けられており、Aランク時期は、現在を含む最も現在に近い時期的範囲に設定されている。Aランク時期に続き、Bランク時期、Cランク時期、Dランク時期、Eランク時期の順序で、より現在から遠い時期的範囲が予め設定されている。例えば、Aランク時期として現在から1年以内の時期が設定され、Bランク時期として1年後から5年後までの時期が設定され、Cランク時期として5年後から10年後までの時期が設定され、Dランク時期として10年後から15年後までの時期が設定され、Eランク時期として15年後以降の時期が設定されてもよい。
第1類顧客は、上述のように、「顧客が子世帯と同居している」「顧客は親である」「多世帯における世帯主は親である」といった特徴を有する可能性が高い。そして、顧客が70代以上である場合には、70代以上の親の世帯と、例えば、40代以上の子の世帯との同居が想定される。このため、相続税対策の金融商品のニーズが高い可能性が高いため、営業時期としてAランク時期が特定される。これに対して、顧客が70代以上でない場合、例えば、60代の親の世帯と、20代の子の世帯との同居が想定される。この場合、相続税対策の金融商品のニーズは、現時点では低いと思われるため、営業時期としてEランク時期が特定される。
図12(b)に示すように、第2類顧客として分類された各顧客について、顧客の年齢が40代以上であるか否かが判定される(ステップS405)。顧客の年齢が40代以上であると判定されると(ステップS405:YES)、営業時期は、Bランク時期と特定される(ステップS410)。これに対して、顧客の年齢が40代以上でないと判定されると(ステップS305:NO)、営業時期は、Eランク時期と特定される。
第2類顧客は、上述のように、「顧客が実親世帯と同居している」「顧客は子である」「多世帯における世帯主は子である」といった特徴を有する可能性が高い。そして、顧客が40代以上である場合には、40代以上の子の世帯と、70代以上の親の世帯との同居が想定される。このため、相続税対策の金融商品のニーズが高いと思われるため、営業時期としてBランク時期が特定される。これに対して、顧客が40代以上でない場合、例えば、20代の子の世帯と、60代の親の世帯との同居が想定される。この場合、相続税対策の金融商品のニーズは、現時点では低いと思われるため、営業時期としてEランク時期が特定される。
図12(c)に示すように、第3類顧客として分類された各顧客について、顧客の年齢が20〜30代であるか否かが判定される(ステップS505)。顧客の年齢が20〜30代であると判定されると(ステップS505:YES)、営業時期は、Cランク時期と特定される(ステップS510)。これに対して、顧客の年齢が20〜30代でないと判定されると(ステップS505:NO)、同居不明(営業時期不明)と特定される(ステップS515)。
第3類顧客は、上述のように、「顧客と同居する世帯有り」「3世帯以上の同居の可能性有り」といった特徴を有する可能性が高い。そして、顧客が20〜30代である場合には、20〜30代の子の世帯と、50〜60代の親の世帯との同居が想定される。このため、相続税対策の金融商品のニーズはそれほど高くないと思われるため、営業時期としてCランク時期が特定される。これに対して、顧客が20〜30代でない場合、例えば、同年代の複数世帯が何らかの理由で同居しており、親と子の同居でない可能性もある。このため、相続税対策の金融商品のニーズの高低は不明であり、同居不明と特定される。
図12(d)に示すように、第4類顧客として分類された各顧客について、顧客の年齢が70代以上であるか否かが判定される(ステップS605)。顧客の年齢が70代以上であると判定されると(ステップS605:YES)、同居不明(営業時期不明)と特定される(ステップS610)。これに対して、顧客の年齢が70代以上でないと判定されると(ステップS605:NO)、顧客の年齢が40〜60代であるか否かが判定される(ステップS615)。顧客の年齢が40〜60代であると判定されると(ステップS615:YES)、営業時期は、Dランク時期と特定される(ステップS620)。これに対して、顧客の年齢が40〜60代でないと判定されると(ステップS615:NO)、営業時期は、Eランク時期と特定される(ステップS625)。
第4類顧客は、上述のように、「2世帯が同居している可能性が高い」という特徴を有する可能性が高い。また、顧客が40〜60代である場合、顧客である40代の子の世帯と60代の親世帯との同居、或いは、20代の子の世帯と顧客である60代の親の世帯との同居が想定される。いずれの場合においても、相続税対策の金融商品のニーズはあまり高くないと想定されるため、営業時期としてDランク時期が特定される。これに対して、顧客が40〜60代でない場合、例えば、顧客である20代の子の世帯と、50代の親の世帯との同居が想定される。この場合、相続税対策の金融商品のニーズはかなり低いため、営業時期として、Eランク時期が特定される。
上述した営業時期判定処理により特定された営業時期は、例えば、記憶部120に記録されている各グループのリストの各顧客に対応付けて記録してもよい。また、営業時期(ランク時期)ごとの顧客リストを新たに生成して、記憶部120に記憶させてもよい。なお、上述した営業時期判定処理は、例えば、情報処理システム10の管理者が定期的に実行してもよく、また、金融機関の社員がスマートフォン200において該当するメニューを選択した場合に実行されてもよい。
B2.変形例2:
上述した実施形態の顧客資産判定処理では、取引額と、建物面積と、路線価とに基づき、顧客を裕福層顧客と非裕福層顧客とに分類していたが、本発明はこれに限定されない。例えば、対象顧客の住所が、既に裕福層顧客として抽出された顧客の住所から所定距離以内であり、且つ、対象顧客の建物面積が所定面積以上である顧客を、取引額および路線価に関わらずに裕福層顧客として抽出してもよい。裕福層顧客の近隣に住み且つ比較的広い建物に住む顧客は、所有資産が高い可能性が高いからである。また、路線価に基づく分類、すなわち、顧客資産判定処理のステップS120を省略してもよい。この構成では、ステップS115において、建物面積が所定面積以上であると判定された場合に(ステップS115:YES)、ステップS110を実行して対象顧客を裕福層顧客として抽出し、建物面積が所定面積未満であると判定された場合に、ステップS125を実行して対象顧客を非裕福層顧客として抽出してもよい。また、この構成では、路線価データベース123を省略できる。同様に、建物面積に基づく分類、すなわち、顧客資産判定処理のステップS115を省略してもよい。この構成では、ステップS105において、対象顧客の取引額が所定額未満であると判定された場合(ステップS105:NO)、ステップS210を実行して、路線価に基づく分類を行なってもよい。この構成では、住宅地図属性データベース21aにおいて、建物面積フィールドを省略できる。なお、住宅地図属性データベース21aにおいて、番号フィールドを省略してもよい。
B3.変形例3:
住宅地図属性データベース21aにおいて登録されている氏または氏名は、該当する住所に存在する表札に記載されている氏または氏名であったが、本発明は、これに限定されない。例えば、各住所を訪問して対面調査して得られた住人の氏または氏名が登録されてもよい。また、例えば、住宅地図属性データベース21aとは異なるデータベースとして、各住所とその住所に居住する人物の氏または氏名とが対応付けられたデータベースが存在すれば、かかるデータベースに登録されている氏または氏名を、住宅地図属性データベース21aの表札名称フィールドに関連付けてもよい。また、例えば住宅地図属性データベース21aとは異なるデータベースに登録された氏または氏名を住宅地図属性データベース21aに付加して登録してもよい。住所に関連付けられている人物の氏または氏名を、住宅地図属性データベース21aに登録してもよい。
また、住宅地図属性データベース21aには、住所を特定する情報として、住所名称が登録されていたが、住所名称に代えて、住所に存在する敷地の中心位置の座標など、住所を示す任意の情報を用いてもよい。同様に、金融機関顧客データベース122においても、住所名称に代えて、住所を示す任意の情報を用いてもよい。
また、住宅地図属性データベース21aにおいて、建物面積に代えて、または、建物面積に加えて、該当する住所に存在する敷地の面積が登録されてもよい。この構成においては、顧客資産判定処理において、建物面積に代えて、または、建物面積に加えて、敷地面積を、対象顧客の分類に用いてもよい。具体的には、例えば、敷地面積が所定面積以上である場合には裕福層顧客として抽出し、所定面積未満である場合には非裕福層顧客として抽出してもよい。
B4.変形例4:
金融機関顧客データベース122において登録されている顧客氏名は、顧客の氏と名との両方であったが、氏のみが登録されてもよい。この構成においても、互いに氏が異なる複数の世帯が同居しているケースにおいては、顧客の年齢を参酌して顧客を分類できる。例えば、顧客が20代であれば、20代の子世帯と50代の親世帯とが同居しており、子が顧客であり且つ同居世帯全体での世帯主であるものとして、第2類顧客に分類してもよい。なお、金融機関顧客データベース122において、番号、年齢、および取引額の各フィールドを省略してもよい。
B5.変形例5:
実施形態では、住宅地図属性データベース21aにおいて、同じ住所の表札に複数の氏または氏名が記載されている場合には、優先度がより高いと推定される氏または氏名のレコードを、より先の番号のレコードとして登録し、優先度がより低いと推定される氏または氏名のレコードを、より後の番号のレコードとして登録することにより、これら2つのレコード間の優先度の高低が明らかになるように記録していたが、本発明はこれに限定されない。例えば、住宅地図属性データベース21aに優先度フィールドを追加して、かかるフィールドに、優先度を示す情報(例えば、高、中、低等)を登録することにより、複数のレコード間の優先度の高低が明らかになるように記録してもよい。また、例えば、住宅地図属性データベース21aとは別に、複数のレコード間の優先度を記録したリストを記憶部120に記憶させておき、同居世帯判定処理のステップS208,S226,S244において、かかるリストを参照して判定を行なってもよい。また、例えば、過去からの住宅地図属性データの経年変化に基づき、親世代および子世代を推定してもよい。具体的には、毎年ないし複数年に一度、表札の調査が行われ、その結果が住宅地図データベース121に反映される構成とし、住宅地図データベース121に記録された氏名に40年間変化がなければ、当該氏名は親世代と推定してもよい。また、40年間変化のない氏名と同一の住所に、5年前に別の氏名が記録された場合、この別の氏名は子世代と推定してもよい。
B6.変形例6:
顧客分類処理において、顧客資産判定処理と同居世帯判定処理の実行順序を反対にしてもよい。すなわち、先ず同居世帯判定処理を実行して各顧客を第1〜第5類顧客に分類し、次に、各グループごとに顧客資産判定処理を実行して、非裕福層顧客として抽出された顧客については、新たに設けた非裕福層顧客グループに分類してもよい。また、顧客分類処理において、顧客資産判定処理と同居世帯判定処理とのうちいずれか一方を省略してもよい。また、実施形態では、顧客資産判定処理と同居世帯判定処理とは連続して実行されていたが、それぞれ異なるタイミングで実行されてもよい。
B7.変形例7:
実施形態では、顧客分類処理は、情報処理システム10の管理者等が情報処理装置100を操作して顧客分類のためのメニューを選択して実行したことを契機として実行されたが、本発明はこれに限定されない。例えば、定期的に実行されてもよい。また、例えば、情報処理装置100において、地図要求コマンドを受信したと判定されたことを契機として、実行されてもよい。
B8.変形例8:
実施形態では、地図表示処理は、スマートフォン200および情報処理装置100においてそれぞれ電源がオンした場合に実行されていたが、本発明はこれに限定されない。例えば、スマートフォン200においては、定期的に実行されてもよい。また、情報処理装置100においては、スマートフォン200から地図データ要求コマンドを受信したことを契機として実行してもよい。また、例えば、情報処理装置100においては、定期的に地図データを生成しておき、スマートフォン200から地図データ要求コマンドを受信した場合には、ステップS410を省略して、既に生成されている地図データをスマートフォン200に送信してもよい。
B9.変形例9:
実施形態の地図表示処理では、図11に示すように、地図上において、ユーザが指定した顧客グループの住所(より正確には、かかる住所の中心位置)のみを矩形の印260により示していたが、本発明はこれに限定されない。例えば、すべての顧客の住所に、各顧客の所属するグループを表す情報を表示してもよい。具体的には、例えば、グループ毎に異なる色によって、各顧客の住所を表示してもよい。また、例えば、グループ毎に異なる形の印を、各顧客の住所に表示してもよい。
B10.変形例10:
実施形態では、顧客を複数のグループに分類するまでを行なっていたが、さらに、かかる分類に基づき、ターゲット顧客を特定してもよい。ターゲット顧客とは、例えば、営業活動を行なう際にターゲットとする顧客などを意味する。特定方法としては、例えば、第1類ないし第4類顧客として分類された顧客をターゲット顧客として特定してもよい。第1類ないし第4類顧客は、裕福層顧客であり、且つ、同居世帯(同居人)が存在する或いは存在する可能性が高い顧客を意味する。このような顧客をターゲット顧客として特定することにより、例えば、住宅ローン、投資信託、および各種保険等の新たな金融商品等の販売促進のターゲットする顧客を容易に特定できる。かかる構成においては、第1類ないし第4類顧客をターゲット顧客として特定する機能部(ターゲット顧客特定部)を、制御部110が有してもよい。
B11.変形例11:
実施形態では、顧客分類処理は、すべて情報処理装置100において実行されていたが、少なくとも一部の処理を、スマートフォン200において実行してもよい。また、顧客分類処理の少なくとも一部を、情報処理装置100およびスマートフォン200とは異なる他の装置において実行してもよい。同様に、地図表示処理においてスマートフォン200で実行される処理の少なくとも一部を情報処理装置100において実行してもよく、また、情報処理装置100で実行される処理の少なくとも一部をスマートフォン200において実行してもよい。例えば、スマートフォン200において地図データを生成してもよい。
B12.変形例12:
実施形態における情報処理システム10の構成は、あくまでも一例であり、種々変更可能である。例えば、地図を表示するデバイスとして、スマートフォン200に代えて、または、スマートフォン200に加えて、他の任意のタイプの携帯電話端末、携帯型のナビゲーション装置、および車載型のナビゲーション装置等を用いてもよい。また、情報処理装置100が路線価データベース123を備えない構成としてもよい。この構成においては、情報処理装置100とは異なる装置が路線価データベースを備える構成とし、顧客資産判定処理のステップS120において、顧客資産判定部112が路線価データベースを備える装置にアクセスして、対象顧客の住所の路線価を取得してもよい。また、実施形態における顧客は、金融取引を行なう金融機関の顧客であったが、他の任意の商取引を行なう顧客であってもよい。かかる顧客であっても、その商取引の取引額を顧客データベースに記録しておくことで、顧客資産判定処理を精度良く実行できる。また、各実施形態において、ハードウェアによって実現されていた構成の一部をソフトウェアに置き換えるようにしてもよく、逆に、ソフトウェアによって実現されていた構成の一部をハードウェアに置き換えるようにしてもよい。また、本発明の機能の一部または全部がハードウェアで実現される場合には、ハードウェアとして、例えば、集積回路およびディスクリート回路等の任意の回路ならびにそれら回路の組み合わせを利用してもよい。また、本発明の機能の一部または全部がソフトウェアで実現される場合には、そのソフトウェア(コンピュータプログラム)は、コンピュータ読み取り可能な記録媒体に格納された形で提供することができる。この発明において、「コンピュータ読み取り可能な記録媒体」とは、フレキシブルディスクやCD−ROMのような携帯型の記録媒体に限らず、各種のRAMやROM等のコンピュータ内の内部記憶装置や、ハードディスク等のコンピュータに固定されている外部記憶装置も含んでいる。すなわち、「コンピュータ読み取り可能な記録媒体」とは、データを一時的ではなく固定可能な任意の記録媒体を含む広い意味を有している。
本発明は、上述の実施形態および変形例に限られるものではなく、その趣旨を逸脱しない範囲において種々の構成で実現することができる。例えば、発明の概要の欄に記載した各形態中の技術的特徴に対応する本実施形態、変形例中の技術的特徴は、上述の課題の一部又は全部を解決するために、あるいは、上述の効果の一部又は全部を達成するために、適宜、差し替えや、組み合わせを行うことが可能である。また、その技術的特徴が本明細書中に必須なものとして説明されていなければ、適宜、削除することが可能である。
10…情報処理システム
21a…住宅地図属性データベース
21b…地物データベース
100…情報処理装置
110…制御部
111…顧客分類部
112…顧客資産判定部
113…同居世帯判定部
115…地図データ生成部
120…記憶部
121…住宅地図データベース
122…金融機関顧客データベース
123…路線価データベース
130…通信部
200…スマートフォン
201…GPSユニット
202…記憶部
210…制御部
212…メニュー制御部
214…地図取得部
216…地図表示制御部
220…無線通信部
222…通話制御部
224…表示部
226…マイク
228…スピーカ
250…地図
260…印
BS…基地局
INT…インターネット

Claims (9)

  1. 顧客の氏または氏名からなる第1名称と、該顧客の住所を示す情報と、を含む情報である顧客データを記録する顧客データベースと、
    住所を示す情報と、該住所に関連付けられた人物の氏または氏名からなる第2名称と、を含む情報である居住者データを記録する居住者データベースと、
    前記顧客データベースに記録された前記顧客データにおける前記顧客の住所を示す情報と前記居住者データベースに記録された前記居住者データにおける前記人物の住所を示す情報とから前記顧客データと前記居住者データとを対応づけ、対応づけられた該顧客データの前記第1名称と該居住者データの前記第2名称とにおける前記氏が一部において一致する場合、前記顧客は異なる人物と同居している同居世帯に属すると推定する同居人推定部と
    を備える、情報処理システム。
  2. 請求項1に記載の情報処理システムであって、
    前記同居人推定部は、前記顧客データに対して前記居住者データの前記第2名称が複数対応付けられる場合、前記顧客は異なる人物と同居している同居世帯に属すると推定する、情報処理システム。
  3. 請求項1または請求項2に記載の情報処理システムであって、
    前記顧客データベースは、前記顧客による商取引における取引額を、更に記録しており、
    前記居住者データベースは、前記住所に存在する建物の面積を示す情報を、更に記録しており、
    前記顧客データベースに記録された前記取引額が所定額以上である前記顧客と、前記取引額が前記所定額未満の前記顧客であって該顧客に対応づけられた前記居住者データの住所に存在する建物の面積が所定面積以上の顧客と、を裕福な世帯を表す裕福層世帯であると推定する裕福層推定部と
    を備える、情報処理システム。
  4. 請求項3に記載の情報処理システムであって、
    前記同居人推定部および前記裕福層推定部の両方で推定された顧客をターゲット顧客として特定するターゲット顧客特定部を備える情報処理システム。
  5. 請求項1から請求項3までのいずれか一項に記載の情報処理システムであって、
    前記顧客データベースは、互いに異なる前記顧客に関する複数の前記顧客データをそれぞれ記録しており、
    前記居住者データベースは、複数の前記居住者データをそれぞれ記録しており、
    前記同居人推定部により同居世帯に属すると推定された複数の前記顧客のうち、前記第1名称と前記第2名称とが少なくとも一部において一致する顧客と、前記第1名称と前記第2名称とが全く一致しない顧客とを、互いに異なるグループに分類する顧客分類部を備える、情報処理システム。
  6. 請求項5に記載の情報処理システムであって、
    前記第1名称は、一人の人物の氏または氏名からなり、
    前記第2名称は、複数の人物の氏または氏名からなり、
    前記顧客データベースは、前記第2名称として、前記複数の人物の氏または氏名を、それぞれに予め設定されている優先順位が明らかになるように記録しており、
    前記顧客分類部は、前記第1名称と前記第2名称とが少なくとも一部において一致する顧客において、該第2名称を構成する前記複数の人物の氏または氏名のうち、該第1名称と少なくとも一部において一致する人物の氏または氏名に予め設定されている前記優先順位が互いに一致する顧客を同一のグループに分類し、該優先順位が互いに異なる顧客を互いに異なるグループに分類する、情報処理システム。
  7. 請求項5または請求項6に記載の情報処理システムであって、
    前記居住者データベースと前記顧客分類部による分類結果とに基づき、前記分類結果を示す情報を含む地図を示す地図データを生成する地図データ生成部と、
    前記地図データに基づき、前記地図を表示する表示部と、
    を更に備える、情報処理システム。
  8. 請求項1から請求項7までのいずれか一項に記載の情報処理システムであって、
    前記第2名称は、住所に存在する表札に記載されている氏または氏名である、情報処理システム。
  9. データ構造であって、
    顧客が異なる人物と同居している同居世帯に属するか否かを示す情報と、該顧客と該異なる人物との関係性と、のうちの少なくとも一方に応じた該顧客の分類結果を示す情報と、該顧客の氏または氏名と、を備え、
    前記分類結果は、
    前記顧客の氏または氏名からなる第1名称と、該顧客の住所を示す情報と、を含む情報である顧客データと、
    住所を示す情報と、該住所に関連付けられた人物の氏または氏名からなる第2名称と、を含む情報である居住者データと、
    の両方のデータに基づき、複数のグループのうちのいずれかのグループに分類されて得られた結果である、データ構造。
JP2015070763A 2015-03-31 2015-03-31 情報処理システムおよびデータ構造 Pending JP2016192019A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2015070763A JP2016192019A (ja) 2015-03-31 2015-03-31 情報処理システムおよびデータ構造

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2015070763A JP2016192019A (ja) 2015-03-31 2015-03-31 情報処理システムおよびデータ構造

Publications (1)

Publication Number Publication Date
JP2016192019A true JP2016192019A (ja) 2016-11-10

Family

ID=57246707

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015070763A Pending JP2016192019A (ja) 2015-03-31 2015-03-31 情報処理システムおよびデータ構造

Country Status (1)

Country Link
JP (1) JP2016192019A (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023005545A (ja) * 2021-06-29 2023-01-18 日本電気株式会社 住民状況推定装置、住民状況推定方法およびコンピュータプログラム
WO2023210249A1 (ja) * 2022-04-26 2023-11-02 インフィック株式会社 情報処理装置及び情報処理方法

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2023005545A (ja) * 2021-06-29 2023-01-18 日本電気株式会社 住民状況推定装置、住民状況推定方法およびコンピュータプログラム
WO2023210249A1 (ja) * 2022-04-26 2023-11-02 インフィック株式会社 情報処理装置及び情報処理方法

Similar Documents

Publication Publication Date Title
US8996523B1 (en) Forming quality street addresses from multiple providers
Chandy et al. Big data for good: Insights from emerging markets
US9798819B2 (en) Selective map marker aggregation
US20050192999A1 (en) System and method of virtualizing physical locations
US9250088B1 (en) Discovery of public points of interest
CA2650674A1 (en) Location-specific content communication system
JP2014511521A (ja) ジオソーシャルネットワーキングシステムのための広告ベース位置のランク付け
JP4828653B1 (ja) サーバ、辞書生成方法、辞書生成プログラム、及びそのプログラムを記録するコンピュータ読み取り可能な記録媒体
Sarkar et al. Corporate editors in OpenStreetMap: Investigating co‐editing patterns
Speake et al. Visual and aesthetic markers of gentrification: agency of mapping and tourist destinations
Kilic et al. Effects of reverse geocoding on OpenStreetMap tag quality assessment
US9262550B2 (en) Processing semi-structured data
Thatcher From volunteered geographic information to volunteered geographic services
Ricker et al. Fuzzy boundaries: Hybridizing location‐based services, volunteered geographic information and geovisualization literature
CN118941330A (zh) 一种基于poi和客户数据挖掘潜在商机的方法及系统
KR20160025698A (ko) 지역 특성을 반영한 지역 정보 제공 장치 및 그 방법
JP2014056364A (ja) 営業支援システム、営業支援方法、営業支援装置、端末装置、営業支援プログラムおよび営業支援要求プログラム
CN107025246B (zh) 一种目标地理区域的识别方法和装置
Hladík et al. Spatial-temporal analysis of retail and services using Facebook Places data: A case study in Brno, Czech Republic
CN105493136A (zh) 具有不同程度的重叠地理编码像素的地图
JP2016192019A (ja) 情報処理システムおよびデータ構造
Küspert et al. Concept of a digital communication platform to increase the citizens’ interest in spatial planning
US9449110B2 (en) Geotiles for finding relevant results from a geographically distributed set
US8954864B1 (en) Contact list integrated with social network
CN109492033A (zh) 一种族谱创建、展示方法以及装置