JP2019160322A - 情報処理装置、情報処理方法、及びプログラム - Google Patents

Abstract

【課題】転居者に適した不動産を効率的に検索する情報処理装置、情報処理方法及びプログラムを提供する。【解決手段】不動産検索部３４における不動産検出条件生成部５２は、所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する。不動産抽出部５３は、複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する。不動産検出条件生成部５２による検索の対象となる前記データベースは、前記情報処理装置の管理者以外の者が管理するデータベースである。【選択図】図４

Description

本発明は、情報処理装置、情報処理方法、及びプログラムに関する。

日本国では、近年、自己所有する不動産に居住する人の割合が低下し、賃貸用不動産に居住する人の割合が増加している。
そこで、賃貸用不動産の検索、契約、入居等を補助する様々な手法が開発されている。例えば、特許文献１では、複数の不動産業者の不動産情報を一度に検索できるシステムが提案されている。

特開２００１−２９７１４２号公報

しかしながら、特許文献１に記載の不動産情報検索システムでは、膨大な不動産情報を検索する必要があり、転居者が検索する負担が大きいものであった。

本発明は、このような状況に鑑みてなされたものであり、転居者に適した不動産を効率的に検索することを目的とする。

上記目的を達成するため、本発明の一態様の情報処理装置は、
所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する検索条件生成手段と、
複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する不動産検索制御手段と、
を備える。

本発明によれば、転居者に適した不動産を効率的に検索することができる。

本発明の第１実施形態に係る情報処理装置を含む情報処理システムの構成を示す図である。 図１の情報処理システムのうちサーバのハードウェア構成の一例を示すブロック図である。 図２のサーバの機能的構成の一例を示す機能ブロック図である。 図３のサーバの機能的構成のうち、不動産検索部の詳細な機能的構成の一例を示す機能ブロック図である。 図４の不動産検索部により実行される不動産検索処理の流れを説明するフローチャートである。 社員が、図１の社員端末において、不動産検索処理に必要な情報を入力するための画面の一例を示す図である。 社員が、図１の社員端末において、図３の社員ＤＢに保存させる社員情報を入力するための画面の一例を示す図である。 図３の会社ＤＢに保存されている複数の会社毎の社内規程のリストの一例を示す図である。 図１の社員端末に表示される不動産情報の一例を示す図である。 図３のサーバを用いた不動産探し支援サービスであって、一般的な賃貸用不動産の検索サイト等でも社内規程に基づく検索が可能となる支援サービスの全体の概略を示す図である。 本発明の第２実施形態に係る情報処理装置を含む情報処理システムの適用対象となる各種サービスの概要を示すイメージ図である。 転居管理サービスと、借上社宅管理サービスとの夫々に、規程管理サービスを連携させた場合のイメージ図である。 本発明の情報処理装置の第２実施形態に係るサーバの機能的構成の一例を示す機能ブロック図である。 社員が承認者に対して入居申請を行う際に社員端末に表示されるＵＩの具体例を示す図である。 不動産業者が契約情報の入力を行う際に不動産会社端末に表示されるＵＩの具体例を示す図である。 借上社宅管理サービスを提供するサービス提供者が操作する提供者端末に表示されるＵＩの具体例を示す図である。 借上社宅管理サービスを提供するサービス提供者が操作する提供者端末に表示されるＵＩの具体例のうち、規程チェックのＵＩを示す図である。

以下、本発明の実施形態について、図面を用いて説明する。

［第１実施形態］
（システム構成）
図１は、本発明の第１実施形態に係る情報処理装置を含む情報処理システムの構成を示す図である。

まず、本発明の実施形態を説明するに先立ち、本発明の第１実施形態に係る情報処理装置を含む情報処理システムの適用対象となる転居管理サービス（以下、「本サービス」と呼ぶ）について簡単に説明する。
本サービスは、所定の会社に属する各社員の転勤等に際し、転居先の不動産探し、引越し手配、社内申請等を支援するサービスである。本サービスは、例えば、福利厚生の一環として、自社の社員等に借り上げ社宅等を利用させる会社（以下、単に「会社」と呼ぶ）に提供すると好適である。
本サービスには、例えば、転居先の不動産探しを支援するサービスが含まれる。このサービスは、社員が、入社、転勤、結婚、出産等により、転居が必要になった場合に、会社の社内規程（賃料、不動産の所在地、専有面積、間取り、駐車場の有無等）に適合する不動産を効率よく検索できるサービスである。

ここで、本サービスは、例えば、借上社宅管理サービスに付随するサービスであって良い。
借上社宅管理サービスとしては、例えば転貸方式による借上社宅管理サービス（以下、「借上社宅管理転貸サービス」と呼ぶ）を採用することができる。
この借上社宅管理転貸サービスは、本サービスの提供者が、１以上の家主から個別に不動産を賃借し、本サービスの利用者（会社）と包括して転貸借契約を締結し、本サービスの利用者（会社）の社員のための社宅として借上げ、その借上社宅の管理を契約当事者として行うサービスである。

若しくは、借上社宅管理サービスとしては、例えば代行方式による借上社宅管理サービス（以下、「借上社宅管理代行サービス」と呼ぶ）を採用することもできる。
この借上社宅管理代行サービスは、本サービスの提供者が、賃貸借にかかる新規契約及び更新等の契約締結業務や管理業務を代理権者として行うサービスである。

図１に示す情報処理システムは、本サービスの提供者により管理されるサーバ１と、会社の人事部等の担当者に使用される会社端末２と、当該会社に属するｎ人（ｎは１以上の任意の整数値）の社員の夫々により使用される社員端末３−１乃至３−ｎとを含むように構成される。
サーバ１と、会社端末２と、社員端末３−１乃至３−ｎとの夫々は、インターネット等の所定のネットワークＮを介して相互に接続されている。

なお、以下、社員端末３−１乃至３−ｎの夫々を個々に区別する必要がない場合、これらをまとめて「社員端末３」と呼ぶ。
また、図１は、１つの会社に対して本サービスが提供される場合を例としたものであるが、当然ながら、複数の会社に対して本サービスが提供されてもよい。その場合、複数の会社毎に、１台以上の会社端末２と、１人以上の社員により夫々使用される１台以上の社員端末３とが、情報処理システムに含まれる。

（ハードウェア構成）
図２は、図１の情報処理システムのうちサーバのハードウェア構成の一例を示すブロック図である。

サーバ１は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１２と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１３と、バス１４と、入出力インターフェース１５と、出力部１６と、入力部１７と、記憶部１８と、通信部１９と、ドライブ２０と、を備えている。

ＣＰＵ１１は、ＲＯＭ１２に記録されているプログラム、又は記憶部１８からＲＡＭ１３にロードされたプログラムに従って各種の処理を実行する。
ＲＡＭ１３には、ＣＰＵ１１が各種の処理を実行する上において必要なデータ等も適宜記憶される。

ＣＰＵ１１、ＲＯＭ１２及びＲＡＭ１３は、バス１４を介して相互に接続されている。このバス１４にはまた、入出力インターフェース１５も接続されている。入出力インターフェース１５には、出力部１６、入力部１７、記憶部１８、通信部１９及びドライブ２０が接続されている。

出力部１６は、液晶等のディスプレイにより構成され、各種画像を表示する。
入力部１７は、各種ハードウェア釦等で構成され、操作者の指示操作に応じて各種情報を入力する。

記憶部１８は、ＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等で構成され、各種データを記憶する。
通信部１９は、インターネットを含むネットワークＮを介して他の装置（会社端末２及び社員端末３）との間で行う通信を制御する。

ドライブ２０は、必要に応じて設けられる。ドライブ２０には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリ等よりなる、リムーバブルメディア２１が適宜装着される。ドライブ２０によってリムーバブルメディア２１から読み出されたプログラムは、必要に応じて記憶部１８にインストールされる。また、リムーバブルメディア２１は、記憶部１８に記憶されている各種データも、記憶部１８と同様に記憶することができる。

このような図２のサーバ１の各種ハードウェアと各種ソフトウェアとの協働により、サーバ１で後述する各種処理の実行が可能になる。
即ち、サーバ１は、各種処理の実行にあたり、図３に示すような機能的構成を有する。

（機能的構成）
図３に示すように、サーバ１のＣＰＵ１１においては、会社側連絡部３１と、社員側連絡部３２と、転居管理部３３と、不動産検索部３４と、引越し見積り部３５と、社内申請支援部３６とが機能する。
サーバ１の記憶部１８の一領域には、社員ＤＢ４１と、会社ＤＢ４２と、不動産ＤＢ４３と、引越し会社ＤＢ４４が設けられる。

会社側連絡部３１は、後述する不動産検索処理、引越し見積り処理、社内申請処理等において通信部１９を介して会社端末２と各種情報を授受することで、会社の人事部等の担当者との連絡を実現する。
社員側連絡部３２は、後述する不動産検索処理、引越し見積り処理、社内申請処理等において通信部１９を介して社員端末３と各種情報を授受することで、社員との連絡を実現する。

転居管理部３３は、社員の転居を管理するために、不動産検索部３４、引越し見積り部３５、及び社内申請支援部３６の夫々を制御する。

不動産検索部３４は、社員より社員端末３を介して（上述の社員側連絡部３２を介して）不動産の検索依頼があった場合、社員ＤＢ４１及び会社ＤＢ４２を照会して、その社員に対する社内規程の内容に基づいて検索条件を生成する。不動産検索部３４は、不動産ＤＢ４３に保存されている複数の不動産に関する情報（以下、「不動産情報」と呼ぶ）の中から検索条件に合致するものを検索して、社員端末３を介して（上述の社員側連絡部３２を介して）所定社員に提示する。

引越し見積り部３５は、所定社員より社員端末３を介して（上述の社員側連絡部３２を介して）転居先への引越しに伴う見積りの依頼があった場合、引越し会社ＤＢ４４を参照して適切な引越し会社を１以上抽出し、１以上の引越し会社の夫々に対して引越し見積りの手配を支援する処理を実行する。

社内申請支援部３６は、上述の社員側連絡部３２や上述の会社側連絡部３１と協働して各種処理を実行することで、所定社員が会社側（人事部等）に対して転居に伴う各種申請を行い、会社側がこれら各種申請に対する承認を行うまでのワークフローが進行するように支援する。

図４は、図３のサーバ１の機能的構成のうち、不動産検索部３４の詳細な機能的構成の一例を示す機能ブロック図である。
不動産検索部３４は、社員要望取得部５１と、不動産検出条件生成部５２と、不動産抽出部５３と、不動産提示部５４とを有する。

社員要望取得部５１は、通信部１９、社員側連絡部３２、及び転居管理部３３を介して、社員が転居をする不動産に対する要望（以下、「社員要望」と呼ぶ）を、社員端末３から取得する。社員要望には、転居の時期、不動産の賃料、所在地、専有面積、間取り、階数、部屋の向き、各種設備の有無等が含まれて良い。

不動産検出条件生成部５２は、社員ＤＢ４１及び会社ＤＢ４２を参照して、社員要望に基づく不動産の検出条件を生成する。
ただし、転居先の住居等（不動産）は、社員要望がそのまま受け入れられて決定されるわけではなく、当該社員が属する会社の社内規程により制限される。
社内規程とは、社員が所属する会社の不動産に関する各種の規程をいう。社内規程には、例えば、転居の時期、不動産の賃料、所在地、専有面積、間取り、階数に関する制限が含まれている。
さらに、社員の属性に応じて制限内容が異なっている社内規程（以下、「社員の属性に関する社内規程」と呼ぶ）が数多く存在する。社員の属性としては、例えば、社員の等級、役職、扶養家族数、転居前住所、転居後の勤務地、転居前の賃料等が存在する。具体的には例えば、社員の役職として一般職、課長職、部長職等が存在し、一般職ならば賃料８万円以下、課長職ならば賃料１０万円以下、部長職ならば賃料１５万円以下等の制限が存在する社内規程が、社員の属性に関する社内規程である。
そこで、不動産検出条件生成部５２は、さらに、社員の属性に関する社内規程に基づいて、当該社員が使用可能な不動産の検索条件を生成する。
具体的には例えば、課長職の社員の社員要望がたとえ賃料１２万円であったとしても、社員の属性に関する社内規程によれば賃料１０万円以下の住居しか許されないことになる。そこで、不動産検出条件生成部５２は、賃料１０万円以下という検索条件を生成する。
このように、不動産検出条件生成部５２は、社員要望を加味しつつも、社員の属性に関する社内規程を考慮して、適切な不動産の検出条件を生成することができる。

このように、不動産検出条件生成部５２により生成される検索条件は、社員の属性に関する社内規程の範囲内で成立可能となる条件、例えば上述の例では、課長職の社員に対しては賃料１０万円以下という条件が採用されることを基本とする。
ただし、社員が負担するならば、社員の属性に関する社内規程の範囲外で転居先の住居等（不動産）を社員が決定することを認める会社も存在する。このような会社の社員に対しては、不動産検出条件生成部５２は、検索条件として、社員の属性に関する社内規程の範囲外であるが社員の負担により成立可能となる条件を生成することもできる。
上述の例で言えば、不動産検出条件生成部５２は、課長職の社員に対して、社内規程では賃料１０万円以下であるため２万円は自己負担になることを示した上で、社員要望通りの賃料１２万円以下という検出条件を生成してもよい。
このようにすることで。サーバ１は、社員の属性に関する社内規程で定められた単純な制限（例えば役職に応じた賃料の上限額）で検索するだけでなく、柔軟に社員要望を取り入れたうえで、効率的に不動産を検出することができる。

不動産抽出部５３は、不動産ＤＢ４３に保存されている複数の不動産情報から、不動産検出条件生成部５２で生成された検出条件に合致する不動産情報を抽出する。
不動産提示部５４は、不動産抽出部５３で抽出された不動産情報を、通信部１９を介して社員端末３に送信することで、社員に提示する。

（処理フロー）
このような図４の機能的構成を有するサーバにより実行される処理のうち、社員の転居先の住居等（不動産）の候補（その候補を特定可能な不動産情報）を検索して当該社員に提示するまでの一連の処理を、以下、「不動産検索処理」と呼ぶ。
図５は、図４の機能的構成を有するサーバにより実行される不動産検索処理の流れを説明するフローチャートである。

ステップＳ１において、社員要望取得部５１は、社員端末３から送信される社員要望を取得する。
ステップＳ２において、不動産検出条件生成部５２は、社員ＤＢ４１を照会して、社員情報を取得する。社員情報とは、社員の属性を特定可能な情報、例えば、その社員についての、等級、役職、扶養家族数、転居前住所、転居後の勤務地、転居前の賃料等を含む情報をいう。
ステップＳ３において、不動産検出条件生成部５２は、会社ＤＢ４２に照会して、社員の属性に関する社内規程を取得する。

ステップＳ４において、不動産検出条件生成部５２は、ステップＳ１において取得された社員要望、ステップＳ２において取得された社員情報、ステップＳ３において取得された社員の属性に関する社内規程に基づいて、不動産の検出条件を生成する。

ステップＳ５において、不動産抽出部５３は、ステップＳ４において生成された検出条件を利用して、不動産ＤＢ４３を検索して、１以上の不動産情報を抽出する。

ステップＳ６において、不動産提示部５４は、ステップＳ５において抽出された１以上の不動産情報を社員端末３に送信することで、社員に提示する。

ステップＳ７において、サーバ１は、新たな社員要望が送信されてきたか否かを判定する。
新たな社員要望が送信されてきた場合、ステップＳ７においてＹＥＳであると判定され、処理はステップＳ１に戻され、それ以降の処理が繰り返される。
これに対して、新たな社員要望が送信されてこなかった場合、ステップＳ７においてＮＯであると判定され、不動産検索処理は終了となる。

（具体例）
図６は、社員が、社員端末３において、転居に関する情報を入力する際の管理画面の一例を示す図である。この画面には、転居までの流れを提示したり、提携先の不動産会社へ希望条件をリクエストしたり、引越しの見積り依頼をしたり、全国の不動産会社が管理している賃貸不動産（「物件」ともいう）を検索したりすることができる画面に遷移するためのボタンが表示されている。

社員端末３では、このように、社員の転居に関する各種の情報を入力することができる。ここで入力された情報は、社員端末３からサーバ１の転居管理部３３に送信され、転居管理部３３は不動産検索部３４、引越し見積り部３５、社内申請支援部３６等の適切な機能を使用して、これらの情報を処理する。

以下、図６乃至図１０の図面を参照して、図３のサーバ１で実行される不動産検索処理の具体例について説明する。

図６は、社員が、図１の社員端末３において、不動産検索処理に必要な情報を入力するための画面の一例を示す図である。
換言すると、社員は、社員端末３に表示される図６の画面を用いて、各種社員要望を入力することができる。即ち、図６の画面に表示される入力ボックスやチェック項目に入力された内容が、社員要望として取得される。

ここで、社員要望として入力可能な項目は、図６の画面の例では、必須入力項目（必須の文字が表示されている項目）、基本条件の入力項目、及び絞り込み条件の入力項目に大別される。

必須入力項目は、社員の転勤等に伴う新しい勤務地の住所と、その住所から検索対象の不動産（転居先）までの所要時間との夫々の項目である。
図６の例では、勤務先の住所の入力領域には、「東京都新宿区新宿」と入力されている。これは、社員の新しい勤務地が東京都新宿区の新宿であることを示している。また、所要時間の入力領域には、「１０分以内」、「徒歩」と入力されている。これは、東京都の新宿区新宿（新しい勤務地）から、徒歩で１０分以内に存在する不動産が検索対象になることを示している。

図６の画面の例では、必須入力項目の下方には、基本条件の入力項目が設けられている。

基本条件の１つとして、賃料についての入力項目が設けられている。社員は、この入力項目に、所望の賃料を入力することができる。
ただし、必須入力項目と基本条件の入力項目の間の「御社の規程が反映された項目には（アラートを示すマーク）がついています。」という表示があり、当該「アラートマーク」が、賃料の入力項目についている。これは、この入力項目は、社員の属性に関する社内規程の制限が存在することを意味している。即ち、上述した様に、社員が、たとえ賃料として２０万円を入力したとしても、その社員の属性（例えば課長等）に関する社内規程が１０万円以下の場合、この入力は受け付けられず、当該社内規程に基づく賃料、ここでは、８万円から１０万円の入力に更新される。
つまり、上述のステップＳ１において、２０万円の賃料がたとえ入力されても、その後のステップＳ２乃至Ｓ４により、社員の属性に関する社内規程に基づく入力内容に更新される。
なお、賃料については、「管理費・共益費込」の有無についても入力が可能とされている。

基本条件の別の１つとして、間取りについての入力項目が設けられている。社員は、この入力項目に、所望の間取りを入力することができる。
ただし、賃料と同様に間取りについても、アラートを示すマークがついている。これは、この入力項目は、社員の属性に関する社内規程の制限が存在することを意味している。即ち、社員が、たとえ間取りとして４ＬＤＫ以上を入力したとしても、その社員の属性（例えば課長等）に関する社内規程が１ＬＤＫ以下の場合、この入力は受け付けられず、当該社内規程に基づく間取り、ここでは、１ＬＤＫ、１Ｋ／１ＤＫ、１Ｒ入力（チェック）に更新される。
つまり、上述のステップＳ１において、４ＬＤＫ以上の間取りがたとえ入力されても、その後のステップＳ２乃至Ｓ４により、社員の属性に関する社内規程に基づく入力内容に更新される。

図６の画面の例では、基本条件の入力項目の下方には、絞込み条件の入力項目が設けられている。
絞込み条件としては、建物種別、最寄り駅からの徒歩時間、専有面積、築年数、こだわり条件、その他条件、その他、及び入居日が設けられている。社員は、これらの入力項目に、所望の間取りを入力することができる。
ただし、賃料や間取りと同様に最寄り駅からの徒歩時間についても、アラートを示すマークがついている。これは、この入力項目は、社員の属性に関する社内規程の制限が存在することを意味している。即ち、社員が、たとえ徒歩１分以内を入力したとしても、その社員の属性に関する社内規程が徒歩１５分まで受け入れるというものである場合、この入力は受け付けられず、当該社内規程に基づく徒歩時間、ここでは、１５分以内の入力（チェック）に更新される。
つまり、上述のステップＳ１において、徒歩１分以内がたとえ入力されても、その後のステップＳ２乃至Ｓ４により、社員の属性に関する社内規程に基づく入力内容に更新される。
なお、それ以外の絞込み条件については、アラートを示すマークがついていない。これは、社員要望、即ち社員による入力内容がそのまま受け入れられることを意味している。

なお、後述するように、上述の図５の各ステップの順番は例示に過ぎず、例えば先にステップＳ２乃至Ｓ４の処理が行われた後ステップＳ１の処理が行われれば、社員による社員要望の入力前に、社員の属性に関する社内規程に基づく内容が自動入力されることになる。

このように、検索条件は、社員の属性に関する社内規程に基づいて生成されることになる。
従って、社員の属性に関する社内規程に対して、当該社員の属性等の情報（社員情報）は予め入力されている必要がある。
図７は、社員が、図１の社員端末３において、図３の社員ＤＢ４１に保存させる社員情報を入力するための画面の一例を示す図である。

図７の例では、氏名、氏名のかな、会社名、部署名、社員番号、メールアドレス、電話番号、転居先住所、勤務地、役職、年齢、勤続年数、家族数、職種、社宅持家期限等の社員情報が、社員により入力可能となっている。
なお、社員情報の内容（入力項目）は、特に限定されないが、社員の属性に応じて条件が可変するような社内規程が存在する場合、当該属性により検索条件が変更され得るので、当該属性が社員情報として入力可能となっていると好適である。
例えば図６の例に対応させると、例えば賃料や間取りが職種や役職に応じて変更となる社内規程が存在する場合、職種や役職が社員情報として入力可能となっていると好適である。

ところで、図１の例では、本発明の理解を容易なものとすべく、会社は１社としたが、実際には複数の会社が本サービスの提供を受ける。
そして、社内規程は、複数の会社毎に作成されているため、複数の会社毎に存在する。
このため、サーバ１は、社内規程に関する情報が複数の会社毎に羅列されたリストを、会社ＤＢ４２に格納して管理している。
図８は、会社ＤＢ４２に保存されている複数の会社毎の社内規程のリストの一例を示す図である。

図８の例のリストでは、所定の１行が所定の会社についての社内規程に関与する属性（後述するコード名称）に対応している。即ち、同一会社が、複数種類の属性に応じて条件が変化するような社内規程を有している場合、同一会社であっても、複数種類の属性に夫々対応する行が設けられる。
所定の１行には、当該１行に対応付けられた属性についての情報として、詳細、複製、法人会社ＩＤ、データ区分、企業別コード、表示順番、及びコード名称が格納されている。
所定の１行の「詳細」には、当該１行に対応付けられた属性（又は会社）についての詳細情報が格納されている。
所定の１行の「複製」には、当該１行に対応付けられた属性に関する社内規程の複製データが格納されている。
所定の１行の「法人会社ＩＤ」には、当該１行に対応付けられた属性に関する社内規程を有する会社について、それを一意に識別するＩＤが格納されている。
所定の１行の「データ区分」には、当該１行に対応付けられた属性に関する社内規程のデータ区分（例えば、区分として賃料に関する規程、区分として間取りに関する規程等）が格納されている。
所定の１行の「企業別コード」には、当該１行に対応付けられた属性に関する社内規程を有する会社の職務分野を示すコードが格納されている。
所定の１行の「表示順番」には、本リストが表示された際の当該１行の表示順番が格納されている。
所定の１行の「コード名称」には、当該１行に対応付けられた属性を示すコード名称が格納されている。

具体的には例えば、１行目と２行目に着目すると、法人会社ＩＤが「３００５」で同一であり、データ区分が「００」で同一であることから、同一会社の同一区分に関する社内規程についての情報が格納されていることがわかる。
具体的には例えば、１行目のコード名称が「勤務地区Ａ」であり、２行目のコード名称が「勤務地区Ｂ」であることから、勤務地区に応じて所定の区分（例えば賃料）が変更になるような社内規程、例えば勤務地区Ａであれば賃料１０万円以下だが、勤務地区Ｂであれば賃料８万円以下であるというような社内規程が存在することがわかる。

サーバ１は、このような図８の例のリストを管理することで、複数の会社毎の社内規程に夫々適合した不動産検索処理を実行することができる。

図９は、このよう不動産検索処理の結果として、社員端末３に表示される画面の一例を示している。
即ち、上述の図５のステップＳ６の処理の結果として、例えば図９の例の画面が社員端末３に表示される。

図９の例の画面で着目すべきは、上方の表示領域である。
この上方の表示領域を設けることで、社員に対して、社内規程に基づく不動産検索が行われたか否かを確認することができる。つまり、たとえ社員要望だけで不動産が検索されても、社員の属性に関する社内規程に基づくものでなければ、検索された不動産が会社に承認されない。つまり、当該社員は、その不動産に住むことはできない。そこで、そのようなことがおこらないように、社内規程に基づく不動産検索が行われたか否かが確認されるのである。
具体的には例えば、図９の例の画面の一番上には「注意：あなたがお求めの物件はルールに違反していないですか？」という確認メッセージが表示される。
そして、その下方には、「会社のルールを確認する」と表示されたリンク、即ち、社員の属性に関する社内規程が表示またはダウンロード可能となる場所へのリンクが表示される。
また、その下方には、今回の不動産検索で用いられた検索条件、特に社員の属性に関する社内規程により制限される検索条件が表示される。
さらに、その下方には、さらに詳細に絞り込んだ検索を再度行うためのソフトウェアボタンと、その上方に表示された検索条件（この条件）を保存するためのソフトウェアボタンとが表示されている。
社員は、このような図９の画面で社内規程に反していないという確認をしっかりと行った後、その下方に示される検索結果、即ち、検索された不動産情報を確認することができる。

図９の例の画面には、検索された３件の不動産についての不動産情報が表示されている。なお、不動産の検索数は「２２件」となっているので、社員は、当然ながらこの２２件についての不動産情報についても視認可能となっている。
不動産情報としては、部屋の間取り図、不動産の外観写真、不動産の内部の写真等の他、その不動産又は部屋の詳細を示すテキスト情報が表示される。

ここで、着目すべきは、「社宅規程範囲」と「個人負担」のテキスト情報が表示されることである。
即ち、不動産検索処理において用いられる検索条件は、上述した様に、社員の属性に関する社内規程の範囲内で成立可能となる条件（以下、「規程内条件」と呼ぶ）は勿論のこと、社内規程の範囲外であるが社員の負担により成立可能となる条件（以下、「規程外条件」と呼ぶ）を採用することができる。
具体的には例えば、社員の属性（役職）が課長であり、当該社員が属する会社の社内規程に、「課長の場合賃料１０万円以下」という条件が存在する場合、規程内条件で検索される不動産は、賃料１０万円以下である。
しかしながら、社員の中には、賃料を自己負担したとしても、規程内条件よりも好条件の不動産に住みたいという要望を有する者もいる。そして、このような要望を認める会社も存在する。このような点に対応すべく、規程外条件による不動産検索も可能となっている。
この規程外条件による不動産検索が行われた場合、規程内条件の枠内か否かが表示される。表示された不動産の賃料と規程内条件との差額が、個人負担として表示される。そして、賃料と社宅規程範囲との差額分が、個人負担として表示される。なお、不動産によっては管理費を取るものもあり、このような管理費を負担していない旨が社内規程に存在する場合、管理費も個人負担として表示される。
このように、社員は、規程外条件での不動産検索を行った場合、どの程度自己負担すべきかを、検索された不動産毎に視認することができるので、検索された不動産のうちどれを候補とするのかについての比較検討を容易かつ効果的に行うことができる。

以上、本発明の実施形態について説明したが、本発明は、上述の実施形態に限定されるものではなく、本発明の目的を達成できる範囲での変形、改良等は本発明に含まれるものである。また、本実施形態に記載された効果は、本発明から生じる最も好適な効果を列挙したに過ぎず、本発明による効果は、本実施形態に記載されたものに限定されるものではない。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。

一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが、コンピュータ等にネットワークや記録媒体からインストールされる。
コンピュータは、専用のハードウェアに組み込まれているコンピュータであっても良い。また、コンピュータは、各種のプログラムをインストールすることで、各種の機能を実行することが可能なコンピュータ、例えば汎用のパーソナルコンピュータであっても良い。

このようなプログラムを含む記録媒体は、ユーザにプログラムを提供するために装置本体とは別に配布されるリムーバブルメディアにより構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに提供される記録媒体等で構成される。リムーバブルメディアは、例えば、磁気ディスク（フロッピーディスクを含む）、光ディスク、又は光磁気ディスク等により構成される。光ディスクは、例えば、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）等により構成される。光磁気ディスクは、ＭＤ（Ｍｉｎｉ Ｄｉｓｋ）等により構成される。また、装置本体に予め組み込まれた状態でユーザに提供される記録媒体は、例えば、プログラムが記録されているＲＯＭや、記憶部に含まれるハードディスク等で構成される。

なお、本明細書において、記録媒体に記録されるプログラムを記述するステップ及びセールスステップは、その順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的或いは個別に実行される処理をも含むものである。
また、本明細書において、システムの用語は、複数の装置や複数の手段等より構成される全体的な装置を意味するものとする。

図１に示すシステム構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。即ち、夫々の装置の役割を実行することができる機能が情報処理システム内に備えられていれば良く、更に、夫々の装置は、ネットワークを介さずに、直接接続されていても良い。

図２に示す各ハードウェア構成は、本発明の目的を達成するための例示に過ぎず、特に限定されない。例えば、１つのハードウェアが他のハードウェアの機能を兼ね備えていても良く、同じ機能を持つハードウェアが複数含まれていても良い。

図３及び図４の機能的構成は例示に過ぎず、特に限定されない。即ち、上述した一連の処理を全体として実行できる機能がサーバ１に備えられていれば足り、この機能を実現するためにどのような機能ブロックを用いるのかは特に図３及び図４の例に限定されない。
また、１つの機能ブロックは、ハードウェア単体で構成しても良く、ソフトウェア単体で構成しても良く、それらの組み合わせで構成しても良い。

例えば、社員ＤＢ４１、会社ＤＢ４２、不動産ＤＢ４３、引越し会社ＤＢ４４は、いずれかのデータベースが他のデータベースの情報を保存していても良い。また、これらのデータベースは、サーバ１の記憶部１８内ではなくて、ネットワークＮを介してサーバ１と接続している他の端末、装置、又はサーバ等のいずれかの中に備えられていても良い。
また、例えば、会社ＤＢ４２に格納された社内規定等について、別途、図示せぬ社内規定ＤＢ等を設けて、そこに格納しても良い。

具体的には例えば、不動産検索処理による検索対象となる不動産情報は、上述の実施形態では不動産ＤＢ４３に格納されていたが、特にこれに限定されず、例えば本サービスの提供者以外の者が管理するＤＢ、例えば一般的な賃貸用不動産の検索サイト等で利用されるＤＢであってもよい。
これにより、社員が、一般的な賃貸用不動産の検索サイト等を利用して不動産情報を検索する際にも、社員の属性に関する社内規程に適合した不動産に関する情報を、効率的に抽出することができる。
即ち、サーバ１は、先ず、社員の属性に関する社内規程に基づいて、当該社員が使用可能な不動産の検索条件を生成する。
そして、サーバ１は、上述の本サービスの提供者以外の者が管理するＤＢから、生成された検索条件に合致する不動産情報を検索する処理の制御を実行する。
ここで、「不動産情報を検索する」とせずに、「不動産情報を検索する処理の制御を実行する」としたのは、検索の処理自体はサーバ１が必ずしも実行しなくてもよいという趣旨である。つまり、検索の処理自体は、一般的な賃貸用不動産の検索サイト等に任せてもよい。サーバ１は、あくまでも、一般的な賃貸用不動産の検索サイト等が検索の処理を実行するに際し、社員の属性に関する社内規程に基づく検索条件を用いることができるような任意の制御を実行すれば足りる。例えば、サーバ１は、社員の属性に関する社内規程に基づく検索条件を、一般的な賃貸用不動産の検索サイト等に送信し、その検索条件で検索の処理を実行するように指示を出してもよい。

図１０は、サーバ１を用いた不動産探し支援サービスであって、一般的な賃貸用不動産の検索サイト等でも社内規程に基づく検索が可能となる支援サービスの全体の概略を示す図である。
階層Ｋ１１において、サーバ１は、社員端末３を操作する社員Ｕに対して、本支援サービスを利用可能な者かについての認証を行う。
階層Ｋ１２において、サーバ１は、社員端末３を操作する社員Ｕに対する不動産の検索条件として、社内規程フィルタを用いた不動産の検索条件を生成する。ここで、社内規程フィルタとは、社員Ｕの属性に関する社内規程に基づいて生成された検索条件を用いて検索する際のフィルタを意味している。
ここで、階層Ｋ１３においては、所定の検索条件を用いて不動産（物件）を検索する物件検索エンジンによる処理が行われる。ここで着目すべき点は、物件検索エンジンの存在場所は、特に限定されず、サーバ１内であってもよいし、一般的な賃貸用不動産の検索サイト等であってもよい。
そして、階層Ｋ１４は、物件検索エンジンによる検索結果（物件情報）を示しているが、この検索結果は、その下方にあるように、サーバ１を管理するサービス提供者と提携する不動産会社に関するデータベースＤＢＴと、全国の不動産会社に関するデータベースＤＢＺとの両方から抽出されている。
つまり、階層Ｋ１３において社内規程フィルタを生成することで、任意の存在場所にある物件検索エンジンを用いて、全国のあらゆるデータベースを検索対象として、社員の属性に関する社内規程に適合した不動産検索を効率的に実現することができるようになる。

また例えば、不動産検索処理において用いられる検索条件は、上述した様に、社員の属性に関する社内規程の範囲内で成立可能となる規程内条件は勿論のこと、当該社内規程の範囲外であるが当該社員の負担により成立可能となる規程外条件を採用することができる。
ここで、規程外条件は、賃料に関する条件について上述したが、これは例示に過ぎず、任意の条件を考慮して生成することができる。例えば、会社が負担する通勤定期等の交通費の関係で、居住の範囲（例えば会社の最寄駅から３駅以内等の範囲）が限定されている社内規程も存在する。このような場合であっても交通費等を社員が負担するならば、社内規程の範囲外に存在する不動産（例えば会社の最寄り駅から４駅目が最寄り駅となる不動産）も検索対象になるように、規程外条件を生成すこともできる。
なお、規程外条件における社員の負担とは、理解を容易なものとするため、金銭的負担としたが、精神的や肉体的に負担となるものであれば任意のものでよい。例えば、最寄り駅から徒歩１０分以内という社内規程が存在する場合、最寄り駅から徒歩２０分に存在する不動産は、賃料等の金銭的な負担は少なくなるかもしれないが、毎日徒歩２０分も歩くという肉体的負担は増加する。しかし、肉体的負担は増加しても、何らかの理由（例えば健康的な理由等）から、最寄り駅から徒歩２０分の不動産も検索対象になるように、規程外条件を生成すこともできる。
また、規程外条件は、上述の例では社員側の明示の要求があった場合に生成されたが、生成のトリガは特にこれに限定されず任意でよい。例えば、社員要望からすると規程内条件で足りる場合であっても、サーバ１は、自律的な判断で規程外条件を生成し、規程外条件により抽出された不動産情報を、「参考までに、少し自己負担をすれば、こんな不動産もありますよ」という趣旨で、社員に提示（推薦）することもできる。

また例えば、規程内条件と規程外条件によらず、検索条件は、検索処理の段階で生成されていれば足り、その生成タイミング等は特に限定されない。
同様に、検索条件を生成するために必要な各種情報も、検索条件の生成前、即ち、検索処理の前までに取得されていれば足り、その取得タイミング等は特に限定されない。例えば上述の図５のステップＳ１〜Ｓ３は、夫々のタイミングで処理することができ、３つ同時に処理しても良く、別々でも良く、さらに言えば処理の順番も任意で良い。

また例えば、検索対象となる不動産情報は、上述の例では、部屋だけを賃貸する不動産に関する情報であったが、特にこれに限定されず、会社側で不動産の費用（賃料）として処理できるものに関する任意の情報を採用することができる。例えば、各種設備が部屋に付いていたり、各種設備が利用可能となった部屋等に関する情報も、不動産情報として採用することができる。
ここで、各種設備としては、例えば、エレベータ、駐車場、バス・トイレ別、室内洗濯機置き場、和室、洋室、エアコン、室内乾燥機、Ｗｉ−Ｆｉ、モニターフォン、温水便座等が挙げられる。
なお、家具等の各種設備付きの部屋の場合、部屋の貸主（大家等）が各種設備を用意する必要は無く、例えばサービスの提供者が、部屋だけを賃貸する通常の不動産情報に対して、家具等の各種設備を後からつけた不動産情報（その分賃料に上乗せした不動産情報）を検索対象とすることもできる。

また例えば、検索の主体は、上述の例では、社内規程が存在する会社に属する社員とされたが、特にこれに限定されず、ユーザの属性に関する規程が存在する所定団体に属する当該ユーザであれば足りる。

［第２実施形態］
（サービス概要）
上述したように、本発明の第１実施形態に係る情報処理装置を含む情報処理システムの適用対象である転居管理サービスには、転居を要する社員が利用できる、転居先の不動産探しを支援するサービス（以下、「転居先検索支援サービス」と呼ぶ）が含まれる。
図１１に示すように、転居先検索支援サービスを含む転居管理サービス、規程管理サービス、及び借上社宅管理サービスは、互いに連携している。
ここで、「規程管理サービス」とは、社員Ｕが転居先となり得る不動産について、社員Ｕの属する会社の社内規程に適合するかどうかの判定を行うサービスである。なお、規程管理サービスによるこのような判定のことを「規程チェック」と呼ぶ。
また、「借上社宅管理サービス」は、上述したように、借上社宅管理転貸サービスと借上社宅管理代行サービスとを含むサービスである。なお、借上社宅管理転貸サービス、及び借上社宅管理代行サービスの内容については、第１実施形態で説明したとおりである。

転居管理サービスには、転居を要する社員が利用できる転居先検索支援サービスの他、当該社員からの各種申請に対する承認を行う会社の承認担当者（以下、「承認者」と呼ぶ）や、当該社員に直接対応して契約を行う不動産業者の夫々の業務を支援するサービスが含まれる。
以下、承認者の業務を支援するサービスのことを「承認業務支援サービス」と呼び、当該社員に直接対応する不動産業者の業務を支援するサービスのことを「契約業務支援サービス」と呼ぶ。

図１１は、本発明の第２実施形態に係る情報処理装置を含む情報処理システムの適用対象となる各種サービスの概要を示すイメージ図である。

図１１には、転居を要する社員Ｕと、社員Ｕにより操作される社員端末３と、社員Ｕが属する会社Ｃの承認者Ｍと、承認者Ｍにより操作される会社端末２と、社員Ｕに直接対応する不動産業者Ｒと、不動産業者Ｒにより操作される不動産会社端末４とが描画されている。なお、図示はしないが、不動産会社端末４も、本発明の第２実施形態に係るサーバ１を含む情報処理システムを構成する情報処理装置として、図１のネットワークＮに接続されている。

（転居先検索支援サービス）
社員Ｕは、社員端末３を操作することにより、転居先検索支援サービスを利用することができる。上述したように、転居先検索支援サービスは、規程管理サービスと連携している。このため、社員Ｕは、転居先検索支援サービスを利用することにより、不動産の検索や、不動産についてのリクエスト等を社内規程に適合する範囲内で行うことができる。
換言すると、転居先検索支援サービスでは、社員Ｕにより入力された社員要望（リクエスト）の受け付け、社員要望（リクエスト）受付時、又は不動産の検索時における、社内規程に基づいた選択肢の設定や、規程チェック等が行われる。

（承認業務支援サービス）
社員Ｕは、社員端末３を操作することにより、自身が属する会社Ｃに対し、各種申請を行うことができる。なお、ここでいう「各種申請」とは、転居を要する社員Ｕの属する会社Ｃの社宅制度において別途定められている各種の申請手続きのことをいう。「各種申請」には、例えば転居先への入居についての承認を会社Ｃに求める申請手続き（以下、「入居申請」と呼ぶ）や、転居先からの退去についての承認を会社Ｃに求める申請手続き（以下、「退去申請」と呼ぶ）等が含まれる。
承認者Ｍは、会社端末２を操作することにより、承認業務支援サービスを利用することができる。上述したように、承認業務支援サービスは規程管理サービスと連携している。このため、承認者Ｍは、承認業務支援サービスを利用することにより、ワークフローにおける入居申請や退去申請等の各種申請についての規程チェックを行うことができる。規程チェックは、承認業務支援サービスによって自動で行われるため、承認者Ｍによる目視によるチェックを最小化させることができるとともに、紙による決裁を省略することができるので、承認者Ｍの作業量を低減化させることができる。
これにより、承認者Ｍ（例えば人事担当者、総務担当者等）における事務的な負担を軽減化させることができる。

（契約業務支援サービス）
不動産業者Ｒは、不動産会社端末４を操作することにより、契約業務支援サービスを利用することができる。上述したように、契約業務支援サービスは規程管理サービスと連携している。このため、不動産業者Ｒは、契約業務支援サービスを利用することにより、社員Ｕの転居先の不動産の賃貸借契約に関する情報（以下、「契約情報」と呼ぶ）を入力するだけで、社員Ｕの転居先となる不動産を対象とする規程チェックを行うことができる。規程チェックは、契約業務支援サービスにより自動で行われる。
これにより、不動産業者Ｒは、社員Ｕの属する会社の社内規程に適合しない不動産を対象とする賃貸借契約を誤って締結してしまうことを防ぐことができる。

上述したように、転居管理サービスは、借上社宅管理サービスに連携させることができる。この場合、借上社宅管理サービスにおいて、社員Ｕが転居先の不動産として所望する不動産を対象とする規程チェックが行われる。

図１２は、転居管理サービスと、借上社宅管理サービスとの夫々に、規程管理サービスを連携させた場合のイメージ図である。

図１２に示すように、転居管理サービスには、社員Ｕが利用できる転居先検索支援サービスと、承認者Ｍが利用できる承認業務支援サービスと、不動産業者Ｒが利用できる契約業務支援サービスとが含まれる。これらの３種類のサービスの夫々は、規程管理サービスと連携している。

これにより、社員Ｕが、転居先検索支援サービスを利用して、転居先となる不動産の検索を行うと、規程管理サービスが連携して、検索条件を設定する制御と、設定された検索条件による検索の結果抽出された不動産について規程チェックが行われる。

また、社員Ｕの属する会社Ｃにおいて、ワークフロー支援サービスが利用されて、社員Ｕによる各種申請、及び承認者Ｍによる承認が行われる過程では、規程管理サービスが連携することで、社員Ｕによる各種申請の内容についての規程チェックが行われる。

また、不動産業者Ｒが、契約業務支援サービスを利用して、社員Ｕの転居先として特定された不動産についての賃貸借契約が締結される際には、規程管理サービスが連携して、当該不動産についての規程チェックが行われる。

また、図１２に示すように、借上社宅管理サービスは、規程管理サービスと連携している。これにより、借上社宅管理転貸サービスや、借上社宅管理代行サービスが提供される際、対象となる不動産についての規程チェックが行われる。ここで、借上社宅管理サービスにおいて行われる規程チェックの具体的手法は特に限定されない。例えば、社員Ｕが属する会社を一意に識別するための企業コード等の情報をキーにして、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ）に対応する項目についてのチェックが行われてもよい。

（機能的構成）
次に、図１３を参照して、第１実施形態のサーバ１と同様に、図２に示すハードウェア構成を有する第２実施形態のサーバ１の機能的構成の、図３に示す例とは異なる例について説明する。
図１３は、本発明の情報処理装置の第２実施形態に係るサーバ１の機能的構成の一例を示す機能ブロック図である。

図１３に示すように、サーバ１のＣＰＵ１１においては、不動産会社側連絡部６０と、会社側連絡部６１と、社員側連絡部６２と、転居管理部６３と、不動産検索部６４と、引越し見積り部６５と、社内申請支援部６６とが機能する。
サーバ１の記憶部１８の一領域には、社員ＤＢ７１と、会社ＤＢ７２と、不動産ＤＢ７３と、引越し会社ＤＢ７４とが設けられる。

会社側連絡部６１及び社員側連絡部６２の夫々が実行する処理は、上述の第１実施形態における会社側連絡部３１及び社員側連絡部３２の夫々が実行する処理と同様であるため説明を省略する。
不動産会社側連絡部６０は、通信部１９を介して不動産会社端末４と、契約情報等の各種情報を授受することで、不動産業者Ｒとの連絡を実現する。なお、上述の各種情報は、図１５を用いて後述する。

転居管理部６３は、社員の転居を管理するために、不動産検索部６４、引越し見積り部６５、社内申請支援部６６、及び契約支援部６７の夫々を制御する。

不動産検索部６４及び引越し見積り部６５の夫々が実行する処理、及び当該処理において参照される社員ＤＢ７１乃至引越し会社ＤＢ７４は、上述の第１実施形態において、不動産検索部３４及び引越し見積り部３５の夫々が実行する処理、及び当該処理において夫々参照される社員ＤＢ４１乃至引越し会社ＤＢ４４と同様であるため説明を省略する。

社内申請支援部６６は、上述の不動産会社側連絡部６０、会社側連絡部６１、及び社員側連絡部６２と協働して各種処理を実行することで、転居を要する社員Ｕが会社Ｃ側（人事部等の承認者Ｍ）に対する各種申請、及びこれらの各種申請に対する会社Ｃ側の承認が行われるまでのワークフローの進行の支援を行う。
なお、当該社員Ｕが会社Ｃ側（人事部等の承認者）に対して各種申請を行う際に社員端末３に表示されるＵＩ（Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）の具体例については、図１４を参照して後述する。

契約支援部６７は、上述の不動産会社側連絡部６０と協働して各種処理を実行することで、転居を要する社員Ｕの転居先となる不動産が、当該社員Ｕの属する会社Ｃの社内規程に適合するかどうかのチェックの支援を行う。なお、当該社員Ｕが会社Ｃ側（人事部等の承認者Ｍ）に対して行う各種申請の具体例については、図１４を参照して後述する。
これにより、例えば不動産業者の店舗に当該社員が来店した場合に、当該社員の転居先となる不動産を対象とする賃貸借契約の締結のために必要となる情報を、不動産会社端末４に入力することができる。
なお、当該社員の転居先となる不動産を対象とする賃貸借契約の締結のために必要となる情報を入力する際に不動産会社端末４に表示されるＵＩの具体例については、図１５を参照して後述する。

（具体例）
図１４は、社員Ｕが承認者Ｍに対して入居申請を行う際に社員端末３に表示されるＵＩの具体例を示す図である。

図１４に示すように、社員Ｕが会社Ｃの承認者Ｍに対して入居申請を行う際に社員端末３に表示されるＵＩは、表示領域Ｆ１乃至Ｆ４で構成される。なお、図１４に示すＵＩは一例にすぎない。例えば表示領域Ｆ１乃至Ｆ３に表示された入力項目以外の入力項目を設けてもよい。

表示領域Ｆ１には、「入居申請入力」という表示と、申請種別を選択するための入力欄が表示されている。「申請種別」とは、入居申請の対象となる不動産の種類及び数量（件数）のことをいう。
申請種別は、プルダウンボタンＢ１１を押下する操作を行うことで選択することができる。申請種別が２種類ある場合には、プルダウンボタンＢ１１の他にプルダウンボタンＢ１２を押下する操作を行うことで選択することができる。なお、申請種別は必須入力項目となる。
図１４の例では、申請種別として、「住居 １件」と「法人駐車場 ２件」とが選択されている。即ち、社員Ｕは、転居をする際、会社Ｃに申請する内容として、１件の住居と、２件の法人駐車場とを希望していることになる。
申請種別を入力する欄の右側には「その他の理由」と表記された入力欄が表示されている。この入力欄は、選択された申請種別の内容を補完する情報を入力する場合に利用される入力欄である。

これらの入力欄の下には、「戻る」と表記されたソフトウェアボタンＢ１３と、「下書保存」と表示されたソフトウェアボタンＢ１４と、「規程チェック」と表記されたソフトウェアボタンＢ１５とが配置されている。
ソフトウェアボタンＢ１３が押下される操作（例えば社員端末３の画面をタップする操作）がなされると、図１４に示す入居申請を行うためのＵＩが社員端末３に表示される前に社員端末３に表示されていた所定画面に画面遷移する。
ソフトウェアボタンＢ１４が押下される操作がなされると、図１４に示す入居申請を行うためのＵＩに入力されていた内容が、「下書き」として保存される。
ソフトウェアボタンＢ１５が押下される操作がなされると、表示領域Ｆ１乃至Ｆ３に入力された内容を対象とする規程チェックが行われる。

表示領域Ｆ２には、「入居者情報」という表示と、社員Ｕの社員番号を入力する欄と、社員Ｕの役職を選択して入力する欄と、入居者（社員Ｕ）の氏名の漢字表記を入力する欄と、入居者（社員Ｕ）の氏名のかな表記を入力する欄とが表示されている。また、社員Ｕの社員番号を入力する欄の右側には、「入居者選択」と表記されたソフトウェアボタンＢ２１が配置されている。
ここで、ソフトウェアボタンＢ２１が押下される操作がなされると、図示はしないが、入居者の候補となる社員Ｕ１乃至Ｕｎの夫々の名称が、社員番号とともに一覧表示される。この一覧の中から一の社員Ｕｍ（ｍは１以上ｎ以下の任意の整数）が選択されると、その社員Ｕの社員番号が、ソフトウェアボタンＢ２１の左側の欄に自動入力される。
「役職」は、プルダウンボタンＢ２２を押下する操作を行うことで選択することができる。図１４の例では、「役職」として、「一般職」が選択されている。

表示領域Ｆ３には、「入居理由（※必須）」と表記された、社員Ｕの「入居理由」を入力する欄と、「出向有無」と表記された、出向の有無を選択して入力する欄と、「入居予定日（※必須）」と表記された「入居予定日」を入力する欄とが表示されている。
「入居理由」は、プルダウンボタンＢ３１を押下する操作を行うことで選択することができる。なお、入居理由は必須入力項目となる。
入居理由を入力する欄の右側には「その他の理由」と表記された入力欄が表示されている。この入力欄は、選択された入居理由の内容を補完する情報を入力する場合に利用される入力欄である。図１４の例では、入居理由として「自己都合」が選択されており、「その他の理由」が「ブランク（空欄）」となっている。
ここで、「その他の理由」と表記された入力欄の右側に、「独身の方の自己都合転居は不可です。」という注意書きが表示されている。この表示は、上述のソフトウェアボタンＢ１５が押下されたことにより実行された規程チェックの結果を示すメッセージである。即ち、このメッセージは、入居理由を選択して入力する欄で選択されている「自己都合」が、社内規程に適合しないことを示すメッセージとなっている。
「出向有無」は、選択ボタンＢ３２を押下する操作を行うことで選択することができる。なお、図１４の例では「有（出向有り）」が選択されている。
「入居予定日」は、年月日の夫々を示す欄に数字（半角）で入力する操作を行うか、又はカレンダーを示す画像を表示させて、具体的な日時を指定することができるカレンダーボタンＢ３３を押下する操作を行うことで入力することができる。

表示領域Ｆ４には、表示領域Ｆ１乃至Ｆ３の各入力項目に入力された内容を対象とする規程チェックの結果が表示される。
図１４の例では、規程チェックの結果として、「規程チェックの結果、１箇所のエラーがあります。」というメッセージが表示されている。そして、そのエラーの具体的内容として、上述の内容（独身の場合、自己都合転居は不可とする内容）が表示領域Ｆ３に表示される。

社員Ｕは、社員端末３を操作して、上述の入力項目毎の入力欄に所定情報を入力することで、社員Ｕが属する会社Ｃに対する入居申請を行うと同時に、規程チェックを受けることができる。
これにより、社員Ｕによる入居申請後に、社内規程に適合しないことを理由に入居申請をやり直すような、迂遠な手続きが会社Ｃ内で繰り返されることを防ぐことができる。
なお、上述の入力項目は、あくまでも例示であり、サーバ１は、その他、任意の項目を入力項目として設定することができる。

図１５は、不動産業者が契約情報の入力を行う際に不動産会社端末４に表示されるＵＩの具体例を示す図である。

図１５に示すように、不動産業者が契約情報の入力を行う際に不動産会社端末４に表示されるＵＩは、表示領域Ｆ５乃至Ｆ７で構成される。なお、図１５に示すＵＩは一例にすぎない。例えば表示領域Ｆ５及びＦ６に表示された入力項目以外の入力項目を設けてもよい。

表示領域Ｆ５には、「［物件決定依頼書登録（契約入力）］（契約内容詳細）」という表示と、「終了」と表記されたソフトウェアボタンＢ５１と、「前へ戻る」と表記されたソフトウェアボタンＢ５２と、「次へ」と表記されたソフトウェアボタンＢ５３と、会社Ｃの「名称、及び社員Ｕの名前の表示と、「契約内容詳細＜ご契約の条件・内容のご入力をお願い致します。＞」という案内表示と、「規程チェック」と表記されたソフトウェアボタンＢ５４とが表示されている。
ソフトウェアボタンＢ５３が押下される操作がなされると、表示領域Ｆ６に入力された内容を対象とする規程チェックが行われる。

表示領域Ｆ６には、契約条件の入力欄が表示されている。即ち、契約条件として、消費税率、賃料、共益費（管理費）、敷金、礼金、保証金、敷引（解約時償却）、その他１及び２、入居人数、ペット飼育の可否、家具の有無（家具付きの物件であるかどうか）、短期解約違約金の有無（有りの場合はその内容）、更新の有無（有りの場合は契約期間）、更新料の有（有りの場合はその額）、更新事務手数料の有無（有りの場合はその額）についての入力欄が表示されている。

図１５の例では、契約条件のうち「消費税」は、「８％」がデフォルト値として設定されている。

契約条件のうち「賃料」の入力欄には、月額として「１２００００」円が入力されている。そして、当該入力欄の右側には、「上限オーバーです。上限は９００００円です。」というメッセージが表示されている。この表示は、上述のソフトウェアボタンＢ５４が押下されたことにより実行された規程チェックの結果を示すメッセージである。即ち、このメッセージは、賃料として入力された額（１２００００円）が、社内規程に適合しないことを示すメッセージとなっている。
契約条件のうち「共益費（管理費）」の入力欄には、月額として「３０００」円が入力されている。

契約条件のうち「敷金」の入力欄には、「０」円が入力されている。また、当該入力欄の右側には、「※敷金免除」というメッセージが表示されている。この表示は、契約上敷金が免除されていることを示すメッセージである。

契約条件のうち「礼金」の入力欄には、「２４００００」円が入力されている。そして、当該入力欄の右側には、「上限オーバーです。家賃上限の２ケ月分を超過しています。」というメッセージが表示されている。この表示は、上述のソフトウェアボタンＢ５４が押下されたことにより実行された規程チェックの結果を示すメッセージである。即ち、このメッセージは、礼金として入力された額（２４００００円）が、社内規程に適合しないことを示すメッセージとなっている。

契約条件のうち「保証金」の入力欄には、「０」円が入力されている。契約条件のうち「敷引（解約時償却）」の入力欄には、「０」円が入力されている。
また、契約条件のうち「その他１」及び「その他２」の夫々の入力欄はブランクとなっている。これらの入力欄は、契約時に取り決めるべき額がある場合に利用される入力欄である。

契約条件のうち「入居人数」の入力欄には、「１」人が入力されている。
契約条件のうち「ペット飼育」の入力欄には、「不可能」が入力（選択）されている。
なお、「ペット飼育」の可否は、プルダウンボタンＢ６１を押下する操作を行うことで選択することができる。
契約条件のうち「家具」の入力欄には、「なし」が入力（選択）されている。なお、「家具」の有無は、プルダウンボタンＢ６２を押下する操作を行うことで選択することができる。
契約条件のうち「短期契約違約金」の入力欄には、「あり」が入力（選択）されている。そして、その内容として、契約期間が「１」年未満に解約された場合、賃料の「１」ケ月分の違約金が発生する旨が入力されている。なお、「短期契約違約金」の有無は、プルダウンボタンＢ６３を押下する操作を行うことで選択することができる。
契約条件のうち「更新」の入力欄には、「あり」が入力（選択）されている。そして、その内容として、「２」年毎に契約が更新される旨が入力されている。なお、「更新」の有無は、プルダウンボタンＢ６４を押下する操作を行うことで選択することができる。
契約条件のうち「更新料」の入力欄には、「なし」が入力（選択）されている。このため、更新料を入力する欄はブランクになっている。なお、「更新料」の有無は、プルダウンボタンＢ６５を押下する操作を行うことで選択することができる。
契約条件のうち「更新事務手数料」の入力欄には、「あり」が入力（選択）されている。そして、その内容として、契約事務手数料を「１０８００」円（税込）とし、そのうち消費税額を「８００」円とする旨が入力されている。なお、「更新事務手数料」の有無は、プルダウンボタンＢ６５を押下する操作を行うことで選択することができる。

表示領域Ｆ７には、表示領域Ｆ６の各入力項目に入力された内容を対象とする規程チェックの結果が表示される。
図１５の例では、規程チェックの結果として、「規程チェックの結果、２箇所のエラーがあります。」というメッセージが表示されている。そして、そのエラーの具体的内容として、上述の内容（賃料の上限をオーバーしているという内容、及び礼金の上限をオーバーしているという内容）が表示領域Ｆ７に表示される。

不動産業者Ｒは、不動産会社端末４を操作して、上述の入力項目毎の入力欄に所定情報を入力することで、契約情報の登録を行うと同時に、規程チェックを受けることができる。
これにより、社内規程に適合しない不動産（物件）を契約の対象としてしまうことを防ぐことができる。

図１６は、借上社宅管理サービスを提供するサービス提供者が操作する提供者端末に表示されるＵＩの具体例を示す図である。

図１６に示すように、借上社宅管理サービスを提供するサービス提供者Ｇが操作する提供者端末に表示されるＵＩは、表示領域Ｆ８乃至Ｆ１１を含むように構成される。なお、図１６に示すＵＩは一例にすぎない。例えば表示領域Ｆ８乃至Ｆ１１に表示された入力項目以外の入力項目を設けてもよい。

表示領域Ｆ８には、「借上社宅管理システム」という表記と、借上社宅管理サービスを利用する会社Ｃの名称、会社Ｃに属する社員Ｕの名前、及び社員Ｕが入居中又は入居予定の不動産（物件）の名称を示す表記と、借上社宅管理サービスの提供を受ける企業についての注意事項と、社員Ｕが各種申請（入居申請や退去申請）を行う際における注意事項とが表示されている。
また、表示領域Ｆ８には、申請ステータス、交渉ステータス、督促中、承認中、受付担当、受付中理由（受け付け中である場合の理由）、交渉担当者、入力担当者、トラブル担当者、社員Ｕによる申請の日時、サービス提供者Ｇによる受付けの日時、申請番号、旧申請番号、申請対策１及び２、ドラフト書類の到着日、規程チェックが行われた日及びその結果、入居日、契約日、支払日、及び承認日の夫々についての情報が表示されている。
また、表示領域Ｆ８には、表示領域Ｆ９乃至日Ｆ１１に表示させる情報の種類を選択するためのタブが表示されている。具体的には、申請情報、受付情報、交渉情報、物決情報、契約詳細情報、及び規程チェックの夫々を示すタブが複数表示されている。

図１６の例では、表示領域Ｆ８に表示された複数のタブのうち、「契約詳細情報」の内容を示すタブが選択されている。このため、表示領域Ｆ９乃至Ｆ１１の夫々には、契約に関する詳細な情報が表示される。このうち表示領域Ｆ９には、「契約ヘッダ」という表記と、その内容として、契約企業コード、契約企業名、契約書番号、管理番号、リクエスト番号、契約内容、登録時における備考、入力情報、及び規程チェックの夫々の情報が表示される。図１６の例では、契約内容について「住宅＋駐車場」が示されている。
また、表示領域Ｆ９には、「修正登録」と表記されたソフトウェアボタンＢ９１が表示されている。このボタンを押下することで登録内容を修正することができる。

表示領域Ｆ１０には、「所有者」という表記と、所有者を一意に識別する表記（例えば「所有者１」、「所有者２」、及び「所有者３」等）と、所有者名と、法人か個人かの表記と、法人番号と、マイナンバーと、持ち分比率を設定するための入力欄とが表示されている。また、所有者として入力されている情報を削除するためのソフトウェアボタンＢ１８２が所有者毎に配置されている。
また、「家主枠追加」と表記されたソフトウェアボタンＢ１８３が配置されている。サービス提供者Ｇは、ソフトウェアボタンＢ１８３を押下する操作を行うことで、所有者の欄を増やすことができる。

表示領域Ｆ１１には、「貸主」という表記と、貸主を一意に識別する表記と、貸主名と、法人か個人かの表記と、法人番号と、マイナンバーと、海外移住の有無についての入力欄とが表示されている。

図１７は、借上社宅管理サービスを提供するサービス提供者が操作する提供者端末に表示されるＵＩの具体例のうち、規程チェックのＵＩを示す図である。

図１７に示すように、借上社宅管理サービスを提供するサービス提供者Ｇが操作する提供者端末に表示されるＵＩにおいて規程チェックの内容を設定することができる。
具体的には、規程チェックの内容として、規程チェックの項目、条件、結果、及び交渉結果が表示されている。
図１７の例では、規程チェックの項目が「住宅：家賃」であり、契約条件が「８万（円）まで」であり、（規程チェックの）結果が「規程外」である例と、規程チェックの項目が「住宅：通勤時間」であり、条件が「１５分以内」であり、（規程チェックの）結果が「企業報告」である例と、規程チェックの項目が「駐車場：駐車場」であり、契約条件は認められず、（規程チェックの）結果が「規程外」である３種類の例が示されている。「交渉結果」の入力欄は、図１７の例ではブランクとなっている。
また、「登録」と表記されたボタンＢ１９１が押下れると規程チェックの内容（条件）登録をすることができる。

また、規程チェックの対象として、以下の内容に基づいたチェックを行うこともできる。即ち、専有面積の上限、間取りの上限、不動産（物件）の構造、不動産（物件）のタイプ、通勤時間、通勤手当、家賃上限、管理共益費の上限、管理共益費の有無、敷金の上限、敷引償却の上限、礼金条件、内装工事費契約可否、敷引金変動、仲介手数料上限、更新料上限、更新事務手数料上限、仲介業者の指定の有無（住宅及び駐車場）、転貸の可否（住宅及び駐車場）庭付き可否、建物分譲、階数制限、オートロック必須の有無、ロフト付き有無、バストイレ共同可否、定借可否、連名契約可否（住宅）、連名契約可否（駐車場）、契約者の風貌、ＵＲ物件の可否、住宅金融支援機であることの構物件可否、ペット飼育の可否（敷金・礼金・償却）値上げ率指定物品可否、住宅フリーレント契約の可否（住宅・駐車場）、解約違約金契約可否（住宅・駐車場）、賃料精算契約可否、家具付き物件可否入居者入替不可物件、解約予告１ケ付超可否（住宅・駐車場）、海外家主解約可否（住宅・駐車場）、１９８１年以前の物件の可否、築年数制限、防災警戒物件契約可否、契約不可取引有無（住宅・駐車場）、入居時鍵交換費用必須任意の区別、電子キー電池交換費用負担区分、入退去時クリーニング発生可否、防虫・消毒発生可否、ストーブ費用発生可否、ゴミ処理費、２４時間サービス、町内会費等負担区分、設備費ＲＪ支払必須物件、公共料金負担区分、駐輪場負担区分、駐車場契約可否、駐車場契約可能台数、駐車場代上限、駐車場プレート代上限、駐車場敷金上限、駐車場礼金上限、駐車場仲介手数料上限、駐車場解約予告期間制限、駐車場更新料上限、駐車場更新事務手数料上限、駐車場契約形態指定、保管場所発行手数料発生契約、駐車場まとめ払い上限、契約開始日指定部、入居日における乖離チェック（住宅、駐車場）、契約日のかい離チェック（住宅、駐車場）、契約条件差異発生時報告承認の要否（住宅、駐車場）、入居者の入れ替え（手数料、ハウスクリーニング、エアコンクリーニング、鍵交換、補修費用、及び残骸物処理）等に基づいたチェックを行うことができる。

以上を換言すると、本発明が適用される情報処理装置は、次のような構成を有する各種各様の実施形態を取ることができる。
即ち、本発明が適用される情報処理装置（例えば図３及び図４のサーバ１）は、
所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する検索条件生成手段（例えば図４の不動産検出条件生成部５２）と、
複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する不動産検索制御手段（例えば図４の不動産抽出部５３）と、
を備える。

本発明が適用される情報処理装置は、このような構成を有するため、不動産を検索するユーザ（社員等）の属性に関する規程（社内規程等）に適合した不動産に関する情報を、効率的に検索することができる。

１・・・サーバ、２・・・会社端末、３−１乃至３−ｎ・・・社員端末、４・・・不動産会社端末、１１・・・ＣＰＵ、１２・・・ＲＯＭ、１３・・・ＲＡＭ、１４・・・バス、１５・・・入出力インターフェース、１６・・・出力部、１７・・・入力部、１８・・・記憶部、１９・・・通信部、２０・・・ドライブ、２１・・・リムーバブルメディア、３１・・・会社側連絡部、３２・・・社員側連絡部、３３・・・転居管理部、３４・・・不動産検索部、３５・・・引越し見積り部、３６・・・社内申請支援部、４１・・・社員ＤＢ、４２・・・会社ＤＢ、４３・・・不動産ＤＢ、４４・・・引越し会社ＤＢ、５１・・・社員要望取得部、５２・・・不動産検出条件生成部、５３・・・不動産抽出部、５４・・・不動産提示部、６０・・・不動産会社側連絡部、６１・・・会社側連絡部、６２・・・社員側連絡部、６３・・・転居管理部、６４・・・不動産検索部、６５・・・引越し見積り部、６６・・・社内申請支援部、７１・・・社員ＤＢ、７２・・・会社ＤＢ、７３・・・不動産ＤＢ、７４・・・引越し会社ＤＢ、Ｂ１〜Ｂ５・・・物件情報、Ｃ１〜Ｃ３・・・図面、Ｄ１〜Ｄ３・・・不動産詳細、Ｎ・・・ネットワーク、Ｓ１〜Ｓ１４・・・ステップ、Ｆ・・・表示領域、Ｂ１１〜Ｂ１９１各ボタン

Claims (6)

1. 所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する検索条件生成手段と、
   複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する不動産検索制御手段と、
   を備える情報処理装置。
2. 前記不動産検索制御手段による検索の対象となる前記データベースは、前記情報処理装置の管理者以外の者が管理するデータベースである、
   請求項１に記載の情報処理装置。
3. 前記不動産検索制御手段は、前記検索条件として、前記所定の団体の規程の範囲内で成立可能となる条件を生成する、
   請求項１又は２に記載の情報処理装置。
4. 前記不動産検索制御手段は、前記検索条件として、前記所定の団体の規程の範囲外であるが前記ユーザの負担により成立可能となる条件を生成する、
   請求項１乃至３のうち何れか１項に記載の情報処理装置。
5. 情報処理装置が実行するステップとして、
   所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する検索条件生成ステップと、
   複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する不動産検索制御ステップと、
   を含む情報処理方法。
6. コンピュータに、
   所定団体に属するユーザの属性に関する当該所定団体の規程に基づいて、当該ユーザが使用可能な不動産の検索条件を生成する検索条件生成ステップと、
   複数の不動産に関する情報が格納されたデータベースから、生成された前記検索条件に合致する不動産に関する情報を検索する処理の制御を実行する不動産検索制御ステップと、
   を含む制御処理を実行させるプログラム。

Images