JP6776308B2

JP6776308B2 - 情報処理システム、情報処理方法、および、プログラム

Info

Publication number: JP6776308B2
Application number: JP2018205435A
Authority: JP
Inventors: 元中川; 仁真木
Original assignee: 株式会社Ｊｏｎ
Priority date: 2018-10-31
Filing date: 2018-10-31
Publication date: 2020-10-28
Anticipated expiration: 2034-09-08
Also published as: JP2019016407A

Description

本発明は、情報処理システム、情報処理方法、および、プログラムに関する。

クレジットカード契約等の申込みをする際には、申込者の氏名とともに住所の記載が求められることが一般的となっている。また、このような住所の記載は、クレジットカード契約の場面以外でも、社会生活の多様な場面において求められるようになっている。

なお、特許文献１には、入力された住所が存在しない場合にユーザが意図した住所の地点により近い地点の座標を得ることができるシステムが記載されている。

特開２０１１−５３９８２号公報

ここで、クレジットカード契約等の申込みを受けて、申込者の氏名や住所等の記載を求める側としては、これらの記載から申込者の信憑性や経済力を判断することができれば有用である。

本発明は、上記のような課題に鑑みて、住所等の情報から申込者の信憑性や経済力を判断することができる情報処理システム、情報処理方法、および、プログラムを提供することを目的とする。

（１）本発明にかかる情報処理システムは、所定地域内に建築された建物の住所を示す住所情報と、前記建物の所有者を示して、前記住所情報に関連付けられる所有者情報と、を記憶する記憶手段を備えた情報処理システムであって、申込者の氏名情報および住所情報を含む、申込者情報を取得する申込者情報取得手段と、前記申込者の住所情報に基づいて前記記憶手段から取得される、前記申込者が居住するとされる建物についての前記所有者情報、および、前記申告者の氏名情報に基づいて、前記申込者が居住するとされる建物の所有状況を判定する所有状況判定手段と、を有することを特徴とする。

（２）（１）に記載された情報処理システムであって、前記記憶手段には、前記建物に設定された抵当権に関する抵当権情報が、前記住所情報に関連付けて記憶され、前記所有状況判定手段は、前記抵当権情報に基づいて、前記申込者が居住するとされる建物に住宅ローンが設定されているか否かを判定する、ことを特徴としてもよい。

（３）（２）に記載された情報処理システムであって、前記記憶手段には、前記所有者情報によって示される所有者が前記建物を所有することとなった時期を示す情報が、前記住所情報に関連付けてさらに記憶され、前記抵当権情報は、前記建物に抵当権が設定された時期を示す情報を含み、前記所有状況判定手段は、前記建物に抵当権が設定された時期を示す情報が、前記建物を所有することとなった時期を示す情報に対応するか否かを判定することにより、前記建物に住宅ローンが設定されているか否かを判定する、ことを特徴としてもよい。

（４）本発明に係る情報処理方法は、所定地域内に建築された建物の住所を示す住所情報と、前記建物の所有者を示して、前記住所情報に関連付けられる所有者情報と、を記憶する記憶手段を備えた情報処理システムにおける情報処理方法であって、申込者の氏名情報および住所情報を含む、申込者情報を取得する申込者情報取得ステップと、前記申込者の住所情報に基づいて前記記憶手段から取得される、前記申込者が居住するとされる建物についての前記所有者情報、および、前記申告者の氏名情報に基づいて、前記申込者が居住するとされる建物の所有状況を判定する所有状況判定ステップと、を有することを特徴とする。

（５）本発明に係るプログラムは、所定地域内に建築された建物の住所を示す住所情報と、前記建物の所有者を示して、前記住所情報に関連付けられる所有者情報と、を記憶する記憶手段を備えた情報処理システムのコンピュータを、申込者の氏名情報および住所情報を含む、申込者情報を取得する申込者情報取得手段、前記申込者の住所情報に基づいて前記記憶手段から取得される、前記申込者が居住するとされる建物についての前記所有者情報、および、前記申告者の氏名情報に基づいて、前記申込者が居住するとされる建物の所有状況を判定する所有状況判定手段、として機能させる。

（６）本発明に係る情報処理システムは、登記の一単位となる建物に対応するレコードと、一筆の土地に対応するレコードとを記録する不動産情報記憶部を備えた情報処理システムであって、住所情報の入力を受け付ける住所情報受付手段と、前記一筆の土地に存在し得る建物の所在地を示す所在地情報を生成する所在地情報生成手段と、前記所在地情報に基づいて、前記住所情報に対応する建物が存在し得る土地を特定する土地特定手段と、前記土地特定手段によって特定された土地に存在し得る建物の登記情報を取得する登記情報取得手段と、を有することを特徴とする。

（７）（６）に記載された情報処理システムであって、前記不動産情報記憶部には、前記一筆の土地に対応する筆ポリゴンと、１又は複数の前記筆ポリゴンに対応する街区ポリゴンと、が記憶され、前記所在地情報生成手段は、前記街区ポリゴンと、当該街区ポリゴン内に含まれる筆ポリゴンとに基づいて基礎番号を導出する基礎番号導出手段を有し、前記基礎番号導出手段によって導出された前記基礎番号が前記所在地情報の少なくとも一部を構成するように、前記所在地情報を生成する、ことを特徴としてもよい。

（８）本発明に係る情報処理方法は、登記の一単位となる建物に対応するレコードと、一筆の土地に対応するレコードと、を記録する不動産情報記憶部を備えた情報処理システムにおける情報処理方法であって、住所情報の入力を受け付ける住所情報受付ステップと、前記一筆の土地に存在し得る建物の所在地を示す所在地情報を生成する所在地情報生成ステップと、前記所在地情報に基づいて、前記住所情報に対応する建物が存在し得る土地を特定する土地特定ステップと、前記土地特定ステップによって特定された土地に存在し得る建物の登記情報を取得する登記情報取得ステップと、を有することを特徴とする。

（９）本発明に係るプログラムは、登記の一単位となる建物に対応するレコードと、一筆の土地に対応するレコードと、を記録する不動産情報記憶部を備えた情報処理システムのコンピュータを、住所情報の入力を受け付ける住所情報受付手段、前記一筆の土地に存在し得る建物の所在地を示す所在地情報を生成する所在地情報生成手段、前記所在地情報に基づいて、前記住所情報に対応する建物が存在し得る土地を特定する土地特定手段、前記土地特定手段によって特定された土地に存在し得る建物の登記情報を取得する登記情報取得手段、として機能させる。

（１０）本発明に係る情報処理システムは、建物の地図上の位置座標を特定できる建物座標情報を含み登記の一単位となる建物に対応する建物レコードと、土地の地図上の位置座標を特定できる土地座標情報を含み一筆の土地に対応する土地レコードと、を記録する不動産情報記憶部を備えた情報処理システムであって、前記情報処理システムは、前記建物座標情報、および、当該建物座標情報によって特定される建物が存在する一筆の土地に対応する土地レコードに含まれる情報に基づいて、前記建物座標情報によって特定される建物の建築計画概要書情報を取得する建築計画概要書情報取得手段を有する、ことを特徴とする情報処理システム。

（１１）本発明に係る情報処理システムは、建物が存在するべき一筆の土地を特定する土地特定手段と、前記土地特定手段によって特定された前記一筆の土地に建てられた前記建物の登記情報を取得する登記情報取得手段と、前記登記情報取得手段によって前記建物の登記情報が取得されなかった場合に、当該建物の建築計画概要書情報を取得する建築計画概要書情報取得手段と、を有することを特徴とする。

（１２）本発明に係る情報処理方法は、建物の地図上の位置座標を特定できる建物座標情報を含み登記の一単位となる建物に対応する建物レコードと、土地の地図上の位置座標を特定できる土地座標情報を含み一筆の土地に対応する土地レコードと、を記録する不動産情報記憶部を備えた情報処理システムにおける情報処理方法であって、前記情報処理方法は、前記建物座標情報、および、当該建物座標情報によって特定される建物が存在する一筆の土地に対応する土地レコードに含まれる情報に基づいて、前記建物座標情報によって特定される建物の建築計画概要書情報を取得する建築計画概要書情報取得ステップを有することを特徴とする。

（１３）本発明に係るプログラムは、建物の地図上の位置座標を特定できる建物座標情報を含み登記の一単位となる建物に対応する建物レコードと、土地の地図上の位置座標を特定できる土地座標情報を含み一筆の土地に対応する土地レコードと、を記録する不動産情報記憶部を備えた情報処理システムのコンピュータを、前記建物座標情報、および、当該建物座標情報によって特定される建物が存在する一筆の土地に対応する土地レコードに含まれる情報に基づいて、前記建物座標情報によって特定される建物の建築計画概要書情報を取得する建築計画概要書情報取得手段、として機能させる。

（１４）本発明に係る情報処理方法は、建物が存在するべき一筆の土地を特定する土地特定ステップと、前記土地特定ステップによって特定された前記一筆の土地に建てられた前記建物の登記情報を取得する登記情報取得ステップと、前記登記情報取得ステップによって前記建物の登記情報が取得されなかった場合に、当該建物の建築計画概要書情報を取得する建築計画概要書情報取得ステップと、を有することを特徴とする。

（１５）本発明に係るプログラムは、建物が存在するべき一筆の土地を特定する土地特定手段、前記土地特定手段によって特定された前記一筆の土地に建てられた前記建物の登記情報を取得する登記情報取得手段、前記登記情報取得手段によって前記建物の登記情報が取得されなかった場合に、当該建物の建築計画概要書情報を取得する建築計画概要書情報取得手段、として機能させる。

本発明によれば、住所等の情報から申込者の信憑性や経済力を判断することができる情報処理システム、情報処理方法、および、プログラムを提供することができる。

第１の実施形態にかかる情報処理システムのネットワークの基本構成を示す図である。第１の実施形態にかかる情報処理システムの機能的構成を示す図である。第１の実施形態における情報処理システムの建物情報記憶部に保持される建物テーブルを説明するための図である。第１の実施形態における情報処理システムの土地情報記憶部に保持される土地テーブルを説明するための図である。第１の実施形態における情報処理システムのポリゴン情報記憶部に保持されるポリゴン情報の種類を説明するための図である。第１の実施形態における情報処理システムに入力される申込者リストを説明するための図である。第１の実施形態における情報処理システムの所有状況判定処理と、供担性判定処理のフローを示す図である。第２の実施形態における情報処理システムの機能的構成を示す図である。第２の実施形態における情報処理システムにおいて、住居表示番号から土地を登記される様子を説明するための図である。第２の実施形態における情報処理システムの住所存在性判定処理（建物情報の取得処理）のフローを示す図である。第３の実施形態における情報処理システムの住所存在性判定処理（建物情報の取得処理）のフローを示す図である。

［第１の実施形態］
以下においては、本発明の第１の実施形態に係る情報処理システム１についての説明をする。

図１は、本発明の第１の実施形態に係る情報処理システム１のネットワークの基本構成を示す図である。本実施形態の情報処理システム１は、サーバ装置２と、例えば、インターネット回線によって接続されたクライアント装置３とを含んで構成されるものとなっている。

次に、図２は、第１の実施形態に係る情報処理システム１の機能的構成を示す図である。

また、図３乃至図４は、本実施形態における不動産情報記憶部４の建物情報記憶部５と土地情報記憶部６において保持されるデータベースのフィールドについての説明をする図であり、図５は、不動産情報記憶部４のポリゴン情報記憶部７において記録されるポリゴン情報について説明をする図である。

ここで、建物情報記憶部５のデータベースにて保持される各レコード（建物レコード）には建物ポリゴンが格納されており、土地情報記憶部６の各レコード（土地レコード）には筆ポリゴンが格納されている。これらの建物ポリゴンや筆ポリゴン、および、ポリゴン情報記憶部７における各ポリゴンは、共通の座標軸上で定義されるものとなっており、情報処理システム１においてこれらを重ね合わせることによって、仮想的に地図表示を生成しデータ処理をすることができるようになっている。

また図６は、本実施形態においてクライアント装置３に入力される申込者リストを示す図となっている。申込者リストは、一又は複数の申込者情報（申込者レコード）を含んで構成されるものとなっている。

以下においては、図３〜図６の説明を適宜行いつつ、図２を用いて本実施形態の情報処理システム１についての説明を行う。

また第１の実施形態においては、図３〜図５で説明される不動産情報記憶部４のデータベースが、原則として、ほぼ完備された状態のものであることを前提として説明をする。なお不動産情報記憶部４の各データベースは、構築や維持には多大な労力がかかること等の事情があるためレコードやフィールドが部分的に欠けていること等も想定される。第２の実施形態および第３の実施形態は、不動産情報記憶部４が過渡的な状態となっていることを考慮した構成となっており、その詳細は後述するものとする。

本実施形態のサーバ装置２およびクライアント装置３は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）等の記憶素子、ならびにハードディスク等によって構成される記憶領域と、ＣＰＵ（Central Processing Unit）等のプログラム制御デバイスを含むことによって実現される。サーバ装置２およびクライアント装置３では、ハードディスク等の記憶領域に格納されたプログラムをＣＰＵが実行することによって各機能が実現される。

サーバ装置２は、不動産情報記憶部４と、登記情報取得部ＲＧとを含んで構成され、クライアント装置３は、申込者情報取得部ＯＧと、建物情報問い合わせ部ＡＱと、所有状況判定部ＰＪとを含んで構成される。

本実施形態の情報処理システム１においては、クライアント装置３を介してサーバ装置に入力された申込者の住所情報が、サーバ装置２の不動産情報記憶部４にて照会され、これにより、クレジットカード契約等の申込者が所有する不動産に関する判断をすることができるようになっている。

まず、本実施形態のサーバ装置２は、所定の領域内の不動産の属性情報を記憶する不動情報記憶部４を含んで構成され、不動産情報記憶部４は、さらに建物情報記憶部５と、土地情報記憶部６と、ポリゴン情報記憶部７とを含んで構成される。建物情報記憶部５は、建物の登記簿上の位置（ＮＯ．１〜ＮＯ．４のフィールドの情報。）やその住所、所有権に関する情報等を保持するデータベースとなっており、土地情報記憶部６は、土地の登記簿上の位置（ＮＯ．１〜ＮＯ．４のフィールドの情報。）や所有権に関する情報等を保持するデータベースとなっている。また、建物情報記憶部５および土地情報記憶部６は、それぞれ建物および土地についての公共座標値に対応する建物座標情報（例えば、建物ポリゴン）と、土地座標情報（例えば、筆ポリゴン）をも保持している。

ここで、本実施形態の建物情報記憶部５は、登記の一単位となる一戸の建物に対応する複数のレコード（建物レコード）を記録するデータベースを保持しており、図３は、そのフィールド名称を説明するための図となっている。「都道府県」、「市区町村」、「字・町目」の情報は、建物の所在を示す情報となっており、これらに「家屋番号」の情報を併せることで、建物が一意に特定される。

また、「住所」は、日常的に建物を特定するための情報として用いられるが、住居表示が実施されている自治体では「住居表示」による住所となり、住居表示が実施されていない自治体では「地番表記」による住所となる。「住居表示」による住所は、都道府県−（郡）−市町村・特別区−町・字‐街区‐住居番号によって原則的に構成され、「地番表記」による住所は、都道府県−（郡）−市町村・特別区−町・字‐地番によって原則的に構成される。このため「住居表示」による住所では、さらに「住所」のフィールドに従属する「街区」、「住居番号」のフィールド（ＮＯ．６〜７）にその部分の情報が格納され、「地番表記」による住所では、「地番」（「番地」と表記されることもある。）のサブフィールド（ＮＯ．８）にその部分の情報が格納される。

また、「種類（用途）」、「構造」、「床面積」、「建築時期」、「所有者」、「所有権に関する情報」、および「所有権以外の権利に関する情報」は、ＮＯ．１〜ＮＯ．４のフィールドと同様に、建物の不動産登記簿を原典とする情報となっている（なお、「所有権に関する情報」、「所有権以外の権利にする情報」以外の情報は、不動産登記簿が存在しない建物については、建築計画概要書など、他の公文書を原典とすることもありうる。）。「所有権に関する情報」は、登記簿における「権利部（甲区）」に対応する情報であり、所有権の移転等の「登記の目的」、その登記が受け付けられた「受付年月日」や「受付番号」、所有権の移転後の「所有者」を含むものとなっている。また、「所有権以外の権利に関する情報」は、登記簿における「権利部（乙区）」に対応する情報であり、抵当権の設定等の「登記の目的」、その登記が受け付けられた「受付年月日」や「受付番号」、抵当権の「債権額」や「債務者」、「抵当権者」を含むものとなっている。

「建物座標情報（建物ポリゴン）」は、地図上での建物の位置を示す建物ポリゴンを形成するための複数の屈曲点座標値を示す（又は含む）ものとなっており、国土基盤地図、あるいは、航空写真、その他の公文書から取得されるものとなっている。本実施形態としては、定期的にこれらによって建物ポリゴンが取得されるようになっている。（なお、建物座標情報としては、建物ポリゴンではなくとも地図上での特定の位置を示す１つの座標・代表点のようなものでも良い。）

なお、本実施形態における建物レコードは、例えば、所定地域内の建物についての登記情報や公図、建物図面を網羅的に取得して生成するものとなっている。また、航空写真等から取得される建物ポリゴンから建物レコードを生成する場合について、例えば、地図上での筆ポリゴンとの重複を判定し、重複する筆ポリゴンを有する土地レコードの地番から当該土地上の建物（すなわち当該建物ポリゴンにかかる建物）の家屋番号を導き出し、この家屋番号をもとに不動産登記簿を取得しこれをデータ化することでも生成される。なお、一筆の土地において複数の建物が存在する場合には、家屋番号が付される規則性（一筆の土地内に複数の建物が存在する場合には、重複を避けて若い番号から順番に付される等）および所定間隔をおいて取得される複数の航空写真等に基づいて、各建物ポリゴンの家屋番号が導き出される。また、各建物ポリゴンにかかる住所（さらには住居番号等）は、例えば、自治体において管理される住居表示台帳を参照することにより導くことができ、これにより建物の所在、家屋番号、建物ポリゴン、住所の情報を備えた建物レコードを生成することができる。ただし、これは建物レコードの生成手法の一例であり、上記以外の行政文書を用いた生成手法もありうるし、上記手法に加え、上記以外の行政文書をも用いることで網羅性や精度、鮮度を向上させることが可能である。例えば、地番と住居表示との対照表が公開されている自治体の場合には、これと上記生成データとを照合し、不整合箇所を調査するなどして、網羅性や精度を向上させることができる。

また、「建築計画概要書の有無」は、建築計画概要書情報が取得されている場合には、「有」の旨が入力され、当該情報が取得されていない場合には「無」の旨が入力される。また「有」が入力されている場合には、建築計画概要書に記載された情報が、上記の「所有者」等の幾つかのフィールドや他の不図示のフィールドに記入される。また、「滅失・閉鎖フラグ」は、「滅失」あるいは「閉鎖」の登記がなされている場合に、その旨の情報が入力されるフィールドとなっており、「滅失」等の登記がなされている場合には、その建物の登記が既に存在しないものとして扱われる。なお「滅失・閉鎖フラグ」は、登記申請情報によって取得されるものとなっており、このフィールドを設けることで、航空写真等よりも早く、建物データベースに建物の消滅等を反映することが出来るようになる。

次に、本実施形態の土地情報記憶部６は、登記の一単位となる一筆の土地に対応する複数のレコード（土地レコード）を記録するデータベースを保持しており、図４は、そのフィールド名称を説明するための図となっている。同図で示されるように、土地情報記憶部６に記憶されるデータベースの土地レコードには、「都道府県」、「市区町村」、「字・町目」の情報が含まれて、これらは土地の所在を示す情報となっており、これらに「地番」の情報を併せることで、土地が一意に特定される。この「都道府県」、「市区町村」、「字・町目」、「地番」の情報は、土地の不動産登記簿を原典とする。

また「街区」は、土地レコードが対応する一筆の土地が、住居表示が実施されている区域である場合に、当該一筆の土地が属する街区の情報を格納するフィールドとなっている。このような「街区」のフィールドに格納される情報は、例えば、地図上で筆ポリゴンに重複する街区ポリゴンを導き出すことにより、取得されるものとなっている。

また、「地目」、「面積」、「所有者」、「所有権に関する情報」、「所有権以外の権利に関する情報」も、同様に、土地の不動産登記簿を原典として取得される情報となっており、「所有権に関する情報」には、建物の場合と同様に、所有権の移転等の「登記の目的」等の情報が含まれ、「所有権以外の権利に関する情報」にも、抵当権の設定等の「登記の目的」等の情報が含まれる。

また、「土地座標情報（筆ポリゴン）」は、地図上での一筆の土地の境界を示す筆ポリゴンを形成するための複数の屈曲点座標値を示す情報となっており、例えば、公図や地積測量図に記された座標値をデジタル化することで取得することができるものとなっている。また、「所在地情報（潜在住所）」のフィールドには、住居表示地区の場合に、街区ポリゴンと筆ポリゴンの位置関係に基づいて、当該筆ポリゴン上に建築される可能性のある建物の住居番号の候補を予め求めて格納するものとなっており、地番表示地区の場合に、当該土地で建築される建物の住所の一部となりうる地番を格納するものとなっている。この「所在地情報」についてのさらなる詳細は第２の実施形態にて説明をする。

また、「校区情報」、「ハザードマップ情報」、「路線価」、「公示地価」、「等高線（標高値）」のフィールドには、当該土地が属する校区の情報やハザードマップに関する情報、さらに、路線価や公示地価、標高値の値がそれぞれ格納される。また、「更地フラグ」のフィールドには、当該土地に建物が建てられていない状態である場合には、更地である旨の情報が記録されるようになっており、例えば、筆ポリゴンと建物ポリゴンとの照合や航空写真の目視調査に基づいて更地であるか否かが判断されるようになっている。

なお、本実施形態における土地レコードは、例えば、所定地域内の土地についての登記情報や公図を網羅的に取得して生成するものとなっている。

そして、本実施形態のポリゴン情報記憶部７は、「都道府県ポリゴン」等の屈曲点座標を記録するものとなっている。これらのポリゴンは、建物情報記憶部５の建物ポリゴンや土地情報記憶部６の筆ポリゴンと重ね合わされて、後述の建物位置情報を生成する処理等が行なわれる。なお、筆ポリゴンにおける「校区情報」等のフィールドにおいては校区ポリゴンのＩＤ情報が格納され、ポリゴンを定義するための地図座標軸上の屈曲点座標値についての情報がポリゴン情報記憶部７において記憶されていてもよい。なお同様に、建物テーブルにおける「建物座標情報」のフィールドに建物ポリゴンの識別情報が記録されて、ポリゴン情報記憶部７において建物ポリゴンの識別情報に関連づけられて、建物ポリゴンを構成する複数の屈曲点座標値が記録されていてもよい。

サーバ装置２は、以上のような不動産情報記憶部４を有するとともに、さらに、登記情報取得部ＲＧを有しており、登記情報取得部ＲＧは、例えば、インターネット回線を利用して、財団法人民事法務協会による登記情報提供サービスにアクセスして登記情報を取得する。登記情報取得部ＲＧとしては、外部から登記申請情報を定期的に取得し、登記変化の生じた不動産についての登記情報を取得するようにしてもよいし、後述のクライアント装置３からの建物情報の問い合わせに応じて、その問い合わせの対象となる建物レコードの登記情報を取得（更新）するようにしてもよい。登記情報取得部ＲＧは、不動産情報記憶部４に記録された不動産のレコードに、取得した登記情報の内容を反映する（新たに建物レコード等を生成する、あるいは、既存の建物レコード等に記録された情報を更新する）。

なお、登記申請情報とは、その登記申請が行われた受付年月日、その申請を特定する受付番号、登記申請された対象物件を特定する情報としての都道府県名、市区町村名、大字・町名、地番及び家屋番号、登記の目的、用途などのデータを含んで構成される情報である。登記申請情報は、例えば、法務局から紙媒体ベースで記載された不動産登録受付簿から取得することができ、これにより、所定地域内の不動産に発生する登記簿上の変化（登記変化）を監視することができる。また本実施形態における登記申請情報は、「地番および家屋番号」等をフィールドとするテーブル形式でデータ化されてサーバ装置２に受け入れられるようになっており、登記申請情報の１レコードは、原則的に、１つの不動産に対する１回の登記申請の内容の一部に対応している。

次に、クライアント装置３の構成について具体的に説明をする。

申込者情報取得部ＯＧは、クレジットカード契約等の申込者に関する情報を取得する。申込者に関する情報には、申込者の氏名を示す情報（氏名情報）と、申込者の住所を示す情報（住所情報）とが含まれており、申込者情報取得部ＯＧとしては、他のサーバやネットワーク経由で申込者に関する情報を取得してもよいし、クライアント装置３のユーザの入力によって取得をするようにしてもよく、複数の申込者に関する情報を含む申込者情報リストを取得するようにしてもよい（図６（ａ）参照）。

また申込者情報としては、氏名情報と住所情報の他の情報（例えば、配偶者の氏名情報や、住所とする建物が借家であるか持ち家であるか等）を含むようにしてもよい。このような他の情報を含むことで、下記の所有状況判定部ＰＪにおける判定の精度を向上できるようになるが、他の情報の入力を申込者に求めるのであればその負担が増大し、迅速性が求められる与信業務処理の効果を減殺することとなる。

建物情報問い合わせ部ＡＱは、申込者の住所情報をサーバ装置２に送信をして、当該住所情報に対応する建物レコードの問い合わせを行う。サーバ装置２は、クライアント装置３からの問い合わせとともに住所情報を受信し、建物テーブルにおける「住所」のフィールド欄を検索して、受け取った住所情報と同一内容のデータが記録されている建物レコードを特定する。建物情報問い合わせ部ＡＱは、サーバ装置２によって特定された建物レコードの内容の少なくとも一部（望ましくは全部）を、サーバ装置２から受け取る。

所有状況判定部ＰＪは、建物情報問い合わせ部ＡＱがサーバ装置２から受け取った建物レコードの内容と、申込者の氏名情報とに基づいて、申込者が居住する住所となる建物（区分建物を含む）をどのように所有しているかについての判定を行う。

より詳細には、所有状況判定部ＰＪは、住所存在性判定部Ｐ１と、所有判定部Ｐ２と、供担性判定部Ｐ３とを含んで構成される。本実施形態における住所存在性判定部Ｐ１は、申込者が契約時に記載をしたはずの住所に対応する建物のレコードが建物情報記憶部５に記録されていない場合に、原則的に、現実には存在しない架空の住所を申込者が住所情報として入力をしたと判定をする。申込者が契約時に記載をしたはずの住所に対応する建物のレコードが建物情報記憶部５に記録されている場合であっても、当該建物レコードにおける「種類」のフィールドにおいて、非住居性の施設である旨の内容が格納されている場合には、上記と同様に、現実には存在しない架空の住所を申込者が住所情報として入力をしたと判定をするようにしてもよい。

次に、所有判定部Ｐ２は、申込者が記載をした住所に対応する建物のレコードが建物情報記憶部５に記録されている場合（住所存在性判定部Ｐ１において、申込者が、架空でない現存する住所にて申し込みをしたと判定される場合）に、当該建物のレコードに記録される建物の所有者についての情報と、申込者の氏名情報とに基づいて、申込者が記載をした住所に対応する建物を所有しているか否かを判定する。具体的には、申込者の「姓・名」と、建物の所有者の「姓・名」が一致している場合には、所有判定部Ｐ２は、申込者が建物を所有しているものとして判定をする。また、申込者の配偶者の「姓・名」の記載が得られており、当該配偶者の「姓・名」と建物の所有者の「姓・名」とが一致している場合には、所有判定部Ｐ２は、申込者が建物を所有しているものとみなして判定をする。また申込者の「姓」と、建物の所有者の「姓」のみが一致している場合には、申込者の肉親や親族が建物を所有しているものと判定をして「姓・名」が一致している場合に準じるものとして扱う（すなわち、「姓・名」が一致している場合と同様に扱う）。これに対して、申込者の「姓」と、建物の一又は複数の所有者の「姓」との一致がない場合には、申込者が記載をした住所に対応する建物が、申込者やその親族によって所有されていない可能性が高いと判断をする。（なお、所有判定部Ｐ２としては、建物レコードにおける「種類（用途）」に基づいて、申込者が記載をした住所に対応する建物が賃貸性住居施設かどうか等の判定をすることで、申込者が記載をした住所に対応する建物を所有しているか否かの判定の精緻性を高めるようにしてもよい。）

そして、供担性判定部Ｐ３は、所有判定部Ｐ２において、申込者やその配偶者、あるいはその親族が建物を所有していると判定をした場合に、当該建物について設定された抵当権に関する情報等に基づいて、当該建物が担保として他者に提供されているか否か等の判定を行う。

具体的には、本実施形態の供担性判定部Ｐ３は、申込者が住宅ローンを有している者か否かの判定をする機能ブロックとなっており、建物情報記憶部５のレコードにおいて保持された所有権以外に関する情報等に基づいて、申込者が記載をした住所に対応する建物が住宅ローンの設定により取得されたものであるか否かを判定する。供担性判定部Ｐ３としては、例えば、（１）建物が非賃貸性住居性施設（居宅または区分所有建物）であるか否か、（２）建物に根抵当権ではない１番抵当権が設定されているか否か、（３）１番抵当権が、建物の新築時の登記の日、あるいは、譲渡性原因の所有権移転登記の日を基準とした所定期間内（例えば、これらの登記から２ヵ月後以内）に設定されているか否か、（４）１番抵当権の抵当権者は、特定の組織（住宅ローンサービスを展開している銀行・金融機関）であるか否か、（５）抵当権の債務者が、建物の所有者であるか否か、といった条件を判定して、全ての条件に合致する場合に住宅ローンの設定により取得されたものであると判定をしてもよい。

また、上記の供担性判定部Ｐ３としては、上記（１）〜（５）の他に、例えば、申込者情報取得部ＯＧによって、さらに申込者の住所に対応する建物の資産価値についての情報が取得されて、この資産価値についての情報と、建物情報記憶部５のレコードにおいて保持された所有権以外に関する情報に含まれる債権額の情報とに基づいて、住宅ローンであるか否かを判定してもよい（（６）すなわち、申込者によって申告された建物の資産価値が、所有権以外に関する情報に記載された債権額以下となるか否か）。またさらに、（７）建物所有者が、抵当権の目的となった建物に居住しているか否か、（８）抵当権設定に付随して共同抵当が付されているか否か、（９）抵当権の抹消が行なわれているか否か、等の条件に基づいて、住宅ローンである否かを判定してもよい。供担性判定部Ｐ３としては、（１）〜（９）の条件の全てに基づいて、住宅ローンであるか否かを判定するようにしてもよいし、例えば、（１）〜（５）および（９）に基づいて、住宅ローンであるか否かを簡易的に判定するようにしてもよく、（１）〜（９）のうちのいずれか複数に基づいて判定をするようにしてよい。

クレジットカード会社としては、住所存在性判定部Ｐ１によって申込者が記載をした住所に対応する建物が存在しないと判定される場合に、クレジットカードの契約を締結しないようにするか、与信査定を低く設定する。また、所有判定部Ｐ２によって申込者が記載をした住所に対応する建物の所有者が、申込者本人や配偶者ではなく親族でもない可能性が高いと判定される場合に、クレジットカードの融資枠の査定を低くするようにする。また、あるいは、担性判定部Ｐ３によって、申込者が記載した住所に対応する建物に住宅ローンが設定されていると判定される場合に、申込者のクレジットカードによる融資枠の査定を低く評価することとする（図６（ｂ）参照）。以上のように、本実施形態の情報処理システム１は、申込者の氏名や住所を含む申込者情報に基づいて、申込者の信憑性や経済力の判定に貢献できるものとなっている。

次に、図７を用いて本実施形態の情報処理システム１の実行する処理のフローについて説明をする。図７（ａ）は、所有状況判定処理のフローを示す図となっており、図７（ｂ）は、Ｓ６０５における供担性判定処理のフローを示す図となっている。

まず本実施形態の情報処理システム１では、申込者情報の取得後、建物情報記憶部５に問い合わせることにより、申込者が入力をした住所情報をキーとする建物レコードが存在するか否かを判定する（Ｓ６０１）。そしてＳ６０２においては、申込者が記入をした住所情報に対応する内容を、「住所」のフィールドに保持しているレコード（以下、住所対応レコードともいう）が存在する場合に、住所が架空のものでなく存在するものとして判定されてＳ６０３に進む。

次に、Ｓ６０３において所有状況判定部ＰＪは、住所対応レコードにおける「所有者」のフィールドの内容と、申込者が入力をした氏名情報と比較をする。そしてＳ６０４では、申込者および配偶者の姓・名と、建物の所有者の姓・名が一致する、あるいは姓のみが一致する場合には、申込者や配偶者、あるいはその親族が住所対応レコードに対応する建物を所有しているものとして判定をし、Ｓ６０５に進む。

Ｓ６０５においては、図７（ｂ）で示されるように、供担性判定の処理が実行される。

図７（ｂ）で示されるように、供担性判定処理のＳ６０５ａでは、建物情報記憶部５において住所対応レコードの登記全部事項が記録されているか否かを判定し、これが否定された場合に、建築計画概要書情報が存在するか否かの判定をする。このＳ６０５ａおよびＳ６０５ｆは、原則的に建物情報記憶部５が完備された状態（現存するすべての建物の建物レコードにおける登記情報が完備された状態）では省略できる処理となっている。建築計画概要書情報についての詳細は第３の実施形態にて後述するが、このＳ６０５ａやＳ６０５ｆは、建物情報記憶部５が過渡的な状態となっている第３の実施形態等において有用な処理となる。Ｓ６０５ａにおいては、具体的には、登記全部事項が記録されておらず（登記情報がなく）、かつ、建築計画概要書情報が存在する建物レコードの場合（ＹＥＳの場合）には、現状において譲渡をする予定のない未登記の建物であると解釈されることから、Ｓ６０５ｆに進んで「抵当権なし」と判定をする。

次に、Ｓ６０５ａにてＮＯとなる場合（住所対応レコードにおいて登記情報が記録されている場合）には、Ｓ６０５ｂに進み、住所対応レコードの「所有権以外の権利に関する情報」のフィールドにて、抵当権が設定されているか否かを判定する。Ｓ６０５ｂでは、抵当権が設定されていないと判定をする場合に、Ｓ６０５ｆに進み、抵当権が設定されていると判定される場合に、Ｓ６０５ｃに進んで住宅ローンによる抵当権であるか否かを判定する。

そして、Ｓ６０５ｃにおいては、供担性判定部Ｐ３は、上述をした（１）〜（５）等の条件のすべてに合致するか否かにより、住宅ローンによる抵当権設定であるか否かを判定する。当該条件がすべて満足される場合には、Ｓ６０５ｄに進んで、「申込者や配偶者（あるいはその親族）に、住宅ローンが有る」という判定をし、いずれかの条件が満足されなかった場合には、Ｓ６０５ｅに進んで、住宅ローンではない（すなわち事業性の融資による抵当権設定である）という判定をする。

本実施形態の情報処理システム１では、以上のようにして、申込者の住所に対応する建物の所有状況を判定する処理を実行する。クライアント装置３のユーザとしては、Ｓ６０２において、住所が存在しないもの（または非住居性施設）として判定された場合には、存在しない住所（または住所としては存在しない箇所）を申込者が悪意で入力した蓋然性が高くなるため、クレジットカード等の契約自体を中止するようにしてもよい。また、Ｓ６０４において、申込者自身や親族が、住所に対応する建物を所有していないと判定された場合には、申込者の与信評価を低くする（あるいは、一時保留にする旨の評価とする）ようにしてもよく、Ｓ６０５において、住宅ローンがあると判定された場合には、同様に、申込者の与信評価を低くする（あるいは、一時保留にする旨の評価とする）ようにしてもよい。

[第２の実施形態]
次に、本発明の第２の実施形態の情報処理システム１について説明をする。

従来、法務局にて地番や家屋番号等を調べる際には、住宅地図の画像データに公図の画像データを単純に重ね合わせたものが用いられているに過ぎず、住居表示における住居番号と、登記簿に記載される地番や家屋番号と、例えば建物ポリゴンのような、地図上における座標を示す建物座標情報とが関連付けられて記録されたものとはなっていない。

ここで情報処理システム１としては、不動産情報記憶部４の各データベースが完備されて最新の状態で維持されているのが望ましいが、不動産情報記憶部４のデータベースはその構築には多大な労力がかかり、扱う地域が広域化するにつれて情報量が莫大なものとなってしまう。また第１の実施形態において説明をした登記申請情報による不動産情報記憶部４の更新や維持をするにしても、その情報量が大きいことから更新処理の負荷も大きいものとなる。

したがって、情報処理システム１としては、部分的にレコードが蓄積されたに過ぎない状態や、更新がされていない（すなわち、全体的にあるいは部分的に、不動産情報記憶部４の各データベースが最新の状態に維持されていない）ことをも想定して運営することも想定される。

以下においては、不動産情報記憶部４における各データベースの構築や維持についての説明をする。

土地情報記憶部６における土地データベースの内容は、筆ポリゴン自体の変動は、分筆や合筆を契機に行ったので良く、例えば、所定の地域内の土地の登記簿を網羅的に取得し初期整備のうえ、分筆・合筆に関する登記申請情報（登記異動情報）の取得を契機として更新をすることにより、その構築や管理が可能である。

また、ポリゴン情報記憶部７におけるポリゴン情報は、図５で示されるように、変動が少ない情報であり、自治体等において積極的に公表されている情報でもあることから、所定の地域内における各種のポリゴン情報を最新の状態に維持することは比較的容易であるものと考えられる。

建物情報記憶部５における建物データベースに関しては、建物の新築（表題登記）や取り壊し（滅失登記）が土地の分筆等よりも頻繁に発生する。このため所定のタイミングにおいて地域内の建物の登記情報を法務局から網羅的に取得・把握したとしても、建物データベースにおける各レコード自体の消滅・発生サイクルが短く、建物ポリゴンの変動が頻繁に生じることとなり、陳腐化してしまうのが早くなってしまう。

また、上述の登記申請情報を取得して建物情報記憶部５の内容を更新するにしても、更新にかかる登記申請情報の件数が多くなる傾向があるため、建物情報記憶部５の建物データベースを維持するコストが大きくなってしまう。また、建物データベースの各レコードの存在が土地のそれよりも頻繁に変動することを考慮すると、更新したレコードが参照・照会されることなく消滅されることも想定され、取得・更新コストの削減余地があるものと考えられる。

建物情報記憶部５としては、第１の実施形態において説明をしたように、定期的に取得される航空写真と、家屋番号の一覧表とに基づいて、家屋番号と建物ポリゴンの関連づけを行ないつつ、住居表示台帳を参照して建物ポリゴンと住所表示との関連付けを行うことで建物レコードを生成することも考えられる。しかしながら、例外的な事例も多く、必ずしもこのような処理により確実に建物レコードを生成することができるとは限らない。このため建物レコードにおいて、建物ポリゴンと、住所と、家屋番号のうちいずれかが欠けていることも想定される。

以上から、第２の実施形態の情報処理システム１においては、建物の登記情報の網羅的な取得や登記申請情報による更新を必ずしも前提としておらず、既に収集された建物の登記情報を保持しつつ、クライアント装置３からの要請や問い合わせに応じて登記情報を取得するものとなっている。

また第２の実施形態では、例えば、「住所」のフィールドの情報が欠けた建物レコードが存在すること（あるいは、建物レコード自体が存在しないこと）により、クライアント装置３からの住所情報をキーとする検索では、当該住所情報に対応する建物を必ずしも特定できないことを想定しており、まず当該住所情報に対応する土地を特定した上で、当該土地に建てられた建物の登記情報を取得するものとなっている（なお、「住所」のフィールドの情報が欠落している建物レコードのバリュエーションとしては、「登記情報（家屋番号等）に対応するフィールド」、および、「建物ポリゴン」の有無により４通りの状態が想定される。このうちいずれの情報も欠落している場合には、建物レコード自体が存在しないこととなる）。

図８は、第２の実施形態の情報処理システム１の機能的構成を示す図である。同図で示されるように、第２の実施形態のサーバ装置２は、所在地情報生成部ＰＡと土地特定部ＬＩをさらに含んで構成される。

所在地情報生成部ＰＡは、土地情報記憶部６に記録された土地レコードについて、所在地情報（潜在住所）のフィールドに格納される情報を生成する。ここで所在地情報とは、一筆の土地に建物が建てられた場合に、その建物にて付与されることとなる住所に直接的あるいは間接的に対応する情報となっており、本実施形態では、住所に用いられる住居番号あるいは地番に対応するものとなっている。所在地情報生成部ＰＡは、所定のレコードによって特定される土地が住居表示地区に属する場合には、当該土地の筆ポリゴンと、当該土地が属する街区ポリゴンの位置関係に基づいて所在地情報を生成する。また所在地情報生成部ＰＡは、地番表示地区の場合には、同一レコード内の地番のフィールドに格納された情報に基づいて所在地情報を生成する。

以下においては図９を用いて、住居表示地区に属する土地レコードの所在地情報を生成する処理について説明をする。

図９は、住居表示地区に土地が属する場合において、その土地に建物が建てられる場合に付される住居番号を決定する方法を説明するための図である。同図においては、１つの街区（街区ポリゴン）内に６つの土地（筆ポリゴン１〜６）が存在しており、各土地には１又は２戸の建物が存在している。

基礎番号は、例えば、自治体の中心に近い街区の頂点を起点とし、そこから外周に沿って時計回りに所定間隔（１０ｍあるいは１５ｍ等）ごとに区切られた領域（フロンテージ）ごとに順番に設定される。図９の例の場合には、街区ポリゴンの図中左上の頂点を起点として、時計回りに１０ｍごとのフロンテージにて順番に基礎番号が付されるようになっている。すなわち筆ポリゴン１に建てられた建物は、その玄関の位置に応じて、基礎番号２〜６のいずれかが住居番号として付される可能性がある。

サーバ装置２においては、住居表示地区であるか地番表示地区であるかについての情報が自治体ごとに記録されており、さらに住居表示地区である場合には、上述のような基礎番号の設定規則も記録されている（基礎番号の設定規則は、自治体ごとに微妙に異なるものとなっている）。所在地情報生成部ＰＡはこれらの情報を参照しつつ、筆ポリゴンと街区ポリゴンとに基づいて、土地情報記憶部６に記録されたレコードの所在地情報のフィールドに所在地情報を生成する。（なお、土地情報記憶部６および建物情報記憶部５において本実施形態のテーブル構成とは異なるテーブル構成が採用されて、所在地情報のフィールドが土地情報記憶部６ではなく建物情報記憶部５に存在してもよい。またこの場合においては、例えば、所在地情報生成部ＰＡにより、仮、又は、潜在的な所在地情報の生成をした際に、その内容を備えたレコードが建物情報記憶部５に新設されるようにしてもよい。）

なお、本実施形態における所在地情報としては、住居番号以外の情報（市区町村や町・字の情報）を含んで構成されるものとするが、これらの情報は土地テーブル（図４参照）におけるＮＯ．１〜３やＮＯ．５のフィールドに格納された情報でもあり後述の説明では、適宜省略されているものとする。

また土地特定部ＬＩは、クライアント装置３から入力された住所情報をキーとして、所在地情報生成部ＰＡによって生成された建物の所在地情報を検索し、住所情報に対応しうる土地を特定する。図９を用いて説明をすると、住所情報が住所表示地区の場合には、基礎番号に対応する土地が特定されることとなる。具体的には、住所情報に含まれる住居番号（基礎番号）が７である場合には、地番２（筆ポリゴン２）の土地が特定され、基礎番号が６である場合には、地番１又は地番２（筆ポリゴン１又は２）の土地が特定されることとなる。

そして登記情報取得部ＲＧは、土地特定部ＬＩによって特定された土地の所在・地番に基づいて、当該土地に建てられた建物の登記情報を取得する。そしてサーバ装置２は、建物情報記憶部５における建物データベースにおいて、登記情報取得部ＲＧによって取得された建物の登記情報に対応するレコードが存在しない場合には、新しくレコードを新設し、取得された登記情報の内容を新設されたレコードにおいて記録する。また、サーバ装置２によって、登記情報取得部ＲＧで取得された建物の登記情報に対応するレコードが存在すると判断される場合には、当該レコードの内容を取得された登記情報に基づいて更新する。

また建物情報記憶部５としては、航空写真等に基づいて、建物ポリゴンのみが判明している建物レコードが生成される場合も想定される。土地特定部ＬＩによって特定された一筆の土地において１つの建物ポリゴンが１対１対応するような場合（具体的には、図８における地番１のような土地が特定された場合）には、当該１つの建物ポリゴンに、登記情報取得部ＲＧによって取得された建物の登記情報を関連付けて記録するようにする。

また図９における地番２の土地が特定される場合のように、一筆の土地に２つの建物ポリゴンを元にして複数の建物レコードが生成される場合も想定される。このような場合には、まず、複数の航空写真情報（所定のタイミングを置いて規則的に撮影されるのが望ましい）に基づいて、２つの建物が建築された順番を特定し、さらに、法務局から取得される家屋番号の一覧表あるいは登記申請情報を取得して、これに基づいて２つの建物の家屋番号を判断するようにする。法務局における家屋番号の一覧表では、原則的に、建築された建物の順番に若い番号が付されて掲載される。（このほか、当該一筆の土地にかかる地番から想定される家屋番号を法務局から取得される家屋番号の一覧表から複数特定の上、当該複数の家屋番号に基づいて法務局より建物図面（建物の位置配置関係が記録されている。）を取得し、その内容を確認することでも、各建物ポリゴンと家屋番号との結びつきを、整備することが出来る。）

以上の説明のように、図９の場合において、例えば、クライアント装置３から入力された住所情報の基礎番号が「６」となる場合には、土地特定部ＬＩにより、地番１又は２の土地が特定されることとなる。そしてこの地番１及び地番２における全ての建物の登記情報が取得され、建物レコードの状態に応じて、取得された登記情報が建物情報記憶部５に反映される。

第２の実施形態の情報処理システム１では、第１の実施形態の場合と同様に、クライアント装置３にて入力された申込者情報が、サーバ装置２の不動産情報記憶部４にて照会される。この際、申込者情報に含まれる住所情報が、建物情報記憶部５の建物テーブルにて記録されていない場合に、所在地情報生成部ＰＡによって建物の所在地情報が生成され、申込者の住所となる建物が建てられていると推定される土地が特定される。サーバ装置２は、この推定された土地の所在・地番に基づいて、推定された土地に建てられた建物の登記情報を取得し、取得された登記情報により建物レコードを生成する（あるいは、既に存在する建物レコードに反映する）ようになっている。

そしてクライアント装置３は、新しく生成された１又は複数の建物レコード（登記情報が反映された建物レコード）の「所有者」フィールドに記録された内容と、申込者の氏名情報とを確認し、第１の実施形態の場合と同様に所有判定等を実行し与信評価を行う。

以下においては、図１０を用いて、第２の実施形態の情報処理システム１における住所存在性判定処理についてのフローを説明する。

図１０で示されるように、第２の実施形態の住所存在性判定処理では、まず、申込者が記載した住所情報をキーとしてデータベース（建物情報記憶部５）にて建物レコードが特定されるか否かが判断される。このＳ９０１において建物が検索された場合には、原則的にそのまま処理を終了する（必要に応じて登記情報を取得して建物レコードの更新処理をする）。そしてＳ９０１において建物が特定されなかった場合にはＳ９０２に進み、当該建物が住居表示地区の自治体に属するか、あるいは、地番表示地区の自治体に属するかが判断される。そして住居表示地区に属する場合（Ｓ９０３）には、所在地情報生成部ＰＡは、申込者の住所情報と同一街区内となる各筆において付される可能性のある住居番号を生成して各土地レコードの所在地情報のフィールドに格納する。また、地番表示地区に属する場合（Ｓ９０４）には、所在地情報生成部ＰＡは、申込者の住所情報と同一の町・字と地番を備えた土地レコードにおいて、建物の所在地情報を生成する（つまりＳ９０４の場合には、土地の地番等に基づいて所在地情報たる潜在的な家屋番号が生成され、かつ、住所情報に対応する土地がそのまま特定されることになるため、住所情報と、地番と、家屋番号とが同様の内容を示すものとなる）。

Ｓ９０３およびＳ９０４のステップによって生成された所在地情報により、各筆に将来的に建てられる予定となる建物の住所（あるいは建てられた建物の住所）が求められ、土地特定部ＬＩは、申込者が記載した住所に対応する建物が存在しうる土地を特定する（Ｓ９０５）。

なお、Ｓ９０３とＳ９０５に関して、図９の例の住居番号「６」に対応する住所となる建物が位置する土地を特定する場合について説明をすると、まず、Ｓ９０３において、街区ポリゴン内の各土地（筆ポリゴン１〜６）の所在地情報を生成する。この場合において、筆ポリゴン１の土地における所在地情報は「２」「３」「４」「５」「６」となり、筆ポリゴン２の土地における所在地情報は「６」「７」「８」となる。そしてＳ９０５においては、土地特定部ＬＩは、住居番号「６」に対応する所在地情報を含む土地の特定をし、筆ポリゴン１及び２に対応する土地が特定されることとなる。

そしてＳ９０６では、登記情報取得部ＲＧは、Ｓ９０５において特定された土地に建てられた建物の登記情報を取得し、取得された登記情報を建物情報記憶部５にて反映されるようにする。

なお、第２の実施形態においては、クライアント装置３からの申込者情報の入力を受け入れて、住所に対応する建物レコードが存在しない場合に、所在地情報を生成して登記情報を取得するようになっている。しかしながら第２の実施形態の変形例としては、土地情報記憶部６の各筆に対応するレコードにおいて、クライアント装置３からの入力に関わらず予め所在地情報が導出・保持されていてもよいし、クライアント装置３から申込者情報が入力される都度、毎回、所在地情報を導出して登記情報を取得するようにしてもよい。

第２の実施形態の情報処理装置１は、上述のような点以外については第１の実施形態の情報処理装置１と同様であり、この同様である点についての説明は適宜省略するものとする。

[第３の実施形態]
次に、本発明の第３の実施形態について説明をする。上記の各実施形態においては、実存する建物については登記が存在することが前提となっている。しかしながら将来的な譲渡を予定していない等の建物の場合には、その所有者が必ずしも登記をしないという現状がある。

所有者による登記がない場合には、法務局から登記情報自体を取得できないにもかかわらず、例えば航空写真においては、建物の存在が確認されることとなる。このため建物の地図上における座標を示す建物座標情報（例えば、建物ポリゴン）のみによって生成された建物レコードが存在しうることとなり、当該建物レコードでは、住所や家屋番号等についての情報が未整備となっていることが想定される。

そこで第３の実施形態の情報処理装置１では、第２の実施形態のサーバ装置２がさらに建築計画概要書情報取得部を有しており、建築計画概要書情報取得部は、インターネット回線を通じて自治体にアクセスし建築計画概要書情報を取得する。本実施形態における建築計画概要書情報取得部は、例えば、Ｓ９０６において登記情報取得部ＲＧが建物の登記情報を取得できなかった場合に、建築計画概要書情報の取得を試行するものとなっている。また、建築計画概要書情報は、その対象となる建物座標情報（建物の空間的座標および形状を示す建物ポリゴン、あるいは建物の空間的な代表点座標を示す情報等）と、対象となる建物が建てられた土地に関する情報（具体的には、土地の所在・地番を示す情報）とに基づいて取得されるものとなっている。具体的には、建築計画概要書情報取得部は、不動産情報記憶部において記録された建物ポリゴンと、当該建物ポリゴンに対応（重複）する筆ポリゴンが関連付けられた土地レコードに含まれる情報に基づいて、建築計画概要書情報の取得をする。

この建築計画概要書は、建築主事のいる市町村において閲覧できる書類であって、建築計画概要書情報は当該書類に記載された情報を電子化したものとなっており、建物の登記がない場合であっても、建設された建物であれば必ず存在する書類・情報となっている。建築計画概要書情報は、具体的には、建築物の概要や検査等の属性情報のみならず、建築物の所有者や、当該建築物が建築される土地の所在・地番等を含むものとなっており、当該建築物に対して将来的に付される住所情報も含むことがある。このような建築計画概要書情報を用いることで、建物の登記が存在しない場合であっても建物が存在するか否かや建物の建築主（すなわち、建物の所有者）等の属性情報を確認することができる。

図１１は、第３の実施形態における住所存在性判定処理のフローを示す図である。同図で示されるように、第３の実施形態における住所存在性判定処理のフローは、Ｓ９０１〜Ｓ９０５のステップにおいて第２の実施形態と同様であり、Ｓ９０５以降のステップにおいて相違している。

Ｓ９０５において、申込者が記載した住所に対応する建物が存在する土地が特定された後、Ｓ９１０においては、特定された土地で建設された建物の登記情報が取得されたか否かが判断される。そしてＳ９１１においては、Ｓ９１０において取得された建物の登記情報を、建物情報記憶部５にて記録された建物レコードに反映する。

一方、Ｓ９１０において、Ｓ９０５で特定された土地に建設された建物の登記情報が取得されなかった場合には、インターネット回線を通じて当該特定された土地を管理する自治体にアクセスし、建築計画概要書情報の取得をする（Ｓ９１２）。建築計画概要書情報が取得された場合には、Ｓ９１３に進んで、取得された情報に基づいて建物情報記憶部５の建物レコードに反映をしつつ、当該建物レコードにおける「建築計画概要書の有無」のフィールドに「有」を書き込む。また、建築計画概要書情報が取得されなかった場合には、Ｓ９１４に進んで、申込者が記載した住所に対応する建物の建築計画概要書情報が存在しないとの判断をし、当該建物レコードにおける「建築計画概要書」のフィールドに「無」を書き込む。なおＳ９１４における建築計画概要書情報が存在しないとの判定に基づいて、申込者が記載した住所の建物自体が存在しないものと判定をし、与信査定を低くするようにしてもよい。

なお、Ｓ９０５においては１又は複数筆の土地が特定されてもよく、Ｓ９１０において、このうちのいずれかの土地における建物の登記情報が取得されなかった場合に、Ｓ９１２等に進んで、建物の登記情報が取得されなかった土地に建てられた建物の建築計画概要書情報を取得し、建物情報記憶部５に反映をするようにしてもよい。

なお、Ｓ９１２において、建築計画概要書情報取得部は、Ｓ９０５において特定された土地を特定するための情報（所在・地番）と、Ｓ９０５において特定された土地の筆ポリゴンに重複して、筆界内における建物の位置を示す情報である建物ポリゴンとを不動産情報記憶部４から取得をして、これらを自治体に送信して建築計画概要書情報を取得する。第３の実施形態においては、航空写真等に基づいて導出された建物ポリゴンにより建物レコードが生成されて、建築計画概要書情報を取得する際に建物の水平輪郭線を示す建物ポリゴンが用いられているが、他の方法によって取得された建物座標情報が用いられてもよい。

なお、建築計画概要書情報としては、サーバ装置２から自治体への要求の直後に取得されるのが望ましいが、その取得までに一定の時間がかかることも想定される。このような場合には、例えば、建築計画概要書を申請中である旨を示す情報を建物レコードの「建築計画概要書の有無」のフィールドにおいて記録し、クライアント装置３における与信評価が保留されるようにしてもよい。

なお、第３の実施形態の変形例としては、クライアント装置３が、サーバ装置２から土地を特定するための情報と、当該土地の建物ポリゴンとを取得し、これらに基づいて、建築計画概要書情報の取得申請用のデータや書面を出力するようにしてもよい（情報処理システム１において、建築計画概要書情報の取得申請用の書面を出力する手段を備えるようにしてもよい）。自治体による建築計画概要書情報のデジタル化が進展しておらず、サーバ装置２がネットワーク経由で取得できないような場合には、このような取得申請書面を自治体に提出し、別途、建築計画概要書を取得することが考えられる。取得された建築計画概要書は、サーバ装置２の管理者、あるいは、クライアント装置３の使用者により、その内容が入力されて、建物情報記憶部５の建物レコードに反映されるようにすればよい。

第３の実施形態の情報処理システム１は、上記のような観点を除いて第２の実施形態と同様であり、この同様である点については説明を適宜省略するものとする。なお第３の実施形態の情報処理システム１において建築計画概要書情報としては、登記情報取得部ＲＧによる登記情報の取得の有無にかかわらず画一的に取得されるようにしてもよく、この場合には、所在地情報生成部ＰＡや土地特定部ＬＩがサーバ装置２において存在しておらずともよい。

[その他]
なお、上記の第１の実施形態においては、申込者がクレジットカード等の契約時に入力をした住所情報をキーとして建物レコードが検出されなかった場合に、架空の住所であると判定をして与信査定を低くするようになっている。しかしながら第２の実施形態や第３の実施形態では、住所情報をキーとして建物レコードが検出されなかった場合であっても、所在地情報を生成して住所情報に対応する土地を特定し、特定された土地における登記情報や建築計画概要書情報を取得するものとなっている。第２の実施形態および第３の実施形態においては、申込者の住所情報に基づいて土地さえも特定することができなかった場合等において、実在しない架空の住所を入力したものと判定をする。

なお、上記の第２の実施形態や第３の実施形態においては、申込者の住所情報に対応して、建物の登記情報や建築計画概要書情報が複数取得されて、申込者の住所情報に対応する建物レコードの複数候補が取得されることも想定される。情報処理システム１としては、各建物レコードにおける「所有者」のフィールドに書き込まれた情報と、申込者の氏名情報等に基づいて、複数候補の建物レコードのうちから、申込者等が所有する建物に対応する建物レコードを特定するようにしてもよい。またこのように、申込者の住所に対応する建物を複数候補のうちから特定する場合には、申込者情報に建物に関する情報をさらに含ませて、これにより精度の高い特定が行えるようにしてもよい。

なお、上記の各実施形態では、土地レコードと建物レコードが別々のテーブルにて記録されているが、本発明はこのような態様に限定されず、例えば、土地レコードと建物レコードが、不動産情報記憶部４にて保持される共通のテーブルにて含まれていてもよい。この場合には、当該共通のテーブル内にて、土地レコードと建物レコードを区別するためのフィールドが設けられるようにしてもよい。また、上記の各実施形態における情報処理システム１は、サーバ装置２とクライアント装置３とがネットワークで接続されて構成されているが、ネットワークを介さずに１つの端末によって構成されても良い。また、サーバ装置２と、不動産情報記憶部４とがネットワークを介して構成されるようにしても良い。

なお、上記の各実施形態では、申込者の住所情報がクライアント装置３を介して取得されてサーバ装置２の不動産情報記憶部４にて照会されるようになっている。しかしながら、例えば、申込者の住所情報としては、携帯端末やＰＣ端末、ＡＴＭ端末等にて入力されてクライアント装置３で中継され、さらにサーバ装置２の不動産情報記憶部４にて照会された後に、中継されたクライアント装置３にて所有状況が判定され、住所情報が入力された申込者の端末にその結果等（クレジットカード契約の可否など）が提供されるようになっていてもよい。

本発明は、上述した各実施形態に限定されるものではなく種々の変形が可能であり、さらに、各実施形態を適宜組み合わせた構成としてもよいことは言うまでもない。

１情報処理システム、２サーバ装置、３クライアント装置、４不動産情報記憶部、５建物情報記憶部、６土地情報記憶部、７ポリゴン情報記憶部、ＲＧ登記情報取得部、ＯＧ申込者情報取得部、ＡＱ建物情報問い合わせ部、ＰＪ所有状況判定部、Ｐ１住所存在性判定部、Ｐ２所有判定部、Ｐ３供担性判定部、ＰＡ所在地情報生成部、ＬＩ土地特定部。

Claims

登記の一単位となる建物に対応するレコードと、一筆の土地に対応する筆ポリゴンを含むレコードと、１又は複数の前記筆ポリゴンに対応するポリゴンであって複数の基礎番号が設定されている街区ポリゴンと、を記録する不動産情報記憶部を備えた情報処理システムであって、
前記一筆の土地に対応する前記筆ポリゴンと、前記街区ポリゴンと、に基づいて、当該一筆の土地に対応付けられる前記基礎番号を特定する基礎番号特定手段と、
住所情報の入力を受け付ける住所情報受付手段と、
前記住所情報に含まれる住居番号に対応する前記基礎番号に対応付けられている前記土地を特定する土地特定手段と、
前記土地特定手段によって特定された土地に建てられた建物の登記情報を取得する登記情報取得手段と、
を有することを特徴とする情報処理システム。
登記の一単位となる建物に対応するレコードと、一筆の土地に対応する筆ポリゴンを含むレコードと、１又は複数の前記筆ポリゴンに対応するポリゴンであって複数の基礎番号が設定されている街区ポリゴンと、を記録する不動産情報記憶部を備えた情報処理システムにおける情報処理方法であって、
前記一筆の土地に対応する前記筆ポリゴンと、前記街区ポリゴンと、に基づいて、当該一筆の土地に対応付けられる前記基礎番号を特定する基礎番号特定ステップと、
住所情報の入力を受け付ける住所情報受付ステップと、
前記住所情報に含まれる住居番号に対応する前記基礎番号に対応付けられている前記土地を特定する土地特定ステップと、
前記土地特定ステップによって特定された土地に建てられた建物の登記情報を取得する登記情報取得ステップと、
を有することを特徴とする情報処理方法。
登記の一単位となる建物に対応するレコードと、一筆の土地に対応する筆ポリゴンを含むレコードと、１又は複数の前記筆ポリゴンに対応するポリゴンであって複数の基礎番号が設定されている街区ポリゴンと、を記録する不動産情報記憶部を備えた情報処理システムのコンピュータを、
前記一筆の土地に対応する前記筆ポリゴンと、前記街区ポリゴンと、に基づいて、当該一筆の土地に対応付けられる前記基礎番号を特定する基礎番号特定手段、
住所情報の入力を受け付ける住所情報受付手段、
前記住所情報に含まれる住居番号に対応する前記基礎番号に対応付けられている前記土地を特定する土地特定手段、
前記土地特定手段によって特定された土地に建てられた建物の登記情報を取得する登記情報取得手段、
として機能させるためのプログラム。