JP2023061637A - 情報処理装置、情報処理方法、プログラム、および情報処理システム - Google Patents

Abstract

【課題】タクシー配車におけるユーザの手間を低減させることが可能な情報処理装置、情報処理方法、プログラム及び情報処理システムを提供する。【解決手段】情報処理システムは、ユーザの行動をセンシングする１以上のセンシングデバイス３０と、ユーザの行動センシングの他、ユーザによる操作入力の受け付け及び情報呈示を行うユーザ端末１０と、タクシー配車用サーバ４０と通信接続し、タクシー配車用サーバ４０に対して配車予約を依頼するサーバ２０と、タクシーの配車予約情報の管理や、各タクシー会社のサーバまたは各タクシーに配車予約情報の送信を行い、サーバ２０からの配車予約依頼に応じて、配車が可能なタクシーを探索し、配車予約できたか否かをサーバ２０に返信するタクシー配車用サーバ４０と、を有する。【選択図】図１

Description

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

従来、タクシーの配車予約方法として、事前にタクシー会社へ電話を行って指定の場所までタクシーを呼ぶことが行われていた。近年では、スマートフォン等を用いてインターネットを介して配車予約を行うことができるサービスが提供されている。

例えば下記特許文献１では、タクシーの出発地、目的地、付加情報（決済方法等）がユーザにより入力され、タクシーの出発地から目的地までのルートや運賃情報をユーザが確認してから配車要求を行うことが開示されている。

特開２０２１－５１６５９号公報

しかしながら、上記特許文献１では、配車要求に必要なユーザの工数が多く、予約操作が煩雑であった。例えば定期的にタクシーを利用する場合等、ユーザの利用形態によっては、毎回発生し得る配車要求のための手間が負担となる。

そこで、本開示では、タクシー配車におけるユーザの手間を低減させることが可能な情報処理装置、情報処理方法、プログラム、および情報処理システムを提案する。

本開示によれば、ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を備える、情報処理装置を提案する。

本開示によれば、プロセッサが、ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断することを含む、情報処理方法を提案する。

本開示によれば、コンピュータを、ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部として機能させる、プログラムを提案する。

本開示によれば、ユーザ行動をセンシングする１以上のセンシングデバイスと、前記１以上のセンシングデバイスから取得した前記ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を有する情報処理装置と、を備える、情報処理システムを提案する。

本開示の一実施形態による情報処理システムの概要について説明する図である。 本実施形態によるサーバの構成の一例を示すブロック図である。 本実施形態によるユーザの行動パターンの登録処理の一例について説明するシーケンス図である。 本実施形態による登録確認画面の一例を示す図である。 本実施形態によるユーザの行動パターンの登録処理の一例について説明するシーケンス図である。 本実施形態による配車予約処理の一例について説明するシーケンス図である。 本実施形態の第１の実施例による配車予約処理の流れについて説明するシーケンス図である。 本実施形態の第２の実施例による配車予約処理の流れについて説明するシーケンス図である。 本開示の他の実施形態による第１の動作処理の流れを示すフローチャートである。 本開示の他の実施形態による第２の動作処理の流れを示すフローチャートである。

以下に添付図面を参照しながら、本開示の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

また、説明は以下の順序で行うものとする。
１．本開示の一実施形態による情報処理システムの概要
２．構成例
３．動作処理
３－１．登録処理
３－２．配車予約処理
３－３．配車予約処理の実施例
４．予約待機リストの利用
５．補足

＜＜１．本開示の一実施形態による情報処理システムの概要＞＞
図１は、本開示の一実施形態による情報処理システムの概要について説明する図である。図１に示すように、本実施形態による情報処理システムは、ユーザの行動をセンシングする１以上のセンシングデバイス３０と、ユーザの行動センシングの他、ユーザによる操作入力の受け付けおよび情報呈示を行うユーザ端末１０と、サーバ２０と、タクシー配車用サーバ４０と、を有する。

サーバ２０は、タクシー配車用サーバ４０と通信接続し、タクシー配車用サーバ４０に対して配車予約を依頼することが可能である。

タクシー配車用サーバ４０は、タクシーの配車予約情報の管理や、各タクシー会社のサーバまたは各タクシーに配車予約情報の送信を行う。タクシー配車用サーバ４０は、サーバ２０からの配車予約依頼に応じて、配車が可能なタクシーを探索し、配車予約できたか否かをサーバ２０に返信し得る。タクシー配車用サーバ４０は、複数のタクシー会社用サーバ（図示せず）と通信接続し、複数のタクシー会社から配車予約可能なタクシーを探索し得る。

ユーザ端末１０は、ユーザに用いられる情報処理端末の一例である。ユーザ端末１０は、スマートフォンや、タブレット端末、ＰＣ、ウェアラブルデバイス（透過型／非透過型ＨＭＤ（ヘッドマウントディスプレイ）、スマートリング、スマートウォッチ等）であってもよい。ユーザ端末１０は、サーバ２０と通信接続し、データの送受信を行い得る。

（課題の整理）
ここで、スマートフォン等を用いてタクシーの配車予約が行えることは利便性が高いが、入力項目が多かったり、サーバと何度もやり取りが発生したり（確認画面が複数回表示される）等、操作が煩雑になっていた。例えば定期的にタクシーを利用する場合等、ユーザの利用形態によっては、毎回手間が発生することが、煩わしく、負担となる。

そこで、本開示による情報処理システムでは、タクシー配車におけるユーザの手間を低減させることを可能とする。

具体的には、サーバ２０において、センシングデバイス３０やユーザ端末１０で取得されたユーザ行動のセンシングデータ（ユーザ行動のセンシング結果）と、登録されたユーザの行動パターンとに基づいて、タクシーの配車要否を判断する。行動パターンは、ユーザのタクシー乗車に関連する行動を含む。例えばユーザが定期的にタクシーを利用している場合、サーバ２０は、センシングデータに基づいて、タクシー乗車する際のユーザの行動パターンを登録し、ユーザが同様の行動パターンを取っている場合に、自動的に配車要と判断することで、ユーザによるタクシー配車の手間を軽減することができる。なお、登録する行動パターンは、上述のようにユーザの実際の行動を学習する他、ユーザが予め任意に設定してもよい。

センシングデバイス３０は、ユーザに装着、所持される各種センサや、環境側に設置される各種センサを含む。センシングデバイス３０は、通信機能を有し、取得したデータ（センシングデータ）を、サーバ２０に送信する。例えば、センシングデバイス３０は、屋外や屋内に設けられる監視カメラや、ビルの出入口に設けられる認証端末、ユーザの身の周りに存在する各種ＩｏＴデバイス（玄関の人感センサ、目覚まし時計、寝室の人感センサ、リビングや洗面台に設けられるカメラ、スマートスピーカ等）が挙げられる。なお、センシングデバイス３０は、ユーザの行動を検知する様々なセンサが想定され、設置場所や設置方法、種類、数等は特に限定しない。ユーザの行動は、様々なセンサで随時検知され、サーバ２０に送信される。なお、監視カメラや認証端末等は、ユーザの顔認識情報、若しくはユーザが所持するユーザ端末１０から受信した識別情報（端末ＩＤやユーザＩＤ）を、センシングデータと対応付けてサーバ２０に送信し、サーバ２０において、ユーザを認識（個人認識）してもよい。

また、本実施形態では、ユーザが所持するユーザ端末１０においても、各種センシングデータを取得し、ユーザ行動のセンシング結果としてサーバ２０に送信する。すなわち、ユーザ端末１０は、センシングデバイスの一例とも言える。

以上、本開示の一実施形態による情報処理システムの概要について説明した。続いて、本実施形態による情報処理システムに含まれるサーバ２０の具体的な構成について図面を参照して説明する。

＜＜２．サーバ２０の構成例＞＞
図２は、本実施形態によるサーバ２０の構成の一例を示すブロック図である。図２に示すように、サーバ２０は、通信部２１０、制御部２２０、および記憶部２３０を有する。

（通信部２１０）
通信部２１０は、有線または無線により外部装置とデータの送受信を行う。通信部２１０は、例えば有線／無線ＬＡＮ（Local Area Network）、Ｗｉ－Ｆｉ（登録商標）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、携帯通信網（ＬＴＥ（Long Term Evolution）、４Ｇ（第４世代の移動体通信方式）、５Ｇ（第５世代の移動体通信方式））等を用いて、ユーザ端末１０や、イベント管理用端末５０と通信接続する。

（制御部２２０）
制御部２２０は、演算処理装置および制御装置として機能し、各種プログラムに従ってサーバ２０内の動作全般を制御する。制御部２２０は、例えばＣＰＵ（Central Processing Unit）、マイクロプロセッサ等の電子回路によって実現される。また、制御部２２０は、使用するプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、及び適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）を含んでいてもよい。

また、本実施形態による制御部２２０は、行動履歴記憶処理部２２１、行動パターン登録処理部２２２、配車要否判断部２２３、および配車予約処理部２２４としても機能する。

行動履歴記憶処理部２２１は、センシングデバイス３０やユーザ端末１０から取得した、ユーザ行動のセンシング結果に基づいて、ユーザの行動履歴を記憶部２３０に記憶する。センシング結果は、センシングデータそのまま（生データ）であってもよいし、サンプリングデータであってもよいし、センシングデータに基づいて生成されたデータ（加工データ）であってもよい。行動履歴記憶処理部２２１は、特にタクシー乗車に関連する行動を、行動履歴として記憶する。タクシー乗車に関連する行動とは、例えばユーザがタクシーを予約するまでの行動や、タクシーに乗車するまでの行動である。行動履歴記憶処理部２２１は、かかる行動の日時情報、場所情報、内容等を記憶する。また、行動履歴は、タクシーの乗車履歴（乗車日時、場所、目的地等）を含んでもよい。例えばユーザ端末１０にタクシー予約用のアプリケーションがダウンロードされ、ユーザが当該アプリケーションを用いて予約等を行っている場合、サーバ２０は、当該アプリケーションからユーザの乗車履歴を取得し得る。また、行動履歴には、その行動を取っている際の状況に関する情報が含まれていてもよい。状況に関する情報とは、例えば、天候情報や交通情報等である。

行動パターン登録処理部２２２は、配車要否判断部２２３において、タクシーの配車を必要と判断するための行動パターンを登録する処理を行う。行動パターン登録処理部２２２は、例えばユーザの行動履歴から、ユーザがタクシー配車の予約やタクシーに乗車する行動パターンを抽出し、登録する。一例として、ユーザがある行動を取った後にタクシーを呼ぶ（配車予約を行う）ことが所定回数以上行われた場合、行動パターン登録処理部２２２は、その行動を行動パターンとして登録する。これにより、再び同じ行動を取った場合に、配車要否判断部２２３によりタクシー配車が必要と判断され得る。また、行動パターン登録処理部２２２は、ユーザが同じ曜日の同じ時刻に同じ場所からタクシーに乗車する行動が所定回数以上行われた場合、その曜日、時刻、場所を行動パターンとして登録してもよい。この際、乗車場所に至るまでのユーザ行動も参照し、乗車場所に到着した際には既にタクシーが到着しているよう、一定時間前の行動をタクシー配車の予約が必要と判断する行動パターンとして登録してもよい。

配車要否判断部２２３は、ユーザ行動のセンシング結果と、登録されたユーザの行動パターンとに基づいて、タクシーの配車要否を判断する。具体的には、配車要否判断部２２３は、ユーザ行動のセンシング結果が、登録されたユーザの行動パターンと一致する場合、タクシーの配車が必要と判断する。そして、配車予約処理部２２４は、配車予約を実行する処理を行う。具体的には、配車予約処理部２２４は、タクシー配車用サーバ４０に対して配車予約を依頼する。配車予約の依頼では、例えば配車予約処理部２２４は、時間、乗車場所、および目的地の情報をタクシー配車用サーバ４０に送信する。

（記憶部２３０）
記憶部２３０は、制御部２２０の処理に用いられるプログラムや演算パラメータ等を記憶するＲＯＭ（Read Only Memory）、および適宜変化するパラメータ等を一時記憶するＲＡＭ（Random Access Memory）により実現される。本実施形態により記憶部２３０は、仮想空間の情報を格納する。

本実施形態による記憶部２３０は、ユーザの行動履歴、行動パターン、および配車予約に関する情報等を記憶する。

以上、サーバ２０の構成について具体的に説明したが、本開示によるサーバ２０の構成は図２に示す例に限定されない。例えばサーバ２０は、複数の装置により実現されてもよい。

＜＜３．動作処理＞＞
次に、本実施形態による情報処理システムの動作処理について図面を用いて具体的に説明する。具体的には、ユーザの行動パターンの登録処理と、ユーザ行動のセンシング結果に応じた配車予約処理について、順次説明する。

＜３－１．登録処理＞
まず、ユーザの行動パターンの登録処理について、図面を参照していくつか具体例を説明する。

（３－１－１．会社から外出する際のタクシー利用）
図３は、本実施形態によるユーザの行動パターンの登録処理の一例について説明するシーケンス図である。図３では、ユーザが会社から外出する際に毎回タクシーを利用している場合に、かかる行動を行動パターンとして登録する例について説明する。

図３に示すように、まず、会議室の出入口や廊下に設置されたカメラ（センシングデバイス３０の一例）は、ユーザが会議室から遠ざかっていることを検知すると（ステップＳ１０３）、検知結果（ユーザ行動のセンシング結果）をサーバ２０に送信する（ステップＳ１０６）。サーバ２０は、ユーザが会議室を出たこと（どの会議室か、および会議室を出た日時等）を記憶する（ステップＳ１０９）。

次に、ユーザ端末１０は、ユーザがエレベータで降りていることを検知すると（ステップＳ１１２）、検知結果をサーバ２０に送信する（ステップＳ１１５）。ユーザ端末１０には、例えば位置測位部やモーションセンサが設けられ、センシングデータからユーザがエレベータに乗って降りていることを検知し得る。なお、位置測位部は、屋外位置測位部と、屋内位置測位部を含んでいてもよい。屋外位置測位部は、ＧＮＳＳ（Ｇｌｏｂａｌ Ｎａｖｉｇａｔｉｏｎ Ｓａｔｅｌｌｉｔｅ ｓｙｓｔｅｍ）によりユーザの現在地情報を算出してもよい。また、屋内位置測位部は、Ｗｉ-Ｆｉ、ビーコン等を利用して、現在地情報を算出し得る。サーバ２０は、ユーザがエレベータで降りていること（何フロア分降りたか、およびエレベータに乗った日時等）を記憶する（ステップＳ１１８）。

次いで、ユーザ端末１０は、ユーザが配車アプリ（配車予約を行うためのアプリケーション）でタクシーを呼んだこと（配車予約）を検知すると（ステップＳ１２１）、検知結果をサーバ２０に送信する（ステップＳ１２４）。サーバ２０は、ユーザがタクシーを呼んだこと（乗車時刻、乗車場所、目的地、および配車予約を行った日時等）を記憶する（ステップＳ１２７）。なお、ここでは一例として配車アプリを利用してタクシーを呼んだ場合について説明しているが、タクシーを呼ぶ手段については特に限定しない。ユーザが、Ｗｅｂサイトや電話、メール、ＳＮＳ（Ｓｏｃｉａｌ Ｎｅｔｗｏｒｋｉｎｇ Ｓｅｒｖｉｃｅ）等を用いてタクシーを呼んだ際も、ユーザ端末１０は、かかる行動を検知し、検知結果をセンシングデバイス３０に送信する。ユーザによる配車予約の情報は、ユーザ端末１０に限らず、例えばタクシー配車用サーバ４０から受信してもよい。

次に、会社の出入口管理システム（センシングデバイス３０の一例）は、ユーザが会社の外に出たことを検知すると（ステップＳ１３０）、検知結果をサーバ２０に送信する（ステップＳ１３３）。サーバ２０は、ユーザが会社の外に出たこと（会社の外に出た日時等）を記憶する（ステップＳ１３６）。

次いで、ユーザ端末１０は、タクシーが目的地に到着してユーザが降車したことを検知すると（ステップＳ１３９）、検知結果をサーバ２０に送信する（ステップＳ１４２）。サーバ２０は、ユーザが目的地に着いたこと（目的地、および日時等）を記憶する（ステップＳ１４５）。ここでは目的地に到着して降車したことを記憶しているが、サーバ２０は、さらにユーザがタクシーに乗車したこと（乗車した場所、および乗車した日時等）をユーザ端末１０から取得して記憶してもよい。

以上説明したように、サーバ２０は、ユーザの行動履歴を随時記憶する。なお、サーバ２０は、タクシー乗車に関連する行動のみを記憶するようにしてもよい。例えば、サーバ２０は、タクシー乗車の時刻の前一定時間から降車までの行動（例えば乗車前１５分から降車までの行動等）のみを残し、他を削除するようにしてもよい。

続いて、サーバ２０は、タクシーを呼ぶまでの行動に関し、同じ行動が所定回数以上発生したか否かを判断する（ステップＳ１４８）。図３に示す例では、ある会議室から出てエレベータで３フロア分降りた際に、タクシーを呼んでいる。サーバ２０は、蓄積した行動履歴に基づいて、このような行動が所定回数以上発生したか否かを判断する。なお、ここでの「同じ行動」には、場所と時刻に限らず、状況が含まれていてもよい。例えば、サーバ２０は、行動履歴から、平日かつ雨が降っている日、朝８時の前後５分の間に、自宅近くの場所からタクシーに乗車するという行動を抽出し、その行動の発生回数をカウントしてもよい。

次に、同じ行動が所定回数以上発生した場合（ステップＳ１４８／Ｙｅｓ）、サーバ２０は、行動パターン登録の要否をユーザに確認要求する（ステップＳ１５１）。

次いで、ユーザ端末１０は、行動パターン登録の要否をユーザに確認する（ステップＳ１５４）。ここで、図４に、登録確認画面の一例を示す。例えば図４左に示す画面６００のように、記録したタクシー呼び出しの前後におけるユーザ行動を示し、この内容で自動配車予約の登録を行ってよいか否かをユーザに尋ねる。ユーザは、編集したい行動がある場合は、画面６００の修正ボタンを押下し、図４右に示す画面６１０において、任意に修正する。また、ユーザは、登録を承認する場合は、画面６００のはいボタンを押下する。このようなユーザへの登録確認は、例えばユーザがタクシーを降車したタイミングで行われてもよい。なお、ユーザへの登録確認のタイミングは特に限定しない。

次に、登録が承認された場合（ステップＳ１５７／Ｙｅｓ）、ユーザ端末１０は、承認されたことをサーバ２０に通知する（ステップＳ１６０）。サーバ２０は、行動パターンを登録する（ステップＳ１６３）。

一方、登録が承認されなかった場合（ステップＳ１５７／Ｎｏ）、ユーザ端末１０は、承認されなかったことをサーバ２０に通知する（ステップＳ１６６）。この場合、サーバ２０は、何ら行動パターンの登録は行わない。なお、サーバ２０は、どの行動について承認が拒否されたかを記憶しておいてもよい。また、サーバ２０は、さらに所定回数発生した場合に、再度登録の確認要求をしてもよい。また、サーバ２０は、承認が拒否されることが多い場合、確認の基準とした上記「所定回数」を調整してもよい。

（３－１－２．自宅から外出する際のタクシー利用）
図５は、本実施形態によるユーザの行動パターンの登録処理の一例について説明するシーケンス図である。図５では、ユーザが自宅から外出する際（例えば出社）に毎回タクシーを利用している場合に、かかる行動を行動パターンとして登録する例について説明する。

図５に示すように、まず、目覚まし時計（センシングデバイス３０の一例）は、設定された時間にアラームを鳴らし（ステップＳ２０３）、アラームが止められたことを検知すると（ステップＳ２０６）、検知結果（ユーザ行動のセンシング結果）をサーバ２０に送信する（ステップＳ２０９）。サーバ２０は、アラームが止められた時刻（ユーザの起床時刻）を記憶する（ステップＳ２１２）。

次に、洗面所に設けられたカメラ（センシングデバイス３０の一例）は、ユーザが洗顔していることを検知すると（ステップＳ２１５）、検知結果をサーバ２０に送信する（ステップＳ２１８）。サーバ２０は、ユーザの洗顔時刻を記憶する（ステップＳ２２１）。なお、ここでは一例として「洗顔」を検知しているが、本実施形態は「洗顔」に限らず、着替えや朝食、歯磨き、メイク等、身支度（外出する準備の進行）が適宜検知され得る。

次いで、玄関に設けられたカメラ（センシングデバイス３０の一例）は、ユーザが外出したことを検知すると（ステップＳ２２４）、検知結果をサーバ２０に送信する（ステップＳ２２７）。サーバ２０は、ユーザが玄関から出たこと（外出時刻）を記憶する（ステップＳ２３０）。

次に、ユーザ端末１０は、ユーザが例えば配車アプリでタクシーを呼んだことを検知すると（ステップＳ２３３）、検知結果をサーバ２０に送信する（ステップＳ２３６）。サーバ２０は、ユーザがタクシーを呼んだこと（乗車時刻、乗車場所、目的地、および配車予約を行った日時等）を記憶する（ステップＳ２３９）。なお、上述したように、ユーザがタクシーを呼ぶ手段については特に限定しない。

次いで、ユーザ端末１０は、タクシーが目的地に到着してユーザが降車したことを検知すると（ステップＳ２４２）、検知結果をサーバ２０に送信する（ステップＳ２４５）。サーバ２０は、ユーザが目的地に着いたこと（目的地、および日時等）を記憶する（ステップＳ２４８）。

続いて、サーバ２０は、タクシーを呼ぶまでの行動に関し、同じ行動が所定回数以上発生したか否かを判断する（ステップＳ２５１）。図５に示す例では、蓄積した行動履歴から、何時に起きて何時に洗顔し、何時に自宅を出た場合にタクシーを呼んでいるかが行動パターンとして抽出される。

次に、同じ行動が所定回数以上発生した場合（ステップＳ２５１／Ｙｅｓ）、サーバ２０は、行動パターン登録の要否をユーザに確認要求する（ステップＳ２５４）。

次いで、ユーザ端末１０は、行動パターン登録の要否をユーザに確認する（ステップＳ２５７）。

次に、登録が承認された場合（ステップＳ２６０／Ｙｅｓ）、ユーザ端末１０は、承認されたことをサーバ２０に通知する（ステップＳ２６３）。サーバ２０は、行動パターンを登録する（ステップＳ２６６）。

一方、登録が承認されなかった場合（ステップＳ２６０／Ｎｏ）、ユーザ端末１０は、承認されなかったことをサーバ２０に通知する（ステップＳ２６９）。

以上、登録処理の具体例について説明した。本実施形態によるサーバ２０は、ユーザの普段の行動から、タクシー乗車に関する行動履歴を蓄積し、タクシー乗車に至るユーザの行動パターンを抽出して登録することができる。なお、本実施形態による登録処理は、図３および図５に示す例に限定されない。

上述した例では、行動パターンを登録する際にユーザの承認を得ているが、これに限らず、サーバ２０は、承認を得ずに登録してもよい。また、サーバ２０は、同じ行動が所定回数以上発生した際に行動パターンを仮登録し、次に同じ行動が発生した際に、ユーザに配車予約を行うか確認し、呼ぶ旨の了承を得た場合に、配車予約を行うと共に、行動パターンを登録してもよい。また、配車予約の了承を得た場合に、「次からも呼びますか？」と確認し、承認を得た場合に行動パターンを登録してもよい。

また、上述した例では、ユーザの行動履歴に基づいて行動パターンを登録しているが、本実施形態はこれに限らず、サーバ２０は、ユーザが任意に設定した行動パターンを登録してもよい。また、サーバ２０は、既定の行動パターンを呈示し、ユーザが選択したりアレンジして登録してもよい。

＜３－２．配車予約処理＞
図６は、本実施形態による配車予約処理の一例について説明するシーケンス図である。

図６に示すように、まず、サーバ２０の配車予約処理部２２４は、ユーザの行動に関するセンシングデータ（ユーザ行動のセンシング結果）を、各センシングデバイス３０やユーザ端末１０から取得し（ステップＳ２７３）、センシングデータを記憶する（ステップＳ２７６）。

次に、配車予約処理部２２４は、ユーザ行動のセンシング結果が、登録された行動パターンと一致するか否かを判断する（ステップＳ２７９）。

そして、一致する場合（ステップＳ２７９／Ｙｅｓ）、配車予約処理部２２４は、配車予約を実行する（ステップＳ２８２）。具体的には、配車予約処理部２２４は、行動パターンに従って、乗車場所、乗車時刻、および目的地をタクシー配車用サーバ４０に送信して配車予約依頼を行う。これにより、サーバ２０は、ユーザがいつも乗車する場所にタクシーを配車し得る。

以上、本実施形態による配車予約処理の一例について説明した。本実施形態によるサーバ２０は、ユーザの普段の行動を、事前に登録された、タクシー乗車に至るユーザの行動パターンと比較することで、自動的に配車予約を行い、ユーザの配車予約における手間を省き、タクシー利用の利便性をさらに向上させることができる。ユーザは普段通り生活しながらタクシーを利用しているだけで、システム側でタクシー乗車に至る行動パターンが登録され、予約の手間無しでタクシー利用を行えるようになる。

なお、本実施形態は図６に示す例に限定されない。例えば、配車予約処理部２２４は、上記ステップＳ２８２の前に、ユーザに配車予約を行ってよいか否かの確認を行ってもよい。また、事前に確認するか否かはユーザが任意に設定してもよい。また、ユーザへの確認は配車予約後であってもよい。この場合、ユーザによりキャンセルが押された場合は、サーバ２０は、タクシー配車用サーバ４０に対してキャンセル通知を行う。

また、サーバ２０は、一度登録した行動パターンを、その後のユーザの行動履歴に基づいて、適宜修正してもよい。サーバ２０は、自動的に修正してもよいし、ユーザに確認した上で修正してもよい。

＜３－３．配車予約処理の実施例＞
次に、本実施形態による配車予約処理の実施例について、図面を参照して具体例をいくつか説明する。

（３－３－１．第１の実施例）
図７は、本実施形態の第１の実施例による配車予約処理の流れについて説明するシーケンス図である。図７に示す例では、普段自宅から外出する際（出社時等）にタクシーを利用するユーザの行動が、行動パターンとして登録されたことで、普段通りの行動に応じて自動的に配車予約される場合について説明する。また、図７に示す例では、さらにサーバ２０は、登録された行動パターンからユーザの行動がずれている場合に、ユーザを急かしたり、代替案を提案したり等する。

図７に示すように、サーバ２０は、登録された行動パターンに基づいて、ユーザの目覚まし時計に対して、いつもの時間にアラーム設定を行う（ステップＳ３０３）。

次に、目覚まし時計は、設定された時間にアラームを鳴らし（ステップＳ３０６）、アラームが止められたことを検知すると（ステップＳ３０９）、検知結果をサーバ２０に送信する（ステップＳ３１２）。サーバ２０は、アラームが止められた時刻（ユーザの起床時刻）を記憶する（ステップＳ３１５）。

次いで、いつも通りの起床時刻ではなかった場合（すなわち行動パターンとのずれが生じている場合）（ステップＳ３１８／Ｎｏ）、サーバ２０は、ユーザを急かす通知を行う（ステップＳ３２１）。具体的には、例えばユーザの自宅に設けられる室内スピーカ（センシングデバイス３０の一例）により、いつもより起きる時間が遅かったので少し急ぐよう声を掛ける（ステップＳ３２４）。室内スピーカは、通信部、制御部、スピーカ、およびマイクを有し、ユーザによる発話音声を認識したり、応答したりできるスマートスピーカであってもよい。発話音声の認識処理は、クラウドで行われてもよい。

次に、洗面所に設けられたカメラ（センシングデバイス３０の一例）は、ユーザが洗顔していることを検知すると（ステップＳ３２７）、検知結果をサーバ２０に送信する（ステップＳ３３０）。サーバ２０は、ユーザの洗顔時刻を記憶する（ステップＳ３３３）。ここでは一例として「洗顔」を検知しているが、本実施例は「洗顔」に限らず、着替えや朝食、歯磨き、メイク等、身支度（外出する準備の進行）が適宜検知される。

次いで、いつも通りの（身支度の）進行ではなかった場合（すなわち行動パターンとのずれが生じている場合）（ステップＳ３３６／Ｎｏ）、サーバ２０は、ユーザを急かす通知を行う（ステップＳ３３９）。具体的には、例えば室内スピーカにより、いつもより身支度に時間が遅かったので急ぐよう声を掛ける（ステップＳ３４２）。

続いて、サーバ２０は、通常のタクシー呼び出しの最終締め切り時間に間に合うか否かを判断する（ステップＳ３４５）。本実施例では、一例として、一般的な有人タクシーを「通常のタクシー」と称する。

間に合わない場合（ステップＳ３４５／Ｎｏ）、サーバ２０は、ユーザに代替案の呈示を行う（ステップＳ３４８）。代替案は、例えば通常タクシーよりも呼び出しの最終締め切りに時間的余裕があるロボットタクシーの利用提案である。ロボットタクシーは、例えば専用レーンや有料レーンを走行することを想定し、通常タクシーよりも早く（道の混雑等で遅れることなく）乗車場所や目的地に到着できる。若しくは、ロボットタクシーの場合、全ての地図情報がインプットされており、人間による運転に比べてより正確に走行し、より早く目的地まで到着できることが期待される。なお、ここでは一例としてロボットタクシーを挙げたが、代替案はこれに限定されない。例えば、専用レーンや有料レーンを走行できる特別な有人タクシーや、特別なベテラン運転手のタクシーであってもよい。

次に、室内スピーカは、ロボットタクシーに切り替えるかをユーザに尋ねる（ステップＳ３５１）。特に割り増し料金が掛かる場合等は、その旨もユーザに通知される。ユーザは、了承するか否かを室内スピーカ（スマートスピーカ）に対して口頭で答えてもよい。室内スピーカは、ユーザが了承した場合、ロボットタクシーの依頼をサーバ２０に通知する（ステップＳ３５４）。

そして、サーバ２０は、通常タクシーまたはロボットタクシーの配車予約を行う（ステップＳ３５７）。具体的には、サーバ２０は、登録された行動パターンに従って、乗車場所、乗車時刻、および目的地の情報をタクシー配車用サーバ４０に送信して配車予約依頼を行う。

また、サーバ２０は、配車予約を行ったことを（ユーザの行動履歴に含まれる乗車履歴として）記憶する（ステップＳ３６０）。

以上、第１の実施例について説明した。なお、代替案を呈示しない例も考え得る。その場合、サーバ２０は、普段よりも遅い到着となる旨をユーザに通知した上で、通常タクシーの配車予約を行う。

（３－３－２．第２の実施例）
図８は、本実施形態の第２の実施例による配車予約処理の流れについて説明するシーケンス図である。図８に示す例では、普段自宅から外出する際（出社時等）にはタクシーを利用しないが、寝坊した場合や、雨の場合、電車遅延が発生した場合等、普段と異なる状況が発生した場合にはタクシーを利用することが行動パターンとして登録されている場合について説明する。このため、本実施例では、タクシーを利用しない普段の行動パターンと、これに対して異なる状況が発生した場合にはタクシーの配車予約を行う旨が、登録されている。

図７に示すように、サーバ２０は、ユーザの目覚まし時計に対して、登録された時間にアラーム設定を行う（ステップＳ４０３）。目覚まし時計のアラーム設定は、ユーザにより任意に行われてもよいし、サーバ２０がユーザの普段の行動から抽出した、外出までの普段の行動パターンに基づいて設定してもよい

次に、目覚まし時計は、設定された時間にアラームを鳴らし（ステップＳ４０６）、アラームが止められたことを検知すると（ステップＳ４０９）、検知結果をサーバ２０に送信する（ステップＳ４１２）。サーバ２０は、アラームが止められた時刻（ユーザの起床時刻）を記憶する（ステップＳ４１５）。

次いで、サーバ２０は、いつも通りの起床時刻であったか否かを判断する（ステップＳ４１８）。

次に、いつも通りの起床時刻であった場合（ステップＳ４１８／Ｙｅｓ）、サーバ２０は、天候情報を外部サーバから取得し（ステップＳ４２１）、雨か否かを確認する（ステップＳ４２４）。なお、雨、雪、または台風であるか否かの確認であってもよい。いずれにしても、サーバ２０は、普段と異なる状況（寝坊や悪天候）が発生しているか否かを判断する。

また、洗面所に設けられたカメラが、ユーザが洗顔していることを検知し（ステップＳ４２７）、検知結果をサーバ２０に送信すると（ステップＳ４３０）、サーバ２０は、ユーザの洗顔時刻を記憶し（ステップＳ４３３）、さらに、いつも通り（身支度の）進行がなされているか否かを確認する（ステップＳ４３６）。ここでは身支度の一例として洗顔に着目しているが、本実施例はこれに限定されず、着替えや朝食、歯磨き、メイク等も適宜検知されてもよい。

いずれにしても、サーバ２０は、普段と異なる状況（寝坊や悪天候）が発生しているか否かを判断する。寝坊せず、天候も悪くなく、身支度もいつも通り進行している場合（ステップＳ４３６／Ｙｅｓ）、サーバ２０は処理を終了する。

一方、いつも通り進行していない場合や（ステップＳ４３６／Ｎｏ）、寝坊した場合（ステップＳ４１８／Ｎｏ）、雨等の悪天候の場合（ステップＳ４２４／Ｙｅｓ）は、サーバ２０は、ユーザにタクシーの配車予約の要否を確認する（ステップＳ４３９）。

次いで、室内スピーカ（センシングデバイス３０の一例）は、タクシーを呼ぶかをユーザに尋ね（ステップＳ４４２）、ユーザの回答をサーバ２０に送信する（ステップＳ４４５）。

そして、サーバ２０は、呼ぶ旨の了承を得た場合、タクシーの配車予約を行う（ステップＳ４４８）。具体的には、サーバ２０は、登録された行動パターンに従って、乗車場所、乗車時刻、および目的地の情報をタクシー配車用サーバ４０に送信して配車予約依頼を行う。

また、サーバ２０は、配車予約を行ったことを（ユーザの行動履歴に含まれる乗車履歴として）記憶する（ステップＳ４５１）。

以上、第２の実施例について説明した。なお、上記ステップＳ４３９ではユーザにタクシーの配車予約の要否を確認しているが、本実施例はこれに限定されず、ユーザに確認せずに配車予約を行ってもよい。

＜＜４．予約待機リストの利用＞＞
続いて、本開示の他の実施形態について説明する。

従来、ユーザが手動で行う配車予約では、一定期間先までかつ一定数の配車予約しか行えず、ユーザが定期的にタクシーを利用する等、予め複数回分の配車予約を行いたい場合でも、一定期間より先の分や一定数以上については、後日適切なタイミングで予約しなければならず、手間になっていた。また、一定期間より先の予定も含めて、予め複数回分の配車予約を行いたい場合も、一定期間より先の予約や一定数以上の予約は困難で、予定の直前に予約を行わなければならない等、面倒であった。

そこで、本開示の他の実施形態では、配車予約処理部２２４による配車予約処理において、配車予約待機リストを用いることで、タクシー配車におけるユーザの手間を低減させることを可能とする。

配車予約待機リストとは、ユーザ毎に生成される、配車予約の実行待ちリストであって、予約実行済みの場合はその旨の情報も含む。配車予約処理部２２４は、ユーザからの配車予約に基づいて、配車予約待機リストを生成し、配車予約待機リストのうち、予約実行可能数分まで配車予約を実行する。予約実行可能数は、例えば配車システム側（具体的には、タクシー配車用サーバ４０）の制限により設定され得る。予約実行可能数の制限には、例えば時間制限（１週間後まで等）がさらに含まれていてもよい。

本開示の他の実施形態では、配車予約待機リストを用いることで、ユーザが予約実行可能数を超える数の配車予約依頼をサーバ２０に対して行うことを可能とする。これにより、ユーザは、数や時間を気にせず、１回の予約で先の分まで複数の予約を行うことができる。また、定期予約の場合も（例えば毎週火曜の朝８時に特定の場所に配車等）、サーバ２０は、配車予約の実行後、配車がなされた際に、自動的に次の予約を配車予約待機リストに入れるようにすることで、ユーザの手間を低減し得る。

＜４－１．配車予約待機リストについて＞
本開示の他の実施形態による配車予約待機リストの一例を、下記表１に示す。サーバ２０の配車予約処理部２２４は、ユーザ端末１０から受信した配車予約情報（日時、場所）を、配車予約待機リストに入れる。

上記表１に示すように、配車予約待機リストのうち、サーバ２０の配車予約処理部２２４により、タクシー配車用サーバ４０に対して配車予約の依頼が実行された場合には、実行済みの情報が付加される。なお、上述した定期予約のリストと、上記表１に示すようなユーザによる任意予約のリストは、別のリストとして生成するようにしてもよい。

＜４－２．動作処理について＞
続いて、本開示の他の実施形態による動作処理について図面を用いて具体的に説明する。

（４－２－１．第１の動作処理例）
図９は、本開示の他の実施形態による第１の動作処理の流れを示すフローチャートである。

図９に示すように、まず、サーバ２０は、ユーザ端末１０から、配車予約情報を受信する（ステップＳ５０３）。

次に、サーバ２０の配車予約処理部２２４は、配車予約待機リストの予約数と、新規予約（新規の配車予約情報）の合計が、既定の予約可能枠数を超えるか否かを判断する（ステップＳ５０６）。既定の予約可能枠数は、ユーザ毎に設定されていてもよいし、タクシー配車用サーバ４０から要求された値であってもよい。既定の予約可能枠数が例えば３件の場合、配車予約処理部２２４は、新規予約を含めて３件を超えるか否かを判断する。

次いで、超えない場合（ステップＳ５０６／Ｎｏ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加し、さらに当該新規予約を実行する（ステップＳ５０９）。具体的には、配車予約処理部２２４は、新規予約の内容をタクシー配車用サーバ４０に送信し、配車予約の依頼を行う。また、配車予約処理部２２４は、当該新規予約に、実行済みを示す情報を付加する。

一方、超える場合（ステップＳ５０６／Ｙｅｓ）、配車予約処理部２２４は、新規予約の予約日時が、配車予約待機リストに含まれる予約実行済みの予約日時よりも早い日時か否かを判断する（ステップＳ５１２）。

次に、早い日時の場合（ステップＳ５１２／Ｙｅｓ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加し、実行済みの予約を１件キャンセルした上で（タクシー配車用サーバ４０に対してキャンセル通知）、追加した新規予約を実行する（ステップＳ５１５）。これにより、日時の早い予約を優先して予約実行することができる。キャンセルした分については、配車予約待機リストには残っているため、予約可能枠に空きが出た場合に、再度予約実行なされる。このように、各予約の実行調整を、サーバ２０が自動的に行うことで、ユーザの手間を省くことができる。

一方、早い日時ではない場合（ステップＳ５１２／Ｎｏ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加する（ステップＳ５１８）。

続いて、配車予約処理部２２４は、実行済みの予約の予約日時が過ぎた場合、当該予約を配車予約待機リストから削除する（ステップＳ５２１）。これにより、予約可能枠数が空くことが想定される。

次いで、予約可能枠が空いた場合（ステップＳ５２４／Ｙｅｓ）、配車予約処理部２２４は、配車予約待機リストに入ってる予約のうち、未実行の予約であって、最も日時が近い予約の実行を行う（ステップＳ５２７）。

（４－２－２．第２の動作処理例）
次に、第２の動作処理例について説明する。例えば、タクシー配車用サーバ４０側で、日時および場所毎に配車可能枠数が設定されている場合がある。配車可能枠数は、例えば過去実績や、予測される天候、予定されているイベント等に基づいて算出され得る。配車可能枠数の設定方法については特に限定しない。ここでは、図１０を参照して、配車可能枠数も考慮した配車予約の動作処理について説明する。

図１０は、本開示の他の実施形態による第２の動作処理の流れを示すフローチャートである。

図１０に示すように、まず、サーバ２０は、ユーザ端末１０から、配車予約情報を受信する（ステップＳ６０３）。

次に、サーバ２０の配車予約処理部２２４は、配車予約待機リストの予約数と、新規予約（新規の配車予約情報）の合計が、既定の予約可能枠数を超えるか否かを判断する（ステップＳ６０６）。

次いで、超えない場合（ステップＳ６０６／Ｎｏ）、配車予約処理部２２４は、予約条件での配車可能枠に空きがあるか否かを判断する（ステップＳ６０９）。具体的には、配車予約処理部２２４は、予約条件（日時および場所）をタクシー配車用サーバ４０に問い合わせ、配車可能枠に空きがあるか否かを確認する。

次に、配車可能枠に空きがある場合（ステップＳ６０９／Ｙｅｓ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加し、さらに当該新規予約を実行する（ステップＳ６１２）。また、配車予約処理部２２４は、当該新規予約に、実行済みを示す情報を付加する。

次いで、上記ステップＳ６０６で、既定の予約可能枠数を超える場合（ステップＳ６０６／Ｙｅｓ）、配車予約処理部２２４は、新規予約の予約日時が、配車予約待機リストに含まれる予約実行済みの予約日時よりも早い日時か否かを判断する（ステップＳ６１５）。

次に、早い日時の場合（ステップＳ６１５／Ｙｅｓ）、配車予約処理部２２４は、予約条件での配車可能枠に空きがあるか否かを判断する（ステップＳ６１８）。

次いで、配車可能枠に空きがある場合（ステップＳ６１８／Ｙｅｓ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加し、実行済みの予約を１件キャンセルした上で、追加した新規予約を実行する（ステップＳ６２１）。

次に、上記ステップＳ６１５で、早い日時ではない場合（ステップＳ６１５／Ｎｏ）、配車予約処理部２２４は、配車予約待機リストに新規予約を追加する（ステップＳ６２４）。

続いて、配車予約処理部２２４は、実行済みの予約の予約日時が過ぎた場合、当該予約を配車予約待機リストから削除する（ステップＳ６２７）。

次いで、予約可能枠が空いた場合（ステップＳ６３０／Ｙｅｓ）、配車予約処理部２２４は、配車予約待機リストに入ってる予約のうち、未実行の予約であって、最も日時が近い予約を選択する（ステップＳ６３３）。

次に、配車予約処理部２２４は、選択した予約における予約条件での配車可能枠に空きがあるか否かを判断する（ステップＳ６３６）。

次いで、配車可能枠に空きがある場合（ステップＳ６３６／Ｙｅｓ）、配車予約処理部２２４は、予約の実行を行う（ステップＳ６３９）。

そして、配車可能枠に空きがない場合（ステップＳ６０９／Ｎｏ、Ｓ６１８／Ｎｏ、またはＳ６３６／Ｎｏ）、配車予約処理部２２４は、指定された予約条件では配車可能枠の制限により予約の実行が不可であることをユーザに通知した上で、代替手段等を実行する（ステップＳ６４２）。

（代替手段）
代替手段の一つとして、「キャンセル待ち」が挙げられる。配車予約処理部２２４は、配車可能枠に空きが出るまで待機し、空きが出た場合に予約実行する。

また、代替手段の一つとして、「修正」が挙げられる。配車予約処理部２２４は、予約実行可能な別の予約条件（なるべくユーザ希望の予約条件に近い日時、場所で）に修正し、これをユーザに提案する。修正案を予約実行した場合の予約待機リストの例を下記表２に示す。下記表２では、例えば日時X3、場所Yでの予約実行が不可だった場合に、各条件と近傍の日時・時間での予約（日時X3’、場所Y’）に修正し、修正した予約を実行した場合を示す。

また、代替手段の一つとして、「スキップ」が挙げられる。配車予約処理部２２４は、配車可能枠の制限により予約実行が不可であった場合、その予約をスキップし、配車予約リストから次の予約を実行するようにしてもよい（この際、再度、配車可能枠の確認は行われ得る）。スキップして次の予約を実行した場合の予約待機リストの例を下記表３に示す。下記表３では、例えば日時X3、場所Yでの予約実行が不可だった場合に、その次の「日時X4、場所Y」の予約を実行した場合を示す。

以上、一例として３つの代替手段について説明した。配車予約処理部２２４は、代替手段について、例えば「修正」、「スキップ」、「キャンセル待ち」の順に提案したり、又は全ての代替手段を同時に提案してもよい。

また、図１０に示す動作処理は一例であって、本開示はこれに限定されない。図１０に示す例では、「予約可能枠」の参照後に、「予約条件での配車可能枠」を参照して、予約実行ができるか否か判断しているが、これに限らず、配車予約処理部２２４は、「予約条件での配車可能枠」を先に参照してから、「予約可能枠」を参照してもよい。

＜４－３．変形例＞
サーバ２０は、複数回の予約を実行出来るユーザを制限し（例えば優先会員と一般会員とを区別し、予約可能数を異ならせる）、全体の予約枠のうち一定割合は優先客のために空けておいてもよい。

また、サーバ２０は、ユーザが予め複数回の予約を実行出来る権利をまとめて購入出来ることとし、当該顧客を優先客としてもよい。また、サーバ２０は、定期予約を設定する顧客は更に優遇するようにしてもよい。定期予約はユーザ都合でのキャンセル率が低いため、配車の予測精度が上がり、タクシー配車用サーバ４０における効率的な配車運用に貢献するためである。

また、ユーザの予約可能枠に空きがある場合でも、予約日時が遠い場合（例えば１か月以上先）には、配車予約処理部２２４は、当該遠い日時の予約は実行しないようにしてもよい。配車予約待機リストには入っている状態であるため、予約日時が近付いた際に、配車予約処理部２２４により自動的に予約実行される。

また、サーバ２０は、予約日時が近くなっても（例えば２日前）、予約が実行できない場合、ユーザに通知し、代替案を呈示する。代替案は、例えばタクシー以外の交通手段（バス、ハイヤー、相乗りサービス等）や、予約可能な近い日時・場所への修正が挙げられる。

また、サーバ２０は、ノーショー（予約をした人がキャンセルの連絡もないまま現れないこと）や直前キャンセルを防ぐべく、予約日時から一定時間前（例えば予約日の２日前）に、変更やキャンセルの必要がないかユーザに通知を行ってもよい。

また、サーバ２０は、天候の急変や、人流が発生するイベントのスケジュール変更等の影響で、タクシー配車用サーバ４０が時間・場所毎の配車可能枠を減らすことになり、予約が出来なくなった場合（キャンセルになった場合）、センシングデバイス３０は、予約の修正等の代替手段を、インセンティブ（割引クーポン等）と共にユーザに呈示してもよい。例えば、急な雨や電車の見合わせ、イベントの終了時間が遅くなって終電間際になった場合等に、緊急手段的に駅周辺により多くのタクシーを用意することが考え得る。この場合、多くのタクシーを用意するために、周辺の場所における配車可能枠を減らす対応が取られる。タクシー配車用サーバ４０は、例えば最も遅くセンシングデバイス３０から依頼された予約からキャンセルするようにしてもよい。

＜＜５．補足＞＞
以上、添付図面を参照しながら本開示の好適な実施形態について詳細に説明したが、本技術はかかる例に限定されない。本開示の技術分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、これらについても、当然に本開示の技術的範囲に属するものと了解される。

例えば、上述したユーザ端末１０、サーバ２０、センシングデバイス３０、またはタクシー配車用サーバ４０に内蔵されるＣＰＵ、ＲＯＭ、およびＲＡＭ等のハードウェアに、ユーザ端末１０、サーバ２０、センシングデバイス３０、またはタクシー配車用サーバ４０の機能を発揮させるためのコンピュータプログラムも作成可能である。また、当該コンピュータプログラムを記憶させたコンピュータ読み取り可能な記憶媒体も提供される。

また、本明細書に記載された効果は、あくまで説明的または例示的なものであって限定的ではない。つまり、本開示に係る技術は、上記の効果とともに、または上記の効果に代えて、本明細書の記載から当業者には明らかな他の効果を奏しうる。

なお、本技術は以下のような構成も取ることができる。
（１）
ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を備える、情報処理装置。
（２）
前記行動パターンは、前記ユーザのタクシー乗車に関連する行動を含む、前記（１）に記載の情報処理装置。
（３）
前記タクシー乗車に関連する行動は、前記ユーザがタクシーに乗車するまでの行動のセンシング結果を少なくとも含む、前記（２）に記載の情報処理装置。
（４）
前記制御部は、前記タクシー乗車に関連する行動のうち、同じ行動が所定回数以上発生した場合、当該行動を前記行動パターンとして登録する、前記（２）または（３）に記載の情報処理装置。
（５）
前記制御部は、前記ユーザから承認を得た場合に、前記行動パターンを登録する、前記（４）に記載の情報処理装置。
（６）
前記制御部は、前記ユーザによる設定に基づいて、前記行動パターンを登録する、前記（２）または（３）に記載の情報処理装置。
（７）
前記制御部は、新たなセンシング結果に基づいて前記登録した行動パターンを修正する、前記（２）～（６）のいずれか１項に記載の情報処理装置。
（８）
前記センシング結果は、１以上のセンシングデバイスから取得される、前記（１）～（７）のいずれか１項に記載の情報処理装置。
（９）
前記センシングデバイスには、前記ユーザが利用するユーザ端末が含まれる、前記（８）に記載の情報処理装置。
（１０）
前記制御部は、前記ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとが一致する場合に、タクシーの配車が必要であると判断する、前記（１）～（９）のいずれか１項に記載の情報処理装置。
（１１）
前記制御部は、さらに前記ユーザから承認を得た場合に、前記タクシーの配車を実行する、前記（１０）に記載の情報処理装置。
（１２）
前記制御部は、タクシーの配車が必要であると判断された際に、前記タクシーの配車を実行する、前記（１０）に記載の情報処理装置。
（１３）
前記制御部は、ユーザ行動のセンシング結果に基づいて、前記行動パターンより前記ユーザの行動が遅れている場合、前記ユーザの行動を急かす通知を行う、前記（２）～（１２）のいずれか１項に記載の情報処理装置。
（１４）
プロセッサが、
ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断することを含む、情報処理方法。
（１５）
コンピュータを、
ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部として機能させる、プログラム。
（１６）
ユーザ行動をセンシングする１以上のセンシングデバイスと、
前記１以上のセンシングデバイスから取得した前記ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を有する情報処理装置と、
を備える、情報処理システム。

１０ ユーザ端末
２０ サーバ
２１０ 通信部
２２０ 制御部
２２１ 行動履歴記憶処理部
２２２ 行動パターン登録処理部
２２３ 配車要否判断部
２２４ 配車予約処理部
２３０ 記憶部
３０ センシングデバイス
４０ タクシー配車用サーバ

Claims (16)

1. ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を備える、情報処理装置。
2. 前記行動パターンは、前記ユーザのタクシー乗車に関連する行動を含む、請求項１に記載の情報処理装置。
3. 前記タクシー乗車に関連する行動は、前記ユーザがタクシーに乗車するまでの行動のセンシング結果を少なくとも含む、請求項２に記載の情報処理装置。
4. 前記制御部は、前記タクシー乗車に関連する行動のうち、同じ行動が所定回数以上発生した場合、当該行動を前記行動パターンとして登録する、請求項２に記載の情報処理装置。
5. 前記制御部は、前記ユーザから承認を得た場合に、前記行動パターンを登録する、請求項４に記載の情報処理装置。
6. 前記制御部は、前記ユーザによる設定に基づいて、前記行動パターンを登録する、請求項２に記載の情報処理装置。
7. 前記制御部は、新たなセンシング結果に基づいて前記登録した行動パターンを修正する、請求項２に記載の情報処理装置。
8. 前記センシング結果は、１以上のセンシングデバイスから取得される、請求項１に記載の情報処理装置。
9. 前記センシングデバイスには、前記ユーザが利用するユーザ端末が含まれる、請求項８に記載の情報処理装置。
10. 前記制御部は、前記ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとが一致する場合に、タクシーの配車が必要であると判断する、請求項１に記載の情報処理装置。
11. 前記制御部は、さらに前記ユーザから承認を得た場合に、前記タクシーの配車を実行する、請求項１０に記載の情報処理装置。
12. 前記制御部は、タクシーの配車が必要であると判断された際に、前記タクシーの配車を実行する、請求項１０に記載の情報処理装置。
13. 前記制御部は、ユーザ行動のセンシング結果に基づいて、前記行動パターンより前記ユーザの行動が遅れている場合、前記ユーザの行動を急かす通知を行う、請求項２に記載の情報処理装置。
14. プロセッサが、
    ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断することを含む、情報処理方法。
15. コンピュータを、
    ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部として機能させる、プログラム。
16. ユーザ行動をセンシングする１以上のセンシングデバイスと、
    前記１以上のセンシングデバイスから取得した前記ユーザ行動のセンシング結果と、登録された前記ユーザの行動パターンとに基づいて、タクシーの配車要否を判断する制御部を有する情報処理装置と、
    を備える、情報処理システム。
    

Images