JP2019121213A - スケジュール管理システム及びスケジュール管理装置 - Google Patents

Abstract

【課題】ユーザの移動を考慮したスケジュール管理を行うことを可能にしたスケジュール管理システム及びスケジュール管理装置を提供する。【解決手段】過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集し、同一又は類似するユーザの特性毎に区分して、移動実績を紐付けて格納するデータベースを作成する。一方で、ユーザによってスケジュールの登録操作が行われた場合に、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合において、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた過去の移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定するように構成する。【選択図】図５

Description

本発明は、ユーザのスケジュールを管理するスケジュール管理システム及びスケジュール管理装置に関する。

従来より、ユーザによって登録されたユーザのスケジュールを管理するシステムについて種々提案されている。このようなシステムでは、ユーザがスマートフォン等の通信端末を用いてスケジュールの内容、日付、時間等を入力することによって、入力したスケジュールの内容が日付や時間に紐付けられて通信端末或いはサーバ装置の記憶媒体に格納される。そして、ユーザの操作に応じて登録済みのスケジュールの一覧を表示したり、登録されたスケジュールの日付や時間が近づいた場合に、その旨をユーザに案内すること等を行う。

また、上記システムではユーザの移動を考慮して登録されたスケジュールの実行が現実的に可能であるか否かを判定し、判定結果を用いたスケジュールの管理を行うことについても提案されている。例えば、特開２００１−１４３９２号公報には、ユーザの現在位置から直近のスケジュールの予定場所まで移動するのに必要な所要時間を算出し、算出した所要時間と現在時刻から、スケジュールの予定時刻までに予定場所へユーザが移動可能か否かを判定し、判定結果を案内することについて提案されている。

特開２００１−１４３９２号公報（第３−５頁）

しかしながら、上記特許文献１に記載された技術では、スケジュールにおいてスケジュールを実行する予定場所が予めユーザによって登録されていなければ、ユーザの移動が必要なスケジュールであるか否かの判断を行うことができない。一方で、ユーザがスケジュールを登録する際には、必ずしもスケジュールを実行する予定場所が登録されるとは限らない。特にユーザが行き慣れた場所でのスケジュールでは、場所などを省略することも一般的である。その結果、特許文献１に記載された技術では、ユーザのスケジュールの管理を適切に行うことができない問題があった。

本発明は前記従来における問題点を解消するためになされたものであり、登録されたスケジュールの内容にかかわらず、ユーザの移動を考慮したスケジュール管理を行うことを可能にしたスケジュール管理システム及びスケジュール管理装置を提供することを目的とする。

前記目的を達成するため本発明に係るスケジュール管理システムは、ユーザのスケジュールを登録するスケジュール登録手段と、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する移動判定手段と、前記移動判定手段の判定結果に基づいて登録された前記スケジュールを管理するスケジュール管理手段と、を有するスケジュール管理システムであって、過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する移動実績収集手段と、同一又は類似するユーザの特性毎に区分して、前記移動実績を紐付けて格納する移動実績格納手段と、を有し、前記移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定する。
尚、「ユーザの移動が必要なスケジュール」とは、スケジュールを実行する前にスケジュールを実行する場所までユーザが移動する必要があるスケジュールをいう。但し、ごく短い時間や距離の移動（例えば同一部屋内での移動、同一施設内での移動）などは移動とみなさないのが望ましい。
また、「スケジュールの管理」には、スケジュールの調整、スケジュールの変更の提案、表示や音声によるユーザへのスケジュールの案内等についても含む。

また、本発明に係るスケジュール管理装置は、ユーザのスケジュールを登録するスケジュール登録手段と、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する移動判定手段と、前記移動判定手段の判定結果に基づいて登録された前記スケジュールを管理するスケジュール管理手段と、を有するスケジュール管理装置であって、過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する移動実績収集手段と、同一又は類似するユーザの特性毎に区分して、前記移動実績を紐付けて格納する移動実績格納手段と、を有し、前記移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定する。

前記構成を有する本発明に係るスケジュール管理システム及びスケジュール管理装置によれば、ユーザの特性とスケジュールに対するユーザの移動有無の実績を紐付けてデータベース化することによって、登録されたスケジュールの内容からユーザの移動を必要とするスケジュールであるか否か判定できない場合であっても、対応する過去の移動実績からユーザの移動が必要なスケジュールであるか否かを適切に判定することが可能となる。その結果、登録されたスケジュールの内容にかかわらず、ユーザの移動を考慮したスケジュール管理が可能となる。

本実施形態に係るスケジュール管理システムを示した概略構成図である。 本実施形態に係るスケジュール管理システムの構成を示したブロック図である。 スケジュールＤＢに記憶される情報の一例を示した図である。 移動実績ＤＢに記憶される情報の一例を示した図である。 グルーピングＤＢのデータ構造を示した図である。 本実施形態に係る情報端末の制御系を模式的に示すブロック図である。 スケジュールの入力例を示した図である。 本実施形態に係るＤＢ作成処理プログラムのフローチャートである。 本実施形態に係るスケジュール管理処理プログラムのフローチャートである。 スケジュールの管理方法の一例を示した図である。

以下、本発明に係るスケジュール管理システムについて具体化した一実施形態に基づき図面を参照しつつ詳細に説明する。先ず、本実施形態に係るスケジュール管理システム１の概略構成について図１及び図２を用いて説明する。図１は本実施形態に係るスケジュール管理システム１を示した概略構成図である。図２は本実施形態に係るスケジュール管理システム１の構成を示したブロック図である。

図１に示すように、本実施形態に係るスケジュール管理システム１は、スケジュール管理センタ２が備えるサーバ装置（スケジュール管理装置）３と、ユーザ４が所持する情報端末５と、を基本的に有する。また、サーバ装置３と情報端末５は通信ネットワーク網６を介して互いに電子データを送受信可能に構成されている。尚、情報端末５としては例えば携帯電話機、スマートフォン、タブレット型端末、パーソナルコンピュータ、ナビゲーション装置等がある。

ここで、スケジュール管理センタ２が備えるサーバ装置３は、ユーザ４が情報端末５を介して登録したスケジュールを管理する装置である。例えば、ユーザの要求があった場合やスケジュールに応じたタイミング（例えばスケジュールで指定された日時の１時間前）において登録されたスケジュールの内容を配信したり、必要に応じてスケジュールの修正の提案についても行う。

一方でサーバ装置３は、過去のユーザのスケジュールに対する移動の有無を特定する実績（以下、移動実績という）を収集し、収集した各情報に基づいてユーザの特性と移動実績とを紐付けたデータベースについても作成する。そして、作成したデータベースは、後述のように登録されたスケジュールの内容からユーザの移動が必要なスケジュールであるか否かを判定できない場合に、移動が必要なスケジュールであるかを判定するのに用いられる。

一方、情報端末５は、ユーザ４が所持し、ユーザ４がスケジュールを入力することによってスケジュールを登録する機能や登録されたスケジュールを案内する機能等を備えた情報端末が用いられ、例えば携帯電話機、スマートフォン、タブレット型端末、パーソナルコンピュータ、ナビゲーション装置等が該当する。特に情報端末５がスマートフォン、タブレット型端末、パーソナルコンピュータである場合については、それらの情報端末５にユーザのスケジュールを管理する為のアプリケーションプログラムがインストールされた状態とする。

尚、各ユーザ４によって登録されたスケジュールについては、ユーザ４が有する各情報端末５において記憶しても良いし、サーバ装置３で複数のユーザ４のスケジュールを一括して記憶しても良い。以下の説明では、ユーザ４が有する各情報端末５とサーバ装置３のそれぞれに記憶することとする。

また、通信ネットワーク網６は全国各地に配置された多数の基地局と、各基地局を管理及び制御する通信会社とを含み、基地局及び通信会社を有線（光ファイバー、ＩＳＤＮ等）又は無線で互いに接続することにより構成されている。ここで、基地局は情報端末５との通信をするトランシーバー（送受信機）とアンテナを有する。そして、基地局は通信会社の間で無線通信を行う一方、通信ネットワーク網６の末端となり、基地局の電波が届く範囲（セル）にある情報端末５の通信をサーバ装置３との間で中継する役割を持つ。

続いて、スケジュール管理システム１におけるサーバ装置３の構成について図２を用いてより詳細に説明する。サーバ装置３は、図２に示すようにサーバ制御ＥＣＵ１１と、サーバ制御ＥＣＵ１１に接続された情報記録手段としてのスケジュールＤＢ１２と、移動実績ＤＢ１３と、グルーピングＤＢ１４と、サーバ側通信装置１５とを備える。

サーバ制御ＥＣＵ１１（エレクトロニック・コントロール・ユニット）は、サーバ装置３の全体の制御を行う電子制御ユニットであり、演算装置及び制御装置としてのＣＰＵ２１、並びにＣＰＵ２１が各種の演算処理を行うにあたってワーキングメモリとして使用されるＲＡＭ２２、制御用のプログラムのほか、後述のＤＢ作成処理プログラム（図８）、スケジュール管理処理プログラム（図９参照）等が記録されたＲＯＭ２３、ＲＯＭ２３から読み出したプログラムを記憶するフラッシュメモリ２４等の内部記憶装置を備えている。尚、サーバ制御ＥＣＵ１１は、後述の情報端末５のＥＣＵとともに処理アルゴリズムとしての各種手段を有する。例えば、スケジュール登録手段は、ユーザのスケジュールを登録する。移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する。スケジュール管理手段は、移動判定手段の判定結果に基づいて登録されたスケジュールを管理する。移動実績収集手段は、過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する。移動実績格納手段は、同一又は類似するユーザの特性毎に区分して、移動実績を紐付けて格納する。

また、スケジュールＤＢ１２は、情報端末５をユーザが操作することによって入力されたスケジュールの内容について、ユーザ毎に該ユーザの特性と紐付けて記憶する記憶手段である。尚、本実施形態においては、スケジュールの内容として、（ａ）件名、（ｂ）日時、（ｃ）場所が含まれる。但し、（ｃ）場所についてはユーザによって入力されない場合もあり、その場合については空白（データ無し）となる。但し、場所が入力されていない場合であっても、件名から場所が推定できる場合には、件名から推定される場所をサーバ装置３側で入力しても良い。一方、ユーザの特性としては年代と性別が含まれる。

図３はスケジュールＤＢ１２に記憶される情報の一例を示した図である。図３に示すように、スケジュールＤＢ１２は、ユーザ毎にユーザの特性とユーザによって現時点で登録されているスケジュール（即ち未実施のスケジュール）及び過去に登録されていたスケジュール（即ち実施済みのスケジュール）の内容が含まれる。但し、所定期間以上過去のスケジュールについては順次削除するのが望ましい。また、スケジュールの内容としては上記（ａ）〜（ｃ）に関する情報が含まれる。例えば、図３に示すスケジュールＤＢ１２には、ユーザＡについて、ユーザ特性として３１〜４０歳の男性であり、スケジュールの内容として『２０１７年の１２月１０日の１０：００に○○さんに電話する』と『２０１７年の１２月１２日の１３：００に資料作成』と『２０１７年の１２月１２日の１５：００にＡ社の１０１会議室で打ち合わせ』とが登録されている。同様にして、他のユーザのユーザ特性やスケジュールについても記憶されている。尚、スケジュールＤＢ１２は、情報端末５において新たなスケジュールの登録がある度に更新される。また、ユーザ特性としては必ずしも年代と性別の両方を含む必要は無く、一方のみでも良い。

一方、移動実績ＤＢ１３は、スケジュールＤＢ１２に記憶されるすスケジュールの内、特に過去に登録されていたスケジュール（即ち実施済みのスケジュール）の実行に際してユーザが移動したか否かを示す移動実績を記憶する記憶手段である。具体的には、サーバ装置３が、情報端末５の有するＧＰＳの検出データ（ユーザの移動履歴）を取得し、スケジュールが登録された日時の直近所定時間以内（例えば１１：００のスケジュールでは１０：３０〜１１：００の間）にユーザが移動したか否かを判定する。但し、ユーザが移動していたとしても、ごく短い距離や時間の移動（例えば同一部屋内での移動、同一施設内での移動）などは移動とみなさないのが望ましい。そして、ユーザが移動している場合には該スケジュールの実行に際してユーザが移動したと推定し、移動していない場合には該スケジュールの実行に際してユーザが移動していないと推定し、その結果をスケジュールに紐付けて移動実績ＤＢ１３に記憶する。

図４は移動実績ＤＢ１３に記憶される情報の一例を示した図である。図４に示すように、移動実績ＤＢ１３は、ユーザ毎且つスケジュール毎に移動実績が紐付けられて記憶される。但し、現時点で実施されていないスケジュールに関しては、移動実績は紐付けられない。例えば、図４に示す移動実績ＤＢ１３には、ユーザＡが過去に登録した『２０１７年の１２月１０日の１０：００に○○さんに電話する』についてはスケジュールの実行に際してユーザが移動しなかったことを示しており、『２０１７年の１２月１２日の１５：００にＡ社の１０１会議室で打ち合わせ』についてはスケジュールの実行に際してユーザが移動したことを示している。同様にして、他のユーザやスケジュールに対する移動実績についても記憶されている。尚、移動実績ＤＢ１３は、定期的（例えば２４時間毎）に更新される。

一方、グルーピングＤＢ１４は、移動実績ＤＢ１３に格納された情報を統計することによって生成されるデータベースである。特に本実施形態では、同一又は類似するユーザの特性に対してスケジュールの内容と移動事績の紐付けを行い、ユーザの特性とスケジュールの内容と移動実績との関連性を示すデータベースとする。そして、サーバ装置３は、作成されたグルーピングＤＢ１４に基づいて後述のようにユーザによって登録されたスケジュールの管理を行う。例えば図５はグルーピングＤＢ１４に記憶されるデータの一例を示した図である。

図５に示すようにグルーピングＤＢ１４には、ユーザを同一又は類似するユーザ特性毎にグループ分けする。そして、各グループに対してスケジュールの内容と移動実績とが紐付けて格納される。但し、格納されるのは移動実績ＤＢ１３において移動実績が対応付けられたスケジュール（即ち実施済みのスケジュール）のみとなる。例えばユーザＡとユーザＢは図３に示すように年代や性別が一致している。従って、ユーザＡとユーザＢは同一又は類似するユーザ特性を有すると認定し、同じグループに分類する。具体的には、性別が一致し且つ年齢が１０歳単位で区分した際に同じ区分となる場合に同一又は類似するユーザ特性を有するとみなす。また、スケジュールの内容として格納されるのは上記（ａ）〜（ｃ）に関する情報である。

尚、図５に示す例では同一又は類似するユーザ特性毎に区分してスケジュールの内容と移動事績が紐付けて格納されているが、同一のユーザ特性毎に区分してスケジュールの内容と移動事績を紐付けて記憶しても良い。具体的には、年齢と性別が完全に一致する場合に同一のユーザ特性を有するとみなす。

作成されたグルーピングＤＢ１４は、ユーザの特性とスケジュールの内容と移動事績との関連性を示すものとなる。従って、サーバ装置３は特に登録されたスケジュールがユーザの移動が必要なスケジュールか否かを判定できない場合に、グルーピングＤＢ１４に記憶された情報を用いてユーザの移動が必要なスケジュールか否かを判定することが可能となる。そして、判定結果を用いてスケジュールの管理を行う。詳細については後述する。

一方、サーバ側通信装置１５は情報の送受信対象となる情報端末５と通信ネットワーク網６を介して通信を行う為の通信装置である。また、情報端末５以外にインターネット網等に対する通信も可能である。

次に、ユーザ４が所有する情報端末５の概略構成について図６を用いて説明する。図６は本実施形態に係る情報端末５の制御系を模式的に示すブロック図である。尚、以下では特に情報端末５がスマートフォンである場合を例に挙げて説明する。

図６に示すように情報端末５はデータバスＢＵＳに、ＣＰＵ３１と、情報端末５を所持するユーザ４に関するユーザ情報（ユーザＩＤ、氏名、年齢、性別等）や登録されたスケジュールやユーザの移動履歴等が記憶されたメモリ３２と、通信ネットワーク網６の基地局との間で信号の送受信を行う送受信回路部（ＲＦ）３３と、送受信回路部３３において受信したＲＦ（Radio Frequency）信号をベースバンド信号に変換するとともにベースバンド信号をＲＦ信号に変換するベースバンド処理部３４と、マイクロホン３５及びスピーカ３６等とのインターフェイスである入出力部３７と、液晶表示パネル等で構成されたディスプレイ３８と、タッチパネルやハードボタン等から構成される入力操作部３９と、ＧＰＳ４０と、カメラ４１とが接続されることにより構成されている。

ここで、情報端末５に内蔵されるＣＰＵ３１は、メモリ３２に格納されている動作プログラムに従って種々の動作を実行する情報端末５の制御手段であり、メモリ３２とともに情報端末ＥＣＵ４２を構成する。また、情報端末ＥＣＵ４２の各種処理内容は必要に応じてディスプレイ３８に表示される。

また、メモリ３２は情報端末５を所持するユーザ４に関するユーザ情報（ユーザＩＤ、氏名、年齢、性別等）、ユーザによって入力されたスケジュール、ＧＰＳ４０で検出されたユーザの移動履歴等が記憶された記憶媒体である。また、後述のスケジュール管理処理プログラム（図９参照）を含む各種アプリケーションプログラムについても記憶される。尚、ユーザによって入力されたスケジュールはメモリ３２に記憶せずにサーバ装置３に記憶し、通信により取得する構成としても良い。また、メモリ３２は、ハードディスク、メモリーカード等により構成しても良い。

ここで、メモリ３２に格納される『スケジュール』は、ユーザ４が該当するアプリケーションプログラムを起動させた状態で、スケジュールの内容を入力することによって登録される。入力されるスケジュールの内容は、（ａ）件名、（ｂ）日時、（ｃ）場所とする。但し、全ての項目を必ずしも入力する必要は無い。例えば、図８に示すようにアプリケーションプログラムが起動されると、ディスプレイ３８においてスケジュール入力画面４５が表示される。スケジュール入力画面４５ではカレンダーが表示され、ユーザがカレンダー内の該当する日付を選択すると、件名、日時、場所を入力可能となり、各情報を入力することによってスケジュールの登録が可能となる。また、既に登録されたスケジュールの内容の修正も可能である。尚、日時としては日時の範囲（例えば２０１７年１２月２１日の１０：００〜１１：００）を指定することも可能である。

また、ディスプレイ３８は、筐体の一面に配設されており、液晶ディスプレイや有機ＥＬディスプレイ等が用いられる。そして、情報端末５にインストールされている各種アプリケーションを実行する為のトップ画面や、実行されたアプリケーションに係る画面（インターネット画面、メール画面等）や、画像、動画等の各種情報が表示される。また、ユーザのスケジュールを管理する為のアプリケーションが起動された状態では、スケジュールの入力画面や、現時点で登録されているスケジュールを案内する案内画面等についても表示される。

また、入力操作部３９は、ディスプレイ３８の前面に設けられたタッチパネルや筐体に配置されたハードボタン等によって構成されている。そして、情報端末ＥＣＵ４２は、タッチパネルやハードボタンの押下等により出力される電気信号に基づき、対応する各種の動作を実行すべく制御を行う。また、本実施形態では、ユーザがスケジュールの内容を情報端末５に入力する際にも操作される。尚、入力操作部３９は、番号／文字入力キー、表示された内容を選択するためのカーソルを動かすカーソルキー、選択を確定する決定キー等の各種キー等により構成することもできる。

また、ＧＰＳ４０は、人工衛星によって発生させられた電波を受信することにより、情報端末５（即ちユーザ４）の現在位置及び現在日時を検出可能とする。また、ＧＰＳ４０以外にも情報端末５の現在位置や方位を検出する為の他の装置（例えばジャイロセンサ等）を備える構成としても良い。

また、カメラ４１は、例えばＣＣＤ等の固体撮像素子を用いたカメラにより構成される小型の撮像装置であり、情報端末５の背面側に内蔵される。そして、専用のアプリケーションプログラムが起動された状態で、ユーザが入力操作部３９を操作することによって周辺を撮像することが可能となる。尚、カメラ４１で撮像された撮像画像は、メモリ３２に格納される。

続いて、前記構成を有する本実施形態に係るスケジュール管理システム１を構成するサーバ装置３においてＣＰＵ２１が実行するＤＢ作成処理プログラムについて図８に基づき説明する。図８は本実施形態に係るＤＢ作成処理プログラムのフローチャートである。ここで、ＤＢ作成処理プログラムは所定時間間隔（例えば２４時間間隔）で実行され、過去に登録されたスケジュールと移動実績を統計することによってユーザの特性とスケジュールの内容と移動実績とを紐付けたＤＢを作成するプログラムである。尚、以下の図８及び図９にフローチャートで示されるプログラムは、情報端末５が備えているメモリ３２又はサーバ装置３が備えているＲＡＭ２２やＲＯＭ２３等に記憶されており、ＣＰＵ３１又はＣＰＵ２１により実行される。

先ず、ＤＢ作成処理プログラムではステップ（以下、Ｓと略記する）１において、ＣＰＵ２１は、情報端末５からユーザの特性を特定する情報を収集する。尚、本実施形態ではユーザの特性として特に年代と性別とを含む。そして、前回の処理時からユーザの特性が変化していた場合には、スケジュールＤＢ１２や移動実績ＤＢ１３に格納されたユーザの特性を更新する。

次に、Ｓ２においてＣＰＵ２１は、スケジュールＤＢ１２に格納されたスケジュールの内容を読み出す。スケジュールＤＢ１２は、後述のようにユーザが情報端末５においてスケジュールの登録操作を行うことによって随時内容が更新される（Ｓ２２）。また、スケジュールＤＢ１２には、現時点で登録されているスケジュール（即ち未実施のスケジュール）に加えて、過去に登録されていたスケジュール（即ち実施済みのスケジュール）の内容についても含まれる。

続いて、Ｓ３においてＣＰＵ２１は、情報端末５からＧＰＳの検出データ（ユーザの移動履歴）を収集し、前回の処理時から現時点までに新たにユーザに実行されたスケジュールについて、スケジュールの実行に際してユーザが移動したか否かを示す移動実績を特定する。具体的には、スケジュール内容に含まれる日時の直近所定時間以内（例えば１１：００のスケジュールでは１０：３０〜１１：００の間）にユーザが移動していた場合には該スケジュールの実行に際してユーザが移動したと推定し、ユーザが移動していない場合には該スケジュールの実行に際してユーザが移動していないと推定する。但し、ユーザが移動していたとしても、ごく短い距離や時間の移動（例えば同一部屋内での移動、同一施設内での移動）などは移動とみなさないのが望ましい。

その後、Ｓ４においてＣＰＵ２１は、前記Ｓ３の判定結果に基づいて移動実績ＤＢ１３を更新する。即ち、移動実績ＤＢ１３に格納されたスケジュールの内、前回の処理時から現時点までに新たにユーザに実行されたスケジュールについて、前記Ｓ３で特定された移動実績を紐付けて格納する。

続いて、Ｓ５においてＣＰＵ２１は、前記Ｓ４で更新された移動実績ＤＢ１３に格納された情報を統計することによって、グルーピングＤＢ１４を更新する。グルーピングＤＢ１４は、図５に示すようにユーザを同一又は類似するユーザ特性毎にグループ分けし、各グループに対してスケジュールの内容と移動実績とが紐付けて格納される。前記Ｓ５で更新されたグルーピングＤＢ１４は、ユーザの特性とスケジュールの内容と移動実績との関連性を示すものとなる。従って、サーバ装置３は後述のように登録されたスケジュールがユーザの移動が必要なスケジュールか否かを判定できない場合に、グルーピングＤＢ１４に記憶された情報を用いてユーザの移動が必要なスケジュールか否かを判定することが可能となる。

次に、本実施形態に係るスケジュール管理システム１を構成するサーバ装置３及び情報端末５において実行するスケジュール管理処理プログラムについて図９に基づき説明する。図９は本実施形態に係るスケジュール管理処理プログラムのフローチャートである。ここで、スケジュール管理処理プログラムは情報端末５においてユーザのスケジュールを管理する為の所定のアプリケーションプログラムが起動された後に実行され、ユーザのスケジュールの登録並びに管理を行うプログラムである。

先ず、情報端末５において実行されるスケジュール管理処理プログラムについて説明する。
Ｓ１１においてＣＰＵ３１は、ユーザが新たなスケジュールの登録操作、或いは既に登録されていたスケジュールを修正する操作が行われたか否かを判定する。尚、スケジュールの登録操作やスケジュールの修正操作は、例えばスケジュールを管理する為のアプリケーションが情報端末５で起動された状態で、ディスプレイ３８に表示された画面に従って行う（図８参照）。

そして、ユーザが新たなスケジュールの登録操作、或いは既に登録されていたスケジュールを修正する操作が行われたと判定された場合（Ｓ１１：ＹＥＳ）には、Ｓ１２へと移行する。それに対して、ユーザが新たなスケジュールの登録操作、或いは既に登録されていたスケジュールを修正する操作が行われていないと判定された場合（Ｓ１１：ＮＯ）には、当該スケジュール管理処理プログラムを終了する。

Ｓ１２においてＣＰＵ３１は、サーバ装置３に対して登録或いは修正されたスケジュールに関する情報を送信する。送信される情報には、情報端末５の所有者であるユーザ４を識別するユーザＩＤと、前記Ｓ１１で登録又は修正されたスケジュールの内容（例えば文章データ）を含む。その後、後述のように情報端末５から情報を受信したサーバ装置３においてスケジュールの管理が行われる（Ｓ２２〜Ｓ３２）。

次に、サーバ装置３において実行されるスケジュール管理処理プログラムについて説明する。
先ず、Ｓ２１においてＣＰＵ２１は、情報端末５から情報の送信があるか否か判定する。

そして、情報の送信があると判定された場合（Ｓ２１：ＹＥＳ）には、送信される情報を受信する（Ｓ２２）。尚、受信される情報には、情報の送信元のユーザ４を識別するユーザＩＤと、新たに登録或いは修正されたスケジュールの内容（例えば文章データ）を含む。また、受信したスケジュールの内容はユーザ毎に区分してスケジュールＤＢ１２に格納される（図３）。スケジュールの内容としては、『件名』、『日時』、『場所』が含まれるが、『場所』についてはユーザによって入力されない場合もあり、その場合については空白（データ無し）となる。但し、『場所』が入力されていない場合であっても、『件名』から『場所』が推定できる場合には、『件名』から推定される『場所』をサーバ装置３側で入力しても良い。

一方、情報の送信がないと判定された場合（Ｓ２１：ＮＯ）には、当該スケジュール管理処理プログラムを終了する。

Ｓ２３においてＣＰＵ２１は、前記Ｓ２２で受信したスケジュールの内容の解析を行う。より具体的にはスケジュールの内容に『場所』を特定する情報が含まれているか否かを判定する。

次に、Ｓ２４においてＣＰＵ２１は、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できるか否かを判定する。尚、“ユーザの移動が必要なスケジュール”とは、スケジュールを実行する前にスケジュールを実行する場所までユーザが移動する必要があるスケジュールをいう。そして、ＣＰＵ２１は、前記Ｓ２３の解析結果に基づいて、スケジュールの内容に『場所』を特定する情報が含まれている場合には、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できると推定する。

そして、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できると推定された場合（Ｓ２４：ＹＥＳ）には、Ｓ３０へと移行する。それに対して、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できないと推定された場合（Ｓ２４：ＮＯ）には、Ｓ２５へと移行する。

Ｓ２５においてＣＰＵ２１は、グルーピングＤＢ１４に記憶されている情報を読み出す。尚、グルーピングＤＢ１４は、前述のＤＢ作成処理プログラム（図８）で作成され、図５に示すように同一又は類似するユーザ特性毎にグループ分けし、各グループに対してスケジュールの内容と移動実績とを紐付けたデータベースである。

次に、Ｓ２６においてＣＰＵ２１は、スケジュールの送信元のユーザが含まれるグループの移動実績がグルーピングＤＢ１４にあるか否か判定する。尚、スケジュールの送信元のユーザは、前記Ｓ２２で受信した情報に含まれるユーザＩＤによって識別される。例えば図５に示すグルーピングＤＢ１４が格納されている場合において、情報を要求したユーザがユーザＡである場合には、ユーザＡを含むグループＧ１の移動実績が格納されているので、移動実績がグルーピングＤＢ１４にあると判定される。

そして、スケジュールの送信元のユーザが含まれるグループの移動実績がグルーピングＤＢ１４にあると判定された場合（Ｓ２６：ＹＥＳ）には、Ｓ２８へと移行する。それに対して、スケジュールの送信元のユーザが含まれるグループの移動実績がグルーピングＤＢ１４にないと判定された場合（Ｓ２６：ＮＯ）には、Ｓ２７へと移行する。

Ｓ２７においてＣＰＵ２１は、グルーピングＤＢ１４を用いた判定を行うことが困難であるので、前記Ｓ２２で受信したスケジュールについてはユーザの移動が不要なスケジュールと仮定する。その後、特にスケジュールの修正提案等は行うことなく当該スケジュール管理処理プログラムを終了する。

一方、前記Ｓ２７では問い返し処理を行っても良い。具体的には、スケジュールが実施される場所を明確にするための質問を、情報端末５を介して出力する。そして、質問の回答として入力されたユーザの回答について情報端末５を介して取得する。上記問い返し処理によってスケジュールが実施される場所が特定された場合には、Ｓ３０へと移行する。

一方、Ｓ２８においてＣＰＵ２１は、スケジュールの送信元のユーザが含まれるグループの移動実績の内、特に前記Ｓ２２で受信したスケジュールの内容と同一又は類似するスケジュールの内容に対する移動実績がグルーピングＤＢ１４内にあるか否か判定する。尚、スケジュールの内容が類似するとは、例えば比較対象となるスケジュールの『件名』をそれぞれ文節で区分し、文節が一部又は完全に共通する場合に、スケジュールの内容が類似するとみなす。例えば前記Ｓ２２で受信したスケジュールの『件名』が「○○さんに電話」であった場合には、「○○さんに」と「電話」を含む『件名』のスケジュールがグルーピングＤＢ１４にあれば、同一又は類似するスケジュールの内容がグルーピングＤＢ１４内にあると判定される。

そして、スケジュールの送信元のユーザが含まれるグループの移動実績の内、特に前記Ｓ２２で受信したスケジュールの内容と同一又は類似するスケジュールの内容に対する移動実績がグルーピングＤＢ１４内にあると判定された場合（Ｓ２８：ＹＥＳ）には、Ｓ２９へと移行する。それに対して、スケジュールの送信元のユーザが含まれるグループの移動実績の内、特に前記Ｓ２２で受信したスケジュールの内容と同一又は類似するスケジュールの内容に対する移動実績がグルーピングＤＢ１４内にないと判定された場合（Ｓ２８：ＮＯ）には、Ｓ２７へと移行する。

Ｓ２９においてＣＰＵ２１は、スケジュールの送信元のユーザが含まれるグループの移動実績の内、スケジュールの内容が最も類似するスケジュールに対する移動実績をグルーピングＤＢ１４から抽出する。前記Ｓ２９で抽出される移動実績は、スケジュールの送信元のユーザと類似する特性を有する他のユーザが過去に類似するスケジュールを実施した際に、移動が必要であったか否かを特定するものである。

その後、Ｓ３０においてＣＰＵ２１は、前記Ｓ２９で抽出された移動実績に基づいて、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールか否かを判定する。具体的には、前記Ｓ２９で抽出された移動実績が、スケジュールに対してユーザが移動を行っていた場合にはユーザの移動が必要なスケジュールであると判定するとともに、スケジュールに対してユーザが移動を行っていない場合にはユーザの移動が必要でないスケジュールであると判定する。

一方、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できると推定された場合（Ｓ２４：ＹＥＳ）に実行されるＳ３０では、スケジュールの内容に含まれる『場所』に基づいて該スケジュールがユーザの移動が必要なスケジュールか否かを判定する。例えば、スケジュールの内容に含まれる『場所』が、平日の勤務時間帯であればユーザの勤務地から離れた場所であれば、ユーザの移動が必要なスケジュールと判定される。一方、平日の勤務時間外や休日であればユーザの自宅から離れた場所であれば、ユーザの移動が必要なスケジュールと判定される。或いは、スケジュールの『件名』に含まれるワードから判定することも可能である。例えば「出張」、「旅行」、「外食」などを含む場合には、ユーザの移動が必要なスケジュールと判定される。一方、「電話」、「資料作成」などを含む場合には、ユーザの移動が不要なスケジュールと判定される。

そして、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が必要なスケジュールと判定された場合（Ｓ３０：ＹＥＳ）には、Ｓ３１へと移行する。それに対して、前記Ｓ２２で受信したスケジュールについて、該スケジュールがユーザの移動が不要なスケジュールと判定された場合（Ｓ３０：ＮＯ）には、特にスケジュールの修正提案等は行うことなく当該スケジュール管理処理プログラムを終了する。

Ｓ３１においてＣＰＵ２１は、スケジュールＤＢ１２を参照し、前記Ｓ２２で受信したスケジュールで指定される日時或いは時間帯の所定時間前までに他のスケジュールが登録されているか否かを判定する。尚、前記Ｓ３１で判定基準となる所定時間は、前記Ｓ２２で受信したスケジュールの実施される場所へのユーザの移動に必要な時間に基づいて設定するのが望ましい。例えば、ユーザの移動に必要な時間が３０分と推定される場合には、４０分前までに他のスケジュールが登録されているか否かを判定する。

そして、前記Ｓ２２で受信したスケジュールで指定される日時或いは時間帯の所定時間前までに他のスケジュールが登録されていると判定された場合（Ｓ３１：ＹＥＳ）には、Ｓ３２へと移行する。それに対して、前記Ｓ２２で受信したスケジュールで指定される日時或いは時間帯の所定時間前までに他のスケジュールが登録されていないと判定された場合（Ｓ３１：ＮＯ）には、特にスケジュールの修正提案等は行うことなく当該スケジュール管理処理プログラムを終了する。

Ｓ３２においてＣＰＵ２１は、情報端末５を介してユーザに対してスケジュールの修正の提案を行う。例えば、図１０に示すようにサーバ装置３が、１０：００〜１１：００までの間のスケジュールを前記Ｓ２２で受信した場合において、該スケジュールがユーザの移動が必要なスケジュールであって、且つ１０：００から所定時間前（例えば４０分前）までの間に他のスケジュールがあると判定された場合には、一方のスケジュールの時間をずらすように提案する。そして、提案に従って情報端末５側でスケジュールの修正に係る操作が行われた場合には、修正後のスケジュールを対象として再度Ｓ２２以降の処理を行う。

尚、サーバ装置３ではなく情報端末５において、上記Ｓ２２〜Ｓ３２の処理を実行させる構成としても良い。その場合には、グルーピングＤＢ１４をサーバ装置３から情報端末５へと配信するように構成する。また、ＤＢ作成処理プログラム（図８）についても情報端末５で実行させる構成としても良い。

以上詳細に説明した通り、本実施形態に係るスケジュール管理システム１及びサーバ装置３では、過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集し（Ｓ３）、同一又は類似するユーザの特性毎に区分して、移動実績を紐付けて格納するデータベースを作成する（Ｓ５）。一方で、ユーザによってスケジュールの登録操作が行われた場合に、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合において、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた過去の移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定する（Ｓ３０）ので、登録されたスケジュールの内容からユーザの移動を必要とするスケジュールであるか否か判定できない場合であっても、対応する過去の移動実績からユーザの移動が必要なスケジュールであるか否かを適切に判定することが可能となる。その結果、登録されたスケジュールの内容にかかわらず、ユーザの移動を考慮したスケジュール管理が可能となる。

尚、本発明は前記実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲内で種々の改良、変形が可能であることは勿論である。
例えば、本実施形態では、一のサーバ装置３がスケジュールＤＢ１２、移動実績ＤＢ１３及びグルーピングＤＢ１４の各ＤＢを作成する処理とスケジュールの管理を行う処理をそれぞれ行っているが、各ＤＢを作成する処理とスケジュールの管理を行う処理は別々のサーバ装置が行うようにしても良い。例えば、サーバ装置３が他のサーバ装置で作成された各ＤＢを受信して、スケジュールの管理を行うようにしても良い。

また、本実施形態では、前記Ｓ２４においてスケジュールの内容に『場所』を特定する情報が含まれている場合には、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できると推定しているが、他の条件に基づいて判定しても良い。例えば、スケジュールの『件名』に特定のワードを含む場合に、該スケジュールがユーザの移動が必要なスケジュールか否かを判定できると推定しても良い。特定のワードとしては例えば「出張」、「旅行」、「電話」、「会議」、「資料作成」、「外食」などである。

また、本実施形態では、情報端末５をスマートフォンに適用した例について説明したが、スケジュールを管理する機能を有していれば他の種類の情報端末に対して適用することも可能である。例えば携帯電話機、タブレット型端末、パーソナルコンピュータ、ナビゲーション装置等に適用することが可能である。

また、本発明に係るスケジュール管理システムを具体化した実施例について上記に説明したが、スケジュール管理システムは以下の構成を有することも可能であり、その場合には以下の効果を奏する。

例えば、第１の構成は以下のとおりである。
ユーザ（４）のスケジュールを登録するスケジュール登録手段（２１）と、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する移動判定手段（２１）と、前記移動判定手段の判定結果に基づいて登録された前記スケジュールを管理するスケジュール管理手段（２１）と、を有するスケジュール管理システム（１）であって、過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する移動実績収集手段（２１）と、同一又は類似するユーザの特性毎に区分して、前記移動実績を紐付けて格納する移動実績格納手段（２１）と、を有し、前記移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定する。
上記構成を有するスケジュール管理システムによれば、ユーザの特性とスケジュールに対するユーザの移動有無の実績を紐付けてデータベース化することによって、登録されたスケジュールの内容からユーザの移動を必要とするスケジュールであるか否か判定できない場合であっても、対応する過去の移動実績からユーザの移動が必要なスケジュールであるか否かを適切に判定することが可能となる。その結果、登録されたスケジュールの内容にかかわらず、ユーザの移動を考慮したスケジュール管理が可能となる。

また、第２の構成は以下のとおりである。
前記移動判定手段（２１）は、登録されたスケジュールに場所を特定する情報を含まない場合が、登録されたスケジュールの内容からユーザ（４）の移動が必要なスケジュールか否かを判定できない場合となる。
上記構成を有するスケジュール管理システムによれば、スケジュールに場所を特定する情報を含まない場合においても、過去の移動実績からユーザの移動が必要なスケジュールであるか否かを適切に判定することが可能となる。

また、第３の構成は以下のとおりである。
前記移動判定手段（２１）は、登録されたスケジュールの内容からユーザ（４）の移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績の内、最も類似するスケジュールの内容を含む移動実績を抽出し、抽出された前記移動実績が、スケジュールに対してユーザが移動を行っていた場合にはユーザの移動が必要なスケジュールであると判定するとともに、スケジュールに対してユーザが移動を行っていない場合にはユーザの移動が必要でないスケジュールであると判定する。
上記構成を有するスケジュール管理システムによれば、過去の移動実績の内、同一または類似するユーザ特性を有する他のユーザが過去に最も類似するスケジュールを実施した際の移動実績から、ユーザの移動が必要なスケジュールであるか否かを適切に判定することが可能となる。

また、第４の構成は以下のとおりである。
前記ユーザ（４）の特性は、年代、性別の少なくとも一方を含む。
上記構成を有するスケジュール管理システムによれば、一又は複数の項目からユーザの特性を特定可能であり、スケジュールを実施するユーザの特性に応じて、スケジュールを実施する際に移動が必要か否かを特定することが可能となる。

また、第５の構成は以下のとおりである。
前記スケジュール管理手段（２１）は、前記移動判定手段（２１）によってユーザ（４）の移動が必要と判定されたスケジュールの登録時間帯の所定時間前までに他のスケジュールが登録されている場合に、ユーザに対してスケジュールの調整を提案する。
上記構成を有するスケジュール管理システムによれば、特にユーザの移動が必要とされるスケジュールの前に他のスケジュールが登録されている場合において、スケジュールの調整を提案することが可能となる。その結果、ユーザにとって実施困難なスケジュールが登録されることを防止することが可能となる。

１ スケジュール管理システム
２ スケジュール管理センタ
３ サーバ装置
４ ユーザ
５ 情報端末
１１ サーバ制御ＥＣＵ
１２ スケジュールＤＢ
１３ 移動実績ＤＢ
１４ グルーピングＤＢ
２１ ＣＰＵ
２２ ＲＡＭ
２３ ＲＯＭ

Claims (6)

1. ユーザのスケジュールを登録するスケジュール登録手段と、
   登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する移動判定手段と、
   前記移動判定手段の判定結果に基づいて登録された前記スケジュールを管理するスケジュール管理手段と、を有するスケジュール管理システムであって、
   過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する移動実績収集手段と、
   同一又は類似するユーザの特性毎に区分して、前記移動実績を紐付けて格納する移動実績格納手段と、を有し、
   前記移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定するスケジュール管理システム。
2. 前記移動判定手段は、登録されたスケジュールに場所を特定する情報を含まない場合が、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合となる請求項１に記載のスケジュール管理システム。
3. 前記移動判定手段は、
   登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績の内、最も類似するスケジュールの内容を含む移動実績を抽出し、
   抽出された前記移動実績が、スケジュールに対してユーザが移動を行っていた場合にはユーザの移動が必要なスケジュールであると判定するとともに、スケジュールに対してユーザが移動を行っていない場合にはユーザの移動が必要でないスケジュールであると判定する請求項１又は請求項２に記載のスケジュール管理システム。
4. 前記ユーザの特性は、年代、性別の少なくとも一方を含む請求項１乃至請求項３のいずれかに記載のスケジュール管理システム。
5. 前記スケジュール管理手段は、前記移動判定手段によってユーザの移動が必要と判定されたスケジュールの登録時間帯の所定時間前までに他のスケジュールが登録されている場合に、ユーザに対してスケジュールの調整を提案する請求項１乃至請求項４のいずれかに記載のスケジュール管理システム。
6. ユーザのスケジュールを登録するスケジュール登録手段と、
   登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定する移動判定手段と、
   前記移動判定手段の判定結果に基づいて登録された前記スケジュールを管理するスケジュール管理手段と、を有するスケジュール管理装置であって、
   過去に登録されたスケジュールの内容と該スケジュールに対するユーザの移動有無とを特定する移動実績を、該ユーザの特性とともに複数のユーザから収集する移動実績収集手段と、
   同一又は類似するユーザの特性毎に区分して、前記移動実績を紐付けて格納する移動実績格納手段と、を有し、
   前記移動判定手段は、登録されたスケジュールの内容からユーザの移動が必要なスケジュールか否かを判定できない場合に、該スケジュールを登録したユーザの特性と同一又は類似するユーザの特性が紐付けられた前記移動実績に基づいてユーザの移動が必要なスケジュールか否かを判定するスケジュール管理装置。

Images