JP7421271B2 - 企業間情報連携システムおよび企業間情報連携方法 - Google Patents

Description

本発明は、概して、不動産サービスを支援する技術に関する。

不動産サービスとして、例えば、物件の内覧サービスがある。内覧サービスを提供するにあたり、一般に、内覧サービスを提供する不動産業者は、内覧サービスの申込者に対して、申込者の氏名や年齢といった個人情報の入力を求める。

しかし、申込者にとって、個人情報の入力は面倒であると考えられる。

一方、不動産業者にとっては、個人情報の入力が申込者にとって面倒であるということが内覧サービスの利用促進の妨げになっていることが考えられる。また、不動産業者は、内覧サービスの申込の際に申込者により入力された個人情報を信用せざるを得ないという問題もある。

このような問題を解決する方法として、組織をまたいだ情報連携の利用が考えられる。組織をまたいだ情報連携においては、個人の認証とその連携が課題になる。

例えば、特許文献１には、「組織内の個人認証が可能な汎用的なシステムを提供する。ユーザ端末からアクセスされるＷＥＢサーバなどのオンラインデータ処理システムと、ネットワークを介して接続される認証機関システムとから構成される。オンラインデータ処理システムは、ユーザ端末から送信される電子証明書を受信する電子証明書受信手段と、認証機関システムとの間でデータ送受信を行いユーザ認証を行う認証手段とを含む。認証機関システムには、認証データベースが備えられ、企業コード等の業種識別データと、業種と個人とを関連付けることにより組織内の個人を認証するための個人認証データとが記憶される。認証データベースから抽出された、組織内の個人の権限情報を少なくとも含む認証情報に基づきユーザ認証を行う。」と記載されている。

国際公開第２００３／１０５００２号

特許文献１に記載の技術によれば、オンラインデータ処理システムが、外部の認証機関システムが持つデータを用いて個人認証を行うことができる。

しかし、これは、外部の認証機関システムに存在するデータを個人認証に利用することを開示しているにすぎない。特許文献１は、組織をまたいで個人情報を連携させるための技術的手段を開示も示唆もしていない。故に、特許文献１は、不動産の内覧サービスの提供に関する課題を解決する手段を開示も示唆もしていない。

上述の課題は、内覧サービス以外の不動産サービスについてもあり得る。

複数のノード装置で構成された分散型台帳システムに、不動産業者と通信事業者とを含んだ複数の組織にそれぞれ対応した複数の装置が通信可能に接続される。不動産サービスの申込に必要とされる個人情報の連携元として、通信事業者が採用される。連携対象の個人情報は、分散型台帳システム経由で行われる。通信事業者装置から不動産業者装置へ分散型台帳システムを経由した個人情報の連携は、不動産業者装置と通信事業者装置との両方が個人情報の連携をユーザが要求していることを確認し、且つ、通信事業者装置に、通信事業者ユーザＩＤ（通信事業者が管理するユーザＩＤ）と不動産業者ＩＤ（連携先組織の組織ＩＤ）の両方について認証がされた場合に行われる。

不動産業者と通信事業者といった異なる組織をまたいだ情報連携を実現し以って不動産サービスの支援を実現することができる。

本発明の一実施形態に係るシステム全体の構成例を示す図である。 本実施形態で行われる処理の流れの一例の一部を示す図である。 本実施形態で行われる処理の流れの一例の残りを示す図である。 内覧候補ＵＩの一例を示す図である。 申込受付ＵＩの一例を示す図である。 ログインＵＩの一例を示す図である。 申込実行ＵＩの一例を示す図である。 組織間情報連携基盤システムの構成例を示すブロック図である。 認証情報生成サーバの構成例を示すブロック図である。 組織の装置におけるＤＢのエントリの構成例を示す図である。 情報連携ＤＢのエントリの構成例を示す図である。

以下の説明では、ＫＹＣ（Know Your Customer）に代表される情報を企業間で情報連携を行う旨が記載されており、各種法令に基づいた（例えばユーザの同意等）、適切な取扱いを行う。

また、以下の説明では、「インタフェース装置」は、一つ以上のインタフェースデバイスでよい。当該一つ以上のインタフェースデバイスは、下記のうちの少なくとも一つでよい。
・一つ以上のＩ／Ｏ（Input/Output）インタフェースデバイス。Ｉ／Ｏ（Input/Output）インタフェースデバイスは、Ｉ／Ｏデバイスと遠隔の表示用計算機とのうちの少なくとも一つに対するインタフェースデバイスである。表示用計算機に対するＩ／Ｏインタフェースデバイスは、通信インタフェースデバイスでよい。少なくとも一つのＩ／Ｏデバイスは、ユーザインタフェースデバイス、例えば、キーボードおよびポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイスとのうちのいずれでもよい。
・一つ以上の通信インタフェースデバイス。一つ以上の通信インタフェースデバイスは、一つ以上の同種の通信インタフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インタフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ」は、一つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも一つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。

また、以下の説明では、「永続記憶装置」は、一つ以上の永続記憶デバイスである。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）であり、具体的には、例えば、ＨＤＤ（Hard Disk Drive）またはＳＳＤ（Solid State Drive）である。

また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。

また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサデバイスである。少なくとも一つのプロセッサデバイスは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサデバイスであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサデバイスでもよい。少なくとも一つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも一つのプロセッサデバイスは、処理の一部または全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）またはＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサデバイスでもよい。

また、以下の説明では、「ｋｋｋ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡまたはＡＳＩＣ）によって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置および／またはインタフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機または計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分を使用し、同種の要素を区別して説明する場合は、参照符号を使用することがある。例えば、ノード装置を特に区別しないで説明する場合には、「ノード装置３０」と記載し、個々のノード装置を区別して説明する場合には、「ノード装置３０Ｓ」、「ノード装置３０Ｋ」のように記載することがある。

以下、本発明の一実施形態を図面に基づいて説明する。なお、以下の実施形態では、不動産サービスとして、物件の内覧サービスを例に取るが、本発明は、内覧サービス以外の不動産サービスについても適用可能である。

図１は、本発明の一実施形態に係るシステム全体の構成例を示す図である。なお、本実施形態の説明（少なくとも図１～図７の説明）では、下記が採用される。
・「ＢＣ」は、ブロックチェーンの略語である。
・「ＤＢ」は、データベースの略語である。
・「Ｃ－ＩＤ」は、通信事業者（例えば通信キャリア）がユーザに割り振ったユーザＩＤ（通信事業者ユーザＩＤの一例）を意味する。例えば、「Ｃ_α－ＩＤ」は、通信事業者がユーザαに割り振ったユーザＩＤを意味する。
・「Ｏ－ＩＤ」は、ＢＣ基盤２０においてユーザを識別するためのユーザＩＤ（共通ユーザＩＤの一例）を意味する。例えば、「Ｏ_α－ＩＤ」は、ＢＣ基盤２０においてユーザαを識別するためのユーザＩＤを意味する。Ｏ－ＩＤは、ユーザの公開鍵でよく、例えばオープンＩＤでよい。
・「Ｐ－ＩＤ」は、ＢＣ基盤２０に通信可能に接続されている組織（組織間情報連携基盤システム１０１に参加している組織）の組織ＩＤを意味する。
・「組織」は、典型的には、企業を意味するが、同一企業内の個々の組織でもよい。
・不動産業者に関する要素には、必要に応じて「Ｓ」が付される。例えば、不動産業者に関する要素の参照符号の末尾には、必要に応じて「Ｓ」が付される。また、例えば、「Ｐ_Ｓ－ＩＤ」は、不動産業者の組織ＩＤを意味する。
・通信事業者に関する要素には、必要に応じて「Ｋ」が付される。例えば、通信事業者に関する要素の参照符号の末尾には、必要に応じて「Ｋ」が付される。また、例えば、「Ｐ_Ｋ－ＩＤ」は、通信事業者の組織ＩＤを意味する。
・「ＫＹＣ」は、Know Your Customerの略であり、個人情報を含む情報を意味してよく、本実施形態では、個人情報それ自体を意味する。従って、以下の説明では、「個人情報」と「ＫＹＣ」は同義である。また、「ＫＹＣ」の前に付される符号は、当該ＫＹＣを管理する組織を意味する。例えば、「Ｋ－ＫＹＣ」は、通信事業者が管理する個人情報を意味する。なお、「Ｋ_α－ＫＹＣ」は、通信事業者が管理する個人情報のうちユーザαの個人情報を意味する。また、「個人情報」の定義は、例えば、改正個人情報保護法に準じ、生存する個人（ユーザ）に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるものでよい。

複数のノード装置３０で構成されたＢＣ基盤２０に、不動産業者と通信事業者（例えば通信キャリア）とを含んだ複数の組織にそれぞれ対応した複数の装置１０が、例えばインターネットのような通信ネットワーク（図示せず）を介して、通信可能に接続される。

内覧サービスの申込に必要とされるＫＹＣの連携元として、通信事業者が採用される。通信キャリアのような通信事業者は、一般に、通信事業者が提供する通信サービスの利用（例えば携帯電話機の利用）のための契約を交わしている。通信事業者において管理されているＫＹＣは、そのような契約のために入力された情報である。また、通信事業者では、当該通信事業者と契約している各ユーザについて、通信サービスの利用に伴い課金された金額の支払いの状況も管理されている。このような理由から、通信事業者において管理されているＫＹＣは信頼性が高いと考えられる。内覧サービスの申込に必要とされるＫＹＣの連携元が、そのような信頼性の高いＫＹＣであるため、不動産業者にとって、一見のユーザであっても、安心して内覧サービスを提供し易い。また、そのようなＫＹＣの連携は、後述するようにユーザの意思により行われるため、不動産業者は、内覧サービスの申込をしたユーザが物件を購入または借りることを真面目に検討していると推測することができる。一方、ユーザにとっては、内覧サービスの申込の都度にＫＹＣを入力しなくても不動産業者が必要とするＫＹＣが提供されるため、内覧サービスの申込の負担が低減される。

また、連携対象のＫＹＣは、ＢＣ基盤２０に格納される。すなわち、ＢＣ基盤２０経由でＫＹＣのような連携対象情報が連携される。ＢＣ基盤２０は、分散型台帳システム（分散型台帳技術が適用された計算機システム）の一例であり、例えば、非中央集権的な計算機システムである。情報連携の一つの方法としては、第１の組織に連携対象の情報を集約し各第２の組織が第１の組織から情報を取得するといった方法があり得るが、このような方法は、資本関係の無い組織間や、競合関係にある組織間に適用することは難しく、つまり、汎用性が低い。ＢＣ基盤２０は、各ノード装置３０が同じ情報を持ち、故に、同じ情報を参照可能である。このため、ＢＣ基盤２０が連携対象の情報を持つ仕組みを採用することが、組織をまたいでＫＹＣを連携することの実現に貢献する要素の一つとなる。

また、ＢＣ基盤２０では、署名と共に情報が書き込まれる。このため、連携に際して読み出された情報が、いずれの組織によって書き込まれた情報であるかを把握することもできる。

また、ＢＣ基盤２０が利用されることで、ＫＹＣのセキュアな連携を実現することができる。すなわち、ＢＣ基盤２０において、Ｏ_α－ＩＤが発行され、Ｏ_α－ＩＤに、ユーザαにより許諾され且つ正当な連携元からのＫＹＣが紐付けられる。Ｏ_α－ＩＤを特定できなければ、ユーザαのＫＹＣを特定することができない。Ｏ_α－ＩＤは、ユーザα以外には、ユーザαについてＫＹＣの連携元と連携先だけが知る。結果として、ＫＹＣのセキュアな連携が実現される。

通信事業者装置１０Ｓから不動産業者装置１０ＫへＢＣ基盤２０を経由したＫ_α－ＫＹＣの連携は、不動産業者装置１０Ｓと通信事業者装置１０Ｋとの両方がＫ_α－ＫＹＣの連携をユーザαが要求（承認）していることを確認し、且つ、通信事業者装置１０Ｋに、Ｃ_α－ＩＤとＰ_Ｓ－ＩＤの両方について認証がされた場合に行われる。連携元と連携先の一方のみからの要求でＫＹＣは連携されない。具体的には、連携元が、ユーザαの意思と連携先が組織間情報連携基盤システム１０１への正当な参加組織であることとの両方を確認できたときに、連携元からＫ_α－ＫＹＣがＢＣ基盤２０に書き込まれ、ユーザαの意思を確認した連携先によりＢＣ基盤２０からＫ_α－ＫＹＣが読み出される。別の言い方をすれば、Ｋ_α－ＫＹＣの開示の範囲が、ユーザαの意思が確認された組織の範囲に制限される。これも、Ｋ_α－ＫＹＣのセキュアな連携に貢献する。

以下、本実施形態を詳細に説明する。なお、ユーザ端末７０は、ユーザ毎に存在してよいが、図１には、ユーザαのユーザ端末７０αが例示される。ユーザ端末７０αは、典型的には計算機であり、本実施形態ではスマートフォンであるが、それに代えて、デスクトップ型、ラップトップ型またはタブレット型のパーソナルコンピュータのような他種の計算機が採用されてよい。

組織間情報連携基盤システム１０１は、ＢＣ基盤２０に通信可能に接続される複数の装置１０を含む。装置１０は、一つ以上の物理的な計算機で構成されていてもよいし、クラウド基盤（複数の物理的な計算リソース）のような計算機システム上に実現されるシステムでもよい。装置１０（または装置１０のベースとなる計算機システム）は、インタフェース装置、記憶装置およびそれらに接続されたプロセッサを有する。

例えば、不動産業者装置１０Ｓは、ユーザ端末７０αのようなＦＥ（フロントエンド）側のデバイスとのやり取りを制御するＦＥ制御部１６Ｓと、ＢＣ基盤２０のようなＢＥ（バックエンド）側のデバイスとのやり取りを制御するＢＥ制御部１７Ｓとを有する。また、例えば、不動産業者装置１０Ｓは、Ｐ_Ｓ－ＩＤ、不動産ＤＢ１１、ユーザＤＢ１２Ｓおよび組織ＤＢ１３Ｓといった情報を保持する。不動産ＤＢ１１は、内覧が可能な物件に関する情報（例えば、部屋、間取りおよび家賃に関する情報）を含む。ユーザＤＢ１２Ｓは、不動産業者のユーザに関する情報を含む。組織ＤＢ１３Ｓは、組織間情報連携基盤システム１０１に関している各組織に関する情報（例えば、Ｐ－ＩＤ）を含む。

また、例えば、通信事業者装置１０Ｋは、ユーザ端末７０αのようなＦＥ側のデバイスとのやり取りを制御するＦＥ制御部１６Ｋと、ＢＣ基盤２０のようなＢＥ側のデバイスとのやり取りを制御するＢＥ制御部１７Ｋとを有する。また、例えば、通信事業者装置１０Ｋは、Ｐ_Ｋ－ＩＤ、ユーザＤＢ１２Ｋおよび組織ＤＢ１３Ｋといった情報を保持する。ユーザＤＢ１２Ｋは、通信事業者のユーザ（典型的には契約者）に関する情報（例えば、ユーザ毎にＣ_α－ＩＤ、パスワード、ＫＹＣおよび支払状況等を示す情報）を含む。組織ＤＢ１３Ｋは、組織間情報連携基盤システム１０１に関している各組織に関する情報（例えば、Ｐ－ＩＤ）を含む。

ＢＣ基盤２０において、ノード装置３０は、一つ以上の物理的な計算機で構成されていてもよいし、クラウド基盤（複数の物理的な計算リソース）のような計算機システム上に実現されるシステムでもよい。ノード装置３０内で複数の計算機において分散合意が行われてもよい。ノード装置３０は、インタフェース部３１と、分散台帳３２とを有する。インタフェース部３１は、書込み要求や読出し要求のような要求を受け付け、当該要求に応答して、分散台帳３２に対する情報の読み書きを行う。なお、本実施形態では、分散台帳３２における一つのエントリを「データセット」と呼ぶ。「データセット」は、アプリケーションプログラムのようなプログラムから見た一つの論理的な電子データの塊であり、例えば、レコード、キーバリューペアおよびタプル等のうちのいずれでもよい。データセットに、Ｏ－ＩＤと、Ｏ－ＩＤに紐付けられるＫＹＣとが含まれる。分散台帳３２には、データセット単位で情報が追加されるものとする。また、ＢＣ基盤２０において、ノード装置３０Ｓは、不動産業者が管理するノード装置３０であり、ノード装置３０Ｋは、通信事業者が管理するノード装置３０である。ＢＣ基盤２０に書き込まれた情報は、ＢＣ基盤２０で採用されている分散合意アルゴリズムに従い、ノード装置３０Ｓの分散台帳３２Ｓにもノード装置３０Ｋの分散台帳３２Ｋにも書き込まれるものとする。

以下、本実施形態で行われる処理の流れの一例を説明する。なお、以下の説明において、ユーザ端末７０αが行う処理の少なくとも一部は、一例として、ユーザ端末７０αにインストールされたプログラム（例えば、不動産業者が提供するアプリケーションプログラム、あるいは、Ｗｅｂブラウザ）が実行されることによって行われる。

図２および図３は、本実施形態で行われる処理の流れの一例を示す図である。なお、ＩＤのような情報の流れは、図１にも示されているため、適宜に図１が参照されてもよい。また、以下の説明では、適宜、情報の一例としてＵＩ（User Interface）が使用される。

不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が、例えばユーザ端末７０αからの検索要求（例えば、物件の条件が指定された検索要求）に応答して、物件選択ＵＩ８１（図４参照）をユーザ端末７０αに提供する（Ｓ２０１）。物件選択ＧＵＩ８１は、例えばＧＵＩ（Graphical User Interface）であり、検索要求に応答して行った検索（不動産ＤＢ１１の検索）の結果を示す情報である検索結果情報７９を表示しユーザ所望の物件の選択を受けるためのＵＩである。検索結果情報７９は、例えば、検索要求にヒットした物件毎に部屋や家賃といった情報を含む。また、検索結果情報７９は、検索要求にヒットした物件毎に選択ＵＩ８０を含む。選択ＵＩ８０は、例えがＧＵＩ部品の一例としてのボタンであり、物件の選択を受け付けるＵＩである。

ユーザ端末７０αが、物件選択ＵＩ８１について物件を選択するユーザ操作（例えばユーザ所望の選択ＵＩ８０の押下）をユーザαから受け付ける（Ｓ２０２）。

不動産業者装置（ＦＥ制御部１６Ｓ）が、物件選択ＵＩ８１を介して物件が選択された場合に、申込受付ＵＩ８２（図５参照）をユーザ端末に提供する（Ｓ２０３）。申込受付ＵＩ８２は、例えばＧＵＩであり、選択された物件に関し内覧サービスの申込をＣ－ＩＤを利用して行うことを受け付けるためのＵＩである。申込受付ＵＩ８２は、例えば、内覧サービスの希望日の入力を受け付けるＵＩ８３と、Ｃ－ＩＤで内覧を申し込むことを指定するためのＵＩ８４とを有する。ＵＩ８３および８４は、例えばいずれもＧＵＩ部品である。申込受付ＵＩ８２（例えば、ＵＩ８４）には、不動産業者の組織ＩＤであるＰ_Ｓ－ＩＤが関連付けられている。また、申込受付ＵＩ８２（例えば、ＵＩ８４）には、リダイレクト先ＵＲＬ、具体的には、例えば、通信事業者装置１０ＫのログインＵＩ８５のＵＲＬが関連付けられている。

ユーザ端末７０αは、ＵＩ８４に対するユーザ操作（例えば、ＵＩ８４の押下）がユーザαによりされた場合、例えば上述のリダイレクト先ＵＲＬへリダイレクトする（Ｓ２０４）。その際、ユーザ端末７０αは、申込受付ＵＩ８２に関連付けられているＰ_Ｓ－ＩＤをリダイレクト先に送信する。ＵＩ８４に対するユーザ操作を不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が受け付けたことが、不動産業者装置１０Ｓがユーザαの意思（Ｋ_α－ＫＹＣの連携の意思）を確認したことに相当する。

通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、Ｃ－ＩＤを利用した申込が申込受付ＵＩ８２を介してされたユーザ端末７０αからＰ_Ｓ－ＩＤとＣ_α－ＩＤとを受け付けることになる。

具体的には、例えば、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、リダイレクト先のログインＵＩ８５（図６参照）を、ユーザ端末７０αに提供する（Ｓ２０５）。ログインＵＩ８５は、例えばＧＵＩであり、Ｃ－ＩＤの入力ＵＩ８６と、パスワードの入力ＵＩ８７と、ログイン要求を送信するために操作されるＵＩ８８（ＯＫボタン）とを有する。ＵＩ８６～８８の各々は、例えばＧＵＩ部品である。ＵＩ８６および８７の各々は、例えばテキストフィールドである。ユーザ端末７０αが保持するＣ_α－ＩＤが例えばＳ２０４のリダイレクトの際にユーザ端末７０αから通信事業者装置１０Ｋに転送されて、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）によりＵＩ８６にＣ_α－ＩＤが入力された状態で、ログインＵＩ８５がユーザ端末７０αに提供されてもよい。ユーザ端末７０αは、ＵＩ８６に対するＣ_α－ＩＤの入力と、ＵＩ８７に対するパスワードの入力とを、ユーザαから受け付け、その後に、ＵＩ８８に対するユーザ操作（例えばＵＩ８８の押下）を受け付ける。そのユーザ操作に応答して、ユーザ端末７０αは、入力されたＣ_α－ＩＤおよびパスワードが関連付けられたログイン要求を通信事業者装置１０Ｋに送信する。通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、当該ログイン要求を受信する。以上のようにして、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、ユーザ端末７０αからＰ_Ｓ－ＩＤとＣ_α－ＩＤとを受け付ける。なお、本実施形態では、当該ログイン要求が、Ｋ_α－ＫＹＣの連携の要求を兼ねるが、Ｋ_α－ＫＹＣの連携の要求が別途ユーザ端末７０αから通信事業者装置１０Ｋに送信されてもよい。通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）がＣ_α－ＩＤを受け付けたことが、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）がユーザの意思（Ｋ_α－ＫＹＣの連携の意思）を確認したことに相当する。

通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、Ｐ_Ｓ－ＩＤとＣ_α－ＩＤとを受け付けた場合に、Ｐ_Ｓ－ＩＤとＣ_α－ＩＤを用いた認証処理を行う（Ｓ２０７）。例えば、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、Ｐ_Ｓ－ＩＤと同じＰ－ＩＤが組織ＤＢ１３Ｋに存在するか否かをチェックすることで、Ｐ_Ｓ－ＩＤが正当か否か（連携先である不動産業者が正当な参加組織か否か）を判断する。また、例えば、通信事業者装置１０Ｋ（ＦＥ制御部１６Ｋ）が、入力されたパスワードと同じパスワードがユーザＤＢ１２ＫにおいてＣ_α－ＩＤと紐付いているか否かをチェックすることで、Ｃ_α－ＩＤおよびパスワードが正当か否かを判断する。Ｐ_Ｓ－ＩＤとＣ_α－ＩＤのいずれについても正当との判断結果が得られた場合、認証処理が成功である。

認証処理が成功の場合に、通信事業者装置１０Ｋにおいて、ＦＥ制御部１６Ｋが、Ｏ_α－ＩＤ（例えば、ユーザαの公開鍵）をユーザ端末７０αに送信し、且つ、ＢＥ制御部１７Ｋが、Ｃ_α－ＩＤに紐付いているＫ_α－ＫＹＣ（例えばユーザＤＢ１２Ｋから取得されたＫＹＣ）とＯ_α－ＩＤとを含んだデータセットをＢＣ基盤２０（具体的には、ノード装置３０Ｋの分散台帳３２Ｋ）に書き込む（Ｓ２０８）。より具体的には、当該データセットの書込み要求がノード装置３０Ｋに送信され、インタフェース部３１Ｋにより、当該書込み要求に応答して、当該データセットが分散台帳３２Ｋに書き込まれる。これにより、当該データセットはノード装置３０Ｓの分散台帳３２Ｓにも書き込まれる。

ユーザ端末７０αに送信されたＯ_α－ＩＤには、例えば、リダイレクト先ＵＲＬが関連付けられている。当該リダイレクト先ＵＲＬは、例えば、申込実行ＵＩ８９（図７参照）のＵＲＬである。Ｏ_α－ＩＤを受信したユーザ端末７０αは、当該リダイレクト先ＵＲＬにリダイレクトする（Ｓ２０９）。すなわち、ユーザ端末７０αは、不動産業者装置１０Ｓにアクセスする。その際、ユーザ端末７０αは、Ｏ_α－ＩＤを不動産業者装置１０Ｓに送信する。

不動産業者装置１０Ｓにおいて、ＦＥ制御部１６Ｓが、Ｏ_α－ＩＤを受け付け、ＢＥ制御部１７Ｓが、当該Ｏ_α－ＩＤに紐付いているＫ_α－ＫＹＣをＢＣ基盤２０（具体的には、ノード装置３０Ｓの分散台帳３２Ｓ）から読み出す（Ｓ２１０）。より具体的には、Ｏ_α－ＩＤが関連付けられた読出し要求がノード装置３０Ｓに送信され、インタフェース部３１Ｓにより、当該読出し要求に応答して、Ｏ_α－ＩＤに紐付いているＫ_α－ＫＹＣが分散台帳３２Ｓから読み出される。

不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が、読み出されたＫ_α－ＫＹＣのうち必要項目の情報が反映された申込実行ＵＩ８９（図７参照）を、ユーザ端末７０αに提供する（Ｓ２１１）。申込実行ＵＩ８９は、例えばＧＵＩであり、ユーザαの個人情報のうち必要項目の情報を必要とした内覧サービスの申込の実行を受け付けるためのＵＩである。申込実行ＵＩ８９は、例えば、必要項目に対応した入力ＵＩ（例えばテキストフィールド）９０Ａ～９０Ｅと、申込実行の指定を受け付けるＵＩ９１（ＯＫボタン）とを有する。入力ＵＩ９０Ａ～９０Ｅに、Ｋ_α－ＫＹＣのうち必要項目の情報が入力済の状態とされる。なお、ＵＩ９０Ａ～９０Ｅに、Ｋ_α－ＫＹＣに必要項目の情報が無い場合（例えばブランクのテキストフィールドがある場合）や変更すべき情報がある場合、ユーザαがマニュアルで必要情報を申込実行ＵＩ８９に入力する。

申込実行ＵＩ８９に必要な情報が入力済の場合、ユーザ端末７０αは、ＵＩ９１に対するユーザ操作をユーザαから受け付け、それに応答して、申込実行を不動産業者装置１０Ｓに指示する（Ｓ２１２）。

その指示（つまり内覧サービスの申込実行）を、不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が受け付けた場合、一連の申込処理が完了する（Ｓ２１３）。

以上の流れは一例である。

例えば、Ｓ２１３で、不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）は、ユーザαについて、申込実行ＵＩ８９に表示されている個人情報や、申込受付ＵＩ８２に入力された希望日や、内覧が希望された（選択された）物件に関する情報を、ユーザＤＢ１２Ｓに書き込んでよい。

また、例えば、申込受付ＵＩ８２が提供された後で、内覧希望の物件の検索や選択が行われてもよい。

また、Ｓ２１３で、不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が、内覧サービスの申込実行を受け付けた場合に電子的なキーをユーザ端末７０αに送信してよい。電子的なキーには、選択された物件のＩＤと、内覧サービスの利用可能時間帯（例えば、希望日を開始時刻とし開始時刻から一定期間（例えば２４時間）経過したときを終了時刻とした時間帯）を示す情報と、上記必要項目の情報の少なくとも一部（例えば、ユーザαの氏名、携帯電話番号および生年月日）とが関連付けられている。電子的なキーは、上記選択された物件の開錠が上記利用可能時間帯において有効なキーである。内覧可能な物件には、例えば、物理的なキーでの開錠／施錠に代えてまたは加えて、電子的なキーでの開錠／施錠が可能なシステムが採用されていてよい。電子的なキーは、例えば、ユーザ端末７０αに格納され、内覧可能な物件に設置されている非接触式のリーダにユーザ端末７０αを近づけることで、当該物件の開錠／施錠が行われてよい。電子的なキーには、セキュアに連携され信頼できるＫＹＣの少なくとも一部が関連付けられている。これにより、安心して不動産業者側の立ち合いが不要の内覧サービスを提供することができる。なお、物件で開錠および施錠の少なくとも一方が行われた場合に、ユーザ端末７０αから読み取られた電子的なキーに関連付いている情報の少なくとも一部が、不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）に送信され、ユーザＤＢ１２Ｓのような、不動産業者装置１０Ｓ（ＦＥ制御部１６Ｓ）が管理するＤＢに、内覧された物件と、当該物件を内覧したユーザαのＫＹＣの少なくとも一部とが紐付けられてよい。そのような情報を蓄積して分析をすることにより、いずれの物件がどのようなユーザにより興味を持たれたか等がわかり、結果として、不動産サービスの新たな技術的支援に貢献することが期待できる。

また、Ｓ２０７で、認証処理は、Ｃ_α－ＩＤについての認証に関し、Ｃ_α－ＩＤと共に入力された認証情報（例えば、パスワードおよび生体情報の少なくとも一方）を用いた一要素認証または多要素認証である第１段階の認証と、Ｃ_α－ＩＤに紐付いているＫ_α－ＫＹＣが示す連絡先（例えば、メールアドレスまたは携帯電話番号）へ発行した通知に基づく第２段階の認証とを含んでよい。第２段階の認証は、例えば、通知に記述されたワンタイムパスワードと同じワンタイムパスワードの入力を受け付け、入力されたワンタイムパスワードが当該通知に記述されたワンタイムパスワードと同じか否かを判断することでよい。

図８は、組織間情報連携基盤システム１０１の構成例を示すブロック図である。

組織間情報連携基盤システム１０１は、一例として、外部ネットワーク２２１に接続された複数の事業者システム２１１を含む。各事業者システム２１１は、内部ネットワーク２０５を介して接続された情報連携サーバ２０１と、アプリケーションサーバ２０２と、認証情報生成サーバ２０３と、ＤＢサーバ２０４とを含む。例えば、アプリケーションサーバ２０２、認証情報生成サーバ２０３およびＤＢサーバ２０４が、上述の装置１０に含まれていてよい。情報連携サーバ２０１が、ノード装置３０に含まれていてよい。

情報連携サーバ２０１は、外部ネットワーク２２１を通じて、他組織の（すなわち当該情報連携サーバ２０１を含む事業者システム２１１とは別の事業者システム２１１に含まれる）情報連携サーバ２０１との間での情報連携対象データの合意、ユーザのクライアントデバイス２２２に対する情報連携許諾伺い、および、他組織の情報連携サーバとの間での情報連携開始通知などの処理および通信を担う。また、情報連携サーバ２０１は、内部ネットワーク２０５を介して、アプリケーションサーバ２０２からの情報連携要求受信と、認証情報生成サーバ２０３への認証情報生成要求と、自組織の（すなわち当該情報連携サーバ２０１を含む事業者システム２１１に含まれる）ＤＢサーバ２０４への問い合わせと、の処理を担う。

アプリケーションサーバ２０２は、ユーザのクライアントデバイス２２２または組織内のデバイスを通じて任意のアプリケーション実行要求を受け、処理を実行する。本実施例では、上記の任意アプリケーションが、情報連携サーバ２０１に対して個人情報を問い合わせることを想定する。

認証情報生成サーバ２０３は、情報連携サーバ２０１からの要求を受けて、本人認証のために使用する認証情報を生成し、情報連携サーバ２０１に渡す。認証情報は、パスワード、公開鍵、または生体認証（例えば顔画像識別、指紋認証または静脈認証など）に対応する公開鍵、などのいずれの情報でもよく、必要な認証強度のものを選んで使用する。

ＤＢサーバ２０４は、自組織が元々保有していたデータを保持し、最初に情報連携ＤＢにユーザのデータを取り込む際に参照される。

外部ネットワーク２２１は、組織間の通信およびユーザのクライアントデバイス２２２の通信のための通信設備網である。内部ネットワーク２０５は、組織内で通信するための通信設備網である。外部ネットワーク２２１および内部ネットワーク２０５の通信設備網は、例えば、インターネット、イントラネット、有線または無線のＬＡＮ（Local Area Network）、ＷＡＮ（Wide Area Network）などである。

情報連携サーバ２０１、アプリケーションサーバ２０２、認証情報生成サーバ２０３、およびＤＢサーバ２０４は、各々が物理的な計算機によって構成されたサーバ装置であってもよいし、仮想マシンによって構成されてもよい。また、各サーバが、分散実行のため複数台で構成されてもよい。

さらに、上記の各サーバ装置の役割が混合されていてもよく、上記の各サーバの一部または全部が一つの装置に含まれてもよい。例えば、情報連携サーバ２０１と、アプリケーションサーバ２０２と、が一つの物理サーバまたは仮想サーバ上で構成されていてもよい。

図９は、認証情報生成サーバ２０３の構成例を示すブロック図である。

認証情報生成サーバ２０３は、入出力回路インタフェース５１２と、プロセッサ５１３と、入出力装置５１４と、記憶装置５１１と、これらを接続する内部通信線（例えば、バス）と、を含む。

入出力回路インタフェース５１２は、インタフェース装置の一例であり、通信設備網５０１と通信するための通信インタフェースデバイスである。通信設備網５０１は、例えば、内部ネットワーク２０５を構成するものである。

プロセッサ５１３が記憶装置５１１に格納された認証情報生成プログラム５２１を実行することによって、認証情報生成が実現される。

入出力装置５１４は、データの入力を受け付けたり、データを出力したり、あるいはその両方を行うための装置である。例えば、入出力装置５１４は、キーボードおよびマウスなどからの入力を受け付け、プロセッサからの情報をディスプレイに表示させる。

記憶装置５１１は、認証情報生成プログラム５２１を格納する。

認証情報生成プログラム５２１は、認証情報を生成する。認証情報は、パスワード、公開鍵、または、生体認証（顔画像識別、指紋認証または静脈認証など）に対応する公開鍵、などのいずれの情報でもよく、必要な認証強度のものを選んで使用する。このとき、例えば生体認証の場合は、認証情報生成プログラム５２１は生体認証を秘密鍵として対応する公開鍵を作る。このような場合、認証情報生成プログラム５２１は、必要に応じてユーザに対して情報入力を要求し、その入力をもとに公開鍵（Ｏ－ＩＤの一例）を生成する。

図１０は、各組織の装置１０におけるＤＢのエントリの構成例を示す図である。また、図１１は、情報連携サーバ２０１の情報連携ＤＢのエントリの構成例を示す図である。情報連携ＤＢは、図１１の各組織の装置１０におけるＤＢが持つエントリにおける情報を連携させたものである。

図１１によれば、ユーザαについて、組織Ｘの装置１０におけるＤＢエントリ６０１は、ＩＤ情報と公開鍵情報を持ち、データ項目として姓名、年齢の情報を持つ。また、ユーザαについて、組織Ｙの装置１０におけるＤＢエントリ６０２は、ＩＤ情報と公開鍵情報を持ち、データ項目として住所の情報を持つ。また、ユーザαについて、組織Ｚの装置１０におけるＤＢエントリ６０３は、ＩＤ情報を持ち、データ項目として姓、名、Ｚサービス使用回数、の情報を持つ。

これら組織Ｘ、Ｙ、Ｚのユーザαに関する個人情報を全て連携させたものが図１１に示す情報連携ＤＢエントリ７０１である。情報連携ＤＢエントリ７０１は、キーフィールドにおいて、組織ＸのＩＤ情報および公開鍵情報と、組織ＹのＩＤ情報および公開鍵情報と、組織ＺのＩＤ情報と、を保持する。情報連携ＤＢエントリ７０１は、データフィールドにおいて、組織Ｘが保持していた姓名、年齢と、組織Ｙが保持していた住所と、組織Ｚが保持していた姓、名、Ｚサービス使用回数と、を保持する。

この情報連携ＤＢエントリ７０１における情報を問い合わせるには、例えば、キーフィールドにおける少なくとも一つの情報要素が選択された上で、その公開鍵と対になる秘密鍵が提示されてよい。具体的には、例えば、組織Ｘが選択された場合、組織ＸのＩＤ情報でエントリが特定されたのち、組織Ｘの公開鍵と対になる秘密鍵が提示され、復号できた場合にのみデータフィールドへのアクセスが許可されてよい。

なお、ＩＤ情報と公開鍵情報が一組織のものに閉じている必要はなく、例えば組織ＺのＩＤ情報と組織Ｙの公開鍵情報に対応する秘密鍵を提示して、データフィールドへのアクセス許可を得ることができてもよい。また、登録された全てのＩＤ情報と全ての公開鍵情報に対応する秘密鍵との任意の組合せによってデータフィールドへのアクセス許可を得ることができてもよい。予めデータフィールドアクセスに有効なＩＤ情報および鍵情報の組合せリスト７０２を設けて、それに従ってもよい。

図１１に示す組合せリスト７０２の例は、組織ＸにおけるユーザのＩＤと組織Ｙにおいて当該ユーザに割り当てられている秘密鍵との組合せ、および、組織ＺにおけるユーザのＩＤと組織Ｘにおいて当該ユーザに割り当てられている秘密鍵との組合せも有効である（すなわちその組合せが入力された場合にも、該当するデータフィールドへのアクセスが許可される）ことを示している。

以上、本発明の一実施形態を説明したが、これは本発明の説明のための例示であって、本発明の範囲をこの実施形態にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実行することが可能である。

１０１…組織間情報連携基盤システム

Claims (8)

1. 複数のノード装置で構成された分散型台帳システムに通信可能に接続されており不動産業者と通信事業者とを含んだ複数の組織にそれぞれ対応した複数の装置を有し、
   前記複数の装置が、前記不動産業者の装置である不動産業者装置と、前記通信事業者の装置である通信事業者装置とを含み、
   前記不動産業者装置が、ユーザ所望の物件についての不動産サービスの申込を通信事業者ユーザＩＤを利用して行うことを受け付けるための情報である申込受付情報をユーザ端末に提供し、
   前記ユーザの前記通信事業者ユーザＩＤは、当該ユーザについて前記通信事業者が管理するユーザＩＤであり、
   前記申込受付情報には、前記不動産業者の組織ＩＤである不動産業者ＩＤが関連付けられており、
   前記通信事業者装置が、前記通信事業者ユーザＩＤを利用した申込が前記申込受付情報を介してされた前記ユーザ端末から、前記不動産業者ＩＤと、前記通信事業者ユーザＩＤとを受け付けた場合に、前記不動産業者ＩＤと前記通信事業者ユーザＩＤを用いた認証処理を行い、
   前記通信事業者装置が、
   前記ユーザについて前記分散型台帳システムに共通のＩＤである共通ユーザＩＤを、前記ユーザ端末に送信し、
   前記通信事業者装置が前記ユーザについて管理し前記通信事業者ユーザＩＤに紐付いている個人情報と、前記共通ユーザＩＤとを含んだデータセットを、前記分散型台帳システムに書き込み、
   前記不動産業者装置が、前記通信事業者装置から前記共通ユーザＩＤを受けた前記ユーザ端末から、前記共通ユーザＩＤを受け付け、
   前記不動産業者装置が、前記共通ユーザＩＤに紐付いており前記通信事業者装置により書き込まれた個人情報を前記分散型台帳システムから読み出し、
   前記不動産業者装置が、前記読み出された個人情報が反映された申込実行情報を、前記ユーザ端末に提供し、
   前記申込実行情報は、前記ユーザの個人情報のうち必要項目の情報を必要とした前記不動産サービスの申込の実行を受け付けるための情報であり、
   前記不動産業者装置が、前記申込実行情報を介して、前記不動産サービスの申込実行を受け付ける、
   システム。
2. 前記認証処理は、前記通信事業者が前記不動産業者を正当な参加組織であると判定する処理を含み、
   前記判定が成功した場合に、前記通信事業者装置は前記データセットを、前記分散型台帳システムに書き込む、
   請求項１に記載のシステム。
3. 前記不動産業者装置は、前記不動産サービスの申込実行を受け付けた場合に、前記ユーザ所望の物件のＩＤと前記不動産サービスの利用可能時間帯と前記必要項目の情報の少なくとも一部とが関連付けられており前記ユーザ所望の物件の開錠が前記利用可能時間帯において有効な電子的なキーを前記ユーザ端末に送信する、
   請求項１に記載のシステム。
4. 前記認証処理は、前記通信事業者ユーザＩＤについての認証に関し、
   前記通信事業者ユーザＩＤと共に入力された認証情報を用いた一要素認証または多要素認証である第１段階の認証と、
   前記通信事業者ユーザＩＤに紐付いている個人情報が示す連絡先へ発行した通知に基づく第２段階の認証とを含む、
   請求項１に記載のシステム。
5. 複数のノード装置で構成された分散型台帳システムに通信可能に接続されており不動産業者と通信事業者とを含んだ複数の組織にそれぞれ対応した複数の装置を有するシステムにより不動産サービスを支援する方法であって、
   （Ａ）不動産業者装置が、ユーザ所望の物件についての不動産サービスの申込を通信事業者ユーザＩＤを利用して行うことを受け付けるための情報である申込受付情報をユーザ端末に提供し、
   前記不動産業者装置は、前記複数の装置のうちの、前記不動産業者の装置であり、
   前記ユーザの前記通信事業者ユーザＩＤは、当該ユーザについて前記通信事業者が管理するユーザＩＤであり、
   前記申込受付情報には、前記不動産業者の組織ＩＤである不動産業者ＩＤが関連付けられており、
   （Ｂ）通信事業者装置が、前記通信事業者ユーザＩＤを利用した申込が前記申込受付情報を介してされた前記ユーザ端末から、前記不動産業者ＩＤと、前記通信事業者ユーザＩＤとを受け付けた場合に、前記不動産業者ＩＤと前記通信事業者ユーザＩＤを用いた認証処理を行い、
   前記通信事業者装置は、前記複数の装置のうちの、前記通信事業者の装置であり、
   （Ｃ）前記認証処理が成功の場合に、前記通信事業者装置が、
   （ｃ１）前記ユーザについて前記分散型台帳システムに共通のＩＤである共通ユーザＩＤを、前記ユーザ端末に送信し、
   （ｃ２）前記通信事業者装置が前記ユーザについて管理し前記通信事業者ユーザＩＤに紐付いている個人情報と、前記共通ユーザＩＤとを含んだデータセットを、前記分散型台帳システムに書き込み、
   （Ｄ）前記不動産業者装置が、前記通信事業者装置から前記共通ユーザＩＤを受けた前記ユーザ端末から、前記共通ユーザＩＤを受け付け、
   （Ｅ）前記不動産業者装置が、前記共通ユーザＩＤに紐付いており前記通信事業者装置により書き込まれた個人情報を前記分散型台帳システムから読み出し、
   （Ｆ）前記不動産業者装置が、前記読み出された個人情報のうち必要項目の情報が反映された申込実行情報を、前記ユーザ端末に提供し、
   前記申込実行情報は、前記ユーザの個人情報のうち必要項目の情報を必要とした前記不動産サービスの申込の実行を受け付けるための情報であり、
   （Ｇ）前記不動産業者装置が、前記申込実行情報を介して、前記不動産サービスの申込実行を受け付ける、
   方法。
6. 前記認証処理は、前記通信事業者が前記不動産業者を正当な参加組織であると判定する処理を含み、
   前記判定が成功した場合に、前記不動産業者装置は前記データセットを、前記分散型台帳システムに書き込む、
   請求項５に記載の方法。
7. （Ｈ）前記不動産業者装置が、前記不動産サービスの申込実行を受け付けた場合に、前記ユーザ所望の物件のＩＤと前記不動産サービスの利用可能時間帯と前記必要項目の情報の少なくとも一部とが関連付けられており前記ユーザ所望の物件の開錠が前記利用可能時間帯において有効な電子的なキーを前記ユーザ端末に送信する、
   請求項５に記載の方法。
8. 前記認証処理は、前記通信事業者ユーザＩＤについての認証に関し、
   前記通信事業者ユーザＩＤと共に入力された第１種の認証情報を用いた一要素認証または多要素認証である第１段階の認証と、
   前記通信事業者ユーザＩＤに紐付いている個人情報が示す連絡先へ発行した通知に基づく第２段階の認証と
   を含む、
   請求項５に記載の方法。

Images