JP2020197962A - チャットを用いたアクティビティ管理方法及び管理サーバ - Google Patents

Abstract

【課題】チャットを用いてオーナーの所有する資産に対するアクティビティ管理を行うアクティビティ管理方法、管理サーバ、及びプログラムを提供する。【解決手段】チャットを用いたアクティビティ管理方法であって、不動産物件のオーナーに確認を取る必要のあるアクティビティ一覧を記憶しており、不動産物件の選択を受け付け、アクティビティ一覧からアクティビティの選択を受け付け、選択された不動産物件のアクティビティに関する不動産物件情報を取得し、取得した不動産物件情報を入力したアクティビティカードを生成し、オーナーとの間でメッセージのやり取りがなされているチャットにアクティビティカードを投稿する。【選択図】図３３

Description

本発明は、チャットを用いたアクティビティ管理方法及び管理サーバに関する。

本技術分野の背景技術として、特開２０１７−２２４２０７号公報（特許文献１）がある。この公報には、「賃貸物件の賃借料の設定の際に、賃貸物件の構造情報及び主観的評価を参照するため、自主管理家主は周辺エリアの類似物件の賃貸料相場から極端に乖離することがなく且つ期待可能な最大収益を狙った賃貸料を自分で容易に設定できる。また、不動産物件の客付けを依頼する仲介不動産業者及び各営業担当者に関するランク情報を管理するため、自主管理家主は賃貸斡旋の依頼をする際に各賃貸物件に適したランクの仲介不動産事業者又は各営業担当者を選択できる。さらに、退去時の原状回復に必要な修繕工事や清掃作業に関連する事業者の情報をランク別に記憶するため、複数の事業者の中から各賃貸物件に適した事業者を容易に見つけ出すことが可能である。」と記載されている（要約参照）。

また、特開２０１７−１３８９３２号公報（特許文献２）がある。この公報には、「システム利用者を認証する認証部１４と、認証部１４により認証されたシステム利用者が営業者の場合には、第１権限を付与し、認証部１４により認証されたシステム利用者が顧客の場合には、第１権限とは異なる第２権限を付与する権限付与部１５と、顧客情報を登録する顧客情報登録部１６と、顧客情報と物件情報とを関連付けて所有情報を登録する所有情報登録部１７と、所有情報登録部１７により登録された所有情報を記憶する所有情報記憶部１８と、顧客ごとの管理用Ｗｅｂページを生成するページ生成部１９と、入力された情報に基づいてシミュレーションを実行するシミュレーション実行部２０とを備える。」と記載されている。

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

前記特許文献１には、賃貸収益物件の管理の仕組みが記載されている。また、前記特許文献２には、投資物件の収益性シミュレーションを実行する仕組みが記載されている。しかしながら、いずれの特許文献においても、顧客とのコミュニケーション方法について検討がなされていない。
そこで、本発明は、チャットを用いてオーナーの所有する資産に対するアクティビティ管理を行う仕組みを提供する。

上記課題を解決するために、例えば特許請求の範囲に記載の構成を採用する。
本願は上記課題を解決する手段を複数含んでいるが、その一例を挙げるならば、チャットを用いたアクティビティ管理方法であって、不動産物件のオーナーに確認を取る必要のあるアクティビティ一覧を記憶しており、前記不動産物件の選択を受け付け、前記アクティビティ一覧から前記アクティビティの選択を受け付け、選択された前記不動産物件の前記アクティビティに関する不動産物件情報を取得し、取得した前記不動産物件情報を入力したアクティビティカードを生成し、前記オーナーとの間でメッセージのやり取りがなされているチャットに前記アクティビティカードを投稿することを特徴とする。

本発明によれば、チャットを用いてオーナーの所有する資産に対するアクティビティ管理を行う仕組みを提供することができる。
上記した以外の課題、構成及び効果は、以下の実施形態の説明により明らかにされる。

全体の資産管理システム１の構成図の例である。 管理サーバ１０１のハードウェア構成の例である。 オーナー端末１０２のハードウェア構成の例である。 資産管理会社端末１０３のハードウェア構成の例である。 ユーザ情報５００の例である。 トピックカテゴリ情報６００の例である。 アクティビティカテゴリ情報７００の例である。 アクティビティマスター情報８００の例である。 アクティビティ詳細情報９００の例である。 メッセージ情報１０００の例である。 アクセストークン情報１１００の例である。 資産管理情報１２００の例である。 チャット画面１３００の例である。 トピック作成画面１４００の例である。 アクティビティ詳細入力画面１５００の例である。 アクティビティカードプレビュー画面１６００の例である。 アクティビティカード投稿画面１７００の例である。 アクティビティ否認画面１８００の例である。 アクティビティ承認画面１９００の例である。 アクティビティ詳細画面２０００の例である。 通知設定画面２１００の例である。 アクティビティ一覧画面２２００の例である。 アクティビティ詳細画面２３００の例である。 アクティビティマスター画面２４００の例である。 アクティビティマスター追加画面２５００の例である。 チャット画面２６００の例である。 アクティビティ詳細画面２７００の例である。 アクティビティ承認画面２８００及び否認画面２８５０の例である。 否認後チャット画面２９００の例である。 アクティビティ一覧画面３０００の例である。 アクティビティフィルタ画面の例である。 資産管理画面３２００の例である。 アクティビティカード投稿処理フロー３３００の例である。 アクティビティカード表示・回答処理フロー３４００の例である。 オーナー確認回答受領処理フロー３５００の例である。 アクティビティカード一覧表示処理フロー３６００の例である。

以下、実施例を図面を用いて説明する。
図１は、全体の資産管理システム１の構成図の例である。
資産管理システム１は、複数のオーナー端末１０２、複数の資産管理会社端末１０３を備え、それぞれがネットワークを介して管理サーバ１０１に接続されている。なお、ネットワークは有線、無線を問わず、それぞれの端末はネットワークを介して情報を送受信することができる。
オーナー端末１０２は、投資用不動産など資産を所有するオーナーが使用する端末である。
資産管理会社端末１０３は、資産を管理する資産管理会社が使用する端末である。

資産管理システム１のそれぞれの端末や管理サーバ１０１は、例えば、スマートフォン、タブレット、携帯電話機、携帯情報端末（ＰＤＡ）などの携帯端末（モバイル端末）でもよいし、メガネ型や腕時計型、着衣型などのウェアラブル端末でもよい。また、据置型または携帯型のコンピュータや、クラウドやネットワーク上に配置されるサーバでもよい。また、機能としてはＶＲ（仮想現実：Virtual Reality）端末、ＡＲ端末、ＭＲ（複合現実：Mixed Reality）端末でもよい。あるいは、これらの複数の端末の組合せであってもよい。例えば、１台のスマートフォンと１台のウェアラブル端末との組合せが論理的に一つの端末として機能し得る。またこれら以外の情報処理端末であってもよい。

資産管理システム１のそれぞれの端末や管理サーバ１０１は、それぞれオペレーティングシステムやアプリケーション、プログラムなどを実行するプロセッサと、ＲＡＭ（Random Access Memory）等の主記憶装置と、ＩＣカードやハードディスクドライブ、ＳＳＤ（Solid State Drive）、フラッシュメモリ等の補助記憶装置と、ネットワークカードや無線通信モジュール、モバイル通信モジュール等の通信制御部と、タッチパネルやキーボード、マウス、音声入力、カメラ部の撮像による動き検知による入力などの入力装置と、モニタやディスプレイ等の出力装置とを備える。なお、出力装置は、外部のモニタやディスプレイ、プリンタ、機器などに、出力するための情報を送信する装置や端子であってもよい。

主記憶装置には、各種プログラムやアプリケーションなど（モジュール）が記憶されており、これらのプログラムやアプリケーションをプロセッサが実行することで全体システムの各機能要素が実現される。なお、これらの各モジュールは集積化する等によりハードウェアで実装してもよい。また、各モジュールはそれぞれ独立したプログラムやアプリケーションでもよいが、１つの統合プログラムやアプリケーションの中の一部のサブプログラムや関数などの形で実装されていてもよい。

本明細書では、各モジュールが、処理を行う主体（主語）として記載をしているが、実際には各種プログラムやアプリケーションなど（モジュール）を処理するプロセッサが処理を実行する。
補助記憶装置には、各種データベース（ＤＢ）が記憶されている。「データベース」とは、プロセッサまたは外部のコンピュータからの任意のデータ操作（例えば、抽出、追加、削除、上書きなど）に対応できるようにデータ集合を記憶する機能要素（記憶部）である。データベースの実装方法は限定されず、例えばデータベース管理システムでもよいし、表計算ソフトウェアでもよいし、ＸＭＬ、ＪＳＯＮなどのテキストファイルでもよい。

図２は、管理サーバ１０１のハードウェア構成の例である。
管理サーバ１０１は、例えばクラウド上に配置されたサーバで構成される。
主記憶装置２０１には、アクティビティ管理モジュール２１１、データ登録管理モジュール２１２、資産登録管理モジュール２１３等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ２０３が実行することで管理サーバ１０１の各機能要素が実現される。

アクティビティ管理モジュール２１１は、オーナー端末との間でチャット機能を提供し、またオーナーの所有する不動産等の資産に対するアクティビティを管理する。以降不動産物件のアクティビティ管理について記載するが、不動産だけに限られず、自動車、宝石、ジェット機などの動産や、株や証券、貯蓄などの金融資産など、広く資産管理に対して適用できる。

アクティビティとは、管理する不動産物件等資産に対してオーナーの確認を要する様々な確認事項のことである。例えば、退去報告、入居者募集、原状回復、工事、更新、収支報告書、滞納督促、税金、修繕提案、売却査定提案、その他について、オーナーに報告や提案、通知を行い、オーナーから確認、承認等を得る必要のある事項のことである。
なお、「確認」とは、確認と承認を含めた意味で用いることもある。

データ登録管理モジュール２１２は、ユーザ情報やアクティビティに関する情報など登録し、管理する。
資産登録管理モジュール２１３は、オーナーや資産管理会社が保有する資産の情報を資産管理情報１２００に登録し、管理する。またこれらの資産の情報をオーナー端末１０２のオーナー資産管理モジュール３１０と連携して、オーナー端末に表示する。

本実施例では、アクティビティ管理モジュール２１１がチャット機能を提供するが、チャット機能は別に構成したチャット管理モジュールが提供することとしてもよい。また、チャット機能を管理サーバ１０１とは別に構成したチャット管理サーバのチャット管理モジュールが提供する実装としてもよい。
資産の登録管理は、管理サーバ１０１と別に構成した資産情報管理サーバの資産登録管理モジュールが提供する実装としてもよい。

補助記憶装置２０２は、メインＤＢ２２０を備える。
メインＤＢ２２０は、ユーザ情報５００や、アクティビティに関する情報であるトピックカテゴリ情報６００、アクティビティカテゴリ情報７００、アクティビティマスター情報８００、アクティビティ詳細情報９００や、チャットに関する情報であるメッセージ情報１０００、認証に関する情報であるアクセストークン情報１１００、管理する資産についての資産管理情報１２００等を記憶する。

図３は、オーナー端末１０２のハードウェア構成の例である。
オーナー端末１０２は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置３０１には、オーナー資産管理モジュール３１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ３０３が実行することでオーナー端末１０２の各機能要素が実現される。

オーナー資産管理モジュール３１０は、管理サーバ１０１の資産登録管理モジュール２１３と連携し、オーナーの所有する不動産等の資産の物件情報や現在価値、キャッシュフロー等を表示する。
補助記憶装置３０２は、オーナーが所有する資産についての情報であるオーナー資産管理情報３２０を記憶する。

図４は、資産管理会社端末１０３のハードウェア構成の例である。
資産管理会社端末１０３は、例えばスマートフォン、タブレット、ノートＰＣ、デスクトップＰＣ等の端末で構成される。
主記憶装置４０１には、管理会社資産管理モジュール４１０等のプログラムやアプリケーションが記憶されており、これらのプログラムやアプリケーションをプロセッサ４０３が実行することで資産管理会社端末１０３の各機能要素が実現される。

管理会社資産管理モジュール４１０は、管理サーバ１０１の資産登録管理モジュール２１３と連携し、資産管理会社の管理する不動産等の資産の物件情報や収益情報等を管理サーバ１０１に送信する。また、オーナーの不動産物件に対するアクティビティに関する確認情報などを受領する。
補助記憶装置４０２は、資産管理会社が管理する資産についての情報である管理会社資産管理情報４２０を記憶する。

図５〜図１２は、管理サーバに記憶されてる各種情報である。これらのすべて又は一部はＪＳＯＮ形式のファイルに記憶することを想定しているが、これに限られない。リレーショナルデータベースや、非リレーショナルデータベースに記憶される構成としてもよい。
図５は、ユーザ情報５００の例である。
ユーザ情報５００は、アクティビティ管理モジュール２１１によりアクティビティを管理する対象であるユーザに関する情報を記憶する。例えば不動産のオーナーなどの情報が記憶されている。

ユーザ情報５００は、ユーザＩＤ５０１、ユーザ表示ＩＤ５０２、役職５０３、所在５０４、属性タグ５０５等を有しており、それぞれフィールド名５３０に対してサンプル値５４０で例示するような値が入力されている。
ユーザＩＤ５０１は、自動的に生成されるハッシュ値などのユニークなＩＤであり、他の情報から参照される主キーである。

ユーザ表示ＩＤ５０２は、管理サーバ１０１やオーナー端末１０２等の画面に表示するユーザのＩＤであり、例えばUSER-1234等の自動的に生成されるユニークなＩＤである。
役職５０３は、ユーザの役職ないしは役割を示す。
所在５０４は、ユーザの所在や言語、地域等を示す。
属性タグ５０５は、各ユーザの属性に対してつけるタグを示す。例えば、東京オフィスの人である旨や、渋谷区の人である旨などをタグ付けすることができる。

図６は、トピックカテゴリ情報６００の例である。
トピックカテゴリ情報６００は、チャットで交わされる会話が属するトピック（項目）の一覧を記憶する。
トピックカテゴリ名６０１は、トピックの内容を示す。例えば、退去報告、入居者募集、原状回復、工事、更新、収支報告書、滞納督促、税金、修繕提案、売却査定提案、等のトピックが記憶される。
トピックカテゴリＩＤ６０２は、各トピックにつけられるユニークなＩＤである。例えばハッシュ値等が記憶される。

図７は、アクティビティカテゴリ情報７００の例である。
アクティビティカテゴリ情報７００は、アクティビティ管理モジュール２１１が使用する各アクティビティの属するカテゴリ一覧を記憶する。
アクティビティカテゴリ名７０１は、アクティビティカードが属するタイプを示す。例えば、費用承認、賃貸条件承認等が記憶される。
アクティビティカテゴリＩＤ７０２は、カテゴリのＩＤであり、他の情報から参照される主キーであって、自動的に生成されるユニークなＩＤである。

図８は、アクティビティマスター情報８００の例である。
アクティビティマスター情報８００は、各アクティビティの内容を記憶する。予め一般的に使用されるアクティビティの情報が記憶されているが、ユーザや管理者が新たにアクティビティを追加することもできる。
アクティビティマスター名８０１は、アクティビティマスターの名前を示す。ユーザ記入の場合には、自由に記述することができる。

アクティビティマスタータイプ８０２は、アクティビティマスターのタイプを示す。あらかじめセットされた値から選択されるもので、例えば、承認、通知、契約等が記憶される。承認タイプ（Approval）は、オーナーから確認事項の承認を得るために、承認依頼を送るものである。オーナーから承認（Approval)又は否認（Decline）の入力を受け付ける。通知タイプ（Notice）は、オーナーに確認事項の確認をしてもらうために、確認依頼を送るものである。オーナーからは確認ボタンの入力を受け付ける。契約タイプ（Contract）は、オーナーから電子承認を得るために、電子承認依頼を送るものである。オーナーに電子契約サービス用いた電子承認の入力を受け付ける。
アクティビティカテゴリＩＤ８０３は、アクティビティのカテゴリを示す。アクティビティカテゴリ情報７００のアクティビティカテゴリＩＤ７０２の値を参照する。
アクティビティマスター目的８０４は、アクティビティマスターの目的を示す。ユーザや管理者が自由に記述することができる。

タイトル８０５は、アクティビティと関連して送信されるチャットメッセージに使われるタイトルを示す。自由に記述することができる。
内容８０６は、アクティビティと関連して送信されるチャットメッセージの本文内容を示す。予め決められた内容が記載されているが、自由に記述することもできる。例えば、サンプル値８２３に記載するように、支出に対して、ルーム清掃費用、壁紙張替費用、畳替え費用、ドア鍵変更費用等があらかじめ決められた内容例として、記入されている。
宛先ユーザ８０７は、アクティビティカードを送付する先であるユーザを示す。

添付８０８は、添付して送付されるファイルへのパスを示す。
表示ＩＤ８０９は、管理サーバ１０１やオーナー端末１０２等の画面に表示するアクティビティのＩＤであり、例えばACT-1234等の自動的に生成されるユニークなＩＤである。
アクティビティマスターＩＤ８１０は、アクティビティマスターに対して生成されるユニークなＩＤを示す。
削除フラグ８１１は、アクティビティマスターが削除されているかどうかを示す。

図９は、アクティビティ詳細情報９００の例である。
アクティビティ詳細情報９００は、各アクティビティの詳細情報を記憶する。
アクティビティメッセージ内容９０１は、アクティビティの内容を示す。アクティビティマスターから呼び出した情報に対して、金額を入力する、記述を追加する等により、メッセージを更新して記憶する。
例えばサンプル値９４０の例では、支出として、アクティビティマスターの内容８０６から読み出したルーム清掃費用、壁紙張替費用、畳替え費用、ドア鍵変更費用に対して、金額を入力して記憶する。

これらの金額は、ユーザや管理者が入力することとしてもよいが、データ登録管理モジュール２１２や資産登録管理モジュール２１３が、オーナーが所有する過去の同じ不動産物件に対するアクティビティや過去の資産の管理情報を、資産管理情報１２００等メインＤＢ２２０に記憶されている過去の情報から取得して、それらに基づいて入力する構成としてもよい。
また、同じオーナーが所有する不動産物件だけでなく、他のオーナーが所有する同一物件の情報や、入力対象の物件に類似する物件、入力対象の物件の周辺の物件、等の情報に基づいて値を記入する構成としてもよい。

アクティビティメッセージ送付日９０２は、アクティビティに対応するメッセージを送付した日時を示す。
ステータス９０３は、アクティビティのステータスを示す。例えば、承認、否認などの情報が記憶される。
ユーザＩＤ９０４は、アクティビティを送付したユーザを示す。

アクティビティマスターＩＤ９０５は、アクティビティマスターのＩＤを示す。アクティビティマスター情報８００のアクティビティマスターＩＤ８１０を参照する。
メッセージＩＤ９０６は、アクティビティに対応して送付されたメッセージを示すＩＤである。メッセージ情報１０００のメッセージＩＤ１００７を参照する。

図１０は、メッセージ情報１０００の例である。
メッセージ情報１０００は、チャット上で送受信されるメッセージの内容を記憶する。
メッセージ内容１００１は、メッセージの内容を示す。例えば、サンプル値１０４０の例の様に、オーナーとの間でやり取りされるメッセージが記憶されている。
ユーザタイプ１００２は、メッセージを送信するユーザのタイプ（属性）を示す。例えば、ＰＭ（資産管理会社：Property Management会社）オペレータや、オーナー等が記憶される。
拡張領域１００３は、自由に拡張できる領域である。

既読日時１００４は、メッセージが既読となった日時のタイムスタンプを記憶する。
送信者ＩＤ１００５は、メッセージを送信したユーザのＩＤを示す。ユーザ情報５００のユーザＩＤ５０１の値が入力され、参照されるか、又はアクセストークン情報１１００のトークンＩＤ１１０２の値が入力され、参照される。
トピックカテゴリ１００６は、メッセージがどのトピックに属しているかを示す。トピックカテゴリ情報６００のトピックカテゴリＩＤの値を参照する。
メッセージＩＤ１００７は、各メッセージに対して生成されるユニークなＩＤを示す。

図１１は、アクセストークン情報１１００の例である。
アクセストークン情報１１００は、ユーザの認証のために使用されるトークンである。
認証トークン１１０１は、ランダムに生成されるトークンを示す。
トークンＩＤ１１０２は、自動的に生成されるユニークなＩＤであり、主キーである。

図１２は、資産管理情報１２００の例である。
資産管理情報１２００は、オーナーが所有する不動産等の資産や、資産管理会社が管理する不動産等の資産についての情報を記憶する。
例えば、資産ＩＤ１２０１、名称１２０２、住所１２０３、資産タイプ１２０４等、資産を特定する情報や、これらの資産に対する収益情報、現在価値、キャッシュフローなどを記憶する。
資産管理情報１２００は、リレーショナルデータベースなどにより、多数の資産に関する情報を記憶するが、記憶形式はこれに限定されない。

図１３は、チャット画面１３００の例である。
管理サーバ１０１の、アクティビティ管理モジュール２１１は、管理している複数のオーナーに関する情報１３０１の中の特定のオーナー１３０２に対して、所有しているそれぞれの資産についてのチャットのやり取り１３０３を一覧表示する。
アクティビティ管理モジュール２１１は、ユーザから特定の物件の表示指示を受け付けた場合には、特定の物件についてのチャットのやり取りをチャットウィンドウ１３１０に表示する。チャットウィンドウ１３１０には、管理サーバ１０１を操作するオペレータからのメッセージ１３０４と、それに対するオーナーからのメッセージ１３０５がチャット形式で表示される。

オペレータは、オーナーに対して複数のトピックと呼ばれる、チャットルームを作成することができる。例えば「税金に関して」や「物件Ａの修繕に関して」など、自由にトピックを作成することができる。オペレータがオーナーを選択し、トピック作成ボタン１３３０をクリックすると、トピック作成画面１４００を表示する。
オペレータは、オーナーに対して承認、通知、契約などの確認事項を連絡したい場合には、アクティビティ作成ボタン１３２０を選択し、アクティビティカード投稿処理を行う。

図１４は、トピック作成画面１４００の例である。
オペレータがトピック作成ボタン１３３０を押した場合に、アクティビティ管理モジュール２１１が、トピック作成画面１４００を表示する。
オペレータは、トピック作成画面１４００において、トピック１４０１を入力し、トピックカテゴリ１４０２から対象となるトピックを選択する。なお、トピックカテゴリ１４０２の選択に応じて対応するトピック名称がトピック１４０１に自動的に入力されるようにしてもよい。
アクティビティ管理モジュール２１１は、オペレータから対象資産の選択を受け付ける。オペレータはオーナーの所有する資産を資産選択領域１４０３からプルダウンで選択する。

図３３は、アクティビティカード投稿処理フロー３３００の例である。
管理サーバ１０１を操作するオペレータが、不動産物件のオーナーに確認を取る必要がある場合に、アクティビティ管理モジュール２１１が、アクティビティカードを生成し、チャットによりオーナーに問い合わせを行う。なお、管理サーバ１０１のオペレータだけでなく、管理会社資産管理モジュール４１０により、アクティビティ管理モジュール２１１を介して、資産管理会社のオペレータが問い合わせを行う構成であってもよい。

オペレータがアクティビティ作成ボタン１３２０を押した場合に、アクティビティ管理モジュール２１１が、アクティビティ選択画面１５５０を表示する（ステップ３３１０）。
アクティビティ管理モジュール２１１は、オペレータからアクティビティの選択を受け付ける（ステップ３３２０）。
太字で示す部分１５５１等は、アクティビティカテゴリであり、システムで予め定義されている。細字で示す部分１５５２は、予めシステムで定義されているものの、オペレータが編集可能であり、また新たにアクティビティを追加することもできる。

なお、トピックカテゴリ１４０２が選択されている場合に、アクティビティ管理モジュール２１１が、このトピックカテゴリの中に属するアクティビティ一覧のみをポップアップ画面で表示する構成としてもよい。例えば、「入居者募集」というトピックカテゴリ１４０２が選択されている場合には、アクティビティ選択画面１５５０がポップアップし、入居者募集（Leasing）１５５１の配下の「入居条件承認（Approval for Leasing criteria）」「物件問合せ（Property inquiries）」「申請通知（Application notice）」「申請承認（Application approval）」などのアクティビティ１５５２が選択可能に表示され、オペレータからの選択を受け付ける。
なお、カテゴリ選択の後に、「入居者募集の条件承認」、入居者募集の条件確認など、承認、通知、契約など、カテゴリに応じて確認を取りたい内容を選択することとしてもよい。

アクティビティ管理モジュール２１１は、選択されたアクティビティに関するアクティビティ詳細入力画面１５００を表示して（ステップ３３３０）、オペレータから詳細情報の入力を受け付ける（ステップ３３４０）。
図１５は、アクティビティ詳細入力画面１５００の例である。
アクティビティタイトル１５１０はアクティビティの概要を示すタイトルである。
物件情報１５０１は、物件の情報を示す。この画面の中で変更可能である。
ターゲット部屋番号１５０２は、物件の中のオーナーの所有する対象の部屋を示す。
メッセージ１５０３は、アクティビティカードの送付に合わせてユーザに伝えたいメッセージの内容を記載する。
添付１５０４は、アクティビティカードと共に送付する添付書類を示す。

問い合わせタイトル１５１２には、問い合わせる内容のタイトルが表示される。問い合わせ内容１５１１には、オーナーの確認を得たい内容が記入され、確認のための数値情報等が記入される。
例えば、アクティビティ詳細入力画面１５００の例は、「入居条件についての承認」を得るというアクティビティに対する入力である。問い合わせ内容１５１１の入居条件として、賃料、管理費、敷金、鍵費用、礼金、広告、等の金額や数値や文章が記入され、オーナーの承認を受ける。
この問い合わせ内容１５１１には、資産管理情報１２００に記憶されている、対応する物件の過去の情報が呼び出され入力される。また、入力された情報を上書き更新することも可能である。

他には、資産登録管理モジュール２１３が管理する同一の不動産物件の他の部屋の入居条件の情報を資産管理情報１２００から取得し、アクティビティ管理モジュール２１１がこれを解析することで、同一物件の他の部屋の入居条件に基づいて調整した新たな入居条件を提示することもできる。この場合には、過去の入居条件との差分の部分だけ色を変える等ハイライトしてオーナーに提案し、確認を求める。
例えば、今までの賃料が１０１,０００円であったところ、他の部屋の賃料が１０３，０００円に上昇していた場合には、オーナーに提案する賃料を１０３,０００円に書き換えて赤色でハイライトしたアクティビティカードを生成し、オーナーに承認を求めることができる。

他には、同一の地域の類似物件の賃料の平均値から提案賃料を求める方法、過去から現在までの賃料の上昇または下降の推移をもとに提案賃料を求める方法、等が考えられる。
本実施例では、複数の資産管理会社が管理している複数の資産を、管理サーバ１０１で統合的に一元管理することで、複数の物件にまたがった統合的な情報をもとに、オーナーに確認を受けるための、問い合わせ内容を修正し、提案を行うことができる。

送信ボタン１５２０が押されると、アクティビティ管理モジュール２１１は、入力された情報及び、資産管理情報から呼び出され入力された情報をもとに、アクティビティカードを生成する（ステップ３３５０）。必要に応じて送信前確認画面を表示してもよい。
オペレータがアクティビティカードの内容を確認すると、アクティビティ管理モジュール２１１は、生成したアクティビティカードを、オーナーとの間でメッセージのやり取りがなされているチャットに投稿する（ステップ３３６０）。

図１７は、アクティビティカード投稿画面１７００の例である。
オーナーとオペレータの間でメッセージのやり取りがなされているチャットの中で、オペレータからのメッセージ１７０１と共に、アクティビティカード１７０２がメッセージと同じように投稿されている。アクティビティ詳細入力画面１５００のメッセージ１５０３で記入した内容が、チャットのメッセージ１７０１として投稿、表示される。なお、通常のチャットの中でオペレータがメッセージを入力することも可能である。
アクティビティカード１７０２には、アクティビティタイトル１７０３、表示ＩＤ１７０４、内容１７０５、添付１７０６が記載されている。
これらの情報は、アクティビティマスター情報８００の、それぞれ対応する項目に記憶される。

なお、チャット上でのアクティビティカードの送受信であるが、オーナー側のチャット画面のアクティビティカードには承認ボタン２７２０、否認ボタン２７３０が表示されるが、オペレータ側のチャット画面には承認ボタン、否認ボタンの表示を行わない。チャットの場合、通常送受信側で同じメッセージを表示するが、本実施例ではオペレータが承認、否認を行うことは無いため、混乱を生じないようにオペレータ側にはあえて承認、否認ボタンを表示しないようにする。但し、オペレータ側にこれらのボタンを表示することとしても構わない。

図１８は、アクティビティ否認画面１８００の例である。
オーナーが確認ボタン１７０７の否認（Decline：拒否）を選択してアクティビティカード表示・回答処理３４００を行った後に表示される画面の例である。
アクティビティ管理モジュール２１１は、否認した際にオーナーにより記入されたコメントを、チャットのメッセージ１８０１として表示する。
また、アクティビティ管理モジュール２１１は、否認した内容や理由を回答画面１８０２として表示する。

図１９は、アクティビティ承認画面１９００の例である。
オーナーが確認ボタン１７０７の承認（Approve）を選択してアクティビティカード表示・回答処理３４００を行った後に表示される画面の例である。
アクティビティ管理モジュール２１１は、承認した内容を回答画面１９０１として表示する。
承認の際には、特にオーナーにコメントの記入を求めないため、メッセージは表示されず、承認された旨の表示のみがなされる。但し、任意でオーナーがコメントを入力し、それがメッセージとしてチャットに投稿される仕組みとしてもよい。

図３５は、オーナー確認回答受領処理フロー３５００の例である。
アクティビティ管理モジュール２１１は、オーナー端末１０２のオーナー資産管理モジュール３１０により、チャット上で送信された回答情報（回答画面）を受領する(ステップ３５１０)。
アクティビティ管理モジュール２１１は、回答情報を解析し、取り込み（ステップ３５２０）、この内容に基づき、アクティビティ詳細情報９００のステータス９０３を更新する（ステップ３５３０）。

図２０は、アクティビティ詳細画面２０００の例である。
送信されたアクティビティや、オーナーから承認、否認、確認などを受けたアクティビティに対して、詳細情報を表示する。
アクティビティ詳細画面２０００には、今までオーナーとの間でやり取りを行ったアクティビティ履歴２００１として、オーナーの確認内容２００４、アクティビティカード２００３、アクティビティの詳細２００２などが表示される。

図２１は、通知設定画面２１００の例である。
アクティビティ管理モジュール２１１は、通知カテゴリ２１０１において選択したカテゴリのアクティビティに対してオーナーからメッセージや確認回答が送信された場合に、通知を表示する。

図２２は、アクティビティ一覧画面２２００の例である。
図３６は、アクティビティカード一覧表示処理フロー３６００の例である。
アクティビティ一覧画面２２００は、アクティビティ一覧表示ボタン２２０１が選択されることで表示される。
アクティビティ管理モジュール２１１は、表示するアクティビティ一覧の絞り込み条件を受け付ける（ステップ３６１０）。例えばオーナー名２２０２、カテゴリ名２２０３、アクティビティ名２２０４、ステータス２２０５、既読・未読２２０６、作成日２２０７等の情報をもとに絞り込みを行うことができる。

アクティビティ管理モジュール２１１は、絞り込み条件に従い、対応するアクティビティ情報を、アクティビティマスター情報８００及びアクティビティ詳細情報９００から取得する（ステップ３６２０）。
アクティビティ管理モジュール２１１は、取得した情報をアクティビティ一覧画面２２００に表示する（ステップ３６３０）。

アクティビティ一覧画面２２００の例は、特定のオーナーの賃貸（Leasing）に関するアクティビティ一覧を表示する例である。このオーナーの所有する複数の不動産物件２２１１に対して、カテゴリ２２１２が賃貸（Leasing）であるものが抽出されており、それぞれのアクティビティ２２１３の現在のステータス２２１４が一覧で表示される。
本実施例によれば、チャットと連携してオーナーとのコミュニケーションを図りながらそれぞれのアクティビティの現在のステータス一覧を表示及び管理することが可能であり、オペレータの不動産管理業務を容易にし、効率化が可能となる。

図２３は、アクティビティ詳細画面２３００の例である。
アクティビティ詳細画面２３００は、アクティビティ一覧画面２２００の中で特定のアクティビティを選択した場合に表示される。
選択されたアクティビティのアクティビティ履歴２３０２、オーナーの確認状況２３０４、アクティビティの詳細２３０３が表示される。

図２４は、アクティビティマスター画面２４００の例である。
管理サーバ１０１のオペレータは、アクティビティのカテゴリごとに、アクティビティを集計することができる。アクティビティ管理モジュール２１１は、アクティビティ一覧画面２２００と同様の条件によりフィルタされたアクティビティについて、対応するアクティビティ情報を、アクティビティマスター情報８００及びアクティビティ詳細情報９００から取得し、アクティビティマスター項目２４０１毎に集計して表示する。
送信済み件数２４０２、オーナーによる承認件数２４０３、オーナーによる確認件数２４０４等が集計されて表示される。

図２５は、アクティビティマスター追加画面２５００の例である。
オペレータがアクティビティマスター追加ボタン２４０５をクリックすると、アクティビティ管理モジュール２１１はアクティビティマスター追加画面２５００を表示する。
アクティビティ管理モジュール２１１は、予め複数のアクティビティ情報を登録しているが、オペレータは任意でアクティビティを追加することができる。
アクティビティ管理モジュール２１１は、アクティビティ名２５０１、アクティビティカテゴリ２５０２、アクティビティタイプ２５０３、目的２５０４、メッセージ２５０５、タイトル２５０６、内容２５０７等の入力を受け付け、アクティビティマスター情報８００に追記する。
アクティビティタイプ２５０３には、例えば承認（Approval）、通知（Notice）、契約（Contract）等の種類があり、オーナーに確認依頼を送りたい内容に応じて選択される。

図１６は、アクティビティカードプレビュー画面１６００の例である。
オペレータがプレビューボタン２５０８をクリックすると、アクティビティ管理モジュール２１１はアクティビティカードプレビュー画面１６００を表示する。
アクティビティカード１６０１は、問い合わせ内容１６０２、確認ボタン１６０３を有する。
問い合わせ内容１６０２には、アクティビティ詳細入力画面１５００の問い合わせ内容１５１１の各項目に対して、オーナーに確認をしてもらう金額や、数値、文章等が入力される。
アクティビティ管理モジュール２１１は、確認ボタン１６０３に、アクティビティの内容に応じて「承認・否認」ボタンの他、「確認」ボタンや、電子契約に進む「契約」ボタン等を使用する。

図２６〜図３２は、オーナー端末１０２に表示される画面の例である。
図２６は、チャット画面２６００の例である。
オーナー端末１０２のオーナー資産管理モジュール３１０は、管理サーバ１０１のアクティビティ管理モジュール２１１と連携して、オーナーとオペレータとの間のチャット機能を提供する。
チャット画面２６００では、オペレータからのメッセージ２６０１と、それに対するオーナーのメッセージ回答２６０２が表示されている。

オペレータの操作により生成されたアクティビティカード２６０４が、オペレータのメッセージ２６０３と共にチャットに投稿され、チャット画面２６００に表示される。詳細２６１０が選択されると、オーナー資産管理モジュール３１０は、アクティビティ詳細画面２７００を表示する。
チャット内で、添付２６１１がアクティビティカード２６０４と併せて送信される。

図２７は、アクティビティ詳細画面２７００の例である。
アクティビティ詳細画面２７００は、トピック２７０１、アクティビティタイトル２７０２、物件名２７０３、ステータス２７０４、メッセージ２７０５、問い合わせ内容２７１０、添付２７１１、承認ボタン２７２０、否認ボタン２７３０を有する。
それぞれ先に説明したアクティビティ及びアクティビティカードの内容が入力されている。
オーナーが承認ボタン２７２０を押すと、オーナー資産管理モジュール３１０は、アクティビティ承認画面２８００を表示する。オーナーが否認ボタン２７３０を押すと、オーナー資産管理モジュール３１０は、アクティビティ否認画面２８５０を表示する。

図２８は、アクティビティ承認画面２８００及び否認画面２８５０の例である。
オーナーは、問い合わせ内容２８１０を再度確認後、そのまま承認する場合には承認ボタン２８２０をタップする。承認しない場合には、否認ボタン２８３０をタップする。
否認する場合には、その理由を通知するために、メッセージ入力欄２８０１が必須入力欄とされて、オーナーのコメントを求める。

図２９は、否認後チャット画面２９００の例である。
オーナー資産管理モジュール３１０は、否認の場合には、メッセージ入力欄２８０１に入力されたメッセージ２９０１をチャットに投稿し、回答画面または回答情報２９０２をチャットに投稿する。このように、アクティビティカードの否認に伴って入力された否認の理由を、チャットメッセージの様に投稿することで、オペレータとオーナーの間のコミュニケーションを円滑に行うことができる。
回答画面には、トピック２９０３、アクティビティタイトル２９０４等の情報の他、オーナーの回答のステータス２９０５が表示される。

図３４は、アクティビティカード表示・回答処理フロー３４００の例である。
オーナー資産管理モジュール３１０は、管理サーバ１０１のアクティビティ管理モジュール２１１から送付されたアクティビティカードに関連するチャットメッセージを表示する（ステップ３４１０）。
オーナー資産管理モジュール３１０は、チャット上でアクティビティカードを表示する（ステップ３４２０）。

オーナー資産管理モジュール３１０は、オーナーから、アクティビティに対する承認・否認・確認等の選択を受け付ける（ステップ３４４０）。回答が否認だった場合には(ステップ３４４０がＹｅｓ)、メッセージ入力欄２８０１を必須入力項目とし、オーナーのメッセージ入力を受け付ける（ステップ３４５０）。
オーナー資産管理モジュール３１０は、これらの入力の結果、アクティビティに対する回答画面（回答情報）を生成し（ステップ３４６０）、オペレータとオーナーの間のチャットに回答画面を投稿する（ステップ３４７０）。

図３０は、アクティビティ一覧画面３０００の例である。
オーナー資産管理モジュール３１０は、アクティビティに対する絞り込み条件３００１に基づいて、対応するアクティビティの情報を、管理サーバ１０１のアクティビティ管理モジュール２１１から取得する。
オーナー資産管理モジュール３１０は、取得したアクティビティの情報３００３、３００４、３００５を一覧で表示する。また、現在のステータスの集計３００２を表示する。
このように管理サーバ１０１で管理されている複数の資産に対して、確認事項を示すアクティビティ情報をまとめてオーナー端末１０２に表示することで、オーナーは複数の資産に対する管理を容易に行うことができる。

図３１は、アクティビティフィルタ画面の例である。
オーナー資産管理モジュール３１０は、オーナーから絞り込み条件３００１の選択を受け付けると、アクティビティフィルタ画面を表示する、若しくは同様の情報をプルダウン形式で表示することで、オーナーから項目の選択を受け付ける。

図３２は、資産管理画面３２００の例である。
オーナー端末１０２のオーナー資産管理モジュール３１０は、オーナーが所有する複数の資産３２０３に対する情報をまとめて資産管理画面３２００に表示する。
オーナー資産管理モジュール３１０は、複数の資産３２０３、３２０４、３２０５等の合計の現在価値３２０１や、キャッシュフローなどの資産情報３２０２を集計して表示する。

通常、多数の不動産等の資産を有している場合には、資産管理会社も複数存在しており、管理方法や、それぞれの資産に対して発生する、承認、確認等の確認事項が、それぞれの資産管理会社のやり方でバラバラの方法で通知される。
本実施例によれば、複数の資産管理会社それぞれが有する資産管理会社端末１０３からの確認事項を、一度管理サーバ１０１の提供するプラットフォーム経由で管理サーバ１０１が受け付けて統合し、アクティビティという決まったフォーマットに従って、オーナーとの間のチャットの中でアクティビティカードの形で通知を行う。
各アクティビティに対する回答はチャット経由で受け付け、管理サーバ１０１のアクティビティマスター情報８００やアクティビティ詳細情報９００を管理、更新することで、そのオーナーの有する複数の資産に対するステータスを、管理サーバ１０１で一元管理することができる。

管理サーバ１０１のアクティビティ管理モジュール２１１と連携して動作するオーナー資産管理モジュール３１０を導入するだけで、オーナーには、複数の資産及び複数の資産管理会社に対する異なる対応ではなく、一元的に管理された画面、方法によって、複数の資産管理を行うことが可能となる。
また、複数の資産に対して多数発生する承認、確認等の確認事項をチャットというリアルタイムな問合せ方法の中で、オペレータとの対話しながら承認、確認を行うことができ、オーナーにとって非常に使い勝手の良いサービスとなる。

なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換えることが可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

また、上記の各構成、機能、処理部、処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリや、ハードディスク、ＳＳＤ（Solid State Drive）等の記録装置、または、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に置くことができる。

また、制御線や情報線は説明上必要と考えられるものを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際には殆ど全ての構成が相互に接続されていると考えてもよい。
なお、上述の実施例は少なくとも特許請求の範囲に記載の構成を開示している。

１…資産管理システム、１０２…オーナー端末、１０３…資産管理会社端末、２１１…アクティビティ管理モジュール、２１２…データ登録管理モジュール、２１３…資産登録管理モジュール、３１０…オーナー資産管理モジュール、４１０…管理会社資産管理モジュール

Claims (13)

1. チャットを用いたアクティビティ管理方法であって、
   不動産物件のオーナーに確認を取る必要のあるアクティビティ一覧を記憶しており、
   前記不動産物件の選択を受け付け、
   前記アクティビティ一覧から前記アクティビティの選択を受け付け、
   選択された前記不動産物件の前記アクティビティに関する不動産物件情報を取得し、
   取得した前記不動産物件情報を入力したアクティビティカードを生成し、
   前記オーナーとの間でメッセージのやり取りがなされているチャットに前記アクティビティカードを投稿する
   ことを特徴とするアクティビティ管理方法。
2. 請求項１に記載のアクティビティ管理方法であって、
   前記不動産物件情報は、前記不動産物件に対する金額に関する情報が含まれ、
   前記アクティビティカードに前記金額に関する情報を入力する
   ことを特徴とするアクティビティ管理方法。
3. 請求項１又は２に記載のアクティビティ管理方法であって、
   前記アクティビティカードに対応する承認及び否認のボタンがあり、
   前記チャットに表示された前記ボタンにより、前記オーナーから前記アクティビティに対する承認又は否認の選択を受け付ける
   ことを特徴とするアクティビティ管理方法。
4. 請求項３に記載のアクティビティ管理方法であって、
   前記オーナーから否認の選択を受け付けた場合には、
   否認の理由の記入を受け付け、前記否認の理由は前記チャットにメッセージとして投稿される
   ことを特徴とするアクティビティ管理方法。
5. 請求項３又は４に記載のアクティビティ管理方法であって、
   前記アクティビティに対する承認又は否認がなされた日時を記憶する
   ことを特徴とするアクティビティ管理方法。
6. 請求項３〜５のいずれか１項に記載のアクティビティ管理方法であって、
   前記オーナーの所有する複数の不動産物件に対して、所定のアクティビティに関する情報を取得し、前記複数の不動産物件の前記所定のアクティビティに関する承認又は否認の状況を一覧で表示する
   ことを特徴とするアクティビティ管理方法。
7. 管理サーバであって、
   不動産物件情報及び不動産物件のオーナーに確認を取る必要のあるアクティビティ一覧を記憶する記憶手段と、
   前記不動産物件の選択を受け付け、前記アクティビティ一覧から前記アクティビティの選択を受け付ける入力手段と、
   選択された前記不動産物件の前記アクティビティに関する不動産物件情報を取得し、取得した前記不動産物件情報を入力したアクティビティカードを生成し、前記オーナーとの間でメッセージのやり取りがなされているチャットに前記アクティビティカードを投稿するアクティビティ管理手段と、
   を有することを特徴とする管理サーバ。
8. 請求項７に記載の管理サーバであって、
   前記不動産物件情報は、前記不動産物件に対する金額に関する情報が含まれ、
   前記アクティビティカードに前記金額に関する情報を入力する
   ことを特徴とする管理サーバ。
9. 請求項７又は８に記載の管理サーバであって、
   前記アクティビティカードに対応する承認及び否認のボタンがあり、
   前記アクティビティ管理手段は、前記チャットに表示された前記ボタンにより、前記オーナーから前記アクティビティに対する承認又は否認の選択を受け付ける
   ことを特徴とする管理サーバ。
10. 請求項９に記載の管理サーバであって、
    前記オーナーから否認の選択を受け付けた場合には、
    否認の理由の記入を受け付け、前記否認の理由は前記チャットにメッセージとして投稿される
    ことを特徴とする管理サーバ。
11. 請求項９又は１０に記載の管理サーバであって、
    前記記憶手段は、前記アクティビティに対する承認又は否認がなされた日時を記憶する
    ことを特徴とする管理サーバ。
12. 請求項９〜１１のいずれか１項に記載の管理サーバであって、
    前記オーナーの所有する複数の不動産物件に対して、所定のアクティビティに関する情報を取得し、前記複数の物件の前記所定のアクティビティに関する承認又は否認の状況を一覧で表示する
    ことを特徴とする管理サーバ。
13. 管理サーバに請求項１〜６のいずれか１項に記載のアクティビティ管理方法の各ステップを実行させるためのプログラム。