特許 7484561 情報処理装置および情報処理方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-05-08

(45)【発行日】2024-05-16

(54)【発明の名称】情報処理装置および情報処理方法

(51)【国際特許分類】

   G06Q 30/06 20230101AFI20240509BHJP

【ＦＩ】

G06Q30/06

【請求項の数】 5

(21)【出願番号】P 2020138681

(22)【出願日】2020-08-19

(65)【公開番号】P2022034804

(43)【公開日】2022-03-04

【審査請求日】2022-08-09

【前置審査】

(73)【特許権者】

【識別番号】000003207

【氏名又は名称】トヨタ自動車株式会社

(74)【代理人】

【識別番号】110002860

【氏名又は名称】弁理士法人秀和特許事務所

(72)【発明者】

【氏名】宮田 亜衣

(72)【発明者】

【氏名】三浦 光博

(72)【発明者】

【氏名】中出 祐介

(72)【発明者】

【氏名】桜田 伸

(72)【発明者】

【氏名】澤田 修一

(72)【発明者】

【氏名】駒嶺 聡史

【審査官】上田 翔太

(56)【参考文献】

【文献】米国特許出願公開第２０２０／００４３０６６（ＵＳ，Ａ１）

【文献】特開２０１９－０３６１９１（ＪＰ，Ａ）

【文献】特開２０１６－０８１０９２（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

ユーザが生活において利用する可能性のある物品をユーザクラスごとに関連付けたアイテムデータを記憶する記憶部と、
前記ユーザをセンシングして得られたセンシングデータを取得することと、
前記センシングデータに基づいて、前記ユーザに対応するユーザクラスを決定することと、
前記ユーザが物品を譲受した履歴を含むユーザデータを取得することと、
前記ユーザクラス、前記アイテムデータ、および前記ユーザデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定することと、
前記推定の結果に基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を行うことと、
を実行する制御部を有し、
前記所定の処理は、前記ユーザごとの前記物品の要否を表す要否データを生成し、前記要否データを所定のデータベースに登録する処理である、
情報処理装置。

【請求項2】

前記ユーザクラスは、前記ユーザに関する属性、および、前記ユーザの家族に関する属性を含む、
請求項１に記載の情報処理装置。

【請求項3】

前記属性は、健康状態、家族構成、年齢のうちの少なくともいずれかを含む、
請求項２に記載の情報処理装置。

【請求項4】

前記センシングデータは、ユーザ端末から受信した前記ユーザの位置情報を含み、
前記制御部は、前記ユーザの位置情報の履歴に基づいて、前記ユーザクラスを決定する、
請求項１から３のいずれか１項に記載の情報処理装置。

【請求項5】

情報処理装置が実行する情報処理方法であって、
ユーザが生活において利用する可能性のある物品をユーザクラスごとに関連付けたアイテムデータを取得するステップと、
前記ユーザをセンシングして得られたセンシングデータを取得するステップと、
前記センシングデータに基づいて、前記ユーザに対応するユーザクラスを決定するステップと、
前記ユーザが物品を譲受した履歴を含むユーザデータを取得するステップと、
前記ユーザクラス、前記アイテムデータ、および前記ユーザデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定するステップと、
前記推定の結果に基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を行うステップと、
を含み、
前記所定の処理は、前記ユーザごとの前記物品の要否を表す要否データを生成し、前記要否データを所定のデータベースに登録する処理である、
情報処理方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、物品のリサイクルを促進するための技術に関する。

【背景技術】

【0002】

ライフステージの変化にともない、生活用品や家具などが新たに必要になる、または、不要になる場面がある。また近年では、取引プラットフォームを利用した不用品のリサイクルが活発に行われている。これに関する技術として、例えば、特許文献１には、リサイクル品の譲渡を希望するユーザと、当該リサイクル品の譲受を希望するユーザをマッチングするプラットフォームが開示されている。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２００３－０５０８５９号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

既存の技術においては、ユーザが、プラットフォームにアクセスし、譲渡品の詳細や連絡先などを交換する必要があるが、ユーザの手間を削減するという点において改善の余地があった。

【0005】

本開示は、物品のリサイクルを促進するための技術を提供することを目的とする。

【課題を解決するための手段】

【0006】

本開示の第一の様態は、ユーザをセンシングして得られたセンシングデータを取得することと、前記センシングデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定することと、前記推定の結果に基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を行うことと、を実行する制御部を有する、情報処理装置である。

【0007】

また、本開示の第二の様態は、第一の情報処理装置と、第二の情報処理装置と、を含む情報処理システムであって、前記第一の情報処理装置は、ユーザをセンシングして得られたセンシングデータを取得することと、前記センシングデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定することと、前記ユーザごとの前記物品の要否を表す要否データを前記第二の情報処理装置に送信することと、を実行する第一の制御部を有し、前記第二の情報処理装置は、前記要否データに基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を実行する第二の制御部を有する、情報処理システムである。

【0008】

また、本開示の第三の様態は、ユーザをセンシングして得られたセンシングデータを取得するステップと、前記センシングデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定するステップと、を含む、情報処理方法である。

【0009】

また、他の態様として、上記の情報処理方法をコンピュータに実行させるためのプログラム、または、上記のプログラムを非一時的に記憶したコンピュータ可読記憶媒体が挙げられる。

【発明の効果】

【0010】

本開示によれば、物品のリサイクルを促進するための技術を提供することができる。

【図面の簡単な説明】

【0011】

【図1】第一の実施形態に係るシステムの概要を説明する図。

【図2】第一の実施形態に係るホームサーバの構成要素を詳細に示した図。

【図3】第一の実施形態におけるモジュール間の関係を示す図。

【図4】記憶部に記憶されるデータを説明する図。

【図5】第一の実施形態に係るセンターサーバの構成要素を詳細に示した図。

【図6】第一の実施形態においてホームサーバが行なう処理のフローチャート。

【図7】第一の実施形態においてセンターサーバが行なう処理のフローチャート。

【図8】第二の実施形態に係るセンターサーバの構成要素を詳細に示した図。

【図9】第二の実施形態に係るシステムの概要を説明する図。

【図10】第二の実施形態においてセンターサーバが行なう処理のフローチャート。

【図11】第三の実施形態に係るシステムの概要を説明する図。

【発明を実施するための形態】

【0012】

本明細書では、ユーザを観察した結果に基づいて、生活用品や家具といった物品の要否を判定する情報処理装置を開示する。あるユーザにとって、新たに必要となる物品が発生したことや、不要になった物品が発生したことをシステムが判定することで、例えば、ユーザ間における中古品の取り引きを活性化することができる。

【0013】

本実施形態に係る情報処理装置は、ユーザをセンシングして得られたセンシングデータを取得することと、前記センシングデータに基づいて、前記ユーザにとっての必要な物品または不要な物品の発生を推定することと、前記推定の結果に基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を行うことと、を実行する制御部を有する。

【0014】

センシングデータは、ユーザの生活や行動等をセンシングした結果を表すデータである。センシングデータは、例えば、ユーザを直接観察して得られるデータ（例えば、画像データや音声データなど）であってもよい。また、センシングデータは、ユーザを間接的に観察して得られるデータ（例えば、ユーザが利用する端末の位置情報や、当該端末によるネットワークトラフィックなど）であってもよい。
本開示における物品とは、典型的には、家具、日用品、生活用品、旅行用品などであるが、これらに限られない。
制御部は、センシングデータに基づいて、新たな物品が必要になったこと（あるいは、将来必要になること）、または、所有している物品が不要になったこと（あるいは、将来不要になること）を、特定のユーザについて推定することができる。
所定の処理として、例えば、中古品の売買やレンタルを仲介する処理を行うことで、ユーザの利便性を向上させることができる。

【0015】

また、前記制御部は、前記センシングデータに基づいて、前記ユーザに対応するユーザクラスを決定することを特徴としてもよい。

【0016】

ユーザクラスとは、例えば、「年齢が所定の範囲内にある」、「所定の家族構成を有している」、または「所定の職業に就いている」といったように、ユーザの生活様式やステータスを分類したものである。ユーザクラスは、ユーザの同居人に関連するものであってもよい。例えば、ユーザクラスは、「子供の年齢が所定の範囲内にある」、「子供が就学している」といったものでもよい。また、ユーザクラスは、「出産予定」「進学予定」「引っ越し予定」など、将来発生するイベントを表すものであってもよい。
制御部は、センシングデータに基づいて、対象ユーザに対応するユーザクラスを決定す
る。例えば、自宅で生活している人の数が増減した場合、家族構成に基づくユーザクラスが変化したと判定することができる。

【0017】

また、情報処理装置は、ユーザが生活において利用する可能性のある物品をユーザクラスごとに関連付けたアイテムデータを記憶する記憶部をさらに有し、前記制御部は、前記ユーザクラスと、前記アイテムデータと、に基づいて前記推定を行うことを特徴としてもよい。

【0018】

アイテムデータは、例えば、ユーザクラスごとに、生活において利用される傾向のある物品を定義したデータとすることができる。
かかる構成によると、例えば、「ユーザが『出産予定』というクラスに属しているため、ベビーベッドが必要になる可能性が高い」といった判断を行えるようになる。

【0019】

また、前記ユーザクラスは、前記ユーザに関する属性、および、前記ユーザの家族に関する属性を含むことを特徴としてもよい。
また、前記属性は、健康状態、家族構成、年齢のうちの少なくともいずれかを含むことを特徴としてもよい。
健康状態や家族構成、年齢等によって、生活上必要になる機器や道具、家具の大きさや数などが変化しうるためである。

【0020】

また、前記センシングデータは、ユーザ端末から受信した前記ユーザの位置情報を含み、前記制御部は、前記ユーザの位置情報の履歴に基づいて、前記ユーザクラスを決定することを特徴としてもよい。
ユーザの位置情報の履歴を用いることで、ユーザクラスを決定することができる。例えば、ユーザが産婦人科を定期的に訪問していた場合、出産を控えていることが推定できる。また、例えば、ユーザが朝夕の時間帯に保育園や幼稚園を訪問していた場合、子供を有していることが推定できる。

【0021】

また、前記所定の処理は、前記ユーザごとの前記物品の要否を表す要否データを生成し、前記要否データをデータベースに登録する処理であることを特徴としてもよい。
要否データは、例えば、あるユーザにとって、ある物品が必要となる旨（または、必要となった旨）、または、ある物品が不要である旨（または、不要となった旨）を表すデータである。当該データをデータベースに登録することで、不用品のリサイクルを促進することができる。

【0022】

また、本開示の第二の様態は、前述した情報処理装置（第一の情報処理装置）と、第二の情報処理装置と、を含む情報処理システムである。
第一の情報処理装置は、前述した要否データを第二の情報処理装置に送信する第一の制御部を有し、第二の情報処理装置は、前記要否データに基づいて、前記必要な物品または不要な物品についての売買または譲受に関する所定の処理を実行する第二の制御部を有する。

【0023】

第二の制御部は、前記所定の処理として、物品を提供する第一のユーザと、前記物品を譲り受ける第二のユーザとを、前記要否データに基づいてマッチングする処理を行ってもよい。
かかる構成によると、複数のユーザ間における物品のやり取りを仲介することが可能になる。

【0024】

また、前記第二の制御部は、前記物品を前記第一のユーザの元から前記第二のユーザの元へ配送する指令を生成することを特徴としてもよい。
当該指令は、例えば、配送業者や交通事業者が管理する装置に送信してもよい。これにより、物品を配送するための手配を自動的に行うことが可能になる。

【0025】

また、前記第二の制御部は、前記所定の処理として、前記要否データに基づいて、前記物品のレンタルまたは売買に関する契約データを生成する処理を行ってもよい。
契約データは、例えば、物品のレンタル事業や販売事業を行う事業者に向けたものとすることができる。

【0026】

また、前記第二の制御部は、前記物品を前記ユーザの元へ配送、または、前記ユーザの元から回収するための指令を生成することを特徴としてもよい。
かかる構成によると、物品の貸与や返却を行うための手配を自動的に行うことが可能になる。

【0027】

また、前記第二の制御部は、前記指令を、前記物品を輸送する移動体を管理するサーバ装置へ送信することを特徴としてもよい。
物品を輸送する移動体は、人が運転する車両であってもよいし、自律走行車両であってもよい。移動体として自律走行車両を利用すると、物品の配送や回収を自動化することができる。

【0028】

以下、図面に基づいて、本開示の実施の形態を説明する。以下の実施形態の構成は例示であり、本開示は実施形態の構成に限定されない。

【0029】

（第一の実施形態）
第一の実施形態に係る情報処理システムの概要について、図１を参照しながら説明する。本実施形態に係るシステムは、ユーザの自宅に設置されたホームサーバ１００と、ホームサーバ１００に関連付いたセンサ群２００と、センターサーバ３００と、を含んで構成される。

【0030】

ホームサーバ１００は、ユーザの自宅に設置されたコンピュータである。ホームサーバ１００は、センサ群２００を用いてユーザをセンシングし、その結果に基づいて、当該ユーザの生活における、新たに必要となる物品、または、不要になった物品の発生を推定する。また、当該推定の結果に基づいて、関連するデータをセンターサーバ３００に送信する。
なお、ホームサーバ１００は、複数あってもよい。本実施形態では、複数のユーザ（または複数の家庭）にそれぞれ関連付いた複数のホームサーバを、ホームサーバ１００として総称する。また、物品のことをアイテムと称する。

【0031】

センターサーバ３００は、複数のホームサーバ１００を管理するコンピュータである。センターサーバ３００は、複数のホームサーバ１００から受信したデータに基づいて、あるアイテムを必要とするユーザと、当該アイテムが不要となったユーザとをマッチングする。

【0032】

図２は、本実施形態に係るホームサーバ１００およびセンサ群２００の構成要素をより詳細に示した図である。

【0033】

ここではまず、センサ群２００に含まれるセンサについて説明する。
センサ群２００は、屋内に設置された複数のセンサ２００Ａ，２００Ｂ…を含んで構成される。複数のセンサは、ユーザの存在、行動、属性、生活様式、または生活環境等を検出するためのデータを取得可能なものであれば、その種類は問わない。例えば、可視光画像や赤外線画像を取得するカメラ（画像センサ）であってもよいし、集音装置であっても
よい。また、これらの組み合わせであってもよい。また、屋内に複数の人が居る場合、個々人を識別可能なセンサであってもよい。
複数のセンサは、センサデータを出力可能に構成される。センサが画像センサである場合、センサデータは画像データであってもよい。
センサ群２００に含まれるセンサは、ユーザをセンシングできるよう、複数の箇所にそれぞれ設置されていることが好ましい。例えば、ユーザの自宅が対象である場合、複数の部屋にセンサが設置されていてもよい。

【0034】

ホームサーバ１００は、ユーザをセンシングして得られたセンサデータと、予め記憶されたデータに基づいて、ユーザにとっての、所定のアイテムに対する要否を判定し、その結果をセンターサーバ３００に送信する。詳細な方法については後述する。

【0035】

ホームサーバ１００は、汎用のコンピュータにより構成することができる。すなわち、ホームサーバ１００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。なお、リムーバブルメディアは、例えば、ＵＳＢメモリ、あるいは、ＣＤやＤＶＤのようなディスク記録媒体であってもよい。補助記憶装置には、オペレーティングシステム（ＯＳ）、各種プログラム、各種テーブル等が格納され、そこに格納されたプログラムを主記憶装置の作業領域にロードして実行し、プログラムの実行を通じて各構成部等が制御されることによって、後述するような、所定の目的に合致した各機能を実現することができる。ただし、一部または全部の機能はＡＳＩＣやＦＰＧＡのようなハードウェア回路によって実現されてもよい。

【0036】

制御部１０１は、ホームサーバ１００が行う制御を司る演算装置である。制御部１０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することがで
きる。
制御部１０１は、データ取得部１０１１、クラス分類部１０１２、および、評価部１０１３の３つの機能モジュールを有して構成される。各機能モジュールは、後述する記憶部１０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0037】

３つの機能モジュールについて、モジュール間で送受信されるデータを示した図である図３を参照しながら説明する。
データ取得部１０１１は、センサ群２００に含まれるセンサからセンサデータを取得する。取得するセンサデータは、画像データ（可視光画像や赤外線画像）であってもよいし、音声データであってもよい。また、その他のデータや、これらの組み合わせであってもよい。

【0038】

また、データ取得部１０１１は、取得したセンサデータに対して所定の処理を行ってもよい。例えば、センサデータを特徴量に変換してもよいし、当該センサデータを解析してその結果を取得してもよい。
例えば、センサデータが画像データである場合、画像認識を行い、当該画像に含まれている人物の識別子、人数、身長、状態、姿勢などを取得してもよい。また、センサデータが音声データである場合、音声認識を行い、会話の内容を表すテキストを取得してもよい。

【0039】

クラス分類部１０１２は、データ取得部１０１１が取得したデータと、予め構築された機械学習モデル（以下、クラス分類モデル）を用いて、ユーザを所定のクラスに分類する。本実施形態では、複数のクラスを予め定義し、それぞれのクラスに対してクラス分類を行う機械学習モデル（クラス分類モデル）を事前に構築したうえで、当該モデルを用いてクラス分類を行う。

【0040】

クラス分類モデルは、予め構築された機械学習モデルであって、入力されたデータを、予め定義された複数のクラスのうちのいずれかに分類する。クラス分類部１０１２は、データ取得部１０１１が取得したデータをクラス分類モデルに入力し、分類結果を出力として取得する。本例の場合、例えば、「出産準備中」というクラスが取得される。
定義されたユーザクラスは、ユーザおよびその家族の行動、状態、属性などに関連するものであってもよい。また、ユーザクラスは、ユーザおよびその家族に将来発生するイベント（出産、進学、就職、転居、結婚等）に関連するものであってもよい。さらに、ユーザクラスは、健康状態（健康、歩行困難、要支援、要介護等）、家族構成（パートナー、子供、同居親族の有無等）、年齢層等に関連するものであってもよい。
なお、一人のユーザが同時に二つ以上のユーザクラスに属していてもよい。

【0041】

評価部１０１３は、後述する記憶部１０２に記憶されたアイテムデータ１０２Ａおよびユーザデータ１０２Ｂに基づいて、あるクラスに属するユーザが必要としている（あるいは、将来必要となる）アイテム、または、当該ユーザにとって不要となった（あるいは、将来不要となる）アイテムを判定する。

【0042】

ここで、アイテムデータ１０２Ａおよびユーザデータ１０２Ｂについて説明する。
図４（Ａ）は、アイテムデータ１０２Ａの一例である。アイテムデータ１０２Ａは、ユーザが生活上どのようなアイテムを必要とするかを、ユーザクラスごとに関連付けたデータである。図４（Ａ）の例では、例えば、ユーザクラスが「出産準備中」である場合に、「ベビーベッド」「ベビーカー」「ベビーバス」が必要となる旨が定義されている。

【0043】

図４（Ｂ）は、ユーザデータ１０２Ｂの一例である。ユーザデータ１０２Ｂは、ユーザが保有しているアイテムのリストである。ホームサーバ１００は、ユーザがアイテムを購入、売却、処分、レンタルなどをした際に、ユーザデータ１０２Ｂを更新する。ユーザデータ１０２Ｂは、ユーザ自身が管理してもよいし、センシングの結果に基づいてシステムが自動的に更新してもよい。

【0044】

評価部１０１３は、アイテムデータ１０２Ａおよびユーザデータ１０２Ｂを参照し、以下の条件を満たす場合に、ユーザが、「現在保有していないアイテムを必要としている」と判定する。
（１）ユーザに対応するユーザクラスのうちの少なくともいずれかに、一つ以上のアイテムが関連付いている
（２）当該アイテムを、ユーザが現在保有していない

【0045】

また、評価部１０１３は、以下の条件を満たす場合に、ユーザが、「現在保有しているアイテムをもはや必要としていない」と判定する。
（１）ユーザが現在保有しているアイテムがある
（２）当該アイテムが、ユーザに対応するユーザクラスのいずれにも関連付いていない

【0046】

評価部１０１３は、判定の結果に基づいて、要否データを生成する。要否データは、ユーザの識別子と、アイテムの識別子と、当該アイテムの要否を関連付けたデータである。
図４（Ｃ）は、要否データの一例である。なお、「要否」カラムに記録された値のうち「１」とは、「現在保有していないアイテムを必要としている」ことを意味する。また、「０」とは、「現在保有しているアイテムを必要としていない」ことを意味する。
なお、要否データは、アイテムの詳細（例えば、サイズや色など）に関する情報を保持していてもよい。
また、本例では、単一のユーザを例示しているが、対象のユーザが複数いる場合、評価部１０１３は、複数のユーザのそれぞれについて要否データを生成してもよい。

【0047】

評価部１０１３は、生成された要否データを、センターサーバ３００へ送信する。

【0048】

記憶部１０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部１０１において実行されるプログラムや、当該プログラムが利用するデータが記憶される装置である。補助記憶装置には、制御部１０１で実行されるプログラムをアプリケーションとしてパッケージ化したものを記憶してもよい。また、これらのアプリケーションを実行するためのオペレーティングシステムを記憶してもよい。補助記憶装置に記憶されたプログラムが主記憶装置にロードされ、制御部１０１によって実行されることで、以降に説明する処理が行われる。

【0049】

主記憶装置は、ＲＡＭ（Random Access Memory）やＲＯＭ（Read Only Memory）を含んでもよい。また、補助記憶装置は、ＥＰＲＯＭ（Erasable Programmable ROM）やＨＤＤ
（Hard Disk Drive）を含んでもよい。さらに、補助記憶装置は、リムーバブルメディア
、すなわち可搬記録媒体を含んでもよい。リムーバブルメディアは、例えば、ＵＳＢ（Universal Serial Bus）メモリ、あるいは、ＣＤ（Compact Disc）やＤＶＤ（Digital Versatile Disc）のようなディスク記録媒体である。

【0050】

また、記憶部１０２には、前述したアイテムデータ１０２Ａおよびユーザデータ１０２Ｂが記憶される。

【0051】

図２に戻って説明を続ける。
通信部１０３は、ホームサーバ１００をネットワークに接続するための無線通信インタフェースである。通信部１０３は、例えば、無線ＬＡＮや３Ｇ、ＬＴＥ、５Ｇ等の移動体通信サービスを介して、センターサーバ３００と通信可能に構成される。
入出力部１０４は、利用者が行った入力操作を受け付け、利用者に対して情報を提示するユニットである。本実施形態では一つのタッチパネルディスプレイからなる。すなわち、液晶ディスプレイとその制御手段、タッチパネルとその制御手段から構成される。

【0052】

次に、センターサーバ３００について説明する。図５は、本実施形態に係るセンターサーバ３００の構成要素をより詳細に示した図である。
センターサーバ３００は、複数のホームサーバ１００から送信された要否データに基づいて、アイテムを提供するユーザと、当該アイテムを欲するユーザと、をマッチングするサーバ装置である。

【0053】

センターサーバ３００も、ホームサーバ１００と同様に汎用のコンピュータにより構成することができる。すなわち、センターサーバ３００は、ＣＰＵやＧＰＵ等のプロセッサ、ＲＡＭやＲＯＭ等の主記憶装置、ＥＰＲＯＭ、ハードディスクドライブ、リムーバブルメディア等の補助記憶装置を有するコンピュータとして構成することができる。

【0054】

制御部３０１は、センターサーバ３００が行う制御を司る演算装置である。制御部３０１は、ＣＰＵ（Central Processing Unit）などの演算処理装置によって実現することが
できる。
制御部３０１は、データ収集部３０１１およびマッチング部３０１２の２つの機能モジュールを有して構成される。各機能モジュールは、後述する記憶部３０２に記憶されたプログラムをＣＰＵによって実行することで実現してもよい。

【0055】

データ収集部３０１１は、複数のホームサーバ１００から要否データを収集し、後述する記憶部３０２へ記憶させる。

【0056】

マッチング部３０１２は、記憶部３０２に記憶された要否データに基づいて、ユーザ同士のマッチングを行い、その結果を、対応するホームサーバ１００へ提供する。具体的には、あるアイテムが不要であると判定されたユーザと、当該アイテムが必要であると判定されたユーザとをマッチングし、その結果を、双方のユーザにそれぞれ対応するホームサーバ１００へ送信する。

【0057】

記憶部３０２は、主記憶装置と補助記憶装置を含んで構成される。主記憶装置は、制御部１０１によって実行されるプログラムや、当該制御プログラムが利用するデータが展開されるメモリである。補助記憶装置は、制御部３０１において実行されるプログラムや、当該制御プログラムが利用するデータが記憶される装置である。

【0058】

記憶部３０２には、ホームサーバ１００から収集した要否データが記憶される。

【0059】

通信部３０３は、通信部１０３と同様の通信インタフェースである。通信部３０３は、例えば、インターネット等の広域ネットワークを介して、ホームサーバ１００と通信可能に構成される。

【0060】

なお、図２および図５に示した構成は一例であり、図示した機能の全部または一部は、専用に設計された回路を用いて実行されてもよい。また、図示した以外の、主記憶装置および補助記憶装置の組み合わせによってプログラムの記憶ないし実行を行ってもよい。

【0061】

次に、ホームサーバ１００が実行する処理について説明する。図６は、ホームサーバ１００が実行する処理のフローチャートである。

【0062】

まず、ステップＳ１１で、データ取得部１０１１が、センサ群２００に含まれるセンサから送信されたセンサデータを取得する。なお、データ取得部１０１１は、クラス分類が行えるだけの量のデータが収集できるまで、センサデータを一時的に蓄積してもよい。また、データ取得部１０１１は、取得したセンサデータに対して分析や加工等を行ってもよい。

【0063】

次に、ステップＳ１２で、クラス分類部１０１２が、データ取得部１０１１によって得られたデータをクラス分類モデルに入力し、分類結果（ユーザクラス）を取得する。
ステップＳ１３では、評価部１０１３が、クラス分類部１０１２が取得したユーザクラス、アイテムデータ１０２Ａ、およびユーザデータ１０２Ｂに基づいて、前述した処理によって要否データを生成する。

【0064】

ステップＳ１４では、評価部１０１３が、要否データをセンターサーバ３００に送信するための要件が満たされているか否かを判定する。
例えば、ユーザクラスを一回判定したのみでは、物品の要否が正確に判定できない場合がある。例えば、自宅内に存在する人の数が増えた場合、居住者が増えたのか、来客があったのかを直ちに決定することは難しい。そこで、ステップＳ１１～Ｓ１３の処理を反復して実行し、要件を満たした場合（例えば、同一のユーザクラスが所定の回数以上得られた場合など）に限って、要否データを送信するようにしてもよい。これにより、尤度が高い状況下にある場合にのみ、要否データを送信することが可能になる。

【0065】

ステップＳ１４で肯定判定となった場合、処理はステップＳ１５へ遷移し、評価部１０１３が、要否データをセンターサーバ３００に送信する。否定判定となった場合、処理はステップＳ１１へ戻る。
送信された要否データは、センターサーバ３００（データ収集部３０１１）によって受
信され、記憶部３０２に記憶される。

【0066】

次に、センターサーバ３００が実行する処理について説明する。図７は、センターサーバ３００（マッチング部３０１２）が実行する処理のフローチャートである。図示した処理は、例えば、所定の周期で実行される。

【0067】

まず、ステップＳ２１で、記憶部３０２に記憶されている最新の要否データを取得する。
次に、ステップＳ２２で、要否データに含まれるアイテムをキーとしてユーザ同士のマッチングを試行する。すなわち、あるアイテムが不要となった（あるいは、不要となることが予想される）ユーザと、当該アイテムを必要としている（あるいは、必要となることが予想される）ユーザとをマッチングする。

【0068】

この結果、マッチングが可能と判断された場合（ステップＳ２３－Ｙｅｓ）、処理はステップＳ２４へ遷移し、双方のユーザに対して、アイテムの譲渡および譲受を打診する。例えば、アイテムを提供する側のユーザに対して、当該アイテムを譲渡可能であるか、および、アイテムの譲渡を受ける側のユーザに対して、当該アイテムの譲受を希望するかを確認する。なお、この際、アイテムの譲渡価格に関する問い合わせを行ってもよい。
ステップＳ２３において、マッチングが成立しないと判定された場合、処理は終了する。

【0069】

双方のユーザが提案を受諾すると（ステップＳ２５－Ｙｅｓ）、処理はステップＳ２６へ遷移し、双方のユーザに対して互いの情報を提供する。これにより、双方のユーザは、アイテムの受け渡しを行なうことができる。いずれかのユーザが提案を受諾しなかった場合、処理は終了する。

【0070】

以上説明したように、第一の実施形態に係る情報処理システムでは、ユーザをセンシングした結果に基づいて、当該ユーザが属するクラスを決定し、当該クラスに基づいて、当該ユーザが必要とする物品、または、不要である物品を判定する。これを複数のユーザに対して行うことで、物品の譲り渡しを行なうためのユーザ同士のマッチングを自動的に行なうことが可能になる。

【0071】

（第一の実施形態の変形例）
センサ群２００に含まれるセンサは、ユーザを直接センシングするものに限られない。例えば、ユーザの自宅に設置されたネットワークスイッチが、当該ユーザによる通信トラフィックを取得してもよい。すなわち、コンピュータを利用してユーザが送受信したデータをセンサデータとして捉えることも可能である。
例えば、ユーザが、出産に関する補助金についての情報を得ようとしていた場合、当該ユーザが『出産準備中』というクラスに属していることが推定できる。

【0072】

また、センサ群２００に含まれるセンサは、必ずしも固定されたものである必要はない。例えば、ユーザが所持する端末（ユーザ端末）をセンサとして扱ってもよい。この場合、ユーザ端末からホームサーバ１００に対してセンサデータを送信するよう構成してもよい。例えば、ユーザ端末が周期的にホームサーバ１００に位置情報を送信し、ホームサーバ１００が、当該位置情報を、ユーザに対応するセンサデータとして扱ってもよい。
この場合、ホームサーバ１００は、ユーザの移動に関するデータ（例えば、ユーザが訪問した場所、日時、回数など）を取得し、記憶部１０２に記憶させることができる。また、クラス分類部１０１２が、このようなデータ（例えば、位置情報の履歴）に基づいて、ユーザクラスを決定することができる。このため、ホームサーバ１００は、位置情報の履歴に基づいてユーザクラスを決定するためのデータ（例えば、テーブルや機械学習モデル
）を記憶していてもよい。

【0073】

また、第一の実施形態では、要否データのみに基づいてユーザをマッチングしたが、ユーザのマッチングは、他の要素（例えば、ユーザの住所など）を考慮して行ってもよい。
また、第一の実施形態では、ユーザ同士を紹介する処理を行ったが、ユーザを直接紹介することはせず、アイテムを欲しているユーザがいる旨、または、アイテムを提供可能なユーザがいる旨のみを案内し、別のサービスへ誘導するようにしてもよい。

【0074】

（第二の実施形態）
第一の実施形態では、ユーザ同士をマッチングすることで、物品（中古品）の譲渡を仲介した。これに対し、第二の実施形態は、物品を購入またはレンタルするための手続きを自動的に行なう実施形態である。

【0075】

図８は、第二の実施形態に係るセンターサーバ３００の構成要素をより詳細に示した図である。
第二の実施形態は、制御部３０１が、マッチング部３０１２の代わりに契約部３０１３を有しているという点において、第一の実施形態と相違する。

【0076】

図９に示したように、第二の実施形態では、センターサーバ３００は、事業者サーバ４００とさらに通信可能に構成される。事業者サーバ４００は、物品のレンタルまたは販売を行なう事業者が管理するサーバ装置である。事業者サーバ４００は、複数の事業者ごとに存在していてもよい。
契約部３０１３は、事業者サーバ４００に向けた契約データを生成する。

【0077】

契約データは、例えば、以下のようなデータとすることができる。
・物品のレンタル契約を申し込むためのデータ
・物品のレンタル契約の終了を申し入れるためのデータ
・物品の購入を申し込むためのデータ
・物品の売却を申し込むためのデータ
契約データには、例えば、対象の物品を特定するためのデータ、契約期間（物品のレンタルを行う場合）、ユーザの情報などが含まれる。

【0078】

図１０は、第二の実施形態においてセンターサーバ３００（契約部３０１３）が行なう処理のフローチャートである。
第二の実施形態では、ステップＳ２１で要否データを取得した後、ステップＳ２２Ａにおいて、物品を扱う事業者を検索する。例えば、外部装置と通信を行なうことで、対象物品の貸し出し、販売、買い取り等を行なうことができる事業者を検索する。
次に、ステップＳ２３Ａにおいて、事業者が決定できたか否かを判定する。事業者が見つからなかった場合、処理は終了する。

【0079】

ステップＳ２４Ａでは、契約データを生成し、当該契約データをユーザに提示する。ここで、ユーザが契約を受諾した場合（ステップＳ２５Ａ－Ｙｅｓ）、処理はステップＳ２６Ａへ遷移し、契約データを事業者サーバ４００に送信する。契約を受諾しなかった場合（ステップＳ２５Ａ－Ｎｏ）、処理は終了する。

【0080】

第二の実施形態によると、物品を扱う事業者とのやり取りを簡略化することができる。
なお、本実施形態では、契約データを生成したが、契約データの生成は行わず、事業者の紹介（レコメンド）のみを行なうようにしてもよい。

【0081】

（第三の実施形態）
第一および第二の実施形態では、物品を輸送するための手配を、ユーザや事業者が行わなければならない。これに対し、第三の実施形態は、物品の輸送が必要となった場合に、当該物品を輸送する自律走行車両をセンターサーバ３００が手配する実施形態である。

【0082】

図１１に示したように、第三の実施形態では、センターサーバ３００は、車両管理装置５００と通信可能に構成される。車両管理装置５００は、複数の自律走行車両５１０を管理する装置である。
車両管理装置５００は、管理下にある複数の自律走行車両５１０から、各車両に関する情報（車両情報。例えば、位置情報、車両のステータス等）を収集する。また、管理下にある複数の自律走行車両５１０に対して、運行を指令するデータ（運行指令）を送信する。これにより、自律走行車両５１０を、指定した経路に沿って運行させることができる。

【0083】

運行指令には、走行経路、経由地、目的地を指定するデータが含まれていてもよい。また、運行指令には、経路上において行なうべき処理を指定するデータが含まれていてもよい。経路上において行なうべき処理として、例えば、ユーザの呼び出し、物品の積み込み、物品の引き渡しなどがある。

【0084】

第三の実施形態を、第一の実施形態と組み合わせる場合、センターサーバ３００は、「譲渡者であるユーザから物品を預かり、譲受者であるユーザに当該物品を届ける」旨の運行指令を生成する。この処理は、図７におけるステップＳ２６が完了した後で実行される。

【0085】

また、第三の実施形態を、第二の実施形態と組み合わせる場合、センターサーバ３００は、例えば、「物品を提供する事業者（レンタル事業者または販売事業者）から物品を預かり、ユーザに当該物品を届ける」旨の運行指令を生成する。または、「ユーザから返却対象である物品を回収し、レンタル事業者に当該物品を届ける」旨の運行指令を生成する。この処理は、図１０におけるステップＳ２６Ａが完了した後で実行される。

【0086】

なお、センターサーバ３００は、当事者であるユーザないし事業者のスケジュール、および、車両のスケジュールを確認したうえで、自律走行車両５１０を運行させる日時を決定してもよい。

【0087】

第三の実施形態によると、物品を輸送するための手配を自動的に行なうことができる。

【0088】

（変形例）
上記の実施形態はあくまでも一例であって、本開示はその要旨を逸脱しない範囲内で適宜変更して実施しうる。
例えば、本開示において説明した処理や手段は、技術的な矛盾が生じない限りにおいて、自由に組み合わせて実施することができる。
また、実施形態の説明では、所定の処理として、物品の売買や譲受に関する手続きを行ったが、レコメンドのみを行なうようにしてもよい。

【0089】

また、１つの装置が行うものとして説明した処理が、複数の装置によって分担して実行されてもよい。あるいは、異なる装置が行うものとして説明した処理が、１つの装置によって実行されても構わない。コンピュータシステムにおいて、各機能をどのようなハードウェア構成（サーバ構成）によって実現するかは柔軟に変更可能である。

【0090】

本開示は、上記の実施形態で説明した機能を実装したコンピュータプログラムをコンピュータに供給し、当該コンピュータが有する１つ以上のプロセッサがプログラムを読み出して実行することによっても実現可能である。このようなコンピュータプログラムは、コ
ンピュータのシステムバスに接続可能な非一時的なコンピュータ可読記憶媒体によってコンピュータに提供されてもよいし、ネットワークを介してコンピュータに提供されてもよい。非一時的なコンピュータ可読記憶媒体は、例えば、磁気ディスク（フロッピー（登録商標）ディスク、ハードディスクドライブ（ＨＤＤ）等）、光ディスク（ＣＤ－ＲＯＭ、ＤＶＤディスク・ブルーレイディスク等）など任意のタイプのディスク、読み込み専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気カード、フラッシュメモリ、光学式カード、電子的命令を格納するために適した任意のタイプの媒体を含む。

【符号の説明】

【0091】

１００・・・ホームサーバ
１０１，３０１・・・制御部
１０２，３０２・・・記憶部
１０３，３０３・・・通信部
１０４・・・入出力部
２００・・・センサ群
３００・・・センターサーバ
４００・・・事業者サーバ
５００・・・車両管理装置
５１０・・・自律走行車両

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】